ref: https://www.cncf.io/blog/2021/09/01/chaos-mesh-2-0-ga-to-a-chaos-engineering-ecology/

Chaos Mesh 2.0 於 07/23/2021 正式 GA 了，團隊期盼透過這次 2.0 的釋出能夠讓整個 Chaos Engineering 的生態性更加茁壯與蓬勃發展。

Chaos Mesh 一直以來的目標就是讓 Chaos Engineering 能夠更輕易地進入到每個管理者的 Kubernetes 叢集， 2.0 則是這個目標路上的一個重大里程碑，
歷經一年左右的開發與努力， 2.0 主要有三大改進
1. 簡化使用的困難性
Chaos Mesh 透過一套基於 Web 的管理介面 Chaos Dashboard 讓使用者可以輕易地去檢視目前所有的實驗與內容，而 2.0 更是簡化整體操作，
界面更加簡潔同時也可以觀看每個實驗的詳細資訊。
針對不同的雲端業者環境，也支援 AWSChaos/GCPChaos 等不同的環境設定，確保所有的 Kubernetes 測試都能夠更加一致。

2. 強化 Chaos 實驗的自動調度功能
實務上來說，一個單一的實驗沒辦法有效的模擬各種測試環境，因此很多時候都需要人為操作的介入，為了讓這一切更加流暢與自動，Chaos Mesh 過往整合了 Argo Workflow 來協助調度各種實驗。
不過後來團隊發現 Argo Workflow 並不是一個非常適合描述 Chaos 實驗的工具，因此 2.0 版本重新實作了 workflow 的機制，這次的機制是原生支援而不需要仰賴任何第三方解決方案。

3. 支援更多 Injection 的類型
從 2.0 開始， Chaos Mesh 開始支援如 JVMChaos, HTTPChaos 等不同的測試目標。
JVMChaos 用來針對 Java/Kotlin 等使用程式語言撰寫的應用程式，而 HTTPChaos 可以攔截 HTTP 的封包並且竄改內容

此外針對實體機器部分，Chaos Mesh 則是開發了一個名為 Chaosd 的來模擬各種環境問題，譬如砍掉 process, 模擬網路問題，模擬 Disk 問題等

對 Chaos Engineering 有興趣的可以試試看

ref: https://lwn.net/Articles/853637/

如果對 SO_REUSEPORT 這個能夠提供網路服務吞吐量的 socket options 不陌生的話，那這篇文章強烈推薦看看。
本篇文章是從討論開啟 SO_REUSEPORT 這個選項會出現的一些行為以及可能可以怎麼做

最直得看的應該是留言區本身，有很多不同層級的討論，大家最愛講的 Google SRE 人也都出來分享自己的經驗了。

正常情況下，每個 TCP Port 只能被一個 process 給使用來聽取封包，但是對於一些網路重度使用的系統來說，就算讓該 process 將連線給分散到其他的 process 去處理，該 process 依然可能是系統的效能瓶頸。
Linux Kernel 3.9 後引入的 SO_REUSEPORT 參數就是為了解決這個效能問題而來的，這個參數允許多個 Process 同時使用一個 TCP Port，每當底層有一條新的連線請求時， Kernel 會從眾多的候選人之一中挑選一個可用來處理。
這種情況下，網路應用程式就可以專心處理連線工作，然後實務上同時執行多個 Process 即可。底層的 Kernel 會幫忙做連線的負載分配。

當眾多候選 process 其中之一掛掉了(可能是 crash，也有可能是有意的重啟)， kernel 會注意到這個候選人要說掰掰，這候選人處理的所有 connection 都會被移除，比較糟糕的是其他待在 Accept-Queue 那些還沒被建立連線的連線請求也會一併被移除。
作者認為 Kernel 應該要有能力可以轉移那些 Accept-queue 中的連線到其他還工作的候選 process 下去處理，這樣使用者/Client 的連線就不會需要處理太多重連的問題。

文章後面都在探討可行的做法以及這個問題可能會導致什麼問題。

留言區滿熱鬧的，譬如說
1. 有人認為 server 重啟的情況實在太少見，有需要為這麽少見的情況導入這麼複雜的修改到 Kernel 中?
a. 有人回答使用 Let's Encrypt 你可能每幾週就要重啟一次。
b. Google SRE 回答其內部因為調整設定的緣由，幾乎無時無刻都需要重啟服務，不過這問題已經從別的層級去處理掉，所以修改 Kernel 對他們的用途不太大。
2. 有人提出 Nginx 本身有 live migration 的功能，可以將 fd 給轉移到其他的 process 去處理。
a. 有人提出這邊談的是 socket/connection 的層級，這些東西都還沒發生到 userspace process 同時也不是 userspace 應用程式可以接觸處理的。
b. 本文探討的是 bind(), accept(), listen() 這類型 function call 之間 kernel 會幫忙做的事情。

有興趣的別忘了閱讀留言區

ref: https://ably.com/blog/no-we-dont-use-kubernetes

八月第一篇，就來個有趣的文章，來看看 ably 這間 SaaS 公司為什麼沒有使用 Kubernetes，不但當前沒有使用，甚至短期未來內都不會想要使用
更是直接的說如果你有興趣來加入團隊，千萬不要把將 Kubernetes 導入到團隊中是一個可能發生的事情。

我個人覺得這篇文章滿好的，因為是認真的去比較導入 Kubernetes 帶來的改變，而這些改變對團隊來說到底是可接受還是不可接受
而不是所謂的人云亦云，人家要我也要，人家不要我也不要...

文章分成兩部分，前述介紹當前 Ably 的環境架構是什麼，而半部分則是很技術的去探討如果導入 Kubernetes 帶來的好處與壞處是什麼
最終權衡比較之下，會發現導入 Kubernetes 沒有帶來實質上的好處。

文章開頭先簡述了一下 Kubernetes 這幾年的風潮，從最初 Google Borg 的開發開始談起，作者特別提到當初 Borg 的用法可是將一堆實體機器給搭建出一個 Private Cloud 的叢集給團隊使用，
而目前 Kubernetes 更多的用法則是搭建於 Public Cloud 上面的虛擬機器中，透過將 Kubernetes 部署到這些不同的 Cloud Provider 似乎帶來了介面統一的結果，對於 DevOps 人員來說
不同 Cloud Provider 如今看起來都是 Kubernetes 的樣貌。

Ably 目前到底怎麼部署應用程式
Ably 主要使用 AWS 作為其 Cloud Provider，並且於 EC2 機器上使用 docker/container 來部署團隊中的應用程式。
作者團隊中沒有使用任何已知的 Orchestration 服務來管理多節點上的 docker/container，取而代之的則是每個 VM 開機後則會根據 autoscaling group 的機制來判斷
每個機器應該要部署哪種 container/docker。

對於 Ably 來說，團隊中沒有任何 scheduler 相關的服務來調度各種服務，這意味每個 VM 就代表一種服務，所以將 VM 上的服務從 Core 轉換成 frontend 這種行為不會發生。
今天需要針對需求轉換服務時就以 VM 為基準來整批換掉即可。
每個節點上面都會有一個輕量的監控服務，用來確保運作的 Container 如果掛掉後可以被重啟，甚至如果當前運行的版本不符合需求時也能夠將該服務給停止。

流量方面，因為每個 Autoscaling Group 就代表一個服務，所以直接使用 NLB 與 Target Group 來將流量導入該 Autoscaling Group 即可。
至於容器與容器之間的內部流量(譬如 k8s service 等)作者認為也不是太大問題，畢竟每個機器本身都會被 VPC 賦予一個 IP 地址，所以使用上沒有什麼太大的問題。

接下來作者從幾個層次去探討當前設計與使用 Kubernetes 帶來的改變，分別有 (原文很多，這邊摘要不然文章會太長)
題外話，由於 Ably 的 Infra Team 數量有限，所以要考慮 K8s 只會考慮 K8s Service，如 EKS。
1. Resource Management
Ably:
a. 根據服務的需求來決定每個服務要用到的 VM 等級
b. 不需要去煩惱如何處理將多個小服務給部署到一個適合的大 VM 中
c. 作者稱這種行為其實就是 AWS 官方強調的 Right Sizing, 譬如只能跑兩個 Thread 的服務不需要 16vCPUs, 久久寫一次硬碟的服務也不需要一個 90,000 IOPS 的 SSD
d. 選擇一個正確的元件來搭建一個符合服務的 VM 讓團隊可以控制成本同時也減少額外的管理負擔
K8s:
a. 必須要使用一個比較強大等級的 EC2 VM，畢竟上面要透過 Container 部署很多服務
b. 針對那些需要小資源的服務來說，透過這種方式能夠盡可能的榨乾機器的資源，整體效能使用率會更好
c. 但是針對資源量沒有很辦法明確定義的服務則是會盡可能地去吃掉系統上的資源，這種被稱為 nosy neighbors 的常見問題已經不是首次出現了， Cloud Provider 本身就需要針對 VM 這類型的服務去思考如何處理資源使用，而 Cloud Provider 都有十年以上的經驗再處理這一塊
而所有 Kubernetes 的使用者則必須要自己去處理這些。
d. 一個可能的作法則是一個 VM 部署一個服務，不過這個做法跟團隊目前的作法已經完全一致，所以就資源管理這一塊，團隊看不到使用 Kubernetes 的優勢。

2. Autoscaling
Ably:
a. EC2 VM 本身可以藉由 Autoscaling Group 來動態調整需求
b. 有時候也是會手動的去調整 EC2 的數量，基本上手動跟自動是互相輔佐的
c. 團隊提供的是 SaaS 服務，所以其收費是針對客戶實際上用多少服務來收，如果開了過多 EC2 VM，則很多不要的花費與開銷都是團隊要自行吸收
d. 團隊需要一個盡可能有效率的方式能夠即使遇到流量暴衝時也能夠保證良好的服務的機制
K8s:
a. 可以透過不少方式來動態調整 Container 的數量，
b. 甚至可以透過 Cluster autoscaler 來針對節點進行調整，根據需求關閉節點或是產生更多節點
c. 動態關閉節點的有個問題是關閉節點時通常會選擇盡可能閒置的節點，但是閒置並不代表沒有任何服務部署再
上面，因此該節點上的 Container 都要先被轉移到其餘節點接者該目標節點才可以被正式關閉。這部分的邏輯作者認為相對複雜
d. 整體來說，k8s 有兩個動態調整的部分，動態節點與動態服務，而現有的架構只有一個動態節點。所以使用 k8s 則會讓問題變得更多更複雜。

3. Traffic Ingress
Ably:
a. Traffic Ingress 基本上每個 cloud provider 都提供了很好的解決方案，基本上團隊只要能夠維持每個服務與背後的機器的關係圖，網路流量基本上都沒有什麼需要團隊管理的。
b. 使用者會透過直接存取 NLB 或是透過 CloudFront 的方式來存取團隊內的服務

K8s:
a. EKS 本身可以透過 AWS VPC CNI 使得每個 Container 都獲得 VPC 內的 IP，這些 IP 都可以讓 VPC 內的其他服務直接存取
b. 透過 AWS LB Controller，這些 Container 可以跟 AWS LB 直接整合，讓封包到達 LoadBalancer 後直接轉發到對應的 Container
c. 整體架構並不會比團隊目前架構複雜
d. 唯一缺點大概就是這個解決方案是完全 AWS 綁定，所以想要透過 k8s 來打造一個跨 Cloud Provider 的統一介面可能就會遇到不好轉移的問題。

4. DevOps
Ably:
a. 開發團隊可以透過簡單的設定檔案來調整部署軟體的版本，後續相關機制就會將 VM 給替換掉，然後網路流量也會自然的導向新版服務
K8s:
a. 開發團隊改使用 Kubernetes 的格式來達到一樣的效果，雖然背後運作的方式不同但是最終都可以對開發團隊帶來一樣的效果。

上次四個分析基本上就是，使用 k8s 沒有帶來任何突破性的好處，但是 k8s 本身還有其他的功能，所以接下來作者想看看 k8s 是否能夠從其他方面帶來好處

Multi-Cloud Readiness
作者引用兩篇文章的內容作為開頭，「除非經過評估，否則任何團隊都應該要有一個跨 Cloud-Provider 的策略」
作者表明自己團隊的產品就是那個經過評估後斷言不需要跨 Cloud Provider 策略的團隊，同時目前沒有往這個方向去追求的打算。
同時作者也不認為 K8s 是一個能夠有效達成這個任務的工具。舉例來說，光 Storage 每家的做法都不同，而 K8s 沒有辦法完全將這些差異性給抽象畫，這意味者開發者終究還是要針對這些細節去處理。

Hybrid Cloud Readiness
管理混合雲(Public Cloud + Private Cloud based on Bare-Metal servers)是作者認為一個很合理使用 K8s 的理由，畢竟這種用法就跟當初 Google Borg 用法一致，是經過驗證可行的。
所以 Ably 如果有計畫要維護自己的資料中心時，底層就會考慮使用 Kubernetes 來管理服務。畢竟這時候沒有任何 Cloud Provider 提供任何好像的功能。
不過 Ably 目前沒有任何計畫，所以這個優點也沒有辦法幫助到團隊

Infrastructure as Code
團隊已經大量使用 Terraform, CloudFormation 來達成 IaC，所以透過 k8s YAML 來維護各種架構不是一個必要且真的好用的方式。

Access to a large and active community
另外一個很多人鼓吹 K8S 的好處就是有龐大的使用者社群，社群內有各種問題分享與探討。
作者認為
a. AWS 的使用者社群數量是高於 Kubernetes
b. 很多情況下，一個迭代太快速的產品其實也不一定對團隊有太大的幫助。
c. 很多人都使用 k8s，但是真正理解 k8s 的人微乎其微，所以想要透過社群來幫忙解決問題其實比你想像的還要難，畢竟裡面的問題太雜，很多時候根本很難找到一個真正有效的答案。

Added Costs of Kubernetes
為了轉移到 K8s, 團隊需要一個全新的 team 來維護 k8s 叢集以及使用到的所有基本服務。舉例來說，EKS, VPN CNI, AWS LB 帶來的網路好處並不是啟動 EKS 就會有的，
還必須要安裝相關的 Controller 並且進行設定，這些都是額外的維運成本。
如果找其他的服務供應商來管理 Kubernetes，這意味公司就要花費更多的$$來處理，所以對團隊來說，金錢與工作量都會提高，不同的解決方式只是這兩個指標的比例不同而已。

結論:
1. Ably 覺得 Kubernetes 做得很好，但是團隊目前沒有任何計畫去使用它，至少目前這階段沒有看到任何實質好處
2. 仔細評估後會發現，導入 k8s 其實也會帶出不少管理上的問題，反而並沒有減輕本來的負擔

▶民進黨中央黨部於３月１８日向中正一分局報案，有關中央黨部的網路被國家級的中國網軍惡意侵入。24日，曾發生對民進黨中央黨部網路五分鐘內高達十萬多次的攻擊。面對這樣的攻擊，且是國內重要的政黨，能癱瘓民進黨的網路，那麼其他交通、金融、政府機關、基礎設施也會面臨相同的問題。民進黨18號報案，警政署派員查看，但回應沒有辦法解決，之後便沒有下文。詢問副署長是否有在處理此問題？
警政署副署長回應：18號民進黨報案後，台北警察局與刑事警察局便成立專案小組，在29號由偵九隊、研發科及台北市同仁到黨部會勘，同時取回側錄封包紀錄，由研發科分析完畢交偵九隊偵辦當中。從這些資料中發現是一個DDOS的攻擊，我們也採取相關的因應，包括尋求民間雲端公司將網站架在該處以利控管。並採用其他商用網站的網站分流機制，希望從攻擊面去溯源追查。
▶本席質詢：目前為止，問題並沒有解決。是否是欲將問題推回民進黨，由其尋求國際級防務公司的協助？還是政府應有所作為？讓不只是國內重要政黨、或是政府機關、金融機構都有一套標準的因應作業程序？
警政署副署長回應：刑事局科技犯罪刑事中心將會結合政府的相關網路安全單位、民間業者單位來進行這一個案子。
▶國安局對於未來的防治機制（防範對岸網路攻擊）的人事編制，對於網路安全部未來招考人員的資格、標準為何？有人才的來源嗎？
國安局長回應：依不同人才的需求將有四大編組。本年度已到國內相關大學進行交流，了解相關大學在領域、專長人才的訓練，也對其提出本局的需求。本局從人員、專業、作業的考量下，使其在一體化的考量來完整推動。另外說明DDOS只會對網路造成癱瘓，並不會對電腦造成傷害。
▶委員質疑：雖然是小技術，但是一癱瘓即造成作業的中斷，這並不可以小看。它可以對政黨，也可以對政府、金融單位造成影響，甚至選舉時對中選會網路造成影響。已有破解的方法嗎？
國安局長回應：回答：去年七月佔中事件，DDOS也對蘋果日報及諸多企業造成癱瘓，這是可以破解的，從被植入殭屍病毒的電腦進行掃毒。
▶本席支持國安局成立網路安全的相關部門。但該部門人事相關的法規、薪資彈性、工作方式，這都需要有一套機制來做長期的管理與運用。對於民進黨所遭受的攻擊，請結合警政署、刑事組盡速處理。
▶本席聽聞哥倫比亞大學將中國學生組織關掉。美國的學生團體都是相當自由化，一般而言學校是不會進行干涉。雖然內容不是很明確，但不排除關閉原因與中國特務運用學生團體、組織有關，以其他不當方式影響美國的國土安全。反觀台灣，陸生也日漸增加，對於正常的學習交流，台灣人都歡迎，可是若有類似的情報工作、不當的組織，本席希望國安局能有所掌握。本席高度懷疑，也不排除類似哥倫比亞學生組織的情報工作也正在台灣發生。詢問國安局是否有掌握？
國安局長回應：同意委員的疑慮。本局在過去也對行蹤不明的人士當成案例，尤其是中共把三中一青的作為其工作重點，我們也將此問題導向為如何捍衛國國家安全。我們不會放鬆，反情報工作上將強化為工作重點。委員提出的問題，我們也將積極深入各個可能場所來進行防範。
▶中國在台灣廣設辦事機構，但我們對辦事機構的法規尚未通過。其可能用各種方式，如商業交流，在台灣開始進行組織滲透。我們自己相關的組織系統，包括國家安全、國安局的預算都該重視，做好交流的管控。國安局應有所作為，有需要皆應提出計畫，國家安全不分黨派。