1. 资源清单介绍

1.1. 资源清单格式

# 如果没有给定 group 名称，那么默认为core，可以使用 kubectl api -
apiVersion:  
# 获取当前k8s 版本上所有的apiVersion 版本信息（每个版本可能不同）
versions: 
# 资源类别
kind:
# 资源元数据
metadata:
  name:
  namespace:
  lables:
  annotations:  
# 期望的状态
spec: 
# 当前状态，本字段有 kubenetes 自身维护，用户不能去定义
status:

1.2. 常用命令

获取 apiversion 版本信息

 $ kubectl api-versions
 admissionregistration.k8s.io/v1beta1
 apiextensions.k8s.io/v1beta1
 apiregistration.k8s.io/v1
 apiregistration.k8s.io/v1beta1
 apps/v1
 apps/v1beta1
 apps/v1beta2
 ...

获取资源的 apiVersion 版本信息

 $ kubectl explain pod
 KIND:     Pod
 VERSION:  v1
	
 DESCRIPTION:
      Pod is a collection of containers that can run on a host. This resource is
      created by clients and scheduled onto hosts.
 ...
	
 $ kubectl explain Ingress
 KIND:     Ingress
 VERSION:  extensions/v1beta1
 ...
	

字段配置格式

字段	格式	说明
apiVersion	`<string>`	字符串
metadata	`<object>`	多层嵌套
labels	`<map[string]string>`	k:v 组成的映射
finalizers	`<[]string>`	字符串列表
ownerReferences	`<[]Object>`	对象列表
hostPID	`<boolean>`	布尔类型
priority	`<integer>`	整数
name	`<string> -required-`	如果类型后面接`-require-`,表示为必填字段

1.3. 通过定义清单文件创建Pod

apiVersion: v1
kind: Pod
metadata:
  name: pod-demo
  namespace: default
  labels:
    app: myapp
spec:
  containers:
    - name: myapp-1
      image: nginx
    - name: busybox-1
      image: busybox
      command:
        - "/bin/sh"
        - "-c"
        - "sleep 3600"

可以通过 kubectl get pod pod-demo -o yaml 或 kubectl get pod pod-demo -o json 方式将资源配置信息输出出来

2. Init 容器

Pod 可以包含多个容器，应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。

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

它们总是运行到完成。
每个都必须在下一个启动之前成功完成。

如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动。

指定容器为 Init 容器，需要在 Pod 的 spec 中添加 initContainers 字段，该字段內以Container 类型对象数组的形式组织，和应用的 containers 数组同级相邻。 Init 容器的状态在 status.initContainerStatuses 字段中以容器状态数组的格式返回（类似 status.containerStatuses 字段）。

示例:

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh','-c','echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox
    command: ['sh','-c','until nslookup myservice;do echo waiting for myservice;sleep 2;done;']
  - name: init-mydb
    image: busybox
    command:  ['sh','-c','until nslookup mydb;do echo waiting for myservice;sleep 2;done;']

---

apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

---
apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9377

3. 容器探针

探针是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的 Handler。有三种类型的处理程序：

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

每次探测都将获得以下三种结果之一：

成功：容器通过了诊断。
失败：容器未通过诊断。
未知：诊断失败，因此不会采取任何行动

Kubelet 可以选择是否执行在容器上运行的两种探针执行和做出反应：

livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为 Success。
readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。

生命时候使用容器探针？

如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活探针; kubelet 将根据 Pod 的restartPolicy 自动执行正确的操作。如果您希望容器在探测失败时被杀死并重新启动，那么请指定一个存活探针，并指定restartPolicy 为 Always 或 OnFailure。

如果要仅在探测成功时才开始向 Pod 发送流量，请指定就绪探针。在这种情况下，就绪探针可能与存活探针相同，但是 spec 中的就绪探针的存在意味着 Pod 将在没有接收到任何流量的情况下启动，并且只有在探针探测成功后才开始接收流量。

如果您希望容器能够自行维护，您可以指定一个就绪探针，该探针检查与存活探针不同的端点。

请注意，如果您只想在 Pod 被删除时能够排除请求，则不一定需要使用就绪探针；在删除 Pod 时，Pod 会自动将自身置于未完成状态，无论就绪探针是否存在。当等待 Pod 中的容器停止时，Pod 仍处于未完成状态。

示例：

livenessProbe

# 存活检测
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  containers:
    - name: myapp
      image: harbor.tansuotv.cn/library/nginx:v1
      imagePullPolicy: IfNotPresent
      command: ["/bin/sh","-c","touch /tmp/live;sleep 10;rm -rf /tmp/live;sleep 3600"]
      livenessProbe:
        exec:
          command: ["test","-e","/tmp/live"]
        initialDelaySeconds: 1
        periodSeconds: 3

readinessProbe

# 就绪检测
---
apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget-pod
  labels:
    app: myapp
spec:
  containers:
  - name: readiness-httpget-container
    image: harbor.tansuotv.cn/library/nginx:v1
    imagePullPolicy: IfNotPresent
    readinessProbe:
      httpGet:
        port: 80
        path: /index1.html
      initialDelaySeconds: 1
      periodSeconds: 3

4. 重启策略

PodSpec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never。默认为 Always。

restartPolicy 适用于 Pod 中的所有容器。restartPolicy 仅指通过同一节点上的 kubelet 重新启动容器。失败的容器由 kubelet 以五分钟为上限的指数退避延迟（10秒，20秒，40秒…）重新启动，并在成功执行十分钟后重置。如 Pod 文档中所述，一旦绑定到一个节点，Pod 将永远不会重新绑定到另一个节点。

4.1 状态示例

Pod 中只有一个容器并且正在运行。容器成功退出。
- 记录完成事件。
- 如果 restartPolicy 为：
- Always：重启容器；Pod phase 仍为 Running。
- OnFailure：Pod phase 变成 Succeeded。
- Never：Pod phase 变成 Succeeded。
Pod 中只有一个容器并且正在运行。容器退出失败。
- 记录失败事件。
- 如果 restartPolicy 为：
- Always：重启容器；Pod phase 仍为 Running。
- OnFailure：重启容器；Pod phase 仍为 Running。
- Never：Pod phase 变成 Failed。
Pod 中有两个容器并且正在运行。有一个容器退出失败。
- 记录失败事件。
- 如果 restartPolicy 为：
- Always：重启容器；Pod phase 仍为 Running。
- OnFailure：重启容器；Pod phase 仍为 Running。
- Never：不重启容器；Pod phase 仍为 Running。
- 如果有一个容器没有处于运行状态，并且两个容器退出：
- 记录失败事件。
- 如果 restartPolicy 为：
  - Always：重启容器；Pod phase 仍为 Running。
  - OnFailure：重启容器；Pod phase 仍为 Running。
  - Never：Pod phase 变成 Failed。
Pod 中只有一个容器并处于运行状态。容器运行时内存超出限制：
- 容器以失败状态终止。
- 记录 OOM 事件。
- 如果 restartPolicy 为：
- Always：重启容器；Pod phase 仍为 Running。
- OnFailure：重启容器；Pod phase 仍为 Running。
- Never: 记录失败事件；Pod phase 仍为 Failed。
Pod 正在运行，磁盘故障：
- 杀掉所有容器。
- 记录适当事件。
- Pod phase 变成 Failed。
- 如果使用控制器来运行，Pod 将在别处重建。
Pod 正在运行，其节点被分段。
- 节点控制器等待直到超时。
- 节点控制器将 Pod phase 设置为 Failed。
- 如果是用控制器来运行，Pod 将在别处重建。

Larry

k8s 笔记(三) 资源清单