聚焦minikube部署过程中遇到的问题，本博客按照Minikube官方文档进行安装，阿里维护了一个国内版，解决某些域名被屏蔽的问题，参考阿里版Minikube。
系统环境：ubuntu 18.04。
准备工作
需要具备的条件：
- 足够的硬件资源，见官方文档“What you'll need”节；
- 网络；
- 容器或虚拟机管理程序。
Dirver的选择和安装
需要明确的是minikube如何进行工作，minikube借助容器或者虚拟机管理程序，即dirver，创建和管理k8s集群，本实验使用docker作为dirver，当使用minikube创建一个集群时，首先主机创建一个minikube容器作为node，然后在该node内启动k8s的组件容器，从而创建一个k8s集群，如果选择kvm2作为dirver，则minikube首先创建一个虚拟机，然后在虚拟机内创建k8s集群，minikube建议在虚拟机中运行时将dirver设置为none，从而在运行minukube的虚拟机上直接部署k8s组件容器，本实验未采纳建议。
实验环境示意：
single node k8s cluster
\----------------------------- docker
Container：minikube
\----------------------------- dirver：docker
ubuntu 18.04
\----------------------------- virtualbox
windows 10
本实验docker安装按照Docker官方文档进行。
minikube安装
使用deb包的方式安装
问题
执行minikube start提示权限问题
实际上由执行docker命令的权限不足引起，minikube不能使用root权限运行，因此将运行minikube start命令的非root用户加入docker组并生效后即可。
在ubuntu中，将用户加入某用户组后不能立即生效，以下操作使配置生效：
# 添加用户到用户组
sudo usermod -aG docker $USER
# 登入docker群组，使配置生效
newgrp docker
CoreDNS CrashLoopBackOff
coredns pod打印的fatal级别日志：
[FATAL] plugin/loop: Loop (127.0.0.1:55603 -> :53) detected for zone ".", see https://coredns.io/plugins/loop#troubleshooting. Query: "HINFO 7185543744641930479.6516381192300417577."
错误日志包含的链接中说明了该类错误发生的原因并给出了解决方案，对于使用systemd-resolved实现dns缓存的系统（例如实验环境ubuntu 18.04），默认配置情况下，/etc/resolv.conf中包含了nameserver 127.0.0.53配置，kubelet默认读取该文件中的配置并传导到pod中，导致pod不能进行正确的dns解析，coredns同样读取该配置，导致请求转发回自身，发生loop情况，解决此问题需要确保/etc/resolv.conf中不能包含类似nameserver 127.0.0.x的配置。
关键在于对/etc/resolv.conf的修改，需要明确两点：
-
修改哪一个：
在dirver使用docker的情况下（本实验环境），kubelet、coredns读取的配置文件位于minikube创建的minikube容器内，可使用minikube ssh连接至该容器进行观察，在dirver设置为none的情况下，读取的配置文件位于运行minikube的主机，其他情况与这两类情况相似。 -
如何修改：
出于对linux软件的兼容性支持，该配置文件作为一个接口文件，在系统使用systemd-resolved提供dns服务时，该文件作为systemd-resolved管理的配置文件的软链接，供其他程序访问，使用其他程序提供dns服务时，该文件也可以成为其他文件的软链接，某些情况下也可以是静态文件，因此该文件的修改需要根据其实际状况决定，对于本实验环境dirver使用docker的情况，进入minikube容器中获知该文件的类型为静态文件，可以通过修改该文件，解决此故障，不应在容器内修改文件，正确修改方法参考minikube的File Sync文档，具体如下：mkdir -p ~/.minikube/files/etc echo nameserver 8.8.8.8 > ~/.minikube/files/etc/resolv.conf # 文件覆盖在start后发生，因此需要重启该集群 minikube stop minikube start当该配置文件为软链接时，可以修改此文件的指向，例如将其指向同样由systemd-resolved服务管理的
/run/systemd/resolve/resolv.conf，而不是默认的/run/systemd/resolve/stub-resolv.conf，修改后可能需要重启systemd-resolved服务。
此节说明的修改仅为确保minikube正常运行，由此引发的其他问题发生后再进行解决。
参考文档：
resolved.conf中文手册 英文
systemd-resolved.service中文手册 英文
kubelet
minikube已经包含kubelet，使用方式如下：
minikube kubectl -- get pods -A
dashboard监听在127.0.0.1，远程浏览器无法访问
使用kubectl proxy做一层代理即可，操作如下：
# 启动dashboard，输出url
minikube dashboard --url
# 使用kubectl proxy监听所有地址
minikube kubectl -- proxy --address=0.0.0.0 --accept-hosts='.*'
# 返回代理地址为[::]:8001
# 可远程访问的url：
# http://192.168.56.58:8001/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/
无法下载位于k8s.gcr.io的镜像
在minikube get started文档第四步deploy applications中，创建deployment后无法成功创建hello-minikube pod，原因为gfw阻止了对该域名的访问，此时可以进入minikube容器（使用minikube ssh）pull相关镜像到本地然后修改tag，在kubelet优先从本地加载镜像的前提下可解决此问题，例如拉取k8s.gcr.io/echoserver:1.4镜像，可先在阿里云谷歌镜像仓库拉取registry.cn-hangzhou.aliyuncs.com/google_containers/echoserver:1.4，后修改tag，本实验环境通过合理上网解决此问题，实际上是向docker传递了用于配置代理的环境变量，过程如下：
# 在物理机上启动代理软件（v2rayN），在软件内设置“允许来自局域网的连接”
# 停止集群
minikube stop
# 设置代理相关的环境变量，注意HTTPS_PROXY设置，由于代理软件未监听https端口，https代理设置为了http协议，
# 否则将出现“proxyconnect tcp: EOF”类型错误
export HTTP_PROXY=http://192.168.56.1:10809 # 注意，对于该项，curl只能识别小写的环境变量：http_proxy
export HTTPS_PROXY=http://192.168.56.1:10809
export NO_PROXY=localhost,127.0.0.1,10.96.0.0/12,192.168.99.0/24,192.168.39.0/24,192.168.49.0/24
# 启动集群，环境变量将传递至运行集群的docker环境
minikube start
# 完成应用部署
实验环境不包含本地浏览器，因此需要进行端口转发：minikube kubectl -- port-forward --address 0.0.0.0 service/hello-minikube 7080:8080，使服务能够通过http://192.168.56.58:7080/被远程访问。
关于获取gcr.io镜像的补充：
安装官方minikube后，执行minikube start --help可看到关于网络特殊情况的说明，可在启动时设置国家代码和中国仓库，具体内容如下：
--image-mirror-country='': Country code of the image mirror to be used. Leave empty to use the global one. For
Chinese mainland users, set it to cn.
--image-repository='': Alternative image repository to pull docker images from. This can be used when you have
limited access to gcr.io. Set it to "auto" to let minikube decide one for you. For Chinese mainland users, you may use
local gcr.io mirrors such as registry.cn-hangzhou.aliyuncs.com/google_containers
在安装完成的环境中minikube stop后使用带参数的minikube start测试，只设置image-mirror-country为cn没有观察到明显的变化，追加设置image-repository为registry.cn-hangzhou.aliyuncs.com/google_containers后，部分pod运行失败，失败原因为dashboard相关pod的image字段错误，例如系统实际拉取的镜像为registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-scraper:v1.0.4，但pod中image字段的值为registry.cn-hangzhou.aliyuncs.com/google_containers/ kubernetesui/ metrics-scraper:v1.0.4@sha256:555981a24f184420f3be0c79d4efb6c948a85cfce84034f85a563f4151a81cbf，这实际上是一个不存在的地址（已经标出url差异），未做深入研究。