リアルノードと仮想ノードが共存する混合クラスターでは、Pod を Elastic Container Instance (ECI) にスケジューリングし、ECI 固有の機能を有効にするには、通常、Pod の YAML ファイルを変更する必要があります。これにより、プラットフォーム運用とアプリケーション構成の境界が曖昧になります。eci-profile はこの負担を解消します。クラスター管理者は、単一のクラスターレベルの ConfigMap でスケジューリングルールとアノテーションの挿入を定義するだけで、アプリケーションの YAML を変更することなく、Pod には適切な設定が自動的に適用されます。
仕組み
Pod が作成されると、ack-virtual-node は kube-system 名前空間にある eci-profile という名前の ConfigMap を読み取り、その data セクションの設定を Pod に適用します。
eci-profile は、次の 3 つの機能を提供します:
-
ECI Scheduler:Mutating Webhook を使用して、Pod のラベルまたは名前空間のラベルに基づいて Pod を ECI にルーティングします。これにより、個々の Pod の YAML ファイルにスケジューリングディレクティブを追加する必要がなくなります。
-
ECI Effect:一致した Pod にアノテーションとラベルを自動的に挿入し、Elastic Compute Service (ECS) インスタンスタイプの指定、イメージキャッシュの有効化、Network Time Protocol (NTP) サービスの設定などの高度な ECI 機能を有効にします。サポートされているアノテーションの完全なリストについては、「ECI Pod Annotation」をご参照ください。
-
ホットアップデート:eci-profile (クラスター IP アドレス、ハイブリッドクラウド、ログ収集、vSwitch) への設定変更は、新しく作成された Pod に対して即座に有効になります。ack-virtual-node の再起動は不要です。既存の Pod は、ローリングアップデート後にのみ変更が適用されます。
前提条件
開始する前に、次のことを確認してください:
-
クラスター内の ack-virtual-node アドオンが最新バージョンであること。更新するには、「コンポーネントの管理」をご参照ください。
-
クラスターで Mutating Webhook が有効になっていること (ECI Scheduler に必要です)。ACK Serverless クラスターでは、Pod は自動的に ECI にスケジューリングされるため、ECI Scheduler は不要です。
注意事項
-
eci-profile を更新すると、新しく作成された ECI Pod は更新された設定をすぐに使用します。既存の Pod は、ローリングアップデート後にのみ更新された設定を使用します。
-
セレクターに
namespaceSelectorもobjectSelectorも設定せず、effectを設定した場合、その effect 設定は ECI にスケジューリングされるすべての Pod に適用されます。 -
複数のセレクターが 1 つの Pod に一致する場合、それらは順番に評価されます。先に一致したセレクターのアノテーションとラベルが、後に一致したセレクターのものより優先されます。既存の Pod のアノテーションとラベルは、
effectによって挿入されるものよりも常に優先されます。
eci-profile の表示
次のコマンドを実行して、現在の eci-profile ConfigMap を表示します:
kubectl get cm -n kube-system eci-profile -o yaml
ConfigMap の data セクションには、次の 2 種類の設定が含まれています:
| パラメーター | 説明 |
|---|---|
selectors |
ECI Scheduler と ECI Effect のルールを定義します。「セレクターの設定」をご参照ください。 |
その他のパラメーター (vpcId、vSwitchIds など) |
Pod レベルのオーバーライドがない場合に適用されるクラスターレベルのパラメーター。ホットアップデートに対応しています。「クラスターレベルパラメーターの更新」をご参照ください。 |
デフォルトの eci-profile は次のようになります:
apiVersion: v1
data:
enableClusterIp: "true"
enableHybridMode: "false"
enableLinuxArm64Node: "false"
enableLogController: "false"
enablePVCController: "false"
enablePrivateZone: "false"
enableReuseSSLKey: "false"
featureGates: "WaitForFirstConsumer=false"
securityGroupId: sg-2zeeyaaxlkq9sppl****
selectors: ""
slsMachineGroup: ""
vSwitchIds: vsw-2ze23nqzig8inprou****,vsw-2ze94pjtfuj9vaymf****
vpcId: vpc-2zeghwzptn5zii0w7****
kind: ConfigMap
metadata:
creationTimestamp: "2023-01-11T08:28:14Z"
name: eci-profile
namespace: kube-system
resourceVersion: "356"
uid: b345fa8c-919e-41fc-a981-57864b1a****
eci-profile の編集
次のいずれかの方法を使用して eci-profile を編集します。
kubectl
kubectl edit configmap eci-profile -n kube-system
ACK コンソール
-
[クラスター] ページで、目的のクラスターの名前をクリックします。
-
左側のナビゲーションペインで、[構成 > ConfigMaps] を選択します。
-
[Namespace] ドロップダウンリストから [kube-system] を選択します。
-
eci-profile を見つけ、[アクション] 列の [YAML の編集] をクリックします。
セレクターの設定
セレクターは、どの Pod を ECI にルーティングするか (ECI Scheduler)、およびそれらの Pod にどのアノテーションまたはラベルを挿入するか (ECI Effect) を定義します。Pod が作成されると、システムは各セレクターを順番に評価し、一致するルールを適用します。
各セレクターは、次のフィールドをサポートしています:
-
name(必須):セレクターの一意の名前。 -
namespaceSelector(任意):名前空間のラベルに基づいて Pod を照合します。matchLabelsの下にラベルを指定します。複数のラベルは AND ロジックを使用します。 -
objectSelector(任意):Pod のラベルに基づいて Pod を照合します。matchLabelsの下にラベルを指定します。複数のラベルは AND ロジックを使用します。 -
effect(任意):一致した Pod に挿入するアノテーションとラベル。挿入された値は、既存の Pod のアノテーションやラベルを上書きしません。
namespaceSelector と objectSelector の両方が設定されている場合、Pod はセレクターに一致するために両方を満たす必要があります。どちらも設定されていないが effect が設定されている場合、その effect は ECI にスケジューリングされるすべての Pod に適用されます。
セレクターテンプレート
data:
selectors: |
[
{
"name": "selector-demo1", # 必須。一意のセレクター名。
"namespaceSelector": { # 任意。名前空間のラベルで照合。
"matchLabels": { # 複数のラベル間では AND ロジック。
"eci": "true"
}
},
"objectSelector": { # 任意。Pod のラベルで照合。
"matchLabels": { # 複数のラベル間では AND ロジック。
"eci": "true"
}
},
"effect": { # 任意。挿入するアノテーションとラベル。
"annotations": {
"k8s.aliyun.com/eci-use-specs": "ecs.c6.xlarge"
},
"labels": {
"created-by-eci": "true"
}
}
},
{
"name": "selector-demo2",
"objectSelector": {
"matchLabels": {
"eci": "test"
}
}
}
]
上記の例では、selector-demo1 は、eci: true の Pod ラベルを持ち、かつ eci: true ラベルを持つ名前空間に属する Pod に一致します。一致した Pod は ECI にスケジューリングされ、k8s.aliyun.com/eci-use-specs: ecs.c6.xlarge アノテーションと created-by-eci: true ラベルが付与されます。
設定を適用する前に、インラインコメント (#) を削除してください。JSON はコメントをサポートしていません。
セレクターが有効になっていることの確認
セレクターを更新した後、次のコマンドを実行して、それらが登録されていることを確認します:
kubectl get mutatingwebhookconfigurations -o yaml vk-webhook
出力に設定したセレクターが含まれている場合、設定は有効です。含まれていない場合は、セレクターの JSON が正しくフォーマットされているかを確認してください。
設定例
例 1:特定の Pod を ECI にルーティング
次のセレクターは、Pod が created-by-eci: true ラベルを持ち、その名前空間が type: eci ラベルを持つ場合に、Pod を ECI にルーティングします。
data:
selectors: |
[
{
"name": "eci-selector",
"namespaceSelector": {
"matchLabels": {
"type": "eci"
}
},
"objectSelector": {
"matchLabels": {
"created-by-eci": "true"
}
}
}
]
例 2:GPU 高速化インスタンスタイプで Pod を ECI にルーティング
次のセレクターは、gpu: true ラベルを持つ名前空間に属する Pod を、ecs.gn6v-c8g1.2xlarge GPU 高速化インスタンスタイプを使用して ECI にルーティングし、一致した Pod に gpu: test ラベルを追加します。
data:
selectors: |
[
{
"name": "gpu-namespace-selector",
"namespaceSelector": {
"matchLabels": {
"gpu": "true"
}
},
"effect": {
"annotations": {
"k8s.aliyun.com/eci-use-specs": "ecs.gn6v-c8g1.2xlarge"
},
"labels": {
"gpu": "test"
}
}
}
]
例 3:自動イメージキャッシュマッチングで Pod を ECI にルーティング
次のセレクターは、imc: auto ラベルを持つ Pod を ECI にルーティングし、自動イメージキャッシュマッチングを有効にします。
data:
selectors: |
[
{
"name": "autoimc-object-selector",
"objectSelector": {
"matchLabels": {
"imc": "auto"
}
},
"effect": {
"annotations": {
"k8s.aliyun.com/eci-auto-imc": "true"
}
}
}
]
クラスターレベルパラメーターの更新
data セクションの次のパラメーターは、クラスターレベルのデフォルトです。Pod が Pod レベルのオーバーライドなしで作成された場合、eci-profile の値が使用されます。すべてのパラメーターはホットアップデートをサポートしており、変更は ack-virtual-node を再起動することなく即座に有効になります。
これらのパラメーターは、Pod レベルの設定で上書きされない場合にのみ適用されます。
| パラメーター | デフォルト | 説明 |
|---|---|---|
enableClusterIp |
"true" |
クラスター IP アドレスをサポートするかどうか。 |
enableHybridMode |
"false" |
ハイブリッドクラウドモードを有効にするかどうか。 |
enableLinuxArm64Node |
"false" |
ARM ベースのノードを有効にするかどうか。「ARM ベースの仮想ノードへの Pod のスケジューリング」をご参照ください。 |
enableLogController |
"false" |
Simple Log Service のカスタムリソース定義 (CRD) を使用して Pod ログを収集するかどうか。"true" に設定した場合は、slsMachineGroup も設定します。 |
enablePVCController |
"false" |
オンラインディスク拡張を有効にするかどうか。"true" に設定すると、システムはディスクにバインドされた PersistentVolumeClaim (PVC) をホットエクステンドすることが可能です。 |
enablePrivateZone |
"false" |
ドメイン名解決に PrivateZone を使用するかどうか。 |
enableReuseSSLKey |
"false" |
Pod 間で SSL キーを再利用するかどうか。デフォルトでは、ack-virtual-node は各 Pod に一意の SSL 証明書を発行します。これを "true" に設定すると、すべての Pod が同じ証明書を共有するようになり、セキュリティが低下する代わりに、Pod の作成スループットが向上します。 |
featureGates |
"WaitForFirstConsumer=false" |
カナリア機能ゲート。WaitForFirstConsumer のみが設定可能です。以下の注記をご参照ください。 |
securityGroupId |
— | ECI Pod のセキュリティグループ。例:sg-2zeeyaaxlkq9sppl****。 |
slsMachineGroup |
— | ECI Pod のマシングループ。enableLogController が "true" の場合に必須です。例:test-mg。 |
vSwitchIds |
— | ECI Pod の vSwitch の ID。複数の ID はカンマで区切ります。例:vsw-2ze23nqzig8inprou****,vsw-2ze94pjtfuj9vaymf****。 |
vpcId |
— | ECI Pod がデプロイされる Virtual Private Cloud (VPC) の ID。例:vpc-2zeghwzptn5zii0w7****。 |
featureGates: WaitForFirstConsumer について
WaitForFirstConsumer が "true" に設定されている場合:
-
この設定を有効にする前に、csi-provisioner アドオンが最新バージョンである必要があります。
-
PersistentVolume (PV) とバックエンドストレージは、Pod がスケジューリングされた後にのみ作成されます。StorageClass で指定されたゾーンとリージョンは使用されなくなり、代わりにスケジューリングされた Pod のノードのゾーンとリージョンがストレージリソースの作成に使用されます。これにより、コンピューティングリソースが優先的にスケジューリングされるようになります。
詳細については、「ボリュームバインディングモード」をご参照ください。
完全な data セクションの例:
data:
enableClusterIp: "true"
enableHybridMode: "false"
enableLinuxArm64Node: "false"
enableLogController: "false"
enablePVCController: "false"
enablePrivateZone: "false"
enableReuseSSLKey: "false"
securityGroupId: sg-2zeeyaaxlkq9sppl****
selectors: ""
slsMachineGroup: ""
vSwitchIds: vsw-2ze23nqzig8inprou****,vsw-2ze94pjtfuj9vaymf****
vpcId: vpc-2zeghwzptn5zii0w7****