Forem: Master

Platform Setup : How To Structure Your Infrastructure Repository

Master — Wed, 21 Jun 2023 16:13:27 +0000

Welcome to the Platform Setup series, a collection of blog posts where I'll be sharing my insights and experiences from deploying applications in enterprises. With a particular focus on Banking and Insurance companies.

I've been part of dynamic teams ranging in size from 20 to 40 talented individuals, each one contributing to the grand mosaic of software development. We've journeyed from traditional software development methodologies to the cutting-edge vistas of DevOps, Kubernetes, and beyond, fostering an environment of continuous learning and growth.

However, with new methodologies come new challenges. This transition isn't always a smooth sail and in this series, we'll delve deep into the unique struggles faced by teams as they migrate towards more modern, streamlined ways of operation.

This immersive series will touch on an array of topics. We'll dive into the nuts and bolts of secrets management, demystify config management, discuss governance and policy enforcements, and explore the crucial areas of observability and developer enablement.

Keeping all these engaging discussions on the horizon, let's kick-start our journey with an exploration of the infrastructure repository. This initial piece, a relatively short yet informative post, will shed light on how we've structured our infra repositories.

Here is an glimpse of what the repo structure looks like

In the vast expanse of our technology-driven operations, a typical service project employs four distinct repositories to house our source code.

Mobile App: This repository is home to our React Native application. The code here is the heart of our mobile app, powering our operations on handheld devices.
Web App: Next up, we have the Web App repository. This is where we host our ReactJS application.
Microservices: This is where we host our microservices—small, autonomous services that work together. Each microservice encapsulates a specific business capability, and collectively they bring our applications to life.
Infrastructure: Herein resides our Infrastructure as Code (IaC). By treating our infrastructure as code, we maintain consistency, enable version control, and reduce manual error, all while streamlining our IT infrastructure processes.

Environments In IAC

A software application goes through various stages of development before reaching the end users. Each stage is accompanied by an environment, where different set of users approve the progression to a higher environment.

In our repo structure, we represent an environment as a directory inside the envs folder, the contents of each folder represents the current state of that environment.

envs/
|
|-- dev/
|
|-- uat/
|
|-- prod/

Let’s now see, what goes into these directories?

Infrastructure & Applications

An environment consists of base infrastructure (like VMs, DBs & other cloud services) on top of which our application runs.

In our repository, infrastructure resides in the 01-infra directory and is defined using IAC tools (like terraform). As we use Kubernetes as the defacto base infra layer for orchestrating containerized applications.

All our software applications reside in these 3 folders and are installed using helm

02-k8s-tools: Contains a set of cloud native tools like Istio, Prometheus, OPA etc… which helps us manage the Kubernetes clusters
03-dev-tools: Contains a set of dev tools like PGAdmin, Keycloack which helps developers in their development activity. Note: The segregation between 02-k8s-tools & 03-dev-tools is totally optional.
04-services: Contains all the services required to run the application.

The diagram below shows how we segregate infrastructure and applications.

envs/
|
|-- dev/
    |
    |-- 01-infra/
    |   |-- 01-networking/
    |   |-- 02-rds/
    |   |-- 03-eks/
    |
    |-- 02-k8s-tools/
    |   |-- 01-opa-gatekeeper/
    |   |-- 02-istio/
    |   |-- 03-fluent-bit/
    |
    |-- 03-dev-tools/
    |   |-- 01-keycloak/
    |   |-- 02-pg-admin/
    |
    |-- 04-services/
        |-- 01-serviceA/
        |-- 02-serviceB/

Why prefix numbers?

In our repository structure, directories are prefixed with numbers. This is optional but it provides a visual hierarchy and a logical order for the creation and deletion of environment components.

Keeping Your Code DRY (Don't Repeat Yourself)

Up until now, we have seen how environments & applications are organized using directories, but what goes inside in each application/infra directory? Where is the actual IAAC code written?

In order to maintain a DRY codebase and avoid code duplication, the code is organized in modules or packages that can be reused.

In the 01-infra directory, the concept of terraform modules is used to encapsulate infrastructure code that can be reused across different environments. Terraform modules are stored under the top level directory called terraform-modules.

Similarly, for applications directories. Helm charts are used and these chart are stored in the helm-charts directory.

An organization can create their own terraform modules or helm charts by building on top of existing open source modules & charts to suit their specific needs.

The diagram below shows how we use Terraform modules and Helm charts.

helm-charts/
|
|-- service-chart/
|
|-- opa-gatekeeper-chart/
|
|-- keycloak-chart/
|
|-- nginx-ingress-controller-chart/
|
terraform-modules/
|
|-- networking/
|
|-- redis/
|
envs/
|
|-- dev/
    |
    |-- 01-infra/
    |   |-- 01-networking/
    |   |   |-- terragrunt.hcl # Refers to ../../../../terraform-modules/networking
    |   |-- 02-rds/
    |
    |-- 02-k8s-tools/
    |   |-- 01-opa-gatekeeper/
    |   |   |-- values.yaml # Refers to ../../../../helm-charts/opa-gatekeeper-chart
    |   |-- 02-istio/
    |
    |-- 03-dev-tools/
    |   |-- 01-keycloak/
    |   |   |-- values.yaml # Refers to ../../../../helm-charts/keycloak-chart
    |   |-- 02-pg-admin/
    |
    |-- 04-services/
        |-- 01-serviceA/
        |   |-- values.yaml # Refers to ../../../../helm-charts/service-chart
        |-- 02-serviceB/
            |-- values.yaml # Refers to ../../../../helm-charts/service-chart

Within each application or infrastructure directory, there are just configuration & CI/CD files. No IAC code is present in this directory.

This config files are used with the terraform module or helm charts to create the actual infrastructure.
This can be compared to calling a function with parameters, where the function to be called is defined inside helm-charts or terraform-modules directory & the actual call to the function exists in the infra/application directory.

Let’s now see, how we manage common configuration?

Managing Common Configuration

In complex systems, it's quite common to have configurations that are shared across different components of the infrastructure and applications. Organizing these configurations efficiently can be challenging but crucial for maintainability and understanding the system's behavior.

In our repository structure, these shared configurations are identified and stored in dedicated _base directories. This helps in reducing redundancy and maintaining consistency across the components or applications.

Let's dive into this in more detail:

Common configuration per environments: If there is a configuration common across an environment (like a cloud region or an AWS role), it is stored in the _base directory under an environment directory like dev. This makes it accessible to all components & applications in that environment.
Common configuration across individual infrastructure components or applications: If there's a configuration common to individual infrastructure components or applications (like a kubernetes namespace or cloud credentials), it is stored in the _base directory which is present for every application & infrastructure directory. This makes the shared configuration easily accessible to all services.

envs/
|
|-- dev/
    |-- _base/
    |
    |-- 01-infra/
    |   |-- _base/
    |   |-- 01-networking/
    |   |-- 02-rds/
    |   |-- 03-eks/
    |
    |-- 02-k8s-tools/
    |   |-- _base/
    |   |-- 01-opa-gatekeeper/
    |   |-- 02-istio/
    |   |-- 03-fluent-bit/
    |
    |-- 03-dev-tools/
    |   |-- _base/
    |   |-- 01-keycloak/
    |   |-- 02-pg-admin/
    |
    |-- 04-services/
        |-- _base/
        |-- 01-serviceA/
        |-- 02-serviceB/

It's also important to note the precedence of the configurations. Any configuration defined in the component or application directory itself has the highest priority and will override what is defined in the respective _base directory. This allows for more specific configurations when needed, without disturbing the shared configuration's general consistency.

This approach ensures a balance between avoiding redundancy and allowing customizations where necessary, making the system robust and adaptable.

Conclusion

In conclusion, we've explored how to effectively structure our infrastructure repositories to manage complex environments and application deployments. We've examined the purpose of different directories and how shared configurations are organized for maintainability and adaptability.

Join me in the next blog post where we'll delve deeper into Infrastructure as Code, specifically focusing on using Terraform and Terragrunt for infrastructure management. We'll discuss how these powerful tools can automate and simplify the provisioning of cloud resources, and explore how they fit into the repository structure we've outlined in this post.

Stay tuned for more insights and practical tips on optimizing your platform setup. See you in the next post!

Guide: How to Mask Sensitive Information Using Fluent Bit

Master — Wed, 14 Jun 2023 03:00:00 +0000

Fluent Bit is a popular open-source log processor and forwarder that allows you to collect data from different sources, filter, and transform it before forwarding it to different destinations. In some cases, the data collected may contain sensitive information like passwords, credit card numbers, social security numbers, and other personal identifiable information (PII). To protect such information, you need to mask or obfuscate it before forwarding it to the destination. In this document, we will discuss how to mask sensitive information using Fluent Bit.

The goal of this guide is convert structured logs that contain PII information like (mobile numbers, identity information, name etc…)

{"timestamp":"2023-06-05T17:04:33.505+05:30","requestURI":"/api/user","message":"Sending SMS to mobileNumber=1234512345 registered on aadhaarNumber=1234512345"}
to a format where this information is masked.
{"@timestamp":"2023-06-05T17:04:33.505+05:30","requestURI":"/api/user","message":"Sending SMS to mobileNumber=******** registered on aadhaarNumber=********"}

Prerequisites & Constraints

This guides assumes the following

Docker is installed on your machine
You have knowledge of fluent-bit concepts like inputs, outputs, parsers, filters etc..
We will be constraining our selves to not introduce any 3rd party service other than fluent-bit.

Let’s start with an initial configuration on your machine that reproduce the behavior where sensitive information is not masked yet.

Create an empty directory on your computer & save the below fluent-bit configuration in a file name fluent-bit.conf.

[INPUT]
    Name   dummy
    dummy  {"@timestamp":"2023-06-05T17:04:33.505+05:30","message":"Staring server on port 8080"}
    Tag    dummy.log

[INPUT]
    Name   dummy
    dummy  {"@timestamp":"2023-06-05T17:04:33.505+05:30","requestURI":"/api/user","message":"Sending SMS to mobileNumber=1234512345, registered on aadhaarNumber=1234512345"}
    Tag    dummy.log

[INPUT]
    Name   dummy
    dummy  {"@timestamp":"2023-06-05T17:04:33.505+05:30","requestURI":"/api/bank","message":"Successfully registered mobileNumber=1234512345, to panNumber=1234512345"}
    Tag    dummy.log

[OUTPUT]
    Name   stdout
    Match  *

Now run the below command from the same directory to start the fluent-bit process in a docker container.

docker run \
  -v $(pwd)/fluent-bit.conf:/fluent-bit/etc/fluent-bit.conf \
  -ti cr.fluentbit.io/fluent/fluent-bit:2.0 \
  /fluent-bit/bin/fluent-bit \
  -c /fluent-bit/etc/fluent-bit.conf

After running the command, the expected output should look like this 👇

As you can see mobileNumber & aadhaarNumber are clearly visible in the application logs. Let’s start masking this information.

The problem of masking PII information can be logically solved by search & replace operation. Where we first search the required information from logs, once found we apply replace operation where the value of replace can be as simple as replacing with ******** or hashing the value.

In Fluent-Bit, the above mentioned operations can be performed at the Filter stage. Now, let’s select the right plugin for this stage.

Selecting the Right Fluent-Bit Plugin

Out of the box fluent-bit provides Nightfall plugin, which interacts with a 3rd party component called Nightfall to process the PII information. We won’t be using Nightfall plugin as we don’t want to introduce any 3rd party component in our system.

Search & Replace can be performed by these 3 filter plugins:

Record Modifier: This plugin gives us the ability to modify our structured logs by replacing entire key, values with something else. But does not allow replacing a small part of the value. For example, take the below structured log {"timestamp":"2023-06-05T17:04:33.505+05:30","requestURI":"/api/user","message":"Sending SMS to mobileNumber=1234512345 registered on aadhaarNumber=1234512345"} in our case the message field of type string has mobileNumber in it. We just want to replace this value. But this filter can only replace the entire message content. So, we won’t using this filter plugin
Modify: This has the same drawback as Record Modifier plugin. So, we won’t using this filter plugin
Lua: This filter allows you to modify the incoming records using custom Lua scripts. This helps us to extend Fluent Bit capabilities by writing custom filters using Lua programming language. We can use this to write custom Lua script to perform search & replace operation for us.

Writing the Lua Script

Create a file called mask.lua in the same directory where fluent-bit.conf exists. Copy the below content inside mask.lua file.

function mask_sensitive_info(tag, timestamp, record)
    message = record["message"]
    if message then
        -- Match "aadhaarNumber:xxxx," and replace with "aadhaarNumber:****,"
        local masked_message = string.gsub(message, 'aadhaarNumber=[^,]*', 'aadhaarNumber=****')

        -- Match "mobileNumber:xxxx," and replace with "mobileNumber:****,"
        masked_message = string.gsub(masked_message, 'mobileNumber=[^,]*', 'mobileNumber=****')

        record["message"] = masked_message
    end
    return 2, timestamp, record
end

Here's a breakdown of what this Lua function does:

function mask_sensitive_info(tag, timestamp, record): This line defines a new Lua function named mask_sensitive_info. This function takes three parameters: tag, timestamp, and record.
message = record["message"]: This line retrieves the value of the "message" field from the record parameter and assigns it to a local variable named message.
if message then: This line starts an if statement that only executes the enclosed block of code if message is not nil or false.
local masked_message = string.gsub(message, 'aadhaarNumber[^,]*', 'aadhaarNumber:****'): This line creates a new local variable named masked_message. It assigns to this variable the result of calling the string.gsub function on message. The string.gsub function is used to replace all occurrences of the pattern 'aadhaarNumber[^,]' (which matches the string "aadhaarNumber" followed by any sequence of characters that are not a comma) with the string 'aadhaarNumber:**'.
masked_message = string.gsub(masked_message, 'mobileNumber[^,]*', 'mobileNumber:****'): This line reassigns masked_message with the result of another call to string.gsub, this time replacing all occurrences of the pattern 'mobileNumber[^,]' (which matches the string "mobileNumber" followed by any sequence of characters that are not a comma) with the string 'mobileNumber:**'.
record["message"] = masked_message: This line updates the "message" field of record with the value of masked_message, which at this point should have all sensitive data replaced with asterisks.
end: This line closes the if statement.
return 2, timestamp, record: This line specifies what the function should return when called. In this case, it returns three values: the number 2, the value of timestamp, and the updated record.
end: This line closes the function definition.

So, the overall purpose of this function is to replace any sensitive data (like Aadhaar numbers and mobile numbers) in the "message" field of a record with asterisks, for privacy reasons.

Using the Lua Script In Lua Plugin

To enable the lua plugin, you need to add it to the Fluent Bit configuration file. Below is an example of how to configure the lua pugin to mask the PII field in the log data.

[INPUT]
    Name   dummy
    dummy  {"@timestamp":"2023-06-05T17:04:33.505+05:30","message":"Staring server on port 8080"}
    Tag    dummy.log

[INPUT]
    Name   dummy
    dummy  {"@timestamp":"2023-06-05T17:04:33.505+05:30","requestURI":"/api/user","message":"Sending SMS to mobileNumber=1234512345, registered on aadhaarNumber=1234512345"}
    Tag    dummy.log

[INPUT]
    Name   dummy
    dummy  {"@timestamp":"2023-06-05T17:04:33.505+05:30","requestURI":"/api/bank","message":"Successfully registered mobileNumber=1234512345, to panNumber=1234512345"}
    Tag    dummy.log

[FILTER]
    Name    lua
    Match   *
    call    mask_sensitive_info
    script  /fluent-bit/scripts/mask.lua

[OUTPUT]
    Name   stdout
    Match  *

In the above configuration, we have added the lua plugin in the filter state. We set the Match parameter to * to match all incoming log data. We then specify the script parameter to /fluent-bit/scripts/mask.lua which specifies the path to the lua script file . We also set the call parameter to mask_sensitive_info to specify the function name which has to be loaded from the lua script file.

Testing

To test the above configuration, run below command

docker run \
  -v $(pwd)/fluent-bit.conf:/fluent-bit/etc/fluent-bit.conf \
  -v $(pwd)/mask.lua:/fluent-bit/scripts/mask.lua \
  -ti cr.fluentbit.io/fluent/fluent-bit:2.0 \
  /fluent-bit/bin/fluent-bit \
  -c /fluent-bit/etc/fluent-bit.conf

The expected output should contain masked valued like this 👇

Conclusion

Masking sensitive information is an important security measure that helps protect personal identifiable information from unauthorized access or disclosure. Fluent Bit provides a simple and effective way of masking sensitive information using the lua filter plugin. By configuring the plugin to mask specific fields or patterns in the log data, you can ensure that no sensitive information is leaked to external systems or logs.

Kubernetes Services Explained: Cluster IP, NodePort, Loadbalancer, Ingress, Ingress Controllers

Master — Sat, 09 Jul 2022 09:33:04 +0000

Introduction

Kubernetes networking principles are really confusing 😖, especially if you're a beginner.

Regardless of how well I follow the official documentation. I honestly didn’t understand a single damn thing !!!

After watching some tutorials on Youtbube I was able to write & duplicate the tutorials, but core understanding of Kubernetes networking concepts was still missing, as sometimes I myself used to get confused about what to use where...

This blog post is my take to explain kubernetes networking concepts in depth & answer the below questions that I had that always confused me...

How Kubernetes networking resource solves Service Discovery problem in Kubernetes?
Does a Load Balancer Service really provisions a Load Balancer automatically? What will happen if I create this service locally?
How does a production ready Kubernetes cluster expose it’s applications?
What is the difference between Ingress & Ingress Controller?
and more...

Let’s Get Started

Throughout the entire blog post, we will assume the following.

You have familiarity with the structure of Kubernetes YAML resource definition
You have deployed an imaginary Kubernetes cluster on the cloud across 3 VMs, the VMs/nodes have the following Public IP addresses
- Node A (192.168.0.1)
- Node B (192.168.0.2)
- Node C (192.168.0.3)
A microservices application having 4 services is deployed on that K8s cluster. the application is deployed in such a way that each VM has at least 1 replica of that service running
- Products
- Reviews
- Details
- Ratings
Notations
- $Reviews_A$ denotes that the Reviews service is running on node A
- K8s denotes Kubernetes
- LBs denotes Load Balancers

Kubernetes Cluster

Let's start with answering the why

🤔 Why do we need services in the first place?

In the K8s cluster, our application code is running inside containers using the K8s Deployment resource. This deployment resource internally creates a K8s Pod resource which in turn actually runs the containers.

K8s assigns an IP address whenever a pod is created. The command below shows you an example IP address of the Pod

kubectl get pods <pod-name> -o wide

Example Pod IP

In our application, $Products_A$ Pod can use the IP address assigned to $Reviews_A$ Pod for communication. Well this technique works..., but it's not an elegant solution the reason being K8s pods are short-lived/ephemeral.

So if a pod dies for any reason, K8s will automatically restart the Pod, but the IP address assigned to that pod also changes. This in turn will lead to communication failure between the $Products_A$ & $Reviews_A$ micro-service as the IP address of $Reviews_A$ service is hardcoded in the configuration file of $Products_A$ service. This is problematic !!!

Wouldn’t it be great if somehow a static IP address or a DNS name gets assigned to the Pod? This will solve our above problem.

That’s where the Service resource of K8s comes to the rescue. I know the name Service sounds deceiving. A Service **resource doesn't run our containers. **It merely provides and maintains a network identity for our Pod resource.

This Service network identity provides both a static IP address & a DNS name, we just need to specify the ports on which the incoming request will be received & the port of the pod on which the request has to be sent.

Services listen on a static address that doesn't change & forwards the request to the unreliable container address. The way it works is that internally it keeps a map that always contains the latest IP address of the Pod. so whenever a Pod restarts it updates that map automatically so you get a seamless connection.

Another benefit of using services is load balancing between replicas of the same application, With our imaginary application as there are 3 instances of each micro-service running on separate VMs, A service will load balance the request between the replicas of $Products_A$ $Proudcts_B$ $Products_C$.

Load Balancing between Pods in K8s using Service Resource

Till now we have understood what are services & why are they needed, Let's check out the different services that K8s offers with their use cases

🤔 How do I make $Products_A$ service talk to $Reviews_A$ service?

ClusterIP Service to the rescue

The following YAML defines a service of type ClusterIP

apiVersion: v1
kind: Service
metadata:
  labels:
    app: reviews
  name: reviews
spec:
  ports:
  - name: http
    port: 5000
    protocol: TCP
    targetPort: 80
  selector:
    app: reviews
  type: ClusterIP

The important fields in these YAML are

targetPort: denotes the container port on which the request has to be forwarded

port: denotes the port on which the service accepts incoming requests

selector: This field is used for associating/attaching a K8s Service resource to a K8s Pod resource, this is done by matching labels (key-value pairs) of the pod with selectors labels specified in the selector section.

📌 Selectors labels defined in the service performs AND operation for attaching a service to a pod, meaning all the labels must match for attachment to be done

The command below shows you the static IP address of the service which can be used by other Pods

kubectl get service <service-name>

You can use the above IP address for communication between $Products_A$ & $Reviews_A$ micro-service

To communicate using DNS, there are 2 ways

Pods residing in the same K8s Namespace can use the name of the service for DNS resolution'
- Example → http://reviews:5000
Pods residing in other namespaces can use the following DNS notation → <service-name>.<namespace>.svc.cluster.local
- Let's say $Products$ Pod resides in products namespaces & $Reviews$ pod resides in reviews namespace, then for $Products$ pod to communicate with $Reviews$ pod you would use the following DNS → http://reviews.reviews.svc.cluster.local:5000

Now you can pass these addresses to your microservice for communication.

Internal Communication Using Cluster IP Service

Till now we understood how applications inside the K8s cluster talk to each other, but you made your application to be consumed by users on the internet. Let’s check out how it is done.

🤔 How do I expose $Products_A$ service over the internet?

Every application that is deployed in K8s by default cannot be accessed over the network/internet, they need to be exposed Via a Services. K8s provides 2 Services to do just that

NodePort Service

The following YAML can be used to create a service of type NodePort

apiVersion: v1
kind: Service
metadata:
  labels:
    app: reviews
  name: reviews
spec:
  ports:
  - name: http
    port: 5000
    protocol: TCP
    targetPort: 80
  selector:
    app: reviews
  type: NodePort

The above YAML definition is very similar to the ClusterIP Service definition, the only field that has changed is the type field from ClusterIP to NodePort. When you create a NodePort service, K8s will randomly select any available port on the node/VM between 30000 - 32767 and listen on it for incoming requests.

📌 You can specify the nodeport field yourself in the service definition, but you have to deal with hassle checking if the port is available on every node

After creating the service, To get the port on which this NodePort service is listening for requests use the below command

kubectl get service <service-name>

In our imaginary K8s cluster, this will happen on all the nodes

Node A (192.168.0.1:30519)
Node B (192.168.0.2:30519)
Node C (192.168.0.3:30519)

You can access your application using the address nodeIP:30519, for Node A it would be 192.168.0.1:30519.

Exposing Application Using Nodeport Service

But this is not practical, users of your application won’t remember your IP address & port for accessing your app. They need a domain name like myapp.com to access your app. We solve this by putting an external load balancer in front of our VMs. The load balancers public IP is mapped to myapp.com. So when you type myapp.com on the browser it resolves to load balancer Ip, Then the load balancer forwards these requests to any of our 3 nodes according algorithm configured in load balancer.

K8s provides another service to expose your application, it is called the Load Balancer service.

Load Balancer

Following Yaml can be used a create a service of type Load Balancer

apiVersion: v1
kind: Service
metadata:
  labels:
    app: reviews
  name: reviews
spec:
  ports:
  - name: http
    port: 5000
    protocol: TCP
    targetPort: 80
  selector:
    app: reviews
  type: LoadBalancer

The above YAML definition is very similar to the ClusterIP Service definition, the only field that has changed is the type field from ClusterIP to LoadBalancer.

Load Balancer service is an abstraction over the NodePort service, What’s special about this service is that If you are using a managed Kubernetes service like EKS(AWS), GKS(GCP), AKS(Azure) or any other cloud provider, it provisions a load balancer by itself so that you don’t have to hassle setting up a load balancer yourself.

After creating the service, To get the public IP address of the load balancer provisioned by this service use the below command

kubectl get service <service-name>

Load Balancer Service Example

But what happens if you create a LoadBalancer service on your local K8s cluster or configured your own K8s from scratch on the cloud?

The answer is it won’t do anything, you will see a state for the IP address section. The reason is cloud-specific K8s clusters add other special programs/controllers which detects the Load Balancer service creation and takes the appropriate action accordingly.

One thing to note here, Loadbalancer service doesn’t expose any ports by itself like the NodePort service

LoadBalancer is a superset of NodePort is a superset of clusterIP service, which means when you create a service of type Nodeport a ClusterIP service also gets created implicitly. So if you create a NodePort service for $Products$ microservice, then this same service can be used for both internal communications by other pods & accessing the $Products$ service on the internet.

Service Superset

🤔 What should we use NodePort or LoadBalancer service?

If you read carefully, you will observe there is not much difference between the NodePort & LoadBalancer service. Except for some automation being done in the latter one.

Using a Load Balancer service takes away the trivial task of configuring & provisioning LBs. Whereas using a NodePort gives you the freedom to set up your own load-balancing solution, such that to configure environments that are not fully supported by Kubernetes, or even to expose one or more nodes' IPs directly.

So it depends upon the situation you are in, but the general rule of thumb is to try to use LoadBalancer service first if it doesn’t work for your environment go for NodePort service

That is it, these two services are used to expose your application outside of the cluster. But there is a slight problem.

If you want to expose more than one application, you end up creating multiple NodePort / LoadBalancer Services. This gets the job done but you have to face some consequences because with each NodePort service you need to deal with the hassle of manually managing the IPs & ports. And with each LoadBalancer service, you go on increasing your cloud bill.

No worries 😟, K8s has addressed this issue with the use of Ingress & Ingress controllers.

🤔 How to expose multiple applications without creating multiple services

Ingress & Ingress controller

Ingress & Ingress controller are two different things, people usually get confused with these terms

An Ingress controller is just another K8s Deployment resource (an app running in a container), but what is special about this deployment is that it provides a single point of control for all incoming traffic into the Kubernetes cluster

Think of Ingress controller as a smart proxy running in K8s & Ingress is a K8s resource that configures the routing logic of Ingress controller.

💡 Analogy, For people who have worked with Nginx (Nginx the webserver will be your Ingress controller, the nginx.conf file will be your Ingress resource)

With these, you can specify what request needs to be routed to which service in your k8s cluster on the basis of any request parameter like host, URL path, sub domain etc...

Following Yaml can be used to create Ingress resource

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-wildcard-host
spec:
    ingressClassName: nginx
  rules:
  - host: "products.myapp.com"
    http:
      paths:
      - pathType: Prefix
        path: "/products"
        backend:
          service:
            name: products-app
            port:
              number: 80
  - host: "ratings.foo.com"
    http:
      paths:
      - pathType: Prefix
        path: "/ratings"
        backend:
          service:
            name: ratings-app
            port:
              number: 80

With the above YAML, we have exposed two services, if a request comes from products.myapp.com and the request path starts with /proudcts we send it to our products-app K8s Service which in turn forwards the request to our container.

Similarly, if a request comes from ratings.bar.com it is forwarded to ratings-app

Ingress YAML Explaination

The important fields in these YAML are

ingressClassName: Usually there is only one ingress controller in the cluster, but no one has stopped you from creating many. So this field is used for the selection of ingress controller, similar to the selector field of services

service: denotes the name of service on which the request has to be forwarded

An ingress resource should be created in the same namespace where the corresponding K8s Service resides, But an ingress controller can be placed in any namespace, it will automatically detect Ingresess defined in other namespaces on the basis of ingressClassName.

An important thing to remember an Ingress by itself doesn’t expose any port. In the end, it's just a K8s deployment resource. You need a service(NodePort/LoadBalancer) in front of it to expose it.

Exposing Application Using Load Balancer Service

Conclustion

Congratulation for sticking to the end, Let’s summarize what we have learned so far.
Kubernetes gives us 3 types of Service Resource Object

Cluster IP Service→
- Used for internal communication amoung workloads & solves Service Discovery.
Nodeport Service →
- Used for exposing applications over the internet, mostly used in development environments
Load Balancer Service →
- Used for exposing applications over the internet
- Provision actual load balancer on the cloud, on supported cloud platforms
Ingress Resource →
- Used for controlling incoming traffic in the Kubernetes cluster
- Various implementations are available each with it’s pros & cons

That’s it in this blog post, If you liked this blog post. You can also checkout my YouTube channel where we talk about M*icroservices, Cloud & Kubernetes,* you can check it out here 👉link

If you have any questions you can reach me on Twitter at @SharadRegoti