Nota do tradutor.: Autor do material original — Henning Jacobs da Zalando. Ele criou uma nova interface web para trabalhar com Kubernetes, que é posicionada como «kubectl para a web». Por que o novo projeto Open Source surgiu e quais critérios não foram atendidos pelas soluções já existentes — leia em seu artigo.
Nesta publicação, analiso várias interfaces web de Kubernetes com código aberto, apresento minhas exigências para uma UI universal e explico por que desenvolvi — uma interface destinada a facilitar o suporte e a resolução de problemas em múltiplos clusters ao mesmo tempo.
Casos de uso
Na Zalando, atendemos a um grande número de usuários do Kubernetes (mais de 900) e clusters (mais de 100). Existem alguns casos típicos de uso onde uma ferramenta web especializada seria muito útil:
- comunicação com colegas durante o suporte;
- resposta a incidentes e investigação de suas causas.
Suporte
Na minha experiência, a comunicação durante o suporte muitas vezes acontece da seguinte maneira:
— Ajude-me, nosso serviço XYZ está indisponível!
— O que você vê ao executar kubectl describe ingress ...?
Ou algo semelhante para CRD:
— Estou com algum problema com o serviço de autenticação...
— O que a equipe retorna quando utiliza kubectl describe platformcredentialsset ...?
Esse tipo de comunicação geralmente se resume a inserir várias variações do comando kubectl para tentar identificar o problema. Como resultado, ambas as partes da conversa são forçadas a ficar alternando entre o terminal e o chat web, além de presenciar situações diferentes.
Portanto, gostaria que o frontend web do Kubernetes permitisse o seguinte:
- que os usuários pudessem trocar links e visualizar a mesma coisa;
- ajudasse a evitar erros humanos no suporte: por exemplo, entrar no cluster errado no terminal, erros de digitação nos comandos da CLI, etc.;
- permitisse gerar views personalizadas para enviar a colegas, ou seja, adicionar colunas de rótulos, exibir múltiplos tipos de recursos em uma única página;
- idealmente, essa ferramenta web deveria permitir criar links "profundos" para seções específicas do YAML (por exemplo, indicar um parâmetro errado que está causando falhas).
Resposta a incidentes e análise
A reação a incidentes na infraestrutura requer consciência situacional, capacidade de avaliar impactos e a busca por padrões em clusters. Alguns exemplos da vida real:
- um serviço de produção crítico está enfrentando problemas e você precisa encontrar todos os recursos Kubernetes pelo nome em todos os clusters, para solucionar as falhas;
- os nós começam a falhar durante a escalabilidade, e você precisa encontrar todos os pods com o status 'Pending' em todos os clusters, para avaliar a extensão do problema;
- usuários individuais relatam um problema com um DaemonSet implantado em todos os clusters, e é necessário descobrir se o problema é de caráter abrangente..
Minha solução padrão nesses casos é algo como for i in $clusters; do kubectl ...; done. É evidente que pode-se desenvolver uma ferramenta que forneça capacidades semelhantes.
As interfaces web existentes do Kubernetes
O mundo Open Source de interfaces web para Kubernetes não é muito grande*, então eu tentei coletar informações adicionais através de :
* Minha explicação para o número limitado de interfaces web para Kubernetes: serviços em nuvem e fornecedores de Kubernetes geralmente oferecem seus próprios front-ends, portanto, o mercado para 'boas' interfaces Kubernetes gratuitas é relativamente pequeno.
Com um tweet eu fiquei sabendo de , e . Vamos dar uma olhada neles e em outras soluções Open Source existentes, tentando entender o que eles representam.
K8Dash
"K8Dash é a maneira mais simples de gerenciar um cluster Kubernetes."
parece bom e tem um desempenho rápido, mas possui várias desvantagens para os cenários de uso mencionados:
- Funciona somente dentro de um único cluster.
- Classificação e filtragem são possíveis, mas não têm links permanentes.
- Falta suporte a Custom Resource Definitions (CRDs).
Kubernator
"Kubernator é uma interface alternativa para Kubernetes. Ao contrário do painel de alto nível do Kubernetes Dashboard, ele proporciona controle de baixo nível e uma excelente visão de todos os objetos no cluster, permitindo a criação de novos, edição deles e resolução de conflitos. Sendo uma aplicação totalmente cliente (como kubectl), não requer backend além do próprio servidor API do Kubernetes, e também considera as regras de acesso ao cluster."
É uma descrição bastante precisa Infelizmente, ele carece de algumas funcionalidades:
- Gerencia somente um cluster.
- Não há modo de visualização em lista (ou seja, não é possível exibir todos os pods com status "Pending").
Kubernetes Dashboard
"O Kubernetes Dashboard é uma interface web universal para clusters Kubernetes. Ele permite aos usuários gerenciar aplicativos em execução no cluster e solucionar problemas, assim como gerenciar o próprio cluster."
Infelizmente, isso não ajuda muito nas minhas atividades de suporte e resposta a incidentes, porque ele:
- não possui links permanentes, por exemplo, quando filtro recursos ou mudo a ordem de classificação;
- não há uma forma fácil de filtrar por status — por exemplo, ver todos os pods com status "Pending";
- suporta apenas um cluster;
- não suporta CRD (essa função está em desenvolvimento);
- não há colunas personalizadas (por exemplo, colunas com rótulos como
kubectl -L).
Kubernetes Operational View (kube-ops-view)
"Uma painel de monitoramento para espaços de clusters K8s."
Na tem uma abordagem completamente diferente: esta ferramenta apenas exibe os nós do cluster e os pods usando WebGL, sem detalhes textuais dos objetos. É excelente para uma visão operacional do estado do cluster ("os pods estão caindo?")*, mas não é adequada para os casos de uso descritos acima em suporte e resposta a incidentes.
* Nota do tradutor.: Nesse sentido, você também pode se interessar pelo nosso plugin , que discutimos mais detalhadamente em .
Kubernetes Resource Report (kube-resource-report)
"Coletar informações sobre as solicitações de recursos dos pods e do cluster Kubernetes, compará-las com o uso de recursos e gerar HTML estático."
gera relatórios HTML estáticos sobre o uso de recursos e a distribuição de custos por equipes/aplicativos em clusters. O relatório é em certa medida útil para suporte e resposta a incidentes, pois permite encontrar mais rapidamente o cluster onde o aplicativo está implantado.
Nota do tradutor.: Na visualização das informações sobre a distribuição de recursos e seus custos, pode também ser útil o serviço e ferramenta , cuja visão geral nós .
Octant
"Uma plataforma web extensível para desenvolvedores, destinada a proporcionar uma melhor compreensão da complexidade dos clusters Kubernetes."
, criado no VMware, é um novo produto que conheci recentemente. Com ele, é fácil explorar o cluster na máquina local (inclusive com visualizações), no entanto, ele aborda a questão do suporte e resposta a incidentes apenas de forma limitada. Desvantagens do Octant:
- Não há busca nos clusters.
- Funciona apenas na máquina local (não é implantado no cluster).
- Não é possível classificar/filtrar objetos (apenas o seletor de rótulos é suportado).
- Não é possível definir colunas personalizadas.
- Não é possível exibir a lista de objetos por namespaces.
Eu também tive problemas com a estabilidade do Octant em clusters Zalando: em alguns CRD, .
Apresento o Kubernetes Web View
o 'kubectl para a web'.
Depois de analisar as opções de interfaces disponíveis para Kubernetes, decidi criar uma nova: . Afinal, eu só precisava de todo o poder kubectl na web, ou seja:
- disponibilidade de todas as operações (somente leitura) nas quais os usuários preferem usar o kubectl;
- todos os URLs devem ser permanentes e representar a página na forma original, para que os colegas possam compartilhá-los e usá-los em outras ferramentas;
- suporte a todos os objetos Kubernetes, o que permitirá resolver problemas de qualquer tipo;
- as listas de recursos devem ser baixáveis para trabalho posterior (em planilhas, ferramentas de CLI como
grep) e armazenamento (por exemplo, para análises posteriores); - suporte à filtragem de recursos por rótulos (semelhante a
kubectl get .. -l); - capacidade de criar listas combinadas de diferentes tipos de recursos (semelhante a
kubectl get all) para obter uma visão operacional geral entre os colegas (por exemplo, durante a resposta a incidentes); - capacidade de adicionar 'deep links' personalizáveis e inteligentes a outras ferramentas, como painéis de monitoramento, registradores, repositórios de aplicativos, etc., para facilitar a busca/resolução de erros e a resposta a incidentes;
- o frontend deve ser o mais simples possível (HTML limpo), para evitar problemas acidentais, como JavaScript travado;
- suporte a múltiplos clusters para facilitar a interação durante consultorias remotas (por exemplo, para memorizar apenas uma URL);
- sempre que possível, a análise situacional deve ser facilitada (por exemplo, com links para download de recursos em todos os clusters/namespaces);
- recursos adicionais para a criação de links flexíveis e extração de informações textuais, por exemplo, para que se possa indicar a colegas uma seção específica na descrição do recurso (linha em YAML);
- capacidade de ajuste às necessidades de um cliente específico, como permitir a criação de templates personalizados de exibição para CRD, suas próprias visualizações tabulares, alteração de estilos CSS;
- ferramentas para estudo adicional no terminal (por exemplo, mostrando comandos completos
kubectl, prontos para cópia);
Fora das tarefas abordadas no Kubernetes Web View (não objetivos) permaneceram:
- abstração de objetos do Kubernetes;
- gerenciamento de aplicativos (por exemplo, gerenciamento de deployments, charts do Helm, etc.);
- operações de gravação (devem ser realizadas através de ferramentas seguras de CI/CD e/ou GitOps);
- interface bonita (JavaScript, temas, etc.);
- visualizações (veja );
- análise de custos (veja ).
Como o Kubernetes Web View ajuda na manutenção e resposta a incidentes?
Suporte
- Todos os links são permanentes, facilitando a troca de informações com colegas.
- É possível criar suas próprias visualizações, por exemplo, listar todos os Deployments e Pods com um determinado rótulo em dois clusters específicos (vários nomes de clusters e tipos de recursos podem ser definidos no link, separados por vírgulas).
- É possível referenciar linhas específicas em um arquivo YAML de um objeto, apontando para potenciais problemas na especificação do objeto.
Busca por clusters no Kubernetes Web View
Resposta a incidentes
- Busca global (global search) permite pesquisar objetos em todos os clusters.
- Visualizações em formato de lista podem exibir todos os objetos com um determinado estado/coluna em todos os clusters (por exemplo, precisamos encontrar todos os pods com o status "Pending").
- Listas de objetos podem ser baixadas no formato de valores separados por tabulação (TSV) para análise posterior.
- permitem alternar para painéis de monitoramento correspondentes e outras ferramentas.
Kubernetes Web View: lista de pods com status "Pending" em todos os clusters
Se deseja experimentar o Kubernetes Web View, recomendo conferir ou assistir à .
Claro, a interface poderia ser melhor, mas enquanto isso, o Kubernetes Web View é uma ferramenta para "usuários avançados" que não têm medo de manipular os caminhos de URL manualmente, se necessário. Se você tiver comentários/adicionais/sugestões, por favor, entre em contato !
Este artigo é um breve relato sobre as premissas que levaram à criação do Kubernetes Web View. Outros artigos seguirão! (Nota do tradutor.: Eles devem ser esperados em .)
P.S. do tradutor
Confira também em nosso blog:
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
