6.9. Déplacement de ressources vers des ensembles de machines d'infrastructure
Certaines ressources d'infrastructure sont déployées par défaut dans votre cluster. Vous pouvez les déplacer vers les ensembles de machines d'infrastructure que vous avez créés.
6.9.1. Déplacement du routeur
Vous pouvez déployer le module de routeur sur un ensemble de machines de calcul différent. Par défaut, le module est déployé sur un nœud de travail.
Conditions préalables
- Configurez des ensembles de machines de calcul supplémentaires dans votre cluster OpenShift Container Platform.
Procédure
Voir la ressource personnalisée
IngressControllerpour l'opérateur de routeur :$ oc get ingresscontroller default -n openshift-ingress-operator -o yaml
La sortie de la commande ressemble au texte suivant :
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: creationTimestamp: 2019-04-18T12:35:39Z finalizers: - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller generation: 1 name: default namespace: openshift-ingress-operator resourceVersion: "11341" selfLink: /apis/operator.openshift.io/v1/namespaces/openshift-ingress-operator/ingresscontrollers/default uid: 79509e05-61d6-11e9-bc55-02ce4781844a spec: {} status: availableReplicas: 2 conditions: - lastTransitionTime: 2019-04-18T12:36:15Z status: "True" type: Available domain: apps.<cluster>.example.com endpointPublishingStrategy: type: LoadBalancerService selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller=defaultModifiez la ressource
ingresscontrolleret changez la ressourcenodeSelectorpour qu'elle utilise l'étiquetteinfra:$ oc edit ingresscontroller default -n openshift-ingress-operator
spec: nodePlacement: nodeSelector: 1 matchLabels: 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- 1
- Ajoutez un paramètre
nodeSelectoravec la valeur appropriée au composant que vous souhaitez déplacer. Vous pouvez utiliser unnodeSelectorau format indiqué ou des paires<key>: <value>, en fonction de la valeur spécifiée pour le nœud. Si vous avez ajouté une taint au nœud d'infrastructure, ajoutez également une tolérance correspondante.
Confirmez que le pod routeur est en cours d'exécution sur le nœud
infra.Affichez la liste des modules de routeur et notez le nom du nœud du module en cours d'exécution :
$ oc get pod -n openshift-ingress -o wide
Exemple de sortie
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES router-default-86798b4b5d-bdlvd 1/1 Running 0 28s 10.130.2.4 ip-10-0-217-226.ec2.internal <none> <none> router-default-955d875f4-255g8 0/1 Terminating 0 19h 10.129.2.4 ip-10-0-148-172.ec2.internal <none> <none>
Dans cet exemple, le pod en cours d'exécution se trouve sur le nœud
ip-10-0-217-226.ec2.internal.Visualiser l'état du nœud du pod en cours d'exécution :
oc get node <node_name> 1- 1
- Spécifiez l'adresse
<node_name>que vous avez obtenue à partir de la liste des pods.
Exemple de sortie
NAME STATUS ROLES AGE VERSION ip-10-0-217-226.ec2.internal Ready infra,worker 17h v1.25.0
Comme la liste des rôles comprend
infra, le pod est exécuté sur le bon nœud.
6.9.2. Déplacement du registre par défaut
Vous configurez l'opérateur de registre pour qu'il déploie ses pods sur différents nœuds.
Conditions préalables
- Configurez des ensembles de machines de calcul supplémentaires dans votre cluster OpenShift Container Platform.
Procédure
Voir l'objet
config/instance:$ oc get configs.imageregistry.operator.openshift.io/cluster -o yaml
Exemple de sortie
apiVersion: imageregistry.operator.openshift.io/v1 kind: Config metadata: creationTimestamp: 2019-02-05T13:52:05Z finalizers: - imageregistry.operator.openshift.io/finalizer generation: 1 name: cluster resourceVersion: "56174" selfLink: /apis/imageregistry.operator.openshift.io/v1/configs/cluster uid: 36fd3724-294d-11e9-a524-12ffeee2931b spec: httpSecret: d9a012ccd117b1e6616ceccb2c3bb66a5fed1b5e481623 logging: 2 managementState: Managed proxy: {} replicas: 1 requests: read: {} write: {} storage: s3: bucket: image-registry-us-east-1-c92e88cad85b48ec8b312344dff03c82-392c region: us-east-1 status: ...Modifiez l'objet
config/instance:$ oc edit configs.imageregistry.operator.openshift.io/cluster
spec: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: namespaces: - openshift-image-registry topologyKey: kubernetes.io/hostname weight: 100 logLevel: Normal managementState: Managed 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- 1
- 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érifiez que le pod de registre a été déplacé vers le nœud d'infrastructure.
Exécutez la commande suivante pour identifier le nœud où se trouve le module de registre :
$ oc get pods -o wide -n openshift-image-registry
Confirmez que le nœud a l'étiquette que vous avez spécifiée :
oc describe node <node_name>
Examinez la sortie de la commande et confirmez que
node-role.kubernetes.io/infrafigure dans la listeLABELS.
6.9.3. Déplacement de la solution de surveillance
La pile de surveillance comprend plusieurs composants, notamment Prometheus, Thanos Querier et Alertmanager. L'opérateur de surveillance des clusters gère cette pile. Pour redéployer la pile de surveillance sur les nœuds d'infrastructure, vous pouvez créer et appliquer une carte de configuration personnalisée.
Procédure
Modifiez la carte de configuration
cluster-monitoring-configet changez la cartenodeSelectorpour qu'elle utilise le labelinfra:$ oc edit configmap cluster-monitoring-config -n openshift-monitoring
apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: |+ alertmanagerMain: nodeSelector: 1 node-role.kubernetes.io/infra: "" tolerations: - key: node-role.kubernetes.io/infra value: reserved effect: NoSchedule - key: node-role.kubernetes.io/infra value: reserved effect: NoExecute prometheusK8s: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - key: node-role.kubernetes.io/infra value: reserved effect: NoSchedule - key: node-role.kubernetes.io/infra value: reserved effect: NoExecute prometheusOperator: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - key: node-role.kubernetes.io/infra value: reserved effect: NoSchedule - key: node-role.kubernetes.io/infra value: reserved effect: NoExecute k8sPrometheusAdapter: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - key: node-role.kubernetes.io/infra value: reserved effect: NoSchedule - key: node-role.kubernetes.io/infra value: reserved effect: NoExecute kubeStateMetrics: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - key: node-role.kubernetes.io/infra value: reserved effect: NoSchedule - key: node-role.kubernetes.io/infra value: reserved effect: NoExecute telemeterClient: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - key: node-role.kubernetes.io/infra value: reserved effect: NoSchedule - key: node-role.kubernetes.io/infra value: reserved effect: NoExecute openshiftStateMetrics: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - key: node-role.kubernetes.io/infra value: reserved effect: NoSchedule - key: node-role.kubernetes.io/infra value: reserved effect: NoExecute thanosQuerier: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - key: node-role.kubernetes.io/infra value: reserved effect: NoSchedule - key: node-role.kubernetes.io/infra value: reserved effect: NoExecute- 1
- 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.
Observez le déplacement des modules de surveillance vers les nouvelles machines :
$ watch 'oc get pod -n openshift-monitoring -o wide'
Si un composant n'a pas été déplacé vers le nœud
infra, supprimez le pod contenant ce composant :oc delete pod -n openshift-monitoring <pod>
Le composant du module supprimé est recréé sur le nœud
infra.
6.9.4. 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
