Upgrade to Pro — share decks privately, control downloads, hide ads and more …

【Okinawa Open Days 2016】OpenStack 環境におけるContainer as a Service の提供と課題

【Okinawa Open Days 2016】OpenStack 環境におけるContainer as a Service の提供と課題

ライベートクラウド環境におけるコンテナプラットフォームを提供する技術や周辺技術をご紹介させて頂きました。Docker, Kubernete, Swarm を始め、Midonet, Kuryr, Calico, Magnum, Contiv など様々なの OSS がありますが、それぞれの特徴や懸念点など、考慮すべきものがあります。弊社でも Container as a Service の環境を提供するというミッションがあり、そのために検討した結果をお話しさせて頂きました。

De266761b955b2636e454a1bc7a99ed4?s=128

Masaya Aoyama (@amsy810)

December 07, 2016
Tweet

Transcript

  1. OpenStack 環境における Container as a Service の提供と課題 株式会社サイバーエージェント アドテク本部 技術戦略室 Central Infrastructure

    Agency 青山 真也
  2. 自己紹介 •  青山 真也 (あおやま まさや) –  2016 年 4

    月 サイバーエージェントに新卒入社 –  同 6 月 アドテク本部 技術戦略室 CIA へ配属 •  最近の業務内容 –  Container 周り –  OpenStack 周り •  OpenStack Summit Barcelona 2016 16/12/09 2
  3. OpenStack Summit Barcelona 2016 について 参加レポートをまとめています •  [OpenStack Summit Barcelona

    2016] 新卒がミタ! コンテナ技術編 •  [OpenStack Summit Barcelona 2016] 新卒がミタ! 運用改善編 •  [OpenStack Summit Barcelona 2016] 新卒がミタ!先輩 OpenStackerと OpenStack コミュニティ編 16/12/09 3 hBp://adtech.cyberagent.io/techblog/
  4. 目次 •  弊社の現状の環境 •  様々なコンテナ技術と問題点 –  Docker, LXC (LXD) – 

    Kubernetes, COE –  Magnum, Kuryr, Midonet, Calico, ConPv •  弊社の要件と CaaS の構想 •  まとめ 16/12/09 4
  5. 弊社の現状の環境 OpenStack によるプライベートクラウド(弊社アドテク本部単体) –  Over 25000 vCPUs •  シビアな性能を求められるのでオーバコミットはしていません – 

    Over 3500 VMs (with KVM) –  Over 500 Hosts コンテナ環境は 各テナントが VM 上に Kubernetes などのクラスタを構築 ↓ CaaS 環境の提供が必要 16/12/09 5
  6. 様々なコンテナ技術 •  Docker •  LXC (LXD) •  FreeBSD Jail • 

    etc. 現状では  アプリケーションコンテナ = Docker  システムコンテナ = LXC (LXD) 今回対象とするのは Docker –  一部 LXC(LXD) の話を含みます。 16/12/09 6
  7. Docker って? •  Docker Image をもとにしたアプリケーションコンテナ –  アプリケーション + 実行環境

    •  ポータビリティ性が高い –  手元の開発環境のイメージをリモートのサーバにデプロイ –  Docker Hub(イメージ保管 + バージョン管理) •  高速なデプロイ –  数秒で起動 基本的にはスケールさせられるものでの利用が多い …どうやってスケールさせるか? 16/12/09 7
  8. Container OrchestraPon Engine (COE) Docker コンテナのオーケストレーションを行う –  スケールアウト、スケールイン、リソース管理 –  ロードバランシング、ヘルスチェック

    –  再デプロイ、ローリングアップデート 様々な Container OrchestraPon Engine –  Kubernetes –  Swarm –  Mesos –  etc. 今回お話するのは Kubernetes ベース(基本的な出来ることは同じ) 16/12/09 8
  9. ちなみに… GCP GKE と AWS ECS •  Google Container Engine

    (GKE) –  Google Compute Engine 上に Kubernetes クラスタを構築 •  Amazon EC2 Container Service (ECS) –  EC2 上に ECS クラスタを構築(独自のオーケストレーションツール) Google も Amazon も同様に COE を使った環境を提供している スケールさせない 1 コンテナの場合も COE に任せればいい 16/12/09 9
  10. Kubernetes 仮想ネットワーク 16/12/09 10 External network Container-B Container-A Kubernetes のコンテナクラスタへのアクセス方法は主に2パターン

     (ReplicaPonController で作成される Pod への Service は主に 2 パターン) Container-B Container-B Container-A Container-A Service Kubernetes cluster Service flannel internal network VXLAN overlay
  11. Kubernetes 仮想ネットワーク 16/12/09 11 flannel internal network VXLAN overlay NIC

    NIC flannel.1 flannel.1 External network docker0 docker0 minion minion Container-B Container-B Container-A Container-A 192.168.1.1 192.168.1.2 Kubernetes のコンテナクラスタへのアクセス方法は主に2パターン  (ReplicaPonController で作成される Pod への Service は主に 2 パターン)
  12. コンテナクラスタへのアクセス (1) 16/12/09 12 flannel internal network VXLAN overlay NIC

    NIC flannel.1 flannel.1 External network docker0 docker0 minion minion Container-B Container-B Container-A Container-A flannel Internal network の VIP を利用(ClusterIP)  ただし疎通する範囲は Kubenetes のクラスタ内からのみ  = 外部公開はできない 10.254.0.y:80 > Container-A:80 への LB 10.254.0.z:80 > Container-B:80 への LB 192.168.1.1 192.168.1.2
  13. コンテナクラスタへのアクセス (2) 16/12/09 13 flannel internal network VXLAN overlay NIC

    NIC flannel.1 flannel.1 External network docker0 docker0 minion minion Container-B Container-B Container-A Container-A External network を利用(ExternalIP, NodePort)  ポートフォワーディングする形  = 同じポート番号を使用できない 192.168.1.1 192.168.1.2 192.168.1.1:80 192.168.1.2:80 > Container-A:80 への LB 192.168.1.1:8080 192.168.1.2:8080 > Container-B:80 への LB
  14. 素の Kubernetes で満たせない要件 ただ Kubernetes 使ったら? じゃ解決しない問題が多い •  ネットワーク的な機能要件 1.  外部疎通性がない

    2.  任意のポートが利用できない –  但し、コンテナごとに外部疎通性のある IP は必要ない? •  但し、コンテナごとにログイン or シェルが起動できることが望ましい •  その他必要そうな機能要件 –  認証 –  Quota –  セキュリティグループ –  Block Device 16/12/09 14 両方解決するには 外部疎通性のある VIP が必要
  15. 弊社の要件 •  外部疎通性のある VIP が欲しい –  ポートは任意のものが使えるように •  積極的に L3

    agent を使う理由はまだない •  各コンテナに入りたい –  SSH じゃなくても COE のノードにログインできればいい •  NW 分離、Security Group、認証、Quota、BlockDevice •  COE は自由に選びたい –  Kubernetes –  Swarm •  COE on VM は出来れば避けたい 16/12/09 15
  16. 有名どころな技術 CaaS の提供方法はいくつか存在 •  OpenStack 環境用 –  Magnum (Zun) +

    (Heat + Midonet) •  Internal Network の VIP に外部疎通性を持たせる方法 –  Kuryr + Midonet –  Calico •  その他検討した方式 –  ConPv –  Large Kubernetes Cluster 16/12/09 16
  17. OpenStack 環境用コンポーネント 16/12/09 17

  18. Magnum (+ Heat + Midonet) Heat と L3 Network を使って

    COE クラスタを構築 –  インスタンスを作って Ansible/Chef で自動構築に近い ※ Heat: AWS CloudFormaPon に近いコンポーネント ※ 以前までコンテナの作成なども Magnum で行っていましたが、 Newton 以降方針が変わり、kubectl や docker swarm などの CLI で操作するか、 Zun を使って操作するようになりました。 16/12/09 18 nova-VM nova-VM nova-VM ・・・ COE クラスタ(k8s, swarm, etc)
  19. Internal Network の VIP に 外部疎通性を持たせる方法 16/12/09 19

  20. Kubenetes クラスタの変更を検知して Midonet に通達 Midonet + Kuryr 16/12/09 20 NIC

    NIC Midonet Gateway flannel internal network VXLAN overlay External network BGP Peer (RouPng for FloaPng IP) flannel.1 docker0 Container-B Container-A flannel.1 docker0 Container-B Container-A FloaPngIP を利用可能 BGP Router Kuryr
  21. Internal Network の VIP を BGP 伝搬して外部から疎通性を持たせる Calico 16/12/09 21

    NIC NIC Kube-proxy flannel internal network VXLAN overlay External network BGP Peer flannel.1 docker0 Container-B Container-A flannel.1 docker0 Container-B Container-A VIP を External NW の BGP Routerに広報 BGP Router
  22. その他検討した方式 16/12/09 22

  23. ConPv (L2 mode) コンテナの内部 NW を L2 透過で見せる  OpenStack 環境では難しい可能性も(未検証)

    16/12/09 23 Bridge Container Container Container Bridge Container Container Container AggrigaPon SW
  24. Large Kubernetes Cluster Kubernetes で巨大な1つの物理クラスタを構築 –  NG: コンテナが集約しすぎた場合に懸念点がある テナント分離は kubernetes

    の機能を利用する –  OK: Quota, 認証 (Keystone 連携) •  kubernetes の namespace 機能 –  NG: Security Group, Block Storage, NW の分離 •  ポートの奪い合いは前段に LB を配置して解決 16/12/09 24 Overlay (flannel + iptables + VXLAN) Container-B Container-A Container-B Container-C Container-C Container-A 192.168.1.1/24 192.168.1.2/24 192.168.1.3/24
  25. 再掲:コンテナクラスタへのアクセス (2) 16/12/09 25 flannel internal network VXLAN overlay NIC

    NIC flannel.1 flannel.1 External network docker0 docker0 minion minion Container-B Container-B Container-A Container-A External network を利用(ExternalIP, NodePort)  ポートフォワーディングする形  = 同じポート番号を使用できない 192.168.1.1 192.168.1.2 192.168.1.1:80 192.168.1.2:80 > Container-A:80 への LB 192.168.1.1:8080 192.168.1.2:8080 > Container-B:80 への LB
  26. ポート衝突の解決 外部疎通性のある VIP を払い出す –  内部のポート 10001 などは CaaS 提供側が管理

    16/12/09 26 Overlay (flannel + iptables + VXLAN) Container-B Container-A Container-B Container-C Container-C Container-A 192.168.1.1/24 192.168.1.2/24 192.168.1.3/24 :10001 > Container-A:80 10.0.0.1:80 (VIP) > 192.168.0.1:10001 > 192.168.0.2:10001 > 192.168.0.3:10001
  27. ポート衝突の解決 外部疎通性のある VIP を払い出す –  内部のポート 10001 などは CaaS 提供側が管理

    –  VIP を使っているためポートの衝突は起きない 16/12/09 27 Overlay (flannel + iptables + VXLAN) Container-B Container-A Container-B Container-C Container-C Container-A 192.168.1.1/24 192.168.1.2/24 192.168.1.3/24 :10001 > Container-A:80 :10002 > Container-B:80 10.0.0.1:80 (VIP) > 192.168.0.1:10001 > 192.168.0.2:10001 > 192.168.0.3:10001 10.0.0.2:80 (VIP) > 192.168.0.1:10002 > 192.168.0.2:10002 > 192.168.0.3:10002
  28. ポート衝突の解決 外部疎通性のある VIP を払い出す –  内部のポート 10001 などは CaaS 提供側が管理

    –  VIP を使っているためポートの衝突は起きない 必要に応じて同じ VIP を利用することも可能 16/12/09 28 Overlay (flannel + iptables + VXLAN) Container-B Container-A Container-B Container-C Container-C Container-A 192.168.1.1/24 192.168.1.2/24 192.168.1.3/24 :10001 > Container-A:80 :10002 > Container-B:80 :10003 > Container-C:53 10.0.0.1:80 (VIP) > 192.168.0.1:10001 > 192.168.0.2:10001 > 192.168.0.3:10001 10.0.0.2:80 (VIP) > 192.168.0.1:10002 > 192.168.0.2:10002 > 192.168.0.3:10002 10.0.0.1:53 (VIP) > 192.168.0.1:10003 > 192.168.0.2:10003 > 192.168.0.3:10003
  29. 有名どころな解決方法 CaaS の提供方法はいくつか存在 •  OpenStack 環境用 –  Magnum (Zun) +

    (Heat + Midonet) Magnum 単体では k8s が構築できるだけ •  Internal Network の VIP に外部疎通性を持たせる方法 –  Kuryr + Midonet 機能的には十分だがまだ敷居が高い –  Calico 機能的には十分だがまだ敷居が高い •  その他検討した方式 –  ConPv OpenStack 環境では動作が怪しい、コミュニティが見えない –  Large Kubernetes Cluster テナント分離や拡張性に難あり 16/12/09 29 障害時のデバッグが大変 情報が少なめ ProducPon Ready?
  30. じゃあどうするか 16/12/09 30

  31. 弊社の CaaS 環境の構想 16/12/09 31 Overlay (flannel + iptables +

    VXLAN) Container-B Container-A Container-B Container-C Container-C Container-A Overlay (LVS+ iptables + VXLAN) Container-B Container-A Container-B Container-C Container-C Container-A Overlay (flannel + iptables + VXLAN) Container-B Container-A Container-B Container-C Container-C Container-A Overlay (LVS+ iptables + VXLAN) Container-B Container-A Container-B Container-C Container-C Container-A Tenant A Tenant B SNAT の LB を利用した 外部疎通性のある VIP OpenStack 上の各テナント毎に任意の COE クラスタ on nova-lxd Container ※ Docker Image は Swin バックエンドの docker-registry
  32. 弊社の要件 •  外部疎通性のある VIP が欲しい –  ポートは任意のものが使えるように •  積極的に L3

    agent を使う理由はまだない •  各コンテナに入りたい –  SSH じゃなくても COE のノードにログインできればいい •  NW 分離、Security Group、認証、Quota、BlockDevice •  COE は自由に選びたい –  Kubernetes –  Swarm •  COE on VM は避けたい 16/12/09 32 物理の SNAT LB を利用 テナント毎に OpenStack 上に クラスタ構築 nova-lxd 上に構築 OpenStack Heat を使って テンプレートを複数用意
  33. 次期 OpenStack 環境に向けて アプリケーション的な用途  Docker のアプリケーションコンテナ on nova-lxd 従来通りの VM

    的用途  nova-lxd のシステムコンテナ 16/12/09 33 KVM docker nova-lxd nova-lxd 【現状】 【次期環境】 フルコンテナプラットフォームの実現も可能
  34. まとめ 16/12/09 34 OpenStack では FloaPng IP が k8s の

    Service に bind できるのが自然 –  Kuryr + Midonet がコンセプト的には好み とはいえ、障害時のデバッグとかは大変そう… コードを追えるようになるには時間が足りない VIP/LB 周りとかは信頼性のある LB に任せたい 大幅なリスク低減、疎結合なアーキテクチャ 全てコンテナで動かしたい 全部が Docker Container というわけではない
  35. ご静聴ありがとうございました。 16/12/09 35