第1章 アドオンの概要
Red Hat Advanced Cluster Management for Kubernetes アドオンは、パフォーマンスの一部の領域を改善し、アプリケーションを強化する機能を追加できます。以下のセクションでは、Red Hat Advanced Cluster Management で使用できるアドオンの概要を説明します。
1.1. Submariner マルチクラスターネットワーキングおよびサービスディスカバリー
Submariner は、Red Hat Advanced Cluster Management for Kubernetes で使用できるオープンソースツールであり、オンプレミスまたはクラウドのいずれかの環境で、2 つ以上のマネージドクラスター間で直接ネットワークおよびサービスディスカバリーを提供します。Submariner は Multi-Cluster Services API (Kubernetes Enhancements Proposal #1645) と互換性があります。Submariner の詳細は、Submariner のサイト を参照してください。
Red Hat Advanced Cluster Management for Kubernetes は、Submariner をハブクラスターのアドオンとして提供します。Submariner の詳細は、Submariner オープンソースプロジェクトのドキュメント を参照してください。
自動化コンソールデプロイメント でサポートされるインフラストラクチャープロバイダーおよび 手動デプロイメント が必要なインフラストラクチャープロバイダーに関する詳細は、Red Hat Advanced Cluster Management のサポートマトリックス を参照してください。
1.1.1. 前提条件
Submariner を使用する前に、以下の前提条件があることを確認します。
-
cluster-admin
のパーミッションを使用してハブクラスターにアクセスするための認証情報。 - ゲートウェイノード間で IP 接続を設定している。2 つのクラスターを接続する場合に、最低でも 1 つのクラスターには、ゲートウェイノード専用のパブリックまたはプライベート IP アドレスを使用してゲートウェイノードにアクセスできる必要があります。詳細は、Submariner NAT Traversal を参照してください。
- 各マネージドクラスターのすべてのノードにおけるファイアウォール設定は、両方の方向で 4800/UDP が許可されている。
- ゲートウェイノードのファイアウォール設定では、入力 8080/TCP が許可されているため、クラスター内の他のノードがアクセスできます。
- UDP/4500、およびゲートウェイノード上の IPsec トラフィックに使用されるその他のポート用にファイアウォール設定が開いている。
ゲートウェイノードが間に NAT を介さずにプライベート IP 経由で直接到達できる場合は、ファイアウォール設定でゲートウェイノード上で ESP プロトコルが許可されていることを確認してください。
注記: これは、クラスターが AWS または GCP 環境にデプロイされる際に自動的に設定されますが、他の環境のクラスター用に手動で設定し、プライベートクラウドを保護するファイアウォール用に設定する必要があります。
managedcluster
名は、RFC1123 で定義されている DNS ラベル標準に従っている。これは、名前が次の基準を満たしている必要があることを意味します。- 最大 63 文字を含む。
- 小文字の英数字またはハイフン (-) のみが含まれる。
- 英数字で始まる。
- 英数字で終わる。
Name | デフォルト値 | カスタマイズ可能 |
---|---|---|
IPsec NATT | 4500/UDP | はい |
VXLAN | 4800/UDP | ❌ |
Submariner メトリクスポート | 8080/TCP | ❌ |
前提条件の詳細は、Submariner アップストリームの前提条件のドキュメント を参照してください。
1.1.2. subctl コマンドユーティリティー
Submariner には、Submariner 環境でのタスクの実行を簡素化する追加コマンドを提供する subctl
ユーティリティーが含まれています。
1.1.2.1. subctl コマンドユーティリティーのインストール
subctl
ユーティリティーは、コンテナーイメージで提供されます。subctl
ユーティリティーをローカルにインストールするには、次の手順を実行します。
次のコマンドを実行し、プロンプトが表示されたら認証情報を入力して、レジストリーにログインします。
oc registry login --registry registry.redhat.io
次のコマンドを入力して、
subctl
コンテナー をダウンロードし、subctl
バイナリーの圧縮バージョンを/tmp
に展開します。oc image extract registry.redhat.io/rhacm2/subctl-rhel8:v0.12 --path=/dist/subctl-v0.12.1-linux-amd64.tar.xz:/tmp/ --confirm
注:
subctl-v0.12.1-linux-amd64.tar.xz
は、使用している Submariner のバージョンに変更する必要がある場合があります。次のコマンドを入力して、
subctl
ユーティリティーを展開します。tar -C /tmp/ -xf /tmp/subctl-v0.12-linux-amd64.tar.xz
次のコマンドを入力して、
subctl
ユーティリティーをインストールします。install -m744 /tmp/subctl-v0.12/subctl-v0.12-linux-amd64 /$HOME/.local/bin/subctl
1.1.2.2. subctl コマンドの使用
パスにユーティリティーを追加した後に使用可能なコマンドの簡単な説明については、次の表を参照してください。
指定されたサービスの | |
指定されたサービスの | |
Submariner リソースに関する情報を提供します。 | |
Submariner がクラスターのペア全体で設定されている場合は、接続性、サービスディスカバリー、およびその他のサブマリーナー機能を検証します。 | |
Submariner で、または単一のクラスター内で有効になっているクラスターのペア全体のスループットおよびレイテンシーをベンチマークします。 | |
チェックを実行して、Submariner デプロイメントが正しく機能しない原因となる問題を特定します。 | |
クラスターから情報を収集して、Submariner デプロイメントのトラブルシューティングに役立てます。 | |
|
subctl
ユーティリティーとそのコマンドの詳細は、Submariner ドキュメントのsubctl
を参照してください。
1.1.3. Globalnet
Globalnet は、CIDR が重複しているクラスター間の接続をサポートする Submariner アドオンに含まれている機能です。Globalnet はクラスターセット全体の設定であり、最初のマネージドクラスターがクラスターセットに追加されたときに選択できます。Globalnet が有効になっている場合、各マネージドクラスターには、仮想グローバルプライベートネットワークからグローバル CIDR が割り当てられます。グローバル CIDR は、クラスター間通信をサポートするのに使用されます。
Submariner を実行しているクラスターで CIDR が重複している可能性がある場合は、Globalnet を有効にすることを検討してください。Red Hat Advanced Cluster Management コンソールを使用する場合、ClusterAdmin
は、クラスターセット内のクラスターに対して Submariner アドオンを有効にするときに、Globalnet を有効にする オプションを選択することにより、クラスターセットに対して Globalnet を有効にすることができます。Globalnet を有効にした後は、Submariner を削除せずに無効にすることはできません。
Red Hat Advanced Cluster Management API を使用する場合、ClusterAdmin
は、<ManagedClusterSet>-broker
namespace に submariner-broker
オブジェクトを作成することで Globalnet を有効にできます。
ClusterAdmin
ロールには、ブローカーの namespace にこのオブジェクトを作成するのに必要な権限があります。クラスターセットのプロキシー管理者として機能するのに作成されることがある ManagedClusterSetAdmin
ロールには、必要な権限がありません。必要な権限を提供する場合は、ClusterAdmin
が access-to-brokers-submariner-crd
のロール権限を ManagedClusterSetAdmin
ユーザーに関連付ける必要があります。
submariner-broker
オブジェクトを作成するには、次の手順を実行します。
次のコマンドを実行して
<broker-namespace>
を取得します。oc get ManagedClusterSet <cluster-set-name> -o jsonpath="{.metadata.annotations['cluster\.open-cluster-management\.io/submariner-broker-ns']}"
submariner-broker
という名前の YAML ファイルを作成して、Globalnet 設定を指定するsubmariner-broker
オブジェクトを作成します。次の行のようなコンテンツを YAML ファイルに追加します。apiVersion: submariner.io/v1alpha1 kind: Broker metadata: name: submariner-broker namespace: <broker-namespace> spec: globalnetEnabled: <true-or-false>
broker-namespace
を、ブローカーの namespace に置き換えます。Globalnet を有効にするには、
true-or-false
をtrue
に置き換えます。注:
メタデータ
名
パラメーターはsubmariner-broker
である必要があります。次のコマンドを入力して、ファイルを YAML ファイルに適用します。
oc apply -f submariner-broker.yaml
Globalnet の詳細は、Submariner のドキュメントの Globalnet コントローラー を参照してください。
1.1.4. Submariner のデプロイ
Submariner は、次のプロバイダーのネットワーククラスターにデプロイできます。
自動デプロイメントプロセス:
- Amazon Web Services
- Google Cloud Platform
- Red Hat OpenStack Platform
手動デプロイメントプロセス:
- Microsoft Azure
- IBM Cloud
- VMware vSphere
- ベアメタル
1.1.4.1. コンソールを使用した Submariner のデプロイ
Red Hat Advanced Cluster Management for Kubernetes コンソールを使用して、Amazon Web Services、Google Cloud Platform、および VMware vSphere にデプロイされた Red Hat OpenShift Container Platform マネージドクラスターに Submariner をデプロイできます。他のプロバイダーに Submariner をデプロイするには、Submariner の手動デプロイ を参照してください。Red Hat Advanced Cluster Management for Kubernetes コンソールで Submariner をデプロイするには、以下の手順を実行します。
必要なアクセス権限: クラスターの管理者
- コンソールナビゲーションメニューから Infrastructure > Clusters を選択します。
- Clusters ページで、Cluster sets タブを選択します。Submariner で有効にするクラスターは、同じクラスターセットにある必要があります。
- Submariner をデプロイするクラスターがすでに同じクラスターセットにある場合は、手順 5 を省略して Submariner をデプロイします。
Submariner をデプロイするクラスターが同じクラスターセットにない場合は、以下の手順に従ってクラスターセットを作成します。
- Create cluster set を選択します。
- クラスターセットに名前を付け、Create を選択します。
- Manage resource assignments を選択して、クラスターセットに割り当てます。
- Submariner で接続するマネージドクラスターを選択して、クラスターセットに追加します。
- Review を選択して、選択したクラスターを表示し、確認します。
- Save を選択してクラスターセットを保存し、作成されるクラスターセットページを表示します。
- クラスターセットページで、Submariner add-on タブを選択します。
- Install Submariner add-ons を選択します。
- Submariner をデプロイするクラスターを選択します。
Install Submariner add-on エディターに以下の情報を入力します。
-
AWS Access Key ID
- このフィールドは、AWS クラスターをインポートする場合にのみ表示されます。 -
AWS Secret Access Key
: このフィールドは、AWS クラスターをインポートする場合にのみ表示されます。 -
Google Cloud Platform service account JSON key
: このフィールドは、Google Cloud Platform クラスターをインポートする場合にのみ表示されます。 -
Instance type
- マネージドクラスターで作成されたゲートウェイノードの Amazon Web Services EC2 インスタンスタイプ。デフォルト値はc5d.large
です。このフィールドは、マネージドクラスター環境が AWS の場合のみ表示されます。 -
IPsec NAT-T ポート
: IPsec NAT トラバーサルポートのデフォルト値はポート4500
です。マネージドクラスター環境が VMware vSphere の場合は、ファイアウォールでこのポートが開いていることを確認してください。 -
ゲートウェイ数
: マネージドクラスターへの Submariner ゲートウェイコンポーネントのデプロイに使用されるワーカーノードの数。デフォルト値は1
です。値が 1 を超える場合、Submariner ゲートウェイの High Availability (HA) は自動的に有効になります。 -
ケーブルドライバー
: クラスター間トンネルを維持する Submariner ゲートウェイケーブルエンジンのコンポーネントです。デフォルト値はLibreswan IPsec
です。
-
- エディターの末尾で Next を選択して、次のクラスターのエディターに移動し、選択した残りのクラスターごとに、エディターを完了します。
- 各マネージドクラスターの設定を確認します。
Install をクリックして、選択したマネージドクラスターに Submariner をデプロイします。
インストールと設定が完了するまで数分かかる場合があります。Submariner add-on タブの一覧で Submariner ステータスを確認できます。
-
Connection status
は、マネージドクラスターで確立される Submariner 接続の数を示します。 -
Agent status
は、Submariner がマネージドクラスターに正常にデプロイされるかどうかを示します。コンソールでは、インストールと設定が完了するまでDegraded
のステータスをレポートする場合があります。 -
Gateway nodes labeled
は、マネージドクラスターの Submariner ゲートウェイラベルsubmariner.io/gateway=true
が付いたワーカーノードの数を示します。
-
Submariner がクラスターにデプロイされました。
1.1.4.2. サブマリーナを手動でデプロイ
Red Hat Advanced Cluster Management for Kubernetes に Submariner をデプロイする前に、接続用にホスト環境でクラスターを準備する必要があります。現時点で、SubmarinerConfig
API を使用して、Amazon Web Services、Google Cloud Platform、および VMware vSphere のクラスターを自動的に準備できます。他のプラットフォームの場合は、手動で準備する必要があります。手順は、Submariner をデプロイする一部のホストの準備 を参照してください。
1.1.4.2.1. Submariner をデプロイする一部のホストの準備
Red Hat Advanced Cluster Management for Kubernetes に Submariner をデプロイする前に、接続用にホスト環境でクラスターを手動で準備する必要があります。要件はホスティング環境によって異なるため、ホスティング環境の手順に従います。
1.1.4.2.1.1. Submariner 向けの Microsoft Azure の準備
Submariner コンポーネントをデプロイするように Microsoft Azure でクラスターを準備するには、以下の手順を実行します。
次のコマンドを実行して、ノードをゲートウェイノードとしてタグ付けします。
kubectl label nodes <worker-node-name> "submariner.io/gateway=true" --overwrite
次のコマンドを実行して、パブリック IP を作成し、ゲートウェイノードとしてタグ付けされたノードの仮想マシンに割り当てます。
az network public-ip create --name <public-ip-name> --resource-group <res-group> -sku Standard az network nic ip-config update --name <name> --nic-name <gw-vm-nic> --resource-group <res-group> --public-ip-address <public-ip-name>
res-group
をクラスターのリソースグループに置き換えます。gw-vm-nic
をインターフェイスアドレスに置き換えます。次のコマンドを実行して、Submariner ゲートウェイのネットワークセキュリティーグループを作成します。
az network nsg create --name <gw-nsg-name> --resource-group <res-group>
Submariner のトンネルポート (デフォルトでは 4500/UDP)、NAT 検出ポート (デフォルトでは 4490/UDP)、メトリックポート (デフォルトでは 8080/TCP および 8081/TCP) を開くには、Azure 環境でネットワークセキュリティーグループルールを作成します。これらのルールは、ポートごとに受信方向と送信方向の両方で作成する必要があります。
az network nsg rule create --resource-group <res-group> \ --nsg-name <gw-nsg-name> --priority <priority> \ --name <name> --direction Inbound --access Allow \ --protocol <Protocol> --destination-port-ranges <port> az network nsg rule create --resource-group <res-group> \ --nsg-name <gw-nsg-name> --priority <priority> \ --name <name> --direction Outbound --access Allow \ --protocol <Protocol> --destination-port-ranges <port>
カプセル化されたセキュリティーペイロード (ESP) および認証ヘッダー (AH) プロトコルを使用して通信を許可するネットワークセキュリティーグループルールを作成します。これらのルールは、両方のプロトコルのインバウンドとアウトバウンドの両方で作成する必要があります。
az network nsg rule create --resource-group <res-group> \ --nsg-name <gw-nsg-name> --priority <priority> \ --name <name> --direction Inbound --access Allow \ --protocol <Protocol> --destination-port-ranges 0-0 az network nsg rule create --resource-group <res-group> \ --nsg-name <gw-nsg-name> --priority <priority> \ --name <name> --direction Outbound --access Allow \ --protocol <Protocol> --destination-port-ranges 0-0
次のコマンドを入力して、セキュリティーグループをゲートウェイ仮想マシンインターフェイスに接続します。
az network nic update -g <res-group> -n <gw-vm-nic> --network-security-group <gw-nsg-name>
ワーカーとメインノードに関連付けられている既存のセキュリティーグループ (デフォルトでは
<resource-group-name>-nsg
) で VXLAN ポート (デフォルトでは 4800/UDP) を開くために、Azure 環境でネットワークセキュリティーグループルールを作成します。az network nsg rule create --resource-group <res-group> \ --nsg-name <nsg-name> --priority <priority> \ --name <name> --direction Inbound --access Allow \ --protocol udp --destination-port-ranges <vxlan-port> az network nsg rule create --resource-group <res-group> \ --nsg-name <nsg-name> --priority <priority> \ --name <name> --direction Outbound --access Allow \ --protocol udp --destination-port-ranges <vxlan-port>
重要: Submariner を再インストールするときは、新しいゲートウェイノードがゲートウェイノードとしてタグ付けされていることを確認してください。Submariner をアンインストールした後に現在のゲートウェイを再利用すると、接続にエラー状態が表示されます。この要件は、手動のクラウド準備手順で Red Hat Advanced Cluster Management for Kubernetes を使用している場合にのみ適用されます。
1.1.4.2.1.2. Submariner 向けの VMware vSphere の準備
Submariner は IPsec を使用して、ゲートウェイノード上のクラスター間でセキュアなトンネルを確立します。デフォルトのポートを使用するか、カスタムポートを指定できます。IPsec NATT ポートを指定せずにこの手順を実行すると、通信にはデフォルトのポートが自動的に使用されます。デフォルトのポートは 4500/UDP です。
Submariner は、仮想拡張可能な LAN (VXLAN) を使用して、ワーカーノードおよびマスターノードからゲートウェイノードに移行するときにトラフィックをカプセル化します。VXLAN ポートはカスタマイズできず、常にポート 4800/UDP を使用します。
Submariner は 8080/TCP を使用してクラスターのノード間でメトリクス情報を送信します。このポートはカスタマイズできません。
Submariner を有効にするには、VMWare vSphere 管理者が以下のポートを開放する必要があります。
Name | デフォルト値 | カスタマイズ可能 |
---|---|---|
IPsec NATT | 4500/UDP | はい |
VXLAN | 4800/UDP | いいえ |
Submariner メトリクス | 8080/TCP | いいえ |
Submariner をデプロイするように VMware vSphere を準備するには、以下の手順を実行します。
- IPsec NATT、VXLAN、およびメトリクスポートが開放されていることを確認します。
次の例のような YAML コンテンツをカスタマイズして適用します。
apiVersion: submarineraddon.open-cluster-management.io/v1alpha1 kind: SubmarinerConfig metadata: name: submariner namespace: <managed-cluster-namespace> spec:{}
managed-cluster-namespace
は、マネージドクラスターの namespace に置き換えます。注記: 以下の例のように、
SubmarinerConfig
の名前はsubmariner
である必要があります。この設定は、Submariner にデフォルトの NATT (Network Address Translation-Traversal) ポート (4500/UDP) を使用し、1 つのワーカーノードは vSphere クラスターの Submariner ゲートウェイとしてラベルが付けられています。
Submariner は IP セキュリティー (IPsec) を使用して、ゲートウェイノード上のクラスター間でセキュアなトンネルを確立します。デフォルトの IPsec NATT ポートを使用するか、設定した別のポートを指定できます。IPsec NATT を指定せずにこの手順を実行すると、4500/UDP のポートが通信に自動的に使用されます。
1.1.4.2.1.3. Submariner 向けのベアメタルの準備
Submariner をデプロイするためのベアメタルクラスターを準備するには、次の手順を実行します。
- IPsec NATT、VXLAN、およびメトリクスポートが開放されていることを確認します。
次の例のような YAML コンテンツをカスタマイズして適用します。
apiVersion: submarineraddon.open-cluster-management.io/v1alpha1 kind: SubmarinerConfig metadata: name: submariner namespace: <managed-cluster-namespace> spec:{}
managed-cluster-namespace
は、マネージドクラスターの namespace に置き換えます。注記: 以下の例のように、
SubmarinerConfig
の名前はsubmariner
である必要があります。この設定は、Submariner にデフォルトの NATT (Network Address Translation-Traversal) ポート (4500/UDP) を使用し、1 つのワーカーノードはベアメタルクラスターの Submariner ゲートウェイとしてラベルが付けられています。
Submariner は IP セキュリティー (IPsec) を使用して、ゲートウェイノード上のクラスター間でセキュアなトンネルを確立します。デフォルトの IPsec NATT ポートを使用するか、設定した別のポートを指定できます。IPsec NATT を指定せずにこの手順を実行すると、4500/UDP のポートが通信に自動的に使用されます。
カスタマイズオプションについては、Submariner デプロイメントのカスタマイズ を参照してください。
1.1.4.2.2. ManagedClusterAddOn API を使用した Submariner のデプロイ
ManagedClusterAddOn
API を使用して Submariner をデプロイするには、最初にホスティング環境でクラスターを準備する必要があります。詳細は Submariner をデプロイする一部のホストの準備 を参照してください。
クラスターを準備したら、次の手順を実行します。
クラスターの管理 ドキュメントの ManagedClusterSets の作成および管理 トピックに記載されている手順を使用して、ハブクラスターに
ManagedClusterSet
リソースを作成します。ManagedClusterSet
のエントリーは以下のような内容になります。apiVersion: cluster.open-cluster-management.io/v1beta1 kind: ManagedClusterSet metadata: name: <managed-cluster-set-name>
managed-cluster-set-name
は、作成するManagedClusterSet
の名前に置き換えます。注記: Kubernetes namespace の名前の最大長は 63 文字であるため、
<managed-cluster-set-name>
の最大長さは 56 文字です。<managed-cluster-set-name>
の長さが 56 を超える場合には、<managed-cluster-set-name>
は、先頭から 56 文字で省略されます。ManagedClusterSet
が作成されたら、submariner-addon
は<managed-cluster-set-name>-broker
と呼ばれる namespace を作成し、その namespace に Submariner ブローカーをデプロイします。次の例のような YAML コンテンツをカスタマイズして適用することにより、
<managed-cluster-set-name>-broker
namespace のハブクラスターにBroker
設定を作成します。apiVersion: submariner.io/v1alpha1 kind: Broker metadata: name: submariner-broker namespace: <managed-cluster-set-name>-broker spec: globalnetEnabled: false
managed-cluster-set-name
は、マネージドクラスターの名前に置き換えます。ManagedClusterSet
で Submariner Globalnet を有効にする場合は、globalnetEnabled
の値をtrue
に設定します。以下のコマンドを入力して、マネージドクラスターを 1 つ
ManagedClusterSet
に追加します。oc label managedclusters <managed-cluster-name> "cluster.open-cluster-management.io/clusterset=<managed-cluster-set-name>" --overwrite
managedcluster-name
は、ManagedClusterSet
に追加するマネージドクラスターの名前に置き換えます。ManagedClusterSet-name
は、マネージドクラスターを追加するManagedClusterSet
の名前に置き換えます。次の例のような YAML コンテンツをカスタマイズして適用することにより、マネージドクラスターに Submariner をデプロイします。
apiVersion: addon.open-cluster-management.io/v1alpha1 kind: ManagedClusterAddOn metadata: name: submariner namespace: <managed-cluster-name> spec: installNamespace: submariner-operator
managedcluster-name
は、Submariner で使用するマネージドクラスターの名前に置き換えます。ManagedClusterAddOn
の仕様のinstallNamespace
フィールドは、Submariner をインストールするマネージドクラスター上の namespace に置き換えます。現在、Submariner-operator
namespace に Submariner をインストールする必要があります。ManagedClusterAddOn
の作成後に、submariner-addon
は Submariner をマネージドクラスターのsubmariner-operator
namespace にデプロイします。このManagedClusterAddOn
のステータスから Submariner のデプロイメントステータスを表示できます。注記:
ManagedClusterAddOn
の名前はsubmariner
である必要があります。- Submariner を有効にするすべてのマネージドクラスターに対して、手順 3 と 4 を繰り返します。
マネージドクラスターに Submariner をデプロイしたら、以下のコマンドを入力して、Submariner
ManagedClusterAddOn
のステータスを確認して Submariner のデプロイメントのステータスを確認できます。oc -n <managed-cluster-name> get managedclusteraddons submariner -oyaml
cluster-name
は、マネージドクラスターの名前に置き換えます。Submariner
ManagedClusterAddOn
のステータスの 3 つの条件により、Submariner のデプロイメントステータスが分かります。-
SubmarinerGatewayNodesLabeled
の条件は、マネージドクラスターに Submariner ゲートウェイノードにラベル付けされているかどうかを示します。 -
SubmarinerAgentDegraded
の条件は、Submariner がマネージドクラスターに正常にデプロイされるかどうかを示します。 -
SubmarinerConnectionDegraded
の条件は、Submariner でマネージドクラスターで確立される接続の数を示します。
-
1.1.4.2.3. Submariner デプロイメントのカスタマイズ
NATT (Network Address Translation-Traversal) ポート、ゲートウェイノードの数、ゲートウェイノードのインスタンスタイプなど、Submariner デプロイメントの設定の一部をカスタマイズできます。これらのカスタマイズは、すべてのプロバイダーで一貫しています。
1.1.4.2.3.1. NATT ポート
NATT ポートをカスタマイズする場合は、プロバイダー環境に合わせて次の YAML コンテンツをカスタマイズして適用します。
apiVersion: submarineraddon.open-cluster-management.io/v1alpha1 kind: SubmarinerConfig metadata: name: submariner namespace: <managed-cluster-namespace> spec: credentialsSecret: name: <managed-cluster-name>-<provider>-creds IPSecNATTPort: <NATTPort>
-
managed-cluster-namespace
は、マネージドクラスターの namespace に置き換えます。 managed-cluster-name
は、マネージドクラスターの名前に置き換えます。-
AWS:
provider
をaws
に置き換えます。<managed-cluster-name>-aws-creds
の値は、AWS の認証情報シークレット名で、この情報はハブクラスターのクラスター namespace にあります。 -
GCP:
provider
をgcp
に置き換えます。<managed-cluster-name>-gcp-creds
の値は、Google Cloud Platform 認証情報シークレット名を指し、ハブクラスターのクラスター namespace で見つけることができます。
-
AWS:
-
managed-cluster-namespace
は、マネージドクラスターの namespace に置き換えます。 -
managed-cluster-name
は、マネージドクラスターの名前に置き換えます。managed-cluster-name-gcp-creds
の値は、Google Cloud Platform 認証情報シークレット名を指し、ハブクラスターのクラスター namespace で見つけることができます。 -
NATTPort
は、使用する NATT ポートに置き換えます。
注記: 以下の例のように、SubmarinerConfig
の名前は submariner
である必要があります。
VMware vSphere 環境で NATT ポートをカスタマイズするには、次の YAML コンテンツをカスタマイズして適用します。
apiVersion: submarineraddon.open-cluster-management.io/v1alpha1 kind: SubmarinerConfig metadata: name: submariner namespace: <managed-cluster-namespace> spec: IPSecNATTPort: <NATTPort>
-
managed-cluster-namespace
は、マネージドクラスターの namespace に置き換えます。 -
NATTPort
は、使用する NATT ポートに置き換えます。
注記: 以下の例のように、SubmarinerConfig
の名前は submariner
である必要があります。
1.1.4.2.3.2. ゲートウェイノードの数
ゲートウェイノードの数をカスタマイズする場合は、次の例のような YAML コンテンツをカスタマイズして適用します。
apiVersion: submarineraddon.open-cluster-management.io/v1alpha1 kind: SubmarinerConfig metadata: name: submariner namespace: <managed-cluster-namespace> spec: credentialsSecret: name: <managed-cluster-name>-<provider>-creds gatewayConfig: gateways: <gateways>
-
managed-cluster-namespace
は、マネージドクラスターの namespace に置き換えます。 managed-cluster-name
は、マネージドクラスターの名前に置き換えます。-
AWS:
provider
をaws
に置き換えます。managed-cluster-name-aws-creds
の値は、AWS の認証情報シークレット名で、この情報はハブクラスターのクラスター namespace にあります。 -
GCP:
provider
をgcp
に置き換えます。<managed-cluster-name>-gcp-creds
の値は、Google Cloud Platform 認証情報シークレット名を指し、ハブクラスターのクラスター namespace で見つけることができます。
-
AWS:
-
gateways
は、使用するゲートウェイ数に置き換えます。値が 1 より大きい場合には、Submariner ゲートウェイは高可用性を自動的に有効にします。
注記: 以下の例のように、SubmarinerConfig
の名前は submariner
である必要があります。
VMware vSphere 環境でゲートウェイノードの数をカスタマイズする場合は、次の例のような YAML コンテンツをカスタマイズして適用します。
apiVersion: submarineraddon.open-cluster-management.io/v1alpha1 kind: SubmarinerConfig metadata: name: submariner namespace: <managed-cluster-namespace> spec: gatewayConfig: gateways: <gateways>
-
managed-cluster-namespace
は、マネージドクラスターの namespace に置き換えます。 -
gateways
は、使用するゲートウェイ数に置き換えます。値が 1 より大きい場合には、Submariner ゲートウェイは高可用性を自動的に有効にします。
1.1.4.2.3.3. ゲートウェイノードのインスタンスタイプ
ゲートウェイノードのインスタンスタイプをカスタマイズする場合は、次の例のような YAML コンテンツをカスタマイズして適用します。
apiVersion: submarineraddon.open-cluster-management.io/v1alpha1 kind: SubmarinerConfig metadata: name: submariner namespace: <managed-cluster-namespace> spec: credentialsSecret: name: <managed-cluster-name>-<provider>-creds gatewayConfig: instanceType: <instance-type>
-
managed-cluster-namespace
は、マネージドクラスターの namespace に置き換えます。 managed-cluster-name
は、マネージドクラスターの名前に置き換えます。-
AWS:
provider
をaws
に置き換えます。managed-cluster-name-aws-creds
の値は、AWS の認証情報シークレット名で、この情報はハブクラスターのクラスター namespace にあります。 -
GCP:
provider
をgcp
に置き換えます。<managed-cluster-name>-gcp-creds
の値は、Google Cloud Platform 認証情報シークレット名を指し、ハブクラスターのクラスター namespace で見つけることができます。
-
AWS:
-
instance-type
は、使用する AWS インスタンスタイプに置き換えます。
注記: 以下の例のように、SubmarinerConfig
の名前は submariner
である必要があります。
1.1.4.2.3.4. ケーブルドライバー
Submariner Gateway Engine コンポーネントは、他のクラスターへの安全なトンネルを作成します。ケーブルドライバーコンポーネントは、ゲートウェイエンジンコンポーネントのプラグ可能なアーキテクチャーを使用してトンネルを維持します。ケーブルエンジンコンポーネントの cableDriver
設定には、Libreswan または VXLAN 実装を使用できます。以下の例を参照してください。
apiVersion: submarineraddon.open-cluster-management.io/v1alpha1 kind: SubmarinerConfig metadata: name: submariner namespace: <managed-cluster-namespace> spec: cableDriver: vxlan credentialsSecret: name: <managed-cluster-name>-<provider>-creds
ベストプラクティス: パブリックネットワークでは VXLAN ケーブルドライバーを使用しないでください。VXLAN ケーブルドライバーは暗号化されていません。プライベートネットワークでの不要な二重暗号化を避けるために、VXLAN のみを使用してください。たとえば、一部のオンプレミス環境では、専用の回線レベルのハードウェアデバイスを使用してトンネルの暗号化を処理する場合があります。
1.1.4.3. Submariner のサービス検出の管理
Submariner がマネージドクラスターと同じ環境にデプロイされた後、マネージドクラスターセット内のクラスター全体で Pod とサービス間の安全な IP ルーティングのためにルートが設定されます。
1.1.4.3.1. Submariner のサービス検出の有効化
クラスターからのサービスをマネージドクラスターセット内の他のクラスターに表示および検出可能にするには、ServiceExport
オブジェクトを作成する必要があります。ServiceExport
オブジェクトでサービスをエクスポートすると、<service>.<namespace>.svc.clusterset.local
形式でサービスにアクセスできます。複数のクラスターが同じ名前で、同じ namespace からサービスをエクスポートすると、他のクラスターは、その複数のクラスターを 1 つの論理サービスとして認識します。
この例では、default
の namespace で nginx
サービスを使用しますが、Kubernetes の ClusterIP
サービスまたはヘッドレスサービスを検出できます。
以下のコマンドを入力して、
ManagedClusterSet
のマネージドクラスターにnginx
サービスのインスタンスを適用します。oc -n default create deployment nginx --image=nginxinc/nginx-unprivileged:stable-alpine oc -n default expose deployment nginx --port=8080
次のコマンドのような
subctl
ツールを使用してコマンドを入力し、ServiceExport
エントリーを作成して、サービスをエクスポートします。subctl export service --namespace <service-namespace> <service-name>
service-namespace
を、サービスが置かれた namespace の名前に置き換えます。この例では、default
になります。service-name
を、エクスポートするサービスの名前に置き換えます。この例では、nginx
になります。その他の使用可能なフラグの詳細については、Submariner ドキュメントの
export
を参照してください。別のマネージドクラスターから以下のコマンドを実行して、
nginx
サービスにアクセスできることを確認します。oc -n default run --generator=run-pod/v1 tmp-shell --rm -i --tty --image quay.io/submariner/nettest -- /bin/bash curl nginx.default.svc.clusterset.local:8080
これで、nginx
サービス検出が Submariner に対して設定されました。
1.1.4.3.2. Submariner のサービス検出の無効化
サービスが他のクラスターにエクスポートされないようにするには、nginx
の次の例のようなコマンドを入力します。
subctl unexport service --namespace <service-namespace> <service-name>
service-namespace
を、サービスが置かれた namespace の名前に置き換えます。
service-name
を、エクスポートするサービスの名前に置き換えます。
その他の使用可能なフラグの詳細は、Submariner ドキュメントの unexport
を参照してください。
このサービスは、クラスターによる検出に使用できなくなりました。
1.1.4.4. Submariner のアンインストール
Red Hat Advanced Cluster Management for Kubernetes コンソールまたはコマンドラインを使用して、クラスターから Submariner コンポーネントをアンインストールできます。0.12 より前の Submariner バージョンで、すべてのデータプレーンコンポーネントを完全に削除するには、追加の手順が必要です。Submariner のアンインストールはべき等であるため、問題なく手順を繰り返すことができます。
1.1.4.4.1. コンソール方式
Red Hat Advanced Cluster Management コンソールを使用してクラスターから Submariner をアンインストールするには、以下のステップを実行します。
- Red Hat Advanced Cluster Management コンソールのナビゲーションから、Infrastructure > Clusters を選択し、Cluster sets タブを選択します。
- Submariner コンポーネントを削除するクラスターを含むクラスターセットを選択します。
- Submariner Add-ons タブを選択して、Submariner がデプロイされているクラスターセット内のクラスターを表示します。
- Submariner をアンインストールするクラスターの Actions メニューで、Uninstall Add-on を選択します。
Submariner を削除する他のクラスターについても、これらの手順を繰り返します。
ヒント: 複数のクラスターを選択して Actions をクリックすると、同じクラスターセット内の複数のクラスターから Submariner アドオンを削除できます。Uninstall Submariner add-ons を選択します。
削除する Submariner のバージョンがバージョン 0.12 より前の場合は、Submariner の初期バージョンの手動削除手順 に進みます。Submariner のバージョンが 0.12 以降の場合、Submariner は削除されます。
重要: クラウドプロバイダーによる追加料金を回避するために、すべてのクラウドリソースがクラウドプロバイダーから削除されていることを確認してください。詳細は、Submariner リソースの削除の確認 を参照してください。
1.1.4.4.2. コマンドライン方式
コマンドラインを使用して Submariner をアンインストールするには、次の手順を実行します。
次のコマンドを入力して、Submariner アドオンを含むクラスターを見つけます。
oc get resource submariner-addon -n open-cluster-management
次の例のようなコマンドを実行して、クラスターから Submariner をアンインストールします。
oc delete resource submariner-addon -n <CLUSTER_NAME>
CLUSTER_NAME
は、クラスターの名前に置き換えます。- すべての Submariner コンポーネントをクラスターから削除することを確認します。
- 各クラスターに対して手順を繰り返して、サブマリーナーを削除します。
削除する Submariner のバージョンがバージョン 0.12 より前の場合は、Submariner の初期バージョンの手動削除手順 に進みます。Submariner のバージョンが 0.12 以降の場合、Submariner は削除されます。
重要: クラウドプロバイダーによる追加料金を回避するために、すべてのクラウドリソースがクラウドプロバイダーから削除されていることを確認してください。詳細は、Submariner リソースの削除の確認 を参照してください。
1.1.4.4.3. Submariner の初期バージョンの手動削除手順
バージョン 0.12 より前のバージョンの Submariner をアンインストールする場合は、Submariner ドキュメントの 手動アンインストール セクションの手順 5 ~ 8 を実行してください。
これらの手順を完了すると、Submariner コンポーネントがクラスターから削除されます。
重要: クラウドプロバイダーによる追加料金を回避するために、すべてのクラウドリソースがクラウドプロバイダーから削除されていることを確認してください。詳細は、Submariner リソースの削除の確認 を参照してください。
1.1.4.4.4. Submariner リソースの削除の確認
Submariner をアンインストールした後、すべての Submariner リソースがクラスターから削除されていることを確認します。それらがクラスターに残っている場合、一部のリソースはインフラストラクチャープロバイダーからの料金を引き続き発生させます。次の手順を実行して、クラスターに追加の Submariner リソースがないことを確認します。
次のコマンドを実行して、クラスターに残っている Submariner リソースを一覧表示します。
oc get cluster <CLUSTER_NAME> grep submariner
CLUSTER_NAME
をクラスターの名前に置き換えます。次のコマンドを入力して、リストのリソースをすべて削除します。
oc delete resource <RESOURCE_NAME> cluster <CLUSTER_NAME>
RESOURCE_NAME
を、削除する Submariner リソースの名前に置き換えます。- 検索でリソースが特定されなくなるまで、クラスターごとに手順 1 ~ 2 を繰り返します。
Submariner リソースがクラスターから削除されます。