Presumo nesta publicação que já entendas de contêineres, caso precise temos um bom material para apresentar este conceito e passos iniciais, é a publicação do colega Maicon Baum que constará nas referências deste artigo.
Independente do orquestrador que estejas utilizando, sendo os mais comuns Kubernetes ou Docker Swarm, os maiores problemas das plataformas são como dimensionar recursos para que atendam aos contratos com módulos ou microsserviços das aplicações que hospedam.
Não tenhas a ambição que os orquestradores resolverão automaticamente, ou por padrão de instalação, dimensionamento de aplicações, e ainda que o façam, este ponto envolve uma análise de regras operacionais das aplicações, viabilidade de escalonamento e expansão da própria plataforma, ou até mesmo a relação de custo e retorno das aplicações envolvidas.
É por essa razão que devemos nos atentarmos para limites e políticas sejam elas por contêiner, ou de forma mais inteligente por service (Docker Swarm) ou NameSpace (K8s).
Com relação a política, seja namespace ou stack, deves considerar condições que satisfaçam o bom uso da plataforma quando relacionada às limitações de seu código.
De nada adianta liberar diversos processadores para uso de uma aplicação NodeJS se a mesma não foi desenvolvida para trabalhar multithread. Logo, isso força a mesma medida que permite a integração cada dia maior do desenvolvedor com o analista de infraestrutura da plataforma. Cito permite, pois proporciona a ambos um ganho de conhecimento.
Mencionaremos aqui como aplicar estes limites na prática nos orquestradores citados: Docker Swarm e Kubernetes.
IMPORTANTE: Em ambos é possível realizar a limitação por contêiner no Dockerfile, entretanto este não é o modelo mais eficiente quando estamos trabalhando com orquestradores e suas réplicas.
Docker Swarm
Método(s) disponível(is) : Por serviço
Aplicação: Na publicação do stack ou na criação, ou atualização individual dos serviços poderás utilizar restrições ou limitações de recursos.
No site de documentação do produto existem exemplos de aplicação, seja criando um serviço ou atualizando um.
https://docs.docker.com/engine/reference/commandline/service_create
Kubernetes
Método(s) disponível(is) :
Resource Quotas
Quality of Service
Aplicação: O Kubernetes dispõe de um modelo mais eficiente e granular de administração de recursos, então temos dois modelos, um de QoS(quality of service) e outro de Resource Quota.
Documentação para aplicação dos métodos:
https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod
https://kubernetes.io/docs/concepts/policy/resource-quotas
Um item não menos relevante é o gerenciamento de logs de sua aplicação, ainda que o limite de armazenamento de log possa ser administrado pelo orquestrador, isso demanda IO (entrada e saída) e por consequência deixar aplicações gravando informações desnecessárias e/ou com baixa criticidade afeta a performance da plataforma como um todo, lembre-se, seja na cloud pública, privada ou híbrida, IO é performance, e se tens bastante performance é porque também custa dinheiro.
Referências:
http://ilegra.com/beyonddata/2017/07/docker-for-beginners/
Palavras chave de busca:
docker swarm k8s kubernetes container contêiner limites restrições constraints limits devops
Agradecimentos:
Agradeço ao engenheiro de infraestrutura, arquiteto de software e amigo Lincolm Aguiar (https://www.linkedin.com/in/lincolmaguiar) que foi parceiro de apresentação do talkabout que foi o conteúdo norteador e originou essa publicação.
