Azure Fundamentals · บทเรียน

แนวคิด Kubernetes สำหรับ Azure

ทบทวนโครงสร้างหลักของ Kubernetes ได้แก่ พ็อด การปรับใช้ บริการ และเนมสเปซ พร้อมทำความเข้าใจว่า AKS จัดการระนาบควบคุมแทนคุณอย่างไร

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

Kubernetes คืออะไร

Kubernetes (K8s) คือแพลตฟอร์มโอเพนซอร์สสำหรับจัดการระบบคอนเทนเนอร์ ซึ่งเดิมพัฒนาโดย Google โดยจะทำให้การปรับใช้ การเพิ่มหรือลดขนาด และการจัดการแอปพลิเคชันแบบคอนเทนเนอร์เป็นไปโดยอัตโนมัติ แทนที่จะเรียกใช้คอนเทนเนอร์ด้วยตนเอง คุณจะประกาศ สถานะที่ต้องการ ของแอปพลิเคชันในไฟล์กำหนดค่า YAML แล้ว Kubernetes จะทำงานอย่างต่อเนื่องเพื่อให้สถานะจริงตรงกับสถานะที่ต้องการ เช่น เริ่มต้นคอนเทนเนอร์ที่ล้มเหลวใหม่ จัดตารางเวิร์กโหลดลงบนโหนดที่มีสถานะปกติ และปรับจำนวนเรพลิกา

สถาปัตยกรรมคลัสเตอร์: ระนาบควบคุมและโหนด

คลัสเตอร์ Kubernetes ประกอบด้วย ระนาบควบคุม และ โหนด Worker ระนาบควบคุมประกอบด้วยเซิร์ฟเวอร์ API (จุดเข้าสำหรับคำสั่ง kubectl ทั้งหมด), etcd (ที่เก็บสถานะแบบกระจาย), ตัวจัดตารางเวลา (กำหนด Pod ให้กับโหนด) และตัวจัดการคอนโทรลเลอร์ (รักษาสถานะที่ต้องการ) โหนด Worker เรียกใช้ kubelet (ตัวแทนโหนด), kube-proxy (กฎเครือข่าย) และ runtime ของคอนเทนเนอร์ (containerd) ใน AKS Microsoft จะจัดการระนาบควบคุม ส่วนคุณจัดการเฉพาะโหนด Worker

# Kubernetes control plane components
# kube-apiserver    - REST API for all cluster operations
# etcd              - Distributed key-value store (cluster state)
# kube-scheduler    - Assigns pending pods to nodes
# kube-controller-manager  - Runs reconciliation controllers

# Worker node components
# kubelet           - Node agent, ensures containers run
# kube-proxy        - Network routing for services
# containerd        - Container runtime (runs containers)

Pod: หน่วยที่เล็กที่สุดที่ปรับใช้ได้

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

# Simple pod manifest
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp
    image: mycontainerregistry.azurecr.io/myapp:v1.0
    ports:
    - containerPort: 80
    resources:
      requests:
        cpu: '100m'
        memory: '128Mi'
      limits:
        cpu: '500m'
        memory: '512Mi'

Deployment: การจัดการ Replica Set

Deployment คือวิธีมาตรฐานสำหรับเรียกใช้แอปพลิเคชันแบบไม่มีสถานะใน Kubernetes โดยจะสร้างและจัดการ ReplicaSet ซึ่งรักษาจำนวนเรพลิกาของ Pod ที่เหมือนกันตามที่ต้องการ Deployment รองรับ การอัปเดตแบบทยอย โดยค่อย ๆ แทนที่ Pod เก่าด้วย Pod ใหม่ และรองรับ การย้อนกลับ ไปยังเวอร์ชันก่อนหน้า คุณอธิบายเทมเพลต Pod และจำนวนเรพลิกาที่ต้องการ แล้ว Kubernetes จะจัดการส่วนที่เหลือ

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1       # Create 1 extra pod during update
      maxUnavailable: 0 # Never reduce below desired count
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: mycontainerregistry.azurecr.io/myapp:v1.0
        ports:
        - containerPort: 80

บริการ: จุดปลายทางเครือข่ายที่คงที่

เนื่องจาก Pod มีอายุชั่วคราวและ IP ของ Pod เปลี่ยนแปลง Services จึงจัดเตรียมจุดปลายทางเครือข่ายที่คงที่เพื่อกระจายโหลดทราฟฟิกไปยัง Pod ที่ตรงกัน บริการจะใช้ ตัวเลือกป้ายกำกับ เพื่อค้นหา Pod ประเภทของบริการ ได้แก่ ClusterIP (ใช้ภายในเท่านั้น เป็นค่าเริ่มต้น), NodePort (เปิดพอร์ตบนทุกโหนด), LoadBalancer (จัดเตรียม Azure Load Balancer พร้อม IP สาธารณะ) และ ExternalName (ชื่อแทน DNS ไปยังบริการภายนอก)

# Service exposing myapp pods externally
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
spec:
  type: LoadBalancer  # Creates Azure Load Balancer
  selector:
    app: myapp        # Routes traffic to pods with this label
  ports:
  - port: 80          # Service port
    targetPort: 80    # Pod/container port

# After creation, check the EXTERNAL-IP (Azure LB public IP)
# kubectl get service myapp-svc

Namespaces สำหรับการใช้งานหลายผู้เช่า

Namespaces แบ่งคลัสเตอร์ Kubernetes เดียวออกเป็นคลัสเตอร์เสมือนหลายชุด ทรัพยากรใน Namespaces ต่างกันจะถูกแยกจากกันด้วยชื่อ ดังนั้นคุณจึงมี Deployment myapp อยู่ทั้งใน Namespace development และ production ได้พร้อมกัน Namespaces เป็นหน่วยหลักสำหรับใช้ RBAC โควตาทรัพยากร และนโยบายเครือข่ายกับทีมหรือสภาพแวดล้อมหนึ่ง ๆ Namespaces เริ่มต้นประกอบด้วย default, kube-system และ kube-public

# Create a namespace for the dev team
kubectl create namespace dev-team

# Deploy into a specific namespace
kubectl apply -f deployment.yaml --namespace dev-team

# List all resources in a namespace
kubectl get all --namespace dev-team

# Set default namespace for current context
kubectl config set-context --current --namespace dev-team

ConfigMaps และ Secrets

ConfigMaps จัดเก็บข้อมูลการกำหนดค่าที่ไม่ละเอียดอ่อนในรูปคู่คีย์-ค่า หรือไฟล์ และฉีดข้อมูลเข้าไปใน Pod เป็นตัวแปรสภาพแวดล้อมหรือการเมานต์โวลุม Secrets จัดเก็บข้อมูลที่ละเอียดอ่อน เช่น รหัสผ่านและโทเค็น ในรูปแบบที่เข้ารหัสด้วย base64 (ไม่ได้เข้ารหัสตามค่าเริ่มต้น ให้ใช้ Azure Key Vault Provider for Secrets Store CSI Driver เพื่อการเข้ารหัสขณะจัดเก็บอย่างแท้จริง) ทั้งสองรายการมีขอบเขตระดับ Namespace และอ้างอิงในข้อกำหนดของ Pod ด้วยชื่อ

# Create a ConfigMap from literal values
kubectl create configmap app-config \
  --from-literal=APP_ENV=production \
  --from-literal=LOG_LEVEL=info

# Create a Secret
kubectl create secret generic db-secret \
  --from-literal=DB_PASSWORD='super-secret'

# Reference in a pod spec
# env:
# - name: APP_ENV
#   valueFrom:
#     configMapKeyRef:
#       name: app-config
#       key: APP_ENV
# - name: DB_PASSWORD
#   valueFrom:
#     secretKeyRef:
#       name: db-secret
#       key: DB_PASSWORD

Persistent Volumes บน Azure

แอปพลิเคชันที่มีสถานะจำเป็นต้องใช้พื้นที่จัดเก็บที่มีอายุยืนยาวกว่า Pod แต่ละรายการ Kubernetes ใช้ PersistentVolumes (PVs) และ PersistentVolumeClaims (PVCs) เพื่อแยกพื้นที่จัดเก็บออกจากวงจรการทำงานของ Pod ใน AKS คลาสพื้นที่จัดเก็บในตัวอย่าง Azure Disk และ Azure Files จะจัดเตรียมดิสก์ที่มีการจัดการและส่วนใช้ร่วมกันของไฟล์โดยอัตโนมัติเมื่อสร้าง PVC โดย Azure Disk ใช้สำหรับการเข้าถึงจาก Pod เดียว ส่วน Azure Files รองรับการอ่านและเขียนพร้อมกันจาก Pod หลายรายการ

# PersistentVolumeClaim using Azure Disk
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-disk-pvc
spec:
  accessModes:
  - ReadWriteOnce   # Single-node read/write (Azure Disk)
  storageClassName: managed-csi
  resources:
    requests:
      storage: 10Gi

# Mount in a pod
# volumes:
# - name: data
#   persistentVolumeClaim:
#     claimName: my-disk-pvc
# volumeMounts:
# - name: data
#   mountPath: /data

Horizontal Pod Autoscaler

Horizontal Pod Autoscaler (HPA) จะปรับจำนวนเรพลิกาของ Pod ใน Deployment โดยอัตโนมัติตามการใช้ CPU/หน่วยความจำที่สังเกตได้หรือตัวชี้วัดแบบกำหนดเอง คอนโทรลเลอร์ HPA จะสอบถามเซิร์ฟเวอร์ตัวชี้วัดทุก 15 วินาที และเพิ่มหรือลดจำนวนเรพลิกาเพื่อให้การใช้ทรัพยากรใกล้เคียงกับเป้าหมาย คุณกำหนดจำนวนเรพลิกาขั้นต่ำและสูงสุดเป็นขอบเขตป้องกันการปรับขนาดเกินควบคุม

# Create an HPA targeting 50% CPU utilisation
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

การตรวจสอบสถานะ: โพรบ Liveness และ Readiness

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

livenessProbe:
  httpGet:
    path: /health
    port: 80
  initialDelaySeconds: 15
  periodSeconds: 20
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /ready
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

startupProbe:
  httpGet:
    path: /startup
    port: 80
  failureThreshold: 30
  periodSeconds: 10  # Allow 300s for slow startup

คำขอและขีดจำกัดทรัพยากร

คอนเทนเนอร์ทุกตัวใน Kubernetes ควรประกาศ คำขอทรัพยากร (การจัดสรรขั้นต่ำที่รับประกัน ซึ่งตัวจัดตารางเวลาใช้) และ ขีดจำกัด (ค่าสูงสุดที่อนุญาต หากเกินค่านี้ คอนเทนเนอร์จะถูกจำกัดความเร็วหรือยุติการทำงาน) คำขอ CPU ใช้หน่วยมิลลิคอร์ (m) โดย 1000m = 1 คอร์ CPU การตั้งค่าคำขอและขีดจำกัดอย่างถูกต้องช่วยป้องกันปัญหาผู้ใช้รายหนึ่งใช้ทรัพยากรมากเกินไป และช่วยให้ตัวจัดตารางเวลาจัดวาง Pod บนโหนดได้อย่างมีประสิทธิภาพโดยไม่จัดสรรทรัพยากรเกินจริง

resources:
  requests:
    cpu: '250m'      # 0.25 CPU core guaranteed
    memory: '256Mi'  # 256 MiB guaranteed
  limits:
    cpu: '1'         # Max 1 CPU core
    memory: '512Mi'  # Max 512 MiB (OOMKilled if exceeded)

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิด Microsoft Azure Fundamentals (AZ-900) จากบทเรียนนี้

สรุปบทเรียน

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

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

บทเรียน “แนวคิด Kubernetes สำหรับ Azure” ฟรีหรือไม่

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

คุณจะเรียนรู้อะไรในบทเรียน “แนวคิด Kubernetes สำหรับ Azure”

ทบทวนโครงสร้างหลักของ Kubernetes ได้แก่ พ็อด การปรับใช้ บริการ และเนมสเปซ พร้อมทำความเข้าใจว่า AKS จัดการระนาบควบคุมแทนคุณอย่างไร คุณปฏิบัติ Azure Fundamentals ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

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

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

บทเรียน “แนวคิด Kubernetes สำหรับ Azure” ใช้เวลานานแค่ไหน

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

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

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

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

← กลับไปที่ Azure Fundamentals