Die dominierende Plattform für die Bereitstellung von Containern ist zweifellos Kubernetes. Es ermöglicht die Verwaltung nahezu aller Aspekte mithilfe seiner APIs und benutzerdefinierten Controller, die die API um benutzerdefinierte Ressourcen erweitern.
Dennoch muss der Nutzer detaillierte Entscheidungen darüber treffen, wie genau Anwendungen bereitgestellt, konfiguriert, verwaltet und skaliert werden. Fragen zum Skalieren von Anwendungen, zur Sicherheit und zum Datenverkehr verbleiben im Ermessen des Nutzers. Diese Aspekte unterscheiden Kubernetes von herkömmlichen „Plattformen als Dienst“ (PaaS) wie beispielsweise Cloud Foundry und Heroku.
Die Plattformen bieten eine vereinfachte Benutzeroberfläche und richten sich an Anwendungsentwickler, die häufig mit der Konfiguration einzelner Anwendungen beschäftigt sind. Das Routing, die Bereitstellung und die Metriken werden nahtlos von der zugrunde liegenden PaaS verwaltet.
Der Workflow „Quellcode – Bereitstellung“ wird von PaaS verarbeitet, indem ein benutzerdefiniertes Container-Image erstellt, bereitgestellt und ein neuer Routing- und DNS-Subdomain für den eingehenden Datenverkehr konfiguriert wird. All dies wird auf Befehl gestartet. git push.
In Kubernetes werden absichtlich nur grundlegende Blöcke für solche Plattformen bereitgestellt, was der Community ermöglicht, diese Arbeit selbst zu erledigen. Wie :
Kubernetes ist eine Plattform zur Erstellung von Plattformen. Der beste Ausgangspunkt, aber nicht das Ziel.
In der Folge sehen wir eine Vielzahl von Kubernetes-Bundles sowie Hosting-Anbietern, die versuchen, PaaS für Kubernetes zu schaffen, wie zum Beispiel OpenShift und Rancher. Angesichts des wachsenden Marktes für Kube-PaaS betritt Knative die Bühne, das im Juli 2018 von Google und Pivotal ins Leben gerufen wurde.
Knative entstand aus einer Zusammenarbeit zwischen Google und Pivotal, mit geringer Unterstützung von anderen Unternehmen wie IBM, RedHat und Solo.im. Es bietet ähnliche PaaS-Funktionen für Kubernetes mit erstklassiger Unterstützung für Anwendungen auf Basis von Serverless Computing. Im Gegensatz zu Kubernetes-Bundles wird Knative als Erweiterung in jedem kompatiblen Kubernetes-Cluster installiert und über benutzerdefinierte Ressourcen konfiguriert.
Was ist Knative?
Knative wird als „Kubernetes-basierte Plattform zur Bereitstellung und Verwaltung von Workloads mit modernen serverlosen Berechnungen“ beschrieben. Knative skaliert Container automatisch proportional zu den gleichzeitigen HTTP-Anfragen und bietet somit bedarfsorientierte Skalierung im Stil serverloser Technologien. Nicht genutzte Dienste skalieren letztendlich auf null.
Knative besteht aus einer Reihe von Controllern, die in jeden Kubernetes-Cluster installiert werden können und die folgenden Funktionen bereitstellen:
- Erstellung containerisierter Anwendungen aus Quellcode (bereitgestellt durch die Komponente Build),
- Zugang für eingehenden Traffic zu Anwendungen (bereitgestellt durch die Komponente Serving),
- Bereitstellung und automatische Skalierung von Anwendungen auf Anfrage (ebenfalls bereitgestellt durch die Komponente Serving),
- Bestimmung von Ereignisquellen, die die Ausführung von Anwendungen anstoßen (bereitgestellt durch die Komponente Eventing).
Ein zentrales Element ist Serving, das Bereitstellung, automatisches Skalieren und die Verwaltung des Datenverkehrs für verwaltete Anwendungen ermöglicht. Nach der Installation von Knative bleibt der vollständige Zugang zur Kubernetes-API erhalten, was es den Benutzern ermöglicht, ihre Anwendungen auf flexible Weise zu verwalten. normalen Es dient auch zur Fehlerbehebung von Knative-Diensten und arbeitet mit denselben API-Primitiven, die diese Dienste verwenden (Module, Dienste usw.).
Mit Serving wird außerdem die Blue-Green-Traffic-Routing automatisiert, wodurch der Datenverkehr zwischen neuen und alten Versionen der Anwendung beim Bereitstellen einer aktualisierten Version durch den Benutzer aufgeteilt wird.
Knative selbst ist von der Installation eines kompatiblen Ingress-Controllers abhängig. Zum Zeitpunkt der Erstellung dieses Artikels werden unterstützt und . Dieser konfiguriert den verfügbaren Ingress zur Datenverkehrslenkung zu den von Knative verwalteten Anwendungen.
Das Istio Service Mesh kann eine erhebliche Abhängigkeit für Knative-Nutzer darstellen, die es ohne die Installation des Istio-Dashboards ausprobieren möchten, da Knative lediglich vom Gateway abhängig ist.
Aus diesem Grund bevorzugen die meisten Nutzer Gloo als Gateway für Knative, da es einen ähnlichen Funktionsumfang wie Istio bietet (wenn es nur um die Verwendung von Knative geht), dabei jedoch erheblich weniger Ressourcen benötigt und geringere Betriebskosten verursacht.
Lassen Sie uns Knative in Aktion auf einem Stand testen. Ich werde einen frisch installierten Cluster verwenden, der in GKE läuft:
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 den Status „Running“ haben:
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 zur Weiterleitung, lassen Sie uns einen automatisch skalierbaren Knative-Service erstellen (nennen wir ihn kservice) und den Datenverkehr darauf leiten.
Knative-Services bieten einen einfacheren Weg, Anwendungen in Kubernetes bereitzustellen – im Vergleich zum herkömmlichen Modell Deployment + Service + Ingress. Lassen Sie uns mit folgendem Beispiel arbeiten:
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-BenutzerIch habe dies in eine Datei kopiert und dann wie folgt auf meinen Kubernetes-Cluster angewendet:
kubectl apply -f ksvc.yaml -n defaultWir können die von Knative im Cluster nach der Bereitstellung unseres ‘helloworld-go’ erstellten Ressourcen 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 ‘helloworld-go’ Image wird beim Bereitstellen des kservice gestartet. Wenn es keinen Datenverkehr gibt, wird die Anzahl der Pods auf null reduziert. Umgekehrt, wenn die Anzahl der gleichzeitigen Anfragen einen konfigurierbaren Schwellenwert überschreitet, wird die Anzahl der Pods wachsen.
kubectl get ingresses.networking.internal.knative.dev -n default
NAME READY REASON
helloworld-go TrueKnative konfiguriert seinen Ingress mit einer speziellen ‘ingress’ Ressource im internen Knative API. Gloo nutzt dieses API als seine Konfiguration, um PaaS-typische Funktionen bereitzustellen, darunter das Blue-Green-Deployment-Modell, automatische TLS-Anwendung, Timeouts und weitere erweiterte Routing-Funktionen.
Nach einiger Zeit sehen wir, dass unsere Pods verschwunden sind (da kein eingehender Traffic vorhanden war):
kubectl get pod -n default
Keine Ressourcen gefunden.
kubectl get deployment -n default
NAME WUNSCHEN AKTUELL AUF DEM NEUESTEN STAND VERFÜGBAR ALTER
helloworld-go-fjp75-deployment 0 0 0 0 9m46sSchließlich versuchen wir, sie zu erreichen. Es ist einfach, die URL für den Knative Proxy zu erhalten mit glooctl:
glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80Ohne eine konfigurierte glooctl kann man die Adresse und den Port im Kube-Service einsehen:
kubectl get svc -n gloo-system knative-external-proxy
NAME TYP CLUSTER-IP EXTERN-IP PORT(S) ALTER
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 eine nahezu-PaaS-Lösung für Entwickler, die auf "Out-of-the-Box" Kubernetes basiert und einen leistungsstarken, voll funktionsfähigen API-Gateway, Gloo, nutzt. Diese Notiz hat nur einen kleinen Teil der umfangreichen Konfigurationsmöglichkeiten für Knative sowie zusätzliche Funktionen angesprochen. Das gleiche gilt für Gloo!
Obwohl Knative noch ein junges Projekt ist, veröffentlicht das Team alle sechs Wochen neue Versionen und startet die Implementierung fortschrittlicher Funktionen wie automatisierte TLS-Bereitstellung und automatisches Scaling des Dashboards. Aufgrund der Zusammenarbeit zahlreicher Cloud-Anbieter sowie der Rolle von Knative als Grundlage für Googles neues Angebot Cloud Run besteht eine hohe Wahrscheinlichkeit, dass es die bevorzugte Lösung für serverlose Berechnungen und PaaS in Kubernetes wird. Bleiben Sie dran!
Von der Redaktion SouthBridge
Ihre Meinung ist uns wichtig, daher 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. Sind Sie an Contour interessiert?
Sollten wir weiterhin Artikel und Anleitungen zu Knative und serverlosen Berechnungen veröffentlichen?
Ja, bitte.
Danke, nicht nötig.
28 Nutzer haben abgestimmt. 4 Nutzer haben sich enthalten.
Quelle: habr.com
