在 Kubernetes 中, Service 有三种对外暴露的方法,但是由于每个 Service 都要有一个负载均衡的服务,所以采用 Service 的话,会造成既浪费成本又高的现象.对于用户来说,我更希望的是,能有一个全局的负载均衡器,然后我只需要通过访问 URL 就可以把请求转发给不同的后端 Service ,从而可以访问到界面.而不是每个 Service 都需要负载均衡.
而这,就引出了 Ingress :它就是全局的,为了代理不同后端 Service 而设置的负载均衡服务.
来说个例子:假设我现在有一个站点: https://cafe.example.com ,其中, https://cafe.example.com/coffee ,对应的是"咖啡点餐系统",而 https://cafe.example.com/tea ,对应的则是"茶水点餐系统",而这两个系统,分别由名叫 coffee 和 tea 这样两个 Deployment 来提供服务.
那么问题来了,我如何使用 Kubernetes 中的 Ingress 来创建一个统一的负载均衡器,从而实现当用户访问不同的域名时,能够访问到不同的 Deployment 呢?
其实很简单,写个 YAML 文件就好了,内容如下:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: cafe-ingress
spec:
tls:
- hosts:
- cafe.example.com
secretName: cafe-secret
rules:
- host: cafe.example.com
http:
paths:
- path: /coffee
backend:
serviceName: coffee-svc
servicePort: 80
- path: /tea
backend:
serviceName: tea-svc
servicePort: 80
在上面这个名叫 cafe-ingress.yaml 文件中,最值得关注的就是在 rules 字段,这个字段在 Kubernetes 中,叫做: IngressRule .
IngressRule 的 Key ,就叫做: host ,它必须是一个标准的域名格式的字符串,而不能是 IP 地址.而 host 字段定义的值,就是 Ingress 的入口.也就是说,当用户访问 cafe.example.com 时,实际上访问的就是这个 Ingress 对象,这样 Kubernetes 就能够使用 IngressRule 来对实际请求进行下一步转发.
而接下来 IngressRule 规则的定义,则依赖于 path 字段.你可以看到,在上面的 YAML 文件中,定义了两个 path ,分别对应 coffee 和 tea 这两个 Deployment 的 Service (即: coffee-svc 和 tea-svc ).
如果你了解过 Nginx 的话,到这儿应该就很容易理解了.所谓 Ingress 对象,其实就是 Kubernetes 项目对"反向代理"的一种抽象,一个 Ingress 对象的主要内容,实际上就是一个"反向代理"服务的配置文件的描述,而这个代理服务对应的转发规则,就是 IngressRule.
所以这也是为什么在每条 IngressRule 中,需要有一个 host 字段来作为这条 IngressRule 的入口,还需要有一系列 path 字段来声明具体的转发策略.如果你对 Nginx , HAproxy 等项目的配置文件熟悉的话,你会发现其实它们的写法是一致的.
所以,有了 Ingress 这样一个统一的抽象, Kubernetes 的用户就无需关心 Ingress 的具体细节了,在实际使用中,只需要选择一个具体的 Ingress Controller ,把它部署在 Kubernetes 集群里就可以了.然后接下来的事情,就交给它去做就OK了,你要做的就是去写相关的 YAML 文件即可.(发现没有,又降低了使用难度)
不知道你有没有一个疑问,就是如果我的请求没有匹配到任何一条 IngressRule ,那么界面会显示什么呢.
你可以想想,当你访问一个网址的时候,它会如何给你反应?没错,就是 404 界面.
在 Ingress Controller 中,你也可以通过 Pod 启动命令中 -default-backend-service 参数,来设置一条默认规则.这样,任何匹配失败的请求,都会被转发到你指定的 Service ,这样你就可以通过部署一个专门的 Pod ,来为用户返回自定义的 404 界面了.
以上内容来自我学习<深入剖析Kubernetes>专栏文章之后的一些见解,有偏颇之处,还望指出.
感谢您的阅读~