Bảng điều khiển Kubernetes - Lỗi máy chủ không xác định sau khi đăng nhập


9

Tôi đã triển khai thành công Kubernetes thông qua Kubespray và mọi thứ dường như hoạt động tốt. Tôi có thể truy cập cụm thông qua kubectl và liệt kê các nút, nhóm, dịch vụ, bí mật, v.v. Cũng có thể áp dụng các nguồn tài nguyên mới và điểm cuối bảng điều khiển cho tôi trang đăng nhập bảng điều khiển.

Tôi đã đăng nhập bằng mã thông báo của các dịch vụ khác nhau (mặc định, kubernetes-dashboard, kubernetes-admin, ...) ... với mỗi lần đăng nhập, tôi nhận được các cửa sổ bật lên giống như được mô tả trong bảng điều khiển kubespray cảnh báo cấm quảng cáo .

Vì vậy, tôi đã áp dụng clusterrolebinding cho tài khoản dịch vụ mặc định như được mô tả. Khi tôi đăng nhập ngay bây giờ bằng mã thông báo tài khoản mặc định, tôi chỉ nhận được một

Unknown Server Error (404)
the server could not find the requested resource
Redirecting to previous state in 3 seconds...

hộp chuyển hướng tôi đến trang đăng nhập sau đó. Hành vi tương tự nếu tôi kết nối với Bảng điều khiển thông qua kubectl proxy. Quyền truy cập là HTTPS qua IP cụm công khai và HTTP qua proxy

Tôi đang sử dụng Kubernetes 1.16.2 và bản gốc Kubespray mới nhất cam kết 18d19d9e

EDIT: Tôi đã phá hủy và phê duyệt lại cụm để có được một cá thể được cung cấp Kubespray mới để thực hiện tất cả các bước xác định, thêm thông tin ...

kubectl -n kube-system logs --follow kubernetes-dashboard-556b9ff8f8-jbmgg -- trong một lần thử đăng nhập mang lại cho tôi

2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Incoming HTTP/2.0 GET /api/v1/csrftoken/login request from 10.233.74.0:57458: { contents hidden }
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Incoming HTTP/2.0 POST /api/v1/login request from 10.233.74.0:57458: { contents hidden }
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Incoming HTTP/2.0 GET /api/v1/login/status request from 10.233.74.0:57458: {}
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Incoming HTTP/2.0 GET /api/v1/csrftoken/token request from 10.233.74.0:57458: {}
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Incoming HTTP/2.0 POST /api/v1/token/refresh request from 10.233.74.0:57458: { contents hidden }
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Incoming HTTP/2.0 GET /api/v1/login/status request from 10.233.74.0:57458: {}
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Incoming HTTP/2.0 GET /api/v1/csrftoken/token request from 10.233.74.0:57458: {}
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Incoming HTTP/2.0 POST /api/v1/token/refresh request from 10.233.74.0:57458: { contents hidden }
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:02 [2019-12-16T12:35:02Z] Incoming HTTP/2.0 GET /api/v1/overview/default?filterBy=&itemsPerPage=10&name=&page=1&sortBy=d,creationTimestamp request from 10.233.74.0:57458: {}
2019/12/16 12:35:03 Getting config category
2019/12/16 12:35:03 Getting discovery and load balancing category
2019/12/16 12:35:03 Getting lists of all workloads
2019/12/16 12:35:03 the server could not find the requested resource
2019/12/16 12:35:03 [2019-12-16T12:35:03Z] Outcoming response to 10.233.74.0:57458 with 404 status code
2019/12/16 12:35:03 No metric client provided. Skipping metrics.
2019/12/16 12:35:03 No metric client provided. Skipping metrics.
2019/12/16 12:35:03 No metric client provided. Skipping metrics.
2019/12/16 12:35:03 Getting pod metrics
2019/12/16 12:35:03 No metric client provided. Skipping metrics.
2019/12/16 12:35:03 No metric client provided. Skipping metrics.
2019/12/16 12:35:03 [2019-12-16T12:35:03Z] Incoming HTTP/2.0 GET /api/v1/systembanner request from 10.233.74.0:57458: {}
2019/12/16 12:35:03 [2019-12-16T12:35:03Z] Incoming HTTP/2.0 GET /api/v1/login/status request from 10.233.74.0:57458: {}
2019/12/16 12:35:03 [2019-12-16T12:35:03Z] Incoming HTTP/2.0 GET /api/v1/rbac/status request from 10.233.74.0:57458: {}
2019/12/16 12:35:03 [2019-12-16T12:35:03Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:03 [2019-12-16T12:35:03Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:03 [2019-12-16T12:35:03Z] Outcoming response to 10.233.74.0:57458 with 200 status code
2019/12/16 12:35:12 Metric client health check failed: the server could not find the requested resource (get services heapster). Retrying in 30 seconds.
2019/12/16 12:35:42 Metric client health check failed: the server could not find the requested resource (get services heapster). Retrying in 30 seconds.

Tôi đã tìm thấy một cách giải quyết kỳ lạ để làm cho bảng điều khiển hoạt động , nhưng điều này không thể sử dụng được cho chúng tôi trong sản xuất, có lẽ ai đó có thể giải thích điều này:

  1. Tôi lấy ví dụ về dịch vụ kube-system:default(Lưu ý: cái này KHÔNG được gán cluster-adminvào thời điểm này
  2. Tôi nhận được mã thông báo của nó và đăng nhập với nó
  3. Bảng điều khiển rõ ràng cho tôi thấy "cửa sổ bật lên bị cấm"
  4. Trong khi vẫn đăng nhập, tôi chạy kubectl create clusterrolebinding default-admin --clusterrole cluster-admin --serviceaccount=kube-system:default
  5. Tôi làm mới tab trình duyệt chứa phiên bảng điều khiển của mình ... et voila, mọi thứ hiển thị chính xác.

Do đó, tôi không thể đăng xuất và đăng nhập lại, tôi luôn phải xóa clusterrolebinding, sau đó đăng nhập và sau đó áp dụng clusterrolebinding một lần nữa.

Điều này dường như có liên quan mạnh mẽ đến các cụm được cung cấp kubespray, vì vậy bất cứ ai cũng có thể tái tạo điều này với kubespray?


Bạn có thể vui lòng chia sẻ nhật ký của bảng điều khiển Kubernetes và mã thông báo tài khoản dịch vụ nào bạn đang sử dụng để đăng nhập không?
Umesh Kumhar

chia sẻ các yamls triển khai và các bước bạn đã thử
P Ekambaram

Câu trả lời:


7

Nếu bạn đang sử dụng chứng chỉ để kết nối thì chứng chỉ của bạn phải nằm trong hệ thống: nhóm thạc sĩ Vì vậy, hãy bao gồm "Chủ đề: O = system: masters, CN ="

Bạn cũng có thể tạo Mã thông báo và sau đó sử dụng mã thông báo thay vì chứng chỉ:

Có thể có khả năng vai trò cụm của bạn bị ràng buộc với "Tài khoản dịch vụ" nhưng không phải nhóm của bạn, Bạn nên kiểm tra nhóm của mình trong tệp yaml. Tài khoản dịch vụ của bạn có mã thông báo truy cập, sử dụng để xác thực thay vì chứng chỉ của bạn.

Sử dụng điều này để tạo mã thông báo và sử dụng nó.

kubectl describe secret $(kubectl get secret | grep cluster-admin | awk '{print $1}')

mã thông báo:

Cập nhật kubeconfig để xác thực chính mình bằng mã thông báo đó, thay vì chứng chỉ bạn hiện đang sử dụng và bạn sẽ được xác thực thành công như tài khoản dịch vụ quản trị cụm.

Kubernetes RBAC - cấm cố gắng cấp thêm đặc quyền


Điều này trả lại cho tôi mã thông báo của dịch vụ "mặc định" trong không gian tên "mặc định", vì không có "quản trị viên cụm" nào được xác định. Ngay cả khi tôi thêm "- không gian tên", dường như Kubespray không cung cấp tài khoản dịch vụ quản trị cụm nói chung: Tôi biết về việc sử dụng mã thông báo để xác thực như một dịch vụ xác thực cụ thể được liên kết với mã thông báo đó. Thật không may, tôi không làm cho tài khoản dịch vụ của mình hoạt động, ngay cả khi tôi xác định phân cụm
Jürgen Zornig 16/12/19

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.