Kubernetes 整合 LimitRange 與 Dashboard 的應用

– 8 分鐘閱讀

在 Kubernetes 環境中，精確的資源管理和全面的監控體系至關重要。本文將探討如何利用 LimitRange 限制資源使用，並結合 Kubernetes Dashboard、Metrics Server、Prometheus 和 Grafana 等工具，建構強大的監控系統，確保應用程式穩定執行。

LimitRange：預先設定資源限制，避免資源濫用

LimitRange 是一種 Kubernetes 內建的資源管理工具，允許管理員預先定義 Pod 和容器的資源使用限制，有效防止資源濫用，確保叢集穩定性。

要使用 LimitRange，首先需確認 LimitRanger admission controller 已啟用。透過以下指令檢查 kube-apiserver 的啟動引數：

ps aux | grep kube-api

確認 --enable-admission-plugins 中包含 LimitRanger。LimitRanger 支援設定資源的預設值、最小值和最大值，適用於 Pod、容器和 PersistentVolumeClaim 等物件。

以下範例示範如何在 demo 名稱空間中設定 LimitRange：

  1. 建立名稱空間：
kubectl create namespace demo
  1. 定義 LimitRange：
apiVersion: v1
kind: LimitRange
metadata:
  name: resource-limits
  namespace: demo
spec:
  limits:
  - type: Container
    max:
      memory: 512Mi
      cpu: 500m
    min:
      memory: 50Mi
      cpu: 50m
    default:
      memory: 256Mi
      cpu: 250m
    defaultRequest:
      memory: 128Mi
      cpu: 100m

以上 YAML 檔案定義了一個名為 resource-limits 的 LimitRange，設定了容器資源的最小、最大和預設值，以及預設請求值。這確保了名稱空間內所有容器的資源使用都在預設範圍內，防止資源被過度分配或不足。

  1. 驗證 LimitRange：
kubectl get limitrange -n demo

嘗試建立一個超出限制的 Pod 將會失敗，確保資源限制有效執行。

  graph LR
    A[建立 Pod 請求] --> B{LimitRange 驗證};
    B -- 符合限制 --> C[Pod 建立成功];
    B -- 超出限制 --> D[Pod 建立失敗];

此流程圖展示了 LimitRange 如何驗證 Pod 建立請求。當請求符合定義的資源限制時，Pod 建立成功；反之，則建立失敗。

Kubernetes 資源監控：Dashboard 與 Metrics Server

Kubernetes 提供了多種監控工具，其中 Kubernetes Dashboard 和 Metrics Server 是最常用的內建工具。

Kubernetes Dashboard：視覺化叢集管理

Dashboard 提供了一個 Web UI，方便管理和監控叢集資源。然而，安全性設定至關重要。以下是一些安全強化措施：

  • 根據角色的存取控制 (RBAC): 精細控制使用者許可權，避免非授權存取。
  • HTTPS 安全通道: 使用 TLS 加密，確保資料傳輸安全。
  • Token 驗證: 使用服務帳戶和 Token 進行驗證，避免使用基本驗證。
  • 網路策略: 限制 Dashboard 的網路存取，例如僅允許內部網路存取。

透過以下步驟，您可以安全地使用服務帳戶存取 Dashboard：

  1. 建立服務帳戶：
kubectl create serviceaccount dashboard-admin -n kubernetes-dashboard
  1. 授予叢集管理員角色（僅供測試環境，生產環境應使用更精細的許可權控制）：
kubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kubernetes-dashboard:dashboard-admin
  1. 取得 Token：
kubectl -n kubernetes-dashboard describe secret $(kubectl -n kubernetes-dashboard get secret | grep dashboard-admin | awk '{print $1}')

以上指令首先建立一個名為 dashboard-admin 的服務帳戶，然後授予其叢集管理員角色，最後取得 Token。在生產環境中，應根據實際需求授予最小必要許可權。

Metrics Server：資源用量資料收集

Metrics Server 負責收集叢集資源使用資料，提供給 HPA 和 VPA 使用，也支援 kubectl top 指令。

在 Minikube 中，使用以下指令啟用 Metrics Server：

minikube addons enable metrics-server

驗證 Metrics Server 是否已啟用：

kubectl get apiservices | grep metrics

使用 kubectl top 檢視節點和 Pod 的資源用量：

kubectl top node
kubectl top pod

這些指令用於啟用、驗證 Metrics Server，並使用 kubectl top 檢視資源用量。

Prometheus 與 Grafana：建構進階監控系統

Prometheus 和 Grafana 的組合提供更強大的監控和視覺化能力。Prometheus 透過 pull 模式收集指標資料，Grafana 則提供友善的介面展示資料。

設定 Prometheus 監控 Kubernetes 叢集的簡要步驟如下：

  1. 佈署 Prometheus 和 Grafana。
  2. 設定 Prometheus 的 scrape target，指定要監控的 Kubernetes 物件。
  3. 在 Grafana 中設定資料來源，連線到 Prometheus。
  4. 建立 Grafana Dashboard，視覺化 Prometheus 資料。
  graph LR
    D[D]
    A[Prometheus] --> B(Kubernetes Metrics);
    C[Grafana] --> B;
    B --> D{視覺化與告警};

此圖展示了 Prometheus 和 Grafana 如何協同工作，從 Kubernetes 收集指標資料，並在 Grafana 中進行視覺化和告警。

透過以上工具和技術，您可以建構全面的 Kubernetes 資源管理和監控體系，有效提升叢集資源利用率和應用程式穩定性。

透過以上方法，您可以有效地管理和監控 Kubernetes 叢集資源，確保應用程式穩定執行。從資源限制到視覺化監控，每一步都至關重要。

開發堅不可摧的 Kubernetes 堡壘：高用性架構深度解析

在瞬息萬變的雲原生時代，應用程式的高用性如同生命線，而 Kubernetes 正是構建這條生命線的根本。我將從工作負載、Kubernetes 核心元件和雲端基礎設施三個層面，深入剖析如何在 Kubernetes 叢集中開發高用性架構，並分享我在實務中的一些心得體會。

Kubernetes 工作負載的高用性設計

Kubernetes 提供了多種佈署工作負載的利器，像是 Deployment 和 StatefulSet，允許我們透過 replicas 引數來指定執行服務的 Pod 副本數量。Kubernetes 的控制器機制會確保在叢集的不同節點上執行指定數量的 Pod，避免單點故障。DaemonSet 則是一種特殊的工作負載，它會在叢集的每個節點上都執行一個 Pod，適用於監控、日誌收集等場景。

  graph LR
    A[Deployment Controller] --> B(Pod 1);
    A --> C(Pod 2);
    A --> D(Pod 3);
    subgraph "Worker Nodes"
        B;
        C;
        D;
    end

上圖展現了 Deployment 如何在多個工作節點上佈署 Pod 副本，實作負載平衡和容錯移轉。即使其中一個節點或 Pod 發生故障，服務仍然可以繼續執行，確保高用性。

除了副本機制，Liveness Probe 和 Readiness Probe 也是維護工作負載高用性的關鍵。Liveness Probe 定期檢查 Pod 的健康狀態，如果 Pod 失效，Kubernetes 會自動重新啟動 Pod。Readiness Probe 則用於判斷 Pod 是否準備好接收流量，只有透過 Readiness Probe 的 Pod 才會被加入到 Service 的後端 Endpoint 列表中。

  graph LR
    B[B]
    Not[Not]
    Ready[Ready]
    A[Request] --> B{Service};
    B -- Ready --> C(Pod 1);
    B -- Not Ready --> D(Pod 2);
    subgraph "Worker Nodes"
        C;
        D;
    end

上圖説明瞭 Readiness Probe 如何確保只有準備好的 Pod 才能接收流量。如果 Pod 2 沒有透過 Readiness Probe，Service 就會將流量導向 Pod 1，避免將流量傳送到未準備好的 Pod，從而提高服務的可用性。

Kubernetes 核心元件的高用性佈署

Kubernetes 核心元件，例如 kube-apiserver、kube-controller-manager 和 kube-scheduler，是維持叢集正常運作的關鍵。為了確保高用性，這些元件通常以多副本的方式佈署。

以 kube-apiserver 為例，可以透過佈署多個 kube-apiserver 例項，並使用負載平衡器將流量分發到不同的例項上，實作高用性。etcd 儲存著 Kubernetes 叢集的狀態資訊，也需要以叢集模式佈署，確保資料的可靠性和高用性。

  graph LR
    A[Load Balancer] --> B(kube-apiserver 1);
    A --> C(kube-apiserver 2);
    B --> D[etcd Cluster];
    C --> D;

上圖展示了 kube-apiserver 的高用性佈署架構。負載平衡器將流量分發到多個 kube-apiserver 例項，而 etcd 叢集則確保了叢集狀態資訊的可靠性。

雲端基礎設施的高用性保障

雲端基礎設施是 Kubernetes 叢集的根本，其高用性直接影響著叢集的穩定性。選擇具有多可用區或多區域支援的雲端供應商，並將 Kubernetes 節點分散到不同的可用區或區域，可以有效地避免單點故障。

此外，組態自動擴充套件組可以根據負載情況自動調整節點數量，確保叢集在高峰期也能夠穩定執行。監控系統和告警機制也是不可或缺的，可以幫助我們及時發現和處理基礎設施層面的問題。

透過結合以上三個層面的高用性策略，我們可以構建一個堅實可靠的 Kubernetes 叢集，為應用程式提供穩定的執行環境。在實踐過程中，我發現預先規劃和測試至關重要，可以幫助我們及早發現和解決潛在問題，避免在生產環境中造成不必要的損失。

確保 Kubernetes 叢集穩定的關鍵：元件高用性探討

在 Kubernetes 叢集中，元件的高用性是維持系統穩定運作的根本。本文將探討幾個關鍵元件，並闡述如何確保它們在各種情況下都能正常運作。

Kubernetes 控制平面核心：API 伺服器 (kube-apiserver)

kube-apiserver 作為 Kubernetes 控制平面的核心，扮演著至關重要的角色。它負責處理所有來自使用者和系統內部元件的 REST 請求，並對 Pod、服務、控制器等物件的資料進行驗證和組態。一旦 kube-apiserver 停機，整個叢集將陷入癱瘓，因為所有操作都依賴於與它的通訊。

叢集狀態的守護者：etcd

etcd 是一個分散式鍵值儲存，負責儲存 Kubernetes 叢集的組態、狀態和中繼資料。它的高用性設計確保了資料的安全性和一致性。etcd 的 watch 功能讓 Kubernetes 能夠即時監聽組態的變化，並動態調整叢集狀態。如果 etcd 停機，叢集將失去狀態資訊，無法正常運作。

Pod 的最佳排程員：kube-scheduler

kube-scheduler 負責將新建立的 Pod 分配到最合適的節點上。它會根據節點的資源使用情況、Pod 的需求以及其他約束條件，做出最佳的排程決策。kube-scheduler 的正常運作確保了工作負載的有效分配和資源利用。

叢集狀態的維護者：kube-controller-manager

kube-controller-manager 包含多個核心控制器，它們持續監控叢集狀態，並根據預先定義的規則進行調整。例如，如果一個 Pod 失敗，控制器管理器會自動啟動一個新的 Pod 來替代它。kube-controller-manager 的穩定執行對於維持叢集的自我修復能力至關重要。

  graph LR
    subgraph Master節點
        APIServer1[API 伺服器 1] --> Etcd
        APIServer2[API 伺服器 2] --> Etcd
        APIServer3[API 伺服器 3] --> Etcd
        Controller1[控制器管理器 1]
        Controller2[控制器管理器 2]
        Controller3[控制器管理器 3]
        Scheduler1[排程器 1]
        Scheduler2[排程器 2]
        Scheduler3[排程器 3]
    end
    Etcd[etcd 叢集]

上圖展現了一個高用性的 Kubernetes 控制平面架構。API 伺服器、控制器管理器和排程器都以多副本的方式佈署，確保即使個別元件失效，整個系統也能繼續運作。所有元件都連線到一個高用性的 etcd 叢集，用於儲存和同步叢集狀態資訊。透過這種架構， Kubernetes 叢集能夠在各種情況下保持穩定和可靠。

要確認這些元件的執行狀態，可以使用 kubectl get pods -n kube-system 命令。這個命令會列出 kube-system 名稱空間下的所有 Pod，包括 kube-apiserver、etcd、kube-scheduler 和 kube-controller-manager。 透過觀察它們的狀態和所在節點，可以確認高用性組態是否生效。

透過佈署多個主節點和合理的資源組態，可以有效提升 Kubernetes 叢集的容錯能力和穩定性，確保業務的持續執行。 選擇合適的高用性策略，需要根據實際業務需求和叢集規模進行調整。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。