"/>
侧边栏壁纸
博主头像
PySuper 博主等级

千里之行,始于足下

  • 累计撰写 218 篇文章
  • 累计创建 15 个标签
  • 累计收到 2 条评论

目 录CONTENT

文章目录

Kubernetes | 资源控制器

PySuper
2021-05-19 / 0 评论 / 0 点赞 / 32 阅读 / 0 字
温馨提示:
本文最后更新于2024-05-28,若内容或图片失效,请留言反馈。 所有牛逼的人都有一段苦逼的岁月。 但是你只要像SB一样去坚持,终将牛逼!!! ✊✊✊

自助式Pod:Pod退出后,此类型的Pod不会被创建

控制器管理的Pod:在控制器的生命周期里,始终要维持Pod的副本数量

控制器类型

RC 和 RS

  • RC
    • 用来确保容器应用的副本数始终保持在用户定义的副本数
      • 如果容器异常退出,会自动创建新的 Pod 来替代
      • 如果因为异常多出来的容器,也会自动回收
    • 在新版本的 Kubernetes 中建议使用 RS来取代 RC
  • ReplicaSet
    • 跟 RC 没有本质的不同,只是名字不一样
    • 但是 RS支持集合式的 selector (标签)

Deployment

虽然 RS 可以独立使用,但一般还是建议使用 Deployment 来自动管理

这样就无需担心跟其他机制的不兼容问题(比如 RS 不支持 rolling-update 但 Deployment 支持)

Deployment 为 Pod 和 RS 提供了一个声明式定义 (declarative) 方法,用来替以前的 RC 来方便的管理应用

  • 定义 Deployment 来创建 Pod 和 RS(Deployment通过RS来管理Pod)
  • 扩容和缩容
  • 滚动升级和回滚应用(通过控制RS的数量实现)
  • 暂停和继续 Deployment(通过控制RS的数量实现)

DaemonSet

  • DaemonSet 确保全部或者一些Node 上运行一个 Pod 的副本(守护进程)
  • 当有 Node 加入集群时,也会为他们新增一个 Pod
  • 当有 Node 从集群移除时,这些 Pod 也会被回收
  • 删除 DaemonSet 将会删除它创建的所有 Pod
  • 使用 DaemonSet 的一些典型用法
    • 运行集群存储 daemon,例如在每个 Node 上运行glusterdceph
    • 在每个 Node 上运行日志收集 daemon,例如fluentdlogstash
    • 在每个 Node 上运行监控 daemon,例如 collectd、Datadog 代理、New Relic 代理,或 Ganglia gmond

Job

  • Job 负责批处理任务,即仅执行一次的任务
  • 它保证批处理任务的一个或多个 Pod 成功结束

Cron Job

  • 基于时间的 Job
    • 在给定时间点只运行一次,在给定的时间点调度 Job 运行
    • 周期性地在给定时间点运行,创建周期性运行的 Job,例如:数据库备份、发送邮件

StatefulSet

作为 Controller 为 Pod 提供唯一的标识。它可以保证部署和 scale 的顺序

StatefulSet 是为了解决有状态服务的问题(对应 RS 和 Deployments 是为无状态服务而设计)

  • 稳定的持久化存储
    • Pod 重新调度后,还是能访问到相同的持久化数据
    • 基于 PVC 来实现
  • 稳定的网络标志
    • Pod 重新调度后其 PodName 和 HostName 不变,基于Headless Service来实现
    • Headless Service:没有 Cluster IP 的 Service
  • 有序部署、有序扩展
    • Pod 是有顺序的,在部署或者扩展的时候要依据定义的顺序依次依次进行
    • 即从 0 到 N-1,在下一个 Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态
    • 基于 init containers 来实现
  • 有序收缩、有序删除:即从 N - 1 到 0

HPA

应用的资源使用率通常都有高峰和低谷的时候,削峰填谷,提高集群的整体资源利用率,让service中的Pod个数自动调整,这就有赖于 HPA 了,顾名思义,使Pod水平自动缩放。

HPA 仅适用于 Deployment 和 RS

  • 在 V1 版本中仅支持根据 Pod 的 CPU 利用率扩所容
  • 在 v1alpha 版本中,支持根据内存和用户自定义的 metric 扩缩容

Deployment

RS 与 RC 与 Deployment 关联

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
     containers:
     - name: php-redis
       image: gcr.io/google_samples/gb-frontend:v3
       env:
       - name: GET_HOSTS_FROM
         value: dns
       ports:
       - containerPort: 80

RS 与 Deployment 的关联

RS&Deployment

Deployment使用

1、部署一个简单的 Nginx 应用

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
          - containerPort: 80
# --record参数可以记录命令,我们可以很方便的查看每次 revision 的变化
# kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record

2、扩容

# kubectl scale deployment nginx-deployment --replicas 10

3、如果集群支持 horizontal pod autoscaling 的话,还可以为Deployment设置自动扩展

# kubectl autoscale deployment nginx-deployment --min=10--max=15--cpu-percent=80

4、更新镜像也比较简单

# kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

5、回滚

# kubectl rollout undo deployment/nginx-deployment

更新Deployment

  • 假如我们现在想要让 nginx pod 使用nginx:1.9.1的镜像来代替原来的nginx:1.7.9的镜像
# kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
   
# -->> deployment "nginx-deployment" image updated
  • 可以使用edit命令来编辑 Deployment
# kubectl edit deployment/nginx-deployment

# -->> deployment "nginx-deployment" edited
  • 查看 rollout 的状态
# kubectl rollout status deployment/nginx-deployment
   
# -->> Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
# -->> deployment "nginx-deployment" successfully rolled out
  • 查看历史 RS
# kubectlget rs
   
# -->> NAME                          DESIRED   CURRENT   READY   AGE
# -->> nginx-deployment-1564180365   3         3         0       6s
# -->> nginx-deployment-2035384211   0         0         0       36s

Deployment 更新策略

  • Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的
    • 默认的,它会确保至少有比期望的Pod数量少一个是up状态(最多一个不可用)
  • Deployment 同时也可以确保只创建出超过期望数量的一定数量的 Pod
    • 默认的,它会确保最多比期望的Pod数量多一个的 Pod 是 up 的(最多1个 surge )
    • 未来的 Kuberentes 版本中,将从1-1变成25%-25%
# kubectl describe deployment

Rollover(多个rollout并行)

假如您创建了一个有5个niginx:1.7.9 replica的 Deployment

但是当只有3个nginx:1.7.9的 replica 创建出来的时候,就开始更新含有5个nginx:1.9.1 replica 的 Deployment

在这种情况下,Deployment 会立即杀掉已创建的3个nginx:1.7.9的 Pod,并开始创建nginx:1.9.1的 Pod

它不会等到所有的5个nginx:1.7.9的Pod 都创建完成后才开始改变航道

回退 Deployment

# kubectl set image deployment/nginx-deployment nginx=nginx:1.91

# rollout status:查看当前的更新状态
# kubectl rollout status deployments nginx-deployment

# kubectl get pods

# history:查看历史版本
# kubectl rollout history deployment/nginx-deployment

# kubectl rollout undo deployment/nginx-deployment

# 可以使用 --revision 参数,指定某个历史版本
# kubectl rollout undo deployment/nginx-deployment --to-revision=2

# 暂停 deployment 的更新
# kubectl rollout pause deployment/nginx-deployment
  • 您可以用kubectl rollout status命令查看 Deployment 是否完成
  • 如果 rollout 成功完成,kubectl rolloutstatus将返回一个0值的 Exit Code
# kubectl rollout status deploy/nginx

# -->> Waiting for rollout to finish: 2 of 3 updated replicas are available...
# -->> deployment "nginx" successfully rolled out
# -->> $ echo$?
# -->> 0

清理 Policy

  • 可以通过设置.spec.revisonHistoryLimit项来指定 deployment 最多保留多少 revision 历史记录
  • 默认的会保留所有的 revision
  • 如果将该项设置为0,Deployment 就不允许回退了

DaaemonSet

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

Job

字段说明

  • spec.template格式同Pod
  • RestartPolicy仅支持Never或OnFailure
  • 单个Pod时,默认Pod成功运行后Job即结束
  • .spec.completions标志Job结束需要成功运行的Pod个数,默认为1
  • .spec.parallelism标志并行运行的Pod的个数,默认为1
  • .spec.activeDeadlineSeconds标志失败Pod的重试最大时间,超过这个时间不会继续重试

示例

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl","-Mbignum=bpi","-wle","print bpi(2000)"]
      restartPolicy: Never

CronJob Spec

字段说明

  • spec.template格式同Pod
  • RestartPolicy仅支持Never或OnFailure
  • 单个Pod时,默认Pod成功运行后Job即结束
  • .spec.completions标志Job结束需要成功运行的Pod个数,默认为1
  • .spec.parallelism标志并行运行的Pod的个数,默认为1
  • .spec.activeDeadlineSeconds标志失败Pod的重试最大时间,超过这个时间不会继续重试

CronJob

字段说明

  • .spec.schedule:调度,必需字段,指定任务运行周期,格式同 Cron
  • .spec.jobTemplate:Job 模板,必需字段,指定需要运行的任务,格式同 Job
  • .spec.startingDeadlineSeconds
    • 启动 Job 的期限(秒级别),该字段是可选的
    • 如果因为任何原因而错过了被调度的时间,那么错过执行时间的 Job 将被认为是失败的
    • 如果没有指定,则没有期限
  • .spec.concurrencyPolicy
    • 并发策略,该字段也是可选的
    • 它指定了如何处理被 Cron Job 创建的 Job 的并发执行
    • 只允许指定下面策略中的一种
      • Allow(默认):允许并发运行 Job
      • Forbid:禁止并发运行,如果前一个还没有完成,则直接跳过下一个
      • Replace:取消当前正在运行的 Job,用一个新的来替换
      • 注意
        • 当前策略只能应用于同一个 Cron Job 创建的 Job
        • 如果存在多个 Cron Job,它们创建的 Job 之间总是允许并发运行。
  • .spec.suspend
    • 挂起,该字段也是可选的
    • 如果设置为true,后续所有执行都会被挂起
    • 它对已经开始执行的 Job 不起作用。默认值为false。
  • .spec.successfulJobsHistoryLimit.spec.failedJobsHistoryLimit
    • 历史限制,是可选的字段
    • 它们指定了可以保留多少完成和失败的 Job
    • 默认情况下,它们分别设置为3和1。设置限制的值为0,相关类型的 Job 完成后将不会被保留。

示例

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure
# kubectl get cronjob

# NAME      SCHEDULE      SUSPEND   ACTIVE    LAST-SCHEDULE
# hello     */1 * * * *   False     0         <none>

# kubectl get jobs

# NAME               DESIRED   SUCCESSFUL   AGE
# hello-1202039034   1         1            49s

# pods=$(kubectl get pods --selector=job-name=hello-1202039034 --output=jsonpath={.items..metadata.name})

# kubectl logs $pods
# Mon Aug 29 21:34:09 UTC 2016
# Hello from the Kubernetes cluster


# 注意,删除 cronjob 的时候不会自动删除 job,这些 job 可以用 kubectl delete job 来删除
# kubectl delete cronjob hello
# cronjob "hello" deleted

限制

  • 创建 Job 操作应该是 幂等的
  • Job的状态可以判断,但是CronJob无法链接到Job的状态,它只会定时的创建Job

0

评论区