はじめに
記事で挙げているkubernetesアーキテクチャ（Master構成）は、k8sを利用する上で必ず必要という訳ではないですが、筆者はCKA(Certificate Kubernetes Administorator)資格をきっかけにk8sの仕組みを知り、k8sを使うことに対する怖さが全くなくなりました。
CKAに無事合格できたので、kubernetesアーキテクチャの概要をまとめてみました。
kubernetesアーキテクチャ概観
k8sはMasterとWorker Nodeの２つに分けることができます。Masterは、４つのコアコンポーネントで構成され、k8sの各種機能を実現しています。Worker Nodeは、主にpodをデプロイするために使用されるノードです。
API Server
API Serverは、多くの場合staticPodとしてkube-systemネームスペースに存在します。API Serverの役割は各コンポーネントとのやり取りで、HUBとして機能をします。クライアントとのkubectlコマンドも、API Serverが受け付けます。
###API Server～クライアント
クライアントとAPI Serveの通信はTSLによって暗号化されています。この暗号化情報や、クライアントが接続するクラスター（API Server）の情報は、KubeConfigで設定します。
Scheduler
Schedulerは、多くの場合staticPodとしてkube-systemネームスペースに存在します。Schedulerの役割は、podを実行するノードを決定することです（デプロイはkubeletが行います）。kubernetesでは、pod実行ノードに制約をかけることのできる機能が多く存在します。
###podが実行されるノードに対する制約
| 機能 | 説明 |
|---|---|
| taint | taintは、tolerationを持たないpodのデプロイを防ぎます |
| affinity | affinityをpodに設定することで、特定のnodeにデプロイさせることができます |
| drain | drainにより、特定のノードへのデプロイを防ぎます |
| required resource | podデプロイ時にノードに要求するCPUやメモリを指定できます |
etcd
etcdは、Key-Valueベースのデータベースで、クラスター情報を管理します。etcdの実体は、多くの場合kube-systemネームスペースのDeploymentです。このetcdのスナップショットを取っておくことで、クラスターのリストアが可能です。このように、etcdはクラスターにとって最も大切なコンポーネントであり、単一障害点にならないように冗長化されることも多いです。
ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save snapshotdb // etcdのsnapshotを取得
ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot restore snapshotdb // etcdのrestoreが可能
※ etcdはAPI Serverと異なるTLSサーバ証明書を持つことが一般的です。
上記コマンド実行の際は、オプションでetcdのTLS証明書の指定が必要な場合が多いです。
controller manager
controller managerは、多くの場合staticPodとしてkube-systemネームスペースに存在し、各種kubernetesリソースのコントローラーの役割をします。例えば、controller managerに含まれるdeployment-controllerは、
「kubernetesリソースのdeploymentで定義されれているreplica数」と「実際にRunning状態の対象Pod数」を比較して、スケールイン/スケールアウトの司令をだします。controller managerが正常に動作していないと、「kubectl scaleコマンド実行したのに、pod数が変わらない」スケールされないなどの事象が起きます。
kubelet
kubeletは、各ノードのデーモンサービスとして動作します。
kubeletの主な役割は、
・API Serverの司令によるpodデプロイ
・ノード指定フォルダ配下のpodデプロイ（staticPodとしてデプロイされます）
・メトリクスをAPI Serverに送信
です。
kube proxy
kubeletは、daemonSetとしてkube-systemネームスペースに存在します（daemonSetは、任意のpodを各ノードに１つずつデプロイすることを可能にします）。kube proxyはトラフィック管理を行います。
Serviceの実体からみる、kube proxyの役割
kubernetesは、Dockerのオーケストレーションサービスです。つまり、kubernetesが行うのはDockerの"管理"で、全てのコンポーネントはDocker上で動作します。Kubernetesリソースは、Docker上でどのように存在しているのでしょうか？？
例えば、Podであれば、Pod内の各コンテナはDockerコンテナとしてデプロイされます。Serviceはどうでしょうか？ServiceのようなDockerリソースは存在しません。Serviceの実体は、iptableのようなネットワーク設定です。kube proxyがkubernetesリソースであるServiceを検知して、Serviceをネットワーク設定に変換します。
kubectlデプロイまでの流れ
kubectlでPod作成コマンド実行～Podデプロイまでの一連の流れです。
以下、コマンド例です。
kubectl run --generator=run-pod/v1 hoge --image=nginx
-
kubectl → API Server
kubectlコマンドは、API Serverが受け付けます。
クライアントへのレスポンスは、2 のetcd更新後に返却します。 -
API Server → etcd
API Serverは、etcdに作成するpod情報を記録します。
この時点で、podはPending状態になります。 -
Scheduler → API Server
Schedulerは、etcdからデプロイされていないpodを検知し、
CPU・メモリ要求に応じてデプロイするノードを決定し、API Serverに教えます。 -
API Server → kubelet
API Serverは、Schedulerが決定したノードのkubeletにpod作成要求を出し、
kubeletがPodデプロイをします。
デプロイ完了をすると、podはRunning状態になります。