今回の第10章で扱う内容は以下の通りです。
- 高可用性（HA）の紹介
- 高可用性のベストプラクティス
- マルチリージョン設定
- セキュリティベストプラクティス
- ホステッドKubernetes PaaSにおける高可用性設定
- クラスターライフサイクルイベント
- アドミッションコントローラーの利用法
- ワークロードAPIの紹介
- カスタムリソース定義（CRD）とは何か？
高可用性（HA）
業界において高可用性とは、非常に高いレベルの可用性を意味し、一般的に「5つの9」（99.999%）の可用性と呼称されます。
基本的に可用性は以下のように計算されます。
可用性（パーセンテージ） = （稼働時間 / （稼働時間 + ダウンタイム）） x 100
稼働時間の可用性は以下の公式となります。
MTBF = 1年を時間換算した値 / 1年間の故障回数
MTTR = （故障回数 x システム修理時間） / 総故障回数
稼働時間可用性 = MTBF / （MTTR + MTBF）
年間ダウンタイム（1時間単位） = （1 - 稼働率） x 365 x 24
SLA（サービスレベル合意書）で保証される可用性のレベルは以下の通りです。
1. 可用性が99.9%の場合、年間ダウンタイム：8時間45分57.0秒
2. 可用性が99.99%の場合、年間ダウンタイム：52分35.7秒
3. 可用性が99.999%の場合、年間ダウンタイム：5分15.6秒
5つの9の可用性を保証するには、Kubernetesクラスターを極めて厳密に運用する必要があります。
HAベストプラクティス
高可用性を保証するKubernetesシステムを構築するには、「可用性は技術的なエラーと同じくらい、人間やプロセスに関する問題であることが多い」という点を理解しておくべきです。
まず知っておくべき用語があります。 段階的性能低下（グレースフル・デグラデーション） という概念です。
段階的性能低下とは、複数のレイヤーやモジュールに機能を分散して構築する概念です。システムの一部で致命的なエラーが発生しても、一定レベルの可用性を継続して提供します。
Kubernetesには2つの段階的性能低下の方法があります。
インフラの性能低下 ：この性能低下方式は、ハードウェアやVMの予期せぬエラーに対処するため、複雑なアルゴリズムやソフトウェアに依存します。この方式を提供するために必要なKubernetes必須コンポーネントの高可用性確保方法を探求します。
アプリケーションの性能低下 ：前述のマイクロサービスベストプラクティスの戦略に大きく依存しますが、ユーザーの成功を保証するためのいくつかのパターンが存在します。
中核となるKubernetes戦略を使用して基盤インフラの障害を分離しつつ、アプリケーションの障害に備えたキャッシング、フェイルオーバー、ロールバックのメカニズムを構築し、Kubernetesコンポーネントの高可用性を確保しなければなりません。
反脆弱性（アンチフラジャイル）
「反脆弱性」とは、一言で言えば、外部からの混乱や圧力に対して、むしろ成果が向上する性質を指します。
Kubernetesシステムの複雑さに対処し、大規模なKubernetesを活用してシステムを維持するには、いくつかの核となる概念を理解する必要があります。
1. 二重化（冗長化）
2. 障害シナリオを発生させ、それに対して対応・分析・探索・改善を行うこと。（NetflixのChaos Monkeyは、複雑なシステムの安定性をテストするための標準的かつ整理されたアプローチです https://github.com/Netflix/chaosmonkey ）
3. システムに適切なパターンを導入する。（リトライ、ロードバランシング、サーキットブレーカー、タイムアウト、ヘルスチェック、同時接続チェックは反脆弱性のための核となるパターンです。さらに高いレベルには、Istioなどのサービスメッシュがあります。 https://techcafe.tistory.com/133 ）
KubernetesのためのHAアプローチ
KubernetesのHA構成には、etcdと管理ノードを結合したスタックマスター方式と、etcdと管理ノードを分離した方式があります。
Kubernetesのインストール手順は省略します。
クラスターのライフサイクル
アドミッションコントローラー、ワークロード、CRDを使用してクラスターを拡張する方法を見ていきましょう。
アドミッションコントローラー
アドミッションコントローラーは、Kubernetes APIサーバーの認証と認可が完了した後、Kubernetes APIサーバーへの呼び出しを傍受できます。
以下の2つのアドミッションコントローラーが特に重要です。
MutatingAdmissionWebhook は、クラスターが変形（Mutation）段階にある場合にのみ実行され、リクエストを連続的に変形するウェブフックを呼び出します。CREATE、DELETE、UPDATEといった操作の承認ロジックをユーザー定義し、ビジネスロジックをクラスターに組み込む際にこのコントローラーを使用します。StorageClassを使用してストレージプロビジョニングを自動化するなどのタスクを実行可能です。
ValidatingAdmissionWebhook は、承認段階でアドミッションコントローラーが実行されます。クォータ増加を検証するウェブフックのように、「リクエストの妥当性」を検査するウェブフックを呼び出します。このコントローラーが呼び出すすべてのウェブフックは、元のオブジェクトを変形できないという点に留意する必要があります。
ワークロードAPI
Kubernetesの初期には、Podとワークロードは、CPU、ネットワーキング、ストレージ、ライフサイクルイベントを共有するコンテナと密接に結合されていました。Kubernetesは、クラウドアプリケーションの「12 Factor App」を管理できるようにレプリケーション、デプロイメント、ラベルなどの概念を導入し、Kubernetes運用者がステートフルなワークロードを扱えるようにStatefulSetを導入しました。
時間が経つにつれ、Kubernetesのワークロード概念は細分化されました。
Pod
ReplicationController
ReplicaSet
Deployment
DaemonSet
StatefulSet
これらの多様な要素は、Kubernetesがワークロードのタイプを合理的に調整した結果ですが、残念ながらKubernetesコードベースのあちこちにAPIが分散してしまいました。この問題を解決するため、後方互換性の一部を犠牲にするような数ヶ月にわたる努力の末、すべてのコードをapps/v1 APIに統合できました。
統合プロセスにおける重要な決定事項は以下の通りです。
デフォルトセレクター ：ラベルセレクターを指定しない場合、テンプレートラベルから抽出して自動生成したセレクターをデフォルト値として使用します。
不変セレクター ：セレクターの変更がDeploymentにとって有用な場合もありますが、セレクターを変形することはKubernetesの推奨事項と相反するため、KubernetesがオーケストレーションするカナリアリリースとPodラベルを付け替える方式に変更されました。
ローリングアップデート ：Kubernetesプログラマーからのリクエストにより、ローリングアップデートがデフォルトになりました。
ガベージコレクション ：1.9バージョンとapps/v1バージョンでは、ガベージコレクションがより攻撃的（積極的）になっています。DaemonSet、ReplicaSet、StatefulSet、Deploymentを削除すると、Podも削除されます。
カスタムリソース定義（CRD）
カスタムリソースは、Kubernetes APIを拡張し、アドミッションコントローラーを補完します。運用中のKubernetesクラスターを改善するためにカスタムリソースを使用できます。
以下のような機能を適用できます。
| CRUD | 新しいエンドポイントは、HTTPとkubectlを介したCRUD基本操作をサポートします。 |
| Watch | 新しいエンドポイントは、HTTPを介したKubernetes Watch操作をサポートします。 |
| Discovery | kubectlやダッシュボードのようなクライアントは、自動的にリソースのリスト表示、表示、フィールド編集操作を提供します。 |
| json-patch | 新しいエンドポイントは、Content-Type: application/json-patch+json を使用したPATCHをサポートします。 |
| merge-patch | 新しいエンドポイントは、Content-Type: application/merge-patch+json を使用したPATCHをサポートします。 |
| HTTPS | 新しいエンドポイントはHTTPSを使用します。 |
| Built-in Authentication | 拡張機能へのアクセスは、認証のためにコアAPIサーバー（アグリゲーションレイヤー）を使用します。 |
| Built-in Authorization | 拡張機能へのアクセスは、コアAPIサーバーで使用される認可（RBACなど）を再利用できます。 |
| Finalizers | 外部のクリーンアップが完了するまで、拡張リソースの削除をブロックします。 |
| Admission Webhooks | 任意の作成/更新/削除操作中に、拡張リソースのデフォルト値を設定し、妥当性を検証します。 |
| UI/CLI Display | Kubectlやダッシュボードで拡張リソースを表示できます。 |
| Unset versus Empty | クライアントは、未設定のフィールドとゼロ値のフィールドを区別できます。 |
| Client Libraries Generation | Kubernetesは汎用クライアントライブラリを提供しており、タイプ別のクライアントライブラリを生成するツールも提供しています。 |
| Labels and annotations | ツールがコアリソースやカスタムリソースに対して編集方法を認識している、オブジェクト共通のメタデータです。 |