<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Kubernetes on Jason Stangroome</title>
		<link>/tags/kubernetes/</link>
		<description>Recent content in Kubernetes on Jason Stangroome</description>
		<generator>Hugo</generator>
		<language>en</language>
		
		
		
		
			<lastBuildDate>Tue, 04 Sep 2018 22:56:37 +0000</lastBuildDate>
		
			<atom:link href="/tags/kubernetes/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>minikube with WSL kubectl</title>
				<link>/2018/09/05/minikube-with-wsl-kubectl/</link>
				<pubDate>Tue, 04 Sep 2018 22:56:37 +0000</pubDate>
				<guid>/2018/09/05/minikube-with-wsl-kubectl/</guid>
				<description>&lt;p&gt;&lt;strong&gt;Update:&lt;/strong&gt; &lt;a href=&#34;https://github.com/kubernetes/minikube/releases/tag/v0.29.0&#34;&gt;minikube 0.29.0 has been released&lt;/a&gt; and includes my &lt;a href=&#34;https://github.com/kubernetes/minikube/pull/3065&#34;&gt;merged PR&lt;/a&gt; so you can enable embedded certificates with &lt;code&gt;minikube config set embed-certs true&lt;/code&gt; once and then just symlink your &lt;code&gt;.kube/config&lt;/code&gt; file from your WSL home directory to the same file in your Windows home directory.&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;p&gt;  I recently &lt;a href=&#34;http://blog.stangroome.com/2018/06/25/minikube-and-wsl/&#34;&gt;blogged about how I work with minikube from the Windows Subsystem for Linux (WSL)&lt;/a&gt;, describing some of the friction points and workarounds. At the time I recommended using the Windows version of kubectl to avoid needing to translate the Windows file paths found in the &lt;code&gt;.kube/config&lt;/code&gt; file to be usable with the Linux version of kubectl. Also, I hadn&amp;rsquo;t at that time encountered any use cases where using the Linux kubectl inside WSL would work better than the Windows version. The first scenario most people would likely encounter with different or breaking behaviour would be passing absolute file paths, e.g. &lt;code&gt;kubectl apply -f /home/jason/my.yaml&lt;/code&gt; would usually fail to locate the file with the Windows version. This is worked around most often by using paths relative to the working directory. Another scenario where the Linux version of kubectl is preferred is the TTY support when running &lt;code&gt;kubectl exec --tty mypod&lt;/code&gt;. This was the reason I personally decided to get the Linux version of kubectl working with minikube in my WSL environment. My first approach was to copy the &lt;code&gt;.kube/config&lt;/code&gt; file that is created in my Windows user profile directory during &lt;code&gt;minikube start&lt;/code&gt;, modify the three certificate paths to be WSL-compatible paths, and save the result in my WSL home directory. Later I realised (from the files generated by &lt;code&gt;kubeadm init&lt;/code&gt; on production Kubernetes clusters) that the certificate entries in the config file don&amp;rsquo;t need to be paths, but can have the certificate content embedded as base64 blobs. Naturally I wrote &lt;a href=&#34;https://gist.github.com/jstangroome/bb72c365ca7b4199e17f7b2e72d64d14&#34;&gt;a bash script&lt;/a&gt; that I could run from WSL to perform these steps for me each time my minikube IP address or certificates changed (which to be fair, isn&amp;rsquo;t often). The script will use the translated paths approach by default but if executed with the &lt;code&gt;--embed&lt;/code&gt; parameter it will use the embedded certificates alternative. After using this solution for a while I began wondering why minikube didn&amp;rsquo;t just generate a &lt;code&gt;.kube/config&lt;/code&gt; file with embedded certificates so WSL support could be solved with a simple symlink instead of copying and rewriting the file each time it changed. So I dived into the minikube source, and &lt;a href=&#34;https://github.com/kubernetes/minikube/pull/3065&#34;&gt;raised a pull request&lt;/a&gt;, and as at the time of writing this post, the PR has been merged into master and is just awaiting an official release. Once the new version of minikube is published (or if you&amp;rsquo;re keen to build it from source yourself), you will be able to execute &lt;code&gt;minikube config set embed-certs true&lt;/code&gt; once and then minikube will always generate a &lt;code&gt;.kube/config&lt;/code&gt; file with the certificates embedded as base64 blobs. Then you can symlink your WSL &lt;code&gt;~/.kube/config&lt;/code&gt; file to your Windows &lt;code&gt;%USERPROFILE%/.kube/config&lt;/code&gt; file and use either version of kubectl with no ongoing management. PS: hat tip to &lt;a href=&#34;https://twitter.com/nunixtech&#34;&gt;Nuno do Carmo&lt;/a&gt; who also found a solution to embedding the certificates in the &lt;code&gt;.kube/config&lt;/code&gt; file by using a pair of &lt;code&gt;kubectl config ... --embed-certs&lt;/code&gt; commands. See the &amp;ldquo;Bonus 3: Do the same with Minikube&amp;rdquo; section of his extensive blog on &lt;a href=&#34;https://medium.com/@hoxunn/wslinux-k8s-the-interop-way-2d98e5b88f08&#34;&gt;WSLinux+K8S: The Interop Way&amp;quot;&lt;/a&gt;.&lt;/p&gt;</description>
			</item>
			<item>
				<title>minikube and WSL</title>
				<link>/2018/06/25/minikube-and-wsl/</link>
				<pubDate>Mon, 25 Jun 2018 12:54:14 +0000</pubDate>
				<guid>/2018/06/25/minikube-and-wsl/</guid>
				<description>&lt;p&gt;I develop services that run on Kubernetes. During development &lt;a href=&#34;https://github.com/kubernetes/minikube&#34;&gt;minikube&lt;/a&gt; provides an convenient way to run a local Kubernetes &amp;ldquo;cluster&amp;rdquo; regardless of whether you use Windows, OS X, or a Linux distribution as your host OS. Day-to-day I use minikube on Windows 10 and I prefer to use the Windows Subsystem for Linux (WSL) bash shell to have a scripting environment consistent with my colleagues, some of whom do not use Windows, and consistent with the CI system. The Linux binary of minikube isn&amp;rsquo;t very useful in WSL since it doesn&amp;rsquo;t support the Hyper-V driver and the Virtualbox driver cannot deal with the path differences it sees within WSL compared to those reported by &lt;code&gt;VboxManage.exe&lt;/code&gt;. However, when running the Windows &lt;code&gt;minikube.exe&lt;/code&gt; binary, many of the commands (e.g. &lt;code&gt;start&lt;/code&gt;, &lt;code&gt;stop&lt;/code&gt;, &lt;code&gt;ip&lt;/code&gt;, &lt;code&gt;dashboard&lt;/code&gt;) just work without any special configuration. Furthermore, creating a symlink so minikube can be executed on the PATH without the &lt;code&gt;.exe&lt;/code&gt; extension easily improves the default experience. Beyond these initial commands though, some extra effort is required. SSH can be a little flakey with &lt;code&gt;minikube ssh&lt;/code&gt; so I find it better to create an alias to use WSL&amp;rsquo;s ssh client:&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
