在业务使用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资源来实现单个域名转发根据不同的路径或其他配置规则转发到K8s集群内部不同的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的使用场景。
图中展示如下信息:
黄色和紫色箭头表示与客户端通信量相关的连接,黑色箭头表示对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” 类型的服务。在21年11 月已进入 CNCF 沙箱(Sandbox)托管,也是解决用户将 Kubernetes 集群部署在裸机上,或是私有化环境特别是物理机或边缘集群,Kubernetes 并不提供 LoadBalancer 的痛点,提供与基于云的负载均衡器相同的用户体验。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。