ノードプールについて
ノードプールとは、クラスタ内で同じ構成を持つノードのグループのことです。通常、リソース要件が異なる Pod がある場合は、別々のノードプールを定義します。たとえば、apigee-cassandra Pod には永続ストレージが必要ですが、他の Apigee ハイブリッド Pod には必要ありません。
このトピックでは、Hybrid インストール環境に専用ノードプールを構成する方法について説明します。
デフォルトの nodeSelector の使用
ベスト プラクティスは、Cassandra Pod 用とその他すべてのランタイム Pod 用に 1 つずつ、計 2 つの専用ノードプールを設定することです。インストール時にデフォルトの nodeSelector 構成を使用すると、Cassandra Pod は apigee-data というステートフル ノードプールに割り当てられ、その他すべての Pod は apigee-runtime というステートレス ノードプールに割り当てられます。このような名前を持つノードプールを作成するだけで、Pod のスケジューリングの詳細が自動的に処理されます。
| デフォルトのノードプール名 | 説明 |
|---|---|
apigee-data |
ステートフル ノードプール。 |
apigee-runtime |
ステートレス ノードプール。 |
次にデフォルトの nodeSelector 構成を示します。apigeeData プロパティは、Cassandra Pod のノードプールを指定します。apigeeRuntime は、その他すべての Pod のノードプールを指定します。後述のように、これらのデフォルト設定はオーバーライド ファイルで変更できます。
nodeSelector: requiredForScheduling: true apigeeRuntime: key: "cloud.google.com/gke-nodepool" value: "apigee-runtime" apigeeData: key: "cloud.google.com/gke-nodepool" value: "apigee-data"
Pod が正しいノードでスケジュールされるように、apigee-data と apigee-runtime という名前の 2 つのノードプールを作成します。
requiredForScheduling プロパティ
nodeSelector 構成セクションには requiredForScheduling というプロパティがあります。
nodeSelector: requiredForScheduling: false apigeeRuntime: key: "cloud.google.com/gke-nodepool" value: "apigee-runtime" apigeeData: key: "cloud.google.com/gke-nodepool" value: "apigee-data"
これが false に設定されている場合、ノードプールが必要な名前で定義されているかどうかにかかわらず、基になる Pod はスケジュールされます。つまり、ノードプールを作成し忘れた場合や、誤ってノードプールに apigee-runtime または apigee-data 以外の名前を付けてしまった場合でも、ハイブリッド ランタイムは正常に機能します。Pod がどこで実行されるかは Kubernetes によって決定されます。
requiredForScheduling を true（デフォルト）に設定する場合、構成済みの nodeSelector 鍵と値に一致するノードプールがなければ、インストールは失敗します。
カスタム ノードプール名の使用
ノードプールの名前をデフォルトとは異なる名前にする場合は、カスタム名を持つノードプールを作成し、それらの名前を nodeSelector スタンザで指定します。たとえば、次の構成では、Cassandra Pod を my-cassandra-pool というノードプールに割り当て、その他すべての Pod を my-runtime-pool というノードプールに割り当てています。
nodeSelector: requiredForScheduling: false apigeeRuntime: key: "cloud.google.com/gke-nodepool" value: "my-runtime-pool" apigeeData: key: "cloud.google.com/gke-nodepool" value: "my-cassandra-pool"
GKE 上の特定のコンポーネントのノードプールのオーバーライド
ノードプールの構成を個々のコンポーネント レベルでオーバーライドすることもできます。たとえば、次の構成では、値が apigee-custom であるノードプールを runtime コンポーネントに割り当てています。
runtime: nodeSelector: key: cloud.google.com/gke-nodepool value: apigee-custom
カスタム ノードプールは次のコンポーネントで指定できます。
istiomartsynchronizerruntimecassandraudcalogger
GKE ノードプール構成
GKE では、ノードプールの作成時に固有の名前を付ける必要があります。そうすると、各ノードに次のラベルが自動的に付加されます。
cloud.google.com/gke-nodepool=THE_NODE_POOL_NAME
apigee-data と apigee-runtime という名前のノードプールを作成すれば、それ以上の構成は必要ありません。カスタムノード名を使用する場合は、カスタム ノードプール名の使用をご覧ください。
ノードの手動ラベル付け
Apigee ハイブリッドは現在、Anthos 1.1.1 でのみサポートされています。このバージョンの Anthos はノードプール機能をサポートしていません。そのため、次の手順でワーカーノードに手動でラベルを付ける必要があります。Hybrid クラスタが稼働した後、次の操作を行います。
- 次のコマンドを実行して、クラスタ内のワーカーノードのリストを取得します。
kubectl -n APIGEE_NAMESPACE get nodes
出力例:
NAME STATUS ROLES AGE VERSION apigee-092d639a-4hqt Ready <none> 7d v1.14.6-gke.2 apigee-092d639a-ffd0 Ready <none> 7d v1.14.6-gke.2 apigee-109b55fc-5tjf Ready <none> 7d v1.14.6-gke.2 apigee-c2a9203a-8h27 Ready <none> 7d v1.14.6-gke.2 apigee-c70aedae-t366 Ready <none> 7d v1.14.6-gke.2 apigee-d349e89b-hv2b Ready <none> 7d v1.14.6-gke.2
- 各ノードにラベルを付けてランタイム ノードとデータノードを区別します。
ノードにラベルを付けるには、次のコマンドを使用します。
kubectl label node NODE_NAME KEY=VALUE
次に例を示します。
$ kubectl label node apigee-092d639a-4hqt apigee.com/apigee-nodepool=apigee-runtime $ kubectl label node apigee-092d639a-ffd0 apigee.com/apigee-nodepool=apigee-runtime $ kubectl label node apigee-109b55fc-5tjf apigee.com/apigee-nodepool=apigee-runtime $ kubectl label node apigee-c2a9203a-8h27 apigee.com/apigee-nodepool=apigee-data $ kubectl label node apigee-c70aedae-t366 apigee.com/apigee-nodepool=apigee-data $ kubectl label node apigee-d349e89b-hv2b apigee.com/apigee-nodepool=apigee-data
Anthos GKE 上の特定のコンポーネント用のノードプールのオーバーライド
ノードプールの構成を Anthos GKE 上の個々のコンポーネント レベルでオーバーライドすることもできます。たとえば、次の構成では、値が apigee-custom であるノードプールを runtime コンポーネントに割り当てています。
runtime: nodeSelector: key: apigee.com/apigee-nodepool value: apigee-custom
カスタム ノードプールは次のコンポーネントで指定できます。
istiomartsynchronizerruntimecassandraudcalogger