การติดตั้งใช้งานจริงในรูปแบบพร้อมใช้งานสูง (HA)

ขั้นตอนการสั่งงานแบบทีละขั้นตอนและสามารถคัดลอกไปวางเพื่อติดตั้งระบบ Opsta AI Gateway ทั้งหมดในรูปแบบพร้อมใช้งานสูง (High-availability หรือ HA) บนคลัสเตอร์ Kubernetes ที่ได้มาตรฐาน โดยชุดระบบทั้งหมดที่ประกอบไปด้วย Higress, PostgreSQL, Redis, Keycloak, ระบบตรวจสอบสถานะการทำงาน LGTM, cert-manager และ control plane กับหน้าเว็บ console ของเราจะถูกติดตั้งรวมกันเป็นหน่วยที่ระบุเวอร์ชันเดียวกันทั้งหมด

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

วิศวกรแพลตฟอร์ม (platform engineer) ที่ทำหน้าที่ติดตั้งระบบ โดยคุณต้องเป็นผู้จัดเตรียมคลัสเตอร์ Kubernetes แบบพร้อมใช้งานสูงที่ได้มาตรฐาน ระบบจัดเก็บข้อมูล และระบบ DNS รวมถึงระบบยืนยันตัวตน IdP ภายนอกและระบบจัดเก็บข้อมูลออบเจกต์ (หากต้องการใช้งาน) ทั้งนี้ ตัวซอฟต์แวร์ระบบจะติดตั้งด้วยวิธีเดียวกันในทุกๆ ดิสทริบิวชันที่รองรับ โดยจะมีความแตกต่างกันเฉพาะขั้นตอนการเตรียมคลัสเตอร์ในขั้นที่ 0 (Phase 0) เท่านั้น สำหรับความต้องการใช้งานระบบทดสอบแบบโหนดเดี่ยว สามารถดูรายละเอียดได้ที่หัวข้อ คู่มือเริ่มต้นด่วนแบบ Standalone

ตรวจสอบข้อมูลความถูกต้องก่อนเริ่มใช้งานจริง

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

ก่อนเริ่มต้นทำงาน โปรดศึกษา สถาปัตยกรรมอ้างอิง (Reference architecture) เพื่อเข้าใจระบบที่จะติดตั้งและเหตุผล รวมถึงดำเนินการตรวจสอบตาม รายการตรวจสอบความพร้อมสำหรับใช้งานจริง (Production-readiness checklist) ให้เรียบร้อย โดยคู่มือการติดตั้งนี้เป็นเพียงขั้นตอนการรันระบบตามรูปแบบสถาปัตยกรรมดังกล่าวและจะไม่มีการอธิบายหลักการซ้ำในหน้านี้

แพลตฟอร์มที่รองรับ

ระบบเกตเวย์นี้สามารถทำงานได้บนระบบ Kubernetes มาตรฐานที่คุณต้องการ ซึ่งขั้นตอนการติดตั้งในขั้นที่ 1 ถึง 5 จะเหมือนกันทั้งหมด โดยจะมีความแตกต่างเฉพาะส่วนของขั้นที่ 0 ที่เกี่ยวกับการเตรียมระบบคลัสเตอร์ซึ่งเป็นไปตามแต่ละแพลตฟอร์ม

สภาพแวดล้อมระบบ	ดิสทริบิวชัน	วิธีการเตรียมคลัสเตอร์
On-prem (ค่าเริ่มต้น)	Rancher / RKE2	ดำเนินการโดยทีมแพลตฟอร์มของคุณ หรือให้ทีมวิศวกรระบบของ Opsta เป็นผู้ดำเนินการหลัก โดยสามารถดูรายละเอียดในส่วนของ Phase 0
On-prem	OpenShift	ตัวติดตั้งของ Red Hat ทั้งรูปแบบ IPI หรือ UPI
On-prem	VMware Tanzu (TKG)	เครื่องมือจัดการคลัสเตอร์ของ Tanzu
Cloud	GKE / AKS / EKS / CCE / OKE	บริการระบบ Kubernetes ที่จัดการโดยผู้ให้บริการคลาวด์นั้นๆ

---

การตรวจสอบก่อนเริ่มงาน สิ่งที่จำเป็นต้องมีก่อนเริ่มต้น

โปรดกรอกข้อมูลในใบงานนี้ก่อนเริ่มต้น เนื่องจากขั้นตอนหลังจากนี้ทั้งหมดจะมีการอ้างอิงข้อมูลส่วนนี้ และยังไม่มีคำสั่งใดๆ รันจริงในตอนนี้

1. คลัสเตอร์แบบพร้อมใช้งานสูงที่ได้มาตรฐาน

ต้องได้รับการจัดเตรียมในขั้นที่ 0 โดยอ้างอิงขนาดทรัพยากรระบบจากหน้า ข้อกำหนดของระบบ ได้แก่ มี worker node ตั้งแต่ 3 โหนดขึ้นไป เพื่อรองรับการกระจายตัวของ replicas แบบ HA ตามกฎ anti-affinity โดยแต่ละโหนดต้องมีทรัพยากรอย่างน้อย 4 vCPU และแรม 8 GiB ขึ้นไป หรือมีขนาดแนะนำอยู่ที่ 8 vCPU และแรม 16 GiB พร้อมพื้นที่ SSD ขนาด 100 GiB อีกทั้งระบบ CNI ต้องรองรับการบังคับใช้ NetworkPolicy และมี StorageClass เริ่มต้นที่มีโหมดการเข้าถึงแบบ ReadWriteOnce (RWO) อยู่ในระบบ

• ดิสทริบิวชันที่เลือก: __________ · โหนด (จำนวนและขนาด): __________

2. ระบบ DNS

• โดเมน *.<baseDomain> ชี้ไปยังไอพีของ ingress ซึ่งได้จากขั้นตอนที่ 5 โดยมีโดเมนหลัก baseDomain คือ __________
• โดเมนย่อยที่จะถูกใช้งานภายใต้โดเมนหลัก ได้แก่ api, console, auth, grafana และ mcp

3. ใบรับรอง TLS

• โหมด letsencrypt โดยที่ cert-manager จะขอและต่ออายุใบรับรองผ่านวิธี DNS-01 หรือ HTTP-01 หรือ โหมด provided ในกรณีที่คุณต้องการนำใบรับรอง wildcard และคีย์สำหรับโดเมน *.<baseDomain> มาติดตั้งใช้งานเอง ซึ่งจะถูกเก็บไว้ใน secrets และห้ามนำไปเก็บไว้ในระบบ git
• โหมดที่เลือก: __________ · (ในกรณีเลือกโหมด provided) ใบรับรองและคีย์พร้อมใช้งาน: ☐

4. ระบบจัดเก็บออบเจกต์ (Object store)

ถังเก็บข้อมูลที่เข้ากันได้กับโปรโตคอล S3 และข้อมูลยืนยันตัวตนเพื่อใช้งานกับชุดระบบ LGTM (สำหรับเก็บข้อมูล logs, metrics และ traces) และระบบสำรองข้อมูล PostgreSQL ซึ่งถือเป็นข้อกำหนดของระบบความพร้อมในการใช้งานจริง หากต้องการติดตั้งภายในองค์กรเองสามารถใช้งาน SeaweedFS ได้

• ลิงก์เชื่อมต่อ (Endpoint): __________ · ชื่อถังข้อมูล (Bucket): __________ · ข้อมูลความลับเก็บไว้ใน vault เรียบร้อย: ☐

5. ระบบกระจายโหลด (Load balancer สำหรับไอพี ingress)

ระบบเกตเวย์จะรับส่งข้อมูลผ่านทางบริการประเภท LoadBalancer โดยโดเมน *.<baseDomain> จะชี้ไปยังไอพีสาธารณะดังกล่าว

• Cloud LoadBalancer จะถูกจัดเตรียมให้อัตโนมัติสำหรับบริการที่เป็นประเภท LoadBalancer
• ระบบกระจายโหลดที่จัดเตรียมเองหรือระบบที่มีอยู่เดิม คุณสามารถชี้ระบบกระจายโหลดระดับ L4 ของคุณ เช่น F5, HAProxy, NSX หรือระบบอื่น ไปยังไอพีของโหนดและ NodePort หรือจะระบุไอพีภายนอกที่ระบบกระจายโหลดของคุณใช้งานอยู่ให้แก่บริการโดยตรงก็ได้
• MetalLB สำหรับระบบติดตั้งบนเซิร์ฟเวอร์จริง (bare-metal) ที่ไม่มีระบบกระจายโหลดภายนอก โดยจะจ่ายไอพีจากช่วงไอพีที่คุณเป็นเจ้าของ
• ระบบที่เลือก: __________ · ไอพีของ ingress เมื่อเปิดใช้งานแล้ว: __________

6. ผู้ให้บริการยืนยันตัวตนภายนอก (ตัวเลือกเพิ่มเติม)

• ประเภทผู้ให้บริการ: __________ (โหมด OIDC หรือ SAML) · ค่า client id และ secret บันทึกใน vault เรียบร้อย: ☐ · โดเมนอีเมลที่ได้รับอนุญาตให้เข้าใช้งาน: __________

7. คีย์สำหรับผู้ให้บริการ LLM

• คีย์สำหรับผู้ให้บริการโมเดลอย่างน้อยหนึ่งรายการ โดยเก็บไว้ใน secrets และห้ามนำไปบันทึกใน git ชื่อผู้ให้บริการ: __________ · บันทึกใน vault เรียบร้อย: ☐

8. เครื่องมือการทำงานบนเครื่องของสถาปนิก

โปรแกรม kubectl โปรแกรม helm ที่ล็อกเวอร์ชันตามข้อมูลในหน้า การอัปเกรด (Upgrades) โปรแกรม helmfile, yq, jq รวมถึงเครื่องมือจัดการใบรับรองและข้อมูลความลับอื่นๆ โดยตัว chart จะถูกดาวน์โหลดจาก OCI registry ปลายทาง oci://ghcr.io/opsta/opsta-ai-gateway/charts ตามรุ่นเวอร์ชัน vX.Y.Z ที่กำหนดไว้ ทำให้ไม่จำเป็นต้องทำการโคลนซอร์สโค้ดของโปรเจกต์มาเพื่อติดตั้ง

---

สถานะการทดสอบความถูกต้อง

ผลการรันระบบจริง

ระบบ การติดตั้งและเส้นทางการรับส่งข้อมูล (Phases 1-3) ได้รับการทดสอบจริงตั้งแต่เริ่มต้นบนคลัสเตอร์ใหม่ในรุ่น v1.12.0 โดยขั้นตอน helmfile sync สำเร็จเรียบร้อย pod ทำงานปกติ และรายการคำสั่งใช้งานโมเดลทั้ง 120 ครั้งทำงานสำเร็จที่รหัสสถานะ 200 รวมถึงระบบ guardrail บล็อกคำสั่งได้ถูกต้อง ส่วนขั้นตอนติดตั้งผ่าน OCI chart นั้นจะถูกใช้งานในการติดตั้งจริงของทุกระบบอยู่เสมอ

ผลการทดสอบบนคลัสเตอร์จริงระบบคลาวด์แบบหลายโหนด (GKE ขนาด 4 โหนด เมื่อวันที่ 18 มิถุนายน 2026) การติดตั้งระบบทั้งหมดบนคลัสเตอร์ปกติโดยดึง chart รุ่นใช้งานและอิมเมจส่วนตัวสำเร็จเรียบร้อยดี โดยทุกส่วนประกอบ ได้แก่ Higress, control plane, console, Postgres (CNPG), Redis, Keycloak และชุดระบบ LGTM สามารถทำงานได้เป็นปกติในการติดตั้งใหม่ มีการใช้งานระบบกระจายโหลด cloud LoadBalancer เป็นช่องทางเข้าของข้อมูล มีการควบคุมเส้นทางข้อมูลที่เป็นปกติ ตัวอย่างเช่น การเรียก API โดยไม่มีคีย์ส่งผลกลับมาเป็นรหัส 401 จากส่วนตรวจสอบความปลอดภัย หน้าเว็บ console มีการทำ redirect รหัส 302 ไปยังหน้ายืนยันตัวตน SSO ส่วนของ Keycloak สามารถเข้าถึงได้ และมีการตั้งค่าบัญชีผู้ดูแลระบบภายใน Keycloak สำเร็จเรียบร้อย ทั้งนี้ มีปัญหาระบบแบบหลายโหนดสองรายการที่พบและได้รับการแก้ไขแล้ว ได้แก่ การติดตั้ง Gateway API CRD จะต้องทำก่อนการเริ่มติดตั้ง chart (ในขั้นที่ 2 ขั้นตอนที่ 1 เนื่องจากคลัสเตอร์แบบ managed จะไม่มีไฟล์เหล่านี้มาให้ล่วงหน้า) และตัวรันข้อมูล seed ของโมเดลเวกเตอร์จะต้องไม่มีการแชร์ PVC ร่วมกันข้ามโหนด

สิ่งที่อยู่ระหว่างการทดสอบในระบบ HA เพิ่มเติม การสลับการทำงานเมื่อเกิดความเสียหายในระบบ HA เช่น การทำ failover ของ Postgres และ Redis ที่มี 3 replicas กฎการแยกโหนดแบบ anti-affinity เมื่อโหนดเสียหาย และระบบสำรองข้อมูลภาพรวม โดยจะมีการระบุหมายเหตุไว้ในหัวข้อที่เกี่ยวข้องกับการทำงานเหล่านั้น

---

ขั้นตอนการติดตั้งใช้งาน

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

Phase 0 การเตรียมคลัสเตอร์ที่ได้มาตรฐาน

ดำเนินการรันคลัสเตอร์ Kubernetes แบบพร้อมใช้งานสูงบนแพลตฟอร์มที่คุณเลือกตามรายละเอียดในตารางด้านบน โดยมีคุณสมบัติคือ มี worker node ตั้งแต่ 3 โหนดขึ้นไป CNI รองรับกฎ NetworkPolicy มี StorageClass เริ่มต้นแบบ RWO มีถังเก็บข้อมูลออบเจกต์ที่เข้าใช้งานได้ และมีไอพีทางเข้าของเกตเวย์ผ่านระบบกระจายโหลดที่เหมาะสม ทั้งนี้ ระบบภายในองค์กรแบบ Rancher หรือ RKE2 จะเป็นรูปแบบเริ่มต้นของ Opsta ซึ่งวิศวกรระบบของ Opsta จะทำหน้าที่จัดเตรียมโครงสร้างนี้ตามคู่มือการจัดหาของบริษัท สำหรับแพลตฟอร์มอื่นๆ เช่น OpenShift, Tanzu หรือบริการระบบคลาวด์ ขอให้ดำเนินเตรียมระบบตามเอกสารแนะนำของแต่ละแพลตฟอร์ม โดยขั้นตอนการติดตั้งหลังจากนี้จะเหมือนกันทั้งหมดโดยไม่ขึ้นกับกระบวนการเตรียมคลัสเตอร์ในขั้นนี้

Phase 1 การกำหนดค่าระบบซอฟต์แวร์

ความตั้งใจของขั้นตอน กำหนดค่าตัวแปรและข้อมูลความลับสำหรับการติดตั้งระบบผ่านไฟล์ 2 ไฟล์คือ ไฟล์ values ทั่วไปสำหรับข้อมูลกำหนดค่า และไฟล์ secrets-values.yaml ที่มีข้อมูลสำคัญและต้องไม่นำไปเก็บไว้ในระบบ git

1. ไฟล์กำหนดค่าทั่วไป (Values) ให้กำหนดค่าเริ่มต้นอย่างน้อยดังนี้

   global:
     baseDomain: <your-domain>          # เช่น ai-gateway.example.com
     highAvailability: true             # เปิดใช้งานระบบ HA; ให้กำหนดเป็น false สำหรับโหมด standalone
     storageClass: <your-default-sc>
   tls:
     mode: letsencrypt                  # หรือ "provided" ในกรณีที่เตรียมใบรับรอง wildcard มาติดตั้งเอง
   postgres:
     backup: { enabled: true }          # เปิดใช้การสำรองข้อมูลคู่กับการระบุค่าในไฟล์ secret

2. ไฟล์ข้อมูลความลับ (Secrets) โดยใช้ไฟล์ตัวอย่างเป็นต้นแบบและต้องไม่ commit ไฟล์นี้เข้าสู่ git

   cp secrets-values.example.yaml secrets-values.yaml
   ./gen-secrets.sh secrets-values.yaml        # สร้างข้อมูลความลับที่ปลอดภัยในช่อง GENERATE อัตโนมัติ
   # จากนั้นแก้ไขข้อมูลในไฟล์ secrets-values.yaml: ใส่คีย์ API สำหรับผู้ให้บริการ LLM ค่า secret สำหรับ IdP
   # ข้อมูลยืนยันตัวตนสำหรับถังเก็บข้อมูล และใบรับรอง wildcard พร้อมคีย์ (หากใช้โหมด provided) โดยดึงข้อมูลจาก vault

   การตั้งค่า secrets.createFromValues: true จะทำหน้าที่แปลงข้อมูลเหล่านี้เป็น Kubernetes Secrets ในขั้นตอนติดตั้งระบบโดยอัตโนมัติ
3. การดาวน์โหลดอิมเมจ (Image pull) อิมเมจระบบที่ใช้งานเป็นอิมเมจส่วนตัวและรันอยู่ในเนมสเปซหลายตัว ให้กำหนดข้อมูลการเข้าถึงเพื่อดึงข้อมูลอิมเมจโดยใช้รหัสโทเค็นที่มีสิทธิ์อ่านแพ็กเกจ ซึ่งได้รับจากทาง Opsta จากนั้นระบบจะสร้าง pull secret ชื่อ ghcr-pull ในทุกๆ เนมสเปซที่เกี่ยวข้องโดยอัตโนมัติ ทำให้ไม่จำเป็นต้องสั่งคำสั่งสร้าง secret แยกทีละเนมสเปซด้วยตัวเอง

   secrets:
     registryAuth:
       create: true
       server: ghcr.io
       username: <ghcr-user>          # ชื่อผู้ใช้และรหัสผ่านจะถูกบันทึกไว้ใน secrets-values.yaml และจะไม่เก็บใน git
       password: <token-with-read:packages>

ผลการตรวจสอบความถูกต้อง

กระบวนการกำหนดค่าใช้งานร่วมกับไฟล์ secrets-values.yaml สคริปต์ gen-secrets.sh และการตั้งค่า createFromValues เป็นกระบวนการมาตรฐานที่ใช้ในการติดตั้งของทุกๆ สภาพแวดล้อมระบบ ไม่ว่าจะเป็นระบบทดสอบหรือระบบใช้งานจริง

Phase 2 การติดตั้งระบบ

ความตั้งใจของขั้นตอน ทำการติดตั้งไฟล์คำจำกัดความทรัพยากร (CRDs) ของ Gateway API จากนั้นสั่งงานเพื่อให้ sync ระบบทั้งหมดจาก OCI chart ล่าสุดด้วยคำสั่งเดียว ซึ่งระบบจะเรียงลำดับการติดตั้งไล่ตั้งแต่ระบบดำเนินการหลัก (operator) ไปจนถึงเกตเวย์และ Keycloak ตามที่ระบุการขึ้นต่อกันไว้

# 1. ติดตั้ง Gateway API CRDs (ในระดับฝั่งเซิร์ฟเวอร์เนื่องจากทรัพยากร HTTPRoute มีขนาดเกินขีดจำกัดปกติ)
kubectl apply --server-side --force-conflicts -f \
  https://github.com/opsta/opsta-ai-gateway/raw/v1.12.0/manifests/crds/gateway-api/experimental-install.yaml

# 2. ลงชื่อเข้าใช้งานคลังเก็บข้อมูลเพื่อดาวน์โหลด จากนั้นทำกระบวนการติดตั้งระบบตามรุ่นเวอร์ชันที่เจาะจง
echo "$GHCR_TOKEN" | helm registry login ghcr.io -u <user> --password-stdin
PRODUCT_VERSION=v1.12.0 helmfile -e <your-env> sync --sync-args "--server-side=false --timeout 20m"

คำสั่ง helmfile sync จะทำการติดตั้งไล่เรียงกันไปตามลำดับ ได้แก่ cert-manager, redis-operator, cnpg, LGTM, opsta-ai-gateway และ Keycloak โดยคุณสามารถตรวจสอบสถานะการติดตั้งได้ด้วยคำสั่งนี้

kubectl get pods -A

ผลลัพธ์ที่คาดหวัง ทุกส่วนประกอบทำงานอยู่ในสถานะปกติ (Running) สำหรับการติดตั้งใหม่ตั้งแต่ต้นในรุ่น v1.12.0 ของระบบ standalone ที่ผ่านการตรวจสอบความถูกต้องแล้ว ตัวระบบจะทำงานสมบูรณ์โดยที่ pod หลักทั้งหมดอยู่ในสถานะ Running ได้แก่ เกตเวย์และตัวควบคุม Higress, control plane, console, Postgres (CNPG), Redis, Keycloak และชุดระบบ LGTM ทั้งหมด และปลั๊กอินประเภท WasmPlugin ได้รับการลงทะเบียนเรียบร้อยในระบบ ซึ่งคุณสามารถรันคำสั่ง kubectl get wasmplugin -A เพื่อตรวจสอบว่าปลั๊กอินประเภทการตรวจสอบคีย์ การเก็บสถิติ การจัดเส้นทาง หรือปลั๊กอินเสริมอื่นๆ ถูกโหลดทำงานเป็นปกติเรียบร้อยดี

Phase 3 การตรวจสอบความถูกต้องของระบบที่ติดตั้ง

ความตั้งใจของขั้นตอน ตรวจสอบว่าระบบสามารถรับส่งข้อมูลและทำงานได้จริง ไม่ใช่เพียงแค่ตรวจสอบว่าสถานะของ pod ทำงานอยู่เท่านั้น

# ส่งคำสั่งเรียกใช้โมเดลผ่านทางเกตเวย์โดยแนบคีย์ของโครงการเพื่อตรวจสอบผลลัพธ์รหัสสถานะ HTTP 200
curl -s https://api-<baseDomain>/v1/chat/completions \
  -H "Authorization: Bearer <project-key>" -H 'Content-Type: application/json' \
  -d '{"model":"<your-model>","messages":[{"role":"user","content":"say hello"}]}'

ผลลัพธ์ที่คาดหวัง ระบบส่งกลับรหัสสถานะ 200 พร้อมข้อความตอบกลับจากโมเดลปกติ จากนั้นให้ทำการยืนยันการเข้าถึงส่วนการทำงานต่างๆ ต่อไปนี้

• ระบบ API สามารถตอบรับข้อมูลและควบคุมการใช้งานได้ โดยผลลัพธ์จากการทดสอบแบบต้นทางถึงปลายทางยืนยันว่า การเรียกใช้งานส่งผลสำเร็จรหัส 200 ทั้งหมด 120 ครั้ง และความพยายามส่งคำสั่งไม่ปลอดภัยเพื่อแฮกโมเดลทั้ง 3 ครั้งถูกตรวจจับและบล็อกได้สำเร็จ โดยระบบ guardrails
• หน้าเว็บ Console สามารถเข้าผ่านทาง https://console-<baseDomain>/ เพื่อเข้าสู่ระบบยืนยันตัวตน SSO และแสดงหน้าหลักของผู้ดูแลระบบได้ปกติ
• ระบบกราฟข้อมูล Grafana ที่เข้าถึงได้ผ่าน https://grafana-<baseDomain>/ จะแสดงข้อมูลปริมาณการใช้โทเค็นและจำนวนเงินที่ใช้งานบนแดชบอร์ด
• ระบบ Keycloak ที่พอร์ต https://auth-<baseDomain>/ สามารถเข้าใช้งานได้ปกติและไม่มีข้อผิดพลาดในระบบควบคุมหลัก
• สำหรับการทำงานแบบพร้อมใช้งานสูง (HA) จะต้องมีประวัติการสำรองข้อมูลของ PostgreSQL ครั้งแรกสำเร็จเรียบร้อยดี ซึ่งสามารถดูรายละเอียดได้ที่หน้า การสำรองข้อมูลและการกู้คืน (Backup & DR)

ผลการตรวจสอบความถูกต้อง

ขั้นตอนการทำงานในส่วนนี้ผ่านการรันจริงบนคลัสเตอร์ใหม่ด้วยซอฟต์แวร์รุ่น v1.12.0 โดยเริ่มติดตั้ง helmfile sync สำเร็จเรียบร้อยดี และการสั่งงานทดสอบทั้ง 120 ครั้งได้รับผลลัพธ์ปกติ อีกทั้งเส้นทางการติดตั้ง OCI chart จะถูกทดสอบและใช้งานร่วมกับการติดตั้งจริงของทุกระบบอยู่เสมอ

Phase 4 การตั้งค่าระบบสำหรับวันแรกของการใช้งาน (Day-1 configuration)

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

1. ลงชื่อเข้าใช้งานด้วยบัญชีผู้ดูแลระบบเริ่มต้น เปิดหน้าเว็บ https://console-<baseDomain>/ เพื่อลงชื่อเข้าใช้งาน โดยบัญชีและรหัสผ่านเริ่มต้นจะระบุไว้ในขั้นตอนติดตั้งที่ค่าความปลอดภัย controlPlane.bootstrapAdmin โปรดเก็บบัญชีนี้ไว้ในคลังความลับของคุณและสามารถดูรายละเอียดได้ที่หน้าแนะนำ การใช้งาน Console
2. ตั้งค่าเชื่อมต่อระบบ IdP ภายนอกและกำหนดโดเมนอีเมลขององค์กร เพื่อให้พนักงานสามารถเข้าใช้งานผ่านระบบยืนยันตัวตนของบริษัท และจำกัดสิทธิ์ให้เข้าได้เฉพาะพนักงานขององค์กรเท่านั้น โดยศึกษาได้ที่หน้า ระบบยืนยันตัวตน SSO และ IdP
3. สร้างข้อมูลองค์กร โครงการ และเพิ่มสมาชิก โดยศึกษาได้ที่หน้า การจัดการองค์กรและสมาชิก
4. ออกคีย์ API สำหรับโครงการ โดยเป็นคีย์เดียวที่รองรับทั้งการเรียกใช้ส่งคุยทั่วไปและการใช้งานคู่กับเครื่องมืออื่น โดยศึกษาได้ที่หน้า การจัดการคีย์ API
5. กำหนดงบประมาณใช้งานและเปิดใช้งานระบบควบคุมคำสั่งปลอดภัย (guardrails) สำหรับโครงการ โดยศึกษาได้ที่หน้า งบประมาณและขีดจำกัดการใช้งาน และ การตั้งค่า guardrail
6. ทดสอบระบบแบบต้นทางถึงปลายทาง นำคีย์ที่ออกไปกำหนดค่าในแอปพลิเคชันของคุณตามแนวทาง การเชื่อมโยงระบบของลูกค้าเข้ากับเกตเวย์ เพื่อลองส่งคำสั่งและยืนยันว่าการใช้โทเค็นและจำนวนเงินถูกบันทึกเข้าระบบจริง ซึ่งเป็นเส้นทางการทำงานเดียวกับที่ได้ทดสอบความปลอดภัยใน Phase 3

Phase 5 การลงนามรับรองมาตรการความมั่นคงปลอดภัยระบบใช้งานจริง (Production hardening sign-off)

ความตั้งใจของขั้นตอน ด่านสุดท้ายก่อนเปิดใช้งานระบบจริง ให้คุณตรวจสอบข้อมูลรายการใน รายการตรวจสอบความพร้อมสำหรับใช้งานจริง (Production-readiness checklist) ทั้งหมดและบันทึกผลลัพธ์ดังนี้

• ยืนยันมาตรการความปลอดภัยในรายการตรวจสอบทุกข้อ หรือบันทึกรายการดังกล่าวเป็นรายการที่ยอมรับความเสี่ยงได้โดยมีระบุผู้รับผิดชอบดูแล สามารถดูได้ที่หน้า ตารางความรับผิดชอบร่วมกันและระดับความพร้อมในการใช้งาน (Shared-responsibility & maturity matrix) เพื่อตรวจสอบว่าขอบเขตใดเป็นหน้าที่ของคุณและขอบเขตใดเป็นของบริษัท Opsta
• บันทึกข้อมูลระยะเวลา RTO และข้อมูลที่เสียหายได้ RPO ที่ได้จากการซักซ้อมกระบวนการสำรองและกู้คืนระบบตามรายละเอียดในหน้า การสำรองข้อมูลและการกู้คืน
• ยืนยันว่าการแจ้งเตือนระบบถูกเชื่อมโยงไปยังช่องทางรับข้อความแจ้งเตือนหลักของทีมเรียบร้อยดีแล้วตามข้อมูลหน้า ระบบตรวจสอบการทำงานของแพลตฟอร์ม (Platform observability)
• มอบหมายผู้รับผิดชอบการทำหน้าที่หมุนเวียนคีย์ความลับอย่างชัดเจนสำหรับคีย์ API ของผู้ให้บริการ ข้อมูลความลับของ IdP และไฟล์ใบรับรอง TLS ต่างๆ

เมื่อดำเนินการและลงนามรับรองในเอกสารตารางเรียบร้อยแล้ว ระบบจะถือว่าเข้าสู่ช่วงการทำงานบนระบบใช้งานจริงอย่างเป็นทางการ

---

ภาคผนวก

• ภาคผนวก A คู่มือเริ่มต้นด่วนแบบ Standalone สำหรับการทดสอบ (PoC) รายละเอียดความแตกต่างจากโหมดพร้อมใช้งานสูงคือ การรันบนโหนดเดี่ยวโดยระบุค่า global.highAvailability=false ส่งผลให้มีทรัพยากรเพียง 1 replica ต่อส่วนประกอบและไม่มีการบังคับใช้งานข้อกำหนด PDB หรือ anti-affinity ระบบสำรองข้อมูลเลือกปิดใช้งานได้ และใช้งาน LGTM ในลักษณะ single-binary ที่ติดตั้งรวมกับ Mimir แบบออลอินวัน โดยคำสั่งในการติดตั้งใน Phase 1 ถึง 3 จะเหมือนกันทั้งหมด เพียงแต่ปรับเปลี่ยนไฟล์ values มาใช้รูปแบบสำหรับโหมด standalone ซึ่งกระบวนการนี้เป็นช่องทางที่สั้นที่สุดในการติดตั้งเพื่อทำการทดสอบระบบและได้รับการยืนยันการทำงานถูกต้องเรียบร้อยแล้ว (รันได้ 32 pods ทำงานเป็นปกติและทดสอบส่งงานสำเร็จทั้ง 120 ครั้ง)
• ### ภาคผนวก B การติดตั้งแบบใช้งานในระบบปิด (Air-gap) สำหรับระบบที่ไม่มีสิทธิ์เข้าถึงอินเทอร์เน็ตภายนอก คุณสามารถทำสำเนา chart และอิมเมจทั้งหมดเข้าสู่คลังเก็บอิมเมจภายในองค์กร เช่น Harbor และตั้งค่าเกตเวย์ให้ดึงอิมเมจจากปลายทางดังกล่าว ร่วมถึงการระบุเปิดพอร์ตขาออกไปยังผู้ให้บริการ LLM เฉพาะที่กำหนด โดยสามารถดูรายละเอียดขั้นตอนทั้งหมดได้ที่หน้า การติดตั้งในระบบปิด (Air-gapped install)
• ### ภาคผนวก C การใช้งานตัวจัดการระบบที่มีอยู่แล้วในคลัสเตอร์ (BYO operators สำหรับผู้ใช้ขั้นสูง) คุณสามารถตั้งค่าเปิดใช้งานเพื่อระบุใช้ตัวจัดการระบบประเภท CloudNativePG หรือ Redis หรือ cert-manager ที่ติดตั้งอยู่แล้วในคลัสเตอร์ของคุณแทนการใช้ตัวจัดการที่มาพร้อมกับ Helm chart แม้การบริการสนับสนุนระบบเกตเวย์จะยังครอบคลุมเช่นเดิม แต่กระบวนการดูแลรักษาอัปเดตและช่วงชีวิตของตัวจัดการระบบดังกล่าวจะอยู่ภายใต้การรับผิดชอบของคุณเองทั้งหมด โดยสามารถดูรายละเอียดได้ที่หน้า การใช้งานตัวจัดการระบบที่มีอยู่เดิม
• ### ภาคผนวก D การอัปเกรดและการย้อนกลับ (Upgrade & rollback) การอัปเกรดสามารถทำได้ง่ายโดยการปรับเลขรุ่น PRODUCT_VERSION และรันคำสั่ง helmfile -e <env> sync อีกครั้ง ทั้งนี้ ขอแนะนำให้สำรองข้อมูลฐานข้อมูลล่วงหน้าเสมอก่อนเริ่มทำการอัปเกรดใดๆ เนื่องจากกระบวนการปรับโครงสร้างข้อมูลในระบบควบคุมเป็นแบบปรับเปลี่ยนไปข้างหน้าเท่านั้นและจะไม่สามารถย้อนกลับเวอร์ชันข้อมูลที่มีการเปลี่ยนแปลงโครงสร้างได้อย่างอัตโนมัติ โดยศึกษาเพิ่มเติมได้ที่หน้า ความรับผิดชอบร่วมกันเกี่ยวกับการย้อนกลับระบบ และดูขั้นตอนการอัปเกรดระบบได้ที่หน้า การอัปเกรด (Upgrades)
• ### ภาคผนวก E การถอนการติดตั้งและล้างระบบ (Uninstall / teardown)

  # ถอนการติดตั้งส่วนเสริมและตัวแอปเกตเวย์ออกจากคลัสเตอร์หลัก
  helmfile -e <your-env> destroy
  # โดยปกติระบบจะไม่ลบ PVC ออก เพื่อรักษาสิทธิ์ความปลอดภัยของข้อมูล หากประสงค์ล้างข้อมูลออกทั้งหมดอย่างถาวรให้รันคำสั่งต่อไปนี้
  kubectl get pvc -A | grep -E 'opsta|observability|cnpg|redis'
  # kubectl delete pvc <name> -n <ns>   # รันเฉพาะเมื่อคุณต้องการลบข้อมูลทั้งหมดทิ้งจริงๆ

  จากนั้นจึงดำเนินการลบระบบคลัสเตอร์ตามขั้นตอนของแพลตฟอร์มที่คุณใช้งาน เช่น ลบผ่านทางหน้า Console คลาวด์ หรือลบผ่านระบบ Rancher
• ### ภาคผนวก F การแก้ไขปัญหาเบื้องต้น (Troubleshooting) ข้อมูลเกี่ยวกับสาเหตุข้อผิดพลาดที่มักพบในแต่ละช่วงพร้อมทั้งแนวทางรวบรวมข้อมูลบันทึกข้อผิดพลาดเพื่อนำมาวิเคราะห์ เช่น คำสั่งเก็บล็อกการทำงาน คำสั่งเก็บเหตุการณ์ต่างๆ หรือประวัติรุ่นการอัปเกรด โดยสามารถดูรายละเอียดเพิ่มเติมได้ที่หน้า การแก้ไขปัญหา (Troubleshooting)