🧙 🤞🏻 🚣🏻 7 fatores ausentes na abordagem 12 Factor App ✌🏾 🤰🏼 🍗

Nota perev. : O entusiasmo que nossos líderes de equipe experimentaram ao ver esse material no blog IBM Cloud - uma espécie de "extensão" do lendário Twelve-Factor App - fala por si. As perguntas levantadas pelo autor não são apenas de ouvido, mas verdadeiramente vitais, ou seja, relevante na vida cotidiana. Seu entendimento é útil não apenas para engenheiros de DevOps, mas também para desenvolvedores que criam aplicativos modernos em execução no Kubernetes.

A conhecida metodologia de aplicação de 12 fatores é um conjunto de regras bem definidas para o desenvolvimento de microsserviços. Eles são amplamente usados para executar, dimensionar e implantar aplicativos. Na plataforma IBM Cloud Private, seguimos os mesmos 12 princípios ao desenvolver aplicativos em contêiner. O artigo “ Kubernetes e aplicativos com 12 fatores” discute as especificidades do uso desses 12 fatores (eles são suportados pelo modelo de orquestração de contêiner Kubernetes).

Pensando nos princípios do desenvolvimento de microsserviços em contêiner que funcionam sob o controle do Kubernetes, chegamos à seguinte conclusão: os 12 fatores acima são completamente verdadeiros, mas outros também são extremamente importantes para organizar um ambiente de produção:

observável
previsibilidade (agendável) ;
capacidade de atualização (atualizável) ;
privilégios mínimos
controlabilidade (auditável) ;
segurança (protegível) ;
mensurável

Vamos nos debruçar sobre esses princípios e tentar avaliar sua importância. Para manter a uniformidade, nós os adicionamos aos já existentes - portanto, começaremos com o XIII ...

Princípio XIII: Observabilidade

Os aplicativos devem fornecer informações sobre seus status e indicadores atuais.

Pode ser difícil gerenciar sistemas distribuídos porque muitos microsserviços estão integrados a um aplicativo. De fato, as várias engrenagens devem mover-se em conjunto para que o mecanismo (aplicativo) funcione. Se ocorrer uma falha em um dos microsserviços, o sistema deve detectá-lo e corrigi-lo automaticamente. O Kubernetes fornece excelentes mecanismos de resgate, como testes de prontidão e vivacidade .

Com a ajuda deles, o Kubernetes garante que o aplicativo esteja pronto para receber tráfego. Se a prontidão falhar, o Kubernetes para de enviar tráfego para o pod até que o próximo teste mostre que o pod está pronto.

Suponha que tenhamos um aplicativo composto por 3 microsserviços: frontend, lógica de negócios e um banco de dados. Para que o aplicativo funcione, antes de aceitar o tráfego, o front-end deve garantir que a lógica de negócios e os bancos de dados estejam prontos. Isso pode ser feito usando o teste de prontidão - permite garantir que todas as dependências estejam funcionando.

A animação mostra que as solicitações ao pod não são enviadas até que o teste de prontidão mostre sua prontidão:

Teste de prontidão em ação: o Kubernetes usa o probe de prontidão para verificar se os pods estão prontos para receber tráfego

Existem três tipos de testes: usando HTTP, solicitações TCP e comandos. Você pode controlar a configuração dos testes, por exemplo, indicar a frequência de partidas, limites de sucesso / falha e quanto tempo esperar por uma resposta. No caso de testes de animação, você precisa definir um parâmetro muito importante - initialDelaySeconds . Certifique-se de que o teste seja iniciado somente depois que o aplicativo estiver pronto. Se este parâmetro estiver definido incorretamente, o aplicativo será reiniciado constantemente. Veja como isso pode ser implementado:

 livenessProbe: # an http probe httpGet: path: /readiness port: 8080 initialDelaySeconds: 20 periodSeconds: 5

Por meio de testes de animação, o Kubernetes verifica se seu aplicativo está sendo executado. Se o aplicativo estiver funcionando normalmente, o Kubernetes não fará nada. Se "morrer", o Kubernetes remove o pod e inicia um novo em troca. Isso corresponde às necessidades dos microsserviços apátridas e à sua reciclabilidade ( fator IX, Descartabilidade ). A animação abaixo ilustra uma situação em que o Kubernetes reinicia o pod depois de falhar no teste de animação:

Teste de vivacidade em ação: o Kubernetes verifica se os pods estão “vivos” com ele

A grande vantagem desses testes é que você pode implantar aplicativos em qualquer ordem sem se preocupar com dependências.

No entanto, descobrimos que esses testes não são suficientes para o ambiente de produção. Normalmente, os aplicativos têm suas próprias métricas que precisam ser rastreadas, por exemplo, o número de transações por segundo. Os clientes definem limites para eles e configuram notificações. O IBM Cloud Private preenche essa lacuna com a pilha de monitoramento altamente segura do Prometheus e Grafana com um sistema de controle de acesso baseado em função. Consulte a seção de monitoramento de cluster IBM Cloud Private para obter mais informações.

O Prometheus coleta dados de destino a partir de métricas de terminal. Seu aplicativo deve especificar métricas de terminal usando a seguinte anotação:

 prometheus.io/scrape: 'true'

Depois disso, o Prometheus detecta automaticamente o terminal e coleta métricas (como mostrado na animação a seguir):

Coleção de métricas personalizadas

Nota perev. : Seria mais correto girar as setas na direção oposta, já que Prometheus caminha e pesquisa pontos finais, e o próprio Grafana obtém dados de Prometheus, mas, no sentido de uma ilustração geral, isso não é tão crítico.

Princípio XIV: Previsibilidade

Os aplicativos devem fornecer previsibilidade dos requisitos de recursos.

Imagine que um guia escolheu sua equipe para experimentar um projeto Kubernetes. Você trabalhou duro para criar um ambiente apropriado. O resultado é um aplicativo que demonstra tempo de resposta e desempenho exemplares. Em seguida, outra equipe se juntou ao trabalho. Ela criou seu aplicativo e o lançou no mesmo ambiente. Após o lançamento do segundo aplicativo, o desempenho do primeiro diminuiu repentinamente. Nesse caso, o motivo desse comportamento deve ser procurado nos recursos de computação (CPU e memória) disponíveis para seus contêineres. Alta probabilidade de sua deficiência. Surge a pergunta: como garantir a alocação de recursos computacionais necessários ao aplicativo?

O Kubernetes tem uma excelente opção que permite definir mínimos de recursos e restrições para contêineres. Os mínimos são garantidos. Se um contêiner exigir um recurso, o Kubernetes o executará apenas no host que esse recurso pode fornecer. Por outro lado, o limite superior garante que o apetite do recipiente nunca exceda um determinado valor.

Mínimos e restrições para contêineres

O seguinte trecho de código YAML mostra o ajuste dos recursos de computação:

 resources: requests: memory: "64Mi" cpu: "150m" limits: memory: "64Mi" cpu: "200m"

Nota perev. : Para obter mais informações sobre o fornecimento de recursos no Kubernetes, solicitações e limites, consulte nosso relatório recente e sua revisão, “ Escalonamento automático e gerenciamento de recursos no Kubernetes ”, além da documentação do K8s .

Outra oportunidade interessante para administradores em um ambiente de produção é definir cotas para namespace . Se a cota for definida, o Kubernetes não criará contêineres para os quais solicitações / limites não estão definidos neste espaço para nome. Um exemplo de configuração de cotas para namespace pode ser visto na figura abaixo:

Cotas para namespaces

Princípio XV. Capacidade de atualização

Os aplicativos devem atualizar os formatos de dados das gerações anteriores.

Freqüentemente, é necessário corrigir um aplicativo de produção em funcionamento para eliminar uma vulnerabilidade ou expandir a funcionalidade. É importante que a atualização ocorra sem interrupções no trabalho. O Kubernetes fornece um mecanismo de atualização contínua que permite atualizar seu aplicativo sem tempo de inatividade. Usando esse mecanismo, você pode atualizar por pod de cada vez sem interromper o serviço inteiro. Aqui está uma representação esquemática desse processo (nele o aplicativo é atualizado para a segunda versão):

Um exemplo de uma descrição YAML correspondente:

 minReadySeconds: 5 strategy: # ,      type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 1

Preste atenção aos maxSurge e maxSurge :

maxUnavailable - um parâmetro opcional que define o número máximo de pods que podem não estar disponíveis durante o processo de atualização. Embora seja opcional, ainda vale a pena definir um valor específico para garantir a disponibilidade do serviço;
maxSurge é outro parâmetro opcional, mas crítico. Ele define o número máximo de pods que podem ser criados além do número desejado.

Princípio XVI: Privilégios Mínimos

Os contêineres devem trabalhar com um mínimo de privilégios.

Parece pessimista, mas você deve pensar em cada resolução no contêiner como uma vulnerabilidade em potencial (veja a ilustração). Por exemplo, se o contêiner for executado como root, qualquer pessoa com acesso a ele poderá injetar um processo malicioso no local. O Kubernetes fornece uma Política de Segurança de Pod (PSP) para restringir o acesso ao sistema de arquivos, porta do host, recursos do Linux e muito mais. O IBM Cloud Private oferece um conjunto pronto de PSPs que se vincula aos contêineres quando eles são provisionados no espaço para nome. Para obter mais informações, consulte Usando namespaces com políticas de segurança de pod .

Toda resolução é um potencial vetor de ataque

Princípio XVII: Controlabilidade

Você precisa saber quem, o que, onde e quando para todas as operações de missão crítica.

A controlabilidade é crítica para qualquer operação com um cluster ou aplicativo Kubernetes. Por exemplo, se o aplicativo processar transações com cartão de crédito, você precisará habilitar uma auditoria para ter um rastreamento de controle de cada transação. O IBM Cloud Private usa o CADF ( Cloud Auditing Data Federation ) padrão do setor, que é invariável para implementações específicas da nuvem. Para obter mais informações, consulte Log de auditoria no IBM Cloud Private .

Um evento CADF contém os seguintes dados:

initiator_id - ID do usuário que executou a operação;
target_uri - target_uri URI de destino (por exemplo: dados / segurança / projeto);
action - a action ser executada, geralmente operation: resource_type .

Princípio XVIII: Segurança (identificação, rede, escopo, certificados)

É necessário proteger o aplicativo e os recursos de estranhos.

Este item merece um artigo separado. Basta dizer que os aplicativos de produção precisam de proteção de ponta a ponta. O IBM Cloud Private toma as seguintes medidas para garantir a segurança dos ambientes de produção:

autenticação: verificação de identidade;
autorização: verificação de acesso de usuário autenticado;
gerenciamento de certificados: trabalhe com certificados digitais, incluindo criação, armazenamento e renovação;
proteção de dados: garantir a segurança dos dados transmitidos e armazenados;
segurança e isolamento da rede: impedindo o acesso à rede por usuários e processos não autorizados;
consultor de vulnerabilidades: identificando vulnerabilidades em imagens;
Consultor de Mutação: Detecção de mutações em contêineres.

Para obter mais informações, consulte o IBM Cloud Private Security Guide .

De nota particular é o gerenciador de certificados. Este serviço no IBM Cloud Private é baseado no projeto de código aberto Jetstack . O Certificate Manager permite emitir e gerenciar certificados para serviços em execução no IBM Cloud Private. Ele suporta certificados públicos e autoassinados, integra-se totalmente ao kubectl e controle de acesso baseado em função.

Princípio XIX: Mensurabilidade

O uso do aplicativo deve ser mensurável para fins de cotas e acordos entre departamentos.

Por fim, as empresas precisam pagar os custos de TI (veja a figura abaixo). Os recursos de computação dedicados à execução de contêineres devem ser mensuráveis e as organizações que usam o cluster devem ser responsáveis. Certifique-se de seguir o Princípio XIV - Previsibilidade. O IBM Cloud Private oferece um serviço de contabilidade que coleta dados sobre recursos de computação para cada contêiner e os combina no nível do espaço para nome para cálculos adicionais (como parte de retrocessos ou estornos).

O uso do aplicativo deve ser mensurável.

Conclusão

Espero que você tenha gostado do tópico mencionado neste artigo e tenha notado os fatores que já está usando e pensado sobre os que ainda estão à margem.

Para obter mais informações, recomendo que você se familiarize com a gravação de nosso desempenho no KubeCon 2019 em Xangai. Nele, Michael Elder e eu discutimos 12 + 7 princípios para orquestração de contêineres baseados em Kubernetes.

7 fatores ausentes na abordagem 12 Factor App