k8s架构篇：服务部署模式是如何变迁的

kubernetes，简称 K8s，是用 8 代替中间 8 个字符 “ubernete” 而成的缩写，是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes 的目标是让部署容器化的应用简单并且高效(powerful)，Kubernetes 提供了应用部署，规划，更新，维护的一种机制。

k8s 在企业中的应用场景

首先我们了解一下 k8s 的三个基本特点：

可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）

可扩展: 模块化，插件化，可挂载，可组合

自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展

自动化运维平台

对于中小型企业，为了降本增效，使用 k8s 来构建一套自动化运维平台，提供了应用部署，规划，更新，维护的一种机制。 对于大型互联网公司更要使用容器化部署。现在服务器越来越多，不可能都人工部署，需要使用自动化的运维平台来监控服务，来实现自动服务化的部署、运维。

充分利用服务器资源

假设现在有一个开发量为 200 个的请求，服务器配置为 2cpus 4G

静态请求：150（访问 CDN，Nginx，cache 等）

动态请求：50（访问数据库，需要把数据读入内存）

估算服务器资源（只考虑内存，不考虑程序响应时间RT，不考虑CPU切换时间） 假设一个静态请求进程占用2M，一个动态请求进程占用10M，则这200个请求并发占用：150×2M + 50×10M = 800M 内存 可以支持的 QPS (批发量，每秒查询率) 为：200×4=800（因为 800 M× 4 < 4G） 因此如果要充分利用服务器资源，需要达到 QPS=800，此时占用内存 3.2G（剩下 0.8G 给 OS 等） 实际上：800QPS 无法达到，还要考虑 RT、CPU 切换、内存等因素，那就保守把 QPS=300，但这时没能充分利用服务器的资源。更何况当下服务器配置可不止 2cpus 4G 容器化解决方案，在服务器部署多个容器，容器当中运行着我们部署的各种服务

服务无缝迁移

在开发环境开发，然后拿到测试环境去测试，但往往一上线就会有 bug，因为应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，所以生产环境的不一致就可能导致错误。 使用容器化解决方案，每个应用可以被打包成一个容器镜像（红色圈起来表示把服务部署在容器中），使用容器可以在 开发 或 测试 的阶段，为应用创建容器镜像，这些镜像能够完全脱离环境，每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构，这使得从研发到测试、生产能提供一致环境。使用 kubernetes 来管理这些容器，便能够实现服务的无缝迁移。

服务部署模式变迁 & 服务部署变化问题的思考

服务部署模式是如何变迁的

物理机：传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作。

虚拟化 (虚拟机)：当然上面的问题可以通过创建虚拟机的方式来实现某些功能，但是虚拟机本身就很占用资源，并不利于可移植性。（就是把服务部署在虚拟机中，达到分隔物理资源的作用——充分利用服务器资源）

容器部署：每个容器之间互相隔离，每个容器有自己的文件系统 ，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。而且更轻量级、运行效率更快。

服务部署模式变化，带来了哪些问题

前提条件：SOA 架构，微服务架构模式下，服务拆分越来越多，部署维护的服务越来越多，该如何管理？ 虚拟机服务部署方式（通过 openstack 软件提供可视化的方式来管理虚拟机） 容器化部署模式（通过 k8s 软件管理容器，其实容器也可以看成一个虚拟机，只不过更轻量级） 容器化部署问题：

如何对服务横向扩展？

容器宕机怎么办？如何恢复？

重新发布版本如何更新且更新后不影响业务？

如何监控容器？

容器如何调度创建？

数据安全性如何保证？

使用 k8s 管理容器，以上问题都能够完美的解决

云架构 & 云原生

云 和 k8s 的关系

云：使用容器构建的一套服务集群网络，云是由很多的容器构成。 k8s：用来管理云中的容器

云架构

iaas：基础设施即服务

用户角度：租用（购买或分配权限）云主机，用户不用考虑网络、DNS、存储和硬件环境等方面的问题。 运营商角度：提供网络、DNS、存储等这样的服务就叫做基础设置服务

paas：平台即服务

在平台上提供了很多服务，如 MySQL 服务、Redis 服务、MQ 服务、Elasticsearch 服务等等

saas：软件即服务

钉钉、财务管理等等，一些软件维护工作都是由运行商来做，用户只管体验软件提供的服务就行了。

serverless：server 服务，less 无 —— 无服务 不需要服务器

站在用户角度考虑问题，用户只需要使用云服务器即可。 在云服务器上的所有的基础环境、软件环境都不需要考虑和维护，非常方便。 未来开发的趋势都是 severless，企业都构建了自己的私有云或者公有云环境。使用 k8s 构建非常方便。

云原生

为了让应用程序（项目，服务软件）都运行在云上的解决方案，这样方案叫做云原生，有以下特点：

容器化：所有的服务都必须部署在容器中。

微服务：web 服务架构是微服务架构

CI/CD：可持续交互和可持续部署

DevOps：开发和运维密不可分

kubernetes 架构原理

k8s 的历史

k8s 是由 Google 公司 用go 语言开发的。google 在全球有相当多的服务器，当然需要一个管理软件。Google内部本身就有一个叫 borg 的系统云平台管理工具，已经使用了十几年。后来参照 borg 系统架构开发了 k8s，主要用它来编排、管理容器，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。

k8s 的架构

k8s 集群（Cluster）

一个 master 对应一群 node 节点

master 节点

api server：相当于 k8s 的网关，所有的指令请求都必须经过 api server

scheduler：调度器，使用调度算法，把请求资源调度到某个 node 节点

controller：控制器，维护 k8s 资源对象（CRUD：添加、删除、更新、修改）

etcd：存储资源对象（可以服务注册、发现等等）

node 节点

docker：运行容器的基础环境，容器引擎

kubelet：每个 node 节点都有一份kubelet，在 node 节点上的资源操作指令由 kuberlet 来执行，scheduler 把请求交给api ，然后 api sever 再把信息指令数据存储在 etcd 里，于是 kuberlet 会扫描 etcd 并获取指令请求，然后去执行

kube-proxy：代理服务，负载均衡

fluentd：日志收集服务

pod：k8s 管理的基本单元（最小单元），pod 内部是容器。k8s 不直接管理容器，而是管理 pod

回顾架构特点

k8s 是用来管理容器的，但是不直接操作容器，最小的操作单元是 pod（间接管理容器）

一个 master 对应一群 node 节点。

master 节点不存储容器，只负责调度，网关，控制器，资源对象存储等

容器存储在 node 节点 的 pod 内部

pod 内部可以有一个或多个容器

kubelet 负责本地的 pod 的维护，CRUD

kube-proxy 负责负载均衡，在多个 pod 间负载均衡
编辑：黄飞