k8sクラスタの環境構築
ことはじめ k8sという技術が注目を浴びている。web業界での近年の大きな変化としてはアプリケーションアーキテクチャの変化が挙げられる。従来は、アプリケーションを構成するソフトはモノリシック(一枚板)であった。つまり、アプリケーションは、一つのソースコードで1プロセスで動いているような感じだった。しかし、このモノリシックなアーキテクチャではソースコードが複雑で、変更が加えにくい等の問題があった。チームで開発する際も、メンバーみんなが同じソースコードをつかってビルドをする必要がある等、いろいろと面倒なことが多かったと思う。そこで、近年はアプリ開発にはマイクロサービスアーキテクチャが採用されている。マイクロサービスアーキテクチャは、小さなコンポーネントの集合が全体として一つのアプリケーションを構成しているようなアーキテクチャである。 自分も意図せずして、開発してきたアプリはマイクロアーキテクチャにしていたが、こちらの方が各コンポーネントの役割をきちんと明確化して進められるので、開発を分担できるのと、変更を加えるとき、役割がコンポーネントに分かれているので、各コンポーネントの中身だけを変えればよく、管理が簡単になると思われる。つまり、APIだけそろえておけば、後は中身はなんだっていいということだ。 これによって、アジャイル開発が非常に簡単になると思われる。 そして、このコンポーネントをひとつひとつをコンテナ化するってのも近年の大きな流れっぽい。そして、コンテナ化されたコンポーネント（マイクロサービス）をうまく協調させるのが コンテナオーケストレーションツールってはなしだ。 コンポーネントを協調させる、と書いたが、具体的には(k8sの機能は非常に多いので、俺が理解できる、かつ、大事そうなものだけをピックアップする)、 コンテナのスケジューリング スケーリング/オートスケーリング 障害時のセルフヒーリング ロードバランシング ワークロードの管理 とかがある。 一方、HPC分野でもK8Sを活用しようという試みがある。これはどういうことか？実は僕もよくわかっていません。k8sをスケジューラに使おうっていう話ぽい。そして、slurmと比較して、k8sが何なのかってのを調べてるみたいですね。 参考資料を少し上げておきます。 ref1 ref2 ref3 これは研究室の仲間と一緒に調べていくことにして、僕は僕で、web業界で使われているk8sがどんなものなのかに焦点を合わせて勉強していきたいと思う。 そして、実際にk8s上で去年開発したアプリを動かしてみる、というのを最終目標にしたいです。せっかくあのアプリはマイクロサービスアーキテクチャになっているからね。インターフェースは全部rest化されているし。 物理クラスタの構築 実験環境はラズパイクラスタです。 まあ、自宅lan内にマスターノードを1台置いて、その下にあらたなネットワークを作って、マスターノードでnatした。 あと、サブネットワークでipを固定した。 詳しくは、別の記事に書いてあるのでそっちを見てくれるとありがたい。 k8sの基本的なコンポーネント 参考動画 基本用語説明 dbと連携させたjsアプリを題材に、k8sのコンポーネントを説明していくよ！ cluster k8sのリソースを管理する集合体のこと node 物理マシン、もしくは仮想マシンのこと。つまり、ホストのこと。 ノードには、master nodeと普通のnodeがある。 master nodeはkubernetesを管理するため、次の管理コンポーネントを持つ kube apiserver:kubernetesのAPIを公開する。kubectlからの操作を受け付ける役割。kubeletからもアクセスを受けるし、他にもいろいろなクライアントがある。これがclusterへのgatewayになる。 etcd:分散kvs。クラスタのバッキングストアとして使用される。ログとかが記録されている。etcdは分散kvs、ということはetcdを何個か立てることが可能、ということでして、そうするとetcd間で内容の一貫性を保たないといけないわけですね。ということは？お？層です。分散合意アルゴリズムのraftが使われているわけですね。最高です。 kube scheduler:コンテナを配置する最適なnodeを選択する。ここも研究の対象になりえるところではある。 kube controller manager: リソースを制御する 普通のNodeはコンテナ化されたアプリケーションを実際に実行するホスト pod コンテナの集合体。PodはNodeの中で動作し、一つ以上のコンテナを持つ。 K8sにデプロイするときは、Pod単位で行う。 pod一つでなにか機能を果たす、とかそういう感じでpodにまとめるのだと思われる。 そうだね、1 application per Podというのが基本らしい。 しかし、そのアプリケーションは2つのコンテナから構成されていても問題ない。 k8sはvirtual networkを提供。各Podはこの仮想ネットワーク上でIPアドレスを持っている。 そして、これが結構大事な概念だんだが、Podは結構簡単に死ぬ。そして、Podが死んだら、新しいPodがデプロイされるのだが、その時にIPアドレスが変わってしまうというのが不便らしい。その時に使うのがServiceらしい。 Container Dockerコンテナのこと ReplicaSet 同一仕様のPodを複数生成する仕組み。 ReplicaSetを複数持っておくことで、一つのReplicaSetが死んでも他のReplicaSetに 処理を移すことでシステムが死んでいる時間をなくす。 後は、ロードバランスもできる。 データベースは基本的にk8sクラスタの外で管理する。というのも、ステートを考えるのが面倒くさいかららしいです。 Service Serviceは、Podにアクセスするための経路を定義。 PodのIPアドレスを固定できる。 外部への公開ポイントもここで設定する。 Deployment ReplicaSetの上位リソースで、ReplicaSetを管理する。 つまり、 DeploymentがReplicaSetを管理し、ReplicaSetがPodを管理する。 ...