Increasing business demands are driving the need for increased automation to support rapid, yet stable, and reliable deployments of applications and supporting infrastructure. Kubernetes and cloud-native technologies are no different. That is why we recently released kubernetes.core
1.1, our first Certified Content Collection for deploying and managing Kubernetes applications and services.
Prior to the release of kubernetes.core
1.1, its contents were released as community.kubernetes. With this content becoming Red Hat supported and certified, a name change was in order. We are in the process of making that transition, starting with this release.
In this blog post, we will go over what else has changed and what’s new in this Content Collection as it transitions and enhances it from its community roots.
Focus on The Future
In looking to create a stable and supported release from the upstream sources that Red Hat is known for, the first thing we did was look at what was in community.kubernetes
and elsewhere to organize it for the future. This not only led to the aforementioned name change: the content and underlying code was reorganized to be more maintainable and ready to serve as the foundation of other Kubernetes-based collections.
We also quickly recognized that community.kubernetes
was serving two distinct user groups with different needs — those working with baseline Kubernetes and those working with Red Hat OpenShift, our enterprise-class Kubernetes platform. So we made the decision to split out OpenShift-specific content and functionality into its own collection called community.okd. This will take some release cycles to completely perform this transition, but it has begun with this release of kubernetes.core
.
We’ve copied over the openshift inventory
plugin, the oc connection
plugin (from community.general
), and the k8s_auth
module (renamed to openshift_auth
), along with associated utilities. We also extracted OpenShift-specific logic in the underlying k8s
module code for resources like Projects
not found in the base Kubernetes distribution.
While the OpenShift-specific code still remains in kubernetes.core
for now, all development and maintenance has been moved to community.okd
. Once that collection reaches 1.0, we will be deprecating that content in the Kubernetes Collection. Look for a separate blog post on community.okd
in the near future.
A Commitment to Standards and the Broader Community
Another thing we became aware of was concerns from the community about the k8s
modules’ dependency on the openshift python client library. OpenShift is Kubernetes at its heart and having both baseline Kubernetes and OpenShift extensions together as it was, this made a lot of sense. The Openshift library also provided logic to baseline k8s
users that was not found in the official Kubernetes python client library. That said, we want to be sensitive that the requirement of the Openshift library raises questions and concerns with the broader Kubernetes community about compatibility with all Kubernetes distributions.
We’ve made a commitment to transition the kubernetes.core collection to the official Kubernetes library. This will take some time and effort to do effectively and without breaking existing usage of this content. Our engineers have already contributed some pull requests to the official client library from the Openshift library and will continue to do so as part of this transition.
New Modules
While a lot of our work has gone into refactoring and reorganizing the Ansible Content Collection for Kubernetes for the future, that’s not all that’s new in kubernetes.core
1.1.
A lot of what’s new in this release is our support of Helm 3 that we've already covered in its own blog post. That support wasn’t the only addition, though.
The scenarios that follow show how common uses of these new Kubernetes modules we’ve added.
Scenario: Executing a command in a Pod
Perhaps you need to do a quick restart of a daemon or run some other maintenance process for a service running in a Pod on your Kubernetes cluster. The k8s_exec
module enables you to execute an arbitrary command in a Pod to do just that.
- name: Execute a command
kubernetes.core.k8s_exec:
namespace: nodana
pod: zuul-scheduler
command: zuul-scheduler full-reconfigure
Scenario: Fetching the log of a Pod
Need to fetch a log from a specific Pod? Let the k8s_log
help you retrieve the contents of a specific Pod. Here is an example task that will get the log from the first Pod found in the testing namespace matching a selector:
- name: Log a Pod matching a label selector
kubernetes.core.k8s_log:
namespace: testing
label_selectors:
- app=example
register: log
This is analogous to the behavior of a kubectl log
command.
Scenario: Getting information about your cluster
Ansible has had the k8s_info
module for fetching info on any Kubernetes objects in a cluster for some time, but there hasn’t been an easy way to get information about the cluster itself in Ansible. That is why we introduced the k8s_cluster_info
module.
- name: Get Cluster information
kubernetes.core.k8s_cluster_info:
register: api_status
- debug:
var: api_status
verbosity: 1
Scenario: Rollback a Deployment
This is an interesting contribution we received from community contributor Julien Huon (@julienhuon).
Try as we may to get things right the first time, sometimes things go wrong and we need to roll them back. The k8s_rollback
provides a straight-forward Kubernetes native means of performing a rollback on a Deployment
or DaemonSet
in your cluster.
- name: Rollback a failed deployment
kubernetes.core.k8s_rollback:
api_version: apps/v1
kind: Deployment
name: web
namespace: testing
Incremental Improvements
No matter the domain, networking, linux, security, public cloud, we are always looking for ways to make what’s possible easier and more frictionless than writing code or doing things manually from the command line. This is not just limited to new modules and plugins either.
Built-in Template Processing
Looking at a lot of early Ansible automation being written for Kubernetes, we noticed many content developers chose to store their K8S object definition files externally and read them into their plays with something like this:
- name: create foo configmap
kubernetes.core.k8s:
definition: "{{ lookup('template', 'foo.yml') | from_yaml }}"
This worked great, but the plays we reviewed would have several, sometimes dozens, of these lookup incantations for every definition param on the k8s
module. We thought we could do better with built-in template processing that could provide the same functionality more concisely.
- name: create foo configmap
kubernetes.core.k8s:
template: foo.yml
Isn’t that much easier to read and write now?
Native Ansible Vaulted File Support
Another area incremental improvement we made was built-in support of Ansible vaulted files. If you are working in a group (maybe you’re using Ansible in a GitOps workflow) and want to store a kubeconfig
or Secrets
definition files in your Git repository, you‘ll want to encrypt them so they aren’t in plain text and easily read. Now, all of the k8s
modules support native handling of Ansible vaulted files. Try it with the kubeconfig
or template
params.
What’s Next?
Ansible lets you connect the different technologies that are ultimately needed to be successful in your efforts with Kubernetes. With the Kubernetes and Helm content in kubernetes.core
, Ansible users can better manage applications on Kubernetes clusters and on existing IT and with faster iterations and easier maintenance. And we’re always looking to improve with ways to help users like you get things done in more simplified, faster ways.
Try out the latest kubernetes.core
collection and let us know what you think.
If you want to dive deeper into the topic of Ansible and Kubernetes, you can also check out these resources:
- The Ansible Kubernetes Content Collection project repo
- How useful is Ansible in a Cloud-Native Kubernetes Environment? blog post
- A general introduction to Ansible Content Collections blog post
- Ansible e-books with topic specific insights.
关于作者
产品
工具
试用购买与出售
沟通
关于红帽
我们是世界领先的企业开源解决方案供应商,提供包括 Linux、云、容器和 Kubernetes。我们致力于提供经过安全强化的解决方案,从核心数据中心到网络边缘,让企业能够更轻松地跨平台和环境运营。