实战：Ingress-2022.1.1

实战：Ingress-2022.1.1 实战：Ingress-2022.1.1

目录

文章目录

• • 实战：Ingress-2022.1.1
  • 目录
  • 实验环境
  • 实验软件
  • 1、Ingress(对外暴露集群服务)
  • 2、资源对象
  • 3、定义
  • • 1.rules
    • 2.Resource
    • 3.pathType
    • 4.IngressClass
    • 5.TLS
  • 关于我
  • 最后

实验环境

实验环境：
1、win10,vmwrokstation虚机；
2、k8s集群：3台centos7.6 1810虚机，1个master节点,2个node节点
   k8s version：v1.22.2
   containerd://1.5.5

实验软件

无

1、Ingress(对外暴露集群服务)

前面我们学习了在 Kubernetes 集群内部使用 kube-dns 实现服务发现的功能，那么我们部署在 Kubernetes 集群中的应用如何暴露给外部的用户使用呢？我们知道可以使用 NodePort 和 LoadBlancer 类型的 Service 可以把应用暴露给外部用户使用。除此之外，Kubernetes 还为我们提供了一个非常重要的资源对象可以用来暴露服务给外部用户，那就是 Ingress。对于小规模的应用(或者测试的时候)我们使用 NodePort 或许能够满足我们的需求，但是当你的应用越来越多的时候，你就会发现对于 NodePort 的管理就非常麻烦了，这个时候使用 Ingress 就非常方便了，可以避免管理大量的端口。

注意：我们知道，NodePort它是要到我们节点上的ClusterIp,然后通过ClusterIp去帮我们做一下负载，其实它的调用链是多了一层。

2、资源对象

Ingress 资源对象是 Kubernetes 内置定义的一个对象，是从 Kuberenets 集群外部访问集群的一个入口，将外部的请求转发到集群内不同的 Service 上，其实就相当于 nginx、haproxy 等负载均衡代理服务器，可能你会觉得我们直接使用 nginx 就实现了，但是只使用 nginx 这种方式有很大缺陷，每次有新服务加入的时候怎么改 Nginx 配置？不可能让我们去手动更改或者滚动更新前端的 Nginx Pod 吧？那我们再加上一个服务发现的工具比如 consul 如何(然后利用consul-template去自动刷新我们的nginx配置)？貌似是可以，对吧？Ingress 实际上就是这样实现的，只是服务发现的功能自己实现了，不需要使用第三方的服务了，然后再加上一个域名规则定义，路由信息的刷新依靠 Ingress Controller 来提供。

注意：这里写的是ingress，但其实是ingress-controller在起作用。这里的路由规则可能是一个域名，或者是一个Path路径，都是可以去做一个路由的匹配。

Ingress Controller 可以理解为一个监听器，通过不断地监听 kube-apiserver，实时的感知后端 Service、Pod (当然也包括ingress)的变化，当得到这些信息变化后，Ingress Controller 再结合 Ingress 的配置，更新反向代理负载均衡器，达到服务发现的作用。其实这点和服务发现工具 consul、 consul-template 非常类似。

⚠️

我们刚才也说了，Ingress它是一种资源对象，但是Ingress-controller他其实就是一种……，我们前面和大家已经介绍了CRD ,operator了，我们自己是不是可以自己随意定义一些自定义资源对象。但是你自定义的这些资源对象是没有意义的，它只是可以在k8s里做一些增删改查，用kube-controller去做一些简单的管理而已。但你你创建出来这个资源对象，它有什么意义呢？它还是要依赖于它背后的一个控制器。所以这个ingress控制器其实你就可以把它认为是一个Operator，或者是一个我们所说的k8s里面通用的控制器。

所以说，如果要让大家自己去实现一个功能，就是说去把service的pod给它暴露到集群外部去，其实也相当于是去开发一个operator，或者说去开发一个控制器。只是说，这个自定义的资源对象可能它的一个规则是按照我们自己的一个规则，按我们自己定义的一个方式去做的。而k8s它提供一个资源对象ingress，可以认为它是把这一块的服务暴露给它做了一个规范。就是你其他一些第三方的ingress控制器可能都需要来实现一下，当然你不实现的话，也可以，只是说的话，可能，大家都认为市面上一些通用的控制器都会兼容k8s提供的这个默认内置的这个ingress资源对象。如果说你提供的一个新的ingress-controller，如果没去兼容它的话，可能使用的人就会有所顾虑吧。

当然你说你自己要去实现一个控制器，你就不用它的ingrss，当然也是可以的。其实，官方内置的ingress相当就是说约定俗成吧，基本上类似于一个通用的。

3、定义

一个常见的 Ingress 资源清单如下所示：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules: #rules下面是可以配置很多规则的
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80

上面这个 Ingress 资源的定义，配置了一个路径为 /testpath 的路由，所有 /testpath/** 的入站请求，会被 Ingress 转发至名为 test 的服务的 80 端口的 / 路径下。可以将 Ingress 狭义的理解为Nginx 中的配置文件 nginx.conf。

此外 Ingress 经常使用注解 annotations 来配置一些选项，当然这具体取决于 Ingress 控制器的实现方式，不同的 Ingress 控制器支持不同的注解。

⚠️另外需要注意的是当前集群版本是 v1.22，这里使用的 apiVersion 是 networking.k8s.io/v1，所以如果是之前版本的 Ingress 资源对象需要进行迁移。 Ingress 资源清单的描述我们可以使用 kubectl explain 命令来了解：

➜ kubectl explain ingress.spec
KIND:     Ingress
VERSION:  networking.k8s.io/v1

RESOURCE: spec