Kubernetes Dashboard და GitLab მომხმარებლების ინტეგრაცია

Kubernetes Dashboard არის ადვილად გამოსაყენებელი ინსტრუმენტი თქვენი გაშვებული კლასტერის შესახებ განახლებული ინფორმაციის მისაღებად და მინიმალური ძალისხმევით მისი მართვისთვის. თქვენ უფრო მეტად იწყებთ მის შეფასებას, როდესაც ამ შესაძლებლობებზე წვდომა სჭირდებათ არა მხოლოდ ადმინისტრატორებს/DevOps ინჟინრებს, არამედ მათაც, ვინც ნაკლებად არის მიჩვეული კონსოლს და/ან არ აპირებს გაუმკლავდეს kubectl-თან და ინტერაქციის ყველა სირთულეს. სხვა კომუნალური საშუალებები. ეს მოხდა ჩვენთან: დეველოპერებს სურდათ სწრაფი წვდომა Kubernetes ვებ ინტერფეისზე და რადგან ჩვენ ვიყენებთ GitLab-ს, გამოსავალი ბუნებრივია.

Რატომ არის ეს?

პირდაპირი დეველოპერები შეიძლება დაინტერესდნენ ისეთი ინსტრუმენტით, როგორიცაა K8s Dashboard ამოცანების გამართვისთვის. ხანდახან გსურთ იხილოთ ჟურნალები და რესურსები, ხანდახან მოკლათ პოდები, გააფართოვოთ Deployments/StatefulSets და გადახვიდეთ კონტეინერის კონსოლზეც (ასევე არის მოთხოვნები, რომელთათვისაც, თუმცა, არსებობს სხვა გზა - მაგალითად, მეშვეობით kubectl-debug).

გარდა ამისა, მენეჯერებს აქვთ ფსიქოლოგიური მომენტი, როცა სურთ კლასტერს შეხედონ - დაინახონ, რომ „ყველაფერი მწვანეა“ და ამით დაამშვიდონ თავი, რომ „ყველაფერი მუშაობს“ (რაც, რა თქმა უნდა, ძალიან ფარდობითია... მაგრამ ეს სცილდება სტატიის ფარგლებს).

როგორც სტანდარტული CI სისტემა გვაქვს გამოყენებითი GitLab: ყველა დეველოპერი ასევე იყენებს მას. ამიტომ, მათთვის წვდომის უზრუნველსაყოფად, ლოგიკური იყო Dashboard-ის ინტეგრირება 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-ში: Admin area → Applications - და დაამატოთ ახალი აპლიკაცია მომავალი პანელისთვის. მოდით ვუწოდოთ მას "კუბერნეტის დაფა":

მისი დამატების შედეგად, 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 წაშლის ქუქი-ფაილს, რომელსაც თავად oauth გვაწვდის...

პრობლემა მოგვარებულია საკუთარი oauth სურათის შექმნით პატჩით.

დააყენეთ 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

დროა გადახვიდეთ Dashboard-ზე და იპოვოთ საკმაოდ არქაული შესვლის ღილაკი:

მასზე დაწკაპუნების შემდეგ, GitLab მოგვესალმება და გვთავაზობს შეხვიდეთ ჩვეულებრივ გვერდზე (რა თქმა უნდა, თუ აქამდე არ ვართ შესული):

ჩვენ შევდივართ GitLab სერთიფიკატებით - და ყველაფერი კეთდება:

დაფის მახასიათებლების შესახებ

თუ თქვენ ხართ დეველოპერი, რომელიც ადრე არ უმუშავია Kubernetes-თან, ან უბრალოდ რაიმე მიზეზით არ შეხვედრიათ Dashboard-ს, მე ილუსტრირებას გავაკეთებ მის ზოგიერთ შესაძლებლობებზე.

პირველ რიგში, თქვენ ხედავთ, რომ "ყველაფერი მწვანეა":

უფრო დეტალური მონაცემები ასევე ხელმისაწვდომია პოდებისთვის, როგორიცაა გარემოს ცვლადები, გადმოწერილი სურათი, გაშვების არგუმენტები და მათი მდგომარეობა:

განლაგებას აქვს ხილული სტატუსები:

...და სხვა დეტალები:

... და ასევე არის განლაგების მასშტაბის შესაძლებლობა:

ამ ოპერაციის შედეგი:

სტატიის დასაწყისში უკვე ნახსენები სხვა სასარგებლო ფუნქციებს შორის არის ჟურნალების ნახვა:

... და არჩეული პოდის კონტეინერის კონსოლში შესვლის ფუნქცია:

მაგალითად, თქვენ ასევე შეგიძლიათ ნახოთ კვანძების ლიმიტები/მოთხოვნები:

რა თქმა უნდა, ეს არ არის პანელის ყველა შესაძლებლობა, მაგრამ იმედი მაქვს, რომ თქვენ მიიღებთ ზოგად იდეას.

ინტეგრაციის და Dashboard-ის ნაკლოვანებები

აღწერილ ინტეგრაციაში არ არსებობს წვდომის კონტროლი. მასთან ერთად, GitLab-ზე ნებისმიერი წვდომის მქონე მომხმარებელი იღებს წვდომას Dashboard-ზე. მათ აქვთ იგივე წვდომა თავად Dashboard-ში, რაც შეესაბამება თავად Dashboard-ის უფლებებს, რაც განსაზღვრულია RBAC-ში. ცხადია, ეს ყველასთვის შესაფერისი არ არის, მაგრამ ჩვენი შემთხვევისთვის ეს საკმარისი აღმოჩნდა.

თავად Dashboard-ის შესამჩნევ ნაკლოვანებებს შორის მე აღვნიშნავ შემდეგს:

• შეუძლებელია საწყის კონტეინერის კონსოლში მოხვედრა;
• შეუძლებელია Deployments და StatefulSets-ის რედაქტირება, თუმცა ამის დაფიქსირება შესაძლებელია ClusterRole-ში;
• Dashboard-ის თავსებადობა Kubernetes-ის უახლეს ვერსიებთან და პროექტის მომავალი აჩენს კითხვებს.

ბოლო პრობლემა განსაკუთრებულ ყურადღებას იმსახურებს.

დაფის სტატუსი და ალტერნატივები

Dashboard თავსებადობის ცხრილი Kubernetes-ის გამოშვებებთან, წარმოდგენილია პროექტის უახლეს ვერსიაში (v1.10.1), არც თუ ისე ბედნიერი:

ამის მიუხედავად, არსებობს (უკვე მიღებული იანვარში) PR #3476, რომელიც აცხადებს მხარდაჭერას K8s 1.13-ისთვის. გარდა ამისა, პროექტის საკითხებს შორის შეგიძლიათ იპოვოთ მითითებები პანელთან მომუშავე მომხმარებლების შესახებ K8s 1.14-ში. ბოლოს და ბოლოს, ახორციელებს პროექტის კოდის ბაზაში არ შეჩერდეთ. ასე რომ (ყოველ შემთხვევაში!) პროექტის რეალური სტატუსი არ არის ისეთი ცუდი, როგორც ეს შეიძლება ჩანდეს ოფიციალური თავსებადობის ცხრილიდან.

დაბოლოს, არსებობს Dashboard-ის ალტერნატივები. Მათ შორის:

1. K8Dash — ახალგაზრდა ინტერფეისი (პირველი შეთანხმებები თარიღდება მიმდინარე წლის მარტში), რომელიც უკვე გვთავაზობს კარგ ფუნქციებს, როგორიცაა კლასტერის ამჟამინდელი სტატუსის ვიზუალური წარმოდგენა და მისი ობიექტების მართვა. განლაგებულია როგორც "რეალურ დროში ინტერფეისი", რადგან ავტომატურად განაახლებს ნაჩვენები მონაცემების ბრაუზერში გვერდის განახლების მოთხოვნის გარეშე.
2. OpenShift კონსოლი - ვებ ინტერფეისი Red Hat OpenShift-ისგან, რომელიც, თუმცა, თქვენს კლასტერში შემოიტანს პროექტის სხვა განვითარებას, რომელიც ყველასთვის შესაფერისი არ არის.
3. კუბერნატორი არის საინტერესო პროექტი, შექმნილი როგორც ქვედა დონის (დაფაზე) ინტერფეისი ყველა კლასტერული ობიექტის ნახვის შესაძლებლობით. თუმცა, როგორც ჩანს, მისი განვითარება შეჩერებულია.
4. Polaris - მხოლოდ მეორე დღეს გამოაცხადა პროექტი, რომელიც აერთიანებს პანელის ფუნქციებს (გვიჩვენებს კლასტერის ამჟამინდელ მდგომარეობას, მაგრამ არ მართავს მის ობიექტებს) და ავტომატურ „საუკეთესო პრაქტიკის შემოწმებას“ (ამოწმებს კლასტერს მასში გაშვებული Deployments-ის კონფიგურაციის სისწორისთვის).

დასკვნების ნაცვლად

Dashboard არის სტანდარტული ინსტრუმენტი Kubernetes კლასტერებისთვის, რომლებსაც ჩვენ ვემსახურებით. GitLab-თან მისი ინტეგრაცია ასევე გახდა ჩვენი ნაგულისხმევი ინსტალაციის ნაწილი, რადგან ბევრი დეველოპერი აღფრთოვანებულია ამ პანელის შესაძლებლობებით.

Kubernetes Dashboard-ს პერიოდულად აქვს ალტერნატივები ღია კოდის საზოგადოებისგან (და ჩვენ სიამოვნებით განვიხილავთ მათ), მაგრამ ამ ეტაპზე ჩვენ ვრჩებით ამ გადაწყვეტაზე.

PS

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «kubebox და სხვა ჭურვები Kubernetes-ისთვის";
• «საუკეთესო CI/CD პრაქტიკა Kubernetes-თან და GitLab-თან (მიმოხილვა და ვიდეო ანგარიში)";
• «შექმენით და განათავსეთ აპლიკაციები Kubernetes-ში dapp-ისა და GitLab CI-ის გამოყენებით";
• «GitLab CI წარმოებაში უწყვეტი ინტეგრაციისა და მიწოდებისთვის. ნაწილი 1: ჩვენი მილსადენი".

წყარო: www.habr.com