共计 3874 个字符,预计需要花费 10 分钟才能阅读完成。
导读 | 在业务使用 Kubernetes 进行编排管理时,针对业务的南北流量的接入,在 Kuberentes 中通常有几种方案,本文就接入的方案进行简单介绍。 |
Kuberentes 社区通过为集群增设入口点的方案,解决对外流量的管理。
通常在最简单的测试或个人开发环境,可以通过 kubectl port-forward 来启动一个 kube-proxy 进程代理内部的服务至该命令执行的宿主机节点,如果该宿主机具备公网 IP,且转发监听端口为 0.0.0.0 就可以实现公网访问该服务,该方式可以代理单个 Pod,或者 Deployment,或者 Servcie。
$ kubectl port-forward -h
Forward one or more local ports to a pod. This command requires the node to have 'socat' installed.
Use resource type/name such as deployment/mydeployment to select a pod. Resource type defaults to 'pod' if omitted.
If there are multiple pods matching the criteria, a pod will be selected automatically. The forwarding session ends
when the selected pod terminates, and rerun of the command is needed to resume forwarding.
Examples:
# Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in the pod
kubectl port-forward pod/mypod 5000 6000
# Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in a pod selected by the
deployment
kubectl port-forward deployment/mydeployment 5000 6000
# Listen on port 8443 locally, forwarding to the targetPort of the service's port named"https" in a pod selected by
the service
kubectl port-forward service/myservice 8443:https
# Listen on port 8888 locally, forwarding to 5000 in the pod
kubectl port-forward pod/mypod 8888:5000
# Listen on port 8888 on all addresses, forwarding to 5000 in the pod
kubectl port-forward --address 0.0.0.0 pod/mypod 8888:5000
# Listen on port 8888 on localhost and selected IP, forwarding to 5000 in the pod
kubectl port-forward --address localhost,10.19.21.23 pod/mypod 8888:5000
# Listen on a random port locally, forwarding to 5000 in the pod
kubectl port-forward pod/mypod :5000
其次较常用的为 NodePort 方式,将 K8s 中 service 的类型修改为 NodePort 方式,会得到一个端口范围在 30000-32767 端口范围内的宿主机端口,同样宿主机具有公网 IP 就可以实现对服务的暴露,但是 NodePort 会占用宿主机端口,一个 Service 对应一个 NodePort,该方式仅为四层,无法实现 SSL 证书的卸载,如果将服务转发到单个 Node 节点的 NodePort 也无法实现高可用,一般需要在 NodePort 前搭配负载均衡来添加多个后端 NodePort 已实现高可用。
四层流量转发一个 LB 的端口只能对应一个 Service,Servcie 的 Type 为 NodePort,例如如下图,LoadBalancer 上的 88 端口对应转发到后端 NodePort 的 32111 端口,对应到 servcieA;LB 上的 8080 端口对应转发到后端 NodePort32001 端口;该方案可以通过添加多个 NodePort 方式实现高可用,但是由于为四层无法实现对 SSL 的卸载,对应 NodePort 需要在 LB 占用一个端口。
七层可以借助 LB 的域名转发,实现一个域名端口对应多个 Service,如图可以根据 path 路径,/cmp 对应 NodePort 的 32111,/gateway 对应 NodePort 的 32000 端口,不仅可以实现高可用,而且七层可以实现 SSL 卸载。
目前一般公有云的 LB 级别都具备四层和七层的功能,配合使用可以实现灵活的业务流量暴露。
在 K8s 中,存在有 Ingress 资源来实现单个域名转发根据不同的路径或其他配置规则转发到 K8 集群内部不同的 Service,但是用户请求需要访问 Ingress 实现控制器的 NodePort 例如 Ingress-nginx 的 Controller 的 Service 的 NodePort,针对具体的业务域名一般不会带端口,所以一般前面还需要一层 80/443 的端口转发。
一般 Ingress 的 Controller 实现业界也有不少解决方案,例如比较知名的 Ingress—nginx/Ingress-traefik 等。
如下图所示在最前面有一个四层 LB 实现端口 80/443 转发至 ingress-provider 的 Service 的 NodePort,K8s 集群内部配置有多个 service。
在上面的几种方案中,均有用到 Ingress,Nginx-ingress 为 Nginx 官方提供的实现 K8s ingress 资源的方案,同时 Kubernetes 官方也提供了基于 Nginx 实现的 Ingress 方案。
Nginx Ingress 由资源对象 Ingress、Ingress 控制器、Nginx 三部分组成,Ingress 控制器的目标是构建完成一个配置文件 (nginx.conf),主要通过检测配置文件发生改变后重载 Nginx 实现,但并不是仅在 Upstream 更改时重载 Nginx(部署应用程序时修改 Endpoints),使用 lua-nginx-module 实现。
根据下图可以更好理解 Ingress-nginx 的使用场景。
图中展示如下信息:
-
1,一个 K8s 集群
2,集群用户管理、用户 A 和用户 B,它们通过 Kubernetes API 使用集群。
3,客户端 A 和客户端 B,它们连接到相应用户部署的应用程序 A 和 B。
4,IC,由 Admin 部署在名称空间 nginx-ingress 中的 pod 中,并通过 ConfigMap nginx-ingress 进行配置。Admin 通常部署至少两个 pod 以实现冗余。IC 使用 Kubernetes API 获取集群中创建的最新入口资源,然后根据这些资源配置 NGINX。
5,应用程序 A 由用户 A 在命名空间 A 中部署了两个吊舱。为了通过主机 A.example.com 向其客户机(客户机 A)公开应用程序,用户 A 创建入口 A。
6,用户 B 在命名空间 B 中部署了一个 pod 的应用程序 B。为了通过主机 B.example.com 向其客户机(客户机 B)公开应用程序,用户 B 创建 VirtualServer B。
7,公共端点,它位于 IC 吊舱前面。这通常是一个 TCP 负载均衡器(云、软件或硬件),或者这种负载均衡器与 NodePort 服务的组合。客户端 A 和 B 通过公共端点连接到他们的应用程序。
黄色和紫色箭头表示与客户端通信量相关的连接,黑色箭头表示对 Kubernetes API 的访问。
为了简单,没有显示许多必要的 Kubernetes 资源,如部署和服务,管理员和用户也需要创建这些资源。
在 K8s 中,通常云厂商的 LB 一般云厂商提供适配 CNI,会在创建 K8s 集群时会自动创建 LB 类型的 servcie,例如阿里的 ACK,腾讯的 TKE,华为的 CCE 等,但是在我们自建或个人测试场景,开源的 Metallb[1] 是一个不错的选择,其作用通过 K8s 原生的方式提供 LB 类型的 Service 支持,开箱即用,当然还有青云科技 KubeSphere 团队开源的负载均衡器插件 OpenELB[2], 是为物理机(Bare-metal)、边缘(Edge)和私有化环境设计的负载均衡器插件,可作为 Kubernetes、K3s、KubeSphere 的 LB 插件对集群外暴露“LoadBalancer”类型的服务。在 2021 年 11 月已进入 CNCF 沙箱(Sandbox)托管,也是解决用户将 Kubernetes 集群部署在裸机上,或是私有化环境特别是物理机或边缘集群,Kubernetes 并不提供 LoadBalancer 的痛点,提供与基于云的负载均衡器相同的用户体验。
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)