Skip to content

Commit ea3c0a8

Browse files
committed
docs-fr | Reference | kubectl misc
1 parent 56021dc commit ea3c0a8

File tree

3 files changed

+85
-0
lines changed

3 files changed

+85
-0
lines changed
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
---
2+
title: "CLI kubectl"
3+
weight: 60
4+
---
5+
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,75 @@
1+
---
2+
title: Conventions d'utilisation de kubectl
3+
content_template: templates/concept
4+
---
5+
6+
{{% capture overview %}}
7+
Conventions d'utilisation recommandées pour `kubectl`.
8+
{{% /capture %}}
9+
10+
{{% capture body %}}
11+
12+
## Utiliser `kubectl` dans des scripts réutilisables
13+
14+
Pour une sortie stable dans un script :
15+
16+
* Demandez une des formes de sortie orientée machine, comme `-o name`, `-o json`, `-o yaml`, `-o go-template` ou `-o jsonpath`.
17+
* Spécifiez complètement la version. Par exemple, `jobs.v1.batch/monjob`. Cela va assurer que kubectl n'utilise pas sa version par défaut, qui risque d'évoluer avec le temps.
18+
* Utilisez le flag `--generator` pour coller à un comportement spécifique lorsque vous utilisez les commandes basées sur un générateur, comme `kubectl run` ou `kubectl expose`.
19+
* Ne vous basez pas sur un contexte, des préférences ou tout autre état implicite.
20+
21+
## Bonnes pratiques
22+
23+
### `kubectl run`
24+
25+
Pour que `kubectl run` satisfasse l'infrastructure as code :
26+
27+
* Taggez les images avec un tag spécifique à une version et n'utilisez pas ce tag pour une nouvelle version. Par exemple, utilisez `:v1234`, `v1.2.3`, `r03062016-1-4`, plutôt que `:latest` (Pour plus d'informations, voir [Bonnes pratiques pour la configuration](/docs/concepts/configuration/overview/#container-images)).
28+
* Capturez les paramètres dans un script enregistré, ou tout au moins utilisez `--record` pour annoter les objets créés avec la ligne de commande correspondante pour une image peu paramétrée.
29+
* Capturez le script pour une image fortement paramétrée.
30+
* Passez à des fichiers de configuration enregistrés dans un système de contrôle de source pour des fonctionnalités désirées mais non exprimables avec des flags de `kubectl run`.
31+
* Collez à une version spécifique de [générateur](#generators), comme `kubectl run --generator=deployment/v1beta1`.
32+
33+
#### Générateurs
34+
35+
Vous pouvez créer les ressources suivantes en utilisant `kubectl run` avec le flag `--generator` :
36+
37+
| Resource | commande kubectl |
38+
|---------------------------------|---------------------------------------------------|
39+
| Pod | `kubectl run --generator=run-pod/v1` |
40+
| Replication controller | `kubectl run --generator=run/v1` |
41+
| Deployment | `kubectl run --generator=extensions/v1beta1` |
42+
| -pour un endpoint (défaut) | `kubectl run --generator=deployment/v1beta1` |
43+
| Deployment | `kubectl run --generator=apps/v1beta1` |
44+
| -pour un endpoint (recommandé) | `kubectl run --generator=deployment/apps.v1beta1` |
45+
| Job | `kubectl run --generator=job/v1` |
46+
| CronJob | `kubectl run --generator=batch/v1beta1` |
47+
| -pour un endpoint (défaut) | `kubectl run --generator=cronjob/v1beta1` |
48+
| CronJob | `kubectl run --generator=batch/v2alpha1` |
49+
| -pour un endpoint (déprécié) | `kubectl run --generator=cronjob/v2alpha1` |
50+
51+
Si vous n'indiquez pas de flag de générateur, d'autres flags vous demandent d'utiliser un générateur spécifique. La table suivante liste les flags qui vous forcent à préciser un générateur spécifique, selon la version du cluster :
52+
53+
| Ressource générée | Cluster v1.4 et suivants | Cluster v1.3 | Cluster v1.2 | Cluster v1.1 et précédents |
54+
|:----------------------:|--------------------------|-----------------------|--------------------------------------------|--------------------------------------------|
55+
| Pod | `--restart=Never` | `--restart=Never` | `--generator=run-pod/v1` | `--restart=OnFailure` OU `--restart=Never` |
56+
| Replication Controller | `--generator=run/v1` | `--generator=run/v1` | `--generator=run/v1` | `--restart=Always` |
57+
| Deployment | `--restart=Always` | `--restart=Always` | `--restart=Always` | N/A |
58+
| Job | `--restart=OnFailure` | `--restart=OnFailure` | `--restart=OnFailure` OU `--restart=Never` | N/A |
59+
| Cron Job | `--schedule=<cron>` | N/A | N/A | N/A |
60+
61+
{{< note >}}
62+
Ces flags utilisent un générateur par défaut uniquement lorsque vous n'avez utilisé aucun flag.
63+
Cela veut dire que lorsque vous combinez `--generator` avec d'autres flags, le générateur que vous avez spécifié plus tard ne change pas. Par exemple, dans cluster v1.4, si vous spécifiez d'abord `--restart=Always`, un Deployment est créé ; si vous spécifiez ensuite `--restart=Always` et `--generator=run/v1`, alors un Replication Controller sera créé.
64+
Ceci vous permet de coller à un comportement spécifique avec le générateur, même si le générateur par défaut est changé par la suite.
65+
{{< /note >}}
66+
67+
Les flags définissent le générateur dans l'ordre suivant : d'abord le flag `--schedule`, puis le flag `--restart`, et finalement le flag `--generator`.
68+
69+
Pour vérifier la ressource qui a été finalement créée, utilisez le flag `--dry-run`, qui fournit l'objet qui sera soumis au cluster.
70+
71+
### `kubectl apply`
72+
73+
* Vous pouvez utiliser `kubectl apply` pour créer ou mettre à jour des ressources. Cependant, pour mettre à jour une ressource, vous devez avoir créé la ressource en utilisant `kubectl apply` ou `kubectl create --save-config`. Pour plus d'informations sur l'utilisation de `kubectl apply` pour la mise à jour de ressources, voir [Gérer les ressources](/docs/concepts/cluster-administration/manage-deployment/#kubectl-apply).
74+
75+
{{% /capture %}}
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
---
2+
title: Commandes kubectl
3+
---
4+
5+
[Référence des commandes kubectl](/docs/reference/generated/kubectl/kubectl-commands/)

0 commit comments

Comments
 (0)