Die dominierende Plattform für die Bereitstellung von Containern ist zweifellos Kubernetes. Es bietet die Möglichkeit, nahezu alles zu verwalten, indem es eigene APIs und benutzerdefinierte Controller nutzt, die seine API durch benutzerdefinierte Ressourcen erweitern.
Dennoch muss der Benutzer weiterhin detaillierte Entscheidungen darüber treffen, wie Anwendungen bereitgestellt, konfiguriert, verwaltet und skaliert werden. Fragen zur Anwendungs-Skalierung, Sicherheit und zum Datenverkehr verbleiben im Ermessen des Benutzers. Dies unterscheidet Kubernetes von herkömmlichen „Platform as a Service“ (PaaS) Lösungen, wie zum Beispiel Cloud Foundry und Heroku.
PaaS-Plattformen bieten eine vereinfachte Benutzeroberfläche, die sich an Anwendungsentwickler richtet, die in der Regel mit der Konfiguration einzelner Anwendungen beschäftigt sind. Routing, Bereitstellung und Metriken werden für den Benutzer transparent von der zugrunde liegenden PaaS-System verwaltet.
Der Workflow „Quellcode – Bereitstellung“ wird von PaaS verarbeitet, indem ein benutzerdefiniertes Container-Image erstellt, bereitgestellt, ein neuer Pfad und ein DNS-Subdomain für den eingehenden Datenverkehr konfiguriert werden. All dies wird auf Kommando gestartet. git push.
In Kubernetes werden (absichtlich) nur die grundlegenden Bausteine für solche Plattformen bereitgestellt, was der Community die Möglichkeit gibt, diese Arbeit selbst zu leisten. Wie :
Kubernetes ist eine Plattform zum Aufbau von Plattformen. Die beste Ausgangsposition, aber kein Ziel.
Infolgedessen sehen wir eine Vielzahl von Kubernetes-Bauten sowie Hosting-Dienste, die versuchen, PaaS für Kubernetes zu schaffen, wie OpenShift und Rancher. Vor dem Hintergrund des wachsenden Marktes für Kube-PaaS betritt Knative, entstanden im Juli 2018 von Google und Pivotal, die Bühne.
Knative entstand aus der gemeinsamen Arbeit von Google und Pivotal, mit wenig Unterstützung anderer Unternehmen wie IBM, RedHat und Solo.im. Es bietet ähnliche PaaS-Funktionen für Kubernetes mit erstklassiger Unterstützung für serverlose Anwendungen. Im Gegensatz zu Kubernetes-Bauten wird Knative als Ergänzung auf jedem kompatiblen Kubernetes-Cluster installiert und über benutzerdefinierte Ressourcen konfiguriert.
Was ist Knative?
Knative wird beschrieben als „eine Kubernetes-basierte Plattform zur Bereitstellung und Verwaltung von Workloads mit modernen serverlosen Berechnungen“. Knative skaliert Container aktiv automatisch im Verhältnis zu gleichzeitigen HTTP-Anfragen. Nicht genutzte Dienste skalieren letztendlich auf null und bieten eine bedarfsgerechte Skalierung im Stil von serverlosen Berechnungen.
Knative besteht aus einer Reihe von Controllern, die in jedem Kubernetes-Cluster installiert werden und folgende Funktionen bieten:
- Zusammenstellung von containerisierten Anwendungen aus Quellcode (bereitgestellt durch die Komponente Build),
- Bereitstellung des Zugangs eingehenden Traffics zu Anwendungen (bereitgestellt durch die Komponente Serving),
- Bereitstellung und automatisches Skalieren von Anwendungen auf Anfrage (ebenfalls bereitgestellt durch die Komponente Serving),
- Bestimmung von Ereignisquellen, die zum Starten von Anwendungen führen (bereitgestellt durch die Komponente Eventing).
Das zentrale Element ist Serving, das die Bereitstellung, automatisches Skalieren und das Management des Traffics für verwaltete Anwendungen bereitstellt. Nach der Installation von Knative bleibt der vollständige Zugang zur Kubernetes API bestehen, was es Benutzern ermöglicht, Anwendungen auf eine gewöhnliche Weise zu verwalten und dient zudem zur Fehlersuche bei Knative-Diensten, indem mit denselben API-Primitiven gearbeitet wird, die diese Dienste verwenden (Module, Dienste usw.).
Mit Serving wird auch das Blue-Green-Traffic-Routing automatisiert, was eine Trennung des Traffics zwischen neuen und alten Versionen der Anwendung bei der Bereitstellung einer aktualisierten Version durch den Benutzer gewährleistet.
Knative selbst ist auf die Installation eines kompatiblen Ingress-Controllers angewiesen. Zum Zeitpunkt der Erstellung dieses Artikels werden unterstützt: und . Er wird den verfügbaren Ingress einrichten, um den Traffic zu den von Knative verwalteten Anwendungen zu routen.
Das Istio Service Mesh kann eine große Abhängigkeit für Knative-Benutzer werden, die es ausprobieren möchten, ohne Istio's Control Panel zu installieren, da Knative nur auf den Gateway angewiesen ist.
Aus diesem Grund ziehen die meisten Benutzer Gloo als Gateway für Knative vor, das ein ähnliches Leistungsangebot wie Istio bereitstellt (wenn nur von der Verwendung von Knative gesprochen wird), während es deutlich weniger Ressourcen verbraucht und geringere Betriebskosten mit sich bringt.
Lassen Sie uns Knative in Aktion auf dem Stand überprüfen. Ich werde ein frisch installiertes Cluster verwenden, das in GKE ausgeführt wird:
kubectl get namespace
NAME STATUS AGE
default Active 21h
kube-public Active 21h
kube-system Active 21hLassen Sie uns mit der Installation von Knative und Gloo beginnen. Dies kann in beliebiger Reihenfolge erfolgen:
# ставим Knative-Serving
kubectl apply -f
https://github.com/knative/serving/releases/download/v0.8.0/serving-core.yaml
namespace/knative-serving created
# ...
# ставим Gloo
kubectl apply -f
https://github.com/solo-io/gloo/releases/download/v0.18.22/gloo-knative.yaml
namespace/gloo-system created
# ...Überprüfen wir, ob alle Pods im Status „Running“ sind:
kubectl get pod -n knative-serving
NAME READY STATUS RESTARTS AGE
activator-5dd55958cc-fkp7r 1/1 Running 0 7m32s
autoscaler-fd66459b7-7d5s2 1/1 Running 0 7m31s
autoscaler-hpa-85b5667df4-mdjch 1/1 Running 0 7m32s
controller-85c8bb7ffd-nj9cs 1/1 Running 0 7m29s
webhook-5bd79b5c8b-7czrm 1/1 Running 0 7m29s
kubectl get pod -n gloo-system
NAME READY STATUS RESTARTS AGE
discovery-69548c8475-fvh7q 1/1 Running 0 44s
gloo-5b6954d7c7-7rfk9 1/1 Running 0 45s
ingress-6c46cdf6f6-jwj7m 1/1 Running 0 44s
knative-external-proxy-7dd7665869-x9xkg 1/1 Running 0 44s
knative-internal-proxy-7775476875-9xvdg 1/1 Running 0 44sGloo ist bereit für das Routing, lassen Sie uns einen automatisch skalierbaren Knative-Dienst erstellen (den wir kservice nennen) und ihm Traffic zuführen.
Die Knative-Dienste bieten einen einfacheren Weg, Anwendungen in Kubernetes bereitzustellen – im Vergleich zum klassischen Modell Deployment+Service+Ingress. Wir arbeiten mit folgendem Beispiel:
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: helloworld-go
namespace: default
spec:
template:
spec:
containers:
- image: gcr.io/knative-samples/helloworld-go
env:
- name: TARGET
Value: Knative userIch habe dies in eine Datei kopiert und dann auf mein Kubernetes-Cluster wie folgt angewendet:
kubectl apply -f ksvc.yaml -n defaultWir können die von Knative im Cluster erstellten Ressourcen nach der Bereitstellung unseres 'helloworld-go' einsehen. kservice:
kubectl get pod -n default
NAME READY STATUS RESTARTS AGE
helloworld-go-fjp75-deployment-678b965ccb-sfpn8 2/2 Running 0 68sDer Pod mit unserem Bild 'helloworld-go' wird beim Bereitstellen des kservice gestartet. Wenn kein Traffic vorhanden ist, wird die Anzahl der Pods auf null reduziert. Umgekehrt, wenn die Anzahl der gleichzeitigen Anfragen einen einstellbaren Schwellenwert überschreitet, wächst die Anzahl der Pods.
kubectl get ingresses.networking.internal.knative.dev -n default
NAME READY REASON
helloworld-go TrueKnative konfiguriert seinen Ingress mithilfe einer speziellen 'Ingress'-Ressource in der internen Knative-API. Gloo verwendet diese API als seine Konfiguration, um PaaS-typische Eigenschaften bereitzustellen, einschließlich des Blue-Green-Bereitstellungsmodells, automatischer TLS-Anwendung, Zeitüberschreitungen und anderer erweiterter Routingfunktionen.
Nach einiger Zeit sehen wir, dass unsere Pods verschwunden sind (da es keinen eingehenden Datenverkehr gab):
kubectl get pod -n default
Keine Ressourcen gefunden.
kubectl get deployment -n default
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
helloworld-go-fjp75-deployment 0 0 0 0 9m46sSchließlich werden wir versuchen, sie zu erreichen. Die URL für den Knative Proxy lässt sich einfach und unkompliziert mit Hilfe von glooctl:
glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80Ohne installiertes glooctl kann die Adresse und den Port im Kube-Service nachgeschlagen werden:
kubectl get svc -n gloo-system knative-external-proxy
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
knative-external-proxy LoadBalancer 10.16.11.157 35.190.151.188 80:32168/TCP,443:30729/TCP 77mLassen Sie uns ein paar Daten mit cURL durchlaufen:
curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hallo Knative-Nutzer!Knative bietet fast PaaS für Entwickler über „Out-of-the-Box“-Kubernetes, indem es das leistungsstarke, voll funktionsfähige API-Gateway Gloo nutzt. Diese Notiz hat nur leicht die Vielzahl der Möglichkeiten von Knative angesprochen, die zur Konfiguration verfügbar sind, sowie zusätzliche Funktionen. Das Gleiche gilt für Gloo!
Obwohl Knative noch ein junges Projekt ist, veröffentlicht das Team alle sechs Wochen neue Versionen, und es wurden fortschrittliche Funktionen wie automatische TLS-Bereitstellung und automatisches Scaling eingeführt. Es besteht eine hohe Wahrscheinlichkeit, dass Knative in Zusammenarbeit mit zahlreichen Cloud-Unternehmen und als Grundlage für das neue Angebot Cloud Run von Google zu einer Hauptwahl für serverlose Berechnungen und PaaS in Kubernetes wird. Bleiben Sie dran!
Von der Redaktion SouthBridge
Die Meinung unserer Leser ist uns wichtig, deshalb bitten wir Sie, an einer kurzen Umfrage zu zukünftigen Artikeln über Knative, Kubernetes und serverlose Berechnungen teilzunehmen:
Nur registrierte Benutzer können an der Umfrage teilnehmen. .
Sollten wir weiterhin Artikel und Leitfäden über Knative und serverlose Berechnungen schreiben?
Ja, bitte.
Danke, nein.
28 Benutzer haben abgestimmt. 4 Benutzer haben sich enthalten.
Quelle: habr.com
