Para que você está usando isso? Este é um tópico enorme.
Vamos manter os componentes puros da GUI fora da equação porque, para eles, os recursos envolvidos são diferentes da memória e da CPU (GPU) e não podem ser realmente distribuídos (é claro que você pode distribuir sua GPU para grandes processamentos) carrega, mas vamos deixar esse caso de uso fora da equação por enquanto).
Vamos falar sobre as aplicações do servidor (e voltar para a minha pergunta anterior, mesmo algo orientado pelo usuário como o emacs pode ser executado com um servidor backend).
Você pode criar um cluster do Kubernetes para basicamente agendar tudo o que quiser em qualquer lugar do cluster. O Kubernetes irá rodar qualquer imagem docker, alocando de forma inteligente, então o limite é o céu. Então, com isso, você já distribuiu seu CPU e RAM.
Agora, para a questão do estado mais persistente. Onde estão os arquivos? Onde estão os dados?
Você pode fazer isso de muitas maneiras diferentes.
Você deve começar com um sistema de arquivos distribuídos (ou armazenamento em bloco distribuído). Um "bom". Nesta categoria, a única estrela parece ser LizardFS. Eu ficaria longe do Ceph.
Qualquer pessoa, de qualquer lugar, onde quer que o kubernetes esteja, pode acessar o endpoint do lizardfs.
Se você estiver executando um banco de dados, é claro que você pode executar o banco de dados em cluster. Onde as instâncias do banco de dados que formam o cluster, em última análise, salvam os dados? Um dos dois lugares que eu diria:
-
As instâncias de banco de dados que formam o cluster de banco de dados são apenas contêineres docker, alocadas como qualquer outra imagem docker por kubernetes (com a restrição de ter apenas um por nó físico) e podem usar disco local onde quer que estejam alocados ( atualmente não é um Volume Persistente ).
-
O Kubernetes fornece um zilhão de tipos de volumes persistentes, que serão acessíveis a partir das instâncias do banco de dados em execução no cluster.
Observe que os próprios provedores podem ser executados como cargas de trabalho do Kubernetes, uma por máquina física. Ao fazer isso, eles usam recursos de disco locais e os disponibilizam para todo o cluster.
LizardFS infelizmente não está incluído, mas você pode expor o LizardFS como um endpoint NFS e usá-lo no Kubernetes Cluster (ainda não vi ninguém fazendo isso, se você ver algum link, por favor, compartilhe.)
ele pode usar o armazenamento de arquivos distribuídos em si (isso pode ser mais lento, existem "dois níveis de indireção").
Observe que a distribuição no caso de armazenamento pode alcançar duas coisas: - HA o fato de você ter várias cópias dos dados significa que, se uma cópia estiver indisponível, você continuará produzindo. - Escala horizontal. Basicamente, os dados são divididos e alocados para diferentes nós. (cada shard pode potencialmente ser executado em HA).
Existem, naturalmente, modos híbridos, e tudo se resume a fazer concessões dentro do teorema CAP. É um problema complexo. Por exemplo, veja como Arango faz isso .
Exemplos de bancos de dados incluem:
- Janusgraph com o backend de Cassandra
- ArangoDB
- OrientDB
Bancos de dados relacionais têm suas configurações de HA que você pode executar naturalmente no K8S. Para configurações de HA / sharding all-in-one, o ArangoDB, bem, não é tão fácil assim.
Outras tecnologias que você pode achar interessantes. Uma lista "o que eu quero rodar na minha rede local quando eu me tornar um homem real " :-). Note que eles têm requisitos de hardware mais altos, mais nós, mais RAM total, etc.
- Enxame do Docker
-
CoreOS
-
Openstack
-
DCOS
-
Openshift
- Fabric8
PS: e sim, você poderia rodar um servidor X em um container agendado do K8S ... Agora eu não quero pensar sobre isso, já que tenho o suficiente em mente com o lado do servidor. Tenho certeza de que há pessoas suficientes por aí que não têm nada melhor para fazer que executem servidores x no Kubernetes ... PS2: Infelizmente, só tenho reputação suficiente para 2 links, mas todos os keywowrds são bastante fáceis de usar.