在練氣初期，靈氣還比較稀薄，只能勉強在體內運轉幾個周天。

簡述k8s靜態pod

1. 定義

   • 靜態Pod是一種特殊類型的Pod，它是由kubelet直接管理的，不需要通過Kubernetes的控制平面（如API Server）進行創建和調度。這意味著它的生命周期獨立于Kubernetes的常規Pod管理機制。通常情況下，它是通過在節點上的特定目錄（配置文件路徑）中定義配置文件來創建的，kubelet會定期檢查這個目錄，一旦發現有新的Pod配置文件或者配置文件發生變化，就會根據這些文件來創建、更新或者刪除靜態Pod。

2. 配置方式

   • 文件路徑：在Kubernetes集群中，kubelet會在特定的目錄下查找靜態Pod的配置文件，這個目錄通常是/etc/kubernetes/manifests（具體路徑可以在kubelet的配置參數中修改）。例如，如果你想在一個節點上創建一個靜態Pod，你可以將Pod的YAML配置文件放置在這個目錄下。
   • 配置文件內容：靜態Pod的配置文件格式與普通Pod的YAML配置文件格式相同。它包含了Pod的基本信息，如apiVersion、kind、metadata（包括Pod的名稱、標簽等）和spec（包括容器的相關信息，如容器的名稱、鏡像、端口等）。例如：

   apiVersion: v1
   kind: Pod
   metadata:name: static - pod - examplelabels:app: static - pod - app
   spec:containers:- name: static - pod - containerimage: my - imageports:- containerPort: 8080
   

3. 與普通Pod的區別

   • 管理方式：
     • 普通Pod：由Kubernetes的控制平面（主要是API Server、Scheduler和Controller Manager等組件）進行管理。當你通過kubectl create -f pod - yaml這樣的命令創建一個普通Pod時，請求會發送到API Server，然后經過Scheduler調度到合適的節點上，Controller Manager會監控Pod的狀態并確保其符合期望狀態。
     • 靜態Pod：由kubelet直接管理。它繞過了Kubernetes的調度器和其他控制平面組件，直接在所在節點創建和運行。例如，在一些特殊場景下，如需要在節點上運行一個對Kubernetes控制平面有依賴的工具容器，使用靜態Pod可以確保它在節點上穩定運行，不受控制平面組件故障的影響。
   • 生命周期：
     • 普通Pod：其生命周期受Kubernetes的多種控制器（如Deployment、ReplicationController等）的影響。例如，當你刪除一個Deployment時，它所管理的所有Pod也會被刪除；當通過Deployment進行Pod的滾動更新時，舊版本的Pod會被逐步替換。
     • 靜態Pod：生命周期相對簡單，主要由kubelet和其配置文件決定。如果配置文件被刪除，對應的靜態Pod也會被刪除；如果配置文件內容發生變化，kubelet會根據新的配置更新靜態Pod。

4. 使用場景

   • 運行系統級組件：用于在Kubernetes集群的節點上運行一些系統級的關鍵組件，如kube - proxy、kube - DNS等。這些組件對于集群的正常運行非常重要，使用靜態Pod可以確保它們在節點上可靠地啟動和運行，不受集群控制平面可能出現的故障影響。
   • 特殊的監控或管理工具：當需要在節點上運行一些特殊的監控工具或者管理工具容器時，靜態Pod是一個很好的選擇。例如，一個用于收集節點硬件信息的監控容器，將其作為靜態Pod運行可以保證它在節點上持續運行，并且可以通過自定義的配置文件來靈活調整其運行參數。

---

為 Kubernetes 集群移除新節點：

一、準備工作

1. 節點狀態確認：
   • 在移除節點之前，需要確保該節點的當前狀態。可以使用 kubectl get nodes 命令查看節點的狀態。
   • 確認節點是否處于 Ready 狀態或其他狀態，例如，如果節點處于 NotReady 狀態，可能需要先解決該節點的問題或確保該狀態不會影響節點的移除操作。
   • 同時，檢查該節點上是否有正在運行的重要 Pod，因為移除節點可能會影響這些 Pod 的運行。例如，如果該節點上運行著一些關鍵業務的 Pod，需要考慮將這些 Pod 遷移到其他節點，以避免服務中斷。

二、驅逐節點上的 Pod

1. 使用 kubectl drain 命令：
   • 為了確保節點上的 Pod 被安全地遷移到其他節點，可以使用 kubectl drain <node-name> 命令。
   • 該命令會將節點標記為不可調度（unschedulable），并將節點上的 Pod 驅逐到其他可用節點上。
   • 例如：

   kubectl drain node1
   

   • 這個命令會嘗試將 node1 上的所有 Pod 驅逐，同時會遵循 Pod 的 PodDisruptionBudgets（如果有的話），確保服務的可用性和可靠性。
   • 注意：如果節點上存在一些 DaemonSet 管理的 Pod 或者一些無法驅逐的 Pod（例如，被本地存儲卷綁定的 Pod），命令會給出相應的警告或錯誤信息。對于這些情況，可能需要手動處理，如手動刪除 DaemonSet 或處理本地存儲卷的綁定問題。

三、節點移除操作

1. 使用 kubectl delete node 命令：

   • 一旦節點上的 Pod 被安全驅逐，就可以使用 kubectl delete node <node-name> 命令從集群中刪除該節點。
   • 例如：

   kubectl delete node node1
   

   • 此命令會將節點從 Kubernetes 的 API 服務器中刪除，但不會對節點的物理機器或虛擬機進行任何操作，只是從集群的管理層面移除節點信息。
   • 該命令會刪除節點的元數據、標簽、注解等信息，使其不再出現在 kubectl get nodes 的列表中。

2. 在節點上清理 K8s 組件（可選）：

   • 從集群中刪除節點后，可以選擇在節點上清理 K8s 組件，包括 kubelet、kube-proxy 等。
   • 對于使用 kubeadm 安裝的節點，可以使用 kubeadm reset 命令來清理節點上的 K8s 配置和狀態。例如：

   kubeadm reset
   

   • 此命令會移除 kubelet 的配置文件、證書、存儲在節點上的 etcd 數據（如果有），并停止 kubelet 和 kube-proxy 服務，將節點恢復到未加入集群的狀態。
   • 對于使用其他安裝工具或手動安裝的節點，需要手動停止相應的服務，如 systemctl stop kubelet 和 systemctl stop kube-proxy，并刪除相應的配置文件和數據目錄。

四、驗證和后續處理

1. 驗證節點移除結果：
   • 再次使用 kubectl get nodes 命令，確認節點已不在節點列表中。
   • 同時，可以檢查其他節點上是否成功接納了從移除節點遷移過來的 Pod，使用 kubectl get pods -o wide 查看 Pod 的分布情況，確保沒有 Pod 處于異常狀態。
   • 例如，如果節點 node1 被移除，檢查其他節點上的 Pod 數量是否增加，以及它們的狀態是否正常。
2. 網絡和存儲清理（可能需要）：
   • 對于使用網絡插件（如 Calico、Flannel 等）的集群，可能需要清理節點在網絡方面的殘留信息，以避免網絡異常。
   • 對于使用了持久卷（PV）和持久卷聲明（PVC）且與移除節點相關的情況，需要檢查存儲的使用情況，確保存儲資源的合理分配和重新利用。
   • 例如，如果節點上的 Pod 使用了 NFS 存儲，需要確保 NFS 服務器端的存儲資源沒有被異常占用或鎖定。

在移除 K8s 集群中的節點時，要遵循安全、有序的步驟，確保對節點上的 Pod 進行合理的處理，避免對業務造成不必要的影響，同時要進行后續的清理和驗證工作，以保證集群的正常運行和資源的合理利用。

請注意，在執行這些操作時，務必謹慎操作，根據實際的集群環境和業務需求調整操作步驟，避免因誤操作導致服務中斷或數據丟失等問題。

---

為 K8s 集群添加新節點

一、前置條件檢查

1. 硬件和軟件要求：
   • 硬件資源：
     • 確保新節點具備足夠的 CPU、內存和存儲資源，以滿足容器和應用程序的運行需求。一般來說，需要根據集群中預期運行的工作負載來評估，避免資源不足影響性能或穩定性。
     • 例如，對于運行多個微服務的集群，新節點至少應具有 2 核 CPU、4GB 內存和一定的磁盤空間，并且要考慮后續的擴容需求。
   • 操作系統兼容性：
     • 新節點應運行支持的操作系統，通常是主流的 Linux 發行版，如 Ubuntu、CentOS、Debian 等。同時，要確保操作系統版本在 K8s 支持的范圍內。
     • 比如，對于某些 K8s 版本，可能要求使用 Ubuntu 18.04 或更高版本，以避免因操作系統不兼容導致的問題。
   • 網絡連通性：
     • 新節點必須能夠與現有集群節點進行網絡通信，包括 TCP/IP 通信和 UDP 通信（部分組件可能需要）。
     • 確保沒有防火墻或網絡策略阻止 K8s 組件之間的通信，如 API Server 的 6443 端口、etcd 的 2379 端口等。

二、容器運行時安裝與配置

1. 選擇容器運行時：
   • 常見容器運行時：
     • Docker：曾經是最常用的容器運行時，但在較新的 K8s 版本中，K8s 更推薦使用 containerd 或 CRI-O。不過 Docker 仍然可用。
     • containerd：輕量級容器運行時，是 Docker 的核心組件，可獨立使用。在 K8s 中使用 containerd 可以提高性能和資源利用率。
     • CRI-O：專門為 K8s 設計的容器運行時，遵循 CRI（Container Runtime Interface）規范，提供更精簡的容器運行環境。
   • 安裝步驟示例（containerd）：
     • 首先添加容器運行時的軟件源，對于 Ubuntu 可以使用 apt 或對于 CentOS 可以使用 yum 進行添加。
     • 然后使用相應的包管理工具安裝 containerd 包，如 sudo apt-get install containerd。
     • 配置 containerd，通常需要修改 /etc/containerd/config.toml 文件，設置鏡像倉庫、存儲驅動等。例如，配置鏡像倉庫為 Docker Hub 或其他私有倉庫，設置存儲驅動為 overlayfs 等。

三、K8s 組件安裝與配置

1. kubelet 安裝與配置：

   • 安裝 kubelet：
     • 從 K8s 官方的軟件源下載 kubelet 包，根據操作系統使用相應的包管理工具進行安裝。
     • 例如，對于 Ubuntu 可以使用 sudo apt-get install kubelet 進行安裝。
   • 配置 kubelet：
     • 設置 kubelet 的啟動參數，主要包括 --kubeconfig（指定 K8s 集群的配置文件路徑）、--node-ip（新節點的 IP 地址）等。
     • 配置文件通常位于 /var/lib/kubelet/config.yaml，可設置資源預留、容器日志目錄、Pod 目錄等信息。
     • 例如，設置資源預留參數，確保系統有足夠的資源留給 K8s 組件和操作系統本身，避免資源競爭。

2. kube-proxy 安裝與配置：

   • 安裝 kube-proxy：
     • 與 kubelet 類似，從官方軟件源安裝 kube-proxy 包，如 sudo apt-get install kube-proxy。
     • kube-proxy 負責將服務請求轉發到相應的 Pod，是實現服務發現和負載均衡的重要組件。
   • 配置 kube-proxy：
     • 可以使用配置文件（如 /var/lib/kube-proxy/config.conf）設置模式（如 iptables 或 ipvs）、集群的 CIDR 等。
     • 不同的模式有不同的性能和特點，可根據集群規模和性能需求選擇，如在大規模集群中，ipvs 模式可能性能更優。

四、加入集群

1. 生成加入命令：
   • 在現有集群的主節點上，使用 kubeadm token create --print-join-command 生成新節點加入集群的命令。
   • 此命令包含認證信息（如 token）、CA 證書哈希和 API Server 的地址，確保新節點能安全加入集群。
   • 例如，生成的命令可能是 kubeadm join 192.168.1.100:6443 --token <token> --discovery-token-ca-cert-hash <hash>。
2. 執行加入命令：
   • 在新節點上執行上述生成的加入命令，將新節點添加到集群。
   • 執行過程中，新節點會與主節點通信，下載集群信息、證書和配置文件，進行身份驗證，并注冊自己為集群的一部分。
   • 例如，通過 sudo sh -c '<join_command>' 執行加入命令。

五、驗證與調試

1. 節點狀態檢查：
   • 在主節點上使用 kubectl get nodes 查看新節點是否已成功加入。
   • 新節點的狀態開始可能是 NotReady，等待一段時間后應變為 Ready，表明新節點已準備好接收和運行 Pod。
   • 例如，運行 kubectl get nodes 會顯示節點列表，其中包括新節點的信息和狀態。
2. 日志檢查：
   • 若新節點未正常變為 Ready，可查看 kubelet 和 kube-proxy 的日志，找出問題所在。
   • 可以使用 journalctl -u kubelet 和 journalctl -u kube-proxy 查看相應的日志信息。
   • 日志可以顯示錯誤信息，如證書驗證失敗、網絡連接問題、資源不足等，根據日志內容進行相應的修復。
3. 功能測試：
   • 在新節點上部署一個簡單的測試 Pod，檢查是否能正常運行。
   • 例如，使用 kubectl run test-pod --image=nginx --restart=Never 創建一個臨時的 Nginx 容器，然后使用 kubectl describe pod test-pod 查看其運行狀態，確保它能正常啟動和運行。

添加新節點是擴展 K8s 集群規模和提高集群性能的重要操作，需要全面考慮硬件、軟件、網絡等多個方面的因素，確保每個步驟正確執行，并通過檢查和測試保證新節點能正常融入集群，為集群的整體運行貢獻力量。

Kubernetes 中 Pod 的調度流程

一、Pod 調度的基本流程概述

當用戶通過 kubectl create 或通過 API 創建一個 Pod 時，Kubernetes 會觸發調度流程，以確定將 Pod 分配到哪個節點上運行。這個過程涉及多個組件的協同工作，主要包括 API Server、Scheduler 和 Kubelet，它們共同確保 Pod 在合適的節點上啟動和運行。

二、調度流程詳細步驟

1. Pod 創建和 API Server 接收：

   • 當用戶創建一個 Pod 時，無論是通過 YAML 文件還是其他方式，請求會被發送到 API Server。
   • API Server 是 Kubernetes 集群的控制平面組件，它會驗證 Pod 的配置是否合法，并將其存儲在 etcd 中。
   • 總結：API Server 作為入口，負責接收和驗證 Pod 請求，將 Pod 信息存儲到 etcd 中，為后續的調度和管理提供數據基礎。

2. 調度器監聽 Pod 事件：

   • Scheduler 會持續監聽 API Server 上的 Pod 事件。一旦發現有新的未調度的 Pod（即沒有指定 nodeName 屬性的 Pod），它會將該 Pod 納入調度隊列。
   • Scheduler 會根據一系列的調度算法和策略來為 Pod 選擇合適的節點。這些算法和策略考慮了多種因素，包括節點的資源（如 CPU、內存）、節點的標簽、節點的親和性/反親和性、污點和容忍度等。
   • 總結：Scheduler 不斷監控 API Server 中未調度的 Pod，根據多種因素來為它們尋找合適的節點，其核心任務是做出最優的節點選擇。

3. 節點篩選和評分：

   • 篩選階段：
     • Scheduler 首先會根據 Pod 的要求和節點的屬性進行篩選。例如，如果 Pod 要求一定的 CPU 和內存資源，那些資源不足的節點會被排除。同時，它會考慮節點的標簽、污點和容忍度等因素。
     • 節點的親和性/反親和性也會影響篩選過程，例如，如果 Pod 要求運行在有特定標簽的節點上，只有滿足這些標簽的節點會被保留。
     • 總結：通過對節點的各項屬性進行篩選，排除不符合 Pod 要求的節點，縮小選擇范圍。
   • 評分階段：
     • 對于通過篩選的節點，Scheduler 會根據一些指標對它們進行評分。這些指標可以包括節點的資源可用性、資源分配的均勻性、節點上已有的負載等。
     • 不同的調度算法可能會采用不同的評分方式，例如，有些算法會優先考慮負載均衡，有些會優先考慮資源使用效率等。
     • 總結：對通過篩選的節點進行評分，以便選出最適合 Pod 運行的節點，不同的調度算法有不同的評分依據。

4. 最終決策和綁定：

   • Scheduler 根據評分結果，選擇得分最高的節點作為最終的目標節點。
   • 然后，Scheduler 會將 Pod 與選定的節點進行綁定，通過更新 Pod 的 nodeName 屬性將這一信息存儲在 API Server 中，最終通過 API Server 持久化到 etcd 中。
   • 總結：根據評分選出最佳節點，將 Pod 與該節點綁定，更新信息并存儲，完成調度的核心決策。

5. Kubelet 啟動 Pod：

   • Kubelet 是運行在每個節點上的組件，它會持續監控 API Server 中分配到本節點的 Pod。
   • 當 Kubelet 發現有新的 Pod 被調度到自己所在的節點時，它會根據 Pod 的配置信息來啟動容器。這包括拉取容器鏡像、創建容器所需的存儲卷、設置網絡等操作。
   • 總結：Kubelet 負責接收分配到本節點的 Pod 任務，并執行實際的容器啟動操作，將調度決策轉化為實際的容器運行。

三、重要的調度策略和機制

1. 資源請求和限制：

   • 在 Pod 的配置中，可以指定資源請求（requests）和資源限制（limits）。
   • 資源請求會影響調度決策，確保節點有足夠的資源來滿足 Pod 的基本運行需求；資源限制則是對容器使用資源的上限約束，防止過度使用資源。
   • 總結：資源請求和限制是調度的重要依據，影響節點篩選和評分，同時保證了資源的合理分配和使用。

2. 親和性和反親和性：

   • 節點親和性允許用戶將 Pod 調度到滿足特定條件的節點，如具有特定標簽的節點。
   • 反親和性可以防止 Pod 過于集中在某些節點，實現分布的均衡或滿足高可用需求。
   • 總結：親和性和反親和性是靈活的調度工具，可實現精確的節點選擇和負載均衡，提高集群的可靠性和性能。

3. 污點和容忍度：

   • 節點可以設置污點，以排斥某些 Pod。
   • Pod 可以設置容忍度，容忍特定的污點，從而能夠在有污點的節點上運行。
   • 總結：污點和容忍度機制允許對節點的使用進行精細化管理，控制哪些 Pod 可以在哪些節點上運行，提高集群資源的調配靈活性。

4. 調度器擴展：

   • 用戶可以編寫自定義的調度算法，實現更復雜的調度需求。
   • 通過實現 Scheduler Extender 接口，可以將自定義算法集成到 Scheduler 中。
   • 總結：支持調度器擴展，以滿足特殊的業務或性能要求，增加了調度的靈活性和定制性。

Kubernetes 的 Pod 調度是一個復雜而精細的過程，涉及多個組件和多種策略，從 Pod 的創建、API Server 的接收，到 Scheduler 的篩選、評分和決策，再到 Kubelet 的執行，以及重要的調度策略和機制的協同工作，確保了 Pod 在集群中高效、合理地分配和運行。這些機制相互配合，保證了集群資源的優化利用和服務的穩定運行。