# สัมภาษณ์ Kubernetes: อธิบาย Pods, Services และ Deployments อย่างละเอียด

> คำถามสัมภาษณ์ Kubernetes เกี่ยวกับ Pods, Services และ Deployments พร้อมตัวอย่าง YAML กลไก networking ภายใน และกลยุทธ์ scaling สำหรับปี 2026

- Published: 2026-04-04
- Updated: 2026-04-04
- Author: SharpSkill
- Tags: kubernetes, devops, interview, pods, services, deployments
- Reading time: 12 min

---

ในการสัมภาษณ์งานที่เกี่ยวข้องกับ Kubernetes คำถามมักจะเน้นไปที่ออบเจ็กต์พื้นฐานสามประเภท ได้แก่ Pods, Services และ Deployments การเข้าใจว่าสิ่งเหล่านี้ทำงานร่วมกันอย่างไร ตั้งแต่การจัดสรรคอนเทนเนอร์ การกำหนดเส้นทางเครือข่าย ไปจนถึงการอัปเดตแบบค่อยเป็นค่อยไป จะช่วยแยกผู้สมัครที่จำคำจำกัดความได้ออกจากผู้ที่สามารถออกแบบระบบสำหรับ production ได้จริง

คู่มือนี้จะอธิบายแต่ละองค์ประกอบด้วย YAML ระดับ production อธิบายรายละเอียดภายในที่ผู้สัมภาษณ์ให้ความสำคัญ และครอบคลุมคำถามที่พบบ่อยในการสัมภาษณ์ตำแหน่ง DevOps และ Platform Engineering

> **สรุปสั้นสำหรับอ้างอิงรวดเร็ว**
>
> Pod ใช้สำหรับรันคอนเทนเนอร์หนึ่งตัวหรือมากกว่าบนโหนดเดียว Deployment ใช้จัดการ Pod หลายๆ replica และการ rollout ส่วน Service จัดหา endpoint เครือข่ายที่มีความเสถียรเพื่อเข้าถึง Pod เหล่านั้น ออบเจ็กต์ทั้งสามนี้ครอบคลุมการจัดการ workload ประมาณ 80% ใน Kubernetes cluster ที่รันเวอร์ชัน v1.35 หรือใหม่กว่า

## ทำความเข้าใจ Kubernetes Pods: หน่วยที่เล็กที่สุดที่สามารถ Deploy ได้

Pod คือหน่วยพื้นฐานของการจัดสรรใน Kubernetes ซึ่งห่อหุ้มคอนเทนเนอร์หนึ่งตัวหรือมากกว่าที่แชร์ network namespace, IPC namespace และ storage volumes เดียวกัน คอนเทนเนอร์ทุกตัวใน Pod จะได้รับ IP address เดียวกันและสามารถสื่อสารกับคอนเทนเนอร์พี่น้องผ่าน `localhost` ได้

รูปแบบ single-container Pod เป็นที่นิยมมากที่สุด Multi-container Pods มีไว้สำหรับสถานการณ์ sidecar เช่น log collectors, service meshes หรือ init containers ที่เตรียม filesystem ก่อนที่ process หลักจะเริ่มทำงาน

```yaml
# api-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: api-server
  labels:
    app: api
    version: v2
spec:
  containers:
    - name: api
      image: registry.example.com/api:3.1.0
      ports:
        - containerPort: 8080
      resources:
        requests:
          cpu: "250m"        # 0.25 CPU core reserved
          memory: "256Mi"    # 256 MB reserved
        limits:
          cpu: "500m"        # hard cap at 0.5 core
          memory: "512Mi"    # OOMKilled beyond this
      readinessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 10
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 20
```

บล็อก `resources` มีความสำคัญมากในการสัมภาษณ์ `requests` กำหนดการจัดสรร โดย scheduler จะวาง Pod บนโหนดที่มีทรัพยากรเพียงพอ ส่วน `limits` บังคับใช้ขีดจำกัดสูงสุดขณะรัน การใช้หน่วยความจำเกิน limit จะทำให้เกิด OOMKill ในขณะที่การใช้ CPU เกินจะทำให้เกิด throttling

> **ข้อผิดพลาดที่พบบ่อยในการสัมภาษณ์**
>
> การตั้งค่า memory limits โดยไม่มี requests จะทำให้การจัดสรรไม่สามารถคาดเดาได้ kubelet อาจวาง Pod บนโหนดที่ไม่สามารถรองรับ workload ได้จริง ควรตั้งค่าทั้ง requests และ limits เสมอสำหรับ production Pods

## Pod Lifecycle Phases และ Restart Policies

Kubernetes ติดตาม Pod แต่ละตัวผ่านห้าเฟส ได้แก่ `Pending`, `Running`, `Succeeded`, `Failed` และ `Unknown` ผู้สัมภาษณ์มักจะถามว่าอะไรทำให้เกิดการเปลี่ยนแปลงแต่ละครั้ง

| Phase | ความหมาย | สาเหตุทั่วไป |
|-------|---------|-------------|
| Pending | ถูกจัดสรรแล้วแต่ยังไม่รัน | Image pull, ทรัพยากรไม่เพียงพอ |
| Running | มีคอนเทนเนอร์อย่างน้อยหนึ่งตัวทำงานอยู่ | การทำงานปกติ |
| Succeeded | คอนเทนเนอร์ทั้งหมดออกด้วยโค้ด 0 | Batch jobs, init containers |
| Failed | มีคอนเทนเนอร์อย่างน้อยหนึ่งตัวออกด้วยโค้ดที่ไม่ใช่ศูนย์ | แอปพลิเคชันล่ม, OOMKill |
| Unknown | การสื่อสารกับโหนดหายไป | Network partition, โหนดล้มเหลว |

ฟิลด์ `restartPolicy` ควบคุมว่าจะเกิดอะไรขึ้นหลังจากคอนเทนเนอร์หยุดทำงาน `Always` (ค่าเริ่มต้นสำหรับ Deployments) จะรีสตาร์ทไม่ว่า exit code จะเป็นอะไร `OnFailure` จะรีสตาร์ทเฉพาะเมื่อออกด้วยโค้ดที่ไม่ใช่ศูนย์ ซึ่งมีประโยชน์สำหรับ Jobs ส่วน `Never` ปล่อยให้คอนเทนเนอร์หยุดทำงาน ใช้สำหรับ debug Pods แบบรันครั้งเดียว

```yaml
# batch-job-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: data-migration
spec:
  restartPolicy: OnFailure   # restart only on crash
  containers:
    - name: migrate
      image: registry.example.com/migrate:1.0.0
      command: ["python", "migrate.py"]
      env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: connection-string
```

รูปแบบ `valueFrom.secretKeyRef` ช่วยให้ข้อมูลที่ละเอียดอ่อนไม่ต้องอยู่ใน manifest Kubernetes Secrets ถูก encode ด้วย base64 โดยค่าเริ่มต้น ไม่ได้ถูกเข้ารหัส สำหรับ production ควรเปิดใช้งาน encryption at rest ผ่าน `EncryptionConfiguration` API หรือใช้ external secret manager เช่น HashiCorp Vault

## Kubernetes Deployments: การจัดการ Rollouts และ Scaling แบบ Declarative

[Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) สร้างและจัดการ ReplicaSets ซึ่งจะจัดการ Pods ต่อไป Deployment controller จะคอยสังเกต desired state และปรับให้ตรงกับความเป็นจริง โดยเพิ่ม Pods เมื่อ scale up แทนที่ Pods ระหว่าง rollouts และ rollback เมื่อ health checks ล้มเหลว

การสร้าง Pod โดยตรงแทบจะไม่เหมาะสมใน production เลย Deployments จัดหาการจัดการ replica, rolling updates, rollback history และความสามารถในการ pause/resume

```yaml
# api-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api
spec:
  replicas: 3                    # run 3 identical Pods
  revisionHistoryLimit: 5        # keep 5 old ReplicaSets for rollback
  selector:
    matchLabels:
      app: api                   # must match Pod template labels
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1          # at most 1 Pod down during update
      maxSurge: 1                # at most 1 extra Pod during update
  template:
    metadata:
      labels:
        app: api
        version: v2
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
```

ส่วน `strategy.rollingUpdate` กำหนดพฤติกรรมการ deploy แบบไม่มี downtime ด้วย `maxUnavailable: 1` และ `maxSurge: 1` Kubernetes จะสร้าง Pod ใหม่หนึ่งตัว รอให้ผ่าน readiness checks แล้วจึงยุติ Pod เก่าหนึ่งตัว วงจรนี้จะทำซ้ำจนกว่า replicas ทั้งหมดจะรันเวอร์ชันใหม่

### การ Rollback Kubernetes Deployment ที่ล้มเหลว

Rollbacks เป็นหัวข้อที่พบบ่อยในการสัมภาษณ์ Deployment controller เก็บ ReplicaSets เก่าไว้ (ควบคุมโดย `revisionHistoryLimit`) ดังนั้นการ rollback จึงทำได้ทันที ไม่ต้อง rebuild image

```bash
# Check rollout status
kubectl rollout status deployment/api-server

# View revision history
kubectl rollout history deployment/api-server

# Roll back to previous version
kubectl rollout undo deployment/api-server

# Roll back to specific revision
kubectl rollout undo deployment/api-server --to-revision=3
```

คำสั่ง `undo` จะแก้ไข Deployment spec ให้ตรงกับ Pod template ของ revision เป้าหมาย จากนั้น rolling update strategy จะถูกนำมาใช้ตามปกติ โดยค่อยๆ แทนที่ Pods ปัจจุบันด้วยเวอร์ชัน rollback

## Kubernetes Services: Networking ที่มีความเสถียรสำหรับ Pods ที่เปลี่ยนแปลงได้

Pods มีลักษณะชั่วคราว พวกมันจะได้รับ IP addresses ใหม่ทุกครั้งที่รีสตาร์ท [Service](https://kubernetes.io/docs/concepts/services-networking/service/) แก้ปัญหานี้โดยจัดหา virtual IP (ClusterIP) และ DNS name ที่มีความเสถียร ซึ่งจะเส้นทาง traffic ไปยัง Pods ที่มีสุขภาพดีที่ตรงกับ label selector

คอมโพเนนต์ kube-proxy บนแต่ละโหนดจะตั้งค่า iptables หรือ IPVS rules เพื่อกระจาย traffic ไปยัง backend Pods เมื่อ Pod ล้มเหลวใน readiness probe Endpoints controller จะลบมันออกจาก Service ทำให้ไม่มี traffic ไปถึง instances ที่ไม่มีสุขภาพดี

```yaml
# api-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  type: ClusterIP               # internal-only by default
  selector:
    app: api                     # routes to Pods with this label
  ports:
    - name: http
      port: 80                   # Service port (what clients use)
      targetPort: 8080           # Pod port (where container listens)
      protocol: TCP
```

เมื่อสร้างแล้ว Pod ใดๆ ใน cluster สามารถเข้าถึง Service นี้ได้ที่ `api-service.default.svc.cluster.local` (หรือแค่ `api-service` ภายใน namespace เดียวกัน) CoreDNS จะจัดการการแปลงชื่อ

## ประเภทของ Service: ClusterIP, NodePort และ LoadBalancer

ผู้สัมภาษณ์คาดหวังให้ผู้สมัครอธิบาย Service types หลักสามประเภทและเมื่อใดควรใช้แต่ละประเภท

| Type | Access Scope | กรณีการใช้งาน |
|------|-------------|----------|
| ClusterIP | ภายใน cluster เท่านั้น | Backend APIs, databases, caches |
| NodePort | External ผ่าน `<NodeIP>:<Port>` | Development, bare-metal clusters |
| LoadBalancer | External ผ่าน cloud LB | Production traffic บน AWS/GCP/Azure |

```yaml
# api-loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-public
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"  # AWS NLB
spec:
  type: LoadBalancer
  selector:
    app: api
  ports:
    - name: https
      port: 443
      targetPort: 8080
      protocol: TCP
```

ประเภท `LoadBalancer` จะกระตุ้นให้ load balancer controller ของ cloud provider จัดหา external endpoint บน AWS จะสร้าง NLB หรือ ALB ขึ้นอยู่กับ annotations บน bare-metal clusters ที่ไม่มี cloud integration MetalLB หรือ kube-vip จะทำหน้าที่นี้

> **Gateway API กำลังแทนที่ Ingress**
>
> ณ Kubernetes v1.35 Ingress NGINX controller ได้ถูกยกเลิกอย่างเป็นทางการแล้ว [Gateway API](https://gateway-api.sigs.k8s.io/) เป็นวิธีการที่แนะนำสำหรับ HTTP routing, TLS termination และ traffic splitting Clusters ใหม่ควรใช้ Gateway API ตั้งแต่เริ่มต้น

## การเชื่อมต่อ Deployments กับ Services ด้วย Label Selectors

การเชื่อมโยงระหว่าง Deployment และ Service คือ label selector เท่านั้น ไม่มีการอ้างอิงโดยตรงระหว่างสองออบเจ็กต์ Service จะคอยดู Pods ที่มี labels ตรงกับ `spec.selector` และดูแลรักษารายการ Endpoints โดยอัตโนมัติ

สถาปัตยกรรมแบบแยกส่วนนี้หมายความว่า Service เดียวสามารถกำหนดเส้นทางไปยัง Pods จากหลาย Deployments ได้ (มีประโยชน์สำหรับ canary releases) และ Deployment สามารถถูกเปิดเผยโดยหลาย Services (พอร์ตต่างกัน ระดับการเข้าถึงต่างกัน)

```yaml
# canary-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api                   # same label as main Deployment
  template:
    metadata:
      labels:
        app: api                 # Service picks this up automatically
        version: v3-canary
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.2.0-rc1
          ports:
            - containerPort: 8080
```

ด้วย Deployment หลักที่รัน 3 replicas และ canary ที่รัน 1 Service จะกระจายประมาณ 25% ของ traffic ไปยัง canary ไม่ต้องเปลี่ยนการตั้งค่า Service label matching จัดการทุกอย่าง

## Horizontal Pod Autoscaling สำหรับ Kubernetes Deployments

จำนวน replica แบบคงที่จะสิ้นเปลืองทรัพยากรในช่วง traffic ต่ำและไม่เพียงพอในช่วง traffic พุ่ง [HorizontalPodAutoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) จะปรับจำนวน replica ตาม metrics ที่สังเกตได้

```yaml
# api-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70   # scale up above 70% CPU
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # wait 5 min before scaling down
```

HPA จะสำรวจ metrics server ทุก 15 วินาทีโดยค่าเริ่มต้น `behavior.scaleDown.stabilizationWindowSeconds` ป้องกันการกระพือ ซึ่งเป็นวงจร scale-up/scale-down ที่เกิดขึ้นเร็วเกินไปเนื่องจาก traffic patterns แบบมีพัก

## คำถามสัมภาษณ์ Kubernetes ที่พบบ่อยและคำตอบ

คำถามเหล่านี้ปรากฏซ้ำๆ ในการสัมภาษณ์ตำแหน่ง DevOps และ Platform Engineering คำตอบแต่ละข้อมุ่งเป้าไปที่ความลึกที่ผู้สัมภาษณ์คาดหวัง

**เกิดอะไรขึ้นเมื่อ Pod ใช้หน่วยความจำเกิน memory limit**
kubelet จะส่ง SIGKILL ผ่าน OOM killer คอนเทนเนอร์จะออกด้วยโค้ด 137 Deployment controller จะตรวจจับ Pod ที่ล้มเหลวและสร้างตัวทดแทน ขึ้นอยู่กับ restart policy และ backoff delays

**Kubernetes กำหนดเส้นทาง traffic ไปยัง Pod เวอร์ชันเฉพาะระหว่าง canary releases อย่างไร**
Service selector จะจับคู่กับ labels ที่แชร์กัน (เช่น `app: api`) ทั้ง stable และ canary Deployments ใช้ label นี้ การกระจาย traffic จะสัมพันธ์กับจำนวน ready endpoints ซึ่ง 3 stable replicas + 1 canary replica หมายความว่าประมาณ 25% canary traffic สำหรับการแบ่ง traffic ที่แม่นยำ (เช่น 5%) ให้ใช้ Gateway API HTTPRoute กับ weighted backends

**`readinessProbe` และ `livenessProbe` ต่างกันอย่างไร**
readiness probe ควบคุมว่า Pod จะรับ traffic จาก Service หรือไม่ การล้มเหลวของ readiness probe จะลบ Pod ออกจากรายการ Endpoints แต่ไม่รีสตาร์ท liveness probe ควบคุมว่าคอนเทนเนอร์จะถูกรีสตาร์ทหรือไม่ การล้มเหลวของ liveness probe จะทำให้เกิดการรีสตาร์ทคอนเทนเนอร์ ทั้งสองสามารถใช้ HTTP, TCP หรือ exec checks

**rolling updates รับประกันว่าจะไม่มี downtime อย่างไร**
Deployment controller จะสร้าง Pods ใหม่ก่อนยุติ Pods เก่า ควบคุมโดย `maxSurge` และ `maxUnavailable` Pods ใหม่ต้องผ่าน readiness probes ก่อนที่ Pods เก่าจะถูก drained `terminationGracePeriodSeconds` (ค่าเริ่มต้น: 30s) ให้เวลา in-flight requests เสร็จสิ้นก่อน SIGKILL

การเตรียมตัวสำหรับการสัมภาษณ์ Kubernetes ต้องการการฝึกปฏิบัติ YAML จริงๆ ไม่ใช่แค่ทฤษฎี [คำถามสัมภาษณ์ DevOps](/technologies/devops/interview-questions/kubernetes-basics) บน SharpSkill ครอบคลุมหัวข้อเหล่านี้ด้วยแบบฝึกหัดแบบโต้ตอบ

## สรุป

- Pods คือหน่วยการจัดสรร ควรตั้งค่า `requests` และ `limits` ของทรัพยากรเสมอ และกำหนดค่าทั้ง readiness และ liveness probes
- Deployments จัดการจำนวน replica, rolling updates และ rollback history ผ่าน ReplicaSets ไม่ควรสร้าง bare Pods ใน production
- Services จัดหา networking ที่มีความเสถียรผ่าน label selectors และ virtual IPs ใช้ ClusterIP สำหรับ internal traffic และ LoadBalancer สำหรับ external
- การเชื่อมโยงระหว่าง Deployments และ Services อิงตาม label เท่านั้น ทำให้สามารถทำ canary patterns ได้โดยไม่ต้องเปลี่ยนการตั้งค่า
- HPA จะ scale Deployments ตาม CPU/memory metrics ควรใช้ `stabilizationWindowSeconds` เพื่อป้องกันการกระพือ
- Gateway API แทนที่ Ingress NGINX ณ Kubernetes v1.35 โปรเจกต์ใหม่ควรใช้งานตั้งแต่เริ่มต้น
- ฝึกปฏิบัติกับ YAML manifests จริงและคำสั่ง `kubectl` แทนการท่องจำคำจำกัดความ

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/th/blog/devops/kubernetes-interview-pods-services-deployments-explained