Jeremy Davis
Sitecore, C# and web development
Before Christmas I was working out how to spin up custom Sitecore images in AKS. Since I'm fairly new to containers generally and this was my first time running them remotely, I messed up. A lot. So I spent quite a bit of time trying to work out what it was I'd messed up. I found these commands particularly useful to work out what was wrong:
The most common thing I found myself wanting to do for debugging was to see what's being recorded in the logs being streamed out of the containers. Just like your local Docker images, K8s can pass you this log data. But you need to tell it which pod you want to see the log data for:
kubectl.exe logs cm-864d7c4c4-d4smb -n your-namespace -f
The
-f
here is basically "tail" – it will keep showing you logs until you stop the kubectl command. If you need a hint about the pod names, you can run
kubectl.exe get pods -n your-namespace
to see a list of all the stuff running in your namespace. (This is also useful for the two other commands I'm commenting on below)
If you get bored of typing this (and I did – as I found myself doing this a lot) then you should investigate the "k9s" tool – which gives you an easier way to browse pods, and view their logs.
I found there tended to be a bit of a pause between an event happening in the container and the log data getting reported back to me – so you may need to apply a bit of patience here while you debug.
By default, the only services exposed outside of your K8s instance are those where you configured it to have an ingress endpoint, or you opened ports directly. For a default setup of Sitecore, that's the CM and CD web servers on port 443.
But what if you want to check xConnect is up without letting all of the internet see it? Or (in non-prod scenarios) talk to SQL Server or Solr? You need "port forwarding"! For example, to be able to web browse Solr in a specific pod:
kubectl.exe port-forward pod/solr-864d7c4c4-p8rsq 9999:8983 -n your-namespace
That will make the local address
127.0.0.1:9999
magcially connect into your cluster, and connect to the Solr pod in your names on its port 8983. So you can open a web browser to
http://127.0.0.1:9999
on your computer and browse the Solr UI.
As long as kubectl is running this command, you'll be able to connect. To end the connection, just hit Ctrl-C in your shell window.
Note that you can't use "localhost" here – it has to be "127.0.0.1".
And it's not just tied to connecting to pods – you can connect to services or deployments in a similar fashion too.
Sometimes you just want to nose around inside a running container. Viewing a log file that's not exported to the k8s log stream maybe? Or checking that a specific file or config setting is actually present? Or running a script...
In this scenario, you need to "exec" a command in your container.
kubectl.exe exec --stdin --tty mssql-7794b4b5cc-hhc24 -n your-namespace -- powershell.exe
Takes a while to type this one – you may want to make some sort of shortcut... But pay attention to the whitespace here – the final
--
has spaces either side of it.
That will connect your local shell window to "powershell.exe" in the container. Much like
exec
in Docker whatever you type gets sent to the container, and whatever it displays gets sent back to you. But in this case it's done across the network to wherever your Kubernetes instance is running. And of course you don't have to run PowerShell – any command-line tool should work.
To get back to your normal local prompt, you just end the command you ran – so
exit
will quit the remote PowerShell, but other commands may be appropriate for different tools.
Just remember that while you can change things on disk in the container, by default nothing is permenent in Kubernetes. Unless you specifically set up a pod or a mounted folder as persistent, any changes you make will vanish as soon as your pod is replaced for any reason. So it's best to make changes in your images most of the time.
↑ Back to top