Muito poucos servidores, mesmo os mais potentes e escaláveis, conseguem atender todas as necessidades de uma só vez. Embora o Kubernetes funcione muito bem por si só, pode faltar elementos essenciais para completude. Você sempre encontrará um caso específico que ignora sua necessidade ou em que o Kubernetes não funcionará com a instalação padrão — como o suporte a bancos de dados ou o funcionamento do CDN.
É aqui que surgem complementos, extensões e outros recursos para este orquestrador de containers, suportados por uma vasta comunidade. Neste artigo, apresentaremos 11 das melhores ferramentas que encontramos. Para nós mesmos, são muito interessantes e planejamos explorá-las praticamente — desmontando-as para ver o que há por dentro. Algumas delas complementam perfeitamente qualquer cluster Kubernetes, enquanto outras ajudam a resolver tarefas específicas não implementadas na versão padrão do Kubernetes. Gatekeeper: gestão de políticas
Open Policy Agent
Projeto Gatekeeper Gravity: Clusters Kubernetes portáveis
Se você deseja implantar uma aplicação no Kubernetes, muitas aplicações possuem um Helm chart, que orienta e automatiza esse processo. Mas e se você quiser levar seu cluster Kubernetes "como ele é" e implantá-lo em outro lugar?
Gravity
pode replicar o cluster em qualquer lugar onde o Kubernetes possa funcionar. .tar, pode replicar o cluster em qualquer lugar onde o Kubernetes possa operar.
Gravity também verifica se a infraestrutura de destino se comporta da mesma forma que a original, e se o ambiente Kubernetes no destino está disponível. A versão paga do Gravity também adiciona recursos de segurança, incluindo RBAC e a capacidade de sincronizar configurações de segurança entre diferentes implantações de clusters.
A última versão principal, Gravity 7, pode implantar uma imagem do Gravity em um cluster Kubernetes existente, em vez de criar um novo cluster a partir da imagem. O Gravity 7 também pode funcionar com clusters instalados sem o uso da imagem Gravity. Além disso, o Gravity suporta SELinux e opera nativamente com o gateway Teleport SSH.
Kaniko: Construção de contêineres em um cluster Kubernetes
A maioria das imagens de contêineres é construída em sistemas fora da pilha de contêineres. No entanto, às vezes é necessário construir uma imagem dentro da pilha de contêineres, por exemplo, em um contêiner em execução ou em um cluster Kubernetes.
realiza a construção de contêineres dentro de um ambiente de contêiner, mas sem depender do serviço de contêinerização, como o Docker. Em vez disso, o Kaniko extrai o sistema de arquivos da imagem base, executa todos os comandos de construção no espaço do usuário sobre o sistema de arquivos extraído, registrando o sistema de arquivos após cada comando.
Nota: O Kaniko no momento (maio de 2020, Nota do tradutor) não pode construir contêineres Windows.
Kubecost: Opções de custo para executar Kubernetes
A maioria das ferramentas de administração do Kubernetes é voltada para facilidade de uso, monitoramento, compreensão do comportamento dentro do pod, etc. Mas e quanto à observação do custo — em reais e centavos — associado à execução do Kubernetes?
processa opções do Kubernetes em tempo real, resultando no recebimento de informações sobre o custo atual dos clusters em execução nos principais provedores de nuvem, exibido em um painel com o custo mensal de cada cluster. Os preços de memória RAM, tempo de CPU, GPU e subsistema de disco são detalhados por componentes do Kubernetes (contêiner, pod, serviço, etc.)
O Kubecost também rastreia o custo de recursos externos ao cluster, como buckets do Amazon S3, embora isso esteja limitado à AWS. Os dados de custo podem ser enviados ao Prometheus, permitindo que você os utilize para alterar o comportamento do cluster programaticamente.
O Kubecost é gratuito para uso se você estiver satisfeito com os dados dos logs por 15 dias. Para recursos adicionais, os preços começam em 199$ mensais para monitoramento de 50 nós.
KubeDB: Executando bancos de dados em produção no Kubernetes
É bastante desafiador executar bancos de dados de forma eficaz no Kubernetes. Você encontrará operadores do Kubernetes para MySQL, PostgreSQL, MongoDB e Redis, mas todos eles têm desvantagens. Além disso, o conjunto padrão de funcionalidades do Kubernetes não permite resolver diretamente a maioria dos problemas específicos de bancos de dados.
ajuda você a criar seus próprios operadores do Kubernetes para gerenciar bancos de dados. Execução de backups, clonagem, monitoramento, criação de snapshots e a criação declarativa de bancos são seus componentes. Observe que o suporte a funcionalidades depende do banco de dados. Por exemplo, a criação de clusters funciona para PostgreSQL, mas não para MySQL ( tem, como bem observado , Nota do tradutor).
Kube-monkey: Chaos Monkey para Kubernetes
A maneira mais infalível de testar estresse é através de falhas aleatórias. Essa teoria é a base do Chaos Monkey da Netflix, uma ferramenta de engenharia caótica que desliga aleatoriamente máquinas virtuais e contêineres em um ambiente de produção para "estimular" os desenvolvedores a criar sistemas mais resilientes. é a implementação da mesma teoria básica de teste de estresse para clusters Kubernetes. Ele funciona matando aleatoriamente módulos no cluster que você designa, e pode ser configurado para operar em um intervalo de tempo específico.
Controlador Ingress do Kubernetes para AWS
Kubernetes fornece um balanceador de carga externo e serviços de rede de cluster através de um serviço chamado A AWS fornece recursos de balanceamento de carga, mas não os vincula automaticamente a capacidades semelhantes do Kubernetes. fecha essa lacuna.
Ele gerencia automaticamente os recursos da AWS para cada objeto ingress no cluster, criando balanceadores de carga para novos recursos ingress e removendo balanceadores ao eliminar recursos. Utiliza o CloudFormation para garantir que o estado do cluster permaneça consistente. Também suporta configurações de alerta do CloudWatch e gerencia automaticamente outros elementos utilizados no cluster, como certificados SSL e Grupos de Auto Scaling EC2.
Kubespray: Instalação automática do Kubernetes
automatiza a instalação de um cluster Kubernetes pronto para uso industrial, começando com a instalação em servidores físicos e terminando nos principais clouds públicos. Ele usa Ansible (Vagrant — opcional) para iniciar a implantação e criar um cluster de alta disponibilidade do zero com o complemento de rede escolhido (por exemplo, Flannel, Calico e outros) na distribuição Linux popular que você escolher ao instalar em servidores físicos.
Skaffold: Desenvolvimento Iterativo para Kubernetes
— uma das ferramentas do Google, utilizada para organizar CD de aplicativos no Kubernetes. Assim que você faz alterações no código-fonte, o skaffold as detecta automaticamente, inicia a construção e a implantação, alertando você se houver algum erro. O Skaffold é executado completamente do lado do cliente, portanto, pode haver algumas particularidades na instalação ou atualização. Ele pode ser usado com pipelines CICD existentes, bem como interagir com algumas ferramentas de construção externas, principalmente o Bazel do Google.
Teresa: PaaS mais simples no Kubernetes
é um sistema de implantação de aplicativos que executa o PaaS mais simples sobre o Kubernetes. Usuários divididos em equipes podem implantar e gerenciar seus aplicativos. Isso simplifica um pouco o trabalho para as pessoas que confiam nesse aplicativo e não desejam lidar com Kubernetes e todas as suas complexidades.
Tilt: Distribuição de atualizações de contêineres em clusters Kubernetes
, desenvolvido pela Windmill Engineering, monitora alterações em vários arquivos Dockerfile e, em seguida, implanta gradualmente os contêineres correspondentes no cluster Kubernetes. Essencialmente, ele permite que você atualize um cluster de produção em tempo real simplesmente atualizando os arquivos Dockerfile. O Tilt executa a construção dentro do cluster, e o código-fonte é tudo que precisa ser alterado. Você também pode fazer uma captura do estado do cluster e registrar as condições que ativam erros diretamente do Tilt para compartilhá-las com os membros da equipe para depuração.
P.S. Todas essas ferramentas já testamos com nossas mãos curiosas. Para apresentar práticas reais já (espero!) em intensivos off-line em fevereiro. 8–10 de fevereiro de 2021. E 8–10 de fevereiro de 2021. E 12 a 14 de fevereiro. Honestamente, também sentimos falta da atmosfera calorosa e energicamente carregada do aprendizado presencial. Por mais avançadas que sejam as tecnologias, elas não substituem o contato humano e aquela atmosfera especial que surge quando pessoas com interesses semelhantes se reúnem.
Fonte: habr.com
