Kubernetes进阶对象Deployment、DaemonSet、Service

FLGB

已于 2024-06-07 17:54:20 修改

阅读量1.1k

点赞数 10

分类专栏： docker+k8s 文章标签： kubernetes linux 容器

于 2024-05-15 16:06:57 首次发布

本文链接：https://blog.youkuaiyun.com/FLGBgo/article/details/138856510

版权

Deployment

Pod 在 YAML 里使用“containers”就可以任意编排容器，而且还有一个“restartPolicy”字段，默认值就是 Always，可以监控 Pod 里容器的状态，一旦发生异常，就会自动重启容器。

不过，“restartPolicy”只能保证容器正常工作。如果容器之外的 Pod 出错了该怎么办呢？比如说，不小心用 kubectl delete 误删了 Pod，或者 Pod 运行的节点发生了断电故障，那么 Pod 就会在集群里彻底消失，对容器的控制也就无从谈起了。

在线业务远不是单纯启动一个 Pod 这么简单，还有多实例、高可用、版本更新等许多复杂的操作。比如最简单的多实例需求，为了提高系统的服务能力，应对突发的流量和压力，我们需要创建多个应用的副本，还要即时监控它们的状态。如果还是只使用 Pod，那就会又走回手工管理的老路，没有利用好 Kubernetes 自动化运维的优势。

Deployment 就是采用和 Job/CronJob 一样的形式——“对象套对象”，用来管理 Pod，实现在线业务应用的新 API 对象。

如何使用 YAML 描述 Deployment

用命令 kubectl api-resources 来看看 Deployment 的基本信息：

kubectl api-resources

#找到显示信息
NAME         SHORTNAMES   APIVERSION   NAMESPACED   KIND
deployments  deploy       apps/v1      true        Deployment

在这里插入图片描述

Deployment 的 YAML 文件头：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: xxx-dep

使用命令 kubectl create 来创建 Deployment 的 YAML 样板
创建了一个名字叫 ngx-dep 的对象，使用的镜像是 nginx:alpine：

export out="--dry-run=client -o yaml"
kubectl create deploy ngx-dep --image=nginx:alpine $out

在这里插入图片描述
根据模板稍微修改一下得到yml：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: ngx-dep
  name: ngx-dep
  
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ngx-dep
      
  template:
    metadata:
      labels:
        app: ngx-dep
    spec:
      containers:
      - image: nginx:alpine
        name: nginx

和 Job/CronJob 对比一下，你会发现有相似也有不同。相似的地方是都有“spec”“template”字段，“template”字段里也是一个 Pod；不同的地方在于它的“spec”部分多了 replicas、selector 这两个新字段。

replicas

replicas就相当于为 Kubernetes 明确了应用部署的“期望状态”，Deployment 对象就可以扮演运维监控人员的角色，自动地在集群里调整 Pod 的数量。
比如，Deployment 对象刚创建出来的时候，Pod 数量肯定是 0，那么它就会根据 YAML 文件里的 Pod 模板，逐个创建出要求数量的 Pod。
接下来 Kubernetes 还会持续地监控 Pod 的运行状态，万一有 Pod 发生意外消失了，数量不满足“期望状态”，它就会通过 apiserver、scheduler 等核心组件去选择新的节点，创建出新的 Pod，直至数量与“期望状态”一致。

selector

它的作用是“筛选”出要被 Deployment 管理的 Pod 对象，下属字段“matchLabels”定义了 Pod 对象应该携带的 label，它必须和“template”里 Pod 定义的“labels”完全相同，否则 Deployment 就会找不到要控制的 Pod 对象，apiserver 也会告诉你 YAML 格式校验错误无法创建。
这个 selector 字段的用法初看起来好像是有点多余，为了保证 Deployment 成功创建，我们必须在 YAML 里把 label 重复写两次：一次是在“selector.matchLabels”，另一次是在“template.matadata”。像在这里，你就要在这两个地方连续写 app: ngx-dep ：

...
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ngx-dep
      
  template:
    metadata:
      labels:
        app: ngx-dep
    ...

Deployment 和 Pod 实际上是一种松散的组合关系，Deployment 实际上并不“持有”Pod 对象，它只是帮助 Pod 对象能够有足够的副本数量运行，仅此而已。如果像 Job 那样，把 Pod 在模板里“写死”，那么其他的对象再想要去管理这些 Pod 就无能为力了
通过在 API 对象的“metadata”元信息里加各种标签（labels）这种设计，Kubernetes 就解除了 Deployment 和模板里 Pod 的强绑定，把组合关系变成了“弱引用”。

Deployment 与被它管理的 Pod 的组合关系
在这里插入图片描述

kubectl 操作 Deployment

Deployment 的 YAML 写好：

#创建yaml
touch deploy.yml
#编辑yaml,把之前修改好的Deployment内容copy进去
vim deploy.yml

创建Deployment对象

kubectl apply -f deploy.yml

要查看 Deployment 的状态，仍然是用 kubectl get 命令：

kubectl get deploy

在这里插入图片描述

READY 表示运行的 Pod 数量，前面的数字是当前数量，后面的数字是期望数量，所以“2/2”的意思就是要求有两个 Pod 运行，现在已经启动了两个 Pod。
UP-TO-DATE 指的是当前已经更新到最新状态的 Pod 数量。因为如果要部署的 Pod 数量很多或者 Pod 启动比较慢，Deployment 完全生效需要一个过程，UP-TO-DATE 就表示现在有多少个 Pod 已经完成了部署，达成了模板里的“期望状态”。
AVAILABLE 要比 READY、UP-TO-DATE 更进一步，不仅要求已经运行，还必须是健康状态，能够正常对外提供服务，它才是我们最关心的 Deployment 指标。
AGE 表示 Deployment 从创建到现在所经过的时间，也就是运行的时间。

检验 Deployment 效果

kubectl delete 删除一个 Pod，模拟一下 Pod 发生故障的情景：

kubectl delete pod ngx-dep-6796688696-jm6tt

再查看 Pod 的状态：

kubectl get pod -o wide

在这里插入图片描述

“惊喜”地发现，被删除的 Pod 确实是消失了，但 Kubernetes 在 Deployment 的管理之下，很快又创建出了一个新的 Pod，保证了应用实例的数量始终是我们在 YAML 里定义的数量。
证明Deployment 确实实现了它预定的目标，能够让应用“永远在线”“永不宕机”。

Deployment 扩缩容

在 Deployment 部署成功之后，你还可以随时调整 Pod 的数量，实现所谓的“应用伸缩”。

kubectl scale 是专门用于实现“扩容”和“缩容”的命令，你只要用参数 --replicas 指定需要的副本数量，Kubernetes 就会自动增加或者删除 Pod，让最终的 Pod 数量达到“期望状态”。

把 Nginx 应用扩容到了 5 个：

kubectl scale --replicas=5 deploy ngx-dep

最低0.47元/天解锁文章