快速网站开发 带数据库代理广告投放平台

deployment是个控制器

主要负责管理pod，来代表k8s集群向外提供稳定的服务。

说，k8s有很多优点。

说k8s的优点，可能先需要说容器提供的便利。

同样的硬件资源

跑几个虚拟机，每个虚拟机上跑几个服务。

就挺重了。风扇呼呼叫

cpu温度嘎嘎上

这，大家叫资源消耗太高

那么提供同样量级的算力、存储等服务

容器化应用需要的资源少很多

服务器感觉也比较轻松

同样

同样的资源供给，容器化应用提供的服务量级更高，可以响应更多的服务

为数据服务的提供方，比如企业，提供更高的服务处理能力。

容器的底层技术来自于镜像

镜像由一层层的只读文件组成

这些只读文件，提供的是容器运行的环境。

比如，跑一个nginx容器，容器里面是nginx进程

跑这个容器，需要一个nginx镜像

镜像里面有多个只读层。

这些只读层，都需要linux操作系统的什么

总不至于需要整个linux操作系统吧

整个linux操作系统包含几乎跑所有服务的所有系统级别的环境

而nginx只需要linux操作系统的操作系统级别的操作系统的一部分资源

把这些资源，做成只读文件，这个只读文件，在容器镜像的角度来讲

就是容器镜像的一个基础层

在这个基础层上，跑nginx进程还需要什么，比如说，

有了操作系统，起码得有nginx软件包的那些东西吧

对，把软件包的那些东西作用一个只读文件，算容器的镜像的一个层

放到基础层上面去

然后还需要什么

需要环境变量，跑nginx时，环境变量需要怎样

弄个文件，弄个只读层

放上去

还需要什么

nginx的配置文件，和调用配置文件，是实现nginx功能的

一个配置的重点

也写成文件，做成只读层。

总的来说，容器镜像。就是多个只读的文件。

是容器运行的环境以及配置。

当用docker run或者写dockerfile，启动容器的时候

那么docker程序就会通过cpu的计算

来读取容器镜像的这些只读文件

来跑一起来一个里面运行着nginx进程的容器

这个怎么听起来像是和虚拟机区别也不是很大。

那么容器和虚拟机有几个比较大的区别：

1.如何调用硬件资源

容器直接找操作系统，让操作系统找cpu进行工作

虚拟机里面的进程，需要找虚拟机的操作系统，然后虚拟机的操作系统需要找虚拟化技术做出来的虚拟化层qemu，qemu负责把虚拟机内操作系统的请求，转发给cpu。

相对比，虚拟化技术比容器化技术，对于从进程的请求达到cpu，的这个链路上，多了一个虚拟机的操作系统，和虚拟化层的qemu

qemu是个仿真器，可以给虚拟机提供虚拟硬盘，虚拟内存，虚拟网卡等

kvm是个支持虚拟化的内核模块，qemu仿真器和kvm内核模块，一起工作，可以做出来比较不错的虚拟机。而虚拟机不仅需要虚拟化的计算存储网络硬件资源，还需要虚拟的操作系统内核，每一个虚拟机需要，相当于复制一份操作系统内核。

那么从数据链路上来讲，容器里的进程和虚拟机里的进程，都找物理cpu工作

虚拟机比容器多了两个较明显的步骤

一个是进程的请求先要打到虚拟机操作系统上，第二个是虚拟机操作系统的请求要打到虚拟化层qemu这里，然后qemu把这个请求给物理操作系统的内核模块kvm，kvm把这个请求发给cpu。

而容器里面进程的请求链路是这样的，容器里面的进程请求直接找物理操作系统的内核，然后物理操作系统的内核，把请求发给cpu

对比之下，容器的链路就少了虚拟操作系统，和qemu，这两个层。

请求的链路是这样的。那么响应的链路，也是多了这两个层。

所以虚拟机的数据链路就要比容器长一些。

从资源消耗角度来看，多的这两个层，一个是虚拟机的操作系统，需要复制物理机上的操作系统，一个是qemu要模拟出来的虚拟硬件软件等资源。

应该都需要占用一些计算和存储的资源。

加上通信链路的长度。

容器比虚拟机占用的资源更少，响应速度更快。

而虚拟机比容器隔离性可能更好，因为每个虚拟机有一个自己的操作系统。

这样的特点，可能就比较能够了解了。

那么k8s在容器的基础上

有一个比较受欢迎的地方

是，k8s的自动化部署、管理、编排容器的能力比较不错。

那么k8s实现这样的功能，是需要比较多的组件。

部署、管理、编排，这些功能，在不容器化的时候

在物理机和虚拟机上，也讲究部署管理编排。

那么k8s这里，除了操作对象的是容器，

还有什么特别的呢

这个就跟控制器deployment有关系

deployment控制器，管理的资源对象是pod

pod里面是数个容器，容器里面是进程，进程可以有一个，也可以有多个

一般情况下一个容器主要跑一个进程

deployment控制器是k8s控制器里面比较常用的

它通过replicaset管理pod

一条命令，kubectl  scale  deployment  xxx  replicas=number

number是数字，写几，deployment控制器就会让replicaset把pod的的数量调整到几

而不用手工增加pod

如果有的pod不在运行状态了

deployment可以自动维护pod的数量，自动创建

比如，replicas设置的是9个pod，其中的3个被删除，那么deployment控制器会让replicas自动再创建3个新的pod，而这个过程不用管理人员去管。

是deployment控制器自动去操作的。

这个就体现了自动化运维。

那么为什么对外发布服务的时候要用deployment结合nodeport进行发布呢

而不是直接用pod和nodeport发布

是因为deployment相当于一个pod的总管理

外面服务要访问pod进程提供的服务，找deployment就行了。

pod部署在哪个节点上，

pod的迁移，

pod的重启，

pod的数量扩展

pod的滚动更新

这些操作，对于k8s集群外部来的访问，都不用太关心。

外部的访问只用到达deployment这一层就行了

deployment负责提供服务。

pod的滚动更新的意思是

新的pod产生了，而且running比较ok

才会逐步删除旧的pod

这样就会实现服务的不停机更新。

比如deployment管的这些pod提供的是nginx服务

里面nginx的版本要从一个旧的更新成新的。

那么新版本的pod会逐步生成

旧版本的pod会逐步删除

在服务的使用的那一方

体验是平稳的。

所以，应该可以这样认为

nodeport转发进来的服务

给到deployment，是更符合实践需要的。