K8s 部署应用必备

应用部署逻辑

知识点介绍：

当希望在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