PFNにある２つのKubernetes

Transcript

1. PFNにある２つの 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に⼊れる