🥇กลยุทธ์การปรับใช้ใน Kubernetes: กลิ้ง, สร้างใหม่, น้ำเงิน/เขียว, คานารี, มืด (การทดสอบ A/B)

บันทึก การแปล: ภาพรวมจาก Weaveworks นี้แนะนำกลยุทธ์การเปิดตัวแอปพลิเคชันที่ได้รับความนิยมมากที่สุด และแสดงให้เห็นว่ากลยุทธ์ขั้นสูงสุดสามารถนำไปใช้งานโดยใช้ตัวดำเนินการ Kubernetes Flagger ได้อย่างไร เขียนด้วยภาษาที่เรียบง่ายและมีไดอะแกรมภาพที่ช่วยให้วิศวกรมือใหม่สามารถเข้าใจปัญหานี้ได้

แผนภาพนี้นำมาจาก รีวิวอื่น กลยุทธ์การเปิดตัวที่ทำใน Container Solutions

หนึ่งในความท้าทายที่ใหญ่ที่สุดในการพัฒนาแอปพลิเคชันแบบเนทีฟบนคลาวด์ในปัจจุบันคือการเร่งการปรับใช้ ในแนวทางไมโครเซอร์วิส นักพัฒนาได้ร่วมงานและออกแบบแอปพลิเคชันแบบโมดูลาร์โดยสมบูรณ์อยู่แล้ว ซึ่งช่วยให้ทีมต่างๆ สามารถเขียนโค้ดและทำการเปลี่ยนแปลงแอปพลิเคชันไปพร้อมๆ กัน

การใช้งานที่สั้นลงและบ่อยขึ้นมีข้อดีดังต่อไปนี้:

เวลาออกสู่ตลาดก็ลดลง
คุณสมบัติใหม่เข้าถึงผู้ใช้ได้เร็วขึ้น
ความคิดเห็นของผู้ใช้ไปถึงทีมพัฒนาเร็วขึ้น ซึ่งหมายความว่าทีมสามารถเพิ่มฟีเจอร์และแก้ไขปัญหาได้รวดเร็วยิ่งขึ้น
ขวัญกำลังใจของนักพัฒนาเพิ่มขึ้น: คุณสมบัติในการพัฒนามากขึ้นทำให้การทำงานสนุกยิ่งขึ้น

แต่เมื่อความถี่ของการเปิดตัวเพิ่มขึ้น โอกาสที่จะส่งผลเสียต่อความน่าเชื่อถือของแอปพลิเคชันหรือประสบการณ์ผู้ใช้ก็เพิ่มขึ้นเช่นกัน นั่นเป็นเหตุผลว่าทำไมจึงเป็นเรื่องสำคัญสำหรับฝ่ายปฏิบัติการและทีม DevOps ในการสร้างกระบวนการและจัดการกลยุทธ์การปรับใช้ในลักษณะที่ช่วยลดความเสี่ยงต่อผลิตภัณฑ์และผู้ใช้ให้เหลือน้อยที่สุด (คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับระบบอัตโนมัติไปป์ไลน์ CI/CD ที่นี่.)

ในโพสต์นี้ เราจะพูดถึงกลยุทธ์การปรับใช้ต่างๆ ใน Kubernetes รวมถึงการปรับใช้แบบต่อเนื่องและวิธีการขั้นสูงอื่นๆ เช่น การเปิดตัว Canary และรูปแบบต่างๆ

กลยุทธ์การปรับใช้

มีกลยุทธ์การปรับใช้หลายประเภทที่คุณสามารถใช้ได้ ขึ้นอยู่กับเป้าหมายของคุณ ตัวอย่างเช่น คุณอาจต้องเปลี่ยนแปลงสภาพแวดล้อมบางอย่างเพื่อการทดสอบเพิ่มเติม หรือกับกลุ่มย่อยของผู้ใช้/ไคลเอนต์ หรือจำเป็นต้องทำการทดสอบผู้ใช้แบบจำกัดก่อนที่จะสร้างฟีเจอร์ สาธารณะ.

การกลิ้ง (การปรับใช้แบบค่อยเป็นค่อยไป "การกลิ้ง")

นี่คือกลยุทธ์การปรับใช้มาตรฐานใน Kubernetes โดยจะค่อยๆ แทนที่พ็อดด้วยแอปพลิเคชันเวอร์ชันเก่าทีละน้อยด้วยพ็อดเวอร์ชันใหม่ โดยไม่มีการหยุดทำงานของคลัสเตอร์

Kubernetes รอจนกว่าพ็อดใหม่จะพร้อมใช้งาน (ตรวจสอบโดยใช้ การทดสอบความพร้อม) ก่อนที่คุณจะเริ่มสะสมอันเก่า หากเกิดปัญหาขึ้น การอัปเดตแบบกลิ้งนี้สามารถยกเลิกได้โดยไม่ต้องหยุดทั้งคลัสเตอร์ ในไฟล์ YAML ที่อธิบายประเภทการใช้งาน อิมเมจใหม่จะแทนที่อิมเมจเก่า:

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

สามารถระบุพารามิเตอร์การอัพเดตแบบโรลโอเวอร์ได้ในไฟล์ Manifest:

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

สร้างใหม่

ในการปรับใช้ประเภทที่ง่ายที่สุดนี้ พ็อดเก่าจะถูกฆ่าทั้งหมดในคราวเดียวและแทนที่ด้วยพ็อดใหม่:

รายการที่เกี่ยวข้องจะมีลักษณะดังนี้:

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

น้ำเงิน/เขียว (การใช้งานสีน้ำเงิน-เขียว)

กลยุทธ์การปรับใช้สีน้ำเงิน-เขียว (บางครั้งเรียกว่าสีแดง/ดำ) เกี่ยวข้องกับการปรับใช้แอปพลิเคชันเวอร์ชันเก่า (เขียว) และใหม่ (สีน้ำเงิน) พร้อม ๆ กัน หลังจากโพสต์ทั้งสองเวอร์ชันแล้ว ผู้ใช้ทั่วไปจะสามารถเข้าถึงเวอร์ชันสีเขียวได้ ในขณะที่เวอร์ชันสีน้ำเงินมีไว้สำหรับทีม QA เพื่อทำการทดสอบอัตโนมัติผ่านบริการแยกต่างหากหรือการส่งต่อพอร์ตโดยตรง:

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

หลังจากที่เวอร์ชันสีน้ำเงิน (ใหม่) ได้รับการทดสอบและได้รับการอนุมัติแล้ว บริการจะสลับไปที่เวอร์ชันนั้น และเวอร์ชันสีเขียว (เก่า) จะถูกพับ:

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

Canary (การติดตั้ง Canary)

การเปิดตัว Canary นั้นคล้ายคลึงกับการเปิดตัวสีน้ำเงิน-เขียว แต่มีการควบคุมและการใช้งานที่ดีกว่า ความก้าวหน้า วิธีการทีละขั้นตอน ประเภทนี้ประกอบด้วยกลยุทธ์ที่แตกต่างกันหลายประการ รวมถึงการเปิดตัวแบบ "ซ่อนตัว" และการทดสอบ A/B

กลยุทธ์นี้ใช้เมื่อมีความจำเป็นต้องลองใช้ฟังก์ชันใหม่บางอย่าง ซึ่งโดยปกติจะอยู่ในแบ็กเอนด์ของแอปพลิเคชัน สาระสำคัญของแนวทางนี้คือการสร้างเซิร์ฟเวอร์ที่เกือบจะเหมือนกันสองเซิร์ฟเวอร์: เซิร์ฟเวอร์หนึ่งให้บริการผู้ใช้เกือบทั้งหมด และอีกเซิร์ฟเวอร์หนึ่งให้บริการผู้ใช้กลุ่มย่อยขนาดเล็กที่มีฟังก์ชันใหม่ หลังจากนั้นจึงเปรียบเทียบผลลัพธ์ของงานของพวกเขา หากทุกอย่างดำเนินไปโดยไม่มีข้อผิดพลาด เวอร์ชันใหม่จะค่อยๆ เปิดตัวไปยังโครงสร้างพื้นฐานทั้งหมด

แม้ว่ากลยุทธ์นี้สามารถนำไปใช้ได้โดยใช้ Kubernetes โดยเฉพาะ โดยแทนที่พ็อดเก่าด้วยอันใหม่ แต่ก็สะดวกกว่าและง่ายกว่ามากในการใช้ service mesh เช่น Istio

ตัวอย่างเช่น คุณอาจมีสองรายการที่แตกต่างกันใน Git: รายการปกติที่มีแท็ก 0.1.0 และรายการ canary ที่มีแท็ก 0.2.0 ด้วยการเปลี่ยนน้ำหนักในรายการเกตเวย์เสมือนของ Istio คุณจะควบคุมการกระจายการรับส่งข้อมูลระหว่างการปรับใช้ทั้งสองนี้ได้:

หากต้องการคำแนะนำทีละขั้นตอนในการติดตั้งใช้งาน Canary โดยใช้ Istio โปรดดู เวิร์กโฟลว์ GitOps กับ Istio. (บันทึก. แปล: เรายังแปลเนื้อหาเกี่ยวกับการเปิดตัว Canary ลงใน Istio อีกด้วย ที่นี่.)

การปรับใช้ Canary ด้วย Weaveworks Flagger

วีฟเวิร์คส์ แฟลกเกอร์ ช่วยให้คุณจัดการการเปิดตัว Canary ได้อย่างง่ายดายและมีประสิทธิภาพ

Flagger ทำงานร่วมกับพวกเขาโดยอัตโนมัติ โดยใช้ Istio หรือ AWS App Mesh เพื่อกำหนดเส้นทางและสลับการรับส่งข้อมูล และใช้ตัววัด Prometheus เพื่อวิเคราะห์ผลลัพธ์ นอกจากนี้ การวิเคราะห์การใช้งาน Canary ยังเสริมด้วย Webhooks เพื่อทำการทดสอบการยอมรับ การทดสอบโหลด และการตรวจสอบประเภทอื่นๆ

จากการปรับใช้ Kubernetes และการปรับสเกลแนวนอนของพ็อด (HPA) หากจำเป็น Flagger จะสร้างชุดของออบเจ็กต์ (การใช้งาน Kubernetes, บริการ ClusterIP และ Istio หรือบริการเสมือนของ App Mesh) เพื่อวิเคราะห์และปรับใช้การปรับใช้ Canary:

การใช้ลูปควบคุม (วงควบคุม),ผู้ตั้งค่าสถานะจะค่อยๆ เปลี่ยนการรับส่งข้อมูลไปยังเซิร์ฟเวอร์คานารี ขณะเดียวกันก็วัดเมตริกประสิทธิภาพหลักไปพร้อมๆ กัน เช่น เปอร์เซ็นต์ของคำขอ HTTP ที่สำเร็จ ระยะเวลาคำขอโดยเฉลี่ย และประสิทธิภาพของพ็อด จากการวิเคราะห์ KPI (ตัวบ่งชี้ประสิทธิภาพหลัก) นกคีรีบูนจะเติบโตหรือพังทลายลง และผลลัพธ์ของการวิเคราะห์จะถูกเผยแพร่ใน Slack คำอธิบายและการสาธิตกระบวนการนี้สามารถพบได้ในเอกสาร การจัดส่งแบบก้าวหน้าสำหรับ App Mesh.

การปรับใช้แบบมืด (ซ่อน) หรือ A/B

การใช้งาน Stealth เป็นอีกรูปแบบหนึ่งของกลยุทธ์ Canary (ซึ่ง Flagger ก็สามารถนำมาใช้ได้เช่นกัน) ความแตกต่างระหว่างการปรับใช้แบบซ่อนตัวและแบบคานารี่ก็คือการปรับใช้แบบซ่อนตัวจะจัดการกับส่วนหน้ามากกว่าแบบแบ็กเอนด์เหมือนกับการปรับใช้แบบคานารี

อีกชื่อหนึ่งสำหรับการปรับใช้เหล่านี้คือการทดสอบ A/B แทนที่จะทำให้ฟีเจอร์ใหม่นี้พร้อมใช้งานสำหรับผู้ใช้ทุกคน ฟีเจอร์ใหม่นี้จะเสนอให้กับผู้ใช้เพียงบางส่วนเท่านั้น โดยทั่วไปแล้ว ผู้ใช้เหล่านี้จะไม่ทราบว่าตนเองเป็นผู้ทดสอบรุ่นบุกเบิก (ด้วยเหตุนี้จึงเรียกว่า "การปรับใช้งานแบบซ่อนตัว")

การใช้สวิตช์ฟังก์ชัน (สลับคุณสมบัติ) และเครื่องมืออื่นๆ คุณสามารถตรวจสอบวิธีที่ผู้ใช้โต้ตอบกับคุณลักษณะใหม่ ไม่ว่าพวกเขาจะมีส่วนร่วมหรือไม่ หรือพบว่าอินเทอร์เฟซผู้ใช้ใหม่น่าสับสนหรือไม่ และเมตริกประเภทอื่นๆ

การปรับใช้ Flagger และ A/B

นอกเหนือจากการกำหนดเส้นทางตามน้ำหนักแล้ว Flagger ยังสามารถกำหนดเส้นทางการรับส่งข้อมูลไปยังเซิร์ฟเวอร์ Canary ตามพารามิเตอร์ HTTP ได้อีกด้วย ในการทดสอบ A/B คุณสามารถใช้ส่วนหัว HTTP หรือคุกกี้เพื่อกำหนดเป้าหมายกลุ่มผู้ใช้เฉพาะได้ ซึ่งจะมีประสิทธิภาพโดยเฉพาะอย่างยิ่งในกรณีของแอปพลิเคชันส่วนหน้าที่จำเป็นต้องมีการเชื่อมโยงเซสชันกับเซิร์ฟเวอร์ (ความสัมพันธ์ของเซสชัน). ดูข้อมูลเพิ่มเติมได้ในเอกสารประกอบของผู้รายงานปัญหา

ผู้เขียนแสดงความขอบคุณ สเตฟาน โปรแดนวิศวกร Weaveworks (และผู้สร้าง Flagger) สำหรับรูปแบบการใช้งานที่น่าทึ่งเหล่านี้

ปล.จากผู้แปล

อ่านเพิ่มเติมในบล็อกของเรา:

ที่มา: will.com

กลยุทธ์การปรับใช้ใน Kubernetes: กลิ้ง, สร้างใหม่, น้ำเงิน/เขียว, คานารี, มืด (การทดสอบ A/B)