kubernetes k8s Deployment 控制器配置管理 k8s 红蓝部署 金丝雀发布

目录

1、Deployment控制器:概念、原理解读

1.1  Deployment概述

1.2  Deployment工作原理:如何管理rs和Pod?

2、Deployment资源清单文件编写技巧

3、Deployment使用案例:创建一个web站点

4、Deployment管理pod:扩容、缩容

5、通过k8s实现滚动更新

5.1 滚动更新简介

5.2 在k8s中实现金滚动更新

5.3 自定义滚动更新策略

6、生产环境如何实现蓝绿部署?

6.1、什么是蓝绿部署?

6.2、蓝绿部署的优势和缺点

6.3 通过k8s实现线上业务的蓝绿部署

7、通过k8s完成线上业务的金丝雀发布

7.1 金丝雀发布简介

7.2 在k8s中实现金丝雀发布


文档中的YAML文件配置直接复制粘贴可能存在格式错误,故实验中所需要的YAML文件以及本地包均打包至网盘

链接:https://pan.baidu.com/s/1S0pKG35ozpg4hmSz-MzTqA 
提取码:bzwm 

作者:韩先超老师

1、Deployment控制器:概念、原理解读

Deployment官方文档:

Deployments | KubernetesA Deployment manages a set of Pods to run an application workload, usually one that doesn't maintain state.icon-default.png?t=N7T8https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

1.1  Deployment概述

Deployment是kubernetes中最常用的资源对象,为ReplicaSet和Pod的创建提供了一种声明式的定义方法,在Deployment对象中描述一个期望的状态,Deployment控制器就会按照一定的控制速率把实际状态改成期望状态,通过定义一个Deployment控制器会创建一个新的ReplicaSet控制器,通过ReplicaSet创建pod,删除Deployment控制器,也会删除Deployment控制器下对应的ReplicaSet控制器和pod资源.

 

使用Deployment而不直接创建ReplicaSet是因为Deployment对象拥有许多ReplicaSet没有的特性,例如滚动升级、金丝雀发布、蓝绿部署和回滚。

扩展:声明式定义是指直接修改资源清单yaml文件,然后通过kubectl apply -f 资源清单yaml文件,就可以更改资源

Deployment控制器是建立在rs之上的一个控制器,可以管理多个rs,每次更新镜像版本,都会生成一个新的rs,把旧的rs替换掉,多个rs同时存在,但是只有一个rs运行。

rs v1控制三个pod,删除一个pod,在rs v2上重新建立一个,依次类推,直到全部都是由rs v2控制,如果rs v2有问题,还可以回滚,Deployment是建构在rs之上的,多个rs组成一个Deployment,但是只有一个rs处于活跃状态.

1.2  Deployment工作原理:如何管理rs和Pod?

Deployment可以使用声明式定义,直接在命令行通过纯命令的方式完成对应资源版本的内容的修改,也就是通过打补丁的方式进行修改;Deployment能提供滚动式自定义自控制的更新;对Deployment来讲,我们在实现更新时还可以实现控制更新节奏和更新逻辑。

互动:什么叫做更新节奏和更新逻辑呢?

比如说Deployment控制5个pod副本,pod的期望值是5个,但是升级的时候需要额外多几个pod,那我们控制器可以控制在5个pod副本之外还能再增加几个pod副本;比方说能多一个,但是不能少,那么升级的时候就是先增加一个,再删除一个,增加一个删除一个,始终保持pod副本数是5个;还有一种情况,最多允许多一个,最少允许少一个,也就是最多6个,最少4个,第一次加一个,删除两个,第二次加两个,删除两个,依次类推,可以自己控制更新方式,这种滚动更新需要加readinessProbe和livenessProbe探测,确保pod中容器里的应用都正常启动了才删除之前的pod。

启动第一步,刚更新第一批就暂停了也可以;假如目标是5个,允许一个也不能少,允许最多可以10个,那一次加5个即可;这就是我们可以自己控制节奏来控制更新的方法。

通过Deployment对象,你可以轻松的做到以下事情:

1、创建ReplicaSet和Pod

2、滚动升级(不停止旧服务的状态下升级)和回滚应用(将应用回滚到之前的版本)

3、平滑地扩容和缩容

4、暂停和继续Deployment

2、Deployment资源清单文件编写技巧

#查看Deployment资源对象由哪几部分组成

[root@xianchaomaster1 ~]# kubectl explain deployment

KIND:     Deployment

VERSION:  apps/v1

DESCRIPTION:

     Deployment enables declarative updates for Pods and ReplicaSets.

FIELDS:

   apiVersion <string>  #该资源使用的api版本

   kind <string>            #创建的资源是什么?

   metadata  <Object>       #元数据,包括资源的名字和名称空间

   spec <Object>           #定义容器的

   status   <Object>       #状态,不可以修改

#查看Deployment下的spec字段

[root@xianchaomaster1 ~]# kubectl explain deployment.spec

KIND:     Deployment

VERSION:  apps/v1

RESOURCE: spec <Object>

DESCRIPTION:

     Specification of the desired behavior of the Deployment.

     DeploymentSpec is the specification of the desired behavior of the

     Deployment.

FIELDS:

    minReadySeconds   <integer>

#Kubernetes在等待设置的时间后才进行升级
#如果没有设置该值,Kubernetes会假设该容器启动起来后就提供服务了

paused  <boolean>  #暂停,当我们更新的时候创建pod先暂停,不是立即更新

    progressDeadlineSeconds <integer>

# k8s 在升级过程中有可能由于各种原因升级卡住(这个时候还没有明确的升级失败),比如在拉取被墙的镜像,权限不够等错误。那么这个时候就需要有个 deadline ,在 deadline 之内如果还卡着,那么就上报这个情况,这个时候这个 Deployment 状态就被标记为 False,并且注明原因。但是它并不会阻止 Deployment 继续进行卡住后面的操作。完全由用户进行控制。

    replicas <integer>  #副本数

    revisionHistoryLimit  <integer> #保留的历史版本,默认是10

    selector <Object> -required- #标签选择器,选择它关联的pod

    strategy <Object>     #更新策略

    template <Object> -required  #定义的pod模板

#查看Deployment下的spec.strategy字段

[root@xianchaomaster1 ~]# kubectl explain deploy.spec.strategy

KIND:     Deployment

VERSION:  apps/v1

RESOURCE: strategy <Object>

DESCRIPTION:

     The deployment strategy to use to replace existing pods with new ones.

     DeploymentStrategy describes how to replace existing pods with new ones.

FIELDS:

   rollingUpdate <Object>

   type <string>

     Type of deployment. Can be "Recreate" or "RollingUpdate". Default is

     RollingUpdate.

#支持两种更新,Recreate和RollingUpdate

#Recreate是重建式更新,删除一个更新一个

#RollingUpdate滚动更新,定义滚动更新方式,也就是pod能多几个,少几个

#查看Deployment下的spec.strategy.rollingUpdate字段

[root@xianchaomaster1 ~]# kubectl explain deploy.spec.strategy.rollingUpdate

KIND:     Deployment

VERSION:  apps/v1

RESOURCE: rollingUpdate <Object>

DESCRIPTION:

     Rolling update config params. Present only if DeploymentStrategyType =

     RollingUpdate.

     Spec to control the desired behavior of rolling update.

FIELDS:

   maxSurge  <string>

#我们更新的过程当中最多允许超出的指定的目标副本数有几个;

它有两种取值方式,第一种直接给定数量,第二种根据百分比,百分比表示原本是5个,最多可以超出20%,那就允许多一个,最多可以超过40%,那就允许多两个

   maxUnavailable <string>

#最多允许几个不可用

假设有5个副本,最多一个不可用,就表示最少有4个可用

replicas: 5

maxSurge: 25%         5*25%=1.25  ->5+2=7

maxUnavailable: 25%    5%25%=1.25  -> 5-1=4

#查看Deployment下的spec.template字段

#template为定义Pod的模板,Deployment通过模板创建Pod

[root@xianchaomaster1 ~]# kubectl explain deploy.spec.template

KIND:     Deployment

VERSION:  apps/v1

RESOURCE: template <Object>

DESCRIPTION:

     Template describes the pods that will be created.

     PodTemplateSpec describes the data a pod should have when created from a template

FIELDS:

   metadata  <Object>  #定义模板的名字

   spec <Object>  

deployment.spec.template为Pod定义的模板,和Pod定义不太一样,template中不包含apiVersion和Kind属性,要求必须有metadata。deployment.spec.template.spec为容器的属性信息,其他定义内容和Pod一致。


 

3、Deployment使用案例:创建一个web站点

deployment是一个三级结构,deployment管理replicaset,replicaset管理pod,

例子:用deployment创建一个pod

#把myapp-blue-v1.tar.gz和myapp-blue-v2.tar.gz上传到xianchaonode1和xianchaonode2上,手动解压:

[root@xianchaonode1 ~]# ctr -n=k8s.io images import  myapp-blue-v1.tar.gz

[root@xianchaonode2 ~]# ctr -n=k8s.io images import  myapp-blue-v1.tar.gz

[root@xianchaonode1 ~]# ctr -n=k8s.io images import  myapp-blue-v2.tar.gz

[root@xianchaonode2 ~]# ctr -n=k8s.io images import  myapp-blue-v2.tar.gz

[root@xianchaomaster1]# cat deploy-demo.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: myapp-v1

spec:

  replicas: 2

  selector:

    matchLabels:

      app: myapp

      version: v1

  template:

    metadata:

      labels:

         app: myapp

         version: v1

    spec:

      containers:

      - name: myapp

        image: janakiramm/myapp:v1

        imagePullPolicy: IfNotPresent

        ports:

        - containerPort: 80

        startupProbe:

           periodSeconds: 5

           initialDelaySeconds: 20

           timeoutSeconds: 10

           httpGet:

             scheme: HTTP

             port: 80

             path: /

        livenessProbe:

           periodSeconds: 5

           initialDelaySeconds: 20

           timeoutSeconds: 10

           httpGet:

             scheme: HTTP

             port: 80

             path: /

        readinessProbe:

           periodSeconds: 5

           initialDelaySeconds: 20

           timeoutSeconds: 10

           httpGet:

             scheme: HTTP

             port: 80

             path: /

更新资源清单文件:

kubectl apply -f deploy-demo.yaml

#kubectl apply:表示声明式的定义,既可以创建资源,也可以动态更新资源

查看deploy状态:

kubectl get deploy

显示如下:

NAME       READY   UP-TO-DATE   AVAILABLE   AGE

myapp-v1     2/2      2               2           60s

1.NAME :列出名称空间中deployment的名称。

2.READY:显示deployment有多少副本数。它遵循ready/desired的模式。

3.UP-TO-DATE: 显示已更新到所需状态的副本数。

4.AVAILABLE: 显示你的可以使用多少个应用程序副本。

5.AGE :显示应用程序已运行的时间。

kubectl get rs 显示如下:

创建的控制器名字是myapp-v1

kubectl get rs

显示如下:

AME                     DESIRED   CURRENT   READY   AGE

myapp-v1-67fd9fc9c8     2         2            2       2m35s

#创建deploy的时候也会创建一个rs(replicaset),67fd9fc9c8 这个随机数字是我们引用pod的模板template的名字的hash值

1.NAME: 列出名称空间中ReplicaSet资源

2.DESIRED:显示应用程序的所需副本数,这些副本数是在创建时定义的。这是所需的状态。

3.CURRENT: 显示当前正在运行多少个副本。

4.READY: 显示你的用户可以使用多少个应用程序副本。

5.AGE :显示应用程序已运行的时间。

请注意,ReplicaSet的名称始终设置为[DEPLOYMENT-NAME]-[RANDOM-STRING]。RANDOM-STRING是随机生成的

kubectl get pods

显示如下:

myapp-v1-67fd9fc9c8-fcprr   1/1     Running   0           3s

myapp-v1-67fd9fc9c8-hw4f9   1/1     Running   0          2m21s

[root@xianchaomaster1 ~]# kubectl get pods -o wide | grep myapp

myapp-v1-67fd9fc9c8-fcprr   1/1   Running  0    10.244.187.78   xianchaonode2  

myapp-v1-67fd9fc9c8-hw4f9  1/1   Running   0   10.244.209.136  xianchaonode1  

#请求刚才创建的pod资源

[root@xianchaomaster1 ~]# curl 10.244.187.78

      …

      background-color: blue;

[root@xianchaomaster1 ~]# curl 10.244.209.136

      …

      background-color: blue;

#Deployment资源清单文件详细解读

apiVersion: apps/v1  #deployment对应的api版本

kind: Deployment    #创建的资源是deployment

metadata:

  name: myapp-v1   #deployment的名字

spec:

  replicas: 2     #deployment管理的pod副本数

  selector:       #标签选择器

   matchLabels:  # matchLabels下定义的标签需要跟template.metadata.labels定义的标签一致

    app: myapp

    version: v1

  template:

   metadata:

    labels:

     app: myapp

     version: v1

   spec:   #定义容器的属性

    containers: 

    - name: myapp

      image: janakiramm/myapp:v1 #容器使用的镜像

      imagePullPolicy: IfNotPresent  #镜像拉取策略

      ports:

      - containerPort: 80     #容器里的应用的端口

4、Deployment管理pod:扩容、缩容

#通过deployment管理应用,实现扩容,把副本数变成3

[root@xianchaomaster1 ~]# cat  deploy-demo.yaml

直接修改replicas数量,如下,变成3

spec:

  replicas: 3

修改之后保存退出,执行

[root@xianchaomaster1 ~]# kubectl apply -f deploy-demo.yaml

注意:apply不同于create,apply可以执行多次;create执行一次,再执行就会报错复。

kubectl get pods

显示如下:

NAME                         READY   STATUS    RESTARTS   AGE

myapp-v1-67fd9fc9c8-fcprr   1/1     Running   0          15m

myapp-v1-67fd9fc9c8-h9js5   1/1     Running   0          11s

myapp-v1-67fd9fc9c8-hw4f9   1/1     Running   0          17m

#上面可以看到pod副本数变成了3个

#查看myapp-v1这个控制器的详细信息

[root@xianchaomaster1 ~]# kubectl describe deploy myapp-v1

Name:                   myapp-v1

Namespace:              default

CreationTimestamp:      Tue, 30 Mar 2021 12:59:02 +0800

Labels:                 <none>

Annotations:            deployment.kubernetes.io/revision: 1

Selector:               app=myapp,version=v1

Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable

StrategyType:           RollingUpdate

MinReadySeconds:        0

RollingUpdateStrategy:  25% max unavailable, 25% max surge

Pod Template:

  Labels:  app=myapp

           version=v1

  Containers:

   myapp:

    Image:        janakiramm/myapp:v1

    Port:         80/TCP

    Host Port:    0/TCP

    Environment:  <none>

    Mounts:       <none>

  Volumes:        <none>

Conditions:

  Type           Status  Reason

  ----           ------  ------

  Progressing    True    NewReplicaSetAvailable

  Available      True    MinimumReplicasAvailable

OldReplicaSets:  <none>

NewReplicaSet:   myapp-v1-67fd9fc9c8 (3/3 replicas created)

Events:

  Type    Reason             Age   From                   Message

  ----    ------             ----  ----                   -------

  Normal  ScalingReplicaSet  18m   deployment-controller  Scaled up replica set myapp-v1-67fd9fc9c8 to 2

  Normal  ScalingReplicaSet  51s   deployment-controller  Scaled up replica set myapp-v1-67fd9fc9c8 to 3

#通过deployment管理应用,实现缩容,把副本数变成2

[root@xianchaomaster1 ~]# cat  deploy-demo.yaml

直接修改replicas数量,如下,变成2

spec:

  replicas: 2

修改之后保存退出,执行

[root@xianchaomaster1 ~]# kubectl apply -f deploy-demo.yaml

[root@xianchaomaster1 ~]# kubectl get pods

NAME                         READY   STATUS    RESTARTS   AGE

myapp-v1-67fd9fc9c8-fcprr    1/1     Running   0          18m

myapp-v1-67fd9fc9c8-hw4f9   1/1     Running   0          20m

5、通过k8s实现滚动更新

5.1 滚动更新简介

滚动更新是一种自动化程度较高的发布方式,用户体验比较平滑,是目前成熟型技术组织所采用的主流发布方式,一次滚动发布一般由若干个发布批次组成,每批的数量一般是可以配置的(可以通过发布模板定义),例如第一批1台,第二批10%,第三批50%,第四批100%。每个批次之间留观察间隔,通过手工验证或监控反馈确保没有问题再发下一批次,所以总体上滚动式发布过程是比较缓慢的

10个pod:

第一我更新1个pod:

第二次更新:1个

第三次更新:5个

第四次:3个

5.2 在k8s中实现金滚动更新

首先看下Deployment资源对象的组成:

[root@xianchaomaster1 ~]# kubectl explain deployment

[root@xianchaomaster1 ~]# kubectl explain deployment.spec

KIND:     Deployment

VERSION:  apps/v1

RESOURCE: spec <Object>

DESCRIPTION:

     Specification of the desired behavior of the Deployment.

     DeploymentSpec is the specification of the desired behavior of the

     Deployment.

FIELDS:

   minReadySeconds <integer>

     Minimum number of seconds for which a newly created pod should be ready

     without any of its container crashing, for it to be considered available.

     Defaults to 0 (pod will be considered available as soon as it is ready)

   paused <boolean>

     Indicates that the deployment is paused.

#暂停,当我们更新的时候创建pod先暂停,不是立即更新

   progressDeadlineSeconds  <integer>

     The maximum time in seconds for a deployment to make progress before it is

     considered to be failed. The deployment controller will continue to process

     failed deployments and a condition with a ProgressDeadlineExceeded reason

     will be surfaced in the deployment status. Note that progress will not be

     estimated during the time a deployment is paused. Defaults to 600s.

   replicas   <integer>

     Number of desired pods. This is a pointer to distinguish between explicit

     zero and not specified. Defaults to 1.

   revisionHistoryLimit <integer>

#保留的历史版本数,默认是10个

     The number of old ReplicaSets to retain to allow rollback. This is a

     pointer to distinguish between explicit zero and not specified. Defaults to

     10.

   selector   <Object> -required-

     Label selector for pods. Existing ReplicaSets whose pods are selected by

     this will be the ones affected by this deployment. It must match the pod

     template's labels.

   strategy   <Object>

#更新策略,支持的滚动更新策略

     The deployment strategy to use to replace existing pods with new ones.

   template   <Object> -required-

     Template describes the pods that will be created.

kubectl explain deploy.spec.strategy

KIND:     Deployment

VERSION:  apps/v1

RESOURCE: strategy <Object>

DESCRIPTION:

     The deployment strategy to use to replace existing pods with new ones.

     DeploymentStrategy describes how to replace existing pods with new ones.

FIELDS:

   rollingUpdate  <Object>

     Rolling update config params. Present only if DeploymentStrategyType =

     RollingUpdate.

   type  <string>

     Type of deployment. Can be "Recreate" or "RollingUpdate". Default is

     RollingUpdate.

#支持两种更新,Recreate和RollingUpdate

#Recreate是重建式更新,删除一个更新一个

#RollingUpdate 滚动更新,定义滚动更新的更新方式的,也就是pod能多几个,少几个,控制更新力度的

kubectl explain deploy.spec.strategy.rollingUpdate

KIND:     Deployment

VERSION:  apps/v1

RESOURCE: rollingUpdate <Object>

DESCRIPTION:

     Rolling update config params. Present only if DeploymentStrategyType =

     RollingUpdate.

     Spec to control the desired behavior of rolling update.

FIELDS:

   maxSurge   <string>

     The maximum number of pods that can be scheduled above the desired number

     of pods. Value can be an absolute number (ex: 5) or a percentage of desired

     pods (ex: 10%). This can not be 0 if MaxUnavailable is 0. Absolute number

     is calculated from percentage by rounding up. Defaults to 25%. Example:

     when this is set to 30%, the new ReplicaSet can be scaled up immediately

     when the rolling update starts, such that the total number of old and new

     pods do not exceed 130% of desired pods. Once old pods have been killed,

     new ReplicaSet can be scaled up further, ensuring that total number of pods

     running at any time during the update is at most 130% of desired pods.

#我们更新的过程当中最多允许超出的指定的目标副本数有几个;

它有两种取值方式,第一种直接给定数量,第二种根据百分比,百分比表示原本是5个,最多可以超出20%,那就允许多一个,最多可以超过40%,那就允许多两个

   maxUnavailable <string>

     The maximum number of pods that can be unavailable during the update. Value

     can be an absolute number (ex: 5) or a percentage of desired pods (ex:

     10%). Absolute number is calculated from percentage by rounding down. This

     can not be 0 if MaxSurge is 0. Defaults to 25%. Example: when this is set

     to 30%, the old ReplicaSet can be scaled down to 70% of desired pods

     immediately when the rolling update starts. Once new pods are ready, old

     ReplicaSet can be scaled down further, followed by scaling up the new

     ReplicaSet, ensuring that the total number of pods available at all times

     during the update is at least 70% of desired pods.

#最多允许几个不可用

假设有5个副本,最多一个不可用,就表示最少有4个可用

deployment是一个三级结构,deployment控制replicaset,replicaset控制pod,

[root@xianchaomaster1 ~]# cat  deploy-demo.yaml

直接修改replicas数量,如下,变成3

spec:

  replicas: 3

修改之后保存退出,执行

[root@xianchaomaster1 ~]# kubectl apply -f deploy-demo.yaml

注意:apply不同于create,apply可以执行多次;create执行一次,再执行就会报错有重复。

[root@xianchaomaster1 ~]# kubectl get pods 

显示如下:

NAME                        READY   STATUS    RESTARTS   AGE

myapp-v1-67fd9fc9c8-tsl92   1/1     Running   0          8m18s

myapp-v1-67fd9fc9c8-4bv5n   1/1     Running   0          8m18s

myapp-v1-67fd9fc9c8-cw59c   1/1     Running   0          18s

上面可以看到pod副本数变成了3个

#查看myapp-v1这个控制器的详细信息

[root@xianchaomaster1 ~]# kubectl describe deploy myapp-v1

#显示如下:

Name:                   myapp-v1

Namespace:              default

CreationTimestamp:      Sun, 21 Mar 2021 18:46:52 +0800

Labels:                 <none>

Annotations:            deployment.kubernetes.io/revision: 1

Selector:               app=myapp,version=v1

Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable

StrategyType:           RollingUpdate

#默认的更新策略rollingUpdate

MinReadySeconds:        0

RollingUpdateStrategy:  25% max unavailable, 25% max surge

#最多允许多25%个pod,25%表示不足一个,可以补一个

Pod Template:

  Labels:  app=myapp

           version=v1

  Containers:

   myapp:

    Image:        janakiramm/myapp:v1

    Port:         80/TCP

    Host Port:    0/TCP

    Environment:  <none>

    Mounts:       <none>

  Volumes:        <none>

Conditions:

  Type           Status  Reason

  ----           ------  ------

  Progressing    True    NewReplicaSetAvailable

  Available      True    MinimumReplicasAvailable

OldReplicaSets:  <none>

NewReplicaSet:   myapp-v1-67fd9fc9c8 (3/3 replicas created)

Events:

  Type    Reason             Age                 From                   Message

  ----    ------             ----                ----                   -------

  Normal  ScalingReplicaSet  3m26s               deployment-controller  Scaled down replica set myapp-v1-67fd9fc9c8 to 2

  Normal  ScalingReplicaSet  2m1s (x2 over 10m)  deployment-controller  Scaled up replica set myapp-v1-67fd9fc9c8 to 3

例子:测试滚动更新

在终端执行如下:

[root@xianchaomaster1 ~]# kubectl get pods -l app=myapp -w

打开一个新的终端窗口更改镜像版本,按如下操作:

 

[root@xianchaomaster1 ~]# vim deploy-demo.yaml

把image: janakiramm/myapp:v1 变成image: janakiramm/myapp:v2

保存退出,执行

[root@xianchaomaster1 ~]# kubectl apply -f deploy-demo.yaml

再回到刚才监测的那个窗口,可以看到信息如下:

NAME                        READY   STATUS    RESTARTS   AGE

myapp-v1-67fd9fc9c8-tsl92   1/1     Running   0          22m

myapp-v1-67fd9fc9c8-4bv5n   1/1     Running   0          22m

myapp-v1-67fd9fc9c8-cw59c   1/1     Running   0          14m

myapp-v1-75fb478d6c-24tbp   0/1     Pending   0          0s

myapp-v1-75fb478d6c-24tbp   0/1     Pending   0          0s

myapp-v1-75fb478d6c-24tbp   0/1     ContainerCreating   0          0s

myapp-v1-75fb478d6c-24tbp   1/1     Running             0          11s

myapp-v1-67fd9fc9c8-cw59c   1/1     Terminating         0          15m

myapp-v1-75fb478d6c-f52l6   0/1     Pending             0          0s

myapp-v1-75fb478d6c-f52l6   0/1     Pending             0          0s

myapp-v1-75fb478d6c-f52l6   0/1     ContainerCreating   0          0s

myapp-v1-67fd9fc9c8-cw59c   0/1     Terminating         0          15m

myapp-v1-75fb478d6c-f52l6   1/1     Running             0          11s

myapp-v1-67fd9fc9c8-4bv5n   1/1     Terminating         0          23m

myapp-v1-75fb478d6c-jlw28   0/1     Pending             0          0s

myapp-v1-75fb478d6c-jlw28   0/1     Pending             0          0s

myapp-v1-75fb478d6c-jlw28   0/1     ContainerCreating   0          0s

myapp-v1-75fb478d6c-jlw28   1/1     Running             0          1s

pending表示正在进行调度,ContainerCreating表示正在创建一个pod,running表示运 行一个pod,running起来一个pod之后再Terminating(停掉)一个pod,以此类推,直 到所有pod完成滚动升级

在另外一个窗口执行

[root@xianchaomaster1 ~]# kubectl get rs

显示如下:

NAME                  DESIRED   CURRENT   READY   AGE

myapp-v1-75fb478d6c   3         3         3       2m7s

myapp-v1-67fd9fc9c8   0         0         0       25m

上面可以看到rs有两个,下面那个是升级之前的,已经被停掉,但是可以随时回滚

[root@xianchaomaster1 ~]# kubectl rollout history deployment myapp-v1

查看myapp-v1这个控制器的滚动历史,显示如下:

deployment.apps/myapp-v1

REVISION  CHANGE-CAUSE

1         <none>

2         <none>

回滚操作如下:

[root@xianchaomaster1 ~]# kubectl rollout undo deployment/myapp-v1 --to-revision=2

5.3 自定义滚动更新策略

maxSurge和maxUnavailable用来控制滚动更新的更新策略

取值范围

数值

1. maxUnavailable: [0, 副本数]

2. maxSurge: [0, 副本数]

注意:两者不能同时为0。

比例

1. maxUnavailable: [0%, 100%] 向下取整,比如10个副本,5%的话==0.5个,但计算按照0个;

2. maxSurge: [0%, 100%] 向上取整,比如10个副本,5%的话==0.5个,但计算按照1个;

注意:两者不能同时为0。

建议配置

1. maxUnavailable == 0

2. maxSurge == 1

这是我们生产环境提供给用户的默认配置。即“一上一下,先上后下”最平滑原则:

1个新版本pod ready(结合readiness)后,才销毁旧版本pod。此配置适用场景是平滑更新、保证服务平稳,但也有缺点,就是“太慢”了。

总结:

maxUnavailable:和期望的副本数比,不可用副本数最大比例(或最大值),这个值越小,越能保证服务稳定,更新越平滑;

maxSurge:和期望的副本数比,超过期望副本数最大比例(或最大值),这个值调的越大,副本更新速度越快。

自定义策略:

修改更新策略:maxUnavailable=1,maxSurge=1

[root@xianchaomaster1 ~]# kubectl patch deployment myapp-v1 -p '{"spec":{"strategy":{"rollingUpdate": {"maxSurge":1,"maxUnavailable":1}}}}'

查看myapp-v1这个控制器的详细信息

[root@xianchaomaster1 ~]# kubectl describe deployment myapp-v1

显示如下:

RollingUpdateStrategy:  1 max unavailable, 1 max surge

上面可以看到RollingUpdateStrategy: 1 max unavailable, 1 max surge

这个rollingUpdate更新策略变成了刚才设定的,因为我们设定的pod副本数是3,1和1表示最少不能少于2个pod,最多不能超过4个pod

这个就是通过控制RollingUpdateStrategy这个字段来设置滚动更新策略的

把pod更新策略变成Recreate

[root@xianchaomaster1]# kubectl apply -f deploy-demo.yaml

打开新的终端,看pod更新过程

[root@xianchaomaster1 rs]# kubectl get pods -w

NAME                        READY   STATUS    RESTARTS   AGE

myapp-v1-59c458cb84-gglnb   1/1     Running   0          5m20s

myapp-v1-59c458cb84-nvjhq   1/1     Running   0          5m20s

myapp-v1-59c458cb84-zslxg   1/1     Running   0          4m59s

############33

myapp-v1-59c458cb84-zslxg   1/1     Terminating   0          5m3s

myapp-v1-59c458cb84-nvjhq   1/1     Terminating   0          5m24s

myapp-v1-59c458cb84-gglnb   1/1     Terminating   0          5m24s

myapp-v1-59c458cb84-gglnb   1/1     Terminating   0          5m24s

myapp-v1-59c458cb84-nvjhq   1/1     Terminating   0          5m24s

myapp-v1-59c458cb84-zslxg   1/1     Terminating   0          5m3s

myapp-v1-59c458cb84-gglnb   0/1     Terminating   0          5m25s

myapp-v1-59c458cb84-gglnb   0/1     Terminating   0          5m25s

myapp-v1-59c458cb84-gglnb   0/1     Terminating   0          5m25s

myapp-v1-59c458cb84-zslxg   0/1     Terminating   0          5m4s

myapp-v1-59c458cb84-zslxg   0/1     Terminating   0          5m4s

myapp-v1-59c458cb84-zslxg   0/1     Terminating   0          5m4s

myapp-v1-59c458cb84-nvjhq   0/1     Terminating   0          5m25s

myapp-v1-59c458cb84-nvjhq   0/1     Terminating   0          5m25s

myapp-v1-59c458cb84-nvjhq   0/1     Terminating   0          5m25s

myapp-v1-6bd64fd79-h668z    0/1     Pending       0          0s

myapp-v1-6bd64fd79-d8v55    0/1     Pending       0          0s

myapp-v1-6bd64fd79-h668z    0/1     Pending       0          0s

myapp-v1-6bd64fd79-wkvmp    0/1     Pending       0          0s

myapp-v1-6bd64fd79-d8v55    0/1     Pending       0          0s

myapp-v1-6bd64fd79-wkvmp    0/1     Pending       0          0s

myapp-v1-6bd64fd79-h668z    0/1     ContainerCreating   0          0s

myapp-v1-6bd64fd79-d8v55    0/1     ContainerCreating   0          0s

myapp-v1-6bd64fd79-wkvmp    0/1     ContainerCreating   0          0s

myapp-v1-6bd64fd79-h668z    0/1     ContainerCreating   0          1s

myapp-v1-6bd64fd79-d8v55    0/1     ContainerCreating   0          1s

myapp-v1-6bd64fd79-wkvmp    0/1     ContainerCreating   0          1s

myapp-v1-6bd64fd79-d8v55    0/1     Running             0          1s

myapp-v1-6bd64fd79-h668z    0/1     Running             0          2s

myapp-v1-6bd64fd79-wkvmp    0/1     Running             0          2s

myapp-v1-6bd64fd79-h668z    0/1     Running             0          21s

myapp-v1-6bd64fd79-h668z    1/1     Running             0          21s

myapp-v1-6bd64fd79-wkvmp    0/1     Running             0          21s

myapp-v1-6bd64fd79-wkvmp    1/1     Running             0          21s

myapp-v1-6bd64fd79-d8v55    0/1     Running             0          21s

myapp-v1-6bd64fd79-d8v55    1/1     Running             0          21s

总结:recreate这种更新策略,会把之前的所有pod都删除,再创建新的pod,风险很大

6、生产环境如何实现蓝绿部署?

6.1、什么是蓝绿部署?

蓝绿部署中,一共有两套系统:一套是正在提供服务系统,标记为“绿色”;另一套是准备发布的系统,标记为“蓝色”。两套系统都是功能完善的、正在运行的系统,只是系统版本和对外服务情况不同。

开发新版本,要用新版本替换线上的旧版本,在线上的系统之外,搭建了一个使用新版本代码的全新系统。 这时候,一共有两套系统在运行,正在对外提供服务的老系统是绿色系统,新部署的系统是蓝色系统。

蓝色系统不对外提供服务,用来做什么呢?

用来做发布前测试,测试过程中发现任何问题,可以直接在蓝色系统上修改,不干扰用户正在使用的系统。(注意,两套系统没有耦合的时候才能百分百保证不干扰)

蓝色系统经过反复的测试、修改、验证,确定达到上线标准之后,直接将用户切换到蓝色系统:

切换后的一段时间内,依旧是蓝绿两套系统并存,但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统(新系统)工作状态,如果出现问题,直接切换回绿色系统。

当确信对外提供服务的蓝色系统工作正常,不对外提供服务的绿色系统已经不再需要的时候,蓝色系统正式成为对外提供服务系统,成为新的绿色系统。 原先的绿色系统可以销毁,将资源释放出来,用于部署下一个蓝色系统。

6.2、蓝绿部署的优势和缺点

优点:

1、更新过程无需停机,风险较少

2、回滚方便,只需要更改路由或者切换DNS服务器,效率较高

缺点:

1、成本较高,需要部署两套环境。如果新版本中基础服务出现问题,会瞬间影响全网用户;如果新版本有问题也会影响全网用户。

2、需要部署两套机器,费用开销大

3、在非隔离的机器(Docker、VM)上操作时,可能会导致蓝绿环境被摧毁风险

4、负载均衡器/反向代理/路由/DNS处理不当,将导致流量没有切换过来情况出现

6.3 通过k8s实现线上业务的蓝绿部署

下面实验需要的镜像包在课件,把镜像压缩包上传到k8s的各个工作节点,ctr -n=k8s.io images import解压:

[root@xianchaonode2 ~]# ctr -n=k8s.io images import myapp-lan.tar.gz

[root@xianchaonode1 ~]# ctr -n=k8s.io images import myapp-lv.tar.gz

Kubernetes不支持内置的蓝绿部署。目前最好的方式是创建新的deployment,然后更新应用程序的service以指向新的deployment部署的应用

1.创建绿色部署环境(基于第一版代码做的镜像运行的pod)

[root@xianchaomaster1 ~]# cat  lv.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: myapp-v1

  namespace: blue-green

spec:

  replicas: 3

  selector:

   matchLabels:

    app: myapp

    version: v2

  template:

   metadata:

    labels:

     app: myapp

     version: v2

   spec:

    containers:

    - name: myapp

      image: janakiramm/myapp:v2

      imagePullPolicy: IfNotPresent

      ports:

      - containerPort: 80

可以使用kubectl命令创建部署。

[root@xianchaomaster1 ~]# kubectl create ns blue-green

[root@xianchaomaster1 ~]# kubectl apply -f lv.yaml

[root@xianchaomaster1 ~]# kubectl get pods -n blue-green

NAME                        READY   STATUS    RESTARTS   AGE

myapp-v1-75d7db5cf7-4qnjz   1/1     Running   0          8s

myapp-v1-75d7db5cf7-5sk6j   1/1     Running   0          8s

myapp-v1-75d7db5cf7-wmhs4   1/1     Running   0          8s

[root@xianchaomaster1 ~]# kubectl get pods -n blue-green --show-labels

NAME                        READY   STATUS    RESTARTS   AGE   LABELS

myapp-v1-75d7db5cf7-4qnjz   1/1     Running   0          35s   app=myapp,pod-template-hash=75d7db5cf7,version=v2

myapp-v1-75d7db5cf7-5sk6j   1/1     Running   0          35s   app=myapp,pod-template-hash=75d7db5cf7,version=v2

myapp-v1-75d7db5cf7-wmhs4   1/1     Running   0          35s   app=myapp,pod-template-hash=75d7db5cf7,version=v2

创建前端service

[root@xianchaomaster1 ~]# cat service_lanlv.yaml

apiVersion: v1

kind: Service

metadata:

  name: myapp-lan-lv

  namespace: blue-green

  labels:

    app: myapp

spec:

  type: NodePort

  ports:

  - port: 80

    nodePort: 30062

    name: http

  selector:

    app: myapp

version: v2

更新服务:

[root@xianchaomaster1 ~]# kubectl apply -f service_lanlv.yaml

[root@xianchaomaster1]# kubectl get svc -n blue-green

NAME           TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE

myapp-lan-lv   NodePort   10.107.213.1   <none>        80:30062/TCP   36s

在浏览器访问http://k8s-master节点ip:30062 显示如下:

2.创建蓝色部署环境(新上线的环境,要替代绿色环境)

[root@xianchaomaster1 ~]# cat  lan.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: myapp-v2

  namespace: blue-green

spec:

  replicas: 3

  selector:

   matchLabels:

    app: myapp

    version: v1

  template:

   metadata:

    labels:

     app: myapp

     version: v1

   spec:

    containers:

    - name: myapp

      image: janakiramm/myapp:v1

      imagePullPolicy: IfNotPresent

      ports:

      - containerPort: 80

然后可以使用kubectl命令创建部署。

[root@xianchaomaster1 ~]# kubectl apply -f lan.yaml

验证部署是否成功:

[root@xianchaomaster1 ~]# kubectl get pods -n blue-green 

NAME                        READY   STATUS    RESTARTS   AGE

myapp-v1-75d7db5cf7-4qnjz   1/1     Running   0          13m

myapp-v1-75d7db5cf7-5sk6j   1/1     Running   0          13m

myapp-v1-75d7db5cf7-wmhs4   1/1     Running   0          13m

myapp-v2-85cc897d89-hp5j2   1/1     Running   0          10s

myapp-v2-85cc897d89-jpgbm   1/1     Running   0          10s

myapp-v2-85cc897d89-q94g4   1/1     Running   0          10s

修改service_lanlv.yaml 配置文件,修改标签,让其匹配到蓝程序(升级之后的程序)

[root@xianchaomaster1 ~]# cat service_lanlv.yaml

apiVersion: v1

kind: Service

metadata:

  name: myapp-lan

  namespace: blue-green

  labels:

    app: myapp

spec:

  type: NodePort

  ports:

  - port: 80

    nodePort: 30062

    name: http

  selector:

    app: myapp

    version: v1

更新资源清单文件:

[root@xianchaomaster1 ~]# kubectl apply -f service_lanlv.yaml

[root@xianchaomaster1 deployment]# kubectl get svc -n blue-green

NAME           TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE

myapp-lan-lv   NodePort   10.107.213.1   <none>        80:30062/TCP   9m50s

在浏览器访问http://k8s-master节点ip:30062 显示如下:

实验完成之后,把资源先删除,以免影响后面实验:

[root@xianchaomaster1 deployment]# kubectl delete -f lan.yaml

[root@xianchaomaster1 deployment]# kubectl delete -f lv.yaml

[root@xianchaomaster1 deployment]# kubectl delete -f service_lanlv.yaml

7、通过k8s完成线上业务的金丝雀发布

7.1 金丝雀发布简介

金丝雀发布的由来:17 世纪,英国矿井工人发现,金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯,金丝雀也会停止歌唱;当瓦斯含量超过一定限度时,虽然人类毫无察觉,金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下,工人们每次下井都会带上一只金丝雀作为瓦斯检测指标,以便在危险状况下紧急撤离。

 

金丝雀发布(又称灰度发布、灰度更新):金丝雀发布一般先发1台,或者一个小比例,例如2%的服务器,主要做流量验证用,也称为金丝雀 (Canary) 测试 (国内常称灰度测试)。

100个pod:

   更新了一个pod:用的新的代码做的镜像

    99个pod:没有更新

简单的金丝雀测试一般通过手工测试验证,复杂的金丝雀测试需要比较完善的监控基础设施配合,通过监控指标反馈,观察金丝雀的健康状况,作为后续发布或回退的依据。 如果金丝测试通过,则把剩余的V1版本全部升级为V2版本。如果金丝雀测试失败,则直接回退金丝雀,发布失败。

优点:灵活,策略自定义,可以按照流量或具体的内容进行灰度(比如不同账号,不同参数),出现问题不会影响全网用户

缺点:没有覆盖到所有的用户导致出现问题不好排查

7.2 在k8s中实现金丝雀发布

打开一个标签1监测更新过程

[root@xianchaomaster1]# kubectl apply -f lv.yaml

[root@xianchaomaster1]# kubectl get pods -l app=myapp -n blue-green -w

NAME                        READY   STATUS    RESTARTS   AGE

myapp-v1-75d7db5cf7-c7z5d   1/1     Running   0          5s

myapp-v1-75d7db5cf7-km5bg   1/1     Running   0          5s

myapp-v1-75d7db5cf7-p7c8j   1/1     Running   0          5s

打开另一个标签2执行如下操作:

[root@xianchaomaster1]# kubectl set image deployment myapp-v1 myapp=docker.io/xianchao/nginx:v1  -n blue-green && kubectl rollout pause deployment myapp-v1 -n blue-green

回到标签1观察,显示如下:

NAME                        READY   STATUS    RESTARTS   AGE

myapp-v1-67fd9fc9c8-5fd2f   1/1     Running   0          86s

myapp-v1-67fd9fc9c8-92mdr   1/1     Running   0          86s

myapp-v1-75fb478d6c-wddds   0/1     Pending   0          0s

myapp-v1-75fb478d6c-wddds   0/1     Pending   0          0s

myapp-v1-75fb478d6c-wddds   0/1     ContainerCreating   0          0s

myapp-v1-75fb478d6c-wddds   0/1     ContainerCreating   0          1s

myapp-v1-75fb478d6c-wddds   1/1     Running             0          2s

注:上面的解释说明把myapp这个容器的镜像更新到docker.io/xianchao/nginx:v1版本 更新镜像之后,创建一个新的pod就立即暂停,这就是我们说的金丝雀发布;如果暂停几个小时之后没有问题,那么取消暂停,就会依次执行后面步骤,把所有pod都升级。

解除暂停:

回到标签1继续观察:

打开标签2执行如下:

[root@xianchaomaster1 ~]# kubectl rollout resume deployment myapp-v1 -n blue-green

在标签1可以看到如下一些信息,下面过程是把余下的pod里的容器都更的版本:

NAME                        READY   STATUS    RESTARTS   AGE

myapp-v1-67fd9fc9c8-5fd2f   1/1     Running   0          86s

myapp-v1-67fd9fc9c8-92mdr   1/1     Running   0          86s

myapp-v1-75fb478d6c-wddds   0/1     Pending   0          0s

myapp-v1-75fb478d6c-wddds   0/1     Pending   0          0s

myapp-v1-75fb478d6c-wddds   0/1     ContainerCreating   0          0s

myapp-v1-75fb478d6c-wddds   0/1     ContainerCreating   0          1s

myapp-v1-75fb478d6c-wddds   1/1     Running             0          2s

myapp-v1-67fd9fc9c8-92mdr   1/1     Terminating         0          10m

myapp-v1-75fb478d6c-z6f5z   0/1     Pending             0          0s

myapp-v1-75fb478d6c-z6f5z   0/1     Pending             0          0s

myapp-v1-75fb478d6c-z6f5z   0/1     ContainerCreating   0          0s

myapp-v1-75fb478d6c-z6f5z   0/1     ContainerCreating   0          1s

myapp-v1-67fd9fc9c8-92mdr   0/1     Terminating         0          10m

myapp-v1-75fb478d6c-z6f5z   1/1     Running             0          2s

myapp-v1-67fd9fc9c8-5fd2f   1/1     Terminating         0          10m

myapp-v1-67fd9fc9c8-5fd2f   0/1     Terminating         0          10m

myapp-v1-67fd9fc9c8-5fd2f   0/1     Terminating         0          10m

myapp-v1-67fd9fc9c8-5fd2f   0/1     Terminating         0          10m

myapp-v1-67fd9fc9c8-92mdr   0/1     Terminating         0          10m

myapp-v1-67fd9fc9c8-92mdr   0/1     Terminating         0          10m

[root@xianchaomaster1 ~]# kubectl get rs -n blue-green

可以看到replicaset控制器有2个了

NAME                  DESIRED   CURRENT   READY   AGE

myapp-v1-67fd9fc9c8   0         0         0       13m

myapp-v1-75fb478d6c   2         2         2       7m28s

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/pingmian/48314.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

科研绘图系列:R语言雨云图(Raincloud plot)

介绍 雨云图(Raincloud plot)是一种数据可视化工具,它结合了多种数据展示方式,旨在提供对数据集的全面了解。雨云图通常包括以下几个部分: 密度图(Density plot):表示数据的分布情况,密度图的曲线可以展示数据在不同数值区间的密度。箱线图(Box plot):显示数据的中…

模型剪枝入门

一、定义 1.定义 2. 案例1 3. 全局剪枝案例 4. 全局剪枝案例 5. 自定义剪枝 6. 特定网络剪枝 7. 多参数模块剪枝 8. torch.nn.utils.prune 解读 二、实现 定义 接口&#xff1a; import torch.nn.utils.prune as prune案例1 import torch.nn as nn import torch.nn.utils.…

全部由1组成的子矩形的数量

题目描述&#xff1a; 给定一个二维数组matrix&#xff0c;其中的值不是0就是1&#xff0c;返回全部由1组成的子矩阵的数量。 way&#xff1a; 假设我们遍历矩形的每一行&#xff0c;以当前遍历到的行作为地基&#xff0c;去看这一行的直方图&#xff08;直方图介绍 ->直方…

10.3.3 QGIS点类型注释(Annotation)的应用与二次开发实现

文章目录 前言注释(Annotation)图层QGis中的注释(Annotation)图层二次开发实现线段类型注释(Annotation)点类型Item 总结 前言 介绍注释(Annotation)图层在QGis中的使用以及二次开发的实现说明&#xff1a;文章中的示例代码均来自开源项目qgis_cpp_api_apps 注释(Annotation)…

【Unity实战100例】Unity声音可视化多种显示效果

目录 一、技术背景 二、界面搭建 三、 实现 UIAudioVisualizer 基类 四、实现 AudioSampler 类 五、实现 IAudioSample 接口 六、实现MusicAudioVisualizer 七、实现 MicrophoneAudioManager 类 八、实现 MicrophoneAudioVisualizer 类 九、源码下载 Unity声音可视化四…

代码随想录算法训练营第九天 |LeetCode151.翻转字符串里的单词 卡码网:55.右旋转字符串

代码随想录算法训练营 Day 9 代码随想录算法训练营第九天 |LeetCode151.翻转字符串里的单词 卡码网&#xff1a;55.右旋转字符串 目录 代码随想录算法训练营前言LeetCode151.翻转字符串里的单词卡码网&#xff1a;55.右旋转字符串 一、LeetCode151.翻转字符串里的单词1.题目链…

laravel为Model设置全局作用域

如果一个项目中存在这么一个sql条件在任何情况下或大多数情况都会被使用&#xff0c;同时很容易被开发者遗忘&#xff0c;那么就非常适用于今天要提到的这个功能&#xff0c;Eloquent\Model的全局作用域。 首先看一个示例&#xff0c;有个数据表&#xff0c;结构如下&#xff1…

一款国外开发的高质量WordPress下载站模板主题

5play下载站是由国外站长开发的一款WordPress主题&#xff0c;主题简约大方&#xff0c;为v1.8版本&#xff0c; 该主题模板中包含了上千个应用&#xff0c;登录后台以后只需要简单的三个步骤就可以轻松发布apk文章&#xff0c; 我们只需要在WordPress后台中导入该主题就可以…

大模型应用如何点燃?

▎****尽管在中国&#xff0c;关于大模型的商业模式的讨论尚显早期&#xff0c;但智能体&#xff0c;尤其是专业智能体&#xff0c;蕴藏着巨大的潜力。 ChatGPT 还没有颠覆世界。 身处“第三次信息革命”&#xff0c;很多人被浓烈的FOMO&#xff08;Fear of Missing Out&…

昇思25天学习打卡营第12天 | ResNet50图像分类

ResNet50在CIFAR-10数据集上的图像分类实践 在深入学习和实践使用ResNet50进行CIFAR-10数据集上的图像分类后&#xff0c;我对深度学习模型的构建、训练和优化有了更深刻的理解。本次学习经历涵盖了从理论探索到实际应用的全过程&#xff0c;以下是我的主要收获和反思。 1. 理…

(南京观海微电子)——电感的电路原理及应用区别

电感 电感是导线内通过交流电流时&#xff0c;在导线的内部及其周围产生交变磁通&#xff0c;导线的磁通量与生产此磁通的电流之比。 当电感中通过直流电流时&#xff0c;其周围只呈现固定的磁力线&#xff0c;不随时间而变化&#xff1b;可是当在线圈中通过交流电流时&am…

Jump Point Search(JPS)算法与A*算法

A* A*算法本质上讲是结合了DFS和BFS&#xff0c;针对当前起点先做一次BFS&#xff0c;再针对搜索的八个点做一次DFS BFS--广度优先算法&#xff08;Breadth First Search&#xff09; DFS A* 算法思想 A*的核心思想就是先进行一次BFS搜索&#xff0c;然后从这次BFS中找到距离…

python Requests库7种主要方法及13个控制参数(实例实验)

文章目录 一、Requests库的7种主要方法二、kwargs:控制访问的13个参数 一、Requests库的7种主要方法 序号方法说明1requests.request()&#xff1a;提交一个request请求&#xff0c;作为其他请求的基础2requests.get()&#xff1a;获取HTML网页代码的方法3requests.head()&…

基于重要抽样的主动学习不平衡分类方法ALIS

这篇论文讨论了数据分布不平衡对分类器性能造成的影响,并提出了一种新的有效解决方案 - 主动学习框架ALIS。 1、数据分布不平衡会影响分类器的学习性能。现有的方法主要集中在过采样少数类或欠采样多数类,但往往只采用单一的采样技术,无法有效解决严重的类别不平衡问题。 2、论…

9种二极管及其特点总结

二极管种类和特点 名字特点恒流二极管近些年出现&#xff0c;电压大于某个值&#xff0c;电流恒定&#xff0c;一般用于led普通二极管低频整流和续流&#xff0c;便宜&#xff0c;反向恢复时间us级别&#xff0c;PN结肖特基二极管比普通二极管反向关断更快&#xff0c;10ns级别…

智能硬件——0-1开发流程

文章目录 流程图1. 市场分析具体分析 2. 团队组建2. 团队组建早期团队配置建议配置一&#xff1a;基础型团队 (4人)配置二&#xff1a;扩展型团队 (6人)配置三&#xff1a;全面型团队 (7人) 3. 产品需求分析4. ID设计&#xff08;Industrial Design, 工业设计&#xff09;5. 结…

阿里云公共DNS免费版自9月30日开始限速 企业或商业场景需使用付费版

本周阿里云发布公告对公共 DNS 免费版使用政策进行调整&#xff0c;免费版将从 2024 年 9 月 30 日开始按照请求源 IP 进行并发数限制&#xff0c;单个 IP 的请求数超过 20QPS、UDP/TCP 流量超过 2000bps 将触发限速策略。 阿里云称免费版的并发数限制并非采用固定的阈值&…

Unity游戏开发入门:从安装到创建你的第一个3D场景

目录 引言 一、Unity的安装 1. 访问Unity官网 2. 下载Unity Hub 3. 安装Unity Hub并安装Unity编辑器 二、创建你的第一个项目 1. 启动Unity Hub并创建新项目 2. 熟悉Unity编辑器界面 3. 添加基本对象 4. 调整对象属性 5. 添加光源 三、运行与预览 引言 Unity&…

netty 自定义客户端连接池和channelpool

目录标题 客户端池化运行分析问题修复 客户端池化 通信完成之后&#xff0c;一般要关闭channel&#xff0c;释放内存。但是与一个服务器频繁的打开关闭浪费资源。 通过连接池&#xff0c;客户端和服务端之间可以创建多个 TCP 连接&#xff0c;提升消息的收发能力&#xff0c;同…

【深度学习】VGG-16原理及代码实现

1.原理及介绍 2.代码实现 2.1model.py import torch from torch import nn from torchsummary import summary import torch.nn.functional as Fclass VGG16(nn.Module):def __init__(self):super(VGG16, self).__init__()self.block1 nn.Sequential( # 用一个序列&#xf…