【k8s】deamonset文件和说明

目录

deamonset的相关命令

deamonset的定义

deamonset的使用场景

deamonset的例子

deamonset字段说明

serviceAccountName

DaemonSet的结构及其各个部分的作用

---

deamonset的相关命令
 

#查看<name-space>空间内有哪些deamonset
kubectl get DaemonSet  -n  <name-space>   

#查看<pod name>的deamonset
kubectl describe DaemonSet -n <name-space>  <pod name>

#导出 <name-space>空间内<pod name>的deamonset
kubectl get daemonset <pod name> -n <name-space>  -o yaml > daemonset.yaml

#应用某个deamonset  （给k8s加载这个DaemonSet文件）
kubectl create -f nginx-deployment.yaml

deamonset的定义

官方说明：

        DaemonSet 是 Kubernetes 集群中的一种资源对象，用来确保所有（或某些特定）节点上都运行该容器的副本。DaemonSet 确保当有节点加入集群时，节点上会启动你指定的容器；同时当节点从集群中移除时，这些容器也会被垃圾回收。

举个例子，如果你有一个名为 daemonset.yaml 的文件，你可以通过以下命令将其应用到 Kubernetes 集群：

kubectl apply -fdaemonset.yaml

这个命令告诉 kubectl 根据 daemonset.yaml 文件中定义的配置来在集群中创建或更新资源

大白话：

这个文件是一个K8S资源描述文件，它定义了一个DaemonSet资源，

DaemonSet告诉K8S如何在集群所有（或部分）节点上运行Pod的副本。

DaemonSet 最常见的应用场景之一是在节点上部署系统级守护进程。例如，Kubernetes 官方提供的 kube-proxy 和 kube-dns 组件都是以 DaemonSet 的形式运行在每个节点上的。

deamonset的使用场景

1,根据dockerfile文件生成了一个pod的镜像 

让k8s 把这个pod镜像要在哪些节点上运行，需要哪些资源（port,内存等），就需要一个配置文件告诉k8s，这个就是DaemonSet文件。

2，配置DaemonSet文件，告诉K8s在哪些节点运行这个pod镜像，给这个pod镜像分配什么资源等。

3，给k8s加载这个DaemonSet文件

deamonset的例子

    在下面这个 YAML 文件中，我们定义了一个 Deployment 对象，它的主体部分（spec.template 部分）是一个使用 Nginx 镜像的 Pod，而这个 Pod 的副本数是 2（replicas=2）。

apiVersion: apps/v1 kind: Deployment metadata:   name: nginx-deployment    #这个pod的名字   labels:     app: nginx spec:   replicas: 2   selector:     matchLabels:       app: nginx   template:     metadata:       labels:         app: nginx     spec:       containers:       - name: nginx             #pod 内第一个容器的名字         image: nginx:1.7.9   #<---镜像的id，确保这个镜像已经拉到本地了         ports:         - containerPort: 80

使用下面的命令给k8s加载这个DaemonSet文件

$ kubectl create -f nginx-deployment.yaml

这样k8s就根据DaemonSet的要求把这个pod 在集群的节点上运行了。

deamonset字段说明

以下是该文件内容的详细解释：
- `apiVersion: apps/v1`: 使用的API版本，表示这是一个稳定版本的DaemonSet。
- `kind: DaemonSet`: 资源类型是DaemonSet。
- `metadata`: 包含用于描述DaemonSet的元数据。
  - `annotations`: 包含键值对的注释信息。
    - `deprecated.daemonset.template.generation`: 这个注解表示这个DaemonSet的控制器检测到template是第二次改变。
  - `creationTimestamp`: DaemonSet资源创建的时间标记。
  - `generation`: 表示DaemonSet的版本，每次修改DaemonSet时都会递增。
  - `name`: DaemonSet的名字是`engine-peon`。
  - `namespace`: DaemonSet被创建在`product-storage`命名空间下。
  - `resourceVersion`: 内部资源的版本号。
  - `uid`: 资源的唯一id。
- `spec`: DaemonSet的规格。
  - `revisionHistoryLimit`: DaemonSet的修订历史限制，表示会保持10个历史的DaemonSet revision。
  - `selector`: 用于选择Pod的标签。
    - `matchLabels`: DaemonSet管理的Pod必须具备的标签。
  - `template`: 用于创建Pod的模板。
    - `metadata`: 模板的元数据。
    - `spec`: 描述创建Pod的详细内容。
      - `affinity`: Pod的亲和性设置。
        - `nodeAffinity`: 设置Pod调度的节点亲和性限制。
      - `containers`: 定义了容器的列表。
        - `image`: 使用的容器镜像。
        - `name`: 容器的名称。
        - `ports`: 容器所开放的端口设定。
        - `resources`: 资源限制和请求。
        - `securityContext`: 安全上下文设定。
        - `terminationMessagePath`: 容器停止时输出的信息存放路径。
        - `volumeMounts`: 容器挂载的卷。
      - `dnsPolicy`: DNS策略。
      - `hostNetwork`: 是否使用主机网络。
      - `initContainers`: 在主容器运行前运行的初始化容器。
      - `priorityClassName`: 优先级类名。
      - `restartPolicy`: Pod的重启策略。
      - `schedulerName`: 使用的调度器名称。
      - `serviceAccount`: 使用的服务账号。
      - `terminationGracePeriodSeconds`: 清理Pod所需要等待的时间。
      - `volumes`: Pod上挂载的卷。
  - `updateStrategy`: 更新策略设置，如何应对Pod的更新。
- `status`: DaemonSet的当前状态信息。
  - `currentNumberScheduled`: 当前应该运行的Pod数量。
  - `desiredNumberScheduled`: 追求的目标Pod数量。
  - `numberAvailable`: 可用Pod数。
  - `numberMisscheduled`: 错误调度的Pod数。
  - `numberReady`: 准备就绪的Pod数。
  - `observedGeneration`: DaemonSet控制器最后一次观察到的`generation`。
  - `updatedNumberScheduled`: 更新版的Pod的数量。

总之，这个DaemonSet用于部署名为`engine-peon`的Pod，该Pod将在标签为`role/stor-worker=true`的节点上运行，并且整个集群中每个符合条件的节点会运行一个该DaemonSet管理的Pod。


当创建DaemonSet资源时，Kubernetes的控制平面会接收这个YAML配置，并根据其中的描述创建并管理DaemonSet所管理的Pods。DaemonSet确保在集群中的每个符合条件的节点上运行指定的Pod副本。继续解释一下DaemonSet中的其他关键组件：

### selector
`selector`字段用于告诉DaemonSet如何找到它应该管理的Pods。它是通过匹配标签来识别Pods。
- `matchLabels`: 这个键值对与`template.metadata.labels`中定义的标签一致，确保DaemonSet知道只应该管理哪些具有这些标签的Pods。在这里，匹配标签为`app: example`。

### template
这部分定义了当DaemonSet创建新的Pod副本时，这些Pod的样子。这个template是模板，用于生成具体的Pod实例。
- `metadata.labels`: 在`template`下的`metadata`中，`labels`定义了Pod的标签，在这个例子中是`app: example`。这个标签确保了Pod可以被上面提及的`selector`正确匹配。

### template.spec
`template`下的`spec`字段详细定义了Pod内部的配置，如下所示：
- `containers`: 这个列表包含了在Pod中运行的容器的定义。每个容器都需要有一个名字，并且可以指定要使用的镜像、端口、环境变量等一系列参数。

对于这个示例DaemonSet来说，意味着集群中的每个符合条件的节点上都会运行一个名为`example-container`的容器，该容器采用的镜像是`nginx`。DaemonSet控制器会自动在新增的符合条件的节点上创建Pod，并且如果有节点被删除，相应的Pod也会被清理。

DaemonSet常用于需要在集群的每个节点上运行的服务，比如日志收集器、监控代理等。这种分布在每个节点的特性确保了这些服务可以收集到所有节点的数据或监控节点的状态。

serviceAccountName

简介：

是Pod使用的Service Account的名称，Pod与Kubernetes API进行交互时，例如拉取配置信息，更新资源状态等，需要对API请求进行授权。通过Service Account，Kubernetes可以控制Pod对API的访问权限，确保它只能访问它需要的资源。

详细说明：

在Kubernetes的`DaemonSet`配置文件的`template`下的`spec`部分，可以指定`serviceAccount`或`serviceAccountName`。据我所知截止到我的知识截止点，`DaemonSet`中是不具有`serviceAccount`字段的，只有`serviceAccountName`字段。下面是`serviceAccountName`字段的用途：

- `serviceAccountName`: 该字段用于指定Pod使用的Service Account的名称。Service Account在Kubernetes中提供了一个身份认证机制，用于给Pod授予访问Kubernetes API的权限。当Pod需要与Kubernetes API进行交互时，例如拉取配置信息，更新资源状态等，需要对API请求进行授权。通过Service Account，Kubernetes可以控制Pod对API的访问权限，确保它只能访问它需要的资源。

当你在一个Pod模板中指定`serviceAccountName`时，所有由这个模板创建的Pod都会自动挂载一个包含指定Service Account凭据的秘钥。这意味着Pod中运行的容器将能够使用这些凭据与Kubernetes API进行交互。

通常，Service Account与特定的访问控制策略相关联，这些策略是通过Role和RoleBinding（或ClusterRole和ClusterRoleBinding，如果需要集群级别的访问权限）来定义的。这样，你可以对Pod进行精细化的权限管理，只给予它们完成其工作所需要的最小权限。

如果你在一个`DaemonSet`配置中看到了`serviceAccount`字段，这可能是一个定制化的Kubernetes发行版支持的特定扩展。不过，根据最常见的Kubernetes API文档，通常只使用`serviceAccountName`来声明应该与Pod关联的Service Account。

DaemonSet的结构及其各个部分的作用

在 DaemonSet 对象中，有以下几个部分：

• metadata：元数据部分包含了对象的名称、命名空间、标签等信息。
• spec：规格部分包含了 DaemonSet 对象的规格，如选择器、Pod 模板等。
• status：状态部分包含了 DaemonSet 对象的当前状态信息，如运行中的 Pod 数量等。

 

其中，spec 部分是 DaemonSet 对象中最重要的部分，它包含了以下几个字段：

• selector：指定了哪些节点需要运行 Pod 副本。可以使用节点标签选择器指定节点的标签，也可以使用节点名称选择器指定节点的名称。
• template：指定了要运行在节点上的 Pod 模板。模板中可以指定容器镜像、启动命令等信息。
• updateStrategy：指定了 DaemonSet 的更新策略。默认情况下，DaemonSet 会在每个节点上运行一个 Pod 副本，如果需要更新 Pod 版本，则会逐个节点进行更新。可以使用 RollingUpdate 策略实现平滑的更新过程，也可以使用 OnDelete 策略实现在节点删除时更新 Pod 版本。