「宣言的API」で指示をして、Kubernetesに「定期的な運用の一部」を任せる方法 / agile-tech-expo-01-202101-amsy810

Kubernetesでは、宣言的APIで定義した状態に収束させるReconciliation Loopの仕組みによって成り立っています。これはあるべき状態をもとに、Controller(Operator)というプログラムが運用者に変わってその状態を実現させるための仕組みです。基本的な機能もこの仕組みを使って実現されており、プロダクト継続的なアップデートを行い、新しい機能の追加を容易にするような仕組みを備えています。
このセッションでは、基本的な機能からはじめて、いくつかのエコシステムも例に上げて具体例を紹介しつつ、注意すべき点や考慮すべき点を紹介します。

Speaker
青山 真也 さん Masaya Aoyama
株式会社CyberAgent KaaS Product Owner, Developer Experts (Kubernetes/CloudNative)

Agile Tech EXPO Online
New Normal Agile Episode 1
https://202101.agiletechexpo.com/

Transcript

1. Masaya Aoyama
   CyberAgent
   「宣言的API」で指示をして、
   Kubernetesに「定期的な運用の一部」を任せる方法
   Agile Tech Expo – New Normal Agile Eposode 1
   amsy810 @amsy810
   

   View Slide

2. - Co-chair
   ੨ࢁ ਅ໵
   + CREATIONLINE - 技術アドバイザ
   + SAKURA Internet Research Center – 客員研究員
   + 3-shake 技術顧問
   + PLAID
   - Organizer
   - KaaS Product Owner - Publications
   Twitter: @amsy810
   

   View Slide

3. ͳͥ CloudNative ͕
   ొ৔ͨ͠ͷ͔ʁඞཁͳͷ͔ʁ
   

   View Slide

4. Cloud Nativeとは？
   クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの
   近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能
   力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービ
   ス、イミュータブルインフラストラクチャ、および宣言型APIがあります。
   これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅
   牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測ど
   おりに行うことができます。
   Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育
   成・維持して、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化
   し、これらのイノベーションを誰もが利用できるようにします。
   CNCF Cloud Native Defenition v1.0, CNCF, 2018-11-28
   (https://github.com/cncf/toc/blob/master/DEFINITION.md)
   

   View Slide

5. そもそもなぜ Cloud Native が必要なのか？
   ビジネスの成功・プロダクトの成功にはより良いものの提供が必要
   Webサービスにおけるより良いものとはなにか？
   • 高性能・停止が少ないサービス
   • 高機能・使いやすい価値のあるサービス
   ではどうすればよいか？
   

   View Slide

6. そもそもなぜ Cloud Native が必要なのか？
   ビジネスの成功・プロダクトの成功にはより良いものの提供が必要
   Webサービスにおけるより良いものとはなにか？ ではどうすればいいか？
   • 高性能・停止が少ないサービス ＝ 安定的に動作する環境
   • 高機能・使いやすい価値のあるサービス ＝ 短いアプリケーションの更新サイクル
   つまり、安定的に動作することができている状態を維持しつつも、
   頻繁にアプリケーションを更新することでユーザーに対してより良い価値を届けられている状態
   これにより、ビジネスやプロダクト展開のスピードを上げ、競争力を維持することができる
   

   View Slide

7. 高性能・停止が少ないサービス
   ＝「安定的に動作する環境」の実現
   クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの
   近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能
   力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービ
   ス、イミュータブルインフラストラクチャ、および宣言型APIがあります。
   これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅
   牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測ど
   おりに行うことができます。
   Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育
   成・維持して、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化
   し、これらのイノベーションを誰もが利用できるようにします。
   

   View Slide

8. 高機能・使いやすい価値のあるサービス
   ＝「短いアプリケーションの更新サイクル」の実現
   クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの
   近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能
   力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービ
   ス、イミュータブルインフラストラクチャ、および宣言型APIがあります。
   これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅
   牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測ど
   おりに行うことができます。
   Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育
   成・維持して、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化
   し、これらのイノベーションを誰もが利用できるようにします。
   

   View Slide

9. Cloud Native を実現するためのプラットフォーム
   CloudNative は先程のような状態を実現するための体系
   実現するために様々な技術が必要
   > このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフ
   ラストラクチャ、および宣言型APIがあります。
   様々な技術（エコシステム）を組み合わせるベースのプラットフォームの 1 つとして Kubernetes がある
   （CNCF はオープンソースで中立なものとして Kubernetes を推している）
   

   View Slide

10. Kubernetesͱ͸ʁ
    

    View Slide

11. Kubernetesとは？
    Kubernetes はコンテナオーケストレーションツール
    複数のノードから構成されたコンピューティングプールに対してコンテナを起動
    「コンテナ ≒ プロセス」なので、巨大なサーバに対してプロセスを起動しているとも言える
    構造化されたデータ（YAMLファイル）を元に宣言的に管理
    ※ Kubernetes では複数のコンテナをまとめたものを最小単位 Pod として扱います
    API 経由で
    操作
    

    View Slide

12. 一般的なインスタンスグループについて考えてみる
    何がしたくてインスタンスグループという機能があるか？
    インスタンスグループの仕組みとは？
    Instance group
    

    View Slide

13. 一般的なインスタンスグループについて考えてみる
    何がしたくてインスタンスグループという機能があるか？
    • 処理性能を増やすことで、高負荷時にサービス影響がないようにする
    • 冗長化することで、障害時にサービス影響がないようにする
    インスタンスグループの仕組みとは？
    ⇒ 同一イメージで作られた複数のインスタンスの数をコントロールし、
    指定されたレプリカ数を維持する
    Instance group
    

    View Slide

14. Kubernetes におけるインスタンスグループ
    Kubernetes におけるインスタンスグループに相当する機能 ReplicaSet
    ⇒ 同一イメージで作られた複数のインスタンスの数をコントロールし、
    指定されたレプリカ数を維持する
    ReplicaSet
    Pod Pod Pod
    

    View Slide

15. Kubernetes ͷ Reconciliation Loop
    

    View Slide

16. あるべき理想の状態（Desired State）≒ Declarative へと収束する
    何か問題が発⽣した場合でも、Controller により セルフヒーリングされる
    ※ 厳密には Controller も API を⽤いて変更します。
    reconcile()
    {
    …
    }
    登録
    (via API Request)
    Watch
    クラスタの状態
    コンテナの作成・削除
    Controller
    登録された時に、ただ起動させるだけではない
    Kubernetes と Reconciliation Loop
    

    View Slide

17. Controller 内では Reconciliation loop（調整ループ）と呼ばれる
    あるべき状態へと収束させるループ処理 が実⾏されている
    Kubernetes の内部には様々な Controller と呼ばれるプログラムが動作している
    Observe
    Diff
    Act Observe: 現状を確認
    Diff: 理想と現実の差分を計算
    Act: 差分に対する処理を実施
    reconcile()
    {
    …
    }
    Controller
    Kubernetes と Reconciliation Loop
    

    View Slide

18. ReplicaSet Controller の責務は
    「指定されたレプリカ数で Pod を維持し続けること」
    Observe
    Diff
    Act
    Observe: 現状を確認
    Diff: 理想と現実の差分を計算
    Act: 差分に対する処理を実施
    クラスタの状態
    理想の状態
    reconcile()
    {
    …
    }
    Controller
    例： ReplicaSet Controller の例
    

    View Slide

19. 例えば、コンテナ（Pod）を 3 つ起動させる ReplicaSet リソースの場合
    Observe
    Diff
    Act
    Observe: 現状を確認
    Diff: 理想と現実の差分を計算
    Act: 差分に対する処理を実施
    クラスタの状態
    理想の状態
    reconcile()
    {
    …
    }
    Controller
    例： ReplicaSet Controller の例
    

    View Slide

20. たとえば 2 つしかコンテナ（Pod）が起動していない場合…
    Observe: 理想=3、現状=2
    Observe
    Diff
    Act
    Observe: 現状を確認
    Diff: 理想と現実の差分を計算
    Act: 差分に対する処理を実施
    クラスタの状態
    理想の状態
    reconcile()
    {
    …
    }
    Controller
    例： ReplicaSet Controller の例
    

    View Slide

21. たとえば 2 つしかコンテナ（Pod）が起動していない場合…
    Diff: 1 つコンテナ（Pod）が⾜りない
    Observe
    Diff
    Act
    Observe: 現状を確認
    Diff: 理想と現実の差分を計算
    Act: 差分に対する処理を実施
    クラスタの状態
    理想の状態
    reconcile()
    {
    …
    }
    Controller
    例： ReplicaSet Controller の例
    

    View Slide

22. たとえば 2 つしかコンテナ（Pod）が起動していない場合…
    Act: 1つ nginx:1.16 のコンテナ（Pod）を作成する
    Observe
    Diff
    Act
    Observe: 現状を確認
    Diff: 理想と現実の差分を計算
    Act: 差分に対する処理を実施
    クラスタの状態
    理想の状態
    reconcile()
    {
    …
    }
    Controller
    例： ReplicaSet Controller の例
    

    View Slide

23. Reconciliation Loop のまとめ
    ⼈が考えること（運⽤ロジック）をプログラムに落とし込んで⾃動化する
    ＝ 運⽤を Kubernetes に任せることができる
    状態は Kubernetes に保存されているため、API 経由で確認可能
    外部システムを観測するものも状態を Kubernetes に保存
    運⽤者
    ReplicaSet の監視（watch）
    Pod の制御
    （create / delete / patch）
    via API
    運⽤のコード化
    ReplicaSet の設定を見ておき、
    指定されたレプリカ数で
    Podを維持する
    

    View Slide

24. Reconciliation Loop のまとめ
    ⼈が考えること（運⽤ロジック）をプログラムに落とし込んで⾃動化する
    ＝ 運⽤を Kubernetes に任せることができる
    状態は Kubernetes に保存されているため、API 経由で確認可能
    外部システムを観測するものも状態を Kubernetes に保存
    reconcile()
    {
    …
    }
    Controller
    ReplicaSet の監視（watch）
    Pod の制御
    （create / delete / patch）
    via API
    運⽤のコード化
    ReplicaSet の設定を見ておき、
    指定されたレプリカ数で
    Podを維持する
    

    View Slide

25. Kubernetes の構成要素
    Kubernetes では⾮常に沢⼭の Controller が動いている
    • ReplicaSet Controller
    • Deployment Controller
    • Ingress Controller
    • Node Controller
    • Scheduler
    • etc.
    これらの Controller が⾮同期に動作することで
    ⼀つの分散システムとして成り⽴っている
    reconcile()
    {
    …
    }
    Controller
    reconcile()
    {
    …
    }
    Controller
    reconcile()
    {
    …
    }
    Controller
    reconcile()
    {
    …
    }
    Controller
    reconcile()
    {
    …
    }
    Controller
    実際の状態
    理想の状態
    watch
    

    View Slide

26. reconcile()
    {
    …
    }
    Controller
    ReplicaSet の監視
    Pod の制御
    via API
    運⽤のコード化
    Kubernetes-native とは
    「スキーマの拡張機能」「宣⾔的 API の操作」を使いつつ、
    Reconciliation Loop を実現する「ロジック」を組み込み、物事を管理すること
    

    View Slide

27. Kubernetes-native とは
    reconcile()
    {
    …
    }
    Custom
    Controller
    独⾃リソースの監視
    Pod などの制御
    via API
    運⽤のコード化
    「スキーマの拡張機能」「宣⾔的 API の操作」を使いつつ、
    Reconciliation Loop を実現する「ロジック」を組み込み、物事を管理すること
    

    View Slide

28. Kubernetes-native ͳख๏ͷ 3 ύλʔϯ
    

    View Slide

29. Controller による運用の自動化パターン（2/3）
    １．ステートフルなミドルウェアを運⽤する Controller がつくられる
    Databaseなどの運⽤を任せられる時代に。
    Message Queue／KVS に関しては近いうちに現実的に
    （個⼈的にステートを持つ Computing リソースの延⻑に感じている）
    ステートフルなミドルウェアが進まない理由
    • Podのライフサイクルに適応できるものが少ない
    • 現状はクラスタ間のボリューム移⾏が得意ではない
    

    View Slide

30. Controller による運用の自動化パターン（1/3）
    ２．⼀般的な運⽤⾃動化ロジック
    • 社内に伝わる秘伝の闇の運⽤スクリプトを駆逐
    • Kubernetes-way な統⼀化された⽅法
    • Reconciliation モデルにより「運⽤」のロジック化に適している
    • 汎化した形で実装し、オープンソースのエコシステムとして共有
    例）
    コンテナのリソースの使⽤率から⾃動的に割当を変える︓{Virtical|Horizontal}PodAutoscaler
    払い出されたロードバランサの IP アドレスを DNS に登録する︓ExternalDNS
    Issuer から証明書を発⾏して Secret として登録する︓Cert Manager
    リポジトリのマニフェストを Kubernetes に apply する︓ArgoCD
    

    View Slide

31. VerticalPodAutoscaler / HorizontalPodAutoscaler
    コンテナに割り当てるレプリカ数やリソース量の管理は運⽤者の仕事
    何のメトリクスを使うか、最⼩/最⼤の値など運⽤者に対する指⽰にあたるところは制御可能
    運⽤者
    監視システム
    定期的に監視システムの値を取得
    推奨値を計算
    設定の変更
    

    View Slide

32. VerticalPodAutoscaler / HorizontalPodAutoscaler
    コンテナに割り当てるレプリカ数やリソース量の管理は運⽤者の仕事
    何のメトリクスを使うか、最⼩/最⼤の値など運⽤者に対する指⽰にあたるところは制御可能
    監視システム
    定期的に監視システムの値を取得
    推奨値を計算
    設定の変更
    VPA / HPA
    Controller
    

    View Slide

33. ExternalDNS – 払い出された IP アドレスを DNS へ
    ロードバランサーを⾃動的に払い出す機能は Kubernetes や IaaS に存在する
    払い出された IP アドレスを DNS に登録するのは運⽤者の仕事
    LB
    203.0.113.1
    DNS
    運⽤者
    203.0.113.1
    ＝
    svc.example.com
    

    View Slide

34. ExternalDNS – 払い出された IP アドレスを DNS へ
    ロードバランサーを⾃動的に払い出す機能は Kubernetes や IaaS に存在する
    払い出された IP アドレスを DNS に登録するのは運⽤者の仕事
    LB
    203.0.113.1
    DNS
    運⽤者
    1. 払い出された IP アドレスの確認
    2. 登録するドメイン名の確認
    3. 外部の DNS に対して登録処理を⾏う
    203.0.113.1
    ＝
    svc.example.com
    

    View Slide

35. ExternalDNS – 払い出された IP アドレスを DNS へ
    ロードバランサーを⾃動的に払い出す機能は Kubernetes や IaaS に存在する
    払い出された IP アドレスを DNS に登録するのは運⽤者の仕事
    払い出された IP アドレスや登録するドメイン名などは
    Kubernetes が保持している
    LB
    203.0.113.1
    DNS
    Controller
    1. 払い出された IP アドレスの確認
    2. 登録するドメイン名の確認
    3. 外部の DNS に対して登録処理を⾏う
    ExternalDNS
    Controller
    203.0.113.1
    ＝
    svc.example.com
    

    View Slide

36. Cert-manager
    HTTPS で利⽤する証明書を取得するのは、運⽤者の仕事
    IP Address を DNS に登録することに⽐べると、より複雑な処理が多い
    LB
    svc.example.com
    =
    203.0.113.1
    Let’s Encrypt
    ドメイン名の確認
    証明書リクエストの作成
    ACME HTTP or DNS Challenge の実施
    証明書ファイルの作成
    DNS
    運⽤者
    

    View Slide

37. Cert-manager
    HTTPS で利⽤する証明書を取得するのは、運⽤者の仕事
    IP Address を DNS に登録することに⽐べると、より複雑な処理が多い
    LB
    svc.example.com
    =
    203.0.113.1
    Let’s Encrypt
    Controller
    ドメイン名の確認
    証明書リクエストの作成
    ACME HTTP or DNS Challenge の実施
    証明書ファイルの作成
    Cert-manager
    Controller
    DNS
    

    View Slide

38. ArgoCD / ArgoRollouts
    Git リポジトリに保存された定義情報をもとに Kubernetes にアプリケーションを継続的デリバリ
    カナリアリリース、ブルーグリーンデプロイ、Progressive Delivery など
    複雑なロールアウト処理は運⽤者によって実現
    Git
    Repository
    運⽤者
    

    View Slide

39. ArgoCD / ArgoRollouts
    Git リポジトリに保存された定義情報をもとに Kubernetes にアプリケーションを継続的デリバリ
    カナリアリリース、ブルーグリーンデプロイ、Progressive Delivery など
    複雑なロールアウト処理は運⽤者によって実現
    Controller
    Argo*
    Controller
    Git
    Repository
    

    View Slide

40. 定期的に実行しているだけではない
    ⼀定期間経過したら処理を再実⾏しているわけではなく、
    変更を検知して効率的に処理を実⾏するようになっている
    例えば、
    • ロードバランサーの IP アドレスを変更した場合
    • 証明書ファイルが誤って削除された場合
    • レプリカ数が誰かによって書き換えられた場合
    全てが Kubernetes（etcd）上にデータとして保存されており、
    変更を検知するための仕組みも⽤意されている
    

    View Slide

41. Controller による運用の自動化パターン（3/3）
    ３．外部システムを制御・運⽤するための仕組み
    • Reconcile を踏襲した管理
    • Config Connector︓ GCP リソースの制御
    • AWS Controller︓ AWS リソースの制御
    • Cluster API︓ Kubernetes クラスタ⾃体を管理
    KVS
    DB
    Computing
    Computing
    KVS (meta)
    DB (meta)
    定期的な運⽤
    

    View Slide

42. Kubernetes-native とは
    reconcile()
    {
    …
    }
    Custom
    Controller
    独⾃リソースの監視
    Pod などの制御
    via API
    運⽤のコード化
    「スキーマの拡張機能」「宣⾔的 API の操作」を使いつつ、
    Reconciliation Loop を実現する「ロジック」を組み込み、物事を管理すること
    

    View Slide

43. Kubernetes-native ͳख๏ͷ
    ϝϦοτɾσϝϦοτ
    

    View Slide

44. 大規模化による人材の不足
    IT 化の推進、サービスやインフラが⼤規模化するに従って従来の運⽤では⼈が不⾜する
    • ⾃動化を⾏い、運⽤コストを低減する
    CNCF の提唱する Cloud Native では技術の⺠主化が⾏われている。
    • ビジネス以外のところは競争⼒を⽣みづらいので OSS で協⼒し合う
    • 各社で作っていた運⽤のための仕組みが汎⽤化されて OSS に
    • Kubernetes-native なエコシステムの広がり
    Kubernetes-native は解決策の1つとして有効
    ただし、運⽤を⾃動化して確実に運⽤コストが減るとも限らない
    

    View Slide

45. Cloud Nativeとは？
    クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの
    近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能
    力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービ
    ス、イミュータブルインフラストラクチャ、および宣言型APIがあります。
    これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅
    牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測ど
    おりに行うことができます。
    Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育
    成・維持して、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化
    し、これらのイノベーションを誰もが利用できるようにします。
    CNCF Cloud Native Defenition v1.0, CNCF, 2018-11-28
    (https://github.com/cncf/toc/blob/master/DEFINITION.md)
    

    View Slide

46. 大規模化による人材の不足
    IT 化の推進、サービスやインフラが⼤規模化するに従って従来の運⽤では⼈が不⾜する
    • ⾃動化を⾏い、運⽤コストを低減する
    CNCF の提唱する Cloud Native では技術の⺠主化が⾏われている。
    • ビジネス以外のところは競争⼒を⽣みづらいので OSS で協⼒し合う
    • 各社で作っていた運⽤のための仕組みが汎⽤化されて OSS に
    • Kubernetes-native なエコシステムの広がり
    Kubernetes-native は解決策の1つとして有効
    ただし、運⽤を⾃動化して確実に運⽤コストが減るとも限らない
    

    View Slide

47. Kubernetes-native な手法の注意点
    1. Controller の進化に追従する
    • Controller も常に進化していくため、塩漬けはせずに更新する
    • プラットフォームも開発者によりよいものを提供するために改善しつづける
    • OSS はものによっては開発が停⽌し、アーカイブされる
    • 成熟度、コミュニティの伸びを⾒極める
    • Upstream への貢献を視野に⼊れる
    • 将来的なリプレースの可能性を視野に⼊れる
    

    View Slide

48. Kubernetes-native な手法の注意点
    2. Controller の独⾃実装は覚悟を持って⾏う
    • Controller のロジックは全員が容易に理解できるとは限らない
    • 実装者が考える運⽤ロジックがコード化されている
    • ⾼頻度で⾏わない運⽤フローまで⾼度な⾃動化は⾏う必要はないため、コストを考える
    • その運⽤について⼗分な知識や経験がない場合は避ける
    • 上位互換性が保てないアプリケーションについての⾃動化は避ける
    Stop Writing Operators - Joe Thompson, HashiCorp, https://sched.co/ekAR, KubeCon + CloudNativeCon NA 2020, 2020-11-18
    

    View Slide

49. CloudNative ʹ޲͚ͯ
    

    View Slide

50. 大事なことは Cloud Native を目指し、選択すること
    ⼤事なのは実現したいこと
    実現したいことを技術的⽅法で体系化したものが CloudNative という考え⽅
    Kubernetes は Cloud Native を実現するためのプラットフォームとして利⽤可能
    盲⽬的に Kubernetes を選択するのではなく、実現したいことと合致しているかを⾒極める
    アプリのアーキテクチャや技術スタックだけクラウドネイティブになっていても
    効果は半減するため、合わせてビジネスや組織体制を Cloud Native に
    

    View Slide

51. Thank you for your attention
    Twitter: @amsy810
    

    View Slide

52. View Slide