Kubernetes CRD: Show durations in additionalPrinterColumns

I will answer on your question partially so you have some understanding and ideas on what/how/where.

kubectl get

When kubectl get jobs is executed, kubernetes API server decides which fields to provide in response:

The kubectl tool relies on server-side output formatting. Your cluster's API server decides which columns are shown by the kubectl get command

See here.

Duration field for jobs is also calculated on the server's side. This happens because job is a well-known resource for kubernetes server and it's built into the code "How to print the response". See JobDuration - printer.

This also can be checked by running regular command:

kubectl get job job-name --v=8

And then using server-print flag set to false (default is true for human-readable reasons):

kubectl get job job-name --v=8 --server-print=false

With last command only general information will be returned and name and age will be shown in output.

What can be done

Let's start with CRDs and controllers:

On their own, custom resources let you store and retrieve structured data. When you combine a custom resource with a custom controller, custom resources provide a true declarative API.

The Kubernetes declarative API enforces a separation of responsibilities. You declare the desired state of your resource. The Kubernetes controller keeps the current state of Kubernetes objects in sync with your declared desired state. This is in contrast to an imperative API, where you instruct a server what to do.

Moving forward to feature gates. We're interested in CustomResourceSubresources:

Enable /status and /scale subresources on resources created from CustomResourceDefinition.

This feature gate is enabled by default starting from kubernetes 1.16.

Therefore custom field like duration-execution could be created within CRD subresource's status and custom controller could update the value of the given field whenever the value is changed using watch update funtion.

Part 2

There's a controller prunning that should be taken into consideration:

By default, all unspecified fields for a custom resource, across all versions, are pruned. It is possible though to opt-out of that for specific sub-trees of fields by adding x-kubernetes-preserve-unknown-fields: true in the structural OpenAPI v3 validation schema.

Here's a very similar answer about custom field and additionalPrinterColumns.