작업 및 DaemonSet : 응용 프로그램 편성 및 관리 | 스크래치 K8S에서 시작

A, 작업

수요 소스

작업 배경 질문

먼저 우리는 욥의 수요의 원천을 확인합니다. 우리는 우리가 직접 작업 포드 프로세스를 실행할 수 있습니다, 가장 작은 단위가 포드 예정이다, 내부 K8S을 알고있다. 다음과 같은 질문을 생성합니다 이렇게 :

• 우리가 어떻게 포드 과정에서 오른쪽 끝을 확인합니까?
• 어떻게 프로세스가 실패시 다시 시도를 실행 보장하기 위해?
• 어떻게 여러 작업을 관리 및 작업 간의 종속성이 있습니다합니까?
• 어떻게 병렬 작업 실행 및 관리 작업 크기를 큐에?

직업 : 관리 작업 컨트롤러

우리는 욥의는 Kubernetes 우리를 위해 기능을 제공하는 것을 보면 :

• 작업의 첫 번째는 Kubernetes는 수를 지정하는 하나 이상의 포드 포드를 만들 수있는 관리 작업 컨트롤러이며, 실행 또는 종료를 성공적으로 모니터링 할 수 있는지 여부;
• 우리는 모드를 재설정 할 수 있습니다 및의 상태에 따라 작업 포드에 재시도 횟수를 설정;
• 우리는 또한 작업 실행이 완료된 후 다음 작업에 다시 실행을 보장하기 위해, 관계에 의존 할 수있다;
• 그러나, 병렬 동작 완료 시간과 전체 크기가되도록 포드 동안에 병렬의 정도에 따라 작업의 병렬 처리를 제어 할 수있다.

 

사용 사례의 해석

우리는 관점의 다음의 예에 따라 작업 응용 프로그램을 작성하는 방법을 살펴.

작업 문법

그림이 실제로 내부 작업 컨트롤러의 유형입니다 작업이 주로 작업이라는 새로운 종류의 소개, 형태 간단한 YAML 작업이다. 그런 다음, 실제로 사양의 포드입니다 다음 spec.template을 이름 작업을 지정하는 이름 내부 메타 데이터.

내용이 두 개 이상의 지점, 동일 내부입니다 :

• 첫 번째는 우리가 항상 세 가지 재시도 전략 작업하지 마십시오, OnFailure을 설정할 수있는 restartPolicy이다. 다시, OnFailure 수 다시 시도 실패 실행할 때에 상관없이 항상 곁에 시간 또는 다시 실행의 어떤 상황에서도 작업은 우리는 절대 사용할 수 없습니다, 희망을 다시 실행해야합니다;
• 또한, 실행시에 작업이 무한 시도에 갈 수 없어, 그래서 우리는 재시도 횟수를 제어하는 ​​매개 변수가 필요합니다. 이 backoffLimit 많은 시간이 시도 할 수있는 방법 결국 일자리를 보장하는 것입니다.

작업 그래서 내부에서, 우리의 주요 초점은이다  restartPolicy 다시 시작 전략 및  backoffLimit의 수는 제한을 다시 시도하십시오 .

작업 상태

일자리 창출이 완료되면, 우리는 작업의 현재 작동 상태를 확인 작업이 명령을받을 kubectl 수 있습니다. 결과 값 내부, 기본적인 작업의 이름, 완료 포드의 현재 숫자가 긴했다.

AGE는  현재 시간을 뺀가 생성 된 시점부터 계산이 포드의 의미를 나타냅니다. 시간의 길이는 주로 당신에게 전에 생성 시간 포드, 포드의 역사를 이야기하는 데 사용됩니다. DURATION은  주로 우리의 시간 성능 튜닝,이 매개 변수는 매우 유용 할 것입니다 얼마나 말에 실제 사업 운영 안에 우리에게 작업을 참조하십시오. 건설 완료 우리가 다음 상태의 수를 완료 포드, 몇 가지의 총, 내부를 들여다 보면 주요 작업이이 필드에 표시됩니다 내부 않습니다. 

보기 포드

여기에서 우리는, 사실, 포드에서 작업의 마지막 실행 유닛 또는 포드 본다. 우리 방금 만든 작업은 포드의 한 소위 "파이"을 만들어, 작업이 원주의 비율을 계산하는 것입니다, 포드의 이름이 될 것 "$ {작업은 이름} - $ {랜덤 접미사}"우리는 볼 수 있습니다 포드의 형식은 다음과 YAML.

它比普通的 Pod 多了一个叫 ownerReferences，这个东西来声明此 pod 是归哪个上一层 controller 来管理。可以看到这里的 ownerReferences 是归 batch/v1，也就是上一个 Job 来管理的。这里就声明了它的 controller 是谁，然后可以通过 pod 返查到它的控制器是谁，同时也能根据 Job 来查一下它下属有哪些 Pod。

并行运行 Job

我们有时候有些需求：希望 Job 运行的时候可以最大化的并行，并行出 n 个 Pod 去快速地执行。同时，由于我们的节点数有限制，可能也不希望同时并行的 Pod 数过多，有那么一个管道的概念，我们可以希望最大的并行度是多少，Job 控制器都可以帮我们来做到。

这里主要看两个参数：一个是 completions，一个是 parallelism。

• 首先第一个参数是用来指定本 Pod 队列执行次数。可能这个不是很好理解，其实可以把它认为是这个 Job 指定的可以运行的总次数。比如这里设置成 8，即这个任务一共会被执行 8 次；
• 第二个参数代表这个并行执行的个数。所谓并行执行的次数，其实就是一个管道或者缓冲器中缓冲队列的大小，把它设置成 2，也就是说这个 Job 一定要执行 8 次，每次并行 2 个 Pod，这样的话，一共会执行 4 个批次。

查看并行 Job 运行

下面来看一下它的实际运行效果，上图就是当这个 Job 整体运行完毕之后可以看到的效果，首先看到 job 的名字，然后看到它一共创建出来了 8 个 pod，执行了 2 分 23 秒，这是创建的时间。

接着来看真正的 pods，pods 总共出来了 8 个 pod，每个 pod 的状态都是完成的，然后来看一下它的 AGE，就是时间。从下往上看，可以看到分别有 73s、40s、110s 和 2m26s。每一组都有两个 pod 时间是相同的，即：时间段是 40s 的时候是最后一个创建、 2m26s 是第一个创建的。也就是说，总是两个 pod 同时创建出来，并行完毕、消失，然后再创建、再运行、再完毕。

比如说，刚刚我们其实通过第二个参数来控制了当前 Job 并行执行的次数，这里就可以了解到这个缓冲器或者说管道队列大小的作用。

Cronjob 语法

下面来介绍另外一个 Job，叫做 CronJob，其实也可以叫定时运行 Job。CronJob 其实和 Job 大体是相似的，唯一的不同点就是它可以设计一个时间。比如说可以定时在几点几分执行，特别适合晚上做一些清理任务，还有可以几分钟执行一次，几小时执行一次等等，这就叫定时任务。

定时任务和 Job 相比会多几个不同的字段：

• schedule：schedule 这个字段主要是设置时间格式，它的时间格式和 Linux 的 crontime 是一样的，所以直接根据 Linux 的 crontime 书写格式来书写就可以了。举个例子： */1 指每分钟去执行一下 Job，这个 Job 需要做的事情就是打印出大约时间，然后打印出“Hello from the kubernetes cluster” 这一句话；

• startingDeadlineSeconds：即：每次运行 Job 的时候，它最长可以等多长时间，有时这个 Job 可能运行很长时间也不会启动。所以这时，如果超过较长时间的话，CronJob 就会停止这个 Job；

• concurrencyPolicy：就是说是否允许并行运行。所谓的并行运行就是，比如说我每分钟执行一次，但是这个 Job 可能运行的时间特别长，假如两分钟才能运行成功，也就是第二个 Job 要到时间需要去运行的时候，上一个 Job 还没完成。如果这个 policy 设置为 true 的话，那么不管你前面的 Job 是否运行完成，每分钟都会去执行；如果是 false，它就会等上一个 Job 运行完成之后才会运行下一个；

• JobsHistoryLimit：这个就是每一次 CronJob 运行完之后，它都会遗留上一个 Job 的运行历史、查看时间。当然这个额不能是无限的，所以需要设置一下历史存留数，一般可以设置默认 10 个或 100 个都可以，这主要取决于每个人集群不同，然后根据每个人的集群数来确定这个时间。

操作演示

Job 的编排文件

下面看一下具体如何使用 Job。

Job 的创建及运行验证

首先看一下 job.yaml。这是一个非常简单的计算 pi 的一个任务。使用 kubectl creat-f job.yaml，这样 job 就能提交成功了。来看一下 kubectl.get.jobs，可以看到这个 job 正在运行；get pods 可以看到这个 pod 应该是运行完成了，那么接下来 logs 一下这个 job 以及 pod。可以看到下图里面打印出来了圆周率。

并行 Job 的编排文件

下面再来看第二个例子：

并行 Job 的创建及运行验证

这个例子就是指刚才的并行运行 Job 创建之后，可以看到有第二个并行的 Job。

现在已经有两个 Pod 正在 running，可以看到它大概执行了快到 30s。

30s 之后它应该会起第二个。

第一批的 pod 已经执行完毕，第二批的 pod 正在 running，每批次分别是两个Pod。也就是说后面每隔 40s 左右，就会有两个 pod 在并行执行，它一共会执行 4 批，共 8 个 pod，等到所有的 pod 执行完毕，就是刚才所说的并行执行的缓冲队列功能。

过一段时间再看这个 pods，可以发现第二批已经执行结束，接下来开始创建第三批······

Cronjob 的编排文件

下面来看第三个例子 —— CronJob。 CronJob 是每分钟执行一次，每次一个 job。

Cronjob 的创建及运行验证

如下图 CronJob 已经创建了，可以通过 get cronjob 来看到当前有一个 CronJob，这个时候再来看 jobs，由于它是每分钟执行一次，所以得稍微等一下。

同时可以看到，上一个 job 还在运行，它的时间是 2m12s 左右，它的完成度是 7/8、6/8，刚刚看到 7/8 到 8/8，也就是说我们上一个任务执行了最后一步，而且每次都是两个两个地去运行。每次两个运行的 job 都会让我们在运行一些大型工作流或者工作任务的时候感到特别的方便。

上图中可以看到突然出现了一个 job，“hello-xxxx”这个 job 就是刚才所说的 CronJob。它距离刚才 CronJob 提交已经过去 1 分钟了，这样就会自动创建出来一个 job，如果不去干扰它的话，它以后大概每一分钟都会创建出来这么一个 job，除非等我们什么时候指定它不可以再运行的时候它才会停止创建。

在这里 CronJob 其实主要是用来运作一些清理任务或者说执行一些定时任务。比如说 Jenkins 构建等方面的一些任务，会特别有效。

架构设计

Job 管理模式

我们来看一下 job 的架构设计。Job Controller 其实还是主要去创建相对应的 pod，然后 Job Controller 会去跟踪 Job 的状态，及时地根据我们提交的一些配置重试或者继续创建。同时我们刚刚也提到，每个 pod 会有它对应的 label，来跟踪它所属的 Job Controller，并且还去配置并行的创建， 并行或者串行地去创建 pod。

Job 控制器

上图是一个 Job 控制器的主要流程。所有的 job 都是一个 controller，它会 watch 这个 API Server，我们每次提交一个 Job 的 yaml 都会经过 api-server 传到 ETCD 里面去，然后 Job Controller 会注册几个 Handler，每当有添加、更新、删除等操作的时候，它会通过一个内存级的消息队列，发到 controller 里面。

通过 Job Controller 检查当前是否有运行的 pod，如果没有的话，通过 Scale up 把这个 pod 创建出来；如果有的话，或者如果大于这个数，对它进行 Scale down，如果这时 pod 发生了变化，需要及时 Update 它的状态。

同时要去检查它是否是并行的 job，或者是串行的 job，根据设置的配置并行度、串行度，及时地把 pod 的数量给创建出来。最后，它会把 job 的整个的状态更新到 API Server 里面去，这样我们就能看到呈现出来的最终效果了。

二、DaemonSet

需求来源

DaemonSet 背景问题

下面介绍第二个控制器：DaemonSet。同样的问题：如果我们没有 DaemonSet 会怎么样？下面有几个需求：

• 首先如果希望每个节点都运行同样一个 pod 怎么办？
• 如果新节点加入集群的时候，想要立刻感知到它，然后去部署一个 pod，帮助我们初始化一些东西，这个需求如何做？
• 如果有节点退出的时候，希望对应的 pod 会被删除掉，应该怎么操作？
• 如果 pod 状态异常的时候，我们需要及时地监控这个节点异常，然后做一些监控或者汇报的一些动作，那么这些东西运用什么控制器来做？

DaemonSet：守护进程控制器

DaemonSet 也是 Kubernetes 提供的一个 default controller，它实际是做一个守护进程的控制器，它能帮我们做到以下几件事情：

• 首先能保证集群内的每一个节点都运行一组相同的 pod；
• 同时还能根据节点的状态保证新加入的节点自动创建对应的 pod；
• 在移除节点的时候，能删除对应的 pod；
• 而且它会跟踪每个 pod 的状态，当这个 pod 出现异常、Crash 掉了，会及时地去 recovery 这个状态。

用例解读

DaemonSet 语法

下面举个例子来看一下，DaemonSet.yaml 会稍微长一些。

首先是 kind:DaemonSet。如果之前学过 deployment，其实我们再看这个 yaml 会比较简单。例如它会有 matchLabel，通过 matchLabel 去管理对应所属的 pod，这个 pod.label 也要和这个 DaemonSet.controller.label 想匹配，它才能去根据 label.selector 去找到对应的管理 Pod。下面 spec.container 里面的东西都是一致的。


这里用 fluentd 来做例子。DaemonSet 最常用的点在于以下几点内容：

• 首先是存储，GlusterFS 或者 Ceph 之类的东西，需要每台节点上都运行一个类似于 Agent 的东西，DaemonSet 就能很好地满足这个诉求；

• 另外，对于日志收集，比如说 logstash 或者 fluentd，这些都是同样的需求，需要每台节点都运行一个 Agent，这样的话，我们可以很容易搜集到它的状态，把各个节点里面的信息及时地汇报到上面；

• 还有一个就是，需要每个节点去运行一些监控的事情，也需要每个节点去运行同样的事情，比如说 Promethues 这些东西，也需要 DaemonSet 的支持。

查看 DaemonSet 状态

创建完 DaemonSet 之后，我们可以使用 kubectl get DaemonSet（DaemonSet 缩写为 ds）。可以看到 DaemonSet 返回值和 deployment 特别像，即它当前一共有正在运行的几个，然后我们需要几个，READY 了几个。当然这里面，READY 都是只有 Pod，所以它最后创建出来所有的都是 pod。

这里有几个参数，分别是：需要的 pod 个数、当前已经创建的 pod 个数、就绪的个数，以及所有可用的、通过健康检查的 pod；还有 NODE SELECTOR，因为 NODE SELECTOR 在 DaemonSet 里面非常有用。有时候我们可能希望只有部分节点去运行这个 pod 而不是所有的节点，所以有些节点上被打了标的话，DaemonSet 就只运行在这些节点上。比如，我只希望 master 节点运行某些 pod，或者只希望 Worker 节点运行某些 pod，就可以使用这个 NODE SELECTOR。

更新 DaemonSet

其实 DaemonSet 和 deployment 特别像，它也有两种更新策略：一个是 RollingUpdate，另一个是 OnDelete。

• RollingUpdate 其实比较好理解，就是会一个一个的更新。先更新第一个 pod，然后老的 pod 被移除，通过健康检查之后再去见第二个 pod，这样对于业务上来说会比较平滑地升级，不会中断；

• OnDelete 其实也是一个很好的更新策略，就是模板更新之后，pod 不会有任何变化，需要我们手动控制。我们去删除某一个节点对应的 pod，它就会重建，不删除的话它就不会重建，这样的话对于一些我们需要手动控制的特殊需求也会有特别好的作用。

操作演示

DaemonSet 的编排

下面举一个例子。比如说我们去改了些 DaemonSet 的镜像，然后看到了它的状态，它就会去一个一个地更新。

上图这个就是刚才 DaemonSet 的 yaml，会比刚才会多一些， 我们做一些资源的限制，这个都不影响。

DaemonSet 的创建与运行验证

下面我们创建一下 DaemonSet ，然后再看一下它的状态。下图就是我们刚才看到的 DaemonSet 在 ready 里打出来的状态。

从下图中可以看到，一共有 4 个 pod 被创建出来。为什么是 4 个 pod呢？因为只有 4 个节点，所以每个节点上都会运行一个对应的 pod。

DaemonSet 的更新

这时，我们来更新 DaemonSet， 执行完了kubectl apply -f 后，它的 DaemonSet 就已经更新了。接下来我们去查看 DaemonSet 的更新状态。

上图中可以看到：DaemonSet 默认这个是 RollingUpdate 的，我们看到是 0-4，现在是 1-4，也就是说它在更新第一个，第一个更新完成会去更新第二个，第二个更新完，就更新第三个······这个就是 RollingUpdate。RollingUpdate 可以做到全自动化的更新，不用有人值守，而是一个一个地去自动更新，更新的过程也比较平滑，这样可以有利于我们在现场发布或者做一些其他操作。

上图结尾处可以看到，整个的 DaemonSet 已经 RollingUpdate 完毕。

架构设计

DaemonSet 管理模式

接下来看一下 DaemonSet 架构设计。DaemonSet 还是一个 controller，它最后真正的业务单元也是 Pod，DaemonSet 其实和 Job controller 特别相似，它也是通过 controller 去 watch API Server 的状态，然后及时地添加 pod。唯一不同的是，它会监控节点的状态，节点新加入或者消失的时候会在节点上创建对应的 pod，然后同时根据你配置的一些 affinity 或者 label 去选择对应的节点。

DaemonSet 控制器

最后我们来看一下 DaemonSet 的控制器，DaemonSet 其实和 Job controller 做的差不多：两者都需要根据 watch 这个 API Server 的状态。现在 DaemonSet 和 Job controller 唯一的不同点在于，DaemonsetSet Controller需要去 watch node 的状态，但其实这个 node 的状态还是通过 API Server 传递到 ETCD 上。

当有 node 状态节点发生变化时，它会通过一个内存消息队列发进来，然后DaemonSet controller 会去 watch 这个状态，看一下各个节点上是都有对应的 Pod，如果没有的话就去创建。当然它会去做一个对比，如果有的话，它会比较一下版本，然后加上刚才提到的是否去做 RollingUpdate？如果没有的话就会重新创建，Ondelete 删除 pod 的时候也会去做 check 它做一遍检查，是否去更新，或者去创建对应的 pod。

当然最后的时候，如果全部更新完了之后，它会把整个 DaemonSet 的状态去更新到 API Server 上，完成最后全部的更新

本文总结

• 작업 및 CronJobs 기본 개념과 분석 작업 :이 논문은 자세한 프리젠 테이션 내의 모든 노트를 작업과 cron 작업의 개념을 소개하고, 작업 cron 작업에 대한 작업 cronjob를 예를 두 가지 실용적인 방법으로, 다양한 기능을 사용하여 설명 ;
• DaemonSet 기본 동작 및 개념 분석 : 유추 배포 컨트롤러에 의해, 우리는 워크 플로우 및 방식 DaemonSet 컨트롤러에 대한 및 DaemonSet 지속적 업데이트의 지식 개념과 작동 모드에 대응을 업데이트하여 이해합니다.

"알리바바 클라우드 네이티브 마이크로 채널 대중 번호 (ID : Alicloudnative) 마이크로 서비스에 초점, 서버를 사용는, 컨테이너, 서비스 메쉬 및 클라우드 네이티브에서 인기있는 기술 동향을 중심으로 다른 기술 분야는 클라우드 네이티브 대규모 상륙 연습은, 대부분의 클라우드 네이티브 개발자를 이해한다 기술 공개 번호입니다. "