Yahoo! JAPAN MeetUp #8 （インフラ技術カンファレンス）セッション④

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

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

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

Youは何しにアメリカへ？

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

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

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

Another Mission

UPDATE ヤフーのインフラ技術

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

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

Container Orchestration

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

Kubernetes

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

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

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

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

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

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

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

Calico + kube-proxyで作るロードバランサ
Redistribute cluster routes

Rotuer

下記3項目の設定を追加することにより動作
ヘルスチェックはk8sにてプロセス(POD)/L7監視を行う

①

# Calico
{“ipam”: false, “cidr”: <Cluster IP>}

LB Node

iBGP peer

④

kube-proxy

k8s Node

# route
blackhole <Cluster IP>

②

③

# iptables (POSTROUTING)
[SNAT]
dest: <Cluster IP>
snat to: <LB Node IP>

k8s Node
Pods

Pods

kube-proxy
Applications

Calicoで管理するネットワークとしてCluster IPの
レンジを追加 PODにIPを払い出さないようIPAMを
無効にする

kube-proxy
Applications

LBノードにパケットの吸込み設定を追加。Cluster
IPからPODへのDNATはkube-proxyが生成する
iptablesのルールによって行う。DSRはできないの
でSNATルールを追加し、PODからの戻りパケット
を受け取り、クライアントへ返送する

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

Deploy K8S on OpenStack

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

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

サイトオペレーション本部での 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 Controller POD Kubernetes Under Cloud OpenStack Bare Bare Metalサーバー Metalサーバー Compute

まとめ

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

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