ReplicationController (复制控制器,RC)和ReplicaSet(复制集,RS)是两种简单部署pod的方式,因为在生产环境中,主要使用更高级的Deployment等方式部署、运行、管理pod,所以本节只对RC和RS部署进行简单介绍
**Deployment 管理Rs/RS 管理 Pod **
ReplicaSet是支持基于集合的标签选择器的下一代Replication Controller,它主要用作Deployment协调创建、删除和更新Pod,和Replication Controller唯一的区别是,ReplicaSet支持标签选择器。在实际应用中,虽然ReplicaSet可以单独使用,但是一般建议使用Deployment来自动管理ReplicaSet,除非自定义的Pod不需要更新或有其他编排等。
Replication Controller和ReplicaSet的创建删除和Pod并无太大区别,Replication Controller目前几乎已经不在生产环境中使用,ReplicaSet也很少单独被使用,都是使用更高级的资源Deployment、DaemonSet、StatefulSet进行管理Pod。
Deployment概念:用于部署无状态的服务,这个最常用的控制器。一般用于管理维护企业内部无状态的微服务,比如configserver、zuul、springboot。他可以管理多个副本的Pod实现无缝迁移、自动扩容缩容、自动灾难恢复、一键回滚等功能。
虽然ReplicaSet可以确保在任何给定时间运行的Pod副本达到指定的数量,但是Deployment(部署)是一个更高级的概念,它管理ReplicaSet并为Pod和ReplicaSet提供声明性更新以及许多其他有用的功能,所以建议在实际使用中,使用Deployment代替ReplicaSet。
如果在Deployment对象中描述了所需的状态,Deployment控制器就会以可控制的速率将实际状态更改为期望状态。也可以在Deployment中创建新的ReplicaSet,或者删除现有的Deployment并使用新的Deployment部署所用的资源。
kubectl get deployment #查看Deployment下Pod
kubectl create deployment nginx --image=nginx:1.19.0 --replicas=4
# 创建deployment pod
--replicas=4 #就是副本,4个副本
直接vim dc-nginx.yaml文件
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec :
- name: nginx
image: nginx:1.19.0
ports:
- containerPort: 80
示例解析:
kind: Deployment 类型 deploymnt
nginx-deployment:Deployment的名称。
replicas: 创建Pod的副本数。
selector:定义Deployment如何找到要管理的Pod,与template的label(标签)对应。
template字段包含以下字段:
app: nginx使用label(标签)标记Pod
spec:表示Pod运行一个名字为nginx的容器。
image:运行此Pod使用的镜像
Port:容器用于发送和接收流量的端口
运行 deployment.yaml文件
kubectl create -f dc-nginx.yaml
也可以直接修改deployment,让yaml文件直接生效
kubectl edit deployment nginx-deployment #按SHIFT加ZZ退出
kubectl get deployment -o wide #更加详细的查看 deployment
NAME:集群中Deployment的名称。
READY: Pod的状态,已经ready的Pod个数,前边的1是准备好的pod数量,后边1是deployment中配置的pod副本数。
UP-TO-DATE:显示已达到期望状态的被更新的副本数。
AVAILABLE:显示用户可以使用的应用程序副本数,当前为1,因为部分Pod仍在创建过程中。
AGE:显示应用程序运行的时间。
CONTAINERS: 容器的名称
IMAGES: 镜像名称
SELECTOR: 管理的pod标签
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nQYAbzrz-1634901461639)(C:\Users\yyc\AppData\Roaming\Typora\typora-user-images\image-20210926180835599.png)]
一般对应用程序升级或者版本迭代时,会通过Deployment对Pod进行滚动更新。
当然也可以直接编辑Deployment,效果相同: 回滚也可以
kubectl edit deployment nginx-deployment
kubectl set image deployment nginx-deployment nginx=nginx:1.20.0 --record
--record # 保留更新的历史纪录
当新版本不稳定时,可以对其进行回滚操作,默认情况下,所有Deployment的rollout历史都保留在系统中,可以随时回滚。
kubectl rollout history deployment nginx-deployment #查看部署历史kubectl rollout undo deployment nginx-deployment --to-revision=1 #回滚--to-revision=1 # 使用--to-revision参数回到指定版本:
当公司访问量变大,三个Pod已无法支撑业务时,可以对其进行扩展。
扩容 kubectl scale deployment nginx --replicas=5--replicas=5 #副本数
缩容 kubectl scale deployment nginx --replicas=3
Deployment支持暂停更新,用于对Deployment进行多次修改操作。
暂停更新 kubectl rollout pause deployment nginx-deployment恢复更新kubectl rollout resume deployment nginx-deployment暂停更新期间 对deployment 修改或更新等回复更新后继续执行。
在默认情况下,revision保留10个旧的ReplicaSet,其余的将在后台进行垃圾回收,可以在.spec.revisionHistoryLimit设置保留ReplicaSet的个数。当设置为0时,不保留历史记录。
.spec.strategy.type==Recreate,表示重建,先删掉旧的Pod再创建新的Pod。strategy: #Recreate: #maxSurge: 25% #maxUnavailable: 25% type: Recreate.spec.strategy.type==RollingUpdate,表示滚动更新,可以指定maxUnavailable和maxSurge来控制滚动更新过程。 .spec.strategy.rollingUpdate.maxUnavailable,指定在回滚更新时最大不可用的Pod数量,可选字段,默认为25%,可以设置为数字或百分比,如果maxSurge为0,则该值不能为0。 .spec.strategy.rollingUpdate.maxSurge可以超过期望值的最大Pod数,可选字段,默认为25%,可以设置成数字或百分比,如果maxUnavailable为0,则该值不能为0maxUnavailable 滚动更新期间最大多少个pod不可用maxSurge 一次可次超出期望值多少个pod
None(无策略)
清除 Pod 预设 DNS 配置,当 dnsPolicy 设置成为这个值之后, kubernetes 不会为 Pod 预先加载任何逻辑用于判定得到 DNS 的配置
默认预设 (Default)
Pod 里面的 DNS 配置继承了宿主机上的 DNS 配置。即,该 Pod 的 DNS 配置与宿主机完全一致。
集群优先 (ClusterFirst)
与 Default 相反,会预先使用 kube-dns (或 CoreDNS ) 的信息当预设置参数写入到该 Pod 内的DNS配置。如设置了 hostNetwork = true 时,ClusterFirst 会被强制转化为 Default
ClusterFirstWithHostNet (宿主机与 Kubernetes 共存 )
集群 DNS 优先,并伴随着使用宿主机网络
单词 Deployment 部署