1.5. インフラストラクチャー環境の作成

Red Hat Advanced Cluster Management for Kubernetes コンソールを使用して、インフラストラクチャー環境を作成して、ホストを管理し、それらのホストでクラスターを作成できます。

インフラストラクチャー環境は、次の機能をサポートしています。

  • クラスターのゼロタッチプロビジョニング: スクリプトを使用してクラスターを展開します。詳細は、Red Hat OpenShift Container Platform ドキュメントの Deploying distributed units at scale in a disconnected environment を参照してください。
  • レイトバインド: インフラストラクチャー管理者がホストを起動できるようにします。クラスター作成者は、後でクラスターをそのホストにバインドできます。レイトバインドを使用する場合、クラスター作成者はインフラストラクチャーに対する管理者権限を持っている必要はありません。
  • デュアルスタック: IPv4 と IPv6 の両方のアドレスを持つクラスターをデプロイします。デュアルスタックは、OVN-Kubernetes ネットワーク実装を使用して、複数のサブネットをサポートします。
  • リモートワーカーノードの追加: リモートワーカーノードを作成して実行した後、クラスターに追加します。これにより、バックアップ目的で他の場所にノードを追加する柔軟性が提供されます。
  • NMState を使用した静的 IP: NMState API を使用して、環境の静的 IP アドレスを定義します。

1.5.1. 前提条件

インフラストラクチャー環境を作成する前に、以下の前提条件を確認してください。

  • OpenShift Container Platform をハブクラスターにデプロイする必要があります。
  • クラスターを作成するために必要なイメージを取得するための、Red Hat Advanced Cluster Management ハブクラスターへのインターネットアクセス (接続済み)、あるいはインターネットへの接続がある内部またはミラーレジストリーへの接続 (非接続) がある。
  • ハブクラスター上にある設定済みの Central Infrastructure Management (CIM) 機能のインスタンスがある。手順は Central Infrastructure Management サービスの有効化 を参照してください。
  • OpenShift Container Platform プルシークレット がある。詳細は、Using image pull secrets を参照してください。
  • デフォルトで ~/.ssh/id_rsa.pub ファイルに SSH キーがある。
  • 設定済みのストレージクラスがある。
  • 非接続環境のみ: OpenShift Container Platform ドキュメントの 非接続環境の準備 の手順を実行している。

1.5.2. Central Infrastructure Management サービスの有効化

Central Infrastructure Management サービスは {mce-short} で提供され、OpenShift Container Platform クラスターをデプロイします。CIM は、ハブクラスターで MultiClusterHub Operator を有効にするとデプロイされますが、有効にする必要があります。

CIM サービスを有効にするには、以下の手順を実行します。

重要: ハブクラスターが次のプラットフォームのいずれかにインストールされている場合のみ: ベアメタル、Red Hat OpenStack Platform、VMware vSphere、またはユーザープロビジョニングインフラストラクチャー (UPI) 方式を使用してインストールされ、プラットフォームが None の場合のみ、次の手順を実行します。ハブクラスターが他のプラットフォームにある場合は、この手順を省略します。

  1. provisioning リソースを変更し、以下のコマンドを実行してベアメタル Operator がすべての namespace を監視できるようにします。

    oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"watchAllNamespaces": true }}'
  2. 非接続環境: では、インフラストラクチャー Operator と 同じ namespaceConfigMap を作成し、ミラーレジストリーの ca-bundle.crt および registries.conf の値を指定します。ファイルの ConfigMap は以下の例のようになります。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: <mirror-config>
      namespace: "<infrastructure-operator-namespace>"
      labels:
        app: assisted-service
    data:
      ca-bundle.crt: |
        -----BEGIN CERTIFICATE-----
        certificate contents
        -----END CERTIFICATE-----
    
      registries.conf: |
        unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
    
        [[registry]]
           prefix = ""
           location = "quay.io/edge-infrastructure"
           mirror-by-digest-only = false
    
           [[registry.mirror]]
           location = "mirror1.registry.corp.com:5000/edge-infrastructure"

1.5.2.1. AgentServiceConfig カスタムリソースの作成

以下の手順を実行して AgentServiceConfig カスタムリソースを作成します。

  1. 切断された環境のみ: 次の YAML コンテンツを agent_service_config.yaml ファイルに保存し、必要に応じて値を置き換えます。

    apiVersion: agent-install.openshift.io/v1beta1
    kind: AgentServiceConfig
    metadata:
     name: agent
    spec:
      databaseStorage:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <db_volume_size>
      filesystemStorage:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <fs_volume_size>
      mirrorRegistryRef:
        name: <mirror_config>
      unauthenticatedRegistries:
        - <unauthenticated_registry>
      imageStorage:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <img_volume_size>
      osImages:
        - openshiftVersion: "<ocp_version>"
          version: "<ocp_release_version>"
          url: "<iso_url>"
          rootFSUrl: "<root_fs_url>"
          cpuArchitecture: "x86_64"

    mirror_config は、ミラーレジストリー設定の詳細が含まれる ConfigMap の名前に置き換えます。

    認証を必要としないミラーレジストリーを使用している場合は、オプションの unauthenticated_registry パラメーターを含めます。このリストのエントリーは検証されず、プルシークレットにエントリーを含める必要はありません。

  2. 接続環境の場合のみ: 次の YAML コンテンツを agent_service_config.yaml ファイルに保存します。

    apiVersion: agent-install.openshift.io/v1beta1
    kind: AgentServiceConfig
    metadata:
     name: agent
    spec:
      databaseStorage:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <db_volume_size>
      filesystemStorage:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <fs_volume_size>
      imageStorage:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <img_volume_size>

    db_volume_sizedatabaseStorage フィールドのボリュームサイズに置き換えます (例: 10G)。この値は、クラスターのデータベーステーブルやデータベースビューなどのファイルを格納するために割り当てられるストレージの量を指定します。クラスターが多い場合は、より高い値を使用する必要がある場合があります。

    fs_volume_sizefilesystemStorage フィールドのボリュームのサイズに置き換えます。たとえば、クラスターごとに 200M、サポートされている OpenShift Container Platform バージョンごとに 2-3G です。必要な最小値は 100G です。この値は、クラスターのログ、マニフェスト、および kubeconfig ファイルを保存するために割り当てられるストレージのサイズを指定します。クラスターが多い場合は、より高い値を使用する必要がある場合があります。

    img_volume_sizeimageStorage フィールドのボリュームのサイズ (オペレーティングシステムイメージあたり 2G など) に置き換えます。最小サイズは 50G です。この値は、クラスターのイメージに割り当てられるストレージの量を指定します。実行中の Red Hat Enterprise Linux CoreOS の各インスタンスに 1 GB のイメージストレージを許可する必要があります。Red Hat Enterprise Linux CoreOS のクラスターおよびインスタンスが多数ある場合は、より高い値を使用する必要がある場合があります。

    ocp_version は、インストールする OpenShift Container Platform バージョンに置き換えます (例: 4.9 )。

    ocp_release_version は、特定のインストールバージョン (例: 49.83.2021032516400) に置き換えます。

    iso_url は、ISO URL に置き換えます (例:https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.10/4.10.3/rhcos-4.10.3-x86_64-live.x86_64.iso)。他の値は https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.10/4.10.3/ にあります。

    root_fs_url は、ルート FS イメージの URL に置き換えます (例: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.10/4.10.3/rhcos-4.10.3-x86_64-live-rootfs.x86_64.img)。他の値は https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.10/4.10.3/ にあります。

  3. 次のコマンドを実行して、AgentServiceConfig カスタムリソースを作成します。

    oc create -f agent_service_config.yaml

    出力は次の例のような内容になります。

    agentserviceconfig.agent-install.openshift.io/agent created

assisted-serviceassisted-image-service デプロイメントをチェックして、Pod の準備ができ、実行されていることを確認して、正常性を検証できます。コンソールを使用したインフラストラクチャー環境の作成 に進んでください。

1.5.2.2. プロビジョニングカスタムリソース (CR) を手動で作成する

次のコマンドを使用して、プロビジョニング CR を手動で作成し、サービスの自動プロビジョニングを有効にします。

oc create -f provisioning-configuration.yaml

CR は次のサンプルのようになります。

apiVersion: metal3.io/v1alpha1
kind: Provisioning
metadata:
  name: provisioning-configuration
spec:
  provisioningNetwork: Disabled
  watchAllNamespaces: true

1.5.2.3. Amazon Web Services での中央インフラストラクチャー管理の有効化

Amazon Web Services でハブクラスターを実行していて、CIM サービスを有効にする場合は、CIM を有効 にした後に次の追加手順を実行します。

  1. ハブにログインしていることを確認し、次のコマンドを実行して、assisted-image-service で設定された一意のドメインを見つけます。

    oc get routes --all-namespaces | grep assisted-image-service

    ドメインは assisted-image-service-multicluster-engine.apps.<yourdomain>.com のようになります。

  2. ハブにログインしていることを確認し、NLB type パラメーターを使用して一意のドメインで新しい IngressController を作成します。以下の例を参照してください。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: ingress-controller-with-nlb
      namespace: openshift-ingress-operator
    spec:
      domain: nlb-apps.<domain>.com
      routeSelector:
          matchLabels:
            router-type: nlb
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: External
          providerParameters:
            type: AWS
            aws:
              type: NLB
  3. nlb-apps.<domain>.com<domain><yourdomain> に置き換えて、IngressControllerdomain パラメーターに <yourdomain> を追加します。
  4. 次のコマンドを使用して、新しい IngressController を適用します。

    oc apply -f ingresscontroller.yaml
  5. 次のコマンドを実行して、assisted-image-service ルートを編集し、nlb-apps の場所を使用します。

    oc edit route assisted-image-service -n <namespace>

    ヒント: デフォルトの名前空間は、:mce: をインストールした場所です。

  6. 次の行を assisted-image-service ルートに追加します。

    metadata:
      labels:
        router-type: nlb
      name: assisted-image-service
  7. assisted-image-service ルートで、spec.host の URL 値を見つけます。URL は次の例のようになります。

    assisted-image-service-multicluster-engine.apps.<yourdomain>.com

  8. URL 内の appsnlb-apps に置き換えて、新しい IngressController で設定されたドメインと一致させます。

Amazon Web Services で CIM サービスが有効になっていることを確認するには、次の手順を実行します。

  1. 次のコマンドを実行して、Pod が正常であることを確認します。

    oc get pods -n multicluster-engine | grep assist
  2. 新しいインフラストラクチャー環境を作成し、ダウンロード URL が新しい nlb-apps URL を使用していることを確認します。

1.5.3. コンソールを使用したインフラストラクチャー環境の作成

Red Hat Advanced Cluster Management コンソールからインフラストラクチャー環境を作成するには、以下の手順を実行します。

  1. ナビゲーションメニューから Infrastructure > Infrastructure environments に移動し、Create infrastructure environment をクリックします。
  2. お使いのインフラストラクチャー環境設定に以下の情報を追加します。

    • Name: お使いの環境の一意の名前。
    • ネットワークタイプ: 環境に追加可能なホストのタイプを指定できます。ベアメタルホストを使用している場合には、静的 IP オプションのみを使用できます。
    • Location: ホストの地理的な場所を指定します。地理的な場所を使用すると、クラスターの作成時に、クラスター上のデータの保存場所を簡単に判断できます。
    • Labels: インフラストラクチャー環境にラベルを追加できる任意のフィールド。これにより、検索がかんたんになり、特徴がよく似た他の環境とグループ化できます。ネットワークタイプと場所に対して行った選択は、自動的にラベルの一覧に追加されます。
    • プルシークレット: OpenShift Container Platform リソースへのアクセスを可能にする OpenShift Container Platform プルシークレット
    • SSH 公開鍵: ホストとのセキュアな通信を可能にする SSH キー。これは通常 ~/.ssh/id_rsa.pub ファイルにあります。
    • すべてのクラスターでプロキシー設定を有効にする必要がある場合は、有効にする設定を選択します。この設定は、以下の情報を入力する必要があります。

      • HTTP Proxy URL: 検出サービスへのアクセス時に使用する必要のある URL。
      • HTTPS Proxy URL: 検出サービスへのアクセス時に使用する必要のあるセキュアなプロキシー URL。https はまだサポートされていないため、形式は http である必要があります。
      • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。

ホストをインフラストラクチャー環境に追加して、続行できるようになりました。

インフラストラクチャー環境にアクセスするには、コンソールで Infrastructure > Host inventory を選択します。一覧からインフラストラクチャー環境を選択し、そのインフラストラクチャー環境の詳細とホストを表示します。

1.5.4. インフラストラクチャー環境へのホストの追加

Red Hat Advanced Cluster Management for Kubernetes コンソールを使用してインフラストラクチャー環境にホストを追加します。ホストを追加すると、クラスターの作成時に設定済みホストを簡単に選択できます。

以下の手順を実行して、新規スポットを追加します。

  1. Red Hat Advanced Cluster Management ナビゲーションで Infrastructure > Infrastructure environments に移動します。
  2. ホストを追加するインフラストラクチャー環境を選択して、その設定を表示します。
  3. ホスト タブを選択して、その環境にすでに追加されているホスト、またはホストを追加するホストを表示します。利用可能なホストが表に表示されるまでに数分かかる場合があります。
  4. Discovery ISO または Baseboard Management Controller(BMC) を選択して、ホストの情報を入力します。
  5. Discovery ISO オプションを選択した場合は、以下の手順を実行します。

    1. コンソールで提供されるコマンドをコピーして ISO をダウンロードするか、Download Discovery ISO を選択します。
    2. ブート可能なデバイスで以下のコマンドを実行し、各ホストを起動します。
    3. セキュリティーを強化する場合は、検出された各ホストに対して Approve host を選択します。この追加手順では、ISO ファイルが変更されたり、アクセス権のないユーザーにより実行された場合に備えて保護します。
    4. localhost に指定されたホスト名を一意の名前に変更します。
  6. Baseboard Management Controller(BMC) オプションを選択した場合は、以下の手順を実行します。

    注記: ホストを追加する BMC オプションは、Red Hat Advanced Cluster Management ハブクラスターのプラットフォームがベアメタル、Red Hat OpenStack Platform、VMware vSphere、またはユーザープロビジョニングのインフラストラクチャー (UPI) メソッドを使用してインストールされており、プラットフォームが None である場合にのみ使用できます。

    1. ホストの BMC の接続詳細を追加します。
    2. ホストの追加 を選択して、ブートプロセスを開始します。ホストは、検出 ISO イメージを使用して自動的に起動され、起動時にホストの一覧に追加されます。

      BMC オプションを使用してホストを追加すると、ホストは自動的に承認されます。

このインフラストラクチャー環境にオンプレミスクラスターを作成できるようになりました。クラスターの作成の詳細については、オンプレミス環境でのクラスターの作成 を参照してください。