JDOS2.0-kubernetes的工业级实践
声明:本篇文章内容整理自我厂美女张伟伟童鞋在DockOne社区微信群中的分享，本篇文章只是内容预览，更美观的图文分享请关注
dockerone公众号，关注容器以及k8s最新动态。
介绍
JDOS(Jingdong Datacenter Operating System) 1.0于2014年推出，基于openstack进行了深度定制，并在国内率先将容器引入生产环境，经历了2015年618/双十一的考验。团队积累了大量的容器运营经验，对Linux内核、网络、存储等深度定制，实现了容器秒级分配。
意识到openstack架构的笨重，2016年当JDOS 1.0逐渐增长到十万、十五万规模时，团队已经启动了新一代容器引擎平台(JDOS 2.0)研发。JDOS 2.0致力于打造从源码到镜像，再到上线部署的CI/CD全流程，提供从日志、监控、排障，终端，编排等一站式的功能。JDOS 2.0迅速成为kubernetes的典型用户，并在kubernetes的官方博客分享了从openstack切换到kubernetes的过程。 JDOS 2.0的发展过程中，逐步完善了容器的监控、网络、存储，镜像中心等容器生态建设，开发了基于BGP的Skynet网络、ContainerLB、ContainerDNS、ContainerFS等多个项目，并将多个项目进行了开源。本次分享，我们主要分享的是在JDOS2.0的实践过程中关于kubernetes的一些经验和教训。
注：kubernetes版本我们目前主要稳定在了1.6版本。本文中的实践也是主要基于此版本。我们做的一些feature和bug，有的在k8s后续发展过程中进行了实现和修复。大家有兴趣也可以同社区版进行对照。
kubernetes定制开发
为什么定制?
很多人可能会问，原生的kubernetes不好么，为什么要定制。首先，我先来解释下定制的原因。在我们使用开源项目的过程中，无论是openstack还是kubernetes，都会有一种体会，就是理想和现实是存在较大的差距的。出于各种原因，开源项目需要做很多的妥协，而且很多功能是很理想化的，这就导致了kubernetes直接应用于生产中会遇到很多的问题。因此，我们对kubernetes进行了定制开发，秉持了两个基本的理念，加固与裁剪。
加固主要指的是在任何时候、任何情况下，将容器的非故障迁移、服务的非故障失效的概率降到最低，最大限度的保障线上集群的安全与稳定，包括etcd故障、apiserver全部失联、apiserver拒绝服务等等极端情况。
裁剪则体现为我们删减了很多社区的功能，修改了若干功能的默认策略，使之更适应我们的生产环境的实际情况。
在这样的原则下，我们对kubernetes进行了许多的定制开发。下面将对其中部分进行介绍。
ip保持不变
线上很多用户都希望自己的应用下的Pod做完更新操作后，IP依旧能保持不变，于是我们设计实现了一个IP保留池来满足用户的这个需求。简单的说就是当用户更新或删除应用中的Pod时，把将要删除的pod的IP放到此应用的IP保留池中，当此应用又有创建新Pod的需求时，优先从其IP保留池中分配IP，只有IP保留池中无剩余IP时，才从大池中分配IP。ip保留池是通过标签来与k8s的资源来保持一致，因此ip保持不变功能不仅支持有状态的statefulset，还可以支持rc/rs/deployment。
重复利用ip会带来一个潜在的问题，就是当前一个pod还未完全删除的时候，后一个pod的网络就不能提早使用，否则会存在ip的二义性。为了提升pod更新速度，我们对容器删除的流程进行了优化，将cni接口的调用提前到了stop容器之前，从而大大加快了IP释放和新Pod创建的速度。
检查IP连通性
Kubernetes创建Pod，调度时pod处于Pending的状态，调度完成后处于Creating的状态，磁盘分配完成，IP分配完成，容器创建完成后即处于Running状态，而此时有可能IP还未真正生效，用户看到Running状态但是却不能登录容器可能会产生困惑，为了让用户有更好的体验，在Pod转变为Running状态之前，我们增加了检查IP连通性的步骤，这样可以确保状态的一致性。
修改默认策略
pod的restart策略其实是rebuild，就是当pod故障(可能是容器自身问题，也可能是因为物理机重启等)后，kubelet会为pod重新创建新的容器。但是在实际过程中，其实很多用户的应用会在根目录写入一些数据或者配置，因此用户会更加期望使用先前的容器。因此我们为pod增加了一个reUseAlways的策略，并成为restart的默认策略。而将原来的Always策略，即rebuild容器的策略作为可选的策略之一。当使用reUseAlways策略时，kubelet将会首先检查是否有对应容器，如果有，则会直接start该容器，而不会重新create一个新的容器。
对于service，我们进行了自己的实现，可以选用haproxy/nginx/LVS进行导流。当节点故障时，controller会将该节点上的pod从对应的service进行摘除。但是在实际生产中，其实很容易遇到另外一个问题，就是节点实际没有完全故障，是处于一个不稳定状态，比如网络时通时不通，会表现为node的状态在ready和notready之间反复切换，会导致service的endpoint会反复修改，最终会影响到haproxy/nginx进行频繁reload。其实这个可以通过给service配置annotation使得ep不受node notready的影响。
但是我们为了安全起见，将该策略设置为了默认策略，而配置额外的annotation可以使其能够在not ready时被摘除。因为我们的LB上都默认开启了健康检查(默认是端口检查，还可以进行配置路径健康检查)。因此不健康节点的流量切除可以通过LB自身进行。
定制controller
在实践过程中，我们有一个深刻的体会，就是官方的controller其实是一个参考实现，特别是node controller和taint controller。node的健康状态来自于其通过apiserver的上报。而controller仅仅依据通过apiserver中获取的上报状态，就进行了一系列的操作。这样的方式是很危险的。
因为controller的信息面非常窄，没法获取更多的信息。这就导致在中间任何一个环节出现问题，比如node节点网络不稳定，apiserver繁忙，都会出现节点状态的误判。假设出现了交换机故障，导致大量kubelet无法上报node状态，controller进行大量的pod重建，导致许多原先的健康节点调度了许多pod，压力增大，甚至部分健康节点被压垮为notready，逐渐雪崩，最终导致整个集群的瘫痪。这种灾难是不可想象的，更是不可接受的。
因此，我们对于controller进行了定制。节点的状态不仅仅由kubelet上报，在controller将其置为notready之前，还会进行复核。复核部分交由一个单独的分布式系统MAGI完成，其在多个物理POD上进行部署，收到请求会对节点分别进行独立的分析和体检，最终投票，做出节点是否notready的判断。这样最大限度的降低了节点误判的概率。
资源限制
k8s默认提供了cpu和memory的资源管理，但是这对生产环境来说，这样的隔离和资源限制是不够的，因此我们增加了磁盘读写速率限制、swap使用限制等，最大限度保证pod之间不会互相影响。
我们对大部分的pod，还提供了本地存储。目前kubernetes支持的一种容器数据本地存储方式是emptydir，也就是直接在物理机上创建对应的目录并挂载给容器，但是这种方式不能限制容器数据盘的大小，容易导致物理机上的磁盘被打满从而影响其它进程。鉴于此，我们为kubernetes的新开发了一个存储插件LvmPlugin，使其支持基于LVM（Logical Volume Manager）管理本地逻辑卷的生命周期，并挂载给容器使用。
LvmPlugin可以执行创建删除挂载卸载逻辑盘LV，并且还可以上报物理机上的磁盘总量及剩余空间给kube-scheduler，使得创建新Pod时scheduler把LVM的磁盘是否满足也作为一个调度指标。
对于数据库容器或者使用磁盘频率较高的业务，用户会有限制磁盘读写的需求。我们的实现方案是把这限制指标看作容器的资源，就像Cpu，Memory一样，可以在创建Pod的yaml文件中指定，同一个pod的不同容器可以有不同的限制值，而kubelet创建容器时可以获取当前容器对应的磁盘限制指标的值并进行相应的设置。
grpc升级
生产环境中，当集群规模迅速膨胀时，即使利用负载均衡的方式部署kube-apiserver，也常常会出现某个或某几个apiserver不稳定，难以承担访问压力的情况。经过了反复的实验排查，最终确定是grpc的问题导致了apiserver的性能瓶颈。我们对于grpc包进行了升级，最终地使得apiserver的性能及稳定性都有了大幅度的提升。
平滑升级
我们于2016年就着手设计研发基于k8s的JDOS2.0，彼时使用的版本是k8s1.5，2017年社区发布了k8s1.6的release版本，其中新增了很多新的特性，比如支持etcd V3，支持节点亲和性（Affinity）、Pod亲和性（Affinity）与反亲和性（anti-affinity）以及污点（Taints）与容忍（tolerations）等调度，支持调用container runtimes的统一接口CRI，支持Pod级别的Cgroup资源限制，支持GPU等，这些新特性都是我们迫切需要的，于是我们决定由k8s1.5升级至当时1.6最新release的版本k8s1.6.3。但是此时生产环境已经基于k8s1.5上线大量容器，如何在保证这些业务容器不受任何影响的情况下平滑升级呢？
对比了两个版本的代码，我们讨论了对于kubernetes进行改造兼容，实现以下几点：
- k8s1.6.x默认的Cgroup资源限制层级是Pod，而老节点上的Cgroup资源限制层级是Container，所以升级后要添加相应配置保证老节点的资源限制层级不发生改变。
- k8s1.6默认会清理掉leacy container也就是老的container，通过对kuberuntime的二次开发，我们保证了升级到1.6后在k8s1.5上创建的老容器不被清理。
新老版本的containerName格式不一致导致获取Pod状态时获取不到IP，从而升级后老Pod的IP不能正常显示，通过对dockershim部分代码的适当调整，我们将老版本的pod的containerName统一成新版本的格式，解决了这个问题。
经过如上的改造，我们实现了线上几千台物理机由k8s1.5到k8s1.6的平滑升级。而业务完全无感知。
bug fix和其他feature
我们还修复了诸如GPU中的nvida卡重复分配给同一容器，磁盘重复挂载bug等。这些大部分社区在后面的版本也做了修复。还增加了一些小的功能，比如增加了service支持set-based的selector，kubelet image gc优化，kubectl get node显示时增加node的版本信息等等。这里就不详述了。
集群运营
参数调优和配置
k8s的各个组件有大量的参数，这些参数需要根据集群的规模进行优化调整，并进行适当的配置，来避免问题以及定制自己的特殊需求。比如说有次我们其中一个集群个别节点出现了不停的在Ready和NotReady的状态之间来回切换的问题，而经过检查，集群的各个服务都处于正常的状态。
很是认真研究了一下，才发现是此node上的容器数量太多，并且每个容器的ConfigMap也比较多，导致node节点每秒向apiserver发送的请求数也很多，超过了kubelet的配置api-qps的默认值，才影响了node节点向apiserver更新状态，导致Node状态的切换。将相关配置值调大后就解决了这个问题。另外apiserver的api-qps，api-burst等配置也需要根据集群规模以及apiserver的个数做出正确的估量并设置。
再比如说，当node节点挂掉多久后才允许kubernetes自动迁移上面的容器，不管是使用node-controller或taint-controller经过适当的配置都可以实现。
以及kubelet重启时，会再一次进行predicates检查，对于不符合二次检查要求的pod会将它们删除，而如果有些pod很重要你绝对不希望它们在这种检查中被删掉，那么其实给pod设置一下对应的annotation就可以实现。
关于这样的配置涉及到很多的细节，因为文档可能没有更新的那么及时，最好对于源码有一定掌握。
组件部署
Apiserver使用域名的方式做负载均衡，可以平滑扩展，Controller-manager和Scheduler使用Leader选举的方式做高可用。同时为了分担压力和安全，我们每个集群部署了两套etcd。一套专门用于event的存储。另一套存储其他的资源。
node管理
使用标签管理node的生命周期，从接管物理机到装机完成再到服务部署完毕网络部署完毕NodeReady直至最终下线，每一个步骤都会自动给node添加对应标签，以方便自动化运维管理。
同时，node上还添加了区域zone。可以方便一些将一些部门独立的物理机纳入统一管理，同时资源又能保证其独享。对于一些特殊的资源，比如物理机上有gpu、ssd等特殊资源，对应会给节点打上专属的标签用以标识。用户申请时可以根据需要申请对应的资源，我们在申请的pod上配属相应的标签，从而将其调度至相应的节点。
节点发生故障或者需要下线维护时，首先将该节点置为disable，禁止调度，如果超过一定时间，节点尚未恢复，controller会自动迁移其上的容器到其他正常的节点上。
上线流程管理
上线之前制定上线步骤，经相关人员review确认无误后，严格按照上线步骤操作。上线操作按照先截停控制台等入口，而后controller、scheduler停止，再停止kubelet。上线结束后按照反向，依次做验证，启动。
先截停控制台以及apiserver是为了阻止用户继续创建删除，而后停止controller和scheduler对Pod的调度和迁移等操作，最后停止kubelet对Pod生命周期的管理。这样的顺序可以最大程度保证运行pod不受上线过程的影响，否则的话容易造成controller和scheduler的误判，做出错误的决策。
故障演练与应急恢复
为了防止一些极端情况和故障的发生，我们也进行了多次的故障演练，并准备了应急恢复的预案。在这里我们主要介绍下etcd和apiserver的故障恢复。
etcd的故障恢复
etcd在整个集群中的非常重要，一旦有差错，整个集群都会处于瘫痪状态，更不要说数据出现丢失的情况。线上etcd集群的运行还是相对稳定的，但是显然还是要防患于未然，为此我们特地定制了etcd备份和恢复。线上所有集群每隔1小时都会自动做一次备份，并且发邮件通知备份成功与否。恢复则分为原地恢复和利用原集群的数据另外启动一个集群恢复两种方式，大致的恢复流程如下：
- 将原etcd数据目录备份
- 另选3台机器，搭建一个全新的etcd集群（带证书认证）
- 将新etcd集群的etcd停止，数据目录下的内容全部删除
- 将备份数据拷贝到3台新etcd机器上，使用etcdctl snapshot restore逐个节点恢复数据，注意观察恢复后id是否一致。数据恢复完成后查看endpoint status状态是否正常
apiserver的故障恢复
一般单台apiserver故障，将其进行维护即可。如果apiserver同时发生故障时，会导致node节点状态出现异常，此时则需要立刻停掉controller和scheduler服务，防止状态判断失误造成的误决策。在apiserver修复后进行验证后，再启动其他组件。
运维工具
ansible
JDOS2.0日常管理的物理机和容器规模庞大，平时的部署和运维如果没有好用的工具会非常繁琐，为此我们主要选用ansible开发了2.0专属的部署和运维工具，极大的提高了工作效率。
集群部署使用ansible新搭建集群或者扩容集群或者升级都及其方便，只需要事先把模板写好，具体操作时执行简单的命令即可，同时也不用担心由于操作失误引发问题。
kubernetes connection plugin
为了方便操作各个容器，我们还开发了ansible的kubernetes插件，可以通过ansible对容器进行批量的诸如更新密码、分发文件、执行命令等操作。
巡检工具
日常巡检系统对于及时发现物理机及各个服务的异常配置和状态非常重要，尤其是大促期间，系统的角落有些许异常可能就带来及其恶劣的影响，因此特殊时期我们还会加大巡检的频率。
巡检的系统的巡检模块都是可插拔的，巡检点可以根据需求灵活配置，随时增减。
其他工具
为了方便运维统计和监控，我们还开发了一些其他的工具：
api日志分析工具：使用python对日志进行预处理，形成结构化数据。而后使用spark进行统计分析。可以对请求的时间、来源、资源、耗时长短、返回值等进行分析。
kubesql：可以将k8s的如pod、service、node等资源，处理成类似于关系数据库中的表。这样就可以使用sql语句对于相关资源进行查询。比如可以使用sql语句来查询mysql、default namespace下的所有pod的名字。
event事件通知：监听event，并根据event事件进行分级，对于紧急事件接入告警处理，可以通过邮件或者短信通知到相关运维人员。
Q&A
Q1:lvm的磁盘io限制是怎么做的？
A1:这是通过改造kube-apiserver以及kubelet，把磁盘限制的指标也作为一种资源，底层最终使用cgroup实现的。
Q2:请问Skynet 网络基于openstack neutron 吗？
A2:我们的kubernetes的网络是分为两套。最开始我们使用的是neutron，因为我们的JDOS 1.0已经稳定运行了多年。今年开始，我们很多数据中心采用的是BGP的网络。可以参考calico的实现。
Q3:巡检工具是只检查不修复吗？
A3:是的，巡检的目的就只是检查并通知，一般有问题会找运维修复。
Q4:使用的什么 docker storage driver?
A4:我们JDOS 1.0是使用的自研的vdisk，2.0使用的是dm。
Q5:为了提升pod更新速度，我们对容器删除的流程进行了优化，将cni接口的调用提前到了stop容器,没太明白这里
A5:删除容器的流程原本是stop app容器->调用cni->stop sandbox容器。因为在实际中，stop app容器时间会较长。因此我们将其调整为调用cni->stop app容器->stop sandbox容器。这样可以更快释放ip。
Q6:有用pv pvc吗？底层存储多的什么技术？
A6:有用到pv pvc，底层存储使用的是我们自研的containerfs。目前已经开源在github上，欢迎使用。
Q7:能详细描述一下“grpc的问题导致了apiserver的性能瓶颈”的具体内容吗？
A7:在1.6我们原来使用的单个apiserver在服务大概300个节点时，就会大量拒绝请求，出现409错误。后来我们查阅了社区的相关资料，发现是grpc的问题，通过升级grpc包，可以实现600以上节点无压力。
Q8:请问多idc的场景你们是如何管理的?
A8:目前是分多个数据中心，每个数据中心再划分多个集群。控制单个集群规模，这样方便管理。但是镜像、配置、调度可以在不同数据中心、不同集群间通用。这样集群和数据中心对用户透明。
Q9:加固环节（包括etcd故障、apiserver全部失联、apiserver拒绝服务等等极端情况）上面列举的几种情况发生时会造成灾难性后果吗？k8s集群的行为会怎样？有进行演练过不？这块可以细说一下吗。
A9:当然，如果未经过加固或者不能正常恢复etcd数据，还可能导致pod大量迁移或销毁，甚至整个集群节点压力增大，发生雪崩效应，最终整个集群崩溃。
Q10:pod固定ip的使用场景是什么？有什么实际意义？
A10:这个实际很多业务，特别是一些老业务，是无法做到完全无状态的。如果不能提供固定ip，那么他们的配置上线都会很麻烦。
Q11:请问有使用SR-IOV 或者DPDK 的技术吗？如果目前没有，是有哪方面的考量，将来会考虑吗？
A11:可以参见我们的团队的DPDK分享。
Q12:请问系统开发完毕后，下一步有什么计划？进入维护优化阶段，优秀的设计开发人员下一步怎么玩？
A12:容器化，自动化这才是万里长征的第一步啊。我们已经在调度方面做了很多的工作，可以参看我们团队关于阿基米德的一些分享。集群自治与智能化，我们已经在路上了。欢迎大家一道来实践。未来我们也会同大家分享这其中的经验。
Q13:应用滚动升级，有无定制?还是采用k8s默认机制
A13:是我们自己定制的deployment，进行了适当的改造，可以支持暂停状态，比如说更新时，可以指定两个版本的pod个数比例，中止在这个中间状态。
Q14:能否介绍一下对GPU支持这块？
A14:GPU我们的玩法其实很简单，就是一个容器一块卡，每个卡只分给一个容器。这样的好处是安全，分配效率高，利用率也比较高。
