# 05-04-k3s 配置 GitLab CI/CD

> 把 manifests 与 values 纳入 GitLab 仓库，通过流水线自动部署到 K3s。


## TL;DR

- **自动化验收**：`./ansible/bin/verify.sh run 05-04`
- **关键前置**：按本文「前置条件」准备环境变量/Secret/入口 IP
- **成功判据**：达到本文「预期」且 playbook 断言通过
- **排障**：见本文「排障」

---

## 建议仓库结构

```text
homelab-config/
  apps/
  charts/
  manifests/
  .gitlab-ci.yml
```

---

## 准备集群凭据

常见做法二选一：

1. `KUBE_CONFIG` 变量（适合快速落地）
2. ServiceAccount + RBAC（适合长期最小权限）

---

## 基础流水线步骤

- `lint`：检查 YAML/Helm 语法
- `deploy`：`kubectl apply -f ...` 或 `helm upgrade --install`
- `verify`：部署后基本健康检查

**唯一真源（示例流水线）**：

- 最小：[`ansible/files/05-04/gitlab-ci-minimal.example.yml`](../ansible/files/05-04/gitlab-ci-minimal.example.yml)
- 多架构 deploy：[`ansible/files/05-04/gitlab-ci-multi-arch-deploy.example.yml`](../ansible/files/05-04/gitlab-ci-multi-arch-deploy.example.yml)
 
复制到仓库根为 `.gitlab-ci.yml`（或 `include` 引用），并配好 Runner 与 `KUBE_CONFIG_CONTENT` 等变量。

---

## 验证

1. 提交一次最小变更（如 ConfigMap）
2. 确认 Pipeline 成功
3. 确认集群资源已更新

---

## 下一步

- `05-05-prometheus与grafana.md`
- `06-02-运维小结.md`

## 排障

- **先看 playbook 输出**：失败时先定位是 deploy/wait/http_check 哪一步。
- **集群侧总览**：`kubectl get nodes -o wide`、`kubectl -n kube-system get pods -o wide`。
- **事件与日志**：`kubectl -n <ns> describe ...`、`kubectl -n <ns> logs ... --tail=200`。