Technologie et architecture Kubernetes-12

1. Introduction

2 Définition de Kubernetes

3 Architecture Kubernetes

4 Technologie Kubernetes

4.1 Technologie de conteneurisation

4.1.1 technologie des groupes de contrôle

4.1.2 Environnement d'exploitation du conteneur Docker

4.1.3 environnement d'exploitation conteneur et conteneur

4.1.4 Concept de base du Pod

4.1.5 Stratégie de planification des pods

4.1.6 Orchestration des ressources de pod

4.1.6.1 Déploiements

4.1.6.2Ensemble de répliques

4.1.6.3StatefulSets

4.1.6.4DaemonSet

4.1.6.5Emplois

Le travail est utilisé pour organiser les tâches. Un travail crée un ou plusieurs pods pour exécuter des tâches jusqu'à ce que ces tâches soient terminées ou terminées. Autrement dit, le travail garde une trace de la piste d'exécution des tâches correspondant à ces pods. Lorsque le nombre spécifié de pods remplir les tâches, le travail aussi la mission accomplie. Si le Job est supprimé, toutes les tâches du Pod correspondant au Job seront supprimées. Si le Job est suspendu, toutes les tâches du Pod actives correspondant au Job seront supprimées jusqu'à ce que le Job reprenne son exécution.

Par exemple, si l'utilisateur planifie un travail qui n'exécute qu'une seule tâche de pod, le travail doit s'assurer que le pod peut terminer l'exécution de la tâche de manière fiable. Si la tâche du pod est anormale ou supprimée pendant l'exécution (erreur matérielle ou redémarrage du nœud), le Tâche Un nouveau Pod sera créé pour continuer l'exécution de la tâche. De plus, les utilisateurs peuvent organiser des tâches pour exécuter plusieurs tâches de pod en parallèle, ou utiliser CronJob (décrit en détail dans les chapitres suivants) pour exécuter une seule tâche ou plusieurs tâches en parallèle sur une base régulière, régulière ou à intervalles.

Exemple de travail

Comme indiqué ci-dessous, organisez un Job, exécutez la tâche Pod correspondant au Job pour calculer π et générer 2 000 bits :

Après avoir exécuté la tâche, utilisez la ligne de commande suivante pour afficher les informations sur l'état de la tâche :

kubectl décrire le travail pi

(ou kubectl get job pi -o yaml)

Voici une brève description des informations d'exécution de la tâche :

Heure de début

heure de début de l'exécution de la tâche

Terminé à Le temps d'achèvement de l'exécution de la tâche

Durée Durée d'exécution de la tâche

Statuts des pods :   0 En cours d'exécution / 1 Réussi / 0 Échec Correspond à l'état d'exécution du pod, où 0 est en cours d'exécution/1 s'exécute avec succès/0 s'exécute en échec

Modèle de module Le template correspondant au Pod

Événements Informations sur les événements liées au contrôleur de tâches

Les utilisateurs peuvent utiliser la ligne de commande suivante pour afficher la liste de toutes les tâches du pod correspondant au Job :

gousses=

$(kubectl obtenir des pods

--selector=nom-travail=pi

--output=jsonpath=

'{.items[*].metadata.name}')

echo $pods

Parmi eux, --output consiste à définir les règles de filtrage ou de correspondance des informations de sortie (similaire aux expressions régulières).

Les utilisateurs peuvent utiliser la ligne de commande suivante pour afficher les informations de sortie de la tâche d'exécution :

kubectl logs $pods

Informations de base sur le poste

Comme pour les autres spécifications de mise en page, vous devez définir les domaines d'attributs de base tels que apiVersion, kind et metadata, vous devez définir les domaines d'attributs liés au modèle .spec.template et vous devez définir les domaines d'attributs liés au .spec.selector sélecteur.

Type de tâche

Job fournit trois types de tâches, comme suit :

1 tâche non parallèle En règle générale, un seul pod est exécuté Lorsque le pod est terminé, sa tâche correspondante est terminée 2 tâches parallèles (nombre fixe de tâches terminées) Utilisez le champ de configuration .spec.completions pour spécifier le nombre de tâches à accomplir Le travail démarre l'exécution de toutes les tâches, et l'exécution du nombre spécifié de tâches est terminée, et l'exécution du travail est terminée Si l'utilisateur définit le domaine de configuration .spec.completionMode="Indexed configuration domain, chaque copie de pod correspond à un index unique, et l'index va de 0 à .spec.completions-1 3 Tâches parallèles (collaboration avec des files d'attente de travail) Ce type de tâche convient au scénario d'utilisation des modes producteur et consommateur. La file d'attente de travail est le producteur et la tâche Pod est le consommateur. Une fois la consommation terminée, vous pouvez quitter ou l'utilisateur peut formuler des règles de consommation. Ne spécifiez pas la configuration domain.spec.completions, utilisez la configuration domain.spec.parallelism par défaut Les tâches correspondant au pod doivent coopérer entre elles, ou un service tiers détermine comment consommer la file d'attente. Par exemple, la tâche du pod peut obtenir N éléments par lots à partir de la file d'attente de travail. Les tâches correspondant à chaque pod peuvent déterminer si les tâches des autres pods ont été traitées, il est donc déterminé que le travail a été terminé Une fois qu'une tâche correspondant à un Pod est terminée avec succès, aucune tâche correspondant à un nouveau Pod ne sera créée Une fois la tâche correspondant à un pod terminée avec succès, toutes les tâches du pod seront terminées et la tâche de travail sera terminée Une fois qu'un pod a réussi à quitter l'exécution de la tâche, aucun autre pod ne peut reprendre sa tâche et les tâches de tous les pods se termineront.

Pour les types de tâches ci-dessus, les paramètres recommandés sont les suivants :

Pour les tâches non parallèles Les utilisateurs n'ont pas besoin de définir la configuration domain.spec.completions configuration domain.spec.parallelism S'il n'est pas défini, la valeur par défaut est 1

Pour les tâches parallèles avec un nombre fixe de tâches Définissez uniquement la configuration domain.spec.completions pour spécifier le nombre de tâches à accomplir Vous pouvez également définir la configuration domain.spec.parallelism, ou non, la valeur par défaut est 1

Pour les tâches parallèles sur les files d'attente de travail Définissez uniquement la configuration domain.spec.parallelism, ne définissez pas la configuration domain.spec.completions

Contrôler le degré de parallélisme

Le degré de parallélisme est spécifié par le domaine de configuration .spec.parallelism. La valeur par défaut est 1. S'il est spécifié à 0, l'exécution du Job correspondant sera suspendue jusqu'à ce que la valeur soit modifiée à une valeur supérieure à 0. Dans l'environnement d'exécution réel, le nombre de tâches de pod en cours d'exécution est supérieur ou inférieur à la valeur spécifiée par le parallélisme (incohérence), les raisons sont les suivantes :

Le champ de configuration .spec.parallelism avec un nombre fixe de tâches, le nombre réel de tâches de pod en cours d'exécution ne sera pas supérieur à cette valeur, et les tâches de pod supérieures à la valeur spécifiée dans le champ de configuration .spec.parallelism seront ignorées Le type de tâche de la file d'attente de travail. Tant qu'une tâche de pod est terminée avec succès, les autres tâches de pod seront terminées et terminées une par une. Si le contrôleur de tâches répond lentement anormalement Si le contrôleur de tâches ne parvient pas à créer la tâche Pod (aucune autorisation ou manque de ressources) Lorsque le contrôleur de tâches ne parvient pas à créer des tâches de pod trop de fois, il met en œuvre une politique de limitation du trafic Lorsque la tâche de pod est en cours d'arrêt normal, il y a un délai

mode de réalisation des tâches

对于固定任务数的任务类型，在配置域.spec.completions值不为空的时候，用户可以使用配置域.spec.completionMode指定Pod任务执行的模式，其设置方式如下所示：

NonIndexed（默认值） 固定任务数的Pod任务执行完成，则Job执行完成。也就是，所有Pod任务是相应的，当固定任务数是0，则使用此默认值

Indexed Job中的每个Pod任务对应一个任务完成的索引标识，从0到.spec.completions-1，该索引值与以下三个方面有关系： Pod任务的注解使用batch.kubernetes.io/job-completion-index 在Pod主机名称中增加$(job-name)-$(index)任务标识，当与service的域名绑定，则可以使用绑定的域名访问Job中的任何Pod任务 在Pod的环境变量中，对应JOB_COMPLETION_INDEX 每个索引值标识与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中容器状态的规则如下所示：

Pod的状态是.status.phase = "Failed" 在重启策略restartPolicy = "OnFailure"的情况下，Pod中运行的容器状态是.status.phase = Pending或者Running

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终止之后，需要人工干涉。

（未完待续）