Ao crear un clúster de Kubernetes, poden xurdir preguntas: cantos nodos de traballo configurar e que tipo? Que é mellor para un clúster local: compre varios servidores potentes ou use unha ducia de máquinas antigas no seu centro de datos? É mellor levar oito instancias dun só núcleo ou dúas de catro núcleos na nube?
As respostas a estas preguntas están no artigo. na tradución do comando .
Capacidade do clúster
En xeral, un clúster de Kubernetes pódese considerar un gran "supernodo". A súa potencia de cálculo total é a suma das potencias de todos os seus nodos constituíntes.
Hai varias formas de acadar o obxectivo de capacidade do clúster desexado. Por exemplo, necesitamos un clúster cunha capacidade total de 8 núcleos de procesador e 32 GB de RAM porque un conxunto de aplicacións require moitos recursos. Despois podes instalar dous nodos con 16 GB de memoria ou catro nodos con 8 GB de memoria, dous procesadores de catro núcleos ou catro de dobre núcleo.
Aquí tes só dúas formas posibles de crear un clúster:
Ambas opcións producen un clúster coa mesma capacidade, pero a configuración inferior ten catro nodos máis pequenos e a configuración superior dous nodos máis grandes.
Que opción é mellor?
Para responder a esta pregunta, vexamos as vantaxes de ambas opcións. Reunímolos nunha táboa.
Varios nodos grandes
Moitos pequenos nodos
Xestión de clústeres máis sinxela (se é local)
Autoescalado suave
Máis barato (se é local)
O prezo é pouco diferente (na nube)
Pode executar aplicacións con uso intensivo de recursos
Replicación completa
Os recursos úsanse de forma máis eficiente (menos sobrecarga nos daemons do sistema
Maior tolerancia a fallos do clúster
Teña en conta que só estamos a falar de nodos de traballo. Elixir o número e o tamaño dos nodos principais é un tema completamente diferente.
Entón, imos discutir cada punto da táboa con máis detalle.
Primeira opción: varios nodos grandes
A opción máis extrema é un nodo de traballo para toda a capacidade do clúster. No exemplo anterior, este sería un único nodo traballador con 16 núcleos de CPU e 16 GB de RAM.
Pros
Máis no 1. Xestión máis sinxela
É máis fácil xestionar unhas poucas máquinas que unha flota enteira. É máis rápido lanzar actualizacións e correccións e sincronizalas. O número de fallos en números absolutos tamén é menor.
Ten en conta que todo o anterior aplícase ao teu hardware, aos teus servidores e non ás instancias na nube.
A situación é diferente na nube. Alí, a xestión corre a cargo do provedor de servizos na nube. Así, xestionar dez nodos na nube non é moi diferente de xestionar un nodo.
Enrutamento de tráfico e distribución de carga entre pods na nube : o tráfico procedente de Internet envíase ao equilibrador de carga principal, que reenvía o tráfico ao porto dun dos nodos (o servizo NodePort establece o porto no intervalo 30000-32767 en cada nodo do clúster). As regras establecidas por kube-proxy redirixen o tráfico do nodo ao pod. Aquí tes o aspecto de dez pods en dous nodos:
Pro #2: Menos custo por nodo
Un coche potente é máis caro, pero o aumento do prezo non é necesariamente lineal. Noutras palabras, un servidor de dez núcleos con 10 GB de memoria adoita ser máis barato que dez servidores dun só núcleo coa mesma cantidade de memoria.
Pero teña en conta que esta regra non adoita funcionar nos servizos na nube. Nos esquemas de prezos actuais de todos os principais provedores de nube, os prezos aumentan linealmente coa capacidade.
Así, na nube normalmente non podes gardar en servidores máis potentes.
Pro # 3: pode executar aplicacións con uso intensivo de recursos
Algunhas aplicacións requiren servidores potentes nun clúster. Por exemplo, se un sistema de aprendizaxe automática require 8 GB de memoria, non poderás executalo en nodos de 1 GB, pero só con polo menos un nodo de traballo grande.
Contra
Desvantaxe número 1. Moitas vainas por nodo
Se a mesma tarefa se realiza en menos nodos, entón cada un deles terá naturalmente máis pods.
Isto pode ser un problema.
O motivo é que cada módulo introduce algunha sobrecarga no tempo de execución do contedor (por exemplo, Docker), así como o kubelet e cAdvisor.
Por exemplo, un kubelet examina regularmente todos os contedores dun nodo para a súa supervivencia; cantos máis contenedores, máis traballo ten que facer o kubelet.
CAdvisor recolle estatísticas de uso de recursos para todos os contedores dun nodo e kubelet consulta regularmente esta información e fornecea a través dunha API. De novo, máis contedores significa máis traballo tanto para cAdvisor como para kubelet.
Se o número de módulos aumenta, pode ralentizar o sistema e mesmo minar a súa fiabilidade.
No repositorio de Kubernetes algúns que os nodos saltan entre os estados Ready/NotReady porque as comprobacións regulares de kubelet de todos os contedores dun nodo tardan demasiado.
Por este motivo Kubernetes . Dependendo do rendemento do nodo, pode executar máis pods por nodo, pero é difícil prever se haberá problemas ou se todo funcionará ben. Paga a pena probar o traballo con antelación.
Desvantaxe no 2. Limitación de replicación
Moi poucos nós limitan a extensión efectiva da replicación da aplicación. Por exemplo, se ten unha aplicación de alta dispoñibilidade con cinco réplicas pero só dous nodos, entón o grao de replicación efectivo da aplicación redúcese a dous.
Cinco réplicas só se poden distribuír en dous nodos e, se un deles falla, eliminará varias réplicas á vez.
Se tes cinco nodos ou máis, cada réplica executarase nun nodo separado e a falla dun nodo eliminará como máximo unha réplica.
Así, os requisitos de alta dispoñibilidade poden requirir un certo número mínimo de nós no clúster.
Desvantaxe no 3. Peores consecuencias do fracaso
Cun pequeno número de nodos, cada fallo ten consecuencias máis graves. Por exemplo, se só tes dous nodos e un deles falla, a metade dos teus módulos desaparece inmediatamente.
Por suposto, Kubernetes migrará a carga de traballo do nodo fallido a outros. Pero se hai poucos, pode que non haxa suficiente capacidade libre. Como resultado, algunhas das túas aplicacións non estarán dispoñibles ata que apareza o nodo fallido.
Así, cantos máis nodos, menor será o impacto dos fallos de hardware.
Desvantaxe número 4: máis pasos de escalado automático
Kubernetes dispón dun sistema de escalado automático de clúster para a infraestrutura na nube, que che permite engadir ou eliminar nós automaticamente segundo as túas necesidades actuais. Con nodos máis grandes, o escalado automático faise máis brusco e torpe. Por exemplo, en dous nodos, engadir un nodo adicional aumentará inmediatamente a capacidade do clúster nun 50%. E terás que pagar por eses recursos, aínda que non os necesites.
Así, se pensas usar a escala automática do clúster, canto máis pequenos sexan os nodos, máis flexible e rendible terás.
Agora vexamos as vantaxes e inconvenientes dun gran número de pequenos nós.
Segunda opción: moitos nodos pequenos
As vantaxes deste enfoque derivan esencialmente das desvantaxes da opción oposta con varios nodos grandes.
Pros
Pro #1: Menos impacto do fracaso
Cantos máis nodos, menos pods en cada nodo. Por exemplo, se tes cen módulos por cada dez nodos, cada nodo terá unha media de dez módulos.
Deste xeito, se un dos nodos falla, só se perde o 10% da carga de traballo. É probable que só un pequeno número de réplicas se vexa afectado e que a aplicación en xeral siga operativa.
Ademais, os nodos restantes probablemente terán recursos gratuítos suficientes para xestionar a carga de traballo do nodo fallido, polo que Kubernetes pode reprogramar libremente os pods e as súas aplicacións volverán a un estado funcional relativamente rápido.
Pro # 2: boa replicación
Se hai suficientes nodos, o planificador de Kubernetes pode asignar nodos diferentes a todas as réplicas. Deste xeito, se un nodo falla, só se verá afectada unha réplica e a aplicación permanecerá dispoñible.
Contra
Desvantaxe no 1. Difícil de controlar
Un gran número de nodos é máis difícil de xestionar. Por exemplo, cada nodo de Kubernetes debe comunicarse con todos os demais, é dicir, o número de conexións crece cuadráticamente e hai que rastrexar todas estas conexións.
O controlador de nodos de Kubernetes Controller Manager percorre regularmente todos os nodos do clúster para comprobar o estado: cantos máis nodos, máis carga terá o controlador.
A carga na base de datos etcd tamén está crecendo: cada chamada kubelet e kube-proxy para etcd (a través da API), ao que etcd debería transmitir actualizacións de obxectos.
En xeral, cada nodo traballador impón unha carga adicional aos compoñentes do sistema dos nodos mestres.
Kubernetes admite oficialmente clústeres con . Non obstante, na práctica xa hai 500 nodos .
Para xestionar un gran número de nodos de traballo, debes escoller nodos mestres máis potentes. Por exemplo, kube-up o tamaño correcto da VM para o nodo mestre dependendo do número de nodos traballadores. É dicir, cantos máis nodos traballadores, máis produtivos deberían ser os nodos mestres.
Para resolver estes problemas específicos existen desenvolvementos especiais, como . Este sistema permítelle evitar restricións e construír clústeres cun gran número de nodos de traballo.
Desvantaxe número 2: máis custos xerais.
En cada nodo de traballo, Kubernetes executa un conxunto de daemons do sistema; estes inclúen o tempo de execución do contenedor (como Docker), kube-proxy e kubelet, incluído cAdvisor. Xuntos consomen unha determinada cantidade de recursos.
Se tes moitos nodos pequenos, a proporción desta sobrecarga en cada nodo é maior. Por exemplo, imaxine que todos os daemons do sistema nun único nodo utilizan xuntos 0,1 núcleos de CPU e 0,1 GB de memoria. Se tes un nodo de dez núcleos con 10 GB de memoria, os daemons consumen o 1 % da capacidade do clúster. Por outra banda, en dez nodos dun só núcleo con 1 GB de memoria, os daemons ocuparán o 10% da capacidade do clúster.
Así, cantos menos nodos, máis eficiente se utilizará a infraestrutura.
Desvantaxe no 3. Uso ineficiente dos recursos
En nós pequenos, pode ser que os anacos de recursos restantes sexan demasiado pequenos para asignarlles carga de traballo, polo que permanecen sen usar.
Por exemplo, cada pod require 0,75 GB de memoria. Se tes dez nodos, cada un con 1 GB de memoria, podes executar dez pods, deixando cada nodo con 0,25 GB de memoria sen usar.
Isto significa que se desperdicia o 25% da memoria de todo o clúster.
Nun nodo grande con 10 GB de memoria, pode executar 13 destes módulos, e só haberá un fragmento de 0,25 GB sen usar.
Neste caso, só se desperdicia o 2,5% da memoria.
Así, os recursos úsanse de forma máis óptima en nós máis grandes.
Varios nodos grandes ou moitos pequenos?
Entón, que é mellor: algúns nodos grandes nun clúster ou moitos pequenos? Como sempre, non hai unha resposta clara. Depende moito do tipo de aplicación.
Por exemplo, se unha aplicación require 10 GB de memoria, os nodos máis grandes son unha opción obvia. E se a aplicación require unha replicación por dez para a alta dispoñibilidade, non paga a pena correr o risco de colocar réplicas en só dous nodos: debe haber un mínimo de dez nodos no clúster.
En situacións intermedias, faga unha elección en función das vantaxes e desvantaxes de cada opción. Quizais algúns argumentos sexan máis relevantes para a túa situación que outros.
E non é para nada necesario que todos os nodos teñan o mesmo tamaño. Nada lle impide experimentar primeiro con nós do mesmo tamaño, despois engadirlles nodos dun tamaño diferente, combinándoos nun clúster. Os nodos de traballo nun clúster de Kubernetes poden ser completamente heteroxéneos. Entón podes tentar combinar as vantaxes de ambos enfoques.
Non hai unha receita única, e cada situación ten os seus propios matices, e só a produción mostrará a verdade.
Tradución elaborada polo equipo da plataforma na nube .
Máis información sobre Kubernetes: .
Fonte: www.habr.com