Deployment生产环境
1、小菜
创建一个yaml文件,用来执行deployment来启动三个nginx的pod
kubectl create -f nginx.yaml --record(后期便于回滚升级该资源)
查询执行后pod(截图我修改了pod数量),可以看见成功启动了pod,并且处于running状态、
若处于其他状态,可查询创建状态描述kubectl describe pod nginx-2312414144(pod后面不加查询所有的描述,现在两个pod不明显,多了就必须指定)。
2、通过ReplicaSet也可以查询pod创建的状态(Deployment其实也就算Replyment的上级,指挥它干活)
他的前缀名nginx就是由我们指定的,存在于template字段,由其定义前缀,官方来说就是<Deployment的名字=pod template的hash值>
另外就是我们的标签,他是由pod的template的label控制的(途中==图中显示为app=nginx)
2、正菜
1、更新Deployment
新名词rollout,触发条件是我们的deployment的pod中的标签label或者镜像更改时被触发,其他更新,比如扩容不会触发。
将nginx的pod由nginx:1.9.1代替nginx:1.7.9
kubectl set image deployment/ngiinx nginx=nginx:1.9.1
还有一种方法使用edit命令编辑Deployment来修改
.spec.template.spec.containers.image,将nginx:1.7.9改为nginx:1.9.1。
kubectl edit deployment/nginx(只能改hash值,其他不能改,改了也没有然后wq退出)
原理:
当我们更新Deployment时,会新建立一个ReplicaSet,将他扩容一个,将之前的缩容到两个,满足两个pod可用,接着持续使用rolling upfate 策略扩容,最后变成3个新的pod,旧的ReplicaSet数目为0
2、回滚Deployment
当Deployment不稳定的时候,有可能回退到上一个版本
默认,kubernetes会保留Deployment的rollout历史记录,以便你随时回退(可以修改revision history limit 来更改保存的revision数量)
只有Deployment的rollout被触发就会创建一个revision,仅当pod的template被更改才会。
其他更新如:扩容Deployment不会创建
检查eployment升级记录
3、Deployment扩容
=====扩容命令
kubectl scale deployment nginx --replicas 10
=======基于hpa的动态扩缩容
kubectl autoscal deployment nginx --min=10 --max=15 --cpu-percent=80
=======比例扩容(允许同时运行多个版本)
举例:正在运行的10个replica的Deployment
maxSurge=3 maxUnavoidable=2
我现在发起新的deployment扩容请求,replica数目增加至15个,Deployment就会判断这replica的实际归属(假如没有比例扩容,那么5个replica都会添加到新的ReplicaSet),将三个添加到数目少的ReplicaSet中,2个添加到新的replicaSet中。
4、暂停和恢复
目的:可以触发一次或多次更新,在此期间的工作,不会触发rollout
暂停:kubectl rollout pause deployment/nginx
恢复:kubectl rollout resume deploy nginx
注意:恢复之前无法回退暂停的Deployment
5、Deployment的状态
(1)progressing Deployment
Deployment正在创建ReplicaSet过程
DEployment正在扩容(缩容)已有的REplicaSet
有新的pod出现
通过kubectl rollout status 监控进度
(2)Complete Deployment
DEployment最小可用,可用的replica个数超过策略中个数
Department相关的replica都被更新到指定版本,就是更新完成
Deployment没有旧的pod
kubectl rollout status查看是否完成,完成返回值为0
(3)
无效的引用
不可读的probe failure
镜像拉取错误
权限不够
范围限制
程序运行配置错误
探测这种情况就是在DEploymet spec中指定progressDeadlineSeconds表示等待多少秒确定进程卡住,自行添加时间
6、DEployment的策略
(1)Recreate Deployment
.spec.strategy.type=Recreate时,在创建出新的pod之前杀死所有已存在pod
(2)Rolling Update Deployment
.spec.stratege.type==RollingUpdate时,指定maxUnavailable和maxSurge控制rollout upate进程
Max Uavailable :指定升级过程中不可用的pod最大数(可以是百分比也可以是绝对值),通过百分比的绝对值向下取整数。
假设,该值设置为30%,启动后rolling update后,旧的replicaset会缩容到期望数量的70%,逐渐更替,但期望值至少是70%
Max Surge:用来指定超过期望的最大个数(通过绝对值向上取整数)
假设,该值为30%,启动rolling update后,新的relicaset会立即扩容,新老pod的总数不能超过期望值的130%,旧的被杀掉后,新的继续扩容,确保pod的数量总和不会超过期望值。
Revision History Limit:保留可回退的旧的Replicaset的数量,一旦删除就无法回退了
Pause:用来指定暂停和恢复,所有paused deployment中的PodTemmolatespec的修改不会触发rollout更新,Deployment被创建默认paused
服务发现和负载均衡
Service是对一组相同功能的pods的额抽象,为他们提供统一的入口,service通过标签来选取服务的后端,一般配合RElication controller或者Deployment来保证后端容器的正常运行。这些匹配标签的pod IP和后端列表组成endpoints,由kube-proxy负责将IP负载均衡到endpoints上。
Sevicice的四种类型
(1)Cluster IP :默认类型,自动分配一个仅cluster内部可以访问的虚拟ip
(2)NodePort:在Cluster IP基础上Service在每台机器绑定一个端口,这样就可以通过NodePort来访问该服务。如果kube-proxy设置了--nideport addresses=10.240.0.016,那么nodeport仅在范围ip有效
(3)LoadBalancer:在Noeport基础上,借助cloud provider创建一个负载均衡,并将请求转发到nodeport
(4)ExternalName:将服务通过DNS CNAME记录方式转发到指定域名(通过spec.externlName设定)需要kube-proxy版本1。7以上。
DaemonSet:保证每一个pod上都运行1一个容器副本,常用来部署一些集群日志、监控或者其他的系统管理应用。
包括:
(1)日志收集,比如fluentd,logstash
(2)监控系统,比如Prometheus Noe Exporter
(3)系统程序,比如kube-proxy kube-dns
Daemonset滚动更新,通过.spec.updateStrategy.type设置策略
OnDelete:默认策略,更新模板后,只有手动删除旧的pod才会创建新的策略
RollingUpdate:更新DaemonSet模板后,自动删除旧的pod并创建新的pod
查看历史版本kubectl rollout history daemonset nginx
回滚kubectl rollout undo daemonset nginx --to-revision=2
查看回滚状态kubectl rollout status ds/nginx
指定node节点
Daemonset会忽略node的unschedulable状态,并指定pod只运行在特定node
=====nodeSelector:只调度到指定label的node上
====nodeAffinity:功能更丰富的node选择器,比如支持集合操作
====podAffinity:调度到满足条件的node上
nodeSelector示例
(1)首先给node打上标签
kubectl label node node-01 disktype=ssd
然后在daemonSet中指定nodeSelector为disktype=ssd
spec:
nodeSelector:
disktype:ssd
(2)nodeAffinity示例
目前支持两种:requireDuringSchedulingIgnoredDuringExecution和preferredDuringSchedulingIgnoredDuringExecution,分别代表满足条件和优选条件。
==比如下面例子代表调度到标签kubernetes.io/e2e-az-name,并且值为e2e-az1或e2
e-az2的node上,并且优选还带有标签another-node-label-key=another-node-label
value 的 Node
apiVersion: v1
kind: Pod
metadata:
name: with-node-affinity
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution: #必须满足
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/e2e-az-name
operator: In
values:
- e2e-az1
- e2e-az2
preferredDuringSchedulingIgnoredDuringExecution: #优选
- weight: 1
preference:
matchExpressions:
- key: another-node-label-key
operator: In
values:
- another-node-label-value
containers:
- name: with-node-affinity
image: gcr.io/google_containers/pause:2.0
(3)podAffinity示例
基于pod的标签来选择node,仅调度到满足条件pod所在的node上,支持podAffinity和podAntiAffinity
如果一个“node”所在的zoon中至少一个带有security=S1标签且运行中的pod,那么可以调度到该node
不调度到至少带有security=S2标签且运行的pod的node上
本文作者:寻仙阁
本文链接:https://www.cnblogs.com/wxfboke/p/16832970.html
版权声明:本作品采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行许可。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
· 上周热点回顾(2.17-2.23)