ProHoster > Blog > Administrazioa > Kubernetes kluster bat berritzea etenaldirik gabe

Kubernetes kluster bat berritzea etenaldirik gabe

Kubernetes kluster bat berritzea etenaldirik gabe

Zure Kubernetes klusterra eguneratzeko prozesua

Noizbait, Kubernetes kluster bat erabiltzean, martxan dauden nodoak eguneratu beharra dago. Horrek paketeen eguneraketak, nukleoaren eguneraketak edo makina birtualaren irudi berrien inplementazioa izan ditzake. Kubernetes-en terminologian horri deitzen zaio "Borondatezko etenaldia".

Mezu hau 4 argitalpen serie baten parte da:

  1. Post hau.
  2. Kubernetes kluster bateko podak zuzen ixtea
  3. Ezabatzen denean pod bat osatzea atzeratu da
  4. Nola saihestu Kubernetes Cluster-en geldialdi-denbora PodDisruptionBudgets erabiliz

(Gutxi gorabehera. Espero etorkizun hurbilean serieko gainerako artikuluen itzulpenak)

Artikulu honetan, Kubernetes-ek eskaintzen dituen tresna guztiak deskribatuko ditugu zure klusterrean exekutatzen diren nodoetarako zero geldialdi-denbora lortzeko.

Problemaren definizioa

Ikuspegi inozoa hartuko dugu hasieran, arazoak identifikatu eta planteamendu honen balizko arriskuak ebaluatuko ditugu, eta ezagutzak eraikiko ditugu zikloan zehar aurkitzen ditugun arazo bakoitza konpontzeko. Ondorioz, bizi-zikloko amuak, presttasun-zundak eta Pod eten-aurrekontuak erabiltzen dituen konfigurazioa da, gure zero geldialdi-helburua lortzeko.

Gure bidaia hasteko, har dezagun adibide konkretu bat. Demagun bi nodoz osatutako Kubernetes kluster bat dugula, eta bertan aplikazio bat exekutatzen ari den atzean kokatutako bi podekin Service:

Kubernetes kluster bat berritzea etenaldirik gabe

Has gaitezen Nginx eta Service gure bi Kubernetes kluster nodoetan exekutatzen dituzten bi podekin.

Gure klusterreko bi langile-nodoen nukleoaren bertsioa eguneratu nahi dugu. Nola egiten dugu hau? Irtenbide sinple bat nodo berriak abiaraztea izango litzateke eguneratutako konfigurazioarekin eta gero nodo zaharrak ixtea berriak abiaraztean. Honek funtzionatuko duen arren, arazo batzuk izango dira ikuspegi honekin:

  • Nodo zaharrak desaktibatzen dituzunean, horietan exekutatzen diren podak ere itzaliko dira. Zer gertatzen da lekak garbitu behar badira itzaltzeko dotorea izateko? Erabiltzen ari zaren birtualizazio-sistema agian ez da itxaron garbiketa-prozesua amaitu arte.
  • Zer gertatzen da nodo guztiak aldi berean itzaltzen badituzu? Etenaldi dexente lortuko duzu lekak nodo berrietara mugitzen diren bitartean.

Nodo zaharretatik pod-ak dotoretasunez migratzeko modu bat behar dugu, gure langile-prozesuetako bat ere ez dela abian nodoan aldaketak egiten ditugun bitartean bermatuz. Edo klusterraren ordezkapen osoa egiten dugunean, adibidean bezala (hau da, VM irudiak ordezkatzen ditugu), martxan dauden aplikazioak nodo zaharretatik berrietara transferitu nahi ditugu. Bi kasuetan, pod berriak nodo zaharretan programatzea eragotzi nahi dugu, eta, ondoren, exekutatzen diren pod guztiak haietatik kanporatu. Helburu hauek lortzeko komandoa erabil dezakegu kubectl drain.

Pod guztiak nodo batetik birbanatzea

Drainatze-eragiketak nodo batetik pod guztiak birbanatzeko aukera ematen du. Drainatze exekuzioan, nodoa programatu ezin den moduan markatzen da (bandera NoSchedule). Honek leka berriak agertzea eragozten du. Ondoren draina nodotik lekak kanporatzen hasten da, une honetan nodoan exekutatzen ari diren ontziak itzaltzen ditu seinale bat bidaliz. TERM ontziak ontzian.

Nahiz eta kubectl drain lekak kanporatzeko lan bikaina egingo du, hustuketa-eragiketak huts egitea eragin dezaketen beste bi faktore daude:

  • Zure eskaera bidaltzean dotore amaitu ahal izan behar du TERM seinalea. Podak kanporatzen direnean, Kubernetes-ek seinale bat bidaltzen du TERM edukiontziak eta denbora jakin batean gelditu arte itxaroten du, eta, ondoren, gelditu ez badira, indarrez amaitzen ditu. Edonola ere, zure edukiontziak seinalea behar bezala hautematen ez badu, okerrak itzal ditzakezu oraindik exekutatzen ari badira (adibidez, datu-basearen transakzio bat abian da).
  • Zure aplikazioa duten pod guztiak galtzen dituzu. Baliteke erabilgarri ez egotea nodo berrietan edukiontzi berriak abiarazten direnean, edo zure podak kontrolagailurik gabe zabaltzen badira, baliteke batere ez berrabiarazi.

Atsedenaldia saihestea

Borondatezko etenengatiko geldialdi-denbora minimizatzeko, adibidez, nodo bateko drainatze-eragiketa baten ondorioz, Kubernetes-ek akatsak kudeatzeko aukera hauek eskaintzen ditu:

Gainontzeko seriean, Kubernetes-en eginbide hauek erabiliko ditugu lekak migratzen duten eragina arintzeko. Ideia nagusia errazago jarraitzeko, goiko adibidea erabiliko dugu baliabideen konfigurazio honekin:

---
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

Konfigurazio hau gutxieneko adibide bat da Deployment, klusterrean nginx lekak kudeatzen dituena. Gainera, konfigurazioak baliabidea deskribatzen du Service, kluster batean nginx pods sartzeko erabil daitekeena.

Zikloan zehar, konfigurazio hau errepikatuko dugu, azkenean Kubernetes-ek geldialdi-denbora murrizteko eskaintzen dituen gaitasun guztiak barne har ditzan.

Kubernetes kluster eguneratzeen guztiz inplementatutako eta probatutako bertsio bat lortzeko, AWS-n eta hortik kanpo geldialdirik ez izateko, bisitatu Gruntwork.io.

Irakurri beste artikulu batzuk ere gure blogean:

Iturria: www.habr.com

Gehitu iruzkin berria