Інтэграцыя Kubernetes Dashboard і карыстальнікаў GitLab

Kubernetes Dashboard - просты ў працы прылада для атрымання актуальных звестак аб які працуе кластары і мінімальнага кіравання ім. Пачынаеш яго шанаваць яшчэ больш, калі доступ да гэтых магчымасцяў патрэбен не толькі адміністратарам/DevOps-інжынерам, але і тым, хто менш абвык да кансолі і/ці не мае намер разбірацца са ўсімі тонкасцямі ўзаемадзеяння з kubectl і іншымі ўтылітамі. Так здарылася і ў нас: распрацоўнікам захацелася хуткага доступу да вэба-інтэрфейсу Kubernetes, а паколькі мы выкарыстоўваем GitLab, рашэнне напрасілася само сабой.

Нашто гэта?

Непасрэдныя распрацоўшчыкі могуць быць зацікаўлены ў інструменце накшталт K8s Dashboard для задач па адладцы. Часам хочацца праглядаць логі і рэсурсы, а часам і забіваць pod'ы, маштабаваць Deployments/StatefulSets і нават заходзіць у кансоль кантэйнераў (здараюцца і такія запыты, для вырашэння якіх, зрэшты, ёсць іншы шлях - напрыклад, праз kubectl-debug).

Акрамя таго, ёсць і псіхалагічны момант для кіраўнікоў, калі яны хочуць паглядзець на кластар - убачыць, што "ўсё зялёненькае", і такім чынам супакоіцца, што "ўсё працуе" (што, вядома, вельмі адносна… але гэта ўжо выходзіць за рамкі артыкула ).

У якасці стандартнай CI-сістэмы ў нас ўжываецца GitLab: ёй карыстаюцца і ўсе распрацоўшчыкі. Таму, каб даць ім доступ, было лагічна зрабіць інтэграцыю Dashboard з акаўнтамі ў GitLab.

Таксама адзначу, што мы выкарыстоўваем NGINX Ingress. Калі ж вы працуеце з іншымі ingress-рашэннямі, спатрэбіцца самастойна знайсці аналагі анатацый для аўтарызацыі.

Спрабуем інтэграцыю

Ўстаноўка Dashboard

Увага: Калі вы збіраецеся паўтараць апісаныя ніжэй крокі, то - у пазбяганне лішніх аперацый - спачатку дачытайце да наступнага падзагалоўка.

Паколькі гэтая інтэграцыя выкарыстоўваецца намі ў мностве інсталяцый, мы аўтаматызавалі яе ўстаноўку. Зыходнікі, якія спатрэбяцца для гэтага, апублікаваны ў спецыяльным GitHub-рэпазітары. У іх аснове – нязначна мадыфікаваныя YAML-канфігурацыі з афіцыйнага рэпазітара Dashboard, а таксама 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: Admin area → Applications - і дадаць новае прыкладанне для будучай панэлі. Назавем яго "kubernetes dashboard":

У выніку яго дадання 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

Рана ці позна ўсё запусціцца, аднак адразу аўтарызацыя працаваць не будзе! Справа ў тым, што ў выкарыстоўванай выяве (сітуацыя ў іншых выявах аналагічная) некарэктна рэалізаваны працэс лоўлі рэдырэкту ў callback. Гэтая акалічнасць прыводзіць да таго, што oauth сцірае cookie, якую сам жа (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

Цяпер можна ажыццявіць зборку выявы і за'push'іць яго ў наш жа GitLab. Далей у manifests/kube-dashboard-oauth2-proxy.yaml пакажам выкарыстанне патрэбнай выявы (заменіце яго на свой):

 image: docker.io/colemickens/oauth2_proxy:latest

Калі ў вас зачынены аўтарызацыяй registry - не забудзьцеся дадаць выкарыстанне сакрэту для pull'а выяў:

      imagePullSecrets:
     - name: gitlab-registry

… і дадайце сам сакрэт для 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 будзе pull'іць выяву з registry.

Пасля таго, як усё зроблена, можна выдаліць бягучую (некарэктна якая працуе) усталёўку Dashboard камандай:

$ ./ctl.sh -d

… і ўсталяваць усё нанова:

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

Надышоў час зайсці ў Dashboard і знайсці даволі архаічную кнопку аўтарызацыі:

Пасля націску на яе нас сустрэне GitLab, прапаноўваючы аўтарызавацца на сваёй звыклай старонцы (вядома ж, калі мы не былі папярэдне аўтарызаваны там):

Аўтарызуемся з уліковымі дадзенымі GitLab – і ўсё адбылося:

Аб магчымасцях Dashboard

Калі вы распрацоўшчык, які перш не працаваў з Kubernetes, ці ж проста па нейкай прычыне не сутыкаліся перш з Dashboard – праілюструю некаторыя яго магчымасці.

Па-першае, можна паглядзець, што «ўсё зялёненькае»:

Па pod'ах даступныя і больш дэталёвыя дадзеныя, такія як зменныя асяроддзі, выпампаваная выява, аргументы запуску, іх стан:

У deployment'аў бачныя статуты:

… і іншыя падрабязнасці:

… а таксама ёсць магчымасць адмаштабаваць deployment:

Вынік гэтай аперацыі:

Сярод іншых карысных магчымасцяў, ужо згаданых у пачатку артыкула, - прагляд логаў:

… і функцыя ўваходу ў кансоль кантэйнераў абранага pod'а:

Яшчэ, напрыклад, можна паглядзець і limit'ы/request'ы на вузлах:

Вядома, гэта не ўсе магчымасці панэлі, але спадзяюся, што агульнае ўяўленне склалася.

Недахопы інтэграцыі і Dashboard

У апісанай інтэграцыі няма ніякага размежаванні доступу. З ёй усе карыстачы, якія маюць які-небудзь доступ да GitLab, атрымліваюць доступ у Dashboard. Доступ у самым Dashboard у іх аднолькавы, які адпавядае правам самой Dashboard, якія вызначаюцца ў RBAC. Відавочна, што гэта падыдзе не ўсім, але для нашага выпадку аказалася дастатковым.

З прыкметных мінусаў у самой панэлі Dashboard адзначу наступныя:

• немагчыма патрапіць у кансоль init-кантэйнера;
• немагчыма рэдагаваць Deployments і StatefulSets, хоць гэта можна паправіць у ClusterRole;
• сумяшчальнасць Dashboard з апошнімі версіямі Kubernetes і будучыню праекту выклікае пытанні.

Апошняя праблема заслугоўвае асаблівай увагі.

Статус і альтэрнатывы Dashboard

Табліца сумяшчальнасці Dashboard з рэлізамі Kubernetes, прадстаўленая ў апошняй версіі праекту (v1.10.1), не вельмі-то радуе:

Нягледзячы на ​​гэта, існуе (ужо прыняты ў студзені) ПР №3476, які аб'яўляе аб падтрымцы K8s 1.13. У дадатак, сярод issues праекту можна знайсці згадванні карыстачоў, якія працуюць з панэллю ў K8s 1.14. Нарэшце, коміты у кодавую базу праекта не спыняюцца. Так што (як мінімум!) фактычны статут праекту не настолькі дрэнны, як можа спачатку здацца з афіцыйнай табліцы сумяшчальнасці.

Урэшце, у Dashboard існуюць альтэрнатывы. Сярод іх:

1. K8Dash - малады інтэрфейс (першыя коміты датуюцца сакавіком гэтага года), які ўжо прапануе нядрэнныя магчымасці, такія як візуальнае прадстаўленне бягучага статусу кластара і кіраванне яго аб'ектамі. Пазіцыянуецца як "інтэрфейс рэальнага часу", т.я. аўтаматычна актуалізуе паказаныя дадзеныя, не патрабуючы абнаўляць старонку ў браўзэры.
2. OpenShift Console - вэб-інтэрфейс ад Red Hat OpenShift, які, зрэшты, прынясе ў ваш кластар і іншыя напрацоўкі праекта, што не ўсім падыходзіць.
3. Kubernator - Цікавы праект, створаны як больш нізкаўзроўневы (чым Dashboard) інтэрфейс з магчымасцю прагляду ўсіх аб'ектаў кластара. Аднак усё выглядае так, што ягоная распрацоўка спынілася.
4. Палярная зорка - літаральна на днях анансаваны праект, які сумяшчае ў сабе функцыі панэлі (паказвае бягучы стан кластара, але не кіруе яго аб'ектамі) і аўтаматычнай "валідацыі лепшых практык" (правярае кластар на карэктнасць канфігурацый запушчаных у ім Deployments).

замест высноў

Dashboard - стандартны інструмент для кластараў Kubernetes, якія мы абслугоўваем. Яго інтэграцыя з GitLab таксама стала часткай нашай «усталёўкі па змаўчанні», паколькі шматлікія распрацоўнікі радыя тым магчымасцям, якія ў іх з'яўляюцца з гэтай панэллю.

У Kubernetes Dashboard перыядычна з'яўляюцца альтэрнатывы ад Open Source-супольнасці (і мы рады іх разгледзець), аднак на дадзеным этапе застаемся з гэтым рашэннем.

PS

Чытайце таксама ў нашым блогу:

• «kubebox і іншыя кансольныя абалонкі для Kubernetes»;
• «Лепшыя практыкі CI/CD з Kubernetes і GitLab (агляд і відэа даклада)»;
• «Зборка і цёплай прыкладанняў у Kubernetes з дапамогай dapp і GitLab CI»;
• «GitLab CI для бесперапыннай інтэграцыі і дастаўкі ў production. Частка 1: наш пайплайн.

Крыніца: habr.com