PFNにある２つのKubernetes

Transcript

1. 1.

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

2. 2.

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

   PFN • React〜Go〜インフラまでだいたい全部 • 前世はRuby on Railsでマイクロサービス • 前前世はC++でソシャゲ作ってました • 前前前世は無いです⊂(・8・)⊃
3. 3.

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

4. 4.

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

5. 5.

   None
6. 6.

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

7. 7.

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

8. 8.

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

9. 9.

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

10. 10.

    None
11. 11.

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

12. 12.

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

13. 13.

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

14. 14.

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

15. 15.

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

16. 16.

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

17. 17.

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

18. 18.

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

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

    Amazon Elastic Kubernetes Serviceで Web Application⽤ クラスタを構築

20. 20.

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

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

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

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

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

23. 23.

    Kubernetesの Network Isolation

24. 24.

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

25. 25.

    Network Policies Pod Pod Pod Pod Pod Pod Namespace A

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

    Network Policies Pod Pod Pod Pod Pod Pod Namespace A

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

    具体的な設定

28. 28.

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

    • 設定を忘れる・間違える可能性が⾼い • デフォルトで相互通信を抑制したい • Network Policiesにはそういう機能は無い
29. 29.

    Calico • ネットワークやセキュリティポリシーを 実現するソフトウェア • VMやOpenStackに対応 • Kubernetesにも対応 (CNIプラグインとして利⽤できる) •

    EKS上でも動作する (AWS公式ドキュメントに載ってる) • Global network policyという設定 • Network Policiesより低優先度にできる • デフォルトルールとして使える https://github.com/projectcalico/calico
30. 30.

    あらゆる 相互通信の 禁⽌ UDPも同様にやります

31. 31.

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

32. 32.

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

33. 33.

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

    controllerを利⽤ • Network PoliciesはPod/Namespace/CIDRのみ • ALBを対象にできない
34. 34.

    ALBだけをネットワーク分割 • Subnet構成で回避する • ALBのみのPublic Subnetを作る • Public Subnetからの通信は全許可 •

    ALBの設定次第で別Namespaceにアクセスできるが… • IngressはNamespaceに紐づくので⼿動変更しない限りは⼤丈夫 • EKSとSecurity Groupとの相性が悪いので良い解決⽅法が欲しい…
35. 35.

    まとめ • PFNには2種類のKubernetesがある • Web Application⽤にはEKSを利⽤している • この使い⽅ではNetwork Isolationが重要になる •

    KubernetesのNetwork Policiesは便利 • Calicoを利⽤するとより⾼度なことができる • ただしAWSの世界とのつなぎ部分はまだ難しい部分がある…
36. 36.

    Appendix • Kubernetes logo • https://github.com/kubernetes/kubernetes/tree/master/logo • Calico • https://github.com/projectcalico/calico

37. 37.

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

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