k8s资源对象的升级、回滚、扩容、缩容

一、资源创建的方式之一,命令的方式创建资源,理解命令运行之后的动作,通过查看资源的方式,总结Pod名称的由来。

当我们执行创建资源的命令后,deployment这个控制器会通过replicaset控制器去管理pod,下面通过一个实例来分析,当我们执行创建资源的命令后,k8s都做了些什么(通过其NAME即可发现规律)?

运行一个deployment

[[email protected] ~]# kubectl run test01 --image=nginx:latest --replicas=2
#运行一个nginx容器,指定副本数量为2个
[[email protected] ~]# kubectl get deployments.    #查看deployment控制器
NAME     READY   UP-TO-DATE   AVAILABLE   AGE
test01   2/2     2            2           48s
#可以看到deployment的name是我们指定的test01
[[email protected] ~]# kubectl get replicasets.   #然后查看replicasets这个控制器
#注:replicasets可以简写为“rs”
NAME                DESIRED   CURRENT   READY   AGE
test01-799bb6cd4d   2         2         2       119s
#可以看到replicasets的NAME就是在deployment的NAME后面追加了一串ID号
[[email protected] ~]# kubectl get pod      #查看pod的name
NAME                      READY   STATUS    RESTARTS   AGE
test01-799bb6cd4d-d88wd   1/1     Running   0          3m18s
test01-799bb6cd4d-x8wpm   1/1     Running   0          3m18s
#可以看到该pod的NAME就是在上面replicasets的后面又追加了一段ID

同时,可以查看每一个资源对象的详细信息,来验证上面的说法,如下:

[[email protected] ~]# kubectl describe deployments test01   #查看test01的详细信息

返回的信息如下,可以看到其生成了一个新的replicasets控制器,如下:

那么,现在查看其replicasets详细信息,如下:

二、如果想要client访问部署的服务,需要怎么做?关键点在哪里?

如果需要client来访问k8s部署的服务,那么需要创建一个service资源对象,并且其类型必须是NodePort,客户端通过访问service这个资源对象映射的端口,与k8s集群中的proxy进行联系,以便访问到部署的服务。

实现过程如下:

[[email protected] ~]# kubectl run test02 --image=nginx:latest --port=80 --replicas=2
#基于nginx镜像创建deployment资源对象,映射容器的80端口到宿主机
[[email protected] ~]# kubectl expose deployment test02 --name=web01 --port=80 --type=NodePort
#创建一个service,将部署的test02的80端口映射出来
[[email protected] ~]# kubectl get svc web01    #查看创建的web01这个service的信息
NAME    TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
web01   NodePort   10.103.223.105   <none>        80:30230/TCP   86s
#可以看到将部署的服务端口映射到了宿主机的30230,

客户端访问k8s群集中的任意一个节点的30230端口,都可以访问到服务的首页,如下:

三、搭建registry仓库,。基于nginx自定义镜像,将默认访问界面更改为:hello k8s。此为1.10版本。并基于此镜像运行一个Deployment资源对象,replicas数量为4个。

#搭建registry仓库,并在群集中的节点指定到私有仓库
[[email protected] ~]# docker run -tid --name registry -p 5000:5000 --restart always registry:latest
[[email protected] ~]# vim /usr/lib/systemd/system/docker.service    #编辑配置文件
ExecStart=/usr/bin/dockerd -H unix:// --insecure-registry 192.168.20.6:5000
#将修改后的配置文件发送到k8s群集中的其他节点
[[email protected] ~]# scp /usr/lib/systemd/system/docker.service [email protected]:/usr/lib/systemd/system/
[[email protected] ~]# scp /usr/lib/systemd/system/docker.service [email protected]:/usr/lib/systemd/system/
#所有更改了docker配置文件的节点都需要进行以下操作,以便更改生效
[[email protected] ~]# systemctl daemon-reload
[[email protected] ~]# systemctl restart docker
#制作自定义镜像
[[email protected] ~]# vim Dockerfile
FROM nginx:latest
ADD index.html /usr/share/nginx/html/
[[email protected] ~]# echo "hello k8s" > index.html
[[email protected] ~]# docker build -t 192.168.20.6:5000/nginx:1.10 .
[[email protected] ~]# docker push 192.168.20.6:5000/nginx:1.10    #上传至私有仓库
#基于自定义镜像运行一个Deployment资源对象,replicas数量为4个。
[[email protected] ~]# kubectl run test03 --image=192.168.20.6:5000/nginx:1.10 --port=80 --replicas=4
[[email protected] ~]# kubectl get pod -o wide | grep test03 | awk ‘{print $6}‘   #查看四个副本的IP地址
10.244.2.20
10.244.1.18
10.244.1.19
10.244.2.21
#接下来在k8s群集内部访问该上述四个任意IP,即可看到其提供的服务,如下:
#访问测试
[[email protected] ~]# curl 10.244.2.21
hello k8s
[[email protected] ~]# curl 10.244.2.20
hello k8s

四、将上述Deployment资源对象,进行更新、扩容操作,replicas数量更新为6个.镜像仍为自定义镜像,且默认访问界面更改为:Hello update.

#更新镜像并上传至私有仓库
[[email protected] ~]# echo "Hello update" > index.html
[[email protected] ~]# docker build -t 192.168.20.6:5000/nginx:2.20 .
[[email protected] ~]# docker push 192.168.20.6:5000/nginx:2.20
#更新资源对象,进行扩容
[[email protected] ~]# kubectl set image deployment test03 test03=192.168.20.6:5000/nginx:2.20 && kubectl scale deployment test03 --replicas=6
#查看pod的IP地址
[[email protected] ~]# kubectl get pod -o wide | grep test03 | awk ‘{print $6}‘
10.244.2.24
10.244.2.22
10.244.1.21
10.244.2.23
10.244.1.22
10.244.1.20
#访问测试
[[email protected] ~]# curl 10.244.1.20
Hello update
[[email protected] ~]# curl 10.244.1.22
Hello update

五、对此Deployment资源对象进行回滚操作,查看验证最后版本的访问界面内容和replicas数量。

[[email protected] ~]# kubectl rollout undo deployment test03   #执行回滚操作
[[email protected] ~]# kubectl get pod -o wide | grep test03 | wc -l
#查看replicas的数量还是6个
6

#访问测试
[[email protected] ~]# kubectl get pod -o wide | grep test03 | awk ‘{print $6}‘
10.244.1.23
10.244.2.27
10.244.1.24
10.244.1.25
10.244.2.26
10.244.2.25
[[email protected] ~]# curl 10.244.2.25
hello k8s
[[email protected] ~]# curl 10.244.2.26
hello k8s

———————— 本文至此结束,感谢阅读 ————————

原文地址:https://blog.51cto.com/14154700/2448427

时间: 2024-11-05 20:48:58

k8s资源对象的升级、回滚、扩容、缩容的相关文章

Kubernetes高级进阶之pod的自动扩容/缩容

目录:实践1:基于autoscaling cpu指标的扩容与缩容实践2:基于prometheus自定义指标QPS的扩容与缩容 Pod自动扩容/缩容(HPA) Horizontal Pod Autoscaler(HPA,Pod水平自动伸缩),根据资源利用率或者自定义指标自动调整replication controller, deployment 或 replica set,实现部署的自动扩展和缩减,让部署的规模接近于实际服务的负载.HPA不适于无法缩放的对象,例如DaemonSet. HPA主要是

分库分布的几件小事(三)可以动态扩容缩容的分库分表方案

1.扩容与缩容 这个是你必须面对的一个事儿,就是你已经弄好分库分表方案了,然后一堆库和表都建好了,基于分库分表中间件的代码开发啥的都好了,测试都ok了,数据能均匀分布到各个库和各个表里去,而且接着你还通过双写的方案咔嚓一下上了系统,已经直接基于分库分表方案在搞了. 那么现在问题来了,你现在这些库和表又支撑不住了,要继续扩容咋办?这个可能就是说你的每个库的容量又快满了,或者是你的表数据量又太大了,也可能是你每个库的写并发太高了,你得继续扩容. 缩容就是现在业务不景气了,数据量减少,并发量下降,那么

K8s资源对象的基本管理(升级、回滚、扩容、缩容)

博文大纲:一.资源创建二.解决客户端无法访问k8s内部pod所运行的服务三.搭建私有仓库,并自定义镜像四.版本扩容.缩容五.服务的升级与回滚 一.资源创建 本次博文主要介绍如何使用命令行的方式创建资源! [[email protected] ~]# kubectl run test --image=nginx:latest --replicas=5 //基于httpd的镜像创建一个deployment类型的控制组,名称为test,并指定副本数量为5 [[email protected] ~]#

Swarm平滑升级回滚

#滚动更新创建服务: docker service create --name my_web --replicas=5 nginx:1.12更新为1.14 docker service update --image nginx:1.14 my_web 默认配置下,Swarm 一次只更新一个副本,并且两个副本之间没有等待时间.我们可以通过 --update-parallelism 设置并行更新的副本数目,通过 --update-delay 指定滚动更新的间隔时间. docker service u

如何设计可以动态扩容缩容的分库分表方案?

对于分库分表来说,主要是面对以下问题: 选择一个数据库中间件,调研.学习.测试: 设计你的分库分表的一个方案,你要分成多少个库,每个库分成多少个表,比如 3 个库,每个库 4 个表: 基于选择好的数据库中间件,以及在测试环境建立好的分库分表的环境,然后测试一下能否正常进行分库分表的读写: 完成单库单表到分库分表的迁移,双写方案: 线上系统开始基于分库分表对外提供服务: 扩容了,扩容成 6 个库,每个库需要 12 个表,你怎么来增加更多库和表呢? 是你必须面对的一个事儿,就是你已经弄好分库分表方案

如何设计可以动态扩容缩容的分库分表方案

停机扩容(不推荐) 这个方案就跟停机迁移一样,步骤几乎一致,唯一的一点就是那个导数的工具,是把现有库表的数据抽出来慢慢倒入到新的库和表里去.但是最好别这么玩儿,有点不太靠谱,因为既然分库分表就说明数据量实在是太大了,可能多达几亿条,甚至几十亿,你这么玩儿,可能会出问题. 从单库单表迁移到分库分表的时候,数据量并不是很大,单表最大也就两三千万.那么你写个工具,多弄几台机器并行跑,1小时数据就导完了.这没有问题. 如果 3 个库 + 12 个表,跑了一段时间了,数据量都 1~2 亿了.光是导 2 亿

Linux系统LVM(卷)部署-扩容-缩容-快照-删除

常用LVM命令总结: 注: 以下案例均采用的系统版本是Oracle linux 7.3 LVM案例: 部署案例: 第 1 步:让新添加的两块硬盘设备支持LVM 技术. [[email protected] ~]# pvcreate /dev/sdb /dev/sdc Physical volume "/dev/sdb" successfully created Physical volume "/dev/sdc" successfully created 第 2 步

如何设计动态扩容缩容的分库分表方案?

面试官:如何来设计动态扩容的分库分表方案?面试官心理剖析:这个问题主要是看看你们公司设计的分库分表设计方案怎么样的?你知不知道动态扩容的方案? 回答: 背景说明:如果你们公司之前已经做了分库分表,你们当时分了 4 个库,每个库 4 张表:公司业务发展的很好,现在的数据库已经开始吃力了,不能满足快速发展的业务量了,需要进行扩容. 1)停机扩容 这个方案跟单库迁移方案是一样的,就是停服进行数据迁移,不过现在的数据迁移比之前的单库迁移要复杂的多,还有数据量也是之前的好几倍,单库的数据量可能就几千万,但

LVM常规操作记录梳理(扩容/缩容/快照等)

基本介绍Linux用户安装Linux 操作系统时遇到的一个最常见的难以决定的问题就是如何正确地给评估各分区大小,以分配合适的硬盘空间.随着 Linux的逻辑盘卷管理功能的出现,这些问题都迎刃而解,lvm是逻辑盘卷管理(Logical Volume Manager)的简称,它是 Linux环境下对磁盘分区进行管理的一种机制, LVM是建立在硬盘和分区之上的一个逻辑层,来提高磁盘分区管理的灵活性. LVM基本术语:1)物理存储介质:这里指系统的存储设备:硬盘,如: /dev/hda./dev/sda