วิธีอัปเกรด canary เป็นการตั้งค่าแบบกำหนดเองของ istio ที่มีอยู่
ความต้องการ:
- เรามีการตั้งค่าแบบกำหนดเองของ istio 1.7.3 (ติดตั้งโดยใช้วิธี istoctl และไม่ได้ตั้งค่าการแก้ไขสำหรับสิ่งนี้) สำหรับ AKS 1.18.14
- ตอนนี้เราต้องอัปเกรดเป็น istio 1.8 โดยไม่มีการหยุดทำงานหรือน้อยที่สุด
- การอัปเกรดควรปลอดภัยกว่าและจะไม่ทำลายสภาพแวดล้อมของผลิตภัณฑ์ของเราแต่อย่างใด
วิธีที่เราติดตั้งสภาพแวดล้อมที่กำหนดเอง istio ปัจจุบัน:
1) สร้างรายการ
รายการ istioctl สร้าง --set profile=default -f /manifests/overlay/overlay.yaml > $HOME/generated-manifest.yaml
2) ติดตั้ง istio
ติดตั้ง istioctl --set profile=default -f /manifests/overlay/overlay.yaml
3) ตรวจสอบ istio กับรายการที่ปรับใช้
istioctl ตรวจสอบติดตั้ง -f $HOME/generated-manifest.yaml
กระบวนการอัปเกรดตามแผน อ้างอิง
1) ตรวจสอบล่วงหน้าสำหรับการอัพเกรด
istioctl x ตรวจสอบล่วงหน้า
2) ส่งออกการกำหนดค่าที่ใช้ในปัจจุบันของ istio โดยใช้คำสั่งด้านล่างไปยังไฟล์ yaml
kubectl -n istio-system รับการติดตั้ง iop-state-install -o yaml > /tmp/iop.yaml
3) ดาวน์โหลดไบนารี istio 1.8 และแตกไดเร็กทอรีและนำทางไดเร็กทอรีไปยังตำแหน่งที่เรามีไบนารี istioctl เวอร์ชัน 1.8
ซีดี istio1.8\istioctl1.8
4) จากไดเร็กทอรี istio เวอร์ชันใหม่ ให้สร้าง controlplane ใหม่สำหรับ istio(1.8) พร้อมชุดการแก้ไขที่เหมาะสม และใช้ "iop.yaml" สถานะการติดตั้งที่เอ็กซ์พอร์ตก่อนหน้านี้
./istioctl1.8 ติดตั้ง --set revision=1-8 --set profile=default -f /tmp/iop.yaml
คาดว่าจะสร้างระนาบการควบคุมใหม่ด้วยการกำหนดค่าแบบ costamised ที่มีอยู่ และตอนนี้เราจะมีการปรับใช้ระนาบการควบคุมสองแบบและบริการที่ทำงานเคียงข้างกัน:
$ kubectl รับพ็อด -n istio-system -l app=istiod
สถานะพร้อมชื่อเริ่มอายุใหม่
istiod-786779888b-p9s5n 1/1 วิ่ง 0 114m
istiod-1-7-6956db645c-vwhsk 1/1 วิ่ง 0 1m
5) หลังจากนี้ เราจำเป็นต้องเปลี่ยนป้ายกำกับที่มีอยู่ของเนมสเปซคลัสเตอร์ทั้งหมดของเรา ซึ่งเราจำเป็นต้องใส่คอนเทนเนอร์พร็อกซี istio จำเป็นต้องลบป้ายกำกับ "istio-injection" เก่าออก และเพิ่มป้ายกำกับ istio.io/rev เพื่อชี้ไปที่การแก้ไข canary 1-8
$ kubectl ป้ายเนมสเปซ test-ns istio-injection- istio.io/rev=1-8
หวังว่า ณ จุดนี้ สภาพแวดล้อมจะเสถียรด้วยการกำหนดค่า istio แบบเก่า และเราสามารถตัดสินใจได้ว่าแอปพ็อดใดที่สามารถรีสตาร์ทได้เพื่อให้ระนาบการควบคุมใหม่เปลี่ยนแปลงตามการหยุดทำงานของเรา และอนุญาตให้เรียกใช้บางแอปด้วยระนาบการควบคุมที่เก่ากว่าและ อีกอันที่มีคอนฟิกูเรชันระนาบคอนโทรลเลอร์ใหม่ ณ จุดนี้
เช่น: การเปิดตัว kubectl เริ่มการปรับใช้ใหม่ -n test-ns (ครั้งแรก)
การเปิดตัว kubectl เริ่มการปรับใช้ใหม่ -n test-ns2 (ภายหลัง)
การเปิดตัว kubectl เริ่มการปรับใช้ใหม่ -n test-ns3 (อีกครั้งในภายหลัง)
6) เมื่อเราวางแผนสำหรับการหยุดทำงานและเริ่มการปรับใช้ใหม่ตามที่เราตัดสินใจแล้ว ให้ยืนยันว่าพ็อดทั้งหมดกำลังใช้ dataplane proxy injector เวอร์ชัน 1.8 เท่านั้น
kubectl รับพ็อด -n test-ns -l istio.io/rev=1-8
7) เพื่อตรวจสอบว่าพ็อดใหม่ในเนมสเปซ test-ns กำลังใช้บริการ istiod-canary ที่สอดคล้องกับการแก้ไข canary
สถานะพร็อกซี istioctl | grep ${pod_name} | awk '{พิมพ์ $7}'
8) หลังจากอัปเกรดทั้ง Control Plane และ Data Plane แล้ว สามารถถอนการติดตั้ง Control Plane เก่าได้
istioctl x ถอนการติดตั้ง -f /tmp/iop.yaml
ต้องล้างจุดด้านล่างก่อนอัปเกรด.
- ขั้นตอนทั้งหมดที่เตรียมไว้สำหรับการอัปเกรดข้างต้นนั้นดีสำหรับการดำเนินการต่อสำหรับสภาพแวดล้อม Prod ที่มีการใช้งานสูงหรือไม่
- โดยการส่งออก iop สถานะที่ติดตั้งก็เพียงพอแล้วที่จะได้รับขั้นตอนที่กำหนดเองทั้งหมดเพื่อดำเนินการอัปเกรด canary? หรือมีโอกาสที่จะหยุดการอัปเกรดหรือการตั้งค่าใด ๆ หายไปหรือไม่?
- ขั้นตอนที่ 4 ด้านบนจะสร้างระนาบควบคุม 1.8 istio พร้อมการปรับแต่งทั้งหมดที่เรามีอยู่แล้วโดยไม่มีการหยุดชะงักหรือขาดหายไปหรือไม่
- หลังจากขั้นตอนที่ 4 เราจำเป็นต้องมีการกำหนดค่าเพิ่มเติมใดๆ ที่เกี่ยวข้องกับการกำหนดค่าบริการ istiod> เอกสารที่ตามมาไม่ชัดเจนเกี่ยวกับสิ่งนั้น
- สำหรับขั้นตอนที่ 5 ข้างต้น เราจะระบุเนมสเปซทั้งหมดได้อย่างไร โดยที่เราเปิดใช้งาน istio-injection และแก้ไขเฉพาะเนมสเปซเหล่านั้นเพียงอย่างเดียวและปล่อยให้เนมสเปซอื่นเหมือนเดิม
- ดังนั้นสำหรับขั้นตอนที่ 8 ข้างต้น จะแน่ใจได้อย่างไรว่าเรากำลังถอนการติดตั้งเฉพาะ Control Plane เก่า เราต้องได้รับไบนารีสำหรับ controlplane เก่าพูด (1.7 ในกรณีของฉัน) และใช้ไบนารีนั้นกับ /tmp/iop.yaml ที่ส่งออกเหมือนกัน ?
- ไม่มีความคิดเกี่ยวกับวิธีย้อนกลับปัญหาใดๆ ที่เกิดขึ้นระหว่าง.. ก่อนหรือหลังการลบคอนโทรลเพลนเก่า