Clusters

Each service generates up to four discovered clusters, of which only the service cluster is visible to the user. SNIP, HIP, and BE clusters appear as related clusters for the service cluster. HIP and BE clusters are generated only when HIPs and BEs are present in the lb scope.

For the example above, automatic policy discovery generates a SNIP cluster and HIP cluster in the lb scope that include SNIPs and HIPs for service. Since BEs lie outside the lb scope, automatic policy discovery does not generate a backend cluster but instead adds the be scope to the list of related clusters for db.

Clusters are generated as follows:

• Service

  The service cluster includes VIPs for service. The query for the service cluster as follows:

  user_orchestrator_system/cluster_id eq 1234 and
  user_orchestrator_system/namespace eq common and
  user_orchestrator_system/service_name eq db
  

• SNIP

  SNIPs for a service are included in the SNIP cluster. The query for the SNIP cluster is as follows:

  user_orchestrator_system/cluster_id eq 1234 and
  user_orchestrator_system/service_startpoint eq db
  

• HIP

  HIPs for a service are included in the HIP cluster. The query for the HIP cluster is as follows:

  user_orchestrator_system/cluster_id eq 1234 and
  user_orchestrator_system/service_healthcheck_startpoint eq db
  

• Backend

  A backend cluster for the service is generated when one or more BEs are part of the lb scope. This doesn’t apply to the example above, resulting in a backend cluster not being generated in the lb scope.