【重识云原生】第六章容器基础6.4.11.1节——Ingress综述

本文链接：https://blog.csdn.net/junbaozi/article/details/127710298

本文详细介绍了Kubernetes中的Ingress概念及其工作原理。包括Ingress的基本介绍、组成部分（Ingress与Ingress Controller）、配置示例以及Ingress如何帮助实现服务的外部访问。适合希望了解或使用K8s Ingress的读者。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1. Ingress概述

1.1 Ingress的简介

service的作用体现在两个方面：

对集群内部，它不断跟踪pod的变化，更新endpoint中对应pod的对象，提供了ip不断变化的pod的服务发现机制；
对集群外部，他类似负载均衡器，可以在集群内外部对pod进行访问。

在Kubernetes中，Pod的IP地址和service的ClusterIP仅可以在集群网络内部做用，对于集群外的应用是不可见的。为了使外部的应用能够访问集群内的服务，Kubernetes目前提供了以下几种方案：

NodePort：将service暴露在节点网络上，NodePort背后就是Kube-Proxy，Kube-Proxy是沟通service网络、Pod网络和节点网络的桥梁。测试环境使用还行，当有几十上百的服务在集群中运行时，NodePort的瑞口管理就是个灾难。因为每个端口只能是一种服务，端口范围只能是 30000-32767。
LoadBalancer：通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种用法仅用于在公有云服务提供商的云平台上设置Servic的场景。受限于云平台，且通常在云平台部署LoadBalancer还需要额外的费用。
Ingress：只需一个或者少量的公网IP和LB，即可同时将多个HTTP服务暴露到外网，七层反向代理。可以简单理解为service的service，它其实就是一组基于域名和URL路径，把用户的请求转发到一个或多个service的规则。

Ingress解决的是新的服务加入后，域名和服务的对应问题，基本上是一个ingress的对象，通过yaml进行创建和更新进行加载。工作机制大致可以用下图表示：

实际上，ingress相当于一个7层的负载均衡器，是k8s对反向代理的一个抽象。大概的工作原理也确实类似于Nginx，可以理解成在 Ingress 里建立一个个映射规则 , ingress Controller 通过监听 Ingress这个api对象里的配置规则并转化成 Nginx 的配置（kubernetes声明式API和控制循环） , 然后对外部提供服务。

1.2 Ingress的组成

Ingress包含了两大组件Ingress Controller和Ingress。

1.2.1 Ingress组件

ingress是一个API对象，通过yaml文件来配置，ingress对象的作用是定义请求如何转发到service的规则，可以理解为配置模板。 ingress通过http或https暴露集群内部service，给service提供外部URI、负载均衡、SSL/TLS能力以及基于域名的反向代理。ingress要依靠ingress-controiler来具体实现以上功能。

简单来说，ingress-controller才是负责具体转发的组件，通过各种方式将它暴露在集群入口，外部对集群的请求流量会先到ingress-controller，而ingress对象是用来告诉ingress-controller该如何转发请求，比如哪些域名哪些path要转发到哪些服务等等。

Ingress 格式示例：

apiVersion: extensions/v1beta1 
kind: Ingress 
metadata: 
  name: test-ingress 
spec: 
  rules: 
    - http: 
      paths: 
        - path: /testpath 
          backend: 
            serviceName: test 
            servicePort: 80

每个 Ingress 都需要配置 rules，目前 Kubernetes 仅支持 http 规则。上面的示例表示请求 /testpath 时转发到服务 test 的 80 端口。

1.2.2 ingress-controller组件

ingress-controller是具体实现反向代理及负载均衡的程序，对ingress定义的规则进行解析，根据配置的规则来实现请求转发。 ingress-controller并不是k8s自带的组件，实际上ingess-controller只是一个统称，用户可以选择不同的ingress-controller实现，目前，由k8s维护的ingress-controller只有google云的GCE与ingress-nginx两个，其他还有很多第三方维护的ingress-controller，比如Contour, Haproxy, trafik, Istio，具体可以参考官方文档。但是不管哪一种ingress-controller，实现的机制都大同小异，只是在具体配置上有差异，ingress controller核心是一个deployment，需要编写的yaml有：Deployment, Service, ConfigMap, ServiceAccount（Auth），其中service的类型可以是NodePort或者LoadBalancer。一般来说，ingress-controller的形式都是一个pod，里面跑着demon程序和反向代理程序。daemon负责不断监控集群的变化，根据ingress对象生成配置并应用新配置到反向代理，比如ingress-nginx就是动态生成nginx配置，动态更新upstreanm，并在需要的时候reload程序应用新配置。为了方便，后面的例子都以k8s官方维护的ingress-nginx为例。 Ingress-Nginx github 地址： GitHub - kubernetes/ingress-nginx: Ingress-NGINX Controller for Kubernetes

Ingress-Nginx 官方网站： Welcome - NGINX Ingress Controller

1.3 Ingress的工作原理

Ingress Controller是将Ingress这种变化生成一段Nginx的配置，然后将这个配置通过Kubernetes API写到Nginx的Pod中，然后reload.（注意：写入 nginx.conf 的不是service的地址，而是service backend 的 pod 的地址，避免在 service 在增加一层负载均衡转发）。

从上图中可以很清晰的看到，实际上请求进来还是被负载均衡器拦截，比如 nginx，然后 Ingress Controller 通过跟 Ingress 交互得知某个域名对应哪个 service，再通过跟 kubernetes API 交互得知 service 地址等信息；综合以后生成配置文件，实时写入负载均衡器，然后负载均衡器 reload 该规则便可实现服务发现，即动态映射：

ingress-controller通过和 kubernetes APIServer交互，动态的去感知集群中ingress规则变化；
然后读取它，按照自定义的规则，规则就是写明了哪个域名对应哪个service，生成一段nginx配置；
再写到nginx-ingress-controller的pod里，这个ingres-controller的pod里运行着一个Nginx服务，控制器会把生成的nginx置写入/etc/nginx.conf文件中；
最后reload一下使配置生效。以此达到域名区分配置和动态更新的作用。

客户端一般会把请求发送到负载均衡器上由负载均衡器转发到ingress控制所在的node节点上目的减小Node节点的负载压力。ingress控制器会根据ingress资源对象的配置转发请求到对应的service；service会根据端点，把请求转发到关联的Pod。

在使用普通的Service时，集群中每个节点的kube-proxy在监听到Service和Endpoints的变化时，会动态的修改相关的iptables的转发规则。客户端在访问时通过iptables设置的规则进行路由转发达到访问服务的目的。

而Ingress则跳过了kube-proxy这一层，通过Ingress Controller中的代理配置进行路由转发达到访问目标服务的目的。实际上可以把IngressController看做一个拥有默认处理后端的代理，根据Ingress资源的配置动态修改代理的配置文件，以实现按照规则转发请求的功能。