從 “容器保姆” 到 “云原生王者”：K8s 全方位指南

開頭專業總結

一、先搞懂：K8s 到底是什么？能解決什么痛點？

1. K8s 的本質

2. 核心用處（解決的痛點）

二、K8s 核心知識點：組件與概念（標重點！）

（一）集群核心組件（K8s 的 “器官”）

（二）核心概念（K8s 的 “詞匯表”）

三、實際應用場景：K8s 到底用在哪？

四、簡單示例：用 K8s 部署一個 Nginx

1. 編寫 Deployment YAML（定義 Nginx 應用）

2. 編寫 Service YAML（給 Nginx 分配固定地址）

3. 執行命令部署并驗證

五、K8s 常用使用方法（從安裝到運維）

1. 集群安裝（以 kubeadm 為例，最常用的方式）

2. 日常運維常用命令

六、常見問題及解決方法（排障必備）

1. 問題：Pod 一直處于 Pending 狀態

2. 問題：Service 訪問不到 Pod

3. 問題：節點處于 NotReady 狀態

七、難點段子解讀：讓硬核概念變通俗

1. 難點：etcd 的 “一致性” 是什么意思？

2. 難點：Deployment 和 StatefulSet 的區別？

3. 難點：kube-proxy 的 “Service 轉發” 怎么實現？

結尾專業總結

開頭專業總結

Kubernetes（簡稱 K8s）是云原生時代的 “容器編排事實標準”，核心價值是解決大規模容器的部署、調度、運維自動化問題—— 它能讓零散的容器像 “軍隊” 一樣有序運行，避免人工管理的混亂與失誤。無論是微服務架構落地、跨環境應用一致性保障，還是高可用集群搭建，K8s 都是底層核心支撐，目前已成為企業級云原生部署的 “標配工具”。

一、先搞懂：K8s 到底是什么？能解決什么痛點？

1. K8s 的本質

K8s 是 Google 基于 Borg（內部容器編排系統）開源的容器編排平臺，簡單說就是 “容器的管家”：你把容器交給它，它負責 “安排住宿（調度到節點）、看病（健康檢查）、換班（滾動更新）、擴招（擴容）”，全程不用你手動干預。

2. 核心用處（解決的痛點）

痛點 1：容器太多管不過來
單機跑 10 個容器還行，跑 1000 個時，手動啟停、監控、故障恢復會累死 ——K8s 能自動化管理所有容器，故障時自動重啟，不用人盯。
痛點 2：應用要高可用，不能單節點掛了就跪
K8s 能把容器分散到多個節點（服務器），一個節點掛了，其他節點自動接管，應用不中斷。
痛點 3：微服務部署復雜，服務間通信亂
K8s 的 Service、Ingress 等組件能統一管理服務訪問，不管容器怎么動，外部訪問地址不變，解決 “服務漂移” 問題。
痛點 4：環境不一致，開發測好生產崩
K8s 用 YAML 定義應用配置，一次編寫可在開發、測試、生產環境復用，避免 “我這好的，到你那就崩了”。

二、K8s 核心知識點：組件與概念（標重點！）

（一）集群核心組件（K8s 的 “器官”）

1. 控制平面組件（Master 節點，集群 “大腦”）

APIServer：★★★★★ 唯一入口！所有操作（如部署應用、查 Pod 狀態）都通過它，像 “前臺接待”，接收請求后交給其他組件處理。
etcd：★★★★★ 集群 “數據庫”！存儲所有集群配置和狀態（如 Pod 在哪、Service 地址），是 K8s 的 “記憶中樞”，必須高可用（多節點備份）。
Scheduler：★★★★ 容器 “調度員”！根據節點資源（CPU、內存）、親和性規則等，給新創建的 Pod 分配 “住宿節點”（比如 “內存剩得多的節點優先”）。
Controller Manager：★★★★ 狀態 “監控官”！負責維護集群狀態，比如 Deployment 控制器確保 Pod 數量符合預期（少了就新建，多了就刪除）、Node 控制器監控節點健康。

2. 節點組件（Worker 節點，集群 “手腳”）

kubelet：★★★★★ 節點 “管家”！在每個 Worker 節點運行，確保容器按 Pod 定義的規則啟動并正常運行，還會向 APIServer 匯報節點狀態（比如 “我這 CPU 用了 80%”）。
kube-proxy：★★★★ 網絡 “路由器”！在每個節點運行，負責 Service 的網絡轉發（比如把外部請求轉發到對應的 Pod），實現 “服務 IP 不變，Pod 可漂移”。
容器運行時（CRI）：★★★★ 容器 “發動機”！比如 Docker、containerd，負責實際創建和運行容器（K8s 本身不跑容器，靠它干活）。

（二）核心概念（K8s 的 “詞匯表”）

Pod：★★★★★ 最小部署單元！K8s 不直接管理容器，而是把 1 個或多個 “緊密關聯” 的容器打包成 Pod（比如 “前端容器 + 日志收集容器”），Pod 里的容器共享網絡和存儲，像 “夫妻合租一間房，資源共用”。
Deployment：★★★★★ 無狀態應用 “部署模板”！最常用的控制器，負責創建 Pod、滾動更新（比如從 Nginx 1.20 更到 1.24，不中斷服務）、回滾（更新崩了就切回舊版本）。適合無狀態應用（如 Web 服務，不用保存數據）。
StatefulSet：★★★★ 有狀態應用 “專屬控制器”！適合需要固定身份、存儲的應用（如 MySQL、Redis 集群）—— 它給每個 Pod 分配固定名稱和存儲，即使 Pod 重建，身份和數據也不變（像 “學區房，房號固定，家具（數據）不丟”）。
Service：★★★★ 服務 “固定地址”！Pod 會漂移（比如重建后 IP 變了），Service 給一組 Pod 分配一個固定虛擬 IP（ClusterIP），外部訪問 Service 即可，不用管 Pod IP 怎么變。
ConfigMap/Secret：★★★★ 配置管理工具！
- ConfigMap：存明文配置（如 Nginx 的 conf 文件、應用的環境變量），修改時不用改應用代碼，直接更 ConfigMap。
- Secret：存敏感信息（如數據庫密碼、API 密鑰），會把明文加密存儲，比直接寫在 YAML 里安全。
Namespace：★★★ 資源 “隔離墻”！把集群分成多個 “虛擬空間”（如 dev、test、prod），避免不同環境的資源沖突（比如 dev 的 Nginx 和 prod 的 Nginx 不會重名）。
Ingress：★★★★ 外部訪問 “總入口”！Service 只能用 ClusterIP（集群內訪問）或 NodePort（節點端口，端口范圍有限），Ingress 可通過域名（如www.xxx.com）和路徑（如 /nginx）轉發請求到不同 Service，像 “小區大門保安，按訪客目的地分配樓棟”。

三、實際應用場景：K8s 到底用在哪？

微服務架構落地
微服務拆分后有幾十上百個服務（如用戶服務、訂單服務、支付服務），K8s 用 Deployment 部署每個服務，Service 實現服務間通信，Ingress 管理外部訪問，輕松應對微服務的動態擴縮容。
? 例：電商平臺，大促時訂單服務壓力大，K8s 自動把訂單服務的 Pod 從 5 個擴到 20 個，大促后縮回 5 個，節省資源。
跨環境應用一致性
開發、測試、生產環境用相同的 K8s YAML 配置，避免 “開發測好，生產崩了”—— 比如開發寫好 Nginx 的 Deployment YAML，測試環境用它部署，生產環境只改 ConfigMap 里的數據庫地址，保證應用行為一致。
高可用集群搭建
K8s 控制平面多節點部署（比如 3 個 Master 節點），etcd 多節點備份，Worker 節點跨機房分布，即使某個機房斷電，其他節點能繼續運行，應用零中斷。
CI/CD 流水線集成
結合 Jenkins、GitLab CI 等工具，實現 “代碼提交→自動構建鏡像→K8s 自動部署” 的全流程自動化（比如程序員提交代碼后，不用手動傳鏡像到生產，K8s 自動拉取新鏡像更新應用）。

四、簡單示例：用 K8s 部署一個 Nginx

1. 編寫 Deployment YAML（定義 Nginx 應用）

創建nginx-deploy.yaml文件，內容如下（關鍵配置已注釋）：

yaml

apiVersion: apps/v1  # API版本
kind: Deployment     # 資源類型（Deployment）
metadata:name: nginx-deploy # Deployment名稱
spec:replicas: 2        # 要創建的Pod數量（2個，高可用）selector:          # 匹配Pod的標簽（找到要管理的Pod）matchLabels:app: nginxtemplate:          # Pod模板（定義Pod里的容器）metadata:labels:app: nginx   # Pod的標簽（和上面selector對應）spec:containers:- name: nginx  # 容器名稱image: nginx:1.24 # 容器鏡像（用Nginx 1.24版本）ports:- containerPort: 80 # 容器暴露的端口（Nginx默認80）resources:    # 資源限制（避免容器占滿節點資源）limits:cpu: "0.5" # 最大CPU（0.5核）memory: "512Mi" # 最大內存（512MB）requests:cpu: "0.2" # 最小CPU（0.2核）memory: "256Mi" # 最小內存（256MB）

2. 編寫 Service YAML（給 Nginx 分配固定地址）

創建nginx-svc.yaml文件，內容如下：

yaml

apiVersion: v1
kind: Service
metadata:name: nginx-svc
spec:type: NodePort  # 類型（NodePort：集群外可通過節點IP+端口訪問）selector:app: nginx    # 匹配標簽為app:nginx的Podports:- port: 80      # Service的端口（集群內訪問用）targetPort: 80 # 轉發到Pod的端口（和容器暴露的端口一致）nodePort: 30080 # 節點暴露的端口（集群外訪問用，范圍30000-32767）

3. 執行命令部署并驗證

# 1. 創建Deployment（啟動2個Nginx Pod）
kubectl apply -f nginx-deploy.yaml# 2. 創建Service（分配訪問地址）
kubectl apply -f nginx-svc.yaml# 3. 查看Pod狀態（確保STATUS是Running）
kubectl get pods
# 輸出類似：
# NAME                            READY   STATUS    RESTARTS   AGE
# nginx-deploy-7f98d7c6b4-2xqzk   1/1     Running   0          2m
# nginx-deploy-7f98d7c6b4-5k87x   1/1     Running   0          2m# 4. 查看Service狀態（獲取NodePort）
kubectl get svc nginx-svc
# 輸出類似：
# NAME         TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
# nginx-svc    NodePort   10.96.123.45   <none>        80:30080/TCP   1m# 5. 集群外訪問（用節點IP+30080端口）
curl http://節點IP:30080
# 輸出Nginx默認頁面，說明部署成功！

五、K8s 常用使用方法（從安裝到運維）

1. 集群安裝（以 kubeadm 為例，最常用的方式）

# 1. 準備3臺服務器（1臺Master，2臺Worker，系統CentOS 7/8或Ubuntu 20.04+）
# 2. 每臺服務器初始化（關閉防火墻、禁用Swap、配置主機名等）
systemctl stop firewalld && systemctl disable firewalld
swapoff -a && sed -i '/swap/s/^/#/' /etc/fstab# 3. 安裝Docker/containerd（容器運行時）
yum install -y docker && systemctl start docker && systemctl enable docker# 4. 安裝kubeadm、kubelet、kubectl（K8s工具集）
cat > /etc/yum.repos.d/kubernetes.repo << EOF
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=0
EOF
yum install -y kubelet-1.26.0 kubeadm-1.26.0 kubectl-1.26.0
systemctl start kubelet && systemctl enable kubelet# 5. 初始化Master節點（--pod-network-cidr是網絡插件的網段，用calico就填192.168.0.0/16）
kubeadm init --image-repository registry.aliyuncs.com/google_containers --pod-network-cidr=192.168.0.0/16# 6. 配置kubectl（Master節點執行，讓當前用戶能操作集群）
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config# 7. 安裝網絡插件（calico，必須裝，否則Pod間不能通信）
kubectl apply -f https://docs.projectcalico.org/v3.25/manifests/calico.yaml# 8. Worker節點加入集群（Master初始化成功后會輸出join命令，類似下面）
kubeadm join 192.168.1.100:6443 --token abcdef.0123456789abcdef \--discovery-token-ca-cert-hash sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef

2. 日常運維常用命令

命令	作用
`kubectl get pods [-n 命名空間]`	查看 Pod 狀態（加 - n 指定命名空間，如 - n dev）
`kubectl get deployments`	查看 Deployment 狀態
`kubectl get svc`	查看 Service 狀態
`kubectl describe pod <Pod名稱>`	查看 Pod 詳情（排障用，比如 Pod 啟動失敗原因）
`kubectl logs <Pod名稱> [-c <容器名>]`	查看 Pod 日志（容器名可選，多容器時需要指定）
`kubectl scale deployment <Deployment名> --replicas=5`	擴容 Pod 到 5 個
`kubectl set image deployment <Deployment名> <容器名>=<新鏡像>`	更新容器鏡像（滾動更新）
`kubectl delete pod <Pod名稱>`	刪除 Pod（Deployment 會自動重建，用于測試自愈）

六、常見問題及解決方法（排障必備）

1. 問題：Pod 一直處于 Pending 狀態

原因 1：節點資源不足（CPU / 內存不夠）
解決：用kubectl describe pod <Pod名>看 Events，若顯示 “Insufficient cpu” 或 “Insufficient memory”，則擴容節點資源，或減少 Pod 的資源請求（修改 YAML 里的 resources.requests）。
原因 2：節點有污點（Taint），Pod 沒有容忍（Toleration）
解決：查看節點污點kubectl describe node <節點名> | grep Taint，若有污點（如 node-role.kubernetes.io/master，Master 節點默認不讓跑 Pod），則給 Pod 加容忍（在 YAML 的 spec 下加 tolerations 字段）。

2. 問題：Service 訪問不到 Pod

原因 1：Service 的 selector 和 Pod 的 label 不匹配（“找錯人了”）
解決：檢查 Service 的 selector（kubectl get svc <Svc名> -o yaml）和 Pod 的 label（kubectl get pods <Pod名> -o yaml | grep labels），確保一致。
原因 2：Pod 沒就緒（READY 狀態是 0/1）
解決：用kubectl logs <Pod名>看容器日志，排查容器啟動失敗原因（比如配置錯誤、端口被占）。

3. 問題：節點處于 NotReady 狀態

原因：網絡插件沒裝或沒啟動（最常見）
解決：查看網絡插件 Pod 狀態kubectl get pods -n kube-system | grep calico（若用 calico），若沒運行則重新安裝網絡插件；或檢查節點網絡是否通（Master 和 Worker 之間能 ping 通 6443 端口）。

七、難點段子解讀：讓硬核概念變通俗

1. 難點：etcd 的 “一致性” 是什么意思？

段子：小區選業委會，規定 “必須超過一半業主到場投票，且同意票超過一半才算通過”——etcd 就像小區投票系統，集群里的 etcd 節點（業主）要對 “Pod 狀態更新”“Service 創建” 等操作投票，只有超過一半節點同意，操作才會生效，確保所有節點存儲的數據一致（不會出現 “這個節點說 Pod 在 A 節點，那個節點說在 B 節點”）。

2. 難點：Deployment 和 StatefulSet 的區別？

段子：Deployment 管理的 Pod 是 “出租屋租客”—— 你租的房子沒固定編號，今天住 301，明天房東讓你搬 302，你無所謂（反正東西少，搬起來方便）；
StatefulSet 管理的 Pod 是 “學區房業主”—— 房子編號固定（比如 1 號樓 101），房產證（存儲）和編號綁定，就算房子塌了重建，還是 1 號樓 101，你的家具（數據）還在（適合 MySQL 這種 “認地址” 的應用，換了地址數據庫就連不上了）。

3. 難點：kube-proxy 的 “Service 轉發” 怎么實現？

段子：小區里有個 “快遞代收點”（Service），代收點的電話是固定的（ClusterIP），不管快遞員（外部請求）找誰，只要報 “代收點電話”，代收點就會根據 “收件人名單”（selector 匹配 Pod）把快遞送到對應的住戶（Pod）手里 —— 哪怕住戶換了房間（Pod IP 變了），只要收件人名單沒改，代收點照樣能送對。

結尾專業總結

K8s 的核心優勢在于自動化、可擴展、高可用，它不僅是容器編排工具，更是云原生應用的 “操作系統”。對于初學者，建議先從 “核心概念（Pod、Deployment、Service）” 和 “簡單部署示例” 入手，再逐步深入集群運維和高級特性（如 StatefulSet、Ingress、監控告警）。需注意：K8s 不是 “銀彈”，小規模應用（如單機跑 1 個容器）用它反而增加復雜度，需根據業務規模決定是否引入。隨著云原生技術的發展，K8s 會持續和 AI 運維、Serverless 等結合，成為更易用、更智能的底層平臺。