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