A Kubernetes Dashboard egy könnyen használható eszköz, amellyel naprakész információkhoz juthat a futó fürtről, és minimális erőfeszítéssel kezelheti azokat. Még jobban kezdi értékelni, ha ezekhez a képességekhez nem csak a rendszergazdáknak/DevOps mérnököknek van szükségük, hanem azoknak is, akik kevésbé vannak hozzászokva a konzolhoz és/vagy nem szándékoznak megbirkózni a kubectl-lel és egyéb közművek. Ez nálunk is megtörtént: a fejlesztők gyors hozzáférést akartak a Kubernetes webes felületéhez, és mivel GitLabot használunk, a megoldás magától jött.
Miért ez?
A közvetlen fejlesztők érdeklődhetnek egy olyan eszköz iránt, mint a K8s Dashboard a hibakeresési feladatokhoz. Néha meg szeretné tekinteni a naplókat és az erőforrásokat, néha pedig meg akarja ölni a podokat, méretezheti a telepítéseket/állapotkészleteket, és még a tárolókonzolra is szeretne menni (vannak olyan kérések is, amelyeknek van egy másik módja is - például ).
Emellett a vezetők számára van egy pszichológiai pillanat, amikor rá akarnak nézni a klaszterre - látni, hogy „minden zöld”, és ezzel megnyugtatják magukat, hogy „minden működik” (ami persze nagyon relatív... de ez túlmutat a cikk keretein ).
Szabványos CI rendszerünk van GitLab: minden fejlesztő is használja. Ezért a hozzáférés biztosítása érdekében logikus volt a Dashboard integrálása a GitLab-fiókokkal.
Azt is megjegyzem, hogy NGINX Ingress-t használunk. Ha másokkal dolgozol , önállóan meg kell találnia a megjegyzések analógjait az engedélyezéshez.
Integráció próbálkozása
A műszerfal telepítése
Figyelem: Ha meg akarja ismételni az alábbi lépéseket, akkor - a felesleges műveletek elkerülése érdekében - először olvassa el a következő alcímet.
Mivel ezt az integrációt sok telepítésnél használjuk, a telepítését automatizáltuk. Az ehhez szükséges forrásokat ben közöljük . Ezek kissé módosított YAML konfigurációkon alapulnak , valamint egy Bash-szkriptet a gyors telepítéshez.
A szkript telepíti az irányítópultot a fürtbe, és beállítja a GitLabbal való integrációhoz:
$ ./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 messageHasználata előtt azonban el kell lépnie a GitLab: Adminisztrációs terület → Alkalmazások oldalra, és új alkalmazást kell hozzáadnia a jövőbeli panelhez. Nevezzük „kubernetes irányítópultnak”:
Hozzáadása eredményeként a GitLab biztosítja a kivonatokat:
Ezek azok, amelyek argumentumaként szolgálnak a szkripthez. Ennek eredményeként a telepítés így néz ki:
$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comEzek után nézzük meg, hogy minden elindult:
$ 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 14sElőbb-utóbb azonban minden beindul az engedélyezés nem működik azonnal! Az a tény, hogy a használt képen (a többi képen hasonló a helyzet) az átirányítás elkapásának folyamata a visszahívásban helytelenül van megvalósítva. Ez a körülmény oda vezet, hogy az oauth törli azt a sütit, amelyet maga az oauth biztosít számunkra...
A problémát úgy oldja meg, hogy saját oauth-képet készít egy javítással.
Patch oauth és telepítse újra
Ehhez a következő Dockerfile-t fogjuk használni:
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" ]És így néz ki maga az rd.patch javítás
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
Most elkészítheti a képet, és behelyezheti a GitLabba. Következő be manifests/kube-dashboard-oauth2-proxy.yaml jelezze a kívánt kép használatát (cserélje ki a sajátjára):
image: docker.io/colemickens/oauth2_proxy:latestHa olyan rendszerleíró adatbázissal rendelkezik, amely felhatalmazással zárva van, ne felejtse el hozzáadni a titkosítás használatát a pull képekhez:
imagePullSecrets:
- name: gitlab-registry... és adja hozzá magát a titkot a rendszerleíró adatbázishoz:
---
apiVersion: v1
data:
.dockercfg: eyJyZWdpc3RyeS5jb21wYW55LmNvbSI6IHsKICJ1c2VybmFtZSI6ICJvYXV0aDIiLAogInBhc3N3b3JkIjogIlBBU1NXT1JEIiwKICJhdXRoIjogIkFVVEhfVE9LRU4iLAogImVtYWlsIjogIm1haWxAY29tcGFueS5jb20iCn0KfQoK
=
kind: Secret
metadata:
annotations:
name: gitlab-registry
namespace: kube-system
type: kubernetes.io/dockercfgA figyelmes olvasó látni fogja, hogy a fenti hosszú karakterlánc base64 a konfigurációból:
{"registry.company.com": {
"username": "oauth2",
"password": "PASSWORD",
"auth": "AUTH_TOKEN",
"email": "[email protected]"
}
}Ezek a felhasználói adatok a GitLab-ban, a Kubernetes kód kihúzza a képet a rendszerleíró adatbázisból.
Miután minden megtörtént, eltávolíthatja a jelenlegi (nem megfelelően működő) irányítópult-telepítést a következő paranccsal:
$ ./ctl.sh -d... és telepítsen újra mindent:
$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comItt az ideje, hogy az Irányítópultra ugorjon, és találjon egy meglehetősen archaikus bejelentkezési gombot:
A rákattintás után a GitLab fogad minket, felajánlva, hogy bejelentkezünk a megszokott oldalára (persze, ha korábban még nem jelentkeztünk be):
Bejelentkezünk a GitLab hitelesítő adataival – és minden készen áll:
Az irányítópult funkcióiról
Ha Ön olyan fejlesztő, aki korábban nem dolgozott a Kubernetes-szel, vagy egyszerűen valamilyen oknál fogva még nem találkozott a Dashboarddal, akkor bemutatok néhány képességét.
Először is láthatja, hogy „minden zöld”:
Részletesebb adatok is elérhetők a podokról, például környezeti változók, letöltött kép, indítási argumentumok és állapotuk:
A telepítéseknek látható állapotai vannak:
...és egyéb részletek:
... és lehetőség van a telepítés méretezésére is:
Ennek a műveletnek az eredménye:
A cikk elején már említett hasznos funkciók között szerepel a naplók megtekintése:
... és a kiválasztott pod tárolókonzoljába való bejelentkezéshez szükséges funkció:
Például megtekintheti a csomópontokra vonatkozó korlátokat/kéréseket is:
Természetesen ez nem a panel összes képessége, de remélem, hogy érti az általános elképzelést.
Az integráció és a műszerfal hátrányai
A leírt integrációban nincs hozzáférés-szabályozás. Ezzel minden felhasználó, aki bármilyen hozzáféréssel rendelkezik a GitLabhoz, hozzáférhet az irányítópulthoz. Ugyanolyan hozzáféréssel rendelkeznek magán az irányítópulton, ami megfelel magának az irányítópultnak a jogainak, amely . Nyilván ez nem mindenkinek megfelelő, de esetünkben elegendőnek bizonyult.
A műszerfal észrevehető hátrányai között megjegyzem a következőket:
- lehetetlen bejutni az init tároló konzoljába;
- a Deployments és StatefulSets nem szerkeszthető, bár ez a ClusterRole-ban javítható;
- A Dashboard kompatibilitása a Kubernetes legújabb verzióival és a projekt jövője kérdéseket vet fel.
Az utolsó probléma külön figyelmet érdemel.
A műszerfal állapota és alternatívák
Irányítópult kompatibilitási táblázat Kubernetes kiadásokkal, a projekt legújabb verziójában bemutatva (), nem túl boldog:
Ennek ellenére létezik (már januárban elfogadták) , amely bejelenti a K8s 1.13 támogatását. Ezenkívül a projektproblémák között találhat hivatkozásokat a K8s 1.14-es panellel dolgozó felhasználókra. Végül, a projekt kódbázisába ne hagyja abba. Tehát (legalább!) a projekt tényleges állapota nem olyan rossz, mint amilyennek a hivatalos kompatibilitási táblázatból elsőre tűnhet.
Végül az irányítópultnak vannak alternatívái. Közöttük:
- — egy fiatal interfész (az első commitok ez év márciusára nyúlnak vissza), amely már jó szolgáltatásokat kínál, mint például a fürt aktuális állapotának vizuális megjelenítése és az objektumok kezelése. „valós idejű interfészként” van elhelyezve, mert automatikusan frissíti a megjelenített adatokat anélkül, hogy frissítenie kellene az oldalt a böngészőben.
- - a Red Hat OpenShift webes felülete, amely azonban a projekt egyéb fejlesztéseit is elhozza a klaszterébe, ami nem mindenki számára megfelelő.
- egy érdekes projekt, alacsonyabb szintű (mint az irányítópult) interfészként, amely képes az összes fürt objektum megtekintésére. Úgy tűnik azonban, hogy fejlődése megállt.
- - pont a minap egy projekt, amely egyesíti egy panel funkcióit (megmutatja a fürt aktuális állapotát, de nem kezeli annak objektumait) és az automatikus „bevált gyakorlatok érvényesítését” (ellenőrzi a fürtben a benne futó Telepítések konfigurációinak helyességét).
Következtetések helyett
Az irányítópult az általunk kiszolgált Kubernetes-fürtök szabványos eszköze. A GitLabbal való integráció az alapértelmezett telepítésünk részévé is vált, mivel sok fejlesztő izgatott a panelben rejlő lehetőségek miatt.
A Kubernetes Dashboard rendszeres időközönként kínál alternatívákat a nyílt forráskódú közösségtől (és örömmel fontolgatjuk őket), de ebben a szakaszban maradunk ennél a megoldásnál.
PS
Olvassa el blogunkon is:
- «";
- «";
- «";
- «".
Forrás: will.com