Integrasi Dasbor Kubernetes dan Pengguna GitLab

Kubernetes Dashboard adalah alat yang mudah digunakan untuk mendapatkan informasi terkini tentang cluster yang sedang berjalan dan pengelolaan minimalnya. Anda akan semakin menghargainya ketika akses terhadap kemampuan ini diperlukan tidak hanya oleh administrator/insinyur DevOps, namun juga oleh mereka yang kurang terbiasa dengan konsol dan/atau tidak berniat untuk menangani semua seluk-beluk interaksi dengan kubectl dan utilitas lainnya. Hal ini terjadi pada kami: para pengembang menginginkan akses cepat ke antarmuka web Kubernetes, dan karena kami menggunakan GitLab, solusinya muncul secara alami.

Kenapa ini?

Pengembang langsung mungkin tertarik dengan alat seperti K8s Dashboard untuk tugas debugging. Terkadang Anda ingin melihat log dan sumber daya, dan terkadang mematikan pod, menskalakan Deployment/StatefulSets, dan bahkan membuka konsol container (ada juga permintaan yang, namun, ada cara lain - misalnya, melalui kubectl-debug).

Selain itu, ada momen psikologis bagi para manajer ketika mereka ingin melihat cluster - untuk melihat bahwa “semuanya hijau”, dan dengan demikian meyakinkan diri mereka sendiri bahwa “semuanya berfungsi” (yang, tentu saja, sangat relatif... tapi ini di luar cakupan artikel).

Sebagai sistem CI standar yang kami miliki terapan GitLab: semua pengembang juga menggunakannya. Oleh karena itu, untuk memberi mereka akses, masuk akal untuk mengintegrasikan Dashboard dengan akun GitLab.

Saya juga mencatat bahwa kami menggunakan NGINX Ingress. Jika Anda bekerja dengan orang lain solusi masuknya, Anda perlu menemukan analogi anotasi secara mandiri untuk otorisasi.

Mencoba integrasi

Pemasangan dasbor

Perhatian: Jika Anda akan mengulangi langkah-langkah di bawah ini, maka - untuk menghindari operasi yang tidak perlu - baca dulu subjudul berikutnya.

Karena kami menggunakan integrasi ini di banyak instalasi, kami telah mengotomatiskan instalasinya. Sumber yang diperlukan untuk ini dipublikasikan di repositori GitHub khusus. Mereka didasarkan pada konfigurasi YAML yang sedikit dimodifikasi dari repositori Dashboard resmi, serta skrip Bash untuk penerapan cepat.

Skrip menginstal Dashboard di cluster dan mengonfigurasinya untuk integrasi dengan 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

Namun, sebelum menggunakannya, Anda harus pergi ke GitLab: Area admin → Aplikasi - dan tambahkan aplikasi baru untuk panel selanjutnya. Sebut saja “dasbor kubernetes”:

Sebagai hasil dari penambahannya, GitLab akan memberikan hash:

Merekalah yang digunakan sebagai argumen terhadap naskah. Hasilnya, instalasinya terlihat seperti ini:

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

Setelah itu, mari kita periksa apakah semuanya sudah dimulai:

$ 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

Namun, cepat atau lambat semuanya akan dimulai otorisasi tidak akan langsung berfungsi! Faktanya adalah bahwa pada gambar yang digunakan (situasinya serupa pada gambar lain), proses menangkap pengalihan dalam panggilan balik diterapkan secara tidak benar. Keadaan ini mengarah pada fakta bahwa oauth menghapus cookie yang diberikan oauth kepada kita...

Masalahnya diselesaikan dengan membuat gambar oauth Anda sendiri dengan tambalan.

Patch oauth dan instal ulang

Untuk melakukan ini, kita akan menggunakan Dockerfile berikut:

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" ]

Dan seperti inilah tampilan patch rd.patch itu sendiri

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

Sekarang Anda dapat membuat gambar dan memasukkannya ke GitLab kami. Selanjutnya masuk manifests/kube-dashboard-oauth2-proxy.yaml tunjukkan penggunaan gambar yang diinginkan (ganti dengan milik Anda sendiri):

 image: docker.io/colemickens/oauth2_proxy:latest

Jika Anda memiliki registri yang ditutup karena otorisasi, jangan lupa menambahkan penggunaan rahasia untuk menarik gambar:

      imagePullSecrets:
     - name: gitlab-registry

... dan tambahkan rahasia itu sendiri untuk registri:

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

Pembaca yang penuh perhatian akan melihat bahwa string panjang di atas adalah base64 dari konfigurasi:

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

Ini adalah data pengguna di GitLab, kode Kubernetes akan menarik image dari registry.

Setelah semuanya selesai, Anda dapat menghapus instalasi Dashboard saat ini (tidak berfungsi dengan benar) dengan perintah:

$ ./ctl.sh -d

... dan instal semuanya lagi:

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

Saatnya membuka Dashboard dan menemukan tombol login yang agak kuno:

Setelah mengkliknya, GitLab akan menyambut kita, menawarkan untuk masuk ke halaman biasanya (tentu saja, jika kita belum pernah masuk ke sana sebelumnya):

Kami masuk dengan kredensial GitLab - dan semuanya selesai:

Tentang fitur Dasbor

Jika Anda seorang pengembang yang belum pernah bekerja dengan Kubernetes sebelumnya, atau karena alasan tertentu belum pernah menemukan Dashboard sebelumnya, saya akan mengilustrasikan beberapa kemampuannya.

Pertama, Anda dapat melihat bahwa “semuanya berwarna hijau”:

Data yang lebih detail juga tersedia untuk pod, seperti variabel lingkungan, image yang diunduh, argumen peluncuran, dan statusnya:

Deployment memiliki status yang terlihat:

...dan detail lainnya:

...dan ada juga kemampuan untuk menskalakan penerapan:

Hasil dari operasi ini:

Di antara fitur berguna lainnya yang telah disebutkan di awal artikel adalah melihat log:

... dan fungsi untuk login ke konsol container dari pod yang dipilih:

Misalnya, Anda juga dapat melihat batasan/permintaan pada node:

Tentu saja, ini belum seluruh kemampuan panel, namun saya harap Anda mendapatkan gambaran umum.

Kekurangan integrasi dan Dashboard

Dalam integrasi yang dijelaskan tidak ada kontrol akses. Dengan itu, semua pengguna dengan akses apa pun ke GitLab mendapatkan akses ke Dasbor. Mereka mempunyai akses yang sama pada Dashboard itu sendiri, sesuai dengan hak dari Dashboard itu sendiri, yaitu didefinisikan dalam RBAC. Jelas, ini tidak cocok untuk semua orang, tetapi untuk kasus kami ini ternyata cukup.

Di antara kelemahan nyata pada Dashboard itu sendiri, saya perhatikan hal berikut:

• tidak mungkin untuk masuk ke konsol wadah init;
• tidak mungkin untuk mengedit Deployment dan StatefulSets, meskipun hal ini dapat diperbaiki di ClusterRole;
• Kompatibilitas Dashboard dengan versi terbaru Kubernetes dan masa depan proyek ini menimbulkan pertanyaan.

Masalah terakhir perlu mendapat perhatian khusus.

Status dasbor dan alternatifnya

Tabel kompatibilitas dasbor dengan rilis Kubernetes, disajikan dalam versi terbaru proyek (v1.10.1), tidak terlalu senang:

Meskipun demikian, ada (sudah diadopsi pada bulan Januari) PR # 3476, yang mengumumkan dukungan untuk K8s 1.13. Selain itu, di antara masalah proyek Anda dapat menemukan referensi ke pengguna yang bekerja dengan panel di K8s 1.14. Akhirnya, berkomitmen ke dalam basis kode proyek jangan berhenti. Jadi (setidaknya!) status proyek sebenarnya tidak seburuk yang terlihat dari tabel kompatibilitas resmi.

Terakhir, ada alternatif selain Dashboard. Diantara mereka:

1. K8Dash — antarmuka muda (komit pertama dimulai pada bulan Maret tahun ini), yang sudah menawarkan fitur-fitur bagus, seperti representasi visual dari status cluster saat ini dan pengelolaan objeknya. Diposisikan sebagai “antarmuka waktu nyata”, karena secara otomatis memperbarui data yang ditampilkan tanpa mengharuskan Anda menyegarkan halaman di browser.
2. Konsol OpenShift - antarmuka web dari Red Hat OpenShift, yang, bagaimanapun, akan membawa pengembangan proyek lainnya ke cluster Anda, yang tidak cocok untuk semua orang.
3. Kubernator adalah proyek menarik, dibuat sebagai antarmuka tingkat lebih rendah (dari Dashboard) dengan kemampuan untuk melihat semua objek cluster. Namun, sepertinya perkembangannya terhenti.
4. Polaris - beberapa hari yang lalu diumumkan sebuah proyek yang menggabungkan fungsi panel (menunjukkan keadaan cluster saat ini, tetapi tidak mengelola objeknya) dan “validasi praktik terbaik” otomatis (memeriksa cluster untuk kebenaran konfigurasi Deployment yang berjalan di dalamnya).

Alih-alih kesimpulan

Dashboard adalah alat standar untuk cluster Kubernetes yang kami layani. Integrasinya dengan GitLab juga telah menjadi bagian dari instalasi default kami, karena banyak pengembang yang antusias dengan kemampuan yang mereka miliki dengan panel ini.

Dasbor Kubernetes secara berkala memiliki alternatif dari komunitas Open Source (dan kami dengan senang hati mempertimbangkannya), namun pada tahap ini kami tetap menggunakan solusi tersebut.

PS

Baca juga di blog kami:

• «kubebox dan shell lain untuk Kubernetes»;
• «Praktik CI/CD terbaik dengan Kubernetes dan GitLab (review dan laporan video)»;
• «Bangun dan terapkan aplikasi di Kubernetes menggunakan dapp dan GitLab CI»;
• «GitLab CI untuk integrasi dan pengiriman berkelanjutan dalam produksi. Bagian 1: saluran pipa kami'.

Sumber: www.habr.com