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

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

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

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

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

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

CyberAgent, Inc
Adtech Studio

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

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

RELIABLE NETWORK PLATFORM
Productionで利⽤されるコンテナ基盤
#1 アドテク領域に耐えうるネットワーク

アドテク領域では 10ms〜50ms 以下の RTT が必須
またトラフィック量も 1 システムあたり 300,000 req/s
#2 利便性の⾼いプラットフォーム

利⽤者のために、ただそれだけのために
便利になるものは積極的に導⼊する
今回のセッションでは⼤きく分けて 2 つに焦点をあてて発表します。

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

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

For production use

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)

Pod Network
(Internal Network)
NIC NIC
x.x.x.x:XX 宛のトラフィックが
各 Pod に転送される
“type: NodePort” Service
VM Network
(External Network)

“type: NodePort” Service
Pod Network
(Internal Network)
NIC NIC
y.y.y.y:YY 宛のトラフィックも同様に
VM Network
(External Network)

“type: NodePort” Service + Manual LB
NIC NIC
LoadBalancer
BIG-IP GCLB
NodePort
+ Manual LoadBalancer
VIP: z.z.z.z
VIP: z.z.z.z 宛のトラフィックが
NodePort
Manual LoadBalancer

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

NIC NIC
LoadBalancer
BIG-IP GCLB
ノードのスケール時や障害時に
LoadBalancer の操作が必要 VIP: z.z.z.z

NIC NIC
LoadBalancer
BIG-IP GCLB
ノードのスケール時や障害時に
LoadBalancer の操作が必要 VIP: z.z.z.z
NIC
IP: w.w.w.w

Kubernetes（マニフェスト）で管理できない
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アドレスを
決める
もちろん静的アドレスの設定も可能

NIC NIC
⼿動でLoadBalancerを作成する場合は
利⽤するIPアドレスを考えなければならない
？
LoadBalancer
BIG-IP GCLB

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
VIP: z.z.z.z

SNAPTが必要 = DSR不可
NIC NIC
LoadBalancer
:30080 :30080
VIP: X.X.X.X:80
NIC NIC
LoadBalancer
:30081 :30081
VIP: Y.Y.Y.Y:80

SNAPTが必要 = DSR不可
NIC NIC
LoadBalancer
:30081 :30081
VIP: Y.Y.Y.Y:80
HAProxy
HAProxy
HAProxy
DSR
SNAPT
弊社の初期Kubernetes

“type: LoadBalancer” Service
01
02
03
04
Kubernetesで管理できない
SNAPTが必要
NIC NIC
LoadBalancer
GCLB
VIP: z.z.z.z

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

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) 誕⽣秘話とアーキテクチャ完全公開！」

CloudProviderのCoreからの分離
従来は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へ反映不要

For production use

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

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 の内側（作成されるリソース側）

For production use

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

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

Nginx Ingress Controller Wrapper
Create Ingress Resource
GKE
ingress controller
Create Ingress Controller Deployment
Create HorizontalPodAutoscaler
Create LoadBalancer Service
Rewrite Ingress status for IP Addr
nginx/nghttpx
ingress controller
「オンプレでも GKE Like な Ingress を使うために⾃作 Ingress Controller を実装してみた」
Create Google Cloud Load Balancer
Auto provisioning

Nginx Ingress Controller Wrapper
GKE
ingress controller
Create Ingress Controller Deployment
Create HorizontalPodAutoscaler
Create LoadBalancer Service
AKE
ingress controller
「オンプレでも GKE Like な Ingress を使うために⾃作 Ingress Controller を実装してみた」
Auto provisioning
Create Google Cloud Load Balancer
Auto provisioning

#1 Network for Ad-technology
Heat Custom Resource for LoadBalancer
For production use

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

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

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

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

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

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

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

CI/CD
HYBRID
ADDON
EVOLUTION

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

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

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

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

CI/CD
CI/CD INTEGRATION
HYBRID
ADDON
EVOLUTION
MORE ADDON
HYBRID ARCHITECURE
Private Cloud の良い所と Public Cloud の良い所を
両⽅活かせるような構成を可能にしていく

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

CI/CD
CI/CD INTEGRATION
HYBRID
ADDON
EVOLUTION
HYBRID ARCHITECURE
Private Cloud の良い所と Public Cloud の良い所を
両⽅活かせるような構成を可能にしていく
MORE ADDON
EVOLUTION
常に新しい技術を検証し、実装していく

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

本⽇のまとめ
AKE = Adtech Container Engine

OpenStack 上に展開する Container as a Service を
本番で利⽤するために必要だったもの
01
04 03
02
アドテク領域に耐えうる
ネットワーク
HWロードバランサとの連携
Ingress機能のカスタマイズ
利便性の⾼いプラットフォーム

Addon機能の実装
Multi COE機能
OpenStack Integration
くじけぬ⼼

Public Cloud の進化は激しいが
我々は良い所を吸収して
プラットフォームへ実装していく

さらなるチューニング

Kubernetes の parameter
Kernel の parameter
Etc….

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

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

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

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

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

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