DEV Community: Sid

Kubernetes - Scheduling containers

Sid — Tue, 08 Sep 2020 10:02:35 +0000

One-shot containers

There are 2 types of one-shot containers based on how they handle recovery in case of error, differentiation between these 2 approaches is from a CLI modifier called "--restart".

Value of this modifier as "OnFailure" will ensure resource created by kubectl run will be restarted if it does not exit in a clean way (Checked using exit return code).
Value of this modifier as "Never" will do nothing regardless of how resource / pod exits.

Scheduling containers

Modifier called "--schedule" to kubectl run command will allow us to supply cron expression and will schedule pods accordingly. One-shot container modifiers can also be used along with scheduling modifiers.
This is command for scheduling a container:

# Sample command
kubectl create cronjob <job-name> --schedule="<schedule>" --restart=OnFailure --image=<image-name> -- <command-to-container>
# E.g. Command
kubectl create cronjob test-cronjob --schedule="*/3 * * * *" --restart=OnFailure --image=alpine -- sleep 10

Example of container with restart on failure and schedule is a batch job that needs to work on batch of data on some frequency.

Command help params

I like commands that use intuitive, multi-level switches to provide help on that topic. Thankfully kubectl does follow that practice, it'll not only auto-complete keywords, on every level you can just provide "-h" switch display help on all available CLI options, their meaning and some good examples. I love it when developers put thought to make their CLIs really good and helpful, particularly when someone like myself (with least possible main memory) is using it! ;)

Shortcomings of Logs

It seems like logs command that kubectl supports just limits no. of pods that it can pull it's data from to just 8! It does make sense since it's internally making round trips to API service and anything over 8 (Magic number ;) ) seems to be harmful that API layer that's a center-piece of whole Kubernetes architecture.
As I had mentioned previously, logs command when run without a filter seems to latch onto a single pod (not even round-robin) so it feels like logs command in kubectl is good for say local development while work is in progress but not a great choice to run it in production.
My application of Kubenetes is for cloud and specifically on AWS as their offering - EKS (AWS Managed Kubernetes Cluster) so seems like I'll have to find this "logging" part really well while using EKS. (I still haven't looked at EKS myself but deep down every fibre of my body is telling me that AWS would have supported option to route all logs to CloudWatch logs out of box)
One option to manage logs that I learned from my Kubernetes training / course if called Stern.

Stern

Seems like a good tool, I gave it a try, it has all options normal logs has plus some more. I would encourage everyone to try this out for local usage.

Deleting Stuff

# Multiple resources can be deleted together
kubectl delete "<resource-type>/<resource-name>" "<resource-type>/<resource-name>"

Delete does not mean, delete right away! It'll still follow a wait time while pods move to "Terminating" state and then finally be killed off.

Phoof, this was a long post that I had anticipated ...

Kubernetes - First deployment

Sid — Tue, 08 Sep 2020 05:12:50 +0000

Deploying new stuff

Start a new pod using deployments as follows:

kubectl run "<deployment-name>" --image "<container-image>" "<commands-passed-on-to-container-image>"

This creates 3 resources - deployment, repliac sets and finally a pod / pods.

A deployment consists of one or more replica sets, replica sets consists of pods.
Deployment allows scaling, rolling updated and rollbacks. A replica set makes sure given number of identical pods are running, it also allows scaling.
Since deployment "manages" it's replica sets, configuration in deployment will override changes in replica set configuration made from CLI.

Watching logs for a running pod

# Logs for a deployment
kubectl logs "deploy/<deployment-name>"

# You can use common switches like tail and follow with this
kubectl logs "deploy/<deployment-name> --tail 1 -f"

Logs command can only pull logs from one pod, if you have multiple identical pods running, logs will stick to just one pod till that gets terminated.
You can also pull logs for a specific pod - using get pods to get pod ID, use that ID with logs command.

Scaling pods

kubectl scale "deploy/<deployment-name>" --replicas "<number>"

It'll scale no. of pods to new replicas number.

Deleting resource

kubectl delete "<resource-type>/<resource-id>"

Delete send SIGTERM to shut down pod gracefully, as soon as one pod is in "Terminating" state, replica set will start a new one to match total replicas configuration. Once grace period expired, Kubernetes will then kill container in "Terminating" state, this grace period is configurable to suite variety of application lifecycles.

Kubernetes - All things kubectl

Sid — Fri, 04 Sep 2020 09:33:36 +0000

First things first - how do we pronounce "kubectl" :) Based on what I heard right now, it's now (and officially) called as "Kube Control"

List Nodes

# Usual Output
kubectl get nodes

# Wide variant (provided more fields w.r.t. node like internal & external IP, OS Image, Kernel version and container runtime etc.
kubectl get nodes -o wide

# Machine friendly output
kubectl get nodes -o yaml
kubectl get nodes -o json

# Awesome node monitoring and all other node info, also lists all pods across all namespaces running on that node
kubectl describe node/<node-name-from-nodes-command>

kubectl describe basically works with all resources in format as follows

kubectl describe "<resource-kind>/<resource-name>"

Get Services

Get's all deployed services that someone can "talk" to

kubectl get svc

Namespaces

# Get all namespaces
kubectl get ns

Most commands can take -n or -A (for all namespaces) as a modifier to run command on

Get Pods

# Gets all pods across all namespaces
kubectl get pods -A

# Gets all pods in a specific namespace
kubectl get pods -n "<namespace-name>"

Kubernetes - Initiate Level 1

Sid — Fri, 04 Sep 2020 08:13:21 +0000

As one of the first things that I wanted to learn, I picked up Kubernetes. I have started taking a lesson in learning Kubernetes on Udemy Course and I'll use this space to document my learning as I progress through course:

There seem to be waaay too many Kubernetes Certified Distributions
Kubernetes is a container management system
What can Kubernetes do out of box:
- Spawn multiple container of an image
- Put internal / External ALB in front of these multiple containers
- Grow / shrink cluster
- Replace image with latest with rolling update
- Auto scaling - nodes and appliacations
- Scheduled / cron containers
- Batch mode
- Integrate third party services (service catalog)
- RBAC
- Automate complex tasks (operators)

Kubernetes Basic Architecture

Kubernetes master - also called by Control Plane. Includes API Server, Scheduler, etcd and Controller Manager. One of more master nodes can exist.

Kubelet - runs on Host Machines, controls local docker

Kube-proxy - Controls network, works with kubelet

CoreDNS - Naming service on master

Cloud Kubernes providers usually hide control plane and run it externally, all we get in return is API endpoint.

Interacting with Kubenetes

Only interact through API that supports CRUD operations.

Pods - Abstract around one or more containers. Lowest deployable unit in Kubernetes. Pods get IP address, not individual containers in a pod. Containers in a pod share localhost and can share volumes. Containers in pod are deployed together.

Not 100 days of code

Sid — Fri, 04 Sep 2020 04:58:36 +0000

If you're reading this, only god knows how did you land on my blog here but this is supposed to be my dev log of sort. Before you say anything, ... nope I'm not in "100 days of code" thing, I'm quite burned out already in just 15 years into IT and software engineering so I just don't have enough energy right now to code outside of my work for 100 days.

This weblog is just attempt to document what I'm learning as I progress through some of the new courses that I'm taking on Udemy to learn new stuff.

This way I would be able to just come back to this and find out important stuff like hacks / commands (if at all) that I can continue to use while I work in future!

Thanks for stopping by and off you go to reading something actually meaningful ...