Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
PFNにある2つのKubernetes
Search
ota42y
November 26, 2019
Programming
10
5.5k
PFNにある2つのKubernetes
Bonfire Backend #4
https://yj-meetup.connpass.com/event/153658/
で発表した内容です。
ota42y
November 26, 2019
Tweet
Share
More Decks by ota42y
See All by ota42y
バックログを導入し やっぱやめた話
ota42y
1
280
ゼロから作るDeep Learning 2 3章 word2vec 3.1〜3.2
ota42y
1
480
Q&A for How to use OpenAPI3 for API developer
ota42y
0
2.6k
How to use OpenAPI3 for API developer (RubyKaigi 2019)
ota42y
5
21k
How should we face with microservices (我々はマイクロサービスとどう向き合うべきか)
ota42y
20
4.7k
DeepLearningの本番環境にSageMakerを利用してる話
ota42y
1
6.3k
検索結果の良さを計測して定量的に改善していく
ota42y
3
2.5k
Flutterを広めるために技術同人誌を作った話
ota42y
1
1.7k
何も考えずにCIや継続的デリバリーしたら辛くなった話.pdf
ota42y
0
3k
Other Decks in Programming
See All in Programming
ソフトウェアエンジニアの成長
masuda220
PRO
12
2.1k
Rails アプリ地図考 Flush Cut
makicamel
1
130
なぜイベント駆動が必要なのか - CQRS/ESで解く複雑系システムの課題 -
j5ik2o
14
4.6k
XStateを用いた堅牢なReact Components設計~複雑なClient Stateをシンプルに~ @React Tokyo ミートアップ #2
kfurusho
1
970
color-scheme: light dark; を完全に理解する
uhyo
7
490
CloudNativePGを布教したい
nnaka2992
0
110
1年目の私に伝えたい!テストコードを怖がらなくなるためのヒント/Tips for not being afraid of test code
push_gawa
1
500
未経験でSRE、はじめました! 組織を支える役割と軌跡
curekoshimizu
1
130
パスキーのすべて ── 導入・UX設計・実装の紹介 / 20250213 パスキー開発者の集い
kuralab
3
880
「個人開発マネタイズ大全」が教えてくれたこと
bani24884
1
150
PHPカンファレンス名古屋2025 タスク分解の試行錯誤〜レビュー負荷を下げるために〜
soichi
1
670
Datadog Workflow Automation で圧倒的価値提供
showwin
1
150
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Mobile First: as difficult as doing things right
swwweet
223
9.4k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Rails Girls Zürich Keynote
gr2m
94
13k
Building an army of robots
kneath
303
45k
Designing Experiences People Love
moore
140
23k
Side Projects
sachag
452
42k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7.1k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
The Invisible Side of Design
smashingmag
299
50k
Transcript
PFNにある2つの Kubernetes 2019/11/26 Bonfire Backend #4 ota42y
⾃⼰紹介 • おおた @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⽤クラスタについて
None
ަ௨γεςϜ ࣗಈӡసٕज़ͳͲ ۀ ϩϘοτೳԽɺ࠷దԽͳͲ όΠΦɾϔϧεέΞ ͕ΜஅɾༀͳͲ ύʔιφϧϩϘοτ ͓ย͚ϩϘοτͳͲ
機械学習がメインなので マシンリソースが 重要な競争⼒
⾃社GPUクラスタ • 息をするように⼤規模計算が出来るように • 2500を超えるGPU • 独⾃チップクラスタも予定 • これらの制御をKubernetesで⾏っている
https://www.slideshare.net/pfi/tech-inmlcluster20180729-julytechfesta2018
None
https://martinfowler.com/articles/cd4ml.html
https://martinfowler.com/articles/cd4ml.html
https://martinfowler.com/articles/cd4ml.html
研究結果を お客様に 使って頂く モデルだけ の提供 推論ライブ ラリの提供 システムの 提供
研究結果を お客様に 使って頂く モデルだけ の提供 推論ライブ ラリの提供 システムの 提供
Web Application 展開 • 研究結果をお客様に実使ってもらう⽅法の⼀つ • インターネットアクセスできるなら 最も容易な⽅法 • 提供や拡張もやりやすい
Web Applicationの 要求 機密情報の暗号化 ユーザ管理 個⼈情報管理 ネットワーク分離 リソースの増減 SLA
GPUクラスタ とは 要求内容が 異なる • リソースガンガン使いたい • アクセス増に備えたい 要求が背反する •
GPUが不要な場合も 推論がメイン • データの信頼性が凄く重要 • S3やRDSなどを利⽤したい サービス⾃体の信頼性・安定性
Amazon Elastic Kubernetes Serviceで Web Application⽤ クラスタを構築
Why not ECS ? 規模的にはECSで⼗分まかなえる • まだイメージの数が少ないので運⽤負荷は低い • 値段が安い •
EKSはコントロールプレーンにも課⾦ • AWSの各サービスと連携しやすい 社内の知⾒はKubernetesのほうが多い • みんなKubernetesに慣れている • 内部のツールやフローをそのまま載せられる • リサーチャーが直接モデル更新も可能に
Why not ECS ? 規模的にはECSで⼗分まかなえる • まだイメージの数が少ないので運⽤負荷は低い • 値段が安い •
EKSはコントロールプレーンにも課⾦ • AWSの各サービスと連携しやすい 社内の知⾒はKubernetesのほうが多い • みんなKubernetesに慣れている • 内部のツールやフローをそのまま載せられる • リサーチャーが直接モデル更新も可能に
今⽇の話 KubernetesのNetwork Isolationについて ⾃社GPUクラスタと Web Application⽤クラスタについて
Kubernetesの Network Isolation
Network Isolationが重要になる 相互通信しないようにNetwork Isolationが重要 同じお客様内でもNetwork Isolationが必要になる場合も ⼀つのEKSクラスタに 関係ないアプリが複数同居する
Network Policies Pod Pod Pod Pod Pod Pod Namespace A
Namespace B • PodやNamespace単位で通信を制御できる標準機能
Network Policies Pod Pod Pod Pod Pod Pod Namespace 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に⼊れる