„A Kubespray képességeinek áttekintése”: Az eredeti verzió és a mi villánk közötti különbség

Szeptember 23-án, moszkvai idő szerint 20.00:XNUMX-án Szergej Bondarev ingyenes webináriumot tart „A Kubespray jellemzőinek áttekintése", ahol elmondja, hogyan kell elkészíteni a kubesprayt, hogy az gyorsan, hatékonyan és hibatűrően elkészüljön.

Szergej Bondarev elmondja, mi a különbség az eredeti verzió és a mi villánk között:

„A Kubespray képességeinek áttekintése”: Az eredeti verzió és a mi villánk közötti különbség

A különbség az eredeti verzió és a mi villánk között.

Azok, akik már találkoztak a cubespray-vel, valószínűleg most azon töprengenek, hogy miért állítom szembe a kubeadm-et a cubespray-vel, mert a fürt létrehozására szolgáló cubespray a kubeadm-et hívja meg, és első pillantásra úgy néz ki, mint egy szkript a csomagok telepítéséhez és az automatikus indításhoz.

De ez nem mindig volt így; kezdetben a cubespray minden alkatrészt egymástól függetlenül telepített:

  • összeállított stbd klaszter;
  • telepített kockák, generált tanúsítványok, konfigurációk és hozzáférési jogkivonatok statikus vezérlősík podokhoz és egyéb szolgáltatási összetevőkhöz;
  • szolgáltatásfiókokat hozott létre a dolgozó csomópontokhoz, és összekapcsolta őket a fürttel.

De tavalyelőtt kivágták ezt a funkciót, és csak a kubadm maradt. Ami akkoriban nem volt túl jó. Megsértve éreztem magam, és elkészítettem a saját villámat, amiben megtartottam a klasszikus telepítési módot, sőt, most ezt a villát tartom naprakészen, az eredeti kockaspray-ből cseresznyeszedő commitokat magamnak. Útközben a klasszikus mód befejezése az új változtatásokhoz.

Ennek eredményeként a fork által létrehozott klaszterek és az eredeti klaszterek közötti különbség a kube-proxy és a tanúsítványok érvényességi ideje.

A villámban minden marad a régiben - a proxy kocka statikus podként indul, a tanúsítványokat 100 évre adják ki.

A Kubeadm-ben a proxy kocka démonsetként indul, és a tanúsítványokat 1 évre adják ki, és azokat rendszeresen meg kell újítani. A kubeadm végre megtanulta, hogyan kell ezt egyetlen paranccsal megtenni.

A különbség kicsi, és ma mindkét lehetőséget használjuk.

Jellemzők (hátrányok) az ipari működés során:

A forgatókönyv univerzális, tehát nem túl gyors. Jelentősen felgyorsíthatja a sajátját az ellenőrzések kiiktatásával és a kész képről történő indítással.

A forgatókönyv bonyolult, vannak logikátlan helyek, súlyos örökség. Kiegészítő felszerelése vezérlők és szoftverek cubespray-n keresztül - jó edzéshez és teszteléshez. A bálban. A működéshez a kockaspray-től függően nem túl jó ötlet, ráadásul a szoftverfrissítés az „öld meg és csinálj újat” módszerrel valósul meg – ami a szolgáltatás megszakítását jelenti.

Csak munkavégző csomópontokat lehet hozzáadni, a mestereknél van néhány árnyalat a tanúsítványoknál, és a szkript nem kezeli az összes felmerülő problémát.

Például a kubeadm-mel volt gondom, amikor összeomlott a második és harmadik mester hozzáadásakor, majd ezután a cubespray csinált egy kubeadm reset-et a csomóponton, és újra megpróbálta hozzáadni a mastert.

A probléma csak az volt, hogy mire a hiba bekövetkezett, a második etcd példányt már sikerült regisztrálni, és mivel az is törölve lett a reset után, rémálom lett a vége - egy két csomópontból álló etcd klaszter, amiből az egyik törölve, a második pedig már nem fogad ügyfeleket. Ennek eredményeként a klaszter megszületés nélkül meghalt.

Opensource, ahogy van.

Mindez és még sok más az ingyenes webináriumon"A Kubespray jellemzőinek áttekintése» Szeptember 23., moszkvai idő szerint 20.00.

Csatlakozzon most!

Forrás: will.com

Hozzászólás