De containers do docker para o Google Kubernetes

6

Este é um pouco teórico, mas por favor, tenha paciência comigo.

Atualmente, tenho um servidor executando alguns contêineres do Docker (4 ou 5, dependendo do dia e da hora). Eu pretendo adicionar outro, assim como o primeiro, e talvez até um terceiro.

Agora, minha pergunta é: se chegar a hora de gerenciar 15 contêineres, em vez de cinco, será que há algum mérito em usar o Google Kubernetes?

Além disso, existe um fluxo de trabalho 'oficial', ou pelo menos 'definitivo', para migrar de contêineres do Docker para 'pods', a unidade nativa do Kubernetes. Antes que você pergunte, eu sei que os pods são feitos de recipientes (algumas vezes até um). Meu principal problema aqui é que 'dockerfiles' são completamente diferentes das configurações do pod.

Alguma idéia?

    
por dsljanus 15.01.2015 / 15:43

2 respostas

6

Should the time come that I have 15 containers to manage, instead of 5, is there any merit in using Google Kubernetes?

Se você executar contêineres em um único servidor usando o daemon do Docker e seus Remote API parece apropriado.

Se você precisar executar contêineres em mais de um servidor, é onde as soluções de orquestração, como Kubernetes , Enxame do Docker , Frota , Mesos , Geard se torna útil.

My primary issue here is that 'dockerfiles' are completely different from pod configs.

Porque eles têm finalidades diferentes:

  • Dockerfile especifica como construir uma imagem de contêiner de uma árvore de fontes
  • pod.yaml define como agendar (imagem, linha de comando, volumes, porta) um conjunto de contêineres co-localizados (compartilhando espaço de nomes de rede e volumes) em um dos nós do cluster.

Você pode ver os pods como uma maneira declarativa de especificar um conjunto de comandos docker run --net=container:... -v ... -p ... .

Also, is there an 'official', or at least 'definitive', workflow to migrate from Docker containers to 'pods', the native unit of Kubernetes.

Existe uma pequena ferramenta em kubernetes / contrib chamada podex que permitem gerar um manifesto de pods a partir de metadados de imagens armazenados no registro público.

$ go get github.com/GoogleCloudPlatform/kubernetes/contrib/podex
$ podex google/nodejs-hello
id: nodejs-hello
kind: Pod
apiVersion: v1beta1
desiredState:
  manifest:
    version: v1beta2
    containers:
    - name: nodejs-hello
      image: google/nodejs-hello
      ports:
      - name: nodejs-hello-tcp-8080
        containerPort: 8080
    
por 04.02.2015 / 20:33
0

@ resposta de proppy está correta: Uma só funciona para um único servidor.

Eu tive a mesma reação inicial, mas você pode ter vários serviços e pods em um único arquivo (separados por --- ). Dessa forma, você ainda tem 1 serviço + 1 pod por contêiner em geral, mas isso não é tão ruim.

Você também tem que nomear um monte de coisas mais do que no docker-compose (às vezes eu sinto que é mais do que necessário). Uma vez que você passou a aprender qual nome importa, você estará bem e a manutenção dos arquivos não será muito mais difícil.

A implantação é um IMO muito mais pesado, mas novamente é distribuída, e também está vindo um tipo de Deployment Pod que deve simplificar as atualizações (atualmente como extensão beta na v1.1).

    
por 21.11.2015 / 10:19