Overview:
A vRA standard deployment is 3 OVA appliances, with one of each installed below (w/ VMware recommended sizing):
- VMware (Broadcom) vRealize Lifecycle Manager (2 vCPUs, 6 GB RAM, 78 GB Storage)
- VMware (Broadcom) Identity Manager (8 vCPUs, 16 GB RAM, 100 GB Storage)
- vRealize (Broadcom) Automation 8.x (12 to 24 vCPUs, 42 to 96 GB RAM, 246 Storage (which is NOT enough )
A clustered deployment is typically 5 appliances (but only the same 3 OVAs).
- VMware (Broadcom) vRealize Lifecycle Manager
- VMware (Broadcom) Identity Manager
- vRealize (Broadcom) Automation 8.x
Notes:
- The number of vRA appliances can be 3, or 5, or whatever. In addition to these 5 appliances above, there are typically separate load balancers (LBs) set-up, as well.
- The sizing comes from the version 8.10 vRealize Automation Reference Architecture
Kubernetes / Docker Containers:
The 3 OVAs are deployed as using Docker Engine Community Edition (regardless if "standard" or "clustered" deployment. Docker Community Edition is basically a Kubernetes variant.
If we SSH into a vRA Automation appliance, we can run docker and Kubernetes commands (e.g. kubeadm).
- The simplest docker command is docker version:
$ ssh root@myvraappliance.mindwatering.net
<enter root password>
root@vra8 [ ~ ]# docker version
<read output>
The output will include the Client: Docker Engine Community and the Server: Docker Engine Community versions, their go code versions, and their OS/Architecture.
- To view all the containers Docker is running:
root@vra8 [ ~ ]# docker ps
<read the long output>
- - To view just the catalog service containers/pod, with the container ID and Name columns:
root@vra8 [ ~ ]# docker ps --filter "name=catalog-service" --format "table {{.ID}}\t{{.Names}}"
<read output>
- - - To view the process of the ID being run by Docker, use the ID returned above with the inspect command:
root@vra8 [ ~ ]# docker inspect --format '{{ .State.Pid }}' <id-pasted-above>
<read output>
- - - - Using the process ID above, use nsenter -t -n <command> to issue commands w/in the container:
root@vra8 [ ~ ]# nsenter -t 12345 -n ping 10.11.22.55
<read output>
- - - - If that fails, to open a shell terminal session w/in the container for further network troubleshooting, issue:
root@vra8 [ ~ ]# nsenter -t 12345 -n /bin/sh
sh-4.4#
You are now in a terminal session w/in the container, until you exit it.
Kubernetes Overview:
The primary Kubernetes programs are:
- kubeadm - automation processes and its API
- kubelet - the API againt, which is like a service or task that bridges Kubernetes and the Docker container. kubelet can also talk to other containers. Popular containers are: CRI-O, Docker, containerd and Mirantis Container Runtime
- kubectl - the command line tool that admins or other APIs send commands to instruct Kubernetes to perform tasks.
Sample tasks:
- List your vRA Automation nodes:
root@vra8 [ ~ ]# kubectl get nodes
<read output>
NAME STATUS ROLES AGE VERSION
vraappliance.mindwatering.net Ready master 200d v1.xx.x
- List your vRA environments Kubernetes namespaces:
root@vra8 [ ~ ]# kubectl get namespace
NAME STATUS AGE
default Active 200d
ingress Active 200d
kube-node-lease Active 200d
kube-public Active 200d
kube-system Active 200d
openfaas Active 200d
openfaas-fn Active 200d
openfaas-ip Active 200d
prelude Active 200d
Important:
prelude is the namespace that contains the core vRA services.
Therefore, most Kubernetes kubectl commands are instructed into this namespace.
- Get all the pods in the prelude namespace:
(A pod is a collection of related containers for a specific task/service which may be 1 or many. A pod has a unique IP, ports, and the replicas w/in the pod communicate in a loopback interface, on the host called a node. vRA 8.x uses the flannel networking plugin for cluster networking. Cluster doesn't mean a vRA cluster of 3 vRA Automation appliances -- it means a cluster of 1 or more replicas that make up a pod.)
root@vra8 [ ~ ]# kubectl get pods -n prelude
<read output>
The output will include the name of the pod, how many containers are running out of how many are set to run (e.g. 1/1 mean 1 is running, and only 1 is supposed to be running), the current status of the pod (e.g. Running), the number of restarts, and the days that pod have been up (e.g. 200d).
Example:
catalog-service-app-7a1bc2df12-k1abc 1/1 Running 1 200d
- Get all the services for those pods and see their IPs and ports:
root@vra8 [ ~ ]# kubectl get services -n prelude
<read output>
Example:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
...
catalog-service ClusterIP 10.11.22.33 <none> 8000/TCP,47500/TCP
...
- Get the Deployments for prelude:
(A deployment is a wrapper around pods and replica-sets. The deployment determines the number of containers/pods desired and maintained. e.g. 1/1. If the desired number is 2/3, then one of the replicas is missing, and it's the deployment level, that dictates that 1 more replica needs to be spun up, and ensures that the desired state of 3/3 is maintained.)
root@vra8 [ ~ ]# kubectl get deployment -n prelude
<read output>
Example:
NAME READY UP-TO-DATE AVAILABLE AGE
...
catalog-service-app 1/1 1 1 200d
...
- - To view the configuration (the settings) of this deployment, issue:
root@vra8 [ ~ ]# kubectl get deployment -n prelude -o yaml
<read output>
- Confirm the PostgreSQL pod for this vRA appliance is running okay:
root@vra8 [ ~ ]# kubectl get pod postgres-0 -n prelude -o wide
<read output>
- - Likewise, to view the configuration (settings) of this pod, issue:
root@vra8 [ ~ ]# kubectl get pod postgres-0-n prelude -o yaml
<read output>
- - To view lots of detail on the pod for troubleshooting:
root@vra8 [ ~ ]# kubectl describe pod postgres-0 -n prelude
<read output>
- Confirm the postgres-0 pod can ping another vRA prelude namespace pod, using the exec (execute) command:
root@vra8 [ ~ ]# kubectl exec catalog-service-app-7a1bc2df12-k1abc -- ping 10.11.23.99
<read output>
- View the logs of a of the service-catalog pod:
root@vra8 [ ~ ]# kubectl logs catalog-service-app-7a1bc2df12-k1abc -n prelude
<read output>
previous page
|