DEV Community: EverythingDevOps

Introduction to Multi-Cluster Deployment in Kubernetes

Onyeanuna prince — Fri, 09 Aug 2024 09:05:36 +0000

When starting out with Kubernetes, you've probably used a single cluster architecture. This architecture is easy to set up and allows you to enjoy the benefits of scaling and deploying your applications. If you've used this setup for a long time and on much larger projects, then you must have started to notice the cracks in this architecture.

As your project grows, you'll start to notice specific bottlenecks of a single Kubernetes cluster architecture. These bottlenecks include resource constraints, fault isolation, geographic distribution, and others. However, there's a solution—multi-cluster architecture.

In this article, you'll understand how multi-cluster architecture in Kubernetes solves these bottlenecks and why it's important. In the end, you'll have the right amount of information to help you decide whether to use a single or multi-cluster architecture in your project.

What are Kubernetes multi-clusters?

Multi-clusters in Kubernetes are the deployment of several clusters across different data centres or cloud regions. In terms of your application, it means using more than one Kubernetes cluster to deploy and manage your product.

A multi-cluster setup can really come in handy when looking to offer optimum uptime. By distributing your application across multiple clusters, you can ensure that your services remain available even if one cluster experiences a failure.

Why do you need multiple clusters?

There are some reasons why most engineers consider using a multi-cluster architecture. Below are some of these reasons:

Scalability

With multi-cluster setups, you can better distribute your resources across several clusters. This makes it possible to scale your application more effectively to take on higher traffic and prevent any cluster from becoming a bottleneck.

Reduced blast radius

Blast radius refers to the extent of impact that a failure in one part of a system can have on the rest of the system. It measures how far-reaching the consequences of an incident can be. By relying on a multi-cluster architecture, you ensure that only a limited part of your system gets affected in the event of an outage or security breach.

Geographical redundancy and disaster recovery

Deploying your clusters in different geographical regions ensures that your application can withstand regional failures, such as natural disasters or network outages. This geographical spread also ensures quick failover and data recovery from unaffected clusters.

Reduced latency

When you place several clusters close to end-users, you greatly reduce the time it takes to process requests on your applications. This is particularly beneficial for global applications that serve users from various locations around the world.

Isolation

Rather than using namespaces in a single Kubernetes cluster, multi-clusters can provide better isolation for various development stages (development, testing, production). This isolation method enhances security by reducing the risk of cross-environment contamination and unauthorized access.

Operational flexibility

When performing maintenance, updates, or any scaling operation, you can decide to carry it out on any one of your clusters. This ensures that you're not affecting the entire system. This flexibility offers smoother operations and less disruption to services.

What does a multi-cluster architecture look like?

In practice, let's say you're working on a project, and you want to use a multi-cluster architecture for it. You can use any method of provisioning your Kubernetes clusters, but in this case, you're relying on Amazon Elastic Kubernetes Service (EKS) and Google Kubernetes Engine (GKE).

Figure 1: Multi-cluster architecture between AWS and GCP

First, you start by provisioning the EKS cluster in AWS and the GKE cluster in Google Cloud. Both clusters are fully functional Kubernetes environments set up in their respective cloud providers.

Next, to enable communication between the clusters, you can set up VPN connections between the AWS VPC and the Google Cloud VPC. This establishes a secure link that allows the clusters to communicate with each other.

After this, you'll install Cilium as the networking plugin (CNI) on both the EKS and GKE clusters. This involves installing Cilium's agents and configuring the clusters to use Cilium for networking. At this point, Cilium doesn't bother about how both clusters are connected but rather if their endpoints are reachable.

You can then configure Cilium's cluster mesh feature, which will integrate the clusters into a single, unified network. This involves configuring Cilium to recognize the other cluster and allowing services and pods in the EKS cluster to communicate seamlessly with those in the GKE cluster.

Finally, you'll deploy applications or services across the clusters and verify that they can interact as expected. With Cilium's cluster mesh, your EKS and GKE clusters are now interconnected, and your multi-cluster setup should work perfectly.

When to use a multi-cluster architecture

Depending on your organization's goals or your application's requirements, you must consider certain measures when choosing your product's architecture.

High availability

Let's say the primary goal of your application - as it is with 100% of other products - is to offer maximum uptime and remain operational even during regional outages or disasters.

In this case, you can consider deploying clusters in multiple geographical regions to ensure that if one cluster goes down, others can take over, providing uninterrupted service.

Geographical distribution

If you already have a large organization with a global user base or you're growing quickly, you can minimize latency by serving users based on location.

By setting up clusters in various regions much closer to your users, you reduce latency and improve the user experience by routing traffic to the cluster closest to them.

Workload segmentation

If your application has unique requirements for its resources, security, or infrastructure, you can use distinct clusters to cater to the specific needs of different workloads. For instance, you can separate machine learning workloads from standard web applications.

Cross-cloud strategy

Let's say your organization currently relies on multiple cloud providers for specific reasons, such as preventing vendor lock-in, utilizing specific resources, or ensuring redundancy. You can consider deploying your clusters across the different cloud providers to leverage each provider's best features.

Conclusion

In this article, we defined a multi-cluster and showed how its architecture works in practice. We also discussed some reasons why you might consider using it and what to look out for when making your choice.

Always remember that a multi-cluster architecture is handy when you need to ensure high availability, minimize latency, and perform maintenance without downtime.

Monitoring, Observability, and Telemetry Explained

Onyeanuna prince — Tue, 02 Apr 2024 19:39:44 +0000

This article was originally posted on EverythingDevOps.

Whenever something goes wrong in a system or application, it affects the customers, the business performance, and of course, the Site Reliability Engineers (SREs) who stay up late to fix it.

While engineers often use terms/tools such as monitoring, observability, and telemetry interchangeably, they aren't the same things. Monitoring sets triggers and alerts that go off when an event occurs, Telemetry gathers system data, and Observability lets you know what's going on in the system.

The trio is responsible for quickly restoring downtime within organizations; however, to utilize them effectively, you need to understand their significant differences and how they work together. By the end of this article, you will have a clear understanding of how each concept works and how they can be combined to ensure your system is reliable.

What is Monitoring?

After deploying an application, to ensure that there are little to no downtimes, several post-deployment practices are put in place. One of such practices is monitoring.

Monitoring can be defined as the continuous assessment of a system's health and performance to ensure that it is running as expected. With monitoring, you don't have to wait for a customer to report an issue before you know that something is wrong. Its triggers and alerts are set to go off when an event occurs.

In monitoring, you define what "normal" means for your system and set up alerts to notify you when the system deviates from that normal state. For example, you could set up an alert to notify you when the CPU usage of your server exceeds 80%. This way, you can take action before the server crashes.

Monitoring not only gives you an insight into the health of your system but also helps you to identify trends and patterns in the system. This helps you know how the application has been used over time and makes it easier to predict future issues.

Types of Monitoring

Although the concept of monitoring stays the same, its application differs. This difference is due to the diverse nature of IT environments, the complexity of systems, varied use cases, and emerging technologies and trends.

There are different types of monitoring, each designed to monitor a specific aspect of the system. Some of these types include:

Application Performance Monitoring (APM): APM focuses on monitoring the performance and availability of software applications. It involves tracking metrics related to response times, throughput, error rates, and resource utilization within the application. APM tools provide real time insights into application bottlenecks, code inefficiencies, and user experience issues.

Infrastructure Monitoring: This type of monitoring focuses on the health and performance of physical and virtual infrastructure such as servers, networks, and storage. It includes monitoring the CPU utilization, memory usage, disk space, and network bandwidth to ensure optimal performance.

Network Monitoring: It involves monitoring the performance of network infrastructure and traffic. It includes the monitoring of devices such as routers, switches, firewalls, and load balancers, as well as the analysis of network traffic patterns, packet loss, latency, and bandwidth utilization. Network monitoring helps ensure optimal network performance, troubleshoot connectivity issues, and detect security threats.

Log Monitoring: Log monitoring involves collecting, analyzing, and correlating log data generated by systems, applications, and devices. It helps organizations track system events, troubleshoot issues, and ensure compliance with regulatory requirements. Log monitoring tools provide centralized log management, real-time alerting, and advanced analytics capabilities to facilitate log analysis and investigation.

Security Monitoring: This type of monitoring focuses on detecting and responding to security threats and vulnerabilities. It involves monitoring network traffic, system logs, and user activities to identify suspicious behaviour, unauthorized access, and security breaches. Security monitoring tools provide real-time threat detection, incident response, and security analytics capabilities to help organizations protect their sensitive data.

Cloud Monitoring: Cloud monitoring involves monitoring the performance and availability of cloud-based infrastructure and services. It includes monitoring cloud resources such as virtual machines, storage, databases, and containers, as well as tracking cloud service metrics provided by cloud service providers (CSPs). Cloud monitoring helps organizations optimize cloud resource utilization, manage costs, and ensure service uptime and reliability.

End-User Monitoring (EUM): This type of monitoring focuses on tracking the experience of end-users interacting with applications and services. It involves measuring metrics such as page load times, transaction completion rates, and user interactions to assess application performance from the end-user perspective. EUM tools provide insights into user behaviour, application performance, and service availability to help organizations deliver a seamless end-user experience.

What's the Problem with Legacy Monitoring?

The term "legacy" refers to outdated systems, technologies, or practices that are no longer efficient or effective. Legacy monitoring is the traditional approach to monitoring that is no longer sufficient for modern IT environments.

The problem with legacy monitoring is that it is not designed to handle the complexity, scale, and dynamism of modern systems and applications. Legacy monitoring tools are often siloed, inflexible, and unable to provide the level of visibility and insights required to manage modern IT environments effectively.

Some of the challenges associated with legacy monitoring include:

Lack of Scalability: Legacy monitoring systems often lack scalability to handle the growing volume, variety, and velocity of data generated by modern IT infrastructure and applications. As organizations scale their operations and adopt new technologies, legacy systems may struggle to keep up, leading to performance degradation and gaps in monitoring coverage.

Limited Visibility: Legacy monitoring tools provide limited visibility into the complex interactions and dependencies within modern IT ecosystems. They often focus on monitoring individual components in isolation, rather than providing holistic insights into system behavior and performance across the entire technology stack. This limited visibility hampers the ability to detect and diagnose issues that span multiple layers of the infrastructure.

Limited support and updates: Legacy monitoring systems are often inflexible and difficult to adapt to changing business requirements, technologies, and use cases. They may lack support for modern deployment models such as cloud computing, containerization, and microservices, making it challenging to monitor dynamically orchestrated environments effectively.

Inadequate Security Monitoring: Legacy monitoring systems may lack robust security monitoring capabilities to detect and respond to cybersecurity threats effectively. As cyberattacks become more sophisticated and targeted, organizations require advanced security monitoring tools that can analyze large volumes of security data in real time and provide actionable insights to mitigate risks.

A Historical Overview of Monitoring and Observability

Since the advent of computing technology and IT management practices over the past decade, monitoring and observability have also evolved. During the early days of computing, primitive monitoring tools focused on hardware components, paving the way for more sophisticated monitoring tools during the mainframe era.

With the popularity of computer networks, network management protocols like SNMP became available, enabling administrators to monitor and manage network resources. The growth of enterprise IT environments, platforms like HP OpenView and IBM Tivoli emerged, providing centralized monitoring and management capabilities for diverse infrastructures.

In the 2000s, as web-based applications and distributed architectures became increasingly popular, Application Performance Management (APM) solutions emerged, monitoring software applications and user experiences.

In 2010, cloud computing and DevOps practices revolutionized IT operations, introducing new challenges and opportunities for monitoring and observability. The development of cloud-native monitoring and DevOps tools enabled organizations to monitor dynamic environments using features such as infrastructure-as-code and containerization. Additionally, observability emerged, emphasizing the importance of understanding system behaviour from rich telemetry and contextual information.

In this way, observability platforms provided insights into complex systems that allowed troubleshooting, debugging, and optimization to be easily accomplished. From early hardware monitoring to modern observability platforms, IT infrastructure and applications have been continually monitored and controlled to gain greater visibility, insight, and control.

Why Observability?

Observability refers to the ability to understand and analyze the internal state of a system based on its external outputs or telemetry data. Observable systems allow users to find the root cause of a performance issue by inspecting the data they generate.

By implementing telemetry-producing tools in systems, you can gather comprehensive data about the system's interactions, dependencies, and performance. Through correlation, analysis, visualization, and automation, observability platforms provide meaningful insights based on this data.

Differences between Observability and Monitoring

The distinction between observability and monitoring lies in their focus, approach, and objectives within IT operations.

Monitoring primarily involves the systematic continuous collection and analysis of predefined metrics and thresholds to track the health, performance, and availability of systems, applications, or services. It operates on the principle of setting triggers and alerts to signal deviations from expected behaviour, enabling reactive management and troubleshooting.

Observability, on the other hand, shifts the focus from predefined metrics to gaining a deeper understanding of system behaviour and interactions. It emphasizes the need for rich, contextual data and insights into the internal state of a system, captured through telemetry data. Observability enables organizations to explore and analyze system behaviour in real time, facilitating troubleshooting, debugging, and optimization efforts.

While monitoring focuses on predefined metrics to track system health and performance, observability emphasizes the need for telemetry data of the system's behaviour to facilitate deeper understanding and analysis. Monitoring is reactive, while observability is proactive, empowering organizations to detect, diagnose, and resolve issues more effectively in complex distributed systems.

A Brief Intro to Telemetry Data

Telemetry data refers to the collection of measurements or data points obtained from remote or inaccessible systems, devices, or processes. This data typically includes information about the operational status, performance metrics, logs, and behaviour of these systems.

The role of telemetry data is to provide insights into how systems operate, how they interact with each other, and how they perform over time. By analyzing telemetry data, organizations can gain a deeper understanding of their systems, identify patterns, detect anomalies, and make informed decisions to optimize performance, enhance reliability, and troubleshoot issues effectively.

Comparisons and Relationships

Monitoring focuses on tracking the health and performance of systems through predefined thresholds. It typically involves collecting metrics related to system resource utilization, response times, error rates, and other key performance indicators (KPIs). Monitoring provides a high-level view of system health and performance, alerting operators to potential issues or deviations from expected behaviour.

Telemetry focuses on collecting data such as logs, metrics, and traces from systems, especially in dynamic cloud environments. While telemetry provides robust data collection and standardization, it lacks the deep insights needed for quick issue resolution.

Observability goes beyond telemetry by offering analysis and insights into why issues occur. It provides detailed, granular views of events in an IT environment, enabling custom troubleshooting and root cause analysis.

APM, while similar to observability, focuses specifically on tracking end-to-end transactions within applications. It offers high-level monitoring of application performance but may not provide the technical details needed for deep analysis.

Overall, telemetry and APM provide monitoring capabilities while observability offers deeper insights into system behaviour and performance, enabling effective troubleshooting and analysis across IT infrastructure.

The Transition from Monitoring to Observability

Imagine a company that operates an e-commerce platform. In the past, they could rely solely on traditional monitoring tools to track the health and performance of their system. These tools would provide the basic metrics such as CPU usage, memory utilization, and response times for their web servers and databases.

However, as their platform grows in complexity and scale, they might frequently encounter issues that traditional monitoring tools can no longer address adequately. For example, during a high-traffic event like a flash sale, they could notice occasional spikes in latency and occasional errors occurring in their checkout process. While they can see these issues occurring, they will struggle to pinpoint the root cause using traditional monitoring alone.

To address these challenges, this company must adopt observability practices. By implementing telemetry solutions that collect a broader range of data, including detailed logs, distributed traces, and custom application metrics. With this richer dataset, they'll gain deeper insights into their system's behaviour and performance.

They can now trace individual requests as they flow through their microservices architecture, allowing them to identify bottlenecks and latency issues more effectively. They can also correlate application logs with system metrics to understand how the changes in application code affect the overall system health.

By transitioning to observability, this company gains a more comprehensive understanding of its system's behaviour and performance. They can proactively identify and resolve issues, leading to improved reliability and a better user experience for their customers.

Choosing the Right Tool

Choosing the right observability tool is crucial for ensuring the reliability of modern software systems. Below are key factors to consider when selecting an observability tool for your organization:

Data Collection: Look for a tool capable of collecting and aggregating data from various sources like logs, metrics, and traces - the three pillars of observability. Before choosing a tool, ask yourself, "Can this tool handle the diverse data sources present in our infrastructure, and can it process high volumes of data in real time?" Example tools include Datadog, Splunk, and New Relic.

Visualization and Analysis: Choose a tool with intuitive and customizable dashboards, charts, and visualizations. A question to ask is, "Are the visualization features of this tool user-friendly and adaptable to our team's specific needs?" Tools like Grafana and Kibana provide powerful visualization capabilities.

Alerting and Notification: Select a tool with flexible alerting mechanisms to proactively detect anomalies or deviations from defined thresholds. Consider asking questions like "Does this tool offer customizable alerting options and support notification channels that suit our team's communication preferences?" A tool like Prometheus provides robust alerting capabilities.

Scalability and Performance: Consider the scalability and performance capabilities, especially if your organization handles large volumes of data or has a growing user base. Ask yourself, "Is this tool capable of scaling with our organization's growth and maintaining performance under increased data loads?" You can utilize a tool like InfluxDB for scalable time-series data storage.

Integration and Compatibility: Assess compatibility with your existing software stack, including infrastructure, frameworks, and programming languages. To make this assessment, ask yourself, "Does this tool seamlessly integrate with our current technologies and support the platforms we use, such as Kubernetes or cloud providers?" Most observability tools are open-source and support a wide range of integrations.

Extensibility and Customization: Evaluate the tool's extensibility to incorporate custom instrumentation and adapt to specific application requirements. Ask yourself, "Can we easily extend the functionality of this tool through custom integrations and configurations to meet our unique monitoring needs?"

By considering these questions, you can make a more informed decision when selecting an observability tool for your organization.

Conclusion

This article has explored the vital aspects of observability and monitoring in modern IT operations. It covered the role of telemetry data, compared observability with related concepts, illustrated the transition from traditional monitoring to observability, and discussed key factors in selecting observability tools.

Throughout, we've emphasized the importance of balancing monitoring and observability for efficient IT operations, highlighting how a comprehensive approach can provide deep insights and enhance system reliability in today's dynamic digital landscape.

By understanding the differences between monitoring, observability, and telemetry, and by leveraging the right tools and practices, DevOps teams can gain a deeper understanding of their systems, proactively identify and resolve issues, and optimize performance to deliver a seamless user experience.

Taking Backup of your Kubernetes etcd Data: A step-by-step guide

omkar kulkarni — Wed, 01 Nov 2023 14:35:32 +0000

This article was originally posted on Everything DevOps.

In the ever-evolving landscape of container orchestration, Kubernetes (K8s) has emerged as the gold standard for managing and scaling containerized applications. At the heart of every K8s cluster lies a critical component known as etcd. etcd is a distributed key-value store that stores and manages all of the K8s' configuration data, ensuring the system's reliability and consistency.

While K8s provides a robust platform for deploying and managing applications, the need to safeguard the etcd data cannot be overstated. This is where the importance of taking regular backups comes into play.

In this article, we'll dive into the essential part of etcd backup in Kubernetes, understanding why it's crucial for the stability and recoverability of your cluster.

The Relationship between Kubernetes and etcd

At the core of Kubernetes, etcd — an open-source distributed key-value store that acts as Kubernetes' primary database for storing configuration data and ensuring cluster consistency.
Etcd serves as the single source of truth, storing information about the cluster's state, configuration, and secrets. Kubernetes components, including the API server, controller manager, and scheduler, rely heavily on etcd to synchronize and manage containerized workloads across the cluster.

This tight integration makes etcd indispensable in maintaining the stability and reliability of a Kubernetes cluster, underlining the need for regular backups to safeguard this vital component.

Why is it crucial to take a backup of your Kubernetes cluster?

Taking regular backups of etcd in the Kubernetes cluster is crucial for several reasons, as it ensures the reliability, recoverability, and security of your K8s cluster. Here are key points explaining why regular etcd backups are essential:

Data Recovery: In the event of data loss or cluster-wide failures, etcd backups serve as a lifeline to restore your K8s cluster to a previously known state. This minimizes downtime and ensures business continuity.
Configuration History: Etcd stores the entire configuration history of your K8s cluster. Regular backups provide a historical record of changes, enabling you to trace and understand configuration modifications and troubleshoot issues over time.
Rollback and Versioning: Etcd backups enable you to roll back to previous cluster configurations or versions, which is essential for testing new configurations or reverting to a stable state in case of issues with updates or changes.

Prerequisites

Before you learn how to take a backup of the etcd cluster, ensure you have the following prerequisites:

A Kubernetes Cluster using Kubeadm
An etcd server

For demo purposes, I used the Killerkoda Kubernetes playground.
To communicate with etcd, you’ll need etcdctl, a command line utility for communicating with the etcd database, as it comes with the Kubeadm cluster by default.
etcdctl supports two versions of the etcd server's API. When making server calls, it defaults to version 2 of the API. In version 2, some operations are either undefined or have different arguments.
Next, you will tell etcdctl to use the V3 API, which is required for the snapshot functionality.

Setting up **ETCDCTL_API** to VERSION 3
To make etcdctl use the V3 API; you can either set the environment variable with each call as in the following commands.

$ ETCDCTL_API=3 etcdctl snapshot save ...  
$ ETCDCTL_API=3 etcdctl snapshot restore ...

or the entire terminal session.

$ export ETCDCTL_API=3
$ etcdctl snapshot save ...
$ etcdctl snapshot restore ...

How to Backup your Kubernetes etcd Data

To take a backup of the etcd database, you run the following command:

$ etcdctl snapshot save

For executing this operation, you’ll need a few flags (arguments) of certificates, which are mandatory for verification of the etcd server. This is because you must authenticate with the etcd server before it will expose its sensitive data. The authentication scheme is called Mutual TLS (mTLS).

To learn more about the flags, run:

$ etcdctl snapshot save -h

The output of the above command should look like this:

You’ll need 4 important arguments to successfully backup etcd:

--cacert
--cert
--key
--endpoints (Optional)

Let’s look into these arguments, what they are, and why you should pass them.
1. --cacert
This provides the path to the Certificate Authority (CA). The CA certificate is used to verify the authenticity of the TLS certificate sent to etcdctl by the etcd server. The server's certificate found must be signed by the CA. Creating the CA is one of the tasks you need to do when building a cluster. Kubeadm does it automatically.
2. --cert
This is the path to the TLS certificate that etcdctl sends to the etcd server. The etcd server will verify that this certificate is also signed by the same CA. Certificates of this type contain a public key that can be used to encrypt data. The public key is used by the server to encrypt data being sent back to etcdctl during the authentication steps.
3. --key
This is the path to the private key that is used to decrypt data sent to etcdctl by the etcd server during the authentication steps. The key is only used by the etcdctl process. It is never sent to the server.
4. --endpoints (optional)
The --endpoints argument on etcdctl is used to tell it where to find the etcd server. If you are running the command on the same host where etcd service is running and there is only one instance of etcd, then you do not need to provide this argument, as it has a default value of https://127.0.0.1:2379.
If your etcd service is running on the different port you need to provide that different port number instead of 2379 - https://127.0.0.1:port
OR
If your etcd service is running on the remote host then you need to pass -
--endpoints https://host-ip:port

Where to find the values of these arguments?
As etcd is running as a pod in the Kubernetes namespace called kube-system. You can describe the same pod, and you will able to see all the arguments and their values.

$ kubectl describe -n kube-system pod etcd-controlplane

As this contains a lot of information that we don't need right now, we can use grep command to extract only what we need.

$ kubectl describe -n kube-system pod etcd-controlplane | grep -i file

As you can observe here the path of these all certificates is at the location /etc/kubernetes/pki/etcd so you can find them as well from controlplane node.

The Final backup command will be:

$ ETCDCTL_API=3 etcdctl snapshot save \
      --cacert /etc/kubernetes/pki/etcd/ca.crt \
      --cert /etc/kubernetes/pki/etcd/server.crt \
      --key /etc/kubernetes/pki/etcd/server.key \
      /opt/etcd-backup.db

/opt/etcd-backup.db is the path for storing etcd backup data.
You should see output similar to this

Restoring from a backup

Normally you will restore this to another directory, and then point the etcd service at the new location. For restores, the certificate and endpoints arguments are not required, as we are doing creating files in directories and not talking to the etcd API, so the only argument required is --data-dir to tell etcdctl where to put the restored files.

$ etcdctl snapshot restore -h

You can pass any value as the path to the argument -- data-dir .

The final restore command will be:

$ ETCDCTL_API=3 etcdctl snapshot restore \
      --data-dir /var/lib/etcd-from-backup \
      /opt/etcd-backup.db

The above command will output the following:

Conclusion

This article described how you can take a backup of etcd in the Kubernetes cluster and restore it safely to avoid data loss and cluster-wide failures.
There is much more to learn about Kubernetes and etcd. Check out the following resources to explore more:

Excited to share my latest article on Kubernetes Server and Clients Certificate

Iribhogbe ehis — Thu, 26 Oct 2023 09:30:39 +0000

I am very excited to share my latest article on Kubernetes Server and Clients Certificate! 🌟

In this comprehensive guide, I delve into the intricate world of securing your Kubernetes environment. From understanding the fundamental concepts to implementing robust server and client certificates, this article serves as your ultimate go-to resource for enhancing the security of your Kubernetes setup.

Additionally, you'll gain insights into the various server and client certificates utilized by Kubernetes components and you will also learn how these certificates are generated, signed, and distributed.

Check it out here:
[https://everythingdevops.dev/securing-your-kubernetes-environment-a-comprehensive-guide-to-server-and-client-certificates-in-kubernetes/]

Deploying a Database Cluster on DigitalOcean using Pulumi

s1ntaxe770r — Sat, 19 Aug 2023 00:24:15 +0000

This article was originally posted on EverythingDevOps

Pulumi is an open source infrastructure as code (IaC) tool that allows you to define and manage cloud resources using popular languages such as Golang, Python, Typescript, and a few others.

Pulumi is often compared to Terraform, which is another infrastructure as code tool that allows users to declaratively manage infrastructure using HashiCorp Configuration Language(HCL). The key difference here Is Pulumi allows you to manage your infrastructure using one of their supported SDKs in your language of choice.

In this guide, you would be using Typescript to deploy a PostgreSQL database cluster on DigitalOcean, as such, this guide assumes some familiarity with Typescript.

Why Pulumi?

Unlike most infrastructure as code tools, Pulumi allows you to define your infrastructure using a general-purpose programming language, this allows your code to be tested much more easily. If you are familiar with Terraform you’d agree that not many testing frameworks exist for it. In comparison to a language like Python, where numerous testing frameworks exist.

Another advantage lies in the use of a general-purpose programming language, most developers would find using their favorite language more intuitive than a DSL (Domain-Specific Language*)* such as HCL.

Prerequisites

To follow along in this tutorial you would need the following:

A DigitalOcean account
DigitalOcean API token
Pulumi CLI
Node.js. ## Initializing a Pulumi project

The Pulumi CLI provides a command for scaffolding new projects. To do this, run the following commands:

mkdir postgres-db && cd postgres-db

Note: It’s important the directory is empty else, the next command will return an error.

pulumi new typescript -y

The above command will show an output showing Pulumi initialization, as shown in the image below.

This generates a new Pulumi project along with a stack, a stack is an Independent instance of a Pulumi program, and each stack is usually used to represent a separate environment (production, development, or staging). This is similar to workspaces if you are familiar with Terraform.

Installing Dependencies

To interact with DigitalOcean resources you would need to install the DigitalOcean Pulumi package:

$ npm install @pulumi/digitalocean

Next, set your DigitalOcean API key:

$ pulumi config set digitalocean:token YOUR_DO_API_KEY --secret

This would store your API key so Pulumi can authenticate against the DigitalOcean API, the --secretflag ensures the value passed in is encrypted.

You could also set your token using an environment variable:

$ export DIGITALOCEAN_TOKEN=YOUR-DO-API-KEY

Provisioning a Database Cluster

To get started open index.ts and follow along with the code below:

import * as pulumi from "@pulumi/pulumi";
import * as digitalocean from "@pulumi/digitalocean";

const pg_cluster = new digitalocean.DatabaseCluster("pulumi-experiments", {
    engine: "pg",
    nodeCount: 2,
    region: "nyc1",
    size: "db-s-2vcpu-4gb",
    version: "12",
});

export const db_uri = pg_cluster.uri;

The above code creates a PostgreSQL database cluster with 2 nodes:

engine allows you to specify the database cluster you want to create. In this case, it’s PostgreSQL. However, DigitalOcean supports a few other database types, see this section of the Pulumi documentation for more information.
Another important field to note is size, this allows you to configure the size of each node, see this section of the Pulumi documentation for all valid database slugs.
version allows you to specify what version of PostgreSQL you would like to run. Here is a list of all supported PostgreSQL versions on DigitalOcean.
Finally, you export the database connection URI so you can connect to it using your client of choice.

To deploy the cluster, run the following:

$ pulumi up

In a few minutes, you should have a cluster up and running.

Notice how db_uri is marked as “secret”, this is because it is a sensitive value, to output your database URI run the following command:

$ pulumi stack output db_uri --show-secrets > pass.db

The above would write the database URI to a file called pass.db.

Updating your Infrastructure

Now that you have a database cluster, chances are you are not going to stop here, and you would want to update your infrastructure. You can do this by adding a user to the newly created cluster.

It's good practice to create a separate user to avoid using the admin user, update index.ts with the following code:

import * as pulumi from "@pulumi/pulumi";
import * as digitalocean from "@pulumi/digitalocean";

const pg_cluster = new digitalocean.DatabaseCluster("pulumi-experiments", {
    engine: "pg",
    nodeCount: 2,
    region: "nyc1",
    size: "db-s-2vcpu-4gb",
    version: "12",
});

const pg_user = new digitalocean.DatabaseUser("non-admin",{clusterId:pg_cluster.id})

export const db_uri = pg_cluster.uri;
export const pg_user_pass = pg_user.password

Here you create a new instance of digitalocean.DatabaseUser, pass in the clusterId of pg_cluster and export the new user’s password as we did with the database URI.

To see what changes would be applied, run the following command:

$ pulumi preview

The output should look something like this:

Once you are satisfied with the changes, go ahead and apply the changes.

$ pulumi up

Once this completes, you should have a new database user called non-admin, you can output the password by running.

$ pulumi stack output pg_user_pass --show-secrets

Clean up (Optional)

To tear down the resources you just created, run the following command:

$ pulumi destroy

Conclusion

In this post, you deployed a PostgreSQL database cluster using Pulumi and updated it with a non-admin user. However, this is one of several services that you could potentially deploy using Pulumi. Hopefully, this was enough to get you started with Pulumi.

Next Steps

Check out this guide on how to deploy a Kubernetes cluster using Pulumi
Take a look at this section of the Pulumi registry for a full list of supported services

Understanding Docker Architecture: A Beginner's Guide to How Docker Works

Onyeanuna prince — Thu, 08 Jun 2023 22:28:38 +0000

This article was originally posted on Everything DevOps.

Using Docker, developers can package all their code and its dependencies into an isolated environment called an image and then run that image as a container. With Docker, deploying an application from a development server to a production server without worrying about compatibility issues is easy.

Aside from knowing basic Docker commands, while learning Docker, it is necessary you understand how these commands work. Therefore, in this article, you will learn about the fundamental components that make up Docker and how they work.

What is a Docker container?

Containers are lightweight, standalone units containing all the code and libraries needed to run an application. Unlike a virtual machine, a Docker container runs directly on the host operating system. This means it shares the host operating system kernel with other containers.

Docker containers are designed to be moved around easily between different environments without changing the application or its dependencies.

What is a Docker engine?

The Docker engine is the core of the Docker platform. It manages containers, including their creation, running and shipping and the entire lifecycle. When you install Docker, the Docker engine gets installed as well. This engine is the primary client-server technology that manages containers using all Dockers services and components.

The 3 fundamental components of the Docker engine

The Docker engine consists of three (3) fundamental components, including the Docker daemon, Docker API and Docker client.

Docker daemon
Docker daemon is a fundamental Docker component. It is a background process that listens to requests from the Docker client and manages the creation and running of Docker containers. The Docker daemon can be considered as the engine that powers the Docker environment. This allows developers to run, build and manage containerized applications.

The Docker daemon pulls Docker images from registries and manages the resources needed to run Docker containers. Docker daemon functions include:

Image management: The Docker daemon manages images, including pulling and caching images for fast and efficient container creation.
Volume management: Persisting data in containers is possible due to the Docker daemon. It enables the creation and management of volumes, which ensures data is saved when containers are deleted.
Network management: The Docker daemon manages communication between containers and the outside world. It manages container network interfaces, ensuring they are isolated from each other and the host machine.
Container management: The Docker daemon manages the starting, stopping and deleting containers.

Docker API
The Docker API is a programmatic interface that communicates with the Docker daemon. With the Docker API, you can tell the Docker daemon to perform tasks like starting, stopping and deleting containers or downloading or uploading Docker images. Docker API makes networks and volumes possible and manages user permissions and access.

All Docker daemon tasks are possible due to the Docker API. Without the Docker API, communicating with the Docker daemon programmatically wouldn't be possible.

Docker client
This is the primary mode of communicating with the Docker daemon. The Docker client is a command line interface (CLI) developers use to interact with the Docker daemon from their computers. When a user uses a command such as a docker run, the Docker client sends this request to the Docker daemon.

With the Docker client, developers can manage Docker containers, images, networks, and volumes from the command line. Below are the key features of the Docker client:

Command line interface: The Docker client provides developers a command line interface to execute Docker commands.
Integration with development tools: With the Docker client, it is possible to manage Docker containers from popular development environments, including Visual Studio Code and IntelliJ IDEA.

Note: Although the Docker API and Docker client may seem similar, as they are tools you can use to interact with the Docker daemon, they differ in a few ways. The Docker client sends requests to the Docker daemon via a Unix socket or a network interface, while the Docker API exposes a RESTful HTTP interface over a network.

Docker workflow

The Docker client, Docker API and Docker daemon work together for a complete Docker workflow. A practical example would be creating a container to see all these parts in action.

To create a Docker container, you would follow the steps below:

Step 1
Using the Docker client, you can pull an image from a registry (such as Docker Hub) or build an image from a Dockerfile.

$ docker pull nginx:latest //This will pull the nginx image from Docker Hub
$ docker build -t <image_tag> . // When you run this in a directory with a Dockerfile, it builds and tags it.

Step 2
Once you have an image, create a container using the Docker client.

$ docker run --name mycontainer -d nginx:latest

The above command requests the Docker API to create a container. The Docker API communicates with the Docker daemon to create the container. The Docker daemon sets up a network interface that allows the container to communicate with other containers or the host system. It also sets up volumes that the container can use to persist data.

Step 3
You can interact with the container once it's running using the Docker client. You can use the following commands to do this.

$ docker exec -it mycontainer bash # Execute a command inside a running container
$ docker logs mycontainer # View the logs of a container
$ docker stop mycontainer # Stop a container
$ docker start mycontainer # Start a container

Step 4
You can also use the Docker client to stop or delete the container.

$ docker stop mycontainer # Stop a container
$ docker rm mycontainer # Start a container

The Docker client sends commands or requests to the Docker API, which communicates with the Docker daemon to create and manage containers and their resources.

Alternatives to Docker

Although Docker isn't the first platform developers use for containerization, it played a significant role in popularizing containerization with a simplified process for creating containers and a user-friendly interface.

However, there are alternatives to Docker, such as container runtimes such as containerd and CRI-O and tools for building images such as Buildah.

Containerd: This is an open-source container runtime to manage a container's lifecycle. Docker and Kubernetes can use Containerd by providing a high-level API for managing containers and a low-level runtime for container orchestration.
CRI-O: This is an open-source container runtime designed for use with Kubernetes. It is a lightweight and stable environment for containers. It also complies with the Kubernetes Container Runtime Interface (CRI), making it easy to integrate with Kubernetes.
Buildah: This lightweight, open-source command-line tool for building and managing container images. It is an efficient alternative to Docker. With Buildah, you can build images in various ways, including using a Dockerfile, a podmanfile or by running commands in a container. Buildah is a flexible, secure and powerful tool for building container images.

Conclusion

Containerization is rapidly becoming the new standard for application deployment, and Docker is leading the way in this area. With its robust and flexible architecture, Docker makes it easy to build, deploy, and manage containerized applications on any platform.

If you're looking to improve your application deployment process or if you want to explore the exciting world of containerization, it is advised that you dive in and explore Docker.

To learn more about Docker, check out the following resources:

How to Set Up a Linux OS (Ubuntu) on Windows using VirtualBox and Vagrant

Angel Onyebuchi — Tue, 21 Mar 2023 00:54:33 +0000

Ubuntu is a popular Linux distribution that offers users a wide range of features and applications. Ubuntu is a great choice for those new to Linux who want to explore its capabilities. However, it can be difficult to set up and configure on a Windows desktop.

Fortunately, there is a way to get Ubuntu up and running quickly and easily with VirtualBox and Vagrant. This tutorial will guide you through setting up Ubuntu with VirtualBox and Vagrant on a Windows desktop, creating a secure and isolated virtual environment for testing and experimenting.

What is Vagrant?

Vagrant is an open-source software for building and managing virtual machine environments in a single workflow. With Vagrant, you can define a configuration file that specifies the details of the virtual machine you want to create and then use a single command to create and configure the virtual machine. This makes it easy to set up and maintain a consistent development environment across multiple machines and to share that environment with others.

Vagrant works with various virtualization software, including VirtualBox, VMware, and Hyper-V, and can manage both Linux and Windows virtual machines.

What is VirtualBox?

VirtualBox is a free, open-source virtualization software platform developed by Oracle that allows you to run multiple operating systems on a single physical machine. With VirtualBox, you can create and run virtual machines (VMs) on your computer, each of which runs a separate operating system and can be configured with its virtual hardware.

VirtualBox is designed to be easy to use, with a simple graphical user interface (GUI) that allows you to create and manage virtual machines. It supports a wide range of operating systems, including Windows, Linux, macOS, and many others, and can be used for various purposes, such as testing software, running legacy applications, and more.

How would Vagrant and VirtualBox work?

When you use Vagrant with VirtualBox, Vagrant creates and manages virtual machines in the VirtualBox environment. You define the operating system type, the amount of memory, and other resources the virtual machine should have in the Vagrant configuration file. Vagrant then uses this configuration to create and configure the virtual machine in VirtualBox.

Once the virtual machine is up and running, you can use Vagrant to manage it by SSHing into it or running provisioning scripts to set up the environment.

Prerequisite

To follow along with this article, you need to have the following:

A computer with
- at least 8 GB RAM
- Windows 10 x64-bit operating system (OS)
- A modern multi-core Intel/AMD CPU
- Virtualization is enabled in its BIOS settings. Find out how to here.
Have a basic knowledge of Powershell or Gitbash.
Installing VirtualBox

To install VirtualBox, you will need to follow these steps:

Step 1: Visit the VirtualBox website using this link, and you will see a page similar to the one below.

Step 2: Click on “Download VirtualBox” and then on Windows hosts to download VirtualBox and its extension pack.

Step 3: After downloading it, click on the “New” icon in the top right-hand corner to create a new virtual machine.

You would see a prompt like this.

Step 4: Name the new machine you want to create and choose the type and version that suits your taste.

Step 5: Click next and assign the memory size you want to allocate to the virtual machine using the up and down arrow keys.

Step 6: Click Next, select “Create a virtual hard disk now”, and create.

Step 7: Choose the hard disk file type (using the default setting is recommended except there are other preferences).

Step 8: Next is to allocate storage space for your hard disk. Choose if you want a flexible or fixed space.

Step 9: Choose the file location and size and create.

Step 10: Click Create, and you’ve successfully set up your virtual machine…

Installing Vagrant

To install Vagrant using a graphical user interface (GUI), you will need to download the Vagrant installer from the Vagrant website and then run it. Here are the steps:

Step 1: Go to the Vagrant download page at https://www.vagrantup.com/downloads.html, and under the "Operating System" heading, click on the appropriate “Binary” for your computer. The installer will be downloaded to your computer.

Step 2: Locate the installer file on your computer and double-click it to start the installation process.

Step 3: Follow the prompts in the installer to complete the installation.
Step 2: Once the installation is complete, you can start using Vagrant by opening a terminal or command prompt and typing vagrant.

Setting up the machine

After downloading Vagrant, to confirm that it was successfully installed, open the terminal/cmd of your choice and head to the home directory using the $ cd ~ as in the image below.

Note: ~ is used to move into the home directory in the command line.

List out the files in that directory using the ls command to check if Vagrant was successfully installed.

$ ls

After confirming the installation, create a directory for the Ubuntu setup using the mkdir command below.

$ mkdir Ubuntu_20.04

Change into the directory that you created using the following command:

$ cd Ubuntu_20.04

Run vagrant init ubuntu/focal64 command. Running this command automatically places a Vagrantfile in the directory created above. A Vagrantfile is a file that instructs Vagrant to create new Vagrant machines or boxes. ubuntu/focal64 is an existing Vagrant box for the Linux Ubuntu distribution.

$ vagrant init ubuntu/focal64

Start the Virtual Machine using vagrant up and watch it spin up the Virtual machine.

$ vagrant up

Ensure your VirtualBox looks like this:

Connect to the VM using vagrant ssh

$ vagrant ssh

Conclusion

This tutorial has shown you how to set up your Linux OS (Ubuntu) on Windows using Vagrant and VirtualBox. Vagrant is a great tool and a very easy way of using Ubuntu on Windows rather than having to dual boot. To learn more about Vagrant and VirtualBox, Check out these resources :

A Brief History of DevOps and Its Impact on Software Development

Amarachi Iheanacho — Mon, 20 Mar 2023 19:36:06 +0000

This article was originally posted on Everything DevOps.

Software development has been and continues to be one of our society's most important building blocks. Software development has gifted us with the mobile phones we use to stay connected, the rockets we send to space and a host of other great innovations.

As complex as these innovations become, the more complex and time-demanding the software that drives them becomes. In an attempt to make the entire software development process as efficient as possible, different approaches have been introduced. An example of one of these is DevOps.

This article will share a brief history of DevOps, from its early days and its impact on software development today. At the end of this article, you will learn what to expect next in the field of DevOps.

Before DevOps: The early days of software development

In the early days of computing, software was developed and maintained by a small group of specialists, often working in isolation from the rest of an organization. The development process known as “Waterfall” was slow, with teams spending months or even years building and testing software before it was ready to be deployed.

The Waterfall model breaks project activities into pre-defined phases, passing the project down from one phase to another. In the waterfall model, each phase depends on the deliverables of the previous one; as a result, each phase must be completed before the next phase can begin with no overlap.

The Waterfall model is typically divided into the following distinct stages:

Image source: Adobe

Requirements gathering and analysis: This phase involves gathering and documenting the requirements for the project.
Design: In this phase, the system architecture and design are developed based on the requirements gathered. The system design helps specify the hardware and software requirements, like what programming language would be the best, while defining the overall system architecture.
Implementation: This phase involves the actual coding and development of the system or software.
Testing: The system is tested in this phase to ensure it meets the requirements and is error-free.
Deployment: The system is deployed and available to the end-users in this phase.
Maintenance: This phase involves ongoing maintenance, bug fixes, and updates to the system.

Challenges with the Waterfall model
Although this Waterfall model has pros, like its ease of use and management, it is inefficient and has high risk and uncertainty. Some of the many disadvantages of the Waterfall model are:

Lack of flexibility
No room for errors
Difficulty in dealing with changes
No customer involvement ## The rise of the Agile methodology

Recognizing the disadvantages of the Waterfall approach in building software, in the late 1990s, a new approach to software development, known as Agile, emerged to improve the software creation process.

Agile combats the rigidity of the Waterfall model by focusing on the clean delivery of individual pieces or parts of the software and not the entire application.

Launched formally in 2001, Agile looked to get new features into the hands of the users quickly by focusing on rapid iteration and delivery brought by emphasizing collaboration, flexibility and continuous improvement.

Teams were encouraged to work in short, iterative cycles, known as “Sprints”, and to continuously refine and improve the software they were building.

Image source: Krusche & Company GmbH

To practice agile effectively, its creators outlined the following guidelines in the Agile Manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

While there is value in the items on the right, we should value the items on the left more.

Agile significantly improves how we create software and offers advantages like:

faster time-to-market,
testing and superior quality,
flexible priorities,
risk reduction,
project visibility and transparency, etc.,

It soon began to replace the need for the Waterfall model in the software development life cycle.

The History of DevOps

As Agile development gained popularity, a new term emerged to describe the practices and principles used to streamline the development and deployment process: DevOps.

To share the history of DevOps, below is a detailed history of DevOps timeline, listing all the defining moments and summarizing the contributions of key influential people from 2007 to 2019.

2007
DevOps started in 2007 when Patrick Debois — an IT consultant, recognized that development (Dev) and operations (Ops) teams were not working well together. While the gaps and conflicts between Dev and Ops have always been unsettling to him, the constant switching and back and forth on a large data center migration project where he was responsible for testing particularly frustrated him.

One day he was deep in the rhythm of Agile development. Next day he was firefighting and living the unpredictability of traditional operations. He knew there had to be a better way.

2008
The following year, at the 2008 Agile Conference, Andrew Shafer created a birds of a feather meeting (BoF) to discuss “Agile Infrastructure”. Andrew didn't think anybody would come, so he himself didn’t show up to his own meeting. Patrick Debois showed up, and went looking for Andrew because he wanted to talk about Agile infrastructure being the solution to get operations to be as Agile like the developers were. This was where DevOps got started.

2009
In 2009, at the Velocity conference, John Allspaw and Paul Hammond talked about “10+ deploys per day - Dev and Ops Cooperation at Flickr,” and the idea started gaining traction. This talk made people notice what was possible by adopting these early DevOps practices. Also, in October 2009, Patrick, held the first DevOpsDays conference in Ghent, Belgium. It was described as “The conference that brings development and operations together.” This is where the term "DevOps" was first used. DevOpsDays is now a local conference held internationally several times a year in different cities.

2010
In 2010, Jez Humble and David Farley wrote a groundbreaking book called Continuous Delivery that sets out the principles and technical practices that enable rapid, incremental delivery of high-quality, valuable new functionality to users using a technique called Continuous Delivery.

Through automation of the build, deploy, and test processes, along with improved collaboration between developers, testers, and operations, delivery teams can release changes in a matter of hours—sometimes even minutes—no matter the size of a project or the complexity. The book is over 13 years old, but it still has a lot of great concepts that helped changed a lot of people's thinking about how to perform software delivery in a continuous fashion.

2013
Two years later, in 2013, Gene Kim, Kevin Behr, and George Spafford published The Phoenix Project, based on Eliyahu Goldratt’s book, The Goal. The Goal is about a manufacturing plant about to go under and what they had to do to bring it back to life. It is a story about lean manufacturing principles. The Phoenix Project is about an information technology (IT) shop in a company about to go under and what it took to bring it back to life. This story is about applying lean manufacturing principles to software development and delivery.

2015
In 2015, Dr. Nicole Forsgren, Gene Kim, and Jez Humble founded a startup called DORA (DevOps Research and Assessment) that produced what are now the largest DevOps studies to date called the State of DevOps Reports. Nicole was the CEO and is an incredible statistician.

Through this research, she found that taking an experimental approach to product development can improve your IT and organizational performance and that high-performing organizations are decisively outperforming their lower-performing peers in terms of throughput. The research shows that undertaking a technology transformation initiative can produce sizeable cost savings in any organization. If you haven't read the most recent State of DevOps report, I strongly urge you to do so.

2016
The DevOps Handbook was published in 2016. It was written by Gene Kim, Jez Humble, Patrick Debois, and John Willis as a follow-on to The Phoenix Project and serves as a practical guide on implementing the concepts introduced in that book. John Willis, by the way, worked at Docker and Chef back then, and is a DevOpsDays coordinator after being at the original DevOpsDays in Ghent 2009 with Patrick Debois. If you only read one DevOps book, this is the book to read. They looked at companies that have adopted DevOps and document what did work and what did not work. It's a great read.

2019 — 10 years of DevOpsDays
Come 2019, 10 years after the first DevOpsDays in Ghent, Belgium, 60+ DevOpsDays events were held in 21 countries.

Patrick Debois led DevOpsDays from its inception in 2009 until 2014, and then Bridget Kromhout became the lead in 2015. She is also the co-host on the very popular podcast, Arrested DevOps. If you don't listen to it, you should. She stepped down in 2020 but stayed on the advisory board of DevOpsDays with Patrick.

The individuals mentioned above are some of the major influential people in the early DevOps movement. They weren’t the only ones, but they went out and made a difference. They showed us how DevOps can be impactful.

Why is the DevOps History Important?

Knowing the DevOps History is important because DevOps was a grassroots effort started by people like Patrick Debois and Andrew Shafer, who just wanted to eliminate the roadblocks in software delivery and figure out how can development and operations work better together.

And as Damon Edwards, who co-hosted a podcast with John Willis called the 'DevOps Cafe', said it best in his talk on “The (Short) History of DevOps”:

DevOps is from the practitioners, by practitioners.
It’s not a product, a specification, or job title.
It is an experience-based movement that is decentralized and open to all.

DevOps Impact on Software Development

The impact of DevOps on modern software development has been significant. The following are some of the key ways that DevOps is changing the way software is developed and deployed:

Faster Time-to-Market: DevOps enables teams to deliver software quickly and efficiently, which reduces the time it takes to bring new features or products to market.
Improved Collaboration: DevOps encourages collaboration between developers, testers, and IT operations teams, which leads to better communication and a faster resolution of issues.
Increased Quality: By automating testing and deployment processes, DevOps reduces the chance of errors and increases the overall software quality.
Greater Efficiency: DevOps automates repetitive tasks and streamlines processes, freeing time and resources for more important tasks.
Better Customer Satisfaction: DevOps allows teams to respond quickly to customer feedback and make necessary changes, resulting in better customer satisfaction. ## What next in DevOps?

DevOps is a constantly evolving field, and several trends and areas of focus are likely to shape its future. Here are a few things to keep an eye on in the world of DevOps:

DevSecOps: The integration of security into DevOps practices, also known as DevSecOps, is becoming increasingly important. As software security threats continue to grow, organizations realise the need to prioritize security throughout the entire software development lifecycle.
Artificial Intelligence and Machine Learning: The use of AI and machine learning in DevOps is on the rise, with the potential to automate more tasks and improve the efficiency of software development and deployment.
Serverless Computing: Serverless computing is a growing trend in DevOps, allowing for code deployment without needing to manage infrastructure. This can help reduce costs and improve scalability.
Site Reliability Engineering: Site Reliability Engineering (SRE) is a discipline that focuses on the reliability and scalability of software systems. It is becoming increasingly important in DevOps as organizations seek to improve the reliability and availability of their applications. ## References

The following are the references used in creating this article:

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 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:

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:

DEV Community: EverythingDevOps

Introduction to Multi-Cluster Deployment in Kubernetes

What are Kubernetes multi-clusters?

Why do you need multiple clusters?

Scalability

Reduced blast radius

Geographical redundancy and disaster recovery

Reduced latency

Isolation

Operational flexibility

What does a multi-cluster architecture look like?

When to use a multi-cluster architecture

High availability

Geographical distribution

Workload segmentation

Cross-cloud strategy

Conclusion

Monitoring, Observability, and Telemetry Explained

What is Monitoring?

Types of Monitoring

What's the Problem with Legacy Monitoring?

A Historical Overview of Monitoring and Observability

Why Observability?

Differences between Observability and Monitoring

A Brief Intro to Telemetry Data

Comparisons and Relationships

The Transition from Monitoring to Observability

Choosing the Right Tool

Conclusion

Taking Backup of your Kubernetes etcd Data: A step-by-step guide

The Relationship between Kubernetes and etcd

Why is it crucial to take a backup of your Kubernetes cluster?

Prerequisites

How to Backup your Kubernetes etcd Data

Restoring from a backup

Conclusion

Excited to share my latest article on Kubernetes Server and Clients Certificate

Deploying a Database Cluster on DigitalOcean using Pulumi

Why Pulumi?

Prerequisites

Installing Dependencies

Provisioning a Database Cluster

Updating your Infrastructure

Clean up (Optional)

Conclusion

Next Steps

Understanding Docker Architecture: A Beginner's Guide to How Docker Works

What is a Docker container?

What is a Docker engine?

The 3 fundamental components of the Docker engine

Docker workflow

Alternatives to Docker

Conclusion

How to Set Up a Linux OS (Ubuntu) on Windows using VirtualBox and Vagrant

What is Vagrant?

What is VirtualBox?

How would Vagrant and VirtualBox work?

Prerequisite

Installing VirtualBox

Installing Vagrant

Setting up the machine

Conclusion

A Brief History of DevOps and Its Impact on Software Development

Before DevOps: The early days of software development

The History of DevOps

Why is the DevOps History Important?

DevOps Impact on Software Development

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 Set Environment Variables on a Linux Machine

Prerequisite

What are environment variables?

Setting environment variables on a Linux machine