Inject version label on pods to support istio destination_version queries

[jessesuen]

With istio, version is a special reserved word that can be applied as a label to pod specs, in order to get this values populated in metrics. From docs (https://istio.io/latest/docs/ops/deployment/requirements/#pod-requirements):

• Pods with app and version labels: We recommend adding an explicit app label and version label to the specification of the pods deployed using a Kubernetes Deployment. The app and version labels add contextual information to the metrics and telemetry that Istio collects.
  • The app label: Each deployment should have a distinct app label with a meaningful value. The app label is used to add contextual information in distributed tracing.
  • The version label: This label indicates the version of the application corresponding to the particular deployment.

Using the version label, queries can be performed using destination_version label. e.g.:

So the query istio_requests_total{destination_service="reviews.default.svc.cluster.local", destination_version="v3"} would require different values for version on every update.

This enhancement request is to implement a new rollout feature to inject version: <rollout revision number> on every update, which would make analysis queries against destination_version to work better out of the box when using Argo Rollouts and Istio.

Originally posted by @jessesuen in https://github.com/argoproj/argo-rollouts/issues/617#issuecomment-731387088

[mihneastaub]

Hello, any news about this enhancement?

[vipul0805]

@jessesuen Hi, I think changing the value of version on each rollout will cause difficulties in monitoring a large number of applications as the value of the label has to be changed in the monitoring dashboards while the Rollout is in progress.

I would like to suggest that the version label can be injected in both the DestinationRule and the pods through the feature #770. The feature has to be modified to add the label in the DestinationRule spec.subsets[].labels . After the Rollout these user-defined labels can be removed from the stable workload and added to the canary workload.

I would like to know your thoughts on this. Thanks

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity.

[Hronom]

Hey any news about this? Can we provide possibility to generate it based on tag of used image?

@jessesuen did you solved it in the end?

[Hronom]

Ok seems like I'm able to mention label version: 1.16.4 and it works. Also during rollback version reflected correctly. Here my Rollout file:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: reviews
spec:
  strategy:
    canary:
      canaryMetadata:
        annotations:
          role: canary
        labels:
          role: canary
      stableMetadata:
        annotations:
          role: stable
        labels:
          role: stable
      maxSurge: 100%
      maxUnavailable: 25%
      steps:
        - setCanaryScale:
            weight: 100
            matchTrafficWeight: false
        - setWeight: 20
        - pause:
            duration: 30s
        - setWeight: 40
        - pause:
            duration: 30s
        - setWeight: 60
        - pause:
            duration: 30s
        - setWeight: 80
        - pause:
            duration: 30s
        - setWeight: 100
      trafficRouting:
        istio:
          virtualService:
            name: reviews
          destinationRule:
            name: reviews
            stableSubsetName: stable
            canarySubsetName: canary
  replicas: 3
  selector:
    matchLabels:
      app: reviews
  template:
    metadata:
      labels:
        app: reviews
        version: 1.16.4
    spec:
      serviceAccountName: reviews
      containers:
        - name: reviews
          #image: docker.io/istio/examples-bookinfo-reviews-v3:1.17.0
          image: docker.io/istio/examples-bookinfo-reviews-v3:1.16.4
          imagePullPolicy: IfNotPresent
          readinessProbe:
            initialDelaySeconds: 1
            periodSeconds: 10
            httpGet:
              path: /health
              port: 9080
          env:
            - name: LOG_DIR
              value: "/tmp/logs"
          ports:
            - containerPort: 9080
          volumeMounts:
            - name: tmp
              mountPath: /tmp
            - name: wlp-output
              mountPath: /opt/ibm/wlp/output
          securityContext:
            runAsUser: 1000
      volumes:
        - name: wlp-output
          emptyDir: {}
        - name: tmp
          emptyDir: {}

is there any downsides of this approach?