Hei Habr!
Edustamme Exnessin alustatiimiä. Aiemmin kollegamme ovat jo kirjoittaneet artikkelin aiheesta . Tänään haluamme jakaa kokemuksemme palveluiden siirtämisestä Kubernetesiin.
Aluksi tarjoamme sinulle joitain numeroita, jotta ymmärrät paremmin, mistä keskustellaan:
- Kehitysosastollamme on yli 100 henkilöä, mukaan lukien yli 10 erilaista tiimiä, joilla on omavaraiset laadunvarmistus-, DevOps- ja Scrum-prosessit. Kehityspino - Python, PHP, C++, Java ja Golang.
- Testaus- ja tuotantoympäristöjen koko on noin 2000 konttia. Heillä on käytössä Rancher v1.6 omassa virtualisoinnissaan ja VMwaren alla.
Motivaatio
Kuten sanotaan, mikään ei kestä ikuisesti, ja Rancher ilmoitti version 1.6 tuen lopettamisesta jo kauan sitten. Kyllä, yli kolmessa vuodessa olemme oppineet valmistautumaan siihen ja ratkaisemaan nousevia ongelmia, mutta yhä useammin kohtaamme ongelmia, joita ei koskaan korjata. Rancher 1.6:ssa on myös luutunut oikeuksien myöntämisjärjestelmä, jossa voit joko tehdä melkein kaiken tai ei mitään.
Vaikka patentoitu virtualisointi lisäsi tietojen tallennusta ja sen turvallisuutta, se aiheutti käyttökustannuksia, joita oli vaikea hyväksyä yrityksen jatkuvan kasvun, projektien määrän ja niille asetettujen vaatimusten vuoksi.
Halusimme noudattaa IaC-standardeja ja tarvittaessa saada kapasiteettia nopeasti, missä tahansa maantieteellisessä paikassa ja ilman toimittajalukkoa ja myös pystyä luopumaan siitä nopeasti.
Ensiaskeleet
Ensinnäkin halusimme luottaa nykyaikaisiin teknologioihin ja ratkaisuihin, jotka mahdollistaisivat tiimeille nopeamman kehityssyklin ja minimoivat käyttökustannukset vuorovaikutuksessa tehoa tarjoavan alustan kanssa.
Tietysti ensimmäisenä mieleemme tuli Kubernetes, mutta emme innostuneet ja teimme vähän tutkimusta nähdäksemme, oliko se oikea valinta. Arvioimme vain avoimen lähdekoodin ratkaisuja, ja epäreilussa taistelussa Kubernetes voitti ehdoitta.
Seuraavaksi tuli kysymys työkalun valitsemisesta klustereiden luomiseen. Vertasimme suosituimpia ratkaisuja: kops, kubespray, kubeadm.
Aluksi kubeadm vaikutti meistä liian monimutkaiselta tieltä, pikemminkin eräänlaiselta "pyörän" keksijältä, eikä kopsilla ollut tarpeeksi joustavuutta.
Ja voittaja oli:
Aloimme kokeilla omaa virtualisointiamme ja AWS:äämme yrittääksemme luoda uudelleen jotain, joka on suunnilleen samanlainen kuin aikaisempi resurssienhallintamallimme, jossa kaikilla oli sama "klusteri". Ja nyt meillä on ensimmäinen 10 pienen virtuaalikoneen klusteri, joista pari sijaitsee AWS:ssä. Aloimme yrittää siirtää tiimejä sinne, kaikki näytti olevan "hyvää" ja tarina voisi olla valmis, mutta...
Ensimmäiset ongelmat
Ansible on se, jolle kubespray on rakennettu, se ei ole työkalu, jolla voit seurata IaC:tä: solmujen käyttöönotossa/poistossa jotain meni jatkuvasti pieleen ja vaadittiin jonkinlaista interventiota, ja eri käyttöjärjestelmiä käytettäessä pelikirja käyttäytyi eri tavalla. eri tavalla . Kun klusterin tiimien ja solmujen määrä kasvoi, aloimme huomata, että pelikirjan valmistuminen kesti yhä kauemmin, ja sen seurauksena ennätyksemme oli 3,5 tuntia, entä sinun? 🙂
Ja näyttää siltä, että kubespray on vain Ansible, ja kaikki on selvää ensi silmäyksellä, mutta:
Matkan alussa tehtävänä oli käynnistää kapasiteettia vain AWS:ssä ja virtualisoinnissa, mutta sitten, kuten usein tapahtuu, vaatimukset muuttuivat.
Tämän valossa kävi selväksi, että vanha mallimme yhdistää resursseja yhdeksi orkestrointijärjestelmäksi ei ollut sopiva - siinä tapauksessa, että klusterit ovat hyvin etäisiä ja niitä hallinnoivat eri toimittajat.
Edelleen lisää. Kun kaikki tiimit työskentelevät samassa klusterissa, erilaiset palvelut väärin asennettujen NodeSelectorien kanssa saattoivat lentää toisen tiimin "vieraalle" isännälle ja hyödyntää siellä resursseja, ja jos pilaantui, tuli jatkuvasti pyyntöjä, että jokin palvelu ei toimi, ei jaettu oikein inhimillisen tekijän vuoksi. Toinen ongelma oli kustannusten laskeminen, erityisesti kun otetaan huomioon ongelmat palveluiden jakamisessa solmujen välillä.
Erillinen tarina oli oikeuksien myöntäminen työntekijöille: jokainen tiimi halusi olla klusterin "päässä" ja hallita sitä kokonaan, mikä saattoi aiheuttaa täydellisen romahduksen, koska tiimit ovat periaatteessa toisistaan riippumattomia.
Mitä tehdä?
Ottaen huomioon edellä mainitut ja joukkueiden toiveet olla itsenäisempiä, teimme yksinkertaisen johtopäätöksen: yksi joukkue - yksi klusteri.
Joten saimme toisen:
Ja sitten kolmas klusteri:
Sitten aloimme miettiä: sanotaanko, että vuoden päästä joukkueillamme on enemmän kuin yksi klusteri? Esimerkiksi eri maantieteellisillä alueilla vai eri palveluntarjoajien hallinnassa? Ja jotkut heistä haluavat pystyä ottamaan nopeasti käyttöön väliaikaisen klusterin joitain testejä varten.
Täysi Kubernetes tulisi! Tämä on jonkinlainen MultiKubernetes, käy ilmi.
Samanaikaisesti meidän kaikkien on jotenkin ylläpidettävä kaikkia näitä klustereita, pystyttävä helposti hallitsemaan niihin pääsyä sekä luomaan uusia ja poistamaan vanhoja käytöstä ilman manuaalista puuttumista.
Matkamme alusta Kubernetes-maailmassa on kulunut jonkin aikaa, ja päätimme tarkastella käytettävissä olevia ratkaisuja uudelleen. Kävi ilmi, että se on jo markkinoilla - Rancher 2.2.
Tutkimuksemme ensimmäisessä vaiheessa Rancher Labs oli jo julkaissut ensimmäisen version 2:sta, mutta vaikka se saatiin nostettua erittäin nopeasti käynnistämällä kontti ilman ulkoisia riippuvuuksia parilla parametrilla tai käyttämällä virallista HELM-kaaviota, se vaikutti karkealta. meille, emmekä tienneet, voimmeko luottaa tähän päätökseen, kehitetäänkö se vai hylätäänkö se nopeasti. Cluster = clicks -paradigma itse käyttöliittymässä ei myöskään sopinut meille, emmekä halunneet sitoutua RKE:hen, koska se on melko kapea-alainen työkalu.
Versio Rancher 2.2 oli jo toimivampi ulkoasu, ja siinä oli yhdessä aiempien kanssa joukon mielenkiintoisia ominaisuuksia, kuten integrointi useiden ulkoisten palveluntarjoajien kanssa, yksi oikeuksien ja kubeconfig-tiedostojen jakelupiste, kubectl:n käynnistäminen kuva oikeuksillasi käyttöliittymässä, sisäkkäiset nimitilat eli projektit.
Rancher 2:n ympärille oli myös jo muodostunut yhteisö, ja sitä hallinnoimaan luotiin HashiCorp Terraform -niminen palveluntarjoaja, joka auttoi meitä yhdistämään kaiken.
Mitä tapahtui
Lopputuloksena päädyimme yhteen pieneen klusteriin, joka käytti Rancheria, joka on kaikkien muiden klustereiden käytettävissä, samoin kuin monet siihen liittyvät klusterit. Pääsy mihin tahansa voidaan myöntää yksinkertaisesti lisäämällä käyttäjä ldap-hakemistoon riippumatta missä se sijaitsee ja minkä palveluntarjoajan resursseja se käyttää.
Gitlab-ci:n ja Terraformin avulla luotiin järjestelmä, jonka avulla voit luoda klusterin mistä tahansa konfiguraatiosta pilvipalveluntarjoajissa tai omassa infrastruktuurissamme ja yhdistää ne Rancheriin. Kaikki tämä tehdään IaC-tyylillä, jossa jokainen klusteri kuvataan arkistolla ja sen tila on versioitu. Samanaikaisesti useimmat moduulit yhdistetään ulkoisista arkistoista, joten jäljellä on vain muuttujien välittäminen tai mukautetun konfiguraation kuvaaminen instansseille, mikä auttaa vähentämään koodin toiston prosenttiosuutta.
Tietenkään matkamme ei ole vielä kaukana ja edessä on vielä monia mielenkiintoisia tehtäviä, kuten yksi työpiste minkä tahansa klusterin lokien ja mittareiden kanssa, palveluverkko, gitopit kuormien hallintaan moniklusterissa ja paljon muuta. Toivomme, että kokemuksemme on kiinnostava!
Artikkelin ovat kirjoittaneet A. Antipov, A. Ganush, Platform Engineers.
Lähde: will.com