O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

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

73.672 visualizações

Publicada em

最近勉強を始めたコンテナ技術に関する基礎的な知識をまとめました。

[訂正と注釈]
p.27-30: 「Deployment」内の「Version: 1」 => 「Version: 2」
p.37: 「終了コードをから」 => 「終了コードから」
p.39: 「HTTPSが利用できない」=> AWS上では、SSL終端するLBがサポートされています。https://kubernetes.io/docs/concepts/services-networking/service/#ssl-support-on-aws
p.40: 「ユーザがingress controllerをmaster上にセットアップする必要」 => master上にセットアップしなければならないという制約はありません。例えばGCEのingress controller(GLBC)はPodとして動作します。https://github.com/kubernetes/ingress-gce/blob/master/README.md
p.71: 「Pod container」 => 「pause container」

Publicada em: Software
  • DOWNLOAD FULL BOOKS, INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... ,DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ,DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ,DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ,DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ,DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ,DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • DOWNLOAD FULL BOOKS, INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... ,DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ,DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ,DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ,DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ,DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ,DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui

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

  1. 1. Copyright©2018 NTT corp. All Rights Reserved. コンテナ未経験新人が学ぶ コンテナ技術入門 2018/09/19 日本電信電話株式会社 ソフトウェアイノベーションセンタ 徳永 航平
  2. 2. 2Copyright©2018 NTT corp. All Rights Reserved.  システム運用の歴史とコンテナに至るまで  コンテナ仮想化の概要 システム運用 と コンテナ コンテナ プラットフォーム  Dockerの概要  Kubernetesの概要 コンテナ周り の 要素技術  namespacesとcgroups  overlayfs(CoWファイルシステム)  DockerとKubernetesのコンテナ間ネットワーク ランタイム周り の 標準と動向  コンテナ技術の標準  主要なコンテナランタイム 1か月で学んだことマップ
  3. 3. 3Copyright©2018 NTT corp. All Rights Reserved.  システム運用の歴史とコンテナに至るまで  コンテナ仮想化の概要 システム運用 と コンテナ  Dockerの概要  Kubernetesの概要  namespacesとcgroups  overlayfs(CoWファイルシステム)  DockerとKubernetesのコンテナ間ネットワーク  コンテナ技術の標準  主要なコンテナランタイム コンテナ プラットフォーム コンテナ周り の 要素技術 ランタイム周り の 標準と動向 1か月で学んだことマップ 青山直樹.“コンテナ・ベース・オーケストレーション”.翔泳社;
  4. 4. 4Copyright©2018 NTT corp. All Rights Reserved. システム運用の道のりとVM仮想化 リソース調達コストの最小化と迅速なサービスの立ち上げにむけて クラウド コンピューティング  サービス間でリソース共有  柔軟なスケーリングが可能  インフラのコード化 Servers Storages Cloud … …… … … … … Service A Service B 仮想サーバ  OS間でリソース共有  計算資源の効率的利用  依然ハード所有の必要あり 物理サーバ  プロセス間でリソース共有  アプリは物理サーバに縛ら れ管理コスト高 OS HW …Apps HW Hyp. HW … … …
  5. 5. 5Copyright©2018 NTT corp. All Rights Reserved. VMでもまだなお残る課題 イメージが 大きくなりがち … イメージサイズが大き く 、 コ ピ ー や ネッ ト ワーク経由でのデプロ イ メ ン ト に 不 向 き … … … …! ! ! 開発・本番環境の差異 起因でデプロイに失敗、 イメージ再作成・再デ プロイ・再起動が必要 デプロイに失敗 する可能性がある デプロイ周りは時間的なコスト面でボトルネックになりがち サービス起動のために、 VM・OS・ミドルウェ ア・アプリ全ての起動 を 待 つ 必 要 有 り サービス起動に 時間がかかる … Now booting...
  6. 6. 6Copyright©2018 NTT corp. All Rights Reserved. Process Files コンテナという実行単位 リソースを隔離した特殊なプロセスを実行単位とする 他プロセスとのリソース隔離  namespaces:システム  cgroups:ハードウェア プロセスが依存するファイル 他のプロセスとは独立したファ イルシステム環境で実行 実行するプロセス 環境隔離以外は通常の Linuxプロセス
  7. 7. 7Copyright©2018 NTT corp. All Rights Reserved. Files Conf. Runtime コンテナイメージとランタイム  コンテナから見えるファイル群  コンテナとして実行するアプリケーション  コンテナ実行に必要な各種設定情報 Etc… コンテナイメージ 渡す 展開 起動 Process Files Etc… コンテナランタイム  コンテナイメージからコンテナの起動終了  コンテナのファイルシステム構築  コンテナのnamespacesとcgroups管理
  8. 8. 8Copyright©2018 NTT corp. All Rights Reserved. コンテナとVM仮想化の比較 VM仮想化に比べてコンテナは“軽量” VM仮想化 コンテナ 抽象化層が多く、各VM におけるハードウェアエ ミュレーショ ンのオー バ ー ヘ ッ ド も 大 き い OS(Linux等)上でプロセ スとして動作するためプ ロセスと同等に動作が軽 量 で 仮 想 O S が 不 要 HW Hyp. HW … … … OS HW …
  9. 9. 9Copyright©2018 NTT corp. All Rights Reserved. コンテナで解決が期待される課題 システム運用のデプロイ周りの問題解決が期待される イメージが軽量 コンテナイメージには OSイメージ内包され ず、設定ファイルや依 存 フ ァ イ ル 群 で構 成 OSイメージ起動不要、 リソース分割とファイ ルシステム構築等最低 限の初期化のみで起動 起動が高速 … Process Container ラ イ ブ ラ リ な ど依 存 ファイルはコンテナが 内包するため、環境差 異 の 影 響 が 少 な い 高ポータビリティ ♪ ♪ …
  10. 10. 10Copyright©2018 NTT corp. All Rights Reserved.  システム運用の歴史とコンテナに至るまで  コンテナ仮想化の概要 コンテナ プラットフォーム  Dockerの概要  Kubernetesの概要  namespacesとcgroups  overlayfs(CoWファイルシステム)  DockerとKubernetesのコンテナ間ネットワーク  コンテナ技術の標準  主要なコンテナランタイム コンテナ周り の 要素技術 ランタイム周り の 標準と動向 システム運用 と コンテナ 1か月で学んだことマップ Docker Inc."Get Started".https://docs.docker.com/get-started/; 青山直樹.“コンテナ・ベース・オーケストレーション”.翔 泳社;
  11. 11. 11Copyright©2018 NTT corp. All Rights Reserved. Docker Ship Build Run コンテナの実行 イメージの作成 イメージの共有  2013年3月dotCloud社(現Docker社)よりリリース  コンテナのライフサイクルをサポートするコンテナ プラットフォーム  コンテナ技術の普及と標準化に貢献  WindowsやMacOSもサポート  コンテナを新たなソフトウェア提供単位として確立 コンテナ技術のシステム運用での活用におけるブレイクスルー https://www.docker.com/
  12. 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. 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. 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. 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. 16. 16Copyright©2018 NTT corp. All Rights Reserved. Dockerの貢献と高まるコンテナへの期待 コンテナのライフサイ クルをサポートするプ ラットフォームを実現 しコンテナ活用のブレ イ ク ス ル ー と な っ た Ship Build Run ? Dockerの貢献 高まる期待 多ノード上の多数のコ ンテナを統一的に管理 し、大規模なサービス に対してもコンテナ技 術 を 活 用 し た い
  17. 17. 17Copyright©2018 NTT corp. All Rights Reserved. Kubernetes  2014年6月Googleよりリリース  サービスをコンテナ集合とみなして管理  コンテナ集合のクラスタへのデプロイやアップデー ト、スケーリング等の統一的な管理手段を提供  Google自身の大規模サービス運用ノウハウ反映 コンテナオーケストレーションツールのデファクト https://kubernetes.io/
  18. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 41. 41Copyright©2018 NTT corp. All Rights Reserved. Kubernetesで得られたもの 大規模なコンテナ集合・クラスタの見通しの良い管理手段 ユーザはCLIやYAML ファイルでクラスタの 理想状態を宣言、K8s に具体的な維持管理を 任 せ る 管 理 ス タイ ル 本来マシン集合である クラスタを、物理的な Nodeにとらわれない Service集合として抽 象化し、見通しを確保 コンテナのステートレ ス性を利用した柔軟な 管理やVolumeを利用 したステートフルな管 理など広範にサポート 機能集合とみなした クラスタ宣言的なクラスタ管理 広範なデプロイパターン をサポート
  42. 42. 42Copyright©2018 NTT corp. All Rights Reserved.  システム運用の歴史とコンテナに至るまで  コンテナ仮想化の概要 コンテナ周り の 要素技術  Dockerの概要  Kubernetesの概要  namespacesとcgroups  overlayfs(CoWファイルシステム)  DockerとKubernetesのコンテナ間ネットワーク  コンテナ技術の標準  主要なコンテナランタイム ランタイム周り の 標準と動向 システム運用 と コンテナ コンテナ プラットフォーム 1か月で学んだことマップ
  43. 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. 44. 44Copyright©2018 NTT corp. All Rights Reserved. Process Files プロセスのコンテナ化の基礎技術 プロセスから見えるリソースをプロセス単位で明示的に制御 cgroupsによるハードウェアリソース制限 namespacesによるシステムリソース分離 プロセスから見えるシステムリ ソースを他プロセスと分離し任意 の環境をプロセス単位で再構築可 能にしてポータビリティを確保 使用可能なCPUやメモリ等のハー ドウェアリソースについて、プロ セス単位で個別に制限・割り当て し ハ ー ド ウ ェ ア レ ベ ル 管 理
  45. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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)
  61. 61. 61Copyright©2018 NTT corp. All Rights Reserved. cgroups P P P P P P P P P P P プロセス集合にハードウェアリソース設定を施す CPU
  62. 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. 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. 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. 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. 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. 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. 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. 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. 70. 70Copyright©2018 NTT corp. All Rights Reserved. KubernetesのCluster Network概要 Ingress traffic をロードバランシング Nodeを超えた コンテナ間通信 (NAT無し) internet  コンテナ間通信  Pod間通信  Serviceの通信  Ingress trafficの処理 本資料で扱う通信
  71. 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. 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. 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. 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. 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. 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. 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. 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. 79. 79Copyright©2018 NTT corp. All Rights Reserved.  システム運用の歴史とコンテナに至るまで  コンテナ仮想化の概要 ランタイム周り の 標準と動向  Dockerの概要  Kubernetesの概要  namespacesとcgroups  overlayfs(CoWファイルシステム)  DockerとKubernetesのコンテナ間ネットワーク  コンテナ技術の標準  主要なコンテナランタイム システム運用 と コンテナ コンテナ プラットフォーム コンテナ周り の 要素技術 1か月で学んだことマップ
  80. 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. 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. 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. 83. 83Copyright©2018 NTT corp. All Rights Reserved.  システム運用の歴史とコンテナに至るまで  コンテナ仮想化の概要 システム運用 と コンテナ コンテナ プラットフォーム  Dockerの概要  Kubernetesの概要 コンテナ周り の 要素技術  namespacesとcgroups  overlayfs(CoWファイルシステム)  DockerとKubernetesのコンテナ間ネットワーク ランタイム周り の 標準と動向  コンテナ技術の標準  主要なコンテナランタイム 1か月で学んだことマップ
  84. 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. 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. 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. 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. 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. 89. 89Copyright©2018 NTT corp. All Rights Reserved. まとめ コンテナについて技術面を中心に体系的・網羅的に概要を学習 コンテナ化の意義 V M に 比 べ 軽 量 で ポータビリティに優 れるためサービスの デプロイコストを軽 減することが可能 プラットフォーム Dockerによりコン テナライフサイクル が確立、K8sにより スケーラブルなサー ビ ス 管 理 が 実 現 要素技術 Linux機能の隔離環 境やファイルシステ ム、仮想NWデバイ スをプロセスに適用 し コ ン テ ナ が 実 現 チュートリアル/コマンド実装を通じて体験的に学習 Docker/k8sチュートリアル プロセス環境分離・通信コマンド実装 Docker・k8sの公式チュートリアル に沿ったコマンドベースの基本操作 を通じてコンテナライフサイクルや コンテナベース管理を体験 namespaces/cgroups/overlayfs/ veth/Linux bridgeなどの要素技術 をシステム/シェルプログラミング を通じて体験 ランタイム動向 コンテナライフサイ クルの全体に渡って 標準が存在し、各ラ ンタイムも準拠。今 後はセキュリティへ

×