Kubernetes Dashboard â njĂ« mjete e lehtĂ« pĂ«r pĂ«rdorim pĂ«r tĂ« marrĂ« informacion tĂ« pĂ«rditĂ«suar mbi klasterin nĂ« funksion dhe menaxhimin minimal tĂ« tij. E vlerĂ«son akoma mĂ« shumĂ« kur qasja nĂ« kĂ«to mundĂ«si i nevojitet jo vetĂ«m administratorĂ«ve/ inxhinierĂ«ve DevOps, por edhe atyre qĂ« nuk janĂ« zakonisht tĂ« njohur me konsolĂ«n dhe/ose nuk kanĂ« ndĂ«rmend tĂ« kuptojnĂ« tĂ« gjitha hollĂ«sitĂ« e bashkĂ«veprimit me kubectl dhe utilitetet e tjera. KĂ«shtu ndodhi edhe me ne: zhvilluesve iu dĂ«shira pĂ«r qasje tĂ« shpejtĂ« nĂ« ndĂ«rfaqen e internetit tĂ« Kubernetes, dhe duke qenĂ« se ne pĂ«rdorim GitLab, zgjidhja ishte e pashmangshme.
Pse është kjo?
Zhvilluesit e drejtpĂ«rdrejtĂ« mund tĂ« jenĂ« tĂ« interesuar nĂ« njĂ« mjet si K8s Dashboard pĂ«r detyra debugimi. NdonjĂ«herĂ« dĂ«shirohet tĂ« shikohen logjet dhe resurset, dhe pĂ«r herĂ« tjetĂ«r pĂ«r tĂ« vrarĂ« podâĂ«t, tĂ« shumfishojnĂ« Deployments/ StatefulSets dhe madje tĂ« hyjnĂ« nĂ« konsolat e konteinerĂ«ve (ndodhin edhe kĂ«rkesa tĂ« tilla, pĂ«r zgjidhjen e tĂ« cilave, megjithatĂ«, ka njĂ« rrugĂ« tjetĂ«r â pĂ«r shembull, pĂ«rmes ).
PĂ«rveç kĂ«saj, ka edhe njĂ« moment psikologjik pĂ«r drejtuesit, kur ata dĂ«shirojnĂ« tĂ« shohin klasterin â tĂ« shohin se "gjithçka Ă«shtĂ« e gjelbĂ«r" dhe kĂ«shtu tĂ« qetĂ«sohen se "gjithçka funksionon" (çka, sigurisht, Ă«shtĂ« shumĂ« relative... por kjo tashmĂ« kalon kufijtĂ« e artikullit).
Si një sistem standard CI, ne kemi GitLab: të cilin e përdorin të gjithë zhvilluesit. Prandaj, për të ofruar qasje për ta, ishte logjike të bëjmë integrimin e Dashboard-it me llogaritë në GitLab.
Gjithashtu, dua të theksoj se ne përdorim NGINX Ingress. Nëse punoni me , do të duhet të gjeni vetë analoge të anotacioneve për autorizimin.
Provoni integrimin
Instalimi i Dashboard-it
Kujdes: NĂ«se planifikoni tĂ« pĂ«rsĂ«risni hapat e pĂ«rshkruar mĂ« poshtĂ«, atĂ«herĂ« â pĂ«r tĂ« shmangur operacione tĂ« tepĂ«rta â sĂ« pari lexoni deri te nĂ«nkapitulli tjetĂ«r.
Duke qenĂ« se kjo integrim pĂ«rdoret nga ne nĂ« shumĂ« instalime, ne e automatizuam instalimin e tij. Burimet, tĂ« cilat do t'ju nevojiten pĂ«r kĂ«tĂ«, janĂ« publikuar nĂ« . NĂ« bazĂ« tĂ« tyre â konfiguracione YAML tĂ« modifikuara pak nga si dhe njĂ« skript Bash pĂ«r vendosjen e shpejtĂ«.
Skripti instalon Dashboard në klaster dhe e konfiguron atë për integrim me GitLab:
$ .\/ctl.sh
Usage: ctl.sh [OPTION]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Instaloni kubernetes-dashboard në klusterin Kubernetes.
Argumente të detyrueshme:
-i, --install instaloni në hapësirën 'kube-system'
-u, --upgrade përmirësoni instalimin ekzistues, do të ripërdorë fjalëkalimin dhe emrat e hosteve
-d, --delete hiqni gjithçka, përfshirë hapësirën
--gitlab-url vendosni URL-në e gitlab me skemë (https:\/\/gitlab.example.com)
--oauth2-id vendosni OAUTH2_PROXY_CLIENT_ID nga gitlab
--oauth2-secret vendosni OAUTH2_PROXY_CLIENT_SECRET nga gitlab
--dashboard-url vendosni URL-në e panelit pa skemë (dashboard.example.com)
Argumente opsionale:
-h, --help nxjerrni kĂ«tĂ« mesazhMegjithatĂ«, pĂ«rpara se ta pĂ«rdorni, Ă«shtĂ« e nevojshme tĂ« hyni nĂ« GitLab: Zona e Administratorit â Aplikacionet â dhe tĂ« shtoni njĂ« aplikacion tĂ« ri pĂ«r panelin qĂ« do tĂ« vijĂ«. Ta quajmĂ« atĂ« "kubernetes dashboard":
Si rezultat i shtimit të tij, GitLab do të ofrojë hash-e:
Këto do të përdoren si argumente për skriptin. Si rezultat, instalimi duket si më poshtë:
$ .\/ctl.sh -i --gitlab-url https:\/\/gitlab.example.com --oauth2-id 6a52769e⊠--oauth2-secret 6b79168f⊠--dashboard-url dashboard.example.comPas kësaj, do të kontrollojmë se gjithçka është nisur:
$ kubectl -n kube-system get pod | egrep '\(dash|oauth\)'
kubernetes-dashboard-76b55bc9f8-xpncp 1\/1 Po punon 0 14s
oauth2-proxy-5586ccf95c-czp2v 1\/1 Po punon 0 14sNjĂ«herĂ« e mirĂ« gjithçka do tĂ« nisĂ«, megjithatĂ« autorizimi menjĂ«herĂ« nuk do tĂ« funksionojĂ«! Kjo ndodh sepse nĂ« imazhin e pĂ«rdorur (situata nĂ« imazhe tĂ« tjera Ă«shtĂ« e ngjashme) procesi i kapjes sĂ« ridrejtimit nĂ« callback Ă«shtĂ« realizuar gabim. Ky rrethanĂ« bĂ«n qĂ« oauth tĂ« fshijĂ« cookie-nĂ«, tĂ« cilĂ«n e ofron vetĂ« (oauth)âŠ
Problemi zgjidhet duke ndërtuar imazhin tuaj të oauth me patch-in.
Patch-i për oauth dhe ripërshkrimi
Për këtë do të përdorim Dockerfile-in si më poshtë:
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\/\n
EXPOSE 8080 4180
ENTRYPOINT [ "/bin\/oauth2_proxy" ]
CMD [ "--upstream=http:\/\/0.0.0.0:8080\/", "--http-address=0.0.0.0:4180" ]Ja si duket patch-i në vetvete 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 "... duke testet"
-.\/test.sh
+#.\/test.sh
-for os in windows linux darwin; do
- echo "... ndërtimi i v$version për $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 "... ndërtimi i v$version për $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 Tani mund të kryejmë ndërtimin e imazhit dhe të 'botojmë' atë në GitLab tonë. Më pas në manifests/kube-dashboard-oauth2-proxy.yaml do të saktësojmë përdorimin e imazhit të nevojshëm (zëvendësojeni me tuajin):
image: docker.io/colemickens/oauth2_proxy:latestNĂ«se keni njĂ« registri tĂ« mbyllur me autorizim â mos harroni tĂ« shtoni pĂ«rdorimin e sekretit pĂ«r tĂ« marrĂ« imazhet:
imagePullSecrets:
- name: gitlab-registry⊠dhe shtoni vetë sekretin për registrin:
---
apiVersion: v1
data:
.dockercfg: eyJyZWdpc3RyeS5jb21wYW55LmNvbSI6IHsKICJ1c2VybmFtZSI6ICJvYXV0aDIiLAogInBhc3N3b3JkIjogIlBBU1NXT1JEIiwKICJhdXRoIjogIkFVVEhfVE9LRU4iLAogImVtYWlsIjogIm1haWxAY29tcGFueS5jb20iCn0KfQoK
=
kind: Secret
metadata:
annotations:
name: gitlab-registry
namespace: kube-system
type: kubernetes.io/dockercfgNjë lexues i kujdesshëm do të vërejë se stringu i gjatë i dhënë më sipër është base64 i konfigurimit:
{"registry.company.com": {
"username": "oauth2",
"password": "PASSWORD",
"auth": "AUTH_TOKEN",
"email": "mail@company.com"
}
}Këto janë të dhënat e përdoruesit në GitLab, me kodin që Kubernetes do të përdorë për të marrë imazhin nga registri.
Pasi të jetë bërë gjithçka, mund të fshijmë instalimin aktual (i pamundur për t'u ekzekutuar) të Dashboard-it me komandën:
$ .\/ctl.sh -d⊠dhe të instalojmë gjithçka nga e para:
$ .\/ctl.sh -i --gitlab-url https:\/\/gitlab.example.com --oauth2-id 6a52769e⊠--oauth2-secret 6b79168f⊠--dashboard-url dashboard.example.comKa ardhur koha për të hyrë në Dashboard dhe për të gjetur butonin mjaft arkaik të autorizimit:
Pas klikimit mbi të, do të përballemi me GitLab, e cila do të na ofrojë të autorizohemi në faqen e saj të zakonshme (sigurisht, nëse nuk ishim autorizuar më parë atje):
Autorizohemi me tĂ« dhĂ«nat e identifikimit tĂ« GitLab â dhe gjithçka Ă«shtĂ« bĂ«rĂ«:
Rreth mundësive të Dashboard-it
Nëse jeni një zhvillues që nuk keni punuar më parë me Kubernetes, ose thjesht për shkak të ndonjë arsyeje nuk keni hasur më parë me Dashboard, do të ilustroj disa nga mundësitë e tij.
Së pari, mund të shikoni se "gjithçka është e gjelbër":
Për pods, janë të disponueshme edhe të dhëna më të detajuara, si variablat e ambientit, imazhi i shkarkuar, argumentet e nisjes, gjendja e tyre:
PĂ«r deployment-et duken statuset:
⊠dhe detaje të tjera:
⊠dhe gjithashtu ka mundësinë për të shkallëzuar deployment-in:
Rezulti i kësaj operacioni:
Mes mundësive të tjera të dobishme, të përmendura tashmë në fillim të artikullit, është: shikimi i logëve:
⊠dhe funksioni i hyrjes në konsolën e kontejnerëve të pods të zgjedhur:
Gjithashtu, për shembull, mund të shikoni edhe limitet / kërkesat në nyjat:
Sigurisht, këto nuk janë të gjitha mundësitë e panelit, por shpresoj që një pamje e përgjithshme është krijuar.
Disavantazhet e integrimit dhe Dashboard
NĂ« integrimin e pĂ«rshkruar nuk ka asnjĂ« ndarje tĂ« aksesit. Me tĂ«, tĂ« gjithĂ« pĂ«rdoruesit qĂ« kanĂ« njĂ«farĂ« akses nĂ« GitLab, fitojnĂ« akses nĂ« Dashboard. Aksesi nĂ« vetĂ« Dashboard-it Ă«shtĂ« i njĂ«jtĂ« pĂ«r ta, i pĂ«rputhshĂ«m me tĂ« drejtat e vetĂ« Dashboard-it, tĂ« cilat . ĂshtĂ« e qartĂ« se kjo nuk do t'i pĂ«rshtatet tĂ« gjithĂ«ve, por pĂ«r rastin tonĂ« u tregua e mjaftueshme.
Nga disavantazhet e dukshme në vetë panelin Dashboard do të veçoja:
- nuk është e mundur të hyni në konsolën e init-kontejnerit;
- nuk është e mundur të redaktoni Deployments dhe StatefulSets, megjithatë kjo është e rregullueshme në ClusterRole;
- kompatibiliteti i Dashboard me versionet e fundit të Kubernetes dhe e ardhmja e projektit ngjallin pyetje.
Problemi i fundit meriton vëmendje të veçantë.
Statusi dhe alternativat e Dashboard
Tabelën e kompatibilitetit të Dashboard me versionet e Kubernetes, të prezantuar në versionin më të fundit të projektit (), nuk është shumë inkurajuese:
Megjithatë, ekziston (tashmë e pranuar në janar) , i cili shpall mbështetje për K8s 1.13. Për më tepër, mes issue-ve të projektit mund të gjeni përmendje nga përdorues që punojnë me panelin në K8s 1.14. Së fundmi, në bazën e kodit të projektit nuk kanë pushuar. Prandaj (të paktën!) statusi aktual i projektit nuk është aq i keq sa mund të duket në fillim nga tabela zyrtare e kompatibilitetit.
Finalmente, Dashboard ka alternativa. Ndër to:
- â njĂ« ndĂ«rfaqe e re (komitetet e para datojnĂ« nga marsi i kĂ«tij viti), tashmĂ« ofron mundĂ«si tĂ« mira, si pĂ«rfaqĂ«simi vizual i statusit aktual tĂ« grumbullit dhe menaxhimi i objekteve tĂ« tij. Pozicionohet si "ndĂ«rfaqe nĂ« kohĂ« reale", pasi automatikisht pĂ«rditĂ«son tĂ« dhĂ«nat e shfaqura, pa kĂ«rkuar rifreskimin e faqes nĂ« shfletues.
- â njĂ« ndĂ«rfaqe web nga Red Hat OpenShift, e cila megjithatĂ« do tĂ« sjellĂ« nĂ« grumbullin tuaj edhe projekte tĂ« tjera, qĂ« nuk i pĂ«rshtaten tĂ« gjithĂ«ve.
- â njĂ« projekt interesant, i krijuar si njĂ« ndĂ«rfaqe mĂ« e ulĂ«t (se Dashboard) me mundĂ«sinĂ« pĂ«r tĂ« parĂ« tĂ« gjithĂ« objektet e grumbullit. SidoqoftĂ«, duket se zhvillimi i tij Ă«shtĂ« ndalur.
- â sapo disa ditĂ« mĂ« parĂ« projekt, i cili kombinon funksionet e panelit (tregon gjendjen e tanishme tĂ« grumbullit, por nuk menaxhon objektet e tij) dhe "validimin automatik tĂ« praktikave mĂ« tĂ« mira" (kontrollon grumbullin pĂ«r saktĂ«sinĂ« e konfigurimeve tĂ« Deployments qĂ« janĂ« aktivizuar nĂ« tĂ«).
Në vend të përfundimeve
Dashboard është mjeti standard për grumbujt Kubernetes që ne mbajmë. Integrimi i tij me GitLab gjithashtu bëhet pjesë e "instalimit tonë të paracaktuar", pasi shumë zhvillues janë të lumtur me mundësitë që u ofrohen me këtë panel.
Alternativa të ndryshme për Kubernetes Dashboard shfaqen nga komuniteti Open Source (dhe ne jemi të lumtur t'i shqyrtojmë ato), megjithatë në këtë fazë mbetem me këtë zgjidhje.
P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
