Kiến Trúc Control Plane Components — API Server, Scheduler, Controller-Manager, Cloud-Controller-Manager

Tại Sao Cần Hiểu Từng Component

Khi container không khởi động, hoặc pod bị stuck pending, hoặc service không được reconcile — vấn đề có thể ở bất kỳ component nào. Hiểu role của từng thành phần giúp:

Thu hẹp nguyên nhân gốc — Biết nơi tìm trong logs
Dự đoán chế độ thất bại — Biết component nào fail → ảnh hưởng gì
Lập kế hoạch phân bổ tài nguyên — Control plane cần CPU/bộ nhớ khác
Thiết kế mẫu HA — Biết phụ thuộc để tránh điểm lỗi duy nhất

High-Level Architecture

┌──────────────────────────────────────────────────┐
│              Control Plane Nodes                  │
│  (Replicated across 3 zones for HA)              │
├──────────────────────────────────────────────────┤
│  ┌─────────────┐  ┌──────────────┐  ┌──────────┐ │
│  │  API Server │  │  Scheduler   │  │Controller│ │
│  │  (multiple) │  │ (leader el.) │  │ Manager  │ │
│  └─────────────┘  └──────────────┘  └──────────┘ │
│        │                                   │      │
│        └────────────────┬───────────────────┘      │
│                         │                          │
│                    ┌────▼─────┐                   │
│                    │   etcd    │                   │
│                    │(consensus)│                   │
│                    └───────────┘                   │
│                                                   │
│  ┌────────────────────────────────────────────┐  │
│  │  Cloud-Controller-Manager                  │  │
│  │  (GCP-specific reconcilers)                │  │
│  └────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────┘

                       │
        ┌──────────────┴──────────────┐
        │                             │
   ┌────▼─────────┐            ┌─────▼──────┐
   │  Worker      │            │  Worker    │
   │  Nodes       │            │  Nodes     │
   │              │            │            │
   │ ┌──────────┐ │            │┌──────────┐│
   │ │ kubelet  │ │            ││ kubelet  ││
   │ │(runs     │ │            ││(watches  ││
   │ │pods)     │ │            ││control   ││
   │ └──────────┘ │            ││plane)    ││
   └──────────────┘            └┴──────────┘

1. API Server — The Heart of Kubernetes

Role dan Responsibilities

API Server là entry point duy nhất cho tất cả Kubernetes operations:

REST endpoint mà tất cả clients (kubectl, controllers, kubelets) gọi
State storage gateway — write/read từ etcd
Request validation — syntax checking, schema validation
Admission control — webhooks, mutations
Watch provider — streaming changes cho clients

Lifecycle

Mỗi request đi qua API Server theo path này:

1. TLS Termination
   ↓
2. Authentication (certificate/token/OIDC)
   ↓
3. Authorization (RBAC, ACL)
   ↓
4. Admission (webhooks, policies)
   ↓
5. etcd Write/Read
   ↓
6. Response Serialization
   ↓
7. Stream/Return to Client

Chi tiết ở Chương 11 — nhưng quan trọng biết luồng tổng thể.

Configuration yang Bisa Tune (GKE Context)

Di GKE, API Server configuration limited, tapi beberapa option ada:

bash

# Tạo cluster với cờ API server tùy chỉnh (GKE hỗ trợ hạn chế)
gcloud container clusters create my-cluster \
  --enable-client-certificate=false \
  --disable-basic-auth \
  --enable-enable-authentication

# Kiểm tra audit API server
gcloud container clusters update my-cluster \
  --enable-cloud-logging

Chế Độ Thất Bại Phổ Biến

Triệu Chứng	Nguyên Nhân Có Thể	Gỡ Lỗi
502/503 lỗi từ kubectl	API Server quá tải hoặc crash	Kiểm tra GCP Cloud Logging
Kết nối watch bị rơi	Restart API Server hoặc vấn đề etcd	Kiểm tra logs kết nối lại
API phản hồi chậm	Timeout webhooks admission	Kiểm tra latency webhook
Lỗi chứng chỉ	Điều kiện race rotation CA	Kiểm tra kube-apiserver logs

Đặc Điểm Hiệu Năng

Giới hạn tỷ lệ yêu cầu: ~1000s yêu cầu/giây per server (phụ thuộc tải)
Kết nối watch: Tối đa hàng nghìn watch đồng thời per server
Khả năng burst: Bị giới hạn bởi latency backend etcd
Bandwidth mạng: Kích thước dữ liệu quan trọng (đối tượng lớn làm chậm)

2. Scheduler — Pod Placement Decision Maker

Vai Trò và Trách Nhiệm

Scheduler quyết định Pod nào chạy trên Node nào. Đây không phải quyết định tầm thường.

Input: Pod Chờ
         ↓
    ┌────────────────────────────────┐
    │ Giai Đoạn Lọc                │
    │ - Tài nguyên đủ?        │
    │ - Node affinity/anti?    │
    │ - Taints & tolerations OK?     │
    │ - PVC bindings có?      │
    └────────────────────────────────┘
         ↓ (tập node giảm)
    ┌────────────────────────────────┐
    │ Giai Đoạn Ghi Điểm                  │
    │ - Sử dụng tài nguyên         │
    │ - Tùy chọn Affinity         │
    │ - Vị trí Image (tối ưu)    │
    │ - Điểm plugin khác          │
    └────────────────────────────────┘
         ↓ (nodes xếp hạng)
    ┌────────────────────────────────┐
    │ Giai Đoạn Ràng Buộc                  │
    │ - Cập nhật etcd với Pod node    │
    │ - Thông báo kubelet khởi chạy     │
    └────────────────────────────────┘
         ↓
    Output: Pod ràng buộc vào Node

Bầu Chọn Lãnh Đạo

Scheduler chạy dạng instance aktif duy nhất (các instance khác ở chế độ chờ):

yaml

# Chỉ một scheduler tích cực scheduling
kubectl get pods -n kube-system -l component=kube-scheduler
# Sẽ thấy 3 replicas, nhưng chỉ 1 leader

# Kiểm tra leader
kubectl get lease -n kube-system kube-scheduler -o yaml

Ảnh hưởng:

Nếu leader scheduler crash, lãnh đạo mới được bầu chọn trong ~5-15 giây
Pods không thể scheduled trong giai đoạn chuyển đổi
Bầu chọn dựa trên cơ chế lease etcd

Hàng Đợi Scheduling

Scheduler duy trì hàng đợi các pods chờ:

┌─────────────┐
│  Chờ    │  Hàng đợi hoạt động —
│   Pods      │  Pods dưới scheduling
├─────────────┤
│ Back-off    │  Retry pods đã
│   Pods      │  scheduling thất bại
├─────────────┤
│ Unschedulable├  Pods cuối cùng failed
│   Pods      │  với lý do vĩnh viễn
└─────────────┘

Pods di chuyển giữa các hàng đợi dựa trên:

Retry lùi exponential (ngăn scheduler thrashing)
Kích hoạt dựa trên sự kiện (node mới → hàng đợi lại unschedulable)

Chế Độ Thất Bại Phổ Biến

Triệu Chứng	Nguyên Nhân Có Thể	Gỡ Lỗi
Pod mắc kẹt Pending	Tài nguyên không đủ hoặc node selector không khớp	`kubectl describe pod` hiển thị lý do chờ
Pods scheduled không đều	Score plugins cấu hình sai	Kiểm tra logs scheduler
Scheduling delays (10s+)	etcd latency hoặc delays webhook	Giám sát chỉ số latency scheduler
Preemption thrashing	Cấu hình sai PriorityClass	Kiểm tra mẫu pods bị chiếm quyền

Xem Xét Production

Scheduling latency SLO: Target < 5s cho 99th percentile (từ tạo pod → scheduled)

bash

# Giám sát scheduling latency (GKE công bố chỉ số này)
kubectl top nodes  # xem đơn giản

# Chi tiết hơn: kiểm tra chỉ số Prometheus
# kube_pod_info{condition="ready"}
# scheduler_scheduling_latency_seconds

3. Controller-Manager — Reconciliation Engine

Vai Trò và Trách Nhiệm

Controller-Manager chạy tập hợp controllers liên tục hoà hợp trạng thái:

Trạng Thái Mong Đợi (YAML)
        ↓
   Reconciler
        ↓
   Trạng Thái Thực Tế
        ↓
   So Sánh ≠? 
        ↓
   Hành Động (tạo, cập nhật, xóa tài nguyên)
        ↓
   Vòng lặp lại mỗi N giây

Controllers Tích Hợp (Danh Sách Một Phần)

Controller	Hoà Hợp	Hành Động
Deployment	Mong đợi → Pods thực tế	Tạo/cập nhật ReplicaSet
ReplicaSet	Mong đợi → số Pods thực tế	Tạo/xóa Pods
StatefulSet	Pods theo thứ tự, danh tính ổn định	Quản lý lifecycle pod + thứ tự
DaemonSet	Pod trên mỗi node	Schedules pods per node
Job	Chạy hoàn tất	Tạo Pods, theo dõi hoàn tất
Service	Khám phá Endpoint	Cập nhật endpoints khi Pods thay đổi
PersistentVolume	Ràng buộc lưu trữ	Claims → volumes

Mẫu Vòng Lặp Hoà Hợp

Tất cả controller tuân theo thiết kế level-triggered:

// Pseudo-code của mỗi vòng lặp hoà hợp
for {
    // Lấy trạng thái mong đợi từ YAML (etcd)
    desired := getDesiredState(namespace, name)
    
    // Lấy trạng thái hiện tại từ cluster
    actual := getCurrentState(namespace, name)
    
    // So sánh
    if desired != actual {
        // Thực hiện hành động để actual khớp với desired
        takeCorrectiveAction()
    }
    
    // Ngủ, chờ hoà hợp tiếp theo
    sleep(resyncInterval)  // ~2-15 phút tùy controller
}

Ưu điểm: Mạnh mẽ với các sự kiện bị bỏ lỡ, tính nhất quán cuối cùng được đảm bảo

Nhược điểm: Latency giữa desired→actual có thể là phút

Bầu Chọn Lãnh Đạo Cho Reconcilers

Giống scheduler, chỉ một instance controller-manager hoạt động:

bash

kubectl get lease -n kube-system kubecontroller-manager

Điều này ngăn chặn điều kiện race (nhiều instances cố hoà hợp tài nguyên giống nhau).

Chế Độ Thất Bại Phổ Biến

Triệu Chứng	Nguyên Nhân Có Thể	Gỡ Lỗi
Deployments không scaling	Vấn đề controller ReplicaSet	Kiểm tra logs controller-manager
StatefulSet Pods không thứ tự	Bug logic thứ tự hoặc cập nhật đồng thời	Kiểm tra ordinals StatefulSet
PVCs không ràng buộc	Vấn đề controller PersistentVolume	Kiểm tra trạng thái PVC
Stuck finalizers	Controller crashed trước cleanup	Cần can thiệp thủ công

Xem Xét Production

Reconciliation latency: Điển hình 30-60 giây (chu kỳ vòng lặp)

Deployment được tạo → kubelet thấy Pod spec → Pod bắt đầu ≈ 5-10 giây
Pod bị xóa → vòng lặp controller nhận biết → finalizers chạy ≈ 10-30 giây
Hiệu năng controller tùy chỉnh phụ thuộc triển khai

4. Cloud-Controller-Manager — GCP-Specific Reconcilers

Vai Trò và Trách Nhiệm

Cloud-Controller-Manager là component cụ thể GKE hoà hợp tài nguyên cloud:

Tài Nguyên	Controller	Hành Động
Service (type: LoadBalancer)	Service controller	Tạo GCP Load Balancer
Ingress	Ingress controller	Tạo GCP HTTP LB
PersistentVolume	Volume controller	Cấp phát GCP Disks
Node	Node controller	Đồng bộ hoá trạng thái node với GCP

Ví Dụ: Hoà Hợp Service LoadBalancer

yaml

# Người dùng tạo service LoadBalancer
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer  # ← kích hoạt cloud-controller
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: myapp

# Cloud-controller-manager:
# 1. Giám sát tài nguyên Service
# 2. Thấy type: LoadBalancer
# 3. Gọi GCP APIs: tạo Load Balancer, Backend Service
# 4. Gán external IP
# 5. Cập nhật Service status.loadBalancer.ingress[].ip

Hành Vi Cụ Thể GKE

Cloud-Controller-Manager xử lý:

Node taints — Autopilot vs Standard taints
Network routes — Quản lý VPC routes
Service IP allocation — Gán ClusterIP
Persistent Volume provisioning — Tạo Disk

Leader Election

Like scheduler/controller-manager, CCM runs in HA:

bash

kubectl get lease -n kube-system cloud-controller-manager

Chế Độ Thất Bại Phổ Biến

Triệu Chứng	Nguyên Nhân Có Thể	Gỡ Lỗi
Service mắc kẹt pending (LoadBalancer type)	CCM không chạy hoặc GCP API throttle	Kiểm tra logs CCM
External IPs không được gán	Hạn ngạch mạng đã hết	Kiểm tra hạn ngạch GCP
PersistentVolumes không cấp phát	Hạn ngạch GCP Disk hoặc ràng buộc vùng	Kiểm tra logs CCM

Inter-Component Communication

Dependency Chain

API Server ← (all components watch)
    ↓
    ├→ Scheduler (watches unscheduled Pods)
    ├→ Controller-Manager (watches all resources)
    └→ Cloud-Controller-Manager (watches cloud-specific resources)
    
All write back via API Server

Cơ Chế Watch

Components không poll etcd. Họ sử dụng watch API:

bash

# Dưới nắp, mỗi controller làm cái gì đó như:
watch --resource=pods --field-selector=status.phase=Pending
# Streams sự kiện: ADDED, MODIFIED, DELETED

# Đây là SỰ KHÁC BIỆT KHỔNG LỒ so với polling

Ảnh hưởng: Nếu kết nối watch bị rơi, component bỏ lỡ sự kiện cho vài giây, cho đến khi kết nối lại.

Scaling Control Plane Components

API Server Scaling

GKE tự động scaling instances API Server dựa trên:

Tỷ lệ yêu cầu
Kết nối đồng thời
etcd throughput

Bạn không thể thêm replicas API Server thủ công — Google quản lý.

Controller-Manager Scaling

Controllers chạy instance duy nhất hoạt động (các instance khác chờ). Không thể mở rộng ngang ngoài 1 hoạt động.

Cách khác cho controllers tùy chỉnh: Chạy control-plane riêng ngoài GKE (nhưng thiết lập cấp doanh nghiệp).

Scheduler Scaling

Tương tự instance duy nhất hoạt động. Bottleneck cho tỷ lệ scheduling là tài nguyên compute scheduler instance.

Giám Sát Control Plane Components

GKE công bố chỉ số qua Prometheus endpoint:

bash

# API server latency
kube_apiserver_request_duration_seconds

# Scheduler latency
scheduler_scheduling_attempt_duration_seconds
scheduler_e2e_scheduling_latency_seconds

# Controller-manager queue depth
workqueue_depth

# Cloud-controller-manager
cloudprovider_googleapis_com_calls_total

Bật control plane metrics:

bash

gcloud container clusters update my-cluster \
  --enable-cloud-logging \
  --logging-service logging.googleapis.com

Tham Khảo Tài Liệu

Thông tin kỹ thuật trong section này từ:

Tóm Tắt

API Server: Entry point cho tất cả Kubernetes operations, gateway cho etcd
Scheduler: Quyết định Pod → Node placement, chạy instance hoạt động duy nhất (replicas chờ)
Controller-Manager: Chạy vòng lặp hoà hợp cho Kubernetes resources (Deployments, StatefulSets, Services, v.v.)
Cloud-Controller-Manager: Reconcilers cụ thể GCP (LoadBalancer Services, cấp phát PV, sync Node)
Tất cả components giao tiếp qua etcd và watch API
GKE quản lý scaling, HA, cập nhật — không phải trách nhiệm khách hàng
Hiểu vai trò component giúp debug production issues hệ thống hơn

Kiến Trúc Control Plane Components — API Server, Scheduler, Controller-Manager, Cloud-Controller-Manager ​

Tại Sao Cần Hiểu Từng Component ​

High-Level Architecture ​

1. API Server — The Heart of Kubernetes ​

Role dan Responsibilities ​

Lifecycle ​

Configuration yang Bisa Tune (GKE Context) ​

Chế Độ Thất Bại Phổ Biến ​

Đặc Điểm Hiệu Năng ​

2. Scheduler — Pod Placement Decision Maker ​

Vai Trò và Trách Nhiệm ​

Bầu Chọn Lãnh Đạo ​

Hàng Đợi Scheduling ​

Chế Độ Thất Bại Phổ Biến ​

Xem Xét Production ​

3. Controller-Manager — Reconciliation Engine ​

Vai Trò và Trách Nhiệm ​

Controllers Tích Hợp (Danh Sách Một Phần) ​

Mẫu Vòng Lặp Hoà Hợp ​

Bầu Chọn Lãnh Đạo Cho Reconcilers ​

Chế Độ Thất Bại Phổ Biến ​

Xem Xét Production ​

4. Cloud-Controller-Manager — GCP-Specific Reconcilers ​

Vai Trò và Trách Nhiệm ​

Ví Dụ: Hoà Hợp Service LoadBalancer ​

Hành Vi Cụ Thể GKE ​

Leader Election ​

Chế Độ Thất Bại Phổ Biến ​

Inter-Component Communication ​

Dependency Chain ​

Cơ Chế Watch ​

Scaling Control Plane Components ​

API Server Scaling ​

Controller-Manager Scaling ​

Scheduler Scaling ​

Giám Sát Control Plane Components ​

Tham Khảo Tài Liệu ​

Tóm Tắt ​

Kiến Trúc Control Plane Components — API Server, Scheduler, Controller-Manager, Cloud-Controller-Manager

Tại Sao Cần Hiểu Từng Component

High-Level Architecture

1. API Server — The Heart of Kubernetes

Role dan Responsibilities

Lifecycle

Configuration yang Bisa Tune (GKE Context)

Chế Độ Thất Bại Phổ Biến

Đặc Điểm Hiệu Năng

2. Scheduler — Pod Placement Decision Maker

Vai Trò và Trách Nhiệm

Bầu Chọn Lãnh Đạo

Hàng Đợi Scheduling

Chế Độ Thất Bại Phổ Biến

Xem Xét Production

3. Controller-Manager — Reconciliation Engine

Vai Trò và Trách Nhiệm

Controllers Tích Hợp (Danh Sách Một Phần)

Mẫu Vòng Lặp Hoà Hợp

Bầu Chọn Lãnh Đạo Cho Reconcilers

Chế Độ Thất Bại Phổ Biến

Xem Xét Production

4. Cloud-Controller-Manager — GCP-Specific Reconcilers

Vai Trò và Trách Nhiệm

Ví Dụ: Hoà Hợp Service LoadBalancer

Hành Vi Cụ Thể GKE

Leader Election

Chế Độ Thất Bại Phổ Biến

Inter-Component Communication

Dependency Chain

Cơ Chế Watch

Scaling Control Plane Components

API Server Scaling

Controller-Manager Scaling

Scheduler Scaling

Giám Sát Control Plane Components

Tham Khảo Tài Liệu

Tóm Tắt