イラストではじめる「Kubernetesが動くしくみ」～Kubernetesのリソースとマニフェストとは

Kubernetesのアーキテクチャ

　Kubernetesのアーキテクチャを見ていきましょう。

　まず大枠として、KubernetesはControl PlaneとNodeからできています。Control Planeはいわゆる頭脳のパートで、Nodeは実際にアプリケーションのコンテナが起動するマシン（物理マシンでも仮想マシンでも良い）です。

　次にPodを利用してコンテナが起動する流れを見ていきましょう。

　①ユーザーはPodを作成するマニフェストを書き、kubectlを利用してkube-apiserverにリクエストを送ります。②リクエストを受け取ったkube-apiserverはetcdというデータベースに情報を保存します。③kube-schedulerがPodを新規作成する必要があることを検知し、メモリ・CPUなどさまざまな情報からどのNodeにPodを作成すべきか決定します。④kube-schedulerによってPodを作成するNodeが決まると、⑤kubeletが「自分のNodeにPodを作成すべきかどうか」を検知します。kubeletは自分のNodeにPodを作成すると決まったことがわかると、コンテナランタイムに指示してコンテナを起動します。

　こうした流れでkubectlを利用してPod作成を指示したユーザーはKubernetesクラスタ上にコンテナを起動できます。

　このようにAPIサーバ、データベース、そしてAPIサーバに問い合わせて稼働する各コンポーネントとしてみると一般的なWebサービスの構成と似ていて馴染みがでてきませんか？

• 参考：Kubernetes Components | Kubernetes

　Kubernetesのアーキテクチャで特徴的なのは、多くのコンポーネントがAPIサーバに問い合わせ、自分がすべき仕事にだけ専念しているところです。これはKubernetesが障害に強いと言われる理由の1つでもあります。例えばControl Planeが丸々障害でダウンしてしまったとします。各NodeのkubeletはAPIサーバにアクセスできなくなりますが、Nodeが正常に生きている限りkubeletは自分の管理するコンテナを監視し、稼働し続けます。

　Kubernetesの動き、リソースやマニフェストについて理解が進んだでしょうか？ 今回完全に理解できていなくても大丈夫です。次回は手を動かしてみる回になるので、手を動かしながらまたこの回に戻ってきてください。きっとより理解が深まることでしょう！