概念理论类-k8s :架构篇

转载:新手通俗易懂 k8s :架构篇

Kubernetes,读音是[kubə’netis],翻译成中文就是“库伯奈踢死”。当然了,也可以直接读它的简称:k8s。为什么把Kubernetes读作k8s,因为Kubernetes中间有8个字母,所以简称为k8s。k8s是一个开源的,用于管理云平台中多个主机上的容器化的应用,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

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

概念理论类-k8s :架构篇_第1张图片

服务无缝迁移

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

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

概念理论类-k8s :架构篇_第2张图片

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

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

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

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

前提条件: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)

概念理论类-k8s :架构篇_第3张图片

一个 master 对应一群 node 节点

master 节点

概念理论类-k8s :架构篇_第4张图片

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

  • scheduler:调度器,使用调度算法,把请求资源调度到某个 node 节点

  • controller:控制器,维护 k8s 资源对象(CRUD:添加、删除、更新、修改)

  • etcd:存储资源对象(可以服务注册、发现等等)

node 节点

概念理论类-k8s :架构篇_第5张图片

  • 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 间负载均衡

你可能感兴趣的:(k8s)