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ôlecluster-readerou les deux rôles pour voir les index infra et audit dans Kibana. L'utilisateur par défautkubeadmindispose des autorisations nécessaires pour afficher ces index.Si vous pouvez voir les pods et les journaux dans les projets
default,kube-etopenshift-, 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
NoteLes 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
defaultpour 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 :
-
Dans la console OpenShift Container Platform, cliquez sur le lanceur d'applications
et sélectionnez Logging.
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é
appet utiliser le champ@timestamptime 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, etauditen utilisant le champ@timestamptime.
-
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é
- 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 :
Définir une étiquette sur l'espace de noms
openshift-operators-redhat. Par exemple :$ oc label namespace openshift-operators-redhat project=openshift-operators-redhat
Créez un objet de politique de réseau dans l'espace de noms
openshift-loggingqui autorise l'entrée des projetsopenshift-operators-redhat,openshift-monitoringetopenshift-ingressdans 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
