コンテナまとめ #1

技術の流れで理解するコンテナ

  • 現在最も多く使われている製品を中心にLinux OSの流れを知る。
  • ★コンテナとコンテナオーケストレーションについて技術的な流れを知る。
  • Kubernetesがコンテナランタイムをどのように使うかを中心に流れを知る。

1. Linux OS

最初のOSとして有料のUnixがありましたが、無料のLinuxが登場し
Linuxをベースに多くのディストリビューションが作られている。

Debian Linuxはコミュニティ用ということで無料。
Redhat LinuxRedhatという会社が作り、有料。

上記二つのディストリビューションがOSインストールの主流であり、
Kubernetesをインストールする時も二つのディストリビューションでインストールガイドを提供しています。

Debianをベースに作ったディストリビューションであるubuntu(ui対応)
→無料で個人学習用やクラウドではUbuntuが多く使われている。
Red Hat社のRedhat Linux
→有料で企業ではRedhat系のLinuxが多く使われる。

レッドハットの配布プロセスは以下
開発(Fedora) -> 正式リリース (有料) (RHEL) -> 無料 (CentOS)

CentOSは無料だがメンテナンスサポートがない。
2024年を最後にサポート終了。

IBMに買収されてから、redhatの配布プロセスが以下のように変わる。

開発(Fedora) -> テスト配布(無料)(CentOS Stream) -> 正式リリース(有料)(RHEL)

従来からCentOSを使っていた環境の対応方法

  1. redhat linuxに切り替えて有料で使用。
  2. CentOSサポート終了後も技術サポートをしてくれる企業に依頼(CentOSをそのまま使用)
  3. 他のOSへの移行(スクリプト)(リスクあり)
  4. redhat linuxを複製して既存のCentOSのように無料配布版を提供するプロジェクトを利用。

全体図
まとめ

  1. 主に使うLinuxにはDebianRedhat系列があります。
  2. Kubernetesのインストールも大きく分けてこの2つの系列をサポートします。
  3. Redhat系の一つであるCentOSはもうすぐサポート終了を迎えます。
  4. Rocky LinuxCentOSの代替品の一つです。

2. Container

Linuxの発展に伴い、内部コア技術の一つである隔離技術が発展。

chroot、cgroup、namespaceカーネルレベルの技術を集約してまとめたのがLXC(LinuxContainer)
LXCをベースに作られたDocker(使いやすい)
rkt (rocket container) : dockerがセキュリティに弱い点を攻略するため、安定的なコンテナとして新しく登場。

  • Dockerはroot権限でインストールする必要があった。
  • Dockerではrootlessインストールモードが追加され、セキュリティが強化された。

代表的なコンテナ

  • docker : k8sとの互換性が悪かったが、MIRANTISに買収されてk8sのインターフェースに合わせてる。
  • containerd : Dockerからコンテナ機能だけ分離されたプロジェクト (CNCF Graduated Project)
  • cri-o : RedHat が作ったコンテナ (CNCF Incubating Project)

Kubernetesがコンテナランタイムを勝手に操作してくれるので、コンテナを直接扱うことが少なくなっている。
→コンテナがkubernetesのインターフェースと合うかどうかが重要になります。

Kubernetes以外にも、モニタリングやロギング、そしてデプロイメントツールまで一つのパッケージでインストールしてくれる企業管理型製品もあります。

まとめ

  1. Kubernetesは様々な分野で活用されています。
  2. Kubernetesはコンテナをより簡単に使うことができます。
  3. コンテナはkubernetesとのインターフェースが重要です。

その他の記事を読む

コンテナまとめ #2

#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ホスト上にCentOSUbuntuを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コンテナランタイム’と呼ばれるようになりました。