k8s教程：08-k8s-Ingress-概述

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

TCP负载均衡器
HTTP(S)负载均衡器

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

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

1 Ingress概述

1.1 什么是Ingress？

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

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

你可以给Ingress配置提供外部可访问的URL、负载均衡、SSL、基于名称的虚拟主机等。用户通过POST Ingress资源到API Server的方式来请求Ingress。Ingress controller负责实现Ingress，通常使用负载平衡器，它还可以配置边界路由和其他前端，这有助于以HA方式处理流量。

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

1.2 Ingress和Ingress Controller

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

Ingress控制器并不直接运行为kube-controller-manager的一部分，它是Kubernetes集群的一个重要组件，类似CoreDNS，需要在集群上单独部署。

1.3 Ingress工作流程

如下图所示，流量到达外部负载均衡器（externalLB）后，首先转发至Service资源Ingres-nginx上，然后通过Ingress控制器基于Ingress资源定义的规则将客户端请求流量直接转发至与Service对应的后端Pod资源之上。这种转发机制会绕过Service资源(app Service；api Service)，从而省去了由kube-proxy实现的端口代理开销。Ingress规则需要由一个Service资源对象辅助识别相关的所有Pod资源。如下Ingress通过app service资源去匹配后端的pod1和pod2；这个app service只是起到一个辅助识别功能。

1.4 先决条件

在使用Ingress resource之前，必须先了解下面几件事情。Ingress是beta版本的resource，在kubernetes1.1之前还没有。你需要一个Ingress Controller来实现Ingress，单纯的创建一个Ingress没有任何意义。

GCE/GKE会在master节点上部署一个Ingress Controller。你可以在一个Pod中部署任意个自定义的Ingress Controller。你必须正确的annotate每个Ingress，比如运行多个Ingress Controller和关闭glbc。

1.5 Ingress清单文件几个字段说明

Ingress资源是基于HTTP虚拟主机或URL的转发规则，spec字段中嵌套了rules、backend、tls等字段进行定义。下面这个示例中，它包含了一个转发规则，把发往www.ilinux.io的请求代理给名为myapp-svc的Service资源。

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

#说明：上面资源清单文件中的annotations用于识别其所属的Ingress控制器的类别，这一点在集群上部署多个Ingress控制器时尤为重要。

`Ingress Spec`（`# kubectl explain ingress.spec`）中的字段是定义`Ingress`资源的核心组成部分，主要嵌套如下三个字段：

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

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

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

`ingress.spec.rules.http.paths.backend`对象的定义由两个必须的内嵌字段组成：`serviceName`和`servicePort`，分别用于指定流量转发的后端目标`Service`资源的名称和端口。