What makes a good K8s manifest

good-k8s-manifest.md

What makes a good K8s manifest

Aside from the required parts, the following is a list of fields that should be included in any deployment manifest. Followed by a layout of a deployment file

MetaData

• name - Make your name something that is easy to Identify what it is. you don’t need to include version information here as that will be elsewhere

• namespace - Specify a namespace, think of this as the default location you plan to deploy something to. This can always be overridden with kubectl -n <namespace> at a later time.

Spec

• replicas- if you want any level of redundancy make sure your replicas are > 1

• strategy.type - This refers to the update strategy. In most cases this can be ignored because the default is RollingUpdate which is a good choice.

Spec.template

• metadata.labels - make use of these for things that will remain fairly static through the life of a deployment. For example app=<appname> or tier=frontend . Anything you wish to use to categorize and locate your deployments will make sense here. These labels can/are use by service objects to connect pods to services.

• metadata.annotations - These are items that can be mutated at anytime in the life cycle of a deployment. Items that are good here are things that can be more dynamic and/or change regularly. Common uses are version information, git build IDs, misc metadata that other controllers will use to make decisions.

Containers

• imagePullPolicy - unless you have some explicit reason not to , use AlwaysPull . This will always try to pull an image. Docker caches layers so you won’t be pulling any data you don’t need. This just triggers a pull even if the image name has not changed.
• resources.requests - This specifies the available resources a container needs to be scheduled on a node. If successfully scheduled the specified resources will be guaranteed to the container.
• resources.limits - This specifies the resource limits of a container. This means that the container cannot use more than what is in the limit. In the case of cpu it will be limited to the percentage of cores, in the case of memory it will get OOM killed if it tries to allocate memory beyond the limit.
• readinessProbe - this is a container probe performed by the kubelet to determine if the pod is ready to receive traffic. If this fails kubernetes will stop sending traffic until the probe passes again.
• livenessProbe - this a container probe that will check if the container is functioning healthily. If this probe fails it will restart the container. Leverage this in a smart way do restart pods that are having issues.
• env - these are environment variables. As appropriate try to get as much of this in a config map as possible. If the data for this is in a config map you can reference the configmap as the value for you env vars.

ConfigMaps and Secrets

anything that would have traditionally been a config file should be loaded in as a configmap. Even a config file can be saved as a configmap and then mounted as a file inside the container. This allows you to update configmaps as changes occur rather than have to update a container image and redeploy.

If you have /any/ sensitive information, put it in a secret. A secret is basically the same thing as a configmap but it is encrypted so it cannot be read by anyone that does not have access. It is also encrypted in the etcd store. Secrets can be referenced very similarly to how configmaps are referenced.

Deployment

metadata

* name
* namespace

spec

* replicas
* strategy
	* type [“recreate”, or “RollingUpdate”] (rolling update is default)
	* maxUnavailable
	* maxSurge
		* /All existing Pods are killed before new ones are created when/
		* /The Deployment updates Pods in a rolling update fashion when .spec.strategy.type==RollingUpdate. You can specify maxUnavailable and maxSurge to control the rolling update process./
* template
	* metadata
		* labels
		( good label examples, appname, tier etc)
		* annotations
			* app version
			* build number 
			* any other useful item
	* spec
		* containers
			* name
			* image
			* imagePullPolicy
			* resources
				* requests
					* memory
					* cpu
				* limits
					* memory
					* cpu
			* readinessProbe
			* livenessProbe
			* env
				* environment variables
			* ports
				* containerPort: