他@

Kubernetes Pod入门

在 Kubernetes 中，一个重要的概念就是 Pod(豆英)，Kubernetes 并不是直接管理容器的，他的最小管理单元叫做 Pod。

一、什么是 Pod。

Pod 是一个或多个容器的组合。这些容器共享存储、网络和命名空间，以及运行规范。在 Pod中，所有容器都被统一安排和调度，并运行在共享的上下文中。对于具体应用而言，Pod 是它们的逻辑主机，Pod 包含业务相关的多个应用容器。所以，Pod 是一组具有共享命名空间、IP 地址和端口的容器的集合。

备注:

共享上下文是一种基于线程的内存位置

1:从使用的角度来看

在实际的使用时，单个容器是无法单独来支撑我们的应用的，往往需要很多微服务才能组成一个系统，并且还会存在A服务依赖B服务，B服务需要和C服务共用某个目录。另外，在使用裸容器时,很难实现对容器内进行健康检査以及横向扩容等操作,而 Pod 可以轻松解决这些问题。

2:从 Kubernetes 的角度来看

Docker 只是容器 Runtime(运行时)的一种们还有很多容器 Runtime，比如 Rkt、CRI-0等，而 Kubernetes 作为目前最流行的容器编排工具，需要支持各个 Runtime 并且不依赖于底层Runtime 的实现技术,于是就抽象出了 Pod 这个概念,用于管理多个紧密相连的符合 CRI 标准的容器。

Pod 可以简单的理解为一组、一个或多个容器，每个 Pod 还包含一个 Pause 容器，Pause 容器是 Pod 的父容器，主要负责僵尸进程的回收管理。同时，通过 Pause 容器可以使同一个 Pod里面的不同容器共享存储、网络、PID、IPC 等，容器之间可以使用 Localhost:Port 的方式相瓦访问，可以使用 volume 实现数据共享。根据 Docker 的构造，Pod 可以被创建为一组具有共享命名空卷、IP 地址和端口的容器。

Pod 有两个必须知道的特点:

网络:每一个 Pod 都会被指派一个唯一的 Ip 地址，在 Pod 中的每一个容器共享网络命名空间，包括 Ip 地址和网络端口。在同一个 Pod 中的容器可以同 1ocahost 进行互相通信。当 Pod中的容器需要与 Pod 外的实体进行通信时，则需要通过端口等共享的网络资源。
存储:Pod 能够被指定共享存储卷的集合，在Pod中所有的容器能够访问共享存储卷，允许这些容器共享数据。存储卷也允许在一个 Pod 持久化数据，以防止其中的容器需要被重启。

3:Pod 的状态

(1)kubectl 命令创建 pod

kubectl run nginx--image=nginx:1.7.9 --labels="app=nginx"

(2)查看 pod

kubectlget pods -n default

NAME READY STATUS RESTARTS AGE

nginx 1/1 Running 0 78s

(3)显示 Pod的更多信息

kubectl get pod nginx -o wide

NAME READY STATUS RESTARTS AGE Ip NODE NOMINATED NODE READINESS GATES

nginx 1/1 Running 0 54s 10.244.58.195 k8s-node02

(4)查看 pod日志

curl 10.244.58.195

kubectl logs nginx

(5)以yaml格式显示 Pod 详细信息

kubectl get pod nginx -o yaml

(6)显示资源的详细描述信息

kubectl describe pod nginx

备注:

kubectl get:常用于査看同一资源类型的一个或多个资源对象，可以使用-0 参数自定义输出格式。
kubectl describe:侧重于描述指定资源的各方面的详细信息，不仅会返回节点信息，还会返回在其上运行的 Pod 的摘要、节点事件等信息。

(7)在 Pod 的容器中执行命令

kubectl exec nginxc nginx-- date

备注：

-c:指定 Pod 中容器的名字

(8)登录到 Pod 中的容器中

kubectl exec -it nginx-c nginx -- bash

备注:

kubectl exec -it nginx --bash

如果登录的时候不指定容器，就登录到 Pod 中的第一个容器中。

(9)在线编辑运行中的资源对象

kubectl edit pod nginx

(10)将 pod 的端口映射到宿主机

kubectl port-forward --address 0.0.0.0 pod/nginx 8080:80

Forwarding from 0.0.0.0:8080->80

其他主机访问测试:

curl 192.168.10.101:8080

注意:

此命令会在前台运行,此时就可以在其他客户端用该 k8s 主机的 IP 地址和 8080 的端口号进行访问了，Ctr1+c停止，但停止后就没有这个映射了。

(11)在宿主机和 Pod 的容器之间拷贝文件

kubectl cp nginx:etc/fstab /opt/aaa.txt

kubectl cp /opt/aaa.txt nginx:etc/bbb.txt

(12)Pod 的状态

kubectl get pods -n default

NAME READY STATUS RESTARTS AGE

nginx 1/1 Running 0 29m

可以看到此时的 Pod 的状态是 Running，Pod 的状态不仅仅只有 Running，常见的其他状态如表所示：

状态

说明

Pending(挂起)

Pod 已经被 Kubernetes 系统接收，但是仍有一个或多个容器未被创建，可以通过 kubectl describe 查看处于Pending 状态的原因。

Running(运行中)

Pod 已经被绑定到一个节点上，并且所有的容器都已经被创建，而且至少有一个是运行的状态、正在启动或者重启，可以通过 kubectl logs 查看 Pod 的日志。

Succeeded

所有容器执行成功，并终止，并且不会再次重启，可以通过kubectl logs 査看 Pod 的日志

Failed(失败)

所有容器都已终止，并且至少一个容器以失败的方式终止，也就是说这个容器要么以非零状态退出，要么被系统终止，可以通过 logs 和 describe 査看 Pod 的日志和状态

Unknown(未知)

通常是由于通信问题造成的无法获得 Pod 的状态

ImagePullBackOff

ErrImagePull

镜像拉取失败，一般是由于镜像不存在、网络不通或者需要登录认证引起的，可以使用 describe 命令查看具体的原因

CrashLoopBackoff

容器启动失败，可以通过 logs 命令查看具体的原因，一般为启动命令不正确、健康检査不通过等原因

OOMKilled

容器内存溢出，一般是容器的内存 Limit 设置的过小，或者程序本身有内存溢出，可以通过 logs 查看程序的启动日志

Terminating

Pod 正在被删除，可以通过 describe 查看状态

SysctlForbiden

Pod 自定义了内核配置，但 kubect1 没有添加内核配置或配置的内核参数不支持，可以通过 describe 查看具体原因

Completed

容器内部主进程退出，一般计划任务执行结束会显示该该状态，此时可以通过 logs 查看容器日志

ContainerCreating

Pod 正在创建,一般正在下载镜像,或者有配置不当的地方可以通过 describe 查看具体原因

(13)删除 Pod

kubectl delete pod nginx

二、Pod 探针

在生产环境中，进程正常启动并不代表应用能正常处理请求，所以合理的设计应用的健康检查尤其重要。在使用裸机或裸容器部署时，一般很难对应用做很完善的健康检査，而 Pod 提供的探针可以很方便的用来检测容器的应用是否正常。目前探针有3种检测方式，可以根据不同的场景选择合适的健康检查方式。检查方式如表所示：

上述的检查方式可以被周期性的执行，每次检查容器后可能得到的容器状态如表所示：

Pod 探针有三类，分别是:livenessProbe(存活探针)、readinessProbe(就绪探针)、startupProbe(启动探针)。

livenessProbe (存活探针):判断容器是否正常运行，如果失败则杀掉容器(不是 pod),再根据重启策略决定是否重启容器
readinessProbe(就绪探针):判断容器是否能够进入ready 状态，探针失败则进入noready 状态，并从service 的endpoints 中剔除此容器
startupProbe(启动探针): 判断容器内的应用是否启动成功，在 success 状态前，其它探针都处于无效状态

三、Pod 镜像拉取策略和重启策略

在发布应用或者更改控制器配置时，会触发Pod 的滚动更新，此时针对容器的镜像有不同的拉取方式。如表所示：

指定拉取策略:

kubectl run nginx --image=nginx:1.7.9 --labels="app=nginx" --image-pull-policy=Never

Pod 进行部署或者运行时，难免会出现故障，对于故障。，Pod也有不同的处理方式，如表所示：

指定重启策略:

kubectl delete pod nginx

kubectl run nginx --image=nginx:1.7.9 --labels="app=nginx" --restart=OnFailure

四、创建一个简单的 Pod

1:编写一个简单的 Pod

vim nginx-pod.yaml

apiVersion: v1

kind: Pod

metadata:

  name: nginx

  labels:

    name: nginx

spec:

  containers:

  - name: nginx

    image: nginx:1.7.9

    ports:

    - containerPort: 80

2:编写 Pod 配置文件 frontend-localredis-pod.yaml

cat <frontend-localredis-pod.yam1

apiVersion: v1

kind: Pod

metadata:

  name: redis-php

  labels:

     name: redis-php

spec:

  containers:

  - name: frontend

     image: kubeguide/guestbook-php-frontend:localredis

     imagePullPolicy: IfNotPresent

     livenessProbe:

       tcpSocket:

       port: 80

     initialDelaySeconds: 1

     periodSeconds: 3

     timeoutSeconds: 1

   ports:

   - containerPort: 80

- name: redis

   image: kubeguide/redis-master

   imagePullPolicy: IfNotPresent

   ports:

   - containerPort: 6379

  restartPolicy: OnFailure

EOF

备注：

##必选，版本号apiVersion:v1

kind: Pod##必选，资源类型

metadata:##必选，元数据

name: redis-php##必选，Pod 名称

labels :##自定义的 pod 标签列表

##标签值name:redis-php

##必选，Pod 中容器的详细信息spec:

##必选，Pod 中的容器列表containers:

##必选，自定义的容器名称- name:frontend

image:kubeguide/guestbook-php-frontend:localredis##必选，容器的镜像名称

imagePullPolicy:IfNotPresent##镜像拉取策略

设置存活探针livenessProbe:

tcpsocket:##测试某端口是否可以连接

##指定要测试的端口port:80

initialDelaySeconds:1 #指定 kubelet 在执行第一次探测前应该等待1秒，即第一次探测是在容器启动后的第2秒才开始执行。默认是0秒，最小值是0

periodseconds:3#指定了 kubelet 应该每 3 秒执行一次存活探测。默认是 10 秒。最小值是 1

timeoutSeconds:1##当探测失败时，Kubernetes 将在放弃之前重试的次数。存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃Pod 会被打上未就绪的标签。默认值是 3。最小值是 1

##需要暴露的端口号列表ports:

##容器需要监听的端口号-containerPort:80

name:redis##另一个容器的名字

image:kubeguide/redis-master##另一个容器的镜像

##需要暴露的另一个容器的端口列表ports:

containerPort:6379##容器需要监听的端口号

##重启策略restartPolicy:onFailure

3:Pod 文件语法

(1)Pod 文件的一级属性
一级属性主要包含5部分:

apiVersion版本，由 kubernetes 内部定义，版本号必须可以用 kubectlapi-versions 查询到
kind类型，由 kubernetes 内部定义，版本号必须可以用 kubect1api-resources 查询到
metadata