欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

K8s 部署应用必备

程序员文章站 2022-07-03 15:07:18
应用部署逻辑知识点介绍:当希望在Kubernetes上部署应用程序时,通常要定义三个组件;部署(Deployment):这是创建Pod应用程序副本的方法;服务(Service):将流量调度到Pods的内部负载平衡器;入口(Ingress):描述流量如何从集群外部流到服务。Cluster介绍:Cluster(集群)是计算、存储和网络资源的集合,Kubernetes利用这些资源运行各种基于容器的应用。最简单的Cluster可以只有一台主机(既是Master也是Node)。Master介绍:...

应用部署逻辑

知识点介绍:

当希望在Kubernetes上部署应用程序时,通常要定义三个组件;

  • 部署(Deployment):这是创建Pod应用程序副本的方法;
  • 服务(Service):将流量调度到Pods的内部负载平衡器;
  • 入口(Ingress):描述流量如何从集群外部流到服务。
Cluster介绍:

Cluster(集群)是计算、存储和网络资源的集合,Kubernetes利用这些资源运行各种基于容器的应用。
最简单的Cluster可以只有一台主机(既是Master也是Node)。

Master介绍:

Master是Cluster的大脑,它的主要职责是调度、即决定应用放在那里运行。
Master运行Linux操作系统,可以是物理机也可以是虚拟机
为了实现高可用,可以运行多个Master

Node介绍:

Node的职责是运行容器应用
Node由Master管理,Node负责监控并汇报容器状态,并根据Master的要求管理容器的生命周期
Node运行在Linux操作系统,可以是物理机也可以是虚拟机

Controller介绍

Kubernetes通常不会直接创建Pod,而是通过controller管理pod。controller中定义了pod的部署特性,比如有几个副本,在什么样的Node上运行等。为了满足不同的应用场景,Kubernetes提供了多种Controller,包括Deployment,RePlicaSet、DaemonSet、StatefulSet、Job等。
各个Controller介绍
Deployment
DepolyMent是最常见的Controller,比如我们可以通过创建Deployment来部署应用。
Deployment可以管理Pod的多个副本,并确保Pod按期望运行。
RePlicaSet
RePlicaSet实现了pod的多副本管理
使用Deployment时会自动创建RePlicaSet,也就是说Deployment是通过RePlicaSet来管理Pod的多个副本的,我们通常不需要直接使用RePlicaSet。
 DaemonSet
DaemonSet用于每个Node最多只运行一个Pod场景,正如其名称所揭示的,DaemonSet通常用于运行daemon。
 StatefulSet
StatefulSet能够保证Pod的每个副本在整个生命周期中名称是不变的。而其他Controller不提供这个功能
当某个Pod发生故障需要删除并重新启动时,Pod的名称将会发生变化。同时StatefulSet会保证副本按照固定的顺序启动、更新或者删除。
Joba
Job用于运行结束就删除的应用。而其他Controller中的pod通常是长期持续运行。
Service介绍
Deployment可以部署多个副本,每个Pod都有自己的IP,Pod可能会被频繁的销毁和重启,它们的IP会随时变化,用IP来访问Deployment不太现实。
Service定义了外界访问一组特定的Pod的方式,Service有自己的IP和端口,Service为Pod提供了负载均衡。
NameSpace介绍
namespace可以将一个物理的Cluster逻辑上划分成多个虚拟的Cluster,每一个Cluster就是一个namespace,不同namespace里面的资源是完全隔离的

Pod介绍:
 Pod是Kubernetes的最小工作单元
 每个Pod包含一个或多个容器,Pod中的容器会作为一个整体被Master调度到一个Node上运行。
Kubernetes引入Pod的目的
 可管理性
有些容器天生就需要有紧密的联系,一起工作。Pod提供了比容器更高层次的抽象,将它们封装到一个部署单元中。
Kubernetes以Pod为最小单位进行调度、扩展、共享资源、管理生命周期。
 通信和资源共享
Pod中的所有容器使用同一个网络namespace,即相同的IP地址和Port空间。它们可以直接用localhost通信。
同样的、这些容器可以共享存储,当Kubernetes挂在volume到Pod,本质上是将volume挂载到Pod中的每一个容器。
Pod的两种使用方式
 运行单一容器
one-container-per-Pod 是Kubernetes最常见的模型,这种情况下,只是将单个容器封装成Pod;
即便是只有一个容器,Kubernetes管理的也是Pod而不是直接管理容器。

 运行多个容器
对于那些联系非常紧密的,而且需要直接共享资源的容器,应该放在同一个Pod中。
比如下面这个Pod包含两个容器:一个File Puller,一个是Web Server。File Puller会定期从外部的Content Manager中拉取最新的文件,将其存放在共享的volume中。Web Server从volume中读取文件,响应controller的请求。这两个容器是紧密协作的,他们一起为Consumer提供最新的数据。同时他们也通过volume共享数据。所以放到一个pod是最合适的。
在Kubernetes集群中,Pod 是所有业务类型的基础,它是一个或多个容器的组合。这些容器共享存储、网络和命名空间,以及如何运行规范。在Pod中,所有容器都被统一安排调度,并运行在共享的上下文中。对于具体应用而言,Pod是他们的逻辑主机,Pod包含业务相关的多个应用容器。
Kubernetes不只是支持Docker容器,它也支持其它容器。
Pod的上下文可以理解成多个linux命名空间的联合:
 PID命名空间(同一个Pod中应用可以看到其它进程)
 网络命名空间(同一个Pod中的应用对相同的IP地址和端口有限)
 IPC命名空间(同一个Pod中的应用可以通过VPC或者POSIX进行通信)
 UTS命名空间(同一个Pod中的应用共享一个主机名称)
在Pod中,容器共享一个IP地址和端口空间,他们可以通过localhost发现彼此。
在不同Pod中的容器,拥有不同的IP地址,因此不能直接在进程间进行通信。
容器之间通常通过Pod IP地址进行通信。
在Pod被创建时,会分配一个唯一ID,并被调度到Node中,直到Pod被终止或删除。如果Pod所在的Node宕机,给定的Pod不会被重新调度,它将被完全相同的Pod代替。
一般来说,用户不应该直接创建Pod,即是创建单个的Pod也应该通过控制器创建。在集群范围内,控制器为Pod提供自愈能力,以及副本和部署管理。
一个多容器的Pod会包含一个文件拉取器和一个Web服务器,此web服务器会使用一个持久化存储卷在容器*享存储
每一个pod都会被指派一个唯一的ip地址,在pod中每一个容器共享网络命名存储空间,包括IP和网络端口。当pod中的容器需要和pod外的实体进行通信时,则需要通过端口等网络资源。
Pod能够被指定共享存储卷的集合,在pod中所有容器能访问共享存储卷,允许这些容器共享数据,存储卷也允许在一个pod持久化数据,以防止其中的容器需要被重启。
Pod的工作方式:
Pod是一个临时存在的实体,所以Kubernetes不会直接创建一个独立的pod。当直接创建一个独立的pod,如果缺少资源或者所被调度到的node失败,则pod会被删除。
重启pod和重启pod中的容器不是同一个概念,pod自身不会运行,它只是容器运行的环境。通过控制器能创建和管理多个pod,并在集群范围内处理副本、部署和提供自愈能力。
例如:当一个Node失败,控制器可以自动在另外的节点上部署一个完全一样的副本。控制器是Pod模板来创建pod。
Pod模板是一个被包含在其它对象(例如:Deployment、StatefulSet、DaemonSet等)中的Pod规格
Pod重启策略:
在pod中的容器可能会由于异常等原因导致其终止退出,Kubernetes提供了重启策略以重启容器。重启策略对同一个Pod中的所有容器起作用,容器的重启,是由Node上的kubelet执行。Pod支持三种重启策略,在配置文件中通过restartPolicy字段设置重启策略。
  Always:只要退出就重启;
  OnFailure:只有在失败退出(exit code != 0 )时,才会重启。
  Never:只要退出,就不再重启;
这里的重启是指在Pod的宿主Node上进行本地重启,而不是调度到其它Node上。
Volume介绍
Docker的数据持久化方式
Volume绕过container的文件系统,直接将数据写到host机器上,只是volume是被docker管理的,docker下所有的volume都在host机器上指定的目录下(/var/lib/docker/volumes)

数据持久化介绍
狭义的理解: “持久化”仅仅指把域对象永久保存到数据库中;广义的理解,“持久化”包括和数据库相关的各种操作。
● 保存:把域对象永久保存到数据库。
● 更新:更新数据库中域对象的状态。
● 删除:从数据库中删除一个域对象。
● 加载:根据特定的OID,把一个域对象从数据库加载到内存。
● 查询:根据特定的查询条件,把符合查询条件的一个或多个域对象从数据库加载内在存中。
2.为什么要持久化?
持久化技术封装了数据访问细节,为大部分业务逻辑提供面向对象的API。
● 通过持久化技术可以减少访问数据库数据次数,增加应用程序执行速度;
● 代码重用性高,能够完成大部分数据库操作;
● 松散耦合,使持久化不依赖于底层数据库和上层业务逻辑实现,更换数据库时只需修改配置文件而不用修改代码。
部署过程:
一旦运行了Kubernetes集群,就可以在其上部署应用;
1、 创建Deployment配置,Deployment将指挥Kubernetes如何创建和更新应用程序的实例。
2、 创建Deployment成功后,master节点将应用实例调度到集群中的各个节点上
3、 创建应用实例成功后,Kubernetes deployment控制器会持续监控这些实例
4、 如果托管实例的节点关闭或被删除,deployment控制器会将该实例替换为集群中的另一个节点上的实例。这提供一种自我修复机制解决故障维护问题
5、 控制器管理pod
a) Deployment:无状态部署,例如web,微服务 ,API;
b) StatefulSet:有状态部署,例如数据库,ZK、ETCD;
c) DaemonSet:守护进程部署,例如监控Agent,日志Agent;
d) Job&CronJob:批处理,例如数据库库备份、邮件通知;
6、 pod数据持久化
容器部署过程一般会有以下三种数据:
 启动时需要的初始数据,可以是配置文件;
 启动过程中产生的临时数据,该临时数据需要多个容器间共享;
 启动过程中产生的业务数据

本文地址:https://blog.csdn.net/Scott_zt/article/details/108868979