Kubernetes 대시보드와 GitLab 사용자의 통합

Kubernetes 대시보드는 실행 중인 클러스터에 대한 최신 정보를 얻고 이를 최소한으로 관리할 수 있는 사용하기 쉬운 도구입니다. 관리자/DevOps 엔지니어뿐만 아니라 콘솔에 익숙하지 않거나 kubectl 및 DevOps 엔지니어와 상호 작용하는 모든 복잡한 작업을 처리할 의도가 없는 사람들도 이러한 기능에 액세스해야 할 때 더욱 감사하게 될 것입니다. 기타 유틸리티. 우리에게도 이런 일이 일어났습니다. 개발자들은 Kubernetes 웹 인터페이스에 대한 빠른 액세스를 원했고 GitLab을 사용했기 때문에 솔루션이 자연스럽게 나왔습니다.

왜 이래?

직접 개발자는 디버깅 작업을 위해 K8s 대시보드와 같은 도구에 관심이 있을 수 있습니다. 때때로 로그와 리소스를 보고 싶고, 때로는 Pod를 종료하고, 배포/StatefulSet를 확장하고, 심지어 컨테이너 콘솔로 이동하고 싶을 수도 있습니다(그러나 요청도 있습니다. 그러나 다른 방법도 있습니다. 예를 들어 다음을 통해) kubectl-디버그).

또한 관리자가 클러스터를 보고 싶을 때 "모든 것이 녹색"임을 확인하고 "모든 것이 작동하고 있다"고 확신할 수 있는 심리적 순간이 있습니다(물론 이는 매우 상대적입니다... 그러나 이는 기사의 범위를 벗어납니다.)

우리는 표준 CI 시스템으로 적용된 GitLab: 모든 개발자도 사용합니다. 따라서 이들에게 액세스 권한을 제공하기 위해 Dashboard를 GitLab 계정과 통합하는 것이 논리적이었습니다.

또한 NGINX Ingress를 사용한다는 점도 언급하겠습니다. 다른 사람들과 함께 일한다면 진입 솔루션, 인증을 위해 주석 유사 항목을 독립적으로 찾아야 합니다.

통합 시도

대시보드 설치

주의: 아래 단계를 반복하려면 - 불필요한 작업을 피하기 위해 - 먼저 다음 부제목을 읽어 보십시오.

우리는 많은 설치에서 이 통합을 사용하므로 설치를 자동화했습니다. 이에 필요한 소스는 다음에 게시되어 있습니다. 특수 GitHub 저장소. 이는 약간 수정된 YAML 구성을 기반으로 합니다. 공식 대시보드 저장소, 빠른 배포를 위한 Bash 스크립트도 있습니다.

스크립트는 대시보드를 클러스터에 설치하고 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를 접해 본 적이 없는 개발자라면 그 기능 중 일부를 설명하겠습니다.

먼저, "모든 것이 녹색"임을 확인할 수 있습니다.

환경 변수, 다운로드한 이미지, 실행 인수 및 해당 상태와 같은 포드에 대한 더 자세한 데이터도 사용할 수 있습니다.

배포에는 다음과 같은 상태가 표시됩니다.

...및 기타 세부정보:

... 배포를 확장할 수 있는 기능도 있습니다.

이 작업의 결과:

기사 시작 부분에서 이미 언급한 다른 유용한 기능 중에는 로그 보기가 있습니다.

... 그리고 선택한 포드의 컨테이너 콘솔에 로그인하는 기능은 다음과 같습니다.

예를 들어 노드에 대한 제한/요청을 확인할 수도 있습니다.

물론 이것이 패널의 모든 기능은 아니지만 일반적인 아이디어를 얻으시기 바랍니다.

통합과 대시보드의 단점

설명된 통합에는 다음이 없습니다. 액세스 제어. 이를 통해 GitLab에 액세스할 수 있는 모든 사용자는 대시보드에 액세스할 수 있습니다. 대시보드 자체의 권한에 따라 대시보드 자체에도 동일한 액세스 권한이 있습니다. RBAC에 정의되어 있습니다.. 분명히 이것은 모든 사람에게 적합하지는 않지만 우리의 경우에는 충분했습니다.

대시보드 자체의 눈에 띄는 단점 중 다음 사항에 주목합니다.

• init 컨테이너의 콘솔에 들어갈 수 없습니다.
• ClusterRole에서 수정할 수 있지만 배포 및 StatefulSet를 편집하는 것은 불가능합니다.
• 최신 버전의 Kubernetes와 대시보드의 호환성 및 프로젝트의 미래에 대한 의문이 제기됩니다.

마지막 문제는 특별한 주의를 기울일 가치가 있습니다.

대시보드 상태 및 대안

프로젝트의 최신 버전에 제시된 Kubernetes 릴리스와의 대시보드 호환성 표(v1.10.1) 별로 만족스럽지 않습니다.

그럼에도 불구하고 (이미 XNUMX월에 채택됨) PR # 3476, K8s 1.13에 대한 지원을 발표합니다. 또한 프로젝트 이슈 중에서 K8s 1.14의 패널로 작업하는 사용자에 대한 참조를 찾을 수 있습니다. 마지막으로, 커밋하다 프로젝트의 코드 베이스에 멈추지 마세요. 따라서 (적어도!) 프로젝트의 실제 상태는 공식 호환성 표에서 처음 보이는 것만큼 나쁘지 않습니다.

마지막으로 대시보드에 대한 대안이 있습니다. 그 중에는:

1. K8대시 — 클러스터의 현재 상태에 대한 시각적 표현 및 개체 관리와 같은 좋은 기능을 이미 제공하는 젊은 인터페이스(첫 번째 커밋 날짜는 올해 XNUMX월로 거슬러 올라갑니다). "실시간 인터페이스"로 포지셔닝되었습니다. 브라우저에서 페이지를 새로 고칠 필요 없이 표시된 데이터를 자동으로 업데이트합니다.
2. 오픈시프트 콘솔 - Red Hat OpenShift의 웹 인터페이스는 프로젝트의 다른 개발을 클러스터에 가져오지만 모든 사람에게 적합하지는 않습니다.
3. 쿠버네이터 모든 클러스터 개체를 볼 수 있는 기능을 갖춘 하위 수준(대시보드보다) 인터페이스로 생성된 흥미로운 프로젝트입니다. 그러나 개발이 중단된 것 같습니다.
4. 폴라리스 - 저번에 발표 패널의 기능(클러스터의 현재 상태를 표시하지만 해당 객체를 관리하지는 않음)과 자동 "모범 사례 검증"(클러스터에서 실행 중인 배포 구성의 정확성 확인)을 결합하는 프로젝트입니다.

결론 대신

대시보드는 우리가 제공하는 Kubernetes 클러스터를 위한 표준 도구입니다. 많은 개발자가 이 패널의 기능에 대해 기대하고 있기 때문에 GitLab과의 통합도 기본 설치의 일부가 되었습니다.

Kubernetes 대시보드에는 정기적으로 오픈 소스 커뮤니티의 대안이 있지만(우리는 기꺼이 이를 고려하고 있습니다), 현 단계에서는 이 솔루션을 유지합니다.

PS

블로그에서도 읽어보세요.

• «Kubernetes용 kubebox 및 기타 셸";
• «Kubernetes 및 GitLab을 사용한 CI/CD 모범 사례(검토 및 비디오 보고서)";
• «dapp 및 GitLab CI를 사용하여 Kubernetes에서 애플리케이션 구축 및 배포";
• «프로덕션 환경에서 지속적인 통합 및 제공을 위한 GitLab CI입니다. 1부: 파이프라인".

출처 : habr.com