Azure Stack Hub へのインストール


OpenShift Container Platform 4.15

Azure Stack Hub への OpenShift Container Platform のインストール

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、Azure Stack Hub に OpenShift Container Platform をインストールする方法を説明します。

第1章 Azure Stack Hub へのインストールの準備

1.1. 前提条件

1.2. OpenShift Container Platform の Azure Stack Hub へのインストール要件

OpenShift Container Platform を Microsoft Azure にインストールする前に、Azure Stack Hub アカウントを設定する必要があります。

アカウントの設定、アカウントの制限、DNS ゾーン設定、必要なロール、およびサービスプリンシパルの作成の詳細は、Azure Stack Hub アカウントの設定 を参照してください。

1.3. Azure Stack Hub に OpenShift Container Platform をインストールする方法の選択

OpenShift Container Platform をインストーラーまたは user-provisioned infrastructure にインストールすることができます。デフォルトのインストールタイプは、installer-provisioned infrastructure を使用します。この場合、インストールプログラムがクラスターの基礎となるインフラストラクチャーをプロビジョニングします。OpenShift Container Platform は、ユーザーがプロビジョニングするインスラストラクチャーにインストールすることもできます。インストールプログラムがプロビジョニングするインフラストラクチャーを使用しない場合は、クラスターリソースをユーザー自身で管理し、維持する必要があります。

installer-provisioned installation および user-provisioned installation のプロセスの詳細は、インストールプロセス を参照してください。

1.3.1. installer-provisioned infrastructure へのクラスターのインストール

次の方法を使用して、OpenShift Container Platform インストールプログラムによってプロビジョニングされた Azure Stack Hub インフラストラクチャーにクラスターをインストールできます。

1.3.2. user-provisioned infrastructure へのクラスターのインストール

以下の方法を使用して、独自にプロビジョニングする Azure Stack Hub インフラストラクチャーにクラスターをインストールできます。

1.4. 次のステップ

第2章 Azure Stack Hub アカウントの設定

OpenShift Container Platform をインストールする前に、Microsoft Azure アカウントを設定する必要があります。

重要

パブリックエンドポイントで利用可能なすべての Azure リソースはリソース名の制限を受けるため、特定の用語を使用するリソースを作成することはできません。Azure が制限する用語のリストは、Azure ドキュメントの 予約されたリソース名のエラーを解決する を参照してください。

2.1. Azure Stack Hub アカウントの制限

OpenShift Container Platform クラスターは数多くの Microsoft Azure Stack Hub コンポーネントを使用し、デフォルトの Azure Stack Hub のクォータタイプ は、OpenShift Container Platform クラスターをインストールする機能に影響を与えます。

以下の表は、OpenShift Container Platform クラスターのインストールおよび実行機能に影響を与える可能性のある Azure Stack Hub コンポーネントの制限を要約しています。

コンポーネントデフォルトで必要なコンポーネントの数説明

仮想 CPU

56

デフォルトのクラスターには 56 vCPU が必要であるため、アカウントの上限を引き上げる必要があります。

デフォルトで、各クラスターは以下のインスタンスを作成します。

  • 1 つのブートストラップマシン。これはインストール後に削除されます。
  • 3 つのコントロールプレーンマシン
  • 3 つのコンピュートマシン

ブートストラップ、コントロールプレーン、およびワーカーマシンは 8 vCPU を使用する Standard_DS4_v2 仮想マシンを使用するため、デフォルトのクラスターには 56 vCPU が必要です。ブートストラップノードの仮想マシンはインストール時にのみ使用されます。

追加のワーカーノードをデプロイし、自動スケーリングを有効にし、大規模なワークロードをデプロイするか、異なるインスタンスタイプを使用するには、アカウントの vCPU 制限をさらに引き上げ、クラスターが必要なマシンをデプロイできるようにする必要があります。

VNet

1

各デフォルトクラスターには、2 つのサブネットを含む 1 つの Virtual Network (VNet) が必要です。

ネットワークインターフェイス

7

各デフォルトクラスターには、7 つのネットワークインターフェイスが必要です。さらに多くのマシンを作成したり、デプロイしたワークロードでロードバランサーを作成する場合、クラスターは追加のネットワークインターフェイスを使用します。

ネットワークセキュリティーグループ

2

各クラスターは VNet の各サブネットにネットワークセキュリティーグループを作成します。デフォルトのクラスターは、コントロールプレーンおよびコンピュートノードのサブネットにネットワークセキュリティーグループを作成します。

controlplane

任意の場所からコントロールプレーンマシンにポート 6443 でアクセスできるようにします。

node

インターネットからワーカーノードにポート 80 および 443 でアクセスできるようにします。

ネットワークロードバランサー

3

各クラスターは以下の ロードバランサー を作成します。

default

ワーカーマシン間でポート 80 および 443 での要求の負荷分散を行うパブリック IP アドレス

internal

コントロールプレーンマシン間でポート 6443 および 22623 での要求の負荷分散を行うプライベート IP アドレス

external

コントロールプレーンマシン間でポート 6443 での要求の負荷分散を行うパブリック IP アドレス

アプリケーションが追加の Kubernetes LoadBalancer サービスオブジェクトを作成すると、クラスターは追加のロードバランサーを使用します。

パブリック IP アドレス

2

パブリックロードバランサーはパブリック IP アドレスを使用します。ブートストラップマシンは、インストール時のトラブルシューティングのためにマシンに SSH を実行できるようにパブリック IP アドレスも使用します。ブートストラップノードの IP アドレスは、インストール時にのみ使用されます。

プライベート IP アドレス

7

内部ロードバランサー、3 つのコントロールプレーンマシンのそれぞれ、および 3 つのワーカーマシンのそれぞれはプライベート IP アドレスを使用します。

2.2. Azure Stack Hub での DNS ゾーンの設定

OpenShift Container Platform を Azure Stack Hub に正常にインストールするには、Azure Stack Hub DNS ゾーンに DNS レコードを作成する必要があります。DNS ゾーンはドメインに対する権威を持っている必要があります。レジストラーの DNS ゾーンを Azure Stack Hub に委譲するには、Microsoft の Azure Stack Hub データセンター DNS 統合 に関するドキュメントを参照してください。

2.3. 必要な Azure Stack Hub ロール

Microsoft Azure Stack Hub アカウントには、使用するサブスクリプションについて以下のロールが必要です。

  • Owner

Azure ポータルでロールを設定するには、Microsoft ドキュメントの Manage access to resources in Azure Stack Hub with role-based access control を参照してください。

2.4. サービスプリンシパルの作成

OpenShift Container Platform とそのインストールプログラムは Azure Resource Manager を使用して Microsoft Azure リソースを作成するため、それを表すサービスプリンシパルを作成する必要があります。

前提条件

  • Azure CLI のインストールまたは更新を実行します。
  • Azure アカウントには、使用するサブスクリプションに必要なロールがなければなりません。

手順

  1. 環境を登録します。

    $ az cloud register -n AzureStackCloud --endpoint-resource-manager <endpoint> 1
    1
    Azure Resource Manager エンドポイント `https://management.<region>.<fqdn>/` を指定します。

    詳細は、Microsoft のドキュメント を参照してください。

  2. アクティブな環境を設定します。

    $ az cloud set -n AzureStackCloud
  3. Azure Stack Hub に特定の API バージョンを使用するように、環境設定を更新します。

    $ az cloud update --profile 2019-03-01-hybrid
  4. Azure CLI にログインします。

    $ az login

    マルチテナント環境の場合は、テナント ID も指定する必要があります。

  5. Azure アカウントでサブスクリプションを使用している場合は、適切なサブスクリプションを使用していることを確認してください。

    1. 利用可能なアカウントの一覧を表示し、クラスターに使用するサブスクリプションの tenantId の値を記録します。

      $ az account list --refresh

      出力例

      [
        {
          "cloudName": AzureStackCloud",
          "id": "9bab1460-96d5-40b3-a78e-17b15e978a80",
          "isDefault": true,
          "name": "Subscription Name",
          "state": "Enabled",
          "tenantId": "6057c7e9-b3ae-489d-a54e-de3f6bf6a8ee",
          "user": {
            "name": "you@example.com",
            "type": "user"
          }
        }
      ]

    2. アクティブなアカウントの詳細を表示し、tenantId 値が使用するサブスクリプションと一致することを確認します。

      $ az account show

      出力例

      {
        "environmentName": AzureStackCloud",
        "id": "9bab1460-96d5-40b3-a78e-17b15e978a80",
        "isDefault": true,
        "name": "Subscription Name",
        "state": "Enabled",
        "tenantId": "6057c7e9-b3ae-489d-a54e-de3f6bf6a8ee", 1
        "user": {
          "name": "you@example.com",
          "type": "user"
        }
      }

      1
      tenantId パラメーターの値が正しいサブスクリプション ID であることを確認してください。
    3. 適切なサブスクリプションを使用していない場合には、アクティブなサブスクリプションを変更します。

      $ az account set -s <subscription_id> 1
      1
      サブスクリプション ID を指定します。
    4. サブスクリプション ID の更新を確認します。

      $ az account show

      出力例

      {
        "environmentName": AzureStackCloud",
        "id": "33212d16-bdf6-45cb-b038-f6565b61edda",
        "isDefault": true,
        "name": "Subscription Name",
        "state": "Enabled",
        "tenantId": "8049c7e9-c3de-762d-a54e-dc3f6be6a7ee",
        "user": {
          "name": "you@example.com",
          "type": "user"
        }
      }

  6. 出力から tenantId および id パラメーター値を記録します。OpenShift Container Platform のインストール時にこれらの値が必要になります。
  7. アカウントのサービスプリンシパルを作成します。

    $ az ad sp create-for-rbac --role Contributor --name <service_principal> \ 1
      --scopes /subscriptions/<subscription_id> 2
      --years <years> 3
    1
    サービスプリンシパル名を指定します。
    2
    サブスクリプション ID を指定します。
    3
    年数を指定します。デフォルトでは、サービスプリンシパルは 1 年で期限切れになります。--years オプションを使用すると、サービスプリンシパルの有効期間を延長できます。

    出力例

    Creating 'Contributor' role assignment under scope '/subscriptions/<subscription_id>'
    The output includes credentials that you must protect. Be sure that you do not
    include these credentials in your code or check the credentials into your source
    control. For more information, see https://aka.ms/azadsp-cli
    {
      "appId": "ac461d78-bf4b-4387-ad16-7e32e328aec6",
      "displayName": <service_principal>",
      "password": "00000000-0000-0000-0000-000000000000",
      "tenantId": "8049c7e9-c3de-762d-a54e-dc3f6be6a7ee"
    }

  8. 直前の出力の appId および password パラメーターの値を記録します。OpenShift Container Platform のインストール時にこれらの値が必要になります。

関連情報

2.5. 次のステップ

第3章 インストーラーでプロビジョニングされたインフラストラクチャーを使用して Azure Stack Hub にクラスターをインストールします。

OpenShift Container Platform バージョン 4.15 では、installer-provisioned infrastructure を使用して、Microsoft Azure Stack Hub にクラスターをインストールできます。ただし、Azure Stack Hub に固有の値を指定するには、install-config.yamlファイルを手動で設定する必要があります。

注記

インストールプログラムを使用して、installer-provisioned infrastructure を使用してクラスターをデプロイするときに、azure を選択できますが、このオプションは Azure Public Cloud でのみサポートされます。

3.1. 前提条件

3.2. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.15 では、クラスターをインストールするためにインターネットアクセスが必要になります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしないと、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。
重要

クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。

3.3. クラスターノードの SSH アクセス用のキーペアの生成

OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。

キーがノードに渡されると、キーペアを使用して RHCOS ノードにユーザー core として SSH を実行できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。

インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。

重要

障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。

注記

AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    x86_64ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      $ eval "$(ssh-agent -s)"

      出力例

      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    $ ssh-add <path>/<file_name> 1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

  • OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。

3.4. RHCOS クラスターイメージのアップロード

RHCOS 仮想ハードディスク (VHD) クラスターイメージをダウンロードし、これを Azure Stack Hub 環境にアップロードして、デプロイメント中にアクセスできるようにする必要があります。

前提条件

  • Azure アカウントを設定します。

手順

  1. RHCOS VHD クラスターイメージを取得します。

    1. RHCOS VHD の URL を環境変数にエクスポートします。

      $ export COMPRESSED_VHD_URL=$(openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.azurestack.formats."vhd.gz".disk.location')
    2. 圧縮された RHCOS VHD ファイルをローカルにダウンロードします。

      $ curl -O -L ${COMPRESSED_VHD_URL}
  2. VHD ファイルを展開します。

    注記

    展開した VHD ファイルは約 16 GB であるため、ホストシステムに 16 GB の空き領域があることを確認してください。VHD ファイルは、アップロードした後に削除できます。

  3. ローカル VHD を Azure Stack Hub 環境にアップロードし、blob が公開されていることを確認します。たとえば、az cli または Web ポータルを使用して VHD を blob にアップロードできます。

3.5. インストールプログラムの取得

OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。

前提条件

  • Linux または macOS を実行し、少なくとも 1.2 GB のローカルディスク容量を備えたコンピューターがある。

手順

  1. Red Hat Hybrid Cloud Console の Cluster Type ページに移動します。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. ページの Run it yourself セクションからインフラストラクチャープロバイダーを選択します。
  3. OpenShift Installer のドロップダウンメニューからホストオペレーティングシステムとアーキテクチャーを選択し、Download Installer をクリックします。
  4. ダウンロードしたファイルを、インストール設定ファイルを保存するディレクトリーに配置します。

    重要
    • インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。クラスターを削除するには、両方のファイルが必要です。
    • インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
  5. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  6. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
ヒント

Red Hat カスタマーポータル からインストールプログラムを取得することもできます。このページでは、ダウンロードするインストールプログラムのバージョンを指定できます。ただし、このページにアクセスするには、有効なサブスクリプションが必要です。

3.6. インストール設定ファイルの手動作成

クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。

前提条件

  • ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。

手順

  1. 必要なインストールアセットを保存するためのインストールディレクトリーを作成します。

    $ mkdir <installation_directory>
    重要

    ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

  2. 提供されるサンプルの install-config.yaml ファイルテンプレートをカスタマイズし、これを <installation_directory> に保存します。

    注記

    この設定ファイルの名前を install-config.yaml と付ける必要があります。

    次の変更を行います。

    1. 必要なインストールパラメーターを指定します。
    2. platform.azure セクションを更新して、Azure Stack Hub に固有のパラメーターを指定します。
    3. オプション: 1 つ以上のデフォルト設定パラメーターを更新して、インストールをカスタマイズします。

      パラメーターの詳細は、「インストール設定パラメーター」を参照してください。

  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。

3.6.1. Azure Stack Hub 用にカスタマイズされた install-config.yaml ファイルのサンプル

install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。

重要

このサンプルの YAML ファイルは参照用にのみ提供されます。これを使用して、手動で作成したインストール設定ファイルにパラメーター値を入力します。

apiVersion: v1
baseDomain: example.com 1
credentialsMode: Manual
controlPlane: 2 3
  name: master
  platform:
    azure:
      osDisk:
        diskSizeGB: 1024 4
        diskType: premium_LRS
  replicas: 3
compute: 5
- name: worker
  platform:
    azure:
      osDisk:
        diskSizeGB: 512 6
        diskType: premium_LRS
  replicas: 3
metadata:
  name: test-cluster 7 8
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 9
  serviceNetwork:
  - 172.30.0.0/16
platform:
  azure:
    armEndpoint: azurestack_arm_endpoint 10 11
    baseDomainResourceGroupName: resource_group 12 13
    region: azure_stack_local_region 14 15
    resourceGroupName: existing_resource_group 16
    outboundType: Loadbalancer
    cloudName: AzureStackCloud 17
    clusterOSimage: https://vhdsa.blob.example.example.com/vhd/rhcos-410.84.202112040202-0-azurestack.x86_64.vhd 18 19
pullSecret: '{"auths": ...}' 20 21
fips: false 22
sshKey: ssh-ed25519 AAAA... 23
additionalTrustBundle: | 24
    -----BEGIN CERTIFICATE-----
    <MY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
1 7 10 12 14 17 18 20
必須。
2 5
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
3
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。どちらのセクションも、現時点では単一のマシンプールを定義しますが、OpenShift Container Platform の今後のバージョンでは、インストール時の複数のコンピュートプールの定義をサポートする可能性があります。1 つのコントロールプレーンプールのみが使用されます。
4 6
使用するディスクのサイズは、GB 単位で指定できます。コントロールプレーンノードの最小推奨値は 1024 GB です。
8
クラスターの名前。
9
インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の OVNKubernetes のみです。
11
Azure Stack Hub オペレーターが提供する Azure Resource Manager エンドポイント。
13
ベースドメインの DNS ゾーンが含まれるリソースグループの名前。
15
Azure Stack Hub ローカルリージョンの名前。
16
クラスターをインストールする既存のリソースグループの名前。定義されていない場合は、クラスターに新しいリソースグループが作成されます。
19
RHCOS VHD を含む Azure Stack 環境のストレージ blob の URL。
21
クラスターを認証するために必要なプルシークレット。
22
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。

23
クラスター内のマシンにアクセスするために使用する sshKey 値をオプションで指定できます。
注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

24
Azure Stack Hub 環境で内部認証局 (CA) を使用している場合は、CA 証明書を追加する必要があります。

3.7. クラウドクレデンシャルの手動管理

Cloud Credential Operator (CCO) は、手動モードのクラウドプロバイダーのみをサポートします。そのため、クラウドプロバイダーの ID およびアクセス管理 (IAM) シークレットを指定する必要があります。

手順

  1. インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。

    $ openshift-install create manifests --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  2. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  3. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest カスタムリソース (CR) のリストを抽出します。

    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \1
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \2
      --to=<path_to_directory_for_credentials_requests> 3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。

    このコマンドにより、それぞれの CredentialsRequest オブジェクトに YAML ファイルが作成されます。

    サンプル CredentialsRequest オブジェクト

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AzureProviderSpec
        roleBindings:
        - role: Contributor
      ...

  4. 以前に生成した openshift-install マニフェストディレクトリーにシークレットの YAML ファイルを作成します。シークレットは、それぞれの CredentialsRequest オブジェクトについて spec.secretRef に定義される namespace およびシークレット名を使用して保存する必要があります。

    シークレットを含む CredentialsRequest オブジェクトのサンプル

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AzureProviderSpec
        roleBindings:
        - role: Contributor
          ...
      secretRef:
        name: <component_secret>
        namespace: <component_namespace>
      ...

    サンプル Secret オブジェクト

    apiVersion: v1
    kind: Secret
    metadata:
      name: <component_secret>
      namespace: <component_namespace>
    data:
      azure_subscription_id: <base64_encoded_azure_subscription_id>
      azure_client_id: <base64_encoded_azure_client_id>
      azure_client_secret: <base64_encoded_azure_client_secret>
      azure_tenant_id: <base64_encoded_azure_tenant_id>
      azure_resource_prefix: <base64_encoded_azure_resource_prefix>
      azure_resourcegroup: <base64_encoded_azure_resourcegroup>
      azure_region: <base64_encoded_azure_region>

重要

手動でメンテナンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。

3.8. 内部 CA を使用するようにクラスターを設定する

Azure Stack Hub 環境で内部認証局 (CA) を使用している場合は、cluster-proxy-01-config.yaml file を更新して、内部 CA を使用するようにクラスターを設定します。

前提条件

  • install-config.yaml ファイルを作成し、証明書の信頼バンドルを .pem 形式で指定します。
  • クラスターマニフェストを作成します。

手順

  1. インストールプログラムがファイルを作成するディレクトリーから、manifests ディレクトリーに移動します。
  2. user-ca-bundlespec.trustedCA.name フィールドに追加します。

    cluster-proxy-01-config.yaml ファイルの例

    apiVersion: config.openshift.io/v1
    kind: Proxy
    metadata:
      creationTimestamp: null
      name: cluster
    spec:
      trustedCA:
        name: user-ca-bundle
    status: {}

  3. オプション: manifests/ cluster-proxy-01-config.yaml ファイルをバックアップします。クラスターをデプロイすると、インストールプログラムは manifests/ ディレクトリーを消費します。

3.9. クラスターのデプロイ

互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。

重要

インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。

前提条件

  • クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
  • ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。

手順

  • インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。

    $ ./openshift-install create cluster --dir <installation_directory> \ 1
        --log-level=info 2
    1
    <installation_directory> に、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

検証

クラスターのデプロイが正常に完了すると、次のようになります。

  • ターミナルには、Web コンソールへのリンクや kubeadmin ユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。
  • 認証情報は <installation_directory>/.openshift_install.log にも出力されます。
重要

インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。

出力例

...
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com
INFO Login to the console with user: "kubeadmin", and password: "password"
INFO Time elapsed: 36m22s

重要
  • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
  • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

3.10. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.15 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

Linux への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
  3. バージョン ドロップダウンリストから適切なバージョンを選択します。
  4. OpenShift v4.17 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  5. アーカイブを展開します。

    $ tar xvf <file>
  6. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    $ echo $PATH

検証

  • OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

    $ oc <command>
Windows への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを展開します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    C:\> path

検証

  • OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

    C:\> oc <command>
macOS への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.17 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

    注記

    macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    $ oc <command>

3.11. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    $ oc whoami

    出力例

    system:admin

3.12. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

3.13. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.15 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにも、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

3.14. 次のステップ

第4章 ネットワークをカスタマイズして Azure Stack Hub にクラスターをインストールする

OpenShift Container Platform バージョン 4.15 では、インストールプログラムが Azure Stack Hub 上にプロビジョニングするインフラストラクチャーに、カスタマイズされたネットワーク設定でクラスターをインストールできます。ネットワーク設定をカスタマイズすることにより、クラスターは環境内の既存の IP アドレスの割り当てと共存でき、既存の MTU および VXLAN 設定と統合できます。

注記

インストールプログラムを使用して、installer-provisioned infrastructure を使用してクラスターをデプロイするときに、azure を選択できますが、このオプションは Azure Public Cloud でのみサポートされます。

4.1. 前提条件

4.2. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.15 では、クラスターをインストールするためにインターネットアクセスが必要になります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしないと、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。
重要

クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。

4.3. クラスターノードの SSH アクセス用のキーペアの生成

OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。

キーがノードに渡されると、キーペアを使用して RHCOS ノードにユーザー core として SSH を実行できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。

インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。

重要

障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。

注記

AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    x86_64ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      $ eval "$(ssh-agent -s)"

      出力例

      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    $ ssh-add <path>/<file_name> 1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

  • OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。

4.4. RHCOS クラスターイメージのアップロード

RHCOS 仮想ハードディスク (VHD) クラスターイメージをダウンロードし、これを Azure Stack Hub 環境にアップロードして、デプロイメント中にアクセスできるようにする必要があります。

前提条件

  • Azure アカウントを設定します。

手順

  1. RHCOS VHD クラスターイメージを取得します。

    1. RHCOS VHD の URL を環境変数にエクスポートします。

      $ export COMPRESSED_VHD_URL=$(openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.azurestack.formats."vhd.gz".disk.location')
    2. 圧縮された RHCOS VHD ファイルをローカルにダウンロードします。

      $ curl -O -L ${COMPRESSED_VHD_URL}
  2. VHD ファイルを展開します。

    注記

    展開した VHD ファイルは約 16 GB であるため、ホストシステムに 16 GB の空き領域があることを確認してください。VHD ファイルは、アップロードした後に削除できます。

  3. ローカル VHD を Azure Stack Hub 環境にアップロードし、blob が公開されていることを確認します。たとえば、az cli または Web ポータルを使用して VHD を blob にアップロードできます。

4.5. インストールプログラムの取得

OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。

前提条件

  • Linux または macOS を実行し、少なくとも 1.2 GB のローカルディスク容量を備えたコンピューターがある。

手順

  1. Red Hat Hybrid Cloud Console の Cluster Type ページに移動します。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. ページの Run it yourself セクションからインフラストラクチャープロバイダーを選択します。
  3. OpenShift Installer のドロップダウンメニューからホストオペレーティングシステムとアーキテクチャーを選択し、Download Installer をクリックします。
  4. ダウンロードしたファイルを、インストール設定ファイルを保存するディレクトリーに配置します。

    重要
    • インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。クラスターを削除するには、両方のファイルが必要です。
    • インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
  5. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  6. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
ヒント

Red Hat カスタマーポータル からインストールプログラムを取得することもできます。このページでは、ダウンロードするインストールプログラムのバージョンを指定できます。ただし、このページにアクセスするには、有効なサブスクリプションが必要です。

4.6. インストール設定ファイルの手動作成

クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。

前提条件

  • ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。

手順

  1. 必要なインストールアセットを保存するためのインストールディレクトリーを作成します。

    $ mkdir <installation_directory>
    重要

    ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

  2. 提供されるサンプルの install-config.yaml ファイルテンプレートをカスタマイズし、これを <installation_directory> に保存します。

    注記

    この設定ファイルの名前を install-config.yaml と付ける必要があります。

    次の変更を行います。

    1. 必要なインストールパラメーターを指定します。
    2. platform.azure セクションを更新して、Azure Stack Hub に固有のパラメーターを指定します。
    3. オプション: 1 つ以上のデフォルト設定パラメーターを更新して、インストールをカスタマイズします。

      パラメーターの詳細は、「インストール設定パラメーター」を参照してください。

  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。

4.6.1. Azure Stack Hub 用にカスタマイズされた install-config.yaml ファイルのサンプル

install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。

重要

このサンプルの YAML ファイルは参照用にのみ提供されます。これを使用して、手動で作成したインストール設定ファイルにパラメーター値を入力します。

apiVersion: v1
baseDomain: example.com 1
credentialsMode: Manual
controlPlane: 2 3
  name: master
  platform:
    azure:
      osDisk:
        diskSizeGB: 1024 4
        diskType: premium_LRS
  replicas: 3
compute: 5
- name: worker
  platform:
    azure:
      osDisk:
        diskSizeGB: 512 6
        diskType: premium_LRS
  replicas: 3
metadata:
  name: test-cluster 7 8
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 9
  serviceNetwork:
  - 172.30.0.0/16
platform:
  azure:
    armEndpoint: azurestack_arm_endpoint 10 11
    baseDomainResourceGroupName: resource_group 12 13
    region: azure_stack_local_region 14 15
    resourceGroupName: existing_resource_group 16
    outboundType: Loadbalancer
    cloudName: AzureStackCloud 17
    clusterOSimage: https://vhdsa.blob.example.example.com/vhd/rhcos-410.84.202112040202-0-azurestack.x86_64.vhd 18 19
pullSecret: '{"auths": ...}' 20 21
fips: false 22
sshKey: ssh-ed25519 AAAA... 23
additionalTrustBundle: | 24
    -----BEGIN CERTIFICATE-----
    <MY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
1 7 10 12 14 17 18 20
必須。
2 5
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
3
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。どちらのセクションも、現時点では単一のマシンプールを定義しますが、OpenShift Container Platform の今後のバージョンでは、インストール時の複数のコンピュートプールの定義をサポートする可能性があります。1 つのコントロールプレーンプールのみが使用されます。
4 6
使用するディスクのサイズは、GB 単位で指定できます。コントロールプレーンノードの最小推奨値は 1024 GB です。
8
クラスターの名前。
9
インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の OVNKubernetes のみです。
11
Azure Stack Hub オペレーターが提供する Azure Resource Manager エンドポイント。
13
ベースドメインの DNS ゾーンが含まれるリソースグループの名前。
15
Azure Stack Hub ローカルリージョンの名前。
16
クラスターをインストールする既存のリソースグループの名前。定義されていない場合は、クラスターに新しいリソースグループが作成されます。
19
RHCOS VHD を含む Azure Stack 環境のストレージ blob の URL。
21
クラスターを認証するために必要なプルシークレット。
22
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。

23
クラスター内のマシンにアクセスするために使用する sshKey 値をオプションで指定できます。
注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

24
Azure Stack Hub 環境で内部認証局 (CA) を使用している場合は、CA 証明書を追加する必要があります。

4.7. クラウドクレデンシャルの手動管理

Cloud Credential Operator (CCO) は、手動モードのクラウドプロバイダーのみをサポートします。そのため、クラウドプロバイダーの ID およびアクセス管理 (IAM) シークレットを指定する必要があります。

手順

  1. インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。

    $ openshift-install create manifests --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  2. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  3. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest カスタムリソース (CR) のリストを抽出します。

    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \1
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \2
      --to=<path_to_directory_for_credentials_requests> 3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。

    このコマンドにより、それぞれの CredentialsRequest オブジェクトに YAML ファイルが作成されます。

    サンプル CredentialsRequest オブジェクト

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AzureProviderSpec
        roleBindings:
        - role: Contributor
      ...

  4. 以前に生成した openshift-install マニフェストディレクトリーにシークレットの YAML ファイルを作成します。シークレットは、それぞれの CredentialsRequest オブジェクトについて spec.secretRef に定義される namespace およびシークレット名を使用して保存する必要があります。

    シークレットを含む CredentialsRequest オブジェクトのサンプル

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AzureProviderSpec
        roleBindings:
        - role: Contributor
          ...
      secretRef:
        name: <component_secret>
        namespace: <component_namespace>
      ...

    サンプル Secret オブジェクト

    apiVersion: v1
    kind: Secret
    metadata:
      name: <component_secret>
      namespace: <component_namespace>
    data:
      azure_subscription_id: <base64_encoded_azure_subscription_id>
      azure_client_id: <base64_encoded_azure_client_id>
      azure_client_secret: <base64_encoded_azure_client_secret>
      azure_tenant_id: <base64_encoded_azure_tenant_id>
      azure_resource_prefix: <base64_encoded_azure_resource_prefix>
      azure_resourcegroup: <base64_encoded_azure_resourcegroup>
      azure_region: <base64_encoded_azure_region>

重要

手動でメンテナンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。

4.8. 内部 CA を使用するようにクラスターを設定する

Azure Stack Hub 環境で内部認証局 (CA) を使用している場合は、cluster-proxy-01-config.yaml file を更新して、内部 CA を使用するようにクラスターを設定します。

前提条件

  • install-config.yaml ファイルを作成し、証明書の信頼バンドルを .pem 形式で指定します。
  • クラスターマニフェストを作成します。

手順

  1. インストールプログラムがファイルを作成するディレクトリーから、manifests ディレクトリーに移動します。
  2. user-ca-bundlespec.trustedCA.name フィールドに追加します。

    cluster-proxy-01-config.yaml ファイルの例

    apiVersion: config.openshift.io/v1
    kind: Proxy
    metadata:
      creationTimestamp: null
      name: cluster
    spec:
      trustedCA:
        name: user-ca-bundle
    status: {}

  3. オプション: manifests/ cluster-proxy-01-config.yaml ファイルをバックアップします。クラスターをデプロイすると、インストールプログラムは manifests/ ディレクトリーを消費します。

4.9. ネットワーク設定フェーズ

OpenShift Container Platform をインストールする前に、ネットワーク設定をカスタマイズできる 2 つのフェーズがあります。

フェーズ 1

マニフェストファイルを作成する前に、install-config.yaml ファイルで以下のネットワーク関連のフィールドをカスタマイズできます。

  • networking.networkType
  • networking.clusterNetwork
  • networking.serviceNetwork
  • networking.machineNetwork

    これらのフィールドの詳細は、インストール設定パラメーター を参照してください。

    注記

    優先される NIC が置かれている CIDR に一致する networking.machineNetwork を設定します。

    重要

    CIDR 範囲 172.17.0.0/16 は libVirt によって予約されています。この範囲、またはこの範囲と重複する範囲をクラスター内のネットワークに使用することはできません。

フェーズ 2
openshift-install create manifests を実行してマニフェストファイルを作成した後に、変更するフィールドのみでカスタマイズされた Cluster Network Operator マニフェストを定義できます。マニフェストを使用して、高度なネットワーク設定を指定できます。

フェーズ 2 で、install-config.yaml ファイルのフェーズ 1 で指定した値を上書きすることはできません。ただし、フェーズ 2 でネットワークプラグインをさらにカスタマイズできます。

4.10. 高度なネットワーク設定の指定

ネットワークプラグインに高度なネットワーク設定を使用し、クラスターを既存のネットワーク環境に統合することができます。高度なネットワーク設定は、クラスターのインストール前にのみ指定することができます。

重要

インストールプロブラムで作成される OpenShift Container Platform マニフェストファイルを変更してネットワーク設定をカスタマイズすることは、サポートされていません。以下の手順のように、作成するマニフェストファイルを適用することがサポートされています。

前提条件

  • install-config.yaml ファイルを作成し、これに対する変更を完了している。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。

    $ ./openshift-install create manifests --dir <installation_directory> 1
    1
    <installation_directory> は、クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。
  2. cluster-network-03-config.yml という名前の、高度なネットワーク設定用のスタブマニフェストファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
  3. 次の例のように、cluster-network-03-config.yml ファイルでクラスターの高度なネットワーク設定を指定します。

    OVN-Kubernetes ネットワークプロバイダーの IPsec を有効にする

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        ovnKubernetesConfig:
          ipsecConfig:
            mode: Full

  4. オプション: manifests/cluster-network-03-config.yml ファイルをバックアップします。インストールプログラムは、Ignition 設定ファイルの作成時に manifests/ ディレクトリーを使用します。

4.11. Cluster Network Operator (CNO) の設定

クラスターネットワークの設定は、Cluster Network Operator (CNO) 設定の一部として指定され、cluster という名前のカスタムリソース (CR) オブジェクトに保存されます。CR は operator.openshift.io API グループの Network API のフィールドを指定します。

CNO 設定は、Network.config.openshift.io API グループの Network API からクラスターのインストール時に以下のフィールドを継承します。

clusterNetwork
Pod IP アドレスの割り当てに使用する IP アドレスプール。
serviceNetwork
サービスの IP アドレスプール。
defaultNetwork.type
クラスターネットワークプラグイン。OVNKubernetes は、インストール時にサポートされる唯一のプラグインです。

defaultNetwork オブジェクトのフィールドを cluster という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプラグイン設定を指定できます。

4.11.1. Cluster Network Operator 設定オブジェクト

Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。

表4.1 Cluster Network Operator 設定オブジェクト
フィールド説明

metadata.name

string

CNO オブジェクトの名前。この名前は常に cluster です。

spec.clusterNetwork

array

Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。

spec:
  clusterNetwork:
  - cidr: 10.128.0.0/19
    hostPrefix: 23
  - cidr: 10.128.32.0/19
    hostPrefix: 23

spec.serviceNetwork

array

サービスの IP アドレスのブロック。OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。以下に例を示します。

spec:
  serviceNetwork:
  - 172.30.0.0/14

マニフェストを作成する前に、このフィールドを install-config.yaml ファイルでのみカスタマイズすることができます。この値は、マニフェストファイルでは読み取り専用です。

spec.defaultNetwork

object

クラスターネットワークのネットワークプラグインを設定します。

spec.kubeProxyConfig

object

このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプラグインを使用している場合、kube-proxy 設定は機能しません。

defaultNetwork オブジェクト設定

defaultNetwork オブジェクトの値は、以下の表で定義されます。

表4.2 defaultNetwork オブジェクト
フィールド説明

type

string

OVNKubernetes。Red Hat OpenShift Networking ネットワークプラグインは、インストール中に選択されます。この値は、クラスターのインストール後は変更できません。

注記

OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。OpenShift SDN は、新しいクラスターのインストールの選択肢として利用できなくなりました。

ovnKubernetesConfig

object

このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。

OVN-Kubernetes ネットワークプラグインの設定

次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドを説明します。

表4.3 ovnKubernetesConfig オブジェクト
フィールド説明

mtu

integer

Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。

自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。

クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも 100 小さく設定する必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1400 に設定する必要があります。

genevePort

integer

すべての Geneve パケットに使用するポート。デフォルト値は 6081 です。この値は、クラスターのインストール後は変更できません。

ipsecConfig

object

IPsec 設定をカスタマイズするための設定オブジェクトを指定します。

policyAuditConfig

object

ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。

gatewayConfig

object

オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。

注記

Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。

v4InternalSubnet

既存のネットワークインフラストラクチャーが 100.64.0.0/16 IPv4 サブネットと重複している場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。たとえば、clusterNetwork.cidr 値が 10.128.0.0/14 で、clusterNetwork.hostPrefix 値が /23 の場合、ノードの最大数は 2^(23-14)=512 です。

このフィールドは、インストール後に変更できません。

デフォルト値は 100.64.0.0/16 です。

v6InternalSubnet

既存のネットワークインフラストラクチャーが fd98::/48 IPv6 サブネットと重複する場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。

このフィールドは、インストール後に変更できません。

デフォルト値は fd98::/48 です。

表4.4 policyAuditConfig オブジェクト
フィールド説明

rateLimit

integer

ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり 20 メッセージです。

maxFileSize

integer

監査ログの最大サイズ (バイト単位)。デフォルト値は 50000000 (50MB) です。

maxLogFiles

integer

保持されるログファイルの最大数。

比較先

string

以下の追加の監査ログターゲットのいずれかになります。

libc
ホスト上の journald プロセスの libc syslog() 関数。
udp:<host>:<port>
syslog サーバー。<host>:<port> を syslog サーバーのホストおよびポートに置き換えます。
unix:<file>
<file> で指定された Unix ドメインソケットファイル。
null
監査ログを追加のターゲットに送信しないでください。

syslogFacility

string

RFC5424 で定義される kern などの syslog ファシリティー。デフォルト値は local0 です。

表4.5 gatewayConfig オブジェクト
フィールド説明

routingViaHost

boolean

Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを true に設定します。インストールおよびアプリケーションがカーネルルーティングテーブルに手動設定されたルートに依存するなど非常に特化されている場合には、Egress トラフィックをホストネットワークスタックにルーティングすることを推奨します。デフォルトでは、Egress トラフィックは OVN で処理され、クラスターを終了するために処理され、トラフィックはカーネルルーティングテーブルの特殊なルートによる影響を受けません。デフォルト値は false です。

このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドをtrueに設定すると、Egress トラフィックがホストネットワークスタックで処理されるため、パフォーマンス的に、オフロードによる利点は得られません。

ipForwarding

object

Network リソースの ipForwarding 仕様を使用して、OVN-Kubernetes マネージドインターフェイス上のすべてのトラフィックの IP フォワーディングを制御できます。Kubernetes 関連のトラフィックの IP フォワーディングのみを許可するには、Restricted を指定します。すべての IP トラフィックの転送を許可するには、Global を指定します。新規インストールの場合、デフォルトは Restricted です。OpenShift Container Platform 4.14 以降に更新する場合、デフォルトは Global です。

表4.6 ipsecConfig オブジェクト
フィールド説明

mode

string

IPsec 実装の動作を指定します。次の値のいずれかである必要があります。

  • Disabled: クラスターノードで IPsec が有効になりません。
  • External: 外部ホストとのネットワークトラフィックに対して IPsec が有効になります。
  • Full: Pod トラフィックおよび外部ホストとのネットワークトラフィックに対して IPsec が有効になります。

IPsec が有効な OVN-Kubernetes 設定の例

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
      ipsecConfig:
        mode: Full

重要

OVNKubernetes を使用すると、IBM Power® でスタック枯渇の問題が発生する可能性があります。

kubeProxyConfig オブジェクト設定 (OpenShiftSDN コンテナーネットワークインターフェイスのみ)

kubeProxyConfig オブジェクトの値は以下の表で定義されます。

表4.7 kubeProxyConfig オブジェクト
フィールド説明

iptablesSyncPeriod

string

iptables ルールの更新期間。デフォルト値は 30s です。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ ドキュメントで説明されています。

注記

OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、iptablesSyncPeriod パラメーターを調整する必要はなくなりました。

proxyArguments.iptables-min-sync-period

array

iptables ルールを更新する前の最小期間。このフィールドにより、更新の頻度が高くなり過ぎないようにできます。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ で説明されています。デフォルト値:

kubeProxyConfig:
  proxyArguments:
    iptables-min-sync-period:
    - 0s

4.12. OVN-Kubernetes を使用したハイブリッドネットワークの設定

OVN-Kubernetes ネットワークプラグインを使用してハイブリッドネットワークを使用するようにクラスターを設定できます。これにより、異なるノードのネットワーク設定をサポートするハイブリッドクラスターが可能になります。

注記

この設定は、同じクラスター内で Linux ノードと Windows ノードの両方を実行するために必要です。

前提条件

  • install-config.yaml ファイルで networking.networkType パラメーターの OVNKubernetes を定義していること。詳細は、選択したクラウドプロバイダーでの OpenShift Container Platform ネットワークのカスタマイズの設定に関するインストールドキュメントを参照してください。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。

    $ ./openshift-install create manifests --dir <installation_directory>

    ここでは、以下のようになります。

    <installation_directory>
    クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。
  2. cluster-network-03-config.yml という名前の、高度なネットワーク設定用のスタブマニフェストファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

    $ cat <<EOF > <installation_directory>/manifests/cluster-network-03-config.yml
    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
    EOF

    ここでは、以下のようになります。

    <installation_directory>
    クラスターの manifests/ ディレクトリーが含まれるディレクトリー名を指定します。
  3. cluster-network-03-config.yml ファイルをエディターで開き、次の例のようにハイブリッドネットワークを使用して OVN-Kubernetes を設定します。

    ハイブリッドネットワーク設定の指定

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        ovnKubernetesConfig:
          hybridOverlayConfig:
            hybridClusterNetwork: 1
            - cidr: 10.132.0.0/14
              hostPrefix: 23
            hybridOverlayVXLANPort: 9898 2

    1
    追加のオーバーレイネットワーク上のノードに使用される CIDR 設定を指定します。hybridClusterNetwork CIDR は clusterNetwork CIDR と重複できません。
    2
    追加のオーバーレイネットワークのカスタム VXLAN ポートを指定します。これは、vSphere にインストールされたクラスターで Windows ノードを実行するために必要であり、その他のクラウドプロバイダー用に設定することはできません。カスタムポートには、デフォルトの 4789 ポートを除くいずれかのオープンポートを使用できます。この要件の詳細は、Microsoft ドキュメントの Pod-to-pod connectivity between hosts is broken を参照してください。
    注記

    Windows Server Long-Term Servicing Channel (LTSC): Windows Server 2019 は、カスタムの VXLAN ポートの選択をサポートしないため、カスタムの hybridOverlayVXLANPort 値を持つクラスターではサポートされません。

  4. cluster-network-03-config.yml ファイルを保存し、テキストエディターを終了します。
  5. オプション: manifests/cluster-network-03-config.yml ファイルをバックアップします。インストールプログラムは、クラスターの作成時に manifests/ ディレクトリーを削除します。
注記

同じクラスターで Linux ノードと Windows ノードを使用する方法の詳細は、Windows コンテナーワークロードについて を参照してください。

4.13. クラスターのデプロイ

互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。

重要

インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。

前提条件

  • クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
  • ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。

手順

  • インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。

    $ ./openshift-install create cluster --dir <installation_directory> \ 1
        --log-level=info 2
    1
    <installation_directory> に、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

検証

クラスターのデプロイが正常に完了すると、次のようになります。

  • ターミナルには、Web コンソールへのリンクや kubeadmin ユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。
  • 認証情報は <installation_directory>/.openshift_install.log にも出力されます。
重要

インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。

出力例

...
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com
INFO Login to the console with user: "kubeadmin", and password: "password"
INFO Time elapsed: 36m22s

重要
  • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
  • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

4.14. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.15 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

Linux への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
  3. バージョン ドロップダウンリストから適切なバージョンを選択します。
  4. OpenShift v4.17 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  5. アーカイブを展開します。

    $ tar xvf <file>
  6. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    $ echo $PATH

検証

  • OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

    $ oc <command>
Windows への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを展開します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    C:\> path

検証

  • OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

    C:\> oc <command>
macOS への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.17 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

    注記

    macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    $ oc <command>

4.15. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    $ oc whoami

    出力例

    system:admin

4.16. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

4.17. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.15 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにも、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

4.18. 次のステップ

第5章 ARM テンプレートを使用したクラスターの Azure Stack Hub へのインストール

OpenShift Container Platform バージョン 4.15 では、独自に提供するインフラストラクチャーを使用して、Microsoft Azure Stack Hub にクラスターをインストールできます。

これらの手順を実行するか、独自の手順を作成するのに役立つ複数の Azure Resource Manager (ARM) テンプレートが提供されます。

重要

user-provisioned infrastructure のインストールする手順は、例としてのみ提供されます。独自にプロビジョニングするインフラストラクチャーでクラスターをインストールするには、クラウドプロバイダーおよび OpenShift Container Platform のインストールプロセスを理解している必要があります。これらの手順を実行するか、独自の手順を作成するのに役立つ複数の ARM テンプレートが提供されます。他の方法を使用して必要なリソースを作成することもできます。これらのテンプレートはサンプルとしてのみ提供されます。

5.1. 前提条件

5.2. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.15 では、クラスターをインストールするためにインターネットアクセスが必要になります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしないと、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。
重要

クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。

5.3. Azure Stack Hub プロジェクトの設定

OpenShift Container Platform をインストールする前に、これをホストするために Azure プロジェクトを設定する必要があります。

重要

パブリックエンドポイントで利用可能なすべての Azure Stack Hub リソースはリソース名の制限を受けるため、特定の用語を使用するリソースを作成することはできません。Azure Stack Hub が制限する用語のリストは、Azure ドキュメントの 予約されたリソース名のエラーを解決する を参照してください。

5.3.1. Azure Stack Hub アカウントの制限

OpenShift Container Platform クラスターは数多くの Microsoft Azure Stack Hub コンポーネントを使用し、デフォルトの Azure Stack Hub のクォータタイプ は、OpenShift Container Platform クラスターをインストールする機能に影響を与えます。

以下の表は、OpenShift Container Platform クラスターのインストールおよび実行機能に影響を与える可能性のある Azure Stack Hub コンポーネントの制限を要約しています。

コンポーネントデフォルトで必要なコンポーネントの数説明

仮想 CPU

56

デフォルトのクラスターには 56 vCPU が必要であるため、アカウントの上限を引き上げる必要があります。

デフォルトで、各クラスターは以下のインスタンスを作成します。

  • 1 つのブートストラップマシン。これはインストール後に削除されます。
  • 3 つのコントロールプレーンマシン
  • 3 つのコンピュートマシン

ブートストラップ、コントロールプレーン、およびワーカーマシンは 8 vCPU を使用する Standard_DS4_v2 仮想マシンを使用するため、デフォルトのクラスターには 56 vCPU が必要です。ブートストラップノードの仮想マシンはインストール時にのみ使用されます。

追加のワーカーノードをデプロイし、自動スケーリングを有効にし、大規模なワークロードをデプロイするか、異なるインスタンスタイプを使用するには、アカウントの vCPU 制限をさらに引き上げ、クラスターが必要なマシンをデプロイできるようにする必要があります。

VNet

1

各デフォルトクラスターには、2 つのサブネットを含む 1 つの Virtual Network (VNet) が必要です。

ネットワークインターフェイス

7

各デフォルトクラスターには、7 つのネットワークインターフェイスが必要です。さらに多くのマシンを作成したり、デプロイしたワークロードでロードバランサーを作成する場合、クラスターは追加のネットワークインターフェイスを使用します。

ネットワークセキュリティーグループ

2

各クラスターは VNet の各サブネットにネットワークセキュリティーグループを作成します。デフォルトのクラスターは、コントロールプレーンおよびコンピュートノードのサブネットにネットワークセキュリティーグループを作成します。

controlplane

任意の場所からコントロールプレーンマシンにポート 6443 でアクセスできるようにします。

node

インターネットからワーカーノードにポート 80 および 443 でアクセスできるようにします。

ネットワークロードバランサー

3

各クラスターは以下の ロードバランサー を作成します。

default

ワーカーマシン間でポート 80 および 443 での要求の負荷分散を行うパブリック IP アドレス

internal

コントロールプレーンマシン間でポート 6443 および 22623 での要求の負荷分散を行うプライベート IP アドレス

external

コントロールプレーンマシン間でポート 6443 での要求の負荷分散を行うパブリック IP アドレス

アプリケーションが追加の Kubernetes LoadBalancer サービスオブジェクトを作成すると、クラスターは追加のロードバランサーを使用します。

パブリック IP アドレス

2

パブリックロードバランサーはパブリック IP アドレスを使用します。ブートストラップマシンは、インストール時のトラブルシューティングのためにマシンに SSH を実行できるようにパブリック IP アドレスも使用します。ブートストラップノードの IP アドレスは、インストール時にのみ使用されます。

プライベート IP アドレス

7

内部ロードバランサー、3 つのコントロールプレーンマシンのそれぞれ、および 3 つのワーカーマシンのそれぞれはプライベート IP アドレスを使用します。

5.3.2. Azure Stack Hub での DNS ゾーンの設定

OpenShift Container Platform を Azure Stack Hub に正常にインストールするには、Azure Stack Hub DNS ゾーンに DNS レコードを作成する必要があります。DNS ゾーンはドメインに対する権威を持っている必要があります。レジストラーの DNS ゾーンを Azure Stack Hub に委譲するには、Microsoft の Azure Stack Hub データセンター DNS 統合 に関するドキュメントを参照してください。

この DNS ゾーンの作成例 を参照し、Azure の DNS ソリューションを確認することができます。

5.3.3. 証明書署名要求の管理

ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager は kubelet クライアント CSR のみを承認します。machine-approver は、kubelet 認証情報を使用して要求される提供証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。

5.3.4. 必要な Azure Stack Hub ロール

Microsoft Azure Stack Hub アカウントには、使用するサブスクリプションについて以下のロールが必要です。

  • Owner

Azure ポータルでロールを設定するには、Microsoft ドキュメントの Manage access to resources in Azure Stack Hub with role-based access control を参照してください。

5.3.5. サービスプリンシパルの作成

OpenShift Container Platform とそのインストールプログラムは Azure Resource Manager を使用して Microsoft Azure リソースを作成するため、それを表すサービスプリンシパルを作成する必要があります。

前提条件

  • Azure CLI のインストールまたは更新を実行します。
  • Azure アカウントには、使用するサブスクリプションに必要なロールがなければなりません。

手順

  1. 環境を登録します。

    $ az cloud register -n AzureStackCloud --endpoint-resource-manager <endpoint> 1
    1
    Azure Resource Manager エンドポイント `https://management.<region>.<fqdn>/` を指定します。

    詳細は、Microsoft のドキュメント を参照してください。

  2. アクティブな環境を設定します。

    $ az cloud set -n AzureStackCloud
  3. Azure Stack Hub に特定の API バージョンを使用するように、環境設定を更新します。

    $ az cloud update --profile 2019-03-01-hybrid
  4. Azure CLI にログインします。

    $ az login

    マルチテナント環境の場合は、テナント ID も指定する必要があります。

  5. Azure アカウントでサブスクリプションを使用している場合は、適切なサブスクリプションを使用していることを確認してください。

    1. 利用可能なアカウントの一覧を表示し、クラスターに使用するサブスクリプションの tenantId の値を記録します。

      $ az account list --refresh

      出力例

      [
        {
          "cloudName": AzureStackCloud",
          "id": "9bab1460-96d5-40b3-a78e-17b15e978a80",
          "isDefault": true,
          "name": "Subscription Name",
          "state": "Enabled",
          "tenantId": "6057c7e9-b3ae-489d-a54e-de3f6bf6a8ee",
          "user": {
            "name": "you@example.com",
            "type": "user"
          }
        }
      ]

    2. アクティブなアカウントの詳細を表示し、tenantId 値が使用するサブスクリプションと一致することを確認します。

      $ az account show

      出力例

      {
        "environmentName": AzureStackCloud",
        "id": "9bab1460-96d5-40b3-a78e-17b15e978a80",
        "isDefault": true,
        "name": "Subscription Name",
        "state": "Enabled",
        "tenantId": "6057c7e9-b3ae-489d-a54e-de3f6bf6a8ee", 1
        "user": {
          "name": "you@example.com",
          "type": "user"
        }
      }

      1
      tenantId パラメーターの値が正しいサブスクリプション ID であることを確認してください。
    3. 適切なサブスクリプションを使用していない場合には、アクティブなサブスクリプションを変更します。

      $ az account set -s <subscription_id> 1
      1
      サブスクリプション ID を指定します。
    4. サブスクリプション ID の更新を確認します。

      $ az account show

      出力例

      {
        "environmentName": AzureStackCloud",
        "id": "33212d16-bdf6-45cb-b038-f6565b61edda",
        "isDefault": true,
        "name": "Subscription Name",
        "state": "Enabled",
        "tenantId": "8049c7e9-c3de-762d-a54e-dc3f6be6a7ee",
        "user": {
          "name": "you@example.com",
          "type": "user"
        }
      }

  6. 出力から tenantId および id パラメーター値を記録します。OpenShift Container Platform のインストール時にこれらの値が必要になります。
  7. アカウントのサービスプリンシパルを作成します。

    $ az ad sp create-for-rbac --role Contributor --name <service_principal> \ 1
      --scopes /subscriptions/<subscription_id> 2
      --years <years> 3
    1
    サービスプリンシパル名を指定します。
    2
    サブスクリプション ID を指定します。
    3
    年数を指定します。デフォルトでは、サービスプリンシパルは 1 年で期限切れになります。--years オプションを使用すると、サービスプリンシパルの有効期間を延長できます。

    出力例

    Creating 'Contributor' role assignment under scope '/subscriptions/<subscription_id>'
    The output includes credentials that you must protect. Be sure that you do not
    include these credentials in your code or check the credentials into your source
    control. For more information, see https://aka.ms/azadsp-cli
    {
      "appId": "ac461d78-bf4b-4387-ad16-7e32e328aec6",
      "displayName": <service_principal>",
      "password": "00000000-0000-0000-0000-000000000000",
      "tenantId": "8049c7e9-c3de-762d-a54e-dc3f6be6a7ee"
    }

  8. 直前の出力の appId および password パラメーターの値を記録します。OpenShift Container Platform のインストール時にこれらの値が必要になります。

関連情報

5.4. インストールプログラムの取得

OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。

前提条件

  • Linux または macOS を実行し、少なくとも 1.2 GB のローカルディスク容量を備えたコンピューターがある。

手順

  1. Red Hat Hybrid Cloud Console の Cluster Type ページに移動します。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. ページの Run it yourself セクションからインフラストラクチャープロバイダーを選択します。
  3. OpenShift Installer のドロップダウンメニューからホストオペレーティングシステムとアーキテクチャーを選択し、Download Installer をクリックします。
  4. ダウンロードしたファイルを、インストール設定ファイルを保存するディレクトリーに配置します。

    重要
    • インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。クラスターを削除するには、両方のファイルが必要です。
    • インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
  5. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  6. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
ヒント

Red Hat カスタマーポータル からインストールプログラムを取得することもできます。このページでは、ダウンロードするインストールプログラムのバージョンを指定できます。ただし、このページにアクセスするには、有効なサブスクリプションが必要です。

5.5. クラスターノードの SSH アクセス用のキーペアの生成

OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。

キーがノードに渡されると、キーペアを使用して RHCOS ノードにユーザー core として SSH を実行できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。

インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。

重要

障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。

注記

AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    x86_64ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      $ eval "$(ssh-agent -s)"

      出力例

      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    $ ssh-add <path>/<file_name> 1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

  • OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。

5.6. Azure Stack Hub のインストールファイルの作成

user-provisioned infrastructure を使用して OpenShift Container Platform を Microsoft Azure Stack Hub にインストールするには、インストールプログラムがクラスターをデプロイするために必要なファイルを生成し、クラスターが使用するマシンのみを作成するようにそれらのファイルを変更する必要があります。install-config.yaml ファイルを手動で作成し、Kubernetes マニフェストおよび Ignition 設定ファイルを生成し、カスタマイズします。また、インストールの準備フェーズ時にまず別の var パーティションを設定するオプションもあります。

5.6.1. インストール設定ファイルの手動作成

クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。

前提条件

  • ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。

手順

  1. 必要なインストールアセットを保存するためのインストールディレクトリーを作成します。

    $ mkdir <installation_directory>
    重要

    ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

  2. 提供されるサンプルの install-config.yaml ファイルテンプレートをカスタマイズし、これを <installation_directory> に保存します。

    注記

    この設定ファイルの名前を install-config.yaml と付ける必要があります。

    Azure Stack Hub について以下の変更を加えます。

    1. compute プールの replicas パラメーターを 0 に設定します。

      compute:
      - hyperthreading: Enabled
        name: worker
        platform: {}
        replicas: 0 1
      1
      0 に設定します。

      コンピュートマシンは後で手動でプロビジョニングされます。

    2. install-config.yaml ファイルの platform.azure セクションを更新し、Azure Stack Hub 設定を設定します。

      platform:
        azure:
          armEndpoint: <azurestack_arm_endpoint> 1
          baseDomainResourceGroupName: <resource_group> 2
          cloudName: AzureStackCloud 3
          region: <azurestack_region> 4
      1
      https://management.local.azurestack.external など、Azure Stack Hub 環境の Azure Resource Manager エンドポイントを指定します。
      2
      ベースドメインの DNS ゾーンが含まれるリソースグループの名前を指定します。
      3
      適切な Azure API エンドポイントで Azure SDK を設定するために使用される Azure Stack Hub 環境を指定します。
      4
      Azure Stack Hub リージョンの名前を指定します。
  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。

5.6.2. Azure Stack Hub 用にカスタマイズされた install-config.yaml ファイルのサンプル

install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。

重要

このサンプルの YAML ファイルは参照用にのみ提供されます。これを使用して、手動で作成したインストール設定ファイルにパラメーター値を入力します。

apiVersion: v1
baseDomain: example.com
controlPlane: 1
  name: master
  platform:
    azure:
      osDisk:
        diskSizeGB: 1024 2
        diskType: premium_LRS
  replicas: 3
compute: 3
- name: worker
  platform:
    azure:
      osDisk:
        diskSizeGB: 512 4
        diskType: premium_LRS
  replicas: 0
metadata:
  name: test-cluster 5
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 6
  serviceNetwork:
  - 172.30.0.0/16
platform:
  azure:
    armEndpoint: azurestack_arm_endpoint 7
    baseDomainResourceGroupName: resource_group 8
    region: azure_stack_local_region 9
    resourceGroupName: existing_resource_group 10
    outboundType: Loadbalancer
    cloudName: AzureStackCloud 11
pullSecret: '{"auths": ...}' 12
fips: false 13
additionalTrustBundle: | 14
    -----BEGIN CERTIFICATE-----
    <MY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
sshKey: ssh-ed25519 AAAA... 15
1 3
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
2 4
使用するディスクのサイズは、GB 単位で指定できます。コントロールプレーンノードの最小推奨値は 1024 GB です。
5
クラスターの名前を指定します。
6
インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の OVNKubernetes のみです。
7
Azure Stack Hub Operator が提供する Azure Resource Manager エンドポイントを指定します。
8
ベースドメインの DNS ゾーンが含まれるリソースグループの名前を指定します。
9
Azure Stack Hub ローカルリージョンの名前を指定します。
10
クラスターをインストールする既存のリソースグループの名前を指定します。定義されていない場合は、クラスターに新しいリソースグループが作成されます。
11
Azure Stack Hub 環境をターゲットプラットフォームとして指定します。
12
クラスターの認証に必要なプルシークレットを指定します。
13
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。

14
Azure Stack Hub 環境で内部認証局 (CA) を使用している場合は、必要な証明書バンドルを .pem 形式で追加します。
15
クラスター内のマシンにアクセスするために使用する sshKey 値をオプションで指定できます。
注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

5.6.3. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。

前提条件

  • 既存の install-config.yaml ファイルがある。
  • クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを Proxy オブジェクトの spec.noProxy フィールドに追加している。

    注記

    Proxy オブジェクトの status.noProxy フィールドには、インストール設定の networking.machineNetwork[].cidrnetworking.clusterNetwork[].cidr、および networking.serviceNetwork[] フィールドの値が設定されます。

    Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、Proxy オブジェクトの status.noProxy フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    apiVersion: v1
    baseDomain: my.domain.com
    proxy:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 1
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 2
      noProxy: example.com 3
    additionalTrustBundle: | 4
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 5
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。
    4
    指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる user-ca-bundle という名前の設定マップを openshift-config namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージする trusted-ca-bundle 設定マップを作成し、この設定マップは Proxy オブジェクトの trustedCA フィールドで参照されます。additionalTrustBundle フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
    5
    オプション: trustedCA フィールドの user-ca-bundle 設定マップを参照する Proxy オブジェクトの設定を決定するポリシー。許可される値は Proxyonly および Always です。Proxyonly を使用して、http/https プロキシーが設定されている場合にのみ user-ca-bundle 設定マップを参照します。Always を使用して、常に user-ca-bundle 設定マップを参照します。デフォルト値は Proxyonly です。
    注記

    インストールプログラムは、プロキシーの readinessEndpoints フィールドをサポートしません。

    注記

    インストーラーがタイムアウトした場合は、インストーラーの wait-for コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。

    $ ./openshift-install wait-for install-complete --log-level debug
  2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。

注記

cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

5.6.4. ARM テンプレートの一般的な変数のエクスポート

ユーザーによって提供されるインフラストラクチャーのインストールを Microsoft Azure Stack Hub で実行するのに役立つ指定の Azure Resource Manager (ARM) テンプレートで使用される一般的な変数のセットをエクスポートする必要があります。

注記

特定の ARM テンプレートには、追加のエクスポートされる変数が必要になる場合があります。これについては、関連する手順で詳しく説明されています。

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。

手順

  1. 提供される ARM テンプレートで使用される install-config.yaml にある一般的な変数をエクスポートします。

    $ export CLUSTER_NAME=<cluster_name>1
    $ export AZURE_REGION=<azure_region>2
    $ export SSH_KEY=<ssh_key>3
    $ export BASE_DOMAIN=<base_domain>4
    $ export BASE_DOMAIN_RESOURCE_GROUP=<base_domain_resource_group>5
    1
    install-config.yaml ファイルからの .metadata.name 属性の値。
    2
    クラスターをデプロイするリージョンを選択します。これは、install-config.yaml ファイルからの .platform.azure.region 属性の値です。
    3
    文字列としての SSH RSA 公開鍵ファイル。SSH キーは、スペースが含まれているために引用符で囲む必要があります。これは、install-config.yaml ファイルからの .sshKey 属性の値です。
    4
    クラスターをデプロイするベースドメイン。ベースドメインは、クラスターに作成した DNS ゾーンに対応します。これは、install-config.yaml からの .baseDomain 属性の値です。
    5
    DNS ゾーンが存在するリソースグループ。これは、install-config.yaml ファイルからの .platform.azure.baseDomainResourceGroupName 属性の値です。

    以下に例を示します。

    $ export CLUSTER_NAME=test-cluster
    $ export AZURE_REGION=centralus
    $ export SSH_KEY="ssh-rsa xxx/xxx/xxx= user@email.com"
    $ export BASE_DOMAIN=example.com
    $ export BASE_DOMAIN_RESOURCE_GROUP=ocp-cluster
  2. kubeadmin 認証情報をエクスポートします。

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

5.6.5. Kubernetes マニフェストおよび Ignition 設定ファイルの作成

一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。

インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターマシンを設定するために後で使用されます。

重要
  • OpenShift Container Platform のインストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
  • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

前提条件

  • OpenShift Container Platform インストールプログラムを取得していること。
  • install-config.yaml インストール設定ファイルを作成していること。

手順

  1. OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。

    $ ./openshift-install create manifests --dir <installation_directory> 1
    1
    <installation_directory> には、作成した install-config.yaml ファイルが含まれるインストールディレクトリーを指定します。
  2. コントロールプレーンマシンを定義する Kubernetes マニフェストファイルを削除します。

    $ rm -f <installation_directory>/openshift/99_openshift-cluster-api_master-machines-*.yaml

    これらのファイルを削除することで、クラスターがコントロールプレーンマシンを自動的に生成するのを防ぐことができます。

  3. コントロールプレーンマシンセットを定義する Kubernetes マニフェストファイルを削除します。

    $ rm -f <installation_directory>/openshift/99_openshift-machine-api_master-control-plane-machine-set.yaml
  4. ワーカーマシンを定義する Kubernetes マニフェストファイルを削除します。

    $ rm -f <installation_directory>/openshift/99_openshift-cluster-api_worker-machineset-*.yaml
    重要

    user-provisioned infrastructure にクラスターをインストールするときに MachineAPI 機能を無効にした場合は、ワーカーマシンを定義する Kubernetes マニフェストファイルを削除する必要があります。そうしないと、クラスターのインストールに失敗します。

    ワーカーマシンは独自に作成し、管理するため、これらのマシンを初期化する必要はありません。

  5. <installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes マニフェストファイルの mastersSchedulable パラメーターが false に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。

    1. <installation_directory>/manifests/cluster-scheduler-02-config.yml ファイルを開きます。
    2. mastersSchedulable パラメーターを見つけ、これが false に設定されていることを確認します。
    3. ファイルを保存し、終了します。
  6. オプション: Ingress Operator を DNS レコードを作成するよう設定する必要がない場合は、<installation_directory>/manifests/cluster-dns-02-config.yml DNS 設定ファイルから privateZone および publicZone セクションを削除します。

    apiVersion: config.openshift.io/v1
    kind: DNS
    metadata:
      creationTimestamp: null
      name: cluster
    spec:
      baseDomain: example.openshift.com
      privateZone: 1
        id: mycluster-100419-private-zone
      publicZone: 2
        id: example.openshift.com
    status: {}
    1 2
    このセクションを完全に削除します。

    これを実行する場合、後のステップで Ingress DNS レコードを手動で追加する必要があります。

  7. オプション: Azure Stack Hub 環境で内部認証局 (CA) を使用する場合には、<installation_directory>/manifests/cluster-proxy-01-config.yaml.spec.trustedCA.name フィールドを更新して、user-ca-bundle を使用する必要があります。

    ...
    spec:
      trustedCA:
        name: user-ca-bundle
    ...

    後で、CA を含めるようにブートストラップ Ignition を更新する必要があります。

  8. user-provisioned infrastructure で Azure を設定する場合、Azure Resource Manager (ARM) テンプレートで後に使用するためにマニフェストファイルに定義された一般的な変数の一部をエクスポートする必要があります。

    1. 以下のコマンドを使用してインフラストラクチャー ID をエクスポートします。

      $ export INFRA_ID=<infra_id> 1
      1
      OpenShift Container Platform クラスターには、<cluster_name>-<random_string> の形式の識別子 (INFRA_ID) が割り当てられます。これは、提供される ARM テンプレートを使用して作成されるほとんどのリソースのベース名として使用されます。これは、manifests/cluster-infrastructure-02-config.yml ファイルからの .status.infrastructureName 属性の値です。
    2. 以下のコマンドを使用してリソースグループをエクスポートします。

      $ export RESOURCE_GROUP=<resource_group> 1
      1
      この Azure デプロイメントで作成されたすべてのリソースは、リソースグループ の一部として存在します。リソースグループ名は、<cluster_name>-<random_string>-rg 形式の INFRA_ID をベースとしています。これは、manifests/cluster-infrastructure-02-config.yml ファイルからの .status.platformStatus.azure.resourceGroupName 属性の値です。
  9. クラウド認証情報を手動で作成します。

    1. インストールプログラムが含まれるディレクトリーから、openshift-install バイナリーがビルドされる OpenShift Container Platform リリースイメージの詳細を取得します。

      $ openshift-install version

      出力例

      release image quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64

    2. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

      $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
    3. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest カスタムリソース (CR) のリストを抽出します。

      $ oc adm release extract \
        --from=$RELEASE_IMAGE \
        --credentials-requests \
        --included \1
        --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \2
        --to=<path_to_directory_for_credentials_requests> 3
      1
      --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
      2
      install-config.yaml ファイルの場所を指定します。
      3
      CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。

      このコマンドにより、それぞれの CredentialsRequest オブジェクトに YAML ファイルが作成されます。

      サンプル CredentialsRequest オブジェクト

      apiVersion: cloudcredential.openshift.io/v1
      kind: CredentialsRequest
      metadata:
        labels:
          controller-tools.k8s.io: "1.0"
        name: openshift-image-registry-azure
        namespace: openshift-cloud-credential-operator
      spec:
        secretRef:
          name: installer-cloud-credentials
          namespace: openshift-image-registry
        providerSpec:
          apiVersion: cloudcredential.openshift.io/v1
          kind: AzureProviderSpec
          roleBindings:
          - role: Contributor

    4. 以前に生成した openshift-install マニフェストディレクトリーにシークレットの YAML ファイルを作成します。シークレットは、それぞれの CredentialsRequest オブジェクトについて spec.secretRef に定義される namespace およびシークレット名を使用して保存する必要があります。シークレットデータの形式は、クラウドプロバイダーごとに異なります。

      secrets.yaml ファイルのサンプル:

      apiVersion: v1
      kind: Secret
      metadata:
          name: ${secret_name}
          namespace: ${secret_namespace}
      stringData:
        azure_subscription_id: ${subscription_id}
        azure_client_id: ${app_id}
        azure_client_secret: ${client_secret}
        azure_tenant_id: ${tenant_id}
        azure_resource_prefix: ${cluster_name}
        azure_resourcegroup: ${resource_group}
        azure_region: ${azure_region}

    5. Cloud Credential Operator (CCO) を無効にして manifests ディレクトリーに cco-configmap.yaml ファイルを作成します。

      サンプル ConfigMap オブジェクト

      apiVersion: v1
      kind: ConfigMap
      metadata:
      name: cloud-credential-operator-config
      namespace: openshift-cloud-credential-operator
        annotations:
          release.openshift.io/create-only: "true"
      data:
        disabled: "true"

  10. Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。

    $ ./openshift-install create ignition-configs --dir <installation_directory> 1
    1
    <installation_directory> には、同じインストールディレクトリーを指定します。

    Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。kubeadmin-password および kubeconfig ファイルが ./<installation_directory>/auth ディレクトリーに作成されます。

    .
    ├── auth
    │   ├── kubeadmin-password
    │   └── kubeconfig
    ├── bootstrap.ign
    ├── master.ign
    ├── metadata.json
    └── worker.ign

5.6.6. オプション: 別個の /var パーティションの作成

OpenShift Container Platform のディスクパーティション設定はインストーラー側で行う必要があります。ただし、拡張予定のファイルシステムの一部に個別のパーティションの作成が必要となる場合もあります。

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

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

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

/var は、Red Hat Enterprise Linux CoreOS (RHCOS) の新規インストール前に有効にする必要があるため、以下の手順では OpenShift Container Platform インストールの openshift-install の準備フェーズで挿入されるマシン設定マニフェストを作成して、別の /var パーティションを設定します。

重要

この手順で個別の /var パーティションを作成する手順を実行する場合、このセクションで後に説明されるように、Kubernetes マニフェストおよび Ignition 設定ファイルを再び作成する必要はありません。

手順

  1. OpenShift Container Platform インストールファイルを保存するディレクトリーを作成します。

    $ mkdir $HOME/clusterconfig
  2. openshift-install を実行して、manifest および openshift のサブディレクトリーにファイルのセットを作成します。プロンプトが表示されたら、システムの質問に回答します。

    $ openshift-install create manifests --dir $HOME/clusterconfig

    出力例

    ? SSH Public Key ...
    INFO Credentials loaded from the "myprofile" profile in file "/home/myuser/.aws/credentials"
    INFO Consuming Install Config from target directory
    INFO Manifests created in: $HOME/clusterconfig/manifests and $HOME/clusterconfig/openshift

  3. オプション: インストールプログラムで clusterconfig/openshift ディレクトリーにマニフェストが作成されたことを確認します。

    $ ls $HOME/clusterconfig/openshift/

    出力例

    99_kubeadmin-password-secret.yaml
    99_openshift-cluster-api_master-machines-0.yaml
    99_openshift-cluster-api_master-machines-1.yaml
    99_openshift-cluster-api_master-machines-2.yaml
    ...

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

    variant: openshift
    version: 4.15.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 MiB (メビバイト) の最小値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。
    3
    データパーティションのサイズ (メビバイト単位)。
    4
    コンテナーストレージに使用されるファイルシステムでは、prjquota マウントオプションを有効にする必要があります。
    注記

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

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

    $ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
  6. openshift-install を再度実行し、manifest および openshift のサブディレクトリー内のファイルセットから、Ignition 設定を作成します。

    $ openshift-install create ignition-configs --dir $HOME/clusterconfig
    $ ls $HOME/clusterconfig/
    auth  bootstrap.ign  master.ign  metadata.json  worker.ign

Ignition 設定ファイルを Red Hat Enterprise Linux CoreOS (RHCOS) システムをインストールするためにインストール手順への入力として使用できます。

5.7. Azure リソースグループの作成

Microsoft Azure リソースグループ を作成する必要があります。これは Azure Stack Hub での OpenShift Container Platform クラスターのインストール時に使用されます。

前提条件

  • Azure アカウントを設定します。
  • クラスターの Ignition 設定ファイルを生成します。

手順

  • サポートされる Azure リージョンにリソースグループを作成します。

    $ az group create --name ${RESOURCE_GROUP} --location ${AZURE_REGION}

5.8. RHCOS クラスターイメージおよびブートストラップ Ignition 設定ファイルのアップロード

Azure クライアントは、ローカルに存在するファイルに基づくデプロイメントをサポートしていません。RHCOS 仮想ハードディスク (VHD) クラスターイメージとブートストラップ Ignition 設定ファイルをコピーしてストレージコンテナーに保存し、デプロイメント中にアクセスできるようにする必要があります。

前提条件

  • Azure アカウントを設定します。
  • クラスターの Ignition 設定ファイルを生成します。

手順

  1. VHD クラスターイメージを保存するために Azure ストレージアカウントを作成します。

    $ az storage account create -g ${RESOURCE_GROUP} --location ${AZURE_REGION} --name ${CLUSTER_NAME}sa --kind Storage --sku Standard_LRS
    警告

    Azure ストレージアカウント名は 3 文字から 24 文字の長さで、数字および小文字のみを使用する必要があります。CLUSTER_NAME 変数がこれらの制限に準拠しない場合、Azure ストレージアカウント名を手動で定義する必要があります。Azure ストレージアカウント名の制限の詳細は、Azure ドキュメントの Resolve errors for storage account names を参照してください。

  2. ストレージアカウントキーを環境変数としてエクスポートします。

    $ export ACCOUNT_KEY=`az storage account keys list -g ${RESOURCE_GROUP} --account-name ${CLUSTER_NAME}sa --query "[0].value" -o tsv`
  3. RHCOS VHD の URL を環境変数にエクスポートします。

    $ export COMPRESSED_VHD_URL=$(openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.azurestack.formats."vhd.gz".disk.location')
    重要

    RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージを指定する必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。

  4. VHD のストレージコンテナーを作成します。

    $ az storage container create --name vhd --account-name ${CLUSTER_NAME}sa --account-key ${ACCOUNT_KEY}
  5. 圧縮された RHCOS VHD ファイルをローカルにダウンロードします。

    $ curl -O -L ${COMPRESSED_VHD_URL}
  6. VHD ファイルを展開します。

    注記

    展開した VHD ファイルは約 16 GB であるため、ホストシステムに 16 GB の空き領域があることを確認してください。VHD ファイルはアップロード後に削除できます。

  7. ローカル VHD を blob にコピーします。

    $ az storage blob upload --account-name ${CLUSTER_NAME}sa --account-key ${ACCOUNT_KEY} -c vhd -n "rhcos.vhd" -f rhcos-<rhcos_version>-azurestack.x86_64.vhd
  8. blob ストレージコンテナーを作成し、生成された bootstrap.ign ファイルをアップロードします。

    $ az storage container create --name files --account-name ${CLUSTER_NAME}sa --account-key ${ACCOUNT_KEY}
    $ az storage blob upload --account-name ${CLUSTER_NAME}sa --account-key ${ACCOUNT_KEY} -c "files" -f "<installation_directory>/bootstrap.ign" -n "bootstrap.ign"

5.9. DNS ゾーンの作成例

DNS レコードは、user-provisioned infrastructure を使用するクラスターに必要です。シナリオに適した DNS ストラテジーを選択する必要があります。

この例では、Azure Stack Hub のデータセンター DNS 統合 が使用されるため、DNS ゾーンが作成されます。

注記

DNS ゾーンは、クラスターデプロイメントと同じリソースグループに存在している必要はなく、必要なベースドメイン用にすでに組織内に存在している可能性があります。その場合、DNS ゾーンの作成を省略できます。先に生成したインストール設定がこのシナリオに基づいていることを確認してください。

前提条件

  • Azure アカウントを設定します。
  • クラスターの Ignition 設定ファイルを生成します。

手順

  • BASE_DOMAIN_RESOURCE_GROUP 環境変数でエクスポートされたリソースグループに、新規 DNS ゾーンを作成します。

    $ az network dns zone create -g ${BASE_DOMAIN_RESOURCE_GROUP} -n ${CLUSTER_NAME}.${BASE_DOMAIN}

    すでに存在する DNS ゾーンを使用している場合は、この手順を省略できます。

Azure Stack Hub での DNS ゾーンの設定 の詳細は、該当のセクションを参照してください。

5.10. Azure Stack Hub での VNet の作成

OpenShift Container Platform クラスター用に Microsoft Azure Stack Hub で使用する仮想ネットワーク (VNet) を作成する必要があります。各種の要件を満たすように VNet をカスタマイズできます。VNet を作成する方法として、提供される Azure Resource Manager (ARM) テンプレートを変更することができます。

注記

提供される ARM テンプレートを使用して Azure Stack Hub インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • Azure アカウントを設定します。
  • クラスターの Ignition 設定ファイルを生成します。

手順

  1. このトピックの VNet の ARM テンプレートセクションからテンプレートをコピーし、これを 01_vnet.json としてクラスターのインストールディレクトリーに保存します。このテンプレートは、クラスターに必要な VNet を記述しています。
  2. az CLI を使用してデプロイメントを作成します。

    $ az deployment group create -g ${RESOURCE_GROUP} \
      --template-file "<installation_directory>/01_vnet.json" \
      --parameters baseName="${INFRA_ID}"1
    1
    リソース名で使用されるベース名。これは通常クラスターのインフラストラクチャー ID です。

5.10.1. VNet の ARM テンプレート

以下の Azure Resource Manager (ARM) テンプレートを使用し、OpenShift Container Platform クラスターに必要な VNet をデプロイすることができます。

例5.1 01_vnet.json ARM テンプレート

link:https://raw.githubusercontent.com/openshift/installer/release-4.15/upi/azurestack/01_vnet.json[]

5.11. Azure Stack Hub インフラストラクチャー用の RHCOS クラスターイメージのデプロイ

OpenShift Container Platform ノードに Microsoft Azure Stack Hub 用の有効な Red Hat Enterprise Linux CoreOS (RHCOS) イメージを使用する必要があります。

前提条件

  • Azure アカウントを設定します。
  • クラスターの Ignition 設定ファイルを生成します。
  • RHCOS 仮想ハードディスク (VHD) クラスターイメージを Azure ストレージコンテナーに保存します。
  • ブートストラップ Ignition 設定ファイルを Azure ストレージコンテナーに保存します。

手順

  1. このトピックの イメージストレージの ARM テンプレートセクションからテンプレートをコピーし、これを 02_storage.json としてクラスターのインストールディレクトリーに保存します。このテンプレートは、クラスターに必要なイメージストレージを記述しています。
  2. RHCOS VHD blob URL を変数としてエクスポートします。

    $ export VHD_BLOB_URL=`az storage blob url --account-name ${CLUSTER_NAME}sa --account-key ${ACCOUNT_KEY} -c vhd -n "rhcos.vhd" -o tsv`
  3. クラスターイメージのデプロイ

    $ az deployment group create -g ${RESOURCE_GROUP} \
      --template-file "<installation_directory>/02_storage.json" \
      --parameters vhdBlobURL="${VHD_BLOB_URL}" \ 1
      --parameters baseName="${INFRA_ID}" \ 2
      --parameters storageAccount="${CLUSTER_NAME}sa" \ 3
      --parameters architecture="<architecture>" 4
    1
    マスターマシンおよびワーカーマシンを作成するために使用される RHCOS VHD の blob URL。
    2
    リソース名で使用されるベース名。これは通常クラスターのインフラストラクチャー ID です。
    3
    Azure ストレージアカウントの名前。
    4
    システムアーキテクチャーを指定します。有効な値は、x64 (デフォルト) または Arm64 です。

5.11.1. イメージストレージの ARM テンプレート

以下の Azure Resource Manager (ARM) テンプレートを使用し、OpenShift Container Platform クラスターに必要な保存された Red Hat Enterprise Linux CoreOS (RHCOS) をデプロイすることができます。

例5.2 02_storage.json ARM テンプレート

link:https://raw.githubusercontent.com/openshift/installer/release-4.15/upi/azurestack/02_storage.json[]

5.12. user-provisioned infrastructure のネットワーク要件

すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs でネットワークを設定し、Ignition 設定ファイルをフェッチする必要があります。

5.12.1. ネットワーク接続の要件

OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。

このセクションでは、必要なポートの詳細を説明します。

重要

接続された OpenShift Container Platform 環境では、プラットフォームコンテナーのイメージをプルし、Telemetry データを Red Hat に提供するために、すべてのノードにインターネットへのアクセスが必要です。

表5.1 すべてのマシンからすべてのマシンへの通信に使用されるポート
プロトコルポート説明

ICMP

該当なし

ネットワーク到達性のテスト

TCP

1936

メトリック

9000-9999

ホストレベルのサービス。 ポート 9100-9101 のノードエクスポーター、ポート 9099 の Cluster Version Operator が含まれます。

10250-10259

Kubernetes が予約するデフォルトポート

UDP

4789

VXLAN

6081

Geneve

9000-9999

ポート 9100-9101 のノードエクスポーターを含む、ホストレベルのサービス。

500

IPsec IKE パケット

4500

IPsec NAT-T パケット

123

UDP ポート 123 のネットワークタイムプロトコル (NTP)

外部 NTP タイムサーバーが設定されている場合は、UDP ポート 123 を開く必要があります。

TCP/UDP

30000-32767

Kubernetes ノードポート

ESP

該当なし

IPsec Encapsulating Security Payload (ESP)

表5.2 すべてのマシンからコントロールプレーンへの通信に使用されるポート
プロトコルポート説明

TCP

6443

Kubernetes API

表5.3 コントロールプレーンマシンからコントロールプレーンマシンへの通信に使用されるポート
プロトコルポート説明

TCP

2379-2380

etcd サーバーおよびピアポート

5.13. Azure Stack Hub でのネットワークおよび負荷分散コンポーネントの作成

OpenShift Container Platform クラスターで使用するネットワークおよび負荷分散を Microsoft Azure Stack Hub で設定する必要があります。これらのコンポーネントを作成する方法として、提供される Azure Resource Manager (ARM) テンプレートを変更することができます。

負荷分散には、以下の DNS レコードが必要です。

  • DNS ゾーンの API パブリックロードバランサーの api DNS レコード
  • DNS ゾーンの API 内部ロードバランサーの api-int DNS レコード
注記

提供される ARM テンプレートを使用して Azure Stack Hub インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • Azure アカウントを設定します。
  • クラスターの Ignition 設定ファイルを生成します。
  • Azure Stack Hub で VNet および関連するサブネットを作成し、設定します。

手順

  1. このトピックの ネットワークおよびロードばランサーの ARM テンプレートセクションからテンプレートをコピーし、これを 03_infra.json としてクラスターのインストールディレクトリーに保存します。このテンプレートは、クラスターに必要なネットワークおよび負荷分散オブジェクトを記述しています。
  2. az CLI を使用してデプロイメントを作成します。

    $ az deployment group create -g ${RESOURCE_GROUP} \
      --template-file "<installation_directory>/03_infra.json" \
      --parameters baseName="${INFRA_ID}"1
    1
    リソース名で使用されるベース名。これは通常クラスターのインフラストラクチャー ID です。
  3. api DNS レコードおよび api-int DNS レコードを作成します。API DNS レコードの作成時に、${BASE_DOMAIN_RESOURCE_GROUP} 変数は DNS ゾーンが存在するリソースグループを参照する必要があります。

    1. 以下の変数をエクスポートします。

      $ export PUBLIC_IP=`az network public-ip list -g ${RESOURCE_GROUP} --query "[?name=='${INFRA_ID}-master-pip'] | [0].ipAddress" -o tsv`
    2. 以下の変数をエクスポートします。

      $ export PRIVATE_IP=`az network lb frontend-ip show -g "$RESOURCE_GROUP" --lb-name "${INFRA_ID}-internal" -n internal-lb-ip --query "privateIpAddress" -o tsv`
    3. 新しい DNS ゾーンに api DNS レコードを作成します。

      $ az network dns record-set a add-record -g ${BASE_DOMAIN_RESOURCE_GROUP} -z ${CLUSTER_NAME}.${BASE_DOMAIN} -n api -a ${PUBLIC_IP} --ttl 60

      クラスターを既存の DNS ゾーンに追加する場合は、api DNS レコードを代わりに作成できます。

      $ az network dns record-set a add-record -g ${BASE_DOMAIN_RESOURCE_GROUP} -z ${BASE_DOMAIN} -n api.${CLUSTER_NAME} -a ${PUBLIC_IP} --ttl 60
    4. 新しい DNS ゾーンに api-int DNS レコードを作成します。

      $ az network dns record-set a add-record -g ${BASE_DOMAIN_RESOURCE_GROUP} -z "${CLUSTER_NAME}.${BASE_DOMAIN}" -n api-int -a ${PRIVATE_IP} --ttl 60

      クラスターを既存の DNS ゾーンに追加する場合は、api-int DNS レコードを代わりに作成できます。

      $ az network dns record-set a add-record -g ${BASE_DOMAIN_RESOURCE_GROUP} -z ${BASE_DOMAIN} -n api-int.${CLUSTER_NAME} -a ${PRIVATE_IP} --ttl 60

5.13.1. ネットワークおよびロードバランサーの ARM テンプレート

以下の Azure Resource Manager (ARM) テンプレートを使用して、OpenShift Container Platform クラスターに必要なネットワークオブジェクトおよびロードバランサーをデプロイすることができます。

例5.3 03_infra.json ARM テンプレート

link:https://raw.githubusercontent.com/openshift/installer/release-4.15/upi/azurestack/03_infra.json[]

5.14. Azure Stack Hub でのブートストラップマシンの作成

OpenShift Container Platform クラスターの初期化を実行する際に使用するブートストラップマシンを Microsoft Azure Stack Hub で作成する必要があります。このマシンを作成する方法として、提供される Azure Resource Manager (ARM) テンプレートを変更することができます。

注記

提供されている ARM テンプレートを使用してブートストラップマシンを作成しない場合、指定される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • Azure アカウントを設定します。
  • クラスターの Ignition 設定ファイルを生成します。
  • Azure Stack Hub で VNet および関連するサブネットを作成し、設定します。
  • Azure Stack Hub でネットワークおよびロードバランサーを作成し、設定します。
  • コントロールプレーンおよびコンピュートロールを作成します。

手順

  1. このトピックの ブートストラップマシンの ARM テンプレートセクションからテンプレートをコピーし、これを 04_bootstrap.json としてクラスターのインストールディレクトリーに保存します。このテンプレートは、クラスターに必要なブートストラップマシンを記述しています。
  2. ブートストラップ URL 変数をエクスポートします。

    $ bootstrap_url_expiry=`date -u -d "10 hours" '+%Y-%m-%dT%H:%MZ'`
    $ export BOOTSTRAP_URL=`az storage blob generate-sas -c 'files' -n 'bootstrap.ign' --https-only --full-uri --permissions r --expiry $bootstrap_url_expiry --account-name ${CLUSTER_NAME}sa --account-key ${ACCOUNT_KEY} -o tsv`
  3. ブートストラップ Ignition 変数をエクスポートします。

    1. ご使用の環境で公開認証局 (CA) を使用している場合は、次のコマンドを実行します。

      $ export BOOTSTRAP_IGNITION=`jq -rcnM --arg v "3.2.0" --arg url ${BOOTSTRAP_URL} '{ignition:{version:$v,config:{replace:{source:$url}}}}' | base64 | tr -d '\n'`
    2. 環境で内部 CA を使用している場合は、PEM エンコードバンドルをブートストラップ Ignition スタブに追加して、ブートストラップ仮想マシンがストレージアカウントからブートストラップ Ignition をプルできるようにする必要があります。次のコマンドを実行します。これは、CA が CA.pem のファイルにあることを前提としています。

      $ export CA="data:text/plain;charset=utf-8;base64,$(cat CA.pem |base64 |tr -d '\n')"
      $ export BOOTSTRAP_IGNITION=`jq -rcnM --arg v "3.2.0" --arg url "$BOOTSTRAP_URL" --arg cert "$CA" '{ignition:{version:$v,security:{tls:{certificateAuthorities:[{source:$cert}]}},config:{replace:{source:$url}}}}' | base64 | tr -d '\n'`
  4. az CLI を使用してデプロイメントを作成します。

    $ az deployment group create --verbose -g ${RESOURCE_GROUP} \
      --template-file "<installation_directory>/04_bootstrap.json" \
      --parameters bootstrapIgnition="${BOOTSTRAP_IGNITION}" \ 1
      --parameters baseName="${INFRA_ID}" \ 2
      --parameters diagnosticsStorageAccountName="${CLUSTER_NAME}sa" 3
    1
    ブートストラップクラスターのブートストラップ Ignition コンテンツ。
    2
    リソース名で使用されるベース名。これは通常クラスターのインフラストラクチャー ID です。
    3
    クラスターのストレージアカウントの名前。

5.14.1. ブートストラップマシンの ARM テンプレート

以下の Azure Resource Manager (ARM) テンプレートを使用し、OpenShift Container Platform クラスターに必要なブートストラップマシンをデプロイすることができます。

例5.4 04_bootstrap.json ARM テンプレート

link:https://raw.githubusercontent.com/openshift/installer/release-4.15/upi/azurestack/04_bootstrap.json[]

5.15. Azure Stack Hub でのコントロールプレーンの作成

クラスターで使用するコントロールプレーンマシンを Microsoft Azure Stack Hub で作成する必要があります。これらのマシンを作成する方法として、提供される Azure Resource Manager (ARM) テンプレートを変更することができます。

提供される ARM テンプレートを使用してコントロールプレーンマシンを使用しない場合、指定される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合は、インストールログで Red Hat サポートに接続することを検討してください。

前提条件

  • Azure アカウントを設定します。
  • クラスターの Ignition 設定ファイルを生成します。
  • Azure Stack Hub で VNet および関連するサブネットを作成し、設定します。
  • Azure Stack Hub でネットワークおよびロードバランサーを作成し、設定します。
  • コントロールプレーンおよびコンピュートロールを作成します。
  • ブートストラップマシンを作成します。

手順

  1. このトピックの コントロールプレーンマシンの ARM テンプレートセクションからテンプレートをコピーし、これを 05_masters.json としてクラスターのインストールディレクトリーに保存します。このテンプレートは、クラスターに必要なコントロールプレーンのマシンを記述しています。
  2. コントロールプレーンマシンのデプロイメントに必要な以下の変数をエクスポートします。

    $ export MASTER_IGNITION=`cat <installation_directory>/master.ign | base64 | tr -d '\n'`
  3. az CLI を使用してデプロイメントを作成します。

    $ az deployment group create -g ${RESOURCE_GROUP} \
      --template-file "<installation_directory>/05_masters.json" \
      --parameters masterIgnition="${MASTER_IGNITION}" \ 1
      --parameters baseName="${INFRA_ID}" \ 2
      --parameters diagnosticsStorageAccountName="${CLUSTER_NAME}sa" 3
    1
    コントロールプレーンノード (別名マスターノード) の Ignition コンテンツ。
    2
    リソース名で使用されるベース名。これは通常クラスターのインフラストラクチャー ID です。
    3
    クラスターのストレージアカウントの名前。

5.15.1. コントロールプレーンマシンの ARM テンプレート

以下の Azure Resource Manager (ARM) テンプレートを使用し、OpenShift Container Platform クラスターに必要なコントロールプレーンマシンをデプロイすることができます。

例5.5 05_masters.json ARM テンプレート

link:https://raw.githubusercontent.com/openshift/installer/release-4.15/upi/azurestack/05_masters.json[]

5.16. ブートストラップの完了を待機し、Azure Stack Hub のブートストラップリソースを削除する

Microsoft Azure Stack Hub ですべての必要なインフラストラクチャーを作成した後に、ブートストラッププロセスが、インストールプログラムで生成した Ignition 設定ファイルを使用してプロビジョニングしたマシンで完了するのを待機します。

前提条件

  • Azure アカウントを設定します。
  • クラスターの Ignition 設定ファイルを生成します。
  • Azure Stack Hub で VNet および関連するサブネットを作成し、設定します。
  • Azure Stack Hub でネットワークおよびロードバランサーを作成し、設定します。
  • コントロールプレーンおよびコンピュートロールを作成します。
  • ブートストラップマシンを作成します。
  • コントロールプレーンマシンを作成します。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

    $ ./openshift-install wait-for bootstrap-complete --dir <installation_directory> \ 1
        --log-level info 2
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

    コマンドが FATAL 警告を出さずに終了する場合、実稼働用のコントロールプレーンは初期化されています。

  2. ブートストラップリソースを削除します。

    $ az network nsg rule delete -g ${RESOURCE_GROUP} --nsg-name ${INFRA_ID}-nsg --name bootstrap_ssh_in
    $ az vm stop -g ${RESOURCE_GROUP} --name ${INFRA_ID}-bootstrap
    $ az vm deallocate -g ${RESOURCE_GROUP} --name ${INFRA_ID}-bootstrap
    $ az vm delete -g ${RESOURCE_GROUP} --name ${INFRA_ID}-bootstrap --yes
    $ az disk delete -g ${RESOURCE_GROUP} --name ${INFRA_ID}-bootstrap_OSDisk --no-wait --yes
    $ az network nic delete -g ${RESOURCE_GROUP} --name ${INFRA_ID}-bootstrap-nic --no-wait
    $ az storage blob delete --account-key ${ACCOUNT_KEY} --account-name ${CLUSTER_NAME}sa --container-name files --name bootstrap.ign
    $ az network public-ip delete -g ${RESOURCE_GROUP} --name ${INFRA_ID}-bootstrap-ssh-pip
注記

ブートストラップサーバーを削除しないと、API トラフィックがブートストラップサーバーにルーティングされるため、インストールが成功しない場合があります。

5.17. Azure Stack Hub での追加のワーカーマシンの作成

Microsoft Azure Stack Hub でクラスターが使用するワーカーマシンを作成するには、それぞれのインスタンスを個別に起動するか、自動スケーリンググループなどのクラスター外にある自動プロセスを実行します。OpenShift Container Platform の組み込まれたクラスタースケーリングメカニズムやマシン API を利用できます。

この例では、Azure Resource Manager (ARM) テンプレートを使用して 1 つのインスタンスを手動で起動します。追加のインスタンスは、ファイル内に 06_workers.json というタイプのリソースを追加して起動することができます。

提供される ARM テンプレートを使用してコントロールプレーンマシンを使用しない場合、指定される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合は、インストールログで Red Hat サポートに接続することを検討してください。

前提条件

  • Azure アカウントを設定します。
  • クラスターの Ignition 設定ファイルを生成します。
  • Azure Stack Hub で VNet および関連するサブネットを作成し、設定します。
  • Azure Stack Hub でネットワークおよびロードバランサーを作成し、設定します。
  • コントロールプレーンおよびコンピュートロールを作成します。
  • ブートストラップマシンを作成します。
  • コントロールプレーンマシンを作成します。

手順

  1. このトピックの ワーカーマシンの ARM テンプレートセクションからテンプレートをコピーし、これを 06_workers.json としてクラスターのインストールディレクトリーに保存します。このテンプレートは、クラスターに必要なワーカーマシンを記述しています。
  2. ワーカーマシンのデプロイメントで必要な以下の変数をエクスポートします。

    $ export WORKER_IGNITION=`cat <installation_directory>/worker.ign | base64 | tr -d '\n'`
  3. az CLI を使用してデプロイメントを作成します。

    $ az deployment group create -g ${RESOURCE_GROUP} \
      --template-file "<installation_directory>/06_workers.json" \
      --parameters workerIgnition="${WORKER_IGNITION}" \ 1
      --parameters baseName="${INFRA_ID}" 2
      --parameters diagnosticsStorageAccountName="${CLUSTER_NAME}sa" 3
    1
    ワーカーノードの Ignition コンテンツ。
    2
    リソース名で使用されるベース名。これは通常クラスターのインフラストラクチャー ID です。
    3
    クラスターのストレージアカウントの名前。

5.17.1. ワーカーマシンの ARM テンプレート

以下の Azure Resource Manager (ARM) テンプレートを使用し、OpenShift Container Platform クラスターに必要なワーカーマシンをデプロイすることができます。

例5.6 06_workers.json ARM テンプレート

link:https://raw.githubusercontent.com/openshift/installer/release-4.15/upi/azurestack/06_workers.json[]

5.18. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.15 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

Linux への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
  3. バージョン ドロップダウンリストから適切なバージョンを選択します。
  4. OpenShift v4.17 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  5. アーカイブを展開します。

    $ tar xvf <file>
  6. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    $ echo $PATH

検証

  • OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

    $ oc <command>
Windows への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.15 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを展開します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    C:\> path

検証

  • OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

    C:\> oc <command>
macOS への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.17 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

    注記

    macOS arm64 の場合は、OpenShift v4.15 macOS arm64 Client エントリーを選択します。

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    $ oc <command>

5.19. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    $ oc whoami

    出力例

    system:admin

5.20. マシンの証明書署名要求の承認

マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。

前提条件

  • マシンがクラスターに追加されています。

手順

  1. クラスターがマシンを認識していることを確認します。

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.28.5
    master-1  Ready     master  63m  v1.28.5
    master-2  Ready     master  64m  v1.28.5

    出力には作成したすべてのマシンがリスト表示されます。

    注記

    上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。

  2. 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。

    $ oc get csr

    出力例

    NAME        AGE     REQUESTOR                                                                   CONDITION
    csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    ...

    この例では、2 つのマシンがクラスターに参加しています。このリストにはさらに多くの承認された CSR が表示される可能性があります。

  3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

    注記

    CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に machine-approver によって自動的に承認されます。

    注記

    ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、oc execoc rsh、および oc logs コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR が system:node または system:admin グループの node-bootstrapper サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。

    • それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name> は、現行の CSR のリストからの CSR の名前です。
    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
      注記

      一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。

  4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。

    $ oc get csr

    出力例

    NAME        AGE     REQUESTOR                                                                   CONDITION
    csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
    csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
    ...

  5. 残りの CSR が承認されず、それらが Pending ステータスにある場合、クラスターマシンの CSR を承認します。

    • それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name> は、現行の CSR のリストからの CSR の名前です。
    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
  6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  73m  v1.28.5
    master-1  Ready     master  73m  v1.28.5
    master-2  Ready     master  74m  v1.28.5
    worker-0  Ready     worker  11m  v1.28.5
    worker-1  Ready     worker  11m  v1.28.5

    注記

    サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。

関連情報

5.21. Ingress DNS レコードの追加

Kubernetes マニフェストの作成および Ignition 設定の生成時に DNS ゾーン設定を削除した場合、Ingress ロードバランサーをポイントする DNS レコードを手動で作成する必要があります。ワイルドカード *.apps.{baseDomain}. または特定のレコードのいずれかを作成できます。要件に基づいて A、CNAME その他のレコードを使用できます。

前提条件

  • 独自にプロビジョニングしたインフラストラクチャーを使用して、OpenShift Container Platform クラスターを Microsoft Azure Stack Hub にデプロイしています。
  • OpenShift CLI (oc) をインストールします。
  • Azure CLI のインストールまたは更新を実行します。

手順

  1. Ingress ルーターがロードバランサーを作成し、EXTERNAL-IP フィールドにデータを設定していることを確認します。

    $ oc -n openshift-ingress get service router-default

    出力例

    NAME             TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                      AGE
    router-default   LoadBalancer   172.30.20.10   35.130.120.110   80:32288/TCP,443:31215/TCP   20

  2. Ingress ルーター IP を変数としてエクスポートします。

    $ export PUBLIC_IP_ROUTER=`oc -n openshift-ingress get service router-default --no-headers | awk '{print $4}'`
  3. *.apps レコードを DNS ゾーンに追加します。

    1. このクラスターを新しい DNS ゾーンに追加する場合は、以下を実行します。

      $ az network dns record-set a add-record -g ${BASE_DOMAIN_RESOURCE_GROUP} -z ${CLUSTER_NAME}.${BASE_DOMAIN} -n *.apps -a ${PUBLIC_IP_ROUTER} --ttl 300
    2. このクラスターを既存の DNS ゾーンに追加する場合は、以下を実行します。

      $ az network dns record-set a add-record -g ${BASE_DOMAIN_RESOURCE_GROUP} -z ${BASE_DOMAIN} -n *.apps.${CLUSTER_NAME} -a ${PUBLIC_IP_ROUTER} --ttl 300

ワイルドカードを使用する代わりに明示的なドメインを追加する場合は、クラスターのそれぞれの現行ルートのエントリーを作成できます。

$ oc get --all-namespaces -o jsonpath='{range .items[*]}{range .status.ingress[*]}{.host}{"\n"}{end}{end}' routes

出力例

oauth-openshift.apps.cluster.basedomain.com
console-openshift-console.apps.cluster.basedomain.com
downloads-openshift-console.apps.cluster.basedomain.com
alertmanager-main-openshift-monitoring.apps.cluster.basedomain.com
prometheus-k8s-openshift-monitoring.apps.cluster.basedomain.com

5.22. user-provisioned infrastructure での Azure Stack Hub インストールの実行

Microsoft Azure Stack Hub の user-provisioned infrastructure で OpenShift Container Platform のインストールを開始した後は、クラスターが準備状態になるまでクラスターのイベントをモニターできます。

前提条件

  • OpenShift Container Platform クラスターのブートストラップマシンを、user-provisioned Azure Stack Hub インフラストラクチャーにデプロイします。
  • oc CLI をインストールし、ログインします。

手順

  • クラスターのインストールを完了します。

    $ ./openshift-install --dir <installation_directory> wait-for install-complete 1

    出力例

    INFO Waiting up to 30m0s for the cluster to initialize...

    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
    重要
    • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
    • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

関連情報

第6章 Azure Stack Hub のインストール設定パラメーター

Azure Stack Hub の OpenShift Container Platform クラスターをデプロイする前に、環境の詳細を記述するカスタマイズされた install-config.yaml インストール設定ファイルを指定します。

6.1. Azure Stack Hub で使用できるインストール設定パラメーター

次の表では、インストールプロセスの一部として設定できる、必須、オプション、および Azure Stack Hub 固有のインストール設定パラメーターを指定します。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

6.1.1. 必須設定パラメーター

必須のインストール設定パラメーターは、以下の表で説明されています。

表6.1 必須パラメーター
パラメーター説明
apiVersion:

install-config.yaml コンテンツの API バージョン。現在のバージョンは v1 です。インストールプログラムは、古い API バージョンもサポートしている場合があります。

文字列

baseDomain:

クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、baseDomain<metadata.name>.<baseDomain> 形式を使用する metadata.name パラメーターの値の組み合わせです。

example.com などの完全修飾ドメインまたはサブドメイン名。

metadata:

Kubernetes リソース ObjectMeta。ここからは name パラメーターのみが消費されます。

オブジェクト

metadata:
  name:

クラスターの名前。クラスターの DNS レコードはすべて {{.metadata.name}}.{{.baseDomain}} のサブドメインです。

dev などの小文字、ハイフン (-)、およびピリオド (.) が含まれる文字列。

platform:

インストールを実行する特定のプラットフォームの設定: alibabacloudawsbaremetalazuregcpibmcloudnutanixopenstackpowervsvsphere、または {}platform.<platform> パラメーターに関する追加情報は、以下の表で特定のプラットフォームを参照してください。

オブジェクト

pullSecret:

Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。

{
   "auths":{
      "cloud.openshift.com":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      },
      "quay.io":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      }
   }
}

6.1.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

注記

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

表6.2 ネットワークパラメーター
パラメーター説明
networking:

クラスターのネットワークの設定。

オブジェクト

注記

インストール後に networking オブジェクトで指定したパラメーターを変更することはできません。

networking:
  networkType:

インストールする Red Hat OpenShift Networking ネットワークプラグイン。

OVNKubernetesOVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プラグインです。デフォルトの値は OVNKubernetes です。

networking:
  clusterNetwork:

Pod の IP アドレスブロック。

デフォルト値は 10.128.0.0/14 で、ホストの接頭辞は /23 です。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
networking:
  clusterNetwork:
    cidr:

networking.clusterNetwork を使用する場合に必須です。IP アドレスブロック。

IPv4 ネットワーク

CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は 0 から 32 の間になります。

networking:
  clusterNetwork:
    hostPrefix:

それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、hostPrefix23 に設定される場合、各ノードに指定の cidr から /23 サブネットが割り当てられます。hostPrefix 値の 23 は、510 (2^(32 - 23) - 2) Pod IP アドレスを提供します。

サブネット接頭辞。

デフォルト値は 23 です。

networking:
  serviceNetwork:

サービスの IP アドレスブロック。デフォルト値は 172.30.0.0/16 です。

OVN-Kubernetes ネットワークプラグインは、サービスネットワークに対して単一の IP アドレスブロックのみをサポートします。

CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。

networking:
  serviceNetwork:
   - 172.30.0.0/16
networking:
  machineNetwork:

マシンの IP アドレスブロック。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。

networking:
  machineNetwork:
  - cidr: 10.0.0.0/16
networking:
  machineNetwork:
    cidr:

networking.machineNetwork を使用する場合に必須です。IP アドレスブロック。libvirt と IBM Power® Virtual Server を除くすべてのプラットフォームのデフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。IBM Power® Virtual Server の場合、デフォルト値は 192.168.0.0/24 です。

CIDR 表記の IP ネットワークブロック。

例: 10.0.0.0/16

注記

優先される NIC が置かれている CIDR に一致する networking.machineNetwork を設定します。

6.1.3. オプションの設定パラメーター

オプションのインストール設定パラメーターは、以下の表で説明されています。

表6.3 オプションのパラメーター
パラメーター説明
additionalTrustBundle:

ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。

文字列

capabilities:

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。

文字列配列

capabilities:
  baselineCapabilitySet:

有効にするオプション機能の初期セットを選択します。有効な値は Nonev4.11v4.12vCurrent です。デフォルト値は vCurrent です。

文字列

capabilities:
  additionalEnabledCapabilities:

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。このパラメーターで複数の機能を指定できます。

文字列配列

cpuPartitioningMode:

ワークロードパーティション設定を使用して、OpenShift Container Platform サービス、クラスター管理ワークロード、およびインフラストラクチャー Pod を分離し、予約された CPU セットで実行できます。ワークロードパーティショニングはインストール中にのみ有効にすることができ、インストール後に無効にすることはできません。このフィールドはワークロードのパーティショニングを有効にしますが、特定の CPU を使用するようにワークロードを設定するわけではありません。詳細は、スケーラビリティとパフォーマンス セクションの ワークロードパーティショニング ページを参照してください。

None または AllNodes。デフォルト値は None です。

compute:

コンピュートノードを構成するマシンの設定。

MachinePool オブジェクトの配列。

compute:
  architecture:

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64 (デフォルト) です。

文字列

compute:
  hyperthreading:

コンピュートマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

compute:
  name:

compute を使用する場合に必須です。マシンプールの名前。

worker

compute:
  platform:

compute を使用する場合に必須です。このパラメーターを使用して、ワーカーマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は controlPlane.platform パラメーターの値に一致する必要があります。

alibabacloudawsazuregcpibmcloudnutanixopenstackpowervsvsphere、または {}

compute:
  replicas:

プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。

2 以上の正の整数。デフォルト値は 3 です。

featureSet:

機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。

文字列。TechPreviewNoUpgrade など、有効にする機能セットの名前。

controlPlane:

コントロールプレーンを構成するマシンの設定。

MachinePool オブジェクトの配列。

controlPlane:
  architecture:

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64 (デフォルト) です。

文字列

controlPlane:
  hyperthreading:

コントロールプレーンマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

controlPlane:
  name:

controlPlane を使用する場合に必須です。マシンプールの名前。

master

controlPlane:
  platform:

controlPlane を使用する場合に必須です。このパラメーターを使用して、コントロールプレーンマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は compute.platform パラメーターの値に一致する必要があります。

alibabacloudawsazuregcpibmcloudnutanixopenstackpowervsvsphere、または {}

controlPlane:
  replicas:

プロビジョニングするコントロールプレーンマシンの数。

サポートされる値は 3、シングルノード OpenShift をデプロイする場合は 1 です。

credentialsMode:

Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。

MintPassthroughManual、または空の文字列 ("")。[1]

fips:

FIPS モードを有効または無効にします。デフォルトは false (無効) です。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。

重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources:

release-image コンテンツのソースおよびリポジトリー。

オブジェクトの配列。この表の以下の行で説明されているように、source およびオプションで mirrors が含まれます。

imageContentSources:
  source:

imageContentSources を使用する場合に必須です。ユーザーが参照するリポジトリーを指定します (例: イメージプル仕様)。

文字列

imageContentSources:
  mirrors:

同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。

文字列の配列。

publish:

Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。

Internal または External。デフォルト値は External です。

このパラメーターを Internal に設定することは、クラウド以外のプラットフォームではサポートされません。

重要

フィールドの値が Internal に設定されている場合、クラスターは機能しなくなります。詳細は、BZ#1953035 を参照してください。

sshKey:

クラスターマシンへのアクセスを認証するための SSH キー。

注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

たとえば、sshKey: ssh-ed25519 AAAA.. です。

  1. すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、認証と認可 コンテンツの「クラウドプロバイダーの認証情報の管理」を参照してください。

6.1.4. 追加の Azure Stack Hub 設定パラメーター

追加の Azure 設定パラメーターは以下の表で説明されています。

表6.4 追加の Azure Stack Hub パラメーター
パラメーター説明
compute:
  platform:
    azure:
      osDisk:
        diskSizeGB:

VM の Azure ディスクのサイズ。

GB 単位でディスクのサイズを表す整数。デフォルトは 128 です。

compute:
  platform:
    azure:
      osDisk:
        diskType:

ディスクのタイプを定義します。

standard_LRS または premium_LRS。デフォルトは premium_LRS です。

compute:
  platform:
    azure:
      type:

コンピュートマシンの azure インスタンスタイプを定義します。

文字列

controlPlane:
  platform:
    azure:
      osDisk:
        diskSizeGB:

VM の Azure ディスクのサイズ。

GB 単位でディスクのサイズを表す整数。デフォルトは 1024 です。

controlPlane:
  platform:
    azure:
      osDisk:
        diskType:

ディスクのタイプを定義します。

premium_LRS.

controlPlane:
  platform:
    azure:
      type:

コントロールプレーンマシンの azure インスタンスタイプを定義します。

文字列

platform:
  azure:
    defaultMachinePlatform:
      osDisk:
        diskSizeGB:

VM の Azure ディスクのサイズ。

GB 単位でディスクのサイズを表す整数。デフォルトは 128 です。

platform:
  azure:
    defaultMachinePlatform:
      osDisk:
        diskType:

ディスクのタイプを定義します。

standard_LRS または premium_LRS。デフォルトは premium_LRS です。

platform:
  azure:
    defaultMachinePlatform:
      type:

コントロールプレーンおよびコンピュートマシンの Azure インスタンスタイプ。

Azure インスタンスタイプ。

platform:
  azure:
    armEndpoint:

Azure Stack Hub Operator が提供する Azure Resource Manager エンドポイントの URL。

文字列

platform:
  azure:
    baseDomainResourceGroupName:

ベースドメインの DNS ゾーンが含まれるリソースグループの名前。

文字列 (例: production_cluster)。

platform:
  azure:
    region:

Azure Stack Hub ローカルリージョンの名前。

文字列

platform:
  azure:
    resourceGroupName:

クラスターをインストールする既存のリソースグループの名前。このリソースグループは空で、この特定のクラスターにのみ使用する必要があります。クラスターコンポーネントは、リソースグループ内のすべてのリソースの所有権を想定します。インストールプログラムのサービスプリンシパルの範囲をこのリソースグループに制限する場合は、環境内でインストールプログラムが使用する他のすべてのリソースに、パブリック DNS ゾーンや仮想ネットワークなどの必要なパーミッションがあることを確認する必要があります。インストールプログラムを使用してクラスターを破棄すると、このリソースグループが削除されます。

文字列 (例: existing_resource_group)。

platform:
  azure:
    outboundType:

クラスターをインターネットに接続するために使用されるアウトバウンドルーティングストラテジー。ユーザー定義のルーティングを使用している場合、クラスターをインストールする前にアウトバウンドルーティングがすでに設定されている既存のネットワークが利用可能な状態にする必要があります。インストールプログラムはユーザー定義のルーティングの設定を行いません。

LoadBalancer または UserDefinedRouting。デフォルトは LoadBalancer です。

platform:
  azure:
    cloudName:

適切な Azure API エンドポイントで Azure SDK を設定するために使用される Azure クラウド環境の名前。

AzureStackCloud

clusterOSImage:

RHCOS VHD を含む Azure Stack 環境のストレージ blob の URL。

文字列 (たとえば、https://vhdsa.blob.example.example.com/vhd/rhcos-410.84.202112040202-0-azurestack.x86_64.vhd)

第7章 Azure Stack Hub でのクラスターのアンインストール

Azure Stack Hub にデプロイしたクラスターを削除できます。

7.1. installer-provisioned infrastructure を使用するクラスターの削除

installer-provisioned infrastructure を使用するクラスターは、クラウドから削除できます。

注記

アンインストール後に、とくに user-provisioned infrastructure (UPI) クラスターで適切に削除されていないリソースがあるかどうかについて、クラウドプロバイダーを確認します。インストーラーが作成されなかったり、インストーラーがアクセスできない場合には、リソースがある可能性があります。

前提条件

  • クラスターをデプロイするために使用したインストールプログラムのコピーがあります。
  • クラスター作成時にインストールプログラムが生成したファイルがあります。

手順

  1. クラスターをインストールするために使用したコンピューターのインストールプログラムが含まれるディレクトリーから、以下のコマンドを実行します。

    $ ./openshift-install destroy cluster \
    --dir <installation_directory> --log-level info 1 2
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
    2
    異なる詳細情報を表示するには、info ではなく、warndebug、または error を指定します。
    注記

    クラスターのクラスター定義ファイルが含まれるディレクトリーを指定する必要があります。クラスターを削除するには、インストールプログラムでこのディレクトリーにある metadata.json ファイルが必要になります。

  2. オプション: <installation_directory> ディレクトリーおよび OpenShift Container Platform インストールプログラムを削除します。

Legal Notice

Copyright © 2024 Red Hat, Inc.

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.