這次我們來看一個用 kubeadm 安裝最新 Kubernetes 集群的完整過程目標(biāo)版本是 k8s 1.37.x并且讓底層容器運行時真正走 Docker。這里需要先把背景說清楚Kubernetes 從 1.24 開始移除了內(nèi)置 dockershimK8s 高版本不再直接內(nèi)置 Docker 支持。如果想在 1.37.x 繼續(xù)使用 Docker Engine正確做法是安裝 cri-dockerd 適配器讓 kubelet 通過 CRI 接口與 Docker 通信。整篇文章會給出從環(huán)境準(zhǔn)備到集群驗證的完整命令同時對這個方案背后的原理做說明方便你判斷哪種運行時更適合自己的項目。適用讀者主要是這幾類第一公司服務(wù)器上已經(jīng)大量使用 Docker想把業(yè)務(wù)平滑遷移到 Kubernetes第二正在學(xué)習(xí) K8s想對比 containerd 與 Docker 在集群中的行為差異第三需要一個可復(fù)現(xiàn)的 kubeadm 安裝步驟把集群搭出來給開發(fā)或測試環(huán)境用。本文不會花太多篇幅講 Kubernetes 基礎(chǔ)概念而是直接圍繞部署鏈路展開所以如果你已經(jīng)知道 Deployment、Service、Pod 的基本含義理解起來會更快。對完全沒接觸過 K8s 的讀者先把這套安裝跑通再回來看概念文檔效果也會比空談概念好很多。部署細節(jié)上我會以 Ubuntu 22.04 作為示例系統(tǒng)過程中會同步給出 Rocky Linux / CentOS 等發(fā)行版的差異說明。硬件方面測試環(huán)境建議至少兩個節(jié)點master 2 核 4Gworker 2 核 4G系統(tǒng)盤 40G 以上。如果只是單機學(xué)習(xí)也可以把 master 和 worker 放在同一臺機器但需要處理 master 節(jié)點的 taint這部分我會在功能驗證時提到。下面先從整體能力開始給出一張快速判斷表。1. 核心能力速覽能力項說明集群安裝工具kubeadm、kubelet、kubectl底層容器運行時Docker Engine通過 cri-dockerd 適配 CRI目標(biāo)版本Kubernetes 1.37.x具體以官方軟件倉庫實際提供為準(zhǔn)節(jié)點組成至少 1 個 master 和 1 個 worker單機測試時可合并推薦硬件Master 2C4G 以上Worker 按業(yè)務(wù)負載評估操作系統(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 等工作負載適用場景生產(chǎn)集群搭建、容器化應(yīng)用遷移、Docker 生態(tài)兼容性驗證、K8s 學(xué)習(xí)上表最需要關(guān)注的是“底層容器運行時”這一行。Docker 并不是一個能直接接入 Kubernetes 高版本的 CRI 實現(xiàn)因此一旦你決定“底層走 Docker”就等于在 kubelet 和 Docker Engine 之間增加了一個適配組件 cri-dockerd。這個組件會帶來少量額外管理和資源開銷但能讓你繼續(xù)使用熟悉的 docker ps、docker logs、docker exec 等命令排查集群里的容器這是很多從 Docker 遷移過來的運維團隊比較看重的一點。2. 為什么 K8s 與 Docker 之間多了一層適配在 Kubernetes 的設(shè)計里每個節(jié)點上的 kubelet 只通過 CRIContainer Runtime Interface與容器運行時通信。早期版本內(nèi)置了 dockershim讓 kubelet 可以直接操作 Docker但在 1.24 版本后這個 shim 被徹底移除官方推薦直接使用 containerd 或 CRI-O。很多用戶還想繼續(xù)使用 Docker主要原因是團隊已有的鏡像倉庫里可能全是 Docker 構(gòu)建的鏡像或者從 Docker Compose 遷移到 Kubernetes 的過程中希望底層行為和 Docker 保持一致方便對照排查。cri-dockerd 就是為這個場景準(zhǔn)備的適配器。它實現(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 - 容器進程安裝 cri-dockerd 之后kubelet 通過unix:///var/run/cri-dockerd.sock這個 socket 與它通信而不是默認的unix:///var/run/containerd/containerd.sock。kubeadm init 和 kubeadm join 時需要顯式指定 cri socket這一點非常關(guān)鍵否則 kubeadm 會優(yōu)先去尋找 containerd導(dǎo)致集群雖然裝好了但底層還是 containerd和你預(yù)想的不一致。還有一個必須處理的點是 cgroup 驅(qū)動。Kubernetes 控制面和 kubelet 默認傾向于使用 systemd cgroup driver而 Docker 安裝后默認可能是 cgroupfs。如果兩者不一致節(jié)點會一直處于 NotReady 狀態(tài)或者 Pod 調(diào)度后報錯。下文安裝 Docker 時會直接修改 daemon.json把 Docker 的 cgroup driver 固定為 systemd。這也意味著這套方案并不是“裝完就能跑”需要在配置層面做好對齊。3. 節(jié)點規(guī)劃與環(huán)境準(zhǔn)備3.1 節(jié)點規(guī)劃開始安裝前先確認節(jié)點和網(wǎng)絡(luò)條件。這里給出一個兩節(jié)點測試環(huán)境作為示例生產(chǎn)環(huán)境可根據(jù)業(yè)務(wù)規(guī)模擴展。節(jié)點角色主機名IP 示例配置建議masterk8s-master192.168.1.102C4G 以上workerk8s-worker1192.168.1.112C4G 以上按業(yè)務(wù)評估所有節(jié)點都需要有固定的主機名并且/etc/hosts中最好寫入包含其他節(jié)點的 IP 映射避免 DNS 解析問題。3.2 關(guān)閉 swap 與加載內(nèi)核模塊kubelet 默認不允許節(jié)點使用 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 容器啟動后網(wǎng)絡(luò)策略和流量轉(zhuǎn)發(fā)異常節(jié)點狀態(tài)倒是 Ready但跨節(jié)點 Pod 通信不通。所以這步不要跳過。3.3 防火墻與端口規(guī)劃各節(jié)點之間需要放行 Kubernetes 組件通信端口。如果使用云廠商安全組或者本機啟用 firewalld / ufw需要按下面這張表精確放行端口協(xié)議用途6443TCPkube-apiserver所有節(jié)點訪問10250TCPkubelet 指標(biāo)、日志、exec10259TCPkube-scheduler10257TCPkube-controller-manager2379/2380TCPetcd 客戶端和集群通信30000-32767TCP/UDPNodePort 服務(wù)訪問內(nèi)網(wǎng)測試環(huán)境如果節(jié)點彼此信任可以臨時關(guān)閉防火墻來減少變量但生產(chǎn)環(huán)境建議精確放行端口不要直接關(guān)閉防火墻。3.4 設(shè)置主機名在 master 節(jié)點執(zhí)行sudo hostnamectl set-hostname k8s-master在 worker 節(jié)點執(zhí)行sudo hostnamectl set-hostname k8s-worker1同時在所有節(jié)點的/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)建一個/etc/docker/daemon.json把 cgroup driver 固定為 systemd同時設(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這里必須確認 docker 服務(wù)正常sudo systemctl status docker docker info | grep -i cgroup輸出應(yīng)該能看到Cgroup Driver: systemd。4.2 安裝 cri-dockerdcri-dockerd 是 Mirantis 維護的開源適配器GitHub 倉庫名為Mirantis/cri-dockerd。安裝方式是下載 release 二進制放到/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)建兩個 systemd 文件。第一個是 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第二個是 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啟動并設(shè)置開機自啟sudo systemctl daemon-reload sudo systemctl enable cri-docker.socket cri-docker.service sudo systemctl start cri-docker.socket cri-docker.service驗證 socket 是否存在ls -l /var/run/cri-dockerd.sock sudo systemctl status cri-docker.socket cri-docker.service到這里Docker 底層已經(jīng)通過 cri-dockerd 暴露出了 CRI 接口。kubelet 使用這個 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 口時會受到限制。安裝完成后三個組件會自動注冊 systemd 服務(wù)但kubelet現(xiàn)在先不要啟動因為集群還沒初始化kubelet 啟動后只會反復(fù)報錯等待配置文件。等 kubeadm init 結(jié)束后再啟動。6. 初始化 Master 節(jié)點6.1 準(zhǔn)備初始化參數(shù)到了最關(guān)鍵的一步。由于我們要讓底層運行時走 Dockerkubeadm init必須帶上--cri-socketunix:///var/run/cri-dockerd.sock否則 kubeadm 自動探測 CRI 時很可能找到 containerd導(dǎo)致后續(xù)集群雖然能用但容器實際由 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要替換成你倉庫里看到的實際版本號比如v1.37.2。如果網(wǎng)絡(luò)能正常訪問 K8s 官方鏡像倉庫可以不加--image-repository如果拉鏡像比較慢或失敗再考慮使用國內(nèi)鏡像倉庫。第二種方式把參數(shù)寫入 kubeadm 配置文件。以 kubeadm.k8s.io/v1beta4 為例部分實際版本字段需要按你的 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初始化成功后末尾會輸出一段配置 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然后確認集群組件狀態(tài)kubectl get nodes kubectl get pods -A這里會遇到一個正常的現(xiàn)象Node 可能是 NotReady很多系統(tǒng) PodCoreDNS顯示 Pending。原因不是集群壞了而是還沒有安裝 CNI 網(wǎng)絡(luò)插件。6.3 安裝 CNI 網(wǎng)絡(luò)插件CNI 負責(zé) Pod 網(wǎng)絡(luò)不裝的話節(jié)點無法變成 Ready。這里以 Flannel 為例因為它對 Pod CIDR 的默認配置正好是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é)點狀態(tài)變成 Ready并且 CNI Pod 都處于 Running說明集群控制面已經(jīng)可用。7. 加入 Worker 節(jié)點kubeadm init成功時終端會輸出一條 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補上否則 worker 節(jié)點的 kubelet 會去找 containerd和 master 使用的運行時不一致雖然也可能加入成功但后續(xù)排查時會多一層問題。如果當(dāng)時沒復(fù)制 join 命令可以在 master 節(jié)點重新生成 tokensudo kubeadm token create --print-join-command拿到 token 后在 worker 節(jié)點執(zhí)行 join 命令。執(zhí)行完畢后回到 master 節(jié)點查看kubectl get nodes -o wide正常情況下master 和 worker 都應(yīng)該是 Ready 狀態(tài)。如果 worker 一直 NotReady先看 worker 節(jié)點 kubelet 狀態(tài)systemctl status kubelet journalctl -u kubelet -f8. 功能測試與效果驗證8.1 驗證節(jié)點和系統(tǒng) Pod集群搭建完成后第一件事是確認所有節(jié)點 Ready并且所有kube-system命名空間下的 Pod 都處于 Runningkubectl get nodes kubectl get pods -A這個步驟能判斷集群組件是否健康。如果某個 system Pod 反復(fù)重啟優(yōu)先看它的日志kubectl logs -n kube-system pod-name8.2 部署一個測試應(yīng)用為了驗證業(yè)務(wù)調(diào)度和 Service 暴露創(chuàng)建一個簡單的 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é)點的30080端口訪問測試服務(wù)。如果訪問不到先查 Service 和 Endpointskubectl describe svc nginx-test-svc kubectl get endpoints nginx-test-svc8.3 驗證底層確實走 Docker這是本文方案的關(guān)鍵驗證點。在任意節(jié)點上執(zhí)行docker ps --format table {{.Names}}\t{{.Image}}\t{{.Status}} | grep k8s_只要看到容器名帶k8s_前綴就說明這個節(jié)點的 Pod 容器確實由 Docker 創(chuàng)建和管理。再用 crictl 驗證同一個視圖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會列出 Kubernetes 視角下的容器列表。如果 Docker 和 crictl 都能看到相同容器說明這層適配鏈路是通的kubelet - cri-dockerd - Docker Engine - 容器如果 crictl 報錯找不到 socket多半是 cri-dockerd 服務(wù)沒起來或者/etc/crictl.yaml的配置沒有生效。8.4 驗證擴容和滾動更新Kubernetes 的日常操作驗證可以先擴容看 Pod 分布kubectl scale deployment nginx-test --replicas5 kubectl get pods -o wide再做一個原地滾動更新鏡像標(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 封裝。你可以開啟一個本地代理直接用 curl 調(diào)用kubectl proxy --port8080 然后請求 APIcurl http://127.0.0.1:8080/api/v1/namespaces/default/pods返回結(jié)果是 JSON 格式的 Pod 列表。這里可以用一個小腳本提取 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適合批量處理和定時任務(wù)。下面這個示例每天凌晨兩點執(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ù)的重點是給容器配置足夠的資源限制和超時避免某個異常任務(wù)一直占住節(jié)點資源。生產(chǎn)級批量框架還可以搭配 Argo Workflows 或 Volcano但基礎(chǔ)的 CronJob 對很多運維場景已經(jīng)夠用。10. 資源占用與性能觀察10.1 控制面組件資源占用master 節(jié)點部署了 kube-apiserver、etcd、kube-controller-manager、kube-scheduler再加上 kubelet 和 Docker / cri-dockerd即使不跑業(yè)務(wù)也會占一部分內(nèi)存。從低負載測試集群的經(jīng)驗看空閑狀態(tài)下這些組件常駐內(nèi)存加起來在 1.5GB 到 2.5GB 之間具體數(shù)值與集群規(guī)模、日志量、etcd 數(shù)據(jù)量有關(guān)實際以你的環(huán)境為準(zhǔn)。建議 master 節(jié)點不要低于 4G 內(nèi)存否則初始化過程中容易出現(xiàn)一次拉起多個鏡像失敗的情況。觀察命令如下free -h docker stats --no-stream crictl stats kubectl top node注意kubectl top node需要先安裝 metrics-server。如果是臨時查看節(jié)點資源直接在節(jié)點上執(zhí)行free -h和docker stats更直接。10.2 Docker cri-dockerd 與 containerd 的差異相比直接在節(jié)點上使用 containerd這套方案多了一層 cri-dockerd 適配器因此 CPU 和內(nèi)存占用會略高一些。優(yōu)勢是運維習(xí)慣不變你可以用 docker exec 進入任意容器排查用 docker logs 拉取標(biāo)準(zhǔn)輸出鏡像構(gòu)建和 Docker Compose 遷移也更順暢。劣勢是容器的創(chuàng)建路徑更長大規(guī)模高并發(fā)創(chuàng)建 Pod 時性能會有輕微損耗。如果集群規(guī)模在幾十個節(jié)點以內(nèi)這個差異通常感知不明顯。如果集群會擴展到幾百個節(jié)點或者對 Pod 啟動速度和資源占用有極致要求建議考慮 containerd 作為運行時。選擇哪種運行時本質(zhì)上是運維習(xí)慣和性能效率之間的取舍。10.3 與網(wǎng)絡(luò)插件配合時的資源觀察CNI 組件同樣會占用節(jié)點資源。以 Flannel 為例每個節(jié)點都會運行一個 flanneld 進程負責(zé)維護 vxlan 網(wǎng)絡(luò)。如果節(jié)點數(shù)量很多或者 Pod 流量很大可以觀察 flannel 進程的 CPU 和內(nèi)存ps aux | grep flanneld如果發(fā)現(xiàn) CNI 組件異常消耗內(nèi)存優(yōu)先檢查節(jié)點是否出現(xiàn)了大量 Pod 重建以及網(wǎng)絡(luò)策略是否過于復(fù)雜。11. 常見問題與排查方法問題現(xiàn)象可能原因排查方式解決方案kubeadm init 拉鏡像失敗網(wǎng)絡(luò)無法訪問鏡像倉庫或鏡像倉庫地址不通查看 init 輸出日志確認鏡像名稱使用--image-repository指定可訪問的鏡像倉庫節(jié)點一直 NotReadyCNI 未安裝或 kubelet 與運行時通信異常kubectl get nodesjournalctl -u kubelet -f安裝 Flannel/Calico檢查 cri socket 配置CoreDNS Pod 反復(fù) CrashLoopBackOff網(wǎng)絡(luò)插件未就緒或容器運行時異常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ù)沒啟動systemctl status cri-docker.socket cri-docker.service啟動服務(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é)點 10250 端口確認節(jié)點間網(wǎng)絡(luò)排查 kubelet 狀態(tài)集群 Pod IP 在不同節(jié)點間不通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 問題時最重要的兩個命令是kubectl describe和日志查看。很多表面現(xiàn)象比如 Pod 一直 Pending、Node 狀態(tài) NotReady、Service 不通最后都能在 describe 輸出和系統(tǒng)組件日志里找到直接原因。12. 最佳實踐與使用建議12.1 第一次部署先小參數(shù)驗證不要一上來就鋪幾十個節(jié)點。先在兩個節(jié)點上跑通整套流程確認 Docker、cri-dockerd、kubeadm 的版本匹配關(guān)系再逐步增加節(jié)點。尤其是 cri-dockerd 版本和 Docker 版本之間最好以官方 Release 說明為準(zhǔn)。沒有驗證過的新版本先在小環(huán)境里跑幾天再考慮上生產(chǎn)。12.2 模型文件、鏡像、配置文件分目錄管理集群運維中建議把 kubeadm 配置、CNI manifest、業(yè)務(wù) YAML 分目錄存放。比如/opt/k8s/ └── manifests/ ├── kubeadm-config.yaml ├── cni/ └── apps/這樣升級集群、排查配置差異時能快速找到對應(yīng)文件也方便用 git 做版本管理。12.3 批量任務(wù)要加日志和失敗重試Kubernetes 原生 Job 的重試策略有限。如果是重要批量任務(wù)建議在應(yīng)用層實現(xiàn)失敗重試并把日志寫入持久化存儲。CronJob 也建議設(shè)置startingDeadlineSeconds避免調(diào)度堆積時產(chǎn)生大量并發(fā) Job。12.4 安全與合規(guī)提醒部署 Kubernetes 集群時組件和鏡像應(yīng)該只從官方或可信來源獲取不要使用來路不明的二進制和容器鏡像尤其是涉及生產(chǎn)數(shù)據(jù)和用戶隱私時。集群中如果運行人臉、聲音、版權(quán)素材等敏感數(shù)據(jù)的處理任務(wù)必須先確認數(shù)據(jù)來源合法、已獲得授權(quán)并按照企業(yè)內(nèi)部安全規(guī)范設(shè)置網(wǎng)絡(luò)策略和訪問控制。kube-apiserver 的 6443 端口不要直接暴露到公網(wǎng)建議放在內(nèi)網(wǎng)或通過堡壘機訪問啟用 RBAC 并配置認證插件避免未授權(quán)訪問。12.5 定期備份 etcdetcd 是整個集群狀態(tài)的核心。生產(chǎn)環(huán)境要配置 etcd 的定期快照備份到獨立存儲。備份命令可以直接使用 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é)點恢復(fù)、集群擴容等場景時這份備份就是最后的兜底。13. 總結(jié)與下一步這套 kubeadm 安裝 K8s 1.37.x 并讓底層走 Docker 的方案最值得嘗試的點在于它保留了 Docker 的運維習(xí)慣同時讓你拿到一個可用的多節(jié)點 Kubernetes 集群。安裝完成后最應(yīng)該先驗證三件事第一節(jié)點是否為 Ready系統(tǒng) Pod 是否 Running第二docker ps 能否看到帶k8s_前綴的容器第三部署一個 Nginx Service 并確認 NodePort 能正常訪問。這三步通過說明 kubelet、cri-dockerd、Docker Engine 整條鏈路是通的。最容易踩的坑有兩個一個是沒有在kubeadm init和kubeadm join中顯式指定 cri socket導(dǎo)致集群底層實際變成 containerd另一個是 Docker 的 cgroup driver 和 Kubernetes 不一致導(dǎo)致節(jié)點狀態(tài)異常。提前把這兩點處理好整個安裝過程會順暢很多。后續(xù)可以繼續(xù)擴展的方向包括接入 Cilium 或 Calico 實現(xiàn)更精細的網(wǎng)絡(luò)策略安裝 metrics-server 或 Prometheus 做監(jiān)控告警通過 Ingress Controller 替代 NodePort 暴露服務(wù)把現(xiàn)有 Docker Compose 服務(wù)逐步改寫成 Deployment 和 StatefulSet。等這一套集群穩(wěn)定運行一段時間后再評估是否需要切換到底層 containerd對比兩者的資源占用和管理成本。建議收藏備用尤其是準(zhǔn)備在多臺機器上復(fù)現(xiàn)這個部署流程的時候。