Kubernetes
• 3 min

Kubernetes: What to expect from the new 1.18 k8s version?

Camil Sadiki
Camil Sadiki

Posted on 18 March 2020, updated on 18 December 2023.

Version 1.18 of the container orchestration system Kubernetes is set to be released on the 24th of March 2020. This is as good an opportunity as any to take a look into the new features that will be introduced by this new version.

To mention just some of the key features: Ingress will be more flexible on the way they match hosts and on the type of resource to which they redirect traffic, kubectl gets a debug subcommand and kubectl run will see its scope reduced to only creating pods.

A dive into Kubernetes 1.18

The draft listing all new features, enhancements, bug fixes that will be included in the next Kubernetes version can be found on GitHub .

As the name of the documents clearly indicates, this is still a project and changes can be made until this new version is released.

From that list of changes, I chose a few that I think, every user of Kubernetes should know about.

If you are not familiar with kubernetes or with some of the resources mentioned in this article, check this article.

Kubectl

  • Remove all the generators from Kubectl run. It will now only create pods. Additionally, deprecates all the flags that are not relevant anymore.

Up to the current version of Kubernetes, the command line command Kubectl run could be used to create different types of workloads in your cluster, depending on some given options.

A bit unclear, isn’t it? A single command used to create four different resources depending on different options. To add to the confusion, neither schedule nor restart clearly takes as an argument the name of the resources to be created.

From now on, Kubectl will be way clearer (and will also do way fewer things): it will only create single pods without any replication control.

  • Kubectl now contains a Kubectl alpha debug command. This command allows attaching an ephemeral container to a running pod for the purposes of debugging.

This feature will be introduced in Kubernetes 1.18 as an alpha feature, thus the leading alpha before the command name.

Kubectl will finally have a long-awaited debugging tool. Until now debugging was, of course, possible, for example with the techniques detailed here but kubectl still lacked that debug command.

The command will create a container inside a specified pod. This is especially practical if, like the majority of containers running in a production environment, the container you want to debug doesn’t have the tool you need (curl, dig, ps, etc.) since you can run a container of your choosing. From there you can investigate any network, data or system issue without having to install new software into your app container.

 

Note that it is also possible to specify a target container inside your pod. With that option enabled, your debugging container with share the namespace of the app container and therefore be able to look into the running processes of this container.

Ingresses become a lot more flexible

  • Ingress: Add Exact and Prefix matching to Ingress PathTypes

When defining an ingress in Kubernetes 1.18 you will be able to specify a PathType field whose value can be either Exact or Prefix:

  • Exact match: Path must be exactly the same as the request path.

  • Prefix match: Matching is done on a path element by element basis. A path element refers is the list of labels in the path split by the '/' separator. A request is a match for path p if every p is an element-wise prefix of p of the request path. Note that if the last element of the path is a substring of the last element in request path, it is not a match (e.g. /foo/bar matches /foo/bar/baz, but does not match /foo/barbaz).

This will allow more flexibility on ingresses making them more nginx-like.

This is not the only change made to ingresses, as a big refactoring of the extensions API is being developed.
  • Ingress: allow wildcard hosts in IngressRule

 

Wildcard support is now available as you can discover in the IngressRule.Host specification:

If Host is a wildcard, then the request matches this rule if the http host header is to equal to the suffix (removing the first label) of the wildcard rule.

  • The wildcard character '*' must appear by itself as the first DNS label and matches only a single label.
  • You cannot have a wildcard label by itself (e.g. Host == "*").

 

For example:

  • "*.foo.com" matches "bar.foo.com" because they share an the same suffix "foo.com".
  • "*.foo.com" does not match "aaa.bbb.foo.com" as the wildcard only matches a single label.
  • "*.foo.com" does not match "foo.com", as the wildcard must match a single label.

 

  • Ingress: Add alternate backends via TypedLocalObjectReference

This is the biggest change made to the ingress resource as the entire Backend can now be specified. The use case of that change is not directly clear - Why would I need to redirect traffic to something other than a Kubernetes service?

I’m sure it will get clearer once you’ve looked at an example:

You will soon be able to redirect traffic to a bucket rather than a Kubernetes secret! Well, for that example to work you will have to create a bucket.io Custom Resource Definition but there’s no doubt those will be made available by cloud providers once Kubernetes 1.18 is out and this feature starts to be used.

 

This version of Kubernetes will not radically change the way everyone uses Kubernetes, but it will make some changes to resources, such as ingresses that still lacked some key features. Of course, the changes made to Kubernetes itself are only a part of the puzzle as it is the community of users that really decides how a resource is used.It is also the community that pushes for change by creating CRD that then be introduced into Kubernetes itself.

Be sure to read Kubernetes 1.18 release note before upgrading your cluster.