Service identities and resolution
Otterize uses universal service identities to refer to services, regardless of which infrastructure they run on. Every service has a name, and possibly a namespace, which is specified in Otterize client intents to request access to other services.
Kubernetes service identity resolution
How do Otterize operators decide what is the name of the service that runs within the pod? The algorithm is as follows:
- If the pod has an
intents.otterize.com/service-name
annotation, its value is used as the service name. (You can change which annotation is used by settingglobal.serviceNameOverrideAnnotationName
— see the docs.) This allows developers and automations to explicitly name services, if needed. The value must not contain a period.
as a period is used to separate service name and namespace, when the service is from a different namespace:svcname.namespace
. - If there is no
intents.otterize.com/service-name
annotation, a recursive look-up is performed for the Kubernetes resource owner of the pod, until the root resource is reached, and its name is used as the service name. For example, if you have aDeployment
namedcheckoutservice
, which then creates and owns aReplicaSet
, which then creates and owns aPod
, then the service name for that pod ischeckoutservice
- same as the name of theDeployment
. This is intended to capture the likely-more-meaningful "human name" of the service. If the resulting service name contains a period.
, it is replaced with an underscore_
. Periods are used in service names to denote namespaces, e.g.svcname.namespace
.