Code change:
*  The named groups are at REST path `/apis/$GROUP_NAME/$VERSION` and use `apiVersion: $GROUP_NAME/$VERSION` (for example, `apiVersion: batch/v1`). You can find the full list of supported API groups in <del> [Kubernetes API reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/). </del> <ins> [Kubernetes API reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#-strong-api-groups-strong-). </ins> ## Enabling or disabling API groups   {#enabling-or-disabling} Certain resources and API groups are enabled by default. You can enable or disable them by setting `--runtime-config` on the API server.  The <del> `--runtime-config` flag accepts comma separated `<key>=<value>` pairs describing the runtime configuration of the API server. For example: </del> <ins> `--runtime-config` flag accepts comma separated `<key>[=<value>]` pairs describing the runtime configuration of the API server. If the `=<value>` part is omitted, it is treated as if `=true` is specified. For example: </ins> - to disable `batch/v1`, set `--runtime-config=batch/v1=false` - to enable `batch/v2alpha1`, set `--runtime-config=batch/v2alpha1`

Related discussion:
text: This is a... <!-- choose one by changing [ ] to [x] --- [x] Feature Request [ ] Bug Report Problem: I cannot find a list in the documentation of possible values for the API Server flag . Could this be provided, or instructions on how to generate the list documented? "Full list of supported API groups can be seen in .", but the top-level of all reference documentation does not clarify the list of possible strings. Proposed Solution: Document the available values in the Or in the Page to Update: Also here, although this is about the API, not the API Server.
have you been able to find the valid values for ? If you have an idea, I can help documenting it.
thanks for the offer. I have not located current possible values and do not have knowledge of the doc generation to propose a solution that will survive versions :( My short-term need is identifying which, if any, values I need to use with versions 1.4, 1.5, 1.6 to enable features including init-containers. However, the Right Thing is to have all possible values documented for each version.
Put me into the shame cube, I just ran into myself as well. Currently I'm trying to figure out why my 1.8 cluster doesn't have api . I think one of these values will work, I'll try these: - ( because ) -
OK I found it. The syntax works. My understanding: api/legacy: not sure what it does api/all: option to enable disable all APIs but obviously this isn't working for maybe because it's alpha core api groups syntax: expected. named api groups syntax: unexpected, because there's no or  prefix. specifying it or enables it, disables it. the list is comma-separated I can help you incorporate these into the docs if you're interested.
Per : : It sort of works if you treat as a placeholder (so, ). In your case: with and and no optional resource specified. This aligns with other docs, too: Certain resources and API groups are enabled by default. You can enable or disable them by setting on apiserver. accepts comma separated values. For example, to disable batch/v1, set , to enable batch/v2alpha1, set If this is the case, the flag help text and the paragraphs and the api groups pages could be clarified.