ref: https://link.medium.com/6uur7w6C1lb

本篇文章不是 Cloud Native 相關的，而是先前遊戲動畫設計的續集，本篇續集探討的是遊戲產業中是如何創造一個 3D 角色。

一個 3D 角色的創造會經歷五個過程，包含概念圖，建模，上色，綁定骨骼，及動畫製作

# Concept Art 概念圖
為了讓之後的建模師能夠將 3D 角色給數位化的建模處理，第一步驟就是概念設計，將團隊討論的結果給初步圖像化，畢竟概念歸概念，需要將概念給實體化才有辦法進行更進一步餓的討論與修正。

# Modeling 建模
有個概念圖之後，下個步驟就是要透過不同的建模軟體來打造一個 3D 建模，軟體如 Maya, Blender, Autocad 等都有不同的支持者。
一個好的建模除了形似概念圖外，更重要的是能夠用更少的資源來打造完成，因為這些建模最後導入到遊戲中後就是一個活生生的資源運算，精確的模型同時很容易伴隨者複雜的模型。
因此這部分就會很仰賴建模師的功力來看看如何達成精準建模的不複雜模型。

# Texturing 紋理與上色
3D 建模師完成後就會得到一個沒有光彩的模型，就如同商場的穿衣模特假人一樣，為了讓其好看還是需要補上貼圖上色讓其看去以來更貼近概念圖的面貌。

# Rigging 綁定骨骼
有了一個賞心悅目的模型後，下一步驟就是要讓該模型有能力動起來像個活生生的樣貌，譬如人的話就會有所謂的四肢與身軀，有了這些關節後該模型才有辦法動起來，從基本的
四肢移動到更為細緻的手指牽動，愈多的細節就要愈多的關節，這意味綁定骨骼就需要更多的時間投入

# Animating 上動畫
一切都完成後最後一個步驟就是將該建模角色給動畫化，藉此能夠於遊戲中的各個場景呈現到遊戲玩家中
文章中還特別提到 恐怖谷理論 的概念，算是一個滿有趣的概念，的確於滿多 3D 遊戲中都有看到這概念的範例

Ref: https://coolshell.cn/articles/21672.html

本篇文章是作者工作 20 年來的經驗分享文，內容非常好，提出了很多不同的觀點，由於是篇中文文章，所以就不幫忙節錄重點，直接列
文章中的十一個原則標題。
每個原則都非常精彩，文章底下的討論也滿有趣的。

原则一：关注于真正的收益而不是技术本身
原则二：以应用服务和 API 为视角，而不是以资源和技术为视角
原则三：选择最主流和成熟的技术
原则四：完备性会比性能更重要
原则五：制定并遵循服从标准、规范和最佳实践
原则六：重视架构扩展性和可运维性
原则七：对控制逻辑进行全面收口
原则八：不要迁就老旧系统的技术债务
原则九：不要依赖自己的经验，要依赖于数据和学习
原则十：千万要小心 X – Y 问题，要追问原始需求
原则十一：激进胜于保守，创新与实用并不冲突

ref: https://pythonspeed.com/articles/stop-using-python-3.6/

本部落格是一個基於 Python & Container 的系列介紹文，而本篇文章是其中一篇探討容器化 Python 要注意的事項。
標題非常簡單：「是時候停止使用 python 3.6了」
Python 3.6 的 EOL 時間就剛好是 2021/12，這也意味到 2022 年後 python 3.6 就不再享受官方的任何維護與更新。
文章中提到建議趕快升級，同時也要注意不要每次都拖到最後一刻才升級相關軟體，應該要把升級軟體的流程給整合到日常流程中，定期掃描定期更新，
否則只會不停的被不同版本的 EOL 追趕而已。

ref: https://docs.microsoft.com/en-us/azure/architecture/patterns/ambassador

微軟文件中的系列好文，探討雲端方面的各種設計模式，而本篇探討的是 Ambassador 模式

想法:
1. 想要提供更多進階的網路功能到應用程式上，譬如 TLS、circuit、breaking、routing 或 metering。
2. 應用程式不太方便修改來符合上述功能。
3. 部署一個跟原應用程式相鄰的應用程式來處理這些網路功能。

應用程式過於古老，團隊沒有辦法進行深度修改或是團隊中的應用程式使用過多的語言與框架完成，很難簡易的將這些功能給導入到既有的應用程式中
這時候部署一個全新的應用程式就可以再不修改既有應用程式的前提下來提供這些進階的網路功能。
這個模式普遍被稱為 ambassador 模式，而本篇文章就是針對該模式進行一個科普概念。
文章最後還要探討使用這種模式的一些注意事項，譬如網路的延遲會因為多一個應用程式而提升，所以使用上也要評估看看是否合適。
也有簡單的列出什麼情況適合使用 ambassador 什麼情況不適合。

ref: https://medium.com/system-design-concepts/dating-application-system-design-aae411412267

本篇是一個系統設計文，探討設計一個如 Tinder 的應用程式該如何去思考整體架構

Tinder 這種交友應用程式有幾個特點
1. 透過 FB 走 OAuth 登入
2. 左滑右滑
3. 配對機制
4. 聊天對話
5. 通知功能

其中 (3) 這個特色是說當使用者開啟 app 之後系統要根據一系列的條件們去推薦可能的對象，條件包含很多
1. 從 FB 中抓到的個人資料，喜好等
2. 地理位置，通常這類型的交友軟體都可以設定希望對象與自己的距離，譬如 10km 內， 50 km 內。

同時這類型的交友軟體支援多語言，支援多語言基本上就是意味多地區，簡單的說法可以說支援全世界不同地區的使用者共同使用，
因此基於效能考量上，通常不會使用單獨使用一個地區的伺服器來提供全球的服務，取而代之的則劃分地區讓每個地方都有一個稍微近的伺服器可以使用。
所以整體架構上還需要考量這類型的分散式架構設計，特別是有一些交友軟體還支援切換地點的功能，使用者可以切換到不同地區去匹配
不同地區的使用者，這意味該使用者的資料也會需要同步到不同地區的伺服器之間，因此資料部分也需要特別注意處理。

接下來就是當使用者希望配對範圍 100km 的使用者，該功能到底該如何實作，要如何將實體的地理位置劃分出來並且有辦法根據該敘述， 100km 內的使用者進行配對。
文章內有針對這部分進行詳細解釋，如何拆分不同的小區塊然後如何後續處理，有興趣的可以參閱全文

ref: https://docs.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer

本篇又是微軟 Cloud Design Pattern 系列，要探討的是 Anti-Corruption Layer 模式
該模式的想法是
1. 應用程式很常需要透過其他的服務來提供外部功能或是資料存取。
2. 當應用程式要轉移到新的系統時，可能會需要同時存取新舊系統內的外部功能與資料。

譬如新舊系統內所使用的 API, 資料架構也都完全不同，然後應用程式並沒有辦法一夜之間完全轉移到全新系統，過渡期不可避免。
這種情況下應用程式就必須要相容新舊系統的寫法。

而 Anti-Corruption Layer 的意思就是讓應用程式與舊系統中間塞入一個轉接人，該轉接人同時面向應用程式與舊的系統，然後將彼此的溝通進行轉換。
應用程式不需要使用過往的 API 來處理，這部分都會讓轉接人處理。

上述敘述聽起來跟過往學到的 Adapter 模式大概有 99% 雷同，而 Anti-Corruption Layer 該詞是由 DDD(Domain-Driven Design) 中被初次提起與強調的，與 adapter 的
差異在於層次的不同，Anti-Corruption Layer 想要處理的是跨 Domain 之間的轉換，而 Corruption 的含義就是要避免不同 domain 之間那些不能受控的系統不要 corrupt 既有的應用程式。
因此 Anti-Corruption Layer 還有一個隱含的想法就是背後要處理的服務會有品質的問題，而這個模式就是用來處理這品質不穩的服務，避免這些服務破壞整個應用程式的功能。

詳細的可以參閱全文ref: https://docs.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer

本篇又是微軟 Cloud Design Pattern 系列，要探討的是 Anti-Corruption Layer 模式
該模式的想法是
1. 應用程式很常需要透過其他的服務來提供外部功能或是資料存取。
2. 當應用程式要轉移到新的系統時，可能會需要同時存取新舊系統內的外部功能與資料。

譬如新舊系統內所使用的 API, 資料架構也都完全不同，然後應用程式並沒有辦法一夜之間完全轉移到全新系統，過渡期不可避免。
這種情況下應用程式就必須要相容新舊系統的寫法。

而 Anti-Corruption Layer 的意思就是讓應用程式與舊系統中間塞入一個轉接人，該轉接人同時面向應用程式與舊的系統，然後將彼此的溝通進行轉換。
應用程式不需要使用過往的 API 來處理，這部分都會讓轉接人處理。

上述敘述聽起來跟過往學到的 Adapter 模式大概有 99% 雷同，而 Anti-Corruption Layer 該詞是由 DDD(Domain-Driven Design) 中被初次提起與強調的，與 adapter 的
差異在於層次的不同，Anti-Corruption Layer 想要處理的是跨 Domain 之間的轉換，而 Corruption 的含義就是要避免不同 domain 之間那些不能受控的系統不要 corrupt 既有的應用程式。
因此 Anti-Corruption Layer 還有一個隱含的想法就是背後要處理的服務會有品質的問題，而這個模式就是用來處理這品質不穩的服務，避免這些服務破壞整個應用程式的功能。

詳細的可以參閱全文

標題: 「多年工作經驗總是搞砸電話面試， why ?」
類別: 其他
連結: https://kevin.burke.dev/kevin/phone-screens-broken/

本篇是一個面試經驗探討文，作者闡述自己雖然已經有十年多的工作經驗，但是部分面試工作上還是沒有很辦法的去展現自己的能力
特別是那些用電話面試的經驗，而此文就是關於電話面試的小小抱怨文

滿多的電話面試都會搭配 Coderpad 這個網站來要求面試者線上進行程式撰寫，而該網站就要求你使用線上編輯器並且將所有的程式碼都統一到一個檔案中
，同時也不一定有辦法去撰寫相關的測試規則，這對於作者來說非常不喜歡。
作者平常習慣開啟多個視窗進行開發，一邊撰寫程式一邊透過測試來驗證當前撰寫的程式是否往正確的方向前進，同時也花費大量時間去調整自己喜歡的工具來輔助所有
程式碼的撰寫。而上述所有習慣都沒有辦法於 Coderpad 的單一編輯器上去完成。
此外面試過程中還會被問各種問題，譬如為什麼這個變數這樣命名，為什麼blablabla... 對於作者來說，有些概念要到快完成時才會最佳化，就很明顯不符合電話面試這種要一次完美的特色。

最後作者也分享了一下關於電話面試的問題想法，相較於問一些實際上工作根本用不到的演算法問題，不如問一些更貼切真正工作會用到的經驗與概念，譬如
1. 給面試者看一段 opensource 專案產生的 stack trace, 問問面試者能不能從這個 trace 看得出來大概可能是什麼問題
2. 如果你開啟一個 database transaction 過久，有可能會發生什麼問題?
3. 寫檔案到硬碟如果每次都只有寫一個 byte, 這可能會帶什麼樣的壞處?
4. 給定一個函數，請面試者描述會如何針對這個函式去寫測試案例

這讓我想到多年前也有接過電話面試直接問我 Linux 用幾個bit實作權限，但是面試官本身也非這個專業，是哪個權限也沒辦法回答，也不能給清楚的 context，就如同教科書一樣一個問題一個答案，沒辦法針對面試者的疑問去解惑...

標題: 「Meta 如何打造一個供多團隊使用的 SLI/SLO 設定與觀測平台」
類別: usecase
連結: https://engineering.fb.com/2021/12/13/production-engineering/slick/

本篇文章是 Meta 公司的技術分享文，探討內部如何搭建一個觀測 SLO 的大平台，讓不同的應用程式團隊都可以更方便地去觀察是否有達到其設定的 SLO。

文章內容有點長，這邊稍微節錄一些重點，非常推薦大家花點時間看完全文
1. Meta 的產品多，同時規模又大，背後又有數千的工程師不停地部署新版本，因此維運團隊必須要有一個好的方式來維運這些服務，包含預期狀態，當前狀態以及有能力去分析問題。
2. 團隊決定從 SLI/SLO 為基準點去設定預期狀態以及量測所有服務的效能。
3. 團隊決定打造一個名為 SLICK 的系統來視覺化與控管所有服務的 SLI/SLO
4. 沒有 SLICK 以前，每個服務的團隊都有各自的處理與儲存方式，所以都要花費很多時間去研究每個開發團隊的文件與用法，整體工作效率會下降
5. 過去的系統也沒有維護超過一週以上的資料，所以後續團隊也沒有辦法針對這些部分去分析。

透過 SLICK 可以讓整個 Meta 達到
1. 每個服務都可以用一個統一的方式去定義 SLO
2. 可以維持資料長達兩年且資料的細度達到每分鐘等級
3. 有個標準化的視覺方式來呈現 SLI/SLO
4. 定期地將當前服務狀態發送到內部群組，讓團隊可以用這些報告來檢視服務的穩定度並進行改善

文章後半部分包含
1. SLICK 用法介紹，包含 UI 的呈現樣子，定期的報告內容以及相關的 CLI 介紹
2. SLICK 的架構，團隊是如何設計 SLICK 這個服務，用到哪些元件以及這些元件之間個溝通流向
3. 兩個使用 SLICK 來改善穩定度的案例，這兩個案例都有簡單的去識別化，主要是介紹這些團隊發生什麼問題，如何透過 SLICK 來改善以及改善後的效能。

標題: 「透過 Kubefarm 來自動化幫實體機器打造基於 Kubernetes in Kubernetes 的 Kubernetes 環境」
類別: Kubernetes
連結: https://kubernetes.io/blog/2021/12/22/kubernetes-in-kubernetes-and-pxe-bootable-server-farm/

摘要:
本篇文章要介紹 Kubefarm 這個專案，該專案的目的是希望能夠於大量的實體機器上去創建各式各樣的 Kubernetes 叢集供不同團隊使用
為了讓整體的運作更加自動化，作者先行介紹何謂 Kubernetes in Kubernetes 這個專案，如何透過 Kubeadm 的方式於一個現存的 Kubernetes 專案
去部署 control-plane 並且透過這個 control-plane 去控管其他的 kubernetes 叢集，基本上達到的效果就如同各種 kubernetes service 服務一樣，使用者完全看不到 control-plane 的元件。

雖然透過這個方式可以很輕鬆地去創建新的 Kubernetes 叢集來使用，但是使用上覺得還是不夠方便，特別是這些實體機器還是會有不少手動的過程要處理，
為了讓整體流程更加自動化，作者團隊又基於 Kubernetes in Kubernetes 這個專案為基礎再開發更上層的專案，稱為 Kubefarm，一個如農場般可以快速於實體機器創建各式各樣 kubernetes 叢集的解決方案

Kubefarm 由三個專案組成，分別是
Kubernetes in Kubernetes, LTSP (PXE-Server) 以及 Dnsmasq-Controller
透過這三者專案的結合，實體機器會自動取得 DHCP 的 IP 地址並且透過 PXE 系統自動化安裝 OS，待一切都安裝完畢後又會自動地加入到現存的 Kubernetes 叢集中

整篇文章滿長的，是一過非常有趣的用法與研究，如果團隊是大量實體非虛擬化機器的讀者可以研究看看別人遇到什麼問題以及透過何種思路去解決的。

標題: 「使用 OpenKruise v1.0 提供更進階的 workload 部署與升級」
類別: tool
連結: https://www.cncf.io/blog/2021/12/23/openkruise-v1-0-reaching-new-peaks-of-application-automation/

Openkruise 1.0 版本釋出，該專案是 CNCF 沙盒層級的專案，主要是由阿里巴巴開發與維護，不久前的 Kubeconf 中阿里巴巴的議題也有
分享到有將此專案部署到期內部的 Kubernetes 管理平台

該專案主要是強化 Kubernetes 內應用程式的自動化，包含部署，升級，維運等面向，此外其架構是基於 Operator 去設計的，因此任何的 Kubernetes 叢集都可以安裝這個功能。
相對於原生的 Deployment 等部署方式， Openkruise 提供了

1. 強化 workloads 的部署方式，包含支援原地更新，金絲雀等不同的升級策略。
2. Sidecar 容器的管理，可以更方便地去定義想要自動掛到不同 workloads 上的 sidecar 容器。
3. 提供更多方便維運的功能，譬如可以針對 container 進行重啟，可以針對不同節點進行先行下載 container image，將一個應用程式給部署到多個 namespace 甚至還可以
去定義 Pod 裏面所有 containers 的啟動優先順序，如果 Pod 內的容器彼此之間有依賴性時就可以透過這個功能讓整個啟動過程更加順暢。

有興趣的可以研究看看此專案

標題: 「2021年回顧，因為 DB 的效能的爭論所以我女友跟我分手了....」
類別: usecase
連結: https://ottertune.com/blog/2021-databases-retrospective/

摘要:

2021 對於 DB 行業來說發生了許多風風雨雨，作者列出幾個觀察到的現象並且給予一些評論

「Dominance of PostgreSQL」
愈多愈多的人開發一個新的應用程式時首選都是 PostgreSQL 這個穩定可信賴且一直不停加入新功能的資料庫。
2010 年時 PostgreSQL 的開發團隊決定採取更為激進的方式來每年都要釋出一個主要版本的演進，其相容性的能力使得 PostgreSQL 能夠跟很多系統整合。
譬如前端介面如 Amazon Aurora, YugaByte, Yellowbrick 甚至 Google 都於 2021/10 宣布要讓 Cloud Spanner 支援 PostgreSQL

作者也嘗試從 Database Subreddit 上去爬文搜尋，基於過去一年所有發文去統計每個資料庫的出現次數，以結論來看 PostgreSQL -> MySQL -> MongoDB -> Oracle -> SQLite 等
這個過程不是非常嚴謹的統計分析，只是一個簡單的方式去觀察該論壇上大家都喜歡討論什麼資料庫而已。


「Benchmark Violence」
Benchmark 一直以來都是各個廠商展示軍火的地方，想辦法利用這些數據去說服大眾自己才是最棒的，作者列出去年三個激烈的 benchmark 討論
1. Databricks vs. Snowflake
2. Rockset vs. Apache Druid vs. ClickHouse
3. ClickHouse vs. TimescaleDB

作者也有參與上述血流成河的 Benchmark 的戰場，但是這些爭論的過程中作者失去了不少朋友，甚至連女朋友也一起離開了，作者回過頭來看這一切都
不值得，此外由於現在雲端的 DBMS 也有許多可最佳化的參數，要直接去比較彼此的優劣其實沒有這麼簡單。

後面還有「Big Data, Big Money」以及「In Memoriam」 兩個不同的議題，有興趣的可以點選全文閱讀

標題: 「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 的內建函式，
有興趣的都可以使用看看