Kubernetes: "Helm Tiller" Install fails with "ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.6/main: temporary error (try again later)"

I’m (still) getting the following error when trying to install Helm Tiller on our internal Kubernetes cluster:

Something went wrong while installing Helm Tiller

ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.6/main: temporary error (try again later) WARNING: Ignoring APKINDEX.84815163.tar.gz: No such file or directory ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.6/community: temporary error (try again later) WARNING: Ignoring APKINDEX.24d64ab1.tar.gz: No such file or directory ERROR: http://mirror.clarkson.edu/alpine/v3.6/main: temporary error (try again later) WARNING: Ignoring APKINDEX.490b721e.tar.gz: No such file or directory ERROR: http://mirror1.hs-esslingen.de/pub/Mirrors/alpine/v3.6/main: temporary error (try again later) WARNING: Ignoring APKINDEX.44c98ace.tar.gz: No such file or directory ERROR: unsatisfiable constraints:

(I have got the same error yesterday.)

When trying again, I’m getting the following error:

Kubernetes error: configmaps "values-content-configuration-helm" already exists

I was able to solve this problem by manually deleting the configmap via the Kubernetes dashboard (though it would be great if GitLab would not mind if the configmap already existed).

But how can I fix the error regarding alpinelinux?

Solution:

Edit /etc/systemd/resolved.conf and set: FallbackDNS=1.1.1.1 1.0.0.1

(Source: Leandro Noskoski’s answer on askubuntu.com)

Background:

  • The Kubernetes cluster is running with minikube on a freshly installed Ubuntu 18.04 LTS host.
  • Ubuntu 18.04 LTS uses netplan by default and symlinks from /etc/resolv.conf to /run/systemd/resolve/stub-resolv.conf, which defines a nameserver at 127.0.0.53.
  • The /etc/resolv.conf is apparently used in the container, where 127.0.0.53 is obviously not available and therefore cannot resolve DNS queries.

PS: Previously I suggested redirecting the symlink to /run/systemd/resolve/resolv.conf, but that’s not a solution, because the symlink is restored when systemd-resolve starts.