Deployment 官方文档:

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

这两个pod 的控制器就是能够管理 pod，监测 pod 运行状况，当 pod 发生故障，可以自动恢复 pod。也就是说能够代我们去管理 pod 中间层，并帮助我 们确保每一个 pod 资源始终处于我们所定义或者我们所期望的目标状态，一旦 pod 资源出现故障，那么 控制器会尝试重启 pod 或者里面的容器，如果一直重启有问题的话那么它可能会基于某种策略来进行重 新布派或者重新编排;如果 pod 副本数量低于用户所定义的目标数量，它也会自动补全;如果多余，也 会自动终止 pod 资源。

Replicaset 概述

ReplicaSet 是 kubernetes 中的一种副本控制器，简称 rs，主要作用是控制由其管理的 pod，使

pod 副本的数量始终维持在预设的个数。它的主要作用就是保证一定数量的 Pod 能够在集群中正常运 行，它会持续监听这些 Pod 的运行状态，在 Pod 发生故障时重启 pod，pod 数量减少时重新运行新的 Pod 副本。官方推荐不要直接使用 ReplicaSet，用 Deployments 取而代之，Deployments 是比 ReplicaSet 更高级的概念，它会管理 ReplicaSet 并提供很多其它有用的特性，最重要的是 Deployments 支持声明式更新，声明式更新的好处是不会丢失历史变更。所以 Deployment 控制器不 直接管理 Pod 对象，而是由 Deployment 管理 ReplicaSet，再由 ReplicaSet 负责管理 Pod 对象。

Replicaset 工作原理:如何管理 Pod?

Replicaset 核心作用在于代用户创建指定数量的 pod 副本，并确保 pod 副本一直处于满足用户期 望的数量， 起到多退少补的作用，并且还具有自动扩容缩容等机制。

Replicaset 控制器主要由三个部分组成:

1、用户期望的 pod 副本数:用来定义由这个控制器管控的 pod 副本有几个 

2、标签选择器:选定哪些 pod 是自己管理的，如果通过标签选择器选到的 pod 副本数量少于我 们指定的数量，需要用到下面的组件

3、pod 资源模板:如果集群中现存的 pod 数量不够我们定义的副本中期望的数量怎么办，需要 新建 pod，这就需要 pod 模板，新建的 pod 是基于模板来创建的。

Replicaset 资源清单文件编写技巧

#查看定义 Replicaset 资源需要的字段有哪些?

]# kubectl explain rs KIND: ReplicaSet

VERSION: apps/v1

DESCRIPTION:

ReplicaSet ensures that a specified number of pod replicas are running at any given time.

FIELDS:

apiVersion <string> #当前资源使用的 api 版本，跟 VERSION: apps/v1 保持一致 kind <string> #资源类型，跟 KIND: ReplicaSet 保持一致

metadata<Object> #元数据，定义 Replicaset 名字的

spec <Object> ##定义副本数、定义标签选择器、定义 Pod 模板

status <Object> #状态信息，不能改

#查看 replicaset 的 spec 字段如何定义?

KIND: ReplicaSet

VERSION:  apps/v1

RESOURCE: spec <Object>

DESCRIPTION:

    Spec defines the specification of the desired behavior of the ReplicaSet.

    More info:

    https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

    ReplicaSetSpec is the specification of a ReplicaSet.

FIELDS:

minReadySeconds. <integer> 

replicas <integer> #定义的 pod 副本数，根据我们指定的值创建对应数量的 pod

selector <Object> -required- #用于匹配 pod 的标签选择器

template <Object> #定义 Pod 的模板，基于这个模板定义的所有 pod 是一样的

#查看 replicaset 的 spec.template 字段如何定义?

#对于 template 而言，其内部定义的就是 pod，pod 模板是一个独立的对象

~]# kubectl explain rs.spec.template

kubectl explain rs.spec.template.spec

KIND: ReplicaSet

VERSION:  apps/v1

RESOURCE: spec <Object>

DESCRIPTION:

    Specification of the desired behavior of the pod. More info:

    https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

    PodSpec is a description of a pod.

FIELDS:

metadata<Object> 

spec <Object>

通过上面可以看到，ReplicaSet 资源中有两个 spec 字段。第一个 spec 声明的是 ReplicaSet 定义 多少个 Pod 副本(默认将仅部署 1 个 Pod)、匹配 Pod 标签的选择器、创建 pod 的模板。第二个 spec 是 spec.template.spec:主要用于 Pod 里的容器属性等配置。

.spec.template 里的内容是声明 Pod 对象时要定义的各种属性，所以这部分也叫做 PodTemplate (Pod 模板)。还有一个值得注意的地方是:在.spec.selector 中定义的标签选择器必须能够匹配到 spec.template.metadata.labels 里定义的 Pod 标签，否则 Kubernetes 将不允许创建 ReplicaSet。

Replicaset 使用:   部署 Guestbook 留言板

工作节点  docker load -I frontend.tar.gz

cat replicaset.yaml

apiVersion: apps/v1

kind:  ReplicaSet

metadata:

  name: frontend

  labels:

    app: guestbook

    tier: frontend

spec:

  replicas: 3      #定义副本数，默认是1个

  selector:         #定义标签选择器，用于匹配pod的标签选择器

    matchLabels:

      tier: frontend

  template:           #定义模版，基于这个模版定义所有的pod是一样的

    metadata:

      labels:

        tier: frontend

    spec:

      containers:

      - name: php-redis

        image: yecc/gcr.io-google_samples-gb-frontend:v3

        imagePullPolicy: IfNotPresent

kubectl apply -f replicaset.yaml

kubectl get pods

AME READY STATUS RESTARTS AGE

frontend-64pc8          1/1    Running  0          7m17s

frontend-nwxmp          1/1    Running  0          7m17s

frontend-tqvf6          1/1    Running  0          7m17s

#pod 的名字是由控制器的名字-随机数组成的

#资源清单详细说明

apiVersion: apps/v1 #ReplicaSet 这个控制器属于的核心群组 

kind: ReplicaSet #创建的资源类型

metadata:

name: frontend #控制器的名字 labels:

app: guestbook

tier: frontend spec:

replicas: 3 #管理的 pod 副本数量 selector:

matchLabels:

tier: frontend #管理带有 tier=frontend 标签的 pod

template: #定义 pod 的模板 metadata:

labels:

tier: frontend#pod 标签，一定要有，这样上面控制器就能找到它要管理的 pod 是哪些了 

spec:

containers: #定义 pod 里运行的容器

- name: php-redis #定义容器的名字

image: yecc/gcr.io-google_samples-gb-frontend:v3 

ports: #定义端口

- name: http #定义容器的名字

containerPort: 80 #定义容器暴露的端口

Replicaset 管理 pod:扩容、缩容、更新

#Replicaset 实现 pod 的动态扩容

ReplicaSet 最核心的功能是可以动态扩容和回缩，如果我们觉得两个副本太少了，想要增加，只需 要修改配置文件 replicaset.yaml 里的 replicas 的值即可，原来 replicas: 3，现在变成 replicaset: 5， 修改之后，执行如下命令更新:

kubectl apply -f replicaset.yaml

kubectl get rs

kubectl get pods

kubectl edit rs frontend

把上面的 spec 下的 replicas 后面的值改成 5，保存退出，就可以看到5个frontend前端程序

#Replicaset 实现 pod 的动态缩容

如果我们觉得 5 个 Pod 副本太多了，想要减少，只需要修改配置文件 replicaset.yaml 里的 replicas 的值即可，把 replicaset:4 变成 replicas: 2，修改之后，执行如下命令更新:

#Replicaset 实现 pod 的更新

docker load -i myapp-v2.tar.gz

kubectl edit rs frontend

#修改镜像 image: yecc/gcr.io-google_samples-gb-frontend:v3 变成- image: ikubernetes/myapp:v2，修改之后保存退出

# kubectl get rs -o wide

NAME DESIRED CURRENT READY IMAGES frontend 2 2 2 ikubernetes/myapp:v2 #

上面可以看到镜像变成了 ikubernetes/myapp:v2，说明滚动升级成功了

kubectl get pods -o wide

NAME            READY  STATUS    RESTARTS  AGE  IP              NODE      NOMINATED NODE  READINESS GATES

frontend-64pc8  1/1    Running  0          22m  10.244.187.78  god62  <none>          <none>

frontend-tqvf6  1/1    Running  0          22m  10.244.187.77  god62  <none>          <none>

curl   10.244.187.78

curl: (7) Failed connect to 10.244.187.78; Connection refused. #如果报错的话看日志

kubectl logs frontend-64pc8

kubectl describe pod frontend-64pc8    #看Containers

div style="width: 50%; margin-left: 20px">

<h2>Guestbook

# curl 10.244.187.77 div style="width: 50%; margin-left: 20px">

<h2>Guestbook

#

上面可以看到虽然镜像已经更新了，但是原来的 pod 使用的还是之前的镜像，新创建的 pod 才会

使用最新的镜像

kubectl delete pods frontend-8khvm

kubectl get pods -o wide

kubectl get pods -o wide

NAME            READY  STATUS    RESTARTS  AGE    IP              NODE      NOMINATED NODE  READINESS GATES

frontend-hh559  1/1    Running  0          5m24s  10.244.187.84   god62  <none>          <none>

frontend-sgnf7  1/1    Running  0           12s    10.244.209.152      god64  <none>          <none>

curl 10.244.209.152

Hello MyApp | Version: v2 | Pod Name

生产环境如果升级，可以删除一个 pod，观察一段时间之后没问题再删除另一个 pod，但是这样需 要人工干预多次;实际生产环境一般采用蓝绿发布，原来有一个 rs1，再创建一个 rs2(控制器)，通过修 改 service 标签，修改 service 可以匹配到 rs2 的控制器，这样才是蓝绿发布，这个也需要我们精心的部 署规划，我们有一个控制器就是建立在 rs 之上完成的，叫做 Deployment

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 处于活跃状态.

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

Deployment 资源清单文件编写技巧

kubectl explain deployment

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

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

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

spec <Object>       #定义容器的

kubectl explain deployment.spec

FIELDS:

minReadySeconds

#Kubernetes 在等待设置的时间后才进行升级

#如果没有设置该值，Kubernetes 会假设该容器启动起来后就提供服务了

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

progressDeadlineSeconds

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

replicas  #副本数

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

selector -required- #标签选择器，选择它关联的 pod 

strategy  #更新策略

template -required #定义的 pod 模板

#查看 Deployment 下的 spec.strategy 字段

kubectl explain deploy.spec.strategy

KIND: Deployment

VERSION:  apps/v1

RESOURCE: strategy <Object>

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 能多几个，少几个 

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

kubectl explain deploy.spec.strategy.rollingUpdate

maxSurge <string>

#我们更新的过程当中最多允许超出的指定的目标副本数有几个; 它有两种取值方式，第一种直接给定数量，第二种根据百分比，百分比表示原本是 5 个，最多 可以超出 20%，那就允许多一个，最多可以超过 40%，那就允许多两个

maxUnavailable <string>

#最多允许几个不可用假设有 5 个副本，最多一个不可用，就表示最少有 4 个可用

#查看 Deployment 下的 spec.template 字段

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

kubectl explain deploy.spec.template

FIELDS:

metadata #定义模板的名字 

spec <Object>

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

#查看 Deployment 下的 spec.template.spec 字段

kubectl explain deploy.spec.template.spec

FIELDS:

activeDeadlineSeconds

#activeDeadlineSeconds     表示 Pod 可以运行的最长时间，达到设置的该值后，Pod 会自 动停止。

affinity  #定义亲和性，跟直接创建 pod 时候定义亲和性类似

 automountServiceAccountToken <boolean> #身份认证相关的 

containers <[]Object> -required- #定义容器属性 

dnsConfig<Object> #设置 Pod 的 DNS

dnsConfig: nameservers:

- 192.xxx.xxx.6 searches:

-  god.svc.cluster.local

- my.dns.search.god

dnsPolicy # dnsPolicy  决定 Pod 内预设的 DNS 配置策略

None 无任何策略:使用自定义的策略

Default 默认:使用宿主机的 dns 配置，/etc/resolv.conf

ClusterFirst  集群 DNS 优先，与 Default 相反，会预先使用 kube-dns (或 CoreDNS ) 的信息当预设置参数写入到该 Pod 内的 DNS 配置。

ClusterFirstWithHostNet 集群 DNS 优先，并伴随着使用宿主机网络:同时使用

hostNetwork 与 kube-dns 作为 Pod 预设 DNS 配置。

enableServiceLinks <boolean> 

ephemeralContainers <[]Object> #定义临时容器

临时容器与其他容器的不同之处在于，它们缺少对资源或执行的保证，并且永远不会自 动重启，因此不适用于构建应用程序。临时容器使用与常规容器相同的 ContainerSpec 段 进行描述，但许多字段是不相容且不允许的。

临时容器没有端口配置，因此像 ports，livenessProbe，readinessProbe 这样的字 段是不允许的。

Pod 资源分配是不可变的，因此 resources 配置是不允许的。

临时容器用途:

当由于容器崩溃或容器镜像不包含调试应用程序而导致 kubectl exec 无用时，临时容器对于交互式故障排查很有用。

hostAliases <[]Object> #在 pod 中增加域名解析的

hostAliases:

– ip: "10.1.2.2"

hostnames: – "mc.local"

– "rabbitmq.local" – ip: "10.1.2.3"

hostnames:

– "redis.local"

– "mq.local"

hostIPC <boolean> #使用主机 IPC

hostNetwork #

是否使用宿主机的网络

hostPID <boolean> #可以设置容器里是否可以看到宿主机上的进程。True 可以 hostname

imagePullSecrets <[]Object>

initContainers <[]Object> 

#定义初始化容器

nodeName  #定义 pod 调度到具体哪个节点上

nodeSelector  #定义节点选择器

overhead #overhead 是 1.16 引入的字段，在没有引入

Overhead 之前，只要一个节点的资源可用量大于等于 Pod 的 requests 时，这个 Pod 就可以被调度到这个节点上。引入 Overhead 之后，只有节点的资源可用量大于等于 Overhead 加上 requests 的和时才能被调度上来。

preemptionPolicy   <string>

priority. <integer>

priorityClassName. <string>

readinessGates <[]Object> 

restartPolicy.  <string>  #Pod 重启策略

runtimeClassName <string>

schedulerName.  <string>

securityContext. <Object>.  #是否开启特权模式

serviceAccount.   <string>

serviceAccountName  <string>

setHostnameAsFQDN <boolean>. #只能布耳值True 或是 False。

shareProcessNamespace  <boolean>.

subdomain   <string>

terminationGracePeriodSeconds   <integer>       #优雅删除

#在真正删除容器之前，K8S 会先发终止信号(kill -15 {pid})给容器，默认 30s 

tolerations <[]Object>   #定义容忍度

topologySpreadConstraints <[]Object。 

volumes <[]Object>        #   挂载存储卷

Deployment 使用:创建一个 web 站点

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

myapp-blue-v1.tar.gz 和 myapp-blue-v2.tar.gz  上传到工作节点

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

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                            2                 60s

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

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 资源 

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

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

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

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

kubectl get pods -o wide | grep myapp

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

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

curl 10.244.187.78

background-color: blue;

#资源清单文件详细解读 

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

kind: Deployment.       #创建的资源是 deployment

 metadata:    

name: myapp-v1        #deployment 的名字

 spec:

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

selector:       #标签选择器

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

....  .... 

spec: #定义容器的属性

containers:

- name: myapp

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

ImagePullPolicy: IfNotPresent #镜像拉取策略 ports:

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

Deployment 管理 pod:扩容、缩容、滚动更新、回滚

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

cat deploy-demo.yaml 直接修改 replicas 数量，如下，变成 3

kubectl apply -f deploy-demo.yaml

kubectl get pods

NAME                        READY  STATUS    RESTARTS  AGE

myapp-v1-75fb478d6c-69rs9  1/1    Running  0          2m17s

myapp-v1-75fb478d6c-bqqv4  1/1    Running  0          2m15s

myapp-v1-75fb478d6c-fjxps  1/1    Running  0          2m13s

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

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

kubectl describe deploy myapp-v1

Name: myapp-v1

Namespace:              default

CreationTimestamp:      Fri, 14 May 2021 16:43:08 +0800

Labels:                <none>

Annotations:            deployment.kubernetes.io/revision: 2

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

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

cat deploy-demo.yaml 直接修改 replicas 数量，如下，变成 2spec:replicas: 2 

kubectl apply -f deploy-demo.yaml

通过 deployment 管理应用，实现滚动更新

kubectl get pods -l app=myapp -w

vim deploy-demo.yaml

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

kubectl apply -f deploy-demo.yaml

再回到刚才执行监测 kubectl get pods -l app=myapp -w 的那个窗口，可以看到信息

myapp-v1-75fb478d6c-x8stq 0/1 Pending

myapp-v1-75fb478d6c-x8stq 0/1 Pending

myapp-v1-75fb478d6c-x8stq 0/1 ContainerCreating

myapp-v1-67fd9fc9c8-fcprr 1/1 Terminating

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

kubectl get rs

NAME                  DESIRED  CURRENT  READY  AGE

frontend              2        2        2      2d23h

myapp-v1-67fd9fc9c8  0        0        0      45h

myapp-v1-75fb478d6c  2         2         2       8m48s

#上面可以看到 rs 有两个，上面那个是升级之前的，已经被停掉，但是可以随时回滚 #查看 myapp-v1 这个控制器的历史版本

# kubectl rollout history deployment myapp-v1 deployment.apps/myapp-v1

REVISION CHANGE-CAUSE

1  <none>

2  <none>

回滚一下

kubectl rollout undo deployment myapp-v1 --to-revision=1

deployment.apps/myapp-v1 rolled back

在查看版本信息

kubectl rollout history deployment myapp-v1

REVISION CHANGE-CAUSE

2        <none>

3        <none>

资源限制  

kubectl explain deploy.spec.template.spec.containers.resources

Deployment 资源清单详解

官方文档无聊看看多学习，加油

https://kubernetes.io/zh/docs/concepts/workloads/controllers/deployment/

apiVersion: apps/v1 

kind: Deployment metadata:

name: portal

namespace: ms spec:

replicas: 1 selector:

matchLabels: project: ms app: portal

template: metadata:

labels: project: ms app: portal

spec: containers:

- name: portal

image: god/portal:v1 imagePullPolicy: Always ports:

- protocol: TCP containerPort: 8080

resources: #资源配额

limits: #资源限制，最多可用的 cpu 和内存

cpu: 1

memory: 1Gi

requests: #最少需要多少资源才可以运行 Pod

cpu: 0.5

memory: 1Gi readinessProbe:

tcpSocket: port: 8080

initialDelaySeconds: 60

periodSeconds: 10 livenessProbe:

tcpSocket: port: 8080

initialDelaySeconds: 60 periodSeconds: 10

livenessProbe:

#存活性探测

#用于判断容器是否存活，即 Pod 是否为 running 状态，如果 LivenessProbe 探针探测到容器不健 康，则 kubelet 将 kill 掉容器，并根据容器的重启策略是否重启。如果一个容器不包含 LivenessProbe 探针，则 Kubelet 认为容器的 LivenessProbe 探针的返回值永远成功。

tcpSocket:

port: 8080 #检测 8080 端口是否存在

initialDelaySeconds: 60 #Pod 启动 60s 执行第一次检查 

periodSeconds: 10 #第一次检查后每隔 10s 检查一次

readinessProbe: #就绪性探测

有时候应用程序可能暂时无法接受请求，比如 

Pod 已经 Running 了，但是容器内应用程序尚未启动成 功，在这种情况下，如果没有 ReadinessProbe，则 Kubernetes 认为它可以处理请求了，然而此时， 我们知道程序还没启动成功是不能接收用户请求的，所以不希望 kubernetes 把请求调度给它，则使用 ReadinessProbe 探针。

ReadinessProbe 和 livenessProbe 可以使用相同探测方式，只是对 Pod 的处置方式不同， ReadinessProbe 是将 Pod IP:Port 从对应的 EndPoint 列表中删除，而 livenessProbe 则 Kill 容器并 根据 Pod 的重启策略来决定作出对应的措施。

ReadinessProbe 探针探测容器是否已准备就绪，如果未准备就绪则 kubernetes 不会将流量转发给此 Pod。

tcpSocket: port: 8080

initialDelaySeconds: 60

periodSeconds: 10

#在 Pod 运行过程中，K8S 仍然会每隔 10s 检测 8080 端口