K8s应用场景简概

k8s应用场景简概

#1. 1  k8s 在企业中的应用场景
o1.1. 1.1  自动化运维平台
o1.2. 1.2  充分利用服务器资源
o1.3. 1.3  服务无缝迁移
#2. 2  服务部署模式变迁 & 服务部署变化问题的思考
o2.1. 2.1  服务部署模式是如何变迁的
o2.2. 2.2  服务部署模式变化，带来了哪些问题
#3. 3  云架构 & 云原生
o3.1. 3.1  云 和 k8s 的关系
o3.2. 3.2  云架构
o3.3. 3.3  云原生
#4. 4  kubernetes 架构原理
o4.1. 4.1  k8s 的历史
o4.2. 4.2  k8s 的架构
#4.2.1. 4.2.1  k8s 集群（Cluster）
#4.2.2. 4.2.2 master 节点
#4.2.3. 4.2.3 node 节点
o4.3. 4.3  回顾架构特点
kubernetes，简称 K8s，是用 8 代替中间 8 个字符 “ubernete” 而成的缩写，是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes 的目标是让部署容器化的应用简单并且高效(powerful)，Kubernetes 提供了应用部署，规划，更新，维护的一种机制。

1. 1 k8s 在企业中的应用场景

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

（1）可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）
（2）可扩展: 模块化，插件化，可挂载，可组合
（3）自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展
1.1. 1.1 自动化运维平台
（1）对于中小型企业，为了降本增效，使用 k8s 来构建一套自动化运维平台，提供了应用部署，规划，更新，维护的一种机制。

（2）对于大型互联网公司更要使用容器化部署。现在服务器越来越多，不可能都人工部署，需要使用自动化的运维平台来监控服务，来实现自动服务化的部署、运维。
1.2. 1.2 充分利用服务器资源

举例说明

    假设现在有一个开发量为 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

— 容器化解决方案，在服务器部署多个容器，容器当中运行着我们部署的各种服务
容器化方式：充分利用服务器资源

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

2. 2 服务部署模式变迁 & 服务部署变化问题的思考
   2.1. 2.1 服务部署模式是如何变迁的
   ------ 物理机：传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作。

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

------ 容器部署：每个容器之间互相隔离，每个容器有自己的文件系统 ，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。而且更轻量级、运行效率更快。
2.2. 2.2 服务部署模式变化，带来了哪些问题
前提条件：SOA 架构，微服务架构模式下，服务拆分越来越多，部署维护的服务越来越多，该如何管理？
虚拟机服务部署方式（通过 openstack 软件提供可视化的方式来管理虚拟机）
容器化部署模式（通过 k8s 软件管理容器，其实容器也可以看成一个虚拟机，只不过更轻量级）

容器化部署问题：
如何对服务横向扩展？
容器宕机怎么办？如何恢复？
重新发布版本如何更新且更新后不影响业务？
如何监控容器？
容器如何调度创建？
数据安全性如何保证？
使用 k8s 管理容器，以上问题都能够完美的解决！
3. 3 云架构 & 云原生
3.1. 3.1 云 和 k8s 的关系
— 云：使用容器构建的一套服务集群网络，云是由很多的容器构成。

— k8s：用来管理云中的容器
3.2. 3.2 云架构
IAAS：基础设施即服务
用户角度：租用（购买或分配权限）云主机，用户不用考虑网络、DNS、存储和硬件环境等方面的问题。
运营商角度：提供网络、DNS、存储等这样的服务就叫做基础设置服务

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

SAAS：软件即服务
钉钉、财务管理等等，一些软件维护工作都是由运行商来做，用户只管体验软件提供的服务就行了。
SERVERLESS：server 服务，less 无 -------无服务 不需要服务器
站在用户角度考虑问题，用户只需要使用云服务器即可。
在云服务器上的所有的基础环境、软件环境都不需要考虑和维护，非常方便。

未来开发的趋势都是 SERVERLESS ，企业都构建了自己的私有云或者公有云环境。使用 k8s 构建非常方便。
3.3. 3.3 云原生
为了让应用程序（项目，服务软件）都运行在云上的解决方案，这样方案叫做云原生，有以下特点：
容器化：所有的服务都必须部署在容器中。
微服务：web 服务架构是微服务架构
CI/CD：可持续交互和可持续部署
DevOps：开发和运维密不可分
4. 4 kubernetes 架构原理
4.1. 4.1 k8s 的历史
k8s 是由 Google 公司 用go 语言开发的。google 在全球有相当多的服务器，当然需要一个管理软件。Google内部本身就有一个叫 borg 的系统云平台管理工具，已经使用了十几年。后来参照 borg 系统架构开发了 k8s，主要用它来编排、管理容器，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。
4.2. 4.2 k8s 的架构
4.2.1. 4.2.1 k8s 集群（Cluster）
一个 master 对应一群 node 节点

4.2.2. 4.2.2 master 节点
api server：相当于 k8s 的网关，所有的指令请求都必须经过 api server
scheduler：调度器，使用调度算法，把请求资源调度到某个 node 节点
controller：控制器，维护 k8s 资源对象（CRUD：添加、删除、更新、修改）
etcd：存储资源对象（可以服务注册、发现等等）

4.2.3. 4.2.3 node 节点
docker：运行容器的基础环境，容器引擎
kubelet：每个 node 节点都有一份kubelet，在 node 节点上的资源操作指令由 kuberlet 来执行，scheduler 把请求交给api ，然后 api sever 再把信息指令数据存储在 etcd 里，于是 kuberlet 会扫描 etcd 并获取指令请求，然后去执行
kube-proxy：代理服务，负载均衡
fluentd：日志收集服务
pod：k8s 管理的基本单元（最小单元），pod 内部是容器。k8s 不直接管理容器，而是管理 pod

4.3. 4.3 回顾架构特点
k8s 是用来管理容器的，但是不直接操作容器，最小的操作单元是 pod（间接管理容器）
一个 master 对应一群 node 节点。
master 节点不存储容器，只负责调度，网关，控制器，资源对象存储等
容器存储在 node 节点 的 pod 内部
pod 内部可以有一个或多个容器
kubelet 负责本地的 pod 的维护，CRUD
kube-proxy 负责负载均衡，在多个 pod 间负载均衡