アプリのライフサイクルの管理

Kubernetes ネイティブのツールやサード・パーティーのツールを使用して、ユーザーにダウン時間を強いることなくアプリのローリング更新やロールバックを実行できます。

更新の戦略

アプリを更新するには、以下のようなさまざまな戦略から選択できます。最初はローリング・デプロイメントや即時切り替えから始めて、その後で複雑なカナリア・デプロイメントに進むことができます。

ローリング・デプロイメント: Kubernetes 固有の機能を使用して、v2 デプロイメントを作成したり、以前の v1 デプロイメントを段階的に置き換えたりできます。この手法を使用する場合は、v2 アプリ・バージョンを使用するユーザーに互換性を破る変更を発生させないよう、アプリが後方互換性を備えている必要があります。詳しくは、アプリを更新するためのローリング・デプロイメントの管理を参照してください。
即時切り替え: 即時切り替え (ブルー/グリーン・デプロイメントとも呼ばれます) では、同じアプリの 2 つのバージョンを同時に実行するために通常の 2 倍のコンピュート・リソースが必要になります。この手法を使用すると、ほぼリアルタイムでユーザーを新しいバージョンに切り替えることができます。サービスラベルセレクタ version: green version: blue など）を使用して、リクエストが正しいアプリバージョンに送信されることを確認してください。新しい version: green デプロイメントを作成して、このデプロイメントの準備が完了するまで待ってから、version: blue デプロイメントを削除できます。あるいは、ローリング更新を実行できますが、その場合は maxUnavailable パラメーターを 0% に設定して、maxSurge パラメーターを 100% に設定します。
カナリア・デプロイメントまたは A/B デプロイメント: さらに複雑な更新戦略であるカナリア・デプロイメントでは、指定した比率 (5% など) のユーザーのみが新しいアプリ・バージョンを利用できるようにします。新しいアプリ・バージョンのパフォーマンスに関するメトリックをロギング・ツールとモニタリング・ツールで収集し、A/B テストを実行してから、より多くのユーザーに更新をロールアウトします。他のデプロイメント方式と同様に、アプリにラベル (version: stable や version: canary など) を割り当てることが非常に重要です。 To manage canary deployments, you might マネージドIstioアドオンサービスメッシュのインストール,クラスタにMonitoringを設定する, and then use the Istio service mesh for A/B testing as described このブログ記事で.

アプリのスケーリング

Kubernetesでは、水平ポッドオートスケーリングを有効にして、CPUに基づいてアプリのインスタンス数を自動的に増減できる。

ポッドではなく、ワーカー・ノードのスケーリングが必要ですか? cluster autoscaler を確認してください。

開始前に

アカウントにログインします。該当する場合は、適切なリソース・グループをターゲットにします。クラスターのコンテキストを設定します。
名前空間内の Kubernetes リソースを処理できる適切な Kubernetes RBAC 役割を付与する、サービス・アクセス役割が自分に割り当てられていることを確認します。

アプリを拡張する

CLI を使用して、アプリをクラスターにデプロイします。デプロイメントがかなり複雑になる場合は、構成ファイルを作成する必要があります。
```
kubectl create deployment <app_name> --image=<image>
```
デプロイメントで実行するコンテナーの CPU リソース制限をミリコア単位で設定します (100m など)。メモリー制限も設定できますが、水平ポッド自動スケーリング機能がスケーリングの目的で考慮するのは、CPU リソースの制限だけです。詳しくは、kubectl set resources のドキュメントを参照のこと。
```
kubectl set resources deployment <app_name> --limits=cpu=100m
```

水平ポッド自動スケーリング機能を作成し、ポリシーを定義します。詳細については、kubectl autoscale の資料を参照してください。

kubectl autoscale deployment <deployment_name> --cpu-percent=<percentage> --min=<min_value> --max=<max_value>

コマンドオプションを理解する
オプション	説明
`--cpu-percent`	水平ポッド自動スケーリング機能で維持する CPU 使用率の平均値。パーセントで指定します。
`--min`	指定した CPU 使用率を維持するために使用するデプロイ済みのポッドの最小数。
`--max`	指定した CPU 使用率を維持するために使用するデプロイ済みのポッドの最大数。

アプリを更新するためのローリング・デプロイメントの管理

ポッド・テンプレート (デプロイメントなど) を使用するワークロードの場合、自動化されて制御された方法で、アプリ変更のロールアウトを管理できます。ロールアウトがプランに従ったものでない場合、デプロイメントを以前のリビジョンにロールバックできます。

ローリング更新中のダウン時間を回避したいですか? デプロイメントで Readiness Probe を指定してください。こうすることで、ロールアウトは、最後に更新されたポッドの準備完了後に、次のアプリ・ポッドに進むようになります。

開始前に

アカウントにログインします。該当する場合は、適切なリソース・グループをターゲットにします。クラスターのコンテキストを設定します。
デプロイメントを作成します。
名前空間内の Kubernetes リソースを処理できる適切な Kubernetes RBAC 役割を付与する、サービス・アクセス役割を持っていることを確認します。

アプリのローリング更新を管理するには、以下のようにします。

コンテナーが実行中で、かつ要求に対処する準備が整っている場合にのみ、デプロイメントに準備完了のマークが付けられるようにするには、デプロイメントに Liveness Probe と Readiness Probe を追加します。
ローリング更新中の急増ポッドと使用不可ポッドの最大数またはポッドのパーセンテージを指定するローリング更新戦略が組み込まれるように、デプロイメントを更新します。
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
spec:
  replicas: 10
  selector:
    matchLabels:
      service: http-server
  minReadySeconds: 5
  progressDeadlineSeconds: 600
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 50%
      maxSurge: 2
...
```
spec.minReadySeconds

デフォルトでは、デプロイメントはポッドに ready のマークが付くまで待機してからロールアウトを続行します。最新のポッドのアプリの準備が整っていないにもかかわらず、デプロイメントによるポッドの作成が続行する場合は、このフィールドを使用して、デプロイメントのロールアウトをスローダウンします。例えば、5 を指定すると、デプロイメントは、ポッドが ready になった後 5 秒待機してから次のポッドを作成します。

spec.progressDeadlineSeconds

デプロイメントが失敗したと見なされてタイムアウトになるまでの秒数を設定します。例えば、タイムアウトにならなければ、新しいアプリ・バージョンにバグがあり、即時にハングした場合、ポッドが ready 状態に達することがないため、ロールアウトを続行できません。このタイムアウトを 600 秒に設定して、ロールアウトのいずれかの段階で 10 分間進行がない場合、デプロイメントには失敗のマークが付けられ、ロールアウトは停止します。

spec.strategy.type

RollingUpdate 戦略タイプを指定します。

spec.strategy.rollingUpdate.maxUnavailable

更新中に使用不可になってもよいポッドの最大数を数値 (2) またはパーセンテージ (50%) で設定します。通常、ロールアウトで一度に使用不可にできるポッドを 1 つのみに制限する場合を除き、後でレプリカの数を変更したときにこの数値を覚えていて更新しなくてもよいように、パーセンテージを使用します。 100％以下にならないようにするには、この値を 0% に設定し、spec.strategy.type.rollingUpdate.maxSurge パラメータを指定する。

spec.strategy.rollingUpdate.maxSurge

ロールアウト中にデプロイメントで使用できる追加のリソース数を数値 (2) またはパーセンテージ (50%) で設定します。例えば、10 レプリカが指定されたデプロイメントで、maxSurge を 2 に設定した場合、ロールアウト中に 2 つの新規レプリカが作成されます。この時点で、12 のレプリカ (既存 10、新規 2) があります。 2 つの新規レプリカの準備が整うと、指定された 10 レプリカに合わせて、デプロイメントがスケール・ダウンして、古いレプリカが 8 つになります。このプロセスは、ロールアウトが完了して、10 レプリカすべてが新規バージョンで実行されるまで続きます。

blue-green 即時切り替えスタイルの更新を実行する場合は、maxSurge を 100% に設定します。デプロイメントでは、すべての新規必須レプリカを作成した後、古いバージョンのレプリカを 0 にスケール・ダウンします。
変更をロールアウトします。例えば、初期デプロイメントで使用したイメージを変更することができます。
1. デプロイメント名を取得します。
```
kubectl get deployments
```
2. ポッド名を取得します。
```
kubectl get pods
```
3. ポッドで実行するコンテナーの名前を取得します。
```
kubectl describe pod <pod_name>
```
4. 使用するデプロイメントの新しいイメージを設定します。
```
kubectl set image deployment/<deployment_name><container_name>=<image_name>
```
コマンドを実行すると、変更がすぐに適用され、ロールアウトの履歴にログが記録されます。
デプロイメントの状況を確認します。
```
kubectl rollout status deployments/<deployment_name>
```
状況の中に、詳しく調べるために時間が必要な個所がある場合は、以下のコマンドを使用して、ロールアウトを一時停止したり再開したりできます。
```
kubectl rollout pause deployment <deployment_name>
```
```
kubectl rollout resume deployment <deployment_name>
```
変更をロールバックします。
1. デプロイメントのロールアウト履歴を参照し、最後のデプロイメントのリビジョン番号を確認します。
```
kubectl rollout history deployment/<deployment_name>
```
  ヒント: 特定のリビジョンの詳細を表示するには、リビジョン番号を指定します。
```
kubectl rollout history deployment/<deployment_name> --revision=<number>
```
2. 以前のバージョンにロールバックするか、またはリビジョンを指定します。以前のバージョンにロールバックするには、次のコマンドを使用します。
```
kubectl rollout undo deployment/<depoyment_name> --to-revision=<number>
```

継続的統合/継続的デリバリーのセットアップ

IBM Cloud およびその他のオープン・ソース・ツールを使用して、継続的統合/継続的デリバリー (CI/CD)、バージョン管理、ツール・チェーンなどをセットアップすることで、アプリの開発とデプロイメントを自動化できます。

サポートされている統合のリストおよび継続的デリバリーのパイプラインをセットアップする手順については、継続的統合/継続的デリバリーのセットアップを参照してください。

別のクラスターへのデプロイメントのコピー

クラスタ内で Gitなどのバージョン管理システム、kustomize などの構成管理プロジェクト、Razeeなどの継続的デリバリ・ツールを使用すると、アプリの構成ファイルをクラスタ間で迅速にデプロイできます。時により、クラスターでテストした数個のデプロイメントを、別のクラスターにコピーして再デプロイしたい場合があります。

始めるには、2 つのクラスターが必要です。また、一方のクラスターのすべてのリソースをもう一方のクラスターにコピーしてデプロイできるように、両方のクラスターのすべての名前空間に対して管理者のサービス・アクセス役割を持っている必要もあります。

アカウントにログインします。該当する場合は、適切なリソース・グループをターゲットにします。クラスターのコンテキストを設定します。

クラスターの構成ファイルすべてをリストし、それらの構成をコピーする必要があることを確認します。

kubectl get all

出力例

NAME                                   READY   STATUS             RESTARTS   AGE
pod/java-web-6955bdbcdf-l756b          1/1     Running            0          59d

NAME                                   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
service/java-web                       NodePort    172.21.xxx.xxx   <none>        8080:30889/TCP   59d

NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/java-web               1/1     1            1           59d

NAME                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/java-web-6955bdbcdf    1         1         1       59d

クラスターの構成ファイルをローカル・ディレクトリーにコピーします。 --export は設定ファイルからクラスタ固有の情報を削除する。
```
kubectl get all -o yaml --export > myconfigs.yaml
```
アカウントにログインします。該当する場合は、適切なリソース・グループをターゲットにします。クラスターのコンテキストを設定します。
オプション：クラスタが複数のネームスペースを使用していた場合は、標準クラスタに同じネームスペースを作成し、イメージのプルシークレットを各ネームスペースにコピーします。
コピーした構成ファイルをクラスターにデプロイします。適用できない固有の情報が構成ファイルに含まれている場合は、構成ファイルを更新して再適用する必要があります。
```
kubectl apply -f myconfigs.yaml
```
出力例
```
pod/java-web-6955bdbcdf-l756b created
service/java-web created
deployment.apps/java-web created
replicaset.apps/java-web-6955bdbcdf created
```
構成ファイルが適用されたことを確認します。
```
kubectl get all
```