🥇Lokale Dateien beim Umzug der Anwendung nach Kubernetes

Bei der Erstellung des CI/CD-Prozesses mit Kubernetes gibt es manchmal Probleme mit der Inkompatibilität der Anforderungen an die neue Infrastruktur und der zu übertragenden Anwendung. Insbesondere ist es in der Phase des Anwendungsbaus wichtig, eine Abbildung zu erhalten, die in allen Umgebungen und Clustern des Projekts verwendet wird. Dieses Prinzip bildet die Grundlage für ein gutes Container-Management, nach Ansicht von Google was schon mehrmals erwähnt wurde und auch unser technischer Direktor dazu sagte. allerdings sieht man oft Situationen, in denen ein bereitgestelltes Framework im Code der Website verwendet wird, dessen Nutzung Einschränkungen für die weitere Nutzung mit sich bringt. Und während dies in einer 'normalen Umgebung' leicht zu bewältigen ist, kann ein solches Verhalten in Kubernetes problematisch werden, insbesondere wenn man damit zum ersten Mal konfrontiert wird. Obwohl ein kreativer Geist in der Lage ist, infrastrukturelle Lösungen anzubieten, die auf den ersten Blick offensichtlich und sogar gut erscheinen… ist es wichtig zu bedenken, dass die meisten Situationen architektonisch angegangen werden können und sollten. Schauen wir uns beliebte Workaround-Lösungen zur Dateispeicherung an, die bei der Nutzung eines Clusters zu unangenehmen Konsequenzen führen können, und zeigen wir auch den richtigen Weg auf.

Speicherung von Statischen Inhalten Zur Veranschaulichung betrachten wir eine Webanwendung, die einen Statik-Generator verwendet, um eine Reihe von Bildern, Stilen und anderem zu erstellen. Zum Beispiel verfügt das PHP-Framework Yii über einen integrierten Asset-Manager, der eindeutige Verzeichnisnamen generiert. Daher entsteht als Ergebnis eine Sammlung von eindeutig nicht überschneidenden Pfaden für die Statik der Website (dies wurde aus mehreren Gründen getan — zum Beispiel zur Vermeidung von Duplikaten bei der Verwendung derselben Ressource durch mehrere Komponenten). So geschieht es standardmäßig, dass beim ersten Zugriff auf das Modul der Webressource die Statik generiert und verteilt wird (in Wirklichkeit sind dies häufig symbolische Links, aber dazu später mehr) mit einem für dieses Deployment eindeutigen gemeinsamen Stammverzeichnis:.

webroot/assets/2072c2df/css/…

webroot/assets/2072c2df/images/…

webroot/assets/2072c2df/js/…

Welche Folgen hat dies im Kontext eines Clusters?
Ein einfaches Beispiel
Nehmen wir den recht gängigen Fall, dass vor PHP nginx steht, um Statische Inhalte auszuliefern und einfache Anfragen zu bearbeiten. Der einfachste Weg ist —

Deployment

mit zwei Containern:

Nehmen wir einen recht verbreiteten Anwendungsfall, bei dem nginx vor PHP steht, um statische Dateien bereitzustellen und einfache Anfragen zu verarbeiten. Der einfachste Weg ist — Deployment mit zwei Containern:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: site
spec:
  selector:
    matchLabels:
      component: backend
  template:
    metadata:
      labels:
        component: backend
    spec:
      volumes:
        - name: nginx-config
          configMap:
            name: nginx-configmap
      containers:
      - name: php
        image: own-image-with-php-backend:v1.0
        command: ["/usr/local/sbin/php-fpm","-F"]
        workingDir: /var/www
      - name: nginx
        image: nginx:1.16.0
        command: ["/usr/sbin/nginx", "-g", "daemon off;"]
        volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx/conf.d/default.conf
          subPath: nginx.conf

In vereinfachter Form besteht die nginx-Konfiguration aus Folgendem:

apiVersion: v1
kind: ConfigMap
metadata:
  name: "nginx-configmap"
data:
  nginx.conf: |
    server {
        listen 80;
        server_name _;
        charset utf-8;
        root  /var/www;

        access_log /dev/stdout;
        error_log /dev/stderr;

        location / {
            index index.php;
            try_files $uri $uri/ /index.php?$args;
        }

        location ~ .php$ {
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_index index.php;
            include fastcgi_params;
        }
    }

Beim ersten Zugriff auf die Website erscheinen im PHP-Container die Assets. Bei zwei Containern innerhalb eines Pods weiß nginx jedoch nichts über diese statischen Dateien, die gemäß der Konfiguration genau an ihn geliefert werden sollten. Infolgedessen sieht der Client auf alle Anfragen zu CSS- und JS-Dateien einen 404-Fehler. Das einfachste Lösung hier besteht darin, ein gemeinsames Verzeichnis für die Container einzurichten. Eine primitive Variante wäre ein gemeinsamer emptyDir:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: site
spec:
  selector:
    matchLabels:
      component: backend
  template:
    metadata:
      labels:
        component: backend
    spec:
      volumes:
        - name: assets
          emptyDir: {}
        - name: nginx-config
          configMap:
            name: nginx-configmap
      containers:
      - name: php
        image: own-image-with-php-backend:v1.0
        command: ["/usr/local/sbin/php-fpm","-F"]
        workingDir: /var/www
        volumeMounts:
        - name: assets
          mountPath: /var/www/assets
      - name: nginx
        image: nginx:1.16.0
        command: ["/usr/sbin/nginx", "-g", "daemon off;"]
        volumeMounts:
        - name: assets
          mountPath: /var/www/assets
        - name: nginx-config
          mountPath: /etc/nginx/conf.d/default.conf
          subPath: nginx.conf

Jetzt werden die im Container generierten statischen Dateien korrekt von nginx bereitgestellt. Aber ich möchte daran erinnern, dass dies eine primitive Lösung ist, was bedeutet, dass sie weit vom Ideal entfernt ist und ihre eigenen Nuancen und Unzulänglichkeiten hat, über die ich später berichten werde.

Ein fortschrittlicherer Speicher

Stellen wir uns nun die Situation vor, in der der Benutzer die Website aufgerufen hat, die Seite mit den im Container vorhandenen Stilen geladen hat, und während er diese Seite liest, haben wir den Container erneut bereitgestellt. Im Asset-Verzeichnis ist es leer geworden und eine Anfrage an PHP ist erforderlich, um die Generierung neuer Assets zu starten. Selbst nach diesem Vorgang werden die Links zur alten Statik nicht mehr aktuell sein, was zu Anzeigeproblemen der Statik führen wird.

Außerdem haben wir höchstwahrscheinlich ein mehr oder weniger stark ausgelastetes Projekt, was bedeutet, dass eine Kopie der Anwendung nicht ausreichen wird:

Wir skalieren Deployment auf zwei Replikate.
Bei der ersten Anfrage an die Website wurden in einer Replikate Assets erstellt.
Irgendwann beschloss der Ingress (zum Zwecke der Lastverteilung), eine Anfrage an die zweite Replikate zu senden, und dort sind diese Assets noch nicht vorhanden. Vielleicht sind sie dort auch nicht mehr vorhanden, weil wir RollingUpdate verwendet werden und derzeit die Bereitstellung durchführen.

Insgesamt das Ergebnis — wieder Fehler.

Um alte Assets nicht zu verlieren, kann man ändern emptyDir auf hostPath, indem man die Statik physisch auf dem Knoten des Clusters speichert. Dieser Ansatz hat den Nachteil, dass wir praktisch uns an einen bestimmten Knoten des Clusters mit unserer Anwendung binden müssen, denn im Falle eines Umzugs zu anderen Knoten wird das Verzeichnis die erforderlichen Dateien nicht enthalten. Alternativ ist eine Art Hintergrundsynchronisierung des Verzeichnisses zwischen den Knoten erforderlich.

Welche Lösungen gibt es?

Wenn die Hardware und die Ressourcen es zulassen, kann man cephfs verwenden, um ein verteiltes Verzeichnis für die Belange der Statik einzurichten. Die offizielle Dokumentation empfiehlt SSD-Laufwerke, mindestens dreifache Replikation und eine stabile "fette" Verbindung zwischen den Knoten des Clusters.
Eine weniger anspruchsvolle Option wäre die Einrichtung eines NFS-Servers. Allerdings sollte man dabei das mögliche Ansteigen der Reaktionszeit bei der Verarbeitung von Anfragen durch den Webserver berücksichtigen, und auch die Fehlertoleranz lässt zu wünschen übrig. Die Konsequenzen eines Ausfalls sind katastrophal: Der Verlust des Mounts verurteilt den Cluster zum Untergang unter dem Druck der Last, die in die Höhe strebt.

Neben allem anderen benötigen alle Optionen zur Einrichtung eines permanenten Speichers eine Hintergrundreinigung veralteter Dateisätze, die über einen bestimmten Zeitraum angesammelt wurden. Vor den PHP-Containern kann man ein DaemonSet aus zwischen speichernden Nginx einrichten, die Kopien von Assets für eine begrenzte Zeit speichern werden. Dieses Verhalten lässt sich leicht über konfigurieren. Proxy-Cache mit einer Speicherdauer in Tagen oder Gigabyte Festplattenspeicher.

Die Kombination dieser Methode mit den oben genannten verteilten Dateisystemen eröffnet enormes Potenzial, wobei das einzige Limit das Budget und das technische Know-how derjenigen ist, die dies umsetzen und unterstützen werden. Aus Erfahrung können wir sagen, dass je einfacher das System, desto stabiler funktioniert es. Bei der Hinzufügung solcher Schichten wird die Wartung der Infrastruktur erheblich komplizierter, was auch die Zeit erhöht, die für Diagnosen und Wiederherstellungen bei Ausfällen benötigt wird.

Empfehlung

Wenn die Implementierung der vorgeschlagenen Speicheroptionen Ihnen auch als unangemessen (komplex, teuer...) erscheint, sollten Sie die Situation aus einer anderen Perspektive betrachten. Nämlich — die Architektur des Projekts zu durchdringen und das Problem im Code zu beseitigen, indem Sie sich an eine bestimmte statische Datenstruktur im Image anhängen, das eindeutige Bestimmen des Inhalts oder das Verfahren "Aufwärmen" und\/oder die Vorkompilierung von Assets während der Build-Phase des Images. So erhalten wir ein absolut vorhersehbares Verhalten und denselben Satz von Dateien für alle Umgebungen und Replikate der laufenden Anwendung.

Wenn wir zum konkreten Beispiel mit dem Yii-Framework zurückkehren und nicht tief in seine Struktur eintauchen (was nicht Ziel des Artikels ist), reicht es aus, auf zwei beliebte Ansätze hinzuweisen:

Den Build-Prozess des Images so zu ändern, dass Assets an einem vorhersehbaren Ort platziert werden. So schlagen Erweiterungen wie yii2-static-assets.
vor, spezifische Hashes für die Asset-Verzeichnisse zu definieren, wie beispielsweise in dieser Präsentation (beginnend mit Folie Nr. 35). Übrigens empfiehlt der Referent am Ende (und nicht ohne Grund!), nach dem Build der Assets auf dem Build-Server diese in ein zentrales Repository (wie S3) hochzuladen, vor dem ein CDN platziert wird.

Hochgeladene Dateien

Ein weiterer Anwendungsfall, der beim Umzug einer Anwendung in ein Kubernetes-Cluster unbedingt erfolgreich sein wird, ist die Speicherung von Benutzerdaten in einem Dateisystem. Zum Beispiel haben wir wieder eine PHP-Anwendung, die Dateien über ein Upload-Formular annimmt, etwas damit während der Verarbeitung macht und sie zurückgibt.

Der Ort, an dem diese Dateien abgelegt werden sollten, muss in der Kubernetes-Realität für alle Replikate der Anwendung gemeinsam sein. Je nach Komplexität der Anwendung und dem Bedarf an der Organisation der Persistenz dieser Dateien kann dieser Ort die oben erwähnten Varianten von Shared-Geräten sein, aber wie wir sehen, haben diese ihre eigenen Nachteile.

Empfehlung

Eine der Möglichkeiten zur Lösung ist die Verwendung eines S3-kompatiblen Speichers (selbst wenn es eine Art von Self-hosted Variante wie minio ist). Der Übergang zur Arbeit mit S3 erfordert Änderungen auf Code-Ebene, und wie der Inhalt im Frontend ausgeliefert wird, haben wir bereits geschrieben.

Benutzersitzungen

Es ist erwähnenswert, wie die Speicherung von Benutzersitzungen organisiert wird. Oftmals handelt es sich dabei auch um Dateien auf der Festplatte, was im Kontext von Kubernetes zu ständigen Autorisierungsanforderungen an den Benutzer führen kann, wenn seine Anfrage in einen anderen Container gelangt.

Teilweise wird das Problem durch die Aktivierung von stickySessions auf dem Ingress (dieses Feature wird in allen gängigen Ingress-Controllern unterstützt – weitere Informationen finden Sie in unserer Übersicht), um den Benutzer an ein bestimmtes Pod der Anwendung zu binden:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: nginx-test
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "route"
    nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"

spec:
  rules:
  - host: stickyingress.example.com
    http:
      paths:
      - backend:
          serviceName: http-svc
          servicePort: 80
        path: /

Aber das wird die Probleme bei wiederholten Deployments nicht lösen.

Empfehlung

Eine geeignetere Vorgehensweise wäre es, die Anwendung auf die Speicherung von Sitzungen in memcached, Redis und ähnlichen Lösungen umzustellen – insgesamt also vollständig auf dateibasierten Varianten zu verzichten.

Fazit

Die im Text betrachteten Infrastrukturmaßnahmen sind nur als temporäre "Notlösungen" (was auf Englisch schöner als "workaround" klingt) geeignet. Sie können zu Beginn der Migration der Anwendung nach Kubernetes relevant sein, sollten jedoch nicht "Wurzeln schlagen".

Der allgemeine empfohlene Weg führt dazu, sich von ihnen zugunsten einer architektonischen Überarbeitung der Anwendung zu verabschieden, die bereits vielen gut bekannt ist. 12-Factor App. Dies bedeutet jedoch, dass die Anwendung in einen Stateless-Zustand überführt werden muss, was zwangsläufig Änderungen im Code erfordert. Hier ist es wichtig, ein Gleichgewicht zwischen den Möglichkeiten/Anforderungen des Unternehmens und den Perspektiven der Umsetzung und Wartung des gewählten Weges zu finden.