กำไร:
- ความสามารถในการเข้าใจออบเจ็กต์พื้นฐาน (Pod, Deployment, Service, ConfigMap, Secret, Namespace) และปรัชญาการประกาศของ Kubernetes และสร้างรายการที่ชัดเจนสำหรับปัญญาประดิษฐ์
- ความสามารถในการจัดทำรายการให้พร้อมสำหรับการผลิตและรักษาความปลอดภัยด้วยการจำกัดทรัพยากร การตรวจสุขภาพ (โพรบ) แท็กรูปภาพคงที่ และ RBAC ที่แคบ
- ความสามารถในการตรวจสอบบริบทที่ถูกต้องก่อนดำเนินการ และใช้ระเบียบวินัยแบบดรายรันกับดรายรัน/ดิฟ
มันง่ายที่จะเรียกใช้คอนเทนเนอร์เดียว แต่การสร้างระบบที่กระจายคอนเทนเนอร์หลายร้อยคอนเทนเนอร์ไปยังเซิร์ฟเวอร์หลายสิบเซิร์ฟเวอร์ รีสตาร์ทโดยอัตโนมัติเมื่อหนึ่งในนั้นขัดข้อง ทำซ้ำเมื่อโหลดเพิ่มขึ้น และอัปเดตโดยมีเวลาหยุดทำงานเป็นศูนย์ นั่นคือการจัดระเบียบ และเครื่องมือมาตรฐานอุตสาหกรรมก็คือ Kubernetes (เรียกสั้นๆ ว่า K8) ซึ่งเป็นแพลตฟอร์มที่ปรับใช้ ปรับขนาด และจัดการคอนเทนเนอร์ทั่วทั้งคลัสเตอร์โดยอัตโนมัติ Kubernetes มีประสิทธิภาพแต่ซับซ้อน ทุกอย่างถูกกำหนดโดยไฟล์ YAML ที่มีความยาวและไวต่อการเยื้อง ซึ่งเรียกว่า manifests นี่คือจุดที่ AI สูดอากาศบริสุทธิ์ ด้วยบริบทที่ถูกต้อง จะสร้างรายการเหล่านี้อย่างรวดเร็วและถอดรหัสข้อผิดพลาดลึกลับ
แต่ใน Kubernetes การแสดงข้อมูลที่ไม่ถูกต้องหมายถึงความล้มเหลวในการให้บริการทั้งหมด ปรับขนาดไม่ถูกต้อง หรือทิ้งช่องโหว่ไว้ เป็นความรับผิดชอบของคุณในการทำความเข้าใจและตรวจสอบแต่ละรายการที่ AI สร้างขึ้น โดยเฉพาะก่อนที่จะใช้ kubectl
ออบเจ็กต์หลักของ Kubernetes
หากต้องการตรวจสอบ Kubernetes คุณควรทราบแนวคิดหลัก:
- พ็อด: หน่วยงานที่เล็กที่สุด; ประกอบด้วยหนึ่งหรือหลายคอนเทนเนอร์ โดยทั่วไปแล้ว Pod จะไม่ถูกใช้โดยตรง แต่จะใช้ออบเจ็กต์พาเรนต์ที่จัดการพ็อดนั้น
- การปรับใช้: กำหนดจำนวนสำเนาของแอปพลิเคชันที่จะรัน รูปภาพที่จะใช้ และวิธีอัปเดต หาก Pod ขัดข้อง มันจะสร้างขึ้นใหม่โดยอัตโนมัติ
- บริการ: จัดเตรียมที่อยู่เครือข่ายแบบคงที่และการปรับสมดุลโหลดให้กับพ็อด แม้ว่าพ็อดจะมาและไป แต่ที่อยู่การเข้าถึงก็ไม่เปลี่ยนแปลง
- ConfigMap และ Secret: เก็บค่าการกำหนดค่าและข้อมูลลับแยกจาก Pods ConfigMap มีไว้สำหรับการตั้งค่าที่ชัดเจน ส่วน Secret ใช้สำหรับค่าที่ละเอียดอ่อน
- เนมสเปซ: พื้นที่ที่แบ่งและแยกทรัพยากรอย่างมีเหตุผล (เช่น dev, prod)
- Ingress: ชุดกฎที่ควบคุมการรับส่งข้อมูล HTTP จากโลกภายนอกไปยังบริการในคลัสเตอร์
Helm เป็น "ผู้จัดการแพ็คเกจ" ของ Kubernetes: ช่วยให้คุณสามารถสร้างเทมเพลตรายการ (แผนภูมิ) ที่เกิดซ้ำและติดตั้งด้วยค่าที่แตกต่างกันในสภาพแวดล้อมที่แตกต่างกันด้วยคำสั่งเดียว AI สร้างทั้งแผนภูมิรายการดิบและแผนภูมิ Helm
เหตุใดจึงมีวัตถุมากมาย? เนื่องจากปรัชญาหลักของ Kubernetes นั้นมีความชัดเจน: คุณกำหนด "วิธีที่คุณต้องการให้ระบบมีรูปลักษณ์ในท้ายที่สุด" (เช่น "มีสำเนาของแอปพลิเคชันนี้ทำงานอยู่ 3 ชุดเสมอ") ในขณะที่ Kubernetes ย้ายสถานะปัจจุบันให้ใกล้กับสถานะที่ต้องการอย่างต่อเนื่อง หากพ็อดตาย มันจะสร้างขึ้นใหม่ หากโหนดหยุดทำงาน มันจะย้ายเวิร์กโหลดไปยังโหนดอื่น นั่นเป็นเหตุผลว่าทำไมรายการจึงไม่ใช่คำสั่ง "ทำ" แต่เป็นสูตร "ปล่อยให้มันเป็นเช่นนี้" การเข้าใจความแตกต่างนี้เป็นสิ่งสำคัญเมื่ออ่าน Manifest ที่ AI สร้างขึ้น แต่ละโดเมนจะอธิบายส่วนหนึ่งของสถานะที่ต้องการของระบบ โดเมนที่ไม่ถูกต้องหมายความว่า Kubernetes กำลังทำงานไปสู่เป้าหมายที่ผิด และเป้าหมายนั้นจะถูกบังคับใช้อย่างเงียบๆ และต่อเนื่อง
เคล็ดลับ: ใน Kubernetes เครื่องมือทดสอบความปลอดภัยที่สำคัญที่สุดคือ kubectl Apply --dry-run=server -f file.yaml ซึ่งแสดงว่าเซิร์ฟเวอร์จะยอมรับหรือไม่ และต้องทำอย่างไรโดยไม่ต้องใช้ Manifest จริงๆ อย่าลืมเรียกใช้ dry-run และ kubectl diff ก่อนที่จะใช้ไฟล์ Manifest กับผลิตภัณฑ์
ทีละขั้นตอน: การสร้างรายการด้วย AI
- อธิบายการใช้งานและความจำเป็น ชื่ออิมเมจ พอร์ต จำนวนเรพลิกา ขีดจำกัดทรัพยากร (CPU/หน่วยความจำ)
- ขอการปรับใช้ + บริการ โดยปกติแล้วทั้งสองจะต้องใช้ร่วมกัน
- แยกการกำหนดค่าและความลับ การตั้งค่าเป็น ConfigMap ค่าที่ละเอียดอ่อนเป็นข้อมูลลับ
- เพิ่มการตรวจสุขภาพ livenessProbe (พร้อมใช้งานหรือไม่) และ readinessProbe (พร้อมสำหรับการรับส่งข้อมูลหรือไม่) เป็นสิ่งสำคัญ
- กำหนดขีดจำกัดทรัพยากร หากไม่มีคำขอ/จำกัด พ็อดก็สามารถใช้ทั้งโหนดได้
- ตรวจสอบด้วย `--dry-run` และ `diff` จากนั้นนำไปใช้ อันดับแรกในเนมสเปซการทดสอบ
ความปลอดภัย: ความเสี่ยงเฉพาะของ Kubernetes
- ความลับไม่ได้เป็นความลับจริงๆ — มันเป็นแค่ base64 อ็อบเจ็กต์ Kubernetes Secret base64 เข้ารหัสค่า นี่ไม่ใช่การเข้ารหัส แต่สามารถถอดรหัสได้ง่าย เพื่อความเป็นส่วนตัวที่แท้จริง จำเป็นต้องมีการเข้ารหัส ฯลฯ และห้องนิรภัยภายนอก (ห้องนิรภัย, เครื่องมือจัดการความลับบนคลาวด์) อย่าส่งข้อมูลลับไปยัง Git โดยตรง (มีวิธีแก้ไขสำหรับสิ่งนี้ เช่น ความลับที่ปิดผนึก/ความลับภายนอก)
- กำหนดขีดจำกัดทรัพยากร พ็อดที่ไม่มีขีดจำกัดอาจทำให้ทั้งโหนดเสียหายเนื่องจากหน่วยความจำรั่ว
- อำนาจขั้นต่ำ (RBAC) ด้วยการควบคุมการเข้าถึงตามบทบาท แต่ละบริการ/ผู้ใช้จะมีเฉพาะสิทธิ์ที่จำเป็นเท่านั้น บางครั้ง AI ก็ให้ผู้ดูแลระบบคลัสเตอร์ขนาดใหญ่ จำกัดสิ่งนี้ให้แคบลง
- อย่าใช้แท็กรูปภาพ 'ล่าสุด' คุณไม่ทราบว่าเวอร์ชันใดกำลังทำงานอยู่ และคุณไม่สามารถย้อนกลับได้
ข้อควรระวัง: การลบ kubectl หรือการใช้ที่ไม่ถูกต้องอาจทำลายการปรับใช้ที่ใช้งานอยู่ได้ อย่าลืมตรวจสอบว่าคุณอยู่ในเนมสเปซใด (kubectl config บริบทปัจจุบัน) ก่อนที่จะรันคำสั่ง การทำงานโดยอุบัติเหตุถือเป็นหายนะทั่วไปในบริบทการผลิต
รายการดิบเทียบกับตาราง Helm
เกณฑ์
รายการ YAML ดิบ
แผนภูมิหางเสือ
การติดตั้ง
kubectl ใช้ -f
ติดตั้งหางเสือ
มัลติมีเดีย (dev/prod)
คัดลอกและวาง มีแนวโน้มที่จะเกิดข้อผิดพลาด
แผนภูมิเดี่ยว ค่าต่างกัน.yaml
เวอร์ชัน/ย้อนกลับ
ด้วยมือ
ง่ายด้วยการย้อนกลับหางเสือ
เส้นโค้งการเรียนรู้
ต่ำ
ปานกลาง
เมื่อ
ขนาดเล็ก สภาพแวดล้อมเดียว
มัลติมีเดีย บริการซ้ำๆ
มินิเคสสามอัน
กรณีที่ 1 — ความลับของบริการที่ขัดข้อง พ็อดทำการรีบูตอย่างต่อเนื่อง (CrashLoopBackOff) ทีมงานได้มอบบันทึกและรายการให้กับ AI AI แสดงให้เห็นว่า Pod ไม่เคยถือว่า "พร้อม" เพราะความพร้อมโพรบมองผิดพอร์ต พวกเขาแก้ไขพอร์ต บริการเริ่มเสถียรใน 10 นาที การสร้างความสัมพันธ์นี้ด้วยตนเองอาจใช้เวลาหลายชั่วโมง
กรณีที่ 2 — การไม่กำหนดขีดจำกัดทำให้ปมเสียหาย ไม่มีข้อจำกัดในการปรับใช้ หน่วยความจำรั่วทำให้ Pod บวมและทำให้ทั้งโหนดเสียหาย ส่งผลให้บริการใกล้เคียงล่มเช่นกัน หลังจากเหตุการณ์ดังกล่าว พวกเขาทำให้ AI พูดว่า "เพิ่มคำขอ CPU/หน่วยความจำที่เหมาะสมและขีดจำกัดในการปรับใช้ทั้งหมด" และทำให้เป็นมาตรฐาน บรรทัดที่ขาดไปหนึ่งบรรทัดต้องใช้เวลานานหลายชั่วโมงในการหยุดทำงาน
กรณีที่ 3 — RBAC ขนาดใหญ่ถูกยึด ในระหว่างการตรวจสอบ พบว่า ServiceAccount Manifest ที่สร้างโดย AI เชื่อมโยงกับบทบาทผู้ดูแลระบบคลัสเตอร์ ซึ่งหมายความว่าบริการสามารถจัดการทั้งคลัสเตอร์ได้ ทีมงานจำกัดสิทธิ์ให้อ่านเฉพาะพ็อดในเนมสเปซเท่านั้น หลักการของสิทธิพิเศษน้อยที่สุดปิดช่องโหว่ด้านความปลอดภัย
เทมเพลตที่สามารถคัดลอกได้สี่แบบ
1) การปรับใช้ + การผลิตการบริการ:
เขียนรายการการปรับใช้และบริการสำหรับ Kubernetes แอปพลิเคชัน: [AD], รูปภาพ: [รูปภาพ: รุ่นคงที่], พอร์ต: [X], แบบจำลอง: [N] กฎ:- เพิ่มคำขอและขีดจำกัด CPU/หน่วยความจำ- กำหนด livenessProbe และ readinessProbe- อ่านการกำหนดค่าจาก ConfigMap ข้อมูลลับจากอ็อบเจ็กต์ลับ อย่าฝังค่าในรายการ ให้ใช้ตัวยึดตำแหน่ง - ห้ามใช้แท็กรูปภาพ ":latest" ให้พร้อมคำอธิบาย.
2) การแก้ไขข้อผิดพลาดอย่างชัดแจ้ง:
Pod ปัจจุบันอยู่ในสถานะ [CrashLoopBackOff / Pending / ImagePullBackOff] ตามรายการต่อไปนี้และเอาต์พุต 'kubectl อธิบาย' ให้แสดงรายการสาเหตุที่แท้จริงที่เป็นไปได้ตามลำดับความน่าจะเป็น และออกคำสั่งตรวจสอบสำหรับแต่ละรายการ รายการ: [YAML] อธิบาย: [เอาต์พุต]
3) การตรวจสอบความปลอดภัย/ความสมบูรณ์:
ตรวจสอบรายการ Kubernetes นี้: ขีดจำกัดทรัพยากรหายไป เป็นไปได้หรือไม่ มีแท็ก :latest มี RBAC/สิทธิ์ที่กว้างเกินไปหรือไม่ ข้อมูลลับฝังอยู่ในรายการหรือไม่ เขียนข้อค้นพบตามลำดับความสำคัญและมีการแก้ไข รายการ: [YAML]
4) การแปลงเป็นแผนภูมิ Helm:
แปลงไฟล์ Manifest ดิบต่อไปนี้เป็นแผนภูมิ Helm ที่นำกลับมาใช้ใหม่ได้: ค่าใดที่ควรส่งออกไปที่ Values.yaml (รูปภาพ แบบจำลอง แหล่งที่มา สภาพแวดล้อม) แสดงโครงสร้างแผนภูมิและตัวอย่างค่าต่างๆ.yaml.Manifests: [YAML]
พรอมต์อ่อน / พรอมต์แข็งแกร่ง
จุดอ่อน: "เขียน Kubernetes YAML สำหรับแอปพลิเคชันของฉัน"
ผลลัพธ์: การปรับใช้แบบไม่มีข้อจำกัด และไม่มีขีดจำกัดด้วยแท็ก :latest ฝังที่ราบลับ ไม่ปลอดภัยและเปราะบางในผลิตภัณฑ์
แข็งแกร่ง: "เขียน Kubernetes Deployment + Service รูปภาพ myapp:1.4.2, 3 เรพลิกา, พอร์ต 8080 CPU 100m-500m, หน่วยความจำ 128Mi-512Mi เพิ่มคำขอ/ขีดจำกัด ใส่ liveness Probe สำหรับ /healthz, Readiness Probe สำหรับ /ready อ่านความลับจาก Secret Object อย่าฝังไว้ในไฟล์ Manifest ให้พร้อมคำอธิบาย"
ความแตกต่าง: เวอร์ชันพรอมต์ที่สองให้ขนาด ขีดจำกัดทรัพยากร การตรวจสุขภาพ และกฎลับ; ผลผลิตใกล้เคียงกับการผลิตและปลอดภัย
ข้อผิดพลาดทั่วไป
- ไม่ได้กำหนดขีดจำกัดทรัพยากร พ็อดเดียวสามารถใช้ทั้งโหนดได้
- ไม่เพิ่มการตรวจสุขภาพ (โพรบ) Kubernetes ตรวจไม่พบพ็อดที่ขัดข้อง/ไม่พร้อมใช้งาน
- แท็ก `:ล่าสุด` ไม่ชัดเจนว่าเวอร์ชันใดกำลังทำงานอยู่ และไม่สามารถย้อนกลับได้
- ส่งมอบความลับให้กับ Git โดยตรง Base64 ไม่ใช่การเข้ารหัส ทุกคนแก้มันได้
- การรันคำสั่งในบริบท/เนมสเปซที่ไม่ถูกต้อง วิธีที่พบบ่อยที่สุดในการขัดข้องในผลิตภัณฑ์
- ข้าม `--dry-run`/`diff` ไม่เห็นว่าจะเกิดอะไรขึ้นก่อนนำไปปฏิบัติ
โดยสรุป
Kubernetes เป็นเครื่องมือจัดการที่ทรงพลังแต่ซับซ้อนซึ่งจะปรับใช้ ปรับขนาด และเพิ่มประสิทธิภาพคอนเทนเนอร์ทั่วทั้งคลัสเตอร์โดยอัตโนมัติ ทุกอย่างถูกกำหนดโดยรายการ YAML ซึ่ง Helm สร้างเทมเพลต AI สร้างรายการปรับใช้/บริการและแผนภูมิ Helm อย่างรวดเร็ว แก้ไขจุดบกพร่องลึกลับ แต่คุณต้องขอขีดจำกัดทรัพยากร การตรวจสอบสภาพ แท็กรูปภาพที่ไม่เปลี่ยนรูป RBAC ที่แคบลง และกฎความปลอดภัยที่เป็นความลับอย่างชัดเจน --dry-run, diff และการตรวจสอบบริบทที่ถูกต้องเป็นพฤติกรรมที่ป้องกันการขัดข้องของผลิตภัณฑ์
งานสมัคร
ให้ AI สร้างรายการสำหรับแอปพลิเคชันตัวอย่างด้วยเทมเพลต "การปรับใช้ + การสร้างบริการ" จากนั้น: (1) ให้ตรวจสอบขีดจำกัดทรัพยากร โพรบ :ล่าสุด และความลับด้วยเทมเพลต "การตรวจสอบความปลอดภัย/สุขภาพ" (2) รัน kubectl Apply --dry-run=server บนคลัสเตอร์ทดสอบ/minikube หากเป็นไปได้และอ่านเอาต์พุต (3) จดบันทึกรายการด้านความปลอดภัย/ความทนทานที่สำคัญที่สุดสองรายการที่คุณพบว่าขาดหายไป
รายการตรวจสอบ
- [ ] ฉันเพิ่มเวอร์ชันรูปภาพ จำนวนเรพลิกา พอร์ต และขีดจำกัดทรัพยากรให้กับคำขอของฉัน
- [ ] ฉันเพิ่มความมีชีวิตชีวาและความพร้อมให้กับรายการ
- [ ] แก้ไขแท็กรูปภาพแล้ว ฉันไม่ได้ใช้ :latest
- [ ] ความลับไม่ได้ถูกฝังอยู่ในรายการ; ฉันใช้วัตถุลับ/ห้องนิรภัยภายนอก
- [ ] ฉันจำกัด RBAC/สิทธิ์ให้แคบลงให้เหลือสิทธิ์ขั้นต่ำสุด
- [ ] ก่อนสมัคร ฉันตรวจสอบแล้วว่าอยู่ในบริบทที่ถูกต้องและเอาต์พุต --dry-run/diff