Kubernetes服务暴露与CoreDNS配置实战指南

1. Kubernetes服务暴露基础解析

在容器化部署环境中，服务暴露是连接集群内外流量的关键环节。我最初接触Kubernetes服务暴露时，常常混淆各种Service类型的使用场景，直到在生产环境踩过几次坑后才真正理解其设计哲学。

ClusterIP作为默认服务类型，其工作原理类似于小区内部的楼栋编号。当我们在Kubernetes中创建Deployment时，每个Pod都会获得独立的IP地址，就像小区里的每户人家都有独立门牌。但直接使用Pod IP存在明显问题——当Pod发生重启或扩容时，IP地址会变化。这就好比住户经常搬家，快递员根本无法通过固定地址找到收件人。ClusterIP通过创建虚拟IP（VIP）解决了这个问题，它像小区的物业管理中心，外部请求只需发送到这个固定地址，由kube-proxy负责将流量转发到具体的Pod实例。

NodePort服务则像是小区对外开放的接待处。它在所有Worker节点上开放相同的端口（默认范围30000-32767），外部客户端可以通过任意节点的IP+端口访问服务。但实际运维中发现，这种方案存在单点故障风险——如果客户端固定连接某个Node的IP，当该节点宕机时服务就会中断。更合理的做法是在前端配置负载均衡器，将流量分发到多个Node节点。

LoadBalancer服务在云环境下最为实用。以AWS为例，当我们创建LoadBalancer类型的服务时，Kubernetes会自动调用云厂商的API创建ELB，并配置相应的监听规则。但需要注意成本问题——每个LoadBalancer服务都会创建独立的云负载均衡器资源，在中小规模集群中可能产生不必要的费用。此时可以考虑使用Ingress配合单个LoadBalancer来统一管理入口流量。

2. Ingress控制器深度配置

2.1 Nginx Ingress部署优化

在主流Ingress控制器中，Nginx Ingress以其高性能和灵活性成为许多团队的首选。但默认安装参数往往不能满足生产需求，这里分享几个调优经验：

首先是资源限制配置。通过helm安装时建议设置资源请求和上限：

yaml复制controller:
  resources:
    requests:
      cpu: 100m
      memory: 128Mi