OpenStack上に展開するContainer as a Service を本番で利用するために必要だったこと

OpenStack上に展開するContainer as a Service を本番で利用するために必要だったこと
at OpenStack Days / Cloud Native Days 2018

CyberAgent, Inc
adtech studio
Strategic Infrastructure Agency

@amsy810
@makocchi

Transcript

1.   OpenStack上に展開する  Container as a Service を 本番で利⽤するために必要だったこと CyberAgent / Adtech Division Masaya Aoyama（@amsy810） Makoto Hasegawa（@makocchi） OpenStack Days Tokyo 2018 Cloud Native Days Tokyo 2018
2. About Us
3. 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
4. ２０１８年９⽉２１⽇発売予定 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とこれから 付録
5. CKA #150 / CKAD #5 / OPCEL Contributing to OpenStack and Kubernetes Bass Makoto Hasegawa (@makocchi) Infrastructure Engineer
6. OpenStack 上に展開する Container as a Service を本番で利⽤するために必要だったこと TODAY’S AGENDA CyberAgent, Inc and Adtech Studio AKE アドテク領域に 耐えうるネットワーク and 利便性の⾼い プラットフォーム ROADMAP まとめ 01 02 03 04 05
7. CyberAgent, Inc Adtech Studio
8. CyberAgent / adtech studio サイバーエージェントはインターネット広告業界No.1の売上 アドテクノロジー分野の⼦会社の集合体として adtech studioが設⽴ 各サービスの開発部⾨を横断して組織化 Products 20+ Engineers 200+ vCPUs 25000+ VMs 3500+ ⼩さな⼦会社の集合体 ⾃由度が⾼い 新しい技術が好きな傾向 新技術も積極採⽤する⽂化 OpenStackを採⽤ 4 Core or 8 Core が主流
9. AKE
10. AKE Container as a Service Platform OpenStack Heat をベースとして⾃動 deploy POINT #1 OpenStack Integrated な Container クラスタ POINT #2 アドテク領域での利⽤に耐えうる環境 POINT #3 カスタマイズ性の⾼い環境 複数のオーケストレーター、ランタイム、アドオン POINT #4
11. RELIABLE NETWORK PLATFORM Productionで利⽤されるコンテナ基盤 #1 アドテク領域に耐えうるネットワーク   アドテク領域では 10ms〜50ms 以下の RTT が必須 またトラフィック量も 1 システムあたり 300,000 req/s #2 利便性の⾼いプラットフォーム   利⽤者のために、ただそれだけのために 便利になるものは積極的に導⼊する 今回のセッションでは⼤きく分けて 2 つに焦点をあてて発表します。
12. #1 アドテク領域に耐えうるネットワーク
13. Network for Ad-technology For production use “type: LoadBalancer” with HW LoadBalancer Heat Resource Plugins for LoadBalancer GKE-like Ingress Controller
14. Network for Ad-technology “type: LoadBalancer” with HW LoadBalancer Heat Resource Plugins for LoadBalancer GKE-like Ingress Controller For production use
15. 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)
16. 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
17. “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
18. “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
19. 問題点 01 02 03 04 スケール時にLBの操作が必要 Kubernetesで管理できない IPアドレスの管理が必要 SNAPTが必要 ノードの追加時にロードバランサのメンバーとして 追加しなければならない KubernetesのYAMLマニフェストで管理することができない  ≒ コード化することができない 利⽤者がLoadBalancerに割り当てるIPアドレスを 決めなければならない LB > NodePort へはポート変換が必要 DSR環境では利⽤できない #1 “type: LoadBalancer” with HW Load Balancer
20. スケール時に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
21. スケール時に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
22. 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アドレスを 決める もちろん静的アドレスの設定も可能
23. 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
24. 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
25. 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
26. 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
27. “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
28. “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 アドテク領域の⽤途では性能不⾜
29. “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) 誕⽣秘話とアーキテクチャ完全公開！」
30. 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へ反映不要
31. “type: LoadBalancer” with HW LoadBalancer Heat Resource Plugins for LoadBalancer GKE-like Ingress Controller For production use Network for Ad-technology
32. スケール時の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
33. 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 の内側（作成されるリソース側）
34. For production use “type: LoadBalancer” with HW LoadBalancer Heat Resource Plugins for LoadBalancer GKE-like Ingress Controller Network for Ad-technology
35. 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
36. 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
37. 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存在します
38. 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
39. 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
40. #1 Network for Ad-technology “type: LoadBalancer” with HW LoadBalancer Heat Custom Resource for LoadBalancer GKE-like Ingress Controller For production use
41. #2 利便性の⾼いプラットフォーム
42. CONVENIENCE PLATFORM 利便性が⾼いプラットフォームを実現させる為に
43. CONVENIENCE PLATFORM 利便性を向上させる為に⾏った 3 つの仕組み ADDON 様々なアプリケーションの deploy を Addon として提供 Multi COE Deploy するシステムによって COE(Container Orchestration Engine)を 選択可能 OpenStack Integration 認証機能を OpenStack と統合し OpenStack の機能を使⽤することが可能
44. ABOUT ADDON
45. VARIOUS ADDON よく使う機能をAddon形式で提供 Cluster 作成時に指定することで⾃動的に deploy される また既に作成された cluster に対しても addon を on/off することが可能に
46. ABOUT MULTI COE
47. MULTI COE (Container Orchestration Engine) 利⽤者は⽤途に応じて COEを選択することができる ⾼度なシステム構築が必要であれば Kubernetes を、シンプルでよければ Docker Swarm mode を選択することができる
48. 02 containerd Docker 内部で使われていてコンテナを起動する機能のみが独⽴したもの 01 Docker 説明するまでもなく世間的に標準となっている Container Runtime Kubernetes only (experimental) MULTI CONTAINER RUNTIME 03 cri-o Kubernetes 専⽤に開発された軽量な Container Runtime
49. ABOUT +OpenStack
50. +OPENSTACK Authentication Keystone と連携することで OpenStack の認証情報を使っ て Cluster にアクセスすること が可能に Volume コンテナから利⽤することができ る volume を cinder で提供 Stateful なアプリケーションも deploy 可能に Scale 作成した cluster は heat の機能 を使って scale in/out すること が可能に
51. ROADMAP OF AKE
52. CI/CD HYBRID ADDON EVOLUTION
53. CI/CD CI/CD INTEGRATION CI/CD との連携を強化して サービス開発者がより開発に集中できるようにしていく HYBRID ADDON EVOLUTION
54. CI/CD INTEGRATION CLOUD NATIVE を加速させる §  モダンな開発スタイルが簡単に始められるように github や spinnaker などとの連携を強化させていく §  例えば AKE cluster 作成時に⾃動的に github と連携さ れ、repository の内容が⾃動的に deploy されるなど 開発やテストの効率を向上させ アプリケーションを より質の⾼いものへと昇華させる
55. CI/CD CI/CD INTEGRATION CI/CD との連携を強化して サービス開発者がより開発に集中できるようにしていく HYBRID ADDON EVOLUTION
56. CI/CD CI/CD INTEGRATION CI/CD との連携を強化して サービス開発者がより開発に集中できるようにしていく HYBRID ADDON EVOLUTION MORE ADDON 利⽤者にとって必要なADDONを増やしていく サービスメッシュや分散トレーシングの環境がすぐ⼊⼿できるように
57. MORE ADDON Istio OpenCensus Jaeger より便利な ADDON の追加 将来的に必要になってくると思われる技術は先取りして 積極的に組み込んでいく 利⽤者側からとの対話を常に⾏い、要望を実装していく 利⽤者側からのフィードバックにも向き合っていく
58. CI/CD CI/CD INTEGRATION CI/CD との連携を強化して サービス開発者がより開発に集中できるようにしていく HYBRID ADDON EVOLUTION MORE ADDON 利⽤者にとって必要なADDONを増やしていく サービスメッシュや分散トレーシングの環境がすぐ⼊⼿できるように
59. CI/CD CI/CD INTEGRATION CI/CD との連携を強化して サービス開発者がより開発に集中できるようにしていく HYBRID ADDON EVOLUTION MORE ADDON 利⽤者にとって必要なADDONを増やしていく サービスメッシュや分散トレーシングの環境がすぐ⼊⼿できるように HYBRID ARCHITECURE Private Cloud の良い所と Public Cloud の良い所を 両⽅活かせるような構成を可能にしていく
60. HYBRID ARCHITECTURE ANY PLATFORM 我々は複数のプラットフォームを選択することができる ANY ADVANTAGE 最適なものを選択することでそれぞれの利点を組み合わせ、 より⼀層の利便性を⽣み出す RUN ANYWHERE 究極的にはアプリケーションがどの platform で動いているのかを 利⽤者側が意識しなくてもよい環境へ導く AKE はこれらを実現させる為の架け橋
61. CI/CD CI/CD INTEGRATION CI/CD との連携を強化して サービス開発者がより開発に集中できるようにしていく HYBRID ADDON EVOLUTION MORE ADDON 利⽤者にとって必要なADDONを増やしていく サービスメッシュや分散トレーシングの環境がすぐ⼊⼿できるように HYBRID ARCHITECURE Private Cloud の良い所と Public Cloud の良い所を 両⽅活かせるような構成を可能にしていく
62. CI/CD CI/CD INTEGRATION CI/CD との連携を強化して サービス開発者がより開発に集中できるようにしていく HYBRID ADDON EVOLUTION HYBRID ARCHITECURE Private Cloud の良い所と Public Cloud の良い所を 両⽅活かせるような構成を可能にしていく MORE ADDON 利⽤者にとって必要なADDONを増やしていく サービスメッシュや分散トレーシングの環境がすぐ⼊⼿できるように EVOLUTION 常に新しい技術を検証し、実装していく
63. EVOLUTION ⼈もシステムも常に進化し ていくことが⼤切 新たな技術は どんどん取り⼊れていく
64. 本⽇のまとめ AKE = Adtech Container Engine
65. OpenStack 上に展開する Container as a Service を 本番で利⽤するために必要だったもの 01 04 03 02 アドテク領域に耐えうる ネットワーク HWロードバランサとの連携 Ingress機能のカスタマイズ 利便性の⾼いプラットフォーム Addon機能の実装 Multi COE機能 OpenStack Integration くじけぬ⼼ Public Cloud の進化は激しいが 我々は良い所を吸収して プラットフォームへ実装していく さらなるチューニング Kubernetes の parameter Kernel の parameter Etc….
66. Network Tuning iptables 周りや Hash table サイズ、 connection 周りなどを中⼼にチューニング 今後は CNI 周りの検証も⾏い、更に⾼速化 さらなる Tuning の例 Kernel Tuning ボトルネックとなりそうな箇所のチューニング 4.x 系で⼊ったパラメータも実施 Kubernetes Tuning Master の設定が⾃由に変更できるため、 HPA の間隔やシステムへの割り当てリソース を調整し、最適化 Image Tuning クラスタ構成に必要なバイナリは あらかじめ作成した専⽤の OS Image に格納 起動からクラスタ組み込みまでの時間の ⼤幅な削減に成功
67.   OpenStack上に展開する  Container as a Service を 本番で利⽤するために必要だったこと CyberAgent Adtech Division Masaya Aoyama（@amsy810） Makoto Hasegawa（@makocchi） OpenStack Days Tokyo 2018 Cloud Native Days Tokyo 2018 ご清聴ありがとうございました