Integração com o Kubernetes Dashboard e GitLab

O Kubernetes Dashboard é uma ferramenta fácil de usar para obter informações atualizadas sobre um cluster em funcionamento e controle mínimo sobre ele. Você começa a apreciar ainda mais quando o acesso a esses recursos é necessário não apenas pelos administradores / engenheiros do DevOps, mas também pelos que estão menos acostumados ao console e / ou não pretendem lidar com todos os meandros da interação com o kubectl e outros utilitários. Foi o que aconteceu conosco: os desenvolvedores queriam acesso rápido à interface da web do Kubernetes e, como usamos o GitLab, a solução veio naturalmente.

Por que isso?

Os desenvolvedores diretos podem estar interessados ​​em uma ferramenta como o K8s Dashboard para tarefas de depuração. Às vezes, você deseja exibir logs e recursos, às vezes, mata pods, dimensiona Deployments / StatefulSets e até entra no console do contêiner (também existem solicitações para as quais existe outra maneira, por exemplo, através do kubectl-debug ).

Além disso, há um momento psicológico para os gerentes quando eles querem olhar para o cluster - ver que "tudo é verde" e, assim, acalmar que "tudo funciona" (que, é claro, é muito relativo ... mas isso está além do escopo do artigo )

Usamos o GitLab como um sistema de IC padrão: todos os desenvolvedores o usam. Portanto, para dar acesso, era lógico integrar o Dashboard às contas no GitLab.

Observe também que estamos usando o NGINX Ingress. Se você trabalha com outras soluções de ingresso , precisará localizar de forma independente análogos de anotações para autorização.

Tentamos integração

Instalar painel

Atenção : Se você deseja repetir as etapas descritas abaixo, primeiro - para evitar operações desnecessárias - leia primeiro a próxima legenda.

Como usamos essa integração em muitas instalações, automatizamos sua instalação. As fontes necessárias para isso são publicadas em um repositório especial do GitHub . Eles são baseados em configurações YAML levemente modificadas do repositório oficial do Dashboard , bem como em um script Bash para implantação rápida.

O script instala o Dashboard em um cluster e o configura para integrar-se ao GitLab:

$ ./ctl.sh Usage: ctl.sh [OPTION]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL Install kubernetes-dashboard to Kubernetes cluster. Mandatory arguments: -i, --install install into 'kube-system' namespace -u, --upgrade upgrade existing installation, will reuse password and host names -d, --delete remove everything, including the namespace --gitlab-url set gitlab url with schema (https://gitlab.example.com) --oauth2-id set OAUTH2_PROXY_CLIENT_ID from gitlab --oauth2-secret set OAUTH2_PROXY_CLIENT_SECRET from gitlab --dashboard-url set dashboard url without schema (dashboard.example.com) Optional arguments: -h, --help output this message 

No entanto, antes de usá-lo, você precisa ir para o GitLab: Área administrativa → Aplicativos - e adicionar um novo aplicativo para o painel futuro. Vamos chamá-lo de "painel kubernetes":



Como resultado de sua adição, o GitLab fornecerá hashes:



Eles são usados ​​como argumentos para o script. Como resultado, a instalação é a seguinte:

 $ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.com 

Depois disso, verifique se tudo começou:

 $ kubectl -n kube-system get pod | egrep '(dash|oauth)' kubernetes-dashboard-76b55bc9f8-xpncp 1/1 Running 0 14s oauth2-proxy-5586ccf95c-czp2v 1/1 Running 0 14s 

Cedo ou tarde tudo começará, mas a autorização não funcionará imediatamente ! O fato é que, na imagem usada (a situação em outras imagens é semelhante), o processo de captura de redirecionamento no retorno de chamada é implementado incorretamente. Essa circunstância leva ao fato de que oauth apaga o cookie, que ele próprio (oauth) nos fornece ...

O problema é resolvido construindo sua imagem oauth com o patch.

Patch para oauth e reinstalar

Para fazer isso, use o seguinte Dockerfile:

 FROM golang:1.9-alpine3.7 WORKDIR /go/src/github.com/bitly/oauth2_proxy RUN apk --update add make git build-base curl bash ca-certificates wget \ && update-ca-certificates \ && go get -u github.com/golang/dep/cmd/dep \ && curl -sSO https://raw.githubusercontent.com/pote/gpm/v1.4.0/bin/gpm \ && chmod +x gpm \ && mv gpm /usr/local/bin RUN git clone https://github.com/bitly/oauth2_proxy.git . \ && git checkout fa2771998a98a5bfdfa3c3503757668ac4f1c8ec ADD rd.patch . RUN patch -p1 < rd.patch && ./dist.sh FROM alpine:3.7 RUN apk --update add curl bash ca-certificates && update-ca-certificates COPY --from=0 /go/src/github.com/bitly/oauth2_proxy/dist/ /bin/ EXPOSE 8080 4180 ENTRYPOINT [ "/bin/oauth2_proxy" ] CMD [ "--upstream=http://0.0.0.0:8080/", "--http-address=0.0.0.0:4180" ] 

Agora você pode criar a imagem e enviá-la para o nosso GitLab. Em seguida, em manifests/kube-dashboard-oauth2-proxy.yaml especifique o uso da imagem desejada (substitua-a por sua própria):

  image: docker.io/colemickens/oauth2_proxy:latest 

Se você tem um registro fechado por autorização - não esqueça de adicionar um segredo para obter imagens:

  imagePullSecrets: - name: gitlab-registry 

... e adicione o próprio segredo para registro:

 --- apiVersion: v1 data: .dockercfg: eyJyZWdpc3RyeS5jb21wYW55LmNvbSI6IHsKICJ1c2VybmFtZSI6ICJvYXV0aDIiLAogInBhc3N3b3JkIjogIlBBU1NXT1JEIiwKICJhdXRoIjogIkFVVEhfVE9LRU4iLAogImVtYWlsIjogIm1haWxAY29tcGFueS5jb20iCn0KfQoK = kind: Secret metadata: annotations: name: gitlab-registry namespace: kube-system type: kubernetes.io/dockercfg 

Um leitor atento verá que a linha longa acima é base64 da configuração:

 {"registry.company.com": { "username": "oauth2", "password": "PASSWORD", "auth": "AUTH_TOKEN", "email": "mail@company.com" } } 

Esses são os dados do usuário no GitLab, o código pelo qual o Kubernetes extrairá a imagem do registro.

Depois que tudo estiver pronto, você poderá remover a instalação atual do painel (funcionando incorretamente) com o comando:

 $ ./ctl.sh -d 

... e reinstale tudo:

 $ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.com 

É hora de entrar no Painel e encontrar o botão de login bastante arcaico:



Depois de clicar nele, o GitLab nos encontrará, oferecendo o login em sua página familiar (é claro, se não estivéssemos pré-autorizados lá):



Entre com suas credenciais do GitLab - e tudo aconteceu:

Sobre os recursos do painel

Se você é um desenvolvedor que anteriormente não trabalhou com o Kubernetes ou, por algum motivo, nunca encontrou o Dashboard antes, ilustrarei alguns de seus recursos.

Primeiro, você pode ver que "tudo é verde":



Dados mais detalhados estão disponíveis nos pods, como variáveis ​​de ambiente, imagem desinflada, argumentos de inicialização e seu status:



Os status de implantação são visíveis:



... e outros detalhes:



... bem como a capacidade de dimensionar a implantação:



O resultado desta operação:



Entre outros recursos úteis já mencionados no começo do artigo, estão os logs de exibição:



... e a função de entrar no console do contêiner do pod selecionado:



Por exemplo, você também pode ver o limite / solicitação nos nós:



Obviamente, essas não são todas as características do painel, mas espero que a idéia geral tenha se desenvolvido.

Desvantagens da integração e painel

Na integração descrita, não há controle de acesso . Com ele, todos os usuários que têm acesso ao GitLab obtêm acesso ao Painel. Eles têm o mesmo acesso ao painel, correspondente aos direitos do próprio painel, definidos no RBAC . Obviamente, isso não é adequado para todos, mas, no nosso caso, acabou sendo suficiente.

Dos pontos negativos perceptíveis no próprio painel, observo o seguinte:

• é impossível entrar no console do contêiner init;
• não é possível editar Deployments e StatefulSets, embora isso possa ser corrigido no ClusterRole;
• A compatibilidade do painel com as versões mais recentes do Kubernetes e o futuro do projeto levanta questões.

O último problema merece atenção especial.

Status e alternativas do painel

A tabela de compatibilidade do Dashboard com as versões do Kubernetes, apresentada na versão mais recente do projeto ( v1.10.1 ), não está muito feliz:



Apesar disso, existe (já adotado em janeiro) o PR # 3476 , que anuncia o suporte ao K8s 1.13. Além disso, entre as questões do projeto, você pode encontrar referências a usuários que trabalham com o painel no K8s 1.14. Por fim, as confirmações na base de código do projeto não param. Portanto (pelo menos!) O status real do projeto não é tão ruim quanto pode parecer pela primeira vez na tabela de compatibilidade oficial.

Por fim, o Dashboard tem alternativas. Entre eles estão:

1. O K8Dash é uma interface jovem (os primeiros commits são datados de março deste ano), que já oferece bons recursos, como uma representação visual do status atual do cluster e o gerenciamento de seus objetos. Posicionado como uma "interface em tempo real", porque atualiza automaticamente os dados exibidos sem exigir uma atualização da página no navegador.
2. O OpenShift Console é uma interface da Web do Red Hat OpenShift, que, no entanto, trará outras conquistas do projeto ao seu cluster, o que não é adequado a todos.
3. O Kubernator é um projeto interessante criado como uma interface de nível inferior (que o Dashboard), com a capacidade de exibir todos os objetos no cluster. No entanto, tudo parece que seu desenvolvimento parou.
4. No outro dia, Polaris anunciou um projeto que combina as funções de um painel (mostra o estado atual do cluster, mas não gerencia seus objetos) e a "validação automática de práticas recomendadas" (verifica o cluster quanto à configuração correta das implantações em execução).

Em vez de conclusões

O painel é a ferramenta padrão para os clusters do Kubernetes que servimos. Sua integração com o GitLab também se tornou parte de nossa “instalação padrão”, pois muitos desenvolvedores estão satisfeitos com as oportunidades que têm neste painel.

O Kubernetes Dashboard periodicamente tem alternativas da comunidade Open Source (e estamos felizes em considerá-las), mas, neste estágio, continuamos com esta solução.

PS

Leia também em nosso blog:

• “ Kubebox e outros shells de console para o Kubernetes ”;
• “ Melhores práticas de CI / CD com Kubernetes e GitLab (revisão e relatório de vídeo) ”;
• “ Construa e instale aplicativos no Kubernetes usando dapp e GitLab CI ”;
• “ GitLab CI para integração e entrega contínuas na produção. Parte 1: nosso pipeline . ”

UPD De acordo com o relatório whoch, foi encontrado um erro no patch (as guias foram substituídas por espaços). O patch no artigo foi atualizado.