kubernetes v1.13.1的容器集群版本升级至v1.14.0的技术实施方案

本文中的容器集群是基于CentOS7系统所搭建，采用的是二进制安装包的部署方式。

新旧版本的功能差异

了解一些版本间功能迭代变化，避免让自己入坑。
1）默认RBAC策略不再授予对未经身份验证的用户的发现和权限检查API（由kubectl auth can -i使用）的访问权限。 升级的群集保留了先前的行为，但希望在新群集中授予未经身份验证的用户访问权限的集群管理员需要明确选择公开发现和/或权限检查API：

kubectl create clusterrolebinding anonymous-discovery --clusterrole=system:discovery --group=system:unauthenticated
kubectl create clusterrolebinding anonymous-access-review --clusterrole=system:basic-user --group=system:unauthenticated

2）不再支持或调整已弃用的taints node.alpha.kubernetes.io/notReady和node.alpha.kubernetes.io/unreachable。 应使用node.kubernetes.io/not-ready和node.kubernetes.io/unreachable替换这些用法。

3）API变化

• 在Kubernetes v1.7 新增的 Initializers，可以用来方便地扩展准入控制，而在v1.14版本中移除了"Initializer"这一准入控制插件。请检查下你的kube-apiserver启动参数中是否有引用该插件，并及时清除掉，否则服务会启动失败。
• Ingress资源现在可通过networking.k8s.io/v1beta1'获得。Extension/v1beta1中的Ingress资源已弃用，将不再在v1.18中提供。 现有的持久数据可通过新的API组/版本获得
• v1.16中的extensions/v1beta1将不再提供NetworkPolicy资源。 将使用迁移到从v1.8开始提供的networking.k8s.io/v1 API。 可以通过networking.k8s.io/v1 API检索现有的持久数据。
• 将不再从v1.16中的extensions/v1beta1提供PodSecurityPolicy资源。 迁移到自v1.10起可用的policy/v1beta1 API。 可以通过policy/v1beta1API检索现有的持久数据。
• 将不再从v1.16中的extensions/v1beta1，apps/v1beta1或apps/v1beta2提供DaemonSet，Deployment和ReplicaSet资源。 迁移到自v1.9起可用的apps/v1 API。 可以通过apps/v1 API检索现有的持久数据。

3）以下功能现在是GA，相关的feature gates已弃用，将在v1.15中删除：

• CustomPodDNS
• HugePages
• MountPropagation
• PersistentLocalVolumes

Kubernetes零宕机时间升级建议

• 所谓平滑升级只是个理想，前提是需要你部署在容器云平台上的各种容器应用自己足够强壮。
• 在升级node节点程序版本时，本机上运行的Pods都会被restart。

资源准备

• 备份kubernetes原先的二进制文件和配置文件。
• 下载最新版本的kubernetes二进制包，如1.14.0版本，查看changelog，下载二进制包，我们使用的是kubernetes-server-linux-amd64.tar.gz，分发到集群的每个节点上。

升级操作思路：

• 在我们的项目中k8s执行文件部署在/opt/k8s/bin下面，docker执行文件，网络组件Calico执行文件等都是部署在/opt/k8s/bin目录下；
• 为了便于管理版本升级和回退，我们在每个主机上将该bin目录复制一份并重命名为bin-1.14.0；
• 将原bin目录重命名为bin-1.13.1，以便于遇到问题时回退；
• 从v1.14.0版本kubernetes/server/bin目录下将所有文件复制到/opt/k8s/bin-1.14.0目录中，覆盖掉旧版本文件；
• 在/opt/k8s下创建一个符号链接bin，指向系统中当前要使用的程序版本的bin目录。
• 建议先升级master，再升级node。如果master和node部署在同一个主机节点上了，则一同关闭、替换和升级。

升级Master节点

因为我们有多个Master节点，逐个的进行升级。

停止master节点的进程

systemctl stop keepalived   # 先停掉本机keepalived，切走高可用VIP地址
systemctl stop kube-apiserver
systemctl stop kube-scheduler
systemctl stop kube-controller-manager
systemctl stop kube-proxy
systemctl stop kubelet

• 因为我们的master节点同时也作为node节点，所有还要执行升级node节点“中的步骤。

使用新版本的kubernetes二进制文件替换原来老版本的文件

即将/opt/k8s/bin符号链接指向新版本的/opt/k8s/bin-1.14.0 。
例如：

cd  /opt/k8s
cp  -r  bin  bin-1.14.0
mv  bin  bin-1.13.1
ln  -s  bin-1.14.0  bin
cd  /home/k8s
tar  zxvf kubernetes-server-linux-amd64.tar.gz
cp  kubernetes/server/bin/*  /opt/k8s/bin-1.14.0

启动master节点上的进程

systemctl start kube-apiserver
systemctl start kube-scheduler
systemctl start kube-controller-manager

启动节点上的kubernetes node进程：

systemctl start kubelet
systemctl start kube-proxy
systemctl start keepalived   #如果你部署了Master的多节点高可用，则启动keepalived

• 在我们的项目中master和node服务进程共用了相同的主机节点。

对于生产集群环境部署，不会出现Master和Node节点共用一个主机资源的情况，此时建议先升级Master节点版本，检查服务无误后再继续依次升级Node节点。

检查集群服务

systemctl status kube-apiserver
systemctl status kube-scheduler
systemctl status kube-controller-manager
systemctl status kubelet
systemctl status kube-proxy
kubectl get nodes
kubectl cluster-info
kubectl get componentstatuses
kubectl get all --all-namespaces

依次升级环境中其他主机节点

大体上按先Master节点，后Node节点的顺序。

以上版本升级技术方案，操作有风险，如果某个操作导致了k8s其他重要组件全局范围内的故障事件了，请先以先行恢复该组件服务为优先，必要的话及时回退，以避免故障事件影响范围的扩大化。