Kubernetes Dashboard هي أداة سهلة الاستخدام للحصول على أحدث المعلومات حول مجموعة العمل والحد الأدنى من التحكم فيها. تبدأ في تقدير ذلك أكثر عندما تكون هناك حاجة إلى الوصول إلى هذه الميزات ليس فقط من قِبل المسؤولين / مهندسي DevOps ، ولكن أيضًا من قِبل المستخدمين الأقل استخدامًا لوحدة التحكم و / أو لا يعتزمون التعامل مع جميع تعقيدات التفاعل مع kubectl والأدوات المساعدة الأخرى. حدث ذلك معنا: أراد المطورون الوصول السريع إلى واجهة ويب Kubernetes ، وبما أننا نستخدم GitLab ، فقد جاء الحل بشكل طبيعي.
لماذا هذا؟
قد يهتم المطورون المباشرون بأداة مثل K8s Dashboard لمهام تصحيح الأخطاء. في بعض الأحيان تريد عرض السجلات والموارد ، وفي بعض الأحيان تقتل السنفات ، وتوسيع نطاق عمليات النشر / StatefulSets وحتى تذهب إلى وحدة التحكم في الحاوية (هناك أيضًا طلبات توجد بها طريقة أخرى ، على سبيل المثال ، من خلال
kubectl-debug ).
بالإضافة إلى ذلك ، هناك لحظة نفسية للمديرين عندما يرغبون في إلقاء نظرة على المجموعة - لرؤية "كل شيء أخضر" ، وبالتالي تهدئة "كل شيء يعمل" (والذي ، بالطبع ، نسبي جدًا ... لكن هذا يتجاوز نطاق المقال) ).
نستخدم GitLab كنظام CI قياسي: يستخدمه جميع المطورين. لذلك ، لمنحهم حق الوصول ، كان من المنطقي دمج Dashboard مع الحسابات في GitLab.
لاحظ أيضًا أننا نستخدم NGINX Ingress. إذا كنت تعمل مع
حلول إدخال أخرى ، فستحتاج إلى العثور على نظائر توضيحية بشكل مستقل للحصول على إذن.
نحاول التكامل
تثبيت لوحة القيادة
انتباه : إذا كنت ستكرر الخطوات الموضحة أدناه ، فحينئذٍ - من أجل تجنب العمليات غير الضرورية - اقرأ أولاً العنوان الفرعي التالي.نظرًا لأننا نستخدم هذا التكامل في العديد من عمليات التثبيت ، فقد قمنا تلقائيًا بتثبيته. يتم نشر المصادر المطلوبة لهذا في
مستودع GitHub خاص . تعتمد على تكوينات YAML المعدلة قليلاً من
مستودع Dashboard الرسمي ، بالإضافة إلى نص 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: منطقة المسؤول → التطبيقات - وإضافة تطبيق جديد للوحة المستقبلية. دعنا نسميها "لوحة 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 \ && go get -u github.com/golang/dep/cmd/dep \ && 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 fa2771998a98a5bfdfa3c3503757668ac4f1c8ec 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/Gopkg.lock b/Gopkg.lock index 5a3758a..1294a90 100644 --- a/Gopkg.lock +++ b/Gopkg.lock @@ -131,7 +131,7 @@ version = "v1.0.0" [[projects]] - name = "gopkg.in/fsnotify.v1" + name = "gopkg.in/fsnotify/fsnotify.v1" packages = ["."] revision = "836bfd95fecc0f1511dd66bdbf2b5b61ab8b00b6" version = "v1.2.11" @@ -149,6 +149,6 @@ [solve-meta] analyzer-name = "dep" analyzer-version = 1 - inputs-digest = "b502c41a61115d14d6379be26b0300f65d173bdad852f0170d387ebf2d7ec173" + inputs-digest = "cfdd05348394cd0597edb858bdba5681665358a963356ed248d98f39373c33b5" solver-name = "gps-cdcl" solver-version = 1 diff --git a/Gopkg.toml b/Gopkg.toml index c4005e1..422bd43 100644 --- a/Gopkg.toml +++ b/Gopkg.toml @@ -4,7 +4,7 @@ # [[constraint]] - name = "github.com/18F/hmacauth" + name = "github.com/mbland/hmacauth" version = "~1.0.1" [[constraint]] @@ -36,7 +36,7 @@ name = "google.golang.org/api" [[constraint]] - name = "gopkg.in/fsnotify.v1" + name = "gopkg.in/fsnotify/fsnotify.v1" version = "~1.2.0" [[constraint]] 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/dist 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 diff --git a/watcher.go b/watcher.go index bedb9f8..4b83946 100644 --- a/watcher.go +++ b/watcher.go @@ -7,8 +7,7 @@ import ( "os" "path/filepath" "time" - - "gopkg.in/fsnotify.v1" + "gopkg.in/fsnotify/fsnotify.v1" ) func WaitForReplacement(filename string, op fsnotify.Op,
يمكنك الآن بناء الصورة ودفعها إلى 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": "mail@company.com" } }
هذه هي بيانات المستخدم في GitLab ، الكود الذي ستسحب به Kubernet الصورة من السجل.
بعد الانتهاء من كل شيء ، يمكنك إزالة تثبيت لوحة المعلومات الحالية (تعمل بشكل غير صحيح) باستخدام الأمر:
$ ./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 الوصول إلى لوحة المعلومات. لديهم نفس الوصول إلى Dashboard ، بما يتوافق مع حقوق Dashboard نفسها ، والتي تم
تعريفها في RBAC . من الواضح أن هذا ليس مناسبًا للجميع ، ولكن بالنسبة إلى حالتنا ، فقد تبين أنه كافٍ.
من السلبيات الملحوظة في لوحة المعلومات نفسها ، ألاحظ ما يلي:
- من المستحيل الدخول إلى وحدة التحكم في حاوية init ؛
- لا يمكن تحرير النشرات و StatefulSets ، على الرغم من أن هذا قابل للتثبيت في ClusterRole ؛
- يطرح توافق لوحة المعلومات مع أحدث إصدارات Kubernetes ومستقبل المشروع أسئلة.
المشكلة الأخيرة تستحق اهتماما خاصا.
حالة لوحة القيادة والبدائل
جدول توافق Dashboard مع إصدارات Kubernetes ، المقدم في أحدث إصدار من المشروع (
الإصدار 1.11 ) ، ليس سعيدًا جدًا:
على الرغم من هذا ، هناك (تم اعتماده بالفعل في يناير)
PR # 3476 ، الذي يعلن دعمه لـ K8s 1.13. بالإضافة إلى ذلك ، من بين مشكلات المشروع ، يمكنك العثور على مراجع للمستخدمين الذين يعملون مع اللوحة في K8s 1.14. أخيرًا ، لا تتوقف عمليات
الالتزام بقاعدة رمز المشروع. لذا (على الأقل!) الحالة الفعلية للمشروع ليست سيئة كما قد تظهر أولاً من جدول التوافق الرسمي.
أخيرًا ، تحتوي Dashboard على بدائل. من بينها:
- K8Dash هي واجهة شابة (يتم تنفيذ الأوليات في شهر مارس من هذا العام) ، والتي توفر بالفعل ميزات جيدة ، مثل التمثيل المرئي للحالة الحالية للكتلة وإدارة كائناتها. يتم وضعه ك "واجهة في الوقت الحقيقي" ، لأنه يقوم تلقائيًا بتحديث البيانات المعروضة دون الحاجة إلى تحديث الصفحة في المستعرض.
- OpenShift Console هي واجهة ويب من Red Hat OpenShift ، والتي ، مع ذلك ، ستجلب إنجازات المشروع الأخرى إلى مجموعتك ، والتي لا تناسب الجميع.
- Kubernator هو مشروع مثير للاهتمام تم إنشاؤه كواجهة منخفضة المستوى (من Dashboard) مع إمكانية عرض جميع الكائنات في الكتلة. ومع ذلك ، يبدو أن كل شيء قد توقف تطورها.
- Polaris هو فقط اليوم الذي تم الإعلان فيه عن مشروع يجمع بين وظائف لوحة (يُظهر الحالة الحالية للكتلة ، لكنه لا يدير كائناتها) و "التحقق من صحة أفضل الممارسات" تلقائيًا (يتحقق من الكتلة للتكوين الصحيح لعمليات النشر التي تعمل فيها).
بدلا من الاستنتاجات
Dashboard هي الأداة القياسية لمجموعات Kubernetes التي نخدمها. أصبح تكامله مع GitLab أيضًا جزءًا من "التثبيت الافتراضي" الخاص بنا ، حيث أن العديد من المطورين سعداء بالفرص المتاحة لهم مع هذه اللوحة.
لدى Kubernetes Dashboard بشكل دوري بدائل من مجتمع المصادر المفتوحة (ويسعدنا النظر فيها) ، ولكن في هذه المرحلة سنظل مع هذا الحل.
PS
اقرأ أيضًا في مدونتنا:
UPD. وفقًا لتقرير whoch ، تم العثور على خطأ في التصحيح (تم استبدال علامات التبويب بمسافات). تم تحديث التصحيح في المقالة.