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

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

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 のコンテナクラスタへのアクセス方法は主に２パターン 　（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 のコンテナクラスタへのアクセス方法は主に２パターン 　（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