Ubuntu下安装microk8s用代理解决无法拉取镜像问题

首先安装microk8s:

sudo snap install microk8s --classic
1

得到输出：

microk8s (1.28/stable) v1.28.7 from Canonical✓ installed
1

设置 K8s 命令别名（alias）

MicroK8s 支持的命令中，我们会相对高频的使用 microk8s.kubectl 这个命令，这个命令相比较官方默认命令 kubectl 长了不少，使用起来不是特别方便。我们可以通过 snap alias 来给命令起个别名：

sudo snap alias microk8s.kubectl kubectl
1

当命令执行完毕，我们将得到下面的日志输出，表示创建命令别名成功：

Added:
  - microk8s.kubectl as kubectl
1
2

接下来，我们就能够直接在系统中使用 kubectl 命令啦。

类似的，我们还可以将高频使用的 主要命令 从 microk8s中“映射”出来：

sudo snap alias microk8s.ctr ctr
sudo snap alias microk8s.helm helm
sudo snap alias microk8s.helm3 helm3
1
2
3

解决 MicroK8s 运行权限问题

完成安装之后，想要在非 root 环境下使用，还需要做一些额外的工作。执行 microk8s.version ，我们可以得到下面的包含“引导信息”的日志：

Insufficient permissions to access MicroK8s.
You can either try again with sudo or add the user soulteary to the 'microk8s' group:

    sudo usermod -a -G microk8s xxx
    sudo chown -f -R xxx ~/.kube

After this, reload the user groups either via a reboot or by running 'newgrp microk8s'.
1
2
3
4
5
6
7

按提示执行命令就可以了，不再复述。

解决 MicroK8s 无法正常运行的问题

在解决上面的问题之后，当我们执行 microk8s status ，可能会得到类似下面的日志输出，告诉我们程序并没有按照预期运行：

microk8s is not running. Use microk8s inspect for a deeper inspection.
1

我们可以执行 microk8s.inspect 查看是否有报错信息，如果没有任何报错，可以来通过 kubectl 来进一步排查问题到底出现在了哪里。

先通过 kubectl 获取所有 pods 的运行状况：

kubectl get pods --all-namespaces
1

命令执行完毕，将得到类似下面的日志结果：

NAMESPACE     NAME                                     READY   STATUS     RESTARTS   AGE
kube-system   calico-node-crhgl                        0/1     Init:0/2   0          3m56s
kube-system   calico-kube-controllers-77bd7c5b-xnd48   0/1     Pending    0          3m56s
kube-system   coredns-864597b5fd-jmb4m                 0/1     Pending    0          3m56s
1
2
3
4

根据日志可以看到，有一个 pod 的状态是 “Init:0/2”，另外一个是“Pending”。这个排队启动的问题，是导致我们的 MicroK8s 没有正常运行的主要原因。

接着，使用 kubectl describe pod 来查看到底是为什么：

kubectl describe pod calico-node-crhgl -n kube-system
1

输出信息比较多，最后面会有这么几行：

Events:
  Type     Reason                  Age                    From               Message
  ----     ------                  ----                   ----               -------
  Normal   Scheduled               5m13s                  default-scheduler  Successfully assigned kube-system/calico-node-crhgl to ibm-johnny-z13
  Warning  FailedMount             5m13s                  kubelet            MountVolume.SetUp failed for volume "kube-api-access-mpscq" : configmap "kube-root-ca.crt" not found
  Warning  FailedCreatePodSandBox  3m13s (x2 over 4m42s)  kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to get sandbox image "registry.k8s.io/pause:3.7": failed to pull image "registry.k8s.io/pause:3.7": failed to pull and unpack image "registry.k8s.io/pause:3.7": failed to resolve reference "registry.k8s.io/pause:3.7": failed to do request: Head "https://us-west2-docker.pkg.dev/v2/k8s-artifacts-prod/images/pause/manifests/3.7": dial tcp 142.251.8.82:443: i/o timeout
  Warning  FailedCreatePodSandBox  22s (x5 over 4m)       kubelet            Failed to create pod sandbox: rpc error: code = DeadlineExceeded desc = failed to get sandbox image "registry.k8s.io/pause:3.7": failed to pull image "registry.k8s.io/pause:3.7": failed to pull and unpack image "registry.k8s.io/pause:3.7": failed to resolve reference "registry.k8s.io/pause:3.7": failed to do request: Head "https://us-west2-docker.pkg.dev/v2/k8s-artifacts-prod/images/pause/manifests/3.7": dial tcp 142.251.8.82:443: i/o timeout
1
2
3
4
5
6
7

看到failed to pull image "registry.k8s.io/pause:3.7"这个关键信息了，就明白registry.k8s.io被墙了，于是设置一下proxy，前提是我司有一个代理于是打开sudo gedit /var/snap/microk8s/current/args/containerd-env
，把里面的HTTPS_PROXY和NO_PROXY两行打开，填上真确的值，例如：

HTTPS_PROXY=http://proxy.emea.ibm.com:8080
NO_PROXY=10.0.0.0/8,192.168.0.0/16,127.0.0.1,172.16.0.0/16
1
2

然后再重启microk8s:

microk8s stop && microk8s start
1

然后再用microk8s status查看，一切正常了。
注：网上说自已用ctr image pull 自己手动拉相关镜像，我拉下来了，但它还是报错，不知道为什么。