当前位置：首页 > news >正文

K8s核心原理及注意事项

news 2026/5/11 20:12:15

Kubernetes (K8s) 的核心原理可以概括为：基于“声明式 API”的“期望状态”与“实际状态”的自动调和（Reconciliation）。

它不像传统脚本那样一步步执行命令（“先启动A，再启动B，如果失败则...”），而是你告诉它“我想要什么状态”，K8s 的控制循环（Control Loop）会不断观察并努力让集群达到这个状态。

以下是 K8s 的核心原理解析及生产环境注意事项。

这是 K8s 的灵魂。

声明式 (Declarative)：用户提交一个 YAML 文件（例如：replicas: 3），描述期望状态 (Desired State)。
观测 (Observe)：K8s 组件通过 List-Watch 机制实时监控集群的实际状态 (Actual State)。
调和 (Reconcile)：控制器（Controller Manager）对比“期望”与“实际”。
- 如果 实际 < 期望（比如挂了1个 Pod），控制器会创建新 Pod。
- 如果 实际 > 期望（比如缩容），控制器会删除多余 Pod。
- 如果 实际 != 期望（比如配置变了），控制器会更新资源。
结果：无论发生什么（节点宕机、进程崩溃、网络抖动），K8s 都会自动尝试修复，直到实际状态等于期望状态。

当一个新的 Pod 被创建且未绑定节点时，Scheduler 介入工作：

K8s 的网络设计遵循三大原则（扁平化网络）：

实现：通过 CNI 插件（如 Calico, Flannel, Cilium）在节点间建立 Overlay 网络（VXLAN/IPIP）或路由表，打通二层或三层网络。
Service 网络：通过 kube-proxy (iptables/IPVS) 或 eBPF (Cilium) 实现虚拟 IP (ClusterIP) 到后端 Pod IP 的负载均衡映射。

在生产环境中运行 K8s，稳定性和安全性是首要考量。以下是必须注意的陷阱：

这是新手最容易忽视导致集群不稳定的原因。

Requests (请求)：调度器依据此值决定把 Pod 放在哪个节点。务必设置，否则可能导致节点超卖，内存溢出 (OOM)。
Limits (限制)：容器能使用的资源上限。
- CPU Limit：超过会被节流 (Throttling)，性能下降但不会挂。
- Memory Limit：超过会被直接 Kill (OOMKilled)，容器重启。
建议：
- Java 应用：JVM 堆内存应设置为 Limit * 0.7 左右，预留空间给非堆内存，防止 OOMKilled。
- 监控：使用 Prometheus 监控 container_memory_usage_bytes 和 throttled_time。

不要依赖 K8s 默认的检测。必须配置三种探针：

Startup Probe (启动探针)：用于启动慢的应用（如大型 Java 服务）。在启动完成前，不执行其他探针，避免被误杀。
Liveness Probe (存活探针)：检测死锁或死进程。失败则重启容器。
- 注意：不要将依赖外部服务（如数据库）的检查放入 Liveness，否则数据库抖动会导致所有应用无限重启（雪崩效应）。
Readiness Probe (就绪探针)：检测是否准备好接收流量。失败则从 Service 负载均衡中剔除，但不重启。
- 场景：应用正在加载缓存或处理大量数据时，暂时切断流量。

K8s 删除 Pod 时，会先发送 SIGTERM 信号，等待 terminationGracePeriodSeconds (默认30秒)，然后强制发送 SIGKILL。

问题：很多应用收到 SIGTERM 后直接退出，但此时 K8s 可能已经将该 Pod 从 Service 摘除，而新的流量还在进来，或者正在处理的请求被中断。
对策：
1. 应用代码需捕获 SIGTERM 信号，停止接收新请求，处理完现有请求后再退出。
2. 在 preStop 钩子中加入 sleep 或使用 Nginx Ingress 的 worker-shutdown-timeout，确保流量完全切断后再关闭应用。
3. 适当延长 terminationGracePeriodSeconds。

禁止硬编码：绝对不要把密码、Key 写死在 Docker 镜像或 YAML 中。
使用 Secret：虽然 Secret 默认只是 Base64 编码（非加密），但应结合 Etcd 加密 或使用外部密钥管理系统（如 HashiCorp Vault, AWS Secrets Manager）并通过 CSI Driver 挂载。
ConfigMap 热更新：修改 ConfigMap 后，挂载为 Volume 的文件会自动更新，但环境变量不会。应用需要支持重载配置或重启 Pod。

不要随意删 Pod：StatefulSet 的 Pod 名字是固定的 (web-0, web-1)，删除后重建也是同名。如果是数据库，直接删除 Pod 可能导致数据不一致或脑裂。
存储绑定：确保 PVC 策略正确。删除 StatefulSet 时，默认不会删除 PVC，防止数据丢失。清理时需手动删除 PVC。
拓扑分布：对于高可用数据库，使用 topologySpreadConstraints 确保副本分布在不同的可用区 (AZ) 或节点上。

隔离：不同环境（Dev, Test, Prod）或不同团队应使用不同的 Namespace。
配额 (ResourceQuota)：在每个 Namespace 设置 CPU/Mem 上限和对象数量上限，防止某个团队的测试脚本失控耗尽整个集群资源。
限制范围 (LimitRange)：设置 Namespace 内 Pod 的默认 Request/Limit，防止用户忘记配置。

标准输出：应用日志必须打印到 stdout/stderr，不要写入容器内的文件（容器重启即丢失，且难以收集）。
Sidecar 模式：对于必须写文件的老应用，使用 Sidecar 容器（如 filebeat/fluentd）采集日志。
可观测性：必须部署 Prometheus + Grafana (监控指标) 和 ELK/Loki (日志)，以及 Jaeger/SkyWalking (链路追踪)。没有监控的 K8s 是在“盲飞”。

RBAC：遵循最小权限原则。不要给开发人员 cluster-admin 权限。
Network Policies：默认情况下 K8s 允许所有 Pod 互通。生产环境应启用 Network Policy，实施零信任网络（只允许必要的 Pod 间通信，如 Web -> DB，禁止 Web -> Web）。
Pod Security Standards (PSS)：启用 PSS，禁止特权容器 (privileged: true)，禁止 Host 网络/PID 命名空间共享。