K8S權威指南摘要
Master
Node
RC，Replication Controller
Replica Set
Deployment
Service
Pod
Lable
Annotation
Namespace
服務發現
網路IP
採用NodePort，對外暴露service，
kubelet
kube-proxy
Operator
純轉載，這個對於operator解釋的比較清楚，
k8s operator的開發感悟
k8s的文件中本身沒有operator這個詞，operator實質是指：使用者註冊自己自定義的Custom Resource Definition，然後建立對應的資源例項（稱為Custom Resource，簡稱CR），而後通過自己編寫Controller來不斷地檢測當前k8s中所定義的CR的狀態，如果狀態和預期不一致，則調整。Controller具體做的事就是通過呼叫k8s api server的客戶端，根據比較預期的狀態和實際的狀態，來對相應的資源進行 增，刪，改。
舉個例子，deployment中的replica數量是3，意味著pod的數量必須維持在3，多了，就去除，少了，就建立。由於deployment是k8s內建的資源，k8s本身就有內建的controller來維護deployment的狀態。如果自己要建立一個新的邏輯，那麼就建立新的CRD和controller，來建立和維護對應的deployment，service之類的服務。
開發自己的k8s的controller的好處是什麼？現在一般部署k8s上自家的程式碼，幾乎都是stateless，也就是說，對應的pod崩了之後，在重啟一個就行，吞吐上不來的時候，橫向增加pod數量就行。但是如果程式碼的邏輯需要維護一個狀態（比如當前訊息讀取的offset），怎麼辦？pod崩了之後，如何恢復狀態？可以上wal，上zookeeper，甚至k8s自身的etcd，如何自動化這部分“恢復的邏輯”？就是controller可以做的事兒，其實你用ansible等指令碼也可以做，只是operator給你提供了一個開發友好的方式。你可以測試，部署，釋出，一切都用go寫，而不是在腳本里掙扎。還有就是用go自己寫如何擴充套件伸縮。
這個Controller可以執行在k8s叢集裡，也可以是另外一個地方，本質就是一個使用了k8s客戶端的小程式。
這裡的開發邏輯是基於pull，而不是push，也就是說k8s的api server不會主動的傳送事件給controller，而是k8s的go的client不斷地‘拉’訊息來獲取最新的叢集狀態。這個‘拉’的方式的效率低，需要不斷地get狀態，這個肯定被考慮了，go的client內建就有一個佇列來快取事件訊息，controller的邏輯就只需從佇列中取訊息處理即可。
https://engineering.bitnami.com/articles/a-deep-dive-into-kubernetes-controllers.html
https://engineering.bitnami.com/articles/kubewatch-an-example-of-kubernetes-custom-controller.html 這兩篇文章就清楚的展示了go的client的內部工作原理。
教程
具體的開發主要是使用controller-runtime和k8s api的Go庫。
可以自己寫，也可以使用框架：kubebuilder或operator-sdk
https://book-v1.book.kubebuilder.io/ 雖然這個教程是v1的，但是我個人認為是最好的入門材料
https://sdk.operatorframework.io/ https://github.com/kubernetes-sigs/controller-runtime 兩者要結合一起看
注意的點
建立CRD的時候，最好要設定owner，這樣刪除CRD的時候，其附帶的deployment等資源，也會被自動刪除。
CRD的刪除事件是通過監測metadata中的deletionTimestamp域，如果deletionTimestamp不為空，那麼說明這個資源被刪除了（其對應的k8s內部的資源，比如service等也會被自動刪除），但是如果需要刪除一些外部的資源，比如資料庫的一些資料，那麼可以通過設定CRD的Finalizer域，一般情況下，Finalizer域為null，k8s看到後就直接把資源刪除了，但是如果Finalizer域不為空，那麼k8s就不會刪除資源，而是等待，知道我們的controller把外部的資源刪了，並且把Finalizer設定為空，k8s才會刪除資源。