Kubernetes

TL;DR 馬上就看到有小王八蛋想壞壞 前言 2025 年 11 月，Kubernetes SIG Network 發布了一篇公告：ingress-nginx 將正式退役。 這個消息讓不少人震驚，但嚴格來說有個細節需要釐清。目前市場上有兩個長得很像的 nginx ingress controller： kubernetes/ingress-nginx：由 Kubernetes SIG Network 維護，這次宣布 EOL 的就是它。 nginx/kubernetes-ingress（又稱 NKS）：由 F5 / NGINX Inc. 維護，目前仍持續開發中。 我的 homelab k3s cluster 一直以來用的是 F5 維護的版本，嚴格來說不在這次 EOL 的範圍內。但這個公告還是給了我一個動力，與其繼續追蹤兩個版本之間的差異、擔心哪天又有什麼變化，不如趁這個機會把遷移一次做完。 遷移目標選定 Traefik v3，原因有兩個： k3s 內建 Traefik 作為預設 Ingress Controller，1.32 版本後升級為 Traefik v3，搭配 HelmChartConfig 管理，和 cluster 的整合度最高。 順手引入 CrowdSec 主動防護——長期以來我的服務靠著 Cloudflare proxy 當唯一守門人，但我一直想要在 Ingress 層就能即時判斷並封鎖攻擊者 IP，而不只是依賴前端的 CDN 過濾。 為什麼不選 Cilium Gateway API 在決定遷移到 Traefik 之前，我也閱讀了 Gene 的告別 ingress-nginx：Cilium Gateway API 遷移筆記，評估過 Cilium Gateway API 方案。Cilium 在 CNI 層整合了 Gateway API，理論上能提供更底層、效能更好的流量控制，且完全符合 Kubernetes Gateway API 的標準規範。 ...

前言 在 Kubernetes 的世界裡，Helm 無疑是管理應用程式部署的霸主。它標準化了資源的定義，讓我們可以用宣告式的方式管理整套系統。然而，在真實世界的維運場景中，事情往往沒那麼單純。 我們常遇到一種尷尬的情況：某些資源（例如 Database 的 Secret、外部系統的 ConfigMap）可能在 Helm Chart 安裝之前就已經由維運人員手動建立，或是由另一個流程（如 Terraform）預先準備好了。 這時候，如果直接執行 helm install，往往會收到 “resource already exists” 的錯誤；如果使用 helm upgrade --install，又擔心 Helm 會覆蓋掉這些既有設定。 這篇文章將分享一種「Smart Resource」的設計模式，透過 Helm 的 lookup 函數與樣板邏輯，讓你的 Chart 能夠聰明地判斷：「這東西是我管的嗎？如果是，我才動它；如果不是，我就尊重現狀。」 核心難題：Ownership 在 Kubernetes 中，資源的「所有權」觀念至關重要。Helm 預設認為它 release 中的所有資源都應該由它全權管理。但當我們需要與外部資源協作時，我們需要更細緻的控制。 我們的目標很明確： 若資源不存在：建立它，並標記為 Helm 管理。 若資源已存在且由 Helm 管理：更新它（Patch/Merge）。 若資源已存在但由外部管理：保持原狀，不進行覆蓋或刪除。 為了達成這個目標，我們需要一個輔助函數來判斷資源的歸屬權。 實作細節 1. 定義所有權檢查 首先，我們在 _helpers.tpl 中定義一個檢查函數。Helm 會在它建立的資源上打上特定的 Annotations（meta.helm.sh/release-name 和 meta.helm.sh/release-namespace）。我們可以利用這一點來判斷資源是否屬於當前的 Release。 {{/* Check if a resource is owned by this Helm release Returns "true" or "false" as string for stable piping */}} {{- define "visionone-filesecurity.isOwnedByRelease" -}} {{- $resource := .resource -}} {{- $releaseName := .releaseName -}} {{- $releaseNamespace := .releaseNamespace -}} {{- $owned := and $resource (hasKey $resource.metadata "annotations") (eq (get $resource.metadata.annotations "meta.helm.sh/release-name") $releaseName) (eq (get $resource.metadata.annotations "meta.helm.sh/release-namespace") $releaseNamespace) -}} {{ printf "%t" $owned }} {{- end -}} 這段程式碼邏輯很簡單：只有當資源存在，且其 Annotations 中的 Release Name 與 Namespace 都與當前 Release 相符時，才視為「Owned」。 ...

前言 身為一個開發者，特別是在 macOS 環境下，Docker Desktop 幾乎是容器化開發的標配。然而，自從 Docker Desktop 開始針對大型企業調整其授權模式後，許多開發者開始尋找替代方案。 市面上確實出現了一些選擇，例如閉源但功能強大的 OrbStack。但對於熱愛開源的我來說，目光自然投向了社群。這時，colima 這個開源專案進入了我的視野。它不僅提供了一個在 macOS 上運行 Linux 容器的輕量級方式，還內建了 Kubernetes 支援，引起了我極大的興趣。 這篇文章，想記錄一下我從 Docker Desktop 轉換到 colima，並且在 colima 的 Kubernetes 環境中，從原本依賴 Docker Engine 逐步遷移到使用 containerd 作為容器執行時（Container Runtime）的心路歷程與踩坑經驗。 lima 與 colima 簡介 在深入 colima 之前，得先提一下 lima (Linux virtual machines on macOS)。lima 是一個旨在於 macOS 上輕鬆運行 Linux 虛擬機的開源專案。它底層利用了 macOS 的虛擬化框架（如 QEMU 或更高效的 vz），提供了一個相對輕量的 Linux VM 環境。 而 colima 則可以看作是建立在 lima 之上的「使用者友善層」。它簡化了 lima 的配置，並專注於提供容器執行時環境。colima 可以讓你輕鬆地啟動一個配置好 Docker 或 containerd 的 Linux VM，並且可以選擇性地啟用 Kubernetes (K3s) 支援。簡單來說，colima 幫你處理了建立 VM、安裝 Runtime 等繁瑣步驟，讓你專注在容器本身。 ...

由於 zpool 吃超過 80%，故將其中一個 VM(k8s-worker) 的硬碟縮小(200GB=>100GB) pve: 7.2.7 zfs: zfs-2.1.5-pve1 zfs-kmod-2.1.5-pve1 確認 vm disk 剩餘空間 $ df -h Filesystem Size Used Avail Use% Mounted on /dev/vda1 197G 14G 178G 7% / vm 關機 下載 gparded iso 到 pve vm 從 gparded iso 開機並縮減 disk 大小 pve server 針對 vm 的 hard disk 調整占用大小 switch(allocate storage type) case LV: lvreduce -L 5G /dev/pve/disk-name (縮小到只剩 5G) or lvreduce -L -5G /dev/pve/disk-name (縮小 5G) case qcow2: qemu-img resize --shrink <vmfile.qcow2> [+-] or size case ZFS: zfs set volsize=<new size>G rpool/vm-<vm id>-disk-<disk number> 舉例: vm(205) 的虛擬硬碟(vm-205-disk-0)放在 zpool land 上面，已經將 vm 縮小至 100GB ❯ zfs list NAME USED AVAIL REFER MOUNTPOINT land/vm-205-disk-0 236G 354G 119.3G - ❯ zfs set volsize=100G land/vm-205-disk-0 ❯ zfs list NAME USED AVAIL REFER MOUNTPOINT land/vm-205-disk-0 136G 354G 19.3G - ``` 在網頁 GUI 中修改強制刷新 disk。修改 disk 的設定，再調整回來 ...

前言 鑒於最近接到 1 CentOS master + 2 Gentoo node k8s cluster 建置雜事，被自己不熟系統雷到，做個筆記紀錄一下，未來敲敲指令就可以了 .. root@master .PLTJ. ----------- <><><><> OS: CentOS Linux 7 (Core) x86_64 KKSSV' 4KKK LJ KKKL.'VSSKK Host: KVM/QEMU (Standard PC (i440FX + PIIX, 1996) pc-i440fx-6.1) KKV' 4KKKKK LJ KKKKAL 'VKK Kernel: 5.4.180-1.el7.elrepo.x86_64 V' ' 'VKKKK LJ KKKKV' ' 'V Uptime: 2 mins .4MA.' 'VKK LJ KKV' '.4Mb. Packages: 359 (rpm) . KKKKKA.' 'V LJ V' '.4KKKKK . Shell: bash 4.2.46 .4D KKKKKKKA.'' LJ ''.4KKKKKKK FA. Terminal: /dev/pts/0 <QDD ++++++++++++ ++++++++++++ GFD> CPU: Common KVM processor (4) @ 3.493GHz 'VD KKKKKKKK'.. LJ ..'KKKKKKKK FV Memory: 97MiB / 16015MiB ' VKKKKK'. .4 LJ K. .'KKKKKV ' 'VK'. .4KK LJ KKA. .'KV' A. . .4KKKK LJ KKKKA. . .4 KKA. 'KKKKK LJ KKKKK' .4KK KKSSA. VKKK LJ KKKV .4SSKK <><><><> 'MKKM' '' 此篇 CentOS 寄宿於 PVE 下，kernel 已升級為 5.4.180-1.el7.elrepo.x86_64 使用 containerd 作為 cri 使用 calico 作為 cni，並使用 host 唯一的網卡，不做其他進階設定。 ...

這幾天把便宜撿到的 Threadripper 2950X 平台也上 Proxmox VE 玩玩了，裝完系統後才發現自己太習慣於 windows 下的電源管理，一直都沒發現 linux 下 CPU 頻率都是拉滿的狀態，找了debian 下進行電源管理的電源計畫設定教學達到降溫省電，順便做做紀錄。 此篇文章的硬體基於 root@raiven:~# neofetch _,met$$$$$gg. root@raiven ,g$$$$$$$$$$$$$$$P. ----------- ,g$$P" """Y$$.". OS: Debian GNU/Linux 10 (buster) x86_64 ,$$P' `$$$. Host: HP Z2 SFF G4 Workstation ',$$P ,ggs. `$$b: Kernel: 5.4.106-1-pve `d$$' ,$P"' . $$$ Uptime: 276 days, 9 hours, 51 mins $$P d$' , $$P Packages: 719 (dpkg) $$: $$. - ,d$$' Shell: bash 5.0.3 $$; Y$b._ _,d$P' Terminal: /dev/pts/1 Y$$. `.`"Y$$$$P"' CPU: Intel Xeon E-2278G (16) @ 5.000GHz `$$b "-.__ GPU: Intel Device 3e9a `Y$$ Memory: 48763MiB / 64099MiB `Y$$. `$$b. `Y$$b. `"Y$b._ `""" root@raiven:~# ^C 用 watch -n 1 "cat /proc/cpuinfo | grep MHz" 可以查看當下的 cpu 頻率狀態。 ...

環境 物理機: 2278G/16G DDR4 ECC*4/1T MX500 OS: - master: Ubuntu server 20.04 - node: Ubuntu server 20.04 安裝 docker、kubeadm、kubelet、kubectl 安裝 docker sudo apt install apt-transport-https ca-certificates curl gnupg-agent software-properties-common -y curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io -y sudo usermod -aG docker $USER 登出再登入 安裝 kubeadm kubelet kubectl sudo apt-get install -y apt-transport-https curl sudo su curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - sudo cat <<EOF >/etc/apt/sources.list.d/kubernetes.list deb https://apt.kubernetes.io/ kubernetes-xenial main EOF exit sudo apt-get update # apt-cache madison kubeadm # K_VER="1.20.5-00" # apt install -y kubelet=${K_VER} kubectl=${K_VER} kubeadm=${K_VER} # 不指定版本的話直接安裝即可 sudo apt install -y kubelet kubeadm kubectl # 若需要鎖定版本可以使用 apt-mark hold sudo apt-mark hold kubelet kubeadm kubectl 設定 kubeadm master sudo kubeadm init \ --pod-network-cidr 網路區段 \ --apiserver-advertise-address 本機IP \ --apiserver-cert-extra-sans gcp IP # kubeadm init --pod-network-cidr 172.100.0.0/16 --apiserver-advertise-address 10.140.0.2 --apiserver-cert-extra-sans 130.211.253.131 結束後會看到 ...