การใช้งาน Operator เดิมบนคลัสเตอร์

แพลตฟอร์มนี้จำเป็นต้องใช้งาน Kubernetes operator จำนวน 3 ตัว ได้แก่ cert-manager Redis operator และ CloudNativePG โดยค่าเริ่มต้นตัว chart จะทำหน้าที่ติดตั้งสิ่งเหล่านี้ให้คุณโดยอัตโนมัติ หากคลัสเตอร์ของคุณมีการเปิดใช้งานเวอร์ชันที่เข้ากันได้อยู่ก่อนแล้ว คุณสามารถเลือกสั่งให้ใช้งานระบบเดิมเหล่านั้นแทนเพื่อหลีกเลี่ยงการติดตั้งซ้ำซ้อนได้

เอกสารนี้เหมาะสำหรับใคร

วิศวกรแพลตฟอร์ม (platform engineer) ที่ต้องการติดตั้งและเชื่อมโยง gateway เข้ากับคลัสเตอร์เดิมที่มีการใช้งาน operator ร่วมกันอยู่แล้ว

สวิตช์ควบคุมทั้งสามตัว

certManager:
  enabled: false     # ใช้งาน cert-manager เดิมที่มีอยู่แล้วบนคลัสเตอร์
redisOperator:
  enabled: false     # ใช้งาน Redis operator เดิมที่มีอยู่แล้ว
cnpg:
  enabled: false     # ใช้งาน CloudNativePG operator เดิมที่มีอยู่แล้ว

แต่ละสวิตช์จะทำหน้าที่ควบคุมเฉพาะส่วนของตัวโปรแกรม operator เท่านั้น ว่าต้องการให้ติดตั้งใหม่หรือไม่ ส่วนทรัพยากรที่กำหนดเองเฉพาะของแพลตฟอร์ม เช่น ใบรับรอง, ตัว Redis instance หรือคลัสเตอร์ PostgreSQL จะยังคงถูกสร้างขึ้นโดยตัว chart และทำงานภายใต้ระบบ operator ที่อยู่บนคลัสเตอร์เช่นเดิม

สวิตช์	ระบบเดิมที่จะใช้งาน	จำเป็นต้องใช้เมื่อ
certManager.enabled	cert-manager	กำหนดโหมด tls.mode เป็น letsencrypt หรือ selfsigned
redisOperator.enabled	Redis operator	กำหนดค่า redis.enabled: true
cnpg.enabled	CloudNativePG	กำหนดค่า postgres.enabled: true หรือ keycloak.enabled: true

ตรวจสอบเวอร์ชันที่ผ่านการทดสอบ

operator เดิมที่อยู่บนคลัสเตอร์จะต้องเป็นเวอร์ชันที่เข้ากันได้ดีกับเวอร์ชันที่ระบุใน chart ซึ่งข้อมูลเวอร์ชันที่ผ่านการทดสอบจะแสดงอยู่ในส่วนคอมโพเนนต์เมทริกซ์ (component matrix) ของผลิตภัณฑ์ โปรดเปรียบเทียบข้อมูลเวอร์ชันดังกล่าวกับระบบบนคลัสเตอร์ของคุณก่อนที่จะปิดการใช้งานสวิตช์ควบคุม ดูรายละเอียดเพิ่มเติมได้ที่ การอัปเกรดระบบ

เปรียบเทียบระหว่างการใช้งานระบบเดิมกับการสั่งติดตั้งใหม่ผ่าน chart

• เลือกใช้งานระบบเดิม: เมื่อ operator เหล่านี้เป็นโครงสร้างพื้นฐานที่ใช้งานร่วมกันบนคลัสเตอร์ซึ่งดูแลโดยทีมอื่น หรือเมื่อคุณต้องการลดจำนวนชุดอิมเมจสำหรับการติดตั้งใน ระบบปิด (air-gapped)
• สั่งติดตั้งผ่าน chart (ค่าเริ่มต้น): เมื่อคลัสเตอร์นี้จัดเตรียมไว้เพื่อใช้รันเกตเวย์โดยเฉพาะ หรือเมื่อคุณต้องการให้แพลตฟอร์มนี้ทำหน้าที่จบครบในตัวเองทั้งหมดและสามารถจำลองการติดตั้งระบบใหม่ขึ้นมาได้จาก chart เพียงตัวเดียว

ทรัพยากรที่กำหนดเองยังคงอยู่ภายใต้การบริหารจัดการของแพลตฟอร์ม

แม้จะมีการกำหนดให้ปิดสวิตช์ควบคุมทั้งสามตัวแล้วก็ตาม ตัว chart จะยังคงทำหน้าที่เป็นเจ้าของและดำเนินกระบวนการปรับประสานสถานะ (reconcile) ให้แก่ใบรับรอง, Redis instance และคลัสเตอร์ PostgreSQL ของตนเองตามปกติ โดยคุณมีหน้าที่คอยดูแลโปรแกรม operator ส่วนตัวแพลตฟอร์มจะคอยดูแลทรัพยากรภายในระบบของตนเอง โครงสร้างลักษณะนี้จะช่วยรักษารูปแบบที่จำลองระบบใหม่ขึ้นมาจาก chart ได้อย่างสมบูรณ์ ในขณะเดียวกันก็เข้ากันได้ดีกับโครงสร้าง operator ที่คุณมีอยู่แล้ว

ขั้นตอนต่อไป

• การติดตั้งในระบบปิด (Air-gapped install) — การลดจำนวน operator จะช่วยลดจำนวนอิมเมจที่ต้องทำสำเนาลงด้วย
• ระบบความพร้อมใช้งานสูง (High availability) — โครงสร้างการขยายระบบฐานข้อมูลและคลัสเตอร์ Redis
• การสำรองข้อมูลและการกู้คืน (Backup & DR) — การดูแลความปลอดภัยของข้อมูลใน CloudNativePG