最近在看kube-proxy ipvs的源码，发现用了很多年的LVS而且NAT模式居多的我尽然不知道原来LVS可以利用Iptables实现SNAT模式。很长时间以来一直以为LVS的NAT模式只支持DNAT，真是印证了“纸上得来终觉浅，绝知此事要躬行”，还是要多读源码。

惯用思路，先实践验证后分细原理。

iptables规则设置用法

iptables的基本语法格式

iptables [-t 表名] 命令选项 ［链名］ ［条件匹配］ ［-j 目标动作或跳转］
说明：
表名、链名：用于指定iptables命令所操作的表和链；
命令选项：用于指定管理iptables规则的方式（比如：插入、增加、删除、查看等；
条件匹配：用于指定对符合什么样 条件的数据包进行处理；
目标动作或跳转：用于指定数据包的处理方式（比如允许通过、拒绝、丢弃、跳转（Jump）给其它链处理。

iptables简介

netfilter/iptables IP 信息包过滤系统是一种功能强大的工具，可用于添加、编辑和除去规则，这些规则是在做信息包过滤决定时，防火墙所遵循和组成的规则。这些规则存储在专用的信息包过滤表中，而这些表集成在 Linux 内核中。在信息包过滤表中，规则被分组放在我们所谓的链（chain）中。

概述

用简单的话来定义tcpdump，就是：dump the traffic on a network，根据使用者的定义对网络上的数据包进行截获的包分析工具。

tcpdump可以将网络中传送的数据包的“头”完全截获下来提供分析。它支持针对网络层、协议、主机、网络或端口的过滤，并提供and、or、not等逻辑语句来帮助你去掉无用的信息。

tcpdump基于底层libpcap库开发，运行需要root权限。

iperf测试带宽

iperf是开源的跨平台网络带宽测试工具，支持windows、linux、macos、bsd等众多系统。可以测试带宽吞吐量、延迟、丢包等；支持使用TCP和UDP测试，结果比较准。由于是C/S架构，使用时需要在测试宽带的两端分别运行一个装有iperf的电脑，我是测试连接两个机房的专线，直接拿机房里的Linux服务器测试。
iperf有两个版本，一个是iperf2和iperf3,建议使用iperf3,iperf2比较老，对10G网卡测试速度上不来。两个版本用法基本上是一样的，我这里是测试百兆的带宽，以ipser2来做演示

IPVS简介

我们接触比较多的是应用层负载均衡，比如haproxy、nginx、F5等，这些负载均衡工作在用户态，因此会有对应的进程和监听socket，一般能同时支持4层负载和7层负载，使用起来也比较方便。

LVS是国内章文嵩博士开发并贡献给社区的（章文嵩博士和他背后的负载均衡帝国 )，主要由ipvs和ipvsadm组成，ipvs是工作在内核态的4层负载均衡，和iptables一样都是基于内核底层netfilter实现，netfilter主要通过各个链的钩子实现包处理和转发。ipvsadm和ipvs的关系，就好比netfilter和iptables的关系，它运行在用户态，提供简单的CLI接口进行ipvs配置。

目的

使用Service Mesh 拥抱云原⽣，拥抱开源社区已经成为⼈尽皆知的共识。
Service Mesh 体系中，使⽤ kubernetes Service 是必不可少的⼀环，在我们逐步迁移服务到Mesh体系的过
程中发现，存在部分应⽤的某些调⽤接经常超时。
经过我们的排查，这些出问题的调⽤往往是通过短链接的⽅式来访问的。
在使⽤短链接时，每次调⽤都会建⽴新的连接，这也会伴随着⼀次次 DNS 查询。
DNS 查询速度成为了提⾼调⽤延迟的罪魁祸⾸。

简介

DeScheduler 是容器服务的一个基于 Node 真实负载进行重调度的插件。该插件会和 Kube-scheduler 协同生效，实时监控集群中高负载节点并驱逐低优先级 Pod。建议您搭配 Dynamic Scheduler（动态调度器扩展组件）一起使用，多维度保障集群负载均衡。
该插件依赖 Prometheus 监控组件以及相关规则配置。

问题

在 K8s 集群运营过程中，常常会被节点 CPU 和内存的高使用率所困扰，既影响了节点上 Pod 的稳定运行，也会增加节点故障的几率。为了应对集群节点高负载的问题，平衡各个节点之间的资源使用率，应该基于节点的实际资源利用率监控信息：

1. 在 Pod 调度阶段，应当优先将 Pod 调度到资源利用率低的节点上运行，不调度到资源利用率已经很高的节点上

问题背景

全球主要的容器集群服务厂商的Kubernetes服务都提供了Nvidia GPU容器调度能力，但是通常都是将一个GPU卡分配给一个容器。这可以实现比较好的隔离性，确保使用GPU的应用不会被其他应用影响；对于深度学习模型训练的场景非常适合，但是如果对于模型开发和模型预测的场景就会比较浪费。 大家的诉求是能够让更多的预测服务共享同一个GPU卡上，进而提高集群中Nvidia GPU的利用率。而这就需要提供GPU资源的划分，而这里GPU资源划分的维度指的就是GPU显存和Cuda Kernel线程的划分。通常在集群级别谈支持共享GPU，通常是两件事情：