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

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

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

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

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

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

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

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

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

10. 10Copyright©2018 NTT corp. All Rights Reserved.  システム運用の歴史とコンテナに至るまで  コンテナ仮想化の概要コンテナプラットフォーム  Dockerの概要  Kubernetesの概要  namespacesとcgroups  overlayfs(CoWファイルシステム)  DockerとKubernetesのコンテナ間ネットワーク  コンテナ技術の標準  主要なコンテナランタイムコンテナ周りの要素技術ランタイム周りの標準と動向システム運用とコンテナ１か月で学んだことマップ Docker Inc."Get Started".https://docs.docker.com/get-started/; 青山直樹.“コンテナ・ベース・オーケストレーション”.翔泳社;

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

12. 12Copyright©2018 NTT corp. All Rights Reserved. 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

13. 13Copyright©2018 NTT corp. All Rights Reserved. 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;

14. 14Copyright©2018 NTT corp. All Rights Reserved. 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

15. 15Copyright©2018 NTT corp. All Rights Reserved. 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;

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

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

18. 18Copyright©2018 NTT corp. All Rights Reserved. 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/

19. 19Copyright©2018 NTT corp. All Rights Reserved. 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/

20. 20Copyright©2018 NTT corp. All Rights Reserved. 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

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

22. 22Copyright©2018 NTT corp. All Rights Reserved. 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

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

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

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

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

27. 27Copyright©2018 NTT corp. All Rights Reserved. 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

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

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

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

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

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

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

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

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

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

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

38. 38Copyright©2018 NTT corp. All Rights Reserved. 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

39. 39Copyright©2018 NTT corp. All Rights Reserved. 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

40. 40Copyright©2018 NTT corp. All Rights Reserved. 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

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

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

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

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

45. 45Copyright©2018 NTT corp. All Rights Reserved. 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)

46. 46Copyright©2018 NTT corp. All Rights Reserved. namespacesとプロセスプロセスはnamespaceを作成し、所属することができる新しくnamespaceと子プロセスを生成し、その子プロセスを最初のメンバにする新しくnamespaceを作成し、プロセス自身をそのnamespaceのメンバにする既存のnamespaceを選択し、プロセス自身をそのnamespaceのメンバにする新しくNS作成し自身が所属新しく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/; Free Software Foundation."NAMESPACES(7)".Linux Programmer's Manual(man page)

47. 47Copyright©2018 NTT corp. All Rights Reserved. namespacesの親子関係 Namespaceは階層構造をなす作成したプロセスが所属していた namespaceの子の namespaceになるプロセスが直前まで所属していた namespaceの子の namespaceになる既存のnamespace にプロセス自身が移るため、新たな親子関係は作成しない新しくNS作成し自身が所属新しくNS作成し子プロセスを所属自身が既存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)

48. 48Copyright©2018 NTT corp. All Rights Reserved. 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が必要

49. 49Copyright©2018 NTT corp. All Rights Reserved. 子孫user namespaceでも同様のcapability集合を持つ親user namespace内プロセス操作可能操作不能 User namespaceと特権プロセスは各user namespaceで異なるcapability集合を持つ親user namespaceに対し capability集合を持たない Free Software Foundation."USER_NAMESPACES(7)".Linux Programmer's Manual(man page); Michael Kerrisk.”Namespaces in operation, part 6: more on user namespaces”.https://lwn.net/Articles/540087/ 子user namespace内プロセス見えていても、親user ns に所有されているリソースを操作することはできない

50. 50Copyright©2018 NTT corp. All Rights Reserved. C P mount IPC PIDnetwork PID UTS 親user namespace 子user namespace User namespaceで全特権を持つプロセス User namespace内で全capabilityを持つプロセス Free Software Foundation."USER_NAMESPACES(7)".Linux Programmer's Manual(man page); 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に対して高い特権を持つ

51. 51Copyright©2018 NTT corp. All Rights Reserved. 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を親子間でマッピング Free Software Foundation."USER_NAMESPACES(7)".Linux Programmer's Manual(man page); Michael Kerrisk."Namespaces in operation, part 5: User namespaces".https://lwn.net/Articles/532593/ マップされてないユーザはわからない userB userB userB

52. 52Copyright©2018 NTT corp. All Rights Reserved. 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/

53. 53Copyright©2018 NTT corp. All Rights Reserved. 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で共有するかのフラグマウントポイント毎にフラグを付与する

54. 54Copyright©2018 NTT corp. All Rights Reserved. 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内でイベントが伝搬される

55. 55Copyright©2018 NTT corp. All Rights Reserved. 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作成

56. 56Copyright©2018 NTT corp. All Rights Reserved. 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/

57. 57Copyright©2018 NTT corp. All Rights Reserved. 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);

58. 58Copyright©2018 NTT corp. All Rights Reserved. UTS namespace ホスト名とドメイン名を隔離する UTS NS A UTS NS B hostname domainname hostname domainname ホスト名/ドメイン名関連システムコールで扱う値を分離 sethostname() uname() setdomainname() gethostname() getdomainname() Michael Kerrisk."Namespaces in operation, part 2: the namespaces API".https://lwn.net/Articles/531381/; Free Software Foundation."UTS namespaces (CLONE_NEWUTS)".NAMESPACES(7),Linux Programmer's Manual(man page);

59. 59Copyright©2018 NTT corp. All Rights Reserved. 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/

60. 60Copyright©2018 NTT corp. All Rights Reserved. namespacesのLinux API Namespace操作用のシステムコール(<sched.h>) int clone(int (*fn)(void *), void *child_stack, int flags, void *arg); procファイルシステム中のnamespace関連のファイル新しくNS作成し子プロセスを所属 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作成し自身が所属自身が既存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)

62. 62Copyright©2018 NTT corp. All Rights Reserved. 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/

63. 63Copyright©2018 NTT corp. All Rights Reserved. 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

64. 64Copyright©2018 NTT corp. All Rights Reserved. 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)

65. 65Copyright©2018 NTT corp. All Rights Reserved. ファイルシステムとコンテナイメージ 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/

66. 66Copyright©2018 NTT corp. All Rights Reserved. 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

67. 67Copyright©2018 NTT corp. All Rights Reserved. コンテナ間ネットワークコンテナ間の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/

68. 68Copyright©2018 NTT corp. All Rights Reserved. コンテナ間ネットワークコンテナ同士の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コマンド".オライリージャパン

69. 69Copyright©2018 NTT corp. All Rights Reserved. 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

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

71. 71Copyright©2018 NTT corp. All Rights Reserved. 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

72. 72Copyright©2018 NTT corp. All Rights Reserved. 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

73. 73Copyright©2018 NTT corp. All Rights Reserved. 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/

74. 74Copyright©2018 NTT corp. All Rights Reserved. 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 ② ③ ①

75. 75Copyright©2018 NTT corp. All Rights Reserved. iptablesによるService Network ルータへ Master ユーザ空間のkube-proxyを経由する必要がないのでより高速で高信頼 Kube- apiserver eth0 ClusterIP宛パケットを、対応する PodのIPアドレスに転送するよう設定 iptables podIP:port のPodへリダイレクト Pod選択はランダム Service 追加削除の監視 cbr0 clusterIP:targetPort のServiceへ 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 Node ① ②

76. 76Copyright©2018 NTT corp. All Rights Reserved. ipvsによるService Network Master eth0 ClusterIP宛パケットを、対応する PodのIPアドレスに転送するよう設定  Service構成Podに多種類のロードバランシング  ハッシュテーブルをデータ構造に用い高パフォーマンス  iptablesへのフォールバック Kube- apiserver podIP:port のPodへロードバランス ipvs ルータへ Service 追加削除の監視 cbr0 clusterIP:targetPort のServiceへ 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 Node ① ②ipvs Linuxカーネルのロードバランシング機能

77. 77Copyright©2018 NTT corp. All Rights Reserved. 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 ② ③ ①

78. 78Copyright©2018 NTT corp. All Rights Reserved. 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 ① ② ③

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

80. 80Copyright©2018 NTT corp. All Rights Reserved. コンテナ技術標準の概要 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)

81. 81Copyright©2018 NTT corp. All Rights Reserved. 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

82. 82Copyright©2018 NTT corp. All Rights Reserved. コンテナランタイムの技術的展望標準準拠からセキュリティ担保へ 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;

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

84. 84Copyright©2018 NTT corp. All Rights Reserved. チュートリアルへの取り組み 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

85. 85Copyright©2018 NTT corp. All Rights Reserved. チュートリアルへの取り組み 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コマンド

86. 86Copyright©2018 NTT corp. All Rights Reserved. コマンド実装を通じた要素技術の学習 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)

87. 87Copyright©2018 NTT corp. All Rights Reserved. コマンド実装を通じた要素技術の学習 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 64 bytes from 192.168.0.10: icmp_seq=2 ttl=64 time=0.030 ms 64 bytes from 192.168.0.10: icmp_seq=3 ttl=64 time=0.042 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間の疎通確認

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

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

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

Kohei Tokunaga

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