FR localization: replaced {{< codenew ... >}} with {{% codenew ... %}} in all files
Andrey Goran
parent
ff6d646409
commit
bf5eda7d3c
|
|
@ -50,7 +50,7 @@ d'évènements avec le flux de sortie standard. Cette démonstration utilise un
|
|||
manifeste pour un Pod avec un seul conteneur qui écrit du texte sur le flux
|
||||
de sortie standard toutes les secondes.
|
||||
|
||||
{{< codenew file="debug/counter-pod.yaml" >}}
|
||||
{{% codenew file="debug/counter-pod.yaml" %}}
|
||||
|
||||
Pour lancer ce Pod, utilisez la commande suivante :
|
||||
|
||||
|
|
@ -243,7 +243,7 @@ Un Pod exécute un unique conteneur et ce conteneur écrit dans deux fichiers de
|
|||
journaux différents en utilisant deux format différents. Voici le manifeste du
|
||||
Pod :
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
|
||||
{{% codenew file="admin/logging/two-files-counter-pod.yaml" %}}
|
||||
|
||||
Il serait très désordonné d'avoir des évènements avec des formats différents
|
||||
dans le même journal en redirigeant les évènements dans le flux de sortie
|
||||
|
|
@ -253,8 +253,7 @@ suit un des fichiers et renvoie les évènements sur son propre `stdout`.
|
|||
|
||||
Ci-dessous se trouve le manifeste pour un Pod avec deux conteneurs side-car.
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml"
|
||||
>}}
|
||||
{{% codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" %}}
|
||||
|
||||
Quand ce Pod s'exécute, chaque journal peut être diffusé séparément en
|
||||
utilisant les commandes suivantes :
|
||||
|
|
@ -323,7 +322,7 @@ Le premier fichier contient un
|
|||
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) pour
|
||||
configurer fluentd.
|
||||
|
||||
{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
|
||||
{{% codenew file="admin/logging/fluentd-sidecar-config.yaml" %}}
|
||||
|
||||
{{< note >}}
|
||||
La configuration de fluentd est hors du cadre de cet article. Vous trouverez
|
||||
|
|
@ -335,7 +334,7 @@ Le second fichier est un manifeste pour un Pod avec un conteneur side-car qui
|
|||
exécute fluentd. Le Pod monte un volume où fluentd peut récupérer sa
|
||||
configuration.
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}
|
||||
{{% codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" %}}
|
||||
|
||||
Apres quelques minutes, les évènements apparaîtront dans l'interface de
|
||||
Stackdriver.
|
||||
|
|
|
|||
|
|
@ -330,7 +330,7 @@ type: kubernetes.io/tls
|
|||
|
||||
Référencer ce secret dans un Ingress indiquera au contrôleur d'Ingress de sécuriser le canal du client au load-balancer à l'aide de TLS. Vous devez vous assurer que le secret TLS que vous avez créé provenait d'un certificat contenant un Common Name (CN), aussi appelé nom de domaine pleinement qualifié (FQDN), pour `https-example.foo.com`.
|
||||
|
||||
{{< codenew file="service/networking/tls-example-ingress.yaml" >}}
|
||||
{{% codenew file="service/networking/tls-example-ingress.yaml" %}}
|
||||
|
||||
|
||||
{{< note >}}
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ Voici des cas d'utilisation typiques pour les déploiements:
|
|||
Voici un exemple de déploiement.
|
||||
Il crée un ReplicaSet pour faire apparaître trois pods `nginx`:
|
||||
|
||||
{{< codenew file="controllers/nginx-deployment.yaml" >}}
|
||||
{{% codenew file="controllers/nginx-deployment.yaml" %}}
|
||||
|
||||
Dans cet exemple:
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ utilisez plutôt un déploiement et définissez votre application dans la sectio
|
|||
|
||||
## Exemple
|
||||
|
||||
{{< codenew file="controllers/frontend.yaml" >}}
|
||||
{{% codenew file="controllers/frontend.yaml" %}}
|
||||
|
||||
Enregistrer ce manifeste dans `frontend.yaml` et le soumettre à un cluster Kubernetes va créer le ReplicaSet défini et les pods qu’il gère.
|
||||
|
||||
|
|
@ -145,7 +145,7 @@ labels correspondant au sélecteur de l’un de vos ReplicaSets. Car un ReplicaS
|
|||
|
||||
Prenez l'exemple précédent de ReplicaSet, ainsi que les pods spécifiés dans le manifeste suivant :
|
||||
|
||||
{{< codenew file="pods/pod-rs.yaml" >}}
|
||||
{{% codenew file="pods/pod-rs.yaml" %}}
|
||||
|
||||
Ces pods n’ayant pas de contrôleur (ni d’objet) en tant que référence propriétaire, ils correspondent au sélecteur de du ReplicaSet frontend, ils seront donc immédiatement acquis par ce ReplicaSet.
|
||||
|
||||
|
|
@ -291,7 +291,7 @@ Un ReplicaSet peut également être une cible pour
|
|||
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.
|
||||
|
||||
{{< codenew file="controllers/hpa-rs.yaml" >}}
|
||||
{{% codenew file="controllers/hpa-rs.yaml" %}}
|
||||
|
||||
Enregistrer ce manifeste dans `hpa-rs.yaml` et le soumettre à un cluster Kubernetes devrait
|
||||
créer le HPA défini qui scale automatiquement le ReplicaSet cible en fonction de l'utilisation du processeur
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ Supposons que vous ayez un cluster de 4 noeuds où 3 Pods étiquettés `foo:bar`
|
|||
|
||||
Si nous voulons qu'un nouveau Pod soit uniformément réparti avec les Pods existants à travers les zones, la spec peut être :
|
||||
|
||||
{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}}
|
||||
{{% codenew file="pods/topology-spread-constraints/one-constraint.yaml" %}}
|
||||
|
||||
`topologyKey: zone` implique que la distribution uniforme sera uniquement appliquée pour les noeuds ayant le label "zone:<any value>" présent. `whenUnsatisfiable: DoNotSchedule` indique au scheduler de laisser le Pod dans l'état Pending si le Pod entrant ne peut pas satisfaire la contrainte.
|
||||
|
||||
|
|
@ -133,7 +133,7 @@ Cela s'appuie sur l'exemple précédent. Supposons que vous ayez un cluster de 4
|
|||
|
||||
Vous pouvez utiliser 2 TopologySpreadConstraints pour contrôler la répartition des Pods aussi bien dans les zones que dans les noeuds :
|
||||
|
||||
{{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}}
|
||||
{{% codenew file="pods/topology-spread-constraints/two-constraints.yaml" %}}
|
||||
|
||||
Dans ce cas, pour satisfaire la première contrainte, le Pod entrant peut uniquement être placé dans "zoneB" ; alors que pour satisfaire la seconde contrainte, le Pod entrant peut uniquement être placé dans "node4". Le résultat étant l'intersection des résultats des 2 contraintes, l'unique option possible est de placer le Pod entrant dans "node4".
|
||||
|
||||
|
|
@ -182,7 +182,7 @@ Il existe quelques conventions implicites qu'il est intéressant de noter ici :
|
|||
|
||||
et vous savez que "zoneC" doit être exclue. Dans ce cas, vous pouvez écrire le yaml ci-dessous, pour que "mypod" soit placé dans "zoneB" plutôt que dans "zoneC". `spec.nodeSelector` est pris en compte de la même manière.
|
||||
|
||||
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
|
||||
{{% codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" %}}
|
||||
|
||||
### Contraintes par défaut au niveau du cluster
|
||||
|
||||
|
|
|
|||
|
|
@ -108,13 +108,14 @@ Utilisez cette méthode pour inclure des exemples de fichiers YAML lorsque l'éc
|
|||
Lors de l'ajout d'un nouveau fichier d'exemple autonome, tel qu'un fichier YAML, placez le code dans l'un des sous-répertoires `<LANG>/examples/` où `<LANG>` est la langue utilisé dans votre page.
|
||||
Dans votre fichier, utilisez le shortcode `codenew` :
|
||||
|
||||
<pre>{{< codenew file="<RELPATH>/my-example-yaml>" >}}</pre>
|
||||
|
||||
```none
|
||||
{{%/* codenew file="<RELPATH>/my-example-yaml>" */%}}
|
||||
```
|
||||
où `<RELPATH>` est le chemin vers le fichier à inclure, relatif au répertoire `examples`.
|
||||
Le shortcode Hugo suivant fait référence à un fichier YAML situé sur `/content/en/examples/pods/storage/gce-volume.yaml`.
|
||||
|
||||
```none
|
||||
{{</* codenew file="pods/storage/gce-volume.yaml" */>}}
|
||||
{{%/* codenew file="pods/storage/gce-volume.yaml" */%}}
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
|
|
|||
|
|
@ -1228,7 +1228,7 @@ comprend des recommandations pour restreindre cet accès dans les clusters exist
|
|||
Si vous souhaitez que les nouveaux clusters conservent ce niveau d'accès dans les rôles agrégés,
|
||||
vous pouvez créer le ClusterRole suivant :
|
||||
|
||||
{{< codenew file="access/endpoints-aggregated.yaml" >}}
|
||||
{{% codenew file="access/endpoints-aggregated.yaml" %}}
|
||||
|
||||
## Mise à niveau à partir d'ABAC
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ Si votre environnement ne prend pas en charge cette fonction, vous pouvez utilis
|
|||
Le backend est un simple microservice de salutations.
|
||||
Voici le fichier de configuration pour le Deployment backend :
|
||||
|
||||
{{< codenew file="service/access/backend-deployment.yaml" >}}
|
||||
{{% codenew file="service/access/backend-deployment.yaml" %}}
|
||||
|
||||
Créez le Deployment backend :
|
||||
|
||||
|
|
@ -91,7 +91,7 @@ Un Service utilise des {{< glossary_tooltip text="sélecteurs" term_id="selector
|
|||
|
||||
Tout d'abord, explorez le fichier de configuration du Service :
|
||||
|
||||
{{< codenew file="service/access/backend-service.yaml" >}}
|
||||
{{% codenew file="service/access/backend-service.yaml" %}}
|
||||
|
||||
Dans le fichier de configuration, vous pouvez voir que le Service,
|
||||
nommé `hello`, achemine le trafic vers les Pods ayant les labels `app: hello` et `tier: backend`.
|
||||
|
|
@ -120,16 +120,16 @@ Les Pods du frontend Deployment exécutent une image nginx
|
|||
configurée pour acheminer les requêtes vers le Service backend `hello`.
|
||||
Voici le fichier de configuration nginx :
|
||||
|
||||
{{< codenew file="service/access/frontend-nginx.conf" >}}
|
||||
{{% codenew file="service/access/frontend-nginx.conf" %}}
|
||||
|
||||
Comme pour le backend, le frontend dispose d'un Deployment et d'un Service.
|
||||
Une différence importante à noter entre les services backend et frontend est que
|
||||
le Service frontend est configuré avec un `type: LoadBalancer`, ce qui signifie que le Service utilise
|
||||
un équilibreur de charge provisionné par votre fournisseur de cloud et sera accessible depuis l'extérieur du cluster.
|
||||
|
||||
{{< codenew file="service/access/frontend-service.yaml" >}}
|
||||
{{% codenew file="service/access/frontend-service.yaml" %}}
|
||||
|
||||
{{< codenew file="service/access/frontend-deployment.yaml" >}}
|
||||
{{% codenew file="service/access/frontend-deployment.yaml" %}}
|
||||
|
||||
Créez le Deployment et le Service frontend :
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ ayant deux instances en cours d'exécution.
|
|||
|
||||
Voici le fichier de configuration pour le déploiement de l'application :
|
||||
|
||||
{{< codenew file="service/access/hello-application.yaml" >}}
|
||||
{{% codenew file="service/access/hello-application.yaml" %}}
|
||||
|
||||
1. Exécutez une application Hello World dans votre cluster :
|
||||
Créez le déploiement de l'application en utilisant le fichier ci-dessus :
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ Pour les cloud-controller-manager ne faisant pas partie de Kubernetes, vous pouv
|
|||
Pour les fournisseurs qui se trouvent déjà dans Kubernetes, vous pouvez exécuter le cloud-controller-manager dans l'arborescence en tant que Daemonset dans votre cluster.
|
||||
Utilisez ce qui suit comme guide:
|
||||
|
||||
{{< codenew file="admin/cloud/ccm-example.yaml" >}}
|
||||
{{% codenew file="admin/cloud/ccm-example.yaml" %}}
|
||||
|
||||
## Limitations
|
||||
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ dans le manifeste des ressources du conteneur. Pour spécifier une limite de CPU
|
|||
|
||||
Dans cet exercice, vous allez créer un Pod qui a un seul conteneur. Le conteneur a une demande de 0.5 CPU et une limite de 1 CPU. Voici le fichier de configuration du Pod :
|
||||
|
||||
{{< codenew file="pods/resource/cpu-request-limit.yaml" >}}
|
||||
{{% codenew file="pods/resource/cpu-request-limit.yaml" %}}
|
||||
|
||||
La section `args` du fichier de configuration fournit des arguments pour le conteneur lorsqu'il démarre. L'argument `-cpus "2"` demande au conteneur d'utiliser 2 CPUs.
|
||||
|
||||
|
|
@ -147,7 +147,7 @@ L'ordonnancement des pods est basé sur les demandes. Un Pod est prévu pour se
|
|||
Dans cet exercice, vous allez créer un Pod qui a une demande de CPU si importante qu'elle dépassera la capacité de n'importe quel nœud de votre cluster. Voici le fichier de configuration d'un Pod
|
||||
qui a un seul conteneur. Le conteneur nécessite 100 CPU, ce qui est susceptible de dépasser la capacité de tous les nœuds de votre cluster.
|
||||
|
||||
{{< codenew file="pods/resource/cpu-request-limit-2.yaml" >}}
|
||||
{{% codenew file="pods/resource/cpu-request-limit-2.yaml" %}}
|
||||
|
||||
Créez le Pod :
|
||||
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ dans le manifeste des ressources du conteneur. Pour spécifier une limite de mé
|
|||
Dans cet exercice, vous créez un pod qui possède un seul conteneur. Le conteneur dispose d'une demande de mémoire de 100 MiB et une limite de mémoire de 200 MiB. Voici le fichier de configuration
|
||||
pour le Pod :
|
||||
|
||||
{{< codenew file="pods/resource/memory-request-limit.yaml" >}}
|
||||
{{% codenew file="pods/resource/memory-request-limit.yaml" %}}
|
||||
|
||||
La section `args` de votre fichier de configuration fournit des arguments pour le conteneur lorsqu'il démarre.
|
||||
Les arguments `"--vm-bytes", "150M"` indiquent au conteneur d'allouer 150 MiB de mémoire.
|
||||
|
|
@ -123,7 +123,7 @@ Si un conteneur terminé peut être redémarré, le kubelet le redémarre, comme
|
|||
Dans cet exercice, vous créez un Pod qui tente d'allouer plus de mémoire que sa limite.
|
||||
Voici le fichier de configuration d'un Pod qui contient un conteneur avec une demande de mémoire de 50 MiB et une limite de mémoire de 100 MiB :
|
||||
|
||||
{{< codenew file="pods/resource/memory-request-limit-2.yaml" >}}
|
||||
{{% codenew file="pods/resource/memory-request-limit-2.yaml" %}}
|
||||
|
||||
Dans la section `args` du fichier de configuration, vous pouvez voir que le conteneur
|
||||
tentera d'allouer 250 MiB de mémoire, ce qui est bien au-dessus de la limite de 100 MiB.
|
||||
|
|
@ -226,7 +226,7 @@ L'ordonnancement des modules est basé sur les demandes. Un Pod est schedulé po
|
|||
|
||||
Dans cet exercice, vous allez créer un Pod dont la demande de mémoire est si importante qu'elle dépasse la capacité de la mémoire de n'importe quel nœud de votre cluster. Voici le fichier de configuration d'un Pod qui possède un seul conteneur avec une demande de 1000 GiB de mémoire, qui dépasse probablement la capacité de tous les nœuds de votre cluster.
|
||||
|
||||
{{< codenew file="pods/resource/memory-request-limit-3.yaml" >}}
|
||||
{{% codenew file="pods/resource/memory-request-limit-3.yaml" %}}
|
||||
|
||||
Créez le Pod :
|
||||
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ Cette page montre comment assigner un Pod à un nœud particulier dans un cluste
|
|||
|
||||
Le fichier de configuration de pod décrit un pod qui possède un selector de nœud de type `disktype:ssd`. Cela signifie que le pod sera planifié sur un nœud ayant le label `disktype=ssd`.
|
||||
|
||||
{{< codenew file="pods/pod-nginx.yaml" >}}
|
||||
{{% codenew file="pods/pod-nginx.yaml" %}}
|
||||
|
||||
1. Utilisez le fichier de configuration pour créer un pod qui sera ordonnancé sur votre nœud choisi :
|
||||
|
||||
|
|
@ -86,7 +86,7 @@ Le fichier de configuration de pod décrit un pod qui possède un selector de n
|
|||
|
||||
Vous pouvez également ordonnancer un pod sur un nœud spécifique via le paramètre `nodeName`.
|
||||
|
||||
{{< codenew file="pods/pod-nginx-specific-node.yaml" >}}
|
||||
{{% codenew file="pods/pod-nginx-specific-node.yaml" %}}
|
||||
|
||||
Utilisez le fichier de configuration pour créer un pod qui sera ordonnancé sur `foo-node` uniquement.
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ De nombreuses applications fonctionnant pour des longues périodes finissent par
|
|||
|
||||
Dans cet exercice, vous allez créer un Pod qui exécute un conteneur basé sur l'image `registry.k8s.io/busybox`. Voici le fichier de configuration pour le Pod :
|
||||
|
||||
{{< codenew file="pods/probe/exec-liveness.yaml" >}}
|
||||
{{% codenew file="pods/probe/exec-liveness.yaml" %}}
|
||||
|
||||
Dans le fichier de configuration, vous constatez que le Pod a un seul conteneur.
|
||||
Le champ `periodSeconds` spécifie que le Kubelet doit effectuer un check de liveness toutes les 5 secondes. Le champ `initialDelaySeconds` indique au Kubelet qu'il devrait attendre 5 secondes avant d'effectuer la première probe. Pour effectuer une probe, le Kubelet exécute la commande `cat /tmp/healthy` dans le conteneur. Si la commande réussit, elle renvoie 0, et le Kubelet considère que le conteneur est vivant et en bonne santé. Si la commande renvoie une valeur non nulle, le Kubelet tue le conteneur et le redémarre.
|
||||
|
|
@ -104,7 +104,7 @@ liveness-exec 1/1 Running 1 1m
|
|||
Un autre type de liveness probe utilise une requête GET HTTP. Voici la configuration
|
||||
d'un Pod qui fait fonctionner un conteneur basé sur l'image `registry.k8s.io/liveness`.
|
||||
|
||||
{{< codenew file="pods/probe/http-liveness.yaml" >}}
|
||||
{{% codenew file="pods/probe/http-liveness.yaml" %}}
|
||||
|
||||
Dans le fichier de configuration, vous pouvez voir que le Pod a un seul conteneur.
|
||||
Le champ `periodSeconds` spécifie que le Kubelet doit effectuer une liveness probe toutes les 3 secondes. Le champ `initialDelaySeconds` indique au Kubelet qu'il devrait attendre 3 secondes avant d'effectuer la première probe. Pour effectuer une probe, le Kubelet envoie une requête HTTP GET au serveur qui s'exécute dans le conteneur et écoute sur le port 8080. Si le handler du chemin `/healthz` du serveur renvoie un code de succès, le Kubelet considère que le conteneur est vivant et en bonne santé. Si le handler renvoie un code d'erreur, le Kubelet tue le conteneur et le redémarre.
|
||||
|
|
@ -152,7 +152,7 @@ Dans les versions postérieures à la v1.13, les paramètres de la variable d'en
|
|||
Un troisième type de liveness probe utilise un TCP Socket. Avec cette configuration, le Kubelet tentera d'ouvrir un socket vers votre conteneur sur le port spécifié.
|
||||
S'il arrive à établir une connexion, le conteneur est considéré comme étant en bonne santé, s'il n'y arrive pas, c'est un échec.
|
||||
|
||||
{{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}}
|
||||
{{% codenew file="pods/probe/tcp-liveness-readiness.yaml" %}}
|
||||
|
||||
Comme vous le voyez, la configuration pour un check TCP est assez similaire à un check HTTP.
|
||||
Cet exemple utilise à la fois des readiness et liveness probes. Le Kubelet transmettra la première readiness probe 5 secondes après le démarrage du conteneur. Il tentera de se connecter au conteneur `goproxy` sur le port 8080. Si la probe réussit, le conteneur sera marqué comme prêt. Kubelet continuera à effectuer ce check tous les 10 secondes.
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ pour paramétrer du
|
|||
[provisioning dynamique](/docs/concepts/storage/dynamic-provisioning/).
|
||||
|
||||
Voici le fichier de configuration pour le PersistentVolume de type hostPath:
|
||||
{{< codenew file="pods/storage/pv-volume.yaml" >}}
|
||||
{{% codenew file="pods/storage/pv-volume.yaml" %}}
|
||||
|
||||
Le fichier de configuration spécifie que le chemin du volume sur le noeud est `/mnt/data`. Il spécifie aussi une taille de 10 gibibytes, ainsi qu'un mode d'accès de type `ReadWriteOnce`, impliquant que le volume ne peut être monté en lecture et écriture que par un seul noeud. Le fichier définit un [nom de StorageClass](/docs/concepts/storage/persistent-volumes/#class) à `manual`, ce qui sera utilisé pour attacher un PersistentVolumeClaim à ce PersistentVolume
|
||||
|
||||
|
|
@ -103,7 +103,7 @@ La prochaine étape est de créer un PersistentVolumeClaim (demande de stockage)
|
|||
Dans cet exercice, vous créez un PersistentVolumeClaim qui demande un volume d'au moins 3 GB, et qui peut être monté en lecture et écriture sur au moins un noeud.
|
||||
|
||||
Voici le fichier de configuration du PersistentVolumeClaim:
|
||||
{{< codenew file="pods/storage/pv-claim.yaml" >}}
|
||||
{{% codenew file="pods/storage/pv-claim.yaml" %}}
|
||||
|
||||
Créez le PersistentVolumeClaim:
|
||||
|
||||
|
|
@ -137,7 +137,7 @@ La prochaine étape est de créer un Pod qui utilise le PersistentVolumeClaim co
|
|||
|
||||
Voici le fichier de configuration du Pod:
|
||||
|
||||
{{< codenew file="pods/storage/pv-pod.yaml" >}}
|
||||
{{% codenew file="pods/storage/pv-pod.yaml" %}}
|
||||
|
||||
Notez que le fichier de configuration du Pod spécifie un PersistentVolumeClaim et non un PersistentVolume. Du point de vue du Pod, la demande est un volume de stockage.
|
||||
|
||||
|
|
@ -200,7 +200,7 @@ Vous pouvez maintenant arrêter la session shell vers votre noeud.
|
|||
Vous pouvez monter plusieurs fois un même PersistentVolume
|
||||
à plusieurs endroits différents dans votre container nginx:
|
||||
|
||||
{{< codenew file="pods/storage/pv-duplicate.yaml" >}}
|
||||
{{% codenew file="pods/storage/pv-duplicate.yaml" %}}
|
||||
|
||||
- `/usr/share/nginx/html` pour le site statique
|
||||
- `/etc/nginx/nginx.conf` pour la configuration par défaut
|
||||
|
|
|
|||
|
|
@ -453,7 +453,7 @@ configmap/special-config-2-c92b5mmcf2 created
|
|||
|
||||
1. Attribuez la valeur `special.how` défini dans ConfigMap à la variable d'environnement `SPECIAL_LEVEL_KEY` dans la spécification du Pod.
|
||||
|
||||
{{< codenew file="pods/pod-single-configmap-env-variable.yaml" >}}
|
||||
{{% codenew file="pods/pod-single-configmap-env-variable.yaml" %}}
|
||||
|
||||
Créez le pod:
|
||||
|
||||
|
|
@ -467,7 +467,7 @@ configmap/special-config-2-c92b5mmcf2 created
|
|||
|
||||
* Comme avec l'exemple précédent, créez d'abord les ConfigMaps.
|
||||
|
||||
{{< codenew file="configmap/configmaps.yaml" >}}
|
||||
{{% codenew file="configmap/configmaps.yaml" %}}
|
||||
|
||||
Créez le ConfigMap:
|
||||
|
||||
|
|
@ -477,7 +477,7 @@ configmap/special-config-2-c92b5mmcf2 created
|
|||
|
||||
* Définissez les variables d'environnement dans la spécification Pod.
|
||||
|
||||
{{< codenew file="pods/pod-multiple-configmap-env-variable.yaml" >}}
|
||||
{{% codenew file="pods/pod-multiple-configmap-env-variable.yaml" %}}
|
||||
|
||||
Créez le pod:
|
||||
|
||||
|
|
@ -495,7 +495,7 @@ Cette fonctionnalité est disponible dans Kubernetes v1.6 et versions ultérieur
|
|||
|
||||
* Créez un ConfigMap contenant plusieurs paires clé-valeur.
|
||||
|
||||
{{< codenew file="configmap/configmap-multikeys.yaml" >}}
|
||||
{{% codenew file="configmap/configmap-multikeys.yaml" %}}
|
||||
|
||||
Créez le ConfigMap:
|
||||
|
||||
|
|
@ -506,7 +506,7 @@ Cette fonctionnalité est disponible dans Kubernetes v1.6 et versions ultérieur
|
|||
* Utilisez `envFrom` pour définir toutes les données du ConfigMap en tant que variables d'environnement du conteneur.
|
||||
La clé de ConfigMap devient le nom de la variable d'environnement dans le pod.
|
||||
|
||||
{{< codenew file="pods/pod-configmap-envFrom.yaml" >}}
|
||||
{{% codenew file="pods/pod-configmap-envFrom.yaml" %}}
|
||||
|
||||
Créez le pod:
|
||||
|
||||
|
|
@ -522,7 +522,7 @@ Vous pouvez utiliser des variables d'environnement définies par ConfigMap dans
|
|||
|
||||
Par exemple, la spécification de pod suivante
|
||||
|
||||
{{< codenew file="pods/pod-configmap-env-var-valueFrom.yaml" >}}
|
||||
{{% codenew file="pods/pod-configmap-env-var-valueFrom.yaml" %}}
|
||||
|
||||
créé en exécutant
|
||||
|
||||
|
|
@ -543,7 +543,7 @@ Le contenu du fichier devient la valeur de la clé.
|
|||
|
||||
Les exemples de cette section se réfèrent à un ConfigMap nommé special-config, illustré ci-dessous.
|
||||
|
||||
{{< codenew file="configmap/configmap-multikeys.yaml" >}}
|
||||
{{% codenew file="configmap/configmap-multikeys.yaml" %}}
|
||||
|
||||
Créez le ConfigMap:
|
||||
|
||||
|
|
@ -557,7 +557,7 @@ Ajoutez le nom ConfigMap sous la section `volumes` de la spécification Pod.
|
|||
Ceci ajoute les données ConfigMap au répertoire spécifié comme `volumeMounts.mountPath` (dans ce cas, `/etc/config`).
|
||||
La section `command` répertorie les fichiers de répertoire dont les noms correspondent aux clés de ConfigMap.
|
||||
|
||||
{{< codenew file="pods/pod-configmap-volume.yaml" >}}
|
||||
{{% codenew file="pods/pod-configmap-volume.yaml" %}}
|
||||
|
||||
Créez le pod:
|
||||
|
||||
|
|
@ -581,7 +581,7 @@ S'il y a des fichiers dans le dossier `/etc/config/`, ils seront supprimés.
|
|||
Utilisez le champ `path` pour spécifier le chemin de fichier souhaité pour les éléments de configmap spécifiques.
|
||||
Dans ce cas, le `SPECIAL_LEVEL` sera monté dans le volume `config-volume` au chemin `/etc/config/keys`.
|
||||
|
||||
{{< codenew file="pods/pod-configmap-volume-specific-key.yaml" >}}
|
||||
{{% codenew file="pods/pod-configmap-volume-specific-key.yaml" %}}
|
||||
|
||||
Créez le Pod :
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Dans cet exercice, vous allez créer un Pod qui a un conteneur d'application et
|
|||
|
||||
Voici le fichier de configuration du Pod :
|
||||
|
||||
{{< codenew file="pods/init-containers.yaml" >}}
|
||||
{{% codenew file="pods/init-containers.yaml" %}}
|
||||
|
||||
Dans le fichier de configuration, vous pouvez voir que le Pod a un Volume que le conteneur d'initialisation et le conteneur d'application partagent.
|
||||
|
||||
|
|
|
|||
|
|
@ -269,7 +269,7 @@ Ce comportement est configuré sur un PodSpec utilisant un type de ProjectedVolu
|
|||
[ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Pour fournir un
|
||||
Pod avec un token avec une audience de "vault" et une durée de validité de deux heures, vous devriez configurer ce qui suit dans votre PodSpec :
|
||||
|
||||
{{< codenew file="pods/pod-projected-svc-token.yaml" >}}
|
||||
{{% codenew file="pods/pod-projected-svc-token.yaml" %}}
|
||||
|
||||
Créez le Pod
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ Dans cet exercice, vous créez un pod qui contient un seul conteneur. Ce Pod a u
|
|||
[emptyDir](/fr/docs/concepts/storage/volumes/#emptydir) qui dure toute la vie du Pod, même si le conteneur se termine et redémarre.
|
||||
Voici le fichier de configuration du Pod :
|
||||
|
||||
{{< codenew file="pods/storage/redis.yaml" >}}
|
||||
{{% codenew file="pods/storage/redis.yaml" %}}
|
||||
|
||||
1. Créez le Pod :
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Les noms de ressources supplémentaires valides ont la forme `example.com/foo` o
|
|||
|
||||
Voici le fichier de configuration d'un Pod qui a un seul conteneur :
|
||||
|
||||
{{< codenew file="pods/resource/extended-resource-pod.yaml" >}}
|
||||
{{% codenew file="pods/resource/extended-resource-pod.yaml" %}}
|
||||
|
||||
Dans le fichier de configuration, vous pouvez constater que le conteneur demande 3 dongles.
|
||||
|
||||
|
|
@ -70,7 +70,7 @@ Requests:
|
|||
Voici le fichier de configuration d'un Pod qui a un seul conteneur. Le conteneur demande
|
||||
deux dongles.
|
||||
|
||||
{{< codenew file="pods/resource/extended-resource-pod-2.yaml" >}}
|
||||
{{% codenew file="pods/resource/extended-resource-pod-2.yaml" %}}
|
||||
|
||||
Kubernetes ne pourra pas satisfaire la demande de deux dongles, parce que le premier Pod
|
||||
a utilisé trois des quatre dongles disponibles.
|
||||
|
|
|
|||
|
|
@ -170,7 +170,7 @@ Vous avez réussi à définir vos identifiants de Docker comme un Secret appelé
|
|||
|
||||
Voici un fichier de configuration pour un Pod qui a besoin d'accéder à vos identifiants Docker dans `regcred` :
|
||||
|
||||
{{< codenew file="pods/private-reg-pod.yaml" >}}
|
||||
{{% codenew file="pods/private-reg-pod.yaml" %}}
|
||||
|
||||
Téléchargez le fichier ci-dessus :
|
||||
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ Pour qu'un Pod reçoive une classe de QoS Guaranteed :
|
|||
Ci-dessous le fichier de configuration d'un Pod qui a un seul conteneur.
|
||||
Le conteneur dispose d'une limite de mémoire et d'une demande de mémoire, tous deux égaux à 200 MiB. Le conteneur a également une limite CPU et une demande CPU, toutes deux égales à 700 milliCPU :
|
||||
|
||||
{{< codenew file="pods/qos/qos-pod.yaml" >}}
|
||||
{{% codenew file="pods/qos/qos-pod.yaml" %}}
|
||||
|
||||
Créez le Pod :
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ Un Pod reçoit une classe QoS de Burstable si :
|
|||
|
||||
Voici le fichier de configuration d'un pod qui a un seul conteneur. Le conteneur a une limite de mémoire de 200 MiB et une demande de mémoire de 100 MiB.
|
||||
|
||||
{{< codenew file="pods/qos/qos-pod-2.yaml" >}}
|
||||
{{% codenew file="pods/qos/qos-pod-2.yaml" %}}
|
||||
|
||||
Créez le Pod :
|
||||
|
||||
|
|
@ -143,7 +143,7 @@ avoir des limites ou des demandes de mémoire ou de CPU.
|
|||
|
||||
Voici le fichier de configuration d'un Pod qui a un seul conteneur. Le conteneur n'a pas des limites ou des demandes de mémoire ou de CPU :
|
||||
|
||||
{{< codenew file="pods/qos/qos-pod-3.yaml" >}}
|
||||
{{% codenew file="pods/qos/qos-pod-3.yaml" %}}
|
||||
|
||||
Créez le Pod :
|
||||
|
||||
|
|
@ -181,7 +181,7 @@ kubectl delete pod qos-demo-3 --namespace=qos-example
|
|||
Voici le fichier de configuration d'un Pod qui a deux conteneurs. Un conteneur spécifie une
|
||||
demande de mémoire de 200 MiB. L'autre conteneur ne spécifie aucune demande ou limite.
|
||||
|
||||
{{< codenew file="pods/qos/qos-pod-4.yaml" >}}
|
||||
{{% codenew file="pods/qos/qos-pod-4.yaml" %}}
|
||||
|
||||
Notez que le pod répond aux critères de la classe QoS Burstable. En d'autres termes, il ne répond pas aux exigences de la classe de qualité de service Guaranteed, et l'un de ses conteneurs dispose d'une demande de mémoire.
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ Vous pouvez utiliser cette fonctionnalité pour configurer les conteneurs coopé
|
|||
|
||||
Le partage de l'espace de nommage du processus est activé en utilisant le champ `shareProcessNamespace` de `v1.PodSpec`. Par exemple:
|
||||
|
||||
{{< codenew file="pods/share-process-namespace.yaml" >}}
|
||||
{{% codenew file="pods/share-process-namespace.yaml" %}}
|
||||
|
||||
1. Créez le pod `nginx` sur votre cluster :
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Dans cet exercice, vous allez créer un pod contenant un conteneur.
|
|||
Le conteneur exécute une image nginx.
|
||||
Voici le fichier de configuration du Pod:
|
||||
|
||||
{{< codenew file="application/shell-demo.yaml" >}}
|
||||
{{% codenew file="application/shell-demo.yaml" %}}
|
||||
|
||||
Créez le Pod:
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ Le champ `command` correspond à `entrypoint` dans certains runtimes de containe
|
|||
|
||||
Dans cet exercice, vous allez créer un Pod qui exécute un container.
|
||||
Le fichier de configuration pour le Pod défini une commande ainsi que deux arguments:
|
||||
{{< codenew file="pods/commands.yaml" >}}
|
||||
{{% codenew file="pods/commands.yaml" %}}
|
||||
|
||||
1. Créez un Pod en utilisant le fichier YAML de configuration suivant:
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ dans le fichier de configuration.
|
|||
|
||||
Dans cet exercice, vous allez créer un Pod qui exécute un container. Le fichier de configuration pour ce Pod contient une variable d'environnement s'appelant `DEMO_GREETING` et sa valeur est `"Hello from the environment"`. Voici le fichier de configuration du Pod:
|
||||
|
||||
{{< codenew file="pods/inject/envars.yaml" >}}
|
||||
{{% codenew file="pods/inject/envars.yaml" %}}
|
||||
|
||||
1. Créez un Pod à partir de ce fichier:
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ Pour définir une variable d'environnement dépendante, vous pouvez utiliser le
|
|||
|
||||
Dans cette exercice, vous allez créer un Pod qui exécute un container. Le fichier de configuration de ce Pod définit des variables d'environnement interdépendantes avec une ré-utilisation entre les différentes variables. Voici le fichier de configuration de ce Pod:
|
||||
|
||||
{{< codenew file="pods/inject/dependent-envars.yaml" >}}
|
||||
{{% codenew file="pods/inject/dependent-envars.yaml" %}}
|
||||
|
||||
1. Créez un Pod en utilisant ce fichier de configuration:
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ afin de réduire les risques de sécurité liés à l'utilisation d'un outil ext
|
|||
Voici un fichier de configuration que vous pouvez utiliser pour créer un Secret
|
||||
qui contiendra votre identifiant et mot de passe:
|
||||
|
||||
{{< codenew file="pods/inject/secret.yaml" >}}
|
||||
{{% codenew file="pods/inject/secret.yaml" %}}
|
||||
|
||||
1. Créez le Secret:
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ montrée précédemment permet de démontrer et comprendre le fonctionnement des
|
|||
|
||||
Voici un fichier de configuration qui permet de créer un Pod:
|
||||
|
||||
{{< codenew file="pods/inject/secret-pod.yaml" >}}
|
||||
{{% codenew file="pods/inject/secret-pod.yaml" %}}
|
||||
|
||||
1. Créez le Pod:
|
||||
|
||||
|
|
@ -255,7 +255,7 @@ permettant de redémarrer les containers lors d'une mise à jour du Secret.
|
|||
* Assignez la valeur de `backend-username` définie dans le Secret
|
||||
à la variable d'environnement `SECRET_USERNAME` dans la configuration du Pod.
|
||||
|
||||
{{< codenew file="pods/inject/pod-single-secret-env-variable.yaml" >}}
|
||||
{{% codenew file="pods/inject/pod-single-secret-env-variable.yaml" %}}
|
||||
|
||||
* Créez le Pod:
|
||||
|
||||
|
|
@ -286,7 +286,7 @@ permettant de redémarrer les containers lors d'une mise à jour du Secret.
|
|||
|
||||
* Définissez les variables d'environnement dans la configuration du Pod.
|
||||
|
||||
{{< codenew file="pods/inject/pod-multiple-secret-env-variable.yaml" >}}
|
||||
{{% codenew file="pods/inject/pod-multiple-secret-env-variable.yaml" %}}
|
||||
|
||||
* Créez le Pod:
|
||||
|
||||
|
|
@ -323,7 +323,7 @@ Cette fonctionnalité n'est disponible que dans les versions de Kubernetes
|
|||
d'environnement. Les clés du Secret deviendront les noms des variables
|
||||
d'environnement à l'intérieur du Pod.
|
||||
|
||||
{{< codenew file="pods/inject/pod-secret-envFrom.yaml" >}}
|
||||
{{% codenew file="pods/inject/pod-secret-envFrom.yaml" %}}
|
||||
|
||||
* Créez le Pod:
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ et vous allez projeter les champs d'informations du Pod à l'intérieur du
|
|||
container via des fichiers dans le container.
|
||||
Voici le fichier de configuration du Pod:
|
||||
|
||||
{{< codenew file="pods/inject/dapi-volume.yaml" >}}
|
||||
{{% codenew file="pods/inject/dapi-volume.yaml" %}}
|
||||
|
||||
Dans la configuration, on peut voir que le Pod a un volume de type `downward API`, et que le container monte ce volume sur le chemin `/etc/podinfo`.
|
||||
|
||||
|
|
@ -154,7 +154,7 @@ qui appartiennent au
|
|||
[container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container), plutôt qu'au Pod.
|
||||
Voici un fichier de configuration pour un Pod qui n'a qu'un seul container:
|
||||
|
||||
{{< codenew file="pods/inject/dapi-volume-resources.yaml" >}}
|
||||
{{% codenew file="pods/inject/dapi-volume-resources.yaml" %}}
|
||||
|
||||
Dans cette configuration, on peut voir que le Pod a un volume de type
|
||||
[`downwardAPI`](/docs/concepts/storage/volumes/#downwardapi),
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ Dans cette partie de l'exercice, vous allez créer un Pod qui a un container,
|
|||
et vous allez projeter les champs d'informations du Pod à l'intérieur du
|
||||
container comme variables d'environnement.
|
||||
|
||||
{{< codenew file="pods/inject/dapi-envars-pod.yaml" >}}
|
||||
{{% codenew file="pods/inject/dapi-envars-pod.yaml" %}}
|
||||
|
||||
Dans ce fichier de configuration, on trouve cinq variables d'environnement.
|
||||
Le champ `env` est une liste de variables d'environnement.
|
||||
|
|
@ -113,7 +113,7 @@ qui est exécuté à l'intérieur du Pod.
|
|||
Voici un fichier de configuration pour un autre Pod qui ne contient qu'un seul
|
||||
container:
|
||||
|
||||
{{< codenew file="pods/inject/dapi-envars-container.yaml" >}}
|
||||
{{% codenew file="pods/inject/dapi-envars-container.yaml" %}}
|
||||
|
||||
Dans ce fichier, vous pouvez voir 4 variables d'environnement.
|
||||
Le champ `env` est une liste de variables d'environnement.
|
||||
|
|
|
|||
|
|
@ -53,7 +53,9 @@ Pour apprendre comment déployer le Metrics Server, consultez la [documentation
|
|||
Pour démontrer un HorizontalPodAutoscaler, vous commencerez par démarrer un
|
||||
Deployment qui exécute un conteneur utilisant l'image `hpa-example`
|
||||
et l'expose en tant que {{< glossary_tooltip term_id="service">}} en utilisant le
|
||||
manifeste suivant: {{< codenew file="application/php-apache.yaml" >}}
|
||||
manifeste suivant:
|
||||
|
||||
{{% codenew file="application/php-apache.yaml" %}}
|
||||
|
||||
Pour créer les ressources, exécutez la commande suivante:
|
||||
```shell
|
||||
|
|
@ -505,7 +507,7 @@ Cela signifie que vous pouvez voir la valeur de votre métrique fluctuer entre `
|
|||
Au lieu d'utiliser la commande `kubectl autoscale` pour créer un HorizontalPodAutoscaler de manière impérative,
|
||||
nous pouvons utiliser le manifeste suivant pour le créer de manière déclarative :
|
||||
|
||||
{{< codenew file=application/hpa/php-apache.yaml >}}
|
||||
{{% codenew file=application/hpa/php-apache.yaml %}}
|
||||
|
||||
Ensuite, créez l'autoscaler en exécutant la commande suivante :
|
||||
|
||||
|
|
|
|||
|
|
@ -37,8 +37,8 @@ Remarque: le mot de passe MySQL est défini dans le fichier de configuration YAM
|
|||
Voir les [secrets Kubernetes](/docs/concepts/configuration/secret/)
|
||||
pour une approche sécurisée.
|
||||
|
||||
{{< codenew file="application/mysql/mysql-deployment.yaml" >}}
|
||||
{{< codenew file="application/mysql/mysql-pv.yaml" >}}
|
||||
{{% codenew file="application/mysql/mysql-deployment.yaml" %}}
|
||||
{{% codenew file="application/mysql/mysql-pv.yaml" %}}
|
||||
|
||||
1. Déployez le PV et le PVC du fichier YAML:
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ déploiement Kubernetes, et vous pouvez décrire un
|
|||
déploiement dans un fichier YAML. Par exemple,
|
||||
ce fichier YAML décrit un déploiement qui exécute l'image Docker nginx:1.14.2 :
|
||||
|
||||
{{< codenew file="application/deployment.yaml" >}}
|
||||
{{% codenew file="application/deployment.yaml" %}}
|
||||
|
||||
1. Créez un déploiement basé sur ce fichier YAML:
|
||||
|
||||
|
|
@ -102,7 +102,7 @@ Vous pouvez mettre à jour le déploiement en appliquant un nouveau fichier YAML
|
|||
Ce fichier YAML indique que le déploiement doit être mis à jour
|
||||
pour utiliser nginx 1.16.1.
|
||||
|
||||
{{< codenew file="application/deployment-update.yaml" >}}
|
||||
{{% codenew file="application/deployment-update.yaml" %}}
|
||||
|
||||
1. Appliquez le nouveau fichier YAML :
|
||||
|
||||
|
|
@ -121,7 +121,7 @@ pour utiliser nginx 1.16.1.
|
|||
Vous pouvez augmenter le nombre de pods dans votre déploiement en appliquant un nouveau fichier YAML.
|
||||
Ce fichier YAML définit `replicas` à 4, ce qui spécifie que le déploiement devrait avoir quatre pods :
|
||||
|
||||
{{< codenew file="application/deployment-scale.yaml" >}}
|
||||
{{% codenew file="application/deployment-scale.yaml" %}}
|
||||
|
||||
1. Appliquez le nouveau fichier YAML :
|
||||
|
||||
|
|
|
|||
|
|
@ -39,9 +39,9 @@ Vous pouvez également suivre ce tutoriel si vous avez installé [Minikube local
|
|||
|
||||
Ce tutoriel fournit une image de conteneur construite à partir des fichiers suivants :
|
||||
|
||||
{{< codenew language="js" file="minikube/server.js" >}}
|
||||
{{% codenew language="js" file="minikube/server.js" %}}
|
||||
|
||||
{{< codenew language="conf" file="minikube/Dockerfile" >}}
|
||||
{{% codenew language="conf" file="minikube/Dockerfile" %}}
|
||||
|
||||
Pour plus d'informations sur la commande `docker build`, lisez la documentation de [Docker](https://docs.docker.com/engine/reference/commandline/build/).
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue