Интеграција на Kubernetes Dashboard и GitLab корисници

Kubernetes Dashboard е лесна за употреба алатка за добивање ажурирани информации за активен кластер и минимално управување со него. Почнувате да го цените уште повеќе кога пристапот до овие способности им е потребен не само на администраторите/инженерите на DevOps, туку и на оние кои се помалку навикнати на конзолата и/или немаат намера да се справат со сите сложености на интеракцијата со kubectl и други комунални услуги. Ова се случи со нас: програмерите сакаа брз пристап до веб-интерфејсот на Kubernetes, и бидејќи користиме GitLab, решението дојде природно.

Зошто е ова?

Директните програмери може да бидат заинтересирани за алатка како K8s Dashboard за задачи за отстранување грешки. Понекогаш сакате да ги прегледате дневниците и ресурсите, а понекогаш да убиете подлоги, да ги размерите Deployments/StatefulSets, па дури и да одите во конзолата на контејнерот (има и такви барања, за кои, сепак, постои друг начин - на пример, преку kubectl-debug).

Дополнително, постои психолошки момент за менаџерите кога сакаат да го погледнат кластерот - да видат дека „се е зелено“, и на тој начин да се уверат дека „сè работи“ (што, се разбира, е многу релативно ... но ова е надвор од опсегот на статијата).

Како стандарден CI систем имаме важи GitLab: го користат и сите програмери. Затоа, за да им се обезбеди пристап, логично беше да се интегрира Dashboard со сметките на GitLab.

Исто така, ќе забележам дека користиме NGINX Ingress. Ако работите со други решенија за влез, ќе треба самостојно да најдете аналози на прибелешки за овластување.

Обид за интеграција

Инсталација на контролната табла

Внимание: Ако сакате да ги повторите чекорите подолу, тогаш - за да избегнете непотребни операции - прво прочитајте до следниот поднаслов.

Бидејќи ја користиме оваа интеграција во многу инсталации, ја автоматизиравме нејзината инсталација. Изворите потребни за ова се објавени во специјално складиште на GitHub. Тие се засноваат на малку изменети YAML конфигурации од официјално складиште на контролната табла, како и Bash скрипта за брзо распоредување.

Скриптата ја инсталира Dashboard во кластерот и ја конфигурира за интеграција со 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

Сепак, пред да го користите, треба да отидете во GitLab: Административна област → Апликации - и да додадете нова апликација за идниот панел. Да го наречеме „табла на кубернетс“:

Како резултат на неговото додавање, GitLab ќе ги обезбеди хашовите:

Тие се оние кои се користат како аргументи на сценариото. Како резултат на тоа, инсталацијата изгледа вака:

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

После тоа, да провериме дали сè започна:

$ 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

Сепак, порано или подоцна сè ќе започне овластувањето нема да работи веднаш! Факт е дека на употребената слика (ситуацијата на другите слики е слична) процесот на фаќање пренасочување во повратниот повик е имплементиран погрешно. Оваа околност води до фактот дека oauth го брише колачето што самиот oauth ни го дава...

Проблемот е решен со градење на сопствена слика за уверување со лепенка.

Закрпи oauth и повторно инсталирај

За да го направите ова, ќе го користиме следниов 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" ]

А еве како изгледа самиот лепенка 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 "... 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

Сега можете да ја изградите сликата и да ја турнете во нашата GitLab. Следно во manifests/kube-dashboard-oauth2-proxy.yaml наведете ја употребата на саканата слика (заменете ја со своја):

 image: docker.io/colemickens/oauth2_proxy:latest

Ако имате регистар што е затворен со овластување, не заборавајте да додадете употреба на тајна за влечење слики:

      imagePullSecrets:
     - name: gitlab-registry

... и додадете ја самата тајна за регистарот:

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

Внимателниот читател ќе види дека долгата низа погоре е base64 од конфигурацијата:

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

Ова се корисничките податоци во GitLab, кодот на Kubernetes ќе ја повлече сликата од регистарот.

Откако сè ќе заврши, можете да ја отстраните тековната (не работи правилно) инсталација на контролната табла со командата:

$ ./ctl.sh -d

... и повторно инсталирајте сè:

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

Време е да отидете на контролната табла и да најдете прилично архаично копче за најавување:

Откако ќе кликнете на него, GitLab ќе не поздрави, нудејќи да се најавите на неговата вообичаена страница (се разбира, ако претходно не сме се најавиле таму):

Се најавуваме со ингеренциите на GitLab - и сè е направено:

За карактеристиките на контролната табла

Ако сте програмер кој претходно не работел со Kubernetes, или едноставно поради некоја причина не сте се сретнале порано со Dashboard, ќе ви илустрирам некои од неговите способности.

Прво, можете да видите дека „сè е зелено“:

Подетални податоци се достапни и за подлоги, како што се променливите на околината, преземената слика, аргументите за стартување и нивната состојба:

Распоредувањата имаат видливи статуси:

...и други детали:

... и исто така постои можност за зголемување на распоредувањето:

Резултатот од оваа операција:

Меѓу другите корисни функции веќе споменати на почетокот на статијата е гледање дневници:

... и функцијата за најавување во конзолата на контејнерот на избраниот под:

На пример, можете исто така да ги погледнете границите/барањата на јазлите:

Се разбира, ова не се сите можности на панелот, но се надевам дека ја добивте општата идеја.

Недостатоци на интеграцијата и контролната табла

Во опишаната интеграција нема контрола на пристап. Со него, сите корисници со кој било пристап до GitLab добиваат пристап до контролната табла. Тие имаат ист пристап во самата Контролна табла, што одговара на правата на самата Контролна табла, која се дефинирани во RBAC. Очигледно, ова не е погодно за секого, но за нашиот случај се покажа дека е доволно.

Меѓу забележливите недостатоци во самата контролна табла, го забележувам следново:

• невозможно е да се влезе во конзолата на почетниот контејнер;
• невозможно е да се уредуваат Deployments и StatefulSets, иако тоа може да се поправи во ClusterRole;
• Компатибилноста на контролната табла со најновите верзии на Kubernetes и иднината на проектот покренуваат прашања.

Последниот проблем заслужува посебно внимание.

Статус и алтернативи на контролната табла

Табела за компатибилност на контролната табла со изданијата на Kubernetes, претставена во најновата верзија на проектот (v1.10.1), не многу среќен:

И покрај ова, постои (веќе усвоен во јануари) ПР # 3476, кој најавува поддршка за K8s 1.13. Покрај тоа, меѓу проблемите со проектот можете да најдете референци за корисници кои работат со панелот во K8s 1.14. Конечно, обврзува во кодната база на проектот не застанувај. Така, (барем!) вистинскиот статус на проектот не е толку лош како што на прв поглед може да изгледа од официјалната табела за компатибилност.

Конечно, постојат алтернативи за контролната табла. Меѓу нив:

1. K8Dash — млад интерфејс (првите обврзувања датираат од март оваа година), кој веќе нуди добри карактеристики, како што е визуелно прикажување на моменталниот статус на кластерот и управување со неговите објекти. Позициониран како „интерфејс во реално време“, бидејќи автоматски ги ажурира прикажаните податоци без да бара од вас да ја освежите страницата во прелистувачот.
2. Конзола OpenShift - веб-интерфејс од Red Hat OpenShift, кој, сепак, ќе донесе други случувања на проектот во вашиот кластер, што не е погодно за секого.
3. Кубернатор е интересен проект, создаден како интерфејс на пониско ниво (од таблата) со можност за прегледување на сите објекти на кластерот. Сепак, се чини дека неговиот развој е запрен.
4. Поларис - баш пред некој ден објавија проект кој ги комбинира функциите на панелот (ја покажува моменталната состојба на кластерот, но не управува со неговите објекти) и автоматска „валидација на најдобрите практики“ (го проверува кластерот за точноста на конфигурациите на распоредувањата што се извршуваат во него).

Наместо заклучоци

Контролната табла е стандардна алатка за кластерите на Kubernetes што ги опслужуваме. Неговата интеграција со GitLab, исто така, стана дел од нашата стандардна инсталација, бидејќи многу програмери се возбудени за можностите што ги имаат со овој панел.

Kubernetes Dashboard периодично има алтернативи од заедницата со отворен код (и ние сме среќни да ги разгледаме), но во оваа фаза остануваме со ова решение.

PS

Прочитајте и на нашиот блог:

• «kubebox и други школки за Kubernetes";
• «Најдобри практики за CI/CD со Kubernetes и GitLab (преглед и видео извештај)";
• «Изградете и распоредувајте апликации во Kubernetes користејќи dapp и GitLab CI";
• «GitLab CI за континуирана интеграција и испорака во производството. Дел 1: нашиот гасовод".

Извор: www.habr.com