本文檔主要根據(jù)k8s官網(wǎng)文檔和其插件的官網(wǎng)文檔，參考部分他人優(yōu)秀經(jīng)驗，在實際操作中逐漸完成，比較詳盡，適合在境內(nèi)學習者和實踐者參考。
實操環(huán)境基于VMware Workstation 17 pro，采用ubuntu22.04操作系統(tǒng)（有時也提到rhel系列系統(tǒng)），采用kubeadm1.27.4（部分地方提到了1.28）部署和初始化集群，采用IPVS做為負載均衡和網(wǎng)絡轉(zhuǎn)發(fā)，采用containerd1.7.3做為容器運行時，選擇calico作為k8s的Pod網(wǎng)絡組件，采用插件Dashboard做為Web控制臺界面，采用Prometheus+Grafana做為監(jiān)控組件。
文檔涉及面廣，雖反復斟酌，也難免疏漏甚至錯誤，歡迎指正。

[基于Ubuntu22.04部署生產(chǎn)級K8S集群v1.27]系列文檔(陸續(xù)發(fā)布中…)
基于Ubuntu22.04部署生產(chǎn)級K8S集群v1.27(規(guī)劃和核心組件部署篇)
基于Ubuntu22.04部署生產(chǎn)級K8S集群v1.27(包管理器Helm3)
基于Ubuntu22.04部署生產(chǎn)級K8S集群v1.27(網(wǎng)絡模型和Calico)
基于Ubuntu22.04部署生產(chǎn)級K8S集群v1.27(集群管理kubectl)
基于Ubuntu22.04部署生產(chǎn)級K8S集群v1.27(日志架構(gòu))
基于Ubuntu22.04部署生產(chǎn)級K8S集群v1.27(集群彈性-Master高可用和etcd集群)
基于Ubuntu22.04部署生產(chǎn)級K8S集群v1.27(服務發(fā)現(xiàn)CoreDNS)
基于Ubuntu22.04部署生產(chǎn)級K8S集群v1.27(儀表板和Dashboard)
基于Ubuntu22.04部署生產(chǎn)級K8S集群v1.27(持久卷)
基于Ubuntu22.04部署生產(chǎn)級K8S集群v1.27(集群監(jiān)控Prometheus&Grafana)

Kubernetes生產(chǎn)級集群規(guī)劃和核心組件部署

一些k8s概念未在本文闡述，官方文檔比較詳盡，但初學者仍然可能比較迷茫，第三方文檔也比較多，主要就靠積累了，將來也準備單獨整理一篇通俗易懂的文檔。
如果k8s各組件、概念還不清，建議先花上20~40小時以上來熟悉，否則直接部署可能更加云里霧里，徒增煩惱。
本文提到的“生產(chǎn)級”，是相對于開發(fā)環(huán)境來講的，可以直接應用于生產(chǎn)環(huán)境，考慮到信息安全，規(guī)劃雖基于生產(chǎn)環(huán)境，實操部分則參照模擬環(huán)境的部署寫作。

參考文檔

重點參考官方文檔：https://kubernetes.io/zh-cn/docs/home/
也參考了一些其它文檔，在本文中均有出處體現(xiàn)。
可以說網(wǎng)上每三方任何文檔都無法超越官方文檔，本文也只能朝著“盡快規(guī)劃和部署生產(chǎn)級集群”的目標，大量引用官方文檔的內(nèi)容或地址，做一些更簡易直接的說明，官方的部分闡述實在精要，缺之恐誤事，就盡量引用，稍加整理，同時提供部署的實踐經(jīng)驗。

在哪里使用k8s

你可以下載 Kubernetes，在本地機器、云或你自己的數(shù)據(jù)中心上部署 Kubernetes 集群。
諸如 kube-apiserver 或 kube-proxy 等某些 Kubernetes 組件可以在集群中以容器鏡像部署。
建議盡可能將 Kubernetes 組件作為容器鏡像運行，并且讓 Kubernetes 管理這些組件。 但是運行容器的相關(guān)組件 —— 尤其是 kubelet，不在此列。

如果你不想自己管理 Kubernetes 集群，則可以選擇托管服務，包括經(jīng)過認證的平臺。

對于你自己管理的集群，官方支持的用于部署 Kubernetes 的工具是 kubeadm。
安裝kubeadm參考：https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/install-kubeadm/

本文部署基于ubuntu22.04，盡可能將 Kubernetes 組件作為容器鏡像運行。

生產(chǎn)環(huán)境考量

官文：https://kubernetes.io/zh-cn/docs/setup/production-environment/
官文中提到了以下，這里略
可用性
規(guī)模
安全性與訪問管理

大規(guī)模集群的注意事項

官文：https://kubernetes.io/zh-cn/docs/setup/best-practices/cluster-large/
部分關(guān)鍵信息如下：
Kubernetes v1.28 單個集群支持的最大節(jié)點數(shù)為 5,000。 更具體地說，Kubernetes 旨在適應滿足以下所有標準的配置：
每個節(jié)點的 Pod 數(shù)量不超過 110
節(jié)點數(shù)不超過 5,000
Pod 總數(shù)不超過 150,000
容器總數(shù)不超過 300,000

其它：
增加云資源的配額。
應該在每個故障區(qū)域至少應運行一個控制平面實例，以提供容錯能力。 Kubernetes 節(jié)點不會自動將流量引向相同故障區(qū)域中的控制平面端點。 但是，你的云供應商可能有自己的機制來執(zhí)行此操作。
為了提高大規(guī)模集群的性能，你可以將事件對象存儲在單獨的專用 etcd 實例中。
對插件資源設(shè)置CPU和內(nèi)存等限制。插件的默認限制通?；趶闹行∫?guī)模 Kubernetes 集群上運行每個插件的經(jīng)驗收集的數(shù)據(jù)。 插件在大規(guī)模集群上運行時，某些資源消耗常常比其默認限制更多。 如果在不調(diào)整這些值的情況下部署了大規(guī)模集群，則插件可能會不斷被殺死，因為它們不斷達到內(nèi)存限制。 或者，插件可能會運行，但由于 CPU 時間片的限制而導致性能不佳。

集群資源規(guī)劃和網(wǎng)絡規(guī)劃

參考：https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/plan-cidr-blocks-for-an-ack-cluster-1 阿里云ACK Kubernetes集群網(wǎng)絡規(guī)劃
一般性業(yè)務小于100個節(jié)點
Terway Pod獨占模式或IPVlan模式的IP分配示例：
專有網(wǎng)絡網(wǎng)段 192.168.0.0/16
虛擬交換機網(wǎng)段 192.168.0.0/19
Pod虛擬交換機網(wǎng)段 192.168.32.0/19 最大可分配Pod地址數(shù) 8192
Service CIDR網(wǎng)段 172.21.0.0/20 最大可分配Service地址數(shù)：4094

可以看出，Service的地址數(shù)一般是小于Pod地址數(shù)的，而kubeadm.yaml中serviceSubnet默認prefixlen是/12，1048576個，百萬多，對一般性業(yè)務來講，這個數(shù)字太大了。

參考https://blog.csdn.net/QW_sunny/article/details/122495071 關(guān)于PodSubnet在kubeadm初始化時的配置
podSubnet至少要包含14個IP地址。

實踐中，參考官文“大規(guī)模集群的注意事項”、“阿里云ACK Kubernetes集群網(wǎng)絡規(guī)劃”，以及默認配置，考慮到pod數(shù)量，應當做好規(guī)劃，大部分場景下，單個集群的node數(shù)量可規(guī)劃在100個左右，pod數(shù)量1萬個，但為了便于記憶，可以直接規(guī)劃為65536個，prefixlen為/16。
配置可像下面這樣：
networking:
podSubnet: 172.28.0.0/16
serviceSubnet: 172.29.0.0/16

Calico插件在初始化時，注意calico.yaml中的CALICO_IPV4POOL_CIDR配置，應該和kubeadm.yaml中podSubnet配置一樣

安裝集群核心組件

宿主機系統(tǒng)必要的初始配置

這里講的宿主機是運行k8s集群的操作系統(tǒng)主機，即可以是vmware虛擬機、物理機或云主機，我們這里是vmware虛擬機ubuntu22.04。

宿主機配置

官文中提到了安裝kubeadm最低配置是2核2G。
控制平面2核4G，至少1臺，
每臺節(jié)點2核2G，共2臺，
每臺宿主機磁盤推薦40G以上。

ubuntu安裝過程

省略
安裝過程建議不要分配swap，它會造成kubelet不能正常工作，即使分配了，也必須刪除或關(guān)閉。
做好必要的初始配置和安全基線加固（未來將準備一篇專門的文檔來做這部分工作）

更換國內(nèi)鏡像源

vi /etc/apt/sources.list

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
deb http://mirrors.aliyun.com/ubuntu jammy main restricted
# deb-src http://mirrors.aliyun.com/ubuntu jammy main restricted

## Major bug fix updates produced after the final release of the
## distribution.
deb http://mirrors.aliyun.com/ubuntu jammy-updates main restricted
# deb-src http://mirrors.aliyun.com/ubuntu jammy-updates main restricted

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
deb http://mirrors.aliyun.com/ubuntu jammy universe
# deb-src http://mirrors.aliyun.com/ubuntu jammy universe
deb http://mirrors.aliyun.com/ubuntu jammy-updates universe
# deb-src http://mirrors.aliyun.com/ubuntu jammy-updates universe

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team, and may not be under a free licence. Please satisfy yourself as to
## your rights to use the software. Also, please note that software in
## multiverse WILL NOT receive any review or updates from the Ubuntu
## security team.
deb http://mirrors.aliyun.com/ubuntu jammy multiverse
# deb-src http://mirrors.aliyun.com/ubuntu jammy multiverse
deb http://mirrors.aliyun.com/ubuntu jammy-updates multiverse
# deb-src http://mirrors.aliyun.com/ubuntu jammy-updates multiverse

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
deb http://mirrors.aliyun.com/ubuntu jammy-backports main restricted universe multiverse
# deb-src http://mirrors.aliyun.com/ubuntu jammy-backports main restricted universe multiverse

deb http://mirrors.aliyun.com/ubuntu jammy-security main restricted
# deb-src http://mirrors.aliyun.com/ubuntu jammy-security main restricted
deb http://mirrors.aliyun.com/ubuntu jammy-security universe
# deb-src http://mirrors.aliyun.com/ubuntu jammy-security universe
deb http://mirrors.aliyun.com/ubuntu jammy-security multiverse
# deb-src http://mirrors.aliyun.com/ubuntu jammy-security multiverse

sudo apt update

常用軟件包安裝

sudo apt-get install vim wget netstat curl inetutils-ping telnet lrzsz

暫時關(guān)閉防火墻

sudo ufw status # ufw（如果安裝了）查看當前的防火墻狀態(tài)：inactive狀態(tài)是防火墻關(guān)閉狀態(tài) active是開啟狀態(tài)。
sudo ufw enable | disable # 啟動、關(guān)閉防火墻

禁用SELINUX

sudo setenforce 0
sudo vim /etc/selinux/config
修改如下
SELINUX=disabled

時區(qū)設(shè)置和時間同步

sudo cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
配置好時間同步，vmware虛擬機建議安裝好VMwareTools，可設(shè)置好時間和宿主機同步，即使宿主機休眠也不影響虛擬機的時間。
其它場景可配置好NTP時間同步
時間不同步會出error

設(shè)備主機名

在/etc/hosts中添加下列解析，例：
192.168.130.88 k8smaster.loadbalancer.local
192.168.130.88 k8smaster01
192.168.130.89 k8snode001
192.168.130.90 k8snode002
部署集群前配置好主機名是必要的，部署好之后再來改就很麻煩了。
修改系統(tǒng)主機名，執(zhí)行下面的命令，包括會自動修改/etc/hostname中的內(nèi)容，以控制平面的為例：
hostname=k8smaster01
sudo hostnamectl set-hostname $hostname
sudo hostnamectl set-hostname $hostname --pretty
sudo hostnamectl set-hostname $hostname --static
sudo hostnamectl set-hostname $hostname --transient

簡要關(guān)系圖

k8s集群master和worker節(jié)點主機名修改

修改master 節(jié)點的主機名

不建議修改 master 節(jié)點的主機名，因為 Kubernetes 集群中的許多組件都會使用主機名來進行通信和識別。
如果您修改了 master 節(jié)點的主機名，可能會導致某些組件無法正常工作，從而影響整個集群的健康狀態(tài)。
如果您確實需要修改主機名，建議在修改前備份好相關(guān)配置文件，并且在修改后進行全面的測試和驗證。

證書簽發(fā)也跟主機名有關(guān)。
在 Kubernetes 集群中，每個節(jié)點都需要使用 TLS 證書來進行安全通信。
這些證書通常會包含節(jié)點的主機名信息，用于驗證通信的身份。
如果您修改了節(jié)點的主機名，可能會導致證書無法正常驗證，從而影響節(jié)點間的安全通信。
因此，在修改節(jié)點主機名時，還需要相應地更新證書信息，以確保節(jié)點間的安全通信能夠正常工作。
openssl x509 -noout -text -in /etc/kubernetes/pki/apiserver.crt

修改節(jié)點名稱

參考：https://blog.csdn.net/weixin_33858485/article/details/92386452 k8s集群修改節(jié)點和master的hostname之后需要如何調(diào)整
修改節(jié)點名稱還要修改calico服務中的主機名

修改主機名總結(jié)

從以上分享的經(jīng)驗來看，無論是修改master還是worker節(jié)點主機名，都是非常麻煩的，如果是生產(chǎn)環(huán)境，不建議修改，如果是初始部署的實驗環(huán)境，或者不必保留數(shù)據(jù)的集群，最直接的辦法就是，按照“清理節(jié)點”的步驟，清理后，再重新初始化節(jié)點，重建集群。

綜上，鑒于修改主機名的困難，應該在創(chuàng)建集群時，就把主機名規(guī)劃好，配置好。

安裝kubeadm

準備工作

參考：https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/install-kubeadm/
一臺兼容的 Linux 主機。Kubernetes 項目為基于 Debian 和 Red Hat 的 Linux 發(fā)行版以及一些不提供包管理器的發(fā)行版提供通用的指令。
每臺機器 2 GB 或更多的 RAM（如果少于這個數(shù)字將會影響你應用的運行內(nèi)存）。
CPU 2 核心及以上。
集群中的所有機器的網(wǎng)絡彼此均能相互連接（公網(wǎng)和內(nèi)網(wǎng)都可以）。
節(jié)點之中不可以有重復的主機名、MAC 地址或 product_uuid。
開啟機器上的某些端口。
禁用交換分區(qū)。為了保證 kubelet 正常工作，你必須禁用交換分區(qū)。例如，sudo swapoff -a 將暫時禁用交換分區(qū)。要使此更改在重啟后保持不變，請確保在如 /etc/fstab、systemd.swap 等配置文件中禁用交換分區(qū)，具體取決于你的系統(tǒng)如何配置。

準備工作的具體指令參考

確保每個節(jié)點上 MAC 地址和 product_uuid 的唯一性
你可以使用命令 ip link 或 ifconfig -a 來獲取網(wǎng)絡接口的 MAC 地址
可以使用 sudo cat /sys/class/dmi/id/product_uuid 命令對 product_uuid 校驗
一般來講，硬件設(shè)備會擁有唯一的地址，但是有些虛擬機的地址可能會重復。 Kubernetes 使用這些值來唯一確定集群中的節(jié)點。 如果這些值在每個節(jié)點上不唯一，可能會導致安裝失敗。

禁用所有swap交換分區(qū)
sudo swapoff -a

了解端口和協(xié)議
當你在一個有嚴格網(wǎng)絡邊界的環(huán)境里運行 Kubernetes，例如擁有物理網(wǎng)絡防火墻或者擁有公有云中虛擬網(wǎng)絡的自有數(shù)據(jù)中心， 了解 Kubernetes 組件使用了哪些端口和協(xié)議是非常有用的。
官文：https://kubernetes.io/zh-cn/docs/reference/networking/ports-and-protocols/
控制面（Master）
協(xié)議 方向 端口范圍 目的 使用者
TCP 入站 6443 Kubernetes API server 所有
TCP 入站 2379-2380 etcd server client API kube-apiserver, etcd
TCP 入站 10250 Kubelet API 自身, 控制面
TCP 入站 10259 kube-scheduler 自身
TCP 入站 10257 kube-controller-manager 自身

工作節(jié)點（Worker node）
協(xié)議 方向 端口范圍 目的 使用者
TCP 入站 10250 Kubelet API 自身, 控制面
TCP 入站 30000-32767 NodePort Services（默認端口范圍） 所有

可以使用 netcat 之類的工具來檢查端口是否啟用，例如：
nc 127.0.0.1 6443

配置服務器支持開啟ipvs的前提條件

kube-proxy開啟ipvs的前提需要加載以下的內(nèi)核模塊:
ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_sh
nf_conntrack

sudo vi /etc/modules-load.d/ipvs.conf
添加上述模塊
sudo modprobe – ip_vs
sudo modprobe – ip_vs_rr
sudo modprobe – ip_vs_wrr
sudo modprobe – ip_vs_sh
sudo modprobe – nf_conntrack
lsmod | grep -e ip_vs -e nf_conntrack
接下來還需要確保各個節(jié)點上已經(jīng)安裝了ipset軟件包，為了便于查看ipvs的代理規(guī)則，最好安裝一下管理工具ipvsadm。
如果沒有安裝好ipvs相關(guān)模塊，則即使kube-proxy的配置開啟了ipvs模式，也會退回到iptables模式。

安裝容器運行時

官文：https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/
https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime

說明：為什么要安裝容器運行時？
“容器運行時”（Container Runtime）是負責運行容器的軟件，以使 Pod 可以運行在上面。
默認情況下，Kubernetes 使用 容器運行時接口（Container Runtime Interface，CRI） 來與你所選擇的容器運行時交互。
如果你不指定運行時，kubeadm 會自動嘗試通過掃描已知的端點列表來檢測已安裝的容器運行時。
如果檢測到有多個或者沒有容器運行時，kubeadm 將拋出一個錯誤并要求你指定一個想要使用的運行時。
Docker Engine 沒有實現(xiàn) CRI， 而這是容器運行時在 Kubernetes 中工作所需要的。 為此，必須安裝一個額外的服務 cri-dockerd。 cri-dockerd 是一個基于傳統(tǒng)的內(nèi)置 Docker 引擎支持的項目， 它在 1.24 版本從 kubelet 中移除。
v1.24 之前的 Kubernetes 版本直接集成了 Docker Engine 的一個組件，名為 dockershim。 這種特殊的直接整合不再是 Kubernetes 的一部分 （這次刪除被作為 v1.20 發(fā)行版本的一部分宣布）。

容器運行時有下列：
containerd （推薦）
Dockershim （不推薦，且k8s1.24開始棄用）
CRI-O （推薦）
cri-dockerd （不推薦）
Mirantis

來了解一下：Kubernetes、Docker、Dockershim、Containerd、runC、CRI、OCI的關(guān)系
參考：https://zhuanlan.zhihu.com/p/630976577
CRI可以實現(xiàn)kubelet對containerd、CRI-O的統(tǒng)一管理。同時，Kubernetes 1.24將dockershim 組件從 kubelet 中刪除后，也建議用戶使用更加輕量的容器運行時 containerd 或 CRI-O。
雖然 dockershim 組件在 Kubernetes v1.24 發(fā)行版本中已被移除。不過來自第三方的替代品 cri-dockerd 可以適配器允許你通過 容器運行時接口（Container Runtime Interface，CRI） 來使用 Docker Engine（并不建議使用，除非有特殊的需求）。
對于Docker生成的鏡像，也并不受任何影響，Docker 對鏡像的構(gòu)建是符合 OCI 標準的 (runC 也是 Docker 獨立出去的)，鏡像適用于所有 CRI 容器運行時。

參考：https://cloud.tencent.com/developer/article/1791730
有評論：從我個人角度考慮的話，我個人的選擇是：containerd，他速度快，配置方便，相當可靠和安全，不過 cri-o 已經(jīng)支持 cgroupsv2 了，所以如果我使用 fedora 或者 centos8 的話我會優(yōu)先選擇 cri-o。

本文檔考慮containerd做為CRI。

轉(zhuǎn)發(fā) IPv4 并讓 iptables 看到橋接流量

（這是安裝和配置容器運行時的先決條件）

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

# 設(shè)置所需的 sysctl 參數(shù)，參數(shù)在重新啟動后保持不變
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

# 應用 sysctl 參數(shù)而不重新啟動
sudo sysctl --system

通過運行以下指令確認 br_netfilter 和 overlay 模塊被加載：
lsmod | grep br_netfilter
lsmod | grep overlay

通過運行以下指令確認 net.bridge.bridge-nf-call-iptables、net.bridge.bridge-nf-call-ip6tables 和 net.ipv4.ip_forward 系統(tǒng)變量在你的 sysctl 配置中被設(shè)置為 1：

cgroup 驅(qū)動

（容器運行時的驅(qū)動，位于最底層）
在 Linux 上，控制組（CGroup）用于限制分配給進程的資源。
kubelet 和底層容器運行時都需要對接控制組來強制執(zhí)行 為 Pod 和容器管理資源 并為諸如 CPU、內(nèi)存這類資源設(shè)置請求和限制。若要對接控制組，kubelet 和容器運行時需要使用一個 cgroup 驅(qū)動。 關(guān)鍵的一點是 kubelet 和容器運行時需使用相同的 cgroup 驅(qū)動并且采用相同的配置。
可用的 cgroup 驅(qū)動有兩個：
cgroupfs
systemd
當 systemd 是初始化系統(tǒng)時， 不 推薦使用 cgroupfs 驅(qū)動，因為 systemd 期望系統(tǒng)上只有一個 cgroup 管理器。
使用 cgroup v2， 則應用 systemd cgroup 驅(qū)動取代 cgroupfs
要將 systemd 設(shè)置為 cgroup 驅(qū)動，需編輯 KubeletConfiguration 的 cgroupDriver 選項，并將其設(shè)置為 systemd。例如：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
…
cgroupDriver: systemd

說明：從 v1.22 開始，在使用 kubeadm 創(chuàng)建集群時，如果用戶沒有在 KubeletConfiguration 下設(shè)置 cgroupDriver 字段，kubeadm 默認使用 systemd。

如果你將 systemd 配置為 kubelet 的 cgroup 驅(qū)動，你也必須將 systemd 配置為容器運行時的 cgroup 驅(qū)動。

CRI 版本支持

你的容器運行時必須至少支持 v1alpha2 版本的容器運行時接口。

Kubernetes 從 1.26 版本開始僅適用于 v1 版本的容器運行時（CRI）API。早期版本默認為 v1 版本， 但是如果容器運行時不支持 v1 版本的 API， 則 kubelet 會回退到使用（已棄用的）v1alpha2 版本的 API。

安裝containerd做為容器運行時

containerd官網(wǎng)地址：https://github.com/containerd/containerd/blob/main/docs/getting-started.md
containerd官網(wǎng)提供了多種安裝方式，

選項一，二進制包安裝
ubuntu和rhel系可以用二進制包安裝，其它系統(tǒng)可用源碼包安裝，下面是二進制安裝：

Step 1: Installing containerd
下載地址：https://github.com/containerd/containerd/releases
wget https://github.com/containerd/containerd/releases/download/v1.7.3/containerd-1.7.3-linux-amd64.tar.gz
sudo tar Cxzvf /usr/local containerd-1.7.3-linux-amd64.tar.gz

If you intend to start containerd via systemd, you should also download the containerd.service unit file from https://raw.githubusercontent.com/containerd/containerd/main/containerd.service into /usr/local/lib/systemd/system/containerd.service, and run the following commands:
wget https://raw.githubusercontent.com/containerd/containerd/main/containerd.service
sudo mv containerd.service /usr/lib/systemd/system/ # ubuntu是這個路徑，rhel系是官文中提到的路徑
sudo systemctl daemon-reload && sudo systemctl enable --now containerd
systemctl status containerd

Step 2: Installing runc
curl -LO https://github.com/opencontainers/runc/releases/download/v1.1.8/runc.amd64 && sudo install -m 755 runc.amd64 /usr/local/sbin/runc
The binary is built statically and should work on any Linux distribution.

Step 3: Installing CNI plugins
wget https://github.com/containernetworking/plugins/releases/download/v1.3.0/cni-plugins-linux-amd64-v1.3.0.tgz
sudo tar Cxzvf /opt/cni/bin cni-plugins-linux-amd64-v1.3.0.tgz
The binaries are built statically and should work on any Linux distribution.

選項二：deb或dnl安裝
The containerd.io packages in DEB and RPM formats are distributed by Docker (not by the containerd project). See the Docker documentation
https://docs.docker.com/engine/install/ubuntu/
https://docs.docker.com/engine/install/centos/
就是deb或rpm包安裝docker環(huán)境的過程中，就可以順便裝上了containerd.io，很快，例如：
先有一些卸載老包的步驟，然后

sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update 
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo docker run hello-world

經(jīng)驗：如果按二進制包安裝了，再通過dnl或yum安裝，會有提示，容器運行時保持當前配置（/etc/containerd/config.toml）還是安裝配置，為了穩(wěn)定，一般選擇之前的配置，即當前配置。

containerd的配置

修改containerd的配置，其中containerd默認從k8s官網(wǎng)拉取鏡像，幾乎不會成功，需變更為境內(nèi)源。

sudo mkdir -p /etc/containerd #創(chuàng)建一個目錄用于存放containerd的配置文件
containerd config default | sudo tee /etc/containerd/config.toml #把containerd配置導出到文件
sudo vim /etc/containerd/config.toml #修改配置文件
[plugins.“io.containerd.grpc.v1.cri”]
…
sandbox_image = “registry.aliyuncs.com/google_containers/pause:3.9” #搜索sandbox_image，把原來的registry.k8s.io/pause:3.8改為"registry.aliyuncs.com/google_containers/pause:3.9"
[plugins.“io.containerd.grpc.v1.cri”.containerd.runtimes.runc.options]
…
SystemdCgroup = true #搜索SystemdCgroup，把這個false改為true

[plugins.“io.containerd.grpc.v1.cri”.registry]
config_path = “/etc/containerd/certs.d” #搜索config_path，配置鏡像加速地址（這是一個目錄下面創(chuàng)建）

鏡像加速配置

創(chuàng)建鏡像加速的目錄
sudo mkdir /etc/containerd/certs.d/docker.io -pv

#配置加速
sudo cat > /etc/containerd/certs.d/docker.io/hosts.toml <<\EOF
server = “https://docker.io”
[host.“https://xxx.mirror.aliyuncs.com”]
capabilities = [“pull”, “resolve”]
EOF
最好檢查一下hosts.toml的實際內(nèi)容，其中xxx.mirror.aliyuncs.com在aliyun.com上面申請。

加載containerd的內(nèi)核模塊

（如果/etc/modules-load.d/k8s.conf中配置了，不必再重復配置）
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter

#重啟containerd
sudo systemctl restart containerd
systemctl status containerd

測驗containerd

拉取鏡像，測試containerd是否能創(chuàng)建和啟動成功
說明：ctr命令是containerd CLI，類似于docker命令，但又不是docker的命令。containerd和cri-docker是不同的容器運行時。
sudo ctr i pull docker.io/library/nginx:alpine # 能正常拉取鏡像說明沒啥問題
sudo ctr images ls # 查看鏡像
sudo ctr c create --net-host docker.io/library/nginx:alpine nginx # 創(chuàng)建容器
sudo ctr task start -d nginx # 啟動容器，正常說明containerd沒啥問題
sudo ctr containers ls # 查看容器
sudo ctr tasks kill -s SIGKILL nginx # 終止容器
sudo ctr containers rm nginx # 刪除容器

crictl手動操作容器運行時containerd

containerd 也有類似 docker 的 CLI 工具，改為 crictl pull 也可以拉鏡像，參數(shù)比ctr更多。如果能操作節(jié)點，是可以在每個節(jié)點上都提前拉取鏡像，然后配置 imagePullPolicy為IfNotPresent。
官文：https://kubernetes.io/zh-cn/docs/concepts/containers/images/#using-a-private-registry

如果系統(tǒng)中存在多個容器運行時，需要先配置
vi /etc/crictl.yaml
內(nèi)容如下

runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock
timeout: 10
debug: false

使用 containerd 作為 CRI 運行時的必要步驟

如果你從軟件包（例如，RPM 或者 .deb）中安裝 containerd，你可能會發(fā)現(xiàn)其中默認禁止了 CRI 集成插件。
你需要啟用 CRI 支持才能在 Kubernetes 集群中使用 containerd。 要確保 cri 沒有出現(xiàn)在 /etc/containerd/config.toml 文件中 disabled_plugins 列表內(nèi)。如果你更改了這個文件，也請記得要重啟 containerd。
如果你在初次安裝集群后或安裝 CNI 后遇到容器崩潰循環(huán)，則隨軟件包提供的 containerd 配置可能包含不兼容的配置參數(shù)?？紤]按照 getting-started.md 中指定的 containerd config default > /etc/containerd/config.toml 重置 containerd 配置，然后相應地設(shè)置上述配置參數(shù)。
如果你應用此更改，請確保重新啟動 containerd：
sudo systemctl restart containerd

安裝kubeadm、kubelet、kubectl

你需要在每臺機器上安裝以下的軟件包：
kubeadm：用來初始化集群的指令。
kubelet：在集群中的每個節(jié)點上用來啟動 Pod 和容器等。
kubectl：用來與集群通信的命令行工具。
kubeadm 不能幫你安裝或者管理 kubelet 或 kubectl， 所以你需要確保它們與通過 kubeadm 安裝的控制平面的版本相匹配。 如果不這樣做，則存在發(fā)生版本偏差的風險，可能會導致一些預料之外的錯誤和問題。 然而，控制平面與 kubelet 之間可以存在一個次要版本的偏差，但 kubelet 的版本不可以超過 API 服務器的版本。 例如，1.7.0 版本的 kubelet 可以完全兼容 1.8.0 版本的 API 服務器，反之則不可以。

更新 apt 包索引并安裝使用 Kubernetes apt 倉庫所需要的包：
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl

下載 Google Cloud 公開簽名秘鑰：
curl -fsSL https://dl.k8s.io/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg
或
curl https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | sudo apt-key add

添加 Kubernetes apt 倉庫：

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

或

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] http://mirrors.ustc.edu.cn/kubernetes/apt kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

或

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] http://mirrors.aliyun.com/kubernetes/apt kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl # 鎖定版本
kubectl
kubectl version --short

輸出：
Client Version: v1.27.4
Kustomize Version: v5.0.1

kubeadm token list

sudo systemctl enable kubelet.service # 如果開啟了swap就會報錯

使用 kubeadm 創(chuàng)建集群

https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/
使用 kubeadm，你能創(chuàng)建一個符合最佳實踐的最小化 Kubernetes 集群。 事實上，你可以使用 kubeadm 配置一個通過 Kubernetes 一致性測試的集群。 kubeadm 還支持其他集群生命周期功能， 例如啟動引導令牌和集群升級。

你可以在各種機器上安裝和使用 kubeadm：筆記本電腦， 一組云服務器

本節(jié)目標

• 安裝單個控制平面的 Kubernetes 集群
• 在集群上安裝 Pod 網(wǎng)絡，以便你的 Pod 可以相互連通

主機準備

在所有主機上安裝 容器運行時 和 kubeadm

準備所需的容器鏡像（可選）

這個步驟是可選的，只適用于你希望 kubeadm init 和 kubeadm join 不去下載存放在 registry.k8s.io 上的默認的容器鏡像的情況。
當你在離線的節(jié)點上創(chuàng)建一個集群的時候，Kubeadm 有一些命令可以幫助你預拉取所需的鏡像。 閱讀離線運行 kubeadm 獲取更多的詳情。
Kubeadm 允許你給所需要的鏡像指定一個自定義的鏡像倉庫。 閱讀使用自定義鏡像 獲取更多的詳情。

初始化控制平面節(jié)點

控制平面節(jié)點是運行控制平面組件的機器， 包括 etcd（集群數(shù)據(jù)庫） 和 API 服務器 （命令行工具 kubectl 與之通信）。

• （推薦）如果計劃將單個控制平面 kubeadm 集群升級成高可用， 你應該指定 --control-plane-endpoint 為所有控制平面節(jié)點設(shè)置共享端點。 端點可以是負載均衡器的 DNS 名稱或 IP 地址。（kubeadm 不支持將沒有 --control-plane-endpoint 參數(shù)的單個控制平面集群轉(zhuǎn)換為高可用性集群。）
• 選擇一個 Pod 網(wǎng)絡插件，并驗證是否需要為 kubeadm init 傳遞參數(shù)。 根據(jù)你選擇的第三方網(wǎng)絡插件，你可能需要設(shè)置 --pod-network-cidr 的值。 請參閱安裝 Pod 網(wǎng)絡附加組件。
• （可選）kubeadm 試圖通過使用已知的端點列表來檢測容器運行時。 使用不同的容器運行時或在預配置的節(jié)點上安裝了多個容器運行時，請為 kubeadm init 指定 --cri-socket 參數(shù)。 請參閱安裝運行時。
• （可選）除非另有說明，否則 kubeadm 使用與默認網(wǎng)關(guān)關(guān)聯(lián)的網(wǎng)絡接口來設(shè)置此控制平面節(jié)點 API server 的廣播地址。 要使用其他網(wǎng)絡接口，請為 kubeadm init 設(shè)置 --apiserver-advertise-address= 參數(shù)。 要部署使用 IPv6 地址的 Kubernetes 集群， 必須指定一個 IPv6 地址，例如 --apiserver-advertise-address=2001:db8::101。

結(jié)合一份配置文件來使用 kubeadm init
官文：https://kubernetes.io/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file
通過一份配置文件而不是使用命令行參數(shù)來配置 kubeadm init 命令是可能的， 但是一些更加高級的功能只能夠通過配置文件設(shè)定。
先打印集群初始化默認的使用的配置，在此基礎(chǔ)上定制新的kubeadm.yaml：
kubeadm config print init-defaults --component-configs KubeletConfiguration > ~/kubeadm.yaml

其中
name 需要變更為master的名稱，例如k8smaster01
advertiseAddress需要替換master節(jié)點IP
criSocket是cri的套接字，containerd是unix:///var/run/containerd/containerd.sock
imageRepository是鏡像源，registry.k8s.io這個源要可換成阿里的：registry.aliyuncs.com/google_containers
cgroupDriver設(shè)置kubelet的cgroupDriver為systemd
clusterDNS的IP以0.10結(jié)尾為佳，不然初始化過程中也會有提示，指定另一個IP也未嘗不可，但未實踐過，還是盡量聽程序的建議吧。
networking的podSubnet: 172.28.0.0/16，serviceSubnet: 172.29.0.0/16。
controlPlaneEndpoint就是創(chuàng)建多個控制面板所必要的參數(shù)，設(shè)為k8smaster.loadbalancer.local:6443

設(shè)置kube-proxy代理模式為ipvs，追加如下：

---
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: ipvs

關(guān)于kubeadm配置的更多幫助，見官文：https://kubernetes.io/zh-cn/docs/reference/config-api/kubeadm-config.v1beta3/

k8s1.27.4一次完整的kubeadm.yaml內(nèi)容：

apiVersion: kubeadm.k8s.io/v1beta3
bootstrapTokens:
- groups:
  - system:bootstrappers:kubeadm:default-node-token
  token: abcdef.0123456789abcdef
  ttl: 24h0m0s
  usages:
  - signing
  - authentication
kind: InitConfiguration
localAPIEndpoint:
  advertiseAddress: 192.168.130.88
  bindPort: 6443
nodeRegistration:
  criSocket: unix:///var/run/containerd/containerd.sock
  imagePullPolicy: IfNotPresent
  name: k8smaster01
  taints: null
---
apiServer:
  timeoutForControlPlane: 4m0s
apiVersion: kubeadm.k8s.io/v1beta3
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controllerManager: {}
dns: {}
etcd:
  local:
    dataDir: /var/lib/etcd
imageRepository: registry.aliyuncs.com/google_containers
kind: ClusterConfiguration
kubernetesVersion: 1.27.0
networking:
  dnsDomain: cluster.local
  podSubnet: 172.28.0.0/16
  serviceSubnet: 172.29.0.0/16
controlPlaneEndpoint: k8smaster.loadbalancer.local:6443
scheduler: {}
---
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
  anonymous:
    enabled: false
  webhook:
    cacheTTL: 0s
    enabled: true
  x509:
    clientCAFile: /etc/kubernetes/pki/ca.crt
authorization:
  mode: Webhook
  webhook:
    cacheAuthorizedTTL: 0s
    cacheUnauthorizedTTL: 0s
cgroupDriver: systemd
clusterDNS:
- 172.29.0.10
clusterDomain: cluster.local
containerRuntimeEndpoint: ""
cpuManagerReconcilePeriod: 0s
evictionPressureTransitionPeriod: 0s
fileCheckFrequency: 0s
healthzBindAddress: 127.0.0.1
healthzPort: 10248
httpCheckFrequency: 0s
imageMinimumGCAge: 0s
kind: KubeletConfiguration
logging:
  flushFrequency: 0
  options:
    json:
      infoBufferSize: "0"
  verbosity: 0
memorySwap: {}
nodeStatusReportFrequency: 0s
nodeStatusUpdateFrequency: 0s
resolvConf: /run/systemd/resolve/resolv.conf
rotateCertificates: true
runtimeRequestTimeout: 0s
shutdownGracePeriod: 0s
shutdownGracePeriodCriticalPods: 0s
staticPodPath: /etc/kubernetes/manifests
streamingConnectionIdleTimeout: 0s
syncFrequency: 0s
volumeStatsAggPeriod: 0s
---
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: ipvs

這里定制了imageRepository為阿里云的registry，避免因gcr被墻，無法直接拉取鏡像。criSocket設(shè)置了容器運行時為containerd。 同時設(shè)置kubelet的cgroupDriver為systemd，設(shè)置kube-proxy代理模式為ipvs。

集群初始化完成后，可查看到kube-proxy代理模式
參考：https://blog.csdn.net/wy_hhxx/article/details/119858961
kubectl get pod -n kube-system # 查看kube-proxy的Name
kubectl logs kube-proxy-6vfqw -n kube-system # 根據(jù)剛才查到的kube-proxy的Name，查詢其日志
在日志中可以看到用的ipvs還是iptables。

在開始初始化集群之前可以使用kubeadm config images pull --config kubeadm.yaml預先在各個服務器節(jié)點上拉取所k8s需要的容器鏡像。
sudo kubeadm config images pull --config kubeadm.yaml

接下來使用kubeadm初始化集群執(zhí)行下面的命令：
sudo kubeadm init --config kubeadm.yaml --control-plane-endpoint=“k8smaster.loadbalancer.local:6443” --upload-certs
這里使用了–control-plane-endpoint，是為了將來可以升級為高可用集群，即多個控制平面，如果在配置文件中配置了，這里就不必使用了，如下：
sudo kubeadm init --config kubeadm.yaml --upload-certs
創(chuàng)建高可用集群參考官文：https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/high-availability/
將會整理文檔[基于Ubuntu22.04部署生產(chǎn)級K8S集群v1.27(集群彈性-Master高可用和etcd集群)]

根據(jù)輸出的內(nèi)容基本上可以看出手動初始化安裝一個Kubernetes集群所需要的關(guān)鍵步驟。 其中有以下關(guān)鍵內(nèi)容：

[certs]生成相關(guān)的各種證書
[kubeconfig]生成相關(guān)的kubeconfig文件
[kubelet-start] 生成kubelet的配置文件"/var/lib/kubelet/config.yaml"
[control-plane]使用/etc/kubernetes/manifests目錄中的yaml文件創(chuàng)建apiserver、controller-manager、scheduler的靜態(tài)pod
[bootstraptoken]生成token記錄下來，后邊使用kubeadm join往集群中添加節(jié)點時會用到
[addons]安裝基本插件:CoreDNS, kube-proxy

成功后有下列提示：

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of the control-plane node running the following command on each as root:

  kubeadm join k8smaster.loadbalancer.local:6443 --token [token] \
        --discovery-token-ca-cert-hash sha256:[sha256] \
        --control-plane --certificate-key [key]

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 --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 k8smaster.loadbalancer.local:6443 --token [token] \
        --discovery-token-ca-cert-hash sha256:[sha256] 

可以看到有加入另一個控制平面的命令，其中token和sha256被我替換掉了，請注意你實際環(huán)境中的值。

開始使用集群前的操作

mkdir -p $HOME/.kube                                        #復制上面提示照著做即可
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config    #復制上面提示照著做即可
sudo chown $(id -u):$(id -g) $HOME/.kube/config            #復制上面提示照著做即可
export KUBECONFIG=/etc/kubernetes/admin.conf

查看一下集群狀態(tài)，確認個組件都處于healthy狀態(tài)
kubectl get cs # 默認不要用sudo

報錯：
E0812 15:44:43.823568 28146 memcache.go:265] could not get current server API group list: Get “http://localhost:8080/api?timeout=32s”: dial tcp 127.0.0.1:8080: connect: connection refused
處理：在/etc/systemd/system/kubelet.service.d/10-kubeadm.conf中添加：
Environment=“KUBELET_SYSTEM_PODS_ARGS=–pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true --fail-swap-on=false”
重啟kubelet
sudo systemctl restart kubelet
未成功
重啟系統(tǒng)，再運行kubectl get cs，成功，該現(xiàn)象可復現(xiàn)，原因暫未知

初始化完成后有下列提示：

接下來可以部署網(wǎng)絡插件：
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  /docs/concepts/cluster-administration/addons/

添加節(jié)點：
You can now join any number of machines by running the following on each node
as root:
  kubeadm join <control-plane-host>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>

其中token和sha256被我替換掉了，請注意你實際環(huán)境中的值。

添加節(jié)點

先總結(jié)一下：
2023年的模擬環(huán)境中，是在后續(xù)插件（包管理器helm3、網(wǎng)絡、CoreDNS等）安裝完成后，再克隆出的node，然后添加節(jié)點，節(jié)點是不需要初始化控制平面的（kubeadm init）。
節(jié)點有兩個部署思路：

• 控制平面節(jié)點（master）完成必要安裝和配置后，包括網(wǎng)絡插件，克隆出節(jié)點，確保UUID、MAC、IP、HOSTNAME的不同，在節(jié)點上執(zhí)行kubeadm reset等重置操作，詳見卸載集群筆記，再做為節(jié)點加入集群；
• 節(jié)點單獨部署，參照控制平面節(jié)點的部署，安裝好容器運行時，和kubeadm、kubelet、kubectl（kubeadm也是要安裝的，官文中提到過所有主機上安裝kubeadm），但節(jié)點系統(tǒng)不執(zhí)行初始化控制平面，再部署好必要插件比如網(wǎng)絡和存儲插件，最后加入集群，（該方法暫未實踐，網(wǎng)絡插件和DNS插件均是以POD方式運行的）；

2023年實際操作：
克隆出2臺k8snode, 添加到Kubernetes集群中，分別做為k8snode002, k8snode003，在上面執(zhí)行初始化時產(chǎn)生的“kubeadm join”指令（默認24小時內(nèi)，超時后需要重新生成token）。

加入節(jié)點時報錯：
error execution phase preflight: [preflight] Some fatal errors occurred:
[ERROR FileAvailable–etc-kubernetes-kubelet.conf]: /etc/kubernetes/kubelet.conf already exists
[ERROR Port-10250]: Port 10250 is in use
[ERROR FileAvailable–etc-kubernetes-pki-ca.crt]: /etc/kubernetes/pki/ca.crt already exists
參考：https://www.cnblogs.com/wangzy-Zj/p/13130877.html
重置后重新加入
sudo kubeadm reset 以及清理網(wǎng)絡規(guī)則和config配置（參照卸載集群，但不要刪除節(jié)點）
由此可知，節(jié)點是只需要部署好節(jié)點的組件即可。

再報錯：could not find a JWS signature in the cluster-info ConfigMap for token ID “abcdef”
參考：https://www.cnblogs.com/dream397/p/14922802.html
原因：token 默認有效時間為24小時
處理：重新生成，且可設(shè)置ttl=0表示生成的 token 永不失效
kubeadm token create --print-join-command --ttl=0
sudo kubeadm join 192.168.130.88:6443 --token [token] --discovery-token-ca-cert-hash sha256:xxx --v=5

可在master節(jié)點上執(zhí)行命令查看集群中的節(jié)點：
kubectl get node

重新配置 kubeadm 集群

官文：https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure/
要修改組件配置，你必須手動編輯磁盤上關(guān)聯(lián)的集群對象和文件。
kubeadm 在 ConfigMap 和其他對象中寫入了一組集群范圍的組件配置選項。 這些對象必須手動編輯，可以使用命令 kubectl edit
kubectl edit 命令將打開一個文本編輯器，你可以在其中直接編輯和保存對象。 你可以使用環(huán)境變量 KUBECONFIG 和 KUBE_EDITOR 來指定 kubectl 使用的 kubeconfig 文件和首選文本編輯器的位置。
例如：
KUBECONFIG=/etc/kubernetes/admin.conf KUBE_EDITOR=nano kubectl edit
保存對這些集群對象的任何更改后，節(jié)點上運行的組件可能不會自動更新。 以下步驟將指導你如何手動執(zhí)行該操作。
警告：
ConfigMaps 中的組件配置存儲為非結(jié)構(gòu)化數(shù)據(jù)（YAML 字符串）。 這意味著在更新 ConfigMap 的內(nèi)容時不會執(zhí)行驗證。 你必須小心遵循特定組件配置的文檔化 API 格式， 并避免引入拼寫錯誤和 YAML 縮進錯誤。

應用集群配置更改

更新 ClusterConfiguration
官文：https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure/#%E6%9B%B4%E6%96%B0-clusterconfiguration
在集群創(chuàng)建和升級期間，kubeadm 將其 ClusterConfiguration 寫入 kube-system 命名空間中名為 kubeadm-config 的 ConfigMap。
要更改 ClusterConfiguration 中的特定選項，你可以使用以下命令編輯 ConfigMap：
kubectl edit cm -n kube-system kubeadm-config
說明：
ClusterConfiguration 包括各種影響單個組件配置的選項， 例如 kube-apiserver、kube-scheduler、kube-controller-manager、 CoreDNS、etcd 和 kube-proxy。 對配置的更改必須手動反映在節(jié)點組件上。
在控制平面節(jié)點上反映 ClusterConfiguration 更改
kubeadm 將控制平面組件作為位于 /etc/kubernetes/manifests 目錄中的靜態(tài) Pod 清單進行管理。 對 apiServer、controllerManager、scheduler 或 etcd鍵下的 ClusterConfiguration 的任何更改都必須反映在控制平面節(jié)點上清單目錄中的關(guān)聯(lián)文件中。
在繼續(xù)進行這些更改之前，請確保你已備份目錄 /etc/kubernetes/。
要編寫新證書，你可以使用：
kubeadm init phase certs --config
要在 /etc/kubernetes/manifests 中編寫新的清單文件，你可以使用：
kubeadm init phase control-plane --config
內(nèi)容必須與更新后的 ClusterConfiguration 匹配。 值必須是組件的名稱。
說明：
更新 /etc/kubernetes/manifests 中的文件將告訴 kubelet 重新啟動相應組件的靜態(tài) Pod。 嘗試一次對一個節(jié)點進行這些更改，以在不停機的情況下離開集群。

應用 kubelet 配置更改

kubectl edit cm -n kube-system kubelet-config
反映 kubelet 的更改
登錄到 kubeadm 節(jié)點
運行 kubeadm upgrade node phase kubelet-config 下載最新的 kubelet-config ConfigMap 內(nèi)容到本地文件 /var/lib/kubelet/config.conf
編輯文件 /var/lib/kubelet/kubeadm-flags.env 以使用標志來應用額外的配置，pause鏡像和–container-runtime-endpoint便在這里面。
使用 systemctl restart kubelet 重啟 kubelet 服務
說明：
一次執(zhí)行一個節(jié)點的這些更改，以允許正確地重新安排工作負載。

應用 kube-proxy 配置更改

sudo kubectl edit cm -n kube-system kube-proxy
反映 kube-proxy 的更改
更新 kube-proxy ConfigMap 后，你可以重新啟動所有 kube-proxy Pod：
獲取 Pod 名稱：
kubectl get po -n kube-system | grep kube-proxy
使用以下命令刪除 Pod：
kubectl delete po -n kube-system
將創(chuàng)建使用更新的 ConfigMap 的新 Pod。
說明：
由于 kubeadm 將 kube-proxy 部署為 DaemonSet，因此不支持特定于節(jié)點的配置。

應用 CoreDNS 配置更改

kubeadm 將 CoreDNS 部署為名為 coredns 的 Deployment，并使用 Service kube-dns， 兩者都在 kube-system 命名空間中。
要更新任何 CoreDNS 設(shè)置，你可以編輯 Deployment 和 Service：
kubectl edit deployment -n kube-system coredns
kubectl edit service -n kube-system kube-dns
反映 CoreDNS 的更改
應用 CoreDNS 更改后，你可以刪除 CoreDNS Pod。
獲取 Pod 名稱：
kubectl get po -n kube-system | grep coredns
使用以下命令刪除 Pod：
kubectl delete po -n kube-system
將創(chuàng)建具有更新的 CoreDNS 配置的新 Pod。

卸載集群

官文：https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#tear-down

技術(shù)同行：初始化失?。?運行：sudo kubeadm reset && rm -rf $HOME/.kube/config && rm -rf $HOME/.kube; 再執(zhí)行初始化命令。
實踐：沒有清理iptables 規(guī)則或 IPVS 表，可能留下問題。

如果你在集群中使用了一次性服務器進行測試，則可以關(guān)閉這些服務器，而無需進一步清理。 你可以使用 kubectl config delete-cluster 刪除對集群的本地引用。
但是，如果要更干凈地取消配置集群， 則應首先清空節(jié)點并確保該節(jié)點為空， 然后取消配置該節(jié)點。

刪除節(jié)點

使用適當?shù)膽{證與控制平面節(jié)點通信，驅(qū)逐pod，控制平面節(jié)點上運行：
kubectl drain --delete-emptydir-data --force --ignore-daemonsets

在刪除節(jié)點之前，請重置 kubeadm 安裝的狀態(tài)，在要刪除的節(jié)點上操作：
sudo kubeadm reset

重置過程不會重置或清除 iptables 規(guī)則或 IPVS 表。如果你希望重置 iptables，則必須手動進行（root用戶）：
sudo iptables -F && sudo iptables -t nat -F && sudo iptables -t mangle -F && sudo iptables -X
sudo iptables -vnL

如果要重置 IPVS 表，則必須運行以下命令：
sudo ipvsadm -C
sudo ipvsadm -ln # 查看結(jié)果

清理CNI配置
sudo rm -rf /etc/cni/net.d

現(xiàn)在刪除節(jié)點，控制平面節(jié)點上運行：
kubectl delete node <節(jié)點名稱>

如果是刪除worker節(jié)點，此時可重新加入集群了。

清理控制平面

你可以在控制平面主機上使用 kubeadm reset 來觸發(fā)盡力而為的清理。
sudo kubeadm reset && rm -rf $HOME/.kube/config && rm -rf $HOME/.kube
有關(guān)此子命令及其選項的更多信息，請參見 kubeadm reset 參考文檔。
清除 iptables 規(guī)則或 IPVS 表，同刪除節(jié)點的操作一樣：
sudo iptables -F && sudo iptables -t nat -F && sudo iptables -t mangle -F && sudo iptables -X
sudo iptables -vnL
sudo ipvsadm -C
sudo ipvsadm -ln # 查看結(jié)果

如何安全地清空一個節(jié)點（擴展）

官文：https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/safely-drain-node/
使用 kubectl drain 從服務中刪除一個節(jié)點（操作后，一般要多等一會兒）

kubectl drain 的成功返回，表明所有的 Pod（除了上一段中描述的被排除的那些）， 已經(jīng)被安全地逐出（考慮到期望的終止寬限期和你定義的 PodDisruptionBudget）。 然后就可以安全地關(guān)閉節(jié)點， 比如關(guān)閉物理機器的電源，如果它運行在云平臺上，則刪除它的虛擬機。

說明：
如果存在新的、能夠容忍 node.kubernetes.io/unschedulable 污點的 Pod， 那么這些 Pod 可能會被調(diào)度到你已經(jīng)清空的節(jié)點上。 除了 DaemonSet 之外，請避免容忍此污點。
如果你或另一個 API 用戶（繞過調(diào)度器）直接為 Pod 設(shè)置了 nodeName字段， 則即使你已將該節(jié)點清空并標記為不可調(diào)度，Pod 仍將被綁定到這個指定的節(jié)點并在該節(jié)點上運行。

首先，確定想要清空的節(jié)點的名稱?？梢杂靡韵旅盍谐黾褐械乃泄?jié)點:
kubectl get nodes
接下來，告訴 Kubernetes 清空節(jié)點：
kubectl drain --ignore-daemonsets <節(jié)點名稱>

如果存在 DaemonSet 管理的 Pod，你將需要為 kubectl 設(shè)置 --ignore-daemonsets 以成功地清空節(jié)點。 kubectl drain 子命令自身實際上不清空節(jié)點上的 DaemonSet Pod 集合： DaemonSet 控制器（作為控制平面的一部分）會立即用新的等效 Pod 替換缺少的 Pod。 DaemonSet 控制器還會創(chuàng)建忽略不可調(diào)度污點的 Pod，這種污點允許在你正在清空的節(jié)點上啟動新的 Pod。
一旦它返回（沒有報錯）， 你就可以下線此節(jié)點（或者等價地，如果在云平臺上，刪除支持該節(jié)點的虛擬機）。 如果要在維護操作期間將節(jié)點留在集群中，則需要運行：
kubectl uncordon

然后告訴 Kubernetes，它可以繼續(xù)在此節(jié)點上調(diào)度新的 Pod。

并行清空多個節(jié)點
官文：https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/safely-drain-node/#draining-multiple-nodes-in-parallel
狀態(tài)的副本數(shù)量低于指定預算的清空操作都將被阻止。

有關(guān) kubeadm init 參數(shù)的更多信息

請參見 kubeadm 參考指南。https://kubernetes.io/zh-cn/docs/reference/setup-tools/kubeadm/
Kubeadm 是一個提供了 kubeadm init 和 kubeadm join 的工具， 作為創(chuàng)建 Kubernetes 集群的 “快捷途徑” 的最佳實踐。
kubeadm 通過執(zhí)行必要的操作來啟動和運行最小可用集群。 按照設(shè)計，它只關(guān)注啟動引導，而非配置機器。同樣的， 安裝各種 “錦上添花” 的擴展，例如 Kubernetes Dashboard、 監(jiān)控方案、以及特定云平臺的擴展，都不在討論范圍內(nèi)。
相反，我們希望在 kubeadm 之上構(gòu)建更高級別以及更加合規(guī)的工具， 理想情況下，使用 kubeadm 作為所有部署工作的基準將會更加易于創(chuàng)建一致性集群。
kubeadm init 用于搭建控制平面節(jié)點
kubeadm join 用于搭建工作節(jié)點并將其加入到集群中
kubeadm upgrade 用于升級 Kubernetes 集群到新版本
kubeadm config 如果你使用了 v1.7.x 或更低版本的 kubeadm 版本初始化你的集群，則使用 kubeadm upgrade 來配置你的集群
kubeadm token 用于管理 kubeadm join 使用的令牌
kubeadm reset 用于恢復通過 kubeadm init 或者 kubeadm join 命令對節(jié)點進行的任何變更
kubeadm certs 用于管理 Kubernetes 證書
kubeadm kubeconfig 用于管理 kubeconfig 文件
kubeadm version 用于打印 kubeadm 的版本信息
kubeadm alpha 用于預覽一組可用于收集社區(qū)反饋的特性文章來源地址http://www.zghlxwxcb.cn/news/detail-784461.html

到了這里，關(guān)于基于Ubuntu22.04部署生產(chǎn)級K8S集群v1.27(規(guī)劃和核心組件部署篇)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！