在业务使用Kubernetes进行编排管理时，针对业务的南北流量的接入，在Kuberentes中通常有几种方案，本文就接入的方案进行简单介绍。

二 流量接入方案

Kuberentes社区通过为集群增设入口点的方案，解决对外流量的管理。

2.1 通过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

2.1 NodePort方式

其次较常用的为NodePort方式，将K8s中service得类型修改为NodePort方式，会得到一个端口范围在30000-32767端口范围内的宿主机端口，同样改宿主机具有公网IP就可以实现对服务的暴露，但是NodePort会占用宿主机端口，一个service对应一个NodePort，该方式仅为四层，无法实现SSL证书的卸载，如果将服务转发到单个Node节点的NodePort也无法实现高可用，一般需要在NodePort前搭配负载均衡来添加多个后端NodePort已实现高可用。

2.2 LoadBalancer

2.2.1 四层

四层流量转发一个LB的端口只能对应一个Service，Servcie的Type为NodePort，例如如下图，LoadBalancer上的88端口对应转发到后端NodePort的32111端口，对应到servcieA；LB上的8080端口对应转发到后端NodePort32001端口；该方案可以通过添加多个NodePort方式实现高可用，但是由于为四层无法实现对SSL的卸载，对应NodePort需要在LB占用一个端口。

2.2.2 七层

七层可以借助LB的域名转发，实现一个域名端口对应多个service，如图可以根据path路径，/cmp对应NodePort的32111，/gateway 对应NodePort的32000端口，不仅可以实现高可用，而且七层可以实现SSL卸载。

目前一般公有云的LB级别都具备四层和七层的功能，配合使用可以实现灵活的业务流量暴露。

2.3 Ingress

在K8s中，存在有Ingress资源来实现单个域名转发根据不同的路径或其他配置规则转发到K8s集群内部不同的service，但是用户请求需要访问ingress实现控制器的NodePort例如Ingress-nginx的controller的service的NodePort，针对具体的业务域名一般不会带端口，所以一般前面还需要一层80/443的端口转发。 一般Ingress的controller实现业界也有不少解决方案，例如比较知名的Ingress—nginx/Ingress-traefik等。

2.4 LoadBalancer + Ingress

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

三 其他

在K8s中，通常云厂商的LB一般云厂商提供适配CNI，会在创建K8s集群时会自动创建LB类型的servcie，例如阿里的ACK，腾讯的TKE，华为的CCE等，但是在我们自建或个人测试场景，开源的​​Metallb​​是一个不错的选择，其作用通过k8s原生的方式提供LB类型的Service支持，开箱即用。