5.Kubernetes调度基础 | Evergreen Notes

1.Replication Controlle

Replication Controller（复制控制器，RC）和 ReplicaSet（复制集，RS）是两种简单部署 Pod 的方式。因为在生产环境中，主要使用更高级的 Deployment 等方式进行 Pod 的管理和部署，所以只需要简单了解即可。

Replication Controller Replication Controller（简称 RC）可确保 Pod 副本数达到期望值，也就是 RC 定义的数量。换句话说，Replication Controller 可确保一个 Pod 或一组同类 Pod 总是可用。如果存在的 Pod 大于设定的值，则 Replication Controller 将终止额外的 Pod。如果太小， Replication Controller 将启动更多的 Pod 用于保证达到期望值。与手动创建 Pod 不同的是，用 Replication Controller 维护的 Pod 在失败、删除或终止时会自动替换。因此即使应用程序只需要一个 Pod，也应该使用 Replication Controller 或其他方式管理。Replication Controller 类似于进程管理程序，但是 Replication Controller 不是监视单个节点上的各个进程，而是监视多个节点上的多个 Pod。

定义一个 Replication Controller 的示例如下

YAML

vim nginx.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

上面的yaml清单文件将创建一个 ReplicationController,其中有 3 个副本 pod 一直在运行

BASH

kubectl apply -f nginx.yml

验证上述资源创建

BASH

描述我们创建的 ReplicationController

BASH

我们通过手动删除由复制控制器控制的正在运行的 pod 来验证 ReplicationController 的功能,复制控制器将自动生成一个新的 pod 以满足所需的状态

BASH

扩展复制控制器

BASH

可以在上面看到添加了两个新的 pod

删除复制控制器

BASH

2.ReplicaSet

ReplicaSet 是支持基于集合的标签选择器的下一代 Replication Controller，它主要用作 Deployment 协调创建、删除和更新 Pod，和 Replication Controller 唯一的区别是，ReplicaSet 支持标签选择器。在实际应用中，虽然 ReplicaSet 可以单独使用，但是一般建议使用 Deployment 来自动管理 ReplicaSet，除非自定义的 Pod 不需要更新或有其他编排等

YAML

确保您没有使用已被其他控制器使用的标签。否则,另一个 ReplicaSet 或 Controller 可能会先获取 pod。另请注意,pod 模板中定义的标签不能与 matchLabels 部分中定义的标签不同。

matchLabels字段指定了env: qa，表示选择具有env=qa标签的Pod。
matchExpressions字段指定了一个表达式，key: tier, operator: In, values: [front-end]，表示选择具有标签的Pod。

BASH

描述我们创建的ReplicaSet

BASH

扩大 ReplicaSet

BASH

在ReplicaSet上配置Auto Scaling

我们可以为 ReplicaSets 配置自动缩放,以根据节点的 CPU 负载扩展到最大数量的 Pod。运行以下命令为我们的 ReplicaSet 启用自动缩放:

BASH

kubectl autoscale replicaset --max=5 nginx
horizontalpodautoscaler.autoscaling/nginx autoscaled

设置上述指标后,您无法将 Replicaset 扩展超过 5 个 Pod

在您可能有数千个 Pod 运行的生产环境中,您可能希望验证特定 Pod 是否实际上由该 ReplicaSet 管理,而不是。通过查询 pod,您可以获得以下信息:找出正在运行的 pod 的所有者

BASH

只想删除 ReplicaSet 资源,而不是它管理的 pod

BASH

ReplicaSets 和 ReplicationController 的区别

BASH

如何理解 Kubernetes官方强烈建议避免直接使用ReplicaSet，而应该通过Deployment来创建RS和Pod。由于ReplicaSet是ReplicationController的代替物，因此用法基本相同，唯一的区别在于ReplicaSet支持集合式的selector

BASH

3.无状态应用管理 Deployment

BASH

# kubectl create deployment nginx --image=registry.cn-beijing.aliyuncs.com/dotbalo/nginx:1.15.12-alpine --replicas=3 -oyaml --dry-run=client > nginx.yaml

3.1 创建Deployment

YAML

注意：从 Kubernetes 1.16 版本开始，彻底废弃了其他的 APIVersion，只能使用 apps/v1， 1.16 以下的版本可以使用 extension 等

示例解析

使用 kubectl create 创建此 Deployment

BASH

NAME：集群中Deployment的名称；

READY：Pod就绪个数和总副本数；

UP-TO-DATE：显示已达到期望状态的被更新的副本数；

AVAILABLE：显示用户可以使用的应用程序副本数，当前为0，说明目前还没有达到期望的Pod；

AGE：显示应用程序运行的时间。可以使用 rollout 命令查看整个 Deployment 创建的状态:

BASH

root@k8s-master01:~/hhh# kubectl rollout status deployment/nginx-deployment

查看此 Deployment 当前对应的 ReplicaSet

BASH

DESIRED：应用程序副本数；

CURRENT：当前正在运行的副本数；

当 Deployment 有过更新，对应的 RS 可能不止一个，可以通过-o yaml 获取当前对应的 RS 是哪个，其余的 RS 为保留的历史版本，用于回滚等操作。查看此 Deployment 创建的 Pod，可以看到 Pod 的 hash 值 5c689d88bb 和上述 Deployment 对应的 ReplicaSet 的 hash 值一致：

BASH

3.2 更新 Deployment

注意：当且仅当 Deployment 的 Pod 模板（即.spec.template）更改时，才会触发 Deployment 更新，例如更改内存、CPU 配置或者容器的 image。

假如更新 Nginx Pod 的 image 使用 nginx:latest，并使用--record 记录当前更改的参数，后期回滚时可以查看到对应的信息：

BASH

当然也可以使用 edit 命令直接编辑 Deployment，效果相同

BASH

root@k8s-master01:~/hhh# kubectl edit deployments.apps nginx-deployment 
deployment.apps/nginx-deployment edited

同样可以使用 kubectl rollout status 查看更新过程：

BASH

可以看出更新过程为新旧交替更新，首先新建一个 Pod，当 Pod 状态为 Running 时，删除一个旧的 Pod，同时再创建一个新的 Pod。当触发一个更新后，会有新的 ReplicaSet 产生，旧的 ReplicaSet 会被保存，查看此时 ReplicaSet，可以从 AGE 或 READY 看出来新旧 ReplicaSet

BASH

通过 describe 查看 Deployment 的详细信息

BASH

在 describe 中可以看出，第一次创建时，它创建了一个名为nginx-deployment-5c8578bf64 的 ReplicaSet，并直接将其扩展为 3 个副本。更新部署时，它创建了一个新的 ReplicaSet，命名为 nginx-deployment-7ffd5c8dc9，并将其副本数扩展为 1，然后将旧的 ReplicaSet 缩小为 2，这样至少可以有 2 个 Pod 可用，最多创建了 4 个 Pod。以此类推，使用相同的滚动更新策略向上和向下扩展新旧 ReplicaSet，最终新的 ReplicaSet 可以拥有 3 个副本，并将旧的 ReplicaSet 缩小为 0。

5.3 回滚 Deployment

当更新了版本不稳定或配置不合理时，可以对其进行回滚操作，假设我们又进行了几次更新（此处以更新镜像版本触发更新，更改配置效果类似）：

BASH

# kubectl set image deployment nginx-deployment nginx=nginx:1.15.12 --record
# kubectl set image deployment nginx-deployment nginx=nginx --record

使用 kubectl rollout history 查看更新历史

BASH

查看 Deployment 某次更新的详细信息，使用--revision 指定某次更新版本号

BASH

如果只需要回滚到上一个稳定版本，使用 kubectl rollout undo 即可

BASH

如果要回滚到指定版本，使用--to-revision 参数

BASH

root@k8s-master01:~#  kubectl rollout undo deployment/nginx-deployment --to-revision=15
deployment.apps/nginx-deployment rolled

5.4 扩容 Deployment

当公司访问量变大，或者有预期内的活动时，三个 Pod 可能已无法支撑业务时，可以提前对其进行扩展。使用 kubectl scale 动态调整 Pod 的副本数，比如增加 Pod 为 5 个

BASH

5.5 暂停和恢复 Deployment 更新

上述演示的均为更改某一处的配置，更改后立即触发更新，大多数情况下可能需要针对一个资源文件更改多处地方，而并不需要多次触发更新，此时可以使用 Deployment 暂停功能，临时禁用更新操作，对 Deployment 进行多次修改后在进行更新。使用 kubectl rollout pause 命令即可暂停 Deployment 更新

BASH

root@k8s-master01:~#  kubectl rollout pause deployment/nginx-deployment
deployment.apps/nginx-deployment paused

然后对 Deployment 进行相关更新操作，比如先更新镜像，然后对其资源进行限制（如果使用的是 kubectl edit 命令，可以直接进行多次修改，无需暂停更新，kubectlset 命令一般会集成在 CICD 流水线中）

BASH

# kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
# kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi

通过 rollout history 可以看到目前更新

BASH

进行完最后一处配置更改后，使用 kubectl rollout resume 恢复 Deployment 更新

BASH

root@k8s-master01:~# kubectl rollout resume deployment.v1.apps/nginx-deployment

可以查看到恢复更新的 Deployment 创建了一个新的 RS（ReplicaSet 缩写）

BASH

可以看到更新

BASH

5.6 更新 Deployment 的注意事项

历史版本清理策略：在默认情况下，revision 保留 10 个旧的 ReplicaSet，其余的将在后台进行垃圾回收，可以在.spec.revisionHistoryLimit 设置保留 ReplicaSet 的个数。当设置为 0 时，不保留历史记录

更新策略

.spec.strategy.type==Recreate，表示重建，先删掉旧的Pod再创建新的Pod；
.spec.strategy.type==RollingUpdate，表示滚动更新，可以指定maxUnavailable和maxSurge 来控制滚动更新过程；
.spec.strategy.rollingUpdate.maxUnavailable，指定在回滚更新时最大不可用的Pod数量，可选字段，默认为25%，可以设置为数字或百分比，如果maxSurge为0，则该值不能为0；
.spec.strategy.rollingUpdate.maxSurge可以超过期望值的最大Pod数，可选字段，默认为 25%，可以设置成数字或百分比，如果maxUnavailable为0，则该值不能为0。

Ready 策略

spec.minReadySeconds 是可选参数，指定新创建的 Pod 应该在没有任何容器崩溃的情况下视为 Ready（就绪）状态的最小秒数，默认为 0，即一旦被创建就视为可用，通常和容器探针连用。

4.有状态应用管理 StatefulSet

4.1 什么是 StatefulSet？

StatefulSet 是Kubernetes中的一种控制器，他解决的什么问题呢？我们知道Deployment是对应用做了一个简化设置，Deployment认为一个应用的所有的pod都是一样的，他们之间没有顺序，也无所谓在那台宿主机上。需要扩容的时候就可以通过pod模板加入一个，需要缩容的时候就可以任意杀掉一个。但是实际的场景中，并不是所有的应用都能做到没有顺序等这种状态，尤其是分布式应用，他们各个实例之间往往会有对应的关系，例如：主从、主备。还有数据存储类应用,它的多个实例，往往会在本地磁盘存一份数据，而这些实例一旦被杀掉，即使从建起来，实例与数据之间关系也会丢失，而这些实例有不对等的关系，实例与外部存储有依赖的关系的应用，被称作“有状态应用”。StatefulSet与Deployment相比，相同于他们管理相同容器规范的Pod，不同的时候，StatefulSet为pod创建一个持久的标识符，他可以在任何编排的时候得到相同的标识符。

特点：

4.2 Headless Service

4.3 定义一个 StatefulSet 资源文件

YAML

kind: Service定义了一个名字为Nginx的Headless Service，创建的Service格式为nginx- 0.nginx.default.svc.cluster.local，其他的类似，因为没有指定Namespace（命名空间），所以默认部署在default；

kind: StatefulSet定义了一个名字为web的StatefulSet，replicas表示部署Pod的副本数，本实例为2

在 StatefulSet 中必须设置 Pod 选择器（ .spec.selector ）用来匹配其标签（.spec.template.metadata.labels）。在 1.8 版本之前，如果未配置该字段（.spec.selector），将被设置为默认值，在 1.8 版本之后，如果未指定匹配 Pod Selector，则会导致 StatefulSet 创建错误。

当 StatefulSet 控制器创建 Pod 时，它会添加一个标签 statefulset.kubernetes.io/pod-name，该标签的值为 Pod 的名称，用于匹配 Service

创建 StatefulSet

BASH

StatefulSet 创建 Pod 流程

StatefulSet 管理的 Pod 部署和扩展规则如下：

4.4 StatefulSet 扩容和缩容

和 Deployment 类似，可以通过更新 replicas 字段扩容/缩容 StatefulSet，也可以使用 kubectl scale、kubectl edit 和 kubectl patch 来扩容/缩容一个 StatefulSet。

（1）扩容将上述创建的 sts 副本增加到 5 个

BASH

（2）缩容

首先打开另一个终端动态查看缩容的流程

BASH

4.5 StatefulSet 更新策略

（1）On Delete 策略

OnDelete 更新策略实现了传统（1.7 版本之前）的行为，它也是默认的更新策略。当我们选择这个更新策略并修改 StatefulSet 的.spec.template 字段时，StatefulSet 控制器不会自动更新 Pod，必须手动删除 Pod 才能使控制器创建新的 Pod。

（2）RollingUpdate

策略 RollingUpdate（滚动更新）更新策略会自动更新一个 StatefulSet 中所有的 Pod，采用与序号索引相反的顺序进行滚动更新。

比如更改一个名称为 web 的 StatefulSet 使用 RollingUpdate 方式更新：

BASH

root@k8s-master01:~/hhh# kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}'

查看更改后的 StatefulSet

BASH

然后改变容器的镜像触发滚动更新（此处使用的 jsonPath 的方式更改的资源配置，可以使用 set 或 edit 减少复杂度）

BASH

在更新过程中可以使用 kubectl rollout status sts/ 来查看滚动更新的状态：

BASH

查看更新后的镜像

BASH

（3）分段更新

比如我们定义一个分区"partition":3，可以使用 patch 或 edit 直接对 StatefulSet 进行设置：

BASH

root@k8s-master01:~/hhh#  kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate", "rollingUpdate":{"partition":3}}}}'

然后再次使用 patch 改变容器的镜像

BASH

删除 Pod 触发更新

BASH

root@k8s-master01:~/hhh# kubectl delete po web-2
pod "web-2" deleted

此时，因为 Pod web-2 的序号小于分区 3，所以 Pod 不会被更新，还是会使用以前的容器恢复 Pod。

BASH

将分区改为 2，此时会自动更新 web-2（因为之前更改了更新策略），但是不会更新 web-0 和 web-1：

BASH

root@k8s-master01:~/hhh#  kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}'

按照上述方式，可以实现分阶段更新，类似于灰度/金丝雀发布。查看最终的结果如下

BASH

4.6 删除 StatefulSet

删除StatefulSet有两种方式，即级联删除和非级联删除。使用非级联方式删除 StatefulSet时， StatefulSet 的 Pod 不会被删除；使用级联删除时，StatefulSet 和它的 Pod 都会被删除。

（1）非级联删除

使用 kubectl delete sts xxx 删除 StatefulSet 时，只需提供--cascade=false 参数，就会采用非级联删除，此时删除 StatefulSet 不会删除它的 Pod：

BASH

由于此时删除了 StatefulSet，它管理的 Pod 变成了“孤儿”Pod，因此单独删除 Pod 时，该 Pod 不会被重建：

BASH

再次创建 sts：

BASH

（2）级联删除

省略--cascade=false 参数即为级联删除

BASH

也可以使用-f 指定创建 StatefulSet 和 Service 的 yaml 文件，直接删除 StatefulSet 和 Service （此文件将 StatefulSet 和 Service 写在了一起）：

BASH

5.守护进程集 DaemonSet

创建一个 DaemonSet 和 Deployment 类似，比如创建一个 nginx 的 DaemonSet

YAML

（1）必需字段

和其他所有 Kubernetes 配置一样，DaemonSet 需要 apiVersion、kind 和 metadata 字段，同时也需要一个.spec 配置段。

（2）Pod 模板

spec 唯一需要的字段是.spec.template。.spec.template 是一个 Pod 模板，它与 Pod 具有相同的配置方式，但它不具有 apiVersion 和 kind 字段。除了 Pod 必需的字段外，在 DaemonSet 中的 Pod 模板必须指定合理的标签.

（3）Pod Selector

spec.selector 字段表示 Pod Selector，它与其他资源的.spec.selector 的作用相同。 .spec.selector 表示一个对象，它由如下两个字段组成：

spec.selector 由两个字段组成：
matchLabels：这是一个键值对的映射，用于指定要匹配的标签。它表示要选择的关联资源对象必须具有与这些标签匹配的标签。只有具有完全匹配的标签的资源对象才会与该选择器匹配。
matchExpressions：这是一个包含多个标签选择表达式的列表。每个表达式由键、操作符和值组成，用于更复杂的标签选择。常见的操作符包括 In、NotIn、Exists、DoesNotExist 等，可以根据需要进行组合使用。
通过定义 spec.selector，资源对象可以与其他资源对象进行关联，例如 Service 通过 spec.selector 来选择与之关联的 Pod，或者 Deployment 通过 spec.selector 来选择与之关联的 ReplicaSet。这种关联关系使得 Kubernetes 能够管理和控制相关资源之间的依赖和关联，实现它们之间的正确匹配和协同工作。

（4）指定节点部署 Pod

如果指定了.spec.template.spec.nodeSelector，DaemonSet Controller 将在与 Node Selector（节点选择器）匹配的节点上创建 Pod，比如部署在磁盘类型为 ssd 的节点上（需要提前给节点定义标签 Label）

YAML

nodeSelector:
 disktype: ssd

创建 DaemonSet

比如创建一个 nginx

BASH

更新和回滚 DaemonSet

如果添加了新节点或修改了节点标签（Label），DaemonSet 将立刻向新匹配上的节点添加 Pod，同时删除不能匹配的节点上的 Pod

在 Kubernetes 1.6 以后的版本中，可以在 DaemonSet 上执行滚动更新，未来的 Kubernetes 版本将支持节点的可控更新

DaemonSet 滚动更新可参考：https://kubernetes.io/docs/tasks/manage-daemon/update-daemonset/

DaemonSet 更新策略和 StatefulSet 类似，也有 OnDelete 和 RollingUpdate 两种方式。

查看上一节创建的 DaemonSet 更新方式：

BASH

root@k8s-master01:~/hhh# kubectl get ds nginx -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}'
RollingUpdate

命令式更新，和之前 Deployment、StatefulSet 方式一致

BASH

# kubectl edit ds/<daemonset-name>
# kubectl patch ds/<daemonset-name> -p=<strategic-merge-patch>

更新镜像

BASH

# kubectl set image ds/<daemonset-name><container-name>= <container-new-image> --record=true

查看更新状态

BASH

# kubectl rollout status ds/<daemonset-name>

列出所有修订版本

BASH

# kubectl rollout history daemonset <daemonset-name>

回滚到指定 revision

BASH

# kubectl rollout undo daemonset <daemonset-name> --to-revision=<revision>

DaemonSet 的更新和回滚与 Deployment 类似

6.HPA

6.1 HPA 接口类型

HPA v1为稳定版自动水平伸缩，只支持CPU指标

V2为beta版本，分为v2beta1(支持CPU、内存和自定义指标)

v2beta2(支持CPU、内存、自定义指标Custom和额外指标ExternalMetrics)

6.2 HPA 实践

创建一个具有CPU资源请求为10m的Deployment

YAML

BASH

root@k8s-master01:~/hhh# kubectl get  replicationcontrollers nginx 
NAME    DESIRED   CURRENT   READY   AGE
nginx   3         3         3       2m9s
root@k8s-master01:~/hhh# kubectl get pod
NAME          READY   STATUS    RESTARTS   AGE
nginx-5b97c   1/1     Running   0          2m18s
nginx-kdpmh   1/1     Running   0          2m18s
nginx-rgg8t   1/1     Running   0          2m18s

root@k8s-master01:~/hhh# kubectl describe replicationcontrollers nginx 
Name:         nginx
Namespace:    default
Selector:     app=nginx
Labels:       app=nginx
Annotations:  <none>
Replicas:     3 current / 3 desired
Pods Status:  3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age   From                    Message
  ----    ------            ----  ----                    -------
  Normal  SuccessfulCreate  4m8s  replication-controller  Created pod: nginx-kdpmh
  Normal  SuccessfulCreate  4m8s  replication-controller  Created pod: nginx-rgg8t
  Normal  SuccessfulCreate  4m8s  replication-controller  Created pod: nginx-5b97c

root@k8s-master01:~/hhh# kubectl delete pod nginx-5b97c
pod "nginx-5b97c" deleted
root@k8s-master01:~/hhh# kubectl get pod
NAME          READY   STATUS    RESTARTS   AGE
nginx-59vwh   1/1     Running   0          41s
nginx-kdpmh   1/1     Running   0          9m1s
nginx-rgg8t   1/1     Running   0          9m1s

root@k8s-master01:~/hhh# kubectl scale replicationcontroller --replicas=5 nginx 
replicationcontroller/nginx scaled
root@k8s-master01:~/hhh# kubectl get pod
NAME          READY   STATUS    RESTARTS   AGE
nginx-59vwh   1/1     Running   0          2m19s
nginx-b9q6p   1/1     Running   0          35s
nginx-kdpmh   1/1     Running   0          10m
nginx-n4lgs   1/1     Running   0          35s
nginx-rgg8t   1/1     Running   0          10m

root@k8s-master01:~/hhh# kubectl delete replicationcontroller  nginx 
replicationcontroller "nginx" deleted
root@k8s-master01:~/hhh# kubectl get pod
No resources found in default namespace.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      env: qa
    matchExpressions:
    - { key: tier, operator: In, values: [front-end] }
  template:
    metadata:
      name: nginx
      labels:
        env: qa
        tier: front-end
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

kubectl apply -f nginx.yml 
replicaset.apps/nginx created
root@k8s-master01:~/hhh# kubectl get pod
NAME          READY   STATUS    RESTARTS   AGE
nginx-jf2ct   1/1     Running   0          3s
nginx-qk9xk   1/1     Running   0          3s
nginx-vl575   1/1     Running   0          3s

root@k8s-master01:~/hhh# kubectl describe replicasets.apps nginx 
Name:         nginx
Namespace:    default
Selector:     env=qa,tier in (front-end)
Labels:       <none>
Annotations:  <none>
Replicas:     3 current / 3 desired
Pods Status:  3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  env=qa
           tier=front-end
  Containers:
   nginx:
    Image:        nginx
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age   From                   Message
  ----    ------            ----  ----                   -------
  Normal  SuccessfulCreate  18m   replicaset-controller  Created pod: nginx-vl575
  Normal  SuccessfulCreate  18m   replicaset-controller  Created pod: nginx-qk9xk
  Normal  SuccessfulCreate  18m   replicaset-controller  Created pod: nginx-jf2ct

kubectl scale replicaset --replicas=5 nginx
 
root@k8s-master01:~/hhh# kubectl scale replicaset --replicas=5 nginx
replicaset.apps/nginx scaled
root@k8s-master01:~/hhh# kubectl get pod
NAME          READY   STATUS    RESTARTS   AGE
nginx-jf2ct   1/1     Running   0          20m
nginx-ndkj9   1/1     Running   0          4s
nginx-pm6g2   1/1     Running   0          4s
nginx-qk9xk   1/1     Running   0          20m
nginx-vl575   1/1     Running   0          20m

root@k8s-master01:~/hhh# kubectl get pods nginx-jf2ct -o yaml | grep -A 5 owner
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: nginx

kubectl delete replicasets nginx --cascade=false
 
root@k8s-master01:~/hhh# kubectl delete replicasets nginx --cascade=false
warning: --cascade=false is deprecated (boolean value) and can be replaced with --cascade=orphan.
replicaset.apps "nginx" deleted
 
root@k8s-master01:~/hhh# kubectl get pods
NAME          READY   STATUS    RESTARTS   AGE
nginx-jf2ct   1/1     Running   0          24m
nginx-ndkj9   1/1     Running   0          4m51s
nginx-pm6g2   1/1     Running   0          4m51s
nginx-qk9xk   1/1     Running   0          24m
nginx-vl575   1/1     Running   0          24m
root@k8s-master01:~/hhh# kubectl get replicasets
No resources found in default namespace.

ReplicaSets和ReplicationController是Kubernetes中用于管理Pod副本的两种资源对象。它们在功能上有一些相似之处，但也有一些区别。
相似之处：
1. 目的：ReplicaSets和ReplicationController的主要目的都是确保在集群中运行指定数量的Pod副本，以实现应用程序的高可用性和负载均衡。
2. 选择器匹配：它们都使用选择器匹配来确定要管理的Pod副本。选择器匹配条件由标签（labels）定义。
区别：
1. API版本：ReplicaSets是在Kubernetes v1.8版本中引入的，而ReplicationController是早期版本的资源对象。因此，ReplicaSets是API版本为`apps/v1`，而ReplicationController是API版本为`v1`。
2. 滚动升级和回滚功能：ReplicaSets支持滚动升级和回滚功能，可以逐步更新Pod副本的版本，确保应用程序的平滑升级和回滚。而ReplicationController不直接支持滚动升级和回滚，需要使用其他工具或手动操作来实现这些功能。
3. 选择器匹配方式：ReplicaSets支持更灵活的选择器匹配方式。除了支持`matchLabels`字段外，还支持`matchExpressions`字段，可以使用更复杂的表达式来选择Pod副本。而ReplicationController只支持`matchLabels`字段，只能使用简单的标签匹配条件。
4. 自动缩放支持：ReplicaSets可以与Horizontal Pod Autoscaler（HPA）一起使用，实现根据CPU使用率等指标自动扩展或缩减Pod副本的数量。而ReplicationController没有原生的自动缩放支持，需要使用其他工具或手动操作来实现自动缩放。
总的来说，如果你在使用较新版本的Kubernetes，推荐使用ReplicaSets来管理Pod副本，因为它提供了更多功能和灵活性。但如果你在使用早期版本的Kubernetes或只需要基本的Pod副本管理功能，ReplicationController也是一个可行的选择。

这句话的意思是，Kubernetes官方强烈建议避免直接使用ReplicaSet来创建和管理Pod副本，而应该使用Deployment对象来管理ReplicaSet和Pod。
ReplicaSet是Kubernetes中一种控制器对象，用于确保指定数量的Pod副本正在运行。它是ReplicationController的升级版本，提供了更强大的选择器（selector）功能。选择器用于标识由ReplicaSet控制的Pod副本集合。
尽管ReplicaSet可以直接使用，但官方建议使用Deployment来管理ReplicaSet和Pod。Deployment是Kubernetes中的另一个控制器对象，它提供了对应用程序部署的声明性描述，可以方便地管理Pod副本的创建、更新和删除。
使用Deployment的好处包括：
1. 声明性描述：通过Deployment，您可以使用声明性的方式描述应用程序的期望状态，而不需要手动管理每个ReplicaSet和Pod的详细配置。
2. 滚动升级和回滚：Deployment允许您在应用程序升级时进行滚动升级，逐步替换旧的Pod副本。如果发生问题，您可以轻松地回滚到先前的版本。
3. 扩展和缩减：Deployment提供了方便的方法来扩展和缩减Pod副本的数量，以适应应用程序的负载变化。
4. 版本控制：使用Deployment，您可以轻松地管理应用程序的不同版本，跟踪每个版本的变更历史和部署状态。
总而言之，通过使用Deployment来管理ReplicaSet和Pod，您可以更方便地管理和控制应用程序的部署，实现滚动升级、回滚、扩展和缩减等操作，并且能够更好地跟踪和管理应用程序的版本。这也是Kubernetes官方强烈建议避免直接使用ReplicaSet的原因。

vim nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
   name: nginx-deployment
   labels:
     app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.12
        ports:
        - containerPort: 80

1. nginx-deployment：Deployment的名称；
2. replicas： 创建Pod的副本数；
3. selector：定义Deployment如何找到要管理的Pod，与template的label（标签）对应，apiVersion
为apps/v1必须指定该字段；
4. template字段包含以下字段：
app: nginx使用label（标签）标记Pod；
spec：表示Pod运行一个名字为nginx的容器；
image：运行此Pod使用的镜像；
Port：容器用于发送和接收流量的端口

root@k8s-master01:~/hhh# kubectl create -f  nginx.yaml 
root@k8s-master01:~/hhh# kubectl get deploy
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           2m1s
root@k8s-master01:~/hhh# kubectl describe deployments.apps nginx-deployment 
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Mon, 13 Nov 2023 07:47:56 +0000
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=nginx
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=nginx
  Containers:
   nginx:
    Image:        nginx:1.15.12
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-deployment-5c8578bf64 (3/3 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  3m4s  deployment-controller  Scaled up replica set nginx-deployment-5c8578bf64 to 3

root@k8s-master01:~/hhh# kubectl get rs -l app=nginx
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-5c8578bf64   3         3         3       6m3s

root@k8s-master01:~/hhh# kubectl get pods --show-labels
NAME                                READY   STATUS    RESTARTS   AGE    LABELS
nginx-deployment-5c8578bf64-hsgrx   1/1     Running   0          8m2s   app=nginx,pod-template-hash=5c8578bf64
nginx-deployment-5c8578bf64-v49pd   1/1     Running   0          8m2s   app=nginx,pod-template-hash=5c8578bf64
nginx-deployment-5c8578bf64-v5tdd   1/1     Running   0          8m2s   app=nginx,pod-template-hash=5c8578bf64

root@k8s-master01:~/hhh# kubectl set image deployment nginx-deployment nginx=nginx:1.9.1
 
root@k8s-master01:~/hhh# kubectl describe deployments.apps nginx-deployment 
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Mon, 13 Nov 2023 07:47:56 +0000
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 2
                        kubernetes.io/change-cause: kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
Selector:               app=nginx
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=nginx
  Containers:
   nginx:
    Image:        nginx:1.9.1
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  nginx-deployment-5c8578bf64 (0/0 replicas created)
NewReplicaSet:   nginx-deployment-7ffd5c8dc9 (3/3 replicas created)
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  41m    deployment-controller  Scaled up replica set nginx-deployment-5c8578bf64 to 3
  Normal  ScalingReplicaSet  3m48s  deployment-controller  Scaled up replica set nginx-deployment-7ffd5c8dc9 to 1
  Normal  ScalingReplicaSet  2m39s  deployment-controller  Scaled down replica set nginx-deployment-5c8578bf64 to 2 from 3
  Normal  ScalingReplicaSet  2m39s  deployment-controller  Scaled up replica set nginx-deployment-7ffd5c8dc9 to 2 from 1
  Normal  ScalingReplicaSet  105s   deployment-controller  Scaled down replica set nginx-deployment-5c8578bf64 to 1 from 2
  Normal  ScalingReplicaSet  105s   deployment-controller  Scaled up replica set nginx-deployment-7ffd5c8dc9 to 3 from 2
  Normal  ScalingReplicaSet  35s    deployment-controller  Scaled down replica set nginx-deployment-5c8578bf64 to 0 from 1

root@k8s-master01:~/hhh# kubectl rollout status deployment.v1.apps/nginx-deployment
 
Waiting for deployment "nginx-deployment" rollout to finish: 1 out of 3 
new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 
new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 
new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 
new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 1 old 
replicas are pending termination...
Waiting for deployment "nginx-deployment" rollout to finish: 1 old 
replicas are pending termination...
deployment "nginx-deployment" successfully rolled out

root@k8s-master01:~/hhh# kubectl get replicasets.apps 
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-5c8578bf64   3         3         3       48m
nginx-deployment-7ffd5c8dc9   0         0         0       9m58s

root@k8s-master01:~/hhh# kubectl describe deployments.apps nginx-deployment 
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Mon, 13 Nov 2023 07:47:56 +0000
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 3
                        kubernetes.io/change-cause: kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
Selector:               app=nginx
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=nginx
  Containers:
   nginx:
    Image:        nginx:1.15.12
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  nginx-deployment-7ffd5c8dc9 (0/0 replicas created)
NewReplicaSet:   nginx-deployment-5c8578bf64 (3/3 replicas created)
Events:
  Type    Reason             Age                From                   Message
  ----    ------             ----               ----                   -------
  Normal  ScalingReplicaSet  44m                deployment-controller  Scaled up replica set nginx-deployment-5c8578bf64 to 3
  Normal  ScalingReplicaSet  6m9s               deployment-controller  Scaled up replica set nginx-deployment-7ffd5c8dc9 to 1
  Normal  ScalingReplicaSet  5m                 deployment-controller  Scaled down replica set nginx-deployment-5c8578bf64 to 2 from 3
  Normal  ScalingReplicaSet  5m                 deployment-controller  Scaled up replica set nginx-deployment-7ffd5c8dc9 to 2 from 1
  Normal  ScalingReplicaSet  4m6s               deployment-controller  Scaled down replica set nginx-deployment-5c8578bf64 to 1 from 2
  Normal  ScalingReplicaSet  4m6s               deployment-controller  Scaled up replica set nginx-deployment-7ffd5c8dc9 to 3 from 2
  Normal  ScalingReplicaSet  2m56s              deployment-controller  Scaled down replica set nginx-deployment-5c8578bf64 to 0 from 1
  Normal  ScalingReplicaSet  21s                deployment-controller  Scaled up replica set nginx-deployment-5c8578bf64 to 1 from 0
  Normal  ScalingReplicaSet  19s                deployment-controller  Scaled down replica set nginx-deployment-7ffd5c8dc9 to 2 from 3
  Normal  ScalingReplicaSet  19s                deployment-controller  Scaled up replica set nginx-deployment-5c8578bf64 to 2 from 1
  Normal  ScalingReplicaSet  15s (x3 over 16s)  deployment-controller  (combined from similar events): Scaled down replica set nginx-deployment-7ffd5c8dc9 to 0 from 1

root@k8s-master01:~#  kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
2         kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
7         kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
8         kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
9         kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
10        kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
12        kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
13        kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
14        kubectl set image deployment nginx-deployment nginx=nginx:1.15.12 --record=true
15        kubectl set image deployment nginx-deployment nginx=nginx --record=true

root@k8s-master01:~# kubectl rollout history deployment/nginx-deployment --revision=14
deployment.apps/nginx-deployment with revision #14
Pod Template:
  Labels:	app=nginx
	pod-template-hash=5c8578bf64
  Annotations:	kubernetes.io/change-cause: kubectl set image deployment nginx-deployment nginx=nginx:1.15.12 --record=true
  Containers:
   nginx:
    Image:	nginx:1.15.12
    Port:	80/TCP
    Host Port:	0/TCP
    Environment:	<none>
    Mounts:	<none>
  Volumes:	<none>

root@k8s-master01:~#  kubectl rollout undo deployment/nginx-deployment
deployment.apps/nginx-deployment rolled back
再次查看更新历史
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
2         kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
7         kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
8         kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
9         kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
10        kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
12        kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
13        kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
15        kubectl set image deployment nginx-deployment nginx=nginx --record=true
16        kubectl set image deployment nginx-deployment nginx=nginx:1.15.12 --record=true

root@k8s-master01:~#  kubectl scale deployment.v1.apps/nginx-deployment --replicas=5
deployment.apps/nginx-deployment scaled
root@k8s-master01:~# kubectl get pod 
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-64888c994d-bzr5f   1/1     Running   0          2m22s
nginx-deployment-64888c994d-nmtqc   1/1     Running   0          9s
nginx-deployment-64888c994d-t9q2h   1/1     Running   0          9s
nginx-deployment-64888c994d-w5fj6   1/1     Running   0          2m26s
nginx-deployment-64888c994d-wfjfw   1/1     Running   0          2m24s

root@k8s-master01:~#  kubectl rollout history deployment.v1.apps/nginx-deployment
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
7         kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
8         kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
9         kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
10        kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
12        kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
13        kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
16        kubectl set image deployment nginx-deployment nginx=nginx:1.15.12 --record=true
17        kubectl set image deployment nginx-deployment nginx=nginx --record=true
18        kubectl set image deployment nginx-deployment nginx=nginx --record=true

root@k8s-master01:~# kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-77b488689f   5         5         5       18s

root@k8s-master01:~# kubectl rollout history deployment nginx-deployment 
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
7         kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
8         kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
9         kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
10        kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
12        kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true                                         13        kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true
16        kubectl set image deployment nginx-deployment nginx=nginx:1.15.12 --record=true
17        kubectl set image deployment nginx-deployment nginx=nginx --record=true
18        kubectl set image deployment nginx-deployment nginx=nginx --record=true
19        kubectl set image deployment nginx-deployment nginx=nginx --record=true

StatefulSet是Kubernetes中的一种资源对象，用于管理有状态应用程序的部署和管理。
与Deployment不同，StatefulSet旨在管理有状态的应用程序，这些应用程序通常需要持久性存储和稳定的网络标识。StatefulSet为这些应用程序提供了以下特性：
1. 稳定的网络标识：每个StatefulSet Pod都有一个唯一的网络标识符，通常以序号的形式命名，例如`<StatefulSetName>-<ordinal>`。这个网络标识符在Pod的整个生命周期中保持不变，即使Pod重新启动或迁移，它的标识符也不会改变。
2. 有序的部署和扩展：StatefulSet按照定义的序号顺序逐个创建和更新Pod。这确保了有状态应用程序的有序启动和关闭。当需要扩展StatefulSet时，新的Pod也会按照序号顺序逐个创建。
3. 稳定的持久性存储：StatefulSet可以与持久性存储卷（如PersistentVolume）结合使用，为每个Pod提供独立的持久性存储。这使得有状态应用程序可以在Pod重新启动或迁移时保持数据的持久性和一致性。
4. 有状态的服务发现：StatefulSet可以创建一个与每个Pod关联的稳定的网络服务。这个服务的DNS名称与Pod的网络标识符相对应，可以通过服务名称轻松地访问和发现每个有状态的Pod。
StatefulSet适用于需要有状态应用程序的场景，例如数据库（如MySQL、PostgreSQL）、分布式存储系统、消息队列等。它提供了一种可靠和可扩展的方式来管理这些有状态应用程序，并确保它们在Kubernetes集群中以有序和稳定的方式运行。

Headless Service（无头服务）是Kubernetes中的一种服务类型，与普通的服务类型（ClusterIP、NodePort、LoadBalancer）不同，它不会为服务创建一个负载均衡器或代理。
Headless Service的主要特点是它不会分配一个固定的虚拟IP地址给服务，而是通过DNS记录提供对服务中每个Pod的直接访问。当创建一个Headless Service时，Kubernetes会为该服务创建一个对应的DNS域名，该域名解析为服务中每个Pod的IP地址列表。
Headless Service的优势在于它提供了直接与服务中的每个Pod进行通信的能力，适用于以下场景：
1. 无头服务发现：通过Headless Service的DNS域名，可以直接获取服务中每个Pod的IP地址列表。这对于一些需要直接与每个Pod交互的应用程序非常有用，例如数据库集群、分布式存储系统等。
2. 自定义服务发现：由于Headless Service不涉及负载均衡器或代理，它允许应用程序自定义服务发现和负载均衡的逻辑。应用程序可以根据自身的需求选择和管理与服务中的Pod的通信方式。
3. 多副本应用程序的扩展性：对于一些需要保持多个副本之间状态同步的应用程序，使用Headless Service可以更好地控制数据同步和复制的逻辑。每个Pod都有唯一的DNS名称和IP地址，可以实现更精细的数据复制和同步策略。
需要注意的是，由于Headless Service不提供负载均衡功能，它的访问方式可能需要应用程序自己实现负载均衡和故障转移的逻辑。因此，在选择使用Headless Service时需要考虑应用程序的特性和需求，确保能够正确处理服务的访问和通信。

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        name: web

root@k8s-master01:~/hhh# kubectl create -f nginx.yaml 
service/nginx created
statefulset.apps/web created
 
root@k8s-master01:~/hhh# kubectl get statefulsets.apps 
NAME   READY   AGE
web    2/2     2m11s
 
root@k8s-master01:~/hhh# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.100.0.1   <none>        443/TCP   5d7h
nginx        ClusterIP   None         <none>        80/TCP    2m33s
 
root@k8s-master01:~/hhh# kubectl get pod -l app=nginx
NAME    READY   STATUS    RESTARTS   AGE
web-0   1/1     Running   0          74s
web-1   1/1     Running   0          56s

1.对于具有N个副本的StatefulSet，将按顺序从0到N-1开始创建Pod； 
2. 当删除Pod时，将按照N-1到0的反顺序终止； 
3. 在缩放Pod之前，必须保证当前的Pod是Running（运行中）或者Ready（就绪）； 
4. 在终止Pod之前，它所有的继任者必须是完全关闭状态。
 
StatefulSet 的 pod.Spec.TerminationGracePeriodSeconds（终止 Pod 的等待时间）不应该指定为 0，设置为 0 对 StatefulSet 的 Pod 是极其不安全的做法，优雅地删除 StatefulSet 的 Pod 是非常有必要的，而且是安全的，因为它可以确保在 Kubelet 从 APIServer 删除之前，让 Pod 正常关闭。
当创建上面的 Nginx 实例时，Pod 将按 web-0、web-1、web-2 的顺序部署 3 个 Pod。在 web-0 处于 Running 或者 Ready 之前，web-1 不会被部署，相同的，web-2 在 web-1 未处于 Running和 Ready 之前也不会被部署。如果在 web-1 处于 Running 和 Ready 状态时，web-0 变成 Failed（失败）状态，那么 web-2 将不会被启动，直到 web-0 恢复为 Running 和 Ready 状态。如果用户将 StatefulSet 的 replicas 设置为 1，那么 web-2 将首先被终止，在完全关闭并删除
web-2 之前，不会删除 web-1。如果 web-2 终止并且完全关闭后，web-0 突然失败，那么在 web-0 未恢复成 Running 或者 Ready 时，web-1 不会被删除。

root@k8s-master01:~/hhh#  kubectl scale sts web --replicas=5
statefulset.apps/web scaled
 
root@k8s-master01:~/hhh# kubectl get pods 
NAME    READY   STATUS    RESTARTS   AGE
web-0   1/1     Running   0          7m8s
web-1   1/1     Running   0          6m50s
web-2   1/1     Running   0          62s
web-3   1/1     Running   0          45s
web-4   1/1     Running   0          38s
 
root@k8s-master01:~/hhh# kubectl get pods -w -l app=nginx #动态查看

root@k8s-master01:~/hhh# kubectl patch sts web -p '{"spec":{"replicas":3}}'
statefulset.apps/web patched
 
此时可以看到第一个终端显示 web-4 和 web-3 的 Pod 正在被有序的删除（或终止）
root@k8s-master01:~# kubectl get pods -w -l app=nginx
NAME    READY   STATUS    RESTARTS   AGE
web-0   1/1     Running   0          8m27s
web-1   1/1     Running   0          8m9s
web-2   1/1     Running   0          2m21s
web-3   1/1     Running   0          2m4s
web-4   1/1     Running   0          117s
web-4   1/1     Terminating   0          2m18s
web-4   0/1     Terminating   0          2m19s
web-4   0/1     Terminating   0          2m20s
web-4   0/1     Terminating   0          2m20s
web-4   0/1     Terminating   0          2m20s
web-3   1/1     Terminating   0          2m27s
web-3   0/1     Terminating   0          2m28s
web-3   0/1     Terminating   0          2m28s
web-3   0/1     Terminating   0          2m28s
web-3   0/1     Terminating   0          2m28s
 
root@k8s-master01:~/hhh# kubectl get pods 
NAME    READY   STATUS    RESTARTS   AGE
web-0   1/1     Running   0          9m37s
web-1   1/1     Running   0          9m19s
web-2   1/1     Running   0          3m31s

root@k8s-master01:~/hhh# kubectl get sts web -o yaml | grep -A 1 "updateStrategy"
  updateStrategy:
    rollingUpdate:

root@k8s-master01:~/hhh# kubectl rollout status sts/web
Waiting for 1 pods to be ready...
Waiting for partitioned roll out to finish: 2 out of 3 new pods have been updated...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
partitioned roll out complete: 3 new pods have been updated...

root@k8s-master01:~/hhh#  for p in 0 1 2; do kubectl get po web-$p --template '{{range $i,$c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
dotbalo/canary:v1
dotbalo/canary:v1
dotbalo/canary:v1

root@k8s-master01:~/hhh# for p in 0 1 2; do kubectl get po web-$p --template '{{range $i,$c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
dotbalo/canary:v1
dotbalo/canary:v1
dotbalo/canary:v1

root@k8s-master01:~/hhh# for p in 0 1 2; do kubectl get po web-$p --template '{{range $i,$c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
dotbalo/canary:v1
dotbalo/canary:v1
k8s.gcr.io/nginxslim:0.7

root@k8s-master01:~/hhh# kubectl get po
NAME    READY   STATUS             RESTARTS   AGE
web-0   1/1     Running            0          9m17s
web-1   1/1     Running            0          9m35s
web-2   0/1     ImagePullBackOff   0          108s
root@k8s-master01:~/hhh#  kubectl delete statefulset web --cascade=false  # 采用非级联删除
warning: --cascade=false is deprecated (boolean value) and can be replaced with --cascade=orphan.
statefulset.apps "web" deleted
root@k8s-master01:~/hhh#  kubectl get sts # 查看此时 sts 已经被删
No resources found in default namespace.
root@k8s-master01:~/hhh# kubectl get po # 该 StatefulSet 管理的 Pod 并未被删除
NAME    READY   STATUS             RESTARTS   AGE
web-0   1/1     Running            0          10m
web-1   1/1     Running            0          10m
web-2   0/1     ImagePullBackOff   0          2m36s

root@k8s-master01:~/hhh# kubectl get po
NAME    READY   STATUS             RESTARTS   AGE
web-0   1/1     Running            0          10m
web-1   1/1     Running            0          10m
web-2   0/1     ImagePullBackOff   0          2m36s
root@k8s-master01:~/hhh# kubectl get po
NAME    READY   STATUS             RESTARTS   AGE
web-0   1/1     Running            0          11m
web-1   1/1     Running            0          11m
web-2   0/1     ImagePullBackOff   0          4m2s
root@k8s-master01:~/hhh#  kubectl delete po web-0
pod "web-0" deleted
root@k8s-master01:~/hhh# kubectl get po
NAME    READY   STATUS             RESTARTS   AGE
web-1   1/1     Running            0          12m
web-2   0/1     ImagePullBackOff   0          4m18s

root@k8s-master01:~/hhh# kubectl create -f  nginx.yaml 
root@k8s-master01:~/hhh# kubectl get po
NAME    READY   STATUS    RESTARTS   AGE
web-0   1/1     Running   0          69s
web-1   1/1     Running   0          39s

root@k8s-master01:~/hhh# kubectl delete statefulset web
statefulset.apps "web" deleted
root@k8s-master01:~/hhh# kubectl get po
No resources found in default namespace.

root@k8s-master01:~/hhh# kubectl delete -f nginx.yaml 
service "nginx" deleted
Error from server (NotFound): error when deleting "nginx.yaml": statefulsets.apps "web" not found
# 因为 StatefulSet 已经被删除，所以会提示该StatefulSet 不存在

apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    app: nginx
  name: nginx
spec:
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - image: nginx:1.15.12
       imagePullPolicy: IfNotPresent
       name: nginx

root@k8s-master01:~/hhh# kubectl create -f nginx.yaml 
daemonset.apps/nginx created
此时会在每个节点创建一个 Pod：
root@k8s-master01:~/hhh# kubectl get pod -owide
NAME          READY   STATUS              RESTARTS   AGE   IP               NODE        NOMINATED NODE   READINESS GATES
nginx-27c6k   0/1     ContainerCreating   0          48s   <none>           master-01   <none>           <none>
nginx-88dsv   1/1     Running             0          48s   10.200.58.230    node-02     <none>           <none>
nginx-gwx8c   1/1     Running             0          48s   10.200.135.130   node-03     <none>           <none>
nginx-qvhjw   0/1     ContainerCreating   0          48s   <none>           master-03   <none>           <none>
nginx-rxkk7   1/1     Running             0          48s   10.200.85.226    node-01     <none>           <none>
nginx-v6zfj   0/1     ContainerCreating   0          48s   <none>           master-02   <none>           <none>

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: registry.cn-beijing.aliyuncs.com/dotbalo/nginx
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 10m

 
# kubectl autoscale deployment nginx-server-hpa --cpu-percent=10 --min=1 --max=10
这将为nginx-server-hpa Deployment设置HPA，其中--cpu-percent=10表示当Pod的CPU利用率达到80%时，将增加副本数量，--min=1表示最小副本数为1，--max=10表示最大副本数为10。
通过执行上述步骤，你将创建一个具有HPA的Deployment，并根据CPU利用率自动调整副本数量。请根据你的需求调整HPA的参数值。
压力测试
 
root@k8s-master01:~/hhh# kubectl get pod nginx-deployment-c5cb98fc4-t6krf -owide
NAME                               READY   STATUS    RESTARTS   AGE    IP               NODE      NOMINATED NODE   READINESS GATES
nginx-deployment-c5cb98fc4-t6krf   1/1     Running   0          104s   10.200.135.134   node-03   <none>           <none>
root@k8s-master01:~/hhh# kubectl top pod 
NAME                               CPU(cores)   MEMORY(bytes)   
nginx-deployment-c5cb98fc4-t6krf   20m          2Mi             
 
root@k8s-master01:~# while true; do wget -q -O- http://10.200.135.134 > /dev/null; done
root@k8s-master01:~/hhh# kubectl get deployments.apps 
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/8     8            3           2m36s
root@k8s-master01:~/hhh# kubectl top pod 
NAME                               CPU(cores)   MEMORY(bytes)   
nginx-deployment-c5cb98fc4-6sqsc   0m           2Mi             
nginx-deployment-c5cb98fc4-8qhmr   0m           2Mi             
nginx-deployment-c5cb98fc4-c6kqw   0m           2Mi             
nginx-deployment-c5cb98fc4-d4fdm   0m           2Mi             
nginx-deployment-c5cb98fc4-fg9pc   0m           2Mi             
nginx-deployment-c5cb98fc4-mk5wc   0m           2Mi             
nginx-deployment-c5cb98fc4-qwwxc   0m           2Mi             
nginx-deployment-c5cb98fc4-t6krf   76m          2Mi             
nginx-deployment-c5cb98fc4-vl4qt   0m           2Mi             
nginx-deployment-c5cb98fc4-x6vgd   0m           2Mi    
 
必须安装metrics-server或其他自定义metrics-server
必须配置requests参数
不能扩容无法缩放的对象，比如DaemonSet