DevOps Bootcamp · บทเรียน

คอนเทนเนอร์เริ่มต้นและลำดับการเริ่มทำงาน

เรียนรู้ว่าคอนเทนเนอร์เริ่มต้นทำงานเตรียมการก่อนคอนเทนเนอร์แอปหลักเริ่มต้นอย่างไร และช่วยบังคับลำดับภายใน Pod ได้อย่างไร

คอนเทนเนอร์เริ่มต้นและลำดับการเริ่มทำงาน เป็นบทเรียน DevOps Bootcamp ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน DevOps Bootcamp และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส DevOps Bootcamp มีบทเรียนทั้งหมด 4 บทเรียน

Init Containers คืออะไร

คอนเทนเนอร์เริ่มต้น คือคอนเทนเนอร์พิเศษที่ทำงานจนเสร็จสมบูรณ์ ก่อน ที่คอนเทนเนอร์แอปพลิเคชันหลักในพ็อดจะเริ่มทำงาน พ็อดหนึ่งรายการอาจมีคอนเทนเนอร์เริ่มต้นหนึ่งรายการหรือหลายรายการ

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

ความแตกต่างจากคอนเทนเนอร์แอปพลิเคชัน

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

คอนเทนเนอร์เริ่มต้นทำงานตามลำดับ ทีละรายการ
คอนเทนเนอร์แอปพลิเคชันทำงานแบบขนาน
หากคอนเทนเนอร์เริ่มต้นทำงานล้มเหลว Kubernetes จะเริ่มคอนเทนเนอร์นั้นใหม่ (ตาม restartPolicy)

ข้อมูลจำเพาะของ Init Container พื้นฐาน

คอนเทนเนอร์เริ่มต้นอยู่ภายใต้ spec.initContainers ซึ่งอยู่ระดับเดียวกับ spec.containers

apiVersion: v1
kind: Pod
metadata:
  name: app-with-init
spec:
  initContainers:
  - name: wait-for-db
    image: busybox:1.36
    command: ['sh', '-c', 'echo waiting; sleep 5']
  containers:
  - name: app
    image: nginx:1.27

เหตุใดลำดับจึงสำคัญ

Kubernetes รับรองลำดับการทำงานดังนี้: คอนเทนเนอร์เริ่มต้นทุกรายการต้องทำงานสำเร็จก่อนที่คอนเทนเนอร์หลักจะเริ่มทำงาน

วิธีนี้ช่วยให้คุณประกาศการพึ่งพาได้โดยตรง แทนที่จะฝังลูปลองใหม่ไว้ในอิมเมจแอปพลิเคชัน

การรอบริการ

รูปแบบที่พบบ่อยคือบล็อกการเริ่มต้นไว้จนกว่าบริการที่ต้องพึ่งพาจะตอบสนอง

initContainers:
- name: wait-for-api
  image: busybox:1.36
  command:
  - sh
  - -c
  - 'until nslookup api-service; do echo waiting; sleep 2; done'

Init Containers หลายรายการ

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

initContainers:
- name: step-1-fetch-config
  image: busybox:1.36
  command: ['sh', '-c', 'echo fetching config']
- name: step-2-migrate
  image: busybox:1.36
  command: ['sh', '-c', 'echo running migration']

การใช้ข้อมูลร่วมกันด้วย emptyDir

คอนเทนเนอร์เริ่มต้นมักเตรียมไฟล์ให้คอนเทนเนอร์แอปพลิเคชันโดยใช้โวลุ่ม emptyDir ร่วมกัน

volumes:
- name: shared
  emptyDir: {}
initContainers:
- name: setup
  image: busybox:1.36
  command: ['sh', '-c', 'echo hello > /work/index.html']
  volumeMounts:
  - name: shared
    mountPath: /work

การตรวจสอบสถานะของ Init

ขณะที่คอนเทนเนอร์เริ่มต้นกำลังทำงาน พ็อดจะแสดงสถานะ เช่น Init:0/2 ใช้ kubectl เพื่อติดตามความคืบหน้า

kubectl get pod app-with-init
kubectl logs app-with-init -c wait-for-db
kubectl describe pod app-with-init

กฎการใช้ทรัพยากร

เนื่องจากคอนเทนเนอร์เริ่มต้นทำงานตามลำดับ Kubernetes จึงใช้ค่าคำขอหรือขีดจำกัดทรัพยากรที่ สูงที่สุด ในบรรดาคอนเทนเนอร์เหล่านั้น (ไม่ใช่ผลรวม) เมื่อจัดกำหนดการ จากนั้นจึงเปรียบเทียบกับความต้องการของคอนเทนเนอร์แอปพลิเคชัน

กรณีการใช้งานที่พบบ่อย

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

พฤติกรรมเมื่อเกิดข้อผิดพลาด

หากคอนเทนเนอร์เริ่มต้นทำงานล้มเหลว และ restartPolicy ของพ็อดเป็น Always หรือ OnFailure Kubernetes จะพยายามเรียกใช้คอนเทนเนอร์นั้นซ้ำจนกว่าจะสำเร็จ คอนเทนเนอร์หลักจะยังไม่เริ่มทำงานจนกว่าจะถึงตอนนั้น

ตรวจสอบอย่างรวดเร็ว

ทดสอบความเข้าใจของคุณเกี่ยวกับลำดับการทำงานของคอนเทนเนอร์เริ่มต้น

สรุปทบทวน

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

ถัดไป คุณสามารถใช้คอนเทนเนอร์เริ่มต้นร่วมกับคอนเทนเนอร์เสริม เพื่อสร้างรูปแบบการเริ่มต้นพ็อดที่หลากหลายยิ่งขึ้น

คำถามที่พบบ่อย

บทเรียน “คอนเทนเนอร์เริ่มต้นและลำดับการเริ่มทำงาน” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “คอนเทนเนอร์เริ่มต้นและลำดับการเริ่มทำงาน” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส DevOps Bootcamp ให้อัปเกรดเป็น CoddyKit PRO คอร์ส DevOps Bootcamp มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “คอนเทนเนอร์เริ่มต้นและลำดับการเริ่มทำงาน”

เรียนรู้ว่าคอนเทนเนอร์เริ่มต้นทำงานเตรียมการก่อนคอนเทนเนอร์แอปหลักเริ่มต้นอย่างไร และช่วยบังคับลำดับภายใน Pod ได้อย่างไร คุณปฏิบัติ DevOps Bootcamp ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน DevOps Bootcamp หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน DevOps Bootcamp บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “คอนเทนเนอร์เริ่มต้นและลำดับการเริ่มทำงาน” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน DevOps Bootcamp นี้ได้ไหม

ได้ บทเรียน DevOps Bootcamp ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

Pod: หน่วยที่เล็กที่สุด
วงจรชีวิตและสถานะของ Pod
Pod หลายคอนเทนเนอร์ (ไซด์คาร์)
คอนเทนเนอร์เริ่มต้นและลำดับการเริ่มทำงาน

← กลับไปที่ DevOps Bootcamp