如何在TKE集群玩转nginx-ingress

一：了解什么是ingress

kubernetes Ingess 是有2部分组成，Ingress Controller 和Ingress服务组成，常用的Ingress Controller 是ingress-nginx，工作的原理是：

Ingress Controller 会动态感知集群中的Ingress的规则变化，然后读取，动态生成Nginx的配置文件，最后注入到运行nginx的pod的中，然后会自动reload，配置生效。

用kubernetes Ingress 是由于它是7层调度，可以直接卸载https会话，代理的后端的pod可以直接使用明文的http协议。

而Service NodePort/Loadbalancer/ClusterIP 等类型，是4层的调度，做不到这点，然而现在https是一种趋势，所以在kubernetes 对外暴露服务得时候我们还是要选择Ingress。

简单理解：service 是四层负载均衡只能代理四层转发，ingress 是七层负载均衡用来代理七层转发

二：nginx-ingress需要使用哪些组件

1.Ingress-Controller: 核心组件，用于七层请求转发

2.ingress: 外部配置，ingress中配置的转发规则会自动注入到ingress-controller中

3.Ingress-Controller-service: Ingress-Controller组件的前段service，用于接入外部流量

4.nginx-ingress-default-backend: ingress-controller中没有对应转发规则的时候，请求自动分发到这个默认容器内（可以理解为网站文件中的404配置文件）

5.service: 底层容器服务，用于标识后段的pod信息（只起标识作用，真正的请求不经过service）

以上四个是部署nginx-ingress 的几个基于容器的组件，当然这里还要搭配到具体的ServiceAccount 和 Role 来使用，剩余部分这里不做详细解释。

请求流程图：

完整请求流程

上面截图中实线部分代表真是请求走向，从上面截图中可以看到，真正请求的时候是没有过service 和 ingress 这两个组件的，那么这两个组件在这里具体是起什么作用呢。

service：用于声明整理后端pod信息，ingress-controller 的配置文件中直接映射到后段pod IP+端口

ingress：用于声明前端请求域名 和 path 路径，对应的后段service 和 端口，ingress中声明的配置会自动注入到ingress-controller 的配置文件中

三：如何在TKE集群中部署nginx-ingress

在kubernetes集群中部署nginx-ingress网上有很多很完善的说明文档，这里只针对腾讯云TKE集群环境中怎么部署做说明。

部署方法

使用yaml 文件手动部署：参考网上配置文档，配置基本上都一致。

使用helm部署：这里主要讲一下helm的部署方法

1.配置 集群helm 部署环境

helm服务端：可以直接控制台创建，如图：

部署helm服务端

helm客户端：可以参考https://cloud.tencent.com/document/product/457/32731

helm 部署好之后，使用helm version 可以看到具体的server 和 client 版本

2.使用helm部署nginx-ingress

这里同样可以直接在控制台操作，如图：

点击完成，选择进入刚才创建的helm 应用，可以看到详细状态，都安装了哪些东西。如图：

从这里可以看到是安装了这么多的资源，接下来需要做的就是登录命令行，检查下这些资源是否都创建完成，是否都正常运行。（主要检查下面的两个service 和 deployment 资源）

只要这里资源都正常存在，确保 pod 都是正常running 状态，就可以了。

四：验证nginx-ingress

nginx-ingress-contraller 相关组件配置完成，接下来就需要验证nginx-ingress 转发了。

这里需要先部署一个用来被访问的容器资源，我们这里就使用最简单的nginx容器。

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.12
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: default
spec:
  clusterIP: None
  ports:
  - name: tcp-80-80
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
     app: nginx
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

这里nginx的service 使用clusterIP Headless 的暴露方式，专门用于nginx-ingress 的访问方式。

具体Headless 的使用说明：不创建用于集群内访问的ClusterIP，访问Service名称时返回后端Pods IP地址，用于适配自有的服务发现机制。

重点来了：创建nginx-ingress ，配置转发规则

因为我们这里是在TKE 集群中创建，所以要规避qcloud 类型的ingress ，可以参考官网文档：

https://cloud.tencent.com/document/product/457/31711

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx ## 可选值：qcloud（CLB类型ingress）, nginx（nginx-ingress）
    ## kubernetes.io/ingress.subnetId: subnet-xxxxxxxx  ##若是创建CLB类型内网ingress需指定该条annotation
  name: my-ingress
  namespace: default
spec:
  rules:
  - host: www.kubernete.cn
    http:
      paths:
      - backend:
          serviceName: nginx
          servicePort: 80
        path: /

root@VM-20-7-ubuntu:/data/docker# kubectl get ingress | grep  my-ingress
my-ingress   www.kubernete.cn    192.144.216.168   80        29s
root@VM-20-7-ubuntu:/data/docker# kubectl describe ingress my-ingress
Name:             my-ingress
Namespace:        default
Address:          192.144.216.168
Default backend:  default-http-backend:80 (<none>)
Rules:
  Host              Path  Backends
  ----              ----  --------
  www.kubernete.cn  
                    /   nginx:80 (<none>)
Annotations:
  kubectl.kubernetes.io/last-applied-configuration:  {"apiVersion":"extensions/v1beta1","kind":"Ingress","metadata":{"annotations":{"kubernetes.io/ingress.class":"nginx"},"name":"my-ingress","namespace":"default"},"spec":{"rules":[{"host":"www.kubernete.cn","http":{"paths":[{"backend":{"serviceName":"nginx","servicePort":80},"path":"/"}]}}]}}

  kubernetes.io/ingress.class:  nginx
Events:
  Type    Reason  Age   From                      Message
  ----    ------  ----  ----                      -------
  Normal  CREATE  112s  nginx-ingress-controller  Ingress default/my-ingress
  Normal  UPDATE  98s   nginx-ingress-controller  Ingress default/my-ingress

ps：正常来讲，创建nginx 类型ingress ，这里不该生成Address ，这里应该是TKE 底层逻辑问题，会自动生成Address ，这里的Address 地址是node IP （已跟产品侧提需求修改，这里先不关注Address 问题）

我们上面讲过，这里创建完ingress ，会自动把转发信息同步到ingress-controller 中，我们这就进入ingress-controller

所在的pod 观察下，对应的转发规则是否生成。

ingress-controller

这里看到ingress 的转发规则一定自动同步到 ingress-controller ，现在我们就可以访问测试。

添加www.kubernete.cn 的域名解析，指向ingress-controller-service 的IP 152.136.238.156

测试访问

测试访问成功。

五：延伸思考

问题1.：如果这里不配置host解析，直接请求 152.136.238.156 会怎么样。

[root@VM_1_6_centos ~]# curl  152.136.238.156
default backend - 404[root@VM_1_6_centos ~]# 

这个时候nginx-ingress-default-backend 就起作用了，因为请求的域名，在转发规则里没有，这里都会转发到默认的容器里，然后返回404 。

问题2：为什么ingress 中创建的规则没有自动同步到 ingress-controller

解答：检查ingress 中的 kubernetes.io/ingress.class: 字段是否为 nginx ，如果这里填写的不是nginx ，填写成nginx-ingress 或者 qcloud 这种类型，都是不会跟 ingress-controller 做联动同步的。

如果这里大家有其他问题，可以在下方评论处留言，一起学习。