恭喜 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/

本篇文章的標題很聳動，看起來是要人完全放棄 Docker，實際上則是詳細的跟大家介紹 Docker 生態系中各種潛在的替換工具，這個生態系主要可以分成 Container Engines, Building Images, Container Runtime 以及 Image Inspection and Distribution.

文章內容偏長，但是偏向系統與概念的去介紹，也是非常推薦吃飯時的良好讀物。
這篇就簡單重點整理一下，詳細的還是請點選全文去觀看

1. Container Engines
作者列出了幾個競爭對手，譬如 podman, lxd, cri-o 以及 rkt. 不過介紹都是以 podman 為主，其特色有(1)daemonless, (2) non-root container, (3) 支援 pod 的概念
此外 podman 的指令完全相容於 docker，因此也可以透過 aliase docker=podman 的方式去運行。

2. Building Images
這邊提到了 Buildah, Kaniko 以及 buildkit.
Buildah 是由 RedHat 所推廣的開源專案，天生整合到 podman 裡面，而 Kaniko 則是 Google 所推出的解決方案，主要應用場景是於 Kubernetes 內建置 contianer image。最後 buildkit 則是 moby 目前開發的下一代 docker build 解決方案，期望能夠提供更多的功能及來提升建置的效率

3. Contianer Runtime
這邊的選擇性列出兩個，最常使用的 runc 以及 RedHat 開源的 crun，兩者都遵循 OCI 標準，因此上述的 Container Engine 都必須要可以輕鬆的於兩者之間切換。

當然除了這些之外，還有不同的 Contaienr Runtime，譬如 gVisor, Kata Container 等安全性更高的解決方案。


4. Image Inspection and Distribution
這邊則是提到了 Skopeo，一樣是由 RedHat 所推廣的開源專案，Skopeo 甚至支援同步不同節點的 Container Registry 而不需要將其內容可複製到本地端，使用上有滿多有趣的功能。

此外還有一個叫做 Dive 的工具也非常棒，能夠幫你檢視 Docker Image 每一層的內容，譬如使用的空間大小等，讓你有機會好好的認識你的 imagea。





原文: https://towardsdatascience.com/its-time-to-say-goodbye-to-docker-5cfec8eff833

今天這篇文章探討的是 JVM 於 Kubernetes 下的使用經驗，對於基於 JVM 的應用程式來說，其需要一點暖身時間，暖身完畢以前，這些應用程式沒有辦法發揮百分百的能力去處理流量與請求，這樣的概念導入到 Kubernetes 後就會使得事情惡化。當今天發現過多流量近來，需要動態產生新的 Pod 來分攤流量，然而這些 Pod 都還在慢慢暖身，這些暖身過程會導致對應的請求時間變得非常長，甚至 timeout。

因此作者要跟大家分享他們團隊是怎麼處理這個問題，嘗試過哪些手段，哪些有效，哪些無效以及這些過程中到底學到了什麼

1. 第一次遇到這個問題時，團隊沒有太多心力去研究，當下解法就是，那我就開更多的 Pod，繼續降低每個 Pod 可能要負責的請求數量 (RRM)。經過團隊測試，這種方式奏效但是帶來的資源浪費的問題，團隊最後部署的資源量是真正理想情況下的三倍之多，這意味者用三倍的金錢，來處理一倍的請求量。

2. 階段二中，團隊打算嘗試增加一個 Warm-up 的腳本去發送一些流量，期盼這種機制可以加速暖身機制。該做法同時也要修改 Readiness 來確保 Warm-up 完成前 Readiness 不會讓真實流量封包導入到 Pod裡面。結果來說，是個不管用的效果，有一點點的長進，但是帶來更多的問題，譬如一個 Pod要花三分鐘 才可以起來，結論就是弊大於利

3. 階段三中，決定從 JVM 本身開始研究起，發現提升 CPU 的資源量可以明顯地縮短暖身時間，讓這些 Pod 可以更快的加入戰場服務。根據作者團隊的觀察，過往使用 1000m 的 CPU 使用量，大概需要 5-7 分鐘的暖身時間，透過將 CPU 使用量提升到 3000m，能夠將整體時間縮短不到 4 秒，效果顯著。因此提升 CPU 使用量就是一個可行的解決方案。 然而因為過往採用的是 Guareanteed Class 的 QoS 設定 (limited == request)，這樣 3000m 的CPU 使用量反而會造成資源浪費，最後造成節點不夠觸發自動新增節點的機制，然後花更多的錢

4. 重新探索 CPU Resource 的用法，決定採取 Burstable Class 的概念，針對 Limit 設定 3000m, request 則是 1000m，這樣可以確保 Schedule 時會用 1000m 來找資源，系統上有足夠 CPU 時也可以讓 JVM 使用到 3000m.

詳細內容請參考下列全文:
原文: https://tech.olx.com/improving-jvm-warm-up-on-kubernetes-1b27dd8ecd58