k8s（三）pod生命周期与控制器

三、Pod生命周期

简介

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

• Init 容器与普通的容器非常像，除了如下两点：
  —它们总是运行到完成。
  —Init 容器不支持 Readiness，因为它们必须在 Pod 就绪之前运行完成，每个 Init 容器必须运行成功，下一个才能够运行。

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

pod的环境由goole底层景象pause提供

1. init 初始化容器

cat init.yaml

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

执行清单后，初始化未成功，会不停重启进行初始化。

2.添加服务

添加所有完整的初始化服务之后，init才能成功

vim init.yaml

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busyboxplus
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busyboxplus
    command: ['sh', '-c', "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  - name: init-mydb
    image: busyboxplus
    command: ['sh', '-c', "until nslookup mydb.default.svc.cluster.local; do echo waiting for mydb; 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

查看pod，初始化init成功后，pod启动成功
kubectl get pod-w ##可以查看过程
查看容器解析

解析由两个coredns提供

3.探针

探针 是由 kubelet 对容器执行的定期诊断:

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

每次探测都将获得以下三种结果之一：
成功：容器通过了诊断。
失败：容器未通过诊断。
未知：诊断失败，因此不会采取任何行动。

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

• livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针，则默认状态为 Success。

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

• startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success。

3.1 存活探针:livenessProbe

8080一直重启

cat pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-example
  labels:
    app: myapp
spec:
  #hostNetwork: true
  #nodeName: server4
  #imagePullSecrets: 
  containers:
  - name: myapp
    image: myapp:v1
    imagePullPolicy: IfNotPresent
    resources:
      requests:
        cpu: "100m"
        memory: "50Mi"
      limits:
        cpu: "200m"
        memory: "100Mi"
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 1
    readinessProbe:
      httpGet:
        path: /test.html
        port: 80
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 1

cat svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: mysvc
spec:
  ports:

  - protocol: TCP
    port: 80
    targetPort: 80
      selector:
    app: nginx

改为80后，没有一直重启

kubectl describe pod pod-example##查看pod的详细信息
可以看到存活探针的信息

3.2 存活探针+就绪探针:livenessProbe+readinessProbe

删除pod节点，修改pod.yaml文件，加入就绪探针readinessProbe

cat pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-example
  labels:
    app: myapp
spec:
  #hostNetwork: true
  #nodeName: server4
  #imagePullSecrets: 
  containers:
  - name: myapp
    image: myapp:v1
    imagePullPolicy: IfNotPresent
    resources:
      requests:
        cpu: "100m"
        memory: "50Mi"
      limits:
        cpu: "200m"
        memory: "100Mi"
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 1
    readinessProbe:
      httpGet:
        path: /test.html
        port: 80
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 1

执行pod清单，无法running

没有就绪，可以访问，不对外访问（svc）

4.添加标签将svc和pod联系

通过标签匹配，将svc和pod联系起来，供外网访问。需要就绪，没有就绪没有后端，不会暴露出去

cat svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: mysvc
spec:
  ports:

  - protocol: TCP
    port: 80
    targetPort: 80
      selector:
    app: myapp

cat pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-example
  labels:
    app: myapp
spec:
  #hostNetwork: true
  #nodeName: server4
  #imagePullSecrets: 
  containers:
  - name: myapp
    image: myapp:v1
    imagePullPolicy: IfNotPresent
    resources:
      requests:
        cpu: "100m"
        memory: "50Mi"
      limits:
        cpu: "200m"
        memory: "100Mi"
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 1
    readinessProbe:
      httpGet:
        path: /test.html
        port: 80
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 1

拉起容器后查看标签，没有Running！
kubectl describe svc mysvc 可以看到endpoints还是没有就绪

访问后依然失败，因为容器的nginx中没有test.html
进入容器，添加测试页

查看pod-example已READY

访问给定IP
此时查看mysvc的详细信息，可以看到endpoints也出现了ip地址

kubectl describe svc mysvc

四、控制器

Pod 的分类：

• 自主式 Pod：Pod 退出后不会被创建
• 控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod 的副本数目

1.Replication Controller和ReplicaSet

• ReplicaSet 是下一代的 Replication Controller，官方推荐使用ReplicaSet。
• ReplicaSet 和 Replication Controller 的唯一区别是选择器的支持，ReplicaSet 支持新的基于集合的选择器需求。
• ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。
• 虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制。

ReplicaSet控制器(rs): 控制副本，确定任何时间都有指定数量的Pod副本在运行，根据标签匹配。

ReplicaSet控制器示例
cat rs.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replicaset-example
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

查看pod的扩展信息

查看rs信息

扩容至6个

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replicaset-example
spec:
  replicas: 6
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

查看节点标签

修改节点标签myapp，–overwrite：覆盖节点标签

修改标签后，不影响原来的rs控制器建立的容器，rs还是6

2. Deployment

• Deployment 为 Pod 和 ReplicaSet 提供了一个申明式的定义方法。
• 典型的应用场景：
  用来创建Pod和ReplicaSet;
  滚动更新和回滚;
  扩容和缩容;
  暂停与恢复

deployments控制器：用来创建pod和ReplicaSet，依靠标签显示，相比较rs可更新容器，可扩容，可暂停和恢复

cat deployment.yaml

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

将前面的rs.yaml删除，执行deployment.yaml

kubectl delete -f rs.yaml

查看pod信息

发现，deployment控制器挂载rs控制器

扩容

修改yaml文件，更新容器，节点数为6个

再次执行deployment.yaml清单就可以更新至6个

查看标签，都为nginx

kubectl get pod --show-labels

覆盖

kubectl label pod nginx-deloyment-****** app=myapp --overwrite

查看标签，会多一个标签为myapp的pod，共7个pod

删除myapp标签的pod，剩下6个pod

回滚

一个rs一个本版，保留原来的rs为了回滚
v2-v1

重新执行清单，myapp:v2

3. DaemonSet

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

• DaemonSet 的典型用法：

  • 在每个节点上运行集群存储 DaemonSet，例如 glusterd、ceph。
  • 在每个节点上运行日志收集 DaemonSet，例如 fluentd、logstash。
  • 在每个节点上运行监控 DaemonSet，例如 Prometheus Node Exporter、zabbix agent等

• 一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用。

• 一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求。
  每个节点分布一个

每个集群节点都需要创建，保证每个集群节点有且只有一个的操作。

cat daemonset.yaml

vim  daemonset.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-example
  labels:
    k8s-app: nginx
spec:
  selector:
    matchLabels:
      name: nginx
  template:
    metadata:
      labels:
        name: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

执行清单，查看pod

4. StatefulSet

• StatefulSet 是用来管理有状态应用的工作负载 API 对象。实例之间有不对等关系，以及实例对外部数据有依赖关系的应用，称为“有状态应用”

• StatefulSet 用来管理 Deployment 和扩展一组 Pod，并且能为这些 Pod 提供序号和唯一性保证。

• StatefulSets 对于需要满足以下一个或多个需求的应用程序很有价值：

  • 稳定的、唯一的网络标识符。
  • 稳定的、持久的存储。
  • 有序的、优雅的部署和缩放。
  • 有序的、自动的滚动更新。

5. Job

• 执行批处理任务，仅执行一次任务，保证任务的一个或多个Pod成功结束。

用控制器来做一次计算pi的值，计算到小数点后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

此处的仓库应该为hyl.westos.org

执行清单

6. CronJob

• Cron Job 创建基于时间调度的 Jobs。

• 一个 CronJob 对象就像 crontab (cron table) 文件中的一行，它用 Cron 格式进行编写，并周期性地在给定的调度时间执行 Job。
  周期性的动作

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cronjob-example
spec:
  schedule: "* * * * *" ###每分钟做一次
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: cronjob
            image: busyboxplus
            args:
            - /bin/sh
            - -c
            - date; echo Hello from k8s cluster
          restartPolicy: OnFailure

7. HPA全称Horizontal Pod Autoscaler

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