Pod概念简介
从逻辑上看K8S将多个物理机资源抽象成一个整体,用于运行各类K8S资源。

Pod是K8S的核心资源之一,属于一种逻辑单元,也是K8S中最小的操作单元。一个Pod单元封装一个应用容器(也可以有多个容器),存储资源、一个独立的网络IP以及管理容器运行的策略。这样在外部看来一个Pod相当于一个虚拟机。

Kubernetes中的Pod使用可分两种主要方式

  1. Pod中运行一个容器。“one-container-per-Pod”模式是Kubernetes最常见的用法;在这种情况下,将Pod视为单个封装的容器,但Kubernetes是直接管理Pod而不是容器。
  2. Pods中运行多个需要一起工作的容器。Pod可以封装紧密耦合的应用容器,它们之间能够共享资源,这些容器可以形成一个单一的内部service单位;

每一个Pod下的都有一个基础容器pause容器,主要为每个业务容器提供以下功能:

  • PID命名空间:Pod中的不同应用程序可以看到其他应用程序的进程ID。
  • 网络命名空间:Pod中的多个容器能够访问同一个IP和端口范围。
  • IPC命名空间:Pod中的多个容器使用SystemV IPC或POSIX消息队列进行通信。
  • UTS命名空间:Pod中的多个容器共享一个主机名;
  • Volumes(共享存储卷):Pod中的各个容器可以访问在Pod级别定义的Volumes。

Pod有元数据以供master进行管理,master主要通过Pod的label进行唯一标识。Pod资源Label格式:key=value是其中一项元数据,使用Label Selector组件根据Label选择Pod资源

Pod存在生命周期,一旦Pod出现问题,controller控制器能指挥Pod重启或者重建

Pod资源的生命周期
周期中的所有状态:pending,running,failed,successed,unknown
生命周期中的行为,如下图
在这里插入图片描述
在主容器启动前,所有的初始化操作是串行完成的。

容器启动之后,对容器有两类探测:

  1. 存活性探测liveness prode,指示容器是否正在运行。如果存活探测失败,则 kubelet 会杀死容器,并且容器将受到其restartpolicy的影响。如果容器不提供存活探针,则默认状态为 Success。
  2. 就绪性探测readinessprode,指示容器是否准备好服务请求。如果就绪探测失败,Endpoint控制器将从与 Pod 匹配的所有 Service 的Endpoint中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针,则默认状态为 Success。

两类探测的三种实现方式:

  1. ExecAction:在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
  2. TCPSocketAction:对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开,则诊断被认为是成功的。
  3. HTTPGetAction:对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于400,则诊断被认为是成功的。

pod的创建过程
Pod是Kubernetes的基础单元,了解其创建的过程,更有助于理解系统的运作。

①用户通过kubectl或其他API客户端提交Pod Spec给API Server。

②API Server尝试将Pod对象的相关信息存储到etcd中,等待写入操作完成,API Server返回确认信息到客户端。

③API Server开始反映etcd中的状态变化。

④所有的Kubernetes组件通过"watch"机制跟踪检查API Server上的相关信息变动。

⑤kube-scheduler(调度器)通过其"watcher"检测到API Server创建了新的Pod对象但是没有绑定到任何工作节点。

⑥kube-scheduler为Pod对象挑选一个工作节点并将结果信息更新到API Server。

⑦调度结果新消息由API Server更新到etcd,并且API Server也开始反馈该Pod对象的调度结果。

⑧Pod被调度到目标工作节点上的kubelet尝试在当前节点上调用docker engine进行启动容器,并将容器的状态结果返回到API Server。

⑨API Server将Pod信息存储到etcd系统中。

⑩在etcd确认写入操作完成,API Server将确认信息发送到相关的kubelet。

Pod资源的定义

可通过yaml文件具体定义一个Pod实例,然后以此文件创立该Pod实例
常用的一层定义
apiVersion:标记资源版本 格式group/version 使用命令kebectl api-version查看
kind:标记资源类别
metadata:元数据
spec:用户定义的期望状态(通过kubectl explain pod.spec 获取更详细)
常用的二层定义
nodeName:定义在指定的node节点上运行此Pod在这里插入图片描述
nodeSelector:定义对node的选择策略,选择符合策略要求的node节点运行此Pod
在这里插入图片描述
restartPolicy:定义容器的重启策略

  • Always : 容器失效时,kubelet 自动重启该容器;
  • OnFailure : 容器终止运行且退出码不为0时重启;
  • Never :不论状态为何, kubelet 都不重启该容器。

常用的三层定义
spec.containers <[]object> 说明spec.container的值为队列类型对象

name 定义容器的名字
image 定义容器使用的镜像,若节点没有会从仓库拉取
imagePullPolicy

  • 镜像拉取的策略,可用的值为Always,Never,IfNotPresent。
    Always表示总是从仓库中拉取镜像,不关本地有无镜像
    Never表示一直使用本地的镜像,本地没有镜像则等待本地导入
    IfNotPresent表示本地有镜像则使用,没有则去仓库中拉取
    只要容器标签为latest则默认使用Always,可以改使用IfNotPresent
    此字段一旦创建无法更新

ports 仅提供容器暴露的端口信息,并不能决定容器暴露什么端口,端口暴露由镜像决定。

command 提供的命令不会在shell中执行;如果需要执行shell命令 则使用/bin/bash ;
如果没有指定command,则使用容器镜像中的ENTRYPOINT。

args 提供命令参数,如果没有指定args,则使用容器镜像中的CMD
在这里插入图片描述

Pod实例操作
exec探测的测试
存活和就绪的探测方式基本接近
ngx-liveness-exec.yaml文件内容如下

apiVersion: v1
kind: Pod
metadata:
   name: liveness-exec-pod
   namespace: default
   labels:
     app: liveness-exec
     tier: frontend
spec:
   containers:
   - name: liveness-exec
     image: 192.168.80.146:5000/busybox:latest
     command: ["/bin/sh","-c","touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 60"]
     livenessProbe:
       exec: ##探测命令
          command: ["test","-e", "/tmp/healthy"] ##判断/tmp/healthy文件是否还存在
       initialDelaySeconds: 1 ##容器初始化完成后迟延1秒再开始存活探测
       periodSeconds: 3  ##每次探测间隔3秒

1、以此文件生成一个pod并观察pod状态

[root@k8s-master k8s-yaml]# kubectl create -f ngx-liveness-exec.yaml 
pod/liveness-exec-pod created
[root@k8s-master k8s-yaml]# kubectl get pods -w
NAME                READY     STATUS              RESTARTS   AGE
liveness-exec-pod   0/1       ContainerCreating   0          4s
liveness-exec-pod   1/1       Running   0         11s

2、running前30秒进入pod的容器进行,存在/tmp/healty文件

[root@k8s-node2 ~]# docker exec -it 94d25d20fc85 /bin/sh
/ # ls /tmp/
healthy

3、30秒后容器删除该文件,但不关闭容器,但liveness探测到该文件不存在,就依据restartPolicy完成重启,观察RESTARTS可以确定重启次数

[root@k8s-master k8s-yaml]# kubectl get pods -w                      
NAME                READY     STATUS    RESTARTS   AGE
liveness-exec-pod   1/1       Running   2          3m
liveness-exec-pod   1/1       Running   3         3m

httpget探测的测试
ngx-liveness-httpget.yaml文件内容如下

apiVersion: v1
kind: Pod
metadata:
   name: liveness-httpget-pod
   namespace: default
   labels:
     app: liveness-httpget
     tier: frontend
spec:
   nodeName: k8s-node2
   containers:
   - name: liveness-httpget
     image: 192.168.80.146:5000/my_ngx:v1
     ports:
     - name: http
       containerPort: 80
     livenessProbe:
       httpGet:
          port: http
          path: /index.html
       initialDelaySeconds: 1
       periodSeconds: 3

1、以此文件生成一个pod并观察pod状态

[root@k8s-master k8s-yaml]# kubectl create -f ngx-liveness-httpget.yaml 
pod/liveness-httpget-pod created
[root@k8s-master k8s-yaml]# kubectl get pods -w
NAME                READY     STATUS              RESTARTS   AGE
liveness-httpget-pod   0/1       ContainerCreating   0          4s
liveness-httpget-pod   1/1       Running   0         12s

2、进入pod的容器删除 /usr/share/nginx/html/index.html文件,即ngx的默认index文件

[root@k8s-node2 ~]# docker exec -it 34bf577f8920 /bin/sh
/ # rm -f /usr/share/nginx/html/index.html

3、liveness探测到httpget失败,就依据restartPolicy完成重启,观察RESTARTS可以确定重启次数

[root@k8s-master k8s-yaml]# kubectl get pods -w                      
NAME                READY     STATUS    RESTARTS   AGE
liveness-httpget-pod   1/1       Running   2          3m
Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐