Kubernetes网络原理——Ingress对象

定义

全局的、为了代理不同后端 Service 而设置的负载均衡服务，就是 Kubernetes 里的Ingress 服务。

所以，Ingress 的功能其实很容易理解：所谓 Ingress，就是 Service 的“Service”。

假如我现在有这样一个站点：https://cafe.example.com，其中https://cafe.example.com/coffee对应的是“咖啡点餐系统”，而https://cafe.example.com/tea对应的是茶水点餐系统，这两个系统，分别由名叫coffee和tea两个Deployment来提供服。

那么，我如何能使用 Kubernetes 的 Ingress 来创建一个统一的负载均衡器，从而实现当用户访问不同的域名时，能够访问到不同的 Deployment 呢？
上述功能，在 Kubernetes 里就需要通过 Ingress 对象来描述：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  tls:
  - hosts:
    - cafe.example.com
    secretName: cafe-secret
  rules: # 这个字段在Kubernetes里叫IngressRule
  - host: cafe.example.com  # Ingress的入口
    http:
      paths:
      - path: /tea  # /tea 对应 tea Deployment的 Service
        backend:
          serviceName: tea-svc # Deployment的 Service的名字
          servicePort: 80
      - path: /coffee  # /coffee 对应 coffee Deployment的 Service
        backend:
          serviceName: coffee-svc
          servicePort: 80

所谓 Ingress 对象，其实就是Kubernetes项目对“反向代理”的一种抽象。

一个 Ingress 对象的主要内容，实际上就是一个“反向代理”服务（比如：Nginx）的配置文件的描述。而这个代理服务对应的转发规则，就是 IngressRule。

这就是为什么在每条 IngressRule 里，需要有一个 host 字段来作为这条 IngressRule 的入口，然后还需要有一系列 path 字段来声明具体的转发策略。
这其实跟 Nginx、HAproxy等项目的配置文件的写法是一致的。

以 Nginx Ingress Controller 为例

总结

• Ingress 实际上就是 Kubernetes 对“反向代理”的抽象。
• 目前，Ingress 只能工作在七层，而 Service 只能工作在四层。所以当你想要在Kubernetes 里为应用进行 TLS 配置等 HTTP 相关的操作时，都必须通过 Ingress 来进行。