从最基础开始了解k8s,首先需要清楚三个问题:
- k8s是怎么出现的?
- 他解决了什么问题?
- 整体架构是什么样的,有哪些优缺点?
从以上三个问题出发,本文将分为三个章节,讲述K8S的一些基础概念。
发展历程
接触K8S之前,就得先了解一下云计算这个概念,因为他也是云计算中的一个产物。
云计算指的是通过网络云将巨大的数据计算处理程序分解成无数个小程序,然后通过多台服务器组成的系统进行处理和分析这些小程序得到结果并返回给用户。
说人话就是分而治之,一个人完成不了的事,就找多个人来完成,这也是近些年微服务架构发展这么火热的一个背景。
- IAAS(Infrastructure as a Service)基础设施即服务,例如阿里云。
-
PAAS(Platform as a Service) 平台即服务,例如新浪云,K8S属于这个层面的应用。
- SAAS(Software as a Service)软件即服务,例如office全家桶,访问浏览器版的office即可使用一些基础功能,,目前市面上大多数公司都在做软件。
- 用户下单到云厂商,厂商的运维工程师再手动构建环境。
- 采用工具进行自动化构建环境
- 使用docker构建运行环境的封装体,但端口的转发和映射会很杂乱,资源的使用率低下。
- 资源管理器Mesos(Apache)
- docker-Swarm集群化方案,虽然很轻量,只占几十MB,但是缺乏很多功能,例如滚动更新,回滚
- kubernetes(Google)最初的brog系统,谷歌怕落伍,于是用go语言在brog的基础上开发出kubernates,很多人甚至会说,k8s会是下一代操作系统,关于K8S的一些特性,会在后文讲到
解决痛点
我们在使用新技术之前,应该去思考一下,为什么要使用这套系统,能够解决我们什么问题?
- 有很多并未实现容器化的公司,部署方式就是运维工程师在服务器上构建好运行环境之后,将开发人员提供的jar包,使用java -jar命令,后面跟一堆参数,才能将这个服务运行起来。
- 实现容器化的公司,会将微服务都打包成镜像,通过docker以容器的方式运行起来,会方便很多,但是当微服务多起来之后,拆分的细致的话,甚至会有上百个微服务,这个时候,容器的运维管理,依然会是个麻烦事儿。
- k8s最基础的功能就是容器编排,屏蔽掉了很多上层的容器管理操作,不仅如此,他还提供了很多实用特性,例如弹性伸缩,滚动更新等等…
优缺点
- 只要应用能够打包进容器,K8S就一定能够启动它,不用关心环境依赖等问题。
- Kubernetes 如果发现有节点工作不饱和,便会重新分配 pod,节省开销,高效的利用内存、cpu等资源。如果一个节点宕机了,Kubernetes 会自动重新创建之前运行在此节点上的 pod,调度到其他节点上运行。
- 网络、负载均衡、pod复制等特性,对于 Kubernetes 都是开箱即用的,不用去做一些复杂的配置。
- 能够通过探针检测,实现应用永远提供服务(有pod宕掉之后,会有其他的pod顶上去),也可以根据实际的系统性能做弹性伸缩,将资源利用率最大化。
- 简化CI/CD,完美符合DevOPS的思想。可以将CI服务打包进pod中运行。
总结
上述是PAAS这个层面看整个运维方式的发展历程,是一步步的自动化的过程,这些技术的出现,并不是像大家口中玩梗所说的替代运维工程师,他们的出现是将工程师们从繁杂重复的工作中解救出来。工程师们也应该去学习如何使用和驾驭。