Ressources Hosteur

Explorons ensemble les technologies de demain

  1. Accueil
  2.  > 
  3. HWS
  4.  > 
  5. Ressources
  6.  > 
  7. Rubrique Aide Hosteur


   Votre espace client
   Hosteur Emailing
   Gestion des services
   Hosteur Ragnarokkr
Menu Ragnarokkr 13. HEBERGEMENT DE KUBERNETES RAGNARØKKR Marketplace
   FAQ
   FAQ FlexOne
13.4. DEPLOIEMENT DE L'APPLICATION

13.4. DEPLOIEMENT DE L'APPLICATION

13.4.1. Cluster Kubernetes - intégration de Helm
13.4.2. Cluster Kubernetes - déploiements YAML
13.4.3. Cluster Kubernetes : mise en réseau interne
13.4.4. Cluster Kubernetes - exposition des services
13.4.5. Cluster Kubernetes - création d’ingresses

 

 

13.4.1. Cluster Kubernetes : intégration de Helm

 

Kubernetes offre de multiples options pour le déploiement des applications. Ainsi, l'une des méthodes les plus courantes consiste à utiliser le gestionnaire de package Helm. Il permet d'installer des applications Kubernetes à partir de dépôts distants ainsi que de créer des Charts Helm locales. Le CLI Helm communique avec un service appelé Tiller qui déclenche l'API Kubernetes pour créer des objets tels que des déploiements, des services, des Persistent Volume Claims, etc.

 

Helm est disponible par défaut sur tous les nœuds maîtres du Cluster Kubernetes et ne nécessite aucune configuration supplémentaire.

 

Remarque : le gestionnaire de package est automatiquement mis à jour lors des mises à niveau du Cluster Kubernetes.

 

1. Vous pouvez voir quels charts sont disponibles en exécutant la commande helm search.

 

2. L'installation d'une application avec Helm est aussi simple que l'exécution de la commande helm install avec la solution requise (énumérée dans l’image de l'étape précédente). Par exemple, pour installer WordPress :

 

De plus, Helm propose un CLI riche en fonctionnalités pour gérer les charts existants et packager vos applications.

 

 

13.4.2. Cluster Kubernetes : déploiements YAML

 

Kubernetes supporte nativement les déploiements à partir des fichiers JSON et YAML. Cependant, au sein de la communauté, YAML est une option plus fréquente et peut être considéré comme un standard.

 

Le déploiement à partir des YAML est quelque peu similaire aux charts de Helm : le fichier .yaml ou .yml fournit une définition des objets ou une liste d'objets. Il peut donc être appliqué directement dans le tableau de bord Kubernetes ou avec l'outil de ligne de commande Kubectl sans installation de logiciel supplémentaire.

 

kubernetes dashboard deploy application with yaml

 

Lorsque vous travaillez sur Kubectl, utilisez la commande apply avec le chemin d'accès correct à votre fichier de déploiement YAML :

 

D'autre part, l'avantage des charts de Helm est la flexibilité avancée (support des conditions, remplacements, paramètres, etc).

 

 

13.4.3. Cluster Kubernetes : mise en réseau interne

La configuration de la mise en réseau interne au sein du Cluster Kubernetes est un processus entièrement automatisé, qui repose sur les Services K8s (https://kubernetes.io/fr/docs/concepts/services-networking/service/#d%c3%a9finition-dun-service). Le plugin CNI crée et configure un réseau superposé, qui permet de fournir tous les pods avec les adresses IP.

 

De plus, Kubernetes permet un accès direct aux services par leurs noms, le mécanisme de découverte de services n'est donc pas nécessaire. Par exemple, votre serveur d'application peut se connecter à la base de données en utilisant son nom DNS, qui sera déterminé comme une IP interne requise. Il vous suffit donc de créer un objet service avec le sélecteur approprié.

 

Le Cluster Kubernetes est fourni avec le déploiement, le service et l'entrée réseau (ingress) Hello World par défaut (sauf si l'option de déploiement personnalisé a été sélectionnée lors de l'installation). Vous pouvez examiner cette application par défaut pour mieux comprendre le concept du service Kubernetes.

 

 

 

Résolution des noms DNS dans les Pods

Le Cluster Kubernetes de RAGNARØKKR utilise CoreDNS pour résoudre les noms DNS internes de Kubernetes. Il est automatiquement défini dans le fichier /etc/resolv.conf de chaque pod. De plus, CoreDNS utilise les serveurs de noms RAGNARØKKR, ce qui permet d'établir un accès direct entre le Cluster K8s et d'autres conteneurs à l'intérieur de la plateforme.

 

Par exemple, si vous avez un environnement avec une base de données dans RAGNARØKKR et que vous voulez vous y connecter à partir de votre pod Kubernetes, vous devez utiliser le nom d'hôte « ${IDnœud}-${NomEnv}.${platformDomain} » (où {platformDomain} = rag-cloud.hosteur.com (France) ou rag-cloud-ch.hosteur.com (Suisse)) et le port par défaut de votre base de données (3306 pour MySQL, 5432 pour Postgres, etc).

 

Cependant, vous devez créer un point d’arrivée (https://www.hosteur.com/ressources/aide/p-points-darrivee-une-connexion-directe-au-cloud) pour vous connecter à une telle base de données depuis l'extérieur de RAGNARØKKR.

 

 

13.4.4. Cluster Kubernetes - exposition des services

 

Les composants de votre application peuvent communiquer entre eux par des noms de service en utilisant le réseau interne, mais les connexions externes nécessitent des configurations supplémentaires.

 

La façon la plus simple d'établir une connexion externe à un service est de l'exposer directement via NodePort (https://kubernetes.io/fr/docs/concepts/services-networking/service/#nodeport). Comme son nom l'indique, ce type de service ouvre un port spécifique sur les nœuds, tout trafic envoyé à ce port est transmis à votre service. Par défaut, le nodePort de votre service est sélectionné de manière aléatoire dans la plage 30000-32767.

 

Remarque : cette méthode présente plusieurs inconvénients dont il faut tenir compte lors de la configuration du Kubernetes Cluster (un service par port, plage restreinte de ports, etc). Par conséquent, le type de service NodePort peut être utilisé pour la démo ou d'autres applications temporaires. Toutefois, les solutions de production nécessitent généralement un accès externe plus permanent. Par exemple, des entrées (ingress).

 

1. Voici un exemple de configuration de service de type NodePort :

 

Remarque : sachez que RAGNARØKKR PaaS ne prend pas en charge le type de service LoadBalancer actuellement. Si vous appliquez YAML ou des Charts Helm avec un tel objet de service, vous devez le convertir en NodePort ou créer des entrées (ingress) pour l'accès externe.

 

2. Si nécessaire, un nodePort particulier peut être sélectionné pour votre service. Par exemple, le code suivant peut être utilisé pour configurer une redirection à partir du port 30984 :

 

Remarque : la valeur du nodePort fournie manuellement doit être comprise dans la plage autorisée (30000-32767) et être unique (pour éviter toute collision avec d'autres services).

 

3. Si une IP publique est rattachée aux nœuds workers de Kubernetes, aucune action supplémentaire n'est nécessaire.

Dans le cas contraire, le port obtenu doit être exposé du côté de RAGNARØKKR. Naviguez jusqu'aux Paramètres > Points d'arrivée de l'environnement Kubernetes et cliquez sur Ajouter. Fournissez ensuite les données suivantes :

  • Nœud : choisissez n'importe quel nœud worker dans la liste
  • Nom : définissez le nom du point d'arrivée
  • Port privé : fournissez le nodePort de l'étape précédente
  • Protocole : sélectionnez l'option TCP

 

 

Cliquez sur Ajouter pour confirmer. Cela peut prendre quelques minutes pour que RAGNARØKKR expose un port et redirige les demandes vers le service NodePort.

 

13.4.5. Cluster Kubernetes - création d’ingresses

L’Ingress (https://kubernetes.io/fr/docs/concepts/services-networking/ingress/) est un équilibreur de charge du Cluster Kubernetes qui gère l'accès externe aux services, fournit une terminaison SSL et un hébergement virtuel basé sur le nom. Il est géré par un ensemble de règles (spec) qui sont comparées à toutes les demandes entrantes.

 

Conseil : Par rapport au service exposé via NodePort, l'ingress est une option plus puissante mais aussi plus compliquée qui est particulièrement utile lorsque vous devez exposer plusieurs services sous une même adresse IP. En outre, les ingresses sont gérés par un contrôleur, qui offre de nombreuses fonctionnalités prêtes à l'emploi (SSL, authentification, routage, etc).

 

Les ingresses dans le Cluster Kubernetes sont gérés par le contrôleur d'ingress Traefik (https://docs.traefik.io/v1.7/user-guide/kubernetes/) par défaut, avec les options HAProxy et NGINX. Il surveille les objets, analyse les specs/annotations et les traduit en règles de redirection.

 

Note : Il n'est pas possible de changer le contrôleur d'ingress sélectionné via l'add-on de gestion Kubernetes ou un autre outil d'automatisation après l'installation. L'opération peut toujours être effectuée manuellement, n'hésitez pas à contacter notre assistance si vous avez besoin d'aide.

 

Un spec d'ingress est une combinaison d'une règle de cheminement (path), d'un service backend et d'un port. Par exemple, votre ingress peut se présenter comme suit :

 

Cet exemple expose le service myapp, qui est lié au port 8080 sur un chemin de votre domaine par défaut de l'environnement Kubernetes avec le suffixe /myapp (c'est-à-dire https://${NomEnv}.${platformDomain}/myapp avec {platformDomain} = rag-cloud.hosteur.com (France) ou rag-cloud-ch.hosteur.com (Suisse)). Pour de plus amples informations sur la configuration des règles d'ingress (y compris le routage basé sur le chemin et les sous-domaines), veuillez vous référer à la documentation officielle : https://kubernetes.io/fr/docs/concepts/services-networking/ingress/#ingress-rules.

 

 

Nombre de domaines: 126140 Sites: 23460 Serveurs: 9772 Clients: 106003 SSL: 5712 Tickets traités: 1617955

10% de réduction sur votre prochaine commande(1)
Inscrivez-vous à notre NEWSLETTER pour recevoir votre code de réduction
(1) Valable uniquement pour toutes nouvelles commandes, hors achat de crédit hosteur et hors renouvellement de prestation.