A nevem Viktor Yagofarov, és a Kubernetes platformot fejlesztem a DomClicknél, mint műszaki fejlesztési vezető az Ops (operation) csapatban. Szeretnék beszélni a Dev <-> Ops folyamataink felépítéséről, az egyik legnagyobb oroszországi k8s-klaszter működésének jellemzőiről, valamint a csapatunk által alkalmazott DevOps/SRE gyakorlatokról.
Ops Team
Az Ops csapata jelenleg 15 főből áll. Közülük hárman az irodáért felelősek, ketten más időzónában dolgoznak, és éjjel is elérhetők. Így valaki az Ops-tól mindig a monitor mellett áll, és készen áll arra, hogy reagáljon bármilyen bonyolult eseményre. Nálunk nincs éjszakai műszak, ami megőrzi lelkivilágunkat, és mindenkinek lehetőséget ad arra, hogy eleget aludjon és ne csak a számítógép előtt töltse a szabadidejét.
Mindenkinek más a kompetenciája: hálózatépítők, DBA-k, ELK verem specialisták, Kubernetes adminok/fejlesztők, monitorozás, virtualizáció, hardver specialisták stb. Egy dolog egyesít mindenkit – mindenki bármelyikünket helyettesítheti bizonyos mértékig: például új csomópontokat bevezetni a k8s klaszterbe, frissíteni a PostgreSQL-t, írni CI/CD + Ansible folyamatot, automatizálni valamit Python/Bash/Go-ban, hardvert csatlakoztatni Adatközpont. Bármely területen megszerzett erős kompetenciák nem akadályozzák meg abban, hogy tevékenységi irányát változtasd, és más területen kezdj el fejlődni. Például PostgreSQL-szakértőként csatlakoztam egy céghez, és most a fő felelősségi területem a Kubernetes-fürtök. A csapatban bármilyen magasságot szívesen látunk, és az áttételérzék nagyon fejlett.
Egyébként vadászunk. A jelöltekkel szemben támasztott követelmények meglehetősen általánosak. Számomra személy szerint fontos, hogy az ember beilleszkedjen a csapatba, konfliktusmentes legyen, de tudja is megvédeni a nézőpontját, akarjon fejlődni és ne féljen újat csinálni, felajánlja ötleteit. Emellett szükséges a script nyelvek programozási ismerete, a Linux és az angol nyelv alapjainak ismerete. Az angol egyszerűen azért kell, hogy fakap esetén az ember 10 másodperc alatt tudjon megoldást találni a google-ban, és ne 10 perc alatt. Ma már nagyon nehéz olyan szakembereket találni, akik mélyen ismerik a Linuxot: ez vicces, de háromból kettő nem tud válaszolni a „Mi az átlagos terhelés? Miből van?”, és a „Hogyan állítsunk össze egy core dump-ot egy C programból” kérdés a szupermenek... vagy a dinoszauruszok világából való. Ezt el kell tűrnünk, hiszen általában az emberek magasan fejlett egyéb kompetenciákkal rendelkeznek, de mi megtanítjuk a Linuxot. A „miért kell mindezt egy DevOps mérnöknek tudnia a felhők modern világában” kérdésre a választ a cikk keretein kívül kell hagyni, de három szóval: minderre szükség van.
Csapateszközök
Az Eszközök csapata jelentős szerepet játszik az automatizálásban. Fő feladatuk kényelmes grafikus és CLI eszközök létrehozása a fejlesztők számára. Például a belső fejlesztési Confer lehetővé teszi, hogy néhány egérkattintással szó szerint kiterjesszen egy alkalmazást a Kubernetesre, konfigurálja erőforrásait, kulcsait a tárolóból stb. Korábban volt Jenkins + Helm 2, de ki kellett fejlesztenem egy saját eszközt, hogy kiküszöböljem a másolást és beillesztést, és egységessé tegyem a szoftver életciklusát.
Az Ops csapata nem ír csővezetékeket a fejlesztőknek, de tanácsot tud adni írásukkal kapcsolatos kérdésekben (néhány embernek még mindig van Helm 3).
DevOps
Ami a DevOps-ot illeti, ezt így látjuk:
A fejlesztői csapatok kódot írnak, majd a Confer to dev -> qa/stage -> prod segítségével teszik közzé. Annak biztosításáért, hogy a kód ne lassuljon le, és ne tartalmazzon hibákat, a Fejlesztői és az Ops csapatok felelősek. Nappal az Ops csapat ügyeletese mindenekelőtt egy eseményre reagáljon az alkalmazásával, este és éjszaka pedig az ügyeletes adminisztrátor (Ops) ébressze fel az ügyeletes fejlesztőt, ha tudja, győződjön meg arról, hogy a probléma nem az infrastruktúrában van. A megfigyelésben minden mérőszám és figyelmeztetés automatikusan vagy félautomatikusan jelenik meg.
Az Ops felelősségi köre attól a pillanattól kezdődik, amikor az alkalmazás gyártásba kerül, de a Fejlesztő felelőssége ezzel nem ér véget – ugyanazt csináljuk, és ugyanabban a csónakban járunk.
A fejlesztők tanácsot adnak az adminisztrátoroknak, ha segítségre van szükségük egy adminisztrátori mikroszolgáltatás megírásához (például Go backend + HTML5), az adminisztrátorok pedig tanácsot adnak a fejlesztőknek bármilyen infrastrukturális vagy a k8-al kapcsolatos problémában.
Egyébként egyáltalán nincs monolitunk, csak mikroszolgáltatásaink vannak. Számuk eddig 900 és 1000 között ingadozik a prod k8s klaszterben, ha számmal mérjük bevetések. A hüvelyek száma 1700 és 2000 között ingadozik. Jelenleg körülbelül 2000 hüvely található a termékcsoportban.
Pontos számokat nem tudok mondani, mivel a felesleges mikroszolgáltatásokat figyeljük és félautomatikusan kivágjuk. A K8s segít nyomon követni a szükségtelen entitásokat , ami rengeteg erőforrást és pénzt takarít meg.
Erőforrás menedzsment
megfigyelés
A jól strukturált és informatív monitorozás egy nagy klaszter működésének sarokkövévé válik. Még nem találtunk olyan univerzális megoldást, amely az összes monitorozási igényt 100%-ban fedezné, ezért ebben a környezetben időszakonként különböző egyedi megoldásokat készítünk.
- Zabbix. A jó öreg monitorozás, amely elsősorban az infrastruktúra általános állapotának nyomon követésére szolgál. Megmondja, ha egy csomópont elhal a feldolgozás, a memória, a lemezek, a hálózat stb. tekintetében. Semmi természetfeletti, de van egy külön DaemonSet ügynökünk is, aminek segítségével például a DNS állapotát figyeljük a klaszterben: keresünk hülye coredns podokat, ellenőrizzük a külső hostok elérhetőségét. Úgy tűnik, minek foglalkozni ezzel, de nagy forgalom mellett ez az összetevő komoly meghibásodási pontot jelent. én már , hogyan küzdöttem a DNS teljesítményével egy fürtben.
- Prometheus operátor. Különböző exportőrök csoportja nagy áttekintést ad a klaszter összes összetevőjéről. Ezután mindezt a Grafana nagy irányítópultjain jelenítjük meg, és az alertmanagert használjuk a riasztásokhoz.
Egy másik hasznos eszköz volt számunkra . Megírtuk, miután többször találkoztunk olyan helyzettel, amikor az egyik csapat átfedte egy másik csapat behatolási útvonalát, ami 50-szeres hibát eredményezett. Most az éles üzembe helyezés előtt a fejlesztők ellenőrzik, hogy senkit ne érintsen, és csapatom számára ez egy jó eszköz az Ingresses-szel kapcsolatos problémák kezdeti diagnosztizálására. Vicces, hogy eleinte rendszergazdáknak írták, és meglehetősen „ügyetlennek” tűnt, de miután a fejlesztői csapatok beleszerettek az eszközbe, sokat változott, és nem úgy tűnt, mintha „egy admin webarcot csinált az adminoknak. ” Hamarosan elhagyjuk ezt az eszközt, és az ilyen helyzeteket még a folyamat bevezetése előtt ellenőrizni fogjuk.
Csapatforrások a Kockában
Mielőtt belevágnánk a példákba, érdemes elmagyarázni, hogyan allokálunk forrásokat mikroszolgáltatások.
Hogy megértsük, mely csapatok és milyen mennyiségben használják erőforrások (processzor, memória, helyi SSD), minden parancsnak kiosztjuk a sajátját névtér a „Cube”-ban, és korlátozza annak maximális képességeit a processzor, a memória és a lemez tekintetében, miután korábban megbeszéltük a csapatok igényeit. Ennek megfelelően egy parancs általában nem blokkolja a teljes fürtöt a telepítéshez, több ezer magot és terabájt memóriát foglal le. A névtérhez való hozzáférést AD-n keresztül biztosítjuk (mi RBAC-t használunk). A névterek és korlátaik lekéréses kéréssel kerülnek hozzáadásra a GIT-tárhoz, majd minden automatikusan megjelenik az Ansible folyamaton keresztül.
Példa az erőforrások csapathoz való hozzárendelésére:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Kérések és korlátok
kocka" Kérjen a garantáltan lefoglalt erőforrások száma hüvely (egy vagy több dokkolókonténer) egy fürtben. A limit egy nem garantált maximum. A grafikonokon gyakran láthatja, hogy néhány csapat túl sok kérést állított be magának az összes alkalmazáshoz, és nem tudja telepíteni az alkalmazást a „Cubába”, mivel a névterük alatti összes kérést már „elköltötték”.
Ebből a helyzetből a helyes kiút az, ha megnézzük a tényleges erőforrás-felhasználást, és összehasonlítjuk a kért összeggel (Kérés).
A fenti képernyőképeken láthatja, hogy a „Kért” CPU-k a szálak valós számához illeszkednek, és a korlátok meghaladhatják a CPU-szálak valós számát =)
Most nézzünk meg néhány névteret részletesen (én a kube-system névteret választottam - magának a „Cube”-nak a rendszernévterét), és nézzük meg a ténylegesen használt processzoridő és memória arányát a kérthez:
Nyilvánvaló, hogy sokkal több memória és CPU van fenntartva a rendszerszolgáltatások számára, mint amennyit ténylegesen felhasználnak. A kube-rendszer esetében ez indokolt: előfordult, hogy az nginx ingress controller vagy nodelocaldns csúcson beütötte a CPU-t és rengeteg RAM-ot fogyasztott, így itt indokolt az ilyen tartalék. Ráadásul nem hagyatkozhatunk az elmúlt 3 óra grafikonjaira: kívánatos, hogy a történelmi mutatókat hosszú időn keresztül nézzük.
Kidolgozták az „ajánlás” rendszerét. Például itt láthatja, hogy mely erőforrások esetében lenne jobb a „korlátok” (a felső megengedett sáv) megemelése, hogy ne forduljon elő „fojtás”: az a pillanat, amikor egy erőforrás már elhasználta a CPU-t vagy a memóriát a kijelölt időszeletben, és megvárja, amíg „feloldódik”:
És itt vannak azok a hüvelyek, amelyeknek meg kell fékeznie az étvágyukat:
Про fojtó + erőforrás-figyelés, több cikket is írhat, ezért tegye fel kérdéseit a megjegyzésekben. Néhány szóban elmondhatom, hogy az ilyen mérőszámok automatizálása nagyon nehéz, és sok időt igényel, valamint az „ablak” függvényekkel és a „CTE” Prometheus / VictoriaMetrics-szel való egyensúlyozást (ezek a kifejezések idézőjelben vannak, mivel szinte semmi ilyesmi a PromQL-ben, és az ijesztő lekérdezéseket több szöveges képernyőre kell felosztani, és optimalizálni kell őket).
Ennek köszönhetően a fejlesztők rendelkeznek eszközökkel a Cube névtereinek figyelésére, és maguk választhatják meg, hogy hol és mikor melyik alkalmazások „levághatják” az erőforrásaikat, és mely szerverek kaphatják egész éjjel a teljes CPU-t.
Módszertanok
A mostani társaságban divatos, betartjuk a DevOps- és SRE- gyakorló Ha egy cégnek 1000 mikroszolgáltatása, körülbelül 350 fejlesztője és 15 adminisztrátorija van a teljes infrastruktúrához, akkor "divatnak kell lenni": mindezen "baswords" mögött sürgősen mindent és mindenkit automatizálni kell, és az adminok nem lehetnek szűk keresztmetszetek. folyamatokban.
Opsként különféle mutatókat és irányítópultokat biztosítunk a fejlesztők számára a szolgáltatások válaszarányával és hibáival kapcsolatban.
Olyan módszereket használunk, mint pl. , и ezek kombinálásával. Igyekszünk minimálisra csökkenteni az irányítópultok számát, hogy egy pillantással egyértelmű legyen, hogy éppen melyik szolgáltatás romlik (például válaszkódok másodpercenként, válaszidő 99 százalékponttal), és így tovább. Amint néhány új mérőszám szükségessé válik az általános irányítópultokhoz, azonnal megrajzoljuk és hozzáadjuk azokat.
Egy hónapja nem rajzoltam grafikonokat. Ez valószínűleg jó jel: azt jelenti, hogy a legtöbb „kívánság” már megvalósult. Előfordult, hogy a héten legalább naponta egyszer rajzoltam valami új grafikont.
Az eredmény azért értékes, mert a fejlesztők ma már nagyon ritkán fordulnak a rendszergazdákhoz olyan kérdéssel, hogy „hol nézzünk meg valamilyen mérőszámot”.
bevezetése Service Mesh a közelben van, és mindenkinek sokkal könnyebbé kell tennie az életét, a Tools munkatársai már közel állnak az elvont „Egészséges ember Istio” megvalósításához: minden HTTP(k) kérés életciklusa látható lesz a monitorozásban, és A szolgálatok közötti (és nem csak) interakció során mindig meg lehet érteni, hogy „melyik szakaszban tört el minden”. Feliratkozás a DomClick hub híreire. =)
Kubernetes infrastruktúra támogatás
Történelmileg a javított verziót használjuk Kubespray — Alkalmas szerep a Kubernetes telepítésében, bővítésében és frissítésében. Valamikor a nem kubeadm telepítések támogatása megszűnt a fő ágról, és nem javasolták a kubeadm-re való váltás folyamatát. Ennek eredményeként a Southbridge cég elkészítette saját villát (kubeadm támogatással és a kritikus problémák gyors javításával).
Az összes k8s-fürt frissítésének folyamata így néz ki:
- vesz Kubespray Southbridge-ből, nézd meg a szálunkkal, Merjim.
- A frissítést elindítjuk feszültség- „Kocka”.
- A frissítést egyenként tesszük közzé (az Ansible-ben ez „soros: 1”) Dev- „Kocka”.
- Frissítünk Döf szombat este egy-egy csomópont.
A tervek szerint a jövőben kicserélik Kubespray valami gyorsabb és menjen kubeadm.
Összesen három „kockánk” van: Stress, Dev és Prod. Tervezzük egy másik elindítását (forró készenlét) Prod-„Cube” a második adatközpontban. feszültség и Dev „virtuális gépekben” élnek (oVirt for Stress és VMWare cloud for Dev). Döf- A „Cube” „csupasz fémen” él: egyforma csomópontokról van szó, 32 CPU-szállal, 64-128 GB memóriával és 300 GB-os SSD RAID 10-zel – összesen 50 van belőlük. Három „vékony” csomópont van a „mestereknek” szentelve Döf- „Kuba”: 16 GB memória, 12 CPU szál.
Az értékesítés során előnyben részesítjük a „csupasz fém” használatát, és kerüljük a felesleges rétegeket, mint pl OpenStack: nincs szükségünk „zajos szomszédokra” és CPU-ra időt lopni. Az adminisztráció bonyolultsága pedig megközelítőleg megduplázódik a házon belüli OpenStack esetében.
A CI/CD „Cubic” és egyéb infrastrukturális komponensekhez külön GIT szervert, Helm 3-at használunk (ez elég fájdalmas átállás volt a Helm 2-ről, de nagyon elégedettek vagyunk a lehetőségekkel atom), Jenkins, Ansible és Docker. Szeretjük a funkciók elágazását és a különböző környezetekben történő telepítést egyetlen tárolóból.
Következtetés
Általánosságban így néz ki a DevOps folyamat a DomClicknél az üzemeltetési mérnök szemszögéből. A cikk kevésbé technikai jellegűnek bizonyult, mint amire számítottam: ezért kövesd a DomClick híreit a Habrén: lesznek még „kemény” cikkek a Kubernetesről és egyebekről.
Forrás: will.com