Nota. transl.: este material é dun proxecto educativo é a resposta a unha pregunta popular ao deseñar unha infraestrutura baseada en Kubernetes. Agardamos que unhas descricións bastante detalladas dos pros e contras de cada opción che axuden a escoller a mellor opción para o teu proxecto.
TL, RD: o mesmo conxunto de cargas de traballo pódese executar en varios clusters grandes (cada cluster terá un gran número de cargas de traballo) ou en moitos pequenos (cun pequeno número de cargas en cada cluster).
A continuación móstrase unha táboa que avalía os pros e os contras de cada enfoque:
Cando se usa Kubernetes como plataforma para executar aplicacións, moitas veces xorden varias preguntas fundamentais sobre as complejidades da configuración de clústeres:
- Cantos clusters debo usar?
- Que grandes debo facelos?
- Que debe incluír cada cluster?
Neste artigo, tentarei responder a todas estas preguntas analizando os pros e os contras de cada enfoque.
Enunciado dunha pregunta
Como desenvolvedor de software, é probable que desenvolvas e operes moitas aplicacións ao mesmo tempo.
Ademais, é probable que moitas instancias destas aplicacións se executen en diferentes ambientes; por exemplo, poden ser estes dev, proba и produción.
O resultado é toda unha matriz de aplicacións e contornos:
Aplicacións e contornos
O exemplo anterior representa 3 aplicacións e 3 ambientes, o que resulta nun total de 9 opcións posibles.
Cada instancia de aplicación é unha unidade de implantación autónoma coa que se pode traballar independentemente doutras.
Nótese que instancia de aplicación pode constar de moitos compoñentes, como frontend, backend, base de datos, etc. No caso dunha aplicación de microservizos, a instancia incluirá todos os microservizos.
Como resultado, os usuarios de Kubernetes teñen varias preguntas:
- Deben colocarse todas as instancias de aplicación nun clúster?
- Paga a pena ter un clúster separado para cada instancia de aplicación?
- Ou quizais debería usar unha combinación dos enfoques anteriores?
Todas estas opcións son bastante viables, xa que Kubernetes é un sistema flexible que non limita as capacidades do usuario.
Aquí tes algunhas das formas posibles:
- un gran grupo común;
- moitos pequenos clusters altamente especializados;
- un clúster por aplicación;
- un clúster por ambiente.
Como se mostra a continuación, os dous primeiros enfoques están en extremos opostos da escala de opcións:
Desde algúns grupos grandes (esquerda) ata moitos pequenos (dereita)
En xeral, un clúster considérase "máis grande" que outro se ten unha maior suma de nodos e vainas. Por exemplo, un clúster con 10 nodos e 100 pods é máis grande que un cluster con 1 nodo e 10 pods.
Ben, imos comezar!
1. Un gran grupo común
A primeira opción é colocar todas as cargas de traballo nun clúster:
Un gran grupo
Dentro deste enfoque, o clúster utilízase como un universal plataforma de infraestruturas — simplemente implementas todo o que necesitas nun clúster de Kubernetes existente.
Kubernetes permite que partes do clúster se separen loxicamente entre si, para que cada instancia de aplicación poida ter o seu propio espazo de nomes.
Vexamos os pros e os contras deste enfoque.
+ Uso eficiente dos recursos
Cun único clúster, só precisa unha copia de todos os recursos necesarios para executar e xestionar o clúster de Kubernetes.
Por exemplo, isto é certo para os nodos mestres. Normalmente, cada clúster de Kubernetes ten 3 nodos mestres, polo que para un único clúster o seu número seguirá sendo así (para comparación, 10 clústeres necesitarán 30 nodos mestres).
A sutileza anterior tamén se aplica a outros servizos que operan en todo o clúster, como equilibradores de carga, controladores de entrada, sistemas de autenticación, rexistro e seguimento.
Nun único clúster, todos estes servizos pódense utilizar á vez para todas as cargas de traballo (non é necesario crear copias deles, como é o caso de varios clústeres).
+ Barato
Como consecuencia do anterior, menos clusters adoitan ser máis baratos porque non hai custos xerais.
Isto é especialmente certo para os nodos mestres, que poden custar unha cantidade significativa de diñeiro independentemente de como estean aloxados (local ou na nube).
Algúns servizos de Kubernetes xestionados, como ou , proporciona a capa de control de forma gratuíta. Neste caso, o problema do custo é menos grave.
Tamén hai servizos xestionados que cobran unha tarifa fixa polo funcionamento de cada clúster de Kubernetes (por exemplo, ).
+ Administración eficiente
Xestionar un clúster é máis fácil que xestionar varios.
A administración pode incluír as seguintes tarefas:
- actualización da versión de Kubernetes;
- establecer unha canalización CI/CD;
- instalar o complemento CNI;
- configurar un sistema de autenticación de usuarios;
- instalación dun controlador de acceso;
e moitos outros...
No caso dun clúster, terás que facer todo isto só unha vez.
Para moitos clústeres, as operacións terán que repetirse moitas veces, o que probablemente requirirá certa automatización dos procesos e ferramentas para garantir a coherencia e coherencia no proceso.
E agora algunhas palabras sobre os contras.
− Punto único de fallo
En caso de denegación o único o clúster deixará de funcionar inmediatamente todo cargas de traballo!
Hai moitas formas en que as cousas poden saír mal:
- actualizar Kubernetes leva a efectos secundarios inesperados;
- Un compoñente de todo o clúster (por exemplo, un complemento CNI) comeza a non funcionar como se esperaba;
- un dos compoñentes do clúster non está configurado correctamente;
- fallo na infraestrutura subxacente.
Un destes incidentes pode causar danos graves a todas as cargas de traballo aloxadas nun clúster compartido.
− Sen illamento ríxido
A execución nun clúster compartido significa que as aplicacións comparten o hardware, as capacidades de rede e o sistema operativo nos nodos do clúster.
En certo sentido, dous contedores con dúas aplicacións diferentes que se executan no mesmo nodo son como dous procesos que se executan na mesma máquina que executa o mesmo núcleo do sistema operativo.
Os contedores de Linux proporcionan algún tipo de illamento, pero non é tan forte como o que proporcionan, por exemplo, as máquinas virtuais. En esencia, un proceso nun contedor é o mesmo proceso que se executa no sistema operativo host.
Isto pode ser un problema de seguridade: este arranxo teoricamente permite que aplicacións non relacionadas se comuniquen entre elas (de xeito intencionado ou accidental).
Ademais, todas as cargas de traballo nun clúster de Kubernetes comparten algúns servizos de todo o clúster, como - isto permite que as aplicacións atopen Servizos doutras aplicacións no clúster.
Todos os puntos anteriores poden ter significados diferentes dependendo dos requisitos de seguridade da aplicación.
Kubernetes ofrece varias ferramentas para evitar problemas de seguridade, como и . Non obstante, configuralos correctamente require certa experiencia; ademais, non son capaces de pechar absolutamente todos os buracos de seguridade.
É importante lembrar sempre que Kubernetes foi deseñado orixinalmente para compartindo, non para illamento e seguridade.
− Falta de multitensión estrita
Dada a abundancia de recursos compartidos nun clúster de Kubernetes, hai moitas formas en que diferentes aplicacións poden pisarse entre si.
Por exemplo, unha aplicación pode monopolizar un recurso compartido (como a CPU ou a memoria) e denegar a outras aplicacións que se executan no mesmo nodo o acceso a el.
Kubernetes ofrece varios mecanismos para controlar este comportamento, como (ver tamén o artigo ""- aprox. trad.), и . Non obstante, como no caso da seguridade, a súa configuración non é nada trivial e non son capaces de evitar absolutamente todos os efectos secundarios imprevistos.
− Gran número de usuarios
No caso dun único clúster, ten que abrir o acceso a el a moitas persoas. E canto maior sexa o seu número, maior é o risco de que "rompan" algo.
Dentro do clúster pode controlar quen pode facer que uso (ver artigo ""- aprox. trad.). Non obstante, non impedirá aos usuarios "romper" algo dentro da súa área de responsabilidade.
− Os clústeres non poden crecer indefinidamente
O clúster que se utiliza para todas as cargas de traballo probablemente será bastante grande (en termos de número de nodos e pods).
Pero aquí xorde outro problema: os clústeres en Kubernetes non poden crecer indefinidamente.
Existe un límite teórico no tamaño do clúster. En Kubernetes é aproximadamente .
Non obstante, na vida real, os problemas poden comezar moito antes, por exemplo, só con .
O feito é que os clústeres grandes supoñen unha gran carga na capa de control de Kubernetes. Noutras palabras, manter o clúster funcionando de forma eficiente require un axuste coidadoso.
Este problema explórase nun artigo relacionado no blog orixinal chamado "».
Pero consideremos o enfoque contrario: moitos pequenos clústeres.
2. Moitos clústeres pequenos e especializados
Con este enfoque, usa un clúster separado para cada elemento que despregue:
Moitos pequenos racimos
Para os efectos deste artigo, en virtude elemento despregable refírese a unha instancia dunha aplicación, por exemplo, unha versión de desenvolvemento dunha aplicación separada.
Esta estratexia utiliza Kubernetes como un especialista tempo de execución para instancias de aplicación individuais.
Vexamos os pros e os contras deste enfoque.
+ "Raio de explosión" limitado
Cando un clúster falla, as consecuencias negativas limítanse só ás cargas de traballo que se despregaron nese clúster. Todas as demais cargas de traballo permanecen intactas.
+ Illamento
As cargas de traballo aloxadas en clústeres individuais non comparten recursos como procesador, memoria, sistema operativo, rede ou outros servizos.
O resultado é un estrito illamento entre aplicacións non relacionadas, o que pode ser beneficioso para a súa seguridade.
+ Pequeno número de usuarios
Dado que cada clúster contén só un conxunto limitado de cargas de traballo, o número de usuarios con acceso a el redúcese.
Cantas menos persoas teñan acceso ao clúster, menor será o risco de que algo se "rompe".
Vexamos os contras.
− Uso ineficiente dos recursos
Como se mencionou anteriormente, cada clúster de Kubernetes require un conxunto específico de recursos de xestión: nodos mestres, compoñentes da capa de control, solucións de seguimento e rexistro.
No caso dun gran número de clústeres pequenos, hai que destinar unha maior parte dos recursos á xestión.
− Caro
O uso ineficiente dos recursos implica automaticamente custos elevados.
Por exemplo, manter 30 nodos mestres en lugar de tres coa mesma potencia de cálculo afectará necesariamente aos custos.
− Dificultades na administración
Xestionar varios clústeres de Kubernetes é moito máis difícil que xestionar só un.
Por exemplo, terá que configurar a autenticación e autorización para cada clúster. A versión de Kubernetes tamén terá que actualizarse varias veces.
Probablemente teña que usar a automatización para facer todas estas tarefas máis eficientes.
Agora vexamos escenarios menos extremos.
3. Un clúster por aplicación
Neste enfoque, crea un clúster separado para todas as instancias dunha aplicación concreta:
Clúster por aplicación
Este camiño pódese considerar como unha xeneralización do principio "clúster separado por equipo”, xa que normalmente un equipo de enxeñeiros está a desenvolver unha ou varias aplicacións.
Vexamos os pros e os contras deste enfoque.
+ O clúster pódese axustar á aplicación
Se unha aplicación ten necesidades especiais, pódense implementar nun clúster sen afectar a outros clústeres.
Tales necesidades poden incluír traballadores da GPU, certos complementos de CNI, unha malla de servizos ou algún outro servizo.
Cada clúster pódese adaptar á aplicación que se executa nel para que só conteña o necesario.
− Contornas diferentes nun clúster
A desvantaxe deste enfoque é que no mesmo clúster coexisten instancias de aplicacións de diferentes ambientes.
Por exemplo, a versión prod da aplicación execútase no mesmo clúster que a versión dev. Isto tamén significa que os desenvolvedores operan no mesmo clúster no que se opera a versión de produción da aplicación.
Se, debido ás accións dos desenvolvedores ou a fallas na versión de desenvolvemento, se produce un fallo no clúster, a versión prod tamén podería sufrir, un gran inconveniente deste enfoque.
E por último, o último escenario da nosa lista.
4. Un clúster por ambiente
Este escenario implica asignar un clúster separado para cada ambiente:
Un clúster por ambiente
Por exemplo, pode ter clusters dev, proba и produción, no que executará todas as instancias da aplicación dedicadas a un entorno específico.
Aquí están os pros e os contras deste enfoque.
+ Illamento do ambiente de prod
Dentro deste enfoque, todos os ambientes están illados entre si. Non obstante, na práctica isto é especialmente importante nun ambiente de produtos.
As versións de produción da aplicación agora son independentes do que está a suceder noutros clústeres e contornos.
Deste xeito, se de súpeto xorde un problema no clúster de desenvolvemento, as versións prod das aplicacións seguirán funcionando coma se nada pasase.
+ O clúster pódese axustar ao ambiente
Cada cluster pódese axustar ao seu entorno. Por exemplo, pode:
- instalar ferramentas para o desenvolvemento e depuración no clúster de desenvolvemento;
- instalar marcos de proba e ferramentas no clúster proba;
- utilizar canles de rede e hardware máis potentes no clúster produción.
Isto permítelle aumentar a eficiencia tanto do desenvolvemento como da operación de aplicacións.
+ Restrinxir o acceso ao clúster de produción
A necesidade de traballar directamente cun clúster de produtos raramente xorde, polo que pode limitar significativamente o círculo de persoas que teñen acceso a el.
Podes ir aínda máis lonxe e denegar o acceso das persoas a este clúster por completo e realizar todas as implantacións mediante unha ferramenta de CI/CD automatizada. Este enfoque minimizará o risco de erros humanos exactamente onde sexa máis relevante.
E agora algunhas palabras sobre os contras.
− Sen illamento entre aplicacións
A principal desvantaxe do enfoque é a falta de illamento de hardware e recursos entre aplicacións.
As aplicacións non relacionadas comparten recursos do clúster: o núcleo do sistema, o procesador, a memoria e algúns outros servizos.
Como se mencionou, isto pode ser potencialmente perigoso.
− Incapacidade para localizar as dependencias da aplicación
Se unha aplicación ten requisitos especiais, deben cumprirse en todos os clústeres.
Por exemplo, se unha aplicación require unha GPU, entón cada clúster debe conter polo menos un traballador cunha GPU (aínda que só a use esa aplicación).
Como resultado, corremos o risco de custos máis elevados e de uso ineficiente dos recursos.
Conclusión
Se tes un conxunto específico de aplicacións, pódense colocar en varios grupos grandes ou en moitos pequenos.
O artigo analiza os pros e os contras de varios enfoques, que van desde un clúster global ata varios pequenos e altamente especializados:
- un gran clúster xeral;
- moitos pequenos clusters altamente especializados;
- un clúster por aplicación;
- un clúster por ambiente.
Entón, que enfoque deberías tomar?
Como sempre, a resposta depende do caso de uso: cómpre sopesar os pros e os contras dos diferentes enfoques e escoller a opción máis óptima.
Non obstante, a elección non se limita aos exemplos anteriores: podes usar calquera combinación deles.
Por exemplo, podes organizar un par de clústeres para cada equipo: un clúster de desenvolvemento (no que haberá contornas dev и proba) e cluster para produción (onde se situará o entorno de produción).
Con base na información deste artigo, pode optimizar os pros e os contras en consecuencia para un escenario específico. Moita sorte!
PS
Lea tamén no noso blog:
- «»;
- «»;
- «»;
- «».
Fonte: www.habr.com