GKEのベスト・プラクティス :可用性の高いクラスターの設計と構築（後半）

GKEのクラスター設計についての記事です。長いので前半と後半の二回に分けて投稿します。今回は後半です。

Correctly set up your deployment

アプリケーションはそれぞれ異なる特徴を持っています。あるものはバッチワークロード、あるものはステートレスなマイクロサービス、あるものはステートフルなデータベースをベースにしています。アプリケーションの制約をKubernetesに認識させるために、Kubernetes Deploymentsを使ってワークロードを管理することができます。Deploymentは望ましい状態を記述し、Kubernetesのスケジュールと連動して実際の状態を望ましい状態に合わせて変更します。

Is your application stateful or not?

あなたのアプリケーションはステートフルですか、それともそうではありませんか？

データベースなど、セッション間で状態を保存する必要があるアプリケーションであれば、ステートフルなアプリケーション特有の特性を適切に処理する方法で1つ以上のポッドを管理・維持するKubernetesコントローラであるStatefulSetの使用を検討してください。これは、ReplicaSetsやDeploymentsのようなポッドを管理する他のKubernetesコントローラと似ています。しかし、Deploymentsとは異なり、StatefulsetはPodが交換可能であることを前提としていません。

状態を維持するために、StatefulSetにはPersistent Volumes も必要で、ホストされたアプリケーションが再起動時にデータを保存・復元できるようにします。Kubernetesは、Cloud Storageの上の抽象化レイヤーとして、Storage Class、Persistent Volumes、Persistent Volume Claimsを提供しています。

Understanding Pod affinity

ポッドアフィニティについて

すべてのレプリカを同じノードでスケジューリングしたいですか？そのノードが故障したらどうなるでしょうか？一度にすべてのレプリカを失ってもいいのでしょうか？KubernetesのPodアフィニティとアンチアフィニティのルールを使えば、Podとそのレプリカの配置をコントロールすることができます。

単一障害点（Single Point of Failure）を回避するために、Pod anti-affinity を使用してKubernetesに同一ノード上にPodを配置しないように指示します。ステートフルなアプリケーションの場合、特に正常に動作するために最低数のレプリカ（つまりクォーラム）を必要とする場合、これは重要なコンフィグレーションとなります。