1. 为什么需要Service和Ingress刚开始接触Kubernetes时很多新手都会遇到这样的困惑明明已经创建了Pod为什么还是无法访问我的应用这个问题背后其实涉及Kubernetes网络模型的两个核心概念——Service和Ingress。在Kubernetes中Pod是最小的部署单元但它们具有以下特点生命周期短暂随时可能被销毁重建IP地址动态变化每次重建都会获得新IP单个Pod难以承载高并发流量假设你部署了一个Nginx Pod虽然可以通过kubectl port-forward临时访问但这显然不是生产环境可用的方案。Service的出现就是为了解决这些痛点。1.1 Service的核心价值Service本质上是一个稳定的网络端点Endpoints它通过标签选择器Label Selector动态关联后端的Pod集合。无论背后的Pod如何变化Service的访问地址始终保持不变。这就像给餐厅订餐时你只需要记住外卖平台的统一号码而不需要关心具体是哪位厨师在做菜。Service的三种主要类型ClusterIP默认集群内部可访问的虚拟IPNodePort通过节点端口暴露服务LoadBalancer通过云厂商的负载均衡器暴露服务1.2 Ingress的进阶能力虽然Service已经解决了内部访问的问题但在对外暴露服务时我们还需要考虑基于域名的路由HTTPS证书管理流量调度策略七层负载均衡Ingress就是专门处理这些需求的API对象。它相当于一个智能路由网关配合Ingress Controller如Nginx、Traefik实现高级流量管理功能。可以理解为Ingress是Service的增强版网关。2. Service的深度解析与实践2.1 ClusterIP服务详解ClusterIP是最基础的Service类型其YAML定义示例如下apiVersion: v1 kind: Service metadata: name: my-web spec: selector: app: nginx # 关联所有带有appnginx标签的Pod ports: - protocol: TCP port: 80 # Service暴露的端口 targetPort: 80 # Pod上的实际端口关键点说明selector定义了如何选择后端Pod创建后会自动分配一个集群内可访问的虚拟IPCLUSTER-IP通过service-name.namespace.svc.cluster.local域名也可访问实际测试时可以这样验证# 创建一个临时Pod作为客户端 kubectl run -it --rm test-pod --imagealpine -- sh # 在临时Pod内测试访问 wget -qO- http://my-web.default.svc.cluster.local2.2 NodePort的生产实践NodePort类型的Service会在每个Worker节点上开放一个静态端口默认范围30000-32767外部可以通过NodeIP:NodePort访问服务。典型配置apiVersion: v1 kind: Service metadata: name: my-web-nodeport spec: type: NodePort selector: app: nginx ports: - port: 80 targetPort: 80 nodePort: 31000 # 可选不指定则随机分配注意事项生产环境通常不会直接使用NodePort因为需要手动管理端口分配缺乏高级路由能力需要额外处理节点故障转移更推荐使用Ingress LoadBalancer的组合方案2.3 服务发现机制揭秘Kubernetes内置的DNS服务通常是CoreDNS会为每个Service创建DNS记录格式为service-name.namespace.svc.cluster.local这意味着在集群内部应用之间可以通过服务名直接通信。例如前端应用访问后端API时只需配置连接地址为http://backend-service/api无需关心后端Pod的实际IP。重要提示如果遇到服务无法解析的情况按以下步骤排查检查CoreDNS Pod是否正常运行验证/etc/resolv.conf中的search域配置使用nslookup或dig命令测试DNS解析3. Ingress实战指南3.1 安装Ingress Controller以Nginx Ingress为例安装命令如下kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.1/deploy/static/provider/cloud/deploy.yaml安装完成后检查状态kubectl get pods -n ingress-nginx -l app.kubernetes.io/componentcontroller3.2 基础Ingress配置一个典型的Ingress定义如下apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: demo.example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80 - path: / pathType: Prefix backend: service: name: web-service port: number: 80这个配置实现了将demo.example.com/api路由到后端api-service其他请求路由到web-service自动处理路径重写通过annotation配置3.3 HTTPS安全配置为Ingress配置HTTPS需要先准备证书然后创建Secretkubectl create secret tls example-tls \ --certpath/to/cert.crt \ --keypath/to/cert.key然后在Ingress中引用spec: tls: - hosts: - demo.example.com secretName: example-tls rules: - host: demo.example.com ...进阶技巧使用cert-manager可以自动管理证书续期配置HSTS增强安全性设置适当的SSL协议和加密套件4. 生产环境最佳实践4.1 服务网格集成模式在微服务架构中通常会结合Service Mesh如Istio实现更精细的流量管理apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v1 weight: 90 - destination: host: reviews subset: v2 weight: 10这种配置可以实现灰度发布按权重分流熔断机制细粒度超时控制分布式追踪4.2 性能优化技巧连接池管理annotations: nginx.ingress.kubernetes.io/upstream-keepalive-connections: 100 nginx.ingress.kubernetes.io/upstream-keepalive-timeout: 60启用gzip压缩annotations: nginx.ingress.kubernetes.io/enable-gzip: true调整缓冲区大小annotations: nginx.ingress.kubernetes.io/proxy-buffer-size: 16k4.3 监控与告警建议监控以下关键指标Ingress Controller的请求延迟和错误率后端服务的响应时间TCP连接数SSL握手性能Prometheus示例配置- job_name: nginx-ingress metrics_path: /metrics static_configs: - targets: [ingress-nginx-controller-metrics:10254]5. 常见问题排查指南5.1 服务无法访问排查流程检查Service的后端Endpoint是否正常kubectl get endpoints service-name验证网络策略NetworkPolicy是否阻止了流量kubectl get networkpolicy测试从客户端Pod直接访问目标Pod IPkubectl run -it --rm test-pod --imagealpine -- sh wget -qO- http://pod-ip检查kube-proxy日志kubectl logs -n kube-system -l k8s-appkube-proxy5.2 Ingress特有问题处理问题现象配置了Ingress但返回404排查步骤确认Ingress Controller Pod运行正常检查Ingress资源是否被正确识别kubectl get ingress查看Ingress Controller日志kubectl logs -n ingress-nginx ingress-controller-pod验证域名解析是否正确问题现象HTTPS证书不生效排查步骤确认Secret中的证书和密钥格式正确kubectl get secret tls-secret -o jsonpath{.data.tls\.crt} | base64 -d检查证书是否过期验证Ingress的tls配置是否正确引用Secret5.3 跨命名空间访问问题当服务需要跨命名空间访问时使用完全限定域名FQDNservice-name.namespace.svc.cluster.local例如从default命名空间访问test命名空间的服务apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: cross-ns-ingress spec: rules: - host: cross.example.com http: paths: - path: / backend: service: name: test-service.test.svc.cluster.local port: number: 80关键点需要确保网络策略允许跨命名空间通信目标服务需要暴露ClusterIP考虑使用ExternalName类型的Service作为桥梁