Allgemeines

Die Leocloud ist eine bare metal Kubernetes - Installation, die zur Verfügung steht, um Cloud - Anwendungen zu hosten. Die dort eingesetzten Anwendungen stehen in einer eigenen Subdomain von cloud.htl-leonding.ac.at zur Verfügung.

Verwenden Sie folgenden Prompt für Ihren Agenten:

Read https://cloud.htl-leonding.ac.at/llms.txt and follow it.
Install the LeoCloud skill into this repository, then deploy this project to LeoCloud.

Um Anwendungen in der LeoCloud installieren zu können, müssen Sie ein gültiges Konto der HTL-Leonding haben. Es ist keine eigenene Registrierung notwendig, zur Anmeldung wird das normale Schulkonto verwendet.

Es werden folgende Commandline - Programme benötigt:

Die Commandline - Tools leocloud und kubectl müssen sich in einem Ordner befinden, der im Suchpfad des Betriebssystems liegt.

Anmerkungen

Für das Arbeiten mit der LeoCloud sind Grundkenntnisse im Cloud-Computing und Kubernetes erforderlich. Es ist nicht erwünscht die LeoCloud zur Software - Entwicklung zu verwenden. Zum Erstellen und Debuggen einer Anwendung muss zuerst minikube verwendet werden. LeoCloud ist 1:1 kompatibel mit minikube. Erst wenn die Anwendung problemlos auf minikube funktioniert kann sie auf der LeoCloud eingespielt werden. Wenn Sie Fragen zur LeoCloud haben ist es zwingend erforderlich, dass vorher die Anwendung, um die es geht, auf minikube problemlos läuft und diese erfolgreich vorgeführt werden kann. Erst danach können angebliche Probleme mit der LeoCloud behandelt werden.

leocloud

Leocloud für Linux und OSX

um leocloud zu installieren führen Sie im Terminal folgendes aus:

bash -c "$(curl -fsSL https://cloud.htl-leonding.ac.at/html/install.sh)"

leocloud für Windows

Es gibt kein leocloud für Windows. Es wird auch keine leocloud.exe angeboten, weder zum Herunterladen noch im Archiv der Clients. LeoCloud wird für Linux und macOS ausgeliefert.

Unter Windows arbeiten Sie mit dem Windows-Subsystem für Linux (WSL): Sie installieren dort Ubuntu und darin die Linux-Version von leocloud. Das ist der einzige unterstützte Weg.

  1. Installieren Sie Ubuntu für Windows.

  2. Aktualisieren Sie Ubuntu für Windows mit:

    sudo apt update && sudo apt full-upgrade

    Starten Sie Ubuntu danach neu, und zwar nicht in Ubuntu, sondern in der PowerShell:

    wsl --shutdown
    sudo do-release-upgrade

  3. installieren Sie leocloud wie in Leocloud für Linux und OSX beschrieben.

leocloud zeigt die Adresse der Login - Seite immer im Terminal an und versucht dann, sie im Browser zu öffnen. Sollte sich das Browser - Login Fenster nicht automatisch öffnen (z.b. unter Windows mit WSL2), kopieren Sie die angezeigte Adresse und öffnen Sie sie selbst in einem Browser.

kubectl

kubectl muss laut den Anweisungen unter Install Tools installiert sein. Die korrekte Installation muss durch folgende Eingabe im Terminal überprüft werden:

kubectl

Es sollten jetzt die verfügbaren kubectl Kommandos aufgelistet werden.

kubectl config Datei erstellen

Damit kubectl funktioniert brauchen wir eine gültige Konfigurationsdatei. Diese wird als ~/.kube/config gespeichert.

Eine bereits vorhandene Datei müssen Sie nicht umbenennen oder löschen. Ihre LeoCloud - Einträge werden in die vorhandene Datei eingefügt; alle anderen Cluster, Benutzer und Kontexte, die Sie schon hatten, bleiben unverändert erhalten.

Nach einem erfolgreichen Login ist der Kontext leocloud der aktuelle Kontext. kubectl arbeitet danach ohne weitere Angaben in Ihrem eigenen Namespace.

Für das Zusammenführen wird kubectl selbst verwendet, es muss also installiert sein (siehe kubectl). Fehlt kubectl, bricht der Befehl mit einer entsprechenden Meldung ab und ändert nichts an Ihrer Konfigurationsdatei.

Die Datei enthält ein Zugangs - Token und wird deshalb so angelegt, dass nur Ihr eigenes Benutzerkonto sie lesen kann.

Die Konfigurationsdatei wird erstellt mit:

leocloud auth login

Danach überprüfen wir, ob alles funktioniert:

kubectl get nodes
kubectl config view

In der Ausgabe des letzten Kommandos sehen Sie den Namen Ihres Namespaces. Ab jetzt können sie in ihrem eigenen Namespace with gewohnt mit kubectl arbeiten. Der einzige Unterschied zu minikube ist, dass ihr Namespace - Name nicht "default" ist.

die Sitzung auf diesem Rechner beenden

leocloud auth logout

Damit werden die gespeicherten Zugangsdaten von diesem Rechner entfernt, und aus ~/.kube/config werden genau jene Einträge entfernt, die der Login angelegt hat. Alle anderen Einträge in dieser Datei bleiben bestehen.

Important
 Sie sind damit noch nicht im Browser abgemeldet. Solange die Single - Sign - On - Sitzung im Browser besteht, meldet Sie ein neuer Login sofort wieder als dieselbe Person an, ohne nach dem Passwort zu fragen. Der Befehl öffnet deshalb die Abmelde - Seite im Browser. Bestätigen Sie die Abmeldung dort mit einem Klick auf "Logout". Erst danach können Sie sich als jemand anderer anmelden. Öffnet sich kein Browser, dann öffnen Sie die Adresse, die der Befehl im Terminal anzeigt, selbst in einem Browser. Das gilt auch dann, wenn auf diesem Rechner keine Sitzung mehr gespeichert war.

die eigene Homepage erstellen und aufrufen

leocloud get template nginx | kubectl apply -f -

Dies startet das Deployment. Anschließend beobachten Sie den Vorgang mit

kubectl get pods

bis alle Pods "RUNNING" sind.

den eigenen Hostnamen anzeigen

kubectl describe ingress

die eigene Homepage öffnen

Die Homepage öffnet sich mit:

leocloud get home

Dies zeigt Ihnen im Browser die Informationen an, die sie zum Erstellen Ihrer Deployments und Services benötigen.

Was ein Pod in der LeoCloud nicht darf

Ihre Pods laufen auf Rechnern, die Sie mit allen anderen teilen. Deshalb gilt in jedem LeoCloud-Namespace die Kubernetes-Stufe baseline (Pod Security Standard). Ein Pod wird abgelehnt, wenn er eines der folgenden Dinge verlangt:

  • das Netzwerk, die Prozesse oder die IPC des Rechners (hostNetwork, hostPID, hostIPC),

  • ein Verzeichnis des Rechners als Volume (hostPath),

  • einen Port direkt auf dem Rechner (hostPort),

  • den privilegierten Modus (privileged: true),

  • zusätzliche Linux-Capabilities (capabilities.add, etwa NET_ADMIN oder SYS_ADMIN).

Alles andere funktioniert wie bisher — die Vorlage leocloud get template nginx zum Beispiel ist davon nicht betroffen. Für einen Webserver brauchen Sie keinen Port auf dem Rechner: dafür gibt es den Service und den Ingress.

Was Sie sehen, wenn etwas abgelehnt wird

  • Ein Pod, den Sie direkt anlegen, wird sofort abgelehnt. Die Meldung nennt die Stufe und das Feld:

    pods "..." is forbidden: violates PodSecurity "baseline:latest": host namespaces (hostNetwork=true)

  • Ein Deployment (ebenso Job, CronJob, StatefulSet) wird angenommen. kubectl apply gibt dabei eine Warnung aus, die das Feld nennt:

    Warning: would violate PodSecurity "baseline:latest": host namespaces (hostNetwork=true)

    Die Pods dazu werden aber nicht angelegt: kubectl get pods zeigt keine. Den Grund sehen Sie mit

    kubectl get events

    als FailedCreate mit derselben Meldung. Entfernen Sie das genannte Feld aus Ihrem Deployment und wenden Sie es erneut an.

Diese Stufe können Sie in Ihrem Namespace nicht ändern oder abschalten.

Ein Pod, der bereits läuft, wird nicht beendet. Muss er aber neu angelegt werden — bei einer neuen Version Ihres Deployments oder wenn ein Rechner neu startet —, wird der neue Pod abgelehnt.

Wie viel Platz ein Pod auf dem Rechner hat

Ein Container schreibt nicht nur in seine persistenten Volumes, sondern auch auf die Festplatte des Rechners, auf dem er läuft. Dazu zählt:

  • alles, was er in sein eigenes Dateisystem schreibt, etwa nach /tmp,

  • seine Logs (alles, was er auf die Konsole ausgibt),

  • Volumes vom Typ emptyDir.

Diese Festplatte teilen Sie mit allen anderen. Deshalb gelten in jedem LeoCloud-Namespace folgende Grenzen (Kubernetes nennt diesen Speicher ephemeral-storage):

  • Ein Container, der selbst nichts angibt, darf 2Gi schreiben. Reserviert werden für ihn 100Mi.

  • Ein Container darf höchstens 20Gi verlangen. Ein Pod, der mehr verlangt, wird abgelehnt.

  • Alle Pods eines Namespaces zusammen dürfen höchstens 40Gi verlangen. Zwanzig Container ohne eigene Angabe füllen das bereits. Während ein Deployment eine neue Version ausrollt, zählen der alte und der neue Pod gleichzeitig.

Braucht ein Container mehr als 2Gi, geben Sie die Grenze im Deployment selbst an, bis höchstens 20Gi:

    containers:
      - name: meine-anwendung
        resources:
          requests:
            ephemeral-storage: 1Gi
          limits:
            ephemeral-storage: 5Gi

Geben Sie dabei immer auch limits an. Ein Container, der nur requests nennt, bekommt die Grenze von 2Gi; verlangt er mehr als 2Gi, wird er abgelehnt.

Daten, die wachsen, gehören in ein PersistentVolumeClaim, nicht in das Dateisystem des Containers: eine Datenbank, hochgeladene Dateien, Backups, Archive. Was im Container selbst liegt, ist beim nächsten Neustart des Pods ohnehin weg.

Die Vorlage leocloud get template nginx ist davon nicht betroffen.

Was Sie sehen, wenn ein Pod zu viel schreibt

Der Pod wird beendet — nur dieser Pod, andere laufen weiter. kubectl get pods zeigt ihn als Evicted oder Error. Den Grund sehen Sie mit

kubectl describe pod MYPOD

unter Message; er nennt die überschrittene Grenze. Gehört der Pod zu einem Deployment, wird ein neuer gestartet — schreibt er wieder zu viel, wird auch er beendet. Ersetzen Sie MYPOD durch den Namen des Pods.

Was Sie sehen, wenn die 40Gi des Namespaces erreicht sind

  • Ein Pod, den Sie direkt anlegen, wird sofort abgelehnt. Die Meldung nennt die Grenze des Namespaces und wie viel davon schon verbraucht ist.

  • Ein Deployment wird angenommen, aber seine neuen Pods werden nicht angelegt. Den Grund sehen Sie mit

    kubectl get events

    als FailedCreate. Löschen Sie Deployments, die Sie nicht mehr brauchen, oder geben Sie Ihren Containern kleinere Grenzen.

Diese Grenzen können Sie in Ihrem Namespace nicht ändern oder abschalten.

Ein Pod, der bereits lief, bevor diese Grenzen in Ihrem Namespace galten, läuft ohne Grenze weiter. Muss er neu angelegt werden — bei einer neuen Version Ihres Deployments oder wenn ein Rechner neu startet —, bekommt der neue Pod die Grenzen.

Services und Speicher (PersistentVolumeClaim)

Ein Service ist immer vom Typ ClusterIP. Lassen Sie den Typ einfach weg, dann ist es dieser. Die Typen NodePort, LoadBalancer und ExternalName werden abgelehnt. Von außen erreichbar ist Ihre Anwendung nur über einen Ingress auf Ihrem eigenen Hostnamen — so wie in der Vorlage leocloud get template nginx.

Ein PersistentVolumeClaim verlangt höchstens 20Gi. Ein Claim, der mehr verlangt, wird abgelehnt. Einen bestehenden Claim können Sie nicht über 20Gi hinaus vergrößern.

Was Sie sehen, wenn etwas abgelehnt wird

  • Ein Service eines anderen Typs wird bei kubectl apply sofort abgelehnt:

    LeoCloud: a service of type NodePort is not allowed in this namespace. Only type ClusterIP is allowed (leave the type out). An application is reached from outside through an ingress on your hostname.

    Entfernen Sie die Zeile type: aus dem Service oder schreiben Sie type: ClusterIP.

  • Ein zu großer Claim wird bei kubectl apply sofort abgelehnt:

    LeoCloud: this volume claim requests 25Gi of storage. A claim in this namespace may request at most 20Gi, and an existing claim cannot be enlarged beyond 20Gi.

    Schreiben Sie bei storage: höchstens 20Gi.

  • Ein StatefulSet mit volumeClaimTemplates wird angenommen, aber ein zu großer Claim wird nicht angelegt, und der Pod startet nicht. Den Grund sehen Sie mit

    kubectl get events

    als FailedCreate mit derselben Meldung.

Diese Regeln können Sie in Ihrem Namespace nicht ändern oder abschalten.

Ingress: welche Einstellungen wirken

Den Ingress Ihrer Anwendung liest der Ingress-Controller Traefik. So wie in der Vorlage leocloud get template nginx gilt:

Die Ingress-Klasse steht im Feld ingressClassName, nicht in einer Annotation:

spec:
  ingressClassName: nginx

Steht in Ihrem Ingress noch die ältere Annotation kubernetes.io/ingress.class: nginx (aus einem älteren Tutorial), dann löschen Sie diese Zeile und schreiben stattdessen das Feld.

Es wirken nur die Annotationen nginx.ingress.kubernetes.io/…​, die Traefik als unterstützt auflistet. Die Liste: doc.traefik.io/traefik/reference/routing-configuration/kubernetes/ingress-nginx/

Keine Wirkung haben:

  • Annotationen anderer Ingress-Controller, zum Beispiel traefik.ingress.kubernetes.io/…​ oder nginx.org/…​,

  • eine Annotation nginx.ingress.kubernetes.io/…​, die in dieser Liste nicht als unterstützt steht (dort unter „Unsupported Annotations“).

Eine solche Annotation wird nicht beachtet. Entfernen Sie sie, damit Ihr Ingress zeigt, was tatsächlich gilt.

Der Pfad einer Anfrage kommt so bei Ihrem Service an, wie er gesendet wurde: //, /./ und /../ werden weder zusammengefasst noch aufgelöst.

Dashboard

Das Dashboard ist eine Web-Oberfläche für Ihren Namespace. Sie erreichen es im Browser unter dashboard.cloud.htl-leonding.ac.at. Sie müssen dafür nichts in Ihrem Namespace starten.

  1. Geben Sie im Terminal ein:

    leocloud dashboard

    Der Befehl gibt einen Token aus, der eine Stunde gilt, und öffnet die Adresse im Browser. Öffnet sich kein Browser (zum Beispiel unter WSL), öffnen Sie die Adresse selbst.

  2. Kopieren Sie den Token in das Anmeldefeld der Seite und melden Sie sich an.

Die Anmeldung gilt eine Stunde. Danach führen Sie leocloud dashboard noch einmal aus und melden sich mit dem neuen Token an. Auf einem Computer, den auch andere benutzen, melden Sie sich am Ende ab.

Im Dashboard sehen und ändern Sie dasselbe wie mit kubectl: die Objekte in Ihrem eigenen Namespace. Die Liste der Namespaces zeigt alle Namespaces der LeoCloud, aber Inhalte sehen Sie nur in Ihrem eigenen. Die Übersicht über den ganzen Cluster zeigt zwei Meldungen „Forbidden" (für Ereignisse und für Messwerte der Knoten). Alles in Ihrem eigenen Namespace funktioniert trotzdem.

Wie viel CPU und Arbeitsspeicher Ihre Pods gerade verbrauchen, sehen Sie im Dashboard bei den Pods und im Terminal mit kubectl top pod. Den Verbrauch der Knoten (kubectl top node) sehen Sie nicht.

Gibt leocloud dashboard stattdessen eine Anleitung mit sechs Schritten aus, ist Ihr leocloud veraltet; die Vorlage, mit der diese Anleitung beginnt, gibt es nicht mehr. Installieren Sie leocloud neu, mit demselben Befehl wie in Leocloud für Linux und OSX.

Happy Leoclouding!

Container Registry (ghcr.io)

Ihr Image laden Sie in die Container Registry von GitHub, ghcr.io. Ein Image heißt dort ghcr.io/<github-user>/<image>, ganz in Kleinbuchstaben, auch wenn Ihr GitHub-Name Großbuchstaben enthält. Ersetzen Sie <github-user> in allen Befehlen dieses Abschnitts durch Ihren GitHub-Namen.

Token anlegen

Die Registry akzeptiert nur einen Personal access token (classic). Ein fine-grained Token funktioniert für die Registry nicht, auch wenn GitHub ihn zuerst anbietet.

  1. Öffnen Sie dieses Formular für einen neuen classic Token. Die Berechtigung write:packages (Images hochladen und herunterladen) ist darin schon ausgewählt.

  2. Wählen Sie bei Expiration den Eintrag Custom und ein Datum am Ende des Schuljahres (Anfang Juli). Die Voreinstellung von 30 Tagen läuft mitten im Projekt ab.

  3. Klicken Sie unten auf Generate token.

  4. GitHub zeigt den Token nur ein einziges Mal. Kopieren Sie ihn sofort, bevor Sie die Seite verlassen, und bewahren Sie ihn sicher auf, zum Beispiel in einem Passwortmanager. Er beginnt mit ghp_.

Geben Sie den Token niemandem weiter, auch keinem Agenten, und schreiben Sie ihn in keine Datei Ihres Repositorys.

Anmelden

docker login ghcr.io -u <github-user>

Bei Password: fügen Sie den Token ein und drücken Enter. Beim Einfügen wird nichts angezeigt; das ist normal. Unter Linux und in WSL warnt Docker eventuell, dass das Passwort unverschlüsselt gespeichert wird; die Anmeldung hat trotzdem funktioniert. Erscheint statt Login Succeeded die Meldung unauthorized oder denied, ist der Token falsch, abgelaufen oder ohne write:packages: Legen Sie einen neuen an und melden Sie sich erneut an.

Das Paket finden

Nach dem ersten Hochladen (docker push) erscheint das Image als Paket in Ihrem GitHub-Profil, unter github.com/<github-user>?tab=packages. Ein neues Paket ist privat. Der Cluster kann es dann ohne Zugangsdaten nicht laden, und der Pod zeigt ImagePullBackOff oder ErrImagePull.

Das Paket öffentlich machen

Wir empfehlen, das Paket öffentlich zu machen. Dann braucht niemand Zugangsdaten, um es zu laden, und im Cluster muss kein Geheimnis liegen.

Warning
 Ein öffentliches Paket lässt sich nicht wieder privat machen. Alles im Image — Ihr Code und jede Datei, die hineinkopiert wurde — kann dann jeder herunterladen und lesen. Prüfen Sie vorher: Eine Datei .dockerignore hält mindestens .env, .git und private Schlüssel aus dem Image heraus, und das Dockerfile enthält kein Passwort und keinen Token. Auch alle früher hochgeladenen Versionen werden öffentlich; enthält eine davon ein Geheimnis, löschen Sie zuerst das ganze Paket und laden es neu hoch.

Öffnen Sie die Einstellungen des Pakets: auf der Seite des Pakets rechts Package settings, oder direkt github.com/users/<github-user>/packages/container/<image>/settings. Ganz unten unter Danger Zone: Change visibility → Public → Namen des Pakets eintippen → bestätigen.

Ob das Paket wirklich öffentlich ist, prüfen Sie ohne Zugangsdaten (das leere Verzeichnis sorgt dafür, dass Ihre gespeicherte Anmeldung nicht benutzt wird):

DOCKER_CONFIG="$(mktemp -d)" docker manifest inspect ghcr.io/<github-user>/<image>:<tag>

Gibt der Befehl ein Manifest (JSON) aus, ist das Paket öffentlich. unauthorized heißt: noch privat. denied heißt: Ein Image dieses Namens mit diesem Tag gibt es nicht.

Muss Ihr Paket privat bleiben, braucht der Cluster ein Pull Secret mit einem Token, der Pakete lesen darf (read:packages). Legen Sie es direkt mit kubectl create secret docker-registry an, nie aus einer Datei Ihres Repositorys.

Problembehandlung

Sollten Sie Probleme mit Ihrer Anwendung haben, denken Sie daran: es gibt nur zwei schwierige Dinge beim Entwickeln von Software. Löschen Sie Ihren Namespace mit kubectl delete namespace MYNAMESPACE wobei sie MYNAMESPACE durch den Namen Ihres Namespaces ersetzen. Den Namespace finden Sie mit kubectl config view oder wie oben beschrieben mit leocloud get home.

Achtung: damit löschen Sie auch alle Daten in Ihren persistenten Volumes — sofort und unwiderruflich. Das Löschen des Namespaces ist kein Neustart, sondern entfernt den gesamten Inhalt. Es gibt keine Frist, innerhalb derer sich etwas zurückholen ließe. Holen Sie vorher heraus, was Sie behalten wollen — siehe Lebensdauer Ihres Bereichs. Danach neu einloggen; Sie bekommen einen leeren Bereich. Melden Sie sich gleich nach dem Löschen an, kann die Anmeldung abgelehnt werden, weil der alte Namespace noch entfernt wird; führen Sie den Befehl dann in ein paar Sekunden noch einmal aus.

Lebensdauer Ihres Bereichs

Ihr Namespace bleibt nicht dauerhaft bestehen. Er wird entfernt, wenn Ihr Jahrgang die fünfjährige Ausbildung abgeschlossen hat: Wer im Jahr Y eingetreten ist, verliert seinen Bereich beim Aufräumen nach dem Jahr Y + 5. Solange Sie an der Schule sind, bleibt Ihr Bereich bestehen, auch über die Ferien.

Wer eine Klasse wiederholt, ist nach diesen fünf Jahren noch an der Schule. Deshalb wird ein Bereich mit seinem Jahrgang nur entfernt, wenn bei der letzten Anmeldung zwischen September und Juni des abgelaufenen Schuljahres die Abschlussklasse Ihres Ausbildungszweigs eingetragen wurde: die 5. Klasse, in der Abendschule das 6. Semester. Bei jeder Anmeldung wird Ihre aktuelle Klasse aus dem Schulkonto übernommen. Ist eine niedrigere Klasse eingetragen, oder haben Sie sich in diesem Schuljahr nicht angemeldet, wird Ihr Bereich nicht mit Ihrem Jahrgang entfernt, und die Administration entscheidet einzeln.

Wenn Sie eine Klasse wiederholen

  • Melden Sie sich in jedem Schuljahr zwischen September und Juni mindestens einmal bei LeoCloud an. Dann ist die eingetragene Klasse die richtige.

  • Wenn Sie die Abschlussklasse wiederholen, kann LeoCloud Sie nicht von jemandem unterscheiden, der die Schule abgeschlossen hat. Sie erhalten dann die Verständigung vor dem Löschen. Antworten Sie vor dem darin genannten Tag auf diese Nachricht, dann bleibt Ihr Bereich bestehen.

Bereiche ohne Matrikelnummer — Lehrende, Seminarteilnehmerinnen und Seminarteilnehmer — sind von dieser Regel nicht erfasst und werden einzeln entschieden.

Für Prüfungszugänge gilt etwas anderes — siehe Prüfungszugänge.

Vor dem Löschen

  • Sie werden vorher per E-Mail verständigt, mindestens 7 Tage davor. Die Nachricht nennt den Tag, an dem gelöscht wird.

  • Verständigt wird an die Adresse, die bei Ihrer Anmeldung aus dem Schulkonto übernommen wurde. Es wird keine Adresse aus dem Namen Ihres Namespaces gebildet.

  • Früher als angekündigt wird nicht gelöscht. Später kann es werden.

Was gelöscht wird

  • der gesamte Namespace: alle Deployments, Services und Ingresses,

  • alle Daten in den persistenten Volumes,

  • Ihr Zugang. Eine noch vorhandene ~/.kube/config funktioniert danach nicht mehr.

Beim Löschen sind die Daten sofort weg

Die Daten in den persistenten Volumes werden in dem Moment vernichtet, in dem der Bereich gelöscht wird. Es gibt keine Aufbewahrungsfrist — weder 30 Tage noch eine kürzere. Danach liegt am Fileserver nichts mehr, was noch herausgegeben werden könnte, und niemand kann die Daten zurückholen, auch die Administration nicht.

Dasselbe gilt, wenn Sie selbst löschen: kubectl delete pvc und kubectl delete namespace vernichten die Daten sofort und endgültig.

Sichern Sie deshalb selbst, was Sie behalten wollen, solange Ihr Bereich noch besteht. Der folgende Befehl ist die einzige Rettung, die es gibt. Aus einem laufenden Pod geht das zum Beispiel so:

kubectl cp MYNAMESPACE/MYPOD:/pfad/im/pod ./ziel-am-eigenen-rechner

Ersetzen Sie dabei MYNAMESPACE durch den Namen Ihres Namespaces, MYPOD durch den Namen des Pods und die beiden Pfade durch den Ordner im Pod und durch das Ziel auf Ihrem eigenen Rechner.

Prüfungszugänge

Für praktische Prüfungen gibt die Schule eigene Zugänge aus. Ihr Benutzername beginnt mit test, danach folgen zwei Buchstaben für den Prüfungssatz und die Katalognummer — zum Beispiel testee01. Für diese Zugänge gilt die Regel im vorigen Abschnitt nicht.

Ein Prüfungsbereich wird 24 Stunden nach seiner Erstellung gelöscht. Der Zeitpunkt wird beim Anlegen am Namespace vermerkt und kann abgelesen werden:

kubectl get namespace MYNAMESPACE -o jsonpath='{.metadata.annotations.cloud\.htl-leonding\.ac\.at/delete-after}'

Ersetzen Sie dabei MYNAMESPACE durch den Namen Ihres Namespaces.

Während der Prüfung

Wer sich ein zweites Mal anmeldet — weil die Konfigurationsdatei verloren gegangen ist oder ein anderer Rechner verwendet wird — bekommt denselben Bereich zurück, mit allem, was darin schon läuft. Es wird dabei nichts gelöscht und nichts neu angelegt. Die 24 Stunden verlängern sich dadurch aber auch nicht: sie laufen ab dem ersten Anlegen.

Kommt die Anmeldung genau in dem Moment, in dem der Bereich gerade entfernt wird, wird sie abgelehnt mit der Aufforderung, den Befehl in ein paar Sekunden noch einmal auszuführen. Der nächste Versuch legt dann einen neuen, leeren Bereich an.

Was für Prüfungsbereiche anders ist

  • Es wird nicht vorher verständigt. Ein Prüfungszugang hat keine E-Mail-Adresse, und es wird auch keine gebildet.

Holen Sie also heraus, was Sie behalten wollen, bevor die 24 Stunden um sind.

Download as Pdf

Diese Dokument steht auch als user-manual.pdf zur Verfügung.