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方式处理流量。

1
2
3
4
5
6
7
8
9

 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资源。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

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`资源的名称和端口。

2 部署Ingress Controller（Nginx）

2.1 描述

Ingress 控制器自身是运行于Pod中的容器应用，一般是Nginx或Envoy一类的具有代理及负载均衡功能的守护进程，它监视着来自API Server的Ingress对象状态，并根据规则生成相应的应用程序专有格式的配置文件并通过重载或重启守护进程而使新配置生效。

Ingress控制器其实就是托管于Kubernetes系统之上的用于实现在应用层发布服务的Pod资源，跟踪Ingress资源并实时生成配置规则。

运行为Pod资源的Ingress控制器进程通过下面两种方式接入外部请求流量：

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

1. 借助于DaemonSet控制器，将Ingress控制器的Pod资源各自以单一实例的方式运行于集群的所有或部分工作节点之上，并配置这类Pod对象以HostPort（如下图中的a）或HostNetwork（如下图中的b）的方式在当前节点接入外部流量。