這篇文章是 Tekton 這套號稱完全針對 Cloud-Native 所發展的 CI/CD 工具教學文，作者從基本概念到如何使用都詳細的介紹一番，讓讀者看完就對 Tekton 能夠有基本的認知。

就如同其他常見的 Pipeline 系統一樣，Tekton 的工作流程是由 Step, Task 以及 Pipeline 組成。Tekton 使用 Step 描述每個最小工作事項，而每個 Task 則由數個 Step 組成，這些 Step 會依序執行，且彼此會共用相同環境，譬如 Volume.
Pipeline 則是由數個 Task 所組成，不過比較特別的是這些 Task 可以有更為靈活的執行順序，譬如依序執行，平行執行，甚至是 DAG 這種有向無環圖的執行順序。

Tekton 的一大特色是其完全寄生於 Kubernetes 內，必須要搭配 k8s 的環境來使用，也因此上述的 Step,Task 以及 Pipeline 實質上都是屬於 K8s 的 CRD 一種，部署時需要透過 YAML 來撰寫，並且用常見的方式 (kubectl, helm, kustomize) 來安裝到 k8s 內去設定 Tekton。

這種模式帶來的一個好處就是每個元件都是獨立的 YAML 檔案與類別，因此相同的部分可以非常輕易的被重複使用，舉例來說一個運行 Git-Clone 的 Task 就可以被多個不同的 Pipeline 重複使用，而有需求需要修改的時候也只需要修改一個 Task 即可。

對於 Tekton 這套解決方案有興趣的可以參閱下列全文玩耍看看
https://lambda.grofers.com/adopting-tekton-cloud-native-ci-solution-67fb229f4992

本篇文章帶來的是 Kubernetes 1.20 的一些整理，到底 Kubernetes 1.20 有什麼改變以及要如何升級舊有的 Kubernetes 到 1.20

官方宣稱該版本有 42 個改進，其中 11 個改進是該內容正式畢業進入 stable 版本， 15 個轉移到 beta 版本而剩下 16 個則是進入 alpha。

1. Volume Snapshot Operations (Stable)
針對容器快照的相關操作正式進入穩定版，要注意的是這個功能必須要使用的 Storage 服務有支援，同時請記得，針對任何的儲存設備，可以使用 CSI 來安裝就使用 CSI。
盡量不要繼續使用 in-tree 的方式去銜接這些設備了，因為所有的維護與修改都轉移到 CSI driver 上

2. Kubectl Debug (Beta)
Kubectl alpha 之前的子指令 debug 已經正式轉移到 beta 版本，未來可以直接使用 kubectl debug 的指令來幫忙一些資源的驗證與處理。
譬如
a. 創建一個 pod 部署到指定的節點上並存取節點上的檔案系統來提供對節點的除錯功能
b. 針對運行 crash 的 pod 除錯

3. Dual IP Stack IPv4/IPv6 (Alpha)
IPv4/IPv6 功能重新實作，未來將可以對單一 Serivce 同時指派 ipv4 + ipv6 的地址，同時也可以針對現存單一 ipv4 的 service 進行轉換

4. Graceful node shutdown (Alpha)
過往刪除 Pod 時都會有所謂的 pod lifecycle 等階段來處理一切狀態，但是當節點被關機時，節點上方運行的 Pod 並不會遵循 Pod lifecycle 來處理。
這個新的功能將會讓 Kubelet 去感知到節點正在關閉，並且能夠針對正在運行的Pod去提供 graceful shutdown 的過程

更多的討論可以參考下列文章或是直接看官方全文，滿多功能都慢慢改變
另外要注意的是，每次改版都要注意 API 是否有改變名稱，非常推薦使用如 kube-no-trouble 這類型的工具去檢查當前部署資源的 APIVersion 是否有即將要被捨棄的，避免 k8s 更新後應用程式都無法部署上去的情況發生

https://faun.pub/whats-new-in-kubernetes-version-1-20-and-how-to-upgrade-to-1-20-x-5ea72f904e7d

Kubernetes 中最常使用的工作單位就是 Deployment，而 Deployment 採用的更新策略是 RollingUpdate，意味者當更新發生時，會先產生出 n 個新版本的 Pod，並且透過 Readiness 去確認該 Pod 目前可視為正常工作後，就會移除先前版本的 n 個 Pod。

因此本文想要探討的是，如果你想要使用不同的更新策略，你可以怎麼做？

該文章的架構是基於 Argo RollOuts 這個工具來如何達到金絲雀部署與藍綠部署

1. Argo RollOut 的安裝非常簡單，主要操作都是透過 CRD 來完成
2. 對於已經現存的 Deployment 物件，可以非常輕鬆的轉換到 Argo RollOut 的 CRD

#金絲雀部署
金絲雀部署的狀況下，我們會希望能夠把部分的流量先行導入到新的應用程式，接者逐漸調高比例直到最後全面切換過去。這部分可以想像成類似下列的步驟

假設本來有10個舊有應用程式 v1, 現在要升級成 v2.
1. 先部署兩個新版本的應用程式，直到 Readiness 完成後，移除舊有的兩個應用程式
2. 部署人員確認目前狀況良好，決定繼續往下推動，再次部署兩個新的
3. 部署人員再次確認，依序往下部署新的應用程式直到十個都全面替換完成

而上述的過程再 Argo RollOut 會依賴兩個部分完成
1. Yaml 中定義這些步驟
2. 透過 kubectl argo (Plugin) 的方式告訴 Controller 請繼續往下

譬如下列檔案定義步驟
```
strategy:
canary:
steps:
- setWeight: 20
- pause: {}
- setWeight: 40
- pause: {duration: 10}
- setWeight: 60
- pause: {duration: 10}
- setWeight: 80
- pause: {duration: 10}
```
維運人員透過指令要求繼續往下執行

文章後續還有探討如何用 Argo RollOut 來完成藍綠部署，同時部署兩個完整群體，並且透過切換 Service 來指向不同版本的群體

對於想要嘗試不同更新策略的玩家，可以詳細閱讀本文並且玩轉看看 Argo RollOut。

https://medium.com/@ptran32/control-your-kubernetes-deployment-with-argo-rollouts-adb54c4e9b7d