Yushiro FURUKAWA
committed by
Kubernetes Prow Robot
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 >}}
|
||||
|
||||
|
||||
@@ -2,13 +2,13 @@
|
||||
title: Composants de Kubernetes
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
card:
|
||||
card:
|
||||
name: concepts
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
Ce document résume les divers composants binaires requis pour livrer
|
||||
Ce document résume les divers composants binaires requis pour livrer
|
||||
un cluster Kubernetes fonctionnel.
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -16,11 +16,11 @@ un cluster Kubernetes fonctionnel.
|
||||
## Composants Master
|
||||
|
||||
Les composants Master fournissent le plan de contrôle (control plane) du cluster.
|
||||
Les composants Master prennent des décisions globales à propos du cluster (par exemple, la planification (scheduling)).
|
||||
Les composants Master prennent des décisions globales à propos du cluster (par exemple, la planification (scheduling)).
|
||||
Ils détectent et répondent aux événements du cluster (par exemple, démarrer un nouveau {{< glossary_tooltip text="Pod" term_id="pod">}} lorsque le champ `replicas` d'un déploiement n'est pas satisfait).
|
||||
|
||||
Les composants Master peuvent être exécutés sur n'importe quelle machine du cluster. Toutefois,
|
||||
par soucis de simplicité, les scripts de mise en route démarrent typiquement tous les composants master sur la
|
||||
par soucis de simplicité, les scripts de mise en route démarrent typiquement tous les composants master sur la
|
||||
même machine et n'exécutent pas de conteneurs utilisateur sur cette machine.
|
||||
Voir [Construire des Clusters en Haute Disponibilité](/docs/admin/high-availability/) pour une configuration d'exemple en multi-master-VM.
|
||||
|
||||
@@ -46,16 +46,16 @@ Ces contrôleurs incluent :
|
||||
* Replication Controller : Responsable de maintenir le bon nombre de pods pour chaque objet
|
||||
ReplicationController dans le système.
|
||||
* Endpoints Controller : Remplit les objets Endpoints (c'est-à-dire joint les Services et Pods).
|
||||
* Service Account & Token Controllers : Créent des comptes par défaut et des jetons d'accès à l'API
|
||||
* Service Account & Token Controllers : Créent des comptes par défaut et des jetons d'accès à l'API
|
||||
pour les nouveaux namespaces.
|
||||
|
||||
### cloud-controller-manager
|
||||
|
||||
Le [cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) exécute les contrôleurs
|
||||
qui interagissent avec les fournisseurs cloud sous-jacents. Le binaire du cloud-controller-manager est une
|
||||
Le [cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) exécute les contrôleurs
|
||||
qui interagissent avec les fournisseurs cloud sous-jacents. Le binaire du cloud-controller-manager est une
|
||||
fonctionnalité alpha introduite dans la version 1.6 de Kubernetes.
|
||||
|
||||
Le cloud-controller-manager exécute seulement les boucles spécifiques des fournisseurs cloud.
|
||||
Le cloud-controller-manager exécute seulement les boucles spécifiques des fournisseurs cloud.
|
||||
Vous devez désactiver ces boucles de contrôleurs dans le kube-controller-manager.
|
||||
Vous pouvez désactiver les boucles de contrôleurs en définissant la valeur du flag `--cloud-provider` à `external` lors du démarrage du kube-controller-manager.
|
||||
|
||||
@@ -89,30 +89,30 @@ et en fournissant l'environnement d'exécution Kubernetes.
|
||||
## Addons
|
||||
|
||||
Les addons utilisent les ressources Kubernetes ({{< glossary_tooltip term_id="daemonset" >}}, {{< glossary_tooltip term_id="deployment" >}}, etc)
|
||||
pour implémenter des fonctionnalités cluster. Comme ces derniers fournissent des fonctionnalités au niveau
|
||||
pour implémenter des fonctionnalités cluster. Comme ces derniers fournissent des fonctionnalités au niveau
|
||||
du cluster, les ressources dans des namespaces pour les addons appartiennent au namespace `kube-system`.
|
||||
|
||||
Les addons sélectionnés sont décrits ci-dessous. Pour une liste étendue des addons disponibles, voir la page
|
||||
Les addons sélectionnés sont décrits ci-dessous. Pour une liste étendue des addons disponibles, voir la page
|
||||
[Addons](/docs/concepts/cluster-administration/addons/).
|
||||
|
||||
### DNS
|
||||
|
||||
Tandis que les autres addons ne sont pas strictement requis, tous les clusters Kubernetes devraient avoir un
|
||||
Tandis que les autres addons ne sont pas strictement requis, tous les clusters Kubernetes devraient avoir un
|
||||
[DNS cluster](/fr/docs/concepts/services-networking/dns-pod-service/) car de nombreux exemples en dépendent.
|
||||
|
||||
Le DNS Cluster est un serveur DNS, en plus des autres serveurs DNS dans votre environnement, qui sert
|
||||
Le DNS Cluster est un serveur DNS, en plus des autres serveurs DNS dans votre environnement, qui sert
|
||||
les enregistrements DNS pour les services Kubernetes.
|
||||
|
||||
Les conteneurs démarrés par Kubernetes incluent automatiquement ce serveur DNS dans leurs recherches DNS.
|
||||
|
||||
### Interface utilisateur Web (Dashboard)
|
||||
|
||||
Le [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) est une interface utilisateur web à but général pour les clusters Kubernetes. Il permet aux utilisateurs de gérer et de dépanner aussi bien des
|
||||
Le [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) est une interface utilisateur web à but général pour les clusters Kubernetes. Il permet aux utilisateurs de gérer et de dépanner aussi bien des
|
||||
applications s'exécutant dans le cluster que le cluster lui-même.
|
||||
|
||||
### La surveillance des ressources de conteneur
|
||||
|
||||
[La surveillance des ressources de conteneur](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) enregistre des métriques chronologiques génériques à propos des conteneurs dans une base de données centrale et
|
||||
[La surveillance des ressources de conteneur](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) enregistre des métriques chronologiques génériques à propos des conteneurs dans une base de données centrale et
|
||||
fournit une interface utilisateur pour parcourir ces données.
|
||||
|
||||
### Le logging au niveau cluster
|
||||
|
||||
@@ -6,11 +6,11 @@ weight: 10
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Les fichiers sur disque dans un conteneur sont éphémères, ce qui présente des problèmes pour
|
||||
des applications non-triviales lorsqu'elles s'exécutent dans des conteneurs. Premièrement, lorsqu'un
|
||||
conteneur plante, kubelet va le redémarrer mais les fichiers seront perdus - le conteneur démarre
|
||||
avec un état propre. Deuxièmement, lorsque plusieurs conteneurs s'exécutent ensemble dans un `Pod`,
|
||||
il est souvent nécessaire de partager des fichiers entre ces conteneurs. L'abstraction Kubernetes
|
||||
Les fichiers sur disque dans un conteneur sont éphémères, ce qui présente des problèmes pour
|
||||
des applications non-triviales lorsqu'elles s'exécutent dans des conteneurs. Premièrement, lorsqu'un
|
||||
conteneur plante, kubelet va le redémarrer mais les fichiers seront perdus - le conteneur démarre
|
||||
avec un état propre. Deuxièmement, lorsque plusieurs conteneurs s'exécutent ensemble dans un `Pod`,
|
||||
il est souvent nécessaire de partager des fichiers entre ces conteneurs. L'abstraction Kubernetes
|
||||
`Volume` résout ces deux problèmes.
|
||||
|
||||
Une connaissance des [Pods](/fr/docs/concepts/workloads/pods/pod) est suggérée.
|
||||
@@ -21,14 +21,14 @@ Une connaissance des [Pods](/fr/docs/concepts/workloads/pods/pod) est suggérée
|
||||
|
||||
## Contexte
|
||||
|
||||
Docker a également un concept de [volumes](https://docs.docker.com/engine/admin/volumes/), bien qu'il
|
||||
Docker a également un concept de [volumes](https://docs.docker.com/engine/admin/volumes/), bien qu'il
|
||||
soit, dans une certaine mesure, plus relâché et moins géré.
|
||||
Avec Docker, un volume est simplement un dossier sur le disque ou dans un autre conteneur.
|
||||
Les durées de vie ne sont pas gérées et, jusqu'à très récemment, seuls les volumes supportés par un disque local l'étaient.
|
||||
Docker fournit maintenant des pilotes de volume, mais la fonctionnalité est très limitée pour le moment (par exemple, à partir de Docker 1.7, seulement un pilote de volume est autorisé par conteneur et il n'est pas possible de passer des paramètres aux volumes).
|
||||
|
||||
|
||||
Un volume Kubernetes, en revanche, a une durée de vie explicite - la même que le Pod qui l'inclut.
|
||||
Par conséquent, un volume survit aux conteneurs qui s'exécutent à l'intérieur du Pod et les données sont préservées lorsque le conteneur redémarre.
|
||||
Par conséquent, un volume survit aux conteneurs qui s'exécutent à l'intérieur du Pod et les données sont préservées lorsque le conteneur redémarre.
|
||||
Bien sûr, lorsqu'un Pod cesse d'exister, le volume va également cesser d'exister.
|
||||
Peut-être plus important encore, Kubernetes supporte de nombreux types de volumes et un Pod peut en utiliser plusieurs simultanément.
|
||||
|
||||
@@ -79,7 +79,7 @@ Toute contribution supplémentaire est la bienvenue.
|
||||
|
||||
### awsElasticBlockStore {#awselasticblockstore}
|
||||
|
||||
Un type de volume `awsElasticBlockStore` monte un [Volume EBS](http://aws.amazon.com/ebs/) d'Amazon Web Services (AWS) dans un Pod.
|
||||
Un type de volume `awsElasticBlockStore` monte un [Volume EBS](http://aws.amazon.com/ebs/) d'Amazon Web Services (AWS) dans un Pod.
|
||||
À la différence de `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un volume EBS
|
||||
est préservé et le volume est seulement démonté. Cela signifie qu'un volume EBS peut être prérempli avec des données et que les données peuvent être transmises entre les Pods.
|
||||
|
||||
@@ -132,7 +132,7 @@ spec:
|
||||
|
||||
La fonctionnalité de migration CSI pour awsElasticBlockStore, lorsque activée, fixe toutes les opérations de plugin depuis le plugin "in-tree" vers le pilote de l'interface CSI (Container Storage Interface) `ebs.csi.aws.com`.
|
||||
Afin d'utiliser cette fonctionnalité, le [Pilote AWS EBS CSI](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) doit être installé dans le cluster et les fonctionnalités Alpha `CSIMigration` et `CSIMigrationAWS` doivent être activées.
|
||||
|
||||
|
||||
### azureDisk {#azuredisk}
|
||||
|
||||
Un type de volume `azureDisk` est utilisé pour monter un disque de données ([Data Disk](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-about-disks-vhds/)) dans un Pod.
|
||||
@@ -175,7 +175,7 @@ Voir [l'exemple CephFS](https://github.com/kubernetes/examples/tree/{{< param "g
|
||||
### cinder {#cinder}
|
||||
|
||||
{{< note >}}
|
||||
prérequis : Kubernetes avec le fournisseur infonuagique OpenStack (OpenStack Cloud Provider) configuré.
|
||||
prérequis : Kubernetes avec le fournisseur infonuagique OpenStack (OpenStack Cloud Provider) configuré.
|
||||
Pour la configuration cloudprovider, se référer à [cloud provider openstack](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#openstack).
|
||||
{{< /note >}}
|
||||
|
||||
@@ -213,10 +213,10 @@ Afin d'utiliser cette fonctionnalité, le [Pilote Cinder CSI](https://github.com
|
||||
### configMap {#configmap}
|
||||
|
||||
La ressource [`configMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) fournit un moyen d'injecter des données de configuration dans les Pods.
|
||||
Les données stockées dans un objet `ConfigMap` peuvent être référencées dans un volume de type `configMap`
|
||||
Les données stockées dans un objet `ConfigMap` peuvent être référencées dans un volume de type `configMap`
|
||||
et être ensuite consommées par des applications conteneurisées s'exécutant dans un Pod.
|
||||
|
||||
Lorsque l'on référence un objet `configMap`, on peut simplement fournir son nom dans le volume
|
||||
Lorsque l'on référence un objet `configMap`, on peut simplement fournir son nom dans le volume
|
||||
pour le référencer. On peut également personnaliser le chemin pour utiliser une entrée spécifique dans
|
||||
la ConfigMap. Par exemple, pour monter la ConfigMap `log-config` sur un Pod appelé `configmap-pod`,
|
||||
vous pourriez utiliser le YAML suivant :
|
||||
@@ -307,7 +307,7 @@ spec:
|
||||
### fc (fibre channel) {#fc}
|
||||
|
||||
Un volume `fc` permet à un volume Fibre Channel existant d'être monté dans un Pod.
|
||||
Vous pouvez spécifier une ou plusieurs cibles World Wide Names en utilisant le paramètre
|
||||
Vous pouvez spécifier une ou plusieurs cibles World Wide Names en utilisant le paramètre
|
||||
`targetWWNs` dans votre configuration de volume.
|
||||
Si plusieurs WWNs sont spécifiés, targetWWNs s'attend à ce que ces WWNs proviennent de connexions multi-path.
|
||||
|
||||
@@ -334,7 +334,7 @@ Voir [l'exemple Flocker](https://github.com/kubernetes/examples/tree/{{< param "
|
||||
|
||||
### gcePersistentDisk {#gcepersistentdisk}
|
||||
|
||||
Un volume `gcePersistentDisk` monte un [Disque Persistant](http://cloud.google.com/compute/docs/disks) Google Compute Engine (GCE) dans un Pod.
|
||||
Un volume `gcePersistentDisk` monte un [Disque Persistant](http://cloud.google.com/compute/docs/disks) Google Compute Engine (GCE) dans un Pod.
|
||||
À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un disque persistant est préservé et le volume est simplement démonté. Cela signifie qu'un disque persistant peut être prérempli avec des données et que ces données peuvent être transmises entre les Pods.
|
||||
|
||||
{{< caution >}}
|
||||
@@ -347,7 +347,7 @@ Des restrictions existent lors de l'utilisation d'un `gcePersistentDisk`:
|
||||
* ces VMs doivent se trouver dans le même projet et la même zone GCE que le disque persistant
|
||||
|
||||
Une fonctionnalité des disques persistants est qu'ils peuvent être montés en lecture seule par plusieurs consommateurs simultanément.
|
||||
Cela signifie que vous pouvez préremplir un disque persistant avec votre jeu de données et l'exposer en parallèle à partir d'autant de Pods que nécessaire.
|
||||
Cela signifie que vous pouvez préremplir un disque persistant avec votre jeu de données et l'exposer en parallèle à partir d'autant de Pods que nécessaire.
|
||||
Malheureusement, les disques persistants peuvent seulement être montés par un seul consommateur en mode lecture-écriture - les écritures simultanées ne sont pas autorisées.
|
||||
|
||||
Utiliser un disque persistant dans un Pod contrôlé par un ReplicationController échouera à moins que le disque persistant soit en lecture seule ou que le nombre de répliques soit de 0 ou 1.
|
||||
@@ -459,7 +459,7 @@ spec:
|
||||
Un volume `glusterfs` permet à un volume [Glusterfs](http://www.gluster.org) (un système de fichiers en réseau open
|
||||
source) d'être monté dans un Pod. À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé. le contenu d'un volume `glusterfs` est préservé et le volume est simplement démonté.
|
||||
Cela signifie qu'un volume glusterfs peut être prérempli avec des données et que ces données peuvent être transmises entre les Pods.
|
||||
GlusterFS peut être monté plusieurs fois en écriture simultanément.
|
||||
GlusterFS peut être monté plusieurs fois en écriture simultanément.
|
||||
|
||||
{{< caution >}}
|
||||
Vous devez exécuter votre propre installation de GlusterFS avant de pouvoir l'utiliser.
|
||||
@@ -469,7 +469,7 @@ Voir [l'exemple GlusterFS](https://github.com/kubernetes/examples/tree/{{< param
|
||||
|
||||
### hostPath {#hostpath}
|
||||
|
||||
Un volume `hostPath` monte un fichier ou un dossier depuis le système de fichiers du nœud hôte à l'intérieur d'un Pod.
|
||||
Un volume `hostPath` monte un fichier ou un dossier depuis le système de fichiers du nœud hôte à l'intérieur d'un Pod.
|
||||
Ce ne sera pas requis pour la plupart des Pods, mais cela offre une puissante solution de secours pour certaines applications.
|
||||
|
||||
Par exemple, des utilisations du `hostPath` peuvent être :
|
||||
@@ -525,7 +525,7 @@ spec:
|
||||
|
||||
### iscsi {#iscsi}
|
||||
|
||||
Un volume `iscsi` permet à un volume existant iSCSI (SCSI over IP) d'être monté dans un Pod.
|
||||
Un volume `iscsi` permet à un volume existant iSCSI (SCSI over IP) d'être monté dans un Pod.
|
||||
À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un volume `iscsi` est préservé et le volume est simplement démonté.
|
||||
Cela signifie qu'un volume iscsi peut être prérempli avec des données que ces données peuvent être transmises entre les Pods.
|
||||
|
||||
@@ -534,7 +534,7 @@ Vous devez exécuter votre propre serveur iSCSI avec le volume créé avant de p
|
||||
{{< /caution >}}
|
||||
|
||||
Une fonctionnalité de iSCSI est qu'il peut être monté en lecture seule par plusieurs consommateurs simultanément.
|
||||
Cela signifie que vous pouvez préremplir un volume avec votre jeu de données et l'exposer en parallèle à partir d'autant de Pods que nécessaire.
|
||||
Cela signifie que vous pouvez préremplir un volume avec votre jeu de données et l'exposer en parallèle à partir d'autant de Pods que nécessaire.
|
||||
Malheureusement, les volumes iSCSI peuvent seulement être montés par un seul consommateur en mode lecture-écriture - les écritures simultanées ne sont pas autorisées.
|
||||
|
||||
Voir [l'exemple iSCSI](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi) pour plus de détails.
|
||||
@@ -545,7 +545,7 @@ Voir [l'exemple iSCSI](https://github.com/kubernetes/examples/tree/{{< param "gi
|
||||
|
||||
Un volume `local` représente un périphérique de stockage local monté tels qu'un disque, une partition ou un dossier.
|
||||
|
||||
Les volumes locaux peuvent seulement être utilisés comme un PersistentVolume créé statiquement.
|
||||
Les volumes locaux peuvent seulement être utilisés comme un PersistentVolume créé statiquement.
|
||||
Le provisionnement dynamique n'est pas encore supporté.
|
||||
|
||||
Comparés aux volumes `hostPath`, les volumes locaux peuvent être utilisés de manière durable et portable sans planifier manuellement des Pods sur les nœuds, puisque le système est conscient des contraintes de nœud du volume en examinant l'affinité de nœud sur le PersistentVolume.
|
||||
@@ -580,10 +580,10 @@ spec:
|
||||
- example-node
|
||||
```
|
||||
|
||||
La `nodeAffinity` d'un PersistentVolume est requise lors de l'utilisation de volumes locaux.
|
||||
La `nodeAffinity` d'un PersistentVolume est requise lors de l'utilisation de volumes locaux.
|
||||
Cela permet au planificateur (scheduler) Kubernetes de planifier correctement des Pods utilisant des volumes locaux aux bons nœuds.
|
||||
|
||||
Le `volumeMode` d'un PersistentVolume peut maintenant être configuré à "Block" (au lieu de la valeur par défaut "Filesystem") pour exposer le volume local en tant que périphérique bloc brut (raw block device).
|
||||
Le `volumeMode` d'un PersistentVolume peut maintenant être configuré à "Block" (au lieu de la valeur par défaut "Filesystem") pour exposer le volume local en tant que périphérique bloc brut (raw block device).
|
||||
Le champ `volumeMode` requiert l'activation de la "feature gate" Alpha `BlockVolume`.
|
||||
|
||||
Lors de l'utilisation des volumes locaux, il est recommandé de créer une StorageClass avec `volumeBindingMode` configuré à `WaitForFirstConsumer`. Voir [l'exemple](/docs/concepts/storage/storage-classes/#local). Retarder la liaison (binding) du volume garantit que la décision de liaison du PersistentVolumeClaim sera également évaluée avec toutes les autres contraintes de nœud que le Pod peut avoir, tels que les exigences en ressources du nœud, les sélecteurs de nœud, leur affinité et leur anti-affinité.
|
||||
@@ -598,7 +598,7 @@ Le PersistentVolume local requiert un nettoyage manuel et une suppression par l'
|
||||
### nfs {#nfs}
|
||||
|
||||
Un volume `nfs` permet à un partage NFS (Network File System) existant d'être monté dans un Pod.
|
||||
À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un volume `nfs` est préservé et le volume est simplement démonté.
|
||||
À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un volume `nfs` est préservé et le volume est simplement démonté.
|
||||
Cela signifie qu'un volume NFS peut être prérempli avec des données et que les données peuvent être transmises entre les Pods. NFS peut être monté plusieurs fois en écriture simultanément.
|
||||
|
||||
{{< caution >}}
|
||||
@@ -701,7 +701,7 @@ spec:
|
||||
mode: 511
|
||||
```
|
||||
|
||||
Chaque source de volume projeté est listée dans la spec, sous `sources`. Les paramètres sont à peu près les mêmes avec deux exceptions :
|
||||
Chaque source de volume projeté est listée dans la spec, sous `sources`. Les paramètres sont à peu près les mêmes avec deux exceptions :
|
||||
|
||||
* Pour les secrets, le champ `secretName` a été changé par `name` pour être consistant avec le nommage des ConfigMap.
|
||||
* Le `defaultMode` peut seulement être spécifié au niveau projeté et non pour chaque source de volume. Cependant, tel qu'illustré au-dessus, il est possible de configurer explicitement le `mode` pour chaque projection individuelle.
|
||||
@@ -731,10 +731,10 @@ spec:
|
||||
path: token
|
||||
```
|
||||
|
||||
Le pod d'exemple possède un volume projeté contenant le jeton injecté du service account.
|
||||
Ce jeton peut être utilisé par des conteneurs de Pod pour accéder au service d'API Kubernetes API, par exemple.
|
||||
Le champ `audience` contient l'audience-cible du jeton.
|
||||
Un destinataire du jeton doit s'identifier avec un identificateur spécifié dans l'audience du jeton, sinon il doit rejeter le jeton. Ce champ est facultatif et sa valeur par défaut est l'identifiant du serveur API.
|
||||
Le pod d'exemple possède un volume projeté contenant le jeton injecté du service account.
|
||||
Ce jeton peut être utilisé par des conteneurs de Pod pour accéder au service d'API Kubernetes API, par exemple.
|
||||
Le champ `audience` contient l'audience-cible du jeton.
|
||||
Un destinataire du jeton doit s'identifier avec un identificateur spécifié dans l'audience du jeton, sinon il doit rejeter le jeton. Ce champ est facultatif et sa valeur par défaut est l'identifiant du serveur API.
|
||||
|
||||
Le champ `expirationSeconds` est la durée de validité attendue du jeton de service account.
|
||||
Sa valeur par défaut est de 1 heure et doit être au moins de 10 minutes (600 secondes). Un administrateur peut aussi limiter sa valeur maximum en spécifiant l'option `--service-account-max-token-expiration` pour le serveur API.
|
||||
@@ -750,7 +750,7 @@ Un `portworxVolume` est une couche de stockage bloc élastique qui s'exécute de
|
||||
[Portworx](https://portworx.com/use-case/kubernetes-storage/) donne l'empreinte digitale d'un stockage dans un serveur, tiers basés sur les capacités et agrège la capacité sur plusieurs serveurs. Portworx s'exécute en invité sur des machines virtuelles ou sur des nœuds Linux bare metal.
|
||||
|
||||
Un `portworxVolume` peut être créé dynamiquement à travers Kubernetes ou il peut également être pré-provisionné et référencé à l'intérieur d'un Pod Kubernetes.
|
||||
Voici un exemple de Pod référençant un PortworxVolume pré-provisionné :
|
||||
Voici un exemple de Pod référençant un PortworxVolume pré-provisionné :
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -786,29 +786,29 @@ Un volume `quobyte` permet à un volume existant [Quobyte](http://www.quobyte.co
|
||||
Vous devez exécuter votre propre configuration Quobyte avec les volumes créés avant de pouvoir l'utiliser.
|
||||
{{< /caution >}}
|
||||
|
||||
Quobyte supporte le {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}}.
|
||||
Quobyte supporte le {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}}.
|
||||
CSI est le plugin recommandé pour utiliser les volumes Quobyte volumes dans Kubernetes. Le projet GitHub Quobyte dispose [d'instructions](https://github.com/quobyte/quobyte-csi#quobyte-csi) pour déployer Quobyte en utilisant CSI, avec des exemples.
|
||||
|
||||
### rbd {#rbd}
|
||||
|
||||
Un volume `rbd` permet à un volume périphérique bloc Rados ([Rados Block
|
||||
Device](http://ceph.com/docs/master/rbd/rbd/)) d'être monté dans un Pod.
|
||||
À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un volume `rbd` est préservé et le volume est simplement démonté.
|
||||
À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un volume `rbd` est préservé et le volume est simplement démonté.
|
||||
Cela signifie qu'un volume RBD peut être prérempli avec des données et que ces données peuvent être transmises entre les Pods.
|
||||
|
||||
{{< caution >}}
|
||||
Vous devez exécuter votre propre installation Ceph avant de pouvoir utiliser RBD.
|
||||
{{< /caution >}}
|
||||
|
||||
Une fonctionnalité de RBD est qu'il peut être monté en lecture seule par plusieurs consommateurs simultanément.
|
||||
Cela signifie que vous pouvez préremplir un volume avec votre jeu de données et l'exposer en parallèle à partir d'autant de Pods que nécessaire.
|
||||
Une fonctionnalité de RBD est qu'il peut être monté en lecture seule par plusieurs consommateurs simultanément.
|
||||
Cela signifie que vous pouvez préremplir un volume avec votre jeu de données et l'exposer en parallèle à partir d'autant de Pods que nécessaire.
|
||||
Malheureusement, les volumes RBD peuvent seulement être montés par un seul consommateur en mode lecture-écriture - les écritures simultanées ne sont pas autorisées.
|
||||
|
||||
Voir [l'exemple RBD](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd) pour plus de détails.
|
||||
|
||||
### scaleIO {#scaleio}
|
||||
|
||||
ScaleIO est une plateforme de stockage logicielle qui peut utiliser du matériel physique existant pour créer des clusters de stockage bloc partagé en réseau évolutif.
|
||||
ScaleIO est une plateforme de stockage logicielle qui peut utiliser du matériel physique existant pour créer des clusters de stockage bloc partagé en réseau évolutif.
|
||||
Le plugin de volume `scaleIO` permet aux Pods déployés d'accéder à des volumes ScaleIO existants (ou il peut provisionner dynamiquement de nouveaux volumes pour des revendications de volumes persistants, voir [ScaleIO Persistent Volumes](/docs/concepts/storage/persistent-volumes/#scaleio)).
|
||||
|
||||
{{< caution >}}
|
||||
@@ -846,7 +846,7 @@ Pour plus de détails, consulter [les exemples ScaleIO](https://github.com/kuber
|
||||
|
||||
### secret {#secret}
|
||||
|
||||
Un volume `secret` est utilisé pour fournir des informations sensibles, comme des mots de passe, aux Pods.
|
||||
Un volume `secret` est utilisé pour fournir des informations sensibles, comme des mots de passe, aux Pods.
|
||||
Vous pouvez stocker des secrets dans l'API Kubernetes et les monter en tant que fichiers pour être utilisés par les Pods sans les coupler directement avec Kubernetes. Les volumes `secret` sont supportés par tmpfs (un système de fichiers en RAM) pour qu'ils ne soient jamais écrits sur du stockage non volatil.
|
||||
|
||||
{{< caution >}}
|
||||
@@ -864,7 +864,7 @@ Les secrets sont décrits plus en détails [ici](/docs/user-guide/secrets).
|
||||
Un volume `storageos` permet à un volume [StorageOS](https://www.storageos.com) existant d'être monté dans un Pod.
|
||||
|
||||
StorageOS s'exécute en tant que conteneur dans l'environnement Kubernetes en rendant le stockage local ou attaché accessible depuis n'importe quel nœud dans le cluster Kubernetes.
|
||||
Les données peuvent être répliquées pour se protéger des défaillances de nœuds.
|
||||
Les données peuvent être répliquées pour se protéger des défaillances de nœuds.
|
||||
Les techniques d'allocation fine et dynamique et de compression peuvent améliorer l'utilisation et réduire les coûts.
|
||||
|
||||
À la base, StorageOS fournit un stockage bloc aux conteneurs accessible via un système de fichiers.
|
||||
@@ -1046,9 +1046,9 @@ spec:
|
||||
|
||||
## Ressources
|
||||
|
||||
Le support de stockage (Disk, SSD, etc.) d'un volume `emptyDir` est déterminé par le support du système de fichiers
|
||||
Le support de stockage (Disk, SSD, etc.) d'un volume `emptyDir` est déterminé par le support du système de fichiers
|
||||
contenant le dossier racine de kubelet (typiquement `/var/lib/kubelet`).
|
||||
Il n'y a pas de limite sur l'espace qu'un volume `emptyDir` ou `hostPath` peut consommer
|
||||
Il n'y a pas de limite sur l'espace qu'un volume `emptyDir` ou `hostPath` peut consommer
|
||||
et pas d'isolation entre les conteneurs ou entre les Pods.
|
||||
|
||||
Dans le futur, il est prévu que les volumes `emptyDir` et `hostPath` soient en mesure de demander une certaine quantité d'espace en utilisant une spécification de [ressource](/docs/user-guide/compute-resources) et de sélectionner un type de support à utiliser, pour les clusters qui ont plusieurs types de support.
|
||||
@@ -1086,30 +1086,30 @@ utiliser le type de volume `csi` pour attacher, monter, etc.., les volumes expos
|
||||
|
||||
Le type de volume `csi` ne supporte pas de référence directe depuis un Pod et ne peut être référencé seulement dans un Pod que par un objet `PersistentVolumeClaim`.
|
||||
|
||||
Les champs suivants sont disponibles aux administrateurs de stockage pour configurer un volume persistant CSI :
|
||||
Les champs suivants sont disponibles aux administrateurs de stockage pour configurer un volume persistant CSI :
|
||||
|
||||
- `driver`: Une valeur texte qui spécifie le nom du pilote de volume à utiliser.
|
||||
Cette valeur doit correspondre à la valeur retournée dans le `GetPluginInfoResponse` par le pilote CSI tel que défini dans la
|
||||
Cette valeur doit correspondre à la valeur retournée dans le `GetPluginInfoResponse` par le pilote CSI tel que défini dans la
|
||||
[spec CSI](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo).
|
||||
Elle est utilisée par Kubernetes pour identifier le pilote CSI à appeler et par les composants du pilote CSI
|
||||
pour identifier quels objets PV appartiennent au pilote CSI.
|
||||
- `volumeHandle`: Une valeur texte qui identifie le volume de manière unique. Cette valeur doit correspondre à la valeur retournée dans le champ `volume.id` de `CreateVolumeResponse` par le pilote CSI tel que défini dans la [spec CSI](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume).
|
||||
La valeur est passée en tant que `volume_id` sur tous les appels au pilote de volume CSI lorsque le volume est référencé.
|
||||
- `readOnly`: Une valeur booléenne optionnelle indiquant si le volume doit être
|
||||
- `readOnly`: Une valeur booléenne optionnelle indiquant si le volume doit être
|
||||
"ControllerPublished" (attaché) en lecture seule. La valeur par défaut est "false". Cette valeur est passées au pilote CSI
|
||||
via le champ `readonly` dans le `ControllerPublishVolumeRequest`.
|
||||
- `fsType`: Si le `VolumeMode` du PV est `Filesystem`, alors ce champ peut être utilisé pour spécifier le système de fichiers
|
||||
qui devrait être utilisé pour monter le volume. Si le volume n'a pas été formaté et que le formatage est supporté, cette valeur sera
|
||||
qui devrait être utilisé pour monter le volume. Si le volume n'a pas été formaté et que le formatage est supporté, cette valeur sera
|
||||
utilisée pour formater le volume.
|
||||
Cette valeur est passée au pilote CSI driver via le champ `VolumeCapability` de
|
||||
Cette valeur est passée au pilote CSI driver via le champ `VolumeCapability` de
|
||||
`ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, et
|
||||
`NodePublishVolumeRequest`.
|
||||
- `volumeAttributes`: Un tableau associatif (map) string vers string qui spécifie les propriétés statiques d'un volume. Ce tableau associatif doit correspondre à celui retourné dans le champ
|
||||
- `volumeAttributes`: Un tableau associatif (map) string vers string qui spécifie les propriétés statiques d'un volume. Ce tableau associatif doit correspondre à celui retourné dans le champ
|
||||
`volume.attributes` du `CreateVolumeResponse` par le pilote CSI tel que défini dans
|
||||
la [spec CSI](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume).
|
||||
Le tableau associatif est passé au pilote CSI via le champ `volume_attributes` dans la `ControllerPublishVolumeRequest`, `NodeStageV olumeRequest`, et `NodePublishVolumeRequest`.
|
||||
- `controllerPublishSecretRef`: Une référence de l'objet de type secret contenant des informations sensibles à passer
|
||||
au driver CSI pour compléter les appels CSI `ControllerPublishVolume` et `ControllerUnpublishVolume`.
|
||||
- `controllerPublishSecretRef`: Une référence de l'objet de type secret contenant des informations sensibles à passer
|
||||
au driver CSI pour compléter les appels CSI `ControllerPublishVolume` et `ControllerUnpublishVolume`.
|
||||
Ce champ est optionnel et peut être vide si aucun secret n'est requis.
|
||||
Si l'objet secret contient plus qu'un secret, tous les secrets sont passés.
|
||||
- `nodeStageSecretRef`: Une référence à l'objet de type secret contenant des informations sensibles à passer au pilote CSI
|
||||
@@ -1123,7 +1123,7 @@ Les champs suivants sont disponibles aux administrateurs de stockage pour config
|
||||
|
||||
{{< feature-state for_k8s_version="v1.14" state="beta" >}}
|
||||
|
||||
À partir de la version 1.11, CSI a introduit le support des volumes bloc bruts, qui s'appuient
|
||||
À partir de la version 1.11, CSI a introduit le support des volumes bloc bruts, qui s'appuient
|
||||
sur la fonctionnalité de volume bloc brut introduite dans une version précédente de Kubernetes.
|
||||
Cette fonctionnalité va permettre aux fournisseurs avec des pilotes CSI externes d'implémenter le support pour les volumes bloc bruts
|
||||
dans les charges de travail Kubernetes.
|
||||
@@ -1178,7 +1178,7 @@ Pour plus d'informations sur la manière de développer un pilote CSI, se réfé
|
||||
{{< feature-state for_k8s_version="v1.14" state="alpha" >}}
|
||||
|
||||
La fonctionnalité de migration CSI, lorsque activée, dirige les opérations sur les plugins "in-tree" existants vers les plugins CSI correspondants (qui sont sensés être installés et configurés).
|
||||
Cette fonctionnalité implémente la logique de translation nécessaire et les fixations nécessaires pour rerouter les opérations
|
||||
Cette fonctionnalité implémente la logique de translation nécessaire et les fixations nécessaires pour rerouter les opérations
|
||||
de manière transparente. En conséquence, les opérateurs n'ont pas à effectuer de changements de configuration aux classes de stockage (Storage Classes) existantes, PV ou PVC (référençant aux plugins "in-tree") lors de la transition vers un pilote CSI qui remplace un plugin "in-tree".
|
||||
|
||||
Dans l'état alpha, les opérations et fonctionnalités qui sont supportées incluent provisionnement/suppression, attachement/détachement, montage/démontage et le redimensionnement des volumes.
|
||||
@@ -1198,7 +1198,7 @@ Plus de détails sont disponibles [ici](https://github.com/kubernetes/community/
|
||||
La propagation de montage permet à des volumes partagés montés par un conteneur à d'autres conteneurs dans un même Pod, ou même à d'autres Pods dans le même nœud.
|
||||
|
||||
La propagation de montage d'un volume est contrôlée par le champ `mountPropagation` dans Container.volumeMounts.
|
||||
Ses valeurs sont :
|
||||
Ses valeurs sont :
|
||||
|
||||
* `None` - Ce montage de volume ne recevra aucun montage subséquent qui est monté à ce volume ou n'importe lequel de ses sous-dossiers par l'hôte. De la même manière, aucun montage créé par le conteneur ne sera visible sur l'hôte. C'est le mode par défaut.
|
||||
|
||||
@@ -1207,7 +1207,7 @@ Ses valeurs sont :
|
||||
* `HostToContainer` - Ce montage de volume recevra les montages subséquents qui sont montés sur ce volume ou n'importe lequel de ses sous-dossiers.
|
||||
|
||||
En d'autres termes, si l'hôte monte quoi que ce soit dans le montage de volume, le conteneur va le voir monté à cet endroit.
|
||||
|
||||
|
||||
De manière similaire, si un Pod avec la propagation de montage `Bidirectional` vers le même volume y monte quoi que ce soit,
|
||||
le conteneur avec la propagation de montage `HostToContainer` le verra.
|
||||
|
||||
@@ -1223,7 +1223,7 @@ Ses valeurs sont :
|
||||
[documentation du noyau Linux](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)
|
||||
|
||||
{{< caution >}}
|
||||
La propagation de montage `Bidirectional` peut être dangereuse. Elle peut endommager le système d'exploitation hôte
|
||||
La propagation de montage `Bidirectional` peut être dangereuse. Elle peut endommager le système d'exploitation hôte
|
||||
et est donc autorisée seulement dans des conteneurs privilégiés.
|
||||
Il est fortement recommandé d'être familier avec le comportement du noyau Linux.
|
||||
De plus, tous les montages de volume créés par des conteneurs dans des Pods doivent être détruits (démontés) par les conteneurs lors de la terminaison.
|
||||
@@ -1231,7 +1231,7 @@ De plus, tous les montages de volume créés par des conteneurs dans des Pods do
|
||||
|
||||
### Configuration
|
||||
Avant que la propagation de montage puisse fonctionner correctement sur certains déploiements (CoreOS,
|
||||
RedHat/Centos, Ubuntu) le partage de montage doit être correctement configuré dans Docker tel qu'illustré ci-dessous :
|
||||
RedHat/Centos, Ubuntu) le partage de montage doit être correctement configuré dans Docker tel qu'illustré ci-dessous :
|
||||
|
||||
Modifiez le fichier de service `systemd` de votre Docker. Configurez votre `MountFlags` comme suit :
|
||||
```shell
|
||||
|
||||
@@ -7,7 +7,7 @@ weight: 10
|
||||
{{% capture overview %}}
|
||||
|
||||
Un ReplicaSet (ensemble de réplicas en français) a pour but de maintenir un ensemble stable de Pods à un moment donné.
|
||||
Cet objet est souvent utilisé pour garantir la disponibilité d'un certain nombre identique de Pods.
|
||||
Cet objet est souvent utilisé pour garantir la disponibilité d'un certain nombre identique de Pods.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -15,14 +15,14 @@ Cet objet est souvent utilisé pour garantir la disponibilité d'un certain nomb
|
||||
|
||||
## Comment un ReplicaSet fonctionne
|
||||
|
||||
Un ReplicaSet est défini avec des champs, incluant un selecteur qui spécifie comment identifier les Pods qu'il peut posséder,
|
||||
Un ReplicaSet est défini avec des champs, incluant un selecteur qui spécifie comment identifier les Pods qu'il peut posséder,
|
||||
un nombre de replicas indiquant le nombre de Pods qu'il doit maintenir et un modèle de Pod spécifiant les données que les
|
||||
nouveaux Pods que le replicatSet va créer jusqu'au nombre de replicas demandé.
|
||||
|
||||
Un ReplicaSet va atteindre son objectif en créant et supprimant des Pods pour atteindre le nombre de réplicas désirés.
|
||||
Quand un ReplicaSet a besoin de créer de nouveaux Pods, il utilise alors son Pod template.
|
||||
|
||||
Le lien d'un ReplicaSet à ses Pods est fait par le champ [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents),
|
||||
Le lien d'un ReplicaSet à ses Pods est fait par le champ [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents),
|
||||
qui spécifie la ressource de l'objet par lequel il est détenu. Tous les Pods acquis par un ReplicaSet ont leurs propres informations d'identification de leur Replicaset, avec leur propre champ ownerReferences. C'est par ce lien que le ReplicaSet connait l'état des Pods qu'il maintient et agit en fonction de ces derniers.
|
||||
|
||||
Un ReplicaSet identifie des nouveaux Pods à acquérir en utilisant son selecteur.
|
||||
@@ -276,7 +276,7 @@ Pour mettre à jour les Pods à une nouvelle spec de manière contrôlée, utili
|
||||
### Isoler les pods d'un ReplicaSet
|
||||
|
||||
Vous pouvez supprimer les pods d'un ReplicaSet en modifiant leurs labels. Cette technique peut être utilisée pour enlever les pods
|
||||
pour le débogage, récupération de données, etc. Les pods ainsi supprimés seront automatiquement remplacés
|
||||
pour le débogage, récupération de données, etc. Les pods ainsi supprimés seront automatiquement remplacés
|
||||
(en supposant que le nombre de réplicas n’est pas également modifié).
|
||||
|
||||
### Scaling d'un ReplicaSet
|
||||
@@ -287,7 +287,7 @@ garantit que le nombre souhaité de pods avec un sélecteur de label corresponda
|
||||
### ReplicaSet en tant que Horizontal Pod Autoscaler Target
|
||||
|
||||
Un ReplicaSet peut également être une cible pour
|
||||
[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/).
|
||||
[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/).
|
||||
Un ReplicaSet peut être mis à l'échelle automatiquement par un HPA. Voici un exemple HPA qui cible
|
||||
le ReplicaSet que nous avons créé dans l'exemple précédent.
|
||||
|
||||
@@ -332,7 +332,7 @@ Utilisez un [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) au
|
||||
|
||||
Utilisez un [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) au lieu d’un ReplicaSet pour les pods qui fournissent une
|
||||
fonction au niveau du noeud, comme le monitoring ou la gestion des logs de ce noeud. Ces pods ont une durée de vie qui est liée
|
||||
durée de vie d’une machine : le pod doit être en cours d’exécution sur la machine avant le démarrage des autres Pods et sont
|
||||
durée de vie d’une machine : le pod doit être en cours d’exécution sur la machine avant le démarrage des autres Pods et sont
|
||||
sûrs de se terminer lorsque la machine est prête à être redémarrée/arrêtée.
|
||||
|
||||
### ReplicationController
|
||||
|
||||
@@ -25,35 +25,35 @@ Les init containers se comportent comme les conteneurs réguliers, avec quelques
|
||||
Si le init container d'un Pod échoue, Kubernetes redémarre le Pod à répétition jusqu'à ce que le init container se termine avec succès.
|
||||
Cependant, si le Pod a une `restartPolicy` à "Never", Kubernetes ne redémarre pas le Pod.
|
||||
|
||||
Afin de spécifier un init container pour un Pod, il faut ajouter le champ `initContainers` dans la spécification du Pod, comme un
|
||||
tableau d'objets de type [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core), au même niveau que le tableau d'applications `containers`.
|
||||
Le statut des init containers est retourné dans le champ `.status.initContainerStatuses`
|
||||
Afin de spécifier un init container pour un Pod, il faut ajouter le champ `initContainers` dans la spécification du Pod, comme un
|
||||
tableau d'objets de type [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core), au même niveau que le tableau d'applications `containers`.
|
||||
Le statut des init containers est retourné dans le champ `.status.initContainerStatuses`
|
||||
comme un tableau des statuts du conteneur (comparable au champ `.status.containerStatuses`).
|
||||
|
||||
### Différences avec les conteneurs réguliers
|
||||
|
||||
Les init containers supportent tous les champs et fonctionnalités des conteneurs d'application
|
||||
incluant les limites de ressources, les volumes et les paramètres de sécurité.
|
||||
Cependant, les demandes de ressources pour un init container sont gérées différemment des
|
||||
Les init containers supportent tous les champs et fonctionnalités des conteneurs d'application
|
||||
incluant les limites de ressources, les volumes et les paramètres de sécurité.
|
||||
Cependant, les demandes de ressources pour un init container sont gérées différemment des
|
||||
limites de ressources, tel que documenté dans [Ressources](#ressources).
|
||||
|
||||
De plus, les init containers ne supportent pas les readiness probes parce que ces conteneurs
|
||||
De plus, les init containers ne supportent pas les readiness probes parce que ces conteneurs
|
||||
s'exécutent jusqu'au bout avant que le Pod soit prêt.
|
||||
|
||||
Si l'on spécifie plusieurs init containers pour un Pod, Kubelet exécute chaque
|
||||
init container de manière séquentielle.
|
||||
Chaque init container doit se terminer avec succès avant que le prochain ne puisse s'exécuter.
|
||||
Lorsque tous les init containers se sont exécutés jusqu'au bout, Kubelet initialise
|
||||
Lorsque tous les init containers se sont exécutés jusqu'au bout, Kubelet initialise
|
||||
les conteneurs d'application pour le Pod et les exécute comme d'habitude.
|
||||
|
||||
## Utiliser les init containers
|
||||
|
||||
Puisque les init containers ont des images séparées des conteneurs d'application,
|
||||
Puisque les init containers ont des images séparées des conteneurs d'application,
|
||||
ils apportent certains avantages pour du code de mise en route :
|
||||
|
||||
* Les init containers peuvent contenir des utilitaires ou du code de configuration personnalisé
|
||||
qui ne sont pas présents dans une image d'application.
|
||||
Par exemple, il n'y a pas besoin de faire hériter une image d'une autre (`FROM`) seulement pour utiliser
|
||||
* Les init containers peuvent contenir des utilitaires ou du code de configuration personnalisé
|
||||
qui ne sont pas présents dans une image d'application.
|
||||
Par exemple, il n'y a pas besoin de faire hériter une image d'une autre (`FROM`) seulement pour utiliser
|
||||
un outil comme `sed`, `awk`, `python`, ou `dig` pendant l'installation.
|
||||
* Les init containers peuvent exécuter en toute sécurité des utilitaires qui rendraient moins sécurisée une image de conteneur d'application.
|
||||
* Les rôles "builder" et "deployer" d'une image d'application peuvent travailler indépendamment sans qu'il n'y ait besoin
|
||||
@@ -67,7 +67,7 @@ offrent un mécanisme pour bloquer ou retarder le démarrage d'un conteneur d'ap
|
||||
Voici plusieurs idées pour utiliser les init containers :
|
||||
|
||||
* Attendre qu'un {{< glossary_tooltip text="Service" term_id="service">}} soit créé,
|
||||
en utilisant une commande shell d'une ligne telle que :
|
||||
en utilisant une commande shell d'une ligne telle que :
|
||||
```shell
|
||||
for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
|
||||
```
|
||||
@@ -85,7 +85,7 @@ Voici plusieurs idées pour utiliser les init containers :
|
||||
* Cloner un dépôt Git dans un {{< glossary_tooltip text="Volume" term_id="volume" >}}
|
||||
|
||||
* Placer des valeurs dans un fichier de configuration et exécuter un outil de templating pour générer
|
||||
dynamiquement un fichier de configuration pour le conteneur d'application principal.
|
||||
dynamiquement un fichier de configuration pour le conteneur d'application principal.
|
||||
Par exemple, placer la valeur `POD_IP` dans une configuration et générer le fichier de configuration de l'application principale
|
||||
en utilisant Jinja.
|
||||
|
||||
@@ -207,7 +207,7 @@ kubectl logs myapp-pod -c init-mydb # Inspecter le second init container
|
||||
À ce stade, ces init containers attendent de découvrir les services nommés
|
||||
`mydb` et `myservice`.
|
||||
|
||||
Voici une configuration que vous pouvez utiliser pour faire apparaître ces Services :
|
||||
Voici une configuration que vous pouvez utiliser pour faire apparaître ces Services :
|
||||
|
||||
```yaml
|
||||
---
|
||||
@@ -242,7 +242,7 @@ service/myservice created
|
||||
service/mydb created
|
||||
```
|
||||
|
||||
Vous verrez ensuite que ces init containers se terminent et que le Pod `myapp-pod` évolue vers l'état "Running" (en exécution) :
|
||||
Vous verrez ensuite que ces init containers se terminent et que le Pod `myapp-pod` évolue vers l'état "Running" (en exécution) :
|
||||
|
||||
```shell
|
||||
kubectl get -f myapp.yaml
|
||||
@@ -264,7 +264,7 @@ se termine avec un échec, il est redémarré selon la `restartPolicy` du Pod.
|
||||
Toutefois, si la `restartPolicy` du Pod est configurée à "Always", les init containers utilisent la `restartPolicy` "OnFailure".
|
||||
|
||||
Un Pod ne peut pas être `Ready` tant que tous les init containers ne se sont pas exécutés avec succès.
|
||||
Les ports d'un init container ne sont pas agrégés sous un Service. Un Pod qui s'initialise
|
||||
Les ports d'un init container ne sont pas agrégés sous un Service. Un Pod qui s'initialise
|
||||
est dans l'état `Pending` mais devrait avoir une condition `Initializing` configurée à "true".
|
||||
|
||||
Si le Pod [redémarre](#raisons-du-redémarrage-d-un-pod) ou est redémarré, tous les init containers
|
||||
@@ -273,7 +273,7 @@ doivent s'exécuter à nouveau.
|
||||
Les changements aux spec d'un init containers sont limités au champ image du conteneur.
|
||||
Changer le champ image d'un init container équivaut à redémarrer le Pod.
|
||||
|
||||
Puisque les init containers peuvent être redémarrés, réessayés ou ré-exécutés,
|
||||
Puisque les init containers peuvent être redémarrés, réessayés ou ré-exécutés,
|
||||
leur code doit être idempotent. En particulier, le code qui écrit dans des fichiers sur `EmptyDirs`
|
||||
devrait être préparé à la possibilité qu'un fichier de sortie existe déjà.
|
||||
|
||||
@@ -282,38 +282,38 @@ Cependant, Kubernetes interdit l'utilisation de `readinessProbe` parce que les i
|
||||
ne peuvent pas définir une "readiness" distincte de la complétion. Ceci est appliqué lors de la validation.
|
||||
|
||||
L'utilisation de `activeDeadlineSeconds` sur le Pod et `livenessProbe` sur le conteneur
|
||||
permet d'empêcher les init containers d'échouer tout le temps.
|
||||
permet d'empêcher les init containers d'échouer tout le temps.
|
||||
La deadline active inclut les init containers.
|
||||
|
||||
Le nom de chaque application et init container dans un Pod doit être unique; une erreur de validation
|
||||
Le nom de chaque application et init container dans un Pod doit être unique; une erreur de validation
|
||||
est générée pour tout conteneur partageant un nom avec un autre.
|
||||
|
||||
### Ressources
|
||||
|
||||
Étant donné l'ordonnancement et l'exécution des init containers, les règles suivantes s'appliquent pour l'utilisation des ressources :
|
||||
Étant donné l'ordonnancement et l'exécution des init containers, les règles suivantes s'appliquent pour l'utilisation des ressources :
|
||||
|
||||
* La plus haute requête ou limite particulière de ressource définie pour tous les init containers
|
||||
est la *limite/requête d'initialisation effective*
|
||||
* La *limite/requête effective* d'un Pod pour une ressource est la plus haute parmis :
|
||||
* La *limite/requête effective* d'un Pod pour une ressource est la plus haute parmis :
|
||||
* la somme de toutes les requêtes/limites des conteneurs d'application pour une ressource
|
||||
* la limite/requête d'initialisation effective pour une ressource
|
||||
* Le Scheduling est effectué sur la base des requêtes/limites effectives, ce qui signifie
|
||||
que les init containers peuvent réserver des ressources pour l'initialisation qui ne sont pas utilisées durant le
|
||||
que les init containers peuvent réserver des ressources pour l'initialisation qui ne sont pas utilisées durant le
|
||||
cycle de vie du Pod.
|
||||
* La QoS (qualité de service) tierce de la *QoS tierce effective* d'un Pod est la QoS tierce aussi bien pour les init containers
|
||||
que pour les conteneurs d'application.
|
||||
|
||||
Les quotas et limites sont appliqués sur la base de la requête/limite effective d'un Pod.
|
||||
|
||||
Les groupes de contrôle au niveau du Pod ({{< glossary_tooltip text="cgroups" term_id="cgroup" >}}) sont basés sur la requête/limite effective de Pod, la même que
|
||||
Les groupes de contrôle au niveau du Pod ({{< glossary_tooltip text="cgroups" term_id="cgroup" >}}) sont basés sur la requête/limite effective de Pod, la même que
|
||||
celle du scheduler.
|
||||
|
||||
### Raisons du redémarrage d'un Pod
|
||||
|
||||
Un Pod peut redémarrer, ce qui cause la ré-exécution des init containers, pour les raisons suivantes :
|
||||
Un Pod peut redémarrer, ce qui cause la ré-exécution des init containers, pour les raisons suivantes :
|
||||
|
||||
* Un utilisateur met à jour les spécifications du Pod, ce qui cause le changement de l'image de l'init container.
|
||||
Tout changement à l'image du init container redémarre le Pod. Les changements au conteneur d'application entraînent seulement le
|
||||
Tout changement à l'image du init container redémarre le Pod. Les changements au conteneur d'application entraînent seulement le
|
||||
redémarrage du conteneur d'application.
|
||||
* Le conteneur d'infrastructure Pod est redémarré. Ceci est peu commun et serait effectué par une personne ayant un accès root aux nœuds.
|
||||
* Tous les conteneurs dans un Pod sont terminés tandis que `restartPolicy` est configurée à "Always", ce qui force le redémarrage, et l'enregistrement de complétion du init container a été perdu à cause d'une opération de garbage collection (récupération de mémoire).
|
||||
|
||||
@@ -21,8 +21,8 @@ contenant un champ `phase`.
|
||||
|
||||
La phase d'un Pod est un résumé simple et de haut niveau de l'étape à laquelle le Pod se trouve
|
||||
dans son cycle de vie.
|
||||
La phase n'est pas faite pour être un cumul complet d'observations de l'état
|
||||
du conteneur ou du Pod, ni pour être une machine à état compréhensible.
|
||||
La phase n'est pas faite pour être un cumul complet d'observations de l'état
|
||||
du conteneur ou du Pod, ni pour être une machine à état compréhensible.
|
||||
|
||||
Le nombre et la signification des valeurs de phase d'un pod sont soigneusement gardés.
|
||||
Hormis ce qui est documenté ici, rien ne doit être supposé sur des Pods
|
||||
@@ -42,7 +42,7 @@ Valeur | Description
|
||||
|
||||
Un Pod a un PodStatus, qui contient un tableau de
|
||||
[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core)
|
||||
à travers lesquelles le Pod est ou non passé. Chaque élément
|
||||
à travers lesquelles le Pod est ou non passé. Chaque élément
|
||||
du tableau de PodCondition a six champs possibles :
|
||||
|
||||
* Le champ `lastProbeTime` fournit un timestamp auquel la condition du Pod
|
||||
@@ -61,7 +61,7 @@ du tableau de PodCondition a six champs possibles :
|
||||
* Le champ `type` est une chaîne de caractères ayant une des valeurs suivantes :
|
||||
|
||||
* `PodScheduled` : le Pod a été affecté à un nœud ;
|
||||
* `Ready` : le Pod est prêt à servir des requêtes et doit être rajouté aux équilibreurs
|
||||
* `Ready` : le Pod est prêt à servir des requêtes et doit être rajouté aux équilibreurs
|
||||
de charge de tous les Services correspondants ;
|
||||
* `Initialized` : tous les [init containers](/docs/concepts/workloads/pods/init-containers)
|
||||
ont démarré correctement ;
|
||||
@@ -75,8 +75,8 @@ du tableau de PodCondition a six champs possibles :
|
||||
|
||||
Une [Sonde](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) (Probe) est un diagnostic
|
||||
exécuté périodiquement par [kubelet](/docs/admin/kubelet/)
|
||||
sur un Conteneur. Pour exécuter un diagnostic, kubelet appelle un
|
||||
[Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) implémenté par
|
||||
sur un Conteneur. Pour exécuter un diagnostic, kubelet appelle un
|
||||
[Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) implémenté par
|
||||
le Conteneur. Il existe trois types de handlers :
|
||||
|
||||
* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
|
||||
@@ -98,7 +98,7 @@ Chaque sonde a un résultat parmi ces trois :
|
||||
* Failure: Le Conteneur a échoué au diagnostic.
|
||||
* Unknown: L'exécution du diagnostic a échoué, et donc aucune action ne peut être prise.
|
||||
|
||||
kubelet peut optionnellement exécuter et réagir à deux types de sondes sur des conteneurs
|
||||
kubelet peut optionnellement exécuter et réagir à deux types de sondes sur des conteneurs
|
||||
en cours d'exécution :
|
||||
|
||||
* `livenessProbe` : Indique si le Conteneur est en cours d'exécution. Si
|
||||
@@ -115,7 +115,7 @@ en cours d'exécution :
|
||||
|
||||
### Quand devez-vous uiliser une liveness ou une readiness probe ?
|
||||
|
||||
Si le process de votre Conteneur est capable de crasher de lui-même lorsqu'il
|
||||
Si le process de votre Conteneur est capable de crasher de lui-même lorsqu'il
|
||||
rencontre un problème ou devient inopérant, vous n'avez pas forcément besoin
|
||||
d'une liveness probe ; kubelet va automatiquement exécuter l'action correcte
|
||||
en accord avec la politique de redémarrage (`restartPolicy`) du Pod.
|
||||
@@ -125,11 +125,11 @@ spécifiez une liveness probe et indiquez une valeur pour `restartPolicy` à Alw
|
||||
ou OnFailure.
|
||||
|
||||
Si vous voulez commencer à envoyer du trafic à un Pod seulement lorsqu'une sonde
|
||||
réussit, spécifiez une readiness probe. Dans ce cas, la readiness probe peut être
|
||||
réussit, spécifiez une readiness probe. Dans ce cas, la readiness probe peut être
|
||||
la même que la liveness probe, mais l'existence de la readiness probe dans la spec
|
||||
veut dire que le Pod va démarrer sans recevoir aucun trafic et va commencer
|
||||
à recevoir du trafic après que la sonde réussisse.
|
||||
Si votre Conteneur doit charger une grande quantité de données, des fichiers de
|
||||
Si votre Conteneur doit charger une grande quantité de données, des fichiers de
|
||||
configuration ou exécuter des migrations au démarrage, spécifiez une readiness probe.
|
||||
|
||||
Si vous désirez que le Conteneur soit capable de se mettre en maintenance tout seul, vous
|
||||
@@ -137,7 +137,7 @@ pouvez spécifier une readiness probe qui vérifie un point de terminaison spéc
|
||||
readiness et différent de la liveness probe.
|
||||
|
||||
Notez que si vous voulez uniquement être capable de dérouter les requêtes lorsque
|
||||
le Pod est supprimé, vous n'avez pas forcément besoin d'une readiness probe; lors
|
||||
le Pod est supprimé, vous n'avez pas forcément besoin d'une readiness probe; lors
|
||||
de sa suppression, le Pod se met automatiquement dans un état non prêt, que la
|
||||
readiness probe existe ou non.
|
||||
Le Pod reste dans le statut non prêt le temps que les Conteneurs du Pod s'arrêtent.
|
||||
@@ -151,16 +151,16 @@ Pour des informations détaillées sur le statut d'un Pod et d'un Conteneur, voi
|
||||
[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
|
||||
et
|
||||
[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
|
||||
Notez que l'information rapportée comme statut d'un Pod dépend du
|
||||
Notez que l'information rapportée comme statut d'un Pod dépend du
|
||||
[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core) actuel.
|
||||
|
||||
## États d'un Conteneur
|
||||
|
||||
Une fois que le Pod est assigné à un nœud par le scheduler, kubelet commence
|
||||
à créer les conteneurs en utilisant le runtime de conteneurs. Il existe trois états possibles
|
||||
à créer les conteneurs en utilisant le runtime de conteneurs. Il existe trois états possibles
|
||||
pour les conteneurs : en attente (Waiting), en cours d'exécution (Running) et terminé (Terminated). Pour vérifier l'état d'un conteneur, vous pouvez utiliser `kubectl describe pod [POD_NAME]`. L'état est affiché pour chaque conteneur du Pod.
|
||||
|
||||
* `Waiting` : état du conteneur par défaut. Si le conteneur n'est pas dans un état Running ou Terminated, il est dans l'état Waiting. Un conteneur dans l'état Waiting exécute
|
||||
* `Waiting` : état du conteneur par défaut. Si le conteneur n'est pas dans un état Running ou Terminated, il est dans l'état Waiting. Un conteneur dans l'état Waiting exécute
|
||||
les opérations nécessaires, comme télécharger les images, appliquer des Secrets, etc. À côté
|
||||
de cet état, un message et une raison sur l'état sont affichés pour vous fournir plus
|
||||
d'informations.
|
||||
@@ -172,23 +172,23 @@ d'informations.
|
||||
...
|
||||
```
|
||||
|
||||
* `Running` : Indique que le conteneur s'exécute sans problème. Une fois qu'un centeneur est
|
||||
* `Running` : Indique que le conteneur s'exécute sans problème. Une fois qu'un centeneur est
|
||||
dans l'état Running, le hook `postStart` est exécuté (s'il existe). Cet état affiche aussi
|
||||
le moment auquel le conteneur est entré dans l'état Running.
|
||||
|
||||
le moment auquel le conteneur est entré dans l'état Running.
|
||||
|
||||
```yaml
|
||||
...
|
||||
State: Running
|
||||
Started: Wed, 30 Jan 2019 16:46:38 +0530
|
||||
...
|
||||
```
|
||||
```
|
||||
|
||||
* `Terminated`: Indique que le conteneur a terminé son exécution et s'est arrêté.
|
||||
Un conteneur entre dans cet état lorsqu'il s'est exécuté avec succès ou lorsqu'il a
|
||||
échoué pour une raison quelconque. De plus, une raison et un code de retour sont affichés,
|
||||
ainsi que les moments de démarrage et d'arrêt du conteneur. Avant qu'un conteneur entre
|
||||
ainsi que les moments de démarrage et d'arrêt du conteneur. Avant qu'un conteneur entre
|
||||
dans l'état Terminated, le hook `preStop` est exécuté (s'il existe).
|
||||
|
||||
|
||||
```yaml
|
||||
...
|
||||
State: Terminated
|
||||
@@ -197,18 +197,18 @@ dans l'état Terminated, le hook `preStop` est exécuté (s'il existe).
|
||||
Started: Wed, 30 Jan 2019 11:45:26 +0530
|
||||
Finished: Wed, 30 Jan 2019 11:45:26 +0530
|
||||
...
|
||||
```
|
||||
```
|
||||
|
||||
## Pod readiness gate
|
||||
|
||||
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
|
||||
|
||||
Afin d'étendre la readiness d'un Pod en autorisant l'injection de données
|
||||
supplémentaires ou des signaux dans `PodStatus`, Kubernetes 1.11 a introduit
|
||||
Afin d'étendre la readiness d'un Pod en autorisant l'injection de données
|
||||
supplémentaires ou des signaux dans `PodStatus`, Kubernetes 1.11 a introduit
|
||||
une fonctionnalité appelée [Pod ready++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md).
|
||||
Vous pouvez utiliser le nouveau champ `ReadinessGate` dans `PodSpec`
|
||||
Vous pouvez utiliser le nouveau champ `ReadinessGate` dans `PodSpec`
|
||||
pour spécifier des conditions additionnelles à évaluer pour la readiness d'un Pod.
|
||||
Si Kubernetes ne peut pas trouver une telle condition dans le champ `status.conditions`
|
||||
Si Kubernetes ne peut pas trouver une telle condition dans le champ `status.conditions`
|
||||
d'un Pod, le statut de la condition est "`False`" par défaut. Voici un exemple :
|
||||
|
||||
```yaml
|
||||
@@ -244,11 +244,11 @@ Avec l'introduction de nouvelles conditions d'un Pod, un Pod est considéré com
|
||||
* Tous les conteneurs du Pod sont prêts.
|
||||
* Toutes les conditions spécifiées dans `ReadinessGates` sont à "`True`".
|
||||
|
||||
Pour faciliter le changement de l'évaluation de la readiness d'un Pod,
|
||||
Pour faciliter le changement de l'évaluation de la readiness d'un Pod,
|
||||
une nouvelle condition de Pod `ContainersReady` est introduite pour capturer
|
||||
l'ancienne condition `Ready` d'un Pod.
|
||||
|
||||
Avec K8s 1.11, en tant que fonctionnalité alpha, "Pod Ready++" doit être explicitement activé en mettant la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `PodReadinessGates`
|
||||
Avec K8s 1.11, en tant que fonctionnalité alpha, "Pod Ready++" doit être explicitement activé en mettant la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `PodReadinessGates`
|
||||
à true.
|
||||
|
||||
Avec K8s 1.12, la fonctionnalité est activée par défaut.
|
||||
@@ -280,7 +280,7 @@ Pods qui doivent se terminer, par exemple des calculs par batch. Les Jobs sont a
|
||||
seulement pour des Pods ayant `restartPolicy` égal à OnFailure ou Never.
|
||||
|
||||
- Utilisez un [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/),
|
||||
[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) ou
|
||||
[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) ou
|
||||
[Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
pour des Pods qui ne doivent pas s'arrêter, par exemple des serveurs web.
|
||||
ReplicationControllers sont appropriés pour des Pods ayant `restartPolicy` égal à
|
||||
@@ -302,8 +302,8 @@ une politique pour mettre la `phase` de tous les Pods du nœud perdu à Failed.
|
||||
|
||||
### Exemple avancé de liveness probe
|
||||
|
||||
Les Liveness probes sont exécutées par kubelet, toutes les requêtes sont donc faites
|
||||
dans l'espace réseau de kubelet.
|
||||
Les Liveness probes sont exécutées par kubelet, toutes les requêtes sont donc faites
|
||||
dans l'espace réseau de kubelet.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Aperçu du Pod
|
||||
description: Pod Concept Kubernetes
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
card:
|
||||
card:
|
||||
name: concepts
|
||||
weight: 60
|
||||
---
|
||||
@@ -76,7 +76,7 @@ En général, les Controllers utilisent des Templates de Pod que vous lui fourni
|
||||
|
||||
## Templates de Pod
|
||||
|
||||
Les Templates de Pod sont des spécifications de pod qui sont inclus dans d'autres objets, comme les
|
||||
Les Templates de Pod sont des spécifications de pod qui sont inclus dans d'autres objets, comme les
|
||||
[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), et
|
||||
[DaemonSets](/docs/concepts/workloads/controllers/daemonset/). Les Controllers utilisent les Templates de Pod pour créer réellement les pods.
|
||||
L'exemple ci-dessous est un manifeste simple pour un Pod d'un conteneur affichant un message.
|
||||
|
||||
@@ -17,12 +17,12 @@ qui peuvent être créées et gérées dans Kubernetes.
|
||||
|
||||
## Qu'est-ce qu'un pod ?
|
||||
|
||||
Un _pod_ (terme anglo-saxon décrivant un groupe de baleines ou une gousse de pois) est un groupe d'un ou plusieurs conteneurs
|
||||
(comme des conteneurs Docker), ayant du stockage/réseau partagé, et une spécification
|
||||
Un _pod_ (terme anglo-saxon décrivant un groupe de baleines ou une gousse de pois) est un groupe d'un ou plusieurs conteneurs
|
||||
(comme des conteneurs Docker), ayant du stockage/réseau partagé, et une spécification
|
||||
sur la manière d'exécuter ces conteneurs. Les éléments d'un pod sont toujours co-localisés
|
||||
et co-ordonnancés, et s'exécutent dans un contexte partagé. Un pod modélise un
|
||||
"hôte logique" spécifique à une application - il contient un ou plusieurs conteneurs applicatifs
|
||||
qui sont étroitement liés — dans un monde pré-conteneurs, être exécuté sur la même machine
|
||||
qui sont étroitement liés — dans un monde pré-conteneurs, être exécuté sur la même machine
|
||||
physique ou virtuelle signifierait être exécuté sur le même hôte logique.
|
||||
|
||||
Bien que Kubernetes prenne en charge d'autres runtimes de conteneurs que Docker, Docker est le runtime
|
||||
@@ -32,12 +32,12 @@ Le contexte partagé d'un pod est un ensemble de namespaces Linux, cgroups, et
|
||||
potentiellement d'autres facettes d'isolation - les mêmes choses qui isolent un conteneur Docker.
|
||||
Dans le contexte d'un pod, les applications individuelles peuvent se voir appliquer d'autres sous-isolations.
|
||||
|
||||
Les conteneurs d'un pod partagent une adresse IP et un espace de ports, et peuvent communiquer via `localhost`.
|
||||
Les conteneurs d'un pod partagent une adresse IP et un espace de ports, et peuvent communiquer via `localhost`.
|
||||
Ils peuvent aussi communiquer entre eux en utilisant des communications inter-process standard comme
|
||||
les sémaphores SystemV ou la mémoire partagée POSIX. Les conteneurs appartenant à des pods distincts ont des adresses IP
|
||||
distinctes et ne peuvent pas communiquer par IPC sans [configuration spécifique](/docs/concepts/policy/pod-security-policy/). Ces conteneurs communiquent en général entre eux via les adresses IP de leurs pods.
|
||||
|
||||
Les applications à l'intérieur d'un pod ont aussi accès à des volumes partagés,
|
||||
Les applications à l'intérieur d'un pod ont aussi accès à des volumes partagés,
|
||||
qui sont définis dans le cadre d'un pod et sont mis à disposition pour être montés
|
||||
dans le système de fichiers de chaque application.
|
||||
|
||||
@@ -66,11 +66,11 @@ utilisant un volume persistant comme espace de stockage partagé entre les conte
|
||||
### Gestion
|
||||
|
||||
Les pods fournissent une unité de service cohérente afin d'avoir un modèle coopératif entre plusieurs processus.
|
||||
Ils simplifient le déploiement et la gestion d'applications
|
||||
Ils simplifient le déploiement et la gestion d'applications
|
||||
en fournissant une abstraction de plus haut niveau que l'ensemble des applications les constituant.
|
||||
Les pods servent d'unité de déploiement, de mise à l'échelle horizontale, et de réplication.
|
||||
La co-localisation (co-ordonnancement), la fin partagée (par ex. l'arrêt),
|
||||
la réplication coordonnée, le partage de ressources et la gestion des dépendances sont
|
||||
La co-localisation (co-ordonnancement), la fin partagée (par ex. l'arrêt),
|
||||
la réplication coordonnée, le partage de ressources et la gestion des dépendances sont
|
||||
traités automatiquement pour les conteneurs dans un pod.
|
||||
|
||||
### Partage de ressources et communication
|
||||
@@ -80,14 +80,14 @@ Les pods permettent le partage de ressources et la communication entre ses const
|
||||
Les applications dans un pod utilisent toutes le même réseau (même adresse IP et espace de ports)
|
||||
et peuvent donc "se trouver" entre elles et communiquer en utilisant `localhost`.
|
||||
À cause de cela, les applications dans un pod doivent coordonner leurs usages de ports.
|
||||
Chaque pod a une adresse IP dans un réseau plat partagé ayant un accès complet
|
||||
Chaque pod a une adresse IP dans un réseau plat partagé ayant un accès complet
|
||||
aux autres hôtes et pods à travers le réseau.
|
||||
|
||||
Le nom d'hôte est défini avec le nom du pod pour les conteneurs applicatifs à l'intérieur du pod.
|
||||
[Plus de détails sur le réseau](/docs/concepts/cluster-administration/networking/).
|
||||
|
||||
En plus de définir les conteneurs applicatifs s'exécutant dans le pod, le pod spécifie
|
||||
un ensemble de volumes de stockage partagés. Les volumes permettent aux données de survivre
|
||||
En plus de définir les conteneurs applicatifs s'exécutant dans le pod, le pod spécifie
|
||||
un ensemble de volumes de stockage partagés. Les volumes permettent aux données de survivre
|
||||
aux redémarrages de conteneurs et d'être partagés entre les applications d'un même pod.
|
||||
|
||||
## Cas d'utilisation de pods
|
||||
@@ -112,8 +112,8 @@ Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-pa
|
||||
_Pourquoi ne pas simplement exécuter plusieurs programmes dans un unique conteneur (Docker) ?_
|
||||
|
||||
1. Transparence. Rendre les conteneurs à l'intérieur du pod visibles par l'infrastucture
|
||||
permet à l'infrastucture de fournir des services à ces conteneurs,
|
||||
comme la gestion des processus et le monitoring des ressources. Ceci
|
||||
permet à l'infrastucture de fournir des services à ces conteneurs,
|
||||
comme la gestion des processus et le monitoring des ressources. Ceci
|
||||
apporte un certain nombre de facilités aux utilisateurs.
|
||||
1. Découpler les dépendances logicielles. Les conteneurs individuels peuvent être
|
||||
versionnés, reconstruits et redéployés de manière indépendante. Kubernetes pourrait
|
||||
@@ -124,7 +124,7 @@ _Pourquoi ne pas simplement exécuter plusieurs programmes dans un unique conten
|
||||
|
||||
_Pourquoi ne pas prendre en charge le co-ordonnancement de conteneurs basé sur les affinités ?_
|
||||
|
||||
Cette approche pourrait fournir la co-localisation, mais ne fournirait pas la plupart
|
||||
Cette approche pourrait fournir la co-localisation, mais ne fournirait pas la plupart
|
||||
des bénéfices des pods, comme le partage de ressources, IPC, la garantie d'une fin partagée et une gestion simplifiée.
|
||||
|
||||
## Durabilité des pods (ou manque de)
|
||||
@@ -132,7 +132,7 @@ des bénéfices des pods, comme le partage de ressources, IPC, la garantie d'une
|
||||
Les pods ne doivent pas être considérés comme des entités durables. Ils ne survivent pas à des erreurs d'ordonnancement, à un nœud en échec
|
||||
ou à d'autres expulsions, suite à un manque de ressources ou une mise en maintenance d'un nœud.
|
||||
|
||||
En général, les utilisateurs n'ont pas à créer directement des pods. Ils doivent presque toujours
|
||||
En général, les utilisateurs n'ont pas à créer directement des pods. Ils doivent presque toujours
|
||||
utiliser des contrôleurs, même pour des singletons, comme par exemple des [Deployments](/docs/concepts/workloads/controllers/deployment/).
|
||||
Les contrôleurs fournissent l'auto-guérison à l'échelle du cluster, ainsi que la réplication et la gestion des déploiements (rollout).
|
||||
Les contrôleurs comme [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)
|
||||
@@ -152,7 +152,7 @@ Un Pod est exposé en tant que primitive afin de faciliter :
|
||||
## Arrêt de pods
|
||||
|
||||
Les pods représentant des processus s'exécutant sur des nœuds d'un cluster, il est important de permettre à ces processus de se terminer proprement
|
||||
lorsqu'ils ne sont plus nécessaires (plutôt que d'être violemment tués avec un signal KILL et n'avoir aucune chance de libérer ses ressources). Les
|
||||
lorsqu'ils ne sont plus nécessaires (plutôt que d'être violemment tués avec un signal KILL et n'avoir aucune chance de libérer ses ressources). Les
|
||||
utilisateurs doivent pouvoir demander une suppression et savoir quand les processus se terminent, mais aussi être capable de s'assurer que la suppression
|
||||
est réellement effective. Lorsqu'un utilisateur demande la suppression d'un pod, le système enregistre le délai de grâce prévu avant que le pod puisse
|
||||
être tué de force, et qu'un signal TERM soit envoyé au processus principal de chaque conteneur. Une fois la période de grâce expirée, le signal KILL
|
||||
|
||||
Reference in New Issue
Block a user