6.8. Déplacement des ressources du sous-système de journalisation à l'aide de sélecteurs de nœuds
Vous pouvez utiliser des sélecteurs de nœuds pour déployer les pods Elasticsearch et Kibana sur différents nœuds.
6.8.1. Déplacer les ressources de journalisation d'OpenShift
Vous pouvez configurer le Cluster Logging Operator pour déployer les pods des composants du sous-système de journalisation, tels qu'Elasticsearch et Kibana, sur différents nœuds. Vous ne pouvez pas déplacer le pod Cluster Logging Operator de son emplacement d'installation.
Par exemple, vous pouvez déplacer les pods Elasticsearch vers un nœud distinct en raison des exigences élevées en matière de CPU, de mémoire et de disque.
Conditions préalables
- Les opérateurs Red Hat OpenShift Logging et Elasticsearch doivent être installés. Ces fonctionnalités ne sont pas installées par défaut.
Procédure
Modifiez la ressource personnalisée (CR)
ClusterLoggingdans le projetopenshift-logging:$ oc edit ClusterLogging instance
apiVersion: logging.openshift.io/v1 kind: ClusterLogging ... spec: collection: logs: fluentd: resources: null type: fluentd logStore: elasticsearch: nodeCount: 3 nodeSelector: 1 node-role.kubernetes.io/infra: '' tolerations: - effect: NoSchedule key: node-role.kubernetes.io/infra value: reserved - effect: NoExecute key: node-role.kubernetes.io/infra value: reserved redundancyPolicy: SingleRedundancy resources: limits: cpu: 500m memory: 16Gi requests: cpu: 500m memory: 16Gi storage: {} type: elasticsearch managementState: Managed visualization: kibana: nodeSelector: 2 node-role.kubernetes.io/infra: '' tolerations: - effect: NoSchedule key: node-role.kubernetes.io/infra value: reserved - effect: NoExecute key: node-role.kubernetes.io/infra value: reserved proxy: resources: null replicas: 1 resources: null type: kibana ...- 1 2
- Ajoutez un paramètre
nodeSelectoravec la valeur appropriée au composant que vous souhaitez déplacer. Vous pouvez utiliser unnodeSelectordans le format indiqué ou utiliser des paires<key>: <value>, en fonction de la valeur spécifiée pour le nœud. Si vous avez ajouté une tare au nœud de l'infrasructure, ajoutez également une tolérance correspondante.
Vérification
Pour vérifier qu'un composant a été déplacé, vous pouvez utiliser la commande oc get pod -o wide.
Par exemple :
Vous souhaitez déplacer le pod Kibana du nœud
ip-10-0-147-79.us-east-2.compute.internal:$ oc get pod kibana-5b8bdf44f9-ccpq9 -o wide
Exemple de sortie
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES kibana-5b8bdf44f9-ccpq9 2/2 Running 0 27s 10.129.2.18 ip-10-0-147-79.us-east-2.compute.internal <none> <none>
Vous souhaitez déplacer le pod Kibana vers le nœud
ip-10-0-139-48.us-east-2.compute.internal, un nœud d'infrastructure dédié :$ oc get nodes
Exemple de sortie
NAME STATUS ROLES AGE VERSION ip-10-0-133-216.us-east-2.compute.internal Ready master 60m v1.25.0 ip-10-0-139-146.us-east-2.compute.internal Ready master 60m v1.25.0 ip-10-0-139-192.us-east-2.compute.internal Ready worker 51m v1.25.0 ip-10-0-139-241.us-east-2.compute.internal Ready worker 51m v1.25.0 ip-10-0-147-79.us-east-2.compute.internal Ready worker 51m v1.25.0 ip-10-0-152-241.us-east-2.compute.internal Ready master 60m v1.25.0 ip-10-0-139-48.us-east-2.compute.internal Ready infra 51m v1.25.0
Notez que le nœud a une étiquette
node-role.kubernetes.io/infra: '':$ oc get node ip-10-0-139-48.us-east-2.compute.internal -o yaml
Exemple de sortie
kind: Node apiVersion: v1 metadata: name: ip-10-0-139-48.us-east-2.compute.internal selfLink: /api/v1/nodes/ip-10-0-139-48.us-east-2.compute.internal uid: 62038aa9-661f-41d7-ba93-b5f1b6ef8751 resourceVersion: '39083' creationTimestamp: '2020-04-13T19:07:55Z' labels: node-role.kubernetes.io/infra: '' ...Pour déplacer le pod Kibana, modifiez le CR
ClusterLoggingpour ajouter un sélecteur de nœud :apiVersion: logging.openshift.io/v1 kind: ClusterLogging ... spec: ... visualization: kibana: nodeSelector: 1 node-role.kubernetes.io/infra: '' proxy: resources: null replicas: 1 resources: null type: kibana- 1
- Ajouter un sélecteur de nœud correspondant à l'étiquette de la spécification du nœud.
Après avoir sauvegardé le CR, le pod Kibana actuel est terminé et le nouveau pod est déployé :
$ oc get pods
Exemple de sortie
NAME READY STATUS RESTARTS AGE cluster-logging-operator-84d98649c4-zb9g7 1/1 Running 0 29m elasticsearch-cdm-hwv01pf7-1-56588f554f-kpmlg 2/2 Running 0 28m elasticsearch-cdm-hwv01pf7-2-84c877d75d-75wqj 2/2 Running 0 28m elasticsearch-cdm-hwv01pf7-3-f5d95b87b-4nx78 2/2 Running 0 28m fluentd-42dzz 1/1 Running 0 28m fluentd-d74rq 1/1 Running 0 28m fluentd-m5vr9 1/1 Running 0 28m fluentd-nkxl7 1/1 Running 0 28m fluentd-pdvqb 1/1 Running 0 28m fluentd-tflh6 1/1 Running 0 28m kibana-5b8bdf44f9-ccpq9 2/2 Terminating 0 4m11s kibana-7d85dcffc8-bfpfp 2/2 Running 0 33s
Le nouveau pod se trouve sur le nœud
ip-10-0-139-48.us-east-2.compute.internal:$ oc get pod kibana-7d85dcffc8-bfpfp -o wide
Exemple de sortie
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES kibana-7d85dcffc8-bfpfp 2/2 Running 0 43s 10.131.0.22 ip-10-0-139-48.us-east-2.compute.internal <none> <none>
Après quelques instants, le pod Kibana original est retiré.
$ oc get pods
Exemple de sortie
NAME READY STATUS RESTARTS AGE cluster-logging-operator-84d98649c4-zb9g7 1/1 Running 0 30m elasticsearch-cdm-hwv01pf7-1-56588f554f-kpmlg 2/2 Running 0 29m elasticsearch-cdm-hwv01pf7-2-84c877d75d-75wqj 2/2 Running 0 29m elasticsearch-cdm-hwv01pf7-3-f5d95b87b-4nx78 2/2 Running 0 29m fluentd-42dzz 1/1 Running 0 29m fluentd-d74rq 1/1 Running 0 29m fluentd-m5vr9 1/1 Running 0 29m fluentd-nkxl7 1/1 Running 0 29m fluentd-pdvqb 1/1 Running 0 29m fluentd-tflh6 1/1 Running 0 29m kibana-7d85dcffc8-bfpfp 2/2 Running 0 62s
