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