Jaetun Kubernetes PaaS -ohjaustaso

(Ankur Singla) (15. marraskuuta , 2019)

Tekijät : Ankur Singla , Harshad Nakil

Tämä blogi on ensimmäinen blogisarja, joka kattaa eri näkökohdat siitä, mitä meidän tarvitsi rakentamaan ja operoimaan SaaS -palvelu:

  1. Jaetun Kubernetes PaaS -ohjaustaso
  2. (hajautettujen sovellusten maailmanlaajuinen palveluverkko)
  3. (hajautetun infrastruktuurin, sovellusten ja datan tietoturva)
  4. (Hajautettujen klustereiden sovellus- ja verkkoturva)
  5. Havaittavuus globaalisti hajautetulla alustalla
  6. Globaalisti hajautetun alustan toiminnot ja SRE
  7. Golang-palvelukehys hajautetulle mikropalvelulle s

Kuten edellisessä blogissamme kuvailimme, asiakkaamme rakentavat monimutkaisia ​​ja monipuolisia liiketoimintaratkaisuja – kuten älykkäitä valmistus, videoiden rikostekninen käyttö yleiseen turvallisuuteen, algoritmikauppa, telco 5G -verkot – ja siksi meidän on tarjottava jatkuvasti käytössä oleva, kytketty ja luotettava kokemus näille sovelluksille ja niiden loppukäyttäjille.

Koska nämä sovellukset Alustotiimimme piti rakentaa hajautettu ohjaustaso ja PaaS-palvelu useiden useiden vuokralaisten Kubernetes-klustereiden asentamiseksi, suojaamiseksi ja käyttämiseksi. Tämä hajautettu ohjaustaso on tuottanut monia toiminnallisia, skaalaus- ja suorituskykyetuja, jotka katamme -esityksessämme ( videolinkki ) – esim kuinka hallita tuhansia reunamaisia ​​K8-klustereita GitOpsilla – ja myös erillisenä blogiviestinä tulevina viikkoina.

TL; DR (Yhteenveto)

  1. Emme löytäneet yksinkertainen käyttää ratkaisua markkinoilla, joka voi ratkaista useiden sovellusklusterien käyttöönoton, suojaamisen ja käytön ongelman, joka on jaettu pilvipalvelujen tarjoajien, yksityisten pilvien tai useiden reuna-alueiden välillä.
  2. Emme löytäneet vankkaa Kubernetes-jakelu tai PaaS (esim. OpenShift, Cloud Foundry jne.), Jotka tarjosivat kattavan joukon hajautetuille klustereille tarvittavia tietoturva- ja operatiivisia palveluita – esimerkiksi PKI-pohjainen identiteetti, RBAC- ja käyttöoikeuksien hallinta, salaisuudet ja avainten hallinta pilvipalvelujen tarjoajien välillä , usean klusterin palveluverkko, havainnoitavuus- ja tarkastuslokit tai sovellusten ja verkkojen suojaus.
  3. Anthos (Google), Azure Arc (Microsoft) ja Rancher ovat usean klusterin hallinta-asemia ja useiden erilaisten palvelujen pakkauksia. ; Analyysimme mukaan nämä eivät olleet ratkaisseet käyttö-, skaalaus-, tietoturva- ja vuokravaatimuksia, jotka meillä oli sovellus- ja infrastruktuuripalveluille useissa klustereissa.
  4. Meidän oli rakennettava oma hajautettu ohjaustaso hallittu PaaS, joka on rakennettu Kubernetesin päälle. Aloitimme vanilja Kubernetesista ja teimme sitten merkittäviä muutoksia toimittamaan DevOps- ja SRE-tiimiemme tarvitsemia alustapalveluja. Lisäksi meidän oli rakennettava ohjaustaso suurten määrien hajautettujen klustereiden hallitsemiseksi ja monivuokralaisuuden tarjoamiseksi heterogeenisen infrastruktuurin yli (reunassa, verkossa ja useissa pilvipalvelujen tarjoajissa).

Kubernetes sovellusten hallintaan: miksi & miten

Valitsimme Kubernetesin (K8) alustamme ytimeksi hajautettujen sovellusten hallinnassa, koska se tarjoaa monipuoliset toiminnot olematta liian määräävä – antamalla meille joustavuutta innovaatioissa asioissa, joiden uskomme olevan tärkeitä asiakkaillemme. Käytimme tätä perustana palvelun rakentamisen aloittamiselle ja K8: n kasvavan suosion myötä on myös helpompaa löytää kehittäjät ja operaattorit, jotka tuntevat sen.

Siitä huolimatta suuren määrän tuotantoluokan Kubernetes-klustereiden käyttöönotto ja hallinta hybridiympäristössä (useita pilviä, verkon POP: ita ja reunapaikkoja) ei ole kovin helppoa, koska ei ole olemassa ulkopuolisia -box-ratkaisut Kubernetesille, jotka voivat:

  1. Yhdenmukaistaa heterogeeniset infrastruktuuriresurssit automatisoidulla klusteroinnilla, skaalauksella ja nolla-kosketuksella. tämä oli erityisen tuskallista reunalla ja verkko-operaattoreissamme.
  2. Tarjoa suorituskykyinen ja luotettava yhteys eri paikoissa – etenkin ylittäessäsi pilvipalvelujen tarjoajia ja tultaessa reuna-alueilta. tiedonsiirron, levossa olevan tiedon, salaisuuksien, avainten ja verkon ongelma … kaikki tukena yhtenäisellä PKI-identiteetillä, joka toimii reunojen, verkon ja pilvien yli
  3. Tarjoa todellinen monivuokraisuus – vuokralaisten eristäminen ja tietoturvatakuut – kyky suorittaa tuotanto- ja kehitystyömäärät sisäisiin ja asiakkaiden tarpeisiin samoissa klustereissa
  4. Tarjoa havaittavuus ja toiminnot hajautettujen klustereiden kesken, jotka yhdistyvät keskitettyyn politiikkaan ja tarkoitukseen ilman monimutkaisten rakennusten tarvetta lokien ja mittareiden kerääminen

Useiden konseptien jälkeen useiden pilvipalvelujen tarjoajien ja avoimen lähdekoodin alustojen, kuten GKE, AKS, EKS ja RKE sekä OpenShift ja Cloud Foundry – tajusimme että kukaan heistä ei voinut tavata kaikkia elokuvia Ve vaatimukset edellä. Tämän seurauksena päätimme rakentaa oman PaaS-palvelumme – alkaen vanilja-Kubernetesista ja tekemällä useita lisäyksiä – identiteettiin, verkostoitumiseen, tietoturvaan, monivuokralaisuuteen, puunkorjuuseen, mittareihin jne. Vaikka käytämme Kubernetesia sisäisten tarpeidemme täyttämiseen, meidän oli tehtävä joitain vaikeita päätöksiä, kuten jättää nämä Kubernetes-klusterit paljastamatta suoraan sisäisille käyttäjillemme ja / tai asiakkaillemme heidän kuormituksensa ajamiseksi (tarkemmin siitä myöhemmin, koska monivuokraus oli meille keskeinen tavoite).

Useiden uusien ominaisuuksien lisäksi, jotka meidän oli lisättävä, oli myös tarpeen suorittaa työmäärämme / palvelumme yhdessä asiakkaiden kuormitusten kanssa monissa paikoissa reunan toisella puolella, verkostossamme ja julkisissa / yksityisissä pilvissä. Tämä tarkoitti sitä, että meidän piti rakentaa lisäominaisuuksia hallita useita klustereita useissa ympäristöissä … kaikki yhdistettynä maailmanlaajuisen verkon ja hajautettujen sovellusyhdyskäytävien avulla, jotta voimme tarjota nolla luottamuksen ja sovellustason yhteyden näihin klustereihin.

Kova osa: Monivuokraus- ja moniklusteri Kubernetesille

Yhdessä Kubernetes-klusterissa toimivien sovellusten rakentaminen ja käyttäminen ei ole vähäpätöinen tehtävä, vaikka kuluttaisitkin pilvipalvelujen tarjoajan hallitsemaa klusteria. Siksi on yleistä, että DevOps- ja SRE-ryhmät minimoivat yleiskustannuksensa eivätkä käsittele monien klustereiden monimutkaisuutta. On melko tavallista nähdä joukkueiden rakentavan yhden suuren Kubernetes-klusterin ja sijoittavan kaiken tyyppiset resurssit samaan klusteriin. Vaikka tämä näyttää hyvältä, koska ne voivat yksinkertaistaa toimintaa ja käyttää klusteria parhaan laskentatehokkuuden ja kustannusten saavuttamiseksi, tämä ei ole paras idea useista syistä. Ensinnäkin tuotantokuormitusten tarpeet eroavat suuresti dev-testistä ja vaiheistuksesta – epävakaat kehityskuormitukset voivat aiheuttaa ongelmia vakaammalle tuotantokuormitukselle.

Eri työmäärien tarpeiden lisäksi K8: n turvallisuus ja eristysrajoitukset ovat toinen ohjain moniklusterille. Tyypillinen lähestymistapa K8: n tietoturvan ja resurssien eristämisen ratkaisemiseen on itsenäisten klustereiden yhdistäminen kullekin vuokralaiselle käyttämällä usean vuokralaisen mallia. Vaikka tämä voi olla mahdollista tehdä pilvessä, reunalla ei ole mahdollista suorittaa useita klustereita. Edge-sivustoilla on laskenta- ja tallennusresurssirajoitukset ja rajoitettu verkon kaistanleveys, jotta lokit ja mittarit voidaan lähettää jokaisesta lisäklusterista keskuspilvelle.

Useiden Kubernetes-klustereiden ongelman ratkaisemiseksi arvioimme Rancherin keskitetystä Kubernetes-klusterimme (kun aloitimme, Anthos ja Azure Arc eivät olleet olemassa) ja KubeFed. Kaksi tuolloin käytettävissä olevaa lähestymistapaa olivat (ja sama tilanne on nykyäänkin):

  1. Usean klusterin hallinta (esim. Rancher) keskuskonsolista olisi antanut meille mahdollisuuden ottaa käyttöön useita klustereita missä tahansa paikassa ja suorittaa elinkaaren hallinnan toimintoja, kuten päivitykset, palautus jne. Jotkut näistä järjestelmistä antoivat myös mahdollisuuden kohdistaa yksittäinen klusteri automatisoimalla sovellusten konfigurointia ja käyttöönottoa varten.
  2. Toinen tapa on ottaa Kubernetes käyttöön klusterin federaation (KubeFed) ohjaustaso ja se voi saada useita fyysisiä klustereita näyttämään yhdeltä klusterilta. Tämä projekti oli vasta alkamassa tuolloin, kun katselimme, ja tänäänkin se on vasta alfa-vaiheessa.

GCP Anthosin ja Azure Arcin äskettäisen ilmoituksen jälkeen arvioimme uudelleen alkuperäisen päätöksemme rakentaa hajautettu ohjaustaso ja johtopäätös oli, että edes nämä kaksi uutta tarjontaa eivät olisi voineet ratkaista kahta kriittistä ongelmaa hajautettujen klustereiden kanssa.Nämä kaksi keskeistä ominaisuutta, joita tarvitsimme alustallemme, olivat:

  1. Useiden klustereiden hallinta kalustona, jotta voidaan ratkaista toimintojen suorittaminen kaikissa klustereissa tai loogisessa ryhmässä – toiminnot, kuten kokoonpano, käyttöönotto, mittarit jne. Tämä on kriittistä, koska haluamme vähentää SRE-tiimiemme toimintakustannuksia, parantaa DevOps-ohjelmistojemme virheenkorjauskykyä ja parantaa järjestelmän skaalautuvuutta
  2. Kyky yksilöidä fyysinen fyysinen Kubernetes-klusteri monivuokraukseen tarvitsematta kehittää fyysisiä klustereita – tämä on erityisen kriittistä resurssirajoitteisissa ympäristöissä, joissa emme halua lisätä uusia fyysisiä klustereita vain monivuokraukseen

Näiden kahden ongelman ratkaisemiseksi meidän oli keksittävä uusi tekniikka – hajautettu ohjaustaso – ratkaistaksemme ”Useita” klustereita ja tarjoavat vastaavan ”useita klustereita” monivuokralle resurssirajoituksissa d ympäristöissä.

Hajautettu ohjaustaso: Kuinka saavutimme usean klusterin Kubernetes

Alustatiimimme päätti rakentaa Kubernetesille hajautetun ohjaustason, joka paljastaa kuitenkin Kubernetes-sovellusliittymät tiimimme käyttöön. , nämä sovellusliittymät ovat peräisin virtuaalisista klustereista, jotka ovat olemassa vain ohjaustasossa – virtuaalisista K8s (vK8s) -sovelluspalvelimista virtuaalisille K8s-klustereille (kuten kuvassa 1 ). Tämä ohjaustaso kartoittaa käyttäjän aikomuksen useisiin fyysisiin Kubernetes-klustereihin, jotka kulkevat reunassamme, verkon POP: eissa ja julkisissa pilvipalveluissa. Näihin fyysisiin klustereihin pääsee vain hajautetulle ohjaustasolle, eivätkä kukaan yksittäinen vuokralainen / käyttäjä.

Kuva 1: Hajautettu ohjaustaso

Tämä ohjaustaso tarjoaa jokaiselle vuokralaiselle yhden tai useampia ”virtuaalisia” sovellusklustereita, joihin he voivat ottaa käyttöön sovelluksensa ) ja kokoonpanon perusteella ohjaustaso replikoi ja hallitsee sitä useissa fyysisissä Kubernetes-klustereissa. Konfigurointi- ja käyttöönottotoimintojen lisäksi seurantatoimet seuraavat myös tätä ”virtuaalista” klusteria ilman tarvetta rakentaa työkaluja tietojen keräämiseksi ja jakamiseksi useista fyysisistä klustereista.

Otetaan esimerkki käyttöliittymäsovelluksesta nimeltä productpage, missä käyttäjän tarkoitus on suorittaa se jaettuna 3 sijaintiin – pa2-par, ny8-nyc ja ams9-ams, joissa kummassakin on 2 kopiota. Kun käyttäjä luo vK8s-objektin ja liittää sen virtuaaliseen klusteriin, joka heti huolehtii vK8s API -palvelimesta, jota voidaan käyttää tavallisen kubectlin kanssa.

Seuraavassa vaiheessa käyttäjä lataa kubeconfigin tälle virtuaalille. klusteri ja luo tavallisen yaml: n kuvaamaan tuotesivun K8s-käyttöönottoa.

Käyttöönoton määrityksen luomisen jälkeen , käyttäjä voi jatkaa käyttöönoton luomista tälle virtuaaliselle klusterille:

Jos käyttäjä tarkistaa hänen käyttöönoton hän näkee 6 kopiota on aloitettu kahdella kussakin paikassa (pa2-par, ny8-nyc ja ams9-ams).

Seuraava tulos näyttää 2 podia, jotka kulkevat kussakin paikassa ja kartoitetaan tiettyyn fyysiseen solmuun.

Tämä yksinkertainen esimerkki osoittaa, kuinka triviaalia on saada minkä tahansa sovelluksen usean klusterin replikointi minuutissa ilman asennusta ja hallintaa. Tarkoituksen kartoituksen lisäksi hajautettu ohjaustaso tarjoaa havaittavuuden myös virtuaaliselle klusterille eikä yksittäisille klustereille.

Hajautettu hallinta ja keskitetty hallinta monivuokraukselle

Kuten näet kuvassa 2 , keskitetty hallintatasomme kulkee kahden julkisen pilvipalvelun tarjoajan (yksi alue kumpikin) – yksi sisään AWS ja yksi Azuressa (redundanssia varten). Tämän hallintatason avulla SRE voi luoda vuokralaisia, joilla on vaikea monivuokraus – esim. VoltMesh-palvelullamme työskentelevä kehitystiimi voi olla vuokralainen ja asiakasratkaisutiimi, joka työskentelee asiakkaiden POC-palvelujen parissa, voi olla oma vuokralainen omilla käyttäjäryhmillään.

Kuva 2: Monivuokraus- ja moniklusteri

Jokainen näistä vuokralaisista voi luoda monia nimiavaruudet ja määritä käyttäjäryhmä tekemään yhteistyötä näiden nimiavaruuksien kanssa. Nämä nimitilat eivät ole Kubernetes-nimitiloja – ne ovat alustamme eristysraja, jossa on RBAC-sääntöjä ja IAM-käytäntöjä käyttäjille.

Kun nimitilan käyttäjä haluaa luoda sovellusklusterin, hän luo vK8s-objektin ja Tämä vuorostaan ​​luo vK8s-API-palvelimen hallintatasoon.Tämän vK8s-objektin avulla käyttäjä voi luoda käyttöönottoja, tilakokonaisuuksia, PVC: itä jne., Ja ohjaustaso varmistaa, että nämä toiminnot tapahtuvat yhdessä tai useammassa fyysisessä klusterissa vK8s-objektiin liittyvien sivustojen perusteella.

Koska jokainen vuokralainen ja käyttäjä käyttää tavanomaisia ​​K8s-toimintoja ilman muutoksia, se antaa järjestelmän olla yhteensopiva useiden käyttäjien kanssa suosittujen työkalujen kanssa – esim. Spinnaker, Helm, Jenkins jne.

Hajautetulta ohjaustasolta saadut voitot

Hajautetun ohjaustason suuri etu on, että se on ratkaissut SRE: n ja DevOps: n operatiiviset kustannukset joukkueet. He voivat nyt suorittaa toimintoja (kokoonpano, käyttöönotto, seuranta, käytäntö jne.) Virtuaaliryhmässä ja ohjaustaso kartoittaa sen automaattisesti useisiin fyysisiin klustereihin. Useiden klustereiden toiminnan yksinkertaistamisen lisäksi ohjaustaso on ratkaissut monivuokrauksen turvallisuus- ja eristysongelman.

Tämä hajautettu ohjaustaso on parantanut myös kehittäjien tuottavuutta, jotka haluavat lisätä uusia ominaisuuksia alustamme – heidän ei tarvitse rakentaa uutta automaatiota joka kerta, kun lisätään uusia ominaisuuksia, jotka vaikuttavat kokoonpanoon tai toimintoihin useissa klustereissa. He käyttävät tarkoitukseen perustuvaa kokoonpanomallia ja ohjaustaso tietää, mitä on tehtävä. Lisäksi he voivat jatkaa vuorovaikutusta tämän hajautetun ja useiden klusterikohteiden – virtuaalisten kubernetien – kanssa käyttämällä kubectlia eikä muuta CLI: tä.

Suoritettuaan tämän dev-testi-, lavastus- ja tuotantoympäristöissämme lisää Yli vuosi nyt tajusimme, että tämä maailmanlaajuisesti hajautettu ohjaustaso (joka toimii POP-verkkoissamme) tarjoaa myös merkittäviä mittakaavan, suorituskyvyn ja luotettavuuden etuja – mitä emme olleet aivan kuvitelleet alkuaikoina. Esittelemme tämän havainnon tulevassa KubeCon-esityksessämme ja erillisenä blogiviestinä tulevina viikkoina.

Jatkuu …

Tämä blogisarja kattaa useita näkökohtia Rakensimme ja käytimme maailmanlaajuisesti hajautettua SaaS-palvelua, jossa oli monia sovellusklustereita julkisessa pilvessä, yksityisen verkon palveluntarjoajissamme ja reunasivustoissa. Seuraavaksi on (Global Service Mesh for Distributed Apps)…