Para cada recurso de Kubernetes, podes configurar dous tipos de requisitos: solicitudes e límites. O primeiro describe os requisitos mínimos para a dispoñibilidade de recursos de nodos libres necesarios para executar un contedor ou pod, o segundo limita estrictamente os recursos dispoñibles para o contedor.
Cando Kubernetes programa pods, é moi importante que os contedores teñan recursos suficientes para funcionar correctamente. Se está a planear implementar unha aplicación grande nun nodo con recursos limitados, é posible que non se execute porque o nodo está quedando esgotando a memoria ou quedando sen enerxía da CPU. Neste artigo, imos ver como pode resolver a escaseza de enerxía de cómputo mediante solicitudes de recursos e límites.
As solicitudes e os límites son mecanismos que Kubernetes utiliza para xestionar recursos como a CPU e a memoria. As solicitudes son as que garanten que o contedor reciba o recurso solicitado. Se un contedor solicita un recurso, Kubernetes só o programará nun nodo que o poida proporcionar. Os límites controlan que os recursos solicitados polo contedor nunca superarán un determinado valor.
Un contedor só pode aumentar a súa potencia de cálculo ata un determinado límite, despois do cal estará limitado. A ver como funciona. Entón, hai dous tipos de recursos: procesador e memoria. O programador de Kubernetes usa datos sobre estes recursos para descubrir onde executar os teus pods. Unha especificación de recurso típica para un pod é así.
Cada recipiente dunha vaina pode establecer as súas propias consultas e límites, todo é aditivo. Os recursos do procesador defínense en milinúcleos. Se o teu recipiente necesita dous núcleos completos para funcionar, estableces o valor en 2000 m. Se o recipiente só necesita a potencia de 1/4 do núcleo, o valor será de 250 m. Teña en conta que se asigna un valor de recurso de CPU maior que o número de núcleos do nodo máis grande, o seu pod non estará programado para iniciarse. Unha situación similar ocorrerá se tes un Pod que necesita catro núcleos e o clúster de Kubernetes só consta de dúas máquinas virtuais principais.
A menos que a túa aplicación estea deseñada especificamente para aproveitar varios núcleos (véñense á mente programas como a informática científica complexa e as operacións de bases de datos), a mellor práctica é establecer as solicitudes de CPU en 1 ou inferior e, a continuación, executar máis réplicas para a escalabilidade. Esta solución dará ao sistema unha maior flexibilidade e fiabilidade.
Cando se trata de limitacións da CPU, as cousas vólvense máis interesantes xa que se considera un recurso comprimible. Se a túa aplicación comeza a achegarse ao límite de potencia do procesador, Kubernetes comezará a ralentizar o teu contedor mediante a limitación da CPU, reducindo a frecuencia do procesador. Isto significa que a CPU acelerarase artificialmente, o que lle dará á aplicación un rendemento potencialmente peor, pero o proceso non se finalizará nin se eliminará.
Os recursos de memoria defínense en bytes. Normalmente, o valor da configuración mídese en mebibytes Mib, pero pode definir calquera valor, desde bytes ata petabytes. A mesma situación aplícase aquí que coa CPU: se solicita unha cantidade de memoria maior que a cantidade de memoria dos seus nodos, ese pod non se programará para executarse. Pero a diferenza dos recursos da CPU, a memoria non está comprimida porque non hai forma de limitar o seu uso. Polo tanto, pararase a execución do contedor en canto supere a memoria asignada ao mesmo.
É importante lembrar que non pode configurar solicitudes que excedan os recursos que poden proporcionar os seus nodos. As especificacións de recursos compartidos para máquinas virtuais de GKE pódense atopar nas ligazóns que aparecen a continuación deste vídeo.
Nun mundo ideal, a configuración predeterminada do contedor sería suficiente para que os fluxos de traballo funcionen sen problemas. Pero o mundo real non é así, a xente pode esquecerse facilmente de configurar o uso dos recursos, ou os hackers establecerán solicitudes e restricións que superen as capacidades reais da infraestrutura. Para evitar que se produzan tales escenarios, pode configurar as cotas de recursos ResourceQuota e LimitRange.
Unha vez creado un espazo de nomes, pódese bloquear mediante cotas. Por exemplo, se tes os espazos de nomes prod e dev, o patrón é que non hai cotas de produción e cotas de desenvolvemento moi estritas. Isto permite que prod, en caso de aumento brusco do tráfico, se faga cargo de todo o recurso dispoñible, bloqueando completamente o desenvolvemento.
A cota de recursos pode verse así. Neste exemplo hai 4 seccións: estas son as 4 liñas inferiores de código.
Vexamos cada un deles. Requests.cpu é o número máximo de solicitudes de CPU combinadas que poden proceder de todos os contedores do espazo de nomes. Neste exemplo, podes ter 50 contedores con solicitudes de 10 m, cinco contedores con solicitudes de 100 m ou só un contedor con solicitudes de 500 m. Sempre que o número total de requests.cpu dun espazo de nomes determinado sexa inferior a 500 m, todo estará ben.
Solicitudes de memoria solicitadas.memory é a cantidade máxima de solicitudes de memoria combinadas que poden ter todos os contedores do espazo de nomes. Como no caso anterior, podes ter 50 contedores de 2 mib, cinco contenedores de 20 mib ou un único contenedor de 100 mib sempre que a cantidade total de memoria solicitada no espazo de nomes sexa inferior a 100 mebibytes.
Limits.cpu é a cantidade máxima combinada de potencia da CPU que poden usar todos os contedores do espazo de nomes. Podemos considerar que este é o límite das solicitudes de potencia do procesador.
Finalmente, limits.memory é a cantidade máxima de memoria compartida que poden usar todos os contedores do espazo de nomes. Este é un límite de solicitudes de memoria total.
Así, por defecto, os contedores dun clúster de Kubernetes execútanse con recursos informáticos ilimitados. Coas cotas de recursos, os administradores do clúster poden limitar o consumo de recursos e a creación de recursos baseándose no espazo de nomes. Nun espazo de nomes, un pod ou contedor pode consumir tanta potencia da CPU e memoria como o determine a cota de recursos do espazo de nomes. Non obstante, existe a preocupación de que unha cápsula ou recipiente poida monopolizar todos os recursos dispoñibles. Para evitar esta situación, utilízase un intervalo límite: unha política para limitar a asignación de recursos (para pods ou contedores) no espazo de nomes.
O rango límite ofrece restricións que poden:
- Garantir o uso mínimo e máximo dos recursos informáticos para cada módulo ou contedor do espazo de nomes;
- aplicar as solicitudes de almacenamento mínimas e máximas de Starage Request para cada PersistentVolumeClaim no espazo de nomes;
- aplicar unha relación entre unha solicitude e un límite para un recurso nun espazo de nomes;
- Estableza Solicitudes/Límites predeterminados para os recursos informáticos no espazo de nomes e inxécteos automaticamente nos contedores no tempo de execución.
Deste xeito, pode crear un intervalo límite no seu espazo de nomes. A diferenza dunha cota, que se aplica a todo o espazo de nomes, o intervalo límite úsase para contedores individuais. Isto pode evitar que os usuarios creen contedores moi pequenos ou, pola contra, xigantescos dentro do espazo de nomes. O intervalo límite pode verse así.
Como no caso anterior, aquí pódense distinguir 4 apartados. Vexamos cada un.
A sección predeterminada establece os límites predeterminados para o contedor do pod. Se estableces estes valores no intervalo extremo, calquera recipiente para os que non se estableceron explícitamente estes valores seguirán os valores predeterminados.
A sección de solicitude predeterminada defaultRequest configura as solicitudes predeterminadas para o contedor do pod. De novo, se estableces estes valores no intervalo extremo, calquera contedor que non estableza de forma explícita estas opcións terá estes valores por defecto.
A sección max especifica os límites máximos que se poden establecer para un recipiente na vaina. Os valores da sección predeterminada e os límites do contedor non se poden establecer por riba deste límite. É importante ter en conta que se o valor está definido como máximo e non hai unha sección predeterminada, entón o valor máximo pasa a ser o valor predeterminado.
A sección mínima especifica as solicitudes mínimas que se poden establecer para un contedor nun pod. Non obstante, os valores da sección predeterminada e as consultas para o contedor non se poden establecer por debaixo deste límite.
Unha vez máis, é importante ter en conta que se se establece este valor, o valor predeterminado non o é, entón o valor mínimo convértese no indicador predeterminado.
Estas solicitudes de recursos son utilizadas finalmente polo programador de Kubernetes para executar as túas cargas de traballo. Para que configures correctamente os teus contedores, é moi importante entender como funciona. Digamos que queres executar varios pods no teu clúster. Asumindo que as especificacións dos pods son válidas, a programación de Kubernetes utilizará o equilibrio round robin para seleccionar un nodo para executar a carga de traballo.
Kubernetes comprobará se o nodo 1 ten recursos suficientes para satisfacer as solicitudes dos contedores de vainas e, se non, pasará ao seguinte nodo. Se ningún dos nodos do sistema é capaz de satisfacer as solicitudes, os pods pasarán ao estado Pendente. Usando funcións do motor de Google Kubernetes, como a escala automática de nodos, GKE pode detectar automaticamente o estado de espera e crear varios nodos adicionais.
Se posteriormente queda sen capacidade dos nodos, a escala automática reducirá o número de nodos para aforrarche cartos. É por iso que Kubernetes programa pods en función das solicitudes. Non obstante, o límite pode ser superior ás solicitudes e, nalgúns casos, o nodo pode quedar sen recursos. Chamámoslle a este estado estado de sobrecompromiso.
Como dixen, cando se trata de CPU, Kubernetes comezará a limitar os pods. Cada pod recibirá tanto como solicitou, pero se non chega ao límite, comezará a aplicarse o estrangulamento.
Cando se trata de recursos de memoria, Kubernetes vese obrigado a tomar decisións sobre que pods eliminar e cales conservar ata que libere os recursos do sistema ou todo o sistema fallará.
Imaxinemos un escenario no que tes unha máquina sen memoria: como xestionaría Kubernetes?
Kubernetes buscará pods que utilicen máis recursos dos que solicitaron. Polo tanto, se os teus contedores non teñen ningunha solicitude, isto significa que usan máis do que pediron, simplemente porque non pediron nada. Estes contedores convértense en candidatos principais para o peche. Os seguintes candidatos son contedores que cumpriron todas as súas solicitudes pero aínda están por debaixo do límite máximo.
Polo tanto, se Kubernetes atopa varios pods que superaron os seus parámetros de solicitude, ordenaraos por prioridade e despois eliminará os pods de menor prioridade. Se todos os pods teñen a mesma prioridade, Kubernetes cancelará aqueles pods que superen as súas solicitudes máis que outros pods.
En casos moi raros, Kubernetes pode abortar pods que aínda están dentro do alcance das súas solicitudes. Isto pode ocorrer cando os compoñentes críticos do sistema, como o axente Kubelet ou o Docker, comezan a consumir máis recursos dos que estaban reservados para eles.
Así, nas primeiras etapas das pequenas empresas, un clúster de Kubernetes pode funcionar ben sen establecer restricións e solicitudes de recursos, pero a medida que os teus equipos e proxectos comezan a crecer, corres o risco de ter problemas nesta área. Engadir consultas e restricións aos teus módulos e espazos de nomes require moi pouco esforzo adicional e pode aforrar moitos problemas.
Algúns anuncios 🙂
Grazas por estar connosco. Gústanche os nosos artigos? Queres ver máis contido interesante? Apóyanos facendo un pedido ou recomendando a amigos, , un análogo único de servidores de nivel de entrada, que inventamos nós para ti: (dispoñible con RAID1 e RAID10, ata 24 núcleos e ata 40 GB DDR4).
Dell R730xd 2 veces máis barato no centro de datos Equinix Tier IV en Amsterdam? Só aquí nos Países Baixos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - desde $ 99! Ler sobre
Fonte: www.habr.com