Kubernetes Dashboard 和 GitLab Users 的集成

Kubernetes Dashboard 是一個易於使用的工具，用於獲取有關正在運行的叢集的最新資訊並以最小的努力進行管理。 當不僅管理員/DevOps 工程師需要存取這些功能，而且那些不太熟悉控制台和/或不打算處理與 kubectl 互動的所有複雜問題的人也需要存取這些功能時，您會開始更加欣賞它其他公用事業。 我們就遇到過這種情況：開發人員希望快速存取 Kubernetes Web 介面，而由於我們使用 GitLab，解決方案就自然而然地出現了。

為什麼是這樣？

直接開發人員可能對 K8s Dashboard 這樣用於調試任務的工具感興趣。 有時你想查看日誌和資源，有時你想殺死 pod，擴展 Deployments/StatefulSet，甚至轉到容器控制台（也有請求，但是，還有另一種方法 - 例如，透過 kubectl 偵錯).

此外，當管理者想要查看集群時，他們會有一個心理時刻- 看到“一切都是綠色的”，從而讓自己放心“一切都在工作”（當然，這是非常相對的.... ..但這超出了本文的範圍）。

作為標準 CI 系統，我們有 適用 GitLab：所有開發人員也都使用它。 因此，為了向他們提供存取權限，將儀表板與 GitLab 帳戶整合是合乎邏輯的。

我還要指出的是，我們使用 NGINX Ingress。 如果你和別人一起工作 入口解決方案，您將需要獨立找到註釋的類似物以進行授權。

嘗試整合

儀表板安裝

Vnimanie：如果您要重複以下步驟，那麼 - 為避免不必要的操作 - 首先閱讀下一個小標題。

由於我們在許多安裝中使用此集成，因此我們已自動化其安裝。 為此所需的來源發佈於 特殊的 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本身提供給我們的cookie...

透過使用補丁建立您自己的 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 還可以獲得更詳細的數據，例如環境變數、下載的映像、啟動參數及其狀態：

部署具有可見的狀態：

……以及其他細節：

……並且還能夠擴展部署：

這個操作的結果：

在文章開頭已經提到的其他有用功能包括查看日誌：

....以及登入所選 Pod 的容器控制台的功能：

例如，您也可以查看節點上的限制/請求：

當然，這些並不是面板的全部功能，但希望您能有個大概的了解。

整合和儀表板的缺點

在所描述的整合中沒有 存取控制。 有了它，所有有權訪問 GitLab 的用戶都可以存取儀表板。 他們在 Dashboard 本身中具有相同的存取權限，對應於 Dashboard 本身的權限，這 在 RBAC 中定義。 顯然，這並不適合所有人，但對於我們的情況來說，它已經足夠了。

在儀表板本身的明顯缺點中，我注意到以下幾點：

• 無法進入init容器的控制台；
• 無法編輯 Deployments 和 StatefulSet，儘管這可以在 ClusterRole 中修復；
• Dashboard 與最新版本 Kubernetes 的兼容性以及該專案的未來引發了疑問。

最後一個問題值得特別關注。

儀表板狀態和替代方案

儀表板與 Kubernetes 版本的相容性表，在專案的最新版本中提供（v1.10.1），不太高興：

儘管如此，還是有（一月份已經通過） 公關#3476，宣布支持 K8s 1.13。 此外，在專案問題中，您可以找到有關在 K8s 1.14 中使用面板的使用者的參考。 最後， 提交 進入專案的程式碼庫不要停止。 因此（至少！）該項目的實際狀態並不像官方相容性表中乍看之下那麼糟糕。

最後，還有儀表板的替代方案。 他們之中：

1. K8Dash — 一個年輕的介面（第一次提交可以追溯到今年 XNUMX 月），它已經提供了很好的功能，例如集群當前狀態的可視化表示及其對象的管理。 定位為“即時介面”，因為自動更新顯示的數據，無需您在瀏覽器中重新整理頁面。
2. OpenShift 控制台 - 來自 Red Hat OpenShift 的 Web 介面，但是，它將將該專案的其他開發帶到您的叢集中，這並不適合所有人。
3. 庫伯納特 是一個有趣的項目，創建為較低級別（比儀表板）介面，能夠查看所有集群物件。 然而，它的發展似乎已經停止了。
4. Polaris - 就在前幾天 宣布 一個項目，結合了面板功能（顯示叢集的當前狀態，但不管理其物件）和自動「最佳實踐驗證」（檢查叢集中運行的部署配置的正確性）。

而不是結論

Dashboard 是我們服務的 Kubernetes 叢集的標準工具。 它與 GitLab 的整合也成為我們預設安裝的一部分，因為許多開發人員對面板的功能感到興奮。

Kubernetes Dashboard 定期提供來自開源社群的替代方案（我們很樂意考慮它們），但現階段我們仍然使用此解決方案。

聚苯乙烯

另請閱讀我們的博客：

• «kubebox 和 Kubernetes 的其他 shell“;
• «Kubernetes 和 GitLab 的最佳 CI/CD 實踐（評論和視訊報告）“;
• «使用 dapp 和 GitLab CI 在 Kubernetes 中建置和部署應用程式“;
• «GitLab CI 用於生產中的持續整合和交付。 第 1 部分：我們的管道“。

來源： www.habr.com