管理程序 ID 限制

總覽

程序 ID (PID) 限制是 Kubernetes 對節點和 Pod 的資源限制，可防止過度建立程序，進而影響節點穩定性。Apigee Hybrid 支援 Kubernetes 功能，可設定程序 ID 限制。本文將說明如何設定這些限制，並提供特定平台上 Apigee 服務的值建議。

Apigee 混合式使用者管理自己的叢集時，在 Kubernetes 中設定 PID 限制可改善系統穩定性、安全性和資源管理。這也符合 Kubernetes 最佳做法。

處理程序 ID 限制的定義

程序 ID 限制包括節點 PID 限制和 Pod PID 限制。

節點 PID 限制包括 Kube 保留的 PID 和系統保留的 PID。可分配 PID 的總數為核心上限數量減去 kube 保留的 PID 數量，再減去系統保留的 PID 數量，再減去淘汰閾值 PID 數量：

• 核心 ID 上限：取決於作業系統及其核心設定。由於 Apigee Hybrid 僅在 Linux 核心上執行，因此本指南將討論 Kubernetes 節點的 Linux 限制。Linux 核心的程序 ID 上限為 4194304。
• Kube 保留和系統保留：用於為 Kubernetes 或 OS 系統守護程式保留資源。
• 剔除門檻：用於表示節點壓力的限制值。達到閾值時，節點就會遭到淘汰。詳情請參閱「以 PID 為依據的淘汰機制」。
• 可分配：可用的 PID 數量。詳情請參閱「Kubernetes：Node Allocatable」。您可以使用 Node PID 限制設定來設定 Kube 保留和系統保留。

您可以為節點設定 Pod PID 上限，並在節點內的所有 Pod 中共用。

準備管理程序 ID 限制

這些程序會使用下列環境變數：

export PROJECT_ID=MY_PROJECT_ID
export CLUSTER_NAME=MY_CLUSTER_NAME
export LOCATION=MY_CLUSTER_LOCATION
export APIGEE_NAMESPACE=MY_APIGEE_NAMESPACE # Default: apigee

驗證存取權

設定程序 ID 限制前，請確認您有權編輯 Kubernetes 叢集。

以下步驟適用於在 GKE 上安裝。如需其他平台的說明，請參閱該平台的說明文件。

1. 檢查 IAM 政策中是否有 roles/container.clusterAdmin：

   gcloud projects get-iam-policy ${PROJECT_ID}  \
    --flatten="bindings[].members" \
    --format='table(bindings.role)' \
    --filter="bindings.members:your_account_email"
   

2. 如果您沒有這項存取權，請在帳戶中新增角色：

   gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member user:your_account_email \
    --role roles/container.clusterAdmin

確認現有的 PID 限制

請先確認節點是否有現有的 PID 限制，再設定新的限制。

1. 從叢集中取得節點，以便檢查值。您需要檢查 apigee-data 和 apigee-runtime 節點集區中的節點：

   kubectl get nodes -n ${APIGEE_NAMESPACE}
   

   輸出內容應類似以下所示：

   NAME                                      STATUS   ROLES    AGE    VERSION
   gke-my-hybrid-apigee-data-0a1b2c3d-efgh      Ready       2d8h   v1.31.5-gke.1169000
   gke-my-hybrid-apigee-runtime-1b2c3d4e-fghi   Ready       2d8h   v1.31.5-gke.1169000
   

2. 從上一個步驟的輸出內容匯出節點名稱。請先針對 apigee-data 節點執行下一個步驟，然後再針對 apigee-runtime 節點執行：

   程式碼

   export NODE_NAME=MY_NODE_NAME
   

   範例

   export NODE_NAME="gke-my-hybrid-apigee-data-0a1b2c3d-efgh"
   

3. 查看 節點的 PID 限制。請使用下列指令檢查保留值。如果值為空值，表示未設定該值：

   kubectl get --raw "/api/v1/nodes/${NODE_NAME}/proxy/configz" | jq '.kubeletconfig.kubeReserved'
   kubectl get --raw "/api/v1/nodes/${NODE_NAME}/proxy/configz" | jq '.kubeletconfig.systemReserved'
   kubectl get --raw "/api/v1/nodes/${NODE_NAME}/proxy/configz" | jq '.kubeletconfig.evictionHard'
   

4. 請查看 Pod PID 限制。使用下列指令檢查現有的 Pod PID 限制。如果傳回的值為 -1 或空白，則未設定限制：

   kubectl get --raw "/api/v1/nodes/${NODE_NAME}/proxy/configz" | jq '.kubeletconfig.podPidsLimit'
   

管理程序 ID 限制

管理節點 PID 限制

在 GKE 上安裝時，Kubernetes 節點的基礎架構資源會由內部管理，因此您不需要設定。如要查看目前的容量和可分配資源，請參閱 Google Kubernetes Engine 說明文件中的「節點可分配資源」一節。

如果是其他非 GKE 平台，請參閱該平台的對應 Kubernetes 說明文件。如果叢集/節點是使用者管理 (而非完全管理)，則可以使用 Kubelet 設定 kube 保留的 PID 限制和系統保留的 PID 限制。請參閱 Kubernetes 說明文件中的「節點 PID 限制」一節。

工具

本程序會使用 Kubelet 管理程序 ID 限制。Kubelet 是執行在 Pod 和容器上的代理程式，可確保 Pod 和容器按照 PodSpec 執行。如果您需要安裝 Kubelet，請按照 Kubernetes 說明文件中的操作說明進行：安裝 kubeadm、kubelet 和 kubectl。

程序

1. 建立名為 kubelet-config.yaml 的 Kubelet 設定檔。

   apiVersion: kubelet.config.k8s.io/v1beta1
   kind: KubeletConfiguration
   kubeReserved:
    pid: PID_VALUE # Example: 1000
   

   如要進一步瞭解設定，請參閱 Kubernetes 說明文件中的「Kube Reserved」。

2. 套用 Kubelet 設定：

   kubelet --config PATH_TO_KUBELET_CONFIG_YAML
   

管理 Pod PID 限制

選擇限制

如果 PID 限制設得太低，可能會導致 Pod 無法啟動。如果設定過高，可能會無法偵測資源錯誤行為。在選擇適當的限制時，請務必考量節點先前的行為，以及任何服務專屬需求。

GKE 對值有必要的範圍限制：[1024, 4194304]。在 GKE 平台上，您可以在 Google Cloud console Metrics Explorer 中查看 Kubernetes 服務帳戶的狀態。選取「Kubernetes Node - PID usage」指標並套用篩選器。這項指標會顯示最近的程序 ID 用量，可在選擇 PID 限制時參考。

Metrics Explorer

在非 GKE 平台上，您可能可以使用其他監控選項。請參閱對應平台的 Kubernetes 說明文件，查看指標。

Apigee 廣告連播的程序 ID 規定

Apigee Hybrid 使用 2 個節點集區：apigee-data 和 apigee-runtime。由於部分 Apigee 元件會部署在兩個節點集區中，因此兩個節點集區的 Pod PID 限制應相同。Pod PID 上限也應高於所有 Apigee Pod 所需的 PID 上限。所需的 Apigee Pod PID 上限為 1000，低於 GKE 平台的最低要求數量。

建議的 Pod PID 限制

部分平台會強制執行 Pod PID 限制的最低值需求，在這種情況下，系統會選取最低值需求。

程序

在 GKE 和非 GKE 平台上，Pod PID 限制的管理程序有所不同。

排解程序 ID 限制問題

Pod 卡在 Pending 狀態，並發生 FailedScheduling 錯誤

如果節點或 Pod PID 限制會導致 Pod 遭到移除或無法啟動，Pod 就會卡在 Pending 狀態，並因 FailedScheduling 錯誤而失敗。

1. 取得 Node 欄：

   kubectl get pods -n ${APIGEE_NAMESPACE} ${POD_NAME} -o wide
   

2. 檢查是否有 PIDPressure 條件：

   kubectl describe node -n apigee ${NODE_NAME} | grep PIDPressure
   

3. 或者，您也可以檢查對應 Pod 的 ApigeeDeployment。從結果中取得與錯誤 Pod 相同前置字串的 ApigeeDeployment。

   kubectl get ApigeeDeployment -n ${APIGEE_NAMESPACE}
   

4. 檢查最近的 Events 是否有 PID 相關錯誤訊息：

   kubectl describe ApigeeDeployment -n ${APIGEE_NAMESPACE} ${APIGEE_DEPLOYMENT_NAME}
   

5. 如果確認原因是 PID 限制，請按照「管理節點 PID 限制」中的步驟，將 PID 限制更新為較高的值。

「podPidsLimit」無效

設定 GKE 限制時，如果 podPidsLimit 超過限制，系統會顯示錯誤訊息：

ERROR: (gcloud.container.node-pools.update) ResponseError: code=400, message=Invalid podPidsLimit : value must be 1024 <= podPidsLimit <= 4194304.

將 podPidsLimit 值更新至必要範圍內。