上個月幫一位朋友搭環(huán)境他手里有一批業(yè)務(wù)要從 EC2 手動部署遷到 Kubernetes團隊里沒有專職集群運維問我到底是買托管服務(wù)還是自己用 kubeadm 搭。我直接建議用 AWS EKS——Amazon Elastic Kubernetes Service。用 EKS 最大的好處是控制面由 AWS 負責apiserver、etcd、scheduler 這些組件不需要你操心你只需要管節(jié)點和應(yīng)用集群本身又是標準 Kubernetes社區(qū)工具和生態(tài)都能直接用。這篇文章沒有廢話從零開始帶你創(chuàng)建 EKS 集群包括前置準備、ClusterConfig 模板、節(jié)點組擴容、kubectl 配置再深入講 Namespace 隔離、Redis 集群部署、GPU 調(diào)用最后把生產(chǎn)環(huán)境最容易踩的坑和排查思路一并整理出來。不管你是剛學 K8s 的新手還是在自建集群和托管集群之間猶豫的老手這篇都可以當作一份能直接照做的手冊。1. 為什么我推薦用 EKS托管和自建的差別真的巨大1.1 控制面托管省下的時間成本先把概念理清楚。很多人會把 Docker 和 K8s 混在一起問Docker 是容器運行時解決單個容器怎么打包、怎么啟動的問題K8s 是容器編排平臺解決成千上萬個容器怎么調(diào)度、怎么保證服務(wù)可用性、怎么做滾動更新的問題。AWS EKS 則是 K8s 的托管版本你給它一個 VPC 區(qū)域和節(jié)點組它就幫你把 K8s 控制面全部拉起來。如果你的集群是自建的需要準備至少三臺 master 節(jié)點跑 apiserver、controller-manager、scheduler、etcd光一個 etcd 的備份、恢復、高可用就夠你喝一壺?？刂泼娴淖C書過期、etcd 磁盤空間被打滿、apiserver 被大流量請求拖垮這些故障每一個都可能把業(yè)務(wù)環(huán)境搞掛。EKS 把這些風險全部承接過去AWS 負責控制面的高可用、證書輪換、etcd 備份你只需要把精力放到節(jié)點組和業(yè)務(wù)負載上。1.2 EKS 集群的組成和賬單有哪些EKS 集群從視角上看分成三部分控制面、節(jié)點組、附加組件?？刂泼婢褪悄銏?zhí)行 kubectl 看到的那個 apiserver endpoint它分布在所選區(qū)域內(nèi)至少兩個可用區(qū)AWS 會自動管理。節(jié)點組是真正運行 Pod 的 EC2 實例可以是 Managed Node Group也可以自帶節(jié)點到集群。附加組件包括 CoreDNS、VPC CNI、kube-proxyEKS 默認會裝上也可以自定義版本。計費方面集群本身是每小時收一定的控制面費用具體金額以 AWS 官方價格頁為準。節(jié)點組里的 EC2 實例按普通的 EC2 計費EBS 卷、EIP 等資源另外算錢。沒有免費的 EKS 集群哪怕你一臺節(jié)點都不加只要控制面在跑它就在計費。所以實驗做完一定要記得刪除集群否則錢包會替你記仇。1.3 什么場景不適合 EKSEKS 不是銀彈。如果你的場景是離線環(huán)境、機房自建網(wǎng)絡(luò)到不了 AWS那顯然沒法用。如果團隊想深入掌握 Kubernetes 的每一層原理控制面被托管之后反而看不到內(nèi)部細節(jié)。還有成本敏感的小實驗環(huán)境長期跑一個自建的單節(jié)點集群成本可能比 EKS 更低。我列一張簡單的對比表方便你按需判斷對比維度自建 K8sAWS EKS控制面維護自己部署、監(jiān)控、備份AWS 托管自動高可用初始門檻需要 3 臺 master 容器運行時調(diào)優(yōu)eksctl 一條命令拉起學習價值高能徹底理解 K8s 內(nèi)部機制中等更多關(guān)注業(yè)務(wù)負載生產(chǎn)可用性需要大量運維投入天然設(shè)計為生產(chǎn)級別成本只有 EC2 成本但維護成本高每小時控制面費 EC2 成本所以我的觀點是如果你是為了快速上線業(yè)務(wù)EKS 是更劃算的選擇如果你是為了學習 K8s一定要找個自建集群練練手但別在生產(chǎn)環(huán)境拿自建硬扛。2. 創(chuàng)建集群前這些準備工作一個都不能省2.1 工具鏈安裝awscli、eksctl、kubectl創(chuàng)建 EKS 最常用的工具就三個AWS CLI、eksctl、kubectl。很多教程是從 AWS console 點出來的但點控制臺容易漏細節(jié)而且不好重復執(zhí)行。我更推薦用 eksctl 命令行的方式它是 AWS 官方推薦的集群創(chuàng)建工具底層用 CloudFormation 幫你生成資源出錯的時候可以通過 CloudFormation 日志精確排錯。安裝方式按你的系統(tǒng)來。macOS 方便一點brew install awscli brew install kubectl brew install eksctlLinux 上如果沒有包管理器可以下載二進制丟到 /usr/local/bincurl --silent --location https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz | tar xz -C /tmp sudo mv /tmp/eksctl /usr/local/bin裝完順手驗證一下版本aws --version eksctl version kubectl version --client這里有個容易忽略的小坑kubectl 的客戶端版本最好不要太老否則有些新的資源字段沒法解析。我建議使用和集群版本接近的客戶端版本比如集群是 1.30就用 1.30 或更新的 kubectl。2.2 IAM 權(quán)限模型和角色EKS 的角色體系分三層集群 IAM 角色、節(jié)點實例角色、以及執(zhí)行 kubectl 的用戶權(quán)限。集群 IAM 角色是讓 EKS 控制面可以調(diào)用 AWS API 創(chuàng)建負載均衡器、安全組等資源。這個角色需要信任 eks.amazonaws.com并且綁定 AmazonEKSClusterPolicy。節(jié)點實例角色是讓 EC2 節(jié)點能向控制面注冊從 ECR 拉鏡像使用彈性網(wǎng)卡和安全組。一般給節(jié)點綁定 AmazonEKSWorkerNodePolicy、AmazonEKS_CNI_Policy、AmazonEC2ContainerRegistryReadOnly 這幾個托管策略。創(chuàng)建 EKS 的 AWS 用戶還需要 eks:CreateCluster、eks:CreateNodegroup、iam:CreateRole、iam:PassRole 等權(quán)限。如果你不是管理員賬號建議讓管理員直接給你一個最小權(quán)限的 IAM Policy省得到創(chuàng)建一半報 AccessDenied。用 eksctl 創(chuàng)建集群時它會自動幫你創(chuàng)建第二個角色不需要你去 IAM 手工開。但如果你想用現(xiàn)有角色在 ClusterConfig 里可以指定 iam 配置生產(chǎn)審計要求嚴格的團隊通常這么做。2.3 VPC 和子網(wǎng)設(shè)計EKS 對 VPC 的要求比普通 EC2 嚴格得多?？刂泼鎰?chuàng)建的時候你要給它指定至少兩個可用區(qū)的子網(wǎng)每個子網(wǎng)必須帶特定標簽不然節(jié)點組會注冊失敗。如果你用 eksctl 默認方式創(chuàng)建它會新建一個 VPC自動分配 CIDR 和子網(wǎng)并且打上正確的標簽省心很多。但生產(chǎn)環(huán)境通常要用已有的 VPC就必須手動確認子網(wǎng)標簽存在kubernetes.io/cluster/eks-demo: owned kubernetes.io/role/elb: 1第一個標簽是讓 EKS 識別子網(wǎng)歸屬第二個標簽是讓 AWS Load Balancer 找到公網(wǎng)子網(wǎng)來部署負載均衡器。如果你只給私有子網(wǎng)跑節(jié)點還需要確認 Pod 使用的網(wǎng)段不會和 VPC 網(wǎng)段沖突。默認的 VPC CNI 會給 Pod 分配 VPC 內(nèi)空閑 IP如果 VPC 地址規(guī)劃太緊張集群一大就容易出現(xiàn) IP 耗盡。另外創(chuàng)建 VPC 時要開啟 DNS Hostnames 和 DNS Resolution否則節(jié)點解析 apiserver 域名會失敗這個問題我在排查節(jié)點加入失敗時遇到不止一次。2.4 賬號配額和后付費確認創(chuàng)建集群之前最容易被忽視的是賬號配額。比如一個區(qū)域最大 EC2 實例數(shù)量只有 20如果你選擇 3 個節(jié)點組、每組 3 臺 t3.large可能直接超過配額導致創(chuàng)建失敗。還有 VPC 數(shù)量、彈性 IP 數(shù)量都有默認配額建議提前到 Service Quotas 頁面檢查。同時確認賬號已經(jīng)正確關(guān)聯(lián)支付方式。EKS 控制面、EC2 節(jié)點都是后付費如果賬號欠費創(chuàng)建到一半直接被停掉清理起來比創(chuàng)建更麻煩。3. EKS 集群創(chuàng)建實錄一條命令并不神秘3.1 編寫可復用的 ClusterConfig我習慣用 ClusterConfig 文件管理集群配置而不是直接敲一大堆參數(shù)。它像是一份“基礎(chǔ)設(shè)施即代碼”的模板后續(xù)改節(jié)點組、加 GPU 節(jié)點只要改 YAML 再執(zhí)行就行。下面是一份我在實驗環(huán)境常用的模板apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: eks-demo region: ap-southeast-1 version: 1.30 vpc: cidr: 192.168.0.0/16 managedNodeGroups: - name: workers instanceType: t3.large desiredCapacity: 3 minSize: 2 maxSize: 6 privateNetworking: true ssh: allow: true publicKeyName: my-key解釋幾個關(guān)鍵字段version填你希望創(chuàng)建的 K8s 版本創(chuàng)建前先到 EKS 支持的版本列表里確認。vpc.cidr是自定義 VPC 網(wǎng)段如果你不寫eksctl 會用默認 192.168.0.0/16。managedNodeGroups表示托管節(jié)點組由 EKS 自動管理 Auto Scaling 和節(jié)點更新。privateNetworking: true讓節(jié)點只使用私有子網(wǎng)公網(wǎng)訪問通過負載均衡器出去安全性和網(wǎng)絡(luò)成本都更好。之后執(zhí)行eksctl create cluster -f cluster.yaml執(zhí)行過程大約 15 到 20 分鐘。它會先創(chuàng)建一個 CloudFormation 棧里面包含 VPC、IAM、控制面和節(jié)點組。中途會輸出類似waiting for the control plane to become ready的日志。如果創(chuàng)建失敗到 CloudFormation 控制臺看具體哪一個資源報錯是角色權(quán)限還是網(wǎng)絡(luò)配置定位非常直接。3.2 集群創(chuàng)建后的健康檢查創(chuàng)建完不要急著部署應(yīng)用先做一輪基本健康檢查。eksctl get cluster --region ap-southeast-1 kubectl get nodes正常情況下你會看到節(jié)點處于 Ready 狀態(tài)。再看控制面相關(guān)的 Pod 是否正常kubectl get pods -n kube-systemkube-system 里通常有 aws-node、coredns、kube-proxy這些 Pod 的 READY 應(yīng)該都是 1/1。如果 coredns 一直 Pending八成是節(jié)點資源不足或者安全組阻止了 DNS 流量。這里要說明一下EKS 是托管控制面你不會在 EKS 里看到 kube-controller-manager、etcd 這些 Pod它們運行在 AWS 托管的組件里。所以如果你看到網(wǎng)上有人用一個命令初始化 Kubernetes master然后報出the api server is not healthy after 4m0.00747357s那是在自建 kubeadm 環(huán)境里的情況EKS 控制面不會出現(xiàn)這個報錯。3.3 節(jié)點組擴容和加 GPU 節(jié)點業(yè)務(wù)量漲了怎么辦托管節(jié)點組支持兩種方式擴容手動調(diào)整期望數(shù)量或者啟用 Cluster Autoscaler。手動擴縮容只要一條命令eksctl scale nodegroup --cluster eks-demo --name workers --nodes 5這是把 desiredCapacity 調(diào)整為 5。如果你沒有指定--nodes-max實際節(jié)點組里還能靠 ASG 自動擴張。想加一個 GPU 節(jié)點組比如跑推理任務(wù)就在 ClusterConfig 里再加一組- name: gpu-workers instanceType: g4dn.xlarge desiredCapacity: 1 minSize: 1 maxSize: 2 privateNetworking: true然后執(zhí)行eksctl create nodegroup --config-file cluster.yaml這里需要注意GPU 節(jié)點組必須使用 EKS 的 GPU 優(yōu)化 AMIeksctl 默認會選對。如果你想手動給節(jié)點打標簽可以在 nodeGroup 里加 labels 字段比如accelerator: nvidia后續(xù)調(diào)度 GPU 任務(wù)會用到。3.4 如果創(chuàng)建到一半失敗了怎么辦創(chuàng)建失敗大概率是角色權(quán)限、子網(wǎng)標簽、配額、以及安全組規(guī)則的問題。第一反應(yīng)應(yīng)該是看 CloudFormation 事件。aws cloudformation describe-stack-events \ --stack-name eksctl-eks-demo-cluster \ --region ap-southeast-1查看RESOURCE_STATUS_REASON字段里面通常會直接告訴你哪個資源失敗比如VPC does not have DNS hostname attributes enabled。修復之后再重新執(zhí)行創(chuàng)建命令。刪除失敗的集群不要直接在 console 里東刪一個西刪一個用命令清理干凈eksctl delete cluster --name eks-demo --region ap-southeast-1它會連帶刪除 CloudFormation 棧里的負載均衡器、數(shù)據(jù)庫避免留下孤兒資源繼續(xù)計費。4. 從創(chuàng)建到上線部署應(yīng)用、隔離、Redis 與 GPU4.1 kubectl 配置和驗證用 eksctl 創(chuàng)建集群成功之后它會自動把 kubeconfig 寫到默認位置但如果你在別的機器上想連接集群可以用 AWS CLI 重新生成aws eks update-kubeconfig --region ap-southeast-1 --name eks-demo --alias eks-demo然后執(zhí)行kubectl get namespace如果能看到 kube-system、default、kube-public說明連接成功了。在環(huán)境變量或 kubeconfig 里設(shè)置 context 別名的好處是多個集群切換的時候不會迷路。實際操作中我發(fā)現(xiàn)很多人連不通是因為 IAM 用戶沒有eks:DescribeCluster權(quán)限執(zhí)行 update-kubeconfig 時報 AccessDenied。這個問題只要給用戶加上 eks 相關(guān)只讀權(quán)限就行不用太復雜。4.2 用 Namespace 做環(huán)境隔離K8s 里很基礎(chǔ)也很重要的一個概念就是 Namespace。很多人會把 Namespace 當成環(huán)境隔離的唯一手段但它其實是邏輯隔離不是硬隔離。比如你可以創(chuàng)建 dev、staging、prod 三個 Namespace讓業(yè)務(wù)資源各歸各的但底層網(wǎng)絡(luò)和計算資源還是共享的。在 EKS 里創(chuàng)建 Namespace 直接一條命令kubectl create namespace dev kubectl create namespace prod但我更建議用文件方式管理方便審查apiVersion: v1 kind: Namespace metadata: name: dev --- apiVersion: v1 kind: ResourceQuota metadata: name: dev-quota namespace: dev spec: hard: requests.cpu: 4 requests.memory: 8Gi limits.cpu: 8 limits.memory: 16Gi pods: 10ResourceQuota 是 Namespace 隔離的關(guān)鍵沒有配額機制一個 Namespace 里的業(yè)務(wù)很容易把整個集群的資源吃光。我一般會給 dev、staging、prod 配不同的配額再配合 LimitRange 設(shè)置默認 requests 和 limits這樣哪怕開發(fā)者忘寫資源請求也不會裸奔。4.3 部署一個 Web 服務(wù)并暴露到公網(wǎng)部署一個簡單的 Nginx 服務(wù)感受一下完整的應(yīng)用上線路徑。先創(chuàng)建 DeploymentapiVersion: apps/v1 kind: Deployment metadata: name: nginx-demo namespace: prod spec: replicas: 3 selector: matchLabels: app: nginx-demo template: metadata: labels: app: nginx-demo spec: containers: - name: nginx image: nginx:1.27-alpine ports: - containerPort: 80 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 256Mi執(zhí)行kubectl apply -f nginx-demo.yaml之后Service 用 LoadBalancer 類型暴露出來apiVersion: v1 kind: Service metadata: name: nginx-demo-svc namespace: prod spec: selector: app: nginx-demo ports: - port: 80 targetPort: 80 type: LoadBalancerEKS 會自動創(chuàng)建一個 AWS 負載均衡器等kubectl get svc -n prod看到 EXTERNAL-IP 變成實際地址就可以訪問了。這個方案適合單個服務(wù)暴露如果服務(wù)多了建議裝 AWS Load Balancer Controller用 Ingress 統(tǒng)一管理路由和 TLS 證書。4.4 在 EKS 上部署 Redis Cluster很多人問 Redis 能不能跑在 K8s 里答案當然能而且 EKS 上跑 Redis Cluster 是很典型的場景。我這里的方案是使用 StatefulSet給每個 Redis 實例一個穩(wěn)定的網(wǎng)絡(luò)標識和獨立存儲卷。三個 master 節(jié)點的 Redis Cluster 最小結(jié)構(gòu)是3 個 StatefulSet 副本每個副本配一個 headless service讓 Pod 之間可以通過類似redis-0.redis-headless.prod.svc.cluster.local的域名互相發(fā)現(xiàn)。關(guān)鍵文件片段apiVersion: apps/v1 kind: StatefulSet metadata: name: redis-cluster namespace: prod spec: serviceName: redis-headless replicas: 6 selector: matchLabels: app: redis-cluster template: metadata: labels: app: redis-cluster spec: containers: - name: redis image: redis:7-alpine command: - /bin/sh - -c - redis-server --cluster-enabled yes --cluster-config-file /data/nodes.conf --cluster-node-timeout 5000 --appendonly yes記得掛載 PVC不然節(jié)點重建秒變空庫。Redis 的 Cluster 初始化也很有意思需要先用redis-cli --cluster create把所有節(jié)點的 IP 或域名加進去形成槽位分配之后才能真正執(zhí)行 KV 請求。我踩過的坑是 headless service 的端口沒有定義 clusterIP: None或者選舉用的 port 沒有暴露導致節(jié)點間找不到彼此。這種問題用redis-cli --cluster check能很快定位到時哪個節(jié)點缺席。4.5 讓 K8s 成功調(diào)用 GPU跑 AI 推理、模型訓練核心訴求是讓 K8s 的調(diào)度器感知 GPU 資源。在 EKS 上要分三步走。第一步創(chuàng)建 GPU 節(jié)點組實例類型選擇g4dn.xlarge或者更高型號。這個在 3.3 里提到過不再重復。第二步安裝 NVIDIA device plugin讓節(jié)點上的 GPU 數(shù)量以擴展資源的形式暴露給 K8s。官方倉庫有一條現(xiàn)成的 DaemonSet執(zhí)行kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.15.0/nvidia-device-plugin.yml安裝完成后查看節(jié)點資源kubectl describe node g4dn-instance你應(yīng)該能看到nvidia.com/gpu: 1這樣的可調(diào)度資源。第三步在應(yīng)用里聲明 GPU 請求resources: limits: nvidia.com/gpu: 1調(diào)度器看到這個字段就會把 Pod 調(diào)度到有 GPU 的節(jié)點上。EKS 的 GPU 節(jié)點組一般預裝了 NVIDIA 驅(qū)動如果你用的是自定義 AMI還需要自己處理驅(qū)動和 ec2 實例類型匹配的問題。5. 那些年我踩過的 EKS/K8s 故障坑5.1 API Server “not healthy” 到底是怎么回事很多人在學習 K8s 初始化時會在 kubeadm init 階段看到這個報錯the api server is not healthy after 4m0.00747357s我為什么對這個時間戳印象深因為第一次在 Rocky 系統(tǒng)上自建集群就卡在這里徹底崩了一次。這個問題幾乎都和 kubelet 或容器運行時有關(guān)特別是 containerd 的配置沒跟上對應(yīng) K8s 版本的 pause 鏡像。常見排查路徑是systemctl status kubelet containerd journalctl -xeu kubelet | tail -200 crictl ps -a重點看 containerd 報的image pull failed如果 pause 鏡像版本不匹配就把 sandbox_image 改掉再重啟 containerd。說實話這類問題讓你難受但你解一遍之后對 K8s 控制面的理解會比原來深很多。在 EKS 里不會看到這個錯誤因為控制面是 AWS 管的。但如果你自己搭的節(jié)點訪問不到 EKS 的 apiserver會看到節(jié)點狀態(tài) NotReadykubelet 日志里一直報連接超時。這種時候優(yōu)先檢查安全組節(jié)點到 443 端口是否放行再看節(jié)點上的 aws-vpc-cni 是否正常。5.2 節(jié)點組加入失敗的幾個隱蔽原因節(jié)點組已經(jīng)創(chuàng)建但節(jié)點一直沒有 NotReady是最頭疼的。我排查過太多現(xiàn)場發(fā)現(xiàn)幾個高頻原因。子網(wǎng)標簽缺失是第一大坑。EKS 是靠子網(wǎng)上的kubernetes.io/cluster/cluster-name標簽來識別能不能用于集群的。如果你用的是已有 VPC沒打標簽節(jié)點組創(chuàng)建出來了但控制面不認子網(wǎng)自然注冊不了。第二個是節(jié)點實例角色的權(quán)限不夠。如果你只綁定了一個AmazonSSMManagedInstanceCore而漏掉了AmazonEKSWorkerNodePolicy節(jié)點無法從控制面拿到調(diào)度配置就一直卡在初始化。第三個是節(jié)點所在的安全組把 kubelet 到 apiserver 的 443 端口擋了。很多企業(yè)安全策略默認只開放 80/443/3389結(jié)果 kubelet 連接控制面被攔死。解決方法是把控制面安全組加到節(jié)點安全組的入方向白名單里。5.3 Pod 起不來、老被驅(qū)逐怎么辦Pod 啟動不起來最典型的場景是 Pending。執(zhí)行kubectl describe pod的時候Events 部分會把原因?qū)懬宄?。最常見的是Insufficient cpu/memory說明節(jié)點資源不夠或者你的 requests 設(shè)得太高。還有一種是FailedScheduling因為沒有節(jié)點滿足 nodeSelector、親和性、或者容忍度要求。比如你部署 GPU 工作負載Pod 明明聲明了 nvidia.com/gpu但集群里沒有 GPU 節(jié)點調(diào)度器當然不會給面子。Pod 被驅(qū)逐要分情況看待。如果節(jié)點本身內(nèi)存壓力高kubelet 會率先驅(qū)逐使用量超過 limits 的容器。生產(chǎn)環(huán)境里常見的故障就是開發(fā)者忘了設(shè)置 requests 和 limits某一個容器瘋狂吃內(nèi)存觸發(fā)整節(jié)點 OOM然后所有 Pod 被拖累。解決方式不復雜所有 workload 都要寫資源配額再按 HPA 或 Cluster Autoscaler 應(yīng)對增量。5.4 生產(chǎn)故障怎么影響用戶的我的一次真實 CPU 吃滿事故有一回我接手一個 EKS 集群線上用戶投訴服務(wù)白屏打開監(jiān)控發(fā)現(xiàn)節(jié)點 CPU 已經(jīng)無限接近 100%。原因是多個 Java 服務(wù)共享一個節(jié)點組而它們的 Deployment 全部沒有設(shè)置 CPU limitsG1 GC 在某些版本下會瘋狂占 CPU節(jié)點很快被打穿Pod 全部進入 CPUThrottled 狀態(tài)延遲飆升。當時排查的順序是先用kubectl top nodes看節(jié)點負載再用kubectl top pods -n prod --sort-bycpu找到吃 CPU 的 Pod最后把服務(wù)拆到獨立的節(jié)點組并加了如下配置resources: requests: cpu: 500m memory: 512Mi limits: cpu: 2 memory: 1Gi這個事給我的教訓是節(jié)點資源不是無限的應(yīng)用一定要設(shè)置 requests 和 limits同時生產(chǎn)集群必須搭配監(jiān)控和告警像kubectl top只是臨場急救真正的容量規(guī)劃要靠 Prometheus 的數(shù)據(jù)積累才能提前發(fā)現(xiàn)風險。5.5 Rocky 上自建 K8s 的翻車記錄這個話題和 EKS 無關(guān)但很多人在學習 K8s 時都會經(jīng)歷從 EKS 到自建的跨越所以還是寫一下。朋友在 Rocky Linux 上用 kubeadm 安裝某個新版本 K8s集群初始化之后同樣報了the api server is not healthy。我遠程過去看發(fā)現(xiàn) containerd 啟動正常但 kubelet 一直看不到靜態(tài) Pod最終查出來是 containerd 的 sandbox_image 拉取 pause 鏡像失敗。解決方法是修改/etc/containerd/config.toml里的sandbox_image換成與當前 K8s 版本兼容的 pause 鏡像地址然后重載 containerd清理臨時文件再重新 reset 后 init。自建集群就要接受這種時不時折騰一下的事實但這也反過來提醒我EKS 托管控制面的價值不只是省時間更是把這類基礎(chǔ)環(huán)境的穩(wěn)定性外包給 AWS 的 SRE。6. 學習 K8s 的資料和環(huán)境建議6.1 別只囤 PDF動手練起來網(wǎng)上經(jīng)常有人找《K8s 權(quán)威指南》的 PDF我應(yīng)該也翻過老版本內(nèi)容確實系統(tǒng)但這本書再厚也只是幫你建立概念真正學會 K8s 只有一條路自己在真實集群里反復打命令。我建議照著這篇教程建一個 EKS 集群然后立刻開始跑 Deployment、Service、StatefulSet再故意刪掉幾個 Pod 看看發(fā)生了什么體會一下什么叫自愈。做實驗的時候可以把每天用到的命令記成學習筆記。比如記錄kubectl get events --sort-by.lastTimestamp怎么看調(diào)度事件或者kubectl rollout status deployment/nginx-demo怎么等發(fā)布完成。這些筆記積累起來比任何一本教程都有用。6.2 把 EKS 理解為 K8s 的“套餐”用 EKS 越久越發(fā)現(xiàn)托管服務(wù)雖然方便但它只是 You 獲得標準 K8s 的一種途徑。如果你只會用 eksctl 創(chuàng)建集群不理解 master 節(jié)點在做什么遇到奇奇怪怪的網(wǎng)絡(luò)問題還是會懵圈。我建議學完 EKS 之后用 kubeadm 在虛擬機或者本地環(huán)境自建一個單節(jié)點集群體驗一下證書生成、etcd 啟動、kubelet static Pod 這些過程。等碰到 kubeadm init 報not healthy這些錯誤時別煩躁那是在給你補課。每一類報錯背后都隱藏著 K8s 某個機制的原理解決了它你對集群的理解才算真正到位。我現(xiàn)在電腦里還存著第一次創(chuàng)建 EKS 集群時用的 cluster.yaml每次打開都能想起那天晚上反復刪槽、重建、等狀態(tài)的折騰。如果你正準備創(chuàng)建自己的第一個 EKS 集群希望這篇教程能幫你少踩幾個坑。記住創(chuàng)建成功只是開始監(jiān)控、配額、升級演練這些東西越早準備后面越輕松。