O problema com aplicativos com estado no Kubernetes
A configuração, o lançamento e o dimensionamento adicional de aplicações e serviços são fáceis quando se trata de casos classificados como sem estado, ou seja, sem salvar dados. É conveniente executar tais serviços no Kubernetes, utilizando suas APIs padrão, porque tudo acontece “pronto para usar”: de acordo com configurações padrão, sem envolver nenhum detalhe ou mágica.
Simplificando, para lançar mais cinco cópias do backend em PHP/Ruby/Python em um cluster de containers, você só precisa configurar um novo servidor 5 vezes e copiar os fontes. Como tanto o código-fonte quanto o script de inicialização estão na imagem, dimensionar um aplicativo sem estado torna-se completamente elementar. Como bem sabem os fãs de containers e arquitetura de microsserviços, a dificuldade começa com aplicativos com estado, ou seja com persistência de dados como bancos de dados e caches (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Isso se aplica tanto a softwares que implementam independentemente um cluster de quorum (por exemplo, Percona XtraDB e Cassandra) quanto a softwares que requerem utilitários de gerenciamento separados (como Redis, MySQL, PostgreSQL...).
As dificuldades surgem porque o código-fonte e o lançamento do serviço não são mais suficientes - é necessário realizar mais algumas etapas. No mínimo, copie os dados e/ou ingresse no cluster. Mais precisamente, estes serviços requerem uma compreensão de como dimensioná-los, atualizá-los e reconfigurá-los adequadamente sem perda de dados ou indisponibilidade temporária. Levar essas necessidades em consideração é chamado de “conhecimento operacional”.
Operadores CoreOS
Para “programar” o conhecimento operacional, no final do ano passado o projeto CoreOS “uma nova classe de software” para a plataforma Kubernetes - Operadores (do inglês “operação”, ou seja, “operação”).
Operadores que usam e ampliam os recursos principais do Kubernetes (incl. Conjuntos de estado, veja a diferença abaixo) permitem que especialistas em DevOps adicionem conhecimento operacional ao código do aplicativo.
Objetivo do Operador - fornecer ao usuário uma API que permite gerenciar várias entidades de aplicativos com estado em um cluster Kubernetes, sem pensar no que está por trás (quais dados e o que fazer com eles, quais comandos ainda precisam ser executados para manter o cluster ). Na verdade, o Operador foi pensado para simplificar ao máximo o trabalho com a aplicação dentro do cluster, automatizando a execução de tarefas operacionais que antes tinham que ser resolvidas manualmente.
Como funcionam os operadores
ReplicaSets O Kubernetes permite que você especifique o número desejado de pods em execução, e os controladores garantem que seu número seja mantido (criando e excluindo pods). Um Operador funciona de maneira semelhante, adicionando um conjunto de conhecimento operacional a um recurso e controlador padrão do Kubernetes que permite executar ações adicionais para dar suporte ao número necessário de entidades de aplicativo.
Como isso é diferente de Conjuntos de estado, projetado para aplicativos que exigem que o cluster forneça recursos com estado, como armazenamento de dados ou IPs estáticos? Para tais aplicações, os operadores podem usar Conjuntos de estado (em vez de ReplicaSets) como base, oferecendo automação adicional: realizar as ações necessárias em caso de travamentos, fazer backups, atualizar a configuração, etc.
Assim, como tudo isso funciona? O operador é um daemon gerenciador que:
- assina a API de eventos no Kubernetes;
- recebe dele dados sobre o sistema (sobre seu ReplicaSets, vagens, Serviços e assim por diante.);
- recebe dados sobre Recursos de terceiros (veja exemplos abaixo);
- reage à aparência/mudança Recursos de terceiros (por exemplo, para alterar o tamanho, alterar a versão e assim por diante);
- reage a mudanças no estado do sistema (sobre sua ReplicaSets, vagens, Serviços e assim por diante.);
- o mais importante:
- chama a API Kubernetes para criar tudo o que precisa (novamente, seu próprio ReplicaSets, vagens, Serviços...),
- faz alguma mágica (para simplificar, você pode pensar que o próprio Operador entra nos pods e chama comandos, por exemplo, para ingressar em um cluster ou para atualizar o formato dos dados ao atualizar uma versão).
Na verdade, como pode ser visto na imagem, um aplicativo separado é simplesmente adicionado ao Kubernetes (um aplicativo regular desenvolvimento с Conjunto de réplicas), que é chamado de Operador. Ele vive em um grupo comum (geralmente apenas um) e, via de regra, é responsável apenas por seu Namespace. Este aplicativo operador implementa sua API - embora não diretamente, mas por meio de Recursos de terceiros em Kubernetes.
Assim, depois de termos criado em Namespace Operador, podemos adicionar a ele Recursos de terceiros.
Exemplo para etcd (veja abaixo para detalhes):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Exemplo para Elasticsearch:
apiVersion: enterprises.upmc.com/v1
kind: ElasticsearchCluster
metadata:
name: example-es-cluster
spec:
client-node-replicas: 3
master-node-replicas: 2
data-node-replicas: 3
zones:
- us-east-1c
- us-east-1d
- us-east-1e
data-volume-size: 10Gi
java-options: "-Xms1024m -Xmx1024m"
snapshot:
scheduler-enabled: true
bucket-name: elasticsnapshots99
cron-schedule: "@every 2m"
storage:
type: gp2
storage-class-provisioner: kubernetes.io/aws-ebs
Requisitos para Operadores
CoreOS formulou os principais padrões obtidos pelos engenheiros enquanto trabalhavam em Operadores. Apesar de todos os Operadores serem individuais (criados para uma aplicação específica com características e necessidades próprias), a sua criação deve basear-se numa espécie de framework que impõe os seguintes requisitos:
- A instalação deve ser feita através de um único desenvolvimento: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - e não requer ações adicionais.
- Ao instalar um Operador no Kubernetes, um novo tipo de terceiro deve ser criado (Recurso de terceiros). Para iniciar instâncias de aplicativos (instâncias de cluster) e gerenciá-las posteriormente (atualização de versões, redimensionamento, etc.), o usuário utilizará este tipo.
- Sempre que possível, você deve usar os primitivos integrados ao Kubernetes, como Serviços и ReplicaSetsusar código bem testado e compreensível.
- Requer compatibilidade retroativa de Operadores e suporte para versões mais antigas de recursos criados pelo usuário.
- Se o Operador for removido, o próprio aplicativo deverá continuar funcionando sem alterações.
- Os usuários devem ser capazes de definir a versão desejada do aplicativo e orquestrar atualizações de versão do aplicativo. A falta de atualizações de software é uma fonte comum de problemas operacionais e de segurança, por isso os Operadores devem ajudar os usuários nesta questão.
- Os operadores devem ser testados com uma ferramenta como o Chaos Monkey, que identifica possíveis falhas nos pods, nas configurações e na rede.
Operador etcd
Exemplo de implementação de operador - Operador etcd, no dia do anúncio deste conceito. A configuração do cluster etcd pode ser complexa devido à necessidade de manter o quorum, à necessidade de reconfigurar a associação ao cluster, criar backups, etc. Por exemplo, dimensionar manualmente um cluster etcd significa que você precisa criar um nome DNS para um novo membro do cluster, iniciar uma nova entidade etcd e alertar o cluster sobre o novo membro (adição de membro etcdctl). No caso da Operadora, o usuário precisará apenas alterar o tamanho do cluster – todo o resto acontecerá automaticamente.
E como o etcd também foi criado no CoreOS, era bastante lógico ver seu Operador aparecer primeiro. Como ele funciona? Lógica do operador etcd é determinado por três componentes:
- Observar. O operador monitora o estado do cluster usando a API Kubernetes.
- Análise. Encontra diferenças entre o estado atual e o desejado (definido pela configuração do usuário).
- Ação. Resolve diferenças detectadas usando as APIs de serviço etcd e/ou Kubernetes.
Para implementar esta lógica, foram preparadas funções no Operador Criar/Destruir (criando e excluindo membros do cluster etcd) e Redimensionar (mudança no número de membros do cluster). A exatidão de seu funcionamento foi verificada por meio de um utilitário criado à semelhança do Chaos Monkey da Netflix, ou seja, matando pods etcd aleatoriamente.
Para operação completa do etcd, o Operador fornece recursos adicionais: backup (criação automática e invisível para os usuários de cópias de backup - na configuração basta determinar com que frequência fazê-las e quantas armazenar - e posterior restauração dos dados delas) e Atualizar (atualizando instalações do etcd sem tempo de inatividade).
Como é trabalhar com um Operador?
$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
etcd-cluster-0000 1/1 Running 0 23s
etcd-cluster-0001 1/1 Running 0 16s
etcd-cluster-0002 1/1 Running 0 8s
etcd-cluster-backup-tool-rhygq 1/1 Running 0 18s
O status atual do Operador etcd é uma versão beta, exigindo Kubernetes 1.5.3+ e etcd 3.0+ para ser executado. O código-fonte e a documentação (incluindo instruções de uso) estão disponíveis em .
Outro exemplo de implementação do CoreOS foi criado - , mas ainda está em versão alfa (nem todos os recursos planejados foram implementados).
Status e perspectivas
5 meses se passaram desde o anúncio dos Operadores Kubernetes. Ainda existem apenas duas implementações disponíveis no repositório oficial do CoreOS (para etcd e Prometheus). Ambos ainda não atingiram suas versões estáveis, mas os commits são observados diariamente.
Os desenvolvedores imaginam “um futuro em que os usuários instalem Operadores Postgres, Operadores Cassandra ou Operadores Redis em seus clusters Kubernetes e trabalhem com as entidades escalonáveis desses aplicativos tão facilmente quanto é hoje a implantação de réplicas de aplicativos da Web sem estado”. Primeiro Operadores de desenvolvedores terceirizados realmente começou a aparecer:
- da UPMC Empresas;
- da Crunchy Data (anunciado no final de março de 2017);
- dos autores de um sistema distribuído de armazenamento de dados baseado em Ceph (Rook está em status alfa);
- do SAP CCloud.
Na maior conferência europeia de software livre FOSDEM, que ocorreu em fevereiro de 2017 em Bruxelas, Josh Wood da CoreOS anunciou Operadores em (um vídeo está disponível no link!), o que deverá contribuir para o crescimento da popularidade deste conceito na comunidade Open Source mais ampla.
PS Obrigado pelo seu interesse no artigo! Inscreva-se em nosso hub, para não perder novos materiais e receitas sobre DevOps e administração de sistemas GNU/Linux - iremos publicá-los regularmente!
Fonte: habr.com