料想不到部落格(unexpected blog)

使用 kubeadm 進行 Cluster 升級與維護如何安全地升級和維護 Kubernetes ClusterKubernetes 的升級和維護對於保持 Cluster 的安全性和穩定性相當重要。使用 kubeadm 來管理 Kubernetes Cluster 的升級過程，可以幫助你順利進行版本更新。kubeadm 提供了一個相對簡單和可靠的方法來升級 Kubernetes 控制平面和節點，同時最大限度地減少對運行中工作負載的影響。以下是使用 kubeadm 進行 Kubernetes Cluster 升級和維護的詳細步驟。

使用 Kubernetes Dashboard 圖形介面管理Cluster介紹 Kubernetes DashboardKubernetes Dashboard 是一個基於 Web 的用戶界面，允許用戶直接在瀏覽器中管理和監控 Kubernetes Cluster。它提供了一個直觀的方式來查看 Cluster 的狀態、部署應用程式、排查問題以及管理資源。這使得即使是不熟悉命令行操作的用戶，也可以輕鬆地與 Kubernetes 進行互動。Kubernetes Dashboard 的功能Cluster概覽：查看整個 Kubernetes Cluster的健康狀況，包括節點的可用性、Pod 的狀態以及各種資源的使用情況。工作負載管理：創建、更新和刪除 Deployment、ReplicaSet、DaemonSet、StatefulSet 等 Kubernetes 資源，並監控它們的運行狀況。Pod 和容器管理：查看 Pod 的日誌，排查容器的啟動錯誤，進行故障排除和重啟操作。資源管理：管理 ConfigMaps、Secrets、PersistentVolumeClaims 等 Kubernetes 資源，輕鬆調整應用程式的設定和敏感資訊。應用部署：使用 YAML 檔案或 UI 中的表單部署應用程式，簡化應用程式的管理流程。

使用 Prometheus 與 Grafana 監控 Kubernetes關於 Prometheus 與 GrafanaPrometheus 和 Grafana 是當今 Kubernetes 生態系統中最常用的開源監控和可視化工具。Prometheus 用於收集和儲存來自各種來源的監控資料，而 Grafana 用於將這些資料可視化，幫助運維人員快速了解系統狀況。
下圖是 prometheus.io 所提供的架構圖：這張圖展示了 Prometheus 監控系統的整體架構，說明了各個組件之間的交互關係以及資料流的走向。
Prometheus Server 是系統的核心，負責資料檢索和儲存，而 Alertmanager 和 Grafana 則負責告警處理和資料可視化。這樣的架構確保了系統運維的可觀測性和自動化告警能力。Kube Prometheus StackKube Prometheus Stack 是一個集成的開源解決方案，專門用於在 Kubernetes Cluster 中實現全面的監控和告警管理。它包括 Prometheus、Grafana、Alertmanager 以及其他相關工具，通過 Prometheus Operator 來簡化這些組件的部署和運維管理。以下將詳細說明如何使用 Kube Prometheus Stack 來設定和管理 Kubernetes Cluster 的監控系統。

Network Policies：Kubernetes中的網路安全設定和管理網路策略在 Kubernetes 中，Network Policies 是一種強大的工具，用於控制和管理 Pod 之間的網路流量。它們允許你定義哪些 Pod 可以互相通訊，以及哪些 Pod 可以存取 Cluster 外部或從外部接收流量。通過適當設定網路策略，可以大幅增強 Kubernetes Cluster的安全性，防止未經授權的網路存取和內部攻擊。Network Policies 的基本概念

什麼是 Network Policies：

• Network Policies 是 Kubernetes 提供的一種資源，用於定義 Pod 之間的網路流量控制規則。它們作用於第 3 層（IP 層）和第 4 層（傳輸層），允許你指定允許哪些流量進入和離開 Pod。

網路外掛模組的支援：

• 要啟用和使用 Network Policies，Kubernetes Cluster 必須運行支援該功能的網路外掛模組（如 Calico、Weave、Cilium、Flannel 等）。這些外掛模組實現了網路策略的應用和執行。

策略作用範圍：

• Network Policies 只影響被選擇的 Pod（通過選擇標籤），並且預設情況下，Pod 之間的流量是允許的，除非有具體的 Network Policies 進行限制。

使用 RBAC 進行身份驗證和授權基於角色的存取控制的設定基於角色的存取控制（RBAC，Role-Based Access Control）是 Kubernetes 提供的一種存取控制機制，用於管理和控制對 Kubernetes 資源的存取。RBAC 允許你為用戶、群組或服務帳戶分配特定角色，從而限制它們在 Cluster 中可以執行的操作。這一天的課程將深入探討如何設定 RBAC 來進行身份驗證和授權，確保 Kubernetes Cluster 的安全性。RBAC 的基本概念

Role（角色）：

• 角色定義了用戶或服務帳戶可以對 Kubernetes 資源執行的操作。這些操作包括 CRUD（創建、讀取、更新、刪除）操作。
• 角色可以在命名空間範圍內生效（Role），也可以在整個 Cluster 範圍內生效（ClusterRole）。

RoleBinding（角色綁定）：

• 角色綁定將一個角色（Role 或 ClusterRole）與用戶、組或服務帳戶綁定，從而授予它們特定的權限。
• 角色綁定可以在命名空間內生效（RoleBinding），或在整個 Cluster 範圍內生效（ClusterRoleBinding）。

Subject（主體）：

• 主體是指將要授予權限的實體，可以是用戶（User）、群組（Group）或服務帳戶（ServiceAccount）。

Operators：自動化應用程式運維使用 Operators 進行應用程式的自動化管理Operators 是 Kubernetes 中的一種模式和工具，用於將人類運維工程師的知識撰寫為類似軟體套件，使得 Kubernetes 可以自動管理復雜的應用程式。Operators 不僅可以自動執行應用的部署和升級，還可以處理備份、恢復、故障轉移等更高級的運維任務。今天，我們將探討 Operators 的概念、其工作原理以及如何使用 Operators 來自動化應用程式的管理。Operators 的基本概念

什麼是 Operators：

• Operators 是一種 Kubernetes 的擴展，用於自動化運維任務。它們基於自定義資源（CRD, Custom Resource Definitions）和自定義控制器（Custom Controllers）構建，通過定義特定的狀態和行為，Operators 可以管理應用的完整生命周期。
• 與傳統的腳本或手動操作不同，Operators 以聲明性設定和事件驅動的方式來管理應用程式，這使得操作更加可靠和一致。

Operators 的核心組件：

• Custom Resource Definitions (CRDs)：CRDs 是 Kubernetes 中的一種擴展資源類型，允許使用者創建和管理自定義資源。Operators 使用 CRDs 來定義和管理應用程式的特定狀態。
• Controllers：控制器是運行在 Kubernetes Cluster中的一個循環進程，負責監控 CRD 的變化並執行相應的操作，以確保 Cluster 中的狀態符合預期。

Operators 的應用場景：

• 資料庫管理：例如，MySQL、PostgreSQL 等資料庫的 Operators 可以自動處理資料庫的備份、恢復、縮放、升級等任務。
• 分佈式系統管理：例如，Cassandra 或 Kafka 的 Operators 可以自動化節點擴展、故障節點恢復、組態調整等操作。
• 應用程式生命周期管理：Operators 可以管理應用的部署、升級、回滾、擴展、健康檢查等各個階段。

Operators 的流程圖例說明：

深入理解 Kubernetes 的調度器調度器的工作原理和自定義調度Kubernetes 調度器是 Kubernetes Cluster 的核心組件之一，負責將 Pod 調度到適合的節點上運行。調度器在 Pod 的生命周期中扮演著非常重要的角色，它決定了應用程式如何在 Cluster 中進行分佈，以確保資源利用最大化並滿足特定的部署需求。今天，我們將深入探討 Kubernetes 調度器的工作原理，並了解如何進行自定義調度。調度器的工作原理

調度器的基本概念：

• Kubernetes 調度器（Kube-scheduler）是一個獨立的服務，負責將尚未分配到節點的 Pod 分配到適合的節點上。
• 調度器會考慮多種因素來選擇最合適的節點，包括資源需求（CPU、RAM 等）、節點的健康狀態、Pod 的親和性/反親和性策略、節點的可用性區域等。

調度流程：

• Pending 階段：當 Pod 被創建後，Kubernetes API 服務器會將該 Pod 標記為 Pending 狀態，並將其放入調度隊列中等待調度。
• 節點篩選（Filtering）：調度器首先根據資源需求和其他硬性約束來篩選出能夠滿足 Pod 需求的節點。
• 節點打分（Scoring）：對於篩選出的節點，調度器會根據一系列打分算法對它們進行評分，評分最高的節點將被選擇來運行該 Pod。
• 綁定（Binding）：調度器將 Pod 綁定到選中的節點，這個過程使得該節點成為 Pod 的運行載體。

調度策略：

• 資源請求與限制：Pod 的資源請求和限制（如 CPU 和 RAM）是調度器選擇節點時考慮的主要因素之一。調度器會確保節點能夠滿足 Pod 的資源需求。
• 親和性與反親和性：調度器可以根據 Pod 和節點之間的親和性和反親和性策略來決定 Pod 的調度位置，這對於優化應用程式的性能和可靠性至關重要。
• 拓撲約束：調度器可以將 Pod 調度到不同的可用區或區域，以提高應用程式的高可用性和容災能力。

Pod的生命周期與調度策略理解 Pod 的各個階段和調度過程Kubernetes 中的 Pod 是應用程式運行的基本單位，了解 Pod 的生命周期和調度策略對於管理和運營 Kubernetes Cluster 相當重要。在這一天的課程中，我們將深入探討 Pod 的生命周期各個階段，並了解 Kubernetes 如何調度 Pod 到 Cluster 中的節點。Pod 的生命周期Pod 的生命周期分為多個階段，從創建到刪除，每個階段都表示 Pod 的不同狀態。這些階段主要包括：

Pending（等待中）：

• 當 Pod 被創建時，它會進入 Pending 階段。在這個階段，Kubernetes 正在為 Pod 分配所需的資源，例如 PersistentVolume 和網路設置。
• 如果 Pod 需要的資源（如 PersistentVolumeClaim）無法分配，Pod 可能會長時間停留在 Pending 階段。

ContainerCreating（容器創建中）：

• 在這個階段，Kubernetes 調度器（Scheduler）已經將 Pod 調度到某個節點上，並開始拉取容器鏡像，創建容器。
• 如果鏡像拉取速度較慢，或者節點資源不足，Pod 可能會停留在這個狀態。

Running（運行中）：

• 當所有的容器都成功啟動後，Pod 會進入 Running 狀態。在這個狀態下，Pod 正在正常運行並提供服務。
• 此時，Pod 可能處於初始化中（init containers 還在運行）或者已經完成初始化，正式進入穩定運行狀態。

Succeeded（成功）：

• 如果 Pod 中所有容器都正常終止且不需要重啟，Pod 會進入 Succeeded 狀態。這通常發生在處理完成一次性任務（如 Job）後。

Failed（失敗）：

• 當 Pod 中的某個容器因為失敗原因（如崩潰、超時等）終止並且無法重啟，Pod 會進入 Failed 狀態。

Unknown（未知）：

• 當 Kubernetes 無法與 Pod 進行通信時（例如，由於網路問題或節點宕機），Pod 會進入 Unknown 狀態。

Terminating（終止中）：

• 當 Pod 被刪除時，它會進入 Terminating 狀態，並進行清理工作，例如終止所有容器和釋放資源。

使用 Kustomize 進行 Kubernetes 設定管理Kustomize 的基本用法和設定Kustomize 是 Kubernetes 原生的組態管理工具，它允許你通過覆蓋組態檔案來靈活地管理和修改 Kubernetes 應用程式的 YAML 檔案，而不需要對原始組態進行複製和修改。Kustomize 使得在不同環境之間（如開發、測試、和正式環境）管理和部署應用程式更加簡單和一致。今天，我們將深入探討 Kustomize 的基本用法和設定。Kustomize 的基本概念

Kustomization：

• Kustomization 是 Kustomize 的核心概念，它定義了應用程式的資源、更新檔（Patches）、生成器（Generators）以及模型集（Transformers）。
• 通常 Kustomization 檔案的名稱是 kustomization.yaml，這個檔案描述了如何組合、覆蓋和生成 Kubernetes 資源。

Base 和 Overlay：

• Base：Base 是應用程式的基本組態，通常是通用的，可以應用於多個環境。
• Overlay：Overlay 是在 Base 基礎上進行的組態覆蓋，用於定義環境特定的組態。例如，你可以為開發、測試、和正式環境定義不同的 Overlay。

安裝 KustomizeKustomize 已經集成到 kubectl 中，可以直接使用 kubectl 來運行 Kustomize：

Kubernetes的套件管理工具 HelmHelm 是 Kubernetes 的套件管理工具，旨在簡化應用的部署、升級和管理過程。它透過 Chart 封裝應用程式，使得 Kubernetes 上的應用部署變得更加容易且可管理。Helm 的基本概念

Chart：
Chart 是 Helm 的封裝格式，類似於 Linux 的套件管理器（如 apt 或 yum）。它包含 Kubernetes 應用程式的所有必要資源，如 Deployment、Service、ConfigMap 等的 YAML 檔案範本。Chart 允許用戶定義應用程式的設定選項，這些選項可以根據不同的環境進行自定義。

Values：
Values 檔案提供了用戶自定義 Chart 中設定的途徑，使得同一個 Chart 可以根據開發、測試和正式環境的不同需求進行靈活設定。

Release：
Release 是基於 Chart 部署後的應用實例。每次使用 Helm 部署 Chart，都會創建一個唯一名稱的 Release，方便管理和追蹤應用版本。

Repository：
Chart Repository 是儲存和分發 Chart 的場所，類似於 Linux 的套件管理儲存庫。用戶可以從官方的 Helm Hub 或 Artifact Hub 等公共儲存庫中下載和安裝所需的 Chart。

Helm 的架構與組件Helm 由以下主要組件構成：

Helm CLI：這是用戶與 Helm 互動的命令列工具，負責 Chart 管理、Release 操作及與 Kubernetes API 進行通訊。

Tiller（Helm 2 中的架構）：在 Helm 2 中，Tiller 是運行在 Kubernetes Cluster中的伺服器端元件，負責管理 Release。需要注意的是，Helm 3 移除了 Tiller，改進了安全性並簡化了操作。

Chart Repository：這些是 Helm Chart 的集中存放地，類似於 Linux 的軟體儲存庫。