Kubernetes ist zweifellos zur dominierenden Plattform für die Containerbereitstellung geworden. Es bietet die Möglichkeit, fast alles mithilfe seiner APIs und benutzerdefinierten Controller zu steuern, die seine APIs um benutzerdefinierte Ressourcen erweitern.
Allerdings muss der Benutzer immer noch detaillierte Entscheidungen darüber treffen, wie Anwendungen genau bereitgestellt, konfiguriert, verwaltet und skaliert werden. Fragen der Anwendungsskalierung, des Schutzes und des Datenverkehrsflusses bleiben im Ermessen des Benutzers. Dies unterscheidet Kubernetes von herkömmlichen Plattformen als Service (PaaS) wie Cloud Foundry und Heroku.
Die Plattformen verfügen über eine vereinfachte Benutzeroberfläche und richten sich an Anwendungsentwickler, die am häufigsten mit der Einrichtung einzelner Anwendungen befasst sind. Routing, Bereitstellung und Metriken werden für den Benutzer transparent vom zugrunde liegenden PaaS-System verwaltet.
Der Workflow von der Quelle bis zum Versand wird von PaaS abgewickelt, indem ein benutzerdefiniertes Container-Image erstellt, bereitgestellt und eine neue Route und DNS-Subdomäne für eingehenden Datenverkehr eingerichtet wird. All dies wird auf Befehl gestartet git push.
Kubernetes stellt (absichtlich) nur die Kernbausteine für solche Plattformen bereit und lässt der Community die Freiheit, die Arbeit selbst zu erledigen. Wie :
Kubernetes ist eine Plattform zum Aufbau von Plattformen. Die beste Position zum Starten, aber nicht zum Beenden.
Infolgedessen sehen wir eine Reihe von Kubernetes-Builds sowie Hosting-Unternehmen, die versuchen, PaaS für Kubernetes zu erstellen, wie OpenShift und Rancher. Inmitten des wachsenden Kube-PaaS-Marktes betritt Knative, im Juli 2018 von Google und Pivotal gegründet, den Ring.
Knative war eine Zusammenarbeit zwischen Google und Pivotal, mit ein wenig Hilfe von anderen Unternehmen wie IBM, RedHat und Solo.im. Es bietet ähnliche PaaS-Funktionen wie Kubernetes mit erstklassiger Unterstützung für serverlose Computing-basierte Anwendungen. Im Gegensatz zu Kubernetes-Builds wird Knative als Add-on auf jedem kompatiblen Kubernetes-Cluster installiert und über Benutzerressourcen konfiguriert.
Was ist Knative?
Knative wird beschrieben als „Eine Kubernetes-basierte Plattform zur Bereitstellung und Verwaltung von Workloads mithilfe moderner serverloser Datenverarbeitung.“ Obwohl Knative sich selbst als eine solche Plattform bezeichnet, skaliert es Container aktiv automatisch im Verhältnis zu gleichzeitigen HTTP-Anfragen. Ungenutzte Dienste werden schließlich auf Null herunterskaliert, was eine serverlose On-Demand-Skalierung ermöglicht.
Knative besteht aus einer Reihe von Controllern, die in jedem Kubernetes-Cluster installiert werden und die folgenden Funktionen bieten:
- Erstellen von Containeranwendungen aus Quellcode (bereitgestellt von der Komponente). Bauen),
- Bereitstellung des Zugriffs auf eingehenden Datenverkehr für Anwendungen (bereitgestellt von der Komponente). Geschirr),
- Bereitstellung und automatische Skalierung von Anwendungen nach Bedarf (ebenfalls von der Komponente bereitgestellt). Geschirr),
- Identifizieren der Quellen von Ereignissen, die zum Start von Anwendungen führen (von der Komponente bereitgestellt). Vielseitigkeit).
Eine Schlüsselkomponente ist Serving, das Bereitstellung, automatische Skalierung und Datenverkehrsverwaltung für verwaltete Anwendungen bereitstellt. Nach der Installation von Knative haben Sie weiterhin vollen Zugriff auf die Kubernetes-API, sodass Benutzer Anwendungen verwalten können das übliche und dient auch zum Debuggen von Knative-Diensten, indem es mit denselben API-Primitiven arbeitet, die diese Dienste verwenden (Module, Dienste usw.).
Mit Hilfe von Serving wird auch das Blue-Green-Traffic-Routing automatisiert, wodurch eine Traffic-Trennung zwischen neuen und alten Versionen der Anwendung sichergestellt wird, wenn der Benutzer eine aktualisierte Version der Anwendung bereitstellt.
Knative selbst ist auf die Installation eines kompatiblen Ingress-Controllers angewiesen. Zum Zeitpunkt des Schreibens wird dieser Artikel unterstützt и . Es konfiguriert den verfügbaren Eingang, um den Datenverkehr an von Knative verwaltete Anwendungen weiterzuleiten.
Istio Service Mesh kann für Knative-Benutzer, die es ausprobieren möchten, ohne das Istio-Control-Panel zu installieren, eine große Abhängigkeit darstellen, da Knative nur vom Gateway abhängt.
Aus diesem Grund bevorzugen die meisten Benutzer Gloo als Gateway zu Knative, das einen ähnlichen Funktionsumfang wie Istio bietet (um nur Knative zu verwenden) und gleichzeitig deutlich weniger Ressourcen verbraucht und niedrigere Betriebskosten verursacht.
Lassen Sie uns Knative am Stand in Aktion testen. Ich verwende einen frisch installierten Cluster, der in GKE ausgeführt wird:
kubectl get namespace
NAME STATUS AGE
default Active 21h
kube-public Active 21h
kube-system Active 21hBeginnen wir mit der Installation von Knative und Gloo. 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
# ...Wir prüfen, ob sich alle Pods im Status „Running“ befinden:
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. Erstellen wir einen automatisch skalierenden Knative-Dienst (nennen wir ihn kservice) und leiten wir den Datenverkehr dorthin weiter.
Knative-Dienste bieten einen einfacheren Weg zur Bereitstellung von Anwendungen für Kubernetes als das herkömmliche Deployment+Service+Ingress-Modell. Wir werden mit diesem 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 userIch habe dies in eine Datei kopiert und es dann folgendermaßen auf meinen Kubernetes-Cluster angewendet:
kubectl apply -f ksvc.yaml -n defaultWir können die von Knative im Cluster erstellten Ressourcen anzeigen, nachdem wir unser „helloworld-go“ übermittelt haben. 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 gestartet, wenn der kservice bereitgestellt wird. Wenn kein Verkehr stattfindet, wird die Anzahl der Pods auf Null reduziert. Und umgekehrt: Wenn die Anzahl gleichzeitiger Anfragen einen bestimmten konfigurierbaren Schwellenwert überschreitet, erhöht sich die Anzahl der Pods.
kubectl get ingresses.networking.internal.knative.dev -n default
NAME READY REASON
helloworld-go TrueKnative konfiguriert seinen Eingang mithilfe einer speziellen „Ingress“-Ressource in der internen Knative-API. Gloo verwendet diese API als Konfiguration, um PaaS-ähnliche Funktionen bereitzustellen, darunter ein Blau-Grün-Bereitstellungsmodell, automatische TLS-Durchsetzung, Zeitüberschreitungen und andere erweiterte Routing-Funktionen.
Nach einiger Zeit sehen wir, dass unsere Pods verschwunden sind (weil kein eingehender Datenverkehr vorhanden war):
kubectl get pod -n default
No resources found.
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. Sie können die URL für Knative Proxy einfach und unkompliziert abrufen glooctl:
glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80Ohne installiert glooctl Sie können die Adresse und den Port im Kube-Dienst sehen:
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 einige Daten mit cURL ausführen:
curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hello Knative user!Knative bietet Entwicklern mithilfe des leistungsstarken Full-Stack-API-Gateways von Gloo ein Fast-PaaS-Angebot für Entwickler zusätzlich zu sofort einsatzbereitem Kubernetes. Dieser Beitrag hat nur einen kleinen Einblick in die umfangreichen Anpassungsmöglichkeiten und Zusatzfunktionen von Knative gegeben. Das Gleiche gilt für Gloo!
Obwohl Knative noch ein junges Projekt ist, veröffentlicht sein Team alle sechs Wochen neue Versionen und die Implementierung erweiterter Funktionen hat begonnen, wie z. B. die automatische TLS-Bereitstellung und die automatische Skalierung des Control Panels. Es besteht eine gute Chance, dass Knative als Ergebnis der Zusammenarbeit mehrerer Cloud-Unternehmen und als Grundlage des neuen Cloud Run-Angebots von Google zur primären Option für Serverless Computing und PaaS auf Kubernetes werden könnte. Verfolgen Sie die Nachrichten!
Von den Herausgebern von SouthBridge
Die Meinungen der Leser sind uns wichtig, daher bitten wir Sie, an einer kurzen Umfrage zu zukünftigen Artikeln über Knative, Kubernetes und Serverless Computing teilzunehmen:
An der Umfrage können nur registrierte Benutzer teilnehmen. bitte.
Sollte ich weiterhin Artikel und Leitfäden über Knative und Serverless Computing schreiben?
-
Ja, bitte.
-
Nein, danke.
28 Benutzer haben abgestimmt. 4 Benutzer enthielten sich der Stimme.
Source: habr.com