有关中国Azure Stack部署K8S的疑难解答

提示

要参加微信课堂以及日常技术交流，请给我们发微信(微信号：markpah)，请注明加入以下哪个群：

• 微软Azure Stack交流微信群
• 微软Azure Docker交流微信群

哪位朋友已经在Azure Stack里部署过K8S了吗？

昨天官网已经发布了如何在Azure Stack里部署K8S的文档：

https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-solution-template-kubernetes-cluster-add

不过国内的朋友，请您留步，因为该文档并不适合中国区的用户，主要是因为伟大的防火墙的原因，请暂移尊驾参考盆盆的文章(您可以在公众号里回复k8s即可看到盆盆的这篇文章)。

核心步骤

核心步骤就是生成ARM模板后，确保作以下修改：

以下是对AzureDeployParameters.json文件进行修改：

• "dockerEngineDownloadRepo": { "value": "https://mirror.kaiyuanshe.cn/docker-engine/apt/repo/"
• 同时搜索k8s-gcrio.azureedge.net，将其改为“ crproxy.trafficmanager.net:6000/google_containers ”。
• 并将以下参数改为： "kubernetesTillerSpec": { "value": "crproxy.trafficmanager.net:6000/kubernetes-helm/tiller:v2.8.1"

同时修改azuredeploy.json文件的CustomData部分，这部分将会通过Cloud Init执行相关的配置脚本：

• 搜索--pod-infra-container-image，将其改为以下的格式(共有2处)： --pod-infra-container-image=crproxy.trafficmanager.net:6000/google_containers/pause-amd64:3.1
• 指定docker hub mirror，搜索 retrycmd_if_failure 20 10 apt-get install -y ebtables docker-engine，在其后添加以下的语句(共有2处)： \n- curl -sSL WebPath/dockermirror.sh | sh -s 请注意，其中的dockermirror.sh是指您用来更改docker mirror的脚本。可以使用DaoCloud或者其他docker mirror，如果不设置mirror的话，那么大概率无法从docker hub下载约512MB的定制HyperKubeImage。该脚本的内容可以是以下格式，并将其上传到Azure中国的Blob里。

sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json <<-'EOF' { "registry-mirrors": ["https://YourMirror"] } EOF

疑难问题

请注意，不管是用ASDK，还是多节点的Azure Stack，请确保一定要使用最新的1803版本，否则会遇到Cloud Init执行失败的问题！

盆盆就曾经遇到在1802版本里，节点在每次执行Cloud init时，节点虚拟机都会自动重启，导致Cloud init里的runcmd脚本执行失败，由于这个脚本的任务是安装docker engine，这会导致节点连docker都无法安装。所以CustomScript扩展的Provision.sh脚本也无法执行。

这时候如果检查Agent虚拟机的syslog日志，可以发现以下的事件：

hv_utils: Shutdownrequest received - graceful shutdown initiated

紧接着Agent就重启，导致Cloud init失败(默认仅执行一次)

在Azure Stack服务器节点上查看日志，可以发现这个关机操作，是由Hyper-V集成服务的关机功能执行的，也就是说这是由Azure Stack的Hypervisor发起的操作，而不是节点自己。事件里的GUID是虚拟机的GUID。

在虚拟机的Hyper-V属性对话框里可以看到该虚拟机就是Master节点。Agent也会一样。

这时候，可以在节点虚拟机上执行以下命令，就可以继续执行cloud init，有机会完成后续的操作：

sudo /usr/bin/cloud-initsingle -n cc_scripts_user

这时候盆盆想到，既然是这个关机事件是由Hyper-V Hypervisor发起的，是通过Hyper-V集成服务执行的(就是Linux虚拟机里的hv_utils)，那么我只要在Cloud init的runcmd脚本里添加以下的内容，每次执行runcmd的时候，自动停用hv_utils服务，等runcmd执行到最后一步，再启用hv_utils，不就可以避免系统重启了吗？

kill-1 `pidof hv_kvp_daemon`

kill-1 `pidof hv_vss_daemon`

rmmod hv_utils

但是结果很遗憾，这个操作会导致节点虚拟机直接失联，无法通过SSH访问。

所以，还是直接升级到最新的1803版本吧！