Tweet
Tweet

Slide 1

Slide 1 text

  OpenStack上に展開する  Container as a Service を 本番で利⽤するために必要だったこと CyberAgent / Adtech Division Masaya Aoyama（@amsy810） Makoto Hasegawa（@makocchi） OpenStack Days Tokyo 2018 Cloud Native Days Tokyo 2018

Slide 2

Slide 2 text

About Us

Slide 3

Slide 3 text

Masaya Aoyama (@amsy810) Infrastructure Engineer Cloud Native Meetup Tokyo Organizer (+ KubeCon⽇本⼈会 + JKD) Japan Container Days v18.04 Keynote 登壇 連載「今こそ始めよう！Kubernetes ⼊⾨」 @ThinkIT CKA #138 / CKAD #2 OpenStack / Kubernetes Contributor

Slide 4

Slide 4 text

２０１８年９⽉２１⽇発売予定 https://bit.ly/k8s-amsy810 Kubernetesの各リソースについて体系的かつ網羅的に説明 Cloud Nativeな開発を促進させる周辺エコシステムについても紹介 ■⽬次案 第1章 なぜKubernetesが必要なのか？ 第2章 Kubernetes環境の選択肢 第3章 APIリソースとkubectl 第4章 Workloadsリソース 第5章 Discovery & LBリソース 第6章 Config & Storageリソース 第7章 ClusterリソースとMetadataリソース 第8章 リソース管理とオートスケーリング 第9章 ヘルスチェックとコンテナのライフサイクル 第10章 メンテナンスとノードの停⽌ 第11章 ⾼度で柔軟なスケジューリング 第12章 セキュリティ 第13章 マニフェストの汎⽤化を⾏うオープンソースソフトウェア 第14章 モニタリング 第15章 コンテナログの集約 第16章 CI/CD環境 第17章 マイクロサービスとServiceMesh 第18章 Kubernetesのアーキテクチャ 第19章 Kubernetesとこれから 付録

Slide 5

Slide 5 text

CKA #150 / CKAD #5 / OPCEL Contributing to OpenStack and Kubernetes Bass Makoto Hasegawa (@makocchi) Infrastructure Engineer

Slide 6

Slide 6 text

OpenStack 上に展開する Container as a Service を本番で利⽤するために必要だったこと TODAY’S AGENDA CyberAgent, Inc and Adtech Studio AKE アドテク領域に 耐えうるネットワーク and 利便性の⾼い プラットフォーム ROADMAP まとめ 01 02 03 04 05

Slide 7

Slide 7 text

CyberAgent, Inc Adtech Studio

Slide 8

Slide 8 text

CyberAgent / adtech studio サイバーエージェントはインターネット広告業界No.1の売上 アドテクノロジー分野の⼦会社の集合体として adtech studioが設⽴ 各サービスの開発部⾨を横断して組織化 Products 20+ Engineers 200+ vCPUs 25000+ VMs 3500+ ⼩さな⼦会社の集合体 ⾃由度が⾼い 新しい技術が好きな傾向 新技術も積極採⽤する⽂化 OpenStackを採⽤ 4 Core or 8 Core が主流

Slide 9

Slide 9 text

AKE

Slide 10

Slide 10 text

AKE Container as a Service Platform OpenStack Heat をベースとして⾃動 deploy POINT #1 OpenStack Integrated な Container クラスタ POINT #2 アドテク領域での利⽤に耐えうる環境 POINT #3 カスタマイズ性の⾼い環境 複数のオーケストレーター、ランタイム、アドオン POINT #4

Slide 11

Slide 11 text

RELIABLE NETWORK PLATFORM Productionで利⽤されるコンテナ基盤 #1 アドテク領域に耐えうるネットワーク   アドテク領域では 10ms〜50ms 以下の RTT が必須 またトラフィック量も 1 システムあたり 300,000 req/s #2 利便性の⾼いプラットフォーム   利⽤者のために、ただそれだけのために 便利になるものは積極的に導⼊する 今回のセッションでは⼤きく分けて 2 つに焦点をあてて発表します。

Slide 12

Slide 12 text

#1 アドテク領域に耐えうるネットワーク

Slide 13

Slide 13 text

Network for Ad-technology For production use “type: LoadBalancer” with HW LoadBalancer Heat Resource Plugins for LoadBalancer GKE-like Ingress Controller

Slide 14

Slide 14 text

Network for Ad-technology “type: LoadBalancer” with HW LoadBalancer Heat Resource Plugins for LoadBalancer GKE-like Ingress Controller For production use

Slide 15

Slide 15 text

Pod Network (Internal Network) NIC NIC IP: x.x.x.x IP: y.y.y.y Kubernetesで起動されるPodのネットワークは外部から疎通性がない 外部のエンドポイントを作成するにはServiceが必要 #1 “type: LoadBalancer” with HW Load Balancer Kubernetes Pod Network VM Network (External Network)

Slide 16

Slide 16 text

Pod Network (Internal Network) NIC NIC IP: x.x.x.x IP: y.y.y.y x.x.x.x:XX 宛のトラフィックが 各 Pod に転送される “type: NodePort” Service VM Network (External Network) #1 “type: LoadBalancer” with HW Load Balancer

Slide 17

Slide 17 text

“type: NodePort” Service Pod Network (Internal Network) NIC NIC IP: x.x.x.x IP: y.y.y.y y.y.y.y:YY 宛のトラフィックも同様に 各 Pod に転送される VM Network (External Network) #1 “type: LoadBalancer” with HW Load Balancer

Slide 18

Slide 18 text

“type: NodePort” Service + Manual LB NIC NIC LoadBalancer BIG-IP GCLB IP: x.x.x.x IP: y.y.y.y NodePort + Manual LoadBalancer VIP: z.z.z.z VIP: z.z.z.z 宛のトラフィックが 各 Pod に転送される NodePort Manual LoadBalancer #1 “type: LoadBalancer” with HW Load Balancer

Slide 19

Slide 19 text

問題点 01 02 03 04 スケール時にLBの操作が必要 Kubernetesで管理できない IPアドレスの管理が必要 SNAPTが必要 ノードの追加時にロードバランサのメンバーとして 追加しなければならない KubernetesのYAMLマニフェストで管理することができない  ≒ コード化することができない 利⽤者がLoadBalancerに割り当てるIPアドレスを 決めなければならない LB > NodePort へはポート変換が必要 DSR環境では利⽤できない #1 “type: LoadBalancer” with HW Load Balancer

Slide 20

Slide 20 text

スケール時にLBの操作が必要 NIC NIC LoadBalancer BIG-IP GCLB IP: x.x.x.x IP: y.y.y.y ノードのスケール時や障害時に LoadBalancer の操作が必要 VIP: z.z.z.z #1 “type: LoadBalancer” with HW Load Balancer

Slide 21

Slide 21 text

スケール時にLBの操作が必要 NIC NIC LoadBalancer BIG-IP GCLB IP: x.x.x.x IP: y.y.y.y ノードのスケール時や障害時に LoadBalancer の操作が必要 VIP: z.z.z.z NIC IP: w.w.w.w #1 “type: LoadBalancer” with HW Load Balancer

Slide 22

Slide 22 text

Kubernetes（マニフェスト）で管理できない #1 “type: LoadBalancer” with HW Load Balancer apiVersion: v1 kind: Service metadata: name: sample-lb spec: type: LoadBalancer ports: - name: "http-port" protocol: "TCP" port: 8080 targetPort: 80 selector: app: sample-app apiVersion: v1 kind: Service metadata: name: sample-lb spec: type: NodePort ports: - name: "http-port" protocol: "TCP" port: 8080 targetPort: 80 selector: app: sample-app LB操作 1. ランダムに割り当てられる NodePort番号を調べる 2. LBに利⽤するIPアドレスを 決める もちろん静的アドレスの設定も可能

Slide 23

Slide 23 text

IPアドレスの管理が必要 #1 “type: LoadBalancer” with HW Load Balancer NIC NIC IP: x.x.x.x IP: y.y.y.y ⼿動でLoadBalancerを作成する場合は 利⽤するIPアドレスを考えなければならない ？ LoadBalancer BIG-IP GCLB

Slide 24

Slide 24 text

IPアドレスの管理が必要 #1 “type: LoadBalancer” with HW Load Balancer apiVersion: v1 kind: Service metadata: name: sample-lb spec: type: LoadBalancer ports: - name: "http-port" protocol: "TCP" port: 8080 targetPort: 80 selector: app: sample-app リソースの作成 NIC NIC LoadBalancer BIG-IP GCLB IP: x.x.x.x IP: y.y.y.y VIP: z.z.z.z

Slide 25

Slide 25 text

SNAPTが必要 = DSR不可 #1 “type: LoadBalancer” with HW Load Balancer NIC NIC LoadBalancer :30080 :30080 VIP: X.X.X.X:80 NIC NIC LoadBalancer :30081 :30081 VIP: Y.Y.Y.Y:80

Slide 26

Slide 26 text

SNAPTが必要 = DSR不可 #1 “type: LoadBalancer” with HW Load Balancer NIC NIC LoadBalancer :30081 :30081 VIP: Y.Y.Y.Y:80 HAProxy HAProxy HAProxy DSR SNAPT 弊社の初期Kubernetes

Slide 27

Slide 27 text

“type: LoadBalancer” Service #1 “type: LoadBalancer” with HW Load Balancer 01 02 03 04 スケール時にLBの操作が必要 Kubernetesで管理できない IPアドレスの管理が必要 SNAPTが必要 NIC NIC LoadBalancer GCLB IP: x.x.x.x IP: y.y.y.y VIP: z.z.z.z

Slide 28

Slide 28 text

“type: LoadBalancer” Service #1 “type: LoadBalancer” with HW Load Balancer Kubernetes CloudProviderが機能を提供 GCP CloudProviderでは  PersistentVolume: GCP Persistent Disk  “type: LoadBalancer”: Google Cloud LoadBalancer OpenStack CloudProviderでは  PersistentVolume: Cinder  “type: LoadBalancer”: Octavia アドテク領域の⽤途では性能不⾜

Slide 29

Slide 29 text

“type: LoadBalancer” Service #1 “type: LoadBalancer” with HW Load Balancer Kubernetes CloudProviderが機能を提供 GCP CloudProviderでは  PersistentVolume: GCP Persistent Disk  “type: LoadBalancer”: Google Cloud LoadBalancer OpenStack CloudProviderでは  PersistentVolume: Cinder  “type: LoadBalancer”: BIG-IP CloudProvider連携を独⾃実装（OpenStack Cloud Providerを改良）  ・BIG-IPの操作  ・使⽤可能なIPアドレスの決定 参考: https://developers.cyberagent.co.jp/blog/archives/12058/ 「GKE 互換のオンプレコンテナ基盤 AKE (Adtech Container Engine) 誕⽣秘話とアーキテクチャ完全公開！」

Slide 30

Slide 30 text

CloudProviderのCoreからの分離 #1 “type: LoadBalancer” with HW Load Balancer 従来はKubernetes Core（kubernetes/kubernetes）に内包されていた https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/openstack 現在は別バイナリとしてCloudProviderが実装されている https://github.com/kubernetes/cloud-provider-openstack Kubernetesバイナリのリビルドが不要 CloudProvider実装の変更をupstreamへ反映不要

Slide 31

Slide 31 text

“type: LoadBalancer” with HW LoadBalancer Heat Resource Plugins for LoadBalancer GKE-like Ingress Controller For production use Network for Ad-technology

Slide 32

Slide 32 text

スケール時のLBへのメンバー追加 NIC NIC BIG-IP Pool IP: x.x.x.x IP: y.y.y.y OS::Heat:ResourceGroupでのスケール時にPool追加 NIC IP: z.z.z.z #2 Heat Resource Plugins for LoadBalancer

Slide 33

Slide 33 text

Heat Resource Plugins for BIG-IP #2 Heat Resource Plugins for LoadBalancer OS::Heat::ResourceGroup の外側 参考: https://adtech.cyberagent.io/techblog/archives/2594 sample_pool: type: ADTECH::AXC::BIGIPPool properties: axcauthtoken: {get_param: axcauthtoken} poolname: {get_param: poolname} mode: {get_param: mode} monitor: {get_param: monitor} sample_poolmember: type: ADTECH::AXC::BIGIPPoolMember properties: axcauthtoken: {get_param: axcauthtoken} poolname: {get_resource: sample_pool} ipaddr: {get_attr: [kubernetes_node_eth0, fixed_ips, 0, ip_address]} port: {get_param: port} ratio: {get_param: ratio} OS::Heat::ResourceGroup の内側（作成されるリソース側）

Slide 34

Slide 34 text

For production use “type: LoadBalancer” with HW LoadBalancer Heat Resource Plugins for LoadBalancer GKE-like Ingress Controller Network for Ad-technology

Slide 35

Slide 35 text

Serviceリソース と Ingress リソース #3 GKE-like Ingress Controller Serviceリソース：L4 LoadBalancer Ingressリソース：L7 LoadBalancer NIC NIC LoadBalancer NIC NIC LoadBalancer over TCP over HTTP パスベースルーティング SSL終端 etc

Slide 36

Slide 36 text

Serviceリソース と Ingress リソース #3 GKE-like Ingress Controller Serviceリソース：L4 LoadBalancer Ingressリソース：L7 LoadBalancer NIC NIC LoadBalancer NIC NIC LoadBalancer over TCP over HTTP パスベースルーティング SSL終端 etc

Slide 37

Slide 37 text

Serviceリソース と Ingress リソース #3 GKE-like Ingress Controller Ingressリソース：L7 LoadBalancer （オンプレ） Ingressリソース：L7 LoadBalancer （GKE） LoadBalancer NIC NIC LoadBalancer パスベースルーティング SSL終端 etc NIC NIC nginx-ingress (L7処理を担当) 厳密にはLB > nginx-ingressの経路は複雑です また、nginx-ingressは各ノードに複数Pod存在します

Slide 38

Slide 38 text

Nginx Ingress Controller Wrapper #3 GKE-like Ingress Controller Create Ingress Resource GKE ingress controller Create Ingress Resource Create Ingress Controller Deployment Create HorizontalPodAutoscaler Create LoadBalancer Service Rewrite Ingress status for IP Addr nginx/nghttpx ingress controller 参考: https://adtech.cyberagent.io/techblog/archives/3758 「オンプレでも GKE Like な Ingress を使うために ⾃作 Ingress Controller を実装してみた」 Create Google Cloud Load Balancer Rewrite Ingress status for IP Addr Auto provisioning

Slide 39

Slide 39 text

Nginx Ingress Controller Wrapper #3 GKE-like Ingress Controller Create Ingress Resource GKE ingress controller Create Ingress Resource Create Ingress Controller Deployment Create HorizontalPodAutoscaler Create LoadBalancer Service Rewrite Ingress status for IP Addr AKE ingress controller 参考: https://adtech.cyberagent.io/techblog/archives/3758 「オンプレでも GKE Like な Ingress を使うために ⾃作 Ingress Controller を実装してみた」 Auto provisioning Create Google Cloud Load Balancer Rewrite Ingress status for IP Addr Auto provisioning

Slide 40

Slide 40 text

#1 Network for Ad-technology “type: LoadBalancer” with HW LoadBalancer Heat Custom Resource for LoadBalancer GKE-like Ingress Controller For production use

Slide 41

Slide 41 text

#2 利便性の⾼いプラットフォーム

Slide 42

Slide 42 text

CONVENIENCE PLATFORM 利便性が⾼いプラットフォームを実現させる為に

Slide 43

Slide 43 text

CONVENIENCE PLATFORM 利便性を向上させる為に⾏った 3 つの仕組み ADDON 様々なアプリケーションの deploy を Addon として提供 Multi COE Deploy するシステムによって COE(Container Orchestration Engine)を 選択可能 OpenStack Integration 認証機能を OpenStack と統合し OpenStack の機能を使⽤することが可能

Slide 44

Slide 44 text

ABOUT ADDON

Slide 45

Slide 45 text

VARIOUS ADDON よく使う機能をAddon形式で提供 Cluster 作成時に指定することで⾃動的に deploy される また既に作成された cluster に対しても addon を on/off することが可能に

Slide 46

Slide 46 text

ABOUT MULTI COE

Slide 47

Slide 47 text

MULTI COE (Container Orchestration Engine) 利⽤者は⽤途に応じて COEを選択することができる ⾼度なシステム構築が必要であれば Kubernetes を、シンプルでよければ Docker Swarm mode を選択することができる

Slide 48

Slide 48 text

02 containerd Docker 内部で使われていてコンテナを起動する機能のみが独⽴したもの 01 Docker 説明するまでもなく世間的に標準となっている Container Runtime Kubernetes only (experimental) MULTI CONTAINER RUNTIME 03 cri-o Kubernetes 専⽤に開発された軽量な Container Runtime

Slide 49

Slide 49 text

ABOUT +OpenStack

Slide 50

Slide 50 text

+OPENSTACK Authentication Keystone と連携することで OpenStack の認証情報を使っ て Cluster にアクセスすること が可能に Volume コンテナから利⽤することができ る volume を cinder で提供 Stateful なアプリケーションも deploy 可能に Scale 作成した cluster は heat の機能 を使って scale in/out すること が可能に

Slide 51

Slide 51 text

ROADMAP OF AKE

Slide 52

Slide 52 text

CI/CD HYBRID ADDON EVOLUTION

Slide 53

Slide 53 text

CI/CD CI/CD INTEGRATION CI/CD との連携を強化して サービス開発者がより開発に集中できるようにしていく HYBRID ADDON EVOLUTION

Slide 54

Slide 54 text

CI/CD INTEGRATION CLOUD NATIVE を加速させる §  モダンな開発スタイルが簡単に始められるように github や spinnaker などとの連携を強化させていく §  例えば AKE cluster 作成時に⾃動的に github と連携さ れ、repository の内容が⾃動的に deploy されるなど 開発やテストの効率を向上させ アプリケーションを より質の⾼いものへと昇華させる

Slide 55

Slide 55 text

CI/CD CI/CD INTEGRATION CI/CD との連携を強化して サービス開発者がより開発に集中できるようにしていく HYBRID ADDON EVOLUTION

Slide 56

Slide 56 text

CI/CD CI/CD INTEGRATION CI/CD との連携を強化して サービス開発者がより開発に集中できるようにしていく HYBRID ADDON EVOLUTION MORE ADDON 利⽤者にとって必要なADDONを増やしていく サービスメッシュや分散トレーシングの環境がすぐ⼊⼿できるように

Slide 57

Slide 57 text

MORE ADDON Istio OpenCensus Jaeger より便利な ADDON の追加 将来的に必要になってくると思われる技術は先取りして 積極的に組み込んでいく 利⽤者側からとの対話を常に⾏い、要望を実装していく 利⽤者側からのフィードバックにも向き合っていく

Slide 58

Slide 58 text

CI/CD CI/CD INTEGRATION CI/CD との連携を強化して サービス開発者がより開発に集中できるようにしていく HYBRID ADDON EVOLUTION MORE ADDON 利⽤者にとって必要なADDONを増やしていく サービスメッシュや分散トレーシングの環境がすぐ⼊⼿できるように

Slide 59

Slide 59 text

CI/CD CI/CD INTEGRATION CI/CD との連携を強化して サービス開発者がより開発に集中できるようにしていく HYBRID ADDON EVOLUTION MORE ADDON 利⽤者にとって必要なADDONを増やしていく サービスメッシュや分散トレーシングの環境がすぐ⼊⼿できるように HYBRID ARCHITECURE Private Cloud の良い所と Public Cloud の良い所を 両⽅活かせるような構成を可能にしていく

Slide 60

Slide 60 text

HYBRID ARCHITECTURE ANY PLATFORM 我々は複数のプラットフォームを選択することができる ANY ADVANTAGE 最適なものを選択することでそれぞれの利点を組み合わせ、 より⼀層の利便性を⽣み出す RUN ANYWHERE 究極的にはアプリケーションがどの platform で動いているのかを 利⽤者側が意識しなくてもよい環境へ導く AKE はこれらを実現させる為の架け橋

Slide 61

Slide 61 text

CI/CD CI/CD INTEGRATION CI/CD との連携を強化して サービス開発者がより開発に集中できるようにしていく HYBRID ADDON EVOLUTION MORE ADDON 利⽤者にとって必要なADDONを増やしていく サービスメッシュや分散トレーシングの環境がすぐ⼊⼿できるように HYBRID ARCHITECURE Private Cloud の良い所と Public Cloud の良い所を 両⽅活かせるような構成を可能にしていく

Slide 62

Slide 62 text

CI/CD CI/CD INTEGRATION CI/CD との連携を強化して サービス開発者がより開発に集中できるようにしていく HYBRID ADDON EVOLUTION HYBRID ARCHITECURE Private Cloud の良い所と Public Cloud の良い所を 両⽅活かせるような構成を可能にしていく MORE ADDON 利⽤者にとって必要なADDONを増やしていく サービスメッシュや分散トレーシングの環境がすぐ⼊⼿できるように EVOLUTION 常に新しい技術を検証し、実装していく

Slide 63

Slide 63 text

EVOLUTION ⼈もシステムも常に進化し ていくことが⼤切 新たな技術は どんどん取り⼊れていく

Slide 64

Slide 64 text

本⽇のまとめ AKE = Adtech Container Engine

Slide 65

Slide 65 text

OpenStack 上に展開する Container as a Service を 本番で利⽤するために必要だったもの 01 04 03 02 アドテク領域に耐えうる ネットワーク HWロードバランサとの連携 Ingress機能のカスタマイズ 利便性の⾼いプラットフォーム Addon機能の実装 Multi COE機能 OpenStack Integration くじけぬ⼼ Public Cloud の進化は激しいが 我々は良い所を吸収して プラットフォームへ実装していく さらなるチューニング Kubernetes の parameter Kernel の parameter Etc….

Slide 66

Slide 66 text

Network Tuning iptables 周りや Hash table サイズ、 connection 周りなどを中⼼にチューニング 今後は CNI 周りの検証も⾏い、更に⾼速化 さらなる Tuning の例 Kernel Tuning ボトルネックとなりそうな箇所のチューニング 4.x 系で⼊ったパラメータも実施 Kubernetes Tuning Master の設定が⾃由に変更できるため、 HPA の間隔やシステムへの割り当てリソース を調整し、最適化 Image Tuning クラスタ構成に必要なバイナリは あらかじめ作成した専⽤の OS Image に格納 起動からクラスタ組み込みまでの時間の ⼤幅な削減に成功

Slide 67

Slide 67 text

  OpenStack上に展開する  Container as a Service を 本番で利⽤するために必要だったこと CyberAgent Adtech Division Masaya Aoyama（@amsy810） Makoto Hasegawa（@makocchi） OpenStack Days Tokyo 2018 Cloud Native Days Tokyo 2018 ご清聴ありがとうございました