KubeCon + CloudNativeCon NA 2023 Sessions for Site Reliability Engineers / amsy810-srett08

Transcript

1. Masaya Aoyama CyberAgent KubeCon + CloudNativeCon NA 2023 Sessions for Site Reliability Engineers 3-shake SRE Tech Talk #8 amsy810 @amsy810
2. - Co-chair ⻘⼭ 真也 + CREATIONLINE - 技術アドバイザ + SAKURA Internet Research Center – 客員研究員 + 3-shake 技術顧問 + PLAID - Organizer - KaaS Product Owner - Publications Twitter: @amsy810
3. Event info
4. KubeCon + CloudNativeCon NA 2023 開催⽇︓2023/11/6 – 2023/11/9 (11/6: Co-located event) ※ 前回に引き続き Co-located Event は 1 ⽇間 会場︓ CHICAGO, ILLINOIS + Virtual platform ※ 前回引き引き続きは All Attendees Party はなし
5. $/$'IPTUFE
   $PMPDBUFE
   &WFOUʢ/"
   ʣ CNCF が主催する Co-located イベント︓ 15 + 1 個（前回は 9 + 1 個） CNCF 以外が主催する Co-located イベント︓ 12 個（前回は 9 個） 去年から 2 種類の In-person チケット が販売 • KubeCon + CNCon のみ参加のパス • $895〜$1650 • 全ての CNCF-hosted Co-located イベントにも参加で きるパス • $1099-$1899
6. $/$'IPTUFE
   $PMPDBUFE
   &WFOUʢ&6
   ʣ Backstage Con に始まり、 Platform Engineering Day も開催予定 前回 CNCF TAG App Delivery が Platforms White paper を公開 ↓ Platform Engineering への注⽬度++
7. ,VCF$PO
   $/$PO /PSUI
   "NFSJDB
    オフライン参加者数
8. ,VCF$PO
   $/$PO &VSPQF
    オフライン参加者数
9. ,VCF$PO
   $/$PO /"
    オフライン参加者数
10. ,VCF$PO
    $/$PO "UUFOEFFT
    ਪҠ 0% 10% 20% 30% 40% 50% 60% 70% 80% 0 5000 10000 15000 20000 25000 30000 2017 NA 2018 EU 2018 NA 2019 EU 2019 NA 2020 EU 2020 NA 2021 EU 2021 NA 2022 EU 2022 NA 2023 EU 2023 NA Online Offline Total Firsttime(%) $07*%
11. ,VCF$PO
    $MPVE/BUJWF$PO /"
    
    ͷ೔ຊਓࢀՃऀ • CyberAgent • LINEヤフー • DMM • メルカリ • NTT • NTT DOCOMO • NTTデータグループ • ⽇⽴ • Fujitsu • Midokura • Sysdig • SCSK • KDDI etc. 合計 50-60 名程度
12. Next KubeCon + CloudNativeCon • KubeCon + CNCon EU 2024 @PARIS, FRANCE • 3/19 - 3/22（4 Days） • 🆕 KubeCon + CNCon NA 2024 @SALT LAKE CITY • 11/12 - 11/15（4 Days） KubeCon + CNCon China は発表されず。 KubeCon + CNCon India が開催予定。
13. Keynote
14. Keynote: Everything, Everywhere, All At Once Hemanth Malla, Senior Software Engineer, Datadog & Laurent Bernaille, Principal Engineer, Datadog https://sched.co/1R4bN
15. 概要 • 2023/3 にあった Datadog の障害の話 • 全てのデータセンターで 60 %の Kubernetes Node が 1時間ダウンして発⽣した⼤規模なサービス障害 • ⽣々しい対応の全貌が語られていたので、セッションやブログをぜひ
16. Datadog の Kubernetes 構成と障害原因 Cilium では Pod IP に対する ルーティングエントリを Agent が管理し 疎通性を確保
17. Datadog の Kubernetes 構成と障害原因
18. Datadog の Kubernetes 構成と障害原因
19. Datadog の Kubernetes 構成と障害原因
20. Datadog の Kubernetes 構成と障害原因
21. 障害復旧: クラスタステータスの正常化 GCP の場合: インスタンスの Reboot を実施 AWS の場合: AutoScaling group により⾃動復旧 ただし、ローカルディスクを利⽤しているステートフルなアプリのデータが⽋損
22. 障害復旧: 50%+のスケールアウトにおける課題
23. 障害復旧: 50%+のスケールアウトにおける課題
24. 障害復旧: 50%+のスケールアウトにおける課題
25. Deep dive blog https://www.datadoghq.com/ja/blog/engineering/ 2023-03-08-deep-dive-into-platform-level-impact/
26. ʲ OpenTelemetry ʳ OTTL Me Why Transforming Telemetry in the OpenTelemetry Collector Just Got Better Tyler Helmuth, Honeycomb & Evan Bradley, Dynatrace https://sched.co/1Rj2Y Journey from Fluent Bit, Fluentd and Prometheus to OpenTelemetry Collector - Lessons Learned Marcin "Perk" Stożek, Canonical https://sched.co/1Rj68 Remote Control for Observability Using the Open Agent Management Protocol Jacob Aronoff, Lightstep from ServiceNow & Andy Keller, observIQ https://sched.co/1R2sr
27. ʲ OpenTelemetry ʳ OTTL Me Why Transforming Telemetry in the OpenTelemetry Collector Just Got Better Tyler Helmuth, Honeycomb & Evan Bradley, Dynatrace https://sched.co/1Rj2Y Journey from Fluent Bit, Fluentd and Prometheus to OpenTelemetry Collector - Lessons Learned Marcin "Perk" Stożek, Canonical https://sched.co/1Rj68 Remote Control for Observability Using the Open Agent Management Protocol Jacob Aronoff, Lightstep from ServiceNow & Andy Keller, observIQ https://sched.co/1R2sr
28. OpenTelemetry とは • Traces データを収集する SDK • Metrics・Logs・Traces などのテレメトリデータを扱う Agent（OpenTelemetry Collector） • ※Metrics・Traces などのテレメトリデータにも対応した Fluentd のようなもの • それらのデータをやり取りするプロトコル Processor Exporter Receiver
29. OpenTelemetry Transformation Language（OTTL） Transform Processor や Filter Processor などで変換処理などを⾏う際に利⽤できる DSL 今までは特定の機能に限定した Processor の設定を記述していたものが、 OTTL を利⽤して変換やフィルタルールを記述可能に YAML と⽐較して、OTTL は DSL なので記述量が少なくて済む
30. 既存の OTel Config との違い • 各種 Processor 特有の記述⽅法などはなし • 多種多様な関数の利⽤ • 複数段階の処理
31. 既存の OTel Config との違い • 各種 Processor 特有の記述⽅法などはなし • 多種多様な関数の利⽤ • 複数段階の処理
32. OTTL の将来 現在は Alpha リリース、今後は Beta リリースに向けで開発中 将来的に既存の各種処理に特化した Processor は廃⽌し、汎⽤的な Transform/Filter Processor へ e.g. Log Transform Processor、Resoruce Attribute Processor、etc
33. ʲ OpenTelemetry ʳ OTTL Me Why Transforming Telemetry in the OpenTelemetry Collector Just Got Better Tyler Helmuth, Honeycomb & Evan Bradley, Dynatrace https://sched.co/1Rj2Y Journey from Fluent Bit, Fluentd and Prometheus to OpenTelemetry Collector - Lessons Learned Marcin "Perk" Stożek, Canonical https://sched.co/1Rj68 Remote Control for Observability Using the Open Agent Management Protocol Jacob Aronoff, Lightstep from ServiceNow & Andy Keller, observIQ https://sched.co/1R2sr
34. Fluentd/Prometheus > OpenTelemetry Metadata / Logs / Metrics の処理を Fluentd / Fluent Bit / Prometheus から OTel への置き換えを推奨するセッション
35. Metadata における OpenTelemetry Collector ⽐較 Metrics/Logs/Traces に対して Kubernetes の Pod情報などのメタデータを付 与する処理 OpenTelemetry 以外で 各種テレメトリデータに対して付与できるのは Fluentd のみ
36. Metadata における OpenTelemetry Collector ⽐較 • 処理対象がログ以外は最適化されていない • ⾔語的なパフォーマンス的にも不利 ↓ 約 1/3 倍のリソース消費量 ※ 実際には Prometheus や Fluent Bit 側で 付与することが⼀般的な気がします
37. Logs における OpenTelemetry Collector ⽐較 Fluent Bit よりパフォーマンスは劣る パフォーマンスに関する記述はなし
38. Metrics における OpenTelemetry Collector ⽐較 各クラスタ上で Scrape したデータを 中央集権の TSDB/Prometheus 互換実装へ 書き込む場合の移設 ↓ OpenTelemetry の Prometheus Receiver へ切替可能 Remote write scrape
39. Metrics における OpenTelemetry Collector ⽐較 各クラスタ上で Scrape したデータを 中央集権の TSDB/Prometheus 互換実装へ 書き込む場合の移設 ↓ OpenTelemetry の Prometheus Receiver へ切替可能 Remote write scrape
40. Metrics における OpenTelemetry Collector ⽐較 各クラスタ上で Scrape したデータを 中央集権の TSDB/Prometheus 互換実装へ 書き込む場合の移設 ↓ OpenTelemetry の Prometheus Receiver へ切替可能
41. Metrics における OpenTelemetry Collector ⽐較 TSDBへの保存や UI などもないシンプルな構成 約 1/5 のリソース消費量に抑えることができる
42. まとめ OpenTelemetry は良好なパフォーマンスを発揮しており、 Fluentd/Fluent Bit や Prometheus 代替としての利⽤価値がある ⼀⽅で、Otel はまだ多少バグがあるプラグインもある状況 検証結果は mat-rumian/work で公開 公開されている Metrics generator や Log Generator なども便利そう
43. ʲ OpenTelemetry ʳ OTTL Me Why Transforming Telemetry in the OpenTelemetry Collector Just Got Better Tyler Helmuth, Honeycomb & Evan Bradley, Dynatrace https://sched.co/1Rj2Y Journey from Fluent Bit, Fluentd and Prometheus to OpenTelemetry Collector - Lessons Learned Marcin "Perk" Stożek, Canonical https://sched.co/1Rj68 Remote Control for Observability Using the Open Agent Management Protocol Jacob Aronoff, Lightstep from ServiceNow & Andy Keller, observIQ https://sched.co/1R2sr
44. OpAMP (Open Agent Management Protocol) OpenTelemetry プロジェクトのサブプロジェクト 複数 Agent を統合的に管理するプロトコル / SDK OpAMP Client が外部の Backend からデータを取得 OpAMP Server? は OTel の Config を⽣成し、 シグナルを送って再読み込みを⾏う ※ 仕様 を⾒ると OpAMP Server の位置が怪しい
45. OpAMP with Operator OpenTelemetry Operator では OpAMPBridge リソースが⽤意されており、 OpAMP を元に OpenTelemetryCollector リソースを作成
46. ʲ Others topics for Observability ʳ
47. その他 Observability 関連の Topics • Observability Whitepaper が GA • Query⾔語の標準化は 2024 Q2 を⽬処に調査を完了し、具体的なディスカッションへ • Kubernetes ⾃体に対するロードテストツール kube-burner が Sandbox 申請
48. ʲ Argo CD / Argo Rollouts ʳ Extending Argo Projects: Customizing Argo CD and Argo Rollouts for Your Needs Leonardo Luz Almeida & Zach Aller, Intuit https://sched.co/1Rj43
49. Argo Rollouts の拡張ポイント それぞれ各種 Interface を実装したバイナリを⽤意することで拡張可能 • Metric Provider Plugin • Prometheus などのように、任意のデータソースの情報をもとに Analisys したり、 Rollout 条件の分析の仕組みを⾃前実装する • Traffic Router Plugin • Canary などのように、任意のアルゴリズムでトラフィックを制御する仕組みを⾃前実装する • Step Plugin • 複数のリージョンのトラフィックコントロールや、フィーチャーフラグ連携、そのほか任意のバリデーションなど、 Argo Rollouts の Step で任意の処理を実施可能にする
50. Argo CD の拡張ポイント • Config Management Plugins (CMP) • HelmやKustomizeではない任意のツールでArgoCDとの連携をしたり、 マニフェスト⽣成時に機密情報の復号や置換処理などの任意の処理を⾏うための仕組み • ApplicationSet Generator Plugin • Applicationリソースを⾃動⽣成する部分をカスタマイズできる • Clusterごとに⽣成したり、Gitリポジトリのディレクトリ構造を元に⾃動⽣成したりする部分を⾃前実装できる • ⾃社の任意の DB と連携して⾃動⽣成させるとかそう⾔ったことも可能 • ⽣成する部分は HTTP Server として実装する
51. Argo CD の拡張ポイント • UI + Proxy Extensions • Argo CDのUIに任意の拡張UIを差し込む機能 • Istio関連のリソースが利⽤時にはKialiを表⽰させたり、Prometheusのページも埋め込んだり、任意の拡張が可能 • Rollouts Extension • Argo Rollouts の状況をArgo CDのUIに表⽰する • https://github.com/argoproj-labs/rollout-extension • Metrics Extension • PrometheusのメトリクスをArgo CDのUIに表⽰する • https://github.com/argoproj-labs/argocd-extension-metrics
54. ʲ Gateway API ʳ Gateway API: The Most Collaborative API in Kubernetes History Is GA Rob Scott, Google & Nick Young, Isovalent https://sched.co/1R2qM What's Happening with Ingress-Nginx! James Strong, Chainguard & Ricardo Katz, VMware https://sched.co/1R2n1 Why Service Is the Worst API in Kubernetes, and What Weʼre Doing About It Tim Hockin, Google https://sched.co/1R2lw
55. Gateway API の GA release • Gateway API が 2023/10/31 に GA Release • GKE の Gateway Controller ⾃体は 2022/11 に GA Release • Ingress の課題を解決するために、当初は Ingress v2 としても発⾜したプロジェクト • Ingress ⾃体は⾮推奨にする計画はない
57. Gateway API: The Most Collaborative API in Kubernetes History Is GA - Rob Scott, Google & Nick Young, Isovalent • 2019年のプロジェクト発⾜から、現在の設計に⾄るまでの試⾏錯誤
58. What's Happening with Ingress-Nginx! - James Strong, Chainguard & Ricardo Katz, VMware • k/ingress-nginx は最もメジャーな Ingress Controller の実装の⼀つ • 2024 年に Gateway API への対応を計画 • 現在は優先度の⾼い前段タスクを遂⾏中 • 利⽤されていない機能の削除・リファクタリング • Controlplane（Kubernetes Controller） と Dataplane（Nginx）の分離
59. Gateway API の今後 • 機能強化は Gateway Enhancement Proposals（GEPs） によって管理 • Network Policy Enhancement Proposals（NPEPs）も踏襲 • 現在 Experimental な主な機能追加 • GRPCRoute の追加 • Gateway で利⽤される IP アドレスの接続性の設定 • HTTPRoute での timeout 設定 • ベンダー固有の設定の設定を Gateway 単位で設定可能に（現状は GatewayClass 単位） • Gateway Controller の利⽤可能な機能を GatewayClassで管理可能に
60. Why Service Is the Worst API in Kubernetes, & What Weʼre Doing About It - Tim Hockin, Google • Kubernetes の共同創設者であり、現在もコアメンテナーを務める Tim Hockin ⽒ • Service の⼀部機能の Gateway API への統合案の紹介 • Service は Pod を抽象的にまとめる • Gateway は接続性を担うもの • 複雑度の解消 • Service/Ingress/Gateway の責務分離
61. Kubernetes Advent Calendar 2023
62. Gateway API 関連の便利なツール群や今後について • gwctl • 各種ポリシーやルールをまとめた上で計算し、結果や問題箇所を表⽰する • kubectl プラグインとしても提供 • e.g. • ingress2gateway • Ingress リソースを Gateway リソースに変換するツール 今後の機能拡張については、Gateway Enhancement Proposals（GEPs） から確認可能 GA 後も 16 個の Enhancement が実装予定 https://github.com/kubernetes-sigs/gateway-api/tree/main/geps
63. Tim による Service の re-design 10年前に実装された Service リソースは、 現在様々な機能の追加により複雑化している Gateway API を利⽤して ロードバランシングに関する部分を分離し、 Service はディスカバリーに関する部分に注⼒する 実装に変えてはどうかという 提案 LT
64. Thank you for your attention Twitter: @amsy810