Nous développons un environnement pour travailler avec des microservices. Partie 1 Installer Kubernetes HA sur du métal nu (Debian)

Bonjour chers lecteurs de Habr!

Avec cette publication, je veux commencer une série d'articles sur le déploiement d'un environnement d'orchestration à part entière avec des conteneurs Kubernetes, qui sera prêt à fonctionner et à lancer des applications.
Je veux dire non seulement comment déployer un cluster Kubernetes, mais aussi comment configurer un cluster après l'installation, comment y ajouter des outils pratiques et des modules complémentaires pour utiliser l'architecture de microservice.

Ce cycle comprendra au moins quatre articles:

1. Dans la première d'entre elles, je vous dirai comment installer un cluster kubernetes à sécurité intégrée sur du fer nu, comment installer un tableau de bord standard et configurer l'accès à celui-ci, comment installer un contrôleur d'entrée.
2. Dans le deuxième article, je vais vous montrer comment déployer un cluster de basculement Ceph et comment commencer à utiliser des volumes RBD dans notre cluster Kubernetes. Je vais également aborder un peu d'autres types de stockages (stockages) et examiner plus en détail le stockage local. De plus, je vais vous expliquer comment organiser le stockage S3 à tolérance de pannes en fonction du cluster CEPH créé
3. Dans le troisième article, je décrirai comment déployer un cluster de basculement MySql dans notre cluster Kubernetes, à savoir, Percona XtraDB Cluster on Kubernetes. Et je décrirai également tous les problèmes que nous avons rencontrés lorsque nous avons décidé de transférer la base de données vers kubernetes.
4. Dans le quatrième article, j'essaierai de tout rassembler et de dire comment déployer et exécuter une application qui utilisera la base de données et les volumes ceph. Je vais vous expliquer comment configurer le contrôleur d'entrée pour accéder à notre application de l'extérieur et au service de commande automatique de certificats de Let's Encrypt. Une autre est de savoir comment maintenir automatiquement ces certificats à jour. Nous aborderons également RBAC dans le cadre de l'accès au panneau de contrôle. Je vais vous parler en bref de Helm et de son installation.
   Si vous êtes intéressé par les informations contenues dans ces publications, alors bienvenue!

Entrée:

À qui sont destinés ces articles? Tout d'abord, pour ceux qui commencent tout juste leur voyage dans l'étude de Kubernetes. De plus, ce cycle sera utile aux ingénieurs qui envisagent de passer d'un monolithe à des microservices. Tout ce qui est décrit est mon expérience, y compris celle obtenue lors de la traduction de plusieurs projets d'un monolithe vers Kubernetes. Il est possible que certaines parties des publications intéressent des ingénieurs expérimentés.

Ce que je ne considérerai pas en détail dans cette série de publications:

• expliquer en détail ce que sont les primitives kubernetes, telles que: pod, déploiement, service, entrée, etc.
• Je considérerai CNI (Container Networking Interface) très superficiellement, nous utilisons callico donc d'autres solutions, je vais seulement lister.
• processus de génération d'image Docker.
• Processus CI \ CD. (Peut-être une publication séparée, mais après tout le cycle)
• barre; beaucoup a été écrit à son sujet, je ne parlerai que du processus d'installation de celui-ci dans le cluster et de configuration du client.

Ce que je veux considérer en détail:

• Processus pas à pas du déploiement de cluster Kubernetes. J'utiliserai kubeadm. Mais en même temps, j'examinerai pas à pas le processus d'installation d'un cluster sur du métal nu, les différents types d'installation ETCD et la configuration des fichiers pour kube admina. Je vais essayer de clarifier toutes les options d'équilibrage pour le contrôleur Ingress et la différence dans les différents schémas d'accès des nœuds de travail à l'API du serveur.
  Je sais qu'aujourd'hui, pour le déploiement de kubernetes, il existe de nombreux excellents outils, par exemple, kubespray ou le même éleveur. Il sera peut-être plus pratique pour quelqu'un de les utiliser. Mais, je pense, il y a beaucoup d'ingénieurs qui veulent examiner la question plus en détail.
• Terminologie CEPH et installation étape par étape du cluster CEPH, ainsi que des instructions étape par étape sur la connexion du stockage ceph au cluster créé par Kubernetes.
• les stockages locaux, la connexion au cluster kubernetes, ainsi que les différences par rapport aux connexions comme le chemin de l'hôte, etc.
• opérateurs kubernetes et le déploiement de Percona XtraDB Cluster avec l'aide de l'opérateur, ainsi que d'essayer de parler des avantages et des inconvénients d'une telle solution après six mois d'expérience en production. Et je partagerai également quelques plans pour finaliser l'opérateur de percona.

Table des matières:

1. Liste des hôtes, des ressources hôtes, des versions du système d'exploitation et des logiciels
2. Diagramme HA du cluster Kubernetes
3. Avant de commencer ou avant de commencer
4. Remplissez le fichier create-config.sh
5. Mise à jour du noyau du système d'exploitation
6. Préparation des nœuds Installation de Kubelet, Kubectl, Kubeadm et Docker
7. Installation de l'ETCD (diverses options)
8. Lancement du premier assistant kubernetes
9. Installation de CNI Callico
10. Lancement des deuxième et troisième assistants kubernetes
11. Ajouter un nœud de travail au cluster
12. Installer haproxy sur les nœuds de travail pour HA
13. Installation d'Ingress Controller
14. Installer l'interface utilisateur Web (tableau de bord)

Liste et destination des hôtes

Tous les nœuds de mon cluster seront situés sur des machines virtuelles avec un système extensible Debian 9 préinstallé avec le noyau 4.19.0-0.bpo.5-amd64. Pour la virtualisation, j'utilise Proxmox VE.

Table VM et leurs performances:

Il n'est pas nécessaire que vous ayez une telle configuration de machines, mais je vous conseille tout de même de respecter les recommandations de la documentation officielle et, pour les maîtres, d'augmenter la quantité de RAM à au moins 4 Go. Pour l'avenir, je dirai qu'avec un plus petit nombre, j'ai eu des pépins dans le travail de CNI Callico
Ceph est également assez vorace en termes de performances de mémoire et de disque.
Nos installations de production fonctionnent sans virtualisation bare-metal, mais je connais de nombreux exemples où des machines virtuelles avec des ressources assez modestes suffisaient. Tout dépend de vos besoins et de vos charges de travail.

Liste et versions des logiciels

À partir de la version 1.14, Kubeadm a cessé de prendre en charge la version d'API v1alpha3 et est complètement passé à la version d'API v1beta1, qu'il prendra en charge dans un avenir proche, donc dans cet article, je ne parlerai que de v1beta1.
Nous pensons donc que vous avez préparé les machines pour le cluster kubernetes. Ils sont tous accessibles les uns aux autres sur le réseau, ont une «connexion Internet» à Internet et un système d'exploitation «propre» y est installé.
Pour chaque étape d'installation, je préciserai sur quelles machines la commande ou le bloc de commandes est exécuté. Exécutez toutes les commandes en tant que root, sauf indication contraire.
Tous les fichiers de configuration, ainsi qu'un script pour leur préparation, sont disponibles en téléchargement dans mon github
Commençons donc.

Diagramme HA du cluster Kubernetes

Un diagramme approximatif du cluster HA. L'artiste de moi est moyen, pour être honnête, mais je vais essayer de l'expliquer en quelques mots et de manière assez simpliste, sans me plonger particulièrement dans la théorie.
Ainsi, notre cluster sera composé de trois nœuds maîtres et de trois nœuds travailleurs. Sur chaque nœud maître kubernetes, etcd (flèches vertes sur le diagramme) et les pièces de rechange kubernetes fonctionneront pour nous; appelons-les génériquement - kubeapi.
Par le biais du cluster maître etcd, les nœuds échangent l'état du cluster kubernetes. Je vais indiquer les mêmes adresses que les points d'entrée du contrôleur d'entrée pour le trafic externe (flèches rouges sur le schéma)
Sur les nœuds de travail, kubelet fonctionne pour nous, qui communique avec le serveur api kubernetes via un haproxy installé localement sur chaque nœud de travail. En tant qu'adresse API du serveur pour kubelet, j'utiliserai l'hôte local 127.0.0.1:6443, et l'haproxy sur roundrobin dispersera les demandes sur trois nœuds maîtres, il vérifiera également la disponibilité des nœuds maîtres. Ce schéma nous permettra de créer une haute disponibilité et, en cas de défaillance de l'un des nœuds maîtres, les nœuds de travail enverront discrètement des demandes aux deux nœuds maîtres restants.

Avant de commencer

Avant de commencer à travailler sur chaque nœud du cluster, nous vous fournirons les packages dont nous aurons besoin pour travailler:

apt-get update && apt-get install -y curl apt-transport-https git 

Sur les nœuds principaux, copiez le référentiel avec des modèles de configuration

 sudo -i git clone https://github.com/rjeka/kubernetes-ceph-percona.git 

Vérifiez que l'adresse IP des hôtes sur les assistants correspond à celle sur laquelle le serveur kubernetes écoutera

 hostname && hostname -i master01 10.73.71.25 

et donc pour tous les nœuds maîtres.

Assurez-vous de désactiver SWAP, sinon kubeadm générera une erreur

 [ERROR Swap]: running with swap on is not supported. Please disable swap 

Vous pouvez désactiver la commande

 swapoff -a 

N'oubliez pas de commenter dans / etc / fstab

Remplissez le fichier create-config.sh

Pour remplir automatiquement les configurations nécessaires à l'installation du cluster kubernetes, j'ai téléchargé un petit script create-config.sh. Vous devez le remplir littéralement 8 lignes. Indiquez les adresses IP et le nom d'hôte de vos maîtres. Et spécifiez également etcd tocken, vous ne pouvez pas le changer. Je vais donner ci-dessous la partie du script dans laquelle vous devez apporter des modifications.

 #!/bin/bash ####################################### # all masters settings below must be same ####################################### # master01 ip address export K8SHA_IP1=10.73.71.25 # master02 ip address export K8SHA_IP2=10.73.71.26 # master03 ip address export K8SHA_IP3=10.73.71.27 # master01 hostname export K8SHA_HOSTNAME1=master01 # master02 hostname export K8SHA_HOSTNAME2=master02 # master03 hostname export K8SHA_HOSTNAME3=master03 #etcd tocken: export ETCD_TOKEN=9489bf67bdfe1b3ae077d6fd9e7efefd #etcd version export ETCD_VERSION="v3.3.10" 

Mise à jour du noyau du système d'exploitation

Cette étape est facultative, car le noyau devra être mis à jour à partir des ports arrière, et vous le faites à vos risques et périls. Peut-être ne rencontrerez-vous jamais ce problème, et si vous le faites, vous pouvez mettre à jour le noyau même après avoir déployé kubernetes. En général, vous décidez.
Une mise à jour du noyau est requise pour corriger l'ancien bug de docker, qui n'était corrigé que dans la version 4.18 du noyau Linux. Vous pouvez en savoir plus sur ce bug ici . Un bug a été exprimé dans le blocage périodique de l'interface réseau sur les nœuds kubernetes avec l'erreur:

 waiting for eth0 to become free. Usage count = 1 

Après avoir installé le système d'exploitation, j'avais la version 4.9 du noyau

 uname -a Linux master01 4.9.0-7-amd64 #1 SMP Debian 4.9.110-3+deb9u2 (2018-08-13) x86_64 GNU/Linux 

Sur chaque machine pour kubernetes, nous exécutons
Étape # 1
Ajouter des ports de retour à la liste des sources

 echo deb http://ftp.debian.org/debian stretch-backports main > /etc/apt/sources.list apt-get update apt-cache policy linux-compiler-gcc-6-x86 

Étape numéro 2
Installation du package

 apt install -y -t stretch-backports linux-image-amd64 linux-headers-amd64 

Étape numéro 3
Redémarrer

 reboot 

Vérifiez que tout va bien

 uname -a Linux master01 4.19.0-0.bpo.5-amd64 #1 SMP Debian 4.19.37-4~bpo9+1 (2019-06-19) x86_64 GNU/Linux 

Préparation des nœuds Installation de Kubelet, Kubectl, Kubeadm et Docker

Installer Kubelet, Kubectl, Kubeadm

Nous mettons sur tous les nœuds du cluster, selon la documentation de kubernetes

 apt-get update && apt-get install -y apt-transport-https curl curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - cat <<EOF >/etc/apt/sources.list.d/kubernetes.list deb https://apt.kubernetes.io/ kubernetes-xenial main EOF apt-get update apt-get install -y kubelet kubeadm kubectl apt-mark hold kubelet kubeadm kubectl 

Installer Docker

Installez docker selon les instructions de la documentation

 apt-get remove docker docker-engine docker.io containerd runc apt-get install apt-transport-https ca-certificates curl gnupg2 software-properties-common 

 curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add - apt-key fingerprint 0EBFCD88 

 add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/debian \ $(lsb_release -cs) \ stable" 

 apt-get update apt-get install docker-ce docker-ce-cli containerd.io 

 git clone https://github.com/rjeka/kubernetes-ceph-percona.git cd kubernetes-ceph-percona/playbooks vim masters.ini 

 # sudo c  ansible-playbook -i hosts.ini kubelet.yaml -K ansible-playbook -i hosts.ini docker.yaml -K # sudo  ansible-playbook -i hosts.ini kubelet.yaml ansible-playbook -i hosts.ini docker.yaml 

Si, pour une raison quelconque, vous ne souhaitez pas utiliser Docker, vous pouvez utiliser n'importe quel CRI. Vous pouvez en savoir plus, par exemple ici , mais cette rubrique dépasse le cadre de cet article.

Installation ETCD

Je n'entrerai pas dans les détails de la théorie, en bref: etcd est un stockage de valeurs-clés distribué open source. etcd est écrit en GO et utilisé dans kubernetes en fait, comme base de données pour stocker l'état du cluster. Pour un examen plus détaillé, consultez la documentation de kubernetes .
etcd peut être installé de plusieurs façons. Vous pouvez l'installer localement et l'exécuter en tant que démon, vous pouvez l'exécuter dans des conteneurs Docker, vous pouvez l'installer même en tant que pod kubernetes. Vous pouvez l'installer à la main, ou vous pouvez l'installer en utilisant kubeadm (je n'ai pas essayé cette méthode). Peut être installé sur des machines en cluster ou des serveurs individuels.
Je vais installer etcd localement sur les nœuds principaux et exécuter en tant que démon via systemd, ainsi que d'envisager l'installation dans docker. J'utilise etcd sans TLS, si vous avez besoin de TLS, reportez-vous à la documentation d'etcd ou de kubernetes lui-même
Aussi dans mon github sera ansible-playbook pour installer etcd avec lancement via systemd.

Numéro d'option 1
Installer localement, exécuter via systemd

Sur tous les maîtres: (sur les nœuds de travail du cluster, cette étape n'est pas nécessaire)
Étape # 1
Téléchargez et décompressez l'archive avec etcd:

 mkdir archives cd archives export etcdVersion=v3.3.10 wget https://github.com/coreos/etcd/releases/download/$etcdVersion/etcd-$etcdVersion-linux-amd64.tar.gz tar -xvf etcd-$etcdVersion-linux-amd64.tar.gz -C /usr/local/bin/ --strip-components=1 

Étape numéro 2
Créer un fichier de configuration pour ETCD

 cd .. ./create-config.sh etcd 

Le script accepte la valeur etcd en entrée et génère un fichier de configuration dans le répertoire etcd. Une fois le script exécuté, le fichier de configuration terminé sera situé dans le répertoire etcd.
Pour toutes les autres configurations, le script fonctionne sur le même principe. Il prend quelques entrées et crée une configuration dans un répertoire spécifique.

Étape numéro 3
Nous démarrons le cluster etcd et vérifions ses performances

 systemctl start etcd 

Vérification des performances du démon

 systemctl status etcd ● etcd.service - etcd Loaded: loaded (/etc/systemd/system/etcd.service; disabled; vendor preset: enabled) Active: active (running) since Sun 2019-07-07 02:34:28 MSK; 4min 46s ago Docs: https://github.com/coreos/etcd Main PID: 7471 (etcd) Tasks: 14 (limit: 4915) CGroup: /system.slice/etcd.service └─7471 /usr/local/bin/etcd --name master01 --data-dir /var/lib/etcd --listen-client-urls http://0.0.0.0:2379,http://0.0.0.0:4001 --advertise-client-urls http://10.73.71.25:2379,http://10.73.71. Jul 07 02:34:28 master01 etcd[7471]: b11e73358a31b109 [logterm: 1, index: 3, vote: 0] cast MsgVote for f67dd9aaa8a44ab9 [logterm: 2, index: 5] at term 554 Jul 07 02:34:28 master01 etcd[7471]: raft.node: b11e73358a31b109 elected leader f67dd9aaa8a44ab9 at term 554 Jul 07 02:34:28 master01 etcd[7471]: published {Name:master01 ClientURLs:[http://10.73.71.25:2379 http://10.73.71.25:4001]} to cluster d0979b2e7159c1e6 Jul 07 02:34:28 master01 etcd[7471]: ready to serve client requests Jul 07 02:34:28 master01 etcd[7471]: serving insecure client requests on [::]:4001, this is strongly discouraged! Jul 07 02:34:28 master01 systemd[1]: Started etcd. Jul 07 02:34:28 master01 etcd[7471]: ready to serve client requests Jul 07 02:34:28 master01 etcd[7471]: serving insecure client requests on [::]:2379, this is strongly discouraged! Jul 07 02:34:28 master01 etcd[7471]: set the initial cluster version to 3.3 Jul 07 02:34:28 master01 etcd[7471]: enabled capabilities for version 3.3 lines 1-19 

Et la santé du cluster lui-même:

 etcdctl cluster-health member 61db137992290fc is healthy: got healthy result from http://10.73.71.27:2379 member b11e73358a31b109 is healthy: got healthy result from http://10.73.71.25:2379 member f67dd9aaa8a44ab9 is healthy: got healthy result from http://10.73.71.26:2379 cluster is healthy etcdctl member list 61db137992290fc: name=master03 peerURLs=http://10.73.71.27:2380 clientURLs=http://10.73.71.27:2379,http://10.73.71.27:4001 isLeader=false b11e73358a31b109: name=master01 peerURLs=http://10.73.71.25:2380 clientURLs=http://10.73.71.25:2379,http://10.73.71.25:4001 isLeader=false f67dd9aaa8a44ab9: name=master02 peerURLs=http://10.73.71.26:2380 clientURLs=http://10.73.71.26:2379,http://10.73.71.26:4001 isLeader=true 

 git clone https://github.com/rjeka/kubernetes-ceph-percona.git cd kubernetes-ceph-percona/playbooks vim masters.ini 

 # sudo c  ansible-playbook -i hosts.ini -l masters etcd.yaml -K BECOME password: <sudo > # sudo  ansible-playbook -i hosts.ini -l masters etcd.yaml 

Si vous voulez exécuter etcd dans docker, alors il y a une instruction sous le spoiler.

 git clone https://github.com/rjeka/kubernetes-ceph-percona.git cd kubernetes-ceph-percona 

 apt-get install -y docker-compose 

 ./create-config.sh docker 

 docker-compose --file etcd-docker/docker-compose.yaml up -d 

 docker ps 

 root@master01:~/kubernetes-ceph-percona# docker exec -ti etcd etcdctl cluster-health member 61db137992290fc is healthy: got healthy result from http://10.73.71.27:2379 member b11e73358a31b109 is healthy: got healthy result from http://10.73.71.25:2379 member f67dd9aaa8a44ab9 is healthy: got healthy result from http://10.73.71.26:2379 cluster is healthy root@master01:~/kubernetes-ceph-percona# docker exec -ti etcd etcdctl member list 61db137992290fc: name=etcd3 peerURLs=http://10.73.71.27:2380 clientURLs=http://10.73.71.27:2379,http://10.73.71.27:4001 isLeader=false b11e73358a31b109: name=etcd1 peerURLs=http://10.73.71.25:2380 clientURLs=http://10.73.71.25:2379,http://10.73.71.25:4001 isLeader=true f67dd9aaa8a44ab9: name=etcd2 peerURLs=http://10.73.71.26:2380 clientURLs=http://10.73.71.26:2379,http://10.73.71.26:4001 isLeader=false 

 docker logs etcd 

Lancement du premier assistant kubernetes

Tout d'abord, nous devons générer une configuration pour kubeadmin

 ./create-config.sh kubeadm 

 apiVersion: kubeadm.k8s.io/v1beta1 kind: InitConfiguration localAPIEndpoint: advertiseAddress: 10.73.71.25 #    API- --- apiVersion: kubeadm.k8s.io/v1beta1 kind: ClusterConfiguration kubernetesVersion: stable #      apiServer: #    kubeadm   certSANs: - 127.0.0.1 - 10.73.71.25 - 10.73.71.26 - 10.73.71.27 controlPlaneEndpoint: 10.73.71.25 #     etcd: #  etc external: endpoints: - http://10.73.71.25:2379 - http://10.73.71.26:2379 - http://10.73.71.27:2379 networking: podSubnet: 192.168.0.0/16 #   ,   CNI  . 

Nous initions le premier maître

 kubeadm init --config=kubeadmin/kubeadm-init.yaml 

Si kubeadm fonctionne sans erreur, à la sortie, nous obtenons approximativement la sortie suivante:

 You can now join any number of control-plane nodes by copying certificate authorities and service account keys on each node and then running the following as root: kubeadm join 10.73.71.25:6443 --token ivwoap.259retezqf34amx8 \ --discovery-token-ca-cert-hash sha256:b5c93e32457c8e6478782ff62e8ef77acf72738dda59cd603cdf4821abe12ca3 \ --control-plane Then you can join any number of worker nodes by running the following on each as root: kubeadm join 10.73.71.25:6443 --token ivwoap.259retezqf34amx8 \ --discovery-token-ca-cert-hash sha256:b5c93e32457c8e6478782ff62e8ef77acf72738dda59cd603cdf4821abe12ca3 

Installation de CNI Calico

Le moment est venu d'établir un réseau dans lequel nos pods fonctionneront. J'utilise du calicot, et nous le mettrons.
Et pour commencer, configurez l'accès pour kubelet. Nous exécutons toutes les commandes sur master01
Si vous exécutez en tant que root

 export KUBECONFIG=/etc/kubernetes/admin.conf 

Si sous le simple utilisateur

 mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config 

Vous pouvez également gérer le cluster à partir de votre ordinateur portable ou de n'importe quelle machine locale. Pour ce faire, copiez le fichier /etc/kubernetes/admin.conf sur votre ordinateur portable ou toute autre machine dans $ HOME / .kube / config

Nous mettons CNI selon la documentation de Kubernetes

 kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml 

On attend que tous les pods se lèvent

 watch -n1 kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-system calico-kube-controllers-59f54d6bbc-psr2z 1/1 Running 0 96s kube-system calico-node-hm49z 1/1 Running 0 96s kube-system coredns-5c98db65d4-svcx9 1/1 Running 0 77m kube-system coredns-5c98db65d4-zdlb8 1/1 Running 0 77m kube-system kube-apiserver-master01 1/1 Running 0 76m kube-system kube-controller-manager-master01 1/1 Running 0 77m kube-system kube-proxy-nkdqn 1/1 Running 0 77m kube-system kube-scheduler-master01 1/1 Running 0 77m 

Lancement des deuxième et troisième assistants kubernetes

Avant de démarrer master02 et master03, vous devez copier les certificats avec master01 générés par kubeadm lors de la création du cluster. Je vais copier via scp
Sur master01

 export master02=10.73.71.26 export master03=10.73.71.27 scp -r /etc/kubernetes/pki $master02:/etc/kubernetes/ scp -r /etc/kubernetes/pki $master03:/etc/kubernetes/ 

Sur master02 et master03
Créer une configuration pour kubeadm

 ./create-config.sh kubeadm 

Et ajoutez master02 et master03 au cluster

 kubeadm init --config=kubeadmin/kubeadm-init.yaml 

 root@master01:~/kubernetes-ceph-percona# kubectl get pods -A -w NAMESPACE NAME READY STATUS RESTARTS AGE kube-system calico-kube-controllers-658558ddf8-t6gfs 0/1 ContainerCreating 0 11s kube-system calico-node-7td8g 1/1 Running 0 11s kube-system calico-node-dthg5 0/1 CrashLoopBackOff 1 11s kube-system calico-node-tvhkq 0/1 CrashLoopBackOff 1 11s 

 kubectl edit -n kube-system ds calico-node 

 - name: IP_AUTODETECTION_METHOD value: ens19 

 # kubectl get nodes NAME STATUS ROLES AGE VERSION master01 Ready master 28m v1.15.1 master02 Ready master 26m v1.15.1 master03 Ready master 18m v1.15.1 

 # kubectl get pods -A -o wide | grep calico kube-system calico-kube-controllers-59f54d6bbc-5lxgn 1/1 Running 0 27m kube-system calico-node-fngpz 1/1 Running 1 24m kube-system calico-node-gk7rh 1/1 Running 0 8m55s kube-system calico-node-w4xtt 1/1 Running 0 25m 

Ajouter des nœuds de travail au cluster

À l'heure actuelle, nous avons un cluster dans lequel trois nœuds maîtres fonctionnent. Mais les nœuds maîtres sont des machines exécutant l'api, le planificateur et d'autres services du cluster kubernetes. Pour pouvoir exécuter nos pods, nous avons besoin des soi-disant nœuds de travail.
Si vos ressources sont limitées, vous pouvez exécuter des modules sur des nœuds maîtres, mais je ne vous conseille pas personnellement de le faire.

 kubectl taint nodes --all node-role.kubernetes.io/master- 

Installer les nœuds kubelet, kubeadm, kubectl et docker sur le travailleur comme sur les nœuds maîtres

 apt-get update && apt-get install -y apt-transport-https curl curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - cat <<EOF >/etc/apt/sources.list.d/kubernetes.list deb https://apt.kubernetes.io/ kubernetes-xenial main EOF apt-get update apt-get install -y kubelet kubeadm kubectl apt-mark hold kubelet kubeadm kubectl 

 apt-get remove docker docker-engine docker.io containerd runc apt-get install apt-transport-https ca-certificates curl gnupg2 software-properties-common 

 curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add - apt-key fingerprint 0EBFCD88 

 add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/debian \ $(lsb_release -cs) \ stable" 

 apt-get update apt-get install docker-ce docker-ce-cli containerd.io 

 git clone https://github.com/rjeka/kubernetes-ceph-percona.git cd kubernetes-ceph-percona/playbooks vim masters.ini 

 # sudo c  ansible-playbook -i hosts.ini kubelet.yaml -K ansible-playbook -i hosts.ini docker.yaml -K # sudo  ansible-playbook -i hosts.ini kubelet.yaml ansible-playbook -i hosts.ini docker.yaml 

Il est maintenant temps de revenir à la ligne générée par kubeadm lorsque nous avons installé le nœud maître.
Elle ressemble à ça pour moi.

 kubeadm join 10.73.71.25:6443 --token ivwoap.259retezqf34amx8 \ --discovery-token-ca-cert-hash sha256:b5c93e32457c8e6478782ff62e8ef77acf72738dda59cd603cdf4821abe12ca3 

Il est nécessaire d'exécuter cette commande sur chaque nœud de travail.
Si vous n'avez pas écrit de jeton, vous pouvez générer un nouveau

 kubeadm token create --print-join-command --ttl=0 

Une fois que kubeadm fonctionne, votre nouveau nœud est entré dans le cluster et prêt à fonctionner

 This node has joined the cluster: * Certificate signing request was sent to apiserver and a response was received. * The Kubelet was informed of the new secure connection details. Run 'kubectl get nodes' on the control-plane to see this node join the cluster. 

Maintenant regardons le résultat

 root@master01:~# kubectl get nodes NAME STATUS ROLES AGE VERSION master01 Ready master 10d v1.15.1 master02 Ready master 10d v1.15.1 master03 Ready master 10d v1.15.1 worknode01 Ready <none> 5m44s v1.15.1 worknode02 Ready <none> 59s v1.15.1 worknode03 Ready <none> 51s v1.15.1 

Installer haproxy sur les nœuds de travail

Nous avons maintenant un cluster de travail avec trois nœuds maîtres et trois nœuds travailleurs.
Le problème est que maintenant nos nœuds de travail n'ont pas de mode HA.
Si vous regardez le fichier de configuration du kubelet, nous verrons que nos nœuds de travail n'accèdent qu'à l'un des trois nœuds maîtres.

 root@worknode01:~# cat /etc/kubernetes/kubelet.conf | grep server: server: https://10.73.71.27:6443 

Dans mon cas, c'est master03. Avec cette configuration, si master03 se bloque, le nœud de travail perdra la communication avec le serveur API du cluster. Pour rendre notre cluster entièrement HA, nous allons installer un Load Balancer (Haproxy) sur chacun des travailleurs, qui, selon le round robin, dispersera les demandes pour trois nœuds principaux, et dans la configuration du kubelet sur les nœuds de travail, nous changerons l'adresse du serveur en 127.0.0.1:6443
Tout d'abord, installez HAProxy sur chaque nœud de travail.
Il y a une bonne feuille de triche pour l'installation

 curl https://haproxy.debian.net/bernat.debian.org.gpg | \ apt-key add - echo deb http://haproxy.debian.net stretch-backports-2.0 main | \ tee /etc/apt/sources.list.d/haproxy.list apt-get update apt-get install haproxy=2.0.\* 

Une fois HAproxy installé, nous devons créer une configuration pour celui-ci.
Si sur les nœuds de travail il n'y a pas de répertoire avec des fichiers de configuration, nous le clonons

 git clone https://github.com/rjeka/kubernetes-ceph-percona.git cd kubernetes-ceph-percona/ 

Et exécutez le script de configuration avec le drapeau haproxy

 ./create-config.sh haproxy 

Le script configurera et redémarrera haproxy.
Vérifiez que haproxy a commencé à écouter le port 6443.

 root@worknode01:~/kubernetes-ceph-percona# netstat -alpn | grep 6443 tcp 0 0 127.0.0.1:6443 0.0.0.0:* LISTEN 30675/haproxy tcp 0 0 10.73.75.241:6443 0.0.0.0:* LISTEN 30675/haproxy 

Maintenant, nous devons dire à kubelet d'accéder à localhost au lieu du nœud maître. Pour ce faire, modifiez la valeur du serveur dans les fichiers /etc/kubernetes/kubelet.conf et /etc/kubernetes/bootstrap-kubelet.conf sur tous les nœuds de travail.

 vim /etc/kubernetes/kubelet.conf vim nano /etc/kubernetes/bootstrap-kubelet.conf 

La valeur du serveur doit prendre cette forme:

 server: https://127.0.0.1:6443 

Après avoir apporté les modifications, redémarrez les services kubelet et docker

 systemctl restart kubelet && systemctl restart docker 

Vérifiez que tous les nœuds fonctionnent correctement.

 kubectl get nodes NAME STATUS ROLES AGE VERSION master01 Ready master 29m v1.15.1 master02 Ready master 27m v1.15.1 master03 Ready master 26m v1.15.1 worknode01 Ready <none> 25m v1.15.1 worknode02 Ready <none> 3m15s v1.15.1 worknode03 Ready <none> 3m16s v1.15.1 

Jusqu'à présent, nous n'avons aucune application dans le cluster pour tester HA. Mais nous pouvons arrêter le fonctionnement de kubelet sur le premier nœud maître et nous assurer que notre cluster est resté opérationnel.

 systemctl stop kubelet && systemctl stop docker 

Vérifier à partir du deuxième nœud maître

 root@master02:~# kubectl get nodes NAME STATUS ROLES AGE VERSION master01 NotReady master 15h v1.15.1 master02 Ready master 15h v1.15.1 master03 Ready master 15h v1.15.1 worknode01 Ready <none> 15h v1.15.1 worknode02 Ready <none> 15h v1.15.1 worknode03 Ready <none> 15h v1.15.1 

Tous les nœuds fonctionnent normalement sauf celui sur lequel nous avons arrêté les services.
N'oubliez pas de réactiver les services kubernetes sur le premier nœud maître

 systemctl start kubelet && systemctl start docker 

Installation d'Ingress Controller

Le contrôleur d'entrée est un module complémentaire Kubernetes, avec lequel nous pouvons accéder à nos applications de l'extérieur. Une description détaillée se trouve dans la documentation Kuberbnetes . Il y a pas mal de contrôleurs en entrée, j'utilise un contrôleur de Nginx. Je vais parler de son installation. La documentation sur le fonctionnement, la configuration et l'installation du contrôleur Ingress de Nginx peut être consultée sur le site officiel

Commençons l'installation, toutes les commandes peuvent être exécutées avec master01.
Installez le contrôleur lui-même

 kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/mandatory.yaml 

Et maintenant - un service grâce auquel l'entrée sera disponible
Pour ce faire, préparez la config

 ./create-config.sh ingress 

Et envoyez-le à notre cluster

 kubectl apply -f ingress/service-nodeport.yaml 

Vérifiez que notre Ingress fonctionne aux bonnes adresses et écoute sur les bons ports.

 # kubectl get svc -n ingress-nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ingress-nginx NodePort 10.99.35.95 10.73.71.25,10.73.71.26,10.73.71.27 80:31669/TCP,443:31604/TCP 10m 

  kubectl describe svc -n ingress-nginx ingress-nginx Name: ingress-nginx Namespace: ingress-nginx Labels: app.kubernetes.io/name=ingress-nginx app.kubernetes.io/part-of=ingress-nginx Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app.kubernetes.io/name":"ingress-nginx","app.kubernetes.io/par... Selector: app.kubernetes.io/name=ingress-nginx,app.kubernetes.io/part-of=ingress-nginx Type: NodePort IP: 10.99.35.95 External IPs: 10.73.71.25,10.73.71.26,10.73.71.27 Port: http 80/TCP TargetPort: 80/TCP NodePort: http 31669/TCP Endpoints: 192.168.142.129:80 Port: https 443/TCP TargetPort: 443/TCP NodePort: https 31604/TCP Endpoints: 192.168.142.129:443 Session Affinity: None External Traffic Policy: Cluster Events: <none> 

Installer l'interface utilisateur Web (tableau de bord)

Kubernetes possède une interface utilisateur Web standard, à travers laquelle il est parfois pratique de consulter rapidement l'état d'un cluster ou de ses parties individuelles. Dans mon travail, j'utilise souvent le tableau de bord pour le diagnostic initial des déploiements ou l'état de parties d'un cluster.
Le lien vers la documentation est sur le site kubernetes
L'installation J'utilise la version stable, je n'ai pas encore essayé 2.0.

 #  kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yaml # 2.0 kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta1/aio/deploy/recommended.yaml 

Après avoir installé le panneau dans notre cluster, le panneau est devenu disponible sur

 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/. 

Mais pour y accéder, nous devons transférer les ports de la machine locale à l'aide du proxy kubectl. Pour moi, ce schéma n'est pas très pratique. Par conséquent, je vais modifier le service du panneau de configuration afin que le tableau de bord devienne disponible sur l'adresse de n'importe quel nœud de cluster sur le port 30443. Il existe encore d'autres façons d'accéder au tableau de bord, par exemple, par entrée. J'examinerai peut-être cette méthode dans les publications suivantes.
Pour modifier le service, exécutez le déploiement du service modifié

 kubectl apply -f dashboard/service-nodeport.yaml 

Il reste à créer l'utilisateur admin et le token pour accéder au cluster via le tableau de bord

 kubectl apply -f dashboard/rbac.yaml kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}') 

Après cela, vous pouvez vous connecter au panneau de configuration à https://10.73.71.25:30443

Écran d'accueil du tableau de bord

Félicitations! Si vous avez atteint cette étape, vous disposez d'un cluster HA fonctionnel de kubernetes, prêt pour le déploiement de vos applications.
Kubernetes , . .
, GitHub, , .
C , .