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

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

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

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)

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

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

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

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

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

Kubernetesͱ͸ʁ

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

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

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

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

Kubernetes ͷ Reconciliation Loop

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

CloudNative ʹ޲͚ͯ

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

Thank you for your attention Twitter: @amsy810

No content