目录
1、ReplicaSet
2、Deployment
2.1 创建一个Deployment
2.2、 更新Deployment
2.3 、查看Deployment
2.4 、Deployment的回滚
3、DaemonSet
4、Job
5、StatefuleSet
Pod控制器是用于实现管理pod的中间层,确保pod资源符合预期的状态,pod的资源出现故障时,会尝试 进行重启,当根据重启策略无效,则会重新新建pod的资源。 Kubernetes 通过各种 Controller 来管理 Pod 的生命周期。为了满足不同业务场景,Kubernetes 开发了 ReplicaSet、Deployment、DaemonSet、StatefuleSet、Job 等多种 Controller。
1、ReplicaSet
创建指定数量的pod副本数量,确保pod副本数量符合预期状态,并且支持滚动式自动扩容和缩容功能。
ReplicaSet主要三个组件组成:
(1)用户期望的pod副本数量
(2)标签选择器,判断哪个pod归自己管理
(3)当现存的pod数量不足,会根据pod资源模板进行新建
在新版本的Kubernetes中建议使用ReplicaSet来取代ReplicationController。ReplicaSet跟ReplicationController没有本质的不同,只是名字不一样,并且ReplicaSet支持集合式的selector。
虽然ReplicaSet可以独立使用,但一般还是建议使用 Deployment 来自动管理ReplicaSet,这样就无需担心跟其他机制的不兼容问题(比如ReplicaSet不支持rolling-update但Deployment支持)。
注意:Kubernetes官方强烈建议避免直接使用ReplicaSet,而应该通过Deployment来创建RS和Pod
2、Deployment
Deployment为Pod和Replica Set(升级版的 Replication Controller)提供声明式更新。
你只需要在 Deployment 中描述您想要的目标状态是什么,Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。您可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。
2.1 创建一个Deployment
创建名为nginx-deployment的Deployment对象
命令:kubectl apply -f nginx-deployment.yaml
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name : nginx image: nginx : 1.7.9 ports: - containerPort : 80 hostPort: 31002 |
2.2、 更新Deployment
将nginx镜像版本更新:nginx:1.9.1
查看当前nginx版本 kubectl get deploy nginx-deployment -o wide NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR nginx-deployment 5 5 5 5 52m nginx nginx: 1.7 . 9 app=nginx 升级: kubectl set image deployment/nginx-deployment nginx=nginx: 1.9 . 1 --record= true 查看当前nignx版本: kubectl get deploy nginx-deployment -o wide NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR nginx-deployment 5 6 2 4 52m nginx nginx: 1.9 . 1 app=nginx |
2.3 、查看Deployment
kubectl describe deployment nginx-deployment 可以查看deployment,rs,pod 的信息 |
2.4 、Deployment的回滚
有时候您可能想回退一个 Deployment,例如,当 Deployment 不稳定时,比如一直 crash looping。
默认情况下,kubernetes 会在系统中保存前两次的 Deployment 的 rollout 历史记录,以便您可以随时回退(您可以修改revision history limit来更改保存的revision数)。
注意: 只要 Deployment 的 rollout 被触发就会创建一个 revision。也就是说当且仅当 Deployment 的 Pod template(如.spec.template)被更改,例如更新template 中的 label 和容器镜像时,就会创建出一个新的 revision。
其他的更新,比如扩容 Deployment 不会创建 revision——因此我们可以很方便的手动或者自动扩容。这意味着当您回退到历史 revision 是,直有 Deployment 中的 Pod template 部分才会回退。
升级一个错误的版本 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx: 1.91 --record= true kubectl rollout status deployments nginx-deployment Waiting for rollout to finish: 2 out of 5 new replicas have been updated... 可以看到说 5 个中 2 个在升级 查看pod kubectl get pod NAME READY STATUS RESTARTS AGE nginx-deployment-595696685f-l52n9 0 / 1 ImagePullBackOff 0 40s nginx-deployment-595696685f-vc949 0 / 1 ImagePullBackOff 0 39s nginx-deployment-c4747d96c-7nzh9 1 / 1 Running 0 23m nginx-deployment-c4747d96c-9cml8 1 / 1 Running 0 22m nginx-deployment-c4747d96c-btsgc 1 / 1 Running 0 22m nginx-deployment-c4747d96c-m6xnp 1 / 1 Running 0 23m 检查 Deployment 升级的历史记录 kubectl rollout history deployment/nginx-deployment 回退到历史版本 kubectl rollout undo deployment/nginx-deployment --to-revision= 2 |
2.5、Deployment 扩容
kubectl scale deployment nginx-deployment --replicas 10 |
3、DaemonSet
DaemonSet能够让所有(或者一些特定)的Node节点运行同一个pod。当节点加入到kubernetes集群中,pod会被(DaemonSet)调度到该节点上运行,当节点从kubernetes集群中被移除,被(DaemonSet)调度的pod会被移除,如果删除DaemonSet,所有跟这个DaemonSet相关的pods都会被删除。
apiVersion: apps/v1 kind: DaemonSet metadata: name: redis-master labels: app: redis chart: redis-4.0.11 release: "redis" heritage: "Tiller" spec: selector: matchLabels: release: "redis" chart: redis-4.0.11 role: master app: redis template: metadata: labels: release: "redis" chart: redis-4.0.11 role: master app: redis spec: containers: - name : redis image: "harbor.k2software.com.cn/library/bitnami/redis:4.0.11-debian-9" imagePullPolicy: "IfNotPresent" env: - name : REDIS_REPLICATION_MODE value: master - name : REDIS_PASSWORD value: "SzJwYXNzIQ==" - name : REDIS_DISABLE_COMMANDS value: FLUSHDB , FLUSHALL ports: - name : redis containerPort: 6379 livenessProbe: initialDelaySeconds: 30 periodSeconds: 60 timeoutSeconds: 5 successThreshold: 1 failureThreshold: 5 exec: command: - redis-cli - ping readinessProbe: initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 1 successThreshold: 1 failureThreshold: 5 exec: command: - redis-cli - ping resources: requests: cpu: 200m memory: 512Mi volumeMounts: - name : redis-data mountPath: /bitnami/redis/data subPath: volumes: - name : "redis-data" emptyDir: { } |
4、Job
Job负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个Pod成功结束。
Job Spec格式
- spec.template格式同Pod
- RestartPolicy仅支持Never或OnFailure
- 单个Pod时,默认Pod成功运行后Job即结束
.spec.completions
标志Job结束需要成功运行的Pod个数,默认为1.spec.parallelism
标志并行运行的Pod的个数,默认为1spec.activeDeadlineSeconds
标志失败Pod的重试最大时间,超过这个时间不会继续重试
5、StatefuleSet
StatefulSet是为了解决有状态服务的问题(对应Deployments和ReplicaSets是为无状态服务而设计)。
应用场景:
- 稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现
- 稳定的网络标志,即Pod重新调度后其PodName和HostName不变,基于Headless Service(即没有Cluster IP的Service)来实现
- 有序部署,有序扩展,即Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依次依次进行(即从0到N-1,在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态),基于init containers来实现
- 有序收缩,有序删除(即从N-1到0)
apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: ports: - port : 80 name: web clusterIP: None selector: app: nginx --- apiVersion: apps/v1beta2 kind: StatefulSet metadata: name: web spec: selector: matchLabels: app: nginx serviceName: "nginx" replicas: 2 template: metadata: labels: app: nginx spec: containers: - name : nginx image: nginx ports: - containerPort : 80 name: web volumeMounts: - name : disk-ssd mountPath: /data volumeClaimTemplates: - metadata : name: disk-ssd spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "nfs-dynamic-class" resources: requests: storage: 5Gi |
kubectl apply - f nginx-sts.yaml 创建 StatefulSet
Pod一致性
StatefulSet Pod有着唯一的一致性,该一致性包含次序(启动和停止次序)、稳定的网络一致性,和稳定的网络。该一致性和Pod紧密相关,无论Pod被调度到哪个node节点上。
次序索引
对于有N个副本的StatefulSet,StatefulSet的每个Pod都被分配了一个数字序号,序号在[0,N)的范围内,并且在Set中是唯一的。
稳定的存储
Kubernetes为每个VolumeClaimTemplate创建一个PV。在上面的nginx例子中,每个Pod会得到一个PV,该PV的存储等级(storagee class)为anything,大小为1Gb。当Pod被调度到其他node节点上时,volumeMounts会重新映射对应的PVC。注意,当Pod或者StatefulSet被删除时,对应的PV和PVC不会被删除,这个删除操作必须手动来执行。