关于云计算:Kubernetes-集群中流量暴露的几种方案

作者：KaliArch（薛磊），某 Cloud MSP 服务商产品负责人，相熟企业级高可用 / 高并发架构，包含混合云架构、异地灾备，纯熟企业 DevOps 革新优化，相熟 Shell/Python/Go 等开发语言，相熟 Kubernetes、Docker、云原生、微服务架构等。

背景

在业务应用 Kubernetes 进行编排治理时，针对业务的南北流量的接入，在 Kuberentes 中通常有几种计划，本文就接入的计划进行简略介绍。

流量接入计划

Kuberentes 社区通过为集群增设入口点的计划，解决对外流量的治理。

通过 kube-proxy 进行代理

通常在最简略的测试或集体开发环境，能够通过 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 形式

其次较罕用的为 NodePort 形式，将 K8s 中 service 的类型批改为 NodePort 形式，会失去一个端口范畴在 30000-32767 端口范畴内的宿主机端口，同样改宿主机具备公网 IP 就能够实现对服务的裸露，然而 NodePort 会占用宿主机端口，一个 Service 对应一个 NodePort，该形式仅为四层，无奈实现 SSL 证书的卸载，如果将服务转发到单个 Node 节点的 NodePort 也无奈实现高可用，个别须要在 NodePort 前搭配负载平衡来增加多个后端 NodePort 已实现高可用。

LoadBalancer

四层

四层流量转发一个 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 级别都具备四层和七层的性能，配合应用能够实现灵便的业务流量裸露。

Ingress

在 K8s 中，存在有 Ingress 资源来实现单个域名转发依据不同的门路或其余配置规定转发到 K8 集群外部不同的 Service，然而用户申请须要拜访 Ingress 实现控制器的 NodePort 例如 Ingress-nginx 的 Controller 的 Service 的 NodePort，针对具体的业务域名个别不会带端口，所以个别后面还须要一层 80/443 的端口转发。

个别 Ingress 的 Controller 实现业界也有不少解决方案，例如比拟出名的 Ingress—nginx/Ingress-traefik 等。

LoadBalancer + Ingress

如下图所示在最后面有一个四层 LB 实现端口 80/443 转发至 ingress-provider 的 Service 的 NodePort，K8s 集群外部配置有多个 service。

Ingress-nginx 详解

在下面的几种计划中，均有用到 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 的应用场景。

图中展现如下信息：

• 一个 K8s 集群
• 集群用户治理、用户 A 和用户 B，它们通过 Kubernetes API 应用集群。
• 客户端 A 和客户端 B，它们连贯到相应用户部署的应用程序 A 和 B。
• IC，由 Admin 部署在名称空间 nginx-ingress 中的 pod 中，并通过 ConfigMap nginx-ingress 进行配置。Admin 通常部署至多两个 pod 以实现冗余。IC 应用 Kubernetes API 获取集群中创立的最新入口资源，而后依据这些资源配置 NGINX。
• 应用程序 A 由用户 A 在命名空间 A 中部署了两个吊舱。为了通过主机 A.example.com 向其客户机（客户机 A）公开应用程序，用户 A 创立入口 A。
• 用户 B 在命名空间 B 中部署了一个 pod 的应用程序 B。为了通过主机 B.example.com 向其客户机（客户机 B）公开应用程序，用户 B 创立 VirtualServer B。
• 公共端点，它位于 IC 吊舱后面。这通常是一个 TCP 负载均衡器（云、软件或硬件），或者这种负载均衡器与 NodePort 服务的组合。客户端 A 和 B 通过公共端点连贯到他们的应用程序。

黄色和紫色箭头示意与客户端通信量相干的连贯，彩色箭头示意对 Kubernetes API 的拜访。

为了简略，没有显示许多必要的 Kubernetes 资源，如部署和服务，管理员和用户也须要创立这些资源。

其余

在 K8s 中，通常云厂商的 LB 个别云厂商提供适配 CNI，会在创立 K8s 集群时会主动创立 LB 类型的 servcie，例如阿里的 ACK，腾讯的 TKE，华为的 CCE 等，然而在咱们自建或集体测试场景，开源的 Metallb 是一个不错的抉择，其作用通过 K8s 原生的形式提供 LB 类型的 Service 反对，开箱即用，当然还有青云科技 KubeSphere 团队开源的负载均衡器插件 OpenELB, 是为物理机（Bare-metal）、边缘（Edge）和私有化环境设计的负载均衡器插件，可作为 Kubernetes、K3s、KubeSphere 的 LB 插件对集群外裸露“LoadBalancer”类型的服务。在 2021 年 11 月已进入 CNCF 沙箱（Sandbox）托管，也是解决用户将 Kubernetes 集群部署在裸机上，或是私有化环境特地是物理机或边缘集群，Kubernetes 并不提供 LoadBalancer 的痛点，提供与基于云的负载均衡器雷同的用户体验。

本文由博客一文多发平台 OpenWrite 公布！