早期的部署模式,直接将应用部署到物理机上
优点:简单,不需要其他技术的参与
缺点:不能为应用程序定义资源使用边界,很难合理分配计算资源,而且程序之间容易产生影响
可以在一台物理机上运行多台虚拟机,每个虚拟机都是独立的运行环境
优点:程序运行环境不会互相影响,资源容易分配,且安全性较高
缺点:每台虚拟机都需要安装操作系统,造成了部分的资源的浪费
与虚拟化类似,区别是共享底层操作系统
优点:
1、每个程序的运行资源都是分配好的;
2、运行容器仅需运行程序所需的最小化系统需求即可,相比虚拟化来说体积更小;
3、容器之间程序运行是互相隔离的,具有较高的安全性
大家可借用下面这张图来形象的查看几种部署方式的区别
容器化部署方式带来了很多便利,但是也会出现一些问题,比如说:
我们拿Swarm和Kubernetes的市场占用率情况,选择那款由各自自己决定咯
按官网的说法就是Kubernetes是用于自动部署,扩展和管理容器化应用程序的开源系统。 它将组成应用程序的容器组合成逻辑单元,以便于管理和服务发现。Kubernetes 源自Google 15 年生产环境的运维经验,同时凝聚了社区的最佳创意和实践。
废话不多说,我们来看一下Kubernetes的特性,官网描述如下:
那Kubernetes具备这么特性,能做什么呢,我们来列举几点:
Kubernetes集群主要包含控制节点(master)和工作节点(worker)这两种角色,每个节点安装不同的组件。 master节点:
Apiserver:资源操作的唯一入口,接收用户输入的命令
Scheduler:负责集群的资源调度,按照预定的调度策略将pod调度到相应的node节点上
ControllerManger:负责维护集群的状态,比如程序部署安排,故障检测,自动扩展,滚动更新等
Etcd:负责存储集群中各个资源对象的信息
worker节点:
Kubelet:负责维护容器的生命周期,即通过Docker实现容器的创建、更新、销毁等
KubeProxy:为集群内部的运行容器提供服务发现和负载均衡
Docker:负责各节点上的容器的操作
在这里要说明一下,在Kubernetes中,一切皆资源,就像Java当初说的那样,一切皆对象,Kubernetes中的资源有:Pod,Service,DaemonSet等
结合上图我们来描述下各个组件的协作流程,列举资源操作的流程 1、ApiServer作为资源操作的唯一入口,首先接收到由用户端发送的资源操作的请求 2、ApiServer向Scheduler发起询问,要Scheduler调度一台可用的节点 3、Scheduler通过计算得出节点数据返回给ApiServer 4、ApiServer将资源操作的请求和节点信息发送给ControllerManager 5、ControllerManager根据节点信息发送资源操作请求 6、节点上的kubelet接收到资源操作的请求,将资源操作发送到底层的Docker进行操作
上述步骤并未涉及到KubeProxy,那么KubeProxy的作用时啥呢?KubeProxy就是提供节点上运行容器的服务访问入口点,比如:在节点1上部署了一个nginx的服务,外部无法访问,只能通过KubeProxy做一层代理,将nginx服务代理到外部,在宿主机节点上生成一个端口映射到容器内部的nginx服务端口
Master: 集群控制节点,每个集群至少一个master节点 Node: 工作节点,由master分配容器到这些工作节点上,然后由工作节点上的docker负责容器的运行 Pod: k8s的最小控制单元,容器运行在pod中,一个pod包含多个容器 Controller: 控制器,通过他实现对pod的管理,比如pod的启动,停止,销毁等 Service: pod对外提供服务的入口,Service下面可以维护同一类pod,一般是同一类标签 Label: 标签,用于对pod进行分类,同一类的pod拥有同样的标签 NameSpace: 命名空间,用来隔离pod的运行环境