Kubernetes hat sich zweifellos zur dominierenden Plattform für die Bereitstellung von Containern entwickelt. Es bietet die Möglichkeit, fast alles mit seinen APIs und Benutzercontrollern zu verwalten, die seine API durch Benutzerressourcen erweitern.
Der Benutzer muss jedoch noch detaillierte Entscheidungen über die Bereitstellung, Konfiguration, Verwaltung und Skalierung von Anwendungen treffen. Es liegt im Ermessen des Benutzers, Fragen zur Skalierung der Anwendung, zum Schutz und zum Verkehrsweg zu stellen. Dies unterscheidet Kubernetes von herkömmlichen „Platform as a Service“ (PaaS) wie Cloud Foundry und Heroku.
Plattformen haben eine vereinfachte Benutzeroberfläche, die sich an Anwendungsentwickler richtet, die am häufigsten an der Anpassung einzelner Anwendungen beteiligt sind. Routing, Bereitstellung und Metriken, die für den Benutzer transparent sind, werden vom zugrunde liegenden PaaS-System verwaltet.
Der Workflow für die Quellzustellung wird von PaaS abgewickelt, indem ein benutzerdefiniertes Container-Image erstellt, bereitgestellt, eine neue Route und eine DNS-Unterdomäne für eingehenden Datenverkehr eingerichtet wird. All dies wird durch den Befehl git push ausgelöst.
Kubernetes stellt (absichtlich) nur die Grundbausteine für solche Plattformen zur Verfügung und gibt der Community die Möglichkeit, diese Arbeit alleine zu erledigen. Wie Kelsey Hightower sagte :
Kubernetes ist eine Plattform zum Bauen von Plattformen. Die beste Position, um zu starten, aber nicht zu beenden.
Infolgedessen sehen wir eine Reihe von Kubernetes-Assemblys sowie Hosting-Unternehmen, die versuchen, PaaS für Kubernetes zu erstellen, z. B. OpenShift und Rancher. Inmitten des wachsenden Kube-PaaS-Marktes betritt Knative, der im Juli 2018 von Google und Pivotal gegründet wurde, den Ring.
Knative war eine Zusammenarbeit zwischen Google und Pivotal, wobei andere Unternehmen wie IBM, RedHat und Solo.im kaum zusammengearbeitet haben. Es bietet ähnliche PaaS-Produkte für Kubernetes mit erstklassiger Unterstützung für serverlose Computeranwendungen. Im Gegensatz zu Kubernetes-Assemblys wird Knative als Add-On zu jedem kompatiblen Kubernetes-Cluster installiert und über Benutzerressourcen konfiguriert.
Was ist Knative?
Knative wird als "Kubernetes-basierte Plattform zur Bereitstellung und Verwaltung von Workloads mit modernem Serverless Computing" beschrieben. Knative erklärt sich selbst zu einer solchen Plattform und skaliert Container automatisch proportional zu gleichzeitigen HTTP-Anforderungen. Nicht genutzte Dienste werden letztendlich auf null skaliert und bieten eine On-Demand-Skalierung im Stil von Serverless Computing.
Knative besteht aus einer Reihe von Controllern, die in einem beliebigen Kubernetes-Cluster installiert sind und die folgenden Funktionen bieten:
- Zusammenstellung von containerisierten Anwendungen aus dem Quellcode (bereitgestellt von der Build- Komponente),
- Bereitstellung des Zugriffs auf eingehenden Datenverkehr für Anwendungen (bereitgestellt von der Serving- Komponente),
- Bereitstellung und automatische Skalierung von Anwendungen nach Bedarf (auch von der Serving- Komponente bereitgestellt),
- Ermittlung der Ereignisquellen, die zum Starten von Anwendungen führen (bereitgestellt von der Eventing- Komponente).
Eine Schlüsselkomponente ist Serving, das die Bereitstellung, automatische Skalierung und Datenverkehrssteuerung für verwaltete Anwendungen bietet. Nach der Installation von Knative bleibt der uneingeschränkte Zugriff auf die Kubernetes-API erhalten, sodass Benutzer Anwendungen auf die übliche Weise verwalten und Knative-Dienste debuggen können, indem sie mit denselben API-Grundelementen arbeiten, die diese Dienste verwenden (Module, Dienste usw.).
Durch das Serving wird auch das blau-grüne Routing des Datenverkehrs automatisiert und die Trennung des Datenverkehrs zwischen neuen und alten Versionen der Anwendung sichergestellt, wenn der Benutzer eine aktualisierte Version der Anwendung bereitstellt.
Knative selbst hängt von der Installation eines kompatiblen Ingress-Controllers ab. Zum Zeitpunkt des Schreibens werden Gloo API Gateway und Istio Service Mesh unterstützt. Er wird den verfügbaren Eingang konfigurieren, um Datenverkehr an Knative-gesteuerte Anwendungen weiterzuleiten.
Istio Service Mesh kann eine große Sucht für Knative-Benutzer werden, die es ausprobieren möchten, ohne das Istio-Kontrollfeld zu installieren, da Knative nur vom Gateway abhängig ist.
Aus diesem Grund bevorzugen die meisten Benutzer Gloo als Gateway zu Knative, das mit Istio ähnliche Funktionen bietet (wenn wir über den Zweck sprechen, nur Knative zu verwenden), sowie deutlich weniger Ressourcen verbraucht und niedrigere Betriebskosten bietet.
Lassen Sie uns Knative in Aktion am Stand überprüfen. 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 21h
Wir fahren mit der Installation von Knative und Gloo fort. 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 # ...
Stellen Sie sicher, dass 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 44s
Gloo ist bereit für das Routing. Erstellen wir einen automatisch skalierbaren Knative-Service (nennen wir ihn kservice) und leiten Sie den Datenverkehr dorthin.
Knative Services bieten eine einfachere Möglichkeit, Anwendungen für Kubernetes bereitzustellen - im Vergleich zum regulären Deployment + Service + Ingress-Modell. Wir werden mit einem solchen 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 user
Ich habe dies in eine Datei kopiert und es dann folgendermaßen auf meinen Kubernetes-Cluster angewendet:
kubectl apply -f ksvc.yaml -n default
Wir können die Ressourcen anzeigen, die Knative nach der Bereitstellung unseres 'helloworld-go'-Service im Cluster erstellt hat :
kubectl get pod -n default NAME READY STATUS RESTARTS AGE helloworld-go-fjp75-deployment-678b965ccb-sfpn8 2/2 Running 0 68s
Der Pod mit unserem "helloworld-go" -Image wird gestartet, wenn Sie kservice bereitstellen. Wenn es keinen Verkehr gibt, wird die Anzahl der Pods auf Null reduziert. Und umgekehrt, wenn die Anzahl der gleichzeitigen Anforderungen einen benutzerdefinierten Schwellenwert überschreitet, erhöht sich die Anzahl der Pods.
kubectl get ingresses.networking.internal.knative.dev -n default NAME READY REASON helloworld-go True
Knative konfiguriert seinen Eingang mithilfe einer speziellen Eingangsressource in der internen API von Knative. Gloo verwendet diese API als Konfiguration, um die Eigenschaften von PaaS bereitzustellen, einschließlich des blau-grünen Bereitstellungsmodells, des automatischen TLS, Timeouts und anderer erweiterter Routingfunktionen.
Nach einiger Zeit sehen wir, dass unsere Pods verschwunden sind (da es keinen eingehenden Verkehr gab):
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 9m46s
Schließlich werden wir versuchen, sie zu erreichen. Das Abrufen von URLs für Knative Proxy ist mit glooctl einfach:
glooctl proxy url --name knative-external-proxy http://35.190.151.188:80
Ohne glooctl Installation von glooctl können glooctl die Adresse und den Port in kube service ausspähen:
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 77m
Führe ein bisschen Daten mit cURL aus:
curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188 Hello Knative user!
Knative bietet Entwicklern Near-PaaS zusätzlich zu Kubernetes 'Box-basiertem, leistungsfähigem API-Gateway von Gloo. Diese Anmerkung hat die umfangreiche Anzahl an Knative-Funktionen, die zur Anpassung zur Verfügung stehen, sowie zusätzliche Funktionen nur geringfügig berührt. Ähnliches gilt für Gloo!
Obwohl Knative noch ein junges Projekt ist, veröffentlicht sein Team alle sechs Wochen neue Versionen. Mit der Implementierung erweiterter Funktionen wurde begonnen, z. B. die automatische TLS-Bereitstellung und die automatische Skalierung des Control Panels. Es besteht eine hohe Wahrscheinlichkeit, dass Knative aufgrund der Zusammenarbeit zwischen zahlreichen Cloud-Unternehmen sowie aufgrund des neuen Cloud-Run-Angebots von Google zur Hauptoption für die Organisation von Serverless Computing und PaaS in Kubernetes wird. Befolgen Sie die Nachrichten!
Von SouthBridge
Die Meinung der Leser ist uns wichtig, daher bitten wir Sie, an einer kleinen Umfrage zu zukünftigen Artikeln über Knative, Kubernetes und Serverless Computing teilzunehmen: