Nota. transl.: Ang pagsagop sa Kubernetes sa GitLab gikonsiderar nga usa sa duha ka nag-unang hinungdan nga nakatampo sa pagtubo sa kompanya. Bisan pa, hangtod karon, ang imprastraktura sa serbisyo sa online nga GitLab.com gitukod sa mga virtual nga makina, ug mga usa lang ka tuig ang milabay nagsugod ang paglalin niini sa K8, nga wala pa nahuman. Nalipay kami nga ipresentar ang usa ka hubad sa usa ka bag-o nga artikulo sa usa ka inhenyero sa GitLab SRE kung giunsa kini mahitabo ug kung unsa ang mga konklusyon nga gihimo sa mga inhenyero nga nag-apil sa proyekto.
Sulod sa mga usa ka tuig na karon, ang among dibisyon sa imprastraktura nagbalhin sa tanan nga mga serbisyo nga nagdagan sa GitLab.com ngadto sa Kubernetes. Niining panahona, nakasugat mi og mga hagit nga may kalabotan dili lang sa pagbalhin sa mga serbisyo ngadto sa Kubernetes, kondili sa pagdumala usab sa hybrid nga deployment atol sa transisyon. Ang bililhong mga leksiyon nga atong nakat-onan hisgotan niining artikuloha.
Gikan sa sinugdanan sa GitLab.com, ang mga server niini nagdagan sa panganod sa mga virtual machine. Kini nga mga virtual nga makina gidumala sa Chef ug gi-install gamit ang among . kung ang aplikasyon kinahanglan nga i-update, naglangkob sa yano nga pag-update sa armada sa server sa usa ka coordinated, sequential nga paagi gamit ang CI pipeline. Kini nga pamaagi - bisan pa hinay ug gamay - nagsiguro nga ang GitLab.com naggamit sa parehas nga mga pamaagi sa pag-install ug pag-configure sama sa mga offline nga tiggamit (nagdumala sa kaugalingon) GitLab installations gamit ang among Linux packages para niini.
Gigamit namo kini nga pamaagi tungod kay importante kaayo nga masinati ang tanang kasubo ug kalipay nga nasinati sa ordinaryong mga miyembro sa komunidad sa dihang nag-instalar ug nag-configure sa ilang mga kopya sa GitLab. Kini nga pamaagi nagtrabaho og maayo sulod sa pipila ka panahon, apan sa dihang ang gidaghanon sa mga proyekto sa GitLab milapas sa 10 ka milyon, among naamgohan nga kini wala na makatubag sa among mga panginahanglan alang sa scaling ug deployment.
Unang mga lakang sa Kubernetes ug cloud-native GitLab
Ang proyekto gihimo sa 2017 aron maandam ang GitLab alang sa cloud deployment, ug aron makahimo ang mga tiggamit sa pag-install sa GitLab sa mga cluster sa Kubernetes. Nahibal-an namon kaniadto nga ang pagbalhin sa GitLab ngadto sa Kubernetes makadugang sa scalability sa platform sa SaaS, makapasimple sa mga pag-deploy, ug makapauswag sa kahusayan sa mga kapanguhaan sa pag-compute. Sa parehas nga oras, daghan sa mga gimbuhaton sa among aplikasyon nagsalig sa gi-mount nga partisyon sa NFS, nga nagpahinay sa pagbalhin gikan sa mga virtual machine.
Ang pagduso ngadto sa cloud native ug Kubernetes nagtugot sa among mga inhenyero sa pagplano og hinay-hinay nga transisyon, diin among gibiyaan ang pipila sa mga dependency sa aplikasyon sa network storage samtang nagpadayon sa paghimo og mga bag-ong feature. Sukad nga nagsugod kami sa pagplano sa paglalin sa ting-init sa 2019, daghan niini nga mga limitasyon ang nasulbad na, ug ang proseso sa pagbalhin sa GitLab.com ngadto sa Kubernetes maayo na karon!
Mga bahin sa GitLab.com sa Kubernetes
Para sa GitLab.com, migamit kami ug usa ka rehiyonal nga GKE cluster nga nagdumala sa tanang trapiko sa aplikasyon. Aron mamenosan ang pagkakomplikado sa (malisud na) nga paglalin, nagpunting kami sa mga serbisyo nga wala magsalig sa lokal nga pagtipig o NFS. Ang GitLab.com naggamit sa usa ka kasagaran nga monolithic Rails codebase, ug among giruta ang trapiko base sa workload nga mga kinaiya ngadto sa lain-laing mga endpoint nga nahimulag sa ilang kaugalingong node pool.
Sa kaso sa frontend, kini nga mga tipo gibahin sa mga hangyo sa web, API, Git SSH/HTTPS ug Registry. Sa kaso sa backend, gibahin namon ang mga trabaho sa pila sumala sa lainlaing mga kinaiya depende sa .
Ang tanan niini nga mga serbisyo sa GitLab.com gi-configure gamit ang wala gibag-o nga tsart sa GitLab Helm. Ang pag-configure gihimo sa mga subchart, nga mahimong pilion nga mahimo samtang anam-anam namon nga ibalhin ang mga serbisyo sa cluster. Bisan kung nakahukom kami nga dili iapil ang pipila sa among mga stateful nga serbisyo sa paglalin, sama sa Redis, Postgres, GitLab Pages ug Gitaly, gamit ang Kubernetes nagtugot kanamo nga makunhuran ang gidaghanon sa mga VM nga karon gidumala sa Chef.
Ang Kubernetes Configuration Visibility ug Management
Ang tanan nga mga setting gidumala sa GitLab mismo. Alang niini, tulo ka mga proyekto sa pag-configure base sa Terraform ug Helm ang gigamit. Gisulayan namon nga gamiton ang GitLab sa iyang kaugalingon kung posible aron madagan ang GitLab, apan alang sa mga buluhaton sa operasyon kami adunay lahi nga pag-install sa GitLab. Kinahanglan kini aron masiguro nga wala ka nagsalig sa pagkaanaa sa GitLab.com sa paghimo sa mga pag-deploy ug pag-update sa GitLab.com.
Bisan kung ang among mga pipeline alang sa cluster sa Kubernetes nagdagan sa usa ka bulag nga pag-install sa GitLab, adunay mga salamin sa mga repositoryo sa code nga magamit sa publiko sa mosunod nga mga adres:
- β GitLab.com configuration framework alang sa GitLab Helm chart;
- - Naglangkob sa mga pag-configure alang sa mga serbisyo nga dili direktang nalangkit sa aplikasyon sa GitLab. Naglakip kini sa mga pag-configure alang sa pag-log ug pag-monitor sa cluster, ingon man mga hiniusa nga himan sama sa PlantUML;
- - Pag-configure sa Terraform alang sa Kubernetes ug panulundon nga imprastraktura sa VM. Dinhi imong gi-configure ang tanan nga mga kapanguhaan nga gikinahanglan aron madagan ang cluster, lakip ang cluster mismo, mga node pool, mga account sa serbisyo, ug mga reserbasyon sa IP address.
Ang pagtan-aw sa publiko gipakita kung adunay mga pagbag-o. nga adunay usa ka link sa detalyado nga kalainan nga gisusi sa SRE sa wala pa maghimo mga pagbag-o sa cluster.
Alang sa SRE, ang link nagpadulong sa usa ka detalyado nga diff sa pag-install sa GitLab, nga gigamit alang sa produksiyon ug pag-access nga gipugngan. Kini nagtugot sa mga empleyado ug sa komunidad, nga walay access sa operational nga proyekto (nga bukas lamang sa SREs), sa pagtan-aw sa gisugyot nga mga kausaban sa configuration. Pinaagi sa pagkombinar sa usa ka publikong GitLab nga instance para sa code nga adunay pribadong instance para sa CI pipelines, among gipadayon ang usa ka workflow samtang gisiguro ang kagawasan gikan sa GitLab.com para sa mga update sa configuration.
Ang among nahibal-an sa panahon sa paglalin
Atol sa paglihok, nakuha ang kasinatian nga nag-aplay kami sa mga bag-ong paglalin ug pag-deploy sa Kubernetes.
1. Nadugangan nga gasto tungod sa trapiko tali sa availability zones
Adlaw-adlaw nga egress statistics (bytes kada adlaw) para sa Git repository fleet sa GitLab.com
Gibahin sa Google ang network niini sa mga rehiyon. Kadtong, sa baylo, gibahin sa mga accessibility zone (AZ). Ang pag-host sa Git gilangkit sa daghang mga datos, busa hinungdanon alang kanamo nga kontrolon ang paggawas sa network. Alang sa internal nga trapiko, ang paggawas libre lang kung kini magpabilin sa parehas nga availability zone. Sa pagsulat niini, nag-alagad kami sa gibana-bana nga 100 TB nga datos sa usa ka kasagaran nga adlaw sa trabaho (ug kana alang lang sa mga repositoryo sa Git). Ang mga serbisyo nga nagpuyo sa parehas nga virtual machine sa among karaan nga topology nga nakabase sa VM karon nagdagan sa lainlaing mga pod sa Kubernetes. Kini nagpasabut nga ang pipila ka trapiko nga kaniadto lokal sa VM mahimoβg makabiyahe gawas sa mga lugar nga magamit.
Ang rehiyonal nga mga cluster sa GKE nagtugot kanimo sa paglangoy sa daghang Availability Zone para sa redundancy. Atong gikonsiderar ang posibilidad alang sa mga serbisyo nga makamugna og daghang gidaghanon sa trapiko. Kini makapakunhod sa mga gasto sa paggawas samtang nagmintinar sa cluster-level redundancy.
2. Mga limitasyon, mga hangyo sa kapanguhaan ug pag-scale
Ang gidaghanon sa mga replika nga nagproseso sa trapiko sa produksiyon sa registry.gitlab.com. Ang mga peak sa trapiko sa ~15:00 UTC.
Nagsugod ang among istorya sa paglalin kaniadtong Agosto 2019, sa dihang among gibalhin ang among una nga serbisyo, ang GitLab Container Registry, sa Kubernetes. Kini nga mission-critical, high-traffic nga serbisyo usa ka maayong pagpili alang sa unang paglalin tungod kay kini usa ka stateless nga aplikasyon nga adunay pipila ka mga eksternal nga dependency. Ang una nga problema nga among nasugatan mao ang daghang gidaghanon sa gipalayas nga mga pod tungod sa kakulang sa memorya sa mga node. Tungod niini, kinahanglan namong usbon ang mga hangyo ug limitasyon.
Nadiskobrehan nga sa kaso sa usa ka aplikasyon diin ang pagkonsumo sa memorya nagdugang sa paglabay sa panahon, ang ubos nga mga kantidad alang sa mga hangyo (nagreserba sa memorya alang sa matag pod) inubanan sa usa ka "manggihatagon" nga lisud nga limitasyon sa paggamit misangpot sa saturation (saturation) mga node ug taas nga lebel sa pagpalayas. Aron masulbad kini nga problema, kini . Gikuha niini ang presyur sa mga node ug gisiguro nga ang mga pod adunay usa ka siklo sa kinabuhi nga wala magbutang ug daghang presyur sa node. Karon nagsugod kami sa mga paglalin uban ang manggihatagon (ug halos parehas) nga hangyo ug limitahan ang mga kantidad, pag-adjust niini kung kinahanglan.
3. Sukatan ug mga troso
Ang dibisyon sa imprastraktura nagpunting sa latency, mga rate sa sayup ug saturation nga adunay na-install (SLO) nalambigit sa .
Sa miaging tuig, usa sa mga mahinungdanong panghitabo sa dibisyon sa imprastraktura mao ang pag-uswag sa pagmonitor ug pagtrabaho kauban ang mga SLO. Gitugotan kami sa mga SLO nga magtakda og mga katuyoan alang sa indibidwal nga mga serbisyo nga among gibantayan pag-ayo sa panahon sa paglalin. Apan bisan pa niining gipaayo nga obserbasyon, dili kanunay posible nga makita dayon ang mga problema gamit ang mga sukatan ug mga alerto. Pananglitan, pinaagi sa pag-focus sa latency ug error rate, dili namo hingpit nga masakop ang tanang kaso sa paggamit alang sa usa ka serbisyo nga gipaagi sa paglalin.
Kini nga isyu nadiskobrehan halos diha-diha dayon human sa pagbalhin sa pipila ka mga workloads ngadto sa cluster. Nahimo kini labi ka grabe kung kinahanglan namon susihon ang mga gimbuhaton diin gamay ra ang gidaghanon sa mga hangyo, apan adunay piho nga mga dependency sa pag-configure. Usa sa hinungdanon nga mga leksyon gikan sa paglalin mao ang kinahanglan nga tagdon dili lamang ang mga sukatan kung mag-monitor, apan usab ang mga troso ug ang "taas nga ikog" (kini mahitungod sa sa tsart - gibanabana. transl.) mga sayop. Karon alang sa matag paglalin among gilakip ang usa ka detalyado nga lista sa mga pangutana sa log (mga pangutana sa log) ug pagplano og tin-aw nga mga pamaagi sa rollback nga mahimong ibalhin gikan sa usa ka pagbalhin ngadto sa sunod kung adunay mga problema.
Ang pag-alagad sa parehas nga mga hangyo nga parehas sa daan nga imprastraktura sa VM ug ang bag-ong imprastraktura nga nakabase sa Kubernetes nagpakita usa ka talagsaon nga hagit. Dili sama sa lift-and-shift migration (dali nga pagbalhin sa mga aplikasyon "as is" sa usa ka bag-ong imprastraktura; daghang mga detalye ang mabasa, pananglitan, - gibanabana. transl.), parallel work sa "daan" nga mga VM ug Kubernetes nanginahanglan nga ang mga himan sa pagmonitor mahiuyon sa duha ka palibot ug makahimo sa paghiusa sa mga sukatan sa usa ka pagtan-aw. Importante nga gamiton nato ang parehas nga mga dashboard ug log query aron makab-ot ang makanunayon nga obserbasyon sa panahon sa transisyon.
4. Pagbalhin sa trapiko ngadto sa bag-ong cluster
Alang sa GitLab.com, ang bahin sa mga server gipahinungod sa . Ang Canary Park nagsilbi sa among mga internal nga proyekto ug mahimo usab . Apan kini nag-una nga gidisenyo aron sulayan ang mga pagbag-o nga gihimo sa imprastraktura ug aplikasyon. Ang unang migrate nga serbisyo nagsugod pinaagi sa pagdawat og limitado nga gidaghanon sa internal nga trapiko, ug padayon namo nga gigamit kini nga pamaagi aron masiguro nga matuman ang mga SLO sa dili pa ipadala ang tanang trapiko sa cluster.
Sa kaso sa paglalin, nagpasabot kini nga ang mga hangyo sa internal nga mga proyekto ipadala una ngadto sa Kubernetes, ug dayon anam-anam namong ibalhin ang nahabilin nga trapiko ngadto sa cluster pinaagi sa pag-usab sa gibug-aton sa backend pinaagi sa HAProxy. Atol sa paglalin gikan sa VM ngadto sa Kubernetes, nahimong tin-aw nga kini mapuslanon kaayo nga adunay sayon ββββnga paagi sa pag-redirect sa trapiko tali sa daan ug bag-ong imprastraktura ug, sumala niana, ipadayon ang daan nga imprastraktura nga andam alang sa rollback sa unang mga adlaw human sa paglalin.
5. Reserve kapasidad sa pods ug sa ilang paggamit
Hapit diha-diha dayon ang mosunod nga problema giila: ang mga pod para sa serbisyo sa Registry nagsugod dayon, apan ang paglansad sa mga pod para sa Sidekiq mikabat sa . Ang taas nga oras sa pagsugod para sa Sidekiq pods nahimong isyu sa dihang gisugdan namo ang pagbalhin sa mga workloads ngadto sa Kubernetes para sa mga trabahante nga kinahanglang magproseso dayon sa mga trabaho ug paspas nga sukdon.
Sa kini nga kaso, ang leksyon mao nga samtang ang Kubernetes' Horizontal Pod Autoscaler (HPA) maayo nga pagdumala sa pagtubo sa trapiko, importante nga tagdon ang mga kinaiya sa mga workloads ug igahin ang ekstrang kapasidad sa mga pod (ilabi na kung ang panginahanglan dili parehas nga giapod-apod). Sa among kaso, adunay kalit nga pagdagsang sa mga trabaho, nga misangpot sa paspas nga pag-scale, nga misangpot sa saturation sa mga kapanguhaan sa CPU sa wala pa kami adunay panahon sa pag-scale sa node pool.
Adunay kanunay nga tentasyon sa pagpislit kutob sa mahimo gikan sa usa ka pungpong, bisan pa, sa una nga nasugatan ang mga problema sa pasundayag, nagsugod na kami karon sa usa ka ubay-ubay nga badyet ug pagkunhod sa ulahi, nga gibantayan pag-ayo ang mga SLO. Ang paglansad sa mga pod alang sa serbisyo sa Sidekiq mikusog pag-ayo ug karon molungtad mga 40 segundos sa aberids. nakadaog sa GitLab.com ug sa among mga tiggamit sa self-manged installations nga nagtrabaho uban sa opisyal nga GitLab Helm chart.
konklusyon
Pagkahuman sa pagbalhin sa matag serbisyo, nalipay kami sa mga benepisyo sa paggamit sa Kubernetes sa produksiyon: mas paspas ug luwas nga pag-deploy sa aplikasyon, pag-scale, ug labi ka episyente nga alokasyon sa kapanguhaan. Dugang pa, ang mga bentaha sa paglalin labaw pa sa serbisyo sa GitLab.com. Ang matag pag-uswag sa opisyal nga tsart sa Helm nakabenepisyo sa mga tiggamit niini.
Nanghinaut ko nga nalingaw ka sa istorya sa among Kubernetes migration adventures. Nagpadayon kami sa pagbalhin sa tanan nga mga bag-ong serbisyo sa cluster. Dugang nga impormasyon makita sa mosunod nga mga publikasyon:
- Β«";
- Β«";
- .
PS gikan sa tighubad
Basaha usab sa among blog:
- Β«";
- Β«";
- Β«";
- Β«".
Source: www.habr.com