Kubernetesによる ハイパースケール時代のクラウドインフラ 市川 博隆
Kubernetesによるハイパースケール時代のクラウドインフラ
市川 博隆
市川 博隆とは?
2010 〜 2014
ヤフー サイトオペレーション本部
ネットワーク運用/開発
[LB/GSLB/DNS/Backbone, LBaaS]
2014 〜
YJ America, Inc.(出向中)
インフラ全般(電気からクラウドまで)
カリフォルニア州 (ビジネス 2名、ビックデータ 1名)ワシントン州 (インフラ 3名、アドミン 2名)
YJ Americaとは?
ヤフー株式会社の米国現地法人として2014年設立
サイトオペレーション本部から赴任(ボス, ネットワーク, サーバー)
Youは何しにアメリカへ?
USデータセンター化によるコスト削減
データセンター運用コストにおける電気代
コスト削減効果大
日本の電気料金は年々上昇…
電気料金の安価な海外での拠点化を検討
電気代26%
日米電気料金比較
日本の約1/6の電気料金
DC運用コスト削減を実現
Japan US (WA)
約1/6
KW
h単価
Another Mission
UPDATE
ヤフーのインフラ技術
優れたトレンド技術を直輸入
ヤフーのインフラ技術の発展にコミット
Facebook発オープンハードウェアの採用によりCAPEX/OPEX削減
ハイパースケール企業のKNOW-HOWを吸収
理想のインフラ実現に向けて
次の取り組みのテーマが…
低コストデータセンター
高効率オープンハードウェアサーバー
ハードウェア抽象化(IaaS)
???
US DC
OCP
OpenStack
Container Orchestration
なぜこの分野を扱うのか?• コンテナ技術は避けては通れないほどに成熟
大規模環境では手動管理は非現実的。オーケストレータは必須
• コンテナ環境でも効率良くH/Wリソースを使い切りたい
しっかり性能を出すにはインフラレイヤーとの結びつきが必須
リソースマネージメントも大事
• Bare Metal、VM、コンテナ、どれも同一のコードから各種対応イメ
ージを作成、デプロイ可能にしたい(リリースプロセスの効率化)
Bare Metal/VMを管理するOpenStackとコンテナオーケストレータ
を同レイヤーとして扱う
インフラ部門としてコンテナオーケストレータを検討
Kubernetes
Kubernetes (K8S) とは?Google発のコンテナオーケストレータ
自動化されたデプロイ、スケーリング、マネージメント環境を提供
Nodekubelet
APP PodAPP Pod
kube-proxy
Nodekubelet
APP PodAPP Pod
kube-proxy
Masterkubelet
kube-apiserver
kube-schedulerkube-controller-manager
Database Masterクラスタ管理・API
NodePod実行環境
PodAPPの実行単位コンテナの集合
なぜ Kubernetes?
1. アーキテクチャ
2. 大規模での稼働実績
3. プロジェクトの今後の継続性
1. アーキテクチャ
スケールアウト型でシンプル
…
OpenStack連携による資産活用も可能
2. 大規模稼働実績
Googleがビッグユーザー
Google Container Engineの
バックエンドとして多数のクラスタ
の稼働・運用実績有り
週に数十億のコンテナが実行される
Planet Scale
導入後に発生する課題を解決済み
3. プロジェクトの今後の継続性
積極的な開発陣
参加者数 約300人(2015) ▶ 約1000人+300人待ち (2016)
OpenStackもKubernetes連携に面舵いっぱい
コミュニティの注目度
今後の継続的発展の見通し良好
ネットワークはどうする?
プラガブルで選択可能なネットワーク環境
一般的なKubernetesネットワーク
オーバーレイを利用したマルチホストネットワーク
POD IP / Cluster IPは内部からのみ到達可能
Ingress/NodePortで外部からのアクセスを処理
IngressはL7負荷分散機能も提供
もっとシンプルに使いたい
Project Calicoを採用
BGPベース、オーバーレイ不要 ▶ 安定・運用しやすいピュアL3ネットワーク (/32のIPを付与) ▶ スケーラブルクラスタ外部からPodへ直接到達可能 ▶ シンプル・フラット
Calicoで組むKubernetesネットワーク構成
1. iBGP フルメッシュ
2. iBGP フルメッシュ + IPIPカプセル化
3. ルートリフレクタ利用
1. iBGPフルメッシュ
宛先PODのホストノードが異なるネットワークに存在する場合デフォルトゲートウェイがネクストホップがとなるが
GW上にクラスタの経路情報が無いため PODへ到達不可
2. iBGPフルメッシュ + IPIPカプセル化
1. の課題をIPIPでノード間通信として扱い解決カプセル化によるパフォーマンス劣化が懸念
3. メッシュ無し(ルートリフレクタ利用)
経路再配布により外部からPODへの到達も可能に
ゲートウェイのルータへクラスタ内の経路情報を
広報し 1. の課題を解決
Calicoネットワーク比較表
フルメッシュ フルメッシュ + IPIP ルートリフレクタ利用
外部からPODへのリーチ × × ◯
総BGPピア数(M: RR, N: ノード数) △ N(N-1)/2 △ N(N-1)/2 ◯ MN
マルチネットワーククラスタ × ◯ ◯
トンネリング × ◯ ×
ルートリフレクタ利用構成を採用
パフォーマンス比較
Calico (IPIP無し)
Calico (IPIP有り)
Flannel (VXLAN)
vs
vs
パフォーマンス比較環境
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)評価
スループット測定結果
オーバーレイ不要なCalicoの優位性を確認
Calico (IPIP)Flannel における大幅な性能低下
Calico Calico (IPIP) Flannel (VXLAN)
85%Down
95.5%Down
Th
rou
gh
pu
t
サービスの外部公開はどうする?
PODは起動の度にIPが変わってしまう…
単体ではスケールできない…
Service (Cluster IP)分散したPODへ単一のエンドポイントを提供(L4負荷分散)※クラスタ内のみ
Ingress ?
Cluster IPを外部から到達可能にしよう
Calico + kube-proxyで作るロードバランサ
LB Node
kube-proxy
k8s Node
Pod
s
kube-proxyApplications
k8s Node
Pod
s
kube-proxyApplications
Rotuer
iBGP peer
# routeblackhole <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からの戻りパケットを受け取り、クライアントへ返送する
ヤフーにおけるKubernetesネットワーク
必要とする機能を絞り シンプルなネットワークを構築
Deploy K8S on OpenStack
Kubernetes on OpenStack
kubelet
k8
s M
aste
r
Bare Metal / VM
Docker
etcd-proxyP
od
s
kube-apiserverkube-schedulerkube-controller-manager
kubelet
k8
s N
od
e
Bare Metal / VM
Docker
etcd-proxyP
od
s
kube-proxyApplications
keystone
cinder
etcd
k8s cluster deploy
認証・認可:Keystone連携で認証環境を統一テナント情報をk8s namespaceへ紐付け権限制御を実現
kubelet
k8
s N
od
e
Bare Metal / VM
Docker
etcd-proxy
Pod
s
kube-proxyApplications
Persistent Volume
AuthenticationAuthorization
永続的ストレージ:Cinder連携によりボリュームを仮想マシン経由でPodへマウント
ネットワーク:Kubernetes/OpenStack共にシンプルでフラットなネットワーク
DevOpsツールチェーンにのせた全体構成
• Docker registry
• VM image
• etc
Application repo Master job controller
Docker
buildPacker
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
CinderPersistent
Volume
Keystone
Auth
Tenant Isolation
push
Launch Pod
pull image
k8s master
Kubernetes Service Cluster B
VM/Bare metal
APPAPP
CinderPersistent
Volume
Keystone
Auth
Tenant Isolation
Launch Pod
ChatOps
サイトオペレーション本部でのKubernetes導入事例
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
まとめ
OpenStackとKubernetesを組み合わせは有効▶ 認証・認可システムの統合(アカウント情報を増やさない)
▶ PODへのPVストレージ提供
▶ 柔軟なHWリソース提供
Calicoによるシンプル・スケーラブルネットワーク
▶ ボトルネックの無い快適な通信環境を実現
インフラレイヤーからのアプローチによって
シンプル・高パフォーマンスなコンテナ環境を実現
ありがとうございました
Photos by Aflo