![市川 博隆とは?
2010 〜 2014
ヤフー サイトオペレーション本部
ネットワーク運用/開発
[LB/GSLB/DNS/Backbone, LBaaS]
2014 〜
YJ America, Inc.（出向中）
インフラ全般（電気からクラウドまで）](https://image.slidesharecdn.com/4infraconference20170124hichikaw-170207071500/85/Yahoo-JAPAN-MeetUp-8-2-320.jpg)
![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からの戻りパケット
を受け取り、クライアントへ返送する](https://image.slidesharecdn.com/4infraconference20170124hichikaw-170207071500/85/Yahoo-JAPAN-MeetUp-8-32-320.jpg)
More Related Content
What's hot (20)
Viewers also liked (12)
Similar to Yahoo! JAPAN MeetUp #8 （インフラ技術カンファレンス）セッション④ (20)
More from Yahoo!デベロッパーネットワーク (20)
Yahoo! JAPAN MeetUp #8 （インフラ技術カンファレンス）セッション④
- 2. 市川 博隆とは? 2010 〜 2014 ヤフー サイトオペレーション本部 ネットワーク運用/開発 [LB/GSLB/DNS/Backbone, LBaaS] 2014 〜 YJ America, Inc.（出向中） インフラ全般（電気からクラウドまで）
- 3. カリフォルニア州 (ビジネス 2名、ビックデータ 1名) ワシントン州 (インフラ 3名、アドミン 2名) YJ Americaとは？ ヤフー株式会社の米国現地法人として2014年設立 サイトオペレーション本部から赴任(ボス, ネットワーク, サーバー)
- 11. 理想のインフラ実現に向けて 次の取り組みのテーマが… 低コストデータセンター 高効率オープンハードウェアサーバー ハードウェア抽象化（IaaS） ??? US DC OCP OpenStack
- 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. プロジェクトの今後の継続性
- 18. 2. 大規模稼働実績 Googleがビッグユーザー Google Container Engineの バックエンドとして多数のクラスタ の稼働・運用実績有り 週に数十億のコンテナが実行される Planet Scale 導入後に発生する課題を解決済み
- 19. 3. プロジェクトの今後の継続性 積極的な開発陣 参加者数 約300人(2015) ▶ 約1000人+300人待ち (2016) OpenStackもKubernetes連携に面舵いっぱい コミュニティの注目度 今後の継続的発展の見通し良好
- 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でノード間通信として扱い解決 カプセル化によるパフォーマンス劣化が懸念
- 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からの戻りパケット を受け取り、クライアントへ返送する
- 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
- 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によるシンプル・スケーラブルネットワーク ▶ ボトルネックの無い快適な通信環境を実現 インフラレイヤーからのアプローチによって シンプル・高パフォーマンスなコンテナ環境を実現