ポッドスケジューリング
概要 ジュニパークラウドネイティブのContrail Networking(CN2)リリース23.1は、 を使用した contrail-schedulerネットワーク対応ポッドスケジューリングをサポートしています。この機能は、ポッドをスケジューリングする前にノードのネットワークメトリックを分析するプラグインで、Kubernetesポッドスケジューラを強化します。この記事では、ネットワーク対応ポッドスケジューリングの概要、実装、導入情報を提供します。
Kubernetesでのポッドスケジューリング
Kubernetesでは、スケジューリングとは、ポッドをノードに一致させるプロセスを指し、kubeletがポッドを実行できるようにします。スケジューラーは、ポッド作成のリクエストを監視し、スケジューリングとバインディングサイクル中に一連の拡張ポイントを使用して、これらのポッドを適切なノードに割り当てようとします。潜在的なノードは、ポッドのリソース要件などの属性に基づいてフィルタリングされます。ノードにポッドに使用可能なリソースがない場合、そのノードは除外されます。複数のノードがフィルタリングフェーズに合格した場合、Kubernetesは特定のポッドに対する適合性に基づいて残りのノードをスコアし、ランク付けします。スケジューラーは、ランキングが最も高いノードにポッドを割り当てます。2 つのノードのスコアが同じ場合、スケジューラーはランダムにノードを選択します。
CN2でのポッドスケジューリング
CN2リリース22.4は、デフォルトのKubernetesポッドスケジューラを拡張し、DPDKノードの仮想マシンインターフェイス(VMI)の考慮事項に基づいてポッドをスケジュールします。と呼ばれる contrail-schedulerこの拡張スケジューラは、DPDKノードの現在のアクティブなVPIに基づいてポッドのスケジューリングを有効にするカスタムプラグインをサポートしています。
CN2リリース23.1は、2つの追加プラグインをサポートすることで、この機能を改善します。これらのプラグインの結果、 contrail-scheduler 以下のネットワークメトリックに基づいてポッドをスケジュールします。
-
アクティブなイングレス/エグレス トラフィック フローの数
-
帯域幅の利用
-
仮想マシン インターフェイス(VMI)の数
ネットワーク認識型ポッドスケジューリングの概要
多くのハイパフォーマンスアプリケーションには、帯域幅やネットワークインターフェイスの要件のほか、一般的なCPUやVSIの要件があります。帯域幅の可用性が低いノードにポッドを割り当てると contrail-scheduler 、そのアプリケーションは最適に動作できません。CN2リリース23.1は、メトリックコレクター、中央コレクター、カスタムスケジューラプラグインの導入により、この問題に対処します。これらのコンポーネントは、ネットワークメトリックを収集、保存、処理し、これらのメトリックに contrail-scheduler 基づいてポッドをスケジュールします。
ネットワーク認識型ポッド スケジューリング コンポーネント
CN2のネットワーク対応ポッドスケジューリングソリューションは、以下の主要コンポーネントで構成されています。
-
メトリックコレクター:これは、コンテナ内で、クラスター内の各ノードで実行されるvRouterポッドとともに実行されます。.vRouter エージェントは、vRouter CR の フィールドで指定された方法
localhost: 6700でcollectorsagent:default:メトリック データをメトリック コレクターに送信します。Deploymentメトリック コレクターは、構成で指定された構成済みのシンクに要求されたデータを転送します。中央コレクターは、構成済みのシンクの 1 つであり、メトリック コレクターからこのデータを再入力します。 -
中央コレクター: このコンポーネントはアグリゲータとして機能し、メトリック コレクターを介してクラスター内のすべてのノードから受信したデータを保存します。中央コレクターは、コンシューマがクラスター内のノードに対してこのデータを要求するために使用する gRPC エンドポイントを公開します。例えば、 は、
contrail-schedulerこれらのgRPCエンドポイントを使用して、ネットワークメトリックを取得して処理し、それに応じてポッドをスケジュールします。 -
Contrail スケジューラ:このカスタム スケジューラには、次の 3 つのカスタム プラグインが導入されています。
-
VMICapacityプラグイン(リリース 22.4 以降から利用可能):スケジューラ フレームワークにフィルター、スコア、拡張NormalizeScoreポイントを実装します。これらのcontrail-scheduler拡張ポイントを使用して、アクティブなVPIに基づいてポッドを割り当てる最適なノードを決定します。 FlowsCapacityプラグイン:ノード内のアクティブフローの数に基づいてポッドをスケジュールするのに最適なノードを決定します。ノード上のトラフィックフローが多すぎると、新しいポッドトラフィックの競争が激しくなります。フロー数が低いポッドとノードは、スケジューラによって上位にランク付けされます。-
BandwidthUsageプラグイン:ノードの帯域幅使用量に基づいてポッドを割り当てるための最適なノードを決定します。1 秒あたりの帯域幅使用量(進行中および送信トラフィック)が最も少なくなったノードは、最も高いランクです。メモ：設定したプラグインに応じて、各プラグインはスコアをスケジューラーに送信します。スケジューラーは、すべてのプラグインから加重スコアを取得し、ポッドをスケジュールするのに最適なノードを見つけます。
-
ネットワーク対応ポッドスケジューリングコンポーネントの導入
ネットワーク対応ポッドスケジューリング用のコンポーネントの展開については、以下のセクションを参照してください。メトリックコレクターの導入
CN2には、デフォルトでvRouterポッド導入にメトリックコレクターが含まれています。 agent: default: vRouter仕様のフィールドには、 collectors: メトリックコレクターの再シーバーアドレスで設定されたフィールドが含まれています。以下の例は、 の値 collectors: - localhost: 6700を示しています。メトリックコレクターはvRouterエージェントと同じポッドで実行されるため、ポートを介して localhost 通信できます。ポート 6700 はメトリック コレクターの再切り替えアドレスとして固定されており、変更できません。vRouter エージェントはメトリック データをこのアドレスに送信します。
以下に、コレクターを有効にしたデフォルトの vRouter 導入のセクションを示します。
apiVersion: dataplane.juniper.net/v1
kind: Vrouter
metadata:
name: contrail-vrouter-nodes
namespace: contrail
spec:
agent:
default:
collectors:
- localhost:6700
xmppAuthEnable: true
sandesh:
introspectSslEnable: true
一元的なコレクターの導入
中央コレクター の配置 オブジェクトは、常に レプリカ 数が 1 に設定されている必要があります。以下 Deployment のセクションでは、例を示します。
spec:
selector:
matchLabels:
component: central-collector
replicas: 1
template:
metadata:
labels:
component: central-collector
configMap は、クラスター内のポッドにキー値設定データを提供します。一元的なコレクター構成用 の を
configMap作成します。この設定はコンテナにマウントされます。
以下に、一元的なコレクター構成ファイルの例を示します。
http_port: 9090 tls_config: key_file: /etc/config/server.key cert_file: /etc/config/server.crt ca_file: /etc/config/ca.crt service_name: central-collector.contrail metric_configmap: name: mc_configmap namespace: contrail key: config.yaml
この設定ファイルには、以下のフィールドが含まれています。
-
http_port: 中央コレクター gRPC サービスが実行するポートを指定します。 -
tls_config: 何server_nameに関連付けられた一元的なkey_fileコレクター サービスを指定します。このフィールドには、アップストリーム(ノースバウンド API)サーバー情報が含まれています。 -
service_name: 中央コレクターが公開するサービスの名前を指定します。この場合、central-collector.contrail中央コレクターDeploymentの上にサービスとして公開されます。クラスター内のコンシューマは、このサービス名を使用して中央コレクターと対話できます。 -
metric_configmap: このセクションのフィールドは、メトリック コレクターconfigMapの詳細を示します。中央コレクターは、この情報を使用して、シンクが受信する必要なメトリックをメトリック コレクター シンクを構成します。以下は、 を作成するためのサンプル コマンドですconfigMap。kubectl create cm -n contrail central-collector-config –from-file=config.yaml=<path-to-config-file>
中央コレクター Deploymentの例を次に示します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: central-collector
namespace: contrail
labels:
app: central-collector
spec:
replicas: 1
selector:
matchLabels:
app: central-collector
template:
metadata:
labels:
app: central-collector
spec:
securityContext:
fsGroup: 2000
runAsGroup: 3000
runAsNonRoot: true
runAsUser: 1000
containers:
- name: contrail-scheduler
image: enterprise-hub.juniper.net/contrail-container-prod/central-collector:latest
command:
- /central-collector
- --kubeconfig=/tmp/config/kubeconfig
- --config=/etc/central-collector/config.yaml
imagePullPolicy: Always
volumeMounts:
- mountPath: /tmp/config
name: kubeconfig
readOnly: true
- mountPath: /etc/central-collector
name: central-collector-config
readOnly: true
- mountPath: /etc/config/tls
name: tls
readOnly: true
volumes:
- name: kubeconfig
secret:
secretName: cc-kubeconfig
- name: tls
secret:
secretName: central-collector-tls
- name: central-collector-config
configMap:
name: central-collector-config
導入する前に volume 、 と volumeMounts fied を検証します。
中央コレクター サービスは、オブジェクトの上に Deployment 公開されます。次の YAML ファイルは、中央コレクター サービス ファイルの例です。
apiVersion: v1
kind: Service
metadata:
name: central-collector
namespace: contrail
spec:
selector:
component: central-collector
ports:
- name: grpc
port: <port-as-per-config>
- name: json
protocol: TCP
port: 10000
フィールドは、 name 一元的なコレクター構成で指定されたサービス名と一致する必要があります。名前空間は、中央コレクターの配置の名前空間と一致する必要があります。例えば、 namespace: contrail.
Contrail スケジューラの導入
次の手順を実行して、以下を展開します contrail-scheduler。
- の名前空間を作成します
contrail-scheduler。kubectl create ns contrail-scheduler
-
オブジェクト(必須)を
ServiceAccount作成し、 のクラスターロールを設定しますServiceAccount。クラスターServiceAccount内のポッドまたはコンポーネントにロールを割り当てます。この場合、 フィールドkind: ClusterRoleに、デフォルトのcontrail-schedulerServiceAccountKubernetes スケジューラ(kube-scheduler)とname: system:kube-scheduler同じ権限を付与します。 -
configMapVMI プラグイン構成用の を作成します。と同じ名前空間を作成configMapするcontrail-schedulerDeployment必要があります。kubectl create configmap vmi-config -n contrail-scheduler --from-file=vmi-config=<path-to-vmi-config>
以下に、VMIプラグインの構成例を示します。
nodeLabels: "test-agent-mode": "dpdk" maxVMICount: 64 address: "central-collector.contrail:9090"
-
ファイルの を
Secret作成しますkubeconfig。このファイルは、 にSecretsマウントされたボリューム内のcontrail-schedulerDeploymentファイルまたはコンテナー環境変数として機密データを格納します。kubectl create secret generic kubeconfig -n contrail-scheduler --from-file=kubeconfig=<path-to-kubeconfig-file>
configMapコンフィグ用にcontrail-schedulerを作成します。kubectl create configmap scheduler-config -n contrail-scheduler --from-file=scheduler-config=<path-to-scheduler-config>
スケジューラ構成の例を以下に示します。
apiVersion: kubescheduler.config.k8s.io/v1 clientConnection: acceptContentTypes: "" burst: 100 contentType: application/vnd.kubernetes.protobuf kubeconfig: /tmp/config/kubeconfig qps: 50 enableContentionProfiling: true enableProfiling: true kind: KubeSchedulerConfiguration leaderElection: leaderElect: false profiles: - schedulerName: contrail-scheduler pluginConfig: - args: apiVersion: kubescheduler.config.k8s.io/v1 kind: VMICapacityArgs config: /tmp/vmi/config.yaml name: VMICapacity - args: apiVersion: kubescheduler.config.k8s.io/v1 kind: FlowsCapacityArgs address: central-collector.contrail:9090 name: FlowsCapacity - args: apiVersion: kubescheduler.config.k8s.io/v1 kind: BandwidthUsageArgs address: central-collector.contrail:9090 name: BandwidthUsage plugins: multiPoint: enabled: - name: VMICapacity weight: 50 - name: FlowsCapacity weight: 1 - name: BandwidthUsage weight: 20以下のフィールドに注意してください。
-
schedulerName: デプロイするスケジューラーの名前。 -
pluginConfig:展開に含まれるプラグインに関する情報がcontrail-scheduler含まれています。この展開には、以下のプラグインが含まれています。-
VMICapacity -
FlowsCapacity -
BandwidthUsage
-
-
config:このフィールドには、VMI プラグイン設定がマウントされているファイルパスが含まれています。 -
multiPoint:含まれている各プラグインの拡張ポイントを有効にできます。プラグインの特定の拡張ポイントを有効にする代わりに、multiPointフィールドを特定のプラグイン用に開発されたすべての拡張ポイントを有効または無効にしてみましょう。プラグインの重みは、プラグインから特定のスコアの優先度を決定します。これは、採点の最後に、すべてのプラグインが重み付きスコアを送信することを意味します。ポッドは、集約されたスコアが最も高いノードでスケジュールされます。
-
-
. を作成します
contrail-schedulerDeployment。以下は、 の例ですDeployment。apiVersion: apps/v1 kind: Deployment metadata: name: contrail-scheduler namespace: contrail-scheduler labels: app: scheduler spec: replicas: 1 selector: matchLabels: app: scheduler template: metadata: labels: app: scheduler spec: serviceAccountName: contrail-scheduler securityContext: fsGroup: 2000 runAsGroup: 3000 runAsNonRoot: true runAsUser: 1000 containers: - name: contrail-scheduler image: <registry>/contrail-scheduler:<tag> command: - /contrail-scheduler - --authentication-kubeconfig=/tmp/config/kubeconfig - --authorization-kubeconfig=/tmp/config/kubeconfig - --config=/tmp/scheduler/scheduler-config - --secure-port=10271 imagePullPolicy: Always livenessProbe: failureThreshold: 8 httpGet: path: /healthz port: 10271 scheme: HTTPS initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 30 resources: requests: cpu: 100m startupProbe: failureThreshold: 24 httpGet: path: /healthz port: 10271 scheme: HTTPS initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 30 volumeMounts: - mountPath: /tmp/config name: kubeconfig readOnly: true - mountPath: /tmp/scheduler name: scheduler-config readOnly: true - mountPath: /tmp/vmi name: vmi-config readOnly: true hostPID: false volumes: - name: kubeconfig secret: secretName: kubeconfig - name: scheduler-config configMap: name: scheduler-config - name: vmi-config configMap: name: vmi-config
これを Deployment適用すると、新しい contrail-scheduler ファイルがアクティブになります。
Contrailスケジューラを使用してポッドを展開する
新しいポッドをスケジュールする(デプロイする)を使用contrail-schedulerするフィールドに、自分contrail-schedulerschedulerNameの名前を入力します。定義されたポッド マニフェストの例を次にschedulerName示します。
apiVersion: v1
kind: Pod
metadata:
name: my-app
labels:
app: web
spec:
schedulerName: contrail-scheduler
containers:
- name: app
image: busybox
command:
- sh
- -c
- sleep 500