1. Kubernetesによる
ハイパースケール時代のクラウドインフラ
市川 博隆

2. 市川 博隆とは?
2010 〜 2014
ヤフー サイトオペレーション本部
ネットワーク運用/開発
[LB/GSLB/DNS/Backbone, LBaaS]
2014 〜
YJ America, Inc.（出向中）
インフラ全般（電気からクラウドまで）

3. カリフォルニア州 (ビジネス 2名、ビックデータ 1名)
ワシントン州 (インフラ 3名、アドミン 2名)
YJ Americaとは？
ヤフー株式会社の米国現地法人として2014年設立
サイトオペレーション本部から赴任(ボス, ネットワーク, サーバー)

4. Youは何しにアメリカへ？

5. USデータセンター化によるコスト削減

6. データセンター運用コストにおける電気代
コスト削減効果大
日本の電気料金は
年々上昇…
電気料金の安価な海外での拠点化を検討
電気代
26%

7. 日米電気料金比較
日本の約1/6の
電気料金
DC運用コスト
削減を実現
Japan US (WA)
約1/6
KWh単価

8. Another Mission

9. UPDATE
ヤフーのインフラ技術

10. 優れたトレンド技術を直輸入
ヤフーのインフラ技術の発展にコミット
Facebook発オープンハードウェアの採用によりCAPEX/OPEX削減
ハイパースケール企業のKNOW-HOWを吸収

11. 理想のインフラ実現に向けて
次の取り組みのテーマが…
低コストデータセンター
高効率オープンハードウェアサーバー
ハードウェア抽象化（IaaS）
???
US DC
OCP
OpenStack

12. Container Orchestration

13. なぜこの分野を扱うのか？
• コンテナ技術は避けては通れないほどに成熟
大規模環境では手動管理は非現実的。オーケストレータは必須
• コンテナ環境でも効率良くH/Wリソースを使い切りたい
しっかり性能を出すにはインフラレイヤーとの結びつきが必須
リソースマネージメントも大事
• Bare Metal、VM、コンテナ、どれも同一のコードから各種対応イメ
ージを作成、デプロイ可能にしたい（リリースプロセスの効率化）
Bare Metal/VMを管理するOpenStackとコンテナオーケストレータ
を同レイヤーとして扱う
インフラ部門としてコンテナオーケストレータを検討

14. Kubernetes

15. Kubernetes (K8S) とは？
Google発のコンテナオーケストレータ
自動化されたデプロイ、スケーリング、マネージメント環境を提供
Node
kubelet
APP PodAPP Pod
kube-proxy
Node
kubelet
APP PodAPP Pod
kube-proxy
Master
kubelet
kube-apiserver
kube-schedulerkube-controller-manager
Database
Master
クラスタ管理・API
Node
Pod実行環境
Pod
APPの実行単位
コンテナの集合

16. なぜ Kubernetes？
1. アーキテクチャ
2. 大規模での稼働実績
3. プロジェクトの今後の継続性

17. 1. アーキテクチャ
スケールアウト型でシンプル
…
OpenStack連携による資産活用も可能

18. 2. 大規模稼働実績
Googleがビッグユーザー
Google Container Engineの
バックエンドとして多数のクラスタ
の稼働・運用実績有り
週に数十億のコンテナが実行される
Planet Scale
導入後に発生する課題を解決済み

19. 3. プロジェクトの今後の継続性
積極的な開発陣
参加者数 約300人(2015) ▶ 約1000人+300人待ち (2016)
OpenStackもKubernetes連携に面舵いっぱい
コミュニティの注目度
今後の継続的発展の見通し良好

20. ネットワークはどうする？
プラガブルで選択可能なネットワーク環境

21. 一般的なKubernetesネットワーク
オーバーレイを利用したマルチホストネットワーク
POD IP / Cluster IPは内部からのみ到達可能
Ingress/NodePortで外部からのアクセスを処理
IngressはL7負荷分散機能も提供
もっとシンプルに使いたい

22. Project Calicoを採用
BGPベース、オーバーレイ不要 ▶ 安定・運用しやすい
ピュアL3ネットワーク (/32のIPを付与) ▶ スケーラブル
クラスタ外部からPodへ直接到達可能 ▶ シンプル・フラット

23. Calicoで組むKubernetesネットワーク構成
1. iBGP フルメッシュ
2. iBGP フルメッシュ + IPIPカプセル化
3. ルートリフレクタ利用

24. 1. iBGPフルメッシュ
宛先PODのホストノードが異なるネットワークに存在する場合
デフォルトゲートウェイがネクストホップがとなるが
GW上にクラスタの経路情報が無いため PODへ到達不可

25. 2. iBGPフルメッシュ + IPIPカプセル化
1. の課題をIPIPでノード間通信として扱い解決
カプセル化によるパフォーマンス劣化が懸念

26. 3. メッシュ無し（ルートリフレクタ利用）
経路再配布により外部からPODへの到達も可能に
ゲートウェイのルータへクラスタ内の経路情報を
広報し 1. の課題を解決

27. Calicoネットワーク比較表
フルメッシュ フルメッシュ + IPIP ルートリフレクタ利用
外部からPODへのリーチ × × ◯
総BGPピア数
(M: RR, N: ノード数) △ N(N-1)/2 △ N(N-1)/2 ◯ MN
マルチネットワーククラスタ × ◯ ◯
トンネリング × ◯ ×
ルートリフレクタ利用構成を採用

28. パフォーマンス比較
Calico (IPIP無し)
Calico (IPIP有り)
Flannel (VXLAN)
vs
vs

29. パフォーマンス比較環境
Calico (メッシュ/RR利用)
MTU 1500
Host Node 1 (10.0.0.10)
Pod 1
172.16.0.1/32
Host Node 2 (10.0.0.11)
Pod 2
172.16.1.1/32
iperf
Calico (IPIP) MTU 1440
Host Node 1 (10.0.1.10)
Pod 1
172.17.0.1/32
Host Node 2 (10.0.1.11)
Pod 2
172.17.1.1/32
iperf
Tunnel Interface
172.17.0.0/32
Tunnel Interface
172.17.1.0/32
Flannel (VXLAN) MTU 1450
Host Node 1 (10.0.2.10)
Pod 1
172.18.0.2/24
Host Node 2 (10.0.2.11)
Pod 2
172.18.1.2/24
iperf
CNI Bridge
172.18.0.1/24
CNI Bridge
172.18.1.1/24
Flannel VTEP
172.18.0.0/32
Flannel VTEP
172.18.1.0/32
（CentOS 7.2 3.10.0-327.36.3 、Docker 1.11.2、 Kubernetes 1.4.4、Calico 0.23.0、Flannel 0.6.1）
同一Hypervisor, 異ノードVM上のPOD間通信でiperf(TCP)評価

30. スループット測定結果
オーバーレイ不要な
Calicoの優位性を確認
Calico (IPIP)
Flannel における
大幅な性能低下
Calico Calico (IPIP) Flannel (VXLAN)
85%
Down
95.5%
Down
Throughput

31. サービスの外部公開はどうする？
PODは起動の度にIPが変わってしまう…
単体ではスケールできない…
Service (Cluster IP)
分散したPODへ単一のエンドポイントを提供（L4負荷分散）※クラスタ内のみ
Ingress ?
Cluster IPを外部から到達可能にしよう

32. Calico + kube-proxyで作るロードバランサ
LB Node
kube-proxy
k8s Node
Pods
kube-proxy
Applications
k8s NodePods
kube-proxy
Applications
Rotuer
iBGP peer
# route
blackhole <Cluster IP>
# iptables (POSTROUTING)
[SNAT]
dest: <Cluster IP>
snat to: <LB Node IP>
# Calico
{“ipam”: false, “cidr”: <Cluster IP>}
Redistribute cluster routes 下記3項目の設定を追加することにより動作
ヘルスチェックはk8sにてプロセス(POD)/L7監視を行う
①
②③
④
Calicoで管理するネットワークとしてCluster IPの
レンジを追加 PODにIPを払い出さないようIPAMを
無効にする
LBノードにパケットの吸込み設定を追加。Cluster
IPからPODへのDNATはkube-proxyが生成する
iptablesのルールによって行う。DSRはできないの
でSNATルールを追加し、PODからの戻りパケット
を受け取り、クライアントへ返送する

33. ヤフーにおけるKubernetesネットワーク
必要とする機能を絞り シンプルなネットワークを構築

34. Deploy K8S on OpenStack

35. Kubernetes on OpenStack
kubelet
k8sMaster
Bare Metal / VM
Docker
etcd-proxy
Pods
kube-apiserver
kube-scheduler
kube-controller-manager
kubelet
k8sNode
Bare Metal / VM
Docker
etcd-proxy
Pods
kube-proxy
Applications
keystone
cinder
etcd
k8s cluster deploy
認証・認可：
Keystone連携で認証環境を統一
テナント情報をk8s namespaceへ
紐付け権限制御を実現
kubelet
k8sNode
Bare Metal / VM
Docker
etcd-proxy
Pods
kube-proxy
Applications
Persistent Volume
Authentication
Authorization
永続的ストレージ：
Cinder連携によりボリュームを
仮想マシン経由でPodへマウント
ネットワーク：
Kubernetes/OpenStack共に
シンプルでフラットなネットワーク

36. DevOpsツールチェーンにのせた全体構成
• Docker registry
• VM image
• etc
Application repo Master job controller
Docker
build
Packer
build
k8s master
Terraform
apply
Launch Jenkins slave pod
and execute job
hook
deploy artifacts
pull repository
track commit build result
CI/CD support Kubernetes Cluster
k8s master
Kubernetes Service Cluster A
deploy
VM/Bare metal
APPAPP
Cinder
Persistent
Volume
Keystone
Auth
Tenant Isolation
push
Launch Pod
pull image
k8s master
Kubernetes Service Cluster B
VM/Bare metal
APPAPP
Cinder
Persistent
Volume
Keystone
Auth
Tenant Isolation
Launch Pod
ChatOps

37. サイトオペレーション本部での
Kubernetes導入事例

38. OKO（OpenStack on K8S on OpenStack）
TripleO (OpenStack On OpenStack)のアンダークラウド上に
Kubernetesをデプロイし、PODとしてオーバークラウドのOpenStackを構築
auto-healing機能による自動復旧
柔軟なクラスタ構築が可能
Over Cloud OpenStack
Controller VM
Under Cloud OpenStack
Bare Metalサーバー
Compute
Over Cloud OpenStack
Under Cloud OpenStack
Bare Metalサーバー
ComputeController POD
Bare Metalサーバー
Kubernetes

39. まとめ

40. OpenStackとKubernetesを組み合わせは有効
▶ 認証・認可システムの統合（アカウント情報を増やさない）
▶ PODへのPVストレージ提供
▶ 柔軟なHWリソース提供
Calicoによるシンプル・スケーラブルネットワーク
▶ ボトルネックの無い快適な通信環境を実現
インフラレイヤーからのアプローチによって
シンプル・高パフォーマンスなコンテナ環境を実現

41. ありがとうございました
Photos by Aflo