Hallo zusammen!
Es hat sich ergeben, dass unser kleines Team, nicht gerade neu und auch nicht plötzlich, dazu gewachsen ist, einige (und perspektivisch alle) Produkte in Kubernetes zu migrieren.
Die Gründe dafür sind vielfältig, aber unsere Geschichte ist kein Streit darüber.
Aus infrastruktureller Sicht war unsere Auswahl recht begrenzt. vCloud Director und vCloud Director. Wir wählten die neuere Version und beschlossen, zu beginnen.
Ein weiteres Mal blätternd durch 'The Hard Way', kam ich sehr schnell zu dem Schluss, dass ein Tool zur Automatisierung zumindest grundlegender Prozesse wie Deployment und Größenanpassung schon längst überfällig ist. Eine tiefere Recherche bei Google brachte ein Produkt namens VMware Container Service Extension (CSE) ans Licht – ein Open-Source-Produkt, das die Erstellung und Größenanpassung von k8s-Clustern für diejenigen im vCloud ermöglicht.
Hinweis: CSE hat seine Einschränkungen, aber für unsere Zwecke war es ideal. Außerdem sollte die Lösung vom Cloud-Anbieter unterstützt werden, aber da der Serverteil ebenfalls Open Source ist, verlangen Sie dessen Verfügbarkeit bei Ihrem nächsten Manager 🙂
Um das System zu nutzen, benötigen Sie ein Administratorkonto in der vCloud-Organisation und ein im Voraus erstelltes geroutetes Netzwerk für den Cluster (während des Deployments ist Internetzugang aus diesem Netzwerk erforderlich, vergessen Sie nicht, die Firewall/NAT entsprechend zu konfigurieren). Die Adressierung ist nicht entscheidend. In diesem Beispiel verwenden wir 10.0.240.0/24.
Da der Cluster nach der Erstellung verwaltet werden muss, wird die Einrichtung eines VPNs mit Routing in das erstellte Netzwerk empfohlen. Wir nutzen ein Standard-SSL-VPN, das auf dem Edge Gateway unserer Organisation konfiguriert ist.
Als Nächstes muss der CSE-Client installiert werden, von dem aus die Verwaltung der k8s-Cluster erfolgt. In meinem Fall ist das ein Arbeits-Laptop und ein paar gut versteckte Container, die für die Automatisierung zuständig sind.
Der Client erfordert eine installierte Python-Version von 3.7.3 oder höher und das installierte Modul , daher werden wir beides installieren.
pip3 install vcd-cli
pip3 install container-service-extension
Nach der Installation überprüfen wir die CSE-Version und erhalten Folgendes:
# vcd cse version
Error: No such command "cse".
Unerwartet, aber korrigierbar. Es stellte sich heraus, dass die CSE als Modul an vcd-cli angehängt werden muss.
Dazu müssen wir zunächst vcd-cli in unsere Organisation einloggen:
# vcd login MyCloud.provider.com org-dev admin
Password:
admin logged in, org: 'org-dev', vdc: 'org-dev_vDC01'
Danach erstellt vcd-cli eine Konfigurationsdatei. ~/.vcd-cli/profiles.yaml
Fügen Sie folgendes am Ende hinzu:
extensions:
- container_service_extension.client.cse
Prüfen wir anschließend erneut:
# vcd cse version
CSE, Container Service Extension for VMware vCloud Director, version 2.5.0
Der Installationsprozess des Clients ist abgeschlossen. Lassen Sie uns versuchen, den ersten Cluster bereitzustellen.
CSE verfügt über mehrere Nutzungssätze, die alle angezeigt werden können.
Zunächst erstellen wir die Schlüssel für den passwortlosen Zugriff auf den zukünftigen Cluster. Dies ist wichtig, da der Passwortzugang zu den Knoten standardmäßig deaktiviert ist, und wenn keine Schlüssel festgelegt werden, können viele Aufgaben über die Konsolen der virtuellen Maschinen durchgeführt werden, was nicht sehr bequem ist.
# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
Versuchen wir, die Clustererstellung zu starten:
vcd cse cluster create MyCluster --network k8s_cluster_net --ssh-key ~/.ssh/id_rsa.pub --nodes 3 --enable-nfsFalls wir einen Fehler erhalten: Error: Sitzung ist abgelaufen oder Benutzer nicht angemeldet. Bitte erneut einloggen. — Melden Sie sich erneut bei vcd-cli in vCloud an, wie oben beschrieben, und versuchen Sie es erneut.
Dieses Mal läuft alles gut und die Clustererstellung wurde gestartet.
cluster operation: Erstellen des Cluster vApp 'MyCluster' (38959587-54f4-4a49-8f2e-61c3a3e879e0) aus der Vorlage 'photon-v2_k8-1.12_weave-2.3.0' (Revision 1)
Die Aufgabe wird voraussichtlich etwa 20 Minuten in Anspruch nehmen; in der Zwischenzeit besprechen wir die wichtigsten Startparameter.
—network — das zuvor von uns erstellte Netzwerk.
—ssh-key — von uns erstellte Schlüssel, die auf den Knoten des Clusters gespeichert werden.
—nodes n — Anzahl der Worker-Knoten im Cluster. Der Master wird immer einer sein, das ist eine Einschränkung von CSE.
—enable-nfs — einen zusätzlichen Knoten für NFS-Freigaben unter persistenten Volumes erstellen. Eine etwas komplexe Option; wir werden später auf die Feinheiten eingehen.
In der Zwischenzeit kann man in vCloud visuell die Erstellung des Clusters beobachten.
Sobald die Clustererstellung abgeschlossen ist, ist es bereit für den Einsatz.
Überprüfen wir die Korrektheit des Deployments mit dem Befehl vcd cse cluster info MyCluster
Als Nächstes müssen wir die Konfiguration des Clusters abrufen, um sie zu verwenden. kubectl
# vcd cse cluster config MyCluster > ./.kube/config
Und wir können den Zustand des Clusters damit überprüfen:
An diesem Punkt kann man den Cluster als weitgehend betriebsbereit betrachten, wären da nicht die Probleme mit den persistenten Volumes. Da wir in vCloud sind, können wir den vSphere Provider nicht verwenden. Die Option —enable-nfs sollte dieses Problem mildern, aber es war nicht vollständig erfolgreich. Eine manuelle Nachjustierung ist erforderlich.
Für den Anfang müssen wir unserer Node eine separate Independent-Disk in vCloud erstellen. Das gewährleistet, dass unsere Daten nicht gemeinsam mit dem Cluster gelöscht werden, falls dieser entfernt wird. Außerdem verbinden wir die Disk mit NFS.
# vcd disk create nfs-shares-1 100g --description 'Kubernetes NFS shares'
# vcd vapp attach mycluster nfsd-9604 nfs-shares-1
Nun verbinden wir uns über SSH (Sie haben doch Schlüssel erstellt?) mit unserem NFS-Knoten und schließen die Disk endgültig an:
root@nfsd-9604:~# parted /dev/sdb
(parted) mklabel gpt
Warnung: Das bestehende Datenträgerlabel auf /dev/sdb wird zerstört und alle Daten auf diesem Datenträger gehen verloren. Möchten Sie fortfahren?
Ja/Nein? ja
(parted) einheit GB
(parted) mkpart primary 0 100
(parted) print
Modell: VMware Virtual disk (scsi)
Disk /dev/sdb: 100GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Datenträger-Flags:
Nummer Start Ende Größe Dateisystem Name Flags
1 0,00GB 100GB 100GB primär
(parted) quit
root@nfsd-9604:~# mkfs -t ext4 /dev/sdb1
Erstelle Dateisystem mit 24413696 4k Blöcken und 6111232 Inodes
Dateisystem-UUID: 8622c0f5-4044-4ebf-95a5-0372256b34f0
Sicherheitskopien der Superblöcke gespeichert auf Blöcken:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872
Allokation der Gruppentabellen: abgeschlossen
Schreiben der Inode-Tabellen: abgeschlossen
Erstellen des Journals (32768 Blöcke): abgeschlossen
Schreiben der Superblöcke und der Dateisystembuchhaltungsinformationen: abgeschlossen
Erstellen wir ein Verzeichnis für die Daten und mounten dort die frische Partition:
mkdir /export
echo '/dev/sdb1 /export ext4 defaults 0 0' >> /etc/fstab
mount -a
Lassen Sie uns fünf Testpartitionen erstellen und diese für den Cluster freigeben:
>cd /export
>mkdir vol1 vol2 vol3 vol4 vol5
>vi /etc/exports
#Fügen Sie dies ans Ende der Datei hinzu
/export/vol1 *(rw,sync,no_root_squash,no_subtree_check)
/export/vol2 *(rw,sync,no_root_squash,no_subtree_check)
/export/vol3 *(rw,sync,no_root_squash,no_subtree_check)
/export/vol4 *(rw,sync,no_root_squash,no_subtree_check)
/export/vol5 *(rw,sync,no_root_squash,no_subtree_check)
#:wq! ;)
#Anschließend exportieren wir die Partitionen
>exportfs -r
Nach all dieser Magie können wir PV und PVC in unserem Cluster etwa so erstellen:
PV:
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-vol1
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteMany
nfs:
# Gleiche IP wie der NFS-Host, zu dem wir vorher SSH hatten.
server: 10.150.200.22
path: "/export/vol1"
EOF
PVC:
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nfs-pvc
spec:
accessModes:
- ReadWriteMany
storageClassName: ""
resources:
requests:
storage: 10Gi
EOF
Damit endet die Geschichte der Erstellung eines Clusters und beginnt die Geschichte seines Lebenszyklus. Als Bonus – hier sind zwei nützliche CSE-Befehle, die manchmal helfen können, Ressourcen gut zu sparen oder auch nicht:
#Увеличиваем размер кластера до 8 воркер нод
>cse cluster resize MyCluster --network k8s_cluster_net --nodes 8
#Выводим ненужные ноды из кластера с их последующим удалением
>vcd cse node delete MyCluster node-1a2v node-6685 --yes
Vielen Dank für Ihre Zeit, wenn es Fragen gibt – fragen Sie gerne in den Kommentaren.
Quelle: habr.com
