PFNにある2つのKubernetes

7fefbc0ddbb13f3bfde050f85acfa0c4?s=47 ota42y
November 26, 2019

 PFNにある2つのKubernetes

Bonfire Backend #4
https://yj-meetup.connpass.com/event/153658/

で発表した内容です。

7fefbc0ddbb13f3bfde050f85acfa0c4?s=128

ota42y

November 26, 2019
Tweet

Transcript

  1. PFNにある2つの Kubernetes 2019/11/26 Bonfire Backend #4 ota42y

  2. ⾃⼰紹介 • おおた @ota42y (github/twitter) • Web Application Engineer in

    PFN • React〜Go〜インフラまでだいたい全部 • 前世はRuby on Railsでマイクロサービス • 前前世はC++でソシャゲ作ってました • 前前前世は無いです⊂(・8・)⊃
  3. 今⽇の話 ⾃社GPUクラスタと Web Application⽤クラスタについて KubernetesのNetwork Isolationについて

  4. 今⽇の話 KubernetesのNetwork Isolationについて ⾃社GPUクラスタと Web Application⽤クラスタについて

  5. None
  6. ަ௨γεςϜ ࣗಈӡసٕज़ͳͲ ੡଄ۀ ϩϘοτ஌ೳԽɺ޻৔࠷దԽͳͲ όΠΦɾϔϧεέΞ ͕Μ਍அɾ૑ༀͳͲ ύʔιφϧϩϘοτ ͓ย෇͚ϩϘοτͳͲ

  7. 機械学習がメインなので マシンリソースが 重要な競争⼒

  8. ⾃社GPUクラスタ • 息をするように⼤規模計算が出来るように • 2500を超えるGPU • 独⾃チップクラスタも予定 • これらの制御をKubernetesで⾏っている

  9. https://www.slideshare.net/pfi/tech-inmlcluster20180729-julytechfesta2018

  10. None
  11. https://martinfowler.com/articles/cd4ml.html

  12. https://martinfowler.com/articles/cd4ml.html

  13. https://martinfowler.com/articles/cd4ml.html

  14. 研究結果を お客様に 使って頂く モデルだけ の提供 推論ライブ ラリの提供 システムの 提供

  15. 研究結果を お客様に 使って頂く モデルだけ の提供 推論ライブ ラリの提供 システムの 提供

  16. Web Application 展開 • 研究結果をお客様に実使ってもらう⽅法の⼀つ • インターネットアクセスできるなら 最も容易な⽅法 • 提供や拡張もやりやすい

  17. Web Applicationの 要求 機密情報の暗号化 ユーザ管理 個⼈情報管理 ネットワーク分離 リソースの増減 SLA

  18. GPUクラスタ とは 要求内容が 異なる • リソースガンガン使いたい • アクセス増に備えたい 要求が背反する •

    GPUが不要な場合も 推論がメイン • データの信頼性が凄く重要 • S3やRDSなどを利⽤したい サービス⾃体の信頼性・安定性
  19. Amazon Elastic Kubernetes Serviceで Web Application⽤ クラスタを構築

  20. Why not ECS ? 規模的にはECSで⼗分まかなえる • まだイメージの数が少ないので運⽤負荷は低い • 値段が安い •

    EKSはコントロールプレーンにも課⾦ • AWSの各サービスと連携しやすい 社内の知⾒はKubernetesのほうが多い • みんなKubernetesに慣れている • 内部のツールやフローをそのまま載せられる • リサーチャーが直接モデル更新も可能に
  21. Why not ECS ? 規模的にはECSで⼗分まかなえる • まだイメージの数が少ないので運⽤負荷は低い • 値段が安い •

    EKSはコントロールプレーンにも課⾦ • AWSの各サービスと連携しやすい 社内の知⾒はKubernetesのほうが多い • みんなKubernetesに慣れている • 内部のツールやフローをそのまま載せられる • リサーチャーが直接モデル更新も可能に
  22. 今⽇の話 KubernetesのNetwork Isolationについて ⾃社GPUクラスタと Web Application⽤クラスタについて

  23. Kubernetesの Network Isolation

  24. Network Isolationが重要になる 相互通信しないようにNetwork Isolationが重要 同じお客様内でもNetwork Isolationが必要になる場合も ⼀つのEKSクラスタに 関係ないアプリが複数同居する

  25. Network Policies Pod Pod Pod Pod Pod Pod Namespace A

    Namespace B • PodやNamespace単位で通信を制御できる標準機能
  26. Network Policies Pod Pod Pod Pod Pod Pod Namespace A

    Namespace B • 1 アプリケーションにつき1 Namespace • Namespaceごとに世界を分けて相互にアクセスを禁⽌
  27. 具体的な設定

  28. Kubernetesは デフォルトで 相互通信許可 • 明⽰的な禁⽌が必要 • Network PoliciesはNamespaceに紐付く • 新しいNamespaceごとに設定が必要

    • 設定を忘れる・間違える可能性が⾼い • デフォルトで相互通信を抑制したい • Network Policiesにはそういう機能は無い
  29. Calico • ネットワークやセキュリティポリシーを 実現するソフトウェア • VMやOpenStackに対応 • Kubernetesにも対応 (CNIプラグインとして利⽤できる) •

    EKS上でも動作する (AWS公式ドキュメントに載ってる) • Global network policyという設定 • Network Policiesより低優先度にできる • デフォルトルールとして使える https://github.com/projectcalico/calico
  30. あらゆる 相互通信の 禁⽌ UDPも同様にやります

  31. Namespace 設定 • Namespace側で 内部のpodの相互通信を許可 • Calicoの設定より優先される • Namespace内は許可、それ 以外は⾮許可が実現できる

  32. Tips: kube-system への許可 kube-dnsなどが使えなくなる kube-systemだけは特別に許可

  33. IngressとAWSの相性問題 • アクセスはVPCの外からくる • ALBを⽴ててそこからEKSにアクセスさせている • TLS終端 • ALB ingress

    controllerを利⽤ • Network PoliciesはPod/Namespace/CIDRのみ • ALBを対象にできない
  34. ALBだけをネットワーク分割 • Subnet構成で回避する • ALBのみのPublic Subnetを作る • Public Subnetからの通信は全許可 •

    ALBの設定次第で別Namespaceにアクセスできるが… • IngressはNamespaceに紐づくので⼿動変更しない限りは⼤丈夫 • EKSとSecurity Groupとの相性が悪いので良い解決⽅法が欲しい…
  35. まとめ • PFNには2種類のKubernetesがある • Web Application⽤にはEKSを利⽤している • この使い⽅ではNetwork Isolationが重要になる •

    KubernetesのNetwork Policiesは便利 • Calicoを利⽤するとより⾼度なことができる • ただしAWSの世界とのつなぎ部分はまだ難しい部分がある…
  36. Appendix • Kubernetes logo • https://github.com/kubernetes/kubernetes/tree/master/logo • Calico • https://github.com/projectcalico/calico

  37. 完全隔離VPC • 特定のお客様⽤に完全に別のVPCを作る場合もある • Kubernetesの設定を間違えても確実に外に漏れない • 内部でさらに細かく隔離が必要になる場合もありえる • 開発環境での問題 •

    機密情報はそもそもコンテナに⼊れない • S3やRDSに⼊れる