DEV Community: Swapnil V. Patil

Getting Started with Kubernetes Networking

Swapnil V. Patil — Wed, 19 Oct 2022 19:18:46 +0000

In this article, we will examine the idea of Kubernetes networking with the help of 10 detailed diagrams and additional context for both novice and experienced readers.

Introduction

Networking is a key topic in the Kubernetes universe. In addition to the fact that Kubernetes applications require access to resources outside the cluster to function, Kubernetes networking also allows you freedom. It promotes the usage of loosely linked service architectures.

We’ll expose you to the fundamentals of Kubernetes networking in this article. We’ll discuss how loosely coupled services may interact to build sophisticated, large-scale systems, how these services can talk to other services, and how different services can talk to our services.

Terminology Used in Networking

We need to define a few networking terminologies before we can begin to talk about Kubernetes. There are a few basic methods that one system communicates with another system in almost all networked systems.

In Figure 1, an application is communicating with Computer “A” on the left and Computer “B” on the right. Several things need to take place for that conversation to happen.

First, Computer “A” must determine the location of the program using the following two pieces of knowledge:

Hostname.

The Computer “B” has been given this unique name. We are using app.myapp.com in this instance.

Port quantity.

This particular address on Computer “B” indicates which program to communicate with on that machine. In this example, the port number is “12953.”

To locate the desired application, Computer “A” takes the hostname and performs a lookup to determine the computer’s IP address. The IP address is the address the underlying network protocols use to locate Computer “B.” It does this by contacting a service called DNS, or Domain Name System. The DNS service performs a lookup to map the hostname to the computer’s IP address. This is analogous to how a phone book is used to find a person’s name and phone number.

Once Computer “A” knows the IP address of Computer “B,” it can send a message to “B” by sending it to the IP address.

This IP address is connected with a particular network interface on computer “B.” The message is sent to a specific port on Computer “B,” allowing it to be delivered to the desired application. A network interface/port number pair is assigned to each application on the computer, ensuring that all communications arriving on a specific network interface (identified by the IP address) and a particular port number are forwarded to the intended application.

Many port numbers are standard among popular applications to make it simpler to discover the relevant program. For instance, port 80 is used by the “HTTP service,” which handles requests for online pages. The “FTP service” for file transfers uses port 21. For the “SMTP service,” port 25 is the standard port used to send emails.

There may be several network interfaces on a machine (for instance, a cell phone typically has one for WiFi networking and one for cellular networking). Additionally, they could include one or more virtual network interfaces. As a result, a single machine might be linked to multiple IP addresses.

Figure.1 Terminology Used in Networking

This is the foundation for all application-to-application and user-to-application networking on the internet today.

The Fundamental Kubernetes Cluster

When it comes to Kubernetes clusters, things get a little more intricate. Let’s take a look at the fundamental components of a Kubernetes cluster.

Containers like those created with Docker run our applications and application services. These containers are contained within a Kubernetes object known as a pod. A pod is a Kubernetes system’s smallest addressable component. A single pod contains a single container (although it can include multiple containers cooperating) and accomplishes the work of a single service instance.

In a Kubernetes-based system, many pod instances will typically run concurrently for the same application. When these pods are combined, they form a Kubernetes service. A Kubernetes service is a collection of deployed pods performing the same function. A service will distribute the workload it must perform across all of its pods. An application will typically have several instances of such a particular service running to distribute the workload and provide a higher level of availability.

Each pod in each service must be run on a computer instance. These computer instances are referred to as nodes in Kubernetes. A Kubernetes node can be a standalone server or a virtualized server instance. To increase availability, the nodes of a single service are typically distributed across multiple nodes. As a result, if a node fails and the pods on that node terminate, the service can continue to operate by distributing the workload to other pods on other nodes.

Figure 2. The Fundamental Kubernetes Cluster

A Kubernetes cluster is formed by all of the nodes running all of the pods in a Kubernetes system working together. Figure 2 depicts the components of a single cluster.

Inter-Pod Communication

We already mentioned network interfaces, but one feature of network interfaces is that they enable a single computer to divide processes into multiple network namespaces, each of which is assigned to a different ethernet interface. Namespaces are typically isolated and cannot communicate with one another without passing through the ethernet interface. Each pod in a Kubernetes cluster is assigned a unique namespace, so you must communicate with the code running in the pod via the assigned ethernet interface.

The node establishes a network tunnel between each pod and the root namespace. Pods can communicate because they all have a tunnel to the root namespace. The root namespace is also a namespace for the node.

Figure 3 shows an example of this.

The root namespace assigns a unique IP address to each pod (a unique range of IP addresses called a CIDR block). Messages sent from one pod are routed to the correct pod by the root namespace using the message’s destination IP address. This is exactly how messages are sent from one computer to another in regular networking. Messages are sent from one pod to another in this case.

When a message is sent to an IP address representing a pod on another node in a different node case, the root namespace sends the message over the typical network connecting the nodes to the node with the destination pod. The message is sent to the destination node’s root namespace, which routes it to the appropriate pod. The same model applies to communication between two pods on the same node and between two pods on different nodes.

Figure 4. Pod to pod communications across nodes

“How does the root namespace know which node to send a message to?” is an intriguing question. How does any given node know where to send a message for it to reach the correct pod? “ Each node may have hundreds of pods, each with one or more unique IP addresses (CIDR blocks), and a Kubernetes cluster may contain hundreds of nodes.”

Kubernetes ensures that each pod in the cluster has a distinct set of IP addresses, allowing each pod to be identified. The IP addresses and how to get to them are then broadcast to each node in the system using a standard network protocol known as ARP. This protocol generates a map, or route, from any given node to any other node’s IP address. Because the exact makeup of pods in the system can change frequently, this protocol dynamically creates this map, which is automatically updated continuously.

The same question arises in traditional networking: “How do you know where to send a message destined for a specific IP address?” The same ARP protocol, along with other standard routing protocols and default routes, determines how any given computer on the internet can communicate with any other computer on the internet automatically and dynamically. In addition, the ARP protocol is used in standard host-based networking. It’s dynamic, fast, scalable to a massive number of hosts, and highly stable. It has been the backbone of the internet since the 1960s.

Communication via Services

Although each pod has an IP address that allows it to be directly addressed, this model has one major flaw. Pods appear and disappear. If a pod encounters a problem, it is terminated, and a new pod is launched. New pods are created when traffic to a service increases and more instances are required to handle the traffic. Pods are essentially temporary, and so are their IP addresses. How can you send a message to a pod when the IP addresses of the pods change?

The service is the solution to that problem. A Kubernetes service is a front end for a collection of pods that perform the same functions. All pods in a system that perform the same functions are considered part of the same service. Pods are added and removed from the corresponding service as they are launched and terminated, ensuring that the service always has a list of valid pods and IP addresses.

If you need the capabilities of a pod, you now send a message to the service rather than directly to the pod. The request is then routed to one of the pods that the service knows is active. The service can load balance requests across a series of pods performing the same capability, even if those pods are located on different nodes.

The service keeps track of which pods are currently active and routes requests to the appropriate active pod. The service is associated with a fixed, assigned IP address. This IP address is typically never changed, so anyone wishing to engage a pod to perform some action can contact the service at a well-known IP address without worrying about which pod is implementing the request. Figure 5 depicts a service called “ABC” and the pods to which it is linked. In the diagram, one pod is dying, and a new pod is being created.

Figure 5 shows how a service generates a virtual address in front of changing pods.

Pod to the Service

When services are involved, the network message routing for one pod talking to another differs slightly. Figure 6 shows Pod A sending a message to Service ABC. This service in the node’s root namespace determines which pod to send the request to. It then updates the message’s IP address to include the correct IP address of the selected pod and forwards the request to that pod (Pod D in this example). The message routing from the service to the pod is the same as shown in Figure 4. If a pod is terminated and a new one is created, the new pod will receive requests sent to the service instead of the old one. The pod mapping service is entirely dynamic

Figure 6: Service-based pod-to-pod communication.

External Internet to Service

Services enable the external internet to easily access the capabilities of the pods within the cluster without having any knowledge of how the pods are laid out in the cluster. A load balancer is attached to the front end of the system facing the internet when a service is created that is designed to accept traffic from the external internet. It directs traffic to the nodes containing the service. The service then selects an appropriate node to which to send the message. As a result, an external internet request can be routed to a specific pod without the requestor knowing the address of the pod.

Figure 7. Service load balancer for external internet access

Figure 7 depicts a message being routed from the external internet (bottom of image) to the service load balancer, then to the service on a node, and finally to the destination pod.

Services for DNS and Kubernetes

The service has a publicly visible IP address for receiving traffic, we can enter it into DNS and refer to it by its hostname rather than its IP address. Figure 8 depicts the hostname “app.myapp.com,” which maps the request to the IP address of the service load balancer in charge of this service.

Figure 8: DNS allows for application discovery.

Communication between clusters

Communication between pods in two different clusters is handled similarly to communication with the outside internet. The pod sending the request queries DNS for the hostname and obtains the IP address of the service load balancer. The load balancer routes the request to one of the destination cluster’s nodes. This node routes the request to the correct pod within the destination cluster.

Large-scale Service-Oriented Applications

Using Kubernetes to build a large service-based application is an exercise in creating multiple Kubernetes services, each of which operates numerous pods. The pods are distributed across multiple nodes to ensure proper load balancing and service-level availability.

Figure 9 depicts a typical service-oriented application (top) and how Kubernetes services and pods map onto it.

Figure 9. Kubernetes services and nodes are mapped to a service-based application.

These nodes are spread across multiple nodes within the cluster, with pods for each service distributed across numerous nodes for availability. Figure 10 depicts the application as seen by pods running on nodes.

Figure 10: Node-based service-based application

This application distribution makes it easy to see why pod-to-pod communication across node boundaries via services is so important. In a Kubernetes cluster environment, Kubernetes provides the networking infrastructure for complex service-oriented architectures to exist and thrive.

Last Thoughts

This was a basic explanation of how networking works in a Kubernetes cluster. Kubernetes is very flexible regarding how it allows communication between pods within the cluster and with the internet. While the details can become technical, the high-level overview is straightforward. Kubernetes networking offers a sophisticated and adaptable model for networking in a distributed containerized environment.

10 Git Best Practices to Start Using in Your Next Git Commit

Swapnil V. Patil — Sun, 16 Oct 2022 18:27:43 +0000

Conflict?

Don’t we all eventually find ourselves wondering…?

What aims does this code pursue?
How did this bug get there?
How should I start working on this sizable pull request?

Code comments, style guides, and documentation are a few solutions to these problems, and we all, at some point, have unavoidably wasted hours trying to comprehend code.

Git commits are more than just saved points or logs of every single step in a larger project. A stable and collaborative open or closed-source project depends on high-quality Git commits.

Let's discuss some pointers to enhance and streamline your development process. So without further ado, let’s get started.

What do commits mean 🤷‍♂️

Commits are periodic & logical changes; Ideally, each change is the smallest possible unit in the git repository. The history of your repository and how it came to be the way it is now should be chronicled throughout time through commits.

To put it simply, commits are a first-person historical record of precisely how and why each line of code was created.

Commits work best when they are polished and adjusted to specifically address their target audiences, which may include reviewers, other contributors, and even your future self.

The Anatomy of a Commit Message 🫀

Basic:

git commit -m <message>

Detailed:

git commit -m <title> -m <description>

Writing Better Commits 👍

Capitalization and Punctuation 🅰️

Put the first word in capital letters and omit the period in the end. Keep in mind to utilize just lowercase letters while utilizing traditional commits.

Mood 🌚

In the subject line, use the imperative mood. When you use the imperative mood, you convey that you are issuing a command or request.

Type of Commit 🥸

Indicate the kind of commit. A set of phrases to explain your consistent modifications across the board is advised and much more helpful.

Length 🍢

The body should be limited to 72 characters, and the opening line should ideally not exceed 50 characters.

Content 📃

Be concise and attempt to avoid using extraneous words and phrases.

Structure the narrative 🪶

The “story” of your modification is contextualized with the code using the narrative framework of a series of commits. Your project’s history should be depicted in the commits. It ought to be your project’s biography.

Commits that are disjointed and lack a straightforward narrative will impact both the reviewer and the developer.

The reviewer will have to switch contexts if those commits don’t provide a straightforward narrative since they move from subject to subject.🥴

Rearrange your commits to correspond to your narrative’s plan.

Huenry Hueffman 🔜 Reboot Blue on Twitter: "I fucked up Git so bad it turned into Guitar Hero pic.twitter.com/vUKZJAQKWg / Twitter"

I fucked up Git so bad it turned into Guitar Hero pic.twitter.com/vUKZJAQKWg

Resize and stabilize the commits ⚛️

The code in each commit generates software, even though the structure of a commit series might describe a feature’s high-level history. Even though code can be pretty sophisticated, people must comprehend it to work together. Make each commit “atomic” and “short,” then.

A small commit only does one “thing” and has a limited reach. When a commit is a reliable, standalone change unit, it is atomic.

Explain the context ❓

Code in commits is only one aspect of what they are. Although valuable, commit messages are frequently ignored commit components. In the commit message, please explain what you’re doing and why you’re doing it.

What readers need to grasp should be communicated in a committed message’s content.

Commit Early & Often ⌚

Early and frequent commitments help you commit just related changes and keep your commits minimal. Additionally, it enables you to avoid merge conflicts and share your code more frequently with others.

I know Git, depending on what you mean by “know”.

Conventional Commits 📜

Conventional commit is a formatting standard that offers a set of guidelines for creating a constant commit message structure.

The following is a list of possible commit types:

feat

Title: Feature
Description: A completely new feature
Emoji: ✨

fix

Title: Bug Fix
Description: A bug fix
Emoji: 🐛

docs

Title: Documentation
Description: Changes only to the documentation
Emoji: 📚

style

Title: Styles
Description: Alterations that don’t change the code’s intent(white space, formatting, missing semi-colons, etc.)
Emoji: 💎

refactor

Title: Code Refactoring
Description: An update to the code that neither adds features nor fixes bugs
Emoji: 📦

perf

Title: Performance Improvements
Description: A performance-enhancing tweak to the code
Emoji: 🚀

test

Title: Tests
Description: Addition of tests or updating of tests
Emoji: 🚨

build

Title: Builds
Description: Modifications to the build system or external dependencies
Emoji: ⚒️

ci

Title: Continuous Integrations
Description: Modifications to our CI configuration scripts and files
Emoji: ⚙️

chore

Title: Chores
Description: Other updates that don’t alter the test or src files
Emoji: ♻️

revert

Title: Reverts
Description: Reverts a previous commit
Emoji: 🗑

Now, let’s see some commit aliases:

initial

Maps to: feat
Title: Initial
Description: Initial Commit
Emoji 🎉

dependencies

Maps to: fix
Title: Dependencies
Description: Update dependencies
Emoji: ⏫

peerDependencies

Maps to: fix
Title: Peer dependencies
Description: Update peer dependencies
Emoji: ⬆️

devDependencies

Maps to: chore
Title: Dev dependencies
Description: Update development dependencies
Emoji: 🔼

metadata

Maps to: fix
Title: Metadata
Description: Update metadata (package.json)
Emoji: 📦

Good Commits VS Bad Commits ⚡

Never miss a commit

Good 👍

git commit -m “Add margin to nav items to prevent them from overlapping the logo”

♻️ chore: update npm dependency to the latest version

✨ feat: set the background color to red to improve contrast

🐛 Fix bug redirecting users to 404 page

Bad 👎

git commit -m “ Add margin”

lazy loading

dependency updated

Set bg to red

endgame

deleted all the files

Style changed

Additional Resources 🌟

git-absorb: A tool that divides random fixes into allocated fixups automatically commits
Commitizen: Its primary goal is to establish a uniform method for committing rules and disseminating them via the Commitizen CLI.
Git Commit Message Emoji List

Thank you so much for reading!

Happy coding!

A Bootstrapped Guide to Building a Community That Will Last

Swapnil V. Patil — Sun, 16 Oct 2022 18:25:41 +0000

Credits: Photo by John Cameron on Unsplash

Introduction

When you build an open source project, you’re building something for the community. But what does that mean? How do you create a community around an open source project? What makes a great open-source community? In this post, we’ll explore these questions and more.

Make it easy for everyone to understand how to use your project.

The best way to get people involved is by making it easy for everyone to understand how to use your project. This can be done in a number of ways:

A clear description of the purpose and motivation behind your project. If you don’t explain what you’re doing and why, then no one will want to help build on top of it.
A getting started guide explaining how quickly new developers can learn enough about the system so that they can get started contributing code or documentation or testing features.
Listing out common use cases so that when someone asks “What am I supposed to do with this?”, there are already examples available — and even if those examples aren’t exactly what you had in mind, there may still be something useful for them based on their knowledge level!

Make it easy for everyone to contribute to your project.

One of the most important things to keep in mind is that everyone should be able to contribute. This requires making it easy for people to understand what they need to do and where they need to go.

It’s also important for contributors not only feel confident about their contributions, but also that whatever contribution process you have in place is clear and easy for everyone involved.

Build personal relationships.

To build a vibrant open-source community, it’s important to have personal relationships with contributors. You can do this by:

Giving credit where it is due. If you’ve used the code in your project and made an improvement to it, let the original author know that you appreciate their work and share what changes you’ve made so they can use them too!
Being aware of contributors’ time constraints. Some people are very busy with other projects or jobs — if this is something that’s going on in your team as well, make sure everyone knows how much time they need for each task before starting any big new feature or project (or at least give people enough warning). This will help keep everybody motivated and focused on what needs doing at any given time!
Being aware of contributors’ personal lives outside work hours too; sometimes working late into nights has been known to happen without anyone realizing until months later when someone finally goes “Hey guys did we all complete our tasks?”

Curate and thank users and contributors, as your community grows.

It’s important to thank people in public and private. You should also be sure to use a personalized message when thanking contributors, since they’ll know they’re being thanked by name (and not just “thank you”). And if you want to give an example of how much your community means to you, consider sending out a personal note thanking all of the people who have helped build it up over the years.

When it comes down to it, this is one of those things where we think it’s best done organically: just keep track of how many times people contribute or retweet something cool enough that it deserves some sort of acknowledgment from on high (or however else feels right).

Make people feel included.

It’s important to make it clear to everyone that your community is a safe place for everyone, and that you have a code of conduct. This can be as simple as posting a link to your code of conduct on your website or providing it in an email newsletter.

There are many ways you can enforce the code of conduct: You could create an online forum where people can post questions or concerns about your project; you could require members who violate it to leave the group; or even ban violators from participating in any way (e.g., no more comments).

Create a code of conduct, and be vigilant about enforcing it.

A code of conduct is a set of rules for how people should behave in your community. While these rules may be simple and easy to follow, they can also be very strict. They should be enforced by the community itself, not by a single person or group.

A good code of conduct will include:

A statement about what you expect from other members (e.g., don’t harass others).
Guidelines on how you want others to behave (e.g., don’t spam).

Building a community around an open source project is hard work, and can require a lot of effort (but is ultimately rewarding).

Finding time. You need to dedicate some time each day to building your community. This may be difficult for some people who are busy with other things in life, or have too much on their plate already. For others, this might mean taking time away from work or family obligations during evenings or weekends when you could otherwise be doing something else fun!
Finding motivation: It’s not always easy finding enough motivation to keep going with this type of project; it requires dedication over long periods of time (and sometimes even decades). If you don’t feel like there’s enough value in what you’re doing right now then maybe think about how much better off everyone will be once its done — this could give extra incentive! And if someone else works on something similar but doesn’t share any data back then perhaps they’ll share some insights into how things went wrong(?) Or maybe just get together once every few months so everyone knows whats going on?

A great open-source community takes the project to the next level, and helps many people!

Open source projects are built by communities of developers who want to contribute their knowledge and time in order to make something better. If you want your project to become successful, it’s important that you create an inclusive environment where everyone can get involved. This means having a code of conduct (or similar policies), clear explanations of how the project works, and making sure everyone has access — not just those who have technical skills but also non-technical contributors who might benefit from being able to help out with some tasks or provide feedback on features they would like added into future versions of your software program or app store listing.

Conclusion

Building a vibrant open-source community is hard, but it’s worth the effort. If you can make your project welcoming, inclusive and welcoming to new users, they will feel more connected to the project and its goals. You can help make this happen by building relationships with people who are interested in your project or who are looking for ways to contribute — and by fostering an environment where everyone feels welcome as part of a larger community.

What Kubernetes Is And Why Use It

Swapnil V. Patil — Fri, 09 Sep 2022 10:57:46 +0000

Introduction

Kubernetes is the leading container-oriented platform, which allows you to run containers efficiently on top of a cluster of machines. It is a family of open source software that simplifies IT operations by automating deployment, scaling, and management of containerized applications in production.

Why Kubernetes?

Kubernetes is a container orchestration tool that makes it easy to deploy applications in containers. It’s the most popular container orchestration tool, and it has been growing in popularity over time.

Kubernetes was developed by Google engineers as a way to manage their own internal systems at scale. The open source nature of Kubernetes means that anyone can use it—and many companies have! Red Hat, IBM (formerly known as LinuxONE), and Microsoft all support Kubernetes on their operating systems: Red Hat Enterprise Linux 7 LTS; IBM z Systems; and Microsoft Azure Container Service (ACS).

What is Kubernetes?

In a nutshell, Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. It was originally developed by Google in 2014 and has since been adopted by many enterprises as well as startups.

Kubernetes can be used to deploy and manage applications written in any programming language (including Python).

Features of Kubernetes

Kubernetes is an open source container orchestration system.

Kubernetes is a container management tool that can manage containers at scale. It's built on top of Docker and provides a solution for managing large numbers of applications across clusters or clouds, including multi-node clusters in the cloud. Kubernetes also supports advanced features like service discovery, self-healing systems, rolling updates and fine grained policy management across multiple environments like development and production—all without impacting performance or cost.

You can deploy Kubernetes on-premise or in the cloud if you want to run it locally (on your own hardware). With Kubernetes you'll be able to create highly available apps that scale automatically with your infrastructure needs as well as provide high availability by replicating data between two different nodes when needed so that both machines remain up even if one node fails unexpectedly during normal operation - this will help keep everything running smoothly even when things aren't working optimally yet!

Kubernetes vs. Docker Swarm

Kubernetes and Docker Swarm are two different container orchestration tools. They both use the same underlying technology, which is Docker Engine and its API (the command line interface).

Docker Swarm is built on top of Docker Engine and Docker API. It allows you to create clusters that make use of multiple nodes, each running one copy of the software in order to scale up or down as needed without having to manually restart them. Kubernetes was specifically designed with this goal in mind: scaling up/down applications by creating multiple instances that share resources like storage space, CPU time and memory across all nodes in your cluster

Kubernetes Architecture

Kubernetes architecture is a distributed system. The control plane contains the API server, scheduler and controller manager. The worker nodes contain the kubelet, container runtime (Docker), and docker daemon.

The network of control plane components is designed to be as decoupled as possible from that of worker nodes so that changes in one part don't impact another part; however, it's important to note that some aspects are still tightly coupled since they're all implemented on top of Pod objects which exist within each namespace hierarchy.

Go through these topics and get your hands dirty!

The Kubernetes platform, formerly known as Google Container Engine (GKE), is an open source container orchestration system that allows you to automate deployment, scaling and management of containerized applications. It’s designed for any workload from small one-off jobs to large data centers.

Kubernetes was created by the same team behind Hadoop and it has been running on Google's cloud since 2014; however it wasn't until recently (2017) that they decided they would make this technology available outside of their own internal ecosystem. The main reason behind this decision was probably because many people were using containers as part of their microservices architecture instead of virtual machines which would not have been supported by Kubernetes at launch time - hence why we now have two different frameworks with similar names!

Conclusion

Do you want to learn about Kubernetes but don’t know where to start? Follow these five steps and you will be up and running with a Kubernetes cluster in no time!