Kubernetes overview - Phần 1/2 - Object model, kiến trúc cluster và workload resource

Bài 3/6 trong series CI/CD và Kubernetes. Nếu chưa quen với pipeline, hãy đọc CI/CD overview (Phần 1/2) và Phần 2/2 trước nhé!

Mục tiêu

Phần này tập trung tìm hiểu các nội dung sau:

• giải thích desired state và reconciliation loop;
• đọc object Kubernetes qua apiVersion, kind, metadata, spec và status;
• mô tả vai trò của API Server, etcd, Scheduler, Controller Manager, kubelet, container runtime, CNI và CoreDNS;
• phân biệt Pod, ReplicaSet, Deployment, StatefulSet, DaemonSet, Job và CronJob;
• hiểu scheduling, resource management, configuration, identity (RBAC) và storage ở mức nền tảng.

Vì sao container chưa đủ

Container là đơn vị đóng gói và chạy ứng dụng. Khi chỉ có một container trên laptop, ta có thể dùng docker run, xem log và restart thủ công. Trong môi trường thật, các câu hỏi nhanh chóng phức tạp hơn:

• Container nên chạy trên máy nào?
• Nếu process chết hoặc cả máy mất network connectivity thì ai tạo bản thay thế?
• Client tạo connection tới đâu khi địa chỉ của container thay đổi?
• Làm sao cập nhật phiên bản mà không dừng toàn bộ dịch vụ?
• Khi tải tăng, làm sao thêm instance và khi tải giảm, làm sao thu hồi chúng?

Kubernetes là hệ thống orchestration giải quyết nhóm vấn đề này. Ta không ra lệnh “hãy chạy container ở máy A mãi mãi”. Ta khai báo “tôi muốn ba bản sao của workload này, dùng image này, chỉ nhận traffic khi probe thành công”. Các controller liên tục đưa actual state về gần desired state.

Object model và desired state

Mọi thứ người dùng tạo trong Kubernetes đều được biểu diễn thành API object. Manifest YAML là cách khai báo object; API Server mới là nơi kiểm tra, lưu và cung cấp object cho controller.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mqtt-broker
  namespace: mqtt
  labels:
    app.kubernetes.io/name: mqtt-broker
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: mqtt-broker
  template:
    metadata:
      labels:
        app.kubernetes.io/name: mqtt-broker
    spec:
      containers:
        - name: broker
          image: registry.example/mqtt-broker:v1.0.0

Năm trường nền tảng:

• apiVersion chọn nhóm API và phiên bản schema.
• kind cho biết loại resource, chẳng hạn Deployment hoặc Service.
• metadata chứa tên, namespace, label, annotation và thông tin nhận diện.
• spec là desired state do người dùng khai báo.
• status là actual state do Kubernetes controller cập nhật; thông thường không viết status trong manifest.

Label, selector và annotation

Label là cặp key/value dùng để nhóm và chọn object. Deployment dùng selector để nhận diện Pod thuộc quyền quản lý; Service dùng selector để tìm backend. Selector sai có thể khiến Service không có endpoint hoặc Deployment không quản lý đúng Pod. Annotation chứa metadata không dùng để chọn object, ví dụ release tag, commit SHA hoặc đường dẫn pipeline. Label nên ngắn và có cấu trúc ổn định; annotation phù hợp với dữ liệu truy vết chi tiết hơn.

Namespace và phạm vi

Namespace chia resource trong cùng cluster thành các phạm vi logic. Tên mqtt-broker chỉ cần duy nhất trong namespace mqtt, không cần duy nhất toàn cluster. Deployment, Pod, Service, ConfigMap và Secret thường có namespace; Node, PersistentVolume và Namespace là resource cấp cluster. Namespace giúp tổ chức, áp ResourceQuota và RBAC, nhưng tự nó không phải ranh giới bảo mật hoàn chỉnh. Muốn cô lập tenant còn cần policy mạng, identity và cấu hình cluster phù hợp.

Desired state và reconciliation loop

Desired state là điều khai báo trong spec; actual state được phản ánh qua status và các object liên quan. Controller lặp liên tục quá trình quan sát và sửa chênh lệch:

Ví dụ Deployment yêu cầu ba Pod: nếu còn hai Pod, controller tạo thêm; nếu template đổi image, controller tạo revision mới; nếu có bốn Pod ngoài ý muốn, controller giảm về ba. Vì vậy Pod là thực thể có thể thay thế, còn controller giữ ý định lâu dài. kubectl apply không trực tiếp “chạy container”. Nó gửi object tới API Server; các controller, Scheduler và kubelet phối hợp để hiện thực hóa object đó.

Kiến trúc một Kubernetes cluster

Cluster gồm control plane và một hay nhiều Node chạy workload. Các component giao tiếp qua Kubernetes API thay vì cùng sửa trực tiếp một database hay file cấu hình.

Các component của control plane

• kube-apiserver là entry point của cluster. Nó xác thực request, chạy authorization và admission, kiểm tra schema rồi đọc/ghi state. kubectl, kubelet và controller đều nói chuyện với API Server.
• etcd là key-value store nhất quán lưu state của Kubernetes. Mất etcd có thể đồng nghĩa mất state control plane, vì vậy production cần backup và mô hình high availability phù hợp.
• kube-scheduler chọn Node cho Pod chưa được gán Node. Scheduler xét resource request, constraint, affinity, taint/toleration và topology; nó không trực tiếp khởi động container.
• kube-controller-manager chạy các reconciliation controller như Deployment, ReplicaSet, Node, Job và EndpointSlice controller.
• cloud-controller-manager tích hợp với cloud provider để quản lý tài nguyên như load balancer, route hoặc thông tin Node. Cluster không dùng cloud integration có thể không cần component này.

Các component trên Node

Node thường là máy vật lý hoặc VM đã đăng ký với cluster. Node object báo capacity, allocatable resources và các condition như Ready; nó không phải Pod và cũng không được Deployment tạo ra.

• kubelet là agent trên từng Node. Nó theo dõi PodSpec đã được gán, yêu cầu runtime tạo container, mount volume và thực hiện probe.
• container runtime chạy container thông qua Container Runtime Interface (CRI). Lab dùng containerd; Docker image vẫn chạy được vì image format không phụ thuộc Docker daemon.
• CNI plugin cấp network interface và kết nối mạng cho Pod. Lab cài Flannel để tạo Pod network.
• kube-proxy hoặc service proxy tương đương lập trình đường dữ liệu để Service chuyển traffic đến backend. Một số CNI có thể thay chức năng này bằng eBPF.

Add-on thường gặp

• CoreDNS cung cấp service discovery bằng DNS, ví dụ mqtt-broker.mqtt.svc.cluster.local.
• Ingress Controller hiện thực hóa Ingress rule cho HTTP/HTTPS. Tạo object Ingress mà không có controller sẽ không tự sinh traffic path.
• Metrics Server cung cấp CPU/memory resource metrics cho kubectl top và HPA cơ bản; nó không thay thế Prometheus.
• Prometheus, Prometheus Adapter và Grafana lần lượt thu thập metric, đưa custom metric vào Kubernetes API và trực quan hóa dữ liệu trong lab. Lab có một control-plane và hai worker. Control-plane được bỏ taint để cũng có thể chạy workload, phù hợp seminar nhỏ nhưng không phải mẫu high availability cho production.

Các workload resource

Workload resource là API object quản lý Pod theo một hành vi vòng đời cụ thể. Không phải ứng dụng nào cũng nên dùng Deployment.

Pod: building block nhỏ nhất

Pod là đơn vị nhỏ nhất Scheduler đặt lên Node. Các container trong cùng Pod dùng chung network namespace, địa chỉ IP và volume được khai báo. Chúng được co-locate và có cùng vòng đời scheduling, nên chỉ đặt chung khi thực sự cần phối hợp chặt. Ngoài application container, Pod có thể có:

• init container chạy tuần tự trước application container để chuẩn bị cấu hình hoặc dependency;
• sidecar container chạy cùng ứng dụng để cung cấp chức năng hỗ trợ như proxy hoặc log shipping;
• ephemeral container được thêm phục vụ debug, không phải cách triển khai service thường xuyên. MQTT Pod trong lab có một application container tên broker, mount TLS Secret và mở các port MQTT cùng metrics.

ReplicaSet và Deployment

ReplicaSet bảo đảm số Pod khớp replicas. Deployment quản lý ReplicaSet và lịch sử revision. Khi Pod template đổi, Deployment tạo ReplicaSet mới, tăng Pod mới và giảm Pod cũ theo rollout strategy.

ownerReferences cho Kubernetes biết quan hệ sở hữu để controller và garbage collector xử lý object con. Xóa Deployment theo propagation policy thông thường sẽ kéo theo ReplicaSet và Pod do nó sở hữu; xóa riêng một Pod chỉ khiến ReplicaSet tạo Pod thay thế. Không nên sửa Pod hay ReplicaSet do Deployment quản lý để tạo thay đổi lâu dài. Controller cấp trên sẽ ghi lại hoặc thay thế chúng. Hãy sửa Deployment.

StatefulSet

StatefulSet tạo Pod có tên ổn định như database-0, database-1, hỗ trợ thứ tự start/stop và PVC riêng qua volumeClaimTemplates. Nó thường kết hợp Headless Service để cung cấp DNS identity ổn định cho từng Pod. StatefulSet không tự biến một ứng dụng stateful thành hệ thống phân tán an toàn; replication, quorum, backup và restore vẫn thuộc thiết kế ứng dụng.

DaemonSet

DaemonSet duy trì một Pod trên mỗi Node phù hợp. Khi thêm Node, Pod tương ứng được tạo. Log collector, node exporter và CNI agent là các ví dụ phổ biến. Node selector, affinity và taint/toleration quyết định DaemonSet có chạy trên mọi Node hay chỉ một nhóm.

Job và CronJob

Job theo dõi tác vụ đến khi đủ số completion thành công; backoffLimit kiểm soát retry. CronJob tạo Job theo lịch, vì vậy cần cân nhắc concurrencyPolicy, lịch sử Job và tính idempotent khi một lần chạy bị lặp hoặc chồng lấn. MQTT broker là service stateless và long-running nên dùng Deployment. MQTT load test là tác vụ hữu hạn nên về mặt Kubernetes có thể mô hình hóa thành Job, dù trong lab nó chạy bằng GitLab Runner bên ngoài cluster.

Scheduling và resource management

Scheduler chọn Node dựa trên desired state và resource đã khai báo, không dựa trực tiếp trên mức CPU tức thời của container.

Requests và limits

• Request là lượng CPU/memory Scheduler dùng để quyết định Node còn chỗ hay không.
• Limit là trần runtime. Vượt CPU limit thường bị throttling; vượt memory limit có thể khiến container bị OOM kill.

Nếu không khai báo request, Scheduler thiếu tín hiệu để phân bổ ổn định. Nếu request quá cao, Pod có thể Pending dù cluster còn tài nguyên sử dụng thực tế; nếu quá thấp, nhiều Pod dồn lên một Node và cạnh tranh khi tải tăng. MQTT broker request 100m CPU và 128Mi memory, limit 500m CPU và 256Mi memory. Đây là cấu hình seminar, cần đo tải thật trước khi dùng cho production.

Constraint và placement

• nodeSelector chọn Node bằng label theo điều kiện đơn giản.
• node affinity/anti-affinity biểu diễn điều kiện placement linh hoạt hơn.
• taint ngăn Pod không phù hợp vào Node; toleration cho phép Pod chấp nhận taint nhưng không bắt buộc Scheduler chọn Node đó.
• topology spread constraint phân phối Pod qua Node hoặc zone để giảm correlated failure.
• PodDisruptionBudget giới hạn số Pod có thể đồng thời unavailable trong voluntary disruption như drain Node; nó không bảo vệ khỏi Node crash và không tạo thêm replica.

Configuration, identity và storage

ConfigMap và Secret

ConfigMap lưu cấu hình không nhạy cảm; Secret lưu dữ liệu cần được quản lý như thông tin nhạy cảm. Cả hai có thể được đưa vào container qua environment variable hoặc volume. Gọi một resource là Secret không tự động giải quyết mã hóa, phân quyền và rotation. Cần kết hợp RBAC, encryption at rest và quy trình không in nội dung Secret ra log. Trong lab, wildcard TLS certificate được mount read-only vào broker. Thay ConfigMap hoặc Secret không phải lúc nào cũng tự restart Pod. Nếu ứng dụng đọc qua volume, nội dung có thể được cập nhật sau một khoảng thời gian nhưng ứng dụng phải biết reload. Nếu dùng environment variable, thường cần rollout Pod mới.

ServiceAccount và RBAC

ServiceAccount là identity cho process chạy trong Pod hoặc automation truy cập Kubernetes API. RBAC ghép Role/ClusterRole với subject qua RoleBinding/ClusterRoleBinding. CI của broker dùng ServiceAccount riêng, chỉ được patch Deployment liên quan, quản lý HPA và xóa broker Pod phục vụ fault injection trong namespace mqtt. Nó không dùng quyền cluster-admin. Namespace scope và resourceNames giúp giảm blast radius, dù một số verb như tạo resource hoặc xóa Pod sinh tên động không thể giới hạn hoàn toàn bằng resourceNames.

Volume, PV, PVC và StorageClass

Filesystem ghi trong writable layer của container không phải nơi lưu dữ liệu bền vững. Khi container hoặc Pod bị thay, dữ liệu đó có thể mất.

Volume được khai báo trong Pod và mount vào container; vòng đời tùy loại volume.

• emptyDir tồn tại theo vòng đời Pod, phù hợp dữ liệu tạm dùng chung giữa container.
• PersistentVolumeClaim (PVC) là yêu cầu storage của workload.
• PersistentVolume (PV) biểu diễn storage cấp cluster đã provision.
• StorageClass mô tả lớp storage và chính sách dynamic provisioning.
• CSI driver là integration thực hiện create, attach, mount và snapshot tùy backend. MQTT broker của lab được thiết kế stateless nên không dùng PVC cho message state. TLS certificate đến từ Secret volume, không phải persistent application data.

Đây là các resource nền tảng của một Pod. Phần tiếp theo sẽ theo dấu traffic thật đi qua Service tới các Pod này, và xem điều gì xảy ra khi một Pod biến mất.