Configuring application name, component name and component version in K8s webhook

Deepfactor enable users to instrument their Kubernetes workload without the need to change their kubernetes pod/deployment yaml files. You can read more about how to enable the webhook for your K8s cluster in the article below.

Run your Kubernetes workload with Deepfactor

Users can also select the pods that should be run with Deepfactor enabled by using the fine grained options provided in the webhook config. You can read more about how to select the pods for Deepfactor instrumentation in the article below.

Selecting the pods you want to run with Deepfactor

Grouping pods into an application

Different enterprises deploy and run their application pods differently in their kubernetes clusters.

A few common scenarios are

1. All pods belonging to an application are deployed exclusively in a single namespace

2. Pods belonging to an application are spread across multiple namespaces but have the same label value (ex. app=myapp)

Deepfactor mutating admission webhook provides the appName config option to support the various use cases.

The appName option can be set at different levels

  • Global webhook config level: webhookconfig.appName 
    This setting will be applied for all namespaces in the cluster
  • Individual namespace level: webhookconfig.namespaces[x].appName 
    This setting will be applied for the individual namespace and will override the global setting (webhookconfig.appName) for this particular namespace alone.
  • Pod level via an annotation (df.k8-app.name) added to the podspec
    This setting will be applied for the individual pod and will override the global setting (webhookconfig.appName) and namespace level setting (webhookconfig.namespaces[x].appName) for this particular pod alone.

The appName option can be set to a literal string or a templatized string which takes the following variables

  • namespace
  • podName
  • labels.x (the value of the label 'x' in the podspec)

With this capability, users can pick the pods that should be grouped into a single application. A few common examples are covered in the table below.

appName Description When to use
%podName%
(Default)
Every pod will be shown as a separate application. All pods running with the same podName in all namespaces within the cluster will be mapped to the same application. You can filter based on the namespace on the Deepfactor portal UI.
Example: If a pod with the name 'user-service' is running in two namespaces 'dev' and 'staging', a single application named 'user-service' will be shown in the UI and namespace filter dropdown will have the options 'dev' and 'staging'

- You have a monolith running as a pod OR you want to view individual microservices as separate applications on the Deepfactor portal UI.

- You are running the same pod in multiple namespaces but want to view the insights from the pod in all namespaces in a single application

%namespace%

All pods within the namespace will be grouped into a single application with the namespace being the name of the application

Example: If you have two namespaces, 'publicapp' and 'privatetool' running 15 and 10 containers respectively, you will see two applications 'publicapp' and 'privatetool' on the Deepfactor portal UI with 15 and 10 components respectively

- You run all pods related to a single application in an exclusive namespace.

- You have less than 20 pod containers in your namespaces

We do not recommend using this mode for namespaces that have pods from different applications or for namespaces that have more than 20 containers. 

%podName%-%namespace%

Every pod running in every namespace will be shown as a separate application.

Example: If pod with name 'user-service' is running in two namespaces 'dev' and 'staging', two applications named 'user-service-dev' and 'user-service-staging' will be shown in the UI

- You have a monolith running as a pod OR you want to view individual microservices as separate applications on the Deepfactor portal UI.

- You are running the same pod in multiple namespaces and want to view the insights for the pod running in each namespace in a separate application

%labels.x%

All pods that have the same value for label 'x' in the podspec will be grouped into a single application.

Example: If 5 pods have the label 'app=user-service' in two namespaces 'dev' and 'staging' and the appName option is set to %labels.app%, then all of these pods will be grouped into an application called 'user-service' and namespace filter dropdown will have the options 'dev' and 'staging'

- You add a specific label to all the pods that belong to a single application.

- You want to see the insights of such pods running across different namespaces in a single application.

%labels.x%-%namespace%

All pods that have the same value for label 'x' in the podspec will be grouped into a single application per namespace.

Example: If 5 pods have the label 'app=user-service' in two namespaces 'dev' and 'staging' and the appName option is set to %labels.app%, then you will see two applications on the UI: 'user-service-dev' and 'user-service-staging'

- You add a specific label to all the pods that belong to a single application.

- You want to see the insights of such pods running across different namespaces as different applications on the Deepfactor portal UI

Note: You can use a combination of string literals and variables. Example: myapp-%labels.x%-%namespace%

Composing component names for containers

The previous section described the ways to group pods into an application for the different use cases. This section will describe how you can specify the name for the containers running within the pods.

Every container that is included for instrumentation by Deepfactor is treated as a separate component within the application. Users have the flexibility to name the components using the componentName option in the webhook config. 

Similar to appName, componentName option can be set at different levels as described below

  • Global webhook config level: webhookconfig.componentName 
    This setting will be applied for all namespaces in the cluster
  • Individual namespace level: webhookconfig.namespaces[x].componentName 
    This setting will be applied for the individual namespace and will override the global setting (webhookconfig.componentName) for this particular namespace alone
  • Pod level via an annotation (df.k8-app.comp/name) added to the podspec
    This setting will be applied for all containers within the individual pod and will override the global setting (webhookconfig.componentName) and namespace level setting (webhookconfig.namespaces[x].componentName) for this particular pod alone.
  • Container level via an annotation (df.k8-app.comp.<containerName>/name) added to the podspec
    This setting will be applied only to the container with name 'containerName' within the pod. This setting will override the global, namespace level and pod level setting for this container alone.

Similar to appName option, componentName option can be set to a literal string or a templatized string which takes the following variables

  • namespace
  • podName
  • containerName
  • containerImagePath
  • containerImageTag
  • labels.x (the value of the label 'x' in the podspec)

Note: If you are running multi container pods, then having at least one of the following three variables in the componentName option is mandatory to ensure different containers don't get assigned the same name.

  • containerName
  • containerImagePath
  • containerImageTag

With this capability, users can pick the names of their choice for the containers running with Deepfactor. A few common examples are covered in the table below.

componentName Description When to use
%containerName%
(Default)
The name specified for the container in the podspec will be used for the component name.
Example: If a pod has two containers with the names 'user-service' and 'logger', two components with the same names will be shown on the UI

You want to see the container name as the name of the component

%containerImagePath%

The container image path will be used for the component name

Example: If a pod has two containers with the container image paths as 'internal.deepfactor.acme.org/user-service:v1.0.0' and 'internal.deepfactor.acme.org/transaction-service:v1.0.1', then two components with the same name will be shown on the UI.

You want to see the container image path as the component name

%namespace%-%podName%-%containerName%

A concatenated string of namespace, podName and containerName will be used as component name.

Example: If a pod has the name 'user-service', is running in the 'dev' namespace and has two containers with names, 'springapp' and 'logger', two components with the names, 'dev-user-service-springapp' and 'dev-user-service-logger' will be shown on the UI

You would like to see the namespace and pod name along with container name in the component name

Note: You can use a combination of string literals and variables. Example: component-%namespace%-%podName%-%containerName%

Assigning component version

This section will describe the componentVersion option which can be used to specify the version of the component for every container.

Similar to componentName option, componentVersion option can be specified at different levels as described below

  • Global webhook config level: webhookconfig.componentVersion
    This setting will be applied for all namespaces in the cluster
  • Individual namespace level: webhookconfig.namespaces[x].componentVersion
    This setting will be applied for the individual namespace and will override the global setting (webhookconfig.componentVersion) for this particular namespace alone
  • Pod level via an annotation (df.k8-app.comp/version) added to the podspec
    This setting will be applied for all containers within the individual pod and will override the global setting (webhookconfig.componentVersion) and namespace level setting (webhookconfig.namespaces[x].componentVersion) for this particular pod alone.
  • Container level via an annotation (df.k8-app.comp.<containerName>/version) added to the podspec
    This setting will be applied only to the container with name 'containerName' within the pod. This setting will override the global, namespace level and pod level setting for this container alone.

Similar to appName and componentName options, componentVersion option can be set to a literal string or a templatized string which takes the following variables

  • ImageID

  • ImageTag

By default, %imageTag% is used for the component version and you can view the image tags in the version filter dropdown on the UI. If you would like to use the imageID instead of the imageTag, please set this option to %imageID% in the webhook config.

Example: Consider the following deployment yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: demo-app
spec:
  selector:
    matchLabels:
      app: nginx-server
  template:
    metadata:
      labels:
        app: nginx-server
        logging: info
    spec:
      containers:
      - name: nginx-container
        ports: 
        - containerPort: 4000
          image: nginx:1.23.0

Webhook options and the output values are shown below:

Option Option value Output
appName "app-%labels.app%" app-nginx-server
componentName "comp-%containerName%" comp-nginx-container
componentVersion "%imageTag% 1.23.0

 

Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Please sign in to leave a comment.