標題: 「NPM 的 colors modules 打亂一堆人...」
類別: other
連結: https://research.swtch.com/npm-colors


NPM 上一個著名的 Module Color 以及 Faker 的作者這幾天生氣氣的修改這兩個 module，於 Color 內塞入了無限循環並且印出各種亂碼
然後所有使用這兩個 module 的工具一旦更新就會發現自己的 Terminal 輸出整個爆炸，完全看不懂了。

這篇文章是 Golang 的作者 Russ Cox 分享關於這件事情的一些看法，簡單來說每個開放原始碼的授權都有提到並沒有保固這種事情，所以任何現代化的模組管理者
設計時都必須要考量到這種版本更新的可能性，並且盡可能地去減少。

文章中以 aws-cdk 作為範例， aws-cdk 最初描述時是使用 ^1.4.0 的方式來參考各種 ^1.4.0 版本的 color，結果 color 的作者就直接爆氣來一個炸彈，aws-cdk 直接更新然後建置，最後
產生出一個令人崩潰的版本。

作者認為任何一個系統要更新的時候應該都需要緩慢與穩健的去逐步更新，並且這些更新都要經過一段時間的觀察與測試來降低各種可能放到生產系統出包的可能性。

以下節錄自文章中的重點
「High-fidelity builds solve both the testing problem and the gradual rollout problem. A new version of colors wouldn’t get picked up by an aws-cdk install until the aws-cdk authors had gotten a chance to test it and push a new version configuration in a new version of aws-cdk. At that point, all new aws-cdk installs would get the new colors, but all the other tools would still be unaffected, until they too tested and officially adopted the new version of colors.」

標題: 「Kubernetes, system-reserved, kube-reserved, cgroup 與 capacity, allocatable 的複雜關係」
類別: introduction
連結: https://www.hwchiu.com/k8s-capacity-allocatable.html

久違的原創文章，主要是探討到底 Kubernetes 節點上關於 Capacity 與 Allocatable 的關係為何？
Kubelet 是如何透過 system-reserved, kube-reserved 以及 eviction-hard 等參數來計算彼此的數值
以及最後又探討了到底 enforceNodeAllocatable 這個參數是如何將上述的概念轉換為 cgroup 的設定

如果你對 kubelet 的下列參數有一個不是很清楚的話都很推薦閱讀本篇文章，
- --system-reserved
- --kube-reserved
- --system-reserved-cgroup
- --kube-reserved-cgroup
- --enforce-node-allocatable

另外本篇文章沒有任何潤飾，所以有任何錯字或是語句不通順的地方就麻煩底下留言，我看到就會修正，感謝感謝

標題: 「The pains of GitOps 1.0」
類別: cicd
連結: https://codefresh.io/about-gitops/pains-gitops-1-0/


作者認為很多文章都闡述 GitOps 對於部署帶來的好處，但是軟體世界沒有十全十美的東西，所以作者就探討了 12 個其認為 GitOps 的缺點

註:
1. 本篇文章是 2020 年底的文章，所以文章探討的內容也許當年沒有很好的解決方式，但是現在已經有了比較好的處理方式。
2. 我個人覺得文章的某些部分有點太牽強，已經假設 GitOps 是個萬能解法，什麼問題都要靠這個。就這個問題是不管有沒有 GitOps 都會存在的問題，有點為了反對而反對，與其說 GitOps 的缺點不如說沒有解決的問題。


這邊就節錄幾個文章中探討的議題，剩下有興趣的可以閱讀全文

# GitOps covers only a subset of the software lifecycle
作者認為 GitOps 的精神「我想要將 Git 專案內的所描述的狀態給同步到叢集中」這點只能處理應用程式部署的問題，但是其他的流程
譬如編譯程式碼，運行單元測試，安全性檢查，靜態掃描等過程都沒有辦法被 GitOps 給處理。

作者不滿的點主要是很多 GitOps 的工具好像都會宣傳自己是個全能的解決方案，能夠處理所有事情，但是實際上卻沒有辦法。
實際上其專注的點就是應用程式部署策略為主的部分，其餘部分還是團隊要有自己的方式去處理

# Splitting CI and CD with GitOps is not straightforward
過往很多團隊都會將 CI/CD 給整合到相同的 pipeline 中去處理，通常是最後一個階段就會將應用程式給部署到目標叢集，然而有外部 Controller 實作的 GitOps
解決方案會使得 CI/CD 兩者脫鉤，好處來說就是 pipeline 不需要去處理部署，只需要專心維護 Git 內的資訊，後續都讓 Controller 來處理。

然後某些團隊本來的 CI/CD 流程會於部署完畢後還會進行一些測試或是相關操作，這部分會因為 GitOps 將部署給弄走導致整個流程不太好處理，畢竟要如何讓
GitOps 部署完畢後又要可以觸發其他的工作也是額外要處理的事情


# There is no standard practice for GitOps rollbacks
雖然 GitOps 的核心是透過 Git Commit 去控制當前部署的版本，那發生問題時到底該怎麼處理，如何去 rollback?
作者舉兩種範例
1. 讓 GitOps 去指向之前的 Git Commit
2. 針對 Git 使用 Git revert 等相關操作來更新最新的內容
作者認為沒有一個標準來告訴使用者該怎麼使用以及處理

# Observability for GitOps (and Git) is immature
作者認為目前現有的 GitOps 工具都沒有辦法提供下列答案
1. 目前生產環境是否有包含 Feature X
2. Bug X,Y 是否只有存在於 Staging 環境？ 還是生產環境也有？

註: 有什麼概念是天生就可以有這些東西的..? GitOps 有點無妄之災

標題: 「透過 Crossplane 與 ArgoCD 來達成應用程式與基礎建設的 GitOps 部署方式」
類別: cicd
連結: https://medium.com/containers-101/using-gitops-for-infrastructure-and-applications-with-crossplane-and-argo-cd-944b32dfb27e

作者表示過往很多教學文章當探討到 Kubernetes 部署議題的時候，通常都不會去探討如何部署 Kubernetes 而是專注於應用程式的部署，
理由非常直觀，文章就是要專注於 Deployment 的議題，能夠讓讀者更容易地去閱讀與參考，另外一個背後的原因其實是因為 Kubernetes 部署的方式
太多種，常見的方式使用 Terraform 透過 IaC 的概念來管理，而應用程式都使用 Helm/Kustomize 完全不同的方式來管理

而作者今天想要探討的是如何透過 ArgoCD 來建設一個 GitOps 的環境，並且於上面使用 Crossplan 這個解決方案來處理各種底層基礎建設的需求，如此一來
就可以統一透過 Helm/Kustomize 的方式來描述這些基礎建設

Crossplan 很類似 Terraform 但是有者一些些微的差異
1. Crossplan 本身是 Kubernetes 的應用程式，所以本身的描述方式就是 Kubernetes 的 YAML 方式
2. 可以使用 kubectl, Helm/Kustomize 等方式來部署這些描述並且讓 Crossplan 來幫忙創建描述的基礎建設

由於整個 Crossplan 可以視為一個 Kubernetes 應用程式，所以直接使用 ArgoCD 的方式來部署
有興趣的可以閱讀全文

標題: 「Kubernetes 內透過 DNS-01 處理 wildcard TLS 的兩三事」
類別: introduction
連結: https://medium.com/linkbynet/dns-01-challenge-wildcard-tls-certificates-on-kubernetes-d2e7e3367328

很多人都會使用 Kubernetes 的 Ingress 讓外部可以存取的部署的應用程式，同時會透過 Ingress 搭配 Cert Manager 來處理 TLS 的憑證
大部分情況下都會使用 HTTP-01 的方式來進行域名擁有性的認證，而某些情況可能不方便透過 HTTP 來驗證的話就會採取 DNS-01 的方式透過 DNS 創建一個
TXT 的資訊來驗證域名的擁有權，本篇文章則是作者分享 DNS-01 的一些心得分享

1. 文章開頭有介紹使用的 Stack，包含透過 Terraform 來架設模擬環境，並且使用 Scaleway DNS 作為 DNS Provider
2. Cert-Manager 部分的 DNS Provider 要採用 webhook 的方式來動態處理請求，當 cert-manager 偵測到有新的 TLS 憑證
需求時就會透過 webhook 的方式去創建遠方的 DNS TXT 紀錄，接者 Let's Encrypt 就會透過 TXT 來判斷你是否真的擁有個域名

對 DNS-01 使用有興趣的可以看看本篇文章

標題: 「Linux 5.17 將使用 BLAKE2s 來替代 SHA1 來達到更安全更快速的隨機亂數產生器」
類別: other
連結: https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.17-RNG

Linux Kernel 內亂數子系統的維護者近期遞交了一個將 SHA1 給全面替換為 BLAKE2s 的相關 Patch

相對於 SHA1 來說， BLAKE2s 本身更為安全，同時計算速度也更快，這邊也可以參考下列這篇 2017 的文章
https://valerieaurora.org/hash.html 來探討不同 HASH 演算法的一些狀態，雖然沒有及時更新到 2022 的狀態，但是如果 2017 都
不安全的東西現在就更不應該使用，譬如文章中提到 SAH1 於 2017 就被 Google 用(6500 CPU或是110 GPU)的實驗來證實有衝突，建議停止使用。

標題: 「透過 Kubernetes 內建 Event 來監控叢集狀況」
類別: Kubernetes
連結: https://www.cncf.io/blog/2021/12/21/extracting-value-from-the-kubernetes-events-feed/

這篇文章是介紹 Kubernetes 內建 event 的概念與用法，作者認為現在的監控與告警的訊息愈來愈多，這些訊息疲勞轟炸維運人員導致維運人員沒有辦法很精準地找到問題。
作者後來認為其實透過 Kubernetes 原生的 Event 就可以提供一些有用的訊息，其訊息精簡且種類不多，主要是針對 k8s 叢集的各種問題，能夠第一時間提供一些有用的資訊。

但是這些 event 可以透過 kubectl describe 來觀察或是直接使用 kubectl get event 來觀察，相對於 log 來說，event 的紀錄預設只會
保留一小時的時間，這就是為什麼使用 kubectl describe 只能觀察到最近的事件，所以如果要使用 event 作為資料來源整合到觀測系統或是告警系統的話
必須要有其他的系統幫忙收集這些 event。

實務上來說，作者認為觀測 Failed 以及 Scheduling 相關的事件為主，透過這樣可以快速地看到一些更靠近 k8s 的事件，然後文章後半部分介紹不少用來收集 event 的專案，如
1. KubeWatch
2. Event Exporter
3. EventRouter

有興趣的可以參閱全文

標題: 「PwnKit, 長達 12 年可以讓一般使用者輕鬆變成 Root 的 CVE」
類別: others
連結: https://blog.qualys.com/vulnerabilities-threat-research/2022/01/25/pwnkit-local-privilege-escalation-vulnerability-discovered-in-polkits-pkexec-cve-2021-4034

CVE-2021-4034 講述的是 pkexec 此工具的 vulnerability，其影響範圍非常廣大，主要原因有
1. 滿多系統預設都有安裝這個工具，而該工具預設有 SUID 的權限
2. 2009 後的版本就內建此安全性問題，所以請趕緊更新系統上的 pkexec
3. 任何使用者可以輕鬆地直接透過此漏洞變成 root 的身份，譬如你今天取得一個 nobody 的角色，你也是有辦法變成 root 的。

漏洞細節文章中有解釋非常多，主要是記憶體位置的處理沒有處理，當運行參數為空的時候，程式會意外地去讀取到後面的 envp 這塊用來存放環境變數的區塊，搭配
pkexec 後續的程式邏輯就有機會觸發本次 CVE 的安全性問題。
所以請趕緊更新系統上的 pkexec，確保該版本已經更新，否則任何一個使用者都可以輕鬆變成 root。

Ubuntu 使用者可參考 https://ubuntu.com/security/CVE-2021-4034

標題: 「視覺化系統內 iptables 規則」
類別: tools
連結: https://github.com/Nudin/iptable_vis

這是一個非常有趣的小工具，目標就是視覺化系統中的 iptables 規則，把 chain 之間的關聯給視覺化呈現出來
整個專案非常小，該專案主要會透過 awk 來解析系統中的規則並且產生特定輸出，接者使用別的軟體將該輸出給轉換成圖檔

有興趣的都可以使用看看

標題: 「如何使用 jq 讓你的 kubectl更為強大」
類別: tools
連結: https://medium.com/geekculture/my-jq-cheatsheet-34054df5b650

作者認為 kubectl 本身提供的 label-selector, go-templates, jsonpath, custom-colume 等各式各樣功能使這個工具變得強大，能夠找到符合自己需求的各式各樣資源
然而上述的這些指令使用起來還是會覺得卡卡的，並沒有辦法滿足所有條件，而且不同選項的語法也完全不同，所以對於操作者來說其實不太便利。

順利的是 kubectl 可以透過 -o json 以 json 的格式輸出結果，這時候就可以搭配 jq 這個指令來使用，相對於前述的各種用法，作者更加推薦使用 jq 來處理，因為 jq 是一個更為廣泛的工具，
除了 kubectl 可以搭配外，很多時候都可以搭配 jq 來處理其他情況，因此掌握 jq 的語法實務上會有更多用途。

文章幾乎都是以 kubectl 為範例來介紹 jq 內的各種用法，除了基本的 read/write/filter 之外，還有各式各樣 jq 的內建函式，
有興趣的都可以使用看看

標題: 「如何用 2297 個 Linux Kernel Patches 來重新整理所有的 header file 並提升整個 Kernel 建置時間高達 78%」
類別: 其他
連結: https://www.phoronix.com/scan.php?page=news_item&px=Linux-Fast-Kernel-Headers

摘要:
Linux Kernel 的長期貢獻者 Ingo Molnar 花了一年多的時間整理 Kernel 內的 Header 架構，一口氣提交了 2297 個 patches，其中影響
的檔案數量有 25,288 個，並且加入了 178,024 行數，移除了 74,720 行。
這一系列的改動直接重新整理 Linux Kernel 內將近 10,000 個不同的 header 檔案，這次的整理將過去 30 年累積的各種你呼叫我，我呼叫你這
種「Dependency Hell」問題給一起處理掉，結果論來說提升了整體建置時間 50% ~ 80 %

標題: 「視覺化系統內 iptables 規則」
類別: tools
連結: https://github.com/Nudin/iptable_vis

這是一個非常有趣的小工具，目標就是視覺化系統中的 iptables 規則，把 chain 之間的關聯給視覺化呈現出來
整個專案非常小，該專案主要會透過 awk 來解析系統中的規則並且產生特定輸出，接者使用別的軟體將該輸出給轉換成圖檔

有興趣的都可以使用看看

https://daniel.feldroy.com/posts/autodocumenting-makefiles

標題: 「透過一點小技巧讓你的 Makefile 有一個更好的 Help說明」
類別: tools
連結: https://daniel.feldroy.com/posts/autodocumenting-makefiles

本篇文章使用 python 搭配 Makefile 的內建語法來輕鬆幫你的 Makefile 加上各種 Help 訊息，整個概念滿簡單的
1. 每個 Target 後面都補上一個基於 ## 的註解說明
2. 使用 define/endef 來定義一個 python3 的內容，該 python3 會從 stdin 中去判別該 target 是否含有 ## 的字串，有的話就組合起來，並且輸出
3. 加入一個 help 的 target，將內建變數 MAKEFILE_LIST 給丟到上述的 python3 去執行

有興趣的可以看看，整個寫法非常簡單有趣。

標題: 「GitHub 上常常看到的奇妙 commit 到底是什麼？」
類別: others
連結: https://people.kernel.org/monsieuricon/cross-fork-object-sharing-in-git-is-not-a-bug

每過一段時間都可以於 GitHub 上面看到一些看起來很嚇人的 Commit，最經典莫過於 Linux Kernel 中的各種內容，譬如檔案被砍光，README 加入一些驚嚇言論
不知道情的使用者可能會想說這個內容是真正的 Github Repo 上的東西，鐵定是真正被認可而合併進去的，所以相信不疑。
殊不知這一切其實都只是 Git 的底層設計使得一些有心人可以打造出一些以假亂真的內容，文章中就有列出兩個關於 Linux Kernel 的有趣 Commit.

文章內詳細的去解釋整個來龍去賣以及底層 Git 的設計，包含 blob, tree, commit 之間的關係，並且說明為什麼有心人可以輕鬆的產生這些以假亂真的 Commit。
舉個範例來說，Linux Kernel 的整個 Git 專案大概有 3GB 的大小，然後被 Fork 的次數高達 40000 次，請問從實作方面來考量，你會希望
1. 每個 Fork 有一份屬於自己的 Git 專案?
2. 仰賴 Git 的底層設計，針對差異性去記錄每個 Fork 專案？

如果是選項(1)的話，那這樣至少要準備 120TB 的資料，從儲存方面來說完全不是一個可接受的實作方式，因此自然而然的都會是基於(2)的方式去實作
因此該 Linux Kernel 的 Git 專案實際上裡面記錄了所有的 Fork 資料，而每個人針對自己的 Fork 去進行更新等行為也都會記錄到 Linux Kernel 本身的專案上。
換句話說， 那 40000 個 Fork 出來的專案實際上還是共用同一份 Git 專案，因此每個人的 Commit 都只要該 Hash 被知道，其他人都有機會去檢視與瀏覽。

而 GitHub 的 UI 又允許使用者以 Commit Hash 的方式去瀏覽每一個 Commit 的內容，因此就可以跑到主要專案去輸入自己 Fork 產生的 Commit 來產生以假亂真的 Commit 內容。

對於整體有興趣的可以觀看全文

標題: 「 談談遷移應用程式到 Kubernetes 內的失敗經驗談」
類別: Kubernetes
連結: https://medium.com/@marcong_54227/unsuccessful-experience-of-migrating-applications-to-kubernetes-a896823d9b95

作者團隊於 2019 年要開發一個全新的 API 應用程式，當時部門的 IT 團隊計畫要將既有的 VM-Based 應用程式給轉換到 Container-Based，最後團隊使用了 RedHat 的系統，並且使用
OpenShift 做為容器管理平台。

從結果來看，該專案從 2020/05 一路到 2021/05 花了整整一年也沒有順利的將應用程式轉移到 OpenShift 中，其中的一些重點有
1. 初期建設時 RedHat 有展示過如何使用 Java 基於 Fuse 開發應用程式，但是作者團隊全部都是 .Net 的經驗，因此團隊花了很多時間來學習如何使用 Fuse
2. 2020/06 時因為團隊的進度緩慢，所以 IT 團隊尋找外部的軟體顧問，尋求如何將 .Net 從 VM 轉移到 OpenShift
3. 團隊內的開發者都不擅長學習新技術，對於學習新技術這一塊非常不行。
4. 外部團隊幫忙建置了 CI/CD 系統，然後團隊內從 2020/09 開始進行程式開發與轉移，可惜直到 2021/05 依然沒有半個產品成功的用 OpenShift 作為正式生產環境
5. 與此同時，外部團隊也撰寫了幾個 .NET 示範應用程式來展示容器化的注意事項，然而團隊本身對 Container 的知識非常薄落，所以團隊人員沒有辦法參考這些範例程式來改善自己開發過程

最後團隊內又針對不同團隊給予不同的想法
1. Application Team
2. Server Team
3. Network Team
4. IT Management Team

譬如 Application Team 的開發人員都只滿足自身的技能，而且拒絕學習新技能，誇張的是一年過後團隊內的人也沒有辦法撰寫 dockerfile 或是使用 docker build.

後續還有一些針對不同團隊的想法與總體建議，整體來說非常真實，一個血淋淋的轉換案例。

標題: 「 Kubernetes 四種不同開發環境的比較」
類別: Kubernetes
連結: https://loft-sh.medium.com/kubernetes-development-environments-a-comparison-f4fa0b3d3d8b

根據 VMware 2020 的一個研究報告指出，如何存取 Kubernetes 叢集是影響開發者生產效率的最大要素，所以本篇文章就是就會針對如何去評估與挑選一個適合開發者的
Kubernetes 叢集與存取方式。

作者將 Kubernetes 叢集分成四大類，分別是
1. Local Cluster: 開發者會基於自己本地的電腦來創造一個本地的 Kubernetes 叢集
2. Individual Cloud-Based Cluster: 開發者基於雲端環境來創建一個專屬於該開發者的 Kubernetes 叢集
3. Self-Service Namespace: 使用基於 namespace 的方式來讓多位開發者共享一個 Kubernetes 叢集
4. Self-Service Virtual Cluster: 讓 Kubernetes 來創建更多小 Kubernetes 叢集並且讓每個使用者有獨立專屬的 Kubernetes 叢集

為了比較這四種不同的叢集，作者定義了幾個不同的面向，針對這幾個面向來評比，分別是

1. Developer Experience: 對於開發者來說要如何開始使用叢集，包含架設的複雜度，使用的難易度以及需要的相關背景多寡
2. Admin Experience: 對於公司的管理人員來說需要花多少心力來管理該從開發者環境，除了基本的管理還要考慮增加新使用者帶來的負擔
3. Flexibility/Realism: 該開發環境與正式生產環境的架構相似度如何，此外開發者是否有足夠的彈性去客製化該叢集的所有設定
4. Scalability: 該環境是否能夠根據開發需求來擴充？ 特別是針對部分需要大量使用資源的應用程式開發是否有辦法處理。
5. Isolation/Stability: 開發者彼此之間的隔離程度如何，彼此之間的工作是否會影響彼此？ 有資安問題的時候是否會連環爆？
6. Cost: 該解決方案的成本多寡，成本就是真正的金錢考量。

文章一開始就有列出一個結論表，對於這個議題有興趣的歡迎閱讀

標題: 「 取代 Docker Desktop 的高效率開發環境」
類別: Container
連結: https://medium.com/partoo/replacing-docker-desktop-with-a-more-efficient-development-environment-582c61c50984

作者認為 Docker Desktop 是一個非常好的開發環境工具，能夠簡化很多設定讓開發者更容易的開發應用程式，但是對於 Windows/Mac 的使用者來說
Docekr Desktop 實際上也是先運行一個基於 Linux 的 VM 並且於其中運行 Docker Container。這種架構實際上帶來了一些使用上的缺陷，包含
1. FileSystem 的處理效能非常不好，不論是使用 cahced 或是 gRPC-fuse 檔案系統還是沒有辦法得到很好的效能。
2. 資源使用有問題不如預期，作者設定希望最多使用 6GB 結果最後卻使用到了 15GB，幾乎吃光系統所有記憶體
3. 官方幾乎沒有文件去探討該 VM 的存取方式(雖然滿多人會用 nsenter 進入)，所以很難把一些本地檔案給直接放到 VM 內來提昇儲存相關的問題，變成所有的儲存都只能用 docker volume 來處理。

作者的公司 Partoo 採取了 VM + Vagrant + Ansible 的方式來創建開發者環境，讓每個加入團隊的開發者都可以輕鬆簡單的建設期開發環境
並且文章中也探討如何於本地端使用 Vistual Studio Code, PyCharm 來編輯 VM 的檔案並且順利的進行應用程式開發。

從效率來看，相對於直接使用 Dodcker Desktop 來看，作者團隊的測試程式基於自己的 VM 提升了將近 30% 的效能，主要的問題就是儲存系統與 Docker Container 之間的掛載關係差異。

標題: 「macOS 的 fsync 實作其實跟大家想像的完全不同 」
類別: others
連結: https://mobile.twitter.com/marcan42/status/1494213855387734019?t=TyXUEg-2LcbNiKkv0JVOsg&s=09

以下節錄自該留言串
「As it turns out, macOS cheats. On Linux, fsync() will both flush writes to the drive, and ask it to flush its write cache to stable storage.

But on macOS, fsync() only flushes writes to the drive. Instead, they provide an F_FULLSYNC operation to do what fsync() does on Linux.」

簡單來說就是 Linux 的 fsync 會執行兩次動作，最終讓當次修改給寫回到底層儲存設備，而 macOS 的版本卻不會真的確認寫回硬碟，所以這個導致很多仰賴 fsync 的應用程式就會有一些不預期的行為，這也是為什麼首篇發文的內容
「Well, this is unfortunate. It turns out Apple's custom NVMe drives are amazingly fast - if you don't care about data integrity.

If you do, they drop down to HDD performance. Thread.」

標題: 「Paypal 如何調整 Kubernetes 讓其規模達到四千節點，20萬個 Pod」
類別: usecase
連結: https://medium.com/paypal-tech/scaling-kubernetes-to-over-4k-nodes-and-200k-pods-29988fad6ed

摘要:
Paypal 過去一直都使用 Apache Mesos 來運行其大部分的服務，而其最近正在針對 Kubernetes 進行一個評估與測試，想瞭解如果需要轉移到 Kubernetes 會有哪些問題需要挑戰與克服。
本篇文章著重的是效能問題，原先的 Apache Mesos 可以同時支持一萬個節點，因此 Kubernetes 是否可以拿到相同的效能
而本文節錄的就是擴充 Kubernetes 節點中遇到的各種問題以及 Paypal 是如何修正與調整讓 Kubernetes 可能容納盡可能更多的節點。

# Cluster Topology
1. 三個 Master 節點與三個獨立的 ETCD 叢集，所有服務都運行於 GCP 上。
2. 工作節點與控制平面的服務都運行於相同的 GCP Zone 上。

# Workload
效能測試方面是基於 k-bench 去開發的測試工具，基於平行與依序等不同方式來創建 Pod/Deployment 兩種資源。

# Scale
1. 測試初期先以少量的節點與少量的 Pod 開始，接者發現還有提升的空間就會開始擴充 Pod 與節點的數量。
2. 測試的應用程式是一個要求 0.1m CPU 的無狀態應用程式。
3. 最初的工作節有點 4 個 CPU，根據測試可以容納大概 40 Pod 左右。
接者就是不停地擴充數量，先從一千個節點開始，接者調整Pod 的數量直到 32,000 個 Pod。最後擴充到 4,100 個節點並且配上 200,000 個 Pod.
過程後期有調整節點的 CPU 數量讓其能夠容納更多的 Pod 數量

文章接下來開始針對 API Server, Controller Manager, Scheduler, ETCD 元件遇到的問題並且如何解決，中間提到了不少參數，這部分應該是大部分使用者都比較不會去研究與使用的參數
因此我認為本篇文章非常值得閱讀。
ETCD 的部分遇到很嚴重的效能問題，作者團隊觀察到大量的 Raft 溝通失敗個訊息，觀測到跟硬碟寫入速度有關，然而 GCP 沒有辦法單純增加效能，必須要同時提升硬碟空間，所以使用上彈性不變。
不過就算採用 1TB 的 PD-SSD ，當 4 千個節點同時加入到 Kubernetes 時依然會遇到效能上的問題，團隊最後決定使用本地端的 SSD 來想辦法改善寫入速度，結果又遇到 ext4 的一些設定
過程很多問題也很多解決方式。

結論來說: k8s 複雜

標題: 「ClickHouse 與 Elasticsearch 的比較」
類別: other
連結: https://developer.aliyun.com/article/783804

這篇文章內容非常精彩，從不同層面去探討 Elasticsearch 與 ClickHouse 這兩套解決方案的差異，探討了包含
1. 分散式架構
2. 儲存架構，包含寫入資料的設計，底層 Segment 與 DataPart 的差異以及 Schemaless 特性帶來的影響
3. 查詢架構，包含底層引擎是如何計算使用者的輸入
4. 效能測試，針對不同的場景來比較效能

文章很長且滿多技術坑，適合對於 Elasticsearch 有維運與管理有經驗的使用者

標題: 「大家總是喜歡誇大自己的工作時數」
類別: other
連結: https://drmaciver.substack.com/p/people-dont-work-as-much-as-you-think

本篇是一個心態探討文，作者探討了到底一天的有效工作時間有多少，並且認為人們宣稱的工作時間通常都不准，很多時候只是一種想要讓人看到自己工作很久的心態而已。
從作者的經驗來說，作者認為軟體開發，作家，顧問等行業都會有這類型的特性，一個有效率的工作者其實根本不可能一整天連續工作八小時。
一開始作者先列舉自己一天可以達到的事情有哪些(可達到不代表全部都會做)
1. 1-2 小時的重度耗腦力工作，如果事情沒有太複雜有時候可以到三小時左右。
2. 不太動腦 code review 或是閱讀不會花費太多精力，整體來說算可以輕鬆進行
3. 4 小時的面對面教學與指導
4. 4-6 小時左右的常規工作，譬如重構程式碼
5. 4-6 小時左右的沈浸式工作，譬如研究一個困難的 Bug。這類型的工作通常需要當天身心狀況良好同時也沒有人會一直打斷你，通常一年中發生的次數不太高。

總體來說，作者一天認真工作的時間大概就是四小時左右，當然有需求時當然可以提升整體的工作量，不過作者認為這會影響身心健康，所以不是很喜歡。作者也認為「愈需要創作的工作其實真正工作的時間愈少」
很多工程師看起來工時很長其實有時候上班也都在滑 Twitter, Reddit 等各種網站，真正的工作時長其實都不如自己宣稱的。因為每個人的精力有限，不可能長時間執行高度專心的工作，很多時候花一堆時間去拼工作量結果得到的是每件事情都辦不好，
與其如此不如找到一個適合自己的工作方式，讓自己能夠有效率地去做好每件事情。

這邊要特別注意的是
1. 請評估自己每天到底可以工作多少小時，然後不要嘗試工作超時
2. 不要因為自己的精力與工作時數多寡而感到羞愧，好好面對自己
3. 不要為了那些會打破你上述規則的工作而加班

如果今天有人要丟工作給你，請友善禮貌地回答「我很願意幫忙你，不過我目前手頭上正在忙 XYZ，你想要做的事情優先度有比較高嗎？」

最後作者針對工程師列出一個不同類型工作的適合工作時數

1. 1-2 小時的專注工作，如 coding, debugging
2. 1-2 小時的無腦工作，如參加會議， code review
3. 1-2 小時的"可被找到"的時間，譬如 Slack 上可以被找到，可以回答各種問題
4. 結論來說一天工作不會超過四小時