kube(cuttle)

Athavan Kanapuli — Mon, 03 Feb 2020 02:32:01 +0000

Kubectl

Kubernetes is actually a one big API server and kubectl is the command-line client tool to manage Kubernetes clusters. Kubectl is also the new SSH for Kubernetes. Kubectl reads the cluster context from the config file present inside $HOME/kube directory.

Here is Hightower's word on kubectl,

Syntax structure

Kubectl has the following syntax,

Kubectl [operation] [resource] [name] [options]

operations are the tasks that you want to perform such as create, get, describe, delete, apply -f, exec -it

resource is the Kubernetes resource kinds like deployment, pods, connfigmap, daemonset etc.

name specifies the name of the resource such as POD name, deployment name etc.

options are the various choices available for the operations and the resources. Some of the common options are
* -o yaml - outputs in yaml format
* -o json - outputs in json format
* --watch
* --show-labels
* --namespace

How Kubectl works?

kubectl works on REST apis. Whenever a command is entered using kubectl, it's translated into a REST API call and hits the Kubernetes API server. Now based on the kubectl command, the API server either refers kubelet or the etcd database to retrieve or modify the data.

Get documentation using Kubectl

Kubernetes has a lot of resources and custom resource definitions. Kubectl has a wonderful feature to read all the documentation about these resources from the command line. It's pretty useful while writing the Kubernetes manifest yamls. For example, to view the options of the Pod resource, just run kubectl explain pod

The explain command also works to explain any inner field of a resource. For example, to know about the spec of a POD resource, just call the explain API with dot notation like kubectl explain pod.spec

kubectl - an alternative to SSH for containers

The kubectl exec is a valuable command for those who are working with the pods. It helps to get into the containers and allows us to execute commands.

Say, for example when we run the exec command to a running nginx POD, the following happens,

From the above image, the following can be noted,

A GET request is called to fetch the POD nginx
A POST request to the exec subresource of the POD
Finally, the server responds with the Response status 101 and switches to SPDY protocol to serve the content. Now technically we've logged-in to a pod and can run any commands.

kubectl - For Local debugging of the remote services

One of the top features of kubectl is the port-forward command. This allows forwarding one or more local ports to the remote service/pod running in the cluster and allows debugging of a remote service locally.

The following is an example where we port forward the local 8080 port to the remote 80 port of an nginx POD and we can access the remote nginx server using localhost:8080 for the terminal.

Common Useful kubectl commands

apply - kubectl apply -f FILENAME.yaml will create/apply all configurations specified in the file. apply also takes input from STDIN
annotate - kubectl annotate (-f FILENAME.yaml | RESOURCE NAME) KEY1=VAL1 KEY2=VAL2. This adds or updates annotations on one or more resources.
delete - kubectl delete (-f FILENAME | RESOURCE NAME) . This deletes the specified resources from the cluster
describe - kubectl describe RESOURCE NAME displays all the detailed state of the specified resource.
diff - kubectl diff FILENAME [flags] shows the diff between resources specified in the file against the live server configurations.
edit - kubectl edit ( FILENAME | RESOURCE NAME) edits or updates the resources specified. This helps to dynamically change the server resources.
get - kubectl get RESOURCE NAME retrieves the specified resource information from the server.
logs - kubectl logs -f RESOURCE NAME. This is an equivalent of tail -f. This tails the logs of a resource directly from your terminal

The complete reference of kubectl commands with examples can be found in the kubectl reference document.

Thanks for Reading ! See you soon again with another post :)

What are Kubernetes Pods Anyway?

Athavan Kanapuli — Thu, 23 Jan 2020 01:27:18 +0000

What is a Pod?

A Pod is a colocated group of containers and represents the very basic unit in Kubernetes. By this, we are not implying that a pod always contains more than a container. It's usual for pods to have a single container most of the time.

Why do we need a Pod?

Why would we run multiple containers together? Why can't we run a single container that does all our jobs? Let's try to answer these.

Generally, containers are designed to run a single process. It doesn't have an init system which manages all processes. So if we run multiple processes inside a container, it is our responsibility to keep all those processes running, manage their logs, handle all SIGNALS and so on. Truth be told, this is a pain. So it is always recommended to run a single process inside a container. Now it's obvious that we need some higher-level construct which helps to bind containers together and manage them as a single unit.

A Pod of containers allows multiple processes to be tied together and provide them with the same environment as if they were all running in the same container.

What's shared inside a Pod?

All containers in a pod share the same Linux namespaces. They are in the same Network and UTS namespaces. Because of this, containers within a pod shares the same IP address and hostname. Similarly, all containers run under the same IPC namespace and can communicate themselves through IPC.

What's different inside a Pod?

Each container in a pod has it's own PID namespace. So when you run ps aux inside a container, you see only the container's own processes.
When we speak about the filesystem, they mostly come from the container image. Hence the file system of each container inside the Pod is fully isolated. Here is a note, you can still have a shared volume for all containers in a pod using Kubernetes Volumes

Pod's Network

Containers inside the pod share the same IP and port space. They all are in the same loopback interface and a container can talk to another container in a pod using localhost. Since the port space is shared, processes running in two containers cannot bind to the same port inside a Pod. Containers of different pods can never run into such port conflicts.
All pods in a Kubernetes cluster stay in a single flat, network space. Hence any pod can communicate with any other pod with the pod IP. There are no NAT gateways required for Pod-to-Pod communication.

The Kubernetes documentation on Pods provides the most complete explanation of pods and I would recommend to read it as it's a better and more correct explanation than I could write.

DEV Community: Athavan Kanapuli