共计 3218 个字符,预计需要花费 9 分钟才能阅读完成。
什么是控制器
Kubernetes 中内建了很多的 controller(控制器),这些控制器相当于一个状态机,用来管制 Pod 的具体状态和行为
控制器的类型
ReplicationController 和 ReplicaSet
ReplicationController(RC) 用来确保容器利用的正本数始终维持在用户定义的正本数,即如果有容器异样退出,会主动创立新的 Pod 来代替,而如果异样多进去的容器也会主动回收。
在新版本的 Kubernetes 中倡议应用 ReplicaSet 来取代 ReplicationController,ReplicaSet 跟 ReplicationController 没有实质的区别,只是名字不一样,并且 ReplicaSet 反对汇合式的 selector(标签)。
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: frontend
spec:
replicas: 3
selector:
natchLatels:
tier: frontend
template:
metadata:
latels:
tier: frontend
sepc:
containsers:
- name: myapp
image: myapp:v1
env:
- name: GET_HOST_FROM
values: dns
ports:
- containerPort: 80
Deployment
Deployment 为 Pod 和 ReplicaSet 提供了一个申明式定义(declarative) 办法,用来代替以前的 ReplicationController 类不便的治理利用,典型的利用场景包含:
- 定义 Deployment 来创立 Pod 和 ReplicaSet
- 滚动降级和回滚利用
- 扩容和缩容
- 暂停和持续 Deployment
apiVersion: extensions/v1beta1
kind:Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: myapp:v1
ports:
- containerPort: 80
扩容
kubectl scale deployment nginx-deployment --replicats 10
如果集群反对 HPA 的话,还能够为 Deployment 设置主动扩大
kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
更新镜像也比较简单
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
回滚
kubectl rollout undo deployment/nginx-deployment
kubectl rollout status deployments nginx-deployment #查看回滚状态
kubectl rollout history deployment/nginx-deployment #查看回滚历史
kubectl rollout pause deployment/nginx-deployment #暂停 deployment 的更新
DaemonSet
Daemon 确保全副或者一些 Node 上运行一个 Pod 的正本,当有 Node 退出集群时,也会为他们新增一个 Pod,当有 Node 从集群移除时,这些 Pod 也会被回收,删除 DaemonSet 将会删除它创立的所有 Pod
应用 DaemonSet 的一些典型用法:
- 运行集群存储 daemon,如 glusterd、ceph
- 在每个 Node 上运行日志手机 daemon,如 fluentd、logstash
- 在每个 Node 上运行监控 daemon,如 prometheus Node Exporter、colletcd、Datadog 代理、New Relic 代理,或 Ganglia gmond
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: daemonset-example #与上面的 selector.matchLabels 中的 name 必须保持一致,不然会始终重启
labels:
app: daemonset
spec:
selector:
matchLabels:
name: daemonset-example
template:
metadata:
labels:
name: daemonset-example
spec:
containers:
- name: daemonset-example
image: myapp:v1
StateFulSet
StateFulSet 作为 Controller 为 Pod 提供惟一的标识,它能够保障部署和 scale 的程序
StateFulSet 是为了解决有状态服务的问题,对应 Deployment 和 ReplicaSet 是为无状态服务而设计的,器利用场景包含:
- 稳固的长久化存储,即 Pod 从新调度后还能拜访到雷同的长久化数据,基于 PVC 来实现
- 稳固的网络标识,即 Pod 从新调度后其 PodName 和 HostName 不变,基于 Headless Service(即没有 Cluster IP 的 Service)来实现
- 有序部署,有序扩大,即 Pod 是有程序的,在部署或者扩大的时候要根据定义的程序顺次进行(即从 0 到 N -1,在下一个 Pod 运行之前所有之前的 Pod 必须都是 Runing 和 Ready 状态),基于 init containers 来实现
- 有序膨胀,有序删除(即从 N - 1 到 0)
Job/CronJob
Job 负责批处理工作,即仅执行一次工作,它保障批处理工作的一个或者多个 Pod 胜利完结
CronJob 治理基于工夫的 Job,即:
- 在给定工夫只运行一次
- 周期性地在给定工夫点运行
典型利用场景如数据库备份,发送邮件等
Job
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
templata:
metadata:
name: pi
spec:
containers:
- name: pi
image: perl
command: ["perl","-Mbignum=bpi","-wle","print bpi(2000)"]
restartPolicy: Never
CronJob
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *" #必须填写的字段
completions: 1 #标记 Job 完结须要胜利运行的 Pod 个数,默认为 1
parallelism: 1 #标记并行运行的 Pod 个数,默认为 1
activeDeadlineSeconds: 5 #标记失败 Pod 的重试最大工夫,超过这个工夫不会持续重试
startingDeadlinSeconds: 5 #启动 Job 的期限(秒级别)concurrencyPolicy: Allow #并发策略,可选 Allow(默认)容许并发运行 Job、Forbid 禁止编发运行、Replace 替换
jobTemplate: #必须填写的字段
spec:
template:
spec:
containers:
- name: hello
image: busybox
args:
- /bin/sh
- -c
- date: echo Hello from the Kubernetes cluster
restartPolicy: OnFailure
Horizontal Pod Autoscaling
利用的资源使用率通常都有顶峰和低谷的时候,如何削峰填谷,进步集群的整体资源利用率,让 service 中的 Pod 个数主动调整呢?这就要依赖于 Horizontal Pod Autoscaling 了,即 Pod 的程度主动缩放