Skip to main content

Service identities and resolution

Otterize supports two approaches for specifying service identities in Kubernetes: explicit and implicit.

Explicitly specifying Kind​

This approach requires specifying both the name, possibly with a namespace, and the kind of the service in the intent, ensuring precise identification.

   apiVersion: k8s.otterize.com/v1alpha3
   kind: ClientIntents
   metadata:
     name: client
     namespace: otterize-tutorial-istio-mapping
   spec:
     service:
       name: client
       kind: Deployment
     calls:
       - name: server.example-ns
         kind: Service

In the YAML above, the service client is a Deployment in the namespace otterize-tutorial-istio-mapping, and it intends to call the service server is a Service in the namespace example-ns.

Implicit Specification​

This approach requires only the service name to be specified in the intent. When using the implicit approach, Otterize employs an identity resolution algorithm to determine the service kind.

   apiVersion: k8s.otterize.com/v1alpha3
   kind: ClientIntents
   metadata:
     name: client
     namespace: otterize-tutorial-istio-mapping
   spec:
     service:
       name: client
     calls:
       - name: server.example-ns

In the YAML above, both services has no kind specified. Otterize will resolve the kind of the service based on the identity resolution algorithm. Pay attention that by not specifying the kind, the identity resolution algorithm will not use the kubernetes kind:Service but will use the kind of the resource that owns the pod.

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:

  1. 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 setting global.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.
  2. 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 a Deployment named checkoutservice, which then creates and owns a ReplicaSet, which then creates and owns a Pod, then the service name for that pod is checkoutservice - same as the name of the Deployment. 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.