この文書は自動機械翻訳技術を使用して翻訳されています。正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。相違がある場合は、元の英語版英語が優先され、正式なテキストとなります。

既存のクラスターの登録

クラスター登録機能は、クラスターをインポートする機能に置き換えられました。

Rancherが登録されたクラスターを管理するための制御は、クラスターの種類によって異なります。詳細については、登録クラスターの管理機能をご覧ください。

前提条件

Kubernetesノードロール

登録されたRKE Kubernetesクラスターは、etcd、controlplane、workerの3つのノードロールをすべて持っている必要があります。controlplaneコンポーネントのみを持つクラスターは、Rancherに登録することはできません。

RKEノードロールに関する詳細は、ベストプラクティスをご覧ください。

権限

Rancherにクラスターを登録するには、そのクラスター内で`cluster-admin`の権限を持っている必要があります。持っていない場合は、次のコマンドを実行してユーザーにこれらの権限を付与してください：

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole cluster-admin \
  --user [USER_ACCOUNT]

デフォルトでは、Google Kubernetes Engine (GKE)は`cluster-admin`ロールを付与しないため、これらのコマンドをGKEクラスターで実行する必要があります。GKEのロールベースのアクセス制御について詳しくは、公式のGoogleドキュメントをご覧ください。

Elastic Kubernetes Service (EKS)、Azure Kubernetes Service (AKS)、およびGoogle Kubernetes Engine (GKE)

RancherからEKS、AKS、GKEクラスターを正常にインポートまたはプロビジョニングするには、クラスターに少なくとも1つの管理ノードグループが必要です。

AKSクラスターは、ローカルアカウントが有効になっている場合にのみインポートできます。クラスターが認証にMicrosoft Entra IDを使用するように構成されている場合、Rancherはそれをインポートできず、エラーを報告します。

EKS Anywhereクラスターは、APIアドレスと資格情報を使用してRancherにインポート/登録できます。これは、他のダウンストリームクラスターと同様です。EKS Anywhereクラスターはインポートされたクラスターとして扱われ、Rancherからの完全なライフサイクルサポートはありません。

GKE Autopilotクラスターはサポートされていません。GKEモードの違いについての詳細は、 GKE AutopilotとStandardの比較をご覧ください。を参照してください。

クラスターの登録

*☰ > クラスター管理*をクリックします。
*クラスター*ページで、*既存クラスターのインポート*を選択します。
クラスターのタイプを選択します。
クラスターのユーザー認可を構成するには、*メンバー役割*を使用してください。*メンバーを追加*をクリックして、クラスターにアクセスできるユーザーを追加してください。各ユーザーの権限を設定するには、*役割*のドロップダウンを使用してください。
Rancherで一般的なKubernetesクラスターをインポートする場合は、次の手順を実行してセットアップします：
1. エージェント環境変数をクラスターオプションの下でクリックして、rancherクラスタエージェントの環境変数を設定します。環境変数はキーと値のペアを使用して設定できます。Rancherサーバーと通信するためにrancherエージェントがプロキシの使用を必要とする場合、HTTP_PROXY、`HTTPS_PROXY`および`NO_PROXY`の環境変数はエージェント環境変数を使用して設定できます。
2. プロジェクトネットワークの分離を有効にして、クラスターがKubernetes `NetworkPolicy`リソースをサポートすることを確認します。ユーザーは、高度なオプションのドロップダウンの下にあるプロジェクトネットワークの分離オプションを選択できます。
3. インポートされたRKE2およびK3sクラスターのバージョン管理機能を構成する。
［作成］をクリックします。
`cluster-admin`権限の前提条件が表示されます（上記の*前提条件*を参照）、前提条件を満たすための例のコマンドが含まれています。
`kubectl`コマンドをクリップボードにコピーし、kubeconfigがインポートしたいクラスターを指すように設定されているノードで実行します。正しく設定されているか不明な場合は、Rancherに表示されているコマンドを実行する前に`kubectl get nodes`を実行して確認します。
自己署名証明書を使用している場合、`certificate signed by unknown authority`というメッセージが表示されます。この検証を回避するには、Rancherに表示される`curl`で始まるコマンドをクリップボードにコピーします。次に、kubeconfigがインポートしたいクラスターを指すように設定されているノードでコマンドを実行します。
ノードでコマンドの実行が完了したら、*完了*をクリックします。

`NO_PROXY`環境変数は標準化されておらず、値の受け入れられる形式はアプリケーションによって異なる場合があります。Rancherの`NO_PROXY`変数を構成する際、値はGolangが期待する形式に従う必要があります。

具体的には、値はIPアドレス、CIDR表記、ドメイン名、または特別なDNSラベル（例：*）のみを含むカンマ区切りの文字列である必要があります。期待される値の形式の完全な説明については、 上流のGolangドキュメントを参照してください。

結果:

クラスターは登録され、*保留中*の状態が割り当てられています。Rancherは、クラスターを管理するためのリソースをデプロイしています。
状態が*アクティブ*に更新された後、クラスターにアクセスできます。
*アクティブ*なクラスターには、Default（ネームスペース`default`を含む）と`System`（ネームスペース`cattle-system`、traefik、kube-public、および`kube-system`を含む場合）という2つのプロジェクトが割り当てられています。

現在Rancherのセットアップでアクティブなクラスターを再登録することはできません。

Terraformを使用してインポートされたEKS、AKS、またはGKEクラスターを設定する

Terraformを使用してEKS、AKS、またはGKEクラスターをインポートする際には、Rancherが要求する最小限のフィールドを*のみ*定義する必要があります。これは重要です。なぜなら、Rancherはユーザーが提供した設定でクラスター構成にあったものを上書きするからです。

現在のクラスターとユーザーが提供した設定との間に小さな違いがあるだけでも、予期しない結果をもたらす可能性があります。

Terraformを使用してEKSクラスターをインポートするためにRancherが必要とする最小限の構成フィールドは`eks_config_v2`次のとおりです：

cloud_credential_id
name
地域
インポートされた（このフィールドはインポートされたクラスターに対して常に`true`に設定する必要があります）

インポートされたEKSクラスターの例YAML設定：

resource "rancher2_cluster" "my-eks-to-import" {
  name        = "my-eks-to-import"
  description = "Terraform EKS Cluster"
  eks_config_v2 {
    cloud_credential_id = rancher2_cloud_credential.aws.id
    name                = var.aws_eks_name
    region              = var.aws_region
    imported            = true
  }
}

他のクラウドプロバイダーの追加の例は、 Rancher2 Terraform Providerドキュメントで見つけることができます。

登録されたクラスターの管理機能

Rancherが登録されたクラスターを管理する方法は、クラスターの種類によって異なります。

すべての登録されたクラスターの機能
登録されたRKE2およびK3sクラスターの追加機能
登録されたEKS、AKS、およびGKEクラスターの追加機能

すべての登録済みクラスターの機能

クラスターを登録した後、クラスターの所有者は次のことができます：

ロールベースのアクセス制御を通じてクラスターへのアクセスを管理する
監視、アラート、通知機能を有効にする
ログ記録を有効にする
Istioを有効にする
プロジェクトとワークロードを管理する

登録済みSUSE® Rancher Prime: RKE2およびSUSE® Rancher Prime: K3sクラスターの追加機能

K3sは、エッジインストール用の軽量で完全に準拠したKubernetesディストリビューションです。

RKE2は、データセンターおよびクラウドインストール用のRancherの次世代Kubernetesディストリビューションです。

RancherにRKE2またはK3sクラスターが登録されると、Rancherはそれを認識します。 RancherのUIは、すべての登録済みクラスターに利用可能な機能を表示し、クラスターの編集およびアップグレードのための次のオプションを提供します：

バージョン管理を有効または無効にする
Kubernetesのバージョンをアップグレードする（バージョン管理が有効な場合）
バージョン管理が有効な場合、アップグレード戦略を設定する
クラスターの設定引数と各ノードを起動するために使用される環境変数の読み取り専用バージョンを表示する

登録済みEKS、AKS、GKEクラスターの追加機能

Rancherは、登録済みEKS、AKS、またはGKEクラスターをRancherで作成されたクラスターと同様に扱います。ただし、RancherはRancherのUIを通じて削除した場合、登録済みクラスターを破棄しません。

EKS、AKS、またはGKEクラスターをRancherで作成し、その後削除すると、Rancherはクラスターを破棄します。Rancherを通じて登録されたクラスターを削除すると、Rancherサーバーはクラスターから_切断します_。クラスターは生き続けますが、Rancherにはもはや存在しません。登録解除されたクラスターには、登録する前と同じ方法でアクセスできます。

登録されたクラスターの管理に利用可能な機能についての詳細は、クラスタータイプ別のクラスター管理機能を参照してください。

SUSE® Rancher Prime: RKE2およびSUSE® Rancher Prime: K3sクラスターのバージョン管理の設定

インポートされたクラスターに対してバージョン管理が有効になっている場合、Rancherの外でアップグレードすると予期しない結果を招く可能性があります。

インポートされたRKE2およびK3sクラスターのバージョン管理機能は、次のオプションのいずれかを使用して設定できます：

グローバルデフォルト（既定）：グローバルインポートされたクラスターのバージョン管理設定から動作を継承します。
真：バージョン管理を有効にし、ユーザーがRancherを通じてクラスターのKubernetesバージョンとアップグレード戦略を制御できるようにします。
偽：バージョン管理を無効にし、ユーザーがRancherの外でクラスターのKubernetesバージョンを独立して管理できるようにします。

新しく作成されたクラスターや「グローバルデフォルト」に設定された既存のクラスターのデフォルト動作を、imported-cluster-version-management設定を変更することで定義できます。

グローバルimported-cluster-version-management設定の変更は、クラスターの次の調整サイクル中に適用されます。

クラスターに対してバージョン管理が有効になっている場合、Rancherは`system-upgrade-controller`アプリと関連するプランおよびその他の必要なKubernetesリソースをクラスターにデプロイします。バージョン管理が無効になっている場合、Rancherはこれらのコンポーネントをクラスターから削除します。

SUSE® Rancher Prime: RKE2およびSUSE® Rancher Prime: K3sクラスターのアップグレードの設定

アップグレードの前にクラスターをバックアップすることはKubernetesのベストプラクティスです。外部データベースを使用した高可用性のK3sクラスターをアップグレードする際は、リレーショナルデータベースプロバイダーが推奨する方法でデータベースをバックアップしてください。

*同時実行数*は、アップグレード中に利用できないことが許可されている最大ノード数です。利用できないノードの数が*同時実行数*よりも大きい場合、アップグレードは失敗します。アップグレードが失敗した場合、アップグレードが成功する前に失敗したノードを修復または削除する必要があります。

*コントロールプレーンの同時実行数:*一度にアップグレードする最大サーバーノード数; また、最大の利用できないサーバーノード数
*ワーカーの同時実行数:*同時にアップグレードする最大ワーカーノード数; また、最大の利用できないワーカーノード数

RKE2およびK3sのドキュメントでは、コントロールプレーンノードはサーバーノードと呼ばれています。これらのノードはKubernetesマスターを実行し、クラスターの望ましい状態を維持します。デフォルトでは、これらのコントロールプレーンノードには、デフォルトでワークロードをスケジュールする機能があります。

RKE2およびK3sのドキュメントでも、ワーカー役割を持つノードはエージェントノードと呼ばれています。クラスターにデプロイされたワークロードやポッドは、デフォルトでこれらのノードにスケジュールされることができます。

登録されたSUSE® Rancher Prime: RKE2およびSUSE® Rancher Prime: K3sクラスターのデバッグログとトラブルシューティング

ノードは、ダウンストリームクラスターで実行されているシステムアップグレードコントローラーによってアップグレードされます。クラスターの構成に基づいて、Rancherはノードをアップグレードするために2つのプランをデプロイします: 1つはコントロールプレーンノード用、もう1つはワーカー用です。システムアップグレードコントローラーはプランに従ってノードをアップグレードします。

システムアップグレードコントローラーのデプロイメントでデバッグログを有効にするには、 configmapを編集してデバッグ環境変数をtrueに設定します。次に、`system-upgrade-controller`ポッドを再起動します。

`system-upgrade-controller`によって作成されたログは、このコマンドを実行することで表示できます：

kubectl logs -n cattle-system system-upgrade-controller

プランの現在のステータスは、このコマンドで表示できます：

kubectl get plans -A -o yaml

クラスターがアップグレード中にスタックした場合は、`system-upgrade-controller`を再起動してください。

アップグレード時の問題を防ぐために、 Kubernetesアップグレードのベストプラクティスに従う必要があります。

SUSE® Rancher Prime: RKE2およびSUSE® Rancher Prime: K3sクラスターのための認可されたクラスターエンドポイントサポート

Rancherは、登録されたRKE2およびK3sクラスターのための認可されたクラスターエンドポイント（ACE）をサポートしています。このサポートには、ACEを有効にするためにダウンストリームクラスターで実行する手動ステップが含まれます。認可されたクラスターエンドポイントに関する追加情報は、こちらをクリックしてください。

メモ:

これらのステップは、ダウンストリームクラスターのコントロールプレーンノードでのみ実行する必要があります。各コントロールプレーンノードを個別に構成する必要があります。
以下のステップは、v2.6.xに登録されたRKE2およびK3sクラスター、および以前のRancherバージョンからアップグレードしてv2.6.xに登録（またはインポート）されたクラスターの両方で機能します。
これらのステップは、ダウンストリームのRKE2およびK3sクラスターの構成を変更し、`kube-api-authn-webhook`をデプロイします。将来のACEの実装が`kube-api-authn-webhook`の更新を必要とする場合、これも手動で行う必要があります。このWebhookに関する詳細情報は、こちらをクリックしてください。

各ダウンストリームクラスターのコントロールプレーンでACEを有効にするために取るべき手動ステップ：

`/var/lib/rancher/{rke2,k3s}/kube-api-authn-webhook.yaml`に次の内容でファイルを作成します：

 apiVersion: v1
 kind: Config
 clusters:
 ** name: Default
cluster:
  insecure-skip-tls-verify: true
  server: http://127.0.0.1:6440/v1/authenticate
 users:
 ** name: Default
user:
  insecure-skip-tls-verify: true
 current-context: webhook
 contexts:
 ** name: webhook
context:
  user: Default
  cluster: Default

設定ファイルに次の内容を追加する（存在しない場合は作成する）；デフォルトの場所は`/etc/rancher/{rke2,k3s}/config.yaml`であることに注意してください：
```
 kube-apiserver-arg:
     - authentication-token-webhook-config-file=/var/lib/rancher/{rke2,k3s}/kube-api-authn-webhook.yaml
```

次のコマンドを実行します。

sudo systemctl stop {rke2,k3s}-server
sudo systemctl start {rke2,k3s}-server

最後に、必ず*Rancher UIに戻り、そこでインポートされたクラスターを編集してACEの有効化を完了する必要があります。⋮ > 設定を編集*をクリックし、次にクラスター構成の下にある*ネットワーキング*タブをクリックします。最後に、*認可されたエンドポイント*用の*有効*ボタンをクリックします。ACEが有効になると、完全修飾ドメイン名（FQDN）と証明書情報を入力するオプションがあります。

*FQDN*フィールドはオプションで、入力された場合はダウンストリームクラスターを指す必要があります。証明書情報は、信頼されていない証明書を使用しているダウンストリームクラスターの前にロードバランサーがある場合にのみ必要です。有効な証明書がある場合、*CA証明書*フィールドに追加する必要はありません。

登録されたクラスターの注釈

RKE2およびK3s Kubernetesクラスターを除くすべてのタイプの登録されたKubernetesクラスターについて、Rancherはクラスターがどのようにプロビジョニングまたは構成されているかに関する情報を持っていません。

したがって、Rancherがクラスターを登録する際、いくつかの機能がデフォルトで無効であると仮定します。Rancherは、登録されたクラスターで機能が有効でない場合でも、ユーザーにUIオプションを表示しないようにするためにこれを仮定しています。

ただし、クラスターに特定の機能がある場合、そのクラスターのユーザーはRancher UIでクラスターの機能を選択したい場合があります。そのためには、ユーザーはRancherに対して特定の機能がクラスターに対して有効であることを手動で示す必要があります。

登録されたクラスターに注釈を付けることで、Rancherに対してクラスターがRancherの外で追加の機能を与えられたことを示すことができます。

次の注釈は、Ingress機能を示します。非プリミティブオブジェクトの値はJSONエンコードされ、引用符がエスケープされる必要があることに注意してください。

"capabilities.cattle.io/ingressCapabilities": "[
  {
    "customDefaultBackend":true,
    "ingressProvider":"asdf"
  }
]"

これらの機能はクラスターに注釈を付けることができます：

ingressCapabilities
loadBalancerCapabilities
nodePoolScalingSupported
nodePortRange
taintSupport

すべての機能とその型定義は、Rancher APIビューで`[Rancher Server URL]/v3/schemas/capabilities`に表示できます。

登録されたクラスターに注釈を付けるには、

*☰ > クラスター管理*をクリックします。
クラスター*ページで、注釈を付けたいカスタムクラスターに移動し、⋮ > 設定を編集*をクリックします。
*ラベルと注釈*セクションを開きます。
*注釈を追加*をクリックします。
`capabilities/<capability>: <value>`の形式でクラスタに注釈を追加してください。ここで`value`は注釈によって上書きされるクラスタの機能です。このシナリオでは、Rancherは注釈を追加するまでクラスタの機能を認識していません。
［保存］をクリックします。

*結果:*注釈はクラスタに機能を与えるものではありませんが、Rancherに対してクラスタがその機能を持っていることを示します。

トラブルシューティング

このセクションでは、クラスタをインポートする際に発生する可能性のある一般的なエラーのいくつかをリストし、それらをトラブルシューティングする手順を提供します。

AKS

ローカルアカウントがクラスタで無効になっている場合、次のエラーが発生する可能性があります：

Error: Getting static credential is not allowed because this cluster is set to disable local accounts.

この問題を解決するには、再度クラスタをインポートする前にローカルアカウントを有効にしてください：

az aks update --resource-group <resource-group> --name <cluster-name> --enable-local-accounts