DEV Community: Yasir Rehman

Comprehensive Guide to 50+ Kubernetes Resources

Yasir Rehman — Mon, 20 Jan 2025 21:56:08 +0000

Kubernetes is a powerful container orchestration platform that enables easy deployment, management, and scaling of applications. At the heart of Kubernetes are its resources—the fundamental building blocks that define and manage the behavior of your applications, networking, and storage.

Why are they important?

- Foundation of Kubernetes operations: Every Kubernetes action involves resources, making them essential for mastering the platform.
- Customizable and extensible: These resources can be tailored to meet your application's unique requirements, ensuring flexibility and scalability.
- Interconnected system: Understanding how these resources interact helps you design robust and reliable systems in Kubernetes.

This article provides a clear overview of each resource, including:
✅ Resource Name
✅ Short Names
✅ API Version
✅ Namespaced
✅ A brief explanation of what each resource does!
Find an easy-to-read document on my LinkedIn post about "Comprehensive Guide to 50+ Kubernetes Resources".

1. APIServices

Name: APIService
API Version: apiregistration.k8s.io/v1
Name-spaced: No (Cluster-scoped)
Explanation: Enables custom resource definitions to be served over HTTPS by registering them with the API server.

2. CertificateSigningRequests

Name: CertificateSigningRequest (csr)
API Version: certificates.k8s.io/v1
Name-spaced: Yes
Explanation: Requests a signed certificate from a Certificate Authority within the Kubernetes cluster.

3. ClusterRoleBindings

Name: ClusterRoleBinding
API Version: rbac.authorization.k8s.io/v1
Name-spaced: No (Cluster-scoped)
Explanation: Grants permissions to users, service accounts, or other groups at the cluster level by binding them to a ClusterRole.

4. ClusterRoles

Name: ClusterRole
API Version: rbac.authorization.k8s.io/v1
Name-spaced: No (Cluster-scoped)
Explanation: Defines a set of permissions that can be granted to users or groups at the cluster level.

5. ComponentStatuses

Name: ComponentStatus (cs)
API Version: core/v1
Name-spaced: No (Cluster-scoped)
Explanation: Provides information about the health and status of core Kubernetes components.

6. ConfigMaps

Name: ConfigMap (cm)
API Version: v1
Name-spaced: Yes
Explanation: Stores non-sensitive key-value data that can be mounted as environment variables or volumes in containers.

7. ControllerRevisions

Name: ControllerRevision
API Version: apps/v1
Name-spaced: Yes
Explanation: Stores past configurations of Deployments and ReplicaSets, allowing for easy rollback to previous versions.

8. CronJobs

Name: CronJob (cj)
API Version: batch/v1
Name-spaced: Yes
Explanation: Schedules jobs to run periodically on a specified schedule (e.g., daily, weekly).

9. CSIDrivers

Name: CSIDriver
API Version: storage.k8s.io/v1
Name-spaced: No (Cluster-scoped)
Explanation: Represents a Container Storage Interface (CSI) driver, which allows for the integration of third-party storage systems with Kubernetes.

10. CSINodes

Name: CSINode
API Version: storage.k8s.io/v1
Name-spaced: No (Cluster-scoped)
Explanation: Represents the registration of a CSI driver on a specific node within the cluster.

11. CSIStoreageCapacities

Name: CSIStoreageCapacity
API Version: storage.k8s.io/v1
Name-spaced: No (Cluster-scoped)
Explanation: Reports the available capacity of a CSI volume.

12. CustomResourceDefinitions

Name: CustomResourceDefinition (crd, crds)
API Version: apiextensions.k8s.io/v1
Name-spaced: No (Cluster-scoped)
Explanation: Defines custom resources that extend the Kubernetes API, allowing users to create and manage their own application-specific objects.

13. DaemonSets

Name: DaemonSet (ds)
API Version: apps/v1
Name-spaced: Yes
Explanation: Ensures that a single instance of a pod is running on every node in the cluster.

14. Deployments

Name: Deployment (deploy)
API Version: apps/v1
Name-spaced: Yes
Explanation: Manages the deployment and updates of pods and ReplicaSets. Provides features like rolling updates, rollback, and health checks.

15. Endpoints

Name: Endpoints (ep)
API Version: v1
Name-spaced: Yes
Explanation: Represents the current endpoints (IP addresses and ports) for a Service.

16. Endpointslices

Name: Endpointslice
API Version: discovery.k8s.io/v1
Name-spaced: Yes
Explanation: Divides large sets of endpoints into smaller subsets for efficient service discovery in Kubernetes. Improves scalability and performance for services with many pods.

17. Events

Name: Event (ev)
API Version: v1
Name-spaced: Yes
Explanation: Records events that occur within the Kubernetes cluster, such as pod creation, deletion, and scheduling failures.

18. FlowSchemas

Name: FlowSchema
API Version: flowcontrol.apiserver.k8s.io/v1beta2
Name-spaced: No (Cluster-scoped)
Explanation: Defines a set of rules for limiting the rate of API requests to the Kubernetes API server.

19. HorizontalPodAutoscalers

Name: HorizontalPodAutoscaler (HPA)
API Version: autoscaling/v2beta2
Name-spaced: Yes
Explanation: Automatically scales the number of pods in a Deployment or ReplicaSet based on observed CPU utilization or other metrics.

20. IngressClasses

Name: IngressClass
API Version: networking.k8s.io/v1
Name-spaced: No (Cluster-scoped)
Explanation: Defines a set of configuration parameters that can be used by Ingress controllers to configure their behavior.

21. Ingresses

Name: Ingress (ing)
API Version: networking.k8s.io/v1
Name-spaced: Yes
Explanation: Exposes HTTP and HTTPS routes from outside the cluster to services within the cluster.

22. Jobs

Name: Job
API Version: batch/v1
Name-spaced: Yes
Explanation: Creates one or more pods and ensures that a specified number of them successfully completed. Often used for one-time tasks or batch
processing.

23. LimitRanges

Name: LimitRange (limits)
API Version: v1
Name-spaced: Yes
Explanation: Defines minimum and maximum resource limits for containers that are created in a namespace.

24. LocalSubjectAccessReview

Name: LocalSubjectAccessReview
API Version: authorization.k8s.io/v1
Name-spaced: Yes
Explanation: Allows you to determine if a user or group has specific permissions within the context of the pod where the request originates.

25. MutatingWebhookConfigurations

Name: MutatingWebhookConfiguration
API Version: admissionregistration.k8s.io/v1
Name-spaced: No (Cluster-scoped)
Explanation: Defines a set of webhooks that are called to modify objects before they are created or modified in the Kubernetes API server.

26. Namespaces

Name: Namespace (ns)
API Version: v1
Name-spaced: No (Cluster-scoped)
Explanation: Provides a way to divide a single cluster into multiple virtual clusters, isolating resources and permissions.

27. NetworkPolicies

Name: NetworkPolicy (netpol)
API Version: networking.k8s.io/v1
Name-spaced: Yes
Explanation: Controls network traffic between pods within a namespace and between pods and external entities.

28. Nodes

Name: Node (no)
API Version: v1
Name-spaced: No (Cluster-scoped)
Explanation: Represents a worker machine in the Kubernetes cluster, where pods are scheduled and executed.

29. PersistentVolumeClaims

Name: PersistentVolumeClaim (PVC)
Short Names: pvc
API Version: v1
Name-spaced: Yes
Explanation: Represents a request for persistent storage by a user. PVCs describe the desired characteristics of the storage (e.g., size, access
modes).

30. PersistentVolumes

Name: PersistentVolume (PV)
API Version: v1
Name-spaced: No (Cluster-scoped)
Explanation: Represents a piece of persistent storage in the cluster that has been provisioned by an administrator or dynamically provisioned using a storage class.

31. PodDisruptionBudgets

Name: PodDisruptionBudget (PDB)
API Version: policy/v1
Name-spaced: Yes
Explanation: Protects applications from disruption caused by voluntary and involuntary node evacuations (e.g., maintenance). Ensures that a minimum number of pods of a specific type are always available.

32. Pods

Name: Pod (po)
API Version: v1
Name-spaced: Yes
Explanation: The smallest and most atomic unit in Kubernetes. Represents a running container or a set of co-located containers that share resources and a common lifecycle.

33. PodTemplates

Name: PodTemplate
API Version: v1
Name-spaced: Yes
Explanation: A blueprint for creating pods. Used within higher-level objects like Deployments, ReplicaSets, and Jobs.

34. PriorityClasses

Name: PriorityClass (pc)
API Version: scheduling.k8s.io/v1
Name-spaced: No (Cluster-scoped)
Explanation: Defines a priority level for pods, influencing their scheduling decisions. Higher priority pods are more likely to be scheduled on available nodes.

35. PriorityLevelConfigurations

Name: PriorityLevelConfiguration
API Version: flowcontrol.apiserver.k8s.io/v1
Name-spaced: No (Cluster-scoped)
Explanation: Configures the global priority and preemption behavior of pods.

36. Profiles

Name: Profile
API Version: autoscaling.k8s.io/v1
Name-spaced: Yes
Explanation: Defines a set of resource requests and limits that can be applied to pods within a namespace. Used by horizontal pod autoscalers to determine scaling boundaries.

37. ReplicaSets

Name: ReplicaSet (rs)
API Version: apps/v1
Name-spaced: Yes
Explanation: Ensures that a specified number of pod replicas are running at any given time. Often used as a building block for higher-level controllers like Deployments.

38. ReplicationControllers

Name: ReplicationController (rc)
API Version: v1
Name-spaced: Yes
Explanation: An older mechanism for ensuring a fixed number of pod replicas. Largely superseded by ReplicaSets.

39. ResourceQuotas

Name: ResourceQuota (quota)
API Version: v1
Name-spaced: Yes
Explanation: Limits the amount of resources (CPU, memory, storage) that can be consumed by users or teams within a namespace.

40. RoleBindings

Name: RoleBinding
API Version: rbac.authorization.k8s.io/v1
Name-spaced: Yes
Explanation: Grants permissions to users, service accounts, or other groups by binding them to a specific Role.

41. Roles

Name: Role
API Version: rbac.authorization.k8s.io/v1
Name-spaced: Yes
Explanation: Defines a set of permissions that can be granted to users or groups within a namespace.

42. RuntimeClasses

Name: RuntimeClass
API Version: node.k8s.io/v1
Name-spaced: No (Cluster-scoped)
Explanation: Specifies the runtime environment (e.g., container runtime, security settings) for containers within a pod.

43. Secrets

Name: Secret
API Version: v1
Name-spaced: Yes
Explanation: Stores sensitive information securely within the Kubernetes cluster, such as passwords, API keys, and certificates.

44. SelfSubjectAccessReview

Name: SelfSubjectAccessReview
API Version: authorization.k8s.io/v1
Name-spaced: Yes
Explanation: Allows a user or service account to check whether they have specific permissions within the current namespace.

45. SelfSubjectRulesReview

Name: SelfSubjectRulesReview
API Version: authorization.k8s.io/v1
Name-spaced: Yes
Explanation: Allows a user or service account to check the set of permissions they have within the current namespace.

46. ServiceAccounts

Name: ServiceAccount (sa)
API Version: v1
Name-spaced: Yes
Explanation: Represents a service account within a namespace, which can be used to authenticate and authorize access to Kubernetes resources.

47. Services

Name: Service (svc)
API Version: v1
Name-spaced: Yes
Explanation: Defines a logical set of Pods and a policy for accessing them. Enables services to be discovered and accessed by other services within or outside the cluster.

48. StatefulSets

Name: StatefulSet (sts)
API Version: apps/v1
Name-spaced: Yes
Explanation: Manages the deployment and scaling of stateful applications that require stable, persistent identifiers for each pod.

49. StorageClasses

Name: StorageClass (sc)
API Version: storage.k8s.io/v1
Name-spaced: No (Cluster-scoped)
Explanation: Provides a way for administrators to define and manage different types of storage (e.g., cloud storage, local storage) that can be used by PersistentVolumes.

50. SubjectAccessReview

Name: SubjectAccessReview
API Version: authorization.k8s.io/v1
Name-spaced: Yes
Explanation: Allows a user to check whether a particular user or group has specific permissions within the current namespace.

51. TokenReview

Name: TokenReview
API Version: authentication.k8s.io/v1
Name-spaced: No (Cluster-scoped)
Explanation: Validates an authentication token and returns information about the user associated with the token.

52. ValidationWebhookConfigurations

Name: ValidationWebhookConfiguration
API Version: admissionregistration.k8s.io/v1
Name-spaced: No (Cluster-scoped)
Explanation: Defines a set of webhooks that are called to validate objects before they are created or modified in the Kubernetes API server.

53. VolumeAttachments

Name: VolumeAttachment
API Version: storage.k8s.io/v1
Name-spaced: No (Cluster-scoped)
Explanation: Represents the binding of a
PersistentVolume to a node. This object is created automatically by the Kubernetes system.

To discover the full list of resources available in your Kubernetes cluster, use the kubectl api-resources command.

Remember that production clusters often include add-on components (e.g., Istio, Traefik, Prometheus, Grafana, Fluentd, Falco, etc.) that extend the core set of resources listed here.

Find an easy-to-read document on my LinkedIn post about "Comprehensive Guide to 50+ Kubernetes Resources".

I post about DevOps, cloud-native, and compassionate leadership. You can reach out to me on LinkedIn.

Backing Up and Restoring the System—Best Practices

Yasir Rehman — Sun, 08 Dec 2024 16:06:13 +0000

Backup is the process of copying and storing data securely to prevent loss.
Recovery is the process of restoring this data after a failure or disaster.

How is it important?

Prevents data loss: Protects against accidental deletion, hardware failures, or cyberattacks.
Ensures business continuity: Minimizes downtime during disasters.
Compliance: Some industries mandate regular backups for security and audit purposes.

Consider RTO and RPO factors to strategize backup and recovery.

RTO

Recovery Time Objective (RTO) is the maximum acceptable duration your system can be down after a failure before it impacts business operations.

How can I calculate RTO for my systems?

Identify critical systems and processes for your business operations.
Perform a Business Impact Analysis (BIA) including financial losses, operational disruptions, and reputational damage.
Determine Maximum Tolerable Downtime (MTD) of each critical system before it causes significant harm.
Evaluate recovery resources (personnel, technology, and processes) required to restore each critical system.
Calculate recovery time to acquire or create the necessary resources and complete the recovery process for each system.
Set the RTO by combining the MTD and the estimated recovery time to determine the RTO for each critical system.

For example, if a critical application has an MTD of 4 hours and it takes 2 hours to recover, the RTO would be 6 hours.

RPO

Recovery Point Objective (RPO) is the maximum acceptable amount of data loss measured in time (e.g. last 5 mins, 1 hour).

How can I calculate RPO for my systems?

Identify critical data for your business operations and cannot be lost without significant impact.
Assess data change rate for you critical data changes.
Evaluate data loss tolerance for your business can tolerate. This is often measured in time (e.g., hours or minutes).
Set backup frequency based on your data change rate and loss tolerance, decide how often you need to perform backups.
Implement the backup strategy and regularly test it to ensure it meets your RPO requirements.

For example, if your critical data changes every hour and you can tolerate up to 2 hours of data loss, your RPO would be 2 hours, meaning you need to back up your data at least every 2 hours.

Types of backups

Some common types of backups are:

Full backup: A complete copy of all data. Longer time, more storage needed.
Incremental backup: Backs up only the data that has changed since the last full or incremental backup. Faster, uses less storage.
Differential backup: Backs up all data that has changed since the last full backup. Balances speed and storage usage.

Methods of backups

Some common methods for backing up the systems are:

Manual backup: Human intervention is required to initiate and monitor the backup process.
Local automated backup: Backups are automated and stored locally on the same device or network.
Remote automated backup: Backups are automated and stored remotely, often in a cloud-based storage solution.

Recommendations

A few recommendations for backing up and restoring the system are:
The 3-2-1 Rule:

3 total copies of your data
2 different storage types (e.g., local and cloud)
1 copy offsite This rule is also known as “the rule of three”. Depending on your needs, consider variations like 3-1-2, 3-2-2, or 3-2-3.

Continuous backup check
Regularly test your backups to ensure they are functioning correctly, and that data can be restored without issues.

Clear and documented backup strategy

Define responsibilities: Who handles backups?
Set schedules: When do backups occur?
Test recovery plans: Practice restoring to ensure readiness during disasters.

That's it for today!

You can find a document on my LinkedIn post about "Backing Up and Restoring the System".

I post about DevOps, engineering excellence, and compassionate leadership. You can reach out to me on LinkedIn.

Understanding Kubernetes Services

Yasir Rehman — Sun, 01 Dec 2024 21:25:57 +0000

A Kubernetes Service is an abstract way to expose an application running on a cluster. It provides a stable network endpoint for your application, even if the underlying pods are constantly changing.

Kubernetes offers the following types of Services:

ClusterIP
NodePort
LoadBalancer
External
Headless

ClusterIP

The ClusterIP service is the default Kubernetes service type. It assigns a cluster-internal IP address to the Service. Ideal for internal communication between Pods.

NodePort

A NodePort service exposes the application on a specific port on each node's IP address. It forwards traffic from that port to the underlying pods. Useful for development and testing, allowing access without a full load balancer setup.

LoadBalancer

A LoadBalancer service creates an external load balancer that routes traffic to the service's Pods. It is typically used in cloud environments
where load balancing is supported.Ideal for production applications that need to handle high traffic efficiently.

External

An External service allows you to connect to services that are outside your Kubernetes cluster. Useful for integrating with external APIs or
services. Allows Kubernetes applications to interact with resources that are not managed within the cluster.

Headless

A Headless service is a service without a ClusterIP. It enables direct access to the Pods without load balancing. Useful for stateful applications where you want to connect directly to specific Pods.

That's it for today!

Link to my LinkedIn post on "Understanding Kubernetes Services".

I post about DevOps, engineering excellence, and compassionate leadership. You can reach out to me on LinkedIn.

Docker Mastery: A Comprehensive Guide for Beginners and Pros

Yasir Rehman — Fri, 07 Jun 2024 21:12:20 +0000

Docker is a powerful platform that simplifies the creation, deployment, and management of applications within lightweight, portable containers. It allows developers to package applications and their dependencies into a standardized unit for seamless development and deployment. Docker enhances efficiency, scalability, and collaboration across different environments, making it an essential tool for modern software development and DevOps practices.
We'll delve into every aspect of Docker, from installation and configuration to mastering images, storage, networking, and security.

Installation and configuration

Basic guides for installing Docker Community Edition (CE) on CentOS and Ubuntu are given below.
Install Docker CE on CentOS

Install the required packages:
sudo yum install -y () device-mapper-persistent-data lvm2
Add Docker CE yum repository:
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
Install the Docker CE packages:
sudo yum install -y docker-ce-18.09.5 docker-ce-cli-18.09.5 containerd.io
Start and enable Docker Service:
sudo systemctl start docker sudo systemctl enable docker
Add the user to Docker group to grant the user permission to run Docker commands. It will have access to Docker after its next login.
sudo usermod -a -G docker

Installing Docker CE on Ubuntu

Install the required packages:
sudo apt-get update sudo apt-get -y install apt-transport-https ca-certificates curl gnupg-agent software-properties-common
Add the Docker repo's GNU Privacy Guard (GPG) key:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
Add the Docker Ubuntu repository:
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable
Install packages:
sudo apt-get install -y docker-ce=5:18.09.5~3-0~ubuntu-bionic docker-ce-cli=5:18.09.5~3-0~ubuntu-bionic containerd.io
Add the user to Docker group to grant the user permission to run Docker commands. It will have access to Docker after its next login.
sudo usermod -a -G docker

Selecting a storage driver
A storage driver is a pluggable driver that handles internal storage for containers. The default driver for CentOS and Ubuntu systems is overlay2.
To determine the current storage driver:
docker info | grep "Storage"
One way to select a different storage driver is to pass the --storage-driver flag over to the Docker daemon. The recommended method to set the storage driver is using the Daemon Config file.

Create or edit the Daemon config file:
sudo vi /etc/docker/daemon.json
Add the storage driver value:
"storage-driver": "overlay2"
Remember to restart Docker after any changes, and then check the status.
sudo systemctl restart docker sudo systemctl status docker

Running a container
docker run IMAGE[:TAG] [COMMAND] [ARGS]
IMAGE: Specifies the image to run a container.
COMMAND and ARGS: Run a command inside the container.
TAG: Specifies the image tag or version
-d: Runs the container in detached mode.
--name NAME: Gives the container a specified name instead of the usual randomly assigned name.
--restart RESTART: Specifies when Docker should automatically restart the container.

no (default): Never restart the container.
on-failure: Only if the container fails (exits with a non-zero exit code).
always: Always restart the container whether it succeeds or fails.
unless-stopped: Always restart the container whether it succeeds or fails, and on daemon startup unless the container is manually stopped.

-p HOST_PORT: CONTAINER_PORT: Publish a container's port. The HOST_PORT is the port that listens on the host machine, and traffic to that port is mapped to the CONTAINER_PORT on the container.
--memory MEMORY: Set a hard limit on memory usage.
--memory-reservation MEMORY: Set a soft limit on memory usage.

docker run -d --name nginx --restart unless-stopped -p 8080:80 --memory 500M --memory-reservation 256M nginx:latest

Some of the commands for managing running containers are:
docker ps: List running containers.
docker ps -a: List all containers, including stopped containers.
docker container stop [alias: docker stop]: Stop a running container.
docker container start [alias: docker start]: Start a stopped container.
docker container rm [alias: docker rm]: Delete a container (must be stopped first)

Upgrading the Docker Engine
Stop the Docker service:
sudo systemctl stop docker
Install the required version of docker-ce and docker-ce-cli:
sudo apt-get install -y docker-ce=<new version> docker-ce-cli=<new version>
Verify the current version
docker version

Image creation, management, and registry

An image is an executable package containing all the software needed to run a container.
Run a container using an image with:
docker run IMAGE
Download an image with:
docker pull IMAGE docker image pull IMAGE

Images and containers use a layered file system. Each layer contains only the differences from the previous layer.
View file system layers in an image with:
docker image history IMAGE
A Dockerfile is a file that defines a series of directives and is used to build an image.

# Use the official Nginx base image
FROM nginx:latest

# Set an environment variable
ENV MY_VAR=my_value

# Copy custom configuration file to container
COPY nginx.conf /etc/nginx/nginx.conf

# Run some commands during the build process
RUN apt-get update && apt-get install -y curl

# Expose port 80 for incoming traffic
EXPOSE 80

# Start Nginx server when the container starts
CMD ["nginx", "-g", "daemon off;"]

Build an image:
docker build -t TAG_NAME DOCKERFILE_LOCATION
Dockerfile directives:
FROM: Specifies the base image to use for the Docker image being built. It defines the starting point for the image and can be any valid image available on Docker Hub or a private registry.
ENV: Sets environment variables within the image. These variables are accessible during the build process and when the container is running.
COPY or ADD: Copies files and directories from the build context (the directory where the Dockerfile is located) into the image. COPY is generally preferred for simple file copying, while ADD supports additional features such as unpacking archives.
RUN: Executes commands during the build process. You can use RUN to install dependencies, run scripts, or perform any other necessary tasks.
EXPOSE: Informs Docker that the container will listen on the specified network ports at runtime. It does not publish the ports to the host machine or make the container accessible from outside.
CMD or ENTRYPOINT: Specifies the command to run when a container is started from the image. CMD provides default arguments that can be overridden, while ENTRYPOINT specifies a command that cannot be overridden.
WORKDIR: Sets the working directory for any subsequent RUN, CMD, ENTRYPOINT, COPY, or ADD instructions.
STOPSIGNAL: Sets a custom signal that will be used to stop the container process.
HEALTHCHECK: Sets a command that will be used by the Docker daemon to check whether the container is healthy

A multi-stage build in a Dockerfile is a technique used to create more efficient and smaller Docker images. It involves defining multiple stages within the Dockerfile, each with its own set of instructions and dependencies.
An example Dockerfile containing a multi-stage build definition is:

# Build stage
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /app

# Copy and restore project dependencies
COPY *.csproj .
RUN dotnet restore

# Copy the entire project and build
COPY . .
RUN dotnet build -c Release --no-restore

# Publish the application
RUN dotnet publish -c Release -o /app/publish --no-restore

# Runtime stage
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS runtime
WORKDIR /app
COPY --from=build /app/publish .

# Expose the required port
EXPOSE 80

# Set the entry point for the application
ENTRYPOINT ["dotnet", "YourApplication.dll"]

Managing images
Some key commands for image management are:
List images on the system:
docker image ls
List images on the system including intermediate images:
docker image ls -a
Get detailed information about an image:
docker image inspect <IMAGE>
Delete an image:
docker rmi <IMAGE> docker image rm <IMAGE> docker image rm -f <IMAGE>
An image can only face deletion if no containers or other image tags reference it. Find and delete dangling or unused images:
docker image prune

Docker registries
Docker Registry serves as a centralized repository for storing and sharing Docker images. Docker Hub is the default, publicly available registry managed by Docker. By utilizing the registry image, we can set up and manage our own private registry at no cost.
Run a simple registry:
docker run -d -p 5000:5000 --restart=always --name registry registry:2
Upload an image to a registry:
docker push <IMAGE>:<TAG>
Download an image from a registry:
docker pull <IMAGE>:<TAG>
Login to a registry:
docker login REGISTRY_URL
There are two authentication methods for connecting to a private registry with an untrusted or self-signed certificate:
Secure: This involves adding the registry's public certificate to the /etc/docker/certs.d/ directory.
Insecure: This method entails adding the registry to the insecure-registries list in the daemon.json file or passing it to dockerd using the --insecure-registry flag.

Storage and volumes
The storage driver controls how images and containers are stored and managed on your Docker host. Docker supports several storage drivers, using a pluggable architecture.
overlay2: Preferred for all Linux distributions
fuse-overlayfs: Preferred only for running Rootless Docker (not Ubuntu or Debian 10)
vfs: Intended for testing purposes, and for situations where no copy-on-write filesystem can be used.

Storage models
*Filesystem storage: *

Data is stored in the form of regular files on the host disk
Efficient use of memory
Inefficient with write-heavy workloads
Used by overlay2

Block Storage:

Stores data in blocks using special block storage devices
Efficient with write-heavy workloads
Used by btrfs and zfs

Object Storage:

Stores data in an external object-based store
Applications must be designed to use object-based storage.
Flexible and scalable.

Configuring the overlay2 storage driver
Stop Docker service:
sudo systemctl stop docker
Create or edit the Daemon config file:
sudo vi /etc/docker/daemon.json
Add/edit the storage driver value:
"storage-driver": "overlay2"
Remember to restart Docker after any changes, and then check the status.
sudo systemctl restart docker sudo systemctl status docker

Docker Volumes
There are two different types of data mounts on Docker:
Bind Mount: Mounts a specific directory on the host to the container. It is useful for sharing configuration files, and other data between the container and host.
Named Volume: Mounts a directory to the container, but Docker controls the location of the volume on disk dynamically.
There are different syntaxes for adding bind mounts or volumes to containers:
-v syntax _
Bind mount: The source begins with a forward slash "/" which makes this a bind mount.
docker run -v /opt/data:/tmp nginx
Named volume: The source is just a string, which means this is a volume. It will be automatically created if no volume exists with the provided name.
docker run -v my-vol:/tmp nginx
_--mount syntax
Bind mount:
docker run --mount source=/opt/data,destination=/tmp nginx
Named volume:
docker run --mount source=my-vol,destination=/tmp nginx
We can mount the same volume to multiple containers, allowing them to share data. We can also create and manage volumes by ourselves without running a container.

Some common and useful commands:
docker volume create VOLUME: Creates a volume.
docker volume ls: Lists volumes.
docker volume inspect VOLUME: Inspects a volume.
docker volume rm VOLUME: Deletes a volume.

Image Cleanup
Check Docker's disk usage:
docker system df
docker system df -v
Delete unused or dangling images:
docker image prune docker image prune -a

Docker networking

Docker Container Networking Model (CNM) is a conceptual model that describes the components and concepts of Docker networking.
There are multiple implementations of the Docker CNM:
Sandbox: An isolated unit containing all networking components associated with a single container.
Endpoint: Connects one sandbox to one network.
Network: A collection of endpoints that can communicate with each other. Network Driver: A pluggable driver that provides a specific implementation of the CNM.
IPAM Driver: Provides IP address management. Allocates and assigns IP addresses.

Built-In Network Drivers
Host: This driver connects the container directly to the host's networking stack. It provides no isolation between containers or between containers and the host.
docker run --net host nginx
Bridge: This driver uses virtual bridge interfaces to establish connections between containers running on the same host.
docker network create --driver bridge my-bridge-net docker run -d --network my-bridge-net nginx
Overlay: This driver uses a routing mesh to connect containers across multiple Docker hosts, usually in a Docker swarm.
docker network create --driver overlay my-overlay-net docker service create --network my-overlay-net nginx
MACVLAN: This driver connects containers directly to the host's network interfaces but uses a special configuration to provide isolation.
docker network create -d macvlan --subnet 192.168.0.0/24 --gateway 192.168.0.1 -o parent=eth0 my-macvlan-net docker run -d --net my-macvlan-net nginx
None: This driver provides sandbox isolation, but it does not provide any implementation for networking between containers or between containers and the host.
docker run --net none -d nginx

Creating a Docker Bridge network
It is the default driver. Therefore, any network that is created without specifying the driver will be a bridge network.
Create a bridge network.
docker network create my-net
Run a container on the bridge network.
docker run -d --network my-net nginx

By default, containers and services on the same network can communicate with each other simply by using their container or service names. Docker provides DNS resolution on the network that allows this to work.
Supply a network alias to provide an additional name by which a container or service is reached.
docker run -d --network my-net --network-alias my-nginx-alias nginx

Some useful commands for when one must interact with Docker networks are:
docker network ls: Lists networks.
docker network inspect NETWORK: Inspects a network.
docker network connect CONTAINER NETWORK: Connects a container to a network.
docker network disconnect CONTAINER NETWORK: Disconnects a container from a network.
docker network rm NETWORK: Deletes a network.

Creating a Docker Overlay Network
Create an overlay network:
docker network create --driver overlay NETWORK_NAME
Create a service that uses the network:
docker service create --network NETWORK_NAME IMAGE

Network Troubleshooting
View container logs:
docker logs CONTAINER
View logs for all tasks of a service:
docker service logs SERVICE
View Docker daemon logs:
sudo jounralctl -u docker

We can use the nicolaka/netshoot image to perform network troubleshooting. It comes packaged with a variety of useful networking-related tools. We can inject a container into another container's networking sandbox for troubleshooting purposes.
docker run --network container:CONTAINER_NAME nicolaka/netshoot

Configuring Docker to Use External DNS
Set the system-wide default DNS for Docker containers in daemon.json:
{ "dns": ["8.8.8.8"] }
Set the DNS for an individual container.
docker run --dns 8.8.4.4 IMAGE

Security

Signing Images and Enabling Docker Content Trust
Docker Content Trust (DCT) is a feature that allows us to sign images and verify signatures before running them. Enable Docker Content Trust by setting an environment variable:
DOCKER_CONTENT_TRUST=1
The system will not run images if they are unsigned or if the signature is not valid with Docker Content Trust enabled.
Sign and push an image with:
docker trust sign
With DOCKER_CONTENT_TRUST=1, docker push automatically signs the image before pushing it.

Default Docker Engine Security
Basic Docker security concepts:
Docker uses namespaces to isolate container processes from one another and the host. This prevents an attacker from affecting or gaining control of other containers or the host if they manage to gain control of one container.
The Docker daemon must run with root access. Before allowing anyone to interact with the daemon, be aware of this. It could be used to gain access to the entire host.
Docker leverages Linux capabilities to assign granular permissions to container processes. For example, listening on a low port (below 1024) usually requires a process to run as root, but Docker uses Linux capabilities to allow a container to listen on port 80 without running as root.

Securing the Docker Daemon HTTP Socket
Generate a certificate authority and server certificates for the Docker server.

openssl genrsa -aes256 -out ca-key.pem 4096` 

`openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem -subj "/C=US/ST=Texas/L=Keller/O=Linux Academy/OU=Content/CN=$HOSTNAME" openssl genrsa -out server-key.pem 4096 `

`openssl req -subj "/CN=$HOSTNAME" -sha256 -new -key server-key.pem -out server.csr \ echo subjectAltName = DNS:$HOSTNAME,IP:,IP:127.0.0.1 >> extfile.cnf `

`echo extendedKeyUsage = serverAuth >> extfile.cnf `

`openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile extfile.cnf`
Generate client certificates:
`openssl genrsa -out key.pem 4096 

openssl req -subj '/CN=client' -new -key key.pem -out client.csr 

echo extendedKeyUsage = clientAuth > extfile-client.cnf 

openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem \
-CAcreateserial -out cert.pem -extfile extfile-client.cnf

Set appropriate permissions on the certificate files:
chmod -v 0400 ca-key.pem key.pem server-key.pem chmod -v 0444 ca.pem server-cert.pem cert.pem
Configure the Docker host to use tlsverify mode with the certificates created earlier:

sudo vi /etc/docker/daemon.json

{
 "tlsverify": true,
 "tlscacert": "/home/user/ca.pem",
 "tlscert": "/home/user/server-cert.pem",
 "tlskey": "/home/user/server-key.pem"
 }

Edit the Docker service file, look for the line that begins with ExecStart and change the -H.
sudo vi /lib/systemd/system/docker.service

ExecStart=/usr/bin/dockerd -H=0.0.0.0:2376 --containerd=/run/containerd/containerd.sock

sudo systemctl daemon-reload
sudo systemctl restart docker
Copy the CA cert and client certificate files to the client machine.
On the client machine, configure the client to connect to the remote Docker daemon securely:
mkdir -pv ~/.docker
cp -v {ca,cert,key}.pem ~/.docker
export DOCKER_HOST=tcp://:2376 DOCKER_TLS_VERIFY=1
Test the connection:
docker version

Conclusion

In conclusion, mastering Docker transforms your development workflow by streamlining installation, configuration, image management, storage, networking, and security. This guide equips you with essential knowledge and practical skills, enabling you to build, ship, and run applications efficiently. Embrace Docker's power to elevate your container management to the next level.

Maximizing Value: A Guide to Cost Optimization in Microsoft Azure

Yasir Rehman — Wed, 27 Mar 2024 22:19:01 +0000

Cost optimization is essential for businesses to ensure they are getting the most value from their Azure investments. By optimizing costs, organizations can effectively manage their budgets, allocate resources efficiently, and ultimately improve their bottom line. With the right strategies in place, businesses can achieve significant savings while maintaining optimal performance and scalability.

Cost optimization fundamentals

Balance is everything
Achieving cost optimization requires striking a delicate balance between performance, reliability, and cost. It involves identifying areas where resources are underutilized or overprovisioned and making adjustments to optimize efficiency without sacrificing quality.
The cloud shift in process
Cloud cost management requires a different mindset compared to on-premises IT. Traditional upfront capital expenditure is replaced by a pay-as-you-go model, demanding continuous monitoring and optimization strategies.
Financial Operations (FinOps)
FinOps is a methodology that combines financial and operational processes to optimize cloud costs continuously. It involves collaboration between finance, operations, and engineering teams to align cloud spending with business objectives and drive accountability across the organization.
FinOps goal
The primary goal of FinOps is to enable organizations to understand and control their cloud spending effectively. By implementing FinOps practices, businesses can gain visibility into their cloud usage, identify cost optimization opportunities, and implement strategies to reduce waste and unnecessary spending.

FinOps advocates for a continuous improvement approach. This involves setting clear goals, measuring and analyzing costs, identifying optimization opportunities, implementing solutions, and monitoring progress.

Azure Cloud constructs

Management Groups, Subscriptions, and Resource Groups
Organizing Azure resources into management groups, subscriptions, and resource groups provides a hierarchical structure for managing access, policies, and costs. This allows organizations to enforce governance policies, track spending, and optimize resource utilization effectively.
Using Tags
Tags provide a flexible mechanism for categorizing and organizing Azure resources. By applying tags consistently across resources, organizations can gain insights into cost allocation, track spending by department or project, and implement targeted cost optimization strategies.
Policy and Role-Based Access Control
Implementing policies and role-based access control (RBAC) helps organizations enforce compliance requirements, control access to resources, and prevent unauthorized spending. By defining policies and roles, businesses can ensure that only authorized users have access to resources and that they adhere to predefined cost optimization guidelines.
Infrastructure as Code
Infrastructure as code (IaC) enables organizations to define and manage Azure resources programmatically. By automating the deployment and configuration of resources, businesses can improve consistency, reduce errors, and optimize costs by eliminating manual intervention and streamlining resource provisioning.
Budgets
Setting and managing budgets in Azure allows organizations to monitor and control their cloud spending effectively. By establishing budget thresholds and alerts, businesses can proactively identify and address potential cost overruns, track spending against targets, and optimize resource usage to stay within budget constraints.

Azure cloud constructs provide a foundation for organized and accountable resource management, ultimately contributing to optimized Azure cloud costs.

Azure tooling

Azure Monitoring
Azure monitoring provides visibility into the performance, availability, and usage of Azure resources. By monitoring key metrics and trends, organizations can identify areas for optimization, troubleshoot issues, and ensure optimal performance and cost efficiency.
Azure Pricing Calculator
Estimate costs upfront for various Azure resources and configurations using the Azure Pricing Calculator. This helps plan your cloud migration and optimize resource selection for future deployments.
Azure Advisor
Azure Advisor offers personalized recommendations for optimizing Azure resources based on best practices and usage patterns. By following Advisor recommendations, businesses can improve resource utilization, reduce costs, and enhance the overall efficiency of their Azure environment.
Azure Advisor Cost Optimization Workbook
The Azure Advisor cost optimization workbook provides a comprehensive view of cost-saving opportunities across Azure subscriptions. By analyzing cost recommendations and implementing optimization actions, organizations can achieve significant cost savings while maintaining performance and reliability.
Azure Monitor Insights
Azure Monitor Insights provides actionable insights into Azure resource usage, performance, and cost trends. By analyzing monitoring data and identifying optimization opportunities, businesses can make informed decisions to improve efficiency and reduce costs in their Azure environment.
Microsoft Cost Management
Microsoft Cost Management offers a centralized platform for managing and optimizing Azure costs. By leveraging Cost Management features, organizations can track spending, analyze cost drivers, implement cost-saving strategies, and optimize resource usage to achieve maximum value from their Azure investments.
Power BI Cost Management App
The Power BI Cost Management app provides interactive dashboards and reports for visualizing and analyzing Azure cost data. By using Power BI, businesses can gain deeper insights into their cloud spending, identify cost optimization opportunities, and make data-driven decisions to improve cost efficiency.

Azure offers a variety of tools for managing and optimizing cloud resources. Azure Monitor provides visibility into resource performance and usage. Azure Advisor offers recommendations for improving efficiency and reducing costs. Azure Monitor Insights and Cost Management tools along with Power BI help analyze resource data and make informed decisions to optimize your Azure environment. Additionally, the Azure Pricing Calculator helps estimate costs upfront, allowing you to plan your cloud migration and optimize resource selection for future deployments.

Optimization of workloads

General Guidance
Optimizing workload involves identifying inefficiencies and implementing strategies to improve resource utilization and reduce costs. By following general guidance and best practices, organizations can achieve significant cost savings while maintaining performance and reliability in their Azure environment.

Plan for the future: Invest time upfront to understand your requirements and strategic direction. This ensures you architect the optimal solution that meets your needs without overspending.
Optimize the development environment: Utilize the most cost-effective resources for development environments. Restrict resource types and ensure they are stopped when not in use. However, be cautious not to create a testing environment that deviates significantly from production, as this can lead to performance issues later.
Evaluate regional costs: Azure offers varying pricing across different regions. Evaluate the cost implications of deploying resources in specific regions based on your needs and data residency requirements.
Leverage development benefits: Take advantage of Visual Studio Subscriptions for development purposes, but avoid using them for production workloads to control costs. Utilize Dev/Test Pricing and free tier resources offered by Azure for development and testing activities.
Governance is key: Implement strong governance standards to manage resource provisioning and usage. This helps prevent accidental overspending and ensures resources are aligned with business needs.
Find and remove unused resources: Regularly identify and remove unused resources like idle VMs or unattached disks. However, exercise caution to avoid deleting critical resources accidentally.
Shift right: As you move your workloads to platform as a service (PaaS) and embrace serverless offerings, you benefit from a pay-per-use model, where you only pay for the work performed by the service. This can significantly reduce your cloud expenditures.

Specific workload approach
Each workload requires a tailored approach to cost optimization based on its unique requirements and usage patterns. By analyzing workload characteristics and implementing targeted optimization strategies, businesses can optimize costs effectively without compromising performance or reliability.

Virtual Machines: Optimizing virtual machines involves rightsizing instances, implementing auto-scaling, and leveraging reserved instances or Azure Hybrid Benefit to reduce costs while meeting performance requirements.
Azure Kubernetes Service: For Azure Kubernetes Service (AKS), optimizing costs involves rightsizing node pools, leveraging spot instances, and optimizing cluster configurations to improve resource utilization and reduce costs.
App Services: Optimizing App Services involves implementing auto-scaling, optimizing instance sizes, and leveraging Azure Hybrid Benefit or reserved instances to reduce costs while ensuring scalability and performance.
Storage Accounts: Optimizing storage accounts involves implementing data lifecycle management policies, leveraging tiered storage, and optimizing data access patterns to reduce storage costs while meeting data retention and access requirements.
Managed Disks: For managed disks, optimizing costs involves rightsizing disk sizes, implementing auto-scaling, and leveraging reserved capacity to reduce costs while ensuring optimal performance and availability.
Databases: Optimizing databases involves rightsizing database instances, implementing auto-scaling, and leveraging reserved capacity or Azure Hybrid Benefit to reduce costs while maintaining performance and reliability.
App Gateway: Optimizing Azure Application Gateway involves rightsizing instances, optimizing configuration settings, and leveraging reserved capacity or Azure Hybrid Benefit to reduce costs while ensuring optimal performance and scalability.
Log Analytics Workspaces: Optimizing log analytics workspaces involves managing retention policies, optimizing data ingestion and query performance, and leveraging reserved capacity to reduce costs while meeting compliance and operational requirements.

Optimizing workloads involves finding inefficiencies and making your resources work best for you. This can be done through general best practices or by taking a specific approach depending on the workload type. Here's a breakdown for common Azure workloads: VMs, AKS clusters, App Services, Storage, and Databases. Each has its own optimization techniques like rightsizing, auto-scaling, and leveraging cost-saving options.

Financial strategies

Azure Hybrid Benefit
Azure Hybrid Benefit allows organizations to use on-premises licenses to run certain Microsoft software on Azure virtual machines, reducing costs by up to 40%.
Reserved Instances
Reserved Instances enable organizations to reserve virtual machines or Azure SQL Database capacity for one or three years, offering significant cost savings compared to pay-as-you-go pricing.
Azure Savings Plan
Azure Savings Plan provides flexible pricing options for virtual machines, Azure Kubernetes Service, Azure SQL Database capacity, and other Azure services, offering up to 72% savings compared to pay-as-you-go pricing. With Azure Savings Plan, organizations commit to a specific usage volume for a one or three-year term, allowing them to benefit from discounted rates based on their committed usage.
Reserved Instances vs Azure Savings Plan
While both Reserved Instances and Azure Savings Plan offer significant cost savings, they differ in terms of flexibility and pricing model. Choosing between reserved instances and Azure savings plans depends on your specific workload predictability:
Reserved Instances: Ideal for workloads with consistent and predictable resource consumption. You get the highest discount (up to 72%) but sacrifice some flexibility.
Azure Savings Plan: More flexible option suitable for workloads with variable compute usage. You get a lower discount (up to 65%) but can benefit from applying it across different compute resources.

Azure offers financial strategies to reduce costs. Use existing licenses for VMs with Azure Hybrid Benefit, reserve resources for upfront discounts with Reserved Instances, or commit to a spending level for broader discounts with Azure Savings Plan.

Conclusion

Cost optimization in the cloud is a dynamic and ongoing process. By understanding and leveraging the tools and mechanisms available within Azure, organizations can achieve a balance between cost, performance, and scalability, driving greater business value and innovation. Implementing a culture of cost awareness and accountability, such as FinOps, and utilizing Azure's cost management features, can lead to significant savings and a more efficient use of cloud resources.

Kubernetes: Designing and Building Applications

Yasir Rehman — Sat, 08 Jul 2023 18:39:12 +0000

This article provides various aspects of application design and development in Kubernetes, covering topics such as container images, running jobs and cron jobs, building multi-container pods, utilizing Init containers, leveraging volumes and their types, and utilizing persistent volumes.

Container Image

An image is a self-contained file that encapsulates all the essential software and executables required to execute a container. It serves as a compact and portable package that enables you to deploy and operate your application across numerous containers.
Docker is one tool that you use to create your own images. A Dockerfile defines what is contained in the image. The docker build command builds an image using the Dockerfile.
Checkout to my article "Docker: Image Creation, Management, and Registry" to create and manage Docker images.

Running Jobs and CronJobs

Jobs are specifically designed to execute containerized tasks and ensure their successful completion. It can also be used to run multiple Pods in parallel.
A sample manifest of a Job:

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  template:
    spec:
      containers:
      - name: my-container
        image: my-image:latest
        command: ["echo", "Hello, Kubernetes!"]
      restartPolicy: Never
  backoffLimit: 3
  activeDeadlineSeconds: 10

The Job object is in Kubernetes "batch" APIs. The restartPolicy is set to "Never" to ensure the Job completes without retries. The backoffLimit is set to 3, meaning the Job will be retried at most 3 times in case of failures. The activeDeadlineSeconds is the maximum time Kubernetes allows to run the job.

CronJobs are designed to execute Jobs at regular intervals based on a predefined schedule. One CronJob object is like one line of a crontab (cron table) file on a Unix system.
A sample manifest of a CronJob:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: example-cronjob
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: my-container
            image: my-image:latest
            command: ["echo", "Hello, Kubernetes CronJob!"]
          restartPolicy: OnFailure
      backoffLimit: 3
      activeDeadlineSeconds: 10

The schedule field uses a cron expression to define the desired schedule for running the Job. It represents minute, hour, day of the month, month, and day of the week (from left to right).

The restartPolicy for a Job or CronJob Pod must be OnFailure or Never.

Building Multi-Container Pods

Multi-Container Pods are Pods that consist of multiple containers collaborating within a single unit. They involve the inclusion of more than one container within a shared Pod.

An example manifest of a multi-container Pod:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  volumes:
    - name: shared-volume
      emptyDir: {}
  containers:
    - name: main-container
      image: main-image:latest
      volumeMounts:
        - name: shared-volume
          mountPath: /shared-data
    - name: sidecar-container
      image: sidecar-image:latest
      volumeMounts:
        - name: shared-volume
          mountPath: /shared-data

Multi-container Pods are recommended for scenarios where containers require tight coupling and the need to share resources like network and storage volumes.

It is advisable to utilize multi-container Pods selectively, focusing on situations where close collaboration and resource sharing between containers are necessary.

Multi-Container Design Patterns

In the Sidecar pattern, a sidecar container works alongside the main container to provide assistance or perform complementary tasks. One example is when the main container serves files from a shared volume, and the sidecar container periodically updates those files.
In the Ambassador pattern, an ambassador container acts as a proxy for network traffic to and/or from the main container. One example is when the main container needs to communicate with a database, and the ambassador container proxies the traffic to different databases based on the environment.
In the Adapter pattern, an adapter container is responsible for transforming the output of the main container in some way. One example is when the main container produces log data in a non-standard format without timestamps, and the adapter container transforms the data by adding timestamps and converting it into a standard format.

Using Init containers

An Init container is designed to fulfill a specific task before the main container within a Pod is initiated. It operates on a one-time basis, executing its designated job and then concluding its execution. Once the Init container completes its task, the main container within the Pod is initiated and begins its execution.
An example manifest of a Pod using Init container:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: main-container
      image: main-image:latest
      command: ["sh", "-c", "echo Main container started; sleep 10; echo Main container completed"]
      ports:
        - containerPort: 8080
          protocol: TCP
  initContainers:
    - name: init-container
      image: init-image:latest
      command: ["sh", "-c", "echo Init container started; sleep 5; echo Init container completed"]

A few use-cases of Init containers are:

Separate image: Init containers offer the capability to execute start-up tasks using a distinct image, which may involve software not included or required by the main container's image.
Delay startup: Init containers provide a means to defer the start of the main container until specific prerequisites are satisfied.
Security: Init containers offer a secure approach to executing sensitive start-up processes, such as consuming secrets, in isolation from the main container.

Exploring Volumes

A volume serves as a storage solution external to the container's file system, offering additional storage capabilities for containers.
Volume vs VolumeMounts
Volume: Specified within the Pod configuration, the volume defines the specifics regarding the storage location and configuration for data within a Pod.
VolumeMounts: Configured within the container specification, volumeMounts associate a volume with a particular container and determine the directory path at which the volume data will be accessible during runtime.

Volume types

The volume type determine where and how data storage is handled. There are a lot of volume types but a few important ones are:
hostPath
Data is stored in a specific location directly on the host file system on the Kubernetes node where the Pod is running.
An example manifest of Pod using hostPath volume:

apiVersion: v1
kind: Pod
metadata:
  name: hostpath-pod
spec:
  containers:
    - name: example-container
      image: example-image:latest
      volumeMounts:
        - name: data-volume
          mountPath: /app/data
  volumes:
    - name: data-volume
      hostPath:
        path: /data
        type: Directory

hostPath volume has further four types:

Directory: Mounts an existing directory on the host
DirectoryOrCreate: Mounts an existing directory on the host and creates if does not exist.
File: Mounts an existing single file on the host
FileOrCreate: Mounts an existing single file on the host and creates if it does not exist.

emptyDir
Data is stored in an automatically managed location on the host file system. Data is deleted if the Pod is deleted.
An example manifest of a Pod using emptyDir volume:

apiVersion: v1
kind: Pod
metadata:
  name: emptydir-pod
spec:
  containers:
    - name: example-container
      image: example-image:latest
      volumeMounts:
        - name: data-volume
          mountPath: /app/data
  volumes:
    - name: data-volume
      emptyDir: {}

persistentVolumeClaim
Data is stored using a persistentVolume.

Using PersistentVolume

A PersistentVolume provides the ability to abstract storage details from Pods, treating storage as a consumable resource without directly exposing the underlying storage implementation.

PersistentVolume vs PersistentVolumeClaim
A PersistentVolume (PV) defines an abstract storage resource that is available for consumption by Pods. It encompasses specific information regarding the type and capacity of storage that it provides.
A PersistentVolumeClaim (PVC) declares the need for storage and specifies the required characteristics, such as storage type. It automatically binds to an available PersistentVolume (PV) that fulfills the defined requirements. Once bound, the PVC can be mounted within a Pod like any other volume.

An example of a Pod manifest YAML file that includes a PersistentVolumeClaim (PVC) and PersistentVolume (PV):

apiVersion: v1
kind: Pod
metadata:
  name: pvc-pod
spec:
  containers:
    - name: example-container
      image: example-image:latest
      volumeMounts:
        - name: data-volume
          mountPath: /app/data
  volumes:
    - name: data-volume
      persistentVolumeClaim:
        claimName: my-pvc
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /data

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

This example demonstrates the usage of PVC and PV in a Pod. The PVC is bound to an available PV that meets the specified requirements, and the PV is mounted as a volume within the Pod.

By focusing on container images, running jobs and cron jobs, building multi-container pods, utilizing Init containers, exploring volumes and their types, and leveraging persistent volumes, developers can create robust and resilient applications in the Kubernetes ecosystem. Adopting these approaches and understanding the underlying concepts will empower developers to unlock the full potential of Kubernetes for their application deployments.

Docker: Image Creation, Management, and Registry

Yasir Rehman — Sun, 25 Jun 2023 22:29:57 +0000

Docker Images

A Docker image is a self-contained bundle that includes all the necessary software required to run a container. It serves as an executable package, encapsulating the application code, dependencies, and system libraries, ensuring consistency and portability across different environments.

Run a container using an image:

 docker run <IMAGE>

Download an image:

 docker pull <IMAGE>
 docker image pull <IMAGE>

Docker utilizes a layered file system for its images and containers. Each layer within the file system contains only the modifications and differences from the preceding layer, allowing for efficient storage and sharing of resources.
View file system layers in an image:

 docker image history <IMAGE>

The Components of a Dockerfile

A Dockerfile is a file that provides instructions for building a Docker image. It contains a series of directives that define the steps and configuration needed to create the image.

An example of Dockerfile:

# Use the official Nginx base image
FROM nginx:latest

# Set an environment variable
ENV MY_VAR=my_value

# Copy custom configuration file to container
COPY nginx.conf /etc/nginx/nginx.conf

# Run some commands during the build process
RUN apt-get update && apt-get install -y curl

# Expose port 80 for incoming traffic
EXPOSE 80

# Start Nginx server when the container starts
CMD ["nginx", "-g", "daemon off;"]

Build an image:

 docker build -t TAG_NAME DOCKERFILE_LOCATION

Dockerfile directives:

FROM: Specifies the base image to use for the Docker image being built. It defines the starting point for the image and can be any valid image available on Docker Hub or a private registry.
ENV: Sets environment variables within the image. These variables are accessible during the build process and when the container is running.
COPY or ADD: Copies files and directories from the build context (the directory where the Dockerfile is located) into the image. COPY is generally preferred for simple file copying, while ADD supports additional features such as unpacking archives.
RUN: Executes commands during the build process. You can use RUN to install dependencies, run scripts, or perform any other necessary tasks.
EXPOSE: Informs Docker that the container will listen on the specified network ports at runtime. It does not actually publish the ports to the host machine or make the container accessible from outside.
CMD or ENTRYPOINT: Specifies the command to run when a container is started from the image. CMD provides default arguments that can be overridden, while ENTRYPOINT specifies a command that cannot be overridden.
WORKDIR: Sets the working directory for any subsequent RUN, CMD, ENTRYPOINT, COPY, or ADD instructions.
STOPSIGNAL: Sets a custom signal that will be used to stop the container process.
HEALTHCHECK: Sets a command that will be used by the Docker daemon to check whether the container is healthy

An example Dockerfile containing multi-stage build defination:

# Build stage
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /app

# Copy and restore project dependencies
COPY *.csproj .
RUN dotnet restore

# Copy the entire project and build
COPY . .
RUN dotnet build -c Release --no-restore

# Publish the application
RUN dotnet publish -c Release -o /app/publish --no-restore

# Runtime stage
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS runtime
WORKDIR /app
COPY --from=build /app/publish .

# Expose the required port
EXPOSE 80

# Set the entry point for the application
ENTRYPOINT ["dotnet", "YourApplication.dll"]

Managing images

Some key commands for image management are:

List images on the system:

docker image ls

List images on the system including intermediate images:

docker image ls -a

Get detailed information about an image:

docker image inspect <IMAGE>

Delete an image:

docker rmi <IMAGE>
docker image rm <IMAGE>
docker image rm -f <IMAGE>

An image can only face deletion if no containers or other image tags reference it. But force deletion of an image, even if gets referenced by something else.
Find and delete dangling or unused images:

docker image prune

Docker registries

Docker Registry serves as a centralized repository for storing and sharing Docker images. Docker Hub is the default, publicly available registry managed by Docker.
By utilizing the registry image, we have the ability to set up and manage our own private registry at no cost.

Run a simple registry:

docker run -d -p 5000:5000 --restart=always --name registry registry:2

Upload an image to a registry:

docker push <IMAGE>:<TAG>

Download an image from a registry:

docker pull <IMAGE>:<TAG>

docker login REGISTRY_URL

There are two authentication methods for connecting to a private registry with an untrusted or self-signed certificate:

Secure: This involves adding the registry's public certificate to the /etc/docker/certs.d/ directory.
Insecure: This method entails adding the registry to the insecure-registries list in the daemon.json file or passing it to dockerd using the --insecure-registry flag.

By leveraging the power of Docker, developers and organizations can streamline application deployment, improve scalability, and enhance overall software development processes. With the knowledge gained from this comprehensive overview, you're well-equipped to harness the full potential of Docker images and drive innovation in your containerized workflows.

Kubernetes Architectural Overview

Yasir Rehman — Sun, 25 Jun 2023 17:49:18 +0000

Kubernetes is a popular open-source platform used to manage containerized applications. It provides a flexible and scalable way to deploy, manage, and automate containerized workloads. A Kubernetes cluster consists of a control plane and worker nodes.

Control Plane

The Kubernetes control plane is composed of several components that are responsible for overseeing and managing the cluster on a global scale. Its main function is to govern the operations of the entire cluster. While the control plane components can be deployed on any machine within the cluster, it is common practice to run them on dedicated controller machines.

The kube-api-server fulfills the role of serving the Kubernetes API, which serves as the primary interface for interacting with the control plane and the cluster as a whole. When you interact with your Kubernetes cluster, you will typically do so through the Kubernetes API.
Etcd serves as the underlying data storage for the Kubernetes cluster, functioning as a reliable and highly available storage solution for all cluster-related data. It is responsible for storing and maintaining the cluster's state information.
The kube-scheduler is responsible for the task of scheduling, which involves the selection of an appropriate node within the cluster for running containers. It ensures that containers are allocated to available nodes based on factors such as resource requirements and availability, optimizing the distribution of workloads across the cluster.
The kube-controller-manager consolidates multiple controller utilities into a single process. These controllers perform various automated tasks within the cluster, facilitating efficient management and operation. By running multiple controllers within a unified framework, the kube-controller-manager streamlines the execution of these automation tasks in a cohesive manner.
The cloud-controller-manager serves as a bridge between Kubernetes and diverse cloud platforms, facilitating seamless integration and management of cloud resources within the Kubernetes environment. This component is utilized specifically when leveraging cloud-based resources alongside Kubernetes, enabling efficient utilization of cloud services in conjunction with Kubernetes capabilities.

The control plane components can be deployed on either a single server or multiple servers, depending on the desired configuration. In order to achieve high availability for the cluster, it is recommended to run these components on multiple servers. This ensures redundancy and fault tolerance, enhancing the overall resilience of the cluster.

Worker nodes

Kubernetes nodes serve as the execution environment for containers managed by the cluster. A cluster can comprise any number of nodes, each responsible for hosting and managing containers. The nodes consist of multiple components that oversee container operations on the machine and establish communication with the control plane. These components ensure proper orchestration and coordination of containers within the cluster.

The kubelet acts as the Kubernetes agent deployed on every node within the cluster. It establishes communication with the control plane and ensures the execution of containers on its respective node, following instructions provided by the control plane. Additionally, the kubelet is responsible for reporting container status and transmitting relevant data pertaining to containers back to the control plane.
The kube-proxy serves as a network proxy within the Kubernetes cluster. It runs on each node, and takes on specific responsibilities associated with facilitating networking between containers and services.
The container runtime is an independent software component that Kubernetes relies on to execute containers on the underlying machine. It is not inherently integrated into Kubernetes itself. Instead, Kubernetes supports multiple implementations of container runtimes. These runtime implementations are responsible for the actual execution and management of containers.

In conclusion, Kubernetes architecture consists of a robust control plane comprising various components such as kube-api-server, kube-scheduler, kube-controller-manager, and cloud-controller-manager. These components work together to manage the cluster, schedule containers, handle automation tasks, and interface with cloud platforms. On the worker nodes, kubelet and kube-proxy play essential roles in managing and executing containers while ensuring seamless networking. This distributed architecture enables the efficient orchestration and scalability of containerized applications in Kubernetes clusters.

Azure Architecture Fundamentals: Azure subscriptions and management groups

Yasir Rehman — Wed, 24 May 2023 16:26:33 +0000

Azure Architecture Fundamentals:
Part 1: Overview of Azure subscriptions, management groups, and resources
Part 2: Azure regions, availability zones, and region pairs
Part 3: Azure resources and Azure Resource Manager
Part 4: Azure subscriptions and management groups

To get started with Azure, one of your first steps will be to create at least one Azure subscription. You'll use it to create your cloud-based resources in Azure.

Azure subscriptions

Using Azure requires an Azure subscription. A subscription provides you with authenticated and authorized access to Azure products and services. It also allows you to provision resources. An Azure subscription is a logical unit of Azure services that links to an Azure account, which is an identity in Azure Active Directory (Azure AD) or in a directory that Azure AD trusts.

An account can have one subscription or multiple subscriptions that have different billing models and to which you apply different access-management policies. You can use Azure subscriptions to define boundaries around Azure products, services, and resources. There are two types of subscription boundaries that you can use:

Billing boundary: This subscription type determines how an Azure account is billed for using Azure. You can create multiple subscriptions for different types of billing requirements. Azure generates separate billing reports and invoices for each subscription so that you can organize and manage costs.
Access control boundary: Azure applies access-management policies at the subscription level, and you can create separate subscriptions to reflect different organizational structures.

Create additional Azure subscriptions

You might want to create additional subscriptions for resource or billing management purposes. For example, you might choose to create additional subscriptions to separate:

Environments: When managing your resources, you can choose to create subscriptions to set up separate environments for development and testing, security, or to isolate data for compliance reasons. This design is particularly useful because resource access control occurs at the subscription level.
Organizational structures: You can create subscriptions to reflect different organizational structures. For example, you could limit a team to lower-cost resources, while allowing the IT department a full range. This design allows you to manage and control access to the resources that users create within each subscription.
Billing: You might want to also create additional subscriptions for billing purposes. Because costs are first aggregated at the subscription level, you might want to create subscriptions to manage and track costs based on your needs. For instance, you might want to create one subscription for your production workloads and another subscription for your development and testing workloads.
You might also need additional subscriptions because of:

Subscription limits: Subscriptions are bound to some hard limitations. For example, the maximum number of Azure ExpressRoute circuits per subscription is 10. Those limits should be considered as you create subscriptions on your account. If there's a need to go over those limits in particular scenarios, you might need additional subscriptions.

Customize billing to meet your needs

If you have multiple subscriptions, you can organize them into invoice sections. Each invoice section is a line item on the invoice that shows the charges incurred that month. For example, you might need a single invoice for your organization but want to organize charges by department, team, or project.

Depending on your needs, you can set up multiple invoices within the same billing account by creating additional billing profiles. Each billing profile has its own monthly invoice and payment method.

The following diagram shows an overview of how billing is structured. If you've previously signed up for Azure or if your organization has an Enterprise Agreement, your billing might be set up differently.

Azure management groups

If your organization has many subscriptions, you might need a way to efficiently manage access, policies, and compliance for those subscriptions. Azure management groups provide a level of scope above subscriptions. You organize subscriptions into containers called management groups and apply your governance conditions to the management groups. All subscriptions within a management group automatically inherit the conditions applied to the management group. Management groups give you enterprise-grade management at a large scale no matter what type of subscriptions you might have. All subscriptions within a single management group must trust the same Azure AD tenant.

Hierarchy of management groups and subscriptions
You can build a flexible structure of management groups and subscriptions to organize your resources into a hierarchy for unified policy and access management. The following diagram shows an example of creating a hierarchy for governance by using management groups.

Important facts about management groups

10,000 management groups can be supported in a single directory.
A management group tree can support up to six levels of depth. This limit doesn't include the root level or the subscription level.
Each management group and subscription can support only one parent.
Each management group can have many children.
All subscriptions and management groups are within a single hierarchy in each directory.

Credits: Microsoft

Azure Architecture Fundamentals: Azure resources and Azure Resource Manager

Yasir Rehman — Wed, 24 May 2023 16:09:37 +0000

You will need to be ready to start creating resources and storing them in resource groups before you create a subscription.

Resource: A manageable item that's available through Azure. Virtual machines (VMs), storage accounts, web apps, databases, and virtual networks are examples of resources.
Resource group: A container that holds related resources for an Azure solution. The resource group includes resources that you want to manage as a group. You decide which resources belong in a resource group based on what makes the most sense for your organization.

Azure resource groups

Resource groups are a fundamental element of the Azure platform. A resource group is a logical container for resources deployed on Azure. These resources are anything you create in an Azure subscription like VMs, Azure Application Gateway instances, and Azure Cosmos DB instances.

All resources must be in a resource group, and a resource can only be a member of a single resource group.
Many resources can be moved between resource groups with some services having specific limitations or requirements to move. Resource groups can't be nested.
Before any resource can be provisioned, you need a resource group for it to be placed in.

Logical grouping
Resource groups exist to help manage and organize your Azure resources. By placing resources of similar usage, type, or location in a resource group, you can provide order and organization to resources you create in Azure. Logical grouping is the aspect that you're most interested in here, because there's disorder among our resources.

Life cycle
If you delete a resource group, all resources contained within it are also deleted. Organizing resources by life cycle can be useful in nonproduction environments, where you might try an experiment and then dispose of it. Resource groups make it easy to remove a set of resources all at once.

Authorization
Resource groups are also a scope for applying role-based access control (RBAC) permissions. You can ease administration and limit access to allow only what's needed by applying RBAC permissions to a resource group.

Azure Resource Manager

Azure Resource Manager is the deployment and management service for Azure. It provides a management layer that enables you to create, update, and delete resources in your Azure account. You use management features like access control, locks, and tags to secure and organize your resources after deployment.

When a user sends a request from any of the Azure tools, APIs, or SDKs, Resource Manager receives the request. It authenticates and authorizes the request. Resource Manager sends the request to the Azure service, which takes the requested action. Because all requests are handled through the same API, you see consistent results and capabilities in all the different tools.

The following image shows the role Resource Manager plays in handling Azure requests.

All capabilities that are available in the Azure portal are also available through PowerShell, the Azure CLI, REST APIs, and client SDKs. Functionality initially released through APIs will be represented in the portal within 180 days of initial release.

Benefits of using Resource Manager
With Resource Manager, you can:

Manage your infrastructure through declarative templates rather than scripts. A Resource Manager template is a JSON file that defines what you want to deploy to Azure.
Deploy, manage, and monitor all the resources for your solution as a group, rather than handling these resources individually.
Redeploy your solution throughout the development life cycle and have confidence your resources are deployed in a consistent state.
Define the dependencies between resources so they're deployed in the correct order.
Apply access control to all services because RBAC is natively integrated into the management platform.
Apply tags to resources to logically organize all the resources in your subscription.
Clarify your organization's billing by viewing costs for a group of resources that share the same tag.

Credits: Microsoft

Azure Architecture Fundamentals: Azure regions, availability zones, and region pairs

Yasir Rehman — Wed, 24 May 2023 15:38:22 +0000

In part 1, you learned about Azure resources and resource groups. Resources are created in regions, which are different geographical locations around the globe that contain Azure datacenters.

Azure is made up of datacenters located around the globe. When you use a service or create a resource such as an SQL database or virtual machine (VM), you're using physical equipment in one or more of these locations. These specific datacenters aren't exposed to users directly. Instead, Azure organizes them into regions. As you'll see later in this post, some of these regions offer availability zones, which are different Azure datacenters within that region.

Azure regions

A region is a geographical area on the planet that contains at least one but potentially multiple datacenters that are nearby and networked together with a low-latency network. Azure intelligently assigns and controls the resources within each region to ensure workloads are appropriately balanced.

When you deploy a resource in Azure, you'll often need to choose the region where you want your resource deployed.

Note: Some services or VM features are only available in certain regions, such as specific VM sizes or storage types. There are also some global Azure services that don't require you to select a particular region, such as Azure Active Directory, Azure Traffic Manager, and Azure DNS.

A few examples of regions are West US, Canada Central, West Europe, Australia East, and Japan West. Here's a view of all the available regions as of June 2020. [Image link]

Why are regions important?
Azure has more global regions than any other cloud provider. These regions give you the flexibility to bring applications closer to your users no matter where they are. Global regions provide better scalability and redundancy. They also preserve data residency for your services.

Special Azure regions

Azure has specialized regions that you might want to use when you build out your applications for compliance or legal purposes. A few examples include:

US DoD Central, US Gov Virginia, US Gov Iowa and more: These regions are physical and logical network-isolated instances of Azure for U.S. government agencies and partners. These datacenters are operated by screened U.S. personnel and include extra compliance certifications.
China East, China North, and more: These regions are available through a unique partnership between Microsoft and 21Vianet, whereby Microsoft doesn't directly maintain the datacenters.

Regions are what you use to identify the location for your resources. There are two other terms you should also be aware of: geographies and availability zones.

Azure availability zones

You want to ensure your services and data are redundant so you can protect your information if there's a failure. When you host your infrastructure, setting up your own redundancy requires that you create duplicate hardware environments. Azure can help make your app highly available through availability zones.

What is an availability zone?
Availability zones are physically separate datacenters within an Azure region. Each availability zone is made up of one or more datacenters equipped with independent power, cooling, and networking. An availability zone is set up to be an isolation boundary. If one zone goes down, the other continues working. Availability zones are connected through high-speed, private fiber-optic networks.

Supported regions
Not every region has support for availability zones. For an updated list, see Regions that support availability zones in Azure.

Use availability zones in your apps
By co-locating your compute, storage, networking, and data resources within a zone and replicating them in other zones. You can use availability zones to run mission-critical applications and build high-availability into your application architecture. Keep in mind that there could be a cost to duplicating your services and transferring data between zones.

Availability zones are primarily for VMs, managed disks, load balancers, and SQL databases. The following categories of Azure services support availability zones:

Zonal services: You pin the resource to a specific zone (for example, VMs, managed disks, IP addresses).
Zone-redundant services: The platform replicates automatically across zones (for example, zone-redundant storage, SQL Database).
Non-regional services: Services are always available from Azure geographies and are resilient to zone-wide outages and region-wide outages.
Check the documentation to determine which elements of your architecture you can associate with an availability zone.

Azure region pairs

Availability zones are created by using one or more datacenters. There's a minimum of three zones within a single region. It's possible that a disaster could cause an outage large enough to affect even two datacenters, so Azure also creates region pairs.

What is a region pair?
Each Azure region is always paired with another region within the same geography (such as US, Europe, or Asia) at least 300 miles away. This approach allows for the replication of resources (such as VM storage) across a geography to help reduce the likelihood of interruptions due to catastrophic events. For example, events such as natural disasters, civil unrest, power outages, or physical network outages that affect multiple zones at once. If a region in a pair was affected by a natural disaster, services would automatically failover to the other region in its region pair.

Examples of region pairs in Azure are West US paired with East US and SouthEast Asia paired with East Asia.

Because the pair of regions is directly connected and far enough apart to be isolated from regional disasters, you can use them to provide reliable services and data redundancy. Some services offer automatic geo-redundant storage by using region pairs.

More advantages of region pairs:

If an extensive Azure outage occurs, one region out of every pair is prioritized to make sure at least one is restored as quickly as possible for applications hosted in that region pair.
Planned Azure updates are rolled out to paired regions one region at a time to minimize downtime and risk of application outage.
Data continues to reside within the same geography as its pair (except for Brazil South) for tax- and law-enforcement jurisdiction purposes. Having a broadly distributed set of datacenters allows Azure to provide a high guarantee of availability.

Credits: Microsoft

Azure Architecture Fundamentals: Overview of Azure subscriptions, management groups, and resources

Yasir Rehman — Wed, 24 May 2023 15:14:58 +0000

Let's say that you work as a developer for a successful company, and your company's Chief Technology Officer recently decided to adopt Azure as the cloud computing platform. You're currently in the planning stages for the migration. Before you begin the migration process, you decide to study Azure concepts, resources, and terminology to ensure your migration is a success.

As part of your research, you need to learn the organizing structure for resources in Azure, which has four levels: management groups, subscriptions, resource groups, and resources.

The following image shows the top-down hierarchy of organization for these levels.

Screenshot of the hierarchy for objects in Azure.

Having seen the top-down hierarchy of organization, let's describe each of those levels from the bottom up:

Resources: Resources are instances of services that you create, like virtual machines, storage, or SQL databases.
Resource groups: Resources are combined into resource groups. Resource groups act as a logical container into which Azure resources like web apps, databases, and storage accounts are deployed and managed.
Subscriptions: A subscription groups together user accounts and the resources that have been created by those user accounts. For each subscription, there are limits or quotas on the amount of resources that you can create and use. Organizations can use subscriptions to manage costs and the resources that are created by users, teams, or projects.
Management groups: These groups help you manage access, policy, and compliance for multiple subscriptions. All subscriptions in a management group automatically inherit the conditions applied to the management group.

Credits: Microsoft