Version imprimable multipages. Cliquer ici pour imprimer.
Accès aux applications dans un cluster
- 1: Tableau de bord (Dashboard)
- 2: Configurer l'accès à plusieurs clusters
- 3: Utiliser le Port Forwarding pour accéder à des applications dans un cluster
- 4: Utiliser un Service pour accéder à une application dans un cluster
- 5: Connecter un Frontend à un Backend en utilisant les Services
- 6: Lister toutes les images de conteneur exécutées dans un cluster
1 - Tableau de bord (Dashboard)
Le tableau de bord (Dashboard) est une interface web pour Kubernetes. Vous pouvez utiliser ce tableau de bord pour déployer des applications conteneurisées dans un cluster Kubernetes, dépanner votre application conteneurisée et gérer les ressources du cluster. Vous pouvez utiliser le tableau de bord pour obtenir une vue d'ensemble des applications en cours d'exécution dans votre cluster, ainsi que pour créer ou modifier des ressources Kubernetes individuelles. (comme des Deployments, Jobs, DaemonSets, etc). Par exemple, vous pouvez redimensionner un Deployment, lancer une mise à jour progressive, recréer un pod ou déployez de nouvelles applications à l'aide d'un assistant de déploiement.
Le tableau de bord fournit également des informations sur l'état des ressources Kubernetes de votre cluster et sur les erreurs éventuelles.
Déploiement du tableau de bord
L'interface utilisateur du tableau de bord n'est pas déployée par défaut. Pour le déployer, exécutez la commande suivante:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/charts/recommended.yaml
Accès à l'interface utilisateur du tableau de bord
Pour protéger vos données dans le cluster, le tableau de bord se déploie avec une configuration RBAC minimale par défaut. Actuellement, le tableau de bord prend uniquement en charge la connexion avec un jeton de support. Pour créer un jeton pour cette démo, vous pouvez suivre notre guide sur créer un exemple d'utilisateur.
Proxy en ligne de commande
Vous pouvez accéder au tableau de bord à l'aide de l'outil en ligne de commande kubectl en exécutant la commande suivante:
kubectl proxy
Kubectl mettra le tableau de bord à disposition à l'adresse suivante: http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/.
Vous ne pouvez accéder à l'interface utilisateur que depuis la machine sur laquelle la commande est exécutée.
Voir kubectl proxy --help
pour plus d'options.
Page de bienvenue
Lorsque vous accédez au tableau de bord sur un cluster vide, la page d'accueil s'affiche.
Cette page contient un lien vers ce document ainsi qu'un bouton pour déployer votre première application.
De plus, vous pouvez voir quelles applications système sont exécutées par défaut dans le namespace kubernetes-dashboard
de votre cluster, par exemple le tableau de bord lui-même.
Déploiement d'applications conteneurisées
Le tableau de bord vous permet de créer et de déployer une application conteneurisée en tant que Deployment et optionnellement un Service avec un simple assistant. Vous pouvez spécifier manuellement les détails de l'application ou charger un fichier YAML ou JSON contenant la configuration de l'application.
Cliquez sur le bouton CREATE dans le coin supérieur droit de n’importe quelle page pour commencer.
Spécifier les détails de l'application
L'assistant de déploiement s'attend à ce que vous fournissiez les informations suivantes:
-
App name (obligatoire): Nom de votre application. Un label avec le nom sera ajouté au Deployment et Service, le cas échéant, qui sera déployé.
Le nom de l'application doit être unique dans son namespace Kubernetes. Il doit commencer par une lettre minuscule et se terminer par une lettre minuscule ou un chiffre et ne contenir que des lettres minuscules, des chiffres et des tirets (-). Il est limité à 24 caractères. Les espaces de début et de fin sont ignorés.
-
Container image (obligatoire): L'URL d'une image de conteneur sur n'importe quel registre, ou une image privée (généralement hébergée sur le registre de conteneurs Google ou le hub Docker). La spécification d'image de conteneur doit se terminer par un deux-points.
-
Number of pods (obligatoire): Nombre cible de pods dans lesquels vous souhaitez déployer votre application. La valeur doit être un entier positif.
Un objet Deployment sera créé pour maintenir le nombre souhaité de pods dans votre cluster.
-
Service (optionnel): Pour certaines parties de votre application (par exemple les serveurs frontaux), vous souhaiterez peut-être exposer un Service sur une adresse IP externe, peut-être publique, en dehors de votre cluster (Service externe). Pour les Services externes, vous devrez peut-être ouvrir un ou plusieurs ports pour le faire. Trouvez plus de détails ici.
Les autres services visibles uniquement de l'intérieur du cluster sont appelés Services internes.
Quel que soit le type de service, si vous choisissez de créer un service et que votre conteneur écoute sur un port (entrant), vous devez spécifier deux ports. Le Service sera créé en mappant le port (entrant) sur le port cible vu par le conteneur. Ce Service acheminera le trafic vers vos pods déployés. Les protocoles pris en charge sont TCP et UDP. Le nom DNS interne de ce service sera la valeur que vous avez spécifiée comme nom d'application ci-dessus.
Si nécessaire, vous pouvez développer la section Options avancées dans laquelle vous pouvez spécifier davantage de paramètres:
-
Description: Le texte que vous entrez ici sera ajouté en tant qu'annotation au Deployment et affiché dans les détails de l'application.
-
Labels: Les labels par défaut à utiliser pour votre application sont le nom et la version de l’application. Vous pouvez spécifier des labels supplémentaires à appliquer au Deployment, Service (le cas échéant), et Pods, tels que la release, l'environnement, le niveau, la partition et la piste d'édition.
Exemple:
release=1.0 tier=frontend environment=pod track=stable
-
Namespace: Kubernetes prend en charge plusieurs clusters virtuels s'exécutant sur le même cluster physique. Ces clusters virtuels sont appelés namespaces. Ils vous permettent de partitionner les ressources en groupes nommés de manière logique.
Le tableau de bord propose tous les namespaces disponibles dans une liste déroulante et vous permet de créer un nouveau namespace. Le nom du namespace peut contenir au maximum 63 caractères alphanumériques et des tirets (-), mais ne peut pas contenir de lettres majuscules. Les noms de Namespace ne devraient pas être composés uniquement de chiffres. Si le nom est défini sous la forme d’un nombre, tel que 10, le pod sera placé dans le namespace par défaut.
Si la création du namespace réussit, celle-ci est sélectionnée par défaut. Si la création échoue, le premier namespace est sélectionné.
-
Image Pull Secret: Si l'image de conteneur spécifiée est privée, il peut être nécessaire de configurer des identifiants de pull secret.
Le tableau de bord propose tous les secrets disponibles dans une liste déroulante et vous permet de créer un nouveau secret. Le nom de secret doit respecter la syntaxe du nom de domaine DNS, par exemple.
new.image-pull.secret
. Le contenu d'un secret doit être codé en base64 et spécifié dans un fichier.dockercfg
. Le nom du secret peut contenir 253 caractères maximum.Si la création du secret d’extraction d’image est réussie, celle-ci est sélectionnée par défaut. Si la création échoue, aucun secret n'est appliqué.
-
CPU requirement (cores) et Memory requirement (MiB): Vous pouvez spécifier les limites de ressource minimales pour le conteneur. Par défaut, les pods fonctionnent avec des limites de CPU et de mémoire illimitées.
-
Run command et Run command arguments: Par défaut, vos conteneurs exécutent les valeurs par défaut de la commande d'entrée de l'image spécifiée. Vous pouvez utiliser les options de commande et les arguments pour remplacer la valeur par défaut.
-
Run as privileged: Ce paramètre détermine si les processus dans conteneurs privilégiés sont équivalents aux processus s'exécutant en tant que root sur l'hôte. Les conteneurs privilégiés peuvent utiliser des fonctionnalités telles que la manipulation de la pile réseau et l'accès aux périphériques.
-
Environment variables: Kubernetes expose ses Services via des variables d'environnement. Vous pouvez composer une variable d'environnement ou transmettre des arguments à vos commandes en utilisant les valeurs des variables d'environnement.
Ils peuvent être utilisés dans les applications pour trouver un Service. Les valeurs peuvent référencer d'autres variables à l'aide de la syntaxe$(VAR_NAME)
.
Téléchargement d'un fichier YAML ou JSON
Kubernetes supporte la configuration déclarative. Dans ce style, toute la configuration est stockée dans des fichiers de configuration YAML ou JSON à l'aide des schémas de ressources de l'API de Kubernetes.
Au lieu de spécifier les détails de l'application dans l'assistant de déploiement, vous pouvez définir votre application dans des fichiers YAML ou JSON et télécharger les fichiers à l'aide du tableau de bord.
Utilisation du tableau de bord
Les sections suivantes décrivent des vues du tableau de bord de Kubernetes; ce qu'elles fournissent et comment peuvent-elles être utilisées.
Navigation
Lorsque des objets Kubernetes sont définis dans le cluster, le tableau de bord les affiche dans la vue initiale. Par défaut, seuls les objets du namespace default sont affichés, ce qui peut être modifié à l'aide du sélecteur d'espace de nom situé dans le menu de navigation.
Le tableau de bord montre la plupart des types d'objets Kubernetes et les regroupe dans quelques catégories de menus.
Vue d'ensemble de l'administrateur
Pour les administrateurs de cluster et de namespace, le tableau de bord répertorie les noeuds, les namespaces et les volumes persistants et propose des vues de détail pour ceux-ci. La vue Liste de nœuds contient les mesures d'utilisation de CPU et de la mémoire agrégées sur tous les nœuds. La vue détaillée affiche les métriques d'un nœud, ses spécifications, son statut, les ressources allouées, les événements et les pods s'exécutant sur le nœud.
Charges de travail
Affiche toutes les applications en cours d'exécution dans le namespace selectionné. La vue répertorie les applications par type de charge de travail. (e.g., Deployments, Replica Sets, Stateful Sets, etc.) et chaque type de charge de travail peut être visualisé séparément. Les listes récapitulent les informations exploitables sur les charges de travail, telles que le nombre de Pods prêts pour un Replica Set ou l'utilisation actuelle de la mémoire pour un Pod.
Les vues détaillées des charges de travail affichent des informations sur l'état et les spécifications, ainsi que les relations de surface entre les objets. Par exemple, les Pods qu'un Replica Set controle ou bien les nouveaux Replica Sets et Horizontal Pod Autoscalers pour les Deployments.
Services
Affiche les ressources Kubernetes permettant d’exposer les services au monde externe et de les découvrir au sein d’un cluster. Pour cette raison, les vues Service et Ingress montrent les Pods ciblés par eux, les points de terminaison internes pour les connexions au cluster et les points de terminaison externes pour les utilisateurs externes.
Stockage
La vue de stockage montre les ressources Persistent Volume Claim qui sont utilisées par les applications pour stocker des données.
Config Maps et Secrets
Affiche toutes les ressources Kubernetes utilisées pour la configuration en temps réel d'applications s'exécutant dans des clusters. La vue permet d’éditer et de gérer des objets de configuration et d’afficher les secrets cachés par défaut.
Visualisation de journaux
Les listes de Pod et les pages de détail renvoient à une visionneuse de journaux intégrée au tableau de bord. Le visualiseur permet d’exploiter les logs des conteneurs appartenant à un seul Pod.
A suivre
Pour plus d'informations, voir la page du projet Kubernetes Dashboard.
2 - Configurer l'accès à plusieurs clusters
Cette page montre comment configurer l'accès à plusieurs clusters à l'aide de fichiers de configuration.
Une fois vos clusters, utilisateurs et contextes définis dans un ou plusieurs fichiers de configuration, vous pouvez basculer rapidement entre les clusters en utilisant la commande kubectl config use-context
.
kubeconfig
.
Pré-requis
Vous devez disposer d'un cluster Kubernetes et l'outil de ligne de commande kubectl doit être configuré pour communiquer avec votre cluster. Si vous ne possédez pas déjà de cluster, vous pouvez en créer un en utilisant Minikube, ou vous pouvez utiliser l'un de ces environnements Kubernetes:
Pour vérifier que kubectl est installé, executez kubectl version --client
.
La version kubectl doit être dans une version mineure de votre
serveur API du cluster.
Définir des clusters, des utilisateurs et des contextes
Supposons que vous ayez deux clusters, un pour le développement et un pour le travail scratch
.
Dans le cluster development
, vos développeurs frontend travaillent dans un espace de noms appelé frontend
, et vos développeurs de stockage travaillent dans un espace de noms appelé storage
.
Dans votre cluster scratch
, les développeurs travaillent dans le namespace par défaut ou créent des namespaces auxiliaires comme bon leur semble.
L'accès au cluster development
nécessite une authentification par certificat.
L'accès au cluster scratch
nécessite une authentification par nom d'utilisateur et mot de passe.
Créez un répertoire nommé config-exercice
.
Dans votre répertoire config-exercice
, créez un fichier nommé config-demo
avec ce contenu:
apiVersion: v1
kind: Config
preferences: {}
clusters:
- cluster:
name: development
- cluster:
name: scratch
users:
- name: developer
- name: experimenter
contexts:
- context:
name: dev-frontend
- context:
name: dev-storage
- context:
name: exp-scratch
Un fichier de configuration décrit les clusters, les utilisateurs et les contextes.
Votre fichier config-demo
a le cadre pour décrire deux clusters, deux utilisateurs et trois contextes.
Allez dans votre répertoire config-exercice
.
Entrez ces commandes pour ajouter les détails du cluster à votre fichier de configuration:
kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file
kubectl config --kubeconfig=config-demo set-cluster scratch --server=https://5.6.7.8 --insecure-skip-tls-verify
Ajoutez les détails de l'utilisateur à votre fichier de configuration:
kubectl config --kubeconfig=config-demo set-credentials developer --client-certificate=fake-cert-file --client-key=fake-key-seefile
kubectl config --kubeconfig=config-demo set-credentials experimenter --username=exp --password=some-password
- Pour supprimer un utilisateur, vous pouvez exécuter
kubectl --kubeconfig=config-demo config unset users.<name>
- Pour supprimer un cluster, vous pouvez exécuter
kubectl --kubeconfig=config-demo config unset clusters.<name>
- Pour supprimer un contexte, vous pouvez exécuter
kubectl --kubeconfig=config-demo config unset contexts.<name>
Ajoutez des détails de contexte à votre fichier de configuration:
kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer
kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=development --namespace=storage --user=developer
kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter
Ouvrez votre fichier config-demo
pour voir les détails ajoutés.
Au lieu d'ouvrir le fichier config-demo
, vous pouvez utiliser la commande kubectl config view
.
kubectl config --kubeconfig=config-demo view
La sortie montre les deux clusters, deux utilisateurs et trois contextes:
apiVersion: v1
clusters:
- cluster:
certificate-authority: fake-ca-file
server: https://1.2.3.4
name: development
- cluster:
insecure-skip-tls-verify: true
server: https://5.6.7.8
name: scratch
contexts:
- context:
cluster: development
namespace: frontend
user: developer
name: dev-frontend
- context:
cluster: development
namespace: storage
user: developer
name: dev-storage
- context:
cluster: scratch
namespace: default
user: experimenter
name: exp-scratch
current-context: ""
kind: Config
preferences: {}
users:
- name: developer
user:
client-certificate: fake-cert-file
client-key: fake-key-file
- name: experimenter
user:
password: some-password
username: exp
Le fake-ca-file
, fake-cert-file
et fake-key-file
ci-dessus sont les espaces réservés pour les noms de chemin des fichiers de certificat.
Vous devez les remplacer par les noms de chemin réels des fichiers de certificat dans votre environnement.
Parfois, vous souhaiterez peut-être utiliser des données encodées en Base64 incorporées ici au lieu de fichiers de certificat séparés; dans ce cas, vous devez ajouter le suffixe -data
aux clés, par exemple, certificate-Authority-data
, client-certificate-data
, client-key-data
.
Chaque contexte est un triplet (cluster, utilisateur, namespace).
Par exemple, le contexte dev-frontend
dit, "Utilisez les informations d'identification de l'utilisateur developer
pour accéder au namespace frontend
du cluster development
".
Définissez le contexte actuel:
kubectl config --kubeconfig=config-demo use-context dev-frontend
Maintenant, chaque fois que vous entrez une commande kubectl
, l'action s'appliquera au cluster et au namespace répertorié dans le contexte dev-frontend
.
Et la commande utilisera les informations d'identification de l'utilisateur répertoriées dans le contexte dev-frontend
.
Pour voir uniquement les informations de configuration associées au contexte actuel, utilisez l'indicateur --minify
.
kubectl config --kubeconfig=config-demo view --minify
La sortie affiche les informations de configuration associées au contexte dev-frontend
:
apiVersion: v1
clusters:
- cluster:
certificate-authority: fake-ca-file
server: https://1.2.3.4
name: development
contexts:
- context:
cluster: development
namespace: frontend
user: developer
name: dev-frontend
current-context: dev-frontend
kind: Config
preferences: {}
users:
- name: developer
user:
client-certificate: fake-cert-file
client-key: fake-key-file
Supposons maintenant que vous souhaitiez travailler pendant un certain temps dans le cluster scratch.
Changez le contexte actuel en exp-scratch
:
kubectl config --kubeconfig=config-demo use-context exp-scratch
Maintenant, toute commande kubectl
que vous donnez s'appliquera au namespace par défaut du cluster scratch
.
Et la commande utilisera les informations d'identification de l'utilisateur répertoriées dans le contexte exp-scratch
.
Afficher la configuration associée au nouveau contexte actuel, exp-scratch
.
kubectl config --kubeconfig=config-demo view --minify
Enfin, supposons que vous vouliez travailler pendant un certain temps dans le namespace storage
du cluster development
.
Changez le contexte actuel en dev-storage
:
kubectl config --kubeconfig=config-demo use-context dev-storage
Afficher la configuration associée au nouveau contexte actuel, dev-storage
.
kubectl config --kubeconfig=config-demo view --minify
Créer un deuxième fichier de configuration
Dans votre répertoire config-exercice
, créez un fichier nommé config-demo-2
avec ce contenu:
apiVersion: v1
kind: Config
preferences: {}
contexts:
- context:
cluster: development
namespace: ramp
user: developer
name: dev-ramp-up
Le fichier de configuration précédent définit un nouveau contexte nommé dev-ramp-up
.
Définissez la variable d'environnement KUBECONFIG
Vérifiez si vous avez une variable d'environnement nommée KUBECONFIG
.
Si tel est le cas, enregistrez la valeur actuelle de votre variable d'environnement KUBECONFIG
, afin de pouvoir la restaurer ultérieurement.
Par exemple:
Linux
export KUBECONFIG_SAVED=$KUBECONFIG
Windows PowerShell
$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
La variable d'environnement KUBECONFIG
est une liste de chemins vers les fichiers de configuration.
La liste est délimitée par deux-points pour Linux et Mac et par des points-virgules pour Windows.
Si vous avez une variable d'environnement KUBECONFIG
, familiarisez-vous avec les fichiers de configuration de la liste.
Ajoutez temporairement deux chemins à votre variable d'environnement KUBECONFIG
.
Par exemple:
Linux
export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
Windows PowerShell
$Env:KUBECONFIG=("config-demo;config-demo-2")
Dans votre répertoire config-exercice
, entrez cette commande:
kubectl config view
La sortie affiche les informations fusionnées de tous les fichiers répertoriés dans votre variable d'environnement KUBECONFIG
.
En particulier, notez que les informations fusionnées ont le contexte dev-ramp-up
du fichier config-demo-2
et les trois contextes du fichier config-demo
:
contexts:
- context:
cluster: development
namespace: frontend
user: developer
name: dev-frontend
- context:
cluster: development
namespace: ramp
user: developer
name: dev-ramp-up
- context:
cluster: development
namespace: storage
user: developer
name: dev-storage
- context:
cluster: scratch
namespace: default
user: experimenter
name: exp-scratch
Pour plus d'informations sur la manière dont les fichiers kubeconfig sont fusionnés, consultez Organisation de l'accès au cluster à l'aide des fichiers kubeconfig
Explorez le répertoire $HOME/.kube
Si vous avez déjà un cluster, et vous pouvez utiliser kubectl
pour interagir avec le cluster, alors vous avez probablement un fichier nommé config
dans le repertoire $HOME/.kube
.
Allez dans $ HOME/.kube
, et voyez quels fichiers sont là.
En règle générale, il existe un fichier nommé config
.
Il peut également y avoir d'autres fichiers de configuration dans ce répertoire.
Familiarisez-vous brièvement avec le contenu de ces fichiers.
Ajoutez $HOME/.kube/config à votre variable d'environnement KUBECONFIG
Si vous avez un fichier $ HOME/.kube/config
, et qu'il n'est pas déjà répertorié dans votre variable d'environnement KUBECONFIG
, ajoutez-le maintenant à votre variable d'environnement KUBECONFIG
.
Par exemple:
Linux
export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
Windows Powershell
$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"
Affichez les informations de configuration fusionnées à partir de tous les fichiers qui sont maintenant répertoriés dans votre variable d'environnement KUBECONFIG
.
Dans votre répertoire config-exercice, entrez:
kubectl config view
Nettoyage
Remettez votre variable d'environnement KUBECONFIG
à sa valeur d'origine.
Par exemple:
Linux
export KUBECONFIG=$KUBECONFIG_SAVED
Windows PowerShell
$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
A suivre
3 - Utiliser le Port Forwarding pour accéder à des applications dans un cluster
Cette page montre comment utiliser kubectl port-forward
pour se connecter à un serveur MongoDB s'exécutant dans un cluster Kubernetes.
Ce type de connexion peut être utile pour le debug d'une base de données.
Pré-requis
Vous devez disposer d'un cluster Kubernetes et l'outil de ligne de commande kubectl doit être configuré pour communiquer avec votre cluster. Si vous ne possédez pas déjà de cluster, vous pouvez en créer un en utilisant Minikube, ou vous pouvez utiliser l'un de ces environnements Kubernetes:
Votre serveur Kubernetes doit être au moins à la version v1.10. Pour consulter la version, entrezkubectl version
.- Installez MongoDB Shell.
Création du déploiement et du service MongoDB
-
Créez un déploiement qui exécute MongoDB :
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
Le résultat d'une commande réussie doit valider que le déploiement a bien été créé :
deployment.apps/mongo créé
Affichez l'état du pod pour vérifier qu'il est prêt :
kubectl get pods
Le résultat doit lister le pod créé :
NOM PRÊT STATUT REDÉMARRAGES ÂGE mongo-75f59d57f4-4nd6q 1/1 Running 0 2m4s
Affichez l'état du déploiement :
kubectl get deployment
Le résultat affiche que le déploiement a bien été créé :
NOM PRÊT ACTUALISÉ DISPONIBLE ÂGE mongo 1/1 1 1 2m21s
Le déploiement gère automatiquement un ReplicaSet. Affichez l'état du ReplicaSet à l'aide de la commande :
kubectl get replicaset
Le résultat affiche que le ReplicaSet a bien été créé :
NOM DÉSIRÉ ACTUEL PRÊT ÂGE mongo-75f59d57f4 1 1 1 3m12s
-
Créez un service pour exposer MongoDB sur le réseau :
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
Le résultat d'une commande réussie vérifie que le service a été créé :
service/mongo créé
Vérifiez que le service a été créé :
kubectl get service mongo
Le résultat affiche le service qui vient d'être créé :
NOM TYPE CLUSTER-IP EXTERNAL-IP PORT(S) ÂGE mongo ClusterIP 10.96.41.183 <none> 27017/TCP 11s
-
Vérifiez que le serveur MongoDB s'exécute dans le pod et écoute sur le port 27017 :
# Changez mongo-75f59d57f4-4nd6q par le nom du pod kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
Le résultat affiche le port pour MongoDB dans ce pod :
27017
27017 est le port TCP attribué à MongoDB sur Internet.
Rediriger un port local vers un port du pod
-
kubectl port-forward
permet d'utiliser un nom de ressource, tel qu'un nom de pod, pour sélectionner un pod correspondant vers lequel rediriger le port.# Changez mongo-75f59d57f4-4nd6q par le nom du pod kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017
qui est identique à
kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017
ou
kubectl port-forward deployment/mongo 28015:27017
ou
kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017
ou
kubectl port-forward service/mongo 28015:27017
N'importe laquelle des commandes ci-dessus fonctionne. Le résultat sera similaire à ceci :
Forwarding from 127.0.0.1:28015 -> 27017 Forwarding from [::1]:28015 -> 27017
Note:kubectl port-forward
ne se termine pas une fois le port-forward lancé. Pour continuer avec les exercices, vous devrez ouvrir un autre terminal. -
Démarrez l'interface de ligne de commande MongoDB :
mongosh --port 28015
-
Depuis la ligne de commande de MongoDB, entrez la commande
ping
:db.runCommand( { ping: 1 } )
Une demande de ping réussie renvoie :
{ ok: 1 }
Laisser kubectl choisir le port local
Si vous n'avez pas besoin d'un port local précis,
vous pouvez laisser kubectl
choisir et attribuer le port local,
vous évitant ainsi de gérer les conflits de ports locaux, avec cette syntaxe légèrement plus simple :
kubectl port-forward deployment/mongo :27017
kubectl
trouvera un numéro de port local qui n'est pas utilisé
(en évitant les numéros de ports bas, car ils pourraient être utilisés par d'autres applications).
Le résultat sera similaire à :
Forwarding from 127.0.0.1:63753 -> 27017
Forwarding from [::1]:63753 -> 27017
Discussion
Les connexions établies sur le port local 28015 sont redirigées vers le port 27017 du pod qui exécute le serveur MongoDB. Avec cette connexion en place, vous pouvez utiliser votre poste de travail local pour debug la base de données MongoDB qui s'exécute dans le pod.
kubectl port-forward
est implémenté pour les ports TCP uniquement. La prise en charge du protocole UDP est suivie dans l'issue 47862.
A suivre
En savoir plus sur kubectl port-forward.
4 - Utiliser un Service pour accéder à une application dans un cluster
Cette page montre comment créer un Service Kubernetes que des clients externes peuvent utiliser pour accéder à une application s'exécutant dans un cluster. Le Service fournit une répartition de charge pour une application ayant deux instances en cours d'exécution.
Pré-requis
Vous devez disposer d'un cluster Kubernetes et l'outil de ligne de commande kubectl doit être configuré pour communiquer avec votre cluster. Si vous ne possédez pas déjà de cluster, vous pouvez en créer un en utilisant Minikube, ou vous pouvez utiliser l'un de ces environnements Kubernetes:
Objectifs
- Exécuter deux instances d'une application Hello World.
- Créer un Service qui expose un port du nœud.
- Utiliser le Service pour accéder à l'application en cours d'exécution.
Création d'un service pour une application s'exécutant dans deux pods
Voici le fichier de configuration pour le déploiement de l'application :
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-world
spec:
selector:
matchLabels:
run: load-balancer-example
replicas: 2
template:
metadata:
labels:
run: load-balancer-example
spec:
containers:
- name: hello-world
image: gcr.io/google-samples/node-hello:1.0
ports:
- containerPort: 8080
protocol: TCP
-
Exécutez une application Hello World dans votre cluster : Créez le déploiement de l'application en utilisant le fichier ci-dessus :
kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
La commande précédente crée un Deployment et un ReplicaSet associé. Le ReplicaSet possède deux Pods, chacun exécutant l'application Hello World.
-
Affichez les informations du déploiement :
kubectl get deployments hello-world kubectl describe deployments hello-world
-
Affichez les informations des ReplicaSet :
kubectl get replicasets kubectl describe replicasets
-
Créez un Service qui expose le déploiement :
kubectl expose deployment hello-world --type=NodePort --name=example-service
-
Affichez les informations sur le Service :
kubectl describe services example-service
Le résultat sera similaire à ceci :
Name: example-service Namespace: default Labels: run=load-balancer-example Annotations: <none> Selector: run=load-balancer-example Type: NodePort IP: 10.32.0.16 Port: <unset> 8080/TCP TargetPort: 8080/TCP NodePort: <unset> 31496/TCP Endpoints: 10.200.1.4:8080,10.200.2.5:8080 Session Affinity: None Events: <none>
Notez la valeur de NodePort pour le service. Par exemple, dans le résultat précédent, la valeur de NodePort est 31496.
-
Répertoriez les pods qui exécutent l'application Hello World :
kubectl get pods --selector="run=load-balancer-example" --output=wide
Le résultat est similaire à ceci :
NAME READY STATUS ... IP NODE hello-world-2895499144-bsbk5 1/1 Running ... 10.200.1.4 worker1 hello-world-2895499144-m1pwt 1/1 Running ... 10.200.2.5 worker2
-
Obtenez l'adresse IP publique de l'un de vos nœuds qui exécute un pod Hello World. L'obtention de cette adresse dépend de la manière dont vous avez configuré votre cluster. Par exemple, si vous utilisez Minikube, vous pouvez voir l'adresse du nœud en exécutant
kubectl cluster-info
. Si vous utilisez des instances Google Compute Engine, vous pouvez utiliser la commandegcloud compute instances list
pour voir les adresses publiques de vos nœuds. -
Sur le nœud choisi, créez une règle de pare-feu autorisant le trafic TCP sur votre port. Par exemple, si votre Service a une valeur NodePort de 31568, créez une règle de pare-feu autorisant le trafic TCP vers le port 31568. Différents fournisseurs cloud offrent différentes façons de configurer des règles de pare-feu.
-
Utilisez l'adresse du nœud et le port de nœud pour accéder à l'application Hello World :
curl http://<adresse-ip-publique>:<port>
où
<adresse-ip-publique>
est l'adresse IP publique de votre nœud, et<port>
est la valeur de NodePort pour votre service. La réponse à une requête réussie est un message de bienvenue :Hello Kubernetes!
Utilisation d'un fichier de configuration de service
Au lieu d'utiliser kubectl expose
, vous pouvez utiliser un
fichier de configuration de service
pour créer un Service.
Cleanup
Pour supprimer le Service, saisissez cette commande :
kubectl delete services example-service
Pour supprimer le Déploiement, le ReplicaSet et les Pods qui exécutent l'application Hello World, saisissez cette commande :
kubectl delete deployment hello-world
A suivre
Suivez le tutoriel Connecter des applications avec les Services.
5 - Connecter un Frontend à un Backend en utilisant les Services
Cette tâche montre comment créer un microservice frontend et un microservice backend. Le backend renvoie un message de salutations à chaque requête. Le frontend expose le backend en utilisant Nginx et un Service Kubernetes.
Objectifs
- Créer et exécuter un microservice backend
hello
en utilisant un Déploiement. - Utiliser un Service pour envoyer du trafic vers les multiples réplicas du microservice backend.
- Créer et exécuter un microservice frontend
nginx
, en utilisant également un Deployment. - Configurer le microservice frontend pour envoyer du trafic vers le microservice backend.
- Utiliser un Service de type
LoadBalancer
pour exposer le microservice frontend en dehors du cluster.
Pré-requis
Vous devez disposer d'un cluster Kubernetes et l'outil de ligne de commande kubectl doit être configuré pour communiquer avec votre cluster. Si vous ne possédez pas déjà de cluster, vous pouvez en créer un en utilisant Minikube, ou vous pouvez utiliser l'un de ces environnements Kubernetes:
Pour consulter la version, entrezkubectl version
.
Cette tâche utilise les Services avec des équilibreurs de charge externes, qui nécessitent un environnement spécifique. Si votre environnement ne prend pas en charge cette fonction, vous pouvez utiliser un Service de type NodePort à la place.
Création du backend à l'aide d'un Deployment
Le backend est un simple microservice de salutations. Voici le fichier de configuration pour le Deployment backend :
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: backend
spec:
selector:
matchLabels:
app: hello
tier: backend
track: stable
replicas: 3
template:
metadata:
labels:
app: hello
tier: backend
track: stable
spec:
containers:
- name: hello
image: "gcr.io/google-samples/hello-go-gke:1.0"
ports:
- name: http
containerPort: 80
...
Créez le Deployment backend :
kubectl apply -f https://k8s.io/examples/service/access/backend-deployment.yaml
Affichez les informations du Deployment:
kubectl describe deployment backend
Le retour sera similaire à celui-ci:
Name: backend
Namespace: default
CreationTimestamp: Mon, 24 Oct 2016 14:21:02 -0700
Labels: app=hello
tier=backend
track=stable
Annotations: deployment.kubernetes.io/revision=1
Selector: app=hello,tier=backend,track=stable
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
Pod Template:
Labels: app=hello
tier=backend
track=stable
Containers:
hello:
Image: "gcr.io/google-samples/hello-go-gke:1.0"
Port: 80/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: hello-3621623197 (3/3 replicas created)
Events:
...
Création du Service hello
La solution pour envoyer des requêtes d'un frontend vers un backend est le Service backend
.
Un Service crée une adresse IP persistante et un enregistrement DNS afin que le microservice backend puisse toujours être joignable.
Un Service utilise des sélecteurs pour trouver les Pods vers lesquels acheminer le trafic.
Tout d'abord, explorez le fichier de configuration du Service :
---
apiVersion: v1
kind: Service
metadata:
name: hello
spec:
selector:
app: hello
tier: backend
ports:
- protocol: TCP
port: 80
targetPort: http
...
Dans le fichier de configuration, vous pouvez voir que le Service,
nommé hello
, achemine le trafic vers les Pods ayant les labels app: hello
et tier: backend
.
Créez le Service backend :
kubectl apply -f https://k8s.io/examples/service/access/backend-service.yaml
À ce stade, vous avez un Deployment backend
exécutant trois réplicas de votre application hello
,
et un Service capable d'acheminer le trafic vers celles-ci.
Cependant, ce service n'est ni disponible, ni résolvable en dehors du cluster.
Création du frontend
Maintenant que votre backend est opérationnel, vous pouvez créer un frontend accessible en dehors du cluster, qui se connecte au backend en acheminant les requêtes vers celui-ci.
Le frontend envoie des requêtes aux Pods du backend en utilisant le nom DNS attribué au Service backend.
Le nom DNS est hello
, qui est la valeur du champ name
dans le fichier de configuration examples/service/access/backend-service.yaml
.
Les Pods du frontend Deployment exécutent une image nginx
configurée pour acheminer les requêtes vers le Service backend hello
.
Voici le fichier de configuration nginx :
# The identifier Backend is internal to nginx, and used to name this specific upstream
upstream Backend {
# hello is the internal DNS name used by the backend Service inside Kubernetes
server hello;
}
server {
listen 80;
location / {
# The following statement will proxy traffic to the upstream named Backend
proxy_pass http://Backend;
}
}
Comme pour le backend, le frontend dispose d'un Deployment et d'un Service.
Une différence importante à noter entre les services backend et frontend est que
le Service frontend est configuré avec un type: LoadBalancer
, ce qui signifie que le Service utilise
un équilibreur de charge provisionné par votre fournisseur de cloud et sera accessible depuis l'extérieur du cluster.
---
apiVersion: v1
kind: Service
metadata:
name: frontend
spec:
selector:
app: hello
tier: frontend
ports:
- protocol: "TCP"
port: 80
targetPort: 80
type: LoadBalancer
...
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: frontend
spec:
selector:
matchLabels:
app: hello
tier: frontend
track: stable
replicas: 1
template:
metadata:
labels:
app: hello
tier: frontend
track: stable
spec:
containers:
- name: nginx
image: "gcr.io/google-samples/hello-frontend:1.0"
lifecycle:
preStop:
exec:
command: ["/usr/sbin/nginx","-s","quit"]
...
Créez le Deployment et le Service frontend :
kubectl apply -f https://k8s.io/examples/service/access/frontend-deployment.yaml
kubectl apply -f https://k8s.io/examples/service/access/frontend-service.yaml
Le retour valide la création des deux ressources:
deployment.apps/frontend created
service/frontend created
Interagir avec le Service frontend
Une fois que vous avez créé un Service de type LoadBalancer, vous pouvez utiliser cette commande pour trouver l'IP externe :
kubectl get service frontend --watch
Cela affiche la configuration du Service frontend
et surveille les changements.
Initialement, l'IP externe est indiquée comme <pending>
:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend LoadBalancer 10.51.252.116 <pending> 80/TCP 10s
Dès qu'une IP externe est attribuée, cependant,
la configuration est mise à jour pour inclure la nouvelle IP sous l'en-tête EXTERNAL-IP
:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend LoadBalancer 10.51.252.116 XXX.XXX.XXX.XXX 80/TCP 1m
Cette IP peut maintenant être utilisée pour interagir avec le service frontend
depuis l'extérieur du cluster.
Envoyer du trafic via le frontend
Le frontend et le backend sont maintenant connectés. Vous pouvez accéder à l'endpoint en utilisant la commande curl sur l'IP externe de votre Service frontend.
curl http://${EXTERNAL_IP} # à remplacer par l'ip externe affichée précédemment
Le résultat affiche le message généré par le backend :
{"message":"Hello"}
Cleanup
Pour supprimer les Services, saisissez cette commande :
kubectl delete services frontend backend
Pour supprimer les Deployments, les ReplicaSets et les Pods qui exécutent les applications backend et frontend, saisissez cette commande :
kubectl delete deployment frontend backend
A suivre
- En savoir plus sur les Services
- En savoir plus sur les ConfigMaps
- En savoir plus sur le DNS pour les Services et les Pods
6 - Lister toutes les images de conteneur exécutées dans un cluster
Cette page montre comment utiliser kubectl pour répertorier toutes les images de conteneur pour les pods s'exécutant dans un cluster.
Pré-requis
Vous devez disposer d'un cluster Kubernetes et l'outil de ligne de commande kubectl doit être configuré pour communiquer avec votre cluster. Si vous ne possédez pas déjà de cluster, vous pouvez en créer un en utilisant Minikube, ou vous pouvez utiliser l'un de ces environnements Kubernetes:
Pour consulter la version, entrezkubectl version
.
Dans cet exercice, vous allez utiliser kubectl pour récupérer tous les pods exécutés dans un cluster et formater la sortie pour extraire la liste des conteneurs pour chacun.
Répertorier toutes les images de conteneurs dans tous les namespaces
- Récupérez tous les pods dans tous les namespace à l'aide de
kubectl get pods --all-namespaces
- Formatez la sortie pour inclure uniquement la liste des noms d'image de conteneur à l'aide de
-o jsonpath={.items[*].spec.containers[*].image}
. Cela analysera récursivement le champimage
du json retourné.- Voir la reference jsonpath pour plus d'informations sur l'utilisation de jsonpath.
- Formatez la sortie à l'aide des outils standard:
tr
,sort
,uniq
- Utilisez
tr
pour remplacer les espaces par des nouvelles lignes - Utilisez
sort
pour trier les résultats - Utilisez
uniq
pour agréger le nombre d'images
- Utilisez
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
tr -s '[[:space:]]' '\n' |\
sort |\
uniq -c
La commande ci-dessus renverra récursivement tous les champs nommés image
pour tous les éléments retournés.
Comme alternative, il est possible d'utiliser le chemin absolu vers le champ d'image dans le Pod.
Cela garantit que le champ correct est récupéré même lorsque le nom du champ est répété, par ex. de nombreux champs sont appelés name
dans un élément donné:
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"
Le jsonpath est interprété comme suit:
.items[*]
: pour chaque valeur renvoyée.spec
: obtenir les spécifications.containers[*]
: pour chaque conteneur.image
: obtenir l'image
kubectl get pod nginx
, la portion .items[*]
du chemin doit être omis car un seul pod est renvoyé au lieu d'une liste d'éléments.
Liste des images de conteneurs par pod
Le formatage peut être contrôlé davantage en utilisant l'opération range
pour parcourir les éléments individuellement.
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort
Filtrage des images de conteneur de liste par label de pod
Pour cibler uniquement les pods correspondant à un label spécifique, utilisez l'indicateur -l.
Les éléments suivants correspondent uniquement aux pods avec les labels app=nginx
.
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
Filtrage des images de conteneur de liste par namespace de pod
Pour cibler uniquement les pods dans un namespace spécifique, utilisez l'indicateur de namespace.
Ce qui suit correspond uniquement aux pods du namespace kube-system
.
kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}"
Répertorier les images de conteneurs en utilisant un go-template au lieu de jsonpath
Comme alternative à jsonpath, Kubectl peut aussi utiliser les go-templates pour formater la sortie:
kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
A suivre
Reference
- Guide de référence pour Jsonpath
- Guide de référence pour les Go template