[Part 7] Truy cập Cluster, Networking và Kiểm thử trong series xây dựng Kubernetes Cluster

Sau khi hoàn tất việc khởi tạo control plane và worker node ở các phần trước, Kubernetes cluster lúc này đã có đầy đủ các thành phần cần thiết để vận hành. Tuy nhiên, trước khi có thể xem cluster là “hoạt động hoàn chỉnh”, vẫn cần xác nhận thêm nhiều yếu tố quan trọng như:

• Khả năng truy cập cluster từ bên ngoài
• Kết nối networking giữa các node và Pod
• Cơ chế mã hóa dữ liệu
• Khả năng triển khai workload
• Hoạt động của các tính năng runtime như logs, exec và port-forward

Trong phần cuối cùng của series này, chúng ta sẽ thực hiện kiểm tra toàn bộ cluster từ góc nhìn vận hành thực tế, đồng thời xác minh rằng các thành phần đã được triển khai ở những phần trước đang hoạt động chính xác cùng nhau.

Cấu hình kubectl

Để quản lý Kubernetes cluster từ máy local hoặc jumpbox, cần cấu hình công cụ dòng lệnh kubectl.

Mỗi Kubernetes cluster sẽ sử dụng một file kubeconfig để lưu thông tin:

• Cluster endpoint
• Certificate xác thực
• User và context truy cập

Kiểm tra khả năng truy cập Kubernetes API Server

Trước tiên, xác minh Kubernetes API Server đang hoạt động:

curl --cacert ca.crt \

  https://server.kubernetes.local:6443/version

Kết quả ví dụ: 

 "major": "1",

  "minor": "32",

  "gitVersion": "v1.32.3",

  "gitCommit": "32cc146f75aad04beaaa245a7157eb35063a9f99",

  "gitTreeState": "clean",

  "buildDate": "2025-03-11T19:52:21Z",

  "goVersion": "go1.23.6",

  "compiler": "gc",

  "platform": "linux/arm64"

Nếu API Server phản hồi thành công, control plane đã sẵn sàng tiếp nhận request từ client. 

Tạo kubeconfig cho kubectl

Tạo file cấu hình kubeconfig cho user admin:

  kubectl config set-cluster kubernetes-the-hard-way \

    --certificate-authority=ca.pem \

    --embed-certs=true \

    --server=https://${KUBERNETES_PUBLIC_ADDRESS}:6443



  kubectl config set-credentials admin \

    --client-certificate=admin.pem \

    --client-key=admin-key.pem \

    --embed-certs=true



  kubectl config set-context kubernetes-the-hard-way \

    --cluster=kubernetes-the-hard-way \

    --user=admin



  kubectl config use-context kubernetes-the-hard-way

Xác minh kết nối cluster

Kiểm tra xem cluster có phản hồi hay không bằng cách truy cập phiên bản phần mềm của Kubernetes:

kubectl version

Kết quả mong đợi:

Client Version: v1.28.3

Kustomize Version: v5.0.4-0.20230601165947-6ce0e2390928

Server Version: v1.28.3

Kiểm tra trạng thái của các node trong cluster:

kubectl get nodes

Kết quả mong đợi

NAME     STATUS   ROLES    AGE    VERSION

node-0   Ready    <none>   6m4s   v1.28.3

node-1   Ready    <none>   6m4s   v1.28.3

Thiết lập Networking giữa các Pod

Tại thời điểm này, Pod trên mỗi node đã có thể được cấp IP từ Pod CIDR tương ứng. Tuy nhiên, các Pod giữa các node vẫn chưa thể giao tiếp với nhau do chưa có routing phù hợp.

Trong bài lab này, networking sẽ được cấu hình thủ công thông qua Linux routing table để giúp các node biết cách forward traffic tới Pod CIDR của nhau.

Lưu ý: Có nhiều cách khác để triển khai mô hình mạng Kubernetes (như sử dụng CNI plugins chuyên dụng như Calico, Cilium, v.v.), nhưng ở đây chúng ta sẽ thực hiện thủ công qua bảng định tuyến.

Thu thập thông tin mạng

Lấy thông tin IP và Pod CIDR của từng node:

SERVER_IP=$(grep server machines.txt | cut -d " " -f 1) NODE_0_IP=$(grep node-0 machines.txt | cut -d " " -f 1) NODE_0_SUBNET=$(grep node-0 machines.txt | cut -d " " -f 4) NODE_1_IP=$(grep node-1 machines.txt | cut -d " " -f 1) NODE_1_SUBNET=$(grep node-1 machines.txt | cut -d " " -f 4) 

Cấu hình route giữa các node

Trên server

ssh root@server <<EOF

  ip route add ${NODE_0_SUBNET} via ${NODE_0_IP}

  ip route add ${NODE_1_SUBNET} via ${NODE_1_IP}

EOF

ssh root@node-0 <<EOF

  ip route add ${NODE_1_SUBNET} via ${NODE_1_IP}

EOF

ssh root@node-1 <<EOF

  ip route add ${NODE_0_SUBNET} via ${NODE_0_IP}

EOF

Kiểm tra routing table

Kiểm tra bảng định tuyến trên từng máy để đảm bảo các tuyến đường đã được thêm chính xác.

Trên máy server

ssh root@server ip route

Kết quả mong đợi (ví dụ):

default via XXX.XXX.XXX.XXX dev ens160 

10.200.0.0/24 via XXX.XXX.XXX.XXX dev ens160 

10.200.1.0/24 via XXX.XXX.XXX.XXX dev ens160 

XXX.XXX.XXX.0/24 dev ens160 proto kernel scope link src XXX.XXX.XXX.XXX

Trên node-0:

ssh root@node-0 ip route

Kết quả mong đợi (ví dụ):

default via XXX.XXX.XXX.XXX dev ens160 

10.200.1.0/24 via XXX.XXX.XXX.XXX dev ens160 

XXX.XXX.XXX.0/24 dev ens160 proto kernel scope link src XXX.XXX.XXX.XXX 

Trên node-1:

ssh root@node-1 ip route

Kết quả mong đợi (ví dụ):

Plaintext

default via XXX.XXX.XXX.XXX dev ens160 

10.200.0.0/24 via XXX.XXX.XXX.XXX dev ens160 

XXX.XXX.XXX.0/24 dev ens160 proto kernel scope link src XXX.XXX.XXX.XXX 

Nếu các route đã xuất hiện đúng Pod CIDR tương ứng, networking cơ bản giữa các node đã được thiết lập thành công. 

Kiểm tra Kubernetes Cluster

Sau khi hoàn tất networking, bước tiếp theo là xác minh khả năng vận hành thực tế của cluster.

Kiểm tra mã hóa dữ liệu trong etcd

Tạo một Kubernetes Secret:

kubectl create secret generic kubernetes-the-hard-way \

  --from-literal="mykey=mydata"

Kiểm tra dữ liệu được lưu trong etcd 

ssh root@server \

    'etcdctl get /registry/secrets/default/kubernetes-the-hard-way | hexdump -C'

00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|

00000010  73 2f 64 65 66 61 75 6c  74 2f 6b 75 62 65 72 6e  |s/default/kubern|

00000020  65 74 65 73 2d 74 68 65  2d 68 61 72 64 2d 77 61  |etes-the-hard-wa|

00000030  79 0a 6b 38 73 3a 65 6e  63 3a 61 65 73 63 62 63  |y.k8s:enc:aescbc|

00000040  3a 76 31 3a 6b 65 79 31  3a 4f 1b 80 d8 89 72 f4  |:v1:key1:O....r.|

00000050  60 8a 2c a0 76 1a e1 dc  98 d6 00 7a a4 2f f3 92  |`.,.v......z./..|

00000060  87 63 c9 22 f4 58 c8 27  b9 ff 2c 2e 1a b6 55 be  |.c.".X.'..,...U.|

00000070  d5 5c 4d 69 82 2f b7 e4  b3 b0 12 e1 58 c4 9c 77  |.\Mi./......X..w|

00000080  78 0c 1a 90 c9 c1 23 6c  73 8e 6e fd 8e 9c 3d 84  |x.....#ls.n...=.|

00000090  7d bf 69 81 ce c9 aa 38  be 3b dd 66 aa a3 33 27  |}.i....8.;.f..3'|

000000a0  df be 6d ac 1c 6d 8a 82  df b3 19 da 0f 93 94 1e  |..m..m..........|

000000b0  e0 7d 46 8d b5 14 d0 c5  97 e2 94 76 26 a8 cb 33  |.}F........v&..3|

000000c0  57 2a d0 27 a6 5a e1 76  a7 3f f0 b7 0a 7b ff 53  |W*.'.Z.v.?...{.S|

000000d0  cf c9 1a 18 5b 45 f8 b1  06 3b a9 45 02 76 23 61  |....[E...;.E.v#a|

000000e0  5e dc 86 cf 8e a4 d3 c9  5c 6a 6f e6 33 7b 5b 8f  |^.......\jo.3{[.|

000000f0  fb 8a 14 74 58 f9 49 2f  97 98 cc 5c d4 4a 10 1a  |...tX.I/...\.J..|

00000100  64 0a 79 21 68 a0 9e 7a  03 b7 19 e6 20 e4 1b ce  |d.y!h..z.... ...|

00000110  91 64 ce 90 d9 4f 86 ca  fb 45 2f d6 56 93 68 e1  |.d...O...E/.V.h.|

00000120  0b aa 8c a0 20 a6 97 fa  a1 de 07 6d 5b 4c 02 96  |.... ......m[L..|

00000130  31 70 20 83 16 f9 0a 22  5c 63 ad f1 ea 41 a7 1e  |1p ...."\c...A..|

00000140  29 1a d4 a4 e9 d7 0c 04  74 66 04 6d 73 d8 2e 3f  |).......tf.ms..?|

00000150  f0 b9 2f 77 bd 07 d7 7c  42 0a                    |../w...|B.|

0000015a

Kết quả mong đợi:

Kết quả mong đợi sẽ chứa prefix: k8s:enc:aescbc:v1:key1

Điều này cho thấy Secret đã được mã hóa trước khi lưu xuống etcd thay vì lưu dưới dạng plaintext.

Deploy workload đầu tiên

Để xác nhận cluster đã hoạt động đầy đủ sau quá trình bootstrap, bước tiếp theo sẽ triển khai một workload mẫu lên Kubernetes.

Tạo một Deployment sử dụng image nginx:

kubectl create deployment nginx --image=nginx:latest

Kiểm tra Pod được tạo:

kubectl get pods -l app=nginx

Kết quả mong đợi:

NAME                     READY   STATUS    RESTARTS   AGE

nginx-76d6c9b8c-6sq9w    1/1     Running   0          55s

Nếu Pod ở trạng thái Running, điều đó cho thấy scheduler, kubelet, container runtime và networking đã phối hợp hoạt động đúng trong cluster. 

Kiểm tra Port Forwarding

Tiếp theo, kiểm tra khả năng truy cập ứng dụng thông qua cơ chế port forwarding của Kubernetes.

Lấy tên Pod nginx:

POD_NAME=$(kubectl get pods -l app=nginx -o jsonpath="{.items[0].metadata.name}")

Thiết lập port forwarding từ máy local tới Pod: 

kubectl port-forward $POD_NAME 8080:80

Kết quả mong đợi:

Forwarding from 127.0.0.1:8080 -> 80

Forwarding from [::1]:8080 -> 80

Mở một terminal mới và thực hiện yêu cầu HTTP bằng curl:

curl --head http://127.0.0.1:8080

Kết quả mong đợi:

HTTP/1.1 200 OK

Server: nginx/1.27.4

Date: Sun, 06 Apr 2025 17:17:12 GMT

Content-Type: text/html

Content-Length: 615

Last-Modified: Wed, 05 Feb 2025 11:06:32 GMT

Connection: keep-alive

ETag: "67a34638-267"

Accept-Ranges: bytes

Kết quả trên xác nhận API Server đã có thể giao tiếp với Pod thông qua kubelet và cơ chế port forwarding.

Sau khi hoàn tất kiểm tra, nhấn Ctrl + C để dừng phiên port forwarding.

Kiểm tra Logs

Kiểm tra khả năng truy xuất log container từ Kubernetes API:

kubectl logs $POD_NAME

Kết quả mong đợi:

...

127.0.0.1 - - [13/Oct/2023:00:00:00 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.88.1" "-"

Điều này cho thấy kubelet đã hoạt động đúng và API Server có thể truy xuất log từ container runtime trên worker node. 

Kiểm tra Exec

Kiểm tra khả năng thực thi lệnh trực tiếp bên trong container:

kubectl exec -ti $POD_NAME -- nginx -v

Kết quả mong đợi:

nginx version: nginx/1.25.3

Tính năng kubectl exec được sử dụng phổ biến trong quá trình troubleshooting và vận hành thực tế của Kubernetes. 

Kiểm tra Services

Tiếp theo, kiểm tra khả năng expose ứng dụng thông qua Kubernetes Service.

Expose Deployment nginx bằng Service kiểu NodePort:

kubectl expose deployment nginx --port 80 --type NodePort

Lấy NodePort được Kubernetes cấp phát::

NODE_PORT=$(kubectl get svc nginx \

  --output=jsonpath='{range .spec.ports[0]}{.nodePort}{"\n"}{end}')

Lấy tên máy chủ của node đang chạy pod nginx:

NODE_NAME=$(kubectl get pods \

  -l app=nginx \

  -o jsonpath="{.items[0].spec.nodeName}")

Thực hiện gọi 1 HTTP request đến địa chỉ IP của node worker và NodePort:

curl -I http://${NODE_IP}:${NODE_PORT} 

Kết quả mong đợi:

HTTP/1.1 200 OK

Server: nginx/1.27.4

Date: Thu, 27 Feb 2025 15:57:46 GMT

Content-Type: text/html

Content-Length: 615

Last-Modified: Tue, 11 Feb 2025 14:15:33 GMT

Connection: keep-alive

ETag: "67ab6105-267"

Accept-Ranges: bytes

Nếu nhận được HTTP response thành công, điều đó cho thấy kube-proxy, iptables và networking giữa các node đã hoạt động chính xác. 

Kết luận

Đến thời điểm này, Kubernetes cluster đã được xây dựng hoàn chỉnh từ những thành phần nền tảng nhất: networking, PKI, TLS, etcd, control plane, worker node và workload runtime.

Toàn bộ quá trình được triển khai thủ công mà không sử dụng kubeadm hay các công cụ tự động hóa. Điều đó giúp làm rõ cách Kubernetes thực sự vận hành phía sau những abstraction quen thuộc mà chúng ta thường sử dụng mỗi ngày.

Ở phần mở đầu của series, chúng ta bắt đầu từ một tình huống rất quen thuộc trong thực tế: một node đột nhiên mất trạng thái Ready, Pod bị reschedule, service phản hồi bất thường và hàng loạt cảnh báo xuất hiện trên hệ thống monitoring.

Khi đó, những câu hỏi quan trọng nhất thường không nằm ở câu lệnh kubectl nào cần chạy tiếp theo, mà nằm ở việc:

• Điều gì đang xảy ra bên trong cluster?
• Thành phần nào đang phản ứng với sự cố?
• Kubernetes dựa vào cơ chế nào để đưa cluster quay trở lại trạng thái mong muốn?

Series này được xây dựng để trả lời chính những câu hỏi đó.

Thông qua việc tự tay bootstrap từng thành phần của cluster, chúng ta đã lần lượt đi qua:

• cách kubelet xác thực với API Server bằng TLS certificate
• cách etcd lưu trữ trạng thái của toàn bộ hệ thống
• cách Controller Manager liên tục reconcile trạng thái cluster
• cách Scheduler lựa chọn node cho Pod
• cách kube-proxy và networking kết nối workload giữa các node
• cách Kubernetes duy trì một hệ thống phân tán hoạt động ổn định phía sau các API quen thuộc

Mục tiêu của “the hard way” không phải để triển khai Kubernetes theo cách thủ công trong production, mà để hiểu rõ những gì các công cụ automation đang thực hiện phía sau.

Khi đã hiểu được nền tảng này, việc tiếp cận các hệ thống Kubernetes managed service, các distribution như RKE2, K3s, OpenShift hay các nền tảng cloud Kubernetes sẽ trở nên rõ ràng hơn rất nhiều. Bởi dù giao diện triển khai có khác nhau, các thành phần cốt lõi phía dưới vẫn hoạt động dựa trên cùng những nguyên lý cơ bản.

Quan trọng hơn, việc troubleshooting Kubernetes cũng sẽ thay đổi theo hướng chủ động hơn. Thay vì chỉ nhìn thấy “Pod bị lỗi”, chúng ta có thể lần ngược về scheduler, kubelet, networking, certificate, etcd hoặc control plane để xác định đúng bản chất vấn đề.

Và đó cũng là giá trị lớn nhất của việc xây dựng Kubernetes từ con số 0: Không chỉ để có một cluster hoạt động, mà để hiểu được cách toàn bộ hệ thống phối hợp với nhau phía sau một dòng lệnh kubectl apply.

Xem lại: [Part 6] Khởi tạo các node Worker trong chuỗi series xây dựng Kubernetes Cluster