Ingress

通常情况下，service 和 pod 仅可在集群内部网络中通过 IP 地址访问。所有到达边界路由器的流量或被丢弃或被转发到其他地方。从概念上讲，可能像下面这样：

  internet
      |
------------
[Services]

Ingress 是 授权 入站连接 到达 集群服务 的 规则集合

 internet
     |
[Ingress]
--|-----|--
[Services]

可以给 Ingress 配置提供外部可访问的 URL 、 负载均衡 、 SSL 、 基于名称的虚拟主机 等：

• 用户通过 POST Ingress 资源到 API server 的方式来请求 ingress
• Ingress controller 负责实现 Ingress，通常使用 负载均衡器
  • 还可以配置边界路由和其他前端，这有助于以高可用的方式处理流量

在使用 Ingress 资源之前，有必要先了解下面几件事情：

• Ingress 资源对象在 Kubernetes 1.1 之前还没有
• 需要一个 Ingress Controller 来实现 Ingress，单纯的创建一个 Ingress 没有任何意义
  • GCE/GKE 会在 master 节点上部署一个 ingress controller
    • 可以在一个 pod 中部署任意个自定义的 ingress controller
    • 必须正确地注解每个 ingress，比如运行多个 ingress controller 和关闭 glbc
  • 在非 GCE/GKE 的环境中，需要在 pod 中 部署一个 controller，例如 Nginx Ingress Controller

最简化的 Ingress 配置如下：

1: apiVersion: extensions/v1beta1
2: kind: Ingress
3: metadata:
4:   name: test-ingress
5: spec:
6:   rules:
7:   - http:
8:       paths:
9:       - path: /testpath
10:        backend:
11:           serviceName: test
12:           servicePort: 80

• 1-4 行 ：跟 Kubernetes 的其他配置一样，ingress 的配置也需要 apiVersion，kind 和 metadata 字段
• 5-7 行 : Ingress spec 中包含配置一个 loadbalancer 或 proxy server 的所有信息

  • 最重要的是，它包含了一个匹配 所有入站请求 的 规则列表

    目前 ingress 只支持 http 规则
    

• 8-9 行 ：每条 http 规则包含以下信息：

  • 一个 host 配置项

    比如 for.bar.com，在这个例子中默认是 *
    

  • path 列表

    比如：/testpath
    

    • 每个 path 都关联一个 backend

      比如 test:80
      

  • 在 loadbalancer 将流量转发到 backend 之前， 所有的入站请求 都要先 匹配 host 和 path
• 10-12 行 ：backend 是一个 service:port 的组合。Ingress 的流量被转发到它所匹配的 backend

如果没有配置 Ingress controller 就将其 POST 到 API server 不会有任何用处

为了简单起见，示例中没有全局参数：在所有请求都不能跟 spec 中的 path 匹配的情况下，请求被发送到 Ingress controller 的默认后端，可以指定全局缺省 backend

为了使 Ingress 正常工作，集群中必须运行 Ingress controller：

• Kubernetes 当前支持并维护 GCE 和 nginx 两种 controller
• F5 公司 支持并维护 F5 BIG-IP Controller for Kubernetes
• Kong 同时支持并维护 社区版 与 企业版 的 Kong Ingress Controller for Kubernetes
• Traefik 是功能齐全的 ingress controller (Let’s Encrypt, secrets, http2, websocket…), Containous 也对其提供商业支持
• Istio 使用 CRD Gateway 来 控制 Ingress 流量

这与其他类型的控制器不同，其他类型的控制器通常作为 kube-controller-manager 二进制文件的一部分运行，在集群启动时自动启动

用户需要选择最适合自己集群的 Ingress controller 或者自己实现一个

确保使用前查看控制器特定的文档，以便了解每个文档的注意事项

假如想要向已有的 ingress 中增加一个新的 Host，可以编辑和更新该 ingress：

$ kubectl get ing
NAME      RULE          BACKEND   ADDRESS
test      -                       178.91.123.132
foo.bar.com
/foo          s1:80
$ kubectl edit ing test

这会弹出一个包含已有的 yaml 文件的编辑器，修改它，增加新的 Host 配置：

spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
	  serviceName: s1
	  servicePort: 80
	path: /foo
  - host: bar.baz.com
    http:
      paths:
      - backend:
	  serviceName: s2
	  servicePort: 80
	path: /foo
..

保存它会更新 API server 中的资源，这会触发 ingress controller 重新配置 loadbalancer：

$ kubectl get ing
NAME      RULE          BACKEND   ADDRESS
test      -                       178.91.123.132
foo.bar.com
/foo          s1:80
bar.baz.com
/foo          s2:80

在一个修改过的 ingress yaml 文件上调用 kubectl replace -f 命令一样可以达到同样的效果

在不同云供应商之间，跨故障域的流量传播技术有所不同

有关详细信息，请查看相关 Ingress controller 的文档

有关在 federation 集群中部署 Ingress 的详细信息，请参阅 federation 文档

• 多样化的 HTTPS/TLS 模型支持（如 SNI，re-encryption）
• 通过声明来请求 IP 或者主机名
• 结合 L4 和 L7 Ingress
• 更多的 Ingress controller

可以通过很多种方式暴露 service 而不必直接使用 ingress：

• 使用 Service.Type=LoadBalancer
• 使用 Service.Type=NodePort
• 使用 Port Proxy
• 部署一个 Service loadbalancer 这允许在多个 service 之间共享单个 IP，并通过 Service Annotations 实现更高级的负载平衡

如果部署了 Traefik 作为 Ingress Controller，集群外部直接访问 Kubenetes 内部服务的话，可以直接创建 Ingress 如下所示：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: traefik-ingress
  namespace: default
spec:
  rules:
  - host: traefik.nginx.io
    http:
      paths:
      - path: /
	backend:
	  serviceName: my-nginx
	  servicePort: 80