Sovellus toimii. Sitten tulee päivitys, palvelin vikaantuu tai useat osastot tarvitsevat samaan aikaan lisää kapasiteettia. Kubernetes järjestää, missä kontit suoritetaan ja miten sovittu toimintatila palautetaan. Parantaako se sovelluksen luotettavuutta, riippuu koko arkkitehtuurista.
Esimerkkinä on sisäinen tilausportaali: työntekijät kirjaavat tilauksia, rajapinta siirtää ne varastonhallintaan ja taustaprosessi luo asiakirjoja. Erilliset kontit voivat hoitaa nämä tehtävät. Jos ne käynnistetään yksitellen, myös päivitykset, uudelleenkäynnistykset ja sijoittelu koneille on koordinoitava. Tässä orkestrointi auttaa.
Tavoitetilasta tulee ylläpidon perusta
Kubernetesissa voidaan esimerkiksi määrittää, että verkkosovelluksesta on oltava käynnissä kaksi tiettyä ohjelmistoversiota käyttävää instanssia. Alusta vertaa tavoitetilaa jatkuvasti toteutuneeseen tilaan. Deployment kuvaa sovelluksen käyttöönoton ja hallitsee Podeja ReplicaSet-ohjaimen avulla. Jos instanssi puuttuu, ohjaus pyrkii käynnistämään korvaavan instanssin.
Tästä on hyötyä myös päivityksissä: uusi versio voidaan ottaa käyttöön vaiheittain. Resurssien, käynnistymiskäyttäytymisen ja valitun päivitystavan on tuettava sitä. Teknisesti onnistunut käyttöönotto ei osoita, onko tilaus käsitelty oikein. Tämä tarkistus kuuluu edelleen sovellukseen ja sen testeihin.
Keskeiset käsitteet tilausportaalin avulla
- Konttikuva
- Sovelluksen paketoitu perusta, joka sisältää tarvittavat tiedostot ja suoritusympäristön osat. Tästä kuvasta käynnistetään suoritettavat kontit.
- Pod
- Kubernetesin pienin käyttöönotettava yksikkö. Se sisältää tavallisesti yhden sovelluskontin; läheisesti toisiinsa liittyvät kontit voivat jakaa Podin ja esimerkiksi sen verkon nimiavaruuden. Kaksi verkkosovelluksen kopiota tarkoittaa yleensä kahta Podia.
- Solmu eli Node
- Kone, joka suorittaa Podeja. Solmu voi olla virtuaalikone tai fyysinen palvelin. Kubernetes voi siis täydentää virtualisointikerrosta eikä välttämättä korvaa sitä.
- Klusteri ja ohjaustaso
- Klusteri yhdistää ohjauksen ja työkuormia suorittavat solmut. Ohjaustasoon kuuluvat esimerkiksi API-palvelin, tilatietokanta, ajastin ja ohjaimet. Solmuilla kubelet ja konttien suoritusympäristö huolehtivat suorituksesta.
- Service
- Vakaa looginen yhteyspiste Pod-joukolle. Podien osoitteet voivat vaihtua, kun ne korvataan. Service erottaa yhteyden yksittäisistä lyhytikäisistä instansseista.
Mitä vikatilanteessa todella tapahtuu
Jos solmu vikaantuu, hallitut Podit voidaan ottaa uudelleen käyttöön muilla sopivilla solmuilla. Tämä edellyttää vian havaitsemista, riittävää varakapasiteettia ja pääsyä tarvittaviin tietoihin. Toinen instanssi samalla fyysisellä isäntäkoneella ei suojaa sen koneen vikaantumiselta. Myös useat samaan sähkö- tai verkkoympäristöön kuuluvat palvelimet voivat jakaa yhteisen vikakohdan.
Tilausportaalissa tämä tarkoittaa, että verkkokäyttöliittymä voidaan ehkä korvata nopeasti. Jo käynnistynyt asiakirjatehtävä on kuitenkin suunniteltava niin, ettei sen toistaminen luo päällekkäistä laskua tai tilausta. Istunnot eivät saa kadota hallitsemattomasti, kun instanssi korvataan. Nämä ominaisuudet riippuvat ohjelmistoarkkitehtuurista ja siihen liitetyistä järjestelmistä.
Kolme palvelinta ei siis yksin ole käytettävyyssuunnitelma. Ohjaus, sovellukset, verkko, tallennus ja vian jälkeen jäljelle jäävä kapasiteetti on tarkasteltava yhdessä. Sama koskee pilveä ja hallittua Kubernetes-palvelua: todellinen palvelulaajuus ratkaisee, mitkä vastuut kuuluvat tarjoajalle ja mitkä jäävät yritykselle.
Pysyvät tiedot tarvitsevat oman suunnitelman
Podit ovat korvattavia. Yritystiedot eivät siksi saa olla ainoastaan kontin kirjoitettavassa tiedostojärjestelmässä. Kubernetes voi liittää pysyvää tallennustilaa Persistent Volume -resurssien ja niihin liittyvien Persistent Volume Claim -varausten avulla. StorageClass kuvaa, miten sopiva tallennustila voidaan järjestää.
Nämä objektit eivät tee taustalla olevasta tallennuksesta automaattisesti vikasietoista. Paikallinen levy on edelleen sidoksissa infrastruktuuriinsa; ulkoisella tallennuspalvelulla on omat suorituskyky- ja vikaominaisuutensa. Myös klusterin ulkopuolinen tietokanta voi olla oikea ratkaisu. Ratkaisevia ovat sovellustuki, tietojen eheys, yhteysreitit ja sovittu palautusmenettely.
Portaalille määritetään siksi erikseen, kuinka kauan se saa olla poissa käytöstä, millainen tietohävikki hyväksytään ja miten palautus testataan. Klusteri, joka välittää tahattoman poiston luotettavasti jokaiseen instanssiin, ei korvaa varmuuskopiota. Lue lisää aiheesta varmuuskopiointi ja palautus.
Milloin lisäkokoonpano kannattaa
Kubernetes on kiinnostava, kun useita sovelluksia päivitetään säännöllisesti, tarvitaan toistettavaa käyttöönottoa tai työkuormat ja käytettävissä olevat koneet halutaan kohdentaa hallitusti. Samalla syntyy tehtäviä alustan päivityksiin, käyttöoikeuksien hallintaan, verkkoon, tallennukseen ja valvontaan.
Yhdelle vakaalle sovellukselle hyvin ylläpidetty Docker Compose -palvelin tai tavallinen virtuaalikone voi olla taloudellisesti sopivampi. Päätöksen on lähdettävä vaaditusta toiminnasta: millaiset katkokset hyväksytään? Kuinka usein muutoksia tehdään? Kuka ymmärtää ympäristön ja osaa palauttaa sen, jos jokin menee vikaan?
Hyödyllisellä pilotilla on todennettavat tavoitteet
- Testaa edustava liiketoimintaprosessi realistisilla tietomäärillä ilman asiakkaiden tuotantotietoja.
- Harjoittele päivitys ja suunniteltu paluureitti. Arvioi tietokantaskeeman muutokset erikseen.
- Testaa hallitusti yhden instanssin ja yhden suunnitellun infrastruktuurikomponentin vikaantuminen.
- Palauta varmuuskopio erilliseen testiympäristöön ja avaa tiedot varmistaaksesi niiden käyttökelpoisuuden.
- Nimeä vastuuhenkilöt hälytyksille, alustan ylläpidolle ja sovellukselle.
DAXS auttaa arvioimaan sovelluksen ja valitsemaan sopivan infrastruktuurin sekä hoitaa toteutuksen ja sovitun ylläpidon. Ensimmäinen arvio konkreettisesta käyttötapauksesta ja selkeät hyväksymiskriteerit ovat käytännöllinen aloitus.
Lähteet: Kubernetes: alustan tehtävä ja rajat · Klusterin komponentit · Podit ja niiden elinkaari · Deploymentit ja päivitykset · Service-resurssit · Pysyvä tallennus · Tuotantoympäristöjen suunnittelu
