Kubernetes 从1.10到1.11升级记录
文章目录
【注意】最后更新于 October 3, 2018,文中内容可能已过时,请谨慎使用。
Kubernetes 1.12已经发布。我们线上的版本升级都是按照比官方低一个版本的节奏。 因此可以开始考虑将团队线上环境的Kubernetes集群从1.10升级到1.11了。 本文记录了在测试环境中的演练过程。
1.准备
当前Kubernetes 1.11的小版本是1.11.3。 在升级之前一定要多读几遍官方的升级须知Kubernetes 1.11 - Action Required Before Upgrading。
其中针对我们对Kubernetes的使用情况,有几个需要我们注意的地方:
- 基于IPVS的负载均衡进入GA,当不满足IPVS的条件时,kube-proxy会使用iptables Proxier。(本次升级演练将不开启IPVS。)
- 可使用CoreDNS作为Kubernetes的DNS插件进入GA。(本次升级演练将不做从kube-dns到CoreDNS的切换)
- heapster已经废弃,推荐使用metrics-server
Kubernetes 1.11所需的外部依赖和一些组件的版本:
- etcd 3.2.18
- 以下docker版本在Kubernetes 1.11(和Kubernetes 1.10一样)上进行过验证:docker 1.11.2, 1.13.1, 17.03.x (支持的最小docker版本是1.11.2)
- CNI 0.6.0和Kubernetes 1.10依赖的版本相同
- CSI 0.3.0
- dashboard 1.8.3
- kube-dns 1.14.10
- flannel 0.10.0
- kube-state-metrics 1.4.0
- metrics-server 0.3.1
2.使用ansible升级Kubernetes
2.1 master节点
我们的集群有3个master节点,在使用ansible升级master节点(kube-apiserver
, kube-scheduler
, kube-controller-manager
)时,通过修改ansible role的inventory文件,只先升级第一个master节点,当测试没有问题后再升级剩余两个master节点。
master节点升级完成后,kube-controller-manager
启动后出现访问API Server权限问题:
|
|
应该是新版本需要system:kube-controller-manager
这个ClusterRole需要更多的权限,因为这个ClusterRole是系统默认的。
所以这里怀疑某处除了问题,Annotations: rbac.authorization.kubernetes.io/autoupdate=true
表明每次重启API Server时是可以被Auto-reconciliation
,详见这里Default Roles and Role Bindings Auto-reconciliation。
所以尝试删掉它,重启apiserver让其重新创建新的,之后重启kube-controller-manager问题解决。
|
|
2.2 node节点
同样也是先选择一个node节点升级做测试,如果这个节点上有业务Pod正在运行,可以先将这个节点排干(drain),将业务容器转移到其他的node节点上。 测试环境中的升级十分顺利,各个核心组件成功升级到了1.11.3。
注意提前准备–pod-infra-container-image到k8s.gcr.io/pause:3.1
从kube-proxy的启动日志来看,因为本次演练没有开启ipvs proxyier,所以还是使用的iptables Proxier。
|
|
3.其他组件
3.1 移除Heapster
heapster已经废弃,需要将heapster及其相关内容从Kubernetes集群中移除:
|
|
3.2 部署metrics-server
heapster已经废弃,推荐使用metrics-server。 metrics-server的部署可以使用helm,官方的chart在这里;也可以参考和定制官方给的yaml deploy metrics-server
文章作者 青蛙小白
上次更新 2018-10-03