What You Need to Know About Kubernetes v1.19

Kubernetes 1.19 is finally out! So dust-off the single malt, grab a couple of tumblers and pull up a chair.

Ingress

Ingress was initially introduced as a beta API in version 1.1, in version 1.19, Ingress graduated to general availability and got appended to the networking API group. In a nutshell, the Ingress object and controller enable north-south traffic flow into the cluster using a layer 7 approach to control and shape traffic flow using both HTTP (not recommended) and HTTPS routes. Other features include load balancing, SSL/TLS termination, certificate embedding and health checking.

Seccomp

Seccomp also graduated to GA in K8s 1.19. First introduced in k8s 1.13, seccomp (short for secure computing mode) is a Linux kernel facility that acts like a firewall for applications attempting to make system calls by filtering the types of system calls they're allowed to make. The Kubernetes implementation of seccomp on older versions had limits. For example, seccomp profiles could only be applied via annotations on a PodSecurityPolicy object which is then applied to relevant Kubernates objects (pods, deployments, statefulsets...etc) using annotations. In the latest release however, seccomp is finally getting a first-class citizen treatment via the introduction of the new seccompProfile field on pod and container securityContext object manifests. Here is an example:

apiVersion: v1

kind: Pod

metadata:

  name: seccheck

  labels:

    app: seccheck

spec:

  securityContext:

    seccompProfile:

      type: Localhost

      localhostProfile: profiles/openscap.json

  containers:

  - name: security-audit

    image: openscap:latest

    securityContext:

      allowPrivilegeEscalation: false

Alpha debug

Although still in alpha, the kubectl alpha debug command is one of my favorites features in k8s v1.19. This command creates a new pod in the host namespace(s) to troubleshoot nodes and pods alike. Going back to the basics, we all know that pods do not allow shared namespaces and we also know that objects running pods are immutable. So when a container in a running pod is not playing nice, troubleshooting it often means redeploying the pod with a sidecar container. Next, you hope the same issue shows up and shelling into the sidecar. If I haven't lost you already and you're still reading (good on you) this is where the kubectl alpha debug command comes in. By allowing users to attach an ephemeral troubleshooting container (with their chosen container image) to a running pod, you then proceed to diagnose the problem in real-time without the need a sidecar or rely on SSH for node specific pods.  This is especially handy in cases where the pod is running a container with a distroless image. Here is an example of using the debug command to troubleshoot a running pod named alpha:

kubectl alpha debug -it pod-debugger --image=busybox --target=pods/alpha 

Support for generic ephemeral inline volumes

There are several ways to implement ephemeral volumes. Ephemeral volumes are short lived storage objects that are created for a specific container or pod and attached to the lifecycle of the object, so when an object is deleted they are deleted.

You might be asking, "So what is the problem with that?" These ephemeral volume drivers are functionally limited to the creation of native Kubernetes storage objects (EmptyDir, Secrets, ConfigMap) but what about vendor specific storage devices? A simple and horrible answer: to implement a third-party solution, write a custom driver and trick your co-workers into becoming the maintainers. 

Luckily, the kubernetes team understanding the aforementioned issues now provide an API to define inline ephemeral volumes that will work with any storage driver that supports dynamic provisioning.

kubeadm customization

Advanced configurations for kubeadm using Kustomize were initially introduced in Kubernetes 1.16 to enable IaC-like workflow by allowing users the ability to patch a base configuration with a specific profile for custom environments (dev, test, prod). A more relatable example might be how a terraform template can be customized using .tfvars for different environments.

In the latest release, Kubeadm takes the native approach of  raw patching (like kubectl).  In other words, the new flag --experimental-patches can be used to add custom options for kubeadm: kubeadm init --experimental-patches sre-eastUS-profile/.

For the time being, only patching of static pod manifests is allowed.

Increased support window

Support for Kubernetes releases will increase from nine months to 12 months. Previously, patches for minor releases were supported for up to 9 months which typically meant you would get patches for the previous three releases but as of release  1.19 this has been bumped up to one year. This is in part due to a survey conducted in 2019 by the LTS working group that discovered that a majority of k8s administrators did not upgrade within their clusters within that 9 month window leading to the bump of the support window to 12 months.

Other changes

• There is a new topology scoring function that uses the max score instead of sum of scores to better differentiate between nodes and availability zones. 
• New transition guidelines for beta features. In an effort to avoid "permanent beta" the K8s team is implementing a new policy to graduate features from beta to stable faster. Once a feature or an API enters beta, it gets a nine month lease on life after which it is either deprecated or graduated to stable (unless a new beta version is introduced.)
• Also entering beta is the Immutable Secrets and ConfigMaps objects, that were first introduced in 1.18. One of the key benefits of making objects immutable is the reduced load on the api-server.
• A security feature for the default volume mount created for service account credentials now includes the ability to add file permissions which improves the level of security when running non-root containers. 
• K8s  1.19 also includes support for JSON logging output from control-plane components by passing the flag –log-format=json.
• The 'kubeadm config upload' command is finally removed and replaced with 'kubeadm init phase upload-config.' 
• K8s 1.19 also adds support for the new TLS 1.3 ciphers.

For a full list of features and changes checkout the Kubernetes 1.19 release notes.