PFNにある２つのKubernetes

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

で発表した内容です。

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⽤クラスタについて
6. ަ௨γεςϜ ࣗಈӡసٕज़ͳͲ ੡଄ۀ ϩϘοτ஌ೳԽɺ޻৔࠷దԽͳͲ όΠΦɾϔϧεέΞ ͕Μ਍அɾ૑ༀͳͲ ύʔιφϧϩϘοτ ͓ย෇͚ϩϘοτͳͲ
7. 機械学習がメインなので マシンリソースが 重要な競争⼒
8. ⾃社GPUクラスタ • 息をするように⼤規模計算が出来るように • 2500を超えるGPU • 独⾃チップクラスタも予定 • これらの制御をKubernetesで⾏っている
9. https://www.slideshare.net/pfi/tech-inmlcluster20180729-julytechfesta2018
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に⼊れる