Интеграция на Kubernetes Dashboard и потребители на GitLab

Kubernetes Dashboard — лесен за работа инструмент за получаване на актуални сведения относно работещия кластер и минимално управление с него. Започваш да го цениш още повече, когато достъпът до тези възможности е нужен не само на администратори/DevOps инженери, но и на тези, които не са свикнали с конзолата и/или не желаят да се заплитат във всички нюанси на взаимодействието с kubectl и други инструменти. Така стана и при нас: разработчиците искат бърз достъп до уеб интерфейса на Kubernetes, а понеже използваме GitLab, решението се наложи само по себе си.

Защо е това необходимо?

Непосредствените разработчици може да се интересуват от инструмент като K8s Dashboard за задачи по отстраняване на проблеми. Понякога искате да прегледате логовете и ресурсите, а понякога да убивате под'ове, да мащабирате Deployments/StatefulSets и дори да влезете в консолите на контейнерите (поради което обаче има и друг начин — например, чрез kubectl-debug).

Освен това, съществува и психологически момент за ръководителите, когато искат да погледнат кластерa — да видят, че „всичко е зелено“ и по този начин да се успокоят, че „всичко работи“ (което, разбира се, е много относително… но това вече излиза извън рамките на статията).

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

Също така искам да отбележа, че използваме NGINX Ingress. Ако работите с други ingress решения, ще трябва самостоятелно да намерите аналози на анотациите за авторизация.

Опитваме интеграцията

Инсталация на Dashboard

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

Тъй като тази интеграция се използва от нас в множество инсталации, ние автоматизирахме нейната инсталация. Изходните файлове, които ще са необходими за това, са публикувани в специален GitHub репозитория. В тяхната основа — незначително модифицирани YAML конфигурации от официалния репозитория на Dashboard, а също така и Bash скрипт за бързо разгръщане.

Скриптът инсталира Dashboard в кластера и го настройва за интеграция с GitLab:

$ .\/ctl.sh  
Използване: ctl.sh [OPTION]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Инсталирайте kubernetes-dashboard в Kubernetes клъстера.
Задължителни аргументи:
 -i, --install                инсталирайте в пространство 'kube-system'
 -u, --upgrade                ъпгрейд на съществуваща инсталация, ще се използват съществуващите пароли и имена на хостове
 -d, --delete                 премахнете всичко, включително пространството
     --gitlab-url             задайте gitlab url с протокол (https:\/\/gitlab.example.com)
     --oauth2-id              задайте OAUTH2_PROXY_CLIENT_ID от gitlab
     --oauth2-secret          задайте OAUTH2_PROXY_CLIENT_SECRET от gitlab
     --dashboard-url          задайте url на таблото без протокол (dashboard.example.com)
Опционални аргументи:
 -h, --help                   изведете това съобщение

Въпреки това, преди да го използвате, е необходимо да влезете в GitLab: Административна област → Приложения — и да добавите ново приложение за бъдещото табло. Нека го наречем „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       Работи   0          14s
oauth2-proxy-5586ccf95c-czp2v           1\/1       Работи   0          14s

Рано или късно всичко ще се стартира, но веднага авторизацията няма да работи! Работата е там, че в използвания образ (ситуацията в другите образи е аналогична) процесът на улавяне на пренасочването в callback е неправилно реализиран. Тази ситуация води до това, че oauth изтрива бисквитката, която сам (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 "... стартиране на тестовете"
-.\/test.sh
+#.\/test.sh
 
-for os in windows linux darwin; do
-    echo "... изграждане на v$version за $os\/към"
-    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 "... изграждане на v$version за $os\/към"
+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

Ако имате затворен registry с автентикация — не забравяйте да добавите използването на секрет за изтегляне на образите:

      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": "mail@company.com"
}
}

Това са данните на потребителя в GitLab, с които Kubernetes ще изтегли образа от 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), не е особено обнадеждаваща:

Въпреки това, съществува (вече приет през януари) PR #3476, който обявява поддръжка за K8s 1.13. Освен това, сред проблемите на проекта можете да намерите споменавания на потребители, които работят с панела при K8s 1.14. Накрая, комитите в кодовата база на проекта не спират. Така че (поне!) фактическото състояние на проекта не е толкова лошо, колкото може първоначално да изглежда от официалната таблица за съвместимост.

Накрая, Dashboard има алтернативи. Сред тях:

1. K8Dash — нов интерфейс (първите комити датират от март тази година), който вече предлага прилични възможности, като визуално представяне на текущия статус на клъстера и управление на неговите обекти. Позиционира се като "интерфейс в реално време", тъй като автоматично актуализира показаните данни, без да е нужно да обновявате страницата в браузъра.
2. OpenShift Конзола — уеб интерфейс от Red Hat OpenShift, който обаче ще донесе и други разработки на проекта във вашия клъстер, което не е подходящо за всички.
3. Kubernator — интересен проект, създаден като по-ниско ниво (от Dashboard) интерфейс с възможност за преглед на всички обекти на клъстера. Въпреки това, изглежда, че разработката му е прекратила.
4. Polaris — буквално преди няколко дни анонсирован проект, който съчетава функции на панел (показва текущото състояние на клъстера, но не управлява обектите му) и автоматична "валидация на най-добри практики" (проверява клъстера за коректност на конфигурациите на стартираните в него Deployments).

Вместо изводите

Dashboard — стандартният инструмент за клъстери Kubernetes, които обслужваме. Тази интеграция с GitLab също стана част от нашата "инсталация по подразбиране", тъй като много разработчици се радват на възможностите, които им предлага тази панел.

За Kubernetes Dashboard периодично появяват алтернативи от Open Source общността (и ние сме радостни да ги разгледаме), но в този етап оставаме с това решение.

P.S.

Прочетете също в нашия блог:

• «kubebox и други конзолни обвивки за Kubernetes»;
• «Най-добри практики за CI/CD с Kubernetes и GitLab (преглед и видео доклад)»;
• «Събиране и деплой на приложения в Kubernetes с помощта на dapp и GitLab CI»;
• «GitLab CI за непрекъсната интеграция и доставка в продукция. Част 1: нашият пайплайн».

Източник: habr.com