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

今天要來跟大家分享一個單一節點如何提高應用程式吞吐量與服務能力的方式

這個方式主要探討的是應用程式對於網路連線的 I/O 模型，試想一個常見的使用範例。
一個主要的 Process 會去聽取一個固定的 port number (ex port 80)，並且通知後面眾多的 worker 來幫忙處理這些封包連線，而這些 worker 的工作就是處理連線。
整個架構中是一個 1 v.s N 的狀況， 一個負責 Listen ，N個負責處理連線內容

而今天要分享的則是想要讓架構變成 N v.s N 的狀況， 會有 N 個 Process, 每個 Process 配上一個 Worker。
而這 N個 process 同時共享一樣的 Port (ex, port 80)
這種情況下可以減少多個 worker 共享一個 listen socket 時的各種保護機制，取而代之的則是每個 listen socket 配上一個專屬的 worker 來處理。

要達成這樣的架構非常簡單，只要透過 SO_REUSEPORT 這個 socket option 告
訴 Kernel 當前這個 PORT 可以重複使用。

當封包送到 kernel 後則是由 kernel 幫你分配封包到所有使用相同地址的 Listen Socket (Process)

根據 nginx 官方文章的測試，這種架構下對於 RPS (Request per second) 有顯著的提升，有興趣的可以看看下列兩篇文章

參考文章:
- https://blog.cloudflare.com/the-sad-state-of-linux-socket-balancing/
- https://www.nginx.com/blog/socket-sharding-nginx-release-1-9-1/