Penyepaduan Papan Pemuka Kubernetes dan Pengguna GitLab

Papan Pemuka Kubernetes ialah alat yang mudah digunakan untuk mendapatkan maklumat terkini tentang kluster yang sedang berjalan dan pengurusan minimumnya. Anda mula lebih menghargainya apabila akses kepada keupayaan ini diperlukan bukan sahaja oleh pentadbir/jurutera DevOps, tetapi juga oleh mereka yang kurang biasa dengan konsol dan/atau tidak berhasrat untuk menangani semua selok-belok berinteraksi dengan kubectl dan utiliti lain. Ini berlaku dengan kami: pembangun mahukan akses pantas kepada antara muka web Kubernetes, dan memandangkan kami menggunakan GitLab, penyelesaian itu datang secara semula jadi.

kenapa ni?

Pembangun langsung mungkin berminat dengan alat seperti Papan Pemuka K8s untuk tugasan penyahpepijatan. Kadangkala anda ingin melihat log dan sumber, dan kadangkala membunuh pod, skala Deployments/StatefulSets dan juga pergi ke konsol kontena (terdapat juga permintaan yang, bagaimanapun, terdapat cara lain - contohnya, melalui kubectl-debug).

Di samping itu, terdapat masa psikologi untuk pengurus apabila mereka ingin melihat kelompok - untuk melihat bahawa "semuanya hijau", dan dengan itu meyakinkan diri mereka bahawa "semuanya berfungsi" (yang, tentu saja, sangat relatif... tetapi ini di luar skop artikel).

Sebagai sistem CI standard yang kami ada terpakai GitLab: semua pembangun menggunakannya juga. Oleh itu, untuk memberikan mereka akses, adalah logik untuk menyepadukan Papan Pemuka dengan akaun GitLab.

Saya juga akan ambil perhatian bahawa kami menggunakan NGINX Ingress. Jika anda bekerja dengan orang lain penyelesaian kemasukan, anda perlu mencari analog anotasi secara bebas untuk kebenaran.

Mencuba integrasi

Pemasangan papan pemuka

Perhatian: Jika anda akan mengulangi langkah di bawah, maka - untuk mengelakkan operasi yang tidak perlu - baca ke subtajuk seterusnya terlebih dahulu.

Memandangkan kami menggunakan penyepaduan ini dalam banyak pemasangan, kami telah mengautomasikan pemasangannya. Sumber yang diperlukan untuk ini diterbitkan dalam repositori GitHub khas. Ia berdasarkan konfigurasi YAML yang diubah suai sedikit daripada repositori Papan Pemuka rasmi, serta skrip Bash untuk penggunaan pantas.

Skrip memasang Papan Pemuka dalam kluster dan mengkonfigurasinya untuk penyepaduan 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

Walau bagaimanapun, sebelum menggunakannya, anda perlu pergi ke GitLab: Kawasan pentadbir → Aplikasi - dan tambah aplikasi baharu untuk panel akan datang. Mari kita panggil "papan pemuka kubernetes":

Hasil daripada menambahkannya, GitLab akan menyediakan cincang:

Mereka adalah orang-orang yang digunakan sebagai hujah kepada skrip. Akibatnya, pemasangan kelihatan seperti ini:

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

Selepas itu, mari semak bahawa semuanya bermula:

$ 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

Walau bagaimanapun, lambat laun semuanya akan bermula kebenaran tidak akan berfungsi serta-merta! Hakikatnya ialah dalam imej yang digunakan (keadaan dalam imej lain adalah serupa) proses menangkap ubah hala dalam panggilan balik dilaksanakan secara tidak betul. Keadaan ini membawa kepada fakta bahawa oauth memadamkan cookie yang oauth sendiri sediakan kepada kita...

Masalahnya diselesaikan dengan membina imej oauth anda sendiri dengan tampalan.

Tampal oauth dan pasang semula

Untuk melakukan ini, kami 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 inilah rupa tampalan 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

Kini anda boleh membina imej dan menolaknya ke dalam GitLab kami. Seterusnya dalam manifests/kube-dashboard-oauth2-proxy.yaml nyatakan penggunaan imej yang diingini (gantikan dengan imej anda sendiri):

 image: docker.io/colemickens/oauth2_proxy:latest

Jika anda mempunyai pendaftaran yang ditutup dengan kebenaran, jangan lupa untuk menambah penggunaan rahsia untuk menarik imej:

      imagePullSecrets:
     - name: gitlab-registry

... dan tambahkan rahsia itu sendiri untuk pendaftaran:

---
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 bahawa rentetan panjang di atas adalah base64 dari konfigurasi:

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

Ini adalah data pengguna dalam GitLab, kod Kubernetes akan menarik imej daripada pendaftaran.

Selepas semuanya selesai, anda boleh mengalih keluar pemasangan Papan Pemuka semasa (tidak berfungsi dengan betul) dengan arahan:

$ ./ctl.sh -d

... dan pasang semuanya sekali lagi:

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

Sudah tiba masanya untuk pergi ke Papan Pemuka dan mencari butang log masuk yang agak kuno:

Selepas mengklik padanya, GitLab akan menyambut kami, menawarkan untuk log masuk ke halaman biasa (sudah tentu, jika kami belum log masuk sebelum ini):

Kami log masuk dengan kelayakan GitLab - dan semuanya selesai:

Perihal ciri Papan Pemuka

Jika anda seorang pembangun yang tidak pernah bekerja dengan Kubernetes sebelum ini, atau hanya atas sebab tertentu tidak menemui Papan Pemuka sebelum ini, saya akan menggambarkan beberapa keupayaannya.

Pertama, anda boleh melihat bahawa "semuanya hijau":

Data yang lebih terperinci juga tersedia untuk pod, seperti pembolehubah persekitaran, imej yang dimuat turun, hujah pelancaran dan keadaannya:

Penggunaan mempunyai status yang boleh dilihat:

...dan butiran lain:

... dan terdapat juga keupayaan untuk menskalakan penggunaan:

Hasil daripada operasi ini:

Antara ciri berguna lain yang telah disebutkan pada permulaan artikel ialah melihat log:

... dan fungsi untuk log masuk ke konsol kontena pod yang dipilih:

Sebagai contoh, anda juga boleh melihat had/permintaan pada nod:

Sudah tentu, ini bukan semua keupayaan panel, tetapi saya harap anda mendapat idea umum.

Kelemahan integrasi dan Papan Pemuka

Dalam integrasi yang diterangkan tidak ada kawalan capaian. Dengan itu, semua pengguna yang mempunyai sebarang akses kepada GitLab mendapat akses ke Papan Pemuka. Mereka mempunyai akses yang sama dalam Papan Pemuka itu sendiri, sepadan dengan hak Papan Pemuka itu sendiri, yang ditakrifkan dalam RBAC. Jelas sekali, ini tidak sesuai untuk semua orang, tetapi untuk kes kami ternyata mencukupi.

Antara kelemahan yang ketara dalam Papan Pemuka itu sendiri, saya perhatikan perkara berikut:

• adalah mustahil untuk masuk ke konsol bekas init;
• adalah mustahil untuk mengedit Deployments dan StatefulSets, walaupun ini boleh diperbaiki dalam ClusterRole;
• Keserasian papan pemuka dengan versi terkini Kubernetes dan masa depan projek menimbulkan persoalan.

Masalah terakhir patut diberi perhatian khusus.

Status dan alternatif papan pemuka

Jadual keserasian papan pemuka dengan keluaran Kubernetes, dibentangkan dalam versi terkini projek (v1.10.1), tidak begitu gembira:

Walaupun begitu, terdapat (sudah diterima pakai pada bulan Januari) PR # 3476, yang mengumumkan sokongan untuk K8s 1.13. Di samping itu, antara isu projek anda boleh mencari rujukan kepada pengguna yang bekerja dengan panel dalam K8s 1.14. Akhirnya, melakukan ke dalam asas kod projek jangan berhenti. Jadi (sekurang-kurangnya!) Status sebenar projek itu tidaklah seteruk yang mungkin kelihatan pada jadual keserasian rasmi.

Akhir sekali, terdapat alternatif kepada Papan Pemuka. Antaranya:

1. K8Dash — antara muka muda (komit pertama bertarikh sejak Mac tahun ini), yang sudah menawarkan ciri yang baik, seperti gambaran visual status semasa kluster dan pengurusan objeknya. Diposisikan sebagai "antara muka masa nyata", kerana mengemas kini data yang dipaparkan secara automatik tanpa memerlukan anda memuat semula halaman dalam penyemak imbas.
2. OpenShift Console - antara muka web daripada Red Hat OpenShift, yang, bagaimanapun, akan membawa perkembangan lain projek kepada kelompok anda, yang tidak sesuai untuk semua orang.
3. Kubernator ialah projek yang menarik, dicipta sebagai antara muka peringkat rendah (daripada Papan Pemuka) dengan keupayaan untuk melihat semua objek kluster. Namun, nampaknya perkembangannya terhenti.
4. Polaris - hanya pada hari yang lain diumumkan projek yang menggabungkan fungsi panel (menunjukkan keadaan semasa kluster, tetapi tidak mengurus objeknya) dan "pengesahan amalan terbaik" automatik (menyemak kluster untuk mengetahui ketepatan konfigurasi Deployments yang dijalankan di dalamnya).

Daripada kesimpulan

Papan pemuka ialah alat standard untuk kluster Kubernetes yang kami sediakan. Penyepaduannya dengan GitLab juga telah menjadi sebahagian daripada pemasangan lalai kami, kerana ramai pembangun teruja dengan keupayaan yang mereka ada dengan panel ini.

Papan Pemuka Kubernetes secara berkala mempunyai alternatif daripada komuniti Sumber Terbuka (dan kami gembira untuk mempertimbangkannya), tetapi pada peringkat ini kami kekal dengan penyelesaian ini.

PS

Baca juga di blog kami:

• «kubebox dan cengkerang lain untuk Kubernetes»;
• «Amalan CI/CD terbaik dengan Kubernetes dan GitLab (laporan ulasan dan video)»;
• «Bina dan gunakan aplikasi dalam Kubernetes menggunakan dapp dan GitLab CI»;
• «GitLab CI untuk penyepaduan dan penghantaran berterusan dalam pengeluaran. Bahagian 1: saluran paip kami'.

Sumber: www.habr.com