概要
プロセス ID(PID)の上限は、ノードの安定性に影響する過剰なプロセス作成を防ぐための、ノードと Pod に対する Kubernetes リソース制約です。Apigee ハイブリッドは、プロセス ID の上限を設定する Kubernetes 機能をサポートしています。このドキュメントでは、これらの上限を設定する方法と、特定のプラットフォームの Apigee サービスに推奨される値について説明します。
Apigee ハイブリッドのユーザーが独自のクラスタを管理する場合、Kubernetes での PID の上限を設定すると、システムの安定性、セキュリティ、リソース管理を改善できます。これは Kubernetes のベスト プラクティスとも一貫性があります。
プロセス ID の上限の定義
プロセス ID の上限には、ノード PID の上限と Pod PID の上限があります。
ノード PID の上限には、Kube-reserved PID と system-reserved PID が含まれます。割り当て可能な PID の合計数は、kube-reserved PID、system-reserved PID、エビクションしきい値 PID をカーネルの最大数から差し引いた数です。
カーネルの最大 ID 数の上限 |
|
|
|
= 割り当て可能 |
- カーネルの最大 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_IDexport CLUSTER_NAME=MY_CLUSTER_NAME
export LOCATION=MY_CLUSTER_LOCATION
export APIGEE_NAMESPACE=MY_APIGEE_NAMESPACE # Default: apigee
アクセス権の確認
プロセス ID の上限を構成する前に、Kubernetes クラスタの編集権限を確保してください。
次の手順は、GKE でのインストールの場合です。他のプラットフォームを使用している場合は、それぞれのドキュメントをご覧ください。
-
IAM ポリシーに roles/container.clusterAdmin が含まれているかどうかを確認します。
gcloud projects get-iam-policy ${PROJECT_ID} \ --flatten="bindings[].members" \ --format='table(bindings.role)' \ --filter="bindings.members:your_account_email"
- アクセス権がない場合は、アカウントにこのロールを追加します。
gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member user:your_account_email \ --role roles/container.clusterAdmin
既存の PID の上限を確認する
新しい上限を構成する前に、ノードに既存の PID 上限があるかどうかを確認します。
-
クラスタからノードを取得して値を確認します。
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 -
前の手順の出力からノード名をエクスポートします。次の手順として、このコードをまず
apigee-data
ノードで実行し、次にapigee-runtime
ノードで実行します。コード
export NODE_NAME=MY_NODE_NAME
例
export NODE_NAME="gke-my-hybrid-apigee-data-0a1b2c3d-efgh"
- ノード 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'
- 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 のインストールの手順を行ってください。
手順
-
kubelet-config.yaml
という Kubelet 構成ファイルを作成します。apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration kubeReserved: pid: PID_VALUE # Example: 1000
構成の詳細については、Kubernetes ドキュメントの Kube Reserved をご覧ください。
-
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 の上限を選択する際に参照できます。
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 をご覧ください。
-
node-config.yaml
というノードシステム構成を作成し、Pod PID の上限を次に示す指定通りにします。kubeletConfig: podPidsLimit: POD_PID_VALUE # Example: 1024
-
構成を 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
フィールドで設定します。
-
kubelet-config.yaml
という名前の Kubelet 構成ファイルを、次の内容で作成します。apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration podPidsLimit: POD_PID_VALUE # Example: 1024
-
構成を適用します。podPidsLimit を設定するには、影響を受けるノードを再起動する必要があり、これによりダウンタイムが生じる可能性があります。
kubelet --config PATH_TO_KUBELET_CONFIG_YAML
- 構成を確認します。手順については、既存の 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
エラーで失敗します。
-
Node 列を取得します。
kubectl get pods -n ${APIGEE_NAMESPACE} ${POD_NAME} -o wide
-
PIDPressure
条件があるかどうかを確認します。kubectl describe node -n apigee ${NODE_NAME} | grep PIDPressure
-
または、対応する Pod の
ApigeeDeployment
を確認します。エラーが発生した Pod と同じ接頭辞を持つ結果から、ApigeeDeployment
を取得します。kubectl get ApigeeDeployment -n ${APIGEE_NAMESPACE}
-
最近の
Events
に PID 関連のエラー メッセージがあるかどうかを確認します。kubectl describe ApigeeDeployment -n ${APIGEE_NAMESPACE} ${APIGEE_DEPLOYMENT_NAME}
- 原因が 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 の値を必要な範囲内に更新します。