背景與問題

在日常運維工作中，經(jīng)常遇到開發(fā)團隊反饋 Service 無法訪問、POD 無法啟動、Pod 之間通信異常等問題。這些問題的根因往往不在應(yīng)用層，而在于 Kubernetes 核心工作流的理解偏差。本文從一線運維視角出發(fā)，系統(tǒng)講解從 Deployment 到 Service 的完整數(shù)據(jù)流，剖析每個環(huán)節(jié)的工作原理、常見故障點以及排障方法。

本文基于 Kubernetes 1.29 版本編寫，操作系統(tǒng)環(huán)境為 CentOS Stream 9 或 Ubuntu 24.04 LTS，容器運行時為 containerd 1.7.x。所有命令和配置均經(jīng)過實際環(huán)境驗證。

一、Kubernetes 核心資源對象解析

1.1 Workload 與 WorkloadResources 的區(qū)分

Kubernetes 將資源對象分為 Workload 和 WorkloadResources 兩大類別。Workload 是運行應(yīng)用的工作負(fù)載，WorkloadResources 則是支持工作負(fù)載運行的其他資源。

Workload 資源包括 Deployment、StatefulSet、DaemonSet、Job、CronJob 等。這些資源負(fù)責(zé)管理 Pod 的創(chuàng)建、調(diào)度和生命周期。

WorkloadResources 包括 Service、ConfigMap、Secret、PersistentVolumeClaim、ServiceAccount 等。這些資源為 Pod 提供網(wǎng)絡(luò)、存儲、配置等支撐能力。

理解這個分類是理解 K8s 工作流的基礎(chǔ)。很多新手混淆了這兩類資源的作用域，導(dǎo)致配置錯誤。

1.2 Deployment 的本質(zhì)與作用

Deployment 是 Kubernetes 最常用的 Workload 資源，其核心職責(zé)是管理 ReplicaSet，而 ReplicaSet 才是真正管理 Pod 的資源。

Deployment 的主要功能包括：

第一，聲明式更新。通過 spec.replicas 和 spec.template 定義期望狀態(tài)，Kubernetes 控制器會自動將實際狀態(tài)調(diào)整為期望狀態(tài)。

第二，版本管理。每次 Deployment 更新都會創(chuàng)建一個新的 ReplicaSet，保留了版本回滾的能力。

第三，并行滾動更新。通過 strategy.rollingUpdate 參數(shù)控制更新過程中的最大不可用 Pod 數(shù)量和最大 Surplus Pod 數(shù)量。

查看一個標(biāo)準(zhǔn) Deployment 的 YAML 定義：

apiVersion:apps/v1
kind:Deployment
metadata:
name:nginx-deployment
namespace:default
labels:
 app:nginx
spec:
replicas:3
selector:
 matchLabels:
  app:nginx
strategy:
 type:RollingUpdate
 rollingUpdate:
  maxUnavailable:1
  maxSurge:1
template:
 metadata:
  labels:
   app:nginx
 spec:
  containers:
  -name:nginx
   image:nginx:1.27-alpine
   ports:
   -containerPort:80
   resources:
    limits:
     memory:"256Mi"
     cpu:"500m"
    requests:
     memory:"128Mi"
     cpu:"100m"
   livenessProbe:
    httpGet:
     path:/
     port:80
    initialDelaySeconds:10
    periodSeconds:10
   readinessProbe:
    httpGet:
     path:/
     port:80
    initialDelaySeconds:5
    periodSeconds:5

這個 YAML 包含了 Deployment 的核心配置：副本數(shù)、標(biāo)簽選擇器、更新策略、容器配置、健康檢查。

1.3 ReplicaSet 的控制循環(huán)機制

ReplicaSet 是 Kubernetes 控制器的核心實現(xiàn)，其工作原理基于經(jīng)典的控制循環(huán)。

控制循環(huán)包含四個組件：觀測器（Observers）、解釋器（Interpreters）、分析器（Analyzers）、執(zhí)行器（Effectors）。

在 ReplicaSet 控制器中：

觀測器負(fù)責(zé)監(jiān)聽 Pod 資源的變化，包括 Pod 創(chuàng)建、刪除、狀態(tài)變更。

解釋器將觀測到的實際狀態(tài)與期望狀態(tài)進行對比。期望狀態(tài)來自 ReplicaSet 的 spec.replicas 字段，實際狀態(tài)是當(dāng)前運行的 Pod 數(shù)量。

分析器根據(jù)對比結(jié)果決定是否需要采取行動。如果實際 Pod 數(shù)小于期望數(shù)量，需要創(chuàng)建新 Pod；如果大于期望數(shù)量，需要刪除多余 Pod。

執(zhí)行器通過 API Server 創(chuàng)建或刪除 Pod 資源。

這個控制循環(huán)是 Kubernetes 自愈能力的基礎(chǔ)。當(dāng)某個節(jié)點上的 Pod 異常退出時，ReplicaSet 控制器會自動檢測到 Pod 數(shù)量減少，然后創(chuàng)建新的 Pod 來補充。

1.4 Pod 的調(diào)度流程詳解

Pod 的調(diào)度分為兩個階段：控制平面階段的調(diào)度決策，和節(jié)點階段的容器啟動。

1.4.1 控制平面調(diào)度

控制平面的調(diào)度器（kube-scheduler）負(fù)責(zé)為每個未調(diào)度的 Pod 選擇最佳節(jié)點。調(diào)度決策基于以下因素：

節(jié)點親和性（NodeAffinity）：根據(jù)節(jié)點的標(biāo)簽選擇符合條件的節(jié)點。

Pod 親和性與反親和性（PodAffinity、PodAntiAffinity）：控制 Pod 之間的部署關(guān)系，例如將同一個應(yīng)用的 Pod 分散到不同節(jié)點。

污點與容忍（Taints、Tolerations）：節(jié)點可以通過污點拒絕特定 Pod，Pod 通過容忍來接受帶有污點的節(jié)點。

資源請求與限制（Requests、Limits）：調(diào)度器會檢查節(jié)點的可用資源，確保 Pod 的資源請求能夠得到滿足。

優(yōu)先級與搶占（Priority、Preemption）：高優(yōu)先級的 Pod 可以搶占低優(yōu)先級 Pod 的資源。

查看調(diào)度器配置：

# 查看調(diào)度器配置
kubectl get configmap kube-scheduler-config -n kube-system -o yaml

# 查看 Pod 的調(diào)度結(jié)果
kubectl describe pod  | grep -A 10"Events:"

# 查看節(jié)點的可用資源
kubectl describe node  | grep -A 5"Allocated resources"

1.4.2 節(jié)點階段容器啟動

調(diào)度決策完成后，節(jié)點上的 kubelet 負(fù)責(zé)容器的實際啟動。kubelet 通過 CRI（Container Runtime Interface）與容器運行時交互。

容器啟動流程：

首先，kubelet 通過 CRI API 調(diào)用容器運行時，拉取容器鏡像。

然后，容器運行時創(chuàng)建容器的文件系統(tǒng)、網(wǎng)絡(luò)、存儲等命名空間。

接著，kubelet 配置容器的資源限制和環(huán)境變量。

最后，啟動容器內(nèi)的主進程，并持續(xù)監(jiān)控其狀態(tài)。

1.5 Service 的網(wǎng)絡(luò)抽象

Service 是 Kubernetes 網(wǎng)絡(luò)模型的核心抽象，它為一組 Pod 提供穩(wěn)定的 IP 地址和 DNS 名稱。

1.5.1 Service 的四種類型

ClusterIP：集群內(nèi)部訪問，僅在集群內(nèi)部可達(dá)，默認(rèn)類型。

NodePort：通過節(jié)點端口訪問，每個節(jié)點都會開放一個相同的端口，范圍 30000-32767。

LoadBalancer：通過云廠商的負(fù)載均衡器訪問，需要云廠商支持。

ExternalName：通過 CNAME 記錄將 Service 映射到外部域名。

apiVersion:v1
kind:Service
metadata:
name:nginx-service
namespace:default
spec:
type:ClusterIP
selector:
 app:nginx
ports:
-name:http
 protocol:TCP
 port:80
 targetPort:80

1.5.2 kube-proxy 與服務(wù)發(fā)現(xiàn)

Kubernetes 不直接實現(xiàn) Service 的網(wǎng)絡(luò)轉(zhuǎn)發(fā)，而是通過每個節(jié)點上的 kube-proxy 組件實現(xiàn)。

kube-proxy 有三種工作模式：

iptables 模式：kube-proxy 通過 iptables 規(guī)則實現(xiàn)負(fù)載均衡。適用于節(jié)點數(shù)量不多的場景。

IPVS 模式：kube-proxy 通過 IPVS（IP Virtual Server）實現(xiàn)負(fù)載均衡。適用于大規(guī)模集群，性能更好。

nftables 模式：新一代模式，逐步替代 iptables。

查看 kube-proxy 的工作模式：

# 查看 kube-proxy 模式
kubectl get configmap kube-proxy-config -n kube-system -o yaml | grep mode

# 在節(jié)點上查看 iptables 規(guī)則
sudo iptables -t nat -L KUBE-SERVICES -n -v | head -20

# 查看 IPVS 規(guī)則
sudo ipvsadm -L -n | grep KUBE

二、從 Deployment 到 Service 的完整數(shù)據(jù)流

2.1 工作流的完整路徑

從 Deployment 到 Service 的完整數(shù)據(jù)流包含以下步驟：

第一步，用戶通過 kubectl 或 API 創(chuàng)建 Deployment 資源。

第二步，Deployment 控制器創(chuàng)建 ReplicaSet 資源。

第三步，ReplicaSet 控制器根據(jù) spec 創(chuàng)建 Pod 資源。

第四步，調(diào)度器為每個未調(diào)度的 Pod 選擇節(jié)點。

第五步，節(jié)點上的 kubelet 創(chuàng)建和啟動容器。

第六步，用戶創(chuàng)建 Service 資源，通過 selector 關(guān)聯(lián)到 Pod。

第七步，kube-proxy 配置網(wǎng)絡(luò)規(guī)則，實現(xiàn)服務(wù)訪問。

2.2 實際工作流演示

2.2.1 創(chuàng)建 Deployment

# 創(chuàng)建 Deployment
kubectl apply -f deployment.yaml

# 查看 Deployment 狀態(tài)
kubectl get deployment nginx-deployment
kubectl describe deployment nginx-deployment

# 查看 ReplicaSet
kubectl get replicaset
kubectl get rs -l app=nginx

# 查看 Pod
kubectl get pod -l app=nginx
kubectl get pods -o wide -l app=nginx

Deployment 創(chuàng)建后，ReplicaSet 控制器會立即創(chuàng)建對應(yīng)的 ReplicaSet。然后 ReplicaSet 控制器會創(chuàng)建 Pod 對象。調(diào)度器為每個 Pod 選擇節(jié)點后，kubelet 在對應(yīng)節(jié)點上啟動容器。

2.2.2 創(chuàng)建 Service

# 創(chuàng)建 Service
kubectl apply -f service.yaml

# 查看 Service
kubectl get svc nginx-service
kubectl describe svc nginx-service

# 查看 Endpoint
kubectl get endpoints nginx-service
kubectl describe endpoints nginx-service

Service 創(chuàng)建后，kube-proxy 會自動配置相應(yīng)的網(wǎng)絡(luò)規(guī)則。Endpoint 控制器會根據(jù) selector 自動創(chuàng)建 Endpoint 對象，關(guān)聯(lián)到匹配的 Pod。

2.3 核心配置項詳解

2.3.1 Selector 的作用機制

Selector 是連接 Deployment、ReplicaSet、Pod、Service 的關(guān)鍵紐帶。

Deployment 的 selector 用于標(biāo)識它管理的 ReplicaSet。

ReplicaSet 的 selector 必須匹配其模板中的 Pod 標(biāo)簽。

Service 的 selector 用于發(fā)現(xiàn)和關(guān)聯(lián)后端 Pod。

這三個 selector 的關(guān)系必須一致，否則會導(dǎo)致工作流斷裂。

常見錯誤案例：

# Deployment 的 selector
selector:
matchLabels:
 app:nginx

# 但是 Pod 模板的標(biāo)簽是
template:
metadata:
 labels:
  app:nginx-web# 標(biāo)簽不一致，導(dǎo)致無法管理

# Service 的 selector
selector:
app:nginx-proxy# 與 Pod 標(biāo)簽不匹配，導(dǎo)致無法關(guān)聯(lián)

2.3.2 端口配置的關(guān)鍵點

Service 的端口配置有幾個關(guān)鍵參數(shù)：

port：Service 暴露的端口，其他 Pod 訪問 Service 時使用這個端口。

targetPort：后端 Pod 監(jiān)聽端口，流量轉(zhuǎn)發(fā)到這個端口。

nodePort：節(jié)點端口，外部訪問時使用。

protocol：協(xié)議類型，TCP 或 UDP。

ports:
-name:http
protocol:TCP
port:80   # Service 端口
targetPort:8080# 容器端口，如果省略則默認(rèn)等于 port
nodePort:30080# 節(jié)點端口，僅 NodePort 類型需要指定

三、滾動更新與回滾機制

3.1 滾動更新原理

滾動更新是 Deployment 的默認(rèn)更新策略，它通過逐步替換舊版 Pod 來實現(xiàn)零停機部署。

3.1.1 滾動更新參數(shù)

maxUnavailable：更新過程中允許不可用的最大 Pod 數(shù)量?？梢允墙^對值或百分比。

maxSurge：更新過程中允許超過期望副本數(shù)的最大 Pod 數(shù)量?？梢允墙^對值或百分比。

這兩個參數(shù)配合使用，實現(xiàn)更新過程中的服務(wù)連續(xù)性。

示例配置：

spec:
strategy:
 type:RollingUpdate
 rollingUpdate:
  maxUnavailable:25% # 最多25%的 Pod 不可用
  maxSurge:25%    # 最多25%的 Pod 超出期望數(shù)量

3.1.2 滾動更新過程

滾動更新的實際過程：

假設(shè) replicas=3，maxUnavailable=1，maxSurge=1。

初始狀態(tài)：3 個舊版 Pod 正常運行。

第一步：創(chuàng)建一個新版 Pod，總數(shù)變?yōu)?4。

第二步：等待新版 Pod Ready 后，刪除一個舊版 Pod，總數(shù)變?yōu)?3。

第三步：再創(chuàng)建一個新版 Pod，總數(shù)變?yōu)?4。

第四步：等待新版 Pod Ready 后，再刪除一個舊版 Pod。

重復(fù)以上步驟，直到所有 Pod 都更新為新版。

查看滾動更新狀態(tài)：

# 查看更新歷史
kubectl rollouthistorydeployment/nginx-deployment

# 查看特定版本的詳情
kubectl rollouthistorydeployment/nginx-deployment --revision=2

# 查看當(dāng)前滾動狀態(tài)
kubectl rollout status deployment/nginx-deployment

# 查看 Deployment 事件
kubectl describe deployment nginx-deployment | grep -A 10"Events:"

3.2 回滾操作

當(dāng)滾動更新出現(xiàn)問題時，可以快速回滾到之前的版本。

# 回滾到上一個版本
kubectl rollout undo deployment/nginx-deployment

# 回滾到指定版本
kubectl rollout undo deployment/nginx-deployment --to-revision=2

# 驗證回滾狀態(tài)
kubectl rollout status deployment/nginx-deployment
kubectl get pods -l app=nginx

回滾的本質(zhì)是創(chuàng)建一個新的 ReplicaSet，其配置與指定版本的 ReplicaSet 相同。

3.3 暫停與恢復(fù)更新

對于復(fù)雜的更新場景，可以暫停滾動更新，分步進行。

# 暫停更新
kubectl rollout pause deployment/nginx-deployment

# 執(zhí)行部分更新
kubectlsetimage deployment/nginx-deployment nginx=nginx:1.28-alpine

# 恢復(fù)更新
kubectl rollout resume deployment/nginx-deployment

四、網(wǎng)絡(luò)通信機制

4.1 容器間通信

同一節(jié)點上的容器通過 CNI（Container Network Interface）插件配置的網(wǎng)橋進行通信。

Kubernetes 使用 Pause 容器作為 Pod 的基礎(chǔ)設(shè)施容器，所有業(yè)務(wù)容器共享 Pause 容器的網(wǎng)絡(luò)命名空間。

查看節(jié)點網(wǎng)絡(luò)配置：

# 在節(jié)點上查看網(wǎng)橋
ip link showtypebridge

# 查看 cni0 網(wǎng)橋
ip addr show cni0

# 查看路由表
ip route

4.2 Pod 間通信

不同節(jié)點上的 Pod 通過 overlay 網(wǎng)絡(luò)進行通信。常用的 CNI 插件包括 Flannel、Calico、Cilium 等。

Flannel 使用 VXLAN 封裝數(shù)據(jù)包，通過 UDP 發(fā)送到目標(biāo)節(jié)點。

Calico 使用 BGP 協(xié)議直接路由數(shù)據(jù)包，性能更好。

Cilium 基于 eBPF 實現(xiàn)，提供更精細(xì)的網(wǎng)絡(luò)控制和觀測能力。

4.3 Service 訪問原理

當(dāng)一個 Pod 訪問 Service 時，流量經(jīng)過以下路徑：

第一步，Pod 通過 DNS 解析 Service 名稱得到 ClusterIP。

第二步，Pod 將請求發(fā)送到 ClusterIP。

第三步，kube-proxy 攔截請求，根據(jù) iptables 或 IPVS 規(guī)則將目標(biāo) IP 替換為后端 Pod 的真實 IP。

第四步，請求被路由到后端 Pod。

查看 DNS 解析：

# 進入測試 Pod
kubectl run -it --rm debug --image=busybox:1.36 -- sh

# 查詢 DNS
nslookup kubernetes.default
nslookup nginx-service.default.svc.cluster.local

# 測試 Service 訪問
wget -qO- http://nginx-service:80

五、常見故障與排障

5.1 Pod 無法啟動

5.1.1 鏡像拉取失敗

這是最常見的 Pod 啟動失敗原因。

排查步驟：

# 查看 Pod 狀態(tài)
kubectl get pod  -o wide

# 查看詳細(xì)事件
kubectl describe pod  | grep -A 20"Events:"

# 常見錯誤信息：
# ErrImagePull：鏡像拉取失敗
# ImagePullBackOff：多次拉取失敗后進入回退狀態(tài)
# InvalidImageName：鏡像名稱格式錯誤

解決方案：

# 檢查鏡像是否存在
docker pull 

# 使用私有鏡像倉庫
kubectl create secret docker-registry regcred 
 --docker-server= 
 --docker-username= 
 --docker-password= 
 --docker-email=

# 在 Pod 中引用 secret
spec:
 imagePullSecrets:
 - name: regcred

5.1.2 資源不足

節(jié)點資源不足會導(dǎo)致 Pod 無法調(diào)度或啟動。

排查方法：

# 查看節(jié)點狀態(tài)
kubectl describe node 

# 查看資源分配
kubectl describe node  | grep -A 5"Allocated resources"

# 查看 Pod 的資源請求
kubectl get pod  -o jsonpath='{.spec.containers[*].resources}'

5.1.3 調(diào)度失敗

# 查看 Pod 事件中的調(diào)度錯誤
kubectl describe pod  | grep -A 5"Events:"

# 常見錯誤：
# FailedScheduling：調(diào)度失敗
# 0/3 nodes are available: 1 node(s) had taint {node.kubernetes.io/not-ready:...}
# 0/3 nodes are available: 1 node(s) didn't match Pod's node affinity/selector

5.2 Service 無法訪問

5.2.1 Endpoint 為空

# 查看 Service 和 Endpoint
kubectl get svc nginx-service
kubectl get endpoints nginx-service

# 如果 Endpoint 為空，檢查 selector 是否匹配
kubectl get pods -l app=nginx
kubectl describe svc nginx-service | grep Selector

常見原因：Deployment 的 selector 與 Service 的 selector 不匹配。

5.2.2 kube-proxy 異常

# 檢查 kube-proxy 日志
kubectl logs -n kube-system -l k8s-app=kube-proxy

# 檢查 kube-proxy 配置
kubectl get configmap kube-proxy-config -n kube-system -o yaml

# 重啟 kube-proxy（謹(jǐn)慎操作）
kubectl rollout restart daemonset kube-proxy -n kube-system

5.2.3 DNS 解析問題

# 檢查 CoreDNS 是否正常運行
kubectl get pod -n kube-system -l k8s-app=kube-dns

# 測試 DNS 解析
kubectlexec-it  -- nslookup nginx-service

# 檢查 /etc/resolv.conf 配置
kubectlexec-it  -- cat /etc/resolv.conf

5.3 網(wǎng)絡(luò)連接問題

5.3.1 跨節(jié)點通信故障

# 在源節(jié)點上測試
ping 

# 追蹤路由
traceroute 

# 檢查 CNI 插件狀態(tài)
ip link show | grep cni
cat /etc/cni/net.d/10-flannel.conflist

5.3.2 網(wǎng)絡(luò)策略問題

# 檢查是否配置了 NetworkPolicy
kubectlgetnetworkpolicy-oyaml

# 示例：允許特定命名空間的流量
apiVersion:networking.k8s.io/v1
kind:NetworkPolicy
metadata:
name:allow-frontend
spec:
podSelector:
 matchLabels:
  app:backend
policyTypes:
-Ingress
ingress:
-from:
 -namespaceSelector:
   matchLabels:
    name:frontend
 ports:
 -protocol:TCP
  port:80

5.4 滾動更新異常

5.4.1 更新卡住

# 查看 Deployment 狀態(tài)
kubectl get deployment nginx-deployment

# 查看 ReplicaSet 狀態(tài)
kubectl get rs -l app=nginx

# 檢查不可用的 Pod
kubectl get pod -l app=nginx | grep -v Running

# 強制回滾
kubectl rollout undo deployment/nginx-deployment

5.4.2 Pod 無法 Ready

# 檢查探針配置
kubectl describe pod  | grep -A 10"Conditions:"

# 測試健康檢查端點
kubectlexec-it  -- curl -k http://localhost:80/healthz

# 檢查探針日志
kubectl describe pod  | grep -A 5"Liveness"| grep -A 5"Reason:"

六、最佳實踐

6.1 資源配額與限制

為每個容器設(shè)置合理的資源請求和限制：

spec:
containers:
-name:nginx
 resources:
  requests:
   memory:"128Mi"
   cpu:"100m"
  limits:
   memory:"256Mi"
   cpu:"500m"

建議的做法：

requests 設(shè)置為實際平均使用量，確保調(diào)度器能夠做出正確決策。

limits 設(shè)置為峰值上限，防止單個容器耗盡節(jié)點資源。

內(nèi)存 limits 應(yīng)該與 requests 相近，避免內(nèi)存碎片化。

6.2 健康檢查配置

合理配置探針，避免過早或過晚檢測到故障：

spec:
containers:
-name:nginx
 livenessProbe:
  httpGet:
   path:/healthz
   port:80
  initialDelaySeconds:15 # 等待容器啟動完成
  periodSeconds:10    # 每10秒檢查一次
  failureThreshold:3   # 連續(xù)3次失敗才重啟
 readinessProbe:
  httpGet:
   path:/ready
   port:80
  initialDelaySeconds:5
  periodSeconds:5
  failureThreshold:1   # 一次失敗即移除

initialDelaySeconds 需要根據(jù)應(yīng)用啟動時間調(diào)整。過短會導(dǎo)致啟動過程中被殺死，過長會導(dǎo)致故障發(fā)現(xiàn)延遲。

6.3 標(biāo)簽管理策略

建立統(tǒng)一的標(biāo)簽管理規(guī)范：

metadata:
labels:
 app.kubernetes.io/name:nginx    # 應(yīng)用名稱
 app.kubernetes.io/instance:nginx-prod# 實例名稱
 app.kubernetes.io/version:"1.27"   # 版本號
 app.kubernetes.io/component:webserver# 組件類型
 app.kubernetes.io/part-of:frontend  # 所屬應(yīng)用
 app.kubernetes.io/managed-by:kubectl # 管理工具

使用標(biāo)簽進行環(huán)境隔離、版本管理、團隊劃分。

6.4 部署策略選擇

根據(jù)業(yè)務(wù)需求選擇合適的部署策略：

金絲雀發(fā)布：逐步將流量切換到新版本，降低發(fā)布風(fēng)險。

spec:
strategy:
 type:RollingUpdate
 rollingUpdate:
  maxUnavailable:0
  maxSurge:10%

藍(lán)綠部署：通過兩個完全相同的環(huán)境實現(xiàn)瞬時切換。

滾動更新：適用于無狀態(tài)服務(wù)，默認(rèn)策略。

6.5 日志與監(jiān)控

配置集群級日志收集：

# 使用 Fluentd 收集日志
apiVersion:apps/v1
kind:DaemonSet
metadata:
name:fluentd-logging
namespace:kube-system
spec:
selector:
 matchLabels:
  k8s-app:fluentd-logging
template:
 spec:
  containers:
  -name:fluentd
   image:fluentd:v1.16
   volumeMounts:
   -name:varlog
    mountPath:/var/log
   -name:containers
    mountPath:/var/lib/docker/containers
  volumes:
  -name:varlog
   hostPath:
    path:/var/log
  -name:containers
   hostPath:
    path:/var/lib/docker/containers

七、性能與擴展

7.1 調(diào)度器性能調(diào)優(yōu)

大規(guī)模集群中，調(diào)度器可能成為瓶頸：

# kube-scheduler 配置
apiVersion:kubescheduler.config.k8s.io/v1beta3
kind:KubeSchedulerConfiguration
profiles:
-schedulerName:default-scheduler
percentageOfNodesToScore:50# 減少掃描節(jié)點數(shù)量
podInitialBackoffSeconds:10
podMaxBackoffSeconds:20

7.2 kube-proxy 性能優(yōu)化

IPVS 模式相比 iptables 有更好的性能：

# 查看當(dāng)前模式
kubectl get configmap kube-proxy-config -n kube-system -o yaml | grep mode

# 切換到 IPVS 模式
kubectl edit configmap kube-proxy-config -n kube-system

7.3 水平自動擴縮容

使用 HPA 實現(xiàn)自動擴縮容：

apiVersion:autoscaling/v2
kind:HorizontalPodAutoscaler
metadata:
name:nginx-hpa
spec:
scaleTargetRef:
 apiVersion:apps/v1
 kind:Deployment
 name:nginx-deployment
minReplicas:3
maxReplicas:10
metrics:
-type:Resource
 resource:
  name:cpu
  target:
   type:Utilization
   averageUtilization:70
-type:Resource
 resource:
  name:memory
  target:
   type:Utilization
   averageUtilization:80

八、安全配置

8.1 RBAC 權(quán)限控制

最小權(quán)限原則：

apiVersion:rbac.authorization.k8s.io/v1
kind:Role
metadata:
name:pod-reader
namespace:default
rules:
-apiGroups:[""]
resources:["pods"]
verbs:["get","list","watch"]

---
apiVersion:rbac.authorization.k8s.io/v1
kind:RoleBinding
metadata:
name:pod-reader-binding
subjects:
-kind:ServiceAccount
name:default
namespace:default
roleRef:
kind:Role
name:pod-reader
apiGroup:rbac.authorization.k8s.io

8.2 Pod 安全策略

使用 Pod Security Standards：

apiVersion:v1
kind:Namespace
metadata:
name:production
labels:
 pod-security.kubernetes.io/enforce:restricted
 pod-security.kubernetes.io/audit:restricted
 pod-security.kubernetes.io/warn:restricted

總結(jié)

從 Deployment 到 Service 的工作流是 Kubernetes 最核心的運維主線。理解 Deployment 的聲明式更新機制、ReplicaSet 的控制循環(huán)、Pod 的調(diào)度與啟動過程、Service 的網(wǎng)絡(luò)抽象，是解決日常問題的理論基礎(chǔ)。

實際排障中，應(yīng)該按照數(shù)據(jù)流順序逐層排查：先看資源狀態(tài)是否達(dá)到期望，再看調(diào)度是否成功，然后看容器是否正常啟動，最后看網(wǎng)絡(luò)是否連通。每個環(huán)節(jié)都有對應(yīng)的 kubectl 命令和節(jié)點工具可以使用。

配置層面，資源限制要合理、健康檢查要準(zhǔn)確、標(biāo)簽管理要規(guī)范，這些最佳實踐能夠顯著減少生產(chǎn)環(huán)境中的故障發(fā)生概率。