API对象--Ingress（chrono《kubernetes入门实战课》笔记整理）

【概念说明】

Service 的功能和运行机制，主要由 kube-proxy 控制的四层负载均衡，即根据IP、PORT来做负载均衡。而很多应用都是在7层做均衡更为合理，比如根据主机名、URI、请求头、证书，做更高级准确的路由。另外，Service 还有一个缺点，它比较适合代理集群内部的服务。如果想要把服务暴露到集群外部，就只能使用 NodePort 或者 LoadBalancer 这两种方式，而它们都缺乏足够的灵活性，难以管控。既然 Service 是四层的负载均衡，那么再来一个七层负载均衡的PI对象的想法，就应运而生了，这就是Ingress。这个对象还应该承担更多的职责，也就是作为流量的总入口，统管集群的进出口数据，“扇入”“扇出”流量（也就是我们常说的“南北向”），让外部用户能够安全、顺畅、便捷地访问内部服务。

【Ingress Controller】

Ingress 可以说是在七层上另一种形式的 Service，它同样会代理一些后端的 Pod，也有一些路由规则来定义流量应该如何分配、转发，只不过这些规则都使用的是 HTTP/HTTPS 协议。Service 本身是没有服务能力的，它只是一些 iptables 规则，真正配置、应用这些规则的实际上是节点里的 kube-proxy 组件。同样的，Ingress 也只是一些 HTTP 路由规则的集合，相当于一份静态的描述文件，真正要把这些规则在集群里实施运行，还需要有Ingress Controller，它的作用就相当于 Service 的 kube-proxy，能够读取、应用 Ingress 规则，处理、调度流量。

由于 Ingress Controller 要做的事情太多，与上层业务联系太密切，所以 Kubernetes 把 Ingress Controller 的实现交给了社区，任何人都可以开发 Ingress Controller，只要遵守 Ingress 规则就好。从 Ingress Controller 的描述上我们也可以看到，HTTP 层面的流量管理、安全控制等功能其实就是经典的反向代理，而 Nginx 则是其中稳定性最好、性能最高的产品，所以它也理所当然成为了 Kubernetes 里应用得最广泛的 Ingress Controller。下面的这张图就来自 Nginx 官网，比较清楚地展示了 Ingress Controller 在 Kubernetes 集群里的地位：

【IngressClass】 

随着 Ingress 在实践中的大量应用，很多用户发现这种用法会带来一些问题，比如：由于某些原因，项目组需要引入不同的 Ingress Controller，但 Kubernetes 不允许这样做；Ingress 规则太多，都交给一个 Ingress Controller 处理会让它不堪重负；多个 Ingress 对象没有很好的逻辑分组方式，管理和维护成本很高；集群里有不同的租户，他们对 Ingress 的需求差异很大甚至有冲突，无法部署在同一个 Ingress Controller 上。

所以，Kubernetes 就又提出了一个 Ingress Class 的概念，让它插在 Ingress 和 Ingress Controller 中间，作为流量规则和控制器的协调人，解除了 Ingress 和 Ingress Controller 的强绑定关系。Kubernetes 用户可以转向管理 Ingress Class，用它来定义不同的业务逻辑分组，简化 Ingress 规则的复杂度。比如说，我们可以用 Class A 处理博客流量、Class B 处理短视频流量、Class C 处理购物流量。

【用YAML描述Ingress/Ingress Class】

1、使用kubectl api-resources 查看它们的基本信息，输出列在这里了：

kubectl api-resources

NAME          SHORTNAMES   APIVERSION           NAMESPACED   KIND
ingresses       ing          networking.k8s.io/v1   true         Ingress
ingressclasses               networking.k8s.io/v1   false        IngressClass

可以看到，Ingress 和 Ingress Class 的 apiVersion 都是“networking.k8s.io/v1”，而且 Ingress 有一个简写“ing”，但 Ingress Controller 怎么找不到呢？ 这是因为 Ingress Controller 和其他两个对象不太一样，它不只是描述文件，是一个要实际干活、处理流量的应用程序，而应用程序在 Kubernetes 里早就有对象来管理了，那就是 Deployment 和 DaemonSet，所以我们只需要再学习 Ingress 和 Ingress Class 的的用法就可以了。

1、Ingress：

1）--class，指定 Ingress 从属的 Ingress Class 对象；

2）--rule，指定路由规则，基本形式是“URI=Service”，也就是说是访问 HTTP 路径就转发到对应的 Service 对象，再由 Service 对象转发给后端的 Pod。

生成yaml样板间如下。

export out="--dry-run=client -o yaml"
kubectl create ing ngx-ing --rule="ngx.test/=ngx-svc:80" --class=ngx-ink $out

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ngx-ing

spec:

  ingressClassName: ngx-ink

  rules:
  - host: ngx.test
    http:
      paths:
      - path: /
        pathType: Exact
        backend:
          service:
            name: ngx-svc
            port:
              number: 80

2、Ingress Class：

其Ingress Class 本身并没有什么实际的功能，只是起到联系 Ingress 和 Ingress Controller 的作用，所以它的定义非常简单，在“spec”里只有一个必需的字段“controller”，表示要使用哪个 Ingress Controller。如果我要用 Nginx 开发的 Ingress Controller，那么就要用名字“nginx.org/ingress-controller”，样板间如下：

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: ngx-ink

spec:
  controller: nginx.org/ingress-controller

3）Ingress、IngressClass、IngressController的关系示意图：

【K8S使用Ingress/Ingress Class】

因为 Ingress Class 很小，所以可以把它与 Ingress 合成了一个 YAML 文件。以下是用 kubectl apply 创建这两个对象：

1、copy上面的ingress.yml，然后kubectl apply -f ingress.yml；

2、查看ing对象状态：

3、describe信息如下。Ingress 对象的路由规则 Host/Path 就是在 YAML 里设置的域名“ngx.test/”，而且已经关联了前一节课里面的 Service 对象，还有 Service 后面的两个 Pod。那么访问这个域名，就会转发到对应的service，再由service转发给后端的pod。其中，“Default backend”的作用是，在找不到路由的时候，它被设计用来提供一个默认的后端服务，但不设置也不会有什么问题，所以大多数时候可以忽略它。

【K8S使用Ingress Controller】

准备好了 做规则说明的Ingress 和 Ingress Class，接下来我们就需要部署真正处理路由规则的 Ingress Controller。它以 Pod 的形式运行在 Kubernetes 里，所以同时支持 Deployment 和 DaemonSet 两种部署方式。

Nginx Ingress Controller 的安装有很多个 YAML 需要执行，但如果只是做简单的试验，就只需要用到 4 个 YAML。可以在GitHub 上找到 Nginx Ingress Controller 的项目（https://github.com/nginxinc/kubernetes-ingress），有deploy和ds两种部署方式，实验中选择deploy，然后相关YAML可以在这里找到：（https://github.com/chronolaw/k8s_study/tree/master/ingress）

kubectl apply -f common/ns-and-sa.yaml
kubectl apply -f rbac/rbac.yaml
kubectl apply -f common/nginx-config.yaml
kubectl apply -f common/default-server-secret.yaml

（由于时间较晚，并且写了也背不下来，我后面的就先贴在这里，不整理为笔记了。）

部署 Ingress Controller 不需要我们自己从头编写 Deployment，Nginx 已经为我们提供了示例 YAML，但创建之前为了适配我们自己的应用还必须要做几处小改动：

1）metadata 里的 name 要改成自己的名字，比如 ngx-kic-dep；

2）spec.selector 和 template.metadata.labels 也要修改成自己的名字，比如还是用 ngx-kic-dep；

3）containers.image 可以改用 apline 版本，加快下载速度，比如 nginx/nginx-ingress:2.2-alpine；

4）最下面的 args 要加上 -ingress-class=ngx-ink，也就是前面创建的 Ingress Class 的名字，这是让 Ingress Controller 管理 Ingress 的关键。

修改完之后，Ingress Controller 的 YAML 大概是这个样子：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ngx-kic-dep
  namespace: nginx-ingress

spec:
  replicas: 1
  selector:
    matchLabels:
      app: ngx-kic-dep

  template:
    metadata:
      labels:
        app: ngx-kic-dep
    ...
    spec:
      containers:
      - image: nginx/nginx-ingress:2.2-alpine
        ...
        args:
          - -ingress-class=ngx-ink

关联图如下：

修改完毕，运行：

kubectl apply -f kic.yml

kubectl get deploy -n nginx-ingress
kubectl get pod -n nginx-ingress

此时Ingress Controller已经运行。不过还有最后一道工序，因为 Ingress Controller 本身也是一个 Pod，想要向外提供服务还是要依赖于 Service 对象。所以还要再为它定义一个 Service，使用 NodePort 或者 LoadBalancer 暴露端口，才能真正把集群的内外流量打通。