Red Hat Summit2.2. Aperçu des responsabilités pour Red Hat OpenShift Service sur AWS
Cette documentation décrit Red Hat, Amazon Web Services (AWS) et les responsabilités des clients pour le service géré Red Hat OpenShift sur AWS (ROSA).
2.2.1. Des responsabilités partagées pour Red Hat OpenShift Service sur AWS
Alors que Red Hat et Amazon Web Services (AWS) gèrent le service Red Hat OpenShift sur les services AWS, le client partage certaines responsabilités. Le service OpenShift Red Hat sur les services AWS sont accessibles à distance, hébergés sur des ressources cloud publiques, créés dans des comptes AWS appartenant à des clients, et ont une plate-forme sous-jacente et une sécurité des données qui appartient à Red Hat.
Lorsque le rôle de cluster-admin est ajouté à un utilisateur, consultez les responsabilités et les notes d’exclusion dans l’annexe 4 de l’accord d’entreprise Red Hat (Services d’abonnement en ligne).
| A) Ressources | Gestion des incidents et des opérations | Gestion du changement | Accès et autorisation d’identité | Conformité à la sécurité et à la réglementation | La reprise après sinistre |
|---|---|---|---|---|---|
| Données du client | Client | Client | Client | Client | Client |
| Applications client | Client | Client | Client | Client | Client |
| Les services des développeurs | Client | Client | Client | Client | Client |
| La surveillance de la plate-forme | Chapeau rouge | Chapeau rouge | Chapeau rouge | Chapeau rouge | Chapeau rouge |
| L’exploitation forestière | Chapeau rouge | Chapeau rouge et client | Chapeau rouge et client | Chapeau rouge et client | Chapeau rouge |
| La mise en réseau des applications | Chapeau rouge et client | Chapeau rouge et client | Chapeau rouge et client | Chapeau rouge | Chapeau rouge |
| La mise en réseau de clusters | Chapeau rouge [1] | Chapeau rouge et client [2] | Chapeau rouge et client | Chapeau rouge [1] | Chapeau rouge [1] |
| Gestion des réseaux virtuels | Chapeau rouge et client | Chapeau rouge et client | Chapeau rouge et client | Chapeau rouge et client | Chapeau rouge et client |
| Gestion virtuelle du calcul (plan de contrôle, infrastructure et nœuds ouvriers) | Chapeau rouge | Chapeau rouge | Chapeau rouge | Chapeau rouge | Chapeau rouge |
| La version du cluster | Chapeau rouge | Chapeau rouge et client | Chapeau rouge | Chapeau rouge | Chapeau rouge |
| Gestion des capacités | Chapeau rouge | Chapeau rouge et client | Chapeau rouge | Chapeau rouge | Chapeau rouge |
| Gestion du stockage virtuel | Chapeau rouge | Chapeau rouge | Chapeau rouge | Chapeau rouge | Chapeau rouge |
| Logiciel AWS (services AWS publics) | AWS | AWS | AWS | AWS | AWS |
| Infrastructure mondiale hardware/AWS | AWS | AWS | AWS | AWS | AWS |
- Lorsque le client choisit d’utiliser son propre plugin CNI, la responsabilité revient au client.
- Le client doit configurer son pare-feu pour permettre l’accès aux domaines et ports OpenShift et AWS requis avant que le cluster ne soit mis en place. En savoir plus, voir « Prérequis du pare-feu AWS ».
2.2.3. Examen et notifications des groupes d’action
Les notifications de cluster sont des messages sur l’état, la santé ou les performances de votre cluster.
Les notifications de cluster sont la principale façon dont Red Hat Site Reliability Engineering (SRE) communique avec vous sur la santé de votre cluster géré. Le SRE peut également utiliser des notifications de cluster pour vous inviter à effectuer une action afin de résoudre ou d’empêcher un problème avec votre cluster.
Les propriétaires de clusters et les administrateurs doivent régulièrement examiner et agir les notifications de clusters pour s’assurer que les clusters restent en bonne santé et pris en charge.
Dans l’onglet Historique des clusters de votre cluster, vous pouvez afficher les notifications de cluster dans la console de cloud hybride Red Hat. Par défaut, seul le propriétaire du cluster reçoit des notifications de cluster sous forme d’e-mails. Lorsque d’autres utilisateurs doivent recevoir des e-mails de notification en cluster, ajoutez chaque utilisateur comme contact de notification pour votre cluster.
2.2.3.1. La politique de notification par groupe
Les notifications de cluster sont conçues pour vous tenir informé de la santé de votre cluster et des événements à fort impact qui l’affectent.
La plupart des notifications de cluster sont générées et envoyées automatiquement pour vous assurer que vous êtes immédiatement informé des problèmes ou des changements importants à l’état de votre cluster.
Dans certaines situations, Red Hat Site Reliability Engineering (SRE) crée et envoie des notifications de cluster pour fournir un contexte supplémentaire et des conseils pour un problème complexe.
Les notifications de cluster ne sont pas envoyées pour les événements à faible impact, les mises à jour de sécurité à faible risque, les opérations et la maintenance de routine, ou les problèmes transitoires mineurs qui sont rapidement résolus par SRE.
Les services Red Hat envoient automatiquement des notifications lorsque:
- Les contrôles de surveillance de la santé ou de vérification de l’environnement à distance détectent un problème dans votre cluster, par exemple lorsqu’un nœud de travail a peu d’espace disque.
- Des événements importants du cycle de vie des clusters se produisent, par exemple, lorsque la maintenance ou les mises à niveau programmées commencent, ou que les opérations de cluster sont touchées par un événement, mais ne nécessitent pas d’intervention du client.
- D’importants changements de gestion des clusters se produisent, par exemple, lorsque la propriété de clusters ou le contrôle administratif est transféré d’un utilisateur à un autre.
- L’abonnement à votre cluster est modifié ou mis à jour, par exemple lorsque Red Hat met à jour les conditions d’abonnement ou les fonctionnalités disponibles pour votre cluster.
La SRE crée et envoie des notifications lorsque:
- L’incident entraîne une dégradation ou une panne qui affecte la disponibilité ou les performances de votre cluster, par exemple, votre fournisseur de cloud a une panne régionale. La SRE envoie des notifications ultérieures pour vous informer de l’état d’avancement de la résolution des incidents et lorsque l’incident est résolu.
- Des failles de sécurité, des failles de sécurité ou des activités inhabituelles sont détectées sur votre cluster.
- Le Red Hat détecte que les changements que vous avez apportés sont en train de créer ou peuvent entraîner une instabilité des clusters.
- Le Red Hat détecte que vos charges de travail causent une dégradation des performances ou une instabilité dans votre cluster.
2.2.4. Gestion des incidents et des opérations
Le Red Hat est responsable de la supervision des composants de service requis pour le réseau de plate-forme par défaut. AWS est responsable de la protection de l’infrastructure matérielle qui exécute tous les services offerts dans AWS Cloud. Le client est responsable de la gestion des incidents et des opérations des données d’application client et de tout réseau personnalisé que le client a configuré pour le réseau cluster ou le réseau virtuel.
| A) Ressources | Les responsabilités en matière de service | Les responsabilités du client |
|---|---|---|
| La mise en réseau des applications | Chapeau rouge
|
|
| La mise en réseau de clusters | Chapeau rouge
|
|
| Gestion des réseaux virtuels | Chapeau rouge
|
|
| Gestion du stockage virtuel | Chapeau rouge
|
|
| La surveillance de la plate-forme | Chapeau rouge
| |
| Gestion des incidents | Chapeau rouge
|
|
| Infrastructure et résilience des données | Chapeau rouge
|
|
| Capacité des clusters | Chapeau rouge
| |
| Logiciel AWS (services AWS publics) | AWS
|
|
| Infrastructure mondiale hardware/AWS | AWS
|
|
2.2.4.1. La surveillance de la plate-forme
Les journaux d’audit de plate-forme sont transmis en toute sécurité à un système centralisé d’informations de sécurité et de surveillance des événements (SIEM), où ils peuvent déclencher des alertes configurées à l’équipe SRE et sont également soumis à un examen manuel. Les journaux d’audit sont conservés dans le système SIEM pendant un an. Les journaux d’audit d’un cluster donné ne sont pas supprimés au moment où le cluster est supprimé.
2.2.4.2. Gestion des incidents
L’incident est un événement qui entraîne une dégradation ou une panne d’un ou de plusieurs services Red Hat. L’incident peut être soulevé par un client ou un membre de l’expérience client et de l’engagement (CEE) par le biais d’un dossier d’assistance, directement par le système centralisé de surveillance et d’alerte, ou directement par un membre de l’équipe SRE.
En fonction de l’impact sur le service et le client, l’incident est classé en termes de gravité.
Lors de la gestion d’un nouvel incident, Red Hat utilise le flux de travail général suivant:
- Le premier intervenant de SRE est alerté d’un nouvel incident et commence une enquête initiale.
- Après l’enquête initiale, l’incident est assigné à un responsable de l’incident, qui coordonne les efforts de rétablissement.
- Le responsable de l’incident gère toute communication et coordination autour de la récupération, y compris les notifications pertinentes et les mises à jour des cas d’assistance.
- L’incident est récupéré.
- L’incident est documenté et une analyse des causes profondes (RCA) est effectuée dans les 5 jours ouvrables suivant l’incident.
- L’ébauche du document RCA sera communiquée au client dans les 7 jours ouvrables suivant l’incident.
Le Red Hat aide également les incidents de clients soulevés par des cas d’assistance. Le chapeau rouge peut aider aux activités, y compris, mais sans s’y limiter:
- Collecte médico-légale, y compris l’isolement du calcul virtuel
- Guide de la collection d’images de calcul
- Fournir des journaux d’audit recueillis
2.2.4.3. Capacité des clusters
L’impact d’une mise à niveau du cluster sur la capacité est évalué dans le cadre du processus d’essai de mise à niveau afin de s’assurer que la capacité n’est pas affectée négativement par de nouveaux ajouts au cluster. Lors d’une mise à niveau de cluster, des nœuds de travail supplémentaires sont ajoutés pour s’assurer que la capacité totale du cluster est maintenue pendant le processus de mise à niveau.
Les évaluations des capacités du personnel de Red Hat SRE se produisent également en réponse aux alertes du cluster, après que les seuils d’utilisation soient dépassés pendant une certaine période. De telles alertes peuvent également entraîner une notification au client.
2.2.5. Gestion du changement
Cette section décrit les stratégies sur la façon dont les changements de cluster et de configuration, les correctifs et les versions sont gérés.
Il incombe à Red Hat de modifier l’infrastructure et les services de cluster que le client contrôlera, ainsi que de maintenir les versions des nœuds d’avion de contrôle, des nœuds et des services d’infrastructure et des nœuds de travail. AWS est responsable de la protection de l’infrastructure matérielle qui exécute tous les services offerts dans AWS Cloud. Le client est responsable d’initier des demandes de changement d’infrastructure et d’installer et de maintenir des services et des configurations de réseau optionnels sur le cluster, ainsi que toutes les modifications apportées aux données client et aux applications client.
2.2.5.1. Changements initiés par le client
Il est possible d’initier des modifications en utilisant des fonctionnalités en libre-service telles que le déploiement de clusters, la mise à l’échelle des nœuds de travail ou la suppression de clusters.
L’historique des changements est capturé dans la section Historique des clusters dans l’onglet Aperçu OpenShift Cluster Manager, et est disponible pour vous. L’historique des changements comprend, sans s’y limiter, les journaux des changements suivants:
- Ajout ou suppression de fournisseurs d’identité
- Ajout ou suppression d’utilisateurs vers ou à partir du groupe admins dédiés
- Dimensionnement des nœuds de calcul du cluster
- Dimensionnement de l’équilibreur de charge du cluster
- Dimensionnement du stockage persistant du cluster
- Amélioration du cluster
Il est possible d’implémenter une exclusion de maintenance en évitant les changements dans OpenShift Cluster Manager pour les composants suivants:
- La suppression d’un cluster
- Ajout, modification ou suppression de fournisseurs d’identité
- Ajout, modification ou suppression d’un utilisateur d’un groupe élevé
- Installation ou suppression des add-ons
- La modification des configurations de réseau de clusters
- Ajout, modification ou suppression de pools de machines
- Activer ou désactiver la surveillance de la charge de travail des utilisateurs
- Lancement d’une mise à niveau
Afin de faire respecter l’exclusion de la maintenance, assurez-vous que les politiques d’autoscaling ou de mise à niveau automatique du pool de machines ont été désactivées. Après que l’exclusion de maintenance a été levée, procéder à l’activation automatique de la mise à l’échelle de la machine ou des politiques de mise à niveau automatique comme souhaité.
2.2.5.2. Changements initiés par Red Hat
L’ingénierie de fiabilité du site Red Hat (SRE) gère l’infrastructure, le code et la configuration de Red Hat OpenShift Service sur AWS à l’aide d’un flux de travail GitOps et de pipelines CI/CD entièrement automatisés. Ce processus permet à Red Hat d’introduire en toute sécurité des améliorations de service sur une base continue sans impact négatif sur les clients.
Chaque changement proposé fait l’objet d’une série de vérifications automatisées dès l’enregistrement. Les changements sont ensuite déployés dans un environnement de mise en scène où ils subissent des tests d’intégration automatisés. Enfin, des changements sont déployés dans l’environnement de production. Chaque étape est entièrement automatisée.
L’examinateur autorisé doit approuver l’avancement à chaque étape. L’examinateur ne peut pas être la même personne qui a proposé le changement. Les modifications et approbations sont entièrement vérifiables dans le cadre du flux de travail GitOps.
Certaines modifications sont publiées à la production progressivement, en utilisant des drapeaux de fonctionnalités pour contrôler la disponibilité de nouvelles fonctionnalités pour des clusters ou des clients spécifiés.
2.2.5.3. Gestion des patchs
Le logiciel OpenShift Container Platform et l’image du système d’exploitation immuable Red Hat CoreOS (RHCOS) sous-jacente sont corrigés pour les bogues et les vulnérabilités dans les mises à niveau régulières du flux z. En savoir plus sur l’architecture RHCOS dans la documentation OpenShift Container Platform.
2.2.5.4. Gestion des libérations
Le Red Hat ne met pas automatiquement à niveau vos clusters. Il est possible de programmer la mise à niveau des clusters à intervalles réguliers (mise à niveau récurrente) ou une seule fois (mise à niveau individuelle) à l’aide de la console Web OpenShift Cluster Manager. Le Red Hat pourrait mettre à niveau avec force un cluster vers une nouvelle version z-stream seulement si le cluster est affecté par un CVE d’impact critique.
Étant donné que les autorisations requises peuvent changer entre les versions y-stream, les politiques peuvent devoir être mises à jour avant qu’une mise à jour puisse être effectuée. Donc, vous ne pouvez pas planifier une mise à niveau récurrente sur les clusters ROSA avec STS.
Consultez l’historique de tous les événements de mise à niveau de cluster dans la console Web OpenShift Cluster Manager. Consultez la politique sur le cycle de vie pour plus d’informations sur les communiqués.
| A) Ressources | Les responsabilités en matière de service | Les responsabilités du client |
|---|---|---|
| L’exploitation forestière | Chapeau rouge
|
|
| La mise en réseau des applications | Chapeau rouge
|
|
| La mise en réseau de clusters | Chapeau rouge
|
|
| Gestion des réseaux virtuels | Chapeau rouge
|
|
| Gestion de calcul virtuel | Chapeau rouge
|
|
| La version du cluster | Chapeau rouge
|
|
| Gestion des capacités | Chapeau rouge
|
|
| Gestion du stockage virtuel | Chapeau rouge
|
|
| Logiciel AWS (services AWS publics) | AWS Calcul : Fournir le service Amazon EC2, utilisé pour l’avion de contrôle ROSA, l’infrastructure et les nœuds de travail. Le stockage: Fournir Amazon EBS, utilisé par ROSA pour fournir le stockage de nœuds locaux et le stockage en volume persistant pour le cluster. Stockage: Fournissez Amazon S3, utilisé pour le registre d’images intégré du service ROSA. Fournir les services AWS Cloud suivants, utilisés par ROSA pour répondre aux besoins d’infrastructure de réseau virtuel:
Fournir les services AWS suivants, que les clients peuvent éventuellement intégrer avec ROSA:
|
|
| Infrastructure mondiale hardware/AWS | AWS
|
|
2.2.6. Conformité à la sécurité et à la réglementation
Le tableau suivant présente les responsabilités en matière de conformité en matière de sécurité et de réglementation:
| A) Ressources | Les responsabilités en matière de service | Les responsabilités du client |
|---|---|---|
| L’exploitation forestière | Chapeau rouge
|
|
| Gestion des réseaux virtuels | Chapeau rouge
|
|
| Gestion du stockage virtuel | Chapeau rouge
|
|
| Gestion de calcul virtuel | Chapeau rouge
|
|
| Logiciel AWS (services AWS publics) | AWS Calcul: Secure Amazon EC2, utilisé pour le plan de contrôle ROSA, l’infrastructure et les nœuds de travail. Consultez la sécurité de l’infrastructure dans Amazon EC2 dans le Guide de l’utilisateur Amazon EC2. Amazon Elastic Block Store (EBS), utilisé pour le plan de contrôle ROSA, l’infrastructure et les volumes de nœuds de travail, ainsi que les volumes persistants de Kubernetes. Cliquez ici pour plus d’informations sur la protection des données dans Amazon EC2 dans le Guide de l’utilisateur Amazon EC2. Le stockage: Fournissez AWS KMS, que ROSA utilise pour chiffrer les volumes de plan de contrôle, d’infrastructure et de nœuds de travail et les volumes persistants. Consultez le chiffrement Amazon EBS dans le Guide de l’utilisateur Amazon EC2. Amazon S3, utilisé pour le registre intégré d’images de conteneurs du service ROSA. Consultez la sécurité Amazon S3 dans le guide de l’utilisateur S3. Fournir des capacités et des services de sécurité pour augmenter la confidentialité et contrôler l’accès au réseau sur l’infrastructure mondiale AWS, y compris les pare-feu réseau intégrés dans Amazon VPC, les connexions réseau privées ou dédiées, et le cryptage automatique de tout le trafic sur les réseaux mondiaux et régionaux AWS entre les installations sécurisées AWS. Consultez le modèle de responsabilité partagée AWS et la sécurité de l’infrastructure dans l’introduction au livre blanc AWS Security. |
|
| Infrastructure mondiale hardware/AWS | AWS
|
|
2.2.7. La reprise après sinistre
La reprise après sinistre comprend la sauvegarde des données et de la configuration, la reproduction des données et la configuration dans l’environnement de reprise après sinistre, et le basculement sur les événements de catastrophe.
Le service OpenShift Red Hat sur AWS (ROSA) fournit une reprise après sinistre pour les défaillances qui se produisent au niveau de la zone de pod, du nœud de travail, du nœud d’infrastructure, du nœud d’avion de contrôle et de la zone de disponibilité.
La récupération après sinistre exige que le client utilise les meilleures pratiques pour déployer des applications, du stockage et des clusters hautement disponibles, tels que le déploiement d’une zone unique ou le déploiement multizone, pour tenir compte du niveau de disponibilité souhaité.
En cas de panne d’une zone ou d’une zone de disponibilité, un groupe unique n’assurera pas d’évitement ou de reprise en cas de catastrophe. De multiples clusters à zone unique avec basculement entretenu par le client peuvent tenir compte des pannes à la zone ou au niveau régional.
En cas de panne totale de la région, un groupe multizones ne permettra pas d’éviter les catastrophes ou de se remettre en état. De multiples clusters multizones avec basculement entretenu par le client peuvent tenir compte des pannes au niveau régional.
| A) Ressources | Les responsabilités en matière de service | Les responsabilités du client |
|---|---|---|
| Gestion des réseaux virtuels | Chapeau rouge
|
|
| Gestion du stockage virtuel | Chapeau rouge
|
|
| Gestion de calcul virtuel | Chapeau rouge
|
|
| Logiciel AWS (services AWS publics) | AWS Calcul : Fournir des fonctionnalités Amazon EC2 qui prennent en charge la résilience des données telles que les instantanés Amazon EBS et Amazon EC2 Auto Scaling. Consultez Résilience dans Amazon EC2 dans le Guide de l’utilisateur EC2. Fournir la possibilité pour le service ROSA et les clients de sauvegarder le volume Amazon EBS sur le cluster via des instantanés de volume Amazon EBS. Stockage: Pour des informations sur les fonctionnalités Amazon S3 qui prennent en charge la résilience des données, voir Resilience dans Amazon S3. La mise en réseau : Pour obtenir des informations sur les fonctionnalités Amazon VPC qui prennent en charge la résilience des données, consultez Resilience dans Amazon Virtual Private Cloud dans le Guide de l’utilisateur Amazon VPC. |
|
| Infrastructure mondiale hardware/AWS | AWS
|
|
2.2.8. Les ressources gérées par Red Hat
2.2.8.1. Aperçu général
Ce qui suit couvre tous les services Red Hat OpenShift sur les ressources AWS qui sont gérées ou protégées par l’équipe de la plate-forme d’ingénierie de fiabilité des services (SRE-P). Les clients ne devraient pas essayer de changer ces ressources, car cela peut conduire à une instabilité des clusters.
2.2.8.2. Des ressources gérées
La liste suivante affiche le service Red Hat OpenShift sur les ressources AWS gérées par OpenShift Hive, le système centralisé de gestion de la configuration de la flotte. Ces ressources s’ajoutent aux ressources OpenShift Container Platform créées lors de l’installation. « OpenShift Hive tente continuellement de maintenir la cohérence dans tous les services OpenShift Red Hat sur les clusters AWS. Les modifications apportées au service OpenShift de Red Hat sur les ressources AWS doivent être effectuées via OpenShift Cluster Manager afin que OpenShift Cluster Manager et Hive soient synchronisés. Contactez ocm-feedback@redhat.com si OpenShift Cluster Manager ne prend pas en charge la modification des ressources en question.
Exemple 2.1. Liste des ressources gérées par Red Hat
2.2.8.3. Le Red Hat OpenShift Service sur AWS core namespaces
Le service Red Hat OpenShift sur AWS core namespaces est installé par défaut lors de l’installation du cluster.
Exemple 2.2. Liste des espaces de noms principaux
2.2.8.4. Le Red Hat OpenShift Service sur AWS add-on namespaces
Le Red Hat OpenShift Service sur les add-ons AWS sont des services disponibles pour l’installation après l’installation du cluster. Ces services supplémentaires incluent Red Hat OpenShift Dev Spaces, Red Hat OpenShift API Management et Cluster Logging Operator. Les modifications apportées aux ressources dans les espaces de noms suivants peuvent être remplacées par l’add-on lors des mises à niveau, ce qui peut conduire à des configurations non prises en charge pour la fonctionnalité add-on.
Exemple 2.3. Liste des espaces de noms gérés par add-on
2.2.8.5. Le Red Hat OpenShift Service sur AWS valide les webhooks
Le service Red Hat OpenShift sur AWS validant les webhooks est un ensemble de contrôles d’admission dynamiques maintenus par l’équipe OpenShift SRE. Ces rappels HTTP, également connus sous le nom de webhooks, sont appelés à divers types de requêtes pour assurer la stabilité des clusters. La liste suivante décrit les différents webhooks avec des règles contenant les opérations enregistrées et les ressources qui sont contrôlées. La tentative de contourner ces webhooks valides pourrait affecter la stabilité et la supportabilité du cluster.
Exemple 2.4. Liste des webhooks de validation
2.2.9. Autres responsabilités client pour les données et les applications
Le client est responsable des applications, des charges de travail et des données qu’ils déploient dans Red Hat OpenShift Service sur AWS. Cependant, Red Hat et AWS fournissent divers outils pour aider le client à gérer les données et les applications sur la plateforme.
| A) Ressources | Chapeau rouge et AWS | Les responsabilités du client |
|---|---|---|
| Données du client | Chapeau rouge
AWS
|
|
| Applications client | Chapeau rouge
AWS
|
|
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}