Ενσωμάτωση χρηστών Kubernetes Dashboard και GitLab

Το Kubernetes Dashboard είναι ένα εύχρηστο εργαλείο για τη λήψη ενημερωμένων πληροφοριών σχετικά με ένα λειτουργικό σύμπλεγμα και την ελάχιστη διαχείριση του. Αρχίζετε να το εκτιμάτε ακόμη περισσότερο όταν χρειάζονται πρόσβαση σε αυτές τις δυνατότητες όχι μόνο από διαχειριστές/μηχανικούς DevOps, αλλά και από εκείνους που είναι λιγότερο εξοικειωμένοι με την κονσόλα ή/και δεν σκοπεύουν να ασχοληθούν με όλες τις περιπλοκές της αλληλεπίδρασης με το kubectl και άλλα βοηθητικά προγράμματα. Αυτό συνέβη σε εμάς: οι προγραμματιστές ήθελαν γρήγορη πρόσβαση στη διεπαφή ιστού Kubernetes και δεδομένου ότι χρησιμοποιούμε το GitLab, η λύση ήρθε φυσικά.

Γιατί είναι αυτό?

Οι άμεσοι προγραμματιστές μπορεί να ενδιαφέρονται για ένα εργαλείο όπως το K8s Dashboard για εργασίες εντοπισμού σφαλμάτων. Μερικές φορές θέλετε να προβάλετε αρχεία καταγραφής και πόρους και μερικές φορές να σκοτώσετε ομάδες, να κλιμακώσετε Deployments/StatefulSets, ακόμη και να μεταβείτε στην κονσόλα κοντέινερ (υπάρχουν επίσης αιτήματα για τα οποία, ωστόσο, υπάρχει άλλος τρόπος - για παράδειγμα, μέσω kubectl-debug).

Επιπλέον, υπάρχει μια ψυχολογική στιγμή για τους διευθυντές όταν θέλουν να κοιτάξουν το σύμπλεγμα - να δουν ότι "όλα είναι πράσινα", και έτσι να καθησυχάσουν τον εαυτό τους ότι "όλα λειτουργούν" (κάτι που, φυσικά, είναι πολύ σχετικό... αλλά αυτό ξεφεύγει από το πεδίο εφαρμογής του άρθρου ).

Ως τυπικό σύστημα CI έχουμε εφαρμοσμένος GitLab: όλοι οι προγραμματιστές το χρησιμοποιούν επίσης. Επομένως, για να τους παρέχεται πρόσβαση, ήταν λογικό να ενσωματωθεί ο πίνακας ελέγχου με λογαριασμούς GitLab.

Θα σημειώσω επίσης ότι χρησιμοποιούμε το NGINX Ingress. Εάν συνεργάζεστε με άλλους λύσεις εισόδου, θα χρειαστεί να βρείτε ανεξάρτητα ανάλογα σχολιασμών για εξουσιοδότηση.

Προσπάθεια ενσωμάτωσης

Εγκατάσταση ταμπλό

Προσοχή: Εάν πρόκειται να επαναλάβετε τα παρακάτω βήματα, τότε - για να αποφύγετε περιττές ενέργειες - διαβάστε πρώτα στην επόμενη υποκεφαλίδα.

Εφόσον χρησιμοποιούμε αυτήν την ενσωμάτωση σε πολλές εγκαταστάσεις, έχουμε αυτοματοποιήσει την εγκατάστασή της. Οι πηγές που απαιτούνται για αυτό δημοσιεύονται στο ειδικό αποθετήριο GitHub. Βασίζονται σε ελαφρώς τροποποιημένες διαμορφώσεις YAML από επίσημο αποθετήριο του πίνακα ελέγχου, καθώς και ένα σενάριο Bash για γρήγορη ανάπτυξη.

Το σενάριο εγκαθιστά το Dashboard στο σύμπλεγμα και το διαμορφώνει για ενσωμάτωση με το 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

Ωστόσο, πριν το χρησιμοποιήσετε, πρέπει να μεταβείτε στο GitLab: Περιοχή διαχειριστή → Εφαρμογές - και να προσθέσετε μια νέα εφαρμογή για τον μελλοντικό πίνακα. Ας το ονομάσουμε "πίνακας ελέγχου kubernetes":

Ως αποτέλεσμα της προσθήκης του, το GitLab θα παρέχει τους κατακερματισμούς:

Είναι αυτά που χρησιμοποιούνται ως επιχειρήματα στο σενάριο. Ως αποτέλεσμα, η εγκατάσταση μοιάζει με αυτό:

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

Μετά από αυτό, ας ελέγξουμε ότι όλα ξεκίνησαν:

$ 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

Ωστόσο, αργά ή γρήγορα όλα θα ξεκινήσουν η εξουσιοδότηση δεν θα λειτουργήσει αμέσως! Το γεγονός είναι ότι στην εικόνα που χρησιμοποιείται (η κατάσταση σε άλλες εικόνες είναι παρόμοια) η διαδικασία σύλληψης ανακατεύθυνσης στην επιστροφή κλήσης εφαρμόζεται εσφαλμένα. Αυτή η περίσταση οδηγεί στο γεγονός ότι η oauth διαγράφει το cookie που μας παρέχει η ίδια η oauth...

Το πρόβλημα λύνεται δημιουργώντας τη δική σας εικόνα oauth με ένα patch.

Ενημερώστε το oauth και εγκαταστήστε ξανά

Για να το κάνουμε αυτό, θα χρησιμοποιήσουμε το ακόλουθο 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" ]

Και να πώς μοιάζει η ίδια η ενημερωμένη έκδοση κώδικα 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 "... 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

Τώρα μπορείτε να δημιουργήσετε την εικόνα και να την προωθήσετε στο GitLab μας. Επόμενο μέσα manifests/kube-dashboard-oauth2-proxy.yaml υποδείξτε τη χρήση της επιθυμητής εικόνας (αντικαταστήστε την με τη δική σας):

 image: docker.io/colemickens/oauth2_proxy:latest

Εάν έχετε ένα μητρώο που είναι κλειστό με εξουσιοδότηση, μην ξεχάσετε να προσθέσετε τη χρήση ενός μυστικού για έλξη εικόνων:

      imagePullSecrets:
     - name: gitlab-registry

... και προσθέστε το ίδιο το μυστικό για το μητρώο:

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

Ο προσεκτικός αναγνώστης θα δει ότι η μακριά συμβολοσειρά παραπάνω είναι base64 από τη διαμόρφωση:

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

Αυτά είναι τα δεδομένα χρήστη στο GitLab, ο κώδικας Kubernetes θα τραβήξει την εικόνα από το μητρώο.

Αφού ολοκληρωθούν όλα, μπορείτε να καταργήσετε την τρέχουσα (δεν λειτουργεί σωστά) εγκατάσταση του πίνακα εργαλείων με την εντολή:

$ ./ctl.sh -d

... και εγκαταστήστε ξανά τα πάντα:

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

Ήρθε η ώρα να μεταβείτε στον Πίνακα ελέγχου και να βρείτε ένα μάλλον αρχαϊκό κουμπί σύνδεσης:

Αφού κάνουμε κλικ σε αυτό, το GitLab θα μας χαιρετήσει, προσφέροντάς μας να συνδεθείτε στη συνηθισμένη του σελίδα (φυσικά, εάν δεν έχουμε συνδεθεί προηγουμένως εκεί):

Συνδεόμαστε με διαπιστευτήρια GitLab - και όλα γίνονται:

Σχετικά με τις δυνατότητες του πίνακα ελέγχου

Εάν είστε προγραμματιστής που δεν έχετε δουλέψει με το Kubernetes στο παρελθόν ή απλά για κάποιο λόγο δεν έχετε συναντήσει το Dashboard στο παρελθόν, θα σας παρουσιάσω μερικές από τις δυνατότητές του.

Πρώτον, μπορείτε να δείτε ότι "όλα είναι πράσινα":

Πιο λεπτομερή δεδομένα είναι επίσης διαθέσιμα για τα pod, όπως μεταβλητές περιβάλλοντος, εικόνα λήψης, ορίσματα εκκίνησης και κατάστασή τους:

Οι αναπτύξεις έχουν ορατές καταστάσεις:

...και άλλες λεπτομέρειες:

... και υπάρχει επίσης η δυνατότητα κλιμάκωσης της ανάπτυξης:

Το αποτέλεσμα αυτής της επέμβασης:

Μεταξύ άλλων χρήσιμων λειτουργιών που αναφέρθηκαν ήδη στην αρχή του άρθρου είναι η προβολή αρχείων καταγραφής:

... και τη συνάρτηση σύνδεσης στην κονσόλα κοντέινερ του επιλεγμένου pod:

Για παράδειγμα, μπορείτε επίσης να δείτε τα όρια/αιτήματα στους κόμβους:

Φυσικά, αυτές δεν είναι όλες οι δυνατότητες του πάνελ, αλλά ελπίζω να έχετε τη γενική ιδέα.

Μειονεκτήματα ενσωμάτωσης και ταμπλό

Στην περιγραφόμενη ενσωμάτωση δεν υπάρχει έλεγχος πρόσβασης. Με αυτό, όλοι οι χρήστες με οποιαδήποτε πρόσβαση στο GitLab αποκτούν πρόσβαση στον Πίνακα ελέγχου. Έχουν την ίδια πρόσβαση στο ίδιο το Dashboard, που αντιστοιχεί στα δικαιώματα του ίδιου του Dashboard, το οποίο ορίζονται στο RBAC. Προφανώς, αυτό δεν είναι κατάλληλο για όλους, αλλά για την περίπτωσή μας αποδείχθηκε επαρκής.

Μεταξύ των αξιοσημείωτων μειονεκτημάτων στον ίδιο τον πίνακα εργαλείων, σημειώνω τα εξής:

• είναι αδύνατο να μπείτε στην κονσόλα του κοντέινερ έναρξης.
• Είναι αδύνατο να επεξεργαστείτε Deployments και StatefulSets, αν και αυτό μπορεί να διορθωθεί στο ClusterRole.
• Η συμβατότητα του Dashboard με τις τελευταίες εκδόσεις του Kubernetes και το μέλλον του έργου εγείρουν ερωτήματα.

Το τελευταίο πρόβλημα αξίζει ιδιαίτερης προσοχής.

Κατάσταση πίνακα ελέγχου και εναλλακτικές λύσεις

Πίνακας συμβατότητας πίνακα ελέγχου με εκδόσεις Kubernetes, που παρουσιάζεται στην τελευταία έκδοση του έργου (v1.10.1), όχι πολύ χαρούμενος:

Παρόλα αυτά, υπάρχει (που έχει ήδη εγκριθεί τον Ιανουάριο) PR # 3476, το οποίο ανακοινώνει υποστήριξη για K8s 1.13. Επιπλέον, μεταξύ των προβλημάτων του έργου μπορείτε να βρείτε αναφορές σε χρήστες που εργάζονται με τον πίνακα στο K8s 1.14. Τελικά, δεσμεύεται στη βάση κώδικα του έργου μην σταματήσετε. Έτσι (τουλάχιστον!) η πραγματική κατάσταση του έργου δεν είναι τόσο κακή όσο φαίνεται αρχικά από τον επίσημο πίνακα συμβατότητας.

Τέλος, υπάρχουν εναλλακτικές λύσεις για το Dashboard. Ανάμεσα τους:

1. K8Dash — μια νεανική διεπαφή (τα πρώτα commits χρονολογούνται από τον Μάρτιο του τρέχοντος έτους), η οποία ήδη προσφέρει καλά χαρακτηριστικά, όπως οπτική αναπαράσταση της τρέχουσας κατάστασης του συμπλέγματος και διαχείριση των αντικειμένων του. Τοποθετείται ως "διεπαφή σε πραγματικό χρόνο", επειδή ενημερώνει αυτόματα τα εμφανιζόμενα δεδομένα χωρίς να απαιτεί από εσάς να ανανεώσετε τη σελίδα στο πρόγραμμα περιήγησης.
2. Κονσόλα OpenShift - μια διεπαφή ιστού από το Red Hat OpenShift, η οποία, ωστόσο, θα φέρει άλλες εξελίξεις του έργου στο σύμπλεγμα σας, το οποίο δεν είναι κατάλληλο για όλους.
3. Kubernator είναι ένα ενδιαφέρον έργο, που δημιουργήθηκε ως διεπαφή χαμηλότερου επιπέδου (από τον πίνακα ελέγχου) με δυνατότητα προβολής όλων των αντικειμένων συμπλέγματος. Ωστόσο, φαίνεται ότι η ανάπτυξή του έχει σταματήσει.
4. Polaris - μόλις την άλλη μέρα ανακοινώθηκε ένα έργο που συνδυάζει τις λειτουργίες ενός πάνελ (εμφανίζει την τρέχουσα κατάσταση του συμπλέγματος, αλλά δεν διαχειρίζεται τα αντικείμενά του) και αυτόματη "επικύρωση βέλτιστων πρακτικών" (ελέγχει το σύμπλεγμα για την ορθότητα των διαμορφώσεων των Deployments που εκτελούνται σε αυτό).

Αντί για συμπεράσματα

Το Dashboard είναι ένα τυπικό εργαλείο για τα συμπλέγματα Kubernetes που εξυπηρετούμε. Η ενσωμάτωσή του με το GitLab έχει γίνει επίσης μέρος της προεπιλεγμένης εγκατάστασης, καθώς πολλοί προγραμματιστές είναι ενθουσιασμένοι με τις δυνατότητες που έχουν με αυτό το πάνελ.

Το Kubernetes Dashboard έχει περιοδικά εναλλακτικές λύσεις από την κοινότητα ανοιχτού κώδικα (και είμαστε στην ευχάριστη θέση να τις εξετάσουμε), αλλά σε αυτό το στάδιο παραμένουμε σε αυτήν τη λύση.

PS

Διαβάστε επίσης στο blog μας:

• «kubebox και άλλα κοχύλια για Kubernetes"?
• «Βέλτιστες πρακτικές CI/CD με το Kubernetes και το GitLab (επισκόπηση και αναφορά βίντεο)"?
• «Δημιουργήστε και αναπτύξτε εφαρμογές στο Kubernetes χρησιμοποιώντας dapp και GitLab CI"?
• «GitLab CI για συνεχή ενσωμάτωση και παράδοση στην παραγωγή. Μέρος 1: ο αγωγός μας».

Πηγή: www.habr.com