1.9. ホストインベントリーの概要
ホストインベントリー管理とオンプレミスクラスターのインストールは、マルチクラスターエンジン Operator の Central Infrastructure Management 機能を使用して利用できます。
Central infrastructure management 機能は、ライフサイクル中のベアメタルホストの管理に重点を置いた、マルチクラスターエンジン Operator の Red Hat OpenShift Container Platform インストールエクスペリエンスです。
Assisted Installer は、エージェントを使用してターゲットホストに事前インストールされた検証を実行し、中央サービスを使用してインストールの進行状況を評価および追跡する、OpenShift Container Platform のインストール方法です。
Red Hat OpenShift のインフラストラクチャー Operator は、Assisted Installer サービスを実行するワークロードを管理およびインストールするマルチクラスターエンジン Operator コンポーネントです。
コンソールを使用してホストインベントリーを作成できます。これは、オンプレミスの OpenShift Container Platform クラスターの作成に使用できるベアメタルまたは仮想マシンのプールです。これらのクラスターには、コントロールプレーン専用のマシンを備えたスタンドアロンと、コントロールプレーンがハブクラスター上の Pod として実行される Hosted Control Plane があります。
スタンドアロンクラスターは、コンソール、API、またはゼロタッチプロビジョニング (ZTP) を使用する GitOps を使用してインストールできます。詳細は、Red Hat OpenShift Container Platform ドキュメントの 非接続環境での GitOps ZTP のインストール を参照してください。
マシンは、Discovery Image で起動した後、ホストインベントリーに参加します。Discovery Image は、以下を含む Red Hat CoreOS ライブイメージです。
- 検出、検証、およびインストールタスクを実行するエージェント。
- ハブクラスター上のサービスにアクセスするために必要な設定 (該当する場合、エンドポイント、トークン、静的ネットワーク設定など)。
各インフラストラクチャー環境に Discovery イメージを 1 つ用意します。この環境は、共通のプロパティーセットを共有するホストセットです。InfraEnv
カスタムリソース定義は、このインフラストラクチャー環境と関連する Discovery Image を表します。InfraEnv
カスタムリソースの osImageVersion
フィールドを設定して、Discovery イメージに使用される Red Hat Core OS バージョンを指定できます。値を指定しない場合は、最新の Red Hat Core OS バージョンが使用されます。
ホストが起動し、エージェントがサービスに接続すると、サービスはそのホストを表すハブクラスター上に新しい Agent
カスタムリソースを作成します。Agent
リソースはホストインベントリーを設定します。
後でホストを OpenShift ノードとしてインベントリーにインストールできます。エージェントは、必要な設定とともにオペレーティングシステムをディスクに書き込み、ホストを再起動します。
注記: Red Hat Advanced Cluster Management 2.9 以降および Central infrastructure management は、AgentClusterInstall
を使用して Nutanix プラットフォームをサポートしますが、これには Nutanix 仮想マシンを作成することによる追加の設定が必要です。詳細は、Assisted Installer ドキュメントの オプション: Nutanix へのインストール を参照してください。
ホストインベントリーと Central Infrastructure Management の詳細は、以下を参照してください。
- Central Infrastructure Management サービスの有効化
- Amazon Web Services での Central Infrastructure Management の有効化
- コンソールを使用したホストインベントリーの作成
- コマンドラインインターフェイスを使用したホストインベントリーの作成
- インフラストラクチャー環境用の高度なネットワークの設定
- Discovery Image を使用したホストのホストインベントリーへの追加
- ベアメタルホストのホストインベントリーへの自動追加
- ホストインベントリーの管理
- オンプレミス環境でのクラスターの作成
- Central infrastructure management を使用してオンプレミスの Red Hat OpenShift Container Platform クラスターを手動でインポートする
1.9.1. Central Infrastructure Management サービスの有効化
Central Infrastructure Management サービスはマルチクラスターエンジン Operator とともに提供され、OpenShift Container Platform クラスターをデプロイします。ハブクラスターで MultiClusterHub Operator を有効にすると、Central infrastructure management サービスが自動的にデプロイされますが、サービスは手動で有効にする必要があります。
1.9.1.1. 前提条件
Central Infrastructure Management サービスを有効にする前に、次の前提条件を確認してください。
- サポートされている OpenShift Container Platform バージョンと、サポートされている Red Hat Advanced Cluster Management for Kubernetes バージョンにハブクラスターがデプロイされている。
- クラスターを作成するために必要なイメージを取得するためのハブクラスターへのインターネットアクセス (接続済み)、あるいはインターネットへの接続がある内部またはミラーレジストリーへの接続 (非接続) がある。
- ベアメタルプロビジョニングに必要なポートが開いている。OpenShift Container Platform ドキュメントの 必須ポートが開いていることを確認する を参照してください。
- ベアメタルホストのカスタムリソース定義がある。
- OpenShift Container Platform プルシークレット がある。詳細は、イメージプルシークレットの使用 を参照してください。
- 設定済みのデフォルトのストレージクラスがある。
- 非接続環境の場合のみ、OpenShift Container Platform ドキュメントの ネットワーク遠端のクラスター に関する手順を完了してください。
以下のセクションを参照してください。
1.9.1.2. ベアメタルホストのカスタムリソース定義の作成
Central Infrastructure Management サービスを有効にする前に、ベアメタルホストのカスタムリソース定義が必要です。
次のコマンドを実行して、ベアメタルホストのカスタムリソース定義がすでに存在するかどうかを確認します。
oc get crd baremetalhosts.metal3.io
- ベアメタルホストのカスタムリソース定義がある場合、出力にはリソースが作成された日付が表示されます。
- リソースがない場合は、次のようなエラーが表示されます。
Error from server (NotFound): customresourcedefinitions.apiextensions.k8s.io "baremetalhosts.metal3.io" not found
ベアメタルホストのカスタムリソース定義がない場合は、metal3.io_baremetalhosts.yaml ファイルをダウンロードし、次のコマンドを実行することでコンテンツを適用して、リソースを作成します。
oc apply -f
1.9.1.3. Provisioning リソースの作成または変更
Central Infrastructure Management サービスを有効にする前に、Provisioning
リソースが必要です。
次のコマンドを実行して、
Provisioning
リソースがあるかどうかを確認します。oc get provisioning
-
すでに
Provisioning
リソースがある場合は、Provisioning
リソースの変更 に進みます。 -
Provisioning
リソースがない場合は、No resources found
というエラーが表示されます。Provisioning
リソースの作成 に進みます。
-
すでに
1.9.1.3.1. Provisioning リソースの変更
すでに Provisioning
リソースがある場合は、ハブクラスターが次のいずれかのプラットフォームにインストールされている場合、リソースを変更する必要があります。
- ベアメタル
- Red Hat OpenStack Platform
- VMware vSphere
-
ユーザープロビジョニングインフラストラクチャー (UPI) 方式とプラットフォームは
None
です
ハブクラスターが別のプラットフォームにインストールされている場合は、非接続環境での Central Infrastructure Management の有効化 または 接続環境での Central Infrastructure Management の有効化 に進みます。
provisioning
リソースを変更し、以下のコマンドを実行してベアメタル Operator がすべての namespace を監視できるようにします。oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"watchAllNamespaces": true }}'
1.9.1.3.2. Provisioning リソースの作成
Provisioning
リソースがない場合は、次の手順を実行します。
次の YAML コンテンツを追加して、
Provisioning
リソースを作成します。apiVersion: metal3.io/v1alpha1 kind: Provisioning metadata: name: provisioning-configuration spec: provisioningNetwork: "Disabled" watchAllNamespaces: true
次のコマンドを実行してコンテンツを適用します。
oc apply -f
1.9.1.4. 非接続環境での Central Infrastructure Management の有効化
非接続環境で Central Infrastructure Management を有効にするには、以下の手順を実行します。
インフラストラクチャー Operator と同じ namespace に
ConfigMap
を作成し、ミラーレジストリーのca-bundle.crt
およびregistries.conf
の値を指定します。ファイルのConfigMap
は次の例のようになります。apiVersion: v1 kind: ConfigMap metadata: name: <mirror-config> namespace: multicluster-engine labels: app: assisted-service data: ca-bundle.crt: | <certificate-content> registries.conf: | unqualified-search-registries = ["registry.access.redhat.com", "docker.io"] [[registry]] prefix = "" location = "registry.redhat.io/multicluster-engine" mirror-by-digest-only = true [[registry.mirror]] location = "mirror.registry.com:5000/multicluster-engine"
注記: リリースイメージはダイジェストを使用して指定されるため、
mirror-by-digest-only
をtrue
に設定する必要があります。unqualified-search-registries
のリストにあるレジストリーは、PUBLIC_CONTAINER_REGISTRIES
環境変数の認証無視リストに自動的に追加されます。マネージドクラスターのプルシークレットの検証時に、指定されたレジストリーは認証を必要としません。-
すべての
osImage
リクエストで送信するヘッダーとクエリーパラメーターを表すキーペアを書き込みます。両方のパラメーターが必要ない場合は、ヘッダーのみ、またはクエリーパラメーターのみのキーペアを作成します。
重要: ヘッダーとクエリーパラメーターは、HTTPS を使用する場合にのみ暗号化されます。セキュリティーの問題を避けるために、必ず HTTPS を使用してください。
headers
という名前のファイルを作成し、次の例のような内容を追加します。{ "Authorization": "Basic xyz" }
query_params
という名前のファイルを作成し、次の例のような内容を追加します。{ "api_key": "myexampleapikey", }
次のコマンドを実行して、作成したパラメーターファイルからシークレットを作成します。パラメーターファイルを 1 つだけ作成した場合は、作成しなかったファイルの引数を削除します。
oc create secret generic -n multicluster-engine os-images-http-auth --from-file=./query_params --from-file=./headers
自己署名証明書またはサードパーティー CA 証明書とともに HTTPS
osImage
を使用する場合は、証明書をimage-service-additional-ca
ConfigMap
に追加します。証明書を作成するには、次のコマンドを実行します。oc -n multicluster-engine create configmap image-service-additional-ca --from-file=tls.crt
次の YAML コンテンツを
agent_service_config.yaml
ファイルに保存して、AgentServiceConfig
カスタムリソースを作成します。apiVersion: agent-install.openshift.io/v1beta1 kind: AgentServiceConfig metadata: name: agent spec: databaseStorage: accessModes: - ReadWriteOnce resources: requests: storage: <db_volume_size> filesystemStorage: accessModes: - ReadWriteOnce resources: requests: storage: <fs_volume_size> mirrorRegistryRef: name: <mirror_config> 1 unauthenticatedRegistries: - <unauthenticated_registry> 2 imageStorage: accessModes: - ReadWriteOnce resources: requests: storage: <img_volume_size> 3 OSImageAdditionalParamsRef: name: os-images-http-auth OSImageCACertRef: name: image-service-additional-ca osImages: - openshiftVersion: "<ocp_version>" 4 version: "<ocp_release_version>" 5 url: "<iso_url>" 6 cpuArchitecture: "x86_64"
- 1
mirror_config
は、ミラーレジストリー設定の詳細が含まれるConfigMap
の名前に置き換えます。- 2
- 認証を必要としないミラーレジストリーを使用している場合は、オプションの
unauthenticated_registry
パラメーターを含めます。このリストのエントリーは検証されず、プルシークレットにエントリーを含める必要はありません。 - 3
img_volume_size
をimageStorage
フィールドのボリュームのサイズに置き換えます (例: オペレーティングシステムイメージごとに10Gi
)。最小値は10Gi
ですが、推奨される値は50Gi
以上です。この値は、クラスターのイメージに割り当てられるストレージの量を指定します。実行中の Red Hat Enterprise Linux CoreOS の各インスタンスに 1 GB のイメージストレージを許可する必要があります。Red Hat Enterprise Linux CoreOS のクラスターおよびインスタンスが多数ある場合は、より高い値を使用する必要がある場合があります。- 4
ocp_version
は、インストールする OpenShift Container Platform バージョン (例:4.14
) に置き換えます。- 5
ocp_release_version
は、特定のインストールバージョン (例:49.83.2021032516400
) に置き換えます。- 6
iso_url
は、ISO URL に置き換えます (例:https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.13/4.13.3/rhcos-4.13.3-x86_64-live.x86_64.iso
)。他の値は rhoc で確認できます。
自己署名証明書またはサードパーティー CA 証明書を持つ HTTPS osImage
を使用している場合は、OSImageCACertRef
仕様でその証明書を参照してください。
重要: 遅延バインディング機能を使用しており、AgentServiceConfig
カスタムリソースの spec.osImages
リリースがバージョン 4.13 以降である場合、クラスターの作成時に使用する OpenShift Container Platform リリースイメージが同じバージョンである必要があります。バージョン 4.13 以降の Red Hat Enterprise Linux CoreOS イメージは、以前のイメージと互換性がありません。
assisted-service
デプロイメントおよび assisted-image-service
デプロイメントをチェックし、その Pod が準備ができており実行中であることを確認することで、Central infrastructure management サービスが正常であることを確認できます。
1.9.1.5. 接続環境での Central Infrastructure Management の有効化
接続環境で Central infrastructure management を有効にするには、以下の YAML コンテンツを agent_service_config.yaml
ファイルに保存して、AgentServiceConfig
カスタムリソースを作成します。
apiVersion: agent-install.openshift.io/v1beta1 kind: AgentServiceConfig metadata: name: agent spec: databaseStorage: accessModes: - ReadWriteOnce resources: requests: storage: <db_volume_size> 1 filesystemStorage: accessModes: - ReadWriteOnce resources: requests: storage: <fs_volume_size> 2 imageStorage: accessModes: - ReadWriteOnce resources: requests: storage: <img_volume_size> 3
- 1
db_volume_size
はdatabaseStorage
フィールドのボリュームサイズに置き換えます (例:10Gi
)。この値は、クラスターのデータベーステーブルやデータベースビューなどのファイルを格納するために割り当てられるストレージの量を指定します。必要な最小値は1Gi
です。クラスターが多い場合は、より高い値を使用する必要がある場合があります。- 2
fs_volume_size
はfilesystemStorage
フィールドのボリュームのサイズに置き換えます (例: クラスターごとに200M
、サポートされる OpenShift Container Platform バージョンごとに2-3Gi
)。必要な最小値は1Gi
ですが、推奨される値は100Gi
以上です。この値は、クラスターのログ、マニフェスト、およびkubeconfig
ファイルを保存するために割り当てられるストレージのサイズを指定します。クラスターが多い場合は、より高い値を使用する必要がある場合があります。- 3
img_volume_size
をimageStorage
フィールドのボリュームのサイズに置き換えます (例: オペレーティングシステムイメージごとに10Gi
)。最小値は10Gi
ですが、推奨される値は50Gi
以上です。この値は、クラスターのイメージに割り当てられるストレージの量を指定します。実行中の Red Hat Enterprise Linux CoreOS の各インスタンスに 1 GB のイメージストレージを許可する必要があります。Red Hat Enterprise Linux CoreOS のクラスターおよびインスタンスが多数ある場合は、より高い値を使用する必要がある場合があります。
Central Infrastructure Management サービスが設定されている。assisted-service
と assisted-image-service
デプロイメントをチェックして、Pod の準備ができ、実行されていることを確認して、正常性を検証できます。
1.9.1.6. Assisted Installer を使用して FIPS 対応クラスターをインストールする
FIPS モードの OpenShift Container Platform クラスターバージョン 4.15 以前をインストールする場合は、AgentServiceConfig
リソースで、インストーラーが Red Hat Enterprise Linux (RHEL) バージョン 8 を実行するように指定する必要があります。
必要なアクセス: AgentServiceConfig
および AgentClusterInstall
リソースを編集するためのアクセス権が必要です。
AgentServiceConfig
リソースを更新するには、次の手順を実行します。
次のコマンドを使用して、マネージドクラスターにログインします。
oc login
AgentServiceConfig
リソースにagent-install.openshift.io/service-image-base: el8
アノテーションを追加します。AgentServiceConfig
リソースは、次の YAML のようになります。apiVersion: agent-install.openshift.io/v1beta1 kind: AgentServiceConfig metadata: annotations: agent-install.openshift.io/service-image-base: el8 ...
1.9.1.7. 関連情報
- ゼロタッチプロビジョニングの詳細は、OpenShift Container Platform ドキュメント の ネットワーク遠端の Challenge を参照してください。
- イメージプルシークレットの使用
1.9.2. Amazon Web Services での Central Infrastructure Management の有効化
Amazon Web Services でハブクラスターを実行していて、Central Infrastructure Management サービスを有効にする場合は、Central Infrastructure Management を central infrastructure management の有効化 後に、次の手順を実行します。
ハブクラスターにログインしていることを確認し、次のコマンドを実行して、
assisted-image-service
で設定された一意のドメインを見つけます。oc get routes --all-namespaces | grep assisted-image-service
ドメインは
assisted-image-service-multicluster-engine.apps.<yourdomain>.com
のようになります。ハブクラスターにログインしていることを確認し、
NLB
type
パラメーターを使用して一意のドメインで新しいIngressController
を作成します。以下の例を参照してください。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: ingress-controller-with-nlb namespace: openshift-ingress-operator spec: domain: nlb-apps.<domain>.com routeSelector: matchLabels: router-type: nlb endpointPublishingStrategy: type: LoadBalancerService loadBalancer: scope: External providerParameters: type: AWS aws: type: NLB
-
nlb-apps.<domain>.com
の<domain>
を<yourdomain>
に置き換えて、IngressController
のdomain
パラメーターに<yourdomain>
を追加します。 次のコマンドを実行して、新しい
IngressController
を適用します。oc apply -f ingresscontroller.yaml
次の手順を実行して、新しい
IngressController
のspec.domain
パラメーターの値が既存のIngressController
と競合していないことを確認します。次のコマンドを実行して、すべての
IngressController
を一覧表示します。oc get ingresscontroller -n openshift-ingress-operator
先ほど作成した
ingress-controller-with-nlb
を除く各IngressControllers
で次のコマンドを実行します。oc edit ingresscontroller <name> -n openshift-ingress-operator
spec.domain
レポートが見つからない場合は、nlb-apps.<domain>.com
を除く、クラスターで公開されているすべてのルートに一致するデフォルトドメインを追加します。spec.domain
レポートが提供されている場合は、指定された範囲からnlb-apps.<domain>.com
ルートが除外されていることを確認してください。
次のコマンドを実行して、
assisted-image-service
ルートを編集し、nlb-apps
の場所を使用します。oc edit route assisted-image-service -n <namespace>
デフォルトの namespace は、マルチクラスターエンジン Operator をインストールした場所です。
次の行を
assisted-image-service
ルートに追加します。metadata: labels: router-type: nlb name: assisted-image-service
assisted-image-service
ルートで、spec.host
の URL 値を見つけます。URL は次の例のようになります。assisted-image-service-multicluster-engine.apps.<yourdomain>.com
-
URL 内の
apps
をnlb-apps
に置き換えて、新しいIngressController
で設定されたドメインと一致させます。 Central Infrastructure Management サービスが Amazon Web Services で有効になっていることを確認するには、次のコマンドを実行して Pod が正常であることを確認します。
oc get pods -n multicluster-engine | grep assist
-
新しいホストインベントリーを作成し、ダウンロード URL が新しい
nlb-apps
URL を使用していることを確認します。
1.9.3. コンソールを使用したホストインベントリーの作成
ホストインベントリー (インフラストラクチャー環境) を作成して、OpenShift Container Platform クラスターをインストールできる物理マシンまたは仮想マシンを検出できます。
1.9.3.1. 前提条件
- Central Infrastructure Management サービスを有効にする。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
1.9.3.2. ホストインベントリーの作成
コンソールを使用してホストインベントリーを作成するには、次の手順を実行します。
- コンソールから、Infrastructure > Host inventory に移動して、Create infrastructure environment をクリックします。
次の情報をホストインベントリー設定に追加します。
-
名前: インフラストラクチャー環境の一意の名前。コンソールを使用してインフラストラクチャー環境を作成すると、選択した名前で
InfraEnv
リソースの新しい namespace も作成されます。コマンドラインインターフェイスを使用してInfraEnv
リソースを作成し、コンソールでリソースを監視する場合は、namespace とInfraEnv
に同じ名前を使用します。 - ネットワークタイプ: インフラストラクチャー環境に追加するホストが DHCP または静的ネットワークを使用するかどうかを指定します。静的ネットワーク設定には、追加の手順が必要です。
- 場所: ホストの地理的な場所を指定します。地理的なロケーションを使用して、ホストが配置されているデータセンターを定義できます。
- ラベル: このインフラストラクチャー環境で検出されたホストにラベルを追加できるオプションのフィールド。指定した場所はラベルのリストに自動的に追加されます。
- インフラストラクチャープロバイダーの認証情報: インフラストラクチャープロバイダーの認証情報を選択すると、プルシークレットおよび SSH 公開鍵フィールドに認証情報内の情報が自動的に入力されます。詳細は、オンプレミス環境の認証情報の作成 を参照してください。
- プルシークレット: OpenShift Container Platform リソースへのアクセスを可能にする OpenShift Container Platform プルシークレット。インフラストラクチャープロバイダーの認証情報を選択した場合、このフィールドには自動的に入力されます。
-
SSH 公開鍵: ホストとのセキュアな通信を可能にする SSH キー。これを使用してホストに接続し、トラブルシューティングを行うことができます。クラスターをインストールした後は、SSH 鍵を使用してホストに接続できなくなります。通常、鍵は
id_rsa.pub
ファイルにあります。デフォルトのファイルパスは~/.ssh/id_rsa.pub
です。SSH 公開鍵の値を含むインフラストラクチャープロバイダーの認証情報を選択した場合、このフィールドには自動的に入力されます。 ホストのプロキシー設定を有効にする場合は、有効にする設定を選択し、次の情報を入力します。
- HTTP プロキシー URL: HTTP リクエストのプロキシーの URL。
- HTTPS プロキシー URL: HTTP リクエストのプロキシーの URL。URL は HTTP で始まる必要があります。HTTPS はサポートされていません。値を指定しない場合、デフォルトで HTTP 接続と HTTPS 接続の両方に HTTP プロキシー URL が使用されます。
-
プロキシーなしドメイン: プロキシーを使用しないドメインのコンマ区切りのリスト。ドメイン名をピリオド (
.
) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*
) を追加し、すべての宛先のプロキシーをバイパスします。
- 必要に応じて、NTP プールまたはサーバーの IP 名またはドメイン名のコンマ区切りリストを指定して、独自のネットワークタイムプロトコル (NTP) ソースを追加します。
-
名前: インフラストラクチャー環境の一意の名前。コンソールを使用してインフラストラクチャー環境を作成すると、選択した名前で
コンソールでは使用できない詳細な設定オプションが必要な場合は、コマンドラインインターフェイスを使用したホストインベントリーの作成 に進みます。
高度な設定オプションが必要ない場合は、必要に応じて静的ネットワークの設定を続行し、インフラストラクチャー環境へのホストの追加を開始できます。
1.9.3.3. ホストインベントリーへのアクセス
ホストインベントリーにアクセスするには、コンソールで Infrastructure > Host inventory を選択します。一覧からインフラストラクチャー環境を選択し、詳細とホストを表示します。
1.9.3.4. 関連情報
ベアメタル上で Hosted Control Plane を設定するプロセスの一環としてホストインベントリーを作成した場合は、次の手順を実行します。
1.9.4. コマンドラインインターフェイスを使用したホストインベントリーの作成
ホストインベントリー (インフラストラクチャー環境) を作成して、OpenShift Container Platform クラスターをインストールできる物理マシンまたは仮想マシンを検出できます。自動化されたデプロイメントや、以下の高度な設定オプションには、コンソールの代わりにコマンドラインインターフェイスを使用します。
- 検出されたホストを既存のクラスター定義に自動的にバインドする
- Discovery Image の Ignition 設定をオーバーライドする
- iPXE の動作を制御する
- Discovery Image のカーネル引数を変更する
- 検出フェーズ中にホストに信頼させる追加の証明書を渡す
- 最新バージョンのデフォルトオプションではない、テスト用に起動する Red Hat CoreOS バージョンを選択する
1.9.4.1. 前提条件
- Central Infrastructure Management サービスを有効にする。詳細は、Central infrastructure management サービスの有効化 を参照してください。
1.9.4.2. ホストインベントリーの作成
コマンドラインインターフェイスを使用してホストインベントリー (インフラストラクチャー環境) を作成するには、次の手順を実行します。
次のコマンドを実行して、ハブクラスターにログインします。
oc login
リソースの namespace を作成します。
namespace.yaml
という名前のファイルを作成し、次の内容を追加します。apiVersion: v1 kind: Namespace metadata: name: <your_namespace> 1
- 1
- コンソールでインベントリーを監視するには、namespace とインフラストラクチャー環境に同じ名前を使用します。
以下のコマンドを実行して YAML コンテンツを適用します。
oc apply -f namespace.yaml
OpenShift Container Platform プルシークレット を含む
Secret
カスタムリソースを作成します。pull-secret.yaml
ファイルを作成し、以下の内容を追加します。apiVersion: v1 kind: Secret type: kubernetes.io/dockerconfigjson metadata: name: pull-secret 1 namespace: <your_namespace> stringData: .dockerconfigjson: <your_pull_secret> 2
以下のコマンドを実行して YAML コンテンツを適用します。
oc apply -f pull-secret.yaml
インフラストラクチャー環境を作成します。
infra-env.yaml
ファイルを作成し、以下の内容を追加します。必要に応じて値を置き換えます。apiVersion: agent-install.openshift.io/v1beta1 kind: InfraEnv metadata: name: myinfraenv namespace: <your_namespace> spec: proxy: httpProxy: <http://user:password@ipaddr:port> httpsProxy: <http://user:password@ipaddr:port> noProxy: additionalNTPSources: sshAuthorizedKey: pullSecretRef: name: <name> agentLabels: <key>: <value> nmStateConfigLabelSelector: matchLabels: <key>: <value> clusterRef: name: <cluster_name> namespace: <project_name> ignitionConfigOverride: '{"ignition": {"version": "3.1.0"}, …}' cpuArchitecture: x86_64 ipxeScriptType: DiscoveryImageAlways kernelArguments: - operation: append value: audit=0 additionalTrustBundle: <bundle> osImageVersion: <version>
InfraEnv
テーブルの次のフィールドの説明を参照してください。
フィールド | 任意または必須 | 設定 |
---|---|---|
| 任意 |
|
| 任意 |
HTTP リクエストのプロキシーの URLURL は |
| 任意 |
HTTP リクエストのプロキシーの URLURL は |
| 任意 | プロキシーを使用しない場合は、コンマで区切られたドメインおよび CIDR のリスト。 |
| 任意 | すべてのホストに追加するネットワークタイムプロトコル (NTP) ソース (ホスト名または IP) のリスト。これらは、DHCP などの他のオプションを使用して設定された NTP ソースに追加されます。 |
| 任意 | 検出フェーズ中のデバッグに使用するためにすべてのホストに追加される SSH 公開鍵。検出フェーズは、ホストを Discovery Image を起動するときです。 |
| 必須 | プルシークレットが含まれる Kubernetes シークレットの名前。 |
| 任意 |
|
| 任意 |
ホストの静的 IP、ブリッジ、ボンディングなどの高度なネットワーク設定を統合します。ホストネットワーク設定は、選択したラベルを持つ 1 つ以上の |
| 任意 |
スタンドアロンのオンプレミスクラスターを記述する既存の |
| 任意 |
ファイルの追加など、Red Hat CoreOS ライブイメージの Ignition 設定を変更します。必要に応じて |
| 任意 | サポートされている CPU アーキテクチャー x86_64、aarch64、ppc64le、または s390x のいずれかを選択します。デフォルト値は x86_64 です。 |
| 任意 |
起動に iPXE を使用している場合に、デフォルト値である |
| 任意 |
Discovery Image の起動時にカーネル引数を変更できます。 |
| 任意 |
PEM エンコードされた X.509 証明書バンドル。通常、ホストが再暗号化中間者 (MITM) プロキシーを備えたネットワーク内にある場合、またはコンテナーイメージレジストリーなど、他の目的でホストが証明書を信頼しなければならない場合に必要です。 |
| 任意 |
|
以下のコマンドを実行して YAML コンテンツを適用します。
oc apply -f infra-env.yaml
ホストインベントリーが作成されたことを確認するには、次のコマンドでステータスを確認します。
oc describe infraenv myinfraenv -n <your_namespace>
重要なプロパティーのリストは次のとおりです。
-
conditions
: イメージが正常に作成されたかどうかを示す標準の Kubernetes 条件。 -
isoDownloadURL
: Discovery Image をダウンロードするための URL。 -
createdTime
: イメージが最後に作成された時刻。InfraEnv
を変更する場合は、新しいイメージをダウンロードする前にタイムスタンプが更新されていることを確認してください。
注: InfraEnv
リソースを変更する場合は、createdTime
プロパティーを確認して、InfraEnv
が新しい Discovery Image を作成したことを確認してください。すでにホストを起動している場合は、最新の Discovery Image でホストを再起動します。
必要に応じて静的ネットワークを設定し、インフラストラクチャー環境へのホストの追加を開始することで続行できます。
1.9.4.3. 関連情報
1.9.5. インフラストラクチャー環境用の高度なネットワークの設定
1 つのインターフェイスで DHCP 以外のネットワークを必要とするホストの場合は、高度なネットワークを設定する必要があります。必要な設定には、1 つ以上のホストのネットワークを記述する NMStateConfig
リソースの 1 つ以上のインスタンスの作成が含まれます。
各 NMStateConfig
リソースには、InfraEnv
リソースの nmStateConfigLabelSelector
に一致するラベルが含まれている必要があります。nmStateConfigLabelSelector
の詳細は、コマンドラインインターフェイスを使用したホストインベントリーの作成 を参照してください。
Discovery Image には、参照されているすべての NMStateConfig
リソースで定義されたネットワーク設定が含まれています。起動後、各ホストは各設定をそのネットワークインターフェイスと比較し、適切な設定を適用します。
1.9.5.1. 前提条件
- Central Infrastructure Management サービスを有効にする。詳細は、Central infrastructure management サービスの有効化 を参照してください。
- ホストインベントリーを作成する。詳細は、コンソールを使用したホストインベントリーの作成 を参照してください。
1.9.5.2. コマンドラインインターフェイスを使用した高度なネットワークの設定
コマンドラインインターフェイスを使用してインフラストラクチャー環境の詳細ネットワークを設定するには、以下の手順を実行します。
nmstateconfig.yaml
という名前のファイルを作成し、以下のテンプレートのようなコンテンツを追加します。必要に応じて値を置き換えます。apiVersion: agent-install.openshift.io/v1beta1 kind: NMStateConfig metadata: name: mynmstateconfig namespace: <your-infraenv-namespace> labels: some-key: <some-value> spec: config: interfaces: - name: eth0 type: ethernet state: up mac-address: 02:00:00:80:12:14 ipv4: enabled: true address: - ip: 192.168.111.30 prefix-length: 24 dhcp: false - name: eth1 type: ethernet state: up mac-address: 02:00:00:80:12:15 ipv4: enabled: true address: - ip: 192.168.140.30 prefix-length: 24 dhcp: false dns-resolver: config: server: - 192.168.126.1 routes: config: - destination: 0.0.0.0/0 next-hop-address: 192.168.111.1 next-hop-interface: eth1 table-id: 254 - destination: 0.0.0.0/0 next-hop-address: 192.168.140.1 next-hop-interface: eth1 table-id: 254 interfaces: - name: "eth0" macAddress: "02:00:00:80:12:14" - name: "eth1" macAddress: "02:00:00:80:12:15"
フィールド | 任意または必須 | 設定 |
---|---|---|
| 必須 | 設定しているホストに関連した名前を使用してください。 |
| 必須 |
namespace は、 |
| 必須 |
|
| 任意 |
|
| 任意 |
指定された |
注: イメージサービスは、InfraEnv
プロパティーを更新するか、そのラベルセレクターに一致する NMStateConfig
リソースを変更すると、新しいイメージを自動的に作成します。InfraEnv
リソースの作成後に NMStateConfig
リソースを追加する場合は、InfraEnv
の createdTime
プロパティーを確認して、InfraEnv
が新しい Discovery Image を作成していることを確認してください。すでにホストを起動している場合は、最新の Discovery Image でホストを再起動します。
以下のコマンドを実行して YAML コンテンツを適用します。
oc apply -f nmstateconfig.yaml
1.9.5.3. 関連情報
1.9.6. Discovery Image を使用したホストのホストインベントリーへの追加
ホストインベントリー (インフラストラクチャー環境) を作成したら、ホストを検出してインベントリーに追加できます。
インベントリーにホストを追加するには、ISO ファイルをダウンロードして各サーバーにアタッチする方法を選択します。たとえば、仮想メディアを使用したり、ISO ファイルを USB ドライブに書き込んだりして、ISO ファイルをダウンロードできます。
重要: インストールが失敗しないようにするには、インストールプロセス中は Discovery ISO メディアをデバイスに接続したままにし、各ホストがデバイスから 1 回起動するように設定します。
1.9.6.1. 前提条件
- Central Infrastructure Management サービスを有効にする。詳細は、Central infrastructure management サービスの有効化 を参照してください。
- ホストインベントリーを作成する。詳細は、コンソールを使用したホストインベントリーの作成 を参照してください。
1.9.6.2. コンソールを使用したホストの追加
以下の手順に従って ISO ファイルをダウンロードしてください。
- コンソールで Infrastructure > Host inventory を選択します。
- 一覧からお使いのインフラストラクチャー環境を選択します。
Add hosts をクリックし、With Discovery ISO を選択します。
ISO ファイルをダウンロードするための URL が表示されます。ブートされたホストがホストインベントリーテーブルに表示されます。ホストが表示されるまでに数分かかる場合があります。
注記: デフォルトでは、提供される ISO は minimal ISO です。最小限の ISO には、ルートファイルシステム
RootFS
が含まれていません。RootFS
は後でダウンロードされます。完全な ISO を表示するには、URL 内のminimal.iso
をfull.iso
に置き換えます。- 各ホストを承認して使用できるようにします。Actions をクリックして Approve を選択し、インベントリーテーブルからホストを選択できます。
1.9.6.3. コマンドラインインターフェイスを使用したホストの追加
isoDownloadURL
プロパティー内の ISO ファイルをダウンロードするための URL は、InfraEnv
リソースのステータスに含まれます。InfraEnv
リソースの詳細は、コマンドラインインターフェイス を使用したホストインベントリーの作成を参照してください。
起動したホストごとに、同じ namespace に Agent
リソースを作成します。
次のコマンドを実行して、
InfraEnv
カスタムリソースのダウンロード URL を表示します。oc get infraenv -n <infra env namespace> <infra env name> -o jsonpath='{.status.isoDownloadURL}'
以下の出力を参照してください。
https://assisted-image-service-assisted-installer.apps.example-acm-hub.com/byapikey/eyJhbGciOiJFUzI1NiIsInC93XVCJ9.eyJpbmZyYV9lbnZfaWQcTA0Y38sWVjYi02MTA0LTQ4NDMtODasdkOGIxYTZkZGM5ZTUifQ.3ydTpHaXJmTasd7uDp2NvGUFRKin3Z9Qct3lvDky1N-5zj3KsRePhAM48aUccBqmucGt3g/4.16/x86_64/minimal.iso
注記: デフォルトでは、提供される ISO は minimal ISO です。最小限の ISO には、ルートファイルシステム
RootFS
が含まれていません。RootFS
は後でダウンロードされます。完全な ISO を表示するには、URL 内のminimal.iso
をfull.iso
に置き換えます。URL を使用して ISO ファイルをダウンロードし、ISO ファイルを使用してホストを起動します。
次に、各ホストを承認する必要があります。以下の手順を参照してください。
すべての
エージェント
をリスト表示するには、次のコマンドを実行します。oc get agent -n <infra env namespace>
次のような出力が得られます。
NAME CLUSTER APPROVED ROLE STAGE 24a92a6f-ea35-4d6f-9579-8f04c0d3591e false auto-assign
リストで承認ステータスが
false
のエージェント
を承認します。以下のコマンドを実行します。oc patch agent -n <infra env namespace> <agent name> -p '{"spec":{"approved":true}}' --type merge
承認ステータスを確認するには、次のコマンドを実行します。
oc get agent -n <infra env namespace>
値が
true
の、次のような出力が返されます。NAME CLUSTER APPROVED ROLE STAGE 173e3a84-88e2-4fe1-967f-1a9242503bec true auto-assign
1.9.6.4. 関連情報
1.9.7. ベアメタルホストのホストインベントリーへの自動追加
ホストインベントリー (インフラストラクチャー環境) を作成した後、ホストを検出してインベントリーに追加できます。各ホストの BareMetalHost
リソースおよび関連する BMC シークレットを作成することで、ベアメタル Operator が各ベアメタルホストのベースボード管理コントローラー (BMC) と通信できるようにすることで、インフラストラクチャー環境の Discovery Image の起動を自動化できます。自動化は、インフラストラクチャー環境を参照する BareMetalHost
のラベルによって設定されます。
自動化により以下のアクションが実行されます。
- インフラストラクチャー環境で表される Discovery Image を使用して、各ベアメタルホストを起動します。
- インフラストラクチャー環境または関連するネットワーク設定が更新された場合に、各ホストを最新の Discovery Image で再起動します。
-
検出時に各
Agent
リソースを対応するBareMetalHost
リソースに関連付けます。 -
BareMetalHost
からの情報 (ホスト名、ロール、インストールディスクなど) に基づいてAgent
リソースのプロパティーを更新します。 -
Agent
をクラスターノードとして使用することを承認します。
1.9.7.1. 前提条件
- Central Infrastructure Management サービスを有効にする。詳細は、Central infrastructure management サービスの有効化 を参照してください。
- ホストインベントリーを作成する。詳細は、コンソールを使用したホストインベントリーの作成 を参照してください。
1.9.7.2. コンソールを使用したベアメタルホストの追加
コンソールを使用してベアメタルホストをホストインベントリーに自動的に追加するには、次の手順を実行します。
- コンソールで Infrastructure > Host inventory を選択します。
- 一覧からお使いのインフラストラクチャー環境を選択します。
- Add hosts をクリックし、With BMC Form を選択します。
- 必要な情報を追加し、Create をクリックします。
1.9.7.3. コマンドラインインターフェイスを使用したベアメタルホストの追加
コマンドラインインターフェイスを使用してベアメタルホストをホストインベントリーに自動的に追加するには、以下の手順を実施します。
次の YAML コンテンツを適用し、必要に応じて値を置き換えて、BMC シークレットを作成します。
apiVersion: v1 kind: Secret metadata: name: <bmc-secret-name> namespace: <your_infraenv_namespace> 1 type: Opaque data: username: <username> password: <password>
- 1
- namespace は
InfraEnv
の namespace と同じである必要があります。
以下の YAML コンテンツを適用し、必要に応じて値を置き換えてベアメタルホストを作成します。
apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata: name: <bmh-name> namespace: <your_infraenv_namespace> 1 annotations: inspect.metal3.io: disabled labels: infraenvs.agent-install.openshift.io: <your-infraenv> 2 spec: online: true automatedCleaningMode: disabled 3 bootMACAddress: <your-mac-address> 4 bmc: address: <machine-address> 5 credentialsName: <bmc-secret-name> 6 rootDeviceHints: deviceName: /dev/sda 7
- 1
- namespace は
InfraEnv
の namespace と同じである必要があります。 - 2
- この名前は
InfrEnv
の名前と一致し、同じ namespace に存在する必要があります。 - 3
- 値を設定しない場合、
metadata
の値が自動的に使用されます。 - 4
- MAC アドレスがホスト上のいずれかのインターフェイスの MAC アドレスと一致することを確認してください。
- 5
- BMC のアドレスを使用します。詳細は 帯域外管理 IP アドレスのポートアクセス を参照してください。
- 6
credentialsName
の値が、作成した BMC シークレットの名前と一致していることを確認してください。- 7
- オプション: インストールディスクを選択します。利用可能なルートデバイスのヒントについては、BareMetalHost spec を参照してください。ホストが Discovery Image で起動され、対応する
Agent
リソースが作成された後、このヒントに従ってインストールディスクが設定されます。
ホストの電源をオンにすると、イメージのダウンロードが開始されます。これには数分かかる場合があります。ホストが検出されると、Agent
カスタムリソースが自動的に作成されます。
1.9.7.4. コマンドラインインターフェイスを使用したマネージドクラスターノードの削除
マネージドクラスターからマネージドクラスターノードを削除するには、サポートされている OpenShift Container Platform バージョンで実行されているハブクラスターが必要です。ノードの起動に必要な静的ネットワーク設定が利用可能である必要があります。エージェントとベアメタルホストを削除するときに、NMStateConfig
リソースを削除しないようにしてください。
1.9.7.4.1. ベアメタルホストを使用したマネージドクラスターノードの削除
ハブクラスター上にベアメタルホストがあり、マネージドクラスターからマネージドクラスターノードを削除する場合は、次の手順を実行します。
削除するノードの
BareMetalHost
リソースに次のアノテーションを追加します。bmac.agent-install.openshift.io/remove-agent-and-node-on-delete: true
次のコマンドを実行して、
BareMetalHost
リソースを削除します。<bmh-name>
は、BareMetalHost
の名前に置き換えます。oc delete bmh <bmh-name>
1.9.7.4.2. ベアメタルホストを使用しないマネージドクラスターノードの削除
ハブクラスターにベアメタルホストがなく、マネージドクラスターからマネージドクラスターノードを削除する場合は、OpenShift Container Platform ドキュメントの ノードの削除 手順に従ってください。
1.9.7.5. 関連情報
- ゼロタッチプロビジョニングの詳細は、OpenShift Container Platform ドキュメントの ネットワーク遠端のクラスター を参照してください。
- ベアメタルホストを使用するために必要なポートの詳細は、OpenShift Container Platform ドキュメントの 帯域外管理 IP アドレスのポートアクセス を参照してください。
- ルートデバイスのヒントの詳細は、OpenShift Container Platform ドキュメントの ベアメタルの設定 を参照してください。
- イメージプルシークレットの使用
- オンプレミス環境の認証情報の作成
- コンピュートマシンのスケーリングの詳細は、OpenShift Container Platform ドキュメントの コンピュートマシンセットの手動によるスケーリング を参照してください。
1.9.8. ホストインベントリーの管理
コンソールまたはコマンドラインインターフェイスを使用して、Agent
リソースの編集、ホストインベントリーの管理、既存のホストの編集が可能です。
1.9.8.1. コンソールを使用したホストインベントリーの管理
Discovery ISO で正常に起動した各ホストは、ホストインベントリーの行として表示されます。コンソールを使用してホストを編集および管理できます。ホストを手動で起動し、ベアメタル Operator の自動化を使用していない場合は、使用する前にコンソールでホストを承認する必要があります。OpenShift ノードとしてインストールできるホストが Available
ステータスになっています。
1.9.8.2. コマンドラインインターフェイスを使用したホストインベントリーの管理
Agent
リソースは、各ホストを表します。Agent
リソースで次のプロパティーを設定できます。
clusterDeploymentName
このプロパティーは、クラスターにノードとしてインストールする場合に使用する
ClusterDeployment
の namespace および名前に設定します。任意:
role
クラスター内のホストのロールを設定します。使用できる値は、
master
、worker
、およびauto-assign
です。デフォルト値はauto-assign
です。hostname
ホストのホスト名を設定します。ホストに有効なホスト名が自動的に割り当てられる場合は任意です (例: DHCP を使用)。
approved
ホストを OpenShift ノードとしてインストールできるかどうかを示します。このプロパティーは、デフォルト値が
False
のブール値です。ホストを手動で起動しており、ベアメタル Operator の自動化を使用していない場合は、ホストをインストールする前にこのプロパティーをTrue
に設定する必要があります。installation_disk_id
ホストのインベントリーに表示されるインストールディスクの ID。
installerArgs
ホストの coreos-installer 引数のオーバーライドが含まれる JSON 形式の文字列。このプロパティーを使用して、カーネル引数を変更できます。構文例を以下に示します。
["--append-karg", "ip=192.0.2.2::192.0.2.254:255.255.255.0:core0.example.com:enp1s0:none", "--save-partindex", "4"]
ignitionConfigOverrides
ホストの Ignition 設定のオーバーライドが含まれる JSON 形式の文字列。このプロパティーを使用して、ignition を使用してファイルをホストに追加できます。構文例を以下に示します。
{"ignition": "version": "3.1.0"}, "storage": {"files": [{"path": "/tmp/example", "contents": {"source": "data:text/plain;base64,aGVscGltdHJhcHBlZGluYXN3YWdnZXJzcGVj"}}]}}
nodeLabels
ホストのインストール後にノードに適用されるラベルのリスト。
Agent
リソースの status
には、以下のプロパティーがあります。
role
クラスター内のホストのロールを設定します。これまでに
Agent
リソースでrole
をしたことがある場合は、その値がstatus
に表示されます。inventory
ホスト上で実行されているエージェントが検出するホストプロパティーが含まれます。
progress
ホストのインストールの進行状況。
ntpSources
ホストの設定済みの Network Time Protocol (NTP) ソース。
conditions
次の標準 Kubernetes 条件 (
True
またはFalse
値) が含まれます。-
SpecSynced: 指定されたすべてのプロパティーが正常に適用される場合は
True
。何らかのエラーが発生した場合は、False
。 -
Connected: インストールサービスへのエージェント接続が禁止されていない場合は
True
。エージェントがしばらくの間インストールサービスに接続していない場合はFalse
。 -
RequirementsMet: ホストがインストールを開始する準備ができている場合は
True
。 -
Validated: すべてのホスト検証に合格した場合は
True
。 -
installed: ホストが OpenShift ノードとしてインストールされている場合は
True
。 -
Bound: ホストがクラスターにバインドされている場合は
True
。 -
Cleanup:
Agent
リソースの削除リクエストが失敗した場合はFalse
。
-
SpecSynced: 指定されたすべてのプロパティーが正常に適用される場合は
debugInfo
インストールログおよびイベントをダウンロードするための URL が含まれています。
validationsInfo
ホストの検出後にインストールが成功したことを確認するためにエージェントが実行する検証の情報が含まれます。値が
False
の場合は、トラブルシューティングを行ってください。installation_disk_id
ホストのインベントリーに表示されるインストールディスクの ID。