前回の続編になります。
はじめに
アップデート戦略
Kubernetes には素晴らしい、そして魅力的な機能がたくさんあります。僕が Kubernetes を学んで（現在進行形）一番良かったなと思えることは、Google（現在はCNCF）の一流の考え方を学ぶことができることです。書籍などから考え方を学ぶと同じように、Kubernetes から学ぶことができるのです。最も衝撃を受けたのがアプリケーション（コンテナ）のアップデート戦略です。
えっ？！アップデート！？って思われたかもしれませんが、ちょっと思い出して下さい。Goolge サービスで「バージョンアップのためシステム停止します」っていうお知らせを見聞きしたことあります？ないですよね。気が付くとGmailのレイアウト、機能がアップデートしてます。
僕はそこそこアプリケーション開発（オンプレ）に携わっていますが、
”アップデート＝システム停止”
に何の疑問を持つことなく過ごしてきました。そのため Kubernetes の RollingUpdate 戦略を知ったとき、そしてさらっとアップデート前後の互換性はもたせるのは当たり前ですよね的な言葉を目にしたときは、マジか！？と衝撃が走りました。世界でサービス提供している人たちの当たり前ってスゲーなと。これ以降サービスを調査するときにアップデート戦略も意識しています。クラウドサービスにガンガン携わっている方々には当たり前かもしれませんが、きっと僕のような人も少なからずいると思うのでちょっと他のアップデート戦略についても紹介します。
Blue-Green デプロイメント
２つの同じ環境（Blue・Green）を使用します。現在、Blue がアクティブ環境の場合は、Green 環境でアップデートの準備をして問題なければ、Blue ⇒ Green にスワップして Green がアクティブ環境になります。
Azure Web Apps
Azure でサーバーレスを実現できる Azure Web Apps を具体例にします。
ステージング デプロイ スロット
Azure Web Apps には ”運用スロット” と ”デプロイ スロット” の機能があり、デプロイ スロットでアプリケーションの変更を検証した後、運用スロットにスワップすることができます。また、自動スワップ を構成することで自動化できます。そして、スワップした後に何らかの問題があった場合は、前の環境が残っているため環境を戻す（いわゆるフェールオーバー）動作も可能です。
Kubernetes のうれしいこと
次が今回のメインである Kubernetes のうれしいことです。
- 障害時のセルフヒーリング
- コンテナの死活監視
- ロードバランス
- 宣言的設定（Infrastracture as code）
- 簡単なスケーリング
- アップデート方法
上記以外にも ”イミュータブルな設計との相性の良さ” 、”疎結合” などなど、たくさんありますが、今回はこの６つのうれしいことを簡単に紹介します。
障害時のセルフヒーリング
Kubernetes はセルフヒーリング（自己回復）するシステムです。望ましい状態を常に継続させます。どういうことかというと、nginx コンテナが３つ動作しているのが望ましい状態としてマニフェストファイルを定義してデプロイを実行すると、Kubernetes は常に nginx コンテナが３つ動作している状態を継続します。
- 間違ってある1つの nginx コンテナを削除してしまった
- 何らかの障害により nginx コンテナが応答しなくなった
- ホストに何らかの障害が発生して nginx コンテナの動作継続が不可になった
上記が発生した場合でも Kubernetes は nginx コンテナが３つ動作するようセルフヒーリングします。詳細は次回以降で予定しているPod 、ReplicaSetの記事の中で体験（ハンズオン）していきたいと思います。
ReplicaSet のセルフヒーリング（自己回復） については ↓ の記事で紹介しています。
コンテナの死活監視
”1. 障害時のセルフヒーリング” で ”何らかの障害によりコンテナが応答しなくなった” という例を挙げました。この応答しなくなったことを判断する死活監視のヘルスチェック機能が Kubernetes にはあります。
Liveness probe
”Liveness probe” はコンテナ（アプリケーション）が起動しているかどうかを監視する機能です。これは、コンテナ単位で定義します。”Liveness probe” に失敗したコンテナは再起動が実行されます（セルフヒーリング）
Readiness probe
”Readiness probe” はコンテナ（アプリケーション）が応答できるかどうかを監視する機能です。コンテナがユーザからのリクエストを処理可能であることを表します。
Kubernetes の基本となる Pod （前編）については ↓ の記事で紹介しています。
Pod （後編）のヘルスチェックについては ↓ の記事で紹介しています。
ロードバランス
Kuberbetesの ”サービスディスカバリ” は Service オブジェクトから始まります。
サービスディスカバリとは
何かを見つけるという問題とその解決策を一般に、サービスディスカバリと呼びます。サービスディスカバリツールは、どのプロセスがどのアドレスでどのサービスのために待ち受けているのかを見つける際に起きる問題を解決します。よいサービスディスカバリのサービスを使うと、ユーザはこの手の情報をすばやく確実に見つけられるようになります。よいシステムには、関連づけられたサービスに変更があると情報がすぐに更新される、つまりレイテンシが低いという特徴もあります。
Service オブジェクトは ”サービスディスカバリ” と ”ロードバランス” の役割を担っています。そして ”Publishing services” として 次の ”type” があります。
- ClusterIP
- NodePort
- LoadBalancer
- ExternalName
他にも目的に応じて”Headless services”、”Ingress”といったService オブジェクトがあります。詳細は次回以降で予定している Service の記事の中で体験（ハンズオン）していきたいと思います。
宣言的設定（Infrastracture as code）
宣言的設定（Infrastracture as code）については、以前の記事で紹介しています。”Infrastracture as code” って何？？という方は、良ければご覧ください。
簡単なスケーリング
”障害時のセルフヒーリング” の例にした nignx コンテナを３⇒４にする変更も簡単にできます。またオートスケーリング機能もあります。より細かなスケジューリングする場合には、例えば ”ディスクI/Oが多い”、”特定のコンテナとの通信が多い” といったようなワークロードや、Docker ホストのスペックによる ”ディスクがSSD”、”CPUのクロック数が高い” といったような 、affinityやanti-affinityを意識して行うことも可能です。
アップデート方法
Recreate
これは僕が経験してきたアップデートとほぼ同様の考え方です。動作している Pod （コンテナ）を削除して、新しい Docker イメージから Pod をデプロイする方法です。つまり Pod が起動するまでの短いダウンタイムが発生します。しかし、忘れてはいけないのが Docker のメリットの１つである携帯性です。検証済みのイメージであれば、このメリットは大きいですよね。
RollingUpdate
アップデート中に許容される不足 Pod 数（maxUnavailable）と超過 Pod 数（maxSurge）を設定可能です。これらを駆使することで、リソースを余分に使わないようにしたり、リソースを多く消費する代わりにすばやく切り替えたりと、アップデート時の挙動を制御できるようになります。
簡単に言うと Pod（コンテナ）の動作を継続しながら、アップデートを実行するというダウンタイムなしの戦略です。詳細は次回以降で予定している Deployment の記事の中で体験（ハンズオン）していきたいと思います。
まとめ
いかがだったでしょうか。初心者の方にも Kubernetes のうれしいことが分かるように、Kubernetes だとこんなことができるよっていうのを簡単に紹介しました。他にも ”Label（Selector として使用）” など重要なオブジェクトはありますが、ハンズオン形式で体験する方が理解しやすいと思ったため、今回は載せていません。知れば知るほど Kubernetes から新しい発見があり勉強になります。 この６つのうれしいことで Kubernetes に興味が湧いてきた方がいらしゃれば幸いです。
おススメ書籍
技術本を読むなら Kindle がおすすめです。こちらの記事をご覧ください。
1.6,5 のバージョンで解説（リポジトリ、注釈は翻訳時の最新1.9で更新）されています。バージョンは少し古いですが、初心者の入門書（おえるべきポイントはしっかり網羅されてる）としては、途中で挫折しない適度なボリューム（本の厚さ）で、とっかかりとしては良い本になっています。
僕は「入門 Kubernetes」⇒「Kubernetes完全ガイド」（現在進行形）という進み方をしていますが、より本番環境を想定した方法を学べます。特にWeb 系だと、https で使用する Ingress リソースなどもしっかり説明してくれています。「入門 Kubernetes」には、詳しい説明がなかったので個人的にはすごく助かっています。
