[Kubernetes]说说 Service 与 Ingress

在 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>专栏文章以后的一些看法,有偏颇之处,还望指出.
感谢您的阅读~