Docker không phải Kubernetes thu nhỏ

Docker tooling build và chạy containers trên một engine/host; Kubernetes quản desired state của workloads trên cluster qua API/controllers. Kubernetes hiện không cần Docker Engine để chạy Pod.

1. Trách nhiệm khác nhau

2. Image tới process trong Pod

docker build / buildx
  → OCI manifest + config + layers
  → registry by tag/digest
  → kubelet observes assigned Pod
  → CRI ImageService pulls/unpacks image
  → CRI RuntimeService creates Pod sandbox + containers
  → OCI runtime configures namespaces/cgroups/mounts/seccomp
  → application becomes PID 1 inside container namespace

Kubernetes bỏ dockershim từ lâu; image do Docker build vẫn chạy vì tuân OCI image format. Docker Engine và containerd không đồng nghĩa: Engine dùng containerd, nhưng kubelet nói qua CRI implementation chứ không gọi Docker CLI/API.

3. Dockerfile contract trở thành Pod behavior

4. Compose không chuyển 1:1 sang Kubernetes

• Compose service thường map sang Deployment/StatefulSet + Service, nhưng lifecycle/identity/storage khác.
• depends_on không trở thành startup ordering. Kubernetes giả định dependencies có thể restart; app cần retry/backoff/readiness.
• Published port map sang Service/Ingress/Gateway, không phải hostPort mặc định.
• Named volume không tự map PVC; cần StorageClass/access mode/reclaim/backup/topology.
• Environment variables có thể map ConfigMap/Secret, nhưng secret lifecycle/rotation/RBAC cần thiết kế.
• Replicas yêu cầu stateless/shared state design; chỉ tăng replica không sửa local session/file state.

5. Resource limits: cùng kernel, khác scheduling layer

Docker runtime cgroups enforce CPU/memory/pids. Kubernetes thêm requests để scheduler đặt Pod và limits để runtime/cgroup enforce. CPU limit có thể throttle; memory limit có thể OOMKill. JVM memory gồm heap, metaspace, code cache, direct buffers, thread stacks và native/page cache.

resources:
  requests: { cpu: "500m", memory: "768Mi" }
  limits:   { cpu: "1",    memory: "1Gi" }

Request quá thấp tạo noisy neighbor/overpacking và HPA utilization sai; limit quá chặt tạo throttle/OOM. Tune từ workload và downstream capacity, không copy defaults.

6. Signals và termination timeline

Pod deletion / rollout
  → Endpoint readiness/removal bắt đầu hội tụ
  → preStop hook nếu có
  → SIGTERM tới container PID 1
  → app stop intake, drain in-flight, checkpoint
  → grace period hết thì SIGKILL

Endpoint propagation và proxy/LB connection draining không instant. App phải xử lý repeated/late requests và idempotency. preStop tiêu trong cùng terminationGracePeriodSeconds, không cộng thêm thời gian.

7. Networking mapping

8. Storage mapping

Container writable layer vẫn ephemeral. emptyDir sống theo Pod, không theo container restart nhưng mất khi Pod bị xóa/reschedule. PVC có lifecycle riêng và được CSI provision/attach/mount; access modes không tự chứng minh storage thật sự hỗ trợ concurrent application semantics. StatefulSet cho identity/order/PVC templates, không tự replicate database hoặc backup.

9. Security layers

1. Supply chain: trusted base, pin digest, SBOM, scan/sign/provenance.
2. Container: non-root, read-only, drop capabilities, seccomp, no privilege escalation.
3. Pod/workload: ServiceAccount, securityContext, resource bounds.
4. Cluster/API: RBAC, admission, audit, Secret encryption/external manager.
5. Network/tenant: default-deny policies, namespace/cluster boundaries theo threat model.

10. Debug theo layer

1. Image: digest/platform/config/user/entrypoint/file permissions.
2. Runtime: container state, exit code, OOM, mounts, cgroups.
3. Pod: init, probes, events, previous logs, security context.
4. Scheduling: requests, taints, affinity, topology, PVC.
5. Network: listener → Pod IP → EndpointSlice → Service → Ingress/Gateway/DNS.
6. Controller: rollout conditions, ReplicaSet ownership, desired/available replicas.
7. Application: request trace, pool/queue/downstream saturation và business invariant.

11. Interview questions