本文延續前一篇文章，作者探討十五種 Kubernetes 不該使用的部署與維運模式，總共三篇，每篇五種。
Using Kubectl as a debugging tool
作者認為一個良好的 Kubernetes 叢集必定要有一個相對應個可觀測性工具，包含 Metrics/Log/Tracing 等。對於一個維運人說來說，今天要處理事情時，第一件事情如果還是慢慢的用 kubectl 來執行 get, describe ,log 等指令找問題的話就太慢了，這類型的工具都應該只是輔助使用，真正還是要依賴有效的監控系統，不論是常見的系統指標，應用程式狀態甚至是應用程式獨特的指標等，將這些資訊整合到一個方便顯示的儀表板，甚至搭配對應的 Alert 功能來達到主動通知。
Misunderstanding Kubernetes network concepts
Kubernetes 內提供的網路功能很容易被搞混，Service(ClusterIP, NodePort, LoadBalancer) 與 Ingress 的差異到底是什麼，很多初次踏入 Kubernetes 的玩家沒有特別去理解差異，只知道應用程式部署後就可以通了。Service Mesh 這個概念作者也推薦去學習與瞭解，知道這個概念是什麼，以及想要什麼解決問題就好，因為並非不是每個叢集都真的需要一套 Service Mesh 的解決方案，但是理解這個概念未來就有能力知道什麼時候需要導入。
Using permanent staging environments instead of dynamic environments
對於應用程式開發者來說，如何於 Kubernetes 環境上測試新功能一直都是一個困難的問題。大部分的團隊中都會有 QA/Staging/Production/Dev(甚至更多)的環境，假設 Dev 環境可以供開發者測試，這些開發者要如何確保自己的修改沒有問題且通過整合測試。
一個常見的問題是假如多個開發者同事部署自己的程式碼到固定環境中，有可能會造成互相干擾，導致問題發生時沒有辦法正確的判別問題是誰產生的。
作者提到一種作法就是透過預借的概念，確保每個開發者使用叢集時都不會有他人干擾，然而這個問題也會引發其他問題，譬如開發者間要互相協調時間，同時每個人用完環境後都要還原成穩定的狀態，以免干擾下一位的使用。
作者推薦使用動態叢集的方式來進行測試，使用 Github PR 為範例，當 PR 開啟時，動態創建 Kubernetes 叢集供測試，當 PR 合併後就會將該 Cluster 給移除。透過這種範例每個開發者都可以有獨立的環境進行測試彼此不干擾，同時也會隨者程式碼的合併而自動回收環境，也不需要擔心環境污染問題。
Mixing production and non-production clusters
任何團隊一定要有正式生產環境的叢集跟其他叢集分隔開來，千萬不能使用 namespace 的方式於一個叢集中同時維護生產與非生產環境。譬如
1. 任何人操作 Kubernetes 都很容易失誤，譬如指令下錯，指向錯的物件。這類型的操作都有可能導致該叢集上生產環境被誤刪
2. namespace 的隔離性不好，實際上很多物件彼此還是可以互相存與溝通，這部分也有其他的隱憂
詳細原文可以參考下列連結。
https://medium.com/containers-101/kubernetes-deployment-antipatterns-part-2-2af25a710bc0
