Linux虚拟化、流量治理

大规模 Kubernetes 集群故障注入的利器-ChaosBlade

Linux 虚拟化
对于 Linux 虚拟化技术而言，核心实现原理就是 Linux Namespace 的隔离能力、Linux Cgroups 的限制能力，以及基于 rootfs 的文件系统；

Linux Namespace 可以让进程（容器）处在一个独立的沙箱环境，Linux Cgroups 可以限制该沙箱内进程的资源使用，比如限制 CPU、内存的使用率等等；

Linux Cgroups
Linux Cgroups 可以限制沙箱内进程的资源使用，并且也可以人为将某个进程的资源使用交给已经存在的某个的 Linux Cgroups 控制，而通常容器的资源使用率统计也是 Linux Cgroups 控制组下面进程的使用情况计算出来的；此时在宿主机启动的一个 CPU 负载的进程，并且将改进程交给某个已经存在的容器的控制组控制，就相当于给该容器注入了 CPU 负载场景。
在 docker 上面尝试在不侵入该容器的情况下，给容器 nginx 注入 CPU 负载的场景。

Linux Namespace
通过 Linux Cgroups 做到了不侵入该容器的情况下，给该容器注入 CPU 负载的场景，同时也能支持CPU 高负载、内存占用高、IO 高负载等等； 对于其他类型的故障，比如网络延时、文件删除等等，则需要通过另外一种方式来实现 ， 就是 Linux Namespace 的隔离能力
Linux Namespace 网络、IPC、MNT 等命名空间隔离的能力，在容器独立的 Namespace 下，新建一个文件，新启动一个进程等等操作也是其他容器不可感知和观测到的；

Linux的namespace

Linux内核namespace机制
Linux Namespaces机制提供一种资源隔离方案。PID,IPC,Network等系统资源不再是全局性的，而是属于某个特定的Namespace。每个namespace下的资源对于其他namespace下的资源都是透明，不可见的。因此在操作系统层面上看，就会出现多个相同pid的进程。系统中可以同时存在两个进程号为0,1,2的进程，由于属于不同的namespace，所以它们之间并不冲突。而在用户层面上只能看到属于用户自己namespace下的资源，例如使用ps命令只能列出自己namespace下的进程。这样每个namespace看上去就像一个单独的Linux系统。

“天猫双11”背后的流量治理技术与标准实践

我们从微服务流量的视角来看，可以粗略分为两类常见的运行时场景：

• 服务自身流量超过承载能力导致不可用。比如激增流量、批量任务投递导致服务负载飙高，无法正常处理请求。

• 服务因依赖其他不可用服务，导致自身连环不可用。比如我们的服务可能依赖好几个第三方服务，假设某个支付服务出现异常，调用非常慢，而调用端又没有有效地进行预防与处理，则调用端的线程池会被占满，影响服务自身正常运转。在分布式系统中，调用关系是网状的、错综复杂的，某个服务出现故障可能会导致级联反应，导致整个链路不可用。

OpenSergo 流量防护与容错标准
在 OpenSergo 中，我们结合 Sentinel 等框架的场景实践对流量防护与容错抽出标准 CRD。一个容错治理规则 (FaultToleranceRule) 由以下三部分组成：
• Target: 针对什么样的请求。可以通过通用的 resourceKey（Sentinel 中即为资源名的概念）来标识，也可以用细化的规则来标识（如具有某个特定 HTTP header 的请求）
• Strategy: 容错或控制策略，如流控、熔断、并发控制、自适应过载保护、离群实例摘除等
• FallbackAction: 触发后的 fallback 行为，如返回某个错误或状态码