30.2. MetalLB Operator のインストール
クラスター管理者は、Operator がクラスター上の MetalLB インスタンスのライフサイクルを管理できるようにする MetallB Operator を追加できます。
MetalLB および IP フェイルオーバーは互換性がありません。クラスターの IP フェイルオーバーを設定している場合、Operator をインストールする前に IP フェイルオーバーを削除する 手順を実行します。
30.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
30.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.11.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.11.0-nnnnnnnnnnnn Succeeded
30.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 が表示されることを確認します。
30.2.3.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 を制限することもできます。アフィニティールール、テイント、および容認の詳細は、追加のリソースを参照してください。