Ingress：k8s集群进出流量的总管

最新推荐文章于 2023-11-29 18:38:11 发布

grantpole

最新推荐文章于 2023-11-29 18:38:11 发布

阅读量385

点赞数

文章标签： kubernetes 容器云原生

本文链接：https://blog.csdn.net/lomodays207/article/details/130703396

版权

Ingress：k8s集群进出流量的总管

Service 对象，它是 Kubernetes 内置的负载均衡机制，使用静态 IP 地址代理动态变化的 Pod，支持域名访问和服务发现，是微服务架构必需的基础设施。

Service 很有用，但也只能说是“基础设施”，它对网络流量的管理方案还是太简单，离复杂的现代应用架构需求还有很大的差距，所以 Kubernetes 就在 Service 之上又提出了一个新的概念：Ingress。

为什么要有 Ingress？

下图是Service 的功能和运行机制，它本质上就是一个由 kube-proxy 控制的四层负载均衡，在 TCP/IP 协议栈上转发流量（Service 工作原理示意图）：

但在四层上的负载均衡功能还是太有限了，只能够依据 IP 地址和端口号做一些简单的判断和组合，而我们现在的绝大多数应用都是跑在七层的 HTTP/HTTPS 协议上的，有更多的高级路由条件，比如主机名、URI、请求头、证书等等，而这些在 TCP/IP 网络栈里是根本看不见的。

该怎么解决这个问题呢？

Kubernetes 还是沿用了 Service 的思路，既然 Service 是四层的负载均衡，那么我再引入一个新的 API 对象，在七层上做负载均衡是不是就可以了呢？

不过除了七层负载均衡，这个对象还应该承担更多的职责，也就是作为流量的总入口，统管集群的进出口数据，让外部用户能够安全、顺畅、便捷地访问内部服务。

所以，这个 API 对象就顺理成章地被命名为 Ingress，意思就是集群内外边界上的入口。

怎么使用 Ingress？

Ingress 的功能其实很容易理解：所谓 Ingress，就是 Service 的“Service”。

举个例子，假如现在有这样一个站点：https://cafe.example.com。其中，https://cafe.example.com/coffee，对应的是“咖啡点餐系统”。而，https://cafe.example.com/tea，对应的则是“茶水点餐系统”。

这两个系统，分别由名叫 coffee 和 tea 这样两个 Deployment 来提供服务。那么现在，我如何能使用 Kubernetes 的 Ingress 来创建一个统一的负载均衡器，从而实现当用户访问不同的域名时，能够访问到不同的 Deployment 呢？上述功能，在 Kubernetes 里就需要通过 Ingress 对象来描述，如下所示：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  tls:
  - hosts:
    - cafe.example.com
    secretName: cafe-secret
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        backend:
          serviceName: tea-svc
          servicePort: 80
      - path: /coffee
        backend:
          serviceName: coffee-svc
          servicePort: 80

在上面这个名叫 cafe-ingress.yaml 文件中，最值得我们关注的，是 rules 字段。

在 Kubernetes 里，这个字段叫作：IngressRule。IngressRule 的 Key，就叫做：host。它必须是一个标准的域名格式，而不能是 IP 地址，而 host 字段定义的值，就是这个 Ingress 的入口。

这也就意味着，当用户访问 cafe.example.com 的时候，实际上访问到的是这个 Ingress 对象。

而接下来 IngressRule 规则的定义，则依赖于 path 字段。你可以简单地理解为，这里的每一个 path 都对应一个后端 Service。

在这个例子里，定义了两个 path，它们分别对应 coffee 和 tea 这两个 Deployment 的 Service（即：coffee-svc 和 tea-svc）。

通过上面的例子，不难看到，所谓 Ingress 对象，其实就是 Kubernetes 项目对“反向代理”的一种抽象。一个 Ingress 对象的主要内容，实际上就是一个“反向代理”服务（比如：Nginx）的配置文件的描述，而这个代理服务对应的转发规则，就是 IngressRule。

这其实跟 Nginx、HAproxy 等项目的配置文件的写法是一致的，而有了 Ingress 这样一个统一的抽象，Kubernetes 的用户就无需关心 Ingress 的具体细节了。

Ingress 可以说是在七层上另一种形式的 Service，它同样会代理一些后端的 Pod，也有一些路由规则来定义流量应该如何分配、转发，只不过这些规则都使用的是 HTTP/HTTPS 协议。

你知道Service 本身是没有服务能力的，它只是一些 iptables 规则，真正配置、应用这些规则的实际上是节点里的 kube-proxy 组件。如果没有 kube-proxy，Service 定义得再完善也没有用。

同样的，Ingress 也只是一些 HTTP 路由规则的集合，相当于一份静态的描述文件，真正要把这些规则在集群里实施运行，还需要有另外一个东西，这就是 Ingress Controller，它的作用就相当于 Service 的 kube-proxy，能够读取、应用 Ingress 规则，处理、调度流量。

一键部署Ingress Controller

按理来说，Kubernetes 应该把 Ingress Controller 内置实现，作为基础设施的一部分，就像 kube-proxy 一样。

不过 Ingress Controller 要做的事情太多，与上层业务联系太密切，所以 Kubernetes 把 Ingress Controller 的实现交给了社区，任何人都可以开发 Ingress Controller，只要遵守 Ingress 规则就好。

在实际的使用中，你只需要从社区里选择一个具体的 Ingress Controller，把它部署在 Kubernetes 集群里即可。然后，这个 Ingress Controller 会根据你定义的 Ingress 对象，提供对应的代理能力。目前，业界常用的各种反向代理项目，比如 Nginx、HAProxy、Envoy等。

因为 Nginx 是开源的，谁都可以基于源码做二次开发，所以它又有很多的变种，比如社区的 Kubernetes Ingress Controller（https://github.com/kubernetes/ingress-nginx）、Nginx 公司自己的 Nginx Ingress Controller（https://github.com/nginxinc/kubernetes-ingress）、还有基于 OpenResty 的 Kong Ingress Controller（https://github.com/Kong/kubernetes-ingress-controller）等等

下面的这张图就来自 Nginx 官网，比较清楚地展示了 Ingress Controller 在 Kubernetes 集群里的地位：

部署 Nginx Ingress Controller 的方法非常简单，如下所示：

1、下载一键部署yaml文件

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.3.1/deploy/static/provider/cloud/deploy.yaml

2、处理国内无法下载k8s.io上的镜像

sed -i s#registry.k8s.io/ingress-nginx/controller:v1.3.1@sha256:54f7fe2c6c5a9db9a0ebf1131797109bb7a4d91f56b9b362bde2abd237dd1974#registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller:v1.3.1#g deploy.yaml

sed -i s#registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.3.0@sha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47#registry.cn-hangzhou.aliyuncs.com/google_containers/kube-webhook-certgen:v1.3.0#g deploy.yaml

3、用 NodePort service 暴露 Nginx Ingress Controller

在这里插入图片描述

4、部署Nginx Ingress Controller

kubectl apply -f deploy.yaml

上述操作完成后，可以查看下 Service 的访问入口，即：宿主机的地址和 NodePort 的端口，如下所示：

在 Ingress Controller 和它所需要的 Service 部署完成后，我们就可以使用它了。

如何在 k8s里使用 Ingress Controller

备注：这个“咖啡厅”Ingress 的所有示例文件，都在这里。

https://github.com/resouer/kubernetes-ingress/tree/master/examples/complete-example

首先，我在集群里部署我们的应用咖啡厅 Pod 和它们对应的 Service：

$ kubectl create -f cafe.yaml

然后，我们需要创建 Ingress 所需的 SSL 证书（tls.crt）和密钥（tls.key），这些信息都是通过 Secret 对象定义好的，如下所示：

$ kubectl create -f cafe-ingress.yaml

这一步完成后，就可以创建在本篇文章一开始定义的 Ingress 对象了：

$ kubectl create -f cafe-ingress.yaml

然后，我们就可以查看一下这个 Ingress 对象的信息：

可以看到，这个 Ingress 对象最核心的部分，正是 Rules 字段。其中，我们定义的 Host 是cafe.example.com，它有两条转发规则（Path），分别转发给 tea-svc 和 coffee-svc。

接下来，我们就可以通过访问这个 Ingress 的地址和端口，访问到我们前面部署的应用了，比如，当我们访问https://cafe.example.com:443/coffee时，应该是 coffee 这个 Deployment 负责响应我的请求。

我们在 curl 发测试请求的时候需要注意，因为 Ingress 的路由规则是 HTTP 协议，所以就不能用 IP 地址的方式访问，必须要用域名，你可以修改 /etc/hosts 来手工添加域名解析，也可以使用 --resolve 参数，指定域名的解析规则。

要访问该应用程序，请求 tea-svc 和 coffee-svc。我们将使用 curl 的 --insecure 选项来关闭自签名证书的证书验证，并使用 --resolve 选项来设置域名cafe.example.com 和IP的映射

#设置环境变量
[root@k8s-master1 deployments]# IC_IP=192.168.2.129
[root@k8s-master1 deployments]# IC_HTTPS_PORT=32043

# 请求 coffee:
[root@k8s-master1 deployments]# curl --resolve cafe.example.com:$IC_HTTPS_PORT:$IC_IP https://cafe.example.com:$IC_HTTPS_PORT/coffee --insecure
Server address: 10.244.36.77:8080
Server name: coffee-6f4b79b975-d4dwp
Date: 16/May/2023:11:41:12 +0000
URI: /coffee
Request ID: 55722fd73ebb8ff0981251fe42406ca7

# 请求 tea:
[root@k8s-master1 deployments]# curl --resolve cafe.example.com:$IC_HTTPS_PORT:$IC_IP https://cafe.example.com:$IC_HTTPS_PORT/tea --insecure
Server address: 10.244.36.79:8080
Server name: tea-6fb46d899f-bxdqj
Date: 16/May/2023:11:45:21 +0000
URI: /tea
Request ID: 688de602d9894b2316cd5d95dc9f417f

可以看到，Nginx Ingress Controller 为我们创建的 Nginx 负载均衡器，已经成功地将请求转发给了对应的后端 Service。

以上，就是 Kubernetes 里 Ingress 的设计思想和使用方法了。

小结

我们学习了 Kubernetes 里七层的反向代理和负载均衡对象，包括 Ingress、Ingress Controller它们联合起来管理了集群的进出流量，是集群入口的总管。

Service 是四层负载均衡，能力有限，所以就出现了 Ingress，它基于 HTTP/HTTPS 协议定义路由规则。
Ingress 只是规则的集合，自身不具备流量管理能力，需要 Ingress Controller 应用 Ingress 规则才能真正发挥作用。
Ingress Class 解耦了 Ingress 和 Ingress Controller，我们应当使用 Ingress Class 来管理 Ingress 资源。
最流行的 Ingress Controller 是 Nginx Ingress Controller，它基于经典反向代理软件 Nginx。

好了，以上就是今天分享的全部内容，enjoy 欢迎吐槽、交流~微信公众号【AI黑板报】