在k8s中，客户端访问服务的链路流程，ingress---＞service---＞deployment---＞pod---＞container

                                                             图片来源：自己画的

ingress是一个API资源。

客户端访问ingress的不同url

ingress给客户端返回不同的服务。

就和nginx反向代理服务器一样。

根据不同的url，给客户端返回不同的服务。

------------------------------------------------------------------

ingress的核心是class+rules

class是控制器，典型实例是nginx

rules是反向代理的规则，典型用法是rules="/path=svc:port"

ingress资源文件中，顶级字段.spec的内容如下：

spec:ingressClassName: nginxrules:- http:paths:- pathType: Prefixpath: /hellobackend:service:name: beautfulport:number: 3579

客户端访问这个url：

https://ingress_ip/hello

ingress会给客户端返回

一个叫“beautyful”的服务.

ingress是如何拿到这个"beautyful"服务的。

是找nodeport拿的。

ingress转发https://ingress_ip/hello

的请求时，

转发的指向是服务名"beautyful"+端口号"3579"

而nodeport就是这个服务，

它的名字就叫"beautyful"

它监听的端口号也就是"3579"

如图是nodeport服务的资源文件：

---kind: ServiceapiVersion: v1metadata:name: beautyfulspec:type: NodePortselector:app: shi-is-beautyfulports:- name: nomatterprotocol: TCPport: 3579targetPort: http

nodeport也是个中介

nodeport监听的是3579端口

然后又转发给一个叫http的端口

接收转发的服务是deployment

nodeport是怎么联系到这个deployment的？

通过nodeport资源文件里面声明的selector:

这个selector就是找后端应用的标签

后端有一个deployment带这个标签

那他们就能搭上线

进行通信

然后deployment通过replicas动态自动化管理后端的pods

后端pod里面跑的容器，来提供服务。