【Linux39-2】pod、资源清单的书写、pod生命周期（探针）、init初始化容器、控制器（Deployment、ReplicaSet、DaemonSet、Job、Cronjob）

0官网

kubectl命令官网详解

pod官网文档

Deployment官网文档

实验环境：
master端：server2：192.168.17.2
node端：server3：192.168.17.3
harbor仓库：server1：192.168.17.1

1. pod与控制器

• pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元
• Pod （就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个） 容器； 这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。 Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器， 这些容器是相对紧密的耦合在一起的。 在非云环境中，在相同的物理机或虚拟机上运行的应用类似于在同一逻辑主机上运行的云应用。
• 就 Docker 概念的术语而言，Pod 类似于共享名字空间和文件系统卷的一组 Docker 容器。
• 每个 Pod 都旨在运行给定应用程序的单个实例。如果希望横向扩展应用程序（例如，运行多个实例 以提供更多的资源），则应该使用多个 Pod，每个实例使用一个 Pod。 在 Kubernetes 中，这通常被称为 副本（Replication）。 通常使用一种工作负载资源及其控制器 来创建和管理一组 Pod 副本。

1.1 创建与删除pod

集群内部可以访问，外部无法直接访问

• 创建pod：

kubectl run nginx --image=myapp:v1

• 删除pod：

kubectl delete pod nginx

1.2 Deployment控制器管理pod

• 创建

kubectl create deployment nginx --image=myapp:v1

用pod命令删除后会又自动创建一个新的
kubectl delete pod nginx-67f9d9c97f-zk7z5 

• 彻底删除

kubectl delete deployments nginx

1.3 扩容与缩容

--replicas：在deployment控制器的基础上

kubectl scale deployment --replicas=2 nginx 

1.4 创建service并外部访问

1)ClusterIP：默认类型，自动分配一个仅集群内部可以访问的虚拟IP

kubectl expose deployment nginx --port=80

2)NodePort 暴露端口：外部客户端访问（可以通过NodeIP：NodePort来访问）

• 修改类型为NodePort

kubectl edit svc nginx （修改  type: NodePort）

• 创建时指定类型为NodePort：

kubectl expose deployment nginx --port=80 --type=NodePort

1.5 更新与回滚

更新pod镜像

kubectl set image deployment nginx myapp=myapp:v2

回滚

1.查看历史版本
kubectl rollout history deployment nginx
2.回滚
kubectl rollout undo deployment nginx --to-revision=1

2. 资源清单

kubectl api-versions ：查询命令
kubectl explain pod 查询帮助文档

• apiVersion：group/version 指明api资源属于哪个群组和版本，同一个组可以有多个版本
• kind：标记创建的资源类型
• metadata：元数据
  • name：对象名称，
  • namespace：对象所属的命名空间，
  • labels：指定资源标签（键值数据）
• spec：定义目标资源的期望状态
  
  

简单pod示例

kubectl apply -f pod.yml #创建
kubectl delete -f pod.yml #删除

#pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: default
spec:
  containers:
  - name: nginx
    image: myapp:v1
    imagePullPolicy: IfNotPresent

Deployment控制器示例

kubectl apply -f deployment.yml #创建
kubectl delete -f deployment.yml #删除

#deployment.yml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      #nodeSelector:
      #  kubernetes.io/hostname: server3
      #nodeName: server3
      #hostNetwork: true
      containers:
      - name: nginx
        image: myapp:v1
        imagePullPolicy: IfNotPresent
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
          limits:
            cpu: 0.5
            memory: 512Mi

标签

查看标签
kubectl get pod --show-labels
过滤标签（-l 或 -L）
[root@server2 ~]# kubectl get pod -L nginx
[root@server2 ~]# kubectl get pod -L run
打标签
kubectl label pod demo version=v1
更改标签
kubectl label pod demo app=nginx --overwrite

3. pod生命周期

pod生命周期官方文档

3.1 pod阶段

• Pod 的 status 字段是一个 PodStatus 对象，其中包含一个 phase 字段。
• Pod 的阶段（Phase）是 Pod 在其生命周期中所处位置的简单宏观概述。 该阶段并不是对容器或 Pod 状态的综合汇总，也不是为了成为完整的状态机。
  
  

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

3.2 容器状态

Waiting （等待）

如果容器并不处在 Running 或 Terminated 状态之一，它就处在 Waiting 状态。 处于 Waiting 状态的容器仍在运行它完成启动所需要的操作：例如，从某个容器镜像 仓库拉取容器镜像，或者向容器应用 Secret 数据等等。 当你使用 kubectl 来查询包含 Waiting 状态的容器的 Pod 时，你也会看到一个 Reason 字段，其中给出了容器处于等待状态的原因。

Running（运行中）

Running 状态表明容器正在执行状态并且没有问题发生。 如果配置了 postStart 回调，那么该回调已经执行且已完成。 如果你使用 kubectl 来查询包含 Running 状态的容器的 Pod 时，你也会看到 关于容器进入 Running 状态的信息。

Terminated（已终止）

处于 Terminated 状态的容器已经开始执行并且或者正常结束或者因为某些原因失败。 如果你使用 kubectl 来查询包含 Terminated 状态的容器的 Pod 时，你会看到 容器进入此状态的原因、退出代码以及容器执行期间的起止时间。

如果容器配置了 preStop 回调，则该回调会在容器进入 Terminated 状态之前执行。

3.3 容器探针

三种探针：

• livenessProbe：指示容器是否正在运行。如果存活态探测失败，则 kubelet 会杀死容器， 并且容器将根据其重启策略决定未来。如果容器不提供存活探针， 则默认状态为 Success(成功)。

• readinessProbe：指示容器是否准备好为请求提供服务。如果就绪态探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始延迟之前的就绪态的状态值默认为 Failure。 如果容器不提供就绪态探针，则默认状态为 Success。

• startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被 禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依其重启策略进行重启。 如果容器没有提供启动探测，则默认状态为 Success。
  
  

示例1

#live.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: busyboxplus
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

示例2

#live.yml 
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: myapp:v1
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 2
      periodSeconds: 3
    readinessProbe:
      httpGet:
        path: /hostname.html
        port: 80
      initialDelaySeconds: 3
      periodSeconds: 3

3.4 init初始化容器

init容器官方文档

kubectl create -f service.yml

# cat service.yml 
---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

#init.yml
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: myapp:v1
  initContainers:
  - name: init-myservice
    image: busyboxplus
    command: ['sh', '-c', "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]

4. 控制器

控制器官方文档

4.1 Deployment

一个 Deployment 为 Pods 和 ReplicaSets 提供声明式的更新能力。

适用于：

• 创建pod与ReplicaSet
• 滚动更新和回滚
• 扩容与缩容
• 暂停与恢复

4.2 ReplicaSet

可以单独使用，但主要被Deployment用于协调pod创建、删除、更新的机制

• ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。
• 保证给定数量的、完全相同的 Pod 的可用性。
• ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行（与控制器ReplicationController功能相同）
  
  

工作原理

• RepicaSet 是通过一组字段来定义的，包括一个用来识别可获得的 Pod 的集合的选择算符、一个用来标明应该维护的副本个数的数值、一个用来指定应该创建新 Pod 以满足副本个数条件时要使用的 Pod 模板等等。 每个 ReplicaSet 都通过根据需要创建和 删除 Pod 以使得副本个数达到期望值， 进而实现其存在价值。当 ReplicaSet 需要创建新的 Pod 时，会使用所提供的 Pod 模板。
• ReplicaSet 通过 Pod 上的 metadata.ownerReferences 字段连接到附属 Pod，该字段给出当前对象的属主资源。 ReplicaSet 所获得的 Pod 都在其 ownerReferences 字段中包含了属主 ReplicaSet 的标识信息。正是通过这一连接，ReplicaSet 知道它所维护的 Pod 集合的状态， 并据此计划其操作行为。
• ReplicaSet 使用其选择算符来辨识要获得的 Pod 集合。如果某个 Pod 没有 OwnerReference 或者其 OwnerReference 不是一个 控制器，且其匹配到 某 ReplicaSet 的选择算符，则该 Pod 立即被此 ReplicaSet 获得

示例

#rs.yml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: myapp:v1

4.3 DaemonSet

DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。 当有节点加入集群时， 也会为他们新增一个 Pod 。 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

DaemonSet 的一些典型用法：

• 在每个节点上运行集群守护进程
• 在每个节点上运行日志收集守护进程
• 在每个节点上运行监控守护进程

一种简单的用法是为每种类型的守护进程在所有的节点上都启动一个 DaemonSet。 一个稍微复杂的用法是为同一种守护进程部署多个 DaemonSet；每个具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求

示例

#daemonset.yml 
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-example
  labels:
    k8s-app: zabbix-agent
spec:
  selector:
    matchLabels:
      name: zabbix-agent
  template:
    metadata:
      labels:
        name: zabbix-agent
    spec:
      containers:
      - name: zabbix-agent
        image: zabbix-agent

4.4 Job

Job 会创建一个或者多个 Pods，并将继续重试 Pods 的执行，直到指定数量的 Pods 成功终止。 随着 Pods 成功结束，Job 跟踪记录成功完成的 Pods 个数。 当数量达到指定的成功个数阈值时，任务（即 Job）结束。 删除 Job 的操作会清除所创建的全部 Pods。

一种简单的使用场景下，你会创建一个 Job 对象以便以一种可靠的方式运行某 Pod 直到完成。 当第一个 Pod 失败或者被删除（比如因为节点硬件失效或者重启）时，Job 对象会启动一个新的 Pod。

• 仅执行一次任务

示例

#job.yml 
#计算 π 到小数点后 2000 位，并将结果打印出来
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

4.5 Cronjob基于时间调度

基于时间调度的 Job

示例

#cronjob.yml 
#每分钟打印出当前时间和问候消息
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busyboxplus
            imagePullPolicy: IfNotPresent
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

4.6 HPA

根据资源利用率自动调整service中pod数量，实现pod水平自动缩放