Integriĝo de Kubernetes Dashboard kaj GitLab Uzantoj

Kubernetes Dashboard estas facile uzebla ilo por akiri ĝisdatajn informojn pri via funkcianta areto kaj administri ĝin per minimuma peno. Vi komencas aprezi ĝin eĉ pli kiam aliro al ĉi tiuj kapabloj estas bezonata ne nur de administrantoj/DevOps-inĝenieroj, sed ankaŭ de tiuj, kiuj estas malpli alkutimiĝintaj al la konzolo kaj/aŭ ne intencas trakti ĉiujn komplikaĵojn de interagado kun kubectl kaj aliaj utilecoj. Ĉi tio okazis ĉe ni: la programistoj volis rapidan aliron al la interfaco de Kubernetes, kaj ĉar ni uzas GitLab, la solvo venis nature.

Kial ĉi tio estas?

Rektaj programistoj eble interesiĝas pri ilo kiel K8s Dashboard por sencimigaj taskoj. Kelkfoje vi volas vidi protokolojn kaj rimedojn, kaj foje mortigi podojn, skali Deployments/StatefulSets, kaj eĉ iri al la kontenera konzolo (estas ankaŭ petoj por kiuj, tamen, ekzistas alia maniero - ekzemple, tra kubectl-debug).

Krome, estas psikologia momento por administrantoj, kiam ili volas rigardi la areton - vidi ke "ĉio estas verda", kaj tiel trankviligi sin ke "ĉio funkcias" (kio, kompreneble, estas tre relativa... sed ĉi tio estas ekster la amplekso de la artikolo ).

Kiel norma CI-sistemo ni havas aplikita GitLab: ankaŭ ĉiuj programistoj uzas ĝin. Tial, por provizi ilin per aliro, estis logike integri Dashboard kun GitLab-kontoj.

Mi ankaŭ rimarkos, ke ni uzas NGINX Ingress. Se vi laboras kun aliaj enirsolvoj, vi devos sendepende trovi analogojn de komentarioj por rajtigo.

Provante integriĝon

Instalado de panelo

singardo: Se vi ripetos la subajn paŝojn, tiam - por eviti nenecesajn operaciojn - unue legu al la sekva subtitolo.

Ĉar ni uzas ĉi tiun integriĝon en multaj instalaĵoj, ni aŭtomatigis ĝian instaladon. La fontoj necesaj por tio estas publikigitaj en speciala GitHub-deponejo. Ili baziĝas sur iomete modifitaj YAML-agordoj de oficiala Dashboard-deponejo, same kiel Bash-skripton por rapida disfaldo.

La skripto instalas Dashboard en la areto kaj agordas ĝin por integriĝo kun 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

Tamen antaŭ ol uzi ĝin, vi devas iri al GitLab: Administra areo → Aplikoj - kaj aldoni novan aplikaĵon por la estonta panelo. Ni nomu ĝin "kubernetes panelo":

Kiel rezulto de aldoni ĝin, GitLab provizos la haŝojn:

Ili estas tiuj, kiuj estas uzataj kiel argumentoj al la skripto. Kiel rezulto, la instalado aspektas jene:

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

Post tio, ni kontrolu, ke ĉio komenciĝis:

$ 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

Pli aŭ malpli frue ĉio komenciĝos, tamen rajtigo ne funkcios tuj! La fakto estas, ke en la uzita bildo (la situacio en aliaj bildoj estas simila) la procezo de kapti alidirektilon en la revoko estas efektivigita malĝuste. Ĉi tiu cirkonstanco kondukas al tio, ke oauth forigas la kuketon, kiun oauth mem provizas al ni...

La problemo estas solvita konstruante vian propran aŭauth-bildon kun flikaĵo.

Flikigu oauth kaj reinstalu

Por fari tion, ni uzos la sekvan 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" ]

Kaj jen kiel aspektas la flikaĵo rd.patch mem

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

Nun vi povas konstrui la bildon kaj puŝi ĝin en nian GitLab. Poste en manifests/kube-dashboard-oauth2-proxy.yaml indiku la uzon de la dezirata bildo (anstataŭigu ĝin per via propra):

 image: docker.io/colemickens/oauth2_proxy:latest

Se vi havas registron fermitan per rajtigo, ne forgesu aldoni la uzon de sekreto por tiraj bildoj:

      imagePullSecrets:
     - name: gitlab-registry

... kaj aldonu la sekreton mem por la registro:

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

La atentema leganto vidos, ke la longa ĉeno supre estas bazo64 el la agordo:

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

Ĉi tio estas la uzantdatumoj en GitLab, la Kubernetes-kodo eltiros la bildon el la registro.

Post kiam ĉio estas farita, vi povas forigi la nunan (ne funkciante ĝuste) Panelan instaladon per la komando:

$ ./ctl.sh -d

... kaj instalu ĉion denove:

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

Estas tempo iri al la Panelo kaj trovi sufiĉe arkaikan ensalutbutonon:

Post klako sur ĝi, GitLab salutos nin, proponante ensaluti al ĝia kutima paĝo (kompreneble, se ni antaŭe ne ensalutis tie):

Ni ensalutas kun GitLab-akreditaĵoj - kaj ĉio estas farita:

Pri la funkcioj de Dashboard

Se vi estas programisto, kiu antaŭe ne laboris kun Kubernetes, aŭ simple ial ne renkontis Dashboard antaŭe, mi ilustros kelkajn el ĝiaj kapabloj.

Unue, vi povas vidi, ke "ĉio estas verda":

Pli detalaj datumoj ankaŭ haveblas por podoj, kiel mediovariabloj, elŝutita bildo, lanĉaj argumentoj kaj ilia stato:

Deplojoj havas videblajn statusojn:

...kaj aliaj detaloj:

... kaj ekzistas ankaŭ la kapablo skali la deplojon:

La rezulto de ĉi tiu operacio:

Inter aliaj utilaj funkcioj jam menciitaj komence de la artikolo estas vidi protokolojn:

... kaj la funkcio por ensaluti en la kontenera konzolo de la elektita pod:

Ekzemple, vi ankaŭ povas rigardi la limojn/petojn sur nodoj:

Kompreneble, ĉi tiuj ne estas ĉiuj kapabloj de la panelo, sed mi esperas, ke vi ricevas la ĝeneralan ideon.

Malavantaĝoj de integriĝo kaj Dashboard

En la priskribita integriĝo ne ekzistas kontrolo de aliro. Per ĝi, ĉiuj uzantoj kun ajna aliro al GitLab akiras aliron al la Panelo. Ili havas la saman aliron en la Panelo mem, respondante al la rajtoj de la Panelo mem, kiu estas difinitaj en RBAC. Evidente, ĉi tio ne taŭgas por ĉiuj, sed por nia kazo ĝi montriĝis sufiĉa.

Inter la rimarkindaj malavantaĝoj en la Dashboard mem, mi notas la jenajn:

• estas neeble eniri la konzolon de la init-ujo;
• estas neeble redakti Deplojojn kaj StatefulSets, kvankam ĉi tio povas esti riparita en ClusterRole;
• La kongruo de Dashboard kun la plej novaj versioj de Kubernetes kaj la estonteco de la projekto levas demandojn.

La lasta problemo meritas specialan atenton.

Statuso de panelo kaj alternativoj

Tabelo de kongrueco de panelo kun Kubernetes-eldonoj, prezentita en la plej nova versio de la projekto (v1.10.1), ne tre feliĉa:

Malgraŭ tio, ekzistas (jam adoptita en januaro) PR # 3476, kiu anoncas subtenon por K8s 1.13. Krome, inter la projektaj aferoj vi povas trovi referencojn al uzantoj laborantaj kun la panelo en K8s 1.14. Fine, faras en la kodon de la projekto ne haltu. Do (almenaŭ!) la reala stato de la projekto ne estas tiel malbona kiel ĝi unue povus ŝajni el la oficiala kongrua tabelo.

Fine, ekzistas alternativoj al Dashboard. Inter ili:

1. K8 Dash — juna interfaco (la unuaj engaĝiĝoj datiĝas de marto de ĉi tiu jaro), kiu jam proponas bonajn funkciojn, kiel vidan reprezentadon de la nuna stato de la areto kaj administrado de ĝiaj objektoj. Poziciita kiel "realtempa interfaco", ĉar aŭtomate ĝisdatigas la montratajn datumojn sen postuli, ke vi refreŝigu la paĝon en la retumilo.
2. OpenShift Konzolo - TTT-interfaco de Red Hat OpenShift, kiu tamen alportos aliajn evoluojn de la projekto al via areto, kiu ne taŭgas por ĉiuj.
3. Kubernatoro estas interesa projekto, kreita kiel malsupra-nivela (ol Dashboard) interfaco kun la kapablo vidi ĉiujn aretajn objektojn. Tamen, ŝajnas, ke ĝia evoluo ĉesis.
4. Polaris - ĝuste la alian tagon anoncita projekto kiu kombinas la funkciojn de panelo (montras la nunan staton de la areto, sed ne administras ĝiajn objektojn) kaj aŭtomatan "validigon de plej bonaj praktikoj" (kontrolas la areton pri la ĝusteco de la agordoj de Deplojoj kurantaj en ĝi).

Anstataŭ konkludoj

Panelo estas norma ilo por la Kubernetes-aretoj, kiujn ni servas. Ĝia integriĝo kun GitLab ankaŭ fariĝis parto de nia defaŭlta instalado, ĉar multaj programistoj estas entuziasmaj pri la kapabloj, kiujn ili havas kun ĉi tiu panelo.

Kubernetes Dashboard periode havas alternativojn de la Malfermfonta komunumo (kaj ni ĝojas konsideri ilin), sed en ĉi tiu etapo ni restas kun ĉi tiu solvo.

PS

Legu ankaŭ en nia blogo:

• «kubebox kaj aliaj ŝeloj por Kubernetes»;
• «Plej bonaj CI/KD-praktikoj kun Kubernetes kaj GitLab (recenzo kaj videoraporto)»;
• «Konstruu kaj deploji aplikaĵojn en Kubernetes uzante dapp kaj GitLab CI»;
• «GitLab CI por kontinua integriĝo kaj livero en produktado. Parto 1: nia dukto".

fonto: www.habr.com