Kubernetes Dashboardi ja GitLabi kasutajate integreerimine

Kubernetes Dashboard — lihtne kasutada tööriist, et saada ajakohast teavet töötava klastriga ja minimaalset juhtimist selle üle. Hakatakse seda veel rohkem hindama, kui need võimalused on vajalikud mitte ainult administraatoritele/DevOps-inseneridele, vaid ka neile, kes ei ole harjunud konsooli kasutama ja/või ei kavatse süveneda kõigi nüanssidega, kuidas suhelda kubectl'i ja teiste utiliitidega. Just nii juhtus meil: arendajad soovisid kiiret juurdepääsu Kubernetes'i veebiliidesele, ja kuna me kasutame GitLab'i, tundus lahendus loogiline.

Miks see vajalik on?

Otsesed arendajad võivad olla huvitatud sellisest tööriistast nagu K8s Dashboard tõrkeotsingu ülesannete jaoks. Mõnikord on soov vaadata logsid ja ressursse, aga vahel tuleb ka pod'e lõpetada, skaleerida Deployments/StatefulSets ja isegi sukelduda konteinerite konsooli (sellised päringud on samuti olemas, mille lahendamiseks on aga ka teine tee — näiteks läbi kubectl-debug).

Lisaks on olemas ka psühholoogiline aspekt juhtidele, kes tahavad klastrit vaadata — näha, et "kõik on roheline", ja seeläbi end rahustada, et "kõik töötab" (mis on muidugi väga suhteline ... kuid see jääb juba artikli teemast välja).

Meie standardne CI-süsteem on rakendatakse GitLab: seda kasutavad kõik arendajad. Seetõttu oli mõistlik võimaldada neile juurdepääs, integreerides Dashboard'i GitLab'i kontodega.

Pean ka mainima, et me kasutame NGINX Ingress'i. Kui töötate aga teistega ingress-lahendustega, peate ise leidma analoogsed annotatsioonid autoriseerimiseks.

Proovime integreerimist

Dashboard'i installimine

Ettevaatusabinõud: Kui kavatsete allpool kirjeldatud samme korrata, siis — vältimaks liigseid toiminguid — lugege kõigepealt järgmise pealkirjani.

Kuna me kasutame seda integreerimist paljudes paigaldustes, oleme automatiseerinud selle installimise. Eeltöötlused, mida on vaja selleks, on avaldatud eriti GitHub'i hoidlas. Nende aluseks on vähesel määral muudetud YAML-konfiguratsioonid ametlikust Dashboard'i hoidlast, samuti Bash-skripti kiireks juurutamiseks.

Skript installib Dashboard'i klastrisse ja seadistab selle GitLab'iga integreerimiseks:

$ ./ctl.sh  
Kasutamine: ctl.sh [VALIK]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Installige kubernetes-dashboard Kubernetes klastrisse.
Kohustuslikud argumendid:
 -i, --install                install 'kube-system' nimesse
 -u, --upgrade                uuendage olemasolevat installatsiooni, kasutades sama parooli ja hostinimesid
 -d, --delete                 eemaldage kõik koos nimeserveriga
     --gitlab-url             seadistage gitlabi URL skeemiga (https://gitlab.example.com)
     --oauth2-id              seadistage OAUTH2_PROXY_CLIENT_ID gitlabist
     --oauth2-secret          seadistage OAUTH2_PROXY_CLIENT_SECRET gitlabist
     --dashboard-url          seadistage armatuurlaud ilma skeemita (dashboard.example.com)
Valikuline argument:
 -h, --help                   väljastab selle sõnumi

Kuid enne selle kasutamist peate registreerima GitLabis: Admin ala → Rakendused — ja looma uue rakenduse tulevase paneeli jaoks. Nimeks olgu «kubernetes dashboard»:

Tulemuseks on GitLabis loodud hashid:

Just neid kasutatakse skripti argumendina. Tulemuseks on, et installatsioon näeb välja järgmine:

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

Pärast seda kontrollime, et kõik käivitus:

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

Varem või hiljem käivitatakse kõik, kuid autentimine ei tööta kohe! Asi on selles, et kasutatav pilt (teiste piltide puhul on olukord sarnane) ei realiseeri õigesti redirekti protsessi callback'is. See asjaolu põhjustab selle, et oauth kustutab küpsise, mille just (oauth) meile annab...

Probleem lahendatakse oma oauth pildi kokkupanemisega koos patchiga.

Patch oauth'le ja uuesti installimine

Selle jaoks kasutame järgmist Dockerfile'i:

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

Nii näeb välja 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 "... käivitatakse testid"
-.\/test.sh
+#.\/test.sh
 
-for os in windows linux darwin; do
-    echo "... kogutakse v$version jaoks $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 "... kogutakse v$version jaoks $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

Nüüd on võimalik pildi kogumine ja selle pushimine meie GitLabi. Edasi... manifests/kube-dashboard-oauth2-proxy.yaml määrame vajaliku pildi kasutamise (asendage oma omaga):

 image: docker.io/colemickens/oauth2_proxy:latest

Kui teil on privaatne autentimisega registry - ärge unustage lisada saladuse kasutamine piltide tõmbamiseks:

      imagePullSecrets:
     - name: gitlab-registry

… ja lisage ise saladus registry jaoks:

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

Hoolikas lugeja märkab, et eespool toodud pikk rida on base64 konfi:

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

Need on kasutaja andmed GitLabis, millega Kubernetes tõmbab pilti registry'lt.

Pärast kõike seda on võimalik eemaldada praegune (vale töötav) Dashboardi installatsioon käsuga:

$ .\/ctl.sh -d

… ja seadistada kõik uuesti:

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

On aeg minna Dashboardi ja leida üsna vanamoodne autentimise nupp:

Pärast nupule vajutamist kohtame GitLabi, pakkudes autentimisele oma harjutatud lehel (loomulikult, kui me pole eelnevalt seal autentitud):

Autentime end GitLabi konto andmetega — ja kõik on valmis:

Dashboardi võimaluste kohta

Kui olete arendaja, kes ei ole varem Kubernetesega töötanud, või lihtsalt mingil põhjusel pole Dashboardiga kokku puutunud, illustreerin ma mõningaid selle võimalusi.

Esiteks, saate näha, et "kõik on rohelised":

Podide kohta on saadaval ka detailsemad andmed, näiteks keskkonnamuutujad, allalaaditud pilt, käivitamisargumendid, nende olek:

Deploymentide korral on nähtavad seisundid:

… ja muud üksikasjad:

… samuti on võimalik skalmeerida deploymenti:

Selle operatsiooni tulemus:

Muude kasulike võimaluste seas, nagu juba artikli alguses mainitud, on logide vaatamine:

… ja valitud podi konteinerite konsooli sisenemise funktsioon:

Samuti on võimalik vaadata ka piiranguid/taotlusi sõlmedes:

Muidugi, need ei ole kõik paneeli võimalused, kuid loodetavasti on üldine ettekujutus selge.

Integratsiooni ja Dashboardi puudused

Kirjeldatud integratsioonis puudub igasugune juurdepääsu piiramine. Sellega saavad kõik kasutajad, kellel on mingi juurdepääs GitLabile, juurdepääsu Dashboardile. Dashboardis on neil sama juurdepääs, mis vastab Dashboardi õigustele, mis määratakse RBAC-is. On ilmne, et see ei sobi kõigile, kuid meie juhtumi jaoks oli see piisav.

Peamiste puudustena teiste parameetrite seas toome välja järgmised:

• ei saa pääseda init-konteineri konsooli;
• ei saa redigeerida Deploymente ja StatefulSet'e, kuigi seda saab parandada ClusterRole'is;
• Dashboardi ühilduvus viimaste Kubernetes’i versioonidega ja projekti tulevik tekitab küsimusi.

Viimane probleem väärib erilist tähelepanu.

Dashboardi staatus ja alternatiivid

Dashboardi ühilduvustabel Kubernetes’i väljaannetega, mis on esitatud projekti viimases versioonis (v1.10.1), ei ole just rõõmustav:

Sellegipoolest on olemas (juba jaanuaris vastuvõetud) PR #3476, mis kuulutab välja K8s 1.13 toe. Lisaks võivad projekti probleemide seas leida kasutajad, kes töötavad paneeliga K8s 1.14. Lõpuks, commitid projekti koodibaasi ei ole katkenud. Nii et (minimaalselt!) projekti tegelik seisund ei ole nii halb, kui esmapilgul ametlikust ühilduvustabelist tundub.

Lõpuks on Dashboardil alternatiive. Nende seas:

1. K8Dash — noorliides (esimese kommid on märtsist sel aastal), mis pakub juba häid võimalusi, nagu klastrite aktiivse oleku visuaalne esitamine ja selle objektide haldamine. Positiivne "reaalajas liides", kuna see värskendab automaatselt kuvatavaid andmeid, ilma et oleks vaja brauseris lehte uuendada.
2. OpenShifti konsool — Red Hati OpenShifti veebiliides, mis toob teie klastrisse ka muid projekti arendusi, mis ei pruugi kõikidele sobida.
3. Kubernator — huvitav projekt, mis loodi madalama tasemega (kui Dashboard) liideseks, võimaldades vaadata kõiki klastrite objekte. Kuid tundub, et selle arendamine on peatunud.
4. Polaris — literally just recently tutvustatud projekt, mis ühendab endas paneeli funktsioonid (näitab klastrite praegust seisu, kuid ei halda selle objekte) ja automaatse "parimate praktikate valideerimise" (kontrollib klastrit käivitatud Deployments'i konfiguratsioonide korrektsuse osas).

Järeldused

Dashboard — standardne tööriist Kubernetes'i klastrite jaoks, mida me haldame. Selle integreerimine GitLabiga on samuti osa meie "vaikimisi installatsioonist", kuna paljusid arendajaid rõõmustavad võimalused, mis neil selle paneeliga avanevad.

Kubernetes Dashboard'il ilmub aeg-ajalt Open Source-kommunteti alternatiive (ja me oleme valmis neid arutama), kuid hetkel jääme selle lahenduse juurde.

P.S.

Lugege ka meie blogist:

• «kubebox ja muud käsurealiidesed Kubernetes'ele»;
• «Parimad CI/CD praktikad Kubernetes'i ja GitLabiga (ülevaade ja videoettekanne)»;
• «Rakenduste ülesehitamine ja juurutamine Kubernetes'is dapp'i ja GitLab CI abil»;
• «GitLab CI pidevaks integreerimiseks ja tootmisesse toimetamiseks. Osa 1: meie torujuhe».

Allikas: habr.com