„Kubernetes“ prietaisų skydelio ir „GitLab“ vartotojų integravimas

„Kubernetes“ prietaisų skydelis yra paprastas naudoti įrankis, leidžiantis gauti naujausią informaciją apie veikiančią grupę ir ją valdyti su minimaliomis pastangomis. Jūs pradedate tai dar labiau vertinti, kai prieigos prie šių galimybių reikia ne tik administratoriams / „DevOps“ inžinieriams, bet ir tiems, kurie yra mažiau pripratę prie konsolės ir (arba) neketina susidoroti su visomis sąveikos su kubectl ir kitos komunalinės paslaugos. Taip atsitiko su mumis: kūrėjai norėjo greitos prieigos prie Kubernetes žiniatinklio sąsajos, o kadangi mes naudojame GitLab, sprendimas atsirado natūraliai.

Kodėl tai?

Tiesioginiai kūrėjai gali būti suinteresuoti tokiu įrankiu kaip „K8s Dashboard“, skirtu derinimo užduotims atlikti. Kartais norite peržiūrėti žurnalus ir išteklius, o kartais sunaikinti blokus, keisti diegimo / būsenos rinkinių mastelį ir net eiti į konteinerio konsolę (taip pat yra tokių užklausų, tačiau yra ir kitas būdas – pavyzdžiui, per kubectl-debug).

Be to, vadovams ateina psichologinis momentas, kai norisi pažvelgti į klasterį – pamatyti, kad „viskas žalia“, ir taip save nuraminti, kad „viskas veikia“ (kas, žinoma, labai reliatyvu... bet tai nepatenka į straipsnio taikymo sritį).

Turime standartinę CI sistemą taikoma GitLab: visi kūrėjai taip pat jį naudoja. Todėl norint suteikti jiems prieigą, buvo logiška integruoti informacijos suvestinę su „GitLab“ paskyromis.

Taip pat atkreipsiu dėmesį, kad naudojame NGINX Ingress. Jei dirbate su kitais patekimo sprendimai, turėsite savarankiškai rasti anotacijų analogus autorizacijai gauti.

Bando integruotis

Prietaisų skydelio montavimas

Dėmesio: Jei ketinate kartoti toliau nurodytus veiksmus, pirmiausia perskaitykite kitą paantraštę, kad išvengtumėte nereikalingų operacijų.

Kadangi šią integraciją naudojame daugelyje įrenginių, automatizavome jos diegimą. Tam reikalingi šaltiniai skelbiami m speciali „GitHub“ saugykla. Jie pagrįsti šiek tiek pakeistomis YAML konfigūracijomis iš oficiali prietaisų skydelio saugykla, taip pat „Bash“ scenarijų greitam diegimui.

Scenarijus įdiegia informacijos suvestinę klasteryje ir sukonfigūruoja ją integracijai su „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

Tačiau prieš naudodami turite eiti į GitLab: Admin area → Applications - ir pridėti naują programą būsimam skydeliui. Pavadinkime tai „kubernetes prietaisų skydeliu“:

Pridėjus jį, „GitLab“ pateiks maišos:

Būtent jie naudojami kaip scenarijaus argumentai. Dėl to diegimas atrodo taip:

$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.com

Po to patikrinkime, ar viskas prasidėjo:

$ 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

Tačiau anksčiau ar vėliau viskas prasidės leidimas neveiks iš karto! Faktas yra tas, kad naudojamame vaizde (kituose paveikslėliuose situacija panaši) peradresavimo sugavimo procesas atgalinio skambučio metu įgyvendintas neteisingai. Ši aplinkybė lemia tai, kad oauth ištrina slapuką, kurį pats oauth mums pateikia...

Problema išspręsta sukuriant savo oauth vaizdą su pataisu.

Pataisykite oauth ir įdiekite iš naujo

Norėdami tai padaryti, naudosime šį 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" ]

Ir štai kaip atrodo pats rd.patch pleistras

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

Dabar galite sukurti vaizdą ir perkelti jį į mūsų „GitLab“. Kitas manifests/kube-dashboard-oauth2-proxy.yaml nurodykite norimo vaizdo naudojimą (pakeiskite jį savo):

 image: docker.io/colemickens/oauth2_proxy:latest

Jei turite registrą, kuris uždarytas autorizuojant, nepamirškite pridėti paslapties naudojimo vaizdams ištraukti:

      imagePullSecrets:
     - name: gitlab-registry

... ir pridėkite pačią registro paslaptį:

---
apiVersion: v1
data:
 .dockercfg: eyJyZWdpc3RyeS5jb21wYW55LmNvbSI6IHsKICJ1c2VybmFtZSI6ICJvYXV0aDIiLAogInBhc3N3b3JkIjogIlBBU1NXT1JEIiwKICJhdXRoIjogIkFVVEhfVE9LRU4iLAogImVtYWlsIjogIm1haWxAY29tcGFueS5jb20iCn0KfQoK
=
kind: Secret
metadata:
 annotations:
 name: gitlab-registry
 namespace: kube-system
type: kubernetes.io/dockercfg

Dėmesingas skaitytojas pamatys, kad aukščiau esanti ilga eilutė yra base64 iš konfigūracijos:

{"registry.company.com": {
 "username": "oauth2",
 "password": "PASSWORD",
 "auth": "AUTH_TOKEN",
 "email": "[email protected]"
}
}

Tai yra „GitLab“ vartotojo duomenys, „Kubernetes“ kodas ištrauks vaizdą iš registro.

Viską atlikę galite pašalinti dabartinį (neveikiantį) prietaisų skydelio diegimą naudodami komandą:

$ ./ctl.sh -d

... ir įdiekite viską iš naujo:

$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.com

Atėjo laikas eiti į prietaisų skydelį ir rasti gana archajišką prisijungimo mygtuką:

Paspaudus ant jo, GitLab pasisveikina, siūlydamas prisijungti prie savo įprasto puslapio (žinoma, jei anksčiau ten nebuvome prisijungę):

Prisijungiame naudodami „GitLab“ kredencialus – ir viskas padaryta:

Apie prietaisų skydelio funkcijas

Jei esate kūrėjas, kuris anksčiau nedirbo su Kubernetes arba tiesiog dėl kokių nors priežasčių anksčiau nesusidūrėte su Dashboard, pavaizduosiu kai kurias jos galimybes.

Pirma, galite pamatyti, kad „viskas žalia“:

Taip pat galima gauti išsamesnių duomenų apie rinkinius, tokius kaip aplinkos kintamieji, atsisiųstas vaizdas, paleidimo argumentai ir jų būsena:

Diegimo būsenos yra matomos:

...ir kita informacija:

... ir taip pat yra galimybė išplėsti diegimą:

Šios operacijos rezultatas:

Tarp kitų naudingų funkcijų, jau minėtų straipsnio pradžioje, yra žurnalų peržiūra:

... ir funkcija prisijungti prie pasirinkto rinkinio konteinerio konsolės:

Pavyzdžiui, taip pat galite peržiūrėti mazgų apribojimus / užklausas:

Žinoma, tai dar ne visos skydelio galimybės, bet tikiuosi, kad suprasite bendrą idėją.

Integravimo ir prietaisų skydelio trūkumai

Apibūdintoje integracijoje nėra prieigos kontrolė. Su juo visi vartotojai, turintys bet kokią prieigą prie „GitLab“, gauna prieigą prie informacijos suvestinės. Jie turi tą pačią prieigą prie informacijos suvestinės, atitinkančios pačios prietaisų skydelio teises, kurios yra apibrėžti RBAC. Akivaizdu, kad tai netinka visiems, bet mūsų atveju to pakanka.

Tarp pastebimų paties prietaisų skydelio trūkumų atkreipiu dėmesį į šiuos dalykus:

• neįmanoma patekti į init konteinerio konsolę;
• neįmanoma redaguoti Deployments ir StatefulSets, nors tai gali būti ištaisyta naudojant ClusterRole;
• Informacijos suvestinės suderinamumas su naujausiomis Kubernetes versijomis ir projekto ateitis kelia klausimų.

Paskutinė problema nusipelno ypatingo dėmesio.

Prietaisų skydelio būsena ir alternatyvos

Prietaisų skydelio suderinamumo lentelė su Kubernetes leidimais, pateikta naujausioje projekto versijoje (v1.10.1), nelabai patenkintas:

Nepaisant to, yra (jau priimtas sausio mėn.) PR Nr. 3476, kuriame skelbiama apie K8s 1.13 palaikymą. Be to, tarp projekto problemų galite rasti nuorodų į vartotojus, dirbančius su skydeliu K8s 1.14 versijoje. Pagaliau, įsipareigoja į projekto kodų bazę nesustoja. Taigi (bent jau!) tikroji projekto būsena nėra tokia bloga, kaip iš pradžių gali pasirodyti iš oficialios suderinamumo lentelės.

Galiausiai yra informacijos suvestinės alternatyvų. Tarp jų:

1. K8Dash — jauna sąsaja (pirmieji įsipareigojimai datuojami šių metų kovo mėnesį), kuri jau siūlo gerų funkcijų, tokių kaip vaizdinis esamos klasterio būsenos vaizdas ir jos objektų valdymas. Padėtas kaip „realaus laiko sąsaja“, nes automatiškai atnaujina rodomus duomenis, nereikalaujant atnaujinti puslapio naršyklėje.
2. „OpenShift“ konsolė - „Red Hat OpenShift“ žiniatinklio sąsaja, kuri vis dėlto į jūsų klasterį atneš kitus projekto patobulinimus, kurie netinka visiems.
3. Kubernatorius yra įdomus projektas, sukurtas kaip žemesnio lygio (nei informacijos suvestinė) sąsaja su galimybe peržiūrėti visus klasterio objektus. Tačiau panašu, kad jo plėtra sustojo.
4. Polaris – tik kitą dieną paskelbė projektas, apjungiantis skydelio funkcijas (rodo esamą klasterio būseną, bet nevaldo jo objektų) ir automatinį „geriausios praktikos patvirtinimą“ (tikrina klasterį, ar jame veikiančių diegimų konfigūracijos yra teisingos).

Vietoj išvadų

Informacijos suvestinė yra standartinis mūsų aptarnaujamų „Kubernetes“ grupių įrankis. Jo integravimas su „GitLab“ taip pat tapo mūsų numatytojo diegimo dalimi, nes daugelis kūrėjų džiaugiasi šio skydelio teikiamomis galimybėmis.

„Kubernetes Dashboard“ periodiškai turi alternatyvų iš atvirojo kodo bendruomenės (ir mes mielai jas svarstome), tačiau šiame etape liekame prie šio sprendimo.

PS

Taip pat skaitykite mūsų tinklaraštyje:

• «kubebox ir kiti Kubernetes apvalkalai»;
• «Geriausia CI / CD praktika naudojant „Kubernetes“ ir „GitLab“ (apžvalga ir vaizdo reportažas)»;
• «Kurkite ir įdiekite programas Kubernetes naudodami dapp ir GitLab CI»;
• «GitLab CI nuolatiniam integravimui ir pristatymui gamyboje. 1 dalis: mūsų vamzdynas".

Šaltinis: www.habr.com