1. Zuhause
  2. Frage und Antwort
  3. Zugriff auf Kubernetes Dashboard nicht möglich

Zugriff auf Kubernetes Dashboard nicht möglich

2016-08-03 15 views
0

Ich habe einen Kubernetes v1.3.3-Cluster auf CoreOS basierend auf contrib repo erstellt. Mein Cluster scheint fehlerfrei zu sein, und ich möchte das Dashboard verwenden, aber ich kann nicht auf die Benutzeroberfläche zugreifen, auch wenn die gesamte Authentifizierung deaktiviert ist. Im Folgenden finden Sie Details zu den Komponenten kubernetes-dashboard sowie einige API-Serverkonfigurationen/-ausgaben. Was fehlt mir hier?Zugriff auf Kubernetes Dashboard nicht möglich

Dashboard-Komponenten

[email protected] ~ $ kubectl get ep kubernetes-dashboard --namespace=kube-system -o yaml 
apiVersion: v1 
kind: Endpoints 
metadata: 
    creationTimestamp: 2016-07-28T23:40:57Z 
    labels: 
    k8s-app: kubernetes-dashboard 
    kubernetes.io/cluster-service: "true" 
    name: kubernetes-dashboard 
    namespace: kube-system 
    resourceVersion: "345970" 
    selfLink: /api/v1/namespaces/kube-system/endpoints/kubernetes-dashboard 
    uid: bb49360f-551c-11e6-be8c-02b43b6aa639 
subsets: 
- addresses: 
    - ip: 172.16.100.9 
    targetRef: 
     kind: Pod 
     name: kubernetes-dashboard-v1.1.0-nog8g 
     namespace: kube-system 
     resourceVersion: "345969" 
     uid: d4791722-5908-11e6-9697-02b43b6aa639 
    ports: 
    - port: 9090 
    protocol: TCP 

[email protected] ~ $ kubectl get svc kubernetes-dashboard --namespace=kube-system -o yaml 
apiVersion: v1 
kind: Service 
metadata: 
    creationTimestamp: 2016-07-28T23:40:57Z 
    labels: 
    k8s-app: kubernetes-dashboard 
    kubernetes.io/cluster-service: "true" 
    name: kubernetes-dashboard 
    namespace: kube-system 
    resourceVersion: "109199" 
    selfLink: /api/v1/namespaces/kube-system/services/kubernetes-dashboard 
    uid: bb4804bd-551c-11e6-be8c-02b43b6aa639 
spec: 
    clusterIP: 172.20.164.194 
    ports: 
    - port: 80 
    protocol: TCP 
    targetPort: 9090 
    selector: 
    k8s-app: kubernetes-dashboard 
    sessionAffinity: None 
    type: ClusterIP 
status: 
    loadBalancer: {} 
[email protected] ~ $ kubectl describe svc/kubernetes-dashboard -- 

namespace=kube-system 
Name:   kubernetes-dashboard 
Namespace:  kube-system 
Labels:   k8s-app=kubernetes-dashboard 
      kubernetes.io/cluster-service=true 
Selector:  k8s-app=kubernetes-dashboard 
Type:   ClusterIP 
IP:   172.20.164.194 
Port:   <unset> 80/TCP 
Endpoints:  172.16.100.9:9090 
Session Affinity: None 
No events. 

[email protected] ~ $ kubectl get po kubernetes-dashboard-v1.1.0-nog8g --namespace=kube-system -o yaml 
apiVersion: v1 
kind: Pod 
metadata: 
    annotations: 
    kubernetes.io/created-by: | 
     {"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicationController","namespace":"kube-system","name":"kubernetes-dashboard-v1.1.0","uid":"3a282a06-58c9-11e6-9ce6-02b43b6aa639","apiVersion":"v1","resourceVersion":"338823"}} 
    creationTimestamp: 2016-08-02T23:28:34Z 
    generateName: kubernetes-dashboard-v1.1.0- 
    labels: 
    k8s-app: kubernetes-dashboard 
    kubernetes.io/cluster-service: "true" 
    version: v1.1.0 
    name: kubernetes-dashboard-v1.1.0-nog8g 
    namespace: kube-system 
    resourceVersion: "345969" 
    selfLink: /api/v1/namespaces/kube-system/pods/kubernetes-dashboard-v1.1.0-nog8g 
    uid: d4791722-5908-11e6-9697-02b43b6aa639 
spec: 
    containers: 
    - image: gcr.io/google_containers/kubernetes-dashboard-amd64:v1.1.0 
    imagePullPolicy: IfNotPresent 
    livenessProbe: 
     failureThreshold: 3 
     httpGet: 
     path:/
     port: 9090 
     scheme: HTTP 
     initialDelaySeconds: 30 
     periodSeconds: 10 
     successThreshold: 1 
     timeoutSeconds: 30 
    name: kubernetes-dashboard 
    ports: 
    - containerPort: 9090 
     protocol: TCP 
    resources: 
     limits: 
     cpu: 100m 
     memory: 50Mi 
     requests: 
     cpu: 100m 
     memory: 50Mi 
    terminationMessagePath: /dev/termination-log 
    volumeMounts: 
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount 
     name: default-token-lvmnw 
     readOnly: true 
    dnsPolicy: ClusterFirst 
    nodeName: ip-10-178-153-57.us-west-2.compute.internal 
    restartPolicy: Always 
    securityContext: {} 
    serviceAccount: default 
    serviceAccountName: default 
    terminationGracePeriodSeconds: 30 
    volumes: 
    - name: default-token-lvmnw 
    secret: 
     secretName: default-token-lvmnw 
status: 
    conditions: 
    - lastProbeTime: null 
    lastTransitionTime: 2016-08-02T23:28:34Z 
    status: "True" 
    type: Initialized 
    - lastProbeTime: null 
    lastTransitionTime: 2016-08-02T23:28:35Z 
    status: "True" 
    type: Ready 
    - lastProbeTime: null 
    lastTransitionTime: 2016-08-02T23:28:34Z 
    status: "True" 
    type: PodScheduled 
    containerStatuses: 
    - containerID: docker://1bf65bbec830e32e85e1cd9e22a5db7a2b623c6d9d7da17c747d256a9838676f 
    image: gcr.io/google_containers/kubernetes-dashboard-amd64:v1.1.0 
    imageID: docker://sha256:d023c050c0651bd96508b874ca1cd628fd0077f8327e1aeec92d22070b331c53 
    lastState: {} 
    name: kubernetes-dashboard 
    ready: true 
    restartCount: 0 
    state: 
     running: 
     startedAt: 2016-08-02T23:28:34Z 
    hostIP: 10.178.153.57 
    phase: Running 
    podIP: 172.16.100.9 
    startTime: 2016-08-02T23:28:34Z

API Server-Konfigurations

/opt/bin/kube-apiserver --logtostderr=true --v=0 --etcd-servers=http://internal-etcd-elb-236896596.us-west-2.elb.amazonaws.com:80 --insecure-bind-address=0.0.0.0 --secure-port=443 --allow-privileged=true --service-cluster-ip-range=172.20.0.0/16 --admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,ServiceAccount,ResourceQuota --bind-address=0.0.0.0 --cloud-provider=aws

API Server von Remote-Host (Laptop) zugänglich ist

$ curl http://10.178.153.240:8080/ 
{ 
    "paths": [ 
    "/api", 
    "/api/v1", 
    "/apis", 
    "/apis/apps", 
    "/apis/apps/v1alpha1", 
    "/apis/autoscaling", 
    "/apis/autoscaling/v1", 
    "/apis/batch", 
    "/apis/batch/v1", 
    "/apis/batch/v2alpha1", 
    "/apis/extensions", 
    "/apis/extensions/v1beta1", 
    "/apis/policy", 
    "/apis/policy/v1alpha1", 
    "/apis/rbac.authorization.k8s.io", 
    "/apis/rbac.authorization.k8s.io/v1alpha1", 
    "/healthz", 
    "/healthz/ping", 
    "/logs/", 
    "/metrics", 
    "/swaggerapi/", 
    "/ui/", 
    "/version" 
    ]
UI

ist nicht zugänglich remote

$ curl -L http://10.178.153.240:8080/ui 
Error: 'dial tcp 172.16.100.9:9090: i/o timeout' 
Trying to reach: 'http://172.16.100.9:9090/'

UI von Minion Knoten zugänglich ist

[email protected] ~$ curl -L 172.16.100.9:9090 
<!doctype html> <html ng-app="kubernetesDashboard">...

API Server Routing-Tabellen

[email protected] ~ $ ip route show 
default via 10.178.153.1 dev eth0 proto dhcp src 10.178.153.240 metric 1024 
10.178.153.0/24 dev eth0 proto kernel scope link src 10.178.153.240 
10.178.153.1 dev eth0 proto dhcp scope link src 10.178.153.240 metric 1024 
172.16.0.0/12 dev flannel.1 proto kernel scope link src 172.16.6.0 
172.16.6.0/24 dev docker0 proto kernel scope link src 172.16.6.1

Minion (Wo pod lebt) Routentabelle

[email protected] ~ $ ip route show 
default via 10.178.153.1 dev eth0 proto dhcp src 10.178.153.57 metric 1024 
10.178.153.0/24 dev eth0 proto kernel scope link src 10.178.153.57 
10.178.153.1 dev eth0 proto dhcp scope link src 10.178.153.57 metric 1024 
172.16.0.0/12 dev flannel.1 
172.16.100.0/24 dev docker0 proto kernel scope link src 172.16.100.1

Flanell Logs Es scheint, dass dies ein Weg mit Flanell ist misbehaving. Ich erhalte diese Fehler in den Protokollen, aber ein Neustart des Daemon scheint ihn nicht zu lösen.

...Watch subnets: client: etcd cluster is unavailable or misconfigured 

... L3 miss: 172.16.100.9 

... calling NeighSet: 172.16.100.9

Quelle

2016-08-03 smugcloud

+0

Dies ist möglicherweise ein Problem mit dem Dienst nicht definiert oder geschaffen? Können Sie versuchen, die Ausgabe von kubectl beschreiben beschreiben Svc? –

+0

Es ist definitiv auf @SantanuDey. Ich habe dem OP den Befehl describe hinzugefügt und es wird der Endpunkt 172.16.100.9 erreicht, der die Seite aufruft. – smugcloud

+0

Wenn Sie eine Antwort von erhalten: 9090 bedeutet das, dass es in Ordnung ist. Möglicherweise müssen Sie einen zusätzlichen Dienst vom Knoten-Port-Typ definieren, um auf ihn über die IP-Adresse des Knotens oder von außen zugreifen zu können. –

Antwort

1

Für alle, die ihren Weg auf diese Frage finden, wollte ich die endgültige Auflösung schreiben, da es kein Flanell, Kubernetes war, oder SkyDNS Problem, es war eine unbeabsichtigte Firewall. Sobald ich die Firewall auf dem API-Server geöffnet habe, waren meine Flannel-Routen voll funktionsfähig und ich konnte auf das Dashboard zugreifen (vorausgesetzt, die Basisauthentifizierung wurde auf dem API-Server aktiviert).

Also am Ende, Benutzerfehler :)

Quelle

2016-08-13 20:49:13 smugcloud

+0

Was hat Flannel benötigt, um richtig zu funktionieren? Vielen Dank! –

+0

Ich hatte TCP-Verkehr in der Firewall ausgesetzt, aber nicht UDP. Das Öffnen dieser Beschränkung löste es. – smugcloud

0

Wenn Sie versuchen, unter anderen Dienst wie in der Definition hinzugefügt, dann denken Sie, dass ich Sie in der Lage sein sollte, das Armaturenbrett unter Verwendung eines beliebigen des Knotens IP und der nodeport zuzugreifen, die in diesem Beispiel 30100

kind: Service 
apiVersion: v1 
metadata: 
    name: kube-expose-dashboard 
    namespace: kube-system 
    labels: 
    k8s-app: kubernetes-dashboard 
spec: 
    type: NodePort 
    ports: 
    - port: 80 
     protocol: TCP 
     nodePort: 30100 
     targetPort: 9090 
    selector: 
    app: kubernetes-dashboard

Quelle

2016-08-03 04:47:57

+2

Korrigieren. Es ist nicht notwendig, einen anderen Dienst dafür zu erstellen, aber der NodePort kann einfach durch das Patchen des bestehenden Dienstes hinzugefügt werden, zum Beispiel mit 'kubectl edit svc kubernetes-dashboard' –

1

Entweder Sie haben Ihren Dienst außerhalb des Clusters belichten einen Dienst vom Typ NodePort, wie in der vorherige Antwort erwähnt, oder wenn Sie Grund Auth auf Ihrem API Server aktiviert können Sie Ihren Dienst mit der folgenden URL erreichen:

http://kubernetes_master_address/api/v1/proxy/namespaces/namespace_name/services/service_name

See: http://kubernetes.io/docs/user-guide/accessing-the-cluster/#manually-constructing-apiserver-proxy-urls

Quelle

2016-08-03 06:52:12

+0

Danke Antoine. Ich habe eine grundlegende Auth-Datei hinzugefügt, den API-Server neu gestartet, und ich sehe immer noch die 'Error: 'wählen tcp 172.16.100.9: 9090: i/o Timeout' Der Versuch zu erreichen: 'http: // 172.16. 100.9: 9090/'' Ausgabe. Wenn ich versuche, mich mit dem base64-Benutzer zu rollen: pw, werde ich nicht autorisiert. Ich habe den NodePort versucht und konnte auch nicht auf den darunter liegenden Container zugreifen. Gibt es etwas im Proxy, das falsch konfiguriert ist? @ antoine-cotten – smugcloud

+0

Das ist, weil Sie versuchen, auf Ihre Dienst-IP zuzugreifen, die höchstwahrscheinlich nicht routingfähig in dem Netzwerk ist, in dem sich Ihre Arbeitsstation befindet! Versuchen Sie die URL, die ich gepostet habe (ersetzen Sie 'namespace_name' und' service_name'), und stellen Sie sicher, dass Sie Ihre * master * IP/Adresse verwenden –

+0

ja, das ist, was ich tue. Hier ist die vollständige URL, die ich versuche zu treffen: https://10.178.153.240/api/v1/proxy/namespaces/kube-system/services/kubernetes-dashboard/ – smugcloud

 Verwandte Themen

  • Keine verwandten Themen^_^