🥇Strategi penggunaan dalam Kubernetes: berguling, mencipta semula, biru/hijau, kenari, gelap (ujian A/B)

Catatan terjemahan: Gambaran keseluruhan daripada Weaveworks ini memperkenalkan strategi pelancaran aplikasi yang paling popular dan menunjukkan cara yang paling maju boleh dilaksanakan menggunakan pengendali Bendera Kubernetes. Ia ditulis dalam bahasa yang mudah dan mengandungi gambar rajah visual yang membolehkan jurutera baru memahami isu ini.

Strategi penggunaan dalam Kubernetes: berguling, mencipta semula, biru/hijau, kenari, gelap (ujian A/B)
Gambar rajah diambil daripada tinjauan lain strategi pelancaran yang dibuat dalam Penyelesaian Kontena

Salah satu cabaran terbesar dalam membangunkan aplikasi asli awan hari ini ialah mempercepatkan penggunaan. Dalam pendekatan perkhidmatan mikro, pembangun sudah bekerja dengan dan mereka bentuk aplikasi modular sepenuhnya, membenarkan pasukan yang berbeza menulis kod dan membuat perubahan pada aplikasi secara serentak.

Penggunaan yang lebih pendek dan lebih kerap mempunyai faedah berikut:

Masa untuk memasarkan dikurangkan.
Ciri baharu menjangkau pengguna dengan lebih pantas.
Maklum balas pengguna sampai kepada pasukan pembangunan dengan lebih cepat. Ini bermakna pasukan boleh menambah ciri dan menyelesaikan isu dengan lebih cepat.
Semangat pembangun meningkat: lebih banyak ciri dalam pembangunan lebih menyeronokkan untuk digunakan.

Tetapi apabila kekerapan keluaran meningkat, peluang untuk memberi kesan negatif terhadap kebolehpercayaan aplikasi atau pengalaman pengguna juga meningkat. Itulah sebabnya penting untuk operasi dan pasukan DevOps membina proses dan mengurus strategi penggunaan dengan cara yang meminimumkan risiko kepada produk dan pengguna. (Anda boleh mengetahui lebih lanjut tentang automasi saluran paip CI/CD di sini.)

Dalam siaran ini, kami akan membincangkan pelbagai strategi penggunaan dalam Kubernetes, termasuk penggunaan rolling dan kaedah yang lebih maju seperti pelancaran kenari dan variasinya.

Strategi penempatan

Terdapat beberapa jenis strategi penggunaan yang boleh anda gunakan bergantung pada matlamat anda. Sebagai contoh, anda mungkin perlu membuat perubahan pada persekitaran tertentu untuk ujian lanjut, atau subset pengguna/pelanggan, atau anda mungkin perlu melakukan ujian pengguna terhad sebelum membuat ciri. tersedia untuk umum.

Berguling (berperingkat-peringkat, penggunaan "bergolek")

Ini ialah strategi penggunaan standard dalam Kubernetes. Ia secara beransur-ansur, satu demi satu, menggantikan pod dengan versi lama aplikasi dengan pod dengan versi baharu - tanpa masa henti kelompok.

Strategi penggunaan dalam Kubernetes: berguling, mencipta semula, biru/hijau, kenari, gelap (ujian A/B)

Kubernetes menunggu sehingga pod baharu sedia untuk berfungsi (menyemaknya menggunakan ujian kesediaan), sebelum anda mula menggulung yang lama. Jika masalah berlaku, kemas kini bergulir ini boleh dihentikan tanpa menghentikan keseluruhan kluster. Dalam fail YAML yang menerangkan jenis penggunaan, imej baharu menggantikan imej lama:

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 kemas kini peralihan boleh ditentukan dalam fail manifes:

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

Buat semula

Dalam jenis penempatan yang paling mudah ini, pod lama dimatikan sekaligus dan digantikan dengan yang baharu:

Strategi penggunaan dalam Kubernetes: berguling, mencipta semula, biru/hijau, kenari, gelap (ujian A/B)

Manifes yang sepadan kelihatan seperti ini:

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

Biru/Hijau (penyerahan biru-hijau)

Strategi penggunaan biru-hijau (kadangkala juga dipanggil merah/hitam) melibatkan penggunaan serentak versi lama (hijau) dan baharu (biru) aplikasi. Selepas menyiarkan kedua-dua versi, pengguna biasa mempunyai akses kepada versi hijau, manakala versi biru tersedia untuk pasukan QA untuk mengautomasikan ujian melalui perkhidmatan berasingan atau pemajuan port langsung:

Strategi penggunaan dalam Kubernetes: berguling, mencipta semula, biru/hijau, kenari, gelap (ujian A/B)

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

Selepas versi biru (baharu) telah diuji dan keluarannya telah diluluskan, perkhidmatan beralih kepadanya dan versi hijau (lama) dilipat:

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

Canary (pengerahan kenari)

Pelancaran kenari adalah serupa dengan pelancaran biru-hijau, tetapi mempunyai kawalan dan penggunaan yang lebih baik progresif pendekatan langkah demi langkah. Jenis ini termasuk beberapa strategi berbeza, termasuk pelancaran "senyap" dan ujian A/B.

Strategi ini digunakan apabila terdapat keperluan untuk mencuba beberapa fungsi baharu, biasanya di bahagian belakang aplikasi. Intipati pendekatan ini adalah untuk mencipta dua pelayan yang hampir sama: satu melayani hampir semua pengguna, dan yang lain, dengan fungsi baru, hanya melayani subkumpulan kecil pengguna, selepas itu hasil kerja mereka dibandingkan. Jika semuanya berjalan lancar tanpa ralat, versi baharu dilancarkan secara beransur-ansur ke seluruh infrastruktur.

Walaupun strategi ini boleh dilaksanakan secara eksklusif menggunakan Kubernetes, menggantikan pod lama dengan yang baharu, adalah lebih mudah dan lebih mudah untuk menggunakan jaringan perkhidmatan seperti Istio.

Sebagai contoh, anda mungkin mempunyai dua manifes berbeza dalam Git: manifes biasa dengan teg 0.1.0 dan manifes kenari dengan teg 0.2.0. Dengan menukar pemberat dalam manifes get laluan maya Istio, anda boleh mengawal pengedaran trafik antara kedua-dua penempatan ini:

Strategi penggunaan dalam Kubernetes: berguling, mencipta semula, biru/hijau, kenari, gelap (ujian A/B)

Untuk panduan langkah demi langkah untuk melaksanakan penggunaan kenari menggunakan Istio, lihat Aliran Kerja GitOps dengan Istio. (Catatan. terjemah: Kami juga menterjemah bahan tentang pelancaran kenari ke dalam Istio di sini.)

Penggunaan Canary dengan Weaveworks Flagger

Bendera Tenun membolehkan anda mengurus pelancaran kenari dengan mudah dan berkesan.

Flagger mengautomasikan berfungsi dengan mereka. Ia menggunakan Istio atau AWS App Mesh untuk menghala dan menukar trafik, dan metrik Prometheus untuk menganalisis keputusan. Di samping itu, analisis penggunaan kenari boleh ditambah dengan webhooks untuk menjalankan ujian penerimaan, ujian beban dan sebarang jenis pemeriksaan lain.

Berdasarkan penggunaan Kubernetes dan, jika perlu, penskalaan mendatar pod (HPA), Flagger mencipta set objek (pengerahan Kubernetes, perkhidmatan KlusterIP dan perkhidmatan maya Istio atau App Mesh) untuk menganalisis dan melaksanakan penempatan kenari:

Strategi penggunaan dalam Kubernetes: berguling, mencipta semula, biru/hijau, kenari, gelap (ujian A/B)

Melaksanakan gelung kawalan (gelung kawalan),Flagger menukar trafik secara beransur-ansur ke pelayan kanari, sambil pada masa yang sama mengukur metrik prestasi utama seperti peratusan permintaan HTTP yang berjaya, purata tempoh permintaan dan kesihatan pod. Berdasarkan analisis KPI (Petunjuk Prestasi Utama), kenari sama ada tumbuh atau runtuh dan hasil analisis diterbitkan dalam Slack. Penerangan dan demonstrasi proses ini boleh didapati dalam bahan Penghantaran Progresif untuk App Mesh.

Strategi penggunaan dalam Kubernetes: berguling, mencipta semula, biru/hijau, kenari, gelap (ujian A/B)

Gelap (tersembunyi) atau penempatan A/B

Penggunaan stealth ialah satu lagi variasi strategi kenari (yang, secara kebetulan, Flagger juga boleh berfungsi dengannya). Perbezaan antara penggunaan stealth dan kenari ialah penggunaan stealth berurusan dengan bahagian hadapan dan bukannya bahagian belakang seperti penempatan kenari.

Nama lain untuk penempatan ini ialah ujian A/B. Daripada menjadikan ciri baharu itu tersedia kepada semua pengguna, ia ditawarkan kepada sebahagian terhad sahaja daripada mereka. Lazimnya, pengguna ini tidak menyedari bahawa mereka adalah penguji perintis (oleh itu istilah "pengerahan tersembunyi").

Menggunakan suis fungsi (togol ciri) dan alatan lain, anda boleh memantau cara pengguna berinteraksi dengan ciri baharu, sama ada mereka terlibat dengan ciri tersebut atau sama ada mereka mendapati antara muka pengguna baharu mengelirukan dan jenis metrik lain.

Strategi penggunaan dalam Kubernetes: berguling, mencipta semula, biru/hijau, kenari, gelap (ujian A/B)

Penerapan Flagger dan A/B

Selain penghalaan berasaskan berat, Flagger juga boleh menghalakan trafik ke pelayan kanari berdasarkan parameter HTTP. Dalam ujian A/B, anda boleh menggunakan pengepala HTTP atau kuki untuk menyasarkan segmen pengguna tertentu. Ini amat berkesan dalam kes aplikasi frontend yang memerlukan sesi mengikat ke pelayan (perkaitan sesi). Maklumat lanjut boleh didapati dalam dokumentasi Flagger.

Penulis mengucapkan terima kasih Stefan Prodan, jurutera Weaveworks (dan pencipta Flagger), untuk semua corak penggunaan yang menakjubkan ini.