Kubernetes Dashboard is een gebruiksvriendelijke tool waarmee u met minimale inspanning actuele informatie over uw actieve cluster kunt verkrijgen en deze kunt beheren. Je begint het zelfs nog meer te waarderen wanneer toegang tot deze mogelijkheden niet alleen nodig is voor beheerders/DevOps-ingenieurs, maar ook voor degenen die minder gewend zijn aan de console en/of niet van plan zijn om te gaan met alle fijne kneepjes van de interactie met kubectl en andere nutsvoorzieningen. Bij ons gebeurde dit: de ontwikkelaars wilden snelle toegang tot de Kubernetes-webinterface, en aangezien we GitLab gebruiken, kwam de oplossing vanzelf.
Waarom is dit?
Directe ontwikkelaars zijn wellicht geïnteresseerd in een tool als K8s Dashboard voor het opsporen van fouten. Soms wil je logs en bronnen bekijken, en soms pods doden, Deployments/StatefulSets schalen en zelfs naar de containerconsole gaan (er zijn ook verzoeken waarvoor er echter een andere manier is - bijvoorbeeld via ).
Bovendien is er voor managers een psychologisch moment waarop ze naar het cluster willen kijken – om te zien dat ‘alles groen is’, en zichzelf daarmee gerust te stellen dat ‘alles werkt’ (wat natuurlijk heel relatief is… maar dit valt buiten het bestek van het artikel).
Als standaard CI-systeem hebben we GitLab: alle ontwikkelaars gebruiken het ook. Om hen toegang te geven, was het daarom logisch om Dashboard te integreren met GitLab-accounts.
Ik zal ook opmerken dat we NGINX Ingress gebruiken. Als je met anderen samenwerkt , moet u zelfstandig analogen van annotaties vinden voor autorisatie.
Integratie proberen
Dashboardinstallatie
Attentie: Als u onderstaande stappen gaat herhalen, lees dan – om onnodige handelingen te voorkomen – eerst door naar het volgende subkopje.
Omdat we deze integratie in veel installaties gebruiken, hebben we de installatie ervan geautomatiseerd. De bronnen die hiervoor nodig zijn, zijn gepubliceerd in . Ze zijn gebaseerd op licht gewijzigde YAML-configuraties van , evenals een Bash-script voor snelle implementatie.
Het script installeert Dashboard in het cluster en configureert het voor integratie met 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 messageVoordat u het echter gebruikt, moet u naar GitLab gaan: Beheergebied → Applicaties - en een nieuwe applicatie toevoegen voor het toekomstige paneel. Laten we het “kubernetes-dashboard” noemen:
Als resultaat van de toevoeging ervan zal GitLab de hashes leveren:
Zij zijn degenen die worden gebruikt als argumenten voor het script. Als resultaat ziet de installatie er als volgt uit:
$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comLaten we daarna controleren of alles is begonnen:
$ 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 14sVroeg of laat begint echter alles autorisatie werkt niet onmiddellijk! Feit is dat in de gebruikte afbeelding (de situatie in andere afbeeldingen is vergelijkbaar) het proces van het opvangen van een omleiding in de callback onjuist is geïmplementeerd. Deze omstandigheid leidt ertoe dat oauth de cookie wist die oauth zelf aan ons verstrekt...
Het probleem wordt opgelost door uw eigen oauth-image met een patch te bouwen.
Patch oauth en installeer opnieuw
Om dit te doen, gebruiken we het volgende Dockerbestand:
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 zo ziet de rd.patch-patch zelf eruit
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
Nu kunt u de afbeelding bouwen en naar ons GitLab pushen. Volgende binnen manifests/kube-dashboard-oauth2-proxy.yaml geef het gebruik van de gewenste afbeelding aan (vervang deze door uw eigen afbeelding):
image: docker.io/colemickens/oauth2_proxy:latestAls u een register heeft dat door autorisatie is gesloten, vergeet dan niet het gebruik van een geheim voor pull-images toe te voegen:
imagePullSecrets:
- name: gitlab-registry... en voeg het geheim zelf toe voor het register:
---
apiVersion: v1
data:
.dockercfg: eyJyZWdpc3RyeS5jb21wYW55LmNvbSI6IHsKICJ1c2VybmFtZSI6ICJvYXV0aDIiLAogInBhc3N3b3JkIjogIlBBU1NXT1JEIiwKICJhdXRoIjogIkFVVEhfVE9LRU4iLAogImVtYWlsIjogIm1haWxAY29tcGFueS5jb20iCn0KfQoK
=
kind: Secret
metadata:
annotations:
name: gitlab-registry
namespace: kube-system
type: kubernetes.io/dockercfgDe oplettende lezer zal zien dat de lange string hierboven base64 is uit de configuratie:
{"registry.company.com": {
"username": "oauth2",
"password": "PASSWORD",
"auth": "AUTH_TOKEN",
"email": "[email protected]"
}
}Dit zijn de gebruikersgegevens in GitLab, de Kubernetes-code haalt de afbeelding uit het register.
Nadat alles klaar is, kun je de huidige (niet goed werkende) Dashboard-installatie verwijderen met het commando:
$ ./ctl.sh -d... en installeer alles opnieuw:
$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comHet is tijd om naar het Dashboard te gaan en een nogal archaïsche inlogknop te vinden:
Nadat we erop hebben geklikt, zal GitLab ons begroeten en aanbieden om in te loggen op de gebruikelijke pagina (natuurlijk, als we daar nog niet eerder hebben ingelogd):
We loggen in met GitLab-inloggegevens - en alles is klaar:
Over Dashboard-functies
Als u een ontwikkelaar bent die nog niet eerder met Kubernetes heeft gewerkt, of om een of andere reden Dashboard nog niet eerder bent tegengekomen, zal ik enkele van de mogelijkheden ervan illustreren.
Ten eerste kun je zien dat “alles groen is”:
Er zijn ook meer gedetailleerde gegevens beschikbaar voor pods, zoals omgevingsvariabelen, gedownloade afbeeldingen, startargumenten en hun status:
Implementaties hebben zichtbare statussen:
...en andere details:
... en er is ook de mogelijkheid om de implementatie te schalen:
Het resultaat van deze operatie:
Onder andere handige functies die al aan het begin van het artikel zijn genoemd, is het bekijken van logs:
... en de functie om in te loggen op de containerconsole van de geselecteerde pod:
Je kunt bijvoorbeeld ook kijken naar de limieten/verzoeken op knooppunten:
Dit zijn natuurlijk niet alle mogelijkheden van het paneel, maar ik hoop dat u een algemeen idee krijgt.
Nadelen van integratie en Dashboard
In de beschreven integratie is er geen toegangscontrole. Hiermee krijgen alle gebruikers met enige toegang tot GitLab toegang tot het Dashboard. Ze hebben dezelfde toegang tot het Dashboard zelf, overeenkomend met de rechten van het Dashboard zelf . Uiteraard is dit niet voor iedereen geschikt, maar voor ons geval bleek het voldoende.
Onder de merkbare nadelen van het Dashboard zelf merk ik het volgende op:
- het is onmogelijk om in de console van de init-container te komen;
- het is onmogelijk om Deployments en StatefulSets te bewerken, hoewel dit kan worden opgelost in ClusterRole;
- De compatibiliteit van Dashboard met de nieuwste versies van Kubernetes en de toekomst van het project roepen vragen op.
Het laatste probleem verdient bijzondere aandacht.
Dashboardstatus en alternatieven
Dashboard-compatibiliteitstabel met Kubernetes-releases, gepresenteerd in de nieuwste versie van het project (), niet erg blij:
Desondanks is er (reeds in januari aangenomen) , dat ondersteuning aankondigt voor K8s 1.13. Bovendien kunt u onder de projectproblemen verwijzingen vinden naar gebruikers die met het paneel werken in K8s 1.14. Eindelijk, in de codebasis van het project stoppen niet. Dus (tenminste!) De werkelijke status van het project is niet zo slecht als het op het eerste gezicht lijkt op basis van de officiële compatibiliteitstabel.
Tenslotte zijn er alternatieven voor Dashboard. Onder hen:
- — een jonge interface (de eerste commits dateren van maart van dit jaar), die al goede eigenschappen biedt, zoals een visuele weergave van de huidige status van het cluster en het beheer van zijn objecten. Gepositioneerd als een “real-time interface”, omdat werkt de weergegeven gegevens automatisch bij zonder dat u de pagina in de browser hoeft te vernieuwen.
- - een webinterface van Red Hat OpenShift, die echter andere ontwikkelingen van het project naar uw cluster zal brengen, wat niet voor iedereen geschikt is.
- is een interessant project, gemaakt als een interface op een lager niveau (dan Dashboard) met de mogelijkheid om alle clusterobjecten te bekijken. Het lijkt er echter op dat de ontwikkeling ervan is gestopt.
- - laatst nog een project dat de functies van een paneel combineert (toont de huidige status van het cluster, maar beheert de objecten niet) en automatische “validatie van best practices” (controleert het cluster op de juistheid van de configuraties van de implementaties die erin draaien).
In plaats van conclusies
Dashboard is een standaardtool voor de Kubernetes-clusters die wij bedienen. De integratie ervan met GitLab is ook onderdeel geworden van onze standaardinstallatie, omdat veel ontwikkelaars enthousiast zijn over de mogelijkheden die ze met dit paneel hebben.
Kubernetes Dashboard heeft periodiek alternatieven vanuit de Open Source-gemeenschap (en die overwegen we graag), maar in dit stadium blijven we bij deze oplossing.
PS
Lees ook op onze blog:
- «";
- «";
- «";
- «.
Bron: www.habr.com