Confluent Operator および Confluent Platform のアップグレード¶

アップグレードのプロセスに着手する前に、使用する Kubernetes クラスターが Confluent Operator のターゲットバージョンのサポートされる環境に該当していることを確認します。

このガイドの例では、以下が想定されています。

$VALUES_FILE は「グローバル構成ファイルの作成」でセットアップする構成ファイルのことです。
Operator ドキュメントで簡潔で明快な例を提示できるよう、すべての構成パラメーターが構成ファイル（ $VALUES_FILE ）に指定されます。ただし、本稼働環境でのデプロイにおいて、Helm を使用して機密データを扱う場合には、--set または --set-file オプションを使用します。以下に例を示します。
```
helm upgrade --install kafka \
 --set kafka.services.mds.ldap.authentication.simple.principal="cn=mds\,dc=test\,dc=com" \
 --set kafka.services.mds.ldap.authentication.simple.credentials=”Developer!” \
 --set kafka.enabled=true
```
operator は Confluent Platform のデプロイ先となる名前空間です。
コマンドはすべて、Confluent Operator のダウンロード先ディレクトリにある helm ディレクトリで実行されます。

現状の Confluent Operator では、Confluent Platform 5.3.x から 6.1.x へ、または 5.4.x から 6.1.x への直接アップグレードはサポートされていません。Confluent Platform 6.1.x へアップグレードするには、以下の手順でローリングアップグレードを実施します。

Confluent Platform を 5.3.x から 5.4.x へアップグレードします。具体的には、アップグレードの前に pre_upgrade_cp54_zookeeper.sh スクリプトを実行します。
Confluent Platform を 5.4.x から 5.5.x へアップグレードします。
Confluent Platform を 5.5.x から 6.0.x へアップグレードします。
以下のセクションの説明に従って、Confluent Platform を 6.0.x から 6.1.x へアップグレードします。

Confluent Platform バージョン 6.0.x から 6.1.x へのアップグレード¶

重要

Operator 1.7.2 の init コンテナーにはリソース構成が導入されているため、Confluent Platform を 6.1 にアップグレードするとクラスターがローリングされます。

Confluent Operator 1.7.2 のダウンロード¶

移行およびアップグレードプロセスの第一歩として、Operator バンドルをダウンロードして抽出します。

アップグレードの準備¶

一般に、一度に発生する変更の数を最小限に抑えることが最善です。Confluent Platform の 6.0 から 6.1 へのアップグレードでは、スケールアップ、構成の変更、認証情報のローテーションなどのクラスターに対する他の変更とは別にこのアップグレードを実施することを推奨します。

Confluent Operator のアップグレード¶

作業ディレクトリを Confluent Operator 1.7.2 のルートディレクトリに変更します。
Confluent Platform の CustomResourceDefinitions（CRD）をアップデートします。

Confluent Platform の CRD のインストールとアップデートは、Confluent Operator によって管理されます。ユーザーは、以下のいずれかのオプションを使用してオプトアウトできます。
- 構成ファイル（$VALUES_FILE）に operator.installClusterResources: false を設定して、直接オプトアウト
- 構成ファイル（$VALUES_FILE）に operator.namespaced: true を設定して、名前空間を使用するモードに Operator をデプロイすることで間接的にオプトアウト
Operator 管理の CRD をオプトアウトし、Confluent Platform の CRD を別途管理する場合は、Operator ディレクトリのルートから以下のコマンドを実行して、CRD をアップデートする必要があります。
```
kubectl apply -f ./resources/crds/
```
Confluent Platform コンポーネントをデプロイした各名前空間について、disable_reconcile.sh スクリプトを実行します。

アップグレードの実行前のリコンサイル操作を無効にしなかった場合、コンポーネントのローリング再起動が始まり、一部のポッドが CrashLoopBackOff ステータスになることがあります。

スクリプトはリコンサイル操作を無効にするので、Confluent Platform コンポーネントは再起動されません。このアップグレード中に再起動されるのは Operator のみです。
```
./scripts/upgrade/disable_reconcile.sh <namespace>
```
出力は以下のようになります。
```
./scripts/upgrade/disable_reconcile.sh <namespace>

physicalstatefulcluster.operator.confluent.cloud/connectors annotated
physicalstatefulcluster.operator.confluent.cloud/controlcenter annotated
physicalstatefulcluster.operator.confluent.cloud/kafka annotated
physicalstatefulcluster.operator.confluent.cloud/ksql annotated
physicalstatefulcluster.operator.confluent.cloud/replicator annotated
physicalstatefulcluster.operator.confluent.cloud/schemaregistry annotated
physicalstatefulcluster.operator.confluent.cloud/zookeeper annotated
```

以下のコマンドを実行して、Operator Helm リリース名 <operator-helm-release-name> を取得します。

helm ls

<operator-helm-release-name> は、出力に表示される名前です。

NAME        REVISION    UPDATED              STATUS   CHART                APP VERSION    NAMESPACE
operator    2           Mon Jan 6            DEPLOYED confluent-operator   1.0            operator

Confluent Operator 1.7.2 ディレクトリの helm ディレクトリから以下のコマンドを実行して、Operator をアップグレードします。

helm upgrade --install <operator-helm-release-name> \
  ./confluent-operator \
  --values $VALUES_FILE \
  --set operator.enabled=true \
  --namespace <namespace> \
  --wait

ZooKeeper、Kafka、その他の Confluent Platform コンポーネントのアップグレード¶

ZooKeeper、Kafka、およびその他のコンポーネント、具体的には Schema Registry、Connect、Replicator、Confluent Control Center について、以下のコマンドを実行します。

Confluent Operator 1.7.2 ディレクトリにある helm ディレクトリから helm upgrade コマンドを実行します。

注釈

この処理中、各クラスターのローリングが行われます。

Confluent Platform コンポーネントクラスターごとに、クラスターの目的の構成とバージョンをアップデートします。

helm upgrade --install <component-helm-release-name> \
   ./confluent-operator \
   --values $VALUES_FILE \
   --set <component>.enabled=true \
   --namespace <namespace> \
   --wait

構成ファイル（ $VALUES_FILE ）から <component-name> を取得します。
```
<component>:
  name: # This value
```
各 Confluent Platform コンポーネントクラスターについて、前のステップの <component-name> を使用してリコンサイルを有効にして、Operator によって目的の構成が適用され、クラスターがアップデートされるようにします。
```
./scripts/upgrade/enable_reconcile.sh <namespace> <component-name>
```
以下に例を示します。
```
./scripts/upgrade/enable_reconcile.sh operator kafka
```

単一コンポーネントイメージのアップデート¶

クラスターのパフォーマンスに影響を与えることなく、単一の Confluent Platform コンポーネントイメージバージョンをアップデートすることができます。

Kafka ブローカーのアップグレード時には、特別な注意が必要です。アップグレードプロセスでは、トピックリーダーが選び直されていることとレプリケーション中パーティションがゼロであることが確認されてから、次の Kafka ブローカーのアップグレードプロセスが始まります。これにより、アップグレード中の Kafka クラスターの通常動作が継続されます。

Operator バンドルに同梱の IMAGES ファイルで、アップデートする Confluent Platform コンポーネントを探し、イメージタグ <new-tag> を確認します。
構成ファイル（ $VALUES_FILE ）で、以下のセクションを追加またはアップデートします。
```
<component>:
  image:
    tag: <new-tag>
```
以下のコマンドを実行して、<component-helm-release-name> をコンポーネントの Helm リリース名に置き換えます。
```
helm upgrade --install <component-helm-release-name> \
 --values $VALUES_FILE \
 --set <component>.enabled=true \
 --set <component>.image.tag=<new-tag> \
 ./confluent-operator \
 --namespace <namespace>
```
上記の helm upgrade コマンドを実行すると、リコンサイルが無効ではない限り、コンポーネントのローリングアップグレードが始まります（リコンサイルを無効にした場合の例については、1.7.2 へのアップグレードに関する前述のワークフローを参照）。