Introduce ExternalWorkload CRD

[mateiidavid]

To support mesh expansion, the control plane needs to read configuration associated with an external instance (i.e. a VM) for the purpose of service and inbound authorization policy discovery.

This change introduces a new CRD that supports the required configuration options. The resource supports:

• a list of workload IPs (with a generic format to support ipv4 and ipv6 in the future)
• a set of mesh TLS settings (SNI and identity)
• a set of ports exposed by the workload
• a set of status conditions

---

Some background on choices

OpenAPI supports validation, where applicable, we add validation rules.

• We validate SNI & Identity are max 253 characters (max allowed for a DNS name, although for identity it might not make sense since we will support URIs. SNI is based on DNS though).
• We validate conditions, but a resource may be created without a status. Condition validation is taken from the httproute resource since it follows a very similar format.
• We do not require meshTls settings, but we require workloadIPs and ports.

Unfortunately, for ips we cannot add any server side validation through the schema since we plan on supporting both ipv4 and ipv6. All IPs will have to be parsed and validated in the controllers that read the resource.

For printer columns, we list the age and the identity. IPs and ports will not render properly since printer columns only support primitive data types (record types can still be printed but in debug format). A choice would be to eliminate the need for an ip key and have the IPs printed as `["192.0.2.0", "192.0.3.0"].

Output:

NAME              IDENTITY                                           AGE
nginx-vm-test-3   foo.default.serviceaccount.linkerd.cluster.local   2m56s
nginx-vm-test-4   bar.default.serviceaccount.linkerd.cluster.local   2s

and with IPs as a printer column:

NAME              IPS                    PORTS
nginx-vm-test-3   [{"ip":"192.0.2.2"}]   [{"port":8080,"protocol":"TCP"},{"port":7777,"protocol":"TCP"}]

apiVersion: workload.linkerd.io/v1alpha1
kind: ExternalWorkload
metadata:
  annotations:
    config.linkerd.io/default-inbound-policy: deny
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"workload.linkerd.io/v1alpha1","kind":"ExternalWorkload","metadata":{"annotations":{"config.linkerd.io/default-inbound-policy":"deny"},"labels":{"app":"echo-service"},"name":"nginx-vm-test-3","namespace":"default"},"spec":{"meshTls":{"identity":"foo.default.serviceaccount.linkerd.cluster.local","serverName":"foo.default.serviceaccount.linkerd.cluster.local"},"ports":[{"port":8080,"protocol":"TCP"},{"port":7777,"protocol":"TCP"}],"workloadIPs":[{"ip":"192.0.2.2"}]},"status":{"conditions":[{"status":"True","type":"Ready"}]}}
  creationTimestamp: "2023-12-20T14:48:22Z"
  generation: 1
  labels:
    app: echo-service
  name: nginx-vm-test-3
  namespace: default
  resourceVersion: "31812"
  uid: 21a22e4e-36c7-4315-973c-90cc39ad83af
spec:
  meshTls:
    identity: foo.default.serviceaccount.linkerd.cluster.local
    serverName: foo.default.serviceaccount.linkerd.cluster.local
  ports:
  - port: 8080
    protocol: TCP
  - port: 7777
    protocol: TCP
  workloadIPs:
  - ip: 192.0.2.2
status:
  conditions:
  - status: "True"
    type: Ready

[alpeb]

This is exciting! 🥳

[alpeb]

Why isn't identity required?

[mateiidavid]

Good question. Ports and workload IPs are necessary to fill out an EndpointSlice, so they need to be present on the resource when we start indexing. But identity / tls settings aren't a necessity strictly speaking. I thought maybe it makes sense to have looser server side validation requirements here to start with. Maybe it does make sense to also require these up front though. We could always do that as a follow-up; could there be external endpoints expressed through this resource that do not require TLS settings? I might be thinking a bit too far ahead heh.