#云原生征文#K8s集群流量暴露的几种方案 原创 精华

KaliArch
发布于 2022-6-9 09:01
浏览
1收藏

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

一 背景

在业务使用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已实现高可用。

#云原生征文#K8s集群流量暴露的几种方案-鸿蒙开发者社区

2.2 LoadBalancer

2.2.1 四层

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

#云原生征文#K8s集群流量暴露的几种方案-鸿蒙开发者社区

2.2.2 七层

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

#云原生征文#K8s集群流量暴露的几种方案-鸿蒙开发者社区

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

2.3 Ingress

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

一般Ingress的controller实现业界也有不少解决方案,例如比较知名的Ingress—nginx/Ingress-traefik等。

#云原生征文#K8s集群流量暴露的几种方案-鸿蒙开发者社区

2.4 LoadBalancer + Ingress

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

#云原生征文#K8s集群流量暴露的几种方案-鸿蒙开发者社区

三 其他

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

四 other

【本文正在参加云原生有奖征文活动】,活动链接:https://ost.51cto.com/posts/12598

©著作权归作者所有,如需转载,请注明出处,否则将追究法律责任
分类
4
收藏 1
回复
举报
回复
    相关推荐