admin管理员组

文章数量:1031589

Ingress,你这个老6

hello，本文是有态度马甲的第185篇原创， 有趣指数5颗星，有用指数4颗星。

本文记录了k8s中核心对象Ingress的产生背景和实现机制。

我们都知道k8s Service是一种将Pods通过网络暴露出来的抽象，每个服务定义了一组有关Pod的端点， Service有几种类型

  • ClusterIP： 默认，以集群内Ip的形式提供集群内的可访问性
  • NodePort：在每个节点的静态端口上对外暴露了服务
  • LoadBalancer： 外部负载均衡器

这不明摆了，常规的对外暴露服务的方式只有NodePort吗？

NodePort类型建立在ClusterIP服务类型之上， 意味着你创建了NodePort类型服务，k8s自动创建了ClusterIP 服务。

外部客户端---> 任意节点（NodePort）---> ClusterIP服务---> Pod

有几个缺陷：

  • NodePort形式的服务没有跨节点的负载均衡能力， 有的节点忙着导流，有的闲得蛋疼
  • 能暴露的服务数量受限于节点的可用端口
  • 这姑且不算缺陷吧： 引流方式基于节点端口，位于osi网络模型的4层， 人类感知不明显。

Ingress号称是一种智能路由，表象上Ingress从集群外部将HTTP和HTTPS请求路由引流到k8s集群中的Service。

一个典型的数据流如上图。

曾几何时，我以为Ingress是高深的、开天辟地的网络引流方案。

后面我深究一丢丢，发现k8s Ingress 其实是个老6， 它对外暴露服务的方式其实很贼，用的还是现成技能的积木。

Ingress 本质上是先在集群内产生了负载均衡服务(nginx pod), 这个k8s服务在集群内与其他服务必然可以互访。

然后咋们目标不是要对外暴露服务吗？ 那我这个Ingress Nginx服务就作为一个流量入口，我这个服务就使用NodePort形式对外暴露自身， 对内通过nginx天生的路由能力来引流到后端的Service。

下面是Ingress-nginx的请求流图:

注意流量从 client---> nginx pod ---> service Pod, 

Ingress记录了注册到Ingress上服务的路由规则，Ingress-Nginx Controller是本次业务的声明式核心控制器，确保产生满足这一规则的NodePort类型的nginx服务，注意还需前置负载提供跨节点负载均衡能力。

我们找个demo快速验证一下吧。

k8s ingress官方[1] 给了一个通过Ingress引流到"hello world“ 这样的演示服务，但是它的服务竟然采用了NodePort形式，这都NodePort了，还要你Ingress作甚。

我的Demo是以默认的ClusterIP形式快速启动了Nginx服务，

已经显示nginx-svc是ClusterIP类型的服务。

代码语言：javascript代码运行次数：0运行复制
aladdin@bogon ~ % kubectl get  svc
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1      <none>        443/TCP   7d
nginx-svc    ClusterIP   10.103.46.57   <none>        80/TCP    24h

之后使用Ingress配置通过host:hello.nginx路由到nginx-svc服务：

代码语言：javascript代码运行次数：0运行复制
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: hello.nginx
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-svc
            port:
              number: 80

产生一个Ingress核心对象

代码语言：javascript代码运行次数：0运行复制
aladdin@bogon ~ % kubectl get  ingress
NAME              CLASS   HOSTS             ADDRESS        PORTS   AGE
example-ingress   nginx   hello.nginx   192.168.58.2   80      24h

准备工作就做完了。

启动minikube tunnel, 然后在新的终端执行curl  127.0.0.1 -H  "host:hello.nginx" 你会看到nginx服务的Welcome to nginx!输出， That's All， Ingress就是这么暴露引流的。

Ingress相关的核心对象默认被安装在Ingress-nginx命名空间下，我们接着验证Ingress架构图中出现的组件:

上图中出现了两种核心对象：

  • Deployment/Pod： ingress-nginx-controller-56d7c84fd4-znrvq其实就是Nginx Pod
  • Service： 以NodePort形式的ingress-nginx-controller Service

根据我们的猜想：

这个Nginx Pod受ingress-nginx-controller Service(NodePort)控制对外暴露路由服务， 对内引流到集群内Service。

验证如下：

Ingress-nginx分为两大块：Ingress规则和Ingress-nginx controller，  

两者配合一举解决了NodePort暴露服务的一些缺陷： 通过Ingress暴露服务既能有效节约节点端口，又有负载均衡能力，又是广大码农喜闻乐见的7层协议来路由分流， 悠哉快哉。

但是归根到底，Ingress-nginx底层还是NodePort服务和 ClusterIP服务的积木组合， 实在是高啊。

参考资料

[1] 

k8s ingress官方: /

本篇内容为原创，读者可结合图片探索源码和官方， 欢迎反馈 ~。。~。

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-03-28，如有侵权请联系 cloudcommunity@tencent 删除负载均衡对象服务集群路由

Ingress,你这个老6

hello，本文是有态度马甲的第185篇原创， 有趣指数5颗星，有用指数4颗星。

本文记录了k8s中核心对象Ingress的产生背景和实现机制。

我们都知道k8s Service是一种将Pods通过网络暴露出来的抽象，每个服务定义了一组有关Pod的端点， Service有几种类型

  • ClusterIP： 默认，以集群内Ip的形式提供集群内的可访问性
  • NodePort：在每个节点的静态端口上对外暴露了服务
  • LoadBalancer： 外部负载均衡器

这不明摆了，常规的对外暴露服务的方式只有NodePort吗？

NodePort类型建立在ClusterIP服务类型之上， 意味着你创建了NodePort类型服务，k8s自动创建了ClusterIP 服务。

外部客户端---> 任意节点（NodePort）---> ClusterIP服务---> Pod

有几个缺陷：

  • NodePort形式的服务没有跨节点的负载均衡能力， 有的节点忙着导流，有的闲得蛋疼
  • 能暴露的服务数量受限于节点的可用端口
  • 这姑且不算缺陷吧： 引流方式基于节点端口，位于osi网络模型的4层， 人类感知不明显。

Ingress号称是一种智能路由，表象上Ingress从集群外部将HTTP和HTTPS请求路由引流到k8s集群中的Service。

一个典型的数据流如上图。

曾几何时，我以为Ingress是高深的、开天辟地的网络引流方案。

后面我深究一丢丢，发现k8s Ingress 其实是个老6， 它对外暴露服务的方式其实很贼，用的还是现成技能的积木。

Ingress 本质上是先在集群内产生了负载均衡服务(nginx pod), 这个k8s服务在集群内与其他服务必然可以互访。

然后咋们目标不是要对外暴露服务吗？ 那我这个Ingress Nginx服务就作为一个流量入口，我这个服务就使用NodePort形式对外暴露自身， 对内通过nginx天生的路由能力来引流到后端的Service。

下面是Ingress-nginx的请求流图:

注意流量从 client---> nginx pod ---> service Pod, 

Ingress记录了注册到Ingress上服务的路由规则，Ingress-Nginx Controller是本次业务的声明式核心控制器，确保产生满足这一规则的NodePort类型的nginx服务，注意还需前置负载提供跨节点负载均衡能力。

我们找个demo快速验证一下吧。

k8s ingress官方[1] 给了一个通过Ingress引流到"hello world“ 这样的演示服务，但是它的服务竟然采用了NodePort形式，这都NodePort了，还要你Ingress作甚。

我的Demo是以默认的ClusterIP形式快速启动了Nginx服务，

已经显示nginx-svc是ClusterIP类型的服务。

代码语言：javascript代码运行次数：0运行复制
aladdin@bogon ~ % kubectl get  svc
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1      <none>        443/TCP   7d
nginx-svc    ClusterIP   10.103.46.57   <none>        80/TCP    24h

之后使用Ingress配置通过host:hello.nginx路由到nginx-svc服务：

代码语言：javascript代码运行次数：0运行复制
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: hello.nginx
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-svc
            port:
              number: 80

产生一个Ingress核心对象

代码语言：javascript代码运行次数：0运行复制
aladdin@bogon ~ % kubectl get  ingress
NAME              CLASS   HOSTS             ADDRESS        PORTS   AGE
example-ingress   nginx   hello.nginx   192.168.58.2   80      24h

准备工作就做完了。

启动minikube tunnel, 然后在新的终端执行curl  127.0.0.1 -H  "host:hello.nginx" 你会看到nginx服务的Welcome to nginx!输出， That's All， Ingress就是这么暴露引流的。

Ingress相关的核心对象默认被安装在Ingress-nginx命名空间下，我们接着验证Ingress架构图中出现的组件:

上图中出现了两种核心对象：

  • Deployment/Pod： ingress-nginx-controller-56d7c84fd4-znrvq其实就是Nginx Pod
  • Service： 以NodePort形式的ingress-nginx-controller Service

根据我们的猜想：

这个Nginx Pod受ingress-nginx-controller Service(NodePort)控制对外暴露路由服务， 对内引流到集群内Service。

验证如下：

Ingress-nginx分为两大块：Ingress规则和Ingress-nginx controller，  

两者配合一举解决了NodePort暴露服务的一些缺陷： 通过Ingress暴露服务既能有效节约节点端口，又有负载均衡能力，又是广大码农喜闻乐见的7层协议来路由分流， 悠哉快哉。

但是归根到底，Ingress-nginx底层还是NodePort服务和 ClusterIP服务的积木组合， 实在是高啊。

参考资料

[1] 

k8s ingress官方: /

本篇内容为原创，读者可结合图片探索源码和官方， 欢迎反馈 ~。。~。

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-03-28，如有侵权请联系 cloudcommunity@tencent 删除负载均衡对象服务集群路由

本文标签： Ingress你这个老6

版权声明：本文标题：Ingress,你这个老6 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://it.en369.cn/jiaocheng/1747862468a2219212.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。