Why is the YAML of "kubectl get" so different from the YAML of "kubectl apply" in GKE?

Question

I have a GKE cluster.

I used kubectl apply to apply the following YAML from my local machine:

apiVersion: v1
kind: Service
metadata:
  name: flask-app-svc
  namespace: myapp
spec:
  ports:
  - port: 5000
    targetPort: 5000
  selector:
    component: flask-app

Got applied. All Good. ✅

---

Then I used kubectl get service to get back the YAML from the cluster. It returned this:

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"ingress":true}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"5000":"k8s1-5fe0c3c1-myapp-flask-app-svc-5000-837dba94"},"zones":["asia-southeast1-a"]}'
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"flask-app-svc","namespace":"myapp"},"spec":{"ports":[{"port":5000,"targetPort":5000}],"selector":{"component":"flask-app"}}}
  creationTimestamp: "2021-10-29T14:40:49Z"
  name: flask-app-svc
  namespace: myapp
  resourceVersion: "242820340"
  uid: ad80f634-5aab-4147-8f71-11ccc44fd867
spec:
  clusterIP: 10.22.52.180
  clusterIPs:
  - 10.22.52.180
  ports:
  - port: 5000
    protocol: TCP
    targetPort: 5000
  selector:
    component: flask-app
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

---

1. What kubernetes "concept" is at play here?

2. Why are the 2 YAMLs SO DIFFERENT from each other?

3. What is happening under the hood?

4. Is this specific to GKE, or would any k8s cluster behave this way?

5. Where can I find some info/articles to learn more about this concept?

---

Thank you in advance.

I've been trying to wrap my head around this for a while. Appreciate any help you can advise and suggest here.

Answer 1

The Kubernetes API server validates and configures data for the API objects which include pods, services, replication controllers, and others. The API Server services REST operations and provides the frontend to the cluster's shared state through which all other components interact. The API server takes the definitions provided by the user to create all the detailed definitions needed to create the objects required. In this document you can find an overview of the GKE API server engine.

You can find an example on this document about a create operation. There you can switch between the request input and the response generated for the API server to create the complete definition of the objects required, its parameters, metadata and all the related configuration parameters that you see in the "extended" version of the original yaml file. In the same document you can find additional information about this topic.