|
| 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 %}} |
0 commit comments