聚焦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差異），未做深入研究。