Pour appeler l'API de Kubernetes depuis un langage de programmation on peut utiliser une bibliothèque client. Les bibliothèques client officiellement supportées sont:
kubeadm - Outil en ligne de commande (CLI) pour provisionner facilement un cluster Kubernetes sécurisé.
kubefed - Outil en ligne de commande (CLI) pour aider à administrer des clusters fédérés.
Documents de Référence pour la configuration
kubelet - Le principal agent qui s'exécute sur chaque noeud. Kubelet prends un ensemble de PodSpecs et s'assure que les conteneurs qui y sont décrit s'exécutent correctement.
kube-apiserver - L'API REST qui valide et configure les données des objects de l'API tels que les Pods, Services, Deployments ...
kube-controller-manager - Démon en charge de la principale boucle de régulation (core control loop) de Kubernetes.
kube-proxy - S'occupe de reacheminer (forwarding) simplement les flux TCP/UDP ou bien en utilisant un Round-Robin sur un ensemble de back-ends.
kube-scheduler - Ordonnanceur (scheduler) qui gère la disponibilité, la performance et la capacité.
2 - Problèmes et alertes de sécurité de Kubernetes
3 - Utilisation de l'API Kubernetes
4 - Accéder à l'API
4.1 - Utilisation de l'autorisation RBAC
Le contrôle d'accès basé sur les rôles (RBAC) est une méthode permettant de
réguler l'accès aux ressources informatiques ou réseau en fonction des rôles des
utilisateurs individuels au sein de votre organisation.
L'autorisation RBAC utilise le groupe d'APIrbac.authorization.k8s.io pour prendre les
décisions d'autorisation, ce qui vous permet de configurer
dynamiquement les politiques via l'API Kubernetes.
Pour activer RBAC, démarrez l'API server
avec l'indicateur --authorization-mode défini sur une liste séparée par des virgules qui inclut RBAC ;
par exemple :
L'API RBAC déclare quatre types d'objets Kubernetes : Role, ClusterRole,
RoleBinding et ClusterRoleBinding. Vous pouvez
décrire les objets,
ou les modifier, en utilisant des outils tels que kubectl, comme tout autre objet Kubernetes.
Avertissement:
Ces objets, de par leur conception, imposent des restrictions d'accès. Si vous apportez des modifications
à un cluster au fur et à mesure de votre apprentissage, consultez la
prévention de l'escalade des privilèges et amorçage
pour comprendre comment ces restrictions peuvent vous empêcher d'effectuer certaines modifications.
Role et ClusterRole
Un Role ou ClusterRole RBAC contient des règles qui représentent un ensemble de permissions.
Les permissions sont purement additives (il n'y a pas de règles de "refus").
Un rôle définit toujours les autorisations dans un namespace particulier;
lorsque vous créez un Role, vous devez spécifier le namespace auquel il appartient.
ClusterRole, en revanche, est une ressource sans namespace. Les ressources portent des noms différents (Role
et ClusterRole) parce qu'un objet Kubernetes doit toujours être soit avec un namespace ou soit sans namespace;
Il ne peut pas être les deux.
Les ClusterRoles ont plusieurs usages. Vous pouvez utiliser une ClusterRole pour :
définir les autorisations sur les ressources avec un namespace et obtenir l'accès à l'intérieur d'un ou plusieurs namespaces
définir les permissions sur les ressources avec un namespace et obtenir l'accès à travers tous les namespaces.
définir les permissions sur les ressources à l'échelle du cluster
Si vous souhaitez définir un rôle au sein d'un namespace, utilisez un Role; si vous souhaitez
définir un rôle à l'échelle du cluster, utilisez un ClusterRole.
Exemple de Role
Voici un exemple de rôle dans le namespace "default" qui peut être utilisé pour accorder un accès en lecture aux
pods:
apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:namespace:defaultname:pod-readerrules:- apiGroups:[""]# "" indicates the core API groupresources:["pods"]verbs:["get","watch","list"]
Exemple de ClusterRole
Un ClusterRole peut être utilisé pour accorder les mêmes permissions qu'un Role.
Étant donné que les ClusterRoles sont à l'échelle des clusters, vous pouvez également
les utiliser pour accorder l'accès à:
des ressources à l'échelle du cluster (comme nodes)
des endpoints non liés aux ressources (comme /healthz)
des ressources à namespaces (comme les pods), dans tous les namespaces.
Par exemple: vous pouvez utiliser un ClusterRole pour autoriser un utilisateur particulier à exécuter
kubectl get pods --all-namespaces
Voici un exemple de ClusterRole qui peut être utilisé pour accorder un accès en lecture à
secrets dans un namespace particulier,
ou dans tous les namespaces (selon la façon dont il est lié):
apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRolemetadata:# "namespace" omitted since ClusterRoles are not namespacedname:secret-readerrules:- apiGroups:[""]## at the HTTP level, the name of the resource for accessing Secret# objects is "secrets"resources:["secrets"]verbs:["get","watch","list"]
Un RoleBinding accorde les permissions définies dans un rôle à un utilisateur ou à un ensemble d'utilisateurs.
Il contient une liste de sujets (utilisateurs, groupes, ou comptes de service), et une référence au rôle accordé.
Un RoleBinding accorde des permissions dans un namespace spécifique alors qu'un ClusterRoleBinding accorde cet accès à l'échelle du cluster.
Le nom d'un objet RoleBinding ou ClusterRoleBinding doit être un nom de segment de chemin valide.
Exemples de RoleBinding
Voici un exemple de RoleBinding qui accorde le Role "pod-reader" à l'utilisateur "jane"
dans le namespace "default".
Ceci permet à "jane" de lire les pods dans le namespace "default".
apiVersion:rbac.authorization.k8s.io/v1# This role binding allows "jane" to read pods in the "default" namespace.# You need to already have a Role named "pod-reader" in that namespace.kind:RoleBindingmetadata:name:read-podsnamespace:defaultsubjects:# You can specify more than one "subject"- kind:Username:jane# "name" is case sensitiveapiGroup:rbac.authorization.k8s.ioroleRef:# "roleRef" specifies the binding to a Role / ClusterRolekind:Role#this must be Role or ClusterRolename:pod-reader# this must match the name of the Role or ClusterRole you wish to bind toapiGroup:rbac.authorization.k8s.io
Un RoleBinding peut également faire référence à un ClusterRole pour accorder les
permissions définies dans ce ClusterRole aux ressources du namespace du RoleBinding.
Ce type de référence vous permet de définir un ensemble de rôles communs à l'ensemble
de votre cluster, puis de les réutiliser dans plusieurs namespaces.
Par exemple, même si le RoleBinding suivant fait référence à un ClusterRole, "dave" (le sujet, sensible à la casse)
ne pourra lire que les Secrets dans le namespace "development", car le namespace du
RoleBinding (dans son metadata) est "development".
apiVersion:rbac.authorization.k8s.io/v1# This role binding allows "dave" to read secrets in the "development" namespace.# You need to already have a ClusterRole named "secret-reader".kind:RoleBindingmetadata:name:read-secrets## The namespace of the RoleBinding determines where the permissions are granted.# This only grants permissions within the "development" namespace.namespace:developmentsubjects:- kind:Username:dave# Name is case sensitiveapiGroup:rbac.authorization.k8s.ioroleRef:kind:ClusterRolename:secret-readerapiGroup:rbac.authorization.k8s.io
Exemple de ClusterRoleBinding
Pour accorder des permissions sur l'ensemble d'un cluster, vous pouvez utiliser un
ClusterRoleBinding. Le ClusterRoleBinding suivant permet à tout utilisateur du groupe "manager"
de lire secrets dans n'importe quel namespace.
apiVersion:rbac.authorization.k8s.io/v1# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.kind:ClusterRoleBindingmetadata:name:read-secrets-globalsubjects:- kind:Groupname:manager# Name is case sensitiveapiGroup:rbac.authorization.k8s.ioroleRef:kind:ClusterRolename:secret-readerapiGroup:rbac.authorization.k8s.io
Après avoir créé un lien, vous ne pouvez pas modifier le Role ou le ClusterRole auquel il fait référence.
Si vous essayez de modifier le roleRef d'un lien, vous obtenez une erreur de validation.
Si vous souhaitez changer le roleRef d'un lien, vous devez supprimer l'objet binding
et en créer un autre.
Il y a deux raisons à cette restriction :
Rendre roleRef immuable permet d'accorder à quelqu'un la permission update sur un objet de liaison existant,
afin qu'il puisse gérer la liste des sujets, sans pouvoir changer le rôle qui est accordé à ces sujets.
Un lien vers un rôle différent est un lien fondamentalement différent.
Le fait d'exiger qu'un lien soit supprimé/créé afin de modifier le roleRef
garantit que la liste complète des sujets dans le binding est destinée à
recevoir le nouveau rôle (par opposition à l'activation ou à la modification
accidentelle uniquement du roleRef sans vérifier que tous les sujets existants
doivent recevoir les permissions du nouveau rôle).
L'utilitaire de ligne de commande kubectl auth reconcile crée ou met à jour un fichier manifeste contenant des objets RBAC,
et gère la suppression et la recréation des objets de liaison si nécessaire pour modifier le rôle auquel ils se réfèrent.
Voir utilisation de la commande et exemples pour plus d'informations.
Référence aux ressources
Dans l'API Kubernetes, la plupart des ressources sont représentées et accessibles à l'aide d'une chaîne de caractères de leur nom d'objet,
comme pods pour un Pod. RBAC fait référence aux ressources en utilisant exactement
le même nom que celui qui apparaît dans l'URL du endpoint de l'API concerné.
Certaines API Kubernetes impliquent une
sous-ressource, comme les logs d'un Pod. Une requête pour les logs d'un Pod ressemble à ceci :
GET /api/v1/namespaces/{namespace}/pods/{name}/log
Dans ce cas, pods est la ressource à namespace pour les ressources Pods,
et log est une sous-ressource de pods. Pour représenter cela dans un rôle RBAC,
utilisez une barre oblique (/) pour délimiter la ressource et la sous-ressource.
Pour permettre à un sujet de lire pods et d'accéder également à la sous-ressource log pour chacun de ces Pods, vous écrivez :
Vous pouvez également faire référence à des ressources par leur nom pour certaines demandes par le biais de la liste resourceNames.
Lorsque cela est spécifié, les demandes peuvent être limitées à des instances individuelles d'une ressource.
Voici un exemple qui limite son sujet à seulement get ou update une
ConfigMap nommée my-configmap:
apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:namespace:defaultname:configmap-updaterrules:- apiGroups:[""]## at the HTTP level, the name of the resource for accessing ConfigMap# objects is "configmaps"resources:["configmaps"]resourceNames:["my-configmap"]verbs:["update","get"]
Note:
Vous ne pouvez pas restreindre les demandes create ou deletecollection par leur nom de ressource.
Pour create, cette limitation est due au fait que le nom du nouvel objet peut ne pas être connu au moment de l'autorisation.
Si vous limitez list ou watch par le nom de la ressource, les clients doivent inclure un sélecteur de champ metadata.name dans leur demande de list ou watch qui correspond au nom de la ressource spécifiée afin d'être autorisés.
Par exemple, kubectl get configmaps --field-selector=metadata.name=my-configmap
Plutôt que de faire référence à des ressources et des verbes individuels, vous pouvez utiliser le symbole astérisque * pour faire référence à tous ces objets.
Pour les nonResourceURLs, vous pouvez utiliser le symbole astérisque * comme suffixe de correspondance glob et pour les apiGroups et les resourceNames un ensemble vide signifie que tout est autorisé.
Voici un exemple qui autorise l'accès pour effectuer toute action actuelle et future sur toutes les ressources actuelles et futures (remarque, ceci est similaire au rôle cluster-admin intégré).
apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:namespace:defaultname:example.com-superuser # DO NOT USE THIS ROLE, IT IS JUST AN EXAMPLErules:- apiGroups:["example.com"]resources:["*"]verbs:["*"]
Avertissement:
L'utilisation d'astérisques dans les entrées de ressources et de verbes peut entraîner l'octroi d'un accès trop permissif à des ressources sensibles.
Par exemple, si un nouveau type de ressource est ajouté, ou si une nouvelle sous-ressource est ajoutée, ou si un nouveau verbe personnalisé est coché, l'utilisation de l'astérisque accorde automatiquement l'accès, ce qui peut être indésirable.
Le principe du moindre privilège doit être employé, en utilisant des ressources et des verbes spécifiques pour garantir que seules les autorisations nécessaires au bon fonctionnement de la charge de travail sont appliquées.
ClusterRoles agrégés
Vous pouvez agréger plusieurs ClusterRoles en un seul ClusterRole combiné.
Un contrôleur, qui s'exécute dans le cadre du plan de contrôle du cluster, recherche les objets ClusterRole
avec une aggregationRule définie. L'aggregationRule définit un label
selector que le contrôleur
utilise pour faire correspondre d'autres objets ClusterRole qui devraient être combinés dans le champ de règles de celui-ci.
Avertissement:
Le plan de contrôle écrase toutes les valeurs que vous spécifiez manuellement dans le champ rules d'un ClusterRole agrégé.
Si vous souhaitez modifier ou ajouter des règles, faites-le dans les objets ClusterRole
qui sont sélectionnés par l'aggregationRule.
Voici un exemple de ClusterRole agrégé :
apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRolemetadata:name:monitoringaggregationRule:clusterRoleSelectors:- matchLabels:rbac.example.com/aggregate-to-monitoring:"true"rules:[]# The control plane automatically fills in the rules
Si vous créez un nouvel ClusterRole qui correspond au sélecteur d'étiquette d'une ClusterRole
agrégé existant, ce changement déclenche l'ajout des nouvelles règles dans le ClusterRole agrégé.
Voici un exemple qui ajoute des règles au ClusterRole "monitoring", en créant un autre ClusterRole
étiqueté rbac.example.com/aggregate-to-monitoring: true.
apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRolemetadata:name:monitoring-endpointslabels:rbac.example.com/aggregate-to-monitoring:"true"# When you create the "monitoring-endpoints" ClusterRole,# the rules below will be added to the "monitoring" ClusterRole.rules:- apiGroups:[""]resources:["services","endpointslices","pods"]verbs:["get","list","watch"]
Les rôles par défaut destinés aux utilisateurs utilisent l'agrégation ClusterRole. Cela vous permet,
en tant qu'administrateur de cluster, d'inclure des règles pour les ressources personnalisées, telles que celles servies par
CustomResourceDefinitions
ou les serveurs API agrégés, afin d'étendre les rôles par défaut.
Par exemple : les ClusterRoles suivants permettent aux rôles par défaut "admin" et "edit" de gérer la ressource personnalisée
nommée CronTab, tandis que le rôle "view" ne peut effectuer que des actions de lecture sur les ressources CronTab.
Vous pouvez supposer que les objets CronTab sont nommés "crontabs" dans les URLs telles que vues par le serveur API.
apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRolemetadata:name:aggregate-cron-tabs-editlabels:# Add these permissions to the "admin" and "edit" default roles.rbac.authorization.k8s.io/aggregate-to-admin:"true"rbac.authorization.k8s.io/aggregate-to-edit:"true"rules:- apiGroups:["stable.example.com"]resources:["crontabs"]verbs:["get","list","watch","create","update","patch","delete"]---kind:ClusterRoleapiVersion:rbac.authorization.k8s.io/v1metadata:name:aggregate-cron-tabs-viewlabels:# Add these permissions to the "view" default role.rbac.authorization.k8s.io/aggregate-to-view:"true"rules:- apiGroups:["stable.example.com"]resources:["crontabs"]verbs:["get","list","watch"]
Role examples
Les exemples suivants sont des extraits d'objets Role ou ClusterRole,
montrant uniquement la section rules.
Autoriser la lecture des ressources "pods" dans l'
API Group central :
rules:- apiGroups:[""]## at the HTTP level, the name of the resource for accessing Pod# objects is "pods"resources:["pods"]verbs:["get","list","watch"]
Autoriser la lecture/écriture des Déploiements (au niveau HTTP : objets avec "deployments"
dans la partie ressource de leur URL) dans les groupes API "apps" :
rules:- apiGroups:["apps"]## at the HTTP level, the name of the resource for accessing Deployment# objects is "deployments"resources:["deployments"]verbs:["get","list","watch","create","update","patch","delete"]
Autorise la lecture des Pods dans le groupe d'API central, ainsi que de lire ou d'écrire
des ressources Job dans le groupe d'API "batch" :
rules:- apiGroups:[""]## at the HTTP level, the name of the resource for accessing Pod# objects is "pods"resources:["pods"]verbs:["get","list","watch"]- apiGroups:["batch"]## at the HTTP level, the name of the resource for accessing Job# objects is "jobs"resources:["jobs"]verbs:["get","list","watch","create","update","patch","delete"]
Autoriser la lecture d'un ConfigMap nommé "my-config"
(doit être lié avec un RoleBinding pour limiter à un seul ConfigMap dans un seul namespace).
rules:- apiGroups:[""]## at the HTTP level, the name of the resource for accessing ConfigMap# objects is "configmaps"resources:["configmaps"]resourceNames:["my-config"]verbs:["get"]
Autoriser la lecture des ressources "nodes"dans le groupe central (parce
qu'un Nœud est à l'échelle-du-cluster, il doit être dans un ClusterRole
lié à un ClusterRoleBinding pour être effectif) :
rules:- apiGroups:[""]## at the HTTP level, the name of the resource for accessing Node# objects is "nodes"resources:["nodes"]verbs:["get","list","watch"]
Autorise les requêtes GET et POST vers l'endpoint non ressource /healthz et
tous les sous-chemins (doit être dans un ClusterRole lié à un ClusterRoleBinding
pour être effectif) :
rules:- nonResourceURLs:["/healthz","/healthz/*"]# '*' in a nonResourceURL is a suffix glob matchverbs:["get","post"]
Référence à des subjects
Un RoleBinding ou ClusterRoleBinding lie un rôle à des sujets.
Les sujets peuvent être des groupes, des utilisateurs ou des
ServiceAccounts.
Kubernetes représente les noms d'utilisateurs sous forme de chaînes de caractères.
Il peut s'agir: de noms simples, tels que "alice"; de noms de style e-mail, tels que "bob@example.com";
ou des IDs d'utilisateur numériques représentés sous forme de chaîne de caractères. Il vous appartient, en tant qu'administrateur de cluster,
de configurer les modules d'authentification
afin que l'authentification produise des noms d'utilisateur dans le format que vous souhaitez.
Avertissement:
Le préfixe system: est réservé à l'utilisation du système Kubernetes, vous devez donc vous assurer
que vous n'avez pas d'utilisateurs ou de groupes dont le nom commence par system:
par accident.
En dehors de ce préfixe spécial, le système d'autorisation RBAC ne requiert aucun format pour les
noms d'utilisateurs.
Dans Kubernetes, les modules Authenticator fournissent des informations sur les groupes.
Les groupes, comme les utilisateurs, sont représentés sous forme de chaînes de caractères et cette chaîne n'a aucune exigence de format,
si ce n'est que le préfixe system: est réservé.
Les ServiceAccounts ont des noms préfixés par
system:serviceaccount:, et appartiennent à des groupes qui ont des noms préfixés par system:serviceaccounts:.
Note:
system:serviceaccount: (singulier) est le préfixe pour les noms d'utilisateur des comptes de service.
system:serviceaccounts: (pluriel) est le préfixe pour les groupes de comptes de service.
Exemples de RoleBinding
Les exemples suivants sont des extraits de RoleBinding
qui ne montrent que la section des subjects.
Les serveurs API créent un ensemble d'objets ClusterRole et ClusterRoleBinding par défaut.
Beaucoup d'entre eux sont préfixés system:, ce qui indique que la ressource est directement
gérée par le plan de contrôle du cluster.
Tous les ClusterRoles et ClusterRoleBindings par défaut sont étiquetés avec kubernetes.io/bootstrapping=rbac-defaults.
Avertissement:
Faites attention lorsque vous modifiez les ClusterRoles et les ClusterRoleBindings
dont les noms ont un préfixe system:.
Les modifications apportées à ces ressources peuvent entraîner des clusters non fonctionnels.
Auto-reconciliation
À chaque démarrage, le serveur API met à jour les rôles de cluster par défaut avec toutes les permissions manquantes,
et met à jour les liaisons de rôles de cluster par défaut avec tous les sujets manquants.
Cela permet au cluster de réparer les modifications accidentelles, et aide à maintenir les rôles et les liaisons de rôles
à jour lorsque les autorisations et les sujets changent dans les nouvelles versions de Kubernetes.
Pour ne pas participer à cette reconciliation, définissez l'annotation rbac.authorization.kubernetes.io/autoupdate
sur un rôle ou un rolebinding de cluster par défaut sur false.
Sachez que les autorisations et les sujets par défaut manquants peuvent entraîner des clusters non fonctionnels.
L'auto-réconciliation est activée par défaut si l'autorisateur RBAC est actif.
Rôles de détection de l'API
Les liaisons de rôles par défaut autorisent les utilisateurs authentifiés et non authentifiés à lire les informations de l'API qui sont jugées sûres pour être accessibles au public (y compris les CustomResourceDefinitions). Pour désactiver l'accès anonyme non authentifié, ajoutez --anonymous-auth=false à la configuration du serveur d'API.
Pour afficher la configuration de ces rôles via kubectl, exécutez :
kubectl get clusterroles system:discovery -o yaml
Note:
Si vous modifiez ce ClusterRole, vos modifications seront écrasées au redémarrage du serveur API
via l'auto-reconciliation. Pour éviter cet écrasement,
ne modifiez pas manuellement le rôle ou désactivez l'auto-reconciliation.
Rôles de détection de l'API RBAC de Kubernetes
ClusterRole par défaut
ClusterRoleBinding par défaut
Description
system:basic-user
Groupe system:authenticated
Permet à un utilisateur d'accéder en lecture seule aux informations de base le concernant. Avant la v1.14, ce rôle était également lié à system:unauthenticated par défaut.
system:discovery
Groupe system:authenticated
Permet un accès en lecture seule aux points de terminaison de découverte d'API nécessaires pour découvrir et négocier un niveau d'API. Avant la v1.14, ce rôle était également lié à l'option system:unauthenticated par défaut.
system:public-info-viewer
Groupes system:authenticated et system:unauthenticated
Permet un accès en lecture seule à des informations non sensibles sur le cluster. Introduit dans Kubernetes v1.14.
Rôle des utilisateurs
Certains des ClusterRoles par défaut ne sont pas précédés du préfixe system:. Il s'agit de rôles destinés à l'utilisateur.
Ils incluent les rôles de super-utilisateur (cluster-admin), les rôles destinés à être accordés à l'échelle du cluster
à l'aide de ClusterRoleBindings, et les rôles destinés à être accordés dans
des namespaces particuliers à l'aide de RoleBindings (admin, edit, view).
Les ClusterRoles des utilisateurs utilisent l'agrégation de ClusterRole pour permettre aux administrateurs d'inclure
des règles pour les ressources personnalisées sur ces ClusterRoles. Pour ajouter des règles aux rôles admin, edit, ou view, créez
une ClusterRole avec un ou plusieurs des labels suivants :
Permet au super-utilisateur d'effectuer n'importe quelle action sur n'importe quelle ressource.
Lorsqu'il est utilisé dans un ClusterRoleBinding, il donne un contrôle total sur chaque ressource dans le cluster et dans tous les namespaces.
Lorsqu'il est utilisé dans un RoleBinding, il donne un contrôle total sur chaque ressource dans le namespace du role binding, y compris le namespace lui-même.
admin
Aucun
Permet l'accès administrateur, destiné à être accordé au sein d'un espace de nom en utilisant un RoleBinding.
S'il est utilisé dans un RoleBinding, il permet un accès en lecture/écriture à la plupart des ressources d'un namespace,
y compris la possibilité de créer des rôles et des liaisons de rôles dans le namespace.
Ce rôle ne permet pas l'accès en écriture au quota de ressources ou au namespace lui-même.
Ce rôle ne permet pas non plus l'accès en écriture aux EndpointSlices (ou Endpoints) dans les clusters créés
à l'aide de Kubernetes v1.22+. Plus d'informations sont disponibles dans la
section "Accès en écriture pour les EndpointSlices et les Endpoints".
edit
Aucun
Permet l'accès en lecture/écriture à la plupart des objets d'un namespace.
Ce rôle ne permet pas de visualiser ou de modifier les rôles ou les liaisons de rôles.
Cependant, ce rôle permet d'accéder aux Secrets et d'exécuter des Pods comme n'importe quel ServiceAccount
du namespace, il peut donc être utilisé pour obtenir les niveaux d'accès API de n'importe quel ServiceAccount
du namespace. Ce rôle ne permet pas non plus d'accéder en écriture aux EndpointSlices (ou Endpoints) dans
les clusters créés à l'aide de Kubernetes v1.22+. Plus d'informations sont disponibles dans la
section "Write Access for EndpointSlices and Endpoints".
view
Aucun
Permet un accès en lecture seule pour voir la plupart des objets d'un namespace.
Il ne permet pas de visualiser les rôles ou les liens entre les rôles.
Ce rôle ne permet pas de visualiser les Secrets, car la lecture du contenu
des Secrets permet d'accéder aux informations d'identification du ServiceAccount dans le namespace,
ce qui permettrait d'accéder à l'API en tant que tout ServiceAccount dans l'espace de noms (une forme d'escalade des privilèges).
Ce rôle ne permet pas de consulter les secrets, car la lecture
du contenu des secrets permet d'accéder aux informations d'identification du ServiceAccount dans le namespace,
ce qui permettrait d'accéder à l'API en tant que n'importe quel ServiceAccount
dans le namespace (une forme d'escalade des privilèges).
Rôles des composants de base
ClusterRole par défaut
ClusterRoleBinding par défaut
Description
system:kube-scheduler
Utilisateur system:kube-scheduler
Permet l'accès aux ressources requises par le composant scheduler.
system:volume-scheduler
Utilisateur system:kube-scheduler
Permet l'accès aux ressources de volume requises par le composant kube-scheduler.
system:kube-controller-manager
utilisateur system:kube-controller-manager
Permet l'accès aux ressources requises par le composant gestionnaire de contrôleur.
Les autorisations requises par les contrôleurs individuels sont détaillées dans les rôles des contrôleurs.
system:node
Aucun
Permet l'accès aux ressources requises par le kubelet, y compris l'accès en lecture à tous les secrets, et l'accès en écriture à tous les objets d'état des pods.
Vous devriez utiliser le Node authorizer et le plugin d'admission NodeRestriction au lieu du rôle system:node, et autoriser l'octroi d'un accès API aux kubelets en fonction des Pods programmés pour s'exécuter sur eux.
Le rôle system:node n'existe que pour la compatibilité avec les clusters Kubernetes mis à niveau à partir de versions antérieures à la v1.8.
system:node-proxier
Utilisateur system:kube-proxy
Permet l'accès aux ressources requises par le composant kube-proxy.
Autres rôles des composants
Default ClusterRole
Default ClusterRoleBinding
Description
system:auth-delegator
Aucun
Permet de déléguer les contrôles d'authentification et d'autorisation.
Il est couramment utilisé par les serveurs API complémentaires pour l'authentification et l'autorisation unifiées.
Autorise l'accès en lecture aux endpoints de monitoring du control-plane (c'est-à-dire les endpoints kube-apiserver liveness and readiness (/healthz, /livez, /readyz), les endpoints de contrôle de l'état individuel (/healthz/*, /livez/*, /readyz/*), et /metrics). Il convient de noter que les endpoints des contrôles de l'état individuel et les endpoints des mesures peuvent exposer des informations sensibles.
Rôles des contrôleurs intégrés
Le gestionnaire de contrôleurs Kubernetes exécute
les contrôleurs qui sont intégrés au plan de contrôle Kubernetes.
Lorsqu'il est invoqué --use-service-account-credentials, kube-controller-manager démarre chaque contrôleur
en utilisant un compte de service distinct.
Des rôles correspondants existent pour chaque contrôleur intégré, préfixés par system:controller:.
Si le gestionnaire de contrôleur n'est pas démarré avec --use-service-account-credentials, il exécute toutes les boucles de contrôle
en utilisant ses propres informations d'identification, qui doivent se voir attribuer tous les rôles pertinents.
Ces rôles sont les suivants :
Prévention de l'escalade des privilèges et bootstrapping
L'API RBAC empêche les utilisateurs d'escalader les privilèges en modifiant les rôles ou les liaisons de rôles.
Cette interdiction étant appliquée au niveau de l'API, elle s'applique même lorsque l'autorisateur RBAC n'est pas utilisé.
Restrictions à la création ou à la mise à jour des rôles
Vous ne pouvez créer/mettre à jour un rôle que si au moins l'une des choses suivantes est vraie :
Vous disposez déjà de toutes les autorisations contenues dans le rôle, à la même échelle que l'objet en cours de modification
(à l'échelle du cluster pour un ClusterRole, dans le même namespace ou à l'échelle du cluster pour un Role).
Vous avez l'autorisation explicite d'exécuter le verbe escalader sur la ressource roles ou clusterroles dans le groupe API rbac.authorization.k8s.io.
Par exemple, si l'user-1 n'a pas la possibilité de lister les Secrets à l'échelle du cluster, il ne peut pas créer un ClusterRole
contenant cette permission. Pour permettre à un utilisateur de créer/mettre à jour des rôles :
Attribuez-leur un rôle qui leur permet de créer/mettre à jour des objets Role ou ClusterRole, selon leurs besoins.
Leur accorder la permission d'inclure des autorisations spécifiques dans les rôles qu'ils créent/mettent à jour :
implicitement, en leur accordant ces autorisations (s'ils tentent de créer ou de modifier un Role ou un ClusterRole avec des autorisations qui ne leur ont pas été accordées, la demande d'API sera interdite)
ou explicitement, en leur donnant la permission de spécifier n'importe quelle permission dans un Role ou un ClusterRole, en leur donnant la permission d'exécuter le verbe escalader sur les roles ou les ressources clusterroles dans le groupe API rbac.authorization.k8s.io.
Restrictions à la création ou à la mise à jour de l'attribution de rôles
Vous ne pouvez créer/mettre à jour un lien de rôle que si vous disposez déjà de toutes les autorisations contenues dans le rôle référencé
(à la même portée que le lien de rôle) ou si vous avez été autorisé à exécuter le verbe bind sur le rôle référencé.
Par exemple, si l'user-1 n'a pas la possibilité de lister les Secrets à l'échelle du cluster, il ne peut pas créer un ClusterRoleBinding
pour un rôle qui accorde cette permission. Pour permettre à un utilisateur de créer/mettre à jour des liaisons de rôle :
Accordez-leur un rôle qui leur permet de créer/mettre à jour des objets RoleBinding ou ClusterRoleBinding, selon leurs besoins.
Leur accorder les autorisations nécessaires pour lier un rôle particulier :
implicitement, en leur donnant les permissions contenues dans le rôle.
explicitement, en leur donnant la permission d'exécuter le verbe bind sur le rôle particulier (ou ClusterRole).
Par exemple, ce ClusterRole et ce RoleBinding permettraient à user-1 d'accorder à d'autres utilisateurs les rôles admin, edit et view dans l'espace de noms user-1-namespace :
apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRolemetadata:name:role-grantorrules:- apiGroups:["rbac.authorization.k8s.io"]resources:["rolebindings"]verbs:["create"]- apiGroups:["rbac.authorization.k8s.io"]resources:["clusterroles"]verbs:["bind"]# omit resourceNames to allow binding any ClusterRoleresourceNames:["admin","edit","view"]---apiVersion:rbac.authorization.k8s.io/v1kind:RoleBindingmetadata:name:role-grantor-bindingnamespace:user-1-namespaceroleRef:apiGroup:rbac.authorization.k8s.iokind:ClusterRolename:role-grantorsubjects:- apiGroup:rbac.authorization.k8s.iokind:Username:user-1
Lors du démarrage des premiers rôles et des premières liaisons de rôles, il est nécessaire d'accorder à l'utilisateur initial des autorisations qu'il n'a pas encore.
Pour amorcer les premiers rôles et les premières liaisons de rôles :
Utilisez un identifiant avec le groupe "system:masters", qui est lié au rôle de super-utilisateur "cluster-admin" par les liaisons par défaut.
Utilitaires de ligne de commande
kubectl create role
Crée un objet Rôle définissant les autorisations au sein d'un espace de noms unique. Exemples :
Créer un rôle nommé "pod-reader" qui permet aux utilisateurs d'effectuer les opérations get, watch et list sur les pods :
kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
Créer un rôle nommé "pod-reader" avec les resourceNames spécifiés:
kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
Créer un rôle nommé "foo" avec les apiGroups spécifiés:
kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
Créer un rôle nommé "foo" avec des permissions de sous-ressources:
kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
Créer un rôle nommé "my-component-lease-holder" avec des permissions pour obtenir/mettre à jour une ressource avec un nom spécifique:
kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component
kubectl create clusterrole
Crée un ClusterRole. Exemples:
Créer un ClusterRole nommé "pod-reader" qui permet à l'utilisateur d'effectuer les opérations get, watch et list sur les pods :
Crée ou met à jour les objets de l'API rbac.authorization.k8s.io/v1 à partir d'un fichier manifeste.
Les objets manquants sont créés et le namespace contenant est créé pour les objets à namespace, si nécessaire.
Les rôles existants sont mis à jour pour inclure les autorisations dans les objets d'entrée,
et supprimer les permissions supplémentaires si --remove-extra-permissions est spécifiée.
Les liaisons existantes sont mises à jour pour inclure les sujets dans les objets d'entrée,
et supprimer les sujets supplémentaires si --remove-extra-subjects est spécifiée.
Exemples:
Test d'application d'un fichier manifeste d'objets RBAC, avec affichage des modifications apportées:
Appliquer un fichier manifeste d'objets RBAC, en préservant toutes les autorisations supplémentaires (dans les rôles) et tous les sujets supplémentaires (dans les liaisons):
kubectl auth reconcile -f my-rbac-rules.yaml
Appliquer un fichier manifeste d'objets RBAC, en supprimant toutes les autorisations supplémentaires (dans les rôles) et tous les sujets supplémentaires (dans les liaisons) :
Les règles RBAC par défaut accordent des autorisations aux composants du plan de contrôle, aux nœuds
et aux contrôleurs, mais n'accordent aucunes permissions aux comptes de service en dehors du namespace kube-system
(au-delà des autorisations de découverte accordées à tous les utilisateurs authentifiés).
Cela vous permet d'attribuer des rôles particuliers à des ServiceAccounts particuliers en fonction des besoins.
Des attributions de rôles plus fines offrent une plus grande sécurité, mais demandent plus d'efforts de gestion.
Des attributions plus larges peuvent donner un accès API inutile (et potentiellement escaladant) aux ServiceAccounts,
mais elles sont plus faciles à administrer.
Dans l'ordre, de la plus sûre à la moins sûre, les approches sont les suivantes:
Attribuer un rôle à un compte de service spécifique à une application (meilleure pratique)
Cela nécessite que l'application spécifie un serviceAccountName dans son pod spec,
et que le compte de service soit créé (via l'API, le manifeste de l'application, kubectl create serviceaccount, etc.).
Par exemple, accorder au compte de service "my-sa" l'autorisation de lecture seule dans "my-namespace":
Attribuer un rôle au compte de service "par défaut" dans un namespace
Si une application ne spécifie pas de serviceAccountName, elle utilise le compte de service "par défaut".
Note:
Les autorisations accordées au compte de service "par défaut" sont disponibles pour tout pod
dans le namespace qui ne spécifie pas de `serviceAccountName`.
Par exemple, accorder au compte de service "default" l'autorisation de lecture seule dans "my-namespace" :
De nombreux modules complémentaires s'exécutent sous
le compte de service "default" dans le namespace du kube-system.
Pour permettre à ces modules complémentaires de fonctionner avec un accès de super-utilisateur, accordez les permissions cluster-admin
au compte de service "default" dans le namespace kube-system.
Avertissement:
Activer cela signifie que le namespace `kube-system `contient des Secrets
qui accordent un accès de super-utilisateur à l'API de votre cluster.
Attribuer un rôle à tous les comptes de service d'un namespace
Si vous souhaitez que toutes les applications d'un namespace disposent d'un rôle, quel que soit le compte de service qu'elles utilisent,
vous pouvez attribuer un rôle au groupe de comptes de service de cet namespace.
Par exemple, accordez l'autorisation de lecture seule dans "my-namespace" à tous les comptes de service de cet namespace:
Accorder un accès de super-utilisateur à tous les comptes de service à l'échelle du cluster (fortement déconseillé).
Si vous ne vous souciez pas du tout des autorisations de partitionnement, vous pouvez accorder un accès de super-utilisateur à tous les comptes de service.
Avertissement:
Cela permet à n'importe quelle application d'avoir un accès complet à votre cluster, et accorde
également à n'importe quel utilisateur ayant un accès en lecture à Secrets (ou la possibilité de créer n'importe quel pod)
un accès complet à votre cluster.
Accès en écriture pour les EndpointSlices et les Endpoints
Les clusters Kubernetes créés avant Kubernetes v1.22 incluent un accès en écriture à
EndpointSlices (et Endpoints) dans les rôles agrégés "edit" et "admin".
Pour pallier à la CVE-2021-25740,
cet accès ne fait pas partie des rôles agrégés dans les clusters que vous créez
à l'aide de Kubernetes v1.22 ou ultérieur.
Les clusters existants qui ont été mis à niveau vers Kubernetes v1.22 ne seront pas soumis à ce changement.
L'annonce du CVE
comprend des recommandations pour restreindre cet accès dans les clusters existants.
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 :
apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRolemetadata:annotations:kubernetes.io/description:|- Add endpoints write permissions to the edit and admin roles. This was
removed by default in 1.22 because of CVE-2021-25740. See
https://issue.k8s.io/103675. This can allow writers to direct LoadBalancer
or Ingress implementations to expose backend IPs that would not otherwise
be accessible, and can circumvent network policies or security controls
intended to prevent/isolate access to those backends.
EndpointSlices were never included in the edit or admin roles, so there
is nothing to restore for the EndpointSlice API.labels:rbac.authorization.k8s.io/aggregate-to-edit:"true"name:custom:aggregate-to-edit:endpoints# you can change this if you wishrules:- apiGroups:[""]resources:["endpoints"]verbs:["create","delete","deletecollection","patch","update"]
Mise à niveau à partir d'ABAC
Les clusters qui exécutaient à l'origine d'anciennes versions de Kubernetes utilisaient
souvent des politiques ABAC permissives, notamment en accordant un accès API complet
à tous les comptes de service.
Les règles RBAC par défaut accordent des autorisations étendues aux composants du plan de contrôle, aux nœuds
et aux contrôleurs, mais n'accordent aucune autorisation aux comptes de service en dehors du namespace kube-system
(au-delà des autorisations de découverte accordées à tous les utilisateurs authentifiés).
Bien que beaucoup plus sûre, cette solution peut perturber les charges de travail existantes qui s'attendent à recevoir automatiquement les autorisations de l'API.
Voici deux approches pour gérer cette transition:
Autorisateurs parallèles
Exécutez les autorisateurs RBAC et ABAC, et spécifiez un fichier de stratégie qui contient
la stratégie ABAC existante:
Pour expliquer en détail la première option de ligne de commande : si les autorisateurs précédents, tels que Node,
refusent une demande, l'autorisateur RBAC tente d'autoriser la demande d'API. Si RBAC
refuse également cette demande d'API, l'Authorizer ABAC est alors exécuté. Cela signifie que toute demande
autorisée par les stratégies RBAC ou ABAC est autorisée.
Lorsque kube-apiserver est exécuté avec un niveau de log de 5 ou plus pour le composant RBAC
(--vmodule=rbac*=5 ou --v=5), vous pouvez voir les refus RBAC dans le log du serveur API
(préfixé par RBAC).
Vous pouvez utiliser ces informations pour déterminer quels rôles doivent être accordés à quels utilisateurs, groupes ou comptes de service.
Une fois que vous avez accordé des rôles aux comptes de service et que les charges de travail
fonctionnent sans message de refus RBAC dans les journaux du serveur, vous pouvez supprimer l'ABAC Authorizer.
Autorisations RBAC permissives
Vous pouvez répliquer une stratégie ABAC permissive à l'aide de liaisons de rôles RBAC.
Avertissement:
La politique suivante permet à TOUS les comptes de service d'agir en tant qu'administrateurs de cluster.
Toute application s'exécutant dans un conteneur reçoit automatiquement
les informations d'identification du compte de service et peut effectuer n'importe quelle action sur l'API, y compris l'affichage des secrets et la modification des autorisations.
Cette stratégie n'est pas recommandée.
Après la transition vers l'utilisation de RBAC, vous devez ajuster les contrôles
d'accès pour votre cluster afin de vous assurer qu'ils répondent à vos besoins en matière de sécurité de l'information.
5 - Référence de l'API
6 - Référence des outils d'installation
6.1 - Kubeadm
6.1.1 - Aperçu de kubeadm
Kubeadm est un outil conçu afin que les commandes kubeadm init et kubeadm join soient la meilleure façon de créer rapidement des clusters Kubernetes.
Kubeadm effectue les actions nécessaires afin d'obtenir un cluster minimal mais fonctionnel et en état de marche. Son objectif est d'assembler le cluster sans pour autant provisioner les machines qui le composent. De la même façon, kubeadm ne supporte pas l'installation des extensions habituelles comme le Dashboard (tableau de bord), les solutions de surveillance ou bien encore les extensions spécifiques aux fournisseurs cloud.
On préférera des outils plus spécifiques et de plus haut niveau, construits autour de kubeadm, et qui, idéalement, utiliseront kubeadm comme base de déploiement afin de créer facilement des clusters conformes.
Prochaines étapes
kubeadm init pour assembler un noeud Kubernetes control-plane
kubeadm join pour assembler un noeud Kubernetes worker node et le joindre au cluster
kubeadm upgrade pour mettre à jour un cluster Kubernetes vers une version plus récente
kubeadm config si vous avez initialisé votre cluster en utilisant kubeadm v1.7.x ou antérieur, pour configurer votre cluster avec kubeadm upgrade
kubeadm token pour gérer vos jetons avec kubeadm join
kubeadm reset pour annuler des changements faits avec kubeadm init ou kubeadm join à cet hôte
kubeadm alpha pour utiliser un lot de fonctionnalités rendus disponibles afin d'obtenir le retour de la communauté
6.1.2 - Kubeadm généré
6.1.2.1 -
Utilisez cette commande afin de configurer le control plane Kubernetes
Synopsis
Utilisez cette commande afin de configurer le control plane Kubernetes
La commande "init" exécute les phases suivantes :
preflight Exécute les vérifications en amont
kubelet-start Sauvegarde les réglages kubelet et (re)démarre kubelet
certs Génération de certificats
/etcd-ca Génère le certificat CA auto signé pour fournir les identités à etcd
/apiserver-etcd-client Génère le certificat que l'apiserver utilisera pour communiquer avec etcd
/etcd-healthcheck-client Génère le certificat pour les sondes de vivacité (liveness) qui contrôlent etcd
/etcd-server Génère le certificat pour l'accès à etcd
/etcd-peer Génère le certificat pour que les noeuds etcd puissent communiquer ensemble
/ca Génère le certificat CA auto signé de Kubernetes pour fournir les identités aux autres composants Kubernetes
/apiserver Génère le certificat pour l'accès à l'API Kubernetes
/apiserver-kubelet-client Génère le certificat pour permettre à l'API server de se connecter à kubelet
/front-proxy-ca Génère le certificat CA auto signé pour fournir les identités au proxy frontal (front proxy)
/front-proxy-client Génère le certificat pour le client du proxy frontal
/sa Génère une clef privée pour signer les jetons ainsi que la clef publique du compte service
kubeconfig Génère tous les fichiers kubeconfig nécessaires pour la création du control plane et du fichier kubeconfig admin
/admin Génère un fichier kubeconfig pour utilisation par l'administrateur et kubeadm
/kubelet Génère un fichier kubeconfig pour utilisation par kubelet seulement à des fins d'installation initiale
/controller-manager Génère un fichier fichier kubeconfig for the controller manager to use
/scheduler Génère un fichier kubeconfig pour utilisation par le scheduler
control-plane Génère tous les manifests de Pod statiques nécessaires à la création du control plane
/apiserver Génère le manifest de Pod statique de l'apiserver
/controller-manager Génère le manifest de Pod statique du kube-controller-manager
/scheduler Génère le manifest de Pod statique du kube-schedule
etcd Génère le manifest de Pod statique pour l'etcd local
/local Génère le manifest de Pod statique pour une instance etcd locale, à un seul noeud
upload-config Téléverse les configurations kubeadm et kubelet vers une ConfigMap
/kubeadm Téléverse la ClusterConfiguration de kubeadm vers une ConfigMap
/kubelet Téléverse la configuration kubelet vers une ConfigMap
upload-certs Téléverse les certificats vers kubeadm-certs
mark-control-plane Marque un noeud en tant que control-plane
bootstrap-token Génère les jetons d'installation utilisés pour faire joindre un noeud à un cluster
addon Installe les extensions requises pour l'exécution des tests de Conformance
/coredns Installe l'extension CoreDNS à un cluster Kubernetes
/kube-proxy Installe l'extension kube-proxy à un cluster Kubernetes
kubeadm init [flags]
Options
--apiserver-advertise-address string L'adresse IP que l'API Server utilisera pour s'annoncer. Si non spécifiée, l'interface réseau par défaut sera utilisée.
--apiserver-bind-port int32 Port d'écoute de l'API Server. (par default 6443)
--apiserver-cert-extra-sans strings Noms alternatifs (Subject Alternative Names ou encore SANs) optionnels, utilisés dans les certificats servis par l'API Server. Peuvent êtres des adresses IPs ou des noms DNS.
--cert-dir string Le répertoire où sauvegarder les certificats. (par défaut "/etc/kubernetes/pki")
--certificate-key string Clef utilisée pour chiffrer les certificats control-plane dans le Secret the kubeadm-certs.
--config string Chemin vers un fichier de configuration kubeadm.
--cri-socket string Chemin vers la socket CRI à laquelle la connexion doit s'effectuer. S'il n'est pas spécifié, kubeadm essaiera de le détecter; utiliser cette option seulement si vous avez plus d'un CRI installé ou si vous utilisez des sockets CRI non standard.
--dry-run N'effectue aucun changement; affiche seulement la sortie standard de ce qui serait effectué.
--feature-gates string Un ensemble de paires clef=valeur qui décrivent l'entrée de configuration pour des fonctionnalités diverses. Il n'y en a aucune dans cette version.
-h, --help aide pour l'initialisation (init)
--ignore-preflight-errors strings Une liste de contrôles dont les erreurs seront catégorisées comme "warnings" (avertissements). Par exemple : 'IsPrivilegedUser,Swap'. La valeur 'all' ignore les erreurs de tous les contrôles.
--image-repository string Choisis un container registry d'où télécharger les images du control plane. (par défaut "registry.k8s.io")
--kubernetes-version string Choisis une version Kubernetes spécifique pour le control plane. (par défaut "stable-1")
--node-name string Spécifie le nom du noeud.
--pod-network-cidr string Spécifie l'intervalle des adresses IP pour le réseau des pods. Si fournie, le control plane allouera automatiquement les CIDRs pour chacun des noeuds.
--service-cidr string Utilise un intervalle différent pour les adresses IP des services prioritaires (VIPs). (par défaut "10.96.0.0/12")
--service-dns-domain string Utilise un domaine alternatif pour les services, par exemple : "myorg.internal". (par défaut "cluster.local")
--skip-certificate-key-print N'affiche pas la clef utilisée pour chiffrer les certificats du control-plane.
--skip-phases strings List des des phases à sauter
--skip-token-print N'affiche pas le jeton par défaut de l'installation qui a été généré lors de 'kubeadm init'.
--token string Le jeton à utiliser pour établir la confiance mutuelle entre les noeuds et les noeuds du control-plane. Le format correspond à la regexp : [a-z0-9]{6}\.[a-z0-9]{16} - par exemple : abcdef.0123456789abcdef
--token-ttl duration La durée au bout de laquelle le jeton sera automatiquement détruit (par exemple : 1s, 2m, 3h). Si réglée à '0', le jeton n'expirera jamais (par défaut 24h0m0s)
--upload-certs Téléverse les certificats du control-plane vers le Secret kubeadm-certs.
Options héritées depuis la commande parent
--rootfs string [EXPERIMENTALE] Le chemin vers la "vraie" racine du système de fichiers de l'hôte.
6.1.3 - kubeadm init
Cette commande initialise un noeud Kubernetes control-plane.
Utilisez cette commande afin de configurer le control plane Kubernetes
Synopsis
Utilisez cette commande afin de configurer le control plane Kubernetes
La commande "init" exécute les phases suivantes :
preflight Exécute les vérifications en amont
kubelet-start Sauvegarde les réglages kubelet et (re)démarre kubelet
certs Génération de certificats
/etcd-ca Génère le certificat CA auto signé pour fournir les identités à etcd
/apiserver-etcd-client Génère le certificat que l'apiserver utilisera pour communiquer avec etcd
/etcd-healthcheck-client Génère le certificat pour les sondes de vivacité (liveness) qui contrôlent etcd
/etcd-server Génère le certificat pour l'accès à etcd
/etcd-peer Génère le certificat pour que les noeuds etcd puissent communiquer ensemble
/ca Génère le certificat CA auto signé de Kubernetes pour fournir les identités aux autres composants Kubernetes
/apiserver Génère le certificat pour l'accès à l'API Kubernetes
/apiserver-kubelet-client Génère le certificat pour permettre à l'API server de se connecter à kubelet
/front-proxy-ca Génère le certificat CA auto signé pour fournir les identités au proxy frontal (front proxy)
/front-proxy-client Génère le certificat pour le client du proxy frontal
/sa Génère une clef privée pour signer les jetons ainsi que la clef publique du compte service
kubeconfig Génère tous les fichiers kubeconfig nécessaires pour la création du control plane et du fichier kubeconfig admin
/admin Génère un fichier kubeconfig pour utilisation par l'administrateur et kubeadm
/kubelet Génère un fichier kubeconfig pour utilisation par kubelet seulement à des fins d'installation initiale
/controller-manager Génère un fichier fichier kubeconfig for the controller manager to use
/scheduler Génère un fichier kubeconfig pour utilisation par le scheduler
control-plane Génère tous les manifests de Pod statiques nécessaires à la création du control plane
/apiserver Génère le manifest de Pod statique de l'apiserver
/controller-manager Génère le manifest de Pod statique du kube-controller-manager
/scheduler Génère le manifest de Pod statique du kube-schedule
etcd Génère le manifest de Pod statique pour l'etcd local
/local Génère le manifest de Pod statique pour une instance etcd locale, à un seul noeud
upload-config Téléverse les configurations kubeadm et kubelet vers une ConfigMap
/kubeadm Téléverse la ClusterConfiguration de kubeadm vers une ConfigMap
/kubelet Téléverse la configuration kubelet vers une ConfigMap
upload-certs Téléverse les certificats vers kubeadm-certs
mark-control-plane Marque un noeud en tant que control-plane
bootstrap-token Génère les jetons d'installation utilisés pour faire joindre un noeud à un cluster
addon Installe les extensions requises pour l'exécution des tests de Conformance
/coredns Installe l'extension CoreDNS à un cluster Kubernetes
/kube-proxy Installe l'extension kube-proxy à un cluster Kubernetes
kubeadm init [flags]
Options
--apiserver-advertise-address string L'adresse IP que l'API Server utilisera pour s'annoncer. Si non spécifiée, l'interface réseau par défaut sera utilisée.
--apiserver-bind-port int32 Port d'écoute de l'API Server. (par default 6443)
--apiserver-cert-extra-sans strings Noms alternatifs (Subject Alternative Names ou encore SANs) optionnels, utilisés dans les certificats servis par l'API Server. Peuvent êtres des adresses IPs ou des noms DNS.
--cert-dir string Le répertoire où sauvegarder les certificats. (par défaut "/etc/kubernetes/pki")
--certificate-key string Clef utilisée pour chiffrer les certificats control-plane dans le Secret the kubeadm-certs.
--config string Chemin vers un fichier de configuration kubeadm.
--cri-socket string Chemin vers la socket CRI à laquelle la connexion doit s'effectuer. S'il n'est pas spécifié, kubeadm essaiera de le détecter; utiliser cette option seulement si vous avez plus d'un CRI installé ou si vous utilisez des sockets CRI non standard.
--dry-run N'effectue aucun changement; affiche seulement la sortie standard de ce qui serait effectué.
--feature-gates string Un ensemble de paires clef=valeur qui décrivent l'entrée de configuration pour des fonctionnalités diverses. Il n'y en a aucune dans cette version.
-h, --help aide pour l'initialisation (init)
--ignore-preflight-errors strings Une liste de contrôles dont les erreurs seront catégorisées comme "warnings" (avertissements). Par exemple : 'IsPrivilegedUser,Swap'. La valeur 'all' ignore les erreurs de tous les contrôles.
--image-repository string Choisis un container registry d'où télécharger les images du control plane. (par défaut "registry.k8s.io")
--kubernetes-version string Choisis une version Kubernetes spécifique pour le control plane. (par défaut "stable-1")
--node-name string Spécifie le nom du noeud.
--pod-network-cidr string Spécifie l'intervalle des adresses IP pour le réseau des pods. Si fournie, le control plane allouera automatiquement les CIDRs pour chacun des noeuds.
--service-cidr string Utilise un intervalle différent pour les adresses IP des services prioritaires (VIPs). (par défaut "10.96.0.0/12")
--service-dns-domain string Utilise un domaine alternatif pour les services, par exemple : "myorg.internal". (par défaut "cluster.local")
--skip-certificate-key-print N'affiche pas la clef utilisée pour chiffrer les certificats du control-plane.
--skip-phases strings List des des phases à sauter
--skip-token-print N'affiche pas le jeton par défaut de l'installation qui a été généré lors de 'kubeadm init'.
--token string Le jeton à utiliser pour établir la confiance mutuelle entre les noeuds et les noeuds du control-plane. Le format correspond à la regexp : [a-z0-9]{6}\.[a-z0-9]{16} - par exemple : abcdef.0123456789abcdef
--token-ttl duration La durée au bout de laquelle le jeton sera automatiquement détruit (par exemple : 1s, 2m, 3h). Si réglée à '0', le jeton n'expirera jamais (par défaut 24h0m0s)
--upload-certs Téléverse les certificats du control-plane vers le Secret kubeadm-certs.
Options héritées depuis la commande parent
--rootfs string [EXPERIMENTALE] Le chemin vers la "vraie" racine du système de fichiers de l'hôte.
Séquence d'initialisation
kubeadm init assemble un noeud Kubernetes control-plane en effectuant les étapes suivantes :
Exécute une série de contrôles pour valider l'état du système avant d'y apporter des changements.
Certaines validations peuvent émettre seulement des avertissements (warnings),
d'autres peuvent générer des erreurs qui forceront l'interruption de kubeadm
jusqu'à ce que le problème soit résolu
ou jusqu'à ce que l'utilisateur spécifie --ignore-preflight-errors=<list-des-erreurs>.
Génère une autorité de certification (CA) auto signée (ou utilise une existante si spécifiée) pour
installer les identités de chaque composant du cluster. Si l'utilisateur a fourni son propre certificat
et/ou clef de CA en le (la) copiant dans le répertoire des certificats, configuré avec --cert-dir
(/etc/kubernetes/pki par défaut) cette étape est sautée comme expliqué dans le document
utiliser ses propres certificats.
Les certificats de l'API Server auront des entrées SAN additionnelles pour chaque argument --apiserver-cert-extra-sans.
Ecrit les fichiers kubeconfig dans /etc/kubernetes/ pour
kubelet, le controller-manager et l'ordonnanceur (scheduler)
qui seront utlisés pour les connexions à l'API server, chacun avec sa propre identité,
ainsi qu'un fichier kubeconfig supplémentaire pour l'administration, nommé admin.conf.
Génère des manifestes statiques de Pod pour l'API server,
le controller manager et l'ordonnanceur. Au cas où aucun etcd externe n'est fourni,
un manifeste statique de Pod pour etcd est généré.
Les manifestes statiques de Pod sont écrits dans /etc/kubernetes/manifestes;
kubelet surveille ce répertoire afin que les Pods soient créés au démarrage.
Dès lors que les pods de control-plane sont démarrés, la séquence de kubeadm init peut alors continuer.
Applique les étiquettes (labels) et marques (taints) au noeud control-plane afin qu'aucune charge de travail additionnelle ne s'y exécute.
Génère le jeton que les noeuds additionnels peuvent utiliser pour s'enregistrer avec un control-plane. Il est possible que l'utilisateur fournisse un jeton en utilisant --token,
comme décrit dans la documentation à propos du jeton kubeadm.
Produit tous les fichiers de configuration requis pour autoriser les noeuds à rejoindre le cluster avec les
jetons d'assemblage et le mécanisme
d'assemblage TLS :
Ecrit une ConfigMap pour produire toute la configuration nécessaire
pour rejoindre le cluster et installer les règles d'accès RBAC sous jacentes.
Permet aux jetons d'assemblage d'accéder à l'API CSR (Certificate Signing Request, requête de signature de certificat).
Configure l'acceptation automatique des nouvelles requêtes CSR.
Voir kubeadm join pour de l'information complémentaire.
Installe un serveur DNS (CoreDNS) et les modules de l'extension kube-proxy en utilisant l'API Server.
Dans la version 1.11 (et au delà) de Kubernetes, CoreDNS est le serveur DNS par défaut.
Pour installer kube-dns au lieu de CoreDNS, l'extension DNS doit être configurée dans la ClusterConfiguration de kubeadm.
Pour plus d'information, se référer à la section ci-dessous intitulée :
Utiliser kubeadm init avec un fichier de configuration.
Vous remarquerez que bien que le serveur DNS soit déployé, il ne sera pas programmé pour exécution avant que le CNI soit installé.
Utiliser les phases d'initialisation avec kubeadm
Kubeadm vous permet de créer un noeud de type control-plane en plusieurs phases. Dans 1.13 la commande kubeadm init phase a été promue GA (disponibilité générale) alors que précédemment ce n'était qu'une commande alpha : kubeadm alpha phase.
Pour voir la liste des phases et sous phases dans l'ordre, vous pouvez utiliser kubeadm init --help. La liste sera affichée en haut de l'écran d'aide et chaque phase aura une description associée.
Bon à savoir : en appelant kubeadm init toutes les phases et sous phases seront executées dans cet ordre.
Certaines phases ont des options uniques, si vous désirez consulter la liste de ces options, ajoutez --help, par exemple :
Vous pouvez aussi utiliser --help pour voir la liste des sous-phases pour une phase parent :
sudo kubeadm init phase control-plane --help
kubeadm init a aussi une option nommée --skip-phases qui peut être utilisée pour passer outre. Cette option accepte une liste de noms de phases, qui peuvent être retrouvées à partir de la liste ordonée précédente.
Par exemple :
sudo kubeadm init phase control-plane all --config=configfile.yaml
sudo kubeadm init phase etcd local --config=configfile.yaml
# vous pouvez modifier les fichiers manifestes du control-plane et d'etcdsudo kubeadm init --skip-phases=control-plane,etcd --config=configfile.yaml
Cet exemple écrirait les fichiers manifestes pour le control plane et etcd dans /etc/kubernetes/manifestes à partir de la configuration dans configfile.yaml. Cela permet de modifier les fichiers et d'ensuite sauter ces phases en utilisant --skip-phases. En invoquant la dernière commande, vous créerez un noeud de type control plane avec les les fichiers manifestes personnalisés.
Utiliser kubeadm init avec un fichier de configuration
Avertissement:
L'utilisation d'un fichier de configuration est toujours considérée beta et le format du fichier pourrait changer dans les prochaines versions.
C'est possible de configurer kubeadm init avec un fichier de configuration plutôt qu'avec des options en ligne de commande, et certaines fonctionnalités avancées sont d'ailleurs uniquement disponibles en tant qu'options du fichier de configuration. Ce fichier est passé à kubeadm avec l'option --config.
Dans Kubernetes 1.11 et au delà, la configuration par défaut peut être affichée en utilisant la commande
kubeadm config print.
Il est recommandé que vous migriez votre configuration v1alpha3 vers v1beta1 en utilisant
la commande kubeadm config migrate,
car le support de v1alpha3 sera supprimé dans Kubernetes 1.15.
Pour plus de détails à propos de chaque option de la configuration v1beta1 vous pouvez consulter la
référence de l'API.
Ajouter des paramètres kube-proxy
Pour de l'information à propos des paramètres kube-proxy dans la configuration kubeadm, se référer à :
kube-proxy
Pour de l'information sur comment activer le mode IPVS avec kubeadm, se référer à :
IPVS
Passer des options personnalisées aux composants du control plane
Pour de l'information sur comment passer des options aux composants du control plane, se référer à :
control-plane-flags
Utiliser des images personnalisées
Par défaut, kubeadm télécharge les images depuis registry.k8s.io, à moins que la version demandée de Kubernetes soit une version Intégration Continue (CI). Dans ce cas, gcr.io/k8s-staging-ci-images est utilisé.
fournir un imageRepository à utiliser à la place de registry.k8s.io.
régler useHyperKubeImage à true pour utiliser l'image HyperKube.
fournir un imageRepository et un imageTag pour etcd et l'extension (add-on) DNS.
Notez que le champ de configurtation kubernetesVersion ou l'option ligne de commande --kubernetes-version affectent la version des images.
Utiliser des certificats personnalisés
Par défaut, kubeadm génère tous les certificats requis pour que votre cluster fonctionne.
Vous pouvez outrepasser ce comportement en fournissant vos propres certificats.
Pour ce faire, vous devez les placer dans le répertoire spécifié via l'option --cert-dir ou spécifié via la propriété CertificatesDir de votre fichier de configuration.
Par défaut, le répertoire est /etc/kubernetes/pki.
S'il existe un certificat et une clef privée dans ce répertoire, alors kubeadm sautera l'étape de génération et les fichiers fournis seront utilisés.
Cela signifie que vous pouvez, par exemple, copier un CA (Certificate Authority) existant vers /etc/kubernetes/pki/ca.crt
et /etc/kubernetes/pki/ca.key, et kubeadm utilisera ce CA pour signer le reste des certificats.
Mode CA externe
Il est aussi possible de fournir seulement le fichier ca.crt sans le fichier
ca.key (seulement dans le cas d'un fichier CA racine, pas pour d'autres paires de certificats).
Si tous les certificats et fichiers kubeconfig sont en place, kubeadm activera le mode "CA externe".
Kubeadm continuera sans clef CA locale.
Ou alors, vous pouvez utiliser l'outil controller-manager avec --controllers=csrsigner en fournissant les emplacements du certificat CA et la clef.
Gérer le fichier kubeadm ad-hoc pour kubelet
Le paquet kubeadm vient avec de la configuration concernant comment kubelet doit se comporter.
Vous remarquerez que la commande CLI kubeadm ne modifiera jamais ce fichier.
Ce fichier ad-hoc appartient au paquet deb/rpm de kubeadm.
Pour en savoir plus sur comment kubeadm gère kubelet, vous pouvez consulter
cette page.
Utilisation de kubeadm avec des runtimes CRI
Depuis la version v1.6.0, Kubernetes a rendu possible par défaut l'utilisation de CRI, Container Runtime Interface.
Le runtime utilisé par défaut est Docker, activé à travers l'adaptateur fourni dockershim, une implémentation CRI, à l'intérieur de kubelet.
Après avoir installé kubeadm et kubelet, exécuter ces étapes additionnelles :
Installer l'adaptateur runtime sur chaque noeud, en suivant les instructions d'installation du projet mentionné ci-dessus.
Configurer kubelet pour utiliser le runtime CRI distant. Ne pas oublier de modifier
RUNTIME_ENDPOINT en utilisant la valeur adéquate /var/run/{your_runtime}.sock:
Maintenant kubelet est prête à utiliser le runtime CRI spécifié, et vous pouvez reprendre la séquence de déploiement avec kubeadm init et kubeadm joinpour déployer votre cluster Kubernetes.
Il est aussi possible de configurer --cri-socket à kubeadm init et kubeadm reset lorsque vous utilisez une implémentation CRI externe.
Paramétrer le nom du noeud
Par défaut, kubeadm donne un nom au noeud en utilisant l'adresse de la machine. Vous pouvez outrepasser ce réglage en utilisant l'option --node-name.
Cette option se chargera de passer la valeur appropriée pour --hostname-override à kubelet.
A partir de la version 1.8, vous pouvez expérimentalement créer un control plane Kubernetes auto-hébergé (self-hosted) .
Cela signifie que des composants clefs comme le serveur d'API, le controller manager et l'ordonnanceur sont démarrés en tant que
pods DaemonSet, configurés via l'API Kubernetes
plutôt qu'en tant que pods static configurés avec des fichiers statiques dans kubelet.
Pour créer un cluster auto-hébergé, se référer à la commande kubeadm alpha selfhosting.
Avertissements
L'auto-hébergement dans la version 1.8 et au delà comporte de sérieuses limitations.
En particulier, un cluster auto-hébergé ne peut pas survivre au redémarrage du noeud control plane sans intervention manuelle.
Un cluster auto-hébergé ne peut pas être mis à jour via la commande kubeadm upgrade.
Par défaut, les Pods d'un control plane auto-hébergé dépendent des identifiants chargés depuis des volumes de type
hostPath
A part pour la création initiale, ces identifiants ne sont pas gérés par kubeadm.
La partie auto-hébergée du control plane n'inclut pas etcd,
qui fonctionne toujours en tant que Pod statique.
En bref, kubeadm alpha selfhosting fonctionne de la manière suivante :
Attend que le control plane statique soit démarré correctement. C'est la même chose que le procédé kubeadm init lorsque non auto-hébergé.
Utilise les manifestes du Pod statique du control plane pour construire un ensemble de manifestes DaemonSet qui vont lancer le control plane auto-hébergé.
Cela modifie aussi les manifestes si nécessaires, par example pour ajouter des nouveaux volumes pour des secrets.
Crée des DaemonSets dans le namespace kube-system et attend que les pods ainsi créés soient démarrés.
Une fois que les Pods auto-hébergés sont opérationnels, les Pods statiques qui leurs sont associés sont supprimés et kubeadm installe ensuite le prochain composant.
Cela déclenche l'arrêt par kubelet de ces Pods statiques.
Quand le control plane statique d'origine s'arrête, le nouveau control plane auto-hébergé est capable d'écouter sur les mêmes ports et devenir actif.
Utiliser kubeadm sans connexion internet
Pour utiliser kubeadm sans connexion internet, vous devez télécharger les images requises par le control plane à l'avance.
A partir de Kubernetes 1.11, vous pouvez lister et télécharger les images en utilisant les sous commandes à kubeadm config images :
kubeadm config images list
kubeadm config images pull
A partir de Kubernetes 1.12, les images prefixées par registry.k8s.io/kube-*, registry.k8s.io/etcd et registry.k8s.io/pause
ne nécessitent pas un suffix -${ARCH}.
Automatiser kubeadm
Plutôt que copier sur chaque noeud le jeton que vous avez obtenu avec kubeadm init, comme décrit dans
le tutoriel basique de kubeadm, vous pouvez paralléliser la distribution du jeton afin d'automatiser cette tâche.
Pour ce faire, vous devez connaître l'adresse IP que le noeud control plane obtiendra après son démarrage.
Générer un jeton. Ce jeton doit avoir correspondre à la chaîne suivante : <6 caractères>.<16 caractères>. Plus simplement, il doit correspondre à la regexp suivante :
[a-z0-9]{6}\.[a-z0-9]{16}.
kubeadm peut générer un jeton pour vous :
kubeadm token generate
Démarrer en parallèle le noeud control plane et les noeuds worker nodes avec ce jeton.
Lors de leurs démarrages, ils devraient pouvoir se trouver les uns les autres et former le cluster.
L'option --token peut être utilisée aussi bien pour kubeadm init que pour kubeadm join.
Une fois que le cluster est correctement démarré, vous pouvez obtenir les identifiants admin depuis le noeud control plane depuis le fichier /etc/kubernetes/admin.conf
et les utiliser pour communiquer avec le cluster.
Vous remarquerez que ce type d'installation présente un niveau de sécurité inférieur puisqu'il ne permet pas la validation du hash du certificat racine avec --discovery-token-ca-cert-hash
(puisqu'il n'est pas généré quand les noeuds sont provisionnés). Pour plus d'information, se référer à kubeadm join.
kubeadm join pour amorcer un noeud Kubernetes worker node Kubernetes et le faire joindre le cluster
kubeadm upgrade pour mettre à jour un cluster Kubernetes vers une version plus récente
kubeadm reset pour annuler les changements appliqués avec kubeadm init ou kubeadm join à un noeud
6.2 - kubefed
7 - CLI kubectl
kubectl CLI description
7.1 - Aide-mémoire de kubectl
Cette page contient une liste des commandes et options fréquemment utilisées de kubectl.
Note:
Ces instructions concernent Kubernetes v1.32. Pour vérifier la version, utilisez la commande kubectl version.
Autocomplétion de Kubectl
BASH
source <(kubectl completion bash)# set up autocomplete in bash into the current shell, bash-completion package should be installed first.echo"source <(kubectl completion bash)" >> ~/.bashrc # add autocomplete permanently to your bash shell.
Vous pouvez également utiliser un alias pour kubectl qui fonctionne aussi avec l'autocomplétion.
aliask=kubectl
complete -o default -F __start_kubectl k
ZSH
source <(kubectl completion zsh)# set up autocomplete in zsh into the current shellecho'[[ $commands[kubectl] ]] && source <(kubectl completion zsh)' >> ~/.zshrc # add autocomplete permanently to your zsh shell
FISH
Note:
Requires kubectl version 1.23 or above.
echo'kubectl completion fish | source' > ~/.config/fish/completions/kubectl.fish &&source ~/.config/fish/completions/kubectl.fish
Remarque concernant --all-namespaces
L'utilisation de --all-namespaces (tous les espaces de nommage) est assez fréquente, alors sachez qu'il existe un raccourci pour cela :
kubectl -A
Contexte et configuration de Kubectl
Définissez quel cluster Kubernetes doit être utilisé avec kubectl, et modifiez les paramètres de configuration. Pour plus de détails sur le fichier de configuration, consultez la documentation Configurer l'accès à plusieurs clusters.
kubectl config view # Show Merged kubeconfig settings.# use multiple kubeconfig files at the same time and view merged configKUBECONFIG=~/.kube/config:~/.kube/kubconfig2
kubectl config view
# Show merged kubeconfig settings and raw certificate data and exposed secretskubectl config view --raw
# get the password for the e2e userkubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'# get the certificate for the e2e userkubectl config view --raw -o jsonpath='{.users[?(.name == "e2e")].user.client-certificate-data}' | base64 -d
kubectl config view -o jsonpath='{.users[].name}'# display the first userkubectl config view -o jsonpath='{.users[*].name}'# get a list of userskubectl config get-contexts # display list of contextskubectl config get-contexts -o name # get all context nameskubectl config current-context # display the current-contextkubectl config use-context my-cluster-name # set the default context to my-cluster-namekubectl config set-cluster my-cluster-name # set a cluster entry in the kubeconfig# configure the URL to a proxy server to use for requests made by this client in the kubeconfigkubectl config set-cluster my-cluster-name --proxy-url=my-proxy-url
# add a new user to your kubeconf that supports basic authkubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword
# permanently save the namespace for all subsequent kubectl commands in that context.kubectl config set-context --current --namespace=ggckad-s2
# set a context utilizing a specific username and namespace.kubectl config set-context gce --user=cluster-admin --namespace=foo \
&& kubectl config use-context gce
kubectl config unset users.foo # delete user foo# short alias to set/show context/namespace (only works for bash and bash-compatible shells, current context to be set before using kn to set namespace)aliaskx='f() { [ "$1" ] && kubectl config use-context $1 || kubectl config current-context ; } ; f'aliaskn='f() { [ "$1" ] && kubectl config set-context --current --namespace $1 || kubectl config view --minify | grep namespace | cut -d" " -f6 ; } ; f'
Kubectl apply
apply gère les applications à travers des fichiers définissant les ressources Kubernetes. Il crée et met à jour les ressources dans un cluster en exécutant kubectl apply. C'est la méthode recommandée pour gérer les applications Kubernetes en production. Consultez Kubectl Book.
Création d'objets
Les manifestes Kubernetes peuvent être définis en YAML ou en JSON. Les extensions de fichier .yaml, .yml, et .json peuvent être utilisées.
kubectl apply -f ./my-manifest.yaml # create resource(s)kubectl apply -f ./my1.yaml -f ./my2.yaml # create from multiple fileskubectl apply -f ./dir # create resource(s) in all manifest files in dirkubectl apply -f https://example.com/manifest.yaml # create resource(s) from url (Note: this is an example domain and does not contain a valid manifest)kubectl create deployment nginx --image=nginx # start a single instance of nginx# créer un Job qui imprime « Hello World » (bonjour le monde)kubectl create job hello --image=busybox:1.28 -- echo"Hello World"# create a CronJob that prints "Hello World" every minutekubectl create cronjob hello --image=busybox:1.28 --schedule="*/1 * * * *" -- echo"Hello World"kubectl explain pods # get the documentation for pod manifests# Create multiple YAML objects from stdinkubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep
spec:
containers:
- name: busybox
image: busybox:1.28
args:
- sleep
- "1000000"
---
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep-less
spec:
containers:
- name: busybox
image: busybox:1.28
args:
- sleep
- "1000"
EOF# Create a secret with several keyskubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
password: $(echo -n "s33msi4" | base64 -w0)
username: $(echo -n "jane" | base64 -w0)
EOF
Consultez et trouvez les ressources
# Get commands with basic outputkubectl get services # List all services in the namespacekubectl get pods --all-namespaces # List all pods in all namespaceskubectl get pods -o wide # List all pods in the current namespace, with more detailskubectl get deployment my-dep # List a particular deploymentkubectl get pods # List all pods in the namespacekubectl get pod my-pod -o yaml # Get a pod's YAML# Describe commands with verbose outputkubectl describe nodes my-node
kubectl describe pods my-pod
# List Services Sorted by Namekubectl get services --sort-by=.metadata.name
# List pods Sorted by Restart Countkubectl get pods --sort-by='.status.containerStatuses[0].restartCount'# List PersistentVolumes sorted by capacitykubectl get pv --sort-by=.spec.capacity.storage
# Get the version label of all pods with label app=cassandrakubectl get pods --selector=app=cassandra -o \
jsonpath='{.items[*].metadata.labels.version}'# Retrieve the value of a key with dots, e.g. 'ca.crt'kubectl get configmap myconfig \
-o jsonpath='{.data.ca\.crt}'# Retrieve a base64 encoded value with dashes instead of underscores.kubectl get secret my-secret --template='{{index .data "key-name-with-dashes"}}'# Get all worker nodes (use a selector to exclude results that have a label# named 'node-role.kubernetes.io/control-plane')kubectl get node --selector='!node-role.kubernetes.io/control-plane'# Get all running pods in the namespacekubectl get pods --field-selector=status.phase=Running
# Get ExternalIPs of all nodeskubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'# List Names of Pods that belong to Particular RC# "jq" command useful for transformations that are too complex for jsonpath, it can be found at https://jqlang.github.io/jq/sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}echo$(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})# Show labels for all pods (or any other Kubernetes object that supports labelling)kubectl get pods --show-labels
# Check which nodes are readyJSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}'\
&& kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"# Check which nodes are ready with custom-columnskubectl get node -o custom-columns='NODE_NAME:.metadata.name,STATUS:.status.conditions[?(@.type=="Ready")].status'# Output decoded secrets without external toolskubectl get secret my-secret -o go-template='{{range $k,$v := .data}}{{"### "}}{{$k}}{{"\n"}}{{$v|base64decode}}{{"\n\n"}}{{end}}'# List all Secrets currently in use by a podkubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
# List all containerIDs of initContainer of all pods# Helpful when cleaning up stopped containers, while avoiding removal of initContainers.kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3
# List Events sorted by timestampkubectl get events --sort-by=.metadata.creationTimestamp
# List all warning eventskubectl events --types=Warning
# Compares the current state of the cluster against the state that the cluster would be in if the manifest was applied.kubectl diff -f ./my-manifest.yaml
# Produce a period-delimited tree of all keys returned for nodes# Helpful when locating a key within a complex nested JSON structurekubectl get nodes -o json | jq -c 'paths|join(".")'# Produce a period-delimited tree of all keys returned for pods, etckubectl get pods -o json | jq -c 'paths|join(".")'# Produce ENV for all pods, assuming you have a default container for the pods, default namespace and the `env` command is supported.# Helpful when running any supported command across all pods, not just `env`for pod in $(kubectl get po --output=jsonpath={.items..metadata.name}); doecho$pod&& kubectl exec -it $pod -- env; done# Get a deployment's status subresourcekubectl get deployment nginx-deployment --subresource=status
Mise à jour des ressources
kubectl set image deployment/frontend www=image:v2 # Rolling update "www" containers of "frontend" deployment, updating the imagekubectl rollout history deployment/frontend # Check the history of deployments including the revisionkubectl rollout undo deployment/frontend # Rollback to the previous deploymentkubectl rollout undo deployment/frontend --to-revision=2# Rollback to a specific revisionkubectl rollout status -w deployment/frontend # Watch rolling update status of "frontend" deployment until completionkubectl rollout restart deployment/frontend # Rolling restart of the "frontend" deploymentcat pod.json | kubectl replace -f - # Replace a pod based on the JSON passed into stdin# Force replace, delete and then re-create the resource. Will cause a service outage.kubectl replace --force -f ./pod.json
# Create a service for a replicated nginx, which serves on port 80 and connects to the containers on port 8000kubectl expose rc nginx --port=80 --target-port=8000# Update a single-container pod's image version (tag) to v4kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -
kubectl label pods my-pod new-label=awesome # Add a Labelkubectl label pods my-pod new-label- # Remove a labelkubectl label pods my-pod new-label=new-value --overwrite # Overwrite an existing valuekubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # Add an annotationkubectl annotate pods my-pod icon-url- # Remove annotationkubectl autoscale deployment foo --min=2 --max=10# Auto scale a deployment "foo"
Application des correctifs aux ressources
# Partially update a nodekubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'# Update a container's image; spec.containers[*].name is required because it's a merge keykubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'# Update a container's image using a json patch with positional arrayskubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'# Disable a deployment livenessProbe using a json patch with positional arrayskubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'# Add a new element to a positional arraykubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'# Update a deployment's replica count by patching its scale subresourcekubectl patch deployment nginx-deployment --subresource='scale' --type='merge' -p '{"spec":{"replicas":2}}'
Modification des ressources
Modifiez toutes ressources API de votre choix avec votre éditeur préféré
kubectl edit svc/docker-registry # Edit the service named docker-registryKUBE_EDITOR="nano" kubectl edit svc/docker-registry # Use an alternative editor
Mise à l'échelle des ressources
kubectl scale --replicas=3 rs/foo # Scale a replicaset named 'foo' to 3kubectl scale --replicas=3 -f foo.yaml # Scale a resource specified in "foo.yaml" to 3kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # If the deployment named mysql's current size is 2, scale mysql to 3kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Scale multiple replication controllers
Suppression des ressources
kubectl delete -f ./pod.json # Delete a pod using the type and name specified in pod.jsonkubectl delete pod unwanted --now # Delete a pod with no grace periodkubectl delete pod,service baz foo # Delete pods and services with same names "baz" and "foo"kubectl delete pods,services -l name=myLabel # Delete pods and services with label name=myLabelkubectl -n my-ns delete pod,svc --all # Delete all pods and services in namespace my-ns,# Delete all pods matching the awk pattern1 or pattern2kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod
Interaction avec les Pods en cours d'exécution
kubectl logs my-pod # dump pod logs (stdout)kubectl logs -l name=myLabel # dump pod logs, with label name=myLabel (stdout)kubectl logs my-pod --previous # dump pod logs (stdout) for a previous instantiation of a containerkubectl logs my-pod -c my-container # dump pod container logs (stdout, multi-container case)kubectl logs -l name=myLabel -c my-container # dump pod container logs, with label name=myLabel (stdout)kubectl logs my-pod -c my-container --previous # dump pod container logs (stdout, multi-container case) for a previous instantiation of a containerkubectl logs -f my-pod # stream pod logs (stdout)kubectl logs -f my-pod -c my-container # stream pod container logs (stdout, multi-container case)kubectl logs -f -l name=myLabel --all-containers # stream all pods logs with label name=myLabel (stdout)kubectl run -i --tty busybox --image=busybox:1.28 -- sh # Run pod as interactive shellkubectl run nginx --image=nginx -n mynamespace # Start a single instance of nginx pod in the namespace of mynamespacekubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml
# Generate spec for running pod nginx and write it into a file called pod.yamlkubectl attach my-pod -i # Attach to Running Containerkubectl port-forward my-pod 5000:6000 # Listen on port 5000 on the local machine and forward to port 6000 on my-podkubectl exec my-pod -- ls / # Run command in existing pod (1 container case)kubectl exec --stdin --tty my-pod -- /bin/sh # Interactive shell access to a running pod (1 container case)kubectl exec my-pod -c my-container -- ls / # Run command in existing pod (multi-container case)kubectl debug my-pod -it --image=busybox:1.28 # Create an interactive debugging session within existing pod and immediately attach to itkubectl debug node/my-node -it --image=busybox:1.28 # Create an interactive debugging session on a node and immediately attach to itkubectl top pod # Show metrics for all pods in the default namespacekubectl top pod POD_NAME --containers # Show metrics for a given pod and its containerskubectl top pod POD_NAME --sort-by=cpu # Show metrics for a given pod and sort it by 'cpu' or 'memory'
Copie de fichiers et de répertoires vers et depuis des conteneurs
kubectl cp /tmp/foo_dir my-pod:/tmp/bar_dir # Copy /tmp/foo_dir local directory to /tmp/bar_dir in a remote pod in the current namespacekubectl cp /tmp/foo my-pod:/tmp/bar -c my-container # Copy /tmp/foo local file to /tmp/bar in a remote pod in a specific containerkubectl cp /tmp/foo my-namespace/my-pod:/tmp/bar # Copy /tmp/foo local file to /tmp/bar in a remote pod in namespace my-namespacekubectl cp my-namespace/my-pod:/tmp/foo /tmp/bar # Copy /tmp/foo from a remote pod to /tmp/bar locally
Note:
kubectl cp nécessite que le binaire 'tar' soit présent dans l'image de votre conteneur. Si 'tar' n'est pas disponible, kubectl cp échouera.
Pour les cas d'utilisation plus avancés, comme les liens symboliques, widlcard ou la préservation des modes d'accès aux fichiers, envisagez d'utiliser kubectl exec
tar cf - /tmp/foo | kubectl exec -i -n my-namespace my-pod -- tar xf - -C /tmp/bar # Copy /tmp/foo local file to /tmp/bar in a remote pod in namespace my-namespacekubectl exec -n my-namespace my-pod -- tar cf - /tmp/foo | tar xf - -C /tmp/bar # Copy /tmp/foo from a remote pod to /tmp/bar locally
Interaction avec les Deployments et les Services
kubectl logs deploy/my-deployment # dump Pod logs for a Deployment (single-container case)kubectl logs deploy/my-deployment -c my-container # dump Pod logs for a Deployment (multi-container case)kubectl port-forward svc/my-service 5000# listen on local port 5000 and forward to port 5000 on Service backendkubectl port-forward svc/my-service 5000:my-service-port # listen on local port 5000 and forward to Service target port with name <my-service-port>kubectl port-forward deploy/my-deployment 5000:6000 # listen on local port 5000 and forward to port 6000 on a Pod created by <my-deployment>kubectl exec deploy/my-deployment -- ls # run command in first Pod and first container in Deployment (single- or multi-container cases)
Interaction avec les Nodes et le cluster
kubectl cordon my-node # Mark my-node as unschedulablekubectl drain my-node # Drain my-node in preparation for maintenancekubectl uncordon my-node # Mark my-node as schedulablekubectl top node # Show metrics for all nodeskubectl top node my-node # Show metrics for a given nodekubectl cluster-info # Display addresses of the master and serviceskubectl cluster-info dump # Dump current cluster state to stdoutkubectl cluster-info dump --output-directory=/path/to/cluster-state # Dump current cluster state to /path/to/cluster-state# View existing taints on which exist on current nodes.kubectl get nodes -o='custom-columns=NodeName:.metadata.name,TaintKey:.spec.taints[*].key,TaintValue:.spec.taints[*].value,TaintEffect:.spec.taints[*].effect'# If a taint with that key and effect already exists, its value is replaced as specified.kubectl taint nodes foo dedicated=special-user:NoSchedule
Les types de ressources
Listez tous les types de ressources pris en charge, ainsi que leurs noms abrégés, leurs API group, s'ils sont namespaced, et leur kind:
kubectl api-resources
Autres opérations pour explorer les ressources API:
kubectl api-resources --namespaced=true# All namespaced resourceskubectl api-resources --namespaced=false# All non-namespaced resourceskubectl api-resources -o name # All resources with simple output (only the resource name)kubectl api-resources -o wide # All resources with expanded (aka "wide") outputkubectl api-resources --verbs=list,get # All resources that support the "list" and "get" request verbskubectl api-resources --api-group=extensions # All resources in the "extensions" API group
Formatage de la sortie
Pour afficher les détails dans votre terminal avec un format spécifique, ajoutez l'option -o (ou --output) à une commande kubectl prise en charge.
Format de sortie
Description
-o=custom-columns=<spec>
Affiche une table en utilisant une liste de colonnes personnalisées séparées par des virgules
-o=custom-columns-file=<filename>
Affiche une table en utilisant le modèle de colonnes personnalisées dans le fichier <filename>
Affiche les champs définis par le golang template dans le fichier <filename>
-o=json
Produit un objet API formaté en JSON
-o=jsonpath=<template>
Affiche les champs définis dans une expression jsonpath
-o=jsonpath-file=<filename>
Affiche les champs définis par l'expression jsonpathdans le fichier <filename>
-o=name
Affiche uniquement le nom de la ressource et rien d'autre
-o=wide
Produit une sortie en format texte avec des informations supplémentaires, et pour les pods, le nom du noeud est inclus
-o=yaml
Produit un objet API formaté en YAML
Exemples en utilisant -o=custom-columns:
# All images running in a clusterkubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'# All images running in namespace: default, grouped by Podkubectl get pods --namespace default --output=custom-columns="NAME:.metadata.name,IMAGE:.spec.containers[*].image"# All images excluding "registry.k8s.io/coredns:1.6.2"kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="registry.k8s.io/coredns:1.6.2")].image'# All fields under metadata regardless of namekubectl get pods -A -o=custom-columns='DATA:metadata.*'
La verbosité de Kubectl est contrôlée avec les options -v ou --v suivies d'un entier représentant le niveau de log. Les conventions générales de journalisation de Kubernetes et les niveaux de log associés sont décrits ici.
Verbosity
Description
--v=0
Généralement utile pour que cela soit toujours visible pour un opérateur de cluster.
--v=1
Un niveau de log par défaut raisonnable si vous ne souhaitez pas de verbosité.
--v=2
Informations utiles sur l'état stable du service et messages de log importants pouvant correspondre à des changements significatifs dans le système. C'est le niveau de log par défaut recommandé pour la plupart des systèmes.
--v=3
Informations supplémentaires sur les changements.
--v=4
Verbosité de niveau débogage.
--v=5
Verbosité de niveau trace.
--v=6
Affiche les ressources demandées.
--v=7
Affiche les en-têtes des requêtes HTTP.
--v=8
Affiche le contenu des requêtes HTTP.
--v=9
Affiche le contenu des requêtes HTTP sans troncature.
Kubectl est un outil en ligne de commande pour contrôler des clusters Kubernetes. kubectl recherche un fichier appelé config dans le répertoire $HOME/.kube. Vous pouvez spécifier d'autres fichiers [kubeconfig](https://kube
rnetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) en définissant la variable d'environnement KUBECONFIG ou en utilisant le paramètre --kubeconfig.
Cet aperçu couvre la syntaxe kubectl, décrit les opérations et fournit des exemples classiques. Pour des détails sur chaque commande, incluant toutes les options et sous-commandes autorisées, voir la documentation de référence de kubectl. Pour des instructions d'installation, voir installer kubectl.
Syntaxe
Utilisez la syntaxe suivante pour exécuter des commandes kubectl depuis votre fenêtre de terminal :
kubectl [commande][TYPE][NOM][flags]
où commande, TYPE, NOM et flags sont :
commande: Indique l'opération que vous désirez exécuter sur une ou plusieurs ressources, par exemple create, get, describe, delete.
TYPE: Indique le type de ressource. Les types de ressources sont insensibles à la casse et vous pouvez utiliser les formes singulier, pluriel ou abrégé. Par exemple, les commandes suivantes produisent le même résultat :
```shell
$ kubectl get pod pod1
$ kubectl get pods pod1
$ kubectl get po pod1
```
NOM: Indique le nom de la ressource. Les noms sont sensibles à la casse. Si le nom est omis, des détails pour toutes les ressources sont affichés, par exemple $ kubectl get pods.
En effectuant une opération sur plusieurs ressources, vous pouvez soit indiquer chaque ressource par leur type et nom soit indiquer un ou plusieurs fichiers :
Pour indiquer des ressources par leur type et nom :
Pour regrouper des ressources si elles ont toutes le même type : TYPE1 nom1 nom2 nom<#>. Example: $ kubectl get pod exemple-pod1 exemple-pod2
Pour indiquer plusieurs types de ressources individuellement : TYPE1/nom1 TYPE1/nom2 TYPE2/nom3 TYPE<#>/nom<#>. Exemple: $ kubectl get pod/exemple-pod1 replicationcontroller/exemple-rc1
Pour indiquer des ressources avec un ou plusieurs fichiers : -f fichier1 -f fichier2 -f fichier<#>
Utilisez YAML plutôt que JSON, YAML tendant à être plus facile à utiliser, particulièrement pour des fichiers de configuration. Exemple: $ kubectl get pod -f ./pod.yaml
flags: Indique des flags optionnels. Par exemple, vous pouvez utiliser les flags -s ou --server pour indiquer l'adresse et le port de l'API server Kubernetes.
Avertissement:
Les flags indiqués en ligne de commande écrasent les valeurs par défaut et les variables d'environnement correspondantes.
Si vous avez besoin d'aide, exécutez kubectl help depuis la fenêtre de terminal.
Opérations
Le tableau suivant inclut une courte description et la syntaxe générale pour chaque opération kubectl :
Opération
Syntaxe
Description
alpha
kubectl alpha SOUS-COMMANDE [flags]
Liste les commandes disponibles qui correspondent à des fonctionnalités alpha, qui ne sont pas activées par défaut dans les clusters Kubernetes.
annotate
kubectl annotate (-f FICHIER | TYPE NOM | TYPE/NOM) CLE_1=VAL_1 ... CLE_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]
Ajoute ou modifie les annotations d'une ou plusieurs ressources.
api-resources
kubectl api-resources [flags]
Liste les ressources d'API disponibles.
api-versions
kubectl api-versions [flags]
Liste les versions d'API disponibles.
apply
kubectl apply -f FICHIER [flags]
Applique un changement de configuration à une ressource depuis un fichier ou stdin.
attach
kubectl attach POD -c CONTENEUR [-i] [-t] [flags]
Attache à un conteneur en cours d'exécution soit pour voir la sortie standard soit pour interagir avec le conteneur (stdin).
auth
kubectl auth [flags] [options]
Inspecte les autorisations.
autoscale
kubectl autoscale (-f FICHIER | TYPE NOM | TYPE/NOM) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]
Scale automatiquement l'ensemble des pods gérés par un replication controller.
certificate
kubectl certificate SOUS-COMMANDE [options]
Modifie les ressources de type certificat.
cluster-info
kubectl cluster-info [flags]
Affiche les informations des endpoints du master et des services du cluster.
completion
kubectl completion SHELL [options]
Affiche le code de complétion pour le shell spécifié (bash ou zsh).
config
kubectl config SOUS-COMMANDE [flags]
Modifie les fichiers kubeconfig. Voir les sous-commandes individuelles pour plus de détails.
convert
kubectl convert -f FICHIER [options]
Convertit des fichiers de configuration entre différentes versions d'API. Les formats YAML et JSON sont acceptés.
cordon
kubectl cordon NOEUD [options]
Marque un nœud comme non programmable.
cp
kubectl cp <ficher-src> <fichier-dest> [options]
Copie des fichiers et des répertoires vers et depuis des conteneurs.
create
kubectl create -f FICHIER [flags]
Crée une ou plusieurs ressources depuis un fichier ou stdin.
Supprime des ressources soit depuis un fichier ou stdin, ou en indiquant des sélecteurs de label, des noms, des sélecteurs de ressources ou des ressources.
Exécute une commande à l'intérieur d'un conteneur dans un pod.
explain
kubectl explain [--recursive=false] [flags]
Obtient des informations sur différentes ressources. Par exemple pods, nœuds, services, etc.
expose
kubectl expose (-f FICHIER | TYPE NOM | TYPE/NOM) [--port=port] [--protocol=TCP|UDP] [--target-port=nombre-ou-nom] [--name=nom] [--external-ip=ip-externe-ou-service] [--type=type] [flags]
Expose un replication controller, service ou pod comme un nouveau service Kubernetes.
get
kubectl get (-f FICHIER | TYPE [NOM | /NOM | -l label]) [--watch] [--sort-by=CHAMP] [[-o | --output]=FORMAT_AFFICHAGE] [flags]
Liste une ou plusieurs ressources.
kustomize
kubectl kustomize <répertoire> [flags] [options]
Liste un ensemble de ressources d'API généré à partir d'instructions d'un fichier kustomization.yaml. Le paramètre doit être le chemin d'un répertoire contenant ce fichier, ou l'URL d'un dépôt git incluant un suffixe de chemin par rapport à la racine du dépôt.
label
kubectl label (-f FICHIER | TYPE NOM | TYPE/NOM) CLE_1=VAL_1 ... CLE_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]
Ajoute ou met à jour les labels d'une ou plusieurs ressources.
logs
kubectl logs POD [-c CONTENEUR] [--follow] [flags]
Affiche les logs d'un conteneur dans un pod.
options
kubectl options
Liste des options globales, s'appliquant à toutes commandes.
patch
kubectl patch (-f FICHIER | TYPE NOM | TYPE/NOM) --patch PATCH [flags]
Met à jour un ou plusieurs champs d'une resource en utilisant le processus de merge patch stratégique.
plugin
kubectl plugin [flags] [options]
Fournit des utilitaires pour interagir avec des plugins.
port-forward
kubectl port-forward POD [PORT_LOCAL:]PORT_DISTANT [...[PORT_LOCAL_N:]PORT_DISTANT_N] [flags]
Transfère un ou plusieurs ports locaux vers un pod.
Remplace une ressource depuis un fichier ou stdin.
rollout
kubectl rollout SOUS-COMMANDE [options]
Gère le rollout d'une ressource. Les types de ressources valides sont : deployments, daemonsets et statefulsets.
run
kubectl run NOM --image=image [--env="cle=valeur"] [--port=port] [--replicas=replicas] [--dry-run=server|client|none] [--overrides=inline-json] [flags]
Exécute dans le cluster l'image indiquée.
scale
kubectl scale (-f FICHIER | TYPE NOM | TYPE/NOM) --replicas=QUANTITE [--resource-version=version] [--current-replicas=quantité] [flags]
Met à jour la taille du replication controller indiqué.
Expérimental : Attend un condition spécifique sur une ou plusieurs ressources.
Rappelez-vous : Pour tout savoir sur les opérations, voir la documentation de référence de kubectl.
Types de ressources
Le tableau suivant inclut la liste de tous les types de ressources pris en charge et leurs alias abrégés.
(cette sortie peut être obtenue depuis kubectl api-resources, et correspond à Kubernetes 1.13.3.)
Nom de la ressource
Noms abrégés
Groupe API
Par namespace
Genre de la ressource
bindings
true
Binding
componentstatuses
cs
false
ComponentStatus
configmaps
cm
true
ConfigMap
endpoints
ep
true
Endpoints
limitranges
limits
true
LimitRange
namespaces
ns
false
Namespace
nodes
no
false
Node
persistentvolumeclaims
pvc
true
PersistentVolumeClaim
persistentvolumes
pv
false
PersistentVolume
pods
po
true
Pod
podtemplates
true
PodTemplate
replicationcontrollers
rc
true
ReplicationController
resourcequotas
quota
true
ResourceQuota
secrets
true
Secret
serviceaccounts
sa
true
ServiceAccount
services
svc
true
Service
mutatingwebhookconfigurations
admissionregistration.k8s.io
false
MutatingWebhookConfiguration
validatingwebhookconfigurations
admissionregistration.k8s.io
false
ValidatingWebhookConfiguration
customresourcedefinitions
crd, crds
apiextensions.k8s.io
false
CustomResourceDefinition
apiservices
apiregistration.k8s.io
false
APIService
controllerrevisions
apps
true
ControllerRevision
daemonsets
ds
apps
true
DaemonSet
deployments
deploy
apps
true
Deployment
replicasets
rs
apps
true
ReplicaSet
statefulsets
sts
apps
true
StatefulSet
tokenreviews
authentication.k8s.io
false
TokenReview
localsubjectaccessreviews
authorization.k8s.io
true
LocalSubjectAccessReview
selfsubjectaccessreviews
authorization.k8s.io
false
SelfSubjectAccessReview
selfsubjectrulesreviews
authorization.k8s.io
false
SelfSubjectRulesReview
subjectaccessreviews
authorization.k8s.io
false
SubjectAccessReview
horizontalpodautoscalers
hpa
autoscaling
true
HorizontalPodAutoscaler
cronjobs
cj
batch
true
CronJob
jobs
batch
true
Job
certificatesigningrequests
csr
certificates.k8s.io
false
CertificateSigningRequest
leases
coordination.k8s.io
true
Lease
events
ev
events.k8s.io
true
Event
ingresses
ing
extensions
true
Ingress
networkpolicies
netpol
networking.k8s.io
true
NetworkPolicy
poddisruptionbudgets
pdb
policy
true
PodDisruptionBudget
podsecuritypolicies
psp
policy
false
PodSecurityPolicy
clusterrolebindings
rbac.authorization.k8s.io
false
ClusterRoleBinding
clusterroles
rbac.authorization.k8s.io
false
ClusterRole
rolebindings
rbac.authorization.k8s.io
true
RoleBinding
roles
rbac.authorization.k8s.io
true
Role
priorityclasses
pc
scheduling.k8s.io
false
PriorityClass
csidrivers
storage.k8s.io
false
CSIDriver
csinodes
storage.k8s.io
false
CSINode
storageclasses
sc
storage.k8s.io
false
StorageClass
volumeattachments
storage.k8s.io
false
VolumeAttachment
Options de sortie
Utilisez les sections suivantes pour savoir comment vous pouvez formater ou ordonner les sorties de certaines commandes.
Pour savoir exactement quelles commandes prennent en charge quelles options de sortie, voir la documentation de référence de kubectl.
Formater la sortie
Le format de sortie par défaut pour toutes les commandes kubectl est le format texte lisible par l'utilisateur. Pour afficher des détails dans votre fenêtre de terminal dans un format spécifique, vous pouvez ajouter une des options -o ou --output à une des commandes kubectl les prenant en charge.
Syntaxe
kubectl [commande][TYPE][NOM] -o <format_sortie>
Selon l'opération kubectl, les formats de sortie suivants sont pris en charge :
Format de sortie
Description
-o custom-columns=<spec>
Affiche un tableau en utilisant une liste de colonnes personnalisées séparées par des virgules.
-o custom-columns-file=<fichier>
Affiche un tableau en utilisant un modèle de colonnes personnalisées dans le fichier <fichier>.
-o json
Affiche un objet de l'API formaté en JSON.
-o jsonpath=<modèle>
Affiche les champs définis par une expression jsonpath.
-o jsonpath-file=<ffichier>
Affiche les champs définis par une expression jsonpath dans le fichier <fichier>.
-o name
Affiche uniquement le nom de la ressource et rien de plus.
-o wide
Affiche dans le format texte avec toute information supplémentaire. Pour les pods, le nom du nœud est inclus.
-o yaml
Affiche un objet de l'API formaté en YAML.
Exemple
Dans cet exemple, la commande suivante affiche les détails d'un unique pod sous forme d'un objet formaté en YAML :
$ kubectl get pod web-pod-13je7 -o yaml
Souvenez-vous : Voir la documentation de référence de kubectl pour voir quels formats de sortie sont pris en charge par chaque commande.
Colonnes personnalisées
Pour définir des colonnes personnalisées et afficher uniquement les détails voulus dans un tableau, vous pouvez utiliser l'option custom-columns. Vous pouvez choisir de définir les colonnes personnalisées soit en ligne soit dans un fichier modèle : -o custom-columns=<spec> ou -o custom-columns-file=<fichier>.
Exemples
En ligne :
$ kubectl get pods <nom-pod> -o custom-columns=NOM:.metadata.name,RSRC:.metadata.resourceVersion
Fichier modèle :
$ kubectl get pods <nom-pod> -o custom-columns-file=modele.txt
où le fichier modele.txt contient :
NOM RSRC
metadata.name metadata.resourceVersion
Le résultat de ces commandes est :
NOM RSRC
submit-queue 610995
Colonnes côté serveur
kubectl est capable de recevoir des informations de colonnes spécifiques d'objets depuis le serveur.
Cela veut dire que pour toute ressource donnée, le serveur va retourner les colonnes et lignes pour cette ressource, que le client pourra afficher.
Cela permet un affichage de sortie lisible par l'utilisateur cohérent entre les clients utilisés sur le même cluster, le serveur encapsulant les détails d'affichage.
Cette fonctionnalité est activée par défaut dans kubectl version 1.11 et suivantes. Pour la désactiver, ajoutez l'option
--server-print=false à la commande kubectl get.
Exemples
Pour afficher les informations sur le status d'un pod, utilisez une commande similaire à :
kubectl get pods <nom-pod> --server-print=false
La sortie ressemble à :
NAME AGE
nom-pod 1m
Ordonner les listes d'objets
Pour afficher les objets dans une liste ordonnée dans une fenêtre de terminal, vous pouvez ajouter l'option --sort-by à une commande kubectl qui la prend en charge. Ordonnez vos objets en spécifiant n'importe quel champ numérique ou textuel avec l'option --sort-by. Pour spécifier un champ, utilisez une expression jsonpath.
Pour afficher une liste de pods ordonnés par nom, exécutez :
$ kubectl get pods --sort-by=.metadata.name
Exemples : Opérations courantes
Utilisez les exemples suivants pour vous familiariser avec les opérations de kubectl fréquemment utilisées :
kubectl apply - Créer une ressource depuis un fichier ou stdin.
# Crée un service en utilisant la définition dans exemple-service.yaml.$ kubectl apply -f exemple-service.yaml
# Crée un replication controller en utilisant la définition dans exemple-controller.yaml.$ kubectl apply -f exemple-controller.yaml
# Crée les objets qui sont définis dans les fichiers .yaml, .yml ou .json du répertoire <répertoire>.$ kubectl apply -f <répertoire>
kubectl get - Liste une ou plusieurs ressources.
# Liste tous les pods dans le format de sortie texte.$ kubectl get pods
# Liste tous les pods dans le format de sortie texte et inclut des informations additionnelles (comme le nom du nœud).$ kubectl get pods -o wide
# Liste le replication controller ayant le nom donné dans le format de sortie texte.# Astuce : Vous pouvez raccourcir et remplacer le type de ressource 'replicationcontroller' avec l'alias 'rc'.$ kubectl get replicationcontroller <nom-rc>
# Liste ensemble tous les replication controller et les services dans le format de sortie texte.$ kubectl get rc,services
# Liste tous les daemon sets dans le format de sortie texte.kubectl get ds
# Liste tous les pods s'exécutant sur le nœud serveur01$ kubectl get pods --field-selector=spec.nodeName=serveur01
kubectl describe - Affiche l'état détaillé d'une ou plusieurs ressources, en incluant par défaut les ressources non initialisées.
# Affiche les détails du nœud ayant le nom <nom-nœud>.$ kubectl describe nodes <nom-nœud>
# Affiche les détails du pod ayant le nom <nom-pod>.$ kubectl describe pods/<nom-pod>
# Affiche les détails de tous les pods gérés par le replication controller dont le nom est <nom-rc>.# Rappelez-vous : les noms des pods étant créés par un replication controller sont préfixés par le nom du replication controller.$ kubectl describe pods <nom-rc>
# Décrit tous les pods$ kubectl describe pods
Note:
La commande kubectl get est habituellement utilisée pour afficher une ou plusieurs ressources d'un même type. Elle propose un ensemble complet d'options permettant de personnaliser le format de sortie avec les options -o ou --output, par exemple.
Vous pouvez utiliser les options -w ou --watch pour initier l'écoute des modifications d'un objet particulier. La commande kubectl describe est elle plutôt utilisée pour décrire les divers aspects d'une ressource voulue. Elle peut invoquer plusieurs appels d'API à l'API server pour construire une vue complète pour l'utilisateur. Par exemple, la commande kubectl describe node retourne non seulement les informations sur les nœuds, mais aussi un résumé des pods s'exécutant dessus, les événements générés pour chaque nœud, etc.nœud
kubectl delete - Supprime des ressources soit depuis un fichier, stdin, ou en spécifiant des sélecteurs de labels, des noms, des sélecteurs de ressource ou des ressources.
# Supprime un pod en utilisant le type et le nom spécifiés dans le fichier pod.yaml.$ kubectl delete -f pod.yaml
# Supprime tous les pods et services ayant le label <clé-label>=<valeur-label>$ kubectl delete pods,services -l <clé-label>=<valeur-label>
# Supprime tous les pods, en incluant les non initialisés.$ kubectl delete pods --all
kubectl exec - Exécute une commande depuis un conteneur d'un pod.
# Affiche la sortie de la commande 'date' depuis le pod <nom-pod>. Par défaut, la sortie se fait depuis le premier conteneur.$ kubectl exec <nom-pod> -- date
# Affiche la sortie de la commande 'date' depuis le conteneur <nom-conteneur> du pod <nom-pod>.$ kubectl exec <nom-pod> -c <nom-conteneur> -- date
# Obtient un TTY interactif et exécute /bin/bash depuis le pod <nom-pod>. Par défaut, la sortie se fait depuis le premier conteneur.$ kubectl exec -ti <nom-pod> -- /bin/bash
kubectl logs - Affiche les logs d'un conteneur dans un pod.
# Retourne un instantané des logs du pod <nom-pod>.$ kubectl logs <nom-pod>
# Commence à streamer les logs du pod <nom-pod>. Ceci est similaire à la commande Linux 'tail -f'.$ kubectl logs -f <nom-pod>
kubectl diff - Affiche un diff des mises à jour proposées au cluster.
# Diff les ressources présentes dans "pod.json".kubectl diff -f pod.json
# Diff les ressources présentes dans le fichier lu sur l'entrée standard.cat service.yaml | kubectl diff -f -
Exemples : Créer et utiliser des plugins
Utilisez les exemples suivants pour vous familiariser avec l'écriture et l'utilisation de plugins kubectl :
# créez un plugin simple dans n'importe quel langage et nommez# l'exécutable de telle sorte qu'il commence par "kubectl-"$ cat ./kubectl-hello
#!/bin/bash# ce plugin affiche les mots "hello world"echo"hello world"# une fois votre plugin écrit, rendez-le exécutable$ sudo chmod +x ./kubectl-hello
# et déplacez-le dans un répertoire de votre PATH$ sudo mv ./kubectl-hello /usr/local/bin
# vous avez maintenant créé et "installé" un plugin kubectl.# vous pouvez commencer à l'utiliser en l'invoquant depuis kubectl# comme s'il s'agissait d'une commande ordinaire$ kubectl hello
hello world
# vous pouvez "désinstaller" un plugin,# simplement en le supprimant de votre PATH$ sudo rm /usr/local/bin/kubectl-hello
Pour voir tous les plugins disponibles pour kubectl, vous pouvez utiliser la sous-commande kubectl plugin list :
$ kubectl plugin list
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
/usr/local/bin/kubectl-bar
# cette commande peut aussi vous avertir de plugins qui ne sont pas exécutables,# ou qui sont cachés par d'autres plugins, par exemple :$ sudo chmod -x /usr/local/bin/kubectl-foo
$ kubectl plugin list
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
- warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
/usr/local/bin/kubectl-bar
error: one plugin warning was found
Vous pouvez voir les plugins comme un moyen de construire des fonctionnalités plus complexes au dessus des commandes kubectl existantes :
$ cat ./kubectl-whoami
#!/bin/bash# ce plugin utilise la commande `kubectl config` pour afficher# l'information sur l'utilisateur courant, en se basant sur# le contexte couramment sélectionnékubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
Exécuter le plugin ci-dessus vous donne une sortie contenant l'utilisateur du contexte couramment sélectionné dans votre fichier KUBECONFIG :
# rendre le fichier exécutable executable$ sudo chmod +x ./kubectl-whoami
# et le déplacer dans le PATH$ sudo mv ./kubectl-whoami /usr/local/bin
$ kubectl whoami
Current user: plugins-user
Un modèle JSONPath est composé d'expressions JSONPath entourées par des accolades {}.
Kubectl utilise les expressions JSONPath pour filtrer sur des champs spécifiques de l'objet JSON et formater la sortie.
En plus de la syntaxe de modèle JSONPath originale, les fonctions et syntaxes suivantes sont valides :
Utilisez des guillemets doubles pour marquer du texte dans les expressions JSONPath.
Utilisez les opérateurs range et end pour itérer sur des listes.
Utilisez des indices négatifs pour parcourir une liste à reculons. Les indices négatifs ne "bouclent pas" sur une liste et sont valides tant que -index + longeurListe >= 0.
Note:
L'opérateur $ est optionnel, l'expression commençant toujours, par défaut, à la racine de l'objet.
L'objet résultant est affiché via sa fonction String().
Exemples utilisant kubectl et des expressions JSONPath :
kubectl get pods -o json
kubectl get pods -o=jsonpath='{@}'kubectl get pods -o=jsonpath='{.items[0]}'kubectl get pods -o=jsonpath='{.items[0].metadata.name}'kubectl get pods -o=jsonpath="{.items[*]['metadata.name', 'status.capacity']}"kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}'
Note:
Sous Windows, vous devez utiliser des guillemets doubles autour des modèles JSONPath qui contiennent des espaces (et non des guillemets simples comme ci-dessus pour bash). Ceci entraîne que vous devez utiliser un guillemet simple ou un double guillemet échappé autour des chaînes litérales dans le modèle. Par exemple :
kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}"kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}"
Cette page donne un aperçu de la commande kubectl.
Aide-mémoire kubectl
Auto-complétion avec Kubectl
BASH
source <(kubectl completion bash)# active l'auto-complétion pour bash dans le shell courant, le paquet bash-completion devant être installé au préalableecho"source <(kubectl completion bash)" >> ~/.bashrc # ajoute l'auto-complétion de manière permanente à votre shell bash
Vous pouvez de plus déclarer un alias pour kubectl qui fonctionne aussi avec l'auto-complétion :
aliask=kubectl
complete -o default -F __start_kubectl k
ZSH
source <(kubectl completion zsh)# active l'auto-complétion pour zsh dans le shell courantecho"[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # ajoute l'auto-complétion de manière permanente à votre shell zsh
kubectl config view # Affiche les paramètres fusionnés de kubeconfig# Utilise plusieurs fichiers kubeconfig en même temps et affiche la configuration fusionnéeKUBECONFIG=~/.kube/config:~/.kube/kubconfig2
kubectl config view
# Affiche le mot de passe pour l'utilisateur e2ekubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'kubectl config view -o jsonpath='{.users[].name}'# Affiche le premier utilisateurkubectl config view -o jsonpath='{.users[*].name}'# Affiche une liste d'utilisateurskubectl config get-contexts # Affiche la liste des contexteskubectl config current-context # Affiche le contexte courant (current-context)kubectl config use-context my-cluster-name # Définit my-cluster-name comme contexte courant# Ajoute un nouveau cluster à votre kubeconf, prenant en charge l'authentification de base (basic auth)kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword
# Enregistre de manière permanente le namespace pour toutes les commandes kubectl suivantes dans ce contextekubectl config set-context --current --namespace=ggckad-s2
# Définit et utilise un contexte qui utilise un nom d'utilisateur et un namespace spécifiqueskubectl config set-context gce --user=cluster-admin --namespace=foo \
&& kubectl config use-context gce
kubectl config unset users.foo # Supprime l'utilisateur foo
Apply
apply gère des applications en utilisant des fichiers définissant des ressources Kubernetes. Elle crée et met à jour des ressources dans un cluster en exécutant kubectl apply. C'est la manière recommandée de gérer des applications Kubernetes en production. Voir le Livre Kubectl.
Création d'objets
Les manifests Kubernetes peuvent être définis en YAML ou JSON. Les extensions de fichier .yaml,
.yml, et .json peuvent être utilisés.
kubectl apply -f ./my-manifest.yaml # Crée une ou plusieurs ressourceskubectl apply -f ./my1.yaml -f ./my2.yaml # Crée depuis plusieurs fichierskubectl apply -f ./dir # Crée une ou plusieurs ressources depuis tous les manifests dans dirkubectl apply -f https://git.io/vPieo # Crée une ou plusieurs ressources depuis une urlkubectl create deployment nginx --image=nginx # Démarre une instance unique de nginxkubectl explain pods # Affiche la documentation pour les manifests pod# Crée plusieurs objets YAML depuis l'entrée standard (stdin)cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep
spec:
containers:
- name: busybox
image: busybox
args:
- sleep
- "1000000"
---
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep-less
spec:
containers:
- name: busybox
image: busybox
args:
- sleep
- "1000"
EOF# Crée un Secret contenant plusieurs cléscat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
password: $(echo -n "s33msi4" | base64 -w0)
username: $(echo -n "jane" | base64 -w0)
EOF
Visualisation et Recherche de ressources
# Commandes Get avec un affichage basiquekubectl get services # Liste tous les services d'un namespacekubectl get pods --all-namespaces # Liste tous les Pods de tous les namespaceskubectl get pods -o wide # Liste tous les Pods du namespace courant, avec plus de détailskubectl get deployment my-dep # Liste un déploiement particulierkubectl get pods # Liste tous les Pods dans un namespacekubectl get pod my-pod -o yaml # Affiche le YAML du Pod# Commandes Describe avec un affichage verbeuxkubectl describe nodes my-node
kubectl describe pods my-pod
# Liste les services triés par nomkubectl get services --sort-by=.metadata.name
# Liste les pods classés par nombre de redémarrageskubectl get pods --sort-by='.status.containerStatuses[0].restartCount'# Affiche les volumes persistants classés par capacité de stockagekubectl get pv --sort-by=.spec.capacity.storage
# Affiche la version des labels de tous les pods ayant un label app=cassandrakubectl get pods --selector=app=cassandra -o \
jsonpath='{.items[*].metadata.labels.version}'# Affiche tous les noeuds (en utilisant un sélecteur pour exclure ceux ayant un label# nommé 'node-role.kubernetes.io/master')kubectl get node --selector='!node-role.kubernetes.io/master'# Affiche tous les pods en cours d'exécution (Running) dans le namespacekubectl get pods --field-selector=status.phase=Running
# Affiche les IPs externes (ExternalIPs) de tous les noeudskubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'# Liste les noms des pods appartenant à un ReplicationController particulier# "jq" est une commande utile pour des transformations non prises en charge par jsonpath, il est disponible ici : https://stedolan.github.io/jq/sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}echo$(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})# Affiche les labels pour tous les pods (ou tout autre objet Kubernetes prenant en charge les labels)kubectl get pods --show-labels
# Vérifie quels noeuds sont prêtsJSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}'\
&& kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"# Liste tous les Secrets actuellement utilisés par un podkubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
# Liste les containerIDs des initContainer de tous les Pods# Utile lors du nettoyage des conteneurs arrêtés, tout en évitant de retirer les initContainers.kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3
# Liste les événements (Events) classés par timestampkubectl get events --sort-by=.metadata.creationTimestamp
# Compare l'état actuel du cluster à l'état du cluster si le manifeste était appliqué.kubectl diff -f ./my-manifest.yaml
Mise à jour de ressources
Depuis la version 1.11, rolling-update a été déprécié (voir CHANGELOG-1.11.md), utilisez plutôt rollout.
kubectl set image deployment/frontend www=image:v2 # Rolling update du conteneur "www" du déploiement "frontend", par mise à jour de son imagekubectl rollout history deployment/frontend # Vérifie l'historique de déploiements incluant la révisionkubectl rollout undo deployment/frontend # Rollback du déploiement précédentkubectl rollout undo deployment/frontend --to-revision=2# Rollback à une version spécifiquekubectl rollout status -w deployment/frontend # Écoute (Watch) le status du rolling update du déploiement "frontend" jusqu'à ce qu'il se terminekubectl rollout restart deployment/frontend # Rolling restart du déploiement "frontend"cat pod.json | kubectl replace -f - # Remplace un pod, en utilisant un JSON passé en entrée standard# Remplace de manière forcée (Force replace), supprime puis re-crée la ressource. Provoque une interruption de service.kubectl replace --force -f ./pod.json
# Crée un service pour un nginx repliqué, qui rend le service sur le port 80 et se connecte aux conteneurs sur le port 8000kubectl expose rc nginx --port=80 --target-port=8000# Modifie la version (tag) de l'image du conteneur unique du pod à v4kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -
kubectl label pods my-pod new-label=awesome # Ajoute un Labelkubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # Ajoute une annotationkubectl autoscale deployment foo --min=2 --max=10# Mise à l'échelle automatique (Auto scale) d'un déploiement "foo"
Mise à jour partielle de ressources
# Mise à jour partielle d'un nodekubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'# Met à jour partiellement un noeud# Met à jour l'image d'un conteneur ; spec.containers[*].name est requis car c'est une clé du mergekubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'# Met à jour l'image d'un conteneur en utilisant un patch json avec tableaux indexéskubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'# Désactive la livenessProbe d'un déploiement en utilisant un patch json avec tableaux indexéskubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'# Ajoute un nouvel élément à un tableau indexékubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
Édition de ressources
Édite n'importe quelle ressource de l'API dans un éditeur.
kubectl edit svc/docker-registry # Édite le service nommé docker-registryKUBE_EDITOR="nano" kubectl edit svc/docker-registry # Utilise un autre éditeur
Mise à l'échelle de ressources
kubectl scale --replicas=3 rs/foo # Scale un replicaset nommé 'foo' à 3kubectl scale --replicas=3 -f foo.yaml # Scale une ressource spécifiée dans foo.yaml" à 3kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # Si la taille du déploiement nommé mysql est actuellement 2, scale mysql à 3kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Scale plusieurs contrôleurs de réplication
Suppression de ressources
kubectl delete -f ./pod.json # Supprime un pod en utilisant le type et le nom spécifiés dans pod.jsonkubectl delete pod,service baz foo # Supprime les pods et services ayant les mêmes noms "baz" et "foo"kubectl delete pods,services -l name=myLabel # Supprime les pods et services ayant le label name=myLabelkubectl -n my-ns delete pod,svc --all # Supprime tous les pods et services dans le namespace my-ns# Supprime tous les pods correspondants à pattern1 ou pattern2 avec awkkubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod
Interaction avec des Pods en cours d'exécution
kubectl logs my-pod # Affiche les logs du pod (stdout)kubectl logs -l name=myLabel # Affiche les logs des pods ayant le label name=myLabel (stdout)kubectl logs my-pod --previous # Affiche les logs du pod (stdout) pour une instance précédente du conteneurkubectl logs my-pod -c my-container # Affiche les logs d'un conteneur particulier du pod (stdout, cas d'un pod multi-conteneurs)kubectl logs -l name=myLabel -c my-container # Affiche les logs des pods avec le label name=myLabel (stdout, cas d'un pod multi-conteneurs)kubectl logs my-pod -c my-container --previous # Affiche les logs d'un conteneur particulier du pod (stdout, cas d'un pod multi-conteneurs) pour une instance précédente du conteneurkubectl logs -f my-pod # Fait défiler (stream) les logs du pod (stdout)kubectl logs -f my-pod -c my-container # Fait défiler (stream) les logs d'un conteneur particulier du pod (stdout, cas d'un pod multi-conteneurs)kubectl logs -f -l name=myLabel --all-containers # Fait défiler (stream) les logs de tous les pods ayant le label name=myLabel (stdout)kubectl run -i --tty busybox --image=busybox -- sh # Exécute un pod comme un shell interactifkubectl run nginx --image=nginx --restart=Never -n
mynamespace # Exécute le pod nginx dans un namespace spécifiquekubectl run nginx --image=nginx --restart=Never # Simule l'exécution du pod nginx et écrit sa spécification dans un fichier pod.yaml--dry-run -o yaml > pod.yaml
kubectl attach my-pod -i # Attache à un conteneur en cours d'exécutionkubectl port-forward my-pod 5000:6000 # Écoute le port 5000 de la machine locale et forwarde vers le port 6000 de my-podkubectl exec my-pod -- ls / # Exécute une commande dans un pod existant (cas d'un seul conteneur)kubectl exec my-pod -c my-container -- ls / # Exécute une commande dans un pod existant (cas multi-conteneurs)kubectl top pod POD_NAME --containers # Affiche les métriques pour un pod donné et ses conteneurs
Interaction avec des Noeuds et Clusters
kubectl cordon mon-noeud # Marque mon-noeud comme non assignable (unschedulable)kubectl drain mon-noeud # Draine mon-noeud en préparation d'une mise en maintenancekubectl uncordon mon-noeud # Marque mon-noeud comme assignablekubectl top node mon-noeud # Affiche les métriques pour un noeud donnékubectl cluster-info # Affiche les adresses du master et des serviceskubectl cluster-info dump # Affiche l'état courant du cluster sur stdoutkubectl cluster-info dump --output-directory=/path/to/cluster-state # Affiche l'état courant du cluster sur /path/to/cluster-state# Si une teinte avec cette clé et cet effet existe déjà, sa valeur est remplacée comme spécifié.kubectl taint nodes foo dedicated=special-user:NoSchedule
Autres opérations pour explorer les ressources de l'API :
kubectl api-resources --namespaced=true# Toutes les ressources cantonnées à un namespacekubectl api-resources --namespaced=false# Toutes les ressources non cantonnées à un namespacekubectl api-resources -o name # Toutes les ressources avec un affichage simple (uniquement le nom de la ressource)kubectl api-resources -o wide # Toutes les ressources avec un affichage étendu (alias "wide")kubectl api-resources --verbs=list,get # Toutes les ressources prenant en charge les verbes de requête "list" et "get"kubectl api-resources --api-group=extensions # Toutes les ressources dans le groupe d'API "extensions"
Formattage de l'affichage
Pour afficher les détails sur votre terminal dans un format spécifique, utilisez l'option -o (ou --output) avec les commandes kubectl qui la prend en charge.
Format d'affichage
Description
-o=custom-columns=<spec>
Affiche un tableau en spécifiant une liste de colonnes séparées par des virgules
-o=custom-columns-file=<filename>
Affiche un tableau en utilisant les colonnes spécifiées dans le fichier <filename>
-o=json
Affiche un objet de l'API formaté en JSON
-o=jsonpath=<template>
Affiche les champs définis par une expression jsonpath
-o=jsonpath-file=<filename>
Affiche les champs définis par l'expression jsonpath dans le fichier <filename>
-o=name
Affiche seulement le nom de la ressource et rien de plus
-o=wide
Affiche dans le format texte avec toute information supplémentaire, et pour des pods, le nom du noeud est inclus
-o=yaml
Affiche un objet de l'API formaté en YAML
Exemples utilisant -o=custom-columns :
# Toutes les images s'exécutant dans un clusterkubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'# Toutes les images excepté "registry.k8s.io/coredns:1.6.2"kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="registry.k8s.io/coredns:1.6.2")].image'# Tous les champs dans metadata quel que soit leur nomkubectl get pods -A -o=custom-columns='DATA:metadata.*'
La verbosité de Kubectl est contrôlée par une des options -v ou --v suivie d'un entier représentant le niveau de log. Les conventions générales de logging de Kubernetes et les niveaux de log associés sont décrits ici.
Verbosité
Description
--v=0
Le minimum qui doit toujours être affiché à un opérateur.
--v=1
Un niveau de log par défaut raisonnable si vous n'avez pas besoin de verbosité.
--v=2
Informations utiles sur l'état stable du service et messages de logs importants qui peuvent être corrélés à des changements significatifs dans le système. C'est le niveau de log par défaut recommandé pour la plupart des systèmes.
--v=3
Informations étendues sur les changements.
--v=4
Verbosité de Debug.
--v=6
Affiche les ressources requêtées.
--v=7
Affiche les entêtes des requêtes HTTP.
--v=8
Affiche les contenus des requêtes HTTP.
--v=9
Affiche les contenus des requêtes HTTP sans les tronquer.
Conventions d'utilisation recommandées pour kubectl.
Utiliser kubectl dans des scripts réutilisables
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.
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.
Ne vous basez pas sur un contexte, des préférences ou tout autre état implicite.
Bonnes pratiques
kubectl run
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).
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.
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 de générateurs et comment ils étaient utilisés.
Générateurs
Vous pouvez générer les ressources suivantes avec une commande kubectl, kubectl create --dry-run -o yaml:
clusterrole Crée un ClusterRole.
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.
cronjob Crée un cronjob avec le nom spécifié.
deployment Crée un deployment avec le nom spécifié.
job Crée un job avec le nom spécifié.
namespace Crée un namespace avec le nom spécifié.
poddisruptionbudget Crée un pod disruption budget avec le nom spécifié.
priorityclass Crée une priorityclass avec le nom spécifié.
quota Crée un quota avec le nom spécifié.
role Crée un role avec une unique règle.
rolebinding Crée un RoleBinding pour un Role ou ClusterRole particulier.
secret Crée un secret en utilisant la sous-commande spécifiée.
service Crée un service en utilisant la sous-commande spécifiée.
serviceaccount Crée un service account avec le nom spécifié.
kubectl apply
Vous pouvez utiliser kubectl apply pour créer ou mettre à jour des ressources. Pour plus d'informations sur l'utilisation de kubectl apply pour la mise à jour de ressources, voir le livre Kubectl.
7.7 - kubectl
Référence kubectl
Synopsis
kubectl contrôle le manager d'un cluster Kubernetes
--default-not-ready-toleration-seconds int Défaut: 300
Indique les tolerationSeconds de la tolérance pour notReady:NoExecute qui sont ajoutées par défaut à tous les pods qui n'ont pas défini une telle tolérance
--default-unreachable-toleration-seconds int Défaut: 300
Indique les tolerationSeconds de la tolérance pour unreachable:NoExecute qui sont ajoutées par défaut à tous les pods qui n'ont pas défini une telle tolérance
Durée maximale pendant laquelle stocker les événements (par type). La valeur est une liste séparée par des virgules de clefs/valeurs, où les clefs sont des types d'événements (par ex: creation, oom) ou "default" et la valeur est la durée. La valeur par défaut est appliquée à tous les types d'événements non spécifiés
Nombre max d'événements à stocker (par type). La valeur est une liste séparée par des virgules de clefs/valeurs, où les clefs sont les types d'événements (par ex: creation, oom) ou "default" et la valeur est un entier. La valeur par défaut est appliquée à tous les types d'événements non spécifiés
liste séparée par des virgules de fichiers dans lesquels rechercher le machine-id. Utiliser le premier trouvé.
--match-server-version
La version du serveur doit correspondre à la version du client
-n, --namespace chaîne
Si présent, la portée de namespace pour la requête du CLI
--password chaîne
Mot de passe pour l'authentification de base au serveur d'API
--profile chaîne Défaut: "none"
Nom du profil à capturer. Parmi (none|cpu|heap|goroutine|threadcreate|block|mutex)
--profile-output chaîne Défaut: "profile.pprof"
Nom du fichier dans lequel écrire le profil
--request-timeout chaîne Défaut: "0"
La durée à attendre avant d'abandonner une requête au serveur. Les valeurs non égales à zéro doivent contenir une unité de temps correspondante (ex 1s, 2m, 3h). Une valeur à zéro indique de ne pas abandonner les requêtes
-s, --server chaîne
L'adresse et le port de l'API server Kubernetes
--skip-headers
Si vrai, n'affiche pas les entêtes dans les messages de log
--skip-log-headers
Si vrai, évite les entêtes lors de l'ouverture des fichiers de log
--stderrthreshold sévérité Défaut: 2
logs à cette sévérité et au dessus de ce seuil vont dans stderr