Knative: piattaforma come servizio basata su k8s con supporto serverless

Knative: piattaforma come servizio basata su k8s con supporto serverless

Kubernetes è senza dubbio diventata la piattaforma dominante per l’implementazione dei container. Fornisce la possibilità di controllare quasi tutto utilizzando le sue API e controller personalizzati che estendono le sue API con risorse personalizzate.

Tuttavia, l'utente deve ancora prendere decisioni dettagliate su come distribuire, configurare, gestire e scalare le applicazioni. I problemi relativi alla scalabilità, alla protezione e al flusso del traffico delle applicazioni rimangono a discrezione dell'utente. Ciò distingue Kubernetes dalle piattaforme convenzionali come servizio (PaaS), come Cloud Foundry e Heroku.

Le piattaforme hanno un'interfaccia utente semplificata e si rivolgono agli sviluppatori di applicazioni che molto spesso sono coinvolti nella creazione di singole applicazioni. Il routing, la distribuzione e le metriche sono gestiti in modo trasparente per l'utente dal sistema PaaS sottostante.

Il flusso di lavoro dall'origine alla spedizione viene gestito da PaaS creando un'immagine del contenitore personalizzata, distribuendola, impostando un nuovo percorso e un sottodominio DNS per il traffico in entrata. Tutto questo viene lanciato a comando git push.

Kubernetes (intenzionalmente) fornisce solo gli elementi fondamentali per tali piattaforme, lasciando la comunità libera di svolgere il lavoro da sola. Come Kelsey Hightower ha detto:

Kubernetes è una piattaforma per la creazione di piattaforme. La posizione migliore per iniziare, ma non per finire.

Di conseguenza, vediamo un sacco di build Kubernetes, così come società di hosting che stanno cercando di creare PaaS per Kubernetes, come OpenShift e Rancher. Nel crescente mercato Kube-PaaS, Knative, fondata nel luglio 2018 da Google e Pivotal, sta entrando sul ring.

Knative è nata dalla collaborazione tra Google e Pivotal, con un piccolo aiuto da parte di altre aziende come IBM, RedHat e Solo.im. Offre funzionalità PaaS simili a Kubernetes con un supporto di prim'ordine per applicazioni basate sull'elaborazione serverless. A differenza delle build Kubernetes, Knative viene installato come componente aggiuntivo su qualsiasi cluster Kubernetes compatibile e configurato tramite le risorse utente.

Cos'è Knative?

Knative è descritta come "Una piattaforma basata su Kubernetes per la distribuzione e la gestione dei carichi di lavoro utilizzando il moderno computing serverless". Knative, pur presentandosi come tale piattaforma, scala automaticamente i contenitori in proporzione alle richieste HTTP simultanee. I servizi inutilizzati alla fine si riducono a zero, fornendo scalabilità on-demand in stile serverless.

Knative è costituito da un insieme di controller che si installano in qualsiasi cluster Kubernetes e forniscono le seguenti funzionalità:

  • creare applicazioni containerizzate dal codice sorgente (fornito dal componente Costruire),
  • fornendo l'accesso al traffico in entrata alle applicazioni (fornito dal componente Servire),
  • delivery e scalabilità automatica delle applicazioni on demand (fornito anche dal componente Servire),
  • identificare le fonti degli eventi che portano al lancio dell'applicazione (fornito dal componente Eventing).

Un componente chiave è Serving, che fornisce provisioning, scalabilità automatica e gestione del traffico per le applicazioni gestite. Dopo aver installato Knative, avrai ancora accesso completo all'API Kubernetes, consentendo agli utenti di gestire le applicazioni il solito modo e serve anche per eseguire il debug dei servizi Knative, lavorando con le stesse primitive API utilizzate da questi servizi (moduli, servizi, ecc.).

Con l'aiuto di Serving, anche il routing del traffico blu-verde è automatizzato, garantendo la separazione del traffico tra le nuove e le vecchie versioni dell'applicazione quando l'utente fornisce una versione aggiornata dell'applicazione.

Knative stesso dipende dall'installazione di un controller di ingresso compatibile. Al momento della stesura di questo articolo è supportato Gateway API Gloo и Rete di servizi Istio. Configurerà l'ingresso disponibile per instradare il traffico alle applicazioni gestite da Knative.

Istio Service Mesh può rappresentare una grande dipendenza per gli utenti Knative che desiderano provarlo senza installare il pannello di controllo Istio, poiché Knative dipende solo dal gateway.

Per questo motivo, la maggior parte degli utenti preferisce Gloo come gateway per Knative, fornendo un insieme di funzionalità simili a Istio (allo scopo di utilizzare solo Knative), utilizzando allo stesso tempo molte meno risorse e avendo costi operativi inferiori.

Testiamo Knative in azione sullo stand. Utilizzerò un cluster appena installato in esecuzione in GKE:

kubectl get namespace
NAME          STATUS   AGE
default       Active   21h
kube-public   Active   21h
kube-system   Active   21h

Iniziamo a installare Knative e Gloo. Questo può essere fatto in qualsiasi ordine:

# ставим 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
# ...

Controlliamo che tutti i Pod siano nello stato "In esecuzione":

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 è pronto per il routing, creiamo un servizio Knative con scalabilità automatica (chiamiamolo kservice) e instradamo il traffico verso di esso.

I servizi Knative forniscono un percorso più semplice per distribuire le applicazioni a Kubernetes rispetto al modello convenzionale di distribuzione+servizio+ingresso. Lavoreremo con questo esempio:

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

L'ho copiato in un file, quindi l'ho applicato al mio cluster Kubernetes in questo modo:

kubectl apply -f ksvc.yaml -n default

Possiamo visualizzare le risorse create da Knative nel cluster dopo aver consegnato il nostro "helloworld-go" kservice:

kubectl get pod -n default
NAME                                              READY   STATUS    RESTARTS   AGE
helloworld-go-fjp75-deployment-678b965ccb-sfpn8   2/2     Running   0          68s

Il pod con la nostra immagine "helloworld-go" viene avviato quando viene distribuito kservice. Se non c'è traffico, il numero di pod verrà ridotto a zero. E viceversa, se il numero di richieste simultanee supera una certa soglia configurabile, il numero di pod aumenterà.

kubectl get ingresses.networking.internal.knative.dev -n default
NAME            READY   REASON
helloworld-go   True

Knative configura il suo ingresso utilizzando una speciale risorsa di "ingresso" nell'API Knative interna. Gloo utilizza questa API come configurazione per fornire funzionalità simili a PaaS, incluso un modello di distribuzione blu-verde, applicazione TLS automatica, timeout e altre funzionalità di routing avanzate.

Dopo un po' di tempo, vediamo che i nostri pod sono scomparsi (perché non c'era traffico in entrata):

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

Infine proveremo a raggiungerli. Puoi ottenere facilmente e facilmente l'URL per Knative Proxy utilizzando glooctl:

glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80

Senza installato glooctl puoi vedere l'indirizzo e la porta nel servizio kube:

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

Eseguiamo alcuni dati utilizzando cURL:

curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hello Knative user!

Knative fornisce una soluzione quasi PaaS per gli sviluppatori oltre a Kubernetes pronto all'uso utilizzando il gateway API full-stack ad alte prestazioni di Gloo. Questo post ha solo scalfito la superficie delle ampie opzioni di personalizzazione e delle funzionalità aggiuntive di Knative. Lo stesso con Gloo!

Nonostante Knative sia ancora un progetto giovane, il suo team rilascia nuove versioni ogni sei settimane ed è iniziata l'implementazione di funzionalità avanzate, come l'implementazione automatica di TLS e il ridimensionamento automatico del pannello di controllo. Ci sono buone probabilità che, come risultato della collaborazione tra più società cloud e come base della nuova offerta Cloud Run di Google, Knative possa diventare l'opzione principale per il computing serverless e PaaS su Kubernetes. Segui le notizie!

Dalla redazione di SouthBridge
Le opinioni dei lettori sono importanti per noi, quindi ti chiediamo di partecipare a un breve sondaggio relativo ai futuri articoli su Knative, Kubernetes e serverless computing:

Solo gli utenti registrati possono partecipare al sondaggio. AccediPer favore.

Dovrei continuare a scrivere articoli e guide su Knative e serverless computing?

  • Sì, per favore.

  • Grazie no

28 utenti hanno votato. 4 utenti si sono astenuti.

Fonte: habr.com

Aggiungi un commento