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
```
Copy
operator は Confluent Platform のデプロイ先となる名前空間です。
コマンドはすべて、Confluent Operator のダウンロード先ディレクトリにある helm ディレクトリで実行されます。

現状の Confluent Operator では、Confluent Platform 5.3.x から 6.0.x へ、または 5.4.x から 6.0.x への直接アップグレードはサポートされていません。6.0.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 バージョン 5.5.x から 6.0.x へのアップグレード¶

重要

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

Confluent Operator 1.6.2 のダウンロード¶

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

アップグレードの準備¶

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

アップグレードに関する以下の考慮事項を入念に検討してください。ここには、Confluent Platform 6.0.x へのアップグレード前に実施する必要のある必須アクションが含まれています。必要とされるアップグレード前変更を行った場合、以下のセクションで説明しているとおり、変更内容が適用されるのは helm upgrade を使用したアップグレード後です。

RBAC 対応の Confluent Platform のアップグレード準備¶

Confluent Platform 5.5 で RBAC を有効にしている場合は、以下を実行する必要があります。
1. Confluent REST API 用の LDAP サービスにユーザーを追加します。
2. 上記の認証情報を使用するために、「 RBAC の Kafkaの構成」の説明に従って、構成ファイル（ $VALUES_FILE ）の kafka.services.restProxy.authentication セクションをアップデートします。
RBAC を有効にしてあり、Schema Registry をデプロイ済みの場合は、「RBAC の Schema Registry の構成」の説明に従って、Schema Registry コンポーネントのプリンシパルに _confluent-license トピックに対する ResourceOwner ロールを付与する必要があります。

コネクターのアップグレード準備¶

Confluent Platform 1.6.2 から、コネクターは Connect イメージにパッケージ化されなくなりました。Connect ワーカーをアップグレードする前に、コネクターを Connect イメージ cp-server-connect-operator に追加して、コネクターをデプロイし直す必要があります。Docker イメージの拡張の詳細については、「Confluent Platform イメージのビルド」を参照してください。

1 つまたは複数のコネクターを cp-server-connect-operator イメージに追加するには、<dockerfile-dir> に Dockerfile を作成します。

以下のいずれかを行います。
1. Confluent Hub からコネクターをプルします。
2. Docker ビルドを実行しているマシンにダウンロードしたコネクター JAR を使用します。
- コネクターを Confluent Hub からプルするには、以下のように Dockerfile を作成します。
```
FROM confluentinc/cp-server-connect-operator:6.0.0.0
USER root
RUN confluent-hub install --no-prompt <connector1>:<connector1-version> \
  && confluent-hub install --no-prompt <connector2>:<connector2-version> \
  && ...
USER 1001
```
  Copy
  この Dockerfile の例では、Docker イメージの作成に Confluent Hub の data-gen コネクターを使用しています。
```
FROM confluentinc/cp-server-connect-operator:6.0.0.0
USER root
RUN  confluent-hub install --no-prompt confluentinc/kafka-connect-datagen:0.3.3
USER 1001
```
  Copy
- Docker ビルドを実行しているマシン上のコネクター JAR ファイルを使用するには、以下のように Dockerfile を作成します。
```
FROM confluentinc/cp-server-connect-operator:6.0.0.0
ADD <local-connector1-path> /usr/share/java/<connector1> \
  && <local-connector2-path> /usr/share/java/<connector2> \
  && ...
USER 1001
```
  Copy
  この例の Dockerfile では、ローカルマシンの <connector-dir> ディレクトリにある data-gen コネクターを使用します。
```
FROM confluentinc/cp-server-connect-operator:6.0.0.0
ADD my-connector-dir/confluentinc-kafka-connect-datagen /usr/share/java/confluentinc-kafka-connect-datagen
USER 1001
```
  Copy

以下のコマンドを実行して、イメージをビルドしてプッシュします。

docker build <dockerfile-dir> -t <someregistry>/<somerepo>:<sometag>

docker push <someregistry>/<somerepo>:<sometag>
Copy

Docker イメージの詳細を上記のプロセスの出力から入手し、構成ファイル（$VALUES_FILE）の Connect セクションにリポジトリとタグを指定します。
```
connect:
  image:
    repository: <someregistry>/<somerepository>
    tag: <image-tag>
```
Copy

Confluent Operator のアップグレード¶

作業ディレクトリを Confluent Operator 1.6.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/
```
Copy
Confluent Platform コンポーネントをデプロイした各名前空間について、disable_reconcile.sh スクリプトを実行します。

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

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

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

helm ls
Copy

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

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

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

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

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

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

Confluent Operator 1.6.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
Copy

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

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

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

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

Operator バンドルに同梱の IMAGES ファイルで、アップデートする Confluent Platform コンポーネントを探し、イメージタグ <new-tag> を確認します。
構成ファイル（ $VALUES_FILE ）で、以下のセクションを追加またはアップデートします。
```
<component>:
  image:
    tag: <new-tag>
```
Copy
以下のコマンドを実行して、<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>
```
Copy
上記の helm upgrade コマンドを実行すると、リコンサイルが無効ではない限り、コンポーネントのローリングアップグレードが始まります（リコンサイルを無効にした場合の例については、1.6.2 へのアップグレードに関する前述のワークフローを参照）。