Kubernetes Kontrol Paneli - Giriş yaptıktan sonra bilinmeyen sunucu hatası

Kubernetes'i Kubespray aracılığıyla başarıyla dağıttım ve her şey yolunda görünüyor. Kübectl ve liste düğümleri, kapsüller, hizmetler, sırlar vb. Yoluyla kümeye erişebiliyorum. Ayrıca yeni kaynaklar uygulamak da mümkün ve gösterge tablosu bitiş noktası bana gösterge tablosu giriş sayfasını getiriyor.

Farklı servis hesaplarının jetonları ile giriş yaptım (varsayılan, kubernetes-dashboard, kubernetes-admin, ...) ... her girişle örneğin kubespray kontrol paneli uyarı yasak pop-up'larında açıklandığı gibi aynı pop-up'ları alıyorum .

Bu yüzden açıklandığı gibi varsayılan hizmet hesabı için clusterrolebinding uyguladım. Şimdi varsayılan hesap belirteciyle giriş yaptığımda, yalnızca bir

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

beni daha sonra giriş sayfasına yönlendiriyor. Bu aynı şekilde Pano üzerinden bağlanırsam aynı davranış kubectl proxy. Erişim, genel küme IP'si üzerinden HTTPS ve proxy üzerinden HTTP'dir

Kubernetes 1.16.2 ve en son Kubespray master taahhütünü 18d19d9e kullanıyorum

DÜZENLEME: Kümeyi yok ettim ve tüm adımları belirleyici hale getirmek için yeni bir Kubespray tarafından sağlanan örneği elde etmek için kümeyi yeniden oluşturdum ...

kubectl -n kube-system logs --follow kubernetes-dashboard-556b9ff8f8-jbmgg -- bir giriş denemesi sırasında bana

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.

Gösterge tablosunun çalışması için garip bir geçici çözüm buldum , ancak bu üretimde bizim için uygun değil, belki biri bunu açıklayabilir:

1. Örneğin servis hesabını alıyorum kube-system:default(Not: cluster-adminbu nokta bu noktada atanmış DEĞİLDİR)
2. Simgesini alıyorum ve bununla giriş yapıyorum
3. Gösterge Tablosu bana açıkça "yasak açılan pencereleri" gösteriyor
4. Hala giriş yapmış durumdayken koşuyorum kubectl create clusterrolebinding default-admin --clusterrole cluster-admin --serviceaccount=kube-system:default
5. Gösterge paneli oturumumu tutan tarayıcı sekmesini yeniliyorum ... ve diğerleri, her şey doğru görünüyor.

Bu nedenle oturumdan çıkıp tekrar giriş yapamıyorum, her zaman clusterrolebinding silmek zorundayım, giriş yapın ve daha sonra clusterrolebinding tekrar uygulayın.

Bu, kubespray tarafından sağlanan kümelerle güçlü bir şekilde ilişkili gibi görünüyor, bu yüzden bunu kubespray ile çoğaltabilen var mı?

Bağlanmak için sertifika kullanıyorsanız sertifikanızın sistemde olması gerekir: master grubu Yani "Subject: O = system: masters, CN ="

Ayrıca bir Jeton oluşturabilir ve ardından sertifika yerine jetonu kullanabilirsiniz:

Küme rolünüzün "Hizmet Hesabı" na bağlı olması, ancak grubunuza bağlı olmaması olasılığı vardır, yaml dosyasında grubunuzu kontrol etmelisiniz.

Bir jeton oluşturmak ve kullanmak için bunu kullanın.

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

jeton:

Şu anda kullanmakta olduğunuz sertifika yerine bu kodu kullanarak kimliğinizi doğrulamak için kubeconfig dosyasını güncelleyin; bu küme yöneticisi hizmet hesabı olarak başarıyla doğrulanmanız gerekir.

Kubernetes RBAC - ekstra ayrıcalıklar verme yasak girişimi

Tamam, bu kubespray github repo sayısında yayınlanan bir hata gibi görünüyor # 5347