Knative — piattaforma come servizio basata su k8s con supporto per serverless

Knative — piattaforma come servizio basata su k8s con supporto per serverless

La piattaforma dominante per il deployment di container è senza dubbio Kubernetes. Essa offre la possibilità di gestire praticamente tutto utilizzando le sue API e controller personalizzati che estendono le sue API tramite risorse personalizzate.

Tuttavia, l'utente deve ancora prendere decisioni dettagliate su come effettivamente distribuire, configurare, gestire e scalare le applicazioni. All'utente rimangono domande riguardanti la scalabilità delle applicazioni, la sicurezza e la gestione del traffico. Questa è la distinzione di Kubernetes rispetto alle comuni "piattaforme come servizio" (PaaS), come ad esempio Cloud Foundry e Heroku.

Le piattaforme offrono un'interfaccia utente semplificata, orientata agli sviluppatori di applicazioni che si occupano più frequentemente della configurazione di singole applicazioni. Routing, deployment e metriche sono gestiti in modo trasparente per l'utente dal sistema PaaS sottostante.

Il flusso di lavoro ‘codice sorgente – fornitura’ è gestito da PaaS attraverso la creazione di un'immagine del contenitore personalizzato, il suo dispiegamento, la configurazione di un nuovo percorso e di un sottodominio DNS per il traffico in ingresso. Tutto ciò viene attivato su comando. git push.

In Kubernetes (intenzionalmente) vengono forniti solo i blocchi fondamentali per tali piattaforme, consentendo alla comunità di svolgere questo lavoro autonomamente. Come ha detto Kelsey Hightower.:

Kubernetes è una piattaforma per costruire piattaforme. È la posizione migliore per iniziare, ma non per finire.

Di conseguenza, vediamo un'affluenza di distribuzioni Kubernetes, così come di hosting, che cercano di creare PaaS per Kubernetes, come OpenShift e Rancher. Sullo sfondo di un mercato in crescita del Kube-PaaS, emerge Knative, creato nel luglio 2018 dalle aziende Google e Pivotal.

Knative è il risultato della collaborazione tra Google e Pivotal, con il supporto di altre aziende come IBM, RedHat e Solo.im. Offre funzionalità PaaS analoghe per Kubernetes, con un supporto di primo piano per applicazioni basate su calcolo serverless. A differenza delle distribuzioni Kubernetes, Knative viene installato come un'estensione su qualsiasi cluster Kubernetes compatibile e configurato tramite risorse personalizzate.

Che cos'è Knative?

Knative è descritto come una «Piattaforma basata su Kubernetes per la distribuzione e la gestione di carichi di lavoro utilizzando moderne soluzioni di calcolo serverless». Dichiarandosi tale, Knative scala automaticamente i contenitori in base alle richieste HTTP simultanee. I servizi non utilizzati vengono eventualmente scalati a zero, fornendo scalabilità on-demand in stile serverless.

Knative è composto da un insieme di controllori installabili in qualsiasi cluster Kubernetes e fornisce le seguenti funzionalità:

  • costruzione di applicazioni containerizzate dal codice sorgente (fornita dal componente Build),
  • fornendo accesso al traffico in ingresso alle applicazioni (fornito dal componente Servire),
  • fornitura e scalabilità automatica delle applicazioni su richiesta (anch'essa fornita dal componente Servire),
  • definizione delle fonti di eventi che attivano le applicazioni (fornito dal componente Eventing).

Il componente chiave è Serving, che fornisce fornitura, scalabilità automatica e gestione del traffico per applicazioni gestite. Dopo l'installazione di Knative, rimane l'accesso completo all'API Kubernetes, consentendo agli utenti di gestire le applicazioni in modo standard e funge anche da strumento per il debug dei servizi Knative, lavorando con gli stessi primitivi API che questi servizi utilizzano (moduli, servizi, ecc.).

Serving automatizza anche il traffico di routing blue-green, garantendo la ripartizione del traffico tra le versioni nuove e quelle vecchie dell'applicazione durante la distribuzione di una versione aggiornata da parte dell'utente.

Knative stesso dipende dall'installazione di un controller ingress compatibile. Al momento della stesura dell'articolo sono supportati Gloo API Gateway e Istio Service Mesh. Configurerà un ingress accessibile per instradare il traffico verso le applicazioni gestite tramite Knative.

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

Per questo motivo, la maggior parte degli utenti preferisce Gloo come gateway per Knative, fornendo un insieme simile di funzionalità rispetto a Istio (parlando esclusivamente dell'uso di Knative), utilizzando inoltre significativamente meno risorse e comportando minori costi operativi.

Controlliamo Knative in azione su un banco di prova. Userò un cluster appena installato, eseguito su GKE:

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

Iniziamo l'installazione di Knative e Gloo. 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
# ...

Verifichiamo che tutti i Pod siano nello stato 'Running':

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 la gestione del traffico; creiamo un servizio Knative scalabile automaticamente (lo chiameremo kservice) e dirigiamo il traffico verso di esso.

I servizi Knative forniscono un modo più semplice per distribuire applicazioni in Kubernetes, rispetto al modello tradizionale di Deployment+Service+Ingress. Lavoriamo con un esempio del genere:

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

Ho copiato questo in un file, poi 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 la consegna del 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 al momento della distribuzione del kservice. Se non c'è traffico, il numero di pod sarà ridotto a zero. Al contrario, se il numero di richieste simultanee supera una 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 proprio ingress utilizzando una risorsa ‘ingress’ speciale nell'API interna di Knative. Gloo utilizza questa API come configurazione per fornire proprietà tipiche del PaaS, inclusi il modello di distribuzione blue-green, l'applicazione automatica di TLS, i timeout e altre funzionalità avanzate di routing.

Dopo un po' di tempo, vediamo che i nostri pod sono scomparsi (poiché non c'è stato traffico in ingresso):

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

Finalmente proveremo a contattarli. Ottenere l'URL per il Knative Proxy è facile e senza sforzi grazie a glooctl:

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

Senza un'installazione di glooctl puoi visualizzare l'indirizzo e la porta nel servizio kube:

kubectl get svc -n gloo-system knative-external-proxy
NOME                     TIPO           CLUSTER-IP     EXTERNAL-IP      PORT(S)                      ETÀ
knative-external-proxy   LoadBalancer   10.16.11.157   35.190.151.188   80:32168/TCP,443:30729/TCP   77m

Eseguiamo un po' di dati con cURL:

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

Knative fornisce quasi-PaaS per gli sviluppatori sopra il Kubernetes 'out-of-the-box', utilizzando un gateway API Gloo ad alte prestazioni e completo. Questo appunto ha appena toccato la vasta gamma di funzionalità di Knative, disponibili per la configurazione, così come le funzionalità aggiuntive. Lo stesso vale per Gloo!

Nonostante Knative sia ancora un progetto giovane, il suo team rilascia nuove versioni ogni sei settimane e ha avviato l'implementazione di funzionalità avanzate, come il deployment automatico di TLS e lo scaling automatico del pannello di controllo. È molto probabile che, grazie alla collaborazione di numerose aziende cloud e in quanto base della nuova offerta Cloud Run di Google, Knative possa diventare l'opzione principale per l'organizzazione di calcoli serverless e PaaS in Kubernetes. Rimanete sintonizzati per aggiornamenti!

Dalla redazione di SouthBridge
Per noi è importante il parere dei lettori, quindi vi chiediamo di partecipare a un breve sondaggio riguardo ai futuri articoli su Knative, Kubernetes e calcoli serverless:

Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.

Volete continuare a tradurre articoli e guide su Knative e i calcoli serverless?

  • Sì, per favore.

  • Grazie, non è necessario.

Hanno votato 28 utenti. 4 utenti si sono astenuti.

Fonte: habr.com

Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server 🔥 Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server | ProHoster