Kubernetes Dashboardin ja GitLab-käyttäjien integrointi

Kubernetes Dashboardin ja GitLab-käyttäjien integrointi

Kubernetes Dashboard on helppokäyttöinen työkalu, jolla saat ajantasaista tietoa käynnissä olevasta klusteristasi ja hallitset sitä vähällä vaivalla. Alat arvostaa sitä entistä enemmän, kun järjestelmänvalvojien/DevOps-insinöörien lisäksi myös ne, jotka ovat vähemmän tottuneet konsoliin ja/tai jotka eivät aio käsitellä kaikkia kubectlin ja muut apuohjelmat. Tämä tapahtui meille: kehittäjät halusivat nopean pääsyn Kubernetes-verkkokäyttöliittymään, ja koska käytämme GitLabia, ratkaisu tuli luonnollisesti.

Miksi tämä on?

Suorat kehittäjät saattavat olla kiinnostuneita K8s Dashboardin kaltaisesta työkalusta virheenkorjaustehtäviin. Joskus haluat tarkastella lokeja ja resursseja ja joskus tappaa podeja, skaalata käyttöönottoja/StatefulSets-asetuksia ja jopa mennä säilökonsoliin (on myös pyyntöjä, joille on kuitenkin olemassa toinen tapa - esim. kubectl-debug).

Lisäksi johtajilla on psykologinen hetki, kun he haluavat katsoa klusteria - nähdä, että "kaikki on vihreää" ja näin vakuuttaa itselleen, että "kaikki toimii" (mikä on tietysti hyvin suhteellista... mutta tämä ei kuulu artikkelin soveltamisalaan ).

Meillä on vakiona CI-järjestelmä sovellettu GitLab: myös kaikki kehittäjät käyttävät sitä. Siksi oli loogista integroida Dashboard GitLab-tileihin pääsyn tarjoamiseksi heille.

Huomaan myös, että käytämme NGINX Ingressia. Jos työskentelet muiden kanssa sisääntuloratkaisut, sinun on löydettävä itsenäisesti merkintöjen analogit valtuutusta varten.

Yritetään integraatiota

Kojelaudan asennus

Huomio: Jos aiot toistaa alla olevat vaiheet, niin - tarpeettomien toimintojen välttämiseksi - lue ensin seuraava alaotsikko.

Koska käytämme tätä integrointia monissa asennuksissa, olemme automatisoineet sen asennuksen. Tätä varten tarvittavat lähteet on julkaistu erityinen GitHub-arkisto. Ne perustuvat hieman muokattuihin YAML-kokoonpanoihin alkaen virallinen Dashboard-arkisto, sekä Bash-komentosarjan nopeaa käyttöönottoa varten.

Skripti asentaa Dashboardin klusteriin ja määrittää sen integroitavaksi GitLabin kanssa:

$ ./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

Ennen kuin käytät sitä, sinun on kuitenkin siirryttävä GitLabiin: Admin area → Applications - ja lisättävä uusi sovellus tulevaan paneeliin. Kutsutaan sitä "kubernetes-hallintapaneeliksi":

Kubernetes Dashboardin ja GitLab-käyttäjien integrointi

Sen lisäämisen seurauksena GitLab tarjoaa tiivisteet:

Kubernetes Dashboardin ja GitLab-käyttäjien integrointi

Niitä käytetään komentosarjan argumentteina. Tämän seurauksena asennus näyttää tältä:

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

Sen jälkeen tarkistetaan, että kaikki alkoi:

$ 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

Ennemmin tai myöhemmin kaikki kuitenkin alkaa lupa ei toimi heti! Tosiasia on, että käytetyssä kuvassa (tilanne muissa kuvissa on samanlainen) uudelleenohjauksen taltiointiprosessi takaisinkutsussa on toteutettu väärin. Tämä seikka johtaa siihen, että oauth poistaa evästeen, jonka oauth itse tarjoaa meille...

Ongelma ratkaistaan ​​rakentamalla oma oauth-kuvasi patchilla.

Korjaa oauth ja asenna uudelleen

Käytämme tätä varten seuraavaa Docker-tiedostoa:

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" ]

Ja tältä itse rd.patch-korjaustiedosto näyttää

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

Nyt voit rakentaa kuvan ja työntää sen GitLabiimme. Seuraavaksi sisään manifests/kube-dashboard-oauth2-proxy.yaml ilmoita halutun kuvan käyttö (korvaa se omallasi):

 image: docker.io/colemickens/oauth2_proxy:latest

Jos sinulla on rekisteri, joka on suljettu valtuutuksen vuoksi, älä unohda lisätä salaisuuden käyttöä vetokuville:

      imagePullSecrets:
     - name: gitlab-registry

... ja lisää itse salaisuus rekisteriin:

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

Huomaavainen lukija näkee, että yllä oleva pitkä merkkijono on base64 konfiguraatiosta:

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

Tämä on GitLabin käyttäjätiedot, Kubernetes-koodi vetää kuvan rekisteristä.

Kun kaikki on tehty, voit poistaa nykyisen (ei toimi oikein) Dashboard-asennuksen komennolla:

$ ./ctl.sh -d

... ja asenna kaikki uudelleen:

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

On aika mennä Dashboardiin ja löytää melko arkaainen kirjautumispainike:

Kubernetes Dashboardin ja GitLab-käyttäjien integrointi

Napsautettuaan sitä GitLab tervehtii meitä tarjoten kirjautumista tavalliselle sivulleen (tietysti, jos emme ole aiemmin kirjautuneet sinne):

Kubernetes Dashboardin ja GitLab-käyttäjien integrointi

Kirjaudumme sisään GitLab-tunnuksilla - ja kaikki on tehty:

Kubernetes Dashboardin ja GitLab-käyttäjien integrointi

Tietoja hallintapaneelin ominaisuuksista

Jos olet kehittäjä, joka ei ole aiemmin työskennellyt Kubernetesin kanssa tai et ole jostain syystä tavannut Dashboardia aiemmin, esitän joitain sen ominaisuuksia.

Ensinnäkin voit nähdä, että "kaikki on vihreää":

Kubernetes Dashboardin ja GitLab-käyttäjien integrointi

Podista on saatavilla myös tarkempia tietoja, kuten ympäristömuuttujat, ladattu kuva, käynnistysargumentit ja niiden tila:

Kubernetes Dashboardin ja GitLab-käyttäjien integrointi

Käyttöönotoilla on näkyvät tilat:

Kubernetes Dashboardin ja GitLab-käyttäjien integrointi

...ja muita yksityiskohtia:

Kubernetes Dashboardin ja GitLab-käyttäjien integrointi

... ja siellä on myös mahdollisuus skaalata käyttöönottoa:

Kubernetes Dashboardin ja GitLab-käyttäjien integrointi

Tämän operaation tulos:

Kubernetes Dashboardin ja GitLab-käyttäjien integrointi

Muiden hyödyllisten ominaisuuksien joukossa, jotka on jo mainittu artikkelin alussa, on lokien katselu:

Kubernetes Dashboardin ja GitLab-käyttäjien integrointi

... ja toiminto kirjautuaksesi valitun podin konsoliin:

Kubernetes Dashboardin ja GitLab-käyttäjien integrointi

Voit esimerkiksi tarkastella myös solmujen rajoituksia/pyyntöjä:

Kubernetes Dashboardin ja GitLab-käyttäjien integrointi

Nämä eivät tietenkään ole kaikki paneelin ominaisuudet, mutta toivon, että saat yleiskäsityksen.

Integraation ja Dashboardin haitat

Kuvatussa integraatiossa ei ole kulunvalvonta. Sen avulla kaikki käyttäjät, joilla on pääsy GitLabiin, pääsevät hallintapaneeliin. Heillä on samat käyttöoikeudet itse Dashboardiin, mikä vastaa itse Dashboardin oikeuksia määritellään RBAC:ssa. Tämä ei tietenkään sovi kaikille, mutta meidän tapauksessamme se osoittautui riittäväksi.

Itse kojelaudan havaittavista haitoista huomautan seuraavaa:

  • on mahdotonta päästä init-säiliön konsoliin;
  • on mahdotonta muokata käyttöönottoja ja StatefulSets-asetuksia, vaikka tämä voidaan korjata ClusterRolessa;
  • Dashboardin yhteensopivuus Kubernetesin uusimpien versioiden kanssa ja projektin tulevaisuus herättävät kysymyksiä.

Viimeinen ongelma ansaitsee erityistä huomiota.

Kojelaudan tila ja vaihtoehdot

Kojelaudan yhteensopivuustaulukko Kubernetes-julkaisujen kanssa, esitelty projektin uusimmassa versiossa (v1.10.1), ei kovin iloinen:

Kubernetes Dashboardin ja GitLab-käyttäjien integrointi

Tästä huolimatta on olemassa (jo hyväksytty tammikuussa) PR # 3476, joka ilmoittaa tuen K8s 1.13:lle. Lisäksi projektien aiheista löytyy viittauksia käyttäjiin, jotka työskentelevät paneelin kanssa K8s 1.14:ssä. Lopuksi, sitoutuu osaksi projektin koodikanta eivät pysähdy. Joten (ainakaan!) projektin todellinen tila ei ole niin huono kuin virallisesta yhteensopivuustaulukosta saattaa ensiksi näyttää.

Lopuksi Dashboardille on vaihtoehtoja. Heidän joukossa:

  1. K8Dash — nuori käyttöliittymä (ensimmäiset sitoumukset ovat tämän vuoden maaliskuussa), jossa on jo hyviä ominaisuuksia, kuten visuaalinen esitys klusterin nykytilasta ja sen objektien hallinta. Sijoitettu "reaaliaikaiseksi käyttöliittymäksi", koska päivittää automaattisesti näytettävät tiedot ilman, että sinun tarvitsee päivittää sivua selaimessa.
  2. OpenShift-konsoli - Red Hat OpenShiftin verkkokäyttöliittymä, joka kuitenkin tuo klusteriisi muita projektin kehityssuuntia, mikä ei sovi kaikille.
  3. Kubernator on mielenkiintoinen projekti, joka on luotu alemman tason (kuin Dashboard) käyttöliittymäksi, jossa on mahdollisuus tarkastella kaikkia klusteriobjekteja. Sen kehitys näyttää kuitenkin pysähtyneen.
  4. Polaris - toissapäivänä ilmoitti projekti, joka yhdistää paneelin toiminnot (näyttää klusterin nykyisen tilan, mutta ei hallitse sen objekteja) ja automaattisen "parhaiden käytäntöjen validoinnin" (tarkistaa klusterin siinä käynnissä olevien käyttöönottojen konfiguraatioiden oikeellisuuden).

Päätelmien sijasta

Dashboard on vakiotyökalu palvelemillemme Kubernetes-klustereille. Sen integroinnista GitLabiin on myös tullut osa oletusasennustamme, koska monet kehittäjät ovat innoissaan tämän paneelin ominaisuuksista.

Kubernetes Dashboardilla on ajoittain vaihtoehtoja avoimen lähdekoodin yhteisöltä (ja harkitsemme niitä mielellämme), mutta tässä vaiheessa pysymme tässä ratkaisussa.

PS.

Lue myös blogistamme:

Lähde: will.com

Lisää kommentti