In Kubernetes, one approach to spinning resources is using the command line. Another approach that is easier and well documented is creating YAML configuration files. YAML is a text format that enables the creation of configuration files. When you use YAML to define your Kubernetes, you have three advantages:
• You have the convenience of not being required to specify parameters at the command line
• It is easier to maintain YAML files because you can use a source control for change tracking
• The flexibility of YAML files enables the creation of complex structures which is not possible at the command line
When writing configuration files, there are several important points to have in mind:
• In your configuration definition always use the API version that has stability
• Use a version control to hold your files before placing them on your cluster. This will enable you to revert to a previous state if required. It will also help you easily re-create or restore a cluster when required
• Specify your configuration in YAML instead of JSON. Although the formats are interchangeable, YAML has a better user friendly structure
• When sensible, place objects that are related in a single file. This simplifies file management.
• Avoid unnecessary default values. This will lead to simple configurations and will minimize the possibility of errors.
The two types of structures you need to understand to create YAML configurations are lists and maps.
Maps allow you to create name-value pairs which are necessary when specifying configurations. Consider the YAML snippet shown below:
In the previous sample, the values v1 and Pod have been mapped to the apiVersion and Kind. With maps you are not limited to single name-value mapping because you can use nesting to create complex structures. To ensure your definitions are readable, use spaces instead of tabs.
Lists are just object sequences. In the example below, we have a list of indented items that begin with a dash.
- "Enroll for both"
Maps and lists can be combined in many ways to meet your needs. Consider the example shown below:
- name: front-end
- containerPort: 80
- name: rss-reader
- containerPort: 88
In the example shown above, there is a list of two containers. The containers have a list of ports. In the first line, we have specified the API version. On line 2, we indicate we are creating a pod but we can also create a deployment, job or service depending on our objective. Line 3 begins the meta-data which includes the pod name and label by which the pod will be identified by Kubernetes. Line 7 begins the specifications section where we include objects such as containers, volumes and other objects that form the pod. For a comprehensive list of the objects, you can include in your specification. To learn how to do that you can refer to this link . Create a file with the definition and save it as .yaml.
If we saved the file in the Documents folder, we can deploy it using the command below:
kubectl create -f /home/sammy/Documents/firstpod.yaml
The previous sections were concerned with demonstrating how you define and deploy a pod. The following sections will focus on demonstrating how to manage deployed pods.
The key-value pairs linked to objects are referred to as labels. Labels hold meaningful attributes for the user but not necessarily for the system. Labels are very useful for organizing and grouping related objects. A frequent use of labels is using a criteria to select pods that meet a certain criteria. The query format is shown below which is a very basic query.
kubectl get pods -l label_key=label_value
You can construct complex queries using several label values like in the example shown below:
kubectl get pods -l label_key1=label_value1,label_key2=label_value2
Labels are linked to objects at label creation or during changes. Labels are not required to be unique so they can be applied on several objects for grouping. Label selectors enable you to identify objects having the same label. Label selectors can be either set or equality selectors. The symbol = is used to specify equality while the symbol != is used to specify inequality in the equality selector. All the specified constraints need to be specified for a match. An example of an equality selector is shown below.
kubectl get pods -l app=nginx,deployer=distelli
The constraints that need to be satisfied in the previous query are pods having the specified key-value pairs. When the two constraints are satisfied, the pods will be returned otherwise the query will fail. In the example shown below, all but those pods that have the included key-value pair will be returned.
kubectl get pods -l app!=nginx
Set selectors enable objects to be queried on the basis of their inclusion or exclusion from a set. There are four different ways in which set selectors can be used. The in selector is used to return all objects having a specific label/value pair. Consider the query shown below:
get pods -l 'app in (nginx, test), deployer in (distelli)'
The previous command will return pods that have the key/value pairs app:nginx and app:test. The query will also return pods that have a key/value pair deployer:nginx.
The notin selector is used to return objects not having the passed labels and values. Consider the query below.
get pods -l 'app notin (nginx)'
In the query above, pods without the key-value app:nginx will be returned.
The !label is used to return pods without the passed label and without considering the value. An example query is shown below:
get pods -l '!app'
In this article, we introduced YAML as a format for specifying configuration files. We discussed the benefits of using YAML to specify configurations. We discussed key issues to have in mind when writing configuration files. We discussed how maps and lists are used to build YAML files. Finally, we discussed the different ways you can use labels to organize pods.