k8s 实现 nginx-ingress 通过统一 IP 访问服务无缝对接生产上游 Nginx

前言

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

• NodePort
• LoadBalancer
• Ingress

这三种方案中,考虑到NodePort是直接开放外部端口,这样需要管理所有服务开放的端口,跟我们原本使用k8s的初衷略有违背,我们初衷是希望对外是服务访问,对内可以不针对每个服务所在的服务器以及端口进行管理,在降低运维压力同时,实现负载均衡,因此一般不选择这种方案实现对外暴露服务,而LoadBalancer需要云端服务支持,就是一般是需要付费,考虑成本也是不在参考范围里面的,因此最后的Ingress这根稻草,在安全与成本的方向的考虑,满足了大部分人的需求,基础部署参考:helm3.0部署nginx-ingress.

Ingress 简介

在kubernetes集群中，我们知道service和pod的ip仅在集群内部访问。如果外部应用要访问集群内的服务，集群外部的请求需要通过负载均衡转发到service在Node上暴露的NodePort上，然后再由kube-proxy组件将其转发给相关的pod。 而Ingress就是为进入集群的请求提供路由规则的集合，通俗点就是提供外部访问集群的入口，将外部的HTTP或者HTTPS请求转发到集群内部service上。

Ingress访问原理

Ingress代理的并不是pod的service，而是pod，之所以在配置的时候是配置的service，是为了通过service来获取所有pod的信息。

访问原理如下：

Ingress实现生产环境服务暴露方案

Ingress通常使用 http://domain/path 的方式暴露服务,对于生产环境,是已经配置了一层Nginx代理,通过 80/443 端口对外开放应用入口

具体访问原理如下:

当服务部署到k8s之后,能不能用原本的方案呢?

方案一：使用Nginx-Ingress实现反向代理，替换原来的Nginx
具体实现逻辑如下：

这个需要一个前提条件是由于是生产环境，域名是必须能够公网IP进行DNS解析，也就是Nginx-Ingress所在的服务器必须进行DNS解析才可以实现直接对外暴露服务，但是nginx-ingress是通过k8s部署，在正常情况下，我们都不会指定节点去部署，因为指定节点部署就可能会出现单点故障问题，且不能基于k8s进行动态分配服务器，也就是DNS解析这个除非全解析，不然不靠谱，鉴于时间问题以及风险问题，这种模式不考虑。

方案二：使用Nginx-Ingress实现反向代理，上游对接原有的Nginx服务
具体实现逻辑如下:

k8s实现nginx-ingress通过统一IP访问服务无缝对接生产上游Nginx

为者常成，行者常至