«Oversigt over mulighederne med Kubespray»: Forskellen mellem den oprindelige version og vores fork

23. september kl. 20.00 MSK vil Sergey Bondarev afholde et gratis webinar "Oversigt over Kubesprays funktioner", hvor han vil fortælle, hvordan man forbereder kubespray, så det bliver hurtigt, effektivt og fejltolerant.

Sergey Bondarev vil forklare forskellen mellem den originale version og vores fork:

«Oversigt over mulighederne med Kubespray»: Forskellen mellem den oprindelige version og vores fork

Forskellen mellem den originale version og vores fork.

De, der allerede har arbejdet med kubespray, undrer sig nok over, hvorfor jeg sætter kubeadm i kontrast til kubespray, da kubespray netop bruges til at oprette et cluster og kalder kubeadm, og ved første øjekast ligner det et installationsscript til pakker og automatiseret opsætning.

Men det har ikke altid været sådan; oprindeligt installerede kubespray alle komponenter selv:

  • opsatte etcd-clusteret;
  • installerede kubelets, genererede certifikater, konfigurationer og adgangstokens til de statiske pods i kontrolplanen og andre servicekomponenter;
  • oprettede servicekonti for arbejdsnoder og tilsluttede dem til clusteret.

Men i det forrige år blev denne funktionalitet fjernet, kun kubeadm blev tilbage. På det tidspunkt var det ikke så godt. Jeg blev ked af det og lavede min egen fork, hvor jeg bevarede den klassiske installationsmetode, og nu vedligeholder jeg denne fork i en aktuel tilstand ved at cherry-picke commits fra det originale kubespray ind i min egen. Undervejs videreudviklede jeg den klassiske metode til de nye ændringer.

Resultatet er, at forskellen mellem klustrene, skabt med min fork og den originale, er kube-proxy og certificaters gyldighedsperiode.

I min fork forblev alt som før — kube-proxy kører som en statisk pod, certifikater udstedes i 100 år.

I Kubeadm kører kube-proxy som daemonset, og certifikater udstedes i 1 år, og de skal periodisk forlænges. Kubeadm har endelig lært at gøre dette med en enkelt kommando.

Forskellen er lille, og i dag bruger vi begge varianter.

Særlige forhold (mangler) ved industriel drift:

Scenariet er universelt, og derfor ikke specielt hurtigt. Eget kan betydeligt accelereres ved at fjerne kontroller og starte fra et færdigt billede.

Scenariet er komplekst, der er ulogiske steder, et tungt arv. Installation af ekstra controllere og software via Kubespray er godt til læring og tests. At være afhængig af Kubespray i produktion er ikke en særlig klog idé, plus softwareopdatering implementeres med metoden "dræb-lav ny" — hvilket betyder en pause i servicen.

Man kan kun tilføje arbejdsnoder, der er nogle nuancer med mastere vedrørende certifikater, og scenariet dækker ikke alle mulige problemer, der kan opstå.

For eksempel havde jeg et problem med kubeadm, da det faldt, når jeg forsøgte at tilføje den anden og tredje master, og derefter forsøgte Kubespray at foretage kubeadm reset på noden og prøvede at tilføje masteren igen.

Problemet var dog, at på tidspunktet for fejlen var den anden etcd-instant allerede registreret, og da den også blev fjernet efter reset, så fik vi et mareridt — et etcd-kluster bestående af to noder, hvor den ene blev fjernet og den anden ikke længere accepterede klienter. Resultatet var, at klustret døde, før det blev født.

Opensource som det er.

Alt dette og meget mere på gratis webinar "Oversigt over Kubesprays funktioner" den 23. september kl. 20.00 MSK.

Deltag!

Kilde: habr.com

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster