Kubernetes 集群中流量显示的几种方案
发布时间：2022-08-03 13:43:50 所属栏目：云计算 来源：互联网
导读：背景 在业务使用 Kubernetes 进行编排管理时，针对业务的南北流量的接入，在 Kuberentes 中通常有几种方案，本文就接入的方案进行简单介绍。 流量接入方案 Kubernetes 社区通过为集群增设入口点的方案，解决对外流量的管理。 通过 kube-proxy 进行代理 通常
|
背景 在业务使用 Kubernetes 进行编排管理时，针对业务的南北流量的接入，在 Kuberentes 中通常有几种方案，本文就接入的方案进行简单介绍。 流量接入方案 Kubernetes 社区通过为集群增设入口点的方案，解决对外流量的管理。 通过 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 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 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 实现。 （编辑：开发网_郴州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330466号