<p>Can someone explain why some of these resources are both in apps and extensions api-group.</p>

<pre><code>C02W84XMHTD5:~ iahmad$ kubectl api-resources --api-group=apps
NAME                  SHORTNAMES   APIGROUP   NAMESPACED   KIND
controllerrevisions                apps       true         ControllerRevision
daemonsets            ds           apps       true         DaemonSet
deployments           deploy       apps       true         Deployment
replicasets           rs           apps       true         ReplicaSet
statefulsets          sts          apps       true         StatefulSet
C02W84XMHTD5:~ iahmad$ 
C02W84XMHTD5:~ iahmad$ 
C02W84XMHTD5:~ iahmad$ kubectl api-resources --api-group=extensions
NAME                  SHORTNAMES   APIGROUP     NAMESPACED   KIND
daemonsets            ds           extensions   true         DaemonSet
deployments           deploy       extensions   true         Deployment
ingresses             ing          extensions   true         Ingress
networkpolicies       netpol       extensions   true         NetworkPolicy
podsecuritypolicies   psp          extensions   false        PodSecurityPolicy
replicasets           rs           extensions   true         ReplicaSet
</code></pre>

<p>It's part of backward compatibility. Generally, features/resources are introduced as <code>extensions</code> and when they graduate on later Kubernetes releases they become part of the <code>core</code> or <code>apps</code> or something else API. Refer to the <a href="https://kubernetes.io/docs/reference/using-api/deprecation-policy/" rel="nofollow noreferrer">deprecation policy</a> to see how it works with respect to Kubernetes releases.</p>

<p>In case you are wondering the general rule is something like this from older to newer.</p>

<ul>
<li><code>extensions</code> generally older than <code>code</code>, <code>apps</code>, etc.</li>
<li>v1alphav1 -> v1alphav2 -> v1alphavN -> v1betav1 -> v1betav2 -> v1betavN -> v1core/v1apps/etc -> v2alpha/v2beta/v2core -> vNalpha/vNbeta/vNcore/etc</li>
</ul>
