Kubernetes Dashboard é uma ferramenta fácil de usar para obter informações atualizadas sobre seu cluster em execução e gerenciá-lo com o mínimo de esforço. Você começa a apreciar ainda mais quando o acesso a esses recursos é necessário não apenas para administradores/engenheiros de DevOps, mas também para aqueles que estão menos acostumados com o console e/ou não pretendem lidar com todas as complexidades de interagir com kubectl e outras utilidades. Isso aconteceu conosco: os desenvolvedores queriam acesso rápido à interface 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 visualizar logs e recursos e, às vezes, eliminar pods, dimensionar Deployments/StatefulSets e até mesmo ir para o console do contêiner (também há solicitações para as quais, no entanto, há outra maneira - por exemplo, por meio de ).
Além disso, há um momento psicológico dos gestores em que querem olhar para o cluster - ver que “está tudo verde”, e assim se tranquilizarem de que “está tudo a funcionar” (o que, claro, é muito relativo... mas isso está além do escopo do artigo).
Como um sistema CI padrão, temos GitLab: todos os desenvolvedores também usam. Portanto, para fornecer acesso a eles, era lógico integrar o Dashboard às contas do GitLab.
Também observarei que usamos o NGINX Ingress. Se você trabalha com outras pessoas , você precisará encontrar análogos de anotações para autorização de forma independente.
Tentando integração
Instalação do painel
Atenção: Se você for repetir as etapas abaixo, então - para evitar operações desnecessárias - leia primeiro o próximo subtítulo.
Como utilizamos esta integração em muitas instalações, automatizamos sua instalação. As fontes necessárias para isso estão publicadas em . Eles são baseados em configurações YAML ligeiramente modificadas de , bem como um script Bash para implantação rápida.
O script instala o Dashboard no cluster e o configura para integração com o 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 messagePorém, antes de usá-lo, você precisa ir ao GitLab: Área administrativa → Aplicativos - e adicionar um novo aplicativo para o painel futuro. Vamos chamá-lo de “painel do Kubernetes”:
Como resultado da adição, o GitLab fornecerá os hashes:
Eles são usados como argumentos para o script. Como resultado, a instalação fica assim:
$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comDepois disso, vamos verificar 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 14sMais cedo ou mais tarde tudo vai começar, porém a autorização não funcionará imediatamente! O fato é que na imagem utilizada (a situação nas demais imagens é semelhante) o processo de captura de um redirecionamento no callback é implementado incorretamente. Esta circunstância faz com que o oauth apague o cookie que o próprio oauth nos fornece...
O problema é resolvido construindo sua própria imagem oauth com um patch.
Corrigir oauth e reinstalar
Para fazer 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" ]E aqui está a aparência do patch rd.patch em si
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 "... running tests"
-./test.sh
+#./test.sh
-for os in windows linux darwin; do
- echo "... building v$version for $os/$arch"
- EXT=
- if [ $os = windows ]; then
- 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
-done
+os='linux'
+echo "... building v$version for $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 colocá-la em nosso GitLab. Próximo em manifests/kube-dashboard-oauth2-proxy.yaml indique o uso da imagem desejada (substitua pela sua):
image: docker.io/colemickens/oauth2_proxy:latestSe você possui um registro fechado por autorização, não esqueça de adicionar o uso de um segredo para extrair imagens:
imagePullSecrets:
- name: gitlab-registry... e adicione o próprio segredo ao registro:
---
apiVersion: v1
data:
.dockercfg: eyJyZWdpc3RyeS5jb21wYW55LmNvbSI6IHsKICJ1c2VybmFtZSI6ICJvYXV0aDIiLAogInBhc3N3b3JkIjogIlBBU1NXT1JEIiwKICJhdXRoIjogIkFVVEhfVE9LRU4iLAogImVtYWlsIjogIm1haWxAY29tcGFueS5jb20iCn0KfQoK
=
kind: Secret
metadata:
annotations:
name: gitlab-registry
namespace: kube-system
type: kubernetes.io/dockercfgO leitor atento verá que a longa string acima é base64 da configuração:
{"registry.company.com": {
"username": "oauth2",
"password": "PASSWORD",
"auth": "AUTH_TOKEN",
"email": "[email protected]"
}
}Estes são os dados do usuário no GitLab, o código Kubernetes extrairá a imagem do registro.
Depois de tudo feito, você pode remover a instalação atual (que não está funcionando corretamente) do Dashboard com o comando:
$ ./ctl.sh -d... e instale tudo novamente:
$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comÉ hora de ir ao Dashboard e encontrar um botão de login bastante arcaico:
Após clicar nele, o GitLab nos cumprimentará, oferecendo-se para fazer login em sua página habitual (claro, se ainda não tivermos feito login lá):
Efetuamos login com credenciais do GitLab - e tudo está feito:
Sobre os recursos do painel
Se você é um desenvolvedor que nunca trabalhou com Kubernetes antes ou simplesmente por algum motivo não encontrou o Dashboard antes, ilustrarei alguns de seus recursos.
Em primeiro lugar, você pode ver que “tudo é verde”:
Dados mais detalhados também estão disponíveis para pods, como variáveis de ambiente, imagem baixada, argumentos de inicialização e seu estado:
As implantações têm status visíveis:
...e outros detalhes:
... e também existe a capacidade de dimensionar a implantação:
O resultado desta operação:
Entre outros recursos úteis já mencionados no início do artigo está a visualização de logs:
... e a função para fazer login no console do contêiner do pod selecionado:
Por exemplo, você também pode observar os limites/solicitações nos nós:
Claro, essas não são todas as capacidades do painel, mas espero que você tenha entendido a ideia geral.
Desvantagens da integração e Dashboard
Na integração descrita não há controle de acesso. Com ele, todos os usuários com algum acesso ao GitLab ganham acesso ao Dashboard. Têm o mesmo acesso no próprio Dashboard, correspondendo aos direitos do próprio Dashboard, que . Obviamente, isto não é adequado para todos, mas para o nosso caso acabou por ser suficiente.
Entre as desvantagens perceptíveis do próprio Dashboard, destaco o seguinte:
- é impossível entrar no console do contêiner init;
- é impossível editar Deployments e StatefulSets, embora isso possa ser corrigido em 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 painel
Tabela de compatibilidade do dashboard com releases do Kubernetes, apresentada na versão mais recente do projeto (), não muito feliz:
Apesar disso, existe (já adoptado em Janeiro) , que anuncia suporte para K8s 1.13. Além disso, entre os problemas do projeto você encontra referências a usuários que trabalham com o painel no K8s 1.14. Finalmente, 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 à primeira vista na tabela oficial de compatibilidade.
Finalmente, existem alternativas ao Dashboard. Entre eles:
- — uma interface jovem (os primeiros commits datam de março deste ano), que já oferece boas funcionalidades, como representação visual do status atual do cluster e gerenciamento de seus objetos. Posicionado como uma “interface em tempo real”, porque atualiza automaticamente os dados exibidos sem exigir que você atualize a página no navegador.
- - uma interface web do Red Hat OpenShift, que, no entanto, trará outros desenvolvimentos do projeto para o seu cluster, o que não é adequado para todos.
- é um projeto interessante, criado como uma interface de nível inferior (do que o Dashboard) com a capacidade de visualizar todos os objetos do cluster. No entanto, parece que o seu desenvolvimento parou.
- - outro dia mesmo um projeto que combina as funções de um painel (mostra o estado atual do cluster, mas não gerencia seus objetos) e “validação de melhores práticas” automática (verifica o cluster quanto à exatidão das configurações dos Deployments em execução nele).
Em vez de conclusões
Dashboard é uma ferramenta padrão para os clusters Kubernetes que atendemos. Sua integração com o GitLab também se tornou parte de nossa instalação padrão, já que muitos desenvolvedores estão entusiasmados com os recursos que possuem com este painel.
O Kubernetes Dashboard apresenta periodicamente alternativas da comunidade Open Source (e temos o prazer de considerá-las), mas nesta fase continuamos com esta solução.
PS
Leia também em nosso blog:
- «";
- «";
- «";
- «".
Fonte: habr.com