网络容器在生产环境中的实战应用

网络容器在生产环境中的实战应用

最近接手一个老项目，团队之前把服务直接跑在物理机上，一出问题就得登录服务器查日志，扩容也得临时申请机器，效率低还容易出错。后来我们决定把整个架构迁移到基于网络容器的生产环境，用 Docker 和 Kubernetes 搭了一套稳定运行的服务体系。

刚开始担心容器网络复杂，尤其是多个服务之间通信的问题。比如订单服务要调用库存服务，以前靠内网 IP 直连，现在都跑在容器里，IP 动态分配，靠固定地址显然行不通。解决办法是引入服务发现机制，在 Kubernetes 里每个服务都有一个稳定的 DNS 名称，订单服务只需要访问 http://inventory-service:8080 就能通，背后的 Pod 重启或迁移完全无感。

配置容器网络策略

生产环境安全不能马虎。我们通过 NetworkPolicy 限制哪些容器可以互相访问。比如前端 Nginx 容器只能被外部流量访问，后端数据库容器只允许应用服务连接，其他一律拒绝。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-access-only-from-app
spec:
  podSelector:
    matchLabels:
      app: mysql-db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web-app

这个策略确保了数据库不会被意外暴露到不该访问的服务上，哪怕容器在同一集群内。

使用 Ingress 管理外部流量

对外提供服务时，我们没用 NodePort 或 LoadBalancer 直接暴露，而是统一走 Ingress。这样可以通过域名和路径做路由分流，比如 api.example.com 走后端 API，static.example.com 指向静态资源服务。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: main-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /api(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

这样一来，运维不用为每个服务单独开公网 IP，安全性和管理效率都提升了不少。

实际运行中也遇到过问题。有次更新 Ingress 配置后，前端页面加载变慢。排查发现是路径匹配写错了，导致静态资源被转发到了后端服务。改完正则后立刻恢复正常。这说明在生产环境中，每一条网络规则都得反复验证，不能想当然。

现在新服务上线，我们只需要写好容器镜像和部署配置，CI/CD 流水线自动构建、推送到仓库、更新 K8s 部署，几分钟内就能完成发布。回滚也是一键操作，再也不用半夜提心吊胆地改配置。

网络容器不是玩具，但在生产环境用好了，确实能让系统更灵活、更可靠。关键是要理解它的网络模型，别把它当成虚拟机来用。服务之间的通信方式变了，运维思路也得跟着变。