Quickly creating kubernetes manifest files
When someone is just starting with kubernetes, writing manifest files can be a bit difficult. In this post I will try to give some tips in writing manifest files easily.
Pods
Use the generator to create pods. Verify if the given entries are syntactically correct by doing a dry run.
1kubectl run --generator=run-pod/v1 <pod name> --image <image to use> --dry-run
Save the pod definition to a yaml file for future changes as well as reference
1kubectl run --generator=run-pod/v1 <pod name> --image <image to use> --dry-run -o yaml > pod.yaml
Example:
1slashpai@pai ~ (⎈ |kind-pai:default) kubectl run --generator=run-pod/v1 nginx-pod --image nginx --dry-run
2pod/nginx-pod created (dry run)
3slashpai@pai ~ (⎈ |kind-pai:default) kubectl run --generator=run-pod/v1 nginx-pod --image nginx --dry-run -o yaml > pod.yaml
1slashpai@pai ~ (⎈ |kind-pai:default) cat pod.yaml
2apiVersion: v1
3kind: Pod
4metadata:
5 creationTimestamp: null
6 labels:
7 run: nginx-pod
8 name: nginx-pod
9spec:
10 containers:
11 - image: nginx
12 name: nginx-pod
13 resources: {}
14 dnsPolicy: ClusterFirst
15 restartPolicy: Always
16status: {}
17slashpai@pai ~ (⎈ |kind-pai:default)
Deployment
Generator for deployment is deprecated so following way helps. Verify if given entries are syntactically correct by doing a dry run
1kubectl create deployment <deployment name> --image <image to use> --dry-run
Save the deployment definition to a yaml file for future changes as well as reference
1kubectl create deployment <deployment name> --image <image to use> --dry-run -o yaml > deployment.yaml
Example:
1slashpai@pai ~ (⎈ |kind-pai:default) kubectl create deployment nginx-deployment --image nginx --dry-run
2deployment.apps/nginx-deployment created (dry run)
3slashpai@pai ~ (⎈ |kind-pai:default) kubectl create deployment nginx-deployment --image nginx --dry-run -o yaml > deployment.yaml
1slashpai@pai ~ (⎈ |kind-pai:default) cat deployment.yaml
2apiVersion: apps/v1
3kind: Deployment
4metadata:
5 creationTimestamp: null
6 labels:
7 app: nginx-deployment
8 name: nginx-deployment
9spec:
10 replicas: 1
11 selector:
12 matchLabels:
13 app: nginx-deployment
14 strategy: {}
15 template:
16 metadata:
17 creationTimestamp: null
18 labels:
19 app: nginx-deployment
20 spec:
21 containers:
22 - image: nginx
23 name: nginx
24 resources: {}
25status: {}
26slashpai@pai ~ (⎈ |kind-pai:default)
27
ReplicaSet
There is no direct way I could find to create this from kubectl. I found this trick though till I could find a better way. Use the same way to create deployment and modify kind to ReplicaSet in the yaml file and remove fields specific to deployment. I found this with trial and error, so this is the diff file.
1slashpai@pai ~ (⎈ |kind-pai:default) diff deployment.yaml replicaset.yaml
22c2
3< kind: Deployment
4---
5> kind: ReplicaSet
613d12
7< strategy: {}
824c23
9< status: {}
10---
11>
I removed the fields strategy as well as status from replicaset.yaml. While creating ReplicaSet file this way, give the deployment name suffix like replicaset instead of deployment. I haven’t done that in this example since I wanted to show what fields I exactly need to change.
ConfigMap
Even if there are more than one entry to be added in a config map, just add one and then add rest in manifest file directly so you can save time in adding one by one in command line. Verify first syntax wise correct using dry-run.
1kubectl create configmap <config map name> --from-literal key=value --dry-run
Save the deployment definition to a yaml file for future changes as well as reference
1kubectl create configmap <config map name> --from-literal key=value --dry-run -o yaml > configmap.yaml
Example:
1slashpai@pai ~ (⎈ |kind-pai:default) kubectl create configmap mongo-config --from-literal user_id=mongo --dry-run
2configmap/mongo created (dry run)
3slashpai@pai ~ (⎈ |kind-pai:default) kubectl create configmap mongo-config --from-literal user_id=mongo --dry-run -o yaml > configmap.yaml
1slashpai@pai ~ (⎈ |kind-pai:default) cat configmap.yaml
2apiVersion: v1
3data:
4 user_id: mongo
5kind: ConfigMap
6metadata:
7 creationTimestamp: null
8 name: mongo
You may want to move the data section below metadata since that’s where we place this normally.
Adding more entries in manifest file
Now you must have got an idea how to create manifest files for most used kubernetes objects. You can tweak like this for other objects not mentioned. The fields in manifest file created this way is not enough, if you have specific needs or need to add more fields.
Let’s see how we can add more fields in a pod definition file. For example, you want to inject an environment variable into a container from a ConfigMap. Since we know container related info is inside spec section of the pod, we can use kubectl explain pod.spec.containers to get the exact field. See how this is done below.
1slashpai@pai ~ (⎈ |kind-pai:default) kubectl explain pod.spec.containers|grep env
2 container's environment. If a variable cannot be resolved, the reference in
3 are expanded using the container's environment. If a variable cannot be
4 env <[]Object>
5 List of environment variables to set in the container. Cannot be updated.
6 envFrom <[]Object>
7 List of sources to populate environment variables in the container. The
I grepped for env, since I know field starts with env. If you don’t know the field, you would need to scroll down the explain output and figure this out.
From this I got to know it’s the envFrom field that we need to use configmap and it’s a list type (important to note the type). We can check the fields that comes under envFrom similar way like above. But if we are only interested to know the fields without it’s description, just add the recursive flag
1slashpai@pai ~ (⎈ |kind-pai:default) kubectl explain pod.spec.containers.envFrom --recursive
2KIND: Pod
3VERSION: v1
4
5RESOURCE: envFrom <[]Object>
6
7DESCRIPTION:
8 List of sources to populate environment variables in the container. The
9 keys defined within a source must be a C_IDENTIFIER. All invalid keys will
10 be reported as an event when the container is starting. When a key exists
11 in multiple sources, the value associated with the last source will take
12 precedence. Values defined by an Env with a duplicate key will take
13 precedence. Cannot be updated.
14
15 EnvFromSource represents the source of a set of ConfigMaps
16
17FIELDS:
18 configMapRef <Object>
19 name <string>
20 optional <boolean>
21 prefix <string>
22 secretRef <Object>
23 name <string>
24 optional <boolean>
25slashpai@pai ~ (⎈ |kind-pai:default)
That drilled down the config to use as given below in the spec section of pod. Note the type for envFrom, which we had figured out to be of list type.
1spec:
2 containers:
3 - name: mongo
4 image: mongo
5 envFrom:
6 - configMapRef:
7 name: mongo-config
Surely you can go to kubernetes documentation and get this info. But I found this is more easier since I don’t like leaving my terminal so often.
I hope this helps you create the manifest files with ease now. Thank you for reading this post.
comments powered by Disqus