CUEとKubernetesカスタムオペレータを用いた新しいネットワークコントローラをつくってみた

Transcript

1. © NTT Communications Corporation All Rights Reserved. CUEとKubernetesカスタムオペレータを用いた 新しいネットワークコントローラをつくってみた NTTコミュニケーションズ イノベーションセンター 奥井 寛樹 1
2. © NTT Communications Corporation All Rights Reserved. 自己紹介 • NTTコミュニケーションズ • Software Engineer • 奥井 寛樹 • 略歴 ◦ 伝送ネットワーク 設定自動化システム開発 ◦ DevOpsプラットフォーム（Qmonus Value Stream）開発 ◦ IoTデータ収集基盤 モダナイゼーション @HirokiOkui hrk091 2
3. © NTT Communications Corporation All Rights Reserved. こ 取組で目指しているも 5 M tro / Cor A ss OTN, VLAN, IP DWDM, MPLS, EVPN, SR… DC / Clou Us r Sit OTN, VLAN, IP APIオーケストレータ サービスオーダWebUI オペレーションWebUI ユーザ 運用担当 ユーザインテント 「宅Aと宅Bで専用線を張りたい！」 「宅AをクラウドとDedicated Connectしたい！」 ?
4. © NTT Communications Corporation All Rights Reserved. こ 取組で目指しているも 6 M tro / Cor A ss OTN, VLAN, IP DWDM, MPLS, EVPN, SR… DC / Clou Us r Sit OTN, VLAN, IP Infractructure as Codeで管理するConfiguration/Management基盤 APIオーケストレータ サービスオーダWebUI オペレーションWebUI ユーザ 運用担当 ユーザインテント 「宅Aと宅Bで専用線を張りたい！」 「宅AをクラウドとDedicated Connectしたい！」
5. © NTT Communications Corporation All Rights Reserved. こ 取組で目指しているも 7 M tro / Cor A ss OTN, VLAN, IP DWDM, MPLS, EVPN, SR… DC / Clou Us r Sit OTN, VLAN, IP Infractructure as Codeで管理するConfiguration/Management基盤 APIオーケストレータ サービスオーダWebUI オペレーションWebUI ユーザ 運用担当 ユーザインテント 「宅Aと宅Bで専用線を張りたい！」 「宅AをクラウドとDedicated Connectしたい！」 高レベルなインテントが 実コンフィグに変換されて E2Eの全装置に投入される
6. © NTT Communications Corporation All Rights Reserved. こ 取組で目指しているも 8 M tro / Cor A ss OTN, VLAN, IP DWDM, MPLS, EVPN, SR… DC / Clou Us r Sit OTN, VLAN, IP Infractructure as Codeで管理するConfiguration/Management基盤 APIオーケストレータ サービスオーダWebUI オペレーションWebUI ユーザ 運用担当 これをつくりたい
7. © NTT Communications Corporation All Rights Reserved. 本発表 スコープ • スコープ ◦ 高レベル ユーザインテントから コンフィグ生成 ◦ 宣言的なコンフィグ管理 ◦ GitOps • スコープ外 ◦ SDNによるコントロールプレーン ◦ システム間連携をするワークフロー機能 ◦ 監視 ◦ ZTP ◦ etc… 9
8. © NTT Communications Corporation All Rights Reserved. 発表 流れ • IaCと ？GitOpsと ？ • クラウドネイティブなアプリ開発における IaCとGitOps • ネットワーク管理におけるIaCとGitOps 現在 • クラウドネイティブ技術を用いて新しいコントローラをつくってみた • デモ • 検証結果と課題 10
9. © NTT Communications Corporation All Rights Reserved. IaCと ？GitOpsと ？ 11
10. © NTT Communications Corporation All Rights Reserved. IaCとGitOps 12 • IaC(Infractructure as Code)やGitOpsを実践する例がネットワークでも増えている • IaCやGitOps 、コードを宣言的に表現してGitで管理をすれ よいわけで ない ◦ 正しく活用しないと、本質的な価値を享受できない • IaCとGitOpsについて、あらためておさらいします
11. © NTT Communications Corporation All Rights Reserved. IaCで大事なこと（特に開発目線で） • インフラをコードで宣言的に記述し、ソフトウェア開発 プラクティスを活かす ◦ ツールを使うだけでなく、システム・プロセスが大事 ◦ 自動テスト、CI/CD、モニタリング、高 なリリースサイクル ... • 高いプログラマビリティ ◦ モジュール化により複雑な具象を隠蔽し、インテントを記述しやすい 高抽象なインターフェースを提供する ◦ 保守性 高い記述ができる（モジュール化、凝集化、型指向、テスタブル） • CIでテストできる ◦ CIでデプロイ前に問題を検出できる（シフトレフト） ◦ 静的解析・構成テスト・ポリシーエンフォースメント 13
12. © NTT Communications Corporation All Rights Reserved. GitOpsで大事なこと • SSoT(Single Source of Truth) ◦ 単一 Gitレポジトリでコンフィグ全体が管理されており、唯一 情報源となっている • Git branch headを変えることで、適用するコンフィグ 版を変更できる ◦ PRマージをトリガとして、マージされた版がデプロイされる ◦ 古いrevisionに戻すと、rollbackできる • Pullベース アプローチ ◦ SSoT Gitレポ マニフェストを、 外部から値注入せずにそ ままデプロイする ◦ Pullベースにすることで、シークレットを デリバリ先に近いところに置ける 14 Git操作だけでデリバリが 完結する = GitOps pull CIOps push hook deploy GitOps push deploy Push → 値の加工・注入が容易にできてしまう Pull → 値の注入処理をはさみにくい
13. © NTT Communications Corporation All Rights Reserved. IaC・GitOps 構成例 Manifest Repo IaC Platform Admin Approve PR merge Test Pull PR Driver (Agent) Data Mapping GitOps IaC GitOps Operator Data Mapping 15
14. © NTT Communications Corporation All Rights Reserved. クラウドネイティブなアプリ開発における IaCとGitOps 16
15. © NTT Communications Corporation All Rights Reserved. IaC・GitOpsで重要な6つ 機能 Manifest Repo Admin Approve PR merge Test Pull PR Driver (Agent) Data Mapping GitOps IaC GitOps Operator 1 プログラマビリティ 2 IaC実行エンジン 3 ドライバ (プロバイダ) 4 構成テストツール 5 GitOpsエンジン 6 シークレット管理 IaC Platform 18
16. © NTT Communications Corporation All Rights Reserved. アプリリリースにおけるIaCとGitOps トレンド 19 機能 概要 ツール・OSS Terraform 場合 Kubernetes 場合 1 プログラマビリティ - モジュール化、高抽象化 - 型指向でテスタブルな記述 HCL CDKTF kustomize Helm, CUE 2 IaC実行エンジン - 制御対象リソースをIaC 宣言状 態に冪等収束させるエンジン Terraform Kubernetes Reconciliation Loop 3 ドライバ (プロバイダ) - リソース毎 プロトコル・インター フェース差異を吸収 Terraform Provider Kubernetes Custom Operator 4 構成テスト - 静的解析、ポリシーチェックにより デプロイ前に問題を検出 Sentinel Admission Webhook OPA, Kyverno 5 GitOpsエンジン - PullベースでGit コンフィグをそ ままデプロイ(SSoT) Terraform Cloud Atlantis ArgoCD FluxCD 6 シークレット管理 - シークレット 漏洩防止 - SecretManagerと 連携 Vault External Secrets Secrets Store CSI Driver
17. © NTT Communications Corporation All Rights Reserved. アプリリリースにおけるIaCとGitOps トレンド 20 機能 概要 ツール・OSS Terraform 場合 Kubernetes 場合 1 プログラマビリティ - モジュール化、高抽象化 - 型指向でテスタブルな記述 HCL CDKTF kustomize Helm, CUE 2 IaC実行エンジン - 制御対象リソースをIaC 宣言状 態に冪等収束させるエンジン Terraform Kubernetes Reconciliation Loop 3 ドライバ (プロバイダ) - リソース毎 プロトコル・インター フェース差異を吸収 Terraform Provider Kubernetes Custom Operator 4 構成テスト - 静的解析、ポリシーチェックにより デプロイ前に問題を検出 Sentinel Admission Webhook OPA, Kyverno 5 GitOpsエンジン - PullベースでGit コンフィグをそ ままデプロイ(SSoT) Terraform Cloud Atlantis ArgoCD FluxCD 6 シークレット管理 - シークレット 漏洩防止 - SecretManagerと 連携 Vault External Secrets Secrets Store CSI Driver
18. © NTT Communications Corporation All Rights Reserved. IaC 宣言状態に収束させる実行エンジン • IaCで宣言された状態に収束させるに 、実行エンジンが必要 ◦ 非常駐型：Terraformなど IaCツール全般 ◦ 常駐型：Kubernetes Reconciliation Loop ← 昨今 トレンド • k8s Reconciliation Loop ◦ 観測されたインフラ状態と宣言状態が一致するまで、 デプロイ処理を繰り返す k8s 仕組み ◦ k8s リソース 全てこ 仕組みで制御される • k8sカスタムオペレータ ◦ k8s上で、ユーザが独自 定義を持ち込み、 任意 リソースをIaCとして管理するk8s拡張方式 ◦ CNCF 多く OSS 、k8sカスタムオペレータとして実装 21 カスタムオペレータで管理する 対象リソースは、Custom Resource(CR)と呼ばれます
19. © NTT Communications Corporation All Rights Reserved. 現代的なGitOps Manifest Repo Reconciliation Loop Admin Approve PR merge Test Pull PR 23 Custom Operator Admission Webhook
20. © NTT Communications Corporation All Rights Reserved. 現代的なGitOps Manifest Repo Reconciliation Loop Admin Approve PR merge Test Pull PR 24 Custom Operator Admission Webhook 1 プログラマビリティ 2 IaC実行エンジン 3 ドライバ (プロバイダ) 4 構成テストツール 5 GitOpsエンジン 6 シークレット管理
21. © NTT Communications Corporation All Rights Reserved. ネットワーク管理における IaCとGitOps 現在 25
22. © NTT Communications Corporation All Rights Reserved. ネットワーク管理におけるIaCとGitOps 現在 26 機能 概要 ツール・OSS Ansible Module/Roleがある Module/Roleがない 1 プログラマビリティ - モジュール化、高抽象化 - 型指向でテスタブルな記述 Ansible Module/Roleを 加工 汎用言語でスクラッチ (主にPython + Jinja2) 2 IaC実行エンジン - 制御対象リソースをIaC 宣言状 態に冪等収束させるエンジン Ansible Module/Roleで 手続き的に実装 スクラッチ 3 ドライバ (プロバイダ) - リソース毎 プロトコル・インター フェース差異を吸収 Ansible Moduleで実装 スクラッチ 4 構成テスト - 静的解析、ポリシーチェックにより デプロイ前に問題を検出 別途作り込み スクラッチ（難しい） 5 GitOps - PullベースでGit コンフィグをそ ままデプロイ(SSoT) WebhookでCIOps or Agentでpull化 WebhookでCIOps 6 シークレット管理 - シークレット 漏洩防止 - SecretManagerと 連携 Ansible Vault スクラッチ or 外部ツール
23. © NTT Communications Corporation All Rights Reserved. ネットワーク管理におけるIaCとGitOps 現在 27 機能 概要 ツール・OSS Ansible Module/Roleがある Module/Roleがない 1 プログラマビリティ - モジュール化、高抽象化 - 型指向でテスタブルな記述 Ansible Module/Roleを 加工 汎用言語でスクラッチ (主にPython + Jinja2) 2 IaC実行エンジン - 制御対象リソースをIaC 宣言状 態に冪等収束させるエンジン Ansible Module/Roleで 手続き的に実装 スクラッチ 3 ドライバ (プロバイダ) - リソース毎 プロトコル・インター フェース差異を吸収 Ansible Moduleで実装 スクラッチ 4 構成テスト - 静的解析、ポリシーチェックにより デプロイ前に問題を検出 別途作り込み スクラッチ（難しい） 5 GitOps - PullベースでGit コンフィグをそ ままデプロイ(SSoT) WebhookでCIOps or Agentでpull化 WebhookでCIOps 6 シークレット管理 - シークレット 漏洩防止 - SecretManagerと 連携 Ansible Vault スクラッチ or 外部ツール ユーザが少なくAnsibleが未整備な 装置は結局スクラッチ開発 （伝送装置など） スクラッチ開発をすると手続き的な スクリプトになり、Jinja2でテンプ レートマッピングしてSSHで投げる だけになる IaCの実践はほぼ不可能
24. © NTT Communications Corporation All Rights Reserved. ネットワーク GitOps*1 例 28 Github GitOpsツール? Admin Approve PR merge CI PR - サービスオーダー - 装置コンフィグ キャッシュ - etc… Push Push *1: 正しく CIOps
25. © NTT Communications Corporation All Rights Reserved. ネットワーク GitOps*1 例 29 Github GitOpsツール? Ops Admin Approve PR merge CI PR PR reviewでCIの結果を見て判断しているが、 CIで確認したコンフィグが装置に入るとは限らない - SSoTでなく、外部依存がある - CIで検証した版と実環境で動いている版が異なる Push型であり、装置のシークレットが 集約される。セキュリティリスクが高い モデル・スキーマ情報がなく、静的解析は不可。 ゴールデンファイルとの差分確認しか出来ない。 検証は全てReviewerの目視確認に委ねられる。 外部(Netboxなど)に依存しており、SSoTでない Gitで過去の版に戻しても同じconfigを必ずしも 再現できない 構成ドリフト*1が発生する - サービス仕様・実装の変更 - 実機への手動設定変更 Push Push Ansible Moduleがなくスク ラッチだとシンプルな ユースケースに限定される *1: 正しく CIOps *1: NWコントローラで導出したコンフィグと、実機に入っているコンフィグに差異があること
26. © NTT Communications Corporation All Rights Reserved. クラウドネイティブ技術を用いて 新しいコントローラをつくってみた 30
27. © NTT Communications Corporation All Rights Reserved. つくりたいも • 任意 ネットワークコンフィグを高レベルなモデルに抽象化しIaCとして制御するも ◦ ネットワーク ユースケース・プロトコルスタック非依存、伝送も転送も何でも表現可能 ◦ 装置コンフィグ 低レベルすぎる で、高レベルへ 抽象化が必要 ▪ インテントベースになっているSDN そ ままで良いが、それ以外 既存設備など • GitOpsで、Git操作だけでデプロイを完結させる ◦ CIテスト → PRレビュー&マージ でデプロイ ◦ SSoTでありGit操作だけでロールバック • そ 他、基本機能としてほしいも ◦ マルチベンダー・マルチバージョン サポート ◦ マルチデバイス 分散トランザクション ◦ アーキテクチャ 柔軟性・開発容易性 31
28. © NTT Communications Corporation All Rights Reserved. 32
29. © NTT Communications Corporation All Rights Reserved. OSS化しました • https://github.com/nttcom/kuesta 33
30. © NTT Communications Corporation All Rights Reserved. kuesta アーキテクチャ 34 k8s Reconciliation Loop Ops Admin Approve PR merge Test Pull gNMI API Server Map Reduce Eval Composite Northbound Model Southbound Model Source Controller Device Rollout CR DeviceA Operator DeviceA Operator DeviceA CR DeviceA Operator DeviceA Operator DeviceB CR SSoT Multi-vendor Multi-version Devices DeviceA Operator DeviceA Operator DeviceA Subscriber DeviceA Operator DeviceA Operator DeviceB Subscriber Provision Change Notification
31. © NTT Communications Corporation All Rights Reserved. ネットワークIaC実現 ため 8つ 技術要件 1. ドキュメント型を定義できるスキーマ言語 2. 抽象モデルから マッピングを記述する言語 3. ManyToMany リソースマッピング 4. IaCをデプロイするエンジン 5. GitOpsエンジン 6. マルチデバイス間 分散トランザクション 7. 多様な装置に対するドライバープラグイン 8. デバイスシークレット 35
32. © NTT Communications Corporation All Rights Reserved. WHY HOW 1 ドキュメント型を定義できるスキーマ言語 • CIでテストを行うに 、ネットワークコンフィグ 型情報 必須 ◦ 型情報があることで、デプロイ前 静的解析で問題を検出できる • コーディング 品質が大きく改善 ◦ 汎用言語 構 体を出力することで、型安全なコーディングができる ◦ マッピング 実装でも、ポリシー 実装でも 36 • YANG ◦ ネットワークコンフィグ ドキュメントツリースキーマを定義できる ▪ 最近 多く 装置がYANG モデルを提供している ◦ pyang, goyangなどを使え 、汎用言語 構 体を出力できる ◦ 他 静的解析ツールと組み合わせて、コンフィグ 検査ができる
33. © NTT Communications Corporation All Rights Reserved. WHY HOW 2 抽象モデルから マッピングを記述する言語 • IaCで 、インテントを可読性高く記述したい ◦ 装置コンフィグ 低レベルすぎる で、高レベルへ 抽象化が必要 • 高レベルなモデルから低レベルな装置コンフィグへ マッピング処理 実装が必要 • YANG 生成型から、型安全にマッピング処理を 実装できる が望ましい 37 • Python, Goなど、YANGから型生成できる言語なら何でも良い ◦ ただし、テンプレートライブラリと 連携がシームレスな言語が良い • kuestaで CUEを使用（理由 後述） OneToMany
34. © NTT Communications Corporation All Rights Reserved. WHY 3 ManyToMany リソースマッピング（1） • 装置コンフィグ 、装置ごとに 独立した1つ ドキュメントとみなせる • 面・スライスで 抽象化をすると 上位・下位モデル間がManyToManyに • ManyToOne/ManyToMany 難しい ◦ ある上位モデル 更新時に、他 親から設定された コンフィグを保護しつつ、コンフリクトも避ける必要がある • ネットワークIaC ManyToManyと戦わなけれ ならない ◦ 装置コンフィグを直接扱う IaCで 、ManyToMany 避けられない 38 大量のManyToMany → マージ・コンフリクトを機械的に 解きつつスケールする方法が必要 クラウドIaCでは、ManyToManyは 特定のユースケースに限定するなど うまく避けています ManyToMany
35. © NTT Communications Corporation All Rights Reserved. CUE • データ 中にロジックを記述する新しいデータ記述言語 ◦ GCL(Google/Borg 設定言語） 作者が作った OSS • データ マージに強い ◦ 任意 数・任意 レイヤ ドキュメントツリーをマージ化 ◦ 評価順に依存せず、一意 結果に収束する（交換律と結合律） • 型と値と値制約を同一視して一緒に扱う型システム ◦ 値が収束すれ OK、値が不定なら検査エラー ◦ シンプルで可読性が高い • 高いプログラマビリティ ◦ ドキュメントツリーを宣言的プログラミングで記述 ◦ テンプレーティング、モジュール化などを CUEだけで実現 ◦ Go API、OpenAPI、Protobufなどから型を自動生成 39 // Value Alice: age: 20 // Type People: age: int // Constraint Member: age: > 18 // Validate Alice & People & Member Types and Values 交換律: a+b = b+a 結合律: (a+b)+c = a+(b+c)
36. © NTT Communications Corporation All Rights Reserved. HOW 3 ManyToMany リソースマッピング（2） 40 • CUEを使う ◦ ManyToManyに強い、型安全、コンフィグ プログラマビリティが高い • ただし、大量 リソースを一気に評価するとパフォーマンス問題がでる で、 以下 2つに処理ステップを分ける 1. 上位モデル → 下位モデル（装置コンフィグ）へ マッピング 2. 1 処理結果をマージして、実際 装置コンフィグを生成 中間コンフィグもgitにコミット してキャッシュとして使うことで performanceを改善
37. © NTT Communications Corporation All Rights Reserved. 4 IaCをデプロイするエンジン 41 WHY HOW • デプロイ先 状態を観測しつつ、 IaCで宣言された状態に 一致するようにデプロイ処理を進めるエンジンが必要 • 全体を駆動する基盤となるため、拡張性が高い も が望ましい • Kubernetes(k8s) ◦ k8sカスタムコントローラを用いることで、ネットワーク装置 制御もできる ◦ ArgoCD、FluxCDなど、k8sネイティブなGitOpsツールがある ◦ 必要に応じて、任意 オペレーション用 Podを起動し処理を実行できる ◦ 成熟していて開発しやすい（情報・ツール・開発者が多い）
38. © NTT Communications Corporation All Rights Reserved. 5 GitOpsエンジン 42 WHY HOW • SSoTなGitレポジトリからコンフィグを取得して、加工・注入せず装置に流し込む • Git 操作だけで完結するために必要 • FluxCD source-controllerを使う ◦ FluxCD gitからpullする機構を使いつつ、 k8sへ apply以外 用途に拡張できる FluxCD source-controller Pull GitRepository CR source-watcher Update Watch : Pod : Custom Resource(CR)
39. © NTT Communications Corporation All Rights Reserved. 6 マルチデバイス間 分散トランザクション 43 WHY HOW • 上位モデルを作成・更新することで複数 装置に 設定が入るため、装置間 トランザクションが必要 ◦ all or nothingを保証して、一部に み設定が入る を回避 • DeviceRollout CRとコントローラを実装し、トランザクション 管理をさせる ◦ ArgoRolloutを参考にした設計 Device Driver Running Healthy Running Degraded Completed abort succeed detect change succeed or abort DeviceRollout CR FluxCD source-controller Pull GitRepository CR Update Watch Update source watcher Watch
40. © NTT Communications Corporation All Rights Reserved. 7 多様な装置に対するドライバプラグイン 44 WHY HOW • マルチベンダ・マルチバージョン 各デバイスを制御したい ◦ デバイスごとに、SSH/REST/NETCONF/gNMIと異なるプロトコルを使用しており、 コンフィグ syntax/semanticsも異なる • k8sカスタムオペレータを使用する ◦ カスタムコントローラ : コンフィグを実行するドライバ処理 実装 ◦ カスタムリソース: 装置 アドレスなど 接続情報、投入されたコンフィグを保持 • 装置・バージョンごとに実装すれ 、k8s 仕組みを活用していくらでも拡張可能 DeviceRollout CR FluxCD source-controller Pull GitRepository CR Update Watch Update DeviceA Operator DeviceA CR source watcher Watch DeviceB Operator DeviceB CR Watch
41. © NTT Communications Corporation All Rights Reserved. 8 デバイスシークレット 45 WHY HOW • 装置 アクセスに使用するパスワードを安全に管理したい • 漏洩リスク・漏洩時 影響を最小化したい • k8s Secretを使って管理し、k8sで盛んに開発が進められている Secret管理プラクティスに則って管理する • External Secrets Operatorを使って、パブリッククラウド SecretManagerで管理する DeviceRollout CR FluxCD source-controller Pull GitRepository CR Update Watch Update source watcher DeviceB Operator DeviceB CR Watch Secret Ref Use ExternalSecrets Operator
42. © NTT Communications Corporation All Rights Reserved. ネットワークIaC実現 ため 技術選定 1. ドキュメント型を定義できるスキーマ言語 2. 抽象モデルから マッピングを記述する言語 3. ManyToMany リソースマッピング 4. IaCをデプロイするエンジン 5. GitOpsエンジン 6. マルチデバイス間 分散トランザクション 7. 多様な装置に対するドライバープラグイン 8. デバイスシークレット 46 ➔ YANG ➔ CUE ➔ CUE ➔ k8s ➔ FluxCD ➔ DeviceRollout(独自) ➔ k8sカスタムオペレータ(独自) ➔ External Secrets Operator この4つはすべて k8sカスタムオペレータ
43. © NTT Communications Corporation All Rights Reserved. kuesta アーキテクチャ 47 k8s Reconciliation Loop Ops Admin Approve PR merge Test Pull gNMI API Server Map Reduce Eval Composite Northbound Model Southbound Model Source Controller Device Rollout CR DeviceA Operator DeviceA Operator DeviceA CR DeviceA Operator DeviceA Operator DeviceB CR SSoT Multi-vendor Multi-version Devices DeviceA Operator DeviceA Operator DeviceA Subscriber DeviceA Operator DeviceA Operator DeviceB Subscriber Provision Change Notification
44. © NTT Communications Corporation All Rights Reserved. ドライバ実装 どうする？ k8s Reconciliation Loop Ops Admin Approve PR merge Test Pull gNMI API Server Map Reduce Eval Composite Northbound Model Southbound Model Source Controller Device Rollout CR DeviceA Operator DeviceA Operator DeviceA CR SSoT OpenConfig Devices DeviceA Operator DeviceA Operator DeviceA Subscriber gNMI gNMI Subscribe 48
45. © NTT Communications Corporation All Rights Reserved. ドライバ実装 ➞ OpenConfigを活用 k8s Reconciliation Loop Ops Admin Approve PR merge Test Pull gNMI API Server Map Reduce Eval Composite Northbound Model Southbound Model Source Controller Device Rollout CR DeviceA Operator DeviceA Operator DeviceA CR SSoT OpenConfig Devices DeviceA Operator DeviceA Operator DeviceA Subscriber gNMI gNMI Subscribe OpenConfig YANG Go Struct CUE type def ygot generator cue get 49 OpenConfig YANGなら go structを介して CUE型に自動変換できる
46. © NTT Communications Corporation All Rights Reserved. kuesta 全体像 50 k8s Reconciliation Loop Ops Admin Approve PR merge Test Pull gNMI API Server Map Reduce Eval Composite Northbound Model Southbound Model Source Controller Device Rollout CR DeviceA Operator DeviceA Operator DeviceA CR DeviceA Operator DeviceA Operator DeviceB CR SSoT Multi-vendor Multi-version Devices DeviceA Operator DeviceA Operator DeviceA Subscriber DeviceA Operator DeviceA Operator DeviceB Subscriber Provision Change Notification OpenConfig YANG Go Struct CUE type def ygot generator cue get
47. © NTT Communications Corporation All Rights Reserved. kuesta 全体像 51 k8s Reconciliation Loop Ops Admin Approve PR merge Test Pull gNMI API Server Map Reduce Eval Composite Northbound Model Southbound Model Source Controller Device Rollout CR DeviceA Operator DeviceA Operator DeviceA CR DeviceA Operator DeviceA Operator DeviceB CR SSoT Multi-vendor Multi-version Devices DeviceA Operator DeviceA Operator DeviceA Subscriber DeviceA Operator DeviceA Operator DeviceB Subscriber Provision Change Notification OpenConfig YANG Go Struct CUE type def ygot generator cue get 1 YANGによる スキーマ定義 2 CUEによる上位・下位モデル間の マッピング実装 3 CUEによるManyToManyの マッピング・コンフィグ合成 4 k8s Reconciliation Loopに よるIaCエンジン 5 FluxCDによるGitOps 6 DeviceRolloutによる マルチデバイストランザクション 7 k8sカスタムオペレータ によるドライバプラグイン 8 ExternalSecrets Operatorによる パブリッククラウドでのSecret管理
48. © NTT Communications Corporation All Rights Reserved. デモ 52
49. © NTT Communications Corporation All Rights Reserved. • kuesta ドキュメントサイト getting-startedをやります ◦ https://nttcom.github.io/kuesta-website/docs/getting-started/ • デモ 流れ ◦ kindを用いてローカルに k8sクラスタを立ち上げる ◦ kuestaをinstall ◦ サンプル サービスを作って、 GitOpsできていることを確認 • デモ 構成 ◦ ローカル k8sクラスタ と kuesta一式 ◦ OpenConfig/gNMI対応 エミュレータ2台 ◦ エミュレータに対応したドライバ （Kuberenetes カスタムオペレータ） デモ 53 OcDemo Controller OcDemo CR OcDemo CR
50. © NTT Communications Corporation All Rights Reserved. 検証結果と課題 54
51. © NTT Communications Corporation All Rights Reserved. • 対象装置：伝送ホワイトボックス（ Galileo Flex T） • サポートしているOpenConfig YANGからカスタムオペレータを作成し、 kuestaから GitOpsすることで、ライン側を導通しクライアント間を疎通させることに成功 *1 実機と 接続検証 55 Galileo Flex T *1: 本研究 、国立研究開発法人 情報通信研究機構（ NICT）が運用する NICT 総合テストベッド「 B5G高信頼仮想化環境」を用いて行われました。
52. © NTT Communications Corporation All Rights Reserved. これまで 成果 • クラウドネイティブなアプリ開発で用いられている IaC・GitOps プラクティスを ネットワークIaCに持ち込んで、最低限で あるが E2Eで 動作検証ができた ◦ OpenConfig/gNMIな装置であれ 、ドライバを作って実機接続検証できた • 方式 妥当性・有用性を検証し、ある程度 確信を得た • 一方で、課題も ◦ Reconciliation Loop 外（CUEで マッピング）までユースケース実装を追い出している で、ネットワーク 状態を観測しながら管理をすることが難しい ▪ カスタムオペレータに特定ユースケースを実装すれ 可能だが、レイヤ分離構 がおかしくなる ▪ コンフィグだけに特化する案もあるが、システム全体 複雑さ 低減につながらない ◦ 素直に、特定 ユースケース・デバイス向け カスタムオペレータを作るほうが、 実装 簡単だし責務 凝集もできる 56
53. © NTT Communications Corporation All Rights Reserved. ここからが大変 • まだPoC 域を出てない • 本格的に使えるようにするに 、必要なも がたくさん ◦ OpenConfig/gNMI以外 プロトコル サポート ◦ ドライバを作りやすくするため Plugin Framework 作り込み ◦ OpenConfig以外 YANG CUE変換 ◦ Pre/Post-check、監視、そ 他EMS/NMSとして 機能（自装 or 連携） • 1〜2人で 到底開発できない ◦ コミュニティで開発したい → OSS化してみた ◦ 装置 ドライバに関して 、ベンダにコントリビュートしてもらえるとありがたい ▪ そ ために 、ビジネス インセンティブが必要。。。 57 Kubebuilderでは 不十分で、専用のものが必要
54. © NTT Communications Corporation All Rights Reserved. 議論: お訊きしたいこと • こ 取組、どう思いますか？ ◦ 👍ネットワークモデル非依存で任意 抽象モデル化して、 IaC・GitOpsできるところに 　新規性 ある。コンフィグが複雑なサービスを開発するときに 有用な ず ◦ 👎ただし、こ 状態に持っていくまで ハードルが高い（ドライバ開発など） ◦ 👎監視や、装置状態を観測しながら連携する が難しい • 「ネットワークモデルとベンダ非依存で 任意コンフィグ抽象化」 欲しいですか？ ◦ こ ユースケースで成功している某プロダクトがある で、ニーズ ある認識 ▪ ツールセットが充実してきたら、楽にシステム開発できるようになる（ ず） ◦ 伝送 システム開発やってるとかなり欲しい ですが、みなさんどうですか？ • ニーズがあるとして、作りたいと思いますか？ ◦ CUEとKubernetesカスタムオペレータに可能性を感じた で、 PoC作ってみました ◦ 「動くも ファースト」で Ansibleで良く ？という考え方も全然あると思ってます 58
55. © NTT Communications Corporation All Rights Reserved. まとめ 59 • CUEとKubernetesカスタムオペレータを用いて、ネットワーク IaCを行う kuestaというOSSを作りました ◦ https://github.com/nttcom/kuesta/ • すぐに試せる で、getting-startedをやってみてください！ ◦ 面白いと思ったら、ぜひ Starを付けてください ◦ IssueやDiscussionに思ったことをコメントください • こ 取組 是非について、忌憚ないご意見をください ◦ 気に入った！私もやるぜ！ という方 、ぜひお声がけください 🙇🙇🙇