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 "k8s.gcr.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 "k8s.gcr.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 :
sudo kubeadm init phase control-plane controller-manager --help
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'etcd
sudo 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 k8s.gcr.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é.
Vous pouvez outrepasser ce comportement en utilisant kubeadm avec un fichier de configuration.
Les personnalisations permises sont :
- fournir un
imageRepository à utiliser à la place de k8s.gcr.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.
Parmi les autres runtimes CRI, on retrouvera :
Se référer aux instructions d'installation CRI pour plus d'information.
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:
cat > /etc/systemd/system/kubelet.service.d/20-cri.conf <<EOF
[Service]
Environment="KUBELET_EXTRA_ARGS=--container-runtime=remote --container-runtime-endpoint=$RUNTIME_ENDPOINT"
EOF
systemctl daemon-reload
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.
Faîtes attention car forcer un nom d'hôte peut interférer avec les fournisseurs de cloud.
Héberger soi même le control plane Kubernetes
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.
Procédé
Le procédé de démarrage auto-hébergé est documenté dans le document de conception de kubeadm.
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 k8s.gcr.io/kube-*, k8s.gcr.io/etcd et k8s.gcr.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 :
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.
A suivre
- kubeadm init phase pour mieux comprendre les phases
kubeadm init - 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
7.1 - Aperçu de kubectl
kubectl référence
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 :
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. |
delete | kubectl delete (-f FICHIER | TYPE [NOM | /NOM | -l label | --all]) [flags] | 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. |
describe | kubectl describe (-f FICHIER | TYPE [PREFIXE_NOM | /NOM | -l label]) [flags] | Affiche l'état détaillé d'une ou plusieurs ressources. |
diff | kubectl diff -f FICHIER [flags] | Diff un fichier ou stdin par rapport à la configuration en cours |
drain | kubectl drain NOEUD [options] | Vide un nœud en préparation de sa mise en maintenance. |
edit | kubectl edit (-f FICHIER | TYPE NOM | TYPE/NOM) [flags] | Édite et met à jour la définition d'une ou plusieurs ressources sur le serveur en utilisant l'éditeur par défaut. |
exec | kubectl exec POD [-c CONTENEUR] [-i] [-t] [flags] [-- COMMANDE [args...]] | 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. |
proxy | kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags] | Exécute un proxy vers un API server Kubernetes. |
replace | kubectl replace -f FICHIER | 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é. |
set | kubectl set SOUS-COMMANDE [options] | Configure les ressources de l'application. |
taint | kubectl taint NOEUD NNOM CLE_1=VAL_1:EFFET_TAINT_1 ... CLE_N=VAL_N:EFFET_TAINT_N [options] | Met à jour les marques (taints) d'un ou plusieurs nœuds. |
top | kubectl top [flags] [options] | Affiche l'utilisation des ressources (CPU/Mémoire/Stockage). |
uncordon | kubectl uncordon NOEUD [options] | Marque un noeud comme programmable. |
version | kubectl version [--client] [flags] | Affiche la version de Kubernetes du serveur et du client. |
wait | kubectl wait ([-f FICHIER] | ressource.groupe/ressource.nom | ressource.groupe [(-l label | --all)]) [--for=delete|--for condition=available] [options] | 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 exactgement quelles commandes prennent en charge quelles options de sortie, voir la documentation de référence de kubectl.
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 à :
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.
Syntaxe
kubectl [commande] [TYPE] [NOM] --sort-by=<exp_jsonpath>
Exemple
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
Pour en savoir plus sur les plugins, examinez l'exemple de plugin CLI.
A suivre
Commencez à utiliser les commandes kubectl.
7.2 - Support de JSONPath
JSONPath kubectl Kubernetes
Kubectl prend en charge les modèles JSONPath.
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().
Étant donné l'entrée JSON :
{
"kind": "List",
"items":[
{
"kind":"None",
"metadata":{"name":"127.0.0.1"},
"status":{
"capacity":{"cpu":"4"},
"addresses":[{"type": "LegacyHostIP", "address":"127.0.0.1"}]
}
},
{
"kind":"None",
"metadata":{"name":"127.0.0.2"},
"status":{
"capacity":{"cpu":"8"},
"addresses":[
{"type": "LegacyHostIP", "address":"127.0.0.2"},
{"type": "another", "address":"127.0.0.3"}
]
}
}
],
"users":[
{
"name": "myself",
"user": {}
},
{
"name": "e2e",
"user": {"username": "admin", "password": "secret"}
}
]
}
| Fonction | Description | Exemple | Résultat |
|---|
text | le texte en clair | le type est {.kind} | le type est List |
@ | l'objet courant | {@} | identique à l'entrée |
. ou [] | opérateur fils | {.kind}, {['kind']} ou {['name\.type']} | List |
.. | descente récursive | {..name} | 127.0.0.1 127.0.0.2 myself e2e |
* | joker. Tous les objets | {.items[*].metadata.name} | [127.0.0.1 127.0.0.2] |
[start:end:step] | opérateur d'indice | {.users[0].name} | myself |
[,] | opérateur d'union | {.items[*]['metadata.name', 'status.capacity']} | 127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8] |
?() | filtre | {.users[?(@.name=="e2e")].user.password} | secret |
range, end | itération de liste | {range .items[*]}[{.metadata.name}, {.status.capacity}] {end} | [127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]] |
'' | protège chaîne interprétée | {range .items[*]}{.metadata.name}{'\t'}{end} | 127.0.0.1 127.0.0.2 |
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}"
7.3 - Aide-mémoire kubectl
Cheatsheet kubectl aide-mémoire
Voir aussi : Aperçu Kubectl et Guide JsonPath.
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éalable
echo "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 :
alias k=kubectl
complete -F __start_kubectl k
ZSH
source <(kubectl completion zsh) # active l'auto-complétion pour zsh dans le shell courant
echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # ajoute l'auto-complétion de manière permanente à votre shell zsh
Contexte et configuration de Kubectl
Indique avec quel cluster Kubernetes kubectl communique et modifie les informations de configuration. Voir la documentation Authentification multi-clusters avec kubeconfig pour des informations détaillées sur le fichier de configuration.
Information. Voir la documentation Authentification à travers des clusters avec kubeconfig
pour des informations détaillées sur le fichier de configuration.
kubectl config view # Affiche les paramètres fusionnés de kubeconfig
# Utilise plusieurs fichiers kubeconfig en même temps et affiche la configuration fusionnée
KUBECONFIG=~/.kube/config:~/.kube/kubconfig2
kubectl config view
# Affiche le mot de passe pour l'utilisateur e2e
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
kubectl config view -o jsonpath='{.users[].name}' # Affiche le premier utilisateur
kubectl config view -o jsonpath='{.users[*].name}' # Affiche une liste d'utilisateurs
kubectl config get-contexts # Affiche la liste des contextes
kubectl 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 contexte
kubectl config set-context --current --namespace=ggckad-s2
# Définit et utilise un contexte qui utilise un nom d'utilisateur et un namespace spécifiques
kubectl 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 ressources
kubectl apply -f ./my1.yaml -f ./my2.yaml # Crée depuis plusieurs fichiers
kubectl apply -f ./dir # Crée une ou plusieurs ressources depuis tous les manifests dans dir
kubectl apply -f https://git.io/vPieo # Crée une ou plusieurs ressources depuis une url
kubectl create deployment nginx --image=nginx # Démarre une instance unique de nginx
kubectl 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és
cat <<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 basique
kubectl get services # Liste tous les services d'un namespace
kubectl get pods --all-namespaces # Liste tous les Pods de tous les namespaces
kubectl get pods -o wide # Liste tous les Pods du namespace courant, avec plus de détails
kubectl get deployment my-dep # Liste un déploiement particulier
kubectl get pods # Liste tous les Pods dans un namespace
kubectl get pod my-pod -o yaml # Affiche le YAML du Pod
# Commandes Describe avec un affichage verbeux
kubectl describe nodes my-node
kubectl describe pods my-pod
# Liste les services triés par nom
kubectl get services --sort-by=.metadata.name
# Liste les pods classés par nombre de redémarrages
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
# Affiche les volumes persistants classés par capacité de stockage
kubectl get pv --sort-by=.spec.capacity.storage
# Affiche la version des labels de tous les pods ayant un label app=cassandra
kubectl 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 namespace
kubectl get pods --field-selector=status.phase=Running
# Affiche les IPs externes (ExternalIPs) de tous les noeuds
kubectl 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êts
JSONPATH='{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 pod
kubectl 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 timestamp
kubectl 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 image
kubectl rollout history deployment/frontend # Vérifie l'historique de déploiements incluant la révision
kubectl rollout undo deployment/frontend # Rollback du déploiement précédent
kubectl rollout undo deployment/frontend --to-revision=2 # Rollback à une version spécifique
kubectl rollout status -w deployment/frontend # Écoute (Watch) le status du rolling update du déploiement "frontend" jusqu'à ce qu'il se termine
kubectl 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 8000
kubectl expose rc nginx --port=80 --target-port=8000
# Modifie la version (tag) de l'image du conteneur unique du pod à v4
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -
kubectl label pods my-pod new-label=awesome # Ajoute un Label
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # Ajoute une annotation
kubectl 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 node
kubectl 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 merge
kubectl 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és
kubectl 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és
kubectl 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-registry
KUBE_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' à 3
kubectl scale --replicas=3 -f foo.yaml # Scale une ressource spécifiée dans foo.yaml" à 3
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # Si la taille du déploiement nommé mysql est actuellement 2, scale mysql à 3
kubectl 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.json
kubectl 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=myLabel
kubectl -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 awk
kubectl 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 conteneur
kubectl 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 conteneur
kubectl 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 interactif
kubectl run nginx --image=nginx --restart=Never -n
mynamespace # Exécute le pod nginx dans un namespace spécifique
kubectl 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écution
kubectl port-forward my-pod 5000:6000 # Écoute le port 5000 de la machine locale et forwarde vers le port 6000 de my-pod
kubectl 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 maintenance
kubectl uncordon mon-noeud # Marque mon-noeud comme assignable
kubectl top node mon-noeud # Affiche les métriques pour un noeud donné
kubectl cluster-info # Affiche les adresses du master et des services
kubectl cluster-info dump # Affiche l'état courant du cluster sur stdout
kubectl 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
Types de ressources
Liste tous les types de ressources pris en charge avec leurs noms courts (shortnames), groupe d'API (API group), si elles sont cantonnées à un namespace (namespaced), et leur Genre (Kind):
Autres opérations pour explorer les ressources de l'API :
kubectl api-resources --namespaced=true # Toutes les ressources cantonnées à un namespace
kubectl api-resources --namespaced=false # Toutes les ressources non cantonnées à un namespace
kubectl 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"
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 cluster
kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'
# Toutes les images excepté "k8s.gcr.io/coredns:1.6.2"
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'
# Tous les champs dans metadata quel que soit leur nom
kubectl get pods -A -o=custom-columns='DATA:metadata.*'
Plus d'exemples dans la documentation de référence de kubectl.
Verbosité de l'affichage de Kubectl et débogage
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. |
A suivre
Kubeadm est un outil conçu afin que les commandes