ref: https://blog.kubecost.com/blog/kubernetes-labels/

本篇文章是一個 Kubernetes Label 介紹文， Kubernetes 的使用者一定都知道 Kubernetes 內的物件很大量依賴 Label 的使用，最基本的用法就是
Deployment 與 Pod 之間是透過 Label 與 LabelSelector 互相溝通的。

Kubernetes 提供兩種不同的方式來為資源打上標記，分別是
1. labels
2. annotations

兩者都是基於 key/value 的方式來設定，不過用途是完全不同。 Label 主要是用來提供辨識的功能，讓使用者可以透過 key/value 的方式來辨識當前的資源，就如同前述提到的 Deployment 與 Pod 的關係。
透過 Label 來標示 Pod，而 Deployment 則透過 LabelSelector 來選擇符合標準的 Pod。

Label 主要有兩大用法
1. Grouping Resource for Queries
2. Bulk Operations.

第一種用法就是前述提到的，將一群資源透過 Label 給標記起來，另外一個則是透過 kubectl 等指令操作時，可以一口氣操作多個資源，譬如
kubectl delete deployment -l environment in (dev,sit)
上述資源可以一口氣將符合 environmnet=dev 以及 environmnet=sit 的 deployment 給一次刪除。

文章中還列舉了其他介紹與學習 Labeling 概念的網站，最後還提到一個使用 Label 上要注意的相關事項
1. 不要將一些會一直改變的資料放到 Label 中
2. 沒有任何理由的話，不要輕易去修改運行資源的 Label 內容
3. Label 本身的設計不是一個 data store，所以不要將一些 Application 的重要資料給存放到 Label 上

對於 Label 這概念想要更深理解的可以參閱全文

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

這篇文章探討的是 kubectl 於 1.18 對於 kubectl run/kubectl create 改動所造成的影響，這個影響我認為層面不會太大，但是對於習慣用 kubectl run 的人來是一個滿大的困擾，簡單來說就是移除了一些用法，但是卻沒有任何替代解決方案可以取代。

kubectl v1.18 以前，你有至少三種方法可以部署一個 Deployment 到 Kubernetes 中
1. 撰寫程式並且透過相關函式庫直接戳 kubernetes API server 來創建資源
2. 手動撰寫 YAML 檔案，透過 kubectl apply -f 等類似方式創建
3. 透過 kubectl run (e.g kubectl run nginx-1 --image=nginx --port=80 --restart=Always) 此方式來動態創建一個 deployment.

基於各種維護與管理考量，任何的生產環境都會基於 (1)/(2) 這類型可以控管的方式來部署應用程式，基本上不會使用 (3) 這種方式來創建，但是 (3) 某些情況下滿好用的，譬如

1. 新手測試，想要快速起一個 deployment 測試，但是卻不知道去哪邊找一個 deployment Yaml 的範例(Deployment YAML 本身結構多層，人腦難以記住全貌)
2. 一些 OSS 專案想要提供使用者一些範例去操作，會提供 kubectl run 的指令來創建資源

作者還表示可以將 (2) + (3) 給結合，譬如透過下列方式可以產生一個 YAML 內容
kubectl run nginx-1 --image=nginx:1.14.2 --port=80 \
--restart=Always -o yaml --dry-run

接者透過這個範例去創建與修改來達到 (2) 的做法

不過這一切都隨者 kubectl v1.18 的改變而壞光了，因為 v1.18 後 kubectl run 不再支援 deployment 的創建，退而求其次要求使用者透過 kubectl create 去創建資源，但是其支援的參數比過往還要少，所以沒有辦法透過 kubectl create 取代 kubectl run 的所有用法。

詳細的一些內容與比較可以參閱全文

https://alexellisuk.medium.com/kubernetes-1-18-broke-kubectl-run-heres-what-to-do-about-it-2a88e5fb389a

PR: https://github.com/kubernetes/kubernetes/pull/87077
PR: https://github.com/kubernetes/kubectl/issues/898