Bonfire Backend #4 https://yj-meetup.connpass.com/event/153658/
で発表した内容です。
PFNにある２つのKubernetes2019/11/26 Bonfire Backend #4ota42y
View Slide
⾃⼰紹介• おおた @ota42y (github/twitter)• Web Application Engineer in PFN• React〜Go〜インフラまでだいたい全部• 前世はRuby on Railsでマイクロサービス• 前前世はC++でソシャゲ作ってました• 前前前世は無いです⊂(・8・)⊃
今⽇の話⾃社GPUクラスタとWeb Application⽤クラスタについてKubernetesのNetwork Isolationについて
今⽇の話KubernetesのNetwork Isolationについて⾃社GPUクラスタとWeb Application⽤クラスタについて
ަ௨γεςϜࣗಈӡసٕज़ͳͲۀϩϘοτೳԽɺ࠷దԽͳͲόΠΦɾϔϧεέΞ͕ΜஅɾༀͳͲύʔιφϧϩϘοτ͓ย͚ϩϘοτͳͲ
機械学習がメインなのでマシンリソースが重要な競争⼒
⾃社GPUクラスタ• 息をするように⼤規模計算が出来るように• 2500を超えるGPU• 独⾃チップクラスタも予定• これらの制御をKubernetesで⾏っている
https://www.slideshare.net/pfi/tech-inmlcluster20180729-julytechfesta2018
https://martinfowler.com/articles/cd4ml.html
研究結果をお客様に使って頂くモデルだけの提供推論ライブラリの提供システムの提供
Web Application展開• 研究結果をお客様に実使ってもらう⽅法の⼀つ• インターネットアクセスできるなら最も容易な⽅法• 提供や拡張もやりやすい
WebApplicationの要求機密情報の暗号化ユーザ管理個⼈情報管理ネットワーク分離リソースの増減SLA
GPUクラスタとは要求内容が異なる• リソースガンガン使いたい• アクセス増に備えたい要求が背反する• GPUが不要な場合も推論がメイン• データの信頼性が凄く重要• S3やRDSなどを利⽤したいサービス⾃体の信頼性・安定性
Amazon Elastic Kubernetes ServiceでWeb Application⽤ クラスタを構築
Why notECS ?規模的にはECSで⼗分まかなえる• まだイメージの数が少ないので運⽤負荷は低い• 値段が安い• EKSはコントロールプレーンにも課⾦• AWSの各サービスと連携しやすい社内の知⾒はKubernetesのほうが多い• みんなKubernetesに慣れている• 内部のツールやフローをそのまま載せられる• リサーチャーが直接モデル更新も可能に
KubernetesのNetwork Isolation
Network Isolationが重要になる相互通信しないようにNetwork Isolationが重要同じお客様内でもNetwork Isolationが必要になる場合も⼀つのEKSクラスタに関係ないアプリが複数同居する
Network PoliciesPod PodPodPod PodPodNamespace A Namespace B• PodやNamespace単位で通信を制御できる標準機能
Network PoliciesPod PodPodPod PodPodNamespace A Namespace B• 1 アプリケーションにつき1 Namespace• Namespaceごとに世界を分けて相互にアクセスを禁⽌
具体的な設定
Kubernetesはデフォルトで相互通信許可• 明⽰的な禁⽌が必要• Network PoliciesはNamespaceに紐付く• 新しいNamespaceごとに設定が必要• 設定を忘れる・間違える可能性が⾼い• デフォルトで相互通信を抑制したい• Network Policiesにはそういう機能は無い
Calico• ネットワークやセキュリティポリシーを実現するソフトウェア• VMやOpenStackに対応• Kubernetesにも対応(CNIプラグインとして利⽤できる)• EKS上でも動作する(AWS公式ドキュメントに載ってる)• Global network policyという設定• Network Policiesより低優先度にできる• デフォルトルールとして使えるhttps://github.com/projectcalico/calico
あらゆる相互通信の禁⽌UDPも同様にやります
Namespace設定• Namespace側で内部のpodの相互通信を許可• Calicoの設定より優先される• Namespace内は許可、それ以外は⾮許可が実現できる
Tips:kube-systemへの許可kube-dnsなどが使えなくなるkube-systemだけは特別に許可
IngressとAWSの相性問題• アクセスはVPCの外からくる• ALBを⽴ててそこからEKSにアクセスさせている• TLS終端• ALB ingress controllerを利⽤• Network PoliciesはPod/Namespace/CIDRのみ• ALBを対象にできない
ALBだけをネットワーク分割• Subnet構成で回避する• ALBのみのPublic Subnetを作る• Public Subnetからの通信は全許可• ALBの設定次第で別Namespaceにアクセスできるが…• IngressはNamespaceに紐づくので⼿動変更しない限りは⼤丈夫• EKSとSecurity Groupとの相性が悪いので良い解決⽅法が欲しい…
まとめ• PFNには2種類のKubernetesがある• Web Application⽤にはEKSを利⽤している• この使い⽅ではNetwork Isolationが重要になる• KubernetesのNetwork Policiesは便利• Calicoを利⽤するとより⾼度なことができる• ただしAWSの世界とのつなぎ部分はまだ難しい部分がある…
Appendix• Kubernetes logo• https://github.com/kubernetes/kubernetes/tree/master/logo• Calico• https://github.com/projectcalico/calico
完全隔離VPC• 特定のお客様⽤に完全に別のVPCを作る場合もある• Kubernetesの設定を間違えても確実に外に漏れない• 内部でさらに細かく隔離が必要になる場合もありえる• 開発環境での問題• 機密情報はそもそもコンテナに⼊れない• S3やRDSに⼊れる
ota42y
manfredsteyer
kishida
mot_techtalk
munetoshi
dalinaum
ledsun
mozu1206
slobodan
k0kubun
gregonnet
jmatsu
lara
brad_frost
mojombo
orderedlist
eileencodes
trallard
keathley
mza
akmur
aki_iinuma
dougneiner
palkan