容器资源限制、安全组和接入控制是分层协同的稳定支柱：资源限制管“能用多少”，安全组管“谁能连”，接入控制管“连上来能做什么”，三者从资源层、网络层、应用层联合堵住不稳定源头。
容器资源限制、安全组和接入控制三者不是并列的“可选项”，而是分层协同的稳定支柱：资源限制管“能用多少”，安全组管“谁能连”，接入控制管“连上来能做什么”。配合得当，能从资源层、网络层、应用层同时堵住不稳定源头。
资源限制是稳定性第一道防线
没有合理配额的容器，就像没装保险丝的电路——单个服务异常会直接拖垮整台宿主机。重点不是“压到最低”，而是匹配真实负载并留出缓冲：
-
内存必须设 limits：避免 OOM Killer 随机杀进程。生产环境建议
limits.memory设为预估峰值的 1.3–1.5 倍，且requests.memory不低于 60% 的 limits，确保调度器不把容器塞进内存紧张的节点 -
CPU 推荐用 --cpus 而非 --cpu-shares：后者只在争抢时生效，无法防止单容器吃满所有核；
--cpus=1.2这类硬限能真正隔离计算资源 -
swap 必须显式禁用：Docker 中设
--memory-swap=--memory，防止内存溢出后大量换页，引发 I/O 飙升和响应延迟
安全组是网络层的准入闸机
它不看容器内部状态，只按 IP、端口、协议放行流量。与资源限制配合的关键在于“缩小攻击面+减少干扰”：
- 只开放必要端口：比如 API 容器只需开 80/443，数据库容器禁止暴露在公网，连内网也仅允许 backend 网段访问
-
拒绝默认全通规则：很多云平台初始安全组允许全部入站，务必清空或覆盖；容器间通信优先走 Docker 自定义网络（如
backend网络），而非依赖宿主机 iptables -
结合容器网络模式使用：用
bridge模式 + 自定义子网 + 安全组，比host模式更可控；避免因共享宿主机网络栈导致限流失效或端口冲突
接入控制补上应用层最后一环
它决定合法连接进来之后“能执行什么”，防止资源限制被绕过或滥用：
- API 网关统一鉴权与速率限制：在容器前加一层网关（如 Kong、APISIX），对 /login、/pay 等高危路径做每秒请求数（QPS）限制，避免突发流量冲垮后端容器
- 数据库连接池与账号权限收敛：容器内应用连接 DB 时，用最小权限账号，连接数上限设为容器 CPU 核数 × 2～3；避免一个容器因慢查询占满全部连接
-
健康检查探针联动资源状态：Kubernetes 中配置
livenessProbe和readinessProbe，当容器因 CPU throttling 或内存压力响应超时，自动重启或摘除流量，不让“半死”容器持续消耗资源
三者联动的典型生产配置示例
以一个电商订单服务为例：
- 容器启动参数：
docker run --cpus=1.5 --memory=2g --memory-swap=2g ... - 部署在专属
order-net自定义 bridge 网络，IP 固定为172.30.2.10 - 云安全组仅允许来自
172.30.1.0/24（API 网关段）的 443 端口入向流量 - API 网关对该服务配置：单 IP 每分钟最多 300 次请求，错误率超 5% 自动熔断 60 秒
- 容器内 Spring Boot 应用配置 HikariCP 连接池：最大连接数 = 10，空闲超时 = 30s
这样，即使某次促销流量突增，也会先被网关限流，漏过的请求在容器内受 CPU/内存硬限约束，不会拖垮节点；而安全组确保数据库、缓存等下游服务不会被误连或扫描。三层不重叠、不替代，但层层兜底。
