Kubernetes Basic Concepts

[anitsh]

Kubernetes Basic Concepts

[anitsh]

Most Used Commands

kubectl get <resource> --output wide List all information about the select resource type.
Common resources include:

• Pods (kubectl get pods)
• Namespaces (kubectl get ns)
• Nodes (kubectl get node)
• Deployments (kubectl get deploy)
• Service (kubectl get svc)
• ReplicaSets (kubectl get rs)

Call resources using singular (pod), plural (pods),or with shortcuts.
Get pod by namespace: -n, --namespace
Wait for a resource to finish: -w, --watch
Query multiple resources (comma-separated values): kubectl get rs, services -o wide

kubectl create --filename ./pod.yaml
Some resources require a name parameter. A small list of resources you can create include:

• Services (svc)
• Cronjobs (cj)
• Deployments (deploy)
• Quotas (quota)
  See required parameters: kubectl create cronjobs --help

kubectl edit <resource-type>/<name> Edit resources in a cluster.
The default editor opens unless KUBE_EDITOR is specificed:
KUBE_EDITOR="nano"kubectl edit \svc/container-registry

kubectl delete Remove one more our resources by name, label, or by filename. If you want to delete pods by label in mass you have to describe the pod and gather the app=”name” from the label section. This makes it easier to cycle multiple containers at once. Add --grace-period=5 to give yourself a few seconds to cancel before deleting:kubectl delete pod foo --grace-period=5`

kubectl edit <resource-type>/<name> Edit resources in a cluster.
The default editor opens unless KUBE_EDITOR is specificed:KUBE_EDITOR="nano"kubectl edit \svc/container-registry

kubectl describe <resource-type> <name> Show details of a resource.
Often used to describe a pod or node for errors in events, or whether resources are too limited to use.
A few common examples :
kubectl describe pods/nginx
kubectl describe nodes container.proj
kubectl describe pods -l name=myLabel

kubectl logs [-f] [-c] <resource-name> [<pod-name>] View logs of a container.
Helpful when an application is dead within a pod but the pod and containers are shown as active.
Follow a log as it is created: -f, --follow
Get logs from a specific container: -c, --container
kubectl logs -f -c ruby-app web-1

kubectl apply --file ./<filename> Apply configurations from files for resources within the cluster.
Use apply to add, update, or delete fields:
kubectl apply -f ./pod.json
cat pod.json | kubectl apply -f -

kubectl exec is the ability to execute into a container that is having an issue but logging and debugging an app hasn’t provided any answers.

kubectl cp <source> <destination> Copy files and directories to and from containers.
The tar binary must be in the container. This can also be used to pull or restore backups in an emergency. File location must be specified.
Copy a file from a local machine to a container: kubectl cp /tmp/cmd.txt charts/chart-884c-dmcfv:/tmp/cmd.txt
Copy file from container to local machine: kubectl cp charts/chart-884c-dmcfv:/tmp/cmd.txt /tmp/cmd.txt

[anitsh]

• TODO: Examples of Deployment and Service templates

[anitsh]

ReplicationController

A ReplicationController is responsible for managing the pod lifecycle and ensuring that the specified number of pods required are running at any given time.

A ReplicationController is responsible for managing the pod lifecycle and ensuring that the specified number of pods required are running at any given time. On the other hand, it is not responsible for the advanced cluster capabilities like performing auto-scaling, readiness and liveliness probes, and other advanced replication capabilities. Other components within the Kubernetes cluster better perform those capabilities.

In short, the ReplicationController has limited responsibility and gets typically used for specific implementations that do not require complex logic to attain certain requirements (for example, ensuring that the desired number of pods always matches the specified number). If there are more than the desired number, the ReplicationController removes the excess ones and ensures the same number of pods exist even in the event of node failure or pod termination.

https://opensource.com/article/21/11/kubernetes-replicationcontroller