這次跟大家分享一個有趣的反面議題，探討 GitOps 部署策略所帶來的痛點與負荷，本文主要內容翻譯自 Container-Solutions 的原始文章，已獲得原作者同意

原作者列出了數個實際採用 GitOps 遇到的麻煩與痛點，並講述期望的解決方案，最後則提供了一些不同的開源軟體來讓大家去嘗試

如同我不停強調的就是沒有最好的解決方案，只有最適合你環境的解決方案，我們要培養的一直都是如何分析自己的情境，找到對的工具並整合，一昧的追求最新最潮流的東西往往不會是最穩定且最有用的。

有興趣的人可以點選本文內的連結來瞭解更多原作者的思考 https://www.hwchiu.com/gitops-bad-and-ugly.html

CNCF 使用者社群 (CNCF End User Technology Radar) 今天針對可觀測性這個議題發布了九月份的報告，
是針對幾個常見的技術分析投票結果，看看不同的產業公司對於這些軟體是什麼樣的態度
主要分成已經 Adopt, Trial, Assess 三個不同的等級來幫每個專案/產品評論

如果你目前正在觀望各種工具，快來看看大家怎麼說

重點整理
1. 最常被使用的工具都是開源專案
2. 目前沒有一個一統天下的工具，大部分使用者都是會用多項工具一起
3. Prometheus 與 Grafana 通常會一起使用
https://radar.cncf.io/2020-09-observability

跟大家分享一個由 CNCF 組織所發起的 CD 工具調查報告
面向的使用者都是 CNCF 社群的廠商，主要針對各種廣為人知的 CD 工具給予評價，大致上就是推不推薦使用

在 Kubernetes 應用程式部署工具方面, Helm > Kustomize > Jsonnet
至於對於 CD 系統的選擇各有秋色，不論是開源軟體或是 SaaS 服務都有上榜
其中正反意見最多，完全看不出共識的就是我們的老牌 Jenkins, 將近一半的受訪者都推薦停止使用 Jenkins.

有更多興趣可以點選下列文章來閱讀，有興趣也可以到粉絲團留言討論
https://www.hwchiu.com/cncf-tech-radar-cd.html

YAML Templating 工具生態現況

不知道大家是否都有使用 Network Policy 來設定 Kubernetes 內部的 ACL?

這邊有個叫做 OPA 的工具可以用幫你驗證你的 Network Policy 是否運作良好，甚至當有新的應用服務要部署的時候，也會確定是否有跟 Network Policy 衝突
有興趣的人可以研究看看

https://www.cncf.io/blog/2020/09/09/how-to-enforce-kubernetes-network-security-policies-using-opa/

#小編 #深夜讀物

一篇關於 Service Mesh 的好文，發布已經有段時間了不過還是值得一讀， 文章作者是非常早期 Service Mesh 項目: Linkerd 的核心開發成員之一也是新創公司 Buoyant 公司的 CEO。
相信大家應該對於 Service Mesh 一詞已經不陌生，可能對於這個名詞比較熟悉的朋友大多是從另一個 Service Mesh 項目: Istio 去了解 Service Mesh 的面貌，從這篇文章你可以從不同觀點認識 Service Mesh ，全文非常長內容涵蓋
• Service Mesh 詳盡介紹
• 為什麼 Service Mesh 可以被施行？
• 為什麼 Service Mesh 是個好的 idea (比起其他方法)？
• Service Mesh 幫助了什麼？
• Service Mesh 有解決掉所有問題嗎？
• 為什麼在現今 Service Mesh 可以被施行？
• 為什麼人們那麼愛談論 Service Mesh？
• 身為一個謙虛的開發者需要關注 Service Mesh 嗎?
• 一系列F&Q

這裡對 Service Mesh 的需求做個小結，Service Mesh 帶來了三大好處：
1. Reliability: 包含提供請求重試、超時、金絲雀部署(Traffic shifting/splitting) 等功能
2. Observability: 包含提供請求成功率、延時、粒度到個別服務等級的請求量、個別服務等級路由、服務等級拓墣圖等功能
3. Security: ACL 及 Mutual TLS (客戶端及服務端互信）

值得一提的是，本篇作者 William Morgan 對於 istio 持負面的態度，並不是因為 istio 與 linkerd 處於競爭關係的兩個產品，而是對於 istio 在 service mesh 做了太多的商業性 marketing 操作（大部分來自Google的操作)

文章來源: https://servicemesh.io/

有興趣的朋友也可以在 Podcast 上聽到作者在 Podcast 上的訪談: https://reurl.cc/N6GbW9

從 Gitlab 出發探討 GitOps 的概念，有興趣的可以閱讀這篇由 Cheng Wei Chen 於 ITHOME Cloud Edge Summit 2020 的精彩分享

https://blog.chengweichen.com/2020/09/from-devops-to-gitops-with-gitlab.html?fbclid=IwAR3gJJZ_J3hsX7rOJ6MYcIOoDuqwuz2J3xLJxANnvIsvkhra02UfzktjC9Q

七個邁向 Cloud Native 的挑戰!!

本篇文章列出了七個企業想要踏入 Cloud Native 之路上最常遇到的問題
以下幫大家總結並節錄一點小內文
1. 過於緩慢的發布週期
創新需要有能力很快速地針對每次的修改去快速發布。

2. 使用過時的技術
作者認為時時關注當前這個迅速發展的世界是非常重要的，特別是的相關開源專案。

3. 綁定特定服務供應商且成長方面缺乏彈性
當服務與特定廠商的解決方案綁定太深時，很容易遇到所有功能都由該廠商綁定，想要做什麼都會綁手綁腳。

4. 缺乏專業性人才
根據 2019 一篇調查，只有 7% 的 IT 主管再招聘與慰留人才方面沒有遇到困難

5. 安全性
人們總是當問題發生的時候才會開始注意安全性的問題，但是往往這些問題的代價都很高。儘管安全防護是一個複雜且困難的領域，但是擁有一個資安的實踐守則還是非常重要。

6. 過高的運營與技術成本
滿多企業都會使用雲端服務來減少自行維護伺服器所需的成本，然而 Cloud Native 的環境常常會用到各式各樣的元件，這些元件所消耗的成本都會隨者規模放大而有所影響，如何去最佳化你的雲端資源使用量來盡可能的減少你的花費也是一大挑戰

7. Cloud Native 的概念難以溝通
Cloud Native 的觀念難以溝通與理解，對於任何想要導入 Cloud Native 到團隊中的企業來說，領導團隊必須要先理解到底這些解決方案的重要性與複雜性。
甚至可能還會因為微服務，容器等其他概念的認知不同而花時間理解。


https://www.cncf.io/blog/2020/09/15/top-7-challenges-to-becoming-cloud-native/

這次帶來一篇 CNI 效能的文章分析，該文章介紹不同 CNI 基於 10G 網路下的效能評比，詳細請點下方連結參閱全文，
以下節錄重點

1. Kube-OVN 不但資源吃很多，效能還很不好
2. Canal/Calico/Flannel 三者的運算資源使用量都不多，且效能都很好
3. Kube-Router 的效能都很差，資源使用方便也不是特別出色
4. WeaveNet 與 Cilium 效能都不差，但是 Cilium 吃的效能很高，可說跟 Kube-OVN 同等級，而 WeaveNet 用到的資源少
5. 這次的實驗評比我認為其實能看到的東西有限，主要是不同的 CNI 所搭配的解決方案不同，目標要配合的情境也不同，雖然從圖表中可以看到 Kube-OVN 的綜合評比最差，但是其要用的場景本>身就不太一樣，單純用最原始的流量互打來判別優劣其實不太對
6. 如果今天要選擇網路 CNI 的時候，可以看到效能跟資源方面， Flannel/Calico/Canal 幾乎等級都差不多，而且 Calico 還支援加密與 Network Policy 等功能。
7. 此外，目前 Flannel 也從 Kubeadm 的官方教學頁面中移除，因為太多問題且維護者沒有要修復。所以我認為如果沒有特別使用情境需求的話，可以考慮使用 Calico.
8. Cilium 對於安全性以及 load-balancing 方面也有別的功能，就如同(5)點所提到，不同的場景有不同的需求，有些功能是獨占的。

https://www.hwchiu.com/cni-performance-2020.html

這篇分享一篇非常有趣的問題，從 Container 的實作開始介紹，最後介紹幾個與 Container 相關的 CVE
對於資安有興趣的可以研究看看

https://teamt5.org/tw/posts/container-escape-101/

這邊跟大家分享一個有趣的入門文章，介紹各種不同部署方式的差異，譬如Ramped, A/B, Green/Blue, Shadow, Canary 等等

每個更新方式帶來的效果不同，同時需要的環境建置也不同，這部分還會影響到整體的預算成本，最後還有一張簡易的表來快速介紹其差異性，有興趣的可以看看

https://thenewstack.io/deployment-strategies/

由 Cloud Native Taiwan User Group 所持續推動的每月線下活動又來囉，本次內容包含了近幾年與底層非常熱門的 eBPF 以及透過講者所開發的開源專案，KubeFire, 其透過 Firecracker 這個方式來創建並管理一個 Kubernetes 叢集

該次議程地點為台北天瓏書局，同時當天也會開放線上直播，讓不克前來的社群朋友一起參與，會後也會有相關錄影。

請點選下方連結來瞭解更多
https://www.meetup.com/CloudNative-Taiwan/events/273340386/

想必大家一定都有使用過 CPU Limit 的經驗，透過這個機制能夠確保每個 Container 使用的 CPU 資源量，也可以保證每個節點上面會有足夠 CPU 供 Kubernetes 原生服務 (kubelet) 使用。

然而本篇文章就要來跟大家分享一個設定 CPU Limit 反而造成效能更差的故事，故事中當 CPU 設定為 800ms 的時候，卻發現實際運行的 Container 最高大概就只有 200ms 左右，這一切的一切都是因為 Liniux Kernel 的臭蟲導致!

一個直接的做法就是針對那些本來就沒有過高 CPU 使用量服務取消其 CPU Limit，作者於文章中也探討了一些機制要如何保護與應對這些被移除 CPU 限制的服務。

這個臭蟲於 Linux Kernel 4.19 後已經修復，但是要注意你使用的發行版本是否有有包含這個修復，作者列出一些已知的發行版本修復狀況

Debian: The latest version buster has the fix, it looks quite recent (august 2020). Some previous version might have get patched.
Ubuntu: The latest version Ubuntu Focal Fosa 20.04 has the fix.
EKS has the fix since December 2019, Upgrade your AMI if necessary.
kops: Since June 2020, kops 1.18+ will start using Ubuntu 20.04 as the default host image.
GKE: THe kernel fix was merged in January 2020. But it does looks like throttling are still happening.

有興趣的歡迎點選原文閱讀更多

https://erickhun.com/posts/kubernetes-faster-services-no-cpu-limits/

一篇關於 Kubernetes 入門的影片，100 秒快速介紹 Kubernetes, 整個流程非常的快
有興趣的可以看看別人是如何介紹 Kubernetes，同時也可以想想如果今天要跟別人介紹
Kubernetes ，自己有沒有辦法講出連你阿嬤都聽得懂的 Kubernetes

https://youtu.be/PziYflu8cB8

這邊跟大家分享一下牛自己於矽谷遠端六個月的心得與觀察，從不同面向去探討遠端工作帶來的好處與壞處，同時分享一下美國這邊對於遠端工作的看法與大公司的政策，最後則是根據自己過往台灣的工作經驗來試想一下導入全面遠端工作於台灣企業的困難性


https://www.hwchiu.com/covid-wfh.html

昨天晚上的線上活動已圓滿結束，相關資源如下
活動錄影: https://www.youtube.com/watch?v=5JhQOjSSnzQ
投影片:
https://www.slideshare.net/.../introduction-to-cri-and-oci

Terraform 這個工具想必大家都玩過也聽過，這邊非常推薦大家升級到 0.13 版本，這個版本中解決了關於 Module 之間依賴性的問題，能夠使用原先就有的 depends_on 的語法來直接描述，而不需要按照過往以前用各種 fake resource 等機制來完成，整個 Terraform 程式碼會更佳清晰與簡單!

https://medium.com/hashicorp-engineering/creating-module-dependencies-in-terraform-0-13-4322702dac4a?utm_content=buffer50deb&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer&fbclid=IwAR2ksR64Vmu_3Zy6FAZ4ObbemFsaSMiKy3gabDgwq4bbl3SUc7gBlxIUAzk

#小編

有沒有遇過gRPC 在Kubernetes 上的 Load Balance 效果不佳的問題？這篇文章將分析幾種常見gRPC LB的作法也提出一個開箱即用的方案，引入的成本低非常適合想立即在 Kubernetes 上使用 gRPC LB的團隊。

註：第一次使用Telegram 的 telegraph 寫技術文章，在Telegram上閱讀體驗還算不錯。未來會陸續把技術長文放進去 telegraph

https://telegra.ph/In-cluster-gRPC-Load-Balancing-09-28

#小編

本篇討論如何使用 Envoy 2步驟為 Kubernetes 上gRPC 應用做負載均衡

https://telegra.ph/Envoy-as-a-gRPC-Load-Balancer-in-Kubernetes-09-30

想必大家應該都聽過 Operator 的概念，透過 CRD 自定義資源格式並且配上程式化的運作邏輯來控管相關資源的操作。甚至有廠商針對 Operator 的概念來設計一個 Framework 讓大家能夠更輕鬆或是有效率的撰寫屬於自己的 Operator。
然而 Operator 真的一定好嗎? 底下這則推文則是來自於 Darren Shepherd(CTO/Co-founder Rancher Lab ) 對於一篇由 RedHat 所發表關於 Operator 好處文章的反面看法。
其推文最後表示:「Right now invest your IT teams time in GitOps, not operators.」

快來看看 Darren 與其他網友針對這些議題的討論，並且分享看看你的想法

https://twitter.com/ibuildthecloud/status/1295810776179961856