#1の続きになります。
3. Container OrchestrationとContainer
コンテナ技術の一番下のOSのカーネルでは隔離のためのchroot, cgroup, namespace技術が活用されています。
このLinuxカーネル技術の上にContainer Runtimeが実行される仕組みです。
Container Runtime
コンテナランタイムは、コンテナの実行を担当するソフトウェアです。
Kubernetesは次の複数のコンテナランタイムをサポートします。
初期のコンテナランタイムは以下になります。
- LXC : Kernelレベルの技術で作られたLow Levelコンテナランタイム。
- libcontainer : dockerがLXCをベースに作ったLow Levelコンテナランタイム。
- docker : libcontainerを利用してユーザーフレンドリーなHigh Levelコンテナ、機能集約型!
- rkt : セキュリティには良いが、Low Levelで占有率低下
LXC はOSをコンテナ仮想化に分ける目的で使用します。
→自身のlinuxホスト上にCentOSやUbuntuをGuest OSとして置くことができる
dockerはappを独立した環境で動かすために使う。
k8sがコンテナランタイムを使う流れ
kube-apiserver : Kubernetes内の様々な機能や通信を管理します。
kubelet : コンテナ作成過程を中継
上の図で、Container RuntimeとContainerを明確に区別することができます。
Container Runtime : コンテナを作成して実行する技術
Container : コンテナランタイムで生成された生成物 (例. Docker)
4. Kubeletとコンテナランタイム
kubelet は Container Runtime が受信できるように API 呼び出しを行います。
バージョン別でどのように呼び出しているのかをまとめました。
v1.0 ~ v1.20
kubeletのソースにケースステートメントとして、Dockerかrktかを判断するロジックがあり、
Dockerとrktに呼び出すAPIを集めたパッケージもあるので、カスタムAPIをContainer Runtimeで呼び出します。
v1.5 ~ v1.23
Container Runtimeの増加に伴う変化を受け入れるバージョンで、インターフェースを追加します。
kublet のインターフェース規格を決め、この規格に合う実装を作りました。
この実装部をCRI(Container Runtime Interface)と呼び、それぞれのコンテナランタイムを呼び出します。
CRIはKubernetesプロジェクトにあり、Container Runtime側でソースをcontribute(貢献)する形です。
※dockershimの管理が行われず、バグも多かったので、kubernetesからdockershimを外すという話もあったそうです。
CRIが増え、新しいオープンな団体であるOCI(Open Container Initiative)を構成し、コンテナランタイムがコンテナを作る時に守るべき標準規約を管理し始めました。
これでOCIの規格に合わせてコンテナを作れば、コンテナランタイム同士で共有して使うことができるようになりました。
dockerはこのOCI規格を守るため、Low LevelのrunCを作成し、containerdでもrunCを使えるように変更しました。
runCがlibcontainerと異なる点は、LXCを使わず、カーネルレベルの仮想化技術を使うことです。
rktもOCI規格に準拠し、dockerで使っていたイメージをrktでも使えるようになります。
v1.24 ~
kubeletからCRIを直接呼び出す仕組みに変更。
→以前のバージョンは、Container Runtimeがパッチや変更などの変化で
CRIパッチが適用される場合、Kubernetesもパッチを適用する必要がある構造。
- containerdではCRI-Plugin機能追加
- cri-o : Redhatで生まれながらにしてこの規格に合わせて作られた。
- cri-dockered : mirantis社がdockerを買収した後、規格を合わせるために作った(dockershimを外に出した形)
これでdockerを再びサポートできるようになり、名前は’Mirantisコンテナランタイム’と呼ばれるようになりました。
