Kf のアップグレード

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

始める前に

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

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

既存の Kf インストールを検証する

クラスタとやり取りするために必要な認証情報を取得します。

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

kf debug を実行して、Kf CLI のバージョンと Kf サーバーのバージョンが一致していることを確認します。
- CLI のバージョンは Kf Client に表示されます。
- Kf サーバーのバージョンは kf["app.kubernetes.io/version"] に表示されます。
```
$ kf debug
...
Version:
  Kf Client:                        v2.0.0
  Server version:                   v1.17.13-gke.1401
  kf["app.kubernetes.io/version"]:  v2.0.0
...
```
Kf クライアントと Kf サーバーの値が一致していない場合、サーバーのバージョンに一致する Kf CLI のバージョンをダウンロードしてインストールし、新しい CLI で再度確認します。CLI のバージョンとサーバーのバージョンを一致させてから次に進む必要があります。
kf doctor を実行して、クラスタの状態を確認します。次に進む前に、すべてのテストに合格していることを確認してください。
```
$ kf doctor
...
=== RUN doctor/user
=== RUN doctor/user/ContainerRegistry
--- PASS: doctor/user
   --- PASS: doctor/user/ContainerRegistry
...
```
「Error: environment failed checks」というメッセージが表示された場合は、doctor 出力のガイダンスに沿って問題を解決し、成功するまでコマンドを再試行します。

アップグレード

Kf をアップグレードするには、次の手順を行います。

ローカル環境とアップグレードの準備を行います。
Kf の依存関係をアップグレードします。
Kf をアップグレードし、アップグレードが成功したことを検証します。

アップグレードを準備する

kf version を実行して、Kf の現在のバージョンを取得します。
```
$ kf version
kf version v2.0.0 linux
```
そのバージョンよりも 1 つ上のバージョンをダウンロードページで探します。

警告: 現在、Kf は、マイナーバージョンを 1 つずつアップグレードする必要があります。たとえば、v2.0.0 から v2.1.0 へのアップグレードなどです。
1. Kf リリースの YAML ファイルをダウンロードして、kf-release.yaml として保存します。
2. 使用している OS 用の Kf のバージョンをダウンロードし、kf-next という名前を付けます。
3. chmod を実行して、kf-next を実行可能にします。
```
chmod +x kf-next
```
4. kf-next version を実行して、ダウンロードしたバージョンがインストールする Kf のバージョンと一致していることを確認します。
```
$ kf-next version
kf version v2.1.0 linux
```
次のコマンドを実行して config-defaults ConfigMap のバックアップを作成します。
```
kubectl get configmap config-defaults -o yaml -n kf > config-defaults-backup.yaml
```
注: このバックアップは参照専用であり、直接利用することはできません。
kubectl diff -f kf-release.yaml を実行して、アップグレードによってクラスタに加えられた変更を確認します。

注: config-defaults ConfigMap をよく確認してください。Kf ではこの ConfigMap を使用して、ドメイン、機能フラグ、コンテナレジストリなど、クラスタ全体のカスタマイズを保存します。
引き続き使用する変更内容を残しておくには、kf-release.yaml をエディタで変更します。

たとえば、Kf の v2.0.0 で config-defaults ConfigMap プロパティ spaceDefaultToV3Stack を false に設定している場合に、v2.1.0 リリースのデフォルト値では true になっていることがあります。
再度 kubectl diff -f kf-release.yaml を実行し、加えた変更によって想定どおりの結果が得られることを確認します。

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

ダウンロードページを開き、アップグレード後の Kf のバージョンの依存関係マトリックスを探します。
Tekton をアップグレードします。
1. Tekton リリースページを開きます。
2. Kf の依存関係マトリックスに表示されている Tekton のバージョンを見つけます。
3. 「Installation one-liner」の下にあるコマンドを実行して、Tekton をアップグレードします。
Anthos Service Mesh をアップグレードします。
1. Anthos Service Mesh アップグレードガイドを開きます。
2. バージョンのプルダウンで、Kf 依存関係マトリックスに表示されている Anthos Service Mesh のバージョンを選択します。
3. ガイドに沿って ASM をアップグレードします。

Kf をアップグレードして検証する

変更したリリース構成を使用して、アップグレードされた Kf コンポーネントをインストールします。
```
kubectl apply -f kf-release.yaml
```
doctor を実行して、新しくインストールされたバージョンが正常であることを確認します。
```
kf-next doctor --retries=12 --delay=5s
```
このコマンドは、クラスタチェックを数回実行します。新しいコントローラの起動中は、何度か試行が失敗しても問題ではありません。

コマンドが「Error: environment failed checks」というメッセージで失敗した場合は、doctor 出力のガイダンスに従って問題を解決し、成功するまでコマンドを再試行します。
システム上の既存の kf CLI を kf-next CLI に置き換えます。
```
chmod +x kf-next
mv kf-next $(which kf)
```
注: Kf がグローバルにインストールされている場合は、sudo を使用してスーパーユーザーとしてこのコマンドを実行する必要が生じることがあります。

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