バージョン 2.4

利用可能なバージョン

Kf をアップグレードする

このドキュメントでは、既存の Kf インストールとその依存関係をアップグレードする方法について説明します。

アップグレード手順の一環として、Kf のインストールで Kf オペレーターの最新バージョンが使用されていることを確認してください。

現在の Kf バージョンを Kf v2.4.1 にアップグレードできることを確認します。
Kf v2.4.1 にアップグレードします。
依存関係をアップグレードします（必要な場合）。

始める前に

以下のものが必要になります。

Kf がインストールされた既存のクラスタ。
gcloud、kf、kubectl がインストールされているマシンへのアクセス権。

アップグレードの準備を行う

ターゲットクラスタに接続する

gcloud container clusters get-credentials CLUSTER_NAME \
 --zone CLUSTER_ZONE \
 --project CLUSTER_PROJECT_ID

現在の Kf CLI とサーバーバージョンが一致していることを確認する

kf debug を実行して、Kf CLI のバージョンと Kf サーバーのバージョンが一致していることを確認します。

CLI のバージョンは Kf Client に表示されます。
Kf サーバーのバージョンは kf["app.kubernetes.io/version"] に表示されます。

$ kf debug
...
Version:
  Kf Client:                        v2.3.2
  Server version:                   v1.20.6-gke.1000
  kf["app.kubernetes.io/version"]:  v2.3.2
...

Kf クライアントと Kf サーバーの値が一致しない場合で、サーバーのバージョンが v2.3.x の場合は、Kf v2.4.1 CLI をインストールしてから手順をすすめます。

Kf サーバーの値が v2.3.x より古い場合、手順を進めるために、まずは Kf v2.3.x に段階的にアップグレードする必要があります。

アップグレードする前に Kf が正常であることを確認する

kf doctor を実行して、クラスタの状態を確認します。次に進む前に、すべてのテストに合格していることを確認してください。

$ kf doctor
...
=== RUN doctor/user
=== RUN doctor/user/ContainerRegistry
--- PASS: doctor/user
   --- PASS: doctor/user/ContainerRegistry
...

FAIL または Error: environment failed checks というメッセージが表示される場合は、kf doctor 出力のガイダンスに従うか、トラブルシューティングガイドを確認して問題を解決し、成功するまでコマンドを再試行します。

必要に応じて Kf ConfigMap をバックアップする（カスタマイズを行った場合）

次のコマンドを実行して config-defaults ConfigMap のバックアップを作成します。
```
kubectl get configmap config-defaults -o yaml -n kf > config-defaults-backup.yaml
```
次のコマンドを実行して config-secrets ConfigMap のバックアップを作成します。
```
kubectl get configmap config-secrets -o yaml -n kf > config-secrets-backup.yaml
```
注: このバックアップは参照専用であり、直接利用することはできません。

Kf オペレーターをアップグレードする

Kf オペレーターは、最初にバージョン 2.4.0 の一部としてリリースされました。

2.4.0 のインストールの一部として Kf オペレーターをすでにインストールしている場合、2.4.1 へのアップグレードで Kf オペレーターをアップグレードします。

Kf オペレーターをアップグレードするをご覧ください。
2.3.2 からアップグレードする場合は、オペレーターマネージド Kf にアップグレードために、Kf オペレーターのバージョン 2.4.1 をインストールする必要があります。

Kf オペレーターをインストールするをご覧ください。

現在の Kf オペレーターをアップグレードする

Kf オペレーターをアップグレードします。

オペレーター yaml を適用します。

注: この処理はすぐに開始します。元に戻すことはできません。
```
kubectl apply -f "https://storage.googleapis.com/kf-releases/v2.4.1/operator.yaml"
```

Kf オペレーターを初めてインストールする

オペレーターマネージド Kf にアップグレードするには、次の手順を行います。

オペレーター yaml を適用します。

注: この処理はすぐに開始します。元に戻すことはできません。
```
kubectl apply -f "https://storage.googleapis.com/kf-releases/v2.4.1/operator.yaml"
```
デフォルトを使用するか、カスタマイズを維持するかを選択します。

注: いずれかを選択してください。両方とも完了することはしないでください。
1. デフォルトを使用してアップグレードする場合は、kfsystem.yaml を準備します。
  
  注: config-defaults または config-secrets にカスタマイズを行っていない場合は、次の手順を行います。
  kfsystem.yaml ファイルをダウンロードして、以下の変数を入力します。ファイルと同じディレクトリでコマンドを実行して、アップグレード用の kfsystem.yaml を自動的に準備します。
```
export CLUSTER_PROJECT_ID=YOUR_PROJECT_ID
export CLUSTER_NAME=YOUR_CLUSTER_NAME
export CONTAINER_REGISTRY=YOUR_CLUSTER_COMPUTE_REGION-docker.pkg.dev/${CLUSTER_PROJECT_ID}/${CLUSTER_NAME}

kubectl apply -f kfsystem.yaml

kubectl patch \
kfsystem kfsystem \
--type='json' \
-p="[{'op': 'replace', 'path': '/spec/kf', 'value': {'enabled': true, 'config': {'spaceContainerRegistry': '${CONTAINER_REGISTRY}', 'secrets':{'workloadidentity':{'googleserviceaccount':'${CLUSTER_NAME}-sa', 'googleprojectid':'${CLUSTER_PROJECT_ID}'}}}}}]"
```
2. カスタマイズを維持しながらアップグレードする場合は、kfsystem.yaml を準備します。
  
  注: config-defaults または config-secrets にカスタマイズを行った場合は、次の手順を行います。kfsystem.yaml の対応するフィールドに手動で保存する必要があります。
  1. kfsystem.yaml ファイルをダウンロードします。
  2. 次のコマンドを実行して config-defaults ConfigMap のバックアップを作成します。
```
kubectl get configmap config-defaults -o yaml -n kf > config-defaults-backup.yaml
```
  3. 次のコマンドを実行して config-secrets ConfigMap のバックアップを作成します。
```
kubectl get configmap config-secrets -o yaml -n kf > config-secrets-backup.yaml
```
  4. 現在の config-defaults と config-secrets configmap を調べて、kfsystem.yaml で対応する設定を確認してください。
  5. config-secrets と config-defaults から既存の設定をコピーします。config-secrets と config-defaults のすべての設定は、kfsystem.yaml にあります。googleProjectId フィールドが必須になりました。
  6. wi.googleServiceAccount フィールドは config-secrets 内の完全なサービスアカウントですが、kfsystem の場合は接尾辞を削除する必要があります。たとえば、${CLUSTER_NAME}-sa@${CLUSTER_PROJECT_ID}.iam.gserviceaccount.com は kfsystem.yaml では ${CLUSTER_NAME}-sa になります。
  7. 設定をコピーしたら、kfsystem の enabled フィールドを true に変更します。
  8. 変更を kfsystem.yaml に保存します。
  9. Kf のオペレーターを構成します。
```
kubectl apply -f kfsystem.yaml
```

Kf の依存関係をアップグレードする

Tekton をアップグレードします。

kubectl apply -f "https://storage.googleapis.com/tekton-releases/pipeline/previous/v0.23.0/release.yaml"

Cloud Service Mesh をアップグレードします。

注: 1.9 より古いバージョンの Cloud Service Mesh を実行している場合は、このステップを完了してください。
1. Cloud Service Mesh 1.9 アップグレードガイドの手順を行います。
Config Connector をアップグレードします。

注: Kf v2.4.0 以降では、Config Connector が必須です。
警告: GKE アドオンのメソッドは、Kf ではサポートされていないため、Config Connector のインストールに使用しないでください。以下のカスタムインストール手順を使用してください。
1. 必要な Config Connector Operator の tar ファイルをダウンロードします。
  
  注: インストールバンドルは、Config Connector をアンインストールするために必要であるため、このバンドルのコピーを保管してください。
2. tar ファイルを解凍します。
```
tar zxvf release-bundle.tar.gz
```
3. クラスタに Config Connector Operator をインストールします。
```
kubectl apply -f operator-system/configconnector-operator.yaml
```
4. Config Connector を初めてインストールする場合は、Config Connector Operator を構成します。
  1. 次の YAML を configconnector.yaml というファイルにコピーします。
    警告: 以下の YAML の KF_SERVICE_ACCOUNT_NAME 変数は、${CLUSTER_NAME}-sa@${CLUSTER_PROJECT_ID}.iam.gserviceaccount.com で決まる完全なサービスアカウントに置き換えます。
```
# configconnector.yaml
apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnector
metadata:
# the name is restricted to ensure that there is only one
# ConfigConnector resource installed in your cluster
name: configconnector.core.cnrm.cloud.google.com
spec:
mode: cluster
googleServiceAccount: "KF_SERVICE_ACCOUNT_NAME" # Replace with the full service account resolved from ${CLUSTER_NAME}-sa@${CLUSTER_PROJECT_ID}.iam.gserviceaccount.com
```
  2. クラスタに構成を適用します。
```
kubectl apply -f configconnector.yaml
```
5. 続行する前に、Config Connector が完全にインストールされていることを確認します。
  - Config Connector は、すべてのコンポーネントを cnrm-system という名前の名前空間で実行します。次のコマンドを実行して、Pod の準備ができていることを確認します。
```
kubectl wait -n cnrm-system --for=condition=Ready pod --all
```
  - Config Connector が正しくインストールされている場合、出力は次のようになります。
```
pod/cnrm-controller-manager-0 condition met
```
    注: コントローラ Pod の起動に数分かかる場合があります。
6. Config Connector を初めてインストールする場合は、Workload Identity を設定します。
```
kubectl annotate serviceaccount \
--namespace cnrm-system \
--overwrite \
cnrm-controller-manager \
iam.gke.io/gcp-service-account=${CLUSTER_NAME}-sa@${CLUSTER_PROJECT_ID}.iam.gserviceaccount.com
```

Kf v2.4.1 CLI にアップグレードする

CLI をインストールします。
Linux
このコマンドを実行すると、システム上のすべてのユーザーに Kf CLI がインストールされます。Cloud Shell のタブに表示されている手順に沿ってインストールします。
```
gcloud storage cp gs://kf-releases/v2.4.1/kf-linux /tmp/kf
chmod a+x /tmp/kf
sudo mv /tmp/kf /usr/local/bin/kf
```
Mac
このコマンドを実行すると、システム上のすべてのユーザーに kf がインストールされます。
```
gcloud storage cp gs://kf-releases/v2.4.1/kf-darwin /tmp/kf
chmod a+x /tmp/kf
sudo mv /tmp/kf /usr/local/bin/kf
```
Cloud Shell
bash を使用している場合、このコマンドを実行すると、kf が Cloud Shell インスタンスにインストールされます。他のシェルの場合は手順の変更が必要になることがあります。
```
mkdir -p ~/bin
gcloud storage cp gs://kf-releases/v2.4.1/kf-linux ~/bin/kf
chmod a+x ~/bin/kf
echo "export PATH=$HOME/bin:$PATH" >> ~/.bashrc
source ~/.bashrc
```
Windows
このコマンドを実行すると、kf が現在のディレクトリにダウンロードされます。現在のディレクトリ以外の場所から呼び出す場合は、その場所をパスに追加します。
```
gcloud storage cp gs://kf-releases/v2.4.1/kf-windows.exe kf.exe
```
Kf CLI と Kf サーバーのバージョンが一致していることを確認します。
- CLI のバージョンは Kf Client に表示されます。
- Kf サーバーのバージョンは kf["app.kubernetes.io/version"] に表示されます。
```
$ kf debug
...
Version:
  Kf Client:                        v2.4.1
  Server version:                   v1.20.6-gke.1000
  kf["app.kubernetes.io/version"]:  v2.4.1
...
```

Kf が正常にアップグレードされたことを確認する

Kf オペレーターを初めてインストールした場合は、インストールされているオペレーターを確認します。
```
kubectl get deployment -n appdevexperience appdevexperience-operator
```
以下の出力例のようにオペレーターが表示されない場合は、Kf オペレーターを初めてインストールするの手順を確認してください。
```
NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
appdevexperience-operator   1/1     1            1           1h
```
doctor を実行して、新しくインストールされたバージョンが正常であることを確認します。
```
kf doctor --retries=20
```
このコマンドは、クラスタチェックを数回実行します。新しいコントローラの起動中は、何度か試行が失敗しても問題ではありません。

コマンドが「Error: environment failed checks」というメッセージで失敗した場合は、doctor 出力のガイダンスに従って問題を解決し、成功するまでコマンドを再試行します。

config-defaults または config-secrets をカスタマイズした場合は、引き継がれていることを確認します。

config-defaults-backup.yaml ファイルを kubectl diff -f config-defaults-backup.yaml と比較し、クラスタが引き続き正しく構成されていることを確認します。

たとえば、以前の Kf バージョンでの変更をすべて残し、次のバージョンの Kf にバンドルされている新しいビルドパックの使用を承認した場合は、次のようになります。

$ kubectl diff -f config-defaults-backup.yaml
diff -u -N /tmp/LIVE/v1.ConfigMap.kf.config-defaults /tmp/MERGED/v1.ConfigMap.kf.config-defaults
--- /tmp/LIVE/v1.ConfigMap.kf.config-defaults
+++ /tmp/MERGED/v1.ConfigMap.kf.config-defaults
@@ -131,6 +131,8 @@
     enable_route_services: false
   spaceBuildpacksV2: |
-    - name: new_buildpack
-      url: https://github.com/cloudfoundry/new-buildpack
     - name: staticfile_buildpack
       url: https://github.com/cloudfoundry/staticfile-buildpack
     - name: java_buildpack
exit status 1

検証手順が正常に完了すれば、クラスタが正常にアップグレードされたことになります。問題が発生した場合は、サポートページでガイダンスを確認してください。