K
Q

Kubernetes resources by API groups

10/20/2018

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

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
-- Ijaz Ahmad Khan
kubernetes

Similar Questions

Set authentication-token-webhook-config-file
kubernetes LoadBalancer service
Is there any way to cache loaded images on Kubernetes
vswitch not found hyperV while running minikube start
How to claim & configure Bitnami Docker Discourse data in Kubernetes Persistent volume?

1 Answer

10/20/2018

It's part of backward compatibility. Generally, features/resources are introduced as extensions and when they graduate on later Kubernetes releases they become part of the core or apps or something else API. Refer to the deprecation policy to see how it works with respect to Kubernetes releases.

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

  • extensions generally older than code, apps, etc.
  • v1alphav1 -> v1alphav2 -> v1alphavN -> v1betav1 -> v1betav2 -> v1betavN -> v1core/v1apps/etc -> v2alpha/v2beta/v2core -> vNalpha/vNbeta/vNcore/etc
-- Rico
Source: StackOverflow