Kubernetes基础_03_ReplicaSet全解析

Posted 2022-12-30 毛奇志

系列文章目录

文章目录

• 系列文章目录
• 前言
• 一、创建ReplicaSet
• • 1.1 ReplicatSet的三个属性
  • 1.2 从ReplicaSet看Pod
  • 1.3 从Pod看ReplicaSet
  • 1.4 ReplicaSet属性分析
  • • Replicas
    • Pod 选择算符
    • Pod 模板
• 二、使用ReplicaSet
• • 2.1 删除 ReplicaSet操作
  • • 2.1.1 删除 ReplicaSet 和它的 Pod
    • 2.1.2 只删除 replicaset
  • 2.2 ReplicaSet手动扩容缩容
  • 2.3 ReplicaSet自动扩容缩容
• 三、ReplicaSet的局限以及代替方案
• • 3.1 ReplicaSet的局限
  • 3.2 ReplicaSet 的替代方案
  • • 3.2.1 Deployment（推荐）
    • 3.2.2 裸 Pod
    • 3.2.3 Job
    • 3.2.4 DaemonSet
    • 3.2.5 ReplicationController
• 总结

---

前言

第二篇学习了Pod，这里介绍一下管理Pod的Controller，Controller包括RS、Deployment、StatefulSet、DaemonSet、Job/CronJob。

这些管理最小单元Pod的资源称为Controller，所有的Controller都是由静态Pod ControllerManager来管理的。

官网：https://kubernetes.io/docs/concepts/architecture/controller/

一、创建ReplicaSet

1.1 ReplicatSet的三个属性

ReplicaSet 是通过一组字段来定义的，包括三个属性：

(1) 一个用来识别可获得的 Pod 的集合的选择算符、
(2) 一个用来标明应该维护的副本个数的数值、
(3) 一个用来指定应该创建新 Pod 以满足副本个数条件时要使用的 Pod 模板。

每个 ReplicaSet 都通过根据需要创建和删除 Pod 以使得副本个数达到期望值， 进而实现其存在价值。当 ReplicaSet 需要创建新的 Pod 时，会使用所提供的 Pod 模板。

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # 按你的实际情况修改副本数
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

实践一下，上面那个镜像实际不了，换一个一个镜像，比如nginx
修改为 image: nginx:1.16.0

1.2 从ReplicaSet看Pod

kubectl describe rs xxx(rs-name) 这条命令从rs层面看Pod

1.3 从Pod看ReplicaSet

kubectl get pod xxx(pod-name) -o yaml 这条命令从Pod层面看ReplicaSet

1.4 ReplicaSet属性分析

ReplicaSet 需要 apiVersion、kind 和 metadata 字段。 对于 ReplicaSet 而言，其 kind 始终是 ReplicaSet。然后，ReplicaSet 也需要 .spec 部分。.spec 部分分为 副本数、选择器(选择算符)、Pod模板三个部分。

Replicas

你可以通过设置 .spec.replicas 来指定要同时运行的 Pod 个数。 ReplicaSet 创建、删除 Pod 以与此值匹配。如果你没有指定 .spec.replicas，那么默认值为 1。

Pod 选择算符

.spec.selector 字段是一个标签选择算符，这些是用来标识要被获取的 Pod 的标签。在签名的 frontend.yaml 示例中，选择算符为：

matchLabels:
  tier: frontend

在 ReplicaSet 中，.spec.template.metadata.labels 的值必须与 spec.selector 值相匹配，否则该配置会被 API 拒绝。

说明：对于设置了相同的 .spec.selector，但 .spec.template.metadata.labels 和 .spec.template.spec 字段不同的两个 ReplicaSet 而言，每个 ReplicaSet 都会忽略被另一个 ReplicaSet 所创建的 Pod。

Pod 模板

.spec.template 是一个 Pod 模板， 要求设置标签。在 frontend.yaml 示例中，我们指定了标签 tier: frontend。

对于模板的重启策略 字段，.spec.template.spec.restartPolicy，唯一允许的取值是 Always，这也是默认值.

二、使用ReplicaSet

2.1 删除 ReplicaSet操作

kubectl 命令支持级联删除。
(1) 当设置 --cascade=foreground，可以使用 kubectl 在前台删除附属对象。
(2) 当设置 --cascade=orphan，会使附属对象成为孤立附属对象。
(3) 当不指定 --cascade 或者明确地指定它的值为 background 的时候， 默认的行为是在后台删除附属对象。

2.1.1 删除 ReplicaSet 和它的 Pod

上面使用 kubectl apply -f replicaset.yaml 创建了 replicaset 和 pod，如果现在要删除 ReplicaSet 和它的所有 Pod，使用 kubectl delete replicaset xxx(rs-name) 命令 或者 kubectl delete -f replicaset.yaml 命令。执行此命令后， 默认情况下，Kubernetes 垃圾收集器 自动删除所有依赖的 Pod。

唯一注意的是，要删除的是replicaset，而不是下面一个或三个Pod，如果是删除一个或三个Pod，因为 replica 属性被设置为 3 ，被删除的Pod仍然会被创建出来。

kubectl get all -o wide
kubectl delete rs frontend 
kubectl get all -o wide

也可使用命令

# 第一个机器
kubectl proxy --port=8080

# 第二个机器
curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \\
  -d '"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"' \\
  -H "Content-Type: application/json"

2.1.2 只删除 replicaset

你可以只删除 ReplicaSet 而不影响它的各个 Pod，方法是使用 kubectl delete 命令并设置 --cascade=orphan 选项。

kubectl delete rs frontend --cascade=orphan

也可使用命令

# 第一个机器
kubectl proxy --port=8080

# 第二个机器
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend \\
  -d '"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"' \\
  -H "Content-Type: application/json"

2.2 ReplicaSet手动扩容缩容

通过更新 .spec.replicas 字段，ReplicaSet 可以被轻松地进行扩缩。ReplicaSet 控制器能确保匹配标签选择器的数量的 Pod 是可用的和可操作的。

直接修改 replicaset.yaml 文件来更新：

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # 按你的实际情况修改副本数
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: nginx:1.16.0

通过 kubectl 命令来更新：

kubectl scale replicaset frontend --replicas 5
kubectl scale replicaset frontend --replicas 1

2.3 ReplicaSet自动扩容缩容

Horizontal Pod Autoscaler(HPA)的控制器，用于实现基于CPU使用率进行自动Pod扩容和缩容的功能。HPA控制器基于Master的kube-controller-manager服务启动参数–horizontal-pod-autoscaler-sync-period定义的时长(默认周期为30s)，周期性地监测目标Pod的CPU使用率，并在满足条件时对ReplicationController或Deployment中的Pod副本数量进行调整，以符合用户定义的平均Pod CPU使用率。Pod CPU使用率来源于Heapster组件，所以需要预先安装好Heapster。

创建HPA时可以使用kubectl autoscale命令进行快速创建或者使用yaml配置文件进行创建。在创建HPA之前，需要已经存在一个Deployment/RC对象，并且该Deployment/RC中的Pod必须定义resources.requests.cpu的资源请求值，如果不设置该值，则Heapster将无法采集到该Pod的CPU使用情况，会导致HPA无法正常工作。

通过为一个RC设置HPA，然后使用一个客户端对其进行压力测试，对HPA的用法进行示例。

方式1：通过yaml文件来创建

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # 按你的实际情况修改副本数
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: nginx:1.16.0
        resources:
          requests:
            cpu: 200m
        ports:
        - containerPort: 80

apiVersion: v1
kind: Service
metadata:
  name: frontend
spec:
  ports:
  - port: 80
  selector:
    tier: frontend

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: frontend-scaler
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: ReplicaSet
    name: frontend
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

自动扩容缩容包括三个属性：
max 最大副本数Pod
min 最小副本数Pod
targetCPUUtilizationPercentage

三个apply之后如下：

还可以写一个脚本，作为压力测试，但是nginx的太棒了，这一点点压力根本无法引起 hpa 扩容

while true; do curl http://10.96.169.178:80/; done

方式2：通过命令来创建

kubectl autoscale rs frontend --max=10 --min=1 --cpu-percent=50

三、ReplicaSet的局限以及代替方案

3.1 ReplicaSet的局限

ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。 然而，Deployment 是一个更高级的概念，它管理 ReplicaSet，并向 Pod 提供声明式的更新以及许多其他有用的功能。 因此，我们建议使用 Deployment 而不是直接使用 ReplicaSet， 除非你需要自定义更新业务流程或根本不需要更新。

这实际上意味着，你可能永远不需要操作 ReplicaSet 对象：而是使用 Deployment，并在 spec 部分定义你的应用。

3.2 ReplicaSet 的替代方案

3.2.1 Deployment（推荐）

Deployment 是一个可以拥有 ReplicaSet 并使用声明式方式在服务器端完成对 Pod 滚动更新的对象。 尽管 ReplicaSet 可以独立使用，目前它们的主要用途是提供给 Deployment 作为编排 Pod 创建、删除和更新的一种机制。当使用 Deployment 时，你不必关心如何管理它所创建的 ReplicaSet，Deployment 拥有并管理其 ReplicaSet。 因此，建议你在需要 ReplicaSet 时使用 Deployment。

3.2.2 裸 Pod

与用户直接创建 Pod 的情况不同，ReplicaSet 会替换那些由于某些原因被删除或被终止的 Pod，例如在节点故障或破坏性的节点维护（如内核升级）的情况下。 因为这个原因，我们建议你使用 ReplicaSet，即使应用程序只需要一个 Pod。 想像一下，ReplicaSet 类似于进程监视器，只不过它在多个节点上监视多个 Pod， 而不是在单个节点上监视单个进程。 ReplicaSet 将本地容器重启的任务委托给了节点上的某个代理（例如，Kubelet）去完成。

3.2.3 Job

使用Job 代替 ReplicaSet， 可以用于那些期望自行终止的 Pod。

3.2.4 DaemonSet

对于管理那些提供主机级别功能（如主机监控和主机日志）的容器， 就要用 DaemonSet 而不用 ReplicaSet。 这些 Pod 的寿命与主机寿命有关：这些 Pod 需要先于主机上的其他 Pod 运行， 并且在机器准备重新启动/关闭时安全地终止。

3.2.5 ReplicationController

ReplicaSet 是 ReplicationController 的后继者。二者目的相同且行为类似，只是 ReplicationController 不支持 标签用户指南 中讨论的基于集合的选择算符需求。 因此，相比于 ReplicationController，应优先考虑 ReplicaSet。

---

总结