Kubernetes the Hard Way とは、イチから Kubernetes クラスタを組んで勉強しようというもの。
多分 kelseyhightower 氏のこちらの資料が元祖。
今回は冗長構成で組むので、冗長構成でクラスタを組む際の基礎的な話をまとめる。

冗長構成

マルチマスターのときの動き

API Server

Active-Active で動くことができる。
ロードバランサのバックなどに入れてリクエストを両方で受け付けることが可能。

Scheduler と Controller Manager

Active-Standby で動く。
Leader Election という機能により Active 側が定められる。
Controller Manager であれば --leader-elect true といったオプションで指定する。
これにより、エンドポイント側でどちらが Active かを判断し、リクエストを送ることが出来る。

etcd

Stacked Topology

マスターノード内に etcd の pod も一緒に作成する方式。
簡単だが、データロストの可能性などもある。

External ETCD Topology

マスターノードの外に etcd のサーバを配置する。
API Server の設定時に、どこに etcd server があるかを指定する必要がある。

etcd HA mode

Consistency

etcd では、すべてのノードに Read と Write が書き込み可能。では、どうやって consistency を保証するのか。

Write は、それぞれのノード上で処理されるものではない。
前提として、etcd クラスタには leader と follower が存在している。
リクエストが follower に届くと、内部的には leader に送られて処理される。
その後、leader が Write を各ノードに情報を配信し、Write の処理が行われる。
つまり、実質的に Write を行えるのは leader だけである。

一部のノードが受け取れなかった場合は、リーダーを含めてマジョリティな数だけ書き込みが完了すると Write を成功と扱う。
Quorum = N/2 + 1 の式で「マジョリティな数」を決める。
この式を考慮すると、「落ちても問題ないノード」を用意するには最低でも 3 ノード以上必要となる。

Leader Election

RAFT と呼ばれる仕組みで実現されている。
ランダムタイマーで自分がリーダーになるリクエストが送信され他のノードからのレスポンスを受け取るとリーダーが選出される。
リーダーからの notification が来なくなると、再度ランダムタイマーでリクエストが送信される。(re-election プロセス)