這篇文章是 Tekton 這套號稱完全針對 Cloud-Native 所發展的 CI/CD 工具教學文，作者從基本概念到如何使用都詳細的介紹一番，讓讀者看完就對 Tekton 能夠有基本的認知。

就如同其他常見的 Pipeline 系統一樣，Tekton 的工作流程是由 Step, Task 以及 Pipeline 組成。Tekton 使用 Step 描述每個最小工作事項，而每個 Task 則由數個 Step 組成，這些 Step 會依序執行，且彼此會共用相同環境，譬如 Volume.
Pipeline 則是由數個 Task 所組成，不過比較特別的是這些 Task 可以有更為靈活的執行順序，譬如依序執行，平行執行，甚至是 DAG 這種有向無環圖的執行順序。


Tekton 的一大特色是其完全寄生於 Kubernetes 內，必須要搭配 k8s 的環境來使用，也因此上述的 Step,Task 以及 Pipeline 實質上都是屬於 K8s 的 CRD 一種，部署時需要透過 YAML 來撰寫，並且用常見的方式 (kubectl, helm, kustomize) 來安裝到 k8s 內去設定 Tekton。

這種模式帶來的一個好處就是每個元件都是獨立的 YAML 檔案與類別，因此相同的部分可以非常輕易的被重複使用，舉例來說一個運行 Git-Clone 的 Task 就可以被多個不同的 Pipeline 重複使用，而有需求需要修改的時候也只需要修改一個 Task 即可。

對於 Tekton 這套解決方案有興趣的可以參閱下列全文玩耍看看
https://lambda.grofers.com/adopting-tekton-cloud-native-ci-solution-67fb229f4992

本篇文章是個經驗分享系列文，作者探討 Kubernetes 內 15 種不被建議的部署策略與模式。
作者之前曾經撰寫過 Contianer 架構底下的部署模式探討，而本系列文(三篇)則是著重於如何將這些 containers 透過 Kubernetes 給部署到生產環境，總共會探討十五種不推薦的模式，接下來的三篇文章將會介紹各五種不好的模式。

Using containers with the latest tag in Kubernetes deployments
任何 container 的 image 都不應該使用 latest，因為 latest 本身沒有任何意義，這會使得維運人員沒有辦法掌握到底當前部署的版本是什麼，更嚴重的情況適當 latest 搭配 PullPolicy:Always 時會產生更為嚴重的問題。因為 Always 的策略導致每次 Pod 部署時都會重新抓取 image，所以一個 deployment 中，多個使用 latest tag 的 Pod 但是其實使用的 image hash 是不同的。

作者認為比較好的做法有
1. 所有 container image 都是不可修改的，一旦建立就禁止覆蓋，有任何改動就進版
2. 部署用的 image tag 使用有意義的版本名稱

補充: 實際上 pull image 也可以使用 sha256，譬如 "docker pull hwchiu/kubectl-tools@sha256:acfb56059e6d60bf4a57946663d16dda89e12bfb1f8d7556f277e2818680e4c8"


Baking the configuration inside container images
任何 contaienr image 建置的時候應該都要往通用的方向去設計，而不是參雜各種設定在裡面。著名的 12-factor app 裡面也有提到類似個概念，建置好的 image 應該要可以 build once, run everywhere，動態的方式傳入不同的設定檔案，而不是把任何跟環境有關的資訊都寫死
舉例來說，如果 image 內包含了下列設定(舉例，包含不限於)
1. 任何 IP 地址
2. 任何帳號密碼
3. 任何寫死的 URL

作者認為比較好的做法有
1. 透過動態載入的方式來設定運行時的設定，譬如Kubernetes configmaps, Hashicorp Consul, Apache Zookeeper 等
2. 根據不同程式語言與框架甚至可以做到不需要重啟容器就可以載入新的設定


Coupling applications with Kubernetes features/services for no reason
作者認為除了很明確專門針對 Kubernetes 使用，或是用來控制 Kubernetes 的應用程式外，大部分的 應用程式包裝成 Container 時就不應該假設只能運行在 Kubernetes 內。作者列舉了幾個常見的使用範例，譬如

1. 從 K8s label/annotation 取得資訊
2. 查詢當前 Pod 運行的資訊
3. 呼叫其他 Kubernetes 服務(舉例，假設環境已經存在 Vault，因此直接呼叫 vault API 來取得資訊)

作者認為這類型的綁定都會使得該應用程式無法於沒有 Kubernetes 的環境運行，譬如就沒有辦法使用 Docker-compose 來進行本地開發與測試，這樣就沒有辦法滿足 12-factor 中的精神。
對於大部分的應用程式測試，除非其中有任何依賴性的服務是跟外部 Kubernetes 綁定，否則這些測試應該都要可以用 docker-compose 來叫起整個服務進行測試與處理。
服務需要使用的資訊應該是運行期間透過設定檔案，環境變數等塞入到 Container 內，這樣也呼應上述的不要將與環境有關的任何資訊都放入 image 內。

Mixing application deployment with infrastructure deployment (e.g. having
Terraform deploying apps with the Helm provider)
作者認為近年來伴隨者 IaC 概念的熱門，愈來愈多的團隊透過 Terraform/Pulumi 這類型的工具來部署架構，作者認為將部署架構與部署應用程式放到相同一個 Pipeline 則是一個非常不好的做法。

將基礎架構與應用程式同時放在相同 pipeline 可以降低彼此傳遞資訊的困難性，能夠一次部署就搞定全部，然而這種架構帶來的壞處有
1. 通常應用程式改動的頻率是遠大於基礎架構的改變，因此兩者綁在一起會浪費許多時間在架構上
假如部署基礎架構需要 25 分鐘而應用

本文延續前一篇文章，作者探討十五種 Kubernetes 不該使用的部署與維運模式，總共三篇，每篇五種。


Using Kubectl as a debugging tool
作者認為一個良好的 Kubernetes 叢集必定要有一個相對應個可觀測性工具，包含 Metrics/Log/Tracing 等。對於一個維運人說來說，今天要處理事情時，第一件事情如果還是慢慢的用 kubectl 來執行 get, describe ,log 等指令找問題的話就太慢了，這類型的工具都應該只是輔助使用，真正還是要依賴有效的監控系統，不論是常見的系統指標，應用程式狀態甚至是應用程式獨特的指標等，將這些資訊整合到一個方便顯示的儀表板，甚至搭配對應的 Alert 功能來達到主動通知。


Misunderstanding Kubernetes network concepts
Kubernetes 內提供的網路功能很容易被搞混，Service(ClusterIP, NodePort, LoadBalancer) 與 Ingress 的差異到底是什麼，很多初次踏入 Kubernetes 的玩家沒有特別去理解差異，只知道應用程式部署後就可以通了。Service Mesh 這個概念作者也推薦去學習與瞭解，知道這個概念是什麼，以及想要什麼解決問題就好，因為並非不是每個叢集都真的需要一套 Service Mesh 的解決方案，但是理解這個概念未來就有能力知道什麼時候需要導入。

Using permanent staging environments instead of dynamic environments
對於應用程式開發者來說，如何於 Kubernetes 環境上測試新功能一直都是一個困難的問題。大部分的團隊中都會有 QA/Staging/Production/Dev(甚至更多)的環境，假設 Dev 環境可以供開發者測試，這些開發者要如何確保自己的修改沒有問題且通過整合測試。
一個常見的問題是假如多個開發者同事部署自己的程式碼到固定環境中，有可能會造成互相干擾，導致問題發生時沒有辦法正確的判別問題是誰產生的。
作者提到一種作法就是透過預借的概念，確保每個開發者使用叢集時都不會有他人干擾，然而這個問題也會引發其他問題，譬如開發者間要互相協調時間，同時每個人用完環境後都要還原成穩定的狀態，以免干擾下一位的使用。

作者推薦使用動態叢集的方式來進行測試，使用 Github PR 為範例，當 PR 開啟時，動態創建 Kubernetes 叢集供測試，當 PR 合併後就會將該 Cluster 給移除。透過這種範例每個開發者都可以有獨立的環境進行測試彼此不干擾，同時也會隨者程式碼的合併而自動回收環境，也不需要擔心環境污染問題。

Mixing production and non-production clusters
任何團隊一定要有正式生產環境的叢集跟其他叢集分隔開來，千萬不能使用 namespace 的方式於一個叢集中同時維護生產與非生產環境。譬如
1. 任何人操作 Kubernetes 都很容易失誤，譬如指令下錯，指向錯的物件。這類型的操作都有可能導致該叢集上生產環境被誤刪
2. namespace 的隔離性不好，實際上很多物件彼此還是可以互相存與溝通，這部分也有其他的隱憂

詳細原文可以參考下列連結。

https://medium.com/containers-101/kubernetes-deployment-antipatterns-part-2-2af25a710bc0

本篇文章是個經驗分享文，作者分享使用 Docker 作為開發環境時值得注意的 Best practices，透過這些經驗分享希望能夠讓開發者少走一些冤枉路。

原文提出了 15 個經驗談，這邊幫大家節錄幾個，有興趣的可以點選原文瞭解更多!
1. One thing at a time
2. Be ephemeral
3. Utilize .dockerignore
4. Less is more
5. Secrets should be secret
6. PID 1 is your birth right
7. Share and Care
8. Vulnerability Scan
9. Tag like you mean it
10. Permissions are costly
11. Source of Truth
12. Always official
13. Don’t include debug
14. Use entry point script smartly
15. Size does matter

One thing at a time
建置 Image 的時候專注做好一件事情，每個 Image 應該有一個專心要解決的問題，譬如一個應用程式，一個小工具等。對於 Nginx 這類型的 Image 來說，應該沒有人會期望於裡面看到有 Apache 的應用程式吧?

Be ephemeral
這個主要探討的是該 Image 本身建置時應該要以 stateless 的概念去處理，未來不論是透過 docker 或是 Kubernetes 來管理部署時，Contaienr 都很有機會被重啟，每次的重啟都意味該容器是重新啟動。所以千萬不要讓你的 Image 變成多次重啟會導致應用程式出問題的形式，任何的這類型資料應該都要透過外部取得，不要塞到你的 Image 內

Utilize .dockerignore
善用 .dockerignore 這個檔案來將不必要的檔案從 build 過程給排除，使用方法與 .gitignore 類似。透過這個檔案的設定可以避免 docker build 的時候不會把一些過大或是完全不需要的檔案都送給 docker daemon，不當浪費時間也浪費空間。

Less is more
避免安裝任何無關或是非必要的套件到你的 image 中，特別是那些 "nice to have" 的理由。

註: 我個人是滿討厭把 Image 弄得很乾淨的，除錯什麼工具都沒有，連 ash/sh/busybox/bash 都沒有的 image 更是我討厭中的排行榜冠軍

Secrets should be secret
任何機密資訊都應該要於運行期間動態載入，而不是建置期間塞入。請使用其他工具譬如 Vault 來管理這些機密資訊，並且執行期間讓 Container 能夠存取到正確的值。

PID 1 is your birth right
Linux 環境下會使用 SIGTERN, SIGKILL 等相關的 Singal 來戳你的應用程式，請確保你運行的應用程式要能夠攔截這些訊號來處理並完成有效的 Graceful shutdown.

Share and Care
如果環境中有多個 Image 彼此有共享相同的工具與功能，與其每個 Image 都單獨建置維護不如建置一個 Base Image，接者讓所有要使用的 image 去載入使用即可。
透過這種方式可以讓整體的維護性與管理性更為簡單，每個 image 可以減少重複的程式碼，同時要升級時只要針對 base Image 處理即可。


https://medium.com/pradpoddar/avoid-costly-mistakes-using-advanced-docker-development-best-practices-acd812784109

本文延續前一篇文章，作者探討十五種 Kubernetes 不該使用的部署與維運模式，總共三篇，每篇五種。

Misusing Health probes
Kubernetes 內有設定三種不同的 Probe，分別是 Readiness, Liveness 以及 Startup，前兩者 Probe 比較常被提到而且會不停的執行，而 Startup 則是會被運行一次的 Probe。
作者認為所有開發者都要去研究這三種的差異並且小心使用。
文章中列舉一些常見的錯誤用法
1. 用相同的 endpoint 同時處理 liveness 以及 readiness
2. 繼續沿用過往針對 VM 所設計的 health endpoint，應該要針對容器環境重新設計
3. Health 的檢查過於複雜，導致需要花費一個不可預測的時間
..
等

Not using the Helm package manager
作者認為目前 Kubernetes 生態系中只有一個 Package Manager，也就是 Helm，就像是常見的 apt/rpm 等套件般去管理不同的應用程式。
然而 Helm 卻很容易被誤解並拿去跟其他工具比較，譬如 Kustomize, Jsonnet.. 等。
從本質上來看 Helm， Helm 本身有 Package 的管理能力，同時也透過 Template 的方式來產生適合於不同環境的 YAML 檔案。 而上述其他的比較解決方案基本上都只能完成後者，透過如 overlay (kustomize) 等不同的方式來產生不同的 YAML，但是本身卻沒有去管理這些安裝好的應用程式。

如何產生 YAML 這些是部署前的流程，而上述的那些工具對於檔案部署到 Kubernetes 後就無能為力了，譬如想要刪除任何安裝到 Kubernetes 資源的應用程式，必須要找到原始的 YAML 檔案。而 Helm 則不一樣，本身會於 Cluster 內去記錄這些這些資訊，讓你可以透過 helm 的指令去刪除這些安裝好的應用程式。

作者認為除非團隊很明確的瞭解與設計其工作流程，確保 Helm 帶來的部署與管理流程不需要，否則推薦任何團隊都可以採用 Helm，特別是之前因為 Helm2 Tiller 而厭惡的人必須要來試試看 Helm3

Not having a strategy for secrets
如同先前探討的 Configuration 不應該直接嵌入 Contaienr Image 一樣，Secret 這類型的物件也一樣，作者看到團隊常有下列錯誤
1. 使用各種不同的方式來管理 Secret 物件
2. 沒有區分好運行期需要的 Secret 與建制時期需要的 Secret
3. 過於複雜的處理方式導致本地測試與開發過於困難

相反的，團隊應該要
1. 選擇一個策略
2. 所有團隊使用該策略來處理 Secret
3. 所有的 Secret 應該都要用相同的方式處理
4. 這樣的機制使得 secret 的管理與追蹤更為容易


Attempting to solve all problems with Kubernetes
永遠不要認為 Kubernetes 能夠解決所有問題，團隊必須要理解到 Kubernetes 帶來的優點與缺點，團隊本身的部署與工作流程是否適合使用 Kubernetes。
也不要想說要把所有服務都搬到 Kubernetes 內，譬如 databases, caching 等，這些本來就存在的解決方案依然可以使用本來的方式繼續部署，不要一相情願地覺得這些東西放到 Kubernetes 內就一定會更好。

詳細原文可以參考下列連結。

https://medium.com/containers-101/kubernetes-deployment-antipatterns-part-3-dfbdd2fd3292

本篇文章是 Netflix 的內部架構技術分享文，本篇文章要探討的是當 Netflix 內部大量採用 Google Drives(Sheets, DDocs, Slides...etc)進行檔案分享時所遇到的問題，以及 Netflix 是如何解決這些問題的。

問題: 對 Netflix 來說，由於下列兩個理由，導致目前 Google Drive 上大概有兩千萬的檔案
1. Netflix Studio 的合作夥伴大量使用 Google Service 來傳輸資料
2. 資料科學家需要將資料複製回本地的 Data 倉庫進行分析。

Netflix 內部為了方便存取這些資料，透過程式化的方式透過 Google API 來存取這些大量成長的資料，然而這樣的方式卻導致了兩個很麻煩的問題

1. 應用程式開發者與資料科學家必須要各自維護存取 Google 服務的帳號密碼，同時很多程式碼會大量的被重複開發。
2. 從可觀測性系統來說，到底有哪些檔案資料從 Google Drive 與 Data 倉庫移動是很不清楚的。

Netflix 為了解決這些問題，決定自行打造一個 Service Proxy 來處理所有流向 Google Services 的請求。透過這個中介層的服務，Google 服務認證的部分就可以有效率的於 Proxy 這層來處理掉，同時也能夠透過 Log 的方式來記錄到底哪些檔案目前正在移動，彌補了過往可觀性系統的缺失。

文中先介紹了關於 Google API 的架構，Netflix 內部原先大部分都透過 Python 或 Java 等程式語言來撰寫 Client 端的應用程式。為了讓整個 Proxy 能夠更有效的處理 Credential 的部分，Netflix 這邊還導入的內部工具(Metatron) 來管理這些資訊。
其他相關資訊還有
1. Proxy 基於 Java 開發
2. 使用 gRPC 來產生不同語言的 endpoints，統一由 Proxy 將請求轉為 HTTP 送往 Google 處理

此外，為了讓 Netflix 內部的所有人都可以很輕鬆的於 Google Drive 與 Data 倉庫間來更動資料， Netflix 為此打造一個可排程的 Job 來默默執行。文章後半段主要在介紹這個 Job 的架構與用法

對於全文有興趣的都歡迎閱讀~
https://netflixtechblog.medium.com/data-movement-for-google-services-at-netflix-9a77ca69f7c4

本篇文章是一個入門文章，主要探討 GitOps 相關的起源與概念，同時介紹不少關於 GitOps 的工具

起源: Weaveworks 於 2017 年針對 Kubernetes 的工作環境產生了不同的部署方式，而 GitOps 這個詞也就那時開始萌芽發展

概念: 透過 Git PR 的方式來驗證與自動的部署所有與系統有關的修改。今天有任何部署的需求時，團隊要做的事情就是 1) 產生 Git PR 2)進行 Review 3) 合併 接者就是等任何修改被自動部署
Git 於整個環節中扮演者 Single Source of Truth 的角色，所有的修改都必須發生於 Git 本身，也因為是基於 Git 來使用，所以不論是 GitHub, Gitlab, Bitbucket, Gerrit 等系統都可以使用。
註: Bitbucket 還針對 GitOps 這種形式取了一個名為 BDDA 的名稱，意義為 Build-Diff-Deploy-Apply

好處:
1. 稽核性: 透過 Git 可以針對所有的修改去查閱，知道誰於什麼時間點進行什麼修改
2. 由於不需要將 Kubeconfig 等資源放到外部叢集，資安方面會比傳統外部直接Push/Apply 來得更好
3. 開發人員可以更容易地去部署應用，不需要仰賴Ops幫忙
4. ...etc

註: GitOps 並不是只能適用於 Kubernetes 本身，事實上整個系統架構都可以套用這種方式，譬如搭配 Terraform 等相關的 IaC 工具時，就可以透過 GitOps 來搭建整個系統，包含底層架構，k8s叢集以及最重要的應用程式

相關工具(文章列出滿多工具):
1. ArgoCD
2. Atlantis: Terraform PR 的自動化工具
3. Autoapply
4. CloudBees Rollout
5. FlexCD
6. Helm Operator
7. Flagger
8. Ignite
9. Faros
10. Gitkube
11. Jenkins X
12. KubeStack
13. Weave Cloud
14. Werf
15. PipeCD



https://medium.com/searce/gitops-the-next-big-thing-for-devops-and-automation-2a9597e51559

本篇文章是個經驗談，作者想要聊聊是如何將一個 4vCPU 的VM給調整到可以達到每秒處理 1.2M(120萬)個 JSON Reuqest，本篇文章非常的長，所以會分多天來介紹。

整篇文章探討的是各種 turning 的步驟，來聊聊如何從最初每秒 224k(22萬四千) 給調整到每秒 1.2M 的處理能力。

整個過程分成九大步驟，後面同時標示每個過程後的每秒請求能力
1. Application Optimizations (347k)
2. Speculative Execution Migtigations (446k)
3. Syscall Auditing/Blocking (495k)
4. Disabling iptables/netfilter (603k)
5. Perfect Locality (834k)
6. Interrypt Optimizations (1.06M)
7. The Case of the Nosy Neighbor (1.12M)
8. The Battle Against the Spin Lock (1.15M)
9. This Gost to Twelv (1.20M)

作者強調，上述的過程不一定適合你的應用程式，但是透過這些步驟能夠讓你更佳瞭解應用程式的運作行為，同時也有機會發現一些潛在的瓶頸問題。


環境介紹
1. 團隊使用 Techempower 來進行 JSON Serialization 的測試
2. 使用 libreactor(event-driven框架) 來搭建一個簡單的 API Server
3. HTTP 的解析使用 picohttpparser，同時使用 libclo 來處理 JSON 的編碼
4. 硬體環境
- Server: 4 vCPU, c5n.xlarge AWS VM
- Client: 16 vCPU, c5n.4xlarge AWS VM (clinet太弱會變成瓶頸)
- Network: Server/Client 屬於同一個可用區域(AZ)
5. 軟體環境
- 作業系統: Amazon Linux2 (Kernel 4.14)
- Server: 使用 libreactor (使用不同版本，分別是 Round18 以及 Round20)
- Client: 修改 wrk 這個知名的工具並重新命名為 twrk，詳細差異自己看文章內部，主要都跟顯示有關
6. 實驗方式
- 每個測試跑三次，取中間值
- 256 連線，16 threads，同時每個 thread 都會 pin 到一個固定的 CPU
- 每個實驗都有兩秒的暖機時間來建立連線


Ground Zero
第一個要探討的就是什麼最佳化都還沒有使用前，到底當前應用程式可能的瓶頸在哪裏
首先團隊將該應用程式與其他常見的應用程式或是開發框架比較，譬如 Netty, Nginx, Actix, aspcore 等， libreactor 的效能不錯，有中上水準。

接者作者使用火焰圖(Flame Graphs)來 Profile 該伺服器，作者很好心地將文章中所有的火焰圖都調整了一下，讓所有的 user-space 相關的 function call 都轉成藍色，而剩下跟 kernel 相關都維持紅色。
1. 大部分的時間都在 Kernel 處理
2. 主要是花費在收封包與送封包
3. 應用程式本身主要是分兩大部分，解析 HTTP 的封包以及處理請求與回應。
從上述兩點來看，作者認為目前的應用程式寫得算不錯，因為瓶頸很明顯是卡在 Kernel 端

接下來就正式進入到各種 Turning 的章節探討

Application Optimizations

長話短說:
- 作者基於 libreactor Round18 的框架進行修改，並且所有的修改都已經被合併到 Round20 的版本中，而這些修改主要是實作方面的強化以及整個框架的最佳化。

1. 作者首先透過 htop 觀察運行過程，發現 Server 只有使用 2vCPU 而已(系統有 4vCPU)，因此這是作者進行的第一個修改，讓 Server 使用了 4vCPU，這個簡單調整就讓效能提升 25%

註: 作者特別強調，不要覺得從 2vCPU 變成 4vCPU 效能就可以變成兩倍，主要是1) 沒有使用的 vCPU 還有很多其他的工作要處理，因此不是完全都送給你應用程式處理。2)基於 hypter-thread vCPU 的架構，環境只有兩個真正的 CPU 而是透過邏輯的方式產生四個抽象的 CPU，所以全用一定會變快，但是基於很多資源還是要競爭與共用，數字不是單純翻倍

2. 作者自己的應用程式本身使用 gcc 建置時有使用 "-o3" 的方式來最佳化處理，然而框架本身卻沒有使用 "-o3" 的方式來弄，因此作者也針對這個部分來處理，讓建制框架時能夠使用 -o3
3. 從實作方面來看，作者觀察到 libreactor 1.0 版本使用的是 read/write 這兩個常見的方式來處理封包的送收，作者將其修改成 recv/send 整個效能就提升了將近 10%。

註: write(針對 FD，更全面廣泛的用法) 與 send(針對 Socket，更針對的用法) 使用上差異不大，但是 write 於底層 Kernel 最終還是會呼叫到 send 來處理，所以基本上可以理解就是在沒有特別參數需求時，可以直接跳過幾個 kernel function 來達到加速的效果。

write kernel 內的走向: sys_write -> vfs_write -> __vfs_write -> sock_write_iter -> sock_sendmsg

send kernel 內的走向: sendto -> sock_sendmsg

4. 作者觀察到火焰圖中有一些 pthread 相關的資料，進而發現 libreactor 會創造一個 thread pool 來處理非同步的 DNS 名稱解析問題。對於一個 HTTP Client 來說，如果今天要發送請求到多個不同的 domain，而每個 domain 都會需要進行一個 blocking 的解析過程，透過這種方式可以減少 DNS 解析造成的 blocking 問題。然而對於 HTTP Server 來說，這個使用情境帶來的效益似乎就稍微低了些，畢竟 Server 只有 Bind Socket 之前可能會需要去解析一次 DNS 而已。
大部分的情境下， thread pool 都是應用程式初期會去創造而接者就不太會管她，但是對於錙銖必較的效能除錯人來說，任何能夠調整的部分都可能是個值得探討的地方。
作者透過修改 Server 端(準確來說是 libreactor 框架內的程式碼)關於 Thread Pool 的一些用法，成長的讓整個效能提升了 2~3%

結論來說，透過上述四個概念來提升的程式碼效能。
1. vCPU 盡量使用: 25%-27%
2. 使用 gcc -O3 來建置框架的程式碼: 5%-10%
3. 使用 march=native 等參數來建置最後的 server 應用程式: 5%-10%
4. 使用 send/recv 而非 write/read: 5%-10%
5. 修改 pthread 的用法: 2%-3%

註: 作者強調每個最佳化的結果並非是單純累積的概念，反而還會有互補的效果。
可能前述的操作實際上也會讓後續的操作達到更好的效果，
譬如如果先跑 vCPU 的調整，效能大概提升 25%，但是如果先執行別的最佳化過程，最後再來調整 vCPU，就可以達到 40% 的效果，主要是 CPU 可以共有效率的去執行程式。

最後，這個部分讓整個處理封包能力從 224k 提升了 55% 到 347k (req/s)。
從火焰圖來看，整個 user-space 的範圍縮小許多，同時 send/recv 的處理也有使得整體的高度下降一點點(大概四格..)


為了避免文章過長，本篇文章就探討第一個最佳化的過程，剩下的就敬請期待後續!


https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/

本文延續前篇效能校正的經驗談，上篇文章探討了關於應用程式本身可以最佳化的部分，包含了應用程式以及框架兩個部分。本篇文章將繼續剩下最佳化步驟的探討。
Speculative Execution Mitigations
接下來探討這個最佳化步驟對於效能有顯著的提升，但是本身卻是一個非常具有爭議性的步驟，因為其涉及到整個系統的安全性問題。
如果大家對前幾年非常著名的安全性漏洞 Spectre/Meltdown 還有印象的話，本次這個最佳化要做的就是關閉這類型安全性漏洞的處理方法。
標題的名稱 Speculative Execution Migitations 主要跟這漏洞的執行概念與 Pipeline 有關，有興趣理解這兩種漏洞的可以自行研究。
作者提到，大部分情況下這類型的防護能力都應該打開，不應該關閉。不過作者認為開關與否應該是一個可以討論的空間，特別是如果已經確認某些特別情境下，關閉防護能力帶來的效能如果更好，其實也是一個可以考慮的方向。
舉例來說，假設今天你運行了基於 Linux 使用者權限控管與 namespaces 等機制來建立安全防護的多使用者系統，那這類型的防護能力就不能關閉，必須要打開來防護確保整體的 Security Boundary 是完整的。 但是如果今天透過 AWS EC2 運行一個單純的 API Server，假設整個機器不會運行任何不被信任的程式碼，同時使用 AWS Nitro Enclaves 來保護任何的機密資訊，那這種情況下是否有機會可以關閉這類型的檢查?
作者根據 AWS 對於安全性的一系列說明認為 AWS 本身針對記憶體的部分有很強烈的保護，包含使用者之間沒有辦法存取 Hyperviosr 或是彼此 instance 的 Memory。
總之針對這個議題，有很多的空間去討論是否要關閉，以下就單純針對關閉防護能力帶來的效能提升。
作者總共關閉針對四種攻擊相關的處理能力，分別是
1 Spectre V1 + SWAPGS
2 Spectre V2
3 Spectre V3/Meltdown
4 MDS/Zombieload, TSX Anynchronous Abort
5 與此同時也保留剩下四個，如 iTLB multihit, SRBDS 等
這種設定下，整體的運作效能再次提升了 28% 左右，從 347k req/s 提升到 446k req/s。
註: 任何安全性的問題都不要盲從亂遵循，都一定要評估判斷過
Syscall Auditing/Blocking
大部分的情況下，Linux/Docker 處理關於系統呼叫 Auditing/Blocking 兩方面所帶來的效能影響幾乎微乎其微，不過當系統每秒執行數百萬個系統呼叫時，這些額外的效能負擔則不能忽視，如果仔細觀看前述的火焰圖的話就會發線 audit/seccomp 等數量也不少。
Linux Kernel Audit 子系統提供了一個機制來收集與紀錄任何跟安全性有關的事件，譬如存取敏感的機密檔案或是呼叫系統呼叫。透過這些內容可以幫助使用者去除錯任何不被預期的行為。
Audit 子系統於 Amazon Linux2 的環境下預設是開啟，但是本身並沒有被設定會去紀錄系統呼叫的資訊。
即使 Audit 子系統沒有真的去紀錄系統呼叫的資訊，該子系統還是會對每次的系統呼叫產生一點點的額外處理，所以作者透過 auditctl -a never,task 這個方式來將整體關閉。
註: 根據 Redhat bugzilla issue #1117953, Fedora 預設是關閉這個行為的
Docker/Container 透過一連串 Linux Kernel 的機制來隔離與控管 Container 的執行權限，譬如 namespace, Linux capabilities., cgroups 以及 seccomp。
Seccomp 則是用來限制這些 Container 能夠執行的系統呼叫類型
大部分的容器化應用程式即使沒有開啟 Seccomp 都能夠順利的執行，執行 docker 的時候可以透過 --security-opt seccomp=unconfined 這些參數告訴系統運行 Container 的時候不要套用任何 seccomp 的 profile.
將這兩個機制關閉後，系統帶來的效能提升了 11%，從 446k req/s 提升到 495k req/s。
從火焰圖來看，關閉這兩個設定後，syscall_trace_enter 以及 syscall_slow_exit_work 這兩個系統呼叫也從火焰圖中消失，此外作者發現 Amazon Linux2 預設似乎沒有啟動 Apparmor 的防護，因為不論有沒有關閉效能都沒有特別影響。
Disabling iptables/netfilter
再來的最佳化則是跟網路有關，大名鼎鼎的 netfilter 子系統，其中非常著名的應用 iptables 可以提供如防火牆與 NAT 相關功能。根據前述的火焰圖可以觀察到，netfilter 的進入 function nf_hook_slow 佔據了大概 18% 的時間。
將 iptables 關閉相較於安全性來說比較沒有爭議，反而是功能面會不會有應用程式因為 iptables 關閉而不能使用。預設情況下 docker 會透過 iptables 來執行 SNAT與 DNAT(有-p的話)。
作者認為現在環境大部分都將 Firewall 的功能移到外部 Cloud 來處理，譬如 AWS Security Group 了，所以 Firewall 的需求已經減少，至於 SNAT/DNAT 這類型的處理可以讓容器與節點共享網路來處理，也就是運行的時候給予 “–network=host” 的模式來避免需要 SNAT/DNAT 的情境。
作者透過修改腳本讓開機不會去預設載入相關的 Kernel Module 來達到移除的效果，測試起來整體的效能提升了 22%，從 495k req/s 提升到 603k req/s
註: 這個議題需要想清楚是否真的不需要，否則可能很多應用都會壞掉
作者還特別測試了一下如果使用 iptables 的下一代框架 nftables 的效能，發現 nftables 的效能好非常多。載入 nftables 的kernel module 並且沒有規則的情況下，效能幾乎不被影響(iptables 則相反，沒有規則也是會影響速度)。作者認為採用 nftables 似乎是個更好的選擇，能夠有效能的提升同時也保有能力的處理。
不過 nftables 的支援相較於 iptables 來說還是比較差，不論是從 OS 本身的支援到相關第三方工具的支援都還沒有這麼完善。就作者目前的認知， Debian 10, Fedora 32 以及 RHEL 8 都已經轉換到使用 nftables 做為預設的處理機制，同時使用 iptables-nft 這一個中介層的轉換者，讓所有 user-space 的規則都會偷偷的轉換為底層的 nftables。
Ubuntu 似乎要到 20.04/20.10 的正式版本才有嘗試轉移到的動作，而 Amazon Linux 2 依然使用 iptables 來處理封包。
下篇文章會繼續從剩下的五個最佳化策略繼續介紹
https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/

本文延續前篇效能校正的經驗談，上篇文章探討了關於系統呼叫, iptables 可以最佳化的部分，。本篇文章將繼續剩下最佳化步驟的探討。

Perfect Locality
預設情況下， Linux Kernel 會盡量平均地將請求給分配到所有的處理佇列，譬如 network queues, processes, CPUS. 大部分情況下這種機制運作良好不會有太多問題，不過如果今天要追求的不單單只是好的效能，而是極致的效能，則 locality 這個概念就要特別的去注意。

這篇文章中提到很多不同的方式，包含了 CPU Pinning, Receive Side Scaling(RSS), Transmit Packet Sterring(XPS)等，其實用比較簡單的介紹方式就是，希望可以使用固定的 CPU 來處理一條連線上的所有封包(進出)，這樣帶來的好處有
1. CPU Cache 可以盡可能的去使用，減少各種 miss 產生的成本
2. 減少 context switch 帶來的成本
3. 減少跨 CPU 之間交換資料帶來的成本
4. 減少 lock 之間帶來的成本
除了 CPU Pin, RSS, XPS 外，還有 irqbalance, smp_affinity_list 等相關的概念需要一併學習，對於這個概念有興趣的讀者非常歡迎去找尋這類型的資料

接者是 SO_REUSEPORT 這個參數，創建 Socket 時使用這個參數能夠使得多個 Process 共用一個連接埠，底層 Kernel 會針對 src/dst{ip/port} 來產生對應的 Hash，並且決定當前封包要送給哪一個 Process。
這個方式搭配前述各種 CPU Pin, 中斷的最佳化則會遇到問題，因為可能底層將該封包送到 CPU2 結果這個函式又把封包重新分配到 CPU0, 這樣就導致該連線要跨 CPU 處理了。
為了解決這個問題， Linux Kernel 4.6 後有新的參數 SO_ATTACH_REUSEPORT_CBPF，使用者可以自行撰寫 BPF 的程式來決定如何分配封包。作者根據這過想法撰寫了一個 BPF 的程式，來確保這個機制可以與前述的最佳化穩定運作。

這次的最佳化帶來的 38% 的成長，這時候的封包處理能力從 603k req/s 提升到 834k req/s
原文中關於這次的最佳化還有一些後續探討，有興趣的可以閱讀

Interrupt Optimizations

當封包透過網路送到網卡後，網卡必須要通知 OS 讓它知道有封包來了，要記得處理。一切處理完畢後網卡就可以繼續等待新的封包過來並且再次發送中斷給 OS 處理封包。這個流程大部分情況也是運作良好，不過當有大量的封包不停傳送來時，頻繁的中斷其實也是會造成不小的額外成本。

為了解決這個問題，目前比較嶄新的網卡都有支援中斷聚合等功能，透過這個功能可以延後中斷一個小週期，而該週期內收到的所有封包只需要透過一次的中斷就可以來處理，藉此降低中斷的次數。更為進階的網卡甚至支援動態自行調整該週期的時間，譬如當網路空閒時，減少週期使得每個封包能夠盡快的發送中斷被處理，而當網路流量很大時則會加大該該週期時間來更有效地處理封包。

註: AWS ENA 有支持這種動態調整的機制

作者基於 AWS 開啟動態調整收端中斷時間的功能，整個效能提升了 14%，從 834k req/s 提升到 955k req/s。作者說這次的調整可以說是整篇文章中幾個非常強的改動，改動的地方少，效能提升明顯，同時背後的隱憂與限制也少。

除了上述中斷的方式外，另外一種則是透過 Busy Polling 這種針對低延遲性的方式。預設情況下其允訓設定為 blocked 的 socket 能夠消耗額外的 CPU Cycle 來讀取接下來的封包，可以將其想成一成一種混合體，當底層網卡告訴我有資料要讀取時，我預期接下來還會有更多的資料，因此我就透過輪詢的方式去多問幾個封包。

由於作者的應用程式是使用 non-blocking 的方式去讀寫封包，所以預設的方式是沒有辦法使用的。而該應用程式又是使用 epoll 來進行底層封包的讀寫。 epoll 於 kenel 4.12 後正式支援 busy polling 的方式，所以這部分就沒有太大的問題。文章中有滿多關於 busy_poll 的一些參數調整。

將這兩個機制給整合後，整體的效能提升達到 28%，從 834k req/s 到達 1060k req/s，同時 99%的 latency 也從 361μs 下降到 292μs.

同時這兩個機制導入後，整個系統每秒產生的硬體中斷數量也從 183k 降到 16k。 Context switches 的數字也從 6k 下降到 1k 左右。

下篇文章會繼續從剩下的三個最佳化策略繼續介紹

https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/

本文延續前篇效能校正的經驗談，上篇文章探討了關於Locality與中斷中可以最佳化的部分，。本篇文章將繼續剩下最佳化步驟的探討。


The Case of the Nosy Neighbor
從前述最後的火焰圖中，作者觀察到幾個跟網路有關的 kernel call，譬如 dev_queue_xmit_nit 以及 __netif_receive_skb_core 等有可能有成長的空間，於是輾轉前往這邊去研究。
作者觀察到 packet_rev 這個函式有不少的比例，而該函式的意思是有人嘗試透過使用 AF_PACKET 等方式開啟了 RAW socket 來處理封包。透過 ss 這個指令，作者觀察到系統中有其他的應用程式透過 AF_PACKET/SOCKET_RAW 也在處理封包，最後輾轉發現原來是系統上的 dhclient。

DHCP Client 必須要在系統有 IP 以前就有收送封包的能力，所以使用 AF_PACKET 也滿合理的。作者思考是否有辦法可以讓 DHCP Client 拿到 IP 之後就關閉 AF_PACKET，改使用純 UDP 的方式來進行後續的 DHCP Renewal 功能，可惜這個方向沒有辦法達成。

根據 AWS 的官方文件，當一個 IP 被分配到一個機器後，這個 IP 會跟該機器同生死，因此這種情況下 其實不需要透過 DHCP Renewal 來反覆取得 IP，只要取得一次 IP 即可。

作者變修改相關腳本，當 DHCP 取得 IP 後關閉 dhclient，此外還必須要記得去修改網卡層級關於該 IP 的記憶，預設期間是一小時，作者將其修改為永遠。

透過這樣簡單的設定，整體的效能又再度提升了 6%，從 1.06M req/s 提升到 1.12M req/s

The Battle Against the Spin Lock
作者陳述自己花了非常多時間與 Spin Lock(作者心魔的大白鯨) 奮戰，幾乎是茶不思飯不想的滿腦都在思考如何加速，然後再經歷過反反覆覆的失敗後，作者最後決定還是要寫出一些關於 Spin Lock 的嘗試與研究心得，算是一個很精彩的踩雷心得。

這部分的篇幅很長，而且內容也滿深的，最後的解決方式也只有提升 2%左右的效能，所以對這部分有興趣的讀者再自行閱讀囉

This Goes to Twelve
終於來到最後的最佳化步驟了，這個步驟中的範疇都只能勉強壓榨出些許的效能，包含了關閉 GRO, TCP壅塞控制以及靜態中斷處理。


(Generic Receive Offload)GRO 是一個網路相關的功能，目的是用來將 Kernel 層級的封包給聚合起來變成一個大封包，而 Kernel 收到這個封包後會把該大封包重新組合變成本來的小封包，對於使用者的應用程式來說不會有任何感覺，但是對於整體的封包傳輸來說能夠節省花費的並提升效能。大部分情況下這個功能都是開啟的，Amazon Linux 2 預設也是打開這個選項。
然而針對作者的測試情境，由於所有的封包基本上都是同一條連線且資料量也不大，因此 GRO 雖然可以帶來聚合的效果，但是也會拖延封包進入到 Linux Kernel Network Stack 的時間點，因此開啟 GRO 帶來的好處沒有很大。

TCP 壅塞控制有不同的演算法，Amazon Linux2 內建兩種演算法 Cubic 以及 Reno，除此這兩個之外常見的還有 Google 多年前貢獻的 BBR。根據作者測試，其實驗環境中有比較好效能的則是 Reno

註: 不同算法針對不同應用場景，所以要切換演算法前要先釐清自己的應用情境以及用哪種演算法比較合適。

全部零零總總的修改後提升了 4%，整體的效能服務來到了 1.2M reqs/s

這篇文章真的很長，有些最佳化的方式是針對該應用場景而特別去使用的，這也意味者並非所有的修正方式都可以套用到各位的應用程式。
本篇文章還是很值得一讀，整個分析的思路與想法都非常有趣，雖然不一定用得到但是也許未來有一天會有機會使用。


https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/

本篇文章是個新手教學文(複習文)，主要探討 Kubernetes Resource 的使用，主要是 CPU 與 Memory 兩個資源的使用。
本篇文章中我覺得很值得大家再次注意的就是單位的使用，以 Memory 來說有非常多種的設定方式
1. 直些用數字表示，其單位為 Byte，譬如 1024 就是代表 1024 Byte
2. 可以使用指數表示，譬如 129e6，代表 129000000，也就是 129 MB左右
3. 使用固定的 Suffix，譬如 E,P,T,G,M,K。這個代表的是 10^N 次方，所以 1M 就是 10^6 Byte
4. 使用固定的 Suffix，譬如 Ei,Pi,Ti,Gi,Mi,Ki。這個代表的是 2^N 次方(每個級距都是2^10)，所以 1Mi 就是 2^20 次方 Byte，大概就是 1,048,576 Byte

所以 123Mi 接近 129M 也接近 129e6，而實際的數值則是 128974848 Byte 。

CPU 代表的則是 CPU 單位，對於 CloudProvider 來說，該單位則是所謂的 vCPU/Core，對於實體的 bare-metal 機器來說則是 1 hyperthread。
使用上除了直接表示多少單位的 CPU 外也可以使用 m (Milli) 的概念來描述 millicpu，也就是千分之一。
因此常常會看到 500m 的概念，其實就是 0.5 顆CPU,而 0.5 顆CPU則會因為底層不同可能代表 vCPU 或是 hyperthread。

https://medium.com/swlh/understanding-kubernetes-resource-cpu-and-memory-units-30284b3cc866

本篇文章是 Netflix 技術分享文(Netflix 真的滿多技術文章的)，本內容想要探討的是 Netflix 如何使用 eBPF 這個技術來洞察所有的網路流量與封包。

Netflix 開發了一個觀察網路流量封包的 sidecar 服務，稱為 Flow Exporter。這個服務使用 eBPF 來達到即時的 TCP 流量抓取，而產生額外的 CPU/Memory 都少於 1%，整體來說是非常好的表現。

挑戰
Netflix 目前使用 AWS 底層的網路元件來搭建其雲端網路基礎建設，包含了 AWS VPC, DirectConnect, VPC Peering, Transit Gateways, NAT Gatewats 以及 Netflix 自己的裝置與設備。
而 Netflix 的軟體基礎建設則是基於 AWS 搭建的一個大型的分散式環境，這些環境產生了下列挑戰
1. App Dependencies and Data Flow Mappings
隨者微服務架構的擴展，有愈來愈多的服務被部署，但是這些服務背後的彼此的依賴關係則是一個很難清楚描述的現象。開發與維運人員因為沒有辦法清楚的去定位這些資料，所以很多時候沒有很辦法很漂亮的去解決系統性的問題
2. Service Segamentation
因為雲端部署的簡單操作，導致整個環境內有愈來愈多的 AWS 帳號，愈來愈多不同的部署策略以及各種網路互相連接的需求。
3. Network Availability
隨者整個 Netflix 整個生態系的成長，如何瞭解當前網路效能的瓶頸以及可能潛在的問題是一個困難回答的問題。

為了解決上述的問題，Netflix 認為一個基於雲端網路流向的洞察工具必須要能夠針對維運與分析兩種情境去提供相關的資料，並且有辦法去找出當前的網路問題。
Netflix 目前會收集並分析不同來源的網路除錯資料，譬如
VPC Flow logs, ELB Access Logs 以及 eBPF flow logs 等，將其整理並分析後就可以傳給使用者或是內部不同的團隊來進行後續的除錯與處理。

Flow Exporter
本篇文章後半部分主要在介紹Flow Exporter 這個基於 eBPF 的 sidecare 是如何設計與運作的，其使用到了 Hive 以及 Druid 這兩種不同的 DB 來存放資料，對於這塊有興趣的可以再仔細閱讀全文。

https://netflixtechblog.com/how-netflix-uses-ebpf-flow-logs-at-scale-for-network-insight-e3ea997dca96?gi=d5fd990c9368

本篇是一個新手教學文，作者分享如何撰寫一個基於 Library 概念的 Helm Chart。

Helm Chart 的使用基本上不會太困難，透過 Helm Create 也可以很輕鬆地創造出一個範例 Helm Chart，針對該 Helm Chart 簡單修改也可以變成符合使用者需求的 Helm Chart。

作者工作中遇到一個要求，該要求要將一個 mono-repo 內的所有應用程式都變成 Helm Chart 的形式，該 repo 內大概有 10 個左右的應用程式，而這些應用程式部署所需要的資源都差不多，因此最簡單的方式就是創建十個幾乎完全一樣的 Helm Chart，透過 values.yaml 來客製化每個服務即可。

不過作者認為這種做法有點痛苦，要是未來需要針對這些k8s資源加上一些定義或是一些欄位，有可能就要 Copy&Paste 十次來處理所有的 Helm Chart。
為了解決這個問題作者就嘗試創建第一個 Helm Chart Library，只要到 Charts.yaml 裏面將 type 修改為 library 即可。(一般來說是 application)

作者特別提到，Helm 在處理部署的時候，只要檔案開頭為_，則該資源就不會被嘗試部署到 Kubernetes 內，這也是為什麼預設的 helper 會叫做 _helpers.tpl。

對於開發一個供其他 Helm Chart 使用的 Library Helm Chart 有興趣的可以參考這個文來看看一個簡單的範例

https://medium.com/nontechcompany/how-i-create-my-first-library-helm-chart-4f23caf5287d

本篇文章是一個深度介紹文，除了探討 K3S 與 K3D 的關係之外，還針對 K3D 的架構與使用方法很詳細的介紹一番，包含了
1. K3D v3 的特色與架構
2. 如何替換 K3D 裡面的 CNI
3. 如何替換 k3D 預設的 Ingress Controller
4. 使用 private registry 來處理

Kubernetes 的變化版本很多，除了 k3s 之外後來還有 k0s 的出現，每個版本都有自己想要解決的問題，而 k3s 則是一個非常輕量的 Kubernetes 版本，其特色有
1. 使用 Flannel 作為其預設 CNI，不講求太多複雜功能，單純用 VXLAN 打造一個 L2 的 overlay 網路
2. 使用 CoreDNS，與原生一樣
3. 使用 SQLite3 當作預設的 DB，而非 etcd3
4. 使用 Traefik 當作預設的 Ingress Controller，原生 K8s 則把這個主動權交給使用者
5. 使用 Containerd 當作預設的 Container Runtime

而 K3D 就是基於 K3S 的測試環境， K3S in Docker，跟 KIND 類似，只是運行的 Kubernetes 發行版本不同。

相較於 KIND 而已， K3D 的架構稍微複雜一點
1. 為了方便測試與存取，k3D 部署的時候也會部署一個 Nginx Server 來當作簡易的 Load-Balacner，讓 K3D 內的 Ingress 服務可以更簡易的被存取。使用者只需要存取該 Load-Balancer 即可，不需要去針對 Node(Docker) 的 IP 存取
2. 可以支援動態加入與刪除節點

本篇文章算是非常詳細的介紹各種參數用法，對於 K3D 這種測試環境有興趣的可以參考看看
https://yannalbou.medium.com/k3s-k3d-k8s-a-new-perfect-match-for-dev-and-test-e8b871aa6a42

Cloud Native 這個詞近年來非常熱門，CNCF 甚至也有針對這個詞給出了一個簡短的定義，然而對於每個使用者來說，要如何實踐這個定義則是百家爭鳴。我認為很認真地去探討到底什麼樣才算 Cloud Native 其實就跟很認真的探討什麼是 DevOps 一樣，就是一個沒有共識，沒有標準答案的問題。

本篇文章從 CNCF 的定義衍伸出 Cloud Native 帶來的優勢，並且針對這個領域介紹了十三種不同面向的科技樹，每個科技樹也都介紹了幾個常見的解決方案。

好處:
1. Speed
作者認為 Cloud Native 的應用程式要具有快速部署與快速開發的特性，擁有這些特性才有辦法更快地去根據市場需求而上線面對。眾多的雲端廠商都提供不同的解決方案讓部署應用程式愈來愈簡單，而 Cloud Native 相關的工具則是大量採用抽象化的方式去描述這類型的應用程式，讓需求可能更簡單與通用的部署到不同環境中。
2. Scalability and Availability
Cloud Native 的應用程式應該要可以無痛擴張來對面不論是面對一百個或是一百萬個客戶。底層所使用的資源應該都要根據當前的需求來動態配置，避免無謂的金錢成本浪費。此外自動化的 Failover 或是不同類型的部署策略(藍綠/金絲雀..等)也都可以整合到 Cloud native 的工具中。
3. Quality
Cloud Native 的應用程式建置時應該要保持不變性，這特性使得應用程式本身能夠提供良好的品質一致性。此外大部分的 Cloud Native 工具都是開放原始碼專案，這意味者使用時比較不會遇到 vendor lock-ins 的問題。

以下是作者列出來認為 Cloud Native 生態系中不可或缺的十三種面向，以及該面向中幾個知名專案。

相關領域
1. Microservices (Node.js/Kotlin,Golang)
2. CI/CD (Gitlab CICD/ Github Actions)
3. Container (Docker/Podmna/LXD)
4. Container Orchestration (Kubernetes/Google Cloud Run)
5. Infrasturcutre as Code (Terraform/Pulumi)
6. Secrets (Valut/Selaed Secrets)
7. Certificates (cert-manager/Google managerd certificates)
8. API Gateway (Ambassador/Kong)
9. Logging (EKF/Loki)
10. Monitoring (Prometheus/Grafana/Datadog)
11. Alerting (Prometheus Alertmanager/Grafana Alerts)
12. Tracing (Jaeger/Zipkin)
13. Service Mesh (Istio/Consul)

https://medium.com/quick-code/how-to-become-cloud-native-and-13-tools-to-get-you-there-861bcebb22bb

What Are Snowflake IDs?

Credit by: Wei-Yu Chen (感謝分享)

本文介紹了 Universal Unique Identifiers（UUIDs）的用途及其重要性，UUID 以固定且標準的方式為每個物件產生出獨立的 ID，且 產生出來的 ID 幾乎不可能會重複導致發生碰撞。

通常 UUID 由幾個部分組合而成，像是以時間、執行節點的 MAC address，或以 MD5 hash 來生成。UUID 以 128 bits 的數字組成，為了更方便識別及操作，通常都會以十六進制來表示，總長度為 36 個字（加上連字符號 -）。也因用來產生 UUID 的亂數種子包含了時間、節點資訊等參數，所以 UUID 也具有獨特性，在分散式系統執行也不容易發生碰撞。

而為了避免在你的 apps 裡實作 UUID 的產生機制，常見會使用兩種作法，分別是：Persistence Layer Generated ID 和 ID Servers。一種使用 Database 自動產生出來的序號來作為識別物件的 ID（如 MongoDB 的 ObjectID、MySQL 的 AUTO_INCREMENT ... 等），另一種是使用獨立的 ID server 來產生物件的 ID。

以 Database 來作為序號產生器會碰到一個問題，當你在每次建立新物件時，都會需要向資料庫讀取這個物件的「自動產生 ID」，假設應用程式的規模一大，效能勢必會大受影響。

而使用 ID server（也就是本文主要介紹的 Snowflake IDs）去產生 UUID 的話，就可利用架構於 app 以外的第三方序號產生器。以 Twitter 來說，平均每秒鐘有九千個推文，在高峰期間更甚至會出現一秒 143199 則推文的流量，他們所需要的 UUID 不僅要能夠支援龐大的架構，也需要在以非常快的速度產生出 ID，這也是 Snowflake 專案的由來。

因此，Twitter 以這幾個參數來組成 UUID：
- 保留不使用的位元，固定為 0 - 共 1 位
- Timestamp（以毫秒為單位） - 共 41 位
- 機器 ID - 共 10 位
- 序列號 - 從 0 ~ 4095 依序重複使用 - 共 12 位

雖然說以 ID servers 來產生 UUID 之後，效能還是會被這種架構拖累（必須在建立物件就去向 ID server 發送請求，並等待產生出來的 ID），但這種作法和資料庫系統相比起來已經讓效能降低的問題變得更輕微。

在本文當中介紹了三種常見的 ID 產生方式：在 local app 端產生 ID、在資料庫產生 ID、集中式的 ID server 產生 ID，這些策略的選擇也根據你的使用情境而定，畢竟沒有一種一套打天下的解決方案，在選擇時仍須衡量每個專案的需求。

https://betterprogramming.pub/uuid-generation-snowflake-identifiers-unique-2aed8b1771bc

ref: https://sysdig.com/blog/dockerfile-best-practices/
如果你常用到容器化、微服務架構，這些輕量化的架構當碰到問題時，背後的資安事件調查、報告、修復卻是影響甚鉅。然而，這些影響都可以透過「把安全意識擺在開發階段 (shifting left security)」來降低風險，而這篇文章就會講述 Dockerfile 的最佳實作手段有哪一些。
首先，我們會從幾個大面向來說明各種控制安全風險的細節，像是權限控管、降低攻擊層面、預防機敏資料洩漏，以及在發布 container image 時的注意事項。而你需要特別注意的是，其實 Dockerfile 也只是算是開發階段的一部份，所以這邊能提醒到的內容都屬於部署前（特別是開發階段）的準備。以下共提及 20 個你可以注意的重點，但因為篇幅較長，筆者將選出較重要的幾個來談談。
讓我們從「權限控管」說起：
Rootless container
根據報告結果顯示，有超過 58% 的 image 都是用 root 作為執行服務的使用者，所以在此也會建議透過 USER 參數來設定容器的預設使用者，同時，也可以利用執行環境/架構的設定來避免容器的預設使用者是 root。
Make executables owned by root and not writable
服務的 binary file 應該避免被任何人修改，容器的預設使用者只需要執行服務的權限，而不是擁有權。
至於「減少攻擊面」的部分：
Multistage builds小
在 image 的建立，可以透過 multistage build 來建立很多層 container，例如在第一層安裝編譯所需的套件，而第二層則只需安裝 runtime 所需的套件（如 openssl 等），再複製第一層所編譯出來的執行檔就可以了。其餘的因開發/編譯所安裝的套件皆不需要放在最後的 image，這樣同時也可以把 image 的大小縮小。
Distroless & Truested image
採用最小/最輕量化的 base image 來作為你打造 image 的基礎，同時使用可信任來源的 image，避免不小心在未知的情況引入好幾個潛在的安全威脅。（在原文中，sysdig 也使用了自身開發的工具來檢測 image 是否有安全問題，如果有需要也能參考看看）
而再來關於「機敏資訊」的部分：
Copy
當你在從你的開發環境複製檔案到 image 當中時，需要非常小心，因為你很可能一不小心就把你的密碼、開發環境的 token、API key 等資訊複製進去了。而且不要以為把 container 裡面的檔案刪掉就沒事了，別忘了 container image 是一層一層堆疊起來的，就算刪掉了，還是能在前面的 layer 裡面找到。
但如果還是有需要用到這些機敏資料，也可以考慮使用環境變數（docker run -e 引入），或是 Docker secret、Kubernetes secret 也能夠幫你引入這些參數。如果是設定檔的話，則可以用 mount 的方式來掛載到你的 container 裡面。
總而言之，你的 image 裡面不該有任何機敏資料、設定檔，開發服務時讓服務在 runtime 的時候可以接受來自環境變數的參數才是相對安全的。
其他的部分：
其實文章當中還有提到很多製作 image 的注意事項，像是在 deployment 階段，可能你部署的 latest 與實際的 latest 因時間差而不同。又或是在 image 裡面加上 health check，也才能做到狀況監測。
在容器化服務的時代，開發者不僅需要具備撰寫開發程式的能力，也要對於虛擬化環境有足夠的理解，否則，在對架構不熟的情況就將服務部署上去，或把 image 推送到公開的 registry，都可能造成重要的資料外洩與潛在的資安危機。

ref: https://medium.com/opentelemetry/opentelemetry-specification-v1-0-0-tracing-edition-72dd08936978

這篇文章主要是介紹 OpenTelemetry v1.0 版本的發展與演進

OpenTelemetry 專案希望能夠打造出一個符合 Cloud Native 開發與維運使用的系統框架，該框架席望能夠針對可觀性的三大指標進行一系列的整合與提供一個方便且一致的介面。三大指標分別是 Logging, Monitoring 以及 Tracing。

OpenTelemetry v1.0 主要的開發與修改都是針對 Tracing 這面向，其設計中認為 Tracing 的使用環節會包含三種不同角色，分別是應用程式開發者，應用程式部署維運者以及相關 Plugin 的開發者。

應用程式開發者使用 OpenTelemetry API 來控制應用程式 Tracing 相關的處理， v1.0 除了帶來功能的修改與開發外，對於整體的維護與支持也有相當的決心。當下次主要版本 v2.x 公開發佈後， v1.0 還可以繼續受到團隊至少三年的維護與支持，所以開發者三年內可以確保應用程式不會因為大大小小版本的修改而導致應用程式功能出問題。

而 OpenTelemertry SDK 則提供了供應用程式部署維運者與 Plugin 開發者要使用的框架與設定，這部分的維護時間則是有至少一年的時間(當 v2.0 出現時)。

包含了相關的 API 與 SDK 的使用。透過 OpenTelemetry API，開發者可以很輕易的去整合應用程式到 Tracing 的場景中。而當下次大版本 v2.0 出現

除了 Tracing 之外，目前 OpenTelemetry 團隊也持續的於 Monitoring 以及 Logging 兩方面來努力，從過去一年來看，整個專案的開源貢獻程度與速度都明顯比 2019 來得更為踴躍，也許這也代表愈來愈多團隊開始注重可觀測性的重要性，同時也有更多的開發者願意使用 OpenTelemery 作為使用工具。

ref: https://blog.devgenius.io/disaster-recovery-on-kubernetes-98c5c78382bb

作者認為即使那些知名的託管K8s服務(AKS/EKS/GKE)本身有提供各種機制來強化系統的存取性，但是作為一個正式生產環境的 Kubernetes 勢必還是要有一套災難復原的機制，因為有些災難並不是底層架構導致，有可能是人員的操作錯誤導致叢集內發生問題(譬如刪除整個 namespace).

隨者愈來愈多的團隊會將跨地區當作解決方案的一個考量時，要如何能夠找到一個簡單的備份還原機制來面對 Kubernetes 則是一個複雜的問題。 而本篇文章將會探討如何使用 Velero 來針對 Kubernetes 叢集進行備份，還原甚至是災難復原等操作，透過這類型的機制實際上也可以做到遷移 Kubernetes 叢集。

文章開頭作者提出了一個很值得注意的論點，就是高可用性(HA)的環境並不代表該環境擁有備份與還原機制。

HA 用來確保單一底層架構出現問題時整體服務不受影響，還是有能夠繼續存取既有的服務。但是假如遇到資料損毀或是其他意外刪除的，HA 的機制並沒有辦法讓這些服務可以復原。

所以就算系統是運行到 HA 的環境下，對於備份相關的解決方案還是需要準備，而且最重要的是這類型的解決方案不能只有準備，而是需要真的練習，嘗試復原，確保團隊熟悉整個還原的步驟，否則當問題發生時有可能會變成不知道要如何從備份資料來進行有效還原。

文章後半部分探討關於 Velero 的架構與使用，同時也列舉其他相關的專案，如

kube-backup
Cohesity
Kasten 10
Portworx PX-Backup]
Rancher Longhorn

對於 Kubernetes 備份還不熟悉或是團隊尚未導入的讀者可以嘗試使用看看 Velero

Ref: https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html

今天要探討的是一個由 Google Blog 於上個月所推廣的軟體安全性框架，該框架名為 SLSA，全名則是 Supply Chain Levels for Software Artifacts，中文部分我不知道該怎麼翻譯才可以精準達到意思，所以建議就唸英文就好了。

該框架的目的是希望於整個軟體生產鏈中能夠進一步的去提升且確保所有產物的完整性(Integrity 這個詞該怎麼翻呢..)。

文章中用了一個很簡易的流程來清楚的解釋到底何謂 Software Supply Chain 以及整個流程中可能會有什麼問題。

Software Supply Chain 一個範例譬如
1. 開發者撰寫程式碼，並且提交到遠方的 SCM Repository
2. SCM Repo 因為程式碼改變，所以觸發相關的 CI/CD 流程
3. CI/CD 建置結束後則需要打包整個程式碼，產生最後的 Package.
4. 產生後的 Packet 則可以正式上場使用

文章認為上述的流程中有兩個不同類別的安全性問題，分別是
1. Source Integrity
2. Build Integrity.

Source Integrity 這邊主要是針對 Source Code 相關的問題，譬如
1. 開發者是否有意的故意塞入一些會不懷好意的程式碼到 SCM Repo 內。
範例: Linux Hypocrite commits, 之前美國某大學研究團隊基於研究嘗試上傳一些不太好的程式碼而影響的討論風波
2. SCM 的管理平台是否可能被惡意攻擊
範例: PHP 事件: 之前自架的 PHP Git Server 被攻擊者惡意攻擊並且塞入兩筆不懷好意的 Commit

而 Build Integrity 本身則是有更多不同的面向，譬如
1. SCM 觸發 CI/CD 過程是否有可能有問題
範例: Webmin 事件，攻擊者去修改團隊的建置系統去使用沒有被 SCM 所記錄的修改檔案。
2. CI/CD 建置系統本身被攻擊
範例: SolarWinds 事件，攻擊者攻破建置系統去安裝一些軟體來修改整的建置流程
3. CI/CD 建置過程中引用到錯誤的 Dependency
4. 攻擊者上傳一些惡意產物到應該只有 CI/CD 系統才可以存取的場所。
... 等

目前來說， SLSA 還處於非常早期階段，經由業界的共識來思考每個領域有什麼好的措施與指引來避免與偵測系統是否被攻破。其最終目標狀態是希望能夠根據環境自動產生出一套可整合到系統中的產物，並且最後可以給出 SLSA 憑證來給平台或是建置後的 Package。

對 SLSA 這個專案有興趣看看的請參考原始連結，內容不長但是頗有趣的