DEV Community: Olivia Mattiazzo

Understanding Kubernetes Components – Volumes

Olivia Mattiazzo — Wed, 25 Sep 2024 11:00:00 +0000

Having studied Docker last year, initially through a course on Alura, was the starting point for my interest in DevOps culture to flourish. Eventually, in 2021, I was awarded the #ChamaAsMinas program, promoted by the LinuxTips school, and received the Containers Expert training completely free of charge. Besides solidifying my knowledge of Docker, I began learning about Kubernetes and, wow... it’s a lot. In one of the classes, we were introduced to several different concepts, and I’m writing this series of posts because I felt the need to dive deeper into them. So, I'm inviting you all to join me in my next mission: understanding Kubernetes components – Volumes!

What components will this series of posts cover?

If you, like me, are taking the Descomplicating Kubernetes training: today is (almost) your lucky day. I've summarized some of the components explained on Day 4 of the course. For each component, my goal is to describe:

Its definition
Examples of usage
Possible related commands
A snippet of the corresponding creation YAML and/or related YAML

As I start writing this post, I’ve just finished studying this part of the course and, honestly, I’m a bit nervous about the final quiz. 😅 Personally, I find Kubernetes much harder to understand than Docker, but onward we go!

However, if you're not taking this course, here are the components I plan to cover:

Volumes (in this very post!)
- EmptyDir
- Persistent Volume
Cronjobs & Secrets (in the next one)

Volumes in Kubernetes

Definition

First and foremost, to put it simply, a volume is nothing more than a directory accessed by the containers of a Pod, which contains data. If you're a developer and need a rough analogy, we can say that your Pod and its containers are like an application, and the volume would be its database.

The main utility of a volume is to make your containers less ephemeral. For example, you have your cluster with its pods, and one of the existing containers restarts due to some issue. If there is no volume associated with this container, it will come back “clean,” just as it was initially created. Therefore, volumes are used to store any type of information that can help you avoid losing work if something goes wrong.

Docker already has the concept of volumes, but within Kubernetes, this is expanded: there are many different types of volumes tailored to various uses, and pods can use as many volumes as needed simultaneously. Primarily, Kubernetes volumes can be divided into two categories: ephemeral volumes, whose existence is tied to the pod’s existence; and persistent volumes, which continue to exist regardless of whether the pod is still running or has been deleted. However, no matter the volume type, the data will always be preserved even if the containers within that pod are restarted, as they are tied to the pod, not to the containers associated with it.

EmptyDir

Definition

As explained earlier, EmptyDir is a type of Kubernetes volume and falls under the group of ephemeral volumes, as it doesn’t handle data persistence. So be careful: when you delete your pod, everything saved in this volume will be lost.

This volume is created as soon as we assign a pod to an existing node. It always starts empty, and anything stored here can be accessed by all containers within the pod.

Usage Example

EmptyDir is the ideal volume to use in situations such as:

When you need a “scratch space” for your algorithm (e.g., sorting algorithms)
When you need a place to store recovery points for the containers within your pod

Setting Up a Pod with an EmptyDir Volume

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
   emptyDir: {}

⚠ Reminder!

To create any type of Kubernetes component from a YAML file, just run the following command:
kubectl create -f filename.yaml

Persistent Volume

First of all, it's important to clarify that there are "two concepts" associated with this single name, Persistent Volume. The first is more general and defines the Persistent Volume component as a type of volume and what it provides. Within the Persistent Volume component, there is also a "subcomponent" called Persistent Volume.

Confusing, right? Let me explain it a bit better:

Definition

Anyway, there is a subsystem within Kubernetes called Persistent Volume, which provides an API for users and administrators that abstracts the details of how volumes are provisioned and consumed. Within this Persistent Volumes subsystem, there are two main components that handle this process: Persistent Volume and Persistent Volume Claim.

Usage Example

Given that applications are increasingly cloud-based, when someone wants to consume data from an API, for example, it’s necessary to integrate with a specific storage system (Amazon, Azure, etc.). Kubernetes, through Persistent Volume, aims to change this by providing an abstraction. This allows for connecting to a variety of cloud systems without needing explicit dependencies for each system.

Thus, with Persistent Volume, consuming data from a cloud system becomes more straightforward and robust, significantly reducing related costs. It also makes it easier to migrate between cloud systems and/or adopt strategies involving multiple cloud systems.

⚠ Note! Given the more detailed definition, let’s agree on this: when I’m referring to the Persistent Volume subsystem, I’ll use the full name. When referring to the component within the subsystem, I’ll use the acronym PV. Got it?

Persistent Volume (the subcomponent)

Definition

This component, within the subsystem we mentioned, is responsible for providing the actual storage for the volumes we want to create. It is part of the cluster just like any other resource; just as a node is a resource, a PV is too. Unlike EmptyDir, a PV is a persistent volume (obviously), meaning its content is not tied to the lifecycle of a pod; after deleting the pod that uses the volume, the content remains. The PV is also the API object responsible for capturing the details of the storage implementation (such as NFS, iSCSI, or a cloud provider).

Configuring a PV with NFS

apiVersion: v1
kind: PersistentVolume
metadata:
  name: primeiro-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /opt/dados
    server: 10.138.0.2
    readOnly: false

⚠ Note! To configure the PV with NFS, it’s also necessary to set up NFS itself. You can find the complete step-by-step guide for creating this component in the Descomplicando Kubernetes repository.

Related Commands

Unlike EmptyDir, with PVs we can use some kubectl commands for viewing and managing them. Here are a few useful commands:

kubectl get pv
kubectl describe pv [your-pv-name]

Persistent Volume Claim

Definition

The PVC is the component that actually binds a PV to a pod. As the name suggests, it’s through the PVC that you can “claim” access to a PV. Just as a pod consumes resources from a node, the PVC will consume resources from a PV. Similarly, just as a pod can request specific levels of resources like CPU and memory, the PVC can specify the size and access mode it needs from the volume.

Access Modes

Each volume can and should be mounted using only one access mode, even though it may support multiple modes. The available access modes are:

ReadWriteOnce – Only a single node can perform read and write operations.
ReadOnlyMany – The volume will be read-only for all nodes.
ReadWriteMany – All nodes can perform read and write operations.

Configuring a PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: primeiro-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 800Mi

Related Commands

Just like with PVs, we can use some kubectl commands to view and manage PVCs.

kubectl get pvc

A diagram to simplify the process

✔ Links consulted

📕 Documentação do Kubernetes – Volumes

📘 Repositório do treinamento Descomplicando Kubernetes

📗 Stupid Simple Kubernetes — Persistent Volumes Explained

📩 A Last Message

Did you like the text? Do you have anything to add? Any constructive criticism? Feedback? Suggestions? Requests? Feel free to contact me via email (oli.pmatt@gmail.com), LinkedIn (/in/oliviamattiazzo) or through the comments section below! I’d be delighted to chat with you! ✨

You can also check the original post (in PT-BR) at my blog: oliviamattiazzo.dev

⏰ Other posts

💎 A Study on Git Rebase

💎 Super-helpful gem: syntax_suggest

A Study on Git Rebase

Olivia Mattiazzo — Wed, 18 Sep 2024 11:00:00 +0000

It's been a while since I wanted to research and write about the difference between git push --force and git push --force-with-lease. Today, I started looking into these two commands and also thought: hmm, why not include an introduction to git rebase as well? After all, it's such a feared tool, surrounded by so many myths, and personally, I didn't know much about it—just that I need to use it. So, I decided to combine my curiosity with the opportunity to create a study on git rebase and share it here with everyone!

Conceptually, what is Git Rebase?

First, let me clarify that rebase is one of the methods available in Git for updating branches, along with merge (if there are others, let me know, because I can't remember 😅). When you create a feature branch—this special place where you'll start developing a new feature for a system—you do so from the latest commit of a main branch. The characteristic of rebase, unlike merge, is that it changes the base of your branch from one commit to another, making it appear as though you created your feature branch from a different, more recent starting point than the one where you initially started your work.

A bit confusing, right? Hold on, I'll try to clarify with a diagram.

A Git Rebase in 3 Acts

Act I - New Branch

The person speaking here went ahead and created a new branch from the main branch of a project. The initial commit of my branch, which we’ll call branch-oli, is commit wap662, which includes everything from the main branch up to that point.

Act II - Updated branch

The next day, a colleague merged their feature branch, branch-do-colega, into the main branch. As a result, the main branch was updated, and its latest commit, which will serve as the base for any new feature branches, is now commit sus0sz. However, my branch, branch-oli, became outdated and needs to be updated with the latest changes from the main branch. I can do this in two ways: using git merge or git rebase. Today, I'll use rebase: in other words, I'll make branch-oli have sus0sz as its base commit.

Act III - Rebase done

Awesome! Our code is now fully updated.

So, what are the advantages of Git Rebase?

The most practical advantage of rebase is that it results in a cleaner merge of your feature branch into the main branch. The poetic advantage is this: the commits in the main branch are largely composed of merges from other branches. When these merges come with descriptive titles and are done with care, the commits in the main branch start telling the story of a system. Rebase helps make this story more linear, making it more coherent and easier to follow.

When it comes to tracking down which feature branch introduced a bug into the production codebase, having a tidy and organized commit history makes it much easier to find the culprit.

How is this done?

Git organizes this “story” by creating new commits from the existing ones and applying them to the base (which, in this case, is your feature branch). Although the branch may appear unchanged to us, it actually consists of completely new and different commits after the rebase.

Types of Git Rebase

There are two types of Git Rebase available for use, each with its own advantages and disadvantages.

Standard Git Rebase: When you run the rebase command without any additional flags, it will simply take all the new commits created in a branch and automatically add them in front of the new base commit of your feature branch. This process is straightforward and doesn’t require much thought or concern.

Interactive Git Rebase: This occurs when you include the -i flag with the rebase command in the console/terminal. Interactive rebase allows you to modify commits made during development, including splitting, removing, or reordering them.

With interactive rebase, you can focus on developing your feature without worrying about the commit messages or their order. You can make necessary changes as you go, and before merging into the main branch, you can tidy up the commit history using the -i flag.

Leave the Cleanup for Later!

Main Differences Between Git Merge and Git Rebase

First and foremost, it’s important to note that both commands address the same issue: integrating code changes between branches.

The primary difference is that Git Merge brings in the new code independently and integrates it through a single commit into your feature branch. It is a non-destructive operation, meaning there's little risk of making unwanted changes to the branch you're working on.

However, Merge can also introduce extra commits beyond those you've created. If the main branch is very active and you need to perform multiple merges throughout the development of your feature, these extra commits can clutter the “history” of your branch.

On the other hand, Git Rebase rewrites the history of your project, as explained earlier. This is beneficial for clarity and a clean history but can have a downside: it becomes less clear when new changes were added to the feature branch, leading to less context compared to using Git Merge.

About Force Pushes During Git Rebase

Why do we need --force push during a rebase?

Git has a rule called the Fast-Forward Rule: essentially, it will reject any commit if the remote branch is not an "ancestor" of what's on your local branch. Rebase breaks this rule because it creates new commits and changes the base of the local branch, which is why we need to use force push to bypass it. The --force flag will completely ignore the existing history of the feature branch and replace it with what’s on your machine.

Difference Between --force and --force-with-lease

--force is a blunt instrument. If someone has made commits while you were doing the Git rebase locally, those changes will be lost forever. However, this can be circumvented with --force-with-lease, which I translate loosely as forceful with care: Git will refuse to update the branch if its state differs from what is expected.

Force into the force push!

In other words, when using --force-with-lease, Git will first check if the remote version of your feature branch is the same as the one you rebased or if there are any changes beyond the “re-created” commits. If there are additional changes, such as commits made by another developer, the push will be rejected. If there are no additional changes, you can bypass the Fast-Forward Rule without major issues.

Main Commands Related to Git Rebase

To perform a rebase:

git rebase [-i] branch-name

Note: The -i flag is optional and is used for interactive rebases, as explained in the definition above.

To continue with the changes made:

git rebase --skip

Force pushes:

git push --force
git push --force-with-lease

✔ Links consulted

📗git rebase – Atlassian Git Tutorial

📘Atualizando um branch com git rebase – Jessica Temporal

📙Git rebase: integrando alterações de uma branch em outra, por Daniela Araújo – BeTrybe Blog

📕Merging vs. Rebasing – Atlassian Git Tutorial

📗Git Force vs Force with Lease, por Mohammad-Ali A’Râbi

📘Essa resposta no Stack Overflow

📩 A Last Message

You can also check the original post (in PT-BR) at my blog: oliviamattiazzo.dev

⏰ Other posts

💎 Rails Helpers – what are they and what are they used for?

💎 Super-helpful gem: syntax_suggest

Super-helpful gem: syntax_suggest

Olivia Mattiazzo — Thu, 12 Sep 2024 11:00:00 +0000

One day at work, Code Climate flagged an error in one of my commits. Honestly, I don't remember exactly what it was, but it was something related to a missing closing parenthesis or brace, something along those lines. The problem was: I went back to my code and, at first glance, couldn't find exactly where the issue was, and there were no additional details anywhere to help. So, I started looking for a solution to better visualize potential syntax errors and stumbled upon a real gem: syntax_suggest! I thought it would be interesting to write a quick post about it here to document this solution for myself, in case I need to use it again in the future!

That method to give you a little help.

First of all, I need to clarify that I used this gem in a very specific situation, more to find a problem than to actually fix it. So, what I'll present here is the most basic way to use this little gem. Finally, you can always find more about it on its GitHub repository.

Installation in your Ruby project

Open a console in your Ruby project's folder and install the gem as follows:

gem install syntax_suggest

Checking the syntax of a file

I already knew which file had the issue thanks to Code Climate, so I went straight to the point with the following command (in the application console):

syntax_suggest [file-path]

#Example:
syntax_suggest app/services/file_xpto.rb

An example of how the response is returned:

Unmatched keyword, missing `end' ?

> 1 class Dog
> 2 def bark
> 4 end

If you need help within the console itself, you can always access the gem's help:

syntax_suggest --help

And that's it! A simple and short post, but it was also a quick and easy solution to fix a problem I was facing. I hope it helps you as well!

✔ Links consulted

📀 syntax_suggest repository on GitHub

📩 A Last Message

You can also check the original post (in PT-BR) at my blog: oliviamattiazzo.dev

⏰ Other posts

💎 Rails Helpers – what are they and what are they used for?

🪪 Credits

The icons used to illustrate this post came from the following IconFinder users:

https://www.iconfinder.com/PixelBuddha

Rails Helpers – what are they and what are they used for?

Olivia Mattiazzo — Wed, 04 Sep 2024 11:22:28 +0000

Has it ever happened to you that you use a concept in your preferred programming language without really understanding why you’re using it? Or what exactly it does? This recently happened to me when I was tasked with refactoring someone else’s code: I didn’t quite understand what Rails modules were or what Helpers were for. So, I took some time to study this and prepared this summary on what Rails Helpers are and what they are used for!

That method to give you a little help.

Organizing the party

In this post, I intend to cover, in the following order:

A general explanation of what Rails Helper methods are and the best practices associated with them
Delve into more details about Ruby Modules and their importance within the language
Touch on the topic of Composition vs. Inheritance, which is always good to keep fresh in mind

What are Helpers in Rails?

Helpers are methods primarily used to share reusable code between the views in your project. It's important to note that Helpers don't necessarily need to be created by developers: there are already some native methods provided by Rails to make our lives easier.

Examples of native Rails Helpers:

time_ago_in_words(Time.now)
# "less than a minute"

number_to_human(10_000)
# "10 Thousand"

Helper methods are also very important when created by programmers themselves, as they help apply the DRY principle within the project's code. By doing so, you condense a portion of the logic into a single place instead of having it scattered across various parts of the code.

DRY – Don’t Repeat Yourself

Writing Your Own Helpers

There is a specific directory for creating your own Helpers in Rails, which is the app/helpers directory. Inside this folder, you need to create a new file and, within a module, develop what you need. Everything inside it automatically becomes visible to the views in your project.

For example: we went to app/helpers and created the file user_helper.rb, which will contain all our user-related helpers. Inside it, we will build the following module:

module UserHelper
  def format_name(user)
    if user.gender == "M"
      "Mr. #{user.name}"
    else
      "Mrs. #{user.name}"
    end
  end
end

There is also a generic option, useful if your application is small and you need only a few Helpers, for example, which is to put everything inside the ApplicationHelper. This is a base module in Rails, ready to receive any future helpers you develop.

Best Practices for Using Helpers

When should you use and/or create a helper?

Whenever you have reusable logic that produces HTML code. Most of the time, this involves code related to string formatting or view elements that are conditional. It's a good idea to encapsulate this logic within a helper to avoid having it scattered and repeated throughout your application.

Organize your stuff

Use and abuse of parameters

It's a way to clearly specify from the beginning what your method needs, reducing the risk of encountering errors related to missing variables while working with information within your helper.

Try not to use helpers in Controllers

Some developers believe in the concept of Controller Helpers, which are helpers more focused on logic rather than presentation. It's also possible to use view helpers directly in controllers by invoking them with the helpers object. For example:

class UsersController
  def index
    helpers.time_ago_in_words(Time.now)
  end
end

RubyGuides advises caution when doing this, as it can be considered a design problem, suggesting the use of a Ruby object instead, although it doesn't provide further details on why. I also think it's worth noting this warning, and when in doubt, keep helpers confined to views, OK?

What are Ruby Modules?

Throughout this article, I've talked a lot about Ruby modules and how important they are when writing helpers. Then I realized that I didn't know what the heck a Ruby module was. So, I did some research and am sharing this important extra bit on what it is and what this useful little keyword is for.

A module is a Ruby container used to store methods, variables, and constants. It's similar to a class, but unlike a class, a module cannot be instantiated. It's somewhat similar to the concept of static in .NET.

Modules have two main purposes in Ruby:

Creating a namespace, that is, grouping logically related objects together, which also helps avoid name conflicts
Facilitating composition within your application

Ruby, as a programming language, does not support multiple inheritance. Therefore, to keep the code scalable and maintainable in the long run, it is necessary to apply the principle of Composition Over Inheritance. Fortunately, Ruby makes composition easier by offering what is called the Mixing Facility.

Happy dance!

The Mixing Facility is simply a module being included by another module, or even by another class, using keywords like include, prepend, or extend.

Composition vs. Inheritance

Ah, the age-old dilemma for those who program in object-oriented languages ~~and for a paycheck~~. This debate is present from the earliest stages of learning to the most seasoned seniors. Precisely because it’s so prevalent in our daily work, I think it’s important to revisit the definitions of these two concepts, especially since it’s already explained above why one is more important for Rails. I’m also leaving a link to a well-detailed DevMedia article (in PT-BR) that explains the importance of each and when to use them (spoiler: most of the time, it’s not Inheritance).

Inheritance

Inheritance in programming is defined by the existence of a parent class (also known as a base class or superclass) and a child class (or subclass), and it is considered a fundamental tool for extending and reusing functionalities. In this principle, we focus heavily on the generalization of concepts: similarities between classes are placed in the parent class, while all specific business logic is placed in the child class.

In this concept, there is a strong coupling between classes, as one class depends on the other throughout the system.

Composition

In Composition, we define small behaviors that will exist between classes, which are standardized. As our classes are created and evolve, we compose more complex behaviors using these small units of behavior that have already been designed and tested. Here, the emphasis is on encapsulating logic, which is always a good practice.

Encapsulate your stuff, bro.

🪡 Revisions and Corrections

May 30, 2023 – I corrected some parts of the text that mistakenly stated that modules belong to Rails, when they actually belong to Ruby itself. Thanks to Sérgio Ribeiro for the heads up! 😀

✔ Links consulted

♥ RubyGuides: How to Use Rails Helpers (Complete Guide) – by Jesus Castello

★ Helper Methods – by Damely Tineo

♥ Modules in Ruby: Part I – by RubyCademy

★ DevMedia: Herança versus Composição: qual utilizar? – by Higor

Last accessed on April 2, 2023.

📩 A Last Message

You can also check the original post (in PT-BR) at my blog: oliviamattiazzo.dev

🪪 Credits

The icons used to illustrate this post came from the following IconFinder users: