为何 kubernetes 自然适合微服务 （3）

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

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

4、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 上手慢，可是一旦须要定制化，会发现更加容易。

5、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 能够给你各类可能的组合方式。实践过微服务的人，每每会对这一点深有体会。

6、Kubernetes 常见的使用方式

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

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

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

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

当微服务开始拆分了，如何保证拆分后功能的一致性，须要持续集成做为保证，如前面的论述，容器是很是好的持续集成工具，是解决 CI/CD 中 D 的，因此一开始用 host 网络就能够，这样能够保证部署方式和原来兼容。

若是想用私有云进行部署，直接部署在物理机上，在性能要求没有很高，可是又要和其余物理机很好的通讯的状况下，能够用 bridge 打平网络的方式比较好。经过建立网桥，将物理网卡，容器网卡都链接到一个网桥上，能够实现全部的容器和物理机在一样的一个二层网络里面。

若是性能要求比较高，例如要部署相似缓存，则可使用 sr-iov 网卡。

若是想实现租户的简单隔离，则每每使用各类 Overlay 的网络模式，这是最经常使用的部署方式。图中的数据来自网络。Flannel，Calico 都是很是好的网络插件，虽然 Flannel 一开始使用用户态的模式性能很差，后来使用内核态，性能大大改善，使用 gw 模式后，和 Calico 性能至关。

网易云采用了 Kubernetes 和 IaaS 深度融合的方式，相似 AWS 的 Fargate 的模式，一方面可使得原来使用虚拟机的用户平滑地迁移到容器，另外一方面能够实现公有云的租户隔离。

如图是融合的网易云容器服务的架构，这个管理 OpenStack 和 Kubernetes 的管理平台，也是用的微服务架构，有 API 网关，熔断限流功能，拆分红不一样的服务，部署在 K8S 上的，因此到处是微服务。

网易云轻舟微服务是围绕应用和微服务打造的一站式 PaaS 平台，帮助用户快速实现易接入、易运维的微服务解决方案。

相关阅读：为何 kubernetes 自然适合微服务 (1)

为何 kubernetes 自然适合微服务 （2）

为何 kubernetes 自然适合微服务 （3）

文章来源： 网易云社区