Demo Patterns Wildcards

In this lesson you’ll learn how to use Kyverno pattern wildcards to enforce that every container in a Pod declares CPU and memory requests and limits. This is a common policy need to ensure predictable scheduling and resource accounting across a cluster. Overview

We create a ClusterPolicy named all-containers-need-requests-and-limits that enforces CPU and memory requests and limits for every container in a Pod.
The policy uses Kyverno pattern wildcards to match any container and require that the resource fields exist and are non-empty.

ClusterPolicy (ensures every container in a Pod has non-empty CPU and memory requests and limits)

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: all-containers-need-requests-and-limits
spec:
  rules:
    - name: check-container-resources
      match:
        any:
          - resources:
              kinds:
                - Pod
      validationFailureAction: enforce
      validate:
        message: "All containers must have CPU and memory resource requests and limits defined."
        pattern:
          spec:
            containers:
              # Match every container in the pod. The `name` field is optional and shown
              # here only as a visual aid.
              - name: "*"
                resources:
                  limits:
                    # `?` requires at least one character and `*` means zero or more characters.
                    # Using them together as `?*` requires at least one character (i.e., a non-empty value).
                    memory: "?*"
                    cpu: "?*"
                  requests:
                    memory: "?*"
                    cpu: "?*"

How the pattern and wildcards work

The policy targets Pod resources via match and applies a pattern to spec.containers.
Using - name: "*" applies the pattern to every element in the containers list.
The ?* wildcard is applied to string fields to require presence and non-empty values (we are not validating format, only that some value exists).

Wildcard summary

Wildcard	Meaning
`*`	Matches zero or more characters. Useful for optional/any content.
`?`	Matches exactly one character.
`?*`	Combined usage — requires at least one character (ensures a non-empty string).

In Kyverno patterns, using ?* on a string field ensures the field is present and contains at least one character (examples: 100m, 128Mi). Use this when you need to validate presence without enforcing a specific value format.

This policy uses validationFailureAction: enforce, so requests that violate the rule are rejected by the admission webhook. During development, consider validationFailureAction: audit if you want to observe violations without blocking resources.

Apply the policy

kubectl apply -f enforce-containers.yaml

Expected output

clusterpolicy.kyverno.io/all-containers-need-requests-and-limits created

Test a Pod that violates the policy (no resources defined) pod-bad-resource.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: bad-pod
spec:
  containers:
    - name: my-container
      image: nginx

Apply the bad pod (using stdin for demonstration)

kubectl apply -f - <<EOF
# pod-bad-resource.yaml
apiVersion: v1
kind: Pod
metadata:
  name: bad-pod
spec:
  containers:
  - name: my-container
    image: nginx
EOF

Expected rejection (admission webhook denies the request)

Error from server: error when creating "STDIN": admission webhook "validate.kyverno.svc-fail" denied the request:

resource Pod/default/bad-pod was blocked due to the following policies

all-containers-need-requests-and-limits:
  check-container-resources: 'validation error: All containers must have CPU and memory resource requests and limits defined. Rule check-container-resources failed at path /spec/containers/0/resources/limits/'

Why it was rejected

The policy pattern requires limits.memory, limits.cpu, requests.memory, and requests.cpu to be present and non-empty for every container.
The example pod lacked the resources block entirely, so Kyverno denied creation and returned the policy message.

Create a Pod that complies with the policy pod-good-resource.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: good-pod
spec:
  containers:
    - name: my-container
      image: nginx
      resources:
        requests:
          cpu: "100m"
          memory: "128Mi"
        limits:
          cpu: "200m"
          memory: "256Mi"

Apply the good pod

kubectl apply -f pod-good-resource.yaml

Expected output

pod/good-pod created

Explanation

The pod was created successfully because each container included all four resource fields (requests.cpu, requests.memory, limits.cpu, limits.memory) and each value matched the ?* requirement (non-empty string).

Best practices and summary

Use - name: "*" to apply a pattern to every element in a list (e.g., every container).
Use ?* on string fields to require that they exist and are non-empty without enforcing a specific format.
Use validationFailureAction: enforce to actively block invalid resources; use audit to log violations without blocking during policy rollout.
This pattern avoids per-container rules and enforces resource declarations cluster-wide with a single, maintainable policy.

Links and references

Watch Video