Introducing Watch-Proxy: A Beacon to Gather Kubernetes Info for IT Systems

February 11, 2020 Rich Lander

Contributions from Rachel Leekin, Senior Kubernetes Architect, VMware

Today, most enterprises’ IT solutions contain various IT systems. These varying solutions can be legacy systems or non-Kubernetes environments, and enterprises are looking for ways to help users view information in the Kubernetes clusters that are relevant to the other systems. When the systems outside Kubernetes need information about what happens to resources inside Kubernetes, Watch-Proxy, an open source project from VMware, can come in handy. Check out Watch-Proxy on GitHub.

To use Watch-Proxy, simply deploy it into your Kubernetes cluster and give it a ConfigMap that defines the Kubernetes resource types you want it to watch and where you would like it to send the event notifications.

Watching Kubernetes Resources to Automate IT Processes

Faced with large and complex IT systems, IT teams will want to reduce operational effort. They can help reduce this effort by increasing automation between the systems. By introducing Watch-Proxy and using it to help automate processes, an IT team can ease the operational struggle for the portion between Kubernetes and the other systems. For example, perhaps you have DNS servers that need to know when a service with type: LoadBalancer is created in your cluster. You could automate the process of creating CNAME records that map your company's DNS name to the cloud provider's load balancer for your application.

In this case, you would configure Watch-Proxy to watch Service resources in your cluster and give it an API endpoint to send updates to. Each time a Service is created, updated, or deleted, Watch-Proxy sends a POST request to the API endpoint. By default, the request payload contains the Service resource's entire manifest, spec, and status.

This example assumes you have a DNS management system that exposes an API for Watch-Proxy tosend payloads to. The DNS management system must be able to parse the JSON payload, extract information from the Service manifest, and make use of that info. And if you don't already have such a system, you may be better off building a custom Kubernetes controller to fill this gap. However, in a day and age where APIs are a dime a dozen, you may find Watch-Proxy the path of least resistance.

Managing Watch-Proxy with Options

You can configure the behavior of Watch-Proxy in the following ways. Most of these configuration options are aimed at taming the potentially frequent and verbose payloads that Watch-Proxy sends.

  • Cap the maximum number of objects (Kubernetes resources) to emit in a single call. This setting is one way to limit the size of a payload.
  • Set how often the Watch-Proxy should send these updates.
  • Add arbitrary metadata to each payload to provide, for example, information about the environment that Watch-Proxy is watching.
  • Specify fields to prune from the resource manifests. This setting allows you to trim the JSON payload down to just the information you're interested in; it’s another way to reduce the size of payloads.
  • Send delta updates that deliver only the items that have changed instead of the entire resource manifest.
  • Identify namespaces that Watch-Proxy should ignore. By default, Watch-Proxy reports on resources in all namespaces.
  • Identify the namespaces or resource types that you want to report on for each remote API. You can provide any number of remote APIs to Watch-Proxy and identify the namespaces or resource types relevant to each API.
  • Filter out irrelevant events. For example, if you have a node inventory system that needs to know when nodes are created or deleted but doesn't need information about node updates, which can be quite frequent, you can filter out update events.

Wrapping Up

To summarize, Watch-Proxy is useful when you have existing systems that need information about what happens inside Kubernetes clusters, especially if those systems have an API endpoint for Watch-Proxy to send updates to and can be readily configured to parse the JSON payloads containing Kubernetes resource manifests.

Getting Involved

We look forward to improving and expanding the project. If you would like to join the community or help shape the project’s direction, check out the following:

  • Try out the latest release on GitHub.
  • Collaborate with us on GitHub by opening an issue or creating a pull request.

About the Author

Rich Lander was an early adopter of Docker and Kubernetes and has spent the past few years helping enterprises adopt cloud native technology.

More Content by Rich Lander
Previous
Cluster API is a Big Deal. Joe Beda & Craig McLuckie Tell You Why.
Cluster API is a Big Deal. Joe Beda & Craig McLuckie Tell You Why.

The Cluster API is an open-source, cross-vendor effort to simplify cluster lifecycle management. Cluster ...

Next
Enhancing Kubernetes Security with OPA
Enhancing Kubernetes Security with OPA

The security ecosystem for Kubernetes can be confusing. A Sysdig article from July 2019 outlined 33 securit...