Over the last few days I noticed that when I use kubectl to manage a k8s test cluster in Azure, it takes forever to actually carry out the operations remotely. Today I took some time to debug this. Here’s how to fix a slow kubectl on Windows.<\/p>\n
I started with changing the log level, and capturing the details, like this:<\/p>\n
\r\nkubectl get pods -v=20\r\n<\/pre>\nThe good news is, given that the commands worked so slowly, I had enough time to just read what was going on, and even understand where the problem was. If it’s not so slow, it helps to redirect stderr to a file, like this:<\/p>\n
\r\nkubectl get pods -v=20 2> err.txt\r\n<\/pre>\nIn my case, it turned out that the command was going through a cache which was on the H: drive. That may not mean much to you, but my employer’s IT maps the H: drive to the (remote) home directory. They also set the HOMEDRIVE, HOMEPATH and HOMESHARE environment variables on login. HOMEDRIVE in particular is set to H:. Given that Windows (unlike Linux) by default doesn’t come with a HOME environment variable, kubectl for Windows tries to make up by constructing the HOME path using HOMEDRIVE and HOMEPATH. So kubectl ended up caching everything on a remote share, some 8500 km away. Needless to say, the lag between my workstation and the remote share is noticable.<\/p>\n
How to fix Slow kubectl on Windows<\/h2>\n
So, how do you fix this? Well, it’s actually very easy: set the HOME environment variable to a local directory, run kubectl again, and now it’s a lot faster. In PowerShell, for that session, I just did<\/p>\n
\r\n$env:HOME = $env:USERPROFILE\r\n<\/pre>\nNow what’s left for me is to try and convince the IT department to stop using the HOMEDRIVE and HOMESHARE for remote users. That’s the tough part \ud83d\ude09<\/p>\n
<\/p>","protected":false},"excerpt":{"rendered":"