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

Slide 1

Slide 1 text

Masaya Aoyama CyberAgent KubeCon + CloudNativeCon NA 2023 Sessions for Site Reliability Engineers 3-shake SRE Tech Talk #8 amsy810 @amsy810

Slide 2

Slide 2 text

- Co-chair ⻘⼭真也 + CREATIONLINE - 技術アドバイザ + SAKURA Internet Research Center – 客員研究員 + 3-shake 技術顧問 + PLAID - Organizer - KaaS Product Owner - Publications Twitter: @amsy810

Slide 3

Slide 3 text

Event info

Slide 4

Slide 4 text

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 はなし

Slide 5

Slide 5 text

$/$'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

Slide 6

Slide 6 text

$/$'IPTUFE$PMPDBUFE&WFOUʢ&6ʣ Backstage Con に始まり、 Platform Engineering Day も開催予定前回 CNCF TAG App Delivery が Platforms White paper を公開 ↓ Platform Engineering への注⽬度++

Slide 7

Slide 7 text

,VCF$PO $/$PO /PSUI"NFSJDB オフライン参加者数

Slide 8

Slide 8 text

,VCF$PO $/$PO &VSPQF オフライン参加者数

Slide 9

Slide 9 text

,VCF$PO $/$PO /" オフライン参加者数

Slide 10

Slide 10 text

,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*%

Slide 11

Slide 11 text

,VCF$PO $MPVE/BUJWF$PO /"ͷ೔ຊਓࢀՃऀ • CyberAgent • LINEヤフー • DMM • メルカリ • NTT • NTT DOCOMO • NTTデータグループ • ⽇⽴ • Fujitsu • Midokura • Sysdig • SCSK • KDDI etc. 合計 50-60 名程度

Slide 12

Slide 12 text

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 が開催予定。

Slide 13

Slide 13 text

Keynote

Slide 14

Slide 14 text

Keynote: Everything, Everywhere, All At Once Hemanth Malla, Senior Software Engineer, Datadog & Laurent Bernaille, Principal Engineer, Datadog https://sched.co/1R4bN

Slide 15

Slide 15 text

概要 • 2023/3 にあった Datadog の障害の話 • 全てのデータセンターで 60 %の Kubernetes Node が 1時間ダウンして発⽣した⼤規模なサービス障害 • ⽣々しい対応の全貌が語られていたので、セッションやブログをぜひ

Slide 16

Slide 16 text

Datadog の Kubernetes 構成と障害原因 Cilium では Pod IP に対するルーティングエントリを Agent が管理し疎通性を確保

Slide 17

Slide 17 text

Datadog の Kubernetes 構成と障害原因

Slide 18

Slide 18 text

Datadog の Kubernetes 構成と障害原因

Slide 19

Slide 19 text

Datadog の Kubernetes 構成と障害原因

Slide 20

Slide 20 text

Datadog の Kubernetes 構成と障害原因

Slide 21

Slide 21 text

障害復旧: クラスタステータスの正常化 GCP の場合: インスタンスの Reboot を実施 AWS の場合: AutoScaling group により⾃動復旧ただし、ローカルディスクを利⽤しているステートフルなアプリのデータが⽋損

Slide 22

Slide 22 text

障害復旧: 50%+のスケールアウトにおける課題

Slide 23

Slide 23 text

障害復旧: 50%+のスケールアウトにおける課題

Slide 24

Slide 24 text

障害復旧: 50%+のスケールアウトにおける課題

Slide 25

Slide 25 text

Deep dive blog https://www.datadoghq.com/ja/blog/engineering/ 2023-03-08-deep-dive-into-platform-level-impact/

Slide 26

Slide 26 text

ʲ 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

Slide 27

Slide 27 text

Slide 28

Slide 28 text

OpenTelemetry とは • Traces データを収集する SDK • Metrics・Logs・Traces などのテレメトリデータを扱う Agent（OpenTelemetry Collector） • ※Metrics・Traces などのテレメトリデータにも対応した Fluentd のようなもの • それらのデータをやり取りするプロトコル Processor Exporter Receiver

Slide 29

Slide 29 text

OpenTelemetry Transformation Language（OTTL） Transform Processor や Filter Processor などで変換処理などを⾏う際に利⽤できる DSL 今までは特定の機能に限定した Processor の設定を記述していたものが、 OTTL を利⽤して変換やフィルタルールを記述可能に YAML と⽐較して、OTTL は DSL なので記述量が少なくて済む

Slide 30

Slide 30 text

既存の OTel Config との違い • 各種 Processor 特有の記述⽅法などはなし • 多種多様な関数の利⽤ • 複数段階の処理

Slide 31

Slide 31 text

既存の OTel Config との違い • 各種 Processor 特有の記述⽅法などはなし • 多種多様な関数の利⽤ • 複数段階の処理

Slide 32

Slide 32 text

OTTL の将来現在は Alpha リリース、今後は Beta リリースに向けで開発中将来的に既存の各種処理に特化した Processor は廃⽌し、汎⽤的な Transform/Filter Processor へ e.g. Log Transform Processor、Resoruce Attribute Processor、etc

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Fluentd/Prometheus > OpenTelemetry Metadata / Logs / Metrics の処理を Fluentd / Fluent Bit / Prometheus から OTel への置き換えを推奨するセッション

Slide 35

Slide 35 text

Metadata における OpenTelemetry Collector ⽐較 Metrics/Logs/Traces に対して Kubernetes の Pod情報などのメタデータを付与する処理 OpenTelemetry 以外で各種テレメトリデータに対して付与できるのは Fluentd のみ

Slide 36

Slide 36 text

Metadata における OpenTelemetry Collector ⽐較 • 処理対象がログ以外は最適化されていない • ⾔語的なパフォーマンス的にも不利 ↓ 約 1/3 倍のリソース消費量 ※ 実際には Prometheus や Fluent Bit 側で付与することが⼀般的な気がします

Slide 37

Slide 37 text

Logs における OpenTelemetry Collector ⽐較 Fluent Bit よりパフォーマンスは劣るパフォーマンスに関する記述はなし

Slide 38

Slide 38 text

Metrics における OpenTelemetry Collector ⽐較各クラスタ上で Scrape したデータを中央集権の TSDB/Prometheus 互換実装へ書き込む場合の移設 ↓ OpenTelemetry の Prometheus Receiver へ切替可能 Remote write scrape

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Metrics における OpenTelemetry Collector ⽐較各クラスタ上で Scrape したデータを中央集権の TSDB/Prometheus 互換実装へ書き込む場合の移設 ↓ OpenTelemetry の Prometheus Receiver へ切替可能

Slide 41

Slide 41 text

Metrics における OpenTelemetry Collector ⽐較 TSDBへの保存や UI などもないシンプルな構成約 1/5 のリソース消費量に抑えることができる

Slide 42

Slide 42 text

まとめ OpenTelemetry は良好なパフォーマンスを発揮しており、 Fluentd/Fluent Bit や Prometheus 代替としての利⽤価値がある⼀⽅で、Otel はまだ多少バグがあるプラグインもある状況検証結果は mat-rumian/work で公開公開されている Metrics generator や Log Generator なども便利そう

Slide 43

Slide 43 text

Slide 44

Slide 44 text

OpAMP (Open Agent Management Protocol) OpenTelemetry プロジェクトのサブプロジェクト複数 Agent を統合的に管理するプロトコル / SDK OpAMP Client が外部の Backend からデータを取得 OpAMP Server? は OTel の Config を⽣成し、シグナルを送って再読み込みを⾏う ※ 仕様を⾒ると OpAMP Server の位置が怪しい

Slide 45

Slide 45 text

OpAMP with Operator OpenTelemetry Operator では OpAMPBridge リソースが⽤意されており、 OpAMP を元に OpenTelemetryCollector リソースを作成

Slide 46

Slide 46 text

ʲ Others topics for Observability ʳ

Slide 47

Slide 47 text

その他 Observability 関連の Topics • Observability Whitepaper が GA • Query⾔語の標準化は 2024 Q2 を⽬処に調査を完了し、具体的なディスカッションへ • Kubernetes ⾃体に対するロードテストツール kube-burner が Sandbox 申請

Slide 48

Slide 48 text

ʲ 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

Slide 49

Slide 49 text

Argo Rollouts の拡張ポイントそれぞれ各種 Interface を実装したバイナリを⽤意することで拡張可能 • Metric Provider Plugin • Prometheus などのように、任意のデータソースの情報をもとに Analisys したり、 Rollout 条件の分析の仕組みを⾃前実装する • Traffic Router Plugin • Canary などのように、任意のアルゴリズムでトラフィックを制御する仕組みを⾃前実装する • Step Plugin • 複数のリージョンのトラフィックコントロールや、フィーチャーフラグ連携、そのほか任意のバリデーションなど、 Argo Rollouts の Step で任意の処理を実施可能にする

Slide 50

Slide 50 text

Argo CD の拡張ポイント • Config Management Plugins (CMP) • HelmやKustomizeではない任意のツールでArgoCDとの連携をしたり、マニフェスト⽣成時に機密情報の復号や置換処理などの任意の処理を⾏うための仕組み • ApplicationSet Generator Plugin • Applicationリソースを⾃動⽣成する部分をカスタマイズできる • Clusterごとに⽣成したり、Gitリポジトリのディレクトリ構造を元に⾃動⽣成したりする部分を⾃前実装できる • ⾃社の任意の DB と連携して⾃動⽣成させるとかそう⾔ったことも可能 • ⽣成する部分は HTTP Server として実装する

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

ʲ 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

Slide 55

Slide 55 text

Gateway API の GA release • Gateway API が 2023/10/31 に GA Release • GKE の Gateway Controller ⾃体は 2022/11 に GA Release • Ingress の課題を解決するために、当初は Ingress v2 としても発⾜したプロジェクト • Ingress ⾃体は⾮推奨にする計画はない

Slide 56

Slide 56 text

No content

Slide 57

Slide 57 text

Gateway API: The Most Collaborative API in Kubernetes History Is GA - Rob Scott, Google & Nick Young, Isovalent • 2019年のプロジェクト発⾜から、現在の設計に⾄るまでの試⾏錯誤

Slide 58

Slide 58 text

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）の分離

Slide 59

Slide 59 text

Gateway API の今後 • 機能強化は Gateway Enhancement Proposals（GEPs）によって管理 • Network Policy Enhancement Proposals（NPEPs）も踏襲 • 現在 Experimental な主な機能追加 • GRPCRoute の追加 • Gateway で利⽤される IP アドレスの接続性の設定 • HTTPRoute での timeout 設定 • ベンダー固有の設定の設定を Gateway 単位で設定可能に（現状は GatewayClass 単位） • Gateway Controller の利⽤可能な機能を GatewayClassで管理可能に

Slide 60

Slide 60 text

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 の責務分離

Slide 61

Slide 61 text

Kubernetes Advent Calendar 2023

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

Tim による Service の re-design 10年前に実装された Service リソースは、現在様々な機能の追加により複雑化している Gateway API を利⽤してロードバランシングに関する部分を分離し、 Service はディスカバリーに関する部分に注⼒する実装に変えてはどうかという提案 LT

Slide 64

Slide 64 text

Thank you for your attention Twitter: @amsy810