Chapitre 2. Définition des politiques et des services

Les clients ont la possibilité d’acheter des abonnements annuels d’OpenShift Dedicated (OSD) ou de consommer à la demande via des places de marché en nuage. Les clients peuvent décider d’apporter leur propre compte d’infrastructure cloud, appelé Customer Cloud Subscription (CCS), ou de déployer dans des comptes de fournisseurs de cloud appartenant à Red Hat. Le tableau ci-dessous fournit des informations supplémentaires sur la facturation, ainsi que les options de déploiement prises en charge correspondantes.

Des ressources supplémentaires peuvent être achetées pour un cluster OpenShift dédié, y compris:

Les clients peuvent créer, adapter et supprimer leurs clusters à partir d’OpenShift Cluster Manager, à condition qu’ils aient déjà acheté les abonnements nécessaires.

Les actions disponibles dans Red Hat OpenShift Cluster Manager ne doivent pas être exécutées directement à partir du cluster car cela pourrait causer des effets indésirables, y compris le retour automatique de toutes les actions.

L’OpenShift Dedicated propose des clusters OpenShift Container Platform en tant que service géré sur les fournisseurs de cloud suivants:

Les clusters de zone de disponibilité unique nécessitent un minimum de 2 nœuds de travail pour les clusters d’abonnement au cloud client (CCS) déployés dans une seule zone de disponibilité. Au moins 4 nœuds de travail sont requis pour les clusters non-CCS. Ces 4 nœuds ouvriers sont inclus dans l’abonnement de base.

Les clusters de zones de disponibilité multiples nécessitent un minimum de 3 nœuds de travail pour les clusters d’abonnement au cloud client (CCS), 1 déployé dans chacune des 3 zones de disponibilité. Au moins 9 nœuds de travailleurs sont requis pour les clusters non-CCS. Ces 9 nœuds de travail sont inclus dans l’abonnement de base, et des nœuds supplémentaires doivent être achetés en multiples de 3 pour maintenir une bonne distribution des nœuds.

Les nœuds d’avion de contrôle et d’infrastructure sont déployés et gérés par Red Hat. Il y a au moins 3 nœuds de plan de contrôle qui gèrent les charges de travail etcd et API. Il y a au moins 2 nœuds d’infrastructure qui gèrent les métriques, le routage, la console Web et d’autres charges de travail. Il ne faut pas exécuter de charge de travail sur le plan de contrôle et les nœuds d’infrastructure. Les charges de travail que vous avez l’intention d’exécuter doivent être déployées sur les nœuds des travailleurs.

Consultez la section support de Red Hat ci-dessous pour plus d’informations sur les charges de travail de Red Hat qui doivent être déployées sur les nœuds des travailleurs.

Le logiciel OpenShift Dedicated offre les types et tailles d’instances de nœuds de travail suivants sur AWS:

La société OpenShift Dedicated offre les types et tailles de nœuds de travail suivants sur AWS:

L’OpenShift Dedicated propose les types et tailles de nœuds de travail suivants sur Google Cloud qui sont choisis pour avoir un CPU et une capacité de mémoire communs qui sont les mêmes que les autres types d’instances cloud:

Les régions suivantes sont prises en charge par OpenShift Container Platform 4 et sont prises en charge pour OpenShift Dedicated.

Les SLA du service lui-même sont définies à l’annexe 4 de l’Annexe 4 de l’Accord d’entreprise Red Hat (Services d’abonnement en ligne).

Lorsqu’un cluster passe à un statut de support limité, Red Hat ne surveille plus de manière proactive le cluster, le SLA n’est plus applicable et les crédits demandés contre l’ALS sont refusés. Cela ne signifie pas que vous n’avez plus de support produit. Dans certains cas, le cluster peut revenir à un statut entièrement pris en charge si vous corrigez les facteurs de violation. Cependant, dans d’autres cas, vous devrez peut-être supprimer et recréer le cluster.

Il est possible qu’un cluster passe à un statut de support limité pour de nombreuses raisons, y compris les scénarios suivants:

Lorsque vous avez des questions sur une action spécifique qui pourrait faire passer un cluster à un statut de support limité ou avoir besoin d’une assistance supplémentaire, ouvrez un ticket de support.

Le service OpenShift Dedicated inclut le support Red Hat Premium, auquel vous pouvez accéder en utilisant le portail client Red Hat.

Consultez la page Portée de couverture pour plus de détails sur ce qui est couvert avec le support inclus pour OpenShift Dedicated.

Consultez les SLA dédiés OpenShift pour les temps de réponse de support.

Les journaux d’audit en cluster sont disponibles via Amazon CloudWatch (sur AWS) ou Google Cloud Logging (sur GCP), si l’intégration est activée. Lorsque l’intégration n’est pas activée, vous pouvez demander les journaux d’audit en ouvrant un dossier d’assistance. Les demandes de journaux d’audit doivent préciser une date et une période ne dépassant pas 21 jours. Lorsque vous demandez des journaux d’audit, les clients doivent savoir que les journaux d’audit sont de nombreux GB par jour en taille.

Les journaux d’application envoyés à STDOUT sont transmis à Amazon CloudWatch (sur AWS) ou Google Cloud Logging (sur GCP) via la pile de journalisation des clusters, s’il est installé.

Les clusters dédiés OpenShift sont livrés avec une pile Prometheus/Grafana intégrée pour la surveillance des clusters, y compris les métriques CPU, mémoire et réseau. Ceci est accessible via la console Web et peut également être utilisé pour afficher l’état et la capacité / utilisation au niveau du cluster via un tableau de bord Grafana. Ces métriques permettent également un autoscaling de pod horizontal basé sur des métriques CPU ou mémoire fournies par un utilisateur dédié OpenShift.

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.

Afin d’utiliser un nom d’hôte personnalisé pour un itinéraire, vous devez mettre à jour votre fournisseur DNS en créant un enregistrement de nom canonique (CNAME). L’enregistrement CNAME doit cartographier le nom d’hôte du routeur canonique OpenShift à votre domaine personnalisé. Le nom d’hôte du routeur canonique OpenShift est affiché sur la page Détails de l’itinéraire après la création d’une Route. Alternativement, un enregistrement générique CNAME peut être créé une fois pour acheminer tous les sous-domaines d’un nom d’hôte donné vers le routeur du cluster.

Les domaines et sous-domaines personnalisés ne sont pas disponibles pour les routes de service de la plate-forme, par exemple, les routes API ou console Web, ou pour les routes d’application par défaut.

Le programme OpenShift Dedicated inclut les certificats de sécurité TLS nécessaires à la fois pour les services internes et externes sur le cluster. Dans le cas des routes externes, il y a deux certificats de wildcard TLS distincts qui sont fournis et installés sur chaque cluster, un pour la console Web et les noms d’hôte par défaut d’itinéraire et le second pour le point de terminaison API. Let's Encrypt est l’autorité de certification utilisée pour les certificats. Les itinéraires au sein du cluster, par exemple, le point de terminaison interne de l’API, utilisent les certificats TLS signés par l’autorité de certification intégrée du cluster et exigent le paquet CA disponible dans chaque pod pour faire confiance au certificat TLS.

Le logiciel OpenShift Dedicated prend en charge l’utilisation d’autorités de certification personnalisées à utiliser par les builds lors de l’extraction d’images à partir d’un registre d’images.

L’OpenShift Dedicated utilise jusqu’à 5 balanceurs de charge différents:

Dans le cas des clusters dédiés à OpenShift non-CCS, l’utilisation du réseau est mesurée en fonction du transfert de données entre le trafic entrant, VPC peering, VPN et AZ. Dans un cluster de base non-CCS OpenShift dédié, 12 To d’E/S réseau sont fournis. Des E/S supplémentaires de réseau peuvent être achetées par incréments de 12 To. Dans le cas des clusters dédiés à CCS OpenShift, l’utilisation du réseau n’est pas surveillée et est facturée directement par le fournisseur de cloud.

Les administrateurs de projet peuvent ajouter des annotations d’itinéraire à de nombreuses fins différentes, y compris le contrôle d’entrée grâce à la liste d’autorisations IP.

Les stratégies d’entrée peuvent également être modifiées en utilisant les objets NetworkPolicy, qui exploitent le plugin ovs-networkpolicy. Cela permet un contrôle total de la stratégie réseau d’entrée jusqu’au niveau pod, y compris entre les pods sur le même cluster et même dans le même espace de noms.

L’ensemble du trafic d’entrée de cluster passe par les équilibreurs de charge définis. L’accès direct à tous les nœuds est bloqué par la configuration du cloud.

Le contrôle du trafic par le biais d’objets EgressNetworkPolicy peut être utilisé pour prévenir ou limiter le trafic sortant dans OpenShift Dedicated.

Le trafic public sortant du plan de contrôle et des nœuds d’infrastructure est nécessaire pour maintenir la sécurité de l’image de cluster et la surveillance des clusters. Cela nécessite que l’itinéraire 0.0.0.0/0 appartienne uniquement à la passerelle Internet; il n’est pas possible d’acheminer cette gamme sur des connexions privées.

Les clusters dédiés à OpenShift utilisent les passerelles NAT pour présenter une IP publique statique pour tout trafic public sortant du cluster. Chaque sous-réseau dans lequel un cluster est déployé reçoit une passerelle NAT distincte. Dans le cas des clusters déployés sur AWS avec plusieurs zones de disponibilité, jusqu’à 3 adresses IP statiques uniques peuvent exister pour le trafic de sortie de cluster. Dans le cas des clusters déployés sur Google Cloud, quelle que soit la topologie de la zone de disponibilité, il y aura 1 adresse IP statique pour le trafic de nœuds de travail. Le trafic qui reste à l’intérieur du cluster ou qui ne sort pas vers l’Internet public ne passera pas par la passerelle NAT et aura une adresse IP source appartenant au nœud d’origine du trafic. Les adresses IP des nœuds sont dynamiques et, par conséquent, un client ne devrait pas compter sur l’autorisation d’une adresse IP individuelle lors de l’accès aux ressources privées.

Les clients peuvent déterminer leurs adresses IP statiques publiques en exécutant un pod sur le cluster, puis en interrogeant un service externe. À titre d’exemple:

oc run ip-lookup --image=busybox -i -t --restart=Never --rm -- /bin/sh -c "/bin/nslookup -type=a myip.opendns.com resolver1.opendns.com | grep -E 'Address: [0-9.]+'"

$ oc run ip-lookup --image=busybox -i -t --restart=Never --rm -- /bin/sh -c "/bin/nslookup -type=a myip.opendns.com resolver1.opendns.com | grep -E 'Address: [0-9.]+'"

L’OpenShift Dedicated permet la configuration d’une connexion réseau privée via plusieurs technologies gérées par des fournisseurs de cloud:

Dans le cas des clusters dédiés à OpenShift qui ont une configuration de réseau cloud privé, un client peut spécifier des serveurs DNS internes disponibles sur cette connexion privée qui devraient être interrogés pour les domaines explicitement fournis.

Les vérifications réseau s’exécutent automatiquement lorsque vous déployez un cluster dédié OpenShift dans un cloud privé virtuel (VPC) existant ou créez un pool de machines supplémentaire avec un sous-réseau qui est nouveau à votre cluster. Les vérifications valident votre configuration réseau et mettent en évidence les erreurs, vous permettant de résoudre les problèmes de configuration avant le déploiement.

Il est également possible d’exécuter manuellement les vérifications réseau pour valider la configuration d’un cluster existant.

Les nœuds de plan de contrôle utilisent le stockage crypté au repos-EBS.

Les volumes EBS utilisés pour les volumes persistants (PV) sont cryptés au repos par défaut.

Les volumes persistants (PV) sont soutenus par AWS EBS et Google Cloud, qui utilise le mode d’accès ReadWriteOnce (RWO). Dans un cluster de base non-CCS OpenShift dédié, 100 Go de stockage par bloc sont fournis pour les PV, qui sont fournis dynamiquement et recyclés en fonction des demandes d’application. Le stockage persistant supplémentaire peut être acheté par incréments de 500 Go.

Les PVS ne peuvent être attachés qu’à un seul nœud à la fois et sont spécifiques à la zone de disponibilité dans laquelle ils ont été fournis, mais ils peuvent être attachés à n’importe quel nœud dans la zone de disponibilité.

Chaque fournisseur de cloud a ses propres limites pour combien de PV peuvent être attachés à un seul nœud. Consultez les limites de type d’instance AWS ou les types de machines personnalisées de Google Cloud Platform pour plus de détails.

Le pilote AWS CSI peut être utilisé pour fournir la prise en charge RWX pour OpenShift Dedicated sur AWS. L’opérateur communautaire est fourni pour simplifier la configuration. Consultez AWS EFS Setup for OpenShift Dedicated et Red Hat OpenShift Service sur AWS.

Les sauvegardes de données d’application et d’application ne font pas partie du service dédié OpenShift. Dans chaque cluster dédié OpenShift, tous les objets Kubernetes sont sauvegardés pour faciliter une récupération rapide dans le cas peu probable qu’un cluster devienne irréparable.

Les sauvegardes sont stockées dans un seau de stockage d’objets sécurisé (Multi-AZ) dans le même compte que le cluster. Les volumes racine des nœuds ne sont pas sauvegardés parce que Red Hat Enterprise Linux CoreOS est entièrement géré par le cluster OpenShift Container Platform et qu’aucune donnée étatique ne doit être stockée sur le volume racine d’un nœud.

Le tableau suivant montre la fréquence des sauvegardes:

La mise à l’échelle automatique des nœuds est disponible sur OpenShift Dedicated. Consultez À propos des nœuds autoscaling sur un cluster pour plus d’informations sur les nœuds autoscaling sur un cluster.

Les clients peuvent créer et exécuter DaemonSets sur OpenShift Dedicated. Afin de limiter DaemonSets à fonctionner uniquement sur les nœuds de travail, utilisez le nodeSelector suivant:

...
spec:
  nodeSelector:
    role: worker
...

...
spec:
  nodeSelector:
    role: worker
...

Dans un cluster de zones de disponibilité multiple, les nœuds de contrôle sont répartis entre les zones de disponibilité et au moins trois nœuds de travail sont requis dans chaque zone de disponibilité.

Les étiquettes de nœuds personnalisés sont créées par Red Hat lors de la création de nœuds et ne peuvent pas être modifiées sur les clusters dédiés OpenShift pour le moment.

Le service OpenShift Dedicated est mis à jour avec la dernière version OpenShift Container Platform.

Consultez le cycle de vie dédié OpenShift pour plus d’informations sur la politique et les procédures de mise à niveau.

Les conteneurs Windows ne sont pas disponibles sur OpenShift Dedicated pour le moment.

L’OpenShift Dedicated fonctionne sur OpenShift 4 et utilise CRI-O comme seul moteur de conteneur disponible.

Le système OpenShift Dedicated fonctionne sur OpenShift 4 et utilise Red Hat Enterprise Linux CoreOS comme système d’exploitation pour tous les nœuds de plan de contrôle et de travail.

Les charges de travail Red Hat se réfèrent généralement aux opérateurs fournis par Red Hat mis à disposition par l’intermédiaire de l’opérateur Hub. Les charges de travail Red Hat ne sont pas gérées par l’équipe Red Hat SRE et doivent être déployées sur les nœuds des travailleurs. Ces opérateurs peuvent nécessiter des abonnements supplémentaires à Red Hat et peuvent entraîner des coûts d’infrastructure cloud supplémentaires. Des exemples de ces opérateurs fournis par Red Hat sont:

Les opérateurs inscrits sur le marché OperatorHub devraient être disponibles pour l’installation. Les opérateurs installés à partir de OperatorHub, y compris Red Hat Operators, ne sont pas gérés SRE dans le cadre du service dédié OpenShift. Consultez le portail client Red Hat pour plus d’informations sur la compatibilité d’un opérateur donné.

L’authentification pour le cluster est configurée dans le cadre du processus de création de clusters Red Hat OpenShift Cluster Manager. « OpenShift n’est pas un fournisseur d’identité, et tout accès au cluster doit être géré par le client dans le cadre de sa solution intégrée. Le provisionnement de plusieurs fournisseurs d’identité fournis en même temps est pris en charge. Les fournisseurs d’identité suivants sont pris en charge:

Les conteneurs privilégiés ne sont pas disponibles par défaut sur OpenShift Dedicated. Les contraintes de contexte de sécurité anyuid et non racine sont disponibles pour les membres du groupe admins dédiés, et devraient traiter de nombreux cas d’utilisation. Les conteneurs privilégiés ne sont disponibles que pour les utilisateurs de cluster-admin.

En plus des utilisateurs normaux, OpenShift Dedicated fournit l’accès à un groupe dédié OpenShift spécifique appelé dédié-admin. Les utilisateurs du cluster qui sont membres du groupe admin dédié:

En tant qu’administrateur d’OpenShift Dedicated with Customer Cloud Subscriptions (CCS), vous avez accès au rôle cluster-admin. Alors qu’ils sont connectés à un compte avec le rôle de cluster-admin, les utilisateurs ont pour la plupart un accès illimité au contrôle et à la configuration du cluster. Il y a certaines configurations qui sont bloquées avec des webhooks pour empêcher le désétablissement du cluster, ou parce qu’elles sont gérées dans OpenShift Cluster Manager et tout changement dans l’inclusion serait écrasé.

L’ensemble des utilisateurs, par défaut, ont la possibilité de créer, mettre à jour et supprimer leurs projets. Cela peut être restreint si un membre du groupe admin dédié supprime le rôle d’auto-fournisseur des utilisateurs authentifiés:

oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth

$ oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth

Les restrictions peuvent être annulées en appliquant:

oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth

$ oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth

La société OpenShift Dedicated suit les meilleures pratiques courantes de l’industrie en matière de sécurité et de contrôle. Les certifications sont décrites dans le tableau suivant.

Chaque cluster dédié OpenShift est protégé par une configuration réseau sécurisée au niveau de l’infrastructure cloud en utilisant les règles de pare-feu (AWS Security Groups ou Google Cloud Compute Engine). Les clients dédiés sur AWS sont également protégés contre les attaques DDoS avec AWS Shield Standard. De même, tous les équilibreurs de charge GCP et les adresses IP publiques utilisées par OpenShift Dedicated on GCP sont protégés contre les attaques DDoS avec Google Cloud Armor Standard.

Dans OpenShift Dedicated, le stockage du plan de contrôle est crypté au repos par défaut et cela inclut le cryptage des volumes etcd. Ce chiffrement de niveau de stockage est fourni via la couche de stockage du fournisseur de cloud.

Il est également possible d’activer le chiffrement etcd, qui chiffre les valeurs clés dans etcd, mais pas les clés. Lorsque vous activez le cryptage etcd, les ressources suivantes du serveur API Kubernetes et OpenShift API sont cryptées:

La fonction de chiffrement etcd n’est pas activée par défaut et ne peut être activée qu’au moment de l’installation du cluster. Bien que le chiffrement etcd soit activé, les valeurs clés etcd sont accessibles à toute personne ayant accès aux nœuds de plan de contrôle ou aux privilèges cluster-admin.