Image by Gerd Altmann from Pixabay

Kubernetes explained deep enough: Services

Part 5: Services discoverability, DNS, cluster communication

Introduction

This is the fifth part of Kubernetes mini-series Kubernetes explained deep enough

For web version of this blog and more information about docker, Kubernetes and Docker Certification, please visit:

IT Certifications Guide

Katacoda Scenario for self paced learning

Kubernetes Networking: Expose and consume a service | decoder | Katacoda

Part 1: Introduction

Part 2: Kubernetes explained deep enough: Storage

Part 3: Kubernetes explained deep enough: Deployments

Part 4: Kubernetes explained deep enough: Configuration

Part 5: Services discoverability, DNS, cluster communication — this blog

This blog is a little bit longer than other parts of Kubernetes explained deep enough. Kubernetes networking is a very complex topic and trying to write about all nuances of different services and mechanisms would probably take a few blogs on it’s own. Instead we will focus on specific areas of Kubernetes Networking: services and look at their practical applications.

Since this series is about exercising and practical examples, we will focus less on deep diving into each service types, but rather merge them together into a broader category of Networking and look at it from holistic point of view highlighting only those aspects that are important for the examples we will work with.

Visit Kubernetes documentation if you need a refresher about Services

Basic definitions are provided on diagrams below

How does it work?

In Kubernetes service is a resource that abstracts and encapsulates a way of exposing an application running in pods as a network service.

Although services do not require DNS to work, it is strongly recommended to setup DNS service on Kubernetes using an add-on. There are several DNS services compatible with Kubernetes dns specification, 2 most popular are:

• CoreDNS
• Kube-DNS

After DNS service is setup on the cluster, it is very easy to call services taking advantage of the DNS records created for each service. Since Kubernetes networking is flat meaning that resources can communicate with each other directly via their IPs, this means that it should be possible to call any service in any namespace from any pod in any namespace (providing there are no network policies blocking the traffic).

There are 4 types of services in Kubernetes:

https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types

Note on ports: It is often confusing to understand what ports do what in Service manifest, so let’s make sure to refresh the definitions:

• TargetPort is the Port which the application is configured to listen on
• Port is how the application will be accessed from the outside
• NodePort is a static port on each node where service of type NodePort is exposed

What Problem does it solve?

• expose pods to consumers from outside of the cluster
• enables pods to communicate with each other
• service are easily discoverable
• pods up and down scaling does not disrupt communication

How to implement it?

We are going to revisit scenarios from the section What Problem does it solve? and validate that the statements are correct.

If you would like to learn a few useful networking commands, I have created a gist with the ones that helped me pass my CKA certification

Prerequisites

Instead of asciinema recording, this time we are going to use katacoda. You just need a web browser, inquisitive mindset and some spare time to learn new things, no other prerequisites needed :)

Katacoda is a great free service. It is an “Interactive Learning and Training Platform for Software Engineers” that “enables learning new technologies using real environments right in your browser”

Sample Scenario

A very common requirement in any system is ability to facilitate point to point communication between deployed artifacts. One of the most common scenarios for this type of communication is multi-tier architecture (3 tier layers being most common):

• Presentation layer (UI)
• Application layer (business logic, API, middleware)
• Data Persistence layer (typically database, but can be disc etc)

Below diagram shows connectivity between different layers of the multi-tier architecture application. We are going to see how communication part of this setup can be recreated using Kubernetes native resources.

Modern architectures, especially microservices follow different architectural patterns. For example The Twelve-Factor App approach where connectivity between application layer and data persistence layer is done via HTTPS and often UI part of the application is served as a static web app or SPA.

One key difference in Kubernetes world and more broadly, in the era of infrastructure as code, servers are a resource like any other and are dynamically provisioned. Workloads can be reschedules on a different server any any time without notice and everything is expected to work just the same. So first change is that instead of fixed servers we have dynamic, flexible infrastructure. Those are Kubernetes Cluster Nodes.

We are not going to focus on DNS resolution from URL in browser address which happens on public DNS.

Now, let’s see how similar architecture could look like using Kubernetes:

By introducing the service abstraction we have decoupled actual workloads from communication mechanism. This allows us to take advantage of the dynamic nature of Kubernetes infrastructure and unlocked additional possibilities like scaling, separation of layers etc. Kubernetes can now move pods to other nodes, scale them or destroy and re-create without causing disruption to our application.

This time for each scenario we are going to use formalized notation called Gherkin Syntax. This will help us better express goals and conditions of our experiments.

Typically we would use testing framework like Specflow or Cucumber, but for the purpose of learning we are going to execute steps in the Katacoda environment manually.

Let’s describe our scenarios and head to my Katacoda Scenario and experiment on your own!

Kubernetes Networking: Expose and consume a service | decoder | Katacoda

Katacoda Scenarios

Below is an overview of test scenarios prepared in katacoda. Each scenario is written in gherkin syntax and highlights one Kubernetes feature in context of our experiments.

Spoiler alert, all tests passed successfully :)

Challenge

Is there anything you would like to test? Think about a scenario, test it and let us know in comments.