Kubernetes est sans aucun doute devenu la plate-forme dominante pour le déploiement de conteneurs. Il offre la possibilité de gérer presque tout en utilisant ses API et ses contrôleurs utilisateur qui étendent son API via les ressources utilisateur.
Cependant, l'utilisateur doit encore prendre des décisions détaillées sur la façon de déployer, configurer, gérer et faire évoluer les applications. À la discrétion de l'utilisateur, des questions demeurent sur la mise à l'échelle de l'application, la protection, le passage du trafic. Cela distingue Kubernetes des «plates-formes en tant que service» (PaaS) conventionnelles, telles que Cloud Foundry et Heroku.
Les plates-formes ont une interface utilisateur simplifiée, axée sur les développeurs d'applications qui sont le plus souvent impliqués dans la personnalisation d'applications individuelles. Le routage, le déploiement et les métriques transparentes pour l'utilisateur sont gérés par le système PaaS sous-jacent.
Le flux de travail de livraison source 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 déclenché par la commande git push .
Kubernetes (intentionnellement) ne fournit que les blocs de construction de base pour de telles plates-formes, donnant à la communauté la possibilité de faire ce travail par ses propres moyens. Comme l'a déclaré Kelsey Hightower :
Kubernetes est une plate-forme de création de plates-formes. La meilleure position pour commencer, mais pas pour terminer.
En conséquence, nous voyons un tas d'assemblages Kubernetes, ainsi que des sociétés d'hébergement qui essaient de créer PaaS pour Kubernetes, par exemple, OpenShift et Rancher. Dans le contexte du marché en croissance du Kube-PaaS, Knative, créé en juillet 2018 par Google et Pivotal, fait son entrée sur le ring.
Knative était une collaboration entre Google et Pivotal, avec peu de collaboration d'autres sociétés telles que IBM, RedHat et Solo.im. Il offre des fonctionnalités PaaS similaires pour Kubernetes avec une prise en charge d'applications informatiques sans serveur de première classe. Contrairement aux assemblys Kubernetes, Knative est installé en tant que module complémentaire à tout cluster Kubernetes compatible et est 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 les charges de travail avec l'informatique sans serveur moderne». En se déclarant être une telle plate-forme, Knative met automatiquement à l'échelle automatiquement les conteneurs proportionnellement aux requêtes HTTP simultanées. Les services inutilisés sont finalement mis à l'échelle à zéro, offrant une mise à l'échelle à la demande dans le style de l'informatique sans serveur.
Knative se compose d'un ensemble de contrôleurs installés dans n'importe quel cluster Kubernetes et offrant les fonctionnalités suivantes:
- assemblage d'applications conteneurisées à partir du code source (fourni par le composant Build ),
- fournir l'accès au trafic entrant aux applications (fourni par le composant Serveur ),
- livraison et mise à l'échelle automatique des applications à la demande (également fournies par le composant Serving ),
- détermination des sources d'événements conduisant au lancement des applications (fournies par le composant Eventing ).
Un composant clé est le service, qui fournit la livraison, la mise à l'échelle automatique et le contrôle du trafic pour les applications gérées. Après l'installation de Knative, l'accès complet à l'API Kubernetes est toujours maintenu, ce qui permet aux utilisateurs de gérer les applications de la manière habituelle , et sert également à déboguer les services Knative en travaillant avec les mêmes primitives d'API que ces services utilisent (modules, services, etc.).
Le service automatise également le routage du trafic bleu-vert, assurant 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, Gloo API Gateway et Istio Service Mesh sont pris en charge. Il configurera l'entrée disponible pour acheminer le trafic vers les applications pilotées par Knative.
Istio Service Mesh peut devenir une grande dépendance pour les utilisateurs de Knative qui souhaitent 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, qui fournit un ensemble similaire de fonctionnalités avec Istio (si nous parlons de l'objectif d'utiliser uniquement Knative), ainsi que d'utiliser beaucoup moins de ressources et de réduire les coûts d'exploitation.
Vérifions 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 21h
Nous procédons à 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érifiez que tous les pods sont à l'état "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 44s
Gloo est prêt pour le routage, créons un service Knative évolutif automatiquement (appelons-le kservice) et dirigez-le vers lui.
Les services Knative offrent un moyen plus simple de fournir des applications à Kubernetes - par rapport au modèle régulier Deployment + Service + Ingress. Nous allons travailler avec un tel 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 user
J'ai copié ceci dans un fichier, puis l'ai appliqué à mon cluster Kubernetes de cette façon:
kubectl apply -f ksvc.yaml -n default
Nous pouvons voir les ressources créées par Knative dans le cluster après la livraison de notre kservice «helloworld-go»:
kubectl get pod -n default NAME READY STATUS RESTARTS AGE helloworld-go-fjp75-deployment-678b965ccb-sfpn8 2/2 Running 0 68s
Le pod avec notre image «helloworld-go» démarre lorsque vous déployez kservice. S'il n'y a pas de trafic, le nombre de pods sera réduit à zéro. Et vice versa, si le nombre de demandes simultanées dépasse une certaine valeur de seuil personnalisée, le nombre de pods augmentera.
kubectl get ingresses.networking.internal.knative.dev -n default NAME READY REASON helloworld-go True
Knative configure son entrée à l'aide d'une ressource spéciale «entrée» dans l'API interne Knative. Gloo utilise cette API comme configuration pour exposer les propriétés inhérentes à PaaS, y compris le modèle de déploiement bleu-vert, TLS automatique, les délais d'expiration et d'autres fonctionnalités de routage avancées.
Après un certain temps, nous voyons 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 9m46s
Enfin, nous essaierons de les contacter. Obtenir des URL pour Knative Proxy est facile et facile avec glooctl :
glooctl proxy url --name knative-external-proxy http://35.190.151.188:80
Sans glooctl installé, glooctl pouvez espionner 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 77m
Exécutez un peu de données avec cURL:
curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188 Hello Knative user!
Knative fournit des développeurs quasi-PaaS en plus de la boîte de Kubernetes, en utilisant la passerelle API hautes performances et complète de Gloo. Cette note n'a que légèrement touché le nombre important de fonctionnalités Knative disponibles pour la personnalisation, ainsi que des fonctionnalités supplémentaires. De même avec Gloo!
Malgré le fait que Knative soit encore un projet jeune, son équipe publie de nouvelles versions toutes les six semaines, la mise en œuvre de fonctions avancées a commencé, par exemple, le déploiement automatique de TLS, la mise à l'échelle automatique du panneau de contrôle. Il est très probable qu'en raison de la coopération entre de nombreuses sociétés de cloud computing, ainsi que de la base de la nouvelle offre Cloud Run de Google, Knative devienne la principale option pour organiser l'informatique sans serveur et le PaaS dans Kubernetes. Suivez l'actualité!
Depuis SouthBridge
L'avis des lecteurs est important pour nous, nous vous demandons donc de participer à une petite enquête liée aux futurs articles sur Knative, Kubernetes, l'informatique sans serveur: