Pagsasama ng Kubernetes Dashboard at Mga User ng GitLab

Ang Kubernetes Dashboard ay isang madaling gamitin na tool para sa pagkuha ng up-to-date na impormasyon tungkol sa iyong tumatakbong cluster at pamamahala nito nang may kaunting pagsisikap. Magsisimula kang mas pahalagahan ito kapag ang pag-access sa mga kakayahan na ito ay kailangan hindi lamang ng mga administrator/DevOps engineer, kundi pati na rin ng mga hindi gaanong sanay sa console at/o hindi nilayon na harapin ang lahat ng mga intricacies ng pakikipag-ugnayan sa kubectl at iba pang mga kagamitan. Nangyari ito sa amin: gusto ng mga developer ng mabilis na access sa web interface ng Kubernetes, at dahil ginagamit namin ang GitLab, natural na dumating ang solusyon.

Bakit ito?

Maaaring interesado ang mga direktang developer sa isang tool tulad ng K8s Dashboard para sa mga gawain sa pag-debug. Minsan gusto mong tingnan ang mga log at mapagkukunan, at kung minsan ay pumatay ng mga pod, scale Deployments/StatefulSets, at kahit na pumunta sa container console (mayroon ding mga naturang kahilingan, kung saan, gayunpaman, mayroong isa pang paraan - halimbawa, sa pamamagitan ng kubectl-debug).

Bilang karagdagan, mayroong isang sikolohikal na sandali para sa mga tagapamahala kapag nais nilang tingnan ang kumpol - upang makita na "lahat ay berde", at sa gayon ay tiyakin sa kanilang sarili na "ang lahat ay gumagana" (na, siyempre, ay napaka-kamag-anak... ngunit ito ay lampas sa saklaw ng artikulo).

Bilang isang karaniwang CI system na mayroon kami inilapat GitLab: ginagamit din ito ng lahat ng mga developer. Samakatuwid, upang mabigyan sila ng access, lohikal na isama ang Dashboard sa mga GitLab account.

Mapapansin ko rin na gumagamit kami ng NGINX Ingress. Kung nagtatrabaho ka sa iba mga solusyon sa pagpasok, kakailanganin mong malayang maghanap ng mga analogue ng mga anotasyon para sa pahintulot.

Sinusubukan ang pagsasama

Pag-install ng dashboard

Pansin: Kung uulitin mo ang mga hakbang sa ibaba, kung gayon - upang maiwasan ang mga hindi kinakailangang operasyon - basahin muna ang susunod na subheading.

Dahil ginagamit namin ang integration na ito sa maraming installation, automated namin ang pag-install nito. Ang mga mapagkukunang kailangan para dito ay nai-publish sa espesyal na imbakan ng GitHub. Ang mga ito ay batay sa bahagyang binagong mga configuration ng YAML mula sa opisyal na imbakan ng Dashboard, pati na rin ang isang Bash script para sa mabilis na pag-deploy.

Ini-install ng script ang Dashboard sa cluster at kino-configure ito para sa pagsasama sa 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

Gayunpaman, bago ito gamitin, kailangan mong pumunta sa GitLab: Admin area → Applications - at magdagdag ng bagong application para sa hinaharap na panel. Tawagin natin itong “kubernetes dashboard”:

Bilang resulta ng pagdaragdag nito, ibibigay ng GitLab ang mga hash:

Sila ang ginagamit na argumento sa script. Bilang resulta, ang pag-install ay ganito ang hitsura:

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

Pagkatapos nito, suriin natin kung nagsimula ang lahat:

$ 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

Maaga o huli magsisimula ang lahat, gayunpaman hindi agad gagana ang awtorisasyon! Ang katotohanan ay sa larawang ginamit (ang sitwasyon sa iba pang mga larawan ay magkatulad) ang proseso ng pagkuha ng isang pag-redirect sa callback ay ipinatupad nang hindi tama. Ang sitwasyong ito ay humahantong sa katotohanan na binubura ng oauth ang cookie na ibinibigay mismo sa atin ng oauth...

Ang problema ay malulutas sa pamamagitan ng pagbuo ng iyong sariling oauth na imahe na may patch.

Patch oauth at muling i-install

Upang gawin ito, gagamitin namin ang sumusunod na 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" ]

At narito ang hitsura mismo ng rd.patch 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 "... 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

Ngayon ay maaari mong buuin ang imahe at itulak ito sa aming GitLab. Susunod sa manifests/kube-dashboard-oauth2-proxy.yaml ipahiwatig ang paggamit ng nais na imahe (palitan ito ng iyong sarili):

 image: docker.io/colemickens/oauth2_proxy:latest

Kung mayroon kang isang registry na sarado sa pamamagitan ng awtorisasyon, huwag kalimutang idagdag ang paggamit ng isang lihim para sa mga pull images:

      imagePullSecrets:
     - name: gitlab-registry

... at idagdag ang lihim mismo para sa pagpapatala:

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

Makikita ng matulungin na mambabasa na ang mahabang string sa itaas ay base64 mula sa config:

{"registry.company.com": {
 "username": "oauth2",
 "password": "PASSWORD",
 "auth": "AUTH_TOKEN",
 "email": "[email protected]"
}
}

Ito ang data ng user sa GitLab, kukunin ng Kubernetes code ang imahe mula sa registry.

Matapos magawa ang lahat, maaari mong alisin ang kasalukuyang (hindi gumagana nang tama) pag-install ng Dashboard gamit ang command:

$ ./ctl.sh -d

... at i-install muli ang lahat:

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

Oras na para pumunta sa Dashboard at maghanap ng medyo archaic na button sa pag-login:

Pagkatapos mag-click dito, sasalubungin kami ng GitLab, na nag-aalok na mag-log in sa karaniwang pahina nito (siyempre, kung hindi pa kami naka-log in doon):

Nag-log in kami gamit ang mga kredensyal ng GitLab - at tapos na ang lahat:

Tungkol sa mga feature ng Dashboard

Kung ikaw ay isang developer na hindi pa nakakatrabaho sa Kubernetes dati, o para lang sa ilang kadahilanan ay hindi pa nakatagpo ng Dashboard dati, ipapakita ko ang ilan sa mga kakayahan nito.

Una, makikita mo na "lahat ay berde":

Available din ang mas detalyadong data para sa mga pod, gaya ng mga variable ng kapaligiran, na-download na larawan, mga argumento sa paglulunsad, at estado ng mga ito:

Ang mga deployment ay may mga nakikitang katayuan:

...at iba pang detalye:

... at mayroon ding kakayahang sukatin ang deployment:

Ang resulta ng operasyong ito:

Kabilang sa iba pang mga kapaki-pakinabang na tampok na nabanggit na sa simula ng artikulo ay ang pagtingin sa mga log:

... at ang function na mag-log in sa container console ng napiling pod:

Halimbawa, maaari mo ring tingnan ang mga limitasyon/kahilingan sa mga node:

Siyempre, hindi ito lahat ng mga kakayahan ng panel, ngunit umaasa ako na makuha mo ang pangkalahatang ideya.

Mga disadvantages ng integration at Dashboard

Sa inilarawang integrasyon ay wala pagkokontrolado. Gamit nito, lahat ng user na may anumang access sa GitLab ay nakakakuha ng access sa Dashboard. Mayroon silang parehong access sa Dashboard mismo, na naaayon sa mga karapatan ng Dashboard mismo, na ay tinukoy sa RBAC. Malinaw, hindi ito angkop para sa lahat, ngunit para sa aming kaso ito ay naging sapat.

Kabilang sa mga kapansin-pansing disadvantages sa Dashboard mismo, napapansin ko ang mga sumusunod:

• imposibleng makapasok sa console ng init na lalagyan;
• imposibleng i-edit ang Mga Deployment at StatefulSets, bagama't maaari itong ayusin sa ClusterRole;
• Ang pagiging tugma ng dashboard sa mga pinakabagong bersyon ng Kubernetes at ang hinaharap ng proyekto ay naglalabas ng mga katanungan.

Ang huling problema ay nararapat na espesyal na pansin.

Katayuan ng dashboard at mga alternatibo

Dashboard compatibility table na may mga release ng Kubernetes, na ipinakita sa pinakabagong bersyon ng proyekto (v1.10.1), hindi masyadong masaya:

Sa kabila nito, mayroon (na-adopt na noong Enero) PR #3476, na nag-aanunsyo ng suporta para sa K8s 1.13. Bilang karagdagan, kabilang sa mga isyu sa proyekto ay makakahanap ka ng mga sanggunian sa mga user na nagtatrabaho sa panel sa K8s 1.14. Sa wakas, nangangako sa code base ng proyekto ay hindi huminto. Kaya (hindi bababa sa!) Ang aktwal na katayuan ng proyekto ay hindi kasing sama ng maaaring una itong tila mula sa opisyal na talahanayan ng pagiging tugma.

Sa wakas, may mga alternatibo sa Dashboard. Sa kanila:

1. K8Dash — isang batang interface (ang unang nag-commit ng petsa noong Marso ng taong ito), na nag-aalok na ng magagandang feature, gaya ng visual na representasyon ng kasalukuyang status ng cluster at pamamahala ng mga bagay nito. Nakaposisyon bilang isang "real-time na interface", dahil awtomatikong ina-update ang ipinapakitang data nang hindi mo hinihiling na i-refresh ang page sa browser.
2. OpenShift Console - isang web interface mula sa Red Hat OpenShift, na, gayunpaman, ay magdadala ng iba pang mga pagpapaunlad ng proyekto sa iyong cluster, na hindi angkop para sa lahat.
3. Kubernator ay isang kawili-wiling proyekto, na nilikha bilang isang mas mababang antas (kaysa sa Dashboard) na interface na may kakayahang tingnan ang lahat ng mga cluster object. Gayunpaman, mukhang huminto ang pag-unlad nito.
4. Polaris - noong isang araw lang inihayag isang proyekto na pinagsasama-sama ang mga function ng isang panel (ipinapakita ang kasalukuyang estado ng cluster, ngunit hindi pinamamahalaan ang mga bagay nito) at awtomatikong "pag-validate ng mga pinakamahusay na kagawian" (sinusuri ang cluster para sa kawastuhan ng mga configuration ng Deployment na tumatakbo dito).

Sa halip na mga konklusyon

Ang Dashboard ay isang karaniwang tool para sa mga kumpol ng Kubernetes na pinaglilingkuran namin. Ang pagsasama nito sa GitLab ay naging bahagi rin ng aming default na pag-install, dahil maraming developer ang nasasabik sa mga kakayahan na mayroon sila sa panel na ito.

Ang Kubernetes Dashboard ay pana-panahong may mga alternatibo mula sa Open Source na komunidad (at masaya kaming isaalang-alang ang mga ito), ngunit sa yugtong ito nananatili kami sa solusyon na ito.

PS

Basahin din sa aming blog:

• «kubebox at iba pang mga shell para sa Kubernetes";
• «Pinakamahuhusay na kasanayan sa CI/CD sa Kubernetes at GitLab (review at video report)";
• «Bumuo at mag-deploy ng mga application sa Kubernetes gamit ang dapp at GitLab CI";
• «GitLab CI para sa patuloy na pagsasama at paghahatid sa produksyon. Bahagi 1: ang aming pipeline'.

Pinagmulan: www.habr.com