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のアーキテクチャで特徴的なのは、多くのコンポーネントがAPIサーバに問い合わせ、自分がすべき仕事にだけ専念しているところです。これはKubernetesが障害に強いと言われる理由の1つでもあります。例えばControl Planeが丸々障害でダウンしてしまったとします。各NodeのkubeletはAPIサーバにアクセスできなくなりますが、Nodeが正常に生きている限りkubeletは自分の管理するコンテナを監視し、稼働し続けます。
Kubernetesの動き、リソースやマニフェストについて理解が進んだでしょうか？ 今回完全に理解できていなくても大丈夫です。次回は手を動かしてみる回になるので、手を動かしながらまたこの回に戻ってきてください。きっとより理解が深まることでしょう！
