Kubernetes дахь Канарын байршуулалт №3: Istio

Istio+Kiali-г ашиглан Canary байршуулалтыг эхлүүлж, дүрслэн үзүүлээрэй

Энэ цувралын нийтлэлүүд

1. Kubernetes дахь Канарын байршуулалт №1: Gitlab CI
2. Kubernetes №2 дахь Канарын байршуулалт: Argo Rollouts
3. (Энэ нийтлэл)
4. Jenkins-X Istio Flagger ашиглан Canary Deployment

Канарын байршуулалт

Таныг уншина гэж найдаж байна эхний хэсэг, энд бид Canary байршуулалт гэж юу болохыг товч тайлбарлаж, стандарт Kubernetes нөөцийг ашиглан хэрхэн хэрэгжүүлэхийг харуулсан.

Истио

Энэ нийтлэлийг уншсанаар та Istio гэж юу болохыг аль хэдийн мэддэг болсон гэж бид бодож байна. Үгүй бол та энэ тухай уншиж болно энд.

Туршилт хийх өргөдөл

Под тус бүр нь манай програм болон istio-proxy гэсэн хоёр контейнер агуулдаг.

Бид энгийн тестийн программыг frontend-nginx болон backend python pods ашиглана. Nginx pod нь хүсэлт бүрийг арын хэсэг рүү чиглүүлж, прокси байдлаар ажиллах болно. Дэлгэрэнгүй мэдээллийг дараах ямлуудаас олж болно.

• frontend.yaml
• backend.yaml
• istio.yaml

Туршилтын програмыг өөрөө ажиллуулж байна

Хэрэв та миний үлгэр жишээг дагаж, энэ тестийн програмыг өөрөө ашиглахыг хүсвэл үзнэ үү төслийн Readme.

Анхны байршуулалт

Анхны Deployment-ийг эхлүүлэхэд манай програмын хонхорцог ердөө 2 контейнертэй, өөрөөр хэлбэл Istio хажуугийн машин дөнгөж хэрэгжиж байна.

Мөн бид нэрийн талбарт Istio Gateway Loadbalancer-ийг харж байна istio-system:

Замын хөдөлгөөнийг бий болгох

Бид дараах IP-г ашиглан урд талын самбарт хүлээн авч, арын хэсэг рүү дамжуулах урсгалыг үүсгэх болно.

while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done

Бид бас нэмэх болно frontend.istio-test Манай хост файл руу.

Kiali-ээр дамжуулан Mesh-ийг үзэх

Бид туршилтын програм болон Istio-г Tracing, Grafana, Prometheus, Kiali-н хамт суулгасан (дэлгэрэнгүйг доороос үзнэ үү). төслийн Readme). Тиймээс бид Kiali-г дараах байдлаар ашиглаж болно:

istioctl dashboard kiali # admin:admin

Kiali нь Mesh-ээр дамжуулан одоогийн урсгалыг дүрсэлдэг

Бидний харж байгаагаар бид хүсэлтийг арын үйлчилгээ рүү дахин чиглүүлдэг энгийн nginx прокси ашиглаж байгаа тул траффикийн 100% нь урд талын үйлчилгээ рүү, дараа нь v1 шошготой урд талын pods руу явдаг. v1 шошготой.

Kiali нь Istio-тэй маш сайн ажилладаг бөгөөд хайрцагласан Mesh дүрсний шийдлийг өгдөг. Зүгээр л сайхан.

Канарын байршуулалт

Манай арын хэсэгт аль хэдийн хоёр k8s байршуулалт байгаа бөгөөд нэг нь v1, нөгөө нь v2. Одоо бид зөвхөн Istio-д хүсэлтийн тодорхой хувийг v2 руу шилжүүлэхийг хэлэх хэрэгтэй.

Алхам 1: 10%

Бидний хийх ёстой зүйл бол ВиртуалҮйлчилгээний жинг тохируулах явдал юм istio.yaml:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

Хүсэлтийн 10% нь v2 руу дахин чиглэгдэж байгааг бид харж байна.

Алхам 2: 50%

Одоо үүнийг 50% болгоход л хангалттай.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
...
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 50
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 50

Алхам 3: 100%

Одоо Canary байршуулалтыг дууссан гэж үзэж болох бөгөөд бүх урсгалыг v2 руу дахин чиглүүлэв:

Канарыг гараар туршиж байна

Одоо бид бүх хүсэлтийн 2%-ийг v10 backend руу илгээдэг гэж бодъё. Бүх зүйл бидний бодож байгаагаар ажиллаж байгаа эсэхийг шалгахын тулд v2-г гараар туршихыг хүсвэл яах вэ?

Бид HTTP толгой дээр суурилсан тусгай тохирох дүрмийг нэмж болно:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - headers:
        canary:
          exact: "canary-tester"
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

Одоо curl ашиглан бид толгойг илгээх замаар v2 хүсэлтийг хүчээр гаргаж болно:

Гарчиггүй хүсэлтийг 1/10 харьцаагаар удирдсан хэвээр байх болно:

Хоёр хамааралтай хувилбарт зориулсан Canary

Одоо бид урд болон арын аль алинд нь v2 хувилбар байгаа сонголтыг авч үзэх болно. Бид хоёулангийнх нь хувьд траффикийн 10% нь v2 руу явах ёстойг тодорхойлсон:

Бид v1 ба v2 урд талын урсгалыг v1 ба v10 арын хэсэгт 1/2 харьцаагаар дамжуулж байгааг харж байна.

Хэрэв v2-тэй нийцэхгүй байгаа тул бид траффикийг frontend-v2-с зөвхөн backend-v1 руу шилжүүлэх шаардлагатай бол яах вэ? Үүнийг хийхийн тулд бид хэлэлцээрийг ашиглан backend-v1 руу ямар урсгал орж ирэхийг хянадаг урд хэсэгт 10/2 харьцааг тогтооно. sourceLabels :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
...
  - match:
    - sourceLabels:
        app: frontend
        version: v2
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100

Үүний үр дүнд бид хэрэгтэй зүйлээ олж авдаг:

Гарын авлагын Канарын аргын ялгаа

В эхний хэсэг Бид Canary байршуулалтыг гараар хийж, мөн хоёр k8s байршуулалтыг ашигласан. Тэнд бид хуулбарын тоог өөрчлөх замаар хүсэлтийн харьцааг хянаж байсан. Энэ арга нь үр дүнтэй боловч ноцтой сул талуудтай.

Istio нь хуулбарын тооноос үл хамааран хүсэлтийн харьцааг тодорхойлох боломжийг олгодог. Энэ нь жишээ нь, бид HPAs (Хэвтээ Pod Autoscalers) ашиглах боломжтой бөгөөд Канарын байршуулалтын одоогийн төлөвийн дагуу тохируулах шаардлагагүй гэсэн үг юм.

Үр дүн

Истио маш сайн ажилладаг бөгөөд үүнийг Kiali-тай хамт хэрэглэх нь маш хүчтэй хослолыг бий болгодог. Миний сонирхлын жагсаалтын дараагийнх нь автоматжуулалт болон Канарын аналитикийн хувьд Spinnaker-ийг Istio-тэй хослуулах явдал юм.

Эх сурвалж: www.habr.com