The following EntireX components are available as containers:

• EntireX Broker

• RPC Server for Java

• RPC Server for XML/SOAP

These containers can be deployed in a container orchestration environment, for example Kubernetes. This document covers the following topics:

• Container Orchestration Architecture

• Sample Deployment

• Sample Configuration File

---

Container Orchestration Architecture

A typical container orchestration environment has at least one master node and several worker nodes. Containers can be deployed on multiple worker nodes. If one node fails, the remaining nodes keep the application alive. The deployable unit for a worker node is called a pod. A pod consists of at least one container. Containers running in the same pod share the same network namespace (same IP and port space) and the same IPC namespace (visible to each other over PID). From outside the pod, containers are only reachable via sockets.

Sample Deployment

This example assumes you have a Kubernetes cluster installed.

To Deploy EntireX Broker, RPC Server for Java, and RPC Server for XML/SOAP in a Kubernetes cluster

1. Create a pod containing the images of EntireX Broker, RPC Server for Java, and RPC Server for XML/SOAP.

   Note:
   It makes sense to combine EntireX Broker and RPC servers for Java and XML/SOAP in one pod.

2. Configure a deployment for multiple broker and RPC server instances.

3. Assign a port to a service to access the broker and RPC servers from outside the Kubernetes cluster.

4. Use a ConfigMap to deploy the configuration files of your broker and RPC servers.

The following graphic shows the deployment of EntireX Broker, RPC Server for Java and RPC Server for XML/SOAP in a Kubernetes cluster:

Sample Configuration File

Kubernetes uses YAML files to describe the deployment of pods, services and ConfigMaps. Below is a sample configuration file brokerRPCServer.yaml:

The sample file describes a deployment with four pods (replicas). Each pod contains three containers:

• EntireX Broker

• RPC Server for Java

• RPC Server for XML/SOAP

With Kubernetes you can perform a healthcheck and a readiness check. The Kubernetes documentation uses the terms "liveness probe" and "readiness probe". The difference between the two probes is as follows:

• When a liveness probe fails, the related pod is deleted and a new one is started.

• When a readiness probe fails, the related pod is marked as "unready". This means that no messages will be sent to the related pod from the Kubernetes dispatcher.

Both the liveness and the readiness probe offer three kinds of checks:

• TCP check on a specified port

• HTTP check on a specified URL

• user-defined function with return value true (healthy) or false (unhealthy)

In this example, a TCP check on administration port could be used as a readiness probe for the RPC Server for Java. The readiness probe can be defined in the YAML file of the pod deployment.

Example for the RPC Server for Java:

readinessProbe: 
      failureThreshold: 3 
      initialDelaySeconds: 5 
      periodSeconds: 10 
      successThreshold: 1 
      tcpSocket: 
        port: 7001 
      timeoutSeconds: 1.

Probes have a number of fields that you can use to control more precisely the behavior of liveness and readiness checks:

Field	Default	Description
initialDelaySeconds	0	Number of seconds after the container has started before a liveness or readiness probe is initiated.
periodSeconds	10	How often (in seconds) to perform the probe. Minimum value is 1.
timeoutSeconds	1	Number of seconds after which the probe times out. Minimum value is 1.
successThreshold	1	Minimum consecutive successes for the probe to be considered successful after having failed. Must be 1 for liveness. Minimum value is 1.
failureThreshold	3	When a pod starts and the probe fails, Kubernetes will try failureThreshold times before giving up. For a liveness probe, giving up means restarting the container. For a readiness probe, the pod will be marked "Unready". Minimum value is 1.

For the RPC Server for Java a readiness check is defined (readiness probe). The Kubernetes system checks the availability of the TCP port of the server (tcpSocket:port). This port must be defined as Administration Port defined in the properties file of the RPC Server for Java (entire.javarpcserver.properties > entirex.server.monitorport).

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: brokerandrpcserverdeployment
  labels:
    purpose: demonstrate-broker-and.jrpcserver-deployment
spec:
  selector:
    matchLabels:
      app: entirex
  replicas: 4
  template:
    metadata:
      labels:
        app: entirex
    spec:
      containers:
      - name: exxjavarpcserver-node-container
        image: repository.eur.ad.sag:4443/entirex/entirex-java-rpc
        readinessProbe:
         failureThreshold: 3
         initialDelaySeconds: 5
         periodSeconds: 10
         successThreshold: 1
         tcpSocket:
           port: 7001
         timeoutSeconds: 1
        env:
        - name: ACCEPT_EULA
          value: "Y"
        volumeMounts:
        - mountPath: /licenses
          name: config
        - mountPath: /data
          name: data1

      - name: exxxmlrpcserver-node-container
        image: repository.eur.ad.sag:4443/entirex/entirex-xml-rpc
        env:
        - name: ACCEPT_EULA
          value: "Y"
        volumeMounts:
        - mountPath: /licenses
          name: config
        - mountPath: /data2
          name: data2

      - name: exxbroker-container
        image:  repository.eur.ad.sag:4443/entirex/entirex-broker
        env:
        - name: ACCEPT_EULA
          value: "Y"
        volumeMounts:
        - mountPath: /licenses
          name: config
      volumes:
      - name: config
        configMap:
          name: exx-configmap1
      - name: data1
        configMap:
          name: exx-configmap2
      - name: data2
        configMap:
          name: exx-configmap3