SupportConsoleDéveloppeursCommencer un essaiContact

5.4. Post-installation tasks

Si vous prévoyez d'utiliser Kibana, vous devez créer manuellement vos modèles d'index et vos visualisations Kibana pour explorer et visualiser les données dans Kibana.

Si votre module d'extension réseau assure l'isolation du réseau, autorisez le trafic réseau entre les projets qui contiennent le sous-système de journalisation Operators.

5.4.1. Définir les modèles d'index Kibana

Un modèle d'index définit les index Elasticsearch que vous souhaitez visualiser. Pour explorer et visualiser des données dans Kibana, vous devez créer un modèle d'index.

Conditions préalables

  • Un utilisateur doit avoir le rôle cluster-admin, le rôle cluster-reader ou les deux rôles pour voir les index infra et audit dans Kibana. L'utilisateur par défaut kubeadmin dispose des autorisations nécessaires pour afficher ces index.

    Si vous pouvez voir les pods et les journaux dans les projets default, kube- et openshift-, vous devriez pouvoir accéder à ces index. Vous pouvez utiliser la commande suivante pour vérifier si l'utilisateur actuel dispose des autorisations appropriées : 

    $ oc auth can-i get pods/log -n <projet>

    Exemple de sortie

    yes

    Note

    Les journaux d'audit ne sont pas stockés dans l'instance interne d'OpenShift Container Platform Elasticsearch par défaut. Pour afficher les journaux d'audit dans Kibana, vous devez utiliser l'API Log Forwarding pour configurer un pipeline qui utilise la sortie default pour les journaux d'audit.

  • Les documents Elasticsearch doivent être indexés avant de pouvoir créer des modèles d'index. Cette opération est effectuée automatiquement, mais elle peut prendre quelques minutes dans un cluster nouveau ou mis à jour.

Procédure

Pour définir des modèles d'index et créer des visualisations dans Kibana :

  1. Dans la console OpenShift Container Platform, cliquez sur le lanceur d'applications lanceur d'applications et sélectionnez Logging.

  2. Créez vos modèles d'index Kibana en cliquant sur Management Index Patterns Create index pattern:

    • Chaque utilisateur doit créer manuellement des modèles d'index lors de sa première connexion à Kibana pour voir les journaux de ses projets. Les utilisateurs doivent créer un modèle d'index nommé app et utiliser le champ @timestamp time pour afficher les journaux de leurs conteneurs.
    • Chaque utilisateur administrateur doit créer des modèles d'index lors de sa première connexion à Kibana pour les index app, infra, et audit en utilisant le champ @timestamp time.
  3. Créer des visualisations Kibana à partir des nouveaux modèles d'index.

5.4.2. Permettre le trafic entre les projets lorsque l'isolation du réseau est activée

Le plugin réseau de votre cluster peut imposer l'isolation du réseau. Si c'est le cas, vous devez autoriser le trafic réseau entre les projets qui contiennent les opérateurs déployés par OpenShift Logging.

L'isolation du réseau bloque le trafic réseau entre les pods ou les services qui se trouvent dans des projets différents. Le sous-système de journalisation installe OpenShift Elasticsearch Operator dans le projet openshift-operators-redhat et Red Hat OpenShift Logging Operator dans le projet openshift-logging. Vous devez donc autoriser le trafic entre ces deux projets.

OpenShift Container Platform propose deux choix pour le plugin réseau, OpenShift SDN et OVN-Kubernetes. Ces deux fournisseurs mettent en œuvre diverses politiques d'isolation du réseau.

OpenShift SDN dispose de trois modes :

politique de réseau
Il s'agit du mode par défaut. Si aucune politique n'est définie, il autorise tout le trafic. Toutefois, si un utilisateur définit une politique, il commence généralement par refuser tout le trafic, puis ajoute des exceptions. Ce processus risque d'interrompre les applications exécutées dans différents projets. Par conséquent, il convient de configurer explicitement la stratégie afin d'autoriser le trafic à sortir d'un projet lié à la journalisation vers l'autre.
multitenant
Ce mode permet d'isoler le réseau. Vous devez joindre les deux projets liés à la journalisation pour permettre le trafic entre eux.
sous-réseau
Ce mode autorise tout le trafic. Il n'applique pas l'isolation du réseau. Aucune action n'est nécessaire.

OVN-Kubernetes utilise toujours un network policy. Par conséquent, comme avec OpenShift SDN, vous devez configurer la politique pour permettre au trafic de sortir d'un projet lié à la journalisation vers l'autre.

Procédure

  • Si vous utilisez OpenShift SDN en mode multitenant, joignez les deux projets. Par exemple : 

    $ oc adm pod-network join-projects --to=openshift-operators-redhat openshift-logging

  • Sinon, pour OpenShift SDN en mode network policy et OVN-Kubernetes, effectuez les actions suivantes :

    1. Définir une étiquette sur l'espace de noms openshift-operators-redhat. Par exemple : 

      $ oc label namespace openshift-operators-redhat project=openshift-operators-redhat

    2. Créez un objet de politique de réseau dans l'espace de noms openshift-logging qui autorise l'entrée des projets openshift-operators-redhat, openshift-monitoring et openshift-ingress dans le projet openshift-logging. Par exemple : 

      apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-monitoring-ingress-operators-redhat
spec:
  ingress:
  - from:
    - podSelector: {}
  - from:
    - namespaceSelector:
        matchLabels:
          project: "openshift-operators-redhat"
  - from:
    - namespaceSelector:
        matchLabels:
          name: "openshift-monitoring"
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: ingress
  podSelector: {}
  policyTypes:
  - Ingress

Ressources complémentaires

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.