プロセス ID の上限を管理する

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

概要

プロセス ID（PID）の上限は、ノードの安定性に影響する過剰なプロセスの作成を防ぐために、ノードと Pod に対する Kubernetes リソース制約です。Apigee ハイブリッドは、プロセス ID の上限を設定する Kubernetes 機能をサポートしています。このドキュメントでは、これらの上限を設定する方法と、特定のプラットフォームの Apigee サービスの値に関する推奨事項について説明します。

Apigee ハイブリッドのユーザーが独自のクラスタを管理する場合、Kubernetes で PID の上限を設定すると、システムの安定性、セキュリティ、リソース管理を改善できます。これは Kubernetes のベスト プラクティスにも準拠しています。

プロセス ID の上限の定義

プロセス ID の上限には、ノード PID の上限と Pod PID の上限があります。

ノード PID の上限には、Kube が予約した PID とシステムが予約した PID が含まれます。割り当て可能な PID の合計数は、カーネルの最大値から、kube 予約済み PID、システム予約済み PID、強制排除しきい値 PID を差し引いた値です。

• カーネルの最大 ID の上限: オペレーティング システムとそのカーネル設定によって決まります。Apigee Hybrid は Linux カーネルでのみ実行されるため、このガイドでは Kubernetes ノードに対する Linus ベースの上限について説明します。Linux カーネルのプロセス ID の上限は 4194304 です。
• Kube-reserved と system-reserved: Kubernetes または OS システム デーモンのリソース予約に使用します。
• 強制排除しきい値: ノードに負荷がかかっていることを示す上限。しきい値に達すると、ノードは強制排除されます。詳細については、PID ベースのエビクションをご覧ください。
• 割り当て可能: 使用可能な PID の数。詳細については、Kubernetes: Node Allocatable をご覧ください。Kube 予約とシステム予約は、ノードの PID 上限の設定で構成できます。

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 の上限を確認します。予約済み値を確認するには、次のコマンドを使用します。値が null の場合、値は構成されていません。

   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 のドキュメントをご覧ください。クラスタまたはノードがユーザー管理の場合（完全マネージドではない）、kube-reserved PID の上限とシステム予約 PID の上限は Kubelet で構成できます。Kubernetes ドキュメントのノードの PID の上限をご覧ください。

ツール

この手順では、Kubelet を使用してプロセス ID の上限を管理します。Kubelet は、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 Platforms では、 Google Cloud console Metrics Explorer で Kubernetes サービス アカウントのステータスを確認できます。[Kubernetes Node - PID usage] 指標を選択し、フィルタを適用します。この指標は、プロセス ID の最近の使用状況を示します。PID の上限を選択する際に参照できます。

Metrics Explorer

GKE 以外のプラットフォームでは、異なるモニタリング オプションを使用できる場合があります。指標を確認するには、対応するプラットフォームの Kubernetes ドキュメントをご覧ください。

Apigee Pod のプロセス ID の要件

Apigee ハイブリッドは、apigee-data と apigee-runtime の 2 つのノードプールを使用します。Apigee コンポーネントの一部は両方のノードプールにデプロイされるため、Pod PID の上限は 2 つのノードプールで同じにする必要があります。Pod の PID の上限は、すべての Apigee Pod で必要な PID の最大数よりも大きくする必要があります。必要な Apigee Pod PID の上限は 1, 000 で、これは GKE プラットフォームの最小要件を下回っています。

推奨される Pod PID の上限

プラットフォームによっては、Pod PID の上限に最小値の要件が適用されます。この場合、最小値の要件が選択されます。

手順

Pod PID の上限を管理する手順は、GKE プラットフォームと非 GKE プラットフォームで異なります。

プロセス ID の上限に関するトラブルシューティング

Pod が FailedScheduling エラーで Pending ステータスで停止する

ノードまたは 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 の値を必要な範囲内に更新します。