Ces informations sont utiles pour les types d'utilisateurs suivants :
- Les utilisateurs qui débutent avec Knative serving
- Les opérateurs qui disposent déjà d'une expérience dans l'exécution de clusters GKE
- Les développeurs d'applications qui souhaitent en savoir plus sur l'intégration de Knative serving aux clusters Kubernetes pour concevoir de meilleures applications ou configurer leur application Knative serving
Composants de l'installation par défaut
Installez Knative Serving dans votre cluster afin de connecter et de gérer vos charges de travail sans état. Les composants Knative sont créés dans l'espace de noms knative-serving.
Knative serving utilise Cloud Service Mesh pour acheminer le trafic. Par défaut, Cloud Service Mesh installe les composants dans l'espace de noms istio-system.
Voici la liste des composants installés par Knative serving et Cloud Service Mesh:
Les composants installés par Knative serving dans l'espace de noms
knative-serving:- Activator : lorsque les pods font l'objet d'un scaling vertical à zéro ou sont surchargés de requêtes envoyées à la révision, l'activateur met temporairement les requêtes en file d'attente et envoie des métriques à l'autoscaler pour qu'il lance d'autres pods. Une fois que l'autoscaler a procédé au scaling de la révision en fonction des métriques reçues et des pods disponibles, l'activateur transfère les requêtes en file d'attente à la révision. L'activateur est un composant du plan de données. Les composants du plan de données gèrent toutes les fonctions et tous les processus de transfert du trafic utilisateur.
- Autoscaler : agrège et traite les métriques envoyées par l'activateur ainsi que par le conteneur du side-car proxy de file d'attente, qui est un composant du plan de données appliquant les limites de simultanéité des requêtes. L'autoscaler calcule ensuite la simultanéité constatée pour la révision et ajuste la taille du déploiement en fonction du nombre de pods souhaité. Lorsque les pods sont disponibles dans la révision, l'autoscaler est un composant du plan de contrôle. En revanche, lorsque les pods font l'objet d'un scaling vertical à zéro, l'autoscaler est un composant du plan de données.
- Contrôleur : crée et met à jour les ressources enfants de l'autoscaler et les objets Service. Le contrôleur est un composant du plan de contrôle. Les composants du plan de contrôle gèrent toutes les fonctions et tous les processus établissant le chemin de requête du trafic utilisateur.
- Collecteur de métriques : collecte les métriques des composants Knative serving, puis les transmet à Cloud Monitoring.
- Webhook : définit les valeurs par défaut, rejette les objets non valides et incohérents, et valide et mute les appels d'API Kubernetes envoyés aux ressources Knative serving. Le webhook est un composant du plan de contrôle.
Composants installés par Cloud Service Mesh exécutés dans l'espace de noms
istio-system:- Passerelle locale du cluster : équilibreur de charge du plan de données chargé de gérer le trafic interne entre deux services Knative serving. La passerelle locale du cluster n'est accessible qu'à partir de votre cluster GKE et n'enregistre pas de domaine externe pour empêcher l'exposition accidentelle d'informations privées ou de processus internes.
- Passerelle d'entrée Istio : équilibreur de charge du plan de données chargé de recevoir et gérer le trafic entrant provenant de l'extérieur du cluster, y compris le trafic provenant de réseaux externes ou internes.
- Istiod : configure la passerelle locale du cluster et la passerelle d'entrée Istio pour que les requêtes HTTP soient traitées aux points de terminaison appropriés. Istiod est un composant du plan de contrôle. Pour plus d'informations, consultez la page Istiod.
Les composants Knative serving sont mis à jour automatiquement avec les mises à jour du cluster du plan de contrôle GKE. Pour en savoir plus, consultez la page Versions de GKE disponibles.
Utilisation des ressources du cluster
L'installation initiale de Knative serving nécessite environ 1,5 processeur virtuel et 1 Go de mémoire pour votre cluster. Le nombre de nœuds dans votre cluster n'affecte pas les exigences en termes d'espace et de mémoire associées à une installation Knative serving.
Un activateur peut consommer des requêtes avec un maximum de 1 000 milliprocesseurs et 600 Mio de RAM. Lorsqu'un activateur existant ne peut pas gérer le nombre de requêtes entrantes, un activateur supplémentaire démarre, ce qui nécessite une réservation de 300 milliprocesseurs et 60 Mio de RAM.
Chaque pod créé par le service Knative serving crée un side-car proxy de file d'attente qui applique les limites de simultanéité des requêtes. Le proxy de file d'attente réserve 25 milliprocesseurs et n'a aucune réservation de mémoire. La consommation du proxy de file d'attente dépend du nombre de requêtes mises en file d'attente et de leur taille. Les ressources de processeur et de mémoire qu'il peut consommer ne sont pas limitées.
Créer un service
Knative serving étend Kubernetes en définissant un ensemble de définitions de ressources personnalisées (CRD) : service, révision, configuration et route. Ces CRD définissent et contrôlent le comportement de vos applications sur le cluster :
- Le service Knative serving est la ressource personnalisée de premier niveau définie par Knative serving. Il s'agit d'une application unique qui gère l'ensemble du cycle de vie de votre charge de travail. Votre service garantit que votre application dispose d'une route, d'une configuration et d'une nouvelle révision pour chaque mise à jour du service.
- La révision est un instantané immuable à un moment précis du code et de la configuration.
- La configuration conserve les paramètres actuels de votre dernière révision et enregistre l'historique de toutes les révisions précédentes. La modification d'une configuration crée une révision.
- La route définit un point de terminaison HTTP et l'associe à une ou plusieurs révisions vers lesquelles les requêtes sont transférées.
Lorsqu'un utilisateur crée un service Knative serving, les événements suivants se produisent :
L'objet de service Knative Serving définit les éléments suivants :
- Une configuration permettant de diffuser vos révisions
- Une révision immuable pour cette version de votre service
- Une route permettant de gérer la répartition du trafic spécifiée pour votre révision
L'objet route crée un objet VirtualService. L'objet VirtualService configure la passerelle d'entrée et la passerelle locale du cluster pour que le trafic de passerelle soit acheminé vers la révision appropriée.
L'objet de révision crée les composants de plan de contrôle suivants : un objet Service Kubernetes et un objet Déploiement.
La configuration réseau connecte l'activateur, l'autoscaler et les équilibreurs de charge de votre application.
Gestion des requêtes
Le schéma suivant présente une vue d'ensemble d'un chemin de requête possible pour le trafic utilisateur via les composants du plan de données de Knative serving sur un exemple de cluster Google Kubernetes Engine :
Le schéma suivant complète le schéma précédent pour fournir une vue détaillée du chemin de requête du trafic utilisateur, également décrit en détail ci-dessous :
Pour un chemin de requête Knative serving :
Le trafic arrive par :
- la passerelle d'entrée pour le trafic provenant de l'extérieur des clusters ;
- la passerelle locale du cluster pour le trafic interne aux clusters.
Le composant VirtualService, qui spécifie les règles de routage du trafic, configure les passerelles de sorte que le trafic utilisateur soit acheminé vers la révision appropriée.
Le service Kubernetes, un composant du plan de contrôle, détermine l'étape suivante du chemin de requête en fonction de la disponibilité des pods pour gérer le trafic :
S'il n'y a pas de pods dans la révision, les événements suivants se produisent :
- L'activateur met temporairement la requête reçue en file d'attente et envoie une métrique à l'autoscaler pour qu'il ajoute des pods.
- L'autoscaler effectue un scaling pour atteindre l'état souhaité des pods dans le déploiement.
- Le déploiement crée des pods pour que des requêtes supplémentaires puissent être reçues.
- L'activateur relance les requêtes envoyées au side-car proxy de file d'attente.
Si le service fait l'objet d'un scaling horizontal (des pods sont disponibles), le service Kubernetes envoie la requête au proxy side-car de file d'attente.
Le side-car proxy de file d'attente applique les paramètres de file d'attente de requêtes (monothread ou multithread) que le conteneur peut gérer simultanément.
Si le side-car proxy de file d'attente reçoit plus de requêtes qu'il ne peut en gérer, l'autoscaler crée davantage de pods pour que des requêtes supplémentaires puissent être traitées.
Le side-car proxy de file d'attente envoie le trafic au conteneur utilisateur.