這段時(shí)間我把Kubernetes的單機(jī)部署翻來覆去折騰了幾遍從最開始連Pod都調(diào)度不上去到后來能在2C4G的一臺(tái)服務(wù)器上穩(wěn)定跑起完整集群踩了不少坑也摸清了不少門道。這篇東西不是官方文檔翻譯是我自己“如何只使用一臺(tái)服務(wù)器配置kubernetes”的學(xué)習(xí)總結(jié)。文章會(huì)把三條主流路線都講清楚k3s、minikube、kubeadm單節(jié)點(diǎn)各自適用什么場景、關(guān)鍵參數(shù)怎么設(shè)置、部署完怎么自測、遇到報(bào)錯(cuò)怎么查。適合手里只有一臺(tái)服務(wù)器但又想認(rèn)真學(xué)容器編排的運(yùn)維新人、后端開發(fā)以及準(zhǔn)備面試前突擊K8s實(shí)操的學(xué)生。1. 先想清楚單機(jī)K8s到底在學(xué)什么1.1 為什么非要一臺(tái)服務(wù)器很多人學(xué)Kubernetes第一反應(yīng)是湊三臺(tái)機(jī)器覺得少了不像集群。但真實(shí)情況是多節(jié)點(diǎn)集群的日常管理成本很高而學(xué)習(xí)K8s核心概念其實(shí)單機(jī)就能覆蓋80%的內(nèi)容。一臺(tái)服務(wù)器能讓你把Pod、Deployment、Service、Ingress、ConfigMap、PV/PVC這些核心對象全部跑一遍甚至能模擬出Pod調(diào)度、重啟策略、滾動(dòng)更新這些調(diào)度行為。區(qū)別只在于單機(jī)環(huán)境沒有任何高可用可言etcd和kubelet都在同一臺(tái)機(jī)器上宕機(jī)就是全掛。所以單機(jī)部署的核心價(jià)值是“學(xué)習(xí)”和“輕量驗(yàn)證”不是“替代生產(chǎn)”。你得帶著這個(gè)預(yù)期去選方案才不會(huì)出現(xiàn)“為什么我只有一臺(tái)機(jī)器學(xué)不了K8s”的錯(cuò)覺。另外很多人在本機(jī)用虛擬機(jī)或者Docker Desktop折騰總感覺卡頓嚴(yán)重其實(shí)換成一臺(tái)獨(dú)立的Linux服務(wù)器同樣配置下的體驗(yàn)會(huì)好非常多因?yàn)橘Y源隔離更干凈網(wǎng)絡(luò)模型也更接近真實(shí)環(huán)境。1.2 四條技術(shù)路線對比k3s、minikube、kind、kubeadm單機(jī)部署Kubernetes不是只有一種方法。對于“只有一臺(tái)服務(wù)器”這個(gè)約束條件常見的方案有四條k3s、minikube、kind、kubeadm單節(jié)點(diǎn)。我用了一段時(shí)間后把它們放在同一個(gè)表格里對比方案內(nèi)存占用啟動(dòng)速度接近生產(chǎn)程度推薦場景k3s約500MB-700MB極快中高邊緣計(jì)算、臨時(shí)環(huán)境、入門學(xué)習(xí)、低配機(jī)器minikube約1.5GB-2GB較快中等系統(tǒng)學(xué)習(xí)K8s原生API、快速開發(fā)驗(yàn)證kind約1GB-2GB中等較低CI流水線、鏡像構(gòu)建驗(yàn)證、快速銷毀重建kubeadm約1.5GB-2.5GB較慢高模擬生產(chǎn)部署方式、準(zhǔn)備向多節(jié)點(diǎn)擴(kuò)展從內(nèi)存占用就能看出來如果你的服務(wù)器只有2G內(nèi)存基本不用猶豫直接選k3s。4G內(nèi)存的話minikube和kubeadm都能跑起來但會(huì)比較緊張。8G及以上三者隨便選體驗(yàn)都好。這里順便說一個(gè)很多教程不會(huì)提的細(xì)節(jié)調(diào)整方案之前先確認(rèn)服務(wù)器內(nèi)存是不是真正可用很多特價(jià)云主機(jī)標(biāo)注2G內(nèi)存實(shí)際可用只有1.5G左右因?yàn)橄到y(tǒng)本身吃掉了不少。2. 部署前的底線準(zhǔn)備系統(tǒng)初始化與運(yùn)行時(shí)選型2.1 服務(wù)器的最低配置要求按照我的實(shí)測不同方案對應(yīng)不同的最低配置。k3s最低1核1G能跑起來但屬于“能啟動(dòng)不代表能用”的程度連個(gè)像樣的應(yīng)用進(jìn)去CPU就滿了。minikube最低建議2核2G官方文檔寫的是2核2G起步實(shí)際跑起來至少需要2G可分配內(nèi)存。kubeadm單節(jié)點(diǎn)最低建議2核4G因?yàn)閑tcd本身比較吃內(nèi)存加上kubelet、apiserver這些進(jìn)程內(nèi)存不足時(shí)etcd容器會(huì)反復(fù)重啟這是一個(gè)非常典型的失敗表現(xiàn)。磁盤方面單機(jī)集群至少留出20G給K8s相關(guān)組件和鏡像。如果你想拉一些帶有GPU依賴或者大體積的鏡像做實(shí)驗(yàn)30G-50G會(huì)更從容。系統(tǒng)方面Ubuntu 20.04/22.04、Debian 11/12、CentOS 7.9/Stream 9我都試過CentOS系列會(huì)遇到一些內(nèi)核模塊和防火墻規(guī)則的額外問題Ubuntu和Debian是體驗(yàn)最順的。2.2 無論選哪條路線都要做的系統(tǒng)初始化這部分操作三條路線通用絕對不是白做的。第一件事關(guān)閉swap。Kubernetes在1.8版本之后要求節(jié)點(diǎn)必須關(guān)閉swap否則kubelet會(huì)拒絕啟動(dòng)或者直接報(bào)錯(cuò)。命令是swapoff -a但這只是臨時(shí)關(guān)閉重啟后會(huì)恢復(fù)。要把/etc/fstab里帶swap關(guān)鍵字的那行注釋掉才能保證重啟后不再啟用。第二件事加載必要內(nèi)核模塊并設(shè)置內(nèi)核參數(shù)cat EOF | tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF modprobe overlay modprobe br_netfilter cat EOF | 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 --system很多部署失敗都出現(xiàn)在網(wǎng)絡(luò)層比如Pod跨節(jié)點(diǎn)通信不正常、CoreDNS解析超時(shí)根源往往是內(nèi)核參數(shù)沒打開。net.ipv4.ip_forward這個(gè)參數(shù)尤其重要它決定iptables規(guī)則能否正確轉(zhuǎn)發(fā)數(shù)據(jù)包。第三件事確保系統(tǒng)時(shí)間同步。Kubernetes集群內(nèi)部很多組件依賴證書證書有一個(gè)有效期窗口系統(tǒng)時(shí)間如果偏差過大會(huì)出現(xiàn)x509證書校驗(yàn)失敗。安裝chrony并啟動(dòng)即可。2.3 容器運(yùn)行時(shí)containerd優(yōu)先單機(jī)部署K8s容器運(yùn)行時(shí)推薦直接選containerd。原因很簡單Docker在K8s里的地位已經(jīng)變成了一個(gè)兼容層Docker本身默認(rèn)使用的也是containerd。如果你通過Docker來啟動(dòng)K8s組件等于多繞了一層。用containerd作為運(yùn)行時(shí)鏡像路徑、日志格式、資源占用都更簡潔。不過containerd有一個(gè)容易被忽略的配置點(diǎn)SystemdCgroup。如果節(jié)點(diǎn)使用的是systemd作為init系統(tǒng)而containerd的SystemdCgroup沒有切換成truekubelet運(yùn)行起來之后會(huì)報(bào)cgroup相關(guān)錯(cuò)誤或者Pod經(jīng)常處于Pending狀態(tài)。修改方法是編輯/etc/containerd/config.toml找到SystemdCgroup參數(shù)改成true然后重啟containerd。3. 最省心的路徑k3s單機(jī)部署全流程3.1 k3s到底做了什么k3s是一個(gè)輕量級(jí)Kubernetes發(fā)行版它把控制面組件kube-apiserver、kube-controller-manager、kube-scheduler全部打包進(jìn)一個(gè)二進(jìn)制文件里內(nèi)置了containerd、CoreDNS、flannel等組件。你裝完k3s之后機(jī)器上不需要預(yù)先安裝Docker、containerd或者kubectl它全幫你解決了。安裝完成后k3s自帶的kubectl命令是k3s kubectl與原生kubectl使用方式一致。這個(gè)方案非常適合只有一臺(tái)服務(wù)器的情況。裝完之后整個(gè)集群的組件數(shù)量比完整版K8s要少很多資源占用低啟動(dòng)也快。官方提供了極其簡單的安裝命令curl -sfL https://get.k3s.io | sh -如果你下載腳本比較慢可以先把腳本下載到本地再執(zhí)行不要糾結(jié)于必須一條命令完成。3.2 安裝后的關(guān)鍵操作與權(quán)限處理安裝完成后首先檢查狀態(tài)systemctl status k3s k3s kubectl get node k3s kubectl get pods -A正常情況下節(jié)點(diǎn)狀態(tài)是Readykube-system命名空間里的Pod都是Running。k3s的kubeconfig文件默認(rèn)放在/etc/rancher/k3s/k3s.yaml默認(rèn)權(quán)限是600只有root能讀。如果你使用普通用戶執(zhí)行kubectl需要先把配置文件復(fù)制出來并修改權(quán)限mkdir -p $HOME/.kube sudo cp /etc/rancher/k3s/k3s.yaml $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config另外k3s.yaml里的server地址默認(rèn)是https://127.0.0.1:6443只能本機(jī)訪問。如果你想從自己電腦上遠(yuǎn)程操作這臺(tái)服務(wù)器上的集群我個(gè)人的建議是在服務(wù)器上用SSH端口轉(zhuǎn)發(fā)而不是直接把kubeconfig里的地址改成公網(wǎng)IP因?yàn)?443端口暴露到公網(wǎng)的安全隱患很大而且還要處理證書SAN的問題學(xué)習(xí)階段沒有必要踩這個(gè)坑。3.3 部署一個(gè)應(yīng)用驗(yàn)證集群單機(jī)K8s環(huán)境跑通了之后第一個(gè)驗(yàn)證用例很有講究。我的習(xí)慣是部署一個(gè)nginx Deployment然后用NodePort方式暴露服務(wù)。因?yàn)檫@種方式能同時(shí)驗(yàn)證調(diào)度、容器運(yùn)行、網(wǎng)絡(luò)代理三個(gè)核心環(huán)節(jié)kubectl create deployment nginx --imagenginx kubectl scale deployment nginx --replicas2 kubectl expose deployment nginx --port80 --target-port80 --typeNodePort kubectl get svc看到Service的ClusterIP和NodePort之后在當(dāng)前服務(wù)器上直接訪問驗(yàn)證curl http://127.0.0.1:30080如果能正常返回nginx頁面說明整個(gè)鏈路已經(jīng)通了。這時(shí)候你還可以順手驗(yàn)證一下滾動(dòng)更新和副本調(diào)度先把副本數(shù)改成3再修改鏡像tag觀察Pod逐個(gè)重建的過程。3.4 k3s的升級(jí)與卸載k3s升級(jí)非常簡單官方安裝腳本本身支持重復(fù)執(zhí)行。升級(jí)的命令同樣是curl -sfL https://get.k3s.io | sh -腳本檢測到已存在的版本會(huì)自動(dòng)更新。卸載的時(shí)候k3s會(huì)生成一個(gè)卸載腳本執(zhí)行/usr/local/bin/k3s-uninstall.sh即可這個(gè)腳本會(huì)把所有相關(guān)文件、服務(wù)、數(shù)據(jù)目錄清理干凈。這里要提醒一下卸載前確認(rèn)沒有需要保留的PVC數(shù)據(jù)因?yàn)樾遁d腳本會(huì)把/var/lib/rancher/k3s下面的數(shù)據(jù)一起刪掉。4. 更接近原汁原味的K8sminikube單機(jī)部署全流程4.1 minikube能解決什么問題minikube是官方長期維護(hù)的本地Kubernetes環(huán)境它的定位就是“在單機(jī)上跑一個(gè)完整的K8s集群”。和k3s不同minikube不會(huì)幫你把組件打包成一個(gè)二進(jìn)制文件它背后還是標(biāo)準(zhǔn)的K8s組件只是通過緩存和預(yù)下載把安裝過程簡化了。如果你打算系統(tǒng)學(xué)習(xí)K8s原生對象、看kube-system里各個(gè)組件是怎么部署的minikube的體驗(yàn)更接近真實(shí)環(huán)境。之前我推薦過用Docker作為驅(qū)動(dòng)這也是在Linux服務(wù)器上最推薦的運(yùn)行方式。安裝minikube二進(jìn)制文件之后用下面命令啟動(dòng)集群minikube start --driverdocker --cpus2 --memory4096 --container-runtimecontainerd參數(shù)含義很簡單cpus和memory決定分配給K8s集群的資源上限container-runtime選擇containerd。這里建議顯式指定memory因?yàn)槿绻恢付╩inikube可能只用默認(rèn)內(nèi)存導(dǎo)致集群啟動(dòng)后kube-system組件頻繁因內(nèi)存不足被殺掉。4.2 minikube日常使用與Dashboardminikube最實(shí)用的地方是自帶了一套本地開發(fā)體驗(yàn)。啟動(dòng)集群之后可以用minikube dashboard命令打開K8s控制面板這個(gè)功能對可視化觀察資源狀態(tài)和Pod日志非常有用。在無圖形界面的服務(wù)器上你仍然可以訪問Dashboard因?yàn)樗举|(zhì)上是代理到本地的Web服務(wù)。minikube還內(nèi)置了很多addons可以隨時(shí)啟用比如minikube addons enable ingress minikube addons enable metrics-server啟用ingress之后集群里就有了標(biāo)準(zhǔn)的Ingress Controller可以做基于域名的路由轉(zhuǎn)發(fā)實(shí)驗(yàn)這是k3s和kind都容易折騰的地方。minikube對kubectl的整合也做得很好。如果你的系統(tǒng)上沒有獨(dú)立安裝kubectl可以用minikube kubectl -- get pods來調(diào)用內(nèi)置的kubectl。如果想要在任意終端直接使用kubectl可以配置alias但更推薦直接安裝獨(dú)立kubectl然后把kubeconfig指向minikube生成的文件。minikube的kubeconfig在~/.kube/config里自動(dòng)追加了minikube的context使用minikube start之后默認(rèn)的context就是minikube。4.3 minikube的常見坑第一個(gè)坑是卡在SSH連接階段。如果你在云服務(wù)器上使用Docker驅(qū)動(dòng)偶爾會(huì)卡在waiting for SSH主要原因通常是鏡像拉取超時(shí)或者Docker鏡像緩存損壞。處理方式是把minikube重新初始化minikube delete后重新minikube start或者刪除~/.minikube目錄后重試。第二個(gè)坑是鏡像拉取慢。minikube啟動(dòng)時(shí)要從公共鏡像倉庫拉取一組K8s組件鏡像如果網(wǎng)絡(luò)不穩(wěn)定整個(gè)啟動(dòng)流程會(huì)變得很慢。解決辦法是給Docker配置鏡像加速在/etc/docker/daemon.json里配置registry-mirrors選項(xiàng)這個(gè)配置不僅影響Docker也會(huì)影響minikube通過Docker拉取鏡像的速度。第三個(gè)坑是不要在服務(wù)器上使用none驅(qū)動(dòng)。minikube的none驅(qū)動(dòng)是直接把K8s組件以系統(tǒng)服務(wù)方式運(yùn)行在宿主機(jī)上。表面上省了一層虛擬化開銷但后續(xù)刪除集群時(shí)會(huì)把宿主機(jī)上的K8s相關(guān)文件清理得很不干凈而且在系統(tǒng)服務(wù)層面留下不少殘留。Docker驅(qū)動(dòng)雖然多占一點(diǎn)內(nèi)存但隔離性更好刪除也徹底。5. 模擬生產(chǎn)部署方式kubeadm單節(jié)點(diǎn)部署全流程5.1 為什么已經(jīng)有了k3s和minikube還要用kubeadm如果你將來打算進(jìn)公司維護(hù)真實(shí)K8s集群你會(huì)發(fā)現(xiàn)生產(chǎn)環(huán)境普遍是用kubeadm、二進(jìn)制或者發(fā)行版自帶的安裝器搭起來的。kubeadm是構(gòu)建Kubernetes集群的標(biāo)準(zhǔn)工具它把a(bǔ)piserver、controller-manager、scheduler、etcd都封裝成靜態(tài)Pod通過kubelet拉起。用kubeadm在單機(jī)上走一遍你才能真正看到每個(gè)控制面組件是怎么以Pod形式存在的。單節(jié)點(diǎn)的意義在于除了沒有第二個(gè)工作節(jié)點(diǎn)其它流程和生產(chǎn)幾乎完全一致。初始化控制面、安裝CNI插件、移除控制面污點(diǎn)這套流程最接近生產(chǎn)。而且之后如果你有了第二臺(tái)服務(wù)器只需要在另一臺(tái)機(jī)器上執(zhí)行kubeadm join就能把單節(jié)點(diǎn)擴(kuò)成多節(jié)點(diǎn)這是k3s和minikube都不太容易做到的升級(jí)路徑。5.2 初始化控制面的完整命令使用kubeadm之前先準(zhǔn)備好容器運(yùn)行時(shí)。這里以containerd為例。安裝好containerd之后直接初始化控制面kubeadm init --pod-network-cidr10.244.0.0/16然后按照初始化完成后的提示設(shè)置kubectl的配置文件mkdir -p $HOME/.kube cp -i /etc/kubernetes/admin.conf $HOME/.kube/config chown $(id -u):$(id -g) $HOME/.kube/config初始化完成后集群處于NotReady狀態(tài)原因是沒有安裝網(wǎng)絡(luò)插件。這里推薦安裝Calico作為CNI插件kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/master/manifests/calico.yaml安裝完成后重點(diǎn)檢查calico-system命名空間下的Pod是否全部Running。在網(wǎng)絡(luò)插件就緒之前CoreDNS也會(huì)一直處于Pending狀態(tài)這是正常現(xiàn)象不要急著去查CoreDNS的問題。5.3 單節(jié)點(diǎn)集群的污點(diǎn)處理初始化完成的單節(jié)點(diǎn)集群有一個(gè)很經(jīng)典的坑控制面節(jié)點(diǎn)默認(rèn)帶有污點(diǎn)Pods無法調(diào)度上去。所以當(dāng)你嘗試部署一個(gè)普通應(yīng)用時(shí)Pod會(huì)一直Pending。解決辦法是移除控制面節(jié)點(diǎn)的污點(diǎn)kubectl taint nodes --all node-role.kubernetes.io/control-plane-執(zhí)行之后Pod才能調(diào)度到這個(gè)節(jié)點(diǎn)上。這一步非常重要很多初次使用kubeadm單節(jié)點(diǎn)的朋友都會(huì)在這里卡住。需要注意的是生產(chǎn)環(huán)境的多節(jié)點(diǎn)集群里控制面節(jié)點(diǎn)通常不會(huì)移除污點(diǎn)讓它只跑系統(tǒng)組件單機(jī)實(shí)驗(yàn)環(huán)境才需要這樣做。5.4 kubeadm單節(jié)點(diǎn)的其他坑位kubeadm單節(jié)點(diǎn)對資源的要求是三條路線里最高的。最容易出現(xiàn)的失敗是etcd容器反復(fù)重啟表現(xiàn)是kubectl get pods -n kube-system中etcd處于CrashLoopBackOff。根本原因多半是內(nèi)存不足因?yàn)閑tcd會(huì)在啟動(dòng)時(shí)鎖定一定量的內(nèi)存頁資源不夠時(shí)直接被OOM殺掉。這種情況沒有捷徑要么擴(kuò)大內(nèi)存要么換用k3s。另一個(gè)常見問題是系統(tǒng)時(shí)間不對。Kubernetes證書有效期是動(dòng)態(tài)計(jì)算的系統(tǒng)時(shí)間偏差超過幾分鐘apiserver和kubelet之間的通信就會(huì)出現(xiàn)證書校驗(yàn)失敗。排錯(cuò)時(shí)先date看一下當(dāng)前時(shí)間這個(gè)操作花費(fèi)五秒鐘卻經(jīng)常能解決看起來像網(wǎng)絡(luò)故障的問題。6. 三種方案對比之后我留下的真實(shí)結(jié)論6.1 對應(yīng)用途的選型清單如果你問我現(xiàn)在有一臺(tái)2C4G服務(wù)器到底選哪個(gè)我的回答是看階段。只想快速搭建一個(gè)K8s環(huán)境跑幾個(gè)實(shí)驗(yàn)盡量少跟系統(tǒng)配置打交道選k3s。安裝一條命令裝完即可用自帶containerd和網(wǎng)絡(luò)插件占用資源最少。想認(rèn)真把K8s的核心對象學(xué)明白愿意接受鏡像拉取和初始化過程選minikube。Dashboard體驗(yàn)好附加組件豐富kubectl和K8s API版本都是原生的學(xué)習(xí)曲線更順。后續(xù)計(jì)劃擴(kuò)到多節(jié)點(diǎn)想提前模擬生產(chǎn)部署方式選kubeadm。單節(jié)點(diǎn)初始化流程和生產(chǎn)完全一致擴(kuò)節(jié)點(diǎn)時(shí)執(zhí)行kubeadm join即可。如果只是寫自動(dòng)化腳本或者做CI環(huán)境選kind。kind的所有K8s節(jié)點(diǎn)都是Docker容器啟動(dòng)銷毀都非常迅速。三條主線我個(gè)人都完整走過一遍現(xiàn)在的習(xí)慣是遇到復(fù)雜實(shí)驗(yàn)想快速驗(yàn)證用k3s需要研究K8s本身行為時(shí)用minikube模擬生產(chǎn)部署就kubeadm。三者不沖突學(xué)習(xí)階段都用一用反而收獲更大。6.2 資源占用與可維護(hù)性實(shí)測這是我多次部署后記錄的一組真實(shí)數(shù)據(jù)。k3s安裝完成后空閑狀態(tài)下內(nèi)存常駐約600MB-800MBPod數(shù)量非常少。minikube使用Docker驅(qū)動(dòng)時(shí)占用在1.5GB-2GB之間如果再加上Dashboard和附加組件會(huì)接近2.5GB。kubeadm單節(jié)點(diǎn)最重etcd、apiserver、controller-manager、scheduler加上kubelet空閑狀態(tài)約2GB左右跑上業(yè)務(wù)Pod之后容易突破2.5GB。磁盤占用也有明顯差異。k3s因?yàn)楹芏嘟M件合并進(jìn)二進(jìn)制鏡像層更少整體占用約3GB-4GB。minikube因?yàn)橛斜镜冂R像緩存和集群數(shù)據(jù)占用約5GB-6GB。kubeadm單節(jié)點(diǎn)如果加上Calico、CoreDNS等鏡像也在5GB以上?？删S護(hù)性方面k3s的優(yōu)點(diǎn)是升級(jí)卸載全自動(dòng)腳本缺點(diǎn)是它封裝了不少細(xì)節(jié)以后想排查底層問題時(shí)難以直接觀察。minikube的啟動(dòng)參數(shù)最直觀但集群生命周期依賴minikube這個(gè)工具本身。kubeadm最接近原生但手工升級(jí)和排錯(cuò)負(fù)擔(dān)最重。7. 部署完成后的自測清單與高頻報(bào)錯(cuò)速查7.1 單機(jī)部署成功的硬性指標(biāo)不要只看節(jié)點(diǎn)Ready就認(rèn)為大功告成我整理了一份單機(jī)部署完成后的自測清單建議全部過一遍節(jié)點(diǎn)狀態(tài)確認(rèn)kubectl get nodes輸出Ready。系統(tǒng)組件全部Runningkubectl get pods -A里沒有Pending或CrashLoopBackOff。核心DNS解析可用創(chuàng)建一個(gè)臨時(shí)Pod執(zhí)行nslookup kubernetes.default能返回ClusterIP說明CoreDNS正常。應(yīng)用能正常調(diào)度部署一個(gè)nginx Deployment觀察Pod狀態(tài)為Running。應(yīng)用能通過Service訪問部署成功后創(chuàng)建NodePort類型的Service從外部訪問節(jié)點(diǎn)IP加端口能通。持久化能力創(chuàng)建一個(gè)PVC確認(rèn)能綁定到PV。整套清單跑下來才說明你的單機(jī)K8s環(huán)境是真正可用的而不只是“看起來裝好了”。7.2 十個(gè)常見報(bào)錯(cuò)的排查思路下面這張表格基本都是我在單機(jī)環(huán)境里踩過的真實(shí)報(bào)錯(cuò)整理成了速查表典型報(bào)錯(cuò)含義處理思路The connection to the server localhost:8080 was refusedkubectl讀不到有效kubeconfig設(shè)置KUBECONFIG環(huán)境變量或拷貝admin.conf到~/.kube/confignode NotReady網(wǎng)絡(luò)插件沒安裝或未就緒檢查CNI插件Pod狀態(tài)確認(rèn)內(nèi)核模塊br_netfilter已加載CoreDNS Pending一般因?yàn)榫W(wǎng)絡(luò)插件未運(yùn)行先裝好Calico或flannelCoreDNS會(huì)自動(dòng)調(diào)度ImagePullBackOff鏡像拉取失敗檢查鏡像名稱、標(biāo)簽、網(wǎng)絡(luò)源給容器運(yùn)行時(shí)配置鏡像加速CrashLoopBackOff容器啟動(dòng)后自行退出kubectl logs查看退出原因多半是配置錯(cuò)誤或資源不足etcd處于CrashLoopBackOffetcd啟動(dòng)失敗大概率是內(nèi)存不足或磁盤IO異常查看etcd日志確認(rèn)Kubelet服務(wù)啟動(dòng)失敗kubelet報(bào)cgroup或swap錯(cuò)誤檢查swap是否關(guān)閉cgroup驅(qū)動(dòng)是否和運(yùn)行時(shí)一致Pod一直Pending調(diào)度失敗查看describe輸出是否有taint或資源不足TCP healthz probe failedapiserver健康檢查失敗檢查系統(tǒng)時(shí)間和證書嘗試重啟apiserver靜態(tài)Podexec format errorCPU架構(gòu)和鏡像架構(gòu)不匹配換用對應(yīng)架構(gòu)的鏡像arm機(jī)器不要拉amd64鏡像如果你遇到了表中沒有的報(bào)錯(cuò)我的排查習(xí)慣是先看事件描述kubectl describe pod 名稱這里能看到Pod的完整事件鏈絕大多數(shù)問題在事件里就能定位。再不行就看容器日志kubectl logs 名稱 --previous可以看到容器上一次退出時(shí)的日志。這兩個(gè)命令基本覆蓋90%的問題。8. 這條學(xué)習(xí)路我個(gè)人建議怎么走如果讓我重新走一遍單機(jī)K8s的學(xué)習(xí)路徑我會(huì)按下面的順序來先用k3s把集群跑起來花一天時(shí)間熟悉常用kubectl命令知道如何看Pod、Service、Deployment這些基礎(chǔ)對象。然后刪掉k3s換minikube開Dashboard把PVC、Ingress、ConfigMap這些對象逐個(gè)實(shí)驗(yàn)這個(gè)階段是建立抽象概念的關(guān)鍵時(shí)期。最后再用kubeadm按生產(chǎn)方式搭一遍自己裝網(wǎng)絡(luò)插件、自己處理污點(diǎn)感受一下真實(shí)的部署復(fù)雜度。在學(xué)習(xí)過程中一定不要貪多沒必要一上來就疊加Istio、Prometheus這類生態(tài)組件。先把一個(gè)nginx跑通再把多副本和滾動(dòng)更新跑通最后再碰存儲(chǔ)和網(wǎng)絡(luò)。單機(jī)K8s學(xué)到的調(diào)度邏輯和對象模型是通用的換到多節(jié)點(diǎn)集群只是多了一些網(wǎng)絡(luò)通信細(xì)節(jié)核心概念完全一樣。我個(gè)人在實(shí)際操作中體會(huì)最深的兩個(gè)點(diǎn)一是資源規(guī)劃遠(yuǎn)比命令重要很多人失敗在內(nèi)存不足卻不自知頻繁報(bào)錯(cuò)卻找不到根因二是學(xué)會(huì)看現(xiàn)象和日志比背命令重要任何一次部署失敗的過程都是最好的學(xué)習(xí)素材。把這三條路線都親手搭一遍你會(huì)發(fā)現(xiàn)自己對Kubernetes的理解會(huì)扎實(shí)很多。這篇記錄既是備忘也希望能給你一臺(tái)服務(wù)器配置Kubernetes的實(shí)踐之路省下幾步彎路。