Cómo ajustar el rendimiento del nodo

Vista previa

Este producto o función está sujeto a las "Condiciones de la Oferta de la Fase Previa a la DG" en la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Los productos y las funciones de la fase previa a la DG están disponibles "sin modificaciones" y pueden estar sujetos a asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Una forma de mejorar el rendimiento de las aplicaciones basadas en contenedores es aumentar los recursos del clúster agregando nodos o recursos, como CPUs o memoria, a tus nodos. Sin embargo, este enfoque puede resultar costoso. Ajustar los nodos de tu clúster para obtener un mejor rendimiento te ayuda a optimizar la utilización de recursos para tus cargas de trabajo de una manera rentable. En este documento, se describe cómo usar Performance Tuning Operator para ajustar los nodos de trabajadores y optimizar el rendimiento de las cargas de trabajo en Google Distributed Cloud.

Para aprovechar al máximo el hardware y el software subyacentes, los diferentes tipos de aplicaciones, en especial las de alto rendimiento, se benefician de la optimización de la configuración de los nodos, como la siguiente:

• CPUs dedicadas para cargas de trabajo sensibles al rendimiento
• CPUs reservadas para los daemons y servicios estándar de Kubernetes
• Se aumentaron los tamaños de página de memoria con hugepages de 1 GiB (gibibyte) o 2 MiB (mebibyte)
• Distribución de la carga de trabajo según la arquitectura del sistema, como procesadores multinúcleo y NUMA

Con el operador de ajuste del rendimiento, puedes configurar los parámetros de rendimiento a nivel del nodo creando recursos personalizados de Kubernetes que apliquen configuraciones de rendimiento. Estos son los beneficios:

• Interfaz de configuración única y unificada: Con el operador de ajuste del rendimiento, actualizas uno o más manifiestos de PerformanceTuningProfile que se pueden aplicar a nodos trabajadores con selectores de nodos. No es necesario que configures cada nodo de forma individual con varios parámetros de configuración y políticas. Este enfoque te permite administrar la configuración a nivel del nodo y del contenedor de una manera única y unificada.

• Persistencia y confiabilidad: También obtienes toda la confiabilidad que proporciona Kubernetes con su arquitectura de alta disponibilidad. Los recursos personalizados de PerformanceTuningProfile se pueden actualizar cuando quieras, y su configuración persiste en las principales operaciones del clúster, como las actualizaciones.

El operador de ajuste de rendimiento funciona con la organización de las siguientes funciones y herramientas de Kubernetes y el sistema operativo (SO) relacionadas con el rendimiento:

• Administrador de memoria
• CPU Manager
• Administrador de topología
• TuneD

Para evitar conflictos, cuando uses el operador de ajuste de rendimiento, te recomendamos que no uses las herramientas y funciones de Kubernetes y del SO mencionadas anteriormente de forma independiente.

Requisitos previos y limitaciones

Estos son los requisitos previos y las limitaciones para usar el operador de ajuste del rendimiento:

• Solo para Red Hat Enterprise Linux (RHEL): El operador de ajuste del rendimiento solo es compatible con los nodos que ejecutan versiones compatibles de RHEL.

• Clúster híbrido o de usuario con nodos trabajadores: El operador de ajuste del rendimiento solo se admite para su uso con nodos trabajadores en clústeres híbridos o de usuario. No se admite el uso del operador de ajuste del rendimiento para ajustar los nodos del plano de control. El operador de ajuste de rendimiento usa un selector de nodos para determinar cómo aplicar los perfiles de ajuste. Para garantizar que los perfiles de ajuste se apliquen solo a los nodo trabajador, el nodeSelector en cada recurso personalizado del perfil debe incluir la etiqueta estándar del nodo trabajador node-role.kubernetes.io/worker: "". Si el nodeSelector de un perfil de ajuste coincide con las etiquetas de un nodo del plano de control, ese nodo no se ajusta y se establece una condición de error. Para obtener más información sobre las condiciones de error, consulta Verifica el estado. Asegúrate de que tu clúster funcione correctamente antes de instalar el operador de ajuste de rendimiento y aplicar perfiles de ajuste.

• TuneD 2.22.0: El operador de ajuste de rendimiento requiere que la versión 2.22.0 de TuneD esté preinstalada en los nodos de trabajador que deseas ajustar. Para obtener más información sobre TuneD, incluidas las instrucciones de instalación, consulta Cómo comenzar a usar TuneD en la documentación de Red Hat Enterprise Linux. El operador de ajuste del rendimiento usa TuneD con el perfil cpu-partitioning. Si no tienes este perfil, puedes instalarlo con el siguiente comando:

  dnf install -y tuned-profiles-cpu-partitioning
  

• Requisitos de recursos de la carga de trabajo: Para aprovechar al máximo el ajuste del rendimiento, debes comprender bien los requisitos de memoria y CPU (solicitudes y límites de recursos) de tus cargas de trabajo.

• Recursos de nodos disponibles: Encuentra los recursos de CPU y memoria para tus nodos. Puedes obtener información detallada sobre la CPU y la memoria de tu nodo en los archivos /proc/cpuinfo y /proc/meminfo, respectivamente. También puedes usar kubectl get nodes para recuperar la cantidad de recursos de procesamiento y memoria (status.allocatable) que tiene un nodo trabajador disponibles para los Pods.

• Requiere drenaje: Como parte del proceso de ajuste, el operador de ajuste de rendimiento primero drena los nodos y, luego, aplica un perfil de optimización. Como resultado, es posible que los nodos informen un estado NotReady durante el ajuste del rendimiento. Te recomendamos que uses la estrategia de actualización progresiva (spec.updateStrategy.type: rolling) en lugar de una actualización por lotes para minimizar la falta de disponibilidad de la carga de trabajo.

• Requiere reinicio: Para que se apliquen los cambios de ajuste del nodo, el operador de ajuste de rendimiento reinicia el nodo después de aplicar el perfil de ajuste.

Instala el operador de ajuste de rendimiento

El operador de ajuste del rendimiento consta principalmente de dos controladores (un Deployment y un DaemonSet) que interactúan entre sí para ajustar los nodos según la configuración de tu perfil. De forma predeterminada, Performance Tuning Operator no se instala con Google Distributed Cloud. Descargas los manifiestos del operador de ajuste del rendimiento desde Cloud Storage y usas kubectl apply para crear recursos del operador de ajuste del rendimiento en tu clúster.

Para habilitar el ajuste del rendimiento con valores predeterminados para tu clúster, haz lo siguiente:

1. Crea un directorio performance-tuning en tu estación de trabajo de administrador.

2. Desde el directorio performance-tuning, descarga el paquete más reciente del operador de ajuste del rendimiento desde el bucket de versiones de Cloud Storage:

   gcloud storage cp gs://anthos-baremetal-release/node-performance-tuning/0.1.0-gke.47 . --recursive
   

   Los archivos descargados incluyen manifiestos para el Deployment performance-tuning-operator y el DaemonSet nodeconfig-controller-manager. También se incluyen manifiestos para funciones relacionadas, como el control de acceso basado en roles (RBAC) y el control de admisión dinámico.

3. Como usuario raíz, aplica todos los manifiestos del operador de ajuste del rendimiento de forma recursiva a tu clúster de usuario (o híbrido):

   kubectl apply -f performance-tuning --recursive –-kubeconfig USER_KUBECONFIG
   

   Una vez que se crean y ejecutan la Deployment y el DaemonSet, tu única interacción es editar y aplicar manifiestos de PerformanceTuningProfile.

Revisa los requisitos de recursos de tus cargas de trabajo

Antes de ajustar los nodos, debes comprender los requisitos de recursos de procesamiento y memoria de tus cargas de trabajo. Si tus nodos de trabajo tienen recursos suficientes, se pueden ajustar para proporcionar memoria garantizada (estándar y hugepages) para tus cargas de trabajo en la clase de calidad de servicio (QoS) garantizada.

Kubernetes asigna clases de QoS a cada uno de tus Pods según las restricciones de recursos que especifiques para los contenedores asociados. Luego, Kubernetes usa las clases de QoS para determinar cómo programar tus Pods y contenedores, y asignar recursos a tus cargas de trabajo. Para aprovechar al máximo el ajuste de nodos para tus cargas de trabajo, estas deben tener solicitudes de recursos de CPU o memoria, o bien parámetros de configuración de límites.

Para que se les asigne una clase de QoS garantizada, tus Pods deben cumplir con los siguientes requisitos:

• Para cada contenedor del Pod, haz lo siguiente:
  • Especifica valores para las solicitudes de recursos de memoria (spec.containers[].resources.requests.memory) y los límites (spec.containers[].resources.limits.memory).
  • El valor de los límites de memoria debe ser igual al valor de las solicitudes de memoria.
  • Especifica valores para las solicitudes de recursos de CPU (spec.containers[].resources.requests.cpu) y los límites (spec.containers[].resources.limits.cpu).
  • El valor de los límites de CPU debe ser igual al valor de las solicitudes de CPU.

En el siguiente fragmento de la especificación del Pod, se muestran los parámetros de configuración de los recursos de CPU que cumplen con los requisitos de la clase de QoS garantizada:

spec:
  containers:
  - name: sample-app
    image: images.my-company.example/app:v4
    resources:
      requests:
        memory: "128Mi"
        cpu: "2"
      limits:
        memory: "128Mi"
        cpu: "2"
  ...

Cuando recuperas los detalles del Pod con kubectl get pods, la sección status debe incluir la clase QoS asignada, como se muestra en el siguiente ejemplo:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2023-09-22T21:05:23Z"
  generateName: my-deployment-6fdd69987d-
  labels:
    app: metrics
    department: sales
    pod-template-hash: 6fdd69987d
  name: my-deployment-6fdd69987d-7kv42
  namespace: default
  ...
spec:
  containers:
  ...
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2023-09-22T21:05:23Z"
    status: "True"
    type: Initialized
  ...
  qosClass: BestEffort
  startTime: "2023-09-22T21:05:23Z"

Para obtener más información sobre las clases de QoS, consulta Clases de calidad de servicio de los pods en la documentación de Kubernetes. Si deseas obtener instrucciones para configurar tus Pods y contenedores de modo que se les asigne una clase de QoS, consulta Configura la calidad de servicio para los Pods.

Requisitos de CPU

Cuando ajustas un nodo, puedes especificar un conjunto de núcleos de CPU reservados (spec.cpu.reservedCPUs) para ejecutar daemons del sistema de Kubernetes, como kubelet y el tiempo de ejecución del contenedor. Este mismo conjunto de CPUs reservadas también ejecuta daemons del sistema operativo, como sshd y udev. El resto de los núcleos de CPU se asignan como aislados. Las CPUs aisladas están diseñadas para aplicaciones limitadas por la CPU, que requieren tiempo de CPU dedicado sin interferencias de otras aplicaciones o interrupciones de la red o de otros dispositivos.

Para programar un Pod en las CPU aisladas de un nodo trabajador, haz lo siguiente:

• Configura el Pod para una calidad de servicio (QoS) garantizada.

• Los requisitos y límites de CPU deben especificarse en números enteros. Si especificas recursos de CPU parciales en la especificación del Pod, como cpu: 0.5 o cpu: 250m (250 millicores), no se puede garantizar la programación.

Requisitos de la memoria

Cuando ajustas un nodo con el operador de ajuste de rendimiento, puedes crear hugepages y asociarlas con los nodos de acceso a la memoria no uniforme (NUMA) de la máquina. Según la configuración de los Pods y los nodos, los Pods se pueden programar con afinidad de nodo NUMA.

Crea un perfil de ajuste de rendimiento

Después de instalar el operador de ajuste del rendimiento, solo interactúas con el clúster que ejecuta tus cargas de trabajo. Creas recursos personalizados de PerformanceTuningProfile directamente en tu clúster de usuario o clúster híbrido, no en tu clúster de administrador. Cada recurso PerformanceTuningProfile contiene un conjunto de parámetros que especifican la configuración de rendimiento que se aplica a un nodo.

El nodeSelector en el recurso determina los nodos a los que se aplica el perfil de ajuste. Para aplicar un perfil a un nodo, coloca la etiqueta del par clave-valor correspondiente en el nodo. Se aplica un perfil de ajuste a los nodos que tienen todas las etiquetas especificadas en el campo nodeSelector.

Puedes crear varios recursos PerformanceTuningProfile en un clúster. Si más de un perfil coincide con un nodo determinado, se establece una condición de error en el status del recurso personalizado PerformanceTuningProfile. Para obtener más información sobre la sección status, consulta Verifica el estado.

Establece el espacio de nombres de tu recurso personalizado de PerformanceTuningProfile en kube-system.

Para ajustar uno o más nodos trabajadores, haz lo siguiente:

1. Editar el manifiesto PerformanceTuningProfile.

   Para obtener información sobre cada campo del manifiesto y un manifiesto de ejemplo, consulta la referencia del recurso PerformanceTuningProfile.

2. Para los nodos trabajadores a los que aplicas un perfil, agrega etiquetas que coincidan con el par clave-valor spec.nodeSelector (opcional).

   Si no se especifica ningún par clave-valor de spec.nodeSelector en el recurso personalizado PerformanceTuningProfile, el perfil se aplica a todos los nodos trabajadores.

3. Aplica el manifiesto al clúster.

   kubectl apply -f PROFILE_MANIFEST --kubeconfig KUBECONFIG
   

   Reemplaza lo siguiente:

   • PROFILE_MANIFEST: Es la ruta de acceso al archivo de manifiesto del recurso personalizado PerformanceTuningProfile.
   • KUBECONFIG: la ruta del archivo kubeconfig del clúster

Cómo quitar un perfil de ajuste

Para restablecer un nodo a su estado original sin ajustar, haz lo siguiente:

1. Borra el recurso personalizado PerformanceTuningProfile del clúster :

2. Actualiza o quita las etiquetas del nodo para que el perfil de ajuste no lo vuelva a seleccionar.

Si tienes varios perfiles de ajuste asociados con el nodo, repite los pasos anteriores según sea necesario.

Cómo pausar un perfil de ajuste

Si necesitas realizar tareas de mantenimiento en tu clúster, puedes pausar temporalmente el ajuste editando el recurso personalizado PerformanceTuningProfile. Te recomendamos que pauses el ajuste antes de realizar operaciones críticas del clúster, como una actualización del clúster.

Otro caso en el que puedes pausar el ajuste es cuando no se aprueba la solicitud de perfil. Si el proceso de ajuste no se realiza correctamente, es posible que el controlador siga intentando ajustar el nodo, lo que puede provocar que el nodo se reinicie una y otra vez. Si observas que el estado del nodo cambia entre listo y no listo, pausa el ajuste para que puedas recuperarte del estado dañado.

Para pausar el ajuste, haz lo siguiente:

1. Edita el manifiesto del recurso personalizado PerformanceTuningProfile para establecer spec.paused en true.

2. Usa kubectl apply para actualizar el recurso.

Cuando se pausa el ajuste de rendimiento, el controlador del operador de ajuste de rendimiento detiene todas sus operaciones. La pausa evita el riesgo de que las operaciones del controlador del operador de ajuste del rendimiento entren en conflicto con las operaciones de cualquier controlador de Google Distributed Cloud.

Referencia del recurso PerformanceTuningProfile

En esta sección, se describe cada uno de los campos del recurso personalizado PerformanceTuningProfile. Este recurso se usa para crear un perfil de ajuste para uno o más nodos del clúster. Todos los campos del recurso son mutables después de la creación del perfil. Los perfiles deben estar en el espacio de nombres kube-system.

El siguiente manifiesto de perfil de muestra numa para nodos con 8 núcleos de CPU especifica las siguientes asignaciones de recursos:

• Se reservan 4 núcleos de CPU (0-3) para la sobrecarga del sistema de Kubernetes.

• Se reservan 4 núcleos de CPU (4-7) solo para las cargas de trabajo.

• De forma predeterminada, la memoria del nodo se divide en páginas de 2 MiB en lugar de las páginas estándar de 4 KiB.

• Se reservan 10 páginas de memoria de 1 GiB para el uso del nodo NUMA 0.

• Se reservan 5 páginas de memoria de 2 MiB para el uso del nodo NUMA 1.

• Topology Manager usa la política de mejor resultado posible para programar cargas de trabajo.

apiVersion: anthos.gke.io/v1alpha1
kind: PerformanceTuningProfile
metadata:
  name: numa
  namespace: kube-system
spec:
  cpu:
    isolatedCPUs: 4-7
    reservedCPUs: 0-3
  defaultHugepagesSize: 2M
  nodeSelector:
    app: database
    node-role.kubernetes.io/worker: ""
  pages:
  - count: 10
    numaNode: 0
    size: 1G
  - count: 5
    numaNode: 1
    size: 2M
  topologyManagerPolicy: best-effort

Puedes recuperar la definición del recurso personalizado PerformanceTuningProfile relacionado del grupo anthos.gke.io en tu clúster. La definición de recursos personalizados se instala una vez que se agrega la anotación de la función de versión preliminar al recurso del clúster administrado por el usuario.

Configuración de CPU

Propiedad	Descripción
cpu.reservedCPUs	Obligatorio. Mutable. String. Este campo define un conjunto de núcleos de CPU que se reservarán para los daemons del sistema de Kubernetes, como kubelet, el entorno de ejecución del contenedor y el detector de problemas del nodo. Estos núcleos de CPU también se usan para los daemons del sistema operativo (SO), como sshd y udev. El campo cpu.reservedCPUs toma una lista de números de CPU o rangos de números de CPU. Asegúrate de que la lista de CPUs no se superponga con la lista especificada con cpu.isolatedCPUs. La unión de las CPUs que se indican en estos dos campos debe incluir todas las CPUs del nodo.
cpu.isolatedCPUs	Opcional. Mutable. String. El campo cpu.isolatedCPUs define un conjunto de CPU que se usan exclusivamente para aplicaciones sensibles al rendimiento. El CPU Manager programa los contenedores solo en las CPUs no reservadas, según las clases de Calidad de servicio (QoS) de Kubernetes. Para garantizar que las cargas de trabajo se ejecuten en las CPU aisladas, configura los Pods con la clase de QoS garantizada y asigna un recurso de CPU al Pod o al contenedor. Para garantizar la programación de Pods, debes especificar unidades de CPU como números enteros, no recursos de CPU parciales (cpu: "0.5"). apiVersion: v1 kind: Pod ... spec: containers: ... resources: limits: cpu: "1" requests: cpu: "1" ... Maximizar las CPUs aisladas para las cargas de trabajo proporciona el mejor beneficio de rendimiento. Este campo toma una lista de números de CPU o rangos de números de CPU. Asegúrate de que la lista de CPU no se superponga con la lista especificada con cpu.reservedCPUs y de que la unión de las listas en estos dos campos incluya todas las CPU del nodo.
cpu.balanceIsolated	Opcional. Mutable. Booleano. Valor predeterminado: true. Este campo especifica si el conjunto de CPU aisladas es apto para el balanceo de cargas automático de las cargas de trabajo en las CPU. Cuando estableces este campo en false, tus cargas de trabajo deben asignar cada subproceso de forma explícita a una CPU específica para distribuir la carga entre las CPUs. Con las asignaciones explícitas de CPU, obtienes el rendimiento más predecible para las cargas de trabajo garantizadas, pero se agrega más complejidad a tus cargas de trabajo.
cpu.globallyEnableIRQLoadBalancing	Obligatorio. Mutable. Booleano. Valor predeterminado: true. Este campo especifica si se debe habilitar o no el balanceo de cargas de solicitudes de interrupción (IRQ) para el conjunto de CPU aisladas.

Configuración de la memoria

Propiedad	Descripción
defaultHugePageSize	Opcional. Mutable. Enumeración: 1G o 2M. Este campo define el tamaño predeterminado de las hugepages en los parámetros de inicio del kernel. Las páginas enormes se asignan en el momento del arranque, antes de que la memoria se fragmente. Es importante tener en cuenta que establecer el tamaño predeterminado de las páginas grandes en 1 G quita todas las carpetas relacionadas con 2 M del nodo. Un tamaño predeterminado de página enorme de 1 G impide que configures páginas enormes de 2 M en el nodo.
pages	Opcional. Mutable. Número entero. Este campo especifica la cantidad de hugepages que se crearán durante el inicio. Este campo acepta un array de páginas. Verifica la memoria disponible para tus nodos antes de especificar páginas enormes. No solicites más hugepages de las necesarias ni reserves toda la memoria para ellas. Tus cargas de trabajo también necesitan memoria estándar.

Selección de nodos

Propiedad

Descripción

nodeSelector

Obligatorio. Mutable. Este campo siempre requiere la etiqueta del nodo trabajador de Kubernetes, node-role.kubernetes.io/worker:"", que garantiza que el ajuste del rendimiento se realice solo en los nodos trabajadores. Este campo toma una etiqueta de nodo opcional como un par clave-valor. Las etiquetas de pares clave-valor se usan para seleccionar nodos trabajador específicos con etiquetas coincidentes. Cuando las etiquetas nodeSelector coinciden con las etiquetas de un nodo trabajador, se aplica el perfil de rendimiento a ese nodo. Si no especificas una etiqueta de par clave-valor en tu perfil, se aplicará a todos los nodos trabajadores del clúster. Por ejemplo, el siguiente nodeSelector especifica que el perfil de ajuste se aplica solo a los nodos trabajadores con etiquetas app: database coincidentes: ... spec: nodeSelector: app: database node-role.kubernetes.io/worker: "" ...

Configuración de Kubelet

Propiedad

Descripción

topologyManagerPolicy

Opcional. Mutable. Enumeración: none, best-effort, restricted o single-numa-node. Valor predeterminado: best-effort. Este campo especifica la política del Administrador de topología de Kubernetes que se usa para asignar recursos a tus cargas de trabajo, según la clase de calidad de servicio (QoS) asignada. Para obtener más información sobre cómo se asignan las clases de QoS, consulta Configura la calidad de servicio para los Pods.

Operaciones de perfil

Propiedad	Descripción
paused	Opcional. Mutable. Booleano. Establece paused en true para evitar temporalmente que los controladores de DaemonSet ajusten los nodos seleccionados.
updateStrategy	Opcional. Mutable. Especifica la estrategia para aplicar los cambios de configuración de ajuste a los nodos seleccionados.
updateStrategy.rollingUpdateMaxUnavailalble	Opcional. Mutable. Número entero. Valor predeterminado: 1. Especifica la cantidad máxima de nodos que se pueden ajustar al mismo tiempo. Este campo solo se aplica cuando type se configura como rolling.
updateStrategy.type	Opcional. Mutable. Enumeración: batch o rolling. Valor predeterminado: rolling. Especifica cómo aplicar las actualizaciones de perfil a los nodos seleccionados. Si deseas aplicar la actualización a todos los nodos seleccionados al mismo tiempo, establece type en batch. De forma predeterminada, las actualizaciones se lanzan de forma secuencial a los nodos individuales, uno tras otro.

Verificar el estado

Después de que se crea o actualiza el recurso personalizado PerformanceTuningProfile, un controlador ajusta los nodos seleccionados según la configuración proporcionada en el recurso. Para verificar el estado de PerformanceTuningProfile, exponemos el siguiente campo en Status:

Propiedad	Descripción
conditions	El atributo Condition representa las últimas observaciones disponibles del estado actual del recurso de perfil.
conditions.lastTransitionTime	Siempre se devuelve. Cadena (en formato de fecha y hora). Es la última vez que la condición pasó de un estado a otro. Por lo general, esta fecha indica cuándo cambió la condición subyacente. Si no se conoce esa fecha y hora, indica cuándo cambió el campo de la API.
conditions.message	Opcional. String. Es un mensaje legible que indica detalles sobre la transición. Este campo puede estar vacío.
conditions.observedGeneration	Opcional. Número entero. Si se configura, este campo representa el metadata.generation en el que se basó la condición. Por ejemplo, si metadata.generation es 12, pero status.condition[x].observedGeneration es 9, la condición está desactualizada con respecto al estado actual de la instancia.
conditions.reason	Obligatorio. String. Es el motivo de la última transición de la condición.
conditions.status	Obligatorio. Estado de la condición: True, False o Unknown.
conditions.type	Obligatorio. El tipo es el tipo de condición: Stalled o Reconciling.
readyNodes	Es la cantidad de nodos a los que se aplicó correctamente el perfil de ajuste.
reconcilingNodes	Es la cantidad de nodos seleccionados (o seleccionados anteriormente) que están en proceso de reconciliación con el perfil de ajuste más reciente por parte del DaemonSet de nodeconfig-controller-manager.
selectedNodes	Es la cantidad de notas que se seleccionaron. Es decir, la cantidad de nodos que coinciden con el selector de nodos para este recurso personalizado PerformanceTuningProfile.

¿Qué sigue?

• Configura las herramientas de redes de SR-IOV
• Rendimiento de etcd