🥇Strategi panyebaran ing Kubernetes: rolling, recreate, blue/green, canary, dark (testing A/B)

Cathetan ngartekne: Ringkesan iki saka Weaveworks ngenalake strategi peluncuran aplikasi sing paling populer lan nuduhake kepiye cara sing paling maju bisa ditindakake nggunakake operator Kubernetes Flagger. Iki ditulis nganggo basa sing gampang lan ngemot diagram visual sing ngidini para insinyur pemula ngerti masalah kasebut.

Diagram dijupuk saka review liyane strategi rollout digawe ing Solutions Container

Salah sawijining tantangan paling gedhe kanggo ngembangake aplikasi asli awan saiki yaiku nyepetake penyebaran. Ing pendekatan microservices, pangembang wis nggarap lan ngrancang aplikasi modular kanthi lengkap, ngidini tim sing beda-beda bisa nulis kode bebarengan lan nggawe pangowahan ing aplikasi kasebut.

Panyebaran sing luwih cendhek lan luwih kerep duwe keuntungan ing ngisor iki:

Wektu menyang pasar suda.
Fitur anyar tekan pangguna luwih cepet.
Umpan balik pangguna tekan tim pangembangan luwih cepet. Iki tegese tim bisa nambah fitur lan ndandani masalah luwih cepet.
Semangat pangembang mundhak: luwih akeh fitur ing pembangunan luwih nyenengake kanggo digarap.

Nanging nalika frekuensi rilis mundhak, kemungkinan bakal nyebabake linuwih aplikasi utawa pengalaman pangguna uga mundhak. Pramila penting kanggo operasi lan tim DevOps kanggo mbangun proses lan ngatur strategi panyebaran kanthi cara sing nyuda resiko kanggo produk lan pangguna. (Sampeyan bisa sinau luwih lengkap babagan otomatisasi pipa CI/CD kene.)

Ing kirim iki, kita bakal ngrembug macem-macem strategi panyebaran ing Kubernetes, kalebu penyebaran rolling lan cara sing luwih maju kayata rollout kenari lan variasi.

Sastranegara panyebaran

Ana macem-macem jinis strategi penyebaran sing bisa digunakake gumantung saka tujuan sampeyan. Contone, sampeyan bisa uga kudu nggawe pangowahan ing lingkungan tartamtu kanggo nyoba luwih lanjut, utawa menyang subset pangguna/klien, utawa sampeyan kudu nindakake pangujian pangguna winates sadurunge nggawe fitur. umum.

Rolling (penyebaran bertahap, "rolling")

Iki minangka strategi panyebaran standar ing Kubernetes. Mboko sithik, siji-siji, ngganti pods karo versi lawas saka aplikasi karo pods karo versi anyar - tanpa downtime kluster.

Kubernetes ngenteni nganti pod anyar siap digunakake (mriksa nganggo tes kesiapan), sadurunge sampeyan miwiti muter sing lawas. Yen ana masalah, nganyari rolling iki bisa dibatalake tanpa mandheg kabeh kluster. Ing file YAML sing njlèntrèhaké jinis panyebaran, gambar anyar ngganti gambar lawas:

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

Parameter nganyari rollover bisa ditemtokake ing file manifest:

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

Gawe maneh

Ing jinis panyebaran sing paling gampang iki, polong lawas dipateni bebarengan lan diganti karo sing anyar:

Manifest sing cocog katon kaya iki:

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

Biru/Ijo (penyebaran biru-ijo)

Strategi panyebaran biru-ijo (kadhangkala uga diarani abang / ireng) kalebu panyebaran simultan saka versi aplikasi lawas (ijo) lan anyar (biru). Sawise ngirim versi loro kasebut, pangguna biasa duwe akses menyang sing ijo, dene sing biru kasedhiya kanggo tim QA kanggo ngotomatisasi tes liwat layanan sing kapisah utawa terusake port langsung:

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

Sawise versi biru (anyar) wis dites lan rilis wis disetujoni, layanan kasebut ngalih, lan versi ijo (lawas) dilipat:

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

Canary (penyebaran kenari)

Rollouts Canary padha karo rollouts biru-ijo, nanging duwe kontrol lan panggunaan sing luwih apik maju pendekatan langkah-langkah. Jinis iki kalebu sawetara strategi sing beda, kalebu peluncuran "siluman" lan tes A/B.

Strategi iki digunakake nalika ana perlu kanggo nyoba sawetara fungsi anyar, biasane ing backend saka aplikasi. Inti saka pendekatan kasebut yaiku nggawe rong server sing meh padha: siji nglayani meh kabeh pangguna, lan liyane, kanthi fungsi anyar, mung nglayani subkelompok pangguna cilik, sawise asil karyane dibandhingake. Yen kabeh ora ana kesalahan, versi anyar bakal diluncurake menyang kabeh infrastruktur.

Sanajan strategi iki bisa ditindakake kanthi eksklusif nggunakake Kubernetes, ngganti pod lawas karo sing anyar, luwih trep lan luwih gampang nggunakake bolong layanan kaya Istio.

Contone, sampeyan bisa uga duwe rong manifest beda ing Git: manifest biasa kanthi tag 0.1.0 lan manifest kenari kanthi tag 0.2.0. Kanthi ngganti bobot ing manifest gateway virtual Istio, sampeyan bisa ngontrol distribusi lalu lintas ing antarane loro panyebaran kasebut:

Kanggo pandhuan langkah-langkah kanggo ngleksanakake penyebaran kenari nggunakake Istio, waca Alur Kerja GitOps karo Istio. (Cathetan. nerjemahake.: Kita uga nerjemahake materi babagan rollout kenari menyang Istio kene.)

Penyebaran Canary karo Weaveworks Flagger

Weaveworks Flagger ngijini sampeyan kanggo gampang lan èfèktif ngatur rollouts kenari.

Flagger automates bisa karo wong-wong mau. Iki nggunakake Istio utawa AWS App Mesh kanggo nuntun lan ngalih lalu lintas, lan metrik Prometheus kanggo nganalisa asil. Kajaba iku, analisis panyebaran kenari bisa ditambah karo webhooks kanggo nganakake tes acceptance, test load, lan jinis pemeriksaan liyane.

Adhedhasar panyebaran Kubernetes lan, yen perlu, skala horisontal pods (HPA), Flagger nggawe set obyek (penyebaran Kubernetes, layanan ClusterIP lan layanan virtual Istio utawa App Mesh) kanggo nganalisa lan ngleksanakake panyebaran kenari:

Implementasi kontrol loop (kontrol loop),Flagger mboko sithik ngalih lalu lintas menyang server kenari nalika, bebarengan ngukur indikator kinerja tombol kayata, rasio panjalukan HTTP sukses, durasi panjalukan rata-rata, lan kesehatan pods. Adhedhasar analisis KPI (Key Performance Indicator), kenari bisa tuwuh utawa ambruk lan asil analisis kasebut diterbitake ing Slack. Katrangan lan demonstrasi proses iki bisa ditemokake ing materi Pangiriman Progresif kanggo App Mesh.

Penyebaran peteng (didhelikake) utawa A/B

Penyebaran siluman minangka variasi liyane saka strategi kenari (sing, kanthi cara, Flagger uga bisa digunakake). Bedane antarane penyebaran siluman lan kenari yaiku panyebaran siluman ngurusi mburi ngarep tinimbang mburi mburi kaya penyebaran kenari.

Jeneng liya kanggo penyebaran kasebut yaiku tes A/B. Tinimbang nggawe fitur anyar kasedhiya kanggo kabeh pangguna, mung ditawakake bagean winates. Biasane, pangguna iki ora ngerti yen dheweke dadi panguji pionir (mula diarani "penyebaran siluman").

Nggunakake switch fungsi (pilihan fitur) lan alat liyane, sampeyan bisa ngawasi carane pangguna sesambungan karo fitur anyar, apa lagi melu, utawa apa padha nemokake antarmuka panganggo anyar mbingungake, lan jinis metrik liyane.

Penyebaran Flagger lan A/B

Saliyane nuntun basis bobot, Flagger uga bisa nuntun lalu lintas menyang server kenari adhedhasar paramèter HTTP. Ing tes A/B, sampeyan bisa nggunakake header HTTP utawa cookie kanggo target segmen pangguna tartamtu. Iki luwih efektif ing kasus aplikasi frontend sing mbutuhake sesi naleni menyang server (afinitas sesi). Informasi liyane bisa ditemokake ing dokumentasi Flagger.

Penulis matur nuwun Stefan Prodan, Insinyur Weaveworks (lan pangripta Flagger), kanggo kabeh pola penyebaran sing apik tenan iki.

PS saka penerjemah

Waca uga ing blog kita:

Source: www.habr.com

Strategi panyebaran ing Kubernetes: rolling, recreate, blue/green, canary, dark (uji A/B)