Nota. transl.: adoptatio Kubernetes in GitLab censetur una e duobus principalibus factoribus ad incrementum societatis conferentis. Tamen, usque nuper, infrastructura GitLab.com servitii online in virtualis machinis aedificatum est et solum circa annum migratio eius ad K8s incepit, quod adhuc non perficitur. Laeti sumus translationem recentis articuli per GitLab SRE architectum exhibere quomodo hoc fiat et quid conclusiones machinarum in consilium participando faciant.
Circiter anno iam nostra divisio infrastructura migrans omnia officia in GitLab.com ad Kubernetes migrans est. Hoc tempore provocationes non solum ad operas movendas Kubernetes, sed etiam ad administrationem hybridarum per transitum administrandam comparaverunt. Lectiones pretiosae quas didicimus in hoc articulo tractabuntur.
Ab ipso exordio GitLab.com, ministri eius in nube in machinis virtualibus accurrerunt. Hae machinis virtualis ab archimagiri procurantur et in nostro instrumento inauguratus est . si applicatio renovanda est, consistit in tantum adaequationis servo classem in modo ordinato, sequentiali modo CI pipelino utendi. Haec methodus - licet tarde & parum - efficit ut GitLab.com eadem institutione et configuratione exercitiis utitur ut offline utentium (Auto-tractari) GitLab officinae utentes fasciculis Linux nostris ad hoc.
Hac methodo utimur, quia maximi momenti est omnes dolores et gaudia experiri, quae ordinaria membra communitatis experiuntur in eorum exemplaribus GitLab insertis et conformandis. Accessus hic aliquamdiu bene laboravit, sed cum numerus inceptorum in GitLab 10 miliones excessit, intelleximus eam non amplius nostrae necessitati ad scalas et instruere.
Primi gradus ad Kubernetes et nubes-nativa GitLab
Project creatus est in MMXVII parare GitLab ad nubem instruere, et utentes utentes GitLab in Kubernetes ligaturas instituere. Scimus igitur GitLab ad Kubernetes movens scalam suggesti SaaS augere, inilia simpliciorem reddere et efficientiam computandi facultates augere. Eodem tempore multae functionum applicationis nostrae in partitionibus inclusis NFS pendebant, quae transitus a machinis virtualibus retardabant.
Ventilabra ad nubem vernaculam et Kubernetes machinas nostras permiserunt gradatim transitum instituere, in quibus nonnullas evolutionis clientelas in retis retis relinquentes, dum novas lineamenta evolvere perseverem. Cum migrationem aestate anni 2019 parare coepimus, multae harum limitum resolutae sunt, et processus migrandi GitLab.com ad Kubernetes nunc bene comparatus est!
Lineamenta GitLab.com in Kubernetes
Pro GitLab.com uno botro GKE regionali utimur qui omnem applicationem negotiationis tractat. Ad intricationem migrationis (iam captiositatis) obscuratis, officia intendunt quae in loci repositione vel NFS non innituntur. GitLab.com utitur praedominantibus monolithicis Rails codebase, et nos iter negotiationem innixam notis inposuit ad diversos terminos, qui separatim in propriis nodi lacunis sunt.
In frontispicio hae species in petitiones textus, API, Git SSH/HTTPS et Subcriptio dividuntur. In casu backend, jobs in queue iuxta varias notas pendentes dividemus quae nobis permittunt ut servitii-Level obiectiva (SLOs) pro variis laboribus proponamus.
Horum omnium officia GitLab.com figurata sunt utens immodificato GitLab Helm chart. Configuratio exercetur in chartis, quae selective effici possunt dum gradatim officia ad botrum migrant. Etsi non decrevimus aliqua officia civitatis nostrae in migratione comprehendere, ut Redis, Postgres, GitLab Paginae et Gitaly, Kubernetes utentes nobis permittit ut numerum VMs qui Chef nunc administrat, radicaliter minuere sinit.
Kubernetes Configurationis Visibilitas et Management
Omnes occasus ab ipso GitLab administrantur. Ad hoc tria incepta configurationis fundatae in Terraform et Helm adhibentur. Conamur ipsum GitLab uti quotiens potest currere GitLab, sed ad operas operationes separatum GitLab habemus institutionem. Hoc opus est ut ne dependens a promptitudine GitLab.com cum GitLab.com instruere ac updates faciendo.
Etsi nostri pipelines pro botro Kubernetes in institutione GitLab separatam currunt, specula sunt codicis repositoria quae publice praesto sunt in inscriptionibus sequentibus:
- — GitLab.com configuration compagem pro GitLab Helm chart;
- - Continet configurationes pro servitiis quae cum applicatione GitLab non directe coniunguntur. Hae figurationes ligaturae et botri vigilantia includunt, ac instrumenta integrata sicut PlantUML;
- — Configuratio Terraformi Kubernetes et legatum VM infrastructurae. Hic configuras omnes facultates necessarias ad botrum currendum, incluso ipsum botrum, piscinas nodi, rationes muneris, et exceptiones IP inscriptionis.
Publica sententia ostenditur quando mutationes fiunt. cum ligamine ad diss detailed quod SRE analyses priusquam mutatur ad botrum.
Pro SRE, nexus per diff in GitLab institutionem distinctam ducit, quae ad productionem et accessum ad quod limitatur adhibetur. Hoc conductos et communitas concedit, sine accessu ad project operationale (quod solum SREs apertum est), ut mutationes configurationis propositae videant. Coniungendo instantia publica GitLab pro codice cum instantia privata CI pipelines, unum laborem conservamus dum independentiam a GitLab.com pro updates conformatione conservamus.
Quod invenimus per migrationem
In motu, experientia consecuta est ut novis migrationibus et inceptis in Kubernetes incumbamus.
1. Auxit costs propter negotiationis inter disponibilitate zonis
Exitus quotidianus Statistics (bytes per diem) pro Git repositio classis in GitLab.com
Google reticulum suum in regiones dividit. Ea autem in zonis accessibilitatem dividuntur (AZ). Git hosting cum magna copia notitiarum coniungitur, ut exitus retis regere nos amet. Egressus enim mercaturae internae tantum libera est si intra eandem zonam disponibilitatem remanet. Sicut huius scriptionis, circiter 100 TB notitiarum servimus in profesto typico (et hoc modo in repositoriis Git). Officia, quae in eisdem machinis virtualis residebant in antiqua nostra topologia VM-fundata, nunc in diversis siliquis Kubernetes currunt. Hoc significat commercium aliquod, quod antea locale ad VM erat, potentia extra zonas disponibilitates ire.
Botri Regionales GKE permittunt tibi ut multiplices Availability Zonas pro redundantia extendas. Facultatem consideramus ob operas quae magna volumina negotiationis generant. Hic egressum reducet gratuita servato glomerati gradui redundantia.
2. limites, petitiones et subsidia scandendi
Numerus replicationum processus productionis negotiationis in registry.gitlab.com. Negotiatio Alpium ~ 15:00 UTC.
Narratio migrationis nostrae mense Augusto 2019 incepit, cum primum officium nostrum, GitLab Continentis Registry, in Kubernetes migravimus. Haec missio-critica, summus mercaturae ministerium, bonae electionis primae migrationis fuit, quia est assidua applicatio cum paucis clientibus externis. Primum problema quod invenimus fuit magnus numerus siliquae eiectae ob defectum memoriae in nodis. Propter quod petitiones et limites habuimus mutare.
Inventum est in casu applicationis ubi memoria consumptio super tempus augetur, valores humiles pro petitionibus (memoria retinendo pro singulis vasculis) copulata cum "generoso" limite in usu adhibito ad satietatem. (saturatio) nodis et eminentia confinia. Ad hanc quaestionem agendam, erat . Hoc pressum de nodis sumpsit et siliquas servavit vitse cyclus quae nimium pressionem nodi non attulit. Nunc migrationes incipimus cum alacritate (et fere eadem) petitione ac limitibus valoribus, eas ut necessarias accommodans.
3. Metrics and logs
Divisio infrastructura latentiam tendit, errorum et saturitatem cum inaugurato (SLO) coniunctum cum .
Praeterito anno, unus ex clavibus eventus in infrastructura divisione meliorum facta est in vigilantia et operando cum SLOs. SLOs permisit nobis proposita pro singulis officiis disponere quae migrationis arcte monita sumus. Sed etiam hac observatione emendata, non semper fieri potest ut problemata metri ac summis montibus utentes statim videre possit. Exempli gratia, latency et erroris rates positos, omnes casus usus plene non comprehendimus pro servitio migrationis subeundae.
Hic exitus deprehensus est fere statim postquam aliqua incommoda in botrum migravit. Maxime acutus factum est cum functiones compescere debebamus propter quas numerus petitionum erat exiguus, sed certae dependentiae conformationis. Una praecipuorum lectionum e migratione necesse fuit considerare non solum metri vigilantiam, sed etiam tigna et "longam caudam". (Hoc est de in chart - approx. transl.) erroribus. Nunc de unaquaque migratione singulas quaestiones index includimus (Iniuriarum queries) et consilium aperte reverti rationes, quae ab uno transmigratione in alteram transferri possunt, si difficultates oriuntur.
Eadem petitiones inservientes in parallelis veteris VM infrastructurae et in novo Kubernetes-substructio substructio singularem provocationem exhibuerunt. Secus vitae et, subcinctus migratio (velox translatio applicationum "sicut" ad novam infrastructuram; plura legi possunt, e.g. — proxime. transl.), opus parallelum de "vetus" VMs et Kubernetes requirit ut instrumenta vigilantia utrique ambitus componi possint et metrica in unam sententiam coniungi possint. Gravis est ut eisdem ashboardis et quaestionibus stipes utamur, ut constantiam observationis in tempore transitus consequantur.
4. Switching negotiationis ad novam botrum portassent
Nam GitLab.com pars ministrantium dedicata est . Canaria Park inservit inceptis internis et potest etiam . Sed principaliter ordinatur ad probandas mutationes factas infrastructuram et applicationem. Primum ministerium migrantium accipiendo paucas commercii interni coepimus, et pergimus hac methodo utendi SLOs occurrerint antequam omnia negotiatio ad botrum mittant.
In causa migrationis, hoc significat postulationes incepta interna ad Kubernetes primum mitti, et deinde sensim mutando reliquam negotiationem ad botrum, mutato pondere pro backend per HAProxy. Per migrationem ab VM ad Kubernetes, apparebat valde utilem esse facilem viam ad mercaturam redirectam inter vetus et novum infrastructuram habere ac proinde antiquam infrastructuram paratam reverti in primis paucis post diebus post migrationem.
5. Subsidium facultatum siliquae et eorum usus
Prope statim sequentia quaestio notata est: siliquae pro Subcriptio officii celeriter inceperunt, sed siliquae deducendae ad Sidekiq suscepta sunt. . Longum satus tempus pro sidekiq leguminis exitus factus est cum migrare incepta ad Kubernetes inceperunt opifices, qui necessarii sunt ad jobs processum cito et cito scandendum.
In hoc casu documentum fuit quod, dum Kubernetes' Horizontal Pod Autoscaler (HPA) incrementum negotiationis bene tractat, interest considerare characteres in laboribus et facultati siliquis parce collocare (praesertim cum postulatio inaequaliter distributa est). In casu nostro, subitus impetus factus est in jobs, ducens ad scalas rapidas, quae ad satietatem CPU perductae sunt priusquam tempus erat ut piscinam nodi conscenderet.
Tentatio semper est ut quam maxime ex botro exprimatur, tamen, initio congressi problemata perficiendi, nunc incipimus cum magna vasculo fiscali et postea minuendo, in SLOs arcendo intuendo. Siliquas deducentes ad ministerium Sidekiq signanter acceleravit et nunc circiter 40 seconds in mediocris accipit. vicit et GitLab.com et nostri utentes officinarum auto-actarum laborantium cum chart officiali GitLab Helm.
conclusio,
Post unumquodque ministerium migrantes gavisi sumus de beneficiis Kubernetes in productione utendi: celerius et tutius applicationis instruere, scalis, et efficacius destinatio subsidii. Praeterea commoda migrationis GitLab.com servitium excedunt. Omnis emendatio ad Helm chart officialis suis utentibus prodest.
Spero te fruendum fabula Kubernetes migrationis nostrae adventus. Nos omnia nova officia in botrum migrare pergimus. Additional information to be found in his publications:
- «";
- «";
- .
PS ab translator
Lege etiam in nostro diario:
- «";
- «";
- «";
- «".
Source: www.habr.com