1. Kiến trúc hệ thống

Diễn giải kiến trúc như hình dưới đây:

Quy mô triển khai sử dụng 5 máy ảo, phân bổ chức năng như sau:

• 2 máy làm nhiệm vụ cân bằng tải: một máy xử lý L4 (cân bằng tải tầng giao thức), một máy xử lý L7 (cân bằng tải ứng dụng). Máy L7 đóng vai trò reverse proxy cho Ingress, máy L4 phục vụ cân bằng tải cho apiserver.
• Cả hai máy này cũng chạy dịch vụ DNS và etcd. Đồng thời, cả hai đều được cấu hình chung một địa chỉ VIP là 10.211.55.10.
• 2 máy còn lại triển khai các dịch vụ lõi của K8s: vừa là Master, vừa là Node. Nếu tài nguyên đủ, có thể tách biệt giữa node điều khiển (Master) và node thực thi (Worker).
• 1 máy dành riêng cho vận hành: cung cấp kho Docker (Harbor), kho tài nguyên K8s, dịch vụ lưu trữ chia sẻ (NFS), đồng thời dùng để ký phát chứng chỉ. Dịch vụ etcd được triển khai trên các máy có IP 10.211.55.12, 10.211.55.21, và 10.211.55.22.

2. Quy hoạch mạng

Hệ thống sử dụng ba dải mạng chính:

• Mạng máy chủ (Node network): 10.211.55.0/24
• Mạng Pod: 172.7.0.0/16
• Mạng Service: mạng ảo, sử dụng dải 192.168.0.0/16

Địa chỉ IP của hai máy chủ vật lý:

• 10.211.55.21
• 10.211.55.22

Dải mạng Pod tương ứng với từng máy chủ:

• Máy 21: 172.7.21.0/24
• Máy 22: 172.7.22.0/24

Nguyên tắc ánh xạ: vị trí thứ ba trong địa chỉ Pod trùng với số cuối trong địa chỉ IP máy chủ — giúp dễ dàng xác định Pod đang chạy trên máy nào.

3. Phân bổ tài nguyên hệ thống

Tên máy	IP	Loại máy	Cấu hình môi trường
	10.211.55.10	VIP	Không có dịch vụ
CFZX55-11	10.211.55.11	Cân bằng tải (chủ)	Bind, Nginx, Keepalived
CFZX55-12	10.211.55.12	Cân bằng tải (phụ)	etcd, Nginx, Keepalived
CFZX55-21	10.211.55.21	Master + Node	Ingress, kubelet, kube-proxy, pod, etcd, apiserver, controller-manager, scheduler
CFZX55-22	10.211.55.22	Master + Node	Ingress, kubelet, kube-proxy, pod, etcd, apiserver, controller-manager, scheduler
CFZX55-200	10.211.55.200	Máy vận hành	cfssl, harbor, NFS

4. Môi trường phát hành chứng chỉ

Môi trường tạo chứng chỉ được triển khai trên máy CFZX55-200 (máy vận hành). Chứng chỉ được lưu tại thư mục: /opt/certs.

4.1 Cài đặt công cụ cfssl

Phiên bản: 1.6.1
Đường dẫn cài đặt: /opt/cfssl

[root@cfzx55-200 cfssl]# pwd
/opt/cfssl
[root@cfzx55-200 cfssl]# ll
-rwxr-xr-x 1 root root 16659824 Mar 12 15:52 cfssl
-rwxr-xr-x 1 root root 13502544 Mar 12 15:52 cfssl-certinfo
-rwxr-xr-x 1 root root 11029744 Mar 12 15:52 cfssl-json
[root@cfzx55-200 cfssl]# cfssl version
Version: 1.6.1
Runtime: go1.12.12

Chức năng từng công cụ:

• cfssl: Tạo chứng chỉ, đầu ra dạng JSON.
• cfssl-json: Chuyển đổi chứng chỉ JSON thành file nhị phân.
• cfssl-certinfo: Xem thông tin chi tiết về chứng chỉ.

Cập nhật đường dẫn /opt/cfssl vào biến môi trường PATH:

[root@hdss7-200 ~]# vim /etc/profile
export PATH=$PATH:/opt/cfssl
[root@hdss7-200 ~]# source /etc/profile
[root@hdss7-200 ~]# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/opt/cfssl

4.2 Hướng dẫn sử dụng cfssl

Các lệnh con của cfssl:

• genkey: Sinh khóa riêng (private key) và yêu cầu ký chứng chỉ (CSR).
• certinfo: Hiển thị thông tin từ một chứng chỉ đã tồn tại.
• gencert: Sinh khóa mới và chứng chỉ đã được ký. Các tham số chính:
  • -initca: Khởi tạo CA mới — cần khi tạo root CA.
  • -ca: Chỉ định file chứng chỉ CA (ca.pem).
  • -ca-key: Chỉ định file khóa riêng CA (ca-key.pem).
  • -config: Chỉ định file cấu hình CSR dạng JSON (ca-config.json).
  • -profile: Chỉ định profile trong file config để áp dụng quy tắc tạo chứng chỉ.

4.3 Tạo chứng chỉ gốc (CA)

Trước tiên cần tạo chứng chỉ gốc (Root CA) để ký các chứng chỉ khác.

Tạo file cấu hình CSR tại /opt/certs/ca-csr.json:

{
    "CN": "kubernetes",
    "hosts": [],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "ST": "beijing",
            "L": "beijing",
            "O": "k8s",
            "OU": "system"
        }
    ],
    "ca": {
        "expiry": "175200h"
    }
}

Giải thích các trường:

• CN: Common Name — thường điền tên miền. apiserver đọc từ đây để xác định người dùng (User).
• hosts: Danh sách tên miền/hôp host hợp lệ trong yêu cầu truy cập.
• key: Thông tin khóa — mặc định dùng RSA-2048.
• names: Thông tin hiển thị công khai:
  • C: Quốc gia (ví dụ: CN)
  • ST: Tỉnh/thành phố
  • L: Quận/huyện
  • O: Tổ chức — apiserver dùng để xác định nhóm người dùng (Group).
  • OU: Đơn vị tổ chức
• expiry: Thời hạn hiệu lực — 175200h tương đương 20 năm.

Thực hiện tạo CA:

[root@cfzx55-200 certs]# cfssl gencert -initca ca-csr.json | cfssl-json -bare ca
2022/03/12 16:21:32 [INFO] generating a new CA key and certificate from CSR
...
[root@cfzx55-200 certs]# ll
total 16
-rw-r--r-- 1 root root  333 Mar 12 16:20 ca-csr.json
-rw------- 1 root root 1679 Mar 12 16:21 ca-key.pem
-rw-r--r-- 1 root root 1045 Mar 12 16:21 ca.csr
-rw-r--r-- 1 root root 1310 Mar 12 16:21 ca.pem

File sinh ra:

• ca.pem: Chứng chỉ gốc (Root CA).
• ca-key.pem: Khóa riêng của Root CA.

Bây giờ đã có CA gốc, có thể dùng để ký các chứng chỉ khác.

4.4 Tạo file cấu hình chiến lược CA

File này tên là ca-config.json, dùng để định nghĩa các profile (mẫu) chứng chỉ, bao gồm thời hạn, quyền sử dụng (usages), v.v.

Đường dẫn: /opt/certs/ca-config.json

{
    "signing": {
        "default": {
            "expiry": "175200h"
        },
        "profiles": {
            "server": {
                "expiry": "175200h",
                "usages": [
                    "signing",
                    "key encipherment",
                    "server auth"
                ]
            },
            "client": {
                "expiry": "175200h",
                "usages": [
                    "signing",
                    "key encipherment",
                    "client auth"
                ]
            },
            "kubernetes": {
                "expiry": "175200h",
                "usages": [
                    "signing",
                    "key encipherment",
                    "server auth",
                    "client auth"
                ]
            },
            "peer": {
                "expiry": "175200h",
                "usages": [
                    "signing",
                    "key encipherment",
                    "server auth",
                    "client auth"
                ]
            }
        }
    }
}

Giải thích:

• server auth: Cho phép client xác minh chứng chỉ của server.
• client auth: Cho phép server xác minh chứng chỉ của client.
• signing: Chứng chỉ có thể dùng để ký chứng chỉ khác.
• profiles:
  • server: Dùng cho dịch vụ phía server.
  • client: Dùng cho client kết nối đến server.
  • kubernetes: Chứng chỉ kép, dùng cho các thành phần nội bộ K8s (apiserver, kubelet, etc).
  • peer: Dùng cho giao tiếp giữa các nút cluster (ví dụ: etcd).

Khi tạo chứng chỉ, cần chỉ định file cấu hình (ca-config.json) và profile phù hợp. Trong hướng dẫn này, để đơn giản, tất cả sử dụng profile kubernetes.