Installing behind a proxy

Configuring MicroK8s services

To let MicroK8s use a proxy we need to enter the proxy details in
${SNAP_DATA}/args/containerd-env (normally /var/snap/microk8s/current/args/containerd-env). The containerd-env file holds the environment variables containerd runs with. Setting the HTTPS_PROXY to your proxy endpoint enables containerd to fetch conatiner images from the web. You may also want to set the NO_PROXY to the cluster-cidr and the services-cidr as specified in the respective configuration files /var/snap/microk8s/current/args/kube-proxy and /var/snap/microk8s/current/args/kube-apiserver.

Here is an example where HTTPS_PROXY is set to https://squid.internal:3128 and NO_PROXY to 10.1.0.0/16,10.152.183.0/24:

HTTPS_PROXY=https://squid.internal:3128
NO_PROXY=10.1.0.0/16,10.152.183.0/24
#
# Some additional environment variables
#
ulimit -n 65536 || true
ulimit -l 16384 || true

For the changes to take effect we need to restart MicroK8s:

microk8s stop
microk8s start

Host configuration and clustering behind a proxy

Any nodes where MicroK8s is installed on need to be included in the no_proxy environment variable of the host. Usually this can be be done by editing /etc/environment.

DNS configuration

By default the DNS addon (available with microk8s enable dns) points to Google’s 8.8.8.8 and 8.8.4.4 servers for resolving addresses outside the cluster. If these forward DNS endpoints are not reachable you may want to reconfigure CoreDNS as described in the addon’s documentation page.

Some feedback on this page:

  1. Thank you for this page existing! My first attempt at Kubernetes is using a VM on a company server that’s behind a firewall, so I did need to set up a proxy and it was useful to have this page here.

  2. The default of https://squid.internal:3128 seemed appropriate to me but didn’t work for me in the end. I had just uncommented the default in /var/snap/microk8s/current/args/containerd-env. However it turned out that it needed to be http://squid.internal:3128 (not HTTPS). I understand that this should be the common case for most (all?) users who need to configure a proxy; is there anyone who actually uses HTTPS to their own local proxy? If not, then can I suggest that both the doc example and the commented out example in the configuration file be changed?

  3. There was no indication of what the problem was. Perhaps this page could document what the user expects to see when there is a connection problem that might need a proxy configuration? In my case I was following the Getting started page. The microk8s status --wait-ready command hung forever. Running microk8s status told me microk8s is not running. Use microk8s inspect for a deeper inspection. but microk8s inspect listed all services as running. It wasn’t clear to me if this was a proxy configuration problem or something else entirely.

  4. There was no indication of what to do specifically in the Getting started case when proxy configuration is required. Is microk8s stop; microk8s start supposed to fix it? Because I hadn’t yet figured out the configuration error, it didn’t fix it, and I was left wondering if the problem was that some bootstrap step had failed and wouldn’t attempt to run again. In the end, once I worked out the actual problem, microk8s stop; microk8s start did work; my point is some positive affirmation that this is expected to work even on an initial bootstrap failure would have been helpful. Or even better, it’d be nice to be able to supply the proxy configuration prior to any failure, and for the quick start documentation to mention that.

Hi Robie! Great to hear from you.

That’s a great point and a fairly easy fix. I will take advice on what the commonest scenario is, but it is easy to add some note or explanation there to call out that your endpoint may be different.

I agree, a lot of the time knowing exactly what the problem is is 90% of solving it. We can add some more troubleshooting help around this. I wonder @kjackal - is there some nicer way MicroK8s itself could surface such issues?

The getting started is really intended for the general use case. I am reluctant to add too many extra’diversions’ in there, but I agree that we should at least signpost this better, and I will see if I can take a fresh look at the user journey here with your comments in mind.

Really, thanks so much for providing your feedback and spending the time to detail your experience - it is so much more useful than “it doesn’t work” comments!

Thank you for looking at this!

I understand the need to not overcomplicate the general use case directions, so I leave that to your judgement. If you choose not to do that, I wonder if instead referring to the “Getting started” instructions from the “Installing behind a proxy” page might work instead. Specifically so readers can understand how the two things are to be integrated even if the instructions themselves are on the latter page. That’s the connection that I had missed. I suppose the two specific questions I had there were:

  • Were the proxy instructions intended/capable to fix the Quick start or not?
  • If yes, then at what point in the Quick start instructions was it intended that I intervene to configure the proxy, where should I resume in the Quick start instructions when done, and what (if any) steps needed redoing in the Quick start instructions before resuming?