昨天晚上的線上活動已圓滿結束，相關資源如下
活動錄影: 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

#小編

常見 Service Proxy 和 Edge Proxy 分別在 Kubernetes 上扮演什麼角色，而各自的功能又是什麼？
https://telegra.ph/Service-Proxy--Edge-Proxy-10-03

如果有在 Kubernetes 內部署 Java 應用程式的人，千萬不要錯過這篇文章，此文章中分享 Java 應用程式關於 Thread Pool Size 的問題，同時當 Java 應用程式容器化並且部署到 Kubernettes 內之後，該怎麼設定 JVM 來讓其能夠更高效率的於容器化環境下工作
https://mucahit.io/2020/01/27/finding-ideal-jvm-thread-pool-size-with-kubernetes-and-docker/

Rancher v2.5 釋出!

這幾天 Rancher 正式釋出 v2.5 版本，這邊就來重點節錄一些改變
1. 強化與雲端環境 EKS 與 輕量級 K3s 環境的整合，此外宣稱所有 Kubernetes 服務上面都可以安裝 Rancher 用其來幫忙管理
2. 針對美國環境要求而開發更具安全性的發行版，符合 FIPS(Federal Information Processing Standars)
3. 整合 GitOps 部署，針對大規模 Edge 叢集的自動部署解決方案 fleet
4. Monitoring 強化，減少與 Rancher 本身的連接性，反而更加使用 Prometheus operator 來提供服務。管理人員可以直接創建相關的 CRD 提供服務，而這些資訊也都會被 Rancher UI 給一併呈現

其中 (4) 裡面還提供的 cluster-level 的客製化設定，就不需要向過往一樣要開很多個 project-level 的 prometheus 來處理，這方面輕鬆不少


資料來源：
- https://rancher.com/blog/2020/rancher-2-5-delivers-computing-everwhere-strategy
- https://github.com/rancher/fleet
- https://fleet.rancher.io/
- https://github.com/rancher/rancher/issues/23239

於 Minecraft 中玩耍 Kubernetes, 大概是繼 Doom 後另一個有趣玩法了

https://medium.com/@eric.jadi/minecraft-as-a-k8s-admin-tool-cf16f890de42

如果你機會跑過 kubernetes 1.18 版本，一定要試試看最基本的 kubectl get pods -o yaml，看看是不是內容裡面多出了非常多 f:{} 系列的檔案，導致整個 Yaml 變得非常冗長，閱讀不易，甚至想要抓取到最原始的內容都非常麻煩。

Kubernetes 官方 Github 上還有相關的 issue 再討論這個欄位，詢問是否有辦法能夠清除。不少人都提出了一些希望的用法來處理
Issue: https://github.com/kubernetes/kubernetes/issues/90066

目前看下來最簡單的做法還是透過 kubectl plugin, kubectl-neat 來幫忙完成，可以透過 krew 這個 kubectl 管理工具來安裝管理
https://github.com/itaysk/kubectl-neat
此工具可以將 Server 上得到 Yaml 的內容給整理最後得到最初的檔案

至於到底什麼是 managedFiles? 這個由欄位的出現是因為 1.18 以後，已經將 Server Side Apply 更新策略預設啟用而導致的，而 Server Side Apply 則是一種用來管理 Declarative 設定檔案的方式，對使用者來說基本上完全無感，因為一切都還是透過 kubectl apply 來使用，只是到底如何判斷 當前檔案內容與系統上內容誰先誰後，誰對誰錯，甚至當有人透過 kubectl edit 去編輯內容的時候，到底該怎麼更新。

之後有時間可以再寫一篇來詳細介紹 Kubernetes 內的 Declarative 更新策略

#小編

本篇對幾款常見的 Service Mesh 產品做了基本介紹，以及延續之前的議題哪些常見的 Proxy 被應用於 Servie Mesh 實作中作為其 Service Proxy ?
https://telegra.ph/Common-Proxies-in-Service-Mesh-Implementations-10-10

本篇針對 k8s 內部多租戶的挑戰進行一篇文章分享
https://telegra.ph/Kubernetes-%E5%A4%9A%E7%A7%9F%E6%88%B6%E5%AF%A6%E6%88%B0%E7%9A%84%E5%95%8F%E9%A1%8C%E8%88%87%E8%A7%A3%E6%B3%95-10-13

這邊跟大家分享關於 CNCF Radar 9月份的報告，這篇報告主要是針對 Observability 來探討 CNCF 會員會使用哪些工具，以及對這些工具的推薦程度
Observability 通常會被分成三大領域，分別是 Monitoring, Logging, Tracing. 常見的代表解決方案就是 Prometheus+Grafana/EFK/Jaeger, OpenTracking
更多報告內容歡迎點擊下列文章觀看更多
https://www.hwchiu.com/cncf-tech-radar-observability.html

HashiCrop 今天釋出的新工具 Waypoint，一款用來讓開發者也能夠輕鬆部屬測試的工具

Waypoint 提供開發者一個友善的方式，能夠順利的完成 build/deploy/release 這一系列的操作，讓開發者可以直接將開發結果部屬上去，並且觀看相關結果

目前部屬的對象支持 Kubernetes, Nomand, EC2, Google Cloud Run ，文件中也有提到這工具可以與 GitHub Action, CircleCI, Jenkins等整合來完成各種自動化部屬
有興趣的人可以趕快來玩看看，嘗鮮一下
https://www.hashicorp.com/blog/announcing-waypoint

GitOps 的概念我認為還是目前還是相當新穎，但是有觀察到愈來愈多的工具在往這一塊發展，包含最近 Rancher 2.5 就推出自己的 GitOps 工具來滿足大規模邊緣環境部署。

這邊跟大家分享我最近看的一本關於 GitOps 的電子書，整本書篇幅不多，主要分成下列章節

What GitOps isWhy it was inventedWhat problems it solvesThe differences between the principal GitOps toolsImplementation challengesAlternatives to GitOpsThe future of the GitOps movement

我閱讀的同時也隨手記錄其重點，全部分成六篇短文並且記錄下來，接下來則會每天分享一篇跟大家一起學習 GitOps 的概念與玩法

https://www.hwchiu.com/gitops-book-ch1.html

今天來跟大家分享 GitOps 書籍閱讀心得的第二篇，本篇探討 GitOpS 的基本概念，不追究實作細節，主要從其核心角度出發，去探討一種 GitOps 的實作方式


https://www.hwchiu.com/gitops-book-ch2.html

今天來介紹 GitOps 書籍閱讀心得第三篇，主要是探討 GitOps的前後今生

軟體開發的概念很多時候並不是創新，而是不同時空背景下是否合適與適用
不同時代隨者架構潮流的演變，服務用法也在改變，維運的思維與用法也會有所改變，但是改變不一定代表合適，一切還是取決於你的應用環境


https://www.hwchiu.com/gitops-book-ch3.html

今天的系列文章主要會介紹幾個可以考慮用來當做 GitOps 流派的工具，這邊有趣的是 GitOps 其實能夠搭配的東西不一定是應用程式，如果跟 Terraform 合併一同使用是不是也可以針對 Infrastructure 來管理更新

就我個人經驗來說，能夠先把所有環境都用程式碼或是文件以版本控制的方式保存，確保有能力針對需求快速複製與修改，接下來再來思考如何強化整個部署流程，讓整體團隊工作起來更有效率，同時針對近版，退版等需求都能夠有系統化的處理
 
https://www.hwchiu.com/gitops-book-ch4.html

今天來介紹自動部署過程中一個很重要的議題，機密資訊管理！

因為 Kubernetes Secret 本身只是編碼，不是加密，因此如何透過 Git 管理並且部署到 Kubernetes 內則是一個挑戰，特別是整個部署過程都是自動化時，要如何避免有任何一個環節可能會導致明碼洩漏導致後續安全性漏洞。

此外，當這個議題與 GitOps 整合時就更加重要，因為 GitOps 希望透過自動且版控的方式來管理部署使用到的所有檔案，這篇文章則會列出一些關於這個議題的可能解決方案





https://www.hwchiu.com/gitops-book-ch5.html

這裡幫大家整理一下關於 GitOps 的相關資源，除了系列文章之外，也有我之前於線上 Meetup 的一些操作 Demo
GitOps 是一種概念，沒有明文規定要怎麼實作
也不是一定要使用 Flux/ArgoCD 等這類型解決方案才可以被稱為 GitOps
GitOps 對我來說，其實跟很多抽象概念一樣，我在意的反而是其到底想要解決什麼問題，而不是要用什麼工具解決
從出發點去思考，將其套用到當前工作團隊之中，然後反問自己一些問題，譬如
1. 這些問題，我目前的團隊與工作流程中存在嘛？
2. 如果不存在，我需要改變嘛？改變帶來的好處是什麼
3. 如果問題存在，要如何改變與修正?
針對問題(3)，這部份又要仔細考慮，如果要改動，要對既有架構整個重構？還是需要時間小幅度實作即可？
部署流程不是一個簡單工作，往往跟許多系統牽扯在一起
任何大幅度的改動都可能會造成其他服務受到影響，沒有詳細的規劃與演練，可能造成的副作用比效益還來得大
此外，團隊的資源有限，包含時間，人力。當前所有事項的優先順序是什麼？ 如何安排人力資源去解決對應問題更為重要
不論採用哪種方式部署，哪些軟體，最重要的是能夠提昇整個團隊的工作效率
https://www.hwchiu.com/tags/GitOps/
https://www.youtube.com/watch?v=1n2JsOIiHP8&t=2223s

今天要來跟大家分享一個單一節點如何提高應用程式吞吐量與服務能力的方式

這個方式主要探討的是應用程式對於網路連線的 I/O 模型，試想一個常見的使用範例。
一個主要的 Process 會去聽取一個固定的 port number (ex port 80)，並且通知後面眾多的 worker 來幫忙處理這些封包連線，而這些 worker 的工作就是處理連線。 
整個架構中是一個 1 v.s N 的狀況， 一個負責 Listen ，N個負責處理連線內容

而今天要分享的則是想要讓架構變成 N v.s N 的狀況， 會有 N 個 Process, 每個 Process 配上一個 Worker。
而這 N個 process 同時共享一樣的 Port (ex, port 80)
這種情況下可以減少多個 worker 共享一個 listen socket 時的各種保護機制，取而代之的則是每個 listen socket 配上一個專屬的 worker 來處理。

要達成這樣的架構非常簡單，只要透過 SO_REUSEPORT 這個 socket option 告
訴 Kernel 當前這個 PORT 可以重複使用。

當封包送到 kernel 後則是由 kernel 幫你分配封包到所有使用相同地址的 Listen Socket (Process)

根據 nginx 官方文章的測試，這種架構下對於 RPS (Request per second) 有顯著的提升，有興趣的可以看看下列兩篇文章

參考文章:
- https://blog.cloudflare.com/the-sad-state-of-linux-socket-balancing/
- https://www.nginx.com/blog/socket-sharding-nginx-release-1-9-1/