next kubernetes: 旌旗招展，向网格而行！
本篇目录
说明
你还在彷徨吗？还在犹豫吗？还是找不到方向吗？别纠结了，直接搞网格！
kubernetes 之后要做的事情
现在的网格就是 3~4 年前的 kubernetes，kubernetes 带来的效益是非常显著的。
不知道 kubernetes 刚开始流行的时候，你是否向老板描绘过的美好的蓝图，现在用 kubernetes 带来的好处向老板「邀功」一点都不过分。
投入生产的 kubernetes 集群，规模再小，大概也得有 100 多台服务器？
可以看一下现在有多人在维护这些服务器，是不是比以前少了很多？可以走访一下基于 kubernetes 的 PaaS 平台的用户，他们是否还需要关心服务器或者虚拟机的工作状态？他们是否还需要安排专职运维负责系统的部署更新，并在扩容、缩容时紧张到鸡飞狗跳？
日常只需 3~5 人维护的 kubernetes 平台就可以支撑公司十几个到几十个业务线的运作。不仅如此，每条业务线需要操心的事情大大减少，可以全身心地专注于业务系统的开发，为公司节省了大量的人力物力。
经过 3 年的努力，技术人员成功地「革」了自己的命，消灭了大量的工作岗位，把这样的成就摆在老板面前，哪个老板不喜笑颜开？ 然而，这只是万里长征的一小步，开明的技术人员总是眼光向前，因为前方等待开垦的处女地还有很多，需要被优化提效率的地方还有很多！
下一步要做的是： 用被认为技术上依旧不够成熟的「网格」，去掉更多繁琐的事情！
网格能够带来什么？
如果你是习惯采购软件系统的超级甲方，你可以跟老板说：
我们总共从十几家供应商采购了数十套软件系统，每一套软件系统都自成体系，各用各的基础组件。为了提高可靠性每个基础组件又都有各自的备份，占用了非常多的资源。 采购成本和维护成本高居不下，开支一年比一年高，即使这样，巨额投入分散到数十套系统后，每套系统的运营保障投入都不足。
使用网格之后，有足够的理由要求供应商将系统接入网格。网格完全独立于供应商的软件系统，供应商不能以技术上做不到的理由拒绝接入或者索要额外的定制费用。
这样一来，可以将基础组件的冗余程度控制在合理水平，在总投入不变甚至降低的情况下，提高保障能力。自己的技术人员从此可以专注于单一组件的维护，成为经验丰富的技术专家，极大的提升公司的技术实力，公司每年巨额的技术投入将有效地沉淀保留，从纯粹的「消耗性支出」转变为「技术资产」。
如果你是技术实力超级强大的互联网公司，你可以跟同事说：
这个基础服务现在只有 java 接口，有个必须使用 python 开发的机器学习项目因为没有对应的 sdk 而用不了，另外还有用 C、C++、js、Go、Rust 等开发的项目也想使用，都因为没有 sdk 而放弃了。用了网格之后，这些都不是事，把接入层做到 sidecar 中，从此接入和编程语言无关。只需要维护一个 sidecar，什么语言都可以很方便地对接基础服务。
并且，业务程序通过 sidecar 接入后，基础服务可以随时升级降级，业务程序完全无感知。
用户视角的常规功能
引入服务网格之后，用户眼里的平台功能：
1）持续集成/CI：代码提交后自动打包成镜像；
2）持续发布/CD：镜像生成后自动完成部署，自动触发测试；
3）负载均衡/LB：流量自动分散到多个实例、复杂网关功能；
4）自动恢复/Recover：故障实例自动摘除，自动重建新实例；
5）资源池/Resource：一键扩缩规模，资源随用随取。
6）统一日志/Log：一站式日志查看；
7）统一监控/Monitor：全景式状态展示、自动告警；
8）统一认证/Auth：人员与服务、服务与服务的访问控制；
9）统一接入/AllInOne：用一种对升级无感知的方式接入消息、缓存、服务框架等系统。
平台规划时需要考虑的事情
1）集群与外部的网络联通方法，Pod 级别联通还是服务级别联通；
2）集群内服务的对外呈现方式，域名还是 vip；
3）Pod 数据持久化方案；
4）集群外部服务的集成方式；
5）外部访问日志、内部调用链日志、应用程序运行日志的收集展示；
6）服务的访问控制，团队内可见/集群内可见/内网可见/外网可见；
平台实施时需要考虑的事情
大量细节位于 《不一样的 双11 技术，阿里巴巴经济体云原生实践》阅读笔记 中，这里只简单摘录。
1）采用哪种网络方案，开源的 flannel 等，还是复用 IaaS 的 SDN 网络？
蚂蚁金服姚捷分享：
集团电商的容器运行在云上神龙反而比非云物理机的性能要好 10%～15%，主要原因是因为虚拟化开销已经 offload 到 MOC 卡上，神龙的 CPU/Mem 是无虚拟化开销的，而上云后运行在神龙上的每个容器都独享 ENI 弹性网卡，性能优势明显。同时每个容器独享一块 ESSD 块存储云盘，单盘 IOPS 高达 100 万，比 SSD 云盘快 50 倍，性能超过了非云的 SATA 和 SSD 本地盘。
2）负载均衡组件如何设计？统一网关还是独占网关？
3）现有的调度系统在功能上是否满足需求，调度性能是否理想？
蚂蚁金服的曹寅分享：
社区的调度器在 5k 规模测试中，调度性能只有 1~2 pod/s。
4）怎样将各种基础服务的接口下沉到 sidecar ？
需要一事一议，http 的请求的代理时最简单。
蚂蚁金服方克明分享：
NAT 表所使用到的 nf_contrack 内核模块因为效率很低而在阿里巴巴的线上生产机器中被去除了，因此无法直接使用社区的方案。OS团队探索了通过基于 userid 和 mark 标识流量的透明拦截方案，基于 iptables 的 mangle 表实现了一个全新的透明拦截组件。
由于 RPC 的 SDK 仍存在以前的服务发现和路由逻辑，而该流量被劫持到 Envoy 之后又会再做一次，这将导致 Outbound 的流量会因为存在两次服务发现和路由而增加 RT，以终态落地 Service Mesh 时，需要去除 RPC SDK 中的服务发现与路由逻辑，将相应的 CPU 和内存开销给节约下来。
未来计划在 Istio/Envoy 的标准路由策略之外，设计一套基于 Wasm 的路由插件方案，让那些简单的路由策略以插件的形式存在。如此一来，既减少对标准路由模块的侵入，也在一定程度上满足业务方对服务路由定制的需要。
5）怎样做到 sidecar 的无感升级？
蚂蚁金服方克明分享：
热升级采用双进程方案，先拉起新的 Sidecar 容器，由它与旧的 Sidecar 进行运行时数据交接，在新的 Sidecar 准备发接管流量后，让旧的 Sidecar 等待一定时间后退出，最终实现业务流量无损。核心技术主要是运用了 Unix Domain Socket 和 RPC 的节点优雅下线功能。
6）配置策略的下发更新是否及时？单点故障的影响范围是怎样的？
蚂蚁金服的敖小剑分享：
Mixer 的性能问题，一直都是 Istio 中最被人诟病的地方。尤其在 Istio 1.1/1.2 版本之后引入了 Out-Of-Process Adapter，更是雪上加霜。从落地的角度看，Mixer V1 糟糕至极的性能，已经是“生命无法承受之重”。对于一般规模的生产级落地而言，Mixer 性能已经是难于接受，更不要提大规模落地……
Mixer V2 方案则给了社区希望：将 Mixer 合并进 Sidecar，引入 web assembly 进行 Adapter 扩展，这是我们期待的 Mixer 落地的正确姿势，是 Mixer 的未来，是 Mixer 的“诗和远方”。然而社区望穿秋水，但Mixer V2 迟迟未能启动，长期处于 In Review 状态，远水解不了近渴。
Pilot 目前主要有两大问题，1、无法支撑海量数据，2、每次变化都会触发全量推送，性能较差；我们的方案是保留独立的 SOFA 服务注册中心来支持千万级的服务实例信息和秒级推送，业务应用通过直连 Sidecar 来实现服务注册和发现。
7）如何快速高效的增加、缩减业务系统占用的资源？
蚂蚁金服曹寅分享：
Pod 数量不动，改变 Pod 的运行状态，需要多干活的应用把 Pod 设置为运行态多占资源，需要出让资源的应用把 Pod 设置为保活态，少占资源。将不重叠的业务实例放在相同资源池内，通过分时调度腾挪资源。
8）自带调度功能的复杂系统如何自行规划资源？
蚂蚁金服曹寅分享：
向业务方开放 CRD + Operator，较弱的 apiserver 和灵活的 Operator 对集群的稳定性形成巨大挑战，总结出一套实践原则：
- CRD 在定义是要明确未来最大数量，大量 CRD 业务采用 aggregate-apiserver 扩展;
- CRD 必须限定于 namespace 范围内，影响范围最低；
- 避免使用 MutatingWebhook + 资源 Update 操作；
- 所有 controllers 都使用 informers，并对写操作限流；
- DaemonSet 尽量不用。
9) 支撑组件的持续优化，譬如 etcd 性能优化、容器镜像分发优化、容器技术改进。
etcd 优化，阿里云陈星宇分享：
segregated hashmap 的 etcd 内部存储 freelist 分配回收新算法，该优化算法将内部存储分配算法时间复杂度从 o(n) 降为 o(1), 回收从 o(nlgn) 也降为 o(1), 使 etcd 性能有了质的飞跃，极大地提高了 etcd 存储数据的能力，使得 etcd 存储容量从推荐的 2GB 提升到 100GB，提升 50 倍，读写性能提升 24 倍。
容器镜像分发，阿里云杨育兵分享：
ContainerFS 团队合作共建了第三代镜像分发方案：DADI，基于块设备的按需p2p加载技术；
容器技术改进，阿里云杨育兵分享：
和集团 os 创新团队以及蚂蚁 os 虚拟化团队合作共建了 kata 安全容器和 gvisor 安全容器技术，兼容性要求高的场景我们优先推广 kata 安全容器。
PouchContainer 把 diskquota、lxcfs、dragonfly、DADI 这写特性都做成了可插拔的插件，对一些场景做了 containerd 发行版，支持纯粹的标准 CRI 接口和丰富的运行时；
参考
