本文延續前一篇文章，作者探討十五種 Kubernetes 不該使用的部署與維運模式，總共三篇，每篇五種。

Misusing Health probes
Kubernetes 內有設定三種不同的 Probe，分別是 Readiness, Liveness 以及 Startup，前兩者 Probe 比較常被提到而且會不停的執行，而 Startup 則是會被運行一次的 Probe。
作者認為所有開發者都要去研究這三種的差異並且小心使用。
文章中列舉一些常見的錯誤用法
1. 用相同的 endpoint 同時處理 liveness 以及 readiness
2. 繼續沿用過往針對 VM 所設計的 health endpoint，應該要針對容器環境重新設計
3. Health 的檢查過於複雜，導致需要花費一個不可預測的時間
..
等

Not using the Helm package manager
作者認為目前 Kubernetes 生態系中只有一個 Package Manager，也就是 Helm，就像是常見的 apt/rpm 等套件般去管理不同的應用程式。
然而 Helm 卻很容易被誤解並拿去跟其他工具比較，譬如 Kustomize, Jsonnet.. 等。
從本質上來看 Helm， Helm 本身有 Package 的管理能力，同時也透過 Template 的方式來產生適合於不同環境的 YAML 檔案。 而上述其他的比較解決方案基本上都只能完成後者，透過如 overlay (kustomize) 等不同的方式來產生不同的 YAML，但是本身卻沒有去管理這些安裝好的應用程式。

如何產生 YAML 這些是部署前的流程，而上述的那些工具對於檔案部署到 Kubernetes 後就無能為力了，譬如想要刪除任何安裝到 Kubernetes 資源的應用程式，必須要找到原始的 YAML 檔案。而 Helm 則不一樣，本身會於 Cluster 內去記錄這些這些資訊，讓你可以透過 helm 的指令去刪除這些安裝好的應用程式。

作者認為除非團隊很明確的瞭解與設計其工作流程，確保 Helm 帶來的部署與管理流程不需要，否則推薦任何團隊都可以採用 Helm，特別是之前因為 Helm2 Tiller 而厭惡的人必須要來試試看 Helm3

Not having a strategy for secrets
如同先前探討的 Configuration 不應該直接嵌入 Contaienr Image 一樣，Secret 這類型的物件也一樣，作者看到團隊常有下列錯誤
1. 使用各種不同的方式來管理 Secret 物件
2. 沒有區分好運行期需要的 Secret 與建制時期需要的 Secret
3. 過於複雜的處理方式導致本地測試與開發過於困難

相反的，團隊應該要
1. 選擇一個策略
2. 所有團隊使用該策略來處理 Secret
3. 所有的 Secret 應該都要用相同的方式處理
4. 這樣的機制使得 secret 的管理與追蹤更為容易

Attempting to solve all problems with Kubernetes
永遠不要認為 Kubernetes 能夠解決所有問題，團隊必須要理解到 Kubernetes 帶來的優點與缺點，團隊本身的部署與工作流程是否適合使用 Kubernetes。
也不要想說要把所有服務都搬到 Kubernetes 內，譬如 databases, caching 等，這些本來就存在的解決方案依然可以使用本來的方式繼續部署，不要一相情願地覺得這些東西放到 Kubernetes 內就一定會更好。

詳細原文可以參考下列連結。

https://medium.com/containers-101/kubernetes-deployment-antipatterns-part-3-dfbdd2fd3292

這篇文章是 Tekton 這套號稱完全針對 Cloud-Native 所發展的 CI/CD 工具教學文，作者從基本概念到如何使用都詳細的介紹一番，讓讀者看完就對 Tekton 能夠有基本的認知。

就如同其他常見的 Pipeline 系統一樣，Tekton 的工作流程是由 Step, Task 以及 Pipeline 組成。Tekton 使用 Step 描述每個最小工作事項，而每個 Task 則由數個 Step 組成，這些 Step 會依序執行，且彼此會共用相同環境，譬如 Volume.
Pipeline 則是由數個 Task 所組成，不過比較特別的是這些 Task 可以有更為靈活的執行順序，譬如依序執行，平行執行，甚至是 DAG 這種有向無環圖的執行順序。

Tekton 的一大特色是其完全寄生於 Kubernetes 內，必須要搭配 k8s 的環境來使用，也因此上述的 Step,Task 以及 Pipeline 實質上都是屬於 K8s 的 CRD 一種，部署時需要透過 YAML 來撰寫，並且用常見的方式 (kubectl, helm, kustomize) 來安裝到 k8s 內去設定 Tekton。

這種模式帶來的一個好處就是每個元件都是獨立的 YAML 檔案與類別，因此相同的部分可以非常輕易的被重複使用，舉例來說一個運行 Git-Clone 的 Task 就可以被多個不同的 Pipeline 重複使用，而有需求需要修改的時候也只需要修改一個 Task 即可。

對於 Tekton 這套解決方案有興趣的可以參閱下列全文玩耍看看
https://lambda.grofers.com/adopting-tekton-cloud-native-ci-solution-67fb229f4992

這篇文章要介紹的是 Jenkins Operator 這個有趣的應用程式，Operator 的概念先前有不少文章再探討其架構與意義，因此本篇文章會專注於 Jenkins Operator 這個應用程式能夠為 Jenkins 的環境與應用帶來什麼樣的變化。

首先本文開始前，要先準備三個東西
1. Kubernetes Cluster
2. Helm 安裝環境
3. 一個放有你 Jenkins pipeline 與 script 的 SCM(Source Code Management)，通常都是 Git

接下來作者透過 Helm 安裝了 Jenkins Operator 該控制器到 Kubernetes 內並且準備了相關的 CRD 用來控制 Jenkins.

範例中的 CRD 主要會做兩件事情
1. 設定 Jenkins 本身，包含要安裝哪些 Plugin 等
2. SeedJobs: 可以將外部 SCM 內所描述的 Job 內容給直接設定到 Jenkins 內

當該 CRD 給套用到 Kubernetes 後，該 Jenkins Operator 就會幫忙初始化整個 Jenkins 以及相關的 Plugin。最後將 SeedJobs 內所描述的資訊給整合到 Jenkins 中來創建相關的 Job.

透過這整個 CRD 操作帶來的好處我認為有
1. 整個過程盡量減少手動操作，全部都依賴 Yaml 與 Pipeline 等程式碼的方式去維護
2. 與 Kubernetes 整合，對於熟悉 Kubernetes 的操作人員來說，學習過程不會太痛苦。
3. 把 Jenkins 變得稍微簡單一些，一些繁瑣過程讓 Jenkins Operator 去操作

我自己看完後，目前看到的壞處有
1. Jenkins 功能太多，生態系太複雜，我懷疑這種 Operaotr 只是一時的專案，沒有一直保持更新的話一定會有些功能終究還是要手動操作
2. 設定的內容我認為不如 Jenkins 生態系中的 Configuration as Code 這套 Plugin 來的專業與強大
3. Job 的設定部分我個人還是偏好使用 Jenkins Job Builder 這套基於 YAML 的解決方案來管理與定義全部

結論:
1. 我個人是當作一個新東西看看，但是不會有想要嘗試的慾望，因為覺得事情其實沒有變得簡單多少，甚至擔心引入一個半成品，導致多一個東西要維護..

https://medium.com/swlh/introduction-to-jenkins-operator-f4cb7ebc2e0b