今天這篇文章比較偏向一個範例操作，如何透過 Terraform 這種 Infrastructure as Code 的概念來管理 AWS 資源。
範例中使用到的資源是 ECS (Container Service)，一個提供容器運行的服務平台。
一種最簡單的手動範例就是
1. 本地開發應用程式
2. 容器化本地應用程式
3. 找到一個 Container Image Repository 將 Container Image 給推上去
4. 手動創見相關 AWS 資源，譬如 ECS， LoadBalacner, Security Group (Firewall) 等資源
5. 部署該應用程式

本篇文章希望透過 Terraform 的方式將上述的 (3,4,5) 等過程都透過程式碼的方式來描述，這部份帶來的好處其實也是 IaC 所闡述的價值，不論是可以透過 code review 的方式來分享與確保每次變動的品質，對於環境複製等都可以更為快速且品質相當，減少那些不被記錄的人為修改。


註: 我個人認為這類型文章偏向入門，對於還不熟悉 Terraform 的人可以有一個快速的導覽，大概知道 Terraform 可以做到什麼樣的東西
https://medium.com/avmconsulting-blog/how-to-deploy-a-dockerised-node-js-application-on-aws-ecs-with-terraform-3e6bceb48785

如果有在使用 Kubernetes Service 的人可能都有聽過 Load-Balacner 這個類型，然而 Kubernetes 本身並沒有實作 Load-Balacner，而是要仰賴其他的第三方服務，譬如公有雲上提供的 LB。如果今天想要餘地端環境使用，針對這些 bare metal 的機器，我們如果要使用 Load-Balancer 的話，就必須要使用額外的解決方案，譬如 MetalLB
今天要介紹的則是另外一個解決方案， porter，該解決方案的特色有

1. 支援 ECMP (Equal-Cost MultiPath) 多重路由協定
2. 支援 BGP
3. 支援 K8S Service
4. 可以用 Helm Chart 安裝
5. 透過 CRD 的方式來修改 BGP 設定，而不需要重起相關服務


專案內有列出跟 MetalLB 的差異，優點主要是基於 CRD 與 Controller 的概念去整合整個 BGP 的操作，同時與 Calico 衝突時有更好且優雅的方式去解決

有地端環境使用需求的人可以稍微看看這個專案囉

https://github.com/kubesphere/porter

恭喜 etcd 加入 CNCF 畢業者的行列，愈來愈多的畢業專案囉，下列的畢業專案你用過哪些呢?

1. containerd
2. CoreDNS
3. Envoy
4. etcd
5. Fluentd
6. Harbor
7. Helm
8. Jaeger
9. Kubernetes
10. Prometheus
11. Rook
12. TiKV
13. TUF
14. Vitess

稍微分類的話，大概是
基本架構來說，運算儲存網路都有
觀測性來說， Monitoring + Logging + Tracing 也都有
其他的譬如安全性及 DB 也都有相關專案

有興趣的可以每個都研究一下囉

https://www.cncf.io/announcements/2020/11/24/cloud-native-computing-foundation-announces-etcd-graduation/

今天分享的是由 CloudBees 所分享的 DevOps 議題，
GitOps 的世界中，該如何做好 Secret Management ?

該影片提到幾個重點
1. Git 本身的設計不是用來純放與共享 Secret 等資訊
所以千萬千萬不要於 Git 內去存放 Secret 物件，因為他只有編碼，沒有加密。

有不少的流派方式可以用來管理 Secret Management，譬如說
1. Sealed Secrets 該專案的流派，實實在在的加密敏感資訊，並且把加密後的結果存放到 Git 專案中，當這些物件被套用到 Kubernetes 內時，會有對應的 Controller 去解密，並且產生最後的 Secret 物件
評論: 這種流派下就要特別注意該加解密的 key 不能外流，並且要定期 rotate

2. 打包 Image 的時候直接將相關的機密資訊一起打包，這樣使用時完全不需要外力介入，直接使用。
然後這種情況帶來的問題很多，缺乏彈性，image 本身變得非常危險，要花更多心力去確保 Image 不會外流。極度不推薦這種走法

3. 透過外部的 External Secrets Management 平台來管理，譬如使用由 Godaddy 所開源的 kubernetes-external-secrets 專案，該專案後端支援 AWS Secrets Manager, AWS System Manager, Hashicorp Vault, Azure Key Vault, Google Secret Manager 等眾多項目，並且提供一個統一介面給 Kubernetes 使用。 Kubernetes 中透過 ExternalSecrets 的方式就會觸發 Controller 去存取相關的機密資訊，並且轉成 Secret 物件供容器使用


有興趣的人可以點選下方連結觀賞完整影片，大概 20 分鐘左右，非常適合邊吃飯邊看
https://cd.foundation/blog/2020/11/05/gitops-kubernetes-and-secret-management/

今天要來跟大家分享可觀測性的相關議題，作者文章中不斷強調一句話，“You can’t perform any operation without proper visibility.”

因此整篇文章的核心都是基於，你要如何觀測你的 Kubernetes 叢集，你該收集什麼樣的資料。作者列出七個不同的觀測面向，並且主觀根據自身經驗而排序，本文只有先介紹後面三個面向，分別是 Kubernetes metrics APIs, Service APIs, 以及 Container APIs.

Kubernetes metrics APIs
這類型的觀測是最知名也最廣泛使用的，通常有整合 Prometheus + Grafana 的使用者都會直接觀測這類型的資訊。這些資訊來自 kubelet-metrics 以及 kube-state-metrics 等 cluster 層級的資訊。 作者認為這部分不需要提太多，因為基本上是必備且不需要額外設定就會有的資訊。


Service APIs
Service 主要是幫 Pod 提供一個統一的存取介面，牽扯到的內部資源有 endpoints, service，甚至 Ingress 也都包含進去。
作者認為網路這一塊也是一個盲點，也必須要有能力去收集相關資訊，否則遇到如下列情況，容器運作正常，沒有回報任何錯誤，但是網路方面出現問題。從你的監控面板來說則會看不到任何錯誤，只能被動等待任何人發現網路有問題。

Contaienr APIs
我們都知道 Kubernetes 內的最小運算單元是 Pod，然而一個 Pod 上面可以運行多個 container，因此真正在觀測的時候，Container 本身的資訊也非常重要，因為這些元件才是真正使用系統資源(CPU/Memory)的使用者。


文章中還有提到一個有趣的 CNCF trail map，有興趣的可以點選全文觀看

https://www.cncf.io/blog/2020/11/11/the-top-kubernetes-apis-for-cloud-native-observability-part-1-the-kubernetes-metrics-service-container-apis/

Measuring Devops 

來自 Google 的 Developer Programs Enginner 跟大家分享如何透過 Teckon 來分析你的 DevOps 流程

作者認為 DevOps 的概念是一種組織上的文化演進，目標是希望提昇軟體交付的速度，提昇服務可靠性。

根據 DORA (State of DevOps research program) 的研究，認為 DevOps 中有四個主要的指標。分別是
1. Lead Time to Change
-> Code Commit 到生產環境內的花費時間總量
-> 計算方式: Lead Time 單次的計算是根據部署與 Commit 發生的間隔
-> 每一次的 Deployment 都要計算跟他有關的所有 Change.
2. Deployment Frequency
-> 執行一次成功的生產環境部署的頻率 (每日)
-> 計算方式: 每天部署多少次
3. Change Fail Rate
-> 部署到生產環境的失敗次數
-> 計算方式: 每天部署多少次，總共有多少次失敗
4. Time to Restore
-> 生產環境發生問題時，花多少時間恢復

今天如果想要知道自己的 DevOps 流程到底針對上述這些指標有帶來什麼樣的進步與變化，要如何測量這些？

作者認為要滿足這些條件，需要有相關的 Table 來記錄每項資訊，並且整合後匯出相關資訊，因此 Google 開源了一個名為 fourkeys 的專案用來完成這件事情。
有興趣的可以點選影片連結與專案介紹來瞭解更多

專案:
https://github.com/GoogleCloudPlatform/fourkeys/

影片:
https://cd.foundation/blog/2020/11/05/measuring-devops/

不知道大家有沒有注意最近的 LineDevDay(下方影片) ? 該影片中介紹 Line 是如何使用 ArgoCD 作為 GitOps 的解決方案，並且從中獲得了哪些好處。 Line 作為台灣一個非常知名的軟體公司，想必這樣的使用經驗也能夠給大家帶來一點 GitOps 的信心加持

因此今天這篇文章就來跟大家介紹 GitOps 的範例文章，該文章使用 CircleCI + ArgoCD 來搭建一個 
GitOps 的操作流程，文章也介紹了 Repo 本身的管理，到底應用程式的原始碼與相關的設定檔案(Yaml) 要放一起還是要分開？ 實際是這個問題的答案沒有絕對，不同情境都會有不同的用法，甚至還有所謂的 umbrella chart 這種概念來管理多個 Helm Chart。

有興趣的我建議先看看 Line 的介紹，接者再看看別人如何實作。當然如果對於 GitOps 不熟悉的話，也歡迎看看我部落格內全部的 GitOps 相關文章

Reference:
1. https://linedevday.linecorp.com/2020/en/sessions/9156
2. https://www.hwchiu.com/tags/GitOps/

https://medium.com/dev-genius/kubernetes-ci-cd-with-circleci-and-argocd-6473b0acdc1a

#小編

On-premeises Kubernetes CNI - Calico 安裝參考指南

你遇到 flannel CNI plugin 使用上的限制了嗎？你知道flannel 所用的ipam CNI plugins (host-local) 是有潛在的風險嗎 ?

想知道的朋友請持續追蹤粉絲頁，下集將會揭露 flannel 所綁定（不能替換）的IPAM CNI 有使用上的風險。

今天主要是提供一個參考指南給各位安裝 Calico CNI 其實安裝並不麻煩，已經將文件整理好給搭配安裝的決策可以考慮使用哪一種 Calico CNI

[1] https://docs.projectcalico.org/getting-started/kubernetes/quickstart

[2] https://docs.projectcalico.org/getting-started/kubernetes/self-managed-onprem/onpremises#install-calico-with-etcd-datastore

[3] https://docs.projectcalico.org/getting-started/kubernetes/self-managed-onprem/onpremises#install-calico-with-kubernetes-api-datastore-50-nodes-or-less

[4] https://docs.projectcalico.org/getting-started/kubernetes/self-managed-onprem/onpremises#install-calico-with-kubernetes-api-datastore-more-than-50-nodes

* Hybrid deployments 是在可能為混合環境所安裝的 Calico CNI Plugins ，舉例來說基礎設施可能存在 Openstack/Kubernetes，相對來說，none-hybrid 可以視作純Kubernetes環境

延續前篇文章的 CNI/IPAM 管理問題，這邊跟大家分享一個使用 Flannel 可能會遇到的情形，這篇文章中，我透過一個不尋常的操作範例最後讓 Kubernetes 內產生重複 IP 的情況，並且仔細分析這個案例為什麼會發生。

最後探討這不尋常的操作實際上使用 Rancher 來管理 Kubernetes 的時候，是有可能遇到的

本文牽扯到的內容比較底層，從 CNI 到 IPAM 的介紹，並且稍微詳細探討了 host-local 這個 IP 管理工具是如何分配與管理 IP 的。透過對這些工具的熟悉與理解，看到這類型問題的時候會有很多想法知道可以從哪邊下手去除錯與研究。

原文:https://www.hwchiu.com/kubernetes-duplicate-pod-ip.html

想學習更多關於 Kubernetes 的實戰經驗與基礎設計，可參閱我的線上課程: https://technologynoteniu.github.io/awesome-notes/linux/network/

#小編
2330 股價又來到今年的相對高點收在499 還記得一年前才230幾... 昨晚美股TSM更是飆出了單日漲幅6%的紀錄。

好的，今天不是來談投資的 XD

台灣半導體產業 台積電 最近釋出的招募訊息，其中提到雲平台(Cloud infra) 工程師其中包含的職缺有

- DevOps Engineer/Manager [1]
- Cloud Platform Architect [2]

除要求具備 CI/CD 的經驗之外，根據提供的JD訊息可以推測台積電正在架設 in-house infra 也包含了公有雲、私有雲建置，使用的雲平台技術包含最近非常紅的容器編排平台(Containers Orchestration) 也提到了Kubernetes/Docker 可見容器平台管理技術也在硬體公司受到青睞。

此外還有提到需要SDN(Software Defined Networks) 及SDS(Software Defined Storage)等進階的技術，或許在 Kubernetes 上能以 CNI/CSI等方式實現。

大型的半導體公司開始在耕耘 Kubernetes 人才市場這塊，新創軟體公司如果也需要此類人才也應該提高待遇去應對。

對TSMC其他軟體相關職位有興趣的可以參考 [3]

[1] https://tsmc.taleo.net/careersection/tsmc_exti/jobdetail.ftl?job=1900003U&tz=GMT%2B08%3A00&tzname=Asia%2FTaipei

[2] https://tsmc.taleo.net/careersection/tsmc_exti/jobdetail.ftl?job=1900003W&tz=GMT%2B08%3A00&tzname=Asia%2FTaipei

[3] https://www.tsmc.com/static/english/careers/online_recruitment/indexTC.html

#kubernetes1.20 #dockerbye

隨著 kubernetes 1.20 相關消息愈來愈多，目前一個引起廣泛討論的就是 docker support 將被標示為棄用，並且於未來版本的中將正式移除。

到底這個未來的改變對於開發以及維運人員來說，到底會有什麼樣的衝擊，這邊就來跟大家分享一下我的看法。

❗ 開發人員

Q1: 我需要重新學習新的工具嗎？ 能不能繼續使用 Docker?

A1: 大部分情況下，你不需要重新學習任何工具，可以繼續
使用 Docker 作為本地開發，你產生的 Image 依然可以讓 Kubernetes 去運行。

Q2: Kubernetes 一旦不支援 Docker，那我的 Image 還可以放 Docker Hub 嗎?

A2: 這個沒有問題，因為目前的 Container Registry 都基於
OCI 標準來設計，因此格式相容的情況下， Kubernetes 是可以繼續使用 Docker Hub 上的 image.

Q3: 我的開發環境是 Mac，使用的是 Docker for Desktop 並且用 Docker 內建的 Kubernetes 來開發，請問我會被影響嗎

A3: 這個開發環境比較特別，可以讓 docker build 產生的 image 直接給 kubernetes 使用。一旦 Kubernetes 底下使用別套，也許這條路徑會出問題。 因此這個問題值得關注。

❗維運人員

Q1: 我的公有雲 Kubernetes 服務會被影響嗎？

A1: 三大公有雲目前都有提供除了 Docker 以外的解決方案，可以參閱相關文件來切換。
如果已經使用 containerd/cri-o 這些解決方案的話，基本上什麼都不用做。但是如果本來使用的是 docker 的話，那就要注意一下你的服務提供者有沒有提供轉移方式。

Q2: 自架 Kubernetes 會被影響嗎

A2: 這取決於你的使用方案，譬如你使用 Rancher 的話，預設是使用 Docker，因此勢必未來一定會有一波轉移問題要處理。
另外如果 Kubernetes 節點是由自己處理的，那要注意需要自行安裝其他的 Container Runtime。單純只有安裝 docker.io 是不夠。

Q3: 維運上會有什麼改變?

A3: 未來若 k8s 不再支持 docker，勢必你將不能於節點上使用 docker 這個指令來觀察相關的運行資訊。這部分可能需要改用 ctr 或是 crictl 等不同的 CLI 工具來觀察。
全新的工具，全新的用法勢必需要學習

Q4: 這樣切換有什麼好處?

A4: 不論是切換到 Containerd 或是 CRI-O ，效能上會提升，與資源消耗會下降，整個容器處理流程也會變得更加精銳

❗結論

1. Kubernetes 不是 Docker 管理平台，是容器管理平台。定義 CRI 標準就是為了支援多種容器技術。

2. Docker 被移除是可以考慮的，未來我認為 CRI-O 都有可能變成預設解決方案，因為其本身的設計就是為了 K8s 而最佳化，同時也與 Kubernetes 版本對齊，

3. 1.20 只是警告，將要退役，並不代表完全移除。但是不久的將來就會正式移除。

4. 如果有時間，就提早進行準備，永遠都不要到最後一刻才決定處理。大量仰賴 Open Source 的情況下，每個專案的開發能量也都很重要，一個不再維護的專案用起來會很令人提心跳膽。

本篇文章著重於 Terraform 的實戰使用，將 Terraform 這種 IaC 的工具給整合到 Pipeline 系統中，透過 CI/CD 的概念讓 Terraform 來幫基礎建設達到自動更新。

作者使用 Azure 雲端環境作為範例，搭配 Azure DevOps 與 Terraform 來搭建出基於 Infrastructure 的 CI/CD 實作範例。

以下節錄自文章結論
1. 除了 Terraform 之外，其他的 IaC 工具譬如 Ansible, Pulumi 等也都可以搭建出這種 IaC x CI/CD 的模式，當然大部分的雲端服務商也都沒有問題。作者列出了這種模式下帶來的好處
2. 針對 Infrastructure 的改變，可以更輕鬆的再測試環境測試，而且整個架構也相對於彈性，可以加入更多的測試來確保架構改變後，整體服務不受影響
3. 透過測試的步驟，可以確保任何失敗的修改都只會停留在 Testing 的環境，而不會直接更新正式生產環境。
4. 透過 pipeline 的架構，更容易實現 Singe source of truth 的精神，所有 Infrastructure 的修改都要從程式碼著手，並且經由 Review 來確保品質，同時當正式生產環境有出現問題時，也更容易地去發覺到底是什麼修改造成問題。
5. 程式化的執行減少的人員操作的失誤，同時也提供了運行結果的一致性，未來有問題發生時都可以重複執行pipeline來除錯與驗證。
 

https://blog.ardanis.com/ci-cd-for-infrastructure-7d9553b32be0

談論到如何對生產環境進行升級更新時，總是會有幾種方式不停的被討論，譬如 Rolling, Recreate, Blue-Green, A/B, Canary 及 Recreate。 每種策略方法都有其適合場景，底層需要的技術也完全不同，所以使用上除了評估情境之外，也要看看目前團隊現有的工具是否達到你想要的更新策略。

本篇文章要介紹的是 flagger 這套由 weave network 工具，作者於文章中一步一步的介紹如何透過 flagger 來達成 Canary(金絲雀)部署策略。

另外如果你本身是採用 flux 來作為 GitOps 的解決方案的話， flagger 與 flux 出自於同個團隊，因此相關的整合與官方教學文章會更多，有興趣的也可以看一下。

文章的範例清楚簡單，一步一步的介紹使用方式，並且透過不同的情境，譬如更新成功，更新失敗來展示一下 flagger 的部署情況，同時也提到可以透過自定義 Prometheus Exporter 的方式來幫你的應用程式定義什麼叫做服務正常，藉此讓 Flagger 幫你達成 Canary 部署。

有興趣的記得點選全文觀看

https://medium.com/expedia-group-tech/flagger-canary-deployments-on-kubernetes-94364146ff94

過去服務提供者都很喜歡談論 SLA，而現在，更多的討論則是 Service Level Objectives (SLO)。 今天要介紹的文章是個入門文章，帶領大家用簡單的範例來學習什麼是 SLO，裡面牽扯到哪些概念以及元件，以及最後該如何跟相關的監控解決方案整合，來達到提醒與通知的效果。

重點整理
1. 文章使用 Prometheus + Linkerd + Grafana 來示範
2. 如何安裝 Linkerd 以及基本驗證
3. 介紹失敗預算 (Error Budget) 的概念，除了文字敘述之外，還有用實際 PromeQL 的範例
4. 將上述 Error Budget 的資訊給整合到 Grafana 達到更方便的追蹤當前 SLO 的程度

文章內還有提及其他文章來介紹 SLO，連結如下
https://buoyant.io/2020/09/24/service-level-objectives-for-kubernetes/


https://www.cncf.io/blog/2020/11/13/a-guide-to-setting-up-kubernetes-service-level-objectives-slos-with-prometheus-and-linkerd/

對於 CD 操作來說，機密資訊管理一直以來都是重要的議題，我們都知道 Kubernetes Secret 本身只有編碼，沒有加密，因此要如何安全的管理這些機密資訊是個不可忽視的挑戰。

本篇文章採用的是 Helm Secret 的方式來處理這些機密資訊，Helm Secret 本身是基於 Helm Plugin 的架構而開發的，整體使用上就是基於 Helm Chart，這也意味者如果你採用的原生的 Yaml 格式，或是使用 Kustomize，那本篇的內容可能就對你沒太幫助。

作者強調本文不介紹太多關於 Helm Secret 的安裝與使用，相反的，透過一個範例來介紹 Helm Secret 的使用範例，並且針對每一個步驟都有經驗分享，避免大家踩雷

除了 Helm Secret 之外，其實也有非常多的套件再解決這類型的問題，而每個解決方案所採用的架構都不同，有集中管理，有將解密階段移到 Kubernetes 內，各自都有使用者，有機會的話可以每套都玩玩看，看看彼此的差異性與好處。

https://medium.com/@Devopscontinens/encrypting-helm-secrets-7f37a0ccabeb

今天這篇文章主要是探討常見的架構模式，這些架構模式並非侷限於特定的領域或是軟體，而是一個日積月累根據需求而產生的用法。作者開宗明義就說 "A pattern is a solution to a problem in a context."，所以可以想成，每個模式都有針對性，專門用來解決某些脈絡下的問題，
因此本篇文章就針對這個概念介紹了六種不同的架構模式，每個模式都會包含
1. 脈絡情境介紹
2. 遇到什麼問題
3. 可以怎麼採用相關架構模式解決
4. 可能的痛點與缺陷

探討的模式有

- Layered Architecture
- Pipe and Filter
- Client Server
- Model View Controller
- Event Driven Architecture
- Microservices Architecture




文章內容篇長，大概 10min 的閱讀量，推薦吃飯時可以搭配一起看看，有興趣的記得點選下列全文閱讀

https://levelup.gitconnected.com/software-architecture-the-important-architectural-patterns-you-need-to-know-a1f5ea7e4e3d

就是今天！21:00 會進行一場Kubernetes 未來移除Docker runtime 的議題座談，歡迎各位參加！

https://www.meetup.com/CloudNative-Taiwan/events/275020442/

Meetup連結：https://redhat.bluejeans.com/629862972

本篇文章要來探討 Kubernetes/Docker 一些關於 connection timeout 的事情，文章非常長，這邊幫大家重點整理

1. 跟我之前分享的 DNS timeout 問題類似，都會踩到 Kernel 的 race condition，都是 __ip_conntrack_confirm 這個人丟掉大家封包的
2. 本文著重於怎麼發現這個問題，如何減緩這個問題。對於喜歡研究細節的人值得一看。
3. 2017年底作者團隊開始將服務遷移到 Kubernetes (v1.8), Flannel(1.9.0)，開始發現團隊中基於 Scala 的應用程式出現封包 timeout 的問題，這導致部分請求回應都延遲1-3秒
4. 決定認真調查網路問題，經由研究與錄製封包後發現 TCP 重送(SYN)的現象，該現象導致第一個封包會特別慢
5. 接下來要縮小範圍，使用環境中的一個VM作為基底，上面安裝 docker，開始觀察相關的網路流量與封包，發現可以重製這個行為，第一個封包從容器出去後，宿主機上面的真實網卡卻看不到，直到下次第二個封包就可以。藉由這個行為他們判斷，問題出在VM上，跟底層其餘硬體架構無關，藉此縮小問題範圍。
6. 介紹 iptalbes + SNAT + conntrack
7. 問題發生在 Kernel 裡面針對 SNAT 去選擇對外 source IP 時會出錯，因為(1)挑選一個適當的 source port, (2)將該紀錄寫到 conntrack 這兩個步驟中間會有落差，因此如果兩個封包同時進入(1)，選到一樣的結果，後續要跑(2)就會有一個人寫不進去，導致封包被丟棄
8. 一種解決方法是告訴 kernel 請隨機幫我挑選對外的 source port, 這樣就算大家同時執行(1)，有很大的機會會挑到不同的 source port，藉此減少衝突的機會。
9. iptables 執行 --masquerate 的時候可以下 --random-fully 這個參數
10. 團隊當時客製化 Flannel 來解決這個問題


註: 對 SNAT 有興趣瞭解的可以參考我之前撰寫的 SNAT Kernel 原始碼閱讀文章
https://www.hwchiu.com/iptables-masquerade.html
https://www.hwchiu.com/iptables-masquerade-handson.html

https://tech.xing.com/a-reason-for-unexplained-connection-timeouts-on-kubernetes-docker-abd041cf7e02

今天這篇文章的內容比較主觀，是作者列出自己認為 DevOps/SRE 2021 需要注意的工具

1. Managing Cloud Services via Kubernetes CRDs.
三大公有雲廠商目前也都推出透過 CRD 的方式來管理 Cloud Services，譬如 AWS Controllers for Kubernetes, Azure Service Operator, GCP Config Connector。一旦這些工具逐漸成熟，管理人員可以使用管理 kubernetes 的方式一併來管理相關的雲端資源。

個人看法:目前大家習慣用 Terraform, Ansible 等 IaC 等工具來管理，如果往這個方向走去，等於就是逐漸使用一個方式去管理一切。
此外也滿好奇最初的 Kubernetes Service Catalog 搭配 Broker 的方式其實也已經可以用 Yaml 等方式來管理雲端資源了，沒有仔細看 Service Catalog 目前的發展狀況，這兩者的差異有哪些

2. Pulumi
Terraform 作為 IaC 工具的龍頭老大勢必會有挑戰者對其虎視眈眈， Pulumi 這家公司就是挑戰者之一，該公司的產品提供的 IaC 工具能夠採用常見的程式語言來撰寫，避免所有開發者都要額外學習全新的 DSL。此外 Pulumi 今年度也有推出自己的 GitOps 相關工具，不過儘管如此，目前其使用社群都還是不及 Terraform.

個人看法: 當 CDK + Terraform 整合逐漸穩定後， Pulumi 的特色就會減少一項，這場戰爭目前還是看好 Terraform

3. Terragrunt & TFSEC
Terraform 因為其開放原始碼社群的緣故，有愈來愈多的整合工具來幫忙 Terraform 去處理不同的議題，這種合作模式會讓 Terraform 的功能愈來愈強大。 Terrafrunt 則是一個用來管理大型 Terraform 專案的好工具，能夠幫助開發者更友善的管理眾多設定檔案。此外 TFSEC 則是一個針對安全性議題的整合工具，幫助開發者透過靜態分析的方式去檢查當前 Terraform 的內容是否會有潛在的安全性問題。隨者 DevSecOps 的概念慢慢出來，開發與維運者也要多注重些關於安全性的整合工具。

4. Tekton
CI/CD 市場上能夠選擇的工具實在太多，而 Tekton 則是一個基於 Kubernetes 的 CI/CD pipeline 系統，相對於大部分的系統是透過單一 Yaml 去描述 Pipelin， Tekton 則是透過 CRD 的方式於去定義每個 Stage，其帶來的好處就是相同的 stage 可以重複利用，不需要針對每個 pipeline 都去重新設計

個人看法: Tekton 的架構有好有壞，隨者所有的 stage 都變成單一小CRD，管理者想要一目瞭然整個 pipeline 變得非常繁瑣，使用上也常搭配 JenkinsX 來提供複雜的 CI/CD 功能

5. Trivy
如同前面提過，DevSecOps 的概念出來後，任何部分都要去考慮安全性，而 Container Image 本身也是個不容忽視的地方。因此也有不少的開源專案針對 Container Image 來進行掃描與偵測。有些 Contianer Image Registry 直接整合相關的掃描工具，自動掃描所有更新的 Image 並且提供報告給管理人員。 掃描工具諸如 Trivy, Falco, Clair, Anchore Engine 等都值得大家多多注意。

6. ShellCheck
儘管現在有愈來愈多的工具幫助開發者來管理整個叢集，然而 shell script 的定位還是不可動搖，太多時候我們還是需要自行撰寫相關的 shell scrtip 來完成一些任務。 ShellCheck 則是一個針對 shll script 的靜態分析工具，透過 lint 與常見錯誤等分析，讓開發者能夠寫出有更好品質且更好維護的 shell script.

7. Litmus
2011 Netflix 提出 Chaos Monkey 這類型的環境檢測工具，這方面的議題就沒有減少過，即是到了充滿 Kubernetes 的今日，還是有不少的開源專案或是商業平台在提供這方面的服務，譬如 chaoskube, kube-monkey, PowerfulSeal 以及 Gremlin.
作者這邊想要強調另外一套更容易使用且容易擴充的專案 Litmus，該專案基於 Kubernetes Operator 的概念去開發，透過 ChaosEngine, ChaosExperiment 以及 ChaosResult

原文: https://medium.com/dev-genius/technologies-tools-to-watch-in-2021-a216dfc30f25

Kuberentes 支援的運算資源種類繁多，諸如 Pod, Job, ReplicaSet, DaemonSet, Deployment 以及 StatefulSet.
其中 StatefulSet 則是特別針對 stateful 應用程式所設計的，實際使用上會有些許小地方與 Deployment 用法不同，譬如
1. Storage 使用的是 Template 的概念，希望每個 StatefulSet Pod 可以綁定固定的 PV
2. 名稱採取流水號設計，相對於 Deployment -> ReplicaSet -> Pod 兩層亂數來說， StatefulSet 的名稱更加顯眼
3. StatefulSet 的 Pod 有網路存取唯一性，搭配  Headless Service，就可以使用固定一組的 DNS 名稱來存取固定 Pod(預設情況下，Pod 重啟 IP 就會不同，要做到固定一致需要不少修改)

今天這篇文章算是一個入門教學文，主要是跟大家探討什麼是 StatefulSet，以及於 Kubernetes 內該如何使用，使用上有什麼要注意的，以下幫大家節錄部分資訊

1. StatefulSet 的設計是安全優先，所以預設情況下刪除 StatefulSet 不會連帶刪除使用的 Volume
2. 使用 StatefulSet 的時候，要記得處理當 Pod 被停止，被刪除時，相關資料的寫入與同步
3. 預設情況下, StatefulSet 的創建與移除都是一個一個來，創建時由 0-N-1, 移除則反過來。
4. 對於多節點的 StatefulSet 來說，這些應用程式可能都會需要一些初始化的操作，甚至 leader-election 等相關算法。這意味者 Container(s) Running 不等於 Pod 以及準備好了。
5. 針對上述概念，使用者一定要仔細的去設定 liveness 以及 readiness，來確保
6. PostStart/PreStop 的用法與時機也要考慮進去，特別是 PreStop 用得好還可以減少使用端封包無故重送
7. 研究 disruption budgets 的用法，來確保你的 StatefulSet 運行得更安心
8. 針對特定的儲存空間使用權限問題，可以考慮使用 fsGroup 來修改，而不用自己寫一堆 shellScript 來做。當然要注意儲存空間檔案過多內容過大的情況，預設的 fsGroup 行為可以會導致你的 Pod 花太多時間來啟動

原文: https://itnext.io/stateful-applications-in-kubernetes-808a60bc109

想學習更多關於 Kubernetes 的實戰經驗與基礎設計，可參閱我的線上課程: https://technologynoteniu.github.io/awesome-notes/linux/network/