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