vRealize Automation 8.x Architecture

vRA 8.x Architecture Explained

 vRealize automation 8.x has been designed with modern microservices architecture. In this post, I will explain the basic building blocks of this new and redefined product. I will focus only on the technical aspects of the design.

vRealize Automation 8.x is now a single appliance that is packed with a lot of powerful features. VMware has moved away from the complexities of having Windows based IaaS servers and other distributed components (thankfully!).

vRA 8.x can be deployed in

  • Standard Deployment

Easy installer installs vRealize Suite Lifecycle Manager appliance first and using this vRSLCM it deploys VIDM and vRA appliance.

  • Clustered Deployment

Clustered architecture can be configured in many different configurations. In this example the setup is using three vRA appliances in a cluster behind a load balancer. Please check the VMware documentation for the support load balancers.

vRA appliance now includes a native Kubernetes to host containerized services. Let’s explore this new architecture from containers prospective.


Container Runtime

Kubernetes is a container orchestration tool. It needs a container runtime for its execution. vRA8.x deploys docker engine community edition as a container run time for its implementation.


Kubernetes Components:

Kubernetes installs three main components during the vRA installation

  • Kubeadm: Automates processes. 
  • Kubelet: Its an agent on each Kubernetes node that acts as a middleman between Kubernetes API and Docker container run time. Kubelet informs Dockers when to spin up new container sand when to tear down containers.
  • Kubectl: This is a command line tool to interact with the cluster.


Cluster Nodes

Since my lab uses standard deployment it contains a single node. Nodes can be listed usin

In a clustered deployment it will display multiple nodes with roles as master and worker.


Container Namespace

All the core vRA 8.x services now run as pods inside a name space called “Prelude”

All the name spaces can be listed with native “kubectl” command as shows below.


vRA Container Pods

The vRA appliance services are deployed and managed as pods by Kubernetes.

A Pod is the basic execution unit of a Kubernetes application–the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your cluster.

To list pods in all the name spaces:

  • kubectl get pods –all-namespaces

Since all the vRA services are running in prelude namespace, we can filer the list by namespace

  • kubectl get pods -n prelude

You can specify “-o wide” for additional columns for more details.


vRA Containerised Services

Each Kubernetes service in a vRealize Automation appliance is represented by a pod. A service creates an abstraction layer on top of a set of replica pods. You can access the service rather than accessing the pods directly.

All the vRA services running as containers can be listed with:

  • kubectl get services -n prelude <-o wide>
  • kubectl describe services <service name> -n prelude

Each service has a cluster IP.


Kubernetes Deployments

A Deployment provides declarative updates for Pods and ReplicaSets. It defines a desired state of pods, this will ensure the number of replicas specified in a deployment will always be available. If a pod is deleted, deployment spins a new pod.

To get more details about a particular deployment use:

  • kubectl get deployment -n prelude -o yaml


vRA Database

PostgreSQL is the default and only supported database for vRealize Automation.

Postgres also runs as a pod in vRA 8.x. You can view postgress details with the standard pods command:

  • kubectl get pod postgres-0 -n prelude -o wide

To get more details you can view the yaml output of the postgres pod as well. It will list every possible detail you would need about the pod.

  • -o yaml can be used to get any pods YAML details

You can also use the describe command to get all the pod details. 

  • kubectl describe pod postgres-0 -n prelude

This information can be helpful while troublesooting containers.  


vRA 8.x Pod networking:

Kubernetes treats pods as virtual machines, each pod get a unique IP Address and all containers within that pod share that address and communicate with each other over loopback interface. vRA 8.x uses flannel plugin for the cluster networking. 

To get the pods internal cluster IP address use the below command and note the IP address.

  • kubectl get pod -n prelude -o wide

Similarly, to get the service IP address use the below:

  • kubectl get service -n prelude -o wide

Virtual Cluster Network can span across multiple nodes. Pods can communicate with other pods using cluster IP even if they are on seperate nodes. 

Lets check the pod to pod communcation between vRA abx pod and blueprint pod. 

I will use the below command to ping one pod from another:

  • kubectl exec abx-service-app-668dc554c5-b2znk -n prelude — ping

You can run a variety of commands like curl etc. to check the connectivity.  

Let’s explore one the pods by entering its namespace

In my lab I am using abx as an example

To enter the pod namespace, you need to get the container id of the POD. All the containers can be listed using the below command

  • Docker ps

The data can be filtered using –filter option as shown belowTo get the process ID of the container use the following command

  • docker inspect –format ‘{{ .State.Pid }}’ container-id-or-name

You can now use nsenter program to run the commands in abx process network namespace

  • nsenter -t -n

 Eth0 is the pods network interface, @if36 means that pods eth0 is mapped to nodes 36th interface.

You can also enter the pod shell by issuing:

Network architecture is fairly broad topic. I will not touch all the aspects of network communication between pods and services in this post.


Since the new vRA 8.x is a complete shift from the traditional vRA 7.x architecture it will be extremely important for all the vRA admins and architects to invest time in understanding containers & YAML to effectively implement and troubleshoot this version of vRA.

Author : Barjinder Singh

This Post Has 12 Comments

  1. Jaspreet

    Great blog. Easy to understand.

  2. ARUN

    Awesome , very informative

  3. Jagdeep


  4. Abid

    Very informative explained with screen print.

  5. Kaustubh

    Excellent ! Keep posting Barjinder.

  6. Rohan Sharma

    Powerful read with a well weaved explanation!

  7. Manbir

    Very well explained.

  8. Damandeep

    Very Informative Blog. Excellent content !
    Thanks for sharing

  9. Balbir singh

    I barely comment on blogs, but looking at this informative stuff i could not stop myself till end.I know this guy in person,very technical,profound and prolific attitude towards technology and it’s used cases.Very helpful person thou!..writing a blog is not at all an easy task as its a day in day out exercise.Well,Barjinder’s initiative on writing blogs made us proud and kinda impetus move for technolgy seeking people👍👍👍

  10. Ankur Pruthi

    Good Work bro…keep it up …Cheers

  11. Like!! I blog frequently and I really thank you for your content. The article has truly peaked my interest.

  12. NJ

    Anyblogs for the networking and storage side of this?

Leave a Reply