題: 「CNCF 2021 年度報告」
類別: usecase
連結: https://www.cncf.io/reports/cncf-annual-survey-2021/

# 結論
1. 全球有愈來愈多的公司採用容器化或是Kubernetes來管理應用程式，其中以大型企業有更為明顯的使用趨勢
2. 如同 Linux 一樣， Kubernetes 正在轉變為一個如同基本概念般的存在，愈來愈多的公司使用託管平台
3. CNCF 同時也觀察到愈來愈多組織逐漸導入各式各樣的 Cloud Native 專案來處理各種問題，譬如監控維運等

# Container/K8s 的使用報告
Datadog 的 2021 Container 報告顯示有高達 90% 的 Kubernetes 使用者採用的是由雲端管理的 Kubernetes 服務，相較於 2020 的 70% 有明顯成長
至於有將近 40% 使用容器化的公司使用 Amazon ECS(Fargate)，相較於 2020 的 35% 也是有小幅度成長。

CNCF 自己的報告則是有 79% 的使用者都是使用經過認證的 Kubernetes 管理平台，其中 EKS 39%, AKS 23% 以及 Azure Engine (17%). -> 幫 GKE 哭哭



# Serverless 報告顯示
Datadog 的 2021 Serverless 顯示 Lambda 的功能使用次數相較於過去兩年來提升了 3.5 被，而這些使用量中以 Amazon Lambda 為大宗，此外 Azure Functions
以及 Google Cloud Functions 也都有明顯的成長。

SlashData 的報告則指出 Amazon Lambda 佔了所有 Serverleess 解決方案中的 53% 使用量。


# 隨者 Kubernetes 變成一個穩定且成熟的主要技術，愈來愈多的組織基於 Kubernetes API 與其介面來導入各種 Cloud Native 的技術

從 Datadog 的報告來看，相對於 2020 來說， 2021 的成長率
1. Containerd: 500%
2. Envoy: 39%

從 New Relic 的報告來看
1. Prometheus: 43%
2. FluentD: 53%

標題: 「透過 Helm 與 Terraform 來自動 Re-new Cloudflare origin CA」
類別: usecase
連結: https://awstip.com/auto-renew-cloudflare-origin-ca-with-terraform-and-helm-d28be3f5d8fa?source=linkShare-91a396987951-1645539866&gi=a18b2bbd9604

本篇文章是過工具介紹文，探討如何基於 Helm 與 Terraform 這兩個不同層級的工具來處理 Cloudflare 的憑證。

# Why Cloudflare
根據 W3Techs 的調查顯示， 81.2% 的網站都使用 Cloudflare 來提升讀取速度或安全防護。
透過 CDN 的概念與機制，網站可以讓全球使用者有更快的讀取速度，此外也愈來愈多的網站會透過 Cloudflare 來處理如機器人, DDOS 之類的流量攻擊，畢竟要自己架設網站處理這些攻擊非常困難
因此讓 Cloudflare 這類型的網站來幫忙過濾與處理能夠讓團隊更專注於本身的業務開發與維運

# Kubernetes
想要在 Kubernetes 內妥善管理所有使用的憑證其實也是一個麻煩事情，除了要能夠設置正確來創立憑證外，能夠於到期前自動 re-new 也是一個不可或區的功能。
Kubernetes 內跟憑證有關的最知名專案我想就是 Cert-Manager，而 Cloudflare 也基於此專案撰寫了相關的 Kubernetes Controller，如 Origin CA 等
因此本文使用的功能與示範都會基於 cert-manager 與 Cloudflare 的架構。

# 目的
本文的目的是希望能夠將過往手動的繁瑣步驟給自動化，讓 Kubernetes 可以獲得 Cloudflare 提供的好處，如憑證與相關域名等。
內文是基於 Terraform 作為出發點，然後透過 Kubernetes Provider 的方式來與之互動，一步一步的安裝各種資源最後成功於叢集內獲得相關域名的 SSL 憑證以及其他資源

標題: 「如何判別到底要不要使用 Service Mesh」
類別: Network
連結: https://medium.com/google-cloud/when-not-to-use-service-mesh-1a44abdeea31


本篇文章是一個經驗探討文，想要探討近年來非常熱門的網路網格(Service Mesh) 到底導入時要怎麼抉擇與判斷。
Service Mesh 如果用得正確與適當，能夠為團隊帶來很多優勢，可以讓團隊更專注於軟體的服務上，讓 Service Mesh 幫忙提供各種方便的功能。
但是如果使用錯誤則可能只會造成整體架構更加複雜，同時也沒有解決什麼真的重點問題，一切只是疊床架屋的空殼而已。

1. 採用 Service Mesh 要儘早
作者認為到底要不要導入 Service Mesh 是一個專案初期就要決定的事情，即使 Istio 網站有特別教學如何將專案從 non-MTLS 給轉移到基於 Istio MTLS 的過程
但是作者說真的跑過這些流程就知道絕對不是官網寫的三言兩語這麼簡單，有太多額外的事情要考慮，譬如上層安裝的服務，網路分層設計等，這些會因為有沒有 Service Mesh
而有不同的決定

2. 不要當 Yes Man
作者體驗過最多的案例就是每個團隊看到下列問題都是不停的說 YES，然後最後就直接無腦導入 Service Mesh
1. 我們需不需要強化資安
2. 使用 mTLS 能不能強化資安
3. mTLS 是不是很難管理
4. Service Mesh 是不是可以讓 mTLS 便於管理

連續四個 YES 下來就直接無懸念的導入 Service Mesh，殊不知

因此作者接下來就列出幾個要導入 Service Mesh 前需要仔細思考過的問題

1. 是否有計畫於當下或是未來使用到 Serivce Mesh 的所有功能
Service Mesh 的功能除了 mTLS 外還有各式各樣跟流量有關的管理，譬如 A/B Testing, 金絲雀部署等。
透過 Service Mesh 能夠讓應用程式不需要實作這些功能而依然可以享有這些功能的好處。
所以作者認為團隊中的所有人都要仔細的注意，到底你們即將採用的 Service Mesh 有哪些功能可以用，這樣可以避免應用程式重複開發相同功能。
作者也提到不需要第一天就決定好要採用什麼功能，但是至少要仔細理解自己採用的解決方案到底有什麼功能，然後未來改善架構的時候可以即時的想起來這功能有提供

2. 團隊中是否有人對於 Service Mesh 有足夠的理論或是實戰理解？
作者看到的非常多團隊很多人根本不理解 Kubernetes 以及 Service Mesh 但是就想要導入 Service Mesh。
由於對 Service Mesh 完全不理解，連其實作的概念都不同，所以當問題發生的時候就什麼都不能做，因為根本不懂也不知道該從何下手
請花時間學習與理解你要使用的專案，以確保你有足夠的背景知識去使用與除錯

除了問題之外，作者也認為要導入 Service Mesh 到生產環境並不是單純的建構一個 Hello World 這麼簡單，還有很多事情要考慮，譬如
1. 自動化
2. 監控與追蹤
3. 除錯與已難雜症排除

整篇文章非常的棒，有興趣的可以詳細閱讀

標題: 「Package Maintainers 應該要具備的資安概念」
類別: other
連結: https://sethmlarson.dev/blog/security-for-package-maintainers

本篇文章的作者是 python3 urllib3 套件的主要維護者，由於近年來軟體供應鏈的資安議題逐漸受到重視，特別是這些已經被廣泛使用的套件，一套受到入侵與修改，其影響危害程度難以想像
作者撰寫本篇文章分享自己的想法希望能夠讓所有套件維護者有一些基本的資安觀念，同時也讓所有使用 OSS 的使用者一起學習

# 捐贈給開源貢獻者
作者提到本文提到的所有資安意識都需要花時間精力去實作與維護，如果你的組織使用了大量的開源專案但是本身在意資安卻又不想要花時間研究資安，那就花點小錢捐贈給這些開源貢獻者，讓這些貢獻者有更多的動力去幫你維護這些套件。
如果該開源專案對於你公司來說有非常舉足輕重的角色，那甚至可以考慮雇用一兩個該專案的主要維護者讓他們定期分配時間來維護，對公司來說只是花一些小錢但是卻能夠有更有信心的使用這些開源專案，以免哪天這些專案一炸整個公司產品全炸

文章主要分成兩大類，分別是
1. 如何保護好你的個人帳戶
2. 如何保護好你的套件倉庫

# Securing Your Accounts
對於一個套件維護者來說，你的個人帳號由於有超級大的權力，所以該帳號的資安管理必須是最高層級的注意，一但這個帳號被攻破，攻擊者就可以很輕鬆的去發布新版本，加入惡意程式碼等各種行徑，而通常使用者如果本身使用時沒有很好的限制版本，譬如採用大於1.1.0 這種比較寬鬆的用法就會不自覺升級而使用到危險版本
作者強調就算你本身不是套件維護者，這些帳戶保護方式對你來說也是非常實用的，良好的資安保護永遠不吃虧

接下來作者列出幾個大項，分別是
1. Email Securiy Is Your Top Priority
Email 地址很重要，很多情況下這些地址都會是重設密碼的一個途徑，所以妥善保存 Email 地址是非常重要的，所以作者推薦使用那些大公司服務如 Gmail 與 Outlook。 如果你真的想要使用私人域名作為你的聯絡信箱，你就要保證你不會有忘記付費的那天，不會剛好有人買走你的域名然後順利的取走你的 Email 地址。
2. 2FA
2FA 要求提供一個除了密碼以外的認證方式，常見的有手機或是一些硬體裝置，使用妥當的話基本上攻擊者很難登入你的帳號。
作者認為所有跟程式碼有關的帳號密碼最終都需要有一個不使用 SMS(簡訊) 的 2FA 機制保護，譬如 NPM 最近才宣布其 Top 500 的套件管理都需要強迫使用 2FA，作者希望 Python 有天也可以跟上這種趨勢。

3. Password Managers
4. Hardware Keys
5. Why Not SMS 2FA
6. Where Do I Put My Recovery Codes
7. What to do if your account is compromised?

上述範例我就不列出來了，每個項目都沒有很長，非常推薦大家閱讀，甚至可以讓團隊的所有工程師都有這些基本概念

標題: 「Facebook 內的文化特別之處」
類別: usecase
連結: https://chinese.catchen.me/2022/02/unique-engineering-culture-of-facebook.html

作者作為一個 Meta 工作七年的員工，分享了一些認為 Facebook 頗有特色的文化，這些特色文化並沒有辦法直接斷言是好是壞，一切都是看用什麼角度去看待。

# 工程師對產品結果負責
年度績效評估時要如何去評估一個工程師的績效一直都是個不簡單的問題，作者提到對於 Meta 內部的高級工程師(不確定正確級別代號是什麼)來說，其績效並不是單單的只去看技術用的好不好，程式寫的好不好
更多的反而是這個產品是否有真正的商業成長結果。

作者認為這種鼓勵從下而上解決問題的思路能夠讓產品的發展更佳有效率與有意義，舉例來說
假如今天工程師的績效是完全基於技術方面的呈現，而專案負責人(PM)的績效可能是該專案對於使用者的黏著度，兩者績效不一致的情況下很容易發展出不同的開發與演進策略
工程師為了達到自己的績效其發展的路線就不一定可以為產品帶來更好的使用者黏著度，反之亦然，為產品帶來更好使用者黏著度的改善並不一定可以讓工程師看到很好的表現績效。

但是一旦當工程師與 PM 的目標一致，整體的合作就會更加融洽也目標，這也是為什麼 Meta 的工程師非常了解自己產品的指標跟數據，還會花時間去分析產品數據與使用者分析報告，透過自己的理解來思考到底要怎麼去改善產品的方向，而不是完全等待 PM 發號司令。

# 基礎架構被視為一個產品販售

Meta 內部的基礎架構某程度也被視為是一個產品，公司內的其他工程團隊則是該產品的潛在用戶，所以開發該產品的團隊本身也要努力的去推銷這個產品，去說服為什麼要使用這個架構，使用這個架構能夠帶來什麼樣的好處。
作者以早期的 Reat, React Native 為範例，早期該產品於公司內推廣也是四處碰壁，並非外部所想像的一推廣就廣受歡迎與嘗試。

由於基礎架構被視作是產品，所以如果其「商業」表現不如預期的話，該專案也是會被砍掉的，這類型的模式搭配上述的概念其實非常有趣

所有的專案都想要長期存活都必須要證明其有價值，就算是內部架構也要證明其對內部其他工程團隊有價值
這種方式也降低了「只專注技術而不考慮使用者需求的」的開發方式，這讓我想到大家最愛講的「Service Mesh」.... 帶來什麼效應不確定，但是很潮就是享用...，

標題: 「Terraform 生態下的五個相關輔助工具」
類別: terraform
連結: https://betterprogramming.pub/5-essential-terraform-tools-to-use-everyday-e910a96e70d9

隨者 IaC 的概念落地開花，愈來愈多團隊嘗試使用 Terraform 來管理各式各樣的 infrastructure，作者本篇文章分享五個自己每天使用的 Terraform 輔佐工具，分別是

1. TFSwitch
2. TFLint
3. Terraform-docs
4. Checkov
5. Infracost

TFSwitch: 如果環境中目前因為歷史因素沒有辦法統一轉移到相同版本的 Terraform 使得你必須要用不同版本的 Terraform 來處理不同的專案的話，可以透過 TFSwitch 來幫助你快速地切換版本

TFLint: 就如同大部分的 Lint 工具一樣， TFLint 針對 Terraform 的工具，特別是跟特定 CloudProvider 整時候會有更多的錯誤偵錯，將該工具整合到 CI/CD pipeline 中更可以幫助團隊避免合併一個有問題的 Terraform code.

Terraform-docs: 這是一套能夠將你的 Terraform module 直接產生對應 Markdown 格式文件的工具，如果本身有撰寫 Terraform Module 的團隊都可以使用這工具試試看，看看產生的文件是否可以滿足基本需求

Checkov: 這是一套支援 Terraform 的靜態程式碼掃描工具，可以用來檢查是否有可能的安全性漏洞與不良好的設定，目前預設大概有 750+ 以上的預設規則，

Infracost: 這工具會的目的就如同專案名稱一樣，根據創造的雲端資源幫你估計這些資源的實際花費，對於要控管成本的團隊來說，可以提供一個粗略的金額概念，畢竟如網路流量等相關付費還是要實際上線才知道，但是可以快速地針對不同的 infra 直接列出大概的金額差異，搭配得宜對於整體工作流程還是有幫助的。

標題: 「為什麼 3A 大作的遊戲室都不愛喜歡使用 STL」
類別: usecase
連結: https://mobile.twitter.com/m_ninepoints/status/1497768472184430600

熟悉 C++ 語言的讀者必定聽過 STL，而本篇推特系列文則是用來解釋為什麼 3A 大作的遊戲室都不愛使用 STL，這邊節錄一些概念與想法

1. STL 的實作通常會因為不同平台與編譯器而會有不同變化，但是對於遊戲業者來說很多時候會希望能夠針對所有平台能夠有一個統一一致的實作
2. 跨平台的統一實作對於開發者來說可以帶來很多好處，譬如除錯可以更有效率，不需要針對每個平台獨立研究問題
3. STL 由於不同平台的實作方式都不同，所以發生問題或是要客製化都會變得稍嫌麻煩，變成還要根據平台去研究與處理，整體來說就是煩
4. 某些情況下 STL 的實作是犧牲效能來完成的，但是效能反而是業者所需要的

覺得本篇推文非常有興趣，對這系列有興趣的可以看看大家的討論

標題: 「一個用來管理 Kubernetes 開源工具的開源工具」
類別: tools
連結: https://github.com/alexellis/arkade

作者因應過去於 Kubernetes 的教學與開源過程中，必須要一直不停地去安裝各式各樣必備的工具而感到厭煩，譬如每次都要安裝 kubectl, kind, kubectx 等各種常見工具
而每個工具又會有不同的版本，每次都要專寫相關的安裝流程都很麻煩，因此作者萌生出開發一個能夠安裝這些工具的開源工具, arkade
.

該工具用起來非常簡單，同時也支援不同版本的工具，除了基本 CLI 工具外也支援 Helm App 的安裝，我個人認為光工具本身就非常好用了，譬如可以透過該指令輕鬆的安裝不同版本的下列工具
1. dive
2. helm
3. gh
4. jq
5. k3d
6. kind
7. kubectl
8. k9s
9. kail
10. opa
11. terraform
...

如果你常常需要撰寫文件去分享安裝各種文件的需求，也許可以考慮使用看看此工具來簡化流程

標題: 「如何於 Docker 環境中運行 rootless 模式」
類別: container
連結: https://thenewstack.io/how-to-run-docker-in-rootless-mode/

雖然可以使用非 root 的方式去安裝 Docker 服務，但是 Docker 本身服務中還有其他各種元件需要透過 root 身份去運行，譬如 dockerd, containerd, runc 等元件，
而本篇文章則是探討要如何以真正 rootless 的方式來運行一個 docker container 。

使用 rootless container 有一些要注意的事情，譬如 port number 沒有辦法使用 1024 以下，所以如果你的服務有需要被外界存取時要使用大於 1024 的 port number。
此外 AppArmor, host network mode 這些都不支援，因此使用上會有一些情境要注意。

安裝其實滿簡單的， Docker 官網有提供 rootless 的安裝檔案，安裝後需要針對一個使用者 ID 進行處理，這個處理主要是因為要將 container 內的 root 使用者給轉換到系統上的非 root 使用者，所以才會有相關的 userID 要設定。
當然如果真的要完全追求 rootless 的容器解決方案可以考慮使用 Podman 來使用，其本身的設定就是針對 rootless 去開發的，使用上會相對於 docker 來說更為簡單。

標題: 「軟體工程師你真的工作的很開心嗎??」
類別: others
連結: https://stackoverflow.blog/2022/03/17/new-data-what-makes-developers-happy-at-work/

疫情這兩年影響全球，其中對於勞動力來說更有甚巨的變化，而科技業更是其中的佼佼者，是所有行業中離職率最高的行業。
2021 的離職率相對於 2020 來說提升了 4.5%。

StackOverflow 基於想要理解科技領域的這個趨勢及原因，所以發起了一個調查想研究工程師工作是否開心，並且將
基於 350 位來自全球開發者的回應統整為報告於三月份釋出。

結果來看
1. 70.3% 的工程師覺得工作開心
2. 14.4% 表示不開心
3. 15.3% 沒感覺

以最令人感到開心的地區排名來看，前五名分別為
1. 西班牙 (90%)
2. 印度 (79%)
3. 德國 (70%)
4. 美國 (69%)
5. 英國 (68%)

那到底哪些因素會影響開心與否？ 報告中列舉了相關的指標
前五個最令人感到開心的因素有
1. 薪資(60%感到開心)
2. work-life 平衡
3. 工作彈性
4. 是否有足夠生產力
5. 職涯發展機會

而令人感到不開心的五個最重要指標其實就是上述指標的反轉，依序為
1. 工作覺得毫無效率與生產力
2. 工作生活不平衡
3. 沒有職涯發展與機會
4. 薪水太低
5. 工作無彈性

調查的全部指標除了上述五個之外還有
1. 工作是否能夠帶來影響力
2. 是否能夠獨力解決問題
3. 有一個瞭解我工作的主管
... 等

其實面試找工作也就是針對這些條件進行排序，與其跟風看大家去什麼公司就想去什麼公司，不如好好跟自己對話，瞭解自己對於工作的目的以及追求是什麼，才有辦法找到一個自己喜歡且舒適的工作環境

標題: 「Dockerfile 中透過 COPY --chomd 比透過 RUN chomd 可以省下更多空間」
類別: containers
連結: https://blog.vamc19.dev/posts/dockerfile-copy-chmod/

本篇文章是作者探討自己建制 Image 中所發現的一些有趣事實。
作者使用一個大概 70MB 的 image，並且安裝與運行大概 90MB 左右的額外空間，結果最後整個 image 高達 267 70MB
因此作者就花了一些時間來研究整體原因並且嘗試理解到底發生什麼事情

作者首先檢視自己的 Dockerfile，其內容簡單不複雜，包含如
COPY 一個 Binary (該 Binary 80 MB 左右)
RUN xxxxx
等常見用法。

詳細檢視所有的 layer 資訊後，作者發現 RUN 這個指令竟然產生了 94.4MB 的全新 layer，而就是這個 layer 導致整體空間變成 267 MB.
作者的 RUN 指令執行
1. 透過 apt-get 安裝四個套件
2. 透過 chmod 將前述 COPY 來的檔案給予執行的權限
3. 創建資料夾

作者檢查過安裝的套件，大概只有 6MB 左右，但是整個 layer 很明確就是多了 94.4 MB 出來，因此經過測試與研究後，作者觀察到
當移除第二步(修給檔案給予執行的權限)後整個空間瞬間變得很小，整體 image 最後的大小就符合預期的 174MB。

所以整個問題就出來了，為什麼單純執行一個 RUN chmod 就會使得整個 image layer 變大?
簡單來說 image 的底層是基於 OverlayFS，而 OverlayFS 的一大特色就是 CoW, Copy on Write，作者起初覺得
我只是透過 chmod 去修改該 Binary 一個屬性而以，本身並沒有寫入檔案到檔案系統中，怎麼會產生這麼大的檔案變化？

仔細研究 OverlayFS 的文件後終於水落石出，原來除了寫入檔案外，修改檔案的某些 metadata 也會觸發 CoW 的機制
```
When a file in the lower filesystem is accessed in a way the requires write-access, such as opening for write access, changing some metadata etc., the file is first copied from the lower filesystem to the upper filesystem (copy_up).
```

至於為什麼修改個 metadata 也要觸發 CoW 主要是跟安全性有關，文章中有關於這部分的額外連結，有興趣的可以參考

標題: 「kubectl delete 的行為跟 docker delete 完全不同」
類別: kubernetes
連結: https://www.acritelli.com/blog/kubectl-delete-sigkill/

熟悉 Linux 系統的人想必都了解 Signal 的概念，特別是幾個常見的如 SIGTERM, SIGKILL 等，

作者的團隊嘗試透過 SIGKILL 的行為來驗證與測試團隊內部署的 Kuberentes Pod，特別是當遇到 ungraceful shutdown 的情境時這些 Pod 會如何運作。
團隊嘗試透過 kubectl delete 的方式來刪除這些 Pod，但是實驗過程中發現 --grace-period 這個參數的運作行為與團隊的預期行為不同。
kubectl delete 得說明文件中特別指出

```
--grace-period=-1: Period of time in seconds given to the resource to terminate gracefully.
Ignored if negative. Set to 1 for immediate shutdown. Can only be set to 0 when --force is true
(force deletion).
```
作者看文這段文字說明後滿腦問號，提出兩個問題
1. grace-period 設定為 1 的 immediate shutdown 是直接送出 SIGKILL 嗎？ 還是說會有一秒的間隔時間才發送 SIGKILL?
2. grace-period 設定為 0 是代表沒有間隔，所以也是馬上送出 SIGKILL 嗎? 還是說其只是單純將資源從 k8s API 中移除而沒有等待而已？

作者認為文件沒有辦法解決這些問題，所以設計了一些實驗來測試

--grace-period=1 的實驗結果是
1. 送出 SIGTERM
2. 等待一秒
3. 送出 SIGKILL

作者對於這個行為感到不解，認為 "immediate shutdown" 應該就是要馬上關閉呀，怎麼可以送 SIGTERM 給 Pod 讓 Pod 有機會可以優雅的結束一切？
因為對於這行為的認知不同導致作者團隊的測試行為沒有辦法順利完成。

接下來測試 --grace-period=0 & --force=true

文件中說明這樣設定會立刻將該資源從 API Server 內給刪除並且避開 graceful 的階段。
最後測試的結果是
1. 發送 SIGTERM
2. 等待 30 秒
3. 發送 SIGKILL

作者表示又糊塗了，沒想到設定 grace-period=0 竟然中間還有 30 秒的時間，這完全與預料的不同，更麻煩的是文件也沒有講得非常清楚到底什麼是正確的行為，
此外還提到 Docker 就支援真正的 immediate shutdown，直接送 SIGKILL。

另外作者發現 K8s GitHub 中的也有人提出類似的 issue，對於這些 graceful 的行為感到不解同時文件說明不夠精準。

這件事情很難說誰正確誰不正確，畢竟不同的系統架構下的設計方式與條件都不同，不過的確 K8s 的指令文件有時候是真的不是精準，需要仔細測試才可以理解到底運作行為為何

標題: 「升級 Kubernetes 1.22 的注意事項」
類別: kubernetes
連結: https://blog.runx.dev/will-that-kubernetes-v1-22-upgrade-break-my-application-cc339dc2e2c7


隨者各大公有雲逐步支援 Kubernetes 1.22，相關使用者可能都會開始進入升級的準備階段，而每次 Kubernetes 升級除了單純
思考 Kubernetes 本身的升級順利與否外，也要確認正在運行的所有 Kubernetes 資源與相關工具是否也能夠順利運行，這使得整個準備工作變得複雜與龐大。

從 Kubernetes 的角度來看，每次的升級除了基本的穩定性與相關功能修正外，最重要的還有 Kubernetes API 的改變，該改變影響巨大，譬如所有 Manifest 的內容，譬如眾多透過 YAML 所描述的各種資源
API 的改變都會提早通知所有社群，於先前的版本先將該 API 標為 deprecated 接者後續版本才會正式移除，譬如 networking.k8s.io/v1beta1 於 1.19 被標示為 deprecated 然後正式於 1.22 移除。
正式的版本 networking.k8s.io/v1 則從 1.19 正式啟用，讓管理者有大概有三個版本的時間轉移。

因此升級前一定要先架設一個測試環境，嘗試部署所有現存的資源來確保升級不會出現不預期的錯誤。

作者整理出關於 1.22 升級要注意的版本變化，如下(幾乎都是從 v1beta 變成 v1)
1. Webhook: admissionregistration.k8s.io/v1beta1 → admissionregistration.k8s.io/v1
2. CRD: apiextensions.k8s.io/v1beta1 → apiextensions.k8s.io/v1
3. APIService: apiregistration.k8s.io/v1beta1 → apiregistration.k8s.io/v1
4. TokenReview: authentication.k8s.io/v1beta1 → authentication.k8s.io/v1
5. SubjectAccessReview: authorization.k8s.io/v1beta1 → authorization.k8s.io/v1
6. CertificateSigningRequest: certificates.k8s.io/v1beta1 → certificates.k8s.io/v1
7. Lease: coordination.k8s.io/v1beta1 → coordination.k8s.io/v1
8. Ingress: extensions/v1beta1, networking.k8s.io/v1beta1 → networking.k8s.io/v1
9. IngressClass: networking.k8s.io/v1beta1 → networking.k8s.io/v1
10. RBAC resources: rbac.authorization.k8s.io/v1beta1 → rbac.authorization.k8s.io/v1
11. PriorityClass: scheduling.k8s.io/v1beta1 → scheduling.k8s.io/v1
12. Storage resources: storage.k8s.io/v1beta1 → storage.k8s.io/v1

標題: 「透過 Kubernetes Event-Driver Autoscaler(KEDA) 來根據各種指標動態擴充容器」
類別: kubernetes
連結: https://medium.com/@casperrubaek/why-keda-is-a-game-changer-for-scaling-in-kubernetes-4ebf34cb4b61

Kubernetes 內已經有 HPA 的物件可以讓 K8s 根據一些基本的指標來動態調整 Pod 的數量，而 KEDA 這款 CNCF 的孵化專案則是完全強化 HPA 的效果
KEDA 的概念很簡單，就是應用程式應該要可以有更多的指標來幫忙動態擴充，除了最基本的 CPU/Memory 等基本指標外， KEDA 來支援了下列各種不同指標，讓 k8s 可以使用更為廣泛的指標，譬如
1. Redis 內某個 Queue 的長度
2. K8s 內其他 Pod 的數量
3. PostgreSQL Query 的結果
4. Elasticsearch Query 的結果
5. 各種雲端服務，如 Azure Event Hubs, AWS CloudWatch, GCP Pub/Sub
6. Kafka
... 等各種不同指標

使用方式很單純，一切的規則都是基於 K8s 的 CRD 來描述與管理，因此團隊可以使用 YAML 的方式來定義這些擴充的規則
文章中有基於 CPU/Memory 的基本介紹使用，同時文章中也有官方的連結來介紹各種不同指標的示範用法

標題: 「你真的有正確使用 SSH 嗎?」
類別: tools
連結: https://smallstep.com/blog/use-ssh-certificates/

SSH 基本上是每個系統管理員都熟悉不過的工具，而本文的作者指出 SSH 使用上有一些小缺陷，譬如
1. 使用者體驗很差，每一個新使用 SSH 的人如果不熟悉其概念，每次連線到新機器都會看到一次 Yes/No 的選擇，就因為不熟大部分的人都會直接選擇 Yes 來通過，
背後實際發生什麼事情都不清楚，只知道會動就好
2. 大規模的管理 SSH 非常麻煩且花費時間，Hostname 如果前後有出現重複的還會出現問題，需要重新處理 known_hosts 等相關資料
3. 透過 Key 的管理聽起來很安全，但是其架構使得使用者通常不太會換 key，會一直重富使用固定的那把 Key 來避免重新處理一切問題

舉了一些問題後，作者點出能夠真正駕馭 SSH 的應該是採取 SSH Certificate 而非使用 SSH Public Key 來進行身份驗證。
作者團隊開發了些許工具來幫助其他人能夠更輕鬆的使用 SSH Certificate 但是卻發現這類型的工具卻沒有受到歡迎與採用，因此也針對這個現象
進行問卷調查，想瞭解這類型的工具為什麼不受青睞，原因包含
1. 根本沒聽過 SSH Certificate
2. Certificate 以及 PKI 架構對人們來說不容易理解，很難理解其好處
3. 轉換中間有一些陣痛期，所以與其花時間去學習這些不如就繼續使用本來的 Public Key 機制

文章後半開始介紹 SSH Public Key 與 SSH Certificate 的差異
Public Key 的概念非常簡單，就是透過一組 Private/Public Key 並且將 Public Key 給寫入到目標節點帳戶上的 ~/.ssh/authorrized_keys.
節點數量爆炸多的情況下要如何有效率的去管理這些檔案則是一個非常麻煩但是又不能不處理的事情，這也是作者為什麼要推廣 SSH Certificate 的原因之一

SSH Certificate 的方式移除了關於 SSH Public Key 不停重複上傳與設定的情境，相反的則是將自身的 Public Key 給綁到 Certificate 內，同時也包含如過期時間，名稱等其他資料。
目標 Certificate 本身會由一個 CA 簽署，而每台 Server 都需要去修改 /etc/ssh/sshd_config 來指定相關的 CA Key 讓該 SSH 能夠信任。
文章後半部分介紹更多關於 SSH Certificate 的好處以及用法

標題: 「強化 Kubernetes 叢集的必備工具」
類別: kubernetes
連結: https://medium.com/mycloudseries/must-haves-for-your-kubernetes-cluster-to-be-production-ready-dc7d1d18c4a2

作者本篇文章想要分享一個其用來讓一個 Kubernetes 變得能夠真正上戰場的相關工具，因此文章中特別強調是 Production-Ready 的情況。
一個 Production Ready 的 K8s 叢集必須對於下列每個大項目都要有相關處理方式，譬如
1. Reliability and Availability
2. Security
3. Network, Monitoring & Observability
4. Backup/Recovery
5. Cost Optimization
6. Cluster Visualization

Reliability and Availability:
該領域的兩個指標代表的意義不太一樣，但是對於一個提供服務的叢集來說都一樣重要

這邊作者列舉了幾個工具譬如
1. K8s 內建的 HPA
2. AWS 的 karpenter，讓你針對基於節點為單位來擴充
3. Cluster-Autoscaler
4. Goldilocks

Backup/Recovery
有不少人團隊都對於對於叢集的備份與還原感到頭痛，目前最知名的開源專案莫過於 Velero，其支援不同的儲存設備如 Cloud Storage 等來存放，讓不同環境的 k8s 使用者都有辦法去備份其叢集內的資料

Cost Optimization

對於雲端架構來說，基本上雲端業者的內建功能已經可以針對如 VM, 底層架構等各種服務去列舉出各自的花費金錢，將此概念套入到 Kubernetes 本身大抵上只能理解到 Master Node, Worker Node 等之類的花費，
因此透過 Kubecost 之類的專案來將成本的洞察範圍擴充到 Kubernetes 內部，以 namespace, pod 等各種 k8s 的資源為單位來列舉實際花費的金額，能夠讓團隊更有效地去管理相關花費

標題: 「新一代 Helm Chart 的管理套件 helmwave」
類別: tools
連結: https://medium.com/wriketechclub/new-wave-for-helm-b9800733587f

Helm 作為現在包裝與安裝 Kubernetes 應用服務的主流方式，單單使用 Helm 很多時候不能滿足部署需求，譬如公司的業務是由多套 Helm Chart 同時組成的，這時候可能會有幾種做法
1. 使用 Helm Dependency 的方式來產生一個 Umbrella charts 讓你可以安裝一個 Helm 實際上會把相關的服務一起搞定
2. 透過 Helmfile 等相關工具以更上層的概念來管理你的應用，用多套 Helm Chart 來管理與部屬你的應用程式

而作者長期使用 Helmfile 來管理各種 Helm 的安裝方式，而今天作者終於發現一個相對於 Helmfile 來說更容易使用，而且整體使用方式更為簡潔的解決方案，helmwave.

Helmwave 的官方介紹很簡單， Helmwave is like docker-compoose for helm.

其本身的實作更為簡潔，直接使用 Helm Library 於整個實作中，所以下載單獨的 binary 即可，不需要如同 helmfile 一樣還要於系統中先安裝 helm 等相關工具。
文章中透過範例來示範如何滿足
1. 服務需要安裝多套 Helm chart
2. 有兩個不同環境， prod 與 stage 有不同的 values 要使用

整個使用的方式跟 docker-compose 有點類似，可以透過 helmwave up, helmwave down 的概念來啟動與停止服務，只不過所有的服務都是基於 k8s + helm-charts 來完成。

有使用 helmfile 的人可能會對這類型的工具比較有感覺，也許可以看看其差異性是否真的有如作者所提這麼好

標題: 「DevOps 的 2022 學習之路」
類別: others
連結: https://medium.com/faun/devops-roadmap-2022-340934d360f9

本篇文章是作者根據自己的觀察與經驗，列出 2022 需要繼續學習與觀察的 13 項技能與概念，希望讓每個 DevOps(SRE) 相關領域的人有一個方向去精進自己。
1. Network Technologies
網路的概念短時間內很難被顛覆，所以掌握基本的 L4/L7, HTTP2/, HTTP3/(QUIC), DNS, BGP, Load-Balancing 等基本網路概念絕對不吃虧，作為一個熟悉架構的專家，能夠描述環境中的封包流向是不可缺少的能力。

2. OS, particularly Linux
Linux 很重要，請學習系統上的各種基本概念， CPU/Memory 基本概念, Init, cgroup 等

3. CI/CD
Jenkins 作為老牌的解決方案，能夠使用其實也很好，不過要注意的是現在有愈來愈多的環境嘗試使用其他的 pipeline 來搭建，所以有時間的話也可以學習一下其他的解決方式，讓自己能夠有能力去面對各種需求

4. Containerlization/Virtualization
除了最知名的 Docker 環境外，也嘗試看看 containerd, podman 等不同專案，同時也考慮如何將 container security 的概念給導入到日常生活中

5. Container Orchestration
K8s 幾乎變成容器管理維運的 de facto 標準，單純的 k8s 叢集還不足以面對所有正式環境的問題，所以還需要搭配各個面向的概念將其整合才可以打造出一個適合團隊的 k8s 叢集。

6. Observability at Scale
除了最基本常見的 Prometheus 之外，也看一下其他基於 Prometheus 所打造更適合大規模的架構，如 Thanos, Cortex, VictoriaMetrics 等
此外可以試試看 Continuous Profiling 等持續觀察系統效能的工具，如 Parca, Pyroscope, hypertrace 以及順便試試看導入 Open Telemetry。

7. Platform team as a Product team
稍微有規模的團隊可能會慢慢的感覺到 Platform 逐漸轉型成為一個 Product 的概念，只不過該 Product 的面向對象是內部開發與測試人員而並非外部使用者。
整體目標就是打造一個更好的協同平臺，讓開發與測試人員能夠更有效地去滿足日常工作需求，同時 Platform team 除了維護產品之外也要教授使用人員讓他們有能力去使用該平台來滿足需求
而不是所有問題都要一直讓 Platform 的人來幫忙處理，這種模式小團隊可行，但是當團隊過大時就沒有辦法處理。

8. Security
9. Programming
10. Infrastructure as Code
11. Cloud
12. Technical Writing
13. Site Reliability Engineering

剩下的內容就留給有興趣的人自行到文章去觀看，每個類別都有舉出幾個趨勢與值得關注的專案，其中特別注意的是 Technical Writing 這項技能非常重要
遠端工作的趨勢使得透過文字交流的機會比過往多很多，所以如何寫出一個有效不會浪費彼此時間的設計文件，架構，開發文件等則是一個很重要的技能，所以即使是個開發人員也要努力練習
將腦中的想法有系統地呈現出來

標題: 「三座獨立 k8s cluster 還是一個跨三個地區的 k8s cluster ?」
類別: kubernetes
連結: https://itnext.io/3-reasons-to-choose-a-wide-cluster-over-multi-cluster-with-kubernetes-c923fecf4644

講到多套 kubernetes 的情況下，目前大部分的文章都會推薦用三套獨立的 kubernetes 叢集而非架設一套同時管理三個地點的 kubernetes 叢集。
本篇文章作者從不同的面向分享為什麼要選擇一個 kubernetes 管全部，而不是要架設三套 kubernetes 叢集。


# Latency
一套 kubernetes 最令人詬病且很難處理的就是 Latency 的問題，作者提到 Latency 的問題會影響 ETCD
ETCD 被影響後會影響整個叢集的運作，甚至連應用程式相關的處理都會變慢。

作者提到其實這個問題能夠採取兩個步驟來解決
1. 重新安排 etcd 的節點位置，或是使用 non-etcd 的解決方案
2. 透過 node labels 讓要使用 etcd 的服務跟 etcd 盡量靠近

註: 我是覺得這說法不能解決問題，一般應用程式要是被分散到不同地區你的存取還是有機會跨地區，除非要很認真地針對不同地區去設計 label，讓應用程式的部屬都只會固定同個地區，但是要這樣搞跟我直接搞三套不覺得後者會比較累。

# Security
作者一直強調使用 mesh VPN 來打通底層所有網路封包處理，讓你一個大 k8s 管理多個地區，就不用擔心底層網路問題

單套 k8s 的好處有什麼？作者認為有

# No Complicated tooling
作者提到 2021 年的 KubeConf 有各種管理多套 k8s 叢集的工具，如 KubeEdge, OpenShift Edge, Akri, Baetyl,
Kubermatic, Rancher, KubeFed... 等，如果用一套大 k8s 就可以不使用這些工具，直接減少與這類型複雜工具的依賴性
一套 k8s 叢集可以讓你使用最簡單也是最習慣的方式來管理所有環境

# No extra overhead
每套 K8s 環境中都會有如監控，日誌， registry 等各種工具，多套 k8s 的架構就是每個叢集都要安裝一份，但是如果採用一個大 k8s 的架構就只要維護一份即可
所以可以減少很多不必要的重複安裝。

# Ultimate Flexibility
這段其實不很理解，為什麼作者這麼想要推廣 mesh VPN ...

註: 這篇文章底下有留言說探討到說 RBAC 等相關權限問題是個很大的問題，你一套 k8s 很難處理這些，事情沒有想像的這麼簡單

標題: 「istio 下因為YAML 與 Go template 結合產生的 CVE」
類別: others
連結: https://paper.seebug.org/1882/

熟悉 Kubernetes 的使用者一定對於各式各樣的資源格式感到不陌生，譬如描寫一個 Pod 需要準備些關於 containers 的基本資料，其餘還有 Label, Annotation 等
各種資料需要填寫。

Kubernetes 內透過 apimachinery 的方式來驗證每個欄位是不是合法，譬如最常見的就是創建資源名稱時有時候會因為_等出現格式不符合，準確來說是 Pod 的方式來驗證每個欄位是不是合法，譬如最常見的就是創建資源名稱時有時候會因為_等出現格式不符合，準確來說是
透過 DNS RFC 1123 來驗證 Pod 是否合法。
部分的數值資料可能會於 Controller 中額外去檢查，至於自定義的 CRD(Customer Resource Definition) 則是創建時可以透過 openAPIV3Schema 去定義每個欄位的合法數值。

今天這篇文章要介紹的問題是跟 istio 環境的問題，當使用者創建一個名為 Gateway 的資源到叢集中時， istio 會去讀取該 Gateway 資料並且轉換為 Service/Deployment 兩個底層資源。
作者仔細研究發現創建 Service 時會從 Gateway 中的 Annotation 找到名為 "networking.istio.io/service-type" 的資料，並用其作為 Serivce 的 type.

然而 Annotation 的數值沒有並沒有任何檢查機制，所以使用者可以於該欄位 "networking.istio.io/service-type" 填入各種數值，因此作者就嘗試撰寫一個非常長的 Annotation，譬如
```
annotations:
networking.istio.io/service-type: |-
"LoadBalancer"
apiVersion: apps/v1
kind: Deployment
metadata:
name: pwned-deployment
namespace: istio-ingress
spec:
selector:
matchLabels:
app: nginx
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.3
ports:
- containerPort: 80
securityContext:
privileged: true
```

結果非常順利的， isio 最終創造了一個作者故意描述的 deployment，而該 deployment 還特別的設定 privileged: true 的選項並且透過這次的測試證明該 YAML 的檢查問題導致使用者有機會插入任何想要的資源到環境中
對本文有興趣的可以觀看一下

標題: 「使用 serverless 5年後的心酸經驗談」
類別: usecases
連結: https://dev.to/brentmitchell/after-5-years-im-out-of-the-serverless-compute-cult-3f6d


本文作者想要分享自己過去五年來使用 Serveless 的經驗談，從不同角度切入導入 Serveless 後的痛點。
作者的 serverless 環境是基於 AWS 環境，使用了包含
1. API GAteway
2. Cognito
3. Lambda
4. DynamoDB
5. DAX
6. SQS/SNS/EventBridge

作者提及了幾個痛點，包含
1. Testing
2. Account Chaos
3. Security
4. No Fundamental Enforcement
5. DNS Migration Failures
6. Microservice Hell
7. API Respones 回傳不一致

這篇文章最有趣的點不是文章本身，而是底下的留言討論，雖然有少數留言是支持作者但是大部分的人都是秉持反對的意見來看這篇文章。
我自己的角度是這篇文章提出非常多問題，但是這些問題我看不太出來跟 Serveless 的關係是什麼，更多的是公司的文化，工程品質與開發工具有關
譬如作者說團隊內有很多非資深工程師會因為 serveless 的易用而依賴自己的想法去攥寫，譬如光 Auth 就有十種不同方式。
但是仔細思考這個問題，似乎 server-based 的架構也會有這問題，完全是公司的文化與規範問題。
其他問題還有很多寫 serveless 的人都沒有 HTTP 的深厚底子，所以 200,400,500 想回就回，然後回傳格式也都沒有統一固定
這些東西其實跟 serverless 也沒有直接關係，更多依然是 Code Review 的問題，工程師品質的問題。

所以有時候看文章除了單純閱讀外，也要思考一下作者講的東西自己是否認同，同時也可以看下留言處，來自不同文化與團隊的留言往往能夠帶來更大的啟發，也是閱讀網路文章上我覺得非常有價值的地方