Kubernetesとカスタムコントローラーを活用したプラットフォーム開発・運用の勘所 / Platform Engineering and Kubernetes

Copyright (C) 2020 Yahoo Japan Corporation. All Rights Reserved.
©︎2023 Yahoo Japan Corporation All rights reserved.
Kubernetesとカスタムコントローラーを
活用したプラットフォーム開発・運用の勘所
ヤフー株式会社テクノロジーグループシステム統括本部クラウドプラットフォーム本部
第12代黒帯〜クラウドスタック〜
早川博 @hhiroshell

View Slide

自己紹介
• ヤフー株式会社（2020年2月〜）
• プライベートクラウド開発チーム
• 第12代黒帯〜クラウドスタック〜
• 書籍執筆 & レビュー、各所での
登壇発表などしてます
• 分割キーボードはいいぞ
早川博 / @hhiroshell
DIYキーボードたち。
↑Cornelius
→ Corne
← BMEK

View Slide

目次
1. いまPlatform Engineeringがアツい
2. Platform Engineeringの重要パーツとしてのKubernetes
3. ヤフーでの活用事例
4. Kubernetesを使ってプラットフォーム開発を始めよう

View Slide

ITシステム開発の歴史
• リリースの高頻度化と円滑な改善サイクルの確立を目指して進化
モノリシックシステム
継続的デリバリー (2012〜)
デプロイメント・パイプラインによる迅速かつ
高頻度なリリースとフィードバック
Microservices (2014〜)
システムを疎結合な小規模アプリ群で
構成しアップデートを容易に
クラウドインフラとIaC
インフラ管理にソフトウェア・エンジニアリング
のプラクティスを導入し、調達の迅速化
と変更容易性を実現
DevOps (2009〜)
開発者と運用者の協力体制とそれを
支えるツール群
※ 時系列の順序には諸説あります

View Slide

ITシステム開発の歴史
• アプリケーション開発者(Dev)は幸せになったのか…？
• 高頻度のリリースとそれに耐える品質を実現するプラクティスにより、心理
的安心感を持って開発に当たれるようになった
• 高機能かつUXに優れ、スケーラブルで安定的に稼働するシステムが実現でき
るようになり、結果として開発者の評価に…(※)
※ 個人の見解を含みます

View Slide

近年のアプリケーション開発者が抱えている課題
• 開発者の責任範囲や習得すべきスキル/ツールが増加している
モノリシックシステム
継続的デリバリー (2012〜)
デプロイメント・パイプラインによる迅速かつ
高頻度なリリースとフィードバック
Microservices (2014〜)
システムを疎結合な小規模アプリ群で
構成しアップデートを容易に
クラウドインフラとIaC
インフラ管理にソフトウェア・エンジニアリング
のプラクティスを導入し、調達の迅速化
と変更容易性を実現
DevOps (2009〜)
開発者と運用者の協力体制とそれを
支えるツール群
※ 時系列の順序には諸説あります

View Slide

近年のアプリケーション開発者が抱えている課題
• 責任範囲の拡大と、大量のスキル/ツールの習得に悩まされている
• 運用、監視へのコミットと、マイクロサービス化
による運用、監視の複雑化
• デプロイメント・パイプラインの構築とメンテナンス
• 組織によってはクラウド周りの面倒を見たり
• 開発に集中できず効率が悪い
• スーパーマン以外は活躍しにくい / スーパーマンの頑張りに依存す
るようになり時間を奪ってしまう

View Slide

Platform Engineering
• 開発者の効率性と開発体験を高める
方法として、”Platform Engineering”
が期待されるように
• 2022年のGartner Hype Cycleに登場
• Innovation Trigger（黎明期）フェーズ
※ Cloud-Nativeは
Slope of Enlightenment（啓発機）フェーズ
ここ
https://twitter.com/TheMarkONeill/status/1557531379746881536

View Slide

依存コンポー
ネントの設定
Platform Engineeringとは？
• 自社の開発者たちが開発に集中できるようにするための基盤
(IDP: Internal Developer Platform)を提供する取り組み
1. システム開発で発生する基本的な作業を、セルフサービスで、
少ない労力で（舗装された道路を進むように）実施できる
2. 専任チームが “プロダクト” として提供する
• 明確なミッションを持って、顧客（開発者）のリアルな課題を解決する
実行環境
の準備
ビルドと
デプロイ
権限設定
監視系の
セットアップ

View Slide

Platform Engineeringとは？
• 具体的には例えばどういうこと？
• 開発者が必要とする開発、実行環境を、セルフサービスで簡単に入手できる
• 実行環境にデプロイしたら自動的に運用ポリシーが適用されるようにする
• アプリケーションのビルドと同時に一定品質以上のチューニング設定をおこ
なうツールが利用できる
• IDPを使うためのドキュメント群が整備されている
• 専任チームによるサポートを受けられる
• ...etc
※ あくまで一例です。実際には組織ごとの具体的な課題に当てはまる取り組みが必要です

View Slide

パブリッククラウドとの違い
• パブリッククラウドだけでは組織固有の課題や要件に応えるのは難
しい
• 例えば、組織固有のポリシーに準拠した権限をデフォルトで従業員に設定し
たくても、始めからそれが用意されているわけではない
• 権限を自動設定する機能が提供されることはありうるが、それを使って自組
織に適用するのはユーザーの責任
パブリッククラウド
の機能群
IDP
プラットフォーム
チーム
開発者
使用
提供
使用

View Slide

CloudNativeとPlatform Engineering
• CloudNativeなテクノロジー群はIDPを実現するためのパーツとして
重要な役割を担う
• Kubernetesを中心とした様々なミドルウェアと強固なOSSエコシステム
https://landscape.cncf.io/card-mode?project=graduated
CNCF Graduated Projects

View Slide

CloudNativeとPlatform Engineering
• とりわけKubernetesは、組織固有の要件を実装するためのベースと
して活躍
1. 様々なワークロードを安定的に動かすための基本機能
• セルフヒーリング、ローリングアップデート、スケーラビリティ...
2. 使いやすく整備された拡張ポイント
• カスタムコントローラー、Admission Webhook...
3. API Servicerを中心とした一貫性のある使用感
• kubectlでKRM(Kubernetes Resource Model)リソースを操作する、という一貫した
体験

View Slide

目次

View Slide

Kubernetesの拡張ポイント
• Kubernetesには、機能拡張されること想定して多数の拡張ポイント
が設けられている
• カスタムコントローラー
• Aggregation Layer
• Admission / Mutating Webhook
• Authentication / Authorization Webhook
• Scheduler
• Device Plugin
• Network Plugin

View Slide

本セッションで話すこと
• Kubernetesには、機能拡張されること想定して多数の拡張ポイント
が設けられている
• Aggregation Layer
• Admission / Mutating Webhook
• Authentication / Authorization Webhook
• Scheduler
• Device Plugin
• Network Plugin
これについて話します

View Slide

Kubernetesのコントローラーパターン
• Deploymentを適用するといい感じにPod（とコンテナ）が起動する
API
Server
Worker Node
Pod
Worker Node
Pod
> kubectl apply
Deployment

View Slide

• コントローラー群がそれぞれ仕事を果たした結果Podが起動する
API
Server
Worker Node
Worker Node
{ } Deployment
etcd
> kubectl apply
Deployment

View Slide

API
Server
Worker Node
Worker Node
{ } Deployment
{ } ReplicaSet
Controller Manager
Deployment
Controller
etcd
> kubectl apply
Deployment

View Slide

API
Server
Worker Node
Worker Node
{ } Deployment
{ } ReplicaSet
{ } Pod
Controller Manager
Deployment
Controller
ReplicaSet
Controller
etcd
> kubectl apply
Deployment

View Slide

API
Server
Worker Node
Worker Node
{ } Deployment
{ } ReplicaSet
{ } Pod
Controller Manager
Deployment
Controller
ReplicaSet
Controller
kube-
scheduler
etcd
> kubectl apply
Deployment

View Slide

API
Server
Worker Node
k
kubelet
Pod
create / edit
Worker Node
k
kubelet
Pod
create / edit
{ } Deployment
{ } ReplicaSet
{ } Pod
Controller Manager
Deployment
Controller
ReplicaSet
Controller
kube-
scheduler
watch
etcd
> kubectl apply
Deployment

View Slide

Reconciliation Loopの基本
1. 指定された「望ましい状態(Desired State)」を取得する
2. 「実際の状態(Actual State)」を観測する
3. 「実際の状態」を「望ましい状態」に一致するように変更する
4. 1〜3 を繰り返す
Controller
read
read & write
Desired
State
External World
(Actual State)
(1) (2), (3)
(4)
Modifies

View Slide

KubernetesにおけるReconciliation Loop
• 「望ましい状態」をKubernetesリソースとして記述し、API Serverで
管理する
• API Serverに保存したり、CRUD操作を行ったりする
• 「実際の状態」は何でもよい。例えば:
• 所定の内容のKubernetesリソースがAPI Serverにあること
• 所定の状態でPodが起動していること
• 外部システムに所定の設定が行われていること

View Slide

Reconciliation Loopに着目したKubernetesのアーキテクチャ
Deployment Controller
read
read & write
Modifies
API
Server
etcd
ReplicaSet Controller
kube scheduler
kubelet
kubelet
kubelet
{ } Deployment
{ } ReplicaSet
{ } Pod
Pod

View Slide

カスタムコントローラーによるKubernetesの拡張
• カスタムコントローラー:
• Reconciliation Loopを新たに実装することで、元々備わっていない機能を
Kubernetesに追加するもの
• CRD (Custom Resource Definition) とカスタムコントローラーによって実現
Hoge Controller
Modifies
API
Server
etcd
Fuga Controller
{ } Hoge
{ } Fuga
External World
(Actual State)

View Slide

Hoge Controller
Modifies
API
Server
etcd
Fuga Controller
{ } Hoge
{ } Fuga
External World
(Actual State)
• CRD (Custom Resource Definition):
• カスタムリソースのフォーマットを定義するKubernetesリソース
• CRDをKubernetesに適用すると、カスタムリソースをAPI Serverで管理できるよ
うになる
独自フォーマットの
manifestを操作できるようになる

View Slide

Hoge Controller
Modifies
API
Server
etcd
Fuga Controller
{ } Hoge
{ } Fuga
External World
(Actual State)
• 新たに実装したコントローラー
• Go言語でcontroller-runtimeというフレームワークを使って実装するのが基本
• 多くの場合Kubernetesクラスター内にデプロイして動かす
新たに実装した
コントローラー

View Slide

目次

View Slide

本セクションで話すこと
• ヤフーではカスタムコントローラーを活用して、弊社固有の要件に
応えたり、高い開発者体験を実現するプラットフォームを構築して
います
• このセクションではその一部を紹介します

View Slide

ヤフーでの実践例 – Kubernetesベースのアプリケーション実行環境
• セルフサービスで利用開始
• 開発者がGUIでNamespaceを作成すると、アクセス権が自動設定され安全に利
用可能になる
• 少ない手間でWebアプリケーションを実行
• アプリをデプロイするとURLが自動的に払い出され、すぐにアクセス可能に
なる
• アプリにクライアント証明書が自動注入され、Secret管理の必要なく他シス
テムにアクセスできる
• マルチテナント & スケーラブル
• ヤフーの多数のサービスを少数のクラスターで実行
他にも色々ありますが
一部ご紹介します > <

View Slide

ヤフーでの実践例 - Kubernetesベースのアプリケーション実行環境
• セルフサービスのNamespace払い出しと権限設定
• GUIからNamespaceを作成
• 自分が属さないプロジェクトのNamespaceに対しては操作できない
# 関係ないNamespaceに対する操作（CLIのコンテキストは設定しておく）
$ sapctl –n another-project get app
Error from server (Forbidden): apps.fleet.zlab.co.jp is forbidden: User ”hhiros...
Super Awesome Private Cloud Console my-project
Namespace新規作成
Namespace名:

View Slide

• アプリのデプロイからアクセスまで
• 簡単なコマンドまたはカスタムリソースからアプリをデプロイ
• アプリが起動すると自動的にURLが払い出され、すぐにアクセス可能
$ sapctl create app hello-world
--image=example-registry/sample/helloworld-go:latest
--port=8080
$ sapctl get app hello-world
NAME ENDPOINT READY REASON AGE
hello-world https://hello-world.sandbox.app.dev.yahoo.co.jp True 6m4s
$ curl https://hello-world.sandbox.app.dev.yahoo.co.jp
Hello World!

View Slide

• カスタムコントローラーによる自動権限設定の仕組み
Namespace
API
CI
API
Server
Git
{ } Namespace
etcd
Kubernetesクラスター
Namespace
Namespace
作成操作
Namespaceをクラスターに作成
開発者

View Slide

権限管理システム (Athenz)
Namespace
API
CI
API
Server
Git
{ } Namespace
{ } AthenzPolicyClaim
Athenz Policy Operator
ns-controller
policy-controller
etcd
Athenz Policy
Namespace
Namespace
作成操作
開発者
権限情報の登録

View Slide

権限管理システム (Athenz)
Namespace
API
CI
API
Server
Git
{ } Namespace
ns-controller
policy-controller
etcd
Athenz Policy
Namespace
Namespace
作成操作
Namespace内の
リソースに対する操作
開発者
権限情報の登録
権限のチェック

View Slide

• アプリケーションデプロイ時のエンドポイント自動設定の仕組み
{ } App
etcd
API
Server
アプリを
デプロイ
開発者
App

View Slide

App
DNS Server
{ } App
{ } AppBinding
app operator
app-controller
ab-controller
etcd
{ } DNSRegistrationRequest drr-controller
API
Server
アプリを
デプロイ
DNSレコードの登録
開発者

View Slide

App
DNS Server
{ } App
{ } AppBinding
app operator
app-controller
ab-controller
etcd
Ingress
Controller
{ } DNSRegistrationRequest
Pod
Pod
Pod
drr-controller
API
Server
アプリを
デプロイ
DNSレコードの登録
開発者
アプリのユーザー
名前解決
リクエスト

View Slide

その他の取り組み
• マルチテナント & スケーラビリティ
• 複数のKubernetesクラスターを組み合わせた、超大規模なアプリ実行基盤の
実現
• 複数のKubernetesクラスターを束ねるメタクラスターを設け、メタクラス
ターにアプリの起動を指示すると、適切なクラスター上でアプリが立ち上が
る仕組み
アプリをデプロイ
適切なクラスター
でアプリを起動
アプリにアクセス
開発者エンドユーザー
App

View Slide

その他の取り組み
• アプリケーション・アイデンティティの自動設定
• アプリケーションを一意に識別可能なクライアント証明書をPodに自動注入
し、さらにAthenz上にそれに対応するアプリケーションアカウントを作成
• KubernetesのSecretを使わずに外部システムへの認証情報が自動設定される
※ https://github.com/AthenZ/athenz/blob/master/docs/copper_argos.md
API
Server
Pod
ZZZ
システム
証明書の注入
アプリケーション
アカウントを登録
クライアント証明書と共に外部システムにリクエスト
認証・認可
✓ XXXクラスターのYYYアプリ
のアクセスを許可
アプリへのアクセス権を設定
ZZZシステム
管理者
開発者
アプリを
デプロイ
App

View Slide

目次

View Slide

このセクションで話すこと
• ここではカスタムコントローラー開発をおこなう際の、設計の考え
方やプロジェクトの進め方について話します
• 実装作業の観点ではcontroller-runtimeと呼ばれるフレームワークが
デファクトになっていて、これを使いこなす必要があります。これ
についてはすでに良質な資料があるのでそちらを参考にしてくださ
い（本スライドの最後に参考文献を掲載してあります）

View Slide

カスタムコントローラー開発の進め方
• カスタムコントローラー開発の全体の流れ
コントローラーと
カスタムリソースの
構成を決める
仕様を決める
コントローラー毎に
詳しい挙動を決める
設計
の実装・テスト
リリース
コントローラーをひとつずつ
実装・テスト・リリースしていく
設計へのフィードバック

View Slide

カスタムコントローラーの設計の進め方
• コントローラーとカスタムリソースの構成を決める
• 作りたい機能を実現できるようにコントローラーとカスタムリソースを作る
単位を決めていく
• 下のような図を書きながら試行錯誤
{ } Namespace
ns-controller
policy-controller
etcd
• ひとつのコントローラーに機能を詰め込みすぎないように注意
External World
(Actual State)

View Slide

• カスタムリソースの仕様を決める
• 実際にmanifest（yamlファイル）を書きながらフィールド構成を考えていく
• specとstatusがある。statusはコントローラーからリソースに対するActual
Stateの状態などを記録するのに利用できる
$ kubectl get athenzpolicyclaim
NAMESPACE NAME SYNCHRONIZED
my-project-test my-project-test-claim True
• kubectl get したときに表示する項目もいい感じにしておくと運用時に便利
kind: AthenzPolicyClaim
spec:
policySetVersion: user-namespace-template-1_1_0
status:
synchronized: True

View Slide

• コントローラー毎に詳しい挙動を整理する
• ns-controllerの動作
イベントコントローラーの動作
Namespaceリソースが新規作成された子のAthenzPolicyClaimリソースを作成するxxxフィールド、yyy
フィールドの値は…
Namespaceリソースのxxxが変更された子のAthnezPolicyClaimのxxxをNamespaceに合わせて変更する
Namespaceリソースが削除された子のAthenzPolicyClaimを削除する
AthenzPolicyClaimリソースが削除された AthenzPolicyClaimリソースを再作成する
AthenzPolicyClaimリソースが変更された親のNamespaceリソースの内容に合わせてAthenzPolicyClaimリ
ソースを元に戻す
• policy-controllerの動作
イベントコントローラーの動作
... ...

View Slide

• コントローラーの挙動を決めるときのコツ
• Actual Stateに変更があったときの動作も忘れない
• 各表（前ページ）が大きくなり過ぎるようなら、コントローラーの役割が多すぎ
ないか見直す
• 前ページの各表はそのままテストケースにもなる
{ } Namespace
ns-controller
policy-controller
etcd
External World
(Actual State)
ここが変更されたら
policy-controllerがもとに戻す

View Slide

コントローラーの実装
• 1つのバイナリに複数のコントローラーが含まれることがほとんど
• コントローラーを1つずつ実装していく
• それぞれのコントローラーは互いに独立したReconciliation Loopを担当するの
で、別々に実装を進められる
• Athenz Policy Operatorの例では、policy-controllerができ上がった時点で、権限
情報をmanifestで管理できるようになる
policy-controller
etcd
External World
(Actual State)
権限の管理をmanifestで
できるようになった！
カスタムリソースを
直接適用
API
Server

View Slide

コントローラー単位で開発を進めるメリット
• コントローラー単位で開発すると、小さな独立した単位で漸進的に
開発を進めていける
• 意味のある小さな単位でリリースして、早めにフィードバックを得られる
• 複数チームで分担できる
• スクラムチームの動き方にうまくはまる
※ MVP - not “bike to car” (https://www.linkedin.com/pulse/mvp-bike-car-fred-voorhorst/)

View Slide

ここまでのまとめ
• カスタムコントローラー開発の全体の流れ
コントローラーと
構成を決める
仕様を決める
コントローラー毎に
詳しい挙動を決める
設計
の実装・テスト
リリース
コントローラーをひとつずつ
実装・テスト・リリースしていく
設計へのフィードバック

View Slide

おわりに
• 開発者の生産性と開発体験を高めるための “Platform Engineering” が
注目されている
• KubernetesはInternal Developer Platform構築のための重要パーツ
• Kubernetesをカスタムコントローラーで拡張することで、高度な要
件を実現するIDPが構築できる
• カスタムコントローラー開発やっていきましょう！

View Slide

宣伝
• サイバーエージェントさん主催のイベントにて、本日紹介したアプ
リケーション実行基盤についての発表があります。今日よりもっと
詳しい話が気になる方は、ぜひご参加ください！
「CA.infra #1 - Kubernetes as a Service」
・ 2023/03/02(木) 19:00〜オンライン開催
・ https://cyberagent.connpass.com/event/272843/

View Slide


View Slide

参考文献 – Platform Engineeringについて
• What is platform engineering? (Platform Engineering Org)
• https://platformengineering.org/blog/what-is-platform-engineering
• What Is Platform Engineering? (Gartner)
• https://www.gartner.com/en/articles/what-is-platform-engineering
• From Kubernetes to PaaS to … Err, What’s Next? - Daniel Bryant, Ambassador Labs
• https://www.youtube.com/watch?v=btUYeOa7JPI
• 役に立つプラットフォームを作ろう
– プラットフォームエンジニアが知っておくべき「プロダクト」の考え方
• https://speakerdeck.com/jacopen/yi-nili-tupuratutohuomuwozuo-rou-puratutohuomuenziniagazhi-
tuteokubeki-purodakuto-falsekao-efang
• 世界に誇れるプラットフォームチームをつくる
• https://speakerdeck.com/jacopen/shi-jie-nikua-rerupuratutohuomutimuwotukuru

View Slide

参考文献 – カスタムコントローラーの開発について
• The Kubebuilder Book
• https://book.kubebuilder.io/
• つくって学ぶKubebuilder
• https://zoetrope.github.io/kubebuilder-training/
• Kubernetesオペレータのアンチパターン & ベストプラクティス
• https://speakerdeck.com/zoetrope/kubernetesoperetafalseantipatan-
besutopurakuteisu

View Slide

Kubernetesとカスタムコントローラーを活用したプラットフォーム開発・運用の勘所 / Platform Engineering and Kubernetes

Kubernetesとカスタムコントローラーを活用したプラットフォーム開発・運用の勘所 / Platform Engineering and Kubernetes

hhiroshell

More Decks by hhiroshell

Other Decks in Technology

Featured

Transcript