這次我們來看一個(gè)用 kubeadm 安裝最新 Kubernetes 集群的完整過程目標(biāo)版本是 k8s 1.37.x并且讓底層容器運(yùn)行時(shí)真正走 Docker。這里需要先把背景說清楚Kubernetes 從 1.24 開始移除了內(nèi)置 dockershimK8s 高版本不再直接內(nèi)置 Docker 支持。如果想在 1.37.x 繼續(xù)使用 Docker Engine正確做法是安裝 cri-dockerd 適配器讓 kubelet 通過 CRI 接口與 Docker 通信。整篇文章會(huì)給出從環(huán)境準(zhǔn)備到集群驗(yàn)證的完整命令同時(shí)對這個(gè)方案背后的原理做說明方便你判斷哪種運(yùn)行時(shí)更適合自己的項(xiàng)目。適用讀者主要是這幾類第一公司服務(wù)器上已經(jīng)大量使用 Docker想把業(yè)務(wù)平滑遷移到 Kubernetes第二正在學(xué)習(xí) K8s想對比 containerd 與 Docker 在集群中的行為差異第三需要一個(gè)可復(fù)現(xiàn)的 kubeadm 安裝步驟把集群搭出來給開發(fā)或測試環(huán)境用。本文不會(huì)花太多篇幅講 Kubernetes 基礎(chǔ)概念而是直接圍繞部署鏈路展開所以如果你已經(jīng)知道 Deployment、Service、Pod 的基本含義理解起來會(huì)更快。對完全沒接觸過 K8s 的讀者先把這套安裝跑通再回來看概念文檔效果也會(huì)比空談概念好很多。部署細(xì)節(jié)上我會(huì)以 Ubuntu 22.04 作為示例系統(tǒng)過程中會(huì)同步給出 Rocky Linux / CentOS 等發(fā)行版的差異說明。硬件方面測試環(huán)境建議至少兩個(gè)節(jié)點(diǎn)master 2 核 4Gworker 2 核 4G系統(tǒng)盤 40G 以上。如果只是單機(jī)學(xué)習(xí)也可以把 master 和 worker 放在同一臺機(jī)器但需要處理 master 節(jié)點(diǎn)的 taint這部分我會(huì)在功能驗(yàn)證時(shí)提到。下面先從整體能力開始給出一張快速判斷表。1. 核心能力速覽能力項(xiàng)說明集群安裝工具kubeadm、kubelet、kubectl底層容器運(yùn)行時(shí)Docker Engine通過 cri-dockerd 適配 CRI目標(biāo)版本Kubernetes 1.37.x具體以官方軟件倉庫實(shí)際提供為準(zhǔn)節(jié)點(diǎn)組成至少 1 個(gè) master 和 1 個(gè) worker單機(jī)測試時(shí)可合并推薦硬件Master 2C4G 以上Worker 按業(yè)務(wù)負(fù)載評估操作系統(tǒng)Ubuntu 22.04/24.04、Rocky Linux 9、CentOS 7/9 等主流 Linux 發(fā)行版網(wǎng)絡(luò)方案Flannel、Calico、Cilium 等 CNI 插件任選一種API 能力kube-apiserver 提供完整 REST APIkubectl 和 HTTP 客戶端都能調(diào)用批量任務(wù)原生支持 Deployment、StatefulSet、Job、CronJob 等工作負(fù)載適用場景生產(chǎn)集群搭建、容器化應(yīng)用遷移、Docker 生態(tài)兼容性驗(yàn)證、K8s 學(xué)習(xí)上表最需要關(guān)注的是“底層容器運(yùn)行時(shí)”這一行。Docker 并不是一個(gè)能直接接入 Kubernetes 高版本的 CRI 實(shí)現(xiàn)因此一旦你決定“底層走 Docker”就等于在 kubelet 和 Docker Engine 之間增加了一個(gè)適配組件 cri-dockerd。這個(gè)組件會(huì)帶來少量額外管理和資源開銷但能讓你繼續(xù)使用熟悉的 docker ps、docker logs、docker exec 等命令排查集群里的容器這是很多從 Docker 遷移過來的運(yùn)維團(tuán)隊(duì)比較看重的一點(diǎn)。2. 為什么 K8s 與 Docker 之間多了一層適配在 Kubernetes 的設(shè)計(jì)里每個(gè)節(jié)點(diǎn)上的 kubelet 只通過 CRIContainer Runtime Interface與容器運(yùn)行時(shí)通信。早期版本內(nèi)置了 dockershim讓 kubelet 可以直接操作 Docker但在 1.24 版本后這個(gè) shim 被徹底移除官方推薦直接使用 containerd 或 CRI-O。很多用戶還想繼續(xù)使用 Docker主要原因是團(tuán)隊(duì)已有的鏡像倉庫里可能全是 Docker 構(gòu)建的鏡像或者從 Docker Compose 遷移到 Kubernetes 的過程中希望底層行為和 Docker 保持一致方便對照排查。cri-dockerd 就是為這個(gè)場景準(zhǔn)備的適配器。它實(shí)現(xiàn)了 Kubernetes 的 CRI 接口把 kubelet 發(fā)出的請求轉(zhuǎn)換成 Docker API 調(diào)用最終由 Docker Engine 完成容器生命周期管理。數(shù)據(jù)鏈路大致是這樣的kubelet - CRI 調(diào)用 - cri-dockerd - Docker API - dockerd - containerd - runc - 容器進(jìn)程安裝 cri-dockerd 之后kubelet 通過unix:///var/run/cri-dockerd.sock這個(gè) socket 與它通信而不是默認(rèn)的unix:///var/run/containerd/containerd.sock。kubeadm init 和 kubeadm join 時(shí)需要顯式指定 cri socket這一點(diǎn)非常關(guān)鍵否則 kubeadm 會(huì)優(yōu)先去尋找 containerd導(dǎo)致集群雖然裝好了但底層還是 containerd和你預(yù)想的不一致。還有一個(gè)必須處理的點(diǎn)是 cgroup 驅(qū)動(dòng)。Kubernetes 控制面和 kubelet 默認(rèn)傾向于使用 systemd cgroup driver而 Docker 安裝后默認(rèn)可能是 cgroupfs。如果兩者不一致節(jié)點(diǎn)會(huì)一直處于 NotReady 狀態(tài)或者 Pod 調(diào)度后報(bào)錯(cuò)。下文安裝 Docker 時(shí)會(huì)直接修改 daemon.json把 Docker 的 cgroup driver 固定為 systemd。這也意味著這套方案并不是“裝完就能跑”需要在配置層面做好對齊。3. 節(jié)點(diǎn)規(guī)劃與環(huán)境準(zhǔn)備3.1 節(jié)點(diǎn)規(guī)劃開始安裝前先確認(rèn)節(jié)點(diǎn)和網(wǎng)絡(luò)條件。這里給出一個(gè)兩節(jié)點(diǎn)測試環(huán)境作為示例生產(chǎn)環(huán)境可根據(jù)業(yè)務(wù)規(guī)模擴(kuò)展。節(jié)點(diǎn)角色主機(jī)名IP 示例配置建議masterk8s-master192.168.1.102C4G 以上workerk8s-worker1192.168.1.112C4G 以上按業(yè)務(wù)評估所有節(jié)點(diǎn)都需要有固定的主機(jī)名并且/etc/hosts中最好寫入包含其他節(jié)點(diǎn)的 IP 映射避免 DNS 解析問題。3.2 關(guān)閉 swap 與加載內(nèi)核模塊kubelet 默認(rèn)不允許節(jié)點(diǎn)使用 swap。測試環(huán)境直接關(guān)掉最省事避免后續(xù)參數(shù)不一致sudo swapoff -a sudo sed -i / swap / s/^/#/ /etc/fstab然后加載 Kubernetes 需要的內(nèi)核模塊并調(diào)整網(wǎng)絡(luò)轉(zhuǎn)發(fā)參數(shù)cat EOF | sudo tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF sudo modprobe overlay sudo modprobe br_netfilter 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 sudo sysctl --system如果不加載br_netfilter常見的現(xiàn)象是 Flannel 或 Calico 容器啟動(dòng)后網(wǎng)絡(luò)策略和流量轉(zhuǎn)發(fā)異常節(jié)點(diǎn)狀態(tài)倒是 Ready但跨節(jié)點(diǎn) Pod 通信不通。所以這步不要跳過。3.3 防火墻與端口規(guī)劃各節(jié)點(diǎn)之間需要放行 Kubernetes 組件通信端口。如果使用云廠商安全組或者本機(jī)啟用 firewalld / ufw需要按下面這張表精確放行端口協(xié)議用途6443TCPkube-apiserver所有節(jié)點(diǎn)訪問10250TCPkubelet 指標(biāo)、日志、exec10259TCPkube-scheduler10257TCPkube-controller-manager2379/2380TCPetcd 客戶端和集群通信30000-32767TCP/UDPNodePort 服務(wù)訪問內(nèi)網(wǎng)測試環(huán)境如果節(jié)點(diǎn)彼此信任可以臨時(shí)關(guān)閉防火墻來減少變量但生產(chǎn)環(huán)境建議精確放行端口不要直接關(guān)閉防火墻。3.4 設(shè)置主機(jī)名在 master 節(jié)點(diǎn)執(zhí)行sudo hostnamectl set-hostname k8s-master在 worker 節(jié)點(diǎn)執(zhí)行sudo hostnamectl set-hostname k8s-worker1同時(shí)在所有節(jié)點(diǎn)的/etc/hosts中加入192.168.1.10 k8s-master 192.168.1.11 k8s-worker14. 安裝 Docker 與 cri-dockerd4.1 安裝 Docker Engine以 Ubuntu 22.04 為例安裝 Docker 官方源的常用步驟是sudo apt-get update sudo apt-get install -y 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 ar /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 -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin安裝完成后創(chuàng)建一個(gè)/etc/docker/daemon.json把 cgroup driver 固定為 systemd同時(shí)設(shè)置日志輪轉(zhuǎn)避免容器日志無限增長sudo mkdir -p /etc/docker cat EOF | sudo tee /etc/docker/daemon.json { exec-opts: [native.cgroupdriversystemd], log-driver: json-file, log-opts: { max-size: 100m }, storage-driver: overlay2 } EOF sudo systemctl enable docker sudo systemctl restart docker這里必須確認(rèn) docker 服務(wù)正常sudo systemctl status docker docker info | grep -i cgroup輸出應(yīng)該能看到Cgroup Driver: systemd。4.2 安裝 cri-dockerdcri-dockerd 是 Mirantis 維護(hù)的開源適配器GitHub 倉庫名為Mirantis/cri-dockerd。安裝方式是下載 release 二進(jìn)制放到/usr/local/bin再注冊 systemd 服務(wù)。版本以官方 Releases 頁面為準(zhǔn)我這里以 v0.3.16 作為示例版本號wget https://github.com/Mirantis/cri-dockerd/releases/download/v0.3.16/cri-dockerd-0.3.16.amd64.tgz tar -xvf cri-dockerd-0.3.16.amd64.tgz sudo install -o root -g root -m 0755 cri-dockerd /usr/local/bin/cri-dockerd然后創(chuàng)建兩個(gè) systemd 文件。第一個(gè)是 cri-docker.socketsudo tee /etc/systemd/system/cri-docker.socket EOF [Unit] DescriptionCRI Docker Socket for the API PartOfcri-docker.service [Socket] ListenStream%t/cri-dockerd.sock SocketMode0660 SocketUserroot SocketGrouproot [Install] WantedBysockets.target EOF第二個(gè)是 cri-docker.servicesudo tee /etc/systemd/system/cri-docker.service EOF [Unit] DescriptionCRI Interface for Docker Application Container Engine Documentationhttps://docs.mirantis.com Afterdocker.service Requiresdocker.service [Service] Typenotify ExecStart/usr/local/bin/cri-dockerd --container-runtime-endpoint fd:// Restartalways RestartSec10 StartLimitInterval0 StartLimitBurst5 [Install] WantedBymulti-user.target EOF啟動(dòng)并設(shè)置開機(jī)自啟sudo systemctl daemon-reload sudo systemctl enable cri-docker.socket cri-docker.service sudo systemctl start cri-docker.socket cri-docker.service驗(yàn)證 socket 是否存在ls -l /var/run/cri-dockerd.sock sudo systemctl status cri-docker.socket cri-docker.service到這里Docker 底層已經(jīng)通過 cri-dockerd 暴露出了 CRI 接口。kubelet 使用這個(gè) socket 就能把 Pod 的創(chuàng)建請求交給 Docker Engine 處理。5. 安裝 kubeadm、kubelet、kubectl安裝 kubeadm、kubelet、kubectl 的方式通常通過官方軟件倉庫。以 Ubuntu/Debian 為例使用 pkgs.k8s.io 的 v1.37 倉庫sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl gpg curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.37/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg echo deb [signed-by/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.37/deb/ / | 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如果你的倉庫里還沒有提供 1.37.x 的完整版本可以用下面的命令查看可安裝的版本列表apt-cache madison kubeadmRHEL/Rocky/CentOS 的倉庫寫法稍有不同cat EOF | sudo tee /etc/yum.repos.d/kubernetes.repo [kubernetes] nameKubernetes baseurlhttps://pkgs.k8s.io/core:/stable:/v1.37/rpm/ enabled1 gpgcheck1 gpgkeyhttps://pkgs.k8s.io/core:/stable:/v1.37/rpm/repodata/repomd.xml.key excludekubelet kubeadm kubectl EOF sudo setenforce 0 sudo sed -i s/^SELINUXenforcing$/SELINUXpermissive/ /etc/selinux/config sudo yum install -y kubelet kubeadm kubectl --disableexcludeskubernetesRHEL 系列需要把 SELinux 設(shè)成 permissive否則 CNI 插件創(chuàng)建 veth 口時(shí)會(huì)受到限制。安裝完成后三個(gè)組件會(huì)自動(dòng)注冊 systemd 服務(wù)但kubelet現(xiàn)在先不要啟動(dòng)因?yàn)榧哼€沒初始化kubelet 啟動(dòng)后只會(huì)反復(fù)報(bào)錯(cuò)等待配置文件。等 kubeadm init 結(jié)束后再啟動(dòng)。6. 初始化 Master 節(jié)點(diǎn)6.1 準(zhǔn)備初始化參數(shù)到了最關(guān)鍵的一步。由于我們要讓底層運(yùn)行時(shí)走 Dockerkubeadm init必須帶上--cri-socketunix:///var/run/cri-dockerd.sock否則 kubeadm 自動(dòng)探測 CRI 時(shí)很可能找到 containerd導(dǎo)致后續(xù)集群雖然能用但容器實(shí)際由 containerd 管理。下面給出兩種初始化方式。第一種直接用命令行參數(shù)sudo kubeadm init \ --kubernetes-versionv1.37.x \ --apiserver-advertise-address192.168.1.10 \ --pod-network-cidr10.244.0.0/16 \ --cri-socketunix:///var/run/cri-dockerd.sock \ --image-repository registry.aliyuncs.com/google_containers注意v1.37.x要替換成你倉庫里看到的實(shí)際版本號比如v1.37.2。如果網(wǎng)絡(luò)能正常訪問 K8s 官方鏡像倉庫可以不加--image-repository如果拉鏡像比較慢或失敗再考慮使用國內(nèi)鏡像倉庫。第二種方式把參數(shù)寫入 kubeadm 配置文件。以 kubeadm.k8s.io/v1beta4 為例部分實(shí)際版本字段需要按你的 kubeadm 版本調(diào)整apiVersion: kubeadm.k8s.io/v1beta4 kind: InitConfiguration localAPIEndpoint: advertiseAddress: 192.168.1.10 bindPort: 6443 nodeRegistration: criSocket: unix:///var/run/cri-dockerd.sock name: k8s-master --- apiVersion: kubeadm.k8s.io/v1beta4 kind: ClusterConfiguration kubernetesVersion: 1.37.x networking: podSubnet: 10.244.0.0/16保存為kubeadm-config.yaml后執(zhí)行sudo kubeadm init --configkubeadm-config.yaml6.2 配置 kubectl初始化成功后末尾會(huì)輸出一段配置 kubectl 的命令。復(fù)制到 shell 里執(zhí)行mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config然后確認(rèn)集群組件狀態(tài)kubectl get nodes kubectl get pods -A這里會(huì)遇到一個(gè)正常的現(xiàn)象Node 可能是 NotReady很多系統(tǒng) PodCoreDNS顯示 Pending。原因不是集群壞了而是還沒有安裝 CNI 網(wǎng)絡(luò)插件。6.3 安裝 CNI 網(wǎng)絡(luò)插件CNI 負(fù)責(zé) Pod 網(wǎng)絡(luò)不裝的話節(jié)點(diǎn)無法變成 Ready。這里以 Flannel 為例因?yàn)樗鼘?Pod CIDR 的默認(rèn)配置正好是10.244.0.0/16和上面的初始化參數(shù)匹配kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml如果使用 Calico則把--pod-network-cidr192.168.0.0/16寫入初始化參數(shù)再應(yīng)用 Calico 的 manifest。安裝后等待 1-2 分鐘kubectl get nodes -o wide kubectl get pods -A | grep -E flannel|calico當(dāng) master 節(jié)點(diǎn)狀態(tài)變成 Ready并且 CNI Pod 都處于 Running說明集群控制面已經(jīng)可用。7. 加入 Worker 節(jié)點(diǎn)kubeadm init成功時(shí)終端會(huì)輸出一條 join 命令類似sudo kubeadm join 192.168.1.10:6443 --token token \ --discovery-token-ca-cert-hash sha256:hash \ --cri-socketunix:///var/run/cri-dockerd.sock這里必須把--cri-socket補(bǔ)上否則 worker 節(jié)點(diǎn)的 kubelet 會(huì)去找 containerd和 master 使用的運(yùn)行時(shí)不一致雖然也可能加入成功但后續(xù)排查時(shí)會(huì)多一層問題。如果當(dāng)時(shí)沒復(fù)制 join 命令可以在 master 節(jié)點(diǎn)重新生成 tokensudo kubeadm token create --print-join-command拿到 token 后在 worker 節(jié)點(diǎn)執(zhí)行 join 命令。執(zhí)行完畢后回到 master 節(jié)點(diǎn)查看kubectl get nodes -o wide正常情況下master 和 worker 都應(yīng)該是 Ready 狀態(tài)。如果 worker 一直 NotReady先看 worker 節(jié)點(diǎn) kubelet 狀態(tài)systemctl status kubelet journalctl -u kubelet -f8. 功能測試與效果驗(yàn)證8.1 驗(yàn)證節(jié)點(diǎn)和系統(tǒng) Pod集群搭建完成后第一件事是確認(rèn)所有節(jié)點(diǎn) Ready并且所有kube-system命名空間下的 Pod 都處于 Runningkubectl get nodes kubectl get pods -A這個(gè)步驟能判斷集群組件是否健康。如果某個(gè) system Pod 反復(fù)重啟優(yōu)先看它的日志kubectl logs -n kube-system pod-name8.2 部署一個(gè)測試應(yīng)用為了驗(yàn)證業(yè)務(wù)調(diào)度和 Service 暴露創(chuàng)建一個(gè)簡單的 Nginx DeploymentapiVersion: apps/v1 kind: Deployment metadata: name: nginx-test spec: replicas: 2 selector: matchLabels: app: nginx-test template: metadata: labels: app: nginx-test spec: containers: - name: nginx image: nginx:1.27 ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: nginx-test-svc spec: type: NodePort selector: app: nginx-test ports: - port: 80 targetPort: 80 nodePort: 30080保存為nginx-test.yaml并應(yīng)用kubectl apply -f nginx-test.yaml kubectl get deployment nginx-test kubectl get pods -o wide kubectl get svc nginx-test-svc然后通過任意節(jié)點(diǎn)的30080端口訪問測試服務(wù)。如果訪問不到先查 Service 和 Endpointskubectl describe svc nginx-test-svc kubectl get endpoints nginx-test-svc8.3 驗(yàn)證底層確實(shí)走 Docker這是本文方案的關(guān)鍵驗(yàn)證點(diǎn)。在任意節(jié)點(diǎn)上執(zhí)行docker ps --format table {{.Names}}\t{{.Image}}\t{{.Status}} | grep k8s_只要看到容器名帶k8s_前綴就說明這個(gè)節(jié)點(diǎn)的 Pod 容器確實(shí)由 Docker 創(chuàng)建和管理。再用 crictl 驗(yàn)證同一個(gè)視圖cat EOF | sudo tee /etc/crictl.yaml runtime-endpoint: unix:///var/run/cri-dockerd.sock image-endpoint: unix:///var/run/cri-dockerd.sock EOF sudo crictl pscrictl ps會(huì)列出 Kubernetes 視角下的容器列表。如果 Docker 和 crictl 都能看到相同容器說明這層適配鏈路是通的kubelet - cri-dockerd - Docker Engine - 容器如果 crictl 報(bào)錯(cuò)找不到 socket多半是 cri-dockerd 服務(wù)沒起來或者/etc/crictl.yaml的配置沒有生效。8.4 驗(yàn)證擴(kuò)容和滾動(dòng)更新Kubernetes 的日常操作驗(yàn)證可以先擴(kuò)容看 Pod 分布kubectl scale deployment nginx-test --replicas5 kubectl get pods -o wide再做一個(gè)原地滾動(dòng)更新鏡像標(biāo)簽kubectl set image deployment/nginx-test nginxnginx:1.27-alpine kubectl rollout status deployment/nginx-test最后看日志是否能正常輸出kubectl logs -l appnginx-test --tail109. 接口 API 與批量任務(wù)示例9.1 通過 kubectl proxy 調(diào)用 APIKubernetes 的 kube-apiserver 暴露了一整套 REST API日?？吹降氖?kubectl 封裝。你可以開啟一個(gè)本地代理直接用 curl 調(diào)用kubectl proxy --port8080 然后請求 APIcurl http://127.0.0.1:8080/api/v1/namespaces/default/pods返回結(jié)果是 JSON 格式的 Pod 列表。這里可以用一個(gè)小腳本提取 Pod 名稱curl -s http://127.0.0.1:8080/api/v1/namespaces/default/pods | \ python3 -c import sys, json; datajson.load(sys.stdin); print(\n.join([item[metadata][name] for item in data[items]]))如果需要更完整的授權(quán)方式推薦使用 ServiceAccount token。這就涉及到 RBAC 配置生產(chǎn)環(huán)境不建議直接使用kubectl proxy給外部系統(tǒng)調(diào)用只適合本地調(diào)試。9.2 用 CronJob 做批量任務(wù)Kubernetes 原生支持 Job 和 CronJob適合批量處理和定時(shí)任務(wù)。下面這個(gè)示例每天凌晨兩點(diǎn)執(zhí)行一次歸檔操作apiVersion: batch/v1 kind: CronJob metadata: name: batch-archive-job spec: schedule: 0 2 * * * jobTemplate: spec: template: spec: containers: - name: archive image: busybox:1.36 command: [/bin/sh, -c, echo batch job at $(date); ls /data] restartPolicy: OnFailure應(yīng)用并查看執(zhí)行記錄kubectl apply -f cronjob.yaml kubectl get cronjob kubectl get jobs --watch批量任務(wù)的重點(diǎn)是給容器配置足夠的資源限制和超時(shí)避免某個(gè)異常任務(wù)一直占住節(jié)點(diǎn)資源。生產(chǎn)級批量框架還可以搭配 Argo Workflows 或 Volcano但基礎(chǔ)的 CronJob 對很多運(yùn)維場景已經(jīng)夠用。10. 資源占用與性能觀察10.1 控制面組件資源占用master 節(jié)點(diǎn)部署了 kube-apiserver、etcd、kube-controller-manager、kube-scheduler再加上 kubelet 和 Docker / cri-dockerd即使不跑業(yè)務(wù)也會(huì)占一部分內(nèi)存。從低負(fù)載測試集群的經(jīng)驗(yàn)看空閑狀態(tài)下這些組件常駐內(nèi)存加起來在 1.5GB 到 2.5GB 之間具體數(shù)值與集群規(guī)模、日志量、etcd 數(shù)據(jù)量有關(guān)實(shí)際以你的環(huán)境為準(zhǔn)。建議 master 節(jié)點(diǎn)不要低于 4G 內(nèi)存否則初始化過程中容易出現(xiàn)一次拉起多個(gè)鏡像失敗的情況。觀察命令如下free -h docker stats --no-stream crictl stats kubectl top node注意kubectl top node需要先安裝 metrics-server。如果是臨時(shí)查看節(jié)點(diǎn)資源直接在節(jié)點(diǎn)上執(zhí)行free -h和docker stats更直接。10.2 Docker cri-dockerd 與 containerd 的差異相比直接在節(jié)點(diǎn)上使用 containerd這套方案多了一層 cri-dockerd 適配器因此 CPU 和內(nèi)存占用會(huì)略高一些。優(yōu)勢是運(yùn)維習(xí)慣不變你可以用 docker exec 進(jìn)入任意容器排查用 docker logs 拉取標(biāo)準(zhǔn)輸出鏡像構(gòu)建和 Docker Compose 遷移也更順暢。劣勢是容器的創(chuàng)建路徑更長大規(guī)模高并發(fā)創(chuàng)建 Pod 時(shí)性能會(huì)有輕微損耗。如果集群規(guī)模在幾十個(gè)節(jié)點(diǎn)以內(nèi)這個(gè)差異通常感知不明顯。如果集群會(huì)擴(kuò)展到幾百個(gè)節(jié)點(diǎn)或者對 Pod 啟動(dòng)速度和資源占用有極致要求建議考慮 containerd 作為運(yùn)行時(shí)。選擇哪種運(yùn)行時(shí)本質(zhì)上是運(yùn)維習(xí)慣和性能效率之間的取舍。10.3 與網(wǎng)絡(luò)插件配合時(shí)的資源觀察CNI 組件同樣會(huì)占用節(jié)點(diǎn)資源。以 Flannel 為例每個(gè)節(jié)點(diǎn)都會(huì)運(yùn)行一個(gè) flanneld 進(jìn)程負(fù)責(zé)維護(hù) vxlan 網(wǎng)絡(luò)。如果節(jié)點(diǎn)數(shù)量很多或者 Pod 流量很大可以觀察 flannel 進(jìn)程的 CPU 和內(nèi)存ps aux | grep flanneld如果發(fā)現(xiàn) CNI 組件異常消耗內(nèi)存優(yōu)先檢查節(jié)點(diǎn)是否出現(xiàn)了大量 Pod 重建以及網(wǎng)絡(luò)策略是否過于復(fù)雜。11. 常見問題與排查方法問題現(xiàn)象可能原因排查方式解決方案kubeadm init 拉鏡像失敗網(wǎng)絡(luò)無法訪問鏡像倉庫或鏡像倉庫地址不通查看 init 輸出日志確認(rèn)鏡像名稱使用--image-repository指定可訪問的鏡像倉庫節(jié)點(diǎn)一直 NotReadyCNI 未安裝或 kubelet 與運(yùn)行時(shí)通信異常kubectl get nodesjournalctl -u kubelet -f安裝 Flannel/Calico檢查 cri socket 配置CoreDNS Pod 反復(fù) CrashLoopBackOff網(wǎng)絡(luò)插件未就緒或容器運(yùn)行時(shí)異常kubectl logs -n kube-system coredns-pod等待網(wǎng)絡(luò)插件就緒重啟 CoreDNS DeploymentPod 調(diào)度后容器創(chuàng)建失敗cgroup driver 不一致docker info | grep Cgroupkubelet 配置統(tǒng)一為 systemd修改 daemon.json 后重啟 dockercri-dockerd.sock 不存在cri-dockerd 服務(wù)沒啟動(dòng)systemctl status cri-docker.socket cri-docker.service啟動(dòng)服務(wù)檢查 ExecStart 路徑是否正確kubeadm join 找不到 K8s API Servertoken 過期或端口不通在 master 執(zhí)行kubeadm token list檢查 6443 端口重新生成 token或放行防火墻端口NodePort 無法訪問Service 類型不是 NodePort或防火墻未放行 30000-32767kubectl get svcss -lntp | grep 30080修改 Service 類型或在安全組放行 NodePort 段kubectl logs卡住無輸出kubelet 與 apiserver 網(wǎng)絡(luò)異?；蛉萜饕淹顺鰇ubectl describe pod檢查節(jié)點(diǎn) 10250 端口確認(rèn)節(jié)點(diǎn)間網(wǎng)絡(luò)排查 kubelet 狀態(tài)集群 Pod IP 在不同節(jié)點(diǎn)間不通CNI 插件異?；?bridge-nf-call-iptables 未開啟sysctl net.bridge.bridge-nf-call-iptables查看 CNI 日志重新執(zhí)行 sysctl 配置重啟 CNI Pod業(yè)務(wù)容器重啟頻率很高資源限制過低或健康檢查失敗kubectl describe pod查看 OOMKilled 狀態(tài)調(diào)高資源 limits或調(diào)整 liveness/readiness 探針排查 Kubernetes 問題時(shí)最重要的兩個(gè)命令是kubectl describe和日志查看。很多表面現(xiàn)象比如 Pod 一直 Pending、Node 狀態(tài) NotReady、Service 不通最后都能在 describe 輸出和系統(tǒng)組件日志里找到直接原因。12. 最佳實(shí)踐與使用建議12.1 第一次部署先小參數(shù)驗(yàn)證不要一上來就鋪幾十個(gè)節(jié)點(diǎn)。先在兩個(gè)節(jié)點(diǎn)上跑通整套流程確認(rèn) Docker、cri-dockerd、kubeadm 的版本匹配關(guān)系再逐步增加節(jié)點(diǎn)。尤其是 cri-dockerd 版本和 Docker 版本之間最好以官方 Release 說明為準(zhǔn)。沒有驗(yàn)證過的新版本先在小環(huán)境里跑幾天再考慮上生產(chǎn)。12.2 模型文件、鏡像、配置文件分目錄管理集群運(yùn)維中建議把 kubeadm 配置、CNI manifest、業(yè)務(wù) YAML 分目錄存放。比如/opt/k8s/ └── manifests/ ├── kubeadm-config.yaml ├── cni/ └── apps/這樣升級集群、排查配置差異時(shí)能快速找到對應(yīng)文件也方便用 git 做版本管理。12.3 批量任務(wù)要加日志和失敗重試Kubernetes 原生 Job 的重試策略有限。如果是重要批量任務(wù)建議在應(yīng)用層實(shí)現(xiàn)失敗重試并把日志寫入持久化存儲(chǔ)。CronJob 也建議設(shè)置startingDeadlineSeconds避免調(diào)度堆積時(shí)產(chǎn)生大量并發(fā) Job。12.4 安全與合規(guī)提醒部署 Kubernetes 集群時(shí)組件和鏡像應(yīng)該只從官方或可信來源獲取不要使用來路不明的二進(jìn)制和容器鏡像尤其是涉及生產(chǎn)數(shù)據(jù)和用戶隱私時(shí)。集群中如果運(yùn)行人臉、聲音、版權(quán)素材等敏感數(shù)據(jù)的處理任務(wù)必須先確認(rèn)數(shù)據(jù)來源合法、已獲得授權(quán)并按照企業(yè)內(nèi)部安全規(guī)范設(shè)置網(wǎng)絡(luò)策略和訪問控制。kube-apiserver 的 6443 端口不要直接暴露到公網(wǎng)建議放在內(nèi)網(wǎng)或通過堡壘機(jī)訪問啟用 RBAC 并配置認(rèn)證插件避免未授權(quán)訪問。12.5 定期備份 etcdetcd 是整個(gè)集群狀態(tài)的核心。生產(chǎn)環(huán)境要配置 etcd 的定期快照備份到獨(dú)立存儲(chǔ)。備份命令可以直接使用 etcdctlETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 \ --cacert/etc/kubernetes/pki/etcd/ca.crt \ --cert/etc/kubernetes/pki/etcd/server.crt \ --key/etc/kubernetes/pki/etcd/server.key \ snapshot save /backup/etcd-snapshot.db出現(xiàn)節(jié)點(diǎn)恢復(fù)、集群擴(kuò)容等場景時(shí)這份備份就是最后的兜底。13. 總結(jié)與下一步這套 kubeadm 安裝 K8s 1.37.x 并讓底層走 Docker 的方案最值得嘗試的點(diǎn)在于它保留了 Docker 的運(yùn)維習(xí)慣同時(shí)讓你拿到一個(gè)可用的多節(jié)點(diǎn) Kubernetes 集群。安裝完成后最應(yīng)該先驗(yàn)證三件事第一節(jié)點(diǎn)是否為 Ready系統(tǒng) Pod 是否 Running第二docker ps 能否看到帶k8s_前綴的容器第三部署一個(gè) Nginx Service 并確認(rèn) NodePort 能正常訪問。這三步通過說明 kubelet、cri-dockerd、Docker Engine 整條鏈路是通的。最容易踩的坑有兩個(gè)一個(gè)是沒有在kubeadm init和kubeadm join中顯式指定 cri socket導(dǎo)致集群底層實(shí)際變成 containerd另一個(gè)是 Docker 的 cgroup driver 和 Kubernetes 不一致導(dǎo)致節(jié)點(diǎn)狀態(tài)異常。提前把這兩點(diǎn)處理好整個(gè)安裝過程會(huì)順暢很多。后續(xù)可以繼續(xù)擴(kuò)展的方向包括接入 Cilium 或 Calico 實(shí)現(xiàn)更精細(xì)的網(wǎng)絡(luò)策略安裝 metrics-server 或 Prometheus 做監(jiān)控告警通過 Ingress Controller 替代 NodePort 暴露服務(wù)把現(xiàn)有 Docker Compose 服務(wù)逐步改寫成 Deployment 和 StatefulSet。等這一套集群穩(wěn)定運(yùn)行一段時(shí)間后再評估是否需要切換到底層 containerd對比兩者的資源占用和管理成本。建議收藏備用尤其是準(zhǔn)備在多臺機(jī)器上復(fù)現(xiàn)這個(gè)部署流程的時(shí)候。