HomePtNotíciaComo usar o Datree para evitar erros de configuração do Kubernetes

Como usar o Datree para evitar erros de configuração do Kubernetes

- Advertisement -
- Advertisement -
- Advertisement -
- Advertisement -

[ad_1]

Kubernetes é um sistema complexo com muitas partes móveis. Regras de configuração corretas são essenciais para que seu serviço funcione de forma confiável. Erros podem acontecer quando você escreve manifestos do Kubernetes manualmente sem um processo de revisão completo.

Datree é uma ferramenta baseada em regras que automaticamente encontra problemas em seus manifestos. Você pode usá-lo para descobrir violações de política sem sair do seu endpoint, permitindo uma abordagem consistente para a configuração do Kubernetes.

Neste artigo, você aprenderá a usar o Datree CLI para realizar varreduras de manifesto sob demanda. A ferramenta é gratuita e de código aberto, mas é apoiada por um painel online que permite gerenciar centralmente as políticas compartilhadas por toda a sua equipe. Isso é gratuito para pessoas que fazem interface com até dois nós, enquanto os planos de equipe começam em US$ 95/mês com uma alocação básica de cinco nós.

Instalação do Datree CLI

Primeiro baixe e configure o Datree CLI usando seu script de instalação. Isso funciona em Linux e Mac:

$ curl https://get.datree.io | /bin/bash

Instruções de instalação alternativas estão disponíveis na documentação se você estiver usando o Windows ou quiser executar o Datree como um contêiner do Docker.

Verifique se a CLI está instalada corretamente executando o datree comando sem nenhum argumento:

$ datree
Datree is a static code analysis tool for kubernetes files. Full code can be found at https://github.com/datreeio/datree
...

Agora você pode começar a verificar seus manifestos em busca de erros.

Executando uma verificação de política

Copie o seguinte YAML e salve-o como datree-demo.yaml em seu diretório de trabalho:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-deployment
  namespace: demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      namespace: demo-deployment
      labels:
        app: demo-app
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          readinessProbe:
            tcpSocket:
              port: 8080
          resources:
            requests:
              memory: "256Mi"
              cpu: "100m"
            limits:
              cpu: "500m"
          ports:
            - containerPort: 80

Este YAML define um objeto de implementação válido do Kubernetes. O Kubectl o aplicará ao seu cluster sem relatar nenhum erro:

$ kubectl apply -f datree-demo.yaml
deployment/demo-deployment created

No entanto, pode haver problemas com essa configuração. A execução do Datree CLI irá expô-los. Use o datree test comando para completar uma varredura do seu manifesto:

$ datree test datree-demo.yaml
>> File: datree-demo.yaml

[V] YAML validation
[V] Kubernetes schema validation

[X] Policy check

❌  Ensure each container image has a pinned (tag) version  [1 occurrence]
    - metadata.name: demo-deployment (kind: Deployment)
💡  Incorrect value for key `image` - specify an image version to avoid unpleasant "version surprises" in the future

❌  Ensure each container has a configured liveness probe  [1 occurrence]
    - metadata.name: demo-deployment (kind: Deployment)
💡  Missing property object `livenessProbe` - add a properly configured livenessProbe to catch possible deadlocks

❌  Ensure each container has a configured memory limit  [1 occurrence]
    - metadata.name: demo-deployment (kind: Deployment)
💡  Missing property object `limits.memory` - value should be within the accepted boundaries recommended by the organization

(Summary)

- Passing YAML validation: 1/1

- Passing Kubernetes (1.20.0) schema validation: 1/1

- Passing policy check: 0/1

+-----------------------------------+-----+
| Enabled rules in policy "Default" | 21  |
| Configs tested against policy     | 1   |
| Total rules evaluated             | 21  |
| Total rules skipped               | 0   |
| Total rules failed                | 3   |
| Total rules passed                | 18  |
+-----------------------------------+-----+

A Datree descobriu três violações de política que podem afetar seu cluster.

Interpretação dos resultados da verificação

As varreduras do Datree analisam três aspectos de cada manifesto:

  • Validação YAML – A primeira verificação valida a exatidão do seu YAML. Nenhuma verificação adicional será executada se o arquivo YAML tiver erros de sintaxe.
  • Validação de esquema do Kubernetes – Verifica se o manifesto contém um objeto legal do Kubernetes. As causas comuns desses erros incluem valores de campo inválidos e aninhamento incorreto de objetos.
  • Verificações de política – É aqui que o Datree testa um esquema de objeto Kubernetes válido em relação a configurações incorretas comuns. As políticas identificam possíveis problemas e otimizações ausentes para que você possa tornar seu cluster Kubernetes mais resiliente.

Cada relatório termina com uma tabela que resume o número de manifestos analisados, as regras utilizadas e os erros detectados.

Correções para erros de manifesto de amostra

Ao verificar o manifesto de amostra, recebo três erros: o contêiner image o campo não está usando uma marca âncora, não há livenessProbee sem limite de memória.

O primeiro problema pode ser resolvido usando uma versão de imagem explícita como nginx:1.23. A tag mais recente é arriscada porque pode receber grandes alterações inadvertidamente, como 1.23 uma 2.1.

O erro a seguir pode ser removido adicionando uma sonda de atividade. Isso permite que o Kubernetes detecte quando seus contêineres entram em um estado de falha. O plano de controle reiniciará automaticamente o contêiner, reduzindo a chance de interrupção do serviço.

Adicionar um novo livenessProbe campo acima do readinessProbe:

livenessProbe:
  tcpSocket:
    port: 8080

Por fim, defina um limite de memória para endereçar o último aviso. Embora o manifesto de exemplo inclua solicitações de CPU e memória, bem como um limite de CPU, não há limite rígido de memória. O contêiner pode consumir RAM ilimitada, o que pode criar uma situação de falta de memória em seu cluster.

O YAML revisado deve ficar assim:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-deployment
  namespace: demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      namespace: demo-deployment
      labels:
        app: demo-app
    spec:
      containers:
        - name: nginx
          image: nginx:1.23  
          livenessProbe:
            tcpSocket:
              port: 8080
          readinessProbe:
            tcpSocket:
              port: 8080
          resources:
            requests:
              memory: "256Mi"
              cpu: "100m"
            limits:
              memory: "512Mi"
              cpu: "500m"
          ports:
            - containerPort: 80

Repita o datree test Comando para verificar se sua implementação agora está passando nas verificações de política:

$ datree test datree-demo.yaml
(Summary)

- Passing YAML validation: 1/1

- Passing Kubernetes (1.20.0) schema validation: 1/1

- Passing policy check: 1/1

Regras de personalização

O exemplo usado até agora é baseado no conjunto integrado de políticas padrão do Datree. Eles abrangem muitas práticas recomendadas do Kubernetes, como configurar probes, usar limites de recursos e evitar APIs obsoletas.

Você pode personalizar as políticas vinculando o Datree CLI ao seu painel de controle online. Aqui você pode desabilitar políticas desnecessárias e habilitar novas regras personalizadas para implementar as rotinas da sua organização.

A maneira mais fácil de fazer login no Datree é seguir o link mostrado na parte inferior da saída da CLI do Datree:

| See all rules in policy           | https://app.datree.io/login?t=bbY... |

A CLI gera automaticamente um token exclusivo para sua conta. Clique no link e entre no Datree com GitHub ou Google.

Imagem da tela da política da Datree

Você será levado ao painel Políticas que exibe todas as políticas ativas em sua conta. Clique nos botões de alternância na coluna “Status” para ativar ou remover políticas. Suas alterações serão aplicadas imediatamente a novas verificações. A CLI baixa automaticamente sua lista de políticas antes de iniciar cada teste.

Imagem da tela do histórico do Datree

O painel também fornece um histórico das verificações que você concluiu. Clique na guia “Histórico” na barra lateral esquerda para recuperar os resultados da verificação anterior.

Digitalize com uma política específica

Atualmente, o Datree possui 60 regras internas que fornecem testes individuais. As regras são combinadas em grupos chamados políticas. A política padrão é usada automaticamente. Habilita 21 das 60 regras. Datree também vem com políticas pré-configuradas para configurações Argo e NSA Kubernetes.

Você pode criar sua própria política usando o botão azul “Criar política” no painel de controle online. Dê um nome à sua política e ative uma ou mais regras.

Para iniciar uma verificação com uma política específica, adicione o --policy Sinalizador CLI. Isso deve fornecer o nome da política que você deseja usar.

$ datree test --policy NSA datree-demo.yaml

O Datree também permite que você implemente testes personalizados adicionando regras totalmente novas. Embora a criação de regras esteja fora do escopo deste guia de introdução, você pode exigir que as implementações tenham rótulos específicos, uma contagem mínima de réplicas e usem imagens de um registro aprovado. As regras são definidas como JSON ou YAML usando a lógica do esquema JSON.

Verificação de vários arquivos

a datree test O comando aceita um caminho de arquivo ou padrão global. Você pode verificar um diretório em busca de manifestos usando a seguinte sintaxe:

datree test demo-dir/*.yaml

Qualquer arquivo inválido que corresponda ao seu glob aparecerá como falha na verificação de validação do Datree YAML.

Autenticação de outras instâncias da CLI

A CLI da Datree se conecta à sua conta usando um token de autenticação. Um novo token é gerado automaticamente quando você instala a CLI. Configure uma nova conta na primeira vez que for usada.

Você precisará fornecer manualmente seu token de autenticação existente se instalar o Datree em outra máquina. Você pode recuperar o valor do token campo em seu ~/.datree/config.yaml procedimentos. Como alternativa, acesse seu painel online, clique na sua foto de perfil no canto superior direito, escolha Configurações no menu e mude para a guia “Gerenciamento de tokens”.

Imagem da tela de gerenciamento do token Datree

De volta à sua nova instância da CLI, use o seguinte comando para adicionar seu token:

$ datree config set token <TOKEN_VALUE>

A CLI agora usará as políticas configuradas em sua conta. As verificações também começarão a aparecer na tela Histórico.

Usando o Datree sem acesso à conta

Você pode desabilitar os recursos de conexão da conta Datree CLI se estiver satisfeito com o conjunto padrão de regras e não quiser que as varreduras se comuniquem com os servidores Datree:

$ datree config set offline local

Isso também remove o suporte para validação de esquema do Kubernetes.

Você pode impedir que verificações individuais apareçam na página Histórico de sua conta configurando o --no-record sinalizador na CLI.

$ datree test datree-demo.yaml --no-record

Resumo

A Datree automatiza a detecção de configuração incorreta do Kubernetes oferecendo uma CLI simples que é configurada centralmente por meio de um painel online. Isso garante que todos em sua equipe testem seus manifestos em relação às mesmas políticas, reduzindo o risco de bugs atingirem seu cluster. Você pode integrar o Datree em seus pipelines de CI para evitar a implantação de alterações que contenham uma violação de regra.

O Datree também está disponível como um webhook de suporte do Kubernetes que bloqueará ativamente recursos não compatíveis. Os webhooks de admissão são responsáveis ​​por decidir se novos objetos podem ser adicionados a um cluster; A Datree rejeitará qualquer item que falhe em seus testes de política. A configuração do webhook fornece confiança absoluta de que recursos configurados incorretamente não podem ser usados, mesmo que um usuário aplique manualmente um manifesto com Kubectl.

[ad_2]

- Advertisement -
- Advertisement -
Stay Connected
16,985FansLike
2,458FollowersFollow
61,453SubscribersSubscribe
Must Read
- Advertisement -
Related News
- Advertisement -