cloudvtech的博客

一、前言在文章《容器云平台负载均衡解决方案的一些思考》中提到“基于kubernetes nodeport service的IPVS负载均衡”非常适合基于Openshift/kubernetes的容器云的数据层面的负载均衡解决方案。本文对将IPVS容器化以及将IPVS用于部署在Openshift平台的服务的负载均衡所要涉及的技术点进行简要分析。转载自https://blog.csdn.net/clo...

content

一、前言IPVS的director上会绑定一个VIP，这个VIP是下游客户的唯一接入点，所以这个VIP需要满足高可用性的要求。另外，不同的VIP策略需要根据后端real server的部署状态进行更新。Keepalived是一个开源软件，主要提供loadbalancing（负载均衡）和 high-availability（高可用）功能，负载均衡实现需要依赖Linux的虚拟服务内核模块（IPVS），...

一、前言IPVS Direct Routing模式由于其机制的特殊性，需要在Director和real server上进行一些必要的内核参数配置来达到其特殊的VIP部署要求。在Director上需要配置的参数如下：net.ipv4.ip_forward = 1 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_r...

一、前言在测试基于Openshift的负载均衡器的时候，需要进行性能测试，所要要对系统进行一些性能调优，保证每个工作节点能处理巨大的数据流量，其中最重要的调整是对NIC的调整。在对NIC进行调整的时候，发现RSS(receive side scaling)和RPS(Receive Packet Steering)是两个需要关注的点。RSS和RPS都是网卡为了在接受数据包的时候使用多核架构而进行的性...

一、前言在cloud环境中，不是所有的application都有使用80端口这种特权端口的权限；但是在IPVS direct routing模式下，VIP监听的端口必须要保持和后端real server上的application监听的端口一致，见文章http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.rewrite_ports.html：本...

一、前言在《IPVS概览》一文中提到IPVS的Direct Routing模式是一个扩展性比较好的负载均衡方式。但是在默认的情况下，IPVS的Direct Routing模式需要指定一个Director，这个director负责绑定并对外暴露VIP，这个director所在的node上的进程是无法访问VIP获取后端real service的服务的。在一般系统中，这可能不是问题，因为IPVS dir...

一、前言在典型的网络服务模型中，请求流量/响应流量(Req/Res)比是很小的一个值；在直播、高清视频等视频多媒体服务中，请求响应流量比将更小(几十KB的请求V.S.几十MB的返回)。对于这样的应用场景，大量的请求可以通过负载均衡器进行接入，但是响应数据包是无法在某个中心节点进行汇聚在返回客户的。所以针对这种小请求响应比的服务，必须使用在响应返回路径没有汇聚点的负载均衡机制。根据响应数据包返回路径...

一、前言在文章《Kubernetes如何利用iptables对外暴露service》中提到了部署在Kubernetes上的服务对外暴露的方法，比如通过host port、cluster service、node external IP、external load balancer、node port等，这都是借助于iptables的功能在三层和四层进行的。在Openshift中，提供了另外一种基于...

一、前言IPVS是基于TCP四层(IP+端口)的负载均衡软件。IPVS会从TCP SYNC包开始为一个TCP连接所有的数据包建立状态跟踪机制，保证一个TCP连接中所有的数据包能到同一个后端。所以IPVS是基于TCP状态机进行控制管理，只感知TCP头而不对TCP的payload进行查看；因此，对IPVS后端服务器集群还有一个假定，那就是所有后端都具有同样的应用层的服务功能，但是由于IPVS可以给后端...

一、前言kubeadm是Kubernetes官方推出的快速部署Kubernetes集群工具，kubeadm通过将Kubernetes相关服务容器化以简化部署过程。在kubernetes 1.8以上的版本中，对于kube-proxy组件增加了除iptables模式和用户模式之外ipvs模式的支持。通过ipvs的NAT模式，对访问k8s service的请求进行虚IP到POD IP的转发。本文在kub...

一、前言kubernetes提供服务的实体(POD)具有内部网络空间的地址，外部无法直接访问，所以kubernetes提供了多种对外暴露POD服务的方法。这些方法都借助于kubernetes的service的概念，将一系列具有等同服务能力的POD组成一个抽象的服务实体，这个服务实体具有一个虚IP，这个虚IP可以是kubernetes cluster内部网络可达的IP(对应cluster servi...

一、前言在基于虚拟化的云系统中，网络虚拟化是不可或缺的关键部分。虚拟化的网络可以自由的在本地进行基于单机的网络配置或者借助一些互联技术(underlay、overlay或者点对点技术)在虚拟网络内部空间实现跨节点和数据中心的网络互联，但是如果虚拟网络内部的服务要对外进行暴露，就不得不借助地址转换或者端口转换等数据包修改技术。而在现有的container管理框架中，iptables更是承担了服务暴露...

一、前言kubernetes作为container的orchestration框架，主要的功能是在更高的层次对kubernetes服务和承载服务的实体(container)的部署、配置、可靠性进行管理，对应有namespace、POD、deployment、service等kubernetes的资源供application服务的提供者进行不同粒度上的配置和控制。同样，在网络层面，kubernete...

一、前言Kubernetes利用iptables达成以下两个目的：对外暴露POD和服务(通过host port、cluster service、node external IP、external load balancer、node port)简单的负载均衡在Kubernetes worker node的iptables的NAT表的prerouting和output 链表会出现如下规则作为kube...

前言网络的职责是将散落在不同范围的终端实体相互联通，并提供复杂的策略管理能力。根据终端实体散布的范围不同，可以由不同的网络设备和功能进行辅助，而路由和封装是最为常见的网络连接手段。路由方式适合大规模动态扩展并且发送效率较高，但是管理复杂度也更高，单个网络接入点需要感知周围网络的状态；封装方式配置相对简单，但是需要有耗费计算资源的封装步骤，并且不太利于创建动态可扩展的大规模网络。Container网...

一、方案分析在默认container 运行时(比如docker)的网络配置下，所有的container的数据包都会通过一个默认的bridge外加iptables的NAT进出，对于大流量或者大TPS的程序，基于Linux内核功能的bridge和NAT无疑会成为容器网络能力的瓶颈，可以使用macvlan的功能来提高container的网络能力。转载自https://blog.csdn.net/clou...