pod根底概念

pod是kubernetes中最小的资源办理组件，Pod也是最小化运转容器化运用的资源目标。一个Pod代表着集群中运转的一个进程。kubernetes中其他大多数组件都是用绕着Pod来进行支撑和扩展Pod功能的，例如，用于办理eod运转的StatefulSet和Deploment等控制器目标，用于露出pod运用的service和Ingress目标，为pod供给存储的PersistentVolme（PV）存储资源目标等。

在K8S集群中pod的两种运用方法

  1. 一个pod中运转一个容器。”每个pod中一个容器”的模式是最常见的用法:在这种运用方法中，你能够把pod幻想成是单个容器的封装，kterentes办理的是Pod而不是直接办理容器。

  2. 在一个Pod中一起运转多个容器。一个Pod中也能够一起封装几个需求严密耦合相互协作的容器，它们之间同享资源。这些在同一个Pod中的容器能够相互协作成为一个service单位，比方一个容器同享文件，另一个”sidecar”容器（边车容器）来更新这些文件。Pod将这些突器的存储资源作为一个实体来办理

pod 容器的常规运用流程

一个Pod下的容器必须运转于同一节点上。现代容器技术主张一个容器只运转一该进程在容器中PID命名空间中的进程号为1，可直接接纳并处理信号，进程中止时容个讲程，器生命固期也就结束了。若想在容器内运转多个进程，需求有一个相似Linux操作系统1进程的管控类进程，以树状结构完结多进程的生命周期办理。

运转于各自容器内的进程无法直接完结网络通讯，这是由于容器间的隔离机制导致，k8s中的Pod资源笼统正是处理此类问题，Pod目标是一组容器的集合，这些容器同享Network、UTS及IPC命名空间，因而具有相同的域名、主机名和网络接口，并可经过IPC直接通讯。

Pod资源中针对各容器供给网络指令空间等同享机制的是底层根底容器pause,根底容器( 也可称为父容器) pause就是为了办理Pod容器间的同享操作，这个父容器需求能够准确地知道如何去创立同享运转环境的容器，还能办理这些容器的生命周期。为了实现这个父容器的构想，kubernetes中，用pause容器来作为一个Pod中一切容器的父容器。这个pause容器有两个中心的功能，是它供给整个Pod的Linux命名空间的根底。二来启用PID命名空间，它在每个Pod中都作为PID为1进程(init进程)，并回收僵尸进程。

Kubernetes设计这样的Pod概念和特别组成结构的用意

  • 原因一：在一组容器作为一个单元的情况下，难以对全体的容器简略地进行判断及有效地进行行动。比方，一个容器死亡了，此刻是算全体挂了么?那么引进与事务无关的Pause容器作为Pod的根底容器，以它的状况代表着整个容器组的状况，这样就能够处理该问题。

K8S的pod基础

  • 原因二：Pod里的多个运用容器同享Pause容器的IP，同享Pause容器挂载的volume，这样简化了运用容器之间的通讯问题，也处理了容器之间的文件同享问题。

通常把Pod分为两类

自主式Pod

这种Pod自身是不能自我修复的，当Pod被创立后 (不论是你直接创立仍是被其他的Controller)，都会kuberentes调度到集群的node上。直到node的进程中止、被删掉、由于短少资源资源而被驱赶、或许node节点毛病之前都会一向保持在那个node上。pod不会自愈。假如pod运转时，地点的node节点 毛病，或许是调度器自身毛病，这个pod就会被删去。同样的，假如Pod地点Node短少资源或许Pod处于保护状况，Pod也会被驱赶。

控制器办理的Pod

Kubernetes运用更高级的概为controller的笼统层，来办理eod实例。controller能够创立和办理多个pod，供给副本办理、翻滚升级和集群等级的自愈才能。例如，假如一个Node毛病，Controller就能自动将该节点上的Pod调度到其他健康的node上。尽管能够直接运用Pod，可是在Kubernetes中通常是运用controller来办理Pod的。

Pod容器的分类

pause根底容器（infrastructurecontainer）

  • 保护整个Pod网络和存储空间
  • node节点中操作
  • 发动一个Pod时，k8s会自动发动一个根底容器
cat /opt/ kubernetes/cfg/ kubelet
......
--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0
  • 每次创立Pod时候就会创立，运转的每一个Pod都有一个pause-amd64 的根底容器自动会运转，对于用户是透明的
docker ps -a
registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"/pause"

检查pause容器的根底镜像

检查pause容器的根底镜像：docker images

K8S的pod基础

装备kubelet运用阿里云的镜像

#检查pause装备镜像文件
cat /etc/sysconfig/kubelet

K8S的pod基础

#装备修改为阿里的官方pause镜像源，再重启一下kubelet
cat > /etc/sysconfig/kubelet << EOF
KUBELET_EXTRA_ARGS=--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"
EOF

pause容器的效果

  • 在pod中担任Linux命名空间( 如网络指令空间)同享的根底
  • 启用PID命名空间，敞开init进程。

K8S的pod基础

pause容器使得Pod中的一切容器能够同享两种资源：网络和存储

  • 网络：
    • 每个Pod都会被分配一个仅有的IP地址。Pod中的一切容器同享网络空间，包括IP地址和端口。Pod内部的容器能够运用localhost相互通讯。Pod中的容器与外界通讯时，必现分配同享网络资源（例如运用宿主机的端口映射）。
  • 存储：
    • Pod能够指定多个同享的Volume。Pod中的一切容器都能够访问同享的Volume。Volume也能够用来耐久化Pod中的存储资源，以防容器重启后文件丢掉。

K8S的pod基础

总结

每个Pod都有一个特别的被称为”根底容器”的Pause容器。Pause容器对应的镜像归于Kubernetes平台的一部分，除了Pause容器，每个Pod还包括一个或许多个严密相关的用户运用容器。

初始化容器（initcontainers)

Init容器必须在运用程野容器发动之前运转完结，而运用程序容器是并行运转的，所以Init容器能够供给了一种简略的阻塞或延迟运用容器的发动的方法。

Init容器与普通的容器非常像，除了以下两点：

  • Init容器总是运转到成功完结中止
  • 每个Init 容器都必须鄙人一个Init容器发动之前成功完结发动和退出

假如Pod 的Init容器失败，k8s 会不断地重启该Pod，直到Init层容器成功中止。然而，假如Pod对应的重启战略（restatolicy）为Never，它不会从头发动。

Init的容器效果

由于init容器具有与运用容器分离的独自镜像，其发动相关代码具有如下优势：

  • Init容器能够包括一些装置过程中运用容器中不存在的实用东西或个性化代码。例如，没有必要仅为了在装置过程中运用相似 sed、awk、python或dig这样的东西而去FROM一个镜像来生成一个新的镜像。
  • Init容器能够安全地运转这些东西，防止这些东西导致运用镜像的安全性降低。
  • 运用镜像的创立者和部署者能够各自独立作业，而没有必要联合构建一个独自的运用镜像。
  • Init容器能以不同于Pod内运用容器的文件系统视图运转。因而，Init容器可具有访问Secrets的权限，而运用容器不能够访问。
  • 由于Init容器必须在运用容器发动之前运转完结，因而 Init容器供给了一种机制来阻塞或延迟运用容器的发动，直到满意了一组先决条件。一旦前置条件满意，Pod内的一切的运用容器会并行发动。

运用容器（事务容器，Maincontainer）

供给事务服务，它是并行发动，要在一切init容器成功的完结发动、运转和退出后才会发动运用容器

K8S的pod基础

Pod镜像拉取战略（image PullPolicy）

Pod 的中心是运转容器，必须指定容器引擎，比方 Docker，发动容器时，需求拉取镜像，k8s 的镜像拉取战略能够由用户指定：

  1. IfNotPresent：在镜像现已存在的情况下，kubelet将不再去拉取镜像，仅当本地缺失时才从库房中拉取，默许的镜像拉取战略
  2. Always：每次创立 Pod都会从头拉取一次镜像
  3. Never：Pod 不会自动拉取这个镜像，仅运用本地镜像。

默许镜像拉取战略：

  • 对于标签为”:latest”的镜像文件，其默许的镜像获取战略即为”Always”；
    • 在没有指定标签的情况下，标签默许会是latest，如kubectl run XXX --image=nginx，所以其默许的镜像获取战略仍为”Always”
  • 而对于其他标签的镜像，其默许战略则为”IfNotPresent”。

官方示例：kubernetes.io/docs/concep…

例：

kubectl apply -f - <<EOF      #假如kubectl apply -f后边跟的不是文件，而是内容，那么-f后边一定要加一个 -
apiversion: v1
kind: Pod
metadata:
  name: private-image-test-1
spec:
  containers:
    - name: uses-private-image
      image: $PRIVATE_IMAGE_NAME
      imagePullPolicy: Always           #镜像拉取战略用的Always
      command: ["echo", "SUCCESS"]      #容器发动时，履行echo指令，完结后，容器就会退出
EOF

示例

生成一个nginx的yaml模板文件。

K8S的pod基础

IfNotPresent演示

  1. 修改模板文件，删掉不需求用的字段，再containers下一级添加imagePullPolicy字段，将战略设置为IfNotPresent

    K8S的pod基础

  2. 先保证两个node节点都有nginx:latest的镜像

    K8S的pod基础
    K8S的pod基础

  3. 履行yaml文件，创立pod

    K8S的pod基础
    K8S的pod基础
    K8S的pod基础
    K8S的pod基础
    K8S的pod基础

  4. 不运用yaml文件，直接kubectl run来创立pod，运用的是1.14版别（保证两个节点没有nginx1.14版别）

    K8S的pod基础
    K8S的pod基础
    K8S的pod基础
    K8S的pod基础
    K8S的pod基础

Always演示

  1. 删去之前创立的nginx-test1的pod，修改yaml文件中的镜像拉取战略为Always

    K8S的pod基础
    K8S的pod基础

  2. 此刻两个node节点存在nginx:latest的镜像，履行yaml文件创立pod

    K8S的pod基础

  3. 检查该pod的详细信息

    K8S的pod基础
    K8S的pod基础

Never演示

  1. 删去之前创立的nginx-test1的pod，修改yaml文件中的镜像拉取战略为Never，版别号改为1.14

    K8S的pod基础
    K8S的pod基础

  2. 此刻两个node节点都没有nginx:1.14的镜像（假如有，删去该镜像），履行yaml文件创立pod

    K8S的pod基础
    K8S的pod基础
    K8S的pod基础
    K8S的pod基础

  3. 删去创立的nginx-test1的pod，在两个node节点拉取nginx:1.14镜像，再次履行yaml文件

    K8S的pod基础
    K8S的pod基础
    K8S的pod基础
    K8S的pod基础

默许镜像拉取战略演示

  1. 基于nginx:1.14创立镜像

    K8S的pod基础
    K8S的pod基础

  2. 基于nginx:latest创立镜像

    K8S的pod基础
    K8S的pod基础

  3. 不指定标签

    K8S的pod基础
    K8S的pod基础

呈现ImagePullBackOff的原因

当kubelet运用容器运转时创立Pod时，容器或许由于ImagePullBackOff 导致状况为Waiting。

ImagePullBackoff状况意味着容器无法发动，由于Kubernetes无法拉取容器镜像（原因包括无效的镜像名称，或从私有库房拉取而没有 imagePullSecret）。Backoff 部分表明Kubernetes将继续测验拉取镜像，并添加回退延迟。

Kubernetes 会添加每次测验之间的延迟，直到达到编译限制，即300秒（5分钟）。

Pod容器重启战略

重启战略（restartPolicy）：当 Pod 中的容器退出时经过节点上的 kubelet重启容器。适用于 Pod 中的一切容器。

  • Always：当容器中止退出后，总是重启容器，默许战略
  • OnFailure：当容器反常退出（退出状况码非0）时，重启容器；正常退出则不重启容器
  • Never：当容器中止退出，从不重启容器。

回忆

docker容器重启战略：docker run --restart=no|always|on-failure[:n]|unless-stopped

never，默许战略，在容器退出时不重启容器。
on-failure，在容器非正常退出时(退出状况非0)，才会重启容器。
on-failure:3，在容器非正常退出时重启容器，最多重启3次。
always，在容器退出时总是重启容器。
unless-stopped，在容器退出时总是重启容器，可是不考虑在Docker看护进程发动时就现已中止了的容器。

示例

删去掉前面测验用的pod

K8S的pod基础

Always演示

  1. 修改yaml文件，重启战略（撤销注释）和拉取镜像战略都改成Always，而且加上履行指令

    K8S的pod基础

  2. 履行yaml文件

    K8S的pod基础
    K8S的pod基础
    K8S的pod基础

Never演示

  1. 删去前面测验用pod，重启战略改成Never

    K8S的pod基础

  2. 履行yaml文件

    K8S的pod基础
    K8S的pod基础

  3. 去往对应node节点检查，容器履行完操作就现已退出，但也没有再重启

    K8S的pod基础
    K8S的pod基础

OnFailure演示

  1. 删去前面测验用pod，重启战略改成OnFailure

    K8S的pod基础

  2. 履行yaml文件

    K8S的pod基础
    K8S的pod基础
    K8S的pod基础

  3. 去往对应node节点检查，容器履行完操作就现已退出，但也没有再重启。由于OnFailure在退出状况码为0（正常退出）时，不会重启

    K8S的pod基础

  4. 删去前面测验用pod，并修改操作

    K8S的pod基础

  5. 履行yaml文件

    K8S的pod基础
    K8S的pod基础

  6. 去往对应node节点检查，容器退出回来码为3，所以会进行重启

    K8S的pod基础
    K8S的pod基础

留意

  • K8S 中不支撑重启 Pod资源，只要删去重建
  • 在用yaml方法创立Deployment和StatefulSet类型时，restartPolicy只能是Always
  • kubectl run一个pod能够挑选Always, OnFailure, Never三种战略

示例

创立deployment资源的yaml文件进行测验

K8S的pod基础
K8S的pod基础
K8S的pod基础
K8S的pod基础
K8S的pod基础

总结

Pod 的定义：Pod是K8S 最小的创立和运转单元

1个Pod能包括几个必需容器?

  • 1个pause容器（根底容器/父容器/根容器）
  • 1个或许多个运用容器（事务）

一个运用容器最好只运转一个进程

同一个Pod里的容器，是运转在同一个Node节点上的，同享net、uts、ipc、mnt命名空间

pause容器的效果?

  • 给 Pod中的一切运用容器供给网络和存储资源的同享
  • 作为PID=1的进程（init进程）办理整个 Pod中的容器组的生命周期

Pod类型分2种

  • 自主式Pod（静态Pod）
    • 不被控制器办理的，没有自愈才能，即一旦Pod挂掉了，是不会被从头拉起；没有副本办理才能，即pod到副本数量不会由于达不到预期数目而创立新的pod；不支特活动升级；Pod资源信息保存在Node 上。一般用于测验运用
  • 控制器办理的Pod（动态Pod）
    • 被控制器办理的，有自愈才能，即一旦Pod挂掉了，会被从头拉起；有副本办理才能，即pod副本数量会由于达不到预期数目而创立新的pod；支撑活动升级；pod资源信息保存在etcd上。出产环境一般是运用控制器办理pod。

Pod中的容器类型分3种

  • pause容器（根底容器/父容器/根容器）：给容器组环境初始化
  • Init容器（初始化容器）：
    • 阻塞或延迟运用容器的发动；能够为运用容器事前供给好运转环境和实用东西
    • 有多个init容器时，是串行发动的，每个init容器都必须鄙人一个init容器发动前成功的完结发动、运转和退出
  • 运用容器（事务容器/main容器）：
    • 供给运用程序事务
    • 并行发动的，要在一切Init容器成功的完结发动、运转和退出后才会发动运用容器

Pod容器镜像拉取战略3种

imagePullPolicy字段方位在containers 下一个层级里

  • IfNotPresent：优先运用本地已存在的镜像，如本地没有则从库房中拉取镜像
  • Always：总是从库房拉取镜像，不管本地是否存在镜像
  • Never：仅运用本地镜像，并总是不从库房拉取镜像

默许镜像拉取战略：

  • 镜像的标签为latest或无标签时image: XXX:latest /XXX，默许的镜像拉取战略为Always
  • 镜像的标签为非latest时image: XXX:XXX，默许的镜像拉取战略为 IfNotPresent

Pod容器的重启战略3种

restartPolicy字段方位与containers 在同一层级

  • Always：当Pod中的容器退出时，总是重启容器，不管容器退出状况码如何。默许的重启战略
  • OnFailure：当Pod中的容器反常退出（容器退出状况码非0）时，会重启容器，正常退出（容器退出状况码为0）时不重启容器
  • Never：当Pod中的容器退出时，总是不重启容器，不管容器退出状况码如何

留意：

  • K8S 中不支撑重启 Pod资源，只要删去重建。
  • 在用yaml方法创立Deployment和Statefulset 类型时，restartPolicy 只能是Always，kubectl run创立 Pod能够挑选 Always，OnFailure，Never 三种战略

在k8s中指定容器发动时履行的指令

字段方位坐落containers 下一个层级里

command:["指令","参数"]             #横向
args:                              #纵向
-XXX
-XXX