Cài đặt Kubernetes với các công cụ triển khai

• 1: Khởi tạo cụm với kubeadm
• 1.1: Cài đặt kubeadm
• 1.2: Các tùy chọn cho kiến trúc có tính Sẵn sàng cao
• 1.3: Tạo các cụm có tính Sẵn sàng cao với kubeadm
• 1.4: Thiết lập một cụm etcd có tính Sẵn sàng cao (High Availability) với kubeadm

1 - Khởi tạo cụm với kubeadm

1.1 - Cài đặt kubeadm

Trang này hướng dẫn cách cài đặt hộp công cụ kubeadm. Để biết thông tin về cách tạo một cụm với Kubeadm sau khi bạn đã thực hiện quy trình cài đặt này, xem trang Tạo một cụm với kubeadm.

Trước khi bạn bắt đầu

• Một máy chủ Linux tương thích. Dự án Kubernetes cung cấp những hướng dẫn chung cho các bản phân phối Linux dựa trên Debian và Red Hat, và những bản phân phối không có trình quản lý gói.
• 2 GB RAM hoặc nhiều hơn cho mỗi máy (nếu ít hơn sẽ không đủ tài nguyên cho các ứng dụng của bạn).
• 2 CPU hoặc nhiều hơn cho các máy control plane.
• Kết nối toàn mạng giữa tất cả các máy trong cụm (mạng public hoặc private đều được).
• Mọi máy phải có hostname, địa chỉ MAC, và product_uuid duy nhất. Xem tại đây để biết thêm chi tiết.
• Một số cổng được mở trên máy của bạn. Xem tại đây để biết thêm chi tiết.

Kiểm tra phiên bản OS

• Linux
• Windows

Một cụm Kubernetes được tạo bởi kubeadm phụ thuộc vào phần mềm mà chúng sử dụng các chức năng kernel. Phần mềm này bao gồm, nhưng không giới hạn ở container runtime, kubelet, và một plugin Container Network Interface.

Để giúp bạn tránh những lỗi không mong muốn khi sử dụng một phiên bản kernel không được hỗ trợ, kubeadm chạy kiểm tra pre-flight SystemVerification. Quá trình kiểm tra này sẽ lỗi nếu phiên bản kernel không được hỗ trợ.

Bạn có thể chọn bỏ qua kiểm tra, nếu bạn biết rằng kernel của bạn cung cấp các chức năng cần thiết, kể cả kubeadm không hỗ trợ phiên bản đó.

Xác nhận địa chỉ MAC và product_uuid là duy nhất cho từng node

• Bạn có thể biết được địa chỉ MAC của network interfaces bằng câu lệnh ip link hoặc ifconfig -a
• product_uuid có thể kiểm tra bằng câu lệnh sudo cat /sys/class/dmi/id/product_uuid

Rất có thể các thiết bị phần cứng sẽ có các địa chỉ duy nhất, mặc dù một vài máy ảo có thể có các giá trị giống hệt nhau. Kubernetes sử dụng những giá trị đó để định danh duy nhất cho các node trong cụm. Nếu các giá trị đó không là duy nhất cho từng node, quá trình cái đặt có thể thất bại.

Kiểm tra network adapter

Nếu bạn có nhiều hơn một network adapter, và các thành phần Kubernetes của bạn không thể truy cập trên route mặc định, chúng tôi khuyên bạn nên bổ sung (các) IP route để các địa chỉ cụm Kubernetes đi qua adpater thích hợp.

Kiểm tra các cổng cần thiết

Những cổng cần thiết cần phải được mở để các thành phần Kubernetes giao tiếp với nhau. Bạn có thể sử dụng công cụ như netcat để kiểm tra cổng có được mở hay không. Ví dụ:

nc 127.0.0.1 6443 -zv -w 2

Pod network plugin mà bạn sử dụng cũng có thể yêu cầu mở một số cổng nhất định. Vì điều này khác nhau đối với từng pod network plugin, vui lòng xem tài liệu của các plugin về (các) cổng cần thiết.

Cấu hình swap

Mặc định kubelet sẽ không thể khởi động nếu bộ nhớ swap được phát hiện trên một node. Điều này có nghĩa rằng swap nên hoặc là tắt đi hoặc là được chấp nhận bởi kubelet.

• Để chấp nhận swap, thêm failSwapOn: false vào cấu hình kubelet hoặc thông qua tham số dòng lệnh. Lưu ý: thậm chí nếu failSwapOn: false được thêm, workload mặc định cũng không có quyền truy cập swap. Điều này có thể được thay đổi bằng cách đặt swapBehavior, một lần nữa trong file cấu hình kubelet. Để sử dụng swap, đặt một swapBehavior khác với giá trị mặc định NoSwap. Xem Quản lý bộ nhớ swap để biết thêm chi tiết.
• Để tắt swap, sudo swapoff -a có thể được sử dụng để tắt tạm thời. Để làm cho thay đổi này duy trì mỗi khi tái khởi động, đảm bảo rằng swap được tắt trong các file cấu hình như /etc/fstab, systemd.swap, phụ thuộc vào việc nó được cấu hình như thế nào trên hệ thống của bạn.

Cài đặt một container runtime

Để chạy các container trong các Pod, Kubernetes sử dụng một container runtime.

Mặc định, Kubernetes sử dụng Container Runtime Interface (CRI) để giao tiếp với container runtime mà bạn chọn.

Nếu bạn không chỉ định một runtime, kubeadm tự động phát hiện một container runtime đã cài đặt bằng cách quét qua một danh sách những endpoint đã biết.

Nếu có nhiều hoặc không có container runtime nào được phát hiện, kubeadm sẽ ném ra một lỗi và sẽ yêu cầu bạn chỉ định một thứ bạn muốn sử dụng.

Xem container runtimes để biết thêm thông tin.

Những bản bên dưới bao gồm những endpoint đã biết của những hệ điều hành được hỗ trợ:

• Linux
• Windows

Cài đặt kubeadm, kubelet và kubectl

Bạn sẽ cài đặt các package này trên toàn bộ máy chủ của bạn:

• kubeadm: lệnh khởi tạo cụm.

• kubelet: thành phần chạy trên toàn bộ các máy trong cụm của bạn và làm những việc như khởi chạy pod và container.

• kubectl: tiện ích dòng lệnh để giao tiếp với cụm.

kubeadm sẽ không cài đặt hoặc quản lý kubelet và kubectl cho bạn, vì vậy bạn sẽ cần phải đảm bảo rằng phiên bản của chúng giống với Kubernetes control plane bạn muốn kubeadm cài cho bạn. Nếu bạn không làm vậu, rủi ro về sự chênh lệch phiên bản có thể xảy ra và dẫn tới những hành vi lỗi, không mong muốn. Tuy nhiên, chênh lệch một phiên bản minor giữa kubelet và control plane được chấp nhận, nhưng phiên bản kubelet không bao giờ vượt quá phiên bản API server. Ví dụ, kubelet đang chạy 1.7.0 có thể tương thích hoàn toàn với API server phiên bản 1.8.0, nhưng không có chiều ngược lại.

Để biết cách cài đặt kubectl, xem Cài đặt và thiết lập kubectl.

Để biết thêm thông tin về chênh lệch phiên bản, xem:

• Chính sách về phiên bản và chênh lệch phiên bản của Kubernetes
• Chính sách sai lệch phiên bản cụ thể cho kubeadm

• Các bản phân phối dựa trên Debian
• Các bản phân phối dựa trên Red Hat
• Không dùng trình quản lý package

CNI_PLUGINS_VERSION="v1.3.0"
ARCH="amd64"
DEST="/opt/cni/bin"
sudo mkdir -p "$DEST"
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_PLUGINS_VERSION}/cni-plugins-linux-${ARCH}-${CNI_PLUGINS_VERSION}.tgz" | sudo tar -C "$DEST" -xz

DOWNLOAD_DIR="/usr/local/bin"
sudo mkdir -p "$DOWNLOAD_DIR"

CRICTL_VERSION="v1.31.0"
ARCH="amd64"
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz

RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
ARCH="amd64"
cd $DOWNLOAD_DIR
sudo curl -L --remote-name-all https://dl.k8s.io/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet}
sudo chmod +x {kubeadm,kubelet}

RELEASE_VERSION="v0.16.2"
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/krel/templates/latest/kubelet/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /usr/lib/systemd/system/kubelet.service
sudo mkdir -p /usr/lib/systemd/system/kubelet.service.d
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/krel/templates/latest/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf

sudo systemctl enable --now kubelet

Bây giờ kubelet khởi động sau mỗi vài giây, vì nó đợi trong vòng lặp crashloop chờ kubeadm bảo nó phải làm gì.

Cấu hình cgroup driver

Cả container runtime và kubelet có một thuộc tính gọi là "cgroup driver", cái mà quan trọng cho việc quản lý các cgroup trên các máy Linux.

Khắc phục sự cố

Nếu bạn đang gặp các khó khăn với kubeadm, vui lòng tham khảo tài liệu khắc phục sự cố của chúng tôi.

Tiếp theo là gì

• Sử dụng kubeadm để Tạo một cụm

1.2 - Các tùy chọn cho kiến trúc có tính Sẵn sàng cao

Trang này giải thích hai lựa chọn cho việc cấu hình kiến trúc cho các cụm Kubernetes có tính sẵn sàng cao (HA) của bạn.

Bạn có thể thiết lập một cụm HA:

• Với các control plane node xếp chồng, nơi các etcd node được đặt cùng vị trí với các control plane node
• Với các etcd node bên ngoài, nơi etcd chạy trên từng node riêng biệt so với các control plane node

Bạn nên cân nhắc kỹ lưỡng những ưu điểm và nhược điểm của từng kiến trúc trước khi thiết lập một cụm HA.

Kiến trúc etcd xếp chồng

Một cụm HA xếp chồng là một kiến trúc nơi cụm lưu trữ dữ liệu phân tán được cung cấp bởi etcd được xếp chồng lên đầu cụm được hình thành bởi các node được quản lý bởi kubeadm chạy các thành phần control plane.

Mỗi control plane node chạy một instance kube-apiserver, kube-scheduler, và kube-controller-manager. kube-apiserver được expose tới các worker node bằng một bộ cân bằng tải.

Mỗi control plane node tạo một etcd member cục bộ và etcd member này chỉ giao tiếp với kube-apiserver của node đó. Tương tự áp dụng cho các instance kube-controller-manager và kube-scheduler cục bộ.

Cấu trúc liên kết này kết hợp các control plane và các etcd member trên cùng một node. Điều này đơn giản hơn việc thiết lập một cụm với các etcd node bên ngoài, và đơn giản hơn để quản lý replication.

Tuy nhiên, một cụm xếp chồng có nguy cơ lỗi hàng loạt. Nếu một node bị lỗi, cả một etcd member và một instance control plane bị lỗi, và khả năng dự phòng bị ảnh hưởng. Bạn có thể giảm thiểu rủi ro này bằng cách bổ sung thêm control plane node.

Do đó, bạn nên chạy tối thiểu ba node control plane xếp chồng cho cụm HA.

Đây là kiến trúc mặc định trong kubeadm. Một etcd member cục bộ được tạo tự động trên control plane node khi sử dụng kubeadm init và kubeadm join --control-plane.

Kiến trúc etcd bên ngoài

Một cụm HA với etcd bên ngoài là một kiến trúc nơi cụm lưu trữ dữ liệu phân tán được cung cấp bởi etcd nằm ngoài cụm được hình thành bởi các node chạy các thành phần control plane.

Giống như kiến trúc etcd xếp chồng, mỗi control plane node trong một kiến trúc etcd bên ngoài chạy một instance kube-apiserver, kube-scheduler, và kube-controller-manager. Và kube-apiserver được expose tới các worker node bằng một bộ cân bằng tải. Tuy nhiên, các etcd member chạy trên từng host riêng biệt, và từng etcd host giao tiếp với kube-apiserver của từng control plane node.

Kiến trúc này tách rời control plane và etcd member. Vì thế nó cung cấp một thiết lập HA trong đó việc mất một control plane instance hoặc một etcd member có ít tác động hơn và không ảnh hưởng tới khả năng dự phòng của cụm như kiến trúc HA xếp chồng.

Tuy nhiên, kiến trúc này yêu cầu gấp đôi số lượng host so với kiến trúc HA xếp chồng. Yêu cầu tối thiểu ba host cho các control plane node và ba host cho các etcd node cho một cụm HA với kiến trúc này.

Tiếp theo là gì

• Thiết lập một cụm có tính sẵn sàng cao với kubeadm

1.3 - Tạo các cụm có tính Sẵn sàng cao với kubeadm

Trang này giải thích hai cách tiếp cận khác nhau để thiết lập một cụm Kubernetes sẵn sàng cao sử dụng kubeadm:

• Với các control plane node xếp chồng. Cách tiếp cận này yêu cầu ít cơ sở hạ tầng. Các etcd member và control plane node nằm cùng vị trí.
• Với một cụm etcd bên ngoài. Cách tiếp cận này yêu cầu nhiều cơ sở hạ tầng hơn. Các control plane node và etcd member được tách biệt.

Trước khi tiến hành, bạn nên cân nhắc kỹ lưỡng cách tiếp cận nào đáp ứng tốt nhất nhu cầu của các ứng dụng và môi trường của bạn. Các tùy chọn cho kiến trúc có tính Sẵn sàng cao chỉ ra các ưu điểm và nhược điểm của từng cách đó.

Nếu bạn gặp phải các vấn đề khi thiết lập cụm HA, vui lòng phản ánh chúng trong trình theo dõi vấn đề kubeadm.

Xem thêm tài liệu nâng cấp.

Trước khi bạn bắt đầu

Những điều kiện tiên quyết dựa trên kiến trúc bạn chọn cho control plane của cụm:

• etcd xếp chồng
• etcd bên ngoài

Container image

Từng host cần có quyền read và fetch các image từ Kubernetes container image registry, registry.k8s.io. Nếu bạn muốn triển khai một cụm HA trong đó các host không có quyền pull image, điều này khả thi. Bạn cần phải đảm bảo rằng các container image cần thiết có sẵn trên các host liên quan bằng một vài phương pháp khác.

Giao diện dòng lệnh

Để quản lý Kubernetes một khi cụm của bạn được thiết lập, bạn nên cài đặt kubectl trên PC của bạn. Cài đặt công cụ kubectl trên từng control plane node cũng hữu ích, vì nó có thể giúp trong việc xử lý sự cố.

Những bước đầu tiên cho cả hai phương pháp

Tạo bộ cân bằng tải cho kube-apiserver

1. Tạo một bộ cân bằng tải kube-apiserver với tên được phân giải tới DNS.

   • Trong một môi trường cloud bạn nên đặt các control plane node của bạn phía sau một bộ cân bằng tải chuyển tiếp TCP. Bộ cân bằng tải này phân bổ lưu lượng tới toàn bộ các control plane node khỏe mạnh trong danh sách target của nó. Kiểm tra sức khỏe cho một apiserver là một kiểm tra TCP trên port mà kube-apiserver lắng nghe (giá trị mặc định :6443).

   • Không nên sử dụng một địa chỉ IP một cách trực tiếp trong môi trường cloud.

   • Bộ cân bằng tải phải có khả năng giao tiếp với toàn bộ control plane node trên port của apiserver. Nó cũng phải cho phép lưu lượng truy cập đến trên port được nó lắng nghe.

   • Đảm bảo rằng địa chỉ của bộ cân bằng tải luôn khớp với địa chỉ ControlPlaneEndpoint của kubeadm.

   • Đọc hướng dẫn Các tùy chọn cho Cân bằng tải Phần mềm để biết thêm thông tin chi tiết.

2. Thêm control plane node đầu tiên vào bộ cân bằng tải, và kiểm tra kết nối:

   nc -zv -w 2 <LOAD_BALANCER_IP> <PORT>
   

   Một lỗi từ chối kết nối có thể xảy ra bởi vì API server vẫn chưa chạy. Tuy nhiên, timeout có nghĩa là bộ cân bằng tải không thể giao tiếp với control plane node. Nếu một timeout xảy ra, cấu hình lại bộ cân bằng tải để có thể giao tiếp với control plane node.

3. Thêm các control plane node còn lại vào target group của bộ cân bằng tải.

Các control plane và etcd node xếp chồng

Các bước cho control plane node đầu tiên

1. Khởi tạo control plane:

   sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
   

   • Bạn có thể sử dụng cờ --kubernetes-version để chỉ định phiên bản Kubernetes mong muốn. Khuyến nghị rằng các phiên bản của kubeadm, kubelet, kubectl và Kubernetes khớp với nhau.

   • Cờ --control-plane-endpoint nên được đặt thành địa chỉ hoặc DNS và port của bộ cân bằng tải.

   • Cờ --upload-certs được sử dụng để upload các chứng chỉ mà sẽ được chia sẻ tới toàn bộ control-plane instance trong cụm. Nếu thay vào đó, bạn muốn copy các chứng chỉ tới toàn bộ control-plane node một cách thủ công hoặc sử dụng các công cụ tự động, vui lòng bỏ qua cờ này và xem phần Phân bổ chứng chỉ thủ công bên dưới.

   Lưu ý:

   Trong kubeadm init, các cờ --config và --certificate-key không thể kết hợp, vì nếu bạn muốn sử dụng cấu hình kubeadm bạn phải thêm trường certificateKey trong các vị trí cấu hình thích hợp (dưới InitConfiguration và JoinConfiguration: controlPlane).

   Lưu ý:

   Một vài CNI network plugin yêu cầu cấu hình bổ sung, ví dụ chỉ định pod IP CIDR, trong khi những cái khác thì không. Xem tài liệu CNI network. Để thêm một pod CIDR sử dụng cờ --pod-network-cidr, hoặc nếu bạn đang sử dụng file cấu hình kubeadm đặt trường podSubnet bên dưới đối tượng networking của ClusterConfiguration.

   Output sẽ trông giống như dưới đây:

   ...
   You can now join any number of control-plane node by running the following command on each as a root:
       kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
   
   Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
   As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward.
   
   Then you can join any number of worker nodes by running the following on each as root:
       kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
   

   • Copy output này ra một file text. Bạn sẽ cần nó sau này để join các node control plane và worker vào cụm.

   • Khi cờ --upload-certs được sử dụng cùng kubeadm init, các chứng chỉ của control plane chính được mã hóa và upload trong kubeadm-certs Secret.

   • Để upload lại các chứng chỉ và tạo ra một khóa giải mã mới, sử dụng lệnh sau đây trên một control plane node mà đã join vào cụm:

     sudo kubeadm init phase upload-certs --upload-certs
     

   • Bạn cũng có thể chỉ định một --certificate-key tùy chỉnh trong lúc init mà sau này có thể được sử dụng để join. Để tạo ra một khóa như vậy bạn có thể sử dụng lệnh sau đây:

     kubeadm certs certificate-key
     

   Khóa của chứng chỉ là một chuỗi mã hóa hex, đó là một khóa AES có kích thước 32 byte.

   Lưu ý:

   kubeadm-certs Secret và khóa giải mã sẽ hết hạn sau hai giờ.

   Chú ý:

   Như đã nêu trong output của câu lệnh, khóa chứng chỉ cung cấp quyền truy cập tới dữ liệu nhạy cảm của cụm, hãy giữ nó bí mật!

2. Áp dụng CNI plugin mà bạn chọn: Theo dõi các hướng dẫn để cài đặt nhà cung cấp CNI. Chắc chắn rằng cấu hình tương ứng với Pod CIDR đã được chỉ định trong file cấu hình kubeadm (nếu có).

   Lưu ý:

   Bạn phải chọn một network plugin phù hợp với trường hợp sử dụng của bạn và triển khai nó trước khi bạn chuyển sang bước tiếp theo. Nếu bạn không làm điều đó, bạn sẽ không thể khởi chạy cụm của bạn đúng cách.

3. Nhập câu lệnh sau và xem các pod của các thành phần control plane bắt đầu chạy:

   kubectl get pod -n kube-system -w
   

Các bước cho các control plane node còn lại

Đối với từng control plane node bổ sung bạn nên:

1. Thực thi lệnh join bạn nhận được bởi kubeadm init output trước đây trên node đầu tiên. Nó sẽ trông giống như này:

   sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
   

   • Cờ --control-plane báo cho kubeadm join tạo một control plane mới.
   • Cờ --certificate-key ... sẽ download các chứng chỉ cho control plane từ kubeadm-certs Secret trong cụm và được giải mã bằng khóa được cung cấp.

Bạn có thể join nhiều control-plane node đồng thời.

Các etcd node bên ngoài

Thiết lập một cụm với các etcd node bên ngoài giống như các thủ tục được sử dụng cho etcd xếp chồng với ngoại lệ là bạn phải thiết lập etcd trước, và bạn sẽ thêm thông tin etcd trong file cấu hình kubeadm.

Khởi tạo cụm etcd

1. Theo dõi những hướng dẫn này để khởi tạo cụm etcd.

2. Thiết lập SSH như mô tả tại đây.

3. Copy các file sau đây từ bất kỳ etcd node nào trong cụm tới control plane node đầu tiên:

   export CONTROL_PLANE="ubuntu@10.0.0.7"
   scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
   scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
   scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
   

   • Thay giá trị của CONTROL_PLANE bằng user@host của control-plane node đầu tiên.

Thiết lập control plane node đầu tiên

1. Tạo một file với tên kubeadm-config.yaml cùng với những nội dung sau đây:

   ---
   apiVersion: kubeadm.k8s.io/v1beta4
   kind: ClusterConfiguration
   kubernetesVersion: stable
   controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" # thay đổi cái này (xem bên dưới)
   etcd:
     external:
       endpoints:
         - https://ETCD_0_IP:2379 # thay ETCD_0_IP thích hợp
         - https://ETCD_1_IP:2379 # thay ETCD_1_IP thích hợp
         - https://ETCD_2_IP:2379 # thay ETCD_2_IP thích hợp
       caFile: /etc/kubernetes/pki/etcd/ca.crt
       certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
       keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
   

   Lưu ý:

   Sự khác nhau giữa etcd xếp chồng và etcd bên ngoài là thiết lập etcd bên ngoài yêu cầu một file cấu hình với các etcd endpoint bên dưới đối tượng external của etcd. Trong trường hợp của kiến trúc etcd xếp chồng, nó được quản lý tự động.

   • Thay các biến sau đây trong mẫu cấu hình bằng các giá trị thích hợp cho cụm của bạn:

     • LOAD_BALANCER_DNS
     • LOAD_BALANCER_PORT
     • ETCD_0_IP
     • ETCD_1_IP
     • ETCD_2_IP

Những bước sau đây tương tự với thiết lập etcd xếp chồng:

1. Chạy sudo kubeadm init --config kubeadm-config.yaml --upload-certs trên node này.

2. Viết output của các lệnh join được trả về vào một file text để sử dụng sau này.

3. Áp dụng CNI plugin mà bạn chọn.

   Lưu ý:

   Bạn phải chọn một network plugin phù hợp với trường hợp sử dụng của bạn và triển khai nó trước khi bạn chuyển sang bước tiếp theo. Nếu bạn không làm điều đó, bạn sẽ không thể khởi chạy cụm của bạn đúng cách.

Các bước cho các control plane node còn lại

Các bước giống với thiết lập etcd xếp chồng:

• Đảm bảo rằng control plane node đầu tiên được khởi tạo hoàn tất.
• Join từng control plane node với lệnh join bạn lưu trong một file text. Bạn nên join các control plane node lần lượt.
• Đừng quên rằng khóa giải mã từ --certificate-key mặc định sẽ hết hạn sau hai giờ.

Những task phổ biến sau khi khởi tạo control plane

Cài đặt các worker

Các worker node có thể được join vào cụm với lệnh bạn lưu trước đó từ output của lệnh kubeadm init:

sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866

Phân bổ chứng chỉ thủ công

Nếu bạn chọn không sử dụng kubeadm init với cờ --upload-certs điều đó có nghĩa là bạn sẽ phải copy thủ công các chứng chỉ từ control plane node chính tới các control plane node sắp join.

Có nhiều cách để làm điều đó. Cách dưới đây sử dụng ssh và scp:

SSH là cần thiết nếu bạn muốn điều khiển toàn bộ các node từ một máy đơn.

1. Cho phép ssh-agent trên thiết bị chính của bạn có quyền truy cập tới toàn bộ các node khác trong hệ thống:

   eval $(ssh-agent)
   

2. Thêm định danh SSH vào phiên:

   ssh-add ~/.ssh/path_to_private_key
   

3. SSH giữa các node để kiểm tra kết nối hoạt động tốt.

   • Khi bạn SSH tới bất kỳ node nào, thêm cờ -A. Cờ này cho phép node mà bạn đăng nhập qua SSH có quyền truy cập tới SSH agent trên PC của bạn. Cân nhắc các phương pháp thay thế nếu bạn không hoàn toàn tin tưởng vào bảo mật của phiên người dùng của bạn trên node.

     ssh -A 10.0.0.7
     

   • Khi bạn sử dụng sudo trên bất kỳ node nào, đảm bảo duy trì môi trường để SSH chuyển tiếp các hoạt động:

     sudo -E -s
     

4. Sau khi cấu hình SSH trên toàn bộ các node bạn nên chạy tập lệnh sau đây trên control plane node đầu tiên sau khi chạy kubeadm init. Tập lệnh này sẽ copy các chứng chỉ từ control plane node đầu tiên tới các control plane node khác:

   Trong ví dụ dưới đây, thay CONTROL_PLANE_IPS với các địa chỉ IP của các control plane node khác.

   USER=ubuntu # có thể tùy chỉnh
   CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
   for host in ${CONTROL_PLANE_IPS}; do
       scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
       scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
       scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
       scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
       scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
       scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
       scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
       # Bỏ qua dòng tiếp theo nếu bạn đang sử dụng etcd bên ngoài
       scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
   done
   

   Chú ý:

   Chỉ copy các chứng chỉ trong danh sách trên. kubeadm sẽ phụ trách việc sinh ra các chứng chỉ còn lại cùng với các SAN cần thiết cho các control-plane instance sắp join. Nếu bạn copy toàn bộ các chứng chỉ do nhầm lẫn, quá trình tạo các node bổ sung có thể thất bại do thiếu các SAN cần thiết.

5. Sau đó trên từng control plane node sắp join bạn phải chạy tập lệnh sau đây trước khi chạy kubeadm join. Tập lệnh này sẽ di chuyển các chứng chỉ đã được copy trước đây từ thư mục home tới /etc/kubernetes/pki:

   USER=ubuntu # có thể tùy chỉnh
   mkdir -p /etc/kubernetes/pki/etcd
   mv /home/${USER}/ca.crt /etc/kubernetes/pki/
   mv /home/${USER}/ca.key /etc/kubernetes/pki/
   mv /home/${USER}/sa.pub /etc/kubernetes/pki/
   mv /home/${USER}/sa.key /etc/kubernetes/pki/
   mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
   mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
   mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
   # Bỏ qua dòng tiếp theo nếu bạn đang sử dụng etcd bên ngoài
   mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
   

1.4 - Thiết lập một cụm etcd có tính Sẵn sàng cao (High Availability) với kubeadm

Mặc định, kubeadm chạy một instance etcd cục bộ trên từng node control plane. Bạn cũng có thể thiết lập cụm etcd bên ngoài và cung cấp các etcd instance trên các máy chủ riêng biệt. Những sự khác biệt giữa hai cách tiếp cận này được trình bày trong trang Các tùy chọn cho kiến trúc có tính Sẵn sàng cao.

Tác vụ này hướng dẫn quy trình tạo một cụm etcd bên ngoài có tính sẵn sàng cao gồm ba member mà kubeadm có thể sử dụng trong quá trình tạo cụm.

Trước khi bạn bắt đầu

• Ba máy chủ có thể giao tiếp với nhau qua cổng TCP 2379 và 2380. Tài liệu này giả định các cổng mặc định này. Tuy nhiên, chúng có thể được cấu hình thông qua tệp cấu hình kubeadm.
• Mỗi máy chủ phải có systemd và đã cài đặt một shell tương thích với bash.
• Mỗi máy chủ phải đã cài đặt một container runtime, kubelet, và kubeadm.
• Mỗi máy chủ phải có quyền truy cập vào Kubernetes container image registry (registry.k8s.io) hoặc list/pull image etcd cần thiết bằng lệnh kubeadm config images list/pull. Hướng dẫn này sẽ cài đặt các etcd instance dạng static pods được quản lý bởi kubelet.
• Một số công cụ để sao chép các file giữa các máy chủ. Ví dụ ssh và scp có thể đáp ứng yêu cầu này.

Thiết lập cụm

Cách tiếp cận thông thường là tạo ra toàn bộ chứng chỉ trên một node và chỉ phân bổ những file quan trọng tới các node khác.

1. Cấu hình kubelet để trở thành trình quản lý dịch vụ cho etcd.

   Lưu ý:

   Bạn phải thực hiện điều này trên toàn bộ các máy chủ chạy etcd.
   Vì etcd sẽ được tạo ra trước tiên, bạn phải ghi đè độ ưu tiên dịch vụ bằng cách tạo ra một unit file mới có độ ưu tiên cao hơn kubelet unit file mà kubeadm cung cấp.

   cat << EOF > /etc/systemd/system/kubelet.service.d/kubelet.conf
   # Thay thế "systemd" bằng giá trị cgroup driver của container runtime của bạn. Giá trị mặc định trong kubelet là "cgroupfs".
   # Thay thế giá trị của "containerRuntimeEndpoint" bằng một container runtime khác nếu cần.
   #
   apiVersion: kubelet.config.k8s.io/v1beta1
   kind: KubeletConfiguration
   authentication:
     anonymous:
       enabled: false
     webhook:
       enabled: false
   authorization:
     mode: AlwaysAllow
   cgroupDriver: systemd
   address: 127.0.0.1
   containerRuntimeEndpoint: unix:///var/run/containerd/containerd.sock
   staticPodPath: /etc/kubernetes/manifests
   EOF
   
   cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
   [Service]
   ExecStart=
   ExecStart=/usr/bin/kubelet --config=/etc/systemd/system/kubelet.service.d/kubelet.conf
   Restart=always
   EOF
   
   systemctl daemon-reload
   systemctl restart kubelet
   

   Kiểm tra trạng thái kubelet để chắc chắn rằng nó đang chạy.

   systemctl status kubelet
   

2. Tạo các file cấu hình cho kubeadm.

   Tạo một file cấu hình kubeadm cho từng máy chủ mà có etcd member chạy trên đó sử dụng tập lệnh dưới đây.

   # Thay đổi HOST0, HOST1 và HOST2 với các IP của các máy của bạn
   export HOST0=10.0.0.6
   export HOST1=10.0.0.7
   export HOST2=10.0.0.8
   
   # Thay đổi NAME0, NAME1 và NAME2 bằng hostnames của các máy của bạn
   export NAME0="infra0"
   export NAME1="infra1"
   export NAME2="infra2"
   
   # Tạo các thư mục tạm thời để lưu các file sẽ xuất hỉện trên các máy khác
   mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/
   
   HOSTS=(${HOST0} ${HOST1} ${HOST2})
   NAMES=(${NAME0} ${NAME1} ${NAME2})
   
   for i in "${!HOSTS[@]}"; do
   HOST=${HOSTS[$i]}
   NAME=${NAMES[$i]}
   cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml
   ---
   apiVersion: "kubeadm.k8s.io/v1beta4"
   kind: InitConfiguration
   nodeRegistration:
       name: ${NAME}
   localAPIEndpoint:
       advertiseAddress: ${HOST}
   ---
   apiVersion: "kubeadm.k8s.io/v1beta4"
   kind: ClusterConfiguration
   etcd:
       local:
           serverCertSANs:
           - "${HOST}"
           peerCertSANs:
           - "${HOST}"
           extraArgs:
           - name: initial-cluster
             value: ${NAMES[0]}=https://${HOSTS[0]}:2380,${NAMES[1]}=https://${HOSTS[1]}:2380,${NAMES[2]}=https://${HOSTS[2]}:2380
           - name: initial-cluster-state
             value: new
           - name: name
             value: ${NAME}
           - name: listen-peer-urls
             value: https://${HOST}:2380
           - name: listen-client-urls
             value: https://${HOST}:2379
           - name: advertise-client-urls
             value: https://${HOST}:2379
           - name: initial-advertise-peer-urls
             value: https://${HOST}:2380
   EOF
   done
   

3. Tạo cơ quan cấp chứng chỉ (CA).

   Nếu bạn đã có một CA, việc tiếp theo chỉ cần sao chép các file crt và key của CA tới /etc/kubernetes/pki/etcd/ca.crt và /etc/kubernetes/pki/etcd/ca.key. Sau khi các file đó được sao chép, tiến hành các bước tiếp theo, "Tạo các chứng chỉ cho từng member member".

   Nếu bạn chưa có CA nào, hãy chạy câu lệnh này trên $HOST0 (nơi bạn tạo các file cấu hình cho kubeadm).

   kubeadm init phase certs etcd-ca
   

   Nó sẽ tạo ra hai file:

   • /etc/kubernetes/pki/etcd/ca.crt
   • /etc/kubernetes/pki/etcd/ca.key

4. Tạo các chứng chỉ cho từng member member.

   kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
   kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
   cp -R /etc/kubernetes/pki /tmp/${HOST2}/
   # Dọn dẹp các chứng chỉ không sử dụng
   find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
   
   kubeadm init phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
   kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
   cp -R /etc/kubernetes/pki /tmp/${HOST1}/
   find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
   
   kubeadm init phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
   kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
   # Không cần phải di chuyển các chứng chỉ vì chúng dành cho HOST0
   
   # Dọn dẹp các chứng chỉ không nên sao chép khỏi máy chủ này
   find /tmp/${HOST2} -name ca.key -type f -delete
   find /tmp/${HOST1} -name ca.key -type f -delete
   

5. Sao chép các chứng chỉ và các cấu hình kubeadm.

   Các chứng chỉ này đã được tạo ra và bây giờ chúng cần được đưa tới từng máy chủ tương ứng.

   USER=ubuntu
   HOST=${HOST1}
   scp -r /tmp/${HOST}/* ${USER}@${HOST}:
   ssh ${USER}@${HOST}
   USER@HOST $ sudo -Es
   root@HOST $ chown -R root:root pki
   root@HOST $ mv pki /etc/kubernetes/
   

6. Đảm bảo đã có đủ toàn bộ các file cần thiết.

   Danh sách đầy đủ các file cần thiết trên $HOST0 gồm:

   /tmp/${HOST0}
   └── kubeadmcfg.yaml
   ---
   /etc/kubernetes/pki
   ├── apiserver-etcd-client.crt
   ├── apiserver-etcd-client.keyt
   └── etcd
       ├── ca.crt
       ├── ca.key
       ├── healthcheck-client.crt
       ├── healthcheck-client.key
       ├── peer.crt
       ├── peer.key
       ├── server.crt
       └── server.key
   

   Trên $HOST1:

   $HOME
   └── kubeadmcfg.yaml
   ---
   /etc/kubernetes/pki
   ├── apiserver-etcd-client.crt
   ├── apiserver-etcd-client.key
   └── etcd
       ├── ca.crt
       ├── healthcheck-client.crt
       ├── healthcheck-client.key
       ├── peer.crt
       ├── peer.key
       ├── server.crt
       └── server.key
   

   Trên $HOST2:

   $HOME
   └── kubeadmcfg.yaml
   ---
   /etc/kubernetes/pki
   ├── apiserver-etcd-client.crt
   ├── apiserver-etcd-client.key
   └── etcd
       ├── ca.crt
       ├── healthcheck-client.crt
       ├── healthcheck-client.key
       ├── peer.crt
       ├── peer.key
       ├── server.crt
       └── server.key
   

7. Tạo các manifest cho static pod.

   Bây giờ các chứng chỉ và cấu hình đã có, đã đến lúc tạo các manifest. Trên mỗi máy chủ, hãy chạy lệnh kubeadm để tạo static manifest cho etcd.

   root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
   root@HOST1 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
   root@HOST2 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
   

8. Tùy chọn: Kiểm tra sức khỏe cụm.

   Nếu etcdctl không có sẵn, bạn có thể chạy công cụ này trong một container image. Bạn sẽ thực hiện điều đó trực tiếp với container runtime của mình bằng cách sử dụng một công cụ như crictl run và không thông qua Kubernetes.

   ETCDCTL_API=3 etcdctl \
   --cert /etc/kubernetes/pki/etcd/peer.crt \
   --key /etc/kubernetes/pki/etcd/peer.key \
   --cacert /etc/kubernetes/pki/etcd/ca.crt \
   --endpoints https://${HOST0}:2379 endpoint health
   ...
   https://[HOST0 IP]:2379 is healthy: successfully committed proposal: took = 16.283339ms
   https://[HOST1 IP]:2379 is healthy: successfully committed proposal: took = 19.44402ms
   https://[HOST2 IP]:2379 is healthy: successfully committed proposal: took = 35.926451ms
   

   • Đặt ${HOST0} bằng địa chỉ IP của máy chủ bạn đang kiểm tra.

Tiếp theo là gì

Một khi bạn đã có một cụm etcd với 3 member đang chạy, bạn có thể tiếp tục thiết lập một control plane có tính sẵn sàng cao bằng phương pháp etcd bên ngoài với kubeadm.