How to find non-portable fields from existing kubernetes resources configuration?

7/18/2019

Cluster information: Kubernetes version: v1.12.8-gke.10 on GCP

Question: I’m doing application migration now. The thing I do is to grab all configurations of related resources and then deploy them to a new cluster. After getting information from shell command kubectl get <resource> -o yaml, I noticed that there is a lot of information that my deploy YAMLs don’t have.

I deleted .spec.clusterIP, .metadata.uid, .metadata.selfLink, .metadata.resourceVersion, .metadata.creationTimestamp, .metadata.generation, .status, .spec.template.spec.securityContext, .spec.template.spec.dnsPolicy, .spec.template.spec.terminationGracePeriodSeconds, .spec.template.spec.restartPolicy fields.

  1. I’m not sure is there other fields that will influence the new deployment I need to delete?
  2. Is there a way to find all non-portable fields that I can delete?
  3. And another question is: do all related resources matter? For now I just grab a list of resources from kubectl api-resources and then get info of them one by one. Should I ignore some resources like ReplicaSet to migrate the whole application?

For example, output configuration of nginx deployment will be like:

  kind: Deployment
  metadata:
    annotations:
      deployment.kubernetes.io/revision: "1"
    creationTimestamp: "2019-07-16T21:55:39Z"
    generation: 1
    labels:
      app: nginx
    name: nginx-deployment
    namespace: default
    resourceVersion: "1482081"
    selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx-deployment
    uid: 732377ee-a814-11e9-bbe9-42010a8a001a
  spec:
    progressDeadlineSeconds: 600
    replicas: 2
    revisionHistoryLimit: 10
    selector:
      matchLabels:
        app: nginx
    strategy:
      rollingUpdate:
        maxSurge: 25%
        maxUnavailable: 25%
      type: RollingUpdate
    template:
      metadata:
        creationTimestamp: null
        labels:
          app: nginx
      spec:
        containers:
        - image: nginx:1.7.9
          imagePullPolicy: IfNotPresent
          name: nginx
          ports:
          - containerPort: 80
            protocol: TCP
          resources: {}
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
        dnsPolicy: ClusterFirst
        restartPolicy: Always
        schedulerName: default-scheduler
        securityContext: {}
        terminationGracePeriodSeconds: 30
  status:
    availableReplicas: 2
    conditions:
    - lastTransitionTime: "2019-07-16T21:55:41Z"
      lastUpdateTime: "2019-07-16T21:55:41Z"
      message: Deployment has minimum availability.
      reason: MinimumReplicasAvailable
      status: "True"
      type: Available
    - lastTransitionTime: "2019-07-16T21:55:39Z"
      lastUpdateTime: "2019-07-16T21:55:41Z"
      message: ReplicaSet "nginx-deployment-5c689d88bb" has successfully progressed.
      reason: NewReplicaSetAvailable
      status: "True"
      type: Progressing
    observedGeneration: 1
    readyReplicas: 2
    replicas: 2
    updatedReplicas: 2```
-- Mike Que
google-kubernetes-engine
kubernetes

1 Answer

7/23/2019

Right off the bat, there is no way to detect which fields are cluster-specific automatically, the kubectl get [resource] -o yaml is outputting the current RESTful state of the resource. However, you can use some linux bash to manipulate the ouput of a cluster dump to get the fields you want. Take a look at this blog post on medium.

As to the "do all resources matter" the answer is no. If you have a deployment, you don't need the replicaSet or the pod resources since the deployment will manage and create those once it is deployed. You just need the top level controller resource (same thing does for daemonsets and statefulsets).

On another note, the fields from the spec section can mostly all be kept, the values that you are removing are likely default values you never set initially but there is no real benefit in removing them.

-- Patrick W
Source: StackOverflow