La piattaforma dominante per il deployment di container è indubbiamente Kubernetes. Essa offre la possibilità di gestire praticamente tutto, utilizzando le sue API e i controller personalizzati, che ampliano le sue API attraverso risorse personalizzate.
Tuttavia, l'utente deve ancora prendere decisioni dettagliate su come esattamente implementare, configurare, gestire e scalare le applicazioni. Rimangono a carico dell'utente questioni come la scalabilità delle applicazioni, la sicurezza e il traffico. Questo distingue Kubernetes dalle comuni 'piattaforme come servizio' (PaaS), come Cloud Foundry e Heroku.
Le piattaforme offrono un'interfaccia utente semplificata, orientata agli sviluppatori di applicazioni, che si occupano più spesso della configurazione di applicazioni specifiche. La gestione del routing, del deployment e delle metriche è trasparente per l'utente e viene gestita dal sistema PaaS sottostante.
Il flusso di lavoro "codice sorgente – consegna" è gestito dal PaaS creando un'immagine di container personalizzata, distribuendola, configurando un nuovo percorso e un sottodominio DNS per il traffico in entrata. Tutto questo viene avviato su comando. git push.
In Kubernetes vengono forniti (intenzionalmente) solo i blocchi fondamentali per tali piattaforme, consentendo alla comunità di realizzare questo lavoro autonomamente. Come :
Kubernetes è una piattaforma per costruire piattaforme. È la migliore posizione per partire, ma non per finire.
Di conseguenza, vediamo un insieme di distribuzioni di Kubernetes e hosting che cercano di creare PaaS per Kubernetes, come OpenShift e Rancher. Sullo sfondo di un mercato Kube-PaaS in crescita, Knative, creato nel luglio 2018 da Google e Pivotal, fa il suo ingresso.
Knative è frutto della collaborazione tra Google e Pivotal, con il supporto di altre aziende, come IBM, RedHat e Solo.im. Essa offre funzionalità simili a quelle di PaaS per Kubernetes, con un supporto di prim'ordine per le applicazioni basate su computing serverless. A differenza delle distribuzioni di Kubernetes, Knative viene installato come un componente aggiuntivo su qualsiasi cluster Kubernetes compatibile e configurato tramite risorse personalizzate.
Che cos'è Knative?
Knative è descritto come «Una piattaforma basata su Kubernetes per la fornitura e la gestione di carichi di lavoro utilizzando il calcolo serverless moderno». Knative, dichiarandosi tale piattaforma, scala attivamente automaticamente i container in proporzione alle richieste HTTP simultanee. I servizi non utilizzati alla fine vengono scalati a zero, fornendo scalabilità on-demand in stile calcolo serverless.
Knative è composto da un insieme di controller installabili su qualsiasi cluster Kubernetes e fornisce le seguenti funzionalità:
- creazione di applicazioni containerizzate a partire dal codice sorgente (fornita dal componente Build),
- fornire accesso al traffico in ingresso alle applicazioni (fornita dal componente Serving),
- fornitura e scalabilità automatica delle applicazioni su richiesta (anche fornita dal componente Serving),
- definizione delle fonti di eventi che attivano l’esecuzione delle applicazioni (fornita dal componente Eventing).
Il componente chiave è Serving, che offre fornitura, scalabilità automatica e gestione del traffico per le applicazioni gestite. Dopo l'installazione di Knative, rimane l'accesso completo all'API di Kubernetes, che consente agli utenti di gestire le applicazioni in modo normale, e serve anche per il debug dei servizi Knative, lavorando con gli stessi primitivi API che questi servizi utilizzano (moduli, servizi, ecc.).
Con Serving viene anche automatizzata la routing blue-green del traffico, assicurando la separazione del traffico tra le nuove e vecchie versioni dell'applicazione durante la fornitura di una versione aggiornata dell'applicazione da parte dell'utente.
Knative dipende anche dall'installazione di un controller ingress compatibile. Al momento della scrittura, sono supportati e . Questo configurerà l'ingress disponibile per il routing del traffico verso le applicazioni gestite tramite Knative.
L'Istio Service Mesh può diventare una grande dipendenza per gli utenti di 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à simile a Istio (se si considera l’uso esclusivo di Knative), e utilizzando anche significativamente meno risorse e comportando minori costi operativi.
Controlliamo Knative in azione su un ambiente di prova. Utilizzerò un cluster appena installato, avviato in GKE:
kubectl get namespace
NAME STATUS AGE
default Active 21h
kube-public Active 21h
kube-system Active 21hIniziamo ad 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
# ...Verifichiamo che tutti i Pod siano in 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 44sGloo è pronto per la gestione del traffico, creiamo un servizio Knative scalabile automaticamente (chiameremo kservice) e indirizziamo il traffico ad esso.
I servizi Knative forniscono un modo più semplice per distribuire applicazioni in Kubernetes rispetto al modello tradizionale Deployment+Service+Ingress. 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 userHo copiato questo in un file e poi l’ho applicato al mio cluster Kubernetes in questo modo:
kubectl apply -f ksvc.yaml -n defaultPossiamo esaminare le risorse create da Knative nel cluster dopo la distribuzione 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 68sIl Pod con la nostra immagine 'helloworld-go' si avvia al momento del deploy del kservice. Se non c'è traffico, il numero di pod verrà ridotto a zero. 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 TrueKnative configura il proprio ingress utilizzando una risorsa ‘ingress’ speciale nell'API interna di Knative. Gloo utilizza questa API come configurazione per fornire funzionalità simili a quelle di PaaS, inclusi il modello di distribuzione blue-green, l'applicazione automatica del TLS, i timeout e altre caratteristiche avanzate di routing.
Dopo un po' di tempo vediamo che i nostri pod sono scomparsi (poiché non c'era traffico in ingresso):
kubectl get pod -n default
Nessuna risorsa trovata.
kubectl get deployment -n default
NOME DESIDERATO ATTUALE UP-TO-DATE DISPONIBILE ETÀ
helloworld-go-fjp75-deployment 0 0 0 0 9m46sInfine proveremo a contattarli. Ottenere l'URL per il Proxy Knative è facile e senza problemi tramite glooctl:
glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80Senza un'installazione di glooctl si può controllare l'indirizzo e la porta nel servizio kube:
kubectl get svc -n gloo-system knative-external-proxy
NOME TIPO CLUSTER-IP EXTERNAL-IP PORTA(E) ETÀ
knative-external-proxy LoadBalancer 10.16.11.157 35.190.151.188 80:32168/TCP,443:30729/TCP 77mGeneriamo un po' di dati utilizzando cURL:
curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Ciao utente Knative!Knative fornisce una sorta di PaaS per gli sviluppatori sopra un Kubernetes ‘out of the box’, utilizzando un gateway API Gloo ad alte prestazioni e pienamente funzionale. Questa nota ha solo toccato superficilmente l'ampia gamma di funzionalità di Knative disponibili per la configurazione, oltre a funzionalità aggiuntive. Lo stesso vale per Gloo!
Nonostante Knative sia ancora un progetto giovane, il suo team rilascia nuove versioni ogni sei settimane, sono iniziate l'implementazione di funzionalità avanzate come l'autodeploy di TLS, l'autoscaling del pannello di controllo. C'è un'alta probabilità che, a seguito della collaborazione di numerose aziende cloud, e come base della nuova offerta Cloud Run di Google, Knative possa diventare l'opzione principale per organizzare calcolo serverless e PaaS in Kubernetes. Rimanete aggiornati!
Dalla redazione di SouthBridge
Ci interessa l'opinione dei lettori, quindi vi chiediamo di partecipare a un breve sondaggio riguardante i futuri articoli su Knative, Kubernetes e calcolo serverless:
Solo gli utenti registrati possono partecipare al sondaggio. , per favore.
Continuare a tradurre e scrivere articoli e guide su Knative e calcolo serverless?
Sì, per favore.
Grazie, non è necessario.
Hanno votato 28 utenti. 4 utenti si sono astenuti.
Fonte: habr.com
