歡迎訪問我的GitHub
https：//github。com/zq2599/blog_demos
內容：所有原創的分類和彙總，及配套原始碼，涉及Java、Docker、Kubernetes、DevOPS等
本篇概覽
《kubebuilder實戰》系列已經寫了七篇，前面曾遇到不少問題，磕磕碰碰解決後，打算在本篇集中小結作為備忘，主要由以下幾部分組成：
CRD的Status欄位；
選擇合適的映象倉庫
本地執行controller時跳過webhook
controller的pod有兩個容器
常用操作命令整理
接下來挨個整理，今天的內容不寫程式碼，咱們來一次輕鬆愉快的閱讀；
CRD的Status欄位
這個坑算是自己挖的，希望您能提前避開；
回顧elasticweb的CRD，其資料結構程式碼如下圖：
該CRD的
Status
資料結構只有一個欄位
RealQPS
，該欄位的Tag（也就是上圖紅框），裡面的
omitempty
屬性
非常重要！！！
如果RealQPS的Tag中沒有omitempty屬性，會發生什麼事情呢？
實際上，在開發webhook之前，我一時大意漏掉了RealQPS的omitempty屬性，但是整個
controller可以正常工作
，elasticweb的功能也達到了咱們的預期，也就是說status的欄位如果沒有omitempty屬性，不影響operator的功能；
但是，在啟用了webhook之後，建立資源物件時就報錯了：
zhaoqin@zhaoqindeMBP-2 elasticweb % kubectl apply -f config/samples/elasticweb_v1_elasticweb。yamlnamespace/dev createdThe ElasticWeb “elasticweb-sample” is invalid： status。realQPS： Invalid value： “null”： status。realQPS in body must be of type integer： “null”
也就是說，Status資料結構的欄位中，如果json tag沒有
omitempty
屬性
，在啟用了webhook之後建立資源物件會失敗
；
選擇合適的映象倉庫
看過之前文章的您，應該還記得構建映象的命令：
make docker-build docker-push IMG=bolingcavalry/elasticweb：001
因為我在
hub。docker。com
上註冊的帳號是bolingcavalry，因此上述命令可以將做好的本地映象推送到hub。docker。com的倉庫中（記得提前用docker login命令登入）；
只要映象上傳到了hub。docker。com，能訪問外網的kubernetes就都可以直接使用這個operator了，非常方便；
但是
上傳到hub。docker。com的過程是痛苦的
，動輒半小時的等待，還伴隨著超時退出（映象加速在下載的時候效果明顯，但是上傳的時候，我這看似乎沒啥效果，可能是我不會用，如果您知道還請指點）；
還好，我在阿里雲註冊過，可以使用上面的映象倉庫，入口如下圖：
如下圖，新建公開型別的映象倉庫，點選紅框2，可以看到詳細的登入、上傳、拉取命令，點選紅框3可以修改登入密碼：
使用了阿里雲的映象服務後，操作命令改成了如下內容：
make docker-build docker-push IMG=registry。cn-hangzhou。aliyuncs。com/bolingcavalry/elasticweb：001
整個上傳速度也提升了很多，基本上3分鐘內可以完成映象上傳；
如果您沒有阿里雲帳號，或者對阿里雲的速度也不滿意，也可以自己搭建映象倉庫，自己的內網中速度當然沒的說了，細節不在此展開，這裡有兩篇參考文章：
《CentOS部署Harbor映象倉庫 》
《群暉DS218+部署Harbor（1。10。3） 》
本地執行controller時跳過webhook
controller有兩種部署方式：部署在kubernetes環境內，或者在kubernetes環境外獨立執行
在編碼階段，我們通常選擇在自己電腦上執行controller，這樣省去了映象相關的操作，省時又省事兒；
但是，如果使用了webhook，由於其特殊的鑑權方式，需要將kubernetes簽發的證書放置在本地（/tmp/k8s-webhook-server/serving-certs/目錄），這就讓我們兩難了：
選擇部署在kubernetes環境，要製作映象和上傳映象；
選擇執行在kubernetes環境之外，要簽發證書放置在指定目錄；
面對上述兩難的糾結，官方給出了一個建議，如果在開發階段暫時用不上webhook（
注意這個前提
），那麼在本地執行controller時可以用一點小手段遮蔽掉webhook功能，具體操作由以下兩步組成：
首先是修改main。go程式碼，如下圖，紅框中是新增的程式碼，其實就是增加了一個判斷，如果環境變數
ENABLE_WEBHOOKS
等於
false
，就不會執行webhook相關邏輯：
其次，本地啟動controller的命令，以前是
make run
，現在改成如下命令，即增加了一個引數：
make run ENABLE_WEBHOOKS=false
現在controller能正常啟動了，功能也正常，只是
webhook相關的功能全部都不生效
了；
controller的pod有兩個容器
如果controller部署在kubernetes環境內，其是以pod的形態存在的，也就是說咱們寫的webhook、reconcile程式碼都是在這個pod中執行的；
上述pod內實際上有兩個容器，用
kubectl describe
命令看看這個pod，如下圖，可見名為
manager
的容器才是controller程式碼執行的地方：
一個pod中有兩個容器，對咱們的日常操作略有影響，簡單來說就是使用
kubectl logs
命令檢視controller日誌的時候，要用
-c
引數指定容器，完整命令如下：
kubectl logs -f \elasticweb-controller-manager-58576f4cb-hzchl \-c manager \-n elasticweb-system
常用操作命令整理
最後把常用的操作命令整理出來，便於日常使用：
建立operator專案：
kubebuilder init ——domain com。bolingcavalry
建立API
kubebuilder create api \——group webapp \——version v1 \——kind Guestbook
建立webhook
kubebuilder create webhook \——group elasticweb \——version v1 \——kind ElasticWeb \——defaulting \——programmatic-validation
構建和部署CRD
make install
本地執行controller
make run
構建映象並推送到倉庫
make docker-build docker-push IMG=registry。cn-hangzhou。aliyuncs。com/bolingcavalry/elasticweb：001
controller部署到kubernetes
make deploy IMG=registry。cn-hangzhou。aliyuncs。com/bolingcavalry/elasticweb：001
建立elasticweb資源物件
kubectl apply -f config/samples/elasticweb_v1_elasticweb。yaml
刪除elasticweb資源物件
kubectl delete -f config/samples/elasticweb_v1_elasticweb。yaml
刪除controller
kustomize build config/default | kubectl delete -f -
刪除CRD
make uninstall
檢視日誌
kubectl logs -f \elasticweb-controller-manager-58576f4cb-hzchl \-c manager \-n elasticweb-system
至此，kubebuilder實戰期間的知識點小結就完成了，若您正在學習和開發operator，希望本篇的小結能給您一些參考；
歡迎關注我的公眾號：程式設計師欣宸
