Интегриране на таблото за управление на Kubernetes и потребителите на 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: Административна област → Приложения - и да добавите ново приложение за бъдещия панел. Нека го наречем „табло за управление на kubernetes“:

В резултат на добавянето му 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 образ с кръпка.

Пач на 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 преди, ще илюстрирам някои от неговите възможности.

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

Налични са и по-подробни данни за подове, като променливи на средата, изтеглено изображение, аргументи за стартиране и тяхното състояние:

Внедряванията имат видими състояния:

...и други подробности:

... и също така има възможност за мащабиране на внедряването:

Резултатът от тази операция:

Сред другите полезни функции, вече споменати в началото на статията, е преглеждането на регистрационни файлове:

... и функцията за влизане в конзолата на контейнера на избрания pod:

Например можете също да разгледате ограниченията/заявките на възли:

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

Недостатъци на интеграцията и таблото за управление

В описаната интеграция няма контрол на достъпа. С него всички потребители с какъвто и да е достъп до GitLab получават достъп до таблото за управление. Те имат същия достъп в самото табло, съответстващо на правата на самото табло, което са определени в RBAC. Очевидно това не е подходящо за всеки, но за нашия случай се оказа достатъчно.

Сред забележимите недостатъци в самото табло отбелязвам следното:

• невъзможно е да влезете в конзолата на init контейнера;
• невъзможно е да се редактират Deployments и StatefulSets, въпреки че това може да бъде коригирано в ClusterRole;
• Съвместимостта на Dashboard с най-новите версии на Kubernetes и бъдещето на проекта повдигат въпроси.

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

Състояние на таблото и алтернативи

Таблица за съвместимост на таблото с издания на Kubernetes, представена в най-новата версия на проекта (v1.10.1), не много щастлив:

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

И накрая, има алтернативи на таблото за управление. Между тях:

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

Вместо заключения

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

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

PS

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

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

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