Kubernetes 1.18 broke “kubectl run”, here’s what to do about it

Alex Ellis
8 min readMay 12, 2020

If you’ve been using a recent release of Kubernetes like 1.16, then you may have been used to seeing an odd warning message from kubectl run. Up until recently, the command could be used to generate Deployment objects or YAML from the command line.

With Kubernetes 1.18 the user experience for generating and creating Deployments has been broken in a surprising way. Here’s why, and what you can do about it.

Before we get into the change itself, there are three primary ways to create a Deployment object in Kubernetes:

How to create a Deployment in Kubernetes

  • Using the REST API and a client such as client-go (this is what OpenFaaS does)
  • By hand-crafting a YAML file, or more realistically, by copying and pasting from StackOverflow or a known example
  • By kubectl run or kubectl run -o yaml --dry-run

It turns out that I also listed these options in order of complexity (high to low).

Comparing each option

For Option 1 — using the REST API is probably one of the most stable ways to create Deployments, but is the most complex option you can find. Up until recently the API had been relatively stable and happy in “extensions/v1beta” until it moved to “apps/v1”, this was a breaking change and meant lots of OSS projects having to migrate their code and YAML files.

I am not sure what’s harder — crafting Kubernetes objects in Go, or in YAML. With Go you get some hints in the IDE, but have to search all over for which package each type exists in. Core? Meta? Apps? Extensions? Maybe that’s what we’re missing with editing manifest files in VSCode — some good old intellisense?

A snippet of code from the OpenFaaS controller for Kubernetes (faas-netes)

Option 2 is hand-crafting YAML. If you’ve ever used Twitter or watched the #kubernetes hashtag, you’ll see all kinds of folks from newcomers to respected Kubernetes authors and founders bashing on how hard it is…