Kubernetes est sans aucun doute la plateforme dominante pour le déploiement de conteneurs. Elle offre la possibilité de gérer presque tout en utilisant ses API et des contrôleurs personnalisés qui étendent son API via des ressources personnalisées.
Cependant, l'utilisateur doit encore prendre des décisions détaillées sur la manière de déployer, configurer, gérer et mettre à l'échelle les applications. Les questions liées à la mise à l'échelle des applications, à la sécurité et au routage du trafic restent à la discrétion de l'utilisateur. C'est ce qui distingue Kubernetes des « plateformes en tant que service » (PaaS), telles que Cloud Foundry et Heroku.
Les plateformes disposent d'une interface utilisateur simplifiée, axée sur les développeurs d'applications, qui sont le plus souvent engagés dans la configuration d'applications individuelles. Le routage, le déploiement et les métriques sont gérés de manière transparente pour l'utilisateur par le système PaaS sous-jacent.
Le flux de travail « code source – livraison » est géré par le PaaS en créant une image de conteneur personnalisée, en la déployant, en configurant une nouvelle route et un sous-domaine DNS pour le trafic entrant. Tout cela est exécuté sur commande. git push.
Kubernetes fournit (intentionnellement) uniquement les blocs de base pour de telles plateformes, laissant à la communauté le soin de faire ce travail elle-même. Comme :
Kubernetes est une plateforme pour construire des plateformes. C'est le meilleur point de départ, mais pas la fin.
En conséquence, nous voyons une multitude de distributions Kubernetes, ainsi que des hébergeurs qui tentent de créer un PaaS pour Kubernetes, comme OpenShift et Rancher. Dans le contexte d'un marché Kube-PaaS en pleine expansion, Knative entre sur le ring, créé en juillet 2018 par Google et Pivotal.
Knative est le résultat d'une collaboration entre Google et Pivotal, avec le soutien limité d'autres entreprises, telles qu'IBM, RedHat et Solo.im. Il propose des fonctionnalités PaaS similaires pour Kubernetes avec un support de premier ordre pour les applications basées sur le calcul sans serveur. Contrairement aux distributions Kubernetes, Knative s'installe en tant que complément sur tout cluster Kubernetes compatible, et se configure via des ressources personnalisées.
Qu'est-ce que Knative ?
Knative est décrit comme « une plateforme basée sur Kubernetes pour le déploiement et la gestion de charges de travail à l'aide de calculs sans serveur modernes ». Knative, en se proclamant telle une plateforme, optimise automatiquement le dimensionnement des conteneurs proportionnellement aux requêtes HTTP simultanées. Les services non utilisés sont finalement réduits à zéro, offrant un dimensionnement à la demande dans un style de calcul sans serveur.
Knative se compose d'un ensemble de contrôleurs installés dans n'importe quel cluster Kubernetes et fournissant les fonctionnalités suivantes :
- assemblage d'applications conteneurisées à partir de code source (fourni par le composant Build),
- fournir l'accès au trafic entrant vers les applications (fourni par le composant Serving),
- livraison et dimensionnement automatique des applications à la demande (également fourni par le composant Serving),
- définition des sources d'événements déclenchant l'exécution des applications (fourni par le composant Eventing).
Le composant clé est Serving, qui fournit la livraison, le dimensionnement automatique et la gestion du passage du trafic pour les applications gérées. Après l'installation de Knative, l'accès complet à l'API Kubernetes demeure, permettant aux utilisateurs de gérer les applications de manière classique, tout en servant à déboguer les services Knative, utilisant les mêmes primitives API que ces services (modules, services, etc.).
Avec Serving, la routage blue-green du trafic est également automatisé, garantissant la répartition du trafic entre les nouvelles et anciennes versions de l'application lors de la fourniture d'une version mise à jour par l'utilisateur.
Knative dépend également de l'installation d'un contrôleur ingress compatible. Au moment de la rédaction de cet article, les suivants sont pris en charge : et . Il configurera l'ingress disponible pour router le trafic vers les applications gérées par Knative.
Istio Service Mesh peut être une dépendance importante pour les utilisateurs de Knative qui souhaitent l'essayer sans installer le tableau de bord Istio, car Knative dépend uniquement de la passerelle.
Pour cette raison, la plupart des utilisateurs préfèrent Gloo comme passerelle pour Knative, car elle offre un ensemble de fonctionnalités similaire à celui d'Istio (si l'on considère uniquement l'utilisation de Knative), tout en consommant beaucoup moins de ressources et en entraînant des coûts d'exploitation inférieurs.
Testons Knative en action sur notre stand. Je vais utiliser un cluster fraîchement installé, lancé dans GKE :
kubectl get namespace
NAME STATUS AGE
default Active 21h
kube-public Active 21h
kube-system Active 21hCommençons l'installation de Knative et Gloo. Cela peut être fait dans n'importe quel ordre :
# ставим 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
# ...Vérifions que tous les Pods sont en statut « 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 est prêt à router, créons un service Knative évolutif automatiquement (appelons-le kservice) et dirigeons-y le trafic.
Les services Knative offrent une manière plus simple de déployer des applications dans Kubernetes — par rapport au modèle habituel Deployment+Service+Ingress. Travaillons avec un exemple comme celui-ci :
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: Utilisateur KnativeJ'ai copié cela dans un fichier, puis je l'ai appliqué à mon cluster Kubernetes de cette manière :
kubectl apply -f ksvc.yaml -n defaultNous pouvons consulter les ressources créées par Knative dans le cluster après avoir déployé notre ‘helloworld-go’ kservice:
kubectl get pod -n default
NAME READY STATUS RESTARTS AGE
helloworld-go-fjp75-deployment-678b965ccb-sfpn8 2/2 Running 0 68sLe Pod avec notre image ‘helloworld-go’ se lance lors du déploiement du kservice. S'il n'y a pas de trafic, le nombre de pods sera réduit à zéro. Et inversement, si le nombre de requêtes simultanées dépasse une certaine valeur seuil configurable, le nombre de pods augmentera.
kubectl get ingresses.networking.internal.knative.dev -n default
NAME READY REASON
helloworld-go TrueKnative configure son ingress à l'aide d'une ressource ‘ingress’ spéciale dans l'API interne de Knative. Gloo utilise cette API comme sa configuration pour fournir les propriétés typiques d'un PaaS, y compris le modèle de déploiement blue-green, l'application automatique de TLS, les délais d'attente, et d'autres fonctionnalités avancées de routage.
Après un certain temps, nous constatons que nos pods ont disparu (en raison de l'absence de trafic entrant) :
kubectl get pod -n default
Aucune ressource trouvée.
kubectl get deployment -n default
NOM SOUHAITÉ ACTUEL À JOUR DISPONIBLE ÂGE
helloworld-go-fjp75-deployment 0 0 0 0 9m46sEnfin, nous allons essayer de les atteindre. Obtenir l'URL pour le proxy Knative est facile et sans effort grâce à glooctl:
glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80Sans installé glooctl vous pouvez voir l'adresse et le port dans le service kube :
kubectl get svc -n gloo-system knative-external-proxy
NOM TYPE CLUSTER-IP EXTERNAL-IP PORT(S) ÂGE
knative-external-proxy LoadBalancer 10.16.11.157 35.190.151.188 80:32168/TCP,443:30729/TCP 77mFaisons circuler quelques données avec cURL :
curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Bonjour utilisateur Knative !Knative fournit presque un PaaS pour les développeurs sur Kubernetes « prêt à l'emploi », en utilisant la passerelle API Gloo hautes performances et complète. Cette note n'effleure qu'un nombre considérable de fonctionnalités de Knative disponibles pour la configuration, ainsi que d'autres fonctions. Il en va de même pour Gloo !
Bien que Knative soit encore un projet jeune, son équipe publie de nouvelles versions toutes les six semaines, et la mise en place de fonctionnalités avancées, comme le déploiement automatique de TLS, le dimensionnement automatique du tableau de bord, a commencé. Il est fort probable qu'en raison de la collaboration de nombreuses entreprises cloud, ainsi qu'en tant que base de la nouvelle offre Cloud Run de Google, Knative puisse devenir une option de premier plan pour la mise en place de calculs sans serveur et de PaaS sur Kubernetes. Restez à l'écoute !
De la rédaction de SouthBridge
Nous sommes soucieux de l'opinion de nos lecteurs, c'est pourquoi nous vous invitons à participer à un court sondage concernant les futurs articles sur Knative, Kubernetes, et le calcul sans serveur :
Seuls les utilisateurs enregistrés peuvent participer au sondage. , s'il vous plaît.
Voudriez-vous que nous continuions à écrire des articles et des guides sur Knative et le calcul sans serveur ?
Oui, s'il vous plaît.
Merci, pas besoin.
28 utilisateurs ont voté. 4 utilisateurs se sont abstenus.
Source : habr.com
