K8dash Dashboard: Difference between revisions

From WilliamsNet Wiki
Jump to navigation Jump to search
m (update URL for GitHub repository)
mNo edit summary
Line 48: Line 48:
  kubectl get services -n kube-system
  kubectl get services -n kube-system


Authenticating to the dashboard requires a token from a service account with appropriate authority.  This command will retrieve an appropriate token:
Authenticating to the dashboard requires a token from a service account with appropriate authority.  While maybe not totally kosher for general purposes, this will create a service account with admin rights for this purpose:
  kubectl -n kube-system describe secrets \
 
     `kubectl -n kube-system get secrets | awk '/clusterrole-aggregation-controller/ {print $1}'` \
# Create the service account in the current namespace (we assume default)
kubectl create serviceaccount k8dash-sa
# Give that service account root on the cluster
kubectl create clusterrolebinding k8dash-sa --clusterrole=cluster-admin --serviceaccount=default:k8dash-sa
This command will retrieve an appropriate token:
  kubectl describe secrets \
     `kubectl get secrets | awk '/k8dash-sa/ {print $1}'` \
     | awk '/token:/ {print $2}'
     | awk '/token:/ {print $2}'



Revision as of 16:17, 12 July 2020

This is an alternate dashboard developed by Eric Herbrandson and hosted at GitHub. It has multiple advantages over the default dashboard:

  • automatic refresh
  • more responsive
  • uses data provided by the kubernetes metrics-server

Instructions for installing the original dashboard are located here.

Prerequisites

While not required, the Metrics Server is very useful and provides a LOT of good data on system capacity

Installing the Dashboard

The dashboard is deployed using a single manifest:

kubectl apply -f https://raw.githubusercontent.com/herbrandson/k8dash/master/kubernetes-k8dash.yaml

As it stands, the dash board is not accessible from off-cluster, and requires something else (like an ingress) to provide the outside access. Given that an ingress is NOT part of the standard cluster configuration, I prefer to use LoadBalancer services to get an IP address for off-cluster use. Download and modify the above manifest so that the service looks like this:

wget https://raw.githubusercontent.com/herbrandson/k8dash/master/kubernetes-k8dash.yaml
kind: Service
apiVersion: v1
metadata:
  name: k8dash
  namespace: kube-system
spec:
  ports:
    - port: 80
      targetPort: 4654
  selector:
    k8s-app: k8dash
  type:  LoadBalancer
  loadBalancerIP: <dashboard-address>

The only difference is adding the 'type' and 'loadBalancerIP' definitions at the end. Preconfigured manifests for each cluster are in the repository:

filename address
kubernetes-k8dash-prod.yaml 10.0.0.110
kubernetes-k8dash-dev.yaml 10.0.0.200
kubernetes-k8dash-test.yaml 10.0.0.190

After the change is made, apply it:

kubectl apply -f <filename>

At this point, you have the dashboard running and waiting for you to log in. To verify the external IP address for the dashboard, use kubectl:

kubectl get services -n kube-system

Authenticating to the dashboard requires a token from a service account with appropriate authority. While maybe not totally kosher for general purposes, this will create a service account with admin rights for this purpose:

# Create the service account in the current namespace (we assume default)
kubectl create serviceaccount k8dash-sa

# Give that service account root on the cluster
kubectl create clusterrolebinding k8dash-sa --clusterrole=cluster-admin --serviceaccount=default:k8dash-sa

This command will retrieve an appropriate token:

kubectl describe secrets \
   `kubectl get secrets | awk '/k8dash-sa/ {print $1}'` \
   | awk '/token:/ {print $2}'

Run that command in a terminal window, and paste the results in as a 'token' in the dashboard login page -- it's a multi-line hash -- be warned. Using this token will give full cluster admin rights to the dashboard.

if you get an error message instead of a login screen, you're probably using a browser with an existing (now defunct) cookie for a previous installation. Click on the account icon in the upper right corner and sign out ... then you can log in with the new token.

The current tokens for the current clusters are stored in their respective configuration pages: