33.2. MetalLB Operator のインストール
クラスター管理者は、Operator がクラスター上の MetalLB インスタンスのライフサイクルを管理できるようにする MetallB Operator を追加できます。
MetalLB および IP フェイルオーバーは互換性がありません。クラスターの IP フェイルオーバーを設定している場合、Operator をインストールする前に IP フェイルオーバーを削除する 手順を実行します。
33.2.1. Web コンソールを使用した OperatorHub からの MetalLB Operator のインストール
クラスター管理者は、OpenShift Container Platform Web コンソールを使用して MetalLB Operator をインストールできます。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
-
OpenShift Container Platform Web コンソールで、Operators
OperatorHub ページに移動します。 キーワードを Filter by keyword ボックスに入力するか、目的の Operator までスクロールします。たとえば、
metallb
と入力して MetalLB Operator を見つけます。また、インフラストラクチャー機能 でオプションをフィルターすることもできます。たとえば、非接続環境 (ネットワークが制限された環境ともしても知られる) で機能する Operator を表示するには、Disconnected を選択します。
- Install Operator ページで、デフォルトを受け入れて Install をクリックします。
検証
インストールが正常に行われたことを確認するには、以下を実行します。
-
Operators
Installed Operators ページに移動します。 -
Operator が
openshift-operators
の namespace 内に設置されていることと、その状態がSucceeded
となっていることを確認してください。
-
Operators
Operator が正常にインストールされない場合は、Operator のステータスを確認し、ログを確認してください。
-
Operators
Installed Operators ページに移動し、 Status
列でエラーまたは失敗の有無を確認します。 -
Workloads
Podsページにナビゲートし、問題を報告している openshift-operators
プロジェクトの Pod のログを確認します。
-
Operators
33.2.2. CLI を使用した OperatorHub からのインストール
OpenShift Container Platform Web コンソールを使用する代わりに、CLI を使用して OperatorHub から Operator をインストールできます。OpenShift CLI (oc
) を使用して、MetalLB Operator をインストールできます。
CLI を使用する場合は、metallb-system
namespace に Operator をインストールすることを推奨します。
前提条件
- ベアメタルハードウェアにインストールされたクラスター。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
次のコマンドを入力して、MetalLB Operator の namespace を作成します。
$ cat << EOF | oc apply -f - apiVersion: v1 kind: Namespace metadata: name: metallb-system EOF
namespace に Operator グループのカスタムリソースを作成します。
$ cat << EOF | oc apply -f - apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: metallb-operator namespace: metallb-system EOF
Operator グループが namespace にインストールされていることを確認します。
$ oc get operatorgroup -n metallb-system
出力例
NAME AGE metallb-operator 14m
Subscription
CR を作成します。Subscription
CR を定義し、YAML ファイルを保存します (例:metallb-sub.yaml
)。apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: metallb-operator-sub namespace: metallb-system spec: channel: stable name: metallb-operator source: redhat-operators 1 sourceNamespace: openshift-marketplace
- 1
redhat-operators
値を指定する必要があります。
Subscription
CR を作成するには、次のコマンドを実行します。$ oc create -f metallb-sub.yaml
オプション: BGP および BFD メトリックが Prometheus に表示されるようにするには、次のコマンドのように namespace にラベルを付けることができます。
$ oc label ns metallb-system "openshift.io/cluster-monitoring=true"
検証
検証手順は、MetallB Operator が metallb-system
namespace にインストールされていることを前提としています。
インストール計画が namespace にあることを確認します。
$ oc get installplan -n metallb-system
出力例
NAME CSV APPROVAL APPROVED install-wzg94 metallb-operator.4.13.0-nnnnnnnnnnnn Automatic true
注記Operator のインストールには数秒かかる場合があります。
Operator がインストールされていることを確認するには、以下のコマンドを入力します。
$ oc get clusterserviceversion -n metallb-system \ -o custom-columns=Name:.metadata.name,Phase:.status.phase
出力例
Name Phase metallb-operator.4.13.0-nnnnnnnnnnnn Succeeded
33.2.3. クラスターでの MetalLB の起動
Operator のインストール後に、MetalLB カスタムリソースの単一のインスタンスを設定する必要があります。カスタムリソースの設定後、Operator はクラスターで MetalLB を起動します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - MetalLB Operator がインストールされている。
手順
この手順は、MetallB Operator が metallb-system
namespace にインストールされていることを前提としています。Web コンソールを使用してインストールした場合は、namespace の代わりに openshift-operators
を使用してください。
MetalLB カスタムリソースの単一のインスタンスを作成します。
$ cat << EOF | oc apply -f - apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb-system EOF
検証
MetalLB コントローラーのデプロイメントと、MetalLB スピーカーのデーモンセットが実行していることを確認します。
コントローラーのデプロイメントが稼働していることを検証します。
$ oc get deployment -n metallb-system controller
出力例
NAME READY UP-TO-DATE AVAILABLE AGE controller 1/1 1 1 11m
スピーカーに設定されているデーモンが実行されていることを検証します。
$ oc get daemonset -n metallb-system speaker
出力例
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE speaker 6 6 6 6 6 kubernetes.io/os=linux 18m
この出力例は、6 つの speaker Pod を示しています。クラスターの speaker Pod の数は出力例とは異なる場合があります。出力で各ノードの 1 つの Pod が表示されることを確認します。
33.2.4. MetalLB のデプロイメント仕様
MetalLB
カスタムリソースを使用して MetalLB のインスタンスを起動すると、MetalLB
カスタムリソースでデプロイメント仕様を設定して、controller
または speaker
Pod がクラスターにデプロイし、実行する方法を管理できます。これらのデプロイメント仕様を使用して、以下のタスクを管理します。
- MetalLB Pod デプロイメントのノードの選択
- Pod の優先順位および Pod のアフィニティーを使用してたケジューリングの管理
- MetalLB Pod の CPU 制限の割り当て
- MetalLB Pod のコンテナー RuntimeClass の割り当て
- MetalLB Pod のメタデータの割り当て
33.2.4.1. speaker Pod の特定のノードへの限定
デフォルトでは、MetalLB Operator を使用して MetalLB を開始すると、Operator はクラスター内の各ノードでspeaker
Pod のインスタンスを開始します。ロードバランサーの IP アドレスをアドバタイズできるのは、speaker
Pod を備えたノードのみです。ノードセレクターを使用して MetalLB
カスタムリソースを設定し、speaker
Pod を実行するノードを指定できます。
speaker
Pod を特定のノードに制限する最も一般的な理由として、特定のネットワークにネットワークインターフェイスがあるノードのみがロードバランサーの IP アドレスをアドバタイズするようにすることが挙げられます。ロードバランサーの IP アドレスの宛先として、speaker
Pod が実行されているノードのみがアドバタイズされます。
speaker
Pod を特定のノードに制限し、サービスの外部トラフィックポリシーにローカル
を指定する場合は、サービスのアプリケーション Pod が同じノードにデプロイされていることを確認する必要があります。
speaker Pod をワーカーノードに制限する設定例
apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb-system spec: nodeSelector: <.> node-role.kubernetes.io/worker: "" speakerTolerations: <.> - key: "Example" operator: "Exists" effect: "NoExecute"
<.> 設定例では、スピーカー Pod をワーカーノードに割り当てるように指定していますが、ノードまたは任意の有効なノードセレクターに割り当てたラベルを指定できます。<.> この設定例では、この容認がアタッチされている Pod は、operator
を使用して キー
値と effect
値に一致するテイントを容認します。
spec.nodeSelector
フィールドを使用してマニフェストを適用した後に、oc get daemonset -n metallb-systemspeaker
コマンドを使用して Operator がデプロイした Pod の数を確認できます。同様に、oc get node -l node-role.kubernetes.io/worker =
のようなコマンドを使用して、ラベルに一致するノードを表示できます。
オプションで、アフィニティールールを使用して、ノードがどの speaker Pod をスケジュールするか、スケジュールしないかを制御することができます。また、toleration の一覧を適用してこれらの Pod を制限することもできます。アフィニティールール、テイント、および容認の詳細は、追加のリソースを参照してください。
33.2.4.2. MetalLB デプロイメントでの Pod の優先順位および Pod アフィニティーの設定
オプションで、MetalLB
カスタムリソースを設定して、Pod の優先順位と Pod のアフィニティールールを controller
Pod および speaker
Pod に割り当てることができます。Pod の優先順位は、ノード上の Pod の相対的な重要度を示し、この優先順位に基づいて Pod をスケジュールします。controller
または speaker
Pod に高い優先順位を設定して、ノード上の他の Pod よりも優先的にスケジューリングされるようにします。
Pod のアフィニティーは Pod 間の関係を管理します。Pod のアフィニティーを controller
または speaker
Pod に割り当て、スケジューラーが Pod 関係のコンテキストで Pod を配置するノードを制御します。たとえば、Pod アフィニティールールを使用して、複数の特定 Pod を同じノードまたは別のノードに配置するようにできます。これにより、ネットワーク通信が改善され、これらのコンポーネント間の遅延が縮小されます。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。 - MetalLB Operator がインストールされている。
- クラスター上で MetalLB Operator を開始している。
手順
myPriorityClass.yaml
などのPriorityClass
カスタムリソースを作成して、優先度レベルを設定します。この例では、high-priority
という名前のPriorityClass
を、値1000000
で定義します。この優先クラスが割り当てられた Pod は、スケジューリングにおいて、それより低い優先クラスの Pod より優先順位が高いとみなされます。apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 1000000
PriorityClass
カスタムリソース設定を適用します。$ oc apply -f myPriorityClass.yaml
MetalLBPodConfig.yaml
などのMetalLB
カスタムリソースを作成して、priorityClassName
とpodAffinity
の値を指定します。apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb-system spec: logLevel: debug controllerConfig: priorityClassName: high-priority 1 affinity: podAffinity: 2 requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: app: metallb topologyKey: kubernetes.io/hostname speakerConfig: priorityClassName: high-priority affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: app: metallb topologyKey: kubernetes.io/hostname
- 1
- MetalLB コントローラー Pod の優先クラスを指定します。この場合、
high-priority
に設定されます。 - 2
- Pod アフィニティールールを設定していることを指定します。これらのルールは、他の Pod またはノードに関連して Pod がどのようにスケジュールされるかを決定します。この設定は、
app: metallb
ラベルを持つ Pod を同じホスト名を共有するノードにスケジュールするようにスケジューラーに指示します。これは、MetalLB 関連の Pod を同じノード上に配置するのに役立ち、これらの Pod 間のネットワーク通信、遅延、リソース使用量を最適化できる可能性があります。
MetalLB
カスタムリソース設定を適用します。$ oc apply -f MetalLBPodConfig.yaml
検証
metallb-system
namespace の Pod に割り当てた優先クラスを表示するには、次のコマンドを実行します。$ oc get pods -n metallb-system -o custom-columns=NAME:.metadata.name,PRIORITY:.spec.priorityClassName
出力例
NAME PRIORITY controller-584f5c8cd8-5zbvg high-priority metallb-operator-controller-manager-9c8d9985-szkqg <none> metallb-operator-webhook-server-c895594d4-shjgx <none> speaker-dddf7 high-priority
スケジューラーが Pod アフィニティールールに従って Pod を配置したことを確認するには、次のコマンドを実行して Pod のノードのメタデータを表示します。
$ oc get pod -o=custom-columns=NODE:.spec.nodeName,NAME:.metadata.name -n metallb-system
33.2.4.3. MetalLB デプロイメントでの Pod CPU 制限の設定
オプションで、MetalLB
カスタムリソースを設定することで、Pod の CPU 制限を controller
Pod と speaker
Pod に割り当てることができます。controller
Pod または speaker
Pod の CPU 制限を定義すると、ノード上のコンピュートリソースを管理するのに役立ちます。これにより、ノード上のすべての Pod に、ワークロードとクラスターのハウスキーピングを管理するために必要なコンピューティングリソースが確保されます。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。 - MetalLB Operator がインストールされている。
手順
CPULimits.yaml
などのMetalLB
カスタムリソースファイルを作成し、コントローラー
およびspeaker
Pod のcpu
値を指定します。apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb-system spec: logLevel: debug controllerConfig: resources: limits: cpu: "200m" speakerConfig: resources: limits: cpu: "300m"
MetalLB
カスタムリソース設定を適用します。$ oc apply -f CPULimits.yaml
検証
Pod のコンピューティングリソースを表示するには、次のコマンドを実行し、
<pod_name>
をターゲット Pod に置き換えます。$ oc describe pod <pod_name>