Update Provisioner Docs Example

[DWSR]

The spec.limits.resources.cpu field should be a string, not an int.

1. Issue, if available:

An example in the docs is incorrect

2. Description of changes:

Updated example to be correct

3. How was this change tested?

N/A

4. Does this change impact docs?

• Yes, PR includes docs updates
• Yes, issue opened: link to issue
• No

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[netlify]

✔️ Deploy Preview for karpenter-docs-prod ready!

🔨 Explore the source changes: c7f79a8

🔍 Inspect the deploy log: https://app.netlify.com/sites/karpenter-docs-prod/deploys/61f9b39112b1fc00087ef9b7

😎 Browse the preview: https://deploy-preview-1231--karpenter-docs-prod.netlify.app

[bwagner5]

Did you experience an error with that yaml? I just applied it to my cluster and it worked for me:

$ cat <<EOF | kubectl apply -f -
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: test-1
spec:
  limits:
    resources:
      cpu: 1000
      memory: 1000Gi
  requirements:
....

$ k get provisioner test-1 -o yaml
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  ...
  name: test-1
spec:
  kubeletConfiguration: {}
  limits:
    resources:
      cpu: 1k
      memory: 1000Gi```

[ellistarn]

Is this necessary? IIUC, the integer works just fine.

[bwagner5]

I believe quotes are only required if the field is a string and the input is a number. In that case, you'd need to use quotes to tell yaml that you're actually passing a string rather than a number.

https://github.com/aws/karpenter/blob/main/charts/karpenter/crds/karpenter.sh_provisioners.yaml#L65-L67

[DWSR]

@bwagner5 @ellistarn The kube API seems to return a string regardless of the type submitted to the API server, based on my Very Scientific Testing on my 1.20.11 EKS cluster.

Applying a provisioner that uses integer limits via ArgoCD will cause ArgoCD to always mark the resource as Out of Sync.

[ellistarn]

Nice catch!

Can you include this in /preview docs? We copy preview docs into the next release version when we release. Optionally, you could backport this to older versions of docs, but I'm happy with it just being included in the next release.

[ellistarn]

Thank you!