Nota perev. : O autor do material original é Henning Jacobs de Zalando. Ele criou uma nova interface da web para trabalhar com o Kubernetes, posicionada como "kubectl for the web". Por que o novo projeto Open Source apareceu e quais critérios as soluções existentes não atendiam, leia o artigo
Nesta publicação, analiso as várias interfaces da web de código aberto do Kubernetes, apresento meus requisitos para uma interface de usuário universal e explico por que desenvolvi o
Kubernetes Web View , uma interface projetada para facilitar o suporte e a solução de problemas de vários clusters de uma só vez.
Casos de uso
No Zalando, atendemos um grande número de usuários do Kubernetes (mais de 900) e de cluster (mais de 100). Existem alguns casos de uso típicos em que a ajuda de uma ferramenta da web especializada seria muito útil:
- comunicação com colegas de apoio;
- resposta a incidentes e investigação de suas causas.
Suporte
Na minha experiência, a comunicação em uma estrutura de suporte geralmente se parece com isso:
- Ajuda, nosso serviço XYZ está indisponível!
- O que você vê quando executa o kubectl describe ingress ... ?Ou algo semelhante para CRD:
- Eu tenho algum tipo de problema com o serviço de identificação ...
- E o kubectl describe platformcredentialsset ... comando kubectl describe platformcredentialsset ... ?Essa comunicação geralmente se resume à introdução de várias variações do
kubectl para corrigir o problema. Como resultado, os dois lados da conversa são forçados a alternar constantemente entre o terminal e o bate-papo na web, além de observar uma situação diferente.
Portanto, quero que o front-end da web do Kubernetes permita o seguinte:
- os usuários podiam trocar links e observar a mesma coisa;
- Ajudaria a evitar erros humanos no suporte: por exemplo, inserir o cluster errado na linha de comandos, erros de digitação nos comandos da CLI etc.
- permitiria gerar suas próprias visualizações para enviar aos colegas, ou seja, adicionar colunas de rótulos, exibir muitos tipos de recursos em uma página;
- Idealmente, essa ferramenta baseada na Web deve permitir que você coloque links diretos para seções específicas do YAML (por exemplo, aponte para um parâmetro inválido que causa falhas).
Resposta e análise de incidentes
Responder a incidentes em infraestrutura requer consciência situacional, capacidade de avaliar o impacto e procurar padrões em clusters. Alguns exemplos da vida real:
- o serviço crítico de produção tem problemas e você precisa encontrar todos os recursos do Kubernetes por nome em todos os clusters para corrigir os problemas;
- os nós começam a cair durante o dimensionamento e é necessário encontrar todos os pods com o status "Pendente" em todos os clusters para avaliar a magnitude do problema;
- usuários individuais relatam um problema com o DaemonSet implantado em todos os clusters e é necessário descobrir se o problema é total .
Minha solução padrão nesses casos é algo como
for i in $clusters; do kubectl ...; done for i in $clusters; do kubectl ...; done for i in $clusters; do kubectl ...; done . Obviamente, você pode desenvolver uma ferramenta que fornece recursos semelhantes.
Interfaces da Web Kubernetes existentes
O mundo de código aberto das interfaces da web do Kubernetes não é muito grande *, então tentei coletar informações adicionais usando o
Twitter :
* Minha explicação do número limitado de interfaces da web para o Kubernetes: serviços e fornecedores em nuvem O Kubernetes geralmente oferece seus próprios front-ends, portanto, o mercado para a "boa" interface do usuário gratuita do Kubernetes é relativamente pequeno.Eu
twittou sobre
K8Dash ,
Kubernator e
Octant . Vamos dar uma olhada neles e em outras soluções Open Source existentes, tentar entender o que são.
K8Dash
“O K8Dash é a maneira mais fácil de gerenciar seu cluster Kubernetes.”
O K8Dash parece bem e parece rápido, mas possui várias desvantagens para os
casos de uso listados acima:
- Funciona apenas dentro dos limites de um cluster.
- A classificação e a filtragem são possíveis, mas não têm links permanentes.
- Não há suporte para definições de recursos personalizados (CRDs).
Kubernator
“O Kubernator é uma interface alternativa para o Kubernetes. Ao contrário do Painel de alto nível do Kubernetes, ele fornece controle de baixo nível e uma excelente visão geral de todos os objetos no cluster, com a capacidade de criar novos, editá-los e resolver conflitos. Por ser um aplicativo totalmente cliente (como o kubectl), ele não requer nenhum back-end, exceto o próprio servidor da API Kubernetes, e também leva em consideração as regras para acessar o cluster ".
Esta é uma descrição bastante precisa do
Kubernator . Infelizmente, ele não possui alguns recursos:
- Serve apenas um cluster.
- Não há modo de exibição de lista (ou seja, você não pode exibir todos os pods com o status "Pendente").
Painel Kubernetes
“O Kubernetes Dashboard é uma interface da Web universal para clusters Kubernetes. Ele permite aos usuários gerenciar e solucionar problemas de aplicativos em execução no cluster, além de gerenciar o próprio cluster. ”
Infelizmente, o
Kubernetes Dashboard não ajuda muito em minhas atividades de suporte e resposta a incidentes, porque:
- Não há links permanentes, por exemplo, quando eu filtrar recursos ou alterar a ordem de classificação;
- não há uma maneira fácil de filtrar por status - por exemplo, veja todos os pods com o status "Pendente";
- apenas um cluster é suportado;
- CRD não são suportados (esta função está em desenvolvimento);
- nenhuma coluna personalizada (por exemplo,
kubectl -L ).
Visão Operacional do Kubernetes (visão de operação do kube)
“Painel do sistema K8s Cluster Space Observer.”
O Kubernetes Operational View tem uma abordagem completamente diferente: essa ferramenta mostra apenas nós e pods de cluster usando o WebGL, sem nenhum detalhe textual dos objetos. É ótimo para uma visão geral on-line do status do cluster (“os pods caem?”) *, Mas não para os casos de uso descritos acima no suporte e resposta a incidentes.
* Nota perev. : Nesse sentido, você também pode estar interessado em nosso plugin grafana-statusmap , que abordamos em mais detalhes neste artigo .Relatório de Recursos do Kubernetes (kube-resource-report)
"Reúna informações sobre solicitações de recursos de pods e clusters Kubernetes, compare-as com o consumo de recursos e gere HTML estático."
O Relatório de Recursos do Kubernetes 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 é um pouco útil para dar suporte e responder a incidentes, pois permite encontrar rapidamente o cluster no qual o aplicativo está implantado.
Nota perev. : Ao exibir informações sobre a distribuição de recursos e seus custos de provedores de nuvem, o serviço e a ferramenta Kubecost , publicados recentemente, também podem ser úteis.Octante
“Uma plataforma extensível de desenvolvimento da web projetada para fornecer uma melhor compreensão da complexidade do cluster Kubernetes.”
O Octant , criado no VMware, é um novo produto que eu aprendi há relativamente pouco tempo. Ao usá-lo, é conveniente examinar o cluster em uma máquina local (existem até visualizações); no entanto, ele aborda apenas os problemas de suporte e resposta a incidentes de forma limitada. Desvantagens dos octantes:
- Nenhuma pesquisa de cluster.
- Funciona apenas na máquina local (não implantada no cluster).
- Não foi possível classificar / filtrar objetos (apenas o seletor de etiquetas é suportado).
- Você não pode especificar colunas personalizadas.
- Você não pode listar objetos por espaço para nome.
Eu também tive problemas de estabilidade com os clusters Zalando da Octant: ele travou em alguns CRDs.
Apresentando o Kubernetes Web View
"Kubectl para a web."
Após analisar as opções de interface disponíveis para o Kubernetes, decidi criar uma nova: o
Kubernetes Web View . Na verdade, eu só preciso de todo o poder do
kubectl na Web, a saber:
- acessibilidade de todas as operações (somente leitura) nas quais os usuários preferem usar o kubectl;
- Todos os URLs devem ser permanentes e apresentar a página em sua forma original, para que os colegas possam compartilhá-los e usá-los em outras ferramentas;
- suporte para todos os objetos Kubernetes, que resolverão o problema de qualquer tipo;
- as listas de recursos devem estar disponíveis para download para trabalho adicional (em planilhas, ferramentas CLI como
grep ) e armazenamento (por exemplo, para post-mortem); - suporte para selecionar recursos por etiquetas (semelhante ao
kubectl get .. -l ); - a capacidade de criar listas combinadas de vários tipos de recursos (semelhante ao
kubectl get all ) para obter uma imagem operacional comum entre os colegas (por exemplo, no processo de resposta a um incidente); - a capacidade de adicionar links diretos “inteligentes” personalizáveis a outras ferramentas, como painéis, registradores, registros de aplicativos etc. facilitar a solução de problemas / resposta a incidentes;
- o front-end deve ser o mais simples possível (HTML puro) para evitar problemas acidentais, por exemplo, JavaScript congelado;
- suporte a vários clusters para facilitar a interação durante consultoria remota (por exemplo, para lembrar apenas um URL);
- se possível, a análise situacional deve ser simplificada (por exemplo, com links para o download de recursos para todos os clusters / namespaces);
- oportunidades adicionais para criar links flexíveis e destacar informações textuais, por exemplo, para que os colegas possam apontar para uma seção específica na descrição do recurso (linha no YAML);
- a capacidade de se adaptar aos requisitos de um cliente específico, por exemplo, permitindo criar modelos de exibição especiais para CRD, suas visualizações de tabela, alterar estilos CSS;
- ferramentas para estudos adicionais na linha de comando (por exemplo, mostrando comandos completos do
kubectl prontos para cópia);
Fora das
não-metas resolvidas pelo Kubernetes Web View, existem:
- abstraindo objetos Kubernetes;
- gerenciamento de aplicativos (por exemplo, gerenciamento de implantação, gráficos Helm, etc.);
- operações de gravação (devem ser feitas por meio de ferramentas seguras de CI / CD e / ou GitOps);
- interface bonita (JavaScript, temas, etc.);
- visualizações (veja kube-ops-view );
- análise de custo (consulte kube-resource-report ).
Como o Kubernetes Web View ajuda no suporte e na resposta a incidentes?
Suporte
- Todos os links são permanentes , o que facilita a troca de informações com os colegas.
- Você pode criar suas próprias visualizações , por exemplo, exibir todas as implantações e pods com um rótulo específico em dois clusters específicos (vários nomes de clusters e tipos de recursos podem ser especificados no link, separados por vírgulas).
- Você pode fazer referência a linhas específicas no arquivo YAML do objeto, indicando possíveis problemas na especificação do objeto.
Pesquisa de cluster no Kubernetes Web ViewResposta a incidentes
- A pesquisa global permite pesquisar objetos em todos os clusters.
- As visualizações 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 "Pendente").
- As listas de objetos podem ser baixadas no formato formato delimitado por tabulação (TSV) para análise posterior.
- Links externos personalizáveis permitem alternar para os painéis correspondentes e outras ferramentas.
Kubernetes Web View: uma lista de pods com status Pendente em todos os clustersSe você quiser experimentar o Kubernetes Web View, recomendo que você se familiarize com a
documentação ou consulte a
versão demo ao vivo .
Obviamente, a interface poderia ser melhor, mas por enquanto o Kubernetes Web View é uma ferramenta para "usuários avançados" que não evitam manipular manualmente os caminhos da URL, se necessário. Se você tiver comentários / adições / desejos, entre em contato
comigo no Twitter !
Este artigo é uma breve descrição das premissas que levaram à criação do Kubernetes Web View. Outros seguirão!
( Nota : eles devem ser esperados no blog do autor .)PS do tradutor
Leia também em nosso blog: