whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

kubectl conventions

Browse Source
This commit is contained in:
Philippe Martin
2020-05-21 17:01:46 +02:00
parent 42aaef89f7
commit 588bfba93d
1 changed files with 24 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/fr/docs/reference/kubectl/conventions.md
+24 -39
View File
@@ -16,7 +16,6 @@ Pour une sortie stable dans un script :
* Demandez un des formats de sortie orienté machine, comme `-o name`, `-o json`, `-o yaml`, `-o go-template` ou `-o jsonpath`. * Demandez un des formats de sortie orienté machine, comme `-o name`, `-o json`, `-o yaml`, `-o go-template` ou `-o jsonpath`.
* 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. * 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.
* 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`.
* Ne vous basez pas sur un contexte, des préférences ou tout autre état implicite. * Ne vous basez pas sur un contexte, des préférences ou tout autre état implicite.
## Bonnes pratiques ## Bonnes pratiques
@@ -26,48 +25,34 @@ Pour une sortie stable dans un script :
Pour que `kubectl run` satisfasse l'infrastructure as code : Pour que `kubectl run` satisfasse l'infrastructure as code :
* 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)). * 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)).
* 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.
* Capturez le script pour une image fortement paramétrée. * Capturez le script pour une image fortement paramétrée.
* 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`. * 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`.
* Collez à une version spécifique de [générateur](#generators), comme `kubectl run --generator=deployment/v1beta1`.
Vous pouvez utiliser l'option `--dry-run` pour prévisualiser l'objet qui serait envoyé à votre cluster, sans réellement l'envoyer.
{{< note >}}
Tous les générateurs `kubectl` sont dépréciés. Voir la documentation de Kubernetes v1.17 pour une [liste](https://v1-17.docs.kubernetes.io/fr/docs/reference/kubectl/conventions/#g%C3%A9n%C3%A9rateurs) de générateurs et comment ils étaient utilisés.
{{< /note >}}
#### Générateurs #### Générateurs
Vous pouvez générer les ressources suivantes avec une commande kubectl, `kubectl create --dry-run -o yaml`:
Vous pouvez créer les ressources suivantes en utilisant `kubectl run` avec le flag `--generator` : ```
clusterrole Crée un ClusterRole.
| Ressource | groupe api | commande kubectl | clusterrolebinding Crée un ClusterRoleBinding pour un ClusterRole particulier.
|-----------------------------------|--------------------|---------------------------------------------------| configmap Crée une configmap à partir d'un fichier local, un répertoire ou une valeur litérale.
| Pod | v1 | `kubectl run --generator=run-pod/v1` | cronjob Crée un cronjob avec le nom spécifié.
| Replication controller (déprécié) | v1 | `kubectl run --generator=run/v1` | deployment Crée un deployment avec le nom spécifié.
| Deployment (déprécié) | extensions/v1beta1 | `kubectl run --generator=deployment/v1beta1` | job Crée un job avec le nom spécifié.
| Deployment (déprécié) | apps/v1beta1 | `kubectl run --generator=deployment/apps.v1beta1` | namespace Crée un namespace avec le nom spécifié.
| Job (déprécié) | batch/v1 | `kubectl run --generator=job/v1` | poddisruptionbudget Crée un pod disruption budget avec le nom spécifié.
| CronJob (déprécié) | batch/v1beta1 | `kubectl run --generator=cronjob/v1beta1` | priorityclass Crée une priorityclass avec le nom spécifié.
| CronJob (déprécié) | batch/v2alpha1 | `kubectl run --generator=cronjob/v2alpha1` | quota Crée un quota avec le nom spécifié.
role Crée un role avec une unique règle.
{{< note >}} rolebinding Crée un RoleBinding pour un Role ou ClusterRole particulier.
`kubectl run --generator` sauf pour `run-pod/v1` est déprécié depuis v1.12. secret Crée un secret en utilisant la sous-commande spécifiée.
{{< /note >}} service Crée un service en utilisant la sous-commande spécifiée.
serviceaccount Crée un service account avec le nom spécifié.
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 : ```
| Ressource générée | Cluster v1.4 et suivants | Cluster v1.3 | Cluster v1.2 | Cluster v1.1 et précédents |
|:----------------------:|--------------------------|-----------------------|--------------------------------------------|--------------------------------------------|
| Pod | `--restart=Never` | `--restart=Never` | `--generator=run-pod/v1` | `--restart=OnFailure` OU `--restart=Never` |
| Replication Controller | `--generator=run/v1` | `--generator=run/v1` | `--generator=run/v1` | `--restart=Always` |
| Deployment | `--restart=Always` | `--restart=Always` | `--restart=Always` | N/A |
| Job | `--restart=OnFailure` | `--restart=OnFailure` | `--restart=OnFailure` OU `--restart=Never` | N/A |
| Cron Job | `--schedule=<cron>` | N/A | N/A | N/A |
{{< note >}}
Ces flags utilisent un générateur par défaut uniquement lorsque vous n'avez utilisé aucun flag.
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éé.
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.
{{< /note >}}
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`.
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.
### `kubectl apply` ### `kubectl apply`