Kubernetes Dashboard is in maklik te brûken ark foar it krijen fan aktuele ynformaasje oer jo rinnende kluster en it behearjen mei minimale ynspanning. Jo begjinne it noch mear te wurdearjen as tagong ta dizze mooglikheden net allinich nedich is troch behearders / DevOps-yngenieurs, mar ek troch dyjingen dy't minder wend binne oan 'e konsole en / of net fan doel binne om te gean mei alle kompleksjes fan ynteraksje mei kubectl en oare nutsbedriuwen. Dit barde mei ús: de ûntwikkelders woene rappe tagong ta de Kubernetes-webynterface, en om't wy GitLab brûke, kaam de oplossing fansels.
Wêrom is dit?
Direkte ûntwikkelders kinne ynteressearre wêze yn in ark lykas K8s Dashboard foar debuggen fan taken. Soms wolle jo logs en boarnen besjen, en soms wolle jo pods deadzje, Deployments/StatefulSets skaalje, en sels nei de kontenerkonsole gean (d'r binne ek oanfragen wêrfoar d'r lykwols in oare manier is - bygelyks fia ).
Dêrnjonken is d'r in psychologysk momint foar managers as se nei it kluster sjen wolle - om te sjen dat "alles grien is", en har sadwaande gerêststelle dat "alles wurket" (wat fansels tige relatyf is... mar dit is bûten it berik fan it artikel).
As standert CI systeem wy hawwe GitLab: alle ûntwikkelders brûke it ek. Dêrom, om se tagong te jaan, wie it logysk om Dashboard te yntegrearjen mei GitLab-akkounts.
Ik sil ek opmerke dat wy NGINX Ingress brûke. As jo wurkje mei oaren , jo moatte selsstannich analogen fan annotaasjes fine foar autorisaasje.
Besykje yntegraasje
Dashboard ynstallaasje
Opmerking: As jo de stappen hjirûnder werhelje, lês dan - om ûnnedige operaasjes foar te kommen - earst nei de folgjende subkop.
Om't wy dizze yntegraasje yn in protte ynstallaasjes brûke, hawwe wy de ynstallaasje automatisearre. De boarnen dy't dêrfoar nedich binne wurde publisearre yn . Se binne basearre op in bytsje feroare YAML konfiguraasjes fan , en ek in Bash-skript foar flugge ynset.
It skript ynstallearret Dashboard yn it kluster en konfigurearret it foar yntegraasje mei 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 messageFoardat jo it lykwols brûke, moatte jo nei GitLab gean: Admin gebiet → Applikaasjes - en in nije applikaasje tafoegje foar it takomstige paniel. Litte wy it "kubernetes dashboard" neame:
As gefolch fan it tafoegjen sil GitLab de hashes leverje:
It binne dejingen dy't brûkt wurde as arguminten foar it skript. As gefolch, de ynstallaasje sjocht der sa út:
$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comLit ús dêrnei kontrolearje dat alles begon:
$ 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 14sIer of let sil alles lykwols begjinne autorisaasje sil net direkt wurkje! It feit is dat yn 'e brûkte ôfbylding (de situaasje yn oare ôfbyldings is fergelykber) it proses fan it fangen fan in trochferwizing yn' e callback is ferkeard útfierd. Dizze omstannichheid liedt ta it feit dat oauth it koekje wisket dat oauth sels oan ús leveret ...
It probleem wurdt oplost troch it bouwen fan jo eigen oauth-ôfbylding mei in patch.
Patch oauth en opnij ynstallearje
Om dit te dwaan, sille wy de folgjende Dockerfile brûke:
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" ]En hjir is wat de rd.patch patch sels liket
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
No kinne jo de ôfbylding bouwe en it yn ús GitLab drukke. Folgjende yn manifests/kube-dashboard-oauth2-proxy.yaml jouwe it gebrûk fan 'e winske ôfbylding oan (ferfang it mei jo eigen):
image: docker.io/colemickens/oauth2_proxy:latestAs jo in register hawwe dat is sluten troch autorisaasje, ferjit dan net it gebrûk fan in geheim ta te foegjen foar pull-ôfbyldings:
imagePullSecrets:
- name: gitlab-registry... en foegje it geheim sels ta foar it register:
---
apiVersion: v1
data:
.dockercfg: eyJyZWdpc3RyeS5jb21wYW55LmNvbSI6IHsKICJ1c2VybmFtZSI6ICJvYXV0aDIiLAogInBhc3N3b3JkIjogIlBBU1NXT1JEIiwKICJhdXRoIjogIkFVVEhfVE9LRU4iLAogImVtYWlsIjogIm1haWxAY29tcGFueS5jb20iCn0KfQoK
=
kind: Secret
metadata:
annotations:
name: gitlab-registry
namespace: kube-system
type: kubernetes.io/dockercfgDe oandachtige lêzer sil sjen dat de lange string hjirboppe base64 is fan 'e konfiguraasje:
{"registry.company.com": {
"username": "oauth2",
"password": "PASSWORD",
"auth": "AUTH_TOKEN",
"email": "[email protected]"
}
}Dit binne de brûkersgegevens yn GitLab, de Kubernetes-koade sil de ôfbylding út it register lûke.
Nei't alles dien is, kinne jo de aktuele (net goed wurkje) Dashboard-ynstallaasje fuortsmite mei it kommando:
$ ./ctl.sh -d... en alles opnij ynstallearje:
$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comIt is tiid om nei it Dashboard te gean en in nochal archayske oanmeldknop te finen:
Nei it klikken op it, sil GitLab ús begroetsje, en biedt oan te loggen op syn gewoane side (fansels, as wy dêr net earder oanmeld binne):
Wy ynlogge mei GitLab-bewizen - en alles is dien:
Oer Dashboard funksjes
As jo in ûntwikkelder binne dy't net earder mei Kubernetes hat wurke, of gewoan om ien of oare reden net earder Dashboard hawwe tsjinkaam, sil ik guon fan syn mooglikheden yllustrearje.
As earste kinne jo sjen dat "alles grien is":
Mear detaillearre gegevens binne ek beskikber foar pods, lykas omjouwingsfariabelen, ynladen ôfbylding, lansearringsarguminten en har steat:
Ynset hawwe sichtbere statusen:
... en oare details:
... en d'r is ek de mooglikheid om de ynset te skaaljen:
It resultaat fan dizze operaasje:
Under oare nuttige funksjes al neamd oan it begjin fan it artikel is it besjen fan logs:
... en de funksje om oan te melden by de kontenerkonsole fan de selektearre pod:
Jo kinne bygelyks ek sjen nei de grinzen / oanfragen op knopen:
Fansels binne dit net alle mooglikheden fan it paniel, mar ik hoopje dat jo it algemiene idee krije.
Neidielen fan yntegraasje en Dashboard
Yn de beskreaune yntegraasje is der gjin tagongskontrôle. Dêrmei krije alle brûkers mei elke tagong ta GitLab tagong ta it Dashboard. Se hawwe deselde tagong yn it Dashboard sels, oerienkommende mei de rjochten fan it Dashboard sels, dy't . Fansels is dit net foar elkenien geskikt, mar foar ús wie it genôch.
Under de merkbere neidielen yn it Dashboard sels, note ik it folgjende:
- it is ûnmooglik om yn 'e konsole fan' e init-container te kommen;
- it is ûnmooglik om Deployments en StatefulSets te bewurkjen, hoewol dit kin wurde reparearre yn ClusterRole;
- De kompatibiliteit fan Dashboard mei de lêste ferzjes fan Kubernetes en de takomst fan it projekt ropt fragen op.
It lêste probleem fertsjinnet spesjaal omtinken.
Dashboardstatus en alternativen
Dashboard-kompatibiliteitstabel mei Kubernetes-releases, presintearre yn 'e lêste ferzje fan it projekt (), net hiel bliid:
Nettsjinsteande dit is der (yn jannewaris al oannommen) , dy't stipe oankundiget foar K8s 1.13. Derneist kinne jo ûnder de projektproblemen ferwizings fine nei brûkers dy't wurkje mei it paniel yn K8s 1.14. Úteinlik, yn it projekt syn koade basis net ophâlde. Dat (op syn minst!) De eigentlike status fan it projekt is net sa slim as it earst liket út 'e offisjele kompatibiliteitstabel.
Uteinlik binne d'r alternativen foar Dashboard. Under harren:
- - in jonge ynterface (de earste commits datearje werom oant maart fan dit jier), dy't al goede funksjes biedt, lykas in fisuele foarstelling fan 'e hjoeddeistige status fan it kluster en it behear fan har objekten. Gepositioneerd as in "real-time ynterface", omdat fernijt automatysk de werjûn gegevens sûnder dat jo de side yn 'e browser moatte ferfarskje.
- - in webynterface fan Red Hat OpenShift, dy't lykwols oare ûntwikkelingen fan it projekt nei jo kluster bringt, dy't net foar elkenien geskikt is.
- is in ynteressant projekt, makke as in interface op legere nivo (as Dashboard) mei de mooglikheid om alle klusterobjekten te besjen. It liket lykwols as de ûntwikkeling is stoppe.
- - krekt de oare deis in projekt dat de funksjes fan in paniel kombineart (de hjoeddeistige tastân fan it kluster toant, mar syn objekten net beheart) en automatyske "validaasje fan bêste praktiken" (kontrolearret it kluster foar de krektens fan 'e konfiguraasjes fan Deployments dy't deryn rinne).
Yn plak fan konklúzjes
Dashboard is in standert ark foar de Kubernetes-klusters dy't wy tsjinje. De yntegraasje mei GitLab is ek diel wurden fan ús standertynstallaasje, om't in protte ûntwikkelders optein binne oer de mooglikheden dy't se hawwe mei dit paniel.
Kubernetes Dashboard hat periodyk alternativen fan 'e Open Source-mienskip (en wy binne bliid om se te beskôgjen), mar op dit stadium bliuwe wy mei dizze oplossing.
PS
Lês ek op ús blog:
- «";
- «";
- «";
- «".
Boarne: www.habr.com