Shannon's Blog 🐟 技術 | 生活 | 旅行

前言：那兩秒之間發生了什麼事？ 你敲下 kubectl apply -f deployment.yaml，按 Enter，終端機回你一行： 1deployment.apps/my-app created 兩秒後，kubectl get pods 顯示三個 Pod 正在 Running。 那兩秒之間發生了什麼事？ 你的 YAML 去了哪裡？誰決定這三個 Pod 要跑在哪幾台機器上？又是誰真的把容器拉起來的？如果其中一個 Pod 掛掉，是誰發現的、誰把它補回來的？ 大部分講 Kubernetes 元件的文章，會給你一張架構圖和七個名詞解釋。但那樣很難記住——因為你不知道它們什麼時候會用到。 所以這篇文章換個方式：我們跟著這一個 kubectl apply 指令，走完它在叢集裡經過的每一站。 每個元件都會在它該出場的時候登場，你會看到它接收到什麼、做了什麼決定、然後把什麼交給下一棒。 走完這趟旅程，你不需要背，自然就記住了。 [!NOTE] 這篇文章假設你會用 kubectl，但不知道背後發生什麼事 你能 kubectl apply、看得懂 Pod 和 Service 大概在做什麼。...

前言：升級當天才發現，就太晚了 升級 Kubernetes 真正花時間的，從來不是那三行 kubeadm 指令。 是升級前那份「到底什麼東西會爆」的清單。 而會爆的東西分成三種，它們壞掉的方式完全不一樣： 會爆的東西 長什麼樣 什麼時候發現 ① 元件版本不相容 Cilium 不支援新版 K8s、Helm chart 裝不上去 升級當下就失敗 ② 你的 YAML 用了被移除的 API apiVersion 在新版已經不存在，資源直接建不起來 升級後才發現，而且是安靜地壞** ③ Feature gate 換階段了 你依賴的功能預設值變了，或開關直接被移除 行為變了但沒有錯誤訊息，最難查 第一種是大家都會想到的，但它其實最不危險——因為它會當場失敗，你馬上知道。 真正陰險的是第二、三種。你的 Deployment 昨天還好好的，升級完之後某天有人重新 apply 一次，才發現 apiVersion 已經不被接受了；或是某個功能的預設值悄悄從關變成開，三天後某個 Pod 重啟才爆出來。 這篇文章要教的就是怎麼在升級前，把這三種都提前抓出來： 元件版本 → ...

前言 當你管理的機器從 1 台變成 50 台之後，SSH 金鑰一定會讓你半夜驚醒： 「有個工程師離職了，他的 public key 到底散在哪幾台機器的 authorized_keys 裡？我要一台一台去刪嗎？」 「跳板機（bastion / control node）上放了一把萬能私鑰，只要那把鑰匙外洩，整個機房就全裸了。」 「我只想讓 CI 在『部署的那 5 分鐘』內能連進去，但傳統金鑰一放上去就是永久有效，根本沒有『到期』這回事。」 這些痛點的共通根源是：傳統 SSH 是「一把鑰匙配一把鎖」的信任模型——你得把每一把公鑰（public key）事先塞進每一台目標主機。機器一多，這件事就變成災難。 這篇文章要介紹一個更聰明的解法：把 HashiCorp Vault 當成一個「SSH 憑證中心（CA, Certificate Authority）」。 🔑 CA（Certificate Authority，憑證簽發中心）是什麼？ 你可以把它想成「機場的證件核發櫃檯」。目標主機不再認得每一位旅客（每一把公鑰），它只認得「這張登機證是不是機場官方蓋章的」。只要 Vault 蓋...

前言 當你把服務一個個丟進 Kubernetes 叢集之後，一定會遇到這些讓人半夜驚醒的時刻： 「使用者說網站很慢，但我怎麼知道是哪個節點的 CPU 爆了？」 「某個 Pod 一直重啟，到底是記憶體不夠，還是被 OOMKill 了？」 「我想做一張漂亮的儀表板給老闆看，但數據要從哪裡來？」 這些問題的答案，其實都指向同一套解法：Prometheus 負責『收集與儲存』數據，Grafana 負責『把數據畫成人看得懂的圖』。 這兩個工具幾乎是雲原生世界的監控黃金組合。 網路上大部分教學都叫你直接 helm install 一鍵安裝，但那樣你永遠不會知道「箱子裡面到底裝了什麼」。這篇文章反其道而行——我們用手寫 YAML manifests 的方式，在一個 k3s 輕量叢集上，一塊磚一塊磚地把整套監控系統疊起來。等你讀完，你不只會「用」，更會「懂」。 📦 本文所有範例都跑在 k3d 叢集（namespace 為 monitoring）。k3s 是輕量級的 Kubernetes 發行版，而 k3d 則是把 k3s 跑在 Docker 裡的工具，很適合本機學習。指令換成任何標準 K...

如何 curl 測試容器 1kubectl -n monitoring run ne-test --rm -i --restart=Never --image=curlimages/curl:8.10.1 -- curl -s http://node-exporter:9100/metrics 2>&1 | grep -E "^node_(memory_MemAvailable|cpu_seconds_total|filesystem_avail)" | head -5 這是一個非常典型的 Kubernetes 臨時除錯指令。它利用一個暫時性的容器來測試叢集內部的網路連通性，並獲取 Prometheus 格式的監控數據。 我們可以將指令拆解成三個部分來理解： 1.啟動測試容器 (The Runner) 1kubectl -n monitoring run ne-test --rm -i --restart=Never --image=curlimages/curl:8.10.1 -n monitoring: 在指定的 monitoring 命名...

前言 在過去，Python 的世界裡安裝套件、打包專案各有各的工具（setup.py、requirements.txt、Pipfile 等），生態系相當分散。pyproject.toml 是 Python 社群為了統一這些標準而誕生的格式，從 PEP 518 開始逐漸成為官方推薦的專案設定入口。它就像專案的「身分證」與「說明書」，集中描述專案名稱、依賴套件、建置方式等所有關鍵資訊。 核心結構 pyproject.toml 主要由以下兩個區塊組成： [build-system]：宣告要用哪個工具來打包專案（常見為 setuptools 或 hatchling）。 [project]：最核心的區塊，包含專案名稱、版本、作者，以及執行時所需的依賴套件（dependencies）。 建立 pyproject.toml Step 1：建立專案資料夾 以一個需要 requests 套件的爬蟲程式為例，建立以下目錄結構： 123my_project/├── pyproject.toml└── main.py Step 2：撰寫 pyproject.toml 在 pyproject.toml...

前言 這裡是我寫Leetcode總結核心概念的地方，不同的情境會使用到的武器不同，這裡我會描述在什麼樣的情境滿足下，適合的資料結構或是演算法。而這個演算法的核心概念是什麼，同時我也會紀錄一些我在刷題時的心得，以及刷題的時間，來慢慢看到成長與進步。 Leetcode時間紀錄 Hash Table 情境1: 快速找元素 通常使用 Hash 的關鍵在於要用 O(1) 的時間複雜度來查找元素，這樣就可以不用遍歷整個 list 從 O(n) 變成 O(1) 的時間內完成整個問題。 相關題目： leetcode-1-two-sum: 給定一個 target 數值，從 list 中找到兩個數字相加等於 target leetcode-12-integer-to-roman: 整數轉羅馬數字 leetcode-13-roman-to-integer: 羅馬數字轉整數 情境2: 比對無序的東西 如果要比對兩個無序的東西，像是兩個字串是否是 Anagram，這時候可以使用 Hash 來記錄每個字元出現的次數，然後比對兩個 Hash 是否相同。 相關題目： leetcode-49-gr...

前言 最近嘗試在使用 Ansible 寫出針對 Inventory 的 Current State 狀態整理， Inventory 會記錄 kubernetes 中 cluster 所有的 nodes，但很多時候我們在開始執行 playbook 時才發現有些 node 的狀態不是健康的，所以希望寫出一個流程可以先做一些 precheck 捕捉 inventory 的狀態，這樣在執行 playbook 時就可以針對這些 unhealthy node 先排除，不會因為 node 的狀態不健康而導致 playbook 執行失敗。這種自己定義的邏輯我希望自己寫 .py 來實現，所以我在思考應該使用 module 還是 action plugin 來實現。這兩者的差異還是有點模糊，於是就寫下這篇文章來做個比較。 在開始之前，先來講一些 ansible 常見的術語： Modules: 透過 ansible 推送到各個節點的腳本 (像是那個 module 的 .py 檔案)，我們稱為module。 而需要注意的事情是，這些 module 是在 ansible 的目標主機上執行的，你在 Pl...

介紹 最近在開發 Ansible Module 時，想要在 Pycharm 中進行 Debug，不然每次去猜測每個變數裡面現在的值真的是太痛苦了…於是就嘗試使用 Pycharm 的 Debug 功能來進行除錯。 因為最近在開發 collection 的 module 所以本篇主要會以 collection 的 module debug 為主。 這篇文章會介紹如何在 Pycharm 中進行 Ansible Module 的 Debug，並且提供一些小技巧來讓你更有效率地進行除錯。 前置作業 先確保你已經安裝了 Pycharm 和 Ansible。 (這邊建議您使用 venv 或是 conda 來建立虛擬環境，這樣可以避免跟系統的 Python 衝突) 在 Pycharm 中建立一個新的專案，並且將 Ansible Module 的程式碼放到專案中。 12345678910111213141516171819202122# 可以使用 ansible-galaxy init 來建立 collection 的基本架構# 然後放在 collections 底下 .├── collect...

前言 你有沒有曾經想過，在部署程式碼之前，希望先檢查一下有沒有錯誤，或者程式碼格式有沒有符合規範？這時候，CI/CD 就可以派上用場。CI（持續整合）可以幫你自動檢查程式碼品質，而 CD（持續交付/部署）則可以自動化部署流程，讓你的程式碼從開發到上線都更順暢。 但是，如果你有很多專案，而且每個專案都需要寫一模一樣或非常相似的 CI/CD 腳本，這就會變成一件既繁瑣又浪費時間的事情。你可能會想：「有沒有辦法只要簡單放入某些內容，就可以套用特定的腳本？」 其實，GitLab CI/CD 就提供了這樣的功能。透過重複利用與共享配置，你可以「讓多個專案共用同一套 CI/CD 流程」，不但節省時間，還能確保所有專案都遵循相同的規範。 例如，你可以在 .gitlab-ci.yml 套用別人是先撰寫好的腳本： 1234include: - component: $CI_SERVER_FQDN/my-org/security-components/secret-detection@1.0.0 inputs: stage: build 這樣，你的 stages 裡面就會載入 se...