一、部署模式
传统部署模式: 在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界,这会导致资源分配问题。例如:在物理服务器上运行多个应用程序,可能会出现一个应用程序占用大部分资源的情况,导致其他应用程序的性能将下降。解决方案是在不同的物理服务器上运行每个应用程序。但是,这并没有随着资源利用不足而扩展,并且组织维护许多物理服务器增加运维成本。
虚拟化部署模式:将计算机的各种实体资源,如服务器、网络、内存及存储等,予以抽象、转换后呈现出来,打破实体结构间的不可切割的障碍,使用户可以更好地利用物理服务器中的资源,并可以实现更好的可伸缩性,轻松地添加或更新应用程序,降低硬件成本。
容器部署模式:容器类似于VM,但是它们具有轻松的隔离属性和易迁移的特性,可以在应用程序之间共享操作系统(OS)。容器有独立的网络和存储栈,还拥有自己的资源管理能力,使得同一台宿主机中的多个容器可以友好的共存。由于它们与基础架构分离,因此可以跨云和OS分发进行移植。
使用容器部署模式可以帮助开发和运维人员在快捷、灵活的部署应用,专注于构件程序和使用容器而非管理设备上,只需要完成程序的Docker化,不需要关心云上的Iaas层计算资源,就可以通过部署容器把应用程序运行起来。
二、kubernetes基本概念
Kubernetes(k8s)是Google开源的容器集群管理系统(谷歌内部:Borg)。在Docker技术的基础上,为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,提高了大规模容器集群管理的便捷性。Kubernetes是为生产环境而设计的容器调度管理系统,对于负载均衡、服务发现、高可用、滚动升级、自动伸缩等容器云平台的功能要求有原生支持。由于Kubernetes在K和s间有8个字母,因此常简称K8s。
1、Cluster(集群)
Cluster 是计算、存储和网络资源的集合,Kubernetes 利用这些资源运行各种基于容器的应用。最简单的 Cluster 可以只有一台主机(它既是 Mater 也是 Node),常用Cluster部署为3主4从。
2、Master(主节点)
Master 是 Cluster 的大脑,主要负责对Node进行管理,对Pod进行分配调度。
(1)etcd:对集群中的资源、对象进行持久化存储,主要包括Node、Service、Pod、RC、Namespace等。
(2)api service:为操做资源、对象提供统一访问入口,例如可以对资源数据进行查询、监控等。
(3)scheduler:负责Pod在集群节点中的分配。
(4)controller manager:集群的管理控制中心,主要负责检测集群故障和恢复的自动化工作。
a、Deployment:对 Pod 中的多个副本进行管理,确保 Pod 按照期望的状态运行。
b、ReplicaSet:Deployment 使用时会自动创建 ReplicaSet,通过 ReplicaSet 来管理 Pod 的多个副本。
c、DaemonSet:对 Node 节点中最多只运行一个 Pod 副本的使用场景。
d、StatefuleSet:负责 Pod中每个副本在整个生命周期中信息的一致性。例如:某个 Pod 发生故障需要删除并重启时保证Pod 的名称不变。同时 StatefuleSet 会保证副本按照固定的顺序启动、更新或者删除。
e、主要用于运行结束就删除的应用。
3、Node(从节点)
Node 负责为容器应用提供运行环境,并对容器状态向master进行汇报,并根据 Master 的指令对容器应用进行全生命周期管理。
(1)docker:提供Pod运行环境。
(2)kubelet:负责对Node节点上的Pod进行全生命周期管理,同时负责将本节点状态上报给Master和api server。
(3)kubeproxy:实现了Service的代理和软件模式的负载均衡器。
4、Pod(容器组)
Pod 是 Kubernetes 的最小工作单元。每个 Pod 包含一个或多个容器。Pod 中的容器会作为一个整体被 Master 调度到一个 Node 上运行。
5、service(服务)
定义了外界访问一组特定 Pod 的方式。Service 有自己的 IP 和端口,Service 为 Pod 提供了负载均衡。Kubernetes中 运行容器(Pod)与访问容器(Pod)这两项任务分别由 Controller 和 Service 执行。
5、Namespace(命名空间)
将一个物理的 Cluster 逻辑上划分成多个虚拟 Cluster,每个 Cluster 就是一个 Namespace。不同 Namespace 里的资源是完全隔离的。
6、Ingress
一组基于DNS名称(host)或URL路径把请求转发到指定的Service资源的规则。用于将集群外部的请求流量转发到集群内部完成的服务发布。Ingress 通过把 Nginx 负载配置功能抽象出来,变成一个 Ingress 对象,不需要再修改 Nginx配置信息 ,可以通过创建 yaml ,更改 yaml 进行配置更新;
(1) Ingress controller:Ingress资源监听套接字并将流量转发的组件。不同于Master 中的Controller,Ingress controller不直接运行为kube-controller-manager的一部分,是Kubernetes集群的一个附件,类似于CoreDNS,需要在集群上单独部署。Ingress Controoler 通过与 Kubernetes API 交互,动态的去感知集群中 Ingress 规则变化,动态读取,按照他自己模板生成一段 Nginx 配置,再写到 Nginx Pod 中并进行动态更新。