kubectl get pods -n kube-system 在看什麼？K8s 自己也是用 Pod 跑

K8s 怎麼跑自己的組件？

新手以為 API Server、Scheduler 是「裝在主機上的程式」。錯。

K8s 用一個非常優雅的設計：它自己的核心組件也是 Pod。全部住在一個叫 kube-system 的 namespace 裡。

這個叫「自舉（self-hosting）」——K8s 用 K8s 的方式管理自己。看懂這件事，K8s 架構就完全打通。

一行指令看到 K8s 的五臟六腑

裝好 minikube 或 k3d 之後（沒裝看這篇），打開終端機輸入：

kubectl get pods -n kube-system

-n 是 namespace 的縮寫，指定看 kube-system 這個系統 namespace。

如果你用 minikube，輸出大概長這樣：

NAME                               READY   STATUS    AGE
coredns-5d78c9869d-xxxxx           1/1     Running   2m
etcd-minikube                      1/1     Running   2m
kube-apiserver-minikube            1/1     Running   2m
kube-controller-manager-minikube   1/1     Running   2m
kube-proxy-yyyyy                   1/1     Running   2m
kube-scheduler-minikube            1/1     Running   2m
storage-provisioner                1/1     Running   2m

驚不驚喜？這就是 K8s 的全部「核心組件」——每一個都是 Pod。

一個一個來認

1. kube-apiserver — 大門

kube-apiserver-minikube

K8s 的唯一入口。所有 kubectl 指令、所有組件之間的溝通，全部走它。

它掛了 = 整個叢集失聯（其他組件還在跑，但你完全沒辦法操作）。

2. etcd — 大腦 / 資料庫

etcd-minikube

key-value 資料庫，記錄叢集所有狀態。

你建的每一個 Pod / Deployment / ConfigMap，最終都存在這裡
它掛了 = 叢集記憶喪失，所有狀態消失
正式環境最重要的備份對象

3. kube-scheduler — 調度員

kube-scheduler-minikube

新 Pod 該跑在哪個 Node？由它決定。

它的工作就一件事：看每個 Node 的資源狀況，挑最適合的。

實務上你看到 Pod 卡 Pending 8 成都是 scheduler 找不到合適的 Node。

4. kube-controller-manager — 自我修復引擎

kube-controller-manager-minikube

K8s 的「自動駕駛」——一直比對「現狀 vs 期望」，不一致就修。

裡面有一堆 controller：

Deployment Controller
ReplicaSet Controller
Node Controller
Job Controller
...

自我修復、自動擴縮容、滾動更新，全部是它做的。

5. kube-proxy — 網路代理（每個 Node 一份）

kube-proxy-yyyyy

注意這個 Pod 名字不像其他組件帶 -minikube，因為它每個 Node 都要跑一份——所以是 DaemonSet 部署的。

它的工作：讓 Service 真正能轉發請求。

維護一張轉發表（用 iptables 或 IPVS）：

Service 10.0.0.5:80
  ↓ kube-proxy 攔截
  └─► 隨機派給後端 Pod 1 / Pod 2 / Pod 3

6. coredns — 叢集內部 DNS

coredns-5d78c9869d-xxxxx

K8s 的 DNS 服務。讓 Pod 之間用「名字」互相找。

mysql.default.svc.cluster.local  → 解析成 → Service IP

沒有它的話，Pod 只能用 IP 找對方——而 Pod IP 會變，整個系統就崩了。coredns 是 Service 能用的關鍵。

預設是 2 份（高可用），你會看到兩個 coredns-xxxxx Pod。

7. storage-provisioner — 動態 Volume 配置（minikube 專屬）

storage-provisioner

minikube 內建的，當你建立 PVC 要儲存空間時，它幫你動態生出 PV。

正式叢集不會有這個——會用 cloud provider 的（AWS EBS、GCP Persistent Disk 等）。

看更深一層：每個 Pod 在跑什麼？

選一個 Pod 看它的細節：

kubectl describe pod kube-apiserver-minikube -n kube-system

往下看會看到：

Image：registry.k8s.io/kube-apiserver:v1.28.x（API Server 是個容器）
Command：kube-apiserver --advertise-address=... --etcd-servers=...（啟動參數）
Volumes：mount 了憑證、設定檔
Container Runtime：containerd

你會發現 API Server 就是一個 Linux 程式 + 一堆參數——沒有什麼神秘的。

「節點」也藏在這裡：用 `-A` 看全部

加 -A（all namespaces）一次看全：

kubectl get pods -A

你會看到：

kube-system：剛才那一堆系統組件
default：你的應用 Pod 會放這裡
kube-public：公開資訊（很少用）
kube-node-lease：Node 心跳記錄

用 k3d / k3s 會看到什麼不同？

k3s 是輕量版，會多幾個自己的東西：

NAME                                      READY   STATUS    AGE
coredns-77ccd57875-xxxxx                  1/1     Running   1m
local-path-provisioner-957fdf8bc-xxxxx    1/1     Running   1m
metrics-server-648b5df564-xxxxx           1/1     Running   1m
helm-install-traefik-crd-xxxxx            0/1     Completed 1m
helm-install-traefik-xxxxx                0/1     Completed 1m
svclb-traefik-xxxxx                       2/2     Running   1m
traefik-768bdcdcdd-xxxxx                  1/1     Running   1m

多了幾樣：

traefik：k3s 內建的 Ingress Controller（minikube 要自己裝）
metrics-server：metric 收集（給 kubectl top 和 HPA 用的）
local-path-provisioner：本地儲存

少了幾樣（k3s 砍掉的）：

預設 Pod 列表看不到 kube-apiserver、kube-scheduler、etcd——它們全部塞進一個叫 k3s 的程式裡了，沒有獨立 Pod
學習階段差別不大，正式生產要注意

實作練習：找到每個組件的「日誌」

挑 API Server 看它的 log：

kubectl logs kube-apiserver-minikube -n kube-system | head -20

你會看到一堆 K8s 內部運作的訊息。這就是所有 kubectl 操作背後的「真相」——你的每個指令都會在這裡留下痕跡。

如果你看不到這些 Pod 怎麼辦？

幾種常見情況：

沒加 -n kube-system → kubectl get pods 預設只看 default namespace，當然空的

某個 Pod 不是 Running → 叢集有問題，跑 kubectl describe pod xxx -n kube-system 看 Events

completely empty → minikube / k3d 沒啟動，跑 minikube status 或 k3d cluster list 確認

看懂這些之後，K8s 不再是黑盒

重點：你對 K8s 之前的恐懼，9 成來自「我不知道它在幹嘛」。

現在你知道了：

它的「大門」是一個叫 kube-apiserver 的 Pod
它的「資料庫」是 etcd
它的「自動修復」是 controller-manager
它的「DNS」是 coredns

全部都是 Pod，全部都看得到、查得到、可以 describe 的東西。沒有黑盒。

重點整理

K8s 自己的組件全部用 Pod 跑，住在 kube-system namespace
kubectl get pods -n kube-system 一次看光所有核心組件
七個常見組件：kube-apiserver / etcd / scheduler / controller-manager / kube-proxy / coredns / storage-provisioner
k3s/k3d 跟 minikube 不太一樣（k3s 把多個組件塞成一個程式），多了 traefik / metrics-server
看懂這些 = 把 K8s 的黑盒打開

下一步

組件都認完了，現在你需要學「怎麼跟 K8s 說話」——下一篇進入 K8s YAML 完整教學：apiVersion / kind / metadata / spec 四大區塊，這是 K8s 的「公文格式」，看完所有 K8s YAML 都看得懂。