云原生05-Pod高级-Replicaset-Deployment

Replicaset 控制器：概念、原理解读

概念

假设你有一个容器应用程序，需要在·Kubernetes·集群中运行。这个应用程序需要多个相同的 Pod·实例来处理用户请求，以确保应用程序的高可用性和性能。但是，由于：Pod·可能会因为各种原因而停止运行（例如，节点故障、资源不足、应用程序崩溃等），因此你需要一种机制来确保始终有足够数量的：Pod·实例在运行。

这时候，就可以使用·ReplicaSet·来管理这些·Pod·实例。ReplicaSet·可以定义应该运行多少个相同的·Pod·实例，以及在某个Pod·实例失败时如何自动创建新的·Pod·实例来替代。 ReplicaSet·还可以根据资源利用率自动调整·Pod·实例的数量，以确保应用程序始终能够处理用户请求。

简单来说，ReplicaSet·可以帮助你确保你的应用程序始终能够提供足够的容量和可用性，而无需手动管理多个·Pod·实例。

工作原理：如何管理pod

ReplicaSet·的工作原理可以简单概括为：它不断地检查当前集群中的·Pod·副本数量是否符合用户定义的期望数量，如果数量不足，则会自动创建新的·Pod·副本来满足期望数量，如果数量过多，则会删除一些·Pod·副本以满足期望数量。

具体来说，当创建一个·ReplicaSet·时，需要定义以下参数： 1、模板（template）：指定了要创建的·Pod·的规格和属性； 2、副本数量（replicas）：指定了要创建的·Pod·的副本数量； 3、选择器（selector）：指定了要选择哪些·Pod·实例，以确保它们的标签与·ReplicaSet·的标签相匹配。

一旦·ReplicaSet·创建完成，它会不断地监控集群中符合选择器要求的·Pod·实例数量，如果实际数量小于期望数量，则会自动创建新的·Pod·实例，如果实际数量多于期望数量，则会自动删除一些·Pod·实例。

总之，ReplicaSet·是·Kubernetes·中用来管理·Pod·实例数量的核心组件，它通过自动创建和删除·Pod·实例来确保应用程序的高可用性和可伸缩性。简写成 rs。

Replicaset资源清单文件编写技巧

kubectl explain rs

1）apiVersion：表示当前资源使用的·APl·版本，通常为·"apps/v1"。 2）kind：表示资源类型，即."ReplicaSet"。 3）metadata：包括·name、namespace、labels、annotations·等字段，用于定义 Replicaset·的元数据信息。 4）spec：包括·replicas、selector、template·等字段，用于定义·Replicaset·的规格，包括副本数、标签选择器和·Pod·模板等。 5）status：包括·replicas、available、Replicas、readyReplicas·等字段，用于记录当前 Replicaset·的状态信息，例如副本数、可用副本数和就绪副本数等。注意：status·字段是只读的，不能手动修改。

kubectl explain rs.spec

1）replicas：表示需要创建的·Pod·副本数。个 2）selector：用于匹配要管理的·Pod·的标签选择器，通常是一个·key-value·对，例如 matchLabels:-{app:-nginx)。 3）template：定义·Pod·的模板，基于该模板创建的所有·Pod·都是相同的。模板中包含了 Pod·的元数据和规格信息，例如·Pod·的名称、标签、容器镜像、容器端口等。

kubectl explain rs.spec.template.spec

activeDeadlineSeconds:定义Pod的运行时间限制（秒）。
affinity:用于定义Pod如何调度到节点上的规则，可指定nodeSelector、nodeAffinity和podAffinity/podAntiAffinity。
automountServiceAccountToken:是否自动挂载Service·Account的token到Pod中
containers:定义Pod中的容器列表，该字段是必需的。
dnsConfig:定义Pod中的DNS配置，如DNS服务器的IP地址和搜索域。
dnsPolicy:定义Pod中的DNS策略，如使用ClusterFirst或Default
ephemeralContainers:定义Pod中的临时容器列表，这些容器具有短暂的生命周期，例如用于调试或临时的数据处理。
hostAliases:I定义Pod中的hosts文件条目。
hostIPC：是否允许容器共享IPC命名空间。
hostNetwork:是否将Pod的网络命名空间与主机共享。
hostPID：是否允许容器共享主机PID命名空间。
hostUsers:是否允许容器共享主机用户命名空间。
hostname:定义Pod的主机名。
imagePullSecrets:定义从私有仓库中拉取镜像所需的身份验证信息。
initContainers：定义Pod中的初始化容器列表，这些容器在主容器启动之前运行。
nodeName:定义Pod所在的节点名称。
nodeSelector:用于定义Pod应该调度到哪些节点上。
os:定义Pod所在的操作系统类型和版本。
overhead:定义Pod需要的CPU、内存和存储资源之外的其他资源。
preemptionPolicy:定义 Pod 被抢占的行为，如 Never、PreemptLowerPriority 或 PreemptNever。
priority:定义Pod的调度优先级。
priorityClassName:定义Pod使用的调度优先级类名称。
readinessGates:定义Pod的就绪探针列表，这些探针用于检查容器是否已准备好接受流量。
resourceClaims:定义Pod使用的资源声明列表。
restartPolicy:定义Pod 的重启策略，如Always、OnFailure 或Never。
runtimeClassName：定义Pod使用的容器运行时类名称。
schedulerName:定义Pod使用的调度器名称。
schedulingGates:定义Pod的调度探针列表，这些探针用于检查节点是否已准备好接受Pod。
securityContext:定义Pod的安全上下文。
serviceAccount:定义Pod使用的Service·Account的名称。
serviceAccountName:定义Pod使用的Service·Account的名称。
setHostnameAsFQDN:是否将Pod的主机名设置为完全限定域名。
shareProcessNamespace：是否允许容器共享主机命名空间。如果将此字段设置为true，则在同一Pod中的容器可以共享主机的PID命名空间、IPC命名空间和UTS命名空间。这使得容器之间可以相互查看和访问进程、共享进程、文件系统和其他资源。通常情况下，建议不要将此设置为true，以提高容器之间的安全性和隔离性。

实战：Replicaset使用案例-部署Guestbook留言板

# 2台工作节点均要拉取
$ ctr -n=k8s.io images pull docker.io/yecc/gcr.io-google_samples-gb-frontend:v3
$ ctr -n=k8s.io images pull docker.io/ikubernetes/myapp:v1

replicate.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  replicas: 2
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
        - name: php-redis
          image: yecc/gcr.io-google_samples-gb-frontend:v3
          imagePullPolicy: IfNotPresent

现在会一直保证为设置的副本数，kill 会增加，扩容和缩容均可 apply -f 后生效，基于上面YAML文件更新replicaset资源里面的image字段之后，pod不会自动重新创建，也不会用的新的镜像，需要把pod手动删除，重新创建pod之后才会用新的镜像。

Deployment控制器：概念、原原理解读

Deployment 概念

虽然ReplicaSet已经可以用来控制Pod的副本数量和自动重启，但是ReplicaSet仅仅是Pod 的一个管理器，它只能保证有一定数量的Pod在运行，但是对于如何更新Pod、回滚到历史版本等操作，ReplicaSet并不支持或者说不够方便。而Deployment则在ReplicaSet的基础上增加了更多的功能，它可以用来部署应用程序，并且支持更方便的应用程序更新、回滚和扩容缩容操作。Deployment通过定义副本控制器的方式来管理Pod的副本，它可以方便地进行版本控制，而且支持自动更新和回滚，能够保证应用程序的高可用性。另外，Deployment还支持滚动升级和滚动回滚，可以在不影响应用程序运行的情况下，实现无缝升级和回滚操作。

Deployment工作原理：如何管理rs和Pod？

Deployment 通过创建和管理ReplicaSet和 Pod来实现对应用的部署和管理。当 Pod 需要更新时，Deployment会根据新的Pod 模板创建新的 ReplicaSet，并逐步增加新的Pod副本，同时逐渐减少旧的ReplicaSet的Pod副本数量，直到新的ReplicaSet 中所有Pod副本都处于运行状态。具体来说，Deployment包括以下几个步骤：

创建初始的 ReplicaSet 和 Pod：Deployment 根据指定的 Pod 模板创建初始的 ReplicaSet 和 Pod，同时设置 Pod 的标签。
更新Pod模板：当需要更新Pod模板时，Deployment会根据新的Pod模板创建一个新的 ReplicaSet，并逐渐增加新的 Pod 副本，同时逐渐减少旧的 ReplicaSet 的 Pod 副本数量，直到新的 ReplicaSet 中所有Pod 副本都处于运行状态。
回滚操作：如果新的Pod 模板存在问题，需要回滚操作时，Deployment 会根据旧的 Pod 模板创建一个ReplicaSet，并逐渐增加旧的 ReplicaSet的Pod 副本数量，同时逐渐减少新的 ReplicaSet的 Pod 副本数量，直到l旧的 ReplicaSet 中所有Pod 副本都处于运行状态。
扩容和缩容：Deployment 可以通过修改ReplicaSet的副本数量来扩容和缩容应用。
deploy-demo.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v1
  namespace: blue-green
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 get rs -n blue-green
NAME                  DESIRED   CURRENT   READY   AGE
myapp-v1-58bdffcdd7   2         2         2       55d

说明:

NAME       指定名称 + 随机数
DESIRED     期望的 Pod 副本数量
CURRENT 当前实际存在的 Pod 副本数量
READY   已就绪的 Pod 副本数量, 即就绪探测的数量
AGE     ReplicaSet 存活时间

$ kubectl get pods -n blue-green -owide
NAME                        READY   STATUS    RESTARTS      AGE   IP               NODE       NOMINATED NODE   READINESS GATES
myapp-v1-58bdffcdd7-4kxtt   1/1     Running   1 (27d ago)   55d   10.250.209.170   xuegod64   <none>           <none>
myapp-v1-58bdffcdd7-jjb6p   1/1     Running   1 (27d ago)   55d   10.250.209.169   xuegod64   <none>           <none>

说明

NAME    rs名称 + 随机数

实战Deployment管理pod-扩容、缩容、滚动更新、回滚

都可直接改yaml 文件完成

# 查看历史版本，但此处还是不方便查看
$ kubectl rollout history deployment myapp-v1 -n blue-green
deployment.apps/myapp-v1 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
# 回滚
$ kubectl rollout undo deployment myapp-v1 -n blue-green --to-revision=1

一般就通过修改镜像来回滚

kubectl 常用命令补充

`kubectrl cordon` 禁止调度，进入维护状态

在实际维护的时候会出现某个node坏掉，或者做一些处理，暂时不能让生成的pod在此 node上运行，需要通知kubernetes让其不要创建过来，这条命令就是cordon，uncordon则是取消这个要求。

$ kubectl cordon xuegod64
# 进入 SchedulingDisabled 
$ kubectl get nodes
NAME       STATUS                     ROLES           AGE   VERSION
xuegod62   Ready                      worker          64d   v1.26.0
xuegod63   Ready                      control-plane   64d   v1.26.0
xuegod64   Ready,SchedulingDisabled   worker          64d   v1.26.0
# 恢复
$ kubectl uncordon xuegod64

`kubectl uncordon` 禁止调度，进入维护状态，强制删除pod

# 禁止调度，删除 除 daemonsets 控制器调度的其它pod，删除没有持久化的pod
$ kubectl drain xuegod62 --ignore-daemonsets --delete-emptydir-data
# 恢复
$ kubectl uncordon xuegod62

配置自动补全

kubectrl scale 对控制器资源扩容

# 将副本数由 2 扩容到 3
$ kubectl scale --current-replicas=2 --replicas=3 deployment/myapp-v1 -n blue-green
deployment.apps/myapp-v1 scaled
$ kubectl get deploy -n blue-green
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
myapp-v1   2/3     3            2           55d
$ kubectl get deploy -n blue-green
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
myapp-v1   3/3     3            3           55d

建议还是通过yaml文件来管理扩缩容

kubectrl autoscale 自动伸缩

autoscale命令用于自动扩展确认，scale需要手动执行，而autoscale则会根据负载进行调解。而这条命令则可以对Deployment进行设定，通过最小值和最大值的指定进行设定。

# 对扩缩容进行限制
$ kubectl autoscale deployment myapp-v1 --min=2 --max=10 -n blue-green
# 限制后会加入到 hpa
$ kubectl get hpa -n blue-green
NAME       REFERENCE             TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
myapp-v1   Deployment/myapp-v1   <unknown>/80%   2         10        3          3m2s
# 删除扩缩容限制 hpa
$ kubectl delete hpa myapp-v1 -n blue-green