According to https://kubernetes.io/docs/reference/api-overview/, everything at /api/v1 is the "legacy" API group. Although the docs don't go into any further detail than that, my natural inference from the use of the word "legacy" is that:
However, in Module 2 of the Kubernetes tutorial, I'm instructed to use the legacy API group to access my newly-created pod:
Now we can make an HTTP request to the application running in that pod:
curl http://localhost:8001/api/v1/proxy/namespaces/default/pods/$POD_NAME/
What gives? Does the "legacy" API group actually contain functionality that doesn't exist anywhere else, or is there another, non-legacy way to make requests to my pod that the tutorial just hasn't been updated to reflect?
All newer Kubernetes API objects can be found in named API groups (like, for example, the Deployment object in the apps/v1 API group) -- which is also the group that you use in the apiVersion field when declaring new objects.
Older API objects (like the Pod or Service object) are found in the unnamed API group (also called core or legacy). Their apiVersion is just v1, without any name.
In this context, "legacy" does not appear to mean "please do not use it any more". Instead, it seems to mean something like "please do not add any more new objects to this API group". From reading the documentation, it does not look like the "legacy" API group will be deprecated any time soon (after all, it's not like there's any other API that you could use to create a Pod or a Service).
According to the respective design proposal, the goal is to...
...[break] the monolithic v1 API into modular groups and allowing groups to be enabled/disabled individually. This allows [the Kubernetes developers] to break the monolithic API server to smaller components in the future. [...] For backward compatibility, v1 objects belong to the group with an empty name, so existing v1 config files will remain valid.