Kubernetes Dashboard un GitLab lietotāju integrācija

Kubernetes Dashboard — viegli lietojams rīks, lai iegūtu aktuālu informāciju par strādājošo klasteri un minimālu tā pārvaldību. Tu to sāki vairāk novērtēt, ja piekļuve šīm iespējām ir nepieciešama ne tikai administratoriem/DevOps inženieriem, bet arī tiem, kuri mazāk pieraduši pie konsoles un/vai neatņemami domā par visu saskarsmi ar kubectl un citiem rīkiem. Tas notika arī pie mums: izstrādātājiem vēlējās ātru piekļuvi Kubernetes tīmekļa saskarnei, un, ņemot vērā, ka mēs izmantojam GitLab, risinājums pats uzspiedās.

Kāpēc tas ir nepieciešams?

Tiešie izstrādātāji varētu būt ieinteresēti rīkā, piemēram, K8s Dashboard, lai veiktu atkļūdošanas uzdevumus. Dažreiz gribas apskatīt žurnālus un resursus, kā arī nogalināt podus, mērogot Deployments/StatefulSets un pat ieiet konteineru konsolē (notiek arī šādi pieprasījumi, kuru risināšanai ir citi ceļi — piemēram, caur kubectl-debug).

Turklāt ir arī psiholoģiskais moments vadītājiem, kad viņi vēlas paskatīties uz klasteri — redzēt, ka „viss ir zaļš”, un tādējādi nomierināties, ka „viss darbojas” (kas, protams, ir diezgan relatīvi… bet tas jau ir ārpus šī raksta robežām).

Kā standarta CI sistēma mums ir tiek izmantota GitLab: to izmanto visi izstrādātāji. Tāpēc, lai nodrošinātu viņiem piekļuvi, bija loģiski izveidot Dashboard integrāciju ar GitLab kontiem.

Es arī atzīmēšu, ka mēs izmantojam NGINX Ingress. Ja jūs strādājat ar citiem ingress risinājumiem, būs nepieciešams pats atrast analoģijas anotācijām autorizācijai.

Mēģinām integrāciju

Dashboard instalācija

Uzmanību: Ja plānojat atkārtot zemāk aprakstītās darbības, tad — lai izvairītos no liekām operācijām — vispirms izlasiet līdz nākamajam apakšvirsrakstam.

Tā kā šo integrāciju izmantojam vairākās instalācijās, mēs automatizējām tās uzstādīšanu. Avoti, kas nepieciešami tam, ir publicēti īpašā GitHub repozitorijā. To pamatā ir nedaudz modificētas YAML konfigurācijas no oficiālā Dashboard repozitorija, kā arī Bash skripts ātrai izvietošanai.

Skripts instalē Dashboard klasterī un konfigurē to integrācijai ar 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

Tomēr pirms tās izmantošanas ir nepieciešams doties uz GitLab: Admin area → Applications — un pievienot jaunu lietotni nākamajai panelei. Nosauksim to par „kubernetes dashboard”:

Pievienojot to, GitLab nodrošinās hash vērtības:

Tieši tās tiek izmantotas kā argumenti skriptam. Rezultātā uzstādīšana izskatās šādi:

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

Pēc tam pārbaudīsim, vai viss ir palaists:

$ 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

Agrāk vai vēlāk viss paliks uzsākt, tomēr uzreiz autentifikācija nedarbosies! Problēma ir tā, ka izmantotajā attēlā (situācija citos attēlos ir līdzīga) nepareizi realizēts pāradresācijas process atpakaļsaitē. Šis apstāklis noved pie tā, ka oauth dzēš sīkdatni, ko pats (oauth) mums sniedz...

Problēma tiek atrisināta, izveidojot savu oauth attēlu ar izlabošanu.

Izlabošana oauth un atkārtota uzstādīšana

Lai to izdarītu, izmantosim sekojošo 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" ]

Un tā izskatās pats patches 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 "... tests tiek pildīti"
-.\/test.sh
+#.\/test.sh
 
-for os in windows linux darwin; do
-    echo "... būvē v$version priekš $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 "... būvē v$version priekš $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

Tagad varam veikt attēla veidošanu un 'push' to uz mūsu GitLab. Tālāk manifests/kube-dashboard-oauth2-proxy.yaml norādīsim izmantot pareizo attēlu (nomainiet to ar savu):

 image: docker.io/colemickens/oauth2_proxy:latest

Ja jums ir slēgts autentifikācijas reģistrs — neaizmirstiet pievienot slepenā izmantošanu attēlu pullēšanai:

      imagePullSecrets:
     - name: gitlab-registry

… un pievienojiet pašu slepenu reģistram:

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

Uzmanīgi lasītāji pamanīs, ka iepriekš minētā garā rinda — tā ir base64 konfigurācija:

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

Šie ir lietotāja dati GitLab, ar kuriem Kubernetes veiks attēlu pullēšanu no reģistra.

Pēc tam, kad viss ir izdarīts, varat izdzēst pašreizējo (nepareizi strādājošo) Dashboard instalāciju ar komandu:

$ .\/ctl.sh -d

… un uzstādīt visu no jauna:

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

Ir pienācis laiks ieiet Dashboard un atrast diezgan novecojušo autentifikācijas pogu:

Pēc tam, kad mēs uzspiedīsim, mūs sagaidīs GitLab, piedāvājot autentificēties savā ierastajā lapā (protams, ja mēs iepriekš nebijām tur autentificējušies):

Autentificējamies ar GitLab akreditācijas datiem — un viss ir izdarīts:

Par Dashboard iespējām

Ja esat izstrādātājs, kurš iepriekš nav strādājis ar Kubernetes, vai arī kaut kādu iemeslu dēļ iepriekš neesat sastapis Dashboard - es ilustrēšu dažas tā iespējas.

Vispirms var apskatīt, ka "viss ir zaļš":

Par pod'iem ir pieejami arī detalizētāki dati, piemēram, vides mainīgie, lejupielādētais attēls, palaišanas argumenti, to stāvoklis:

Par deploy'yem redzami statusi:

… un citi sīki izklāsti:

… kā arī ir iespēja palielināt deployment skaitu:

Šīs operācijas rezultāts:

Starpposmā starp citām noderīgajām iespējām, kas jau tika pieminētas raksta sākumā, ir iespēja apskatīt žurnālus:

… un funkcija piekļuvei izvēlētā pod'a konteineru konsolē:

Tāpat var apskatīt arī limit'us/request'us uz mezgliem:

Protams, šīs ir ne visas paneļa iespējas, bet ceru, ka ir izveidojies vispārējs priekšstats.

Integrācijas un Dashboard trūkumi

Aprakstītajā integrācijā nav nekādas piekļuves kontroles. Ar to visi lietotāji, kuriem ir kāda piekļuve GitLab, iegūst piekļuvi Dashboard. Piekļuve pašā Dashboard ir vienāda, atbilstoša pašas Dashboard tiesībām, kas tiek noteiktas RBAC. Acīmredzot tas ne visiem būs piemēroti, bet mūsu gadījumā tas izrādījās pietiekami.

No ievērojamajiem mīnusiem pašā Dashboard panelī es vēlētos minēt šādas:

• nav iespējams piekļūt init-konteinera konsolē;
• nav iespējams rediģēt Deployments un StatefulSets, lai gan to var novērst ClusterRole;
• Dashboard saderība ar jaunākajām Kubernetes versijām un projekta nākotne rada bažas.

Pēdējā problēma ir pelnījusi īpašu uzmanību.

Status un Dashboard alternatīvas

Dashboard saderības tabula ar Kubernetes izlaidumiem, kas redzama projekta pēdējā versijā (v1.10.1), nav pārāk iepriecinoša:

Neskatoties uz to, pastāv (jau pieņemts janvārī) PR #3476, kas paziņo par K8s 1.13 atbalstu. Turklāt, starp projekta jautājumiem var atrast lietotāju pieminējumus, kuri strādā ar paneli K8s 1.14. Visbeidzot, komitē projektā turpinās. Tātad (vismaz!) faktiskā projekta statusa nav tik sliktā stāvoklī, kā varētu vispirms likties no oficiālās saderības tabulas.

Visfinally, Dashboard ir alternatīvas. Starp tām:

1. K8Dash — jauna saskarne (pirmās izmaiņas datētas ar šī gada martu), jau piedāvā labas iespējas, piemēram, vizuālo pārskatu par pašreizējo klastera statusu un tā objektu pārvaldību. Tā pozicionēta kā "reālā laika saskarne", jo automātiski aktualizē rādītos datus, neprasot atsvaidzināt lapu pārlūkā.
2. OpenShift Console — tīmekļa saskarne no Red Hat OpenShift, kas tomēr atnesīs jūsu klasterī arī citas projekta attīstības, kas ne visiem iederas.
3. Kubernator — interesants projekts, kas radīts kā zemāka līmeņa (salīdzinot ar Dashboard) saskarne ar iespēju apskatīt visus klastera objektus. Tomēr viss izskatās tā, ka tā izstrāde ir apstājusies.
4. Polaris — burtiski nedēļas laikā paziņotais projekts, kas apvieno paneles funkcijas (parāda pašreizējo klastera stāvokli, bet nepārvalda tā objektus) un automātisku "labāko prakses validāciju" (pārbauda klasteri par konfigurāciju pareizību, kas tajā iestrādātos Deployments).

Vietā secinājumiem

Dashboard — standarta rīks Kubernetes klasteriem, kurus mēs apkopt. Tās integrācija ar GitLab ir kļuvusi arī par daļu no mūsu "noklusējuma instalācijas", jo daudzi izstrādātāji ir priecīgi par iespējām, kuras viņiem sniedz šī saskarne.

Kubernetes Dashboard periodiski parādās alternatīvas no Open Source kopienas (un mēs esam priecīgi tās izskatīt), tomēr šajā posmā paliekam pie šī risinājuma.

P.S.

Lasiet arī mūsu emuāra rakstos:

• «kubebox un citas konsoles saskarnes Kubernetes»;
• «Labākās prakses CI/CD ar Kubernetes un GitLab (apskats un video ziņojums)»;
• «Lietojumprogrammu izveide un izvietošana Kubernetes, izmantojot dapp un GitLab CI»;
• «GitLab CI nepārtrauktai integrācijai un piegādei uz produkciju. 1. daļa: mūsu situācija».

Avots: habr.com