Kubernetes is Cloud OS, Containers are Linux
既前篇文章 永續性軟體工程: 遠端抓封包實錄 有提到降低不必要網路傳輸成本可有效減少碳排放，那我繼續基於 Green Foundation 所提出的綠色軟體實踐者 (Green Software Practitioner) 當中的原則提升設備利用率 (Increasing device utilization) 來繼續延伸這個大議題
盡力地提升單台節點所能服務的量體，減少資源浪費，從這個角度看，其實就是需要來探討 Azure Kuberenetes Service 預設提供的這些節點，本體到底夠不夠提供我們在大流量和高性能計算上所需的資源和調教，這邊就從經典的百萬並行連線 C1000K (Concurrent 1000K Connections) 來做為基準來探討
Wireshark: Packet Don't Lie.
文章 永續性軟體工程: 遠端抓封包實錄 提到如何遠端抓單體 VM 封包，那同樣的招數可不可以去抓 Azure Kubernetes Service 特定 Pod 裡面的封包? 答案是可以，搭配 ksniff 來做就好
最近因為 10/24 要辦 CNCF Sustainability Week - Taiwan x Green Software Foundation 活動，看了一堆 ESG 相關的治理文章和技術書，因為剛好有些客戶是做跨國生意的，遲早會碰到和被問到這個議題，所以就從比較常接觸網路著手看了一下實務上怎麼做，節能減碳先從少收封包開始
這篇只有 Red Hat OpenShift 為主的使用者不用看，那個早在 v3.6 好幾年前就弄了一個 oc debug 出來了，但你若是一般 Kubernetes 發行版的，例如 Tanzu Kubernetes Grid 或 Azure Kubernetes Service 等，則可以參考一下此篇作法。主要是會用到 Ephemeral Containers 和 kubectl debug 這兩個主要能力，而目前都是在 Kubernetes v1.25 標註 Stable 穩定狀態
來問問大家一個問題，以 Container Base Images 來說，以 Deb 體系來看，你覺得 Debian 比較安全還是 Ubuntu 比較安全?
最近看到一個很有趣的網站 kube-score，你把你的 Kubernetes Deployment 丟進去之後，它就會各種無情地跟你說哪裡不好。當中裡面有提到針對 Kubernetes Probe 相關的建議，剛好最近案子有需要特別精算時間，故特別寫了篇文章供大家參考。順便附上一張，從 Bing Creator 提供的 DALL.E 模型所理解到的 Kubernetes livenessProbe、readinessProbe 以及 startupProbe 視覺化的樣子，很像...左納烏能源結晶
前陣子剛好 Kubecon EU 2023 剛辦完，相關的影片也釋出到 YouTube - KubeCon + CloudNativeCon Europe 2023 上，共計 314 部，在當災厄林克破壞海拉魯大陸的同時，記得也要不忘持續學習
最近這幾周收到幾個想要做 SLA 99.999% 的案子，因涉及的服務眾多，所以故針對如何合理計算 SLA 和其架構設計先做一個紀錄，但這邊並不涉及資料最終一致性和對外網路的設計討論
衡量你想要監控的內容意義，不要只監控您碰巧能夠輕鬆監控的內容
Service Level Objectives (SLO) 可以讓你清楚的理解現在系統運作的狀況，但它背後的數字代表意義是需要透過一連串的數字統計和計算而得的。而最近無論是設計跨國網路，雲地混合網路，都會遇到一個關鍵元素: Latency 延遲，對於資料傳輸來說，延遲是一個很重要的指標，因此我們需要一個方法來定義這個指標，這篇文章就是要來介紹如何定義 Network Latency SLOs
因 OpenAI 相關技術發展神速，本文有效時間可能不算太長，閱讀後務必要自行再用自身經驗驗證
很久沒寫 Python，但我本來只是想要研究一下 APM (Application Performance Monitoring) 怎麼順利地跑在 AKS 和 ARO 上，然後就不小心就把 Line Bot ft. OpenAI 寫一寫了，既然寫了就順便紀錄一下
起源是因為做 Azure 網路架構設計，網路線拉完 (ExpressRoute、S2S VPN、VNet Peering 等) 之後，下一個需求多半都是要把 Firewall 開起來，希望所有的連線都要經過 Azure Firewall 確保連線安全性，但基於 Azure Networking 本身的特性和使用者的對於網路連通 (Network Connectivity) 的需求，身為一名記憶力不算特好的架構師，為了確保使用者講的跟實際上運作的結果是一樣的，這時候就要把早年在 Edgecore Network 時期講過的 NetDevOps: Next-Generation Network Engineer 拿來用用了
很多朋友講到 Infrastructure as Code (IaC) 的時候多半都會直接落在單一工具選擇的討論，想要窮舉出最終選擇，但隨著時間久了我覺得這個議題應該要以共生共榮的角度看待比較好
早期的時候都是 Shell Script 當道居多，直至 2012 年左右 Ansible (2015 年被 Red Hat 收購)、Puppet (2022 年被 Perforce 收購)、Chef (2020 年被 Progress 收購)、Saltstack (2020 年被 VMware 收購) 等 4 大多數以作業系統管理為主的組態管理 (Configuration Management) 興盛，到各大雲廠商迅速崛起出現 Hashicorp Terraform (2021 年 IPO) 這類以雲平台 (Cloud Provider) 為 IaC 核心的工具，具體來講，被管理的平台不同，選擇的方向會有點不一樣，下面會有一些我個人的經驗分享
從 2018 起，OpenAI 所採用的 Kubernetes 節點數量於 3 年內成長 300%
或許有些讀者知道小弟以前是專搞地端 Infra 服務的架構師，興趣就是專門看 Networking 和他相關連的服務，最近來到雲端之後，只能說雖然看起來都是一台 VM 連線出去到 Internet，但實際上眉角還蠻多的...倒是如果你是地端網路工程師的話，剛接觸 Azure 網路的話，蠻推薦基礎先從 AZ-700 Designing and Implementing Microsoft Azure Networking Solutions 開始著手，保證你可以研究很久
另外要特別感恩國外的大神 Toni Pasanen 寫了一堆文章讓我更清楚瞭解 Azure Networking 架構 Toni Pasanen - Azure Networking Fundamentals: Internet Access with VM-Specific Public IP 一圖解釋 Azure VM 對外網路連線方式，強烈推薦給大家
此文是寫給廣大的 IT Infra 背景群眾看的，主要是提供落地架構設計參考，若你是想要知道 OpenAI 怎麼用的，此文並無涉及，可以參考官方文件 Azure OpenAI is now generally available
2022/11 最驚嚇到我的事情就是 ChatGPT 這服務的誕生，簡直看到 科技奇異點 ，然後沒想到這服務的母公司 OpenAI 居然是 Microsoft 投資的，我只能說真的是可喜可賀和感到哀傷。
可喜可賀是我可以在很近的距離看到這技術將要創造的歷史，感到哀傷是 ChatGPT 樹立了一個相當驚人的技術屏障，都不知道以後新進或菜鳥工程師到底要怎麼跟這個競爭，但幸好若問他做特別需要專業性問答的事情，這服務目前有可能會回答錯誤或亂答，譬如說問它網路除錯或設計問題後，看起來我還不會失業 :>
下圖是標準工程師使用範例，本人對於 HTML 和 CSS 毫無理解，也不知道從何改，然後我就去問 ChatGPT 後，就改好了...
最近打工打到雲端來了，目前順利活過了 6 個月，我只能說根本天天看網路架構議題，如果你是純雲端直接使用的，完全不需要跟地端網路接再一起的，你是不會有我這種煩惱，但如果你跟我一樣看混合網路架構 (備註:是地端+雲端，不是雲端+雲端) 的話，估計你應該跟我一樣都在滑鼠點點，開服務，對流量
分享一下當初開始看 Azure Networking 的第一篇文章就是出至於 Telstra Purple - Hub and Spoke network topology in Azure，到現在為止，若是要用 Azure 做跨國網路架構參考性還是非常高的
