项目的发布方式和容器的重启策略

2024-08-29 16:28

本文主要是介绍项目的发布方式和容器的重启策略,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

项目的发布方式:

应用升级以及新旧业务切换,在这个过程当中如何保证对外的服务正常是一个非常重要的问题。

三种的发布方式:

1、蓝绿发布:

把服务器分为蓝组和绿组,先停其中的一部分,先停蓝组,绿组依然对外提供服务,等蓝组更新维护完毕,上线之后,再把绿组关闭维护。可以做到业务更新和发布过程的对外服务不受影响。

过去成本很高,

负载均衡+高可用

特点:一旦出现问题,影响范围比较大

发布策略也比较简单

用户无感知,平滑过渡

缺点:需要大量的后台服务器以作为支撑。成本还是比较高的

2、金丝雀发布:

金丝雀发布就是先整个测试服测试版本,先打上断点,版本没问题就可以取消断点进行滚动更新,删除所有旧版本,加上一个新版本

金丝雀发布:灰度发布。

Deployment控制器可以通过自定义控制的方式实现金丝雀发布。

[root@master01 ~]# kubectl create deployment nginx1 --image=nginx:1.12 --replicas=3     #创建pod
​
[root@master01 ~]# kubectl set image deployment/nginx1 nginx=nginx:1.22 && kubectl rollout pause deployment nginx1                      #创建一个测试服
​
[root@master01 ~]# kubectl rollout resume deployment/nginx1             #测试服没有问题,更新版本

自动化控制的要求很高。整个系统的稳定性比蓝绿发布要高。影响范围可控。

3、pod的默认形式,滚动发布,

部署时间比较慢,但是节约资源。发布的策略也比较复杂。

声明式的管理方式:

yaml文件实现:

yaml文件:
deployment的部署方式:
[root@master01 k8s-yaml]# vim nginx-deploy.yaml
#aip版本的标签
aipVersion: apps/v1
kind: Deployment
#定义资源的类型/角色 kind的类型:Deployment  Job Ingress Service  Deamonset
metadata:
#定义创建资源的元数据信息,资源的名称————pod的名称,命名空间,pod的标签name: nginx1
#  namepaces:               #定义命名空间,不写就是默认命名空间labels:app: nginx1
#标签名:app=nginx1 上下文要一致
spec:
#顶格写属于全局配置,spec配置deployment资源需要的参数属性。副本数,匹配的标签以及容器的重启策略replicas: 3
#定义该资源pod的数量selector:matchLabels:
#selector用来定义标签的选择器,matchLabels用来定义匹配的标签,这里需要上下文保持一致。app: nginx1
#都是定义容器和pod的元数据template:
#定义业务模板,定义了3个副本,所有的pod的属性都会和template的设置保持一致metadata:labels:app: nginx1
#这里也需要和上下文保持一致spec:
#定义pod内的容器containers:- name: nginximage: nginx:1.22
#--image=nginx:1.22
#        ports:
#        - containerPort: 8080
#如果nginx的端口是默认的就是80,ports可以不写,写了也无法改变容器内的端口。
#如果默认端口不是80,那就需要加上ports声明非默认端口。
[root@master01 k8s-yaml]# kubectl apply -f nginx-deploy.yaml            #创建资源对象
​
[root@master01 k8s-yaml]# kubectl delete -f nginx-deploy.yaml           #删除资源对象

pod和容器是分开的也是合并的。镜像定义容器。pod不能改变镜像

service的部署方式:
[root@master01 k8s-yaml]# vim nginx-service.yaml 
#定义api标签:
apiVersion: v1
kind: Service
metadata:
#定义service的名称和标签name: nginx1-svclabels:app1: nginx1
spec:
#定义service的资源参数,端口映射,类型、匹配的标签名(和哪个资源对象进行匹配)type: NodePortports:- port: 80
#service的端口targetPort: 80
#容器内的端口nodePort: 30000selector:app: nginx1[root@master01 k8s-yaml]# kubectl apply -f nginx-service.yaml 
pod的部署方式:
[root@master01 k8s-yaml]# vim nginx-pod.yaml
apiVersion: v1
kind: Pod
metadata:name: nginx-podlabels:app: nginx-pod
spec:
#声明容器的参数containers:- name: nginximage: nginx:1.22ports:- containerPort: 80hostPort: 80
#主机端口,直接让主机端口和容器端口做映射(只能在yaml文件当中表示)
​
[root@master01 k8s-yaml]# kubectl apply -f nginx-pod.yaml pod/nginx-pod created
[root@master01 k8s-yaml]# kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE    IP            NODE     NOMINATED NODE   READINESS GATES
nginx-pod                1/1     Running   0          13s    10.244.1.42   node02   <none>           <none>
nginx1-b666bdb8c-67tkt   1/1     Running   0          104m   10.244.2.40   node01   <none>           <none>
nginx1-b666bdb8c-pltdv   1/1     Running   0          104m   10.244.2.41   node01   <none>           <none>
nginx1-b666bdb8c-wzw7q   1/1     Running   0          104m   10.244.1.41   node02   <none>           <none>
[root@master01 k8s-yaml]# curl 192.168.60.130
123

容器的重启策略和传参

重启策略

restartPolicy:

Always 只要启动失败就会一直重启容器

Never 从不重启 docker的默认模式

OnFailure 只有容器异常退出时,才会重启。返回码非0时,才会对容器进行重启。

Always:
[root@master01 k8s-yaml]# vim centos-pod.yaml 
apiVersion: v1
kind: Pod
metadata:name: centos-podlabels:app: centos-pod
spec:
#声明容器的参数containers:- name: centosimage: centos:7ports:- containerPort: 80hostPort: 80restartPolicy: Always
#主机端口,直接让主机端口和容器端口做映射(只能在yaml文件当中表示)
[root@master01 k8s-yaml]# kubectl apply -f nginx-centos.yaml 
[root@master01 k8s-yaml]# kubectl get pod
NAME                     READY   STATUS             RESTARTS   AGE
centos-pod               0/1     CrashLoopBackOff   1          77s

Never
apiVersion: v1
kind: Pod
metadata:name: centos-podlabels:app: centos-pod
spec:
#声明容器的参数containers:- name: centosimage: centos:7ports:- containerPort: 80hostPort: 80restartPolicy: Never[root@master01 k8s-yaml]# kubectl apply -f nginx-pod.yaml pod/centos-pod created
[root@master01 k8s-yaml]# kubectl get pod
NAME         READY   STATUS      RESTARTS   AGE
centos-pod   0/1     Completed   0          3s

总结:

如果是deployment,那么容器只能是Always,默认就是Always,可以不写。

基于pod的yaml文件,三种类型都可以。

pod内的传参:

command和args

在yaml文件当中command和arges只能各存在一个。

agres可以给command传参

写法一:
apiVersion: v1
kind: Pod
metadata:name: centos-podlabels:app: centos-pod
spec:
#声明容器的参数containers:- name: centosimage: centos:7ports:- containerPort: 80hostPort: 80args:- /bin/bash- -c- while true; do sleep 3600; done
[root@master01 k8s-yaml]# kubectl apply -f nginx-pod.yaml --force               #pod的yaml会有这种重复,提示有内容没有发生变化,需要加--force强制执行。
[root@master01 k8s-yaml]# kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
centos-pod               1/1     Running   0          9s
写法二:
apiVersion: v1
kind: Pod
metadata:name: centos-podlabels:app: centos-pod
spec:
#声明容器的参数containers:- name: centosimage: centos:7ports:- containerPort: 80hostPort: 80args: ["/bin/bash","-c","while true;do sleep 3600;done"][root@master01 k8s-yaml]# kubectl apply -f nginx-pod.yaml --force
[root@master01 k8s-yaml]# kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
centos-pod               1/1     Running   0          4s
​

    args: ["/bin/bash","-c","touch /opt/123.txt;echo 123 > /opt/123.txt; sleep 3600"]#/bin/bash 多个命令必须要加/bin/bash
#-c 输出命令的格式
#多个命令 /bin/bash  -c  都需要
#主机端口,直接让主机端口和容器端口做映射(只能在yaml文件当中表示)

command的用法:

 args: ["/bin/bash","-c","touch /opt/123.txt;echo 123 > /opt/123.txt; sleep 3600"]

args给command传参:

apiVersion: v1
kind: Pod
metadata:name: centos-podlabels:app: centos-pod
spec:
#声明容器的参数containers:- name: centosimage: centos:7ports:- containerPort: 80hostPort: 80command: ["echo"]args: ["hello word"][root@master01 k8s-yaml]# kubectl logs -f centos-pod 
hello word

总结:

command和args如果不需要传参只能存在一个

不论是args还是command都会覆盖容器的标准输出(类似CMD和entrypoint)

导出模板:

#先创建一个pod
[root@master01 k8s-yaml]# kubectl create deployment nginx-de --image=nginx-1.22 --replicas=3#将pod的模板导入到/opt/k8s-yaml/目录下
[root@master01 k8s-yaml]# kubectl get deployments.apps nginx-de -o yaml > /opt/k8s-yaml/nginx-de.yaml

这篇关于项目的发布方式和容器的重启策略的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1118364

相关文章

gradle第三方Jar包依赖统一管理方式

《gradle第三方Jar包依赖统一管理方式》:本文主要介绍gradle第三方Jar包依赖统一管理方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录背景实现1.顶层模块build.gradle添加依赖管理插件2.顶层模块build.gradle添加所有管理依赖包

Linux之systemV共享内存方式

《Linux之systemV共享内存方式》:本文主要介绍Linux之systemV共享内存方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、工作原理二、系统调用接口1、申请共享内存(一)key的获取(二)共享内存的申请2、将共享内存段连接到进程地址空间3、将

Maven中引入 springboot 相关依赖的方式(最新推荐)

《Maven中引入springboot相关依赖的方式(最新推荐)》:本文主要介绍Maven中引入springboot相关依赖的方式(最新推荐),本文给大家介绍的非常详细,对大家的学习或工作具有... 目录Maven中引入 springboot 相关依赖的方式1. 不使用版本管理(不推荐)2、使用版本管理(推

C#使用StackExchange.Redis实现分布式锁的两种方式介绍

《C#使用StackExchange.Redis实现分布式锁的两种方式介绍》分布式锁在集群的架构中发挥着重要的作用,:本文主要介绍C#使用StackExchange.Redis实现分布式锁的... 目录自定义分布式锁获取锁释放锁自动续期StackExchange.Redis分布式锁获取锁释放锁自动续期分布式

Java对象转换的实现方式汇总

《Java对象转换的实现方式汇总》:本文主要介绍Java对象转换的多种实现方式,本文通过实例代码给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录Java对象转换的多种实现方式1. 手动映射(Manual Mapping)2. Builder模式3. 工具类辅助映

SpringBoot基于配置实现短信服务策略的动态切换

《SpringBoot基于配置实现短信服务策略的动态切换》这篇文章主要为大家详细介绍了SpringBoot在接入多个短信服务商(如阿里云、腾讯云、华为云)后,如何根据配置或环境切换使用不同的服务商,需... 目录目标功能示例配置(application.yml)配置类绑定短信发送策略接口示例:阿里云 & 腾

SpringBoot项目中报错The field screenShot exceeds its maximum permitted size of 1048576 bytes.的问题及解决

《SpringBoot项目中报错ThefieldscreenShotexceedsitsmaximumpermittedsizeof1048576bytes.的问题及解决》这篇文章... 目录项目场景问题描述原因分析解决方案总结项目场景javascript提示:项目相关背景:项目场景:基于Spring

解决Maven项目idea找不到本地仓库jar包问题以及使用mvn install:install-file

《解决Maven项目idea找不到本地仓库jar包问题以及使用mvninstall:install-file》:本文主要介绍解决Maven项目idea找不到本地仓库jar包问题以及使用mvnin... 目录Maven项目idea找不到本地仓库jar包以及使用mvn install:install-file基

Spring Boot读取配置文件的五种方式小结

《SpringBoot读取配置文件的五种方式小结》SpringBoot提供了灵活多样的方式来读取配置文件,这篇文章为大家介绍了5种常见的读取方式,文中的示例代码简洁易懂,大家可以根据自己的需要进... 目录1. 配置文件位置与加载顺序2. 读取配置文件的方式汇总方式一:使用 @Value 注解读取配置方式二

JAVA保证HashMap线程安全的几种方式

《JAVA保证HashMap线程安全的几种方式》HashMap是线程不安全的,这意味着如果多个线程并发地访问和修改同一个HashMap实例,可能会导致数据不一致和其他线程安全问题,本文主要介绍了JAV... 目录1. 使用 Collections.synchronizedMap2. 使用 Concurren