Banzai Cloud Logo Close
Home Benefits Blog Company Contact
Sign in
Author Janos Matyas

Running Infinispan on Kubernetes

TRY PIPELINE FOR FREE

One of our goals with Pipeline is to support Java and Java Enterprise Edition deployments, allowing developers to iterate fast while building and deploying safe, and also pushing code to production. In order to do that, we place a lot of importance on different aspects of a Java/JEE application’s lifecycle - we allow engineers:

  • To continuously integrate and deploy their Java apps to Kubernetes
  • To deploy Java Enterprise Edition applications to Kubernetes
  • Once the Java containers are deployed to K8s, to avoid OOMKills
  • To correctly size Java containers
  • And, once deployments are done and sized, to monitor them without any code modification

Enter Infinispan - a distributed cache and data grid.

The Infinispan Operator

A month ago the new Kubernetes operators SDK was released, and it’s been easier to put human operational knowledge into the code ever since. We embraced that technology from a very early stage, have even been a Red Hat partner working on the SDK. As a result we have open sourced a few operators for popular frameworks:

We are also working on an Infinispan Operator to run Infinispan clusters on Kubernetes, all built on the new operator SDK. One of the main benefits of this Operator is that, without deep Kubernetes, Helm and Infinispan operational knowledge, you can get a fully HA Infinispan cluster up and running on your Kubernetes cluster.

Nodes are automatically joined together with JGroups configured to use KUBE_PING protocol, which finds each Pod running an Infinispan server based on labels and namespaces. By default, the operator deploys a standalone Full HA configuration to Kubernetes.

JEE Wildfly deployment

Kubernetes discovery protocol for JGroups: In regular host based deployments, Infinispan uses JGroups to find each node. When deployed to Kubernetes the KUBE_PING discovery protocol for JGroups clusters is used instead. This discovery protocol is the result of Kubernetes asking for a list of the IP addresses of all cluster nodes, combined with bind_port/port_range; the protocol then sends a discovery request to all instances and waits for their responses. When a discovery is started, KUBE_PING asks Kubernetes for a list of the IP addresses of all the pods it launched, matching the given namespace and labels.

Once the operator deploys a cluster, the Infinispan REST and Management endpoints are exposed as Kubernetes Services and the Infinispan deployment is continuously monitored by Kubernetes through built-in Infinispan health checks.

This operator is in WIP state and subject to (breaking) changes.

Usage

Prerequisites

Clone the repository

mkdir -p $GOPATH/src/github.com/banzaicloud
cd $GOPATH/src/github.com/banzaicloud
git clone git@github.com:banzaicloud/infinispan-operator.git
cd infinispan-operator

Get the operator Docker image

a. Build the image yourself

operator-sdk build banzaicloud/infinispan-operator
docker tag banzaicloud/infinispan-operator ${your-operator-image-tag}:latest
docker push ${your-operator-image-tag}:latest

b. Use the image from Docker Hub

# No additional steps needed

Install the Kubernetes resources

Finally, you need to deploy the operator, see the running pods and services.

kubectl apply -f deploy

kubectl get pods

kubectl get services

The Infinispan Custom Resource - deploy a cluster

With this YAML template you can easily install a three node Infinispan Cluster into your Kubernetes cluster:

apiVersion: "infinispan.banzaicloud.com/v1alpha1"
kind: "Infinispan"
metadata:
  name: "infinispan-example"
spec:
  size: 3

That’s it: you’ll have an infinispan cluster in minutes. If you are interested in our technology and open source projects, follow us on GitHub, LinkedIn or Twitter:

Star

TRY PIPELINE FOR FREE

Comments

comments powered by Disqus