说起部署Kubernetes这件事，相信做过的人都觉得挺麻烦的。目前主流的做法无非是两种：手动部署或者使用自动化工具。我们目前线上生产环境的k8s就是手动部署的。但对于我们这种小规模的技术团队，由于人力物力有限，手动部署后的运维、升级都不是很方便，而且为了简单，我们目前的集群并没有启用证书验证，也就是说整个通信是未加密的。
在侯斯特启用k8s的时候，当时还是1.5.6的版本阶段，当时为了解决我们自己的两个需求：1.在AWS中终止的ec2不要自动被从集群中删除；2.在创建service时可以选择哪些node挂载到ELB，而不是全部。其中，第一个需求目前已经不需要了；而第二个需求在k8s的1.9中已经alpha了，我也研究了他们的实现方法，与我们当时自己修改的k8s几乎一致。所以我们也不需要部署自己修改编译的版本了。所以我们选择使用Kops作为我们下一代集群的部署工具。之所以选择Kops而不是其他工具的原因是我们只使用AWS，而Kops也是专用于AWS的。
下面说说在中国区的AWS做这件事要面临的问题和解决方法：
1.DNS
以前，Kops是需要AWS的Route53服务的，而悲剧的是中国区没有这个服务，但是值得高兴的是目前新版本的Kops已经支持gossip-based cluster，只要是你的集群名称是“.k8s.local”结尾，那么就会跳过DNS检测。
2.AMI
目前Kops支持的操作系统主要有：Debian（默认），CoreOS，CentOS（并未推荐生产环境），而国际区默认的系统镜像“debian-jessie-amd64-hvm”在中国区并没有。那么要么从国际区搬一个回来（这个有很多教程，不赘述），要么使用CoreOS。这里推荐第二个办法，CoreOS已经在中国区的两个Region都有了官方的AMI：点击查看。因此，直接在创建集群的时候指定AMI的ID就好了。
3.cn-northwest-1（宁夏区域）
在目前Kops官方最新的release版本1.8.1中还不支持cn-northwest-1这个region，如果你使用这个版本在cn-northwest-1建立集群会报错，告诉你使用了不合法的区域。这个原因是两部分造成的：1.由于中国区AWS各个服务的Endpoint的格式和国际区不一致，所以在Kops中做了专门的判断，而他们的做法是判断是不是cn-north-1，那么显然cn-northwest-1就不行了；2.在Kops的依赖库中的aws sdk版本太老了，因为同样的原因不支持cn-northwest-1。所以大家可以看我的这3个PR：#4148、#4234、#4384。也就是说你如果想用Kops在cn-northwest-1建立集群，那么就要自行clone目前的最新稳定版并且自己Patch后编译（参照docs中开发相关的部分，很简单的）。
4.依赖的文件下载
Kops创建集群的时候要下载一些文件，主要是有两部分：1.Kops的部分（主要是用于启动集群中节点的时候初始化节点的工具）；2.k8s的部分（主要是k8s的组件还有CNI）。这些默认是从国际区的某一个S3下载的，但由于众所周知的原因，在国内的网络下失败率很高，延迟很高，带宽很低……。
要解决这个问题，我们首先的思路就是把这些需要的文件都下载下来，上传到国内，之后指定新的下载地址。那么这里就要解决两个问题：
(1)下载什么？
这个问题看上去简单，但是想一想你就会发现，你要看所有Kops的代码才能知道要下载什么。这里我发现一个办法：https://github.com/kubernetes/kops/blob/master/docs/development/release.md#upload-new-version
(2)怎么修改这个默认地址？
这里要分三部分：
第一部分是k8s的组件，这里可以使用集群创建时的kubernetesVersion这个参数控制的。例如：
kubernetesVersion: https://s3.cn-northwest-1.amazonaws.com.cn/${BUCKET}/kubernetes/release/v1.9.2
第二部分是Kops的组件，这里需要用环境变量处理：
export KOPS_BASE_URL=https://s3.cn-north-1.amazonaws.com.cn/$ASSET_BUCKET/kops/$KOPS_VERSION/
第三部分是CNI，这里也需要环境变量去处理，但是区别是需要两个环境变量：
export CNI_VERSION_URL=https://s3.cn-north-1.amazonaws.com.cn/$ASSET_BUCKET/kubernetes/network-plugins/$CNI_FILENAME
export CNI_ASSET_HASH_STRING=afbb526e7d976f98353ac96f73043031 (此处为$CNI_FILENAME的md5值)
5.hub.docker.com的加速和镜像
有一些依赖的镜像，例如weave是要从docker官方的镜像仓库拉取的。同样由于众所周知的原因，很慢，很不稳，很难……。那么我们就要用registry mirror的方案。我们直接在创建集群的yaml文件中增加一段描述就可以了：
docker:
registryMirrors:
- https://registry.docker-cn.com
6.gcr.io的镜像拉取
除了上文提到的那些文件和镜像，还有很多镜像需要从gcr.io这个仓库拉取，如果说上面提到的问题如果都不处理，就用默认的，那么运气好或者有耐心还有可能等到成功下载。那么这个gcr.io就是个完全无法成功的事情了，你问为什么？我的博客在国内，不敢说……。那么怎么办呢？依然是镜像的方式。但是不能像上面那么简单直接定义一个镜像地址就可以了。这里依然有两个办法：
首先要明确都要下载哪些images？主要有3部分：1.etcd；2.dns；3.pause。我可以列出来：
gcr.io/google_containers/etcd
gcr.io/google_containers/pause-amd64
gcr.io/google_containers/cluster-proportional-autoscaler-amd64
gcr.io/google_containers/k8s-dns-kube-dns-amd64
gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64
gcr.io/google_containers/k8s-dns-sidecar-amd64
gcr.io/google_containers/kubedns-amd64
gcr.io/google_containers/k8s-dns-dnsmasq-amd64
gcr.io/google_containers/dnsmasq-metrics-amd64
gcr.io/google_containers/exechealthz-amd64
(1)做个假的：
自己搭建一个docker registry，把上面的镜像自己想办法pull下来再push上去，之后在你的所有ec2上配置一下hosts或者配置你的内部dns解析gcr.io到这个假的registry。这样的好处是不用再修改Kops了。
(2)自定义镜像仓库地址（这里指写出关键部分，本文最后会提供完整的集群配置文件）：
etcd:
image: $REGISTRY/etcd:3.2.14
version: 3.2.14
pause:
podInfraContainerImage: $REGISTRY/pause-amd64:3.1
dns:
这个有点麻烦，要修改upup/models/cloudup/resources/addons/kube-dns.addons.k8s.io/k8s-1.6.yaml.template里面对应的值，之后重新编译Kops。
7.尾声
如果上面的步骤都做完了，那么就可以参照这片官方的aws china的文档的前半部分创建集群了：文档忽略掉Image部分就好了。
最后附上完整的配置文件(要修改里面的一些地方，改成你自己的)：
https://gist.github.com/leeeboo/abf83d811617d21bb5425737dd0df006
网友评论