<?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 Opslifeuk Limited</title><link>https://opslife.co.uk/tags/kubernetes/</link><description>Recent content in Kubernetes on Opslifeuk Limited</description><generator>Hugo</generator><language>en-gb</language><lastBuildDate>Sat, 13 Jun 2020 17:40:34 +0100</lastBuildDate><atom:link href="https://opslife.co.uk/tags/kubernetes/index.xml" rel="self" type="application/rss+xml"/><item><title>Kubernetes Resource Limits and JVM Heap Size</title><link>https://opslife.co.uk/kubernetes/memory/</link><pubDate>Sat, 13 Jun 2020 17:40:34 +0100</pubDate><guid>https://opslife.co.uk/kubernetes/memory/</guid><description>&lt;p&gt;By default, the JVM&amp;rsquo;s &lt;code&gt;maximum heap size&lt;/code&gt; is 1/4 of the physical memory available - you can read about this &lt;a href="https://docs.oracle.com/javase/9/gctuning/parallel-collector1.htm#JSGCT-GUID-74BE3BC9-C7ED-4AF8-A202-793255C864C4"&gt;in the Oracle GC tuning guide&lt;/a&gt;. This means that if you don&amp;rsquo;t define &lt;code&gt;-Xmx&lt;/code&gt; in your JVM parameters, the container will set &lt;code&gt;1/4&lt;/code&gt; of the host memory as the &lt;code&gt;maximum heap size&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;On a recent enough JVM (8u191+ and 10+), the JVM is container-aware: if you set a Kubernetes &lt;code&gt;resource limit&lt;/code&gt;, the JVM uses that limit rather than the host&amp;rsquo;s memory to size the heap. So your &lt;code&gt;maximum heap size&lt;/code&gt; becomes &lt;code&gt;1/4&lt;/code&gt; of your Kubernetes &lt;code&gt;resource limit&lt;/code&gt;.&lt;/p&gt;</description></item><item><title>Kubernetes Service Accounts and Secrets - Mounting Secrets as Volumes</title><link>https://opslife.co.uk/kubernetes/secrets/</link><pubDate>Fri, 12 Jun 2020 14:00:33 +0100</pubDate><guid>https://opslife.co.uk/kubernetes/secrets/</guid><description>&lt;p&gt;A Service Account provides an identity for processes that run in a pod. When processes inside a pod contact the API server, they are authenticated as a particular Service Account.&lt;/p&gt;
&lt;p&gt;Create a Service Account using the YAML below.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"&gt;&lt;code class="language-yaml" data-lang="yaml"&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#f92672"&gt;apiVersion&lt;/span&gt;: &lt;span style="color:#ae81ff"&gt;v1&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#f92672"&gt;kind&lt;/span&gt;: &lt;span style="color:#ae81ff"&gt;ServiceAccount&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#f92672"&gt;metadata&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &lt;span style="color:#f92672"&gt;name&lt;/span&gt;: &lt;span style="color:#ae81ff"&gt;sa-app-name&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &lt;span style="color:#f92672"&gt;namespace&lt;/span&gt;: &lt;span style="color:#ae81ff"&gt;namespace-name&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Once the Service Account is created, you can reference it in your pod spec:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"&gt;&lt;code class="language-yaml" data-lang="yaml"&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#f92672"&gt;apiVersion&lt;/span&gt;: &lt;span style="color:#ae81ff"&gt;v1&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#f92672"&gt;kind&lt;/span&gt;: &lt;span style="color:#ae81ff"&gt;Pod&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#f92672"&gt;metadata&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &lt;span style="color:#f92672"&gt;name&lt;/span&gt;: &lt;span style="color:#ae81ff"&gt;app-name&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#f92672"&gt;spec&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &lt;span style="color:#f92672"&gt;serviceAccountName&lt;/span&gt;: &lt;span style="color:#ae81ff"&gt;sa-app-name&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Now on to Kubernetes Secrets. A Secret lets you store and manage sensitive information. Here we&amp;rsquo;ll create two secrets for our tests: &lt;code&gt;mysecret1&lt;/code&gt; and &lt;code&gt;mysecret2&lt;/code&gt;. Note the &lt;code&gt;---&lt;/code&gt; separator - without it, the second document silently overwrites the first.&lt;/p&gt;</description></item><item><title>Istio Masterclass</title><link>https://opslife.co.uk/talks/istio/</link><pubDate>Sun, 07 Jun 2020 00:54:42 +0100</pubDate><guid>https://opslife.co.uk/talks/istio/</guid><description>&lt;div style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;"&gt;
			&lt;iframe allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen" loading="eager" referrerpolicy="strict-origin-when-cross-origin" src="https://www.youtube.com/embed/Z0X0NmVXk0g?autoplay=0&amp;amp;controls=1&amp;amp;end=0&amp;amp;loop=0&amp;amp;mute=0&amp;amp;start=0" style="position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;" title="YouTube video"&gt;&lt;/iframe&gt;
		&lt;/div&gt;

&lt;p&gt;This talk by Dawid Ziolkowski at &lt;strong&gt;DevOpsDays Warsaw&lt;/strong&gt; is a clear introduction
to &lt;strong&gt;Istio&lt;/strong&gt;. If you&amp;rsquo;ve heard of service meshes but never quite grasped what
problems they solve, it&amp;rsquo;s a good place to start - it covers what a mesh gives
you (traffic management, observability and mutual TLS between services) and how
Istio implements it on top of Kubernetes.&lt;/p&gt;</description></item><item><title>Encrypting Secrets in Amazon EKS</title><link>https://opslife.co.uk/talks/secrets/</link><pubDate>Sun, 07 Jun 2020 00:24:41 +0100</pubDate><guid>https://opslife.co.uk/talks/secrets/</guid><description>&lt;div style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;"&gt;
			&lt;iframe allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen" loading="eager" referrerpolicy="strict-origin-when-cross-origin" src="https://www.youtube.com/embed/d21JrnszG7Y?autoplay=0&amp;amp;controls=1&amp;amp;end=0&amp;amp;loop=0&amp;amp;mute=0&amp;amp;start=0" style="position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;" title="YouTube video"&gt;&lt;/iframe&gt;
		&lt;/div&gt;

&lt;p&gt;In this talk, Paavan Mistry explains how to encrypt Kubernetes secrets at rest
in &lt;strong&gt;etcd&lt;/strong&gt; on Amazon EKS. By default, Kubernetes stores secrets only
base64-encoded - not encrypted - so anyone who gains access to the API server
or to etcd can read them in the clear. The talk shows how to use &lt;strong&gt;AWS KMS
envelope encryption&lt;/strong&gt; to protect secrets at rest, which is an easy win for
anyone running EKS in production.&lt;/p&gt;</description></item></channel></rss>