doddle / lander

a generic landing page for k8s clusters

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Lander

A kubernetes (cluster) landing page

Features/progress

  • golang powered interactings with k8s
  • Simple server-side caching to keep kube-api calls limited.
  • List nodes
  • Configurable list of node labels to show table (Similar to kubectl get nodes -L beta.kubernetes.io/arch -L beta.kubernetes.io/os -L beta.kubernetes.io/instance-type you'd run lander with -l ,beta.kubernetes.io/instance-type)
  • VueJS based PWA/SPA
  • Show links to cluster ingress endpoints based on if it has lander annotations, add the annotation lander.doddle.tech/show="true" to the ingress objects.
  • Unique "identicon" favicons generated against hostname (nicer+predictable bookmarks for multiple k8s clusters)
  • Identicons themed with the colours you decide (see: -hex when deploying lander)
  • search all the Ingresses in the current context cluster
  • "at-a-glance" piechart for Deployments
  • "at-a-glance" piechart for StatefulSets
  • "at-a-glance" piechart for Nodes
  • "at-a-glance" piechart for DaemonSets
  • Basic node information (age, labels, Ready and Unscheduable)
  • front-end settings (colorscheme etc) configurable via launch options. We use different colours to hint at our kubernetes "lifecycles" (dev, staging, prod, etc..)
  • Links will indicate a lock icon if nginx-ingress and oauth2proxy protection was detected on ingress.
  • Allow users to search all Ingress rules and see what hostnames/paths are mapped to which services
  • provide information about the api-groups and supported api's detected
  • provide basic cluster info such as the k8s version etc.. probably worth add a column for this to the nodes tab
  • Represent to the user any objects detected in the cluster that have weave/flux ignore annotations (EG: potential state-drift from gitops definitions.)
  • Make use of more elegant k8s APIs like long-polling or watches instead of brute-force retrieving all objects
  • Some more pragmatic support for older AND newer versions of some APIs (I'm looking at you v1beta1/ingress;-) )
  • a basic idea about CPU/MEM pressure on nodes would be useful, maybe its worth pulling some metrics data?
  • global setting for users to toggle for darkmode (need some state storage in browser)
  • countdown for when some data is going to be reloaded
  • configurable poll frequency?
  • "News/Status" section (pulls intel from an SRE status feed example?).. EG: maintenance on mongodb in eu prod today at 14:00 GMT..
  • Custom graphs where we can represent some simple prometheus queries?
  • represent some interesting data.. EG: "there are X pods with -lruntime=golang and Y pods with -lruntime=nodejs" This could be extremely useful when using labels to track (for example) systems that need migration for example.. There are still X apps on this cluster with the label wip="true"` Giving k8s consumers a real feeling for the progress of their work would be really cool.

Runtime flags

  -annotationBase string
    	The base of the annotations used for lander. e.g. lander.doddle.tech for annotations like lander.doddle.tech/show (default "lander.doddle.tech")
  -clusterFQDN string
    	The cluster this lander is operating in. Used for display and identicon purposes only. (default "k8s.example.com")
  -clusters string
    	comma seperated list of clusters (default "cluster1.example.com,cluster2.example.com")
  -color string
    	Main color scheme (See: https://vuetifyjs.com/en/styles/colors/#material-colors) (default "light-blue lighten-2")
  -debug
    	debug
  -hex string
    	identicon color, hex string, eg #112233, #123, #bAC (default "#26c5e8")
  -labels string
    	comma seperated list of node labels you care about (default "kubernetes.io/role,node.kubernetes.io/instance-type,node.kubernetes.io/instancegroup,topology.kubernetes.io/zone")

local development

To run or develop lander follow the next steps:

running the VueJS front-end

The frontend listens on :8080 and will proxy traffic -> localhost:8000 in development mode.

Simply:

cd frontend
npm i --from-lockfile
npm run serve

Good.. now that the front-end is running.. launch the backend:

running the backend

The backend listens on :8000 and will read assets from a relative path of: ./frontend/dist

NOTE: before launching the backend, either mkdir ./frontend/dist or run cd frontend ; npm run build needless to say if you make an empty directory, don't expect lander to render a pretty website (but its APIs should still work.)

The golang app supports a few flags..:

  • -annotationBase the base of the annotations to use. Appended with /show to figure the annotations above
  • -clusterFQDN The cluster this lander is operating in. Used for display and identicon purposes only.
  • -hex the hex colour to be used for the identicon.. EG: #26c5e8, #123, #b2C
  • -color the colorscheme (vuetify) to be handed to the frontend.. See: material-colors

If you run this locally on your computer it will auto-detect your $KUBECONFIG and use the current context.

go run .

curl it and see if u get any endpoints detected

curl localhost:8000/v1/endpoints

NOTE: opening :8000 in your web browser won't render anything until after you've run npm run build in the frontend. For local-development of the UI we recommend using the VueJS steps above.

Adding a link

You'll need to add an annotation to an ingress to see it in the "Links" section

For example.. In the following example we add:

  1. the annotation lander.doddle.tech/show="true"
  2. to an ingress called prometheus
  3. in the namespace monitoring
export NAMESPACE=monitoring
export INGRESS=prometheus
kubectl annotate \
  -n $NAMESPACE \
  ingress/$INGRESS \
  lander.doddle.tech/show="true" --overwrite

Landers cache may not make the result show up immediately, but if you restart the golang api or wait a minute you should be able to see a link now

TODOS:

Nice-to-haves/ideas for the future:

  • allow adding your own icons
  • more documentation
  • more tests
  • as this will live behind oauth2proxy like many other components, we can determine their username/email.. greet them
  • maybe pull some basic info from RBAC if we're able to determine their github groups (EG hello <persons name>.. you have X namespaces you can play with on this cluster)
  • some information about cronjobs (or some CRDs potentially)

About

a generic landing page for k8s clusters

License:Apache License 2.0


Languages

Language:Go 58.2%Language:Vue 32.1%Language:JavaScript 4.7%Language:Makefile 2.1%Language:Dockerfile 2.0%Language:HTML 0.9%