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.Ở mục này chúng ta sẽ liệt kê ra những cách khác nhau để cài đặt và sử dụng Kubernetes. Khi cài đặt Kubernetes, bạn hãy lựa chọn cách thức dựa trên theo những yếu tố như: dễ dàng bảo trì, tính bảo mật, mức độ kiểm soát, tài nguyên sẵn có, cũng như trình độ chuyên môn cần thiết để vận hành và quản lý cluster.
Để triển khai (deploy) Kubernetes cluster ở máy local, trên dịch vụ điện toán đám mây (cloud) hay ở trung tâm dữ liệu của riêng bạn, hãy tải Kubernetes xuống ở đây.
Một số components của Kubernetes như kube-apiserver hoặc kube-proxy có thể được triển khai dưới dạng container images ở trong cluster.
Chúng tôi khuyến khích bạn thực thi components dưới dạng những container images, Kubernetes sẽ quản lý những components đó. Lưu ý, không bao gồm những components có sử dụng container (đặc biệt là kubelet).
Trong trường hợp bạn không muốn tự quản lý Kubernetes cluster, bạn có thể chọn một service quản lý, bao gồm certified platforms. Ngoài ra còn có các giải pháp tiêu chuẩn và tùy chỉnh khác trên nhiều môi trường điện toán đám mây (cloud), hay môi trường một máy chủ (bare metal environment) khác nhau.
Nếu bạn đang ở trong giai đoạn học Kubernetes, bạn có thể sử dụng những công cụ (tools) được hỗ trợ bởi cộng đồng Kubernetes, hoặc những công cụ trong hệ sinh thái để cài đặt Kubernetes cluster trên máy của bạn. Xem thêm.
Khi đánh giá một giải pháp dành cho môi trường production, bạn cần xem xét những khía cạnh về việc vận hành Kubernetes cluster (hoặc khái niệm trừu trượng của nó) mà bạn muốn tự quản lý, hoặc những phần nào bạn muốn để cho nhà cung cấp quản lý.
Với cluster bạn tự quản lý, công cụ hỗ trợ chính thức để triển khai (deploy) Kubernetes là kubeadm.
Tiếp theo là gì
kubectlMột cụm Kubernetes chất lượng production yêu cầu có sự lên kế hoạch và chuẩn bị. Nếu cụm Kubernetes của bạn dùng để chạy các workload quan trọng, nó phải được cấu hình để có khả năng phục hồi. Trang này giải thích các bước bạn có thể thực hiện để thiết lập một cụm sẵn sàng cho production, hoặc để thúc đẩy một cụm hiện có cho việc sử dụng production. Nếu bạn đã quen thuộc với thiết lập production và muốn những liên kết, hãy bỏ qua đến Tiếp theo là gì.
Thông thường, một môi trường cụm Kubernetes production có nhiều yêu cầu hơn một môi trường Kubernetes cho học tập, phát triển hoặc thử nghiệm cá nhân. Một môi trường production có thể yêu cầu truy cập an toàn bởi nhiều người dùng, tính khả dụng nhất quán, và các nguồn lực để thích ứng với nhu cầu thay đổi.
Khi bạn quyết định nơi bạn muốn triển khai môi trường Kubernetes production (on-premise hoặc trên cloud) và lượng công việc quản lý bạn muốn đảm nhận hoặc trao cho người khác, hãy xem xét các yêu cầu của bạn đối với cụm Kubernetes bị ảnh hưởng như thế nào bởi các vấn đề sau:
Tính sẵn sàng: Một môi trường học tập Kubernetes trên một máy có một điểm lỗi duy nhất. Tạo một cụm có tính sẵn sàng cao có nghĩa là phải cân nhắc:
Quy mô: Nếu bạn mong muốn môi trường Kubernetes production của mình đáp ứng được một lượng yêu cầu ổn định, bạn có thể thiết lập khả năng đáp ứng bạn cần và hoàn thành. Tuy nhiên, nếu bạn mong muốn đáp ứng nhu cầu tăng theo thời gian hoặc thay đổi đáng kể dựa trên những yếu tố như mùa hoặc sự kiện đặc biệt, bạn cần lập kế hoạch về việc mở rộng quy mô để giảm bớt áp lực tăng lên từ nhiều yêu cầu hơn đối với control plane và các worker node hoặc thu hẹp quy mô để tối ưu tài nguyên không sử dụng.
Quản lý bảo mật và truy cập: Bạn có đầy đủ các đặc quyền admin trên cụm Kubernetes học tập của mình. Nhưng các cụm chia sẻ với nhiều workload quan trọng, và nhiều hơn một hoặc hai người dùng, yêu cầu một cách tiếp cận tinh tế hơn đối với những ai và những gì có thể truy cập vào các tài nguyên cụm. Bạn có thể sử dụng kiểm soát truy cập dựa trên vai trò (RBAC) và các kỹ thuật bảo mật khác để chắc chắn rằng người dùng và workloads có thể truy cập được tới tài nguyên họ cần trong khi vẫn đảm bảo bảo mật cho worload và cụm máy chủ. Bạn có thể đặt giới hạn lên tài nguyên mà người dùng và workload có thể truy cập bằng cách quản lý các chính sách và tài nguyên container.
Trước khi dựng một môi trường Kubernetes production, cân nhắc chuyển giao một phần hoặc toàn bộ công việc này cho các nhà cung cấp giải pháp Cloud Turnkey Cloud Solutions hoặc các đối tác Kubernetes Partners. Các tùy chọn gồm:
Liệu bạn tự dựng một cụm Kubernetes production hay làm điều đó với các đối tác, xem những phần dưới đây để đánh giá nhu cầu liên quan tới control plane, các worker node, truy cập người dùng, và các tài nguyên workload cho cụm của bạn.
Trong một cụm Kubernetes có chất lượng production, control plane quản lý cụm từ các dịch vụ có thể được trải đều trên nhiều máy tính theo những cách khác nhau. Tuy nhiên, mỗi worker node đại diện cho một thực thể duy nhất được cấu hình để chạy Kubernetes pod.
Cụm Kubernetes đơn giản nhất có toàn bộ dịch vụ control plane và worker node chạy trên cùng một máy. Bạn có thể phát triển môi trường đó bằng cách thêm các worker node, như được phản ánh trong sơ đồ được minh họa trong Các thành phần Kubernetes. Nếu cụm có nghĩa là có sẵn trong một khoảng thời gian ngắn hoặc có thể bị loại bỏ nếu có sự cố nghiêm trọng, điều này có thể đáp ứng nhu cầu của bạn.
Tuy nhiên, nếu bạn cần một cụm vĩnh viễn, có mức độ sẵn cao hơn, bạn nên xem xét các cách mở rộng control plane. Theo thiết kế, dịch vụ control plane chạy trên một máy tính đơn là không có tính sẵn sàng cao. Nếu việc giữ cụm được dựng lên và chạy và đảm bảo rằng nó có thể được sửa chữa nếu có sự cố xảy ra là điều quan trọng, Xem xét các bước sau:
Để tìm hiểu về các tùy chọn có sẵn khi bạn chạy các dịch vụ control plane, xem các trang kube-apiserver, kube-controller-manager, và kube-scheduler. Đối với các ví dụ về control plane có tính sẵn sàng cao, xem Các tùy chọn cho kiến trúc có tính Sẵn sàng cao, Tạo các cụm có tính Sẵn sàng cao với kubeadm, và Vận hành cụm etcd cho Kubernetes. Xem Sao lưu cụm etcd để biến cách tạo kế hoạch sao lưu cho etcd.
Workload chất lượng production cần phải có tính đàn hồi và bất kỳ thành phần nào mà chúng phụ thuộc vào cũng phải có tính đàn hồi (ví dụ CoreDNS). Cho dù bạn tự quản lý control plane hay có một nhà cung cấp cloud làm điều đó cho bạn, bạn vẫn cần phải xem xét cách bạn muốn quản lý các worker node (còn gọi một cách đơn giản là node).
Trên production, bạn có thể chuyển từ một mô hình nơi bạn hoặc một nhóm nhỏ những người đang truy cập cụm đến nơi có khả năng có hàng tá hoặc hàng trăm người. Trong môi trường học tập hoặc nền tảng nguyên mẫu, bạn có thể có một tài khoản quản trị cho mọi thứ bạn làm. Trên production, bạn sẽ muốn nhiều tài khoản với các cấp độ truy cập khác nhau vào các namespace khác nhau.
Đảm nhận một cụm có chất lượng production nghĩa là quyết định việc bạn muốn làm thế nào để cho phép người dùng khác truy cập một cách chọn lọc. Đặc biệt, bạn cần chọn chiến lược để xác minh danh tính những người đang cố truy cập vào cụm của bạn (xác thực) và quyết định liệu họ có quyền làm những gì họ muốn (phân quyền):
Với tư cách là người thiết lập xác thực và phân quyền trên cụm Kubernetes production, dưới đây là một số điều cần cân nhắc:
Node,RBAC. Điều này sẽ cho phép
phân quyền Node và RBAC tới những yêu cầu đã xác thực.Những yêu cầu từ production workload có thể gây ra áp lực lên cả trong và ngoài Kubernetes control plane. Hãy cân nhắc những mục này khi thiết lập cho nhu cầu của workload trong cụm của bạn:
default từ namespace của nó.
Xem Quản lý Service Account
để biết cách tạo một service account. Ví dụ, bạn có thể muốn:
Có nhiều phương pháp và công cụ cho việc cài đặt cụm Kubernetes production của bạn. Ví dụ:
Cluster API: Một dự án con Kubernetes tập trung vào việc cung cấp API và công cụ khai báo để đơn giản hóa việc cung cấp, nâng cấp và vận hành nhiều cụm Kubernetes.
kops: Một công cụ cung cấp cụm tự động.
Đối với các hướng dẫn, thực hành tốt nhất, tùy chọn cấu hình và thông tin về
tiếp cận với cộng đồng, vui lòng kiểm tra
kOps website để biết chi tiết.
kubespray: Một sự phối hợp của Ansible playbooks, inventory, các công cụ cung cấp, và kiến thức chuyên môn cho các tác vụ quản lý cấu hình Hệ điều hành/cụm Kubernetes chung. Bạn có thể tiếp cận tới cộng đồng trên kênh Slack #kubespray.
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.
Trang installation guide này dành cho Kubernetes v1.35. Nếu bạn muốn sử dụng phiên bản Kubernetes khác, vui lòng tham khảo các trang sau đây thay vì:
kubeadm có thể được thực hiện thông qua các tệp nhị phân sử dụng liên kết động và giả sử hệ thống của bạn cung cấp glibc.
Giả định này hợp lý trên nhiều bản phân phối Linux (bao gồm Debian, Ubuntu, Fedora, CentOS, v.v...)
nhưng không phải luôn đúng đối với các bản phân phối nhẹ và tùy biến bởi mặc định chúng không có sẵn glibc, ví dụ Alpine Linux.
Kỳ vọng là bản phân phối hoặc bao gồm glibc hoặc có một
lớp tương thích
cung cấp các đặc trưng mong muốn.uname -rĐể biết thêm thông tin, xem Các yêu cầu về Linux Kernel.
systeminfoĐể biết thêm thông tin, xem Sự tương thích của các phiên bản Windows OS.
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 đó.
ip link hoặc ifconfig -asudo cat /sys/class/dmi/id/product_uuidRấ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.
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.
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.
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.
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.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.Để 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ợ:
| Runtime | Đường dẫn tới Unix domain socket |
|---|---|
| containerd | unix:///var/run/containerd/containerd.sock |
| CRI-O | unix:///var/run/crio/crio.sock |
| Docker Engine (using cri-dockerd) | unix:///var/run/cri-dockerd.sock |
| Runtime | Đường dẫn tới Windows named pipe |
|---|---|
| containerd | npipe:////./pipe/containerd-containerd |
| Docker Engine (using cri-dockerd) | npipe:////./pipe/cri-dockerd |
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:
apt.kubernetes.io và yum.kubernetes.io) đã bị
lỗi thời và đóng băng từ ngày 13 tháng 9, 2023.
Sử dụng các kho lưu trữ mới được đặt tại pkgs.k8s.io
được khuyến nghị mạnh mẽ và yêu cầu để cài đặt các phiên bản Kubernetes phát hành sau ngày 13 tháng 9, 2023.
Các kho cũ đã lỗi thời, và nội dung của chúng, có thể bị xóa bất kỳ lúc nào trong tương lai và mà không có
thêm thông báo. Các kho lưu trữ mới cung cấp tải về cho các phiên bản Kubernetes bắt đầu từ v1.24.0.
Hướng dẫn này dành cho Kubernetes v1.35.
Cập nhật apt package index và cài đặt các package cần thiết để sử dụng kho lưu trữ apt của Kubernetes:
sudo apt-get update
# apt-transport-https có thể là một package giả; nếu vậy, bạn có thể bỏ qua package này
sudo apt-get install -y apt-transport-https ca-certificates curl gpg
Tải xuống khóa ký công khai cho các kho lưu trữ package của Kubernetes. Toàn bộ các kho lưu trữ sử dụng chung khóa ký do vậy bạn có thể không cần quan tâm tới phiên bản trong URL:
# Nếu thư mục `/etc/apt/keyrings` không tồn tại, nó nên được tạo trước lệnh curl, đọc chú thích bên dưới.
# sudo mkdir -p -m 755 /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.35/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
/etc/apt/keyrings mặc định không
tồn tại, và nó nên được tạo trước lệnh curl.Thêm kho lưu trữ apt Kubernetes thích hợp. Vui lòng chú ý rằng kho lưu trữ này chỉ chứa những package
cho Kubernetes 1.35; đối với các phiên bản Kubernetes minor khác, bạn cần phải
thay đổi phiên bản Kubernetes minor trong URL để trùng với phiên bản minor bạn mong muốn
(bạn cũng nên kiểm tra lại rằng bạn đang đọc tài liệu cho phiên bản Kubernetes
mà bạn dự định cài đặt).
# Điều này sẽ ghi đè bất kỳ những cấu hình nào đang có trong /etc/apt/sources.list.d/kubernetes.list
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.35/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
Cập nhật apt package index, cài đặt kubelet, kubeadm và kubectl, và ghim lại phiên bản của chúng:
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
(Tùy chọn) Bật dịch vụ kubelet trước khi chạy kubeadm:
sudo systemctl enable --now kubelet
Đặt SELinux thành chế độ permissive:
Những hướng dẫn này dành cho Kubernetes 1.35.
# Đặt SELinux trong chế độ permissive (vô hiệu hóa nó một cách hiệu quả)
sudo setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
setenforce 0 và sed ...
vô hiệu hóa nó một cách hiệu quả. Điều này là bắt buộc để cho phép các container truy cập vào hệ thống file
của máy chủ; ví dụ, một vài network plugin của cụm yêu cầu điều này. Bạn phải
làm điều này cho đến khi sự hỗ trợ SELinux được cải thiện trong kubelet.Thêm kho lưu trữ yum của Kubernetes. Tham số exclude trong
định nghĩa kho lưu trữ đảm bảo rằng các package liên quan tới Kubernetes
không được nâng cấp bởi việc chạy yum update vì có một quy trình đặc biệt cần
tuân theo để nâng cấp Kubernetes. Vui lòng chú ý rằng kho lưu trữ này
chỉ có các package cho Kubernetes 1.35; đối với
những phiên bản Kubernetes minor khác, bạn cần phải
thay đổi phiên bản Kubernetes minor trong URL để trùng với phiên bản minor bạn mong muốn
(bạn cũng nên kiểm tra lại rằng bạn đang đọc tài liệu cho phiên bản Kubernetes
mà bạn dự định cài đặt).
# Điều này sẽ ghi đè bất kỳ những cấu hình nào đang có trong /etc/yum.repos.d/kubernetes.repo
cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.35/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.35/rpm/repodata/repomd.xml.key
exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni
EOF
Cài đặt kubelet, kubeadm và kubectl:
sudo yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
(Tùy chọn) Bật dịch vụ kubelet trước khi chạy kubeadm:
sudo systemctl enable --now kubelet
Cài đặt CNI plugin (yêu cầu đối với hầu hết pod network):
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
Tạo thư mục để tải xuống file lệnh:
DOWNLOAD_DIR phải được đặt tới một thư mục có thể ghi.
Nếu bạn đang chạy Flatcar Container Linux, đặt DOWNLOAD_DIR="/opt/bin".DOWNLOAD_DIR="/usr/local/bin"
sudo mkdir -p "$DOWNLOAD_DIR"
Tùy chọn cài đặt crictl (yêu cầu khi tương tác với Container Runtime Interface (CRI), không bắt buộc cho kubeadm):
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
Cài đặt kubeadm, kubelet và thêm systemd service cho kubelet:
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
glibc.Cài đặt kubectl bằng cách làm theo các hướng dẫn trên trang Cài đặt các công cụ.
Một cách tùy chọn, bật dịch vụ kubelet trước khi chạy kubeadm:
sudo systemctl enable --now kubelet
/usr thành một hệ thống file chỉ đọc.
Xem hướng dẫn Khắc phục sự cố Kubeadm
để biết cách thiết lập một thư mục có thể ghi.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ả 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.
Làm cho khớp các cgroup driver của container runtime và kubelet là bắt buộc hoặc nếu không thì tiến trình kubelet sẽ lỗi.
Xem Cấu hình cgroup driver để biết thêm chi tiết.
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.
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:
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.
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.
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.
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:
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.
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:
Bạn cần:
sudo.
sudo trong các ví dụ.kubeadm và kubelet đã được cài đặt trên toàn bộ các máy.Xem thêm Kiến trúc etcd xếp chồng.
Bạn cần:
sudo.
sudo trong các ví dụ.kubeadm và kubelet đã được cài đặt trên toàn bộ các máy.Và bạn cũng cần:
kubeadm và kubelet.Xem thêm Kiến trúc etcd bên ngoài.
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.
Để 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ố.
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.
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.
Thêm các control plane node còn lại vào target group của bộ cân bằng tải.
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.
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).--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.
kubeadm-certs Secret và khóa giải mã sẽ hết hạn sau hai giờ.Á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ó).
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
Đối với từng control plane node bổ sung bạn nên:
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
--control-plane báo cho kubeadm join tạo một control plane mới.--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.
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.
Theo dõi những hướng dẫn này để khởi tạo cụm etcd.
Thiết lập SSH như mô tả tại đây.
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}":
CONTROL_PLANE bằng user@host của control-plane node đầu tiên.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
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_DNSLOAD_BALANCER_PORTETCD_0_IPETCD_1_IPETCD_2_IPNhững bước sau đây tương tự với thiết lập etcd xếp chồng:
Chạy sudo kubeadm init --config kubeadm-config.yaml --upload-certs trên node này.
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.
Áp dụng CNI plugin mà bạn chọn.
Các bước giống với thiết lập etcd xếp chồng:
--certificate-key mặc định sẽ hết hạn sau hai giờ.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
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.
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)
Thêm định danh SSH vào phiên:
ssh-add ~/.ssh/path_to_private_key
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
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
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
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.
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.ssh và scp
có thể đáp ứng yêu cầu này.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.
Cấu hình kubelet để trở thành trình quản lý dịch vụ cho etcd.
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
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
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.keyTạ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
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/
Đả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
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
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
${HOST0} bằng địa chỉ IP của máy chủ bạn đang kiểm tra.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.