微服务技术火遍中华大地，微服务是由一组pod对外提供的某个功能的抽象，pod由一个或多个容器组成，也是Kubernetes最小的管理单位。要想知道Kubernetes下微服务的稳定性如何做实验必须先回答3个问题：1) Kubernetes是一个什么样的平台? 2) 在这样一个平台上部署的微服务是什么样的呢？ 3) 在这样一个平台上的微服务稳定性如何做实验?
1. Kubernetes是一个什么样的平台?
Kubernetes是Google公司于2014年基于内部集群管理系统Borg开源的容器集群管理项目。该项目基于Go语言实现，试图为基于容器的微服务应用部署和管理打造一套强大并且易用的管理平台。
Kubernetes支持pod的创建、调度 、停止、删除以及自动弹性伸缩等生命周期管理。Kubernetes包括管理组件(Master)和节点组件(Node)，提供容器资源池。Master组件提供与管理相关的操作如调度、监控、资源操作等，并统计所管理的Node节点和微服务的资源使用情况。Node组件是实际运行微服务的计算实例。
2. 在这样一个平台上部署的微服务是什么样的呢？
1) 一个微服务的每个Pod内所有容器(单个或多个)共享内存、CPU和磁盘(PV持久化卷)；
2) 在Kubernetes中，Pod资源可以随时故障 ，在故障后通过副本控制器按照微服务的副本个数自动生成。当实际运行Pod副本个数超过数目，则终止某些Pod，反之则创建相应个数的Pod，还可以根据pod内应用的资源使用情况或业务情况进行自动弹性；
3) 一个微服务的每个Pod可以有多个容器，某个Pod内的各个容器可以是负载均衡的，一个任务的某一个请求可能到容器1，另一个请求到容器2；
4) 一个微服务内可以有2个相同的pod实例，pod实例间是主备的，可以部署在2个不同的node节点上，每次调用只到主pod实例上，只能故障其中1个pod实例。
5) 一个微服务内可以有3个相同的pod实例，pod实例间是负荷分担的，可以部署在3个不同的node节点上，每次调用均衡到pod实例上，高可用满足拜占庭故障，只要保证一半以上的pod实例正常运行即可，也就意味着只能1个pod实例故障。
6) 一个微服务拥有以上大多数的特点，微服务间或多或少有依赖。比如某个微服务要读写数据与数据库交互，数据库可能也是微服务。
3. 在这样一个平台上的微服务稳定性如何做实验?
通过第2部分介绍微服务运行故障后会自动恢复正常，微服务可以是主备的可以是负荷分担的，对外提供的服务不变对内接口调用随机的。举例登录系统通过配置界面修改告警配置信息并生效：首先登录要到安全中心认证并获取token以及用户的菜单权限，然后携带token到配置中心获取配置信息，修改提交配置参数后通过kafka广播给告警服务，告警服务收到kafka消息，将配置信息存到mysql数据库。
通过一次修改数据的消息流，看得出来这是一个复杂的系统，如果其中某一个环节出现故障，修改数据就不会成功。我们不应该着眼于发生故障的组件(当然定位问题应该从一个组件一个组件查起，出现问题的组件首当其中)，应该尝试去理解，像组件交互中一些偶发的意外行为一样，是什么导致系统整体滑向一个不稳定的状态。微服务的稳定性测试虽然没有明确的断言(给定一个特定的条件，系统会输出一个特定的结果)，要通过一次一次的实验来找出系统中脆弱的、易出故障的环节和不稳定的因素。
混沌工程正是这样一套通过在系统基础设施上进行实验，主动找出系统中的脆弱环节的方法学。通过实验验证的方法不仅可以打造更具弹性的系统，还可以掌握系统运行时的各种行为规律。
通过一次次的稳定性实验进行不断地探索，混沌工程能让复杂系统中根深蒂固的混乱和不稳定性浮出水面，让我们更加了解系统运行时的各种行为规律，让我们可以更全面地理解这些系统的固有现象，从而有根据地在分布式系统中实现更好的设计，不断提高系统的弹性。
做好混沌工程，保证微服务稳定性测试的质量，要遵守5项原则：
1) 建立稳定状态的假设；
2) 用多样的现实世界事件做验证；
3) 在生产环境中进行实验；
4) 自动化实验以持续运行；
5) 最小化爆炸半径。
做好混沌工程的2个关键步骤：
a) 首先要找到描述稳定状态的业务指标并建立稳定状态的假设；
b) 然后采用注入多样的现实世界事件的方式验证微服务稳定性；
需要什么样的环境?
在有状态、第三方系统和外部输入的生产环境中进行验证；
验证微服务稳定性有什么策略?
从最小爆炸半径开始，采用递进方式，从小规模的扩散实验到中规模的集中实验，最后到风险最大的大规模实验。不断叠加注入事件，逐渐扩大实验的规模，打造配套的实时监控系统，稳扎稳打步步为营。
验证微服务稳定性需要不需要自动化?
自动化是最长的杠杆，只需要做一次，但能收获无数次随时随地执行自动化实验所带来的好处。混沌工程的每次实验的规范化，可能一开始注入某个事件后对系统的影响检查点比较少，可以慢慢积累。