流量卡代理批发(流量卡批发多少钱一张)

今天分享与云端的流量入口、流量代理有关。

一些云平台的部署架构、拓扑结构图有很多对流量代理、入口的界定不是很清晰。有的把 ingress 当成流量代理、有的认为是 K8S service、有的认为是 kube-proxy 等。其实以上都不是流量代理。

ingress 是 K8S 的一种原生资源 (有别于 CRUD 的自定义资源)，是描述具体的路由规则的。

Ingress Controller 才是流量的入口，是名副其实的流量代理，也可以称为边缘服务 (集群内与集群外流量网关)，纵向流量 (有叫南北流量的说法)，一般是 Nginx 、traefik 和 Haproxy（较少使用）。

Ingerss 描述了一个或者多个域名的路由规则，以 ingress 资源的形式存在。

简单说：Ingress 描述路由规则。

可以认为 ingress 其实就是一个配置文件而已，在你真正访问 pod 应用的时候没起任何作用，但是这个配置文件又不能删除，因为 Ingress Controller 实时实现规则。Ingress Controller 会监听 api server 上的 /ingresses 资源并实时生效。

Ingress Controller 实时监听 api server 上 ingresses ，如果ingresses没有了，会马上删除自身的反向代理配置，就无法再进行访问。

Ingress Controller 流量代理自身的部署方式以及服务类型决定了整个 K8S 的流量瓶颈，是每个节点的流量决定，还是整个集群所有的节点一起决定的，这个后面再细讲。

接下来，service 与 kube-proxy 是否是流量代理的分析。

ingerss 与 service 的关系：

ingress 在前，service 在后，前者不是流量代理，顺利成章的会认为是后者，其实也不然。

Kubernetes Service 定义了这样一种抽象：Service 是一种可以访问 Pod 逻辑分组的策略， Service 通常是通过 Label Selector 访问 Pod 组。

Service 能够提供负载均衡的能力。

Service 有以下种类型：

ClusterIp、NodePort、LoadBalancer (升级版 nodeport)

Service 也只仅仅是一种策略，也不是应用每次被访问时，需要经过的组件，也不负载流量的转发。

这里可能会有疑问，不负载流量转发，怎么又能实现这么多类型的服务，又怎么实现负载均衡的。

这时候就该神奇的 kube-proxy K8S 组件闪亮登场了。

kube-proxy 是 Kubernetes 的核心组件，部署在每个 Node 节点上，它是实现 Kubernetes Service 的通信与负载均衡机制的重要组件；kube-proxy 负责为 Pod 创建代理服务，从 apiserver 获取所有 server 信息，并根据 server 信息创建代理服务，实现 server 到 Pod 的请求路由和转发，从而实现 K8s 层级的虚拟转发网络。

在 k8s 中，提供相同服务的一组 pod 可以抽象成一个 service，通过 service 提供的统一入口对外提供服务，每个 service 都有一个虚拟 IP 地址（VIP）和端口号供客户端访问。kube-proxy 存在于各个 node 节点上，主要用于 Service 功能的实现，具体来说，就是实现集群内的客户端 pod 访问 service，或者是集群外的主机通过 NodePort 等方式访问 service。在当前版本的 k8s 中，kube-proxy 默认使用的是 iptables 模式，通过各个 node 节点上的 iptables 规则来实现 service 的负载均衡，但是随着 service 数量的增大，iptables 模式由于线性查找匹配、全量更新等特点，其性能会显著下降。

kube-proxy 当前实现了三种代理模式：userspace, iptables, ipvs。其中 userspace mode 是 v1.0 及之前版本的默认模式，从 v1.1 版本中开始增加了 iptables mode，在 v1.2 版本中正式替代 userspace 模式成为默认模式。也就是说 kubernetes 在 v1.2 版本之前是默认模式，v1.2 版本之后默认模式是 iptables。

linux 分 User space (用户空间) 和 Kernel space (内核空间)。在 K8S 1.0 版本之前，kube-proxy 确实是流量代理。

每次的访问都是从 User space 到 Kernel space 再到 User space 里的 kube-proxy。

显然这种方式会因为 K8S 底层组件的流量瓶颈，会影响整个上层应用生态。

使用 userspace 的资源，比使用 kernelspace 的资源要昂贵的多，这里引申一下，能用 TCP 的场景，要比用 HTTP 的节省资源。其他先不分析，就工作层级来讲 TCP 是工作在 kernelspace ，http 是 userspace 是应用层协议。

第二个阶段，iptables mode, 该模式完全利用内核 iptables 来实现 service 的代理和 LB, 这是 K8s 在 v1.2 及之后版本默认模式。

kube-proxy 在第二阶段使用 iptables mode 时，已经部署流量代理了，这些都交给节点机器的 iptables 路由表来流量转换了，而 kube-proxy 只需要从 api server 拿到 service 的策略配置，来实时维护好 iptables 即可。

第二阶段，随着服务越来越多，维护 Node 上的 iptables rules 将会非常庞大，性能还会再打折扣。

故迎来了第三阶段 ipvs mode.，当下一般的云都是这种模式：

在 kubernetes 1.8 以上的版本中，对于 kube-proxy 组件增加了除 iptables 模式和用户模式之外还支持 ipvs 模式。kube-proxy ipvs 是基于 NAT 实现的，通过 ipvs 的 NAT 模式，对访问 k8s service 的请求进行虚 IP 到 POD IP 的转发。

kubedns/coredns 这个就是 K8S 的 dns 服务器而已，不是流量代理，只提供了一个服务名、主机名等的 DNS 解析。

kube-proxy 经过以上阶段，也不是流量代理了，不会是应用访问的流量影响者。

综合以上分析，现在来看，流量控制代理瓶颈，不会出现在 K8S 的 service，kube-proxy只有可能出现在 ingress-controller。实际 k8s 官方也提供了 ingress-controller 的实现，只是也不太好用，现在基本都用 Nginx 、traefik、Haproxy。

来说下 Nginx 吧，早期版本部署是通过 DaemonSet 的方式，这种方式就是每个节点启用一个 nginx 代理，但是会把当前节点机器的 80、443 端口占用掉。因为 Nginx 自身的 service 的暴露类型是采用的 hostport 方式类似与 nodeprot 但是没负载均衡，就是只能用 POD 所在的节点机器 IP 访问到。

好在是 DaemonSet 方式，反正每个机器都有，用每个节点的 IP 都能访问到 nginx 服务，然后反向代理到应用的服务，后面流量网关也进行了部署升级，例如华为云，不用 DaemonSet，不用每台都启动，启动几个 pod 就行，自身的 service 也通过 LoadBalancer 类型暴露了。

LoadBalancer 类型是需要负载均衡器来支持了，这种类型，如果采用类似 BGP 模式，理论上相当于 K8S 集群每个节点的都可以成为流量入口。相当于 ingress-controller 作为流量入口，流量网关，它理论上可以做到，K8S 的所有节点都能充当入口。以达到流量的最大化。

今天的分析就到这了，梳理了一个论点，即：ingress-controller 才是流量代理，ingress、service、kube-proxy 都不是，理论上可以做到流量的最大化，K8S 从机制上来看，没有流量瓶颈的桎梏。要有也是节点机器、其它方面的。

本站部分内容由互联网用户自发贡献，该文观点仅代表作者本人，本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规等内容，请举报！一经查实，本站将立刻删除。

流量卡代理批发(流量卡批发多少钱一张)

相关推荐