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
```
Kf の最新バージョンをダウンロードページで探します。

警告: 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-line」の下にあるコマンドを実行して、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