高階K8S面試題你會幾個？

前言

K8S架構、公有云、持久化存儲、HELM、CICD、負載均衡、監控告警、可觀察性、服務治理、架構探索。。。

Q1：如何調試 Kubernetes 集群中的網絡連接問題，比如 Pod 間通信失敗的情況？

狀態檢查：使用?kubectl get pods?和?kubectl describe pod?確認 Pod 狀態及事件。
網絡策略審查：檢查是否有NetworkPolicy阻止通信。
DNS驗證：在 Pod 內執行?nslookup?檢查服務名稱解析。
連通性測試：使用?ping?或?nc?測試到目標 Pod IP 的連通性。
網絡插件檢查：確保網絡插件（如Calico, Flannel）運行正常，檢查其 Pod 狀態。
接口與路由：檢查節點上的網絡接口配置和路由規則。
抓包分析：必要時，在 Pod 或節點層面使用?tcpdump?抓包。
日志審查：分析 kubelet、網絡插件及 API Server 日志。
外部因素：檢查防火墻規則、安全組及外部 DNS 配置。

Q2：闡述 Kubernetes 中的資源配額（ResourceQuota）和?LimitRange，它們是如何幫助集群資源管理？

ResourceQuota： ResourceQuota 允許咱們在命名空間級別設置資源使用上限，包括CPU、內存、存儲、Pod數量、服務數量等多種資源類型。這有助于控制單個團隊或項目的資源消耗，確保集群資源不會被個別用戶過度占用，從而保持集群的穩定性和整體效率。

案例：假設有一個多租戶平臺，不同部門或項目分別有自己的命名空間。為了防止某個部門的大量應用消耗所有資源，影響其他部門的服務，可以為每個命名空間設置 ResourceQuota。例如，為 “研發部” 命名空間設置最大CPU使用量為4核，內存為8GiB，這樣即使該部門的應用激增，也不會影響到 “市場部” 的資源需求。

LimitRange： LimitRange 在命名空間內部起作用，它為 Pod 或容器定義資源使用的默認值、最小值和最大值，確保每個 Pod 的資源請求和限制落在合理的范圍內。這有助于規范資源配置，避免因配置不當導致的資源浪費或應用運行問題。

案例：在一個教育機構的 Kubernetes 集群中，教師和學生頻繁部署實驗應用。為了防止資源濫用和保證所有應用都能公平地獲取資源，管理員在 “教學實驗室” 命名空間設置了 LimitRange。規定所有 Pod 的 CPU 請求至少為 0.1 核，最大不超過 2 核，內存請求至少為 100MiB，最大不超過 1GiB 。這樣既保證了每個應用有足夠的資源啟動，也限制了個別應用占用過多資源，導致其他應用無法運行的情況。

Q3：設計一個 Kubernetes 高可用集群的架構，并解釋每個組件的冗余策略？

控制面組件冗余：
- API Server: 使用多實例部署，通常至少三個，后面跟著負載均衡器（如HAProxy或云提供商的負載均衡服務），實現請求分發和故障轉移。
- etcd: 集群化部署，至少三個成員以形成多數派（quorum），確保數據的一致性和高可用性。etcd 成員之間采用 Raft 協議進行共識。
- Controller Manager?& Scheduler（可選）: 同樣采用多實例部署，通過Leader選舉機制確保高可用，通常與API Server配合使用相同的負載均衡策略。
網絡通訊：
- 選擇活躍度較高且較為成熟的網絡插件，如 Calico、Flannel?等，并確保其跨節點配置一致，支持多主機間冗余。
- 對于外部訪問的服務，使用云提供商的高可用負載均衡器或自建高可用 Ingress 控制器（如 Ingress-nginx Controller），確保入口流量的可靠分發。
節點和工作負載冗余：
- 節點分布：確保節點分布在不同的可用區（AZ），以防止單一區域故障導致整個集群不可用。
- Pod副本集：?利用Deployment/StatefulSet管理應用，使用調度規則自動化將 Pod 打散到多可用區；
存儲高可用：
- 持久卷: 選擇支持高可用的存儲解決方案，如分布式存儲系統（Ceph、GlusterFS、MiniO）、云提供商的塊存儲服務，并使用動態卷供給（Dynamic Volume Provisioning）簡化管理。
- 備份與恢復: 定期備份 etcd 數據和其他關鍵應用數據，使用工具如 Velero 實現災難恢復策略。
監控與日志：
- 監控系統: 部署高可用的 Prometheus 集群，采用聯邦機制，結合 PrometheusAlert 進行精確告警，Grafana 展示儀表盤，確保能夠持續監控集群狀態。
- 日志收集: 使用如 Fluentd 或 EFK（Elasticsearch, Fluentd, Kibana）堆棧集中收集和分析日志，確保日志系統的可靠性。
安全措施：
- 網絡策略: 使用 Network Policies 限制 Pod 間通信，增強安全性。
- RBAC: 細粒度的訪問控制，確保只有授權用戶和進程能訪問和操作資源。
- 安全掃描與補丁管理: 定期進行容器鏡像的安全掃描，及時應用系統和軟件更新。

Q4：描述如何實施災難恢復計劃，包括數據備份與恢復策略，以及跨區域多活方案？

需求分析：在我們公司，我們會針對應用進行分類，核心/非核心/邊緣/GPU/計算等指標來識別關鍵業務，配置RTO/RPO的標準。
數據備份：使用 Velero 定期備份至異地存儲，實施增量/差異備份，備份存儲在地理上獨立的區域或第三方備份存儲服務中，定期驗證。
跨區域多活方案：
- 不同地域部署 K8s 集群，可以采用例如：karmada，可根據集群負載、地域親和性等條件，自動將工作負載調度到最適合的集群中，實現資源的高效利用和負載均衡。
- 提供統一的控制平面，這樣運維人員能夠在一個界面下管理多個地域的K8s集群，簡化操作復雜度，提高管理效率。
- 結合云供應商的跨區域數據庫服務或自研數據復制方案，確保應用狀態和數據在多集群間保持一致，支撐應用無縫跨越多個區域運行。
- 可根據業務需求和各集群的實時負載情況，自動擴縮容，實現資源的動態調整，優化成本與性能。
- 在某區域集群出現故障時，例如 Karmada 可快速重新調度受影響的工作負載至其他健康集群，加速服務恢復，實現高可用性。
- 利用云提供商的跨區域數據庫服務或自建數據同步方案（如MySQL Galera Cluster、Cassandra的多數據中心部署）保持數據實時或近實時同步。
- 使用全局負載均衡器（如AWS Global Accelerator、阿里云AnyCast、DCDN等）自動就近上車，基于骨干網到達底層 Pod，確保用戶體驗不受影響。
故障切換：自動故障檢測，實現自動化或半自動化的故障切換腳本，快速將流量切換至備用區域，同時通知 Noc 團隊。制定詳細恢復流程文檔。
演練優化：定期演練、評估、持續改進計劃。確保災時快速響應，保護業務連續性。

Q5：如何監控和優化 Pod 的資源使用，包括 CPU、內存及存儲資源？

監控層面大家可以按照這幾個層面來聊下：

使用metrics-server：首先，確保集群部署了metrics-server，這是 Kubernetes 默認的資源使用度量收集器，用于提供 Pod 和 Node 級別的 CPU 及內存使用情況。
集成監控工具：集成如 Prometheus 和 Grafana 等監控工具。Prometheus 可以通過 Kubernetes 服務發現自動發現 Pod 和 Node，并通過安裝 kube-state-metrics 和 node-exporter 來收集更詳細的指標。Grafana 則用于可視化展示這些指標，幫助直觀理解資源使用趨勢和異常。
日志分析：利用 ELK Stack（Elasticsearch, Logstash, Kibana）或 Fluentd 等日志收集與分析工具，分析 Pod 日志中可能隱藏的資源使用異常信息。
告警設置：在監控系統中設置合理的資源使用閾值告警，當 Pod 資源使用達到或超過預設閾值時，及時通知運維團隊，以便采取相應措施。

優化層面，可以參考如下建議：

合理設置資源請求與限制：為每個Pod的容器明確設置requests和limits，確保容器能夠獲得足夠的資源運行，同時避免過度消費資源導致其他Pod受到影響。通過LimitRange來引導和強制執行資源請求與限制的最佳實踐。
垂直與水平自動縮放：對于CPU和內存使用波動較大的應用，使用HPA（Horizontal Pod Autoscaler）根據CPU利用率自動增加或減少Pod副本數。對于單個Pod內部，可探索基于資源使用情況的VPA（Vertical Pod Autoscaler）進行自動資源調整。
優化容器鏡像：減小容器鏡像大小，減少啟動時間，優化基礎鏡像選擇，確保只包含運行應用所必需的庫和依賴，減少內存占用。
使用Init Containers：在主要容器啟動前，使用Init Containers預加載數據或執行耗時的初始化任務，避免影響主要容器的資源需求和啟動速度。
存儲優化：對于存儲資源，采用按需掛載卷（如EmptyDir）處理臨時文件，對于持久化存儲，合理配置PV/PVC的回收策略，優化數據去重和壓縮策略，減少存儲空間使用。

Q6：解釋如何使用密鑰管理系統（如 Secrets 和 ConfigMaps）來保護敏感數據，并討論潛在的風險和最佳實踐？

Secrets 用途：Secrets 主要用于存儲敏感信息，如密碼、API密鑰、TLS證書等。Kubernetes會對Secrets中的數據進行加密存儲，并在使用時解密，以確保數據的安全性。一般都是通過 volume 或 environment variable 的方式引用 Secret，然后在 Pod 內可用。

ConfigMaps 用途：ConfigMaps用于存儲非敏感的配置數據，比如應用的配置文件內容。雖然不是專為敏感數據設計，但在某些場景下也可能包含敏感信息，因此也需謹慎處理。大多數的場景也都是通過 volume 掛載或環境變量引用 ConfigMap 中的數據。

另外幾點，在真正的線上，為了避免一些問題，我們可以基于如下幾個動作來做一些調整：

最小權限原則：僅為需要訪問 Secrets 和 ConfigMaps 的實體分配最小必要的權限。
使用自動化工具：利用 CI/CD 管道和工具自動創建、管理和更新 Secrets，減少人為操作失誤。
定期密鑰輪換：實施密鑰管理策略，定期自動輪換 Secrets 中的密鑰。

Q7：你是如何在 Kubernetes 集群中實施日志收集，請具體說明使用的工具和技術？

通常日志收集組件我們會選擇 Fluentd 或者 Filebeat 作為日志收集、處理和轉發的工具，通過配置不同的輸入插件收集容器日志，然后通過輸出插件將日志發送到如Elasticsearch、Splunk等后端存儲系統。

在基于 kubernetes 的集群環境下，我們通常會有2種方式去采集日志，例如：

DaemonSet：部署日志代理（如Fluentd或Filebeat）作為DaemonSet，確保每個節點上都運行一個代理實例，自動收集該節點上所有 Pod 的日志。
Sidecar容器：為每個需要日志收集的應用 Pod 添加一個 sidecar 容器（如 Fluentd 或 Filebeat ），這種方式提供了更細粒度的控制，適合需要單獨處理每個應用日志的情況。

另外有時候在做一些日志收集的時候，我們需要針對日志流做一些特殊處理，例如：

日志驅動：在Docker或Container Runtime層配置日志驅動（如json-file、syslog、fluentd等），直接將容器日志發送給日志收集服務。
標簽和解析：利用日志代理的標簽功能，為日志打上Pod、Namespace等元數據標簽，便于后續查詢和分析。
數據流處理：在日志收集過程中，可能需要對原始日志進行清洗、解析和結構化處理，以適應后續的存儲和分析需求。

通常的日志存儲及分析，多數都是采用開源的成熟方案，例如：

Elasticsearch：常作為日志數據的存儲后端，因其強大的搜索和分析能力，非常適合大規模日志數據的索引和查詢。
Kibana：提供可視化界面，用于搜索、分析和展示Elasticsearch中的日志數據，幫助快速定位問題和洞察應用行為。
Prometheus + Grafana：雖然主要用于指標監控，但也可以與其他工具集成，用于日志監控和報警。

至于在后續的運維管理中，我們也要注意，例如：

安全：確保日志數據傳輸和存儲過程中的加密，使用 RBAC 控制對日志訪問權限。
成本控制：根據需要實施日志保留策略和滾動策略，避免無限制的日志增長導致存儲成本上升。
監控與報警：設置日志收集和處理流程的健康檢查，以及針對特定日志內容的報警規則，確保日志系統本身的高可用性和問題的及時發現。

Q8：你是如何在 Kubernetes 集群中落地監控和告警系統的？

通常現在基于 kubernetes 的集群部署方式有 Helm charts 或 Operator，其主要目的還是簡化 Prometheus 及其相關組件（如Alertmanager、Pushgateway）的部署與管理。

在數據收集層面，因為設計的維度比較多，我這邊給大家一個思路：

按照組件進行分類：

控制平面組件：
- kube-apiserver：Kubernetes API Server 的監控包括請求數量、請求延遲、錯誤率等。
- kube-controller-manager：監控控制器的副本數、滾動更新狀態、故障檢測等。
資源管理組件：
- kube-scheduler：監控調度算法、節點負載和調度決策等。
容器運行時組件：
- kubelet：監控節點上的 Pod 運行狀態、資源使用情況、容器啟動錯誤等。
- container runtime（如Docker、containerd等）：監控容器的運行狀態、資源使用情況、鏡像存儲等。
網絡組件：
- kube-proxy：監控網絡規則、服務代理狀態、連接數等。
- CoreDNS：監控域名解析請求、緩存命中率等。

按照不同的維度進行分類：

節點級監控（node-exporter）：Prometheus 可以監控 Kubernetes 集群中每個節點的資源使用情況，如 CPU、內存、磁盤和網絡等。它通過與 kubelet 交互，并收集節點級別的指標數據。
Pod 級監控（metrics-server）：Prometheus 可以監控每個 Pod 的運行狀態和性能指標，如 CPU 使用率、內存使用量、網絡流量等。它通過與 kubelet 和 cAdvisor 進行交互，并收集 Pod 級別的指標數據。
服務級監控（blackbox-exporter）：Prometheus 可以監控 Kubernetes 集群中的服務，包括 Service 和 Ingress 等。它可以通過與 kube-proxy 交互，獲取服務的請求流量、響應時間和錯誤率等指標。
控制器級監控（kube-state-metrics）：Prometheus 還可以監控 Kubernetes 集群中的控制器，如 Deployment、StatefulSet 等。它可以獲取控制器的副本數、滾動更新狀態和故障檢測等指標。
自動服務發現：Prometheus 支持使用 Kubernetes 的服務發現機制自動發現和監控新的 Pod 和服務。它會根據 Kubernetes 的標簽和注解信息，動態生成相應的監控配置。

再者，我們就可以集成 Grafana 以展示 Prometheus 收集的指標，創建儀表板和圖表，實現可視化監控。

最后在監控告警階段，由于 alertmanager 的能力有限，如果針對特別復雜且要求精度又比較高的場景，就不建議去使用了，還是比較推薦 PrometheusAlert 去做一個變現。

最后再提一個不得不說的事情，Prometheus的監控會隨著時間的拉長，產生一系列不需要的臟數據，后續大家可以根據需要調整存儲配置、采樣率等參數，以優化性能和資源使用。

Q9：描述一個完整的 Kubernetes CI/CD 流水線，包括代碼提交、構建、測試和部署到生產環境的過程。

一個完整的 Kubernetes CI/CD 流水線是自動化從代碼提交到生產環境部署的整個過程，確保敏捷、快速、可靠地交付。

下面我來通過一個大概的主流程來給大家描述下一個典型的 CI/CD 流水線示例：

1. 代碼提交

開發者在版本控制系統（如Git）中提交代碼變更，并關聯到特定的 release 分支或向主分支發起 Push Request。
代碼審查團隊成員對提交的代碼進行審查，確保質量并符合編碼規范。

2. 持續集成（CI）階段

觸發構建：代碼倉庫（如GitHub、GitLab）與CI/CD工具（如Jenkins、GitLab CI/CD、Tekton）集成，一旦有代碼提交或PR創建，自動觸發構建流程。
靜態代碼分析：自動執行代碼風格檢查、安全掃描（如SonarQube）、依賴項分析，確保代碼質量和安全性。
構建鏡像：使用 Dockerfile 構建應用的 Docker 鏡像，或通過 Kaniko、Buildah 等工具在無守護進程環境中構建，確保安全性。
鏡像推送：將構建好的鏡像推送到私有鏡像倉庫（如 Harbor、Docker Hub、Google Container Registry）。

3. 持續部署/持續交付（CD）階段

環境隔離：流水線通常會涉及多個環境，如開發、測試、預發布和生產環境，每個環境配置獨立，確保更改不會直接影響生產。
自動化測試：
- 單元測試：運行單元測試，確保代碼模塊的正確性。
- 集成測試：在模擬環境下進行服務間交互測試。
- 端到端測試（E2E）：在接近生產環境的測試環境中，模擬用戶操作進行全鏈路測試。
部署準備：基于測試結果決定是否繼續部署。通過 GitOps（如 Jenkins、Argo CD、FluxCD）或 Kubernetes Manifests 管理工具，準備部署配置。
藍綠部署/金絲雀發布/滾動更新：根據策略選擇合適的部署策略，將新版本應用逐步或全部替換舊版本，確保服務的平滑過渡。
- 藍綠部署：先部署新版本到備用環境，驗證無誤后切換流量。
- 金絲雀發布：先將新版本部署到少量實例上，逐步擴大范圍。
- 滾動更新：逐個替換舊Pod，保證服務的連續性。
回滾策略：部署失敗時，自動或手動觸發回滾操作，恢復到上一穩定版本。

整個CI/CD流程高度自動化，從代碼變更到生產環境的部署可以快速完成，同時確保高質量和高可用性，大大縮短了軟件迭代周期。

Q10：如何利用 Kubernetes 的 Deployment、StatefulSet、DaemonSet 等資源對象來支持不同類型的微服務部署需求？

在 Kubernetes 中，Deployment、StatefulSet?和?DaemonSet是用于部署和管理容器化應用的主要資源對象，每種資源對象都有其特定的使用場景和特點，以滿足不同類型的微服務部署需求：

Deployment：

應用場景：適用于無狀態服務，如web服務器、API服務器、配置服務等，這些服務的實例之間不保存狀態，可以任意替換。
特點：
- 自動化管理 Pod 副本數量，實現滾動更新、自動擴展和回滾等功能。
- 當 Pod 意外終止時，自動創建新的 Pod 以維持期望的副本數量。
- 支持標簽選擇器（label selectors）來確定哪些Pod受其管理。

StatefulSet：

應用場景：面向有狀態服務，如數據庫（MySQL、PostgreSQL）、消息隊列（Kafka）、分布式存儲系統等，這些服務需要持久化存儲和穩定的網絡標識。
特點：
- 為每個 Pod 提供唯一的標識符和穩定的網絡名稱，保證 Pod 重啟或擴展時數據的一致性和順序性。
- 集成了存儲卷的持久化，確保每個 Pod 綁定到特定的存儲卷，即使 Pod 重啟也不改變。
- 支持有序的 Pod 創建和刪除，保障服務的順序性和依賴性。

DaemonSet：

應用場景：確保在每個節點（或滿足特定條件的節點）上運行一個Pod實例，適用于節點級的任務，如日志收集（Fluentd）、監控代理（Prometheus Node Exporter）等。
特點：
- 每個節點上最多只有一個 Pod 副本，確保服務的全局分布。
- 當新的節點加入集群時，自動在新節點上部署 Pod。
- 當節點被移除時，其上的 DaemonSet 管理的 Pod 也會被清理。

實現不同微服務部署需求：

對于需要水平擴展、頻繁更新且不關心實例間狀態的應用，使用?Deployment?是最合適的選擇。
對于有狀態服務，需要保持數據持久性和實例間有固定身份標識的，采用?StatefulSet?來確保數據的連貫性和服務的高可用性。
若服務要求在每個節點上都運行一個實例，以監控或管理節點級資源，DaemonSet?則是最佳實踐。

Q11：解釋 Kubernetes 中的不同存儲類（StorageClass）以及動態卷供給（Dynamic Volume Provisioning）的工作原理？

動態卷供給（Dynamic Volume Provisioning）是 Kubernetes 的一項功能，它允許根據用戶的需求自動創建和管理 Persistent Volumes (PV)。在沒有動態供給前，管理員需要手動創建 PV，然后用戶才能通過 PVC 綁定到這些 PV 來使用存儲。動態供給簡化了這個過程，當用戶創建 PVC 時，Kubernetes 會檢查 PVC 中請求的存儲量和訪問模式，然后匹配到合適的 StorageClass，接著根據該 StorageClass 的配置自動向底層存儲系統請求創建相應的 PV。一旦 PV 創建成功，它會被立即綁定到 PVC 上，使得 Pod 可以使用該存儲。

工作原理概括如下：

**用戶定義PersistentVolumeClaim (PVC)**：用戶根據應用需求定義PVC，指定所需的存儲大小、訪問模式（如ReadWriteOnce、ReadOnlyMany等）和希望使用的 StorageClass（可選，若未指定且集群有默認存儲類，則使用默認）。
Kubernetes查找StorageClass：Kubernetes 檢查 PVC 中指定的 StorageClass，如果沒有指定，則嘗試使用默認存儲類。
**動態創建PersistentVolume (PV)**：Kubernetes 根據 StorageClass 的配置，調用對應的存儲插件（如NFS插件、云提供商的API等）來創建實際的存儲資源。這一步驟完全是自動化的，無需人工干預。
PV與PVC綁定：新創建的PV與PVC自動綁定，此時，PV的狀態變為Bound，PVC也變為Bound，表示存儲資源已經準備好供Pod使用。
Pod使用存儲：Pod通過引用綁定到PVC，間接使用PV提供的存儲空間。當Pod不再需要存儲時，PVC可以被刪除，如果配置得當，相應的PV也會被回收，釋放存儲資源。

Q12：分享一次 Kubernetes 集群性能瓶頸的識別和解決經歷，包括診斷工具和方法？

在一次線上生產環境中，遇到過一個節點頻繁進入?NotReady?狀態的故障案例。此故障直接導致部分 Pod 無法調度，影響了服務的正常運行。

以下是排查與解決的詳細過程：

1）通過 Prometheus 告警，發現某節點標記為?NotReady，通過命令或界面檢查節點狀態；

2）對于Linux節點，可以通過SSH登錄到故障節點，檢查系統日志（如/var/log/messages、journalctl -u kubelet）以尋找錯誤信息；

3）根據容器運行時檢查對應日志，尋找容器啟動失敗或異常退出的記錄；

4）檢查基礎例如磁盤，網絡(ping, curl) 檢查網絡連通性，以及檢查網絡插件（如Calico, Flannel）的狀態及日志。

5）通過上述步驟，發現該節點的 kubelet 日志中頻繁出現關于 cAdvisor（Kubernetes資源使用統計組件）無法啟動的錯誤，進一步調查得知是由于節點上缺少必要的 cAdvisor 依賴庫文件，導致 kubelet 服務啟動失敗。

問題解決：登錄問題節點，安裝或重新配置缺失的依賴庫，確保cAdvisor可以正常運行，修復依賴后，重啟 kubelet 服務(systemctl restart kubelet)，觀察節點狀態是否恢復正常，使用?kubectl describe node?和?kubectl get nodes?確認節點狀態，持續監控節點健康狀況，確保問題徹底解決。

Q13：當遇到 Kubernetes 核心節點故障時，你的排查步驟是什么？如何快速定位并恢復服務？

當遇到 Kubernetes 核心節點（特別是控制平面節點，如apiserver、etcd、controller-manager、scheduler）故障時，問題的嚴重性和處理方式與普通工作節點有所不同，因為控制平面節點的穩定性直接影響到整個集群的管理和運行。

下面我來針對這類故障的排查和恢復步驟給出一些建議，為了方便大家記憶，我這邊按照幾個層面來展示：

確認故障狀態：

首先查看集群的監控工具（如Prometheus、Grafana）是否有控制平面組件相關的報警；
直接訪問或通過?kubectl cluster-info?檢查apiserver、etcd等組件的可達性和狀態；

通過日志分析：

獲取故障組件的日志（如apiserver的日志通常位于/var/log/kubernetes/目錄下），通過日志查找錯誤信息；
檢查系統層面的日志，如/var/log/messages或使用journalctl，以發現潛在的系統級問題；

檢查資源與網絡：

確認是否有資源耗盡問題，如CPU、內存或磁盤空間不足；
檢查網絡配置，確保內部通信和外部訪問（如apiserver的端口）未受阻；

快速恢復服務：

備份與恢復：對于 etcd 等關鍵組件，如果之前有做數據備份，可以考慮使用備份恢復數據。
緊急恢復措施：對于單點故障（如 apiserver 只有一臺），考慮臨時啟動備用實例或使用云服務商的高可用特性快速恢復服務。
重啟或替換：對于因軟件異常導致的問題，嘗試重啟服務或在故障排查無果后，考慮在新節點上重建故障組件。

當然如果有條件，可以定期對如上核心組件做故障演練，編寫詳細的故障處理報告，包括故障現象、處理過程、根本原因及最終解決方案。這樣出現問題后也會游刃有余的按照手冊操作即可！

Q14：請解釋自定義資源定義 (Custom Resource Definitions) 的概念，以及它們如何擴展 Kubernetes API？

自定義資源定義（Custom Resource Definitions，簡稱 CRDs）是Kubernetes 提供的一種核心擴展機制，它允許用戶在 Kubernetes API 中定義新的資源類型，這些資源類型并非 Kubernetes 原生內置的（比如Pods、Services、Deployments等）。通過 CRDs，用戶能夠根據自己的應用場景創建符合特定需求的資源對象，從而擴展 Kubernetes 的功能和適用范圍，使之更加靈活和強大。

至于如何通過 CRDs 去擴展 API，一般對于運維工程師的要求不多，針對二開的同學可能需要更多的關注下：

定義 CRD：首先，你需要定義 CRD 的 YAML 文件，說明自定義資源的名稱、字段、驗證規則等信息。這個定義文件描述了自定義資源的結構和行為，然后通過?kubectl apply?命令提交給集群。
創建自定義資源實例：定義好 CRD 后，就可以開始創建這種類型的資源實例了。這些實例會由 Kubernetes API 服務器管理，并存儲在集群的持久化存儲（如 etcd）中。
開發自定義控制器：為了使自定義資源具有實際的功能（比如自動部署應用、配置管理等），通常還需要編寫自定義控制器（如 Operator）。控制器監視這些自定義資源的變化，根據資源的狀態和定義的邏輯自動執行相應的操作，如創建或修改其他 Kubernetes 資源。
集成與交互：自定義資源和控制器一起工作，使得用戶可以以聲明式的方式管理復雜的有狀態應用或其他特定于業務的組件，而無需直接操作低級別的 Kubernetes 資源。

Q15：請描述實現一個基于 Istio 的服務間通信的故障注入演練，簡單說明配置及目的？

在 Istio 中，實現服務間通信的故障注入演練是一種常見的混沌工程實踐，它主要用于評估系統在模擬故障條件下的健壯性和彈性。

這種方法可以幫助開發者和運維小伙伴提前發現并修復潛在的故障點，增強系統的可靠性。

下面我來通過一個例子的展示來給大家介紹下，基于 Istio 實現服務間通信故障注入的基本配置及目的（直接尬聊貌似看不出效果）：

假設我們有一個由兩個微服務組成的應用程序：“frontend” 和 “backend”。我們的目標是在 “frontend” 調用 “backend” 服務時，故意引入網絡延遲，模擬網絡不穩定場景。

步驟：

確保Istio已安裝并啟用：首先，確保你的 Kubernetes 集群中已安裝了 Istio，并且你的服務都已經被注入到了 Istio 的服務網格中。
創建 DestinationRule 配置：使用 Istio 的 DestinationRule 資源來定義故障注入的策略。

Q16：解釋如何利用 Kubernetes 事件系統進行集群活動的監控和追蹤？

我們先來理解下，為什么要做這件事情？首先 Kubernetes 的事件系統記錄了集群中發生的各種事件，如 Pod 的創建、刪除、更新，以及其他資源（如 Service、Deployment 等）的更改。這些事件為集群管理員或開發者提供了關于集群狀態和活動的重要信息。

針對集群的event，我們可以采用很多種方式，其中?kubectl get events?命令來查看集群中的所有事件，但是這種手動的查看明顯不是咱們需要的，那么對于更復雜的監控需求，我們一般是通過日志系統（EFLK）或者 Kubewatch 來滿足更多的要求。

主要來講下 kubewatch：

Kubewatch 是一個輕量級的工具，可以實時監聽 Kubernetes API 服務器的事件流，并在發生變更時觸發預定義的操作。
通過 Kubewatch，咱們可以配置在特定事件發生時發送通知（如 HTTP webhook 調用）。這對于快速響應集群中的關鍵事件（如 Pod 故障或資源不足）非常有用。

有了順手的工具，下一步就根據你的分析結果，配置警報規則，以便在關鍵事件發生時自動發送通知。有助于確保及時響應和解決潛在問題。

Q17：分享幾個在 Kubernetes 上進行成本優化的策略，比如閑置資源回收、Spot實例的使用？

在成本優化上業界有很多種解決方案，但是基于 kubernetes，更多的咱們需要結合 kubernetes 的一些高級特性去做深度應用，可以從如下幾個層面：

自動伸縮（Horizontal Pod Autoscaler, HPA）: 根據實際工作負載自動調整應用實例數量，減少不必要的運行實例。
Vertical Pod Autoscaler (VPA): 根據 Pod 的實際資源使用情況動態調整 CPU 和內存請求，避免資源過度分配。
Pod驅逐策略與優先級: 設置 Pod 的優先級和搶占政策，確保關鍵服務得到資源保障，非關鍵服務在資源緊張時被優先驅逐。
CronJob清理: 定期檢查并清理已完成的 Job 和 CronJob，避免資源占用。

針對 Spot 實例的場景，目前在云上應用的比較多，但是使用的前提，我們需要結合 Spot 的特性和應用的特性來做一個匹配，也需要注意如下幾點：

結合按需實例和 Spot 實例，確保基礎服務運行在按需實例上，可中斷服務或批處理任務運行在 Spot 實例上。
設置 Spot 實例的最大出價，避免成本失控，同時利用 Spot 實例的低成本優勢。
利用 Kubernetes 的節點親和性和污點/容忍機制，確保 Pod 能夠在 Spot 實例被回收前自動遷移至其他節點。
使用如 Karpenter（AWS開源項目）工具，自動化管理 Spot 實例的生命周期，包括自動擴容、縮容和中斷處理。

另外從優化層面，大家也可以站在這些維度，例如：

優化鏡像大小，減少拉取時間，使用多階段構建減少層的重復，利用緩存；
配置kubelet的垃圾回收策略，定期清理不再使用的鏡像和容器；
結合每個應用的特性，為每個 Pod 設置合理的資源請求和限制（QoS），避免資源過度消耗或浪費。
也可以使用一些成本分析工具，利用如 Kubecost、Kubernetes Cost Analyzer 等工具進行細粒度的成本分析，識別成本熱點。

Q18：闡述 Kubernetes 調度器的工作流程，包括預篩選、打分和綁定階段，并解釋如何自定義調度策略以滿足特定業務需求？

在 kubernetes 中調度流程大致可以分為三個主要階段：預篩選（Predicate）、打分（Scoring）和綁定（Binding）。

下面我來詳細闡述這些階段，并進一步說明如何自定義調度策略以適應特定的業務需求：

1、預篩選（Predicate）階段

這個階段的目標是從所有可用節點中過濾掉那些不滿足 Pod 運行基本要求的節點。預篩選主要基于硬性約束（Hard Constraints），比如：

資源需求：檢查節點是否有足夠的 CPU、內存等資源來滿足 Pod 的請求和限制。
Pod親和性與反親和性：確認 Pod 是否能夠根據其定義的標簽選擇或避免特定節點。
污點與容忍度：檢查 Pod 是否能夠容忍節點上的污點或是否有相應的容忍規則。

不符合任何硬性約束的節點會被立即排除。

2、打分（Scoring）階段

經過預篩選后，剩余的節點將進入打分階段。這一階段主要是基于軟性約束（Soft Constraints），為每個節點分配一個分數，反映其對當前 Pod 的適宜程度。Kubernetes 內置了幾種打分策略，如：

資源量：節點剩余資源越多，得分越高。
親和性/反親和性：符合 Pod 親和性規則的節點得分更高。
交互性：如果 Pod 與某些 Pod 需要在同一節點上運行（如共享數據卷），則該節點得分更高。

打分階段的目的是找到理論上最適合運行Pod的節點。

3、綁定（Binding）階段

最終，得分最高的節點（或達到一定分數閾值的節點）被選中，調度器將 Pod 綁定到該節點上，并在 etcd 中創建一個綁定對象（Binding），通知節點開始下載并運行 Pod。

4、針對自定義調度，主要是為了靈活的機制來定制調度策略，以滿足特定業務需求：

1）可以編寫自定義的調度插件，通過實現Kubernetes調度框架的接口，插入到預篩選或打分階段，以增加新的約束條件或評分邏輯。

2）通過在節點上設置特定的污點（Taints 與 Tolerations），并在 Pod 上設置相應的容忍度，可以實現更為精細的調度控制。這適用于需要隔離特定工作負載或確保某些 Pod 僅在特定節點上運行的場景。

3）利用 Pod 親和性和反親和性規則，可以確保Pod之間保持或避免特定的部署關系，以滿足業務的性能需求或高可用性要求。

4）Node Affinity 規則允許基于節點的標簽來影響調度決策，實現更復雜的節點選擇邏輯，比如確保特定應用的 Pod 運行在具有特定硬件或軟件配置的節點上。

Q19：針對一個具體的微服務架構，設計并解釋如何實施服務網格以實現金絲雀發布、故障注入和安全策略？

在設計針對微服務架構的服務網格實施時，我們就以 Istio 為例來規劃如何實現金絲雀發布、故障注入以及安全策略，以提升服務的穩定性和安全性。

金絲雀發布：通過 Istio 的?VirtualService?與?DestinationRule?配置，輕松劃分服務版本（如v1生產與v2金絲雀），并利用流量權重逐步分配用戶到新版本，實現無感迭代。過程中，借助 Istio 的監控能力密切觀察金絲雀版本性能，確保穩定后再逐步擴大新版本流量，或在問題出現時快速回滾，保證服務連續性。

故障注入：利用 Istio 的 HTTP FaultInjection 功能，在?VirtualService?中配置模擬延遲、超時等故障場景，無需修改服務代碼即可測試系統韌性。這有助于識別并優化服務的容錯邏輯和恢復策略，增強整體系統的穩定性和故障恢復能力。

安全策略：啟用 Istio 的自動 mTLS，實現服務間通信的加密，保障數據傳輸安全。結合?AuthorizationPolicy，精確定義訪問控制規則，確保只有授權的服務或命名空間才能訪問敏感資源，同時利用 Istio 的審計與監控能力，持續監督安全態勢，即時響應潛在威脅。

Q20：Kubernetes 安全策略防護是確保集群穩定性和數據安全的基石，請基于你的工作來談一談在這方面的經驗？

分為幾個層面吧，大家不一定全部答出，按照我說的幾個場景進行記憶下：

訪問控制與身份驗證（RBAC）：

最小權限原則：每個服務賬戶、用戶或系統組件僅被賦予完成其功能所需的最小權限。通過仔細設計Role和RoleBindings，確保不會有過剩的訪問權限。
雙因素認證：對于敏感操作或管理界面訪問，強制實施雙因素認證，以增強身份驗證的可靠性。

網絡策略：

微隔離：使用 Network Policies 實施嚴格的網絡隔離策略，確保服務間僅開放必要的通信通道，減少攻擊面。
服務網格安全：集成 Istio 等服務網格，提供更細粒度的流量控制和安全策略，如 TLS 加密、訪問控制列表（ACL）和端到端加密。

容器安全與運行時保護：

鏡像掃描與簽名：確保使用前所有容器鏡像經過安全掃描，并且要求所有鏡像從信任的注冊表拉取且帶有簽名，以防篡改。
運行時監控：部署運行時安全工具，如 Falco 或 Aqua Security，監控異常行為，如逃逸企圖、非法網絡訪問等。
安全上下文：配置 Pod Security Policies 或使用 PodSecurity Admission Controller 來限制容器特權，使用非 root 用戶運行容器，限制資源使用，以及應用AppArmor或SELinux策略。

密鑰與配置管理：

密鑰管理系統：集成Vault或KMS服務，用于存儲和管理敏感信息，如數據庫憑據、API密鑰等，確保密鑰的生命周期管理及安全傳遞。
動態密鑰注入：利用Kubernetes Secrets或外部密鑰管理系統，在Pod啟動時動態注入敏感信息，避免明文存儲。

審計與監控：

日志與審計：充分利用 Kubernetes 審計日志，跟蹤和分析所有 API 活動，及時發現異常行為。
持續監控：集成 Prometheus 和 Grafana 等工具，監控集群資源使用、網絡流量及應用性能，結合日志分析，快速定位并響應安全事件。

策略與合規：

合規性檢查：定期執行自動化合規性掃描，如使用 Open Policy Agent (OPA) 和 Gatekeeper，確保集群配置符合組織安全策略和行業標準（如 PCI-DSS、GDPR）。
安全意識培訓：提升團隊的安全意識，定期培訓開發和運維人員關于最新安全威脅和最佳實踐，確保每個人都了解他們在安全防護中的角色和責任。