Containers and Orchestration
คอนเทนเนอร์และการจัดการระบบ
Container ทำให้แพ็กแอปเป็นชุดที่รันซ้ำได้ ระบบ orchestration ช่วยดูแลหลายชุดและหลายเครื่อง
หัวข้อในบทนี้
ศัพท์ในบทนี้ · กดคำที่ขีดเส้นใต้ในเนื้อหาเพื่อดูความหมายได้ด้วย
- API
- ข้อตกลงวิธีที่โปรแกรมเรียกความสามารถหรือข้อมูลของอีกโปรแกรม
- RBAC
- ให้สิทธิ์ผ่านบทบาทที่กำหนด
desired state ไม่ใช่สถานะที่เกิดจริงเสมอ
Image บรรจุสิ่งที่ใช้สร้างสภาพรัน Registry เก็บและแจก image Container เป็น instance ที่รันตาม image และ config Kubernetes รับ desired state แล้ว controllers พยายามทำให้สถานะจริงสอดคล้อง Pod เป็นหน่วย workload Node เป็นเครื่องรัน ส่วน Service ให้ทางเข้าตาม backend ที่เลือก
- Build / registry
รู้ base dependencies artifact และ digest Tag อาจถูกชี้ไปข้อมูลใหม่ได้
- Desired state
เช่น Deployment ต้องการ replicas 3 และ image digest ที่กำหนด
- Schedule / run
Control plane เลือกตามข้อจำกัด Node รัน Pods ด้วยทรัพยากรที่ให้
- Ready / route
Running ไม่เท่ากับ Ready Probes และ endpoint selection กระทบว่าคำขอไปถึงงานได้หรือไม่
- Reconcile
ถ้า pod หาย controller อาจสร้างแทนตาม desired state ไม่ใช่การลบไม่สำเร็จ
เป็นภาพ Deployment/Service แบบทั่วไป Service endpoint selection ยังมีรายละเอียดตาม configuration Pod Running ไม่ใช่หลักฐานว่าแอปและ dependency พร้อม
Namespace เป็นขอบเขตจัดการ ไม่รับรอง isolation อย่างสมบูรณ์ ต้องดู workload identity network policy runtime และ storage ร่วมกัน NetworkPolicy ต้องมีส่วนระบบเครือข่ายที่บังคับได้จริง การ pin digest ช่วยระบุ artifact เดิม ไม่รับรองว่าปลอดช่องโหว่หรือเหมาะกับสิทธิ์ runtime
อิมเมจ คอนเทนเนอร์ และที่เก็บImages, Containers and Registries · 26.2.1
Image เป็นแม่แบบ Container เป็นหน่วยที่รัน Registry เก็บและส่ง images
Image มาจาก base image dependency และ build steps Registry เก็บและแจก image Container รันตาม image กับ configuration การใช้ tag latest ไม่รับรองว่าจะได้ byte เดิมทุกครั้ง
base และ dependencies
ที่เก็บและตัวระบุ image
สิทธิ์ network และ volume
Pin digest ช่วยอ้าง image ที่แน่นอน แต่ยังต้องตรวจช่องโหว่ แหล่งที่มาและ policy Deploy image ที่รู้รุ่นแล้วบันทึก digest ให้เทียบการเปลี่ยนได้ ไม่ใช้ชื่อ tag เป็นหลักฐานเดียว
ที่มาของหัวข้อนี้ · คำอธิบายต่อยอด
คำอธิบายและภาพในหน้านี้เรียบเรียงใหม่ ชื่อบทต้นทางด้านล่างใช้ตรวจที่มา ไม่ได้แทนเนื้อหาที่คุณต้องไปอ่านเพิ่มเพื่อเข้าใจหน้านี้ และไม่ยืนยันว่าทุกประโยคมีอยู่ในคอร์ส
เป็นส่วนต่อยอดที่เขียนเพื่อเชื่อมความเข้าใจ ไม่มีชื่อ Video/Reading เฉพาะที่ยืนยันจาก inventory เดิม
พื้นฐานคูเบอร์เนทีสKubernetes Foundations · 26.2.2
Kubernetes จัด desired state ของ workload และทรัพยากร ต้องเข้าใจ pods services และ control plane
Kubernetes จัด workload ผ่าน และ controller Pod เป็นหน่วยรัน container ตามที่ระบุ Deployment ดูแล replica Service ให้ทางเข้าที่คงที่ Node เป็นเครื่องที่รัน pod ต้องเข้าใจ desired state กับสถานะจริง
รับและปรับตาม desired state
หน่วยงานและเครื่องรัน
ทางเข้าถึงตามการเลือก backend
ลบ pod ของ Deployment แล้ว controller อาจสร้างใหม่ เป็นการคืน desired state ไม่ใช่ปัญหาลบไม่สำเร็จ Pod running ยังอาจไม่ ready ต้องดู probe event resource และ dependency ของแอป
kubectl get deployments
kubectl get pods
kubectl describe pod POD_NAMEคำสั่งอ่านสถานะใน context ที่คุณเลือก ต้องตรวจ cluster/namespace ให้ถูก POD_NAME เป็นตัวแทนชื่อจริง describe แสดงสถานะและ events ที่ช่วยตรวจ pending หรือ readiness
ที่มาของหัวข้อนี้ · คำอธิบายต่อยอด
คำอธิบายและภาพในหน้านี้เรียบเรียงใหม่ ชื่อบทต้นทางด้านล่างใช้ตรวจที่มา ไม่ได้แทนเนื้อหาที่คุณต้องไปอ่านเพิ่มเพื่อเข้าใจหน้านี้ และไม่ยืนยันว่าทุกประโยคมีอยู่ในคอร์ส
เป็นส่วนต่อยอดที่เขียนเพื่อเชื่อมความเข้าใจ ไม่มีชื่อ Video/Reading เฉพาะที่ยืนยันจาก inventory เดิม
เอกสารหลักที่ใช้ตรวจแนวคิดเพิ่มเติม
ตัวตนและการแยกเวิร์กโหลดWorkload Identity and Isolation · 26.2.3
Workload identity ระบุแอปที่เรียกบริการ Isolation จำกัดอำนาจและการเชื่อมระหว่างงาน
Workload identity ให้แต่ละงานมีตัวตนและสิทธิ์ที่จำเป็น Isolation จำกัดข้ามงานด้วยหลาย control เช่น namespace network policy และ runtime permission Namespace อย่างเดียวไม่รับรองการแยกภัย
สิทธิ์ของ workload
ทางเชื่อมและสิทธิ์ process
ผลที่ถูกบังคับจริง
Pod อ่าน secret ได้ทั้งหมดเสี่ยงกว่าระบุสิทธิ์เฉพาะ Service account token ต้องจำกัดและไม่ส่งเกินงาน NetworkPolicy ต้องมี network plugin ที่บังคับได้จริง ตรวจ traffic หลังตั้งไม่ถือว่า YAML มีแล้วบังคับเสมอ
API Permission versus Traffic Permission (สิทธิ์ API กับทางสื่อสาร)
Kubernetes คุมการใช้ เช่นใครอ่าน Secret หรือแก้ Deployment NetworkPolicy คุม traffic ตามที่ระบบ network plugin รองรับ เป็นคนละสิ่ง การให้ role อ่าน API ไม่ใช่กฎอนุญาตให้ pod ต่อ database และการปิด network ไม่ได้ถอนสิทธิ์แก้ resource ผ่าน API ให้เอง
Workload identity กับ token ต้องจำกัดอายุ audience และ permissions ตามระบบ Namespace ช่วย scope บาง resources แต่ไม่ได้แยก kernel หรือทุก resource ของ cluster ต้องดู runtime security storage secret access และเส้นทางออกของ workload รวมกัน
| Control | คุมอะไร | ไม่แทน |
|---|---|---|
| RBAC | API actions on resources | Network firewall |
| NetworkPolicy | Traffic ตามการบังคับที่รองรับ | API authorization |
| Runtime permissions | process capabilities / constraints | การตรวจสิทธิ์ข้อมูลในแอป |
| Namespace | ขอบเขตจัด resource บางชนิด | Isolation สมบูรณ์ |
ที่มาของหัวข้อนี้ · คำอธิบายต่อยอด
คำอธิบายและภาพในหน้านี้เรียบเรียงใหม่ ชื่อบทต้นทางด้านล่างใช้ตรวจที่มา ไม่ได้แทนเนื้อหาที่คุณต้องไปอ่านเพิ่มเพื่อเข้าใจหน้านี้ และไม่ยืนยันว่าทุกประโยคมีอยู่ในคอร์ส
เป็นส่วนต่อยอดที่เขียนเพื่อเชื่อมความเข้าใจ ไม่มีชื่อ Video/Reading เฉพาะที่ยืนยันจาก inventory เดิม
เอกสารหลักที่ใช้ตรวจแนวคิดเพิ่มเติม
นำศัพท์มาเชื่อมกับงาน
Container ที่รันได้ในเครื่องยังต้องตรวจสิทธิ์ network policy และ secrets ก่อนใช้ในระบบร่วม
สิ่งที่บทนี้เชื่อมไว้
Container ทำให้แพ็กแอปเป็นชุดที่รันซ้ำได้ ระบบ orchestration ช่วยดูแลหลายชุดและหลายเครื่อง
ใช้ภาพกับตัวอย่างด้านบนเชื่อมหน้าที่ของแต่ละส่วน แล้วตรวจความเข้าใจด้วยการอธิบายเหตุผลของผลที่เห็น ก่อนเปิดบทถัดไป
บทเรียนที่เกี่ยวข้องและที่มาของบทอ่าน
คำอธิบายหน้านี้เขียนใหม่ตามหัวข้อใน Atlas รายการด้านล่างเป็นชื่อ Video/Reading ที่เคยจับคู่ไว้ แสดงไว้ให้ตรวจที่มาของชื่อหัวข้อ และไม่รับรองว่าคอร์สสอนทุกส่วนของคำอธิบายนี้
กลุ่มนี้ไม่มีชื่อบทเรียนเฉพาะในชุดหลักฐานเดิม ใช้อ่านเป็นส่วนต่อยอดของ Atlas