网易云基于Kubernetes的深度定制化实践
Posted DevOps技术栈
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了网易云基于Kubernetes的深度定制化实践相关的知识，希望对你有一定的参考价值。
网易云容器服务的架构
网易云的容器服务基于网易云的IaaS。为了简化用户的操作，Kubernetes并不是直接暴露给用户的，而是通过上层的业务层为用户提供容器服务，增加独立的Netease-Controller， 对接网易IaaS及公共平台，资源管理和复杂的业务需求。
网易云容器Pod网络
容器的网络主要有以下几种方案：
入门级：Docker 基础网络模型 host（共享），bridge(NAT)
进阶级：自建网桥(IP-per-pod)，可跨主机通讯，如Flannel， Weave
专业级： 多租户，ACL，高性能可扩展 ，如Calico，GCE高级网络模式
网易云容器网络实现
网易云的容器服务的网络实现与GCE类似，基于底层的IaaS网络，通过Kubernetes与网易云网络对接，网易云容器与主机在网络上完全对等，租户内全互通。
Kubernetes中没有定义IP的管理，可能一个容器或节点重启一下，IP就变了。网易云通过IP的管理实现了IP的保持功能，同时Pod支持私有网、公网双重网络。
此外，网易云还实现了Pod的私有网、公网IP映射关系管理，在Kubelet上实现Netease CNI插件管理网卡挂卸载、路由配置。
网易云有状态容器
提到容器的状态，人们常用Cattle和Pet来做比喻。Cattle是指无状态的容器，随时可以被替换，Pet则是有标记的，它的数据、状态和配置可能都需要持久化。社区从1.3版本就开始用PetSet实现有状态的容器，最新的1.6版本中，是叫StatefulSet。
网易云在社区版本的有状态容器诞生之前（1.0版本），就自研了StatefulPod的实现方式：
和StatefulSet不同的是，它可以支持容器系统卷、数据卷的保持（PV、PVC）。StatefulSet只能支持外挂的数据卷，但是网易云的StatefulPod能够保证只要不删除用户，用户系统盘的数据也能够保持下来；
StatefulPod还能保证容器私有网、公网IP保持（Network）；
在原生的Docker中，一个Node启动的所有容器目录都是统一的，网易云扩展Docker支持容器rootfs目录自定义；
网易云的有状态容器还支持故障的迁移，比如硬盘和IP等资源都能在Node间漂移。
网易云Kubernetes性能优化
一般在实现公有云时，尽量会保证同一个机房内，只有一个Kubernetes集群，但随着用户的增多，集群的规模也越来越大，会出现很多性能问题。网易云随着社区的发展一路走来，也遇到了很多社区可能在设计之初并没有预料到的问题，比如：
Kube-scheduler对所有pod顺序串行调度
Kube-controller的deltaQueue是无优先级的FIFO队列
Serviceaccounts控制器里没有Secret本地缓存
所有Node重复配置集群所有Service的iptables规则
Kubelet的SyncLoop每次检查都重复GET imagePullSecrets
大量Node的心跳汇报严重影响了Node的watch
Kube-apiserver 没有查询索引
针对这些问题，网易云做了很多性能优化，首先是master端的调度器：
公有云的场景和私有云不一样，容器分布在不同的租户中，每个租户的资源都是独立的，本身就可以通过租户来沟通并调度；
通常在调度的时候需要一个个去遍历Node，实际上很多无闲置资源的Node可以不参与调度的检查，网易云会在遍历前过滤掉无闲置资源的Node；
优化predicate调度算法过滤顺序，提高调度效率；
网易云中，调度都是基于事件的，比如调度失败如果是因为Node资源不足，就会发一个事件去申请资源，资源回来后会又会返回一个事件驱动Pod重调度，没有任何时间等待；
Kubernetes中有很多控制器，比如Node控制器、namespace控制器，其中replication controller是一个核心的控制器，能确保任何时候Kubernetes集群中有指定数量的pod副本在运行。网易云创建了事件优先级机制，根据事件类型进入优先级队列workqueue。
Node端的优化：
网易云的用户很多，用户之间都是完全隔离的，网易云kube-proxy按租户对
Node分组：
租户之间容器网络完全隔离，不配多余转发规则；
只watch本租户的Service，再生成iptable 规则。
Kubelet降低master请求负载：
imagePullSecret推迟都要拉镜像才GET或增加Secret local cache
只watch本租户相关资源变化（依赖apiserver新加的tenant索引）
租户之间容器网络完全隔离，不配多余转发规则；
精简kubelet watch 低master连接数，包括Node
接下来是针对单集群扩展的优化：
通过上图可以知道APIserver是整个集群的通信网关，只是一个proxy代理，而且goroutine对web服务完美支持，最终性能瓶颈在对 Etcd的访问上。
为了解决这个问题，首先想到的是分库，按Node/RS/Pod/Event分库存入多个Etcd集群。因为Etcd本身容量和性能均不能水平扩展，而且没有性能诊断工具；
Etcd2 调优，比如针对snapshot的优化，采用SSD硬盘等；
升级Etcd3，在之前的版本中，每次更改都会发送一个请求，一个请求又对应一个回复，在Etcd3中是批量请求的方式，可能一次请求就把1000个变化推送过来了，所以效率提高很多；
更换Kubernetes后端的存储，换其他性能更优的KV存储。
Node心跳汇报模式修改：
Node心跳间隔延长
Node心跳不持久化
心跳从Node分离出来，Node心跳只需list不必watch
NodeController被动改主动探测
其它优化
镜像、容器的GC完善：目前的GC只考虑了磁盘的空间使用量，没考虑inode的问题，很多用户的小文件很多，所以网易云新增了磁盘inode使用率检查
容器监控统计：Cadvisor新增网络流量、TCP连接、磁盘相关统计
NodeController安全模式，自定义Protected，Normal，Advanced 3种模式。
Protected： 底层IAAS主动临时运维时，为了避免大规模迁移波动， Node离线只报警不迁移
Normal：有状态的不迁移，无状态的及时离线删除重建。(仅仅底层云盘、网络故障)
Advanced：有状态无状态都自动迁移恢复
还需要注意的一些问题：
Pod的graceful delete要容器能正常传递SIGTERM信号
StatefulSet在kubelet挂掉时可能出现两个同时运行的Pod
作者：网易云
来源：https://segmentfault.com/a/1190000011001864
往期精彩内容回顾
以上是关于网易云基于Kubernetes的深度定制化实践的主要内容，如果未能解决你的问题，请参考以下文章