ref: https://loft-sh.medium.com/11-of-the-best-open-source-kubernetes-tools-2021-edition-b4aa49487845

本文會從三個類別來介紹作者認為跟 Kubernetes 開發維運有關的好用工具，這三個領域分別是
1. Running Kubernetes Environments
a. Minikube 依然好用，可以輕鬆創建環境，作者提到創建一個 cluster 只要 23 秒即可 <--- 我是懷疑加上 VM 時間應該沒辦法，除非單純用 container mode.
b. Helm 目前依然是部署方面最普遍被使用的包裝方式，
c. K3S 目前依然是輕量級 k8s 的選擇，特別是 IoT 等輕量級環境下想要部署k8s叢集則k3s幾乎是唯一選擇。

2. Simplify Feedback Loop
這個領域主要探討的針對開發者來說，如何能夠有效的提升開發流程，如何讓開發者能夠與 k8s 的互動更為抽象與簡單，讓開發者可以不需要學會太多k8s的指令又能夠將開發的結果送到k8s叢集內進行測試。
這類型的反饋資訊也就是標題所述的 Feedback Loop

a. 由 Google 開源維護的 Skaffold 專案目前能夠簡化開發者開發k8s 應用程式的流程，將建置Image,部署到k8s等步驟都自動化，開發者只需要呼叫指令或是存擋即可讓最新的程式碼自動部署到k8s叢集內。
b. 另外一套名為 Tilt 的軟體與 Skaffold 非常類似，不同點是 Tilt 有提供友善的介面，讓使用者可以更快地去知道當前撰寫的程式碼部署到k8s後會有什麼問題，從基本的 YAML 錯誤到部署後哪邊出問題都能夠盡量的點出
c. DevSpace 也是一套針對開發流程的開源專案，跟 Tilt 一樣都有提供介面，而全部的操作都是基於 devspace 這個指令來完成。
d. Lens 這套 Kubernetes 的 GUI 軟體功能愈加強大，作者甚至稱其為 IDE 而非單純的 GUI 功能，透過各式各樣不同的 Plugin 幾乎可以完成你想要達到的任何功能。

3. IDE Dev Tools I Can’t Live Without
a. 作者推薦 VSCODE 上面的 Kubernetes Tool 這個擴功功能，作者認為如果你的 IDE 不能夠有效地分辨 Helm Template 與 K8s vanilla YAML 的差異的話，你的開發速度跟體驗將會奇差無比。
b. VSCODE 上面的 YAML Language Support 這個功能也很好，能夠針對各種 YAML 文件的操作給予自動補齊與偵錯
c. 另外一個作者推薦的 VSCODE 擴充功能是 Footsteps，作者提到對於一個數百行以上的 YAML 檔案來進行修改有時候是厭煩的，而這個擴充功能會幫你把最近修改的內容用顏色給標示強調同時也透過快捷鍵可以讓你快速地跳於最近修改的行數之間往返。

這篇文章主要就是作者分享自己使用的一些工具，有興趣的可以參考原文

ref: https://medium.com/swlh/quick-fix-sharing-persistent-disks-on-multiple-nodes-in-kubernetes-ef5541fd8376

這篇文章是 kubernetes 與 Storage 整合的經驗分享文，該文章包括了下列內容
Cloud Storage, NFS, Kubernetes, PV/PVC.

Kubernetes 內針對這些儲存相關的使用方式有
1. 使用 ephemeral 的儲存設備
ephemeral 只適合暫存資料使用，因為該儲存設備不是持久保存的，這意味 Container 如果重啟，資料就會消失。
2. 使用 Bind Mount 的方式將資料從節點掛載到容器中
就如同過往使用 Docker 時會使用 -v 的方式將同節點中的儲存目錄給掛載到容器中來使用。

基本上有任何永久性儲存的需求都會採用(2) 這個方式來處理，而目前很多 Cloud Provider 都有提供相關的儲存裝置讓你的 VM(k8s Node)
可以輕鬆存取與使用。

舉例來說，AWS 有 EBS， GCP 有 GPD，這類型的 Block Storage Device 本身支援動態掛載與卸載，所以就算 Kubernetes 將目標 Container 重新部署到
不同節點上也不需要擔心資料會不同，因為這些 Storage 可以隨者不同節點動態掛載上去，讓你的 Container 看到相同的資料。
但是以上兩個裝置都有一個限制，就是並不支援同時多人寫入的動作，於 Kubernetes 只能使用 Read/Write 模式。
這意味每個 Storage 同時只能有一個 Container 去進行讀寫操作(but Azure 的服務就沒有這個限制)

作者假設今天有一個服務底層是由三個元件組成，這些元件會需要針對相同一個資料集一起處理。
舉例來說有服務 A,B,C
A: 將資料寫入到儲存系統中
B: 從儲存系統中讀入資料進行二次處理，處理完畢再寫回去儲存系統中
C: 將資料從儲存系統中讀出並且供外部使用

上述情境簡單說就是一個儲存設備，會有三個服務同時想要讀取，一個專心寫，一個同時讀寫，一個專心讀。
這種需求就沒有辦法單純使用 EBS/GPD等裝置來使用，因此作者接下來就會針對如何使用 NFS 這套網路儲存系統來搭建一個符合上述需求的用法。
該解決方案流程如下
1) 透過 EBS/GPD 的方式掛載一個儲存空間到 k8s 節點中
2) 部署一個 NFS Server 的容器到 Kubernetes 中，該 NFS Server 會使用 EBS/GPD 作為其儲存空間的來源
3) NFS Server 透過 service 分享服務
4) 部署 PV/PVC 物件到 Kubernetes 中
5) A,B,C 三種容器透過 PVC 的方式來存取 NFS Server

因為 NFS 本身就是一個可多重讀寫的解決方案，作者透過這種方式讓多個應用程式可以同時讀寫，同時將這些資料保存到 EBS/GPD 的儲存空間中。
不過這種用法帶來的問題可能就是速度問題，從同節點直接存取變成透過網路存取，所以如果本身對於存取有非常高的頻寬需求時，使用這種解決方案也許會遇到
很難解決的瓶頸，畢竟大部分人的 k8s 叢集都是 data/control 兩種資料交雜於底層的網路架構中，沒有辦法將 data plane/control plane 給分開來。

有興趣看作者如何一步一步搞定上述流程的可以參考全文

ref: https://svpino.com/lessons-learned-from-the-smartest-software-engineer-ive-met-35895ac9fe3a

本篇文章是工作經驗談，作者想要分享這十多年的工作經驗中，從那些聰明人身上所學到的事情，包含了
1. Fast is better than good
2. Unlearn what you know about technical debt
3. There aren’t stupid questions
4. Communication outweighs technical skills
5. Just because you can doesn’t mean you should
6. Share like there’s no tomorrow
7. Take full responsibility
8. The best code is the one nobody wrote
9. If you don’t test, it doesn’t work
10. Embrace failures

Fast is better than good
大部分的情況下，一個稱得上是好的解決方案勢必都要能夠針對時間，精力與成本這三個方面取得平衡。
太多人很容易一開始就會想要設計最完美個解決方案，導致一開始花費大量時間在思考跟設計，卻遲遲沒有動手。
作者認為不是說不要思考，而是不要認為有辦法一開始就可以想到一個最佳解，而是應該一邊做一邊改進。

Unlearn what you know about technical debt
技術債想必是大家都很厭惡的一個情境，作者希望大家可以從不同層面的地方去看待技術債
作者認為只要能夠用正確的方式去面對，技術債身上也可以有值得學習的機會，因為大部分的技術債
都是因為時間與人力不足下進行取捨所造成的結果，這邊帶來的隱含是到底哪些事情是團隊當前最重要的，哪些是不重要可以之後再改善的
最後來個公道話，計畫債太多一定有問題，但是沒有技術債更大的機率代表你都把時間花費在不是最重要的事情身上

There aren’t stupid questions
有問題就使勁地去發問，更多時候努力工作並不會讓你這個人獲得一個很深刻的印象，但是有效率與聰明的工作相對容易讓你被人記住。
任何不清楚的地方就問，問到一切都明瞭。

最後補上一個引言
「會問問題的人會當傻子五分鐘，但是不問問題人的人則是一生傻子」

Communication outweighs technical skills
能夠透過溝通來清楚描述想法的能力可謂是一個不可或缺的技能。
相對於技術能力來說，溝通能力很容易被大家給遺忘，甚至大家都不會覺得這記得有什麼值得重要的。
但是良好的溝通帶來的效果是無形的，所以請投資時間去學習如何有效的溝通。

Just because you can doesn’t mean you should
最簡單為團隊帶來影響的方式就是好好的針對所有事情排定優先順序，學會如何分辨重要性其實非常重要
畢竟時間有限，如何於有效的時間內帶來最大的效益也是一個不可或缺的技能

Share like there’s no tomorrow
隱瞞各種資訊並不會讓你成為團隊中不可或缺的關鍵人物，相反的，願意分享事情與知識的人更容易變成團隊中的核心角色
學會分享也同時藉由分享的這個步驟讓整體團隊一起成長

後續有興趣的可以參閱原文

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 其實也會帶出不少管理上的問題，反而並沒有減輕本來的負擔

ref: https://medium.com/geekculture/kubestack-a-must-use-117a32efd427

本篇文章要介紹的是一個基於整合 IaC 的 GitOps 開源專案 Kubestack

過往探討到 GitOps 時總是會圍繞如何透過有效的管理與部署 Kubernetes 上的應用程式，譬如 ArgoCD, Flux, Rancher Fleet 等。
當然 GitOps 本身也是一個沒有標準做法的文化與概念，自行透過 Gitlab, Git 等方式也是有辦法實作出相同概念的解決方式。

而 Kubestack 則是一個專注於 Kubernetes 本身的 GitOps 解決方案，而非一般來探討的應用程式。
其本身的架構是基於 Terraform 之上， 因此 Kubestack 本身也自行實作了屬於自己的 Terraform Provider 讓所有對 Terraform 的使用者可以更快上手與使用。
雲端整合方面， Kubestack 整合了 AKS,EKS,以及 GKE，這意味使用者可以輕鬆地透過 Kubestack 來創建這些由雲端企業管理的 Kubernetes 叢集。
除了雲端之外， Kubestack 也支援本地機器的 Kubernetes 叢集，其透過 KIND 的方式於本地端架設一個簡易的模擬環境，可以讓使用者再將修改給合併到真正的 Git 時先行於本地端進行測試，確保一切都沒有問題才會合併。

本文後半部分是一個手把手的教學範例，示範如何透過 Kubestack 來玩耍，同時也提到官網也有滿直覺的教學跟介紹，對於如何使用 GitOps/Terraform 來管理 AKS/GKE/EKS 的使用者也許可以參考看看這個專案

ref: https://faun.pub/the-best-infrastructure-as-code-tools-for-2021-b37c323e89f0

這篇文章是一個 IaC (Infrastructure as Code) 的推廣文，文章分成幾個部分，從 IaC 的基本概念與應用談起，接者分析了幾個常見的 IaC 工具，最後探討了實際的使用案例

文章偏長，對於 IaC 概念很熟悉的讀者應該可以很快速地看完，以下針對部分進行一些摘要

The need for Infrastructure as Code
作者先描述過去幫機房部署新伺服器時的各種流程，機器少量時能夠透過人力慢慢處理，但是這類型的操作繁瑣，重複且惱人
為了讓這些流程處理得更佳順遂與一致，會有各式各樣的 scripts 等相關工具被開發出來 ，而這些流程慢慢的會往自動化的方式去發展。
IaC 文化的興起會使得有愈來愈多獲得共識的工具被開發出來，這使得 IaC 的使用門檻會有機會降低，愈來愈多的使用者能夠更簡易的透過 IaC 的方式來管理與維護自身的架構

Benefits and reasons to implement IaC
IaC 帶來的好處是非常顯著的，譬如
1. 將 Config 檔案當作整個環境的 sing source of truth
2. 每次的部署都是基於上述的 Config 來部署，能夠確保每次部署都獲得一樣的結果，避免人為的反覆長期操作帶來的錯誤
3. 透過程式化的方式去建置環境能夠更快速的去應變各種環境需求，對於 testing, developing, production 等各種變化都可以透過 config 的差異來快速搭建
4. Config 也可以透過 Git 的方式去管理來獲得更好的可稽核性與管理性。

Principles and best practices of Infrastructure as code
作者這邊列出了幾個實作上的推薦方式
1. 透過版本控制的方式來管理 IaC 的設定檔案，能夠讓維運人員使用開發者常見的開發合作流程來管理 IaC
2. 將 IaC 的工具整合到 pipeline 的 CI/CD 流程，讓 CI 流程去檢查 IaC 的設定是否符合預期以及 CD 流程來幫忙自動部署修改架構

Infrastructure as code tools
這個區塊作者列出了幾個常見的工具，包含 Terraform, CloudFormation, Puppet, Pulumi 等，接者又透過一張大表格來比較 Terraform/Pulumi/CloudFormation 三者的差異
Pulumi 這工具這一兩年開始聲勢比較多，跟 Terraform 一個最大的差異我想就是撰寫的方式，可以透過 Js, Go, Python...等程式語言來描述架構而並非使用 Terraform 自定義的 DSL 來管理。


最後面作者也列舉了六七個適合 IaC 的使用場景，有興趣的歡迎閱讀全文

ref: https://medium.com/flant-com/cert-manager-lets-encrypt-ssl-certs-for-kubernetes-7642e463bbce

這篇文章是個分享文，作者分享如何使用 cert-manager 這個工具透過 lets-encrypts 來獲得一個被認證的 SSL 憑證供 kubernetes 內部應用使用。

根據 CNCF Technology Radar(https://radar.cncf.io/2021-02-secrets-management) 的介紹，目前 Cert-Manager 幾乎是 k8s 內管理憑證最為知名的專案。
本篇文章針對幾個四種不同的使用情境來介紹如何使用 cert-manager，以下針對每個用法給一些摘要。

前期提要：
Kubernetes 會使用 SSL 憑證的大部分情況都是透過 Ingress 這個物件去描述需要使用 Certificate，所以文章的範例都會是基於 Ingress 的使用下手。
譬如說 Ingress 想要使用開啟 TLS 的功能，需要使用一個 secret，而 Cert-Manager 則會基於其設定最後產生出一個符合 Certificate 用法的 Secert 物件給 Ingress 使用。


Self-signed certificate
第一種是最簡單也是最直接的用法，透過 cert-manager 來產生一組自行簽署的簽證
正常情況下產生後的自簽憑證預設是不被信任的，畢竟預設情況下並沒有加入一個 CA，因此簽出來的憑證用瀏覽器打開還是會呈現不可信任
如果環境有事先準備好 CA 的話，是可以將該 CA 加入到 cert-manager 的設定中，這樣就可以簽出一個被信任的憑證了。

Let’s Encrypt certificate with the HTTP/DNS validation
第二個則是最普遍的用法，就是透過 Let's Encrypt 的服務來獲得一個可以被信任的憑證，而 Cert-Manager 目前支持兩種 ACME 的認證方式，分別是 HTTP 以及 DNS，這兩個方式最主要的目的都是要確認
申請者是該申請 domain 的擁有者，所以可以透過不同的方式來驗證。

如果想要使用 DNS 來進行驗證的則必須要確認該域名管理的服務商是否有提供相關的 API 同時該 API 是否 cert-manager 有支援，文章中作者使用 CloudFlare 來當範例展示一下如何使用 DNS 挑戰來驗證相關的 TXT Record.
由於 DNS Record 本身會有 Propagation 延遲傳遞的問題，因此驗證上通常會比使用 HTTP 的方式還來得慢一點。
Cert-Manager 本身也支援兩種方式同時使用。

另外使用 Let's Encrypt 時要特別注意，非常推薦一開始使用 Let's Encrypt Staging 的服務來進行測試，不要一開始就直接使用 Production 的 API，因為 Production 會將短時間內發送大量請求的網域給停權一陣子，要等待一段時間後才可以再次發送。
因此開發測試過程請先使用 Staging 的 API，待一切沒問題後才轉向 Production API。

Using special Ingress annotations
這種方法其實是簡化維運者的工作，Cert-Manager 會有一個額外的 Controller 去監聽所有的 Ingress 物件，如果該 Ingress 物件的 Annotation 有描述跟憑證相關的資訊，該 Controller
就會自動創造 cert-manager 相關的資源，讓管理者減少需要自己部署的物件數量，反而將部分操作轉交給 Controller 去處理。

https://itnext.io/great-cks-kubernetes-security-exam-preparation-guide-to-help-you-pass-14fe5ab30ce1

本文是作者的心路歷程分享分享文，想要探討什麼是 Certified Kubernetes Security(CKS) Specialist 以及如果要準備這個考試可以如何準備

CKS
1. 根據 CNCF 官網的介紹, CKS 測驗是用來確認 CKS 能夠擁有與掌握如何安全的管理 Kubernetes Clusters，安全的概念包含安全的去處理這些 Container 以及整個 Kubernetes 平台的安全性(建置，部署，運行等所有階段)
2. 考取 CKS 之前要先通過 CKA (Certified Kubernetes Administrator) 的測試
3. Kubernetes 官網上其實有非常多的文件與操作說明， CKS 更像是一個幫助你去挑戰自我，確認自己有能力與知識去處理 k8s 安全相關的設定與操作。

如何準備 CKS
作者列舉了幾個重點概念
1. Docker Image 實作上的最佳實踐
2. 理解下列內容
a. CIS Kube-bench
b. Trivy
c. Sysdig/Falco
d. AppArmor
e. Seccomp
f. OPA/Gatekeeper
3. Linux 基礎理解，特別是 cGroup
4. Kubernetes 架構以及相關元件，譬如 RBAC, NetworkPolicy, PSP 等
5. API Server 相關操作，包含 Admission control, Audit 以及如何除錯

作者於文章後半部分列出了很多文章與影片連結，資源非常豐富，其中還提到 CKS/CKA/CKAD 的模擬器 (https://killer.sh/)，對於該考試有興趣的一定要使用這些資源來練習

最後列出一些純 k8s 的一些考試內容
1. Admission controllers.
請確保你熟悉各種不同類型，如 PodSecurityPolicy,ImagePolicyWebhook 的實作與差異，並一定要知道這些是如何跟 API Server 互動的。
2. Immutable containers
如何使用 securitycontext 創造一個 Immutable 的容器並且避免一些可能會造成 mutable 的操作
3. Network Policy
4. PodSecurityPolicy(隨者 OPA 的發展，這個考試內容將會慢慢的被捨去)
5. gVisor

對於 CKS 考試有興趣的建議看看本篇文章，其中文章內有滿多跟安全相關的影片與文章也都值得閱讀

ref: https://www.cyberark.com/resources/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions

本篇文章是一個基礎分享文，整個主軸圍繞於 Authentication 與 Authorization 兩大塊，同時透過這兩大概念的介紹來分享一些會可能會有資安問題的設定

開頭作者探討了 Kubernetes 的架構，並且將 API Server 這個重點核心拿來出探討，提到為了存取 Kubernetes API，使用者必須要經過三個階段的處理，分別是
Authentication, Authorization 以及 Admission Control

接者用一個簡單的流程來說明上述三者的差異，假設今天有一個 Client 想要請求 API Server 幫忙創建一個 Pod 的物件。
首先 API Server 會針對該請求進行 Authentication 的檢查，通常情況下會使用 Certificate, Tokens, Basic Authentication(username/password) 來判別。
如果通過後，則會進入到 Authorization 的階段，該階段要判別發送當前 Request 的 Client 是否擁有創建 Pod 的權限，如果有權限就會把相關操作交給後續的 Admission Control 來處理。
文章中舉了一個名為 AlwaysPullImages 的 Admission Controller，該 Controller 對於一個多用戶的 Kubernetes Cluster 來說特別有用，主要是用來確保使用者 A 想要使用的 Private Image 不能被使用者 B 存取。
試想一個情況，假設今天使用者 A 順利於 NodeA 上抓取了自己的 Private Image，那使用者 B 假如很剛好知道這個 Image 的名稱，是不是有機會就可以不需要相關權限直接使用 NodeA 上的 Image？
所以這個 Admission Controller 就是用來避免這個問題的。

接者作者從 Authentication 與 Authorization 中個挑選一個方式來介紹並且講解這兩者如何結合的。

Authentication 使用的是 Service Account Token，管理會事先於 Kubernetes 內創立一個相關的 Service Account，並且把該 SA(Service Account) 的 Token 給交給 Client(Kubeconfig 也可)
Client 發送 HTTPS 請求到 API Server 的時候就可以夾帶這個 Token 的資訊，這樣 API Server 就會去檢查該 Token 是否存在於 Cluster 內。

事實上當每個 Pod 被創立後， Kubernetes 預設情況下就會將該 namespace 下的 service account 資訊給掛載到該 Pod 內的 "/var/run/secrets/kubernetes.io/serviceaccount" 這個路徑
這樣該 Pod 就可以使用該 Service Account Token 的資訊與 API Server 溝通。

Authorization 則是使用 RBAC 的方式來處理， RBAC 由三個部分組成，分別是 Role(代表可以針對 Cluster 進行什麼樣類型的操作，譬如 create pod, delete pod), Subject(你是誰，譬如 Service Account), RoleBinding(用來將 Role 與 Subject 給綁定)

管理員要創建並且管理這些叢集的話，就要好好的去設計這三個物件的關係，來確保最後的 Client 可以擁有剛剛好符合其需求的權限，千萬不要為了懶散而給予過多權限。

接者作者列舉了五種 Risky permissions 的可能情境
1. Listing secrets
大部分的應用程式開發者都會使用 secret 的物件來管理一些機密資訊，如帳號密碼，憑證等，所以一個擁有 list secrets 的 service account 其實是相對危險的。
非必要的話，不要讓管理員以外的任何使用者有這個權限，特別是使用 ClusterRole/ClusterRoleBinding 時要特別注意

2. Creating a pod with a privileged service account
假設今天有一個攻擊者已經獲得一個可以創建 pod 的 service account，那該攻擊者已經可以很順利的於叢集內創建 Pod 去進行基本操作(譬如挖礦)
如果攻擊者很巧地又知道目標 namespace 內存在一個很強的 service account，它就有辦法讓他創立的 Pod 去使用這個很強的 Service Account 並且進行更多後續操作

3. Impersonating privileged accounts
作者提到 Impersonating 這個 Role 裡面的動作要特別小心使用，擁有這個權限的使用者可以輕鬆化身為其他的使用者/群組
舉例來說，一個擁有 Impersonating -> users/group 的 serviceaccount 是沒有辦法看到任何 secrets 的物件。
但是攻擊者只要使用的時候加上 --as=null --as-group=system:master 則就會變成如 master 般的上帝擁有這些權限
因此這種權限設定上要特別小心

4. Reading a secret – brute-forcing token IDs
5. Creating privileged RoleBindings

後續兩個有興趣的可以參考全文，都是滿有趣的一些想法，值得閱讀擴展自己的認知

ref: https://iximiuz.com/en/posts/devops-sre-and-platform-engineering/

本篇是一個由 Twitter 討論串引發的後續文章，作者想要聊聊 DevOps, SRE 以及 Platform Engineering 的差異。
文章中附有相關 Twitter 討論串的連結，對於原文有興趣的也可以去參閱一下 Twitter

註:就我個人觀察到的現象，台灣企業很少看到 Platform Engineer 的職位，有人知道有哪些公司有開這種職位可以留言分享一下

作者自述自己是個從事 SRE 工作但是內心卻是個軟體工程的技術專欄作家，因此就自己的過往經驗想分享一下對於這三者的看法，而這些討論就引起了一些回文
因此作者將這些概念整合下來寫下這篇文章來總結一下各方網友們的看法。

作者的軟體生涯中，從分工仔細的團隊到新創公司都經歷過，再還沒有認知到 DevOps/SRE 這類型名詞前就已經體驗過部署開發維運三合一的人生。

隨者愈來愈多人開始探討 DevOps 以及 SRE 這兩個詞，兩者之間的比較沒有停過，甚至還有專屬的兩個 awesome 系列 awesome-sre, awesome-devops 清單來列舉如何學習這兩個技術。
整個求職市場也因為這兩個名詞的出現而有變化，作者也因應這股潮流開始往下探索，因此最後就以自己自身的經驗來分享自己對於這些名詞的想法。

其中作者有提到一點也是我非常認同的，就是這些名詞代表什麼含義，這些職稱要做什麼都會隨者不同公司不同團隊而有變化，畢竟每個公司的產品跟商業走向都不同
期待能有一個一統天下的職稱跟工作內容反而才是不切實際的。所以接下來的探討就只是作者跟幾個網友們的討論，不要當作圭臬，也不要當作聖旨，自己有自己的想法比較重要。

# What is Development
1. 作者認為開發的概念非常簡單，就撰寫程式，唯一能夠為公司貢獻 $$$ 的職位，畢竟有人寫程式還有產品，沒人寫程式也沒什麼好部署的。
2. 推特網友表示: 只有 sales 才是幫公司賺錢的，剩下都是公司的支出
3. 作者從 2011 開始了軟體工程師生涯，過往作者都很期望自己可以去部署一下自己撰寫的程式，但是基本上都是團隊內的其他神秘人物會默默的部署這些程式到生產環境。

# What is DevOps
1. 作者不想探討何謂官方的正式定義，只想聊聊自己多年工作經驗的感想
2. 對作者來說， DevOps 是一個能夠讓開發者對於部署應用程式有更多機會與權力的文化，實作上沒有一定的準則
3. 作者還待過那些開發者都擁有 sudo 權限來部署應用的新創公司，不過現在這些流程都慢慢的被自動化 CI/CD 流程給取代。
4. DevOps 最初的想法應該是遠遠超過作者所描述的，不過作者就自己工作上的經驗，找工作的經驗，看職稱 JD 的經驗來看，DevOps 更像讓開發者打造的產物可以更有效率的被部署
5. DevOps 本身不應該去探討產品的商業邏輯，那是開發者要探討的。

# What is SRE
1. Google 推出了一系列的書來探討何謂 SRE，那系列書籍的想法偏向 SRE 是其中一種 DevOps 文化的實作方式。
2. 相對於 DevOps，作者更喜歡 SRE 帶來的職缺內容。
3. 作者對於提到 CI/CD pipeline 之類的職缺都感到無聊且沒興趣，而 DevOps 的工作職缺往往都充滿這些令人無聊的東西。
4. 相反的，作者更喜歡去專研系統問題，譬如探討為什麼會有 bug, memory leak, 效能不好...等
5. 作者認為 SRE 要負責去維護上線環境，確保使用上沒有問題。
6. Google 的 SRE 系列書籍還提到了關於 monitoring, alerting, SLO 等各種如何確保服務正常的機制。 Facebook 則是有非常著名的 Production Engineer 的職稱，其跟典型的 SRE 基本上沒太大的差別。
7. 推特網友表示: SRE 專注於生產環境, DevOps 專注於 CI/CD 與開發效率與流程
8. 另外一名推特網友表示(這也是我目前最喜歡的答案): DevOps 從開發角度為起點， SRE 從維護上線環境出發，兩職缺於某處產生交集。

# What is Platform Engineering
1. 作者想起當年還是一家新創的唯一一位工程師時，那時候還要去租借實體機器來架設環境，所以那時候也撰寫了不少腳本來安裝機器，也要確保機器之間的網路可以正常運作。
2. 加入一間比較有規模的公司後瞭解到看來 infra 相關的工作是一個很類似 SRE/DevOps 但是又有些許不同的領域
3. 作者認為 Platform Engineering 目標就是要打造一個可以讓 Dev, Ops, SRE 能夠使用的環境
4. 作者感覺 Platform Engineering 要負責維護 data-center 內上千台的機器，確保這群機器能夠正常運作，維護外也要包含升級，設定等。

# What's about titles?
1. 作者前述探討的都是基於負責領域，比較不去談這些職稱應該要做什麼
2. 根據作者經驗，當公司規模逐漸變大時，分工就會愈來愈細，這時候 Dev, Ops, SRE, PE 等職缺就會開始逐漸專項化。
3. 重點就是， YMMV (Your Mileage May Vary )，不同情況，不同答案，不要太專注於一個死板板的解釋。


個人想法: 公司要開什麼職缺名稱就不管他了，工作內容才是最重要的，有錢的任性老闆也可以開一個"開源軟體整合工程師"但是要你整合 CI/CD 加上維運的工作。

ref: https://medium.com/k8slens/most-popular-lens-extensions-june-2021-8f88ef79aab6

這篇文章是作者推薦 Lens 這套 Kubernetes Dashboard 上相當熱門的擴充功能。

1. Mirantis Container Cloud Extensions
這項功能是由 Mirantis 所開發的，可以讓使用者更輕鬆的去使用 Mirantis Container Cloud 上的資源

2. Starboard Extension
該擴充功能是由 Aqua Security 所開發的功能，可以更方便地去檢視 Kubernetes 中部署 Image 的安全性報告，
該報告主要會列出該 Image 已知的 vulnerability 列表。

3. Kubernetes Resource Map Extension
該擴充功能會透過視覺化的方式來呈現 Kubernetes 內的資源關係，譬如 Service, Deployment, Pod...等彼此關係，可以讓使用者更清楚的知道
目前叢集中不同資源的彼此關係

4. Kubecost Extension
如果有使用 Kubecost 這個專案來管理 Kubernetes 叢集內的相關資源成本的話，可以使用這個擴充工具將這個資訊直接已視覺化的方式呈現到 Lens 的介面中

5. GKE Sync Extension
該擴充功能會自動地透過 gcloud 指令來同步 GCP 上的資源，包含了 projects 以及 GKE Clusters。
透過這個擴充功能，使用者可以不需要去準備相關的 kubeconfig 就可以管理新加入的 GKE Clusters。

6. Capsule Extension
該擴充功能由 Clastix 所開發的，Clastix 提供了一個讓 Kubernetes 支援多租戶的功能，而該擴充功能是讓使用者可以透過 Lens 來輕鬆管理這些多租戶的資源與使用情況

ref: https://engineering.hellofresh.com/ambassador-the-evolution-of-ingress-gateway-at-hellofresh-3889232cab6f

本篇文章是 HelloFresh 這個美國生鮮食材訂購服務想要分享其團隊中 Ingress gateway 的演化史。該團隊過往使用 VM 作為其底層基礎架構來部署應用程式，後來遷移到
kubernetes 改用容器來部署，然而其內部的其他元件並沒有隨者 kubernetes 轉移而一併更新，譬如文章要探討的 Ingress gateway。
因此文章後將探討原先的 Ingress gateway 架構以及相關問題，最後如何將其與 kubernetes 進行整合來解決前述問題。

再使用 kubernetes 之前，團隊使用兩種不同的方式來處理，分別是內部 API Gateway Janus 以及網頁處理的 Entry (基於 Nginx 的 Reverse-Proxy)
團隊遷移到 kubernetes 之後，這兩個服務都想要透過 kubernetes Nginx Ingress 來處理，不過處理的過程中卻遇到一些問題。

1. 一致性: 每個微服務一開始都透過 Ingress 讓外界存取，然而當團隊開始使用 istio 後有些服務就改使用 Istio Ingress-Gateway 來處理，其他想要使用 TCP 的服務則會改使用 AWS ELB 來處理。
2. 延遲性: 因為 API Gateway 的存取節點都是基於 FQDN 的方式來存取，所以每個封包都要經過更多的節點來到達最終目的，這會增加整個封包傳輸時間。

最大的困惱還是第一個一致性的問題，k8s中有太多的方式讓外界可以存取期服務，每個都有自己獨特的設定，監控以及警示。
為了針對這些問題去解決，團隊內部先期構思一下到底什麼是團隊中理想的 Ingress Gateway

1. Reverse Proxy (HTTP) for websites
2. Mixture of an API Gateway
3. Kubernetes native
4. Advanced routing : (headers, methods, path)-based
5. JWT scope validation
6. Reliability features: Rate-limiting, Retries, Circuit breaking
7. Traffic shadowing
8. Interface for extensions
9. Integration with service mesh

後續文章包含了一些內容，如
1. 作者接者談談為什麼不使用 Service Mesh 所提供的 Ingress gateway
2. 到底要自行開發還是購買解決方案?(最後選擇了 Ambassador Edge Stack)
3. 如何透過 Ambassador Edge Stack 來解決團隊問題
4. 透過 Ambassador Edge Stack 後帶來的好處

有興趣的別忘了參閱全文

ref: https://blog.argoproj.io/argo-workflows-2021-survey-results-d6fa890030ee
這篇是由 Argo 官方所發表的統計文章，該文章主要是探討 Argo Workflows 的使用，總共有效的問券有 60 份

你是誰
1. 32% DevOps Engineer
2. 26% Software Engineer
3. 15% Architect
4. 9% Data Engineer

使用案例(前六大項)
1. Infrastructure Automation
2. Data Processing
3. CI/CD
4. Batch Processing
5. Machine Learning
6. ETL

由於問券內容中大部分都是 DevOps 相關職缺，所以答案會偏向 Infrastructure, CI/CD 也是不太意外。

最受歡迎的功能(按照名次排序)
1. Workflow Template
2. CronWorkflows
3. API
4. Prometheus Metrics
5. Workflow Archive
6. Golang/Java/Python Clients
7. SSO
8. WebHooks
9. Workflow Reports
10. Node Offloading
11. Memoization
12. Semaphores/Mutexes

Argo 官方對於這個評比是有點經驗，本以為會更多人使用(6)與(12)，不過這些功能實際上的釋出也是相對新。

規模
1. 大部分的使用者一天會運行 10~100 個左右的 workflows
2. 有三個使用者每天會運行 1000 個以上的 workflows
3. 大部分使用者每個 workflow 運行的 pod 數量範圍為 10~100
4. 有兩個使用者每個 workflow 運行的 pod 數量超過 10,000

導入生產環境的困境
1. 有七個人表示習慣使用 Python，所以使用 YAML 語法相對困難
2. 有三個人表示需要去熟悉 Cloud-native/Container 的相關用法與概念

為什麼使用 Argo Workflows
1. 28 個人表示因為其是 Cloud Native/Kubernetes 相關專案
2. 有六個人表示 Argo Workflow 是目前最好用的 workflow 專案
3. 有五個人表示輕量與容易上手
4. 有五個人表示與 Argo CD 可以輕鬆整合無煩惱

對 Argo Workflow 有興趣的人可以參考這個專案，其還可以組合出符合 DGA 拓墣的關係圖，讓你的 job 組合變化多端

ref: https://medium.com/nerd-for-tech/ceph-ansible-deployment-testing-using-vagrant-8205a9f39f2d

本篇文章是一個工具分享文，探討如何使用 Vagrant 來架設一個 ceph 叢集環境來測試與開發。

Ceph 是非常知名的分散式儲存的解決方案，其提供 Object, block 以及 file 等儲存空間供不同需求的應用程式使用
Ceph 本身是由多個不同的組成元件所組成，這也是為什麼會稱 Ceph 叢集的概念，元件包含
1. Monitors(MON)
2. Managers(MGR)
3. Metadata Servers(MDS)
4. Object Storage Devices(OSD)

CNCF 畢業專案 Rook 則是一個將 Ceph 與 Kubernetes 整合的解決方案，其簡化了部署 Ceph 的複雜度，讓使用者可以更輕鬆的透過 Kubernetes 去部署一套 Ceph 叢集環境來測試與開發。
不過並不是所有使用 Ceph 的環境都會搭配使用 Kubernetes，作者觀察到目前網路上至少有七種以上的部署方式，而其中最知名也受歡迎的部署方式就是透過 Ceph-Ansible 來安裝。

本篇文章作者探討如何透過 Ceph-Ansible 來部署 Ceph 叢集。
Ceph-Ansible 內本身就有提供 Vagrant 的設定檔案，透過修改設定檔案就可以很順利的自動架起多個 VM，接者透過 Ansible 將 Ceph 的服務依序安裝上去最後就可以順利的搭起一個 Ceph 叢集環境來測試與開發。

本篇文章基本上要對 Ceph 有理解才會比較有背景去閱讀，對於 Ceph 有興趣的人可以參考看看

ref: https://loft.sh/blog/the-cost-of-managed-kubernetes-a-comparison/

本篇文章探討不同 Cloud Provider kubernetes 服務的差異，作者列舉了四個常見的 kubernetes 服務，包含 GKE, EKS, AKS 以及 DOKS。

這四個 kubernetes 服務所部署的 Kubernetes 叢集都有獲得 CNCF Kubernetes Certification 的認證，不同 Cloud Provider 都有自己的優缺點。
使用 Kubernetes 服務帶來的好處就是使用者通常不太需要去擔心如何處理
1. Kubernetes 核心元件之間的 Certificate (API Server, Controller, Scheduler, Kubelet ...etc)
2. 動態調整 Kubernetes 節點
3. 相較於單純靠社群， Cloud Provider 可以提供更快速且更好的支援(畢竟有付錢給對方)

因此該文章接下來就會針對這四個 Kubernetes 服務來探討一下彼此的差異。

註: 有興趣的話都可以用 Sonobuoy 這個開源專案來檢測自己維護的 Kubernetes 叢集，通過測試就可以把測試報告送到 GitHub 開 Issue 申請認證


GKE
1. Kubernetes 正式公開後一個月就 GKE 就出現了 (08/2015), 是最早的 Kubernetes 服務
2. GKE 會使用 gVisor 專注於安全層級的容器隔離技術來部署服務。
3. 有機會使用針對 Container 最佳化的 OS，有些 cloud provider 只能使用 Ubuntu image 之類的。
4. 服務出現問題時，可以啟動 auto-repair 來修復叢集，一種典型作法就是將一直回報為 NotReady 的 k8s 節點給重建
5. GKE 提供自動升級 Kubernetes 版本的功能，如果不想要的話記得要去關閉這個功能，否則自動升級是有可能讓某些應用程式無法正常運作的。
6. 使用 GKE 的話，要付每小時 $0.1 美元的管理費。如果使用 on-prem 的解決方案 (Anthos) 的話就可以免去這些管理費。

EKS
1. 06/2018 創立
2. 可以使用 Ubuntu Image 或是 AWS 針對 EKS 最佳化的 EKS AMI 來獲得更好的效能。
3. EKS 沒有提供自動升級 Kubernetes 版本的功能，官方有提供大量詳細的文件介紹如何手動升級 Kubernetes 版本
4. 沒有類似 auto-repair 的機制去幫忙監控與修復出問題的 k8s node，因此 EKS 使用者需要自己去監控與維護這些節點。
5. EKS 也是每小時 $0.10 的管理費用。 AWS Outposts/EKS Anywhere 這些 2021 啟動的專案讓你有機會將 EKS 部署到 on-prem 的環境中。

AKS
1. 06/2018 創立
2. AKS 沒有提供任何最佳化的 OS，你只能使用常見的那些 OS image 作為你的 k8s 節點
3. 預設情況不會自動升級 kubernetes 版本，不過 AKS 提供選項去開啟自動升級。Cluster 有四種不同策略(none,patch,stable,rapid)來自動更新你的 k8s 叢集。
4. AKS 預設不會啟動 auto-repair 功能。對於一直持續回報 NotReady 的節點， AKS 會先重起該節點，如果問題無法解決就會砍掉重建節點。
5. AKS 不收管理費
6. Azure 沒有特別提供一個供 on-prem 的 AKS 解決方案，不過透過 ARC 是有機會於 on-prem 的環境運行 AKS.

DOKS(DigitalOcean)
1. 05/2019 創立
2. 有提供 kubernetes 版本自動更新功能，但是只有針對 patch 版本的變化
3. 沒有 auto-repair 的功能
4. 文章撰寫的當下， DOKS 沒有任何文件說明如何於 on-prem 的環境運行 DOKS
5. 不收管理費
6. 相對其他三家來說，底層架構相對便宜，一個 DOKS 最低可以低到每個月 $10 美元。

價錢比較:
1. 假設需要創建一個擁有 20 節點並且有 80vCPU, 320GB RAM 的叢集 (GKE 因為每個節點都是 15GB，所以最後只能湊到 300GB)
2. 每個月為單位去計算價格，AKS/EKS/GKE 都使用其提供的價格計算機來粗估， DOKS 需要手動計算。
3. 價錢評比
a. AKS: $3416
b. EKS: $2928
c. DOKS: $2400
d. GKE: $1747

對文章有興趣的別忘了參閱全文

ref: https://cmdchallenge.com/#/last_lines

今天分享的是一個有趣的 Command Line Interface(CLI) 挑戰，該挑戰主要是基於 Linux bash 的環境有一系列的指令挑戰

挑戰內容基本上都不會太困難，一開始都是非常基礎的 Linux 指令操作，後面會需要使用 grep, sed, awk, find 等不同指令的組合來完成任務。
大部分的題目都會基於一些情境，譬如想要針對 httpd server 底下的 log 進行過濾，計算符合某些內容的行數等等

每道題目除了自行挑戰外也可以看一下別人的解決方案，不過解決方案中有一些是作弊的內容，譬如直接針對題目用 echo 輸出之類的，就滿搞笑的。

我認為這類型的挑戰有兩個值得去玩看看的理由
1. 測試自已是否能夠解決每一個問題，順便看一下自己的解決方式跟別人的比起來如何，有時候會有一些意想不到的指令與用法可以讓整個寫法更為簡潔
2. 如果有面試需求的時候，可以考慮從這邊找一些相關題目，看看面試者對於 shell script 的熟悉度，同時互相討論每個解法的好壞處。

歡迎愛寫 shell script 的人都寫一遍看看

ref: https://jzimnowo.medium.com/harbor-keycloak-and-istio-a-good-dance-troupe-6c3520fb87de

本篇是個經驗分享文，作者想要打造一個基於 Kubernetes namespace 的多租戶 Kubernetes 平台。
該平台主要針對的是團隊內不同的 DevOps team，並且每個 Team 都會有自己的下列資源
1. Harbor: Private Container Registry
2. Keycloak: SSO
3. Istio: Service Mesh.

# Harbor
Harbor 是 CNCF 的畢業專案，專注於提供 private container registry，本身除了有友善的操作介面外，也整合了多項常見功能，譬如
1. 基於 OIDC 的授權認證機制
2. 容器安全性掃描
3. Chartmuseum (未來會被移除)
4. 專案管理

透過 OIDC 與專案的機制，能夠很輕鬆的針對不同專案設定不同權限，譬如屬於群組 A 的只能使用 Project A。
此外每個專案本身也有提供 robot account，該 robot account 的目的則是讓整個工作流程更佳簡潔。

如果要於 Kubernetes 中去抓取這些 Private Container Registry，則必須要透過 ImagePullSecret 的物件來描述登入資訊。
為了避免使用個人帳戶來存取，作者推薦每個專案都要準備兩個 Robot Account，這兩個 Robot Account 都只能針對該專案底下的 container 去存取
所以也不用擔心會去存取到其他 Team 的專案。
第一個 robot account 專注於 Pull Image，主要是讓 Kubernetes 內部可以下載 Image 使用。
第二個 robot account 則是給 CI/CD pipeline 使用，讓 pipeline 有能力將新的 image 給推向 Harbor。


前述所說 Harbor 可以基於 OIDC 來滿足認證的機制，作者於團隊中就使用 Keycloak 這個開源來作為一個 OIDC 提供者(另外一個常見的是 Dex)。
文章中有稍微介紹如何於 Keycloak 中創立一個 Client 的物件，並且於 Harbor 如何設定。
如果團隊有這個需求的可以看一下要如何操作。

文章最後探討使用這三個專案的一些經驗與痛點，有興趣的可以閱讀全文參考

ref: https://dlorenc.medium.com/improving-tofu-with-transparency-da674aa2879d


本篇文章要介紹的是一種名為 TOFU 的認證機制，其全名為 Trust-On-First-Use.

要探討這個機制前，作者先列舉一個情境
假設你人要到火車站去找一個名為 Alice 的人交換手提箱，你要如何於火車站正確的找到 Alice?

# Nothing
最基本的情況就是你看到每個人都詢問，你是不是 Alice，但是任何人都可以說謊假裝自己是 Alice，因此惡意攻擊者跟 Alice
一樣都可以輕鬆回答你「我就是 Alice」，顯而易見這種機制基本上沒有辦法幫助我們找到 Alice，也沒有辦法分辨到底眼前的人是惡意攻擊者還是 Alice。

一種改善的機制就是 PKI (Public Key Infrastructure)，該機制的概念是
1. 有一個第三方服務會發行相關的 ID 證件，該 ID 證件難以偽造 (譬如 Certificate Authorities)
2. 你信賴這個第三方服務

所以你到火車站之後，每遇到一個人就要求對方出示其 ID，並且請第三方服務幫忙驗證這個 ID 證件是否合法，透過這種概念來找到到底誰是 Alice。

這種機制運作起來沒有問題，唯一的問題就是找到一個可信任的第三方服務相對複雜且困難。

有沒有一種相對簡單又有點有效的機制? 就是本篇要探討的 TOFU

假設情境改成，今天需要頻繁的到火車站去找 Alice 交換行李箱，這件事情會重複非常多次。這種情境下，我們可以
記住第一次遇到號稱自己是 Alice 的那個人，接下來每次都找該人交易。
簡單來說就是，相信第一次遇到的人，並且記住該人的狀態與面貌，接下來每次交易都直接尋找上次熟悉的面孔。

網路世界來說，一個非常知名使用 TOFU 的軟體就是 SSH。
SSH 使用者第一次連線到遠方 Server 時會相信自己連接到的是正確的 Server，同時將 Server 本身的指紋資訊給存入到本地快取。
因此接下來每次連接到該 SSH 的時候，就直接比較 Server 的指紋是否一致來確定是否連線。
這個機制聽起來很可怕，不過對於這種「很難預測第一次連線的 Server 是誰的狀態」的情境是滿堪用的，畢竟不容易一開始就被偽裝攻擊。

另外一個使用 TOFU 機制的概念就是 supply-chain security，假設你要透過 Packager Manager 來使用不同版本的 Package
這種情境下系統要如何信任每次抓到的 Package 都是正確的?

透過 TOFU 的機制將每個 Package 的 Hash 值都存放 local，這種情況下就可以去比對第二次，第三次下載的內容是否一致。
不過對於 CI 環境下，要一直維持 local cache 實在不容易，因此 Trust-On-First-Use 就會演化成另外一種 Trust-On-Every-Use.

文章後續還介紹 golang 生態系的 go get 是採用何種機制去信任每次下載的 library，對於這篇文章有興趣的不要錯過

一年一度的鐵人賽又開賽了，這次跟又跟幾個好朋友們組了一個奇怪的戰隊，兩個 DevOps 領域加上三個 AI/ML 領域一起努力的於這30天產出共 150 篇技術好文。

這次鐵人賽想要跟大家分享如何使用 Rancher & Rancher Fleet 來嘗試不同方式 GitOps 解決方式。
Rancher Fleet 相對於現有知名的 Flux/ArgoCD 最特別的我想莫過於其客製化應用程式的方式，其不但同時支援 Helm 與 Kustomize 這兩種格式，更可以讓兩者同時運作來達到最大客製化。
試想一下想要針對一些第三方 Helm Chart 進行客製化但是對方 values 又沒有開放時該怎麼辦，這時候就可以透過 kustomize 透過 patch 的方式來動態加入檔案或是修改欄位。

唯一遺憾的是 Rancher v2.6.0 開賽前一天才正式發布，試玩了一下不是說非常穩定，因此這30篇文章還是會基於 v2.5.9 來介紹。

歡迎舊雨新知有興趣的都可以追蹤，相關文章之後也都會發佈到自己的部落格上
https://ithelp.ithome.com.tw/users/20120317/ironman/4034

ref: https://blog.mozilla.org/en/internet-culture/deep-dives/why-are-hyperlinks-blue/
本篇是一個歷史科普文，幫大家介紹為什麼瀏覽網頁內的超連結會是藍色的？
千萬不要想到超連結就覺得一定是 Netscape，從本文的歷史角度來看 Netscape 連前五都不算呢

作者從 2001 年就開始撰寫網頁，一直以來都沒有去思考為什麼超連結是藍色的，直到朋友某天的詢問才讓頓時傻住
這個自己視為理所當然的東西實際上必定也是某個發明，是什麼時候被決定的？誰決定的？為什麼決定是藍色的？

與同事一起找尋的結果是 Marc Andreessen and Eric Bina 於 01/23/1993
所發佈的 Mosaic(馬賽克) 瀏覽器是第一套提供藍色超連結功能的瀏覽器。

時間點來看的話
1. 1964 Project Xanadu 是第一個嘗試透過實體連結將兩個頁面的系統
2. 1987 第一套瀏覽器 WWW 誕生
3. 1993 第一個使用基於藍色的超連結瀏覽器出現
4. 2016 Google 開始嘗試將超連結顏色改到黑色

研究出這些歷史痕跡後，作者依然對於為什麼是藍色這件事情沒有著落
很多人都說因為對比色的緣故，所以超連結選則藍色。
作者認為 W3C 直到 1994 才出現，所以那之前所謂的標準都還沒有被定義，此外從對比的角度來看，藍色與黑色的對比程度是2.3:1，實際上也不是說多好。

作者後面從不同角度去思考出一個結論
1. Cello/Mosaic 假設它們的設計都受到該年代 UI 設計潮流的影響
2. 該年代是 Windows 3.1 崛起的日子，而 Windows 3.1 也是第一個重度使用藍色作為選擇色的系統（網頁中有展示 windows 3.1 中很多選擇都會呈現藍色)
3. 隨者支援色彩的電腦螢幕普及，Mosaic 也一起受歡迎，使用藍色的超連結逐漸變成一個習慣，因此此後的 IE/Netscape 等也就沿用這個藍色的設計。

對於歷史考古文有興趣的可以詳細閱讀全文