🥇การบูรณาการผู้ใช้ Kubernetes Dashboard และ GitLab

Kubernetes Dashboard เป็นเครื่องมือที่ใช้งานง่ายสำหรับรับข้อมูลล่าสุดเกี่ยวกับคลัสเตอร์ที่ทำงานอยู่และจัดการคลัสเตอร์โดยใช้ความพยายามเพียงเล็กน้อย คุณจะเริ่มรู้สึกประทับใจมากยิ่งขึ้นเมื่อการเข้าถึงคุณลักษณะเหล่านี้เป็นสิ่งจำเป็น ไม่เพียงแต่โดยผู้ดูแลระบบ/วิศวกร DevOps เท่านั้น แต่ยังรวมถึงผู้ที่ไม่คุ้นเคยกับคอนโซลด้วย และ/หรือไม่ได้ตั้งใจที่จะจัดการกับความซับซ้อนทั้งหมดของการโต้ตอบกับ kubectl และ สาธารณูปโภคอื่น ๆ สิ่งนี้เกิดขึ้นกับเรา: นักพัฒนาต้องการเข้าถึงเว็บอินเทอร์เฟซ Kubernetes อย่างรวดเร็ว และเนื่องจากเราใช้ GitLab วิธีแก้ปัญหาจึงเกิดขึ้นอย่างเป็นธรรมชาติ

ทำไมเป็นเช่นนี้?

นักพัฒนาโดยตรงอาจสนใจเครื่องมือเช่น K8s Dashboard สำหรับงานแก้ไขข้อบกพร่อง บางครั้งคุณต้องการดูบันทึกและทรัพยากร และบางครั้งก็ฆ่าพ็อด ปรับขนาด Deployments/StatefulSets และแม้กระทั่งไปที่คอนเทนเนอร์คอนโซล (ยังมีคำขอดังกล่าวด้วย ซึ่งอย่างไรก็ตาม มีวิธีอื่น - ตัวอย่างเช่น ผ่าน kubectl-debug).

นอกจากนี้ ยังมีช่วงเวลาทางจิตวิทยาสำหรับผู้จัดการเมื่อพวกเขาต้องการดูคลัสเตอร์ - เพื่อดูว่า "ทุกอย่างเป็นสีเขียว" และทำให้มั่นใจว่า "ทุกอย่างทำงานได้ดี" (ซึ่งแน่นอนว่ามีความสัมพันธ์กันมาก... แต่นี่อยู่นอกเหนือขอบเขตของบทความ)

เป็นระบบ CI มาตรฐานที่เรามี นำไปใช้ GitLab: นักพัฒนาทุกคนก็ใช้มันเช่นกัน ดังนั้น เพื่อให้พวกเขาเข้าถึงได้ จึงสมเหตุสมผลที่จะรวมแดชบอร์ดเข้ากับบัญชี GitLab

ฉันจะทราบด้วยว่าเราใช้ NGINX Ingress หากคุณทำงานร่วมกับผู้อื่น โซลูชั่นทางเข้าคุณจะต้องค้นหาแอนะล็อกของคำอธิบายประกอบเพื่อขออนุญาตโดยอิสระ

กำลังพยายามบูรณาการ

การติดตั้งแดชบอร์ด

ความระมัดระวัง: หากคุณกำลังจะทำซ้ำขั้นตอนด้านล่าง เพื่อหลีกเลี่ยงการดำเนินการที่ไม่จำเป็น ให้อ่านหัวข้อย่อยถัดไปก่อน

เนื่องจากเราใช้การผสานรวมนี้ในการติดตั้งจำนวนมาก เราจึงทำการติดตั้งโดยอัตโนมัติ แหล่งที่มาที่จำเป็นสำหรับสิ่งนี้มีการเผยแพร่ใน พื้นที่เก็บข้อมูล GitHub พิเศษ. ขึ้นอยู่กับการกำหนดค่า YAML ที่แก้ไขเล็กน้อยจาก พื้นที่เก็บข้อมูลแดชบอร์ดอย่างเป็นทางการรวมถึงสคริปต์ Bash เพื่อการปรับใช้ที่รวดเร็ว

สคริปต์จะติดตั้งแดชบอร์ดในคลัสเตอร์และกำหนดค่าสำหรับการทำงานร่วมกับ 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 จะลบคุกกี้ที่ 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

ได้เวลาไปที่แดชบอร์ดแล้วค้นหาปุ่มเข้าสู่ระบบที่ค่อนข้างโบราณ:

หลังจากคลิกที่มัน GitLab จะทักทายเราโดยเสนอให้เข้าสู่หน้าปกติ (แน่นอนถ้าเราไม่เคยเข้าสู่ระบบมาก่อน):

เราเข้าสู่ระบบด้วยข้อมูลรับรอง GitLab - และทุกอย่างก็เสร็จสิ้น:

เกี่ยวกับคุณสมบัติแดชบอร์ด

หากคุณเป็นนักพัฒนาที่ไม่เคยทำงานกับ Kubernetes มาก่อน หรือไม่เคยพบ Dashboard มาก่อนด้วยเหตุผลบางประการ ฉันจะอธิบายความสามารถบางอย่างของมัน

ประการแรก คุณจะเห็นว่า “ทุกอย่างเป็นสีเขียว”:

นอกจากนี้ยังมีข้อมูลโดยละเอียดเพิ่มเติมสำหรับพ็อด เช่น ตัวแปรสภาพแวดล้อม ภาพที่ดาวน์โหลด อาร์กิวเมนต์การเรียกใช้ และสถานะ:

การปรับใช้มีสถานะที่มองเห็นได้:

...และรายละเอียดอื่นๆ:

... และยังมีความสามารถในการปรับขนาดการใช้งานอีกด้วย:

ผลลัพธ์ของการดำเนินการนี้:

ในบรรดาคุณสมบัติที่มีประโยชน์อื่น ๆ ที่กล่าวถึงแล้วในตอนต้นของบทความคือการดูบันทึก:

... และฟังก์ชันในการล็อกอินเข้าสู่คอนโซลคอนเทนเนอร์ของพ็อดที่เลือก:

ตัวอย่างเช่น คุณสามารถดูขีดจำกัด/คำขอบนโหนดได้:

แน่นอนว่านี่ไม่ใช่ความสามารถทั้งหมดของแผงควบคุม แต่ฉันหวังว่าคุณจะเข้าใจแนวคิดทั่วไป

ข้อเสียของการรวมและแดชบอร์ด

ในการบูรณาการที่อธิบายไว้ไม่มี การควบคุมการเข้าถึง. ด้วยเหตุนี้ ผู้ใช้ทุกคนที่มีสิทธิ์เข้าถึง GitLab จะสามารถเข้าถึงแดชบอร์ดได้ พวกเขามีสิทธิ์เข้าถึงแดชบอร์ดเหมือนกัน ซึ่งสอดคล้องกับสิทธิ์ของแดชบอร์ดเอง ถูกกำหนดไว้ใน RBAC. แน่นอนว่าสิ่งนี้ไม่เหมาะสำหรับทุกคน แต่สำหรับกรณีของเรามันก็เพียงพอแล้ว

ท่ามกลางข้อเสียที่เห็นได้ชัดเจนในแดชบอร์ด ฉันสังเกตเห็นสิ่งต่อไปนี้:

เป็นไปไม่ได้ที่จะเข้าไปในคอนโซลของคอนเทนเนอร์ init
เป็นไปไม่ได้ที่จะแก้ไข Deployments และ StatefulSets แม้ว่าสามารถแก้ไขได้ใน ClusterRole
ความเข้ากันได้ของแดชบอร์ดกับ Kubernetes เวอร์ชันล่าสุดและอนาคตของโครงการทำให้เกิดคำถาม

ปัญหาสุดท้ายสมควรได้รับความสนใจเป็นพิเศษ

สถานะแดชบอร์ดและทางเลือกอื่น

ตารางความเข้ากันได้ของแดชบอร์ดกับ Kubernetes ที่นำเสนอในเวอร์ชันล่าสุดของโครงการ (v1.10.1) ไม่ค่อยมีความสุข:

อย่างไรก็ตามเรื่องนี้ก็มี (นำมาใช้แล้วในเดือนมกราคม) ประชาสัมพันธ์ #3476ซึ่งประกาศรองรับ K8s 1.13 นอกจากนี้ ในบรรดาปัญหาของโปรเจ็กต์ คุณสามารถดูข้อมูลอ้างอิงถึงผู้ใช้ที่ทำงานกับแผงควบคุมใน K8s 1.14 ได้ ในที่สุด, กระทำ เข้าสู่ฐานรหัสของโครงการไม่หยุด ดังนั้น (อย่างน้อย!) สถานะที่แท้จริงของโครงการจึงไม่แย่เท่าที่ควรจากตารางความเข้ากันได้อย่างเป็นทางการในตอนแรก

ในที่สุดก็มีทางเลือกอื่นสำหรับแดชบอร์ด ในหมู่พวกเขา:

K8แดช — อินเทอร์เฟซรุ่นเยาว์ (คอมมิตครั้งแรกย้อนกลับไปในเดือนมีนาคมของปีนี้) ซึ่งมีฟีเจอร์ที่ดีอยู่แล้ว เช่น การแสดงสถานะปัจจุบันของคลัสเตอร์และการจัดการอ็อบเจ็กต์ด้วยภาพ วางตำแหน่งเป็น “อินเทอร์เฟซแบบเรียลไทม์” เพราะ อัปเดตข้อมูลที่แสดงโดยอัตโนมัติโดยไม่จำเป็นต้องให้คุณรีเฟรชเพจในเบราว์เซอร์
คอนโซล OpenShift - เว็บอินเตอร์เฟสจาก Red Hat OpenShift ซึ่งจะนำการพัฒนาอื่น ๆ ของโครงการมาสู่คลัสเตอร์ของคุณซึ่งไม่เหมาะสำหรับทุกคน
คูเบอร์เนเตอร์ เป็นโปรเจ็กต์ที่น่าสนใจซึ่งสร้างเป็นอินเทอร์เฟซระดับล่าง (มากกว่าแดชบอร์ด) พร้อมความสามารถในการดูออบเจ็กต์คลัสเตอร์ทั้งหมด อย่างไรก็ตาม ดูเหมือนว่าการพัฒนาได้หยุดลงแล้ว
นักษัตรเนมี - เมื่อวันก่อน ประกาศ โปรเจ็กต์ที่รวมฟังก์ชันของพาเนล (แสดงสถานะปัจจุบันของคลัสเตอร์ แต่ไม่ได้จัดการอ็อบเจ็กต์) และ "การตรวจสอบแนวทางปฏิบัติที่ดีที่สุด" โดยอัตโนมัติ (ตรวจสอบคลัสเตอร์เพื่อดูความถูกต้องของการกำหนดค่าของการปรับใช้ที่ทำงานอยู่ในนั้น)

แทนที่จะได้ข้อสรุป

แดชบอร์ดเป็นเครื่องมือมาตรฐานสำหรับคลัสเตอร์ Kubernetes ที่เราให้บริการ การบูรณาการกับ GitLab ได้กลายมาเป็นส่วนหนึ่งของการติดตั้งเริ่มต้นของเรา เนื่องจากนักพัฒนาจำนวนมากรู้สึกตื่นเต้นกับความสามารถที่พวกเขามีในแผงนี้

Kubernetes Dashboard มีทางเลือกอื่นจากชุมชนโอเพ่นซอร์สเป็นระยะๆ (และเรายินดีที่จะพิจารณาทางเลือกเหล่านั้น) แต่ในขั้นตอนนี้ เรายังคงใช้โซลูชันนี้ต่อไป

PS

อ่านเพิ่มเติมในบล็อกของเรา:

ที่มา: will.com

การผสานรวม Kubernetes Dashboard และผู้ใช้ GitLab