Au croisement, l'orchestre n'est
pas changé.
Après avoir été complètement fatigué de Docker Swarm en raison de sa pseudo-simplicité et de sa finition constante, du travail peu pratique avec des systèmes de fichiers distribués, d'une interface Web légèrement humide et de fonctionnalités étroites, ainsi que du manque de support de l'intégration GitLab «prête à l'emploi», il a été décidé de déployer votre cluster Kubernetes sur votre propre matériel, à savoir en déployant Rancher Management Server 2.0.
Expérience d'installation, schéma de tolérance aux pannes, travail avec haProxy et deux tableaux de bord sous le chat:
Données d'entrée:Serveur hôte HP Proliant DL320e Gen8 - 2 pcs.
VM Ubuntu Server 16.04, 2 Go de RAM, 2 vCPU, 20 Go de disque dur - 1 pc. sur chaque hĂ´te (VM-haProxy).
VM Ubuntu Server 16.04, 4 Go de RAM, 4 vCPU, 40 Go de disque dur, 20 Go de SSD - 3 pièces. sur chaque hôte (VM - * - Cluster).
VM Ubuntu Server 16.04, 4 Go de RAM, 4 vCPU, 100 Go de disque dur - 1 pc. sur n'importe quel hĂ´te (VM-NFS).
Diagramme du réseau:
Pour commencer:VM-haProxy a des règles haProxy, fail2ban, iptables à bord. Agit comme une passerelle pour toutes les machines derrière elle. Nous avons deux passerelles et toutes les machines en cas de perte de communication de passerelle sur leur hôte passeront à une autre.
La tâche principale de ces nœuds (VM-haProxy) est de distribuer l'accès au backend, d'équilibrer, de rediriger les ports et de collecter des statistiques.
Mon choix s'est porté sur haProxy, en tant qu'outil plus ciblé en matière d'équilibrage et de contrôle de santé. Pour tout cela, j'aime la syntaxe des directives de configuration et je travaille avec des listes blanches et noires IP, ainsi qu'avec une connexion SSL multi-domaines.
Configuration HaProxy:
haproxy.conf avec commentaires Important: toutes les machines doivent se «connaître» par leur nom d'hôte.
manifeste de marionnettes add-host-entry.pp pour ajouter des noms d'hĂ´tes dans / etc / hosts class host_entries { host { 'proxy01': ip => '10.10.10.11', } host { 'proxy02': ip => '10.10.10.12', } host { 'master': ip => '10.10.10.100', } host { 'node01': ip => '10.10.10.101', } host { 'node02': ip => '10.10.10.102', } host { 'node03': ip => '10.10.10.103', } host { 'node04': ip => '10.10.10.104', } host { 'node05': ip => '10.10.10.105', } host { 'nfs': ip => '10.10.10.200', } }
VM-Master-Cluster est la principale machine de contrôle. Il diffère des autres nœuds à bord par Puppet Master, GlusterFS Server, Rancher Server (conteneur), etcd (conteneur), gestionnaire de contrôle (conteneur). En cas de déconnexion de cet hôte, les services de production continuent de fonctionner.
VM-Node-Cluster - Noeuds, travailleurs. Machines de travail dont les ressources seront combinées dans un environnement tolérant aux pannes. Rien d'intéressant.
VM-NFS - Serveur NFS (nfs-kernel-server). La tâche principale consiste à fournir un espace tampon. Stocke les fichiers de configuration et tout. Ne stocke rien d'important. Sa chute peut être corrigée lentement, tout en buvant du café.
Important: Toutes les machines d'environnement doivent avoir Ă bord: docker.io, nfs-common, gluster-server.
manifeste de marionnettes must-have-packages.pp pour installer le bon logiciel class musthave { package { 'docker.io': ensure => 'installed', } package { 'nfs-common': ensure => 'installed', } package { 'gluster-server': ensure => 'installed', } }
Je ne décrirai pas l'installation de nfs-volume et la configuration de GlusterFS, car elle est généreusement décrite en grand nombre.
Si vous remarquez qu'il y a des disques SSD dans la description des spécifications, ils sont préparés pour le fonctionnement du système de fichiers distribué Gluster. Créez des partitions et du stockage sur des disques haute vitesse.
Remarque En fait, l'exécution d'un Rancher ne nécessite pas un environnement semblable à un miroir. Tout ce qui précède est ma vision du cluster et une description des pratiques que je pratique.
Pour exécuter Rancher,
une seule machine suffit, avec 4CPU, 4 Go de RAM, 10 Go de disque dur.
5 minutes Ă Rancher.
Sur VM-Master-Cluster, nous faisons:
sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher
Vérifier la disponibilité:
curl -k https://localhost
Si vous avez vu l'API - je vous félicite exactement la moitié du chemin parcouru.
En regardant à nouveau le schéma du réseau, nous rappelons que nous travaillerons de l'extérieur, via haProxy, dans la configuration que nous avons publiée le lien
rancher.domain.ru , allez-
y , définissez votre mot de passe.
La page suivante est la page de création de cluster Kubernetes.
Dans le menu Options de cluster, sélectionnez Flanelle. Je n'ai pas travaillé avec d'autres fournisseurs de réseau. Je ne peux pas vous conseiller.
Il convient de prêter attention au fait que nous avons installé les cases à cocher etcd et Control Plane, la case à cocher de travail n'est pas installée, au cas où vous ne prévoyez pas d'utiliser le gestionnaire en mode de travail.
Nous travaillons à l'intérieur du réseau local, avec la même adresse sur la carte réseau, donc dans les champs Adresse publique et interne indiqué la même IP.
Copiez le code résultant ci-dessus, exécutez-le dans la console.
Après un certain temps, dans l'interface Web, vous verrez un message concernant l'ajout d'un nœud. Et après un certain temps, vous démarrerez le cluster Kubernetes.
Pour ajouter un travailleur, allez éditer le cluster dans l'interface web Rancher, vous verrez le même menu qui génère la commande de connexion.
Définissez la case à cocher uniquement sur la position du travailleur, spécifiez l'IP du futur travailleur, copiez la commande et exécutez-la dans la console du nœud dont vous avez besoin.
Après un certain temps, la puissance du cluster augmentera, tout comme le nombre de nœuds.
Installez Kubernetes Dashboard:Accédez au menu Projets / Espaces de noms.
Après l'installation, vous verrez que les espaces de noms liés à Kubernetes seront contenus en dehors des projets. Pour utiliser pleinement ces espaces de noms, ils doivent être placés dans le projet.
Ajoutez un projet, nommez-le comme vous le souhaitez. Déplacez les espaces de noms (système de bovins, entrée-nginx, kube-public, kube-système) vers le projet que vous avez créé à l'aide du menu contextuel «Déplacer». Cela devrait être comme ceci:
Cliquez directement sur le nom du projet, vous serez redirigé vers le panneau de contrôle de la charge de travail. C'est ici que nous verrons comment créer un service simple.
Cliquez sur «Importer YAML» dans le coin supérieur droit. Copiez et collez le contenu de
ce fichier dans la zone de texte de la fenêtre qui s'ouvre, sélectionnez l'espace de nom «kube-system», cliquez sur «Importer».
Après un certain temps, pod kubernetes-dashboard démarre.
Accédez à l'édition de pod, ouvrez le menu de publication de port, définissez les valeurs suivantes:
Vérifiez l'accès sur le nœud sur lequel le pod s'exécute.
curl -k https://master:9090
Voyez la réponse? La publication est terminée, il reste à accéder à la partie administrative.
Sur la page principale de la gestion des clusters dans Rancher, il y a des outils très pratiques, tels que kubectl - la console de gestion des clusters et le fichier Kubeconfig - le fichier de configuration contenant l'adresse API, ca.crt, etc.
Nous allons dans kubectl et exécutons:
kubectl create serviceaccount cluster-admin-dashboard-sa kubectl create clusterrolebinding cluster-admin-dashboard-sa --clusterrole=cluster-admin --serviceaccount=default:cluster-admin-dashboard-sa
Nous avons créé un compte de service avec les privilèges les plus élevés, nous avons maintenant besoin d'un jeton pour accéder au tableau de bord.
Trouvez le secret du compte créé:
kubectl get secret | grep cluster-admin-dashboard-sa
Nous verrons le nom du compte avec un certain hachage à la fin, le copier et exécuter:
kubectl describe secret cluster-admin-dashboard-sa-$( )
Encore une fois, nous rappelons que tout a été publié avec succès via haProxy.
Nous suivons le lien
kubernetes.domain.ru . Saisissez le jeton reçu.
Réjouis-toi:
PSLe résultat global serait de remercier Rancher pour la création d'une interface intuitive, une instance facilement déployable, une documentation simple, la capacité de se déplacer rapidement et l'évolutivité au niveau du cluster. Peut-être que j'ai parlé trop brusquement au début du post que Swarm était fatigué, plutôt, des tendances de développement évidentes, m'ont en quelque sorte incité à regarder sur le côté et à ne pas terminer la routine ennuyeuse. Docker a créé une ère de développement. Et juger ce projet n'est certainement pas pour moi.