DEV Community: Yusuf Isah

Chapter 5 - Kubernetes Labels and Annotations

Yusuf Isah — Fri, 06 Sep 2024 17:11:14 +0000

Introduction

In Kubernetes, labels and annotations are essential tools for managing and organizing resources. Labels provide a way to attach metadata to objects, which can be used for grouping, filtering, and selecting subsets of resources. Annotations, on the other hand, allow you to attach non-identifying metadata to objects, enabling you to store additional information that can be accessed by external tools or processes.

In this chapter, we'll explore the concepts of labels and annotations, how to apply and modify them, and how they play a vital role in Kubernetes architecture.

Labels
- Applying Labels
- Modifying Labels
- Label Selectors
- Label Selectors in API Objects
- Labels in Kubernetes Architecture
Annotations
Conclusion

Labels

Labels are key-value pairs that are attached to Kubernetes objects, such as Pods, Nodes, Services, and Deployments. They are used to categorize and select subsets of objects based on criteria you define.

Applying Labels

In this section, we'll create two deployments (a way to create an array of Pods) and attach some labels to them. We’ll take two apps (called egypt and tanzania) and have one environment and one version for each.

First, create the tanzania-staging deployment and set the ver, app, and env labels:

tanzania-staging.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tanzania-staging
  labels:
    app: tanzania
    env: staging
    ver: "1"
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tanzania
      env: staging
      ver: "1"
  template:
    metadata:
      labels:
        app: tanzania
        env: staging
        ver: "1"
    spec:
      containers:
      - name: tanzania-staging-container
        image: dockeryu853/greetings:tanzania

Finally, create the egypt-production deployment.

egypt-production.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: egypt-production
  labels:
    app: egypt
    env: production
    ver: "2"
spec:
  replicas: 1
  selector:
    matchLabels:
      app: egypt
      env: production
      ver: "2"
  template:
    metadata:
      labels:
        app: egypt
        env: production
        ver: "2"
    spec:
      containers:
      - name: egypt-production-container
        image: dockeryu853/greetings:egypt

After applying both manifests, you should have two deployments in your Kubernetes cluster - tanzania-staging and egypt-production.

To see the labels associated with your deployments, simply run:

kubectl get deployment --show-labels

Modifying Labels

Labels can be modified using the kubectl label command. Here's how you can add or update a label on an existing object:

kubectl label deployment tanzania-staging env=test --overwrite

This command updates the environment label on the tanzania-staging deployment to test.

You can confirm this update by running the command below:

kubectl get deployment --show-labels

Label Selectors

Label selectors allow you to filter and select resources based on their labels. They are commonly used in Kubernetes to specify which objects should be targeted by a particular operation.

For example, to list all deployments with the label app=egypt, you can use the kubectl get command with the -l option:

kubectl get deployment -l app=egypt

You can also use the --selector flag to list which resources have a particular label in your Kubernetes cluster. For example, if you want to list only deployments that have the ver label set to 2, you can simply run:

kubectl get deployment --selector="ver=2"

Label Selectors in API Objects

Label selectors are also used in API objects like Services, ReplicaSets, and Deployments to define which Pods they should manage. For example, in the egypt-production.yaml manifest we created, the selector field uses label selectors to target Pods with the app=egypt label.

Labels in Kubernetes Architecture

Labels are integral to the Kubernetes architecture. They are used by the system to determine how to manage resources, such as deciding which Nodes a Pod should run on, or which Pods should receive traffic from a Service.

Annotations

Annotations are another form of metadata that can be attached to Kubernetes objects. Unlike labels, annotations are not used for selection or grouping. Instead, they are used to store non-identifying information that might be needed by tools or processes.

Annotations are key-value pairs, just like labels, but their purpose is different. Here’s an example of applying annotations to a Pod:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  annotations:
    information: "This is my first pod"
    group: "devops"
spec:
  containers:
    - name: my-container
      image: nginx

In this example, the Pod has two annotations: information and group. These annotations provide additional context about the Pod but are not used for selection or filtering.

Annotations are commonly used to store information such as build details, release versions, or URLs for documentation.

Conclusion

In this chapter, we explored the power of labels and annotations in Kubernetes. By understanding how to apply, modify, and utilize these metadata mechanisms, you'll be able to effectively organize and manage your Kubernetes resources. Stay tuned for the next chapter in our Kubernetes series!

Feel free to leave comments and share this article. Follow my blog for more insights on Kubernetes!

Chapter 5 - Building Docker Images

Yusuf Isah — Fri, 06 Sep 2024 16:22:13 +0000

Introduction

To truly harness the power of Docker, we need to create our own custom images. This chapter will take you into the world of image creation, covering the essential topics of building images from Dockerfiles, tagging images for easy management, and utilizing multi-stage builds for efficient development. Whether you're building a simple web application or a complex microservices architecture, understanding how to build Docker images is a crucial step in unlocking the full potential of containerization.

In this chapter, we will be containerizing a simple Go application called "greetings-app". All the files and directories you need to follow along with this tutorial can be found on my GitHub repository. Simply log into your GitHub repository and search for either "yusbuntu/greetings-tanzania" or "yusbuntu/greetings-egypt". Copy the URL of whichever one you choose and clone the repository on your local machine using the "git clone [url_of_repository_you_want_to_clone]" command.

Building Images From a Dockerfile
Tagging Images
Multi-stage Builds
Conclusion

Building Images From a Dockerfile

After navigating into the project directory of the repository you just cloned, you should see the files and directory below after running the ls command:

The greetings-app which is colorized green, is the Go executable that is created after building the application. You can run this executable by simply typing on your terminal:

./greetings-app

Next, go to your browser and type localhost:8080/ to see the application in its full glory :). To terminate the application, hold the ctrl button and press the c button on your keyboard. Now that you have seen what the greetings-app looks like, let's build a Docker image of this application using a Dockerfile. But first, let's take a look at the contents of our Dockerfile:

nano Dockerfile

In summary, this Dockerfile is building a Docker image for a Go application named greetings-app that listens on port 8080. The image is built using the official Golang 1.18 image as the base, and the resulting image contains the compiled Go binary and exposes the necessary port.

To build the Docker image, use the following command:

docker build -t greetings-app .

The -t flag tags the image with a name (greetings-app), and the . at the end specifies the build context, typically the current directory.

Tagging Images

Tagging images is a crucial part of managing and deploying Docker images. Tags help you identify different versions of your images. To add a tag to an image, you can use the docker tag command:

docker tag greetings-app greetings-app:v1.0

This command tags the greetings-app image with the version v1.0.

Finally, let's start a container using the image:

docker run -d -p 8080:8080 greetings-app:v1.0

In the command above, the-d flag runs the container in detached or daemon mode. The -p flag exposes port 8080 on the container to port 8080 on the host machine. When you run docker ps, you should see your container running. To stop the container, use the docker stop [container_ID] command.

You can also pass environment variables to the greetings-app container. To do this, use the -e flag. For example:

docker run -d -e GREETING="Hello Docker Champ!" -p 8080:8080 greetings-app:v1.0

Multi-stage Builds

Multi-stage builds are an advanced feature in Docker that allow you to use multiple "FROM" statements in your Dockerfile. This helps in reducing the final image size by copying only the necessary files from intermediate/temporary stages. The image we created earlier is about 984MB in size. This is not ideal for production due to the reasons below:

Slower Deployment: Larger images take longer to download and deploy, which means slower startup times for your application.
Increased Storage: Larger images consume more storage space on your servers, which can lead to increased costs.
Security Risks: Larger images may contain unnecessary packages or dependencies, increasing the attack surface for potential security vulnerabilities.
Resource Intensive: Larger images typically require more resources (CPU, memory) to run, which can impact performance and scalability.

To solve these problems, let's re-build the Docker image for our greetings app using a multi-stage build. The Dockerfile we will use to achieve this is titled Dockerfile.multi in the project directory. Before building the Docker image, let's take a look at its contents:

The goal of this multi-stage build is to:

Use the Golang image to build the application, taking advantage of its build tools and dependencies.
Use a smaller, more light-weight Debian image for the final stage, which will run the application.
Keep the final image size small by only copying the necessary files from the Build Stage.

This approach allows for efficient and optimized image creation, reducing the final image size and improving deployment times.

To build the Docker image from this Dockerfile, simply run:

docker build -t greetings-app:v2.0 -f Dockerfile.multi .

Lets breakdown the components of the command above:

docker build: This is the command to build a Docker image.
-t greetings-app:v2.0: This option tags the image with the name greetings-app and version v2.0. This makes it easy to identify and reference the image later.
-f Dockerfile.multi: This option specifies the Dockerfile to use for the build. In this case, it's Dockerfile.multi instead of the default Dockerfile. This allows you to have multiple Dockerfiles for different build scenarios.
.: This is the context directory for the build. The . refers to the current directory, which means Docker will look for the Dockerfile.multi file in the current directory and use the files in the current directory as the build context.

After building the image, If you run docker images you will notice that this new image is only about 78.8MB in size. That is a massive size difference compared to the 984MB size of the previous image.

As an exercise, start a container using this new image.

Conclusion

In this chapter, we explored the fundamentals of building Docker images from Dockerfiles, and tagging them for versioning. We also highlighted the importance of a small image size, and utilized multi-stage builds for efficient image creation. Through consistent practice, you'll become proficient in creating high-quality Docker images that meet the unique needs of your applications.

Feel free to leave comments and share this article. Follow my blog for more insights on Docker!

Chapter 5 - Cloning a Remote Repository

Yusuf Isah — Thu, 05 Sep 2024 17:28:12 +0000

Introduction

Cloning a remote repository is an important Git operation that allows you to create a local copy of a repository hosted on a remote server, such as GitHub, GitLab, or Bitbucket. In this chapter, we'll explore the steps for cloning a remote repository.

What is Cloning?
- Why Clone a Repository?
How to Clone a Remote Repository
Conclusion

What is Cloning?

Cloning a repository creates a new local repository that is an exact copy of the remote repository. This includes all files, commits, and branches. Cloning is a one-time operation that creates a permanent connection between your local repository and the remote repository. This connection allows you to:

Pull changes from the remote repository to your local copy using git pull.
Send your local changes to the remote repository using git push.
Keep track of branches between your local and remote repositories.

Why Clone a Repository?

Collaboration: Cloning repositories allows you to contribute to open-source projects or collaborate with others.
Backup: You can clone your repository to create a backup of your project.

How to Clone a Remote Repository

Get the Repository URL: Go to Github and search for any project of your choice. Click on the code button and then copy the URL of the repository.
Open Terminal or Command Prompt: Open a terminal or command prompt on your local machine.
Use the Git Clone Command: Run the command git clone; e.g.,

   git clone https://github.com/kubernetes/kubernetes.git

Once you clone a project and you navigate into it using the cd command, you can use git log to see the previous commits associated with the project.

Conclusion

In conclusion, cloning a remote repository is a fundamental skill for any developer, enabling seamless collaboration and version control. By mastering the art of cloning, you can effortlessly create local copies of remote repositories, track changes, and contribute to projects with ease. With this guide, you're now equipped to clone confidently.

Feel free to comment and share this article. Please follow my blog for more insights on Git and Github!

Chapter 5 - TCP/IP Protocol Suite

Yusuf Isah — Thu, 05 Sep 2024 17:08:15 +0000

Introduction

The TCP/IP protocol suite is the foundation of Internet and network communication. It defines how data is transmitted over networks and ensures reliable and secure communication between devices. This chapter covers the common protocols within the TCP/IP suite. We'll also delve into port numbers, including well-known port numbers and their associated services.

Common Protocols
- TCP
- UDP
- IP
- ICMP
- ARP
Port Numbers
- Well-known port numbers and their services
Conclusion

Common Protocols

TCP

TCP (Transmission Control Protocol) is a connection-oriented protocol that ensures reliable data transmission between devices. It establishes a connection before transmitting data, checks for errors, and guarantees the delivery of data in the correct order.

UDP

UDP (User Datagram Protocol) is a connectionless protocol that offers fast but unreliable data transmission. It is used for applications where speed is crucial and error correction is not necessary, such as video streaming and online gaming.

IP

IP (Internet Protocol) is responsible for addressing and routing packets of data so they can travel across networks and arrive at the correct destination. IP addresses uniquely identify devices on a network.

ICMP

ICMP (Internet Control Message Protocol) is used for error reporting and network diagnostics. It sends messages about network issues back to the sender, such as unreachable destinations or packet loss.

ARP

ARP (Address Resolution Protocol) is used to map IP addresses to physical MAC addresses in a local network. This allows devices to communicate within the same local network segment.

Port Numbers

Port numbers are used to identify specific services and applications on a device. They facilitate communication between devices by ensuring that data is sent to the correct application.

Well-known port numbers and their services

Port numbers are assigned by the Internet Assigned Numbers Authority (IANA) for use by standard network services. Here are some examples:

HTTP (Port 80): The default port for the Hypertext Transfer Protocol, used for web traffic.
HTTPS (Port 443): The default port for secure web traffic using the Hypertext Transfer Protocol Secure.
SSH (Port 22): The default port for Secure Shell, used for secure remote access to devices.
FTP (Port 21): The default port for the File Transfer Protocol, used for transferring files between devices.
SMTP (Port 25): The default port for the Simple Mail Transfer Protocol, used for sending emails.
DNS (Port 53): The default port for the Domain Name System, used for resolving domain names to IP addresses.

Conclusion

Understanding the TCP/IP protocol suite and port numbers is essential for managing and troubleshooting network communication. These protocols ensure reliable and efficient data transmission, while port numbers help direct data to the correct application or service.

Feel free to leave comments and share this article. Follow my blog for more insights on Networking!

Chapter 5 - Linux File Permissions and Ownership

Yusuf Isah — Thu, 05 Sep 2024 16:40:31 +0000

Introduction

In Linux, permissions and ownership play a crucial role in controlling access to files and directories. Understanding permissions and ownership is essential for maintaining security and organization in your Linux system. In this chapter, we'll delve into the world of permissions and ownership, exploring how to understand, change, and manage them effectively.

Understanding Permissions
Changing Permissions
- chmod: Change File Modes
  - Using Symbolic Representation
  - Using Octal Values
Changing Ownership
- chown: Change File Owner and Group
Conclusion

Understanding Permissions

Linux permissions determine what actions users can perform on files and directories. There are three primary permissions:

Read (r): This allows users to view file contents or list directory contents.
Write (w): This enables users to modify file contents or create/delete files in a directory.
Execute (x): This allows users to execute files (e.g., run programs) or access directories.

These permissions are assigned to three types of users:

Owner: This is the user who created the file or directory.
Group: This refers to a group of users with shared permissions.
Other This refers to all other users on the system.

Permissions can also be represented using octal values:

r = 4
w = 2
x = 1

To see the permissions for the files and folders in your current working directory, run:

ls -la

For example, a file permission of rwxr-xr-- translates to:

Owner: read, write, execute (rwx)
Group: read, execute (r-x)
Others: read (r--)

Changing Permissions

The chmod command is used to change the permissions of a file or directory.

chmod: Change File Modes

To change permissions using chmod, you can use either symbolic representation or octal values.

Using Symbolic Representation

For example, to add execute permission for the owner, run:

chmod u+x filename

To remove write permission for the group, run:

chmod g-w filename

To set read and execute permissions for others, run:

chmod o=rx filename

Using Octal Values

Set permissions to rwxr-xr-x (755)

chmod 755 filename

The rwxr-xr-x above can be broken down into three parts:

rwx (owner permissions)
r-x (group permissions)
r-x (others permissions)

Each part can be converted to a numerical value using the following mapping:

r (read) = 4
w (write) = 2
x (execute) = 1
- (no permission) = 0

So, let's convert each part:

rwx (owner) = 4 + 2 + 1 = 7
r-x (group) = 4 + 0 + 1 = 5
r-x (others) = 4 + 0 + 1 = 5

Now, combine the three numerical values into a single octal number: 755

Set permissions to rw-r--r-- (644):

  chmod 644 filename

Changing Ownership

The chown command is used to change the ownership of a file or directory. Ownership can be assigned to a user and a group.

chown: Change File Owner and Group

To change the owner and group of a file or directory, use the following syntax:

Change the owner of a file:

    chown username filename

Change the owner and group of a file:

  chown username:groupname filename

Change the group of a file

  chown :groupname filename

For example:

Change the owner to Mike:

  sudo chown Mike file.txt

Change the owner to alice and the group to developers:

  sudo chown alice:developers file.txt

Conclusion

Understanding and managing permissions and ownership in Linux is essential for controlling access to files and directories. By using commands like chmod and chown, you can ensure that your system's security and access controls are properly maintained.

Feel free to leave comments and share this article. Follow my blog for more insights on Linux!

Chapter 4 - Kubernetes Pods

Yusuf Isah — Tue, 27 Aug 2024 14:34:01 +0000

Introduction

In Kubernetes, the smallest and simplest unit of deployment is a Pod. Pods represent a single instance of a running process in your cluster. They encapsulate one or more containers, their storage resources, a unique network IP, and options that govern how the containers should run. This chapter will explore the concept of Pods, how to create and manage them, and how to ensure their health and performance in a Kubernetes cluster.

Pods in Kubernetes
- Key Points About Pods
The Pod Manifest
- Creating a Pod
- Creating a Pod Manifest
Running Pods
- Listing Pods
- Pod Details
- Deleting a Pod
Accessing Your Pod
- Getting More Information with Logs
- Running Commands in Your Containers with exec
- Copying Files to and From Containers
Health Checks
- Liveness Probe
- Readiness Probe
Resource Management
- Resource Requests: Minimum Required Resources
- Capping Resource Usage With Limits
Persisting Data with Volumes
- Using Volumes with Pods
Putting it all Together
Conclusion

Pods in Kubernetes

In Kubernetes, a Pod is the basic execution unit that comprises one or more containers. The term, Pod, is a nod to the Docker whale theme, as it refers to a group of whales swimming together. Similarly, a Pod groups containers together to work as a single, cohesive unit that can share resources and dependencies, communicate with each other, and be co-scheduled.

Key Points About Pods:

Single Unit of Deployment: Pods are the smallest deployable units in Kubernetes.
Shared Context: Containers within a Pod share the same network namespace, Inter-Process Communication (IPC) namespace, and can share storage volumes.
Lifecycle: Pods are created, scheduled, and managed by the Kubernetes control plane.

The Pod Manifest

A Pod manifest is a YAML file that defines the desired configuration of a Pod, utilizing Kubernetes' declarative approach. This means you specify the ideal state of your Pod in the manifest file, and then Kubernetes works to ensure that the actual state matches your declared intentions.

Creating a Pod

You can create a Pod by defining a manifest in YAML and applying it to your Kubernetes cluster.

Creating a Pod Manifest

To create a Pod manifest:

Define the apiVersion, kind, and metadata sections.
Under spec, specify the containers that the Pod should run.

Example Manifest:

apiVersion: v1
kind: Pod
metadata:
  name: greetings-pod
spec:
  containers:
  - name: greetings-container
    image: dockeryu853/greetings:1.1
    ports:
    - containerPort: 8080

Let's name the manifest above greetings.yaml. To apply the manifest to your Kubernetes cluster, run:

kubectl apply -f greetings.yaml

Running Pods

Once a Pod is created, you can perform various operations to manage and inspect it.

Listing Pods

Run the command below to list all Pods in your cluster:

kubectl get pods

You can see the name of the Pod (greetings-pod) that we gave it in the YAML file. In addition to the number of ready containers (1/1), the output also shows the status, the number of times the Pod was restarted, and the age of the Pod.

If you ran this command immediately after the Pod was created, you might see:

ContainerCreating means that Kubernetes has received the YAML manifest and is in the process of creating the containers specified in the manifest. If what you see in the status field is Pending, it means that the Pod has been submitted but hasn’t been scheduled yet. If a more significant error occurs, such as an attempt to create a Pod with a container image that doesn’t exist, it will also be listed in the status field.

To see a list of the pods running in your Kubernetes cluster and observe dynamic changes in real-time, run:

kubectl get pods -w

The command above allows you to observe the dynamic changes in your Pod landscape without needing to repeatedly run the kubectl get pods command. Press Ctrl+C to exit watch mode.

In addition, adding -o wide to any kubectl command will print out slightly more information (while still keeping the information to a single line).

kubectl get pods -o wide

Pod Details

To get detailed information about a specific Pod, run:

kubectl describe pod <pod-name>

Deleting a Pod

To delete a Pod, run:

kubectl delete pod <pod-name>

NB: When you delete a Pod, any data stored in the containers associated with that Pod will be deleted as well. If you need to persist data across multiple instances of a Pod, you need to use Persistent Volumes, described at the end of this chapter.

Accessing Your Pod

Kubernetes provides several ways to interact with and troubleshoot Pods.

Getting More Information with Logs

To view the logs of a container in a Pod, run:

kubectl logs <pod-name> -c <container-name>

Running Commands in Your Containers with exec

To execute a command in a running container:

kubectl exec -it <pod-name> -- <command>

To exec into the greetings-pod, run the command below:

kubectl exec -it greetings-pod /bin/sh

To exit, simply run the exit command inside the pod.

Copying Files to and From Containers

To copy files between your local system and a container:

kubectl cp <file-path> <pod-name>:/path/in/container
kubectl cp <pod-name>:/path/in/container <local-path>

Health Checks

Kubernetes allows you to define health checks to ensure your containers are running as expected.

Liveness Probe

The liveness probe checks if a container is still running. If the check fails, Kubernetes restarts the container.

Example Liveness Probe:

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 3

The Liveness Probe configuration above will:

Wait 3 seconds after the container starts.
Send an HTTP GET request to http://localhost:8080/healthz every 3 seconds.
If the request fails or returns an error, Kubernetes will consider the container unhealthy and restart it.

Readiness Probe

The readiness probe checks if a container is ready to serve traffic.

Example Readiness Probe:

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 3

The readiness Probe configuration above will:

Wait 3 seconds after the container starts.
Send an HTTP GET request to http://localhost:8080/ready every 3 seconds.
If the request succeeds (returns a 200 OK response), the container is considered ready to receive traffic.
If the request fails or returns an error, the container is not considered ready, and Kubernetes will not send traffic to it.

Resource Management

You can specify the resources that your Pod's containers require, ensuring they run efficiently.

Resource Requests: Minimum Required Resources

Resource requests define the minimum amount of resources a container needs. These requests serve as a hint to the Kubernetes scheduler to ensure the Pod is placed on a node with sufficient resources. If the node doesn't have enough resources, the Pod won't be scheduled to that node.

Example:

  resources:
    requests:
      memory: "64Mi"
      cpu: "250m"

The pod in the YAML manifest above is requesting:

At least 64 MB of memory to be allocated
At least 250 millicores (or 0.25 cores) of CPU processing power

Note that these are requests, not limits. The container can use more resources if available, but it's guaranteed to get at least the requested amount.

Capping Resource Usage With Limits

Resource limits specify the maximum resources a container can use. These limits prevent the container from consuming excessive resources and impacting other workloads running on the same node. If the container tries to use more resources than specified, Kubernetes will take action to enforce the limits, such as terminating the container if it exceeds the memory limit.

Example:

resources:
  limits:
    memory: "128Mi"
    cpu: "500m"

The Pod in the YAML manifest above is restricted to:

Using no more than 128 MB of memory
Using no more than 500 millicores (or 0.5 cores) of CPU processing power

Persisting Data with Volumes

Kubernetes Volumes provide persistent storage to Pods, ensuring data is retained across restarts.

Using Volumes with Pods

apiVersion: v1
kind: Pod
metadata:
  name: greetings-pod
spec:
  containers:
  - name: greetings-container
    image: dockeryu853/greetings:1.1
    ports:
    - containerPort: 8080
    volumeMounts:
    - name: static-files
      mountPath: /static
  volumes:
  - name: static-files
    hostPath:
      path: /home/yusbuntu/static
      type: Directory

In the YAML manifest above, the VolumeMount is trying to achieve the following:

It's mounting a volume named static-files into the container at the path /static.
The static-files volume is defined in the volumes section and is of type hostPath, which means it's a directory on the host machine (the machine running the Kubernetes node).
The path field specifies the directory on the host machine (in this case, my Minikube Virtual Machine), /home/yusbuntu/static, which will be mounted into the container. Make sure to change /home/yusbuntu to your home directory or any other path you prefer.

As stated earlier, if you are using Minikube, you have to create this directory inside Minikube and not on your computer. Below are the steps to follow to create the directory inside Minikube.

minikube ssh
sudo mkdir -p /home/your_user_name/static

Make sure to change your_user_name to your actual user name.

Putting it all Together

Kubernetes offers a comprehensive set of features, including persistent volumes for data storage, readiness and liveness probes for health monitoring, and resource restrictions for efficient resource allocation, making it an ideal platform for running stateful applications with high reliability and consistency. The manifest below puts this all together.

apiVersion: v1
kind: Pod
metadata:
  name: greetings-pod
spec:
  containers:
  - name: greetings-container
    image: dockeryu853/greetings:1.1
    ports:
    - containerPort: 8080
    volumeMounts:
    - name: static-files
      mountPath: /static
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"
      requests:
        memory: "64Mi"
        cpu: "250m"
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3
  volumes:
  - name: static-files
    hostPath:
      path: /home/yusbuntu/static
      type: Directory

NB: Before applying the greetings.yaml manifest above, make sure to change the path (/home/yusbuntu/static) in your manifest to the path you specified in your Minikube VM.

Next, apply the manifest:

kubectl apply -f greetings.yaml

Follow the steps below to see the contents of the container:

Once the container starts running, run the command below:
```
kubectl get pods -o wide
```

As you can see from the image above, my IP is 10.244.0.214
Next, SSH into Minikube:
```
minikube ssh
```
Run the command below to see the contents of the container running inside the pod:

 curl http://10.244.0.214:8080

Conclusion

Understanding Pods is fundamental to working with Kubernetes. They encapsulate your application's containers, along with their storage, network, and configuration, into a single deployable unit. By mastering Pods and their associated operations, you can effectively manage your applications in a Kubernetes environment.

Feel free to leave comments and share this article. Follow my blog for more insights on Kubernetes!

Chapter 4 - Dockerfiles

Yusuf Isah — Tue, 27 Aug 2024 10:00:47 +0000

What is a Dockerfile?
- Understanding Dockerfiles as Blueprints for Building Images.
Creating a Dockerfile
- Basic Syntax and Structure
- Common Instructions
- Optimizing Image Builds
Conclusion

What is a Dockerfile?

A Dockerfile is a text file that contains instructions for building a Docker image. It's a blueprint for creating an image, specifying the base image, dependencies, files, and commands required to create a container. By using a Dockerfile, you automate the process of creating an image. This makes it easier to build, test, and deploy applications in a reliable and efficient manner.

Understanding Dockerfiles as Blueprints for Building Images.

Think of a Dockerfile as a recipe for building an image. Just as a recipe outlines ingredients and steps to prepare a dish, a Dockerfile outlines the steps to build an image. This blueprint approach allows for reproducible and consistent image builds.

Creating a Dockerfile

A Dockerfile consists of instructions, each starting with a keyword (e.g., FROM, RUN, COPY). The instructions are executed in order, from top to bottom. Just like when you add new ingredients to a dish you are preparing, each executed instruction in a Dockerfile adds or creates a new layer in the image.

Basic Syntax and Structure

A Dockerfile starts with the FROM instruction, specifying the base image. Each instruction is followed by arguments, specifying the action to take.
Instructions are executed in order, from top to bottom. Finally, comments in a Dockerfile start with a # symbol.

Common Instructions

Here are some common instructions you might find in a Dockerfile:

FROM: Specifies the base image. A base image is a pre-built Docker image that serves as the foundation for your new image. By using a base image, you don't need to start from scratch. You can focus on adding your own customizations, like your application code, dependencies, and settings, to create a new image.
RUN: Executes a command during the build process.
COPY: Copies files from the build context into the image. When you run the docker build command, Docker looks at the files and directories in the current directory (or the directory you specify) and uses them to create the image. This directory is called the build context.
CMD: Specifies the default command to run when the container starts.
ENTRYPOINT: Specifies the command to run when the container starts, allowing for parameters.
EXPOSE: Exposes a port to the host machine. in other words, the EXPOSE command exposes a port from a container to the host machine (the machine running the Docker daemon).

From the list of common instructions above, you might be wondering what the differences between the CMD and ENTRYPOINT commands are. Below are some key differences between them:

CMD	ENTRYPOINT
Sets the default command and arguments to run when the container starts	Sets the command that should always be run when the container starts
Can be overridden when running the container with a custom command	Cannot be overridden (easily) when running the container
Think of it as the "default" or "fallback" command. CMD is like a suggestion: "Hey, you might want to run this command."	Think of it as the "required" or "mandatory" command. ENTRYPOINT is like a requirement: "You must run this command."

Here is an example of a Dockerfile:

# Use an official Node.js image as the base
FROM node:18

# Set the working directory
WORKDIR /app

# Copy package.json and package-lock.json
COPY package*.json ./

# Install dependencies
RUN npm install

# Copy the rest of the application
COPY . .

# Expose the port
EXPOSE 5000

# Run the command when the container starts
CMD ["npm", "start"]

The Dockerfile above creates a Node.js image, installs dependencies, copies the application code, exposes port 5000, and sets the default command to run when the container starts.

Optimizing Image Builds

When building Docker images, speed and efficiency are crucial. A well-structured Dockerfile can significantly reduce image build times, making development and deployment processes more agile. When you build an image, Docker stores the results of each step (like installing dependencies) in a cache. If you make changes to your code, Docker can reuse the cached results for the steps that didn't change (like dependencies). This saves time and speeds up the build process. To take advantage of Docker's caching mechanism and reduce image build times, structure your Dockerfile in this order:

Base image (FROM): Start with the base image, as it rarely changes.
Dependencies (COPY): Install dependencies next, as they change less frequently than application code.
Application code (COPY): Copy application code last, as it changes most frequently. Unless neccessary, Use COPY instead of ADD to avoid unnecessary layer creation.
Commands (CMD, ENTRYPOINT, etc.): Finish with commands that set up the container.

This order maximizes caching because If the base image or dependencies don't change, Docker can reuse cached layers.

Conclusion

In conclusion, Dockerfiles are the blueprint for building Docker images, and mastering them is crucial for efficient containerization. By understanding the instructions, optimizing image builds, and leveraging caching, you can create lightweight, portable, and scalable images that streamline your development and deployment processes.

Feel free to leave comments and share this article. Follow my blog for more insights on Docker and DevOps!

Chapter 4 - DNS (Domain Name System)

Yusuf Isah — Tue, 27 Aug 2024 09:21:52 +0000

Introduction

The Domain Name System (DNS) is a critical component of the internet, responsible for translating human-readable domain names into IP addresses that computers use to identify each other on the network. This chapter covers the basics of DNS, including how it works and the different types of DNS records.

What is DNS?
- Understanding how domain names are translated to IP addresses
DNS Records
- Common record types: A, AAAA, CNAME
Conclusion

What is DNS?

DNS is often referred to as the "phone book of the internet." It enables users to access websites using easy-to-remember domain names instead of difficult-to-remember IP addresses.

Understanding how domain names are translated to IP addresses

When you type a domain name into your browser, the DNS system translates it into the corresponding IP address through a process called DNS resolution. Here's how it works:

DNS Query: The browser sends a query to a DNS resolver to find the IP address associated with the domain name.
Recursive Resolution: The DNS resolver queries multiple DNS servers, starting with the root DNS server, then the top-level domain (TLD) server (e.g., .com), and finally, the authoritative DNS server for the specific domain.
Response: The authoritative DNS server responds with the IP address, which is then sent back to the browser.
Connection: The browser connects to the web server using the IP address and loads the website.

DNS Records

DNS records are used to store various types of data about a domain. Each record type serves a different purpose.

Common record types: A, AAAA, CNAME

A Record (Address Record): This maps a domain name to an IPv4 address. For example, the domain name example.com could be mapped to an IPv4 address 192.0.2.1.
AAAA Record (IPv6 Address Record): This maps a domain name to an IPv6 address. For example, the domain name example.com could be mapped to an IPv6 address 2001:0db8:85a3:0000:0000:8a2e:0370:7334.
CNAME Record (Canonical Name Record): This maps a domain name to another domain name, creating an alias. This is useful for pointing multiple subdomains to the same IP address indirectly. For example, the subdomain www.example.com could be mapped to another domain name, example.org. In this example, www.example.com is the alias, and example.org is the canonical name (or the target). The CNAME record essentially tells DNS resolvers that www.example.com should be resolved to the same IP address as example.org.

Conclusion

DNS is a foundational technology that makes the internet user-friendly by allowing the use of domain names instead of numerical IP addresses. Understanding DNS and its various record types is crucial for managing and troubleshooting network and domain-related issues.

Feel free to leave comments and share this article. Follow my blog for more insights on Networking!

Chapter 4 - Gitignore

Yusuf Isah — Tue, 27 Aug 2024 08:42:32 +0000

What is Gitignore?
- Why use Gitignore?
How to use Gitignore
Conclusion
- Best Practices

What is Gitignore?

Gitignore is a file in Git repositories that tells Git which files or directories to ignore and not track. It's a crucial file for managing your project's repository, ensuring that unnecessary files don't clutter your version control system.

Why use Gitignore?

Here are a few reasons you might want to include a Gitignore file in your project's directory:

Exclude sensitive information: Keep sensitive files like API keys, passwords, or personal data out of your repository.
Reduce repository size: Ignore large files, logs, or temporary files that don't need version control.
Enhance Collaboration: Prevent team members from committing unnecessary files, reducing conflicts and merge issues.

How to use Gitignore

In your repository's root directory, create a file named .gitignore (note the dot prefix).

   touch .gitignore

Open the Gitignore file you created using your preferred text editor, e.g., nano.

   nano .gitignore

Inside this file, add files and/or directories you do not want committed to Github. Below is an imaginary Gitignore file:

   # Ignore log files
   *.log

   # Ignore node_modules directory
   node_modules/

   # Ignore environment configuration files
   *.env

   # Ignore temp directory and its contents
   temp/

   # Ignore a file called secrets.txt
   secrets.txt

The imaginary .gitignore file above tells Git to ignore:

All files with the .log extension
The entire node_modules directory
Environment configuration files (*.env)
The temp directory and its contents
A file named secrets.txt

Conclusion

Best Practices

Keep your .gitignore up-to-date: Regularly review and update your .gitignore file as your project evolves.
Communicate with your team: Ensure all team members understand what's being ignored and why.

By mastering Gitignore, you'll maintain a clean, efficient, and secure repository, making collaboration and version control a breeze.

Feel free to comment and share this article. Please follow my blog for more insights on Git and GitHub!

Chapter 4 - Text Editors

Yusuf Isah — Tue, 27 Aug 2024 08:14:25 +0000

Introduction

Text editors are essential tools in Linux for editing configuration files, writing scripts, and even developing software. In this chapter, we will explore some of the most commonly used text editors and their basic usage.

Common Text Editors
- nano
  - Features of nano:
  - Installation
- vim
  - Features of vim:
  - Installation
Basic Usage
- Opening Files
- Editing Files
- Saving Files
Conclusion

Common Text Editors

Linux offers a variety of text editors, each with its own unique features and user interface. Two of the most commonly used text editors are nano and vim.

nano

nano is a simple, user-friendly text editor that is ideal for beginners. It provides an easy-to-use interface with straightforward commands displayed at the bottom of the screen.

Features of nano:

Easy to learn and use
Commands are displayed at the bottom of the screen
Suitable for quick edits and small files

Installation

NB: nano is installed by default on many Linux distributions, so you might not need to install it explicitly. You can check if it is already installed by running nano --version in your terminal. If it is not installed, here are the commands for installing nano on various Linux distributions.

Debian/Ubuntu:
```
sudo apt-get install nano
```
Fedora:
```
sudo dnf install nano
```
Red Hat Enterprise Linux (RHEL)/CentOS:
```
sudo yum install nano
```
openSUSE:
```
sudo zypper install nano
```
Arch Linux:
```
sudo pacman -S nano
```

vim

vim (Vi IMproved) is a powerful and highly configurable text editor. It is an enhanced version of the older vi editor. vim offers a wide range of advanced features and flexibility, but it has a steeper learning curve compared to nano.

Features of vim:

Highly customizable
Supports multiple modes (normal, insert, visual, and command-line)
Extensive plugin ecosystem
Suitable for complex editing tasks and large projects

Installation

NB: vim is installed by default on many Linux distributions, so you might not need to install it explicitly. You can check if it is already installed by running vim --version in your terminal. If it is not installed, here are the commands for installing vim on various Linux distributions.

Debian/Ubuntu:
```
sudo apt-get install vim
```
Fedora:
```
sudo dnf install vim
```
Red Hat Enterprise Linux (RHEL)/CentOS:
```
sudo yum install vim
```
openSUSE:
```
sudo zypper install vim
```
Arch Linux:
```
sudo pacman -S vim
```

Basic Usage

Now that we are familiar with nano and vim, let's explore their basic usage, including how to open, edit, save, and close files.

Opening Files

nano: To open a file with nano, use the following command:
```
nano filename
```

If the file does not exist, nano will create a new file with the specified name.

vim: To open a file with vim, use the following command:
```
vim filename
```

Similar to nano, if the file does not exist, vim will create a new file with the specified name.

Editing Files

nano: In nano, you can start typing to edit the file. The arrow keys can be used to navigate through the text.
vim: In vim, you need to switch to insert mode to edit the text. Press i to enter insert mode, then start typing. To return to normal mode, press Esc or ctrl + [ keys.

Saving Files

nano To save changes in nano, press Ctrl + O, then press Enter to confirm the filename. Then press Ctrl + X to exit the editor.
vim To close vim, first ensure you are in normal mode by pressing Esc or ctrl + [ keys, then type :q and press Enter. If there are unsaved changes, you can use :wq to save and exit or :q! to exit forcefully without saving.

Conclusion

In this chapter, we covered two common text editors in Linux: nano and vim. We explored their basic usage, including how to open, edit, save, and close files. Whether you are a beginner or an advanced user, knowing how to use at least one of these text editors will enhance your ability to manage and configure your Linux system efficiently.

Feel free to leave comments and share this article. Follow my blog for more insights on Linux!

Chapter 3 - Setting up Kubernetes

Yusuf Isah — Tue, 20 Aug 2024 17:14:48 +0000

Introduction

Setting up a Kubernetes environment is the first step in learning how to deploy and manage containerized applications. This chapter will guide you through setting up a local Kubernetes cluster using Minikube and provide an overview of cloud-based Kubernetes setups using managed services like GKE, EKS, and AKS.

Local Setup with Minikube
- Installing Minikube
- Installing Kubectl
Cloud-based Kubernetes Setup
- Google Kubernetes Engine (GKE)
- Amazon Elastic Kubernetes Service (EKS)
- Azure Kubernetes Service (AKS)
Conclusion

Local Setup with Minikube

Minikube is a tool that allows you to run a single-node Kubernetes cluster on your local machine. It is ideal for learning, testing, and development purposes.

Installing Minikube

To install Minikube, follow these steps:

Install Minikube: Download and install minikube from the official minikube website. Ensure to download the version that is compatible with your operating system (Linux, Windows, or MacOS) and architecture. If you are using a MacOS or Linux operating system, you can find out the architecture of your system using the command below:
```
uname -m
```

If you are using Windows, you can find out the architecture of your system by opening your PowerShell terminal as an administrator and running the command below:

```sh   
wmic os get osarchitecture
```

Alternatively, you can also run the command below to find out the architecture of your Windows machine:

```sh
systeminfo | findstr /C:"System Type"
```

After installing minikube, you can verify if the installation was successful through the command below:

```sh
minikube version
```

If there is no output, it means the installation wasn't successful.

Installing Kubectl

kubectl is a command-line tool for interacting with your Kubernetes cluster. Follow these steps to install kubectl:

Download the latest release with the command:

  curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

Make the kubectl binary executable:

  chmod +x kubectl

Move the binary in to your PATH:

  sudo mv kubectl /usr/local/bin/

Verify the installation of kubectl and also check the version installed through the command below:

  kubectl version --client

Configure kubectl to interact with your Minikube cluster.

  kubectl config use-context minikube

Next, start your Minikube cluster with the command below:

  minikube start

The command above will start a virtual machine and set up a Kubernetes cluster within it. The command also automatically uses Docker as the default driver for Minikube (that is if Docker is installed). Other drivers that Minikube can use include VirtualBox, VMware, HyperKit, and Podman. To specify a specific driver (e.g., VirtualBox), use the "-driver" flag.

  minikube start --driver=VirtualBox

Once your Minikube cluster is up and running, run the command below to verify that everything is working perfectly:

  kubectl get nodes

If everything is working perfectly, the command above should display a single node with the status "Ready".

To stop your Minikube cluster, run:

  minikube stop

If you want to delete your minikube cluster, use the command below:

  minikube delete

Cloud-based Kubernetes Setup

For production environments, it is recommended to use managed Kubernetes services offered by cloud providers. These services handle the complexity of setting up and managing Kubernetes clusters, allowing you to focus on deploying and managing your applications. One important point you should note is that unlike Minikube, which is free, cloud-based Kubernetes setups incur costs and you will be billed accordingly. Here are three popular managed Kubernetes services:

Google Kubernetes Engine (GKE)

Google Kubernetes Engine (GKE) is a managed Kubernetes service provided by Google Cloud Platform. It offers automatic updates, scaling, and a highly available control plane. To get started with GKE, you need a Google Cloud
Platform account with billing enabled and the gcloud tool installed. Once you have gcloud installed, follow the remaining steps below to set up your GKE cluster:

Set a Default Zone:

   gcloud config set compute/zone us-west1-a

Create a GKE Cluster:

   gcloud container clusters create my-cluster --zone us-central1-a

Get Authentication Credentials:

   gcloud container clusters get-credentials my-cluster --zone us-central1-a

Deploy an Application:

   kubectl create deployment hello-gke --image=gcr.io/google-samples/hello-app:1.0
   kubectl expose deployment hello-gke --type=LoadBalancer --port 80 --target-port 8080

Amazon Elastic Kubernetes Service (EKS)

Amazon Elastic Kubernetes Service (EKS) is a managed Kubernetes service provided by Amazon Web Services (AWS). It integrates with other AWS services, providing a secure and scalable environment for running Kubernetes clusters.
Before getting started with EKS, first install the open source eksctl
command-line tool. Once you have eksctl installed and in your path, follow the remaining steps below to set up your EKS cluster:

Create an EKS Cluster:

   eksctl create cluster --name my-cluster --region us-west-2

Configure kubectl:

   aws eks --region us-west-2 update-kubeconfig --name my-cluster

Deploy an Application:

   kubectl create deployment hello-eks --image=amazon/amazon-ecs-sample
   kubectl expose deployment hello-eks --type=LoadBalancer --port 80

Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) is a managed Kubernetes service provided by Microsoft Azure. It offers integrated CI/CD capabilities and security features. Before getting started with AKS, first install the az CLI. Once you have installed az CLI, follow the remaining steps below to set up your AKS cluster:

Create an AKS Cluster:

   az aks create --resource-group myResourceGroup --name myAKSCluster --node-count 1 --enable-addons monitoring --generate-ssh-keys

Get AKS Credentials:

   az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

Deploy an Application:

   kubectl create deployment hello-aks --image=nginx
   kubectl expose deployment hello-aks --type=LoadBalancer --port 80

Conclusion

Setting up Kubernetes can be done locally using Minikube for learning and development, or using managed Kubernetes services for production environments. Whether you choose a local setup or a cloud-based setup, Kubernetes provides a robust platform for managing containerized applications at scale.

Feel free to leave comments and share this article. Follow my blog for more insights on Kubernetes!

Chapter 3 - Docker Containers

Yusuf Isah — Tue, 20 Aug 2024 16:21:25 +0000

Introduction

Docker containers are the building blocks of modern containerized applications. In this chapter, we'll delve into the world of Docker containers, exploring their fundamental concepts, basic operations, and essential management tasks. You'll learn how containers are instances of images, how to run, list, inspect, and access containers, and how to perform basic container lifecycle operations such as stopping, starting, restarting, and removing. By the end of this chapter, you'll have a solid understanding of Docker containers and be equipped with the skills to effectively work with them in your containerized applications.

Docker Containers
- Understanding Containers as Instances of Images
Basic Container Operations
- Running a Container
- Listing Running Containers
- Inspecting Containers
- Accessing a Running Container
- Stopping, Starting, Restarting, and Removing Containers
Conclusion

Docker Containers

A Docker container is a lightweight and standalone executable package that includes everything an application needs to run, such as code, libraries, and dependencies. Containers are isolated from each other and the host system, ensuring consistent behavior and performance.

Understanding Containers as Instances of Images

Containers are created from Docker images, which are templates that define the container's configuration and contents. When you run a container, Docker creates an instance of the image, allowing multiple containers to share the same image. This approach ensures efficient resource utilization and enables easy deployment.

Basic Container Operations

Running a Container

To run a Docker container, you can use the docker run command. This command creates a new container from a specified image and starts it. For example:
```
docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
```

Let's breakdown the command above:

docker run: The command to create and start a new container.
[OPTIONS]: Optional flags that modify the container's behavior (e.g., -it for interactive mode, -p for port mapping, or -d for detached/daemon mode).
IMAGE: The Docker image to use as a template for the container.
[COMMAND]: The command to run inside the container (if not specified, the image's default command is used).
[ARG...]: Arguments passed to the command (if any).

For example:

  docker run -d -p 80:80 --name webserver nginx

The command above runs an Nginx web server named webserver in detached mode, mapping port 80 of the host to port 80 of the container.

Listing Running Containers

To list all running containers, use the docker ps command.

docker ps

The command above will show a list of all currently running containers with details such as container ID, image name, and status.

Inspecting Containers

Use the docker inspect command to get detailed information about a container.

docker inspect [container_id]

Accessing a Running Container

Use the docker exec command to run commands inside a running container.

docker exec -it [container_id] [command]

For example:

docker exec -it 929374hfh573hdjf /bin/bash

Let's breakdown what the command above is doing:

docker exec is the command to execute a command inside a running container.
-it allocates a pseudo-TTY and keeps the container running after the command finishes.
929374hfh573hdjf is the container ID.
/bin/bash is the command to run inside the container (in this case, starts a new Bash shell).

Stopping, Starting, Restarting, and Removing Containers

Stopping a Container: To stop a running container, use the docker stop command followed by the container ID or name.
```
docker stop [container_id]
```
Starting a Container: To start a stopped container, use the docker start command.
```
docker start [container_id]
```
Restarting a Container: To restart a running container, use the docker restart command.
```
docker restart [container_id]
```
Removing Containers: To remove a stopped container, use the docker rm command, followed by the container ID.
```
docker rm [container_id]
```

If you want to remove a running container, you can use the -f option to forcefully remove it.

docker rm -f [container_id]

Conclusion

In this chapter, we defined Docker containers. We also learned how to run containers, list and inspect them, access their shells, and perform basic operations like stopping, starting, and removing. By mastering these essential skills, you're on your way to efficiently deploy and manage applications in a containerized environment.

Feel free to leave comments and share this article. Follow my blog for more insights on Docker and DevOps!

DEV Community: Yusuf Isah

Chapter 5 - Kubernetes Labels and Annotations

Introduction

Table of Contents

Labels

Applying Labels

Modifying Labels

Label Selectors

Label Selectors in API Objects

Labels in Kubernetes Architecture

Annotations

Conclusion

Chapter 5 - Building Docker Images

Introduction

Table of Contents

Building Images From a Dockerfile

Tagging Images

Multi-stage Builds

Conclusion

Chapter 5 - Cloning a Remote Repository

Introduction

Table of Contents

What is Cloning?

Why Clone a Repository?

How to Clone a Remote Repository

Conclusion

Chapter 5 - TCP/IP Protocol Suite

Introduction

Table of Contents

Common Protocols

TCP

UDP

IP

ICMP

ARP

Port Numbers

Well-known port numbers and their services

Conclusion

Chapter 5 - Linux File Permissions and Ownership

Introduction

Table of Contents

Understanding Permissions

Changing Permissions

chmod: Change File Modes

Using Symbolic Representation

Using Octal Values

Changing Ownership

chown: Change File Owner and Group

Conclusion

Chapter 4 - Kubernetes Pods

Introduction

Table of Contents

Pods in Kubernetes

Key Points About Pods:

The Pod Manifest

Creating a Pod

Creating a Pod Manifest

Running Pods

Listing Pods

Pod Details

Deleting a Pod

Accessing Your Pod

Getting More Information with Logs

Running Commands in Your Containers with exec

Copying Files to and From Containers

Health Checks

Liveness Probe

Readiness Probe

Resource Management

Resource Requests: Minimum Required Resources

Capping Resource Usage With Limits

Persisting Data with Volumes

Using Volumes with Pods

Putting it all Together

Conclusion

Chapter 4 - Dockerfiles

What is a Dockerfile?

Understanding Dockerfiles as Blueprints for Building Images.

Creating a Dockerfile

Basic Syntax and Structure