k8sIngress资源

k8s提供了两种内建的云端负载均衡机制用于发布公共应用，一种是工作于传输层的service资源，它实现的是TCP负载均衡器，另一种是Ingress资源，它实现的是HTTP(S)负载均衡器。

1）TCP负载均衡器

无论是iptables还是ipvs模型的service资源都配置于Linux内核中的netfilter之上进行四层调度，是一种类型更为通用的调度器，支持调度HTTP、MYSQL等应用层服务。不过，也正是由于工作于传输层从而使得它无法做到类似卸载https种的ssl会话等一类操作，也不支持基于url的请求调度机制，而且，k8s也不支持为此类负载均衡器配置任何类型的健康检查机制

2）HTTP(S)负载均衡器

HTTP(S)负载均衡器是应用层负载均衡机制的一种，支持根据环境做出更好的调度决策。与传输层调度器相比，它提供了诸如可自定义url映射和tls卸载等功能，并支持多种类型的后端服务器监控状态检测机制。

一、Ingress和Ingress Controller

service资源和pod资源的IP地址仅能用于集群网络内部的通信，所有的网络流量都无法穿透边界路由器以实现集群内外通信。尽管可以为service使用NodePort或LoadBalancer类型通过节点引入外部流量，但它依然是4层流量转发，可用的负载均衡器也为传输层负载均衡机制。

Ingress是k8s的标准资源类型之一，它其实就是一组基于DNS名称或URL路径把请求转发至指定的service资源的规则，用于将集群外部的请求流量转发至集群内部完成服务发布。然而，Ingress资源自身并不能进行流量穿透，它仅是规则的集合，这些规则要想真正发挥作用还需要其他功能的辅助，如监听某套接字，然后根据这些规则的匹配机制路由请求流量。这种能够为Ingress资源监听套接字并转发流量的组件称为Ingress控制器。

Ingress控制器可以由任何具有反向代理功能的服务程序实现，如Nginx、Envoy和Traefik等。Ingress控制器自身也是运行于集群中的pod资源对象，它与被代理的运行为pod资源的应用运行于同一网络中。使用Ingress资源进行流量分发时，Ingress控制器可基于某Ingress资源定义的规则将客户端的请求流量直接转发至与service对应的后端pod资源之上，这种转发机制会绕过service资源，从而省去了由kube-proxy实现的端口代理开销。Ingress规则需要由一个service资源对象辅助识别相关的所有pod对象，但Ingress-nginx控制器可经由api.ilinux.io规则的定义直接将请求流量调度至后端pod上，而无须经由service对象api的再次转发。

二、创建Ingress资源

Ingress资源是基于http虚拟主机或url的转发规则，它在资源配置清单的spec字段中嵌套了rules、backend和tls等字段的定义：

apiVersion： extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"

spec:
  rules:
  - host: www.libux.io
    http:
      paths:
      - backend:
          serviceName: myapp-svc
          servicePort: 80

资源清单中annotation用于识别其所属的Ingress控制器的类型，这一点在集群中部署有多个Ingress控制器时尤为重要。Ingress spec中的字段是定义Ingress资源的核心组成部分：

rules：用于定义当前Ingress资源的转发规则列表；未由rules定义规则，或者没有匹配到任何规则时，所有流量都会转发到由backend定义的默认后端。

backend：默认的后端用于服务那些没有匹配到任何规则的请求；定义Ingress资源时，至少应该定义backend或rules两者之一；此字段用于让负载均衡器指定一个全局默认的后端。

tls：TLS配置，目前仅支持通过默认端口443提供服务，如果要配置指定的列表成员指向了不同的主机，则须通过SNI TLS扩展机制来支持此功能。

backend对象的定义由两个必选的内嵌字段组成：serviceName和servicePort，分别用于指定流量转发的后端目标service资源的名称和端口。rules对象由一系列配置Ingress资源的host规则组成，这些host规则用于将一个主机上的某个url路径映射至相关的后端service对象。spec.rules.host属性值目前不支持使用IP地址，也不支持后跟端口号，且字段值留空表示通配所有的主机名。

tls对象由两个内嵌字段组成，仅在定义tls主机的转发规则时才需要定义此类对象：

hosts：包含于使用的tls证书之内的主机名称字符串列表，因此，此处使用的主机名必须匹配tlsSecret中的名称

secretName：用于引用SSL会话的secret对象名称，在基于SNI实现多主机路由的场景中，此字段可选。

三、Ingress资源类型

基于http暴露的每个service资源均可发布于一个独立的FQDN主机名之上，如www.ik8s.io；也可发布于某主机的URL路径之上，从而将它们整合到同一个web站点，如www.ik8s.io/frafana。至于是否需要发布为https类型的应用则取决于用户的业务需求。

1、单service资源型Ingress

暴露单个服务的方法有很多种，如服务类型中的NodePort、LoadBalancer等，不过一样可以考虑Ingress来暴露服务，此时只需要为Ingress指定default.backend即可

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  backend:
    serviceName: my-svc
    servicePort: 

Ingress控制器会为其分配一个IP地址接入请求流量，并将它们转至后端。

2、基于url路径进行流量分发

垂直拆分或微服务架构中，每个小的应用都有其专用的service资源暴露服务，但在对外开放的站点上，它们可能时财经、新闻、电商即可等一类的独立应用，可通过主域名的url路径分别接入，用于发布集群内名称为API和WAP的service资源。于是，可对应地创建一个如下的Ingress资源：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
  nanotations:
    ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: www.ilinux.io
    http:
    - path: /wap
      backend:
        serviceName: wap
        servicePort:
    - path: /api
      backend:
        serviceName: api
        servicePort: 

3、基于主机名称的虚拟主机

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
spec:
  rules:
  - host: api.ik8s.io
    http:
      paths:
      - backend:
          serviceName: api
          servicePort:
  - host: wap.ik8s.io
    http:
      paths:
      - backend:
          serviceName: wap
          servicePort: 

4、TLS类型的Ingress资源

这种类型用于以https发布service资源，基于一个含有私钥和证书的secret对象即可配置TLS协议的Ingress资源，目前来说，Ingress资源仅支持单TLS端口，并且还会卸载TLS会话，在Ingress资源中引用此secret即可让Ingress控制器加载并配置为https服务

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: no-rules-map
spec:
  tls:
  - secretName: ikubernetesSecret
  backend:
    serviceName: homesite
    servicePort: 

四、部署Ingress控制器（Nginx）

运行为pod资源的Ingress控制器进程接入外部的请求流量常用的有两种解决方案：

1）以deployment控制器管理Ingress控制器的pod资源，并通过NodePort或LoadBalancer类型的service对象为其接入集群外部的请求流量，这就意味着，定义一个Ingress控制器时，必须在其前端定义一个专用的service资源

2）借助于DaemonSet控制器，将Ingress控制器的pod资源各自以单一实例的方式运行于集群的所有或部分工作节点之上，并配置这类pod对象以hostPort或hostNetwork的方式在当前节点接入外部流量。

apiVersion： v1
kind: Service
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
spec:
  type: NodePort
  clusterIP: 10.1.11.11
  ports:
  - port:
    name: http
    nodePort:
  - port:
    name: https
    nodePort:
  selector:
    app.kubernetes.io/name: ingress-nginx