作者：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 已完结高可用。

Kubernetes 集群中流量暴露的几种方案

LoadBalancer

四层

四层流量转发一个 LB 的端口只能对应一个 Service，Servcie 的 Type 为 NodePort，例如如下图，LoadBalancer 上的 88 端口对应转发到后端 NodePort 的 32111 端口，对应到 servcieA；LB 上的 8080 端口对应转发到后端 NodePort32001 端口；该计划能够经过增加多个 NodePort 方法完结高可用，但是因为为四层无法完结对 SSL 的卸载，对应 NodePort 需求在 LB 占用一个端口。

Kubernetes 集群中流量暴露的几种方案

七层

七层能够凭借 LB 的域名转发，完结一个域名端口对应多个 Service，如图能够根据 path 途径，/cmp 对应 NodePort 的 32111，/gateway 对应 NodePort 的 32000 端口，不仅能够完结高可用，而且七层能够完结 SSL 卸载。

Kubernetes 集群中流量暴露的几种方案

现在一般公有云的 LB 级别都具备四层和七层的功用，合作运用能够完结灵敏的事务流量露出。

Ingress

在 K8s 中，存在有 Ingress 资源来完结单个域名转发根据不同的途径或其他装备规则转发到 K8 集群内部不同的 Service，但是用户请求需求拜访 Ingress 完结控制器的 NodePort 例如 Ingress-nginx 的 Controller 的 Service 的 NodePort，针对具体的事务域名一般不会带端口，所以一般前面还需求一层 80/443 的端口转发。

一般 Ingress 的 Controller 完结业界也有不少处理计划，例如比较知名的 Ingress—nginx/Ingress-traefik 等。

Kubernetes 集群中流量暴露的几种方案

LoadBalancer + Ingress

如下图所示在最前面有一个四层 LB 完结端口 80/443 转发至 ingress-provider 的 Service 的 NodePort，K8s 集群内部装备有多个 service。

Kubernetes 集群中流量暴露的几种方案

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 的运用场景。

Kubernetes 集群中流量暴露的几种方案

图中展示如下信息：

  • 一个 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 发布！