For Auto Upgrade Kubernetes Version
-
Các thành phần yêu cầu
- Docker
- kind
- kubectl
- clusterctl
-
capi-cluster.yaml
kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 networking: ipFamily: dual nodes: - role: control-plane extraMounts: - hostPath: /var/run/docker.sock containerPath: /var/run/docker.sock
-
Chạy lệnh tạo cụm kind
kind create cluster --config capi-cluster.yaml
-
Khởi tạo management cluster
# Enable the experimental Cluster topology feature. export CLUSTER_TOPOLOGY=true # Initialize the management cluster clusterctl init --infrastructure docker
-
Cài đặt ArgoCD:
kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
Bên trên là các bước chuẩn bị cho việc thử nghiệm, bây giờ chúng ta sẽ bắt đầu thử nghiệm. Trước khi thử nghiệm ta cần hiểu được
cluster-api
sẽ upgrade version một cụm kubernetes như thế nào. Cụ thể là nó sẽ tạo ra một cụm kubernetes mới với version mới và sau đó sẽ migrate dữ liệu từ cụm cũ sang cụm mới. Vậy nên để thử nghiệm chúng ta sẽ tạo ra một cụm kubernetes với version cũ và sau đó thử nghiệm upgrade version của nó.
Kỹ thuật nâng cấp truyền thống, được gọi là
inline upgrade
, bao gồm việc nâng cấp các thành phần Kubernetes tại chỗ. Cách tiếp cận này có một số rủi ro, trong đó có nhiều rủi ro dẫn đến việc nâng cấp không thành công trên một node, đòi hỏi phải chuyển các pods và apps sang các node khác một cách bất ngờ. Nếu các node khác cũng ở trong tình trạng tương tự, một loạt các lỗi nâng cấp có thể khiến một cụm bị sập. Nếu lỗi nâng cấp liên quan đến một loạt bản vá lỗi và cấu hình thủ công đã được áp dụng theo thời gian, thì có thể rất khó để khắc phục sự cố và đưa nó trở lại trạng thái tốt.
Cluster API giúp nâng cấp an toàn hơn và giảm tác động của chúng đến dung lượng cụm. Cluster API thực hiện nâng cấp luân phiên, bao gồm việc cung cấp lần lượt các node mới, được nâng cấp và di chuyển các pods từ các node cũ hơn đến chúng. Cách tiếp cận này giúp duy trì nhiều dung lượng cụm nhất có thể trong quá trình nâng cấp. Trong trường hợp xấu nhất, khi node mới không được cung cấp và thêm thành công, thì workload đang chạy sẽ không bị ảnh hưởng vì các pods chỉ được di chuyển khi node mới tham gia cụm.
Bằng cách giúp việc nâng cấp cụm Kubernetes trở nên dễ dàng và an toàn hơn, Cluster API khuyến khích cập nhật thường xuyên hơn. Điều này giúp Kubernetes luôn cập nhật và an toàn hơn, đồng thời giảm nguy cơ sai lệch cấu hình, trong đó trạng thái thực của cụm khác với trạng thái mong muốn được hệ thống hóa trong bản blueprint/manifest, do các thay đổi được thực hiện trực tiếp trên cụm.
-
Tạo cụm capi-quickstart manual với version 1.26.0:
clusterctl -n capi-quickstart generate cluster capi-quickstart --flavor development \ --kubernetes-version v1.26.0 \ --control-plane-machine-count=1 \ --worker-machine-count=1 \ > capi-quickstart.yaml kubectl apply -f capi-quickstart.yaml clusterctl -n capi-quickstart get kubeconfig capi-quickstart > capi-quickstart.kubeconfig curl https://raw.githubusercontent.com/projectcalico/calico/v3.26.3/manifests/calico.yaml -O kubectl --kubeconfig=capi-quickstart.kubeconfig apply -f calico.yaml
[136ms][~/Desktop/sprint/upgrade-k8s-version]$ clusterctl describe cluster capi-quickstart -n capi-quickstart NAME READY SEVERITY REASON SINCE MESSAGE Cluster/capi-quickstart True 3m45s ├─ClusterInfrastructure - DockerCluster/capi-quickstart-4hnhh True 4m23s ├─ControlPlane - KubeadmControlPlane/capi-quickstart-56sjp True 3m45s │ └─Machine/capi-quickstart-56sjp-vw7nc True 3m45s └─Workers └─MachineDeployment/capi-quickstart-md-0-jjpfw True 85s └─Machine/capi-quickstart-md-0-jjpfw-pknr9-c9pnc True 3m9s
-
Kiểm tra version của cụm kubernetes:
[128ms][~/Desktop/sprint/upgrade-k8s-version]$ k --kubeconfig=capi-quickstart.kubeconfig get nodes NAME STATUS ROLES AGE VERSION capi-quickstart-56sjp-vw7nc Ready control-plane 6m19s v1.26.0 capi-quickstart-md-0-jjpfw-pknr9-c9pnc Ready <none> 5m42s v1.26.0
-
Deploy demo app nginx
kubectl --kubeconfig=capi-quickstart.kubeconfig apply -f clusterapi-gitops/workload
-
Lấy file
MachineTemplate
củacontrol-plane
:[88ms][~/Desktop/sprint/upgrade-k8s-version]$ k -n capi-quickstart get dockermachinetemplate capi-quickstart-control-plane-mr5sc -o yaml apiVersion: infrastructure.cluster.x-k8s.io/v1beta1 kind: DockerMachineTemplate metadata: annotations: cluster.x-k8s.io/cloned-from-groupkind: DockerMachineTemplate.infrastructure.cluster.x-k8s.io cluster.x-k8s.io/cloned-from-name: quick-start-control-plane creationTimestamp: "2023-10-19T18:29:41Z" generation: 1 labels: cluster.x-k8s.io/cluster-name: capi-quickstart topology.cluster.x-k8s.io/owned: "" name: capi-quickstart-control-plane-mr5sc namespace: capi-quickstart ownerReferences: - apiVersion: cluster.x-k8s.io/v1beta1 kind: Cluster name: capi-quickstart uid: 38d363c9-e667-4bc4-bb6b-29985e26f0ad resourceVersion: "20086" uid: a5161b1f-6571-4059-ac81-0cd2dd6e5417 spec: template: spec: customImage: kindest/node:v1.26.0 extraMounts: - containerPath: /var/run/docker.sock hostPath: /var/run/docker.sock
Ta sẽ lưu lại và sửa lại file này để tạo ra một
MachineTemplate
mới với version mới hơn.1.26.0
->1.26.10
-
Tạo 1 MachineTemplate mới với version mới hơn:
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1 kind: DockerMachineTemplate metadata: annotations: cluster.x-k8s.io/cloned-from-groupkind: DockerMachineTemplate.infrastructure.cluster.x-k8s.io cluster.x-k8s.io/cloned-from-name: quick-start-control-plane creationTimestamp: "2023-10-19T18:29:41Z" generation: 1 labels: cluster.x-k8s.io/cluster-name: capi-quickstart topology.cluster.x-k8s.io/owned: "" name: capi-quickstart-control-plane-v1.26.6 namespace: capi-quickstart ownerReferences: - apiVersion: cluster.x-k8s.io/v1beta1 kind: Cluster name: capi-quickstart uid: 38d363c9-e667-4bc4-bb6b-29985e26f0ad resourceVersion: "20086" uid: a5161b1f-6571-4059-ac81-0cd2dd6e5417 spec: template: spec: customImage: kindest/node:v1.26.6 extraMounts: - containerPath: /var/run/docker.sock hostPath: /var/run/docker.sock
kubectl apply -f control-plane-template.yaml
-
Lấy ra
KubeadmControlPlane
của cụm capi-quickstart và sửa đổi thành phiên bản mới hơn vàMachineTemplate
mới tạo ở trên:[63ms][~/Desktop/sprint/upgrade-k8s-version]$ kubectl -n capi-quickstart get kubeadmcontrolplane capi-quickstart-56sjp -o yaml > kubeadm-control-plane-update.yaml
machineTemplate: infrastructureRef: apiVersion: infrastructure.cluster.x-k8s.io/v1beta1 kind: DockerMachineTemplate name: capi-quickstart-control-plane-v1.26.6 namespace: capi-quickstart rolloutStrategy: rollingUpdate: maxSurge: 1 type: RollingUpdate version: v1.26.6 ... selector: cluster.x-k8s.io/cluster-name=capi-quickstart,cluster.x-k8s.io/control-plane unavailableReplicas: 0 updatedReplicas: 1 version: v1.26.6
-
Apply lại
KubeadmControlPlane
mới:kubectl -n capi-quickstart patch --type=merge kubeadmcontrolplane capi-quickstart-56sjp --type merge --patch-file kubeadm-control-plane-update.yaml
-
Kiểm tra trạng thái của cụm kubernetes:
[0.115s][master][~/Desktop/sprint/upgrade-k8s-version/clusterapi-gitops]$ clusterctl describe cluster capi-quickstart -n capi-quickstart NAME READY SEVERITY REASON SINCE MESSAGE Cluster/capi-quickstart False Warning RollingUpdateInProgress 6s Rolling 1 replicas with outdated spec (1 replicas up to date) ├─ClusterInfrastructure - DockerCluster/capi-quickstart-f2wrr True 10m ├─ControlPlane - KubeadmControlPlane/capi-quickstart-n4rtj False Warning RollingUpdateInProgress 6s Rolling 1 replicas with outdated spec (1 replicas up to date) │ ├─Machine/capi-quickstart-n4rtj-jmr9g True 10m │ └─Machine/capi-quickstart-n4rtj-m6g2f False Info WaitingForBootstrapData 8s 1 of 2 completed └─Workers └─MachineDeployment/capi-quickstart-md-0-l5z9b True 8m53s └─Machine/capi-quickstart-md-0-l5z9b-p7hvd-rvp2c True 9m37s
-
Kiếm tra Machine (ở đây là giả lập container) ta thấy đã tạo ra một container control-plane mới:
[40ms][master][~/Desktop/sprint/upgrade-k8s-version/clusterapi-gitops]$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES fcbf443a183c kindest/node:v1.26.6 "/usr/local/bin/entr…" 19 seconds ago Up 11 seconds 0/tcp, 127.0.0.1:32772->6443/tcp capi-quickstart-n4rtj-m6g2f 513e013a5cfa kindest/node:v1.26.0 "/usr/local/bin/entr…" 9 minutes ago Up 9 minutes capi-quickstart-md-0-l5z9b-p7hvd-rvp2c b22f67405369 kindest/node:v1.26.0 "/usr/local/bin/entr…" 10 minutes ago Up 10 minutes 0/tcp, 127.0.0.1:32771->6443/tcp capi-quickstart-n4rtj-jmr9g 21f147f1e106 kindest/haproxy:v20230510-486859a6 "haproxy -W -db -f /…" 10 minutes ago Up 10 minutes 0/tcp, 0.0.0.0:32768->6443/tcp capi-quickstart-lb 59231b74a366 kindest/node:v1.27.1 "/usr/local/bin/entr…" 29 minutes ago Up 29 minutes 127.0.0.1:33867->6443/tcp kind-control-plane
Check các nodes của cụm:
[0.158s][master][~/Desktop/sprint/upgrade-k8s-version/clusterapi-gitops]$ k --kubeconfig=capi-quickstart.kubeconfig get nodes NAME STATUS ROLES AGE VERSION capi-quickstart-md-0-l5z9b-p7hvd-rvp2c Ready <none> 11m v1.26.0 capi-quickstart-n4rtj-jmr9g Ready control-plane 11m v1.26.0 capi-quickstart-n4rtj-m6g2f NotReady control-plane 93s v1.26.6
-
Sau khi upgrade xong:
[1.018s][master][~/Desktop/sprint/upgrade-k8s-version/clusterapi-gitops]$ clusterctl describe cluster capi-quickstart -n capi-quickstart NAME READY SEVERITY REASON SINCE MESSAGE Cluster/capi-quickstart True 9s ├─ClusterInfrastructure - DockerCluster/capi-quickstart-f2wrr True 17m ├─ControlPlane - KubeadmControlPlane/capi-quickstart-n4rtj True 9s │ └─Machine/capi-quickstart-n4rtj-g4t7z True 2m27s └─Workers └─MachineDeployment/capi-quickstart-md-0-l5z9b True 3m40s └─Machine/capi-quickstart-md-0-l5z9b-p7hvd-rvp2c True 15m [121ms][master][~/Desktop/sprint/upgrade-k8s-version/clusterapi-gitops]$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 7b3efefdaa71 kindest/node:v1.26.0 "/usr/local/bin/entr…" 4 minutes ago Up 4 minutes 0/tcp, 127.0.0.1:32773->6443/tcp capi-quickstart-n4rtj-g4t7z 513e013a5cfa kindest/node:v1.26.0 "/usr/local/bin/entr…" 16 minutes ago Up 16 minutes capi-quickstart-md-0-l5z9b-p7hvd-rvp2c 21f147f1e106 kindest/haproxy:v20230510-486859a6 "haproxy -W -db -f /…" 17 minutes ago Up 17 minutes 0/tcp, 0.0.0.0:32768->6443/tcp capi-quickstart-lb 59231b74a366 kindest/node:v1.27.1 "/usr/local/bin/entr…" 36 minutes ago Up 36 minutes 127.0.0.1:33867->6443/tcp kind-control-plane
Upgrade Cluster: những điều sẽ xảy ra khi Google tự động nâng cấp cụm của hoặc khi nâng cấp thủ công.
- Zonal clusters chỉ có một
control-plane
duy nhất. Trong quá trình nâng cấp, khối lượng công việc của bạn tiếp tục chạy nhưng bạn không thể triển khai khối lượng công việc mới, sửa đổi khối lượng công việc hiện có hoặc thực hiện các thay đổi khác đối với cấu hình của cụm cho đến khi quá trình nâng cấp hoàn tất. - Regional clusters có nhiều bản sao của
control-plane
và mỗi lần chỉ có một bản sao được nâng cấp theo thứ tự không xác định. Trong quá trình nâng cấp, cụm vẫn có tính khả dụng cao và mỗi bản saocontrol-plane
chỉ không khả dụng khi nó đang được nâng cấp.
-
Quá trình khi Google tự động nâng cấp node hoặc khi nâng cấp nhóm node thủ công.
- Với nâng cấp node pool GKE, ta có thể chọn giữa hai cách nâng cấp tích hợp, có thể định cấu hình, trong đó có thể điều chỉnh quy trình nâng cấp dựa trên nhu cầu của môi trường cụm của mình. Để tìm hiểu thêm về chiến lược nâng cấp
surge
vàblue-green
, hãy xem - Trong quá trình nâng cấp node pool, không thể thay đổi cấu hình cụm trừ khi hủy nâng cấp.
- Với nâng cấp node pool GKE, ta có thể chọn giữa hai cách nâng cấp tích hợp, có thể định cấu hình, trong đó có thể điều chỉnh quy trình nâng cấp dựa trên nhu cầu của môi trường cụm của mình. Để tìm hiểu thêm về chiến lược nâng cấp
-
Trong quá trình nâng cấp node pool, cách nâng cấp các node tùy thuộc vào option và cách bạn định cấu hình nó. Tuy nhiên, các bước cơ bản vẫn giữ nguyên. Để nâng cấp một node, GKE sẽ xóa Pod khỏi node đó để có thể nâng cấp node đó.
-
Khi một node được nâng cấp, điều sau đây sẽ xảy ra với Pod:
- Node được
cordoned
để Kubernetes không lên lịch cho các Pod mới trên đó. - Nút sau đó sẽ bị
drained
, nghĩa là các Pod sẽ bị loại bỏ. Đối với các bản nâng cấpsurge
, GKE tôn trọng cài đặtPodDisruptionBudget
vàGracefulTerminationPeriod
của Pod trong tối đa một giờ. Với các nâng cấpblue-green
, thời gian này có thể được kéo dài nếu định cấu hình thời gian lâu hơn. - Control-plane sắp xếp lại các Pod do bộ điều khiển quản lý lên các nút khác. Các Pods không thể lên lịch lại sẽ ở trong giai đoạn
Pending
cho đến khi chúng có thể được lên lịch lại. Quá trình nâng cấp node pool có thể mất tới vài giờ tùy thuộc vào cách nâng cấp, số lượng nút và cấu hình khối lượng công việc của chúng.
- Node được
-
- Theo mặc định, Surge upgrades được sử dụng để nâng cấp node pool. Nó sử dụng phương pháp cuộn để nâng cấp các nút. Cách này phù hợp nhất cho các ứng dụng có thể xử lý các thay đổi gia tăng, không gây gián đoạn. Với cách này, các nút được nâng cấp trong một cửa sổ cuộn. Với cách này có thể thay đổi số lượng nút có thể được nâng cấp cùng một lúc và mức độ gián đoạn của việc nâng cấp, tìm ra sự cân bằng tối ưu giữa tốc độ và sự gián đoạn cho nhu cầu của môi trường.
-
- Cách tiếp cận thay thế là nâng cấp blue-green, trong đó hai bộ môi trường (môi trường cũ và mới) được duy trì cùng một lúc, giúp việc khôi phục trở nên dễ dàng nhất có thể. Blue-green tiêu tốn nhiều tài nguyên hơn và tốt hơn cho các ứng dụng nhạy cảm hơn với các thay đổi. Với cách này, khối lượng công việc được di chuyển dần dần từ môi trường "blue" ban đầu sang môi trường "green" mới và có thời gian chuẩn bị để xác thực chúng bằng cấu hình mới. Nếu cần, khối lượng công việc có thể nhanh chóng được khôi phục về môi trường "blue" hiện có.
- kube-apiserver unhealthy after control plane upgrade
Upgrade Azure Cluster:
các node AKS được cordoned
và drained
cẩn thận để giảm thiểu mọi gián đoạn có thể xảy ra đối với các ứng dụng đang chạy. Trong quá trình này, AKS thực hiện các bước sau:
- Thêm một node đệm mới (hoặc nhiều node được định cấu hình ở max surge) vào cụm chạy phiên bản Kubernetes được chỉ định.
- Cordons và drains một trong các nút cũ để giảm thiểu sự gián đoạn đối với các ứng dụng đang chạy. Nếu đang sử dụng mức tăng tối đa (max surge), nó sẽ khoanh vùng và tiêu hao nhiều nút cùng lúc với số lượng nút đệm được chỉ định.
- Quá trình này lặp lại cho đến khi tất cả các nút trong cụm được nâng cấp.
- Khi kết thúc quá trình, nút đệm cuối cùng sẽ bị xóa, duy trì số lượng nút tác nhân hiện có và cân bằng vùng.
Cách này tương tự như cách Surge upgrades node pool của Google Cloud.
Nếu nâng cấp kubeadm không thành công và không roll back, chẳng hạn như do tắt đột ngột trong khi thực thi, ta có thể chạy lại nâng cấp kubeadm. Để khôi phục, có thể chạy áp dụng nâng cấp kubeadm --force mà không cần thay đổi phiên bản mà cụm đang chạy.
Trong quá trình upgrade kubeadm sẽ ghi bản backup vào /etc/kubernetes/tmp
:
kubeadm-backup-etcd-<date>-<time>
kubeadm-backup-manifests-<date>-<time>
kubeadm-backup-etcd
chứa bản sao lưu dữ liệu etcd local cho control-plane đó. Trong trường hợp nâng cấp etcd không thành công và nếu tính năng khôi phục tự động không hoạt động, có thể được khôi phục thủ công trong /var/lib/etcd
.
kubeadm-backup-manifests
chứa bản sao lưu của tệp kê khai Pod tĩnh cho nút control-plane. Trong trường hợp nâng cấp không thành công và nếu tính năng khôi phục tự động không hoạt động, có thể được khôi phục thủ công trong /etc/kubernetes/manifests
.