2025年K8s最新高頻面試題，看看你能答對幾個？
Kubernetes的核心組件有哪些，各自作用是什么？
- Master節點組件：
a.kube-apiserver：集群的控制入口，提供REST API接口。
b.kube-scheduler：負責Pod調度，決定Pod運行在哪個節點上。
c.kube-controller-manager：運行各種控制器，確保集群狀態與期望狀態一致。
d.etcd：分布式鍵值存儲，保存集群所有配置信息。
- Node節點組件：
- kubelet：負責節點上的Pod生命周期管理。
- kube-proxy：負責實現服務(Service)負載均衡和網絡代理。
- 容器運行時（如Docker、containerd）：運行容器鏡像的環境。
Pod和Deployment的區別？
- Pod：是Kubernetes最小的資源單位，一組容器的集合，生命周期短暫，可能隨時被重建。
- Deployment：控制Pod副本的部署和管理，提供滾動升級、回滾等功能，確保應用的高可用性。
Service有哪些類型，分別適用于什么場景？
- ClusterIP（默認）：在集群內訪問服務，不對外暴露。
- NodePort：通過節點IP和靜態端口對外暴露服務（適合測試或臨時訪問）。
- LoadBalancer：結合云服務提供商的負載均衡器，直接對外提供服務。
- ExternalName：通過DNS別名映射到外部服務。
ConfigMap和Secret有什么區別？
- ConfigMap：存儲明文非敏感配置，如環境變量、配置文件等。
- Secret：存儲加密的敏感信息，如密碼、Token和證書。
StatefulSet 和 Deployment 的主要區別是什么？
- StatefulSet：用于有狀態的服務，Pod具有穩定的標識（網絡、存儲），Pod啟動和銷毀嚴格按照順序進行（如數據庫）。
- Deployment：用于無狀態應用，Pod可任意擴展、縮減，無嚴格順序要求。
什么是 Ingress，有哪些常用實現方式?
- Ingress：提供集群外部到服務的HTTP/HTTPS訪問的規則集合。
- 常用實現方式：
a.NGINX Ingress Controller
b.Traefik
c.HAProxy
如何限制 Kubernetes 中 Pod 資源使用？
- 通過在Pod中定義
resources字段的requests（申請）和limits（限制），如CPU、內存等，防止資源爭用或失控。
yaml
復制編輯
resources:
requests:
cpu: "500m"
memory: "256Mi"
limits:
cpu: "1"
memory: "512Mi"Pod如何實現親和性與反親和性？
親和性與反親和性通過節點親和性（NodeAffinity）和Pod親和性（PodAffinity/PodAntiAffinity）實現。
- 親和性（Affinity）：允許Pod根據節點或其他Pod的特征調度在特定節點。
- 反親和性（Anti-affinity）：防止Pod被調度到具有特定特征的節點或與其他Pod位于同一節點。
使用nodeAffinity指定Pod傾向于部署到特定節點，而PodAntiAffinity則避免多個相似Pod集中在同一節點上，增強容災能力。
Kubernetes如何實現健康檢查？
通過兩種探針：
- Liveness Probe：檢測容器是否存活，如失敗則重啟。
- Readiness Probe：檢測容器是否準備好接收流量，如失敗則不轉發請求。
DaemonSet的典型應用場景是什么？
答案：
- 日志收集代理（如Fluentd）
- 節點監控Agent（如Node Exporter）
- 網絡組件（如CNI插件）
DaemonSet確保每個節點運行一個Pod，通常用于基礎設施服務。
Kubernetes的存儲卷（Volume）有哪些常見類型？
答案：
- emptyDir：生命周期跟隨Pod，僅適合臨時存儲。
- hostPath：掛載節點文件系統，可能有安全風險。
- PersistentVolumeClaim (PVC)：與PersistentVolume關聯的持久化存儲卷。
- configMap與secret：掛載配置或敏感數據。
Kubernetes Pod驅逐（Eviction）原因有哪些？
答案：
- 節點資源不足（CPU/內存壓力）
- 節點維護（kubectl drain操作）
- Pod違反QoS策略（超出內存limits）
- 節點NotReady、宕機等異常狀態
如何實現節點隔離（Pod不調度到某節點）？
答案：
- 使用
kubectl cordon標記節點為不可調度。 - 使用
taint與toleration實現節點級別Pod調度控制。
bash
復制編輯
kubectl taint nodes node01 key=value:NoScheduleKubernetes的調度算法主要考慮哪些因素？
答案：
- 節點資源充足性（CPU/內存）
- 節點親和性與反親和性
- 污點（taint）和容忍度（toleration）
- 自定義調度策略（調度擴展器）
什么是Sidecar模式，舉一個典型例子？
答案：
Sidecar是指在Pod中使用輔助容器，增強主容器功能。典型例子：Istio中Envoy代理作為Sidecar，實現流量管理、安全策略、監控等功能。
Kubernetes如何保證Secret的安全性？
答案：
- Secret以Base64編碼存儲在etcd中。
- 生產環境中應啟用etcd加密。
- RBAC限制訪問Secret的權限。
- 使用第三方密鑰管理系統（如Vault）更安全。
Kubernetes中QoS的三種類型有哪些？
答案：
- Guaranteed：設置相同的requests和limits，保證資源。
- Burstable：requests < limits，可能資源被限制或驅逐。
- BestEffort：沒有設置requests和limits，資源最低保證。
Kubernetes如何實現擴容縮容（彈性伸縮）？
答案：
- Pod級：Horizontal Pod Autoscaler (HPA)，根據CPU、內存等指標自動擴縮容。
- 節點級：Cluster Autoscaler，根據資源不足自動增加或減少節點。
為什么要設置PodDisruptionBudget？
答案：
PodDisruptionBudget定義允許同時不可用Pod的數量，用于保護應用高可用，避免維護或升級時服務中斷。
kube-proxy有哪些實現模式，各自優缺點？
答案：
- userspace模式（已棄用）：性能低，轉發開銷大。
- iptables模式（常用）：性能中等，規則復雜，容易擴展。
- ipvs模式（推薦）：性能高，負載均衡功能更強。
Kubernetes資源配額（ResourceQuota）如何工作？
答案：
通過ResourceQuota限制namespace內可申請資源的總量（CPU、內存、Pod數量），確保多租戶環境的公平資源分配。
什么是Admission Controller，常用的有哪些？
答案：
Admission Controller在API Server接收請求時對資源進行準入檢查，決定是否允許操作。
常用的有：
- NamespaceLifecycle
- LimitRanger
- ResourceQuota
- PodSecurityPolicy（已棄用，推薦OPA或Kyverno）
- ValidatingAdmissionWebhook與MutatingAdmissionWebhook
什么是Vertical Pod Autoscaler (VPA)，如何工作？
答案：
VPA根據Pod歷史資源使用情況自動調整Pod資源請求（CPU/內存）。當Pod重建時，以更合適的資源配置重啟。
如何排查Pod無法啟動的問題？
答案：
- 查看Pod事件：
bash
復制編輯
kubectl describe pod <pod-name>- 檢查容器日志：
bash
復制編輯
kubectl logs <pod-name> -c <container-name>- 節點資源檢查：
bash
復制編輯
kubectl top nodes- 節點狀態檢查：
bash
復制編輯
kubectl get nodesKubernetes網絡策略（NetworkPolicy）如何實現Pod間通信控制？
答案：
NetworkPolicy通過label選擇Pod，基于Ingress/Egress規則定義允許或拒絕Pod間網絡訪問，配合網絡插件（如Calico）實現網絡隔離策略。
示例：
yaml
復制編輯
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress以上規則將禁止namespace內所有Pod的進出流量。
如何查看 Kubernetes 集群中的資源使用情況？
答案：
可使用 kubectl top 命令：
bash
復制編輯
kubectl top nodes # 節點資源
kubectl top pods # Pod資源需提前安裝 Metrics Server 組件。
Kubernetes PVC 與 PV 的關系是什么？
答案：
- PV（PersistentVolume）：管理員提供的持久化存儲資源。
- PVC（PersistentVolumeClaim）：用戶對存儲資源的申請，PVC綁定到合適的PV上供Pod使用。
為什么不建議在生產環境中使用 latest 鏡像標簽？
答案：
- latest標簽不明確，難以跟蹤版本。
- latest鏡像變化頻繁，可能出現不可控的行為。
- 影響滾動升級和回滾機制。
Horizontal Pod Autoscaler (HPA) 基于什么指標擴縮容？
答案：
默認基于CPU或內存，也可自定義指標（Custom Metrics）或外部指標（External Metrics）進行擴縮容，如隊列長度或HTTP請求數。
什么是 CSI（容器存儲接口），有什么作用？
答案：
CSI（Container Storage Interface）是一種標準接口，用于將各種存儲系統連接到Kubernetes。通過CSI插件，用戶可以使用任意外部存儲系統，如Ceph、NFS、AWS EBS、阿里云盤等。
Kubernetes中，Pod資源限制超出時會發生什么？
答案：
- 超過內存（limits）：Pod會被OOMKilled，容器自動重啟。
- 超過CPU（limits）：Pod被CPU限流（CPU被throttle），性能受限，但不會被驅逐或殺掉。
Pod的狀態（Pod Phase）有哪些？
答案：
- Pod的狀態（Pod Phase）通常包括以下幾種：
Pending（等待中）
a.Pod已被創建，但尚未調度到節點上，或正在拉取鏡像。
Running（運行中）
- Pod已經成功調度到節點上，且所有容器都已創建并至少有一個容器處于運行狀態。
Succeeded（成功）
- Pod中的所有容器都已成功執行并退出（容器狀態為0），常見于一次性任務型Pod。
Failed（失敗）
- Pod中的至少一個容器異常退出（非0退出碼），或者啟動過程中發生了嚴重錯誤。
Unknown（未知）
- Pod狀態無法被Kubernetes節點準確報告，可能節點故障、網絡中斷或其他通訊異常所致。
Kubernetes中，imagePullPolicy有哪些可選值，意義是什么？
答案：
- 在 Kubernetes 中，
imagePullPolicy有以下三個可選值：
Always
a.latest 標簽鏡像（默認策略）。
b.鏡像頻繁更新，確保總能拉到最新版本。
- 含義：每次啟動容器時，總是嘗試重新拉取鏡像，即使本地已存在該鏡像。
- 適用場景：
IfNotPresent
- 使用固定版本號（例如：
myapp:v1.0.1）的鏡像。 - 降低鏡像拉取頻率，加速 Pod 啟動。
- 含義：只有當本地不存在指定鏡像時才會去遠程倉庫拉取鏡像。
- 適用場景：
Never
- 離線環境或鏡像提前加載到節點本地的情況。
- 確保嚴格控制鏡像來源，不允許從遠程倉庫獲取。
- 含義：永遠不會主動去拉取鏡像，必須使用本地已存在的鏡像。
- 適用場景：
默認規則：
- 當鏡像標簽為
latest時，默認值為：Always。 - 當鏡像標簽不是
latest時，默認值為：IfNotPresent。
為什么生產環境中建議給Pod定義readinessProbe和livenessProbe？
答案：
- readinessProbe：避免流量被轉發到未就緒Pod。
- livenessProbe：自動重啟異常Pod，提高服務可用性。
Kubernetes Pod 重啟策略有哪些？
答案：
- Always（默認）：容器異常退出后自動重啟。
- OnFailure：容器異常退出時才重啟，成功完成則不重啟。
- Never：無論成功失敗，容器退出后都不重啟。
Kubernetes容器探針（Probe）的三種探測方式是什么？
答案：
- Exec：執行命令，成功返回0則探測成功。
- HTTPGet：通過HTTP請求健康檢查。
- TCPSocket：通過TCP端口檢查容器是否正常運行。
Kubernetes PersistentVolume的生命周期如何管理？
答案：
Provisioning（創建）
- 靜態創建（Static Provisioning）
- 管理員預先創建 PV，定義存儲容量、訪問模式和存儲介質。
- 動態創建（Dynamic Provisioning）
- 用戶提交 PVC (PersistentVolumeClaim) 時，動態創建 PV。
- 需要使用 StorageClass 來定義存儲配置和創建規則。
Binding（綁定）
- 當用戶創建 PersistentVolumeClaim (PVC) 時，Kubernetes 會根據 PVC 指定的要求（容量、訪問模式、存儲類別）尋找合適的 PV 并綁定。
- PV 與 PVC 一旦綁定，進入 Bound 狀態，兩者形成一對一綁定關系。
Using（使用）
- PV 綁定到 PVC 后，Pod 可通過 PVC 掛載并使用存儲。
- PV 在 Bound 狀態期間持續提供存儲服務。
Releasing（釋放）
- 用戶刪除 PVC 后，對應的 PV 狀態會變成 Released。
- 此時數據依舊存在，但無法再被其他 PVC 使用，等待管理員處理。
Reclaiming（回收策略）
PV 的回收策略（Reclaim Policy）決定 PV 被釋放后的行為。可選的策略包括：
策略 | 說明 | 場景舉例 |
Retain | 保留 PV 和其上的數據，管理員手動清理 | 數據保護場景 |
Recycle（已廢棄） | 刪除數據，清空 PV，回收再利用（K8s 1.23起已移除） | 已廢棄，不再使用 |
Delete | 刪除 PV 和后端存儲的數據 | 臨時數據或非關鍵場景 |
- 推薦策略：
a.對于關鍵數據或生產環境：使用 Retain，數據由管理員人工處理。
b.對于臨時數據：使用 Delete，PV 和數據會自動清理。
解釋一下Kubernetes中的ResourceQuota和LimitRange的區別？
ResourceQuota限制的是Namespace整體資源申請總量，LimitRange則限制單個Pod容器可申請的資源范圍（如CPU、內存），以保證多租戶環境下的資源公平分配。
描述Kubernetes的RBAC授權原理？
RBAC通過Role定義資源操作權限，通過RoleBinding將權限綁定給用戶或ServiceAccount。ClusterRole與ClusterRoleBinding用于跨Namespace的權限定義。
Ingress Controller如何實現請求路由與流量管理？
Ingress Controller接收Ingress資源定義的HTTP(S)規則，根據Host、路徑（path）等將外部請求路由到不同的Service上。常用的Ingress Controller有NGINX、Traefik、HAProxy、Envoy等。
Service Mesh與Ingress有什么區別？
Ingress僅實現外部到集群服務的HTTP(s)流量入口路由，Service Mesh則覆蓋服務間通信，包括流量管理、服務發現、負載均衡、熔斷、監控、認證等更全面的能力。
什么是容器探針，分別解釋Liveness、Readiness、Startup探針？
- Liveness探針：確定容器是否存活，失敗時重啟容器。
- Readiness探針：容器是否準備好接受流量，未就緒時不會接收請求。
- Startup探針：用于慢啟動應用，確保啟動完成前不觸發其他探針，以防止誤判重啟。
