Hosted Control Plane

手順

1. 次のコマンドを実行して、ホスティングクラスターで HostedCluster カスタムリソース (CR) を編集します。

   $ oc edit <hosted_cluster_name> -n <hosted_cluster_namespace>

   Copy to Clipboard Toggle word wrap

2. 次の例を使用して、HostedCluster CR に OAuth 設定を追加します。

   apiVersion: hypershift.openshift.io/v1alpha1
   kind: HostedCluster
   metadata:
     name: <hosted_cluster_name> 

   1

   
     namespace: <hosted_cluster_namespace> 

   2

   
   spec:
     configuration:
       oauth:
         identityProviders:
         - openID: 

   3

   
             claims:
               email: 

   4

   
                 - <email_address>
               name: 

   5

   
                 - <display_name>
               preferredUsername: 

   6

   
                 - <preferred_username>
             clientID: <client_id> 

   7

   
             clientSecret:
               name: <client_id_secret_name> 

   8

   
             issuer: https://example.com/identity 

   9

   
           mappingMethod: lookup 

   10

   
           name: IAM
           type: OpenID

   Copy to Clipboard Toggle word wrap

   1

   ホステッドクラスターの名前を指定します。

   2

   ホステッドクラスターの namespace を指定します。

   3

   このプロバイダー名はアイデンティティー要求の値に接頭辞として付加され、アイデンティティー名が作成されます。プロバイダー名はリダイレクト URL の構築にも使用されます。

   4

   メールアドレスとして使用する属性のリストを定義します。

   5

   表示名として使用する属性のリストを定義します。

   6

   優先ユーザー名として使用する属性のリストを定義します。

   7

   OpenID プロバイダーに登録されたクライアントの ID を定義します。このクライアントを URL https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name> にリダイレクトできるようにする必要があります。

   8

   OpenID プロバイダーに登録されたクライアントのシークレットを定義します。

   9

   OpenID の仕様で説明されている Issuer Identifier。クエリーまたはフラグメントコンポーネントのない https を使用する必要があります。

   10

   このプロバイダーのアイデンティティーと User オブジェクトの間でマッピングを確立する方法を制御するマッピング方法を定義します。

3. 変更を適用するためにファイルを保存します。

手順

1. Home → API Explorer に移動します。
2. Filter by kind ボックスを使用して、HostedCluster リソースを検索します。
3. 編集する HostedCluster リソースをクリックします。
4. Instances タブをクリックします。
5. ホステッドクラスター名エントリーの横にあるオプションメニュー をクリックし、Edit HostedCluster をクリックします。

6. YAML ファイルに OAuth 設定を追加します。

   spec:
     configuration:
       oauth:
         identityProviders:
         - openID: 

   1

   
             claims:
               email: 

   2

   
                 - <email_address>
               name: 

   3

   
                 - <display_name>
               preferredUsername: 

   4

   
                 - <preferred_username>
             clientID: <client_id> 

   5

   
             clientSecret:
               name: <client_id_secret_name> 

   6

   
             issuer: https://example.com/identity 

   7

   
           mappingMethod: lookup 

   8

   
           name: IAM
           type: OpenID

   Copy to Clipboard Toggle word wrap

   1

   このプロバイダー名はアイデンティティー要求の値に接頭辞として付加され、アイデンティティー名が作成されます。プロバイダー名はリダイレクト URL の構築にも使用されます。

   2

   メールアドレスとして使用する属性のリストを定義します。

   3

   表示名として使用する属性のリストを定義します。

   4

   優先ユーザー名として使用する属性のリストを定義します。

   5

   OpenID プロバイダーに登録されたクライアントの ID を定義します。このクライアントを URL https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name> にリダイレクトできるようにする必要があります。

   6

   OpenID プロバイダーに登録されたクライアントのシークレットを定義します。

   7

   OpenID の仕様で説明されている Issuer Identifier。クエリーまたはフラグメントコンポーネントのない https を使用する必要があります。

   8

   このプロバイダーのアイデンティティーと User オブジェクトの間でマッピングを確立する方法を制御するマッピング方法を定義します。

7. Save をクリックします。

手順

1. 次のコマンドを実行して、ホステッドクラスターで CCO が手動モードで設定されていることを確認します。

   $ oc get cloudcredentials <hosted_cluster_name> -n <hosted_cluster_namespace> -o=jsonpath={.spec.credentialsMode}

   Copy to Clipboard Toggle word wrap

   予想される出力

   Manual

   Copy to Clipboard Toggle word wrap

2. 次のコマンドを実行して、serviceAccountIssuer リソースの値が空でないことを確認します。

   $ oc get authentication cluster --kubeconfig <hosted_cluster_name>.kubeconfig -o jsonpath --template '{.spec.serviceAccountIssuer }'

   Copy to Clipboard Toggle word wrap

   出力例

   https://aos-hypershift-ci-oidc-29999.s3.us-east-2.amazonaws.com/hypershift-ci-29999

   Copy to Clipboard Toggle word wrap

手順

1. Operator プロジェクトの ClusterServiceVersion (CSV) オブジェクトを更新します。

   1. Operator が CredentialsRequests オブジェクトを作成する RBAC 権限を持っていることを確認します。

      例3.1 clusterPermissions リストの例

      # ...
      install:
        spec:
          clusterPermissions:
          - rules:
            - apiGroups:
              - "cloudcredential.openshift.io"
              resources:
              - credentialsrequests
              verbs:
              - create
              - delete
              - get
              - list
              - patch
              - update
              - watch

      Copy to Clipboard Toggle word wrap

   2. AWS STS を使用したこの CCO ベースのワークフロー方式のサポートを要求するために、次のアノテーションを追加します。

      # ...
      metadata:
       annotations:
         features.operators.openshift.io/token-auth-aws: "true"

      Copy to Clipboard Toggle word wrap

2. Operator プロジェクトコードを更新します。

   1. Subscription オブジェクトによって Pod に設定された環境変数からロール ARN を取得します。以下に例を示します。

      // Get ENV var
      roleARN := os.Getenv("ROLEARN")
      setupLog.Info("getting role ARN", "role ARN = ", roleARN)
      webIdentityTokenPath := "/var/run/secrets/openshift/serviceaccount/token"

      Copy to Clipboard Toggle word wrap

   2. パッチを適用して適用できる CredentialsRequest オブジェクトがあることを確認してください。以下に例を示します。

      例3.2 CredentialsRequest オブジェクトの作成例

      import (
         minterv1 "github.com/openshift/cloud-credential-operator/pkg/apis/cloudcredential/v1"
         corev1 "k8s.io/api/core/v1"
         metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
      )
      
      var in = minterv1.AWSProviderSpec{
         StatementEntries: []minterv1.StatementEntry{
            {
               Action: []string{
                  "s3:*",
               },
               Effect:   "Allow",
               Resource: "arn:aws:s3:*:*:*",
            },
         },
      	STSIAMRoleARN: "<role_arn>",
      }
      
      var codec = minterv1.Codec
      var ProviderSpec, _ = codec.EncodeProviderSpec(in.DeepCopyObject())
      
      const (
         name      = "<credential_request_name>"
         namespace = "<namespace_name>"
      )
      
      var CredentialsRequestTemplate = &minterv1.CredentialsRequest{
         ObjectMeta: metav1.ObjectMeta{
             Name:      name,
             Namespace: "openshift-cloud-credential-operator",
         },
         Spec: minterv1.CredentialsRequestSpec{
            ProviderSpec: ProviderSpec,
            SecretRef: corev1.ObjectReference{
               Name:      "<secret_name>",
               Namespace: namespace,
            },
            ServiceAccountNames: []string{
               "<service_account_name>",
            },
            CloudTokenPath:   "",
         },
      }

      Copy to Clipboard Toggle word wrap

      あるいは、YAML 形式の CredentialsRequest オブジェクトから開始している場合 (たとえば、Operator プロジェクトコードの一部として)、別の方法で処理することもできます。

      例3.3 YAML フォームでの CredentialsRequest オブジェクト作成の例

      // CredentialsRequest is a struct that represents a request for credentials
      type CredentialsRequest struct {
        APIVersion string `yaml:"apiVersion"`
        Kind       string `yaml:"kind"`
        Metadata   struct {
           Name      string `yaml:"name"`
           Namespace string `yaml:"namespace"`
        } `yaml:"metadata"`
        Spec struct {
           SecretRef struct {
              Name      string `yaml:"name"`
              Namespace string `yaml:"namespace"`
           } `yaml:"secretRef"`
           ProviderSpec struct {
              APIVersion     string `yaml:"apiVersion"`
              Kind           string `yaml:"kind"`
              StatementEntries []struct {
                 Effect   string   `yaml:"effect"`
                 Action   []string `yaml:"action"`
                 Resource string   `yaml:"resource"`
              } `yaml:"statementEntries"`
              STSIAMRoleARN   string `yaml:"stsIAMRoleARN"`
           } `yaml:"providerSpec"`
      
           // added new field
            CloudTokenPath   string `yaml:"cloudTokenPath"`
        } `yaml:"spec"`
      }
      
      // ConsumeCredsRequestAddingTokenInfo is a function that takes a YAML filename and two strings as arguments
      // It unmarshals the YAML file to a CredentialsRequest object and adds the token information.
      func ConsumeCredsRequestAddingTokenInfo(fileName, tokenString, tokenPath string) (*CredentialsRequest, error) {
        // open a file containing YAML form of a CredentialsRequest
        file, err := os.Open(fileName)
        if err != nil {
           return nil, err
        }
        defer file.Close()
      
        // create a new CredentialsRequest object
        cr := &CredentialsRequest{}
      
        // decode the yaml file to the object
        decoder := yaml.NewDecoder(file)
        err = decoder.Decode(cr)
        if err != nil {
           return nil, err
        }
      
        // assign the string to the existing field in the object
        cr.Spec.CloudTokenPath = tokenPath
      
        // return the modified object
        return cr, nil
      }

      Copy to Clipboard Toggle word wrap
      注記

      CredentialsRequest オブジェクトを Operator バンドルに追加することは現在サポートされていません。

   3. ロール ARN と Web ID トークンパスを認証情報リクエストに追加し、Operator の初期化中に適用します。

      例3.4 Operator の初期化中に CredentialsRequest オブジェクトを適用する例

      // apply credentialsRequest on install
      credReq := credreq.CredentialsRequestTemplate
      credReq.Spec.CloudTokenPath = webIdentityTokenPath
      
      c := mgr.GetClient()
      if err := c.Create(context.TODO(), credReq); err != nil {
         if !errors.IsAlreadyExists(err) {
            setupLog.Error(err, "unable to create CredRequest")
            os.Exit(1)
         }
      }

      Copy to Clipboard Toggle word wrap

   4. 次の例に示すように、Operator が CCO から Secret オブジェクトが表示されるのを待機できるようにします。これは、Operator で調整している他の項目とともに呼び出されます。

      例3.5 Secret オブジェクトを待機する例

      // WaitForSecret is a function that takes a Kubernetes client, a namespace, and a v1 "k8s.io/api/core/v1" name as arguments
      // It waits until the secret object with the given name exists in the given namespace
      // It returns the secret object or an error if the timeout is exceeded
      func WaitForSecret(client kubernetes.Interface, namespace, name string) (*v1.Secret, error) {
        // set a timeout of 10 minutes
        timeout := time.After(10 * time.Minute) 

      1

      
      
        // set a polling interval of 10 seconds
        ticker := time.NewTicker(10 * time.Second)
      
        // loop until the timeout or the secret is found
        for {
           select {
           case <-timeout:
              // timeout is exceeded, return an error
              return nil, fmt.Errorf("timed out waiting for secret %s in namespace %s", name, namespace)
                 // add to this error with a pointer to instructions for following a manual path to a Secret that will work on STS
           case <-ticker.C:
              // polling interval is reached, try to get the secret
              secret, err := client.CoreV1().Secrets(namespace).Get(context.Background(), name, metav1.GetOptions{})
              if err != nil {
                 if errors.IsNotFound(err) {
                    // secret does not exist yet, continue waiting
                    continue
                 } else {
                    // some other error occurred, return it
                    return nil, err
                 }
              } else {
                 // secret is found, return it
                 return secret, nil
              }
           }
        }
      }

      Copy to Clipboard Toggle word wrap

      1

      timeout 値は、CCO が追加された CredentialsRequest オブジェクトを検出して Secret オブジェクトを生成する速度の推定に基づいています。Operator がまだクラウドリソースにアクセスしていない理由を疑問に思っているクラスター管理者のために、時間を短縮するか、カスタムフィードバックを作成することを検討してください。

   5. 認証情報リクエストから CCO によって作成されたシークレットを読み取り、そのシークレットのデータを含む AWS 設定ファイルを作成することで、AWS 設定をセットアップします。

      例3.6 AWS 設定の作成例

      func SharedCredentialsFileFromSecret(secret *corev1.Secret) (string, error) {
         var data []byte
         switch {
         case len(secret.Data["credentials"]) > 0:
             data = secret.Data["credentials"]
         default:
             return "", errors.New("invalid secret for aws credentials")
         }
      
      
         f, err := ioutil.TempFile("", "aws-shared-credentials")
         if err != nil {
             return "", errors.Wrap(err, "failed to create file for shared credentials")
         }
         defer f.Close()
         if _, err := f.Write(data); err != nil {
             return "", errors.Wrapf(err, "failed to write credentials to %s", f.Name())
         }
         return f.Name(), nil
      }

      Copy to Clipboard Toggle word wrap
      重要

      シークレットは存在すると想定されますが、このシークレットを使用する場合、CCO がシークレットを作成する時間を与えるために、Operator コードは待機して再試行する必要があります。

      さらに、待機期間は最終的にタイムアウトになり、OpenShift Container Platform クラスターのバージョン、つまり CCO が、STS 検出による CredentialsRequest オブジェクトのワークフローをサポートしていない以前のバージョンである可能性があることをユーザーに警告します。このような場合は、別の方法を使用してシークレットを追加する必要があることをユーザーに指示します。

   6. AWS SDK セッションを設定します。以下に例を示します。

      例3.7 AWS SDK セッション設定の例

      sharedCredentialsFile, err := SharedCredentialsFileFromSecret(secret)
      if err != nil {
         // handle error
      }
      options := session.Options{
         SharedConfigState: session.SharedConfigEnable,
         SharedConfigFiles: []string{sharedCredentialsFile},
      }

      Copy to Clipboard Toggle word wrap

手順

1. 管理クラスターの config map 内に MachineConfig オブジェクトを作成するには、次の情報を入力します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: <configmap_name>
     namespace: clusters
   data:
     config: |
       apiVersion: machineconfiguration.openshift.io/v1
       kind: MachineConfig
       metadata:
         labels:
           machineconfiguration.openshift.io/role: worker
         name: <machineconfig_name>
       spec:
         config:
           ignition:
             version: 3.2.0
           storage:
             files:
             - contents:
                 source: data:...
               mode: 420
               overwrite: true
               path: ${PATH} 

   1

   Copy to Clipboard Toggle word wrap

   1

   MachineConfig オブジェクトが保存されているノード上のパスを設定します。

2. オブジェクトを config map に追加した後、次のように config map をノードプールに適用できます。

   $ oc edit nodepool <nodepool_name> --namespace <hosted_cluster_namespace>

   Copy to Clipboard Toggle word wrap

   apiVersion: hypershift.openshift.io/v1alpha1
   kind: NodePool
   metadata:
   # ...
     name: nodepool-1
     namespace: clusters
   # ...
   spec:
     config:
     - name: <configmap_name> 

   1

   
   # ...

   Copy to Clipboard Toggle word wrap

   1

   <configmap_name> は、設定マップの名前に置き換えます。

手順

1. 次の情報を入力して、管理クラスターの config map 内に kubelet 設定を追加します。

   kubelet 設定を持つ ConfigMap オブジェクトの例

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: <configmap_name> 

   1

   
     namespace: clusters
   data:
     config: |
       apiVersion: machineconfiguration.openshift.io/v1
       kind: KubeletConfig
       metadata:
         name: <kubeletconfig_name> 

   2

   
       spec:
         kubeletConfig:
           registerWithTaints:
           - key: "example.sh/unregistered"
             value: "true"
             effect: "NoExecute"

   Copy to Clipboard Toggle word wrap

   1

   <configmap_name> は、設定マップの名前に置き換えます。

   2

   <kubeletconfig_name> は、KubeletConfig リソースの名前に置き換えます。

2. 次のコマンドを入力して、config map をノードプールに適用します。

   $ oc edit nodepool <nodepool_name> --namespace clusters 

   1

   Copy to Clipboard Toggle word wrap

   1

   <nodepool_name> をノードプールの名前に置き換えます。

   NodePool リソース設定の例

   apiVersion: hypershift.openshift.io/v1alpha1
   kind: NodePool
   metadata:
   # ...
     name: nodepool-1
     namespace: clusters
   # ...
   spec:
     config:
     - name: <configmap_name> 

   1

   
   # ...

   Copy to Clipboard Toggle word wrap

   1

   <configmap_name> は、設定マップの名前に置き換えます。

手順

1. チューニングされた有効なマニフェストを含む config map を作成し、ノードプールでマニフェストを参照します。次の例で Tuned マニフェストは、任意の値を持つ tuned-1-node-label ノードラベルを含むノード上で vm.dirty_ratio を 55 に設定するプロファイルを定義します。次の ConfigMap マニフェストを tuned-1.yaml という名前のファイルに保存します。

       apiVersion: v1
       kind: ConfigMap
       metadata:
         name: tuned-1
         namespace: clusters
       data:
         tuning: |
           apiVersion: tuned.openshift.io/v1
           kind: Tuned
           metadata:
             name: tuned-1
             namespace: openshift-cluster-node-tuning-operator
           spec:
             profile:
             - data: |
                 [main]
                 summary=Custom OpenShift profile
                 include=openshift-node
                 [sysctl]
                 vm.dirty_ratio="55"
               name: tuned-1-profile
             recommend:
             - priority: 20
               profile: tuned-1-profile

   Copy to Clipboard Toggle word wrap
   注記

   Tuned 仕様の spec.recommend セクションのエントリーにラベルを追加しない場合は、ノードプールベースのマッチングが想定されるため、spec.recommend セクションの最も優先度の高いプロファイルがプール内のノードに適用されます。Tuned .spec.recommend.match セクションでラベル値を設定することにより、よりきめ細かいノードラベルベースのマッチングを実現できますが、ノードプールの .spec.management.upgradeType 値を InPlace に設定しない限り、ノードラベルはアップグレード中に保持されません。

2. 管理クラスターに ConfigMap オブジェクトを作成します。

   $ oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-1.yaml

   Copy to Clipboard Toggle word wrap

3. ノードプールを編集するか作成して、ノードプールの spec.tuningConfig フィールドで ConfigMap オブジェクトを参照します。この例では、2 つのノードを含む nodepool-1 という名前の NodePool が 1 つだけあることを前提としています。

       apiVersion: hypershift.openshift.io/v1alpha1
       kind: NodePool
       metadata:
         ...
         name: nodepool-1
         namespace: clusters
       ...
       spec:
         ...
         tuningConfig:
         - name: tuned-1
       status:
       ...

   Copy to Clipboard Toggle word wrap
   注記

   複数のノードプールで同じ config map を参照できます。Hosted Control Plane では、Node Tuning Operator が Tuned CR の名前にノードプール名と namespace のハッシュを追加して、それらを区別します。この場合を除き、同じホステッドクラスターの異なる Tuned CR に、同じ名前の複数の TuneD プロファイルを作成しないでください。

1. ホステッドクラスター内の Tuned オブジェクトをリスト表示します。

   $ oc --kubeconfig="$HC_KUBECONFIG" get tuned.tuned.openshift.io -n openshift-cluster-node-tuning-operator

   Copy to Clipboard Toggle word wrap

   出力例

   NAME       AGE
   default    7m36s
   rendered   7m36s
   tuned-1    65s

   Copy to Clipboard Toggle word wrap

2. ホステッドクラスター内の Profile オブジェクトをリスト表示します。

   $ oc --kubeconfig="$HC_KUBECONFIG" get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator

   Copy to Clipboard Toggle word wrap

   出力例

   NAME                           TUNED            APPLIED   DEGRADED   AGE
   nodepool-1-worker-1            tuned-1-profile  True      False      7m43s
   nodepool-1-worker-2            tuned-1-profile  True      False      7m14s

   Copy to Clipboard Toggle word wrap

   注記

   カスタムプロファイルが作成されていない場合は、openshift-node プロファイルがデフォルトで適用されます。

3. チューニングが正しく適用されたことを確認するには、ノードでデバッグシェルを開始し、sysctl 値を確認します。

   $ oc --kubeconfig="$HC_KUBECONFIG" debug node/nodepool-1-worker-1 -- chroot /host sysctl vm.dirty_ratio

   Copy to Clipboard Toggle word wrap

   出力例

   vm.dirty_ratio = 55

   Copy to Clipboard Toggle word wrap

手順

1. namespace と Operator グループを作成します。

   apiVersion: v1
   kind: Namespace
   metadata:
     name: openshift-sriov-network-operator
   ---
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: sriov-network-operators
     namespace: openshift-sriov-network-operator
   spec:
     targetNamespaces:
     - openshift-sriov-network-operator

   Copy to Clipboard Toggle word wrap

2. SR-IOV Operator へのサブスクリプションを作成します。

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: sriov-network-operator-subsription
     namespace: openshift-sriov-network-operator
   spec:
     channel: stable
     name: sriov-network-operator
     config:
       nodeSelector:
         node-role.kubernetes.io/worker: ""
     source: redhat-operators
     sourceNamespace: openshift-marketplace

   Copy to Clipboard Toggle word wrap

検証

1. SR-IOV Operator の準備ができていることを確認するには、次のコマンドを実行し、結果の出力を表示します。

   $ oc get csv -n openshift-sriov-network-operator

   Copy to Clipboard Toggle word wrap

   出力例

   NAME                                         DISPLAY                   VERSION               REPLACES                                     PHASE
   sriov-network-operator.4.16.0-202211021237   SR-IOV Network Operator   4.16.0-202211021237   sriov-network-operator.4.16.0-202210290517   Succeeded

   Copy to Clipboard Toggle word wrap

2. SR-IOV Pod がデプロイされていることを確認するには、次のコマンドを実行します。

   $ oc get pods -n openshift-sriov-network-operator

   Copy to Clipboard Toggle word wrap

手順

1. chrony.conf ファイルの内容を含む Butane 設定ファイル 99-worker-chrony.bu を作成します。Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。

   99-worker-chrony.bu の設定例

   # ...
   variant: openshift
   version: 4.16.0
   metadata:
     name: 99-worker-chrony
     labels:
       machineconfiguration.openshift.io/role: worker
   storage:
     files:
     - path: /etc/chrony.conf
       mode: 0644  

   1

   
       overwrite: true
       contents:
         inline: |
           pool 0.rhel.pool.ntp.org iburst  

   2

   
           driftfile /var/lib/chrony/drift
           makestep 1.0 3
           rtcsync
           logdir /var/log/chrony
   # ...

   Copy to Clipboard Toggle word wrap

   1

   マシン設定ファイルの mode フィールドに 8 進数の値でモードを指定します。ファイルを作成して変更を適用すると、mode フィールドは 10 進数値に変換されます。

   2

   Dynamic Host Configuration Protocol (DHCP) サーバーが提供するタイムソースなど、有効で到達可能なタイムソースを指定します。

   注記

   マシン間通信の場合、User Datagram Protocol (UDP) ポート上の NTP は 123 です。外部 NTP タイムサーバーを設定した場合は、UDP ポート 123 を開く必要があります。

2. Butane を使用して、Butane がノードに送信する設定を含む MachineConfig オブジェクトファイル 99-worker-chrony.yaml を生成します。以下のコマンドを実行します。

   $ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml

   Copy to Clipboard Toggle word wrap

   99-worker-chrony.yaml の設定例

   # Generated by Butane; do not edit
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: <machineconfig_name>
   spec:
     config:
       ignition:
         version: 3.2.0
       storage:
         files:
           - contents:
               source: data:...
             mode: 420
             overwrite: true
             path: /example/path

   Copy to Clipboard Toggle word wrap

3. 管理クラスターの config map 内に 99-worker-chrony.yaml ファイルの内容を追加します。

   config map の例

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: <configmap_name>
     namespace: <namespace>  

   1

   
   data:
     config: |
       apiVersion: machineconfiguration.openshift.io/v1
       kind: MachineConfig
       metadata:
         labels:
           machineconfiguration.openshift.io/role: worker
         name: <machineconfig_name>
       spec:
         config:
           ignition:
             version: 3.2.0
           storage:
             files:
             - contents:
                 source: data:...
               mode: 420
               overwrite: true
               path: /example/path
   # ...

   Copy to Clipboard Toggle word wrap

   1

   <namespace> は、ノードプールを作成した namespace の名前 (clusters など) に置き換えます。

4. 次のコマンドを実行して、config map をノードプールに適用します。

   $ oc edit nodepool <nodepool_name> --namespace <hosted_cluster_namespace>

   Copy to Clipboard Toggle word wrap

   NodePool の設定例

   apiVersion: hypershift.openshift.io/v1alpha1
   kind: NodePool
   metadata:
   # ...
     name: nodepool-1
     namespace: clusters
   # ...
   spec:
     config:
     - name: <configmap_name> 

   1

   
   # ...

   Copy to Clipboard Toggle word wrap

   1

   <configmap_name> は、設定マップの名前に置き換えます。

5. InfraEnv カスタムリソース (CR) を定義する infra-env.yaml ファイルに NTP サーバーのリストを追加します。

   infra-env.yaml ファイルの例

   apiVersion: agent-install.openshift.io/v1beta1
   kind: InfraEnv
   # ...
   spec:
     additionalNTPSources:
     - <ntp_server> 

   1

   
     - <ntp_server1>
     - <ntp_server2>
   # ...

   Copy to Clipboard Toggle word wrap

   1

   <ntp_server> は、NTP サーバーの名前に置き換えます。ホストインベントリーと InfraEnv CR の作成の詳細は、「ホストインベントリーの作成」を参照してください。

6. 次のコマンドを実行して、InfraEnv CR を適用します。

   $ oc apply -f infra-env.yaml

   Copy to Clipboard Toggle word wrap

手順

1. 次のコマンドを実行して、ホスティングクラスターで HostedCluster CR を編集するために開きます。

   $ oc edit <hosted_cluster_name> -n <hosted_cluster_namespace>

   Copy to Clipboard Toggle word wrap

2. featureSet フィールドに値を入力して機能セットを定義します。以下に例を示します。

   apiVersion: hypershift.openshift.io/v1beta1
   kind: HostedCluster
   metadata:
     name: <hosted_cluster_name> 

   1

   
     namespace: <hosted_cluster_namespace> 

   2

   
   spec:
     configuration:
       featureGate:
         featureSet: TechPreviewNoUpgrade 

   3

   Copy to Clipboard Toggle word wrap

   1

   ホステッドクラスターの名前を指定します。

   2

   ホステッドクラスターの namespace を指定します。

   3

   この機能セットは、現在のテクノロジープレビュー機能のサブセットです。

   警告

   クラスターで TechPreviewNoUpgrade 機能セットを有効にすると、元に戻すことができず、マイナーバージョンの更新が妨げられます。この機能セットを使用すると、該当するテクノロジープレビュー機能をテストクラスターで有効にして、完全にテストすることができます。実稼働クラスターではこの機能セットを有効にしないでください。

3. 変更を適用するためにファイルを保存します。

手順

1. 次のコマンドを入力して、カスタム証明書でシークレットを作成します。

   $ oc create secret tls sample-hosted-kas-custom-cert \
     --cert=path/to/cert.crt \
     --key=path/to/key.key \
     -n <hosted_cluster_namespace>

   Copy to Clipboard Toggle word wrap

2. 以下の例のように、カスタム証明書の詳細を使用して HostedCluster 設定を更新します。

   spec:
     configuration:
       apiServer:
         servingCerts:
           namedCertificates:
           - names: 

   1

   
             - api-custom-cert-sample-hosted.sample-hosted.example.com
             servingCertificate: 

   2

   
               name: sample-hosted-kas-custom-cert

   Copy to Clipboard Toggle word wrap

   1

   証明書が有効な DNS 名のリスト。

   2

   カスタム証明書を含むシークレットの名前。

3. 次のコマンドを入力して、HostedCluster 設定に変更を適用します。

   $ oc apply -f <hosted_cluster_config>.yaml

   Copy to Clipboard Toggle word wrap

手順

1. プロバイダープラットフォームで、kubeAPIServerDNSName URL が Kubernetes API サーバーの公開先の IP アドレスを指すように DNS レコードを設定します。DNS レコードは、クラスターから適切に設定され、解決できる必要があります。

   DNS レコードを設定するコマンドの例

   $ dig + short kubeAPIServerDNSName

   Copy to Clipboard Toggle word wrap

2. 以下の例のように、HostedCluster 仕様で kubeAPIServerDNSName フィールドを変更します。

   apiVersion: hypershift.openshift.io/v1beta1
   kind: HostedCluster
   metadata:
     name: <hosted_cluster_name>
     namespace: <hosted_cluster_namespace>
   spec:
     configuration:
       apiServer:
         servingCerts:
           namedCertificates:
           - names: 

   1

   
             - api-custom-cert-sample-hosted.sample-hosted.example.com
             servingCertificate: 

   2

   
               name: sample-hosted-kas-custom-cert
     kubeAPIServerDNSName: api-custom-cert-sample-hosted.sample-hosted.example.com 

   3

   
   # ...

   Copy to Clipboard Toggle word wrap

   1

   証明書が有効な DNS 名のリスト。このフィールドにリストされている名前は、spec.servicePublishingStrategy.*hostname フィールドに指定された名前と同じにすることはできません。

   2

   カスタム証明書を含むシークレットの名前。

   3

   このフィールドは、API サーバーエンドポイントとして使用される URI を受け入れます。

3. 次のコマンドを入力して設定を適用します。

   $ oc -f <hosted_cluster_spec>.yaml

   Copy to Clipboard Toggle word wrap

   設定が適用されると、HyperShift Operator はカスタム DNS ドメインを参照する新しい kubeconfig シークレットを生成します。

4. CLI またはコンソールを使用して kubeconfig シークレットを取得します。

   1. CLI を使用してシークレットを取得するには、以下のコマンドを入力します。

      $ kubectl get secret <hosted_cluster_name>-custom-admin-kubeconfig \
        -n <cluster_namespace> \
        -o jsonpath='{.data.kubeconfig}' | base64 -d

      Copy to Clipboard Toggle word wrap

   2. コンソールを使用してシークレットを取得するには、ホストされたクラスターに移動し、Download Kubeconfig をクリックします。

      注記

      コンソールで show login コマンド オプションを使用して、新しい kubeconfig シークレットを使用することはできません。

手順

1. DNS レコードが正しく設定され、解決されていることを確認します。

2. 次のコマンドを入力して、カスタムドメインの TLS 証明書が有効で、SAN がドメインに対して正しいことを確認します。

   $ oc get secret \
     -n clusters <serving_certificate_name> \
     -o jsonpath='{.data.tls\.crt}' | base64 \
     -d |openssl x509 -text -noout -

   Copy to Clipboard Toggle word wrap
3. カスタムドメインへのネットワーク接続が機能していることを確認します。

4. HostedCluster リソースで、次の例に示すように、ステータスに適切なカスタム kubeconfig 情報が表示されることを確認します。

   HostedCluster ステータスの例

   status:
     customKubeconfig:
       name: sample-hosted-custom-admin-kubeconfig

   Copy to Clipboard Toggle word wrap

5. 次のコマンドを入力して、HostedControlPlane namespace で kube-apiserver ログを確認します。

   $ oc logs -n <hosted_control_plane_namespace> \
     -l app=kube-apiserver -f -c kube-apiserver

   Copy to Clipboard Toggle word wrap

1. OpenShift Container Platform クラスターを最新バージョンにアップグレードします。詳細は、「Web コンソールを使用してクラスターを更新」または「CLI を使用したクラスターの更新」を参照してください。
2. multicluster engine Operator を最新バージョンにアップグレードします。詳細は、「インストールされている Operator の更新」を参照してください。
3. ホステッドクラスターとノードプールを以前の OpenShift Container Platform バージョンから最新バージョンにアップグレードします。詳細は、「ホステッドクラスターのコントロールプレーンの更新」および「ホステッドクラスターのノードプールの更新」を参照してください。

手順

1. 次のコマンドを実行して、ホステッドクラスターに hypershift.openshift.io/force-upgrade-to=<openshift_release_image> アノテーションを追加します。

   $ oc annotate hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> "hypershift.openshift.io/force-upgrade-to=<openshift_release_image>" --overwrite 

   1

   2

   Copy to Clipboard Toggle word wrap

   1

   <hosted_cluster_name> と <hosted_cluster_namespace> を、それぞれホステッドクラスター名とホステッドクラスター namespace に置き換えます。

   2

   <openshift_release_image> 変数は、アップグレードする新しい OpenShift Container Platform リリースイメージを指定します (例: quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64)。<4.y.z> をサポートされている OpenShift Container Platform バージョンに置き換えます。

2. 次のコマンドを実行して、ホステッドクラスターの spec.release.image 値を変更します。

   $ oc patch hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace> --type=merge -p '{"spec":{"release":{"image":"<openshift_release_image>"}}}'

   Copy to Clipboard Toggle word wrap

手順

1. All clusters を選択します。
2. Infrastructure → Clusters に移動して、管理対象のホステッドクラスターを表示します。
3. Upgrade available リンクをクリックして、コントロールプレーンとノードプールを更新します。

手順

1. local-cluster namespace に、hypershift-operator-install-flags config map を作成します。次の設定例を参照してください。

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: hypershift-operator-install-flags
     namespace: local-cluster
   data:
     installFlagsToAdd: "--monitoring-dashboards --metrics-set=All" 

   1

   
     installFlagsToRemove: ""

   Copy to Clipboard Toggle word wrap

   1

   --monitoring-dashboards --metrics-set=All フラグは、すべてのメトリクスのモニタリングダッシュボードを追加します。

2. hypershift namespace の HyperShift Operator デプロイメントが更新され、次の環境変数が含まれるまで数分待ちます。

       - name: MONITORING_DASHBOARDS
         value: "1"

   Copy to Clipboard Toggle word wrap

   モニタリングダッシュボードが有効になっている場合、HyperShift Operator が管理するホステッドクラスターごとに、HyperShift Operator が openshift-config-managed namespace に cp-<hosted_cluster_namespace>-<hosted_cluster_name> という名前の config map を作成します。<hosted_cluster_namespace> はホステッドクラスターの namespace、<hosted_cluster_name> はホステッドクラスターの名前です。その結果、管理クラスターの管理コンソールに新しいダッシュボードが追加されます。

3. ダッシュボードを表示するには、管理クラスターのコンソールにログインし、Observe → Dashboards をクリックして、ホステッドクラスターのダッシュボードに移動します。
4. オプション: ホステッドクラスターのモニタリングダッシュボードを無効にするには、hypershift-operator-install-flags config map から --monitoring-dashboards --metrics-set=All フラグを削除します。ホステッドクラスターを削除すると、対応するダッシュボードも削除されます。