Kubernetes （k8s）在企业项目中的重点应用场景以及云原生和云架构的原理

Kubernetes （k8s在企业项目中的重点应用场景以及云原生和云架构的原理。

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

Kubernetes 在企业中的应用场景

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

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

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

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

自动化运维平台

对于中小型企业为了降本增效使用 Kubernetes 来构建一套自动化运维平台提供了应用部署规划更新维护的一种机制。

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

充分利用服务器资源

举例说明

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

静态请求150（访问 CDNNginxcache 等

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

估算服务器资源（只考虑内存不考虑程序响应时间RT不考虑CPU切换时间

假设一个静态请求进程占用 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

容器化解决方案在服务器部署多个容器容器当中运行着我们部署的各种服务

服务无缝迁移

在开发环境开发然后拿到测试环境去测试但往往一上线就会有 bug因为应用的运行、配置、管理、所有生存周期将与当前操作系统绑定所以生产环境的不一致就可能导致错误。

使用容器化解决方案每个应用可以被打包成一个容器镜像（红色圈起来表示把服务部署在容器中使用容器可以在 开发 或 测试 的阶段为应用创建容器镜像这些镜像能够完全脱离环境每个应用不需要与其余的应用堆栈组合也不依赖于生产环境基础结构这使得从研发到测试、生产能提供一致环境。使用 kubernetes 来管理这些容器便能够实现服务的无缝迁移。

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

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

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

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

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

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

前提条件SOA 架构微服务架构模式下服务拆分越来越多部署维护的服务越来越多该如何管理？

虚拟机服务部署方式（通过 OpenStack 软件提供可视化的方式来管理虚拟机

容器化部署模式（通过 Kubernetes 软件管理容器其实容器也可以看成一个虚拟机只不过更轻量级

容器化部署问题

如何对服务横向扩展？

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

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

如何监控容器？

容器如何调度创建？

数据安全性如何保证？

使用 Kubernetes 管理容器以上问题都能够完美的解决 ✿✿ヽ(°▽°)ノ✿

云架构 & 云原生

云和 Kubernetes 的关系

云使用容器构建的一套服务集群网络云是由很多的容器构成。

Kubernetes用来管理云中的容器

云架构

IaaS基础设施即服务

用户角度租用（购买或分配权限云主机用户不用考虑网络、DNS、存储和硬件环境等方面的问题。

运营商角度提供网络、DNS、存储等这样的服务就叫做基础设置服务

PaaS平台即服务

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

SaaS软件即服务

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

Serverlessserver 服务less 无 —— 无服务 不需要服务器

站在用户角度考虑问题用户只需要使用云服务器即可。

在云服务器上的所有的基础环境、软件环境都不需要考虑和维护非常方便。

未来开发的趋势都是 Serverless企业都构建了自己的私有云或者公有云环境。使用 Kubernetes 构建非常方便。

云原生

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

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

微服务Web 服务架构是微服务架构

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

DevOps开发和运维密不可分

Kubernetes 架构原理

Kubernetes 的历史

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

Kubernetes 的架构

Kubernetes 集群（Cluster

一个 Master 对应一群 Node 节点。

Master 节点

API Server相当于 Kubernetes 的网关所有的指令请求都必须经过 API Server

Scheduler调度器使用调度算法把请求资源调度到某个 Node 节点

Controller控制器维护 Kubernetes 资源对象（CRUD添加、删除、更新、修改

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

Node 节点

Docker运行容器的基础环境容器引擎

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

kube-proxy代理服务负载均衡

Fluentd日志收集服务

PodKubernetes 管理的基本单元（最小单元Pod 内部是容器。Kubernetes 不直接管理容器而是管理 Pod。

回顾架构特点

Kubernetes 是用来管理容器的但是不直接操作容器最小的操作单元是 Pod（间接管理容器

一个 Master 对应一群 Node 节点。

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

容器存储在 Node 节点 的 Pod 内部

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

kubelet 负责本地的 Pod 的维护CRUD

kube-proxy 负责负载均衡在多个 Pod 间负载均衡