Expansión y contracción automática de pod de Kubernetes y principio de HPA

En escenarios comerciales reales, a menudo nos encontramos con escenarios en los que un servicio necesita expandirse (por ejemplo: prueba de estrés, pico de comercio electrónico, gran promoción, o debido a limitaciones de recursos, reducción de la carga de trabajo, etc., necesitamos verificar la cantidad de instancias de servicio. Operaciones de expansión). En Kubernetes, el mecanismo de escala de implementación / RC se puede utilizar para facilitar las operaciones de escala automatizadas.

Escalado de Kubernetes

La expansión y contracción de Pod de Kubernetes se divide en dos tipos: manual y automático

1. Modo manual

En el modo manual, la cantidad de copias de pod se establece para una implementación / RC a través del comando kubectl scale. Se puede hacer con un clic.

Ejemplo:

escala de gato.yaml

---
apiVersion: aplicaciones / v1
tipo: Despliegue
metadatos:
  nombre: ops-nginx
  espacio de nombres: ops
Especificaciones:
  selector:
    matchLabels:
      aplicación: ops-nginx
  réplicas: 1 
  modelo:
    metadatos:
      etiquetas:
        aplicación: ops-nginx
    Especificaciones:
      imagePullSecrets:
      - nombre: cd-registro
      contenedores:
      - imagen: harbour.ttsingops.com/nginx/nginx:1.16.0
        nombre: ops-nginx

kubectl apply -f scale.yaml

kubectl obtener po -n ops

#Expandir

kubectl scale deployment ops-nginx -n ops --replicas 5

Operación #Shrink

implementación de escala kubectl ops-nginx -n ops --replicas 2

kubectl obtener po -n ops

2. Modo automático

El usuario debe expandirse y contraerse de acuerdo con un determinado índice de rendimiento o según el índice personalizado de Prometheus, y el sistema cambiará y se ajustará automáticamente de acuerdo con el índice de rendimiento dentro de este rango.

Introducción a HAP

HPA (Escalador automático de pod horizontal, Escalador automático horizontal de pod) se introdujo desde Kubernetes V1.1. Se utiliza para realizar la función de expansión y contracción automática de Pod según el uso de la CPU. El controlador HPA se basa en la duración definida por el parámetro de inicio del servicio kube-controller-manager del maestro: horizontal-pod-autoscaler-sync-period, detecta periódicamente el uso de CPU del Pod de destino y verifica el RC o la implementación cuando se cumplen las condiciones. La cantidad de copias de pod se ajusta para cumplir con el uso promedio de CPU de pod definido por el usuario.

Evolución de la versión de HPA:

HPA admite actualmente tres versiones principales: autoescalado / v1, autoescalado / v2beta1 y autuscaling / v2beta2.

¿Cuál es la diferencia entre estas tres versiones?

La versión de autoescalado / v1 solo admite el escalado horizontal de pod con un indicador de CPU.

El autoescalado / v2beta1 agrega soporte para indicadores personalizados. Además de los indicadores expuestos por ca went, también admite indicadores personalizados, como QPS proporcionado por un tercero, o expansión basada en algunos otros recursos, que es para admitir algunos componentes de terceros. .

Autoescaling / v2beta2 agrega soporte de indicador externo

¿El principio de expansión y contracción automática de HPA?

Metrics Server en Kubernetes recopila continuamente los datos de métricas de todas las copias de pod. El controlador de HPA obtiene estos datos a través de la API de Metrics Server (API de Heapster o API de agregación, que se ha quedado obsoleta lentamente y usa Metrice Server) y calcula en función de las reglas de escala definidas para obtener el número de copias de Pod de destino. Cuando el número de copias del Pod de destino es diferente del número de copias actuales, el controlador de HPA inicia una operación de escala en el controlador de copia del Pod (RC / Deployment) para ajustar el número de copias del Pod para completar la operación de escalado.

Pensando:

Si el uso de CPU de un Pod aumenta repentinamente dentro de un cierto período de tiempo y luego disminuye inmediatamente, ¿no se expandiría y encogería el Pod con frecuencia? Es decir, el número de copias se ajusta constantemente. Habrá un ciclo de enfriamiento aquí. ¿Cuál es el tiempo de enfriamiento después de cada expansión y contracción?

En HPA, el ciclo de enfriamiento de expansión predeterminado es de 3 minutos y el ciclo de enfriamiento de contracción es de 5 minutos.

El tiempo de enfriamiento se puede configurar ajustando los parámetros de inicio del componente kube-controller-manager:

--horizontal-pod-autoscaler-downscale-delay expansión enfriamiento

--horizontal-pod-autoscaler-upscale-delay shrink cooling

Ejemplo:

Tomemos un ejemplo y luego presionemos el módulo para que se expanda automáticamente.

cat auto_scale.yaml

---
apiVersion: aplicaciones / v1
tipo: Despliegue
metadatos:
  nombre: auto-nginx
  espacio de nombres: ops
Especificaciones:
  selector:
    matchLabels:
      aplicación: auto-nginx
  réplicas: 1
  modelo:
    metadatos:
      etiquetas:
        aplicación: auto-nginx
    Especificaciones:
      imagePullSecrets:
      - nombre: cd-registro
      contenedores:
      - imagen: harbour.ttsingops.com/nginx/nginx:1.16.0
        nombre: auto-nginx
        recursos:
          peticiones:
            CPU: 200 m
        puertos:
        - containerPort: 80
---
#Servicio
apiVersion: v1
tipo: Servicio
metadatos:
  nombre: auto-nginx
  espacio de nombres: ops
Especificaciones:
  tipo: NodePort
  puertos:
  - puerto: 8088
    protocolo: TCP
    targetPort: 80
    nodePort: 38088
  selector:
    app: auto-nginx

kubectl apply -f auto_scale.yaml

kubectl get svc,pod -n ops -o wide

cat auto_nginx_hpa.yaml

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: auto-nginx-hpa
  namespace: ops
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: auto-nginx
  minReplicas: 1
  maxReplicas: 8
  targetCPUUtilizationPercentage: 50