Chapitre 17. Débuter avec ROSA
17.1. Tutoriel: Qu’est-ce que ROSA Copier lienLien copié sur presse-papiers!
Le service OpenShift Red Hat sur AWS (ROSA) est une plateforme d’applications clé en main entièrement gérée qui vous permet de vous concentrer sur ce qui compte le plus, en fournissant de la valeur à vos clients en créant et en déployant des applications. Les experts de Red Hat et AWS SRE gèrent la plate-forme sous-jacente afin que vous n’ayez pas à vous soucier de la gestion de l’infrastructure. La ROSA fournit une intégration transparente avec une large gamme de services de calcul AWS, de bases de données, d’analyse, d’apprentissage automatique, de réseautage, de mobile et d’autres services afin d’accélérer la création et la fourniture d’expériences différenciées à vos clients.
Le ROSA utilise AWS Security Token Service (STS) pour obtenir des informations d’identification pour gérer l’infrastructure de votre compte AWS. AWS STS est un service Web mondial qui crée des informations d’identification temporaires pour les utilisateurs IAM ou les utilisateurs fédérés. La ROSA s’en sert pour attribuer des informations d’identification de sécurité à court terme et à privilèges limités. Ces informations d’identification sont associées aux rôles IAM qui sont spécifiques à chaque composant qui effectue des appels API AWS. Cette méthode s’harmonise avec les principes du moindre privilège et des pratiques sécurisées dans la gestion des ressources de service cloud. L’outil d’interface de ligne de commande ROSA (CLI) gère les informations d’identification STS qui sont assignées pour des tâches uniques et agit sur les ressources AWS dans le cadre de la fonctionnalité OpenShift.
17.1.1. Caractéristiques clés de ROSA Copier lienLien copié sur presse-papiers!
- Accès et utilisation de Red Hat OpenShift à la demande grâce à une expérience d’intégration en libre-service via la console de gestion AWS.
- Des prix flexibles et basés sur la consommation : Évoluez en fonction des besoins de votre entreprise et payez au fur et à mesure de la flexibilité des prix et d’un modèle de facturation horaire ou annuel à la demande.
- Facture unique pour l’utilisation de Red Hat OpenShift et AWS : les clients recevront une seule facture d’AWS pour la consommation de Red Hat OpenShift et AWS.
- Expérience de support entièrement intégrée : l’installation, la gestion, la maintenance et les mises à niveau sont effectuées par des ingénieurs de fiabilité du site de Red Hat (SRE) avec le support conjoint Red Hat et Amazon et un accord de niveau de service (SLA) de 99,95 %.
- Intégration de services AWS: AWS dispose d’un portefeuille robuste de services cloud, tels que le calcul, le stockage, la mise en réseau, la base de données, l’analyse et l’apprentissage automatique. L’ensemble de ces services est directement accessible via ROSA. Cela facilite la construction, l’exploitation et l’échelle mondiale et à la demande grâce à une interface de gestion familière.
- Disponibilité maximale : Déployez des clusters sur plusieurs zones de disponibilité dans les régions prises en charge pour maximiser la disponibilité et maintenir une disponibilité élevée pour vos applications et données critiques.
- Cluster node scaling: Ajoutez ou supprimez facilement des nœuds de calcul pour correspondre à la demande de ressources.
- Clusters optimisés: Choisissez parmi les types d’instance EC2 optimisés, optimisés par calcul ou à usage général avec des clusters dimensionnés pour répondre à vos besoins.
- Disponibilité mondiale : Se reporter à la page de disponibilité régionale du produit pour voir où ROSA est disponible à l’échelle mondiale.
17.1.2. La ROSA et les Kubernetes Copier lienLien copié sur presse-papiers!
Dans ROSA, tout ce dont vous avez besoin pour déployer et gérer des conteneurs est groupé, y compris la gestion des conteneurs, les opérateurs, le réseau, l’équilibrage de charge, le maillage de service, le CI/CD, le pare-feu, la surveillance, le registre, l’authentification et les capacités d’autorisation. Ces composants sont testés ensemble pour des opérations unifiées en tant que plate-forme complète. Les opérations de cluster automatisées, y compris les mises à niveau de plate-forme en direct, améliorent encore votre expérience Kubernetes.
17.1.3. Les responsabilités de base Copier lienLien copié sur presse-papiers!
En général, le déploiement et l’entretien des clusters relèvent de la responsabilité de Red Hat ou d’AWS, tandis que les applications, les utilisateurs et les données relèvent de la responsabilité du client. Afin d’obtenir une ventilation plus détaillée des responsabilités, voir la matrice des responsabilités.
17.1.4. Feuille de route et demandes de fonctionnalités Copier lienLien copié sur presse-papiers!
Consultez la feuille de route ROSA pour rester au courant de l’état des fonctionnalités en cours de développement. Lancez un nouveau problème si vous avez des suggestions pour l’équipe produit.
17.1.5. Disponibilité de la région AWS Copier lienLien copié sur presse-papiers!
Consultez la page de disponibilité régionale du produit pour obtenir une vue à jour de l’endroit où le ROSA est disponible.
17.1.6. Certifications de conformité Copier lienLien copié sur presse-papiers!
Actuellement, ROSA est conforme aux normes SOC-2 type 2, SOC 3, ISO-27001, ISO 27017, ISO 27018, HIPAA, GDPR et PCI-DSS. En outre, nous travaillons actuellement vers FedRAMP High.
17.1.7. Les nœuds Copier lienLien copié sur presse-papiers!
17.1.7.1. Nœuds de travail dans plusieurs régions AWS Copier lienLien copié sur presse-papiers!
Les nœuds d’un cluster ROSA doivent être situés dans la même région AWS. Dans le cas des clusters configurés pour plusieurs zones de disponibilité, les nœuds de plan de contrôle et les nœuds ouvriers seront répartis entre les zones de disponibilité.
17.1.7.2. Le nombre minimum de nœuds de travailleurs Copier lienLien copié sur presse-papiers!
Dans le cas d’un cluster ROSA, le minimum est de 2 nœuds ouvriers pour la zone de disponibilité unique et de 3 nœuds ouvriers pour plusieurs zones de disponibilité.
17.1.7.3. Le système d’exploitation des nœuds sous-jacents Copier lienLien copié sur presse-papiers!
Comme pour toutes les offres OpenShift v4.x, le plan de contrôle, l’infra et les nœuds de travail exécutent Red Hat Enterprise Linux CoreOS (RHCOS).
17.1.7.4. Hibernation ou arrêt des nœuds Copier lienLien copié sur presse-papiers!
À l’heure actuelle, ROSA n’a pas de fonction d’hibernation ou d’arrêt pour les nœuds. La fonction d’arrêt et d’hibernation est une fonctionnalité de plate-forme OpenShift qui n’est pas encore assez mature pour une utilisation généralisée des services cloud.
17.1.7.5. Instances prises en charge pour les nœuds ouvriers Copier lienLien copié sur presse-papiers!
Dans la liste complète des instances prises en charge pour les nœuds de travail, voir les types d’instances AWS. Les instances ponctuelles sont également prises en charge.
17.1.7.6. Autoscaling des nœuds Copier lienLien copié sur presse-papiers!
La mise à l’échelle automatique vous permet d’ajuster automatiquement la taille du cluster en fonction de la charge de travail actuelle. Consultez À propos des nœuds autoscaling sur un cluster pour plus de détails.
17.1.7.7. Le nombre maximal de nœuds de travailleurs Copier lienLien copié sur presse-papiers!
Le nombre maximal de nœuds de travail dans les versions 4.14.14 et ultérieures des clusters ROSA est de 249. Dans les versions précédentes, la limite est de 180 nœuds.
La documentation de l’ACR fournit une liste des rôles à l’échelle du compte et par groupe.
17.1.8. Administrateurs Copier lienLien copié sur presse-papiers!
L’administrateur d’un client ROSA peut gérer les utilisateurs et les quotas en plus d’accéder à tous les projets créés par l’utilisateur.
17.1.9. Les versions et mises à jour OpenShift Copier lienLien copié sur presse-papiers!
Le ROSA est un service géré basé sur OpenShift Container Platform. La version actuelle et les dates du cycle de vie sont affichées dans la documentation ROSA.
Les clients peuvent passer à la dernière version d’OpenShift et utiliser les fonctionnalités de cette version d’OpenShift. Consultez les dates du cycle de vie pour plus d’informations. Les fonctionnalités OpenShift ne sont pas toutes disponibles sur ROSA. Examinez la définition du service pour plus d’informations.
17.1.10. Le soutien Copier lienLien copié sur presse-papiers!
Il est possible d’ouvrir un billet directement à partir de l’OpenShift Cluster Manager. Consultez la documentation de support ROSA pour plus de détails sur l’obtention du soutien.
En outre, vous pouvez visiter le portail client Red Hat pour rechercher ou parcourir la base de connaissances Red Hat sur les articles et solutions relatifs aux produits Red Hat ou soumettre un dossier d’assistance à Red Hat Support.
17.1.10.1. Le soutien limité Copier lienLien copié sur presse-papiers!
Lorsqu’un cluster ROSA n’est pas mis à niveau avant la date de fin de vie, le cluster continue de fonctionner dans un statut de support limité. Le SLA pour ce cluster ne sera plus applicable, mais vous pouvez toujours obtenir un support pour ce cluster. Consultez la documentation d’état du support limité pour plus de détails.
Autres ressources d ' appui
- Appui au chapeau rouge
Les clients d’assistance AWS doivent avoir un contrat de support AWS valide
17.1.11. Accord de niveau de service (SLA) Copier lienLien copié sur presse-papiers!
Consultez la page ROSA SLA pour plus de détails.
17.1.12. Les notifications et la communication Copier lienLien copié sur presse-papiers!
Le Red Hat fournira des notifications concernant les nouvelles fonctionnalités Red Hat et AWS, les mises à jour et la maintenance programmée par e-mail et le journal de service Hybrid Cloud Console.
17.1.13. Courtier Open Service pour AWS (OBSA) Copier lienLien copié sur presse-papiers!
Il est possible d’utiliser OSBA avec ROSA. Cependant, la méthode préférée est la plus récente AWS Controller pour Kubernetes. Consultez Open Service Broker pour AWS pour plus d’informations sur OSBA.
17.1.14. Hors-bord Copier lienLien copié sur presse-papiers!
Les clients peuvent cesser d’utiliser ROSA à tout moment et déplacer leurs applications sur site, dans un cloud privé ou dans d’autres fournisseurs de cloud. La politique standard des instances réservées (RI) s’applique aux RI inutilisés.
17.1.15. Authentification Copier lienLien copié sur presse-papiers!
La ROSA prend en charge les mécanismes d’authentification suivants : OpenID Connect (un profil d’OAuth2), Google OAuth, GitHub OAuth, GitLab et LDAP.
17.1.16. Accès au cluster SRE Copier lienLien copié sur presse-papiers!
L’accès au cluster SRE est sécurisé par MFA. Consultez SRE accès pour plus de détails.
17.1.17. Chiffrement Copier lienLien copié sur presse-papiers!
17.1.17.1. Clés de chiffrement Copier lienLien copié sur presse-papiers!
La ROSA utilise une clé stockée dans KMS pour chiffrer les volumes EBS. Les clients ont également la possibilité de fournir leurs propres clés KMS lors de la création de clusters.
17.1.17.2. Clés KMS Copier lienLien copié sur presse-papiers!
Lorsque vous spécifiez une clé KMS, le plan de contrôle, l’infrastructure et les volumes racine des nœuds de travail et les volumes persistants sont chiffrés avec la clé.
17.1.17.3. Chiffrement des données Copier lienLien copié sur presse-papiers!
Il y a par défaut un cryptage au repos. La plate-forme AWS Storage crypte automatiquement vos données avant de les persister et décrypte les données avant leur récupération. Consultez AWS EBS Encryption pour plus de détails.
Il est également possible de chiffrer etcd dans le cluster, en le combinant avec le chiffrement de stockage AWS. Cela se traduit par le double du chiffrement qui ajoute jusqu’à 20% de performance. Consultez la documentation de cryptage etcd pour plus de détails.
17.1.17.4. chiffrement etcd Copier lienLien copié sur presse-papiers!
le chiffrement etcd ne peut être activé que lors de la création de clusters.
le chiffrement etcd entraîne des frais généraux supplémentaires avec une réduction négligeable des risques de sécurité.
17.1.17.5. configuration de chiffrement etcd Copier lienLien copié sur presse-papiers!
le chiffrement etcd est configuré comme dans OpenShift Container Platform. Le cypher aescbc est utilisé et le réglage est corrigé lors du déploiement du cluster. Consultez la documentation Kubernetes pour plus de détails.
17.1.17.6. Clés KMS multi-régions pour le cryptage EBS Copier lienLien copié sur presse-papiers!
Actuellement, le ROSA CLI n’accepte pas les clés KMS multi-régions pour le cryptage EBS. Cette fonctionnalité est dans notre backlog pour les mises à jour des produits. Le ROSA CLI accepte les clés KMS d’une seule région pour le chiffrement EBS s’il est défini lors de la création de clusters.
17.1.18. L’infrastructure Copier lienLien copié sur presse-papiers!
La ROSA utilise plusieurs services cloud différents tels que les machines virtuelles, le stockage et les équilibreurs de charge. Dans les prérequis AWS, vous pouvez voir une liste définie.
17.1.19. Les méthodes d’identification Copier lienLien copié sur presse-papiers!
Il existe deux méthodes d’identification pour accorder à Red Hat les autorisations nécessaires pour effectuer les actions requises dans votre compte AWS: AWS avec STS ou un utilisateur IAM avec des autorisations d’administration. AWS avec STS est la méthode préférée, et la méthode utilisateur IAM sera éventuellement dépréciée. AWS et STS s’alignent mieux avec les principes du moindre privilège et des pratiques sécurisées dans la gestion des ressources de service cloud.
17.1.20. Erreurs d’autorisation ou d’échec préalables Copier lienLien copié sur presse-papiers!
Consultez une nouvelle version de la ROSA CLI. Chaque version de la ROSA CLI est située dans deux endroits: Github et le Red Hat signé des versions binaires.
17.1.21. Le stockage Copier lienLien copié sur presse-papiers!
Consultez la section de stockage de la définition du service.
Le pilote OpenShift inclut le pilote CSI pour AWS EFS. Cliquez ici pour plus d’informations sur la configuration d’AWS EFS pour Red Hat OpenShift Service sur AWS.
17.1.22. À l’aide d’un VPC Copier lienLien copié sur presse-papiers!
Lors de l’installation, vous pouvez choisir de vous déployer sur un VPC existant ou d’apporter votre propre VPC. Ensuite, vous pouvez sélectionner les sous-réseaux requis et fournir une plage CIDR valide qui englobe les sous-réseaux du programme d’installation lors de l’utilisation de ces sous-réseaux.
La ROSA permet à plusieurs clusters de partager le même VPC. Le nombre de clusters sur un VPC est limité par le quota de ressources AWS restant et les plages CIDR qui ne peuvent pas se chevaucher. Consultez Définitions de gamme CIDR pour plus d’informations.
17.1.23. Plugin réseau Copier lienLien copié sur presse-papiers!
La ROSA utilise le fournisseur de réseau CNI OpenShift OVN-Kubernetes par défaut.
17.1.24. La mise en réseau cross-namespace Copier lienLien copié sur presse-papiers!
Les administrateurs de clusters peuvent personnaliser, et nier, cross-namespace sur une base de projet à l’aide d’objets NetworkPolicy. Consultez la section Configurer l’isolement multilocataire avec la politique de réseau pour plus d’informations.
17.1.25. En utilisant Prometheus et Grafana Copier lienLien copié sur presse-papiers!
Il est possible d’utiliser Prometheus et Grafana pour surveiller les conteneurs et gérer la capacité grâce à OpenShift User Workload Monitoring. Il s’agit d’une option de case à cocher dans OpenShift Cluster Manager.
17.1.26. Enregistre les résultats de l’audit à partir du plan de contrôle du cluster Copier lienLien copié sur presse-papiers!
Lorsque le module d’extension de l’opérateur de journalisation du cluster a été ajouté au cluster, les journaux d’audit sont disponibles via CloudWatch. Dans le cas contraire, une demande d’assistance vous permettrait de demander certains journaux d’audit. De petits journaux ciblés et encadrés dans le temps peuvent être demandés pour l’exportation et envoyés à un client. La sélection des journaux d’audit disponibles est à la discrétion de SRE dans la catégorie de la sécurité et de la conformité de la plate-forme. Les demandes d’exportation de l’ensemble des grumes d’un groupe seront rejetées.
17.1.27. Limites des autorisations AWS Copier lienLien copié sur presse-papiers!
Il est possible d’utiliser une limite d’autorisation AWS autour des stratégies de votre cluster.
17.1.28. AMI Copier lienLien copié sur presse-papiers!
Les nœuds de travail ROSA utilisent un AMI différent de OSD et OpenShift Container Platform. Les AMI de Control Plane et Infra sont communs à tous les produits dans la même version.
17.1.29. Les sauvegardes de clusters Copier lienLien copié sur presse-papiers!
Les clusters ROSA STS n’ont pas de sauvegardes. Les utilisateurs doivent avoir leurs propres stratégies de sauvegarde pour les applications et les données. Consultez notre politique de sauvegarde pour plus d’informations.
17.1.30. Domaine personnalisé Copier lienLien copié sur presse-papiers!
Il est possible de définir un domaine personnalisé pour vos applications. Consultez Configuration des domaines personnalisés pour les applications pour plus d’informations.
17.1.31. Certificats de domaine ROSA Copier lienLien copié sur presse-papiers!
L’infrastructure Red Hat (Hive) gère la rotation des certificats pour l’entrée d’application par défaut.
17.1.32. Environnements déconnectés Copier lienLien copié sur presse-papiers!
Le ROSA ne prend pas en charge un environnement déconnecté de l’air. Le cluster ROSA doit avoir accès à Internet pour accéder à notre registre, S3, et envoyer des métriques. Le service nécessite un certain nombre de points de terminaison de sortie. L’entrée peut être limitée à un PrivateLink pour Red Hat SREs et à un VPN pour l’accès des clients.
Ressources supplémentaires
Les pages de produits ROSA:
Les ressources spécifiques de ROSA
- En savoir plus sur OpenShift
- Gestionnaire de cluster OpenShift
- Appui au chapeau rouge