Vérification des prérequis de l'agent sur Red Hat OpenShift

Modifier en ligne

Avant d'installer l'agent, assurez-vous que toutes les conditions préalables sont remplies. Veuillez consulter les conditions préalables suivantes :

  1. Vérifiez si vous disposez d'une version prise en charge d' Red Hat OpenShift.

  2. Vérifiez que les exigences réseau pour les agents sont respectées, comme indiqué dans la section « Exigences d'accès réseau sortant pour les déploiements d' Instana » SaaS.

Remarque : vous devez configurer le réseau comme indiqué dans les sections « Configuration des paramètres du pare-feu » et « Répertoires de l'agent et des capteurs d' Instana ».

Versions d' Red Hat OpenShift prises en charge

Modifier en ligne

Instana prend en charge les versions d' Red Hat OpenShift s décrites dans la documentation relative aux phases du cycle de vie.

L'agent « Instana » prend en charge les offres d' Red Hat OpenShift s gérées suivantes :

Versions en cours des méthodes d'installation

Modifier en ligne

De nouvelles versions de l'opérateur et du tableau de Helm sont régulièrement publiées. Pour rester informé des mises à jour concernant les corrections, les améliorations et les nouvelles fonctionnalités, assurez-vous d'utiliser la dernière version de l'opérateur ou du graphique « Helm ».

Pour connaître les informations relatives à la version des méthodes d'installation, consultez les pages suivantes :

Configuration des comptes de projet et de service

Modifier en ligne

Si vous installez l'agent à l'aide de l'opérateur d'agent « Instana », vous devez d'abord créer un projet pour l'agent « Instana » et configurer ses autorisations.

Créez le instana-agent projet et configurez les autorisations de stratégie afin de vous assurer que le compte instana-agent de service se trouve dans le contexte de sécurité privilégié. Voir les commandes exemple suivantes :

oc login -u system:admin
oc new-project instana-agent
oc adm policy add-scc-to-user privileged -z instana-agent -n instana-agent
oc adm policy add-scc-to-user anyuid -z instana-agent-remote -n instana-agent

ROSA Limites de la surveillance des plans de contrôle hébergés (HCP)

Modifier en ligne

Lorsque vous exécutez des charges de travail sur ROSA avec les plans de contrôle hébergés (HCP), vous ne pouvez pas accéder à certains composants du plan de contrôle à partir des charges de travail des clients.

Dans le cadre d'une installation HCP ( ROSA ), Red Hat héberge et gère le plan de contrôle d' Kubernetes (serveur API, gestionnaire de contrôleurs, planificateur et etcd ) dans un compte AWS distinct. En raison de cette séparation :

  • Les espaces de noms du plan de contrôle suivants ne sont pas accessibles depuis le plan de données du cluster client :
    • openshift-kube-apiserver
    • openshift-kube-controller-manager
    • openshift-kube-scheduler
    • openshift-etcd
  • Les pods et services associés ne sont pas non plus accessibles ni routables depuis le plan de données du cluster du client.

Conséquences sur la surveillance

Les fonctionnalités suivantes restent pleinement opérationnelles :

  • Surveillance de la charge de travail (pods, déploiements, services, espaces de noms, CRD et ressources associées)
  • Surveillance des nœuds de travail
  • Métriques du kubelet des nœuds de travail (utilisation du processeur, de la mémoire et des PVC)
  • Kubernetes API accès aux espaces de noms et aux ressources des utilisateurs.

Toutefois, les restrictions suivantes s'appliquent :

  • Les pods du plan de contrôle ne sont pas visibles pour une surveillance directe.
  • Les points de terminaison /metrics du plan de contrôle (serveur API, gestionnaire de contrôleurs, planificateur et etcd ) ne peuvent pas être scrapés.
  • Les agents au sein du cluster ne peuvent pas accéder aux indicateurs de performance et d'état des nœuds du plan de contrôle.

Ces limitations sont dues à l'architecture HCP d' ROSA. La plateforme gère entièrement le plan de contrôle et l'isole du VPC du client.