Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Cloud Nativeを支える要素技術・プロダクト・プラクティスの歩み / infrastu...

Cloud Nativeを支える要素技術・プロダクト・プラクティスの歩み / infrastudy-returns-01-amsy810

基調講演「Cloud Nativeを支える要素技術・プロダクト・プラクティスの歩み」

青山 真也(@amsy810)
株式会社サイバーエージェント Software Engineer

Cloud Native Computing Foundationが設立されてから約9年、Kubernetesが作られてから約10年が経過しました。
Infra Studyが始まった4年前と比較しても、CNCFがホストするCloudNativeなプロダクトの採用は日本の多くの会社でも一般的になり、Kubernetesを中心としたエコシステムの採用も広く進んでいます。
一方で、膨大に広がるCloud Native Landscapeや思想をキャッチアップするのに疲れて溜めてしまっていた方はいませんか?

本セッションでは、ここ数年で注目されているOSS・それを支えるeBPFやWASMなどの要素技術・CNCFが公開している各種White Paperを振り返り、要素技術〜プロダクトなどの技術的な話から各種プラクティスのトレンドを紹介します。
積んでしまった情報を一緒に吸収しましょう。

---
2016年新卒でサイバーエージェントに入社。Kubernetes as a Serviceの開発やOpenStackを使ったプライベートクラウド構築、CloudNative技術を用いたアーキテクトとして従事。著書に『Kubernetes完全ガイド』『Kubernetesの知識地図』『みんなのDocker/Kubernetes』、技術顧問としての経験やKeynote登壇経験なども。現在はOSSへのコントリビュート活動をはじめ、CloudNative Days Tokyo Co-chair、CNCF Japan ChapterのOrganizer、Kubernetes Meetup TokyoのOrganizerなどコミュニティ活動にも従事。

Masaya Aoyama (@amsy810)

June 25, 2024
Tweet

More Decks by Masaya Aoyama (@amsy810)

Other Decks in Technology

Transcript

  1. - Co-chair ⻘⼭ 真也 + CREATIONLINE - 技術アドバイザ + SAKURA

    Internet Research Center – 客員研究員 + 3-shake 技術顧問 + PLAID - Organizer - KaaS Product Owner - Publications Twitter: @amsy810
  2. eBPF • System calls • Function entry / exit •

    Kernel tracepoints • Network events • etc https://ebpf.io/ カーネルのソースコードの変更やカーネルモジュールの組み込みなしに 任意のプログラム(制限あり) をカーネルに組み込む機能 eBPF プログラムはイベント駆動で 特定のフックポイントで実⾏される
  3. cilium/ebpf Cilium などでも利⽤されている eBPF ⽤の Go ライブラリ eBPF プログラム(written in

    C)から各種 Go のコードを⽣成する bpf2go CLI link, err := link.AttachXDP(link.XDPOptions{ Program: objs.CountPackets, Interface: iface.Index, }) var count uint64 err := objs.PktCount.Lookup(uint32(0), &count) var objs counterObjects if err := loadCounterObjects(&objs, nil); 各種トレースポイントに eBPF コードをアタッチする ⾃動⽣成されたコードを利⽤して eBPF map のデータを操作可能 eBPF ELF を読み込む eBPF ELF ファイル (バイトコード) counter_bpfel.o eBPF プログラム counter_bpfel.go
  4. bpfman/bpfman eBPF プログラムの管理機能を Kubernetes にもつ Operator • CAP_BPF Capability を

    Agent へ局所化することによるセキュリティ向上 • CSI Driver 経由での eBPF map の共有機能 kind: XdpProgram metadata: name: go-xdp-counter-example spec: bpffunctionname: xdp_stats bytecode: image: url: quay.io/go-xdp-counter:v1 attach eBPF program bpfman-agent Node watch ※ 厳密にはXdpProgram > ノードごとに BpfProgram CR が⽣成 https://github.com/bpfman/bpfman/tree/main/examples/config/base/go-xdp-counter with CAP_BPF
  5. bpfman/bpfman eBPF プログラムの管理機能を Kubernetes にもつ Operator • CAP_BPF Capability を

    Agent へ局所化することによるセキュリティ向上 • CSI Driver 経由での eBPF map の共有機能 Pod.spec: volumes: - name: go-xdp-counter-maps csi: driver: csi.bpfman.io volumeAttributes: csi.bpfman.io/program: go-xdp-counter-example csi.bpfman.io/maps: xdp_stats_map https://github.com/bpfman/bpfman/tree/main/examples/config/base/go-xdp-counter # main.go statsMap, err := ebpf.LoadPinnedMap(mapPath, opts)
  6. WASM – Web Assembly Workload Runtime としての WASM • WASI

    を利⽤した従来のコンテナアプリケーション代替 • WASI-NN を利⽤したモデルのロードと推論 Plugin / Extension としての WASM • Webhook などで外部呼び出しを⾏う⽅法と⽐べて⾼速 • リビルドなしに任意のロジックを差し込み可能
  7. Workload runtime としての WASM containerd/runwasi • containerd サブプロジェクトで、containerd で WASM

    アプリケーションを実⾏可能に • WasmEdge / Wasmtime / Wasmer の WASM ランタイムごとに実装 wasi-nn • モデルのロード・⼊⼒値の設定・推論・結果取得といったインターフェースが定義 • WASM ランタイムが ggml / PyTorch / openVINO などバックエンドごとに実装 • アプリケーション側で推論⽤のコードが不要
  8. Plugin / Extension としての WASM Proxy-WASM については「eBPFとWASMに思いを馳せる2022」 • Proxy の様々なタイミングで任意の処理を実⾏

    • Proxy に対して命令を送ることも可能 https://www.envoyproxy.io/docs/envoy/latest/api- v3/extensions/wasm/v3/wasm.proto • WASM プログラムを Filter として利⽤し、 レコードの変更処理を⾏う • (⼀応 Input plugin もある) https://docs.fluentbit.io/manual/pipeline/filters/wasm https://docs.fluentbit.io/manual/development/wasm-input- plugins • 作成したポリシーを WASM 形式で出⼒し、 ブラウザや各種プログラムから利⽤する https://www.openpolicyagent.org/docs/latest/wasm/ • WASM プログラムをフィルターとして利⽤し、 スケジューリングロジックの変更を⾏う • kube-scheduler に wazero ランタイムを内包 https://github.com/kubernetes-sigs/kube-scheduler-wasm- extension
  9. そのほか WASM の話 • knqyf263/go-plugin: WASM のプラグイン機構を実装するための Go 製 SDK

    • WASM のその他の話 • WASI preview 2 • Component model • WIT: Wasm Interface Types (wit-cheat-sheet) https://speakerdeck.com/ainozaki/cnds2024 https://knqyf263.hatenablog.com/entry/2022/08/30/052303
  10. Containerd v2.0 • User Namespace のサポート • Sandbox 機能の提供(ランタイムレベルでの Pod

    サポート) • コンテナへのデバイス追加や 計算リソースの設定変更を⾏う NRI の追加 • NRI: Node Resource Interface https://github.com/ktock/resources/blob/main/container-runtime-meetup-5/containerd.pdf
  11. Kubernetes: Gateway API • Gateway API が 2023/10/31 に GA

    Release • 2022 年には Service 間通信や東⻄トラフィックに Gateway API 利⽤を⽬指す GAMMA initiative の誕⽣ • GAMMA: Gateway API for Mesh Management and Administration • Gateway Enhancement Proposal(GEP) によって機能開発・修正は管理
  12. Kubernetes: Gateway API • Meta resources and policy attachments GEP-2648

    GEP-2649 https://sched.co/1Yhh1 GEP で提案されている各種機能(RateLimiting / Authentication / etc...)も フィールドを新規追加するのではなく、ポリシー経由にすることも検討されています。 kind: RetryPolicy metadata: name: foo spec: maxRetries: 5 targetRef: kind: HTTPRoute name: http-app-1 sectionName: path1 kind: HTTPRoute metadata: name: http-app-1 spec: rules: - name: path1 matches: - path: type: Prefix value: /path1 各ベンダーが任意の CRD を作成し、 Gateway API を拡張できる仕組み GEP-2649 では ポリシーの継承について策定中
  13. Kubernetes: Gateway API Discoverability を上げるために幾つかの GEP が進⾏中 • Supported features

    GEP-2162 • Related Resources GEP未定義 Conformance Profile / Report の提供 https://sched.co/1Yhh1 kind: GatewayClass metadata: name: gke-l7-rilb spec: {...} status: supportedFeatures: - HTTPRoute - HTTPRoutePathRedirect - HTTPRouteHostRewrite - GRPCRoute resourceRepository: - Group: security.istio.io Kind: AuthorizationPolicy - Group: security.istio.io Kind: RequestAuthentication
  14. Kubernetes: Validating Admission Policy kube-apiserver 上で CEL を⽤いたリソースの検証を⾏う仕組み(v1.30 stable) validating

    webhook server なしで良いため、導⼊が容易・リソース消費が少ない c.f. CRD にも CEL による Scheme Validation 機能がある kind: ValidatingAdmissionPolicy metadata: name: demo-policy.example.com spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["apps"] operations: ["CREATE", "UPDATE"] resources: ["deployments"] validations: - expression: "object.spec.replicas <= 5" kind: Deployment metadata: name: test spec: replicas: 3 template: spec: contaienrs: - name: nginx-con image: nginx:latest
  15. LLM runtime and API server ⼤規模⾔語モデルを動作させるランタイム API や ChatGPT ライクな

    UI なども提供 • Ollama • インテグレーションが豊富 • LlamaEdge • wasi-nn を利⽤した WasmEdge を利⽤して動作 • OpenAI Compatible な API KubeCon でも NA 2023 / EU 2024 の Keynote でデモを実施
  16. LLMnetes 「Future of Intelligent Cluster Ops: LLM-Azing Kubernetes」 https://sched.co/1YeQG ⾃然⾔語で指定した命令を

    Kubernetes Controller が実⾏ 内部的には input をもとに OpenAPI or Llama に問い合わせ apiVersion: llmnetes.dev/v1alpha1 kind: Command metadata: name: my-command spec: input: Create 3 nginx pods that will serve traffic on port 80. apiVersion: llmnetes.dev/v1alpha1 kind: ChaosSimulation metadata: name: chaos-simulation-cr spec: level: 10 command: break my cluster networking layer (or at least try to) https://github.com/llmnetes/llmnetes https://github.com/llmnetes/llmnetes/blob/main/internal/controller/chaossimulation_controller.go#L82-L85
  17. そのほか ML 関連のプロダクト • Armada / Volcano / Kueue •

    各種バッチ・キューイング関連システム • おすすめセッション︓https://sched.co/1Yhh7 • OpenLLMetry: • OpenTelemetry の拡張機能で、LLM アプリケーションに対する可観測性を実現する • LLM Provider・Vector DB・フレームワークとの連携のメトリクス
  18. Service Mesh Service Mesh の簡素化のために、⾮サイドカー構成の撤廃へ • 運⽤負荷低減 • リソース消費量の削減 •

    サイドカーコンテナのライフサイクル管理 https://www.solo.io/blog/istio-ambient-mesh-evolution-service-mesh
  19. Service Mesh: Istio ambient mesh https://istio.io/v1.18/blog/2022/introducing-ambient-mesh/ Secure Overlay Layer(L4) と

    L7 Processing Layer(L7) L4 レイヤーの処理を⾏う Rust 製 ztunnel proxy L7 に関する処理が不要な場合は Secure Overlay Layer のみで導⼊可能
  20. Service Mesh: Istio ambient mesh https://istio.io/v1.18/blog/2022/introducing-ambient-mesh/ Secure Overlay Layer(L4) と

    L7 Processing Layer(L7) L7 レイヤーの処理が必要なトラフィックのみ Envoy Proxy へ fallback
  21. Service Mesh: Cilium CNI の導⼊のみで基本的な Service Mesh の機能が利⽤可能(Agent に Envoy

    内包) => シンプルな構成、リソース消費量の低減、サイドカー起動順序依存の排除 基本的には eBPF で処理を⾏い、L7 相当の処理が必要なものだけ Envoy へ Fallback https://isovalent.com/blog/post/cilium-service-mesh/
  22. OpenTelemetry Collector / Fluent Bit v3 OpenTelemetry Collector は Metrics/Logs/Traces

    を処理・転送するエージェント • 標準化された仕様があり、プロトコルや SDK が提供 • ベンダー⾮依存(プラグインにより様々なベンダーに対応) 最近は Fluent Bit も Metrics/Logs/Traces 対応が推し 3 ⽉に v3 がリリース Fluent Bit vs OTel Collector • https://sched.co/1Rj68 • https://sched.co/1YFhI
  23. Whitepaper & Landscape 各要素技術を学ぶだけではなく、根本となる概念や考え⽅・指針なども学ぶべき ⾃組織の状況などをもとに意思決定する際にも役⽴つ e.g. Prometheus の使い⽅ではなく、Observability の概念や具体的なプラクティス CNCFは、オープンソースでベンダー中⽴プロジェクトのエコシステムを育成・維持して、このパラダイムの採⽤を促進し

    たいと考えてます。 私たちは最先端のパターンを⺠主化し、これらのイノベーションを誰もが利⽤できるようにします。 CNCF は特定のプロダクトによらず、 俯瞰した考え⽅や指針などを学んだり、組織/事業の成⻑を⽀えるプラクティスを公開
  24. Whitepaper CNCF Observability Whitepaper 各種データ(メトリック、ログ、トレース、構造化イベントなど)の⽬的とプラクティスの明⽂化 Cloud Native Security Whitepaper 幅広い

    Cloud Native のレイヤーや各ライフサイクルでのセキュリティ対策について CNCF Storage Landscape Whitepaper Availability, scalability, consistency, durability, performanceなどの⽐較 Cloud Native Artificial Intelligence Whitepaper AI/ML と CloudNative の融合や、MLOps の各ステップでの課題など(遠い AIOps の話) CNCF Serverless Whitepaper Serverless のユースケースや FaaS などとの⽐較について
  25. Whitepaper CNCF Platforms White Paper Platform を実装する際の指針・要素・組織構成や計測⽅法など Chaos Engineering Whitepaper

    Chaos Engineeringの原則や、ユースケース・要件・関連ツールのリスト Kubernetes Policy Management White Paper ポリシー制御に関するアーキテクチャや、各ライフサイクルでのポリシー制御について CNCF Operator White Paper Operator のデザインパターン、ライフサイクル管理、セキュリティ、フレームワークなどの提供 Edge Native Applications Principles Whitepaper Edge Nativeの概念、Cloud Native との相関についてに指針
  26. Whitepaper Accelerating Cloud Native in Telco White Paper Telco 向けの

    CloudNative 化への課題と対応⽅法など Service Mesh Patterns 60種類のベストプラクティスや、Service Mesh プロダクトの⽐較
  27. Landscape Cloud Native 領域の各種ソフトウェアの⼀覧 最近では AI/ML 関連の Landscape も公開 •

    Cloud Native Landscape • Serverless Landscape • WASM Landscape • Cloud Native AI Landscape • LF AI & Data Foundation Landscape • Cloud Native Sustainability Landscape
  28. AIOps 「Intelligent Observability: The Foundation for Operating Smarter in the

    Age of AI」 OpenTelemetry Maintainer や TAG O11y Co-chair などの Sharma さん https://sched.co/1YeP6
  29. Energy Efficiency CNCF は AI/ML Computing と Carbon nutral /

    Sustainability の両軸を特に推進 「Empowering Efficiency: PEAKS - Orchestrating Power-Aware Kubernetes Scheduling」 使⽤率による電⼒消費量の傾向などをもとに学習した結果でスケジューリングを⾏う https://sched.co/1YeP1 「Unlock Energy Consumption in the Cloud with eBPF 」 Kepler プロジェクトの eBPF や RAPL を利⽤した電⼒消費量の収集 https://sched.co/1YeOO