Managing Kubernetes objects in OpenShift can be quite a daunting task, particularly in larger environments with multiple projects. It can be challenging to follow best practices that improve the development process while simultaneously enforcing company requirements to ensure compliance. However, there’s a solution that can help: Kubemod, an open-source tool that simplifies the management of Kubernetes objects in OpenShift.  

Kubemod automates updates and enforces policies, ensuring consistency and compliance across projects. By using this tool, you can streamline your DevOps processes and improve reliability, even in the most complex environments. In this blog post, we’ll delve into the benefits of using Kubemod in OpenShift and show you how it can make your life easier as a DevOps professional. 

Avoiding a single point of failure 

During a routine check-up of our OpenShift nodes, we discovered that multiple router nodes were running on the same ESXi physical server. This meant that in the event of a server failure, multiple nodes could crash, potentially affecting the entire OpenShift cluster. As you can imagine, this was a major red flag, and we quickly realised the importance of implementing anti-affinity rules to prevent nodes from running on the same server. 

By implementing this strategy, we were able to significantly increase the reliability and security of our environment. However, we soon discovered that multiple replicas of an application may not necessarily increase availability if they happen to run on the same underlying ESXi physical server, creating a single point of failure in case of server failure. 

Kubemod 

This is where Kubemod came to the rescue. Kubemod is an open-source tool that provides a way of modifying Kubernetes objects before they are deployed into your cluster by creating a resource called modrule.   

With Kubemod, we were able to create a label on all of our worker nodes that contained the ESXi server they were running on. This enabled us to create a modification rule that would be applied to all existing deployments in the cluster, causing high-availability applications to run on OpenShift nodes that are running on different physical servers. 

 To make things more practical, here’s a code snippet that can be used to alter deployments and create a topologySpreadConstraint. The constraint will get a topologyKey, which refers to the label given to each worker node, indicating what physical server it is running on. 

apiVersion: api.kubemod.io/v1beta1 
kind: ModRule 
metadata: 
  name: add-topology-spread-constraints 
  namespace: kubemod-system 

spec: 
  type: Patch 
  targetNamespaceRegex: .* 
  match: 
    - select: "$.kind" 
      matchValue: "Deployment" 
    - select: "$.metadata.namespace" 
      matchRegex: "<namespace regex>" 
    - select: "$.spec.template.spec.topologySpreadConstraints" 
      negate: true 
  patch: 
    - op: add 
      path: /spec/template/spec/topologySpreadConstraints/-1 
      value: |- 
          maxSkew: 1 
          topologyKey: "hardware.layer/esx" 
          whenUnsatisfiable: ScheduleAnyway

The modrule feature also allows you to define which type of Kubernetes resources you want to modify in the match section. For example, the third select statement specifies that if a topologySpreadConstraint is already present, it gets ignored.  

 In the patch section, you can define what you want to modify to the Kubernetes resources that the modrule matches with. Here, we will add the topology spread constraint.  

Wrapping things up 

This is just one example of what you can do with Kubemod, which has become quite useful within our OpenShift environment. If you’re looking for a way to simplify the management of Kubernetes objects in OpenShift, we highly recommend giving Kubemod a try. With its powerful modification capabilities, you can create mandatory standards across all existing projects without causing any development impact to your DevOps teams. 

Need some help with your next DevOps project? Have some more questions about Kubemod or other tools? Don’t hesitate to reach out: we’ll be more than happy to help you streamline your DevOps processes and enhance your business operations

Do you have any remaining questions about this blog? Don’t hesitate to contact us, we’d love to help you out!