今天這篇文章作者跟大家分享一些如何加強 Kubernetes 服務穩定的方式，這篇文章這邊做個簡單摘要一下

發生問題:
作者的 k8s 是基於 Google Kubernetes Service (GKE)的叢集，運作過程中有時候會發現部分節點當掉，最後導致部分的服務不能正確使用。這邊作者團隊從兩個角度出發去改善
1. 研究為什麼節點會一直當掉，與 Google Supporte Team 來回信件最後有找到問題點
2. 強化 Kubernetes 服務的韌性，就算有部分節點壞掉也要讓服務能夠繼續運行
，本文主要的一些觀點也都是基於這邊發展

強化方式
1. 修正 Deployment 的數量，並且加上 Anti-Affinity，讓這些 Deployment 的副本能夠散落到不同的節點上，避免所有 Pod 都塞到同個節點，最後該節點出問題導致 Pod 全部出問題。
2. 所有需要被 Service 存取的服務都加上 Readess Probe 來確保這些服務都準備好後才會收到服務，避免一些請求被送過來確又不能正確處理
3. 加入 Pre-Stop 的使用，再裡面透過 sleep 10的方式，讓 Pod 要被刪除能夠將手上的封包請求給處理完畢

註: 我個人認為第三點其實不太需要，比較漂亮的作法應該是實作 Singal Handler 去處理 SIGTERM 的訊號，收到此訊號後就不要再接受任何 Request 並且把剩下的工作處理完畢，當然如果這部份處理的時間過長，超過預設的 GracePeriod (30sec)，就會被 SIGKILL 給強制刪除。
要解決這個問題可能就要從應用程式下手去看如何改善，或是透過修改 API server 來增加 GracePeroid 的數值

可以點選下方連結來瞭解更多全文，內容不長
https://medium.com/kudos-engineering/increasing-resilience-in-kubernetes-b6ddc9fecf80

今天要分享的是來自 lambda 的團隊根據其多年 Kubernetes 的經驗分享，該篇文章篇長，閱讀可能需要15分鐘左右，這邊幫大家重點整理，有興趣的別錯過完整內容，我個人滿推薦細讀的

# 重點整理
1. 團隊一開始是透過 Ansible + Valut + Consul 來管理整個架構＋應用程式的部署。
2. 作者認為一個非常重要的東西就是， 想清楚你為什麼需要 Kubernetes，不要隨便盲目的使用
3. Kubernetes 的學習曲線非常高，除了 Kubernetes 本身之外，還有很多整合的東西都需要一起學習，譬如 Monitoring, Logging, CI/CD, Secret Management, Tracing 等，每個領域都不簡單
4. Kubernetes 的導入，並非只有營運團隊需要處理，實際上是整個產品團隊都會連帶影響，譬如對於開發者來說，本地開發要怎麼做，本地測試要怎麼做？
CI/CD 如果要考慮 Kuberntees，有哪些部分需要注意？ 應用程式如何打包與上版本？ 更新策略是什麼？ 
這中間有超多的議題需要整個團隊一起學習與克服，才能夠真正享受到 Kubernetes 帶來的好處
5. 轉移到 Kubernets 中間的過渡期很辛苦，同時維護兩種架構，這需要時間去處理，沒有辦法馬上完成，也不可能一步到位
6. 文章中也有提到作者團隊於各領域所採取的解決方案，這邊就大概列一下

Prometheus, Grafana Loki, Vault, Tekton, Argo Workflow, Telepresence, Skaffold,  Kustomize, AWS, Kops


註: 我個人認為裡面最重要的一點就是第二點，任何領域都一定，不要盲目追求潮流，而是要有充分的理由去說服自己為什麼需要使用某產品。對我來說一個很重要的行動準則是，要先說服自己，才有辦法說服別人

https://lambda.grofers.com/learnings-from-two-years-of-kubernetes-in-production-b0ec21aa2814

跟大家分享一個熱騰騰的消息，來自於 CNCF 上面 Apple Inc 的分享
Apple 未來將會將內部的應用都部署從過去的 Apache Mesos 給逐漸轉移到 Kubernetes 上。


# 重點整理
1. Kubernetes 這種 plug-in 的生態系其實對使用者來說非常方便，針對網路，儲存等相關選擇不會再是一次定生死的玩法。任何時刻都可以根據需求重新評估並且不需要整個系統重新打掉
2.. Kubernetes 透過 CRD + Controller 這種概念讓開發者可以存取其 API 來達到很多客製化的功能
3. 要如何讓整個組織內的團隊都採用 Kubernetes 並且使用其學習曲線非常高，對整個團隊帶來的衝擊也是不可忽視
4. 目前內部已經正在嘗試 Kubernetes 想辦法來符合來自於不同團隊的需求，譬如 Jave/Python/Go 的開發者， SRE 團隊， 硬體團隊與機器學習團隊
5. Apple 打算基於 namespace-as-a-service 以及 cluster-as-a-service 來提供環境給不同團隊使用
6. Apple 工程師也積極的參與 Kubernetes 的開發與貢獻，同時也在研究關於 microVM 等技術，希望能夠針對多租戶的應用情況下有所幫助。


註:
1. Kubernetes 透過 CRI/CNI/CSI 來提供彈性的 運算/網路/儲存 選擇
2. 對於  CNCF 來說，Apple 的公開使用是一個令人振奮的消息，愈來愈多的大公司往這邊邁進。
3. 多年前 Linux Foundation 一段演講中提到， Linux 之於作業系統，就如同 Kubernettes 之餘雲端，不知道這件事情會不會發生？

有興趣的點選下文觀看全部訪談

https://thenewstack.io/apple-plans-to-run-most-of-its-compute-management-on-kubernetes/

今天這篇文章是用一個入學者的角度來探討什麼是 Service Account  

基於 RBAC 的使用情境下，我們除了 Role & Rolebinding 外，我們也會需要一個所謂的 Subject 。 

Subject 大抵上可以分成兩類，分別是 User 以及 Service Account，其中 User 比較偏向是給使用者使用的，不論是管理員或是開發者，背後都可以銜接不同的認證方式，來確保當前使用者是經過認證的，接者搭配 Role & Rolebinding 來幫該 User 授權給予相對的存取能力。 

相反地， Service Account 的目標則不是活生生的人類，更偏向 Process 等自動化程式為主，不論是 Cluster 外部的應用程式，或是 Cluster 內的 Pod，都可以透過 Service Account 與 API Server 溝通來滿足認證。 

預設情況下，我們跑起來的 Pod 都會掛上一個 Default 的 Service Account，然而你如果希望你的應用可以有更多的能力去跟 API Server 溝通，就需要考慮幫忙設定全新的 Service Account 搭配特定的 RBAC 規則。 

 本文會針對 Service Account 去簡單介紹，大致上先瞭解什麼是 Service Accont, 什麼情況會使用，要怎麼使用

https://medium.com/the-programmer/working-with-service-account-in-kubernetes-df129cb4d1cc

Infrastructure as Code (Iac) 近來年蔚為潮流，甚至可以說是必備顯學，如何透過系統化的方式去管理架構是個逃不跳的問題，不論是地端環境，或是雲端環境，這類型的需求都不可能少。 Terraform 我個人認為是這幾年來談到 Iac 解決方案中最熱門的選項，其開放的 Provider 架構讓其生態系非常大，能夠透過一套相同的語法來銜接各式各樣的服務提供者。

本篇文章就從入門角度來看待 Terraform 可以怎麼使用，從開發階段到正式上線階段中間，可能會遇到什麼問題，以及這些問題應該怎麼處理，譬如說
1. Terraform 的 Backend Provider 應該怎麼設定，不同設定對於安全性來說是否會有不同的優劣?
2. Terraform 該由誰運行? 到底是一台專屬的開發機器或是說透過 Continuous Integartion (CI) 的過程來運行 Terraform， 這之間各自的好處是什麼
3. Terraform 透過 Module 的方式來達到 Don't Repeat Yourself(DRY) 的架構，而 Module 本身的架構可以有哪些作法，是一個獨佔的 Repository 或是多個？ 這之間的想法有什麼差異

對上述議題有興趣的可以點選全文觀看
https://medium.com/@mike.ensor/terraform-developers-tips-tricks-d5c4be14a553

Docker 網路入門篇最終章
本篇文章延續之前的內容來探討 Docker 的 Bridge 網路模型，這次我們要研究的是到底 docker run -p 12345:80 這種指令背後到底做了哪些事情，除了 iptables 的 DNAT 外，實際上還有一個名為 docker-proxy 的應用程式也被跑了起來。
到底 docker-proxy 是做什麼用的，與 iptables 的關係是什麼，有興趣的可以看看本篇文章。
歡迎留言讓我知道你想要探討學習的任何入門網路議題
https://www.hwchiu.com/docker-network-model-lab-dnat.html

今天這篇文章比較偏向一個範例操作，如何透過 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/