github.com/argoproj/argo-cd@v1.8.7/docs/user-guide/diffing.md (about)

     1  # Diffing Customization
     2  
     3  It is possible for an application to be `OutOfSync` even immediately after a successful Sync operation. Some reasons for this might be:
     4  
     5  * There is a bug in the manifest, where it contains extra/unknown fields from the actual K8s spec. These extra fields would get dropped when querying Kubernetes for the live state,
     6  resulting in an `OutOfSync` status indicating a missing field was detected.
     7  * The sync was performed (with pruning disabled), and there are resources which need to be deleted.
     8  * A controller or [mutating webhook](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) is altering the object after it was
     9  submitted to Kubernetes in a manner which contradicts Git.
    10  * A Helm chart is using a template function such as [`randAlphaNum`](https://github.com/helm/charts/blob/master/stable/redis/templates/secret.yaml#L16),
    11  which generates different data every time `helm template` is invoked.
    12  * For Horizontal Pod Autoscaling (HPA) objects, the HPA controller is known to reorder `spec.metrics`
    13    in a specific order. See [kubernetes issue #74099](https://github.com/kubernetes/kubernetes/issues/74099).
    14    To work around this, you can order `spec.metrics` in Git in the same order that the controller
    15    prefers.
    16  
    17  In case it is impossible to fix the upstream issue, Argo CD allows you to optionally ignore differences of problematic resources.
    18  The diffing customization can be configured for single or multiple application resources or at a system level.
    19  
    20  ## Application Level Configuration
    21  
    22  Argo CD allows ignoring differences at a specific JSON path, using [RFC6902 JSON patches](https://tools.ietf.org/html/rfc6902). The following sample application is configured to ignore differences in `spec.replicas` for all deployments:
    23  
    24  ```yaml
    25  spec:
    26    ignoreDifferences:
    27    - group: apps
    28      kind: Deployment
    29      jsonPointers:
    30      - /spec/replicas
    31  ```
    32  
    33  The above customization could be narrowed to a resource with the specified name and optional namespace:
    34  
    35  ```yaml
    36  spec:
    37    ignoreDifferences:
    38    - group: apps
    39      kind: Deployment
    40      name: guestbook
    41      namespace: default
    42      jsonPointers:
    43      - /spec/replicas
    44  ```
    45  
    46  ## System-Level Configuration
    47  
    48  The comparison of resources with well-known issues can be customized at a system level. Ignored differences can be configured for a specified group and kind
    49  in `resource.customizations` key of `argocd-cm` ConfigMap. Following is an example of a customization which ignores the `caBundle` field
    50  of a `MutatingWebhookConfiguration` webhooks:
    51  
    52  ```yaml
    53  data:
    54    resource.customizations: |
    55      admissionregistration.k8s.io/MutatingWebhookConfiguration:
    56        ignoreDifferences: |
    57          jsonPointers:
    58          - /webhooks/0/clientConfig/caBundle
    59  ```
    60  
    61  The `status` field of `CustomResourceDefinitions` is often stored in Git/Helm manifest and should be ignored during diffing. The `ignoreResourceStatusField` setting simplifies
    62  handling that edge case:
    63  
    64  ```yaml
    65  data:
    66    resource.compareoptions: |
    67      # disables status field diffing in specified resource types
    68      # 'crd' - CustomResourceDefinition-s (default)
    69      # 'all' - all resources
    70      # 'none' - disabled
    71      ignoreResourceStatusField: crd
    72  ```
    73  
    74  By default `status` field is ignored during diffing for `CustomResourceDefinition` resource. The behavior can be extended to all resources using `all` value or disabled using `none`.
    75  
    76  ## Known Kubernetes types in CRDs (Resource limits, Volume mounts etc)
    77  
    78  Some CRDs are re-using data structures defined in the Kubernetes source base and therefore inheriting custom
    79  JSON/YAML marshaling. Custom marshalers might serialize CRDs in a slightly different format that causes false
    80  positives during drift detection. 
    81  
    82  A typical example is the `argoproj.io/Rollout` CRD that re-using `core/v1/PodSpec` data structure. Pod resource requests
    83  might be reformatted by the custom marshaller of `IntOrString` data type:
    84  
    85  from:
    86  ```yaml
    87  resources:
    88    requests:
    89      cpu: 100m
    90  ```
    91  
    92  to:
    93  ```yaml
    94  resources:
    95    requests:
    96      cpu: 0.1
    97  ```
    98  
    99  The solution is to specify which CRDs fields are using built-in Kubernetes types in the `resource.customizations`
   100  section of `argocd-cm` ConfigMap:  
   101  
   102  ```yaml
   103  apiVersion: v1
   104  kind: ConfigMap
   105  metadata:
   106    name: argocd-cm
   107    namespace: argocd
   108    labels:
   109      app.kubernetes.io/name: argocd-cm
   110      app.kubernetes.io/part-of: argocd
   111  data:
   112    resource.customizations: |
   113      argoproj.io/Rollout:
   114        knownTypeFields:
   115        - field: spec.template.spec
   116          type: core/v1/PodSpec
   117  ```
   118  
   119  The list of supported Kubernetes types is available in [diffing_known_types.txt](https://raw.githubusercontent.com/argoproj/argo-cd/master/util/argo/normalizers/diffing_known_types.txt)