02 第2周D8 Kubernetes
D8 Kubernetes
D8 Kubernetes
标准(必讲,但只读到"能看懂、能查询、能跟部署")。公司生产跑在 k3s 集群上,新人要会只读操作、看得懂部署状态。
教学目标(学完能做什么)
- 能说出 K8s 核心对象与作用:Pod / Deployment / Service / Ingress / Namespace / ConfigMap / Secret
- 会用 kubectl 查询集群与服务状态(只读)
- 能看懂一个 Deployment/Ingress 清单,说出它部署了什么
- 知道公司集群环境(prod k3s)与"只看不改"的红线
前置要求
- D5(Linux)、D7(Docker,理解容器)
本模块在业务中的位置
- 公司所有服务都跑在 prod k3s 集群(唯一生产)。新人日常:查日志、看 Pod 状态、跟进发版。本模块给你"看集群"的能力;写清单/改集群是 D22 与后续带教的事。
内容分段
1. 为什么需要 K8s
- Docker 解决"单机怎么跑容器";生产要多台机器、自动调度、故障自愈、滚动更新 → K8s。
- 公司实践:k3s(K8s 的轻量发行版,适合公司规模)。集群信息见 CLAUDE.md(master + 两个 worker)。
2. 核心对象(记牢,这是看集群的字典)
| 对象 | 作用 | 类比 |
|---|---|---|
| Pod | 最小调度单元,1+ 容器 | 一个"进程盒" |
| Deployment | 声明"要几个副本",管滚动更新/自愈 | 团长 |
| Service | Pod 的稳定入口(ClusterIP/NodePort) | 稳定的门牌 |
| Ingress | 对外域名 + TLS 路由(公司用 Traefik) | 大门+门卫 |
| Namespace | 逻辑隔离(公司有 default 及各应用 ns) | 部门 |
| ConfigMap | 非敏感配置 | 配置单 |
| Secret | 敏感配置(密码/密钥,base64) | 保险柜 |
3. kubectl 只读操作(本模块核心技能)
kuse prod # 切到生产集群(公司脚本,见 CLAUDE.md)
kubectl get nodes # 看节点
kubectl get pods -A # 看所有命名空间下的 Pod
kubectl get deploy -A # 看 Deployment
kubectl get svc -n <ns> # 看 Service
kubectl get ingress -A # 看 Ingress(域名/证书路由)
kubectl describe pod <name> -n <ns> # 看 Pod 详情(事件!)
kubectl logs <pod> -n <ns> # 看日志
kubectl top nodes # 看节点资源(只读监控)- 新人红线:以上全是
get/describe/logs/top只读命令;apply/patch/delete/restart一律不允许(Class A,见 AGENTS.md)。
4. 读一个清单(会看就行)
# 一个 Deployment 简化示意(公司真实清单在 manifests/apps/)
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
namespace: default
spec:
replicas: 2 # 两个副本
selector:
matchLabels: { app: myapp }
template:
metadata:
labels: { app: myapp }
spec:
containers:
- name: myapp
image: registry.akria.net/myapp:v1 # 公司镜像仓库
ports: [{ containerPort: 8000 }]- 关键词:
replicas(副本数)、image(哪个镜像,公司都从 registry.akria.net 拉)、labels(怎么互相认)。
5. 一次发版在 K8s 里长什么样(配合 D6 的 CI/CD 图)
- CI 推送新镜像 tag 到 registry。
- 触发 Deployment 更新(
kubectl set image或清单更新,属 Class A)。 - K8s 滚动更新:起新 Pod → 健康检查通过 → 摘旧 Pod。
- 期间
kubectl get pods -w能实时看到ContainerCreating → Running。 - Service/Ingress 不变,客户无感。
- 常见状态:
CrashLoopBackOff(起不来,看日志)、ImagePullBackOff(镜像拉不到,看名字/仓库)、Pending(资源不足/调度不了)。 - 不要删 CrashLoopBackOff 的 Pod(AGENTS.md 安全规则)——查日志找原因,别粗暴删除。
6. 集群存储与监控(了解)
- 存储:Longhorn(默认 2 副本)、longhorn-single(1 副本)——K8s 的持久化卷。
- 监控:headlamp(
monitor.akria.net)可看集群;节点资源kubectl top。 - 备份:Velero(
kubectl get backup.velero.io)。
讲解节奏建议(约 90 分钟)
| 时段 | 内容 |
|---|---|
| 09:00-09:10 | 引入:Docker 是单机集装箱,K8s 是自动化码头 |
| 09:10-09:40 | 核心对象字典(逐表讲) |
| 09:40-10:10 | kubectl 只读命令演示(讲师 kuse prod 现场查) |
| 10:10-10:30 | 读一个 Deployment 清单 |
| 10:30-10:50 | 一次发版在 K8s 里的过程 + 常见状态 |
| 10:50-11:30 | 学员实操:只读查询(对应作业) |
| 11:30-11:50 | 常见误区 + 红线再强调 |
| 11:50-12:00 | 布置作业 |
常见误区汇总
| 误区 | 正确理解 |
|---|---|
| 想删 CrashLoopBackOff 的 Pod"重来" | 不能删(AGENTS.md 红线),查日志找根因 |
| Pod 重启了就是好了 | 自愈只保证"副本数",反复重启说明有 bug 或资源问题 |
kubectl apply 很顺手 | 对新人=Class A 写操作,不允许;只读四件套够用 |
| Ingress 和 Service 一回事 | Service 管集群内稳定入口;Ingress 管对外域名+证书路由 |
| 一个 Pod 一个容器 | 可以多容器,但公司场景大多 1 Pod 1 主容器 |
| 生产集群随便切 | kuse prod 后只读;切回开发环境记得 kuse dev |