With the advent of Kubernetes in the productive environment, automation is expanding from the level of hosts, clusters and virtual machines, including K8S objects: namespace , ingress , service , pod … Do you need to create another automation system specifically for Kubernetes or can you use vRealize Orchestrator, which is already integrated with your information systems?
With the advent of Kubernetes in the productive environment, automation is expanding from the level of hosts, clusters and virtual machines, including K8S objects: namespace , ingress , service , pod … Do you need to create another automation system specifically for Kubernetes or can you use vRealize Orchestrator, which is already integrated with your information systems?
Let’s consider how K8S and vRO work together using one common task as an example: automating the creation of DNS records for namespace , ingress , service objects .
A head-on solution is to poll clusters on a schedule: connect to the cluster, collect the necessary data about objects, start the processes of changing DNS records. In a small infrastructure with infrequent changes, this option is perfectly acceptable. But this approach has its drawbacks: on the one hand, too frequent polling of the clusters creates a constant load on the orchestrator, on the other hand, with less frequent polls, the time between the change in the cluster and the update of the DNS record increases.
It is more correct to track changes from within the cluster and, when certain events occur, to call vRO processes.
VMware Watch-Proxy
The Watch-Proxy container is a sentry that, being in a cluster, will closely monitor the resources you are interested in. In case of any change (creation, modification or deletion) Watch-Proxy will send a POST request to the specified server. The request body includes the complete manifest, BOM, and resource status. Configuring Watch-Proxy operation is done through ConfigMap, which defines what types of resources to monitor, what data and where to send. The settings in ConfigMap allow:
- reduce the amount of transmitted data by eliminating unnecessary fields;
- add arbitrary metadata to each request;
- set a list of namespaces for monitoring;
- limit the number of objects transmitted by one request;
- set the frequency of data transmission;
- simultaneously send data to several different servers and configure different data sets for them;
- filter events.
Project description: https://tanzu.vmware.com/content/blog/introducing-watch-proxy-a-beacon-to-gather-kubernetes-info-for-it-systems Code and documentation: https://github.com/vmware-tanzu/watch-proxy
Watch-Proxy and vRealize Orchestrator
Watch-Proxy is easy to assemble, easy to configure, and now everything works as it should. But it was not always so. More recently, vRealize Orchestrator returned a 400 – Bad Request code to a request from Watch-Proxy . The reason was that vRO processes have a strictly defined input data format. For example, a data structure for a process with one input parameter input of type string looks like this:
{
"parameters": [
{
"value": {
"string": {
"value": ""
}
},
"type": "string",
"name": "input"
}
]
}In order for Watch-Proxy to become friends with vRO, it was necessary to work with its code and bring the transmitted data into the desired format. All code changes were made in the emitter / emitter.go file:
- added a new type vroInput , which defines the structure of the input data of the vRO process;
- describes the EmitChangesVRO function (based on the EmitChanges function ), which prepares data and sends it to the orchestrator.
The changes I made to work with vRO are already included in the main code of the Watch-Proxy project: https://github.com/vmware-tanzu/watch-proxy . The sample configuration file examples / watch-proxy-config.yaml contains a sample Watch-Proxy configuration for the vRO: specify the server address, process ID and configure the vRO user credentials.
When building the container, add your certificates to it if needed. Alternatively, it is possible (but not recommended) to completely disable certificate checking. To do this, emitter / emitter.go need to add an import module « the crypto / tls » and before calling http.NewRequest in function EmitChangesVRO add the following line:
http.DefaultTransport.(*http.Transport).TLSClientConfig = &tls.Config{InsecureSkipVerify: true}Configuring vRO
Configuring vRealize Orchestrator user to launch processes via API for version 8.1 (modified Watch-Proxy will work with both vRO 7 and 8):
- add a user to vIDM;
- in vRA in Identity & Access Management, make the user a member of the organization ( Organization Member , no additional roles required);
- in vRO in Administration -> Groups create a new group;
- add your user to the group with the right to run processes ( Run ) and select the processes that he can call.
The orchestrator process will receive an input parameter with a JSON string from Watch-Proxy . What to do with it next depends on your tasks:
System.log(input);
struct = JSON.parse(input);
for each (obj in struct.data) {
var clusterName = struct.meta.cluster;
var objName = obj.data.metadata.name;
var event = obj.event;
if (obj.asset_type_id == "ns") {
System.log("Изменение в namespaces кластера " + clusterName);
System.log("Namesepace " + objName + " is (" + event + ")");
}
if (obj.asset_type_id == "svc") {
var svcIp = obj.data.spec.clusterIP;
System.log("Изменение в services кластера " + clusterName);
System.log("Service " + objName + " with IP " + svcIp + " (" + event + ")");
}
}
Translated by Google Translate