Ingress资源

官方文档:https://kubernetes.io/zh/docs/concepts/services-networking/ingress/

• 注意：因使用版本不同，与官方文档存在细微差异。
  Service虽然解决了服务发现和负载均衡的问题，但是它在使用上还是有着很多的限制，比如，只支持4层的负载均衡，没有7层功能，而对于http的服务来说，不同的URL地址通常对应到不同的后端服务或者虚拟服务器，这些应用层的转发机制仅通过Service是无法实现的，所以在kubernetes1.1版本开始，新增Ingress资源对象，用于将不同URL的访问请求转发到后端不同的Service，以实现HTTP层的业务路由机制。
  Ingress就是为了解决Service的这些限制而引入的新资源，主要用来将服务暴漏到集群外部，并且可以定义服务的访问策略。比如想通过负载均衡器实现不同子域名的访问。Service实现的是”TCP负载均衡器”，Ingress实现的是”HTTP(S)”负载均衡器
• TCP负载均衡器:无论是iptables还是ipvs模型的Service资源都配置于Linux内核中的netfilter之上进行四层调度，是一种类型更为通用的调度器，它支持调度http，mysql等应用层服务，不过，由于正是其工作于四层从而能使得它无法做到类似卸载HTTPS中的SSL会话等一类操作，也不支持基于URL的请求调度机制，而且K8S也不支持为此类负载均衡器配置任何类型的监控状态检查机制
• HTTP(S)负载均衡器:HTTP(S)负载均衡器是应用层负载均衡机制的一种，支持根据环境做出更好的调度决策。与传输层调度器相比，它提供了诸如可自动义URL映射和TLS卸载等功能，并支持多种类型的后端服务器健康状态检测机制

Ingress和Ingress Controller

K8S中，Service资源和Pod资源的IP地址仅能用于集群网络内部的通信，所有的网络流量都无法穿透边界路由器以实现集群内外通信。尽管可以为Service使用NodePort或LoadBalancer类型通过节点引入外部流量，但它依然是4层流量转发，可用的负载均衡器也为传输层负载均衡机制 Ingress是K8S API的标准资源类型之一，它其实就是一组基于DNS名称(host)或URL路径把请求转发至指定的Service资源的规则，用于将集群外部的请求流量转发至集群内布完成服务发布。但是Ingress资源自身并不能进行”流量穿透”，它仅是一组路由规则的集合,这些规则要想真正发挥作用还需要其他功能的辅助。如监听某套接字，然后根据这些规则的匹配机制路由请求流量。这种能够为Ingress资源监听套接字并转发流量的组件叫Ingress控制器。通俗点讲就是,Ingress可以配置为提供外部服务可访问的URL，负载均衡流量，SSL\TLS，以及提供各种基于名称的虚拟主机。而如果要实现Ingress则必须配置Ingress Controller 不同于Deployment控制器等，Ingress控制器并不直接运行为kube-controller-manager的一部分，它是K8S集群的一个重要附件，类似于CoreDNS，需要在集群上单独部署 Ingress控制器可以由任何具有反向代理(HTTP/HTTPS)功能的服务程序实现，如Nginx，Envoy，HAproxy，vulcand和Traefik等。Ingress控制器自身也是运行于集群中的Pod资源对象，它与被代理的运行为Pod资源的应用运行于同一网络中，如下图所示 另一方面，使用Ingress资源进行流量分发时，Ingress控制器可基于某Ingress资源定义的规则将客户端的请求流量直接转发至与Service对应的后端Pod资源之上，这种转发机制会绕过Service资源，从而省去了由kube-proxy实现的端口代理的开销。如上图所示，Ingress规则需要由一个Service对象辅助识别相关的所有Pod对象，但Ingress-nginx控制器可经由api.ilinux.io规则的定义直接将请求流量调度至Pod3或Pod4上，而无须经由Service对象API的再次转发，WAP相关规则的作用方式于此类同。Service的主要作用就是用于关联后端的Pod资源对象。Ingress通过识别Service资源的目标名称和端口进行流量转发

创建Ingress资源

Ingress资源是基于HTTP虚拟主机或URL的转发规则，它再资源配置清单的spec字段中嵌套了rules、backend和tls等字段进行定义。与其他K8S资源一样，Ingress也必须要使用apiVersion,kind和metadata字段。 Ingress 对象的命名必须是合法的 DNS 子域名名称。下面的示例中定义了一个Ingress资源，它包含了一个转发规则，把发往www.ilinux.io的请求代理给myapp-svc的Service资源的80端口,并且定义了一个默认后端，所有不匹配的规则都将发往这个默认后端default.ilinux.io

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  backend:
    serviceName: default.ilinux.io
    servicePort: 80
  rules:
  - host: www.ilinux.io
    http:
      paths:
      - path: /
        backend:
          serviceName: myapp-svc
          servicePort: 80

上面资源清单中的annotations用于识别其所属的ingress控制器的类别，这一点在集群上部署有多个Ingress控制器时尤为重要。Ingress spec中的字段是定义ingress资源的核心组成部分，它主要嵌套如下三个字段

• rules<[]Object>:用于定义Ingress资源的转发规则列表；未由rules定义规则或者没有匹配到任何规则时，所有流量都会转发到由backend定义的默认后端
• backend