Add subresource marker to workload CRD

[mateiidavid]

Our ExternalWorkload resource has a status field, but the status is not marked as a subresource in the object's schema. Status patches are done in libraries through a separate interface; without marking the status as a subresource, the API Server will respond to patch requests with a 404. This makes ExternalWorkload resource statuses unpatachable from controllers.

We fix the issue by marking the status as a subresource in the v1beta1 schema. No codegen changes are necessary. The version is not bumped since this does not change the existing contract offered by an ExternalWorkload; it only allows the API Server to treat its status as a subresource when patching it (i.e. we can use the patch_status interface).

Additional context:

• In Kubernetes, each resource has its own declarative API that can be used to change its state.
• Resources may optionally include other declarative APIs that are decoupled from the main resource's state; this includes Scale and Status subresources. They can be thought of as a set of shared interfaces that add additional information to a resource.
• Statuses are meant to be patched through a separate interface as a result. This allows both:
  • A separation of concerns: either patch the spec or the status but not both to avoid overwriting or deleting fields
  • Principle of least privileged: fine-grained RBAC can be used to isolate spec writes from status writes.
• Subresources get their own API paths, writing to a subresource means we are effectively sending a requested to a nested path (e.g. /status on a pod). The API server needs to know this path is available.
• CRDs require that fields are marked as a subresource, without doing so, the API Server will reply with a 404 Not Found when attempting to modify a status, since the path doesn't exist (I assume).

See:

• Kubernetes docs
• API conventions

Testing

I tested we can patch the status with a toy controller. kubectl patch --subresource='status' should work as well.

I also tested we can upgrade from edge to current build:

• Install edge.
• Upgrade CRDs
• Restart workloads
• Upgrade linkerd

To test patching works, apply:

apiVersion: workload.linkerd.io/v1beta1
kind: ExternalWorkload
metadata:
  name: test-external
  namespace: default
spec:
  workloadIPs:
  - ip: 192.0.2.0
  meshTLS:
    identity: test-external.default.svc.cluster.local
    serverName: test-external.default.svc.cluster.local
  ports:
  - port: 80

Before the change, patch requests receive a 404 Not Found

:; kubectl patch externalworkloads.workload.linkerd.io test-external --subresource='status' --type='merge' -p '{"status":{"conditions": {"type": "test"}}}'
Error from server (NotFound): externalworkloads.workload.linkerd.io "test-external" not found

After, patch requests are processed

Warning: unknown field "status.conditions.type"
The ExternalWorkload "test-external" is invalid:
* status.conditions: Invalid value: "object": status.conditions in body must be of type array: "object"
* status.conditions.status: Required value
* status.conditions.type: Required value

[alpeb]

Makes sense to me, thanks for the detailed explanation 👍
Doesn't this require finer RBAC on the externalworkloads/status resource? Or that would only apply to controllers attempting to patch that?

[mateiidavid]

Doesn't this require finer RBAC on the externalworkloads/status resource? Or that would only apply to controllers attempting to patch that?

Yup, it would require RBAC but indeed only if we want to patch it. None of our controllers do that.