"実践入門Kubernetes カスタムコントローラへの道"を読んだメモ
これは何?
技術書典で購入させて頂いた"実践入門Kubernetesカスタムコントローラへの道"を読んで、ただただ学んだこととかを書くだけの振り返りメモです。
たまには本を読みながら学んだことをアウトプットしようと思いました。
読んだ本
前提知識
・基本となるリソースとコンポーネントは、なんとなく知っている
・Kubernetesのソースを読んだことは無い
・go言語はチュートリアルレベル
・CRDとかコントローラとかOperatorとか、よく聞くけど全く知らない
・client-goってなに?
CRDとかコントローラとかそのあたり
・CustomResourceDefinitionはユーザが定義した、Kubernetes標準ではないリソース。CRDが定義、CRがオブジェクト。
・コントローラ:リソースの管理や操作を行うcontroller全般。
・カスタムコントローラ:ユーザ定義のコントローラ。
・Operator:CRDとその管理や操作を行うカスタムコントローラをセットでそう呼んでる。なんらかの要件を実現するためにはセットで実装されるのがたぶん一般的であるため。
CRDとCRの話を読んで、つまり他のリソースの多くも同じ仕組みなんだろうかと思った。
ControllerとCRDの実装法
・Kubernetes Way
Kubernetes the hard way と同じようなニュアンス?
・Kubebuilder
Operator開発用のフレームワーク
・OperatorSDK
Operator開発用のフレームワーク
client-go
GoからKubernetesのAPI、リソースにアクセスするためのGoのライブラリのことだった。
たぶんkubectlも中で使ってるのだと思うし、コンポーネントがkube-apiserverにアクセスする時とかも中身はこれを使ってるのだろう。
clientset
client-goの一部であるclientsetが、kubernetes標準へのアクセス全般で使える。
写経して、たぶんこれを生成することから始まるのだと理解。
informer
kube-apiserverのListAPIでオブジェクトを取得して、WatchAPIを見続けてあらゆるイベントを見てる、よく聞くやつ。
・これが、いろんなk8sコンポーネントが参照してトリガーにしてるやつでは?と思った。(でも、正確には後に出てきたworkqueueっぽい)
・kube-apiserverの負荷軽減のため、in-memory-cacheである程度はオブジェクトの状態を保持しておく
・informerの名前の通り、watchした内容をもとに発火する役目。
・発火時の挙動がEventHandler?
lister
informerのin-memory-cacheを覗く役目。
workqueue
・informerのEvntHandlerがエンキューする先
・つまり実際にcontrollerが見るのはWatchAPIでもListAPIでもなくここ?
scheme
CRがここに登録されていないと、Controllerが使えない?
runtime.object
kubernetesのAPIのinterface?
GroupVersionKind / GroupVersionResource
それぞれ、3つをまとめた構造体。おそらくこう持つということか。
type GroupVersionResource struct {
Group string
Version string
Resource string
}
この辺、よく理解するとマニフェストをもっと正確に理解できそうなのでもう少し学びたい。apiVersion付近は未だに厳密にはわからない。
DeepCopy
・Objectをcloneする関数
・たぶんinterfaceで定義されててみんな実装するor持ってる?
TypeMeta
マニフェストのmetadata部、ではなく、
・apiVersion
・kind
ObjectMeta
・こっちがマニフェストで言う、いつものmetadataゾーンのこと。
おわり
informer,lister,workqueueあたりの部分、読んでてめちゃくちゃ熱かった。
あと、地味だけどAdditionalPrinterColumnsが知れてよかった。
kubectl getして出た情報に対して、「これ何?実際どっから取ってんの?」って思うことがたまにあったので。
4章以降はほぼ写経したので、あまりメモに書いてないです。
次はサンプルみたいにやりつつ自分でカスタム要素を入れてみたいと思う。
この記事が気に入ったらサポートをしてみませんか?