昨天我們建立了 Pod。

今天先不要急著進 Deployment。

因為要真正理解 Deployment 和 Service 前，一定要先懂：

Label
Selector
Namespace

這三個概念。

Label 就是貼標籤

假設有四個 Pod：

Pod A → API
Pod B → API
Pod C → Redis
Pod D → PostgreSQL

Kubernetes 不希望透過：

Pod 名稱

判斷角色。

因為 Pod 名稱可能一直變。

所以我們貼 Label：

metadata:
  labels:
    app: api

另外 Redis：

labels:
  app: redis

現在 Kubernetes 就能問：

誰是 app=api？

實際建立幾個 Pod

kubectl run api-1 \
  --image=nginx:alpine \
  --labels="app=api,env=dev"

kubectl run api-2 \
  --image=nginx:alpine \
  --labels="app=api,env=prod"

kubectl run redis-demo \
  --image=redis:alpine \
  --labels="app=redis,env=dev"

查看 Label：

kubectl get pods --show-labels

現在可以：

kubectl get pods -l app=api

-l：

Label Selector。

只會得到：

api-1
api-2

再：

kubectl get pods -l env=dev

Selector 為什麼這麼重要？

後面 Deployment 會說：

我要管理 app=api 的 Pod。

Service 會說：

我要把流量送給 app=api 的 Pod。

NetworkPolicy 可能說：

我要保護 app=redis 的 Pod。

所以 Kubernetes 很多 Resource 並不是：

A 直接綁 B 的名字。

而是透過：

Label Selector

建立關係。

這件事情一定要真正內化。

Namespace 是什麼？

現在：

kubectl get pods

其實你只是在看：

default Namespace。

建立：

kubectl create namespace cka-lab

查看：

kubectl get namespaces

縮寫：

kubectl get ns

你會看到：

default
kube-system
kube-public
cka-lab

Namespace 可以理解成：

Cluster 裡的邏輯分區。

例如：

development
staging
production

或者：

team-a
team-b

在指定 Namespace 建 Pod

kubectl run nginx \
  --image=nginx:alpine \
  -n cka-lab

現在：

kubectl get pods

看不到。

但：

kubectl get pods -n cka-lab

看得到。

所以：

Resource 可以同名 (有兩個都叫做 nginx 的 pod，只要 Namespace 不同就可同時存在)

為什麼 kube-system 不該亂碰？

kubectl get pods -n kube-system

你會看到：

那不是我們 Application 的 Namespace。

它主要包含 Kubernetes System Components。

所以初學時看到：

kube-system

就先建立一種直覺：

這裡是 Cluster 自己的重要東西，不要沒事亂刪。

建立正式 Namespace YAML

接下來系列都放進：

cka-lab

建立：

k8s/00-namespace.yaml

apiVersion: v1

kind: Namespace

metadata:
  name: cka-lab

套用：

kubectl apply -f k8s/00-namespace.yaml

Day 6 小結

今天的三個觀念後面會一直出現：

Label
＝ 我是誰

Selector
＝ 我要找誰

Namespace
＝ 我在哪個邏輯空間

明天我們終於要把：

孤單的 Pod

升級成真正 Production 比較常見的：

Deployment。

而且會親手刪 Pod，看 Kubernetes 自己把它救回來。