file:///C:/Users/qiaochaowen/Desktop/k8s/39%20%20%E8%B0%88%E8%B0%88Service%E4%B8%8EIngress.html 3/11
servicePort: 80
复制代码
在上面这个名叫 cafe-ingress.yaml 文件中,最值得我们关注的,是 rules 字段。
在 Kubernetes 里,这个字段叫作:IngressRule。
IngressRule 的 Key,就叫做:host。它必须是一个标准的域名格式(Fully
Qualified Domain Name)的字符串,而不能是 IP 地址。
备
注
:
Fully Qualified Domain Name
的
具体
格
式
,
可
以
参
考
RFC 3986
标
准
。
而 host 字段定义的值,就是这个 Ingress 的入口。这也就意味着,当用户访问
cafe.example.com 的时候,实际上访问到的是这个 Ingress 对象。这样,
Kubernetes 就能使用 IngressRule 来对你的请求进行下一步转发。
而接下来 IngressRule 规则的定义,则依赖于 path 字段。你可以简单地理解为,
这里的每一个 path 都对应一个后端 Service。所以在我们的例子里,我定义了两
个 path,它们分别对应 coffee 和 tea 这两个 Deployment 的 Service(即:
coffee-svc 和 tea-svc)。
通过上面的讲解,不难看到,所谓 Ingress 对象,其实就是 Kubernetes 项目
对“反向代理”的一种抽象。
一个 Ingress 对象的主要内容,实际上就是一个“反向代理”服务(比如:
Nginx)的配置文件的描述。而这个代理服务对应的转发规则,就是
IngressRule。
这就是为什么在每条 IngressRule 里,需要有一个 host 字段来作为这条
IngressRule 的入口,然后还需要有一系列 path 字段来声明具体的转发策略。这
其实跟 Nginx、HAproxy 等项目的配置文件的写法是一致的。
而有了 Ingress 这样一个统一的抽象,Kubernetes 的用户就无需关心 Ingress 的
具体细节了。
在实际的使用中,你只需要从社区里选择一个具体的 Ingress Controller,把它部
署在 Kubernetes 集群里即可。
然后,这个 Ingress Controller 会根据你定义的 Ingress 对象,提供对应的代理
能力。目前,业界常用的各种反向代理项目,比如 Nginx、HAProxy、Envoy、
Traefik 等,都已经为 Kubernetes 专门维护了对应的 Ingress Controller。
接下来,我就以最常用的 Nginx Ingress Controller 为例,在我们前面用
kubeadm 部署的 Bare-metal 环境中,和你实践一下 Ingress 机制的使用过程。
评论0
最新资源