DEV Community: Divine Odazie

Can you use just any Kubernetes project in your regulated environment?

Divine Odazie — Fri, 11 Apr 2025 13:16:10 +0000

Can you use just any Kubernetes project in your regulated environment?

We all know you can't.

This is one of the challenge some shared on the k8sproject./com waitlist.

The person shared that they are new to Kubernetes.

And restricted to using it in the GovCloud region of AWS at work.

Now where can they go to get updated information based on experience of others.

This is why we are building "k8sprojects/.com".

Tell us what to build: https://everythingdevops.typeform.com/k8sprojects

k8sprojects.com The Kuberentes Review Platform

Divine Odazie — Mon, 31 Mar 2025 09:00:00 +0000

Trustpilot for Kubernetes projects? Stay with me!

KubeCon starts tomorrow; we are going to learn about exciting projects.

With that, I am happy to announce a project I have been working on for a while.

k8sprojects.com

The idea is simple.

A platform for engineers like you to Discover, Validate and Review new and existing Kubernetes projects.

Over my years in the cloud native space, I have seen myself searching for reviews on the tools I want to use.

I find most of those reviews on Reddit.

But the sad thing is most are stale, some leave out context like

↳Number of nodes

↳Type of company. A fintech product is not the same as others

↳Team size., etc.

Also, not everyone is on Reddit or wants to be.

What if there is a platform where engineering context is prioritized?

Where you can easily share your thoughts through your GitHub account.

What if there was a review platform built with cloud-native engineers in mind?

This is what we are building.

And if you like the idea, we want you to tell us what to build.

Join the waitlist: https://everythingdevops.typeform.com/k8sprojects

And let us know what you want to see.

Optimize AWS Storage Costs with Amazon S3 Lifecycle Configurations

Divine Odazie — Wed, 13 Sep 2023 19:49:00 +0000

This article was originally posted on EverythingDevOps.

Data is the lifeblood of any business. Data is used to make decisions, drive innovation, and serve customers. But data can also be expensive to store at scale in the cloud. That's where storage lifecycle configurations come in.

An Amazon s3 lifecycle configuration is a set of rules that define actions that Amazon S3 applies to a group of objects. With lifecycle configurations, you can automatically move old data to a lower-cost storage tier with Transition actions or delete it with Expiration actions. This can save you a significant amount of money on your AWS bill over time.

This article will start by listing the available transition storage tiers in s3 and then explain scenarios where s3 lifecycle configurations can help optimize storage costs. After that, you will learn about the components of an s3 lifecycle configuration and how to create one. Ultimately, this article will share considerations to remember when using s3 lifecycle configurations.

S3 storage classes you can move data to

The following are some of the storage classes that you can move objects to from S3 Standard (default storage class for Amazon S3) with Amazon S3 Lifecycle Configurations:

S3 Standard-IA(Infrequently Accessed): This is a lower-cost storage class than S3 Standard. It is a good choice for objects that are accessed less frequently. It has no minimum storage duration.
S3 Intelligent-Tiering: It is an option for data with changing or unknown access patterns. It has 30 days minimum storage duration.
S3 One Zone-IA: This is for when you want to store infrequently accessed data in a single availability zone. It has a 30 days minimum storage duration.
S3 Glacier Instant Retrieval: You transition data to this storage class if you will only access the data once a quarter (three months). It has a 90 days minimum storage duration.
S3 Glacier Flexible Retrieval: You use this storage class to store data accessed once a year, but will retrieval time of minutes to hours. It has a 90 days minimum storage duration.
S3 Glacier Deep Archive: This is the lowest-cost storage class. It is a good choice for objects that are accessed once a year with a retrieval time of hours.

Use cases of Amazon s3 lifecycle configurations

You can use Amazon s3 lifecycle configurations in many scenarios to help manage your storage costs and optimize your usage. Some prominent use cases include:

To automatically move old objects to a lower-cost storage class: For example, you could create a lifecycle rule that moves objects that have not been accessed in 30 days to s3 Standard-IA. This would save you money on storage costs while still allowing you to access the objects if you need them in the future.
To automatically delete old objects: If you have an s3 bucket that contains temporary files your users create, you could create a lifecycle rule that deletes objects that are older than 7 days. This would help you to avoid storing unnecessary data in S3 and incurring unnecessary storage costs.
To abort incomplete multipart uploads: When you upload a large object to Amazon S3, you can use multipart upload to break the object up into smaller parts and upload them separately. This can be helpful for uploading large objects over a slow network connection. However, if you interrupt a multipart upload, the parts will remain in your S3 bucket, and you will continue to be charged for them.

To avoid this, you can use a lifecycle configuration to abort incomplete multipart uploads after a specified number of days. This will help to free up storage space in your bucket and prevent you from forgetting about the incomplete upload.
To keep track of your data retention policies: You can use lifecycle configurations to ensure that your data is retained for the required amount of time in accordance with your organization's data retention and compliance policies. For example, you could create a lifecycle rule that keeps all logs for 7 years, then delete them.

Components of an s3 lifecycle configuration

A lifecycle configuration contains a set of rules. A rule is made up of four components: ID, Filters, Status, and Actions.

ID

The ID is a unique identifier of the lifecycle rule. This is crucial since one lifecycle configuration can have up to 1000 rules, and the ID will make it easier for you to remember what each rule performs.

Filters

The filters component defines WHICH objects in your bucket you’d like to take action on. You can decide whether to apply actions to every object in a bucket or only some of them. You can filter based on prefix, object tag, or object size if you select a subset of objects. Or, if you wanted to be more specific, you could filter using a combination of these characteristics.

Status

To enable and disable each lifecycle rule, you’d use the status component. When evaluating lifecycle settings and determining the most effective rules for your workload, this can be useful.

Actions

Arguably the most important component of them all. The actions component is where you define WHERE you want to happen to your — are you transitioning them to a lower storage class, or are you deleting them?

There are six main actions you can use: Transition, expiration, NoncurrentVersionExpiration, NoncurrentVersionTransition, ExpiredObjectDeleteMarker, and the AbortIncompleteMultipartUpload action. With Transition actions, you can automatically move old data to a lower-cost storage tier, and expiration actions automate the deletion of your objects in S3.

Transition actions and expiration actions only apply to the most recent version of your item if versioning is enabled for your bucket. Use the NoncurrentVersionTransition action to transition between noncurrent versions of your object. Similarly to this, you must utilize the NoncurrentVersionExpiration action to remove noncurrent versions of your object.

With the AbortIncompleteMultipartUpload action. You should perform this step if you need to clean up any incomplete multipart uploads. You can set the maximum number of days that your multipart uploads can be in progress using this action.

To learn more about each of the above components, check out the Amazon s3 lifecycle rules documentation.

Step-by-Step Guide: How to Create a Lifecycle Configuration on an S3 Bucket (DEMO)

Like creating an s3 bucket, there are several ways to create an s3 lifecycle configuration — using the AWS Console, CLI, SDKs, or Rest API. In this demo, you will create a lifecycle configuration for an s3 bucket using the AWS Console.

The S3 lifecycle configuration you will create in this demo will transition new log data from the s3 Standard to Glacier Deep Archive after 30 days to store for compliance purposes and delete them after 7 years.

To follow along in this demo:

Create a demo s3 bucket. Learn how to create one here.
Download the following sample log data for demo purposes:

Upload the above 3 sample datasets into your demo s3 bucket as in the image below.

To create the lifecycle configuration, at the top right corner, click on the “Management” tab, as highlighted in the above image. In the “Management” tab, click “Create lifecycle rule,” as in the image below.

On the next page, name your lifecycle rule, select the “Apply to all objects in the bucket” rule scope option, and other rule actions as in the image below.

In the image above:

Selecting “Apply to all objects in the bucket” means that the lifecycle rule applies to all the log data in the bucket.
If you select the other option, you will be able to filter objects by prefix, object tags, object size, or whatever combination suits your use case. Learn more about filters here.
For the “Lifecycle rule actions,” seeing there are no other versions of the logs for this demo, this demo selects the “Move current versions of objects between storage classes” and “Expire current versions of objects” options.

The next option is to select the storage class and days — 30 — to transition, as in the image below, and then the days — 2557 (7 years) — to expire the objects after the retention period is over.

Note: You can ignore the warning. It pops up because the objects set to transition to Glacier Deep Archive in this demo are relatively small to the size of objects you would transition in a real-world scenario.

The next step is to review the rule transition and actions and then create it as in the image below.

After you create the rule, you should see it in the image below. From the page, you can edit the rule, enable and disable it, and create more rules.

Cleaning up
Ensure you delete the demo lifecycle rule and s3 bucket to avoid incurring unnecessary AWS charges.

Key Considerations for Creating S3 Lifecycle Configurations

While a lifecycle configuration can be powerful, there are several considerations you should keep in mind when creating one:

Moving between storage classes

Think about the s3 storage classes as a staircase. S3 Standard is at the top of the staircase, while s3 Glacier Deep Archive is at the bottom of the staircase. And all of the other storage classes are in between.

With lifecycle configurations, this staircase only goes one way: down. Once you transition data down the staircase to a lower-cost storage class, you can't move objects back up. For example, let's say you move your data to S3 One Zone-IA. Once your data transitions to that storage class, you can't use a lifecycle configuration to move your data back to S3 Standard or S3 Intelligent Tiering.

Lifecycle configuration costs

Costs follow a similar staircase model. The costs can be categorized in two ways: storage transition costs and minimum storage duration fees. Both of which increase as you move down the staircase.

For storage transition costs, you will be charged $0.01 for every 1,000 lifecycle transition requests when objects are moved from the S3 Standard to the S3 Standard-IA storage class. As you go down all the way to S3 Glacier Deep Archive, this cost increases and can be up to $0.05 for every 1000 transition requests.

For minimum storage duration fees, seeing most storage classes have a minimum storage duration before you can delete, overwrite, or transition those objects. And the minimum storage duration periods increase as you go down the staircase as well.

To learn more about the considerations when creating S3 lifecycle configurations, check out this documentation on that.

Conclusion

In this article, you learned all you need to get started creating Amazon s3 lifecycle configurations. From its use cases to key considerations to make. There is so much more to learn about Amazon s3. To do so, explore the documentation on s3.

Rapid development on AWS EKS using Garden

Divine Odazie — Tue, 23 May 2023 09:42:24 +0000

This article was originally posted on Hackmamba.

In the past two decades, massive changes have occurred in software development. From waterfall to agile methodology, silos to DevOps philosophy, on-premise to cloud computing, and so on, these changes allow engineering teams to develop high-quality software at the fastest pace ever.

"Fastest pace ever?" some developers will question. With all the improvements, they recall the days in which they had to wait before testing their changes due to messy shared environments and their struggles with internal tooling. At best, this is frustrating; at worst, it is a severe drain on developer productivity.

This article introduces Garden, explains how it works, and walk you through how to set up Garden for development on an AWS EKS cluster using an example project.

What is Garden.io?

Garden is an all-in-one platform that simplifies and speeds up software development by combining rapid development, testing, and DevOps automation. Garden allows you to create realistic cloud-native environments for every stage of your software development lifecycle (SDLC) without worrying about the difference between each environment (dev, CI and prod).

With Garden, you can:

program your workflows across all stages of your SDLC,
develop faster in production-like environments at each stage, accompanied by live reloading,
write end-to-end tests faster, and
reduce lead time thanks to smart caching, which dramatically speeds up every step of the process.

How does Garden work?

You might ask, “how does Garden achieve all this?” The high-level answer is that Garden deploys a Stack Graph.

The Stack Graph is an opinionated graph structure that allows you to describe your whole stack in a consistent and structured way without having to write massive scripts or monolithic configuration files.

The Stack Graph is based on the idea that all DevOps workflows can be fully described in terms of the following four actions:

build it
deploy it
test it
run (for running ad-hoc tasks)

With Stack Graph, you define each component of your stack independently with respect to the four actions above using straightforward, understandable YAML declarations—without altering any of your current code. Garden compiles every declaration you make, even those spread over different repositories, into a complete graph of your stack.

Image source — Garden on GitHub

The Stack Graph makes your workflows portable and reproducible across your entire SLDC. Garden can execute the Stack Graph in environments as in the image below.

Image source — Garden on Youtube.

Moreover, you can easily add components to your stack without introducing more complexity to your workflows.

Image source — Garden on Youtube.

To learn more about how Garden works, check out its documentation.

Prerequisites

To follow along with this article’s demo, you must have the following:

The Garden CLI installed on your machine — see how to install it here.
Basic-to-intermediate understanding of AWS and EKS (Amazon Elastic Kubernetes Service).
A running AWS EKS cluster. If you don't have one, you can create a demo cluster using this YAML configuration.
The kubectl command-line tool configured to communicate with the cluster.

Configuring a project for use with Garden

This article will use a simple example project created by Garden. To clone the project and enter its directory, run the following commands:

$ git clone https://github.com/garden-io/garden.git
$ cd garden/examples/demo-project-start

The demo-project-start project contains two directories, with one container service each; backend and frontend. To configure this project for use with Garden, you must first define a boilerplate Garden project and then a Garden module for each service.

To create the boilerplate Garden project, use the following helper command:

$ garden create project --skip-comments

The above command will create a basic boilerplate project configuration — project.garden.yml — in the current directory, as seen below. This is the project's configuration root. The --skip-comments flag removes all the comments that reveal all the available options for the configuration. You can omit it to see all of the options.

kind: Project
name: demo-project-start
environments:
  - name: default
providers:
  - name: local-kubernetes

Every Garden command is run against one of the environments defined in the project.garden.yml configuration. The above configuration has one environment (default) and a single provider. A provider is a resource upon which you will build an environment. The two most commonly used providers in Garden are the local Kubernetes provider and the remote Kubernetes provider.

To learn more about environments and providers, see the Garden Projects documentation.

Later in the article, you will edit this boilerplate config to define a dev environment, connect to your AWS EKS cluster, etc.

Next, create module configs (garden.yml) for each container service, starting with backend.

$ cd backend
$ garden create module --skip-comments
$ cd ..

You'll get a suggestion to make it a container module. Choose that, and give it the default name as well. Then do the same for the frontend module:

$ cd frontend
$ garden create module --skip-comments
$ cd ..

This is now enough configuration to build the project. But before you can deploy it, you need to configure services in each module configuration and then connect to a remote EKS cluster.

Configuring services in each module
Starting with the backend container service, open the garden.yml file and add the following:

services:
  - name: backend
    ports:
      - name: http
        containerPort: 8080
        servicePort: 80
    ingresses:
      - path: /hello-backend
        port: http

The above is enough information for Garden to deploy and expose the backend service. The full module config should look like that of the image below.

Now, for the frontend service, add the following to its garden.yml file:

services:
  - name: frontend
    ports:
      - name: http
        containerPort: 8080
    ingresses:
      - path: /hello-frontend
        port: http
      - path: /call-backend
        port: http
    dependencies:
      - backend

The above does the same as the backend service, adding a runtime dependency on the backend service. The full module config should look like that of the image below.

Connecting to the EKS Cluster and ECR container registry

Garden has great features, the most powerful of which is the ability to build images in your development cluster, thus avoiding the need for local clusters. To enable in-cluster building, you will need to:

configure the remote Kubernetes plugin
and then configure access to the remote deployment registry for built images. While testing, you can skip this step and utilize the in-cluster registry already provided; however, remember that you might run into scaling problems.

Configuring the remote Kubernetes plugin
To configure the remote Kubernetes plugin, update the project-level configuration file, project.garden.yml, with the following:

The context for your EKS cluster. You can get the context of your EKS cluster with the following kubectl command:

$ kubectl config current-context

The hostname for your services.
The build mode. This article uses kaniko build mode, which works well for most scenarios.
The image deployment registry.
The name(s) and namespace(s) of the ImagePullSecret(s) used by your cluster. This article uses just one ImagePullSecret to authenticate your AWS ECR.
A TLS secret (optional).

Before updating the project.garden.yml, create the ImagePullSecret. To do so, first, create a config.json file, and add the following JSON configuration.

{
  "credHelpers": {
    "<aws_account_id>.dkr.ecr.<region>.amazonaws.com": "ecr-login"
  }
}

The <aws_account_id> and <region> are placeholders that you need to replace for your registry.

Next, create the ImagePullSecret in your cluster (you can replace the default namespace; make sure it's correctly referenced in the project.garden.yml):

$ kubectl --namespace default create secret generic ecr-config \
    --from-file=.dockerconfigjson=./config.json \
    --type=kubernetes.io/dockerconfigjson

Then, update your project.garden.yml to be as below:

kind: Project
name: demo-project-start
environments:
- name: dev
  providers:
  - name: kubernetes
    context: <your_eks_cluster_context>
    defaultHostname: test.com //for demo purposes
    buildMode: kaniko 
    deploymentRegistry:
      hostname: <aws_account_id>.dkr.ecr.<region>.amazonaws.com
      namespace: test
    imagePullSecrets:
      - name: ecr-config
        namespace: default
defaultEnvironment: dev

In the above YAML configuration, it is important to note that when you specify <aws_account_id>.dkr.ecr.<region>.amazonaws.com and namespace: test for the deploymentRegistry field, and you have a container module named backend in your project, it will be tagged and pushed to <aws_account_id>.dkr.ecr.<region>.amazonaws.com/test/backend:v:<module-version> after building. That image ID will then be used in Kubernetes manifests when running containers.

Configuring access to ECR container registry
Before you configure access to ECR, create two repositories for the backend and frontend containers respectively as in the image below.

To configure access to ECR, grant your service account the right permission to push to ECR by adding the policy below to each repository.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowPushPull",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::<account-id>:role/<k8s_worker_iam_role>"                ]
            },
            "Action": [
                "ecr:BatchGetImage",
                "ecr:BatchCheckLayerAvailability",
                "ecr:CompleteLayerUpload",
                "ecr:GetDownloadUrlForLayer",
                "ecr:InitiateLayerUpload",
                "ecr:PutImage",
                "ecr:UploadLayerPart"
            ]
        }
    ]
}

In the above policy, arn:aws:iam::<account-id>:role/<k8s_worker_iam_role> will be the ARN of your cluster worker nodes. In the Roles section of your IAM dashboard, search for your cluster name, as seen in the image below. Edit the policy such that it contains your cluster’s ARN, then copy it.

To add the above policy, navigate to the Permissions section of each repository as in the image below, click Edit policy JSON, and paste the policy, then save.

After saving, the policy should look like this:

With all that done, you can now deploy and test your project.

Deploying and testing the Garden project

In the directory, you have the project.garden.yml. Now, run the following command:

$ garden deploy

You should see your services display similarly to the image below.

You can verify that the images were built on ECR and the pods are running using the following command:

$ kubectl get pods -n demo-project-start-default

To set up tests, similar to how you configured the services earlier, open the frontend/garden.yml config and add the following:

tests:
  - name: unit
    args: [npm, test]
  - name: integ
    args: [npm, run, integ]
    dependencies:
      - frontend

The above config defines two simple test suites. One runs the unit tests of the frontend service. The other runs a basic integration test that relies on the frontend service being up and running.

To run the test, run the following command:

$ garden test

You should see the tests pass, similar to that shown in the image below.

With all that done, you can move on from this simple example to configuring your own project with these steps, regardless of its complexity.

Conclusion

In this article, you learned about Garden, how it works, and how to configure an existing project to use it for development on an AWS EKS cluster. There is so much more to learn about Garden; to do so, check out the following resources:

How to restart Kubernetes Pods with kubectl

Divine Odazie — Thu, 16 Mar 2023 01:26:46 +0000

This article was originally posted on Everything DevOps.

Anyone who has used Kubernetes for an extended period of time will know that things don’t always go as smoothly as you’d like. In production, unexpected things happen, and Pods can crash or fail in some unforeseen way. When this happens, you need a reliable way to restart the Pods.

Restarting a pod is not the same as restarting a container, as a Pod is not a process but an environment for running container(s). A Pod persists until it finishes execution, is deleted, is evicted for lack of resources, or its host node fails.

This article will list 4 scenarios where you might want to restart a Kubernetes Pod and walk you through methods to restart Pods with kubectl.

4 scenarios where you might want to restart a Pod

There are several scenarios where you neeed to restart a Pod. The following are 4 of them:

Unexpected errors such as “Pods stuck in an inactive state” (e.g., pending), “Out of Memory” (occurs Pods try to go beyond the memory limits set in your manifest file), etc.
To easily upgrade a Pod with a newly-pushed container image if you previously set the PodSpec imagePullPolicy to Always.
To update configurations and secrets.
You would want to restart Pods when the application running in the Pod has a corrupted internal state that needs to be cleared.

Now you’ve seen some scenarios where you might want to restart a Pod. Next, you will learn how to restart Pods with kubectl.

Restarting Kubernetes pods with kubectl

kubectl, by design, doesn’t have a direct command for restarting Pods. Because of this, to restart Pods with kubectl, you have to use one of the following methods:

Restarting Kubernetes Pods by changing the number of replicas with kubectl scale command
Downtimeless restarts with kubectl rollout restart command
Automatic restarts by updating the Pod’s environment variable
Restarting Pods by deleting them ## Prerequisites

Before you learn how to use each of the above methods, ensure you have the following prerequisites:

A Kubernetes cluster. The demo in this article was done using minikube — a single Node Kubernetes cluster.
The kubectl command-line tool configured to communicate with the cluster.

For demo purposes, in any desired directory, create a httpd-deployment.yaml file with replicas set to 2 using the following YAML configurations:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd-deployment
  labels:
    app: httpd
spec:
  replicas: 2
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      containers:
      - name: httpd-pod
        image: httpd:latest

In your terminal, change to the directory where you saved the deployment file, and run:

$ kubectl apply -f httpd-deployment.yaml

The above command will create the httpd deployment with two pods. To verify the number of Pods, run the $ kubectl get pods command.

Now you have the Pods of the httpd deployment running. Next, you will use each of the methods outlined earlier to restart the Pods.

Restarting Kubernetes Pods by changing the number of replicas

In this method of restarting Kubernetes Pods, you scale the number of the deployment replicas down to zero, which stops and terminates all the Pods. Then you scale them back up to the desired state, which initializes new pods.

Note: It is important to note that when you set the number of replicas to zero, seeing the Pods stop running, there will be some application downtime.

To scale down the httpd deployment replicas you created, run the following kubectl scale command:

$ kubectl scale deployment httpd-deployment --replicas=0

The above command will show an output indicating that Pods have been scaled, as shown in the image below.

To confirm that the pods were stopped and terminated, run $ kubectl get pods, and you should get the “No resources are found in default namespace” message.

To scale up the replicas, run the same kubectl scale, but this time with --replicas=2.

$ kubectl scale deployment httpd-deployment --replicas=2

After running the above command, to verify the number of pods running, run:

$ kubectl get pods

And you should see each Pod back up and running after restarting, as in the image below.

Downtimeless restarts with Rollout restart

In the previous method, you scaled down the number of replicas to zero to restart the Pods; doing so caused an outage and downtime of the application. To restart without any outage and downtime, use the kubectl rollout restart command, which restarts the Pods one by one without impacting the deployment.

To use rollout restart on your httpd deployment, run:

$ kubectl rollout restart deployment httpd-deployment

Now to view the Pods restarting, run:

$ kubectl get pods

Notice in the image below Kubernetes creates a new Pod before Terminating each of the previous ones as soon as the new Pod gets to Running status. Because of this approach, there is no downtime in this restart method.

Automatic restarts by updating the Pod’s environment variable

So far, you’ve learned two ways of restarting Pods in Kubernetes; one by changing the replicas and the other by rollout restart. The methods work, but you explicitly restarted the pods with both of them.

In this method, once you update the Pod’s environment variable, the change will automatically restart the Pods.

To update the environment variables of the Pods in your httpd deployment, run:

$ kubectl set env deployment httpd-deployment DATE=$()

After running the above command, which adds a DATE environment variable in the Pods with a null value (=$()), run $ kubectl get pods and see the Pods restarting, similar to the rollout restart method.

You can verify that each Pod’s DATE environment variable is null with the kubectl describe command.

$ kubectl describe pod <pod_name>

After running the above command, the DATE variable is empty (null) like in the image below.

Restarting Pods by deleting them

Because the Kubernetes API is declarative, it automatically creates a replacement when you delete a Pod that’s part of a ReplicaSet or Deployment. The ReplicaSet will notice the Pod is no longer available as the number of container instances will drop below the target replica count.

To delete a Pod, use the following command:

$ kubectl delete pod <pod_name>

Though this method works quickly, it is not recommended except if you have a failed or misbehaving Pod or set of Pods. For regular restarts like updating configurations, it is better to use the kubectl scale or kubectl rollout commands designed for that use case.

To delete all failed Pods for this restart technique, use this command:

$ kubectl delete pods --field-selector=status.phase=Failed

Cleaning up

Clean up the entire setup by deleting the deployment with the command below:

$ kubectl delete deployment httpd-deployment

Conclusion

This article discussed 5 scenarios where you might want to restart Kubernetes Pods and walked you through 4 methods with kubectl. There is more to learn about kubectl. To learn more, check out the kubectl commands reference.

How to Deploy a Multi Container Docker Compose Application On Amazon EC2

Divine Odazie — Thu, 16 Mar 2023 01:24:32 +0000

This article was originally posted on Everything DevOps.

Container technology streamlined how you’d build, test, and deploy software from local environments, to the cloud or on-premise data centers. But with the benefit of building applications with container technology, there was the problem of manually starting and stopping each container while building multi-container applications.

To solve this problem, Docker Inc created Docker Compose. You can use Docker Compose to simplify the running of multi-container applications with as little as two commands; docker-compose up and docker-compose down.

In this article, you will learn

What Amazon EC2 is,
How to create and connect to an Amazon EC2 instance, and
How to deploy a Docker compose application on EC2

Prerequisites

To follow along in this article, you must have the following:

Basic knowledge of the terminal.
Some experience with Docker and Docker Compose.
An AWS account — Learn how to create one here.

What is Amazon EC2?

Amazon Elastic Compute Cloud (EC2) provides secure, resizable, and scalable computing capacity for virtually any workload in Amazon Web Services (AWS) Cloud. By using Amazon EC2, you can eliminate the overhead of investing in hardware up front so you can focus on developing and deploying your applications faster.

With Amazon EC2, you can launch as many or as few virtual servers (instances) as you need, configure security and networking, and manage storage. Also, Amazon EC2 enables you to easily scale your applications up or down to handle changes in requirements or spikes in popularity, reducing your need to forecast traffic.

To learn more about Amazon EC2, see the Amazon EC2 product page.

Creating and connecting to an Amazon EC2 instance

After creating an AWS account, you create and connect to an Amazon EC2 instance with the following steps:

Select your desired region for the instance
Navigate to the EC2 console
Launch the instance
Connect to the instance from your local computer via SSH

Selecting your desired region to deploy

To select a region on your AWS console, click the dropdown as annotated on the top right corner of the image below and select your desired region.

You may ask, “How would I know which region is best for my application?” To know the best region to deploy your application check out this article on “What to Consider when Selecting a Region for your Workloads.”

Navigating to the EC2 console

After selecting your desired AWS region, to go to the EC2 Console, search for “EC2” in the search box as in the image below.

Once you arrive on the EC2 console, locate the Launch Instance button and click on it to start a new EC2 instance launch flow.

Launch the instance

In the EC2 instance launch flow, you will be required to configure your instance with the following:

Application and OS Images (Amazon Machine Image): An Amazon Machine Image (AMI) is a template that contains the software configuration (operating system, application server, and applications) required to launch your instance.

This article will use a Linux Ubuntu Server 22.04 with the configurations seen in the image below.
Instance type: An ****Instance type is a combination of CPU, memory, storage, and networking capacity. There are various EC2 instance types to give you the flexibility to choose the appropriate mix of resources for your applications.

This article will use a t2.micro with the CPU and memory seen in the image below. To learn more about Amazon EC2 instance types, check out this documentation.

Key pair (login): You can use a key pair to securely connect to your instance remotely from your local computer. To create a key pair, click on Create new key pair as seen in the image below.

After clicking Create new key pair, you will see a pop up. In the popup, name your pair and leave the rest of the configurations as default (if your local computer is Windows OS, select .ppk private key file format), then click Create key pair.

After clicking Create key pair, a .pem private key file will be automatically downloaded on your computer; store the private key in a secure and accessible location on your computer. You will need it later to connect to your instance.

To learn more about Amazon EC2 key pairs, check out this documentation.

Network settings: You can leave the Network settings as default. The default network setting as in the image below uses:
- The default VPC and Subnet of your AWS account, and enables auto-assigning a public address to your instance.
- It also creates a new security group, a set of firewall rules that control the traffic for your instance. The default is the allow SSH traffic from anywhere; this works for this article, but in production use cases, you should set more strict rules.

Configure storage: You can leave the storage configuration as default for this article.

The last configurations are the advanced settings, you can ignore them as they are out of scope of this article. To learn more about them click the Info text as seen in the image below.

After all the above configurations, click on Launch instance and wait a few mins for your instance to launch as in the image below.

Then click on View all Instances as in the above image and select the instance as in the image below.

Connect to your Amazon EC2 instance

With your EC2 instance selected, at the top as annotated in the image below, click Connect.

After clicking Connect you will see a page with options to connect to your instance. This article will us the SSH client option.

Follow the steps you see on the page as in the image below using the .pem private key that was downloaded upon creation of you key pair.

After following the above steps, you should be connected to your instance like in the image below.

Next, you will deploy a demo multi container Docker Compose application that has a React frontend, Node.js backend and MongoDB database containers, and make it accessible on the internet.

Deploying a multi container Docker Compose application on Amazon EC2

Before you can deploy the Docker Compose application, you need to:

First install Docker Engine and Docker compose on your EC2 instance.
Then for this article clone the demo Todo Docker Compose application from Github on your instance
And then deploy the application

Installing Docker Engine on an Ubuntu EC2 instance
The quickest way to install the Docker engine is using the get-docker.sh bash script on get.docker.com. Run the command below to download the script on your EC2 instance.

$ curl -fsSL https://get.docker.com -o get-docker.sh

After running the above command confirm that it downloaded the get-docker.sh like the image below.

To run the script, run the following command:

$ sh get-docker.sh

And after a while Docker will be installed on the Ubuntu EC2 instance. To confirm the installation run $ docker --version and you should see the Docker version as in the image below.

If you used a different AMI, check out the Docker installation documentation to learn how to install on your choice AMI.

Installing Docker Compose on an Ubuntu EC2 instance
Now to install Docker Compose, run the following command to get the release from Github:\

$ sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

And then the following command to make it executable:

$ sudo chmod +x /usr/local/bin/docker-compose

With that done, when you run $ docker-compose -v, you should see the version you just installed as in the image below.

Cloning the demo Docker Compose application
The multi container todo application you will deploy is one of the Awesome Docker Compose Github repository samples.

To access the application, clone the repository on your instance with the following command:

$ git clone https://github.com/docker/awesome-compose.git

After cloning the project, run the following command to change into the react-express-mongodb directory where the todo application is:

$ cd awesome-compose/react-express-mongodb

Once in the project directory, to start the containers using compose.yaml file as annotated above run:

$ docker compose up -d

And after Docker pulls the images and creates the network for the containers to communicate with each other, you will see an output like in the image below.

To confirm that the 3 containers are running, run $ docker ps and you should see an output similar to the image below.

Next, you will test the deployment to be sure the todo application works.

Testing your deployment

The application you just deployed talks on port 3000 but if you visit port 3000 with the public address of your EC2 instance, you won’t be able to view it. This is because of the security group settings which currently only allows inbound traffic from SSH.

To enable viewing your application, on the EC2 instance console, with your EC2 instance selected, move to the Security tab and then click on the security group as in the image below.

After clicking on the security group, in the next menu, click on Edit Inbound rules to add the rule that allows inbound traffic through port 3000.

And then, add the rule as seen in the screenshot below.

With that done, when you visit the your_instance_public_ip:3000 you should see the Todo application as in the image below.

Conclusion

In this article, you learned what Amazon EC2 is, how to create and connect to an Amazon EC2 instance, and how to deploy a Docker compose application on EC2.

There is so much more to learn about Amazon EC2. To learn more, check out the following resources:

Best Practices when using Docker Compose

Divine Odazie — Tue, 27 Sep 2022 18:14:49 +0000

This article was originally posted on Hackmamba.

Container technology has streamlined how you’d build, test, and deploy software from local environments, to on-premise data centers, or the cloud. But while using container technology, a new problem of manually starting and stopping each container arose, making it tedious to build multi-container applications.

This article will discuss 4 best practices you should consider when using Docker Compose to orchestrate multi-container Docker applications. The best practices are:

Substitute environment variables in Docker Compose files
If possible, avoid multiple Compose files for different environments
Use YAML templates to avoid repetition
Use docker-compose up flags where necessary

Substitute Environment Variables in Docker Compose Files

Ideally, when defining a Compose file, you would have environment variables with secrets you wouldn’t want to push to any source code management platform like GitHub.

It is best to configure those environmental variables in the machine's shell, where you will deploy the multi-container application, so there are no secret leaks. And then populate the environment variables inside the Docker Compose file by substituting as seen below.

mongoDB:
    environment:
      - MONGO_INITDB_ROOT_USERNAME=${MONGO_INITDB_ROOT_USERNAME}
      - MONGO_INITDB_ROOT_PASSWORD=${MONGO_INITDB_ROOT_PASSWORD}

With the above configuration in your Docker Compose file, when you run docker-compose up, Docker Compose will look for the MONGO_INITDB_ROOT_USERNAME and MONGO_INITDB_ROOT_PASSWORD environment variables in the shell and then substitute their values in the file.

How to Add Environment Variables to your Shell
Ideally, to add to a shell, you would use export VARIABLE=<variable_value>. But with that method, if the host machine reboots, those environment variables will be lost.

To add environment variables that would persist through reboots, create an environment file with:

$ vi .env

And in that file, store your environment variables like in the image below and save the file.

Then in the root directory of your production machine, run $ ls -la, which should show you a .profile as shown in the image below.

Open up the profile file with $ vi .profile and at the end of the file, add this configuration:

set -o allexport; source /<path_to_the_directory_of_.env_file>/.env; set +o allexport

The above configuration will loop through all the environment variables you set and add them to your machine.

And to ensure the configuration takes effect, log out of your shell session, log back in, and then run:

$ printenv

You should see your environment variables, as shown in the image below.

Check out this documentation to learn more about best practices using environment variables in Docker Compose.

If Possible, Avoid Multiple Compose Files for Different Environments

Although Docker suggests defining an additional Compose file for a specific environment, e.g., docker-compose-prod.yaml for your production environment. This approach can cause issues as it is manual and error-prone when reapplying all modifications from one environment to another. Also, it increases the complexity of your development process when you consider CI, staging, or QA environments.

As a rule, you should always try to keep only a single Docker Compose file for all environments. But in cases where you might want to use nodemon to monitor changes in your node application during development. Or perhaps you would use a managed MongoDB database in production but run MongoDB locally in a container for development.

For these cases, you can use the docker-compose.override.yml file. As its name implies, the override file will contain configuration overrides for existing or entirely new services in your docker-compose.yaml file.

To run your project with the override file, you still run the default docker-compose up command. Then Docker Compose will automatically merge the docker-compose.yml and docker-compose.override.yml files into one. Suppose you defined a service in both files; Docker Compose merges the configurations using the rules described in Adding and overriding configuration.

You can add the override file to your .gitignore file, so it won't be there when you push code to production. After doing this, if you still see the need to create more Compose files, then go ahead but keep in mind the complexity.

Use YAML Templates to Avoid Repetition

When a service has options that will repeat in other services, you can create a template from the initial service to reuse in the other services instead of continuously repeating yourself.

The following illustrates Docker Compose YAML templating:

version: '3.9'
services:
  web: &service_default
    image: .
    init: true
    restart: always 
  backend:
    <<: *service_default # inheriting the service defaults definitions
    image: <image_name>
    env_file: .env
    environment:
      XDEBUG_CONFIG: "remote_host=${DOCKER_HOST_NAME_OR_IP}"

In the above YAML configuration, the first service defines restart: always, which will restart the container automatically if it crashes. Instead of adding restart: always and other recurring configs you might have to all your services, you can replicate them with <<: *service_default.

Check out this article to learn more about YAML templating capabilities for Docker Compose.

Use `docker-compose up` Flags Where Necessary

To make your development process a lot easier when creating and starting up containers with docker-compose up, you could use the features provided by docker-compose up flags.

To see these flags, you can run the command below in your terminal:
$ docker-compose up --help

Also, you can see them in the compose up command line reference, but viewing them on your terminal is easier during development.

Conclusion

This article discussed 4 best practices you should consider when using Docker Compose to orchestrate multi-container Docker applications. There are other best practices you can consider; to learn more about them, check out the following resources:

How to Set Environment Variables on a Linux Machine

Divine Odazie — Wed, 14 Sep 2022 15:41:38 +0000

This article was originally posted on Everything DevOps.

When building software, you start in a development environment (your local computer). You then move to another environment(s) (Staging, QA, etc.), and finally, the production environment where users can use the application.

While moving through each of these environments, there may be some configuration options that will be different. For example, in development, you may want to test CRUD operations with a dummy database with varying configuration values to the live database with real user data.

To ensure a seamless workflow and not have to regularly change the database configurations in code when moving to different environments, you can set environment variables for each.

In this tutorial, you will learn:

What environment variables are, and
How to set environment variables on a Linux machine.

Prerequisite

To follow along in this tutorial, you must have the following:

Basic knowledge of the terminal.
Access to a Linux machine — This article uses Ubuntu 22.04 (LTS) x64 distribution.

What are environment variables?

Environment variables are variables whose values are set outside the code of an application. They are typically set through the built-in functionality of an operating system. Environment variables are made up of name and value pairs, and you can create as many as you wish to be available for reference at a point in time.

Setting environment variables on a Linux machine

To set environment variables on a Linux machine, normally, in the shell session of your terminal, you would run the export command on each environment variable’s name and value like the following:

export ENVIRONMENT_VARIABLE_NAME = <value>

But doing so, if and when the particular shell session ends, all the environment variables will be lost. All the environment variables will be lost because the export command exports variables to the shell session’s environment, not the Linux machine environment.

To persist environment variables on a Linux machine, in any directory aside from your application’s directory, create an environment file with the vi editor using the following command:

$ vi .env

The above command will create and open a .env file, then to edit the file using the vi editor, press i and add your environment variables like in the image below.

After adding your environment variables, to save the file, press esc, then type :wq and press enter.

After saving the file, in the root directory of your Linux machine, run $ ls -la to view all files, including hidden ones, which should show you a .profile as in the image below.

Open up the profile file with $ vi .profile, press i to edit the file, and at the end of the file, add the following configuration:

set -o allexport; source /<path_to_the_directory_of_.env_file>/.env; set +o allexport

The above configuration will loop through all the environment variables you added to the .env file and set them on the Linux machine.

To save the configuration, press esc, then type :wq and press enter as you did previously.

To confirm that the configuration took effect and your environment variables have been set, log out of your current shell session, log back in and then run:

$ printenv

After running the above command, you should see your environment variables, as shown in the image below.

Conclusion

This tutorial explained environment variables and taught how to set them on a Linux machine. There is more to learn about environment variables in Linux. To learn more, check out the following resources:

Top 3 Security Risks Facing Infrastructure as Code and their Preventive Measures

Divine Odazie — Tue, 30 Aug 2022 08:00:53 +0000

This article was originally posted on Hackmamba.

Before Infrastructure as Code (IaC) managing IT infrastructure was a daunting task. System administrators, operation teams, and developers had to manually configure and manage all hardware and software required for applications to run.

With IaC, developers can quickly provision servers with specific operating systems, run containers, Kubernetes clusters, and even integrate third-party services using machine-readable templates.

Through IaC, organizations can build scalable and resilient software faster, reducing cost and addressing inconsistencies between the development and production environment. But with all these benefits, as with every software process, security risks exist.

This article discusses the top 3 security risks facing Infrastructure as Code and measures DevOps teams can take to avoid attacks. The top 3 security risks are:

Misconfigurations in IaC templates
Infrastructure drift
Ghost resources

Misconfigurations in IaC Templates

Misconfigurations in an IaC template (such as YAML files, Terraform, or Helm Charts) can easily expose an organization’s environment leaving them vulnerable to attacks.

According to this report by Palo Alto Networks, nearly 200,000 insecure IaC templates are in use in production environments, and most of these vulnerabilities are due to misconfigurations. On top of that, more than 43% of cloud databases are currently unencrypted and only 60% of cloud storage services have logging enabled.

Now one might ask, how do these misconfigurations happen, and why are they at this scale? They are at this scale because as more people write open source boilerplate templates and blog posts, most forget to review to ensure they conform to IaC security best practices.

The image below from this talk on Infrastructure-as-code Security shows data of misconfigured open source Terraform modules.

And those misconfigured modules were downloaded 10 million times, as seen in the image below.

Although services provisioned with those misconfigurations aren’t necessarily exploitable, they still pose a huge risk.

How to Prevent IaC Template Misconfigurations

To prevent IaC template misconfigurations, DevOps teams must scan for these templates during pre-production. Scanning for misconfigurations in IaC pre-production templates means introducing checks and remediation during the development phase and represents a fundamental step for a secure DevOps workflow.

To integrate this step into their DevOps workflow, organizations can use tools like Bridgecrew to track every change in their IaC, scan those changes, and automatically fix misconfigurations before they move to the production environment.

Infrastructure Drift

In IaC, the concept of drift represents the difference between the originally defined values in a configuration to what’s running in production. A drift can be introduced by external actors (humans or scripts) or the IaC dependency on external data sources.

Drifts by External Actors
If an on-call SRE (site reliability engineer) logs on to the Cloud environment and manually creates or modifies resources otherwise controlled by Terraform, they introduce a drift. Also, suppose an external script updates a Kubernetes cluster in a way that conflicts with its CloudFormation definition; in that case, that is a drift as well.

Drifts by External Data Sources
If there's any change to the external data source it will show up as a drift too. For example, if a load balancer only expects to receive traffic from Amazon CloudFront, the DevOps team may want to restrict ingress to a predefined range of IP addresses. However, that range may be dynamic and their IaC tool queries it every time it runs.

When any of the above drift occurs, if unmanaged, it can lead to:

Data breaches
Application downtime
Possible Deployment failures

How to Mitigate Infrastructure Drift

In the above scenarios, the drift caused by external actors is an unwanted by-product of emergencies or broken processes. The drift caused by external data sources is both desired and inevitable. That said, it is clear that drift occurs and teams can’t entirely prevent it.

But what can teams do? Well, what DevOps teams can do is to detect and reconcile drifts as they happen. See how the following tools can help teams detect and reconcile drifts:

Ghost Resources

Tagging cloud assets during development is critical to ensure compliance and governance in IaC. Failing to tag assets during IaC operations can result in “ghost” resources. These untagged assets are hard to detect and difficult for developers to observe as the observability of these assets may not be equivalent to the rest of the system.

Ghost assets can go undetected for long periods while consuming resources and creating potential attack vectors for an organization's infrastructure as code. In addition to the implications on security, ghost resources make it very challenging to assess the effect on operations like cost, maintenance, and reliability.

How to Prevent Ghost Resources

The only way to mitigate ghost resources is by careful tagging and monitoring for untagged resources.

Conclusion

This article explained the top 3 security risks facing Infrastructure as Code and measures DevOps teams can take to avoid attacks.

To learn more about other security risks facing IaC, check out the following resources:

How to avoid merge commits when syncing a fork

Divine Odazie — Mon, 22 Aug 2022 01:19:00 +0000

This article was originally posted on Everything DevOps.

Whenever you work on open source projects, you usually maintain your copy (a fork) of the original codebase. To propose changes, you open up a Pull Request (PR). After you create a PR, there are chances that during its review process, commits will be made to the original codebase, which will require you to sync your fork.

To sync your fork with the original codebase, ideally, you would use the web UI provided by your Git hosting service or run a git fetch and git merge in your terminal, as indicated in this Github tutorial. But with a PR open, syncing your fork that way will introduce an unwanted merge commit to your PR.

In this article, you will learn what merge commits are and how to avoid them with git rebase when syncing a fork with an original codebase.

What is a merge commit?

A merge commit is just like any other commit, it is the state of a repository at a point in time plus the history it evolved from. But there is one thing unique about a merge commit: it has at least two parent commits.

When you create a merge commit, Git automatically merges the histories of two separate commits. This merge commit can cause conflicts and mess up a project’s Git history if present in a merged PR.

The annotated section in the image above shows a merge commit of two parent commits. Here is the link to the merge commit to the image.

Now you know what a merge commit is. Next, you will learn how to avoid it when syncing your fork with an original codebase.

How to avoid merge commits when syncing a fork in Git.

**
To avoid merge commits, you need to rebase the changes from the original remote codebase in your local fork before pushing them to your remote fork by following the steps below.

Step 1:
Create a link with the original remote repository to track and get the changes from the codebase with the command below:

$ git remote add upstream https://github.com/com/original/original.git

After running the above command, you will now have two remotes. One for your fork and one for the original codebase. If you run $ git remote -v, you will see the following:

origin https://github.com/your_username/your_fork.git (fetch)
origin https://github.com/your_username/your_fork.git (push)
upstream https://github.com/original/original.git (fetch)
upstream https://github.com/original/original.git (push)

In the above, upstream refers to the original repository from which you created the fork.

Step 2:
In this step, you fetch all the branches of the remote upstream with:

$ git fetch upstream

Step 3:
Next, you rewrite your fork’s master with the upstream’s master using git rebase.

$ git rebase upstream/master

Step 4:
Then finally, push the updates to your remote fork. You may need to force the push with “--force.”

$ git push origin master --force

Note:
You can skip the git fetch step by using git pull which is git fetch + git merge but with the --rebase flag to override the git merge. The pull command will be:

$ git pull --rebase upstream master

Conclusion

In this article, you learned about merge commits and how you can avoid them when syncing your fork in Git using git rebase. There is a lot more to learn about git rebase. To learn more, check out the following resources:

Building x86 Images on an Apple M1 Chip

Divine Odazie — Tue, 16 Aug 2022 15:00:00 +0000

This article was originally posted on Everything DevOps.

A few months ago, while deploying an application in Amazon Elastic Kubernetes Service (EKS), my pods crashed with a standard_init_linux.go:228: exec user process caused: exec format error error.

After a bit of research, I found out that the error tends to happen when the architecture an image is built on differs from the architecture it is running on. I then remembered that I was building the image on a MacBook with Apple M1 Chip which is based on ARM64 architecture, and the worker nodes in the EKS cluster I deployed on are based on x86 architecture.

I had two options to fix the error: create new ARM-based worker nodes or build the image on x86 architecture. I couldn’t create new worker nodes for obvious reasons, so I had to figure out how to build x86 images on my Apple M1 chip.

In this article, I will walk you through how I built my application’s Docker image with x86 architecture on an Apple M1 chip using Docker Buildx.

What is Docker Buildx?

Docker Buildx is a CLI plugin that extends the docker command. Docker Buildx provides the same user experience as docker build with many new features like the ability to specify the target architecture for which Docker should build the image. These new features are made possible with the help of the Moby BuildKit builder toolkit.

Before you can build x86-64 images on an Apple M1 chip with Docker Buildx, you first need to install Docker Buildx.

Installing Docker Buildx

If you use Docker Desktop or have Docker version 20.x, Docker Buildx is already included in it, and you don’t need a separate installation. Verify that you have Docker Buildx with:

docker buildx version

But if you are like me that use another tool to get the Docker runtime, install Docker Buildx through the binary with the following commands:

$ ARCH=arm64
$ VERSION=v0.8.2

The above commands set temporary environment variables for the architecture and version of the Docker Buildx binary you will download. See the Docker Buildx releases page on GitHub for the latest version.

After setting the temporary environment variables, download the binary with:

$ curl -LO https://github.com/docker/buildx/releases/download/${VERSION}/buildx-${VERSION}.darwin-${ARCH}

After downloading the binary, create a folder in your home directory to hold Docker CLI plugins with:

$ mkdir -p ~/.docker/cli-plugins

Then move the binary to the Docker CLI plugins folder with:

$ mv buildx-${VERSION}.darwin-${ARCH} ~/.docker/cli-plugins/docker-buildx

After that, make the binary executable with:

$ chmod +x ~/.docker/cli-plugins/docker-buildx

To verify the installation, run:

$ docker buildx version

Building x86-64 images on an Apple M1 chip with Docker Buildx

After installing Docker Buildx, you can now easily build your application image to x86-64 on an Apple M1 chip with this command:

$ docker buildx build --platform=linux/amd64 -t <image-name> .

In the above command:

buildx builds the image using the BuildKit engine and does not require the DOCKER_BUILDKIT=1 environment variable to start the builds.
The --platform flag specifies the target architecture (platform) to build the image for. In this case, linux/amd64, which is of x86 architecture.
And the <image-name> is a placeholder for putting an image tag.

To verify that Docker built the image to linux/amd64, use the docker image inspect <image_name> command as you can see annotated screenshot above.

The inspect command will display detailed information about the image in JSON format. Scroll down, and you should see the Architecture and Os information as in the image below.

Conclusion

This article explored building images based on x86 architecture on an Apple M1 chip using Docker Buildx. There is so much more to learn about Docker Buildx. To learn more, check out the following resources:

Kubernetes Architecture Explained: Worker Nodes in a Cluster

Divine Odazie — Mon, 08 Aug 2022 19:07:15 +0000

This article was originally posted on Everything DevOps.

When you deploy Kubernetes, you get a cluster. And the cluster you get upon deployment would consist of one or more worker machines (virtual or physical) called nodes for you to run your containerized applications in pods.

For each worker node to run containerized applications, it must contain a container runtime for running the containers, a kubelet to ensure everything runs, and the kube-proxy for handling networking.

In this article, you will learn more about what each of the above components does to enable the running of containerized applications in a Kubernetes cluster.

Prerequisites

To properly understand this article, you should have an understanding of the Kubernetes control plane.

Container runtime

The container runtime in a worker node is responsible for running containers. The container runtime is also responsible for pulling container images from a repository, monitoring local system resources, isolating system resources for the use of a container, and managing the container lifecycle.

In Kubernetes, there is support for container runtimes such as:

containerd: An industry-standard container runtime with an emphasis on simplicity, robustness, and portability.
CRI-O: A lightweight container runtime specifically built for Kubernetes.
And any other implementation of the Kubernetes Container Runtime Interface (CRI) — a plugin enabling the kubelet to use other container runtimes without recompiling.

You may wonder why you didn’t see Docker (a major container runtime) in the list above. Docker isn’t there because of the removal of dockershim — the component that allows use of Docker as a container runtime — in Kubernetes release v1.24.

But not to worry, you can still use Docker as a container runtime in Kubernetes using the cri-dockerd adapter. cri-dockerd provides a shim for Docker Engine that lets you control Docker via the Kubernetes CRI. ****

kubelet

The kubelet is the primary Kubernetes node agent. The kubelet is responsible for running the containers for the pods scheduled to its node. The kubelet runs on every machine (control plane, too) in the cluster.

The kubelet for each node keeps a watch on pod resources in the control plane’s kube-apiserver. Whenever the kube-scheduler assigns a pod to a node, the kubelet for that node reads the PodSpec (a YAML or JSON object that describes a pod) and instructs the container runtime using the CRI to spin up containers to satisfy that spec. The container runtime will then pull the container images if they aren’t present in the node and start them.

It is important to note that the kubelet is a Kubernetes component that does not run in a container. The kubelet, along with the container runtime, are installed and run directly on the machine that forms the node in the cluster, and that’s why they are responsible for managing the containerized workloads.

kube-proxy

Like the kubelet, kube-proxy runs on every node in the cluster, but unlike the kubelet, kube-proxy typically runs in a Kubernetes pod as a part of a Kubernetes DaemonSet.

kube-proxy implements essential functionalities for Kubernetes services. kube-proxy maintains network rules that allow communication to your Pods from network sessions inside or outside your cluster.

To dig deep into kube-proxy’s role, you must understand how Service resources work in Kubernetes.

Service in Kubernetes
A Service provides a stable IP address for connecting to pods. There are Service resources in Kubernetes because without them:

When a client application needs to connect to server pods in a cluster, it would need to retrieve and maintain a list of each pod’s IP address, which will burden the client.
And also, it will be hard to maintain those connections, seeing that in Kubernetes, pods will come and go due to scaling, update or hardware failure.

With the above setup using a Service resource, the client will just need the address of the Service, and the rest is taken care of for you automatically.

And how that’s taken care of automatically is that when you create a Service with a selector that references a label applied to a set of pods, the Endpoints controller in the kube-controller-manager will create an Endpoints resource with the pods IP addresses. In the Endpoints resource, the addresses are maintained and if they change, they will be updated automatically and the client’s requests routed accordingly.

In the above image, you might get the impression that a Service is a literal proxy that load balances requests to backends like Nginx. But that’s almost not the case in modern Kubernetes clusters.

Now with your understanding of Service resources, let’s dig into how kube-proxy implements essential functionalities for Kubernetes services.

How kube-proxy implements functionalities for Kubernetes Service resources.
There is an Endpoints controller in the kube-controller-manager that manages the endpoint resources. The Endpoints controller also manages the associations between services and pods.

With the kube-proxy running on each node in the cluster, it watches Service and Endpoint resources. So when a change that needs updating occurs, the kube-proxy will update the rules in iptables. iptables is a network packet filtering utility that allows rules to be set in the network stack of the Linux kernel.

Now, when a client pod sends a request to a Service’s IP, the Linux kernel routes the request to one of the pod’s IP according to the rule kube-proxy sets.

Note: kube-proxy supports alternatives to using iptables to manage network packet routing. But iptables is the most common and suitable for the majority of installations.

Also, note that with iptables, the pod selection will be random. It would not be round robin or other common load balancing strategies. For load balancing, you will need to use IPVS (IP Virtual Server), an alternative to iptables that implements a layer for load balancing in the Linux kernel.

Also, It is important to point out that a Service’s IP is a “virtual IP”, so if you try to ping that IP, you won’t get a response the way you usually would if you ping a pod’s IP, which is an actual endpoint on the network.

A Service’s IP is essentially a key in the rules set by iptables that gives network packet routing instructions to the host’s kernel. But the important part is that a client pod can use the Service IP like it usually would and get the expected behavior as if it were calling an actual pod IP.

Conclusion

This article explained the roles of the container runtime, kubelet, and kube-proxy components in a Kubernetes worker node. There is so much more to learn about these three node components.

To learn more, check out the following resources:

DEV Community: Divine Odazie

Can you use just any Kubernetes project in your regulated environment?

k8sprojects.com The Kuberentes Review Platform

Optimize AWS Storage Costs with Amazon S3 Lifecycle Configurations

S3 storage classes you can move data to

Use cases of Amazon s3 lifecycle configurations

Components of an s3 lifecycle configuration

ID

Filters

Status

Actions

Step-by-Step Guide: How to Create a Lifecycle Configuration on an S3 Bucket (DEMO)

Key Considerations for Creating S3 Lifecycle Configurations

Moving between storage classes

Lifecycle configuration costs

Conclusion

Rapid development on AWS EKS using Garden

What is Garden.io?

How does Garden work?

Prerequisites

Configuring a project for use with Garden

Connecting to the EKS Cluster and ECR container registry

Deploying and testing the Garden project

Conclusion

How to restart Kubernetes Pods with kubectl

4 scenarios where you might want to restart a Pod

Restarting Kubernetes pods with kubectl

Restarting Kubernetes Pods by changing the number of replicas

Downtimeless restarts with Rollout restart

Automatic restarts by updating the Pod’s environment variable

Restarting Pods by deleting them

Cleaning up

Conclusion

How to Deploy a Multi Container Docker Compose Application On Amazon EC2

Prerequisites

What is Amazon EC2?

Creating and connecting to an Amazon EC2 instance

Selecting your desired region to deploy

Navigating to the EC2 console

Launch the instance

Connect to your Amazon EC2 instance

Deploying a multi container Docker Compose application on Amazon EC2

Testing your deployment

Conclusion

Best Practices when using Docker Compose

Substitute Environment Variables in Docker Compose Files

If Possible, Avoid Multiple Compose Files for Different Environments

Use YAML Templates to Avoid Repetition

Use docker-compose up Flags Where Necessary

Conclusion

How to Set Environment Variables on a Linux Machine

Prerequisite

What are environment variables?

Setting environment variables on a Linux machine

Conclusion

Top 3 Security Risks Facing Infrastructure as Code and their Preventive Measures

Misconfigurations in IaC Templates

How to Prevent IaC Template Misconfigurations

Infrastructure Drift

How to Mitigate Infrastructure Drift

Ghost Resources

How to Prevent Ghost Resources

Conclusion

How to avoid merge commits when syncing a fork

What is a merge commit?

How to avoid merge commits when syncing a fork in Git.

Conclusion

Building x86 Images on an Apple M1 Chip

What is Docker Buildx?

Installing Docker Buildx

Building x86-64 images on an Apple M1 chip with Docker Buildx

Conclusion

Kubernetes Architecture Explained: Worker Nodes in a Cluster

Prerequisites

Container runtime

kubelet

kube-proxy

Conclusion

Use `docker-compose up` Flags Where Necessary