今天來介紹 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/

Cloud Native 的影響愈來愈大，連 5G End-To-End Network Slicing 都可以看到 Kubernetes 的蹤影

有興趣的可以看看這篇由交通大學於 ONF Spotlight 所分享的影片，介紹交通大學如何開發一套基於 Cloud Native 的系統於 5G 架構之中

https://www.youtube.com/watch?v=6oBPUppikiw&feature=emb_logo

該會議的所有影片都可以於這邊觀看
https://opennetworking.org/5g-transformation-with-open-source/

不知道大家第一次接觸 kubernetes 的時候都是使用哪套解決方案來打造你的 K8s 叢集？ 亦或是作為一個開發者，你平常都怎麼架設 K8s 來本地測試?

這篇文章提到了作為一個 Local Kubernetes Cluster 幾個選擇，並且點出了三個需要解決的問題
1.  Container Registry, 作為一個開發環境，應該不會想要每次測試都要將 Container Image 給推到遠方，譬如 dockerHub, Quay，這樣整體效率低落
2. Builder, 如何有效率的幫忙建置你的應用程式，並且與 Kubernete 整合，讓開發者可以更專心於本地開發，而不要擔心太多 k8s 之間的設定
https://www.dex.dev/dex-videos/development-clusters
3. Runtime, 底層使用哪套 Container Runtime, 譬如 docker/containerd/cri-o

註: 我個人對第三點其實沒太多感覺，不覺得本地測試這個會影響太多

後面列舉了當前知名的相關專案，譬如 KIND, K3D, MicroK8S, Minikube 以及 Docker for desktop. 並且簡單的比較了一下這些本地開發的差異。

不知道大家平常本地開發時，都會用哪一套?
我個人是比較常使用 KIND 來測試，畢竟輕量化且同時支援多節點，環境也乾淨，測試起來也方便。

這邊跟大家分享一篇 EKS 升級的心得文章，該文章記錄了 EKS 從 k8s 1.17 到 1.18 的過程，並且先分享了幾個 1.18 主要新功能，包含了
1. Topology Manager (Beta)
2. Service Side Apply (Beta)
3. Pod Topology Spread (Beta)
... 等
詳細升級過程看起來無痛輕鬆，有興趣的可以參考全文

當然升級 K8S 最重要的還是要注意 Resource 的 API 版本是否有變，譬如 1.16 就讓很多人採到 Deployment 使用 extensions/v1beta1 的錯誤，所以每次升級請先檢查有沒有哪些過舊的 API 版本被丟棄，以免升級後現有的服務部屬不上去

題外話： ingress 如果還是使用 extensions/v1beta1 的話，建議都換成 networking.k8s.io/v1beta1 (k8s 1.14+), 到了 1.22 後本來的 extensions/v1beta1 就不能用囉


https://medium.com/swlh/amazon-eks-upgrade-journey-from-1-17-to-1-18-e35e134ca898

Kubernetes 1.19 帶來的一個重大改變就是 Ingress 正式 GA, 這個從 kubernetes 1.1 版就引入的元件經歷了 18 個版本演進終於要正式從 Beta 進入到 Stable 版本了，對於使用者來說這有什麼影響?

1. Ingress/IngressClass 這兩個資源的 API 版本將正式使用 networking.k8s.io/v1 ，而過往的 extension/v1beta1 將於 kubernetes 1.22 後正式移除，所以如果有要使用的人可以提早轉移，以免 1.22 又不小心中獎導致 yaml 都失敗
2. Ingress 的設計裡面跟架構不會更動，未來的修復都已臭蟲以及不會破壞向下相容的修改為主
3. 要更多更強的網路功能，請使用 CRD 這種方式來擴充 Kubernetes，讓 Kubernetes 專心維護核心功能與介面。譬如 Istio 內滿滿的 CRD


Reference:
1. https://github.com/kubernetes/kubernetes/pull/89778
2. https://www.cncf.io/blog/2020/10/29/kubernetes-1-19-the-future-of-traffic-ingress-and-routing/

這邊來跟大家分享一下 Docker 網路入門系列文第二篇

該篇文章會一步一步的去探討原生 Docker Bridge 模型到底會做什麼事情，每個步驟如何自己透過 Linux 指令來完成。

本篇文章著重於如何打造一個可以讓容器互通的網路模型，本身還沒有涉入過多關於 iptables 等能夠讓容器存取外網能力的介紹，這部份會於第三篇文章再來仔細介紹

有興趣的人歡迎看看這篇文章，不吝指教
https://www.hwchiu.com/docker-network-model-lab.html

這邊跟大家分享一篇 GitOps 實作心路歷程，這篇文章中總共使用下列工具
1. AWS, 所有環境都基於 AWS 此 cloud provider
2. K3S, 一套由 Rancher 開發的輕量級 Kubernetes 發行版本
3. Rancher, 管理 K3S 介面
4. Cert-Manager, 與 Let's Encrypt 連動，管理相關憑證
5. Vault, Secret 管理工具
6. ArgoCD GitOps 使用工具，連動 Git Repo 與 K8s
7. Terraform, IaaC 的一種工具

這篇文章從頭開始介紹如何整合上述工具，並且完成一個簡易的範例，透過這些範例也讓你理解每個元件對應的功能，如何使用，共重要的是從一個大範圍的視角來看，這些元件的地位，更可以幫助你瞭解整體架構

有興趣的可以閱讀全文

https://adam-toy.medium.com/implementing-gitops-on-kubernetes-using-k3s-rancher-vault-and-argocd-f8e770297d3a

這邊跟大家分享一個有趣的專案 kubemq, 這個專案是完全針對 Kubernetes 環境所使用的 Message Queue，其最主要的特點是針對 Hybrid Cloud 這種多雲環境而設計的，當你今天有多套 Kubernetes Cluster 坐落於不同環境，有的是地端自架，有的是特定雲端服務者，但是你又有這個需求的時候，可以來看看這套解決方案


https://kubemq.io/
https://www.cncf.io/blog/2020/11/03/the-need-for-kubernetes-native-messaging-platform-in-hybrid-cloud-environment/

#小編

大家午安

Grafana Labs 在 observability 的最後一塊拼圖。

Grafana Labs 於前幾天 ObservabilityCon2020 大會上新開源了一個專案 Grafana Tempo 用於做分布式追蹤(Tracing) 的後端服務，具備了「高擴展性」和「低成本消耗」的系統，儲存系統僅只依賴 S3或 GCS ，並與Loki/Grafana 做了高強度的整合，並兼容Jaeger/Zipkin/OpenTelemetry/OpenCensus 等目前主流的分布式追蹤服務。

ObservabilityCon2020: https://grafana.com/go/observabilitycon/keynote-what-is-observability/

Grafana Tempo: https://github.com/grafana/tempo

今天這篇文章來跟大家介紹一下 Custom Resource Definition (CRD) ，對於大部分的 Kubernetes 使用者來說，日常工作中根本不需要去理解什麼叫做 CRD，但是當你整合了一些第三方解決方案之後，你會發現你的 Kubernetes 內增加了好多 CRD。 一個最簡單的範例就是你會看到 Yaml 中使用的 KIND 是一些 Kubernetes 官方文件中沒有提到的內建型態，反而是跟你使用的解決方案緊密相連的情況。

本篇文章用一種輕鬆簡單的方式，去跟你介紹 CRD 的概念，個人覺得淺顯易懂

但是要注意的，通常只有 CRD 沒有辦法發揮其真正用途，畢竟 CRD 就是一個資料結構，需要一個使用者，而這個使用者往往都是由 Controller 來管理。當這兩者結合後就可以變成大家所熟悉的 Operator Pattern 

https://itnext.io/crd-is-just-a-table-in-kubernetes-13e15367bbe4

今天來分享一篇跟科技完全無關的文章，主要是一位好友近期整理自己減肥 20kg 的血淚史！

對於工程師的日常生活來說，大家習慣坐一整天，這過程可能會因為椅子，滑鼠，鍵盤的高低導致肩膀長期屬於不舒服位置，甚至是坐姿不良導致下背，髖關節，骨盆等各種不舒服

當然體重本身也是一個警訊，肌肉過少甚至內臟脂肪過高也都要注意一下身體狀況


最後，大家工作之餘，也要注意身體健康，吃得好，動得好，有良好的身體才有日子去享受努力的果實

https://speakerdeck.com/pichuang/gong-cheng-shi-de-ni-xi

Docker 網路入門系列第三篇!
本文銜接自第二篇手把手打造 Bridge 網路模型系列，上篇文章中我們透過 veth/brctl 等相關指令，打造出一個讓兩個容器網路互通的簡單環境，但是該環境中這些節點還不能對外上網。
因此本篇文章就會從這邊出發，去探討到底要如何讓容器可以對外上網，這中間牽扯到哪些概念，以及 Docker 實際上做了些什麼事情
基本上整個流程跟 Docker 做的事情思路是一致的，透過瞭解這些網路運作原理，更可以讓我們學習 Docker 的用法，同時未來網路出現問題的時候，也會更有背景知識知道如何去除錯
https://www.hwchiu.com/docker-network-model-snat.html

這邊跟大家分享一個常用小工具 scp 的熱門討論!
LWN.net 這幾天有一個文章是關於基於安全性考量下，改用其他工具取代 scp, 譬如使用 sftp 以及 rsync.
有常常使用 scp 這個工具的人可以看一下這篇文章討論的原因，以及如果要改成使用 rsync, 可以有什麼樣的參數使用
https://lwn.net/SubscriberLink/835962/ae41b27bc20699ad/

不知道有沒有人還是習慣用 vim 來編輯 kubernetes yaml 呢？

這邊介紹一個 vim plugin，能夠針對 kubernetes 物件自動補齊，能夠減少一直查找文件的需求，特別是當本地開發配上 kubeeval 等工具來檢查 k8s yaml 語法與語意時就會更有幫助

有使用 vim 的人可以使用看看

https://octetz.com/docs/2020/2020-01-06-vim-k8s-yaml-support/

這邊跟大家分享下個月的線上活動，主要是探討 Jenkins 的一些有趣用法，內容主軸是探討大型跨企業合作專案下， Jenkins 使用上的痛點與解決方式

https://www.facebook.com/events/1254540821590769

不知道大家有沒有聽過 Open Policy Agent (OPA) 這個 CNCF 專案?

有滿多專案的背後都使用基於 OPA 的語言 Rego 來描述各式各樣的 Policy，譬如可以使用 conftest 來幫你的 kubernetes yaml 檢查語意是否有符合事先設定的 Policy。

本篇文章則是跟大家分享如何使用 OPA 來針對 Ingress 資源進行相關防呆與除錯，一個最基本的範例就是如何避免有多個 Ingress 使用相同的 hostname 卻指向不同的 backend service. 過往可能都是靠人工去維護，確保沒有一致的名稱，但是透過 OPA 的概念我們可以再佈署 Ingress 到 Kubernetes 前先進行一次動態的比對，確保當前設定符合所有 Policy，得到所謂的 Approved 後才能夠佈署進去。

有興趣的人可以看看這篇文章，甚至學習一下 OPA 的使用方式
https://www.cncf.io/blog/2020/09/29/enforce-ingress-best-practices-using-opa/

不知道大家有沒有遇過本地儲存空間滿了，再也抓不了 docker image 的慘痛經驗呢？ 本文就想要探討的是遠方 Container Image 上的管理問題，隨者時間演進，愈來愈多的版本產生，那作為管理者，我們要怎麼去看待這些 image，放任他們無限擴張嘛？ 這些資源背後都代表一個儲存空間，也就意味額外的成本開銷。

作者想要解決的問題是，如何設計一套自動機制去刪除用不到的 image tag，保留會用到的，為了解決這個問題，要先定義什麼叫做 "用得到的 image tag".

本文列舉了四種需要保留 image tag的情況
1) Production 環境正在使用的 image tag, 如果刪除了，遇到 ImagePullPolicy:Always 的情況那可真的麻煩了
2) 遇到緊急情況，應用程式需要退版，因此保留的 image tag 可不能只有當前版本，過往穩定版本也都要保留
3) 從開發角度來看需要的 image tag, 譬如我們開了一個 PR，這個 PR 有一個對應的 image tag, 再這個 PR 還沒有結束前，這個 image tag 應該都要保留讓開發者去驗證與使用
4) 最後則是特定版本號或是code name等專屬名稱

作者使用 werf 這套 k8s 建置佈署工具來幫忙，這工具除了常見的 build/deploy 外，還可以刪除遠方的 container image。 因此作者整合一套演算法，將其與 werf 整合，讓整個 CI/CD 的過程中能夠自動去產生新的 image，並且根據需求去移除用不到的 image.

有興趣的記得點選下列原文來學習更多

原文:
https://medium.com/flant-com/cleaning-up-container-images-with-werf-ec35b5d46569