O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

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

7.200 visualizações

Publicada em

Publicada em: Tecnologia
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui

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

  1. 1. Kubernetesによる ハイパースケール時代のクラウドインフラ 市川 博隆
  2. 2. 市川 博隆とは? 2010 〜 2014 ヤフー サイトオペレーション本部 ネットワーク運用/開発 [LB/GSLB/DNS/Backbone, LBaaS] 2014 〜 YJ America, Inc.(出向中) インフラ全般(電気からクラウドまで)
  3. 3. カリフォルニア州 (ビジネス 2名、ビックデータ 1名) ワシントン州 (インフラ 3名、アドミン 2名) YJ Americaとは? ヤフー株式会社の米国現地法人として2014年設立 サイトオペレーション本部から赴任(ボス, ネットワーク, サーバー)
  4. 4. Youは何しにアメリカへ?
  5. 5. USデータセンター化によるコスト削減
  6. 6. データセンター運用コストにおける電気代 コスト削減効果大 日本の電気料金は 年々上昇… 電気料金の安価な海外での拠点化を検討 電気代 26%
  7. 7. 日米電気料金比較 日本の約1/6の 電気料金 DC運用コスト 削減を実現 Japan US (WA) 約1/6 KWh単価
  8. 8. Another Mission
  9. 9. UPDATE ヤフーのインフラ技術
  10. 10. 優れたトレンド技術を直輸入 ヤフーのインフラ技術の発展にコミット Facebook発オープンハードウェアの採用によりCAPEX/OPEX削減 ハイパースケール企業のKNOW-HOWを吸収
  11. 11. 理想のインフラ実現に向けて 次の取り組みのテーマが… 低コストデータセンター 高効率オープンハードウェアサーバー ハードウェア抽象化(IaaS) ??? US DC OCP OpenStack
  12. 12. Container Orchestration
  13. 13. なぜこの分野を扱うのか? • コンテナ技術は避けては通れないほどに成熟 大規模環境では手動管理は非現実的。オーケストレータは必須 • コンテナ環境でも効率良くH/Wリソースを使い切りたい しっかり性能を出すにはインフラレイヤーとの結びつきが必須 リソースマネージメントも大事 • Bare Metal、VM、コンテナ、どれも同一のコードから各種対応イメ ージを作成、デプロイ可能にしたい(リリースプロセスの効率化) Bare Metal/VMを管理するOpenStackとコンテナオーケストレータ を同レイヤーとして扱う インフラ部門としてコンテナオーケストレータを検討
  14. 14. Kubernetes
  15. 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. 16. なぜ Kubernetes? 1. アーキテクチャ 2. 大規模での稼働実績 3. プロジェクトの今後の継続性
  17. 17. 1. アーキテクチャ スケールアウト型でシンプル … OpenStack連携による資産活用も可能
  18. 18. 2. 大規模稼働実績 Googleがビッグユーザー Google Container Engineの バックエンドとして多数のクラスタ の稼働・運用実績有り 週に数十億のコンテナが実行される Planet Scale 導入後に発生する課題を解決済み
  19. 19. 3. プロジェクトの今後の継続性 積極的な開発陣 参加者数 約300人(2015) ▶ 約1000人+300人待ち (2016) OpenStackもKubernetes連携に面舵いっぱい コミュニティの注目度 今後の継続的発展の見通し良好
  20. 20. ネットワークはどうする? プラガブルで選択可能なネットワーク環境
  21. 21. 一般的なKubernetesネットワーク オーバーレイを利用したマルチホストネットワーク POD IP / Cluster IPは内部からのみ到達可能 Ingress/NodePortで外部からのアクセスを処理 IngressはL7負荷分散機能も提供 もっとシンプルに使いたい
  22. 22. Project Calicoを採用 BGPベース、オーバーレイ不要 ▶ 安定・運用しやすい ピュアL3ネットワーク (/32のIPを付与) ▶ スケーラブル クラスタ外部からPodへ直接到達可能 ▶ シンプル・フラット
  23. 23. Calicoで組むKubernetesネットワーク構成 1. iBGP フルメッシュ 2. iBGP フルメッシュ + IPIPカプセル化 3. ルートリフレクタ利用
  24. 24. 1. iBGPフルメッシュ 宛先PODのホストノードが異なるネットワークに存在する場合 デフォルトゲートウェイがネクストホップがとなるが GW上にクラスタの経路情報が無いため PODへ到達不可
  25. 25. 2. iBGPフルメッシュ + IPIPカプセル化 1. の課題をIPIPでノード間通信として扱い解決 カプセル化によるパフォーマンス劣化が懸念
  26. 26. 3. メッシュ無し(ルートリフレクタ利用) 経路再配布により外部からPODへの到達も可能に ゲートウェイのルータへクラスタ内の経路情報を 広報し 1. の課題を解決
  27. 27. Calicoネットワーク比較表 フルメッシュ フルメッシュ + IPIP ルートリフレクタ利用 外部からPODへのリーチ × × ◯ 総BGPピア数 (M: RR, N: ノード数) △ N(N-1)/2 △ N(N-1)/2 ◯ MN マルチネットワーククラスタ × ◯ ◯ トンネリング × ◯ × ルートリフレクタ利用構成を採用
  28. 28. パフォーマンス比較 Calico (IPIP無し) Calico (IPIP有り) Flannel (VXLAN) vs vs
  29. 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. 30. スループット測定結果 オーバーレイ不要な Calicoの優位性を確認 Calico (IPIP) Flannel における 大幅な性能低下 Calico Calico (IPIP) Flannel (VXLAN) 85% Down 95.5% Down Throughput
  31. 31. サービスの外部公開はどうする? PODは起動の度にIPが変わってしまう… 単体ではスケールできない… Service (Cluster IP) 分散したPODへ単一のエンドポイントを提供(L4負荷分散)※クラスタ内のみ Ingress ? Cluster IPを外部から到達可能にしよう
  32. 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. 33. ヤフーにおけるKubernetesネットワーク 必要とする機能を絞り シンプルなネットワークを構築
  34. 34. Deploy K8S on OpenStack
  35. 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. 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. 37. サイトオペレーション本部での Kubernetes導入事例
  38. 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. 39. まとめ
  40. 40. OpenStackとKubernetesを組み合わせは有効 ▶ 認証・認可システムの統合(アカウント情報を増やさない) ▶ PODへのPVストレージ提供 ▶ 柔軟なHWリソース提供 Calicoによるシンプル・スケーラブルネットワーク ▶ ボトルネックの無い快適な通信環境を実現 インフラレイヤーからのアプローチによって シンプル・高パフォーマンスなコンテナ環境を実現
  41. 41. ありがとうございました Photos by Aflo

×