10.2. Design and Install a Kubernetes Cluster - High Availability and etcd

Mục lục

• 1. Vì sao cần High Availability
• 2. HA cho API server
• 3. HA cho scheduler và controller manager
• 4. etcd high availability
• 5. etcd topologies
• 6. Cài đặt etcd

---

1. Vì sao cần High Availability

Trước khi nói về HA, cần hiểu điều gì xảy ra khi cluster chỉ có một master node duy nhất và nó bị fail.

1.1. Điều gì xảy ra khi master node down?

Tình huống: cluster đang chạy ổn, master node đột nhiên không phản hồi.

Những gì vẫn hoạt động:

• Các containers đang chạy trên worker nodes vẫn tiếp tục chạy — chúng không phụ thuộc trực tiếp vào master.
• Người dùng vẫn truy cập ứng dụng được.

Những gì sẽ dừng hoạt động:

• Không thể scale: Muốn tạo thêm pod mới? Không được — scheduler không chạy.
• Không thể recover: Pod đang chạy crash? Replication controller không tạo pod thay thế.
• Không thể quản lý: kubectl không kết nối được — api-server không phản hồi.
• Không thể thay đổi gì mới: Bất kỳ thay đổi nào về configuration đều không được áp dụng.

💡 Hình dung: Cluster không có HA giống công ty chỉ có một giám đốc duy nhất. Giám đốc ốm nằm viện — nhân viên vẫn đi làm, nhưng không ai ký hợp đồng, không ai phê duyệt quyết định mới, không ai tuyển thêm người. Công ty sống từng ngày nhưng không phát triển được.

1.2. Giải pháp: HA configuration

HA configuration nghĩa là redundant cho mọi thành phần quan trọng — không có single point of failure, tức không còn thành phần nào mà chỉ cần nó chết là cả hệ thống chết theo.

1.3. Các thành phần cần HA

Component	HA Mode	Lý do
API Server	Active-Active	Nhiều instance có thể chạy song song
Scheduler	Active-Standby	Chỉ một instance active tại một thời điểm
Controller Manager	Active-Standby	Tránh duplicate actions
etcd	Distributed (Raft)	Consensus-based replication

---

2. HA cho API server

2.1. Active-Active mode

API server là stateless — nó không lưu trữ state, chỉ xử lý requests và ghi vào etcd. Vì vậy, tất cả API servers có thể chạy đồng thời ở chế độ active-active.

Vấn đề phát sinh: kubectl cần trỏ tới một endpoint duy nhất. Nếu có 3 master nodes, không thể configure kubectl trỏ tới cả 3.

Giải pháp: Đặt một load balancer trước các API servers. Load balancer là một thành phần đứng chắn phía trước nhiều server giống nhau: nó nhận request ở một địa chỉ duy nhất rồi chia đều sang các server phía sau, và tự loại server nào không còn khoẻ ra khỏi danh sách. Tài liệu chính thức yêu cầu load balancer này phải phân phối TCP traffic tới tất cả control plane node đang khoẻ, health-check bằng TCP trên port kube-apiserver (mặc định 6443), và địa chỉ của nó phải luôn khớp với ControlPlaneEndpoint mà kubeadm ghi nhận.

# kubectl trỏ tới load balancer
kubectl get pods --server=https://load-balancer:6443

# Load balancer phân phối request tới các API servers
# LB → Master 1:6443 (API Server)
#    → Master 2:6443 (API Server)
#    → Master 3:6443 (API Server)

# Kiểm tra cluster endpoint
kubectl cluster-info

# Output (minh họa):
# Kubernetes control plane is running at https://api-cluster.example.com:6443
# CoreDNS is running at https://api-cluster.example.com:6443/api/v1/...

💡 Hình dung: API servers giống các quầy thu ngân trong siêu thị — mỗi quầy độc lập, khách hàng có thể xếp hàng ở bất kỳ quầy nào. Load balancer là người hướng dẫn khách xếp hàng đều các quầy.

2.2. Các loại load balancer

Loại	Ví dụ	Dùng khi
Cloud LB	AWS ELB, GCP Cloud LB, Azure LB	Cluster trên cloud
Software LB	HAProxy, NGINX	On-premises, self-managed
Virtual IP trong cluster	kube-vip	Cả 2 môi trường

---

3. HA cho scheduler và controller manager

3.1. Tại sao không thể Active-Active

Khác với API server, Scheduler và Controller Manager có state — chúng theo dõi và ra quyết định về cluster state.

Ví dụ về Controller Manager:

Controller Manager chứa nhiều controllers, mỗi controller có nhiệm vụ theo dõi và duy trì desired state. Replication controller theo dõi số lượng replicas.

Nếu có 2 Replication Controllers active cùng lúc:

1. Controller A thấy cần tạo thêm pod.
2. Controller B cũng thấy cần tạo thêm pod.
3. Kết quả: 2 pods được tạo thay vì 1 → quá số lượng mong muốn.

💡 Hình dung: Hai người thợ xây cùng xây một bức tường — không ai báo nhau, tường xây to gấp đôi. Cần một người làm, người kia chờ — đó là Active-Standby.

3.2. Leader election — ai là active?

Kubernetes dùng leader election để quyết định instance nào là active.

Cơ chế hoạt động:

1. Khi scheduler/controller manager start với --leader-elect=true (default):

   • Process cố gắng acquire một Lease — một object khóa thuộc API group coordination.k8s.io, mang ý nghĩa "quyền làm leader, có hạn sử dụng".
   • Lease object nằm trong namespace kube-system, tên kube-scheduler hoặc kube-controller-manager.
   • Process nào acquire thành công trước → trở thành leader (active).
   • Process còn lại → follower (standby), không giữ lease mà liên tục thử acquire theo chu kỳ --leader-elect-retry-period (mặc định 2 giây).

2. Leader phải renew lease trước khi hết hạn --leader-elect-renew-deadline (mặc định 10 giây), nếu không nó tự dừng vai trò leader.

3. Khi leader fail:

   • Leader không renew lease.
   • Sau lease duration hết hạn (mặc định 15 giây).
   • Follower nào sớm nhất acquire được lease → trở thành leader mới.

3.3. Các option của leader election

# Các command-line options cho scheduler và controller manager
--leader-elect=true               # Bật leader election (default: true)
--leader-elect-lease-duration=15s # Thời gian một non-leader chờ trước khi giành quyền leader
--leader-elect-renew-deadline=10s # Hạn chót leader phải renew xong, nếu trễ thì thôi làm leader
--leader-elect-retry-period=2s    # Khoảng cách giữa các lần thử acquire/renew lease
--leader-elect-resource-lock=leases  # Loại resource lock (default: leases)

⚠️ Lưu ý: Giá trị mặc định và khuyến nghị của --leader-elect-resource-lock hiện là leases. Hai giá trị còn lại — endpointsleases và configmapsleases — chỉ còn giữ cho tương thích ngược; giá trị endpoints thuần (khoá trực tiếp trên Endpoints object) không còn được dùng nữa.

# Kiểm tra current leader
kubectl get lease kube-controller-manager -n kube-system -o yaml

# Output (minh họa):
# apiVersion: coordination.k8s.io/v1
# kind: Lease
# metadata:
#   name: kube-controller-manager
#   namespace: kube-system
# spec:
#   holderIdentity: master-1
#   leaseDurationSeconds: 15
#   renewTime: "2026-09-23T04:15:22.000000Z"

---

4. etcd High Availability

4.1. etcd là gì

etcd là distributed, reliable key-value store — nơi lưu trữ toàn bộ cluster state của Kubernetes.

Các đặc điểm chính, đúng theo cách chính dự án etcd tự mô tả:

• Simple: API rõ ràng, hướng tới người dùng, xây trên gRPC.
• Secure: TLS tự động, tuỳ chọn thêm xác thực bằng client certificate.
• Fast: Đã benchmark ở mức 10.000 writes/giây.
• Reliable: Phân tán đúng cách nhờ thuật toán đồng thuận Raft.

⚠️ Lưu ý: Giao diện HTTP/JSON là của etcd v2. Từ etcd v3, API chính thức là gRPC; truy cập kiểu HTTP/JSON chỉ còn qua lớp gRPC gateway.

Key-value store vs traditional database

Khía cạnh	Traditional DB	Key-Value Store (etcd)
Tổ chức data	Bảng, rows	Key-value pairs
Truy xuất	SQL queries	get/put/delete key
Ví dụ	PostgreSQL	etcd, Redis

# Ví dụ: etcd operations
# Lưu key-value
etcdctl put /config/redis-host "10.244.1.5"
# OK

# Đọc value
etcdctl get /config/redis-host
# /config/redis-host
# 10.244.1.5

4.2. etcd distributed system — Raft consensus

Khi có 3 etcd nodes, làm sao đảm bảo data nhất quán trên tất cả?

Vấn đề: write conflict

Nếu 2 write requests đến 2 nodes khác nhau cùng lúc:

• Node A nhận write: name="Alice".
• Node B nhận write: name="Bob".
• Kết quả không thể có 2 giá trị khác nhau trên 2 nodes.

Giải pháp: thuật toán đồng thuận Raft

Raft là thuật toán giúp một nhóm server cùng giữ một bản dữ liệu giống hệt nhau mà không cần ai đứng ngoài phân xử: nhóm bầu ra một leader, mọi thay đổi đều đi qua leader, và chỉ được tính là "xong" khi đa số thành viên đã ghi nhận.

Các bước xảy ra khi có write request:

1. Client gửi write tới bất kỳ etcd node nào.
2. Nếu gửi tới Leader: Leader xử lý trực tiếp.
3. Nếu gửi tới Follower: Follower forward tới Leader.
4. Leader replicate write tới các Followers.
5. Write chỉ complete khi Leader nhận acknowledgment từ quorum (majority).

Cơ chế Leader Election:

1. Cluster khởi động: tất cả nodes là candidates.
2. Nodes bắt đầu election timer (random).
3. Timer hết hạn trước → gửi vote request tới các nodes khác.
4. Node nhận votes từ majority → trở thành Leader.
5. Leader gửi heartbeat định kỳ tới Followers.
6. Nếu Follower không nhận heartbeat → initiate election mới.

4.3. Quorum — số node tối thiểu

Quorum là số thành viên tối thiểu phải cùng đồng ý thì một thao tác mới được tính là hợp lệ — nói cách khác là "đa số" của cụm. Công thức chính thức của etcd: quorum = (Total nodes / 2) + 1 (phép chia lấy phần nguyên).

Số Nodes	Quorum	Fault Tolerance	Khuyến nghị
1	1	0	Testing only
2	2	0	Không dùng
3	2	1	Tối thiểu cho HA
4	3	1	Không khuyến nghị
5	3	2	Tốt
6	4	2	Không khuyến nghị
7	4	3	Tốt cho mission-critical

💡 Fault Tolerance = Total - Quorum: Số nodes có thể fail mà cluster vẫn hoạt động.

Tại sao luôn dùng số LẺ nodes?

Vấn đề với số CHẴN: network partition — tình huống đường mạng giữa các node bị đứt, cụm bị chia thành hai (hoặc nhiều) nhóm vẫn sống nhưng không nói chuyện được với nhau.

Giả sử 6-node cluster bị partition:

• Scenario 1: 4 nodes một bên, 2 nodes một bên.

  • Nhóm 4 nodes → có quorum (4) → tiếp tục hoạt động.
  • Nhóm 2 nodes → không quorum → không hoạt động.

• Scenario 2: 3-3 partition.

  • Quorum cần 4 nodes.
  • Không nhóm nào đạt quorum → cluster FAIL hoàn toàn!

Với số LẺ (5 nodes):

• Partition 3-2: nhóm 3 đạt quorum → cluster sống sót!

Đây chính là lý do etcd khuyến nghị số lẻ: một cụm số lẻ chịu được đúng bằng số lỗi mà cụm số chẵn kế tiếp chịu được, nhưng dùng ít node hơn — thêm 1 node vào cụm lẻ chỉ làm tăng ngưỡng quorum chứ không tăng khả năng chịu lỗi. Với số lẻ, một network partition luôn để lại đúng một nhóm đa số có thể tiếp tục làm nguồn sự thật.

💡 Kết luận: 5 nodes luôn tốt hơn 6 nodes. 3 nodes là đủ cho hầu hết production setups, còn tài liệu Kubernetes khuyến nghị cụm 5 thành viên cho production. Không cần 7 nodes trừ khi cần fault tolerance = 3.

---

5. etcd topologies

Đặt etcd ở đâu trong cluster? Kubernetes cho hai lựa chọn, và chúng đánh đổi giữa số lượng máy phải nuôi và mức độ rủi ro khi một máy chết.

5.1. Stacked (embedded) topology

Stacked etcd nghĩa là mỗi control plane node tự chạy một etcd member ngay trên chính nó, và member đó chỉ nói chuyện với kube-apiserver cùng node — hai vai trò xếp chồng lên nhau trên một máy.

Đặc điểm:

• etcd chạy trên cùng node với control plane.
• Dễ setup, ít servers hơn, và quản lý replication cũng đơn giản hơn.
• Phù hợp cho small-to-medium clusters.

Rủi ro:

• Nếu node fail: mất cả control plane lẫn etcd member cùng một lúc — tài liệu chính thức gọi đây là rủi ro "failed coupling" (hỏng dây chuyền).
• Chính vì vậy, một cluster HA theo kiểu stacked cần tối thiểu 3 control plane node.
• 3 nodes down → cluster mất quorum → không hoạt động.

# kubeadm init với stacked etcd (default)
sudo kubeadm init --control-plane-endpoint "load-balancer:6443" --upload-certs
# etcd pods được tạo tự động trên master nodes
kubectl get pods -n kube-system | grep etcd

# Output (minh họa):
# etcd-master-1   1/1   Running   0   2d
# etcd-master-2   1/1   Running   0   2d
# etcd-master-3   1/1   Running   0   2d

Hai flag trong lệnh trên đáng được giải thích rõ. --control-plane-endpoint là control plane endpoint — địa chỉ ổn định (thường là DNS name của load balancer) mà mọi node và mọi kubectl sẽ dùng để nói chuyện với control plane, thay vì gõ thẳng IP của một master cụ thể; đặt nó ngay từ lệnh init là điều kiện để về sau có thể thêm control plane node mà không phải dựng lại cluster. --upload-certs thì đẩy bộ certificate của control plane lên một Secret trong cluster, được mã hoá bằng một certificate key dài 32 byte — chuỗi khoá này chính là thứ mà control plane node mới dùng để tải và giải mã bộ certificate đó khi join, qua kubeadm join ... --control-plane --certificate-key <key>.

⚠️ Lưu ý: Secret chứa certificate đã upload sẽ tự hết hạn và bị xoá sau 2 giờ. Quá thời hạn đó, phải chạy lại kubeadm init phase upload-certs --upload-certs để sinh certificate key mới trước khi join thêm control plane node.

5.2. External etcd topology

External etcd thì ngược lại: các etcd member chạy trên những host tách hẳn khỏi control plane, và mỗi etcd host phục vụ kube-apiserver của mọi control plane node — hai tầng được tách đôi (decouple) thay vì xếp chồng.

Đặc điểm:

• etcd chạy trên dedicated nodes riêng.
• An toàn hơn: mất một control plane node không đồng thời mất một etcd member.
• Phù hợp cho large, mission-critical clusters.

Nhược điểm:

• Cần gấp đôi số host so với stacked — tối thiểu 3 host cho control plane và 3 host cho etcd.
• Phức tạp hơn trong setup và management.

5.3. So sánh hai topology

Tiêu chí	Stacked	External
Số servers	Ít hơn (tối thiểu 3)	Nhiều hơn (tối thiểu 3 + 3)
Độ phức tạp	Thấp	Cao
Rủi ro khi node fail	Cao (mất cả 2 thứ)	Thấp (etcd riêng)
Phù hợp	Cluster nhỏ và vừa, ưu tiên ít hạ tầng	Cluster lớn, mission-critical, cần tách rủi ro
Recommended cho	Most clusters	Large production

5.4. Giao tiếp giữa API server và etcd

⚠️ Lưu ý quan trọng: API server là component DUY NHẤT nói chuyện trực tiếp với etcd.

Tất cả components khác (scheduler, controller manager) giao tiếp với etcd gián tiếp qua API server.

# API server configuration — chỉ định etcd servers
kube-apiserver \
  --etcd-servers=https://192.168.1.1:2379,https://192.168.1.2:2379,https://192.168.1.3:2379 \
  --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt \
  --etcd-certfile=/etc/kubernetes/pki/etcd/server.crt \
  --etcd-keyfile=/etc/kubernetes/pki/etcd/server.key

etcd cluster có thể đọc/ghi từ bất kỳ instance nào — client (API server) không cần biết leader ở đâu, vì follower sẽ forward requests tới leader.

---

6. Cài đặt etcd

Với topology external, etcd không còn được kubeadm dựng hộ — phải tự cài. Phần này đi qua đúng các bước đó.

6.1. Các bước cài đặt

Bước 1: Download etcd binary

# Download etcd từ GitHub releases
ETCD_VERSION="v3.6.15"
curl -L https://github.com/etcd-io/etcd/releases/download/${ETCD_VERSION}/etcd-${ETCD_VERSION}-linux-amd64.tar.gz -o /tmp/etcd.tar.gz

# Extract
tar xzf /tmp/etcd.tar.gz -C /tmp

Bước 2: Install binary

# Copy binaries to system path
sudo cp /tmp/etcd-${ETCD_VERSION}-linux-amd64/etcd /usr/local/bin/
sudo cp /tmp/etcd-${ETCD_VERSION}-linux-amd64/etcdctl /usr/local/bin/

# Verify installation
etcd --version
# Output (minh họa):
# etcd Version: 3.6.15
# Git SHA: ...
# Go Version: go1.24.x

⚠️ Lưu ý về version: Nhánh etcd 3.6 là nhánh Kubernetes v1.34 trở lên đóng gói sẵn (các bản Kubernetes thấp hơn dùng nhánh 3.5); nhánh mới nhất hiện tại là 3.7. Khi nâng cấp, etcd chỉ hỗ trợ đi từng minor version một (3.5 → 3.6 → 3.7, không nhảy cóc), và trước khi lên 3.6 thì toàn bộ member 3.5 phải đã ở bản 3.5.26 trở lên. Từ 3.6, flag --enable-v2 cùng toàn bộ nhóm flag proxy (--proxy, --proxy-failure-wait, …) đã bị gỡ bỏ — v2store không còn bật được nữa.

Bước 3: Create directory structure

sudo mkdir -p /var/lib/etcd
sudo mkdir -p /etc/etcd
sudo mkdir -p /etc/kubernetes/pki/etcd

Bước 4: Copy certificates

sudo cp ca.crt /etc/kubernetes/pki/etcd/
sudo cp server.crt /etc/kubernetes/pki/etcd/
sudo cp server.key /etc/kubernetes/pki/etcd/

6.2. Cấu hình etcd service

Option quan trọng nhất: --initial-cluster

Đây là nơi khai báo tất cả etcd members trong cluster.

# Ví dụ: etcd service trên node 1
etcd --name=etcd-1 \
  --cert-file=/etc/kubernetes/pki/etcd/server.crt \
  --key-file=/etc/kubernetes/pki/etcd/server.key \
  --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt \
  --client-cert-auth=true \
  --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt \
  --peer-key-file=/etc/kubernetes/pki/etcd/peer.key \
  --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt \
  --peer-client-cert-auth=true \
  --initial-cluster=etcd-1=https://192.168.1.1:2380,etcd-2=https://192.168.1.2:2380,etcd-3=https://192.168.1.3:2380 \
  --initial-cluster-state=new \
  --initial-advertise-peer-urls=https://192.168.1.1:2380 \
  --advertise-client-urls=https://192.168.1.1:2379 \
  --listen-client-urls=https://0.0.0.0:2379 \
  --listen-peer-urls=https://0.0.0.0:2380

Giải thích các options quan trọng:

Option	Ý nghĩa
--name	Tên instance, phải khớp với trong initial-cluster
--initial-cluster	Danh sách tất cả members: name=url,name=url,...
--initial-cluster-state	new (lần đầu) hoặc existing (join cluster có sẵn)
--initial-advertise-peer-urls	URL để peers kết nối tới node này
--advertise-client-urls	URL để clients (API server) kết nối tới node này

6.3. Sử dụng etcdctl

etcdctl là CLI tool để tương tác với etcd.

# Set environment variables cho certificates
export ETCDCTL_CACERT=/etc/kubernetes/pki/etcd/ca.crt
export ETCDCTL_CERT=/etc/kubernetes/pki/etcd/server.crt
export ETCDCTL_KEY=/etc/kubernetes/pki/etcd/server.key
export ETCDCTL_ENDPOINTS=https://127.0.0.1:2379

# Lưu data — gán key với value
etcdctl put /registry/services/specs/myapp '{"Name":"myapp","port":8080}'

# Output:
# OK

# Đọc data
etcdctl get /registry/services/specs/myapp

# Output:
# /registry/services/specs/myapp
# {"Name":"myapp","port":8080}

# Đọc tất cả keys có prefix
etcdctl get /registry/services/specs/ --prefix

# Xóa key
etcdctl del /registry/services/specs/myapp

# Output:
# 1

# Kiểm tra cluster health
etcdctl endpoint health

# Output (minh họa):
# https://192.168.1.1:2379 is healthy: successfully committed proposal: took = 1.234ms
# https://192.168.1.2:2379 is healthy: successfully committed proposal: took = 2.345ms
# https://192.168.1.3:2379 is healthy: successfully committed proposal: took = 1.567ms

# Xem cluster status
etcdctl endpoint status

# Output (minh họa):
# +----+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
# | ID |     ENDPOINT     | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
# +----+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
# | xx | 192.168.1.1:2379 | 3.6.15  |  20 kB  |      true |      false |        10 |       1234 |               1234 |        |
# | xx | 192.168.1.2:2379 | 3.6.15  |  20 kB  |     false |      false |        10 |       1234 |               1234 |        |
# | xx | 192.168.1.3:2379 | 3.6.15  |  20 kB  |     false |      false |        10 |       1234 |               1234 |        |
# +----+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

---

Nguồn tham khảo

Nguồn gốc: Khóa "Certified Kubernetes Administrator (CKA)" — phần "Design and Install a Kubernetes Cluster" (Vì sao cần High Availability; HA cho API server; HA cho scheduler và controller manager qua leader election; etcd high availability và Raft consensus; Quorum và fault tolerance; etcd topologies: stacked và external; Cài đặt và cấu hình etcd, etcdctl), nền tảng KodeKloud. Giảng viên: Mumshad Mannambeth.

Repo ghi chú, link tài liệu, và đáp án các practice question của toàn bộ khóa học: kodekloudhub/certified-kubernetes-administrator-course.

Fact-check:

• Công thức quorum của etcd là (n/2)+1; bảng fault tolerance chính thức: 3 node → quorum 2, chịu được 1 lỗi; 5 node → quorum 3, chịu được 2 lỗi; 7 node → quorum 4, chịu được 3 lỗi — một cụm số lẻ chịu được đúng bằng số lỗi mà cụm số chẵn kế tiếp chịu được nhưng dùng ít node hơn — 2026-09-23, etcd — Frequently Asked Questions
• Kubernetes khuyến nghị chạy etcd với số thành viên lẻ, và khuyến nghị cụm 5 thành viên cho production ở mọi quy mô được hỗ trợ chính thức — 2026-09-23, Kubernetes Docs — Operating etcd clusters for Kubernetes
• Topology stacked etcd: mỗi control plane node chạy một etcd member chỉ nói chuyện với kube-apiserver cùng node; rủi ro "failed coupling" khi mất node làm mất cả hai; cần tối thiểu 3 stacked control plane node cho cluster HA. Topology external etcd tách đôi control plane và etcd, cần gấp đôi số host — tối thiểu 3 host control plane và 3 host etcd — 2026-09-23, Kubernetes Docs — Options for Highly Available Topology
• Load balancer trước kube-apiserver phải phân phối TCP traffic tới tất cả control plane node đang khoẻ, health-check TCP trên port kube-apiserver (mặc định 6443), và địa chỉ của nó phải luôn khớp với ControlPlaneEndpoint của kubeadm — 2026-09-23, Kubernetes Docs — Creating Highly Available Clusters with kubeadm
• kubeadm init --control-plane-endpoint ... --upload-certs đẩy certificate control plane lên một Secret, mã hoá bằng certificate key 32 byte; control plane node mới join bằng kubeadm join ... --control-plane --certificate-key <key>. Secret và khoá giải mã này tự hết hạn sau 2 giờ, sau đó phải chạy lại kubeadm init phase upload-certs --upload-certs — 2026-09-23, Kubernetes Docs — kubeadm init
• Giá trị mặc định của --leader-elect-resource-lock trên kube-controller-manager và kube-scheduler là leases; các giá trị còn được chấp nhận là endpointsleases và configmapsleases. Mặc định các tham số còn lại: --leader-elect=true, --leader-elect-lease-duration=15s, --leader-elect-renew-deadline=10s, --leader-elect-retry-period=2s — 2026-09-23, Kubernetes Docs — kube-controller-manager
• Leader election giữa các instance kube-controller-manager / kube-scheduler dùng Lease object của API group coordination.k8s.io, không còn dùng annotation trên Endpoints object — 2026-09-23, Kubernetes Docs — Leases
• etcd tự mô tả bốn đặc điểm: Simple (API hướng người dùng, định nghĩa rõ ràng, trên gRPC), Secure (TLS tự động, tuỳ chọn xác thực client certificate), Fast (benchmark 10.000 writes/giây), Reliable (phân tán bằng Raft) — 2026-09-23, etcd-io/etcd — README
• etcd v3.6.0 gỡ bỏ flag --enable-v2 (v2store không còn bật được) cùng toàn bộ nhóm flag proxy --proxy, --proxy-failure-wait, --proxy-refresh-interval, --proxy-dial-timeout, --proxy-write-timeout, --proxy-read-timeout — 2026-09-23, Kubernetes Blog — Announcing etcd v3.6.0
• etcd chỉ hỗ trợ nâng cấp từng minor version một; trước khi lên v3.6 thì mọi member v3.5 phải ở bản v3.5.26 trở lên — 2026-09-23, etcd — Upgrade etcd from v3.5 to v3.6
• Nhánh etcd mới nhất hiện tại là v3.7 (v3.7.0 ra mắt 08/07/2026), song song với các nhánh bảo trì v3.6 và v3.5 — 2026-09-23, Kubernetes Blog — Announcing etcd v3.7.0