Інтеграція 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), не дуже радує:

Незважаючи на це, існує (вже прийнятий у січні) PR # 3476, який повідомляє про підтримку K8s 1.13. Крім того, серед цихпроектів можна знайти згадки користувачів, що працюють з панеллю в 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