k8s容器中无法ping Service名称 k8s容器状态

目录

• 1 Pod 特点

• 1.1 网络
• 1.2 存储

• 2 使用方式

• 2.1 自主式Pod
• 2.2 控制器管理的Pod

• 3 自主运行Pod

• 3.1 创建资源清单

• 3.1.1 参数描述

• 3.2 创建Pod
• 3.3 Pod操作

• 3.3.1 查看Pod列表
• 3.3.2 查看描述信息
• 3.3.3 访问pod
• 3.3.4 删除Pod

• 4 控制器运行Pod

• 4.1 创建资源清单
• 4.2 参数描述

• 4.2.1 Replicas
• 4.2.2 Selector
• 4.2.3 Pod Template

• 4.3 创建Pod
• 4.4 Pod操作

• 4.4.1 删除Pod

• 5 镜像拉取策略

• 5.1 always

• 5.1.1 修改资源清单
• 5.1.2 生效配置
• 5.1.3 查看创建过程

• 5.2 IfNotPresent

• 5.2.1 修改资源清单
• 5.2.2 生效配置
• 5.2.3 查看创建过程

• 6 Pod生命周期

• 6.1 各个阶段
• 6.2 Pod重启策略
• 6.3 Pod状态转换
• 6.4 生命周期行为

• 6.4.1 初始化容器
• 6.4.2 容器探测

---

1 Pod 特点

Pod是kubernetes中你可以创建和部署的最小也是最简的单位，一个Pod代表着集群中运行的一个进程。

Pod中封装着应用的容器（有的情况下是好几个容器），存储、独立的网络IP，管理容器如何运行的策略选项，Pod代表着部署的一个单位：kubernetes中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。

Pod有两个必须知道的特点

1.1 网络

每一个Pod都会被指派一个唯一的Ip地址，在Pod中的每一个容器共享网络命名空间，包括Ip地址和网络端口，在同一个Pod中的容器可以同locahost进行互相通信，当Pod中的容器需要与Pod外的实体进行通信时，则需要通过端口等共享的网络资源。

1.2 存储

Pod能够配置共享存储卷，在Pod中所有的容器能够访问共享存储卷，允许这些容器共享数据，存储卷也允许在一个Pod持久化数据，以防止其中的容器需要被重启。

2 使用方式

2.1 自主式Pod

这种Pod本身是不能自我修复的，当Pod被创建后（不论是由你直接创建还是被其他Controller），都会被Kuberentes调度到集群的Node上，直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上，Pod不会自愈。

	如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除，同样的，如果Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱逐。

2.2 控制器管理的Pod

Kubernetes使用更高级的称为Controller的抽象层，来管理Pod实例，Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。

	例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。虽然可以直接使用Pod，但是在Kubernetes中通常是使用Controller来管理Pod的

3 自主运行Pod

3.1 创建资源清单

通过yaml文件或者json描述Pod和其内容器的运行环境和期望状态，例如一个最简单的运行nginx应用的pod，定义如下

vi nginx-pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.12
    ports:
    - containerPort: 80

3.1.1 参数描述

下面简要分析一下上面的Pod定义文件：

• apiVersion： 使用哪个版本的Kubernetes API来创建此对象
• kind：要创建的对象类型，例如Pod，Deployment等
• metadata：用于唯一区分对象的元数据，包括：name，UID和namespace
• labels：是一个个的key/value对，定义这样的label到Pod后，其他控制器对象可以通过这样的label来定位到此Pod，从而对Pod进行管理。（参见Deployment等控制器对象）
• spec： 其它描述信息，包含Pod中运行的容器，容器中运行的应用等等。不同类型的对象拥有不同的spec定义。详情参见API文档

3.2 创建Pod

使用kubectl创建pod

kubectl apply -f nginx-pod.yml

3.3 Pod操作

3.3.1 查看Pod列表

kubectl get pods

可以通过增加 -o wide查看详细信息

kubectl get pods -o wide

3.3.2 查看描述信息

可以通过describe查看pod的详细信息

kubectl describe pod nginx

3.3.3 访问pod

可以通过k8s创建的虚拟IP进行访问，可以在k8s的任何一个节点访问

curl 10.244.1.10

3.3.4 删除Pod

可以使用delete删除Pod，删除后不能进行恢复

kubectl delete pod nginx

4 控制器运行Pod

Pod本身不具备容错性，这意味着如果Pod运行的Node宕机了，那么该Pod无法恢复，因此推荐使用Deployment等控制器来创建Pod并管理。

4.1 创建资源清单

通过yaml文件或者json描述Pod和其内容器的运行环境和期望状态，例如一个最简单的运行nginx应用的pod，定义如下

vi nginx-pod.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
        app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.12
        ports:
        - containerPort: 80

4.2 参数描述

下面简要分析一下上面的Pod定义文件：

4.2.1 Replicas

副本数量

spec.replicas 是可以选字段，指定期望的pod数量，默认是1。

4.2.2 Selector

标签选择器

.spec.selector是可选字段，用来指定 label selector ，圈定Deployment管理的pod范围。如果被指定， .spec.selector 必须匹配 .spec.template.metadata.labels，否则它将被API拒绝。如果 .spec.selector 没有被指定， .spec.selector.matchLabels 默认是.spec.template.metadata.labels。

	在Pod的template跟.spec.template不同或者数量超过了.spec.replicas规定的数量的情况下，Deployment会杀掉label跟selector不同的Pod。

4.2.3 Pod Template

Pod模板，.spec.template 是 .spec中唯一要求的字段。

.spec.template 是 pod template，它跟 Pod有一模一样的schema，除了它是嵌套的并且不需要apiVersion 和 kind字段。

	另外为了划分Pod的范围，Deployment中的pod template必须指定适当的label（不要跟其他controller重复了，参考selector）和适当的重启策略。

	.spec.template.spec.restartPolicy 可以设置为 Always , 如果不指定的话这就是默认配置。

4.3 创建Pod

kubectl apply -f nginx-pod.yml

kubectl get pods -o wide

创建后发现，有两个nginx的pod在运行，符合我们的预期

4.4 Pod操作

4.4.1 删除Pod

这里可以尝试删除Pod

kubectl delete pod nginx-deployment-f77774fc5-cgs82
# 查看Pod详情
kubectl get pods -o wide

删除Pod后发现重新新建了一个Pod，这是因为有控制器发现少了一个Pod就会进行重新拉起来一个

5 镜像拉取策略

pod的镜像拉取策略分为三种：

• always（总是从官方下载镜像）
• never（从不下载镜像）
• ifnotpresent（如果本地没有镜像就从官方下载镜像）。

Kubernetes集群默认使用IfNotPresent策略

5.1 always

不管是否存在本地镜像，总是从远程仓库下载

5.1.1 修改资源清单

我们可以通过修改配置清单来配置不同的策略

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
        app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.12
        imagePullPolicy: Always
        ports:
        - containerPort: 80

5.1.2 生效配置

kubectl apply -f nginx-pod.yml

5.1.3 查看创建过程

kubectl describe pod nginx-deployment

可以清楚的看到重新下载而没有使用本地镜像

5.2 IfNotPresent

Kubernetes集群的默认策略，如果有本地镜像就使用，没有则从远程仓库下载

5.2.1 修改资源清单

我们可以通过修改配置清单来配置不同的策略

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
        app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.12
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

5.2.2 生效配置

kubectl apply -f nginx-pod.yml

5.2.3 查看创建过程

kubectl describe pod nginx-deployment

可以清楚的看到没有重新下载镜像而是使用本地的镜像。

6 Pod生命周期

6.1 各个阶段

POD中明确规定了如下几个阶段

状态值	说明
挂起（Pending）	Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建，等待时间包括调度 Pod 的时间和通过网络下载镜像的时间。
运行中（Running）	该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。
成功（Succeeded）	Pod 中的所有容器都被成功终止，并且不会再重启。
失败（Failed）	Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。
未知（Unknown）	因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。

实际上还有一中状态Terminating，在代码和文档中都没有说明，但却是存在。这种情况出现杂无法获取所在主机的资源情况，一直在尝试建立连接。

6.2 Pod重启策略

在Pod中的容器可能会由于异常等原因导致其终止退出，Kubernetes提供了重启策略以重启容器。

Pod通过`restartPolicy`字段指定重启策略，重启策略类型为：Always、OnFailure 和 Never，默认为 Always。

	重启策略对同一个Pod的所有容器起作用，容器的重启由Node上的kubelet执行。Pod支持三种重启策略，在配置文件中通过`restartPolicy`字段设置重启策略：

重启策略	说明
Always	当容器失效时，由kubelet自动重启该容器
OnFailure	当容器终止运行且退出码不为0时，由kubelet自动重启该容器
Never	不论容器运行状态如何，kubelet都不会重启该容器

注意：这里的重启是指在Pod的宿主Node上进行本地重启，而不是调度到其它Node上。

6.3 Pod状态转换

Pod的容器数	Pod当前状态	发生的事件	Pod结果状态
			RestartPolicy=Always	RestartPolicy=OnFailure	RestartPolicy=Never
包含一个容器	Running	容器成功退出	Running	Succeeded	Succeeded
包含一个容器	Running	容器失败退出	Running	Running	Failure
包含两个容器	Running	1个容器失败退出	Running	Running	Running
包含两个容器	Running	容器被OOM杀掉	Running	Running	Failure

6.4 生命周期行为

6.4.1 初始化容器

初始化容器（init container）即应用程序的主容器启动之前要运行的容器，常用于为主容器执行一些预置操作，它们具有两种典型特征。

1. 初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么kubernetes需要重启它直到成功完成。（注意：如果pod的spec.restartPolicy字段值为“Never”，那么运行失败的初始化容器不会被重启。）
2. 每个初始化容器都必须按定义的顺序串行运行。

6.4.2 容器探测

容器探测（container probe）是Pod对象生命周期中的一项重要的日常任务，它是kubelet对容器周期性执行的健康状态诊断，诊断操作由容器的处理器（handler）进行定义，Kubernetes支持三种处理器用于Pod探测：

• ExecAction：在容器内执行指定命令，并根据其返回的状态码进行诊断的操作称为Exec探测，状态码为0表示成功，否则即为不健康状态。
• TCPSocketAction：通过与容器的某TCP端口尝试建立连接进行诊断，端口能够成功打开即为正常，否则为不健康状态。
• HTTPGetAction：通过向容器IP地址的某指定端口的指定path发起HTTP GET请求进行诊断，响应码为2xx或3xx时即为成功，否则为失败。

任何一种探测方式都可能存在三种结果：“Success”（成功）、“Failure”（失败）、“Unknown”（未知），只有success表示成功通过检测。