这是一本不太新的新书。 国内还没有中文版，据说是腾讯的大佬在翻译中了。 之前翻过一遍，上周末重读了一边。
O’Reilly 连接： https://learning.oreilly.com/library/view/cloud-finops/9781492054610/
对该书内容进行了简单的整理，并结合了一些周边资料。 该书理念介绍居多，也有一些方法论。
这是一篇长文。 真的很长，文章包含大量超链接，图也很多。
下文包含个人理解与主观情感，并未包含所有 Session。 图片来自会议 PPT、付费书籍、网络媒体。
会议议程及 PPT 下载： https://kccncosschn21.sched.com/
第一个主题演讲还提了一下 Dan Kohn。
突然有些唏嘘，如果没有 Dan Kohn，应该不会有 KubeCon China 吧。
躲在 LVS 后面，如何平滑的上下线是个问题
正常上线流程：
- Controller、Nginx 正常运行
- 加到 LVS 后面
- 应用流量接进来
正常下线流程：
- 从 LVS 摘掉
- 应用请求结束
- Controller、Nginx 退出
官方默认的配置肯定做不到。
- Ingress Controller，和 Kubernetes API 通信，实时更新 Nginx 配置。
- Ingress Nginx，实际运行转发、规则的载体。
Ingress 是一个原生的 Kubernetes 资源，可以通过规则将外部流量转发到集群内部的服务 Endpoint。
Ingress 需要借助 Ingress Controller 来转发 Ingress 对象所指定的规则。
kube-proxy 是一个 4 层的接入层。 kube-proxy 主要是靠 iptables 内核转发，有问题基本无法定位，全靠猜，相对黑盒。
Ingress 是一个 7 层的、能转发的、可编程的一个接入层。 流量数据近乎透明。
希望探究复杂系统如何应对异常时，对系统中的服务注入通信故障、超时、错误等，这是一个故障注入的典型场景。 希望探究更多其他的非故障类的场景，流量激增、资源竞争条件、拜占庭故障、非计划中的或非正常组合的消息处理等等。
和故障注入类似，故障测试方法通过对预先设想到的可以破坏系统的点进行测试，但是并没能去探究上述这类更广阔领域里的、不可预知的、但很可能发生的事情。
在测试中，要进行断言：即给定一个特定的条件，系统会输出一个特定的结果。 测试一般来说只会产生二元的结果，验证一个结果是真还是假，从而判定测试是否通过。 严格意义上来说，这个实践过程并不能发掘出系统未知的或尚不明确的认知，它仅仅是对已知的系统属性可能的取值进行测验。 而实验可以产生新的认知，而且通常还能开辟出一个更广袤的对复杂系统的认知空间。
故障注入则是对一个特定的条件、变量的验证方法。 混沌工程是发现新信息的实践过程。