<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Kubernetes on sysarcher/@ich_code</title><link>https://sysarcher.github.io/categories/kubernetes/</link><description>Recent content in Kubernetes on sysarcher/@ich_code</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 22 Oct 2018 21:22:37 +0200</lastBuildDate><atom:link href="https://sysarcher.github.io/categories/kubernetes/index.xml" rel="self" type="application/rss+xml"/><item><title>Kubernetes Pod Networks and Plugins</title><link>https://sysarcher.github.io/posts/k8s-pod-networks/</link><pubDate>Mon, 22 Oct 2018 21:22:37 +0200</pubDate><guid>https://sysarcher.github.io/posts/k8s-pod-networks/</guid><description>&lt;h3 id="pod-networks"&gt;Pod Networks&lt;/h3&gt;
&lt;p&gt;It is natural that to get your first &lt;code&gt;k8s&lt;/code&gt; cluster running you&amp;rsquo;d want to remove the taint from the master node and use it as the cluster (i.e. a single-node cluster). The first thing that a person would do is not set the &lt;a href="https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#installation"&gt;kubelet network plugin (&amp;ndash;network-plugin=cni)&lt;/a&gt;. It&amp;rsquo;s certainly what I did wrong.&lt;/p&gt;
&lt;p&gt;The problem is you don&amp;rsquo;t see the problem until later because the orchestrator will use docker&amp;rsquo;s default networking which would quickly fail in a more-than-one node cluster. So, it&amp;rsquo;s best practice to immediately apply a pod network!!&lt;/p&gt;</description><content:encoded><![CDATA[<h3 id="pod-networks">Pod Networks</h3>
<p>It is natural that to get your first <code>k8s</code> cluster running you&rsquo;d want to remove the taint from the master node and use it as the cluster (i.e. a single-node cluster). The first thing that a person would do is not set the <a href="https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#installation">kubelet network plugin (&ndash;network-plugin=cni)</a>. It&rsquo;s certainly what I did wrong.</p>
<p>The problem is you don&rsquo;t see the problem until later because the orchestrator will use docker&rsquo;s default networking which would quickly fail in a more-than-one node cluster. So, it&rsquo;s best practice to immediately apply a pod network!!</p>
<h3 id="device-sharing">Device Sharing</h3>
<p>What if you want to orchestrate the usage of resources (like GPU, audio, crypto) using Kubernetes? Its best practice to create a device plugin. NVIDIA has a <a href="https://github.com/NVIDIA/k8s-device-plugin"><code>k8s-device-plugin</code></a> for it&rsquo;s GPUs. If this plugin isn&rsquo;t used, you basically end up having to install NVIDIA drivers inside the docker container and hope the host&rsquo;s version of the driver is <em>exactly</em> the same and share the devices with the container.</p>
<p>This is more elegant. Do it!</p>
]]></content:encoded></item><item><title>runc and Friends</title><link>https://sysarcher.github.io/posts/runc-and-friends/</link><pubDate>Sat, 20 Oct 2018 21:22:37 +0200</pubDate><guid>https://sysarcher.github.io/posts/runc-and-friends/</guid><description>&lt;p&gt;Had to dig a bit into Kubernetes&amp;rsquo; friends recently. Here&amp;rsquo;s a TL;DR of what&amp;rsquo;s missing from the internet today:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;runc&lt;/code&gt; is the &lt;strong&gt;CLI tool&lt;/strong&gt; for running containers (create/run/delete/&lt;del&gt;manage&lt;/del&gt;)
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;docker&lt;/code&gt; uses &lt;code&gt;runc&lt;/code&gt; as its runtime.&lt;/li&gt;
&lt;li&gt;Kubernetes uses &lt;code&gt;runc&lt;/code&gt; as its runtime through &lt;code&gt;cri-o&lt;/code&gt; (those &amp;ldquo;unsupported Docker version detected&amp;rdquo; errors you&amp;rsquo;ve probably seen.. yeah!) There&amp;rsquo;s no guarantee that &lt;code&gt;runc&lt;/code&gt; will remain &lt;code&gt;cri-o&lt;/code&gt; compatible.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;&lt;code&gt;cri-o&lt;/code&gt; is an interface for container runtimes. Any compatible runtime can be used. &lt;code&gt;runc&lt;/code&gt; is one of those others being &lt;code&gt;rkt&lt;/code&gt; (never tested it), Kata containers and I guess many more.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;containerd&lt;/code&gt; - runtime manager created by docker and later contributed to CNCF. It&amp;rsquo;s the daemon that&amp;rsquo;s running in the background doing your bidding that you pass through &lt;code&gt;runc&lt;/code&gt;.&lt;/li&gt;
&lt;/ul&gt;</description><content:encoded><![CDATA[<p>Had to dig a bit into Kubernetes&rsquo; friends recently. Here&rsquo;s a TL;DR of what&rsquo;s missing from the internet today:</p>
<ul>
<li><code>runc</code> is the <strong>CLI tool</strong> for running containers (create/run/delete/<del>manage</del>)
<ul>
<li><code>docker</code> uses <code>runc</code> as its runtime.</li>
<li>Kubernetes uses <code>runc</code> as its runtime through <code>cri-o</code> (those &ldquo;unsupported Docker version detected&rdquo; errors you&rsquo;ve probably seen.. yeah!) There&rsquo;s no guarantee that <code>runc</code> will remain <code>cri-o</code> compatible.</li>
</ul>
</li>
<li><code>cri-o</code> is an interface for container runtimes. Any compatible runtime can be used. <code>runc</code> is one of those others being <code>rkt</code> (never tested it), Kata containers and I guess many more.</li>
<li><code>containerd</code> - runtime manager created by docker and later contributed to CNCF. It&rsquo;s the daemon that&rsquo;s running in the background doing your bidding that you pass through <code>runc</code>.</li>
</ul>
]]></content:encoded></item></channel></rss>