De dominante platform voor het implementeren van containers is zonder twijfel Kubernetes geworden. Het biedt de mogelijkheid om vrijwel alles te beheren met zijn API en aangepaste controllers die de API uitbreiden met behulp van aangepaste resources.
Toch moet de gebruiker nog steeds gedetailleerde beslissingen nemen over hoe de toepassingen precies te implementeren, configureren, beheren en schalen. De vragen over het schalen van toepassingen, beveiliging en verkeersrouting blijven de verantwoordelijkheid van de gebruiker. Dit maakt Kubernetes anders dan gewone 'platforms als een dienst' (PaaS), zoals Cloud Foundry en Heroku.
Platforms hebben een vereenvoudigde gebruikersinterface en zijn gericht op applicatieontwikkelaars die zich meestal bezighouden met de configuratie van afzonderlijke toepassingen. Routering, implementatie en metrics worden transparant beheerd door het onderliggende PaaS-systeem.
De workflow van 'broncode – levering' wordt door PaaS afgehandeld door het creëren van een aangepaste containerafbeelding, deze te implementeren, een nieuwe route en DNS-subdomein voor binnenkomend verkeer te configureren. Dit alles wordt gestart met het commando git push.
In Kubernetes worden (opzettelijk) alleen de basiscomponenten voor dergelijke platforms geleverd, waardoor de gemeenschap de mogelijkheid krijgt om dit zelf te doen. Zoals :
Kubernetes is een platform voor het bouwen van platforms. De beste startpositie, maar niet de finish.
Hierdoor zien we een reeks Kubernetes-builds en hostingdiensten die PaaS voor Kubernetes proberen te creëren, zoals OpenShift en Rancher. Tegen de achtergrond van de groeiende Kube-PaaS-markt betreedt Knative, ontwikkeld in juli 2018 door Google en Pivotal, de ring.
Knative is ontstaan uit de samenwerking tussen Google en Pivotal, met enige ondersteuning van andere bedrijven zoals IBM, RedHat en Solo.im. Het biedt vergelijkbare PaaS-functies voor Kubernetes met eersteklas ondersteuning voor toepassingen op basis van serverless computing. In tegenstelling tot Kubernetes-builds wordt Knative geïnstalleerd als een uitbreiding op elke compatibele Kubernetes-cluster, geconfigureerd via aangepaste resources.
Wat is Knative?
Knative wordt beschreven als "Een Kubernetes-gebaseerd platform voor het leveren en beheren van workloads met behulp van moderne serverloze computing". Knative, dat zichzelf als zo'n platform verklaart, schaalt containers automatisch op basis van het aantal gelijktijdige HTTP-verzoeken. Ongebruikte services schalen uiteindelijk naar nul, wat on-demand schaling in serverloze stijl mogelijk maakt.
Knative bestaat uit een set controllers die in elke Kubernetes-cluster kunnen worden geïnstalleerd en de volgende mogelijkheden bieden:
- het bouwen van container-gebaseerde applicaties uit broncode (geleverd door component Build),
- het bieden van toegang voor inkomend verkeer naar applicaties (geleverd door component Serving),
- levering en automatische schaling van applicaties op aanvraag (ook geleverd door component Serving),
- het definiëren van gebeurtenisbronnen die leiden tot het starten van applicaties (geleverd door component Eventing).
Een sleutelcomponent is Serving, dat levering, automatische schaling en traffic management biedt voor beheerde applicaties. Na de installatie van Knative blijft volledige toegang tot de Kubernetes API behouden, waardoor gebruikers applicaties kunnen beheren op de gebruikelijke manier, en ook dient voor het debuggen van Knative-services, gebruikmakend van dezelfde API-primitieven die deze services gebruiken (modules, services, enz.). Met Serving wordt ook de blue-green traffic routing geautomatiseerd, waarbij het verkeer wordt verdeeld tussen nieuwe en oude versies van de applicatie wanneer de gebruiker een bijgewerkte versie van de applicatie levert.
Knative zelf is afhankelijk van de installatie van een compatibele ingress controller. Op het moment van schrijven worden ondersteund
Gloo API Gateway en Istio Service Mesh kan een aanzienlijke afhankelijkheid zijn voor gebruikers van Knative die het willen uitproberen zonder het installeren van een Istio-beheerpaneel, omdat Knative alleen van de gateway afhankelijk is.
Istio Service Mesh kan een grote afhankelijkheid worden voor Knative-gebruikers die het willen uitproberen zonder het installeren van het Istio-dashboard, aangezien Knative alleen van de gateway afhankelijk is.
Om deze reden geven de meeste gebruikers de voorkeur aan Gloo als de gateway voor Knative, die een vergelijkbare set functionaliteiten biedt als Istio (wanneer we alleen kijken naar het gebruik van Knative), terwijl het aanzienlijk minder middelen verbruikt en lagere operationele kosten met zich meebrengt.
Laten we Knative in actie bekijken op de testomgeving. Ik zal een vers geïnstalleerde cluster gebruiken, uitgevoerd in GKE:
kubectl get namespace
NAME STATUS AGE
default Active 21h
kube-public Active 21h
kube-system Active 21hLaten we beginnen met de installatie van Knative en Gloo. Dit kan in eender welke volgorde:
# ставим 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
# ...We controleren of alle Pods in de status 'Running' staan:
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 is klaar om te routeren, laten we een automatisch schaalbare Knative-service (laten we het kservice noemen) creëren en deze van verkeer voorzien.
Knative-services bieden een eenvoudigere manier om applicaties in Kubernetes te implementeren — in vergelijking met het traditionele model Deployment+Service+Ingress. We zullen werken met het volgende voorbeeld:
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 userIk heb dit gekopieerd naar een bestand en het vervolgens op mijn Kubernetes-cluster toegepast op deze manier:
kubectl apply -f ksvc.yaml -n defaultWe kunnen de door Knative gemaakte resources in het cluster bekijken na de levering van onze ‘helloworld-go’ kservice:
kubectl get pod -n default
NAME READY STATUS RESTARTS AGE
helloworld-go-fjp75-deployment-678b965ccb-sfpn8 2/2 Running 0 68sDe Pod met onze 'helloworld-go' afbeelding wordt gestart bij de implementatie van kservice. Als er geen verkeer is, zal het aantal pods worden verminderd tot nul. Omgekeerd, als het aantal gelijktijdige verzoeken een bepaalde configureerbare drempel overschrijdt, zal het aantal pods toenemen.
kubectl get ingresses.networking.internal.knative.dev -n default
NAME READY REASON
helloworld-go TrueKnative stelt zijn ingress in met behulp van een speciale 'ingress' bron in de interne API van Knative. Gloo neemt deze API als zijn configuratie voor het aanbieden van de eigenschappen die typisch zijn voor PaaS, inclusief een blue-green implementatiemodel, automatische toepassing van TLS, time-outs en andere geavanceerde routeringskenmerken.
Na een tijdje zien we dat onze pods zijn verdwenen (omdat er geen binnenkomend verkeer was):
kubectl get pod -n default
Geen resources gevonden.
kubectl get deployment -n default
NAAM GEWENST HUIDIG UP-TO-DATE BESCHIKBAAR LEEFTIJD
helloworld-go-fjp75-deployment 0 0 0 0 9m46sEindelijk zullen we proberen contact met hen te maken. Het verkrijgen van de URL voor Knative Proxy kan eenvoudig en moeiteloos met: glooctl:
glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80Zonder geïnstalleerde glooctl kun je het adres en de poort bekijken in de kube service:
kubectl get svc -n gloo-system knative-external-proxy
NAAM TYPE CLUSTER-IP EXTERNAL-IP POORT(EN) LEEFTIJD
knative-external-proxy LoadBalancer 10.16.11.157 35.190.151.188 80:32168/TCP,443:30729/TCP 77mLaten we wat gegevens doorsturen met cURL:
curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hallo Knative gebruiker!Knative biedt bijna-PaaS voor ontwikkelaars bovenop 'out-of-the-box' Kubernetes, gebruikmakend van de hoog presterende, volle functionaliteit API gateway Gloo. Deze notitie raakte slechts licht aan het uitgebreide aantal mogelijkheden van Knative dat beschikbaar is voor configuratie, evenals extra functies. Dit geldt ook voor Gloo!
Hoewel Knative nog een jong project is, brengt het team elke zes weken nieuwe versies uit, en zijn geavanceerde functies in uitvoering, zoals automatische TLS-implementatie en automatische schaalbaarheid van het dashboard. Er is een grote kans dat Knative, door de samenwerking van verschillende cloudbedrijven en als basis van het nieuwe Cloud Run aanbod van Google, de belangrijkste keuze kan worden voor serverless computing en PaaS in Kubernetes. Houd de updates in de gaten!
Van de redactie van SouthBridge
De mening van de lezers is belangrijk voor ons, daarom vragen we u om deel te nemen aan een korte enquête over toekomstige artikelen over Knative, Kubernetes, serverless computing:
Alleen geregistreerde gebruikers kunnen deelnemen aan de enquête. , alstublieft.
Zal ik doorgaan met het vertalen en schrijven van artikelen en handleidingen over Knative en serverless computing?
Ja, graag.
Bedankt, dat hoeft niet.
28 gebruikers hebben gestemd. 4 gebruikers hebben zich onthouden.
Bron: habr.com
