Kubernetes(k8s)-Deployment介绍

作者介绍：简历上没有一个精通的运维工程师。希望大家多多关注作者，下面的思维导图也是预计更新的内容和当前进度(不定时更新)。

我们上一章介绍了Docker基本情况，目前在规模较大的容器集群基本都是Kubernetes，但是Kubernetes涉及的东西和概念确实是太多了，而且随着版本迭代功能在还增加，笔者有些功能也确实没用过，所以只能按照我自己的理解来讲解。

我们上一小节介绍了k8s的第一个控制器ReplicaSets，也同时说明了，我们一般不会单独使用，而是使用更高级的Deployment(也可以简称deploy)。

Deployment 是 Kubernetes 中一种高级的资源对象，它主要用于管理无状态应用的部署。与 ReplicaSet 类似，Deployment 也确保了一定数量的 Pod 副本处于运行状态，但它提供了更多的功能和灵活性，特别是在应用程序的滚动更新、回滚、扩展等方面。

以下是关于 Deployment 的一些关键点：

声明式定义：用户可以以声明的方式描述所需的应用程序的状态，Kubernetes 将负责将当前状态转换为所需状态。

滚动更新：支持滚动更新（Rolling Update），即在不停机的情况下逐步更新应用程序的新版本。通过控制更新策略，如最大不可用（maxUnavailable）和最大浪涌（maxSurge），可以最小化对服务的影响。

回滚能力：如果新版本的应用出现问题，Deployment 可以很容易地回滚到之前的稳定版本。历史修订版本会被保存下来，使得回滚操作变得简单。但是个人使用这个较少，因为这个需要单独对变更进行记录。

kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="升级到 Nginx 1.19.0"

自动扩展：结合 Horizontal Pod Autoscaler (HPA)，可以根据 CPU 使用率或其他自定义指标自动调整 Pod 数量，这个后面会单独讲。

健康检查：可以配置 Liveness 和 Readiness 探针来监控 Pod 的健康状况，确保只有健康的 Pod 才会接收流量，或者后面会单独讲。

版本控制：每次更新都会创建一个新的 ReplicaSet，并保留旧的 ReplicaSet 作为历史记录的一部分，方便进行回滚。

简化操作：提供了更简化的命令行工具和 API 来管理和操作应用，例如 kubectl rollout 系列命令。

使用场景

无状态应用：适用于那些不需要持久化存储或状态的应用程序。

频繁更新的应用：对于需要频繁更新的应用程序，Deployment 提供了安全可靠的更新机制。

需要高可用性的服务：通过确保多个副本同时运行，提高了服务的可用性和容错性。

范例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3  # 设置你想要维持的Pod副本数量
  selector:
    matchLabels:
      app: nginx  # 定义选择器，用于确定哪些Pod属于此Deployment
  strategy:
    type: RollingUpdate  # 滚动更新策略(不注明，默认也有)
    rollingUpdate:
      maxUnavailable: 25%  # 最大不可用Pod的比例
      maxSurge: 25%        # 最大浪涌Pod的比例
  template:  # 这是创建新Pod时使用的模板
    metadata:
      labels:
        app: nginx  # 确保Pod标签与选择器匹配
    spec:
      containers:
      - name: nginx
        image: nginx  # 使用Nginx镜像
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80  # 容器监听的端口

kubectl set image \
deployment/nginx-deployment  \
nginx=nginx:1.19.0 

1.更新镜像命令下发。

2.创建了一个新的rs，以新的镜像开始创建pod。

3.由于新的镜像我这里故意设置的是错误的，所以他会失败，新的rs无法按照预期更新，所以老的rs也不会减少。

4.下图是正常的更新的，可以发现，创建了一个新的rs，然后开始创建pod，旧的rs开始减少，直到全部替换完成。

#修改副本数量
kubectl scale deployment/nginx-deployment --replicas=5
#这个时候他会自动扩容rs，他不会创建新的rs
deployment.apps/nginx-deployment scaled
[root@master01 ~]# kubectl  get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-66857ff745   0         0         0       5m58s
nginx-deployment-7758d854d    0         0         0       5m33s
nginx-deployment-7b66c5699c   5         5         5       2m39s

关于pod的名字，从上面的名字我们可以看出来pod的名字构成是

deployment名字-rs名字-随机字符，通过这个名字我们也可以看出来这个rs的名字，然后可以根据pod名字反过来查看rs的名字，正常的pod只有有一个rs名字，如果出现一个deployment产生的pod名字出现2个rs名字就说明这个更新出现问题。

deploy可以说是普通k8s集群中使用最广泛的资源，没有之一。大部分业务都会通过deployment来呈现，对他最重要的修改其实就是修改镜像(版本发布，即便回滚也可以通过修改镜像实现)。我们的对deploy的的修改可以用我们上面的两种方法，也可以使用编辑资源方式(也使用其他允许编辑的资源)，具体可以根据自己的需要或者掌握熟悉程度来选择。

 kubectl  edit deploy nginx-deployment
 #虽然我们定义deploy的时候定义了一些参数
 #但是实际上还有很多未定义的参数也会以默认参数存在

​​​​​​​

运维小路

一个不会开发的运维！一个要学开发的运维！一个学不会开发的运维！欢迎大家骚扰的运维！

关注微信公众号《运维小路》获取更多内容。