DEV Community: Samuel Ogunmola

Kubernetes: From Zero to Hero (Part 13) - Quality of Service 🔥💥

Samuel Ogunmola — Mon, 02 Jan 2023 20:18:37 +0000

What is Quality of Service(QoS)

Kubernetes Quality of Service (QoS) is a feature that helps you manage the resources that are allocated to your applications in a cluster. It allows you to specify the relative priority of different applications (called "pods"), which can be useful in a number of different scenarios.

Pods are assigned to one of three QoS classes: "Guaranteed," "Burstable," and "Best Effort." The QoS class of a pod determines the priority of that pod and how it is treated by the scheduler when allocating resources. For example, pods in the Guaranteed class are given the highest priority and are guaranteed a certain amount of resources, while pods in the Best Effort class are given the lowest priority and may be starved of resources if the cluster is under heavy load.

Using QoS can be helpful in a number of different scenarios. For example, if you have a set of applications that are critical to your business and need a consistent level of resources, you might assign them to the Guaranteed class. On the other hand, if you have batch jobs or other non-critical workloads that can tolerate some level of resource contention, you might assign them to the Best Effort class.

Why is Quality of Service important?

Quality of Service (QoS) is important in Kubernetes because it allows you to specify the relative priority of different applications (pods) and how they should be treated when allocating resources. This can be useful in a number of different scenarios.

For example, if you have a set of applications that are critical to your business and need a consistent level of resources, you might want to give them a higher priority by assigning them to the Guaranteed QoS class. This will ensure that they are allocated the resources they need to run effectively, and will prevent them from being starved of resources.

On the other hand, if you have batch jobs or other non-critical workloads that can tolerate some level of resource contention, you might want to give them a lower priority by assigning them to the Best Effort QoS class. This will allow them to use resources that are available, but they may be starved of resources if the cluster is under heavy load.

Types Of Quality of Service

In Kubernetes, there are three Quality of Service (QoS) classes that can be assigned to pods: Guaranteed, Burstable, and Best Effort. Each QoS class has a specific set of characteristics and is intended for use in different scenarios. Here's a brief overview of each QoS class:

Guaranteed: Pods in the Guaranteed class are given the highest priority and are guaranteed a certain amount of resources. If a pod in this class is not able to be scheduled due to resource constraints, the scheduler will not schedule any other pods until resources become available. Here's an example of how to specify the Guaranteed QoS class in a pod specification:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    resources:
      limits:
        cpu: "1"
        memory: "500Mi"
      requests:
        cpu: "1"
        memory: "500Mi"

NOTE: For a Pod to be given a QoS class of Guaranteed:

Every Container in the Pod must have a memory limit and a memory request.
For every Container in the Pod, the memory limit must equal the memory request.
Every Container in the Pod must have a CPU limit and a CPU request.
For every Container in the Pod, the CPU limit must equal the CPU request

Burstable: Pods in the Burstable class are given a lower priority than pods in the Guaranteed class, but are still allocated a certain amount of resources. If a pod in this class is not able to be scheduled due to resource constraints, the scheduler may choose to schedule other pods instead. Here's an example of how to specify the Burstable QoS class in a pod specification:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    resources:
      limits:
        cpu: "1"
        memory: "500Mi"
      requests:
        cpu: "0.5"
        memory: "200Mi"

NOTE: A Pod is given a QoS class of Burstable if:

The Pod does not meet the criteria for QoS class Guaranteed.
At least one Container in the Pod has a memory or CPU request or limit.

Best Effort: Pods in the Best Effort class are given the lowest priority and may be starved of resources if the cluster is under heavy load. They are typically used for batch jobs or other non-critical workloads that can tolerate some level of resource contention. Here's an example of how to specify the Best Effort QoS class in a pod specification:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image

NOTE: For a Pod to be given a QoS class of BestEffort, the Containers in the Pod must not have any memory or CPU limits or requests.

In general, it's a good idea to use the Guaranteed QoS class for critical applications that need a consistent level of resources, the Burstable class for applications that need a certain amount of resources but can tolerate some level of resource contention, and the Best Effort class for batch jobs or other non-critical workloads that can tolerate resource contention.

Kubernetes: From Zero to Hero (Part 12) - Requests and Limits

Samuel Ogunmola — Sun, 01 Jan 2023 17:10:36 +0000

In Kubernetes, requests and limits are used to specify the minimum and maximum amount of resources (such as CPU and memory) that a pod or container should be allocated.

Requests are the minimum amount of resources that a pod or container should receive. If a pod or container has a request for a particular resource, the scheduler will ensure that the pod or container is allocated at least that much of the resource. This is useful for ensuring that your applications have the resources they need to run effectively.

Limits, on the other hand, are the maximum amount of resources that a pod or container is allowed to consume. If a pod or container exceeds its limit for a particular resource, it may be terminated or throttled to prevent it from consuming too many resources. This can be useful for preventing resource contention and overutilization in your cluster.

Here's an example of how to specify requests and limits in a pod specification:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    resources:
      limits:
        cpu: "1"
        memory: "500Mi"
      requests:
        cpu: "0.5"
        memory: "200Mi"

In this example, we are specifying that the container should be allocated at least 0.5 CPU and 200 MiB of memory, and should not be allowed to consume more than 1 CPU and 500 MiB of memory.

NOTE: that requests and limits are specified in terms of millicores (m) for CPU and mebibytes (Mi) for memory. For example, the value "1" for CPU represents one millicore, and the value "500Mi" for memory represents 500 mebibytes.

It's important to note that requests and limits are not guaranteed to be the exact amount of resources that a pod or container will receive. They are used by the scheduler to make decisions about resource allocation, but the actual allocation may vary based on the available resources in the cluster and the demands of other pods and containers.

Using requests and limits can be a powerful tool for managing resources in your Kubernetes cluster. By specifying the minimum and maximum amounts of resources that your applications need, you can help ensure that they are allocated the resources they need to run effectively, and can also prevent resource contention and overutilization in your cluster.

scheduler to make decisions about resource allocation, but the actual allocation may vary based on the available resources in the cluster and the demands of other pods and containers.

One key use case for requests and limits is to ensure that your applications have the resources they need to run effectively. For example, if you know that your application requires a certain amount of CPU and memory to function properly, you can specify those requirements using requests. This will ensure that the scheduler allocates those resources to your application, and will prevent the application from being starved of resources.

Limits, on the other hand, can be useful for preventing resource contention and overutilization in your cluster. By specifying limits for your pods and containers, you can ensure that they don't consume too many resources, which can help to prevent other pods and containers from being starved of resources.

It's also worth noting that requests and limits can be specified at different levels in your Kubernetes cluster. For example, you can specify requests and limits at the pod level, which will apply to all containers in the pod. You can also specify requests and limits at the container level, which will only apply to that specific container.

In general, it's a good idea to specify both requests and limits for your pods and containers. This will help to ensure that your applications have the resources they need to run effectively, while also preventing resource contention and overutilization in your cluster.

To summarize, requests and limits are powerful tools for managing resources in your Kubernetes cluster. By specifying the minimum and maximum amounts of resources that your applications need, you can help ensure that they are allocated the resources they need to run effectively, and can also prevent resource contention and overutilization in your cluster.

🌟 🔥 If you want to switch your career into tech and you are considering DevOps, you can join our online community here for live classes and FREE tutorial videos.

Kubernetes: From Zero to Hero (Part 11) - Namespaces

Samuel Ogunmola — Sat, 31 Dec 2022 11:23:13 +0000

Kubernetes namespaces are a way to partition resources in a cluster and control access to those resources. They allow you to create multiple virtual clusters within a single physical cluster, which can be useful for a number of different purposes.

Why are they useful?

One common use case for namespaces is to isolate resources and control access. For example, you might create a namespace for each team in your organization, and then grant each team access only to the resources within their own namespace. This can help to enforce separation of duties and prevent accidental or unauthorized access to resources.

Another use case for namespaces is to manage multiple environments, such as development, staging, and production. By using namespaces, you can easily deploy and manage different versions of your applications in different environments, while still sharing common resources such as storage and networking.

How to create a namespace

To create a namespace in Kubernetes, you can use the kubectl create namespace command. For example:

kubectl create namespace my-namespace

This will create a namespace called "my-namespace."

How to use namespaces to isolate resources and control access

To use a namespace to isolate resources and control access, you can specify the namespace when creating resources in Kubernetes. For example, to create a deployment in the "my-namespace" namespace, you can use the following command:

kubectl create deployment my-deployment --namespace=my-namespace

You can also use namespace labels and selectors to control access to resources. For example, you can label a namespace with the team that should have access to it, and then use a namespace selector to grant access to that team.

Best practices for using namespaces

Use namespaces to reflect your organization's structure or separation of duties.
Consider using namespaces to isolate resources for different environments (e.g. development, staging, production).
Use namespaces to manage access to shared resources, such as storage and networking.
Tips for naming your namespaces
Use descriptive and meaningful names for your namespaces.
Avoid using names that are too general or could be confused with other resources.
Use a consistent naming convention for your namespaces to make them easier to manage.

Using namespaces to manage multiple environments (e.g. dev, staging, production)

You can use namespaces to deploy and manage different versions of your applications in different environments. For example, you might create a "development" namespace for development versions of your applications, and a "production" namespace for the versions that are live in production.

Using namespaces to provide multi-tenancy

You can use namespaces to provide multi-tenancy, which is the ability to host multiple isolated groups of users (tenants) on a shared cluster. This can be useful in a number of scenarios, such as hosting applications for multiple customers on a shared cluster.

Conclusion

In summary, Kubernetes namespaces are a useful tool for partitioning resources and controlling access in your cluster, and can be used for a variety of different purposes. Some best practices for using namespaces include organizing them based on your organization's structure or separation of duties, and using descriptive and meaningful names. In addition to providing multitenancy, namespaces can also be used to manage multiple environments.

🌟 🔥 If you want to switch your career into tech and you are considering DevOps, you can join our online community here for live classes and FREE tutorial videos.

Kubernetes: From Zero to Hero (Part 10) - Helm

Samuel Ogunmola — Fri, 30 Dec 2022 12:15:10 +0000

Introduction to Helm and its role in Kubernetes

Helm is an open source package manager for Kubernetes that simplifies the deployment and management of applications on the Kubernetes platform. It helps you define, install, and upgrade complex Kubernetes applications, and it provides a way to package all of the resources required for an application into a single, easy-to-use package called a chart.

Imagine that you have a web application that you want to deploy to a Kubernetes cluster. Without Helm, you would have to manually create all of the required Kubernetes resources, such as pods, services, and deployment objects, and then use the kubectl command-line tool to deploy them to your cluster. This process can be time-consuming and error-prone, especially if you have multiple microservices or dependencies that need to be deployed.

With Helm, you can create a chart that defines all of the resources required for your application, and then use the Helm CLI to deploy the chart to your cluster with a single command. This saves time and reduces the risk of mistakes, making it easier to manage and update your applications over time.

Installing Helm

To use Helm, you will need to have a Kubernetes cluster set up and the kubectl command-line tool installed on your local machine. If you don't already have a cluster, you can follow the instructions on the Kubernetes website to set one up.

Once you have a cluster and kubectl installed, you can install Helm by downloading the latest release from the Helm website and following the installation instructions. On macOS or Linux, you can use the following command to install Helm:

curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

This will download the Helm binary and add it to your PATH, so you can use the Helm CLI from any directory.

If you want to install Helm on a Kubernetes cluster, you can use the Helm CLI to install the Helm server-side component, Tiller, on the cluster. To do this, run the following command:

helm init

This will install Tiller on the default namespace of your cluster. If you want to install Tiller on a different namespace, you can use the --namespace flag.

Using Helm

Once Helm is installed, you can use the Helm CLI to search for, install, and manage charts.

To search for charts in the official Helm repository, use the search command:

helm search repo <chart-name>

This will return a list of charts that match the search term. You can then use the install command to install a chart from the repository:

helm install <chart-name>

This will create all of the required resources for the chart on your cluster. You can use the get command to list the releases (i.e. deployments) of a chart:

helm get releases

To update a release, you can use the upgrade command:

helm upgrade <release-name> <chart-name>

This will update the resources for the release to the latest version of the chart.

You can also create your own charts by using the create command:

helm create <chart-name>

This will create a starter chart with the necessary files and directories. You can then modify the chart files to define the resources that you want to deploy and customize the behavior of the chart.

To view the resources that are defined in a chart, you can use the helm show command:

helm show chart <chart-name>

Upgrading and rolling back deployments:
To upgrade a deployment to the latest version of a chart, use the helm upgrade command:

helm upgrade <release-name> <chart-name>

To roll back a deployment to a previous version, use the helm rollback command:

$ helm rollback <release-name> <revision>

Best practices for using Helm in a production environment

When using Helm in a production environment, it's important to follow some best practices to ensure the stability and reliability of your deployments. Here are a few tips:

Use version control for your charts to track changes and roll back if necessary
Test your charts thoroughly before deploying them to production
Use Helm's built-in security features, such as chart signing and repository authentication, to protect your deployments
Use Helm's dependency management features to ensure that all required charts are installed and upgraded in the correct order
Use Helm's release management features, such as the ability to roll back to previous versions, to recover from failures or errors in your deployments.

Advanced Helm features

In addition to the basic Helm commands described above, there are several advanced features that can be useful in a production environment.

Using Helm with continuous integration/continuous deployment (CI/CD) pipelines: Helm can be used in combination with a CI/CD tool, such as Jenkins or CircleCI, to automate the deployment of applications to a Kubernetes cluster. For example, you could set up a pipeline that automatically builds and deploys your application whenever you push changes to a Git repository. To use Helm with a CI/CD tool, you can set up a script that uses the Helm CLI to install or upgrade charts as part of the deployment process.
Customizing chart values and using templates for deployment configuration: Chart values are variables that can be used to customize the behavior of a chart when it is installed. For example, you might use chart values to specify the number of replicas for a deployment or the image tag for a container. Helm charts can use templates to define how these values should be applied to the resources in the chart. This allows you to define reusable templates that can be used across multiple charts, and it makes it easier to manage and maintain your deployments over time. Here's an example of how to use chart values and templates in a chart:

# values.yaml
replicaCount: 3
image:
  repository: nginx
  tag: latest

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
      - name: {{ .Release.Name }}
        image: {{ .Values.image.repository }}:{{ .Values.image.tag }}

In this example, the replicaCount and image values can be customized when the chart is installed using the --set flag:

helm install <chart-name> --set replicaCount=5,image.tag=stable

Using Helm hooks to execute tasks before or after chart installation or upgrade:
Helm provides the ability to use hooks to execute tasks before or after chart installation or upgrade. Hooks are defined in the chart and can be used to perform tasks such as creating a database, migrating data, or sending notifications. This can be especially useful when deploying complex applications that have dependencies on other services or resources.

Here's an example of how to use a hook in a chart:

# hooks/post-install.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: {{ .Release.Name }}-post-install
spec:
  template:
    spec:
      containers:
      - name: post-install
        image: busybox
        command: ["echo", "Post-install hook ran"]
  restartPolicy: Never

In this example, the hook is a Kubernetes Job that runs a simple command after the chart is installed.

Using Helm to manage dependencies between charts:
Helm provides a way to manage dependencies between charts. This can be useful when you have multiple charts that are used together to form a complete application. For example, if you have a chart for a web server and a chart for a database, you can use the dependencies feature to ensure that the database chart is installed before.

In conclusion, Helm is a powerful tool for managing applications on Kubernetes. It simplifies the deployment and management of complex applications by providing a way to package all of the resources needed for an application into a single chart. Helm also offers advanced features such as the ability to use templates to customize deployment configurations, use hooks to execute tasks before or after chart installation or upgrade, and manage dependencies between charts.

Some of the main benefits and features of Helm include:

Simplified deployment and management of complex applications on Kubernetes
Ability to search for and install charts from repositories
Ability to create and manage custom charts
Ability to upgrade and roll back deployments
Advanced features such as chart values, templates, hooks, and dependency management

If you are using Kubernetes and want an easier way to manage your applications, Helm is a great tool to consider. To learn more about Helm and how to use it, you can check out the Helm documentation (https://helm.sh/docs/) and the Kubernetes documentation. There are also many online resources and tutorials available for learning more about Helm and Kubernetes.

🌟 🔥 If you want to switch your career into tech and you are considering DevOps, you can join our online community here for live classes and FREE tutorial videos.

KUBERNETES: FROM ZERO TO HERO (PART 9) - NODE SELECTOR, TAINTS AND TOLERATIONS, POD AND NODE AFFINITY AND ANTI-AFFINITY

Samuel Ogunmola — Thu, 29 Dec 2022 13:45:49 +0000

In Kubernetes, node taints, node affinity, node selector and pod affinity are concepts that allow you to control the placement of pods on nodes in the cluster, based on the characteristics and the capabilities of the nodes and the pods. These concepts are useful when you need to enforce certain rules or constraints on the placement of the pods, or when you want to optimize the resource usage of the cluster.

Node Selector

Node selector is a property of pods that allows you to specify the nodes that the pods should be scheduled on, based on the labels of the nodes. You can use node selector to optimize the resource usage of the cluster, or to ensure that the pods are placed on the nodes that are most suitable for their workloads.

To specify node selector, you can use the nodeSelector field in the pod spec, and set the labels of the nodes that you want to target. The labels of the nodes are key-value pairs that are assigned to the nodes by the cluster administrator.

Here is an example of how you can specify the node selector of a pod:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  nodeSelector:
    key: value
  containers:
  - name: mycontainer
    image: myimage

Node selectors are used in conjunction with pod affinity and anti-affinity rules to determine which nodes a pod should be scheduled on. Pod affinity and anti-affinity rules allow you to specify whether certain pods should be placed on the same node, or whether they should be spread across multiple nodes.

Node Taints

Node taints and tolerations are features in Kubernetes that allow you to mark certain nodes as being suitable or unsuitable for certain pods. Node taints allow you to mark a node as being unsuitable for certain pods by adding a "taint" to the node. Pods that do not have a matching "tolerance" for the taint will not be scheduled on the tainted node.

On the other hand, node tolerations allow you to specify that a pod can tolerate running on a tainted node. This can be useful in situations where you need to temporarily schedule pods on a tainted node, or where you have a pod that is able to tolerate the taint.

To add a taint to a node, you can use the kubectl taint command. For example:

kubectl taint nodes node-1 key=value:NoSchedule

This will add a taint with the key "key" and the value "value" to the node "node-1", with the effect "NoSchedule", which means that pods without a matching tolerance will not be scheduled on the node.

To specify a tolerance for a pod, you can use the tolerations field in the pod specification. For example:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
  tolerations:
  - key: key
    operator: Equal
    value: value
    effect: NoSchedule

In this example, the pod will be able to tolerate a taint with the key "key" and the value "value" with the effect "NoSchedule".

Node taints and tolerations are useful tools for controlling which nodes pods can be scheduled on, and can be useful in situations where you need to temporarily schedule pods on a tainted node, or where you have a pod that is able to tolerate the taint.

Node Affinity and Anti-Affinity

Node affinity and anti-affinity are features in Kubernetes that allow you to specify the preferred or required nodes for a pod to run on, or to specify nodes that a pod should not run on. These features are used in conjunction with node selectors, which are labels applied to nodes in a cluster that can be used to specify the characteristics of a node.

Node affinity means that a pod should be scheduled on nodes with the specified labels, while anti-affinity means that a pod should not be scheduled on nodes with the specified labels. Both node affinity and anti-affinity can be used to specify either preferred or required nodes for a pod.

To specify node affinity or anti-affinity for a pod, you can use the affinity field in the pod specification. For example:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: environment
            operator: In
            values:
            - production

In this example, the pod will only be scheduled on nodes that have the label "environment" set to "production".

To specify anti-affinity, you can use the nodeAntiAffinity field instead of the nodeAffinity field. For example:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
  affinity:
    nodeAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: environment
            operator: In
            values:
            - staging

In this example, the pod will not be scheduled on nodes that have the label "environment" set to "staging".

Node affinity and anti-affinity are useful tools for ensuring that your applications are deployed to the appropriate nodes in your cluster. They allow you to specify the preferred or required characteristics of the nodes that a particular pod should run on, or to specify nodes that a pod should not run on. This can help you to optimize the performance and availability of your applications.

Pod Affinity and Anti-Affinity

Pod affinity and anti-affinity are properties of pods that allow you to specify the pods that should be co-located or separated from each other, based on the labels and the topology of the nodes. You can use pod affinity and anti-affinity to optimize the resource usage of the cluster, or to ensure that the pods are placed on the nodes that are most suitable for their workloads.

Pod affinity allows you to specify the pods that should be co-located with each other, based on the labels and the topology of the nodes. You can use pod affinity to group the pods together, if you want to take advantage of the proximity of the pods to each other, or if you want to minimize the network latency between the pods.

Pod anti-affinity allows you to specify the pods that should not be co-located with each other, based on the labels and the topology of the nodes. You can use pod anti-affinity to spread the pods across the nodes, if you want to distribute the workloads evenly, or if you want to avoid overloading a single node.

To specify pod affinity or anti-affinity, you can use the affinity field in the pod spec, and set the podAffinity or podAntiAffinity field, depending on your needs. You can then specify the labels and the topology of the pods that you want to target, using the labelSelector and the topologyKey fields.

Here is an example of how you can specify the pod affinity of a pod:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: key
            operator: In
            values:
            - value1
            - value2
        topologyKey: topologyKey
  containers:
  - name: mycontainer
    image: myimage

This will specify that the pod should be co-located with the pods that have the label "key" with the values "value1" or "value2", and that are on the same node as the pod.

Here is an example of how you can specify the pod anti-affinity of a pod:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: key
            operator: In
            values:
            - value1
            - value2
        topologyKey: topologyKey
  containers:
  - name: mycontainer
    image: myimage

In conclusion, node selector, node affinity, anti-affinity, pod affinity, anti-affinity, and node taints and tolerations are all features in Kubernetes that allow you to control where your applications are deployed within a cluster. Node selector allows you to specify the characteristics of the nodes that a particular pod should run on, while node affinity and anti-affinity allow you to specify the preferred or required nodes for a pod to run on, or to specify nodes that a pod should not run on. Pod affinity and anti-affinity allow you to specify whether certain pods should be placed on the same node, or whether they should be spread across multiple nodes. Node taints and tolerations allow you to mark certain nodes as being suitable or unsuitable for certain pods, and to specify whether a pod can tolerate running on a tainted node. These features are powerful tools that can help you to optimize the performance and availability of your applications within a Kubernetes cluster.

🌟 🔥 If you want to switch your career into tech and you are considering DevOps, you can join our online community here for live classes and FREE tutorial videos.

KUBERNETES: FROM ZERO TO HERO (PART 8) - CONFIG MAPS AND SECRETS

Samuel Ogunmola — Wed, 28 Dec 2022 09:21:54 +0000

In Kubernetes, Config Maps and Secrets are two types of resources that allow you to store and manage configuration data and sensitive information, respectively. Both types of resources are used to inject data into the containers in a pod, and they can be used to decouple the configuration of your applications from the code itself.

In this article, we will cover the following topics:

What are Config Maps and Secrets, and how are they different
How to create and use Config Maps and Secrets in your pods
The different types of Config Maps and Secrets, and their use cases
Best practices for managing Config Maps and Secrets in your cluster

What are Config Maps and Secrets, and how are they different

Config Maps and Secrets are both types of resources in Kubernetes that allow you to store and manage configuration data and sensitive information, respectively. However, they have some key differences:

Config Maps are used to store non-sensitive configuration data, such as environment variables, command-line arguments, and configuration files. They are stored in plain text, and they can be easily accessed and modified by anyone who has access to the cluster.

Secrets are used to store sensitive information, such as passwords, tokens, and certificates. They are stored in an encrypted form, and they can only be accessed and modified by authorized users.

Both Config Maps and Secrets are stored as key-value pairs, and they can be used to inject data into the containers in a pod. However, Config Maps are intended for non-sensitive data, while Secrets are intended for sensitive data.

How to create and use Config Maps and Secrets in your pods
To use Config Maps and Secrets in your pods, you need to create them first, and then reference them in the pod's configuration file.

Here is an example configuration file that creates a Config Map and a Secret:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config-map
data:
  my-key: my-value
---
apiVersion: v1
kind: Secret
metadata:
  name: my-secret
data:
  my-key: bXktdmFsdWU=

This configuration file creates a Config Map named my-config-map with a single key-value pair, and a Secret named my-secret with the same key-value pair. The value of the Secret is encoded using base64, to ensure that it is stored in an encrypted form.

To create the Config Map and the Secret in the cluster, you can use the kubectl create -f command, passing the configuration file as an argument:

kubectl create -f config-map-secret.yaml

Once the Config Map and the Secret are created, you can reference them in the pod's configuration file. Here is an example configuration file that creates a pod that uses the Config Map and the Secret:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    env:
    - name: MY_ENV_VAR
      valueFrom:
        configMapKeyRef:
          name: my-config-map
          key: my-key
    - name: MY_SECRET_ENV_VAR
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: my-key

Types of Kubernetes Secret

There are several types of Secrets that you can use in Kubernetes, depending on your needs:

Generic Secrets: These are the most basic type of Secrets, and they can be used to store any kind of sensitive data. You can create Generic Secrets from a file or a directory on the host, or from literal key-value pairs.

TLS Secrets: These Secrets are used to store TLS certificates and keys, and they are used to secure the communication between pods and services. You can create TLS Secrets from a file or a directory on the host, or from literal key-value pairs.

Docker Registry Secrets: These Secrets are used to authenticate with a Docker registry, and they are used to pull images from a private registry. You can create Docker Registry Secrets from a file or a directory on the host, or from literal key-value pairs.

Service Account Tokens: These Secrets are used to authenticate with the Kubernetes API server, and they are automatically created and managed by Kubernetes. You don't need to create Service Account Tokens manually, but you can reference them in your pods and services.

In addition to these types of Secrets, Kubernetes also supports custom Secret types, which you can define and use in your cluster

Best practices for managing Config Maps and Secrets in your cluster

Here are some best practices for managing Config Maps and Secrets in your cluster:

Use Config Maps for non-sensitive data, and Secrets for sensitive data: As we saw in the beginning of this article, Config Maps are intended for non-sensitive data, while Secrets are intended for sensitive data. Make sure to use the appropriate type of resource for your data.
Use Config Maps and Secrets sparingly: Config Maps and Secrets can be useful for injecting data into the containers in a pod, but they should not be used as a replacement for proper configuration management. Avoid storing large amounts of data in Config Maps and Secrets, and consider using a configuration management tool such as Ansible, chef, or puppet.
Use the --dry-run flag to test your Config Maps and Secrets: Before creating a Config Map or a Secret in the cluster, you can use the--dry-run flag to test the resource without actually creating it. This can be useful for testing the resource and for debugging any issues.
Use the--output=yaml flag to view the generated Config Map or Secret: After creating a Config Map or a Secret in the cluster, you can use the --output=yaml flag to view the generated resource. This can be useful for verifying the content of the resource and for debugging any issues.
Use Config Maps and Secrets sparingly
: Config Maps and Secrets can be useful for injecting data into the containers in a pod, but they should not be used as a replacement for proper configuration management. Avoid storing large amounts of data in Config Maps and Secrets, and consider using a configuration management tool such as ansible, chef, or puppet.

Overall, Config Maps and Secrets are useful resources for injecting data into the containers in a pod, and they can be used to decouple the configuration of your applications from the code itself. By following the best practices outlined in this article, you can effectively manage the configuration data and sensitive information in your cluster.

🌟 🔥 If you want to switch your career into tech and you are considering DevOps, you can join our online community here for live classes and FREE tutorial videos.

KUBERNETES: FROM ZERO TO HERO (PART 7) - KUBERNETES VOLUMES💥🔥

Samuel Ogunmola — Tue, 27 Dec 2022 09:50:57 +0000

In Kubernetes, a volume is a directory that is accessible to the containers in a pod. It allows you to store and share data among the containers in the pod, and it can be used to persist data beyond the lifecycle of the pod.

Imagine 😎 that you have a pod with two containers: a web server and a database. The web server needs to store its files in a directory that the database can access. You can use a volume to create a shared directory that both containers can access. This way, the web server can store its files in the shared directory, and the database can access them.

There are several types of volumes that you can use in Kubernetes, each with its own characteristics and use cases. For example, you can use an EmptyDir volume to store temporary data that does not need to be persisted beyond the lifecycle of the pod. Or you can use a GCEPersistentDisk volume to store data that needs to be persisted beyond the lifecycle of the pod 🌈.

To use a volume in a pod, you need to specify it in the pod's configuration file. This is done by adding a volumes field to the configuration file, and specifying the type of volume and its parameters. You also need to add a volumeMounts field to the container's configuration, and specify the name of the volume and the mount path. The mount path is the directory in the container where the volume will be mounted.

For example, here is a configuration file that creates a pod with an EmptyDir volume and a container that mounts the volume at the /var/www/htmldirectory:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    volumeMounts:
    - name: my-volume
      mountPath: /var/www/html
  volumes:
  - name: my-volume
    emptyDir: {}

This configuration file creates a pod with an EmptyDir volume named my-volume, and a container named my-container that runs the nginx image. The container mounts the volume at the /var/www/html directory. You can use the kubectl create command to create the pod in the cluster.

Types Of Volumes

There are several types of volumes that you can use in Kubernetes, each with its own characteristics and use cases. In addition to the types of volumes that I mentioned in my previous response (such as EmptyDir, GCEPersistentDisk), Kubernetes also provides the following types of volumes:

PersistentVolume: This type of volume represents a piece of storage in the cluster that has been provisioned by the administrator. It can be used to store data that needs to be persisted beyond the lifecycle of the pod.

PersistentVolumeClaim: This type of volume represents a request for storage by a user. It allows a pod to claim a specific PersistentVolume in the cluster, and to use it to store data that needs to be persisted beyond the lifecycle of the pod.

StorageClass: This type of resource defines the parameters for creating a PersistentVolume. It allows the administrator to specify the type and the size of the PersistentVolume, as well as other parameters such as the access mode (e.g. read-only or read-write), the provisioner (e.g. GCE, AWS, Azure), and the reclaim policy (e.g. delete or retain).

To use a PersistentVolumeClaim volume in a pod, you need to create a PersistentVolume and a StorageClass first, and then create the PersistentVolumeClaim. Here is an example configuration file that creates a PersistentVolumeClaim volume:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  gcePersistentDisk:
    pdName: my-disk
    fsType: ext4
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: standard

This configuration file creates a PersistentVolume named my-pv that uses a GCE persistent disk as the backing store. It also creates a StorageClass named standard that specifies the parameters for creating the PersistentVolume. Finally, it creates a PersistentVolumeClaim named my-pvc that claims the PersistentVolume and requests a storage capacity of 1Gi.

To create the PersistentVolume, the StorageClass, and the PersistentVolumeClaim in the cluster, you can use the kubectl create -f command, passing the configuration file as an argument:

kubectl create -f pvc.yaml

To use the PersistentVolumeClaim volume in a pod, you need to specify it in the pod's configuration file, using the persistentVolumeClaim field. Here is an example configuration file that creates a pod with a PersistentVolumeClaim volume:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    volumeMounts:
    - name: my-volume
      mountPath: /var/www/html
  volumes:
  - name: my-volume
    persistentVolumeClaim:
      claimName: my-pvc

This configuration file creates a pod with a PersistentVolumeClaim volume named my-volume, and a container named my-container that runs the nginximage. The container mounts the volume at the /var/www/html directory. The volume is claimed using the my-pvc PersistentVolumeClaim, which was created in the previous step.

To create the pod in the cluster, you can use the kubectl create command, passing the configuration file as an argument:

kubectl create -f pod.yaml

There are even more types of volumes that are being commonly used in kubernetes:

EmptyDir: This type of volume is created when the pod is created, and it is deleted when the pod is deleted. It is useful for storing temporary data that does not need to be persisted beyond the lifecycle of the pod.

HostPath: This type of volume mounts a directory from the host's file system into the pod. It is useful for accessing data on the host from within the pod, or for debugging purposes.

GCEPersistentDisk: This type of volume mounts a Google Compute Engine (GCE) persistent disk into the pod. It is useful for storing data that needs to be persisted beyond the lifecycle of the pod.

AWSElasticBlockStore: This type of volume mounts an Amazon Web Services (AWS) Elastic Block Store (EBS) volume into the pod. It is useful for storing data that needs to be persisted beyond the lifecycle of the pod.

AzureDisk: This type of volume mounts an Azure Disk into the pod. It is useful for storing data that needs to be persisted beyond the lifecycle of the pod.

NFS: This type of volume mounts an Network File System (NFS) share into the pod. It is useful for storing data that needs to be shared among multiple pods, or that needs to be persisted beyond the lifecycle of the pod.

ConfigMap: This type of volume mounts a ConfigMap as a set of files into the pod. It is useful for injecting configuration data into the containers in the pod.

Secret: This type of volume mounts a Secret as a set of files into the pod. It is useful for injecting sensitive data into the containers in the pod. files into the pod. It is useful for injecting sensitive data into the containers in the pod.

Overall, volumes are an important part of the Kubernetes network model, and they allow you to store and share data among the containers in a pod. They provide a flexible and scalable way to persist. PersistentVolume, PersistentVolumeClaim, and StorageClass are advanced types of volumes that allow you to store and share data that needs to be persisted beyond the lifecycle of the pod. They provide a flexible and scalable way to manage the storage needs of your applications in the cluster. Although GCEPersistentDisk, AzureDisk, AWSElasticBlockStore has been deprecated, they are included here because they are worth knowing.

🌟 🔥 If you want to switch your career into tech and you are considering DevOps, you can join our online community herefor live classes and FREE tutorial videos.

KUBERNETES FROM ZERO TO HERO (PART 6) - KUBERNETES SERVICES 💥🔥

Samuel Ogunmola — Mon, 26 Dec 2022 10:48:28 +0000

Pods are the basic units of deployment. They are containers that run on the cluster, and they can be created and destroyed at any time. When you deploy an application on Kubernetes, you usually create a group of pods to run the application.

One important thing to understand about pods is that they are ephemeral, which means that they are not guaranteed to be stable. This means that if you restart a pod, it will be replaced with a new pod, which will have a different IP address. This can be important to consider if you are using the IP address of a pod to communicate with it.

For example, let's say you have a pod running a database, and you are using the IP address of the pod to connect to the database from your application. If you restart the pod, it will be replaced with a new pod, which will have a different IP address. This means that you will need to update the IP address in your application to the new IP address of the pod, which would be very difficult or even impossible. So clearly, we need something more stable and that is where Services comes into play.

What is a Service.

A service is an abstract way to expose an application running on a set of pods to the external network. When you create a service, you specify which pods you want to expose and how you want to expose them.

One important role of a service is to provide a fixed IP address for the application. This means that you can access the application using a fixed address, even if the underlying pods are changing or moving. For example, if you have a group of pods running a web server, you can create a service that exposes the web server on a fixed IP address. This way, you can access the web server using the fixed IP address, regardless of which pods are running the web server at any given time.

This is useful because it allows you to access the application consistently, regardless of the underlying infrastructure. For example, if you are using the IP address of a pod to connect to a database running in the pod, you will need to update the IP address in your application when the pod is restarted. By using a service, you can avoid this problem because the service provides a stable network endpoint for the application, regardless of the underlying pods.

Another role of a service is to act as a load balancer. This means that it distributes incoming traffic among the underlying pods in a way that is appropriate for the application. For example, if you have a group of pods running a web server, you can create a service that exposes the web server on a fixed IP address. The service will then act as a load balancer, distributing incoming requests to the web server among the underlying pods.

This is useful because it allows you to scale your application horizontally by adding more pods. For example, if you have a group of pods running a web server, and the traffic to the web server increases, you can simply add more pods to the group. The service will automatically distribute the traffic among the new pods, and the application will continue to be available without any disruption.

Types of services

ClusterIP: This is the default type of service in Kubernetes. It exposes the application on a cluster-internal IP address, which is only reachable from within the cluster. This type of service is useful when you want to access the application from within the cluster, but you don't want to expose it to the external network.
Here is an example configuration file for creating a ClusterIP service:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

This configuration file creates a ClusterIP service named my-service that exposes the pods with the app: my-app label on port 80. The pods must be running a container that listens on port 80. The service exposes the application on a cluster-internal IP address, which is only reachable from within the cluster.

To create the service in the cluster, you can use the kubectl create -f command, passing the configuration file as an argument:

kubectl create -f service.yaml

This will create the service in the cluster, and you can verify it by running the kubectl get services command. The cluster IP address of the service can be obtained from the CLUSTER-IP column.

LoadBalancer: This type of service exposes the application on a public IP address, using an external load balancer provided by the cloud provider. The load balancer distributes the traffic among the underlying pods. This type of service is useful when you want to expose the application to the external network.

Here is an example configuration file for creating a LoadBalancer service:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

This configuration file creates a LoadBalancer service named my-service that exposes the pods with the app: my-app label on port 80. The pods must be running a container that listens on port 80. The service exposes the application on a public IP address, using an external load balancer provided by the cloud provider. The load balancer distributes the traffic among the underlying pods.

To create the service in the cluster, you can use the kubectl create -f command, passing the configuration file as an argument:

kubectl create -f service.yaml

This will create the service in the cluster, and you can verify it by running the kubectl get services command. The public IP address of the service can be obtained from the EXTERNAL-IP column.

Keep in mind that the exact process for creating a LoadBalancer service may vary depending on your cloud provider and the type of load balancer that you are using. Some cloud providers may require you to create the load balancer manually, and then specify the load balancer's IP address or DNS name in the service configuration file. Other cloud providers like AWS will automatically create the load balancer when you create the service. Consult the documentation of your cloud provider for more information.

NodePort: This type of service exposes the application on a fixed port of each node in the cluster. This allows you to access the application from the external network using the IP address of any node in the cluster. The traffic is distributed among the underlying pods using a simple round-robin algorithm. This type of service is useful when you want to access the application from the external network, but you don't have a load balancer available.
Here is an example configuration file for creating a NodePort service:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 30080

This configuration file creates a NodePort service named my-service that exposes the pods with the app: my-app label on port 80. The pods must be running a container that listens on port 80. The service exposes the application on a fixed port (30080 in this example) of each node in the cluster. You can access the application from the external network using the IP address of any node in the cluster and the fixed port number.

To create the service in the cluster, you can use the kubectl create -f command, passing the configuration file as an argument:

kubectl create -f service.yaml

This will create the service in the cluster, and you can verify it by running the kubectl get services command. The node port number can be obtained from the NODE-PORT column.

Overall, services are an important part of the Kubernetes network model, and they provide a stable network endpoint for applications running on the cluster. They allow you to expose your applications to the external network in a flexible and scalable way, and they provide load balancing and traffic management capabilities.

🌟 🔥 If you want to switch your career into tech and you are considering DevOps, you can join our online community here for live classes and FREE tutorial videos.

KUBERNETES: FROM ZERO TO HERO (PART 5) - DEPLOYMENT AND PODS 💥🔥

Samuel Ogunmola — Sun, 25 Dec 2022 08:11:14 +0000

In part 2 of this series, we learnt that there are worker nodes and master nodes or control plane. We learnt that nodes are the physical machines or virtual machines that kubernetes runs on. And a kubernetes cluster is only a group of two or more nodes. Today we are going to learn more about the resources we discussed about in part 1 of this series. We are going to learn more about pods and deployment. So are you with me? Let's get started.

DEPLOYMENT

In Kubernetes, a deployment is a resource that represents a set of replicas of a pod. It provides a way to update the pods in a rolling fashion, ensuring that the desired number of replicas are available at all times.

A deployment consists of a set of desired properties, including the number of replicas, the labels and selectors used to identify the pods, and the container image and command to run in the pods. It also has a set of actual properties, including the current number of replicas and the status of the pods.

When you create a deployment, Kubernetes will create the desired number of replicas of the pod and ensure that they are running on the worker nodes. If a pod goes down, the deployment will create a new one to replace it. You can also update the deployment by changing the desired properties, such as the container image or the number of replicas. Kubernetes will then update the pods in a rolling fashion, ensuring that the desired number of replicas are available at all times.

Here is an example deployment configuration file for Kubernetes in YAML format:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: my-container-image:latest
        command: ["/bin/bash", "-c"]
        args: ["echo hello world"]

This configuration file creates a deployment called my-deployment with three replicas of a pod. The pod contains a single container, my-container, which is based on the my-container-image:latest image and runs the echo hello world command.

The replicas field specifies the desired number of replicas of the pod, and the selector field specifies the labels and selectors used to identify the pods. The template field specifies the template for the pods, including the labels, the container image and command, and any other desired properties.

Overall, deployments are a useful resource in Kubernetes for managing the replicas of a pod and ensuring that the desired number of replicas are available at all times. They provide a way to update the pods in a rolling fashion, making it easy to deploy and manage applications in a cluster.

Pods

A pod is the basic unit of deployment. It is a logical host for one or more containers, and it represents the smallest deployable unit in the cluster. Pods are usually managed by higher-level abstractions such as deployments or stateful sets, which handle the details of scaling and self-healing.

In very simple language, pods are like little houses for containers. Containers are like really small computers that can run different types of programs. Pods are like houses because they have a place for the containers to live and they keep the containers safe. Pods can have one or more containers inside them, depending on how big the program is that the containers are running.

A pod configuration file is a file that describes the desired state of a pod or set of pods. It specifies the details of the pod or pods, such as the containers that should be run, the resources they should consume, and the volumes they should mount.

Here is an example configuration file for creating a pod in Kubernetes:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx:latest
    ports:
    - containerPort: 80
  volumes:
  - name: my-volume
    emptyDir: {}

This configuration file creates a pod named my-pod with a single container running the nginx image. The container exposes port 80, and the pod mounts an empty volume named my-volume.

To create the pod in the cluster, you can use the kubectl create -f command, passing the configuration file as an argument:

kubectl create -f pod.yaml

This will create the pod in the cluster, and you can verify it by running the kubectl get pods command.

🌟 🔥 If you want to switch your career into tech and you are considering DevOps, you can join our online community here for live classes and FREE tutorial videos.

KUBERNETES: FROM ZERO TO HERO (PART 4) - KUBERNETES CONFIGURATION FILES💥🔥

Samuel Ogunmola — Sat, 24 Dec 2022 08:08:27 +0000

Kubernetes configuration files are used to define the desired state of a cluster and the resources that run on it. They are written in YAML or JSON format and are used to create, update, and delete resources in the cluster. A kubernetes config file consists of about 5 parts, the:

💎apiVersion: The version of the Kubernetes API that the configuration file is using. This field is used to ensure that the configuration file is compatible with the version of the API server.

💎kind: The type of resource that the configuration file is defining. This can be a pod, service, deployment, or any other resource type supported by Kubernetes.

💎metadata: Metadata about the resource, such as its name, labels, and annotations. This information is used to identify and classify the resource.

💎spec: The specification of the resource, including its properties and behavior. The exact contents of this field depend on the type of resource being defined.

💎status: The current status of the resource, including its conditions and any other relevant information. This field is usually generated by the API server and is not typically specified in the configuration file.

There are several types of resources that can be defined in a Kubernetes configuration file, including pods, services, and deployments. Each resource type has its own set of properties that can be specified in the configuration file.

Here are some examples of Kubernetes configuration files for different resource types:

Pods

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-container-image:latest
    command: ["/bin/bash", "-c"]
    args: ["echo hello world"]

This configuration file creates a pod called my-pod with a single container, my-container, based on the my-container-image:latest image. The container runs the echo hello world command.

Service

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

This configuration file creates a service called my-service that exposes the pods with the app: my-app label on port 80. The service routes traffic to the pods on port 8080.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: my-container-image:latest
        command: ["/bin/bash", "-c"]
        args: ["echo hello world"]

ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-configmap
data:
  # Add key-value pairs here
  key1: value1
  key2: value2
  key3: value3

This configuration file creates a configmap named my-configmap with three key-value pairs: key1: value1, key2: value2, and key3: value3.

Secrets

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  # Add key-value pairs here, with the value in base64 encoding
  key1: dmFsdWUx
  key2: dmFsdWUy
  key3: dmFsdWUz

This configuration file creates a secret named my-secret with three key-value pairs: key1: value1, key2: value2, and key3: value3. The values are encoded in base64.

To create any resource in the cluster, you can use the kubectl create -f command, passing the configuration file as an argument, for example:

kubectl create -f configmap.yaml

Overall, Kubernetes configuration files are a powerful tool for defining the desired state of a cluster and the resources that run on it. They can be used to create, update, and delete resources in the cluster and allow you to easily deploy and manage applications in a cluster.

🌟 🔥 If you want to switch your career into tech and you are considering DevOps, you can join our online community here for live classes and FREE tutorial videos.

KUBERNETES FROM ZERO TO HERO (PART 3) - INSTALLING MINIKUBE, KUBECTL AND KUBECTL COMMANDS

Samuel Ogunmola — Fri, 23 Dec 2022 12:01:30 +0000

Minikube is a tool that allows you to run a single-node Kubernetes cluster locally, on your own machine. It is designed to be used for testing, development, and learning purposes, as it allows you to run a full-featured Kubernetes cluster on your laptop or desktop.

Minikube uses the popular open-source hypervisor VirtualBox to create a virtual machine (VM) on which it runs the Kubernetes control plane and other components. It also uses the kubectl command-line interface (CLI) to manage the cluster and deploy applications.

To install Minikube, you need to follow these steps:

Install a hypervisor, such as VirtualBox and Hyper-V for Windows or Hyper-kit if on MacOS, on your machine.

Download and install the minikube CLI on your machine. This can be done using a package manager, such as apt, yum, or brew, depending on your operating system.

Run the minikube start command to create and start the Minikube cluster. By default, this will create a cluster with one node running in a VM on your machine.

Run the kubectl get nodes command to verify that the cluster is running and the node is ready.

Use the kubectl CLI to deploy applications to the cluster and manage the resources in the cluster.

There are several ways to communicate with kubernetes control plane or master node and one of them is using a tool called kubectl

KUBECTL

kubectl is the command-line interface (CLI) for managing Kubernetes clusters. It is a powerful tool that allows you to control and manage the resources of a cluster, such as pods, services, and deployments.

kubectl communicates with the Kubernetes API server to perform various operations, such as creating, updating, and deleting resources in the cluster. It can be used to view the status of the cluster, debug issues, and perform other tasks related to the management of the cluster.

Here are the most useful kubectl commands:

kubectl get: Used to list the resources in a cluster, such as pods, services, and deployments. Example:

kubectl get pods #Lists all the pods in the current namespace.

kubectl describe: Used to view detailed information about a resource, such as its status, labels, and events. Example:

kubectl describe pod <pod-name>

kubectl create: Used to create a new resource in the cluster, such as a pod, service, or deployment. Example:

kubectl create -f <config-file>

kubectl apply: Used to apply a configuration file to create or update a resource in the cluster. Example:

kubectl apply -f <config-file>

kubectl delete: Used to delete a resource from the cluster. Example

kubectl delete pod <pod-name>

kubectl exec: Used to execute a command in a running container. Example:

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

kubectl logs: Used to view the logs of a container. Example:

kubectl logs <pod-name>

kubectl scale: Used to scale the number of replicas of a deployment or replicaset. Example:

kubectl expose deployment <deployment-name> --type=LoadBalancer --port=80

kubectl rollout: Used to manage the rollout of a deployment, including pausing, resuming, and rolling back a rollout.
kubectl edit: Used to edit a resource in-place, allowing you to make changes to the resource directly from the command line.
kubectl port-forward: Used to forward a local port to a port on a pod, allowing you to access the pod from your local machine.
kubectl top: Used to view resource usage of pods or nodes in the cluster. Example:

kubectl top pod #Shows resource usage of pods in the cluster.

kubectl cp: Used to copy files to and from containers in a pod. Examples:

kubectl cp <local-file-path> <pod-name>:<remote-file-path> #Copies a file from the local machine to a pod.

kubectl cluster-info: Used to view information about the cluster, such as the version of Kubernetes and the list of nodes.
kubectl config: Used to manage the kubectl configuration, including setting the current context and namespace.
kubectl patch: Used to apply a patch to a resource, allowing you to make changes to the resource without replacing it. Example:

kubectl patch deployment <deployment-name> -p '{"spec":{"template":{"spec":{"containers":[{"name":"<container-name>","image":"<image>:<tag>"}]}}}}' #Applies a patch to a deployment to change the image of a specific container.

kubectl drain: Used to drain a node in a cluster, evacuating all pods from the node and marking it as unavailable for scheduling. Example:

kubectl drain <node-name>

kubectl cordon: Used to mark a node as unschedulable, preventing new pods from being scheduled on the node. Example:

kubectl cordon <node-name>

kubectl uncordon: Used to mark a node as schedulable, allowing new pods to be scheduled on the node. Example:

kubectl uncordon <node-name>

kubectl run: Used to create a new deployment or replicaset by running a single container in a pod. Example:

kubectl run <deployment-name> --image=<image>:<tag> --replicas=2

kubectl expose: Used to expose a deployment, replicaset, or pod as a service, allowing it to be accessed from outside the cluster.

kubectl expose pod <pod-name> --port=80 --name=<service-name>

kubectl explain: Used to view the documentation and detailed information about a resource, including its fields and their descriptions. Example:

kubectl explain pod

kubectl cluster-health: Used to view the health of the nodes and pods in a cluster. Example

kubectl cluster-health

kubectl taint: Used to add, modify, or remove a taint on a node, allowing you to control which pods can be scheduled on the node.
kubectl label: Used to add, modify, or remove labels on a resource, allowing you to classify and organize resources in the cluster.
Kubectl Port-forward: Forwards the local port to a specific pod port.
Example:

kubectl port-forward <pod-name> 8080:80 #Forwards the local port 8080 to the port 80 of a specific pod.

kubectl set: Used to set or unset various options, such as the image of a container or the environment variables of a pod. Examples:

kubectl set image deployment <deployment-name> <container-name>=<image>:<tag>

kubectl set env deployment <deployment-name> KEY=VALUE

kubectl api-resources: Used to list the available API resources in the cluster, including their names, short names, and categories. Examples:

kubectl api-resources

kubectl api-versions: Used to list the available API versions in the cluster. Example:

kubectl api-versions

kubectl convert: Used to convert a resource from one format to another, such as YAML to JSON or JSON to YAML. Example:

kubectl convert -f <config-file> -o yaml

kubectl certificate: Used to manage the certificate authorities (CAs) and certificates used by the cluster.

Overall, kubectl is a powerful and flexible tool for managing Kubernetes clusters. It can be used to perform a wide range of tasks, from listing and describing resources to creating, updating, and deleting them. It is an essential tool for anyone working with Kubernetes.

🌟 🔥 If you want to switch your career into tech and you are considering DevOps, you can join our online community here for live classes and FREE tutorial videos.

KUBERNETES FROM ZERO TO HERO (PART 2) - KUBERNETES ARCHITECTURE 💥🔥

Samuel Ogunmola — Thu, 22 Dec 2022 08:37:55 +0000

In the last part of this series, we learnt that Kubernetes is a powerful open-source container orchestration system for automating the deployment, scaling, and management of containerized applications. It provides a set of APIs and tools that can be used to deploy, scale, and manage containerized applications across a cluster of servers. Today we are going to be learning how different parts of kubernetes works together. We are going to see the architecture of kubernetes and how it's components works together to help kubernetes do it's work. Are you with me? Let's get started right away 👍.

At a high level, the architecture of Kubernetes consists of a set of master nodes and worker nodes.

The master nodes or control planes are responsible for managing the worker nodes and the resources that run on them. The worker nodes are responsible for running the containers of an application.

Here is a more detailed breakdown of the components of the Kubernetes architecture ✨⭐️:

The worker node consists of three components or put in a better way, three processes. And they are:

Container Runtime
Kubelet and,
Kube-proxy

while the Master node has four processes and they are:

API Server
Scheduler
Controller-Manager
etcd

Now that we know these, lets look into each of these components in detail.

✨🎖️. WORKER NODE PROCESSES

Container Runtime: the container runtime is responsible for running the containers of an application. It is the software that is responsible for creating and managing the containers, as well as communicating with the operating system to allocate resources and perform other tasks.
Kubernetes supports a number of container runtimes, including Docker, containerd, and CRI-O. Docker is the most widely used container runtime and is the default runtime for Kubernetes. It provides a lightweight, standalone execution environment for containers and is easy to use and integrate with other tools.
Containerd is an open-source container runtime that is designed to be lightweight and modular. It provides a stable and consistent runtime for containers and is used by many cloud providers and container orchestrators, including Kubernetes.
CRI-O is an open-source container runtime that is designed to be used with Kubernetes. It is based on containerd and is optimized for use with Kubernetes, providing a lightweight and stable runtime for containers.
Kubelet: The kubelet is a daemon that runs on each worker node and is responsible for managing the pods and containers on that node. It communicates with the Kubernetes API server to receive instructions and report the status of the pods and containers.
The kubelet is responsible for several key tasks, including:

Running and maintaining the desired number of replicas of a pod: The kubelet ensures that the desired number of replicas of a pod are running at any given time. If a pod goes down, it will create a new one to replace it.

Communicating the status of the pods and containers to the API server: The kubelet reports the status of the pods and containers to the API server, including their resource usage and health status.

Mounting volumes and secrets: The kubelet is responsible for mounting volumes and secrets onto the pods as specified in the pod configuration.

Managing the containers of a pod: The kubelet is responsible for starting, stopping, and restarting the containers of a pod as needed. It also monitors the health of the containers and restarts them if necessary.

Managing the network namespace of a pod: The kubelet is responsible for setting up the network namespace of a pod and configuring the network interfaces, routes, and firewall rules as needed.

Kube-proxy: The kube-proxy is a daemon that runs on each worker node and is responsible for implementing the network proxy and load balancer functions for the node. It is used to forward traffic to the appropriate pods and services based on the destination IP and port. In simple words, they help services do the work of loadbalancing. The kube-proxy works in conjunction with the kube-apiserver to ensure that the desired state of the cluster is maintained. It listens for changes to the services and endpoints in the cluster and updates the iptables rules on the node accordingly. This allows it to load balance traffic to the correct pods and services and ensure that traffic is routed correctly within the cluster. The kube-proxy supports a number of different modes of operation, including userspace, iptables, and ipvs. The default mode is iptables, which uses the Linux kernel's built-in packet filtering system to forward traffic. The userspace and ipvs modes use userspace software to forward traffic and offer additional features, such as direct server return and shared IPs.

Now lets look at the master processes

✨🏆 MASTER NODE PROCESSES

API Server: The API server is the central point of communication between the master nodes and the worker nodes. It exposes a RESTful API that can be used to manage the resources of the cluster, such as pods, services, and deployments. The API server is responsible for several key tasks, including:

Receiving and processing API requests: The API server receives API requests from clients, such as kubectl or Kubernetes client libraries, and processes them to create, update, or delete resources in the cluster.

Storing the desired state of the cluster: The API server stores the desired state of the cluster in etcd, a distributed key-value store. It ensures that the actual state of the cluster matches the desired state by reconciling any discrepancies and making the necessary changes.

Validating and authorizing API requests: The API server validates and authorizes API requests to ensure that only authorized clients can make changes to the cluster. It uses a combination of built-in and pluggable authentication and authorization modules to enforce access controls.

Serving the API: The API server exposes a number of endpoints that allow clients to interact with the resources of the cluster. It serves the API over HTTPS and can be configured to use TLS certificates for secure communication.

Scheduler: The scheduler is a component that is responsible for scheduling pods to run on the worker nodes of a cluster. It takes into account the available resources of the worker nodes and the resource requirements of the pods to determine the best place to run them.
The scheduler works in conjunction with the API server and the kubelets to ensure that the desired state of the cluster is maintained. It receives pod scheduling requests from the API server and assigns them to a worker node based on the available resources and the resource requirements of the pod. It also communicates with the kubelets to ensure that the pods are actually running on the assigned worker nodes.
The scheduler can be configured to use various scheduling algorithms and policies to make scheduling decisions. For example, you can specify constraints on where a pod can be scheduled, such as on a particular node or in a particular region. You can also specify resource requirements for a pod, such as the amount of CPU and memory it needs, and the scheduler will try to find a worker node that can accommodate those requirements.
Contoller-Manager: In Kubernetes, the controller manager is a daemon that runs on the master nodes and is responsible for managing the controllers in the cluster. Controllers are responsible for maintaining the desired state of the cluster by reconciling any discrepancies between the actual state and the desired state.
The controller manager is responsible for starting and stopping the controllers, as well as monitoring their health and restarting them if necessary. It also communicates with the API server to receive updates about the resources in the cluster and takes action to ensure that the desired state is maintained.
There are several types of controllers in Kubernetes, including:

ReplicationController: Ensures that the desired number of replicas of a pod are running at any given time.

Deployment: Provides a way to update the pods in a rolling fashion, ensuring that the desired number of replicas are available at all times.

StatefulSet: Manages the deployment and scaling of a set of pods that have persistent storage.

DaemonSet: Ensures that a copy of a pod is running on all or a subset of the worker nodes.

etcd: etcd is a distributed key-value store that is used to store the configuration data of a Kubernetes cluster. It is used to store the desired state of the cluster and is used by the API server to ensure that the actual state of the cluster matches the desired state. etcd is a highly available and distributed system that can be deployed on a cluster of machines. It stores the data in a replicated log, which allows it to maintain consistency across the cluster and recover from failures. It also provides a number of features to support distributed systems, such as leader election and distributed locks. In Kubernetes, etcd is used to store a wide range of data, including the desired state of the pods, services, and deployments in the cluster. It is also used to store the configuration of the master nodes and the worker nodes, as well as the network and security policies of the cluster.

Overall, the architecture of Kubernetes consists of a set of master nodes and worker nodes that are responsible for managing and running the containers of an application. The API server, etcd, scheduler, and kubelet are key components that work together to ensure that the desired state of the cluster is maintained and that the containers of an application are running as intended. Understanding the architecture of Kubernetes is essential for effectively deploying and managing applications in a cluster 😋.

💎 Note: This is the part 2 of the "Kubernetes: From Zero to Hero" Series. If you want to become a DevOps engineer then you should join our online community here for more content like this. Merry Christmas 🎅