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

ここに表示されているのは、Apigee ハイブリッド バージョン 1.13 のドキュメントです。 詳細については、サポート対象バージョンをご覧ください。

Version 1.13 

サポート対象のバージョン:

• v1.15（最新）
• v1.14
• v1.13
• サポート対象バージョンのリスト

サポートされていないバージョン:

• v1.12
• v1.11
• v1.10
• v1.9
• v1.8
• v1.7
• v1.6
• v1.5
• v1.4
• v1.3
• v1.2
• v1.1

概要

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

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

注: PID の上限を設定する際、上限が低すぎると Pod の起動が制限され、システムのパフォーマンスに影響する可能性があります。推奨される上限に設定すると、Apigee のパフォーマンスに影響しません。

プロセス ID の上限の定義

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

ノード PID の上限には、Kube-reserved PID と system-reserved PID が含まれます。割り当て可能な PID の合計数は、kube-reserved PID、system-reserved PID、エビクションしきい値 PID をカーネルの最大数から差し引いた数です。

カーネルの最大 ID 数の上限

- Kube-reserved

- system-reserved

- エビクションしきい値

= 割り当て可能

• カーネルの最大 ID 数の上限: オペレーティング システムとそのカーネル設定によって決まります。Apigee ハイブリッドは Linux カーネルでのみ実行されるため、このガイドでは Linux ベースでの Kubernetes ノードの上限について説明します。Linux カーネルのプロセス ID 数上限は 4,194,304 個です。
• Kube-reserved と system-reserved: Kubernetes または OS システム デーモンのリソース予約用。
• エビクションしきい値: ノードに負荷がかかっていることを示す上限。しきい値に達すると、ノードは強制排除されます。詳細については、PID ベースの強制排除をご覧ください。
• 割り当て可能: 使用可能な PID の数です。詳細については、Kubernetes: Node Allocatable をご覧ください。Kube-reserved と system-reserved は、ノードの 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 予約 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 では、値に対して必要な範囲が定められており、その範囲は [1,024～4,194,304] です。GKE プラットフォームでは、 Google Cloud console Metrics Explorer で Kubernetes サービス アカウントのステータスを確認できます。[Kubernetes ノード - PID 使用量] 指標を選択し、フィルタを適用すると、この指標は、プロセス ID の最近の使用量を示します。PID の上限を選択する際に参照できます。

Metrics Explorer

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

Apigee Pod 用プロセス ID の要件

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

Pod PID に推奨される上限

一部のプラットフォームでは、Pod PID の上限に、必要最小限の値が適用されます。この場合、必要となる最小値が選択されます。

プラットフォーム	Pod PID の下限
GKE on Google Cloud	1024
GKE on AWS	1024
GKE on Azure	1024
VMware 版 Google Distributed Cloud（ソフトウェアのみ）	1024
ベアメタル版 Google Distributed Cloud（ソフトウェアのみ）	1024
EKS	1000
AKS	1000
OpenShift	1000
Rancher Kubernetes Engine（RKE）	1000

手順

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

GKE プラットフォーム

PID の上限の更新をサポートする GKE プラットフォームには、以下が含まれます。

• Google Cloud 上の GKE: gcloud container node-pools をご覧ください。
• AWS 上の GKE: gcloud container aws node-pools をご覧ください。
• Azure 上の GKE: gcloud container azure node-pools をご覧ください。
• Google Distributed Cloud（ソフトウェアのみ）on VMware: gcloud container vmware node-pools をご覧ください。
• Google Distributed Cloud（ソフトウェアのみ）on bare metal: gcloud container bare-metal node-pools をご覧ください。

Pod PID の上限は、ノードシステム構成によって制御されます。GKE では、値に対して必要な範囲が定められており、その範囲は [1,024～4,194,304] です。詳細については、NodeKubeletConfig をご覧ください。

1. node-config.yaml というノードシステム構成を作成し、Pod PID の上限を次に示す指定通りにします。

   kubeletConfig:
    podPidsLimit: POD_PID_VALUE # Example: 1024
   

2. 構成を apigee の apigee-data ノードプールと apigee-runtime ノードプールの両方に適用します。構成を適用すると、ノードは、ダウンタイムのないノードのアップグレード戦略のいずれかを使用して、ロールアウトを開始します。

   gcloud container OPTIONAL_HOST_PLATFORM node-pools update NODE_POOL_NAME \
      --cluster CLUSTER_NAME \
      --region CLUSTER_LOCATION \
      --system-config-from-file=node-config.yaml \
      --project PROJECT_ID
   

   注: この構成は、クラスタ作成のさまざまな段階で適用できます。ノードプールへの構成の追加をご覧ください。

GKE 以外のプラットフォーム

GKE 以外のプラットフォームでは、Pod PID の上限は Kubelet によって制御されます。この上限は、Kubelet 構成ファイルの podPidsLimit フィールドで設定します。

1. kubelet-config.yaml という名前の Kubelet 構成ファイルを、次の内容で作成します。

   apiVersion: kubelet.config.k8s.io/v1beta1
   kind: KubeletConfiguration
   podPidsLimit: POD_PID_VALUE # Example: 1024
   

2. 構成を適用します。podPidsLimit を設定するには、影響を受けるノードを再起動する必要があり、これによりダウンタイムが生じる可能性があります。

   kubelet --config PATH_TO_KUBELET_CONFIG_YAML
   

3. 構成を確認します。手順については、既存の PID の上限を確認するをご覧ください。

Pod PID の上限構成コマンドと推奨されるツールは、プラットフォームによって異なります。コマンドの詳細については、各プラットフォームのドキュメントをご覧ください。以下に、GKE 以外のプラットフォームのドキュメントへの参照リンクを示します。なお、これらの内容は変更される場合があります。

プラットフォーム	ドキュメント
EKS	起動テンプレートを使用してマネージド ノードをカスタマイズする
AKS	Azure Kubernetes Service（AKS）ノードプールのノード構成をカスタマイズする
OpenShift	Red Hat OpenShift Service on AWS の Pod でプロセス ID の上限を引き上げるリスク
Rancher Kubernetes Engine（RKE）	Kubectl と kubeconfig を使用してクラスタにアクセスする

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

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

ノードまたは Pod の PID の上限により Pod が強制排除される場合や、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 の値を必要な範囲内に更新します。