1. Home
  2. Confluent for Kubernetes
  3. Confluent for Kubernetes を使用したアップグレード

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 に設定されている
    • ノードポートサービスを使用して外部アクセスが構成されている
    • 単純なクライアント認可 が有効になっている

前提条件

  • すべての PV とストレージクラスの回収ポリシーが Retain に設定されていることを確認します。

    移行プロセスを開始する前に、すべての PV とストレージクラスの回収ポリシーが Retain に設定されている必要があります。

    1. 次のコマンドを使用して、PV の回収ポリシーをチェックします。

      kubectl get pv

    2. Delete 回収ポリシーで PV をアップデートし、その回収ポリシーを、次のコマンドを使用して Retain に設定します。

      kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

    3. ストレージクラスの回収ポリシーが 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/confluent-init-container:2.3.1
                                    --- [1]
  kafka: #component section
    enabled: false                  --- [2]
    name: kafka                     --- [3]
    namespace: confluent            --- [4]
    release: kafka                  --- [5]

  • [1] すべての移行において、バージョン confluentinc/confluent-init-container:2.3.1 に設定します。

  • [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 を参照してください。

自動化されたインプレース移行

自動化されたインプレース移行は、次の手順で行います。

  1. Deploy Confluent for Kubernetes 2.0 alongside Confluent Operator 1.x.

  2. Confluent Platform コンポーネントを 1 つずつ移行します。移行の順序については後述します。

    重要

    各コンポーネントの移行ジョブが（ステップ 2 で）開始された後に移行をロールバックすることはできません。

    1. コンポーネントの移行ジョブを実行します。
    2. 移行ジョブの進捗状況をモニタリングします。
    3. 移行ジョブが完了したことを確認します。

  3. すべてのコンポーネントが移行されたら、Confluent Operator 1.x を削除します。

  4. Check the current version of Confluent Platform for compatibility with CFK 2.3.1 and upgrade Confluent Platform if needed.

コンポーネントは次の順序で移行します。

  1. ZooKeeper を移行します。
  2. Kafka を移行します。
  3. Schema Registry を移行します。
  4. ksqlDB を移行します。
  5. Connect を移行します。
  6. Replicator を移行します。
  7. Confluent Control Center を移行します。

Step 1. Deploy Confluent for Kubernetes 2.0 along side Confluent Operator 1.x

  1. Helm リポジトリを追加します。

    helm repo add confluentinc https://packages.confluent.io/helm \
  --namespace <namespace>

    helm repo update --namespace <namespace>

  2. In the same namespace as you have Confluent Operator 1.x, deploy Confluent for Kubernetes 2.0:

    helm upgrade --install confluent-for-kubernetes \
  confluentinc/confluent-for-kubernetes \
  --set licenseKey=<CFK license key> \
  --namespace <namespace>

  3. 両方がデプロイされて実行されていることを確認します。

    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 つずつ実行します。

  1. 「移行ジョブの CR」の説明に従って移行の CR を構成します。

    ZooKeeper を移行する例を次に示します。

    spec:
  initContainerImage: confluentinc/confluent-init-container:2.3.1
  zookeeper:
    enabled: true
    name: zookeeper
    namespace: confluent
    release: zookeeper
  kafka:
    enabled: false

  2. 移行の CR を適用します。これによってコンポーネントの移行ジョブが開始されます。

    移行の CR を適用した後は、その移行の CR を編集できなくなります。

ステップ 3. 移行ジョブ実行の進捗状況をモニタリングする

コンポーネントの移行ジョブによって、次の手順が実行されます。

  1. Create the CFK 2.0 CustomResource and corresponding Kubernetes objects.
  2. Roll the component pods to start being managed through the CFK 2.0 CR.
  3. 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 uses the same image pull secret that Operator 1.x uses. If you use a custom Docker registry, ensure that you can re-apply this secret:

  1. Docker レジストリのシークレットをファイルにコピーします。

    kubectl get secret <your docker registry secret> -oyaml > \
   confluent-docker-registry-secret.yaml \
   -n <namespace>

  2. シークレットファイル（confluent-docker-registry-secret.yaml）を編集し、metadata セクションにある情報を、name と namespace を残してすべて削除します。

すべてのコンポーネントの移行が完了したことを確認したら、Operator 1.x をアンインストールします。

  1. Operator 1.x をアンインストールします。

    helm uninstall <operator 1.x helm release> -n <namespace>

  2. Docker レジストリのシークレットを適用します。

    kubectl apply -f confluent-docker-registry-secret.yaml -n <namespace>

Step 6. View migrated custom resources

コンポーネントは次の順序で移行します。

kubectl get <component type> <component name> -n <namespace> -o yaml \
  >> <component CR yaml file>

For example:

kubectl get zookeeper zookeeper -n confluent -o yaml >> zookeeper.yaml

kubectl get kafka kafka -n confluent -o yaml >> kafka.yaml

Step 7. Upgrade Confluent Platform to the supported version

The migration process does not upgrade the version of Confluent Platform. Check Supported Versions to see if the version of Confluent Platform is compatible with CFK 2.3.1.

If the Confluent Platform version is not compatible, follow the steps in Upgrade Guide to upgrade Confluent Platform to a version supported by CFK 2.3.1.

手動でのインプレース移行

Confluent Operator 1.x の Helm チャートテンプレートに変更を加えた場合は、Confluent サポートにお問い合わせのうえ、Confluent エンジニアリングチームに移行方法をご確認ください。