«Översikt av Kubesprays funktioner»: Skillnaden mellan den ursprungliga versionen och vår fork

23 september 20.00 MSK Sergey Bondarev håller ett gratis webbinarium "Översikt av möjligheterna med Kubespray", där han kommer att berätta hur man förbereder kubespray för att göra det snabbt, effektivt och resilent.

Sergey Bondarev kommer att berätta om skillnaden mellan den ursprungliga versionen och vår fork:

Skillnaden mellan den ursprungliga versionen och vår fork.

De som redan har stött på kubespray kanske nu undrar varför jag sätter kubeadm i kontrast till kubespray, eftersom kubespray används för att skapa kluster, vilket faktiskt anropar kubeadm och vid första anblicken verkar som ett installationsskript för paket och automatiserad start.

Men så har det inte alltid varit, från början installerade kubespray alla komponenter själv:

• sammanställde etcd-klustret;
• installerade kubelets, genererade certifikat, konfigurationer och åtkomsttoken för statiska pods på kontrollplanet och andra tjänstekomponenter;
• skapade tjänstekonton för arbetsnoder och kopplade dem till klustret.

Men förra året tog de bort denna funktionalitet och behöll endast kubeadm, vilket vid den tiden inte var särskilt bra. Jag blev besviken och gjorde min egen fork, där jag bevarade det klassiska installationsläget, och nu underhåller jag den fork i aktuellt skick, genom att cherry-picka commits från den ursprungliga kubespray till mig. Samtidigt justerar jag det klassiska läget för nya förändringar.

Resultatet är att skillnaden mellan kluster skapade med min fork och den ursprungliga är kube-proxy och giltighetstiden för certifikaten.

I min fork har allt stannat kvar som det var förr – kube-proxy körs som en statisk pod, certifikat utfärdas för 100 år.

I Kubeadm körs kube-proxy som en daemonset, och certifikat utfärdas för 1 år, och de måste förnyas regelbundet. Kubeadm har äntligen lärt sig att göra detta med ett enda kommando.

Skillnaden är liten, och idag använder vi båda varianterna.

Egenskaper (nackdelar) vid industriell användning:

Scenariot är universellt, så det är inte särskilt snabbt. Eget kan betydligt snabba upp detta genom att ta bort kontroller och köra från en färdig bild.

Scenariot är komplext, det finns ologiska delar och en tung legacy. Installation av ytterligare kontroller och mjukvara via Kubespray är bra för utbildning och tester. I produktionsmiljö är det inte en särskilt smart idé att vara beroende av Kubespray, plus att mjukvaruuppdateringar genomförs med metoden "dödade-gjorde ny" — vilket innebär avbrott i servicen.

Det kan bara lägga till arbetsnoder, med mästare finns det vissa nyanser med certifikat, och scenariot hanterar inte alla möjliga problem som kan uppstå.

Till exempel hade jag ett problem med kubeadm när det kraschade vid tillägg av andra och tredje mästare, och efter det gjorde Kubespray kubeadm reset på noden och försökte lägga till mästaren igen.

Problemet var bara att vid tidpunkten för kraschen hade den andra instansen av etcd redan registrerats, och eftersom den också raderades efter reset, fick vi en mardröm — en etcd-kluster av två noder, en av dem som raderades och den andra som inte längre tar emot klienter. I slutändan dog klustret innan det föddes.

Öppen källkod som den är.

Allt detta och mycket mer på det kostnadsfria webbinariet "Översikt av möjligheterna med Kubespray" den 23 september klockan 20.00 MSK.

Följ med!

Källa: habr.com