Интеграция на 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  \nИзползване: ctl.sh [ОПЦИЯ]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL\nИнсталирайте kubernetes-dashboard в кластера на Kubernetes.\nЗадължителни аргументи:\n -i, --install                инсталирайте в пространството от имена 'kube-system'\n -u, --upgrade                актуализиране на съществуваща инсталация, ще повтори паролите и имената на хостовете\n -d, --delete                 премахнете всичко, включително пространството от имена\n     --gitlab-url             задайте gitlab url с схема (https:\/\/gitlab.example.com)\n     --oauth2-id              задайте OAUTH2_PROXY_CLIENT_ID от gitlab\n     --oauth2-secret          задайте OAUTH2_PROXY_CLIENT_SECRET от gitlab\n     --dashboard-url          задайте dashboard url без схема (dashboard.example.com)\nНепринудени аргументи:\n -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)'\nkubernetes-dashboard-76b55bc9f8-xpncp   1\/1       Работи   0          14s\noauth2-proxy-5586ccf95c-czp2v           1\/1       Работи   0          14s

Рано или късно всичко ще се стартира, но авторизацията ще не работи веднага! Работата е там, че в използвания образ (ситуацията в другите образи е аналогична) процесът на хващане на пренасочванията в callback е реализиран некоректно. Това обстоятелство води до това, че oauth изтрива бисквитката, която самият oauth ни предоставя...

Проблемът се решава чрез изграждане на свой образ oauth с патч.

Патч за oauth и повторна инсталация

За целта ще използваме следния Dockerfile:

FROM golang:1.9-alpine3.7\nWORKDIR \/go\/src\/github.com\/bitly\/oauth2_proxy\n\nRUN apk --update add make git build-base curl bash ca-certificates wget \n&& update-ca-certificates \n&& curl -sSO https:\/\/raw.githubusercontent.com\/pote\/gpm\/v1.4.0\/bin\/gpm \n&& chmod +x gpm \n&& mv gpm \/usr\/local\/bin\nRUN git clone https:\/\/github.com\/bitly\/oauth2_proxy.git . \n&& git checkout bfda078caa55958cc37dcba39e57fc37f6a3c842  \nADD rd.patch .\nRUN patch -p1 < rd.patch \n&& .\/dist.sh\n\nFROM alpine:3.7\nRUN apk --update add curl bash  ca-certificates && update-ca-certificates\nCOPY --from=0 \/go\/src\/github.com\/bitly\/oauth2_proxy\/dist\/ \/bin\/\n\nEXPOSE 8080 4180\nENTRYPOINT [ \/bin\/oauth2_proxy ]\nCMD [ "--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/$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 "... изграждане на v$version за $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

Ако имате затворен регистър — не забравяйте да добавите използване на секрет за pull-ване на изображения:

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

Това са данните на потребителя в GitLab, с които Kubernetes ще pull-ва изображението от регистъра.

След като всичко е готово, може да изтрием текущата (некоректно работеща) инсталация на 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:

Също така, можете да видите и лимитите/заявките на възлите:

Разбира се, това не са всички възможности на панела, но се надявам, че сте добили обща представа.

Недостатъци на интеграцията и 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 Console — уеб-интерфейс от 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 за непрекъсната интеграция и доставка в production. Част 1: нашия пайплайн».

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