検索
サポートコンソール開発者トライアルの開始お問い合わせ

11.3. Agent-based Installer を使用した OpenShift Container Platform クラスターのインストール

download PDF

以下の手順に従って、Agent-based Installer を使用して、OpenShift Container Platform クラスターをインストールします。

11.3.1. 前提条件

11.3.2. Agent-based Installer を使用した OpenShift Container Platform のインストール

以下の手順では、切断された環境でシングルノードの OpenShift Container Platform をデプロイします。これらの手順を基本として使用し、必要に応じて変更できます。

11.3.2.1. Agent-based Installer のダウンロード

この手順を使用して、インストールに必要な Agent-based Installer と CLI をダウンロードします。

手順

  1. ログイン認証情報を使用して OpenShift Container Platform Web コンソールにログインします。
  2. データセンター に移動します。
  3. Run Agent-based Installer locally をクリックします。
  4. OpenShift インストーラー と コマンドラインインターフェイス のオペレーティングシステムとアーキテクチャーを選択します。
  5. Download Installer をクリックして、インストールプログラムをダウンロードして展開します。
  6. Download pull secret または Copy pull secret をクリックして、プルシークレットをダウンロードまたはコピーします。
  7. Download command-line tools をクリックし、openshift-install バイナリーを PATH 上のディレクトリーに配置します。

11.3.2.2. Agent-based インストールでサポートされるアーキテクチャーの確認

Agent-based Installer を使用して OpenShift Container Platform クラスターをインストールする前に、クラスターをインストールできるサポート対象アーキテクチャーを確認できます。この手順はオプションです。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • インストールプログラムをダウンロードした。

手順

  1. OpenShift CLI (oc) にログインします。

  2. 次のコマンドを実行して、リリースペイロードを確認します。 

    $ ./openshift-install version

    出力例

    ./openshift-install 4.16.0
built from commit abc123def456
release image quay.io/openshift-release-dev/ocp-release@sha256:123abc456def789ghi012jkl345mno678pqr901stu234vwx567yz0
release architecture amd64

    multi ペイロードが含まれるリリースイメージを使用している場合、このコマンドの出力に表示される release architecture はデフォルトのアーキテクチャーです。

  3. ペイロードのアーキテクチャーを確認するには、次のコマンドを実行します。 

    $ oc adm release info <release_image> -o jsonpath="{ .metadata.metadata}" 1
    1
    <release_image> をリリースイメージに置き換えます。例: quay.io/openshift-release-dev/ocp-release@sha256:123abc456def789ghi012jkl345mno678pqr901stu234vwx567yz0。

    リリースイメージが multi ペイロードを使用する場合の出力例 

    {"release.openshift.io architecture":"multi"}

    multi ペイロードが含まれるリリースイメージを使用している場合は、arm64、amd64、s390x、ppc64le などのさまざまなアーキテクチャーにクラスターをインストールできます。それ以外の場合、クラスターは openshift-install version コマンドの出力に表示される release architecture にのみインストールできます。

11.3.2.3. 優先設定入力の作成

この手順を使用して、エージェントイメージの作成に使用される優先設定入力を作成します。

手順

  1. 以下のコマンドを実行して nmstate の依存関係をインストールします。 

    $ sudo dnf install /usr/bin/nmstatectl -y
  2. PATH にあるディレクトリーに openshift-install バイナリーを配置します。

  3. 次のコマンドを実行して、インストール設定を保存するディレクトリーを作成します。 

    $ mkdir ~/<directory_name>
    注記

    これは、エージェントベースのインストールで推奨される方法です。GitOps ZTP マニフェストの使用はオプションです。

  4. 次のコマンドを実行して、install-config.yaml ファイルを作成します。 

    $ cat << EOF > ./my-cluster/install-config.yaml
apiVersion: v1
baseDomain: test.example.com
compute:
- architecture: amd64 1
  hyperthreading: Enabled
  name: worker
  replicas: 0
controlPlane:
  architecture: amd64
  hyperthreading: Enabled
  name: master
  replicas: 1
metadata:
  name: sno-cluster 2
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 192.168.0.0/16
  networkType: OVNKubernetes 3
  serviceNetwork:
  - 172.30.0.0/16
platform: 4
  none: {}
pullSecret: '<pull_secret>' 5
sshKey: '<ssh_pub_key>' 6
EOF
    1
    システムアーキテクチャーを指定します。有効な値は、amd64、arm64、ppc64le、および s390x です。

    multi ペイロードが含まれるリリースイメージを使用している場合は、arm64、amd64、s390x、ppc64le などのさまざまなアーキテクチャーにクラスターをインストールできます。それ以外の場合、クラスターは openshift-install version コマンドの出力に表示される release architecture にのみインストールできます。詳細は、「Agent-based Installer クラスターをインストールするためのサポート対象アーキテクチャーを確認する」を参照してください。

    2
    必須。クラスター名を指定します。
    3
    インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の OVNKubernetes のみです。
    4
    プラットフォームを指定します。
    注記

    ベアメタルプラットフォームの場合、agent-config.yaml ファイル上での設定でオーバーライドされない限り、install-config.yaml ファイルのプラットフォームセクションでのホスト設定がデフォルトで使用されます。

    5
    プルシークレットを指定します。
    6
    SSH 公開鍵を指定します。
    注記

    プラットフォームを vSphere または baremetal に設定すると、クラスターノードの IP アドレスエンドポイントを次の 3 つの方法で設定できます。

    • IPv4
    • IPv6
    • IPv4 と IPv6 の並列 (デュアルスタック)

    IPv6 は、ベアメタルプラットフォームでのみサポートされます。

    デュアルスタックネットワーキングの例

    networking:
  clusterNetwork:
    - cidr: 172.21.0.0/16
      hostPrefix: 23
    - cidr: fd02::/48
      hostPrefix: 64
  machineNetwork:
    - cidr: 192.168.11.0/16
    - cidr: 2001:DB8::/32
  serviceNetwork:
    - 172.22.0.0/16
    - fd03::/112
  networkType: OVNKubernetes
platform:
  baremetal:
    apiVIPs:
    - 192.168.11.3
    - 2001:DB8::4
    ingressVIPs:
    - 192.168.11.4
    - 2001:DB8::5

    注記

    非接続ミラーレジストリーを使用する場合は、作成済みのミラーレジストリー用の証明書ファイルを install-config.yaml ファイルの additionalTrustBundle フィールドに追加する必要があります。

  5. 次のコマンドを実行して、agent-config.yaml ファイルを作成します。 

    $ cat > agent-config.yaml << EOF
apiVersion: v1beta1
kind: AgentConfig
metadata:
  name: sno-cluster
rendezvousIP: 192.168.111.80 1
hosts: 2
  - hostname: master-0 3
    interfaces:
      - name: eno1
        macAddress: 00:ef:44:21:e6:a5
    rootDeviceHints: 4
      deviceName: /dev/sdb
    networkConfig: 5
      interfaces:
        - name: eno1
          type: ethernet
          state: up
          mac-address: 00:ef:44:21:e6:a5
          ipv4:
            enabled: true
            address:
              - ip: 192.168.111.80
                prefix-length: 23
            dhcp: false
      dns-resolver:
        config:
          server:
            - 192.168.111.1
      routes:
        config:
          - destination: 0.0.0.0/0
            next-hop-address: 192.168.111.2
            next-hop-interface: eno1
            table-id: 254
EOF
    1
    この IP アドレスは、ブートストラッププロセスを実行するノードや、assisted-service コンポーネントを実行するノードを判別するために使用されます。networkConfig パラメーターで少なくとも 1 つのホストの IP アドレスを指定しない場合は、ランデブー IP アドレスを指定する必要があります。このアドレスが指定されていない場合、指定されたホストの networkConfig から 1 つの IP アドレスが選択されます。
    2
    オプション: ホスト設定。定義されたホストの数は、install-config.yaml ファイルで定義されたホストの総数 (compute.replicas および controlPlane.replicas パラメーターの値の合計) を超えてはなりません。
    3
    オプション: 動的ホスト設定プロトコル (DHCP) または逆引き DNS ルックアップから取得したホスト名をオーバーライドします。各ホストには、これらの方法のいずれかによって提供される一意のホスト名が必要です。
    4
    特定デバイスへの Red Hat Enterprise Linux CoreOS (RHCOS) イメージのプロビジョニングを有効にします。インストールプログラムは、検出順にデバイスを検査し、検出された値をヒントの値と比較します。ヒントの値と一致する最初に検出されたデバイスが使用されます。
    5
    オプション: ホストのネットワークインターフェイスを NMState 形式で設定します。

関連情報

11.3.2.4. 追加のマニフェストファイルの作成

オプションのタスクとして、追加のマニフェストを作成し、install-config.yaml ファイルと agent-config.yaml ファイルで使用可能な設定を超えてクラスターをさらに設定できます。

11.3.2.4.1. 追加のマニフェストを格納するディレクトリーの作成

追加のマニフェストを作成して、install-config.yaml ファイルおよび agent-config.yaml ファイルを超えてエージェントベースのインストールを設定する場合は、インストールディレクトリー内に openshift サブディレクトリーを作成する必要があります。追加のマシン設定は、すべてこのサブディレクトリーに配置する必要があります。

注記

最も一般的な追加マニフェストのタイプは MachineConfig オブジェクトです。エージェントベースのインストール中に追加できる MachineConfig オブジェクトの例については、「関連情報」セクションの「MachineConfig オブジェクトを使用してノードを設定する」を参照してください。

手順

  • インストールホスト上で次のコマンドを実行して、インストールディレクトリー内に openshift サブディレクトリーを作成します。 

    $ mkdir <installation_directory>/openshift

関連情報

11.3.2.4.2. ディスクパーティション設定

通常は、RHCOS のインストール時に作成されるデフォルトのディスクパーティションを使用する必要があります。ただし、拡張するディレクトリーの個別のパーティションの作成が必要となる場合もあります。

OpenShift Container Platform は、ストレージを /var ディレクトリーまたは /var のサブディレクトリーのいずれかに割り当てる単一のパーティションの追加をサポートします。以下に例を示します。

  • /var/lib/containers: イメージやコンテナーがシステムにさらに追加されると拡張するコンテナー関連のコンテンツを保持します。
  • /var/lib/etcd: etcd ストレージのパフォーマンスの最適化などの目的で分離する必要のあるデータを保持します。

  • /var: 監査などの目的に合わせて分離させる必要のあるデータを保持します。

    重要

    ディスクサイズが 100 GB を超える場合、特に 1 TB を超える場合は、別の /var パーティションを作成します。

/var ディレクトリーのコンテンツを個別に保存すると、必要に応じてこれらの領域のストレージの拡大を容易にし、後で OpenShift Container Platform を再インストールして、そのデータをそのまま保持することができます。この方法では、すべてのコンテナーを再度プルする必要はありません。また、システムの更新時に大きなログファイルをコピーする必要もありません。

/var ディレクトリーまたは /var のサブディレクトリーの個別のパーティションを使用すると、パーティション設定されたディレクトリーでのデータの増加によりルートファイルシステムが一杯になることを避けることもできます。

以下の手順では、インストールの準備フェーズでノードタイプの Ignition 設定ファイルにラップされるマシン設定マニフェストを追加して、別の /var パーティションを設定します。

前提条件

  • インストールディレクトリー内に openshift サブディレクトリーを作成している。

手順

  1. 追加のパーティションを設定する Butane 設定を作成します。たとえば、$HOME/clusterconfig/98-var-partition.bu ファイルに名前を付け、ディスクのデバイス名を worker システムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、/var ディレクトリーを別のパーティションにマウントします。 

    variant: openshift
version: 4.16.0
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 98-var-partition
storage:
  disks:
  - device: /dev/disk/by-id/<device_name> 1
    partitions:
    - label: var
      start_mib: <partition_start_offset> 2
      size_mib: <partition_size> 3
      number: 5
  filesystems:
    - device: /dev/disk/by-partlabel/var
      path: /var
      format: xfs
      mount_options: [defaults, prjquota] 4
      with_mount_unit: true
    1
    パーティションを設定する必要のあるディスクのストレージデバイス名。
    2
    データパーティションをブートディスクに追加する場合は、25000 のメビバイトの最小のオフセット値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。オフセット値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。
    3
    データパーティションのサイズ (メビバイト単位)。
    4
    コンテナーストレージに使用されるファイルシステムでは、prjquota マウントオプションを有効にする必要があります。
    注記

    個別の /var パーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、コンピュートノードに異なるインスタンスタイプを使用することはできません。

  2. Butane config からマニフェストを作成し、clusterconfig/openshift ディレクトリーに保存します。たとえば、以下のコマンドを実行します。 

    $ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml

11.3.2.5. ZTP マニフェストの使用

オプションのタスクとして、GitOps Zero Touch Provisioning (ZTP) マニフェストを使用して、install-config.yaml および agent-config.yaml ファイルで使用できるオプションを超えてインストールを設定できます。

注記

GitOps ZTP マニフェストは、事前に install-config.yaml ファイルと agent-config.yamlファイルを設定したかどうかにかかわらず生成できます。install-config.yaml ファイルと agent-config.yaml ファイルを設定することを選択した場合、設定は生成時に ZTP クラスターマニフェストにインポートされます。

前提条件

  • 使用する PATH 上のディレクトリーに openshift-install バイナリーを配置している。
  • オプション: install-config.yaml ファイルと agent-config.yaml ファイルを作成し、設定している。

手順

  1. 次のコマンドを実行して、ZTP クラスターマニフェストを生成します。 

    $ openshift-install agent create cluster-manifests --dir <installation_directory>
    重要

    install-config.yaml ファイルと agent-config.yaml ファイルを作成した場合、それらのファイルは削除され、このコマンドで生成されたクラスターマニフェストに置き換えられます。

    install-config.yaml ファイルと agent-config.yaml ファイルに対して行われた設定は、openshift-install agent create cluster-manifests コマンドを実行すると ZTP クラスターマニフェストにインポートされます。

  2. 次のコマンドを実行して、cluster-manifests ディレクトリーに移動します。 

    $ cd <installation_directory>/cluster-manifests
  3. cluster-manifests ディレクトリー内のマニフェストファイルを設定します。サンプルファイルの詳細は、「サンプル GitOps ZTP カスタムリソース」セクションを参照してください。

  4. 非接続クラスター: ZTP マニフェストを生成する前に install-config.yaml ファイルでミラー設定を定義しなかった場合は、次の手順を実行します。

    1. 次のコマンドを実行して、mirror ディレクトリーに移動します。 

      $ cd ../mirror
    2. mirror ディレクトリーにマニフェストファイルを設定します。

関連情報

11.3.2.6. ディスクの暗号化

オプションのタスクとして、Agent-based Installer を使用して OpenShift Container Platform をインストールするときに、この手順を使用してディスクまたはパーティションを暗号化できます。

前提条件

  • ZTP マニフェストを使用している場合を除き、install-config.yaml ファイルと agent-config.yaml ファイルが作成および設定されていること。
  • 使用する PATH 上のディレクトリーに openshift-install バイナリーを配置している。

手順

  1. 次のコマンドを実行して、ZTP クラスターマニフェストを生成します。 

    $ openshift-install agent create cluster-manifests --dir <installation_directory>
    重要

    install-config.yaml ファイルと agent-config.yaml ファイルを作成した場合、それらのファイルは削除され、このコマンドで生成されたクラスターマニフェストに置き換えられます。

    install-config.yaml ファイルと agent-config.yaml ファイルに対して行われた設定は、openshift-install agent create cluster-manifests コマンドを実行すると ZTP クラスターマニフェストにインポートされます。

    注記

    すでに ZTP マニフェストを生成している場合は、この手順をスキップしてください。

  2. 次のコマンドを実行して、cluster-manifests ディレクトリーに移動します。 

    $ cd <installation_directory>/cluster-manifests

  3. 次のセクションを agent-cluster-install.yaml ファイルに追加します。 

    diskEncryption:
    enableOn: all 1
    mode: tang 2
    tangServers: "server1": "http://tang-server-1.example.com:7500" 3
    1
    ディスク暗号化を有効にするノードを指定します。有効な値は none、all、master、worker です。
    2
    使用するディスク暗号化モードを指定します。有効な値は tpmv2 および tang です。
    3
    オプション: Tang を使用している場合は、Tang サーバーを指定します。

関連情報

11.3.2.7. エージェントイメージの作成と起動

この手順を使用して、マシンでエージェントイメージを起動します。

手順

  1. 以下のコマンドを実行して agent イメージを作成します。 

    $ openshift-install --dir <install_directory> agent create image
    注記

    Red Hat Enterprise Linux CoreOS (RHCOS) はプライマリーディスクでのマルチパスをサポートするようになり、ハードウェア障害に対する対障害性が強化され、ホストの可用性を強化できるようになりました。マルチパス化は、デフォルトの /etc/multipath.conf 設定を使用して、agent ISO イメージでデフォルトで有効になっています。

  2. ベアメタルマシンで、agent.x86_64.iso、agent.aarch64.iso、または agent.s390x.iso イメージを起動します。

11.3.2.8. RHEL KVM を使用した IBM Z エージェントの追加

RHEL KVM を使用して IBM Z® エージェントを手動で追加するには、次の手順を使用します。この手順は、RHEL KVM を使用する IBM Z® クラスターにのみ使用してください。

手順

  1. RHEL KVM マシンを起動します。

  2. 仮想サーバーをデプロイするために、次のパラメーターを指定して virt-install コマンドを実行します。 

    $ virt-install
    --name <vm_name> \
    --autostart \
    --memory=<memory> \
    --cpu host \
    --vcpus=<vcpus> \
    --cdrom <agent_iso_image> \ 1
    --disk pool=default,size=<disk_pool_size> \
    --network network:default,mac=<mac_address> \
    --graphics none \
    --noautoconsole \
    --os-variant rhel9.0 \
    --wait=-1
    1
    --cdrom パラメーターには、HTTP または HTTPS サーバー上の ISO イメージの場所を指定します。

11.3.2.9. 現在のインストールホストがリリースイメージをプルできることを確認する

エージェントイメージを起動し、ネットワークサービスがホストで利用可能になると、エージェントコンソールアプリケーションは、プルチェックを実行して、現在のホストがリリースイメージを取得できることを確認します。

一次プルチェックに合格した場合は、アプリケーションを終了して、インストールを続行できます。プルチェックが失敗した場合、アプリケーションは、TUI の Additional checks セクションに表示されるように、問題のトラブルシューティングに役立つ追加のチェックを実行します。追加のチェックの失敗は、プライマリープルチェックが成功するかぎり、必ずしも重大ではありません。

インストールが失敗する可能性があるホストネットワーク設定の問題がある場合は、コンソールアプリケーションを使用して、ネットワーク設定を調整できます。

重要

エージェントコンソールアプリケーションがホストネットワーク設定の問題を検出した場合は、ユーザーが手動でコンソールアプリケーションを停止し、続行する意思を示すまで、インストールワークフローは停止されます。

手順

  1. エージェントコンソールアプリケーションが、設定されたリリースイメージをレジストリーからプルできるかどうかを確認するまで待ちます。

  2. エージェントコンソールアプリケーションが、インストーラーの接続チェックに合格したことを示している場合は、プロンプトがタイムアウトになるまで待って、インストールを続行します。

    注記

    接続チェックに合格した場合も、ネットワーク設定の表示または変更を選択できます。

    ただし、タイムアウトせずに、エージェントコンソールアプリケーションとやりとりすることを選択した場合は、TUI を手動で終了して、インストールを続行する必要があります。

  3. エージェントコンソールアプリケーションのチェックが失敗した場合は、Release image URL プルチェックの横に赤いアイコンが表示されます。ホストのネットワーク設定を再設定するには、次の手順を使用します。

    1. TUI の Check Errors セクションを読みます。このセクションには、失敗したチェックに固有のエラーメッセージが表示されます。

      チェックエラーが表示されているエージェントコンソールアプリケーションのホーム画面
    2. Configure network を選択して、NetworkManager TUI を起動します。
    3. Edit a connection を選択し、再設定する接続を選択します。
    4. 設定を編集し、OK を選択して、変更を保存します。
    5. Back を選択して、NetworkManager TUI のメイン画面に戻ります。
    6. Activate a Connection を選択します。
    7. 再設定されたネットワークを選択して、非アクティブ化します。
    8. 再設定されたネットワークを再度選択して、再アクティブ化します。
    9. Back を選択し、Quit を選択して、エージェントコンソールアプリケーションに戻ります。
    10. 新しいネットワーク設定を使用して、継続的なネットワークチェックが再開されるまで、5 秒間以上、待ちます。
    11. Release image URL プルチェックが成功し、URL の横に緑色のアイコンが表示された場合は、Quit を選択して、エージェントコンソールアプリケーションを終了し、インストールを続行します。

11.3.2.10. インストールの進行状況の追跡と確認

次の手順を使用して、インストールの進行状況を追跡し、インストールが成功したことを確認します。

前提条件

  • Kubernetes API サーバーの DNS レコードを設定している。

手順

  1. オプション: ブートストラップホスト (ランデブーホスト) がいつ再起動するかを知るには、次のコマンドを実行します。 

    $ ./openshift-install --dir <install_directory> agent wait-for bootstrap-complete \1
    --log-level=info 2
    1
    <install_directory> には、エージェント ISO が生成されたディレクトリーへのパスを指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warn、debug、または error を指定します。

    出力例

    ...................................................................
...................................................................
INFO Bootstrap configMap status is complete
INFO cluster bootstrap is complete

    Kubernetes API サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。

  2. 進行状況を追跡し、インストールが成功したことを確認するには、次のコマンドを実行します。 

    $ openshift-install --dir <install_directory> agent wait-for install-complete 1
    1
    <install_directory> directory には、エージェント ISO が生成されたディレクトリーへのパスを指定します。

    出力例

    ...................................................................
...................................................................
INFO Cluster is installed
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run
INFO     export KUBECONFIG=/home/core/installer/auth/kubeconfig
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.sno-cluster.test.example.com

注記

GitOps ZTP マニフェストのオプションの方法を使用している場合、次の 3 つの方法で AgentClusterInstall.yaml ファイルを介してクラスターノードの IP アドレスエンドポイントを設定できます。

  • IPv4
  • IPv6
  • IPv4 と IPv6 の並列 (デュアルスタック)

IPv6 は、ベアメタルプラットフォームでのみサポートされます。

デュアルスタックネットワーキングの例

apiVIP: 192.168.11.3
ingressVIP: 192.168.11.4
clusterDeploymentRef:
  name: mycluster
imageSetRef:
  name: openshift-4.16
networking:
  clusterNetwork:
  - cidr: 172.21.0.0/16
    hostPrefix: 23
  - cidr: fd02::/48
    hostPrefix: 64
  machineNetwork:
  - cidr: 192.168.11.0/16
  - cidr: 2001:DB8::/32
  serviceNetwork:
  - 172.22.0.0/16
  - fd03::/112
  networkType: OVNKubernetes

関連情報

11.3.3. GitOps ZTP カスタムリソースのサンプル

オプションで、GitOps Zero Touch Provisioning (ZTP) カスタムリソース (CR) オブジェクトを使用して、Agent-based Installer で OpenShift Container Platform クラスターをインストールできます。

以下の GitOps ZTP カスタムリソースをカスタマイズして、OpenShift Container Platform クラスターの詳細を指定できます。次のサンプル GitOps ZTP カスタムリソースは、単一ノードクラスター用です。

agent-cluster-install.yaml ファイルの例

  apiVersion: extensions.hive.openshift.io/v1beta1
  kind: AgentClusterInstall
  metadata:
    name: test-agent-cluster-install
    namespace: cluster0
  spec:
    clusterDeploymentRef:
      name: ostest
    imageSetRef:
      name: openshift-4.16
    networking:
      clusterNetwork:
      - cidr: 10.128.0.0/14
        hostPrefix: 23
      serviceNetwork:
      - 172.30.0.0/16
    provisionRequirements:
      controlPlaneAgents: 1
      workerAgents: 0
    sshPublicKey: <ssh_public_key>

cluster-deployment.yaml ファイルの例

apiVersion: hive.openshift.io/v1
kind: ClusterDeployment
metadata:
  name: ostest
  namespace: cluster0
spec:
  baseDomain: test.metalkube.org
  clusterInstallRef:
    group: extensions.hive.openshift.io
    kind: AgentClusterInstall
    name: test-agent-cluster-install
    version: v1beta1
  clusterName: ostest
  controlPlaneConfig:
    servingCertificates: {}
  platform:
    agentBareMetal:
      agentSelector:
        matchLabels:
          bla: aaa
  pullSecretRef:
    name: pull-secret

cluster-image-set.yaml ファイルの例

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  name: openshift-4.16
spec:
  releaseImage: registry.ci.openshift.org/ocp/release:4.16.0-0.nightly-2022-06-06-025509

infra-env.yaml ファイルの例

apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: myinfraenv
  namespace: cluster0
spec:
  clusterRef:
    name: ostest
    namespace: cluster0
  cpuArchitecture: aarch64
  pullSecretRef:
    name: pull-secret
  sshAuthorizedKey: <ssh_public_key>
  nmStateConfigLabelSelector:
    matchLabels:
      cluster0-nmstate-label-name: cluster0-nmstate-label-value

nmstateconfig.yaml ファイルの例

apiVersion: agent-install.openshift.io/v1beta1
kind: NMStateConfig
metadata:
  name: master-0
  namespace: openshift-machine-api
  labels:
    cluster0-nmstate-label-name: cluster0-nmstate-label-value
spec:
  config:
    interfaces:
      - name: eth0
        type: ethernet
        state: up
        mac-address: 52:54:01:aa:aa:a1
        ipv4:
          enabled: true
          address:
            - ip: 192.168.122.2
              prefix-length: 23
          dhcp: false
    dns-resolver:
      config:
        server:
          - 192.168.122.1
    routes:
      config:
        - destination: 0.0.0.0/0
          next-hop-address: 192.168.122.1
          next-hop-interface: eth0
          table-id: 254
  interfaces:
    - name: "eth0"
      macAddress: 52:54:01:aa:aa:a1

pull-secret.yaml ファイルの例

apiVersion: v1
kind: Secret
type: kubernetes.io/dockerconfigjson
metadata:
  name: pull-secret
  namespace: cluster0
stringData:
  .dockerconfigjson: <pull_secret>

関連情報

11.3.4. 失敗したエージェントベースのインストールからログデータを収集する

次の手順を使用して、失敗したエージェントベースのインストールに関するログデータを収集し、サポートケースで提供できるよう備えます。

前提条件

  • Kubernetes API サーバーの DNS レコードを設定している。

手順

  1. 次のコマンドを実行し、出力を収集します。 

    $ ./openshift-install --dir <installation_directory> agent wait-for bootstrap-complete --log-level=debug

    エラーメッセージの例

    ...
ERROR Bootstrap failed to complete: : bootstrap process timed out: context deadline exceeded

  2. 直前のコマンド出力で障害の発生が示された場合、またはブートストラップが進行していない場合は、次のコマンドを実行してランデブーホストに接続し、出力を収集します。 

    $ ssh core@<node-ip> agent-gather -O >agent-gather.tar.xz
    注記

    Red Hat サポートは、ランデブーホストから収集したデータを使用してほとんどの問題を診断できますが、一部のホストが登録できない場合はすべてのホストからこのデータを収集すると役立ちます。

  3. ブートストラップが完了し、クラスターノードが再起動したら、次のコマンドを実行して出力を収集します。 

    $ ./openshift-install --dir <install_directory> agent wait-for install-complete --log-level=debug

  4. 前のコマンドの出力が失敗を示している場合は、次の手順を実行します。

    1. 次のコマンドを実行して、kubeconfig ファイルを環境にエクスポートします。 

      $ export KUBECONFIG=<install_directory>/auth/kubeconfig

    2. 次のコマンドを実行して、デバッグ用の情報を収集します。 

      $ oc adm must-gather

    3. 次のコマンドを実行して、作業ディレクトリーに作成した must-gather ディレクトリーから圧縮ファイルを作成します。 

      $ tar cvaf must-gather.tar.gz <must_gather_directory>
  5. /auth サブディレクトリーを除いて、デプロイメント中に使用したインストールディレクトリーを Red Hat カスタマーポータル のサポートケースに添付します。
  6. この手順で収集した他のすべてのデータをサポートケースに添付してください。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.