本文是有态度马甲的第185篇原创。
本文记录了k8s中核心对象Ingress的产生背景和实现机制。
我们都知道k8s Service是一种将Pods通过网络暴露出来的抽象，每个服务定义了一组与Pod有关的端点，
1. Service是物理存在的吗？
Pod是物理存在的实体，而Service是逻辑存在的规则， 每一个服务被以“service.ns.svc.cluster.domain”格式分配了DNS A或者AAAA记录。
当你创建一个服务，k8s仅仅是在集群的网络路由表增加一条记录（kube-proxy去做这个工作）。
流量经过service 规则进入指定的Pod，这一过程起重要作用的linux内核。
- ClusterIP： 默认，以集群内Ip的形式提供集群内的可访问性
- NodePort：在每个机器节点的静态端口上对外暴露了服务
- Loadbalancer： 外部负载均衡器
这不明摆了，常规的对外暴露服务的方式只有 NodePort吗？
NodePort类型建立在ClusterIP服务类型之上， 意味着你创建了NodePort类型服务，k8s自动创建了ClusterIP服务。从这个思路看，nodeport是clusterip的积木套壳。
外部客户端---> 任意节点（NodePort）---> ClusterIP服务---> Pod
1.1 NodePort 服务类型有几个缺陷：
① NodePort形式的服务 没有跨节点的负载均衡能力， 有的节点忙着导流，有的闲得蛋疼
② 能暴露的服务数量受限于节点的可用端口
③ 这姑且不算缺陷吧： 引流方式基于节点端口，位于osi网络模型的4层， 人类感知不明显。
2. 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服务。
!!! Ingress nginx本身不能解决节点间负载均衡问题，注意还需前置负载提供跨节点负载均衡能力。
2.1 快速验证Ingress
k8s ingress官方 给了一个通过Ingress引流到"hello world“ 这样的服务，但是它的服务竟然采用了NodePort形式，这都NodePort了，还要你Ingress作甚。
我的Demo是以默认的ClusterIP形式快速启动了Nginx服务，
已经显示nginx-svc是 ClusterIP类型的应用服务。
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.com路由到nginx-svc服务：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
spec:
rules:
- host: hello.nginx.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginx-svc
port:
number: 80
产生一个Ingress核心对象
aladdin@bogon ~ % kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
example-ingress nginx hello.nginx.com 192.168.58.2 80 24h
准备工作就做完了。
启动minikube tunnel, 然后在新的终端执行curl 127.0.0.1 -H "host:hello.nginx.com" 你会看到nginx服务的Welcome to nginx!输出。
That's All, Ingress 就是如此暴露服务引流的.
2.2 核心对象：nginx pod && nodeport service
Ingress相关的核心对象默认被安装在Ingress-nginx命名空间下，我们接着验证Ingress架构图中出现的组件:
- Deployment/Pod：
ingress-nginx-controller是nginx deployment，ingress-nginx-controller-56d7c84fd4-znrvq是其中的Nginx Pod - Service： 以NodePort形式对外暴露的
ingress-nginx-controller服务
根据我们的猜想：
这个Nginx Pod受ingress-nginx-controller服务(NodePort类型)控制对外暴露路由服务， 对内引流到backend Service。
验证如下：
3. 都是积木的套路
从上面可以看出：
nodeport服务类型是 clusterip之上的积木套壳，通过在节点上打通解决了clusterip只能用于集群内访问的问题。
ingress需要搭配前置负载均衡，
两者配合一举解决了NodePort暴露服务的一些缺陷， 通过Ingress暴露服务既能有效节约节点端口，又有节点负载均衡能力（搭配前置负载），又是广大码农喜闻乐见的7层协议， 悠哉快哉。
核心对象是 ingress-nginx-controller deployment 和对外暴露的nodeport服务。
但是归根到底，Ingress-nginx底层还是NodePort服务和ClusterIP服务的积木组合， 实在是高啊。
