Altgradiga procezo por via Kubernetes-grupo
Iam, kiam vi uzas Kubernetes-grupon, necesas ĝisdatigi kurantajn nodojn. Ĉi tio povas inkluzivi pakajn ĝisdatigojn, kernajn ĝisdatigojn aŭ disfaldidon de novaj virtualaj maŝinaj bildoj. En Kubernetes-terminaro tio estas nomita .
Ĉi tiu afiŝo estas parto de 4-afiŝo:
- Ĉi tiu afiŝo.
- Ĝusta ĉesigo de podoj en Kubernetes-areto
- Prokrastita ĉesigo de pod kiam ĝi estas forigita
- Kiel Eviti Malfunkcion de Kubernetes Cluster Uzante PodDisruptionBudgets
(ĉ. Atendu tradukojn de la ceteraj artikoloj en la serio baldaŭ)
En ĉi tiu artikolo, ni priskribos ĉiujn ilojn, kiujn Kubernetes provizas por atingi nulan malfunkcion por la nodoj kurantaj en via areto.
Difinante la problemon
Ni unue prenos naivan aliron, identigos problemojn kaj taksos la eblajn riskojn de ĉi tiu aliro, kaj konstruos scion por solvi ĉiun el la problemoj, kiujn ni renkontas dum la ciklo. La rezulto estas agordo, kiu uzas vivciklajn hokojn, pretemajn enketojn kaj Pod-interrompajn buĝetojn por atingi nian celon de nula malfunkcio.
Por komenci nian vojaĝon, ni prenu konkretan ekzemplon. Ni diru, ke ni havas Kubernetes-areton de du nodoj, en kiu aplikaĵo funkcias kun du podoj situantaj malantaŭe. Service:
Ni komencu per du guŝoj kun Nginx kaj Servo funkcianta sur niaj du Kubernetes-grupo-nodoj.
Ni volas ĝisdatigi la kernan version de du labornodoj en nia areto. Kiel ni faras ĉi tion? Simpla solvo estus lanĉi novajn nodojn kun la ĝisdatigita agordo kaj poste malŝalti la malnovajn nodojn dum komencado de la novaj. Dum ĉi tio funkcios, estos kelkaj problemoj kun ĉi tiu aliro:
- Kiam vi malŝaltas malnovajn nodojn, la podoj kurantaj sur ili ankaŭ estos malŝaltitaj. Kio se la balgoj devas esti purigitaj por gracia haltigo? La virtualiga sistemo, kiun vi uzas, eble ne atendas ke la puriga procezo finiĝos.
- Kio se vi malŝaltas ĉiujn nodojn samtempe? Vi ricevos decan malfunkcion dum la balgoj moviĝos al novaj nodoj.
Ni bezonas manieron gracie migri podojn de malnovaj nodoj dum ni certigas, ke neniu el niaj laborprocezoj funkcias dum ni faras ŝanĝojn al la nodo. Aŭ kiam ni faras kompletan anstataŭigon de la grapolo, kiel en la ekzemplo (tio estas, ni anstataŭigas VM-bildojn), ni volas translokigi kurantajn aplikojn de malnovaj nodoj al novaj. En ambaŭ kazoj, ni volas malhelpi novajn podojn plani sur malnovaj nodoj, kaj poste forpeli ĉiujn kurantajn podojn de ili. Por atingi ĉi tiujn celojn ni povas uzi la komandon kubectl drain.
Redistribuante ĉiujn podojn de nodo
La drenadoperacio permesas vin redistribui ĉiujn podojn de nodo. Dum drenekzekuto, la nodo estas markita kiel neplanebla (flago NoSchedule). Ĉi tio malhelpas novajn podojn aperi sur ĝi. Tiam drenilo komencas elpeli gusojn de la nodo, fermas la ujojn, kiuj nuntempe funkcias sur la nodo, sendante signalon. TERM ujoj en balgo.
Kvankam kubectl drain faros bonegan laboron por elpeli gusojn, estas du aliaj faktoroj, kiuj povas malsukcesigi la drenan operacion:
- Via kandidatiĝo devas povi fini gracie post submetiĝo
TERMsignalo. Kiam balgoj estas forpelitaj, Kubernetes sendas signalonTERMujojn kaj atendas, ke ili haltos dum difinita tempo, post kiu, se ili ne ĉesis, ĝi perforte ĉesigas ilin. Ĉiukaze, se via ujo ne perceptas la signalon ĝuste, vi ankoraŭ povas estingi podojn malĝuste se ili nuntempe funkcias (ekzemple, datumbaza transakcio estas en progreso). - Vi perdas ĉiujn podojn, kiuj enhavas vian aplikaĵon. Ĝi eble ne estos disponebla kiam novaj ujoj estas lanĉitaj sur novaj nodoj, aŭ se viaj podoj estas deplojitaj sen regiloj, ili eble tute ne rekomencos.
Evitante malfunkcion
Por minimumigi malfunkcion de libervola interrompo, kiel de drenadoperacio sur nodo, Kubernetes disponigas la sekvajn fiaskojn pri traktado de opcioj:
En la resto de la serio, ni uzos ĉi tiujn funkciojn de Kubernetes por mildigi la efikon de balda migrado. Por plifaciligi sekvi la ĉefan ideon, ni uzos nian ekzemplon supre kun la sekva agordo de rimedoj:
---
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Ĉi tiu agordo estas minimuma ekzemplo Deployment, kiu administras nginx pods en la areto. Krome, la agordo priskribas la rimedon Service, kiu povas esti uzata por aliri nginx-podojn en areto.
Dum la ciklo, ni ripete vastigos ĉi tiun agordon, por ke ĝi eventuale inkluzivas ĉiujn kapablojn, kiujn Kubernetes provizas por redukti malfunkcion.
Por plene efektivigita kaj provita versio de Kubernetes-grupo-ĝisdatigoj por nula malfunkcio en AWS kaj pretere, vizitu .
Legu ankaŭ aliajn artikolojn en nia blogo:
fonto: www.habr.com