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

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

相关文章

Golang实现基于角色的访问控制(RBAC)的项目实践

《Golang实现基于角色的访问控制(RBAC)的项目实践》基于角色的访问控制(RBAC)是一种安全机制,通过角色来管理用户权限,本文介绍了一种可落地、易扩展的GolangRBAC实现方案,具有一定... 目录一、RBAC 核心模型设计二、RBAC 核心逻辑实现RBAC 管理器定义基础 CRUD:添加用户

SpringBoot项目jar依赖问题报错解析

《SpringBoot项目jar依赖问题报错解析》本文主要介绍了SpringBoot项目中常见的依赖错误类型、报错内容及解决方法,依赖冲突包括类找不到、方法找不到、类型转换异常等,本文给大家介绍的非常... 目录常见依赖错误类型及报错内容1. 依赖冲突类错误(1) ClassNotFoundExceptio

python在word中插入目录和更新目录实现方式

《python在word中插入目录和更新目录实现方式》文章主要介绍了如何在Word文档中插入和更新目录,并提供了具体的代码示例,插入目录时,需要使用`TablesOfContents`对象,并设置使用... 目录1、插入目录2、更新目录总结1、插入目录需要用到对象:TablesOfContents目录的

Java中Map的五种遍历方式实现与对比

《Java中Map的五种遍历方式实现与对比》其实Map遍历藏着多种玩法,有的优雅简洁,有的性能拉满,今天咱们盘一盘这些进阶偏基础的遍历方式,告别重复又臃肿的代码,感兴趣的小伙伴可以了解下... 目录一、先搞懂:Map遍历的核心目标二、几种遍历方式的对比1. 传统EntrySet遍历(最通用)2. Lambd

Django调用外部Python程序的完整项目实战

《Django调用外部Python程序的完整项目实战》Django是一个强大的PythonWeb框架,它的设计理念简洁优雅,:本文主要介绍Django调用外部Python程序的完整项目实战,文中通... 目录一、为什么 Django 需要调用外部 python 程序二、三种常见的调用方式方式 1:直接 im

Spring Boot 处理带文件表单的方式汇总

《SpringBoot处理带文件表单的方式汇总》本文详细介绍了六种处理文件上传的方式,包括@RequestParam、@RequestPart、@ModelAttribute、@ModelAttr... 目录方式 1:@RequestParam接收文件后端代码前端代码特点方式 2:@RequestPart接

Springboot配置文件相关语法及读取方式详解

《Springboot配置文件相关语法及读取方式详解》本文主要介绍了SpringBoot中的两种配置文件形式,即.properties文件和.yml/.yaml文件,详细讲解了这两种文件的语法和读取方... 目录配置文件的形式语法1、key-value形式2、数组形式读取方式1、通过@value注解2、通过

java中4种API参数传递方式统一说明

《java中4种API参数传递方式统一说明》在Java中,我们可以使用不同的方式来传递参数给方法或函数,:本文主要介绍java中4种API参数传递方式的相关资料,文中通过代码介绍的非常详细,需要的... 目录1. 概述2. 参数传递方式分类2.1 Query Parameters(查询参数)2.2 Path

Python容器转换与共有函数举例详解

《Python容器转换与共有函数举例详解》Python容器是Python编程语言中非常基础且重要的概念,它们提供了数据的存储和组织方式,下面:本文主要介绍Python容器转换与共有函数的相关资料,... 目录python容器转换与共有函数详解一、容器类型概览二、容器类型转换1. 基本容器转换2. 高级转换示

MybatisPlus中几种条件构造器运用方式

《MybatisPlus中几种条件构造器运用方式》QueryWrapper是Mybatis-Plus提供的一个用于构建SQL查询条件的工具类,提供了各种方法如eq、ne、gt、ge、lt、le、lik... 目录版本介绍QueryWrapperLambdaQueryWrapperUpdateWrapperL