为什么 kubernetes 天然适合微服务（3）

此文已由作者刘超授权网易云社区发布。

欢迎访问网易云社区，了解更多网易技术产品运营经验

四、Kubernetes 本身就是微服务架构

基于上面这十个设计要点，我们再回来看 Kubernetes，会发现越看越顺眼。

首先 Kubernetes 本身就是微服务的架构，虽然看起来复杂，但是容易定制化，容易横向扩展。

如图黑色的部分是 Kubernetes 原生的部分，而蓝色的部分是网易云为了支撑大规模高并发应用而做的定制化部分。

Kubernetes 的 API Server 更像网关，提供统一的鉴权和访问接口。

众所周知，Kubernetes 的租户管理相对比较弱，尤其是对于公有云场景，复杂的租户关系的管理，我们只要定制化 API Server，对接 Keystone，就可以管理复杂的租户关系，而不用管其他的组件。

在 Kubernetes 中几乎所有的组件都是无状态化的，状态都保存在统一的 etcd 里面，这使得扩展性非常好，组件之间异步完成自己的任务，将结果放在 etcd 里面，互相不耦合。

例如图中 pod 的创建过程，客户端的创建仅仅是在 etcd 中生成一个记录，而其他的组件监听到这个事件后，也相应异步的做自己的事情，并将处理的结果同样放在 etcd 中，同样并不是哪一个组件远程调用 kubelet，命令它进行容器的创建，而是发现 etcd 中，pod 被绑定到了自己这里，方才拉起。

为了在公有云中实现租户的隔离性，我们的策略是不同的租户，不共享节点，这就需要 Kubernetes 对于 IaaS 层有所感知，因而需要实现自己的 Controller，Kubernetes 的设计使得我们可以独立创建自己的 Controller，而不是直接改代码。

API-Server 作为接入层，是有自己的缓存机制的，防止所有的请求压力直接到后端数据库上。但是当仍然无法承载高并发请求时，瓶颈依然在后端的 etcd 存储上，这和电商应用一摸一样。当然能够想到的方式也是对 etcd 进行分库分表，不同的租户保存在不同的 etcd 集群中。

有了 API Server 做 API 网关，后端的服务进行定制化，对于 client 和 kubelet 是透明的。

如图是定制化的容器创建流程，由于大促和非大促期间，节点的数目相差比较大，因而不能采用事先全部创建好节点的方式，这样会造成资源的浪费，因而中间添加了网易云自己的模块 Controller 和 IaaS 的管理层，使得当创建容器资源不足的时候，动态调用 IaaS 的接口，动态的创建资源。这一切对于客户端和 kubelet 无感知。

为了解决超过 3 万个节点的规模问题，网易云需要对各个模块进行优化，由于每个子模块仅仅完成自己的功能，Scheduler 只管调度，Proxy 只管转发，而非耦合在一起，因而每个组件都可以进行独立的优化，这符合微服务中的独立功能，独立优化，互不影响。而且 Kubernetes 的所有组件都是 Go 开发的，更加容易一些。所以 Kubernetes 上手慢，但是一旦需要定制化，会发现更加容易。

五、Kubernetes 更加适合微服务和 DevOps 的设计

好了，说了 K8S 本身，接下来说说 K8S 的理念设计，为什么这么适合微服务。

前面微服务设计的十大模式，其中一个就是区分无状态和有状态，在 K8S 中，无状态对应 deployment，有状态对应 StatefulSet。

deployment 主要通过副本数，解决横向扩展的问题。

而 StatefulSet 通过一致的网络 ID，一致的存储，顺序的升级，扩展，回滚等机制，保证有状态应用，很好地利用自己的高可用机制。因为大多数集群的高可用机制，都是可以容忍一个节点暂时挂掉的，但是不能容忍大多数节点同时挂掉。而且高可用机制虽然可以保证一个节点挂掉后回来，有一定的修复机制，但是需要知道刚才挂掉的到底是哪个节点，StatefulSet 的机制可以让容器里面的脚本有足够的信息，处理这些情况，实现哪怕是有状态，也能尽快修复。

在微服务中，比较推荐使用云平台的 PaaS，例如数据库，消息总线，缓存等。但是配置也是非常复杂的，因为不同的环境需要连接不同的 PaaS 服务。

K8S 里面的 headless service 是可以很好地解决这个问题的，只要给外部服务创建一个 headless service，指向相应的 PaaS 服务，并且将服务名配置到应用中。由于生产和测试环境分成 Namespace，虽然配置了相同的服务名，但是不会错误访问，简化了配置。

微服务少不了服务发现，除了应用层可以使用 SpringCloud 或者 Dubbo 进行服务发现，在容器平台层当然是用 Service了，可以实现负载均衡，自修复，自动关联。

服务编排，本来 K8S 就是编排的标准，可以将 yml 文件放到代码仓库中进行管理，而通过 deployment 的副本数，可以实现弹性伸缩。

对于配置中心，K8S 提供了 configMap，可以在容器启动的时候，将配置注入到环境变量或者 Volume 里面。但是唯一的缺点是，注入到环境变量中的配置不能动态改变了，好在 Volume 里面的可以，只要容器中的进程有 reload 机制，就可以实现配置的动态下发了。

统一日志和监控往往需要在 Node 上部署 Agent，来对日志和指标进行收集，当然每个 Node 上都有，daemonset 的设计，使得更容易实现。

当然目前最最火的 Service Mesh，可以实现更加精细化的服务治理，进行熔断，路由，降级等策略。Service Mesh 的实现往往通过 sidecar 的方式，拦截服务的流量，进行治理。这也得力于 Pod 的理念，一个 Pod 可以有多个容器，如果当初的设计没有 Pod，直接启动的就是容器，会非常的不方便。

所以 K8S 的各种设计，看起来非常冗余和复杂，入门门槛比较高，但是一旦想实现真正的微服务，K8S 可以给你各种可能的组合方式。实践过微服务的人，往往会对这一点深有体会。

六、Kubernetes 常见的使用方式

下面我们来看一下，微服务化的不同阶段，Kubernetes 的使用方式。

第一阶段：使用公有云虚拟机

也即没有微服务化的阶段，基本上一个进程就能搞定，两个进程做高可用，不需要使用容器，虚拟机就非常好。

第二阶段：容器作为持续集成工具