Pag-upgrade ng Kubernetes cluster nang walang downtime

Proseso ng pag-upgrade para sa iyong Kubernetes cluster

Sa ilang mga punto, kapag gumagamit ng isang Kubernetes cluster, mayroong pangangailangan na i-update ang mga tumatakbong node. Maaaring kabilang dito ang mga update sa package, mga update sa kernel, o pag-deploy ng mga bagong imahe ng virtual machine. Sa terminolohiya ng Kubernetes ito ay tinatawag "Boluntaryong Pagkagambala".

Ang post na ito ay bahagi ng isang 4-post na serye:

1. Itong poste.
2. Tamang pag-shutdown ng mga pod sa isang Kubernetes cluster
3. Naantala ang pagkumpleto ng isang pod kapag na-delete ito
4. Paano Iwasan ang Kubernetes Cluster Downtime Gamit ang PodDisruptionBudgets

(tinatayang. Asahan ang mga pagsasalin ng natitirang mga artikulo sa serye sa malapit na hinaharap)

Sa artikulong ito, ilalarawan namin ang lahat ng tool na ibinibigay ng Kubernetes para makamit ang zero downtime para sa mga node na tumatakbo sa iyong cluster.

Pagtukoy sa problema

Magsasagawa kami ng isang walang muwang na diskarte sa una, tutukuyin ang mga problema at tasahin ang mga potensyal na panganib ng diskarteng ito, at bubuo ng kaalaman upang malutas ang bawat problemang nararanasan namin sa buong cycle. Ang resulta ay isang configuration na gumagamit ng mga lifecycle hook, ready probe, at Pod disruption budget para makamit ang aming zero downtime na layunin.

Upang simulan ang ating paglalakbay, kumuha tayo ng isang kongkretong halimbawa. Sabihin nating mayroon tayong Kubernetes cluster ng dalawang node, kung saan tumatakbo ang isang application na may dalawang pod na matatagpuan sa likod Service:

Magsimula tayo sa dalawang pod na may Nginx at Serbisyo na tumatakbo sa aming dalawang Kubernetes cluster node.

Gusto naming i-update ang kernel na bersyon ng dalawang worker node sa aming cluster. Paano natin ito gagawin? Ang isang simpleng solusyon ay ang pag-boot ng mga bagong node na may na-update na configuration at pagkatapos ay isara ang mga lumang node habang sinisimulan ang mga bago. Bagama't gagana ito, magkakaroon ng ilang problema sa diskarteng ito:

• Kapag na-off mo ang mga lumang node, ang mga pod na tumatakbo sa mga ito ay i-o-off din. Paano kung kailangang i-clear ang mga pod para sa magandang pagsasara? Ang virtualization system na iyong ginagamit ay maaaring hindi maghintay para sa proseso ng paglilinis upang makumpleto.
• Paano kung sabay mong i-off ang lahat ng node? Makakakuha ka ng disenteng downtime habang lumilipat ang mga pod sa mga bagong node.

Kailangan namin ng paraan para maganda ang paglipat ng mga pod mula sa mga lumang node habang tinitiyak na wala sa aming mga proseso ng manggagawa ang tumatakbo habang gumagawa kami ng mga pagbabago sa node. O kapag gumawa kami ng kumpletong pagpapalit ng cluster, tulad ng sa halimbawa (iyon ay, pinapalitan namin ang mga imahe ng VM), gusto naming ilipat ang mga tumatakbong application mula sa mga lumang node patungo sa mga bago. Sa parehong mga kaso, gusto naming pigilan ang mga bagong pod na mai-iskedyul sa mga lumang node, at pagkatapos ay paalisin ang lahat ng tumatakbong pod mula sa kanila. Upang makamit ang mga layuning ito maaari nating gamitin ang utos kubectl drain.

Muling pamamahagi ng lahat ng pod mula sa isang node

Ang pagpapatakbo ng drain ay nagbibigay-daan sa iyong muling ipamahagi ang lahat ng mga pod mula sa isang node. Sa panahon ng pagsasagawa ng drain, ang node ay minarkahan bilang unschedulable (flag NoSchedule). Pinipigilan nito ang mga bagong pod na lumitaw dito. Pagkatapos ay magsisimula ang drain na paalisin ang mga pod mula sa node, pinasara ang mga lalagyan na kasalukuyang tumatakbo sa node sa pamamagitan ng pagpapadala ng signal TERM mga lalagyan sa pod.

Bagaman kubectl drain gagawa ng mahusay na trabaho sa pagpapaalis ng mga pod, may dalawang iba pang salik na maaaring maging sanhi ng pagbagsak ng pagpapatakbo ng drain:

• Ang iyong aplikasyon ay dapat na maayos na wakasan kapag naisumite TERM hudyat. Kapag pinaalis ang mga pod, nagpapadala ng signal ang Kubernetes TERM mga lalagyan at naghihintay na huminto ang mga ito para sa isang tiyak na tagal ng oras, pagkatapos nito, kung hindi pa sila huminto, sapilitang tinatanggal ang mga ito. Sa anumang kaso, kung hindi nakikita ng iyong container ang signal nang tama, maaari mo pa ring patayin ang mga pod nang hindi tama kung kasalukuyang tumatakbo ang mga ito (halimbawa, may kasalukuyang transaksyon sa database).
• Nawala mo ang lahat ng pod na naglalaman ng iyong application. Maaaring hindi ito available kapag inilunsad ang mga bagong container sa mga bagong node, o kung ang iyong mga pod ay na-deploy nang walang mga controller, maaaring hindi na mag-restart ang mga ito.

Pag-iwas sa downtime

Upang mabawasan ang downtime mula sa boluntaryong pagkaantala, tulad ng mula sa pagpapatakbo ng drain sa isang node, ibinibigay ng Kubernetes ang mga sumusunod na opsyon sa paghawak ng pagkabigo:

• Magiliw na pagwawakas
• Lifecycle hook
• PodDisruptionBudgets

Sa natitirang bahagi ng serye, gagamitin namin ang mga feature na ito ng Kubernetes para mabawasan ang epekto ng paglilipat ng mga pod. Upang gawing mas madaling sundin ang pangunahing ideya, gagamitin namin ang aming halimbawa sa itaas kasama ang sumusunod na pagsasaayos ng mapagkukunan:

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

Ang pagsasaayos na ito ay isang kaunting halimbawa Deployment, na namamahala sa mga nginx pod sa cluster. Bilang karagdagan, inilalarawan ng pagsasaayos ang mapagkukunan Service, na maaaring magamit upang ma-access ang mga nginx pod sa isang kumpol.

Sa buong cycle, paulit-ulit naming palalawakin ang configuration na ito para sa kalaunan ay maisama nito ang lahat ng mga kakayahan na ibinibigay ng Kubernetes upang bawasan ang downtime.

Para sa ganap na ipinatupad at nasubok na bersyon ng mga update sa cluster ng Kubernetes para sa zero downtime sa AWS at higit pa, bisitahin ang Gruntwork.io.

Basahin din ang iba pang mga artikulo sa aming blog:

• Zero Downtime Deployment at Mga Database
• Kubernetes: bakit napakahalagang i-configure ang pamamahala ng mapagkukunan ng system?
• Tekton Pipeline - Kubernetes-katutubong pipeline
• Pagbuo ng mga dynamic na module para sa Nginx
• Panimula sa Awtorisasyon ng Kubernetes ng Hashicorp Consul
• Ano ang humantong sa paglipat mula sa ClickHouse nang walang pahintulot sa ClickHouse na may pahintulot?

Pinagmulan: www.habr.com