Mi nomiĝas Viktor Yagofarov, kaj mi disvolvas la Kubernetes-platformon ĉe DomClick kiel teknika disvolva administranto en la Ops (operacia) teamo. Mi ŝatus paroli pri la strukturo de niaj Dev <-> Ops-procezoj, la funkcioj de funkciigado de unu el la plej grandaj k8s-aretoj en Rusio, same kiel la DevOps/SRE-praktikoj kiujn nia teamo aplikas.
Ops Teamo
La Ops-teamo nuntempe havas 15 homojn. Tri el ili respondecas pri la oficejo, du laboras en malsama horzono kaj disponeblas, inkluzive nokte. Tiel, iu de Ops ĉiam estas ĉe la monitoro kaj preta respondi al okazaĵo de ajna komplekseco. Ni ne havas noktajn deĵorojn, kio konservas nian psikon kaj donas al ĉiuj la ŝancon sufiĉe dormi kaj pasigi libertempon ne nur ĉe la komputilo.
Ĉiuj havas malsamajn kompetentecojn: retoj, DBA-oj, ELK-stako-specialistoj, Kubernetes-administrantoj/programistoj, monitorado, virtualigo, hardvarspecialistoj, ktp. Unu afero unuigas ĉiujn - ĉiuj povas anstataŭigi iun ajn el ni: ekzemple, enkonduki novajn nodojn en la k8s-areton, ĝisdatigi PostgreSQL, verki CI/CD + Ansible-dukton, aŭtomatigi ion en Python/Bash/Go, konekti aparataron al Datumcentro. Fortaj kompetentecoj en iu ajn areo ne malhelpas vin ŝanĝi vian direkton de agado kaj komenci pliboniĝi en iu alia areo. Ekzemple, mi aliĝis al kompanio kiel specialisto de PostgreSQL, kaj nun mia ĉefa respondeco estas Kubernetes-grupoj. En la teamo, ajna alteco estas bonvena kaj la sento de levilforto estas tre evoluinta.
Cetere, ni ĉasas. Postuloj por kandidatoj estas sufiĉe normaj. Persone, gravas por mi, ke homo konvenas en la teamon, estas nekonflikta, sed ankaŭ scipovas defendi sian vidpunkton, volas disvolviĝi kaj ne timas fari ion novan, kaj proponas siajn ideojn. Ankaŭ, programaj kapabloj en skriptlingvoj, scio pri la bazaĵoj de Linukso kaj la angla estas postulataj. La angla estas bezonata simple por ke persono en okazo de fakapo povu gugligi solvon de la problemo en 10 sekundoj, kaj ne en 10 minutoj. Nun estas tre malfacile trovi specialistojn kun profunda scio pri Linukso: ĝi estas amuza, sed du el tri kandidatoj ne povas respondi la demandon "Kio estas Ŝarĝo-Mezumo? El kio ĝi estas farita? ", kaj la demando "Kiel kunmeti kerndeponejon el C-programo" estas konsiderata io el la mondo de superhomoj... aŭ dinosaŭroj. Ni devas toleri ĉi tion, ĉar kutime homoj tre evoluigis aliajn kompetentecojn, sed ni instruos Linukson. La respondo al la demando "kial DevOps-inĝeniero bezonas scii ĉion ĉi en la moderna mondo de nuboj" devos esti lasita ekster la amplekso de la artikolo, sed en tri vortoj: ĉio ĉi estas necesa.
Teamaj Iloj
La teamo de Iloj ludas gravan rolon en aŭtomatigo. Ilia ĉefa tasko estas krei oportunajn grafikajn kaj CLI ilojn por programistoj. Ekzemple, nia interna disvolviĝo Confer ebligas al vi laŭvorte lanĉi aplikaĵon al Kubernetes per nur kelkaj musklakoj, agordi ĝiajn rimedojn, ŝlosilojn de la trezorejo ktp. Antaŭe, ekzistis Jenkins + Helm 2, sed mi devis evoluigi mian propran ilon por forigi kopi-alglui kaj alporti unuformecon al la programara vivociklo.
La Ops-teamo ne skribas duktojn por programistoj, sed povas konsili pri iuj aferoj en sia verkado (kelkaj homoj ankoraŭ havas Helm 3).
DevOps
Koncerne DevOps, ni vidas ĝin jene:
Dev-teamoj skribas kodon, rulu ĝin per Konferu al dev -> qa/stage -> prod. Respondeco por certigi ke la kodo ne malrapidiĝas kaj ne enhavas erarojn kuŝas ĉe la Dev kaj Ops-teamoj. Tage, la deĵoranto de la Ops-teamo unue respondu al okazaĵo per sia aplikaĵo, kaj vespere kaj nokte, la deĵoranta administranto (Ops) devus veki la deĵoran programiston, se li scias pri tio. certe ke la problemo ne estas en la infrastrukturo. Ĉiuj metrikoj kaj atentigoj en monitorado aperas aŭtomate aŭ duonaŭtomate.
La respondeco de Ops komenciĝas de la momento, kiam la aplikaĵo estas lanĉita en produktadon, sed la respondeco de Dev ne finiĝas tie - ni faras la samon kaj estas en la sama boato.
Programistoj konsilas administrantojn se ili bezonas helpon skribi administran mikroservon (ekzemple Go backend + HTML5), kaj administrantoj konsilas programistojn pri iuj infrastrukturaj problemoj aŭ aferoj rilataj al k8s.
Cetere, ni tute ne havas monoliton, nur mikroservojn. Ilia nombro ĝis nun variadas inter 900 kaj 1000 en la prod k8s-areto, se mezurite per nombro. deplojoj. La nombro da balgoj variadas inter 1700 kaj 2000. Nuntempe estas ĉirkaŭ 2000 balgoj en la prod-areto.
Mi ne povas doni precizajn nombrojn, ĉar ni kontrolas nenecesajn mikroservojn kaj tranĉas ilin duonaŭtomate. K8s helpas nin konservi trakon de nenecesaj estaĵoj , kiu ŝparas multajn rimedojn kaj monon.
Administrado de rimedoj
Monitorado
Bone strukturita kaj informa monitorado fariĝas la bazŝtono en la operacio de granda areto. Ni ankoraŭ ne trovis universalan solvon, kiu kovrus 100% de ĉiuj monitoraj bezonoj, do ni periode kreas malsamajn kutimajn solvojn en ĉi tiu medio.
- Zabbikh. Bona malnova monitorado, kiu celas ĉefe spuri la ĝeneralan kondiĉon de la infrastrukturo. Ĝi diras al ni kiam nodo mortas laŭ prilaborado, memoro, diskoj, reto, ktp. Nenio supernatura, sed ni ankaŭ havas apartan DaemonSet de agentoj, kun la helpo de kiu, ekzemple, ni kontrolas la staton de DNS en la areto: ni serĉas stultajn koredns pods, ni kontrolas la haveblecon de eksteraj gastigantoj. Ŝajnus ke kial ĝeni ĉi tion, sed kun grandaj volumoj de trafiko ĉi tiu komponanto estas grava punkto de fiasko. mi jam , kiel mi luktis kun DNS-agado en areto.
- Prometheus Operatoro. Aro de malsamaj eksportistoj donas grandan superrigardon de ĉiuj komponentoj de la areto. Poste, ni bildigas ĉion ĉi sur grandaj paneloj en Grafana, kaj uzas alertmanager por atentigoj.
Alia utila ilo por ni estis . Ni skribis ĝin post pluraj fojoj, kiam ni renkontis situacion, kie unu teamo interkovris la Eniro-vojojn de alia teamo, rezultigante 50x-erarojn. Nun antaŭ ol deploji al produktado, programistoj kontrolas, ke neniu estos tuŝita, kaj por mia teamo ĉi tio estas bona ilo por la komenca diagnozo de problemoj kun Eniroj. Estas amuze, ke komence ĝi estis skribita por administrantoj kaj ĝi aspektis sufiĉe "mallerta", sed post kiam la dev-teamoj enamiĝis al la ilo, ĝi multe ŝanĝiĝis kaj komencis aspekti ne kiel "administranto faris retan vizaĝon por administrantoj. ” Baldaŭ ni forlasos ĉi tiun ilon kaj tiaj situacioj estos validigitaj eĉ antaŭ ol la dukto estos lanĉita.
Teamaj rimedoj en la Kubo
Antaŭ ol ni eniros la ekzemplojn, indas klarigi kiel ni asignas rimedojn por mikroservoj.
Por kompreni kiuj teamoj kaj en kiaj kvantoj uzas siajn rimedoj (procesoro, memoro, loka SSD), ni atribuas ĉiun ordon sian propran nomspaco en la "Kubo" kaj limigi ĝiajn maksimumajn kapablojn laŭ procesoro, memoro kaj disko, antaŭe diskutinte la bezonojn de la teamoj. Sekve, unu komando, ĝenerale, ne blokos la tutan areton por deplojo, asignante milojn da kernoj kaj terabajtojn da memoro. Aliro al nomspaco estas donita per AD (ni uzas RBAC). Nomspacoj kaj iliaj limoj estas aldonitaj per tira peto al la GIT-deponejo, kaj tiam ĉio estas aŭtomate elvolvita tra la Ansible-dukto.
Ekzemplo de asignado de rimedoj al teamo:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Petoj kaj limoj
Kubo" peto estas la nombro de garantiitaj rezervitaj rimedoj por pod (unu aŭ pluraj docker ujoj) en areto. Limo estas ne-garantiita maksimumo. Vi ofte povas vidi sur la grafikaĵoj kiel iu teamo starigis al si tro multajn petojn por ĉiuj siaj aplikoj kaj ne povas deploji la aplikaĵon al la "Kubo", ĉar ĉiuj petoj sub sia nomspaco jam estis "eluzitaj".
La ĝusta eliro el ĉi tiu situacio estas rigardi la realan konsumon de rimedoj kaj kompari ĝin kun la petita kvanto (Peto).
En la supraj ekrankopioj vi povas vidi, ke "Petita" CPU-oj kongruas kun la reala nombro da fadenoj, kaj Limoj povas superi la realan nombron da CPU-fadenoj =)
Nun ni detale rigardu iun nomspacon (mi elektis nomspacon kube-system - la sisteman nomspacon por la komponantoj de la "Kubo" mem) kaj vidu la rilatumon de la efektive uzata procesora tempo kaj memoro al la petita:
Estas evidente, ke multe pli da memoro kaj CPU estas rezervitaj por sistemaj servoj ol estas fakte uzataj. En la kazo de la kube-sistemo, tio estas pravigita: okazis, ke nginx enir-regilo aŭ nodelocaldns ĉe sia pinto trafis la CPU kaj konsumis multe da RAM, do ĉi tie tia rezervo estas pravigita. Krome, ni ne povas fidi leterojn dum la lastaj 3 horoj: estas dezirinde vidi historiajn metrikojn dum granda tempodaŭro.
Sistemo de "rekomendoj" estis evoluigita. Ekzemple, ĉi tie vi povas vidi, kiuj rimedoj estus pli bone altigi la "limojn" (la supran permesitan baron) por ke "streĉo" ne okazu: la momento kiam rimedo jam elspezis CPU aŭ memoron en la asignita tempotranĉo kaj atendas ĝis ĝi estos "malfrostita":
Kaj jen la balgoj, kiuj devus bridi siajn apetitojn:
pri stranglante + monitorado de rimedoj, vi povas skribi pli ol unu artikolon, do demandu en la komentoj. En kelkaj vortoj, mi povas diri, ke la tasko aŭtomatigi tiajn metrikojn estas tre malfacila kaj postulas multan tempon kaj ekvilibran agon kun "fenestroj" funkcioj kaj "CTE" Prometheus / VictoriaMetrics (ĉi tiuj terminoj estas inter citiloj, ĉar preskaŭ ekzistas nenio tia en PromQL, kaj vi devas dividi timigajn demandojn en plurajn ekranojn de teksto kaj optimumigi ilin).
Kiel rezulto, programistoj havas ilojn por monitori siajn nomspacojn en Cube, kaj ili povas elekti mem kie kaj je kiu tempo kiuj aplikoj povas havi siajn rimedojn "tranĉitaj", kaj kiuj serviloj povas ricevi la tutan CPU dum la tuta nokto.
Metodologioj
En la firmao kiel ĝi estas nun moda, ni aliĝas al DevOps- kaj SRE-praktikisto Kiam kompanio havas 1000 mikroservojn, ĉirkaŭ 350 programistojn kaj 15 administrantojn por la tuta infrastrukturo, oni devas "esti moda": malantaŭ ĉiuj ĉi tiuj "basvortoj" estas urĝa bezono aŭtomatigi ĉion kaj ĉiujn, kaj administrantoj ne estu botelo. en procezoj.
Kiel Ops, ni provizas diversajn metrikojn kaj instrumentpanelojn por programistoj rilataj al servo-respondaj indicoj kaj eraroj.
Ni uzas metodikojn kiel: , и kombinante ilin kune. Ni provas minimumigi la nombron da instrumentpaneloj por ke per unu ekrigardo estas klare, kiu servo nuntempe malboniĝas (ekzemple respondkodoj je sekundo, respondtempo je 99-a percentilo), ktp. Tuj kiam iuj novaj metrikoj fariĝas necesaj por ĝeneralaj paneloj, ni tuj desegnas kaj aldonas ilin.
Mi ne desegnis grafikaĵojn dum unu monato. Ĉi tio verŝajne estas bona signo: tio signifas, ke la plej multaj el la "deziroj" jam realiĝis. Okazis, ke dum la semajno mi desegnus iun novan grafeon almenaŭ unufoje tage.
La rezulta rezulto estas valora ĉar nun programistoj sufiĉe malofte iras al administrantoj kun demandoj "kie rigardi ian metrikon."
Efektivigo Servo Mesh estas tuj ĉirkaŭ la angulo kaj devus faciligi la vivon al ĉiuj, kolegoj de Iloj jam estas proksimaj al efektivigo de la abstraktaĵo "Istio de sana homo": la vivociklo de ĉiu HTTP(j) peto estos videbla en monitorado, kaj ĝi ĉiam eblos kompreni "en kiu stadio ĉio rompiĝis" dum interserva (kaj ne nur) interago. Abonu novaĵojn de la DomClick-nabo. =)
Subteno de infrastrukturo de Kubernetes
Historie, ni uzas la flikitan version Kubespray — Ansible rolo por disfaldi, etendi kaj ĝisdatigi Kubernetes. Ĉe iu punkto, subteno por ne-kubeadm-instalaĵoj estis tranĉita de la ĉefbranĉo, kaj la procezo de ŝanĝado al kubeadm ne estis proponita. Kiel rezulto, la kompanio Southbridge faris sian propran forkon (kun kubeadm-subteno kaj rapida solvo por kritikaj problemoj).
La procezo por ĝisdatigi ĉiujn k8s-aretojn aspektas jene:
- Prenu Kubespray el Southbridge, kontrolu per nia fadeno, Merjim.
- Ni lanĉas la ĝisdatigon al streso- "Kubo".
- Ni lanĉas la ĝisdatigon po unu nodo (en Ansible ĉi tio estas "seria: 1") Dev- "Kubo".
- Ni ĝisdatigas Prod sabate vespere po unu nodo.
Estas planoj anstataŭigi ĝin en la estonteco Kubespray por io pli rapida kaj iru al kubeadm.
Entute ni havas tri "Kubojn": Streso, Dev kaj Prod. Ni planas lanĉi alian (varma standby) Prod-“Kubo” en la dua datuma centro. streso и Dev vivi en "virtualaj maŝinoj" (oVirt por Streso kaj VMWare-nubo por Dev). Prod- "Kubo" vivas sur "nuda metalo": ĉi tiuj estas identaj nodoj kun 32 CPU-fadenoj, 64-128 GB da memoro kaj 300 GB SSD RAID 10 - estas 50 el ili entute. Tri "maldikaj" nodoj estas dediĉitaj al "majstroj" Prod- "Kubo": 16 GB da memoro, 12 CPU-fadenoj.
Por vendoj, ni preferas uzi "nudan metalon" kaj eviti nenecesajn tavolojn kiel OpenStack: ni ne bezonas "bruaj najbaroj" kaj CPU ŝteli tempon. Kaj la komplekseco de administrado proksimume duobliĝas en la kazo de interna OpenStack.
Por CI/KD "Cubic" kaj aliaj infrastrukturaj komponantoj ni uzas apartan GIT-servilon, Helm 3 (estis sufiĉe dolora transiro de Helm 2, sed ni estas tre feliĉaj pri la elektoj. atomata), Jenkins, Ansible kaj Docker. Ni amas ĉefbranĉojn kaj deplojon al malsamaj medioj de unu deponejo.
konkludo
Ĉi tio estas, ĝenerale, kiel aspektas la DevOps-procezo ĉe DomClick el la perspektivo de operacia inĝeniero. La artikolo montriĝis malpli teknika ol mi atendis: sekve, sekvu la novaĵojn de DomClick pri Habré: estos pli da "hardcore" artikoloj pri Kubernetes kaj pli.
fonto: www.habr.com