首页 > 其他分享 >k8s 深入篇———— 守护容器[九]

k8s 深入篇———— 守护容器[九]

时间:2023-06-29 09:33:54浏览次数:39  
标签:容器 name Kubernetes fluentd DaemonSet Pod k8s 节点 守护

前言

守护容器,也叫做deamonset, 只做整理

正文

顾名思义,DaemonSet 的主要作用,是让你在 Kubernetes 集群里,运行一个 Daemon Pod。 所以,这个 Pod 有如下三个特征:

这个 Pod 运行在 Kubernetes 集群里的每一个节点(Node)上;

每个节点上只有一个这样的 Pod 实例;

当有新的节点加入 Kubernetes 集群后,该 Pod 会自动地在新节点上被创建出来;而当旧节点被删除后,它上面的 Pod 也相应地会被回收掉。

这个机制听起来很简单,但 Daemon Pod 的意义确实是非常重要的。我随便给你列举几个例子:

  1. 各种网络插件的 Agent 组件,都必须运行在每一个节点上,用来处理这个节点上的容器网络;

  2. 各种存储插件的 Agent 组件,也必须运行在每一个节点上,用来在这个节点上挂载远程存储目录,操作容器的 Volume 目录;

  3. 各种监控组件和日志组件,也必须运行在每一个节点上,负责这个节点上的监控信息和日志搜集。

更重要的是,跟其他编排对象不一样,DaemonSet 开始运行的时机,很多时候比整个 Kubernetes 集群出现的时机都要早。

这个乍一听起来可能有点儿奇怪。但其实你来想一下:如果这个 DaemonSet 正是一个网络插件的 Agent 组件呢?

这个时候,整个 Kubernetes 集群里还没有可用的容器网络,所有 Worker 节点的状态都是 NotReady(NetworkReady=false)。这种情况下,普通的 Pod 肯定不能运行在这个集群上。所以,这也就意味着 DaemonSet 的设计,必须要有某种“过人之处”才行。

为了弄清楚 DaemonSet 的工作原理,我们还是按照老规矩,先从它的 API 对象的定义说起。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: k8s.gcr.io/fluentd-elasticsearch:1.20
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

这个 DaemonSet,管理的是一个 fluentd-elasticsearch 镜像的 Pod。这个镜像的功能非常实用:通过 fluentd 将 Docker 容器里的日志转发到 ElasticSearch 中。

可以看到,DaemonSet 跟 Deployment 其实非常相似,只不过是没有 replicas 字段;它也使用 selector 选择管理所有携带了 name=fluentd-elasticsearch 标签的 Pod。

而这些 Pod 的模板,也是用 template 字段定义的。在这个字段中,我们定义了一个使用 fluentd-elasticsearch:1.20 镜像的容器,而且这个容器挂载了两个 hostPath 类型的 Volume,分别对应宿主机的 /var/log 目录和 /var/lib/docker/containers 目录。

显然,fluentd 启动之后,它会从这两个目录里搜集日志信息,并转发给 ElasticSearch 保存。这样,我们通过 ElasticSearch 就可以很方便地检索这些日志了。

需要注意的是,Docker 容器里应用的日志,默认会保存在宿主机的 /var/lib/docker/containers/{{. 容器 ID}}/{{. 容器 ID}}-json.log 文件里,所以这个目录正是 fluentd 的搜集目标。

那么,DaemonSet 又是如何保证每个 Node 上有且只有一个被管理的 Pod 呢?

显然,这是一个典型的“控制器模型”能够处理的问题。

DaemonSet Controller,首先从 Etcd 里获取所有的 Node 列表,然后遍历所有的 Node。这时,它就可以很容易地去检查,当前这个 Node 上是不是有一个携带了 name=fluentd-elasticsearch 标签的 Pod 在运行。

而检查的结果,可能有这么三种情况:

  1. 没有这种 Pod,那么就意味着要在这个 Node 上创建这样一个 Pod;

  2. 有这种 Pod,但是数量大于 1,那就说明要把多余的 Pod 从这个 Node 上删除掉;

  3. 正好只有一个这种 Pod,那说明这个节点是正常的。

其中,删除节点(Node)上多余的 Pod 非常简单,直接调用 Kubernetes API 就可以了。

但是,如何在指定的 Node 上创建新 Pod 呢?

如果你已经熟悉了 Pod API 对象的话,那一定可以立刻说出答案:用 nodeSelector,选择 Node 的名字即可。

nodeSelector:
    name: <Node 名字 >

没错。

不过,在 Kubernetes 项目里,nodeSelector 其实已经是一个将要被废弃的字段了。因为,现在有了一个新的、功能更完善的字段可以代替它,即:nodeAffinity。我来举个例子:

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: metadata.name
            operator: In
            values:
            - node-geektime

在这个 Pod 里,我声明了一个 spec.affinity 字段,然后定义了一个 nodeAffinity。其中,spec.affinity 字段,是 Pod 里跟调度相关的一个字段。关于它的完整内容,我会在讲解调度策略的时候再详细阐述。

而在这里,我定义的 nodeAffinity 的含义是:

  1. requiredDuringSchedulingIgnoredDuringExecution:它的意思是说,这个 nodeAffinity 必须在每次调度的时候予以考虑。同时,这也意味着你可以设置在某些情况下不考虑这个 nodeAffinity;

  2. 这个 Pod,将来只允许运行在“metadata.name”是“node-geektime”的节点上。

所以,我们的 DaemonSet Controller 会在创建 Pod 的时候,自动在这个 Pod 的 API 对象里,加上这样一个 nodeAffinity 定义。其中,需要绑定的节点名字,正是当前正在遍历的这个 Node。

此外,DaemonSet 还会给这个 Pod 自动加上另外一个与调度相关的字段,叫作 tolerations。这个字段意味着这个 Pod,会“容忍”(Toleration)某些 Node 的“污点”(Taint)。

而 DaemonSet 自动加上的 tolerations 字段,格式如下所示:

apiVersion: v1
kind: Pod
metadata:
  name: with-toleration
spec:
  tolerations:
  - key: node.kubernetes.io/unschedulable
    operator: Exists
    effect: NoSchedule

这个 Toleration 的含义是:“容忍”所有被标记为 unschedulable“污点”的 Node;“容忍”的效果是允许调度。

而在正常情况下,被标记了 unschedulable“污点”的 Node,是不会有任何 Pod 被调度上去的(effect: NoSchedule)。可是,DaemonSet 自动地给被管理的 Pod 加上了这个特殊的 Toleration,就使得这些 Pod 可以忽略这个限制,继而保证每个节点上都会被调度一个 Pod。当然,如果这个节点有故障的话,这个 Pod 可能会启动失败,而 DaemonSet 则会始终尝试下去,直到 Pod 启动成功。

假如当前 DaemonSet 管理的,是一个网络插件的 Agent Pod,那么你就必须在这个 DaemonSet 的 YAML 文件里,给它的 Pod 模板加上一个能够“容忍”node.kubernetes.io/network-unavailable“污点”的 Toleration。正如下面这个例子所示:

template:
    metadata:
      labels:
        name: network-plugin-agent
    spec:
      tolerations:
      - key: node.kubernetes.io/network-unavailable
        operator: Exists
        effect: NoSchedule

在 Kubernetes 项目中,当一个节点的网络插件尚未安装时,这个节点就会被自动加上名为node.kubernetes.io/network-unavailable的“污点”。

而通过这样一个 Toleration,调度器在调度这个 Pod 的时候,就会忽略当前节点上的“污点”,从而成功地将网络插件的 Agent 组件调度到这台机器上启动起来。

这种机制,正是我们在部署 Kubernetes 集群的时候,能够先部署 Kubernetes 本身、再部署网络插件的根本原因:因为当时我们所创建的 Weave 的 YAML,实际上就是一个 DaemonSet。

至此,通过上面这些内容,你应该能够明白,DaemonSet 其实是一个非常简单的控制器。在它的控制循环中,只需要遍历所有节点,然后根据节点上是否有被管理 Pod 的情况,来决定是否要创建或者删除一个 Pod。

只不过,在创建每个 Pod 的时候,DaemonSet 会自动给这个 Pod 加上一个 nodeAffinity,从而保证这个 Pod 只会在指定节点上启动。同时,它还会自动给这个 Pod 加上一个 Toleration,从而忽略节点的 unschedulable“污点”。

当然,你也可以在 Pod 模板里加上更多种类的 Toleration,从而利用 DaemonSet 实现自己的目的。比如,在这个 fluentd-elasticsearch DaemonSet 里,我就给它加上了这样的 Toleration:

tolerations:
- key: node-role.kubernetes.io/master
  effect: NoSchedule

这是因为在默认情况下,Kubernetes 集群不允许用户在 Master 节点部署 Pod。因为,Master 节点默认携带了一个叫作node-role.kubernetes.io/master的“污点”。所以,为了能在 Master 节点上部署 DaemonSet 的 Pod,我就必须让这个 Pod“容忍”这个“污点”。

kubectl create -f fluentd-elasticsearch.yaml

创建一下。

需要注意的是,在 DaemonSet 上,我们一般都应该加上 resources 字段,来限制它的 CPU 和内存使用,防止它占用过多的宿主机资源。

而创建成功后,你就能看到,如果有 N 个节点,就会有 N 个 fluentd-elasticsearch Pod 在运行。比如在我们的例子里,会有1个 Pod,如下所示:

因为我只弄了一个主节点

而如果你此时通过 kubectl get 查看一下 Kubernetes 集群里的 DaemonSet 对象:

就会发现 DaemonSet 和 Deployment 一样,也有 DESIRED、CURRENT 等多个状态字段。这也就意味着,DaemonSet 可以像 Deployment 那样,进行版本管理。这个版本,可以使用 kubectl rollout history 看到:

kubectl rollout history daemonset fluentd-elasticsearch -n kube-system

在 Kubernetes 项目中,任何你觉得需要记录下来的状态,都可以被用 API 对象的方式实现。当然,“版本”也不例外。

Kubernetes v1.7 之后添加了一个 API 对象,名叫ControllerRevision,专门用来记录某种 Controller 对象的版本。比如,你可以通过如下命令查看 fluentd-elasticsearch 对应的 ControllerRevision:

kubectl describe controllerrevision fluentd-elasticsearch-64dc6799c9 -n kube-system

就会看到,这个 ControllerRevision 对象,实际上是在 Data 字段保存了该版本对应的完整的 DaemonSet 的 API 对象。并且,在 Annotation 字段保存了创建这个对象所使用的 kubectl 命令。

接下来,我们可以尝试将这个 DaemonSet 回滚到 Revision=1 时的状态:

 kubectl rollout undo daemonset fluentd-elasticsearch --to-revision=1 -n kube-system

这个 kubectl rollout undo 操作,实际上相当于读取到了 Revision=1 的 ControllerRevision 对象保存的 Data 字段。而这个 Data 字段里保存的信息,就是 Revision=1 时这个 DaemonSet 的完整 API 对象。

所以,现在 DaemonSet Controller 就可以使用这个历史 API 对象,对现有的 DaemonSet 做一次 PATCH 操作(等价于执行一次 kubectl apply -f “旧的 DaemonSet 对象”),从而把这个 DaemonSet“更新”到一个旧版本。

这也是为什么,在执行完这次回滚完成后,你会发现,DaemonSet 的 Revision 并不会从 Revision=2 退回到 1,而是会增加成 Revision=3。这是因为,一个新的 ControllerRevision 被创建了出来。

ControllerRevision 和 ReplicaSet 是 Kubernetes 中的两个概念,它们之间有以下区别:

1. 功能:ControllerRevision 是一个记录控制器版本的资源对象,用于实现有状态应用程序的滚动更新。ReplicaSet 是一个控制器,用于管理 Pod 副本的创建、删除和扩缩容。

2. 对象类型:ControllerRevision 是一个自定义资源定义(Custom Resource Definition,CRD)对象,用于记录控制器的版本信息。ReplicaSet 是 Kubernetes 内置的资源对象,用于定义 Pod 副本集。

3. 控制器类型:ControllerRevision 用于有状态应用程序的滚动更新,例如 StatefulSet 控制器。ReplicaSet 用于无状态应用程序的副本管理,例如 Deployment 控制器。

4. 更新方式:ControllerRevision 通过记录每个版本的控制器模板和副本数来实现有状态应用程序的滚动更新。ReplicaSet 通过指定 Pod 模板和副本数量来创建和管理 Pod 副本。

5. 生命周期:ControllerRevision 的生命周期与控制器的滚动更新策略有关,它会记录每次控制器模板的变化。ReplicaSet 的生命周期与 Pod 副本集的创建和删除有关,它会根据副本数量的变化来创建或删除 Pod。

总的来说,ControllerRevision 是一个记录控制器版本的资源对象,用于实现有状态应用程序的滚动更新,而 ReplicaSet 是一个控制器,用于管理 Pod 副本的创建、删除和扩缩容。

下一节job 和 cronjob。

标签:容器,name,Kubernetes,fluentd,DaemonSet,Pod,k8s,节点,守护
From: https://www.cnblogs.com/aoximin/p/17512835.html

相关文章

  • Docker数据管理_数据卷容器
    Docker数据管理_数据卷容器Volume基本使用参数: create#创建数据卷 inspect#查看数据卷元数据 ls#查看数据卷列表 prune#删除所有未使用的卷 rm#删除数据卷创建一个自定义容器dockervolumecreateedc-tomcat-vol查看所有容器卷dockervolumels查看指定容器......
  • .net core IOC容器实现(三)--CallSite
    接着上面一节,这一节主要来看看callSite是如何生成的CallSite是通过CallSiteFactory.GetCallSite(TypeserviceType,CallSiteChaincallSiteChain)生成的,CallSiteFactory是在ServiceProvider里实例化的。代码如下privatereadonlyConcurrentDictionary<ServiceCacheKey,......
  • Docker 容器添加中文字体
    系统里有一个需要在图片上画中文的功能,在开发环境是ok的,一到线上Docker容器环境中文就不显示了,查了一些资料说是缺少中文字体,就在容器里安装中文字体。1.查看当前使用的系统语言:$echo$LANGen_US.UTF-8en_US.UTF-8是支持中文编码的,所以并不需要去安装中文编码的支持。......
  • k8s - 01
    k8s安装:https://www.cnblogs.com/zhh567/p/16894203.html结构apiserver用于管理各种网络接口,负责组件间的交互和对外暴露接口。etcd是位于master的数据库kube-scheduler编排容器kube-controllermanager管理cpu、内存等资源kubelet接收master发送的命令并进行处理......
  • (转)基于velero+minio对k8s进行备份和恢复
    原文:https://www.cnblogs.com/cyh00001/p/16548774.html一、velero介绍Velero是由vmware公司团队研发开源工具,用于安全地备份、恢复和迁移Kubernetes集群和持久卷。它可以在本地和公共云中运行。Velero由一个在您的Kubernetes集群中作为部署运行的服务器进程和一个命令行......
  • 看完这篇,你就了解了K8S的CKA认证考试的内容占比和具体考纲
    如果你正好想要了解关于Kubernetes(K8S)的CKA认证考试的内容占比和具体考纲,那么你来对地方了!本篇文章将详细解析CKA认证考试的内容占比以及具体考纲,让你对考试有一个清晰的了解。CKA(CertifiedKubernetesAdministrator)认证是云原生计算基金会(CNCF)推出的一项权威认证,目的......
  • 15款备受推崇的K8S可视化工具,你都玩过哪些?
    对于那些热爱探索新技术、寻找简化操作方式的运维工程师来说,如何更好地管理和操作K8S集群?本篇将分享15款备受推崇的K8S可视化工具,让你轻松管理和操作集群中的各种资源。你可能已经玩过其中的一些工具,这将是一个与你分享经验的机会哦!备受推崇的15款KubernetesDashboard:http......
  • k8s 深入篇———— 编排[八]
    前言简单整理一下编排。正文一个deployment例子:apiVersion:apps/v1kind:Deploymentmetadata:name:nginx-deploymentspec:selector:matchLabels:app:nginxreplicas:2template:metadata:labels:app:nginxspec:......
  • 在Docker容器中运行Spring Boot应用
    SpringBoot简化了Spring应用的开发过程,遵循约定优先配置的原则提供了各类开箱即用(out-of-the-box)的框架配置。另一方面,SpringBoot还具备将代码直接构建为可执行jar包的能力,这个jar包是一个可以独立运行的部署单元。基于以上特性,现在普遍认为SpringBoot提供了一种快速构造微服务(......
  • 【深入浅出Docker原理及实战】「Docker安装说明」零基础+全方位带你学习探索Docker容
    安装DockerDocker中的容器是一种轻量级的虚拟化技术,它基于镜像运行并具有自己的状态。下面是Docker容器的安装操作。Docker有三种更新频道:stable、test和nightly。官方网站提供了各种环境下的安装指南,主要包括Linux、Windows10和macOS。这里我们侧重点去介绍和分析说明对应......