committed by
Kubernetes Prow Robot
parent
3b10c76ca7
commit
2a120450eb
@@ -7,7 +7,7 @@ weight: 30
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Cette page décrit comment un conteneur pris en charge par kubelet peut utiliser
|
||||
Cette page décrit comment un conteneur pris en charge par kubelet peut utiliser
|
||||
le framework de Hooks de cycle de vie de conteneurs pour exécuter du code déclenché par des
|
||||
événements durant son cycle de vie.
|
||||
|
||||
@@ -39,7 +39,7 @@ Aucun paramètre n'est passé au handler.
|
||||
|
||||
Ce hook est appelé immédiatement avant qu'un conteneur se termine, en raison d'un appel à l'API
|
||||
ou d'un événement comme un échec de la liveness probe, un droit de préemption, un conflit de ressources ou autres.
|
||||
Un appel au hook preStop échoue si le conteneur est déjà dans l'état terminé ou complété.
|
||||
Un appel au hook preStop échoue si le conteneur est déjà dans l'état terminé ou complété.
|
||||
Il est bloquant, ce qui veut dire qu'il est synchrone, et doit donc se terminer avant que l'appel pour supprimer le conteneur soit envoyé.
|
||||
Aucun paramètre n'est passé au handler.
|
||||
|
||||
@@ -57,17 +57,17 @@ Les ressources consommées par la commande sont comptabilisées pour le conteneu
|
||||
|
||||
### Exécution d'un handler de hook
|
||||
|
||||
Lorsqu'un hook de cycle de vie de conteneur est appelé,
|
||||
Lorsqu'un hook de cycle de vie de conteneur est appelé,
|
||||
le système de gestion de Kubernetes exécute le handler dans le conteneur enregistré
|
||||
pour ce hook.
|
||||
|
||||
Les appels aux handlers de hook sont synchrones dans le contexte du pod contenant le conteneur.
|
||||
Ceci veut dire que pour un hook `PostStart`,
|
||||
bien que l'ENTRYPOINT du conteneur et le hook soient lancés de manière asynchrone, si le hook prend trop de temps à s'exécuter ou se bloque,
|
||||
bien que l'ENTRYPOINT du conteneur et le hook soient lancés de manière asynchrone, si le hook prend trop de temps à s'exécuter ou se bloque,
|
||||
le conteneur ne peut pas atteindre l'état `running`.
|
||||
|
||||
Le comportement est similaire pour un hook `PreStop`.
|
||||
Si le hook se bloque durant l'exécution,
|
||||
Si le hook se bloque durant l'exécution,
|
||||
la phase du Pod reste en état `Terminating` et le hook est tué après `terminationGracePeriodSeconds` que le pod se termine.
|
||||
Si un hook `PostStart` ou `PreStop` échoue,
|
||||
le conteneur est tué.
|
||||
@@ -93,7 +93,7 @@ le hook pourrait être re-déclenché après que kubelet redémarre.
|
||||
|
||||
Les logs pour un handler de hook ne sont pas exposés dans les événements du Pod.
|
||||
Si un handler échoue pour une raison particulière, il envoie un événement.
|
||||
Pour `PostStart`, c'est l'événement `FailedPostStartHook`
|
||||
Pour `PostStart`, c'est l'événement `FailedPostStartHook`
|
||||
et pour `PreStop`, c'est l'événement `FailedPreStopHook`.
|
||||
Vous pouvez voir ces événements en exécutant `kubectl describe pod <pod_name>`.
|
||||
Voici un exemple d'affichage d'événements lors de l'exécution de cette commande :
|
||||
@@ -118,7 +118,7 @@ Events:
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* En savoir plus sur l'[Environnement d'un conteneur](/fr/docs/concepts/containers/container-environment-variables/).
|
||||
* Entraînez-vous à
|
||||
* Entraînez-vous à
|
||||
[attacher des handlers de conteneurs à des événements de cycle de vie](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -18,7 +18,7 @@ La propriété `image` d'un conteneur utilise la même syntaxe que la commande `
|
||||
|
||||
## Mettre à jour des images
|
||||
|
||||
La politique de récupération par défaut est `IfNotPresent`, Kubelet ne récupère alors pas une image si elle est déjà présente sur le nœud.
|
||||
La politique de récupération par défaut est `IfNotPresent`, Kubelet ne récupère alors pas une image si elle est déjà présente sur le nœud.
|
||||
Si vous voulez forcer une récupération à chaque fois, vous pouvez faire une des actions suivantes :
|
||||
|
||||
- définissez `imagePullPolicy` du conteneur à `Always`.
|
||||
@@ -46,7 +46,7 @@ Veuillez utiliser les versions *18.06 ou ultérieure*, les versions antérieures
|
||||
|
||||
Si vous avez des problèmes en téléchargeant des manifestes viciés, nettoyez les anciens manifestes dans `$HOME/.docker/manifests` pour recommencer de zéro.
|
||||
|
||||
Pour Kubernetes, nous avons historiquement utilisé des images avec des suffixes `-$(ARCH)`. Pour une rétrocompatibilité, veuillez générer les anciennes images avec des suffixes. Par exemple, l'image `pause` qui a le manifeste pour toutes les architetures et l'image `pause-amd64` qui est rétrocompatible
|
||||
Pour Kubernetes, nous avons historiquement utilisé des images avec des suffixes `-$(ARCH)`. Pour une rétrocompatibilité, veuillez générer les anciennes images avec des suffixes. Par exemple, l'image `pause` qui a le manifeste pour toutes les architetures et l'image `pause-amd64` qui est rétrocompatible
|
||||
pour d'anciennes configurations ou des fichiers YAML qui auraient codé en dur les images avec des suffixes.
|
||||
|
||||
## Utiliser un registre privé
|
||||
@@ -96,7 +96,7 @@ Kubernetes prend en charge nativement [Amazon Elastic Container Registry](https:
|
||||
Utilisez simplement le nom complet de l'image (par ex. `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`)
|
||||
dans la définition du Pod.
|
||||
|
||||
Tous les utilisateurs du cluster qui peuvent créer des pods auront la possibilité
|
||||
Tous les utilisateurs du cluster qui peuvent créer des pods auront la possibilité
|
||||
d'exécuter des pods qui utilisent n'importe quelle image du registre ECR.
|
||||
|
||||
Kubelet va aller chercher et rafraîchir périodiquement les certificats ECR. Les permissions suivantes sont requises par kubelet :
|
||||
@@ -160,7 +160,7 @@ Si vous travaillez dans AWS EC2 et utilisez EC2 Container Registry (ECR), kubele
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
Cette méthode est utilisable si vous avez le contrôle sur la configuration des nœuds. Elle ne marchera pas
|
||||
Cette méthode est utilisable si vous avez le contrôle sur la configuration des nœuds. Elle ne marchera pas
|
||||
correctement sur GCE, et sur tout autre fournisseur cloud qui fait du remplacement de nœud automatique.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -184,7 +184,7 @@ Docker stocke les clés pour les regisres privés dans le fichier `$HOME/.docker
|
||||
Vous pouvez avoir à définir `HOME=/root` explicitement dans votre fichier d'environnement pour kubelet.
|
||||
{{< /note >}}
|
||||
|
||||
Voici les étapes recommandées pour configurer vos nœuds pour qu'ils utilisent un registre privé. Dans cet exemple, exécutez-les sur votre poste de travail :
|
||||
Voici les étapes recommandées pour configurer vos nœuds pour qu'ils utilisent un registre privé. Dans cet exemple, exécutez-les sur votre poste de travail :
|
||||
|
||||
1. Exécutez `docker login [server]` pour chaque jeu de certificats que vous désirez utiliser. Ceci met à jour `$HOME/.docker/config.json`.
|
||||
1. Examinez `$HOME/.docker/config.json` dans un éditeur pour vous assurer qu'il contient uniquement les certificats que vous désirez utiliser.
|
||||
@@ -236,7 +236,7 @@ Si vous travaillez dans Google Kubernetes Engine, vous trouverez un `.dockercfg`
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
Cette méthode est utilisable si vous avez le contrôle sur la configuration des nœuds. Elle ne marchera pas
|
||||
Cette méthode est utilisable si vous avez le contrôle sur la configuration des nœuds. Elle ne marchera pas
|
||||
correctement sur GCE, et sur tout autre fournisseur cloud qui fait du remplacement de nœud automatique.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -268,13 +268,13 @@ kubectl create secret docker-registry <name> --docker-server=SERVEUR_REGISTRE_DO
|
||||
secret/myregistrykey created.
|
||||
```
|
||||
|
||||
Si vous avez déjà un fichier de clés Docker, alors, plutôt que d'utiliser la commande ci-dessus,
|
||||
Si vous avez déjà un fichier de clés Docker, alors, plutôt que d'utiliser la commande ci-dessus,
|
||||
vous pouvez importer le fichier de clés comme un Secret Kubernetes.
|
||||
[Créer un Secret basé sur des clés Docker existantes](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) explique comment s'y prendre.
|
||||
Ceci est particulièrement utile si vous utilisez plusieurs registres privés, `kubectl create secret docker-registry` créant un Secret ne fonctionnant qu'avec un seul registre privé.
|
||||
|
||||
{{< note >}}
|
||||
Les pods peuvent référencer des pull secrets dans leur propre namespace uniquement,
|
||||
Les pods peuvent référencer des pull secrets dans leur propre namespace uniquement,
|
||||
ces étapes doivent donc être faites pour chaque namespace.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user