您的位置:首页 > 其它

kubernetes_02_资源清单_03_Pod控制器_20190919

2020-03-29 13:04 387 查看

Pod类型:

  1. 自主式 Pod:无管理者,Pod退出了,此类型的Pod不会被创建
  2. 控制器管理的 Pod:在控制器的生命周期里,始终要维持 Pod的副本数目

控制器:

         Kubernetes中内建了许多contoller(控制器),这些相当于一个状态机,用来控制Pod的具体状态和行为

控制器类型:

  1. ReplicaSet和ReplicationController(废除)
  2. Deployment
  3. DaemonSet
  4. StateFulSet
  5. Job/CronJob
  6. Horizontal Pod Autoscaling

1.ReplicaSet

rs支持应用容器的副本数目始终保持在用户定义的副本数。创建新的Pod来替代异常退出的Pod。异常多出来的容器自动回收。

rs和rc没有本质的不同,rs支持集合式的selector;rs通过标签Labels(matchLabels)选择与控制

RS与Deployments的关联:deployment通过修改rs的创建来管理对应的Pod,以及通过rs版本的的交替来完成滚动更新

示例:Example006:

/root/yaml/001_pod_rs_deployment_svc/006_rs.yaml

[code]apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: frontend1
spec:
replicas: 3
selector:
matchLabels:
tier: frontend
template:
metadata:
labels:
tier: frontend
spec:
containers:
- name: nginx
image: nginx:latest
imagePullPolicy: IfNotPresent
env:
- name: GET_HOSTS_FROM
value: dns
ports:
- containerPort: 80

2.Deployment

为Pod和ReplicaSet提供一个声明式定义(declarative)方法,用来替代以前的ReplicationCotroller来方便的管理应用。典型的应用场景包括:

  1. 定义Deployment来创建Pod和ReplicaSet
  2. 滚动升级和回滚应用
  3. 扩容和缩容
  4. 暂停和继续更新 Deployment

命令式编程:它侧重于如何实现 create rs

声明式编程:它侧重于结果 apply Deployment

示例:Example007:

/root/yaml/001_pod_rs_deployment_svc/007_deployment.yaml

[code]apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80

1)--record可以记录命令,方便查看每次revision的变化,用于回滚

# kubectl apply -f deployment.yaml --record

2)扩容:

kubectl scale deployment nginx-deployment --replicas 10

3)如果集群支持HPA的话,还可以为Deployment设置自动扩展

4)更新镜像  策略:默认1-1,未来25%-25% ,可以在yaml模版中定义新策略

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

# kubectl set image deployment/nginx-deployment nginx=httpd:latest

Deployment更新策略 # kubectl describe deployments

rollover(多个rollout并行)

v1版本创建了一半,开始升级至v2版,直接杀死v1版的所有pod,并创建v2版本的Pod

5)回滚

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

# kubectl rollout undo deployment/nginx-deployment                         //回滚至上一个版本

# kubectl rollout undo deployment/nginx-deployment --to-revision=2 //回滚到指定版本

# kubectl rollout status deployment/nginx-deployment                       //查看回滚/更新状态,是否更新完成。

# echo $?                                                                                           //Exit Code 退出码为0 ,更新成功

# kubectl rollout pause deployment/nginx-deployment                        //暂停deployment的更新

Deployment.spec.revisionHistoryLimit 可以指定revision历史记录的条数, 默认全保留, 0则不保留历史版本。这同rs版本的数量一致

 

3.DaemonSet

DaemonSet确定全部Node(注意:污点和容忍)上运行一个Pod的副本。新node加入集群,也会为其创建一个Pod。当有Node从集群移除时,这些Pod也会被回收。

删除DaemonSet将会删除它创建的所有Pod

典型用法:

  1. 运行集群存储daemon,例如在每个Node上运行 glusterd、ceph
  2. 在每个Node上运行日志收集daemon,例如fluentd、logstash
  3. 在每个Node上运行监控daemon,例如 Prometheus Node Exporter、collectd、Datadog代理、New Relic代理,或Ganglia gmond

示例:Example008:

/root/yaml/001_pod_rs_deployment_svc/008_DaemonSet.yaml

[code]apiVersion: apps/v1
kind: DaemonSet
metadata:
name: daemonset-example
labels:
app: daemonset
spec:
selector:
matchLabels:
name: daemonset-example
template:
metadata:
labels:
name: daemonset-example
spec:
containers:
- name: daemonset-example
image: httpd:latest

4.Job(执行脚本)

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

Job Spec 特殊说明

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

示例:Example009:

/root/yaml/001_pod_rs_deployment_svc/009_job.yaml

[code]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

5.CronJob(版本>=1.8)

CronJob管理基于时间的Job(分 时 日 月 周 ,同crontab)

典型用法:

1)指定时间点调度Job运行

2)周期性的运行Job,例如:数据库备份、发邮件

CronJob Spec 特殊说明:(同Job Spec)

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

重点字段:

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

CronJob限制:

  1. cronJob创建Job操作应该是 幂等的
  2. cronJob定期运行Job。Job的运行结果运行状态 并不返回给cronJob

示例:Example010:

注意:删除cronjob的时候不会自动删除job。需要独立删除 # kubectl delete job

/root/yaml/001_pod_rs_deployment_svc/010_cronJob.yaml

[code]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 Kubernnetes cluster
restartPolicy: OnFailure

 

6.StatefulSet

  • 与Deployments和ReplicaSets是无状态服务的设计不同,StatefulSet是为了解决有状态服务的问题
  • 需要借助到存储 PV-PVC
  • StatefulSet为Pod提供唯一的标识。它可以保证部署和scale的顺序,保证存储的稳定连接

应用场景:

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

示例在 pv-pvc 处介绍

7.Horizontal Pod Autoscaling

hpa管理deployment,实现Pod的水平自动扩容和缩容,提高集群的整体资源利用率。需要借助到资源收集模块metrics-server。

示例在资源收集模块处介绍

 

  • 点赞
  • 收藏
  • 分享
  • 文章举报
一默1991 发布了47 篇原创文章 · 获赞 5 · 访问量 3万+ 私信 关注
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: