Aan de slag met Kubernetes Dashboard UI

Ik liep tegen een wel heel bijzonder probleem aan toen ik merkte dat ik mijn WSO2 Identity Server Docker container niet kon opstarten omdat één van de toegewezen poorten in gebruik was door mijn systeem. In deze blog laat ik je het probleem zien en hoe je het met Kubernetes Dashboard UI op kunt lossen.

Toen ik de IS-container opstartte, kreeg ik een error dat de ‘bind port’ al in gebruik was. Het ging om de 9443 admin-console port. Ik schakelde gelijk naar mijn terminal om te controleren welk (Mac)OS proces deze poort claimde.

sudo lsof -n -i4TCP:9443 | grep LISTEN

Het resultaat was… niets. Dat was apart, want zoiets was me nog nooit overkomen.

Kubernetes cluster

Ik besefte me dat ik een tijdje terug een deployment op mijn lokale Kubernetes cluster had gecreëerd. Misschien runde die nog steeds en was de poort daarom nog bezet. Toen ik mijn lokale Kubernetes cluster uitzette kon ik inderdaad de WSO2 Identity Server container zonder problemen opstarten. Zo bleek dat Kubernetes de poort daadwerkelijk claimde.

Het uitschakelen van de lokale Kubernetes cluster was een workaround, maar geen duurzame oplossing en dus startte ik de Kubernetes cluster opnieuw op om te zien of ik kon achterhalen welke service of deployment nu werkelijk de poort claimde.

Nadat ik de cluster opgestart had, voerde ik deze opdracht uit:

kubectl get deployments -all-namespaces=true

en zo bleek dat er een aantal deployments waren die op zo’n manier gedefinieerd waren dat ze deze poort konden gebruiken. Ik moest een aantal commando’s uitvoeren om te bepalen welke service het precies was die deze poort nodig had en verwijderde de deployment uiteindelijk helemaal, omdat hij toch al verouderd was.

Om door de kubectl commando’s te gaan om de klus te klaren, kan voor sommigen wellicht wat overweldigend zijn en dan is het wel zo prettig om een user interface te hebben waarin je de informatie die je zoekt kunt vinden.

Voor Docker is er een bekende UI die Portainer heet, maar er is ook een Kubernetes alternatief. Dat heet Kubernetes dashboard en is beschikbaar als importeerbare Kubernetes configuratie. Er zijn een aantal stappen nodig om toegang tot dit dashboard te krijgen.

Het starten van het dashboard op zich is gemakkelijk en doe je door de dashboard configuratie aan je kluster toe te voegen met:

kubectl apply -f

https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta1/aio/deploy/recommended.yaml

​Hierdoor wordt er een deployment en een service toegevoegd aan de kubernetes-dashboard namespace in de Kubernetes-cluster.

Vervolgens kun je de kubernetes proxy starten om toegang te krijgen tot de UI.

kubectl proxy

Voilà, het dashboard zou nu beschikbaar moeten zijn op: http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

Wanneer het dashboard opent krijg je een inlogscherm te zien. Op dit scherm zul je een kubeconfig bestand of een toegangstoken moeten invoeren.

Dat zijn de twee mogelijkheden om in te loggen op het dashboard.

De mogelijkheid met het geheime token kun je opvragen door verschillende kubectl commando’s te gebruiken en de andere mogelijkheid werkt met een gegenereerd kubeconfig bestand waar de inloggegevens in staan. De eerste geeft je inzicht in hoe het serviceaccount opgebouwd is, welke rollen en geheimen het bevat, de tweede is eenvoudiger op lange termijn, omdat het kubeconfig bestand blijvend is en makkelijker is om vaker te gebruiken.

Token

Om te beginnen met de eerste optie voor het instellen van een nieuw account om in te loggen op het Kubernetes dashboard zullen we een serviceaccount moeten hergebruiken of een nieuwe moeten aanmaken door een cluster role binding aan te bieden en dan de geheime token moeten vinden. De tokenwaarde kan daarna in het wachtwoordveld van het inlogscherm geplakt worden en het inloggen zou moeten lukken.

Het volgende commando kan gebruikt worden om het serviceaccount, dat we dashuser noemen, te maken. Voor het gemak maken we het account in de default namespace met:

kubectl create serviceaccount dashuser -n default

Om het meeste uit de UI te halen is het het makkelijkst om een account te hebben dat ook de admin van het cluster kan zijn en daardoor de dashuser een root-like access geeft.

Dit is mogelijk door een cluster role binding van de cluster-admin te verbinden aan de dashuser.

kubectl create clusterrolebinding dashboard-admin -n default
--clusterrole=cluster-admin --serviceaccount=default:dashuser

Hierdoor wordt een clusterrolebinding die dashboard-admin heet in de default namespace gemaakt, waarbij de cluster role cluster-admin eraan verbonden wordt en de binding van toepassing wordt op het serviceaccount default:dashuser.

Dit zou voldoende moeten zijn om met deze gebruiker toegang tot het dashboard te krijgen.

Om nu op het dashboard te komen hebben we het toegangstoken van dit serviceaccount nodig. Dit toegangstoken zit in de secret-store van de dashuser. Het werd automatisch gegenereerd toen we de gebruiker aanmaakten en je moet het uitlezen om in te kunnen loggen.

Om de geheime naam van het serviceaccount te weten te komen vragen we de gegevens ervan op

kubectl get serviceaccount dashuser -o json

Dit geeft ons (ingekort):

...
"secrets": [
   { 
      "name": "dashuser-token-np6c6"
   }
]...

Om dan de geheime waarde te krijgen, kunnen we deze naam als parameter in het volgende commando gebruiken:

kubectl get secret dashuser-token-np6c6 -o json

In de output zou er een dataveld moeten zijn met een tokenelement dat de waarde van het gevraagde token in base64 codering bevat. Kopieer de waarde, decodeer de base64 code en dan heb je de waarde die je in het inlogscherm van het dashboard kunt opgeven.

Het volgende commando is een simpele dynamische one-liner die de bovenstaande drie commando’s combineert in één enkele regel:

kubectl get secret $(kubectl get serviceaccount dashuser -o

Zo krijg je het token om in te loggen op het dashboard. Kopieer de waarde en plak het in het inputveld op het dashboard in je browser en je zou moeten kunnen inloggen.

Voor alle volgende keren dat je in wil loggen op het dashboard zul je dat laatste commando opnieuw moeten uitvoeren om de tokenwaarde te krijgen die je in het inlogscherm kunt plakken.

Kubeconfig

De andere optie is het maken van een kubeconfig bestand dat de inloggegevens voor het dashboard. Om dit kubeconfig bestand te maken zullen we enkele van de bovenstaande commando’s gebruiken en de uitkomsten ervan in een json-structuur zetten om die vervolgens in het kubeconfig bestand te kunnen plaatsen.

Op Stackoverflow staat een waardevolle snippet voor het maken van dit kubeconfig bestand in de vorm van een eenvoudig shell script. Ik heb de snippet licht aangepast om het, naar mijn mening, iets gebruiksvriendelijker te maken. In deze versie kun je de naam van het serviceaccount bepalen in plaats van de naam van het token.

# your server name goes here
server=https://localhost:8443
# the name of the service account goes here
name=dashuser

# Enable this line if you’ve use a custom namespace for the user. This will switch the current namespace to the designated one. 
#kubectl config set-context $(kubectl config current-context) --namespace=default

secretname=$(kubectl get serviceaccount $name -o jsonpath="{.secrets[0].name}")
ca=$(kubectl get secret/$secretname -o jsonpath='{.data.ca.crt}' )
token=$(kubectl get secret/$secretname -o jsonpath='{.data.token}' | base64 --decode)
#namespace=$(kubectl get secret/$secretname -o jsonpath='{.data.namespace}' | base64 --decode)

echo "
apiVersion: v1
kind: Config
clusters:
- name: default-cluster
 cluster:
certificate-authority-data: ${ca}
server: ${server}
contexts:
- name: default-context
 context:
 cluster: default-cluster
 namespace: default
 user: default-user
current-context: default-context
users:
- name: default-user
 user:
 token: ${token}
" > sa.kubeconfig

Het script zal in de huidige map een bestand aanmaken met de naam sa.kubeconfig. Ga terug naar de browser en kies voor de Kubeconfig optie en gebruik dit bestand om in te loggen.

Als je een foutmelding zoals deze krijgt:

dan is het kubeconfig bestand onvolledig. Controleer of het bovenstaande script de juiste naam voor het serviceaccount bevat en dat ook de juiste namespace gebruikt is om de geheime gegevens van het serviceaccount te vinden.

Dashboard

Het dashboard geeft een overzicht van de volledige clusterconfiguratie. Gegevens zoals de namespaces, deployments, services en replica-sets zijn er zichtbaar.

Het is een waardevolle tool om in je toolbox te hebben als je Kubernetes gebruikt, omdat het snelle toegang geeft tot een overzicht van de componenten in de cluster waar je ook een aantal managementhandeling op uit kunt voeren.

Ben je geïnteresseerd geraakt om verder te lezen over Kubernetes? Lees dan ook mijn andere blog over Kubernetes en de WSO2 Enterprise Integrator. Heb je vragen? Neem dan gerust contact op.