PROrdered stack path / text alternative
LinuxからDocker、Kubernetes、Helmへ：責務を積み上げて読む
Linux、Docker、Kubernetes、Helmは、同じ「基盤」の中でどの責務を分けているのか。
四つを代替候補として並べず、下層から上層へ責務と確認点を分けて個別レコードへ進める。
LOWER TO UPPER
下層から順に四つの責務を分ける
- 01
OS・カーネル
Linux
kernel.orgはLinuxをUnix系OSのカーネルとして説明し、完成したLinuxシステムであるディストリビューションとは別のものだと案内している。図鑑では配布形態とカーネル責務を混同しない。
- 02
ランタイム・コンテナ
Docker
Docker公式DocsはGet started、Guides、Manuals、CLI/API referenceをまとめ、Docker製品の利用者向け入口を構成している。上流Mobyの開発者向け説明とは読者目的が異なる。
- 03
オーケストレーション
Kubernetes
公式DocsはKubernetesをcontainerized workloadsとservicesの管理を自動化するためのportableなオープンソースシステムとして案内する。図鑑では単なるコンテナ実行器ではなく、調整層として扱う。
- 04
デリバリー自動化
Helm
Helm公式DocsとrepositoryはHelmをKubernetes package managerとして位置付ける。図鑑ではクラスタを直接置き換える実行層ではなく、アプリケーション配布を記述する層として扱う。
TEXT ALTERNATIVE
図を使わない説明
最下層のLinuxはカーネルとOS環境を担う。Dockerはその上でコンテナイメージと実行・配布の操作面を提供する。Kubernetesは複数node上のcontainer workloadを宣言状態へ近づけるオーケストレーションを担う。HelmはKubernetes resource群をchartとして構成・配布する。四つは全面的な一方向依存や優劣ではなく、実装と運用で責務を分けて確認する読解順である。
BOUNDARY
上下関係は全面依存や優越を意味しない。
DockerとKubernetesの関係は単一runtimeへの固定を意味せず、KubernetesとHelmの関係もchart利用を必須にしない。各レコードのrelation statementと公式sourceへ戻り、実構成を別途確認する。
実際の構成ではcontainer runtime、CNI、storage、controller、chart以外のpackagingも選択されます。このpageは30件の中で確認できた読解順を示し、唯一の構成や採用順を推奨しません。