Kubernetes est sans aucun doute devenue la plateforme dominante pour le déploiement de conteneurs. Il offre la possibilité de contrôler presque tout à l'aide de ses API et de ses contrôleurs personnalisés qui étendent ses API avec des ressources personnalisées.
Cependant, l'utilisateur doit toujours prendre des décisions détaillées sur la manière exacte de déployer, configurer, gérer et faire évoluer les applications. Les questions de mise à l'échelle, de protection et de flux de trafic des applications restent à la discrétion de l'utilisateur. Cela distingue Kubernetes des plates-formes classiques en tant que service (PaaS), telles que Cloud Foundry et Heroku.
Les plateformes disposent d'une interface utilisateur simplifiée et s'adressent aux développeurs d'applications qui sont le plus souvent impliqués dans la mise en place 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 de la source à l'expédition est géré par 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 lancé sur commande git push.
Kubernetes ne fournit (intentionnellement) que les éléments de base de ces plates-formes, laissant la communauté libre de faire le travail elle-même. Comment :
Kubernetes est une plateforme permettant de créer des plateformes. La meilleure position pour commencer, mais pas pour finir.
En conséquence, nous voyons un certain nombre de versions de Kubernetes, ainsi que des sociétés d'hébergement qui tentent de créer du PaaS pour Kubernetes, telles qu'OpenShift et Rancher. Au milieu du marché croissant du Kube-PaaS, Knative, fondée en juillet 2018 par Google et Pivotal, entre sur le ring.
Knative est le fruit d'une collaboration entre Google et Pivotal, avec l'aide d'autres sociétés telles qu'IBM, RedHat et Solo.im. Il offre des fonctionnalités PaaS similaires à Kubernetes avec une prise en charge de premier ordre pour les applications informatiques sans serveur. Contrairement aux versions Kubernetes, Knative est installé en tant que module complémentaire sur n'importe quel cluster Kubernetes compatible et configuré via les ressources utilisateur.
Qu’est-ce que Knative ?
Knative est décrit comme « une plate-forme basée sur Kubernetes pour fournir et gérer des charges de travail à l'aide d'une informatique sans serveur moderne ». Knative, tout en se présentant comme une telle plate-forme, met activement à l'échelle automatiquement les conteneurs proportionnellement aux requêtes HTTP simultanées. Les services inutilisés finissent par être réduits à zéro, offrant ainsi une mise à l'échelle à la demande de type sans serveur.
Knative se compose d'un ensemble de contrôleurs qui s'installent dans n'importe quel cluster Kubernetes et offrent les fonctionnalités suivantes :
- créer des applications conteneurisées à partir du code source (fourni par le composant Développer),
- donnant accès au trafic entrant aux applications (fourni par le composant Au moment de servir),
- livraison et mise à l'échelle automatique des applications à la demande (également assurée par le composant Au moment de servir),
- identifier les sources des événements conduisant aux lancements d'applications (fournies par le composant Concours complet).
Un composant clé est Serving, qui assure le provisionnement, la mise à l'échelle automatique et la gestion du trafic pour les applications gérées. Après avoir installé Knative, vous disposez toujours d'un accès complet à l'API Kubernetes, permettant aux utilisateurs de gérer les applications l'habituel manière, et sert également à déboguer les services Knative, en travaillant avec les mêmes primitives API que ces services utilisent (modules, services, etc.).
Grâce à Serving, le routage du trafic bleu-vert est également automatisé, garantissant ainsi la séparation du trafic entre les nouvelles et les anciennes versions de l'application lorsque l'utilisateur fournit une version mise à jour de l'application.
Knative lui-même dépend de l'installation d'un contrôleur d'entrée compatible. Au moment de la rédaction de cet article, cet article est pris en charge и . Il configurera l'entrée disponible pour acheminer le trafic vers les applications gérées par Knative.
Istio Service Mesh peut constituer une dépendance importante pour les utilisateurs de Knative souhaitant l'essayer sans installer le panneau de configuration Istio, car Knative ne dépend que de la passerelle.
Pour cette raison, la plupart des utilisateurs préfèrent Gloo comme passerelle vers Knative, offrant un ensemble de fonctionnalités similaire à celui d'Istio (dans le but d'utiliser uniquement Knative), tout en utilisant beaucoup moins de ressources et en ayant des coûts opérationnels inférieurs.
Testons Knative en action sur le stand. J'utiliserai un cluster fraîchement installé fonctionnant dans GKE :
kubectl get namespace
NAME STATUS AGE
default Active 21h
kube-public Active 21h
kube-system Active 21hCommençons par installer 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
# ...Nous vérifions que tous les Pods sont dans le statut « En cours d'exécution » :
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 pour le routage, créons un service Knative à mise à l'échelle automatique (appelons-le kservice) et acheminons le trafic vers celui-ci.
Les services Knative offrent un moyen plus simple de fournir des applications à Kubernetes que le modèle conventionnel Déploiement+Service+Ingress. Nous allons travailler avec cet exemple :
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 userJ'ai copié ceci dans un fichier, puis je l'ai appliqué à mon cluster Kubernetes de cette façon :
kubectl apply -f ksvc.yaml -n defaultNous pouvons visualiser les ressources créées par Knative dans le cluster après avoir livré 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' est lancé lorsque le kservice est déployé. S’il n’y a pas de trafic, le nombre de pods sera réduit à zéro. Et vice versa, si le nombre de requêtes simultanées dépasse un certain seuil configurable, le nombre de pods augmentera.
kubectl get ingresses.networking.internal.knative.dev -n default
NAME READY REASON
helloworld-go TrueKnative configure son entrée à l'aide d'une ressource spéciale « ingress » dans l'API interne de Knative. Gloo utilise cette API comme configuration pour fournir des fonctionnalités de type PaaS, notamment un modèle de déploiement bleu-vert, l'application automatique de TLS, des délais d'attente et d'autres fonctionnalités de routage avancées.
Au bout d'un certain temps, nous constatons que nos pods ont disparu (car il n'y avait pas de trafic entrant) :
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 9m46sEnfin, nous essaierons de les atteindre. Vous pouvez facilement et facilement obtenir l'URL de Knative Proxy en utilisant 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
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 77mAnalysons quelques données en utilisant cURL :
curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hello Knative user!Knative fournit un quasi-PaaS aux développeurs en plus de Kubernetes prêt à l'emploi en utilisant la passerelle API full-stack hautes performances de Gloo. Cet article n'a fait qu'effleurer la surface des nombreuses options de personnalisation et des fonctionnalités supplémentaires de Knative. Pareil avec Gloo !
Malgré le fait que Knative soit encore un jeune projet, son équipe publie de nouvelles versions toutes les six semaines et la mise en œuvre de fonctionnalités avancées a commencé, telles que le déploiement automatique de TLS et la mise à l'échelle automatique du panneau de contrôle. Il y a de fortes chances que, grâce à la collaboration entre plusieurs sociétés cloud et en tant que base de la nouvelle offre Cloud Run de Google, Knative devienne la principale option pour l'informatique sans serveur et le PaaS sur Kubernetes. Suivez l'actualité !
De la part des rédacteurs de SouthBridge
Les avis des lecteurs sont importants pour nous, c'est pourquoi nous vous demandons de participer à une courte enquête liée aux futurs articles sur Knative, Kubernetes et l'informatique sans serveur :
Seuls les utilisateurs enregistrés peuvent participer à l'enquête. s'il te plait.
Dois-je continuer à rédiger des articles et des guides sur l’informatique Knative et sans serveur ?
-
Oui s'il vous plait
-
Merci, non
28 utilisateurs ont voté. 4 utilisateurs se sont abstenus.
Source: habr.com