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

5.4. 非ベアメタルエージェントマシンでの Hosted Control Plane の管理

非ベアメタルエージェントマシンに Hosted Control Plane をデプロイした後、次のタスクを完了してホステッドクラスターを管理できます。

5.4.1. ホステッドクラスターへのアクセス

ホステッドクラスターにアクセスするには、kubeconfig ファイルと kubeadmin 認証情報をリソースから直接取得するか、hcp コマンドラインインターフェイスを使用して kubeconfig ファイルを生成します。

前提条件

リソースから kubeconfig ファイルと認証情報を直接取得し、ホステッドクラスターにアクセスするには、ホステッドクラスターのアクセスシークレットを理解している必要があります。ホステッドクラスター (ホスティング) のリソースとアクセスシークレットは、ホステッドクラスターの namespace に格納されます。Hosted Control Plane は、Hosted Control Plane の namespace で実行されます。

シークレット名の形式は次のとおりです。

  • kubeconfig シークレット: <hosted_cluster_namespace>-<name>-admin-kubeconfig.たとえば、clusters-hypershift-demo-admin-kubeconfig です。
  • kubeadmin パスワードシークレット: <hosted_cluster_namespace>-<name>-kubeadmin-password.たとえば、clusters-hypershift-demo-kubeadmin-password です。

kubeconfig シークレットには Base64 でエンコードされた kubeconfig フィールドが含まれており、これをデコードしてファイルに保存し、次のコマンドで使用できます。 

$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes

kubeadmin パスワードシークレットも Base64 でエンコードされます。これをデコードし、そのパスワードを使用して、ホステッドクラスターの API サーバーまたはコンソールにログインできます。

手順

  • hcp CLI を使用してホステッドクラスターにアクセスして kubeconfig ファイルを生成するには、次の手順を実行します。

    1. 次のコマンドを入力して、kubeconfig ファイルを生成します。 

      $ hcp create kubeconfig --namespace <hosted_cluster_namespace> --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig

    2. kubeconfig ファイルを保存した後、次のコマンド例を入力して、ホステッドクラスターにアクセスできます。 

      $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes

5.4.2. ホステッドクラスターの NodePool オブジェクトのスケーリング

ホステッドクラスターにノードを追加することで、NodePool オブジェクトをスケールアップできます。ノードプールをスケーリングする際には、次の情報を考慮してください。

  • ノードプールによってレプリカをスケーリングすると、マシンが作成されます。クラスター API プロバイダーは、すべてのマシンに対して、ノードプール仕様で指定された要件を満たすエージェントを見つけてインストールします。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。
  • ノードプールをスケールダウンすると、エージェントは対応するクラスターからバインド解除されます。Agent を再利用するには、Discovery イメージを使用してエージェントを再起動する必要があります。

手順

  1. NodePool オブジェクトを 2 つのノードにスケーリングします。 

    $ oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> --replicas 2

    Cluster API エージェントプロバイダーは、ホステッドクラスターに割り当てられる 2 つのエージェントをランダムに選択します。これらのエージェントはさまざまな状態を経て、最終的に OpenShift Container Platform ノードとしてホステッドクラスターに参加します。エージェントは次の順序で状態を通過します。

    • binding
    • discovering
    • insufficient
    • installing
    • installing-in-progress
    • added-to-existing-cluster

  2. 以下のコマンドを入力します。 

    $ oc -n <hosted_control_plane_namespace> get agent

    出力例

    NAME                                   CLUSTER         APPROVED   ROLE          STAGE
4dac1ab2-7dd5-4894-a220-6a3473b67ee6   hypercluster1   true       auto-assign
d9198891-39f4-4930-a679-65fb142b108b                   true       auto-assign
da503cf1-a347-44f2-875c-4960ddb04091   hypercluster1   true       auto-assign

  3. 以下のコマンドを入力します。 

    $ oc -n <hosted_control_plane_namespace> get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'

    出力例

    BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding
BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound
BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient

  4. 次の extract コマンドを入力して、新しいホステッドクラスターの kubeconfig を取得します。 

    $ oc extract -n <hosted_cluster_namespace> secret/<hosted_cluster_name>-admin-kubeconfig --to=- > kubeconfig-<hosted_cluster_name>

  5. エージェントが added-to-existing-cluster 状態に達したら、次のコマンドを入力して、ホステッドクラスターの OpenShift Container Platform ノードが表示されることを確認します。 

    $ oc --kubeconfig kubeconfig-<hosted_cluster_name> get nodes

    出力例

    NAME           STATUS   ROLES    AGE     VERSION
ocp-worker-1   Ready    worker   5m41s   v1.24.0+3882f8f
ocp-worker-2   Ready    worker   6m3s    v1.24.0+3882f8f

    Cluster Operator は、ワークロードをノードに追加することによって調整を開始します。

  6. 次のコマンドを入力して、NodePool オブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。 

    $ oc -n <hosted_control_plane_namespace> get machines

    出力例

    NAME                            CLUSTER               NODENAME       PROVIDERID                                     PHASE     AGE   VERSION
hypercluster1-c96b6f675-m5vch   hypercluster1-b2qhl   ocp-worker-1   agent://da503cf1-a347-44f2-875c-4960ddb04091   Running   15m   4.x.z
hypercluster1-c96b6f675-tl42p   hypercluster1-b2qhl   ocp-worker-2   agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6   Running   15m   4.x.z

    clusterversion 調整プロセスは最終的に、Ingress および Console クラスター Operator のみが欠落しているポイントに到達します。

  7. 以下のコマンドを入力します。 

    $ oc --kubeconfig kubeconfig-<hosted_cluster_name> get clusterversion,co

    出力例

    NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version             False       True          40m     Unable to apply 4.x.z: the cluster operator console has not yet successfully rolled out

NAME                                                                             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                      4.12z     False       False         False      11m     RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.hypercluster1.domain.com): Get "https://console-openshift-console.apps.hypercluster1.domain.com": dial tcp 10.19.3.29:443: connect: connection refused
clusteroperator.config.openshift.io/csi-snapshot-controller                      4.12z     True        False         False      10m
clusteroperator.config.openshift.io/dns                                          4.12z     True        False         False      9m16s

5.4.2.1. ノードプールの追加

名前、レプリカの数、およびエージェントラベルセレクターなどの追加情報を指定して、ホステッドクラスターのノードプールを作成できます。

手順

  1. ノードプールを作成するには、次の情報を入力します。 

    $ hcp create nodepool agent \
  --cluster-name <hosted_cluster_name> \1
  --name <nodepool_name> \2
  --node-count <worker_node_count> \3
  --agentLabelSelector size=medium 4
    1
    <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。
    2
    <nodepool_name> は、ノードプールの名前に置き換えます (例: <hosted_cluster_name>-extra-cpu)。
    3
    <worker_node_count> は、ワーカーノード数 (例: 2) に置き換えます。
    4
    --agentLabelSelector フラグは任意です。ノードプールは、size=medium ラベルを持つエージェントを使用します。

  2. clusters namespace 内の nodepool リソースをリスト表示して、ノードプールのステータスを確認します。 

    $ oc get nodepools --namespace clusters

  3. 次のコマンドを入力して、admin-kubeconfig シークレットを抽出します。 

    $ oc extract -n <hosted_control_plane_namespace> secret/admin-kubeconfig --to=./hostedcluster-secrets --confirm

    出力例

    hostedcluster-secrets/kubeconfig

  4. しばらくしてから、次のコマンドを入力してノードプールのステータスを確認できます。 

    $ oc --kubeconfig ./hostedcluster-secrets get nodes

検証

  • 次のコマンドを入力して、使用可能なノードプールの数が予想されるノードプールの数と一致することを確認します。 

    $ oc get nodepools --namespace clusters

5.4.2.2. ホステッドクラスターのノード自動スケーリングの有効化

ホステッドクラスターにさらに容量が必要で、予備のエージェントが利用可能な場合は、自動スケーリングを有効にして新しいワーカーノードをインストールできます。

手順

  1. 自動スケーリングを有効にするには、次のコマンドを入力します。 

    $ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> --type=json -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'
    注記

    この例では、ノードの最小数は 2、最大数は 5 です。追加できるノードの最大数は、プラットフォームによって制限される場合があります。たとえば、エージェントプラットフォームを使用する場合、ノードの最大数は使用可能なエージェントの数によって制限されます。

  2. 新しいノードを必要とするワークロードを作成します。

    1. 次の例を使用して、ワークロード設定を含む YAML ファイルを作成します。 

      apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: reversewords
  name: reversewords
  namespace: default
spec:
  replicas: 40
  selector:
    matchLabels:
      app: reversewords
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: reversewords
    spec:
      containers:
      - image: quay.io/mavazque/reversewords:latest
        name: reversewords
        resources:
          requests:
            memory: 2Gi
status: {}
    2. ファイルを workload-config.yaml として保存します。

    3. 以下のコマンドを入力して、YAML を適用します。 

      $ oc apply -f workload-config.yaml

  3. 次のコマンドを入力して、admin-kubeconfig シークレットを抽出します。 

    $ oc extract -n <hosted_cluster_namespace> secret/<hosted_cluster_name>-admin-kubeconfig --to=./hostedcluster-secrets --confirm

    出力例

    hostedcluster-secrets/kubeconfig

  4. 次のコマンドを入力して、新しいノードが Ready ステータスであるかどうかを確認できます。 

    $ oc --kubeconfig ./hostedcluster-secrets get nodes

  5. ノードを削除するには、次のコマンドを入力してワークロードを削除します。 

    $ oc --kubeconfig ./hostedcluster-secrets -n <namespace> delete deployment <deployment_name>

  6. 数分間待ちます。その間に、容量の追加が必要にならないようにします。エージェントプラットフォームでは、エージェントは廃止され、再利用できます。次のコマンドを入力すると、ノードが削除されたことを確認できます。 

    $ oc --kubeconfig ./hostedcluster-secrets get nodes
注記

IBM Z エージェントの場合、コンピュートノードがクラスターからデタッチされるのは、KVM エージェントを使用する IBM Z の場合だけです。z/VM および LPAR の場合は、コンピュートノードを手動で削除する必要があります。

エージェントは、KVM を使用する IBM Z でのみ再利用できます。z/VM および LPAR の場合は、エージェントを再作成して、それらをコンピュートノードとして使用してください。

5.4.2.3. ホストされたクラスターのノードの自動スケーリングを無効にする

ノードの自動スケーリングを無効にするには、次の手順を実行します。

手順

  • ホステッドクラスターのノードの自動スケーリングを無効にするには、次のコマンドを入力します。 

    $ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> --type=json -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": <specify_value_to_scale_replicas>]'

    このコマンドは、YAML ファイルから "spec.autoScaling" を削除し、"spec.replicas" を追加し、"spec.replicas" を指定の整数値に設定します。

関連情報

5.4.3. 非ベアメタルエージェントマシン上のホステッドクラスターでの Ingress の処理

すべての OpenShift Container Platform クラスターには、通常、外部 DNS レコードが関連付けられているデフォルトのアプリケーション Ingress コントローラーがあります。たとえば、ベースドメイン krnl.es で example という名前のホストされたクラスターを作成する場合は、ワイルドカードドメイン *.apps.example.krnl.es がルーティング可能であると予想することができます。

手順

*.apps ドメインのロードバランサーとワイルドカード DNS レコードを設定するには、ゲストクラスターで次のアクションを実行します。

  1. MetalLB Operator の設定を含む YAML ファイルを作成して MetalLB をデプロイします。 

    apiVersion: v1
kind: Namespace
metadata:
  name: metallb
  labels:
    openshift.io/cluster-monitoring: "true"
  annotations:
    workload.openshift.io/allowed: management
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: metallb-operator-operatorgroup
  namespace: metallb
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: metallb-operator
  namespace: metallb
spec:
  channel: "stable"
  name: metallb-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  2. ファイルを metallb-operator-config.yaml として保存します。

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

    $ oc apply -f metallb-operator-config.yaml

  4. Operator の実行後、MetalLB インスタンスを作成します。

    1. MetalLB インスタンスの設定を含む YAML ファイルを作成します。 

      apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb
    2. ファイルを metallb-instance-config.yaml として保存します。

    3. 次のコマンドを入力して、MetalLB インスタンスを作成します。 

      $ oc apply -f metallb-instance-config.yaml

  5. 単一の IP アドレスを含む IPAddressPool リソースを作成します。この IP アドレスは、クラスターノードが使用するネットワークと同じサブネット上にある必要があります。

    1. 以下の例のような内容で、ipaddresspool.yaml などのファイルを作成します。 

      apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  namespace: metallb
  name: <ip_address_pool_name> 1
spec:
  addresses:
    - <ingress_ip>-<ingress_ip> 2
  autoAssign: false
      1
      IPAddressPool リソース名を指定します。
      2
      環境の IP アドレスを指定します。たとえば、192.168.122.23 です。

    2. 次のコマンドを入力して、IP アドレスプールの設定を適用します。 

      $ oc apply -f ipaddresspool.yaml

  6. L2 アドバタイズメントを作成します。

    1. 以下の例のような内容で、l2advertisement.yaml などのファイルを作成します。 

      apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: <l2_advertisement_name> 1
  namespace: metallb
spec:
  ipAddressPools:
   - <ip_address_pool_name> 2
      1
      L2Advertisement リソース名を指定します。
      2
      IPAddressPool リソース名を指定します。

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

      $ oc apply -f l2advertisement.yaml

  7. LoadBalancer タイプのサービスを作成すると、MetalLB はサービスに外部 IP アドレスを追加します。

    1. metallb-loadbalancer-service.yaml という名前の YAML ファイルを作成して、Ingress トラフィックを Ingress デプロイメントにルーティングする新しいロードバランサーサービスを設定します。 

      kind: Service
apiVersion: v1
metadata:
  annotations:
    metallb.universe.tf/address-pool: ingress-public-ip
  name: metallb-ingress
  namespace: openshift-ingress
spec:
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
    - name: https
      protocol: TCP
      port: 443
      targetPort: 443
  selector:
    ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
  type: LoadBalancer
    2. metallb-loadbalancer-service.yaml ファイルを保存します。

    3. YAML 設定を適用するには、次のコマンドを入力します。 

      $ oc apply -f metallb-loadbalancer-service.yaml

    4. 次のコマンドを入力して、OpenShift Container Platform コンソールにアクセスします。 

      $ curl -kI https://console-openshift-console.apps.example.krnl.es

      出力例

      HTTP/1.1 200 OK

    5. clusterversion と clusteroperator の値をチェックして、すべてが実行されていることを確認します。以下のコマンドを入力します。 

      $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co

      出力例

      NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.x.y      True        False        3m32s   Cluster version is 4.x.y

NAME                                                                             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                      4.x.y     True        False         False      3m50s
clusteroperator.config.openshift.io/ingress                                      4.x.y     True        False         False      53m

      <4.x.y> は、使用するサポート対象の OpenShift Container Platform バージョン (例: 4.17.0-multi) に置き換えます。

関連情報

5.4.4. 非ベアメタルエージェントマシンでマシンのヘルスチェックを有効にする

ベアメタル上でマシンのヘルスチェックを有効にして、異常なマネージドクラスターノードを自動的に修復および置き換えることができます。マネージドクラスターにインストールする準備ができている追加のエージェントマシンが必要です。

マシンのヘルスチェックを有効にする前に、次の制限を考慮してください。

  • MachineHealthCheck オブジェクトを変更することはできません。
  • マシンヘルスチェックでは、少なくとも 2 つのノードが 8 分以上 False または Unknown ステータスのままである場合にのみ、ノードが置き換えられます。

マネージドクラスターノードのマシンヘルスチェックを有効にすると、ホストされたクラスターに MachineHealthCheck オブジェクトが作成されます。

手順

ホストされたクラスターでマシンのヘルスチェックを有効にするには、NodePool リソースを変更します。以下の手順を実行します。

  1. NodePool リソースの spec.nodeDrainTimeout 値が 0s より大きいことを確認します。<hosted_cluster_namespace> をホストされたクラスター namespace の名前に置き換え、<nodepool_name> をノードプール名に置き換えます。以下のコマンドを実行します。 

    $ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep nodeDrainTimeout

    出力例

    nodeDrainTimeout: 30s

  2. spec.nodeDrainTimeout 値が 0s より大きくない場合は、次のコマンドを実行して値を変更します。 

    $ oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec":{"nodeDrainTimeout": "30m"}}' --type=merge

  3. NodePool リソースで spec.management.autoRepair フィールドを true に設定して、マシンのヘルスチェックを有効にします。以下のコマンドを実行します。 

    $ oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec": {"management": {"autoRepair":true}}}' --type=merge

  4. 次のコマンドを実行して、NodePool リソースが autoRepair: true 値で更新されていることを確認します。 

    $ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep autoRepair

5.4.5. 非ベアメタルエージェントマシンでマシンヘルスチェックを無効にする

マネージドクラスターノードのマシンのヘルスチェックを無効にするには、NodePool リソースを変更します。

手順

  1. NodePool リソースで spec.management.autoRepair フィールドを false に設定して、マシンのヘルスチェックを無効にします。以下のコマンドを実行します。 

    $ oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec": {"management": {"autoRepair":false}}}' --type=merge

  2. 次のコマンドを実行して、NodePool リソースが autoRepair: false 値で更新されていることを確認します。 

    $ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep autoRepair

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.