By default, the JVM’s maximum heap size is 1/4 of the physical memory available - you can read about this in the Oracle GC tuning guide. This means that if you don’t define -Xmx in your JVM parameters, the container will set 1/4 of the host memory as the maximum heap size.

On a recent enough JVM (8u191+ and 10+), the JVM is container-aware: if you set a Kubernetes resource limit, the JVM uses that limit rather than the host’s memory to size the heap. So your maximum heap size becomes 1/4 of your Kubernetes resource limit.

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.

Create a Service Account using the YAML below.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-app-name
  namespace: namespace-name

Once the Service Account is created, you can reference it in your pod spec:

apiVersion: v1
kind: Pod
metadata:
  name: app-name
spec:
  serviceAccountName: sa-app-name

Now on to Kubernetes Secrets. A Secret lets you store and manage sensitive information. Here we’ll create two secrets for our tests: mysecret1 and mysecret2. Note the --- separator - without it, the second document silently overwrites the first.

This talk by Dawid Ziolkowski at DevOpsDays Warsaw is a clear introduction to Istio. If you’ve heard of service meshes but never quite grasped what problems they solve, it’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.

In this talk, Paavan Mistry explains how to encrypt Kubernetes secrets at rest in etcd 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 AWS KMS envelope encryption to protect secrets at rest, which is an easy win for anyone running EKS in production.