Kubernetesの使い方を考えるうえでのポイント

できること

Pod を使って、複数のコンテナを同じ Minion (物理サーバ)にまとめる
ダウンしたコンテナを再起動する
ReplicationController で Pod の並列数を管理する
Service でエンドポイントを1つ用意し、各 Pod へのネットワークアクセスを一元的に管理する
- 各 Pod にはRoundRobinで振り分ける
コンテナごとに利用するリソースリミットを設定できる(CPU、メモリ)
Pod をヘルスチェックして、NGになったら切り離す

(今のところ)できないことと代替手段

ダウンしたコンテナを、元のデータを引き継いで別の Minion で起動する
- GCEのPersistentDiskを駆使すればあるいは…
Pod をヘルスチェックして、NGになったらfailoverする
- Pod ではなく Service を複数つくればいける
特定条件に合致した場合に Pod を特定の Minion に配置するようスケジューリングする
- ホストOSのスペックが異なる別Kubernetesクラスタを用意
同一 ReplicationController で別 Pod のコンテナ同士の通信
- Kubernetesの想定範囲外なので無理

Kubernetesの特徴

Pod を展開するのが得意
データに局所性をもたせるのは難しい
可用性の観点だと、restartはするけどfailoverはしない
- Service 配下にstatelessなAct-Actクラスタはうまくいく
- failoverクラスタはうまくいかない

結論1

いまのところKubernetes単体だと使いドコロ難しい。

MySQLを使おうとした時のお悩み

ユースケースとしてMySQLを使うことを考えてみます。

ReplicationController で「MySQLは5台ね！」とかしてみたいですよね。

ダガシカシ…

レプリケーションスレーブ構築上のお悩み

ReplicationController で「MySQLは5台ね！」とすると、 ReplicationController 内で Pod を複数生成する形になる。でもそれだと Pod ごと個別にIDが付与できないのが困る。

具体的にどう困るかというと、MySQLのserver-idが重複しないようにコントロールできない。

このあたりのクラスタグローバルなデータの管理はetcdでやるのが筋なので、server-idはetcdから取得するように仕込む必要があります。ちょっとつらみ。

マスター・スレーブ構成のお悩み

Kubernetesでは同じ ReplicationController 内であっても Pod 間の直接通信がうまく解決できないので、 MySQLでマスター・スレーブ構成にするためには、 guestbook exampleのRedisのように、 MySQLレプリケーションマスタ用の Service と ReplicationController 、 MySQLレプリケーションスレーブ用の Service と ReplicationController を用意する形になります。

なんかダサい。

マスターの冗長化のお悩み

前項のとおりマスターとスレーブの ReplicationController を分ける都合上、 MHAやmysqlfailoverなどを利用してスレーブを昇格させる方法が使えないです。

これは困った…と思いきや、MySQLレプリケーションマスタ用のMySQLのための Service を2つ作成し、その前段にHAProxyを置けばfailoverは実現できるかもしれません。

結論2

めんどくさい。 MySQLのクラスタをKubernetsで組むのは今のところやめたほうがいいです。

素直に、AWSならEC2かRDS、GCPならGCEかCloudSQLあたりを使いましょう。

じゃあKubernetesは何に使うのよ？

データの局所性の問題とかは分散環境の基本で鬼門だと思うので、まだちょっとそのへんに手を出すにはKubernetesはシンプルすぎるかなーという印象です。

GCEありきで考えると解決する問題がたくさんあるので、そのへんがポイントなのかなと思っています。

いいユースケースが浮かんだ方は教えてください。

Kubernetes

Kubernetesの使い方と使いドコロ