矽谷牛的耕田筆記

標題: 「ssh-tunnel 詳細教學」 類別: tools 連結: https://iximiuz.com/en/posts/ssh-tunnels/ ssh 對許多人來說並不陌生，但是對於一些稍微繁雜的環境很多時候就會使用 ssh tunnel 來進行一些反向代理或是不同的處理，複雜的可能還會搭配 .ssh/config 來簡化多節點的跳躍與存取。 此外也有部分人會使用如 sshuttle 之類的工具來簡化操作讓一切更為簡單 而本篇文章則是專注於 ssh tunnel 的介紹，其介紹非常詳細，從指令的用法到圖解整個運作與流程都包含，對於 ssh tunnel 不熟或是想要複習的讀者非常推薦閱讀這一篇文章，能夠幫助你重新理解 ssh tunnel 的流程與用法

標題: 「CNCF 2022 專案回顧」 類別: Networking 連結: https://medium.com/dev-genius/cncf-2022-graduated-projects-year-end-review-part-one-95d27c77983c 2022 依然是 Cloud Native 生態系蓬勃發展的一年，以 CNCF 所託管的 157 個專案中，就有超過來自 189 個國家共 178,000 的貢獻者。 同時，直到 2023 年底，CNCF 中共有 20 個畢業專案，畢業的意思就是該專案已經足夠穩定，有來自不同地方的貢獻者共同維護該專案生態系同時該專案也被證明能夠於正式部署環境使用的。 作者特別整理這些畢業的專案，本篇文章只是上篇，因此只有收錄十個畢業專案 對於使用者來說，選擇畢業專案除了技術上的考量，有時候也是一個政治上的考量，基於 CNCF 的畢業標準作為背書來表示為什麼要使用此專案相對於其他的專案會更有說服力，畢竟使用開源專案除了功能面之外，生態系的活躍也是後續維護與找尋臭蟲的一個重要關鍵點。 目前畢業的 20 個專案分別有 1 ArgoCD 2 Containerd 3 CoreDNS 4 Envoy 5 etcd 6 fluentd 7 flux 8 Harbor 9 Helm 10 Jaeger 11 Kubernetes 12 Linked 13 Open Policy Agent 14 Prometheus 15 Rook 16 Spiffe 17 Spire 18 TUF 19 TiKV 20 Vitess 因此本篇專案就是針對前 10 個進行簡單介紹，從分類來說大抵上可以看成 GitOps -> Argo/Flux Observability -> Fluentd, Jaeger Container Related -> Containerd, Harbor Networking -> Envoy, CoreDNS DB -> etcd K8s Application Management -> Helm

標題: 「網路技術文，探討 Kubenet, Azure CNI 與 Azure CNI(Overlay) 的差異」 類別: Networking 連結: https://medium.com/@inder-devops/aks-networking-deep-dive-kubenet-vs-azure-cni-vs-azure-cni-overlay-a51709171ce9 作為一個 AKS (Azure Kubernetes Service) 的使用者，創建時可能都會觀察到有所謂的 network model 可以選擇，而這個 network model 實際上就是對應到 Kubernetes CNI 的範疇，預設情況下是採用 kubenet 這套解決方案來處理 CNI 的需求。 本篇文章首先先以簡單的概念描述 Azure 的網路概念，與多數的 Cloud Provider 一樣，基本上都會有所謂的 VPC + Subnet 的概念，同時因應 (Kubernetes Service) 都可能配置的 NodePool 來探討一下這些 IP 的基本關係。 接者從 Kubernetes 出發，探討所謂的 PodCIDR, ServiceCIDR 這些實際上跟 Kubernetes 有直接相關的 IP 分配與使用 有了上述的基本概念後再來看接下來的 Kubenet/Azure CNI 的比較才會有更深的體悟實際上的差異是什麼 以下簡單記錄一下每個 CNI 的特性 Kubenet 1 Nodes 會從 Azure virtual network subnet 獲取 IP 2 Pod 會獲得一個全新的虛擬網段，該網段由 kubenet 維護 3 Pod 如果要對外存取服務，需要透過 SNAT 來進行轉換，且轉換後的 source IP都是 Node IP Azure CNI 1 Node 會從 Azure virtual network subnet 獲取 IP 2 Pod 與 Node 一樣，會從一樣的 Azure virtual network subnet 獲取 IP 1 為了實作此功能，每個節點除了主要 IP 外，還會掛載更多網卡來處理 Node 上 Pod 的IP與相關存取 3 Cluster 上 Pod 的數量規模會取決於當前 Azure virtual network subnet 分配的網段大小，太小則沒有辦法分配適當的 IP 給 Pod Azure CNI Overlay 1 運作模式類似於 Kubenet， Pod 都會用新創的虛擬 IP 2 效能相對於 Kubenet 更好 從功能面來看 Azure CNI 與 AWS CNI 類似，都是以 VPC 的角度打出一個大一統的網路平面來給所有的 k8s node, k8s pod 去使用，好處就是 IP 攤平的情況下減少溝通成本同時也能夠透過既有的 network firewall 等進行處理與觀察，但是壞處就是 IP 分配數量直接影響 Pod 的數量，這變成架構設計時就要先想好到底要如何分配 詳細比較圖文可參考內文