Khởi tạo Control-Plane và Worker Nodes với Kubeadm
Thực hiện lệnh khởi tạo cluster trên node đóng vai trò Master (Control-Plane). Lệnh này sẽ cài đặt các component lõi: API Server, Controller Manager, Scheduler và kubelet.
Tại sao: Đây là bước nền tảng để thiết lập bộ não của cluster Kubernetes, quản lý trạng thái và phân phối workload.
Kết quả mong đợi: Cluster được khởi tạo, token join được sinh ra, và các thành phần core chạy sẵn sàng.
kubeadm init --pod-network-cidr=192.168.0.0/16 --apiserver-advertise-address=10.0.2.10 --node-name control-plane
Sau khi lệnh chạy xong, cấu hình kubeconfig cho người dùng hiện tại để có thể truy cập cluster bằng lệnh kubectl.
Tại sao: File ~/.kube/config chứa thông tin xác thực và endpoint API, cần thiết để kubectl giao tiếp với cluster.
Kết quả mong đợi: File ~/.kube/config được tạo ra, bạn có thể chạy kubectl get nodes.
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Trên các node Worker, chạy lệnh join để tham gia vào cluster. Thay thế YOUR_CONTROL_PLANE_IP và YOUR_TOKEN bằng giá trị thực từ output của lệnh kubeadm init ở trên.
Tại sao: Worker nodes cần đăng ký với API Server để nhận lệnh phân phối pod và báo cáo trạng thái.
Kết quả mong đợi: Node worker chuyển trạng thái từ NotReady sang Ready sau khi kết nối thành công.
kubeadm join 10.0.2.10:6443 --token \
--discovery-token-ca-cert-hash sha256: \
--node-name worker-node-1
Verify kết quả khởi tạo
Chạy lệnh sau trên Control-Plane để kiểm tra trạng thái của tất cả nodes.
kubectl get nodes
Bạn sẽ thấy danh sách các node với trạng thái Ready (có thể chưa có label NotReady do chưa cài CNI).
Cấu hình CNI với Calico cho Networking
Áp dụng manifest Calico từ official repository để thiết lập mạng container. Calico sẽ tự động cài đặt kube-proxy và tạo các network interface cho pod.
Tại sao: Kubernetes mặc định không có CNI, pod không thể giao tiếp với nhau (Pod-to-Pod) nếu không có plugin mạng. Calico được chọn vì hiệu năng cao và hỗ trợ tốt IPv4/IPv6.
Kết quả mong đợi: Các pod hệ thống trong namespace kube-system của Calico (calico-node, calico-kube-controllers) chuyển sang trạng thái Running.
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yaml
Chờ khoảng 1-2 phút để các pod của Calico khởi động và thiết lập route table trên các node.
Tại sao: Cần thời gian để agent Calico trên mỗi node trao đổi thông tin BGP hoặc IPIP và xây dựng topology mạng.
Kết quả mong đợi: Trạng thái node chuyển từ NotReady sang Ready hoàn toàn.
Verify kết quả CNI
Chạy lệnh kiểm tra lại trạng thái nodes và pods trong namespace kube-system.
kubectl get nodes
kubectl get pods -n kube-system -o wide
Tất cả nodes phải có trạng thái Ready. Các pod calico-node phải có trạng thái Running trên mỗi node.
Kiểm tra trạng thái Cluster và Node
Sử dụng lệnh describe để kiểm tra chi tiết lỗi (nếu có) trên từng node, đặc biệt là phần "Conditions" và "Events".
Tại sao: Việc kiểm tra chi tiết giúp phát hiện sớm các vấn đề về kernel, docker/containerd, hoặc network connectivity trước khi deploy ứng dụng.
Kết quả mong đợi: Không có lỗi SystemOOM hay NetworkUnavailable trong phần Conditions.
kubectl describe node control-plane
kubectl describe node worker-node-1
Kiểm tra các component hệ thống (control-plane components) để đảm bảo API Server, Controller Manager, Scheduler đang hoạt động bình thường.
Tại sao: Nếu các component này không healthy, cluster sẽ không thể xử lý request từ client hoặc quản lý pod.
Kết quả mong đợi: Tất cả component đều có trạng thái Healthy.
kubectl get componentstatuses
Verify kết quả kiểm tra
Chạy lệnh kiểm tra pod của control-plane để đảm bảo chúng đang chạy và restart count không tăng đột biến.
kubectl get pods -n kube-system -o wide | grep -E "kube-apiserver|kube-scheduler|kube-controller-manager"
Các pod này phải ở trạng thái Running với RESTARTS bằng 0 hoặc thấp.
Tạo Namespace riêng cho Database và Mesh
Tạo file YAML định nghĩa các namespace cần thiết cho series Database Mesh: một namespace cho Database (PostgreSQL) và một namespace cho Mesh (Istio/Envoy).
Tại sao: Namespace giúp cách ly tài nguyên, áp dụng policy riêng biệt và dễ dàng quản lý quyền truy cập (RBAC) cho từng môi trường.
Kết quả mong đợi: Hai namespace database-mesh và istio-system được tạo thành công.
Đường dẫn file: /tmp/namespaces.yaml
apiVersion: v1
kind: Namespace
metadata:
name: database-mesh
labels:
app: database
tier: data
---
apiVersion: v1
kind: Namespace
metadata:
name: istio-system
labels:
app: mesh
tier: control
---
apiVersion: v1
kind: Namespace
metadata:
name: envoy-proxies
labels:
app: proxy
tier: data
Áp dụng file YAML vừa tạo vào cluster để sinh ra các namespace vật lý.
Tại sao: Lệnh apply sẽ đọc file và tạo tài nguyên Namespace trong API Server.
Kết quả mong đợi: Output xác nhận namespace/database-mesh created, namespace/istio-system created.
kubectl apply -f /tmp/namespaces.yaml
Verify kết quả Namespace
Liệt kê tất cả namespaces để xác nhận sự tồn tại của các namespace mới.
kubectl get namespaces
Bạn sẽ thấy các namespace database-mesh, istio-system, envoy-proxies trong danh sách cùng với default và kube-system.
Điều hướng series:
Mục lục: Series: Triển khai Database Mesh với Envoy và Istio trên Ubuntu 24.04
« Phần 1: Chuẩn bị môi trường Ubuntu 24.04 và công cụ cần thiết
Phần 3: Cài đặt Istio Service Mesh bằng Helm trên Kubernetes »