DEV Community: Vasco Ramos

Learning Kubernetes - Part II: Pods, Labels, and Services

Vasco Ramos — Mon, 22 Mar 2021 00:00:55 +0000

Welcome to the second part of my Learning Kubernetes series. This second post builds on the concepts introduced in the previous one and explores a new (better) way of defining objects. We will also explore what Services are and how they can help you better expose your applications.

But first... a quick recap!

Kubernetes is an orchestration tool that allows us to manage containerized applications across a group of nodes.

In the previous post, we talked about:

What is Kubernetes
What it's used for
Some simple concepts and tools around it: Pods and kubectl.

To review what a Pod is, this is what we saw in the previous post:

A pod is the smallest unit inside the Kubernetes cluster, and it represents a collection of application containers and volumes running in the same isolated execution environment.

Also, not to forget that all containers inside the same Pod share:

IP address
Namespace
Storage

One last thing, we saw how to create objects (more precisely, Pods) using kubectl. In this post, I want to introduce you to the de facto way of creating and managing objects in Kubernetes and some new concepts.

So, let's jump right in! 😄

The brave "new" declarative world!

The declarative approach to Infrastructure is natural to DevOps and has gained even more relevance with the surge of GitOps. Immutability is a core concept in the declarative approach. In the case of Kubernetes, as it's said in Kubernetes: Up and Running:

Immutable container images are at the core of everything that you will build in Kubernetes. It is possible to imperatively change running containers, but this is an anti-pattern [...] And even then, the changes must also be recorded through a declarative configuration update later, after the fire is out.

So... how do we do this? Let's go back to the example in Part I. When we created the Pod, we did so by running the following (imperative) command:

kubectl run kubernetes-hello-world --image=paulbouwer/hello-kubernetes:1.9 --port=8080

Now, we will do the same thing but with a declarative configuration.

apiVersion: v1
kind: Pod                                            # 1
metadata:
  name: kubernetes-hello-world                       # 2
spec:                                                # 3
  containers:
    - image: paulbouwer/hello-kubernetes:1.9         # 4
      name: hello-kubernetes                         # 5
      ports:
        - containerPort: 8080                        # 6

As you can see, this YAML manifest is equivalent to the previous command. Now let's see the most important concepts in this definition:

Kind: specifies the kind of Kubernetes object to be created.
Name: defines the name for the object.
Spec is the specification of the object's desired state. The main specification here, at least in the case of Pods, is the array of containers (in our case, there's only 1 container in that array).
Image is the container's image to be executed.
(Containers) Name is the name for the container in the pod (it must be unique).
Container Port is the port on which the container is listening.

Now, to create the Pod we need to "send" the manifest to the Kubernetes API. We do this by running the following command:

# assume the manifest is stored in a file named 'pod.yml'
kubectl apply -f pod.yml

You should see an output stating the object was created. If you describe the object with

kubectl describe pod/kubernetes-hello-world

and compare it to the description of the object created with the previous method, you will see they are similar in every way.

Health Checks

When you run your app as a container, Kubernetes automatically keeps it alive through a health check. This process guarantees that your app is always running, and if the app fails, Kubernetes restarts it immediately.

This default behavior is helpful in simple scenarios. However, in most cases, it's not enough.

That's the utility of health checks for application liveness. It allows you to run customized health checks to verify that your app is running and working.

The following manifest builds on the previous one by adding a custom health check capability, using what is called a Liveness Probe.

apiVersion: v1
kind: Pod
metadata:
  name: kubernetes-hello-world-health
spec:                                       
  containers:
    - image: paulbouwer/hello-kubernetes:1.9
      name: hello-kubernetes                         
      livenessProbe:
        httpGet:
          path: /
          port: 8080
        initialDelaySeconds: 5                       # 1
        timeoutSeconds: 1                            # 2
        periodSeconds: 10                            # 3
        failureThreshold: 3                          # 4
      ports:
        - containerPort: 8080

This first field specifies the number of seconds to delay the probe's first execution.
Specifies that the probe must respond within the X-second timeout (in our case: 1-second timeout).
Specifies that the probe will be called every X seconds (in our case: 10 seconds).
Specifies that the container will fail and restart if the probe fails more than X times in a row (in our case: 3 times).

Now we create the pod by running:

# assume the manifest is stored in a file named 'pod-health.yml'
kubectl apply -f pod-health.yml

If you run kubectl get pods, you will have the following output (or something similar):

This shows you the two pods we created. the first one without a custom health check, and the second one with a custom health check that restarts the Pod if the container fails more than 3x in a row.

Labels and Annotations

Labels and Annotations are cornerstone concepts in Kubernetes that let you work in sets of objects that represent how you think about your app.

Labels are key/value pairs that can be attached to Kubernetes objects such as Pods and Deployments. They can be arbitrary and are useful for attaching semantic information used to group Kubernetes objects.

Annotations are key/value pairs designed to hold non-semantic information that can be used by tools and libraries.

As we will see, labels are essential to the definition of some Kubernetes objects such as Services and Deployments.

To exemplify the usage of labels, and following the recommend usage of labels in Kubernetes, we will create different versions of our 2 Pods by adding labels. Here you have the manifests:

apiVersion: v1
kind: Pod
metadata:
  name: kubernetes-hello-world-labeled
  labels:                                     # label section
    name: hello-world
    part-of: hello-world
    version: labeled
spec:
  containers:
    - image: paulbouwer/hello-kubernetes:1.9
      name: hello-kubernetes
      ports:
        - containerPort: 8080

apiVersion: v1
kind: Pod
metadata:
  name: kubernetes-hello-world-health-labeled
  labels:                                     # label section
    name: hello-world-health
    part-of: hello-world
    version: labeled
spec:
  containers:
    - image: paulbouwer/hello-kubernetes:1.9
      name: hello-kubernetes
      livenessProbe:
        httpGet:
          path: /
          port: 8080
        initialDelaySeconds: 5
        timeoutSeconds: 1
        periodSeconds: 10
        failureThreshold: 3
      ports:
        - containerPort: 8080

By creating these two pods following a similar approach as in the others, we get this output:

Label Selectors

Show Labels

The first interaction with labels is to quickly see all the labels associated with the objects when we list them, just as we can see in the following image.

Selector

The other, more handy interaction, is to list the objects that have the specified labels. The following image shows two different ways to do this.

Services

As we saw, we currently have four Pods: two of them are labeled and the other two are not.

Imagine that we want to expose the two pods that are labeled. How do we do that? The answer is Services!

Services provide an abstract way to expose an app running on a logical set of Pods and a policy by which to access them. The set of Pods targeted by a Service is usually determined by a LabelSelector.

Services provide three policies to expose your app:

ClusterIP (default type): exposes the service on an internal IP in the cluster. This makes the Service only reachable from within the cluster.
NodePort: exposes the service on the same port of each node by forwarding traffic to that port to the service. It's a superset (an expansion) of ClusterIP.
LoadBalancer: creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. The load balancer directs traffic to the nodes in your cluster using NodePort, so it's a superset of NodePort.

As my Kubernetes Cluster is in a cloud setup (GCP), I will expose my application with a service of type LoadBalancer by creating and applying the following YAML:

apiVersion: v1
kind: Service
metadata:
  name: hello-world
spec:
  type: LoadBalancer      # service type: ClusterIP (default), NodePort, LoadBalancer
  selector:               # label selector (of pods)
    part-of: hello-world
    version: labeled
  ports:
    - port: 80            # the port in which the service gets requests
      protocol: TCP       # the communication protocol
      targetPort: 8080    # the port at which incoming requests are forward

And you will have the following output:

As you can see, the service is exposed in IP 35.197.19.160, at port 80. So if I access http://35.197.19.160:80, I see my app up and running:

Wrap Up

That's all for this post! As of a summary, we:

transitioned from imperative object definitions to declarative ones;
explored how to define custom health checks to our pods;
learned the basics of how labels and annotations work;
understood how to expose applications using services.

In the next post, I will address how to create true deployments with dynamic pod creation and destruction, and also how to use Ingress as a way to expose and load balance our applications.

If you liked my post, you can follow me, see my other posts or check my Kubernetes repo with additional resource examples.

Learning Kubernetes - Part I: Introduction

Vasco Ramos — Wed, 10 Mar 2021 19:04:38 +0000

This post is the first part of a series about Kubernetes. Rather than a series of tutorials, this is meant to be a periodic log of my journey learning the concepts and tools regarding orchestration using Kubernetes.

Installation

As I intended to learn how to use Kubernetes (not managing it), I started a Kubernetes cluster in Google Cloud Platform and worked from there. Hence, I will not address Kubernetes cluster installation and configuration in this series. For more details on how to use the GCP Kubernetes cluster, click here.

First: the concepts

One thing that always helps me better understand and learn a new technology or tool is to understand what is the purpose of the tool or technology, what it is used for, and get the concepts right.

Making sure you understand the basic concepts is a great help in the road ahead of improving your knowledge of the tool/technology you're learning.

So, let's start by understanding what is Kubernetes.

Kubernetes

Kubernetes is an orchestration tool that allows us to manage containerized applications across a group of nodes. Not only providing mechanisms to quickly run those but also how to update, deploy and provide access to them.

Pod: the atom in the Kubernetes universe

A pod is the smallest unit inside the Kubernetes cluster and it represents a collection of application containers and volumes running in the same isolated execution environment. Each container in the same Pod shares the same IP address, namespace, and storage.

Although I described a pod as a collection of containers, the most common pattern is to have one container per pod. If you need to think twice about group multiple containers in the same pod, ask yourself

Will these containers work properly if they land on different machines?

If the answer is "no", you should indeed group those containers in the same pod, otherwise, just don't do it.

Kubectl: the basics

Before going any further, let's see some basic capabilities of kubectl (Kubernetes command-line tool).

Version and Status

To ensure kubectl and Kubernetes is working properly, you can run:

kubectl version

And you should see something like the image below, where it's listed the version of your Kubernetes cluster and client.

Furthermore, you can also check the status of your Kubernetes cluster main components with:

kubectl get componentstatuses

Which should provide you with an output similar to this one:

Nodes

To get information about the nodes that make up the Kubernetes cluster and can be scheduled with work run the following command:

kubectl get nodes

This command, as you can see in the following image, gives you a list with some basic information for every node of your cluster. As I said earlier, my cluster is on Google Cloud Platform, so, depending on your setup (a local cluster or a cluster in another cloud provider), the output may be a little different.

Pods

Now, to quickly show you about pods, let's create one by running:

kubectl run kubernetes-hello-world --image=paulbouwer/hello-kubernetes:1.9 --port=8080

Note that kubectl run is not the ideal way to do things, but let's do it for the sake of the example. In the next post, we will explore the right way to define resources (the declarative way). You should see an output similar to this one:

Now, if you run:

kubectl get pods

You will get the following output, where you can see the pod that was created with the kubectl run command.

You can also check more details with other commands such as describe and logs, as follows:

kubectl describe pods kubernetes-hello-world
kubectl logs kubernetes-hello-world

The first gives you a detailed description of the specified pod, as shown below:

Name:         kubernetes-hello-world
Namespace:    default
Priority:     0
Node:         gke-kuar-cluster-default-pool-41051aa0-hs4q/10.138.15.194
Start Time:   Thu, 11 Mar 2021 17:44:41 +0000
Labels:       run=kubernetes-hello-world
Annotations:  <none>
Status:       Running
IP:           10.96.14.3
IPs:
  IP:  10.96.14.3
Containers:
  kubernetes-hello-world:
    Container ID:   docker://db09b9c745c03f3e757f1f386f5df8e04e48faaace587cfa72ed1f3e6a751300
    Image:          paulbouwer/hello-kubernetes:1.9
    Image ID:       docker-pullable://paulbouwer/hello-kubernetes@sha256:be6b5ba3abdca6e01689e0d1d27b41410fb5bf5793da407108a89ef355f362f0
    Port:           8080/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Thu, 11 Mar 2021 17:44:50 +0000
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-dzc9f (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  default-token-dzc9f:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-dzc9f
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  23m   default-scheduler  Successfully assigned default/kubernetes-hello-world to gke-kuar-cluster-default-pool-41051aa0-hs4q
  Normal  Pulling    23m   kubelet            Pulling image "paulbouwer/hello-kubernetes:1.9"
  Normal  Pulled     23m   kubelet            Successfully pulled image "paulbouwer/hello-kubernetes:1.9"
  Normal  Created    23m   kubelet            Created container kubernetes-hello-world
  Normal  Started    23m   kubelet            Started container kubernetes-hello-world

The second option gives you the logs related to the running container(s). These methods of debugging and inspection are available in every resource available in Kubernetes (Pods, Deployments, Services, etc).

One final way to debug your application besides the logs is to inspect and interact with the running container(s) with exec with:

kubectl exec -it kubernetes-hello-world -- sh

You can see one example of this interaction in the following image:

Finally, to delete the created pod, run:

If you like my explanation, you can follow me, I will publish the following parts of this series in the coming weeks.

Click here for the next part.

Get Started with Java Logging (and some tips to easily learn new libraries)

Vasco Ramos — Mon, 10 Aug 2020 14:36:40 +0000

When I started my journey in computer science 3 years ago as a CS undergraduate student, I began to learn the basics of programming in python (attribution statements, conditions, loops, functions, recursion, others). Then, I moved to Java with OOP (Object-Oriented Programming) and, during all that time, I never used logging to debugging or monitoring purposes... I would always use print statements. Only if I knew better, it would have saved me a lot of time.

Before going to implementation details, I will give a quick overview of logging and its levels.

Logging Levels

The most common levels in logging frameworks are Debug, Info, Warn, Error and Fatal.

Debug

This is usually the most verbose log level. It allows you to understand the core code execution path in certain important processes. As the name implies, these messages help debug tasks since it allows us to trace what's going on in the code.

Info

This level is usually used to highlight when something has happened. It's active by default, as opposed to Debug. It's usually used as an "assertion" that everything is operating smoothly, and since this messages use to contain little notes related to performed actions, at the end of the day, info messages are, essentially, just noise.

Warn

It's used to report harmful situations that aren't relevant enough to require immediate action and can be fixed later.

Error

At ERROR level, are logged error events that might still allow the application to continue running, but still, require immediate or close to immediate response.

Fatal

As stated in Tutorials Point, Fatal-level messages are used to report very severe error events that will presumably lead the application to abort.

Java Logging

Passed the overview, let's get started with Java logging. When you are finished reading, you will know how to approach logging in your Java source code, and better yet, how to learn and approach a new library in the scope of your project.

Assumptions

For the sake of focus and simplicity, I'm going to use IntelliJ IDEA and I'm also going to assume that you already have the Java JDK installed on your machine.

I am going to use a simple "dummy" project to explain logging in java, but you can include this code and config directly into your project.

My project structure looks like this:

Using a Logging Framework

In this tutorial, I'm going to use Apache Log4j 2 because it is a widely used framework and I quite like it, but there are a bunch of other Java Logging Frameworks (see more here).

In this project, I am using Maven so, to add log4j to the project, I need to add the following XML to my pom.xml:

<dependency>
   <groupId>org.apache.logging.log4j</groupId>
   <artifactId>log4j-api</artifactId>
   <version>2.13.3</version>
</dependency>
<dependency>
   <groupId>org.apache.logging.log4j</groupId>
   <artifactId>log4j-core</artifactId>
   <version>2.13.3</version>
</dependency>

Configuring the Logger (a different approach)

This bit is where I present to you a different approach from so many others logging config tutorials. Following the line of thought from Robert C. Martin in Clean Code, I decided to explain the learning and configuration process of a third-party library through learning testing. As the author elaborates in the book, using learning tests to approach third-party code that is going to be introduced into your project is a good practice because:

You can test the library capabilities and specificities in a controlled environment with a series of objective and precise experiments.
The tests you write in this learning process are a good tool to test new releases of the third-party package, where you can easily see if something changed which enables you to make an informed decision whether to upgrade the package version or not.

That being said, our journey begins. The first step is to add testing capabilities to our project. To do so, we need to add this XML to pom.xml (I'm going to use JUnit 5):

<dependency>
   <groupId>org.junit.jupiter</groupId>
   <artifactId>junit-jupiter-api</artifactId>
   <version>5.6.2</version>
   <scope>test</scope>
</dependency>
<dependency>
   <groupId>org.junit.jupiter</groupId>
   <artifactId>junit-jupiter-engine</artifactId>
   <version>5.6.2</version>
   <scope>test</scope>
</dependency>

Testing Default Behaviour

Next, without configuring anything, we will test our third-party package (log4j). The tests I wrote are fairly simple but are enough to test the basic capabilities of our logging framework.

public class LogTest {
    private Logger logger;

    @BeforeEach
    public void init() {
        logger = LogManager.getLogger("TestLogger");
    }

    @Test
    void testSimpleMessage() {
        String message = "Hello World!";

        logger.trace(message);
        logger.debug(message);
        logger.info(message);
        logger.warn(message);
        logger.error(message);
        logger.fatal(message);
    }

    @Test
    void testFormattedMessage() {
        String formattedMessage = "Hello {}, this is my current grade {}!";
        String word = "World";
        double grade = 17.64;

        logger.trace(formattedMessage, word, grade);
        logger.debug(formattedMessage, word, grade);
        logger.info(formattedMessage, word, grade);
        logger.warn(formattedMessage, word, grade);
        logger.error(formattedMessage, word, grade);
        logger.fatal(formattedMessage, word, grade);
    }
}

These tests are not going to fail, instead, they are going to show us what is the default behaviour of our logger.

The output implies the format that is being used and what is the upper level that is enabled by default (ERROR).

Configuration

First, go to "Project" tool window in IntelliJ and expand the folders till you locate the "resources" folder (java -> src -> main), just like in the image I showed earlier.

Now, create a file name log4j2.properties inside that folder.

After the file is created, insert the following specifications in the file:

name = Log4j2PropertiesConfig

appenders = console

# configuration of console logging
appender.console.type = Console
appender.console.name = STDOUT
appender.console.layout.type = PatternLayout
appender.console.layout.pattern = %highlight{%-21d{yyyy-MM-dd HH:mm:ss} %-12c %-8level %m%n}

# default root logging config
rootLogger.level = debug
rootLogger.appendRefs = stdout
rootLogger.appenderRef.stdout.ref = STDOUT

When you insert these configurations, the result of re-running the tests is the one you can see below:

Some detail:

name: just specifies the name of that specific configuration layout.
appenders: the name of the different appender components (the ones that effectively writes the message to some medium).
The remaining configuration follows the same line of thought and for more detail see here.

Happy Learning!

What I've tried to show you today is just an over-simplified introduction to the path of understanding logging usage and configuration with log4j2. If you want, there is a lot more to learn!

Here are some suggestions on what you can do:

Learn how to have multiple appenders, each with a different type of output (console, file, etc).
Learn how to configure different loggers, one for each log level.
Play with the options available for the "layout" entry.
Learn about the other ways you can configure log4j.

Furthermore, as I said, there are lots of options for logging frameworks; when you feel confident enough with log4j, try some of them.

My Experience with Java Debugger - Beginner Tips

Vasco Ramos — Tue, 28 Jul 2020 00:00:00 +0000

Recently, while working on a Java project with IEETA Bioinformatics - UA, I needed to do some serious debugging in the code. As I was new to the project and didn't have a strong knowledge of the project's codebase, I decided to use the Java debugger to inspect the behavior of the code and better understand the flow where the specific bug was occurring. That too was a challenge because I had never used a debugger.

Hence, I decided to write this article to help other programmers that, like I, are beginners at proper debugging and also to help me structure the knowledge I have recently learned.

NOTE: This article uses visual examples from IntelliJ IDEA, but the same concepts can be found and applied across most alternative JAVA IDEs.

Breakpoints

A breakpoint allows you to specify where the program should stop when debugging so you can analyze the state of the program (inspect existing fields and variables, change its values, and more) and find what is wrong with your code.

Every debugger offers several types of breakpoints such as:

Line breakpoints: Halt the program upon reaching the line of code where the breakpoint was set.
Method breakpoints: Halt the program upon entering (or exiting) the specified method. This allows you to check the entry or exit conditions of a particular method.
Conditional breakpoints: Halt the program when a certain criterion (condition) is met
Exception breakpoints: Halt the program when Throwable or its subclasses are thrown.
Watch points: Halt the program when the specified field is read or written to.

Here is an example of a condition breakpoint on the IntelliJ IDE, set on line number 73.

In addition to setting breakpoints, you can also remove, mute, enable and disable them. Mute a breakpoint is extremely helpful when you don't need to stop at some specific breakpoint for a while. Another helpful possibility is to enable/disable breakpoints, which is useful because when you delete a breakpoint, its internal configuration is lost, so enabling/disabling breakpoints it's a less terminal operation that allows you to temporarily turn an individual breakpoint off without losing its parameters.

Step Actions

Every Java debugger provides a set of features (stepping actions) that allow you to navigate through different sections of your code when debugging, including:

Step Over: Steps over the current line and takes you to the next line, even if the current line has method calls in it (the implementation of the methods is skipped).
Step Into: Steps into the method to inspect what happens inside it.
Force Step Into: Steps in the method even if this method is skipped by the regular Step Into.
Step Out: Steps out of the current method and takes you to the caller method.
Drop Frame: Allows you to undo the last frame and restore the previous frame in the stack. This can be useful if you've mistakenly stepped too far or want to re-enter a function where you missed a critical spot.
Step Filter: Allows you to skip certain packages during debugging. You don’t have to navigate through all classes of the JDK system when you can simply filter out types you don’t need.

Variables Pane

Although the inline debugger is extremely helpful, the variables pane shows a lot more details. With its help, you can see the exact state and value of each variable in the selected stack and can even change the value of those variables, if you need to better understand what effect a specific change in your variable has in the execution of your code.

If you want a more hands-on approach to this topic, there is this great video from JetBrains that walks you through the concepts I described and its implementation/application in IntelliJ UI.

Wrap Up

Finally, remember that debugging might sometimes take more time than the actual implementation. As you improve your Java debugging skills, always try to write clean, efficient code - it makes an enormous difference when it comes to debugging.

When you do need to do some debugging, remember that you only need to have to be creative and use the right tools.

And even with the right tools, when things seem to get out of hand, it’s always worth taking a break. A bug is nothing more than a programming puzzle, and sometimes you just need a break from the code to solve the bug.

Hello World

Vasco Ramos — Sun, 14 Jun 2020 00:00:00 +0000

This is the first post of my new personal blog. This blog will be a digital registry of some of my findings and experiences with software development and different technologies. Feel free to check out my other posts and to reach out on my social presence.