Kubernetes ダッシュボードと GitLab ユーザーの統合

Kubernetes ダッシュボードは、実行中のクラスターに関する最新情報を取得し、そのクラスターを最小限に管理するための使いやすいツールです。 これらの機能へのアクセスが管理者や DevOps エンジニアだけでなく、コンソールにあまり慣れていない人や、kubectl や kubectl と対話する際のすべての複雑な操作に対処するつもりがない人によっても必要になると、そのありがたみがさらに高まります。他のユーティリティ。 これは私たちにも起こりました。開発者は Kubernetes Web インターフェイスに素早くアクセスしたいと考えていましたが、私たちは GitLab を使用しているため、ソリューションは自然に生まれました。

これはなぜですか？

直接の開発者は、タスクをデバッグするための K8s Dashboard のようなツールに興味があるかもしれません。 ログやリソースを表示したい場合もあれば、ポッドを強制終了したり、Deployment/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 自体が提供する 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

これで、イメージをビルドして 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 コンテナのコンソールにアクセスすることは不可能です。
• Deployment と StatefulSet を編集することはできませんが、これは ClusterRole で修正できます。
• 最新バージョンの Kubernetes と Dashboard の互換性とプロジェクトの将来には疑問が生じます。

最後の問題は特に注意する必要があります。

ダッシュボードのステータスと代替案

プロジェクトの最新バージョンで示されている、Kubernetes リリースとのダッシュボード互換性テーブル (v1.10.1）、あまり満足していません:

それにもかかわらず、（XNUMX月にすでに採用されている） PR＃3476、K8s 1.13 のサポートを発表します。 さらに、プロジェクトの問題の中には、K8s 1.14 のパネルを使用して作業しているユーザーへの参照が見つかります。 ついに、 コミットする プロジェクトのコードベースへの追加は停止しません。 したがって、(少なくとも!) プロジェクトの実際の状況は、公式の互換性表から最初に思われるほど悪くはありません。

最後に、ダッシュボードの代替手段があります。 その中で：

1. K8ダッシュ — 若いインターフェイス (最初のコミットは今年 XNUMX 月に遡ります)。クラスターの現在のステータスの視覚的表現やそのオブジェクトの管理など、優れた機能をすでに提供しています。 「リアルタイムインターフェース」として位置付けられているため、 ブラウザでページを更新しなくても、表示されたデータが自動的に更新されます。
2. OpenShift コンソール - Red Hat OpenShift の Web インターフェイス。ただし、プロジェクトの他の開発をクラスターに取り込むため、すべての人に適しているわけではありません。
3. クベルネーター これは興味深いプロジェクトで、すべてのクラスター オブジェクトを表示する機能を備えた下位レベル (ダッシュボードより) のインターフェイスとして作成されています。 しかし、その開発は中止されたようです。
4. ポラリス - つい先日 発表 パネルの機能 (クラスターの現在の状態を表示しますが、そのオブジェクトは管理しません) と自動の「ベスト プラクティスの検証」 (クラスター内で実行されているデプロイメントの構成が正しいかどうかをクラスターで確認します) を組み合わせたプロジェクトです。

結論の代わりに

ダッシュボードは、当社が提供する Kubernetes クラスターの標準ツールです。 多くの開発者がこのパネルの機能に興奮しているため、GitLab との統合もデフォルトのインストールの一部になっています。

Kubernetes ダッシュボードにはオープンソース コミュニティからの代替案が定期的に提供されています (喜んで検討します) が、現段階ではこのソリューションを使用し続けます。

PS

私たちのブログもお読みください:

• «kubebox および Kubernetes 用のその他のシェル";
• «Kubernetes と GitLab を使用した CI/CD のベスト プラクティス (レビューとビデオ レポート)";
• «dapp と GitLab CI を使用して Kubernetes でアプリケーションを構築およびデプロイする";
• «本番環境での継続的な統合と配信のための GitLab CI。 パート 1: 当社のパイプライン'。

出所： habr.com