Kubernetes on omegaatt

把 k3s 從 Ubuntu 搬到 OpenSUSE MicroOS，順便換上 FluxCD GitOps

raiven.kao@gmail.com (Raiven Kao) — Sun, 24 May 2026 00:00:00 +0000

前言

我的 Homelab 跑著一台 Proxmox VE，底下有一個 Ubuntu Server 24.04 的 VM 負責跑 k3s cluster，這個 cluster 接管了家裡所有的自架服務：從 Vaultwarden 密碼管理、Karakeep 書籤、Filebrowser 文件管理，到 Wakapi 開發時間追蹤，大大小小跑了十幾個服務。

這個架構一直跑得很穩。直到 Linux kernel 7.0 發布，我才開始動搖。

kernel 7.0 的各種新特性讓我心癢，Ubuntu 26.04 LTS 剛好以 kernel 7.0 作為預設核心，理論上從 24.04 升上去就能一步到位。但在一個跑著十幾個服務的生產 VM 上執行 do-release-upgrade，那種心臟發抖的感覺，即便有做好備份，還是讓我遲遲下不了手。

就在猶豫要不要升級的當下，我問了自己一個問題：「我要繼續用 Ubuntu 嗎？」

這個問題打開了一扇門。我的 Linux desktop 是 openSUSE Tumbleweed + KDE Plasma，用了三年、換過兩台裝置（筆電和桌電），沒有遇到太多問題。Tumbleweed 的滾動更新讓我一直跑著最新的 kernel，升級這件事從來不是一個需要另外排行程的壓力事件。

既然 desktop 側已經對 openSUSE 生態有信心，server 側為什麼不試試看？

這讓我開始認真考慮：有沒有一種 OS，讓 server 的升級這件事也變成「預設安全」而不是「需要勇氣」？

為什麼選 OpenSUSE MicroOS

OpenSUSE MicroOS 是一個 Immutable OS（不可變作業系統），核心特性有幾個：

k3s Ingress Controller 從 Nginx 遷移到 Traefik 同時整合 CrowdSec

raiven.kao@gmail.com (Raiven Kao) — Sat, 11 Apr 2026 00:00:00 +0000

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 的標準規範。

Helm Smart Resource：讓你的 Chart 學會與既有資源和平共處

raiven.kao@gmail.com (Raiven Kao) — Sat, 22 Nov 2025 00:00:00 +0000

前言

在 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」。

告別 Docker Desktop 束縛！macOS 容器實戰：colima + k8s + containerd 踩坑遷移全記錄

raiven.kao@gmail.com (Raiven Kao) — Sat, 19 Apr 2025 00:00:00 +0000

前言

身為一個開發者，特別是在 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 等繁瑣步驟，讓你專注在容器本身。

proxmox ve shrink vm disk size

raiven.kao@gmail.com (Raiven Kao) — Sun, 04 Sep 2022 00:00:00 +0000

由於 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 的設定，再調整回來

CentOS 7 kubernetes + containerd + calico basic installation tutorial

raiven.kao@gmail.com (Raiven Kao) — Sun, 20 Feb 2022 00:00:00 +0000

前言

鑒於最近接到 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 唯一的網卡，不做其他進階設定。

改善 Proxmox VE/Debian 始終跑在最高頻率

raiven.kao@gmail.com (Raiven Kao) — Sun, 09 Jan 2022 00:00:00 +0000

這幾天把便宜撿到的 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 頻率狀態。

Kubernetes 學習筆記 - Ubuntu kubeamd 建置 cluster

raiven.kao@gmail.com (Raiven Kao) — Sun, 19 Sep 2021 00:00:00 +0000

環境

物理機: 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

結束後會看到