Subscribe to the feed

Businesses continue to have a high demand for automation. This is not limited to infrastructure components, but stretches across the entire IT, including the platforms supporting application deployments. Here often Kubernetes is the way to go - and why in November we released the first Certified Content Collection for deploying and managing Kubernetes applications and services. Since then, the development and work in this area has only increased. That is why we recently released kubernetes.core 1.2.

In this blog post, we’ll go over what’s new and what’s changed in this release of our Kubernetes Collection.

New Modules

We continue to build on our existing support for Helm 3, the Kubernetes package manager: we added the new helm_template module, which opens up access to Helm’s template command.

Scenario: Examine a chart's content for further processing

There are times when you may need to take an existing chart and do something with its content. For example, there might be existing objects that you would like to bring under Helm's control and you need to compare what's deployed with what's in the chart. The newly added helm_template module gives you access to the rendered YAML of a chart. In the following example, we capture the YAML as a single stream containing multiple documents:

- name: Render a cha:rt
    chart_ref: nginx-stable/nginx-ingress
  register: result

- debug:
    var: result

We could instead also tell the module to write the YAML out to a separate directory that’s structure will match the chart’s directory structure. In this case, the YAML will be written to separate documents.

- name: Render a chart
    chart_ref: nginx-stable/nginx-ingress
    output_dir: local/chart/path

Incremental Improvements

We’re always looking for ways to improve on what we’ve already built. In addition to the new module mentioned above, we have several small changes to make automating the manual tasks easier.

Scenario: Controlling dependent deletion

Do you need to delete a job and ensure that all its dependent pods are also deleted? Use the new delete_options parameter to choose how those dependent pods are removed:

- name: Delete a Job and its Pods
    kind: Job
    name: my-job
    namespace: workflows
    state: absent
    wait: yes
      propagationPolicy: Foreground

The delete_options parameter also supports gracePeriodSeconds and preconditions for even more control over how objects get deleted. To better understand how cascading deletion works, check out the Kubernetes documentation on garbage collection.

Scenario: Use Helm Diff for more reliable idempotency checks

Idempotency is a key pillar of Ansible's vision for automation, as it allows us to bring infrastructure to a desired state. Until now, the Helm module has relied on a few important pieces of information to determine when a chart release would change, such as the stated version of the chart or the provided values. This covers the most common cases, but sometimes you have local charts that aren't being versioned and packaged. In these situations, changes made to the chart's YAML won't be picked up by Ansible. This is why we added optional support for the Helm Diff plugin. With Helm Diff, we can more reliably determine when a release would change.

If you would prefer not to use Helm Diff, don't worry. Everything will continue to work without it. We even have a few improvements in this release to make idempotency checks better for those not using Helm Diff.

To use this new feature, simply install Helm Diff and Ansible will automatically employ it. You can even use the helm_plugin to install it:

- name: Install Helm Diff
    state: present

- name: Release local chart
    name: my-chart
    namespace: my-namespace
    chart_ref: /path/to/local/chart

Support for Kubernetes client version 12

Many of you might have run into some problems when upgrading the underlying Kubernetes python client library to version 12. This release includes a fix to handle a breaking change made in that library, so make sure to upgrade accordingly.

What's Next?

We're already hard at work on the next major release for which we plan to include performance improvements and more convenient ways to create multiple resources at once. In addition, we hope to finish the move from the community.kubernetes namespace to kubernetes.core, and complete the transition from the OpenShift python client library to the official Kubernetes python client library.

Many of the improvements in this release are the result of feedback from users like you. We value your input and hope you will continue working with us to build container-native automation in Ansible.

Try out the latest kubernetes.core Collection and let us know what you think.

If you want to dive deeper into Ansible and Kubernetes, check out the following resources:

About the author

Mike Graves is a Senior Software Engineer on the Ansible Cloud team. When he’s not shuffling bits around, he’s probably reading a book or gaming. You can find his work on GitHub at @gravesm.
Read full bio

Browse by channel

automation icon


The latest on IT automation for tech, teams, and environments

AI icon

Artificial intelligence

Updates on the platforms that free customers to run AI workloads anywhere

open hybrid cloud icon

Open hybrid cloud

Explore how we build a more flexible future with hybrid cloud

security icon


The latest on how we reduce risks across environments and technologies

edge icon

Edge computing

Updates on the platforms that simplify operations at the edge

Infrastructure icon


The latest on the world’s leading enterprise Linux platform

application development icon


Inside our solutions to the toughest application challenges

Original series icon

Original shows

Entertaining stories from the makers and leaders in enterprise tech