Comment installer et configurer Kubernetes sur un cluster CoreOS

introduction

Kubernetes est un système conçu pour gérer les applications intégrées aux conteneurs Docker dans des environnements en cluster. Il gère le cycle de vie complet d’une application conteneurisée, y compris le déploiement et la mise à l’échelle.

Dans ce guide, nous expliquerons comment utiliser Kubernetes sur un cluster CoreOS. Ce système nous permettra de regrouper les services associés pour les déployer en tant qu’unité sur un seul hôte en utilisant ce que Kubernetes appelle des «pods». Il fournit également une fonctionnalité de vérification de l’intégrité, une haute disponibilité et une utilisation efficace des ressources.

Ce tutoriel a été testé avec Kubernetes v0.7.0. Gardez à l’esprit que ce logiciel change fréquemment. Pour voir votre version, une fois celle-ci installée, lancez:

kubecfg -version

Prérequis et objectifs

Nous allons commencer par les mêmes clusters CoreOS que ceux utilisés dans les guides CoreOS précédents. Pour que ce groupe de trois membres soit opérationnel, suivez notre CoreOS Guide de classification en cluster.

Cela vous donnera trois serveurs à configurer. Bien que chaque nœud soit essentiellement interchangeable au niveau CoreOS, dans Kubernetes, nous aurons besoin d’attribuer des rôles plus spécialisés. Nous avons besoin d’un nœud pour agir en tant que maître, ce qui permettra d’exécuter quelques services supplémentaires, tels qu’un serveur API et un gestionnaire de contrôleur.

Pour ce guide, nous utiliserons les détails suivants:

Hostname	Public IPv4	Private IPv4	Role
coreos-1	192.168.2.1	10.120.0.1	Master
coreos-2	192.168.2.2	10.120.0.2	Minion1
coreos-3	192.168.2.3	10.120.0.3	Minion2

Dans la configuration que nous allons suivre, le maître sera également un serveur minion entièrement fonctionnel et capable de mener à bien ses tâches. L’idée de cette configuration a été reprise de Le guide de Brian Ketelson sur la configuration de Kubernetes sur CoreOS ici.

Si vous avez suivi le guide ci-dessus pour créer le cluster, les deux disques + etcd + et + flotte + devraient être configurés pour utiliser les adresses IPv4 privées de chaque serveur pour la communication. L’adresse IP publique peut être utilisée pour se connecter à partir de votre ordinateur local.

Ce guide utilise ce cluster CoreOS de base et installe un certain nombre de services par dessus.

Tout d’abord, nous allons configurer + flannel +, une couche de réseau qui fournit à chaque machine un sous-réseau individuel pour la communication de conteneur. Il s’agit d’un projet CoreOS relativement nouveau, conçu en grande partie pour s’adapter aux hypothèses de Kubernetes concernant l’environnement réseau.

Nous allons configurer Docker pour utiliser cette couche réseau lors de déploiements. En plus de cela, nous allons configurer Kubernetes. Cela implique un certain nombre de pièces. Nous devons configurer un service de proxy, une couche API et un système de gestion «pod» au niveau du nœud appelé Kubelet.

Créer la couche de réseau en flanelle

La première chose à faire est de configurer le service + flannel +. C’est le composant qui fournit des sous-réseaux individuels pour chaque machine du cluster. Docker sera configuré pour l’utiliser pour les déploiements. Comme il s’agit d’une exigence de base, c’est un excellent point de départ.

Au moment d’écrire ces lignes, il n’y a pas de binaires pré-construits de + flannel + fournis par le projet. De ce fait, nous devrons construire le binaire et l’installer nous-même. Pour gagner du temps de construction, nous allons construire cela sur une seule machine, puis transférer l’exécutable vers nos autres nœuds.

Comme de nombreuses parties de CoreOS, Flannel est construit dans le langage de programmation Go. Plutôt que de créer un environnement Go complet pour construire le paquet, nous utiliserons un conteneur pré-construit à cette fin. Google gère un conteneur Go spécifiquement pour ces types de situations.

Toutes les applications que nous installerons seront placées dans le répertoire + / opt / bin +, qui n’est pas créé automatiquement dans CoreOS. Créez le répertoire maintenant:

sudo mkdir -p /opt/bin

Nous pouvons maintenant construire le projet en utilisant le conteneur Go. Il suffit d’exécuter cette commande Docker pour extraire l’image de Docker Hub, exécuter le conteneur, puis télécharger et créer le package dans le conteneur:

docker run -i -t google/golang /bin/bash -c "go get github.com/coreos/flannel"

Lorsque l’opération est terminée, nous pouvons copier le binaire compilé du conteneur. Tout d’abord, nous devons connaître l’ID du conteneur:

docker ps -l -q

Le résultat sera l’ID qui ressemble à ceci:

Nous pouvons utiliser cet ID pour spécifier une opération de copie dans le répertoire + / opt / bin +. Le fichier binaire a été placé à "+ / gopath / bin / flannel " dans le conteneur. Puisque le répertoire ` / opt / bin ` n'est pas accessible en écriture pour notre utilisateur ` core `, nous devrons utiliser ` sudo +`:

sudo docker cp :/gopath/bin/flannel /opt/bin/

Nous avons maintenant la flanelle disponible sur notre première machine. Un peu plus tard, nous allons copier ceci sur nos autres machines.

Construire les binaires Kubernetes

Kubernetes est composé d’un grand nombre d’applications et de technologies en couches différentes. Actuellement, le projet ne contient pas de fichiers binaires pré-construits pour les divers composants dont nous avons besoin. Nous allons les construire nous-mêmes à la place.

Nous ne terminerons ce processus que sur l’un de nos serveurs. Étant donné que nos serveurs sont de nature uniforme, nous pouvons éviter des temps de construction inutiles en transférant simplement les fichiers binaires que nous allons produire.

La première étape consiste à cloner le projet à partir de son référentiel GitHub. Nous allons le cloner dans notre répertoire personnel:

cd ~
git clone https://github.com/GoogleCloudPlatform/kubernetes.git

Ensuite, nous irons dans le répertoire de construction du référentiel. À partir de là, nous pouvons construire les fichiers binaires à l’aide d’un script inclus:

cd kubernetes/build
./release.sh

Ce processus prendra beaucoup de temps. Il lancera un conteneur Docker pour créer les packages binaires nécessaires.

Une fois le processus de construction terminé, vous pourrez trouver les fichiers binaires dans le répertoire + ~ / kubernetes / _output / dockerized / bin / linux / amd64 +:

cd ~/kubernetes/_output/dockerized/bin/linux/amd64
ls

e2e          kube-apiserver           kube-proxy      kubecfg  kubelet
integration  kube-controller-manager  kube-scheduler  kubectl  kubernetes

Nous les transférerons dans le répertoire + / opt / bin + que nous avons créé précédemment:

sudo cp * /opt/bin

Notre première machine dispose maintenant de tous les fichiers binaires nécessaires à notre projet. Nous pouvons maintenant nous concentrer sur l’obtention de ces applications sur nos autres serveurs.

Transférer des exécutables sur vos autres serveurs

Notre première machine dispose de tous les composants nécessaires au démarrage d’un cluster Kubernetes. Nous devons toutefois les copier sur nos autres machines avant que cela fonctionne.

Comme Kubernetes n’est pas une installation uniforme (il y a un maître et plusieurs minions), chaque hôte n’a pas besoin de tous les fichiers binaires. Chaque serveur Minion n’a besoin que des exécutables du planificateur, du menu fixe, du proxy, du kubelet et du flanelle.

Cependant, le transfert de tous les exécutables nous donne plus de flexibilité par la suite. C’est aussi plus facile. Nous allons tout transférer dans ce guide.

Lorsque vous vous êtes connecté à votre première machine, vous devriez avoir transféré les informations de votre agent SSH en vous connectant avec l’indicateur + -A + (après le démarrage de l’agent et l’ajout de votre clé). Ceci est une étape importante. Déconnectez-vous et reconnectez-vous si vous n’avez pas passé cet indicateur plus tôt.

Vous devrez exécuter les commandes + eval + et + + ssh-add + de la section * Step 2-Authenticate * de https://www.digitalocean.com/community/tutorials/how-to-connect-to- votre-droplet-with-ssh # ssh-login-as-root [ce tutoriel] avant de vous connecter avec + -A +.

Commencez par vous déplacer dans le répertoire où nous avons placé nos fichiers binaires:

cd /opt/bin

Nous pouvons maintenant copier les fichiers de ce répertoire sur nos autres hôtes. Pour ce faire, nous exécutons les fichiers exécutables directement au format standard de notre shell. Nous acheminerons ensuite cette information dans notre commande SSH, où nous nous connecterons à l’un de nos autres hôtes.

La commande SSH que nous allons utiliser créera le répertoire + / opt / bin + sur notre autre hôte, passera dans le répertoire et annulera les informations qu’il reçoit via le tunnel SSH. La commande entière ressemble à ceci:

tar -czf - . | ssh core@ "sudo mkdir -p /opt/bin; cd /opt/bin; sudo tar xzvf -"

Cela transférera tous les exécutables à l’adresse IP que vous avez spécifiée. Exécutez à nouveau la commande en utilisant votre troisième hôte:

tar -czf - . | ssh core@ "sudo mkdir -p /opt/bin; cd /opt/bin; sudo tar xzvf -"

Vous avez maintenant tous les exécutables en place sur vos trois machines.

Mise en place de services spécifiques aux maîtres

La prochaine étape consiste à configurer nos fichiers d’unités + systemd + pour configurer et lancer correctement nos nouvelles applications. Nous allons commencer par gérer les applications qui ne fonctionneront que sur notre serveur maître.

Nous allons placer ces fichiers dans le répertoire + / etc / systemd / system +. Déplacer là maintenant:

cd /etc/systemd/system

Nous pouvons maintenant commencer à créer nos fichiers de service. Nous allons créer deux fichiers sur le maître uniquement et cinq fichiers appartenant également aux sbires. Tous ces fichiers seront dans + / etc / systemd / system / *. Service +.

Fichiers maîtres:

+ apiserver.service
+ controller-manager.service

Fichiers Minion pour tous les serveurs:

+ scheduler.service
+ flannel.service +
+ docker.service
+ proxy.service
+ kubelet.service

Créer le fichier d’unité de serveur API

Le premier fichier que nous allons configurer est le fichier unité du serveur API. Le serveur API sert à fournir des informations sur le cluster, à gérer les demandes de publication pour modifier les informations, à planifier le travail sur chaque serveur et à synchroniser les informations partagées.

Nous allons appeler ce fichier unitaire + apiserver.service + par souci de simplicité. Créez et ouvrez ce fichier maintenant:

sudo vim apiserver.service

Dans ce fichier, nous commencerons par les métadonnées de base relatives à notre service. Nous devons nous assurer que cette unité n’est pas démarrée tant que les services + etcd + et Docker ne sont pas opérationnels:

[Unit]
Description=Kubernetes API Server
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

Ensuite, nous terminerons la section + [Service] +. Ceci sera principalement utilisé pour démarrer le serveur API avec certains paramètres décrivant notre environnement. Nous allons également définir les conditions de redémarrage:

[Unit]
Description=Kubernetes API Server
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

[Service]
ExecStart=/opt/bin/kube-apiserver \
-address=127.0.0.1 \
-port=8080 \
-etcd_servers=http://127.0.0.1:4001 \
-portal_net=10.100.0.0/16 \
-logtostderr=true
ExecStartPost=-/bin/bash -c "until /usr/bin/curl http://127.0.0.1:8080; do echo \"waiting for API server to come online...\"; sleep 3; done"
Restart=on-failure
RestartSec=5

La section ci-dessus établit l’adresse réseau et le port sur lequel le serveur sera exécuté, ainsi que l’emplacement où + etcd + est à l’écoute. Le paramètre + portal_net + donne la plage de réseau que le service + flannel + utilisera.

Après avoir démarré le service, nous vérifions qu’il est opérationnel en boucle. Cela garantit que le service est réellement capable d’accepter des connexions avant que les services dépendants ne soient lancés. Ne pas en avoir peut entraîner des erreurs dans les services dépendants nécessitant un redémarrage manuel.

Enfin, nous devrons installer cette unité. Nous pouvons le faire avec une section + [Install] + qui indiquera à notre hôte de démarrer ce service lorsque la machine est complètement démarrée:

[Unit]
Description=Kubernetes API Server
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

[Service]
ExecStart=/opt/bin/kube-apiserver \
-address=127.0.0.1 \
-port=8080 \
-etcd_servers=http://127.0.0.1:4001 \
-portal_net=10.100.0.0/16 \
-logtostderr=true
ExecStartPost=-/bin/bash -c "until /usr/bin/curl http://127.0.0.1:8080; do echo \"waiting for API server to come online...\"; sleep 3; done"
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Lorsque vous avez terminé, fermez le fichier.

Créer le fichier d’unité du Controller Manager

Le composant suivant requis par Kubernetes est le serveur Controller Manager. Ce composant est utilisé pour effectuer la réplication de données parmi les unités du cluster.

Ouvrez un fichier nommé + controller-manager.service + dans le même répertoire:

sudo vim controller-manager.service

Nous allons recommencer avec les métadonnées de base. Cela suivra le même format que le dernier fichier. Outre les autres dépendances, ce service doit démarrer après le serveur API que nous venons de configurer:

[Unit]
Description=Kubernetes Controller Manager
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

Pour la partie + [Service] + de ce fichier, il suffit de transmettre quelques paramètres à l’exécutable. Nous dirigeons principalement l’application vers l’emplacement de notre serveur d’API. Ici, nous avons passé chacune des adresses IP privées de nos machines, séparées par des virgules. Modifiez ces valeurs pour refléter votre propre configuration. Encore une fois, nous allons nous assurer que cette unité redémarre en cas d’échec car il est nécessaire pour que notre cluster Kubernetes fonctionne correctement:

[Unit]
Description=Kubernetes Controller Manager
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

[Service]
ExecStart=/opt/bin/kube-controller-manager \
-master=http://127.0.0.1:8080 \
-machines=,,
Restart=on-failure
RestartSec=5

Nous allons également utiliser les mêmes instructions d’installation pour que cette unité démarre également au démarrage:

[Unit]
Description=Kubernetes Controller Manager
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

[Service]
ExecStart=/opt/bin/kube-controller-manager \
-master=http://127.0.0.1:8080 \
-machines=,,
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Enregistrez et fermez le fichier lorsque vous avez terminé.

Configuration des services de cluster

Maintenant que nos services spécifiques au maître sont configurés, nous pouvons configurer les fichiers d’unité devant être présents sur * toutes * nos machines. Cela signifie que vous devez ajouter ces fichiers aux serveurs maître et sbire et les configurer en conséquence.

Ces cinq fichiers doivent être créés sur toutes les machines, dans + / etc / systemd / system / *. Service +.

+ scheduler.service
+ flannel.service +
+ docker.service
+ proxy.service
+ kubelet.service

Créer le fichier d’unité du planificateur

Le composant suivant est le planificateur. Le planificateur décide sur quel serveur exécuter les charges de travail et communique pour s’assurer que cela se produit.

Créez et ouvrez un fichier pour cette unité maintenant:

sudo vim scheduler.service

Cette unité démarre à peu près de la même façon que la dernière. Il dépend de tous les mêmes services:

[Unit]
Description=Kubernetes Scheduler
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

La section de service elle-même est très simple. Il suffit de pointer l’exécutable sur l’adresse réseau et le port sur lequel se trouve le serveur d’API. De nouveau, nous redémarrerons le service en cas d’échec.

La section installation reflète les autres que nous avons vu jusqu’à présent:

[Unit]
Description=Kubernetes Scheduler
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

[Service]
ExecStart=/opt/bin/kube-scheduler -master=127.0.0.1:8080
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Lorsque vous avez terminé, enregistrez et fermez le fichier.

Créer le fichier d’unité de flanelle

Le composant suivant dont nous avons besoin pour fonctionner est + flannel +, notre couche de réseau. Ceci sera utilisé pour donner à chaque nœud son propre sous-réseau pour les conteneurs Docker.

Là encore, sur chacune de vos machines, accédez au répertoire de configuration + systemd +:

cd /etc/systemd/system

Créez et ouvrez le fichier unité + flannel + dans votre éditeur de texte:

sudo vim flannel.service

À l’intérieur de ce fichier, nous commencerons par les informations de métadonnées. Puisque ce service nécessite + etcd + pour enregistrer les informations de sous-réseau, nous devons le démarrer après + etcd +:

[Unit]
Description=Flannel network fabric for CoreOS
Requires=etcd.service
After=etcd.service

Pour la section + [Service] +, nous allons d’abord créer le fichier + / etc / environment + afin de pouvoir accéder à l’adresse IP privée de notre hôte.

L’étape suivante consistera à placer une ligne + ExecStartPre = + qui tente d’enregistrer la plage de sous-réseau avec + etcd +. Il essaiera continuellement de s’inscrire avec etcd jusqu’à ce qu’il réussisse. Nous utiliserons la plage + 10.100.0.0 / 16 + pour ce guide.

Ensuite, nous commencerons + flannel + avec l’adresse IP privée que nous achetons à partir du fichier d’environnement.

Ensuite, nous voulons vérifier si + flannel + a écrit ses informations dans son fichier (afin que Docker puisse les lire dans un instant) et dormir s’il ne l’a pas déjà fait. Cela garantit que le service Docker n’essaie pas de lire le fichier avant qu’il ne soit disponible (ceci peut se produire sur le premier serveur mis en ligne). Nous allons configurer le redémarrage en utilisant les paramètres habituels et installer à nouveau l’appareil en utilisant le + multi-user.target +:

[Unit]
Description=Flannel network fabric for CoreOS
Requires=etcd.service
After=etcd.service

[Service]
EnvironmentFile=/etc/environment
ExecStartPre=-/bin/bash -c "until /usr/bin/etcdctl set /coreos.com/network/config '{\"Network\": \"10.100.0.0/16\"}'; do echo \"waiting for etcd to become available...\"; sleep 5; done"
ExecStart=/opt/bin/flannel -iface=${COREOS_PRIVATE_IPV4}
ExecStartPost=-/bin/bash -c "until [ -e /run/flannel/subnet.env ]; do echo \"waiting for write.\"; sleep 3; done"
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Enregistrez et fermez le fichier lorsque vous avez terminé. Créez le même fichier sur vos autres hôtes.

Créer le fichier d’unité Docker

Le prochain fichier que nous allons créer n’est pas réellement lié aux exécutables de notre répertoire + / opt / bin +. Nous devons créer un fichier de service Docker afin que le service puisse démarrer avec la connaissance de la superposition réseau + flanel + que nous venons de configurer.

Créez le fichier d’unité approprié avec votre éditeur de texte:

sudo vim docker.service

Commencez avec les métadonnées habituelles. Nous avons besoin de cela pour démarrer après la configuration et la mise en ligne du service + flannel +:

[Unit]
Description=Docker container engine configured to run with flannel
Requires=flannel.service
After=flannel.service

Pour la section + [Service] +, nous devrons trouver le fichier que + flannel + utilise pour stocker les variables d’environnement qu’il crée. Cela aura les informations de sous-réseau de l’hôte actuel.

Ensuite, nous supprimons l’interface de pont + docker0 + actuelle et le supprimons. Cela nous permet de redémarrer Docker avec une table rase. Le processus configurera l’interface + docker0 + à l’aide des informations réseau + flannel +.

Nous utilisons les mêmes détails de redémarrage et + [Installer] + que nous avons utilisés avec nos autres unités:

[Unit]
Description=Docker container engine configured to run with flannel
Requires=flannel.service
After=flannel.service

[Service]
EnvironmentFile=/run/flannel/subnet.env
ExecStartPre=-/usr/bin/ip link set dev docker0 down
ExecStartPre=-/usr/sbin/brctl delbr docker0
ExecStart=/usr/bin/docker -d -s=btrfs -H fd:// --bip=${FLANNEL_SUBNET} --mtu=${FLANNEL_MTU}
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Enregistrez et fermez le fichier lorsque vous avez terminé. Créez ce même fichier sur chacun de vos hôtes.

Créer le fichier d’unité proxy

L’unité logique suivante à discuter est le serveur proxy que chacun des membres du cluster exécute. Le serveur proxy Kubernetes est utilisé pour router et transférer le trafic depuis et vers les conteneurs.

Ouvrez un fichier d’unité proxy avec votre éditeur de texte:

sudo vim proxy.service

Pour la section de métadonnées, nous devrons définir des dépendances sur + etcd + et Docker. Pour la section + [Service] +, il suffit de démarrer l’exécutable avec l’adresse du serveur local + etcd +. Le redémarrage de la configuration et les détails de l’installation refléteront nos fichiers de service précédents:

[Unit]
Description=Kubernetes proxy server
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

[Service]
ExecStart=/opt/bin/kube-proxy -etcd_servers=http://127.0.0.1:4001 -logtostderr=true
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Enregistrez le fichier lorsque vous avez terminé. Créez ce même fichier sur chacun de vos hôtes.

Créer le fichier d’unité Kubelet

Nous allons maintenant créer le fichier d’unité Kubelet. Ce composant est utilisé pour gérer les déploiements de conteneurs. Il s’assure que les conteneurs sont dans l’état dans lequel ils sont censés être et surveille le système pour détecter les modifications de l’état souhaité des déploiements.

Créez et ouvrez le fichier dans votre éditeur de texte:

sudo vim kubelet.service

La section de métadonnées contiendra les mêmes informations de dépendance sur + etcd + et Docker:

[Unit]
Description=Kubernetes Kubelet
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

Pour la section + [Service] +, nous devons à nouveau source le fichier + / etc / environment + pour avoir accès à l’adresse IP privée de l’hôte. Nous appellerons ensuite l’exécutable + kubelet +, en définissant son adresse et son port. Nous substituons également le nom d’hôte pour utiliser la même adresse IP privée et pointons le service vers l’instance locale + etcd +. Nous fournissons les mêmes détails de redémarrage et d’installation que ceux que nous utilisons:

[Unit]
Description=Kubernetes Kubelet
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

[Service]
EnvironmentFile=/etc/environment
ExecStart=/opt/bin/kubelet \
-address=${COREOS_PRIVATE_IPV4} \
-port=10250 \
-hostname_override=${COREOS_PRIVATE_IPV4} \
-etcd_servers=http://127.0.0.1:4001 \
-logtostderr=true
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Enregistrez et fermez le fichier lorsque vous avez terminé.

Activer les services

Maintenant que tous vos fichiers de service sont démarrés, vous pouvez activer ces unités. Cela traite les informations de la section + [Install] + de chaque unité.

Étant donné que nos unités déclarent être recherchées par la cible multi-utilisateurs, cela signifie que lorsque le système tente de placer le serveur en mode multi-utilisateurs, tous nos services sont démarrés automatiquement.

Pour ce faire, allez dans votre répertoire + / etc / systemd / system:

cd /etc/systemd/system

À partir de là, nous pouvons activer tous les scripts:

sudo systemctl enable *

Cela créera un répertoire + multi-user.target.wants + avec des liens symboliques vers nos fichiers unité. Ce répertoire sera traité par + systemd + vers la fin du processus de démarrage.

Répétez cette étape sur chacun de vos serveurs.

Maintenant que nos services sont activés, nous pouvons redémarrer les serveurs.

Nous allons commencer par le serveur maître, mais vous pouvez le faire dans n’importe quel ordre. Bien qu’il ne soit pas nécessaire de redémarrer l’ordinateur pour démarrer ces services, cela garantit que nos fichiers d’unité ont été écrits de manière à permettre une chaîne de dépendance transparente:

sudo reboot

Une fois que le maître est revenu en ligne, vous pouvez redémarrer vos serveurs sbires:

sudo reboot

Une fois que tous vos serveurs sont en ligne, assurez-vous que vos services ont démarré correctement. Vous pouvez vérifier cela en tapant:

systemctl status

Ou vous pouvez consulter le journal en tapant:

journalctl -b -u

Recherchez une indication que les services fonctionnent correctement. S’il y a des problèmes, un redémarrage du service spécifique peut aider:

sudo systemctl restart

Lorsque vous avez terminé, vous devriez pouvoir visualiser vos machines à partir de votre serveur maître. Une fois connecté à votre serveur maître, vérifiez que tous les serveurs sont disponibles en tapant:

kubecfg list minions

Minion identifier
----------

Dans un prochain guide, nous verrons comment utiliser Kubernetes pour planifier et contrôler les services sur votre cluster CoreOS.

Conclusion

Vous devez maintenant configurer Kubernetes sur votre cluster CoreOS. Cela vous donne une excellente interface de gestion et de planification pour travailler avec des services dans des groupements logiques.

Vous avez probablement remarqué que les étapes ci-dessus conduisent à un processus très manuel. Cela tient en grande partie au fait que nous avons construit les fichiers binaires sur nos machines. Si vous deviez héberger les fichiers binaires sur un serveur Web accessible au sein de votre réseau privé, vous pouvez les extraire et les configurer automatiquement en créant des fichiers spéciaux de configuration dans le cloud.

Les fichiers de configuration Cloud sont suffisamment flexibles pour que vous puissiez injecter la plupart des fichiers de l’unité sans aucune modification (à l’exception du fichier + apiserver.service +, qui nécessite un accès aux adresses IP de chaque nœud), puis les démarrer en tant que CoreOS. le noeud est démarré. Cela sort du cadre de ce guide, mais constitue une bonne étape pour automatiser le processus.

TOC