Kubernetesのアーキテクチャと構成するコンポーネント(Master Node)

こんにちわ

がじぇったー (@hackmylife7) | Twitter

です。

Kubernetesのアーキテクチャと構成するコンポーネントについて書いていきます。
今回はWorker Nodeで稼働するコンポーネントについてとりあげていきます。

TL;DR(要約)

• クラスタに登録される全ての情報が格納されるのがetcd
• k8sクラスタにおけるコミュニケーションの中心となるのが、kube-apiserver
• 様々なコントローラを実行するコンポーネントがkube-controller-manager
• 起動するノードの情報が未割り当てのPodを検知し、kube-apiserverにリクエストを送り割り当てるNodeを決めるがkube-scheduler

全体構成

本日は下記画像の緑色に塗られているMaster Nodeを構成する各Componentです。

etcd

実態はオープンソースソフトウェアの分散key-value storeであり、
k8sのクラスタに登録される全ての情報がこのetcdに保存されます。

etcdクラスタには単一のリーダが存在し、何らかの理由で動作しなくなると自動的に新しいリーダが選出され、サービスが継続されます。

→SplitBrainを防ぐため、奇数でクラスタを組むのが基本設計

基本的にk8sは分散システムが前提で作られており、CAP定理におけるConsistency（一貫性）とPartition tolerance(分断耐性)が保証される

※ Availablity(可用性)は担保しない

分散システムにおいては以下の3つの要素のうち2つしか同時に満たすことができない、というCAP定理を提唱したのは、Eric Brewer氏でした。

C：Consistency（一貫性）
A：Availability（可用性）
P：Tolerance to network Paritions（ネットワーク分断への耐性）
CAP定理を見直す。“CAPの3つから2つを選ぶ”という説明はミスリーディングだった － Publickey

kube-apiserver

k8sクラスタにおけるコミュニケーションの中心となるのが、kube-apiserver。

クラスタ内における各種操作をREST（CRUD）で実行し、etcd内の対応するオブジェクトを更新する
※ 実行される際、オペレーションの内容は検証される

• k8sのapiを提供するコンポーネントであり、kubectlもこのコンポーネントを叩いている
• kube-apiserver経由でリクエスト(例えばapplyされると)を受け取り、リソース情報がetcdに書き込まれる
• LB配下に複数台並べて冗長化することが多い(水平方向にスケールする)
• ネームスペース:kube-systemでPodとして稼働しており、kube-apiserver自体は情報を持たない(state)
• 認証、Late Limit、admission control等の機能を司どる

kube-controller-manager

様々なコントローラを実行するコンポーネントがkube-controller-managerの役割

具体的には以下のコントローラを示す。

• replication controller
• endpoints controller: どこにアクセスしたら最終的にリクエストがかえってくるかを管理
• namespace controller
• serviceaccount controller
• deployment controller

例えばdeployment controllerはDeploymentの状態を監視しながら足りないPodを作成する。
例えばマニフェストファイル上では3つのPodが稼働しているのが「正」としているのに、1つしか稼働していなかったら、足りない二つのPodを作成する。

ただ、この際kube-controller-managerが行うのはkubectlコマンドでdeployするときと同様にPodをetcd上に登録するだけである。
実際どのNodeで立ち上げるかを判断するのはkube-scheduler、実際の立ち上げはkubeletによって行われる。

kube-scheduler

kube-apiserverを介してクラスタの状態(etcd)を監視しており、起動するノードの情報が未割り当てのPodを検知し、kube-apiserverにリクエストを送り割り当てるNodeを決める（etcdを更新するようリクエストをだす）
いる。

「Podを作成してください」とkube-apiserverがリクエストを受け取って、「どのノードで稼働させるのか？」を判断するのがkube-schedulerの役割

Pod配置時に、deploy先のノードに十分な空きリソースがあるか、なるべく幅広く各ノードでPodが動くようにする(一つのノードに同一のPodが集中しないようにする）といったチェックを実行している

参考(Kubernetesの最強参考書)

Kubernetes完全ガイド (impress top gear)

Kubernetesの他の記事へは下記の一覧から飛べるようにしているので参照ください。

gadgeterkun.hatenablog.com