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 権限を持つユーザーとしてログインしている。

手順

  1. OpenShift Container Platform Web コンソールで、Operators OperatorHub ページに移動します。
  2. キーワードを Filter by keyword ボックスに入力するか、目的の Operator までスクロールします。たとえば、metallb と入力して MetalLB Operator を見つけます。

    また、インフラストラクチャー機能 でオプションをフィルターすることもできます。たとえば、非接続環境 (ネットワークが制限された環境ともしても知られる) で機能する Operator を表示するには、Disconnected を選択します。

  3. Install Operator ページで、デフォルトを受け入れて Install をクリックします。

検証

  1. インストールが正常に行われたことを確認するには、以下を実行します。

    1. Operators Installed Operators ページに移動します。
    2. Operator が openshift-operators の namespace 内に設置されていることと、その状態が Succeeded となっていることを確認してください。
  2. Operator が正常にインストールされない場合は、Operator のステータスを確認し、ログを確認してください。

    1. Operators Installed Operators ページに移動し、Status 列でエラーまたは失敗の有無を確認します。
    2. Workloads Podsページにナビゲートし、問題を報告している openshift-operators プロジェクトの Pod のログを確認します。

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 権限を持つユーザーとしてログインしている。

手順

  1. 次のコマンドを入力して、MetalLB Operator の namespace を作成します。

    $ cat << EOF | oc apply -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: metallb-system
    EOF
  2. namespace に Operator グループのカスタムリソースを作成します。

    $ cat << EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: metallb-operator
      namespace: metallb-system
    EOF
  3. Operator グループが namespace にインストールされていることを確認します。

    $ oc get operatorgroup -n metallb-system

    出力例

    NAME               AGE
    metallb-operator   14m

  4. Subscription CR を作成します。

    1. 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 値を指定する必要があります。
    2. Subscription CR を作成するには、次のコマンドを実行します。

      $ oc create -f metallb-sub.yaml
  5. オプション: BGP および BFD メトリックが Prometheus に表示されるようにするには、次のコマンドのように namespace にラベルを付けることができます。

    $ oc label ns metallb-system "openshift.io/cluster-monitoring=true"

検証

検証手順は、MetallB Operator が metallb-system namespace にインストールされていることを前提としています。

  1. インストール計画が namespace にあることを確認します。

    $ oc get installplan -n metallb-system

    出力例

    NAME            CSV                                   APPROVAL    APPROVED
    install-wzg94   metallb-operator.4.13.0-nnnnnnnnnnnn   Automatic   true

    注記

    Operator のインストールには数秒かかる場合があります。

  2. 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 を使用してください。

  1. MetalLB カスタムリソースの単一のインスタンスを作成します。

    $ cat << EOF | oc apply -f -
    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb-system
    EOF

検証

MetalLB コントローラーのデプロイメントと、MetalLB スピーカーのデーモンセットが実行していることを確認します。

  1. コントローラーのデプロイメントが稼働していることを検証します。

    $ oc get deployment -n metallb-system controller

    出力例

    NAME         READY   UP-TO-DATE   AVAILABLE   AGE
    controller   1/1     1            1           11m

  2. スピーカーに設定されているデーモンが実行されていることを検証します。

    $ 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 はクラスター内の各ノードでspeakerPod のインスタンスを開始します。ロードバランサーの 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 を開始している。

手順

  1. myPriorityClass.yaml などの PriorityClass カスタムリソースを作成して、優先度レベルを設定します。この例では、high-priority という名前の PriorityClass を、値 1000000 で定義します。この優先クラスが割り当てられた Pod は、スケジューリングにおいて、それより低い優先クラスの Pod より優先順位が高いとみなされます。

    apiVersion: scheduling.k8s.io/v1
    kind: PriorityClass
    metadata:
      name: high-priority
    value: 1000000
  2. PriorityClass カスタムリソース設定を適用します。

    $ oc apply -f myPriorityClass.yaml
  3. MetalLBPodConfig.yaml などの MetalLB カスタムリソースを作成して、priorityClassNamepodAffinity の値を指定します。

    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 間のネットワーク通信、遅延、リソース使用量を最適化できる可能性があります。
  4. 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 がインストールされている。

手順

  1. 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"
  2. MetalLB カスタムリソース設定を適用します。

    $ oc apply -f CPULimits.yaml

検証

  • Pod のコンピューティングリソースを表示するには、次のコマンドを実行し、<pod_name> をターゲット Pod に置き換えます。

    $ oc describe pod <pod_name>

33.2.5. 関連情報

33.2.6. 次のステップ

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.