Kubernetes Dashboard — uma ferramenta fácil de usar para obter informações atualizadas sobre um cluster em funcionamento e gerenciá-lo minimamente. Você começa a valorizá-la ainda mais quando o acesso a essas funcionalidades é necessário não apenas para administradores/engenheiros DevOps, mas também para aqueles que estão menos acostumados com o console e/ou não desejam se aprofundar em todas as sutilezas da interação com o kubectl e outras utilidades. Aconteceu conosco: os desenvolvedores queriam acesso rápido à interface web do Kubernetes e, como usamos o GitLab, a solução se apresentou de imediato.
Por que isso?
Os desenvolvedores diretos podem estar interessados em uma ferramenta como o K8s Dashboard para tarefas de depuração. Às vezes, é necessário visualizar logs e recursos, e às vezes até eliminar pods, escalar Deployments/StatefulSets e até acessar o console dos contêineres (ocorrem tais solicitações, para resolver as quais, porém, há outra maneira — por exemplo, através do ).
Além disso, há um aspecto psicológico para os gerentes que desejam ver o cluster — perceber que "tudo está verde" e assim se acalmar que "tudo está funcionando" (o que, claro, é bastante relativo... mas isso já vai além do escopo deste artigo).
Como sistema CI padrão, usamos GitLab: todos os desenvolvedores o utilizam. Assim, para fornecer acesso a eles, era lógico integrar o Dashboard com as contas do GitLab.
Devo também mencionar que usamos o NGINX Ingress. Se você estiver trabalhando com outras , será necessário encontrar analogias de anotações para autenticação por conta própria.
Vamos tentar a integração
Instalação do Dashboard
Atenção: Se você pretende repetir os passos descritos abaixo, por favor — para evitar operações desnecessárias — leia até o próximo subtítulo.
Como esta integração é usada em várias instalações, automatizamos sua instalação. Os fontes necessários para isso estão publicados em . Eles são baseados em configurações YAML ligeiramente modificadas do , além de um script Bash para rápida implantação.
O script instala o Dashboard no cluster e o configura para integrar-se ao GitLab:
$ ./ctl.sh
Uso: ctl.sh [OPÇÃO]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Instale o kubernetes-dashboard no cluster Kubernetes.
Argumentos obrigatórios:
-i, --install instalar no namespace 'kube-system'
-u, --upgrade atualizar a instalação existente, reutilizando senhas e nomes de host
-d, --delete remover tudo, incluindo o namespace
--gitlab-url definir a URL do gitlab com esquema (https://gitlab.example.com)
--oauth2-id definir OAUTH2_PROXY_CLIENT_ID do gitlab
--oauth2-secret definir OAUTH2_PROXY_CLIENT_SECRET do gitlab
--dashboard-url definir a URL do dashboard sem esquema (dashboard.example.com)
Argumentos opcionais:
-h, --help exibir esta mensagemNo entanto, antes de usá-lo, é necessário acessar o GitLab: Área de Administração → Aplicativos — e adicionar um novo aplicativo para o painel futuro. Vamos chamá-lo de "kubernetes dashboard":
Como resultado da adição, o GitLab fornecerá os hashes:
Esses hashes são usados como argumentos para o script. Assim, a instalação fica da seguinte forma:
$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comApós isso, vamos verificar se tudo foi iniciado:
$ 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 14sTarde ou cedo, tudo funcionará, no entanto a autenticação não funcionará imediatamente! O problema é que a imagem usada (a situação em outras imagens é semelhante) tem o processo de captura de redirecionamento para o callback implementado incorretamente. Essa circunstância leva a oauth a apagar o cookie que ele mesmo (oauth) nos fornece…
O problema é solucionado construindo sua própria imagem oauth com um patch.
Patch para oauth e reinstalação
Para isso, usaremos 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
&& 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 bfda078caa55958cc37dcba39e57fc37f6a3c842
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" ]Eis como fica o patch rd.patch
diff --git a/dist.sh b/dist.sh
index a00318b..92990d4 100755
--- a/dist.sh
+++ b/dist.sh
@@ -14,25 +14,13 @@ goversion=$(go version | awk '{print $3}')
sha256sum=()
echo "... executando testes"
-.\/test.sh
+#.\/test.sh
-para os em windows linux darwin; do
- echo "... construindo v$version para $os/$arch"
- EXT=
- se [ $os = windows ]; então
- EXT=".exe"
- fi
- BUILD=$(mktemp -d ${TMPDIR:-/tmp}/oauth2_proxy.XXXXXX)
- TARGET="oauth2_proxy-$version.$os-$arch.$goversion"
- FILENAME="oauth2_proxy-$version.$os-$arch$EXT"
- GOOS=$os GOARCH=$arch CGO_ENABLED=0
- go build -ldflags="-s -w" -o $BUILD/$TARGET/$FILENAME || exit 1
- pushd $BUILD/$TARGET
- sha256sum+=("$(shasum -a 256 $FILENAME || exit 1)")
- cd .. && tar czvf $TARGET.tar.gz $TARGET
- mv $TARGET.tar.gz $DIR/dist
- popd
-feito
+os='linux'
+echo "... construindo v$version para $os/$arch"
+TARGET="oauth2_proxy-$version.$os-$arch.$goversion"
+GOOS=$os GOARCH=$arch CGO_ENABLED=0
+ go build -ldflags="-s -w" -o ./dist/oauth2_proxy || exit 1
checksum_file="sha256sum.txt"
cd $DIR/dists
diff --git a/oauthproxy.go b/oauthproxy.go
index 21e5dfc..df9101a 100644
--- a/oauthproxy.go
+++ b/oauthproxy.go
@@ -381,7 +381,9 @@ func (p *OAuthProxy) SignInPage(rw http.ResponseWriter, req *http.Request, code
if redirect_url == p.SignInPath {
redirect_url = "/"
}
-
+ if req.FormValue("rd") != "" {
+ redirect_url = req.FormValue("rd")
+ }
t := struct {
ProviderName string
SignInMessage string Agora você pode construir a imagem e 'fazer push' dela em nosso GitLab. Em seguida, manifests/kube-dashboard-oauth2-proxy.yaml especificaremos o uso da imagem necessária (substitua-a pela sua):
image: docker.io/colemickens/oauth2_proxy:latestSe você tiver um registro protegido por autenticação — não se esqueça de adicionar o uso do segredo para puxar as imagens:
imagePullSecrets:
- name: gitlab-registry... e adicione o segredo em si para o registro:
---
apiVersion: v1
data:
.dockercfg: eyJyZWdpc3RyeS5jb21wYW55LmNvbSI6IHsKICJ1c2VybmFtZSI6ICJvYXV0aDIiLAogInBhc3N3b3JkIjogIlBBU1NXT1JEIiwKICJhdXRoIjogIkFVVEhfVE9LRU4iLAogImVtYWlsIjogIm1haWxAY29tcGFueS5jb20iCn0KfQoK
=
kind: Secret
metadata:
annotations:
name: gitlab-registry
namespace: kube-system
type: kubernetes.io/dockercfgUm leitor atento verá que a longa string apresentada acima — é a base64 da configuração:
{"registry.company.com": {
"username": "oauth2",
"password": "PASSWORD",
"auth": "AUTH_TOKEN",
"email": "mail@company.com"
}
}Estes são os dados do usuário no GitLab, que o Kubernetes usará para puxar a imagem do registro.
Após tudo isso, você pode remover a instalação atual (que estava funcionando incorretamente) do Dashboard com o comando:
$ ./ctl.sh -d... e instalar tudo novamente:
$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comÉ hora de acessar o Dashboard e encontrar o botão de autorização, que é bastante arcaico:
Após clicar nele, seremos recebidos pelo GitLab, oferecendo autorizar-se em sua página padrão (claro, se não estivermos previamente autenticados lá):
Autorize-se com suas credenciais do GitLab — e tudo estará feito:
Sobre as capacidades do Dashboard
Se você é um desenvolvedor que nunca trabalhou com Kubernetes ou simplesmente, por algum motivo, nunca teve contato com o Dashboard, vou ilustrar algumas de suas funcionalidades.
Primeiro, é possível verificar que "tudo está verde":
Para os pods, estão disponíveis dados mais detalhados, como variáveis de ambiente, imagem extraída, argumentos de execução e seu estado:
Nos deployments, é possível ver os status:
… e outros detalhes:
… e também é possível escalar o deployment:
O resultado dessa operação:
Entre outras funcionalidades úteis já mencionadas no início do artigo, há a visualização de logs:
… e a função de acessar o console dos containers do pod selecionado:
Além disso, por exemplo, é possível verificar os limites/solicitações nos nós:
Claro, essas não são todas as funcionalidades do painel, mas espero que uma visão geral tenha sido formada.
Desvantagens da integração e do Dashboard
Na integração descrita, não há nenhum controle de acesso. Com ela, todos os usuários que têm algum acesso ao GitLab têm acesso ao Dashboard. O acesso no próprio Dashboard é igual para todos, de acordo com as permissões do próprio Dashboard, que . É evidente que isso não servirá para todos, mas no nosso caso se mostrou suficiente.
Entre as desvantagens notáveis do próprio painel do Dashboard, destaco as seguintes:
- não é possível acessar o console do init-container;
- não é possível editar Deployments e StatefulSets, embora isso possa ser corrigido no ClusterRole;
- a compatibilidade do Dashboard com as versões mais recentes do Kubernetes e o futuro do projeto levantam questões.
O último problema merece atenção especial.
Status e alternativas do Dashboard
A tabela de compatibilidade do Dashboard com os lançamentos do Kubernetes, apresentada na versão mais recente do projeto (), não é muito animadora:
Apesar disso, existe (já aceito em janeiro) um , que anuncia o suporte ao K8s 1.13. Além disso, pode-se encontrar entre os problemas do projeto menções de usuários trabalhando com o painel no K8s 1.14. Por fim, na base de código do projeto não param. Assim, (pelo menos!) o status efetivo do projeto não é tão ruim quanto pode inicialmente parecer na tabela oficial de compatibilidade.
Por fim, existem alternativas ao Dashboard. Entre elas:
- — uma interface jovem (os primeiros commits datam de março deste ano), já oferecendo boas funcionalidades, como a representação visual do estado atual do cluster e a gestão de seus objetos. É posicionada como uma "interface em tempo real", pois atualiza automaticamente os dados exibidos, sem necessitar de uma atualização da página no navegador.
- — uma interface web da Red Hat OpenShift, que, no entanto, trará para seu cluster outras contribuições do projeto, nem sempre adequadas para todos.
- — um projeto interessante, criado como uma interface de nível mais baixo (do que o Dashboard) com a possibilidade de visualizar todos os objetos do cluster. Contudo, parece que seu desenvolvimento foi interrompido.
- — literalmente, nos últimos dias um projeto que combina funções de um painel (exibe o estado atual do cluster, mas não gerencia seus objetos) e uma "validação automática das melhores práticas" (verifica se o cluster possui configurações corretas para os Deployments executados nele).
Em vez das saídas
Dashboard — a ferramenta padrão para clusters Kubernetes que gerenciamos. Sua integração com o GitLab também se tornou parte da nossa "instalação padrão", uma vez que muitos desenvolvedores apreciam as possibilidades que surgem com este painel.
Alternativas ao Kubernetes Dashboard surgem periodicamente da comunidade Open Source (e estamos abertos a considerá-las), mas, neste momento, continuamos com essa solução.
P.S.
Confira também em nosso blog:
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
