Operator reading and writing
Operator SDK 編
2020/1/17 #ふくばねてす node-3
@loftkun
About Me
@loftkun ( 甲斐 新悟 )
ヤフー株式会社 サービスプラットフォーム本部
2019年登壇数 : 10
ふくばねてす皆勤
#ふくばねてす node-1
#ふくばねてす node-2
#ふくばねてす virtual-kubelet-1
#ふくばねてす node-3
Motivation
• 前回、Prometheus Operatorの利用方法を含む話題をLTしました
• 今回はOperatorの実装面に着目してお話しします
Environment
CPU Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
6C/12T
RAM 64GB
OS Ubuntu 18.04.3 LTS
Go 1.13.5
Operator SDK v0.13.0
kubectl v1.17.0
minikube v1.6.2 ( Kubernetes version : v1.17.0 )
Agenda
Operator is 何?
Reading
Writing
Operator is 何?
その前に
予備知識
https://kubernetes.io/docs/concepts/overview/components/
リソース
情報
リソース
操作
Operator is 何?
built-in controller の 例
Repo Resource Controller ( pkg/controller/ )
kubernetes/kubernetes ReplicaSet replicaset/replica_set.go
DeamonSet daemon/daemon_controller.go
Deployment deployment/deployment_controller.go
HPA podautoscaler/horizontal.go
予備知識
1. 監視 ( watch )
resourceのイベント(Add/Update/Delete)をwatch
2. 調整 ( reconcile )
1. イベント毎の reconcile.Requests がトリガー
2. オブジェクトのSpec(あるべき状態)とシステムの状態が
一致するか確認
3. 一致しない場合、必要に応じた調整を行う
必要なオブジェクトをAdd/Update/Deleteする。
https://kubernetes.io/docs/concepts/overview/components/
宣言的設定に基づいた自己修復機能が実装されている
監視(watch)と調整(reconcile)を行うのがController
Operator is 何?
Operator is 何?
Operator = Custom Resource + Custom Controller
https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
• CR ( Custom Resource )
– Deploymentのような built-inなresourceではなく、独自に定義した resource
– CRD( Custom Resource Definition ) で定義できる
• Custom Controller
– CRを監視(watch)、調整(reconcile)し面倒を見るために、独自に実装したcontroller
– 基本的な作りはDeployment controllerのような built-inなcontrollerと同様
• watch や reconcile を行う
人間の手作業による運用(Operation)を自動化するのがOperator
Operator is 何?
built-in controller の例 ( 再掲 )
Repo Resource Controller ( pkg/controller/ )
kubernetes/kubernetes ReplicaSet replicaset/replica_set.go
DeamonSet daemon/daemon_controller.go
Deployment deployment/deployment_controller.go
HPA podautoscaler/horizontal.go
Repo Custom Resource Controller
operator-framework/operator-sdk-samples
Memcached Operator
Memcached controller/memcached/memcached_cont
roller.go
coreos/prometheus-operator Prometheus
Alertmanager , etc
prometheus/operator.go
oracle/mysql-operator Cluster
Backup
Restore , etc
pkg/controllers/
cluster_control.go
backup/operator_controller.go
restore/operator_controller.go
Operator の例
実装手段
• ライブラリを使う
– client-go , code-generator など
• built –in なコントローラーはこれらのライブラリで実装されている
• 他にはcoreos/prometheus-operatorなどもこの手段で実装されているようだ
• フレームワークを使う
– kubernetes-sigs/kubebuilder
– operator-framework/operator-sdk
• OLM ( Operator LifeCycle Manager )
• その他
– KUDO
– Metacontroller
Reading
読む箇所
Operator = Custom Resource + Custom Controller なので、
• CRD ( Custom Resource Definition ) を 読む
– spec
• reconcile loopで参照される情報
– specと現在のオブジェクトの状態を比較してreconcileする
– status
• reconcile loopで更新される情報
– 現在のオブジェクトの状態 ( kubeclt describe で確認できる )
• Reconcile の処理を読む
– Specと現在のシステムの状態の比較
– 必要に応じてオブジェクトの操作(Add/Update/Delete)
operator-framework/operator-sdk-samples
• Operator SDK で作成されたOperatorのサンプル (Memcached Go Operator)
CRD Reconcile
https://github.com/operator-framework/operator-sdk-samples
Writing
Install Operator SDK
https://github.com/operator-framework/operator-sdk/blob/master/doc/user/install-operator-sdk.md
operator-framework/getting-started
1. 新規プロジェクト作成
2. CRDを追加
3. コントローラーを追加
4. ビルド & 動作確認
https://github.com/operator-framework/getting-started
1. 新規プロジェクト作成
新規プロジェクトを生成する
https://github.com/operator-framework/getting-started
Operatorのソースコードのscaffold(足場)ができる
1. 新規プロジェクト作成
失敗
https://github.com/operator-framework/getting-started
1. 新規プロジェクト作成
GOROOTを設定するとうまくいった
https://github.com/operator-framework/getting-started
2. CRDを追加
CRDのscaffoldを追加する
https://github.com/operator-framework/getting-started
2. CRDを追加
CRDのscaffoldを編集する
https://github.com/operator-framework/getting-started
specを編集
・我々はkubectl createでCR生成時に値を指定
できる
・Operatorがreconcile の際に参照する
本チュートリアルではint型のsize(レプリカ数)を定義してい
る。
statusを編集
・Operatorが現在の状態を設定する
・我々はkubectl describeで確認できる
本チュートリアルではstringの配列としてpod名のリストを
定義している。
2. CRDを追加
*_types.goを編集した場合は、リソースのコードを再生成する
https://github.com/operator-framework/getting-started
2. CRDを追加
OpenAPI validations を生成する
https://github.com/operator-framework/getting-started
2. CRDを追加
生成されたCRDのyaml
https://github.com/operator-framework/getting-started
Memcachedというkindはbuilt-inな
resouceにはない
このCRDをクラスタに適用すると、
kind:Memcachedが使えるようになる
2. CRDを追加
生成されたCRDのyaml ( つづき 抜粋 )
https://github.com/operator-framework/getting-started
specのvalidation
statusのvalidation
3. Controllerを追加
Controllerのscaffoldを追加する
https://github.com/operator-framework/getting-started
3. Controllerを追加
追加されたソース
( pkg/controller/memcached/mem
cached_controller.go )
https://github.com/operator-framework/getting-started
CRをwatch
Podをwatch
このようにscaffoldとしてはPodをwatch
するコードが生成される。
Deploymentをwatchするよう改造する。
3. Controllerを追加
https://github.com/operator-framework/getting-started
追加されたソース
( pkg/controller/memcached/mem
cached_controller.go )
CRをwatch
Podをwatch
このようにscaffoldとしてはPodをwatch
するコードが生成される。
Deploymentをwatchするよう改造する。
3. Controllerを追加
追加されたソース
( pkg/controller/memcached/mem
cached_controller.go )
https://github.com/operator-framework/getting-started
( 続く )
Reconcile処理のscaffold
CRのオブジェクトを取得
3. Controllerを追加
追加されたソース
( pkg/controller/memcached/mem
cached_controller.go )
https://github.com/operator-framework/getting-started
Reconcile処理のscaffold
Podを生成する
このようにscaffoldは、Podを生成
するコードである。(imageは
busybox)
Deploymentを生成するようコード
に差し替える
3. Controllerを追加
https://github.com/operator-framework/getting-started
1 Deploymentを作成
m が カスタムリソースの参照情報で、
同じ名前、同じネームスペースに作
成している
Imageはmemcached-alpine
3. Controllerを追加
https://github.com/operator-framework/getting-started
1 Deploymentを作成
r.Clientはsigs.k8s.io/controller-runtime
3. Controllerを追加
https://github.com/operator-framework/getting-started
2 Deploymentを更新
以下が一致するか確認し、一致しない場合は更新する
– CRのspecで定義したsize
– Deploymentのsize(replica数)
3. Controllerを追加
https://github.com/operator-framework/getting-started
3 CRのstatus(describeで見れるやつ)を更新(pod名リストを書く)
3. Controllerを追加
https://github.com/operator-framework/getting-started
3 CRのstatus(describeで見れるやつ)を更新(pod名リストを書く)
StatusのNodesに
node名のリストを
書けている
4 build & 動作確認
CRDをAPI Serverに登録する
https://github.com/operator-framework/getting-started
( 略 )
4 build & 動作確認
コンテナイメージのbuild & push
https://github.com/operator-framework/getting-started
4 build & 動作確認
デプロイ
https://github.com/operator-framework/getting-started
4 build & 動作確認
デプロイ
https://github.com/operator-framework/getting-started
4 build & 動作確認
カスタムリソースを生成する
https://github.com/operator-framework/getting-started
4 build & 動作確認
確かにpodが3つ作成された
https://github.com/operator-framework/getting-started
Operatorのcustom controllerがwatchし、reconcileした結果
Deploymentのreplia数を3に更新している
4 build & 動作確認
カスタムリソースのsizeを4にしてみる
https://github.com/operator-framework/getting-started
4 build & 動作確認
確かにpodが4つになった
https://github.com/operator-framework/getting-started
Operatorのcustom controllerがwatchし、reconcileした結果
Deploymentのreplia数を3から4に更新している
Tips
Operatorをローカルで起動できる。開発&テストを素早く回せる
https://github.com/operator-framework/getting-started
この場合、Operatorはコンテナではなく、goのプロセスとしてローカルで起動する
K8sとの通信にはdefaultで $HOME/.kube/config が使われる
まとめ
• Operator = Custom Resource + Custom Controller
– 人間の手作業による運用(Operation)を自動化
• Reading
– CRD ( Custom Resource Definition ) を読む
–reconcile処理を読む
• Writing
– Operator SDK による実装手順を紹介しました
まとめ
• Operator = Custom Resource + Custom Controller
– 人間の手作業による運用(Operation)を自動化
• Reading
– CRD ( Custom Resource Definition ) を読む
–reconcile処理を読む
• Writing
– Operator SDK による実装手順を紹介しました
Operatorを完全に理解しました

Operator reading and writing ( Operator SDK 編 )

Editor's Notes

  • #2 00:00-00:20 よろしくお願いします
  • #3 00:20-00:40 ふくばねてす皆勤賞の方はいらっしゃいますか?? おめでとうございます、今後ともよろしくお願いいたします 初参加の方はどれくらいいらっしゃいますか? 今後も開催されるはず、ですので、ぜひ盛り上げていただければと思います
  • #4 0:40-01:00 今回のモチベーションです 前回、11月にふくばねてすの番外編がありまして、そこで〜〜〜 内容はQiitaのアドベントカレンダーにも書いていますので、 もしよろしければ読んでいただけたら幸いです。 ちなみに同じ内容を、クラウドネイティブデイズ関西2019の前夜祭でもやってきて、 少しだけふくばねてすの宣伝もしてきております,、全国区になる日も近いです - - - - - - - - - - - - - - - - - - CNDK2019 前夜祭タイムテーブル https://twitter.com/yucky_sun/status/1199628127829278720
  • #5 01:00-01:20 環境です おうち k8s です Minikube 使ってます最新版です 今日紹介する Operator SDK も入れてます、、、 なんとバージョンが 0.13.0、  発展途上感がはんぱないですね
  • #6 1:20-1:40 アジェンダです オペレーターってなんだろうのご紹介 ソースリーディング サンプルを実装してみた の3本です
  • #7 1:40-2:00 まず、Operatorについてご紹介したいと思います Operatorを完全に理解している方はいらっしゃいますか? 仕事でも趣味でも、使ったことある、という方? 詳しいことは今手を挙げた人に聞いてください では聞いたことあるよ、くらいの方? 参考になりましたら幸いです - - - - - - - - - - - - - - - - - - チョットワカル
  • #8 02:00 Operatorの紹介をする前に、ちょっとだけ
  • #9 02:00-02:40 これ説明できる方いらっしゃいますか?? これは公式ドキュメントから引っ張ってきたクーバネテスのコンポーネント構成です 予備知識として、リソースとコントローラーの話をしておきたいと思います。 左が マスターノード、右にワーカーノードがあります ・etcdはデータストアで、 ここにリソースの情報が永続化されます  リソースの操作はAPIを介して行います、etcdにはAPIだけがアクセスできます ・このAPIを介してリソースの操作を行うのがコントローラーになります <さらっと次のページへ> - - - - - - - - - - - - - - - - - コンポーネントの構成 左 マスターノード 右 ワーカーノード マスターノード etcd : リソース永続化のためのkvs。  apiserver : リソースの操作はapiserverを介して行う。唯一etcdにアクセスできる。 controller-manager : 実際の操作はコントローラーが行う scheduler : ノードにPodを割り当てる ワーカーノード  kubelet ( キューブレット ) : Podの管理 proxy : Serviceのルーティング
  • #10 02:40-3:00 K8sにあらかじめ組み込まれているリソースとコントローラーの例です 実装はkubernetesのリポジトリにあります 例として、レプリカセットとか、デーモンセットとか、 それぞれのリソースに対して面倒をみるコントローラーがあるという関係になります - - - - - - - - - - - - - - - - - -
  • #11 03:00-03:20 コントローラーは何しているかは、2つあります 1 〜〜〜 2 〜〜〜 Specは宣言的設定 この監視と調整っていうのは、まさにクーバネテスの 宣言的設定にもとづいて自己修復する機能の実装であると言えると思います。 - - - - - - - - - - - - もし付け加えるなら ・ResourceやKindなど ・代表的なbuilt-in コントローラーがある、対してカスタムコントローラーがある ・ソース https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-controller-manager/app/controllermanager.go
  • #12 03:20 では、Operatorの紹介に入っていきます
  • #13 03:20-04:00 今日はこの足し算だけ覚えていただけると良いかと思います。 〜〜〜 〜〜〜 〜〜〜★★★★ このようにリソースの変化を監視して、必要な調整を行うというのは、 人間の手作業による運用を実装して自動化するものであると、 それがOperatorです。
  • #14 04:00-04:20 built inのコントローラーを再掲してます、 Operatorは3つ挙げてます Memcached Operatorは、今回実装方法を紹介するOperator SDKで作成したサンプルです カスタムリソースとしてはMemcachedを扱います 他にはPrometheus Operatorや、MySQL Operatorなどがあります - - - - - - - - - - - - - - - - - -
  • #15 04:20-5:00 実装手段です ライブラリを使う。これが原始的な書き方です。 built-inなコントローラーとか、prometheus operatorとかはこのライブラリで実装されています このライブラリで書かれているオペレーターはOperator自身を構成するコンポーネントが細分化されていて、結構複雑です。 どこかで整理して発表できると良いなと思ってます。 フレームワーク Kubebuilder とか 今回紹介する Operatro SDKがあります。 今回Operator SDKを選んだ理由としては Operatorを管理できるOLMの機能が使えるようなのと、 RedHatさんの勉強会で発表があったのを見たのでこちらを選びました。 今日RedHatの小西さんもこられてますがこびを売っておこういと思います。 TODO KUDOとかの説明 これはあらかじめ汎用的なオペレーターが用意されていて、 それに具体的な設定投入して動かすコンセプトのようです ---------------- client-go : api叩くためのクライアント code-generator : コントローラはinforerなどからなるんですが、そのコードを生成するライブラリ apimachinery: Kubernetes API Object & Kubernetes API like Object 用 の機能を備えたライブラリ
  • #16 05:00 みなさん、オペーレーターについて完全に理解できたと思いますので、 ソースコードの方を見ていきたいと思います。
  • #17 05:00-5:40 読む箇所としては、 コントローラーが面倒を見るリソースの定義と、調整機能の実装を見ると良いと思います。 CRD 〜〜〜 Reconcile loop 〜〜〜 - - - - - - - - - - - - - - - - - - - - - - - - 他に挙げるならば ・メインプログラム ( cmd/manager/main.go ) pkg/apis/...配下の全CRを登録 pkg/controller/...配下の全contorllerを起動 ・何をwatchしているか CRや紐づくDeploymentなど
  • #18 05:40-6:00 具体的にはこんな感じです これはOperator SDKで作られたサンプルコントローラーです。 こちらがSDKで生成したCRDのyamlファイルで、こちらがReconcileのコード 今回はこのサンプルコントローラの実装手順も紹介しながら、 コードも見ていこうと思います。
  • #19 6:00 では実装手順を見ていきたいと思います。
  • #20 06:00-6:10 まずはOperatro-SDKをインストールします 基本的にはバイナリを取ってきて、所定の位置に置くだけです。 operator-sdk コマンドが使えるようになります。
  • #21 06:10-06:30 作成手順です getting-started というリポジトリがありますので、 それに従ってサンプルオペレーターを実装する手順を紹介しています。 大きく4つの手順があります。 〜〜〜〜 〜〜〜〜 〜〜〜〜 〜〜〜〜
  • #22 06:30-06:40 new コマンドで作成できます。 Operatorのソースコードのscaffold(足場)ができる このgetting-startedのチュートリアルでは、 Memcached( めむきゃっしゅど インメモリキャッシュ ) を運用するオペレーターの作成手順となっています。
  • #23 06:40-06:50 早速失敗しました もしかしたら同じエラーが出る環境の人もいるかもしれませんので共有します
  • #24 07:00-07:20 Issue検索してみましたら 環境変数のGOROOTを設定するとよいのではというコメントがあったので、 やってみるとうまくいきました、このへんgoに強い人いらっしゃいましたら教えてください
  • #25 07:20-07:40 つづいて CRDの作成 add api で作成できます。 なんで add api かというと、CRDを作るのは クーバネテスのAPIを拡張して、エンドポイントを 生やすこと相当することからきているのかなと思います。
  • #26 07:40-08:20 こういう感じで空のstructがscaffoldとして生成されますので、 リソースの定義を追記していくという形になります。 specを編集〜〜〜 statusを編集〜〜〜 こういう感じで、これはSCAFFOLDです、編集してくださいのような、コメントで説明があるので参考になります。 ****このファイルを編集したら、この定義に基づいて必要なコードを再生成するために operator-sdkコマンドを叩く必要がある、もわかります**** コメントも参考になります
  • #27 08:20-08:40 ということで generate k8s というコマンドでリソースのコードを再生成しておきます
  • #28 08:40-08:50 CRDにはバリデーションの条件を定義できます、 Generaet open apiコマンドで追加できます こんな感じでdeprecatedと言われましたがとりあえず通りました。
  • #29 08:50-09:00 生成されたCRDのymalです。 Memcachedというkindは、クーバネテスにはないんですが、 この定義をクラスタに適用すると使えるようになります。 細かいところでは、このリソースを単数形と複数形ではこのように指定する、 みたいな定義も生成されています。
  • #30 09:00-09:20 あとは先ほど生成したバリデーションの条件ですね Spec のvalidation size ( レプリカ数 ) は int 型 数値です とか、 Status の validation nodes ( pod名のリスト ) stringの配列ですとか、が設定できています。
  • #31 09:20-09:30 つづいて、コントローラを作成します。 add controller コマンドでscaffoldが生成されます
  • #32 09:30-09:50 これは生成されたままの状態のscaffoldの、監視(watch)の処理の部分です 先ほど生成したカスタムリソースと、あとはPodのwatchのコードが自動で生成されます。 このscaffoldのまま使うと、memcachedのPodを1つ作るコントローラーになります。 これを改造してして、先ほど定義したspecのsizeの値でレプリカ数を調整したいので、 めんどを見たいのはDeploymentになります( 次ページ )
  • #33 09:50-10:00 ので、Deploymentを監視できように、このコードに差し替えます。
  • #34 10:00-10:10 続いて、reconcile処理も見ていきたいともいます。 Reconcileは、監視しているリソースが変化した際のイベントがトリガになってて呼び出されます。 このコードはカスタムリソースのオブジェクトへの参照を取得して、
  • #35 10:10-10:20 そのnamespaceなどの情報を参照して、Podを1つ作ります。 このようにreconcile処理も、ScaffoldとしてはPodを生成するコードが生成されますので、 今回面倒をみたい、Deploymentの生成コードに書き換えます。
  • #36 10:20-10:30 こちらが、Deplyment生成コードです。 m が イベントのトリガとなっているカスタムリソースの情報で、 それと同じネームスペースに作成してます。 Imageはmemcahedのアルパインを指定しています。
  • #37 10:30-10:40 生成処理は、client.Createで行なっています。 Clientはさきほどかたやまさんの発表にありましたシグのcontroller-runtime パッケージのもので、 apiサーバをたたくclientです
  • #38 10:40-11:00 Deploymentの更新処理です カスタムリソースのスペック ( size ) を見て、 現在のDeploymentのレプリカ数を見て、 一致していなければ、Deploymentのレプリカ数を更新します。
  • #39 11:00-11:10 また、カスタムリソースのStatusという項目に、 現在のMemcachedのpod名のリソースを書いておきます。
  • #40 11:10-11:30 コントローラーが書いたStatusは、 こんな感じで、kubeclt describe カスタムリソース で 確認することができます。 このように、Memcachedのpod名が見えています。
  • #41 11:30-11:50 動作確認です。 まず、CRDのyamlをクラスターに登録しておきます。 登録するとMemchachedというリソースを生成できるようになります。 この登録もOperatorにさせることができるのですが、 このチュートリアルでは手作業になっています。
  • #42 11:50-12:00 それからBuildコマンドで、オペレータのイメージをビルドしてレジストリにプッシュします。
  • #43 12:00-12:20 オペレーターデプロイ用のyamlもSDKで 生成されているので、それを使ってデプロイします。
  • #44 12:20-12:40 デプロイするとこのように見えます。 オペーレーター自身は普通のDeploymentです。
  • #45 12:40-13:00 では、カスタムリソースを生成します。 さきほど、クラスタにCRDを登録しているので、 KindにMemcachedを指定できます。 Specのsizeはここでは3としています。
  • #46 13:00-13:10 このようになります。 Kubectl applyで生成したのはMemcachedなのですが、 その生成イベントを 〜〜〜〜
  • #47 ここで、カスタムリソースのスペックを変えてみます Sizeを3から4に変えてみると
  • #48 13:20-13:40 確かに〜〜〜〜 やはり、カスタムコントローラーがカスタムリソースの変更をwatchしているので、 reconcilenによって、Deploymentが更新できています。 ここまでで動作確認終了となります。
  • #49 13:40-14:00 チップスとしては、コンテナイメージをビルドするのではなくて、 up localコマンドで、オペレーターをgoのプロセスとしてローカルで起動することもできるので、 開発を速く回せるようになっています。 クラスタとの通信設定はkube/configが使われているようでした。
  • #50 14:00-14:20 まとめです ・Operatorについて紹介しました。 〜〜〜〜〜〜〜 ・リーディングするとよい箇所としては CRDと、reconcile 処理を読むと良いと思います。 ・実装方法としては今回はOperator SDKによる手順を紹介しました。 他の実装方法も機会がありましたら紹介できるとよいなと思います。 Operator完全理解した ------------ 感想メモ ・もしキャッシュの話をするならば Api serverに負担をかけないためのcacheの機構があったり、cacheというディレクトリが生成されたりする。 なので、memcachedを題材にしてるのは生成されるディレクトリやソースにcacheという単語が被ってて、サンプルとして不適切だなあと思った(redisくらいで良い)。
  • #51 14:00-14:20 まとめです ・Operatorについて紹介しました。 〜〜〜〜〜〜〜 ・リーディングするとよい箇所としては CRDと、reconcile 処理を読むと良いと思います。 ・実装方法としては今回はOperator SDKによる手順を紹介しました。 他の実装方法も機会がありましたら紹介できるとよいなと思います。 Operator完全理解した という方がいらっしゃいましたら幸いです ------------ 感想メモ ・もしキャッシュの話をするならば Api serverに負担をかけないためのcacheの機構があったり、cacheというディレクトリが生成されたりする。 なので、memcachedを題材にしてるのは生成されるディレクトリやソースにcacheという単語が被ってて、サンプルとして不適切だなあと思った(redisくらいで良い)。