このページで
DPDK ノードでの制御ポッド スケジューリング
概要 クラウドネイティブのContrail Networkingリリース22.2は、ノードインターフェイス容量に基づいてポッドをスケジュールするカスタムプラグインをサポートしています。このプラグインは、ポッド割り当てに最適なDPDKノードをフィルタリングして選択する複数のAPIで構成されています。
Kubernetesでのポッドスケジューリング
Kubernetesでは、スケジューラーがノード割り当てのないポッドの新しく作成されたポッドを監視します。スケジューラーは、フィルタリングフェーズとスコアリングフェーズを使用して、これらのポッドを適切なノードに割り当てようとします。潜在的なノードは、ポッドのリソース要件などの属性に基づいてフィルタリングされます。ノードにポッドに使用可能なリソースがない場合、そのノードは除外されます。複数のノードがフィルタリングフェーズに合格した場合、Kubernetesは特定のポッドに対する適合性に基づいて残りのノードをスコアし、ランク付けします。スケジューラーは、ランキングが最も高いノードにポッドを割り当てます。2 つのノードのスコアが同じ場合、スケジューラーはランダムにノードを選択します。
Kubernetes スケジューリング フレームワークの概要
Kubernetes Scheduling Framework は、拡張スケジューリング機能のために、デフォルトのクラスタ スケジューラに新しいスケジューリング API を追加します。フレームワークは、各ポッドのスケジューリングサイクルとバインディングサイクルを実行します。スケジューリング・サイクルはポッドに最適なノードを選択し、その決定はバインディング・サイクルによってクラスターに適用されます。スケジューリングサイクルとバインディングサイクルは、個々のサイクルの過程で、いくつかの拡張ポイントを公開します。プラグインは、さまざまな拡張ポイントで呼び出すために登録されています。たとえば、スケジュール サイクル中に、公開されている拡張ポイントの 1 つがフィルターと呼ばれます。スケジューリングサイクリングがフィルター拡張ポイントに達すると、フィルタープラグインがフィルタリングタスクを実行するように呼び出されます。
Contrail カスタム スケジューラの概要
クラウドネイティブのContrail Networkingは、高スループットアプリケーション向けのDPDKノードの導入をサポートします。DPDK ノードには、デフォルトで 32 個の VMI(仮想マシン インターフェイス)制限があります。これは、DPDKノードが最大32個のポッドをホストしていることを意味します。Kubernetes のデフォルト スケジューラは、現在、DPDK ノードの要件と制限を認識するためのメカニズムをサポートしていません。その結果、クラウドネイティブのContrail Networkingは、Kubernetesスケジューリングフレームワーク上に構築されたカスタムスケジューラを提供し、DPDKノードでポッドスケジューリングをサポートするプラグインを実装 VMICapacity します。
クラウドネイティブのContrail NetworkingにおけるContrailカスタムスケジューラの実装
クラウドネイティブのContrail Networkingカスタムスケジューラは、スケジューラフレームワークにフィルター、スコア、拡張NormalizeScoreポイントを実装するプラグインをサポートVMICapacityしています。これらの拡張ポイントの詳細については、以下のセクションを参照してください。
フィルター
これらのプラグインは、ポッドを実行できないノードを除外します。ノードは VMI 容量に基づいてフィルタリングされます。ノードに割り当てられたポッドの最大数がある場合、そのノードは除外され、スケジューラーはそのノードでポッドを使用不能とマークします。このフェーズでは、DPDK ノードを識別するユーザー設定 nodeLabels に基づいて、非 DPDK ノードも除外されます。
スコア
これらのプラグインは、フィルタリング・フェーズに合格したノードをランク付けします。スケジューラーは、ノードごとに一連のスコアリング プラグインを呼び出します。クラウドネイティブのContrail Networkingでは、ノードのスコアは、ノードで現在アクティブになっているVPIの数に基づいています。フィルター ステージにパスするノードが 1 つだけの場合、スコアおよび NormalizeScore 拡張ポイントはスキップされ、スケジューラがそのノードにポッドを割り当てます。
スコアの正規化
スケジューラが最終的なノードランキングを計算する前に、これらのプラグインはノードスコアを変更します。ノード上のアクティブな VMI の数によって、そのノードのスコアが決まります。アクティブな VMI の数が多いほど、スコアが低くなります。また、その逆も同様です。スコアは 0~100 の範囲で正規化されます。フェーズ後 NormalizeScore 、スケジューラーは、スケジューラー構成で定義された構成済みプラグインの重さに従って、すべてのプラグインのノード・スコアを結合します。
セカンダリ スケジューリング フレームワークとしての Kubernetes スケジューリング フレームワークの導入
以下の高レベルの手順に従って、Contrail カスタム スケジューラを、デフォルトの Kubernetes スケジューラと共に実行されるセカンダリ スケジューラとして導入します。
- カスタム スケジューラの設定ファイルを作成します。
- スケジューラ設定に適切なボリュームマウントとフラグを使用して、バニラデプロイメントを作成します。
- カスタムスケジューラをスケジュールするポッドを確認します。
詳細については、以下のセクションを参照してください。
カスタム スケジューラの設定ファイルを作成する
カスタム スケジューラには、 kubeconfig スケジューラ設定ファイルと スケジューラー設定ファイルが必要です。次のサンプル スケジューラ設定ファイルを検討してください。
apiVersion: kubescheduler.config.k8s.io/v1beta3
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:
- pluginConfig:
- args:
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: VMICapacityArgs
maxVMICount: 32
nodeLabels:
agent-mode: dpdk
name: VMICapacity
plugins:
filter:
enabled:
- name: VMICapacity
weight: 0
score:
enabled:
- name: VMICapacity
weight: 0
schedulerName: contrail-scheduler
以下のフィールドに注意してください。
schedulerName:カスタム スケジューラの名前。この名前は、クラスターに固有である必要があります。このスケジューラを使用してポッドをスケジュールする場合は、このフィールドを定義する必要があります。kubeconfig:ポッドのkubeconfigファイルシステムにマウントされたファイルへのパス。maxVMICount: DPDK ノードが対応する VMI の最大数。nodeLabels:DPDK ノードのグループを識別する一連のラベル。VMICapacity:Kubernetes が DPDK ノードの VMI 容量を決定できるようにするプラグインの名前。
スケジューラの設定に適切なボリュームマウントとフラグを使用して、バニラ導入を作成する
1 つのノードでスケジューラ導入のインスタンスが複数実行されていないことを確認すると、ポートの競合が発生します。高可用性(HA)要件が必要な場合は、ノード ・アフィニティ・ルール または DaemonSet を使用して、スケジューラーの複数のインスタンスを別のノードで実行します。リーダーの選択を有効にするには、必要に応じてスケジューラの設定を変更します。リーダーの選出の詳細については、以下の Kubernetes 記事「 複数スケジューラの設定」の「リーダー選択を有効にする」を参照してください。
次の YAML ファイルは、スケジューラの導入例を示しています。
スケジューラデプロイYAMLを起動する前に、スケジューラの名前空間を作成する必要があります。スケジューラは、作成した名前空間の下で動作します。
apiVersion: v1
kind: ServiceAccount
metadata:
name: contrail-scheduler
namespace: scheduler
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: contrail -scheduler
subjects:
- kind: ServiceAccount
name: contrail -scheduler
namespace: scheduler
roleRef:
kind: ClusterRole
name: system:kube-scheduler
apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: contrail-scheduler
namespace: 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: <scheduler-image>
command:
- /contrail-scheduler
- --kubeconfig=/tmp/config/kubeconfig
- --authentication-kubeconfig=/tmp/config/kubeconfig
- --authorization-kubeconfig=/tmp/config/kubeconfig
- --config=/tmp/scheduler/scheduler-config
- --secure-port=<metrics-port; defaults to 10259>
livenessProbe:
failureThreshold: 8
httpGet:
path: /healthz
port: <secure-port>
scheme: HTTPS
initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 15
resources:
requests:
cpu: 100m
readinessProbe:
failureThreshold: 8
httpGet:
path: /healthz
port: <secure-port>
scheme: HTTPS
initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 15
volumeMounts:
- mountPath: /tmp/config
name: kubeconfig
readOnly: true
- mountPath: /tmp/scheduler
name: scheduler-config
readOnly: true
hostNetwork: false
hostPID: false
volumes:
- name: kubeconfig
<volume for kubeconfig file>
- name: scheduler-config
<volume for scheduler configuration file>
カスタムスケジューラをスケジュールするポッドを確認する
次のポッドマニフェストは、セカンダリスケジューラを使用したポッド導入の例を示しています。
apiVersion: v1
kind: Pod
metadata:
name: test-pod
spec:
schedulerName: contrail-scheduler
containers:
- name: test
image: busybox:latest
command: ["/bin/sh","-c", "while true; do echo hello; sleep 10;done"]
の点に注意してください schedulerName。このフィールドは、ポッドを展開する際に使用するスケジューラをKubernetesに伝えます。デプロイする各ポッドのマニフェストで、このフィールドを定義する必要があります。指定されたスケジューラがクラスタに存在しない場合、ポッドの導入状態は保留中のままになります。