Theory on Adur

Basic Kubernetes Commands

Thu, 29 Oct 2020 00:00:00 +0000

This post provides an overview of the basic kubectl CLI commands that can be applied to Kubernetes objects. Some examples of Kubernetes objects include Pods, ReplicaSets, Deployments, Namespaces, etc.

Namespaces

Namespaces are used in Kubernetes to organize cluster objects. Essentially, a namespace represents a folder containing a set of objects. By default, kubectl interacts with the default namespace. To use a different namespace, the --namespace flag is required, for example --namespace=example. To interact with all namespaces, use the --all-namespaces flag ¹.

Contexts

If you want to change the default namespace permanently, you can use a context. When used, it is recorded in the kubectl configuration file, stored at HOME/.kube/config. To create a context with a new default namespace name, run ¹:

1

kubectl config set-context my-context --namespace=nuevonamespacepordefecto

1

kubectl config use-context my-context

Kubernetes API objects

Every Kubernetes object is represented by a RESTful resource and exists at a unique HTTP path in the Kubernetes API. Resources are represented as JSON or YAML files. Through the kubectl command, you can access these objects. For example, using kubectl get you can access any resource in the default namespace ¹:

1

kubectl get <resource-name>

To get a more specific resource:

1

kubectl get <resource-name> <object-name>

To get more information about the object in JSON or YAML format, you can add the -o json or -o yaml flags respectively. This output is not very human-readable.

Another option to get human-readable details about an object is to use the kubectl describe command:

1

kubectl describe <resource-name> <object-name>

Creating, updating, or deleting Kubernetes objects

As mentioned earlier, Kubernetes objects or resources are represented by JSON or YAML files. To create, update, or delete these objects, such files are used. For example, to create or update an object stored in ejemplo.yaml, run:

1

kubectl apply -f ejemplo.yaml

If you prefer to make interactive edits instead of modifying the local file, you can use the kubectl edit command to download the latest version and launch an editor. After saving the file, it will be uploaded and automatically updated.

1

kubectl edit <resource-name> <object-name>

The kubectl apply command also saves the version history of configuration files. You can access these records using the edit-last-applied, set-last-applied, and view-last-applied options.

1

kubectl apply -f myobj.yaml view-last-applied

To delete an object, simply run:

1

kubectl delete -f ejemplo.yaml

Debugging

kubectl also has a set of commands for debugging your containers. To view the logs of a running container, run:

1

kubectl logs <pod-name>

If there are multiple containers in the pod, you can choose the container to inspect with the -c flag.

By default, kubectl logs lists the current logs and exits. If you want to continuously stream the logs to the terminal instead, you can add the -f (follow) flag to the command line.

You can also use the exec command to run a command in a running container:

1

kubectl exec -it <pod-name> -- bash

This will provide an interactive console inside the running container for more detailed debugging.

O’Reilly, Kubernetes: Up and Running ↩︎ ↩︎ ↩︎

Basic Kubernetes Objects

Thu, 29 Oct 2020 00:00:00 +0000

This post provides a description of the basic Kubernetes objects. Some examples of Kubernetes objects include Pods, ReplicaSets, Deployments, Namespaces, etc.

Basic objects

According to the Kubernetes documentation, Kubernetes objects are persistent entities. Kubernetes uses these entities to represent the state of the cluster. Each Kubernetes object is represented by a RESTful resource and exists at a unique HTTP path. Specifically, objects can describe ¹:

Which containerized applications are running (and on which nodes).
The resources available to those applications.
The behavioral policies for those applications, such as restart policies, upgrades, and fault tolerance.

Almost all Kubernetes objects include two fields that configure them: the spec or desired state of the object specification, and the status or actual/current state of the object. In the spec section, the intent or desired state of the object is declared. The control plane is responsible for attempting to match the actual state of the object with the desired state.

To create an object, the Kubernetes API must receive the object information in JSON format. Most of the time, the information is sent through kubectl in a .yaml file that will be converted to JSON format. An example of a .yaml file is as follows ¹:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
 name: nginx-deployment
spec:
 selector:
 matchLabels:
 app: nginx
 replicas: 2 # tells deployment to run 2 pods matching the template
 template:
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - name: nginx
 image: nginx:1.14.2
 ports:
 - containerPort: 80

Required fields

The following mandatory fields must be set to create an object ¹:

apiVersion: which version of the Kubernetes API is being used to create the object.
kind: what type of object you want to create.
metadata: data that serves to uniquely identify the object, including a name, a UID, and an optional namespace.
spec: the desired state for the object.

Labels

Labels are key-value pairs attached to Kubernetes objects. They are used to organize and select subsets of objects based on predefined requirements. Many objects can share the same label, so labels do not provide uniqueness to objects ².

For example, to add the label color=green to a Pod called plant, you can run the following ³:

1

kubectl label pods planta color=verde

The above command will not overwrite an existing label, so you need to use the --overwrite flag. Or if you want to remove the color label, use the following command:

1

kubectl label pods bar color -

Label selectors

Controllers use label selectors to select a subset of objects. Kubernetes supports two types of selectors ⁴:

Equality-based selectors

Allow filtering objects based on label keys and values. Matching is achieved using the operators:

Equals = or == (there is no difference between the operators)
Not equals !=

Set-based selectors

Allow filtering objects based on a set of values. You can use in, notin operators for label values, and the exists operator for label keys.

Object types

Pods

A pod is the smallest scheduling unit in Kubernetes. It is a logical collection of one or more containers that ²:

Are scheduled on the same host.
Share the same network namespace, and therefore share a single IP address assigned to the Pod.
Have access to mount the same external storage (volumes).

Pods are ephemeral in nature and do not have self-healing capabilities. That is why controllers are used to manage Pod replication, fault tolerance, self-healing, etc. Some of these controllers include Deployments, ReplicaSets, etc.