32.2. MetalLB Operator のインストール
クラスター管理者は、Operator がクラスター上の MetalLB インスタンスのライフサイクルを管理できるようにする MetallB Operator を追加できます。
MetalLB および IP フェイルオーバーは互換性がありません。クラスターの IP フェイルオーバーを設定している場合、Operator をインストールする前に IP フェイルオーバーを削除する 手順を実行します。
32.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
となっていることを確認してください。
Operator が正常にインストールされない場合は、Operator のステータスを確認し、ログを確認してください。
-
Operators → Installed Operators ページに移動し、
Status
列でエラーまたは失敗の有無を確認します。 -
Workloads → Pods ページに移動し、問題を報告している
openshift-operators
プロジェクトの Pod のログを確認します。
-
Operators → Installed Operators ページに移動し、
32.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.12.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.12.0-nnnnnnnnnnnn Succeeded
32.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 コントローラーのデプロイメントと、BareLB スピーカーのデーモンセットが実行していることを確認します。
コントローラーのデプロイメントが稼働していることを検証します。
$ 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 が表示されることを確認します。
32.2.4. MetalLB のデプロイメント仕様
MetalLB
カスタムリソースを使用して MetalLB のインスタンスを起動すると、MetalLB
カスタムリソースでデプロイメント仕様を設定して、controller
または speaker
Pod がクラスターにデプロイし、実行する方法を管理できます。これらのデプロイメント仕様を使用して、以下のタスクを管理します。
- MetalLB Pod デプロイメントのノードの選択
- Pod の優先順位および Pod のアフィニティーを使用してたケジューリングの管理
- MetalLB Pod の CPU 制限の割り当て
- MetalLB Pod のコンテナー RuntimeClass の割り当て
- MetalLB Pod のメタデータの割り当て
32.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 をスケジュールするか、またはスケジュールしないかを制御することができます。また、容認の一覧を適用してこれらの Pod を制限することもできます。アフィニティールール、テイント、および容認の詳細は、追加のリソースを参照してください。
32.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 がインストールされている。
手順
myPriorityClass.yaml
などのPriorityClass
カスタムリソースを作成して、優先度レベルを設定します。この例では、優先度の高いクラスを使用しています。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 runtimeClassName: myclass speakerConfig: priorityClassName: high-priority runtimeClassName: myclass affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: app: metallb topologyKey: kubernetes.io/hostname
MetalLB
カスタムリソース設定を適用します。$ oc apply -f MetalLBPodConfig.yaml
検証
namespace 内の Pod に割り当てた優先度クラスを表示するには、次のコマンドを実行して
<namespace>
をターゲットの namespace に置き換えます。$ oc get pods -n <namespace> -o custom-columns=NAME:.metadata.name,PRIORITY:.spec.priorityClassName
スケジューラーが Pod アフィニティールールに従って Pod を配置したことを確認するには、次のコマンドを実行して Pod のノードのメタデータを表示し、
<namespace>
をターゲットの namespace に置き換えます。$ oc get pod -o=custom-columns=NODE:.spec.nodeName,NAME:.metadata.name -n <namespace>
32.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>
32.2.4.4. MetalLB デプロイメントでのコンテナーランタイムクラスの設定
必要に応じて、MetalLB
カスタムリソースを設定して、コンテナーランタイムクラスを controller
Pod および speaker
Pod に割り当てることができます。たとえば、Windows ワークロードでは、Windows ランタイムクラスを Pod に割り当てることができ、Pod のすべてのコンテナーに対してこのランタイムクラスが使用されるようになります。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。 - MetalLB Operator がインストールされている。
手順
myRuntimeClass.yaml
などのRuntimeClass
カスタムリソースを作成して、ランタイムクラスを定義します。apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: myclass handler: myconfiguration
RuntimeClass
カスタムリソース設定を適用します。$ oc apply -f myRuntimeClass.yaml
MetalLBRuntime.yaml
などのMetalLB
カスタムリソースを作成して、runtimeClassName
値を指定します。apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb-system spec: logLevel: debug controllerConfig: runtimeClassName: myclass annotations: 1 controller: demo speakerConfig: runtimeClassName: myclass annotations: 2 speaker: demo
MetalLB
カスタムリソース設定を適用します。$ oc apply -f MetalLBRuntime.yaml
検証
Pod のコンテナーランタイムを表示するには、以下のコマンドを実行します。
$ oc get pod -o custom-columns=NAME:metadata.name,STATUS:.status.phase,RUNTIME_CLASS:.spec.runtimeClassName