Kubernetes 1.18 adds more power, addresses shortcomings

Kubectl run restrictions

In any version before Kubernetes 1.18, a developer could use the kubectl run command to create API resources imperatively from the command line. For example, you would create a deployment like so:

kubectl run my-deployment --image=my-app-image --restart=Always

Or a CronJob like so:

kubectl run my-cronjob --schedule="*/1 * * * *" --restart=OnFailure \

  --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster"

Starting in Kubernetes 1.18, the only API resource you’ll be able to create with kubectl run is a single pod. At the production level, this won’t have too much sway if companies use manifest files to create resources in Kubernetes. But scripts that use kubectl run — in CI/CD scripts, for example — in cases such as these, will result in broken usages. Thus, companies should review their Kubneretes implementations to identify potential problems brought on by this new restriction.

Enhanced debugging

Kubernetes 1.18 introduces a new command set, kubectl debug. This command is intended to allow interactive troubleshooting. With kubectl debug, it will create an ephemeral debugging container in a pod. The debugging container can be configured to report different aspects of the activities of containers in the pod. For example, this command will create a pod named “mypod:”

kubectl debug mypod --image=debian

The pod will have a debug container that attaches to the pod based on the container image, debian. By default, the debug container will report debugging information emitted from the container being debugged.

Kubectl debug will prove to be a significant improvement to the way developers, admins and security professionals address issues in a Kubernetes cluster.

Server-side apply

The kubectl apply command is used to execute a Kubernetes manifest file against a Kubernetes cluster. For example, consider the manifest file below. It describes a pod.

apiVersion: v1
kind: Pod

metadata:
  name: static-web
  labels:
    app: web

spec:
  containers:
    – name: web
      image: nginx
      ports:
        – name: web
          containerPort: 80
          protocol: TCP

A Kubernetes YAML file, name my-pod.yaml that describes a pod

To create the pod on a Kubernetes cluster, use the kubectl apply command like so:

kubectl apply -f my-pod.yaml

Prior to Kubernetes 1.18, the information in the YAML file would be sent from the local client onto the Kubernetes API server hosted within the Kubernetes cluster. The pod creation process is then executed from within the Kubernetes control plane.

But, there’s a problem.

Under previous versions of Kubernetes, when kubectl apply is used, there is no record within the cluster of who made the change to Kubernetes resources. As a result, auditing and change management is difficult to track.

Kubernetes 1.18 will publish a new option, — server-side, which makes it so that kubectl apply is executed directly on the server. This means there will be a server-side record of who made changes to the state of the cluster and when that change was made.

The ability to determine who made a change to the cluster and when that change was made will make the work of sysadmins and DevOps personnel a lot easier.

More Windows support

Kubernetes 1.18 adds a more versatile way to assign pods that run Windows containers to Kubernetes node machines that run Windows. Added support for Windows in the API resource, RuntimeClass, makes this possible.

Here’s how to create a Windows runtime class.

apiVersion: node.k8s.io/v1beta1
kind: RuntimeClass

metadata:
  name: windows-amd64

handler: ‘docker’

scheduling:
  nodeSelector:

    kubernetes.io/os: ‘windows’
    kubernetes.io/arch: ‘amd64’
    node.kubernetes.io/windows-build: ‘10.0.18362’

  tolerations:

  – effect: NoSchedule
    key: windows
    operator: Equal
    value: “true”

The Kubernetes API, resource RuntimeClass now supports values for the Windows operating system

Once the RuntimeClass has been defined and assigned to a node, a pod can be configured with the RuntimeClass as shown below:

apiVersion: v1
kind: Pod
metadata:
  name: cool-pod
spec:
  runtimeClassName: windows-amd64
  containers:
    – name: cool-container
      image: myrepo/cool-image

Assign a pod to a Windows-specific node

Enhanced RuntimeClass support is intended to simplify the deployment process for Windows resources.

Immutable configuration

One of the big security risks to a Kubernetes cluster is the corruption of a secret. Secrets are a Kubernetes API resource that makes information available to objects in a Kubernetes cluster in an encrypted manner. If a secret is inadvertently or maliciously changed, that intrusion can bring an application that uses the secret to its knees.

Now in Kubernetes 1.18, the program has added the field, immutable to the secret specification. With the field, immutable in a secret manifest file will make the secret read-only and not subject to inadvertent change. The following shows a secret manifest with the addition of the field, immutable.

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm
immutable: true

As of Kubernetes 1.18, the immutable field will make secrets unalterable.

Along with the field addition and immutable to the Kubernetes secret specification, the field has also been added to the specification for Kubernetes ConfigMaps. Think of a ConfigMap as an unencrypted secret. Thus, not only will developers be able to secure data in Kubernetes secrets from unintended change, the same precaution can be taken with ConfigMaps.

Put it all together

Kubernetes continues to grow within the IT ecosystem as a mainstream technology. But as its popularity rises so too do the complexities that go with Kubernetes usage in production.

Fortunately, the new features introduced in Kubernetes 1.18 will address many of the challenges that Kubernetes presents to system administrators in terms of debugging, windows support and cluster security.