Kubernetes 1.18: Key Features That Address Real-World Shortcomings

Kubernetes is a powerful container orchestration platform, but every major version surfaces areas where day-to-day operations are still harder than they should be. Kubernetes 1.18 targeted several of those pain points head-on: debugging ergonomics, change auditing, Windows node scheduling, and configuration integrity. This article walks through the most significant additions in that release.

kubectl run Is Now Pod-Only

In every Kubernetes release before 1.18, kubectl run could imperatively create several different API resource types from the command line. Depending on the flags you passed, it would create a Deployment, a CronJob, or other resource kinds. For example:

# Pre-1.18: created a Deployment
kubectl run my-deployment --image=my-app-image --restart=Always

# Pre-1.18: created a CronJob
kubectl run my-cronjob --schedule="0 * * * *" --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster"Code language: PHP (php)

Starting with Kubernetes 1.18, kubectl run creates only a single Pod. All other resource types must be created with their dedicated commands (kubectl create deployment, kubectl create cronjob, and so on) or through manifest files applied with kubectl apply.

For teams that already rely on declarative manifest files in production, the practical impact is minimal. However, CI/CD pipelines and automation scripts that use kubectl run to create Deployments or CronJobs will break after upgrading. Before migrating to 1.18, audit every script and pipeline that calls kubectl run and refactor those calls to use the appropriate imperative commands or YAML manifests.

Enhanced Debugging with kubectl debug

Debugging containers in Kubernetes has historically been awkward. If a container crashes on startup, you cannot exec into it. If a minimal production image does not include debugging tools, you are stuck. Kubernetes 1.18 introduced kubectl debug as an alpha feature to address this directly.

kubectl debug injects an ephemeral container into a running pod. Ephemeral containers share the pod’s network and process namespaces, giving you a debugging environment alongside your production container without modifying the original pod spec. A basic invocation looks like this:

kubectl debug mypod --image=debian

This attaches a Debian-based ephemeral container to the pod named mypod. From inside that container you can use standard Linux debugging tools — strace, curl, tcpdump, and so on — without those tools ever needing to exist in your production image. The ephemeral container disappears when the pod is deleted or restarted, leaving no persistent footprint.

This capability is meaningful not just for developers but also for security teams performing live incident response and for SREs diagnosing production issues under time pressure.

Server-Side Apply: Auditable Change Management

The standard kubectl apply -f workflow sends a manifest to the Kubernetes API server and the cluster reconciles the desired state. Consider this simple pod manifest:

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    app: web
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCPCode language: JavaScript (javascript)

kubectl apply -f my-pod.yamlCode language: CSS (css)

Before 1.18, this client-side apply left no server-side record of who made the change or when. That gap made auditing and change management difficult, particularly in regulated environments.

Kubernetes 1.18 introduced the --server-side flag for kubectl apply:

kubectl apply -f my-pod.yaml --server-sideCode language: CSS (css)

With server-side apply, the API server itself performs the field management and records field ownership — tracking which manager last set each field and when. This produces a verifiable, server-resident audit trail and also helps resolve conflicts when multiple controllers or operators manage overlapping fields on the same resource.

Improved Windows Node Support via RuntimeClass

Kubernetes was originally built for Linux. Running Windows workloads has been possible for several releases, but scheduling Windows pods reliably onto Windows nodes required workarounds. Kubernetes 1.18 improved this by adding Windows-specific fields to the RuntimeClass API resource, including node selector and toleration support directly within the RuntimeClass spec.

Define a Windows RuntimeClass:

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"Code language: JavaScript (javascript)

Then reference that RuntimeClass in a pod spec:

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

By centralising the node selector and toleration logic inside the RuntimeClass definition, platform teams no longer need to add Windows-specific scheduling directives to every individual pod or deployment spec. A single RuntimeClass object encapsulates that policy for all pods that reference it.

Immutable Secrets and ConfigMaps

Kubernetes Secrets store sensitive data — credentials, tokens, certificates — that applications consume at runtime. ConfigMaps store non-sensitive configuration data. In both cases, an inadvertent or malicious change to an in-use object can silently break running applications, sometimes in ways that are hard to trace.

Kubernetes 1.18 added an immutable field to both the Secret and ConfigMap specifications. Setting it to true prevents any further modifications to the object’s data after creation:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm
immutable: trueCode language: JavaScript (javascript)

Once immutable: true is set, the Kubernetes API will reject any attempt to update that object’s data or stringData fields. To change the value you must delete the object and recreate it — a deliberate action that is far easier to detect and audit than a silent in-place edit.

The same field works identically for ConfigMaps:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  ENV: production
immutable: trueCode language: JavaScript (javascript)

Immutable Secrets and ConfigMaps are particularly useful for values that are set once at deploy time and should never drift — database DSNs, third-party API keys, and environment-specific feature flags are common examples. There is also a performance benefit at scale: the kubelet does not need to watch immutable objects for changes, reducing API server load in large clusters.

Summary

Kubernetes 1.18 delivered incremental but meaningful improvements across several operational dimensions:

• kubectl run restriction — enforces a cleaner, more intentional imperative workflow; review your automation before upgrading.
• kubectl debug — ephemeral containers make live pod troubleshooting practical without altering production images.
• Server-side apply — moves field management and ownership tracking to the API server, enabling genuine audit trails.
• RuntimeClass scheduling for Windows — centralises Windows node-targeting policy, reducing per-pod boilerplate.
• Immutable Secrets and ConfigMaps — protects critical configuration from accidental or malicious in-place mutation.

Taken together, these features reflect the Kubernetes project’s continued focus on making cluster operations safer and more observable as adoption moves further into regulated and large-scale production environments.

Original reporting credit: TheServerSide.com