タイトル：CyberAgent: How We Deployed Production Kubernetes Clusters on OpenStack without L3 Network 講師：青山さん＠サイバーエージェント

1. CyberAgent: How We Deployed
Production Kubernetes Clusters
on OpenStack without L3 Network

2. 青山 真也 (Masaya Aoyama)
普段の主な仕事↓
世界で 138 番目
https://adtech.cyberagent.io/techblog/
archives/3086

3. adtech studio のプライベートクラウド環境
・OpenStack をベースとしたプライベートクラウド環境
・Network のレイテンシが許容されないアドテクシステム
そんな弊社にも Production で利用可能な
GKE ライクなコンテナ基盤
AKE （Adtech Container Engine）

4. GKE が Google Kubernetes Engine に
GKE = Google Container Engine AKE = Adtech Container Engine
参考:
https://cloudplatform.googleblog.com/2017/11/introducing-Certified-Kubernetes-and-Google-Kubernetes-Engine.html?utm_source=feedburner&ut
m_medium=feed&utm_campaign=Feed:+ClPlBl+(Cloud+Platform+Blog)

5. みなさん Kubernetes って
どういう環境で利用されていますか？

6. L3 Network の機能が必要
LoadBalancer as a Service が必要
細かい設定が困難
成熟度が高くはない
OpenStack 界隈の方々だと…

7. AKE の場合

8. Resource Group として作成し、スケーリング可能に
Interface は別の Resource Group として作成し、
Master 構築時に全 IP Address を利用（etcd など）

9. Heat の Custom Resource Plugins を自作
LoadBalancer を操作して VIP の払い出し
（自動割当て機構を含む）
参考: https://adtech.cyberagent.io/techblog/archives/2594

10. Designate を使った簡易 DNS Round Robin
クライアントからはクラスタ名だけで疎通可能になる VIPが
必要な場合、CLI からopenstack stack show して
取得する必要があるが、結構レスポンスが悪いので …

11. Kubernetes の OpenStack Integration 機能（後述）を
有効化する設定をした Kubernetes をデプロイ

12. 素の Kubernetes を構築した場合
① Dynamic Persistent Volume Provisioning が使えない
○ PVC の要求に応じて PV を動的に払い出す機能
3 GB の Persistent Volume
頂戴！
5 GBの Persistent Volume
あげる！
5GB
10 GB
7 GB
事前に作成
事前に作成する手間、容量の無駄が発生しやすい

13. 素の Kubernetes を構築した場合
① Dynamic Persistent Volume Provisioning が使えない
○ PVC の要求に応じて PV を動的に払い出す機能
3 GB の Persistent Volume
頂戴！
3 GBの Persistent Volume
あげる！
3 GB
欲しいって言われたから
作って渡そう
利用者の管理コストが低下

14. おいでおいで〜
…

15. 素の Kubernetes を構築した場合
② type LoadBalancer Service が使えない
○ クラスタ外 LoadBalancer を作成する機能

16. 別の手段: type NodePort の話
eth0: 10.0.0.1:34567
VM α
Kubernets node
Internal
VM β
Kubernets node
apiVersion: v1
kind: Service
metadata:
name: svc1
spec:
type: NodePort
ports:
- name: "http-port"
protocol: "TCP"
port: 80
targetPort: 80
eth0: 10.0.0.2:34567

17. AKE 1.0 の構成 (NodePort + Metal LB)
eth0: 10.0.0.1:34567
VM α
Kubernets node
Internal
VM β
Kubernets node
52.0.0.1:80
LoadBalancer
External
apiVersion: v1
kind: Service
metadata:
name: svc1
spec:
type: NodePort
ports:
- name: "http-port"
protocol: "TCP"
port: 80
targetPort: 80
52.0.0.1:80
> 10.0.0.1:34567
> 10.0.0.2:34567
（別途登録が必要）
eth0: 10.0.0.2:34567
SNAT + NAPT

18. AKE 1.0 の構成 (NodePort + Metal LB + (HAProxy))
VM α
Kubernets node
Internal
VM β
Kubernets node
52.0.0.1:80
LoadBalancer
(+ HAProxy)
External
52.0.0.1:80
> 10.0.0.1:34567
> 10.0.0.2:34567
（別途登録が必要）
apiVersion: v1
kind: Service
metadata:
name: svc1
spec:
type: NodePort
ports:
- name: "http-port"
protocol: "TCP"
port: 80
targetPort: 80
eth0: 10.0.0.1:34567 eth0: 10.0.0.2:34567
SNAT + NAPT

19. This is a slide title
① SNAT, NAPT が必須な構成
ボトルネック or リソースが必要
② 外部のコマンドでやってもらうの不便
自動 IP 払い出しとかも無い上、二度手間

20. おいでおいで〜
…

21. 機能の実現と Cloud Provider
① Dynamic Persistent Volume Provisioning
● Kubernetes の Cloud Provider 連携機能を利用
● Persistent Volume Plugin (ScaleIO, Flusterfs)
② type LoadBalancer
● Kubernetes の Cloud Provider 連携機能を利用
○ 純粋なベアメタル/VM で Cloud Provider 連携してない場合は？
○ OpenStack で LBaaS 機能を利用していない場合は？
■ Neutron L3 Agent、Octavia は未使用

22. Kubernetes の CoudProvider プラグイン
CloudProvider プラグインには主に下記のようなものがあります
● Routing
● Host
● Zone
● BlockDevice
● LoadBalancer (今回はここの話)
（参考）
インターフェースの一覧: pkg/cloudprovider/cloud.go
OpenStack の場合、pkg/cloudprovider/providers/openstack/* 辺り

23. This is a slide title
今回は AKE の中でも、
LoadBalancer 周りの話をします。

24. Kubernetes の CloudProvider 連携機能（LBaaS）
① CloudProvider 連携で Neutron に LB の作成依頼
② Octavia で LB を作成（LBaaS v1 は 1.8.0 で打ち切り）

25. This is a slide titleKubernetes の CloudProvider 連携機能（LBaaS）
① CloudProvider 連携で Neutron に LB の作成依頼
② BIG-IP で LB を作成（多分プラグイン書けばいけるのかな…）

26. This is a slide titleKubernetes の CloudProvider 連携機能（LBaaS）
① Kubernetes の CloudProvider 連携のコードを変更して、
直接 BIG-IP を操作

27. This is a slide title
① 外部 LoadBalancer の操作
② IP 払い出しの自動化

28. LoadBalancer 用の Interface
GetLoadBalancer(clusterName string, service *v1.Service)
・あまり変える部分はない
EnsureLoadBalancer(clusterName string, service *v1.Service, nodes []*v1.Node)
・LoadBalancer を作成する、IP の指定がない場合は自動アサイン
UpdateLoadBalancer(clusterName string, service *v1.Service, nodes []*v1.Node)
・LoadBalancer を更新する
EnsureLoadBalancerDeleted(clusterName string, service *v1.Service)
・LoadBalancer を削除する
大まかには上記 3 種類の Interface を実装してあげる形
渡ってくる構造体に必要な情報は大体揃っている
service.Name
service.Spec.LoadBalancerIP
service.Spec.Ports[].Port
service.Spec.Ports[].TargetPort
nodes.[].Name

29. 今後オンプレにより求められるのは、
パブリッククラウドとのシームレスな統合
コンテナ環境だとなおさら移行し易い
GKE > AKE ＆ AKE > GKE
これでマルチクラウドでの展開も容易に

30. This is a slide title
ちょっとまった
Ingress ってのもいるよね？

31. おいでおいで〜
…

32. 残すところ Ingress
HTTP LoadBalancer を提供する Ingress
● GKE 様だと L7 GCLB 様がいらっしゃられる
● それ以外は {nginx, nghttpx}-ingress-controller を使う
○ ちょっと使い勝手が悪い、手間が多い、 GKE とは結構違う
現在 GKE Like に Ingress を使えるように controller を実装中。
● 12/1 の Kubernetes Advent Calender で公開予定

33. This is a slide title
付録

34. AKE 1.0 の構成 (NodePort + Metal LB)
eth0: 10.0.0.1:34567
VM α
Kubernets node
Internal
VM β
Kubernets node
52.0.0.1:80
LoadBalancer
External
apiVersion: v1
kind: Service
metadata:
name: svc1
spec:
type: NodePort
ports:
- name: "http-port"
protocol: "TCP"
port: 80
targetPort: 80
52.0.0.1:80
> 10.0.0.1:34567
> 10.0.0.2:34567
（cli で登録が必要）
eth0: 10.0.0.2:34567

35. AKE 1.0 の構成 (NodePort + Metal LB + (HAProxy))
VM α
Kubernets node
Internal
VM β
Kubernets node
52.0.0.1:80
LoadBalancer
(+ HAProxy)
External
52.0.0.1:80
> 10.0.0.1:34567
> 10.0.0.2:34567
（cli で登録が必要）
apiVersion: v1
kind: Service
metadata:
name: svc1
spec:
type: NodePort
ports:
- name: "http-port"
protocol: "TCP"
port: 80
targetPort: 80
eth0: 10.0.0.1:34567 eth0: 10.0.0.2:34567

36. SNAT, NAPT ができない場合
VM α
Kubernets node
Internal
VM β
Kubernets node
52.0.0.1:80
LoadBalancer
External
仮に Service が増えたことを考えると、
こんな感じになります
52.0.0.1:80
> VM α:80
> VM β:80
52.0.0.2:80
> VM α:80
> VM β:80
lo.0: 52.0.0.1:80
lo.1: 52.0.0.2:80
lo.0: 52.0.0.1:80
lo.1: 52.0.0.2:80

37. SNAT, NAPT ができない場合
VM α
Kubernets node
Internal
VM β
Kubernets node
52.0.0.1:80
LoadBalancer
External
52.0.0.1:80
> VM α:80
> VM β:80
52.0.0.2:80
> VM α:80
> VM β:80
NodePort は Interface 全てで
Bind されてしまうため利用出来ない
例: *:80
apiVersion: v1
kind: Service
metadata:
name: svc2
spec:
type: NodePort
ports:
- name: "http-port"
protocol: "TCP"
port: 80
targetPort: 80
apiVersion: v1
kind: Service
metadata:
name: svc1
spec:
type: NodePort
ports:
- name: "http-port"
protocol: "TCP"
port: 80
targetPort: 80
lo.0: 52.0.0.1:80
lo.1: 52.0.0.2:80
lo.0: 52.0.0.1:80
lo.1: 52.0.0.2:80

38. SNAT, NAPT ができない場合
VM α
Kubernets node
Internal
VM β
Kubernets node
52.0.0.1:80
LoadBalancer
External
externalIPs 使えば
いけないことも無いが …
利便性が著しく低い
…
metadata:
name: svc1
spec:
externalIPs:
- 52.0.0.1
ports:
- name: "http-port"
protocol: "TCP"
port: 80
targetPort: 80
52.0.0.1:80
> VM α:80
> VM β:80
52.0.0.2:80
> VM α:80
> VM β:80
…
metadata:
name: svc2
spec:
externalIPs:
- 52.0.0.2
ports:
- name: "http-port"
protocol: "TCP"
port: 80
targetPort: 80
lo.0: 52.0.0.1:80
lo.1: 52.0.0.2:80
lo.0: 52.0.0.1:80
lo.1: 52.0.0.2:80

39. This is a slide title
① SNAT, NAPT が必須な構成
ボトルネック or リソースが必要
② 外部のコマンドでやってもらうの不便
やっぱりGKE がいいって言われる

40. VM α
Kubernets node
Internal
VM β
Kubernets node
52.0.0.1:80
LoadBalancer
External
52.0.0.1:80
> VM α:80
> VM β:80
52.0.0.2:80
> VM α:80
> VM β:80
apiVersion: v1
kind: Service
metadata:
name: svc2
spec:
type: ClusterIP
ports:
- name: "http-port"
protocol: "TCP"
port: 80
targetPort: 80
apiVersion: v1
kind: Service
metadata:
name: svc1
spec:
type: ClusterIP
ports:
- name: "http-port"
protocol: "TCP"
port: 80
targetPort: 80
AKE 2.0 の構成 (ClusterIP + Metal LB)

41. VM α
Kubernets node
Internal
VM β
Kubernets node
52.0.0.1:80
LoadBalancer
External
52.0.0.1:80
> VM α:80
> VM β:80
52.0.0.2:80
> VM α:80
> VM β:80
apiVersion: v1
kind: Service
metadata:
name: svc2
spec:
type: ClusterIP
ports:
- name: "http-port"
protocol: "TCP"
port: 80
targetPort: 80
apiVersion: v1
kind: Service
metadata:
name: svc1
spec:
type: ClusterIP
ports:
- name: "http-port"
protocol: "TCP"
port: 80
targetPort: 80
AKE 2.0 の構成 (ClusterIP + Metal LB)
自前で動的に iptables を書き換えて頑張る
（listen しない、ClusterIP を利用）
52.0.0.1:80 宛にきたパケットを
該当 Service の KUBE-SVC-* に転送

42. This is a slide title
① SNAT, NAPT が必須な構成
ボトルネック or リソースが必要
② 外部のコマンドでやってもらうの不便
やっぱりGKE がいいって言われる

43. VM α
Kubernets node
Internal
VM β
Kubernets node
52.0.0.1:80
LoadBalancer
External
52.0.0.1:80
> VM α:80
> VM β:80
52.0.0.2:80
> VM α:80
> VM β:80
apiVersion: v1
kind: Service
metadata:
name: svc2
spec:
type: LoadBalancer
ports:
- name: "http-port"
protocol: "TCP"
port: 80
targetPort: 80
apiVersion: v1
kind: Service
metadata:
name: svc1
spec:
type: LoadBalancer
ports:
- name: "http-port"
protocol: "TCP"
port: 80
targetPort: 80
AKE 3.0 の構成 (LoadBalancer + Metal LB)
GKE などと全く同じ type LoadBalancer