コンテナ未経験新人が学ぶコンテナ技術入門

Copyright©2018 NTT corp. All Rights Reserved.
コンテナ未経験新人が学ぶ
コンテナ技術入門
2018/09/19
日本電信電話株式会社
ソフトウェアイノベーションセンタ
徳永航平

2Copyright©2018 NTT corp. All Rights Reserved.
 システム運用の歴史とコンテナに至るまで
 コンテナ仮想化の概要
システム運用
と
コンテナ
コンテナ
プラットフォーム
 Dockerの概要
 Kubernetesの概要
コンテナ周り
の
要素技術
 namespacesとcgroups
 overlayfs(CoWファイルシステム)
 DockerとKubernetesのコンテナ間ネットワーク
ランタイム周り
の
標準と動向
 コンテナ技術の標準
 主要なコンテナランタイム
１か月で学んだことマップ

システム運用
と
コンテナ
 Dockerの概要
コンテナ
コンテナ周り
の
要素技術
の
標準と動向
青山直樹.“コンテナ・ベース・オーケストレーション”.翔泳社;

システム運用の道のりとVM仮想化
リソース調達コストの最小化と迅速なサービスの立ち上げにむけて
クラウド
コンピューティング
 サービス間でリソース共有
 柔軟なスケーリングが可能
 インフラのコード化
Servers Storages
Cloud
…
……
… …
…
…
Service A Service B
仮想サーバ
 OS間でリソース共有
 計算資源の効率的利用
 依然ハード所有の必要あり
物理サーバ
 プロセス間でリソース共有
 アプリは物理サーバに縛ら
れ管理コスト高
OS
HW
…Apps
HW
Hyp.
HW
… …
…

VMでもまだなお残る課題
イメージが
大きくなりがち
…
イメージサイズが大き
く、コピーやネット
ワーク経由でのデプロ
イメントに不向き
… …
… …! !
!
開発・本番環境の差異
起因でデプロイに失敗、
イメージ再作成・再デ
プロイ・再起動が必要
デプロイに失敗
する可能性がある
デプロイ周りは時間的なコスト面でボトルネックになりがち
サービス起動のために、
VM・OS・ミドルウェ
ア・アプリ全ての起動
を待つ必要有り
サービス起動に
時間がかかる
…
Now
booting...

Process
Files
コンテナという実行単位
リソースを隔離した特殊なプロセスを実行単位とする
他プロセスとのリソース隔離
 namespaces：システム
 cgroups：ハードウェア
プロセスが依存するファイル
他のプロセスとは独立したファ
イルシステム環境で実行
実行するプロセス
環境隔離以外は通常の
Linuxプロセス

Files
Conf.
Runtime
コンテナイメージとランタイム
 コンテナから見えるファイル群
 コンテナとして実行するアプリケーション
 コンテナ実行に必要な各種設定情報 Etc…
コンテナイメージ
渡す
展開
起動
Process
Files
Etc…
コンテナランタイム
 コンテナイメージからコンテナの起動終了
 コンテナのファイルシステム構築
 コンテナのnamespacesとcgroups管理

コンテナとVM仮想化の比較
VM仮想化に比べてコンテナは“軽量”
VM仮想化コンテナ
抽象化層が多く、各VM
におけるハードウェアエ
ミュレーションのオー
バーヘッドも大きい
OS(Linux等)上でプロセ
スとして動作するためプ
ロセスと同等に動作が軽
量で仮想 O S が不要
HW
Hyp.
HW
… …
…
OS
HW
…

コンテナで解決が期待される課題
システム運用のデプロイ周りの問題解決が期待される
イメージが軽量
コンテナイメージには
OSイメージ内包され
ず、設定ファイルや依
存ファイル群で構成
OSイメージ起動不要、
リソース分割とファイ
ルシステム構築等最低
限の初期化のみで起動
起動が高速
…
Process Container
ライブラリなど依存
ファイルはコンテナが
内包するため、環境差
異の影響が少ない
高ポータビリティ
♪ ♪
…

コンテナ
 Dockerの概要
コンテナ周り
の
要素技術
の
標準と動向
システム運用
と
コンテナ
Docker Inc."Get Started".https://docs.docker.com/get-started/; 青山直樹.“コンテナ・ベース・オーケストレーション”.翔
泳社;

Docker
Ship
Build Run
コンテナの実行
イメージの作成
イメージの共有
 2013年3月dotCloud社(現Docker社)よりリリース
 コンテナのライフサイクルをサポートするコンテナ
 コンテナ技術の普及と標準化に貢献
 WindowsやMacOSもサポート
 コンテナを新たなソフトウェア提供単位として確立
コンテナ技術のシステム運用での活用におけるブレイクスルー
https://www.docker.com/

Dockerのアーキテクチャ
docker build
docker pull
docker run
Docker host
dockerd
Docker registry
 イメージの格納場所
 Docker HubやDocker
Cloud、オンプレ等、選
択肢は様々
Docker API
デーモン(dockerd)がホス
ト上のコンテナやイメージ、
ネットワーク、ストレージ
等を管理
Docker client
CLIコマンドを発行し
Docker API経由で
dockerdにコマンド送信
Docker Inc.”Docker architecture”.https://docs.docker.com/engine/docker-overview/#docker-architecture

Base
image
layer
layer
layer
FROM ubuntu:15.04
COPY . /app
RUN make /app
CMD python /app/app.py
Dockerfile
Context
DockerにおけるBuild
dockerd
docker build コマンド
を実行する
Dockerfileとcontext
を用意する
Dockerfileとcontext
をCLIからdockerdに
渡してイメージ生成
イメージの作成手順と、
Dockerが作成時参照
するファイル群を用意
レイヤ構造のイメージが
生成される
各レイヤは下位の親
レイヤへのコマンド発
行で生ずる差分を保持
① ② ③
CMD python /app/app.py
RUN make /app
COPY . /app
FROM ubuntu:15.04
Docker Inc.“Dockerfile reference”.https://docs.docker.com/engine/reference/builder/; Docker Inc.” Images and layers
”.https://docs.docker.com/v17.09/engine/userguide/storagedriver/imagesandcontainers/#images-and-layers;

DockerにおけるShip
docker run user_b/svcB:v4
… …
……
Docker Hub
user_cuser_buser_a
svcA:v1 svcB:v4
docker push user_a/new:v1
docker pull user_c/repo:v1
repo:v1 repo:v2
異なるマシン間でイメージを共有する仕組み
 コンテナのポータビリティの高さを享受
 マシン上でdocker run等のCLIコマンド発行時
にイメージがレジストリから自動ダウンロード
 Docker Hub以外にもレジストリサービスは存
在し、オンプレで構築することも可能
レジストリ
各ユーザのリポジトリ集合
リポジトリ
イメージ集合の管理単位
Docker Inc.”Docker registries”.https://docs.docker.com/engine/docker-overview/#docker-registries

DockerにおけるRun
dockerdがclientの要求に応じてコンテナを起動および管理
 dockerdがnamespacesやcgroups等コンテナの実行環境を管理
 コンテナ用に新たに読み書き可能レイヤを追加しコンテナを起動
 イメージレイヤは読み込み専用のためコンテナ間でイメージ共有可能
イメージコンテナ
Base
image
layer
layer
layer
dockerd
イメージ
レイヤ
(R専用)
コンテナ
レイヤ
（RW可能）
CoW
RW
Process
Docker Inc.” Docker overview”.https://docs.docker.com/engine/docker-overview/;Docker Inc.” Images and layers
”.https://docs.docker.com/v17.09/engine/userguide/storagedriver/imagesandcontainers/#images-and-layers;

Dockerの貢献と高まるコンテナへの期待
コンテナのライフサイ
クルをサポートするプ
ラットフォームを実現
しコンテナ活用のブレ
イクスルーとなった
Ship
Build Run
?
Dockerの貢献高まる期待
多ノード上の多数のコ
ンテナを統一的に管理
し、大規模なサービス
に対してもコンテナ技
術を活用したい

Kubernetes
 2014年6月Googleよりリリース
 サービスをコンテナ集合とみなして管理
 コンテナ集合のクラスタへのデプロイやアップデー
ト、スケーリング等の統一的な管理手段を提供
 Google自身の大規模サービス運用ノウハウ反映
コンテナオーケストレーションツールのデファクト
https://kubernetes.io/

Node
Kubernetesのアーキテクチャ
Kubernetes API
End user
kubectl run
kubectl get
kubectl scale
CLIコマンドや
YAML/JSONファ
イルでKubernetes
APIを経由し、
Masterにクラスタ
の理想状態を宣言
Cluster
マシンノード集合。
K8sでは各クラス
タごとにコンテナ
を管理
Master
Nodeを制御して
クラスタ全体の管
理を担うマシン
Node
コンテナの展開先
となるマシン
Masterへのアクセス
とObjectの操作手段の
RESTful API
Master
Node
Node
Node
宣言的アーキテクチャ
ユーザはクラスタの理想
状態をAPI経由で宣言し
k8sが維持管理を実施
Object
アプリや管理ポリシー等
K8sシステム中のエン
ティティでユーザはAPIを
通じてこれらを作成する
ことで理想状態を宣言
The Kubernetes Authors.”Concepts”.https://kubernetes.io/docs/concepts/;The Kubernetes Authors.” Understanding
Kubernetes Objects”. https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/

MasterとNodeのコンポーネント
クラスタの管理情
報を保存するKey-
Valueストア
新しく作られたPodの、
Nodeへのアサインを
スケジュール
ノードやルータ
等、基盤クラウ
ド環境を制御す
るベンダ固有
コード
Node
Serviceを実現するため
に、Node上のパケット
転送ルールを管理
プラガブルなコン
テナランタイム
各Objectのデプロイパ
ターンを管理する
controllerプロセスの制御
Master
etcd
Masterと通信し、仕様
（YAML、JSON形式の
PodSpec）通りのPodの
healthyな起動を担保
Kubernetes APIを公
開、各objectをリソー
スとして格納
The Kubernetes Authors.” Kubernetes Components”.https://kubernetes.io/docs/concepts/overview/components/; The Kubernetes Authors.”
kubelet”. https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/

Podとコンテナ
 Basic objectのひとつ
 1つ以上のコンテナで構成
 同一Podのコンテナは同一
Node上にデプロイ
 起動時にIPアドレス付与
 リソースを共有
 NWスタック
 ストレージ
 コンテナ管理情報
192.168.100.10
192.168.100.11
192.168.100.20
192.168.100.21
IP通信可能
192.168.100.30
コンテナ管理の最小単位
The Kubernetes Authors.”Kubernetes model”.https://kubernetes.io/docs/concepts/cluster-
administration/networking/#kubernetes-model

ラベルとアノテーション
App=App_A
App=App_C
App=App_C
App=App_B App=App_B
Objectへの情報付与
 PodなどObjectに付与でき
るKey-Valueペア
 ラベルはSelectorによる絞
り込みが可能
 アノテーションは絞り込み
できず、Kubernetesや周
辺システムが参照

10.0.102.12:8080
10.0.100.11:80
Service
App=App_A
App=App_C
App=App_C
App=App_B App=App_B
10.0.101.12:http Basic objectのひとつ
 物理的なクラスタ構成にと
らわれず機能への安定的な
通信を提供する抽象化層
 Podは起動毎IPアドレスが
変わるがServiceのIPアド
レスは不変
 Podへのトラヒックはロー
ドバランス
 targetPortへのトラヒック
はPodの任意ポートにフォ
ワード
 サーバコンテナはその
転送先ポートをlisten
Serviceの仮想
IPアドレス。ク
ラスタ内で有効
clusterIP targetPort
Serviceがlisten
する仮想ポート。
文字列も可
クラスタを機能の集合とみなす
Selector
Serviceを構成する
Podを指定するラ
ベルのセレクタ
The Kubernetes Authors.“Virtual IPs and service proxies”.https://kubernetes.io/docs/concepts/services-
networking/service/#virtual-ips-and-service-proxies

Volume
emptyDir
 Podと同じ生存区間
 バックエンドはノード上
 コンテナにファイルシス
テムとしてマウント
hostPath
 Nodeと同じ生存区間
 バックエンドはノード上
 コンテナにファイルシス
テムとしてマウント
PVC
 PVを条件付きで要求
 バックエンドは任意
 容量の要求やアクセス
モード、セレクタで指定
ストレージ情報と
その要求を分離
PV
 ストレージ情報定義
 容量
 IPアドレスやマ
ウントポイント
 アクセスモード
コンテナのデータ永続化
 Basic objectのひとつ
 ストレージバックエンド
と生存区間に応じてバリ
エーションが存在
 emptyDir：コンテ
ナ間データ共有
 hostPath：Node上
のファイルシステム
へのアクセス手段
 PV：Podライフサイ
クルを超えた永続化

ConfigMapとSecret
prop: hoge
pass:
cGFzcw==
ConfigMap Secret
pass: fuga
prop: hoge
prop: hoge
pass: fuga
環境依存情報の分離
 環境情報をKey-Valueペ
アで記述
 環境情報はコンテナからは
ファイルシステムにマウン
トされたVolume、または
環境変数に見える
 ConfigMapは平文
 SecretはBase64エンコー
ドされメモリ上にのみ展開

デプロイパターン①: Deployment
Replicas : 1
Version: 1
Deployment
Replicas : 1
Version: 1
ReplicaSet
App=App_v1
主流のデプロイパターン
 Controllerのひとつ
 NodeにとらわれずにPod
を配置するパターン
 ローリングアップデートや
スケーリング、世代管理を
サポート
 ReplicaSetで起動Pod数を
維持

Deploymentのスケーリング
Replicas : 2
Version: 1
Deployment
Replicas : 2
Version: 1
ReplicaSet
App=App_v1
App=App_v1
柔軟なスケーリング
 Deploymentに属するPod
の数はスケールアップ、ス
ケールダウン可能
 Deploymentに対応する
ReplicaSetがPod数を維
持

Deploymentのローリングアップデート
App=App_v1
App=App_v1
Replicas : 2
Version: 1
Deployment
Replicas : 2
Version: 1
ReplicaSet
Replicas : 2
Version: 2
ReplicaSet
起動Pod数を維持可能
 起動しているPod数を維持
しながらアップデート可能
 アップデート時の起動Pod
の最小数と最大数を指定可
 過去バージョンへのロール
バックも可
App=App_v2

App=App_v1
Replicas : 2
Version: 1
Deployment
Replicas : 2
Version: 1
ReplicaSet
Replicas : 2
Version: 2
ReplicaSet
バックも可
App=App_v2

App=App_v1
Replicas : 2
Version: 1
Deployment
Replicas : 2
Version: 1
ReplicaSet
Replicas : 2
Version: 2
ReplicaSet
App=App_v2
バックも可
App=App_v2

Replicas : 2
Version: 1
Deployment
Replicas : 2
Version: 1
ReplicaSet
Replicas : 2
Version: 2
ReplicaSet
App=App_v2
App=App_v2
バックも可

デプロイパターン②: StatefulSet
State
02
host-2
State
01
host-1
State
03
host-3
…
StatefulSet
Podに状態を与える手段
 Podと状態を別々に管理
 Podの起動時に、一意のホ
スト名と状態を付与
 ホスト名はユニークなイン
デックス付
 状態はPVで保持
 Podは付与された状態に
従って動作
 クライアントからはあるホ
ストは一貫した状態を持つ
ように見える
The Kubernetes Authors.”StatefulSet Basics”.https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/

StatefulSetでPod起動
State
01
host-1
State
02
host-2
State
03
host-3
…
StatefulSet
デックス付
従って動作
ように見える

StatefulSetでPod削除
State
01
host-1 逆順に
削除
State
02
host-2
State
03
host-3
…
StatefulSet
デックス付
従って動作
ように見える

State
02
host-2
StatefulSetでPod再起動
State
01
host-1
State
03
host-3
…
StatefulSet
新たなPodが
状態を引継ぐ
デックス付
従って動作
ように見える

デプロイパターン③: DaemonSet
DaemonSet
Podをdaemon的に管理
 各NodeにPodをひとつづ
つ配置するパターン
 Nodeと同じ生存期間
 ログコレクタなどに使用
The Kubernetes Authors.“DaemonSet”.https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

デプロイパターン④: Job/CronJob
exit: 0
exit: 0
exit: 0 exit: 1
exit: 1
Job/CronJob
並列数: 5
完了数: 3
再実行上限: 7
タイムアウト: 100秒
失敗時: 再実行
Podをdaemon的に管理
 Podをバッチジョブとして
起動するパターン
 Job :ワンショットの実行
 CronJob：定期的に実行
 Pod内プロセスの終了コー
ドをから再実行を判断

NodePort Service
10.0.102.12:8080
App=App_A
App=App_C
App=App_C
App=App_B App=App_B
10.0.101.12:http
クラスタ外にサービス公開
 Serviceのtypeのひとつ
 各Node上でサービスに対応
してポートを公開
 ポートへのアクセスはそれに
対応するServiceにプロキシ
 外部公開用のIPアドレス取得
とクラスタの前段のロードバ
ランサのセットアップが必要 10.0.100.11:80
NodeIP:NodePort_A
The Kubernetes Authors.”Type NodePort”.https://kubernetes.io/docs/concepts/services-
networking/service/#nodeport;Sandeep Dinesh.“NodePort”.https://medium.com/google-cloud/kubernetes-nodeport-vs-
loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0/#25af

LoadBalancer Service
10.0.102.12:8080
App=App_A
App=App_C
App=App_C
App=App_B App=App_B
10.0.101.12:http
 Serviceのtypeのひとつ
 外部ロードバランサをサポー
トしているクラウドプロバイ
ダ上で作成可能
 Serviceに対して外部向けの
ロードバランサを提供
 自動的にセットアップ
 フィルタリングもルーティン
グも行わない
 一つのService公開
 HTTPSが利用できない
10.0.100.11:80
foo.bar.com
internet
The Kubernetes Authors.”Type LoadBalancer”.https://kubernetes.io/docs/concepts/services-
networking/service/#loadbalancer;Sandeep Dinesh.“LoadBalancer”.https://medium.com/google-cloud/kubernetes-nodeport-
vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0#0d96

Ingress
10.0.102.12:8080
App=App_A
App=App_C
App=App_C
App=App_B App=App_B
10.0.101.12:http
 各サービスにクラスタ外から
アクセス可能なURLを付与
 ロードバランサを設定しルー
ルベースでロードバランス
 他のリソースとは異なり、
Ingress controllerはkube-
controller-managerの一部
ではない
 ユーザがingress
controllerをmaster上
にセットアップ必要
/bar
/foo
10.0.100.11:80
foo.bar.com
internet
The Kubernetes Authors.”Ingress”.https://kubernetes.io/docs/concepts/services-
networking/ingress/;Sandeep Dinesh.“Ingress”.https://medium.com/google-cloud/kubernetes-nodeport-vs-
loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0#d3d1

Kubernetesで得られたもの
大規模なコンテナ集合・クラスタの見通しの良い管理手段
ユーザはCLIやYAML
ファイルでクラスタの
理想状態を宣言、K8s
に具体的な維持管理を
任せる管理スタイル
本来マシン集合である
クラスタを、物理的な
Nodeにとらわれない
Service集合として抽
象化し、見通しを確保
コンテナのステートレ
ス性を利用した柔軟な
管理やVolumeを利用
したステートフルな管
理など広範にサポート
機能集合とみなした
クラスタ宣言的なクラスタ管理
広範なデプロイパターン
をサポート

コンテナ周り
の
要素技術
 Dockerの概要
の
標準と動向
システム運用
と
コンテナ
コンテナ

コンテナの要素技術
コンテナ技術を支える3つの要素技術に着目した
システムリソースを隔
離し、プロセスをコン
テナ化する基礎技術と
してnamespaceと
cgroupsについて調査
C o W なレイヤ構造
ファイルシステムを構
築する技術のうち主流
なものの一つである
o v e r l a y f s を調査
Dockerにおけるマシ
ンローカルなコンテナ
間通信とKubernetes
におけるマシンを超え
た通信について調査
ファイルシステムプロセスのコンテナ化コンテナ間ネットワーク
Process
Files

Process
Files
プロセスのコンテナ化の基礎技術
プロセスから見えるリソースをプロセス単位で明示的に制御
cgroupsによるハードウェアリソース制限
namespacesによるシステムリソース分離
プロセスから見えるシステムリ
ソースを他プロセスと分離し任意
の環境をプロセス単位で再構築可
能にしてポータビリティを確保
使用可能なCPUやメモリ等のハー
ドウェアリソースについて、プロ
セス単位で個別に制限・割り当て
しハードウェアレベル管理

namespaces
マウントポイント
プロセスから見える以下のようなシステムリソースを分離
ホスト/ドメイン名
プロセス間通信プロセスツリー
NWスタックユーザ/グループ
各プロセスがそれぞ
れ隔離されたマウン
トポイント集合認識
PID番号空間を分離
し異なるプロセスが
同一のPIDを保持可能
各プロセスが、IPC
に使用するオブジェ
クトや f s 等を分離
隔離環境でユーザ/グ
ループ空間を再定義
し他環境とマップ
ホスト名とNISドメ
イン名をnamespace
ごとに個別設定可能
プロセスから見える
NWデバイス集合や
F W 設定を分離
PPPP P P
Michael Kerrisk."Namespaces in operation, part 1: namespaces overview".https://lwn.net/Articles/531114/;
Free Software Foundation."NAMESPACES(7)".Linux Programmer's Manual(man page)

namespacesとプロセス
プロセスはnamespaceを作成し、所属することができる
新しくnamespaceと
子プロセスを生成し、
その子プロセスを最初
のメンバにする
新しくnamespaceを
作成し、プロセス自身
をそのnamespaceの
メンバにする
既存のnamespaceを
選択し、プロセス自身
をそのnamespaceの
メンバにする
新しくNS作成し
自身が所属
子プロセスを所属自身が既存NSに移動
C1 C2
P
NS作成
P
NS作成
P
NS移動
Michael Kerrisk."Namespaces in operation, part 2: the namespaces API".https://lwn.net/Articles/531381/;

namespacesの親子関係
Namespaceは階層構造をなす
作成したプロセス
が所属していた
namespaceの子の
namespaceになる
プロセスが直前ま
で所属していた
namespaceの子の
namespaceになる
既存のnamespace
にプロセス自身が移
るため、新たな親子
関係は作成しない
自身が所属
子プロセスを所属自身が既存NSに移動
親
子
親
子

User namespace
User namespaceは他のnamespaceを所有する
C
P
mount IPC
PIDnetwork
PID
UTS
namespaceを所有
namespace作成時にプロ
セスが所属しているuser
namespaceがそれを所有
owner user
user namespaceを作っ
たプロセスの実効ユーザ
Free Software Foundation."USER_NAMESPACES(7)".Linux Programmer's Manual(man page);
Free Software Foundation."CAPABILITIES(7)".Linux Programmer's Manual(man page)
親user namespace
子user namespace
capablity
 スーパユーザの特権を分
割してプロセス/スレッ
ドに割り当てられるよう
にした特権集合
 特権的なリソースを操作
する際にカーネルによっ
て求められる
 各namespaceが統治す
るリソースの操作にはそ
のnamespaceを所有す
るuser namespace内
でcapabilityが必要

子孫user namespaceでも同
様のcapability集合を持つ
親user namespace内プロセス
操作可能
操作不能
User namespaceと特権
プロセスは各user namespaceで異なるcapability集合を持つ
親user namespaceに対し
capability集合を持たない
Michael Kerrisk.”Namespaces in operation, part 6: more on user
namespaces”.https://lwn.net/Articles/540087/
子user namespace内プロセス
見えていても、親user ns
に所有されているリソース
を操作することはできない

C
P
mount IPC
PIDnetwork
PID
UTS
親user namespace
子user namespace
User namespaceで全特権を持つプロセス
User namespace内で全capabilityを持つプロセス
Michael Kerrisk.”Namespaces in operation, part 6: more on user
namespaces”.https://lwn.net/Articles/540087/
user namespace内
の最初のプロセス
user namespaceを
作ったプロセスuser namespaceを
作ったプロセスを
の実効ユーザが持つ
プロセス
親user namespaceは
子user namespaceに
対して高い特権を持つ

User namespaceとUID/GIDマッピング
NS内で有効なUID/GID(各ユーザ/グループのID)を再設定
User NS A(親) User NS B(子)
1
4 5
3
4
2
root
1
4 5
3
4
2
root userA
nobody
nobody
userC userC userC
nobody
userCuserB UID/GIDを
親子間でマッピング
Michael Kerrisk."Namespaces in operation, part 5: User
namespaces".https://lwn.net/Articles/532593/
マップされてない
ユーザはわからない
userB userB userB

Mount namespace
プロセスから見えるマウントポイント集合を分離
Mount NS A Mount NS B
/
A
C D X Y
B
マウント /
A B
C D
…
マウント/アンマウントイベントが伝搬されない
Free Software Foundation."MOUNT_NAMESPACES(7)".Linux Programmer's Manual(man page)
Michael Kerrisk."Namespaces in operation, part 2: the namespaces API".https://lwn.net/Articles/531381/

Mount namespaceとShared subtree
マウントイベントの共有範囲であるpeer groupが定義可能
Mount NS A (親) Mount NS B (子)
/
A
C D
B
/
A B
C D
MS_SHARED
MS_PRIVATEMS_PRIVATE
MS_SHARED
MS_PRIVATEMS_SHARED MS_SLAVE MS_UNBINDABLE
共有する受け取るが
自らのは伝搬しない
イベントを
共有しない
イベントを共有しない
+ bind mountできない
NS作成と同時に
Peer group追加
※ bind mountでも追加可能
Michael Kerrisk."Mount namespaces and shared subtrees".https://lwn.net/Articles/689856/;Michael Kerrisk."Mount
namespaces, mount propagation, and unbindable mounts".https://lwn.net/Articles/690679/
配下マウントポイントのイベントをpeer groupで共有するかのフラグ
マウントポイント毎
にフラグを付与する

Mount namespaceとShared subtree
Peer group内でマウントイベントが共有される
Mount NS A Mount NS B
/
A
C D X Y
B
マウント /
A B
C D
…
Sa Sb Sa Sb
MS_SHARED
MS_PRIVATEMS_PRIVATE
MS_SHARED
マウントマウント
Michael Kerrisk."Mount namespaces and shared subtrees".https://lwn.net/Articles/689856/;Michael Kerrisk."Mount
namespaces, mount propagation, and unbindable mounts".https://lwn.net/Articles/690679/
ストレージのマウントを複数namespace間で一括で行ったりするのに便利
Peer group内で
イベントが伝搬される

PID namespace
各プロセスが見るプロセスツリーを分離
PID NS A PID NS B
1
4 5
1
2
各NSで異なるPID(各プロセスの一意のID)番号空間が作られる
 /procファイルシステム(カーネルのプロセス関連データ構造)が分離される
 子NSのプロセスは親NSのプロセスを操作できない
 プロセスはネストする各NSレイヤそれぞれでPIDを持つ
3
4
2
Free Software Foundation."PID_NAMESPACES(7)".Linux Programmer's Manual(man page);
Michael Kerrisk."Namespaces in operation, part 3: PID namespaces".https://lwn.net/Articles/531419/
NS作成

PID namespaceのinitプロセス
PID 1のプロセスはinitプロセスに類似した特徴を持つ
 NS全体で必要になる初期化を行う
 NS内の孤児プロセスの親になる
 子プロセスからのシグナルのうちハ
ンドラを未登録のものは無視する
 誤ってkillされない
 終了するときNS内すべてのプロセ
スをSIGKILLで終了させる
 親NSのプロセスからのSIGKILL、
SIGSTOPに対しては通常のプロセ
スと同様のふるまいをする
 SIGSTOP: プロセス停止
 SIGKILL: プロセス終了
 終了するときにNSも破棄される
相違点類似点
Free Software Foundation."PID_NAMESPACES(7)".Linux Programmer's Manual(man page);
Michael Kerrisk."Namespaces in operation, part 4: more on PID namespaces".https://lwn.net/Articles/532748/

IPC namespace
IPC(プロセス間通信)用リソースを分離する
IPC NS A IPC NS B
System V IPC object
POSIX message queue
 オブジェクトID集合
 /proc/sys/kernel(設定)
 /proc/sysvipc(設定)
 Message queue filesystem
 /proc/sys/fs/mqueue(設定)
各namespaceは独立のIPCオブジェクト集合を持つ
 同一のIPC namespaceに所属するプロセス同士がIPCできる
System V IPC object
 オブジェクトID集合
 /proc/sys/kernel(設定)
 /proc/sysvipc(設定)
POSIX message queue
 Message queue filesystem
 /proc/sys/fs/mqueue(設定)
Free Software Foundation."IPC namespaces (CLONE_NEWIPC)".NAMESPACES(7),Linux Programmer's Manual(man page);
Free Software Foundation."MQ_OVERVIEW(7)".Linux Programmer's Manual(man page);
Free Software Foundation."SVIPC(7)"Linux Programmer's Manual(man page);

UTS namespace
ホスト名とドメイン名を隔離する
UTS NS A UTS NS B
hostname
domainname
hostname
domainname
ホスト名/ドメイン名関連システムコールで扱う値を分離
sethostname()
uname()
setdomainname()
gethostname() getdomainname()
Free Software Foundation."UTS namespaces (CLONE_NEWUTS)".NAMESPACES(7),Linux Programmer's
Manual(man page);

Network namespace
ネットワーク関連のシステムリソースを隔離する
Network NS A Network NS B
eth0 eth1lo
iptables route
lo
iptables route
 物理的なネットワークデバイスは1つのnetwork namespaceにのみ所属
 NSが破棄されるときデバイスはinitial NSに戻される
 Linux bridge、vethを使うことでnetwork NS間の通信ができる(後述)
Protocol
stacks
ポート番号
Protocol
stacks
ポート番号
etc… etc…
Free Software Foundation."NETWORK_NAMESPACES(7)".Linux Programmer's Manual(man page);
Jake Edge."Namespaces in operation, part 7: Network namespaces".https://lwn.net/Articles/580893/

namespacesのLinux API
Namespace操作用のシステムコール(<sched.h>)
int
clone(int (*fn)(void *),
void *child_stack,
int flags,
void *arg);
procファイルシステム中のnamespace関連のファイル
子プロセスを所属
flagsで指定したNSを作成し、
その中で子プロセス(fn)にarg
を渡しchild_stack上で実行
int
unshare(int flags);
flagsで指定したNSを作成し
callerプロセスが所属
int
setns(int fd,
int nstype);
fdで指定した(nstypeを持
つ)NSにcallerプロセスが所属
/proc/[pid]/ns/ /proc/sys/user
 Pidプロセスが所属する各NSのハンドル
ファイル(シンボリックリンク)を格納
 setnsシステムコールの引数になる
 open/bind-mountされている間は
NSが生存する
 あるuser namespace内で作成可能な各
namespaceの最大数を設定するファイ
ルを格納
 特権プロセスのみが書き換えられる
自身が所属
自身が既存NSに移動
Michael Kerrisk."Namespaces in operation, part 2: the namespaces API".https://lwn.net/Articles/531381/;Free Software
Foundation."NAMESPACES(7)".Linux Programmer's Manual(man page)

cgroups
P
P
P
P
P
P
P
P
P
P
P
プロセス集合にハードウェアリソース設定を施す
CPU

CPU
cgroups
プロセス集合に階層構造でハードウェアリソース設定を施す
P P P P
P P
P
PPP
P
4コア
使える
コア
3,4のみ
コア
4のみ
コア
3のみ
コア
1のみ
コア
1,2のみ
Control group
(cgroup)
設定を継承親
子
subsystem
Red Hat, Inc."Resource Management Guide".https://access.redhat.com/documentation/en-
us/red_hat_enterprise_linux/6/html/resource_management_guide/

Red Hat, Inc."Resource Management Guide".https://access.redhat.com/documentation/en-
us/red_hat_enterprise_linux/6/html/resource_management_guide/
cgroupsファイルシステム
cgroupの階層構造をファイルシステムとして実装
P P 0
/firsthalf/first /secondhalf/third
/firsthalf /secondhalf
/secondhalf/fourth
P P
P PP 2 3
P
0,1 PPP 2,3
0-3
cgroupディレクトリ
リソース設定ファイル
リソース設定ファイル
ファイル名をパラメータ名、
内容をその値として設定
tasksファイル
cgroupに所属するプ
ロセスのPIDを記述
subsystem情報
マウントオプション
として付与
/
-o cpuset

cgroups namespace
cgroup階層構造のルートディレクトリを分離
/firsthalf
/first
/fourth
/secondhalf
/fourth
/secondhalf
/third
/firsthalf /secondhalf
/
/
/third
親namespaceの
Cgroupを隠蔽
cgroup NS A (親) cgroup NS B (子)
Free Software Foundation."CGROUP_NAMESPACES(7)".Linux Programmer's Manual(man page)

ファイルシステムとコンテナイメージ
RW
Process
イメージ
レイヤ
(R専用)
新規
コンテナレイヤ
（RW可能）
CoW
コンテナ実行時、ファイルシステムはCoWでレイヤ構造
CoW機能
下層レイヤは読み込み専用になるので
再利用および実行時共有ができる
レイヤ構造
コンテナの視点からは、複数レイヤを
重ね合わせたファイルツリーが見える
Docker Inc."About images, containers, and storage
drivers".https://docs.docker.com/v17.09/engine/userguide/storagedriver/imagesandcontainers/

overlayfs
Dockerで採用されているCoWなレイヤ構造の実行時fs
mount –t overlay overlay
-olowerdir=lower:lowest,upperdir=upper,workdir=work ＼
merged
lowest
lower
upper
merged
whiteout/
opaque
「削除済」ファ
イルを表すダ
ミーファイル
ファイル
検索方向
CoW
upperにコピー
Upperは
保存・再利用可
Docker Inc."Docker storage drivers".https://docs.docker.com/storage/storagedriver/select-storage-driver/;
Docker Inc."Use the OverlayFS storage driver".https://docs.docker.com/storage/storagedriver/overlayfs-driver/;
Neil Brown."Overlay Filesystem".https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt

コンテナ間ネットワーク
コンテナ間のP2P通信を実現するveth
ip link add veth0 type veth peer name veth1
ip link set veth1 netns nsb
Network NS “nsa” Network NS “nsb”
veth1veth0
2つのnetwork namespace間を接続する仮想的なインタフェースデバイス
192.168.100.10/24 192.168.100.11/24
Free Software Foundation."veth(4)".Linux Programmer's Manual(man page); Jake Edge."Namespaces in operation,
part 7: Network namespaces".https://lwn.net/Articles/580893/

コンテナ間ネットワーク
コンテナ同士のL2接続を実現するLinux bridge
brctl addbr br0
brctl addif br0 veth0
複数のvethを接続可能な仮想的なブリッジ
eth0 eth2eth1
veth0 veth1veth2
br0
192.168.100.10/24 192.168.100.11/24 192.168.100.12/24
Lennert Buytenhek."brctl(8)".Linux manual page(man page);池田宗広."LinuxカーネルHACKS"."4章 HACK#24 brctlコマ
ンド".オライリージャパン

DockerのBridge Network
Linux bridgeでホスト内にプライベートネットワーク構築
 Linux bridgeを用いた通信がデフォルト
 マシンの外と通信する際はホストマシンのポートをコンテナのポートにマップ
 コンテナ自身からと他マシン上コンテナからの視点でIPアドレスが異なる
 静的にポートを割り当てる場合、サービス開発者は各コンテナにどのポートを
割り当てるのか設計
docker0
192.168.100.10/24 192.168.100.11/24 192.168.100.12/24
eth0 eth0eth0
Docker Inc."Published ports".https://docs.docker.com/config/containers/container-networking/#published-ports;Docker Inc."Docker container
networking".https://docs.docker.com/v17.09/engine/userguide/networking/;The Kubernetes Authors.”Docker
model".https://kubernetes.io/docs/concepts/cluster-administration/networking/#docker-model

KubernetesのCluster Network概要
Ingress traffic
をロードバランシング
Nodeを超えた
コンテナ間通信
(NAT無し)
internet  コンテナ間通信
 Pod間通信
 Serviceの通信
 Ingress trafficの処理
本資料で扱う通信

KubernetesのPod
192.168.100.10
Pod container
Namespaceを保持するコンテナ
 プロセスが一つもないと
namespace破棄されてしまう
Pod毎に必ず1つ起動
起動しているが何もしない
Pod毎にIPアドレス割当
Pod内の各コンテナは一つのIPア
ドレスとポート集合を共有
 各プロセスへのListenポート割
当はVMの頃から必要でスケー
ラビリティの問題にはならない
ネットワーク資源共有
Pod内のコンテナは
Network namespace共有
 localhostで通信可能
 VM内のプロセスに類似
The Kubernetes Authors."Kubernetes
model".https://kubernetes.io/docs/concepts/cluster-
administration/networking/#kubernetes-model

GCEでのPod Network実装例
NEXTDESTINATION
192.168.2.0/24 10.100.0.3
192.168.1.0/24 10.100.0.2
eth0 eth0
192.168.1.10 192.168.1.11
eth0
192.168.2.10
cbr0
192.168.1.1
cbr0
192.168.2.1
10.100.0.2 10.100.0.310.100.0.1
192.168.1.0/24 192.168.2.0/24
ノードごとにサブネットを
割り当ててルーティング
Mark Betz."Understanding kubernetes networking: pods".https://medium.com/google-cloud/understanding-kubernetes-
networking-pods-7117dd28727;The Kubernetes Authors."Google Compute Engine
(GCE)".https://kubernetes.io/docs/concepts/cluster-administration/networking/#google-compute-engine-gce

KubernetesのService Network
192.168.100.11
:https
192.168.100.10
:80
 Podが起動のたびにIPアドレスを
動的に払い出し
 ある機能を呼び出したいときPod
の特定が困難
 機能単位で抽象化し仮想的かつ固
定的なIPアドレス:ポート番号付与
 機能単位でのアクセスが容易
 アドレスの対応をkube-proxyが
保持
Service NetworkPod Network
The Kubernetes Authors."Services".https://kubernetes.io/docs/concepts/services-networking/service/

User spaceによるService Network
Proxy Portを開放
Kube-
apiserver
Node
Master
ルータへ
clusterIP:targetPort
のServiceへ
ClusterIP宛パケットを、対応する
proxy portに転送するよう設定
Service
追加削除の監視
iptables
eth0
cbr0
Service毎に特定のポートを
開放してPodへプロキシ
localhost:proxyPort
へリダイレクト
podIP:port
のPodへプロキシ
Pod選択はラウンドロビン
Mark Betz."Understanding kubernetes networking: services".https://medium.com/google-cloud/understanding-
kubernetes-networking-services-f0cb48e4cc82;The Kubernetes Authors.“Virtual IPs and service
proxies”.https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies
②
③
①

iptablesによるService Network
ルータへ
Master
ユーザ空間のkube-proxyを
経由する必要がないのでより高
速で高信頼
Kube-
apiserver
eth0
PodのIPアドレスに転送するよう設定
iptables
podIP:port
のPodへリダイレクト
Pod選択はランダム
Service
cbr0
のServiceへ
Node
①
②

ipvsによるService Network
Master
eth0
PodのIPアドレスに転送するよう設定
 Service構成Podに多種類の
ロードバランシング
 ハッシュテーブルをデータ構
造に用い高パフォーマンス
 iptablesへのフォールバック
Kube-
apiserver
podIP:port
のPodへロードバランス
ipvs
ルータへ
Service
cbr0
のServiceへ
Node
①
②ipvs
Linuxカーネルの
ロードバランシング
機能

NodePort Serviceの通信
eth0
user space
iptables
ipvs
NodeIP:NodePortへ
cbr0 podIP:portへ
clusterIP:taregetPortへ
全ノードでserviceに対
応するポート(30000–
32767)を公開
 Kube-proxyが
clusterIPへプロキシ
The Kubernetes Authors.”Type NodePort”.https://kubernetes.io/docs/concepts/services-networking/service/#nodeport;
Mark Betz."NodePort Services".https://medium.com/google-cloud/understanding-kubernetes-networking-ingress-
1bc341c84078#0f19
②
③
①

Ingressの通信
eth0
user space
iptables
ipvs
publicIP:publicPort/blue
internet
NodeIP:NodePortへ
clusterIP:taregetPortへ
podIP:portへ
 ルールベースで
NodePort指定
 適切なNodeIPにロー
ドバランス
cbr0
The Kubernetes Authors.”Ingress”.https://kubernetes.io/docs/concepts/services-networking/ingress/;Sandeep
Dinesh.“Ingress”.https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-
what-922f010849e0#d3d1;Mark Betz."LoadBalancer Services and Ingress Resources".https://medium.com/google-
cloud/understanding-kubernetes-networking-ingress-1bc341c84078#9c6d
①
②
③

の
標準と動向
 Dockerの概要
システム運用
と
コンテナ
コンテナ
コンテナ周り
の
要素技術

コンテナ技術標準の概要
OCI Image Format
Specification
OCI Runtime
Specfication
コンテナ周りの技術の標準化プロジェクト
Runtime
コンテナイメージの標準
仕様。コンテナに含める
ファイルのレイヤや、メ
タデータの仕様およびそ
のファイルを定義
コンテナライフサイクル、
ランタイムがサポートす
べき基本操作の仕様、コ
ンテナ生成に必要な情報
の格納方法の定義
コンテナのnetwork NS
で作成するインタフェー
ス仕様、それを行うCNI
プラグインの仕様と入出
力パラメータ定義
CNCF.“Container Network Interface Specification”.https://github.com/containernetworking/cni/blob/master/SPEC.md;OCI.”
OCI Image Format Specification” https://github.com/opencontainers/image-spec;OCI.” Open Container Initiative Runtime
Specification”. https://github.com/opencontainers/runtime-spec
Container Network
Interface(CNCF project)

CNCFプロジェクト。CoreOSが
リリース。rktletによるk8sとの
連携機能を持つ。独自のコンテ
ナの仕様appcを提唱するが、
Dockerイメージも扱える。
主要なコンテナランタイムの概要
runc
runsc
(gVisor)
RedHatがリリース。k8s CRI指
向なコンテナランタイム。
Docker等のランタイムに比べて
軽量。下層レイヤでOCI準拠の
低レベルランタイムを使用。
Dockerの一部として、LXC、
libcontainerと続いて作られて
きた低レベルランタイム。現在
は独立のランタイムとして開発。
OCI Runtime Spec.準拠。
Googleがリリース。カーネル機
能の一部をユーザ空間に再実装
しホストOSと分離。コンテナの
システムコールをキャプチャし
て、ルールベース実行。
コンテナランタイムの界隈は群雄割拠
Antoine Beaupré."Demystifying container runtimes".https://lwn.net/Articles/741897/
https://coreos.com/rkt/ http://cri-o.io/
https://github.com/opencontainers/runc https://github.com/google/gvisor
CNCFプロジェクト。OCI標準
向けにDocker Engineの一部を
独立。CRIプラグインによるk8s
と連携をサポート。runc等OCI
準拠の低レベルランタイム利用。
OpenStack Foundationのプロ
ジェクト。コンテナを軽量の
VMでラップすることでホスト
OSに対して強く隔離しセキュリ
ティを担保。OCIとCRI準拠。
https://containerd.io/
https://katacontainers.io/
Kata Containers

コンテナランタイムの技術的展望
標準準拠からセキュリティ担保へ
OS
HW
…
従来のコンテナ実行 Kata Containers
ホストOSを共有するため
セキュリティリスクが複
数コンテナに波及
runsc(gVisor)
コンテナごとにVMで隔
離されるが、エミュレー
ションオーバヘッド有
システムコールはホスト
OSに直接発行されないが、
仲介のオーバヘッド有
HWHW
… …
…
OS
セキュリティとパフォーマンスの両立が課題
OS
HW
…
コンテナと
OS分離
syscall
仲介
Makoto Hasegawa."Dockerだけじゃないコンテナ runtime 徹底比較".https://speakerdeck.com/makocchi/about-
container-runtimes-japan-container-days-v18-dot-04;Shuji Yamada."20分でわかるgVisor入門
".https://www.slideshare.net/uzy_exe/201805gvisorintroduciton;

システム運用
と
コンテナ
コンテナ
 Dockerの概要
コンテナ周り
の
要素技術
の
標準と動向

チュートリアルへの取り組み
Dockerのライフサイクルをコマンドベースで一通り体験
 Docker Hubアカウント取得
 イメージへのタグ付与
 ユーザ名/リポジトリ名:タグ
 docker pushコマンド
 Dockerfileの作成
 docker buildコマンド
 docker runコマンド
 ホストとコンテナ間でのポー
トマッピング
 リポジトリからのイメージダ
ウンロード
 aptコマンドを用いた導入
 dockerd制御のためのdocker
CLI利用ユーザをdockerグ
ループに追加
Ship
Build
Docker Inc."Get Started".https://docs.docker.com/get-started/
公式チュートリアルのコンテナライフサイクルに関係する章(1～2章)を実施
環境構築
Run

チュートリアルへの取り組み
Kubernetesクラスタへのサービスデプロイをコマンドベースで体験
 Minikube環境の構築
 オールインワンのk8sク
ラスタを単一マシン上に
構築してくれるツール
 kubectlコマンドの導入
Minikubeを用いた公式チュートリアルを実施
The Kubernetes Authors."Kubernetes Basics".https://kubernetes.io/docs/tutorials/kubernetes-
basics/;Hiroaki Ono."Kubernetesに入門したい
".https://speakerdeck.com/hihihiroro/kubernetesniru-men-sitai?slide=136
 Minikubeクラスタにデプロイ
 Deploymentの作成
 kubectl runコマンド
 Pod内でコマンドの実行
 kubectl execコマンド
 Pod数のスケーリング
 kubectl scaleコマンド
 ローリングアップデート/取消
 kubectl set imageコマンド
 kubectl rollout undoコマンド
運用
デプロイ
環境構築
サービス作成
 DeploymentをServiceとして公開
 NodePort typeのService
を作成
 kubectl exposeコマンド

コマンド実装を通じた要素技術の学習
Linux APIを用いた手動でのプロセス環境分離
# ./containerize ＼
-U 0 -G 0 -u 0 -g 0 ＼
-h containerhost -d containerdomain ＼
-n cnet ＼
-l "/" ＼
-r "/cpuset/cpuset.cpus/0" -r "/cpuset/cpuset.mems/0" ＼
bash
[NOTICE(6440)] Prepared for workspace.
===== INPUT ENVIRONMENT =====
exec_file : bash
parent_PID : 6440
jail_enable : true
parent_user : UID=0, GID=0
child_user : UID=0, GID=0
hostname : containerhost
domainname : containerdomain
netns name : cnet
workspace : /tmp/container_64401464957714
pseudoroot : /tmp/container_64401464957714/pseudoroot
upperdir : /tmp/container_64401464957714/upper
lowerdir : /
workdir : /tmp/container_64401464957714/work
cgroupdir : /tmp/container_64401464957714/cgroup
res. conf. :
cpuset: (cpuset.mems => 0)
cpuset: (cpuset.cpus => 0)
=============================
#
プロセスの環境分離
コマンド実装
 指定バイナリを隔離環
境で実行するコマンド
 clone(2)を利用しプロ
セスの環境隔離/初期化
 namespaces分離
 overlayfsを用い
たchroot jail環境
 ipコマンドで操作
可能なNW NS
 cgroupsによるリソー
ス制限機能
Michael Kerrisk氏のチュー
トリアルの延長として実装
(GPLv2 or later)
https://lwn.net/Articles/531114/
隔離・初期化
した環境
隔離・初期化の
環境設定と
実行バイナリ指定
隔離環境からの
標準出力
(この例はbash)

コマンド実装を通じた要素技術の学習
Linux Bridgeを用いたマシンローカルな仮想NWの手動作成
Network NSの
Linux bridgeへの
接続コマンド実装
 指定network NSの指
定Linux bridgeへの接
続とipアドレス付与の
自動化コマンド
 複数network NSが
接続されたプライベー
トネットワーク構築
 veth作成
 IPアドレス割当
 Linux bridge作
成・接続
# ./join.sh br0 netns3 192.168.0.12/24
[NOTICE] Making interfaces: (host)vethnetns3<==>eth0(netns)...
Device "vethnetns3" does not exist.
Device "eth0" does not exist.
[NOTICE] Completed setting up interface of vethnetns3<==>eth0.
[NOTICE] Assigning IP address 192.168.0.12/24 to eth0...
[NOTICE] Completed assigning IP address 192.168.0.12/24 to eth0.
[NOTICE] Completed adding interface vethnetns3 to br0.
[NOTICE] Starting br0...
[NOTICE] Starting vethnetns3...
[NOTICE] Starting eth0...
[NOTICE] Starting netns3's localhost...
[NOTICE] Completed all configuration!!
Connected: [br0](vethnetns3)<==>(eth0=192.168.0.12/24)[netns3]
Bridge status:
bridge name bridge id STP enabled interfaces
br0 8000.1e004d39574a no vethnetns1
vethnetns2
vethnetns3
# ip netns exec netns3 ping 192.168.0.10
PING 192.168.0.10 (192.168.0.10) 56(84) bytes of data.
64 bytes from 192.168.0.10: icmp_seq=1 ttl=64 time=0.030 ms
C-c C-c
--- 192.168.0.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2054ms
rtt min/avg/max/mdev = 0.030/0.034/0.042/0.005 ms
スクラッチからの実装
bridgeとNW NS
の接続、および
IPアドレス付与
ipコマンドで
2つのNW NS間の
疎通確認

チュートリアル/コマンド実装で学んだこと
コンテナ関連技術を幅広いレイヤで体験できた
コンテナベース管理のシンプルさ
 「実現したいこと」駆動で宣言的にクラスタ操作可能
 コマンドだけでも一通りの操作が可能で、JSON/yaml
ファイルを用いればよりきめ細かく設定可能
デプロイ単位としてのコンテナ
 技術的には実行単位(プロセス)であるコンテナをデプロ
イ単位として作成・共有することが可能
 作成レシピをMakefileのようにファイルで記述するだけ
で手軽にイメージが作成可能
コンテナ要素技術
namespaces/cgroups/overlayfs
 プロセスから分離するものはシステムリソースのごく一部
 例えばnamespaceによってシステムコール発行が制
限されるわけでもなく、それには別途機構が必要
 user NSによるcapability分離とNS間のownership関係
が、専有空間とセキュリティとの両立を実現
Linux Bridge
 network namespace間の通信にIP通信の概念を持ち込み、
統一的でシンプルなコンテナ間通信実現

まとめ
コンテナについて技術面を中心に体系的・網羅的に概要を学習
コンテナ化の意義
V M に比べ軽量で
ポータビリティに優
れるためサービスの
デプロイコストを軽
減することが可能
Dockerによりコン
テナライフサイクル
が確立、K8sにより
スケーラブルなサー
ビス管理が実現
要素技術
Linux機能の隔離環
境やファイルシステ
ム、仮想NWデバイ
スをプロセスに適用
しコンテナが実現
チュートリアル/コマンド実装を通じて体験的に学習
Docker/k8sチュートリアルプロセス環境分離・通信コマンド実装
Docker・k8sの公式チュートリアル
に沿ったコマンドベースの基本操作
を通じてコンテナライフサイクルや
コンテナベース管理を体験
namespaces/cgroups/overlayfs/
veth/Linux bridgeなどの要素技術
をシステム/シェルプログラミング
を通じて体験
ランタイム動向
コンテナライフサイ
クルの全体に渡って
標準が存在し、各ラ
ンタイムも準拠。今
後はセキュリティへ

コンテナ未経験新人が学ぶコンテナ技術入門

More Related Content

コンテナ未経験新人が学ぶコンテナ技術入門