Kubernetes Dashboard 和 GitLab Users 的集成

Kubernetes Dashboard 是一个易于使用的工具，用于获取有关正在运行的集群的最新信息并以最小的努力进行管理。 当不仅管理员/DevOps 工程师需要访问这些功能，而且那些不太熟悉控制台和/或不打算处理与 kubectl 交互的所有复杂问题的人也需要访问这些功能时，您会开始更加欣赏它其他公用事业。 我们就遇到过这种情况：开发人员希望快速访问 Kubernetes Web 界面，而由于我们使用 GitLab，解决方案就自然而然地出现了。

这是为什么？

直接开发人员可能对 K8s Dashboard 这样用于调试任务的工具感兴趣。 有时你想查看日志和资源，有时你想杀死 pod，扩展 Deployments/StatefulSet，甚至转到容器控制台（也有请求，但是，还有另一种方法 - 例如，通过 kubectl 调试).

此外，当管理者想要查看集群时，他们会有一个心理时刻 - 看到“一切都是绿色的”，从而让自己放心“一切都在工作”（当然，这是非常相对的......但这超出了本文的范围）。

作为标准 CI 系统，我们有 申请 GitLab：所有开发人员也都使用它。 因此，为了向他们提供访问权限，将仪表板与 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本身提供给我们的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），不太高兴：

尽管如此，还是有（一月份已经通过） PR＃3476，宣布支持 K8s 1.13。 此外，在项目问题中，您可以找到有关在 K8s 1.14 中使用面板的用户的参考。 最后， 提交 进入项目的代码库不要停止。 因此（至少！）该项目的实际状态并不像官方兼容性表中乍看起来那么糟糕。

最后，还有仪表板的替代方案。 他们之中：

1. K8Dash — 一个年轻的界面（第一次提交可以追溯到今年 XNUMX 月），它已经提供了很好的功能，例如集群当前状态的可视化表示及其对象的管理。 定位为“实时界面”，因为自动更新显示的数据，无需您在浏览器中刷新页面。
2. OpenShift 控制台 - 来自 Red Hat OpenShift 的 Web 界面，但是，它将将该项目的其他开发带到您的集群中，这并不适合所有人。
3. 库伯纳特 是一个有趣的项目，创建为较低级别（比仪表板）界面，能够查看所有集群对象。 然而，它的发展似乎已经停止了。
4. Polaris - 就在前几天 宣布 一个项目，结合了面板功能（显示集群的当前状态，但不管理其对象）和自动“最佳实践验证”（检查集群中运行的部署配置的正确性）。

而不是结论

Dashboard 是我们服务的 Kubernetes 集群的标准工具。 它与 GitLab 的集成也成为我们默认安装的一部分，因为许多开发人员对该面板的功能感到兴奋。

Kubernetes Dashboard 定期提供来自开源社区的替代方案（我们很乐意考虑它们），但现阶段我们仍然使用此解决方案。

PS

另请阅读我们的博客：

• «kubebox 和 Kubernetes 的其他 shell“;
• «Kubernetes 和 GitLab 的最佳 CI/CD 实践（评论和视频报告）“;
• «使用 dapp 和 GitLab CI 在 Kubernetes 中构建和部署应用程序“;
• «GitLab CI 用于生产中的持续集成和交付。 第 1 部分：我们的管道“。

来源： habr.com