Version imprimable multipages. Cliquer ici pour imprimer.

Retour à la version par défaut.

Accès aux applications 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.

Tableau de bord Kubernetes

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.

Page d'accueil du tableau de bord Kubernetes

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.

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.

Visualisation de journaux

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.

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

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, entrez kubectl version.
  • Installez MongoDB Shell.

Création du déploiement et du service MongoDB

  1. 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

  2. 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

  3. 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

  1. 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

  2. Démarrez l'interface de ligne de commande MongoDB :

    mongosh --port 28015

  3. 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.

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 :

service/access/hello-application.yaml 
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

  1. 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.

  2. Affichez les informations du déploiement :

    kubectl get deployments hello-world
kubectl describe deployments hello-world

  3. Affichez les informations des ReplicaSet :

    kubectl get replicasets
kubectl describe replicasets

  4. Créez un Service qui expose le déploiement :

    kubectl expose deployment hello-world --type=NodePort --name=example-service

  5. 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.

  6. 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

  7. 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 commande gcloud compute instances list pour voir les adresses publiques de vos nœuds.

  8. 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.

  9. 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, entrez kubectl 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 :

service/access/backend-deployment.yaml 
---
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 :

service/access/backend-service.yaml 
---
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 :

service/access/frontend-nginx.conf 
# 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.

service/access/frontend-service.yaml 
---
apiVersion: v1
kind: Service
metadata:
  name: frontend
spec:
  selector:
    app: hello
    tier: frontend
  ports:
  - protocol: "TCP"
    port: 80
    targetPort: 80
  type: LoadBalancer
...
service/access/frontend-deployment.yaml 
---
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

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, entrez kubectl 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 champ image du json retourné.
  • 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
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

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