可移植：支持公有云，私有云，混合云，多重云（multi-cloud）
可扩展：模块化，插件化，可挂载，可组合
自动化：自动部署，自动重启，自动复制，自动伸缩/扩展
假设一个静态请求进程占用 2M，一个动态请求进程占用 10M，则这 200 个请求并发占用：150×2M + 50×10M = 800M 内存
可以支持的 QPS（批发量，每秒查询率）为：200×4=800（因为 800M × 4 < 4G）
因此如果要充分利用服务器资源，需要达到 QPS=800，此时占用内存 3.2G（剩下 0.8G 给 OS 等）
实际上：800QPS 无法达到，还要考虑 RT、CPU 切换、内存等因素，那就保守把 QPS=300，但这时没能充分利用服务器的资源。更何况当下服务器配置可不止 2cpus 4G
容器化解决方案，在服务器部署多个容器，容器当中运行着我们部署的各种服务
物理机：传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作。
虚拟化（虚拟机）：当然上面的问题可以通过创建虚拟机的方式来实现某些功能，但是虚拟机本身就很占用资源，并不利于可移植性。（就是把服务部署在虚拟机中，达到分隔物理资源的作用——充分利用服务器资源）
容器部署：每个容器之间互相隔离，每个容器有自己的文件系统 ，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。而且更轻量级、运行效率更快。
虚拟机服务部署方式（通过 OpenStack 软件提供可视化的方式来管理虚拟机）
容器化部署模式（通过 Kubernetes 软件管理容器，其实容器也可以看成一个虚拟机，只不过更轻量级）
如何对服务横向扩展？
容器宕机怎么办？如何恢复？
重新发布版本如何更新且更新后不影响业务？
如何监控容器？
容器如何调度创建？
数据安全性如何保证？
云：使用容器构建的一套服务集群网络，云是由很多的容器构成。
Kubernetes：用来管理云中的容器
IaaS：基础设施即服务
用户角度：租用（购买或分配权限）云主机，用户不用考虑网络、DNS、存储和硬件环境等方面的问题。
运营商角度：提供网络、DNS、存储等这样的服务就叫做基础设置服务
PaaS：平台即服务
在平台上提供了很多服务，如 MySQL 服务、Redis 服务、MQ 服务、Elasticsearch 服务等等
SaaS：软件即服务
钉钉、财务管理等等，一些软件维护工作都是由运行商来做，用户只管体验软件提供的服务就行了。
Serverless：server 服务，less 无 —— 无服务 不需要服务器
站在用户角度考虑问题，用户只需要使用云服务器即可。
在云服务器上的所有的基础环境、软件环境都不需要考虑和维护，非常方便。
容器化：所有的服务都必须部署在容器中。
微服务：Web 服务架构是微服务架构
CI/CD：可持续交互和可持续部署
DevOps：开发和运维密不可分
API Server：相当于 Kubernetes 的网关，所有的指令请求都必须经过 API Server
Scheduler：调度器，使用调度算法，把请求资源调度到某个 Node 节点
Controller：控制器，维护 Kubernetes 资源对象（CRUD：添加、删除、更新、修改）
etcd：存储资源对象（可以服务注册、发现等等）
Docker：运行容器的基础环境，容器引擎
kubelet：每个 Node 节点都有一份 kubelet，在 Node 节点上的资源操作指令由 kuberlet 来执行，Scheduler 把请求交给 API，然后 API Server 再把信息指令数据存储在 etcd 里，于是 kuberlet 会扫描 etcd 并获取指令请求，然后去执行
kube-proxy：代理服务，负载均衡
Fluentd：日志收集服务
Pod：Kubernetes 管理的基本单元（最小单元），Pod 内部是容器。Kubernetes 不直接管理容器，而是管理 Pod。
Kubernetes 是用来管理容器的，但是不直接操作容器，最小的操作单元是 Pod（间接管理容器）
一个 Master 对应一群 Node 节点。
Master 节点不存储容器，只负责调度，网关，控制器，资源对象存储等
容器存储在 Node 节点 的 Pod 内部
Pod 内部可以有一个或多个容器
kubelet 负责本地的 Pod 的维护，CRUD
kube-proxy 负责负载均衡，在多个 Pod 间负载均衡
