With increased adoption of container automation, IT organizations continue to expand their requirements when it comes to deploying and managing their Kubernetes clusters. As such, we at Red Hat continue to add new features and capabilities to meet those demands by announcing the availability of kubernetes.core version 2.3, our Red Hat Ansible Certified Content Collection for Kubernetes and Helm.

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

New Module - k8s_taint

With the release of kubernetes.core 2.3, we introduce the k8s_taint module. This module provides the ability for a Kuberentes node to repel a pod or set of pods from being scheduled unless they have a matching toleration. This establishes that with taints and tolerations in place, pods are not scheduled onto inappropriate nodes.

This feature is quite useful when you are trying to ensure exclusivity of a particular set of nodes (only allow a particular group of users access) or you want to provide particular nodes with special hardware (such as GPUs) to only run pods that require the use of the specialized hardware and keep out the pods that don’t require it. 

An example of using the k8s_taint module where the toleration key has a value of key1 and its effect is to not execute NoExecute. This means that no pod will be able to execute onto node foo unless it has a matching toleration.

- name: Taint node "foo"
  kubernetes.core.k8s_taint:
    state: present
    name: foo
    taints:
    - effect: NoExecute
      key: "key1"

Additionally, more than one effect can be provided to apply additional effects:

- name: Taint node "foo"
  kubernetes.core.k8s_taint:
    state: present
    name: foo
    taints:
    - effect: NoExecute
      key: "key1"
      value: "value1"
    - effect: NoSchedule
      key: "key1"
      value: "value1"

This means that no pod will be able to execute nor schedule onto node foo unless it has a matching toleration.

NOTE: The available effects of the taint on pods are: NoSchedule, NoExecute and PreferNoSchedule.

Lastly, a taint can be removed by changing the state from present to absent:

- name: Remove taint from "foo".
  kubernetes.core.k8s_taint:
    state: absent
    name: foo
    taints:
    - effect: NoExecute
      key: "key1"
      value: "value1"
      value: "value1"

Enablement of Server-Side Apply

Server Side Apply assists users and controllers in managing their resources via declarative configurations. One of the goals of Server Side Apply is to provide more robust handling of conflicts that might arise when a resource is modified by multiple agents concurrently. Client Side Apply works by first fetching the existing resource, then determining the difference between the existing state of resource and the desired state of the resource. If they differ, a patch is applied to the resource for the difference. When resources are modified concurrently, this can lead to race conditions where the same fields are being changed. Server Side Apply assigns ownership of individual fields, preventing unintended changes from being applied in situations where there is contention.

To take advantage of Server Side Apply within kubernetes.core.k8s, a user can use the server_side_apply field that declare a field_manager as follows:

- name: Create configmap using server side apply
  kubernetes.core.k8s:
    namespace: testing
    definition:
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: my-configmap
    apply: yes
    server_side_apply:
      field_manager: ansible

NOTE: This option requires Kubernetes Python Client 19.15.0 or higher. 

Incremental Improvements

In this release, we have replaced the client side implementation of dry run with server side dry run. With this switch, we can make sure that admission controllers are run and schema validation occurs, providing a more accurate representation of the changes. This feature requires a Kubernetes Python Client version >= 18.20.0, and is used automatically when running the kubernetes.core.k8s module in check mode.

We have also added the ability to impersonate users and groups through the new impersonate_user and impersonate_groups parameters in the kubernetes.core.k8s module. To use this feature, the authenticating user must have the ability to perform the impersonate verb. This can be configured using Kubernetes RBAC.

There have been a number of small improvements to our Helm modules. The kubernetes.core.helm_info module now has a release_state parameter that gives you expanded control over filtering releases. The default behavior of returning only releases in the failed or deployed state remains the same. Additional release states are now supported, as well. 

A new plugin_version parameter has been added to the kubernetes.core.helm_plugin module. In addition to being able to install a specific version of Helm plugin, a new latest state was added. This state verifies that the requested plugin is always at the latest version. This differs from the default present state in that with state: present, the latest version will only be installed if the plugin is not currently installed. 

Finally, the wait parameter on the kubernetes.core.helm module will now work when deleting releases. Previously, this only worked when installing or upgrading a release due to limitations in helm itself. This functionality requires a helm version >= 3.7.0.

Summary

With the newest release of Ansible Content Collection for kubernetes.core, users now have:

  • the flexibility to set taints and tolerations to repel a pod or set of pods from being scheduled unless they have a matching toleration.
  • the ability to implement Server Side Apply to manage their resources via declarative configurations.
  • the ability to impersonate users and groups through the new impersonate_user and impersonate_groups parameters in the kubernetes.core.k8s module.
  • additional improvements to various Helm modules.

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


关于作者

UI_Icon-Red_Hat-Close-A-Black-RGB

按频道浏览

automation icon

自动化

有关技术、团队和环境 IT 自动化的最新信息

AI icon

人工智能

平台更新使客户可以在任何地方运行人工智能工作负载

open hybrid cloud icon

开放混合云

了解我们如何利用混合云构建更灵活的未来

security icon

安全防护

有关我们如何跨环境和技术减少风险的最新信息

edge icon

边缘计算

简化边缘运维的平台更新

Infrastructure icon

基础架构

全球领先企业 Linux 平台的最新动态

application development icon

应用领域

我们针对最严峻的应用挑战的解决方案

Virtualization icon

虚拟化

适用于您的本地或跨云工作负载的企业虚拟化的未来