确认 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控制台上可以进行版本升级。

スクリーンショット 2023-09-13 12.37.28.png

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

スクリーンショット 2023-09-13 12.39.28.png

更新版本

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

スクリーンショット 2023-09-13 12.40.00.png

操作就是这个。

当执行控制平面的版本升级时,控制平面会升级节点池和节点的版本。

在升级过程中会出现这样的画面。

スクリーンショット 2023-09-13 12.40.37.png

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

スクリーンショット 2023-09-13 13.01.19.png

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

スクリーンショット 2023-09-13 15.29.51.png

升级版本时的操作

我确认了升级版本时的集群状态。

节点 (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>
bannerAds