引言

在我面試的這一段時間里，一些面試官會問到像 k8s 中的各個探針都在什么場景下使用，或者 QoS 中的各個策略都在什么場景下使用，等等……

所以我這邊就稍微總結下我最近在面試過程中的一些致命要點。

開始

存活探針（Liveness Probe）、就緒探針（Readiness Probe）、啟動探針（Startup Probe）的區別及適用場景？

1. 存活探針（Liveness Probe）

? 目的：檢測容器是否處于運行狀態，若失敗則重啟容器。

? 適用場景：

a.應用程序因死鎖或死循環無法響應請求時自動恢復。

b.例如：Web 服務長時間無響應需強制重啟。

? 配置示例

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

2. 就緒探針（Readiness Probe）

? 目的：檢測容器是否準備好接收流量，若失敗則從 Service 的 Endpoints 中移除。

? 適用場景：

a.應用啟動時需要加載大量數據（如緩存預熱）。

b.依賴外部服務（如數據庫）初始化完成后才可提供服務。

? 配置示例

readinessProbe:
  exec:
    command: ["/bin/check-db-connection.sh"]
  initialDelaySeconds: 10
  periodSeconds: 5

3. 啟動探針（Startup Probe）

? 目的：延遲其他探針的啟動，直到容器成功啟動。

? 適用場景：

a.舊應用啟動時間較長（如 Java 應用需數分鐘初始化）。

b.避免存活/就緒探針在啟動階段誤判導致容器重啟。

? 配置示例

startupProbe:
  httpGet:
    path: /startup
    port: 8080
  failureThreshold: 30  # 最長等待 30*5=150 秒
  periodSeconds: 5

2: Kubernetes 的 QoS 分類（Guaranteed、Burstable、BestEffort）及其資源管理策略？

1. Guaranteed

? 條件：所有容器的 CPU/Memory 均設置 limits=requests。

? 資源保障：

a.嚴格保證資源分配，適用于核心服務（如數據庫）。

b.OOM 優先級最低，不易被殺死。

2. Burstable

? 條件：至少一個容器設置了 requests 但未滿足 limits=requests。

? 資源彈性：

a.允許突發使用資源，適用于多數應用（如 Web 服務）。

b.OOM 優先級高于 Guaranteed。

3. BestEffort

? 條件：所有容器均未設置 requests 和 limits。

? 資源競爭：

a.資源不足時優先被終止，適用于非關鍵任務（如批處理作業）。

b.OOM 優先級最高。

3: 如何為 Pod 配置 QoS 策略？舉例說明不同場景的選擇。

? 配置方法：通過 resources.requests 和 resources.limits 定義資源需求。

場景示例：

1. Guaranteed

containers:
- name: redis
  resources:
    requests:
      cpu: "1"
      memory: "2Gi"
    limits:
      cpu: "1"
      memory: "2Gi"

適用場景：MySQL、Redis 等需要穩定資源的服務。

2. Burstable

containers:
- name: web
  resources:
    requests:
      cpu: "0.5"
      memory: "1Gi"
    limits:
      cpu: "2"
      memory: "4Gi"

適用場景：Web 應用需應對流量高峰。

3. BestEffort

containers:
- name: batch-job
  resources: {}

適用場景：日志清理、臨時數據分析任務。

四、 如果一個 Pod 頻繁重啟，如何通過探針和 QoS 策略排查問題？

1. 檢查探針配置

? 確認存活探針是否過于敏感（如檢測間隔 periodSeconds 過短）。

? 查看日志確認探針失敗原因（如 /healthz 接口超時）。

2. 分析資源限制

? 檢查 Pod 的 QoS 類別是否為 BestEffort，導致資源不足被 OOMKill。

? 調整 requests/limits 為 Burstable 或 Guaranteed。

3. 查看事件日志

kubectl describe pod <pod-name>

確認是否因資源不足（OutOfMemory）或探針失敗（Liveness probe failed）觸發重啟。

五、如何通過 QoS 和探針優化高密度集群的資源利用率？

策略：

1. 優先級調度：核心服務設為 Guaranteed，搶占資源能力低但穩定性高。

2. 動態調整：使用 Vertical Pod Autoscaler（VPA）自動優化 requests/limits。

3. 探針精細化：

? 啟動探針避免過早檢測導致重啟。

? 就緒探針確保依賴服務就緒后再接收流量。

6. 在 Kubernetes 中，如何配置資源請求和限制？

資源請求和限制可以在 Pod 的定義文件中通過 resources 字段進行配置。它包括兩部分：

? 請求（request）：容器啟動時所需的最低資源。Kubernetes 使用請求來決定 Pod 調度到哪個節點。

? 限制（limit）：容器能夠使用的最大資源。當容器超過這個限制時，Kubernetes 會限制其資源使用，避免影響其他容器的運行。

例如：

apiVersion: v1
kind:Pod
metadata:
name:mypod
spec:
containers:
-name:mycontainer
    image:myimage
    resources:
      requests:
        memory:"64Mi"
        cpu:"250m"
      limits:
        memory:"128Mi"
        cpu: "500m"

七、Kubernetes 中的 Horizontal Pod Autoscaler（HPA）是如何工作的？

Horizontal Pod Autoscaler（HPA）根據 Pod 的 CPU 使用率或其他自定義指標，自動調整 Pod 的副本數。HPA 通過持續監控指標，并根據設定的閾值（如 CPU 或內存）來自動擴展或縮減 Pod 數量。配置 HPA 時，需要指定最小副本數、最大副本數和目標指標。

例如，下面是一個基于 CPU 使用率的 HPA 配置示例：

apiVersion: autoscaling/v2
kind:HorizontalPodAutoscaler
metadata:
name:myapp-hpa
spec:
scaleTargetRef:
    apiVersion:apps/v1
    kind:Deployment
    name:myapp
minReplicas:1
maxReplicas:10
metrics:
type:Resource
resource:
name:cpu
target:
    type:Utilization
    averageUtilization: 50

8. Kubernetes 中如何進行 Pod 彈性伸縮？

Pod 彈性伸縮可以通過以下幾種方式實現：

? Horizontal Pod Autoscaler（HPA）：根據 CPU、內存或自定義指標來動態增加或減少 Pod 的副本數。

? Vertical Pod Autoscaler（VPA）：根據 Pod 使用的資源自動調整其 CPU 和內存的請求和限制。

? Cluster Autoscaler：自動調整集群的規模，根據節點的資源需求自動增加或減少節點的數量。

9. Kubernetes 中的資源限制和請求設置為什么重要？

設置資源請求和限制對于確保集群資源合理分配非常重要：

? 資源請求：確保每個容器在節點上獲得足夠的資源，可以保證應用的正常運行。

? 資源限制：防止容器使用過多資源，影響其他容器的正常運行。特別是在高負載場景中，合理設置資源限制可以避免資源競爭，保證整個系統的穩定性。

十、如何使用 Kubernetes 進行資源隔離？

Kubernetes 提供了多種方式來實現資源隔離：

? Namespace：用于將集群中的資源劃分為不同的虛擬集群，不同的團隊或應用可以在不同的命名空間中工作，互不干擾。

? Resource Requests and Limits：通過資源請求和限制來確保每個容器有足夠的資源，并防止資源爭奪。

? Node Affinity and Taints/Tolerations：通過節點親和性、污點和容忍度來限制某些 Pod 只能在特定節點上運行，從而實現更細粒度的資源隔離。

十一、Kubernetes 中如何實現 Pod 的高可用性？

Kubernetes 提供了多種方式來確保 Pod 的高可用性：

? 副本集（ReplicaSet）：通過 ReplicaSet 來確保某個 Pod 的副本數始終保持在指定數量。ReplicaSet 可以自動創建和刪除 Pod，以確保所需數量的 Pod 始終運行。

? 部署（Deployment）：Deployment 是一種管理 Pod 副本集的控制器，支持滾動更新和回滾，確保服務可用。

? Pod Disruption Budgets（PDB）：通過 Pod Disruption Budgets 來限制可以同時被中斷的 Pod 數量，確保在升級或維護時，至少有一定數量的 Pod 在運行。

• ? 多節點調度：通過分布式調度和 Affinity 策略，將 Pod 調度到多個物理節點上，避免單點故障。

十二、Kubernetes 如何處理網絡通信？

Kubernetes 使用 CNI（容器網絡接口） 來處理網絡通信。以下是 Kubernetes 網絡的關鍵概念：

? Pod 網絡：每個 Pod 在集群中都有自己的 IP 地址，所有 Pod 都可以直接相互通信，無需 NAT。Kubernetes 通過 CNI 插件（如 Calico、Flannel、Weave）實現 Pod 網絡。

? 服務（Service）：Kubernetes 中的服務提供了對外暴露應用的方式，使用服務的 ClusterIP、NodePort 或 LoadBalancer 類型，可以使 Pod 對外可訪問。

? DNS：Kubernetes 集群內自動為每個服務分配一個 DNS 名稱，使得 Pod 通過 DNS 進行服務發現和通信。

十三、Kubernetes 中如何進行資源的限額管理（Resource Quota）？

資源配額（ResourceQuota）用于限制一個命名空間中可以使用的資源量，避免單個團隊或應用消耗過多資源，影響集群的穩定性。通過定義資源配額來管理 CPU、內存、Pod 數量等。

例如：

apiVersion: v1
kind:ResourceQuota
metadata:
name:example-quota
spec:
hard:
    cpu:"10"
    memory:50Gi
    pods: "10"

十四、Kubernetes 中的 Taints 和 Tolerations 如何工作？

Taints 和 Tolerations 是 Kubernetes 用來控制 Pod 調度的機制：

• ? Taints：是節點上設置的標記，表示某些 Pod 不應該調度到該節點，除非它們能夠容忍這個 taint。Taints 定義了節點的“污點”。
• ? Tolerations：是 Pod 上設置的標記，表示該 Pod 可以容忍某些節點上的 Taints。只有當 Pod 能夠容忍節點上的 Taints 時，才能調度到該節點。

通過 Taints 和 Tolerations，可以實現對特定節點的調度控制，如避免將某些 Pod 調度到資源緊張或不合適的節點上。

十五、Kubernetes 中如何實現服務發現（Service Discovery）？

Kubernetes 內建的服務發現機制使得集群內的 Pod 和服務能夠輕松相互發現和通信。Kubernetes 使用 DNS 來實現服務發現，每個服務都會自動分配一個 DNS 名稱，其他 Pod 可以通過該名稱訪問該服務。例如，如果創建了一個名為 myapp 的服務，它會自動在 DNS 中分配一個 myapp.default.svc.cluster.local 的地址，集群內的其他 Pod 可以通過這個地址訪問該服務。

十六、 Kubernetes 的 Pod 生命周期是如何管理的？

Kubernetes Pod 的生命周期包括以下幾個階段：

? Pending：Pod 已被調度到節點，但容器還沒有啟動。

? Running：Pod 的容器已經啟動并正在運行。

? Succeeded：Pod 中的所有容器都成功終止并完成任務。

? Failed：Pod 中的容器已終止且失敗，無法重新啟動。

• ? Unknown：Kubernetes 無法確定 Pod 的狀態，通常是由于與節點的通信失敗。

Kubernetes 通過控制器（如 Deployment、StatefulSet 等）來管理 Pod 的生命周期，確保在 Pod 失敗或被刪除時，可以自動恢復或創建新的 Pod。

十七、Kubernetes 中如何實現網絡策略（NetworkPolicy）？

NetworkPolicy 用于控制 Pod 之間的通信，通過定義規則來限制或允許流量。前提是你的 CNI 支持 NetworkPolicy，比如 Calico 就支持。

它可以基于 Pod 標簽、命名空間、IP 地址等進行訪問控制。它支持 Ingress（流入）和 Egress（流出）規則。 例如，允許只有標簽為 role=frontend 的 Pod 可以訪問標簽為 role=backend 的 Pod：

apiVersion: networking.k8s.io/v1
kind:NetworkPolicy
metadata:
name:allow-frontend-to-backend
spec:
podSelector:
    matchLabels:
      role:backend
ingress:
-from:
    -podSelector:
        matchLabels:
          role: frontend

十八、Kubernetes 中如何處理節點故障？

Kubernetes 使用節點監控和調度策略來處理節點故障：

? 節點監控：Kubernetes 的 kubelet 組件定期向 master 節點報告節點狀態，如果某個節點長時間無法與 master 節點通信，Kubernetes 會標記該節點為不可用（NotReady）。

? Pod 重新調度：當節點發生故障，調度器會重新將 Pod 調度到其他健康節點上。為了保證 Pod 高可用，可以配置 PodDisruptionBudget 和 ReplicaSet，確保 Pod 可以在其他節點上運行。

十九、Kubernetes 中的 StatefulSet 與 Deployment 有什么區別？

StatefulSet 和 Deployment 都是用于管理 Pod 的控制器，但它們適用于不同類型的應用：

? Deployment：適用于無狀態應用，Pod 的副本可以相互替換，Pod 的名字和順序沒有重要意義。

? StatefulSet：適用于有狀態應用，需要保持 Pod 的唯一標識和順序。StatefulSet 會為每個 Pod 提供一個穩定的持久存儲和網絡標識。

二十、 Kubernetes 中的 PersistentVolume（PV）和 PersistentVolumeClaim（PVC）是什么？它們如何工作？

Kubernetes 中的 PersistentVolume（PV） 和 PersistentVolumeClaim（PVC） 是用于管理持久存儲的資源：

? PersistentVolume（PV）：是集群中的一個存儲資源，它表示一個具體的存儲設備，可能是一個 NFS 存儲、云存儲（如 AWS EBS）或本地磁盤等。

? PersistentVolumeClaim（PVC）：是用戶向 Kubernetes 申請持久存儲的一種方式，它定義了所需存儲的大小、訪問模式等要求。Kubernetes 根據 PVC 自動綁定適當的 PV。

這種機制支持存儲資源的動態分配，確保存儲的生命周期與 Pod 分離，Pod 可以訪問到持久存儲。

二十一、 Kubernetes 中的監控和日志如何結合使用？

Kubernetes 的監控和日志結合使用可以幫助開發和運維人員更好地掌握集群狀態和故障排查：

? 監控：使用 Prometheus 來收集集群和應用的指標（如 CPU、內存、網絡流量等），通過 Grafana 可視化展示。

? 日志管理：使用 ELK Stack（Elasticsearch、Logstash、Kibana）來集中管理和查詢 Kubernetes 的日志。

? 集成：將 Prometheus 和 Grafana 與日志管理工具（如 Fluentd 或 Filebeat）集成，通過統一的面板和報警系統，提高監控和日志的響應效率。

二十二、Kubernetes 中如何處理存儲資源的動態供給？

Kubernetes 通過 StorageClass 和 動態存儲供給（Dynamic Provisioning） 實現存儲資源的自動化管理。通過定義 StorageClass，用戶可以自動為 PVC 申請合適的存儲類型（如 SSD、HDD 或云存儲）。

? 使用 StorageClass，可以定義不同存儲類型的參數，并在 PVC 中指定該 StorageClass，Kubernetes 會根據該配置自動創建和綁定 PV。

二十三、Kubernetes 中的 Affinity 和 Anti-Affinity 是如何工作的？

Kubernetes 中的 Affinity 和 Anti-Affinity 是控制 Pod 調度策略的機制，用于指定 Pod 在節點上的調度規則：

? Affinity：允許指定 Pod 在相同節點上調度，或在特定條件下與其他 Pod 調度在一起。例如，可以使用 nodeAffinity 讓 Pod 只調度到特定標簽的節點上。

? Anti-Affinity：用于確保 Pod 不與其他指定的 Pod 調度在同一節點或同一可用區。例如，可以確保某些 Pod 在不同節點上運行，以避免單點故障。

二十四、 Kubernetes 中如何處理 Pod 的優先級和搶占？

Kubernetes 支持通過 PodPriority 和 PriorityClass 來設置 Pod 的優先級。高優先級的 Pod 可以搶占低優先級的 Pod 資源，確保關鍵服務優先運行。

? PriorityClass：通過為 Pod 設置不同的優先級，控制 Pod 在資源爭奪時的調度順序。

? Pod搶占：如果集群資源緊張，Kubernetes 會終止優先級較低的 Pod 來為高優先級的 Pod 提供資源。

二十五、 Kubernetes 中的 Ingress 和 Egress 是如何控制流量的？

Kubernetes 提供了 Ingress 和 Egress 控制流量進出集群的方式：

? Ingress：是一種 API 資源，允許外部流量通過 HTTP/HTTPS 訪問 Kubernetes 內部服務。Ingress 通常由 Ingress Controller 實現（如 Nginx Ingress Controller）。

? Egress：是集群內的 Pod 發起的流量訪問外部網絡。可以通過配置 NetworkPolicy 來控制 Pod 的出站流量，限制哪些 Pod 可以訪問外部服務。

二十六、Kubernetes 中的 RBAC（Role-Based Access Control）如何控制權限？

RBAC 是 Kubernetes 中的權限管理系統，用于控制用戶或服務賬戶在集群中的操作權限。RBAC 通過定義 Role 和 RoleBinding 來授予權限：

? Role：定義在某個命名空間內的權限，如訪問資源的權限（Pods、Services 等）。

? ClusterRole：定義集群范圍內的權限。

? RoleBinding 和 ClusterRoleBinding：將 Role 或 ClusterRole 綁定到特定的用戶或服務賬戶。

二十七、Kubernetes 中如何處理事件日志？

Kubernetes 中的事件日志用于記錄集群狀態和各類事件，如 Pod 啟動、容器重啟、資源限制等。可以使用 kubectl get events 命令查看事件日志。

? Kubernetes 中的事件是由 Kubelet、Controller Manager 等組件生成的。

? 集成日志管理：可以使用 Fluentd、Elasticsearch 和 Kibana（ELK Stack） 等工具來集中管理和分析 Kubernetes 事件日志。

二十八、 Kubernetes 中的 PodDisruptionBudget（PDB）是什么？如何使用？

PodDisruptionBudget（PDB）用于控制 Pod 的可中斷性，確保在升級或維護時至少有一定數量的 Pod 處于運行狀態。PDB 通過定義 maxUnavailable 或 minAvailable 來保證在允許的范圍內，Pod 可以被中斷。

例如，設置一個 PDB，確保最多只能有一個 Pod 被中斷：

apiVersion: policy/v1
kind:PodDisruptionBudget
metadata:
name:myapp-pdb
spec:
minAvailable:2
selector:
    matchLabels:
      app: myapp

二十九、Kubernetes 中的資源管理器（Resource Manager）如何確保集群資源的公平分配？

Kubernetes 的資源管理器（Scheduler） 通過以下方式確保資源的公平分配：

? 資源請求和限制：每個 Pod 在調度時，Kubernetes 會根據資源請求和限制來選擇最合適的節點。

? QoS 策略：通過 QoS 類別（Guaranteed、Burstable、BestEffort）來管理 Pod 的優先級和資源分配。

? 調度策略：如資源親和性、節點親和性等，幫助在資源有限的情況下，做出最合適的資源調度決策。