In R1, DCAE platform and service components typically obtained the addresses of other components by making requests to the Consul service discovery API, which provides both IP address and port information.   The R1 Docker plugin also configured containerized components to make DNS requests through Consul.  This gave easy access to IP addressing information.

Some containerized components continued to use this approach in R2 in the Kubernetes environment.  This required creating Consul service registrations at the time DCAE was installed.   The preferred approach to service discovery in Kubernetes is to use DNS.  Since each component has its own IP address in the Kubernetes private network, each component can use fixed port assignments for any services that it exposes, so clients can hardcode port values.  DNS can provide the IP addresses.   We should evaluate the possibility of moving all components to DNS-based service discovery, eliminating Consul from the service discovery process.