从Docker到Kubernetes——Kubernetes设计解读之DaemonSet、ConfigMap、Job

最新推荐文章于 2024-01-02 11:33:24 发布

No_Game_No_Life_

最新推荐文章于 2024-01-02 11:33:24 发布

阅读量407

点赞数

分类专栏： K8s 文章标签： K8s

本文链接：https://blog.csdn.net/No_Game_No_Life_/article/details/102697620

版权

K8s 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

文章目录

Kubernetes的设计解读

Kubernetes的设计解读

DaemonSet

在生产环境中，我们可能会希望在每个工作节点上都运行某个相同的副本。比如：

在每台节点上运行一个集群存储服务，例如运行glusterd，ceph。
在每台节点上运行一个日志收集服务，例如fluentd，logstash。
在每台节点上运行一个节点监控服务，例如Prometheus Node Exporter, collectd, Datadog agent, New Relic agent, 或Ganglia gmond

此时，我们当然可以在每个工作节点注册到集群的时候手动将pod绑定到节点上，但是我们希望部署能够尽可能的简单。DaemonSet就提供这样的服务，每当一个新的工作节点加入到集群中的时候，系统就会按照DaemonSet的配置在节点上运行相应的pod，负责这部分工作的是DaemonSet controller。

DaemonSet通过pod selector来找到它对应的pod。关于DaemonSet的问题，我们暂时介绍道这里。

ConfigMap

很多生产环境中的应用程序配置较为复杂，可能需要多个config文件、命令行参数和环境变量的组合。并且，这些配置信息应该从应用程序镜像中解耦出来，以保证镜像的可移植性以及配置星系不被泄漏。

ConfigMap包含了一系列的键值对，用于存储被pod或者系统组件（controller等）访问的信息。

创建ConfigMap：
假设我们存储了两个properties文件：game.properties和ui.properties。

#cat configmap/game.properties
enemies=aliens
lives=3
enemies.ceat=true
secret.code.lives=30

# cat configmap/ui.properties
color.good=purple
color.bad=yellow
allow.textmode=true

此时通过如下命令创建包含目录下所有文件内容的ConfigMap，from-file的参数是包含文件的文件夹目录或者单个文件。

[root@master ~]# kubectl create configmap game-config --from-file=/root/configmap
configmap/game-config created
[root@master ~]# kubectl get configmap game-config
NAME          DATA   AGE
game-config   2      34s
[root@master ~]# kubectl get configmap game-config -o yaml
apiVersion: v1
data:
  game.properties: |
    enemies=aliens
    lives=3
    enemies.ceat=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
kind: ConfigMap
metadata:
  creationTimestamp: "2019-10-23T11:24:58Z"
  name: game-config
  namespace: default
  resourceVersion: "220952"
  selfLink: /api/v1/namespaces/default/configmaps/game-config
  uid: a5678a5e-90ea-4f42-bf04-76cc5348cf1b

使用ConfigMap中的信息：
这里主要有三种主要的方式：

通过环境变量调用。
设置命令行参数。
volume plugin。

暂时介绍到这里。

Job

Job可以简单的理解为run to completion的任务，它对应重启策略是OnFailure或者Never的应用。

Job的应用场景之一就是创建单个pod，一旦pod完成工作退出则认为这个Job也就成功结束了。这样的Job被成为non-parallel job。这种情况下不需要设定.spec.completions和.spec.parallelism，系统默认为1。
而对于parallel job被具体细分为两种类型，分别是有固定completion数值的parallel job（完成指定completion数量的pod运行成功并退出），用户需要设定.spec.completions，对于参数.spec.parallelism可以设定，也可以不做设定默认为1。
以及有work queue的parallel job（同时运行多个pod，其中任意一个pod成功则停止），所以需要指定.spec.parallelism。