ການປະສົມປະສານຂອງ Kubernetes Dashboard ແລະຜູ້ໃຊ້ GitLab

Kubernetes Dashboard ເປັນເຄື່ອງມືທີ່ງ່າຍຕໍ່ການໃຊ້ສໍາລັບການໄດ້ຮັບຂໍ້ມູນທີ່ທັນສະໄຫມກ່ຽວກັບກຸ່ມທີ່ເຮັດວຽກຂອງທ່ານແລະຈັດການມັນດ້ວຍຄວາມພະຍາຍາມຫນ້ອຍທີ່ສຸດ. ທ່ານເລີ່ມຮູ້ຈັກມັນຫຼາຍຂຶ້ນເມື່ອການເຂົ້າເຖິງຄວາມສາມາດເຫຼົ່ານີ້ບໍ່ພຽງແຕ່ໂດຍຜູ້ບໍລິຫານ / ວິສະວະກອນ DevOps ເທົ່ານັ້ນ, ແຕ່ຍັງໂດຍຜູ້ທີ່ບໍ່ຄຸ້ນເຄີຍກັບ console ແລະ / ຫຼືບໍ່ຕັ້ງໃຈທີ່ຈະຈັດການກັບຄວາມສັບສົນທັງຫມົດຂອງການພົວພັນກັບ kubectl ແລະ ອຸປະໂພກອື່ນໆ. ນີ້ເກີດຂຶ້ນກັບພວກເຮົາ: ນັກພັດທະນາຕ້ອງການການເຂົ້າເຖິງໄວໃນການໂຕ້ຕອບເວັບໄຊຕ໌ Kubernetes, ແລະນັບຕັ້ງແຕ່ພວກເຮົາໃຊ້ GitLab, ການແກ້ໄຂແມ່ນມາຈາກທໍາມະຊາດ.

ເປັນຫຍັງຄືອັນນີ້?

ນັກພັດທະນາໂດຍກົງອາດຈະມີຄວາມສົນໃຈໃນເຄື່ອງມືເຊັ່ນ K8s Dashboard ສໍາລັບການແກ້ໄຂບັນຫາວຽກງານ. ບາງຄັ້ງທ່ານຕ້ອງການເບິ່ງບັນທຶກແລະຊັບພະຍາກອນ, ແລະບາງຄັ້ງຂ້າ pods, ຂະຫນາດ Deployments/StatefulSets, ແລະແມ້ກະທັ້ງໄປທີ່ container console (ຍັງມີການຮ້ອງຂໍທີ່, ຢ່າງໃດກໍຕາມ, ມີວິທີອື່ນ - ຕົວຢ່າງ, ໂດຍຜ່ານ. kubectl-debug).

ນອກຈາກນັ້ນ, ມີຊ່ວງເວລາທາງຈິດໃຈສໍາລັບຜູ້ຈັດການໃນເວລາທີ່ພວກເຂົາຕ້ອງການເບິ່ງກຸ່ມ - ເພື່ອເບິ່ງວ່າ "ທຸກສິ່ງທຸກຢ່າງແມ່ນສີຂຽວ", ແລະດັ່ງນັ້ນຈິ່ງຫມັ້ນໃຈຕົນເອງວ່າ "ທຸກສິ່ງທຸກຢ່າງເຮັດວຽກ" (ເຊິ່ງ, ແນ່ນອນ, ແມ່ນພີ່ນ້ອງຫຼາຍ ... ແຕ່ນີ້ແມ່ນເກີນຂອບເຂດຂອງບົດຄວາມ).

ເປັນລະບົບ CI ມາດຕະຖານທີ່ພວກເຮົາມີ ນຳ ໃຊ້ແລ້ວ GitLab: ນັກພັດທະນາທຸກຄົນໃຊ້ມັນຄືກັນ. ດັ່ງນັ້ນ, ເພື່ອໃຫ້ພວກເຂົາເຂົ້າເຖິງ, ມັນສົມເຫດສົມຜົນທີ່ຈະປະສົມປະສານ Dashboard ກັບບັນຊີ GitLab.

ຂ້ອຍຍັງຈະສັງເກດວ່າພວກເຮົາໃຊ້ NGINX Ingress. ຖ້າທ່ານເຮັດວຽກກັບຄົນອື່ນ ວິທີແກ້ໄຂ ingress, ທ່ານຈະຈໍາເປັນຕ້ອງໄດ້ເປັນເອກະລາດຊອກຫາ analogues ຂອງຄໍາບັນຍາຍສໍາລັບການອະນຸຍາດ.

ພະຍາຍາມປະສົມປະສານ

ການຕິດຕັ້ງ Dashboard

ລະມັດລະວັງ: ຖ້າທ່ານກໍາລັງຈະເຮັດຊ້ໍາຂັ້ນຕອນຂ້າງລຸ່ມນີ້, ຫຼັງຈາກນັ້ນ - ເພື່ອຫຼີກເວັ້ນການດໍາເນີນການທີ່ບໍ່ຈໍາເປັນ - ທໍາອິດອ່ານກັບຫົວຂໍ້ຍ່ອຍຕໍ່ໄປ.

ນັບຕັ້ງແຕ່ພວກເຮົານໍາໃຊ້ການປະສົມປະສານນີ້ໃນຫຼາຍໆການຕິດຕັ້ງ, ພວກເຮົາໄດ້ເຮັດການຕິດຕັ້ງຂອງມັນໂດຍອັດຕະໂນມັດ. ແຫຼ່ງຂໍ້ມູນທີ່ຈໍາເປັນສໍາລັບການນີ້ໄດ້ຖືກຈັດພີມມາຢູ່ໃນ ຄັງເກັບ GitHub ພິເສດ. ພວກເຂົາເຈົ້າແມ່ນອີງໃສ່ການຕັ້ງຄ່າ YAML ດັດແກ້ເລັກນ້ອຍຈາກ ຄັງເກັບຂໍ້ມູນ Dashboard ຢ່າງເປັນທາງການ, ເຊັ່ນດຽວກັນກັບ Bash script ສໍາລັບການນໍາໃຊ້ໄວ.

ສະຄຣິບຕິດຕັ້ງ 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 - ແລະເພີ່ມແອັບພລິເຄຊັນໃຫມ່ສໍາລັບແຜງໃນອະນາຄົດ. ໃຫ້ເອີ້ນມັນວ່າ "kubernetes dashboard":

ເປັນຜົນມາຈາກການເພີ່ມມັນ, GitLab ຈະສະຫນອງ hashes:

ພວກເຂົາເຈົ້າແມ່ນຜູ້ທີ່ຖືກນໍາໃຊ້ເປັນການໂຕ້ຖຽງກັບ script. ດັ່ງນັ້ນ, ການຕິດຕັ້ງເບິ່ງຄືວ່າ:

$ ./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.

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 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 ຈາກ config:

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

ນີ້ແມ່ນຂໍ້ມູນຜູ້ໃຊ້ໃນ GitLab, ລະຫັດ Kubernetes ຈະດຶງຮູບພາບຈາກລີຈິດຊີ.

ຫຼັງຈາກທຸກສິ່ງທຸກຢ່າງຖືກເຮັດແລ້ວ, ທ່ານສາມາດຖອນການຕິດຕັ້ງ Dashboard ໃນປັດຈຸບັນ (ບໍ່ເຮັດວຽກຢ່າງຖືກຕ້ອງ) ດ້ວຍຄໍາສັ່ງ:

$ ./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 credentials - ແລະທຸກສິ່ງທຸກຢ່າງແມ່ນແລ້ວ:

ກ່ຽວກັບລັກສະນະ Dashboard

ຖ້າທ່ານເປັນນັກພັດທະນາທີ່ບໍ່ເຄີຍເຮັດວຽກກັບ Kubernetes ມາກ່ອນ, ຫຼືພຽງແຕ່ສໍາລັບເຫດຜົນບາງຢ່າງທີ່ບໍ່ເຄີຍພົບ Dashboard ມາກ່ອນ, ຂ້ອຍຈະສະແດງຄວາມສາມາດບາງຢ່າງຂອງມັນ.

ກ່ອນອື່ນ ໝົດ, ເຈົ້າສາມາດເຫັນໄດ້ວ່າ "ທຸກສິ່ງທຸກຢ່າງແມ່ນສີຂຽວ":

ຂໍ້​ມູນ​ລະ​ອຽດ​ເພີ່ມ​ເຕີມ​ແມ່ນ​ຍັງ​ມີ​ໃຫ້​ສໍາ​ລັບ pods​, ເຊັ່ນ​: ຕົວ​ແປ​ສະ​ພາບ​ແວດ​ລ້ອມ​, ຮູບ​ພາບ​ທີ່​ດາວ​ໂຫຼດ​, arguments ການ​ເປີດ​ຕົວ​, ແລະ​ສະ​ພາບ​ຂອງ​ເຂົາ​ເຈົ້າ​:

ການນຳໃຊ້ມີສະຖານະທີ່ເຫັນໄດ້:

...ແລະລາຍລະອຽດອື່ນໆ:

... ແລະ​ຍັງ​ມີ​ຄວາມ​ສາ​ມາດ​ໃນ​ຂະ​ຫນາດ​ການ​ນໍາ​ໃຊ້​:

ຜົນ​ຂອງ​ການ​ດໍາ​ເນີນ​ງານ​ນີ້​:

ໃນບັນດາຄຸນສົມບັດທີ່ເປັນປະໂຫຍດອື່ນໆທີ່ໄດ້ກ່າວມາແລ້ວໃນຕອນຕົ້ນຂອງບົດຄວາມແມ່ນການເບິ່ງບັນທຶກ:

... ແລະຟັງຊັນເພື່ອເຂົ້າສູ່ລະບົບ container console ຂອງ pod ທີ່ເລືອກ:

ຕົວຢ່າງ, ທ່ານຍັງສາມາດເບິ່ງຂໍ້ຈໍາກັດ / ການຮ້ອງຂໍໃນ nodes:

ແນ່ນອນ, ເຫຼົ່ານີ້ບໍ່ແມ່ນຄວາມສາມາດທັງຫມົດຂອງກະດານ, ແຕ່ຂ້ອຍຫວັງວ່າເຈົ້າຈະໄດ້ຮັບຄວາມຄິດທົ່ວໄປ.

ຂໍ້ເສຍຂອງການເຊື່ອມໂຍງແລະ Dashboard

ໃນການປະສົມປະສານທີ່ອະທິບາຍບໍ່ມີ ການ​ຄວບ​ຄຸມ​ການ​ເຂົ້າ​ເຖິງ​. ດ້ວຍມັນ, ຜູ້ໃຊ້ທຸກຄົນທີ່ມີການເຂົ້າເຖິງ GitLab ສາມາດເຂົ້າເຖິງ Dashboard ໄດ້. ພວກເຂົາເຈົ້າມີການເຂົ້າເຖິງດຽວກັນໃນ Dashboard ຕົວຂອງມັນເອງ, ທີ່ສອດຄ້ອງກັນກັບສິດທິຂອງ Dashboard ເອງ, ເຊິ່ງ. ຖືກກໍານົດໄວ້ໃນ RBAC. ແນ່ນອນ, ນີ້ບໍ່ແມ່ນເຫມາະສົມສໍາລັບທຸກຄົນ, ແຕ່ສໍາລັບກໍລະນີຂອງພວກເຮົາ, ມັນໄດ້ກາຍເປັນພຽງພໍ.

ໃນບັນດາຂໍ້ເສຍທີ່ສັງເກດເຫັນໃນ Dashboard ຕົວຂອງມັນເອງ, ຂ້າພະເຈົ້າສັງເກດເຫັນດັ່ງຕໍ່ໄປນີ້:

• ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະເຂົ້າໄປໃນ console ຂອງຖັງ init;
• ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະແກ້ໄຂ Deployments ແລະ StatefulSets, ເຖິງແມ່ນວ່ານີ້ສາມາດແກ້ໄຂໄດ້ໃນ ClusterRole;
• ຄວາມເຂົ້າກັນໄດ້ຂອງ Dashboard ກັບ Kubernetes ຮຸ່ນຫຼ້າສຸດ ແລະອະນາຄົດຂອງໂຄງການເຮັດໃຫ້ເກີດຄໍາຖາມ.

ບັນຫາສຸດທ້າຍສົມຄວນໄດ້ຮັບຄວາມສົນໃຈເປັນພິເສດ.

ສະຖານະ dashboard ແລະທາງເລືອກ

ຕາຕະລາງຄວາມເຂົ້າກັນໄດ້ຂອງ Dashboard ກັບການເປີດຕົວ Kubernetes, ນໍາສະເຫນີໃນສະບັບຫລ້າສຸດຂອງໂຄງການ (v1.10.1), ບໍ່​ມີ​ຄວາມ​ສຸກ​ຫຼາຍ​:

ເຖິງວ່າຈະມີນີ້, ມີ (ໄດ້ຮັບຮອງເອົາແລ້ວໃນເດືອນມັງກອນ) ປທ #3476, ເຊິ່ງປະກາດສະຫນັບສະຫນູນ K8s 1.13. ນອກຈາກນັ້ນ, ໃນບັນດາບັນຫາຂອງໂຄງການທ່ານສາມາດຊອກຫາການອ້າງອີງເຖິງຜູ້ໃຊ້ທີ່ເຮັດວຽກກັບກະດານໃນ K8s 1.14. ສຸດທ້າຍ, ຄໍາຫມັ້ນສັນຍາ ເຂົ້າໄປໃນຖານລະຫັດຂອງໂຄງການບໍ່ຢຸດ. ດັ່ງນັ້ນ (ຢ່າງຫນ້ອຍ!) ສະຖານະພາບຕົວຈິງຂອງໂຄງການແມ່ນບໍ່ຮ້າຍແຮງເທົ່າທີ່ມັນອາດຈະເບິ່ງຄືວ່າທໍາອິດຈາກຕາຕະລາງຄວາມເຂົ້າກັນໄດ້ຢ່າງເປັນທາງການ.

ສຸດທ້າຍ, ມີທາງເລືອກໃນການ Dashboard. ໃນບັນດາພວກເຂົາ:

1. K8Dash — ເປັນການໂຕ້ຕອບໄວຫນຸ່ມ (ຄໍາຫມັ້ນສັນຍາຄັ້ງທໍາອິດກັບເດືອນມີນາຂອງປີນີ້), ເຊິ່ງສະເຫນີຄຸນສົມບັດທີ່ດີເຊັ່ນ: ການສະແດງພາບຂອງສະຖານະພາບປະຈຸບັນຂອງກຸ່ມແລະການຄຸ້ມຄອງວັດຖຸຂອງມັນ. ຕໍາແຫນ່ງເປັນ "ການໂຕ້ຕອບໃນເວລາທີ່ແທ້ຈິງ", ເພາະວ່າ ປັບປຸງຂໍ້ມູນທີ່ສະແດງໂດຍອັດຕະໂນມັດໂດຍບໍ່ຈໍາເປັນຕ້ອງໃຫ້ທ່ານໂຫຼດຫນ້າໃຫມ່ໃນຕົວທ່ອງເວັບ.
2. OpenShift Console - ການໂຕ້ຕອບເວັບໄຊຕ໌ຈາກ Red Hat OpenShift, ເຊິ່ງ, ຢ່າງໃດກໍຕາມ, ຈະນໍາເອົາການພັດທະນາອື່ນໆຂອງໂຄງການໄປຫາກຸ່ມຂອງທ່ານ, ເຊິ່ງບໍ່ເຫມາະສົມສໍາລັບທຸກຄົນ.
3. Kubernator ເປັນໂຄງການທີ່ຫນ້າສົນໃຈ, ສ້າງເປັນການໂຕ້ຕອບລະດັບຕ່ໍາ (ກ່ວາ Dashboard) ທີ່ມີຄວາມສາມາດໃນການເບິ່ງວັດຖຸຂອງກຸ່ມທັງຫມົດ. ຢ່າງໃດກໍ່ຕາມ, ເບິ່ງຄືວ່າການພັດທະນາຂອງມັນໄດ້ຢຸດເຊົາ.
4. Polaris - ພຽງ​ແຕ່​ມື້​ອື່ນ​ ປະ​ກາດ ໂຄງ​ການ​ທີ່​ລວມ​ຫນ້າ​ທີ່​ຂອງ​ຄະ​ນະ​ກໍາ​ມະ (ສະ​ແດງ​ໃຫ້​ເຫັນ​ສະ​ຖາ​ນະ​ການ​ປະ​ຈຸ​ບັນ​ຂອງ​ກຸ່ມ​, ແຕ່​ບໍ່​ໄດ້​ຈັດ​ການ​ວັດ​ຖຸ​ຂອງ​ຕົນ​) ແລະ​ອັດ​ຕະ​ໂນ​ມັດ "ການ​ກວດ​ສອບ​ການ​ປະ​ຕິ​ບັດ​ທີ່​ດີ​ທີ່​ສຸດ​" (ກວດ​ສອບ​ກຸ່ມ​ສໍາ​ລັບ​ຄວາມ​ຖືກ​ຕ້ອງ​ຂອງ​ການ​ຕັ້ງ​ຄ່າ​ຂອງ​ການ​ນໍາ​ໃຊ້​ໃນ​ມັນ​)​.

ແທນທີ່ຈະສະຫລຸບ

Dashboard ເປັນເຄື່ອງມືມາດຕະຖານສໍາລັບກຸ່ມ Kubernetes ທີ່ພວກເຮົາໃຫ້ບໍລິການ. ການເຊື່ອມໂຍງຂອງມັນກັບ GitLab ໄດ້ກາຍເປັນສ່ວນຫນຶ່ງຂອງການຕິດຕັ້ງໃນຕອນຕົ້ນຂອງພວກເຮົາ, ຍ້ອນວ່ານັກພັດທະນາຫຼາຍຄົນຕື່ນເຕັ້ນກັບຄວາມສາມາດທີ່ພວກເຂົາມີກັບກະດານນີ້.

Kubernetes Dashboard ແຕ່ລະໄລຍະມີທາງເລືອກຈາກຊຸມຊົນແຫຼ່ງເປີດ (ແລະພວກເຮົາຍິນດີທີ່ຈະພິຈາລະນາພວກມັນ), ແຕ່ໃນຂັ້ນຕອນນີ້ພວກເຮົາຍັງຄົງຢູ່ກັບການແກ້ໄຂນີ້.

PS

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «kubebox ແລະແກະອື່ນໆສໍາລັບ Kubernetes"
• «ການປະຕິບັດ CI/CD ທີ່ດີທີ່ສຸດກັບ Kubernetes ແລະ GitLab (ການທົບທວນຄືນແລະບົດລາຍງານວິດີໂອ)"
• «ສ້າງ ແລະນຳໃຊ້ແອັບພລິເຄຊັນໃນ Kubernetes ໂດຍໃຊ້ dapp ແລະ GitLab CI"
• «GitLab CI ສໍາລັບການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງແລະການຈັດສົ່ງໃນການຜະລິດ. ສ່ວນທີ 1: ທໍ່ຂອງພວກເຮົາ".

ແຫຼ່ງຂໍ້ມູນ: www.habr.com