🥇Kubernetes-ontplooiingstrategieë: rol, herskep, blou/groen, kanarie, donker (A/B-toets)

Let wel. vertaling: Hierdie deurbraak van Weaveworks stel die gewildste toepassings-ontplooiingstrategieë bekend en hoe jy die mees gevorderde met die Flagger Kubernetes-operateur kan implementeer. Dit is in eenvoudige taal geskryf en bevat visuele diagramme wat selfs beginner ingenieurs toelaat om die probleem te verstaan.

Diagram geneem uit nog 'n resensie ontplooiingstrategieë gemaak in Container Solutions

Een van die grootste uitdagings in die ontwikkeling van wolk-inheemse toepassings vandag is ontplooiingspoed. Met 'n mikrodiensbenadering werk ontwikkelaars reeds met en ontwerp ten volle modulêre toepassings, wat verskillende spanne in staat stel om kode te skryf en terselfdertyd veranderinge aan die toepassing aan te bring.

Korter en meer gereelde ontplooiings hou die volgende voordele in:

Verminderde tyd om te bemark.
Nuwe kenmerke kom vinniger by gebruikers uit.
Gebruikerterugvoer bereik die ontwikkelingspan vinniger. Dit beteken dat die span kenmerke kan byvoeg en probleme vinniger kan oplos.
Ontwikkelaarsmoraal styg: meer kenmerke in ontwikkeling is lekkerder om mee te werk.

Maar namate die frekwensie van vrystellings toeneem, neem die kanse ook toe om die toepassing se betroubaarheid of gebruikerservaring negatief te beïnvloed. Daarom is dit belangrik vir bedrywighede en DevOps-spanne om prosesse te bou en ontplooiingstrategieë te bestuur op 'n manier wat risiko vir die produk en gebruikers tot die minimum beperk. (Om meer te wete te kom oor die outomatisering van die CI/CD-pyplyn, sien hier.)

In hierdie pos sal ons verskeie Kubernetes-ontplooiingstrategieë bespreek, insluitend rollende ontplooiings en meer gevorderde metodes soos kanarie-ontplooiing en hul variasies.

Ontplooiingstrategieë

Daar is verskeie verskillende tipes ontplooiingstrategieë wat gebruik kan word afhangende van die doel. Byvoorbeeld, jy sal dalk veranderinge aan een of ander omgewing moet maak vir verdere toetsing, of aan 'n subset van gebruikers/kliënte, of jy sal dalk beperkte toetse op gebruikers moet doen voordat jy 'n kenmerk maak publiek.

Rol (geleidelike, rollende ontplooiing)

Dit is die standaard-ontplooiingstrategie vir Kubernetes. Dit vervang geleidelik, een vir een, die peule met die ou weergawe van die toepassing met peule met die nuwe weergawe - sonder stilstand van die groep.

Kubernetes wag vir nuwe peule om gereed te wees om te gaan (kontroleer hulle met gereedheidstoetse) voordat jy voortgaan om die oues op te rol. As 'n probleem opduik, kan so 'n deurlopende opdatering gestaak word sonder om die hele groepering te stop. In die implementeringstipe YAML-lêer vervang die nuwe prent die ou prent:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: awesomeapp
    spec:
      containers:
        - name: awesomeapp
          image: imagerepo-user/awesomeapp:new
          ports:
            - containerPort: 8080

Die parameters van die rollende opdatering kan in die manifeslêer gespesifiseer word:

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
       maxSurge: 25%
       maxUnavailable: 25%  
  template:
  ...

Herskep (herskep)

In hierdie eenvoudigste tipe ontplooiing word ou peule gelyktydig doodgemaak en met nuwes vervang:

Die ooreenstemmende manifes lyk iets soos volg:

spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
  ...

Blou/Groen (blou-groen ontplooiings)

Die blou-groen-ontplooiingstrategie (soms ook na verwys as rooi / swart, dit wil sê rooi-swart) behels die gelyktydige ontplooiing van die ou (groen) en nuwe (blou) weergawes van die toepassing. Sodra beide weergawes gehuisves is, is die groen een beskikbaar vir die algemene gebruiker, terwyl die blou een beskikbaar is vir die QA-span om toetse te outomatiseer via 'n aparte diens of direkte poortaanstuur:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
    metadata:
      labels:
        app: awesomeapp
        version: "02"

Nadat die blou (nuwe) weergawe getoets en goedgekeur is vir vrystelling, word die diens daarna oorgeskakel, en die groen (ou) word geminimaliseer:

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

Kanarie (kanarie-ontplooiings)

Kanarie-uitrol is soortgelyk aan blougroen, maar beter beheer en gebruik progressief stap vir stap benadering. Verskeie verskillende strategieë val in hierdie kategorie, insluitend koverte bekendstellings en A/B-toetse.

Hierdie strategie word gebruik wanneer 'n paar nuwe funksionaliteit getoets moet word, gewoonlik in die toepassing se agterkant. Die kern van die benadering is om twee byna identiese bedieners te skep: een bedien byna alle gebruikers, en die ander, met nuwe funksies, bedien slegs 'n klein subgroep gebruikers, waarna die resultate van hul werk vergelyk word. As alles sonder foute verloop, word die nuwe weergawe geleidelik na die hele infrastruktuur uitgerol.

Alhoewel hierdie strategie uitsluitlik met Kubernetes geïmplementeer kan word, deur ou peule met nuwes te vervang, is dit baie geriefliker en makliker om 'n diensnetwerk soos Istio te gebruik.

Byvoorbeeld, jy kan twee verskillende Git-manifeste hê: 'n gewone een met 'n 0.1.0-merker en 'n kanarie-een met 'n 0.2.0-merker. Deur die gewigte in die Istio Virtual Gateway-manifes te verander, kan jy die verspreiding van verkeer tussen hierdie twee ontplooiings beheer:

'n Stap-vir-stap gids vir die implementering van kanarie-ontplooiings met Istio kan gevind word in GitOps Workflows met Istio. (Let wel. vertaal.: Ons het ook materiaal oor kanarierolletjies in Istio vertaal hier.)

Kanarie-ontplooiings met Weaveworks Flagger

Weaveworks Flagger laat maklike en doeltreffende beheer van kanarierolle toe.

Flagger outomatiseer om met hulle te werk. Dit gebruik Istio of AWS App Mesh om verkeer te stuur en om te skakel, en Prometheus-statistieke om die resultate te ontleed. Daarbenewens kan die ontleding van kanarie-ontplooiings aangevul word met webhooks vir die uitvoer van aanvaardingstoetse, vragtoetse en enige ander tipe tjeks.

Gebaseer op die ontplooiing van Kubernetes en, indien nodig, scale-out pods (HPA), skep Flagger stelle voorwerpe (Kubernetes-ontplooiings, ClusterIP-dienste en Istio of App Mesh virtuele dienste) om kanarie-ontplooiings te ontleed en te implementeer:

Implementering van 'n beheerlus (beheerlus)Flagger skakel geleidelik verkeer na die kanariese bediener oor terwyl hy sleutelprestasiemaatstawwe soos HTTP-versoeksukseskoers, gemiddelde versoekduur en peulgesondheid meet. Op grond van die ontleding van KPI's (Key Performance Indicators), groei die kanarie-deel óf óf krimp, en die resultate van die analise word aan Slack gepubliseer. 'n Beskrywing en demonstrasie van hierdie proses kan in die materiaal gevind word Progressiewe aflewering vir App Mesh.

Donker (versteek) of A/B-ontplooiings

Stealth-ontplooiing is nog 'n variasie van die kanarie-strategie (waarmee Flagger terloops ook kan werk). Die verskil tussen stealth- en kanarie-ontplooiings is dat stealth-ontplooiings met die voorkant handel en nie die agterkant soos kanarie-ontplooiings doen nie.

'n Ander naam vir hierdie ontplooiings is A/B-toetsing. In plaas daarvan om toegang tot 'n nuwe kenmerk vir alle gebruikers te bied, word dit slegs aan 'n beperkte deel van hulle gebied. Tipies is hierdie gebruikers onbewus daarvan dat hulle baanbrekerstoetsers is (vandaar die term "stille ontplooiing").

Met funksie skakelaars (kenmerkwissels) en ander instrumente, kan jy monitor hoe gebruikers met 'n nuwe kenmerk omgaan, of hulle daaraan verslaaf is of die nuwe gebruikerskoppelvlak verwarrend vind, en ander tipes statistieke.

Vlag- en A/B-ontplooiings

Benewens geweegde roetering, kan Flagger ook verkeer na die kanariese bediener stuur op grond van HTTP-parameters. A/B-toetse kan HTTP-opskrifte of webkoekies gebruik om 'n spesifieke segment van gebruikers te herlei. Dit is veral effektief in die geval van frontend-toepassings wat vereis dat die sessie aan die bediener gebind word. (sessie affiniteit). Meer inligting kan gevind word in die Flagger-dokumentasie.

Die skrywer is dankbaar Stefan Prodan, ingenieur van Weaveworks (en skepper van Flagger), vir al hierdie wonderlike ontplooiingskemas.

Kubernetes-ontplooiingstrategieë: rol, herskep, blou/groen, kanarie, donker (A/B-toets)