這篇文章探討的是 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