O Kubernetes parece se concentrar na implantação de contêineres em uma nuvem de clusters. O que parece não tocar são os ambientes de desenvolvimento e preparação (ou semelhantes).

Durante o desenvolvimento, você deseja estar o mais próximo possível do ambiente de produção, com algumas mudanças importantes:

• Implantado localmente (ou pelo menos em algum lugar onde você e somente você possa acessar )
• Use o código-fonte mais recente na atualização da página (supondo que seja um site; de ​​preferência, a atualização automática da página ao salvar o arquivo local, o que pode ser feito se você montar o código-fonte e usar algumas coisas como Yeoman ).

Da mesma forma, pode-se querer um ambiente não público para fazer integração contínua .

O Kubernetes oferece suporte para esse tipo de ambiente de desenvolvimento ou é algo que se deve construir, esperando que durante a produção ainda funcione?

Atualização (15/07/2016)

Com o lançamento do Kubernetes 1.3, o Minikube agora é a maneira recomendada de executar o Kubernetes em sua máquina local para desenvolvimento.

Você pode executar o Kubernetes localmente via Docker . Depois de ter um nó em execução, você pode iniciar um pod que tem um servidor da web simples e monta um volume de sua máquina host. Quando você acessar o servidor da web, ele lerá do volume e, se você alterou o arquivo em seu disco local, ele pode fornecer a versão mais recente.

Estamos trabalhando em uma ferramenta para fazer isso. A ideia básica é que você tenha um cluster Kubernetes remoto, efetivamente um ambiente de teste, e então execute o código localmente e ele é enviado por proxy para o cluster remoto. Você obtém acesso à rede transparente, variáveis ​​de ambiente copiadas, acesso a volumes ... o mais próximo possível de um ambiente remoto, mas com seu código rodando localmente e sob seu controle total.

Então você pode fazer desenvolvimento ao vivo, digamos. Docs em http://telepresence.io

O tipo de "recarga a quente" é algo que temos planos de adicionar, mas não é tão fácil quanto poderia ser hoje. No entanto, se você estiver se sentindo aventureiro, pode usar rsync com docker exec, kubectl exec ou osc exec (todos fazem a mesma coisa) para sincronizar um diretório local em um contêiner sempre que ele for alterado. Você pode usar rsync com kubectl ou osc exec assim:

# rsync using osc as netcat
$ rsync -av -e 'osc exec -ip test -- /bin/bash' mylocalfolder/ /tmp/remote/folder

Outro ótimo ponto de partida é esta configuração do Vagrant , esp. se o seu sistema operacional host for Windows. As vantagens óbvias são

• configuração rápida e indolor
• fácil de destruir / recriar a máquina
• limite implícito de recursos
• capacidade de testar a escala horizontal criando vários nós

As desvantagens - você precisa de muita RAM e o VirtualBox é o VirtualBox ... para melhor ou pior.

Uma vantagem / desvantagem mista é o mapeamento de arquivos por meio do NFS. Em nossa configuração, criamos dois conjuntos de definições RC - um que apenas faz o download de uma imagem docker de nossos servidores de aplicativos; o outro com 7 linhas extras que configuram o mapeamento de arquivo de HostOS -> Vagrant -> VirtualBox -> CoreOS -> pod Kubernetes; sobrescrever o código-fonte da imagem Docker.

A desvantagem disso é o cache de arquivo NFS - com ele, é problemático, sem ele, é problemática e lento. Mesmo a configuração mount_options: 'nolock,vers=3,udp,noac'não elimina completamente os problemas de cache, mas funciona na maioria das vezes. Algumas tarefas Gulp executadas em um contêiner podem levar 5 minutos, quando levam 8 segundos no sistema operacional host. Um bom compromisso parece ser mount_options: 'nolock,vers=3,udp,ac,hard,noatime,nodiratime,acregmin=2,acdirmin=5,acregmax=15,acdirmax=15'.

Quanto ao recarregamento automático do código, isso é específico da linguagem, mas estamos felizes com o devserver do Django para Python e Nodemon para Node.js. Para projetos de front-end, é claro que você pode fazer muito com algo como gulp + browserSync + watch, mas para muitos desenvolvedores não é difícil servir a partir do Apache e apenas fazer o hard refresh tradicional.

Mantemos 4 conjuntos de arquivos yaml para o Kubernetes. Dev, "devstable", estágio, prod. As diferenças entre aqueles são

• variáveis ​​env definindo explicitamente o ambiente (dev / stage / prod)
• número de réplicas
• devstable, stage, prod usa imagens docker
• dev usa imagens docker e mapeia a pasta NFS com o código-fonte sobre elas.

É muito útil criar vários aliases de bash e autocompletar - posso apenas digitar rec userse pronto kubectl delete -f ... ; kubectl create -f .... Se eu quiser que toda a configuração seja iniciada, eu digito recfoe ele recria uma dúzia de serviços, puxando as últimas imagens do docker, importando o db dump mais recente do Staging env e limpando arquivos antigos do Docker para economizar espaço.

Acabei de começar com o Skaffold

É realmente útil aplicar alterações no código automaticamente a um cluster local.

Para implantar um cluster local, a melhor maneira é Minikube ou apenas Docker para Mac e Windows, ambos incluem uma interface Kubernetes.

Consulte https://github.com/kubernetes/kubernetes/issues/12278 para saber como montar um volume da máquina host, o equivalente a:

docker run -v hostPath:ContainerPath

Ter um bom ciclo de feedback de desenvolvimento local é um tópico de rápido desenvolvimento no ecossistema Kubernetes.

Resolvendo essa questão, existem algumas ferramentas que acredito apoiar bem esse objetivo.

Docker para Mac Kubernetes

Docker para Mac Kubernetes ( Docker Desktop é o nome genérico de plataforma cruzada) oferece uma excelente opção para desenvolvimento local. Para virtualização, ele usa o HyperKit, que é construído na estrutura nativa do Hypervisor no macOS em vez do VirtualBox.

O recurso Kubernetes foi lançado pela primeira vez como beta no canal de borda em janeiro de 2018 e já percorreu um longo caminho desde então, tornando-se um Kubernetes certificado em abril de 2018 e passando para o canal estável em julho de 2018 .

Na minha experiência, é muito mais fácil trabalhar com o Minikube, especialmente no macOS, e especialmente quando se trata de problemas como RBAC, Helm, hipervisor, registro privado, etc.

Leme

No que diz respeito à distribuição de seu código e à obtenção de atualizações localmente, o Helm é uma das opções mais populares. Você pode publicar seus aplicativos via CI / CD como gráficos Helm (e também as imagens Docker subjacentes às quais eles fazem referência). Em seguida, você pode obter esses gráficos de seu registro de gráficos do Helm localmente e atualizar em seu cluster local.

Rascunho do Azure

Você também pode usar uma ferramenta como o Azure Draft para fazer implantações locais simples e gerar gráficos básicos do Helm a partir de modelos de linguagem comum, como buildpacks, para automatizar essa peça do quebra-cabeça.

Skaffold

Skaffold é como o Azure Draft, mas mais maduro, muito mais amplo em escopo e feito pelo Google. Possui uma arquitetura muito plugável. Acho que, no futuro, mais pessoas o usarão para o desenvolvimento de aplicativos locais para o Kubernetes.

Se você já usou o React, penso no Skaffold como " Criar aplicativo React para Kubernetes".

Kompose ou Compose no Kubernetes

O Docker Compose , embora não relacionado ao Kubernetes, é uma alternativa que algumas empresas usam para fornecer um ambiente de desenvolvimento local simples, fácil e portátil, análogo ao ambiente Kubernetes executado na produção. No entanto, seguir esse caminho significa divergir suas configurações de produção e desenvolvimento local.

Kompose é um conversor do Docker Compose para Kubernetes. Esse pode ser um caminho útil para alguém que já está executando seus aplicativos como coleções de contêineres localmente.

Compose no Kubernetes é uma oferta de código aberto recentemente (dezembro de 2018) do Docker que permite implantar arquivos Docker Compose diretamente em um cluster do Kubernetes por meio de um controlador personalizado.

Kubespary é útil para configurar clusters locais. Principalmente, usei cluster baseado em vagrant na máquina local.

Configuração do Kubespray Você pode ajustar essas variáveis ​​para ter a versão desejada do kubernetes.

A desvantagem de usar minkubeé que ele gera outra máquina virtual em sua máquina. Além disso, com a minikubeversão mais recente, ele requer, no mínimo, 2 CPUs e 2 GB de RAM do seu sistema, o que o torna bastante pesado se você não tiver o sistema com recursos suficientes.

Este é o motivo pelo qual mudei microk8spara o desenvolvimento no kubernetes e adoro isso. microk8ssuporta DNS, armazenamento local, painel, istio, ingress e muito mais, tudo que você precisa para testar seus microsserviços.

Ele foi projetado para ser uma instalação upstream rápida e leve do Kubernetes, isolada do seu ambiente local. Esse isolamento é obtido empacotando todos os binários para Kubernetes, Docker.io, iptables e CNI em um único pacote de snap.

Um cluster de Kubernetes de nó único pode ser instalado em um minuto com um único comando:

snap install microk8s --classic

Certifique-se de que seu sistema não tenha nenhum docker ou serviço kubelet em execução. Microk8sirá instalar todos os serviços necessários automaticamente.

Por favor, dê uma olhada no seguinte link para habilitar outros add ons em microk8s.

https://github.com/ubuntu/microk8s

Você pode verificar o status usando:

velotio@velotio-ThinkPad-E470:~/PycharmProjects/k8sClient$ microk8s.status
microk8s is running
addons:
ingress: disabled
dns: disabled
metrics-server: disabled
istio: disabled
gpu: disabled
storage: disabled
dashboard: disabled
registry: disabled

Dê uma olhada em https://github.com/okteto/okteto e Okteto Cloud . A proposta de valor é ter a experiência de desenvolvimento clássica do que trabalhar localmente, antes do docker, onde você pode ter hot-reloads, compilações incrementais, depuradores ... mas todas as suas alterações locais são imediatamente sincronizadas para um contêiner remoto. Os contêineres remotos fornecem acesso à velocidade da nuvem, permitem um novo nível de colaboração e integram o desenvolvimento em um ambiente de produção. Além disso, elimina o peso das instalações locais.

Conforme especificado anteriormente por Robert, minikube é o caminho a percorrer.

Aqui está um guia rápido para começar a usar o minikube. As etapas gerais são:

• Instale minikube

• Crie um cluster de minikube (em uma máquina virtual que pode ser VirtualBox ou Docker para Mac ou HyperV no caso do Windows)

• Crie uma imagem Docker do arquivo do seu aplicativo (usando Dockerfile)

• Execute a imagem criando uma implantação

• Crie um serviço que exponha seu aplicativo para que você possa acessá-lo.