Bảng thông tin Kubernetes là một công cụ dễ sử dụng để nhận thông tin cập nhật về cụm đang chạy của bạn và quản lý nó mà không tốn nhiều công sức. Bạn bắt đầu đánh giá cao điều đó hơn nữa khi không chỉ quản trị viên/kỹ sư DevOps cần quyền truy cập vào các khả năng này mà còn bởi những người ít quen với bảng điều khiển và/hoặc không có ý định giải quyết tất cả những điều phức tạp khi tương tác với kubectl và các tiện ích khác. Điều này đã xảy ra với chúng tôi: các nhà phát triển muốn truy cập nhanh vào giao diện web Kubernetes và vì chúng tôi sử dụng GitLab nên giải pháp đã xuất hiện một cách tự nhiên.
Tại sao thế này?
Các nhà phát triển trực tiếp có thể quan tâm đến một công cụ như Bảng điều khiển của K8 để thực hiện các tác vụ gỡ lỗi. Đôi khi bạn muốn xem nhật ký và tài nguyên, đôi khi hủy các nhóm, chia tỷ lệ Triển khai/StatefulSets và thậm chí truy cập bảng điều khiển vùng chứa (tuy nhiên, cũng có các yêu cầu đối với chúng, có một cách khác - ví dụ: thông qua ).
Ngoài ra, có một khoảnh khắc tâm lý đối với các nhà quản lý khi họ muốn nhìn vào cụm - để thấy rằng “mọi thứ đều xanh”, và từ đó tự trấn an rằng “mọi thứ đều đang hoạt động” (điều này tất nhiên là rất tương đối… nhưng điều này nằm ngoài phạm vi của bài viết).
Là một hệ thống CI tiêu chuẩn, chúng tôi có GitLab: tất cả các nhà phát triển cũng sử dụng nó. Do đó, để cung cấp cho họ quyền truy cập, việc tích hợp Bảng điều khiển với tài khoản GitLab là điều hợp lý.
Tôi cũng sẽ lưu ý rằng chúng tôi sử dụng NGINX Ingress. Nếu bạn làm việc với người khác , bạn sẽ cần phải tìm các chú thích tương tự một cách độc lập để ủy quyền.
Đang thử tích hợp
Cài đặt bảng điều khiển
Sự chú ý: Nếu bạn định lặp lại các bước bên dưới, thì - để tránh những thao tác không cần thiết - trước tiên hãy đọc tiêu đề phụ tiếp theo.
Vì chúng tôi sử dụng tính năng tích hợp này trong nhiều quá trình cài đặt nên chúng tôi đã tự động hóa quá trình cài đặt nó. Các nguồn cần thiết cho việc này được xuất bản trong . Chúng dựa trên cấu hình YAML được sửa đổi đôi chút từ , cũng như tập lệnh Bash để triển khai nhanh chóng.
Tập lệnh cài đặt Bảng điều khiển trong cụm và định cấu hình để tích hợp với 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 messageTuy nhiên, trước khi sử dụng, bạn cần truy cập GitLab: Khu vực quản trị → Ứng dụng - và thêm ứng dụng mới cho bảng điều khiển trong tương lai. Hãy gọi nó là “bảng điều khiển kubernetes”:
Kết quả của việc thêm nó là GitLab sẽ cung cấp các giá trị băm:
Chúng là những cái được sử dụng làm đối số cho tập lệnh. Kết quả là quá trình cài đặt trông như thế này:
$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comSau đó, hãy kiểm tra xem mọi thứ đã bắt đầu chưa:
$ 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 14sTuy nhiên, sớm hay muộn mọi thứ cũng sẽ bắt đầu ủy quyền sẽ không hoạt động ngay lập tức! Thực tế là trong hình ảnh được sử dụng (tình huống trong các hình ảnh khác cũng tương tự), quá trình bắt chuyển hướng trong lệnh gọi lại được triển khai không chính xác. Tình huống này dẫn đến việc oauth xóa cookie mà chính oauth cung cấp cho chúng ta...
Vấn đề được giải quyết bằng cách xây dựng hình ảnh oauth của riêng bạn bằng một bản vá.
Vá oauth và cài đặt lại
Để làm điều này, chúng tôi sẽ sử dụng Dockerfile sau:
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" ]Và đây là bản vá lỗi rd.patch trông như thế nào
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
Bây giờ bạn có thể xây dựng hình ảnh và đẩy nó vào GitLab của chúng tôi. Tiếp theo trong manifests/kube-dashboard-oauth2-proxy.yaml cho biết việc sử dụng hình ảnh mong muốn (thay thế nó bằng hình ảnh của bạn):
image: docker.io/colemickens/oauth2_proxy:latestNếu bạn có một sổ đăng ký bị đóng theo ủy quyền, đừng quên thêm việc sử dụng bí mật cho hình ảnh kéo:
imagePullSecrets:
- name: gitlab-registry... và thêm bí mật cho sổ đăng ký:
---
apiVersion: v1
data:
.dockercfg: eyJyZWdpc3RyeS5jb21wYW55LmNvbSI6IHsKICJ1c2VybmFtZSI6ICJvYXV0aDIiLAogInBhc3N3b3JkIjogIlBBU1NXT1JEIiwKICJhdXRoIjogIkFVVEhfVE9LRU4iLAogImVtYWlsIjogIm1haWxAY29tcGFueS5jb20iCn0KfQoK
=
kind: Secret
metadata:
annotations:
name: gitlab-registry
namespace: kube-system
type: kubernetes.io/dockercfgNgười đọc chú ý sẽ thấy chuỗi dài ở trên là base64 từ cấu hình:
{"registry.company.com": {
"username": "oauth2",
"password": "PASSWORD",
"auth": "AUTH_TOKEN",
"email": "[email protected]"
}
}Đây là dữ liệu người dùng trong GitLab, mã Kubernetes sẽ kéo image từ sổ đăng ký.
Sau khi mọi thứ hoàn tất, bạn có thể xóa cài đặt Bảng điều khiển hiện tại (không hoạt động chính xác) bằng lệnh:
$ ./ctl.sh -d... và cài đặt lại mọi thứ:
$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comĐã đến lúc vào Bảng điều khiển và tìm nút đăng nhập khá cổ xưa:
Sau khi nhấp vào nó, GitLab sẽ chào đón chúng tôi, đề nghị đăng nhập vào trang thông thường của nó (tất nhiên, nếu trước đó chúng tôi chưa đăng nhập vào đó):
Chúng tôi đăng nhập bằng thông tin đăng nhập GitLab - và mọi thứ đã hoàn tất:
Giới thiệu về các tính năng của Trang tổng quan
Nếu bạn là nhà phát triển chưa từng làm việc với Kubernetes trước đây hoặc đơn giản vì lý do nào đó chưa từng gặp Dashboard trước đây, tôi sẽ minh họa một số khả năng của nó.
Đầu tiên, bạn có thể thấy rằng “mọi thứ đều xanh”:
Dữ liệu chi tiết hơn cũng có sẵn cho các nhóm, chẳng hạn như biến môi trường, hình ảnh được tải xuống, đối số khởi chạy và trạng thái của chúng:
Triển khai có trạng thái hiển thị:
...và các chi tiết khác:
... và còn có khả năng mở rộng quy mô triển khai:
Kết quả của hoạt động này:
Trong số các tính năng hữu ích khác đã được đề cập ở đầu bài viết là xem nhật ký:
... và chức năng đăng nhập vào bảng điều khiển vùng chứa của nhóm đã chọn:
Ví dụ: bạn cũng có thể xem các giới hạn/yêu cầu trên các nút:
Tất nhiên, đây không phải là tất cả các khả năng của bảng điều khiển, nhưng tôi hy vọng rằng bạn hiểu được ý kiến chung.
Nhược điểm của việc tích hợp và Dashboard
Trong sự tích hợp được mô tả không có kiểm soát truy cập. Với nó, tất cả người dùng có bất kỳ quyền truy cập nào vào GitLab đều có quyền truy cập vào Trang tổng quan. Họ có cùng quyền truy cập vào Trang tổng quan, tương ứng với các quyền của chính Trang tổng quan đó. . Rõ ràng, điều này không phù hợp với tất cả mọi người, nhưng đối với trường hợp của chúng tôi, nó hóa ra là đủ.
Trong số những nhược điểm đáng chú ý của chính Bảng điều khiển, tôi lưu ý những điều sau:
- không thể vào được bảng điều khiển của vùng chứa init;
- không thể chỉnh sửa Triển khai và StatefulSets, mặc dù điều này có thể được sửa trong ClusterRole;
- Khả năng tương thích của bảng điều khiển với các phiên bản Kubernetes mới nhất và tương lai của dự án đặt ra câu hỏi.
Vấn đề cuối cùng đáng được quan tâm đặc biệt.
Trạng thái trang tổng quan và các lựa chọn thay thế
Bảng tương thích bảng điều khiển với các bản phát hành Kubernetes, được trình bày trong phiên bản mới nhất của dự án (), không được vui lắm:
Mặc dù vậy, vẫn có (đã được thông qua vào tháng XNUMX) , thông báo hỗ trợ cho K8s 1.13. Ngoài ra, trong số các vấn đề của dự án, bạn có thể tìm thấy tài liệu tham khảo về người dùng làm việc với bảng điều khiển trong K8s 1.14. Cuối cùng, vào cơ sở mã của dự án không dừng lại. Vì vậy (ít nhất!) Tình trạng thực tế của dự án không tệ như lần đầu tiên có thể thấy từ bảng tương thích chính thức.
Cuối cùng, có những lựa chọn thay thế cho Bảng điều khiển. Trong số đó:
- - một giao diện trẻ (lần cam kết đầu tiên bắt đầu từ tháng XNUMX năm nay), đã cung cấp các tính năng tốt, chẳng hạn như trình bày trực quan về trạng thái hiện tại của cụm và quản lý các đối tượng của nó. Được định vị là “giao diện thời gian thực”, bởi vì tự động cập nhật dữ liệu hiển thị mà không yêu cầu bạn phải làm mới trang trong trình duyệt.
- - giao diện web từ Red Hat OpenShift, tuy nhiên, giao diện này sẽ mang lại những phát triển khác của dự án cho cụm của bạn, giao diện này không phù hợp với tất cả mọi người.
- là một dự án thú vị, được tạo dưới dạng giao diện cấp thấp hơn (so với Bảng điều khiển) với khả năng xem tất cả các đối tượng cụm. Tuy nhiên, có vẻ như sự phát triển của nó đã dừng lại.
- - mới hôm nọ thôi một dự án kết hợp các chức năng của một bảng điều khiển (hiển thị trạng thái hiện tại của cụm nhưng không quản lý các đối tượng của nó) và tự động “xác thực các biện pháp thực hành tốt nhất” (kiểm tra cụm để biết tính chính xác của các cấu hình Triển khai đang chạy trong đó).
Thay vì kết luận
Bảng thông tin là công cụ tiêu chuẩn cho các cụm Kubernetes mà chúng tôi phục vụ. Việc tích hợp nó với GitLab cũng đã trở thành một phần trong quá trình cài đặt mặc định của chúng tôi, vì nhiều nhà phát triển rất hào hứng với các khả năng mà họ có với bảng điều khiển này.
Bảng điều khiển Kubernetes định kỳ có các lựa chọn thay thế từ cộng đồng Nguồn mở (và chúng tôi rất vui khi xem xét chúng), nhưng ở giai đoạn này, chúng tôi vẫn sử dụng giải pháp này.
PS
Đọc thêm trên blog của chúng tôi:
- «»;
- «»;
- «»;
- «'.
Nguồn: www.habr.com