Confluent for Kubernetes への移行¶
このトピックでは、Confluent Platform デプロイを管理するための Operator 1.x を Confluent for Kubernetes (CFK)|release| に移行する方法について説明します。
次のソフトウェアバージョンからの移行がサポートされます。
- Confluent Operator 1.6.x または 1.7.x
- Confluent Platform 6.0.x または 6.1.x
以下に示した移行オプションは、いずれも Confluent Platform のデプロイに対する破壊的な変更を伴いません。Confluent コンポーネントポッド、PersistentVolumeClaims、サービスが移行プロセスで削除されることはありません。
次に示したのは、現在のデプロイ状態(表中の「開始点」)ごとに推奨される移行オプションです。
開始点 | 推奨される移行方法 |
---|---|
Operator 1 Helm チャートテンプレートにアウトオブバンドの変更 [1] が加えられていない | 自動化されたインプレース移行 [2] |
Operator 1 Helm チャートテンプレートにアウトオブバンドの変更が加えられている | 手動でのインプレース移行 |
Operator 1 の Helm チャートで作成された従来型のストレージクラスが使用されている | 新しいクラスターのデプロイとデータのレプリケート |
- [1] アウトオブバンドの変更とは、
values.yaml
構成ファイル以外の方法で Operator 1 のデプロイに加えた変更を指します。values.yaml
ファイルで行った構成の変更はこの変更に含まれません。 - [2] 以下の構成シナリオでは、たとえアウトオブバンドの変更が一切なかったとしても、移行の自動化はできません。手動での移行が要求されるシナリオとなるため、Confluent サポートにお問い合わせください。
- RBAC が有効になっていて、
internalTLS
がfalse
に設定されている - RBAC が有効になっていて、
internalTLS
がtrue
に設定され、さらにinterbrokerTLS
がfalse
に設定されている - ノードポートサービスを使用して外部アクセスが構成されている
- 単純なクライアント認可 が有効になっている
- RBAC が有効になっていて、
前提条件¶
すべての PV とストレージクラスの回収ポリシーが
Retain
に設定されていることを確認します。移行プロセスを開始する前に、すべての PV とストレージクラスの回収ポリシーが
Retain
に設定されている必要があります。次のコマンドを使用して、PV の回収ポリシーをチェックします。
kubectl get pv
Delete
回収ポリシーで PV をアップデートし、その回収ポリシーを、次のコマンドを使用してRetain
に設定します。kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
ストレージクラスの回収ポリシーが
Retain
に設定されていることを確認します。
内部アクセス用の TLS 証明書のホスト名が正しいことを確認します。
Connect、ksqlDB、Schema Registry のいずれかで TLS が有効になっている場合、内部 Kubernetes ネットワークでのコンポーネント間通信に使用される TLS 証明書のホスト名が正しいことを、その証明書の SAN(Subject Alternative Name)で確認してください。これは通常、ポッドの DNS 名にマッピングされます(例:
*.<component-name>.<namespace>.svc.cluster.local
)。
移行ジョブの CR¶
Confluent for Kubernetes には、現在のデプロイ状態を宣言的に指定できる、MigrationJob
のカスタムリソース定義(CRD)が用意されています。MigrationJob
のカスタムリソース(CR)を作成することで移行をトリガーできます。
現在の移行の状態には、MigrationJob
の CR の status
サブリソースを通じてアクセスできます。
次に示したのは、Kafka セクションの例です。
spec:
initContainerImage: confluentinc/cp-init-container-operator:6.1.1.0
--- [1]
kafka: #component section
enabled: false --- [2]
name: kafka --- [3]
namespace: confluent --- [4]
release: kafka --- [5]
[1] すべての移行において、バージョン
confluentinc/cp-init-container-operator:6.1.1.0
に設定します。[2](必須)
MigrationJob
の CR を使用してコンポーネントを移行するには、true
に設定します。[3](必須)Operator 1.x によってデプロイされた Helm チャートコンポーネントの名前に設定します。その場所については、Operator 1.x の Helm の
values.yaml
で確認してください。## Kafka Cluster ## kafka: name: <this-component-name>
[4](必須)現在のコンポーネントの検索先の名前空間。移行されたリソースは、この名前空間に作成されます。
[5](必須)Operator 1.x をデプロイしたときに次のコマンドで指定した Helm リリース名に設定します。
helm install <release-name> -f myvalues.yaml ./chart
移行ジョブの構成については、Confluent コンポーネントの移行ジョブのサンプル CR を参照してください。
自動化されたインプレース移行¶
自動化されたインプレース移行は、次の手順で行います。
- Confluent Operator 1.x とともに Confluent for Kubernetes 2.0 をデプロイします。
- Confluent Platform コンポーネントを 1 つずつ移行します。移行の順序については後述します。
- コンポーネントの移行ジョブを実行します。
- 移行ジョブの進捗状況をモニタリングします。
- 移行ジョブが完了したことを確認します。
- すべてのコンポーネントが移行されたら、Confluent Operator 1.x を削除します。
重要
各コンポーネントの移行ジョブが(ステップ 2 で)開始された後に移行をロールバックすることはできません。
コンポーネントは次の順序で移行します。
- ZooKeeper を移行します。
- Kafka を移行します。
- Schema Registry を移行します。
- ksqlDB を移行します。
- Connect を移行します。
- Replicator を移行します。
- Confluent Control Center を移行します。
ステップ 1. Confluent Operator 1.x とともに Confluent for Kubernetes 2.0 をデプロイする¶
Helm リポジトリを追加します。
helm repo add confluentinc https://packages.confluent.io/helm \ --namespace <namespace>
helm repo update --namespace <namespace>
Confluent Operator 1.x と同じ名前空間に Confluent for Kubernetes 2.0 をデプロイします。
helm upgrade --install confluent-for-kubernetes \ confluentinc/confluent-for-kubernetes \ --set licenseKey=<CFK license key> \ --namespace <namespace>
両方がデプロイされて実行されていることを確認します。
kubectl get pods
NAME READY STATUS RESTARTS AGE cc-operator-7dbc8fd598-bh8r7 1/1 Running 0 2d19h confluent-operator-5b99cdd9d9-bzmqr 1/1 Running 0 20h
ステップ 2. コンポーネントの移行ジョブを 1 つずつ実行する¶
コンポーネントの移行ジョブを 1 つずつ実行します。
「移行ジョブの CR」の説明に従って移行の CR を構成します。
ZooKeeper を移行する例を次に示します。
spec: initContainerImage: confluentinc/cp-init-container-operator:6.1.1.0 zookeeper: enabled: true name: zookeeper namespace: confluent release: zookeeper kafka: enabled: false
移行の CR を適用します。これによってコンポーネントの移行ジョブが開始されます。
移行の CR を適用した後は、移行の CR を編集できなくなります。
ステップ 3. 移行ジョブ実行の進捗状況をモニタリングする¶
コンポーネントの移行ジョブによって、次の手順が実行されます。
- CFK 2.0 CustomResource および対応する Kubernetes オブジェクトを作成します。
- コンポーネントポッドをローリングします。これによって CFK 2.0 CR による管理が開始されます。
- Operator 1.x リソースを削除します。
移行中は、以下のコマンドで進捗状況とステータスを確認します。<component>
は、ZooKeeper、Kafka、Schema Registry、Confluent Control Center、ksqlDB、Connect のいずれかに置き換えてください。<namespace>
は、Operator 1.x のデプロイ先の名前空間に置き換えます。
# Check the status of current migration job
kubectl get migration migration -oyaml -n <namespace> -w
# Check that the migration job creates the CFK 2.0 CustomResource
kubectl get <component> -n <namespace>
# Check that the component pods are rolling
kubectl get pods -n <namespace>
ステップ 4. 移行ジョブが完了したことを確認する¶
移行ジョブが正常に完了したことを確認します。
# Validate that migrated components do not have a release
helm list
# Validate that migrated components do not have a PSC - an Operator 1.x object
kubectl get psc -n <namespace>
# Validate that all secrets are prefixed with v2 prefix
kubectl get secrets -n <namespace>
ステップ 5. Confluent Operator 1.x を削除する¶
すべてのコンポーネントが正常に移行されたら、Confluent Platform デプロイが正常な状態になっています。
CFK 2.0 では、Operator 1.x と同じイメージプルシークレットが使用されます。カスタム Docker レジストリを使用する場合は、このシークレットを確実に再適用できるようにしてください。
Docker レジストリのシークレットをファイルにコピーします。
kubectl get secret <your docker registry secret> -oyaml > \ confluent-docker-registry-secret.yaml \ -n <namespace>
シークレットファイル(
confluent-docker-registry-secret.yaml
)を編集し、metadata
セクションにある情報を、name
とnamespace
を残してすべて削除します。
すべてのコンポーネントの移行が完了したことを確認したら、Operator 1.x をアンインストールします。
Operator 1.x をアンインストールします。
helm uninstall <operator 1.x helm release> -n <namespace>
Docker レジストリのシークレットを適用します。
kubectl apply -f confluent-docker-registry-secret.yaml -n <namespace>
手動でのインプレース移行¶
Confluent Operator 1.x の Helm チャートテンプレートに変更を加えた場合は、Confluent サポートにお問い合わせのうえ、Confluent エンジニアリングチームに移行方法をご確認ください。