19.3. RHACM および SiteConfig リソースを使用したマネージドクラスターのインストール


Red Hat Advanced Cluster Management (RHACM) を使用して OpenShift Container Platform クラスターを大規模にプロビジョニングするには、アシストサービスと、コア削減テクノロジーが有効になっている GitOps プラグインポリシージェネレーターを使用します。ゼロタッチプライオビジョン (ZTP) パイプラインがクラスターのインストールを実行します。ZTP は、切断された環境で使用できます。

19.3.1. GitOps ZTP および Topology Aware Lifecycle Manager

GitOps ゼロタッチプロビジョニング (ZTP) は、Git に格納されたマニフェストからインストールと設定の CR を生成します。これらのアーティファクトは、Red Hat Advanced Cluster Management (RHACM)、アシストサービス、および Topology Aware Lifecycle Manager (TALM) が CR を使用してマネージドクラスターをインストールおよび設定する中央ハブクラスターに適用されます。ZTP パイプラインの設定フェーズでは、TALM を使用してクラスターへの設定 CR の適用をオーケストレートします。GitOps ZTP と TALM の間には、いくつかの重要な統合ポイントがあります。

Inform ポリシー
デフォルトでは、GitOps ZTP は、inform の修復アクションですべてのポリシーを作成します。これらのポリシーにより、RHACM はポリシーに関連するクラスターのコンプライアンスステータスを報告しますが、必要な設定は適用されません。ZTP プロセス中、OpenShift のインストール後、TALM は作成された inform ポリシーをステップスルーし、ターゲットのマネージドクラスターに適用します。これにより、設定がマネージドクラスターに適用されます。クラスターライフサイクルの ZTP フェーズ以外では、影響を受けるマネージドクラスターに変更をすぐにロールアウトするリスクなしに、ポリシーを変更できます。TALM を使用して、修正されたクラスターのタイミングとセットを制御できます。
ClusterGroupUpgrade CR の自動作成

新しくデプロイされたクラスターの初期設定を自動化するために、TALM はハブクラスター上のすべての ManagedCluster CR の状態を監視します。新規に作成された ManagedCluster CR を含む ztp-done ラベルを持たない ManagedCluster CR が適用されると、TALM は以下の特性で ClusterGroupUpgrade CR を自動的に作成します。

  • ClusterGroupUpgrade CR が ztp-install namespace に作成され、有効にされます。
  • ClusterGroupUpgrade CR の名前は ManagedCluster CR と同じになります。
  • クラスターセレクターには、その ManagedCluster CR に関連付けられたクラスターのみが含まれます。
  • 管理ポリシーのセットには、ClusterGroupUpgrade の作成時に RHACM がクラスターにバインドされているすべてのポリシーが含まれます。
  • 事前キャッシュは無効です。
  • タイムアウトを 4 時間 (240 分) に設定。

有効な ClusterGroupUpgrade の自動生成により、ユーザーの介入を必要としないゼロタッチのクラスターデプロイメントが可能になります。さらに、ztp-done ラベルのない ManagedCluster に対して ClusterGroupUpgrade CR が自動的に作成されるため、失敗した ZTP インストールを、そのクラスターの ClusterGroupUpgrade CR を削除するだけで再開することができます。

Waves

PolicyGenTemplate CR から生成される各ポリシーには、ztp-deploy-wave アノテーションが含まれます。このアノテーションは、そのポリシーに含まれる各 CR と同じアノテーションに基づいています。wave アノテーションは、自動生成された ClusterGroupUpgrade CR でポリシーを順序付けするために使用されます。wave アノテーションは、自動生成された ClusterGroupUpgrade CR 以外には使用されません。

注記

同じポリシーのすべての CR には ztp-deploy-wave アノテーションに同じ設定が必要です。各 CR のこのアノテーションのデフォルト値は PolicyGenTemplate で上書きできます。ソース CR の wave アノテーションは、ポリシーの wave アノテーションを判別し、設定するために使用されます。このアノテーションは、実行時に生成されるポリシーに含まれるビルドされる各 CR から削除されます。

TALM は、wave アノテーションで指定された順序で設定ポリシーを適用します。TALM は、各ポリシーが準拠しているのを待ってから次のポリシーに移動します。各 CR の wave アノテーションは、それらの CR がクラスターに適用されるための前提条件を確実に考慮することが重要である。たとえば、Operator は Operator の設定前後にインストールする必要があります。同様に、Operator 用 CatalogSource は、Operator 用サブスクリプションの前または同時にウェーブにインストールする必要があります。各 CR のデフォルトの波動値は、これらの前提条件を考慮したものです。

複数の CR およびポリシーは同じアンブ番号を共有できます。ポリシーの数を少なくすることで、デプロイメントを高速化し、CPU 使用率を低減させることができます。多くの CR を比較的少なくするのがベストプラクティスです。

各ソース CR でデフォルトの wave 値を確認するには、ztp-site-generate コンテナーイメージからデプロイメントした out/source-crs ディレクトリーに対して以下のコマンドを実行します。

$ grep -r "ztp-deploy-wave" out/source-crs
フェーズラベル

ClusterGroupUpgrade CR は自動的に作成され、ZTP プロセスの開始時と終了時に ManagedCluster CR をラベルでアノテートするディレクティブが含まれています。

インストール後の ZTP 設定開始時には、ManagedCluster にztp-running という ラベルが貼られています。すべてのポリシーがクラスターに修復され、完全に準拠されると、TALM は ztp-running ラベルを削除し、ztp-done ラベルを適用します。

informDuValidator ポリシーを使用するデプロイメントでは、クラスターが完全にアプリケーションをデプロイするための準備が整った時点で ztp-done ラベルが適用されます。これには、ZTP が適用される設定 CR のすべての調整および影響が含まれます。ztp-done ラベルは、TALM による ClusterGroupUpgrade CR の自動作成に影響します。クラスターの最初の ZTP インストール後は、このラベルを操作しないでください。

リンクされた CR
自動的に作成された ClusterGroupUpgrade CR には所有者の参照が、そこから派生した ManagedCluster として設定されます。この参照により、ManagedCluster CR を削除すると、ClusterGroupUpgrade のインスタンスがサポートされるリソースと共に削除されるようにします。

19.3.2. ZTP を使用したマネージドクラスターのデプロイの概要

Red Hat Advanced Cluster Management (RHACM) は、ゼロタッチプロビジョニング (ZTP) を使用して、単一ノードの OpenShift Container Platform クラスター、3 ノードのクラスター、および標準クラスターをデプロイします。サイト設定データは、Git リポジトリーで OpenShift Container Platform カスタムリソース (CR) として管理します。ZTP は、宣言的な GitOps アプローチを使用して、一度開発すればどこにでもデプロイメントするモデルを使用して、マネージドクラスターをデプロイメントします。

クラスターのデプロイメントには、以下が含まれます。

  • ホストオペレーティングシステム (RHCOS) の空のサーバーへのインストール。
  • OpenShift Container Platform のデプロイ
  • クラスターポリシーおよびサイトサブスクリプションの作成
  • サーバーオペレーティングシステムに必要なネットワーク設定を行う
  • プロファイル Operator をデプロイし、パフォーマンスプロファイル、PTP、SR-IOV などの必要なソフトウェア関連の設定を実行します。
マネージドサイトのインストールプロセスの概要

マネージドサイトのカスタムリソース (CR) をハブクラスターに適用すると、次のアクションが自動的に実行されます。

  1. Discovery イメージの ISO ファイルが生成され、ターゲットホストで起動します。
  2. ISO ファイルがターゲットホストで正常に起動すると、ホストのハードウェア情報が RHACM にレポートされます。
  3. すべてのホストの検出後に、OpenShift Container Platform がインストールされます。
  4. OpenShift Container Platform のインストールが完了すると、ハブは klusterlet サービスをターゲットクラスターにインストールします。
  5. 要求されたアドオンサービスがターゲットクラスターにインストールされている。

マネージドクラスターの Agent CR がハブクラスター上に作成されると、検出イメージ ISO プロセスが完了します。

重要

ターゲットのベアメタルホストは、vDU アプリケーションワークロードに推奨される単一ノード OpenShift クラスター設定 に記載されているネットワーク、ファームウェア、およびハードウェアの要件を満たす必要があります。

19.3.3. マネージドベアメタルホストシークレットの作成

マネージドベアメタルホストに必要な Secret カスタムリソース (CR) をハブクラスターに追加します。ZTP パイプラインが Baseboard Management Controller (BMC) にアクセスするためのシークレットと、アシストインストーラーサービスがレジストリーからクラスターインストールイメージを取得するためのシークレットが必要です。

注記

シークレットは、SiteConfig CR から名前で参照されます。namespace は SiteConfig namespace と一致する必要があります。

手順

  1. ホスト Baseboard Management Controller (BMC) の認証情報と、OpenShift およびすべてのアドオンクラスター Operator のインストールに必要なプルシークレットを含む YAML シークレットファイルを作成します。

    1. 次の YAML をファイル example-sno-secret.yaml として保存します。

      apiVersion: v1
      kind: Secret
      metadata:
        name: example-sno-bmc-secret
        namespace: example-sno 1
      data: 2
        password: <base64_password>
        username: <base64_username>
      type: Opaque
      ---
      apiVersion: v1
      kind: Secret
      metadata:
        name: pull-secret
        namespace: example-sno  3
      data:
        .dockerconfigjson: <pull_secret> 4
      type: kubernetes.io/dockerconfigjson
      1
      関連する SiteConfig CR で設定された namespace と一致する必要があります
      2
      passwordusername の Base64 エンコード値
      3
      関連する SiteConfig CR で設定された namespace と一致する必要があります
      4
      Base64 でエンコードされたプルシークレット
  2. example-sno-secret.yaml への相対パスを、クラスターのインストールに使用する kustomization.yaml ファイルに追加します。

19.3.4. SiteConfig と ZTP を使用したマネージドクラスターのデプロイ

次の手順を使用して、SiteConfig カスタムリソース (CR) と関連ファイルを作成し、ゼロタッチプロビジョニング (ZTP) クラスターのデプロイメントを開始します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしていることを確認します。
  • 必要なインストール CR とポリシー CR を生成するためにハブクラスターを設定している。
  • カスタムサイトの設定データを管理する Git リポジトリーを作成しています。リポジトリーはハブクラスターからアクセスできる必要があり、ArgoCD アプリケーションのソースリポジトリーとして設定する必要があります。詳細は、「GitOps ZTP サイト設定リポジトリーの準備」を参照してください。

    注記

    ソースリポジトリーを作成するときは、ztp-site-generate コンテナーから抽出した argocd/deployment/argocd-openshift-gitops-patch.json パッチファイルを使用して ArgoCD アプリケーションにパッチを適用してください。「ArgoCD を使用したハブクラスターの設定」を参照してください。

  • マネージドクラスターをプロビジョニングする準備を整えるには、各ベアメタルホストごとに次のものが必要です。

    ネットワーク接続
    ネットワークには DNS が必要です。マネージドクラスターホストは、ハブクラスターから到達可能である必要があります。ハブクラスターとマネージドクラスターホストの間にレイヤー 3 接続が存在することを確認します。
    Baseboard Management Controller (BMC) の詳細
    ZTP は、BMC のユーザー名とパスワードの詳細を使用して、クラスターのインストール中に BMC に接続します。GitOps ZTP プラグインは、サイトの Git リポジトリーの SiteConfig CR に基づいて、ハブクラスター上の ManagedCluster CR を管理します。ホストごとに個別の BMCSecret CR を手動で作成します。

    手順

    1. ハブクラスターで必要なマネージドクラスターシークレットを作成します。これらのリソースは、クラスター名と一致する名前を持つネームスペースに存在する必要があります。たとえば、out/argocd/example/siteconfig/example-sno.yaml では、クラスター名と namespace が example-sno になっています。

      1. 次のコマンドを実行して、クラスター namespace をエクスポートします。

        $ export CLUSTERNS=example-sno
      2. namespace を作成します。

        $ oc create namespace $CLUSTERNS
    2. マネージドクラスターのプルシークレットと BMC Secret CR を作成します。プルシークレットには、OpenShift Container Platform のインストールに必要なすべての認証情報と、必要なすべての Operator を含める必要があります。詳細は、「マネージドベアメタルホストシークレットの作成」を参照してください。

      注記

      シークレットは、名前で SiteConfig カスタムリソース (CR) から参照されます。namespace は SiteConfig namespace と一致する必要があります。

    3. Git リポジトリーのローカルクローンに、クラスターの SiteConfig CR を作成します。

      1. out/argocd/example/siteconfig/ フォルダーから CR の適切な例を選択します。フォルダーには、単一ノード、3 ノード、標準クラスターのサンプルファイルが含まれます。

        • example-sno.yaml
        • example-3node.yaml
        • example-standard.yaml
      2. サンプルファイルのクラスターおよびホスト詳細を、必要なクラスタータイプに一致するように変更します。以下に例を示します。

        単一ノードの OpenShift クラスター SiteConfig CR の例

        apiVersion: ran.openshift.io/v1
        kind: SiteConfig
        metadata:
          name: "<site_name>"
          namespace: "<site_name>"
        spec:
          baseDomain: "example.com"
          pullSecretRef:
            name: "assisted-deployment-pull-secret" 1
          clusterImageSetNameRef: "openshift-4.10" 2
          sshPublicKey: "ssh-rsa AAAA..." 3
          clusters:
          - clusterName: "<site_name>"
            networkType: "OVNKubernetes"
            clusterLabels: 4
              common: true
              group-du-sno: ""
              sites : "<site_name>"
            clusterNetwork:
              - cidr: 1001:1::/48
                hostPrefix: 64
            machineNetwork:
              - cidr: 1111:2222:3333:4444::/64
            serviceNetwork:
              - 1001:2::/112
            additionalNTPSources:
              - 1111:2222:3333:4444::2
            #crTemplates:
            #  KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml" 5
            nodes:
              - hostName: "example-node.example.com" 6
                role: "master"
                #biosConfigRef:
                #  filePath: "example-hw.profile" 7
                bmcAddress: idrac-virtualmedia://<out_of_band_ip>/<system_id>/ 8
                bmcCredentialsName:
                  name: "bmh-secret" 9
                bootMACAddress: "AA:BB:CC:DD:EE:11"
                bootMode: "UEFI" 10
                rootDeviceHints:
                  wwn: "0x11111000000asd123"
                cpuset: "0-1,52-53"
                nodeNetwork: 11
                  interfaces:
                    - name: eno1
                      macAddress: "AA:BB:CC:DD:EE:11"
                  config:
                    interfaces:
                      - name: eno1
                        type: ethernet
                        state: up
                        ipv4:
                          enabled: false
                        ipv6: 12
                          enabled: true
                          address:
                          - ip: 1111:2222:3333:4444::aaaa:1
                            prefix-length: 64
                    dns-resolver:
                      config:
                        search:
                        - example.com
                        server:
                        - 1111:2222:3333:4444::2
                    routes:
                      config:
                      - destination: ::/0
                        next-hop-interface: eno1
                        next-hop-address: 1111:2222:3333:4444::1
                        table-id: 254

        1
        SiteConfig CR と同じ namespace を使用して、assisted-deployment-pull-secret CR を作成します。
        2
        clusterImageSetNameRef は、ハブクラスターで使用可能なイメージセットを定義します。ハブクラスターでサポートされるバージョンの一覧を表示するには、oc get clusterimagesets を実行します。
        3
        クラスターへのアクセスに使用する SSH 公開鍵を設定します。
        4
        クラスターラベルは、定義した PolicyGenTemplate CR の bindingRules フィールドに対応している必要があります。たとえば、policygentemplates/common-ranGen.yamlcommon: true が設定されたすべてのクラスターに適用され、policygentemplates/group-du-sno-ranGen.yamlgroup-du-sno: "" が設定されたすべてのクラスターに適用されます。
        5
        オプション: KlusterletAddonConfig で指定された CR は、クラスター用に作成されたデフォルトの KlusterletAddonConfig をオーバーライドするために使用されます。
        6
        単一ノードの導入では、単一のホストを定義します。3 ノードのデプロイメントの場合、3 台のホストを定義します。標準のデプロイメントでは、role: master と、role: worker で定義される 2 つ以上のホストを持つ 3 つのホストを定義します。
        7
        オプション: biosConfigRef を使用して、ホストに必要なファームウェアを設定します。
        8
        すべてのクラスタータイプに適用されます。BMC アドレスを指定します。
        9
        BMC 認証情報を指定する bmh-secret CR を作成します。SiteConfig CR と同じ namespace を使用します。
        10
        UEFISecureBoot を使用して、ホストでセキュアブートを有効にします。
        11
        ノードのネットワーク設定を指定します。
        12
        ホストの IPv6 アドレスを設定します。静的 IP アドレスを持つ単一ノードの OpenShift クラスターの場合、ノード固有の API と Ingress IP は同じである必要があります。
        注記

        BMC アドレッシングの詳細については、「関連情報」セクションを参照してください。

      3. out/argocd/extra-manifest で extra-manifest MachineConfig CR のデフォルトセットを検査できます。これは、インストール時にクラスターに自動的に適用されます。
      4. オプション: プロビジョニングされたクラスターに追加のインストール時マニフェストをプロビジョニングするには、Git リポジトリーに sno-extra-manifest/ などのディレクトリーを作成し、このディレクトリーにカスタムマニフェストの CR を追加します。SiteConfig.yamlextraManifestPath フィールドでこのディレクトリーを参照する場合、この参照ディレクトリーの CR はすべて、デフォルトの追加マニフェスト セットに追加されます。
    4. out/argocd/example/siteconfig/kustomization.yaml に示す例のように、generators セクションの kustomization.yaml ファイルに SiteConfig CR を追加してください。
    5. SiteConfig CR と関連する kustomization.yaml の変更を Git リポジトリーにコミットし、変更をプッシュします。

      ArgoCD パイプラインが変更を検出し、マネージドクラスターのデプロイを開始します。

19.3.5. マネージドクラスターのインストールの進行状況の監視

ArgoCD パイプラインは、SiteConfig CR を使用してクラスター設定 CR を生成し、それをハブクラスターと同期します。ArgoCD ダッシュボードでこの同期の進捗をモニターできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしていることを確認します。

手順

同期が完了すると、インストールは一般的に以下のように行われます。

  1. Assisted Service Operator は OpenShift Container Platform をクラスターにインストールします。次のコマンドを実行して、RHACM ダッシュボードまたはコマンドラインからクラスターのインストールの進行状況を監視できます。

    1. クラスター名をエクスポートします。

      $ export CLUSTER=<clusterName>
    2. マネージドクラスターの AgentClusterInstall CR をクエリーします。

      $ oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Completed")]}' | jq
    3. クラスターのインストールイベントを取得します。

      $ curl -sk $(oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.debugInfo.eventsURL}')  | jq '.[-2,-1]'

19.3.6. インストール CR の検証による GitOps ZTP のトラブルシューティング

ArgoCD パイプラインは SiteConfigPolicyGenTemplate カスタムリソース (CR) を使用して、クラスター設定 CR と Red Hat Advanced Cluster Management (RHACM) ポリシーを生成します。以下の手順に従って、このプロセス時に発生する可能性のある問題のトラブルシューティングを行います。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしていることを確認します。

手順

  1. インストール CR が作成されたことは、以下のコマンドで確認することができます。

    $ oc get AgentClusterInstall -n <cluster_name>

    オブジェクトが返されない場合は、以下の手順を使用して ArgoCD パイプラインフローを SiteConfig ファイルからインストール CR にトラブルシューティングします。

  2. ハブクラスターで SiteConfig CR を使用して ManagedCluster CR が生成されたことを確認します。

    $ oc get managedcluster
  3. ManagedCluster が見つからない場合は、clusters アプリケーションが Git リポジトリーからハブクラスターへのファイルの同期に失敗したかどうかを確認します。

    $ oc describe -n openshift-gitops application clusters
    1. Status.Conditions フィールドを確認して、マネージドクラスターのエラーログを表示します。たとえば、SiteConfig CR で extraManifestPath: に無効な値を設定すると、次のエラーが発生します。

      Status:
        Conditions:
          Last Transition Time:  2021-11-26T17:21:39Z
          Message:               rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/siteconfigs/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not create extra-manifest ranSite1.extra-manifest3 stat extra-manifest3: no such file or directory 2021/11/26 17:21:40 Error: could not build the entire SiteConfig defined by /tmp/kust-plugin-config-913473579: stat extra-manifest3: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-913473579; exit status 1: exit status 1
          Type:  ComparisonError
    2. Status.Sync フィールドを確認します。ログエラーがある場合、Status.Sync フィールドは Unknown エラーを示している可能性があります。

      Status:
        Sync:
          Compared To:
            Destination:
              Namespace:  clusters-sub
              Server:     https://kubernetes.default.svc
            Source:
              Path:             sites-config
              Repo URL:         https://git.com/ran-sites/siteconfigs/.git
              Target Revision:  master
          Status:               Unknown

19.3.7. ZTP パイプラインからマネージドクラスターサイトを削除

ZTP パイプラインから、マネージドサイトと、関連するインストールおよび設定ポリシーの CR を削除できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしていることを確認します。

手順

  1. 関連する SiteConfig ファイルと PolicyGenTemplate ファイルを kustomization.yaml ファイルから削除して、サイトと関連する CR を削除します。

    ZTP パイプラインを再度実行すると、生成された CR が削除されます。

  2. 任意: サイトを永続的に削除する場合は、Git リポジトリーから SiteConfig ファイルおよびサイト固有の PolicyGenTemplate ファイルも削除する必要があります。
  3. 任意: たとえば、サイトを再デプロイする際にサイトを一時的に削除する場合には、Git リポジトリーに SiteConfig およびサイト固有の PolicyGenTemplate CR を残しておくことができます。
注記

Git リポジトリーから SiteConfig ファイルを削除した後、対応するクラスターがデタッチプロセスで停止する場合は、デタッチされたクラスターのクリーンアップに関する情報について、ハブクラスターの Red Hat Advanced Cluster Management (RHACM) を確認してください。

関連情報

19.3.8. 古いコンテンツを ZTP パイプラインから削除する

ポリシーの名前を変更した場合など、PolicyGenTemplate 設定を変更した結果、古いポリシーが作成された場合は、次の手順を使用して古いポリシーを削除します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしていることを確認します。

手順

  1. Git リポジトリーから影響を受ける PolicyGenTemplate ファイルを削除し、コミットしてリモートリポジトリーにプッシュしてください。
  2. アプリケーションを介して変更が同期され、影響を受けるポリシーがハブクラスターから削除されるのを待ちます。
  3. 更新された PolicyGenTemplate ファイルを Git リポジトリーに再び追加し、リモートリポジトリーにコミットし、プッシュします。

    注記

    Git リポジトリーからゼロタッチプロビジョニング (ZTP) ポリシーを削除し、その結果、ハブクラスターからもポリシーを削除しても、マネージドクラスターの設定には影響しません。ポリシーとそのポリシーによって管理される CR は、マネージドクラスターに残ります。

  4. 任意: 別の方法として、PolicyGenTemplate CR に変更を加えて古いポリシーを作成した後、これらのポリシーをハブクラスターから手動で削除することができます。ポリシーの削除は、RHACM コンソールから Governance タブを使用するか、以下のコマンドを使用して行うことができます。

    $ oc delete policy -n <namespace> <policy_name>

19.3.9. ZTP パイプラインの解体

ArgoCD パイプラインと生成されたすべての ZTP アーティファクトを削除できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしていることを確認します。

手順

  1. ハブクラスターの Red Hat Advanced Cluster Management (RHACM) からすべてのクラスターを切り離します。
  2. 次のコマンドを使用して、deployment ディレクトリーの kustomization.yaml ファイルを削除します。

    $ oc delete -k out/argocd/deployment
  3. 変更をコミットして、サイトリポジトリーにプッシュします。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.