@Vijin Palazhi @Mumshad Mannambeth 1. When we have an existing pod and we want t . . .

Kubernetes
#1

Jia:
@Vijin Palazhi @Mumshad Mannambeth

  1. When we have an existing pod and we want to modify it, we do kubectl get <podname> -o yaml > some.yaml
    This some.yaml has too much extra data also suppose we tend to just change the serviceaccountName but we also have the volumeMount we get by default due to default serviceaccounttoken and forgot to remove it… whats the best way to modify the existing pod and how to extract just the relevant data ?
    David had suggested to use
    kubectl get po nginx -o yaml --dry-run > test.yaml but it errors out in 1.20… and Mayman had suggested kubectl get pod nginx -o yaml | grep -v “f:” > pod.yaml but this doesnt extracts the data
    Please help
#2

Tej_Singh_Rana:
> kubectl get po nginx -o yaml --dry-run > test.yaml
I think you don’t need to use --dry-run with above command.

#3

Tej_Singh_Rana:
> Mayman had suggested kubectl get pod nginx -o yaml | grep -v “f:” > pod.yaml but this doesnt extracts the data
I would prefer this suggestion, rest we can manage from Vi editor.

#4

Jia:
@Tej_Singh_Rana kubectl get po nginx -o yaml --dry-run > test.yaml
This gives the extra fields so not a shortcut

#5

Jia:
kubectl get pod nginx -o yaml | grep -v “f:” > pod.yaml but this doesnt extracts the data
—> If someone has any shortcut, would love to know… as the above does not removes all the unnecessary data

#6

Jia:
I think there should be something, is it new in v1.20 where so much data is added

#7

chris resnik:
> kubectl get po nginx -o yaml --dry-run > test.yaml
as pointed out, “dry-run” is not required for existing resources

#8

chris resnik:
as Jia wrote, you’ll have to do with
> grep -v “f:
unfortunately, --export was deprecated a couple of versions ago

#9

chris resnik:
at the moment, it looks like you will not get nice-to-look-at yaml files from existing resources

#10

Jia:
Thanks Chris… yes seems like

#11

Shwetha Shenoy V:
You could consider using kubectl version 1.21, if your server is on 1.20. Kubectl 1.21 doesnt output the managed fields in yaml.

#12

Jia:
but at any point kubectl or any component should not be greater than kube-apiserver version… this may cause issues… @Vijin Palazhi @Shwetha Shenoy V thoughts ?

#13

Shwetha Shenoy V:
kubectl supports a +/-1 version skew from current version.
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#supported-releases-and-component-skew

From the doc:
> A client should be skewed no more than one minor version from the master, but may lead the master by up to one minor version
> For example, a v1.3 master should work with v1.1, v1.2, and v1.3 nodes, and should work with v1.2, v1.3, and v1.4 clients.

#14

Shwetha Shenoy V:
Version skew between other components also possible according to https://kubernetes.io/releases/version-skew-policy/