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
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
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.
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