ProHoster > Blogi > antaminen > Kubernetes-klusterin päivittäminen ilman seisokkeja

Kubernetes-klusterin päivittäminen ilman seisokkeja

Kubernetes-klusterin päivittäminen ilman seisokkeja

Päivitysprosessi Kubernetes-klusterillesi

Jossain vaiheessa, kun käytetään Kubernetes-klusteria, käynnissä olevia solmuja on päivitettävä. Tämä voi sisältää pakettipäivityksiä, ytimen päivityksiä tai uusien virtuaalikoneen näköistiedostojen käyttöönottoa. Kubernetes-terminologiassa tätä kutsutaan "Vapaaehtoinen häiriö".

Tämä postaus on osa neljän tekstin sarjaa:

  1. Tämä postaus.
  2. Kubernetes-klusterin podien oikea sammutus
  3. Pod:n lopettaminen viivästyy, kun se poistetaan
  4. Kubernetes-klusterin seisokkien välttäminen PodDisruptionBudgetsin avulla

(noin. Sarjan muiden artikkelien käännöksiä odotetaan lähitulevaisuudessa)

Tässä artikkelissa kuvataan kaikki Kubernetesin tarjoamat työkalut, joilla saavutetaan nolla seisokkiaika klusterin solmuille.

Ongelman määrittely

Otamme aluksi naiivia lähestymistapaa, tunnistamme ongelmat ja arvioimme tämän lähestymistavan mahdollisia riskejä ja rakennamme tietoa ratkaistaksemme jokaisen syklin aikana kohtaamamme ongelman. Tuloksena on konfiguraatio, joka käyttää elinkaarikoukkuja, valmiusantureita ja Pod-häiriöbudjetteja saavuttaakseen nollakatkostavoitteemme.

Aloitamme matkamme ottamalla konkreettisen esimerkin. Oletetaan, että meillä on kahden solmun Kubernetes-klusteri, jossa sovellus on käynnissä kahdella podilla takana Service:

Kubernetes-klusterin päivittäminen ilman seisokkeja

Aloitetaan kahdella podilla, joissa Nginx ja Service toimivat kahdessa Kubernetes-klusterisolmussamme.

Haluamme päivittää klusterin kahden työntekijäsolmun ydinversion. Miten tämä tehdään? Yksinkertainen ratkaisu olisi käynnistää uudet solmut päivitetyillä kokoonpanoilla ja sulkea sitten vanhat solmut samalla kun käynnistetään uusia. Vaikka tämä toimii, tähän lähestymistapaan liittyy muutamia ongelmia:

  • Kun sammutat vanhat solmut, myös niissä käynnissä olevat podit sammuvat. Entä jos kotelot on tyhjennettävä sulavaa sulkemista varten? Käyttämäsi virtualisointijärjestelmä ei välttämättä odota puhdistusprosessin valmistumista.
  • Entä jos sammutat kaikki solmut samanaikaisesti? Saat kunnollisia seisokkeja, kun podit siirtyvät uusiin solmuihin.

Tarvitsemme tavan siirtää podeja sulavasti vanhoista solmuista ja varmistaa samalla, että mikään työprosesseistamme ei ole käynnissä, kun teemme muutoksia solmuun. Tai kun korvaamme klusterin täydellisesti, kuten esimerkissä (eli korvaamme VM-kuvat), haluamme siirtää käynnissä olevat sovellukset vanhoista solmuista uusiin. Molemmissa tapauksissa haluamme estää uusia podeja ajoittamasta vanhoja solmuja ja sitten häätää kaikki käynnissä olevat podit niistä. Näiden tavoitteiden saavuttamiseksi voimme käyttää komentoa kubectl drain.

Kaikkien podien uudelleenjakaminen solmusta

Tyhjennystoiminnon avulla voit jakaa uudelleen kaikki kotelot solmusta. Tyhjennyssuorituksen aikana solmu on merkitty aikatauluttomaksi (lippu NoSchedule). Tämä estää uusien palojen ilmestymisen siihen. Sitten dreeni alkaa häätää podeja solmusta, sammuttaa solmussa parhaillaan käynnissä olevat säiliöt lähettäen signaalin TERM astiat pussissa.

Vaikka kubectl drain tekee erinomaista työtä koteloiden häätämisessä, kaksi muuta tekijää voivat aiheuttaa tyhjennystoiminnan epäonnistumisen:

  • Hakemuksesi on voitava lopettaa sulavasti lähetyksen jälkeen TERM signaali. Kun palot häädetään, Kubernetes lähettää signaalin TERM kontteja ja odottaa niiden pysähtymistä tietyn ajan, jonka jälkeen, jos ne eivät ole pysähtyneet, se lopettaa ne väkisin. Joka tapauksessa, jos säiliösi ei havaitse signaalia oikein, voit silti sammuttaa podit väärin, jos ne ovat parhaillaan käynnissä (esimerkiksi tietokantatapahtuma on meneillään).
  • Menetät kaikki sovelluksesi sisältävät kotelot. Se ei ehkä ole käytettävissä, kun uusia säilöjä käynnistetään uusissa solmuissa, tai jos podit otetaan käyttöön ilman ohjaimia, ne eivät välttämättä käynnisty uudelleen ollenkaan.

Katkosaikojen välttäminen

Kubernetes tarjoaa seuraavat viankäsittelyvaihtoehdot minimoidakseen seisokit, jotka johtuvat vapaaehtoisesta häiriöstä, kuten solmun tyhjennystoiminnosta:

Sarjan loppuosassa käytämme näitä Kubernetes-ominaisuuksia lieventämään pod-migraatiovaikutuksia. Pääidean noudattamisen helpottamiseksi käytämme yllä olevaa esimerkkiämme seuraavan resurssikokoonpanon kanssa:

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

Tämä kokoonpano on minimaalinen esimerkki Deployment, joka hallitsee klusterin nginx-paloja. Lisäksi konfiguraatio kuvaa resurssia Service, jota voidaan käyttää klusterin nginx-palojen käyttämiseen.

Laajennamme tätä kokoonpanoa toistuvasti koko syklin ajan niin, että se sisältää lopulta kaikki Kubernetesin tarjoamat ominaisuudet seisokkien vähentämiseksi.

Täysin toteutettu ja testattu versio Kubernetes-klusteripäivityksistä AWS:n ja sen jälkeisten käyttökatkojen nollaamiseksi on osoitteessa Gruntwork.io.

Lue myös muut artikkelit blogistamme:

Lähde: will.com

Lisää kommentti