Wir entwickeln eine Umgebung für die Arbeit mit Microservices. Teil 1 Installation von Kubernetes HA auf Bare Metal (Debian)

Hallo liebe Leser von Habr!

Mit dieser Veröffentlichung möchte ich eine Reihe von Artikeln über die Bereitstellung einer vollwertigen Orchestrierungsumgebung mit Kubernetes-Containern beginnen, die betriebsbereit sind und Anwendungen starten.
Ich möchte nicht nur erläutern, wie ein Kubernetes-Cluster bereitgestellt wird, sondern auch, wie ein Cluster nach der Installation konfiguriert wird und wie praktische Tools und Add-Ons hinzugefügt werden, um die Microservice-Architektur zu verwenden.

Dieser Zyklus besteht aus mindestens vier Artikeln:

1. Im ersten Teil werde ich Ihnen erklären, wie Sie einen ausfallsicheren Kubernetes-Cluster auf Bare Iron installieren, ein Standard-Dashboard installieren und den Zugriff darauf konfigurieren sowie einen Ingress-Controller installieren.
2. In einem zweiten Artikel werde ich Ihnen zeigen, wie Sie einen Ceph-Failovercluster bereitstellen und wie Sie RBD-Volumes in unserem Kubernetes-Cluster verwenden. Ich werde auch ein wenig auf andere Arten von Speichern eingehen (Speicher) und die lokale Speicherung genauer betrachten. Außerdem werde ich Ihnen erklären, wie Sie einen fehlertoleranten S3-Speicher basierend auf dem erstellten CEPH-Cluster organisieren
3. Im dritten Artikel werde ich beschreiben, wie ein Failover-Cluster MySql in unserem Kubernetes-Cluster bereitgestellt wird, nämlich Percona XtraDB-Cluster auf Kubernetes. Außerdem werde ich alle Probleme beschreiben, auf die wir gestoßen sind, als wir beschlossen haben, die Datenbank auf Kubernetes zu übertragen.
4. Im vierten Artikel werde ich versuchen, alles zusammenzustellen und Ihnen zu erklären, wie Sie eine Anwendung bereitstellen und ausführen, die die Datenbank- und Ceph-Volumes verwendet. Ich werde Ihnen erklären, wie Sie den Ingress-Controller für den Zugriff auf unsere Anwendung von außen und den automatischen Zertifikatbestelldienst von Let's Encrypt konfigurieren. Zum anderen können diese Zertifikate automatisch auf dem neuesten Stand gehalten werden. Wir werden RBAC auch im Zusammenhang mit dem Zugriff auf das Control Panel ansprechen. Ich erzähle Ihnen kurz und bündig von Helm und seiner Installation.
   Wenn Sie an den Informationen in diesen Veröffentlichungen interessiert sind, dann willkommen!

Eintrag:

Für wen sind diese Artikel? Zuallererst für diejenigen, die gerade ihre Reise in das Studium von Kubernetes beginnen. Dieser Zyklus ist auch nützlich für Ingenieure, die daran denken, von einem Monolithen zu Microservices zu wechseln. Alles, was beschrieben wird, ist meine Erfahrung, einschließlich derjenigen, die ich bei der Übersetzung mehrerer Projekte von einem Monolithen nach Kubernetes erhalten habe. Es ist möglich, dass einige Teile der Veröffentlichungen für erfahrene Ingenieure von Interesse sind.

Was ich in dieser Reihe von Veröffentlichungen nicht im Detail betrachten werde:

• Erklären Sie ausführlich, was Kubernetes-Grundelemente sind, z. B.: Pod, Bereitstellung, Service, Ingress usw.
• Ich werde CNI (Container Networking Interface) sehr oberflächlich betrachten, wir verwenden callico daher andere Lösungen, die ich nur auflisten werde.
• Docker-Image-Erstellungsprozess.
• CI \ CD-Prozesse. (Vielleicht eine separate Veröffentlichung, aber nach dem gesamten Zyklus)
• Helm; Es wurde ziemlich viel über ihn geschrieben. Ich werde nur auf den Prozess der Installation im Cluster und der Einrichtung des Clients eingehen.

Was ich im Detail betrachten möchte:

• Schrittweise schrittweise Bereitstellung des Kubernetes-Clusters. Ich werde Kubeadm verwenden. Gleichzeitig werde ich Schritt für Schritt detailliert auf den Prozess der Installation eines Clusters auf Bare Metal, verschiedene Arten der ETCD-Installation und die Konfiguration von Dateien für kube admina eingehen. Ich werde versuchen, alle Ausgleichsoptionen für den Ingress-Controller und den Unterschied in den verschiedenen Zugriffsschemata von Arbeitsknoten auf die Server-API zu klären.
  Ich weiß, dass es heute viele großartige Tools für die Bereitstellung von Kubernetes gibt, zum Beispiel Kubespray oder denselben Rancher. Vielleicht ist es für jemanden bequemer, sie zu benutzen. Aber ich denke, es gibt viele Ingenieure, die das Problem genauer betrachten möchten.
• CEPH-Terminologie und schrittweise Installation des CEPH-Clusters sowie schrittweise Anweisungen zum Verbinden des Ceph-Speichers mit dem von Kubernetes erstellten Cluster.
• lokale Speicher, Verbindung zum Kubernetes-Cluster sowie Unterschiede zu Verbindungen wie Hostpfad usw.
• kubernetes-Betreiber und die Bereitstellung von Percona XtraDB Cluster mit Hilfe des Betreibers sowie der Versuch, nach sechs Monaten Erfahrung in der Produktion über die Vor- und Nachteile einer solchen Lösung zu sprechen. Und ich werde auch ein paar Pläne für die Finalisierung des Betreibers von percona teilen.

Inhaltsverzeichnis:

1. Liste der Hosts, Hostressourcen, Betriebssystem- und Softwareversionen
2. Kubernetes Cluster HA-Diagramm
3. Bevor Sie beginnen oder bevor Sie beginnen
4. Füllen Sie die Datei create-config.sh aus
5. Betriebssystem-Kernel-Update
6. Vorbereiten von Knoten Installieren von Kubelet, Kubectl, Kubeadm und Docker
7. ETCD installieren (verschiedene Optionen)
8. Starten des ersten Kubernetes-Assistenten
9. CNI Callico Installation
10. Start des zweiten und dritten Kubernetes-Assistenten
11. Fügen Sie dem Cluster einen Arbeitsknoten hinzu
12. Installieren Sie Haproxy auf Worker-Knoten für HA
13. Ingress Controller installieren
14. Installieren Sie die Web-Benutzeroberfläche (Dashboard)

Liste und Ziel der Hosts

Alle Knoten meines Clusters befinden sich auf virtuellen Maschinen mit einem vorinstallierten Debian 9-Stretch-System mit dem Kernel 4.19.0-0.bpo.5-amd64. Für die Virtualisierung verwende ich Proxmox VE.

Tabellen-VM und ihre Leistungsmerkmale:

Es ist nicht erforderlich, dass Sie nur eine solche Konfiguration von Maschinen haben müssen, aber ich rate Ihnen dennoch, die Empfehlungen der offiziellen Dokumentation zu befolgen und für Master die RAM-Größe auf mindestens 4 GB zu erhöhen. Mit Blick auf die Zukunft werde ich sagen, dass ich mit einer kleineren Anzahl Störungen in der Arbeit von CNI Callico festgestellt habe
Ceph ist auch in Bezug auf Speicher- und Festplattenleistung ziemlich unersättlich.
Unsere Produktionsinstallationen funktionieren ohne Bare-Metal-Virtualisierung, aber ich kenne viele Beispiele, bei denen virtuelle Maschinen mit relativ bescheidenen Ressourcen ausreichten. Es hängt alles von Ihren Bedürfnissen und Arbeitslasten ab.

Listen- und Softwareversionen

Ab Version 1.14 hat Kubeadm die Unterstützung der v1alpha3-API-Version eingestellt und vollständig auf die v1beta1-API-Version umgestellt, die in naher Zukunft unterstützt wird. In diesem Artikel werde ich daher nur auf v1beta1 eingehen.
Wir glauben, dass Sie die Maschinen für den Kubernetes-Cluster vorbereitet haben. Sie sind alle über das Netzwerk für einander zugänglich, haben eine „Internetverbindung“ zum Internet und ein „sauberes“ Betriebssystem ist auf ihnen installiert.
Für jeden Installationsschritt werde ich klären, auf welchen Maschinen der Befehl oder Befehlsblock ausgeführt wird. Führen Sie alle Befehle als root aus, sofern nicht anders angegeben.
Alle Konfigurationsdateien sowie ein Skript zur Vorbereitung stehen in meinem Github zum Download zur Verfügung
Also fangen wir an.

Kubernetes Cluster HA-Diagramm

Ein ungefähres Diagramm des HA-Clusters. Der Künstler von mir ist, um ehrlich zu sein, so lala, aber ich werde versuchen, es kurz und bündig zu erklären, ohne mich besonders mit der Theorie zu befassen.
Unser Cluster wird also aus drei Masterknoten und drei Arbeiterknoten bestehen. Auf jedem Kubernetes-Masterknoten funktionieren etcd (grüne Pfeile im Diagramm) und kubernetes-Serviceteile für uns. Nennen wir sie generisch - Kubeapi.
Über den Mastercluster etcd tauschen Knoten den Status des Kubernetes-Clusters aus. Ich werde die gleichen Adressen wie die Einstiegspunkte des Eingangscontrollers für den externen Verkehr angeben (rote Pfeile im Diagramm).
Auf Worker-Knoten arbeitet kubelet für uns, das über haproxy, das lokal auf jedem Worker-Knoten installiert ist, mit dem kubernetes-API-Server kommuniziert. Als Server-API-Adresse für kubelet verwende ich den localhost 127.0.0.1:6443, und haproxy on roundrobin verteilt Anforderungen auf drei Masterknoten und überprüft auch die Verfügbarkeit der Masterknoten. Mit diesem Schema können wir HA erstellen. Im Falle eines Ausfalls eines der Masterknoten senden die Arbeiterknoten leise Anforderungen an die beiden verbleibenden Masterknoten.

Bevor Sie beginnen

Bevor wir mit der Arbeit an jedem Knoten des Clusters beginnen, stellen wir die Pakete bereit, die wir für die Arbeit benötigen:

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

Kopieren Sie auf den Masterknoten das Repository mit Konfigurationsvorlagen

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

Überprüfen Sie, ob die IP-Adresse der Hosts auf den Assistenten mit der übereinstimmt, die der kubernetes-Server abhört

 hostname && hostname -i master01 10.73.71.25 

und so für alle Masterknoten.

Deaktivieren Sie unbedingt SWAP, da sonst kubeadm einen Fehler auslöst

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

Sie können den Befehl deaktivieren

 swapoff -a 

Denken Sie daran, in / etc / fstab zu kommentieren

Füllen Sie die Datei create-config.sh aus

Um die für die Installation des kubernetes-Clusters erforderlichen Konfigurationen automatisch auszufüllen, habe ich ein kleines Skript create-config.sh hochgeladen. Sie müssen es buchstäblich 8 Zeilen ausfüllen. Geben Sie die IP-Adressen und den Hostnamen Ihrer Master an. Und geben Sie auch etcd tocken an, Sie können es nicht ändern. Ich werde unten den Teil des Skripts angeben, in dem Sie Änderungen vornehmen müssen.

 #!/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" 

Betriebssystem-Kernel-Update

Dieser Schritt ist optional, da der Kernel über die Backports aktualisiert werden muss und Sie dies auf eigene Gefahr und Gefahr tun. Möglicherweise tritt dieses Problem nie auf. In diesem Fall können Sie den Kernel auch nach der Bereitstellung von Kubernetes aktualisieren. Im Allgemeinen entscheiden Sie.
Ein Kernel-Update ist erforderlich, um den alten Docker-Fehler zu beheben, der nur in der Linux-Kernel-Version 4.18 behoben wurde. Sie können hier mehr über diesen Fehler lesen. Ein Fehler wurde im periodischen Hängen der Netzwerkschnittstelle auf den Kubernetes-Knoten mit dem Fehler ausgedrückt:

 waiting for eth0 to become free. Usage count = 1 

Nach der Installation des Betriebssystems hatte ich die Kernel-Version 4.9

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

Auf jeder Maschine für Kubernetes führen wir aus
Schritt 1
Fügen Sie der Quellliste Back-Ports hinzu

 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 

Schritt Nummer 2
Paketinstallation

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

Schritt Nummer 3
Starten Sie neu

 reboot 

Überprüfen Sie, ob alles in Ordnung ist

 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 

Vorbereiten von Knoten Installieren von Kubelet, Kubectl, Kubeadm und Docker

Installieren Sie Kubelet, Kubectl, Kubeadm

Wir setzen alle Knoten des Clusters gemäß der Dokumentation von Kubernetes ein

 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 

Installieren Sie Docker

Installieren Sie Docker gemäß den Anweisungen in der Dokumentation

 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 

Wenn Sie aus irgendeinem Grund kein Docker verwenden möchten, können Sie ein beliebiges CRI verwenden. Sie können zum Beispiel hier darüber lesen, aber dieses Thema geht über den Rahmen dieses Artikels hinaus.

ETCD-Installation

Ich werde nicht kurz auf die Theorie eingehen: etcd ist ein Open-Source-verteilter Schlüsselwertspeicher. etcd ist in GO geschrieben und wird in Kubernetes tatsächlich als Datenbank zum Speichern des Clusterstatus verwendet. Eine ausführlichere Übersicht finden Sie in der Dokumentation zu kubernetes .
etcd kann auf viele Arten installiert werden. Sie können es lokal installieren und als Daemon ausführen, Sie können es in Docker-Containern ausführen, Sie können es sogar als Kubernetes-Bottom installieren. Sie können es von Hand oder mit kubeadm installieren (ich habe diese Methode nicht ausprobiert). Kann auf Cluster-Computern oder einzelnen Servern installiert werden.
Ich werde etcd lokal auf den Masterknoten installieren und als Daemon über systemd ausführen sowie die Installation in Docker in Betracht ziehen. Ich verwende etcd ohne TLS. Wenn Sie TLS benötigen, lesen Sie die Dokumentation zu etcd oder kubernetes
Auch in meinem Github wird Ansible-Playbook für die Installation von etcd mit Start über systemd sein.

Option Nummer 1
Lokal installieren, über systemd ausführen

Auf allen Mastern: (Auf den Arbeitsknoten des Clusters ist dieser Schritt nicht erforderlich.)
Schritt 1
Laden Sie das Archiv herunter und entpacken Sie es mit 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 

Schritt Nummer 2
Erstellen Sie eine Konfigurationsdatei für ETCD

 cd .. ./create-config.sh etcd 

Das Skript verwendet den Wert etcd als Eingabe und generiert eine Konfigurationsdatei im Verzeichnis etcd. Nachdem das Skript ausgeführt wurde, befindet sich die fertige Konfigurationsdatei im Verzeichnis etcd.
Bei allen anderen Konfigurationen funktioniert das Skript nach dem gleichen Prinzip. Es nimmt einige Eingaben entgegen und erstellt eine Konfiguration in einem bestimmten Verzeichnis.

Schritt Nummer 3
Wir starten den etcd-Cluster und überprüfen seine Leistung

 systemctl start etcd 

Überprüfen der Leistung des Dämons

 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 

Und die Gesundheit des Clusters selbst:

 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 

Wenn Sie etcd im Docker ausführen möchten, befindet sich unter dem Spoiler eine Anweisung.

 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 

Starten des ersten Kubernetes-Assistenten

Zunächst müssen wir eine Konfiguration für kubeadmin generieren

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

Wir initiieren den ersten Meister

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

Wenn kubeadm fehlerfrei funktioniert, erhalten wir am Ausgang ungefähr den folgenden Ausgang:

 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 

CNI Calico Installation

Es ist an der Zeit, ein Netzwerk aufzubauen, in dem unsere Pods arbeiten werden. Ich benutze Kaliko, und wir werden es sagen.
Konfigurieren Sie zunächst den Zugriff für Kubelet. Wir führen alle Befehle auf master01 aus
Wenn Sie als root ausgeführt werden

 export KUBECONFIG=/etc/kubernetes/admin.conf 

Wenn unter dem einfachen Benutzer

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

Sie können den Cluster auch von Ihrem Laptop oder einem beliebigen lokalen Computer aus verwalten. Kopieren Sie dazu die Datei /etc/kubernetes/admin.conf auf Ihren Laptop oder einen anderen Computer in $ HOME / .kube / config

Wir setzen CNI gemäß der Kubernetes-Dokumentation ein

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

Wir warten, bis alle Schoten aufgehen

 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 

Start des zweiten und dritten Kubernetes-Assistenten

Bevor Sie master02 und master03 starten, müssen Sie die Zertifikate mit master01 kopieren, die kubeadm beim Erstellen des Clusters generiert hat. Ich werde über scp kopieren
Auf 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/ 

Auf master02 und master03
Erstellen Sie eine Konfiguration für kubeadm

 ./create-config.sh kubeadm 

Fügen Sie dem Cluster master02 und master03 hinzu

 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 

Fügen Sie dem Cluster Arbeitsknoten hinzu

Im Moment haben wir einen Cluster, in dem drei Masterknoten ausgeführt werden. Masterknoten sind jedoch Computer, auf denen API, Scheduler und andere Dienste des Kubernetes-Clusters ausgeführt werden. Damit wir unsere Pods ausführen können, benötigen wir die sogenannten Worker-Knoten.
Wenn Sie nur über begrenzte Ressourcen verfügen, können Sie Pods auf Masterknoten ausführen. Ich persönlich rate jedoch nicht dazu.

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

Installieren Sie die Knoten kubelet, kubeadm, kubectl und docker auf dem Worker wie auf den Masterknoten

 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 

Jetzt ist es Zeit, zu der Zeile zurückzukehren, die kubeadm bei der Installation des Masterknotens generiert hat.
Sie sieht für mich so aus.

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

Dieser Befehl muss auf jedem Arbeitsknoten ausgeführt werden.
Wenn Sie kein Token geschrieben haben, können Sie ein neues generieren

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

Nachdem kubeadm funktioniert hat, wird Ihr neuer Knoten in den Cluster eingegeben und ist arbeitsbereit

 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. 

Schauen wir uns nun das Ergebnis an

 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 

Installieren Sie haproxy auf Arbeitsknoten

Jetzt haben wir einen Arbeitscluster mit drei Hauptknoten und drei Arbeitsknoten.
Das Problem ist, dass unsere Worker-Knoten jetzt keinen HA-Modus haben.
Wenn Sie sich die Kubelet-Konfigurationsdatei ansehen, werden Sie feststellen, dass unsere Worker-Knoten nur auf einen der drei Master-Knoten zugreifen.

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

In meinem Fall ist dies master03. Bei dieser Konfiguration verliert der Worker-Knoten bei einem Absturz von master03 die Kommunikation mit dem Cluster-API-Server. Um unseren Cluster vollständig HA zu machen, installieren wir auf jedem der Worker einen Load Balancer (Haproxy), der laut Round Robin Anforderungen für drei Masterknoten verteilt, und in der Kubelet-Konfiguration auf Worker-Knoten ändern wir die Serveradresse in 127.0.0.1:6443
Installieren Sie zunächst HAProxy auf jedem Arbeitsknoten.
Es gibt einen guten Spickzettel für die 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.\* 

Nach der Installation von HAproxy müssen wir eine Konfiguration dafür erstellen.
Wenn auf den Worker-Knoten kein Verzeichnis mit Konfigurationsdateien vorhanden ist, klonen wir es

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

Führen Sie das Konfigurationsskript mit dem Haproxy-Flag aus

 ./create-config.sh haproxy 

Das Skript konfiguriert haproxy und startet es neu.
Überprüfen Sie, ob Haproxy Port 6443 abhört.

 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 

Jetzt müssen wir kubelet anweisen, auf localhost anstatt auf den Masterknoten zuzugreifen. Bearbeiten Sie dazu den Serverwert in den Dateien /etc/kubernetes/kubelet.conf und /etc/kubernetes/bootstrap-kubelet.conf auf allen Arbeitsknoten.

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

Der Serverwert sollte folgende Form annehmen:

 server: https://127.0.0.1:6443 

Starten Sie nach dem Vornehmen der Änderungen die Kubelet- und Docker-Dienste neu

 systemctl restart kubelet && systemctl restart docker 

Überprüfen Sie, ob alle Knoten ordnungsgemäß funktionieren.

 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 

Bisher haben wir keine Anwendungen im Cluster, um HA zu testen. Wir können jedoch den Betrieb von kubelet auf dem ersten Masterknoten stoppen und sicherstellen, dass unser Cluster betriebsbereit bleibt.

 systemctl stop kubelet && systemctl stop docker 

Überprüfen Sie vom zweiten Masterknoten

 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 

Alle Knoten funktionieren normal, außer dem, auf dem wir die Dienste gestoppt haben.
Vergessen Sie nicht, die kubernetes-Dienste auf dem ersten Masterknoten zurückzusetzen

 systemctl start kubelet && systemctl start docker 

Ingress Controller installieren

Ingress Controller ist das Kubernetes-Add-On, mit dem wir von außen auf unsere Anwendungen zugreifen können. Eine ausführliche Beschreibung finden Sie in der Kuberbnetes-Dokumentation . Es gibt ziemlich viele Controller, ich verwende einen Controller von Nginx. Ich werde über die Installation sprechen. Die Dokumentation zu Betrieb, Konfiguration und Installation des Ingress-Controllers von Nginx finden Sie auf der offiziellen Website

Beginnen wir mit der Installation, alle Befehle können mit master01 ausgeführt werden.
Installieren Sie den Controller selbst

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

Und jetzt - ein Service, über den Ingress verfügbar sein wird
Bereiten Sie dazu die Konfiguration vor

 ./create-config.sh ingress 

Und senden Sie es an unseren Cluster

 kubectl apply -f ingress/service-nodeport.yaml 

Überprüfen Sie, ob unser Ingress an den richtigen Adressen arbeitet und die richtigen Ports überwacht.

 # 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> 

Installieren Sie die Web-Benutzeroberfläche (Dashboard)

Kubernetes verfügt über eine Standard-Web-Benutzeroberfläche, über die es manchmal bequem ist, den Status eines Clusters oder seiner einzelnen Teile schnell anzuzeigen. In meiner Arbeit verwende ich häufig das Dashboard für die Erstdiagnose von Bereitstellungen oder den Status von Teilen eines Clusters.
Der Link zur Dokumentation befindet sich auf der Website kubernetes
Installation Ich benutze die stabile Version, ich habe 2.0 noch nicht ausprobiert.

 #  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 

Nachdem wir das Panel in unserem Cluster installiert hatten, wurde das Panel unter verfügbar

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

Um dorthin zu gelangen, müssen wir die Ports vom lokalen Computer mithilfe des kubectl-Proxys weiterleiten. Für mich ist dieses Schema nicht sehr praktisch. Daher werde ich den Dienst des Control Panels so ändern, dass das Dashboard unter der Adresse eines beliebigen Clusterknotens an Port 30443 verfügbar wird. Es gibt noch andere Möglichkeiten, auf das Dashboard zuzugreifen, z. B. über Ingress. Vielleicht werde ich diese Methode in den folgenden Veröffentlichungen betrachten.
Führen Sie zum Ändern des Dienstes die Bereitstellung des geänderten Dienstes aus

 kubectl apply -f dashboard/service-nodeport.yaml 

Der Administrator und das Token müssen noch erstellt werden, um über das Dashboard auf den Cluster zuzugreifen

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

Danach können Sie sich unter https://10.73.71.25:30443 bei der Systemsteuerung anmelden

Dashboard-Startbildschirm

Glückwunsch! Wenn Sie diesen Schritt erreicht haben, verfügen Sie über einen funktionierenden HA-Cluster von Kubernetes, der für die Bereitstellung Ihrer Anwendungen bereit ist.
Kubernetes , . .
, GitHub, , .
C , .