Kubernetesin korkea käytettävyys varmistaa, että klusterisi pysyy toiminnassa myös vikojen aikana. Tämä opas selittää, miten suunnitellaan ja otetaan käyttöön vikasietoinen Kubernetes-klusteri, ja käsittelee keskeisiä komponentteja, redundanssistrategioita ja konfigurointivaiheita.

Tärkeimmät takeawayt:

• Miksi korkea käytettävyys on tärkeääEstä laitteistovikojen, verkko-ongelmien tai huollon aiheuttamat käyttökatkokset.
• Ydinstrategiat:
  • Käytä useita ohjaustason solmuja yksittäisten vikaantumiskohtien poistamiseksi.
  • Jaa työsolmut vyöhykkeiden tai alueiden välillä vikasietoisuuden parantamiseksi.
  • Ota käyttöön kuormituksen tasaajat liikenteen hallintaan ja sujuvan vikasietoisuuden varmistamiseksi.
• Kriittiset komponentit:
  • API-palvelin, etcd-tietokanta, ajoitusohjelma ja ohjainhallinta tarvitsevat redundanssia.
  • Valitse pinottujen tai ulkoisten etcd-topologioiden välillä kokoonpanosi monimutkaisuuden ja mittakaavan mukaan.
• Käyttöönottovaiheet:
  • Käyttää kubeadm klusterin perustamiseksi.
  • Määritä kuormituksen tasaajat, kuntotarkastukset ja työsolmut.
  • Testaa vikasietoisuus- ja varmuuskopiointiprosesseja säännöllisesti.

Korkea käytettävyys vaatii huolellista suunnittelua, vankkaa infrastruktuuria ja jatkuvaa testausta tasaisen suorituskyvyn ja käyttöajan varmistamiseksi.

[ Kube 1.5 ] Asenna erittäin käytettävissä oleva Kubernetes-klusteri vaihe vaiheelta | Keepalived & Haproxy

Korkean käytettävyyden Kubernetes-klusterin suunnittelu

Korkean käytettävyyden (HA) Kubernetes-klusteria rakennettaessa on erittäin tärkeää sovittaa suunnittelu yhteen selkeiden liiketoiminta- ja teknisten tavoitteiden kanssa. Ilman huolellista suunnittelua saatat päätyä järjestelmään, joka on joko liian monimutkainen tai liian hauras vastaamaan saatavuustarpeitasi. Alla tarkastelemme keskeisiä huomioitavia asioita ja arkkitehtuuripäätöksiä, jotka auttavat sinua löytämään oikean tasapainon.

Liiketoiminta- ja teknisten vaatimusten arviointi

Aloita määrittämällä käyttökatkosten ja datan menetyksen sietokykysi. Nämä parametrit muokkaavat kaikkia klusteriisi liittyviä teknisiä valintojasi.

• Palautumisajan tavoite (RTO)Tämä mittaa, kuinka nopeasti järjestelmiesi on toivuttava vian jälkeen. Jos esimerkiksi yrityksesi vaatii järjestelmien olevan toiminnassa viiden minuutin kuluessa, tarvitset automatisoituja vikasietoprosesseja ja esimääritettyjä vararesursseja. Toisaalta, jos pidemmät palautumisajat ovat hyväksyttäviä, voit valita yksinkertaisempia ja kustannustehokkaampia ratkaisuja, jotka edellyttävät manuaalista puuttumista asiaan.
• Recovery Point Objective (RPO)Tämä määrittää, kuinka paljon datahävikki on hyväksyttävää. Esimerkiksi rahoitusalan kaupankäyntialusta ei välttämättä vaadi datahävikkiä, mikä edellyttää synkronista datan replikointia. Verkkokauppa-alusta puolestaan saattaa sietää pienen dataaukon järjestelmän monimutkaisuuden vähentämiseksi.

Sinun on myös määriteltävä saatavuustavoitteesi. Tiedoksi:

• 99.9% käyttöaika sallii noin 8,77 tuntia seisokkiaikaa vuodessa.
• 99.99% käyttöaika lyhentää sen noin 52,6 minuuttiin.

Ota lisäksi huomioon sovelluksesi liikennemallit ja skaalaustarpeet. Ennakoitavissa olevat liikennepiikit vaativat erilaisia strategioita verrattuna sovelluksiin, jotka kokevat äkillisiä ja arvaamattomia piikkejä. Resurssi-intensiiviset työkuormat saattavat vaatia erikoistuneita solmupooleja räätälöidyillä laitteistokokoonpanoilla, mikä vaikuttaa siihen, miten jaat työkuormat vyöhykkeiden välillä.

Nämä mittarit muodostavat klusteriarkkitehtuurisi perustan, jossa tekninen tehokkuus tasapainotetaan liiketoiminnan vaatimusten kanssa. Seuraava vaihe on määrittää, miten maantieteellinen jakauma vaikuttaa suunnitteluusi.

Alueellisten vs. vyöhykkeellisten arkkitehtuurien valitseminen

Klusterin maantieteellinen hajauttaminen vaikuttaa merkittävästi sen sietokykyyn. Sekä vyöhyke- että alueelliset arkkitehtuurit tarjoavat selkeitä etuja tarpeistasi riippuen.

• VyöhykearkkitehtuuritNämä jakavat resursseja useille saatavuusvyöhykkeille yhden alueen sisällä. Ne suojaavat yksittäisten datakeskusten häiriöiltä ja pitävät samalla komponenttien välisen viiveen alhaisena. Tämä kokoonpano sopii hyvin paikallisten ongelmien, kuten sähkökatkosten tai verkkovikojen, käsittelyyn tietyllä vyöhykkeellä.
• Alueelliset arkkitehtuuritNämä jakavat resursseja useille maantieteellisille alueille ja tarjoavat suojan laajamittaisilta katastrofeilta, kuten luonnonilmiöiltä tai alueellisilta verkkokatkoksilta. Tämä lähestymistapa tuo kuitenkin usein mukanaan suuremman viiveen, joka voi vaikuttaa komponenttien, kuten etcd:n, suorituskykyyn ja klusterin yleiseen reagointikykyyn.

Alueelliset käyttöönotot toimivat parhaiten sovelluksille, joilla on globaali käyttäjäkunta tai kun määräykset edellyttävät tietojen tallentamista tiettyihin maihin. Ne sopivat myös erinomaisesti organisaatioille, joilla on tiukat katastrofien jälkeiset palautustarpeet.

Useimmissa HA-kokoonpanoissa monivyöhykkeinen ohjaustaso tarjoaa tasapainoisen lähestymistavan. Sijoittamalla ohjaustason solmut kolmelle saatavuusvyöhykkeelle yhden alueen sisällä varmistat, että etcd pystyy ylläpitämään koorumia, vaikka yksi vyöhyke vikaantuisi. Tämä lähestymistapa tarjoaa vikasietoisuuden ilman alueiden välisen viestinnän viivehaittoja.

Työsolmut voivat noudattaa samankaltaisia jakelumalleja, mutta tässä on enemmän joustavuutta. Tilattomat sovellukset voivat toimia millä tahansa solmulla, kun taas tilalliset työkuormat saattavat vaatia huolellista sijoittelua sen varmistamiseksi, että tiedot pysyvät saatavilla ja suorituskyky pysyy yhdenmukaisena.

Verkko- ja redundanssivaatimukset

Vankka verkkostrategia on avainasemassa sekä pohjois-eteläsuuntaisen liikenteen (asiakkaalta klusteriin) että itä-länsisuuntaisen liikenteen (klusterikomponenttien välinen viestintä) tukemisessa. Useiden tasojen redundanssi ei ole neuvoteltavissa.

• Käyttää useita kuormituksen tasaajia kanssa /terveys tarkistukset hajautettu vyöhykkeille. Kunkin kuormituksen tasaajan tulisi pystyä käsittelemään koko liikennekuorma yksittäisten vikakohtien poistamiseksi.
• Varmista verkkopolkujen monimuotoisuus suojautuakseen yhteysongelmilta. Vyöhykkeiden välisellä liikenteellä tulisi olla useita fyysisiä reittejä, ja sinun pilvipalveluntarjoaja tai datakeskuksen on tarjottava redundantti verkkoinfrastruktuuri.
• varten DNS- ja palveluiden etsintä, ota käyttöön useita DNS-palvelimia asianmukaisilla TTL-määrityksillä klusterin päätepisteitä varten. Vaikka DNS-pohjainen kuormituksen tasapainotus lisää redundanssia, huomaa, että asiakaspuolen DNS-välimuisti voi viivästyttää vikasietoisuuden havaitsemista.

Kun työskentelet pysyvät volyymitvarmista, että tallennustila pysyy saatavilla vyöhykkeiden vikaantumisen aikana. Tämä voi edellyttää vyöhykkeiden välistä replikointia tai hajautettuja tallennusjärjestelmiä. Suunnittele myös riittävä verkon kaistanleveys tietojen synkronoinnin käsittelemiseksi palautustapahtumien aikana, erityisesti suurten tietojoukkojen tapauksessa.

Jos harkitset Serverionin infrastruktuuriHeidän globaalit datakeskussijaintinsa tarjoavat vahvan tuen sekä vyöhyke- että alueellisille arkkitehtuureille. Heidän VPS- ja dedikoitujen palvelimien vaihtoehtonsa tarjoavat vankan laskentapohjan klusterisolmuillesi, kun taas heidän konesalipalvelunsa mahdollistavat hybridikäyttöönotot, jotka yhdistävät pilvipalvelun joustavuuden paikallisten kokoonpanojen hallintaan. Lisäksi heidän redundantti verkkoinfrastruktuurinsa on rakennettu vastaamaan korkean käytettävyyden klusterien yhteysvaatimuksiin, varmistaen, että Kubernetes-käyttöönottosi pysyy vikasietoisena ja luotettavana.

Korkean käytettävyyden ydinkomponentit ja topologiat

Erittäin käytettävissä olevan Kubernetes-klusterin luominen tarkoittaa järjestelmän toiminnan kannalta keskeisten komponenttien ymmärtämistä ja niiden järjestelyn päättämistä. Nämä päätökset vaikuttavat suoraan klusterisi luotettavuuteen, suorituskykyyn ja monimutkaisuuteen.

Kubernetes-keskuksen keskeiset komponentit HA:lle

Ohjaustaso on Kubernetes-klusterisi selkäranka. Se sisältää API-palvelin, ajastin, Controller-päälliköt, ja jne., joilla kaikilla on kriittinen rooli toiminnan ylläpidossa.

• API-palvelinAPI-palvelin on keskusyksikkö, joka käsittelee pyyntöjä kubectl, työsolmut ja muut sisäiset komponentit. Useiden API-palvelimien käyttäminen eri vyöhykkeillä varmistaa, että yhden palvelimen menettäminen ei häiritse klusteria.
• AjoitusohjelmaAikatauluttaja määrittää podit solmuille käytettävissä olevien resurssien ja määriteltyjen rajoitusten perusteella. Vaikka voit ottaa käyttöön useita aikatauluttajia redundanssin vuoksi, vain yksi tekee aktiivisesti päätöksiä kerrallaan. Jos aktiivinen aikatauluttaja epäonnistuu, toinen astuu esiin.
• Controller ManageritNämä valvovat jatkuvasti klusterin tilaa varmistaen, että resurssit vastaavat haluttua kokoonpanoa. Ne käyttävät johtajan valintaa, joten vain yksi instanssi hallinnoi aktiivisesti resursseja, kun taas varmuuskopiot ovat valmiina ottamaan haltuunsa tarvittaessa.
• jne.Tämä hajautettu avain-arvo-säilö sisältää määritystietoja, salaisuuksia ja tilatietoja. Se käyttää konsensusalgoritmia, joka vaatii toimiakseen enemmistön solmuista (päätösvaltaisuuden). Esimerkiksi kolmen solmun etcd-klusteri pystyy käsittelemään yhden solmun menettämisen menettämättä toiminnallisuutta.
• KubeletKullakin työsolmulla suoritettava kubelet kommunikoi API-palvelimen kanssa vastaanottaakseen pod-spesifikaatiot ja raportoidakseen solmun tilan. Vaikka kubeletit itsessään eivät ole klusteroituja korkean käytettävyyden takaamiseksi, useiden työsolmujen käyttö varmistaa työkuormien jatkumisen, vaikka jotkin solmut vikaantuisivat.

Kun olet ymmärtänyt nämä osatekijät, seuraava vaihe on valita tarpeisiisi parhaiten sopiva topologia.

HA-topologiat: Pinottu vs. ulkoinen etcd

Ohjaustason komponentteja järjesteltäessä on kaksi päävaihtoehtoa, joilla molemmilla on omat kompromissinsa luotettavuuden ja monimutkaisuuden suhteen.

• Pinottu etcd-topologiaTässä etcd-instanssit sijaitsevat samoilla solmuilla ohjaustason komponenttien kanssa. Tämä kokoonpano on yksinkertaisempi ottaa käyttöön ja vaatii vähemmän palvelimia. Se tuo kuitenkin mukanaan riskin: jos ohjaustason solmu vikaantuu, sekä ohjaustason palvelut että etcd-jäsen menetetään.
• Ulkoinen etcd-topologiaTässä lähestymistavassa etcd toimii erillisillä, ohjaustasosta erillisillä solmuilla. Tämä erottelu tarjoaa paremman eristämisen ja mahdollistaa resurssien itsenäisen skaalaamisen, mikä tekee siitä hyvän valinnan suurempiin tai vaativampiin ympäristöihin.

Ominaisuus	Pinottu jne.	Ulkoinen jne.
Asetuksen monimutkaisuus	Helpompi ottaa käyttöön ja hallita	Vaatii enemmän solmuja ja hallintaa
Resurssien eristäminen	Jaetut resurssit ohjaustasolla	Omistetut resurssit etcd:lle
Epäonnistumisen vaikutus	Sekä etcd että ohjaustaso vaikuttavat	Viat hallitaan itsenäisesti
skaalautuvuus	Rajoitettu jaettujen resurssien vuoksi	Itsenäinen skaalaus mahdollinen

Pienemmissä käyttöönotoissa pinottu topologia tarjoaa yksinkertaisemman lähtökohdan ja riittävän redundanssin. Toisaalta suuremmat klusterit tai sellaiset, joilla on tiukat käyttöaikavaatimukset, voivat hyötyä ulkoisen etcd-asennuksen tarjoamasta lisäjoustavuudesta.

Kun topologia on valittu, seuraava vaihe on kuormituksen tasaajat, jotka varmistavat sujuvan toiminnan.

Kuormituksen tasaajan määritys

Kuormituksen tasaajat ovat avainasemassa API-pyyntöjen jakamisessa useille API-palvelimille ja vikasietoisuuden hallinnassa palvelimien kaatuessa. Ilman niitä asiakkaiden olisi seurattava yksittäisiä API-palvelimien päätepisteitä, mikä monimutkaistaisi prosessia.

Oikein konfiguroidun kuormituksen tasaajan tulisi:

• Suorita terveystarkastukset /terveys kunkin API-palvelimen päätepiste. HTTP 200 -vastaus osoittaa valmiutta, kun taas HTTP 500 viestii ongelmasta. Terveystarkistukset tulisi suorittaa 10–15 sekunnin välein ja niissä tulisi olla 5 sekunnin aikakatkaisu, jotta ongelmat voidaan havaita nopeasti.
• Jaa pyynnöt tasaisesti, sillä Kubernetes API -palvelimet ovat tilattomia. Istuntoaffiniteettia ei yleensä vaadita, joten liikenne voi kulkea sujuvasti myös palvelinvikojen aikana.
• Käsittele SSL-päättäminen. Voit siirtää TLS-käsittelyn kuormituksen tasaajalla vähentääksesi API-palvelimien työmäärää tai välittää salatun liikenteen päästä päähän -salausta varten, jos vaatimustenmukaisuus sitä vaatii.

Lisää redundanssia ottamalla käyttöön useita kuormituksen tasaajia eri vyöhykkeillä. DNS-pohjainen kuormituksen tasaus voi tarjota toisen vikasietoisuuskerroksen, mutta muista, että DNS-välimuisti voi aiheuttaa viiveitä siirtymien aikana.

Jos käytät Serverionin infrastruktuuria, heidän omistettu palvelimet tarjoavat vankan ohjaustason suorituskyvyn, kun taas VPS-vaihtoehdot sopivat ihanteellisesti pienempiin kokoonpanoihin. Maailmanlaajuisten datakeskusten ansiosta Serverion tukee monivyöhykkeisiä kokoonpanoja ja tarjoaa kuormituksen tasapainotustyökaluja liikenteen tehokkaaseen jakamiseen jopa haastavissa verkko-olosuhteissa.

sbb-itb-59e1987

Vaiheittainen opas: HA Kubernetesin käyttöönotto kubeadm:n avulla

Nyt kun olet perehtynyt komponentteihin ja topologioihin, on aika rakentaa korkean käytettävyyden omaava Kubernetes-klusterisi. Käytämme tässä oppaassa kubeadm-työkalua – se yksinkertaistaa käyttöönottoa ja antaa silti sinun hallita kokoonpanoa.

Infrastruktuurin asennus ja edellytykset

Aloita valmistelemalla infrastruktuurisi tuotantokuormien käsittelyä varten.

Tarvitset vähintään kolme ohjaustasosolmua (vähintään: 2 suorittimen ydintä ja 4 Gt RAM-muistia; suositus: 4 ydintä ja 8 Gt RAM-muistia) ja vähintään kaksi työsolmua (vähintään: 1 ydin ja 2 Gt RAM-muistia). Asenna tuettu Linux-jakelu, kuten Ubuntu 20.04/22.04, CentOS 8 tai Rocky Linux 9, kaikkiin solmuihin. Varmista, että jokaisella solmulla on yksilöllinen isäntänimi ja että se voi kommunikoida muiden solmujen kanssa verkon kautta.

Poista vaihto käytöstä kaikissa solmuissa, koska Kubernetes ei tue sitä. Suorita sudo swapoff -a ja kommentoi kaikki swap-merkinnät pois /etc/fstab tehdäksesi muutoksesta pysyvän. Avaa tarvittavat portit: 6443 (API-palvelin), 2379–2380 (etcd), 10250 (kubelet) ja 10251–10252 (ajastin/ohjain-hallinta).

Asenna säilön suoritusympäristö jokaisella solmulla. Useimmat käyttäjät valitsevat containerd:n, jota tuetaan hyvin. Määritä se käyttämään systemd:tä cgroup-ajurina Kubernetesin oletusasetusten mukaiseksi. Asenna sitten kubeadm, kubelet ja kubectl kaikkiin solmuihin varmistaen, että ne kaikki käyttävät samaa Kubernetes-versiota yhteensopivuusongelmien välttämiseksi.

Perusta kuormituksen tasaaja ennen klusterin alustamista. Kuormituksen tasaaja voi olla laitteistopohjainen, osa pilvipalveluntarjoajan tarjontaa tai ohjelmistoratkaisu, kuten HAProxy. Sen tulisi kuunnella porttia 6443 ja välittää liikennettä API-palvelimille ohjaustason solmuillasi.

Globaalin vikasietoisen kokoonpanon saavuttamiseksi harkitse erillisten palvelimien käyttöä ohjaustason solmuille ja VPS-instanssien käyttöä työsolmuille.

Ohjaustason solmujen määrittäminen

Ensimmäinen ohjaustason solmu on klusterisi perusta. Komentorivivalitsimien sijaan luo kubeadm-määritystiedosto HA-asetuksien määrittämiseksi.

Luo tiedosto nimeltä kubeadm-config.yaml ja sisällytä klusterikokoonpanosi. Aseta ohjaustasoPäätepiste kuormituksen tasaajan osoitteeseen ja porttiin. Pinotussa etcd-topologiassa kubeadm konfiguroi etcd:n ohjaustason solmuilla automaattisesti. Jos käytät ulkoista etcd:tä, määritä päätepisteet tässä tiedostossa.

Alusta ensimmäinen ohjaustason solmu seuraavalla komennolla:
sudo kubeadm init --config=kubeadm-config.yaml --upload-certs
The --upload-sertifikaatit lippu yksinkertaistaa varmenteiden jakamista muille ohjaustason solmuille. Tämä vaihe kestää muutaman minuutin ja tuottaa liitoskomentoja lisäsolmujen lisäämiseksi.

Säilytä nämä liitoskomennot turvallisesti – ne sisältävät arkaluontoisia tokeneita. Seuraavaksi määritä kubectl ensimmäiselle ohjaustason solmulle:
mkdir -p $HOME/.kube && sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config && sudo chown $(id -u):$(id -g) $HOME/.kube/config

Ennen kuin lisäät lisää solmuja, asenna ympäristöösi sopiva CNI-laajennus.

Lisää jäljellä olevat ohjaustason solmut alustustulosteesta tulevalla join-komennolla:
sudo kubeadm join load-balancer-ip:6443 --token --discovery-token-ca-cert-hash sha256: --ohjaustaso --sertifikaatin-avain
Suorita tämä komento jokaiselle lisäohjaustason solmulle.

Varmista, että kaikki ohjaustason solmut ovat toiminnassa, suorittamalla:
kubectl hakee solmut
Sinun pitäisi nähdä kaikki solmut listattuna tilassa "Valmis".

etcd:n ja kuormituksen tasaajien konfigurointi

Viimeistele HA-määritys hienosäätämällä etcd:n ja kuormituksen tasaajan asetuksia.

Jos käytät pinottua etcd-topologiaa, kubeadm konfiguroi sen automaattisesti. Ulkoisten etcd-klusterien tapauksessa sinun on määritettävä etcd erillisille solmuille, luotava suojatut tietoliikennesertifikaatit ja määritettävä jokainen etcd-jäsen tunnistamaan muut. Käytä aina pariton määrä etcd-jäseniä (esim. 3, 5 tai 7) koorumin ylläpitämiseksi virheiden aikana.

Tarkista etcd:n kunto suorittamalla:
sudo kubectl exec -n kube-system etcd- -- etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key päätepisteen terveys
Kaikkien päätepisteiden tulisi raportoida olevan terveitä.

Kuormituksen tasaajille määritä kuntotarkistukset valvomaan /terveys päätepiste kunkin API-palvelimen portissa 6443. Aseta aikaväliksi 10 sekuntia ja 5 sekunnin aikakatkaisuksi ja varmista, että epäterveet palvelimet poistetaan ja lisätään automaattisesti uudelleen, kun ne palautuvat.

Testaa kuormituksen tasaaja pysäyttämällä API-palvelin yhdellä ohjaustason solmulla (sudo systemctl stop kubelet) ja varmista, että kubectl-komennot toimivat edelleen. Käynnistä palvelu uudelleen ja varmista, että solmu liittyy takaisin klusteriin.

Jos käytät useita kuormituksen tasaajia, määritä ne aktiivisesti passiiviseksi asetukseksi tai käytä DNS-vuoropohjaista kuormanjakoa. Dokumentoi vikasietomenettelyt, jotka ohjaavat tiimiäsi kuormituksen tasaajan ongelmien käsittelyssä.

Työsolmujen lisääminen ja klusterin kunnon testaaminen

Työsolmut ovat klusterisi selkäranka ja tarjoavat sovellustesi laskentatehon. Niiden lisääminen on yksinkertaista, mutta testaaminen varmistaa klusterin vikasietoisuuden.

Käytä kubeadm-alkuasennuksen aikana annettua työsolmun liityntäkomentoa:
sudo kubeadm join load-balancer-ip:6443 --token --discovery-token-ca-cert-hash sha256:
Jos token on vanhentunut, voit luoda uuden.

Tarkista, että työsolmut ovat liittyneet onnistuneesti suorittamalla:
kubectl hakee solmut
Kaikkien solmujen tulisi näyttää tila "Valmis". Jos solmu pysyy tilassa "EiValmis", tarkista kubeletin lokit seuraavasti:
sudo journalctl -u kubelet -f

Ota käyttöön testisovellus klusterin kunnon varmistamiseksi. Luo esimerkiksi nginx-käyttöönotto useilla replikoilla:
kubectl luo käyttöönoton nginx-test --image=nginx --replicas=5
Tarkista sitten pod-jakauma solmujen välillä:
kubectl hakee podsit -o leveäksi

Simuloi virheitä testataksesi HA-toiminnallisuutta. Ohjaustason solmujen osalta pysäytä kubelet-palvelu yhdellä solmulla ja varmista, että kubectl-komennot toimivat edelleen. Jos sinulla on yli kolme ohjaustason solmua, kokeile pysäyttää kaksi solmua samanaikaisesti – klusterin pitäisi pysyä toiminnassa niin kauan kuin suurin osa solmuista on kunnossa.

Työsolmujen tapauksessa simuloi vikaa eristämällä ja tyhjentämällä solmu:
kubectl-kordoni && kubectl-tyhjennys --ignore-daemonsets --delete-emptydir-data
Tarkkaile, kun Kubernetes ajoittaa podeja uudelleen muihin solmuihin.

Seuraa klusterin komponentteja seuraavasti:
kubectl hakee komponenttien tilat ja kubectl get pods -n kube-system
Kaikkien järjestelmäpakettien tulisi olla käynnissä ja komponenttien tulisi raportoida toimivan hyvin. Jatkuvaan valvontaan voit käyttää työkaluja, kuten Prometheusta, mittareiden seuraamiseen ajan kuluessa.

Älä unohda asettaa etcd- ja varmennevarmuuskopiotTestaa varmuuskopiointi- ja palautusmenettelyjäsi säännöllisesti ei-tuotantoympäristössä varmistaaksesi niiden tehokkuuden.

Kun erittäin käytettävä Kubernetes-klusterisi on toiminnassa ja testattu, olet valmis tukemaan jatkuvia toimintoja ja suorittamaan rutiinihuoltoa luottavaisin mielin.

HA Kubernetes -toimintojen parhaat käytännöt

Korkean käytettävyyden omaavan Kubernetes-klusterin perustaminen on vasta ensimmäinen askel. Jotta se toimisi tehokkaasti ja luotettavasti, sinun on keskityttävä jatkuvaan valvontaan, testaukseen ja toiminnan parhaisiin käytäntöihin. Nämä vaiheet auttavat sinua ylläpitämään suorituskykyä, välttämään käyttökatkoksia ja varmistamaan, että klusterisi pysyy vikasietoisena.

Valvonta ja ylläpito

Tehokas valvonta on korkean käytettävyyden (HA) selkäranka. Käytä työkaluja, kuten Prometheus ja Grafana seurataksesi keskeisiä mittareita, kuten suorittimen käyttöä, muistin kulutusta, verkon viivettä ja etcd:n suorituskykyä. Kiinnitä tarkkaa huomiota etcd:n kuntoon seurantamittarit kuten johtajan valinnat, ehdotusten epäonnistumiset ja levyn I/O-latenssi. Aseta hälytyksiä kriittisille kynnysarvoille – esimerkiksi jos suorittimen käyttö ylittää 80%:n useissa solmuissa tai jos etcd-latenssi ylittää 100 ms, tarvitaan välittömiä toimia. Käytä säännöllisesti etcdctl-päätepisteen tila komennolla varmistaaksesi, että kaikki etcd-jäsenet ovat synkronoituja ja toimivat oikein.

Pidä Kubernetes-komponenttisi ajan tasalla strukturoidun aikataulun mukaisesti. Suunnittele neljännesvuosittaiset päivitykset pienille julkaisuille ja ota ne käyttöön. tietoturvakorjaukset heti kun ne ovat saatavilla. Testaa päivitykset aina testiympäristössä ennen niiden käyttöönottoa tuotantoympäristössä. Käsittele etcd:tä ja Kubernetesia erikseen päivitystä tehdessäsi riskien minimoimiseksi – älä koskaan päivitä molempia samanaikaisesti.

Sertifikaattien hallinta on toinen kriittinen alue. Kubernetes-sertifikaatit vanhenevat yleensä vuoden kuluttua, joten automaattinen uusiminen on välttämätöntä. Käytä työkaluja, kuten kubeadm tai sertifikaattipäällikkö käsitellä uusimisia ja seurata vanhenemispäiviä tarkasti. Testaa uusimisprosessisi kuukausittain välttääksesi vanhentuneiden varmenteiden aiheuttamat odottamattomat käyttökatkokset.

Keskitä lokien yhdistäminen työkaluilla, kuten Fluentd tai Sujuva bittiTämä helpottaa tapahtumien korrelointia solmujen ja komponenttien välillä tapahtumiin reagoinnin aikana. Näiden valvonta- ja ylläpitokäytäntöjen avulla havaitset mahdolliset ongelmat varhaisessa vaiheessa, mikä auttaa turvaamaan klusterisi saatavuuden.

Vikasietoisuuden ja varmuuskopioinnin menettelyjen testaus

Pelkkä valvonta ei riitä – sinun on myös testattava vikasietoisuus- ja varmuuskopiointiprosessisi perusteellisesti. Suorita kuukausittain vikainjektiotestejä simuloidaksesi todellisia vikoja. Esimerkiksi sammuta ohjaustason solmut, luo verkko-osioita tai ylikuormita työsolmuja nähdäksesi, miten järjestelmäsi reagoi. Seuraa kunkin skenaarion palautumisaikoja ja pyri lyhentämään niitä.

Testaa säännöllisesti etcd-varmuuskopiointi- ja palautusmenettelyjä varmistaaksesi tietojen eheyden. Suorita nämä testit erillisessä ympäristössä varmistaaksesi tarkkuuden ja mitataksesi palautukseen kuluvan ajan. Jos palautusprosessisi ylittää palautusaikatavoitteesi (RTO), harkitse nopeampia tallennusratkaisuja tai menettelytapojen virtaviivaistamista. Automatisoi etcd-varmuuskopiot kuuden tunnin välein ja tallenna ne hajautettuihin sijainteihin lisäturvallisuuden takaamiseksi.

Sovellustason vikasietotestaus on yhtä tärkeää. Käytä työkaluja, kuten Kaaosapina tai Lakmus sulkea podeja tai solmuja satunnaisesti toimistoaikoina. Tämä auttaa tunnistamaan, pystyvätkö sovelluksesi käsittelemään virheitä vaikuttamatta käyttäjiin.

Luo yksityiskohtaiset runbookit yleisiä vikatilanteita varten. Näihin tulisi sisältyä vaiheittaiset palautumisohjeet, eskalointiyhteystiedot ja päätöksentekopuut erityyppisille tapahtumille. Päivitä nämä asiakirjat jokaisen tapahtuman jälkeen ja testaa niitä eri tiimin jäsenten kanssa selkeyden ja käytettävyyden varmistamiseksi.

Varmuuskopioiden varmennus on pelkän varmuuskopioiden luomisen laajempaa. Palauta klusterisi tila säännöllisesti erillisissä ympäristöissä ja varmista, että sovellukset toimivat odotetulla tavalla. Testaa sekä klusterin täydellisiä palautuksia että yksittäisten nimiavaruuksien palautuksia valmistautuaksesi erilaisiin katastrofitilanteisiin.

HA-sovellusten suunnittelu

Jotta sovellukset menestyisivät HA-ympäristössä, ne on suunniteltava saatavuus mielessä pitäen. Pod-häiriöbudjetit (PDB:t) auta varmistamaan, että ylläpidon tai skaalauksen aikana on käytettävissä vähimmäismäärä replikoita. Kriittisten palveluiden osalta aseta minSaatavilla tiettyyn kopioiden määrään prosenttiosuuden sijaan.

Käytä affiniteettivastaisia sääntöjä yksittäisten epäonnistumiskohtien estämiseksi. podAntiAffinityVoit levittää replikoita eri solmujen tai saatavuusvyöhykkeiden kesken. Tilatietoisissa sovelluksissa, kuten tietokannoissa, yhdistä affiniteettien esto topologian levitysrajoituksiin työkuormien tasaiseksi jakamiseksi.

Määritä resurssipyynnöt ja -rajoitukset todellisen käyttötiedon perusteella. Tämä varmistaa, että Kubernetes-aikatauluttaja voi tehdä älykkäämpiä sijoittelupäätöksiä ja välttää resurssien kilpailun. Tarkista ja säädä näitä arvoja neljännesvuosittain valvontatietojesi perusteella.

Kuntotarkistuksilla on tärkeä rooli sovelluksen valmiuden ylläpitämisessä. Käytä elävyystarkastuksia reagoimattomien prosessien havaitsemiseen ja valmiustarkastuksia liikenteen reitityksen hallintaan. Hienosäädä aikakatkaisuarvoja tasapainon löytämiseksi – liian aggressiiviset asetukset voivat aiheuttaa tarpeettomia uudelleenkäynnistyksiä, kun taas lievät asetukset voivat antaa epäonnistuneiden podien jatkaa liikenteen vastaanottamista.

Suunnittele sovellukset aina kun mahdollista tilattomiksi. Tallenna istuntotiedot ulkoisiin järjestelmiin, kuten Redis tai tietokantoja muistin sijaan. Tämä mahdollistaa podien uudelleenkäynnistyksen tai skaalautumisen vaikuttamatta käyttäjäistuntoihin. Sovelluksissa, jotka vaativat tilaa, käytä StatefulSets-menetelmiä pysyvien asemien kanssa ja varmista, että tiedot replikoidaan vyöhykkeiden välillä. Nämä strategiat yhdistettynä vikasietoiseen infrastruktuuriin auttavat varmistamaan, että sovelluksesi pysyvät käytettävissä.

Käyttämällä Serverionn infrastruktuuri HA Kubernetesille

Serverionin globaali datakeskusverkko yksinkertaistaa maantieteellistä hajautusta, joka on korkean käytettävyyden avainkomponentti. Ota käyttöön ohjaustason solmut useilla alueilla saavuttaaksesi todellisen redundanssin. Heidän erilliset palvelimensa tarjoavat etcd-klustereille tarvittavan johdonmukaisen suorituskyvyn, kun taas VPS-instanssit tarjoavat kustannustehokasta skaalautuvuutta työsolmuille.

Serverionin dedikoidut palvelimet sopivat ihanteellisesti ohjaustason solmuille, koska ne poistavat "kohinaisen naapurin" vaikutuksen ja varmistavat ennustettavan suorituskyvyn. Organisaatioille, joilla on vaatimustenmukaisuusvaatimuksia tai olemassa olevia laitteistoinvestointeja, Serverionin konesalipalvelut mahdollistavat hybridiarkkitehtuurit. Tämän kokoonpanon avulla voit yhdistää paikallisen infrastruktuurin heidän datakeskuksiinsa, ja sitä tukevat suuren kaistanleveyden yhteydet reaaliaikaista tiedon replikointia ja saumatonta vikasietoisuutta varten.

Serverionin useat datakeskuksen sijainnit tekevät myös katastrofien jälkeisestä palautumisesta vankempaa. Aseta valmiusklustereita eri alueille ja käytä työkaluja, kuten Velero sovellustason varmuuskopioille, jotka voidaan palauttaa klusterien välillä. Heidän DNS-hosting-palvelunsa mahdollistavat automaattisen vikasietoisuuden päivittämällä DNS-tietueita, kun ensisijainen sivusto menee offline-tilaan.

Lisäksi Serverion tarjoaa infrastruktuuritason suojauksen ja SSL-varmennepalvelut sekä ulkoisen että sisäisen liikenteen suojaamiseksi. Heidän palvelimien hallintapalvelunsa hoitavat laitteiston valvonnan, käyttöjärjestelmäpäivitykset ja perustietoturvatehtävät, jolloin tiimisi voi keskittyä Kubernetes-kohtaisiin toimintoihin. Tämä ominaisuuksien yhdistelmä tarjoaa vahvan perustan HA Kubernetes -klusterien ylläpidolle.

Johtopäätös

Jokainen suunnitteluvalinta ja operatiivinen vaihe myötävaikuttaa luotettavan Kubernetes-klusterin luomiseen. Erittäin käytettävissä olevan Kubernetes-ympäristön rakentaminen vaatii huolellista suunnittelua, vankkaa toteutusta ja jatkuvaa ylläpitoa sekä sen joustavuuden että suorituskyvyn ylläpitämiseksi.

Oikean topologian valitseminen ja luotettavan kuormituksen tasaajan asentaminen takaavat keskeytymättömän API-käytön. Monille organisaatioille pinottu ohjaustasomalli löytää hyvän tasapainon yksinkertaisuuden ja luotettavuuden välillä. Työkalut, kuten kubeadm, helpottavat käyttöönottoa ja auttavat hallitsemaan varmenteita tehokkaasti.

Toiminnan menestys riippuu ennakoivasta valvonnasta, säännöllisistä vikasietoharjoituksista ja sovellusten suunnittelusta ominaisuuksilla, kuten Pod-häiriöbudjeteilla ja affiniteettien vastaisilla säännöillä. Nämä toimenpiteet auttavat työkuormia pysymään vakaina infrastruktuurin häiriöiden aikana varmistaen luotettavan suorituskyvyn.

Serverionin globaali infrastruktuuri lisää tähän strategiaan uuden luotettavuuskerroksen. Tarjoamalla maantieteellistä monimuotoisuutta ja vahvoja katastrofien palautusvaihtoehtoja yhdistettynä dedikoituihin palvelimiin ne auttavat ylläpitämään yhdenmukaista ohjaustason suorituskykyä useissa datakeskuksissa.

UKK

Mitä eroa on pinotulla ja ulkoisella etcd-asennuksella Kubernetesissa, ja miten valitsen parhaan kokoonpanon klusterilleni?

Keskeinen ero pinottu ja ulkoinen jne. Määrityksissä on kyse siitä, missä etcd-tietokanta toimii ja miten sitä hallitaan. Pinotussa kokoonpanossa etcd toimii samoilla solmuilla kuin Kubernetesin ohjaustason komponentit. Tämä menetelmä on helpompi toteuttaa ja halvempi, mutta siihen liittyy kompromissi: solmun vikaantuminen voi vaikuttaa sekä ohjaustasoon että etcd:hen ja aiheuttaa mahdollisesti merkittäviä häiriöitä.

Ulkoisessa etcd-topologiassa etcd sijoitetaan erillisille, dedikoiduille koneille. Tämä lähestymistapa parantaa vikasietoisuutta ja suorituskykyä, erityisesti suuremmissa tai tuotantoluokan klustereissa. Se kuitenkin myös monimutkaistaa kokoonpanoa ja jatkuvaa ylläpitoa.

Pienemmissä tai vähemmän kriittisissä Kubernetes-ympäristöissä pinottu kokoonpano täyttää yleensä tarpeet. Mutta suurten tai korkean käytettävyyden omaavien tuotantoklusterien kohdalla ulkoinen etcd on ensisijainen vaihtoehto luotettavuuden ja vakauden ylläpitämiseksi.

Mitkä ovat parhaat käytännöt erittäin käytettävissä olevan Kubernetes-klusterin valvontaan ja ylläpitoon käyttöaikatavoitteiden saavuttamiseksi?

Jotta Kubernetes-klusterisi toimisi sujuvasti ja täyttäisi käyttöaikaodotukset, sinun on valvottava kolmea kriittistä tasoa: infrastruktuuri, alusta, ja sovelluksetTyökalut, kuten Prometheus, voivat auttaa sinua seuraamaan olennaisia mittareita, kun taas Grafana helpottaa datan visualisointia. Kiinnitä erityistä huomiota mittareihin, kuten suorittimen käyttöön, muistin kulutukseen, podin uudelleenkäynnistyksiin ja virhemääriin. Hälytysten asettaminen varmistaa, että voit havaita ja korjata ongelmat nopeasti ennen kuin ne eskaloituvat.

Kun määrität klusteriasi, noudata parhaita käytäntöjä. roolipohjainen pääsynhallinta (RBAC) hallita käyttöoikeuksia tehokkaasti, järjestää resurssit nimiavaruuksiin paremman rakenteen saavuttamiseksi ja ottaa käyttöön useita ohjaustason solmuja kuormituksen tasaajilla vikasietoisuuden parantamiseksi. Säännöllinen päivittäminen uusimpaan Kubernetes-versioon ja ennakoivan ylläpidon aikatauluttaminen ovat yhtä tärkeitä. Nämä toimenpiteet eivät ainoastaan vähennä seisokkiaikaa, vaan myös varmistavat, että klusterisi skaalautuu vastaamaan liiketoimintatarpeitasi.

Miten voin suunnitella sovellukseni korkean käytettävyyden takaamiseksi Kubernetes-klusterissa?

Jotta sovelluksesi toimisivat sujuvasti Kubernetes-klusterissa, aloita määrittämällä useita kopioita sovelluksestasi Kubernetes-käyttöönottojen kautta. Tämä jakaa työmäärää ja varmistaa, että sovelluksesi pystyy käsittelemään pod-virheet keskeytyksettä.

Toinen hyödyllinen työkalu on Pod-häiriöbudjettiTämä ominaisuus auttaa ylläpitämään aktiivisten podien vähimmäismäärän päivitysten tai ylläpidon aikana, mikä vähentää käyttökatkoksia. Voit parantaa luotettavuutta entisestään ottamalla klusterin käyttöön eri yksiköissä. useita vyöhykkeitä tai alueitaTämä kokoonpano suojaa sovelluksiasi paikallisilta käyttökatkoksilta ja tehostaa redundanssia.

Näitä menetelmiä käyttämällä Kubernetes-järjestelmäsi on kestävämpi ja varmistaa vakaan suorituskyvyn myös häiriöiden ilmetessä.

Aiheeseen liittyvät blogikirjoitukset

• Vikasietoinen tallennus suoratoistotiedoille: perusasiat
• Tietokannan virhetestaus: avainvaiheet
• NGINX Config for DevOps: Serverionin temppu nollakäyttöönottoihin
• Kubernetes-työkuormien automaattinen skaalaus