Para dominar completamente Kubernetes, necesitas coñecer diferentes formas de escalar os recursos do clúster: por , esta é unha das principais tarefas de Kubernetes. Ofrecemos unha visión xeral de alto nivel dos mecanismos de escalado automático horizontal e vertical e de cambio de tamaño do clúster, así como recomendacións sobre como usalos de forma eficaz.
Artigo traducido polo equipo que implementou a escala automática .
Por que é importante pensar na escala
- unha ferramenta para a xestión e orquestración de recursos. Por suposto, é bo xogar coas funcións interesantes de despregar, supervisar e xestionar pods (un pod é un grupo de contedores que se lanzan en resposta a unha solicitude).
Non obstante, tamén debes pensar nas seguintes preguntas:
- Como escalar módulos e aplicacións?
- Como manter os contedores operativos e eficientes?
- Como responder aos cambios constantes no código e nas cargas de traballo dos usuarios?
Configurar clústeres de Kubernetes para equilibrar os recursos e o rendemento pode ser un reto e require coñecementos expertos sobre o funcionamento interno de Kubernetes. A carga de traballo da túa aplicación ou servizos pode variar ao longo do día ou mesmo ao longo dunha hora, polo que o equilibrio é mellor pensar como un proceso continuo.
Niveis de escalado automático de Kubernetes
O autoescalado eficaz require a coordinación entre dous niveis:
- Nivel de pod, incluído horizontal (Horizontal Pod Autoscaler, HPA) e vertical (Vertical Pod Autoscaler, VPA). Isto está a escalar os recursos dispoñibles para os teus contedores.
- Nivel de clúster, que é xestionado polo Cluster Autoscaler (CA), que aumenta ou diminúe o número de nós dentro do clúster.
Módulo Horizontal Autoscaler (HPA).
Como o nome indica, HPA escala o número de réplicas de pod. A maioría dos devops usan a CPU e a carga de memoria como disparadores para cambiar o número de réplicas. Non obstante, é posible escalar o sistema en función de , eles ou mesmo .
Diagrama de funcionamento HPA de alto nivel:
- O HPA comproba continuamente os valores métricos especificados durante a instalación nun intervalo predeterminado de 30 segundos.
- O HPA tenta aumentar o número de módulos se se alcanza o limiar especificado.
- O HPA actualiza o número de réplicas dentro do controlador de implantación/réplica.
- O controlador de implantación/replicación desprega entón os módulos adicionais necesarios.
HPA inicia o proceso de implantación do módulo cando se alcanza un limiar métrico
Cando use HPA, teña en conta o seguinte:
- O intervalo de comprobación HPA predeterminado é de 30 segundos. Establécese pola bandeira período de sincronización de autoscaler-pod horizontal no xestor do controlador.
- O erro relativo predeterminado é do 10%.
- Despois do último aumento no número de módulos, HPA espera que as métricas se estabilicen en tres minutos. Este intervalo está establecido pola bandeira horizontal-pod-autoscaler-upscale-delay.
- Despois da última redución do número de módulos, o HPA agarda cinco minutos para estabilizarse. Este intervalo está establecido pola bandeira horizontal-pod-autoscaler-downscale-delay.
- HPA funciona mellor con obxectos de implementación en lugar de controladores de replicación. O escalado automático horizontal é incompatible coa actualización continua, que manipula directamente os controladores de replicación. Coa implementación, o número de réplicas depende directamente dos obxectos de implementación.
Autoescalado vertical de pods
A escala automática vertical (VPA) asigna máis (ou menos) tempo de CPU ou memoria aos pods existentes. Adecuado para pods con estado ou sen estado, pero destinado principalmente a servizos con estado. Non obstante, tamén pode usar VPA para módulos sen estado se precisa axustar automaticamente a cantidade de recursos inicialmente asignados.
O VPA tamén responde aos eventos OOM (sen memoria). Cambiar o tempo e a memoria da CPU require reiniciar os pods. Cando se reinicia, o VPA respecta o orzamento de asignación () para garantir o número mínimo de módulos esixido.
Podes establecer os recursos mínimos e máximos para cada módulo. Así, pode limitar a cantidade máxima de memoria asignada a 8 GB. Isto é útil se os nodos actuais definitivamente non poden asignar máis de 8 GB de memoria por contedor. As especificacións detalladas e o mecanismo de funcionamento descríbense en .
Ademais, VPA ten unha interesante función de recomendación (VPA Recommender). Supervisa o uso de recursos e os eventos OOM de todos os módulos para suxerir novos valores de memoria e tempo de CPU baseados nun algoritmo intelixente baseado en métricas históricas. Tamén hai unha API que toma un controlador de pod e devolve os valores de recursos suxeridos.
Paga a pena notar que o recomendador VPA non rastrexa o "límite" de recursos. Isto pode provocar que o módulo monopolice os recursos dentro dos nodos. É mellor establecer o límite a nivel de espazo de nomes para evitar un gran consumo de memoria ou CPU.
Esquema de operación VPA de alto nivel:
- VPA comproba continuamente os valores métricos especificados durante a instalación nun intervalo predeterminado de 10 segundos.
- Se se alcanza o limiar especificado, o VPA tenta cambiar a cantidade de recursos asignada.
- O VPA actualiza o número de recursos dentro do controlador de implantación/réplica.
- Cando se reinician os módulos, todos os novos recursos aplícanse ás instancias creadas.
VPA engade a cantidade necesaria de recursos
Teña en conta os seguintes puntos cando use VPA:
- O escalado require un reinicio obrigatorio do pod. Isto é necesario para evitar un funcionamento inestable despois de facer cambios. Por motivos de fiabilidade, os módulos reinician e distribúense entre nós en función dos recursos recén asignados.
- VPA e HPA aínda non son compatibles entre si e non poden funcionar nos mesmos pods. Se está a usar os dous mecanismos de escala no mesmo clúster, asegúrese de que a súa configuración impida que se activen nos mesmos obxectos.
- VPA axusta as solicitudes de contedores de recursos baseándose só no uso pasado e actual. Non establece límites de uso de recursos. Pode haber problemas coas aplicacións que non funcionan correctamente e comezan a facerse cargo de cada vez máis recursos, o que provocará que Kubernetes desactive este pod.
- O VPA aínda está nunha fase inicial de desenvolvemento. Estea preparado para que o sistema poida sufrir algúns cambios nun futuro próximo. Podes ler sobre и . Así, hai plans para implementar o funcionamento conxunto de VPA e HPA, así como o despregamento de módulos xunto cunha política de autoescalado vertical para eles (por exemplo, unha etiqueta especial "require VPA").
Escalado automático dun clúster de Kubernetes
O Cluster Autoscaler (CA) cambia o número de nodos en función do número de pods en espera. O sistema comproba periodicamente os módulos pendentes e aumenta o tamaño do clúster se son necesarios máis recursos e se o clúster non supera os límites establecidos. A CA comunícase co provedor de servizos na nube, pídelle nodos adicionais ou libera os inactivos. A primeira versión xeralmente dispoñible de CA presentouse en Kubernetes 1.8.
Esquema de alto nivel de operación SA:
- CA verifica os módulos pendentes nun intervalo predeterminado de 10 segundos.
- Se un ou máis pods están en estado de espera porque o clúster non ten suficientes recursos dispoñibles para asignalos, tentará aprovisionar un ou máis nodos adicionais.
- Cando o fornecedor de servizos na nube asigna o nodo necesario, únese ao clúster e está listo para servir os pods.
- O planificador de Kubernetes distribúe pods pendentes ao novo nodo. Se despois disto algúns módulos aínda permanecen en estado de espera, o proceso repítese e engádense novos nodos ao clúster.
Aprovisionamento automático de nodos de clúster na nube
Considere o seguinte cando use CA:
- CA garante que todos os pods do clúster teñan espazo para executarse, independentemente da carga da CPU. Tamén tenta garantir que non haxa nodos innecesarios no clúster.
- CA rexistra a necesidade de escalar despois de aproximadamente 30 segundos.
- Unha vez que xa non se necesita un nodo, a CA espera por defecto 10 minutos antes de escalar o sistema.
- O sistema de autoescalado ten o concepto de expansores. Trátase de diferentes estratexias para seleccionar un grupo de nodos aos que se engadirán novos nodos.
- Use a opción de forma responsable cluster-autoscaler.kubernetes.io/safe-to-evict (true). Se instalas moitos pods, ou se moitos deles están espallados por todos os nodos, perderás en gran medida a capacidade de escalar o clúster.
- Usar para evitar que se eliminen os pods, o que pode provocar un fallo completo en partes da súa aplicación.
Como interactúan os escaladores automáticos de Kubernetes entre si
Para unha harmonía perfecta, a escala automática debe aplicarse tanto a nivel de pod (HPA/VPA) como a nivel de clúster. Interactúan entre si de forma relativamente sinxela:
- Os HPA ou VPA actualizan as réplicas de pod ou os recursos asignados a pods existentes.
- Se non hai suficientes nodos para o escalado planificado, a CA nota a presenza de pods en estado de espera.
- A CA asigna novos nodos.
- Os módulos distribúense a novos nodos.
Sistema colaborativo de escalado horizontal de Kubernetes
Erros comúns no escalado automático de Kubernetes
Hai varios problemas comúns cos que se atopan os devops ao tentar implementar a escala automática.
HPA e VPA dependen das métricas e dalgúns datos históricos. Se non se asignan recursos suficientes, os módulos minimizaranse e non poderán xerar métricas. Neste caso, a escala automática nunca ocorrerá.
A operación de escala en si é sensible ao tempo. Queremos que os módulos e clústeres escalan rapidamente, antes de que os usuarios noten algún problema ou fallo. Polo tanto, débese ter en conta o tempo medio de escalado das vainas e do clúster.
Escenario ideal - 4 minutos:
- 30 segundos. Actualizar as métricas de destino: 30-60 segundos.
- 30 segundos. HPA verifica valores métricos: 30 segundos.
- Menos de 2 segundos. Os pods créanse e pasan ao estado de espera: 1 segundo.
- Menos de 2 segundos. CA ve módulos en espera e envía chamadas aos nodos de provisión: 1 segundo.
- 3 minutos. O provedor de nube asigna nós. Os K8 esperan ata que estean listos: ata 10 minutos (dependendo de varios factores).
O peor dos casos (máis realista) - 12 minutos:
- 30 segundos. Actualizar as métricas de destino.
- 30 segundos. HPA verifica os valores métricos.
- Menos de 2 segundos. Os pods créanse e entran no estado de espera.
- Menos de 2 segundos. A CA ve os módulos en espera e fai chamadas para aprovisionar os nodos.
- 10 minutos. O provedor de nube asigna nós. Os K8 esperan ata que estean listos. O tempo de espera depende de varios factores, como o atraso do provedor, o atraso do SO e as ferramentas de soporte.
Non confunda os mecanismos de escala dos provedores de nube coa nosa CA. Este último execútase dentro dun clúster de Kubernetes, mentres que o motor do provedor de nube funciona sobre unha base de distribución de nodos. Non sabe o que está a pasar cos teus pods ou aplicacións. Estes sistemas funcionan en paralelo.
Como xestionar o escalado en Kubernetes
- Kubernetes é unha ferramenta de xestión e orquestración de recursos. As operacións para xestionar pods e recursos do clúster son un fito fundamental no dominio de Kubernetes.
- Comprender a lóxica da escalabilidade dos pods tendo en conta HPA e VPA.
- CA só debe usarse se entende ben as necesidades das súas vainas e recipientes.
- Para configurar de forma óptima un clúster, cómpre comprender como funcionan xuntos os diferentes sistemas de escalado.
- Ao estimar o tempo de escalado, ten en conta o peor e o mellor dos casos.
Fonte: www.habr.com