Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
Kubernetesクラスタ内のリソースに 柔軟なフィルタリングをかける方法 3-shake SRE Tech Talk #4 LT / SRETT4-LT-amsy810
Masaya Aoyama (@amsy810)
August 04, 2022
Programming
0
82
Kubernetesクラスタ内のリソースに 柔軟なフィルタリングをかける方法 3-shake SRE Tech Talk #4 LT / SRETT4-LT-amsy810
Masaya Aoyama (@amsy810)
August 04, 2022
Tweet
Share
More Decks by Masaya Aoyama (@amsy810)
See All by Masaya Aoyama (@amsy810)
KubeCon + CloudNativeCon EU 2022 Recap Kubernetes Meetup Tokyo #51 / k8sjp51-kubecon-eu-2022-recap
masayaaoyama
0
170
ebpfとWASMに思いを馳せる2022 / techfeed-conference-2022-ebpf-wasm-amsy810
masayaaoyama
1
1k
Kubernetes基盤における運用フローのController化と継続的な改善 / kubernetes-controller-improvements
masayaaoyama
11
2.5k
Kubernetesエコシステムのバージョン追従と柔軟な管理への挑戦 / cndt2021-amsy810
masayaaoyama
4
650
KubeCon + CloudNativeCon NA 2021 Overview and TAG Whitepaper at Kubernetes Meetup Tokyo #46 / k8sjp46-amsy810
masayaaoyama
0
160
Kubernetesとともに育てるアプリケーション実行基盤 / cloudnativelounge-01-amsy810
masayaaoyama
1
1.8k
Platform for Platform with Kubernetes 〜ML Platform and KaaS〜 / cabasenext2021-k8s-amsy810
masayaaoyama
0
5.4k
Kubernetes と Toil の削減に立ち向かう 〜 Controller 開発時に考えていること 〜 3-shake SRE Tech Talk #1 / srett1-k8s-amsy810
masayaaoyama
3
680
AI事業本部におけるGPU活用の取り組みとKubernetes - CloudNative Days Spring 2021 Online / cndo2021-ca-ml-gpuaas-aiplatform
masayaaoyama
2
1.7k
Other Decks in Programming
See All in Programming
段階的な技術的負債の解消方法.pdf
ko2ic
2
920
設計の考え方とやり方
masuda220
PRO
53
29k
ZOZOTOWNにおけるDatadogの活用と、それを支える全社管理者の取り組み / 2022-07-27
tippy
1
3.2k
NestJS_meetup_atamaplus
atamaplus
0
210
Better Angular Architectures: Architectures with Standalone Components @DWX2022
manfredsteyer
PRO
1
410
それ全部エラーメッセージに書いてあるよ!〜独学でPHPプログラミングが上達するたった一つの方法〜
77web
1
150
Records の使い方はこれでいいの? をみんなで考えたい / Java DO #20
gishi_yama
0
120
Computer Vision Seminar 1/コンピュータビジョンセミナーvol.1 OpenCV活用
fixstars
0
170
ESM移行は無理だけどおれもSindreのライブラリが使いたい!
sosukesuzuki
2
540
WindowsコンテナDojo:第6回 Red Hat OpenShift入門
oniak3ibm
PRO
0
180
フロントエンドエンジニアが変える現場のモデリング意識/modeling-awareness-changed-by-front-end-engineers
uggds
32
13k
閱讀原始碼 - 再戰十年的 jQuery
eddie
1
290
Featured
See All Featured
Faster Mobile Websites
deanohume
294
28k
Rails Girls Zürich Keynote
gr2m
87
12k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
655
120k
The Power of CSS Pseudo Elements
geoffreycrofte
47
4k
VelocityConf: Rendering Performance Case Studies
addyosmani
316
22k
Web development in the modern age
philhawksworth
197
9.3k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
11
4.8k
The Web Native Designer (August 2011)
paulrobertlloyd
75
2k
A better future with KSS
kneath
226
16k
Documentation Writing (for coders)
carmenintech
48
2.6k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
21
1.4k
Designing for humans not robots
tammielis
241
24k
Transcript
Masaya Aoyama 3-shake Kubernetesクラスタ内のリソースに 柔軟なフィルタリングをかける方法 3-shake SRE Tech Talk #4
LT amsy810 @amsy810
- Co-chair ⻘⼭真也 + CREATIONLINE - 技術アドバイザ + SAKURA Internet
Research Center – 客員研究員 + 3-shake 技術顧問 + PLAID - Organizer - KaaS Product Owner - Publications Twitter: @amsy810
kubectl get pods --filter Service ʹඥ͍͍ͯͳ͍Pod
kubectl get ServiceMonitors --filter Serviceʹඥ͍͍ͯͳ͍ServiceMonitor
Ͳ͏ͬͯΓ·͔͢ʁ
• ServiceMonitor は Prometheus Operator で実装されている API • 指定された条件の Service
(Endpoint)に対して Scrape を⾏う ServiceMonitor と Service リソース Kind: ServiceMonitor spec: endpoints: - path: /metrics port: service namespaceSelector: matchNames: - default selector: matchLabels: app: my-app Kind: Service metadata: namespace: default labels: app: my-app spec: {} Service Endpoint 10.0.0.1 Endpoint 10.0.0.2 app: my-app app: my-app app: my-app Scrape
• ラベルの整理を⾏ったところ ServiceMonitor にマッチしない状態に • Argo CD が app.kubernetes.io/instance ラベルを付与する兼ね合いで
Git リポジトリ上では判別できないケースもあり ServiceMonitor と Service リソース Kind: ServiceMonitor spec: endpoints: - path: /metrics port: service namespaceSelector: matchNames: - default selector: matchLabels: app: my-app Kind: Service metadata: namespace: default labels: app: dummy spec: {} Service Endpoint 10.0.0.1 Endpoint 10.0.0.2 app: dummy app: dummy app: dummy Scrape
無意味な ServiceMonitor の⼀覧を表⽰したい = ServiceMonitor で指定されている Service が存在するか否か • e.g.
Deployment に PDB / HPA / etc が存在しているか • e.g. 使われていない ConfigMap / ServiceAccount / etc が存在するか 実現したいこと Service Endpoint 10.0.0.1 Endpoint 10.0.0.2 app: dummy app: dummy app: dummy Scrape
• kubectl get servicemonitors -o jsonpath=ʻ.items[?(@...)]ʼ • 複数のリソースにまたがる条件⼀致は指定できない • jq
や go-template でも同様 • 軽量なプログラムを Go などで実装する • client-goで実装し、ポリシーロジックを実装するのは少々⼿間がかかる • Gatekeeper で ServiceMonitor / Service の 作成/更新時 にチェックを⾏う • audit 機能があるものの新たな要件発⽣時には対応しづらい 考えられる⽅法
ղܾࡦͷ࣮ํ๏ࣗମΑ͋͘ΔͰ͢
• kubectl get した結果を元に Conftest を実⾏する Conftest を⽤いて柔軟なフィルターを実装する deny[msg] {
sm = input.items[_] sm.kind == "ServiceMonitor" not has_valid_svc(sm, input.items) msg = sprintf("ServiceMonitor=%s", [sm.metadata.name]) } $ kubectl get service,servicemonitor –A –o yaml apiVersion: v1 items: - kind: Service metadata: {name: svc-1} - kind: Service metadata: {name: svc-2} - kind: ServiceMonitor metadata: {name: sm-1} ... • 取得した複数の Object は items[] 配列に格納 • YAML ストリームではなく単⼀のドキュメントと して返されるため、”conftest test” 実⾏時の --combine オプションは不要
kubectl get と conftest test --combine を両⽴する • kubectl get
で取得した list を元にテストする場合 deny[msg] { sm = input[_] sm.kind == "ServiceMonitor" not has_valid_svc(sm, input) msg = sprintf("ServiceMonitor=%s", [sm.metadata.name]) } deny[msg] { sm = input.items[_] sm.kind == "ServiceMonitor" not has_valid_svc(sm, input.items) msg = sprintf("ServiceMonitor=%s", [sm.metadata.name]) } • conftest test --combine でマニフェストを元にテストする場合(CI での利⽤を想定) 後々 CI にも Conftest を組み込んで再利⽤できる形で関数を実装する 特定のリソース or リソースの配列に対する関数を意識して実装する
あとは Rego でポリシーを実装するだけ • ServiceMonitor の Selector に⼀致する Service の存在確認(実際には
Namespace を考慮すること) # ServiceMonitor にマッチする Service が1つ以上存在することの確認 has_valid_svc(sm, items){ svc = items[i] svc.kind == "Service" match_svc(sm, svc) } # 「1つのServiceMonitorのSelector」と「1つのServiceのラベル」がマッチするか否かの確認 match_svc(sm, svc) { s := {sprintf("%s=%s", [i, sm.spec.selector.matchLabels[i]]) | sm.spec.selector.matchLabels[i]} l := {sprintf("%s=%s", [i, svc.metadata.labels[i]]) | svc.metadata.labels[i]} sub := s - l count(sub) = 0 } ポリシーは下記の通り数⾏で表現可能
まとめ クラスタから取得した情報をもとに、柔軟にフィルタリングを掛ける場合にも Conftest は有⽤ • yq などでの表現⼒ < Rego の表現⼒
• 複数のリソースにまたがるポリシー 実装したフィルタリングポリシーは、場合によっては CI に組み込むことも有⽤ • ServiceMonitor に適切な Service が存在するか(不適切な Selector の防⽌) Kind: ServiceMonitor spec: endpoints: - path: /metrics port: service selector: matchLabels: app: my-app Kind: Service metadata: namespace: default labels: app: dummy spec: {} ?
None
Thank you for your attention Twitter: @amsy810