1 はじめに
2 Kubernetesの定義
3 Kubernetes アーキテクチャ
4 Kubernetes テクノロジー
4.1 コンテナ化技術
4.1.1 cgroups テクノロジー
4.1.2 Dockerコンテナ動作環境
4.1.3 コンテナとコンテナの動作環境
4.1.4 ポッドの基本概念
4.1.5 ポッドのスケジューリング戦略
4.1.6 ポッドリソースオーケストレーション
4.1.6.1展開
4.1.6.2レプリカセット
4.1.6.3ステートフルセット
4.1.6.4デーモンセット
4.1.6.5ジョブ
ジョブはタスクを配置するために使用されます。ジョブは 1 つ以上の Pod を作成し、これらのタスクが終了または完了するまでタスクを実行します。つまり、ジョブはこれらの Pod に対応するタスクの実行履歴を追跡します。指定された数の Pod が達したときタスクを完了すると、ジョブもミッションが完了します。ジョブが削除されると、そのジョブに対応するすべての Pod タスクが削除されます。ジョブが一時停止されると、ジョブが実行を再開するまで、そのジョブに対応するすべてのアクティブな Pod タスクが削除されます。
たとえば、ユーザーが 1 つのポッド タスクのみを実行するジョブをスケジュールする場合、ジョブはポッドがタスクの実行を確実に完了できることを確認する必要があります。ポッド タスクが異常であるか、実行中に削除された場合 (ハードウェア エラーまたはノードの再起動)、ジョブ タスクの実行を継続するために新しいポッドが作成されます。さらに、ユーザーは複数の Pod タスクを並行して実行するようにジョブを配置したり、CronJob (後続の章で詳細に説明) を使用して単一のタスクまたは複数のタスクを定期的、定期的、または間隔ベースで並行して実行したりできます。
仕事例
以下に示すように、ジョブを配置し、そのジョブに対応する Pod タスクを実行して π を計算し、2000 ビットを出力します。
タスクの実行後、次のコマンド ラインを使用してタスクのステータス情報を表示します。
kubectl ジョブ pi を記述します
(または kubectl get job pi -o yaml)
タスク実行情報の簡単な説明は次のとおりです。
| 始まる時間 |
| タスクの実行開始時刻 |
| 完了日 タスク実行の完了時間 |
| 間隔 タスクの実行時間 |
| ポッドのステータス: 0 実行中 / 1 成功 / 0 失敗 ポッドの実行ステータスに対応します。0 は実行中/1 は正常に実行中/0 は実行に失敗しました |
| ポッドテンプレート Podに対応するテンプレート |
| イベント タスクコントローラーに関するイベント情報 |
ユーザーは次のコマンドラインを使用して、ジョブに対応するすべての Pod タスクのリストを表示できます。
ポッド=
$(kubectl ポッドを取得
--selector=ジョブ名=pi
--output=jsonpath=
'{.items[*].metadata.name}')
エコー $pods
このうち --output は出力情報のフィルタリングやマッチングルール（正規表現と同様）を設定するものです。
ユーザーは、次のコマンド ラインを使用して、実行タスクの出力情報を表示できます。
kubectl ログ $pods
ジョブの基本情報
他のレイアウト仕様と同様に、apiVersion、kind、metadata などの基本的な属性ドメインを定義する必要があり、.spec.template テンプレートに関連する属性ドメインを定義する必要があり、.spec.template テンプレートに関連する属性ドメインを定義する必要があります。 .spec.selector セレクター。
ジョブタスクのタイプ
ジョブには、次の 3 つのタスク タイプが用意されています。
| 1 つの非並列タスク
2 つの並列タスク (完了するタスクの数は固定)
3 並列タスク (ワークキューとの連携) このタスク タイプは、プロデューサー モードとコンシューマー モードの使用シナリオに適しています。ワーク キューがプロデューサーであり、ポッド タスクがコンシューマーです。消費が完了した後、終了するか、ユーザーが消費ルールを作成できます。
|
上記のタスク タイプの推奨設定は次のとおりです。
| 非並列タスクの場合 ユーザーは、domain.spec.completions 構成を設定する必要はありません。 設定されていない場合、デフォルト値は 1 です。 |
| タスク数が固定された並列タスクの場合 完了する必要があるタスクの数を指定するには、構成 domain.spec.completions のみを設定します。 構成domain.spec.Parallelismを設定することも、設定しないこともできます。デフォルト値は1です。 |
| ワークキュー上の並列タスクの場合 構成domain.spec.Parallelismのみを設定し、構成domain.spec.completionsは設定しないでください。 |
並列度を制御する
並列度は構成ドメイン .spec.Parallelism で指定されます。デフォルト値は 1 です。0 に指定すると、値が 0 より大きい値に変更されるまで、対応するジョブの実行が一時停止されます。実際の実行環境では、実際に実行されている Pod タスクの数が並列度で指定した値より多くなったり、少なくなったりすることがあります (不整合)。その理由は次のとおりです。
|
タスク完了モード
对于固定任务数的任务类型，在配置域.spec.completions值不为空的时候，用户可以使用配置域.spec.completionMode指定Pod任务执行的模式，其设置方式如下所示：
| NonIndexed（默认值） 固定任务数的Pod任务执行完成，则Job执行完成。也就是，所有Pod任务是相应的，当固定任务数是0，则使用此默认值 |
| Indexed Job中的每个Pod任务对应一个任务完成的索引标识，从0到.spec.completions-1，该索引值与以下三个方面有关系：
每个索引值标识与Pod任务是一对多的关系，因而，只要Job中每个索引值标识对应的其中一个Pod任务成功完成，则Job成功完成，也就是，每个索引值标识可以对应多个Pod任务，但是只有一个成功完成的Pod任务参与任务完成总数的统计。 |
处理Pod与容器异常
在实际的运行环境中，Pod中运行的容器实例发生异常的原因有很多，其中包括错误码退出、内存资源不足而引起进程的非法退出，在异常出现的情况下，如果用户设置重启策略是
.spec.template.spec.restartPolicy = "OnFailure"，
则控制器会在相同的节点中重启容器。用户也可以设置重启策略是.spec.template.spec.restartPolicy = "Never"，
则控制器不会重启容器，而是新建一个Pod任务。
在实际的运行环境中，Pod实例发生异常的原因也有很多，其中包括节点更新、重启、删除而引起运行在其中的Pod自动退出，如果用户设置配置域.spec.template.spec.restartPolicy = "Never"，
Pod中运行的容器发生异常，则Pod也被认为是发生异常。在Pod重启过程中，往往涉及到业务应用的可用性问题，需要用户根据实际业务需求处理业务应用重启的问题，例如数据重新加载问题或者分布式锁问题。
如果用户设置了以下所示三个配置域的值，则业务应用也存在启动两次的可能性：
.spec.parallelism = 1
.spec.completions = 1
.spec.template.spec.restartPolicy = "Never"
如果用户设置了以下所示的配置域的值，Job控制器会同时启动多个Pod任务，则需要用户根据实际业务需求处理业务应用因并发性而引起资源争夺的问题：
.spec.parallelism > 1
.spec.completions > 1
Pod错误补偿策略
Pod错误补偿策略是用于Job控制器在Pod任务发生异常的时候，继续尝试重启Pod任务N次之后，Pod任务还不能恢复正常的运行，则Job控制器认为Job启动失败，对应N的次数是由配置域.spec.backoffLimit的值确定，其默认值是6，每次重试的时间间隔是以10秒为单位的指数级增长，例如，10秒、20秒…，其总时间延迟的上限是6分钟，用于统计重试次数的Pod状态或者Pod中容器状态的规则如下所示：
|
Job终止与清理
当一个Job完成，则不再创建新的Pod任务，已终止运行的旧Pod任务也不会被删除，用户可以查看旧Pod任务的日志信息用于检查业务应用的错误、告警或者其他的诊断信息，Job对应的元数据信息也不会被删除，用户可以查看Job对象的状态，Job完成之后由用户自行删除，用户可以使用以下的命令行自行删除Job：
kubectl delete jobs/pi或者
kubectl delete -f ./job.yaml
当用户使用该命令行删除Job，则Job对应的旧Pod也将被删除。
默认的情况下，Job是由集群统一调度，在不受外部干涉的情况下，自动地执行该Job的任务，如果Pod发生异常或者运行在Pod中的容器发生异常，则对Pod或者对运行在Pod中的容器执行恢复重试策略，如果重试恢复的执行次数达到限制的次数之后，Job还没有恢复正常执行，则最终Job被认为是失败的，然后，Job中所有的Pod任务将被终止执行。
用户也可以设置Job的执行截止时间终止Job的执行，对应配置域
.spec.activeDeadlineSeconds，不管Job的状态、Job中Pod的状态、运行在Pod中的容器状态如何，只要Job执行的总时间达到该截止时间，则Job立刻被终止执行，则其对应的全部Pod任务也将被终止执行，此时Job的状态是type: Faile，原因是reason: DeadlineExceeded。该优先级比Pod错误重试次数的优先级更高，也就是，即使错误重试次数未达到限制的次数，但是只要截止时间到期，则Job立刻被终止执行。
由以上的分析可知，配置域restartPolicy重启策略是用于Pod的，而不是用于Job，一旦Job被终止，则Job永远不会被恢复。Job的终止机制包括配置域.spec.activeDeadlineSeconds与配置域.spec.backoffLimit，Job终止之后，需要人工干涉。
（未完待续）