确认 OKE Virtual Nodes 集群升级步骤
首先
我们将确认使用Serverless的Virtual Nodes作为OKE的Worker Node时的集群版本升级步骤。
我在两个虚拟节点上配置了一个集群。
$ k get node
NAME STATUS ROLES AGE VERSION
10.0.1.150 Ready virtual-node 67m v1.26.2
10.0.1.191 Ready virtual-node 67m v1.26.2
我们正在使用 Deployment 将一个 Pod 部署到每个节点上。
$ k get pod -o wide -w
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-748c667d99-ccx7q 1/1 Running 0 3m11s 10.0.5.198 10.0.1.150 <none> <none>
nginx-748c667d99-jnr4z 1/1 Running 0 3m11s 10.0.5.2 10.0.1.191 <none> <none>
确认是否可以进行版本升级
我将确保在OCI控制台上可以进行版本升级。

同样,节点池中也有一个感叹号标记。

更新版本
点击“可使用Kubernetes控制台的新版本”后,将会进入以下界面,选择要升级的版本,然后点击“升级”。

操作就是这个。
当执行控制平面的版本升级时,控制平面会升级节点池和节点的版本。
在升级过程中会出现这样的画面。

升级完成后,图标会恢复为绿色。

节点池已经进行了版本升级。

升级版本时的操作
我确认了升级版本时的集群状态。
节点 (Nuò
在以前的Managed Node中,我们通过添加新版本的节点并删除旧版本的节点来更新节点。而在Virtual Node中,似乎是对该节点进行版本升级而保留节点不变。
$ k get node -w
NAME STATUS ROLES AGE VERSION
10.0.1.150 Ready virtual-node 72m v1.26.2
10.0.1.191 Ready virtual-node 72m v1.26.2
10.0.1.150 Ready virtual-node 73m v1.26.2
10.0.1.191 Ready virtual-node 73m v1.27.2
10.0.1.191 Ready virtual-node 73m v1.27.2
10.0.1.150 Ready virtual-node 74m v1.27.2
10.0.1.150 Ready virtual-node 74m v1.27.2
10.0.1.191 Ready virtual-node 74m v1.27.2
(虚拟)kubelet的版本也在升级。
$ k describe node 10.0.1.150 |grep "Kubelet Version"
Kubelet Version: v1.27.2
另外,状态始终是Ready,但我尝试了几次后,有时会变成NotReady。
由于NotReady的时间很短,可能导致无法通过命令捕捉的情况。
$ k get node -w
NAME STATUS ROLES AGE VERSION
10.0.1.205 Ready virtual-node 13m v1.26.2
10.0.1.220 Ready virtual-node 14m v1.26.2
10.0.1.220 Ready virtual-node 14m v1.26.2
10.0.1.205 NotReady virtual-node 14m v1.26.2
10.0.1.220 Ready virtual-node 15m v1.26.7
10.0.1.205 NotReady virtual-node 14m v1.26.7
10.0.1.205 Ready virtual-node 14m v1.26.7
10.0.1.220 Ready virtual-node 15m v1.26.7
10.0.1.205 Ready virtual-node 17m v1.26.7
10.0.1.220 Ready virtual-node 18m v1.26.7
播客
虽然理解很困难,但是Pod已经下线并在同一节点上重新创建。
虽然不是同时存在两个Pod,但是第一个Pod正在重新创建的过程中,第二个Pod似乎已经处于终止状态。
尽管尚未进行外部连接的确认,但是与传统节点相比,虚拟节点的Pod启动较慢。因此,为了确保业务不中断,最好在升级版本之前调整节点数和副本数量,并进行事前确认。
我看到了升级版本时的动作,作为一个集群,我们是通过滚动升级进行版本升级的,但似乎没有考虑到Pod。
$ k get pod -o wide -w
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-748c667d99-427vj 1/1 Running 0 8m39s 10.0.4.48 10.0.1.220 <none> <none>
nginx-748c667d99-h2nsd 1/1 Running 0 8m39s 10.0.4.159 10.0.1.205 <none> <none>
nginx-748c667d99-h2nsd 1/1 Running 0 12m 10.0.4.159 10.0.1.205 <none> <none>
nginx-748c667d99-427vj 1/1 Running 0 12m 10.0.4.48 10.0.1.220 <none> <none>
nginx-748c667d99-427vj 1/1 Terminating 0 12m 10.0.4.48 10.0.1.220 <none> <none>
nginx-748c667d99-xns85 0/1 Pending 0 0s <none> <none> <none> <none>
nginx-748c667d99-xns85 0/1 ContainerCreating 0 0s <none> 10.0.1.220 <none> <none>
nginx-748c667d99-h2nsd 1/1 Running 0 12m 10.0.4.159 10.0.1.205 <none> <none>
nginx-748c667d99-h2nsd 1/1 Terminating 0 12m 10.0.4.159 10.0.1.205 <none> <none>
nginx-748c667d99-7vq9v 0/1 Pending 0 0s <none> <none> <none> <none>
nginx-748c667d99-h2nsd 1/1 Terminating 0 12m 10.0.4.159 10.0.1.205 <none> <none>
nginx-748c667d99-7vq9v 0/1 Pending 0 0s <none> 10.0.1.205 <none> <none>
nginx-748c667d99-h2nsd 1/1 Terminating 0 12m 10.0.4.159 10.0.1.205 <none> <none>
nginx-748c667d99-7vq9v 0/1 ContainerCreating 0 0s <none> 10.0.1.205 <none> <none>
nginx-748c667d99-h2nsd 0/1 Terminating 0 12m 10.0.4.159 10.0.1.205 <none> <none>
nginx-748c667d99-xns85 0/1 ContainerCreating 0 1s <none> 10.0.1.220 <none> <none>
nginx-748c667d99-7vq9v 0/1 ContainerCreating 0 2s <none> 10.0.1.205 <none> <none>
nginx-748c667d99-xns85 0/1 ContainerCreating 0 2m19s <none> 10.0.1.220 <none> <none>
nginx-748c667d99-7vq9v 0/1 ContainerCreating 0 2m22s <none> 10.0.1.205 <none> <none>
nginx-748c667d99-xns85 1/1 Pending 0 2m34s <none> 10.0.1.220 <none> <none>
nginx-748c667d99-7vq9v 1/1 Pending 0 2m41s <none> 10.0.1.205 <none> <none>
nginx-748c667d99-7vq9v 1/1 Running 0 2m41s 10.0.5.168 10.0.1.205 <none> <none>
nginx-748c667d99-xns85 1/1 Pending 0 2m49s <none> 10.0.1.220 <none> <none>
nginx-748c667d99-xns85 1/1 Running 0 2m51s 10.0.5.101 10.0.1.220 <none> <none>