La serie de pruebas Kubernetes - Pruebas de Rendimiento

prefacio

Para el software, la prueba de funcionamiento comprende generalmente dos partes, la producción de una carga apropiada, el segundo es de carga bajo observado razonable.

La definición del objeto observado

Cualquier rendimiento del sistema son todas las fronteras, la necesidad de asegurar el costo de rendimiento, mano de obra, tiempo, tampoco puede ser sin fin, o toda la gama de requisitos de rendimiento.
El objetivo es desarrollar sistemas de software con el fin de servir mejor a los clientes, los usuarios del sistema tienen requisitos de calidad. Afecta a las exigencias de calidad del rendimiento del usuario es el principal indicadores básicos, otros son indicadores secundarios (tales como los programadores de trasiego nuestro indicadores de cerebros). Por lo tanto, antes de la prueba de rendimiento, para definir qué métricas de usuario afectará a la exigencia de calidad es el trabajo, indicadores, incluso si no está completamente definida. resultados de las pruebas de rendimiento ciegos obtenidos generalmente son insignificantes.

Nube vendedores suelen utilizar el SLA (Service Level Agreement) para resumir los requisitos de calidad de usuario del sistema. Por desgracia, debido a la complejidad de Kubernetes, a partir del 05/18/2019, los principales proveedores de la nube no proporcionan SLA puede finalmente liberado.
Kubernetes ofertas comunitarios algunos SLI (indicadores de nivel de servicio) y el rendimiento del sistema de orientación (Objetivos de Nivel de Servicio) SLO pruebas, análisis, ver la dirección de salto . Estos indicadores se describen indirectamente la calidad de servicio del sistema Kubernetes, es un indicador de enfoque de pruebas de rendimiento.
Además, la CPU de la máquina principal, la memoria y otros indicadores, y otros indicadores de ETCD ioutil también causa un efecto significativo sobre los servicios Kubernetes, y por lo tanto deben ser incluidos en las pruebas de rendimiento observado mismo rango.

La fabricación de carga de clúster

• carga baratos
  datos de la comunidad muestran Kubernetes puede soportar 5.000 Nodo, 15 Wan Pod clúster que ejecuta bien. Este medio de verificación de esta declaración debe ser de al menos 5,000 fabricación Node, 15 carga Wan Pod. Sin embargo, para conseguir que la máquina real de 5000 el derecho a utilizar costosos, ocupación a largo plazo de tantas máquinas para el desarrollo y las pruebas Kubernetes no es científico. Por lo tanto, el desarrollo de la comunidad kubemarky Virtual Kubeletotras herramientas utilizadas para simular el verdadero nodo, utilice una pequeña cantidad de la máquina también puede producir una carga suficientemente grande. Durante la prueba de mijo, 20 máquina real puede simular 3000 Node, cargar 100 000 Pod de.
• Una variedad de carga
  en el entorno de funcionamiento real, la carga real es variado, diferente carga puede tener diferentes efectos sobre el rendimiento del sistema para simular una variedad de condiciones de carga durante la prueba es necesaria. Con el fin de facilitar una variedad de carga simulada, el programa de pruebas de rendimiento puede ser configurado para proporcionar una resistencia de carga debe ser tan fuerte como sea posible. En el código Kubernetes temprano, los parámetros del programa de prueba de rendimiento escritos en código muerto, para modificar el código fuente para recompilación después Kubernetes, copiado en el entorno de prueba, los parámetros de prueba se pueden cambiar sólo una vez. proceso de prueba es muy doloroso.
  Por lo tanto, la comunidad desarrolló Perf-Test / clusterloader2 , altamente configurable, y está equipado con indicadores de rendimiento que observan el código correspondiente, lo recomiendo encarecidamente.

instrucciones para la herramienta

pruebas de rendimiento Kubernetes de pre-requisitos:

• Bien preparado para ejecutar un conjunto de Kubernetes

Este artículo describe las siguientes herramientas de pruebas de rendimiento kubemark y Perf-Test / clusterloader2 .

kubemark

kubemark es una versión castrado de kubelet, además de no llamar a las interfaces de CRI (es decir, no llame acoplable, directamente de nuevo), y otros actos kubelet básicamente el mismo.

Compilar

• Binario compilado
  fuente descarga kubernetes, ejecutarmake WHAT='cmd/kubemark'
• Reflejando compilado
  compilado escritura de espejo ventana acoplable prueba / kubemark / start-kubemark.sh porque implica una cierta transformación de código, que no voy a explicar.

Use los pasos

• Marcamos verdad Nodo
  1. Conjunto Mancha
  asume el nombre de nodo mytestnode, ejecute el siguiente comando para establecer la Mancha.
  kubectl taint nodes mytestnode role=real:NoSchedule
  Mancha proporciona propósito es evitar las pruebas de resistencia a la programación real de la vaina de nodo.
  2. Conjunto de la etiqueta
  asume el nombre de nodo mytestnode, ejecute el siguiente comando para establecer la etiqueta.
  kubectl label nodes mytestnode role=real
• kubeconfig configuración

apiVersion: v1
kind: Config
users:
- name: kubelet
  user: {}
clusters:
- name: kubemark
  cluster:
    server: http://10.114.25.172:8083 #替换成你自己的APIServer地址
contexts:
- context:
    cluster: kubemark
    user: kubelet
  name: kubemark-context
current-context: kubemark-context

Si el kubeconfig anteriormente guardados /home/mi/.kube/config, ejecute el siguiente comando para crear un secreto

kubectl create secret generic kubeconfig --from-file=kubelet.kubeconfig=/home/mi/.kube/config

• La creación de kubemark Pod
  ejecutar la siguiente secuencia de comandos para kubemark de ejecución:

curl -L https://gist.githubusercontent.com/Betula-L/fef068ef7e914aa4a52113ac81fc6517/raw/77abf3f9b234274e33435597dec079ef46300324/kubemark.yaml | kubectl apply -f -

precauciones

• try y maestros versiones kubemark de la misma versión
• La descripción anterior no se aplica volvió autenticación y autorización maestro

clusterloader2

Los requisitos operativos

• nodo maestro servicio SSH abierto
• hora de inicio de prueba para todos nodo en el estado Ready (incluyendo el nodo hueco)

Compilar

Descarga pert-tests proyectar , ejecutar ${perf-tests}/clusterloader2/run-e2e.sho compilar un guión sigue un archivo binario.

CLUSTERLOADER_ROOT=${perf-tests}
cd ${CLUSTERLOADER_ROOT}/ && go build -o clusterloader './cmd/'

Use los pasos

• Establecer las variables de Medio Ambiente

# kube config for kubernetes api
KUBE_CONFIG=${HOME}/.kube/config

# Provider setting
# Supported provider for xiaomi: local, kubemark, lvm-local, lvm-kubemark
PROVIDER='kubemark'

# SSH config for metrics' collection
KUBE_SSH_KEY_PATH=$HOME/.ssh/id_rsa
MASTER_SSH_IP=10.142.43.51
MASTER_SSH_USER_NAME=root

# Clusterloader2 testing strategy config paths
# It supports setting up multiple test strategy. Each testing strategy is individual and serial.
TEST_CONFIG='configs/examples/density/config.yaml'

# Clusterloader2 testing override config paths
# It supports setting up multiple override config files. All of override config files will be applied to each testing strategy.
# OVERRIDE_CONFIG='testing/density/override/200-nodes.yaml'

# Log config
REPORT_DIR='./reports'
LOG_FILE='logs/tmp.log'

Llena con el contenido de la secuencia de comandos, y utilizar el sourceconjunto de comandos de las variables de entorno Linux

• Ejecutar clusterloader2

$CLUSTERLOADER_BIN --kubeconfig=$KUBE_CONFIG \
    --provider=$PROVIDER \
    --masterip=$MASTER_SSH_IP --mastername=$MASTER_SSH_USER_NAME \
    --testconfig=$TEST_CONFIG \
    --report-dir=$REPORT_DIR \
    --alsologtostderr 2>&1 | tee $LOG_FILE
#   --testoverrides="${OVERRIDE_CONFIG:-}" \

Clusterloader2 encima de comando de operación, en el que CLUSTERLOADER_BINunos binarios compilados clusterloader2 posición, los otros parámetros son un conjunto bien variables de entorno.

DESCRIPCIÓN DE LA pRUEBA

PERT-pruebas sólo pruebas de rendimiento marco, el cumplimiento específico probando estrategia requiere que el usuario defina su propio a través de un archivo de configuración.
A prueba de densidad kubernetes , por ejemplo, explicar el proceso de pruebas de clusterloader2 y sus resultados.
estrategia de las pruebas de densidad

1. Para iniciar varios programas de observación
   en el fichero de configuración política de prueba , todos de medida se emplean para la recolección de datos del programa de observación. Potencia-pruebas proporcionan una docena de la Medición , densidad, en el que cinco pruebas utilizados, incluyendo APIResponsiveness, SaturationPodStartupLatency, WaitForRunningSaturationRCs, SchedulingThroughput, PodStartupLatency.
2. sistema de programación de rendimiento de ensayo
   kubernetes que cada nodo 30 Pod está en funcionamiento de carga normal de la máquina. liberación Disposable #node*30un programado rendimiento para el ensayo de clúster Pod puede "fallo del sistema de escala completa ocurre, el tiempo de recuperación de cero a la carga normal deseada", definido como un cierto horario:
     　 　 　 　 调度吞吐量=一段较长时间内最大可以发布的Pod数量/总发布时间
   Notablemente, clusterloader2 no simplemente utilizando un rc crear #node*30una vaina, ya que el uso del sistema Kubernetes algunos supuestos básicos, entre ellos el "número de no más de espacio de nombres de cada vaina 3000", "número de vainas por nodo no puede superar los 110". Con el fin de cumplir con estas premisas básicas, clusterloader2 al crear rc, hacemos un montón de tratamiento especial.
3. Pod empezar E2E tiempo pruebas
   para ilustrar la vaina se inicia E2E, sin borrar base mucho tiempo "programación de rendimiento de pruebas" de carga, la prueba de latencia.
   estrategia de prueba de latencia es crear una vaina cada 0,2 segundos, de acuerdo con la marca de tiempo y crea generado evento durante pod calculado proceso de arranque Pod, cada etapa de la e2e total de lento y consume mucho tiempo. Si el 调度吞吐量<5pods/sse crea el intervalo de tiempo de la vaina debe ser mayor que 0,2 s.
   Actualmente problemas de precisión de la prueba de latencia, ya que el tiempo de almacenamiento caso kubernetes es RFC3339, lo que resulta en la etapa de precisión mucho tiempo sólo en la segunda parte, no en el desempeño de valor analítico.

   

   estrategia de las pruebas de densidad

resultados de la prueba

• stdout / stderr
  pruebas de rendimiento general y algunos de los resultados de la prueba se imprimirán en stdout, si el clusterloader2 de ejecución por los métodos descritos en el presente documento, a un resultado de impresión se guardará ${LOG_FILE}.

调度吞吐量结果:
Jan  9 13:55:47.876: INFO: E2E startup time for 10500 pods: 28m40.333662404s
Jan  9 13:55:47.876: INFO: Throughput (pods/s) during cluster saturation phase: 6.1034675
^[[1mSTEP^[[0m: Printing Pod to Node allocation data
Jan  9 13:55:47.884: INFO: Density Pods: 10500 out of 10500 created, 10500 running, 0 pending, 0 waiting, 0 inactive, 0 terminating, 0 unknown, 0 runningButNotReady

Pod启动e2e耗时结果:
Jan  9 14:09:31.598: INFO: perc50: 1614, perc90: 2241, perc99: 2541
Jan  9 14:09:31.598: INFO: Approx throughput: 7486.052881923156 pods/min

• carpetas de informes
  detallados resultados de las pruebas de rendimiento recopilados en la carpeta clusterloader2 informe, si se ejecuta de acuerdo con el método propuesto, el resultado se almacena en {$REPORT_DIR}el. Debido a que muy involucrado en los resultados de las pruebas de rendimiento, este artículo no es para enumerarlos aquí. Actualmente análisis de rendimiento Kubernetes la mayoría de los indicadores de rendimiento importantes son los siguientes:
  • APIServer reparador tiempo de respuesta del API - APIResponsiveness
  • Pod iniciar tiempo total - PodStartupLatency
  • rendimiento de la programación Programador - SchedulingThroughput, SchedulingMetrics
  • Índice ETCD - EtcdMetrics