Install Docker

# Add Docker’s official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg — dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Add the repository to Apt sources:
echo \
“deb [arch=$(dpkg — print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo “$VERSION_CODENAME”) stable” | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

sudo docker run hello-world

sudo service docker start
sudo docker run hello-world

Install Minikube

$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
$ sudo install minikube-linux-amd64 /usr/local/bin/minikube

$ minikube version

Install Kubectl

$ chmod +x kubectl
$ sudo mv kubectl /usr/local/bin/

$ kubectl version -o yaml

$ minikube start — driver=docker

minikube status

$ kubectl get nodes
$ kubectl cluster-info

$ kubectl create deployment nginx-web — image=nginx
$ kubectl expose deployment nginx-web — type NodePort — port=80
$ kubectl get deployment,pod,svc

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh

minikube addons list

$ minikube addons enable dashboard
$ minikube addons enable ingress

$ minikube dashboard

$ minikube stop
$ minikube start

$ minikube delete

sudo apt-get install virtualbox-guest-additions-iso

Source:

• How to Install Minikube on Ubuntu 22.04 Step-by-Step
• VirtualBox/GuestAdditions
• Installing Helm | Helm

Helm Basics

Packaging manager: win installer, apt, yum, npm

Chart is packages in helm world.

helm install apache bitnami/apache — namespace=web

helm upgrade apache bitnami/apache — namespace=web

helm rollback apache 1 — namespace=web

helm uninstall apache

Values.yaml file we can pass parameters to this template. It will be used to generate final yaml file.

Packages are stored in a chart repository.

Helm is written Go language that it is compiled language.

sudo usermod -aG sudo username

sudo usermod -aG wheel username

tar -zxvf helm-v3.0.0-linux-amd64.tar.gz

mv linux-amd64/helm/usr/local/bin/helm

Choco install kubernetes-helm

helm — help

helm repo list

helm repo add bitnami https://charts.bitnami.com/bitnami

helm repo list

helm repo remove bitnami

helm repo add bitnami https://charts.bitnami.com/bitnami

Search the repository:

helm search repo apache

helm repo update

helm search repo mysql

helm search repor mysql — versions this will list all chart versions

helm search repo database

helm search repo database — versions

Install a package:

kubectl get pods command will run first terminal. if it did not start minikube start

(Below Two commands — In a Different Shell/Commandline window/tab)

minikube ssh

docker images

We run this command in minikube

helm install mydb bitnami/mysql

helm install my-release oci://registry-1.docker.io/bitnamicharts/mysql

helm install mysqldb oci://registry-1.docker.io/bitnamicharts/mysql

Kubectl get pods -w — namespace default

echo Password : $(kubectl get secret — namespace default mydb-mysql -o jsonpath=”{.data. mysql-root-password}” | base64 — decode)

To connect to your database:

1. Run a pod that you can use as a client:

kubectl run mydb-mysql-client — rm — tty -i — restart=’Never’ — image docker.io/bitnami/mysql:8.0.26-debian-10-r31 — namespace default

— command — bash

2. To connect to primary service (read/write):

mysql -h mydb-mysql.default.svc.cluster. local -uroot -p my_database

Show databases;

Check the cluster:

kubectl get pods

minikube ssh

docker images

To check the installation status:

helm status mydb

Kubectl create ns teamtwo

Helm install — namespace teamtwo mydbsql bitnami/mysql

List & Unlist

Helm list

helm list — namespace teamtwo

helm uninstall mysqldb

kubectl get pods

helm uninstall mysqldb -n teamtwo

Helm install mysqldb bitnami/mysql — values /Users/bharaththippireddy/Documents/helm/values.yaml

Values.yaml file contains below codes

Auth:

rootPassword:””

kubectl run mydb-mysql-client — rm — tty -i — restart=’Never’ — image docker.io/bitnami/mysql:8.0.26-debian-10-r31 — namespace default — command — bash

mysql -h mydb-mysql.default.svc.cluster.local uroot -p my_database

After login

Show tables;

Create database test;

helm install mysqldb bitnami/mysql — set auth.rootPassword

— — — — — — — — — — — — — — — — — — — — — —

helm repo update

helm list

helm status mysqldb

helm install mysqldb bitnami/mysql — values /Users/bharaththippireddy/Documents/helm/values.yaml

helm upgrade mysqldb bitnami/mysql — reuse-values

To Upgrade:

ROOT_PASSWORD=$(kubectl get secret — namespace default mydb-mysql -o jsonpath=”{.data.mysql-root-password}” | base64 — decode)

helm upgrade — namespace default mysql-release bitnami/mysql — set auth.rootPassword=$ROOT_PASSWORD

— — — -

helm uninstall mysql-release

— — — — — — — — — — — — — — — — — — — — — — — — — — — —

Kubectl get secrets

After upgrade secret will have new version. After uninstall secrets will be deleted.

helm uninstall mysqldb — keep-history

Helm ls will show nothing

Kubectl get secrets will show default secret

OLD:

tomcatPassword: test

service:

type: NodePort

nodePort: 30007

NEW:

tomcatPassword: test

service:

type: NodePort

nodePorts:

http: 30007

Advanced Commands

helm install mysqldb bitnami/mysql — set auth.rootPassword=Password

helm — dry-run

it will not create any in the cluster

helm install mysqldb bitnami/mysql — values /Users/bharaththippireddy/Documents/helm/values.yaml — dry-run

Dry-run is using for debugging. Generates the output manifest and sends it to the Kubernetes API for verification.

From <https://www.squadcast.com/blog/helm-dry-run>

Dry-run is a new feature that we intend to implement in the api-server. The goal is to be able to send requests to modifying endpoints, and see if the request would have succeeded (admission chain, validation, merge conflicts, …) and/or what would have happened without having it actually happen.

From <https://www.google.com/search?q=helm+dry+run&rlz=1C1GCEU_enTR1056TR1056&oq=helm+dr&gs_lcrp=EgZjaHJvbWUqBwgAEAAYgAQyBwgAEAAYgAQyCQgBEEUYORiABDIHCAIQABiABDINCAMQLhivARjHARiABDIHCAQQABiABDIHCAUQABiABDIHCAYQABiABDIHCAcQABiABDIHCAgQABiABDIHCAkQABiABKgCALACAA&sourceid=chrome&ie=UTF-8>

When we execute it will show many more rows of code kubernetes details.

There are 3 section. First is release information.

install never happens when we use dry-run

Second section is key section.

Third section is release notes. We can look at that everything is ok

Dry-run can be used installation and upgrade.

Helm template

helm template mysqldb bitnami/mysql — values /Users/bharaththippireddy/Documents/helm/values.yaml

It will again generate template we can see at command screen.

It never communicate kubernetes API server

Sources:

udemy course helm-kubernetes-packaging-manager-for-developers-and-devops/

helm.sh/docs

Bitnami.com/stacks/helm

https://bitnami.com/stack/mysql/helm

https://github.com/bitnami/charts/tree/main/bitnami/mysql/#installing-the-chart

https://github.com/bitnami/charts/blob/main/bitnami/mysql/templates/NOTES.txt

https://www.linkedin.com/posts/mmumshad_kodekloud-devops-kubernetes-activity-7151550895804022784-xh0r

https://phoenixnap.com/kb/helm-commands-cheat-sheet

https://cheat-sheets.nicwortel.nl/helm-cheat-sheet.pdf

Build

# Build OCI images (default for podman)
$ podman build — format=oci

# Build Docker images instead
$ podman build — format=docker

# Similarly in ‘docker buildx’
$ docker buildx build — output type=oci
$ docker buildx build — output type=docker

Runtime

Container runtimes are software that facilitate the containers to run. According to the official GitHub repo “Containerd is an industry-standard container runtime with an emphasis on simplicity and robustness and portability.” “Containerd is one of the most extensible, well-architected and optimal runtimes focused on simplicity that is meant to be embedded into a larger ecosystem.” Containerd does not build images; it just consumes them. For a clearer picture, check out the scope of Containerd in the official Github repo.

History

The Containerd is born out of the monolithic Docker, and is included in Docker, from Docker 1.11. Kubernetes supports the use of Containerd as a runtime from Kubernetes 1.10 and above

High-level container runtime: containerd / CRI-O
Responsibilities:

-pull container images from registries

-manage images on disk

-launch a lower-level runtime to run container processes

containerd: born from parts of the original Docker project.
-has its own CLI (ctr) in addition to crictl.
-config: /etc/containerd

CRI-O:

-created by RedHat
-CRI-O stands for “Container Runtime Interface — OpenShift”.
-depend on other RedHat container tools: podman, buildah, skopeo.
-no separate CLI.

-config files:
/etc/containers
/etc/crio/crio.conf
/etc/containers/registries.conf
- images stored in /var/lib/containers

Low-level container runtime: runc, crun
-runc: the “reference implementation” of OCI. Written in Go. Both containerd and CRI-O use runc by default.
-runsc: gVisor from Google, which creates containers that have their own kernel. Also compliant with OCI spec.
-crun: written in C.

Most likely you do not need to use runc directly, but you can get more info about the running containers:

$ runc list

$ ls /run/runc

$ cat /run/runc/$NAME/state.json

containerd

# containerd view logs
$ journalctl -u containerd

ctr vs crictl:

-ctr: containerd CLI, not related to k8s.
-crictl: CRI Compatible container runtime command line interface, related to k8s.

crictl image = ctr -n=k8s.io images ls

kind load uses “ctr”, “ — namespace=k8s.io”, “images”, “import”, “ — digests”, “ — snapshotter=”+snapshotter, “-”

Registry

Config: /etc/containerd/config.toml

version = 2

[plugins.”io.containerd.grpc.v1.cri”.registry]
config_path = “/etc/containerd/certs.d”

Per registry config:

$ tree /etc/containerd/certs.d
/etc/containerd/certs.d
docker.io
hosts.toml

Versus

buildah run vs podman run

-buildah run command emulates the RUN command in a Dockerfile
-podman run command emulates the docker run command in functionality.

podman vs docker
-Podman containers are rootless; docker supports both root and rootless mode.
Podman uses systemd to make updates and keep containers running in the background. By integrating systemd and Podman,

you can generate control units for your containers and run them with systemd automatically enabled.
-Docker is all-in-one; podman work with buildah, skopeo, etc.

Basic Demo Commands:

Pull image

# ctr image pull docker.io/library/hello-world

# ctr images pull — all-platforms docker.io/library/nginx:alpine

# sudo ctr images pull docker.io/library/nginx:latest

List images

# ctr image ls

# ctr image ls -q

# sudo ctr images list

Run container

#ctr container create docker.io/library/hello-world:latest demo

This would create a container with container id, ‘demo’, based on the image that we pulled.

#sudo ctr run — rm -t docker.io/library/nginx:latest my-nginx-container

— rm removes the container when it exits.

-t allocates a TTY for an interactive session.

Unlike Docker, we need to use the full path with the object every time we use a container image.

Also, the image needs to be pulled before being able to run a container.

Run a Container in the Background (Daemon):

#sudo ctr run — rm -d docker.io/library/nginx:latest my-nginx-container

-d runs the container as a detached, background process.

List the containers or tasks:

# ctr container list

You can see the demo container listed. You can even use -q to get just the container names.

# sudo ctr containers list

# sudo ctr task list

Delete the image

# ctr image remove docker.io/library/hello-world:latest

# ctr container list

Your container would still be running. This is because containerd works on references, and in this case, the image is no longer being referenced as an image but it is still being referenced by the container (as a snapshot), so it wouldn’t be deleted as long as it’s being referenced.

Delete the container

# ctr container remove demo

Execute a Command in a Running Container:

# sudo ctr exec -t my-nginx-container sh

sh can be replaced with the desired command.

Stop a Container:

# sudo ctr task kill my-nginx-container

Remove a Container:

# sudo ctr task delete my-nginx-container

Inspect a Container or Task:

# sudo ctr task inspect my-nginx-container

Logs of a Container:

# sudo ctr task logs my-nginx-container

List Snapshots (Checkpoints):

# sudo ctr snapshots list

Create a Snapshot:

# sudo ctr snapshot create my-snapshot my-nginx-container

Delete a Snapshot:

# sudo ctr snapshot delete my-snapshot

List Checkpoints:

# sudo ctr checkpoints list

Create a Checkpoint:

# sudo ctr checkpoint create my-checkpoint my-nginx-container

Delete a Checkpoint:

# sudo ctr checkpoint delete my-checkpoint

List Active Tasks:

# sudo ctr tasks ps

Prune Containers and Images:

# sudo ctr containers prune and sudo ctr images prune

What is the difference between crictl % ctr?

crictl and ctr are both command-line tools for managing containers in Kubernetes. However, they have different purposes and use cases.

crictl is a tool for managing containers through the Container Runtime Interface (CRI). CRI is a standard interface that allows Kubernetes to communicate with different container runtimes, such as containerd and Docker. crictl can be used to perform a variety of tasks, such as:

• Listing all containers
• Inspecting a container
• Running a container
• Stopping a container
• Removing a container
• Pulling an image
• Executing a command in a container

ctr is a tool for managing containers directly through the containerd runtime. ctr can be used to perform a variety of tasks, such as:

• Listing all images
• Pulling an image
• Running a container
• Executing a command in a container
• Removing an image

Which tool should you use?

If managing containers in Kubernetes, may use crictl. crictl is the recommended tool for interacting with containerd through the CRI.

If developing or debugging containerd, or need to manage containers directly, may use ctr. ctr provides more features than crictl, such as the ability to list and remove images.

# ctr images
NAME:
ctr images — manage images

USAGE:
ctr images command [command options] [arguments…]

COMMANDS:
check check existing images to ensure all content is available locally
export export images
import import images
list, ls list images known to containerd
mount mount an image to a target path
unmount unmount the image from the target
pull pull an image from a remote
push push an image to a remote
delete, del, remove, rm remove one or more images by reference
tag tag an image
label set and clear labels for an image
convert convert an image

Viewing Images
# ctr images ls

Downloading an Image
Containerd supports OCI-standard images. Therefore, you can directly use Docker official images or Dockerfile images.

# ctr images pull — all-platforms docker.io/library/nginx:alpine
# ctr images pull docker.io/library/nginx:latest
# uname -a

Image Mounting

# ctr images mount docker.io/library/nginx:alpine /mnt
sha256:af2fcce448e2e4451a5f4796a9bf9cb5c9b5f88e0d6d10029cada42fb9d268ac
/mnt
[root@localhost ~]# ls /mnt

# umount /mnt

Exporting Images
# ctr i export — all-platforms nginx.img docker.io/library/nginx:alpine

Image Deletion
# ctr image rm docker.io/library/nginx:alpine
# ctr images ls

Importing Images
# ctr images import nginx.img

Modifying an Image Tag

# ctr images tag docker.io/library/nginx:alpine nginx:alpine
# ctr images ls
# ctr images check

Containerd container management
#ctr — help

# ctr container — help
NAME:
ctr containers — manage containers

USAGE:
ctr containers command [command options] [arguments…]

COMMANDS:
create create container
delete, del, remove, rm delete one or more existing containers
info get info about a container
list, ls list containers
label set and clear labels for a container
checkpoint checkpoint a container
restore restore a container from checkpoint

Viewing Containers
# ctr container ls
# ctr c ls

Viewing Tasks
# ctr task ls
# ctr t ls

Creating a Static Container
# ctr c create docker.io/library/nginx:alpine nginx1
# ctr container ls

Entering the Container
# ctr task exec — exec-id 1 nginx1 /bin/sh

Directly running a dynamic container
# ctr run -d — net-host docker.io/library/nginx:alpine nginx2
# ctr container ls
# ctr tasks ls

Pausing Containers

# ctr tasks pause nginx2
# ctr tasks ls

Restoring a Container
# ctr tasks resume nginx2
# ctr tasks ls

Stop Container
# ctr tasks — help
# ctr tasks kill nginx2
# ctr tasks ls

Deleting a Container
# ctr tasks delete nginx2
# ctr container ls
# ctr container delete nginx2

ctr download image
# ctr images pull — platform linux/amd64 docker.io/library/nginx:latest

Uploading an Image to the CTR
# ctr images tag docker.io/library/nginx:latest harbor.kubemsb.com/library/nginx:latest
# ctr images push — platform linux/amd64 — plain-http -u admin:密码 harbor.kubemsb.com/library/nginx:latest

Source:

https://github.com/containerd/containerd/blob/main/docs/getting-started.md

https://www.hackingnote.com/en/cheatsheets/containers/

https://github.com/containers

https://sweetcode.io/getting-started-with-containerd/

https://sweetcode.io/tag/cloud-native-computing-foundation/

https://cloud.tencent.com/developer/article/2308391

https://containerd.io

https://opencontainers.github.io/org/introduction

https://developers.redhat.com/blog/2018/02/22/container-terminology-practical-introduction/

https://github.com/containerd/containerd

https://www.scribd.com/document/688368691/containerd-commands

https://www.mankier.com/8/ctr

https://www.devopsschool.com/blog/what-is-difference-between-crictl-and-ctr/#:~:text=Which%20tool%20should%20you%20use,directly%2C%20you%20can%20use%20ctr.

-o <file> # — output: write to file
-u user:pass # — user: Authentication
-v # — verbose
-vv # Even more verbose
-s # — silent: don’t show progress meter or errors
-S # — show-error: when used with — silent (-sS), show errors but no progress meter

-i # — include: Include the HTTP-header in the output
-I # — head: headers only

SSL

— cacert <file>
 — capath <dir>
-E, — cert <cert> # — cert: Client cert file
 — cert-type # der/pem/eng
-k, — insecure # for self-signed certs

Request

-X POST # — request
-L # follow link if page redirects
-F # — form: HTTP POST data for multipart/form-data

Data

-d ‘data’ # — data: HTTP post data, URL encoded (eg, status=”Hello”)
-d @file # — data via file
-G # — get: send -d data via get

Header

-A <str> # — user-agent
-b name=val # — cookie
-b FILE # — cookie
-H “X-Foo: y” # — header
 — compressed # use deflate/gzip

# Post data:
curl -d password=x http://x.com/y
# Auth/data:
curl -u user:pass -d status=”Hello” http://abc.com/statuses/update.xml
# multipart file upload
curl -v — include — form key1=value1 — form upload=@localfilename URL

# multipart form: send data from text field and upload file
curl -F person=anonymous -F secret=@file.txt http://abc.com/submit.cgi
# Use Curl to Check if a remote resource is available
# details: https://matthewsetter.com/check-if-file-is-available-with-curl/
curl -o /dev/null — silent -Iw “%{http_code}” https://example.com/my.remote.tarball.gz

Resource

https://devhints.io/curl

https://everything.curl.dev/usingcurl

K9s

K9s is a terminal based UI to interact with Kubernetes clusters. This product is to make easier to navigate, observe and manage deployed applications. K9s continually watches Kubernetes for changes and offers subsequent commands to interact with observed resources.

1. Get info about K9s runtime (logs, configs, locations for config, screen dumps, etc..)
   k9s info

2. Run K9s in a given namespace.
k9s -n mycoolns

3. Run K9s and launch in pod view via the pod command.
k9s -c pod

4. Start K9s in a non default KubeConfig context
k9s -- context coolCtx

5. Start K9s in readonly mode — with all modification commands disabled
k9s -- readonly

6. Use default kubeconfig
$ k9s

7. Use non-default kubeconfig
$ k9s — kubeconfig /path/to/kubeconfig

Check more from outside of k9s:

$ kubectl top nodes
$ kubectl top pods

Metrics Server

Metrics Server is a scalable, efficient source of container resource metrics for Kubernetes pipelines.

Metrics Server collects resource metrics from Kubelets and exposes them in Kubernetes apiserver through Metrics API for use by Horizontal Pod Autoscaler and Vertical Pod Autoscaler. Metrics API can also be accessed by kubectl top

In such cases metrics are able to collect from Kubelet /metrics/resource endpoint directly.

Metrics Server offers:

• A single deployment that works on most clusters For details please go to Requirements page.
• Fast autoscaling, collecting metrics every 15 seconds.
• Resource efficiency, using 1 mili core of CPU and 2 MB of memory for each node in a cluster.
• Scalable support up to 5,000 node clusters.

This article is going to improve.

Thanks for reading.

Source:

• K9s - Manage Your Kubernetes Clusters In Style
• Commands

• k9s Cheatsheet
• Checking Kubernetes pod CPU and memory - Octopus Deploy
• GitHub - kubernetes-sigs/metrics-server: Scalable and efficient source of container resource metrics for Kubernetes built-in autoscaling pipelines.
• GitHub - kubernetes-sigs/metrics-server: Scalable and efficient source of container resource metrics for Kubernetes built-in autoscaling pipelines.