k8s的控制器介绍
一、Kubernetes 通过各种 Controller 来管理 Pod 的生命周期。
为了满足不同业务场景,Kubernetes 开发了 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等多种 Controller。
1、Controller的控制器类型
Kubernetes 中支持的控制器包括:
ReplicationController:用来维护一个数量稳定的 Pod 副本集合的控制器
ReplicaSet:是 ReplicationController 的升级版,比 ReplicationController 多一个特性:支持基于集合的选择器。 不支持滚动更新(RollingUpdate)
Deployment:包含了 ReplicaSet,可通过声明式、滚动更新的方式更新 ReplicaSet 及其 Pod。对于无状态应用,推荐使用Deployment 部署
StatefulSet:用于管理有状态的应用程序
DaemonSet:在节点上以守护进程的方式运行一个指定的 Pod 副本,例如监控节点、收集节点上的日志时,可使用 DaemonSet
CronJob:按照预定的时间计划创建 Job,类似于 linux 的crontab
Job:使用 Job 执行任务,执行完后结束
##问题一
无状态服务:就是没有特殊状态的服务,各个请求对于服务器来说统一无差别处理,请求自身携带了所有服务端所需要的所有参数
(服务端自身不存储跟请求相关的任何数据,不包括数据库存储信息)
有状态服务:容器数据持久化保持
1.有状态服务 可以说是 需要数据存储功能的服务、或者指多线程类型的服务,队列等。
(mysql数据库、kafka、zookeeper等)
总结:
ReplicaSet控制器:
1、确保pod副本的数量
2、支持自定扩容和收缩
3、不能支持服务的滚动部署
deployment的很好的解决的ReplicaSet 不能灰度发布的问题,支持了滚动部署
Deployment 对象包含 ReplicaSet 作为从属对象,并且可通过声明式、滚动更新的方式来更新 ReplicaSet 及其 Pod。
ReplicaSet 现在主要是被用作 Deployment 中负责 Pod 创建、删除、更新的一种手段。
使用 Deployment 时,无需关心由 Deployment 创建的 ReplicaSet,Deployment 将处理所有与之相关的细节。
同时,Deployment 还能以“声明式”的方式管理 Pod 和 ReplicaSet
(其本质是将一些特定场景的一系列运维步骤固化下来,以便快速准确无误的执行),并提供版本(revision)回退功能。
2、了解三种部署
红绿部署:
创建所有服务新的版本后,将流量更换到新的版本上,再将所有旧版本干掉
滚动部署:
一部分一部分服务的升级,每升级一个服务,将在该旧服务的流量打到新的版本上,并干掉这部分旧服务(逐步替换)
灰度部署(金丝雀):
一部分一部分服务的升级,每升级一个服务,将在该旧服务的部分流量打到新的版本上,但新版本有问题时,可以进行回滚
总结:
deployment控制器:
1、提供了一个声明式的方法来通过replicationset管理pods
2、支持pod的rolingupdate,并自动管理其背后的replicationset
3、支持rollback到之前的revision
3、deployment 在yml文件表示
apiversion: apps/v1 # api版本
kind: Deployment #资源类型
metadata: #元数据定义
name:nginx-deployment-demo #该数据类型的名称
spec:
replicas: 3 #保证pod副本数量为3
revisionHistorylimit: 3 #
selector: #标签选择器
matchlabels:
app: nginx
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnvailable: 0
template: #pod定义模板
metadata:
labels:
app: nginx #pod 标签
spec: # 定义容器模板,可以包含多个容器
containers: #容器定义
- name: nginx
image: nginx:1.7.9 #容器所用镜像
ports:
- containerPort: 80 #向外暴露的端口的
指令
Kubernetes 支持两种方式创建资源:
1. 用 kubectl 命令直接创建,比如:
kubectl run nginx-deployment --image=nginx:1.7.9 --replicas=2
在命令行中通过参数指定资源的属性。
2. 通过配置文件和 kubectl apply 创建,要完成前面同样的工作,可执行命令:
kubectl apply -f nginx.yml
kubectl apply -f nginx-deployment.yml --record
#-f指定更新所用的yml文件,--record可以在以后查看到的升级的历史的情况(kubectl rollout history deployment/nginx-deployment-demo)
kubectl run nginx-deployment --image=nginx:1.7.9 --replicas=2
#通过 kubectl run 创建 Deployment,运行一个 Deployment,上面的命令将部署包含两个副本的 Deployment nginx-deployment,容器的 image 为 nginx:1.7.9。
kubectl rollout status deployment/nginx-deployment-demo #查看deployment的状态
kubectl get deployment #查看deployment的情况
bubectl get rs #查看replicaset的情况
kubectl describe deployment nginx-deployment # 了解deployment更详细的信息。
kubectl get pod --show-labels #查看所有pod的标签,后面可以根据标签进行升级
kubectl get pod -o wide --show-label #查看pod,显示调度的节点及标签
kubectl rollout undo #撤销之前一步的升级
kubectl scale deploy nginx-deploy --replicas=2 #将 Pod 数缩放到2个
kubectl get rs #常看rs的资源,一般滚动升级时,rs会保留一段的旧版本的rs
kubectl get pods #查看pod详细编号
kubectl describe pod nginx-deployment-demo-12254s587-45sl2 #kubectl describe pod 加pod的标签
kubectl explain deployment #查看deployment 的配置项
kubectl explain deployment.spec #查看deployment.spec 模块的配置项
###其它配置项说明:
.spec.minReadySeconds:用来控制应用升级的速度。升级过程中,新创建的 Pod 一旦成功响应了就绪探测即被认为是可用状态,然后进行下一轮的替换。 .spec.minReadySeconds 定义了在新的 Pod 对象创建后至少需要等待多长的时间才能会被认为其就绪,在该段时间内,更新操作会被阻塞。
.spec.progressDeadlineSeconds:用来指定在系统报告 Deployment 失败 —— 表现为状态中的 type=Progressing、Status=False、 Reason=ProgressDeadlineExceeded 前可以等待的 Deployment 进行的秒数。Deployment controller 会继续重试该 Deployment。如果设置该参数,该值必须大于 .spec.minReadySeconds。
.spec.revisionHistoryLimit:用来指定可以保留的旧的 ReplicaSet 或 revision(版本) 的数量。默认所有旧的 Replicaset 都会被保留。如果删除了一个旧的 RepelicaSet,则 Deployment 将无法再回退到那个 revison。如果将该值设置为0,所有具有0个 Pod 副本的 ReplicaSet 都会被删除,这时候 Deployment 将无法回退,因为 revision history 都被清理掉了。
#其他发布更新的方法
# 方式一:直接使用 kubectl 命令设置修改
[root@kmaster ~]# kubectl set image deploy nginx-deploy nginx=nginx:1.16.1 --record
# 方式二:使用 kubectl edit 编辑yaml修改
[root@kmaster ~]# kubectl edit deploy nginx-deploy
自动伸缩(HPA)
如果集群启用了自动伸缩(HPA —— Horizontal Pod Autoscaling),则可以基于 CPU、 内存的使用率在一个最大和最小的区间对 Deployment 实现自动伸缩,
# 创建一个 HPA
[root@kmaster ~]# kubectl autoscale deploy nginx-deploy --min=2 --max=4 --cpu-percent=80
horizontalpodautoscaler.autoscaling/nginx-deploy autoscaled
# 查看 HPA
[root@kmaster ~]# kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx-deploy Deployment/nginx-deploy <unknown>/80% 2 4 2 16s
# 删除 HPA
[root@kmaster ~]# kubectl delete hpa nginx-deploy
horizontalpodautoscaler.autoscaling "nginx-deploy" deleted
#暂停与恢复
我们可以将一个 Deployment 暂停(pause),然后在它上面做一个或多个更新,此时 Deployment 并不会触发更新,只有再恢复(resume)该 Deployment,才会执行该时间段内的所有更新。这种做法可以在暂停和恢复中间对 Deployment 做多次更新,而不会触发不必要的滚动更新。
# 1. 暂停 Deployment
[root@kmaster ~]# kubectl rollout pause deploy nginx-deploy
deployment.apps/nginx-deploy paused
# 2. 更新容器镜像
[root@kmaster ~]# kubectl set image deploy nginx-deploy nginx=nginx:1.9.1 --record
deployment.apps/nginx-deploy image updated
# 3. 查看版本历史, 此时并没有触发更新
[root@kmaster ~]# kubectl rollout history deploy nginx-deploy
deployment.apps/nginx-deploy
REVISION CHANGE-CAUSE
3 kubectl set image deploy nginx-deploy nginx=nginx:1.161 --record=true
4 kubectl set image deploy nginx-deploy nginx=nginx:1.16.1 --record=true
5 kubectl apply --filename=nginx-deploy.yaml --record=true
# 4. 更新 Resource 限制,同样并不会触发更新
[root@kmaster ~]# kubectl set resources deploy nginx-deploy -c=nginx --limits=memory=512Mi,cpu=500m
deployment.apps/nginx-deploy resource requirements updated
# 5. 查看修改,Pod 定义已被更新
[root@kmaster ~]# kubectl describe deploy nginx-deploy
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.9.1
Port: 80/TCP
Host Port: 0/TCP
Limits:
cpu: 500m
memory: 512Mi
# 6. 恢复 Deployment
[root@kmaster ~]# kubectl rollout resume deploy nginx-deploy
deployment.apps/nginx-deploy resumed
# 7. 查看版本历史,可见两次修改只做了一次 rollout
[root@kmaster ~]# kubectl rollout history deploy nginx-deploy
deployment.apps/nginx-deploy
REVISION CHANGE-CAUSE
3 kubectl set image deploy nginx-deploy nginx=nginx:1.161 --record=true
4 kubectl set image deploy nginx-deploy nginx=nginx:1.16.1 --record=true
5 kubectl apply --filename=nginx-deploy.yaml --record=true
6 kubectl set image deploy nginx-deploy nginx=nginx:1.9.1 --record=true