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

OpenStack 環境における

Container as a Service の提供と課題

株式会社サイバーエージェント

アドテク本部　技術戦略室　

Central Infrastructure Agency

青山　真也

自己紹介

•  青山 真也 （あおやま まさや） –  2016 年 4 月 サイバーエージェントに新卒入社 –  同 6 月 アドテク本部 技術戦略室 CIA へ配属 •  最近の業務内容 –  Container 周り –  OpenStack 周り •  OpenStack Summit Barcelona 2016

OpenStack Summit Barcelona 2016 について

参加レポートをまとめています

•  [OpenStack Summit Barcelona 2016] 新卒がミタ！ コンテナ技術編 •  [OpenStack Summit Barcelona 2016] 新卒がミタ！ 運用改善編 •  [OpenStack Summit Barcelona 2016] 新卒がミタ！先輩 OpenStackerと OpenStack コミュニティ編

hBp://adtech.cyberagent.io/techblog/

目次

•  弊社の現状の環境 •  様々なコンテナ技術と問題点 –  Docker, LXC (LXD) –  Kubernetes, COE –  Magnum, Kuryr, Midonet, Calico, ConPv •  弊社の要件と CaaS の構想

弊社の現状の環境

OpenStack によるプライベートクラウド（弊社アドテク本部単体） –  Over 25000 vCPUs •  シビアな性能を求められるのでオーバコミットはしていません –  Over 3500 VMs (with KVM) –  Over 500 Hosts コンテナ環境は 各テナントが VM 上に Kubernetes などのクラスタを構築 ↓ CaaS 環境の提供が必要

様々なコンテナ技術

•  Docker •  LXC (LXD) •  FreeBSD Jail •  etc. 現状では 　アプリケーションコンテナ = Docker 　システムコンテナ = LXC (LXD)

Docker って？

•  Docker Image をもとにしたアプリケーションコンテナ –  アプリケーション ₊ 実行環境 •  ポータビリティ性が高い –  手元の開発環境のイメージをリモートのサーバにデプロイ –  Docker Hub（イメージ保管 + バージョン管理） •  高速なデプロイ –  数秒で起動 基本的にはスケールさせられるものでの利用が多い …どうやってスケールさせるか？

Container OrchestraPon Engine （COE）

Docker コンテナのオーケストレーションを行う –  スケールアウト、スケールイン、リソース管理 –  ロードバランシング、ヘルスチェック –  再デプロイ、ローリングアップデート 様々な Container OrchestraPon Engine –  Kubernetes –  Swarm –  Mesos –  etc.

ちなみに

… GCP GKE と AWS ECS

•  Google Container Engine (GKE) –  Google Compute Engine 上に Kubernetes クラスタを構築 •  Amazon EC2 Container Service (ECS) –  EC2 上に ECS クラスタを構築（独自のオーケストレーションツール） Google も Amazon も同様に COE を使った環境を提供している スケールさせない 1 コンテナの場合も COE に任せればいい

Kubernetes 仮想ネットワーク

NIC NIC External network docker0 docker0 Container-B Container-B Container-A Container-A 192.168.1.1 192.168.1.2 Kubernetes のコンテナクラスタへのアクセス方法は主に２パターン 　（_{ReplicaPonController で作成される Pod への Service は主に 2 パターン）}

コンテナクラスタへのアクセス

(1)

flannel internal network 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

コンテナクラスタへのアクセス

(2)

NIC NIC External network docker0 docker0 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

素の

Kubernetes で満たせない要件

•  ネットワーク的な機能要件 –  任意のポートが必要 –  外部疎通性のある IP が必要 –  コンテナごとに外部疎通性のある IP は必要ない？ •  但し、コンテナごとにログイン or シェルが起動できることが望ましい •  その他必要そうな機能要件 –  認証 –  Quota –  セキュリティグループ –  Block Device 外部疎通性のある VIP が必要

弊社の要件

•  外部疎通性のある VIP が欲しい –  ポートは任意のものが使えるように •  積極的に L3 agent を使う理由はまだない •  各コンテナに入りたい –  SSH じゃなくても COE のノードにログインできればいい •  NW 分離、Security Group、認証、Quota、BlockDevice •  COE on VM は出来れば避けたい

有名どころな技術

CaaS の提供方法はいくつか存在 •  OpenStack 環境用 –  Magnum (Zun) + (Heat + Midonet) •  Internal Network の VIP に外部疎通性を持たせる方法 –  Kuryr + Midonet –  Calico •  その他検討した方式 –  ConPv –  Large Kubernetes Cluster

Magnum (+ Heat + Midonet)

Heat と L3 Network を使って COE クラスタを構築 –  インスタンスを作って Ansible/Chef で自動構築に近い ※ Heat: AWS CloudFormaPon に近いコンポーネント ※ 以前までコンテナの作成なども _{Magnum で行っていましたが、} Newton 以降方針が変わり、kubectl や docker swarm などの CLI で操作するか、 Zun を使って操作するようになりました。 nova-VM nova-VM nova-VM ・・・ COE クラスタ（k8s, swarm, etc）

Internal Network の VIP に

外部疎通性を持たせる方法

Midonet + Kuryr

Kubernetes クラスタへの変更を検知して Neutron を操作 　　外部からの疎通性がなかった VIP に FloaPng IP を利用可能 flannel internal network 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 VIP に対して FloaPngIP を利用可能

Internal Network の VIP を BGP 伝搬して外部から疎通性を持たせる

Calico

NIC NIC Kube-proxy External network BGP Peer docker0 Container-B Container-A docker0 Container-B Container-A VIP を External NW の BGP Routerに広報 BGP Router

ConPv (L2 mode)

コンテナの内部 NW を L2 透過で見せる 　OpenStack 環境では難しい可能性も（未検証） Bridge Container Bridge Container AggrigaPon SW

Large Kubernetes Cluster

Kubernetes で巨大な1つの物理クラスタを構築

–  OK: Quota, 認証 _{(Keystone 連携)} •  kubernetes の namespace 機能

–  NG: NW の分離_{, Security Group, Block Storage}

•  ポートの奪い合いは前段に LB を配置して解決 Overlay (flannel + iptables + VXLAN) Container-B Container-A Container-B Container-C Container-C Container-A :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

有名どころな解決方法

CaaS の提供方法はいくつか存在 •  OpenStack 環境用 –  Magnum (Zun) + (Heat + Midonet)　Magnum 単体では k8s が構築できるだけ •  Internal Network の VIP に外部疎通性を持たせる方法 –  Kuryr + Midonet　機能的には十分だがまだ敷居が高い –  Calico　機能的には十分だがまだ敷居が高い •  その他検討した方式 障害時のデバッグが大変 情報が少なめ ProducPon Ready?

弊社の

CaaS 環境の構想

Overlay (flannel + iptables + VXLAN) Overlay (LVS+ iptables + VXLAN) 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

弊社の要件

•  外部疎通性のある VIP が欲しい –  ポートは任意のものが使えるように •  積極的に L3 agent を使う理由はまだない •  各コンテナに入りたい –  SSH じゃなくても COE のノードにログインできればいい •  NW 分離、Security Group、認証、Quota、BlockDevice •  COE on VM は避けたい 物理の SNAT LB を利用 テナント毎に OpenStack 上に クラスタ構築 nova-lxd 上に構築

次期

OpenStack 環境に向けて

アプリケーション的な用途 　Docker のアプリケーションコンテナ on nova-lxd 従来通りの VM 的用途 　nova-lxd のシステムコンテナ KVM docker nova-lxd nova-lxd 【現状】 【次期環境】

まとめ

OpenStack では FloaPng IP が k8s の Service に bind できるのが自然 –  Kuryr + Midonet がコンセプト的には好み とはいえ、障害時のデバッグとかは大変そう… コードを追えるようになるには時間が足りない VIP/LB 周りとかは信頼性のある LB に任せたい 大幅なリスク低減、疎結合なアーキテクチャ