Kubernetes（AKS）をやさしく学ぶ旅 その10
更にディープな Kubernetes を学ぶ旅へ
その9 まではハンズオンを交えつつ記事にしていきましたが、以降はドキュメントサイトを参考にしつつアーキテクチャを学んでいく記事にします。幸いなことに昔に比べるとマイクロソフトのドキュメントは充実の一途を辿っており、基本はドキュメント先を見るだけでも十分学べると思います。笑
押さえた方がよい（と思う）アーキテクチャに関して
Reconciliation Loops
読了した本の共著の方でもあるマイクロソフトの真壁様の登壇資料（超良資料です！）でこのキーワードのことを詳しく解説されています。全画面で閲覧することをオススメします。
ネットワーク
読了した本で参考例として記載されていたのは kubenet と Azure SDN の話がメインでしたが、リンク先には CNI（Container Network Interface） のことも詳しく記載されています。大事なポイントとしては Kubernetes では Node 間だけでなく Pod 間の通信も視野に入れたネットワーク設計が必要になります。
可用性
「可用性」はこの業界にいるとよく聞くキーワードですが「システムが継続して稼働できる能力のこと」を指します。以前の記事にも記載している通りで Pod のレプリカ数を2以上に定義すれば複数の Node に Pod を分散できます。また Pod が動作している Node が NG になった際の挙動に関してもハンズオンしてみました。
視点を変えて、Kubernetes 本体（の可用性）を考えてみます。Kubernetes のコントロールを司るコンポーネント群は主に Master サーバー上に配置されます。（例：API Server / etcd / Controller Manager / Scheduler 等）
特に etcd はクリティカルな要素であり、それを冗長化するために Master サーバーを冗長化することが重要です。
ただし、注意点として前述の例で挙げた前2つは冗長化した環境においてアクティブ／アクティブですが後2つはアクティブ／スタンバイとなります。
後ろ2つは API Server 経由でウォッチされており、状態維持に努めるため、他とのオブジェクト操作に競合を起こさないようにアクティブ／スタンバイとしております。
Master と同様、Node の可用性も同じ構成のサーバーを増やすスケールアウトがベースのアプローチなようです。他は分散数等を考慮したりします。
拡張性
Kubernetes のアドオンとして開発されている Cluster Autoscaler が Node の水平自動スケール機能を担います。機能として「Pod に割り当て可能な空きリソースがどの Node を見てもない場合に、Node を追加する。」・「Node 追加後にクラスターのリソース利用率が下がったら Node を減らす。」を持っております。判断基準は「Pending の Pod」があるかです。詳しくは下記をご覧下さい。
柔軟な拡張性を活かすことで突発的なアクセス増に対応することが可能（ただし、スケールアウトには仮想マシン作成と Kubernetes のセットアップが必要なため、予めアクセス増が分かっている場合は自動ではなく手動で増やした方がよい。）になります。また、その7 で挙げた Pod の水平自動スケールである Horizontal Pod Scaler も自動スケールの重要なキーワードです。リンクは当記事中部にも掲載しておりますが下記に再掲します。記事の下部です。
なお、Node の水平自動スケールと Pod の水平自動スケールは共存可能です。
今回はここで終了です。
