本文延續前一篇文章，作者探討十五種 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
