How to identify API of created deployment YAML-CodePudding

I am migrating the Kubernetes deployments from API version extensions/v1beta1 to apps/v1.

I've changed the API group in deployment to apps/v1 and applied the deployment.

However when I check the deployment using get deployment -o yaml it's showing deployment in extensions/v1beta1 API group and when I check using get deployment.apps -o yaml, it's showing in app/v1 API group.

can you please let us know a way to identify the API group of the created deployment YAML other than displaying the YAMLs using the commands get deployment -o yaml or get deployment.app -o yaml since the output apiVersion is just based on the command we give irrespective of the one with which it was created.

I just need to make sure that my deployment is migrated to apps/v1.

CodePudding user response：

Kubernetes automatically handles API version conversion. This can happen when you upgrade the cluster - or when requesting a resource in a different api version that is supported by your cluster. The stored objects in etcd are always upgraded to the latest version when edited or during creation.

If you want to bulk upgrade all deployments you could use a command like

kubectl get deployment --all-namespaces -o json | kubectl replace -f -

The changed api version in your manifests is especially important to future-proof the files, in case you want to create/apply them in a newer cluster that does not support the old api versions.

CodePudding user response：

You may view all api resources and versions by command kubectl api-resources

~# kubectl api-resources
NAME                              SHORTNAMES   APIVERSION                             NAMESPACED   KIND
limitranges                       limits       v1                                     true         LimitRange
namespaces                        ns           v1                                     false        Namespace
nodes                             no           v1                                     false        Node
services                          svc          v1                                     true         Service
mutatingwebhookconfigurations                  admissionregistration.k8s.io/v1        false        MutatingWebhookConfiguration
validatingwebhookconfigurations                admissionregistration.k8s.io/v1        false        ValidatingWebhookConfiguration
customresourcedefinitions         crd,crds     apiextensions.k8s.io/v1                false        CustomResourceDefinition
apiservices                                    apiregistration.k8s.io/v1              false        APIService
deployments                       deploy       apps/v1                                true         Deployment
…

In the APIVERSION column, you can see the resource version used by the current cluster.

Here are some other viewing tips.

You can check the version of the api through kubectl api-versions

~# kubectl api-versions
admissionregistration.k8s.io/v1
admissionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1
…

If you want to view the fields of a resource, you can check which fields it has through kubectl explain <resource name>

~# kubectl explain deploy
I1228 16:22:05.186255   57803 request.go:668] Waited for 1.105127456s due to client-side throttling, not priority and fairness, request: GET:https://kubernetes.docker.internal:6443/apis/policy/v1beta1?timeout=32s
KIND:     Deployment
VERSION:  apps/v1

DESCRIPTION:
     Deployment enables declarative updates for Pods and ReplicaSets.

FIELDS:
   apiVersion   <string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

   kind <string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

   metadata <Object>
     Standard object metadata.

   spec <Object>
     Specification of the desired behavior of the Deployment.

   status   <Object>
     Most recently observed status of the Deployment.

You can also see the version of deployment in the Version field here.

Furthermore, the above command does not list all the api fields. In fact, the above list is only the first-level fields. The first-level fields may also contain second-level and third-level fields. I want to list all the api fields. Fields, you can add --recursive to list all possible fields.

~# kubectl explain deploy --recursive
I1228 16:24:54.950197   57954 request.go:668] Waited for 1.187183007s due to client-side throttling, not priority and fairness, request: GET:https://kubernetes.docker.internal:6443/apis/batch/v1beta1?timeout=32s
KIND:     Deployment
VERSION:  apps/v1

DESCRIPTION:
     Deployment enables declarative updates for Pods and ReplicaSets.

FIELDS:
   apiVersion   <string>
   kind <string>
   metadata <Object>
      annotations   <map[string]string>
      clusterName   <string>
      creationTimestamp <string>
…

The above is just a list of all the api names. If you want to know the detailed information of a certain api name, you can view it by kubectl explain . For example, the following example can view the spec under service Information in the ports field under.

~# kubectl explain svc.spec.ports
I1228 16:26:31.625776   58094 request.go:668] Waited for 1.098854835s due to client-side throttling, not priority and fairness, request: GET:https://kubernetes.docker.internal:6443/apis/node.k8s.io/v1beta1?timeout=32s
KIND:     Service
VERSION:  v1

RESOURCE: ports <[]Object>

DESCRIPTION:
     The list of ports that are exposed by this service. More info:
     https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

     ServicePort contains information on service's port.

FIELDS:
   appProtocol  <string>
     The application protocol for this port. This field follows standard
     Kubernetes label syntax. Un-prefixed names are reserved for IANA standard
     service names (as per RFC-6335 and
     http://www.iana.org/assignments/service-names). Non-standard protocols
     should use prefixed names such as mycompany.com/my-custom-protocol. This is
     a beta field that is guarded by the ServiceAppProtocol feature gate and
     enabled by default.

   name <string>
     The name of this port within the service. This must be a DNS_LABEL. All
     ports within a ServiceSpec must have unique names. When considering the
     endpoints for a Service, this must match the 'name' field in the
     EndpointPort. Optional if only one ServicePort is defined on this service.

   nodePort <integer>
…

CodePudding user response：

As I understand, you want to view the last applied configuration for the deployments?

If yes, you should use kubectl apply view-last-applied command.

Example for the one specific deployment:

kubectl apply view-last-applied deployment {your-deployment-name}

Example for the all deployments:

kubectl get deployments -o name | xargs kubectl apply view-last-applied