# 02-00 Nginx 矩阵系列说明（节点 + Ingress / IngressRoute）

> 目的：先把本系列（02-01~02-05）共用的“节点调度规则”和“Traefik 路由对象差异”讲清楚，后面的 02-01~02-04 分篇才能读得更快、更少踩坑。

---

## 1. 节点与调度（M1~M4 到底落在哪）

本仓库的 nginx 矩阵里，4 个场景 M1~M4 的“落点”不同，主要通过 `nodeSelector` 控制。

### 1.1 查看 `node-role` 与 `hostname`（用于排查 nodeSelector）

```bash
# 1) 最直观：查看所有节点的全部 labels
kubectl get nodes --show-labels

# 2) 检查 hostname label（用于 M2/M4）
kubectl get nodes -l kubernetes.io/hostname=<hostname> -o name

# 3) 检查 control-plane label（用于 M1）
kubectl get nodes -l node-role.kubernetes.io/control-plane -o name

# 4) 检查 worker label（用于 M3）
kubectl get nodes -l node-role.kubernetes.io/worker -o name

# 5) 最后：查看单节点全部信息（Labels / Taints / Events）
kubectl describe node <节点名>
```

提示：如果你在 M2/M4 里写的是 `nodeSelector: kubernetes.io/hostname: ylc61`，但该节点没有打上 `kubernetes.io/hostname=ylc61` 这个 label，则 M2/M4 会匹配不到。

### 1.2 M1 / M2：控制节点（control-plane）

- **M1（Ingress）**：用 `nodeSelector: node-role.kubernetes.io/control-plane: ""` + `tolerations`（允许调度到控制节点的 `NoSchedule` 污点）。
- **M2（IngressRoute）**：用 `nodeSelector: kubernetes.io/hostname: ylc61`（指定某一台控制节点）。

如果你看到 M1/M2 的 Pod 一直 Pending：
- 通常是控制节点缺少对应的 label（`node-role.kubernetes.io/control-plane` 或 hostname 不匹配）
- 或者存在 taint 没有匹配到 M1 的 toleration

### 1.3 M3 / M4：工作节点（worker）

- **M3（Ingress）**：`nodeSelector: node-role.kubernetes.io/worker: ""`，因此会“随机落在任意 worker”。
- **M4（IngressRoute）**：`nodeSelector: kubernetes.io/hostname: ylc64`，指定某一台 worker。

如果你看到 M3/M4 落不到目标节点：
- 确认 worker 节点带有 `node-role.kubernetes.io/worker` 标签（M3）
- 或 hostname 是否与你写入的 `ylc64` 一致（M4）

---

## 2. Ingress vs IngressRoute（Traefik 路由对象差异）

本项目使用 Traefik：
- `Ingress`：Kubernetes 原生对象 `kind: Ingress`（依赖 Ingress Controller 对接）
- `IngressRoute`：Traefik CRD 对象 `kind: IngressRoute`（需要 CRD 已启用）

在本系列中，它们还体现为两类“路由写法”：

### 2.1 Ingress（用于 M1 / M3）

- 采用 `spec.rules.http.paths`，典型写法是：
  - `path: /demo-mx`
  - `pathType: Prefix`
- 中间件挂载方式在本仓库的示例里使用 annotation：
  - `traefik.ingress.kubernetes.io/router.middlewares: default-stripprefix-mx@kubernetescrd`

### 2.2 IngressRoute（用于 M2 / M4）

- 采用 `spec.entryPoints` + `spec.routes`，并使用 `match`：
  - `entryPoints: [web]`
  - `match: PathPrefix(\`/demo-mx\`)`
  - `services` 指向对应 Service
  - `middlewares` 在 CRD 内直接引用（`name: stripprefix-mx`）

---

## 3. `/demo-mx` 路由结构（为什么还要 Middleware）

每个 Mx 都有一个 `Middleware`（`kind: Middleware`）做 `stripPrefix`：
- 前缀例如 `/demo-m1`
- 去掉前缀后，nginx 才能把请求当成 `/` 来返回 `index.html`

因此在本系列里：
- 你访问 `http://<入口节点IP>/demo-m1/` 会先经过 `stripPrefix`
- ngnix 最终拿到的是 `/`
- 页面中会显示本场景的标识（M1/M2/M3/M4），便于你确认落点与路由是否正确

---

## 4. 本系列的“共同资源”你应该知道怎么删/怎么验证

所有 M1~M4 都在同一个命名空间 `default`：
- Pod/Service：`kubectl get pod,svc -n default ...`
- Ingress/IngressRoute：分别 `kubectl get ing -n default` 或 `kubectl get ingressroute -n default`

通用删除建议使用 manifests 目录（一键清理同一个场景）：

```bash
kubectl delete -f ansible/files/nginx-matrix/ -R
```

或按具体文件删单个场景（见各分篇的 `## 删除` 小节）。

---

## 5. 推荐阅读顺序

1. `02-00-nginx-系列说明.md`（本页）
2. `02-01~02-04`（按你关心的节点落点/路由对象读）
3. `02-05-nginx-验证矩阵-一键部署.md`（最终整合、一次验证 4 个场景）