由於 Kubernetes 的導入，目前公司內的 Windows Container 已所剩無幾，並且 Docker Desktop 現有授權的關係，在公司使用 Docker Desktop 是需要每年採購授權的。因此想要嘗試改用 Podman，在轉換至 podman 過程有二件事：
docker CLI，要改成 podman CLI
一開始的前幾章，Uncle Bob 火力展示 TDD 的實戰應用，從無到有，手把手教你起手式，透過自然而然的推論，最終完成一個又一個的「演算法」。重點是他提供的影片。我觀看第一則展示 Stack 的影片時就被嚇到了。
我們將地端 VM 進行作業系統（OS）升級，由 Windows Server 2016 升級至 Windows Server 2022，升級之後發現，Azure Arc 裡的 MDE.Windows Extensions 有點不太正常。
備註，MDE.Windows Extension 只支援 Windows Server 2019 之後的作業系統。例如，Windows Server 2016 那麼是不會被安裝此 Extension。
就在我們完成 ExpressRoute 加入 Windows / Linux VM 的問題後，我們開始大量部屬 Azure Monitor Agent（AMA），但二天後收到 DBA 的通知，說我們安裝 Azure Monitor Agent（AMA）之後，不斷有程式在嘗式新增 SQLArcExtensionServerRole 角色進資料庫。
前篇（07）（08）提到，不論在 Windows 或 Linux 之下，我們最終都會碰到 AZCM0026: Network Error 錯誤，從錯誤訊息及測試得知 agentserviceapi.guestconfiguration.azure.com 這個端點無法正常連線。
PS C:\> & "$env:ProgramW6432\AzureConnectedMachineAgent\azcmagent.exe" connect --service-principal-id "$ServicePrincipalId" --service-principal-secret "$ServicePrincipalClientSecret" --resource-group "$env:RESOURCE_GROUP" --tenant-id "$env:TENANT_ID" --location "$env:LOCATION" --subscription-id "$env:SUBSCRIPTION_ID" --cloud "$env:CLOUD" --correlation-id "$env:CORRELATION_ID";
INFO Connecting machine to Azure... This might take a few minutes.
INFO Testing connectivity to endpoints that are needed to connect to Azure... This might take a few minutes.
INFO Exit Code: AZCM0026: Network Error
INFO For troubleshooting, see https://aka.ms/arc/azcmerror
FATAL required endpoints unavailable: https://agentserviceapi.guestconfiguration.azure.com
接續 ExpressRoute with Microsoft Peering with Windows第一次 PoC 成功之後，這裡要繼續研究如何在 Azure ExpressRoute + Microsoft Peering 環境將 Linux VM 加入 Azure Arc 管理清單。一樣分析官方提供的 Shell 指令碼，發現麻煩的一件事，以我們 Linux 環境來說明。我們採用 Ubuntu 22.04，因此 Shell 指令碼協助設定 APT 的下載點，然後，透過 APT 來進行安裝 azcmagent 套件。
我們公司是混合雲架構，採用 Azure ExpressRoute 來進行「地與雲之間安全的連線」，這在此 Blog 提到多次。
從圖來看，Azure ExpressRoute 本身還有兩種選擇，採用 Microsoft Peering 與 Private Peering，差異細節不是這裡的重點，就先跳過。簡單以安全性來說，Microsoft Peering 安全性高於 Private Peering，因此我們選擇 Microsoft Peering 線路架構來實踐。你可以把 Microsoft Peering 想成一個完全黑箱，中間的線路沒有第三者碰得到，而且能存取內容也僅是微軟官方的雲服務（Microsoft 365、Azure Public Service等），A 存取 B 服務，僅此而已，沒了。
前面，我們花了很多功夫進行各類型的 Azure Arc 整合的 PoC。但進入到企業實際內部發現，原本來 PoC 無法實行。以「如何在Azure Arc加入多台地端VM伺服器」為例，它為 Windows 提供的 PowerShell ，我們在跑安裝指令碼的過程是會去下載外部資源。
前面我們利用 Kind 及 MicroK8s 來架設 Kubernetes 叢集，以驗證地端 Kubernetes 叢集與 Azure Arc 的整合，過程也還算順利。接下來，我在同一台 Surface Pro 主機上採用 Hyper-V 並利用Kubeadm 架設的 Kubernetes 叢集來進行再次驗證。當然，有這一篇的出現，代表過程有問題的出現。
$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
lnode Ready control-plane 111d v1.26.5 192.168.8.150 <none> Ubuntu 22.04.2 LTS 5.15.0-88-generic containerd://1.6.21
lnode2 Ready <none> 2d5h v1.26.11 192.168.8.153 <none> Ubuntu 22.04.3 LTS 5.15.0-88-generic containerd://1.6.24
原生 Kubernetes 的設定步驟均和 MicroK8s 一樣。不過進行到 az connectedk8s connect 步驟時，我得到不一樣的結果：
首先當然是要準備好 MicroK8s 叢集。
$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
wk8s Ready <none> 14h v1.28.3 192.168.8.184 <none> Ubuntu 22.04.3 LTS 5.15.0-89-generic containerd://1.6.15
mk8s Ready <none> 14h v1.28.3 192.168.8.182 <none> Ubuntu 22.04.3 LTS 5.15.0-89-generic containerd://1.6.15
想要學習如何將地端 Kubernets 叢集加入 Azure Arc，並且利用 Azure Monitor 來監控地端 Kubernets 叢集。架設地端 Kubernets 叢集對我來說已經沒什麼難度了。但對於入門介紹，總不能說，我們要先架個三台地端 Kubernets 叢集，才能開始進入主題吧。借此機會，跟大家介紹一下 Kind 這套架設與測試 Kubernets 叢集的利器。
有了前面把地端 VM 加入 Azure Arc 及地端 VM 安裝 Azure Monitor Agetn 的經驗，接下來我們要挑戰把地端的 SQL Server 也加入到 Azure Arc 清單中。
實作環境：
前篇，我們先把地端安裝 Azure Monitor Agent 的前置環境給準備好。接下來我們要安裝 Azure Monitor Agent。
我們使用 Azure Log Analytics agent（Microsoft Monitoring Agent (MMA)） 來收集監控地端 VM 多年，但從 2023 年初開始，不斷看到 Azure 文件或系統上提示 MMA 在2024年8月31日將不再受到支援。近來地端有申請新的 VM，因此規劃新的 VM 改用Manage Azure Monitor Agent，並且熟悉了解整個設定及升級流程。
我們映像檔（images）是儲存在ACR（Azure Registry Container），在ACR有提供 Microsoft Defender 能提供我們映像檔（images）的安全性報告。
同事回報，進行 Kubernetes CD 部署時出現錯誤：
couldn't get current server API group list: the server has asked for the client to provide credentials
unable to recognize "...API.yaml": the server has asked for the client to provide credentials
在一個標準 3 台 Node （1 Control Plane + 2 Worker Node）的 Kubernetes 叢集上，在進行維護（drain）之後很容易出現 Pods 集中在某一台 Worker Node 的情況。這在測試區還好，測試區更新極快，通常沒幾天就能回到平衡（Balance）的狀態。正式區就比較麻煩，正式區更新速度不比測試區，因此，Pods 集中在某一台 Worker Node 情況容易時間不短，這會造成特定 Worker Node 資源吃重的情況。針對維護過後，Pods 會集中在某一台 Worker 上，我想改進這一點。
之前在架設 Kubernetes 叢集預設把防火牆給關閉。當然，關閉防火牆是非常不安全的行為。 當所有 Kubernetes 和 Calico 組態與服務都上線之後，我們需要把防火牆設定回去。
這裡只針對兩個部分：Kubernetes 與 Calico 所以需要埠（Port）。
我們參考 Calico upgrade docs (uses the operator) 升級了 Calico CNI 元件從 3.27.x 到 3.28.1。
$ calicoctl version
Client Version: v3.28.1
Git commit: 601856343
Cluster Version: v3.28.1
Cluster Type: typha,kdd,k8s,operator,bgp,kubeadm,win
升級後發現，原本的 default-ipv4-ippool 被設定回來了。在 3.27.x，因為一開始沒考慮好網段問題，因此我們設定了一組新的 IPPool 來提供給 Pods 使用，來解決一些 IP 網路的問題。在 3.27 依照 migrate-pools 文件，我們為 default-ipv4-ippool 設定了 disabled: true 並且運作良好。但升級至 3.28.1 後，除了 default-ipv4-ippool 被設定回來並且被啟用了。我們還發現，原始按照文件可以設定 disabled: true 無法被正確套用，刪除指令就算執行成功，其實也是無效的。
$ calicoctl get ippool -o wide
NAME CIDR NAT IPIPMODE VXLANMODE DISABLED DISABLEBGPEXPORT SELECTOR
default-ipv4-ippool 192.168.0.0/16 true Never CrossSubnet false false all()
new-pool 10.244.0.0/16 true Never CrossSubnet false false all()
$ calicoctl get ippool -o yaml > pools.yaml
# add disabled: true
$ vim pools.yaml
$ calicoctl apply -f pools.yaml
Successfully applied 2 'IPPool' resource(s)
# DISABLED : false
$ calicoctl get ippool -o wide
NAME CIDR NAT IPIPMODE VXLANMODE DISABLED DISABLEBGPEXPORT SELECTOR
default-ipv4-ippool 192.168.0.0/16 true Never CrossSubnet false false all()
new-pool 10.244.0.0/16 true Never CrossSubnet false false all()
# delete default-ipv4-ippool
$ calicoctl delete pool default-ipv4-ippool
Successfully deleted 1 'IPPool' resource(s)
$ calicoctl get ippool -o wide
NAME CIDR NAT IPIPMODE VXLANMODE DISABLED DISABLEBGPEXPORT SELECTOR
default-ipv4-ippool 192.168.0.0/16 true Never CrossSubnet false false all()
new-pool 10.x.0.0/16 true Never CrossSubnet false false all()
# use patch method
$ calicoctl patch ippool default-ipv4-ippool -p '{"spec": {"disabled": true}}'
$ calicoctl get ippool -o wide
NAME CIDR NAT IPIPMODE VXLANMODE DISABLED DISABLEBGPEXPORT SELECTOR
default-ipv4-ippool 192.168.0.0/16 true Never CrossSubnet false false all()
new-pool 10.x.0.0/16 true Never CrossSubnet false false all()
時間先讓我回到2017年前後，那段時間有幾件技術正在發酵、發芽、成長。
2023年12月，正忙於年末最後一場iThome - Kubernetes Summit 2023的演講，心想，忙完這一場終於可以好好休息一下。但事情永遠不是傻子所想的那麼簡單。突然，信箱進來一封編輯邀約的信件，正想說，如果是翻譯工作，就再幫忙找其他新鮮的肝（新譯者），結果是翻譯也不是翻譯。出版社嘗試用了ChatGPT進行初譯，然後由專業編輯與譯者進行修潤與審校，想嘗試這樣的合作模式。快速瀏覽了主題與內容，我非常有興趣，立即回信說，我想接下這份工作。
最近讀 infoQ 翻譯的一篇Kubernetes 开源 9 年，但我们已经有了 8 年的踩坑血泪史（原文：Lessons From Our 8 Years Of Kubernetes In Production — Two Major Cluster Crashes, Ditching Self-Managed, Cutting Cluster Costs, Tooling, And More），看得心驚膽跳，其中 Kubernetes 憑證沒換把 Kubernetes 叢集搞掛這件事，我已經不只一次在文章裡看到。一般的教學文件會教你如何架 Kubernetes 叢集，教你 Pod、Service、Deployment、Network等等物件的基礎，但很少好好跟你談談憑證這件事。但如果你跟我一樣走自架 Kubernetes 叢集的路，這件事就無比重要，它關係到你的 Kubernetes 叢集的持續運作。這篇我們來解一下 Kubernetes 叢集憑證。
在容器主機(Container Host)中，還蠻有機會碰到 Disk 容量不足的情況。通常會先請 Infra 同事做擴充，因為我們習慣用 Server Core，因此需要用指令來去進行擴充磁碟區的動作。
一般，大多會找到或教你用 diskpart 來進行操作。雖然有大量範例可查，但 diskpark 有點繁瑣，而且用了多次，也沒記起來過，每次都要重找，而要小心的下 diskpark 指令。
想說，官方 PowerShell 不知道有無支援那麼底層操作指令。查了一下，還真得有。
# Variable specifies the disk drive to extend
$drive_letter = "D"
# Script gets the partition sizes, and resizes the volume
$size = (Get-PartitionSupportedSize -DriveLetter $drive_letter)
Resize-Partition -DriveLetter $drive_letter -Size $size.SizeMax
去除第一行參數指令不算的話，兩個指令就能完成擴充磁碟區。簡單，好用，不管什麼 PowerShell，都給我來一份。