Kubernetes 系列(一):Deployment 扩容

(1)首先我们创建一个nginx的Deployment,采用官方的yaml:

kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record

创建完成后查看下状态:

kubectl get deployments
kubectl get rs
kubectl get pods

OK,现在我们有了一个3各Pod的deployment。

我们使用以下命令进行扩容:

kubectl scale deployment nginx-deployment --replicas 10

假设您的集群中启用了horizontal pod autoscaling,您可以给 Deployment 设置一个 autoscaler,基于当前 Pod的 CPU 利用率选择最少和最多的 Pod 数。

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

通过Kubectl get pods查看最新状态:

比例扩容

RollingUpdate Deployment 支持同时运行一个应用的多个版本。或者 autoscaler 扩 容 RollingUpdate Deployment 的时候,正在中途的 rollout(进行中或者已经暂停的),为了降低风险,Deployment controller 将会平衡已存在的活动中的 ReplicaSet(有 Pod 的 ReplicaSet)和新加入的 replica。这被称为比例扩容。

例如,您正在运行中含有10个 replica 的 Deployment。maxSurge=3,maxUnavailable=2。

$ kubectl get deploy
NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment     10        10        10           10          50s

您更新了一个镜像,而在集群内部无法解析。

kubectl set image deploy/nginx-deployment nginx=nginx:sometag
deployment "nginx-deployment" image updated

镜像更新启动了一个包含ReplicaSet nginx-deployment-1989198191的新的rollout,但是它被阻塞了,因为我们上面提到的maxUnavailable。

kubectl get rs
NAME                          DESIRED   CURRENT   READY     AGE
nginx-deployment-1989198191   5         5         0         9s
nginx-deployment-618515232    8         8         8         1m

然后发起了一个新的Deployment扩容请求。autoscaler将Deployment的repllica数目增加到了15个。Deployment controller需要判断在哪里增加这5个新的replica。如果我们没有谁用比例扩容,所有的5个replica都会加到一个新的ReplicaSet中。如果使用比例扩容,新添加的replica将传播到所有的ReplicaSet中。大的部分加入replica数最多的ReplicaSet中,小的部分加入到replica数少的ReplciaSet中。0个replica的ReplicaSet不会被扩容。

在我们上面的例子中,3个replica将添加到旧的ReplicaSet中,2个replica将添加到新的ReplicaSet中。rollout进程最终会将所有的replica移动到新的ReplicaSet中,假设新的replica成为健康状态。

kubectl get deploy
NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment     15        18        7            8           7m
kubectl get rs
NAME                          DESIRED   CURRENT   READY     AGE
nginx-deployment-1989198191   7         7         0         7m
nginx-deployment-618515232    11        11        11        7m

检查 Deployment 升级的历史记录

因为我们创建 Deployment 的时候使用了--recored参数可以记录命令,我们可以很方便的查看每次 revision 的变化。

首先,检查下 Deployment 的 revision:

PS G:\k8s-for-docker\k8s-for-docker-desktop> kubectl rollout history deployment/nginx-deployment
deployments "nginx-deployment"
REVISION  CHANGE-CAUSE
1         kubectl.exe create --filename=https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record=true
2         kubectl.exe scale deployment nginx-deployment --replicas=10
3         kubectl.exe set image deploy/nginx-deployment nginx=nginx:sometag

我们还可以查看版本的具体信息:

PS G:\k8s-for-docker\k8s-for-docker-desktop> kubectl rollout history deployment/nginx-deployment --revision=2
deployments "nginx-deployment" with revision #2
Pod Template:
  Labels:       app=nginx
        pod-template-hash=703038527
  Annotations:  kubernetes.io/change-cause=kubectl.exe scale deployment nginx-deployment --replicas=10
  Containers:
   nginx:
    Image:      nginx:1.9.1
    Port:       80/TCP
    Host Port:  0/TCP
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>

回退到历史版本

我们可以看到包括创建在内一共有3各版本,我们可以指定回退到某个版本,比如回退到2版本:

kubectl rollout undo deployment/nginx-deployment --to-revision=2

查看回滚状态:

kubectl get deploy
NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   10        10        10           10          3h
kubectl rollout history deployment/nginx-deployment
deployments "nginx-deployment"
REVISION  CHANGE-CAUSE
1         kubectl.exe create --filename=https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record=true
3         kubectl.exe set image deploy/nginx-deployment nginx=nginx:sometag
4         kubectl.exe scale deployment nginx-deployment --replicas=10

可以看到版本历史记录里多了一个4版本,10个副本的历史记录。

暂停和恢复Deployment

您可以在发出一次或多次更新前暂停一个 Deployment,然后再恢复它。这样您就能多次暂停和恢复 Deployment,在此期间进行一些修复工作,而不会发出不必要的 rollout。

例如使用刚刚创建 Deployment:

kubectl get deploy
NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   10        10        10           10          3h

使用以下命令暂停 Deployment:

kubectl rollout pause deployment/nginx-deployment
deployment.apps "nginx-deployment" paused

然后更新 Deplyment中的镜像,最后,恢复这个 Deployment,观察完成更新的 ReplicaSet 已经创建出来了:

kubectl rollout resume deploy nginx

Deployment 状态

Deployment 在生命周期中有多种状态。在创建一个新的 ReplicaSet 的时候它可以是 progressing 状态, complete 状态,或者 fail to progress状态。

进行中的 Deployment

Kubernetes 将执行过下列任务之一的 Deployment 标记为 progressing 状态:

  • Deployment 正在创建新的ReplicaSet过程中。
  • Deployment 正在扩容一个已有的 ReplicaSet。
  • Deployment 正在缩容一个已有的 ReplicaSet。
  • 有新的可用的 pod 出现。

您可以使用kubectl rollout status命令监控 Deployment 的进度。

kubectl rollout status deployment/nginx-deployment
deployment "nginx-deployment" successfully rolled out
PS G:\k8s-for-docker\k8s-for-docker-desktop> echo $?
True

完成的 Deployment

Kubernetes 将包括以下特性的 Deployment 标记为 complete 状态:

Deployment 最小可用。最小可用意味着 Deployment 的可用 replica 个数等于或者超过 Deployment 策略中的期望个数。
所有与该 Deployment 相关的replica都被更新到了您指定版本,也就说更新完成。
该 Deployment 中没有旧的 Pod 存在。

您可以用kubectl rollout status命令查看 Deployment 是否完成。如果 rollout 成功完成,kubectl rollout status将返回一个0值的 Exit Code。

失败的 Deployment

您的 Deployment 在尝试部署新的 ReplicaSet 的时候可能卡住,用于也不会完成。这可能是因为以下几个因素引起的:

  • (1)无效的引用
  • (2)不可读的 probe failure
  • (3)镜像拉取错误
  • (4)权限不够
  • (5)范围限制
  • (6)程序运行时配置错误

原文地址:https://www.cnblogs.com/weiBlog/p/10463736.html

时间: 2024-10-04 03:35:47

Kubernetes 系列(一):Deployment 扩容的相关文章

kubernetes系列教程(五)初识核心概念pod

写在前面 前面的系列文章已介绍kubernetes架构,安装,升级和快速入门,读者通过文章的实操已对kubernetes已有初步的认识和理解,从本章开始逐步介绍kubernetes中的基础概念概念和核心概念,基础概念包括:namespace,labels,annotations,pods,volumes等:核心概念包含kubernetes中各种controller,包含以下几种: 应用副本控制器有:Deployments,ReplicaSets,DaemonSets,StatefulSets:

kubernetes系列之ConfigMap使用方式

作用理解 核心用途就是容器和配置的分离解耦. 如启用一个mysql容器,mysql容器重要的文件有两部分,一部分为存储数据文件,一部分为配置文件my.cnf,存储数据可以用持久存储实现和容器的分离解耦,配置文件也能够实现和容器的分离解耦,也就是说mysql容器能够直接读取并使用预先配置好的配置文件(而不是使用容器中默认自带的配置文件).这就是configMap的功能. ConfigMap 用于保存配置数据的键值对,可以用来保存单个属性,也可以用来保存配置文件.ConfigMap 跟 secret

kubernetes系列教程(十八)TKE中实现ingress服务暴露

写在前面 上一篇文章中介绍了基于Nginx实现Ingress Controller的实现,介绍了Nginx Ingress Controller安装.相关功能,TLS,高级特性等介绍,本章开始介绍基于腾讯云TKE实现ingress服务暴露. 1. TKE ingress 1.1 TKE ingress架构 TKE是Tencent Kubernetes Engine即腾讯云基于kubernetes提供的公有云上容器云服务,TKE提供了两种暴露服务的方式:service和ingress. 内网CLB

kubernetes系列教程(三)kubernetes快速入门

写在前面 kubernetes中涉及很多概念,包含云生态社区中各类技术,学习成本比较高,k8s中通常以编写yaml文件完成资源的部署,对于较多入门的人来说是个较高的门坎,本文以命令行的形式代理大家快速入门,俯瞰kubernetes核心概念,快速入门. 1. 基础概念 1.1 集群与节点 kubernetes是一个开源的容器引擎管理平台,实现容器化应用的自动化部署,任务调度,弹性伸缩,负载均衡等功能,cluster是由master和node两种角色组成,其中master负责管理集群,master节

kubernetes系列教程(九)初识Pod存储管理

写在前面 上一篇文章中kubernetes系列教程(八)Pod健康检查机制介绍了kubernetes中Pod健康检查机制,通过实战介绍了kubernetes中两种健康检查探针:livenessProbe存活检查,readinessProbe就绪检查,存活检查用于检查应用的可用性,就绪检查用于检查容器是否准备接受流量,健康检查包含三种探测的方法:exec命令行探测,tcpSocket端口检测,httpGet请求检测,分别适用于不同场景下的健康检查.接下来介绍kubernetes系列教程pod的存储

Kubernetes系列之Kubernetes部署metrics-server

四.Kubernetes系列之Kubernetes部署metrics-server#一.metrics-server简介自kubernetes 1.8开始,资源使用指标(如容器 CPU 和内存使用率)通过 Metrics API 在 Kubernetes 中获取,metrics-server 替代了heapster.Metrics Server 实现了Resource Metrics API,Metrics Server?是集群范围资源使用数据的聚合器.?Metrics Server 从每个节点

Kubernetes Controller 之 Deployment 介绍

一.Deployment 我们接着前面的文章说,如果不清楚的请查看之前的博文:http://blog.51cto.com/wzlinux/2322616 前面我们已经了解到,Kubernetes 通过各种 Controller 来管理 Pod 的生命周期.为了满足不同业务场景,Kubernetes 开发了 Deployment.ReplicaSet.DaemonSet.StatefuleSet.Job 等多种 Controller.我们首先学习最常用的 Deployment. 1.运行 Depl

Kubernetes 控制器之 Deployment 介绍(六)

一.Deployment.ReplicaSet.Pod之间的关系 我们接着前面的文章说,如果不清楚的请查看之前的博文:http://blog.51cto.com/wzlinux/2322616 前面我们已经了解到,Kubernetes 通过各种 Controller 来管理 Pod 的生命周期.为了满足不同业务场景,Kubernetes 开发了 Deployment.ReplicaSet.DaemonSet.StatefuleSet.Job 等多种 Controller.我们首先学习最常用的 D

kubernetes系列03—kubeadm安装部署K8S集群

1.kubernetes安装介绍 1.1 K8S架构图 1.2 K8S搭建安装示意图 1.3 安装kubernetes方法 1.3.1 方法1:使用kubeadm 安装kubernetes(本文演示的就是此方法) 优点:你只要安装kubeadm即可:kubeadm会帮你自动部署安装K8S集群:如:初始化K8S集群.配置各个插件的证书认证.部署集群网络等.安装简易. 缺点:不是自己一步一步安装,可能对K8S的理解不会那么深:并且有那一部分有问题,自己不好修正. 1.3.2 方法2:二进制安装部署k