Ces informations sont utiles pour les types d'utilisateurs suivants :
- Les utilisateurs qui débutent avec Cloud Run for Anthos
- 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 Cloud Run pour Anthos aux clusters Kubernetes afin de concevoir de meilleures applications ou de configurer leur application Cloud Run pour Anthos
Composants de l'installation par défaut
Lorsque vous installez Cloud Run pour Anthos en tant que module complémentaire de votre cluster Google Kubernetes Engine, les espaces de noms knative-serving et gke-system sont automatiquement créés. Les composants suivants sont déployés dans l'un de ces espaces de noms :
Composants exécutés dans l'espace de noms
knative-serving:- Activateur : 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.
- 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 Cloud Run pour Anthos. Le webhook est un composant du plan de contrôle.
Composants exécutés dans l'espace de noms
gke-system:- Passerelle locale du cluster : équilibreur de charge du plan de données gérant le trafic interne entre deux services Cloud Run pour Anthos. 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.
- Pilote Istio : 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. Le pilote Istio est un composant du plan de contrôle. Pour en savoir plus, consultez la page sur le pilote Istio.
Les composants Cloud Run pour Anthos 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 Cloud Run for Anthos 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 Cloud Run pour Anthos.
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 Cloud Run pour Anthos 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
Cloud Run pour Anthos complète 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 Cloud Run pour Anthos est la ressource personnalisée de premier niveau définie par Cloud Run pour Anthos. 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 Cloud Run pour Anthos, les événements suivants se produisent :
L'objet Service Cloud Run pour Anthos définit les éléments ci-dessous :
- 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 Cloud Run for Anthos sur un exemple de cluster Google Kubernetes Engine :
Le schéma suivant reprend le schéma ci-dessus 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 Cloud Run for Anthos :
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.