Search for a command to run...
DevOps Engineer working on Cloud Automation, CI/CD, and Monitoring. Day by Day Improving Cloud SkillSets and storing Hard coded Memories in the bucket. Passionate to Work Around Cloud, AWS, GCP, Jenkins, Docker, Kubernetes and Ansible.
No comments yet. Be the first to comment.
Managing AWS EKS clusters provides excellent scalability and reliability for running containerized applications. However, without careful cost monitoring, expenses can quickly add up. This article breaks down practical strategies to help you reduce A...
Amazon Web Services (AWS) comes to mind when you think about cloud computing. AWS takes care of all the scenarios of how we deploy and manage applications, offering flexibility, scalability, and reliability. But what makes AWS so powerful? It’s all i...
· Understanding CORS Errors:∘ Access-Control-Allow-Origin:∘ Preflight CORS request failed:· Causes of CORS Errors:· Resolving CORS Errors:∘ Identify the cause:∘ Configure CORS headers:∘ Check origin matching:∘ Secure SSL certificates:∘ Test and monit...
Understanding the Linux Directory Structure is like having a map to guide you through the core of your computer’s operating system. In this journey, we’re going to break down the directories, revealing their secrets, and helping you make sense of how...
Today, we will guide you through one of the essential aspects: Kubernetes Services and Ingress.
Kubernetes Services, which allows network access to Pods managed within deployments. We’ll explore the various Kubernetes Services types and touch upon Kubernetes Ingress.
Unlike a service, Ingress isn’t a service but offers an alternative method for directing traffic to your services and cluster.
we will go through all services and ingress and provide examples of deploying an application both without using Ingress and with using Ingress to help everyone understand the differences and benefits of Ingress.
Kubernetes Services act like traffic managers within your cluster, directing requests to the right destinations.
In Kubernetes, a service serves as a stable access point for pods offering the same functionality. Think of it as a consistent address and port combination that remains unchanged as long as the service runs.
The service automatically routes incoming connections to one of the pods, even if the pod’s location changes within the cluster.
This simplifies management, as pods can be moved or scaled without disrupting client access. Kubernetes services support load balancing, ensuring efficient distribution of client requests among the available pods.
Kubernetes Services are endpoints or interfaces of pods (or groups of pods) that perform the same function. In simple terms, they act as gates, but only as entrances.
Creating a service is like creating a gate for traffic from outside to easily communicate with the pod that owns the gate.
There are a few types of Kubernetes Services, each serving a different purpose. Whether it’s ClusterIP for internal communication or NodePort/LoadBalancer for external access, there’s a service for every need.
Suitable for exposing services only internally, such as databases, caches, or message queues (no one outside can talk to them).
When we create ClusterIPa service, Kubernetes creates a virtual IP for that service by pulling the IP from the reserved pool, allowing pods or other services within the cluster to access the service through that IP.
Suitable for exposing services for testing or debugging during app development.
When we create NodePorta service, Kubernetes reserves one port on every node in the cluster (usually port 30000–32767), and traffic sent via node IP + port is forwarded to that service. It can be the IP of any node.
such as
[Node1] IP XXXX Port 8080 will forward to Apache Server.
[Node2] IP YYYY Port 3000 will be forwarded to Nodejs backend as well.
[Node1] IP XXXX Port 3001 will be forwarded to the product Server.
When we create LoadBalancera service, Kubernetes creates the actual load balancer outside of the cluster (if using the cloud, it is created on the cloud platform), allowing external users to access our service through the load balancer IP.
LoadBalancerservice is suitable for use to expose services in production that require access from outside Kubernetes or from the public internet, such as a simple web app that is not complicated.
In fact, Kubernetes also has another type of service that may not be talked about in general.ExternalNamewhich I would like not to go into details about. Let's just say it uses a map service to the DNS name (redirection) and doesn't do load balancing in any way.
Picture a busy highway road with cars and trucks around the road. Kubernetes Services ensure that each car (or pod) reaches its destination safely, without crashing into others.
Kubernetes Services are handy in various scenarios, from microservices architectures to monolithic applications. They keep everything connected and running smoothly behind the scenes.
Suppose I have an infiq app that consists of 4 parts:
Frontend
Admin Panel
Backend
PostgreSQL Database
If I want to deploy this app with Kubernetes services, I might choose the following service:
Frontend service is used LoadBalancerbecause users from outside will call in.
Admin service is used LoadBalancerbecause users from outside(Other Team) will call in.
Backend service is used LoadBalancerbecause users from outside will call into the backend service.
Database service is used ClusterIPbecause it is called from an internal service itself.
And I need to create a record from an external DNS like this.
infiq.tech Points to the load balancer IP of the frontend service.
admin.infiq.tech Points to the load balancer IP of the Admin service.
backend.infiq.tech Points to the load balancer IP of the Backend service.
It works fine, but the problem is…
Wasteful: to run this application in production I have to pay for 3 load balancers.
Complicated: we must must manage 3 DNS records
There are limitations: URL path routing cannot be done. Must use a subdomain instead. For example:- infiq.tech/profilecannot be used → must be used with their subdomains.
(Maybe) Chaotic: If the load balancer IP changes, you have to change the DNS record (except on the cloud where we usually point DNS to the load balancer DNS name).
Actually, regarding URL path routing, we can deploy a proxy to do the same. It reduces the hassle of DNS records as well, but it has to take care of the proxy and still wastes load balancer fees.
And let’s try to see what Kubernetes Ingress can help us with.
Think of Kubernetes Ingress as the gatekeeper to your cluster. It manages incoming traffic, allowing external users to access your applications securely.
Ingress works its magic by routing requests based on rules you define. It’s like having a personal concierge who ensures that each visitor gets to their desired destination without getting lost.
Kubernetes Ingress is a traffic controller in a Kubernetes cluster that is inserted in front of other services. It receives traffic from the load balancer and sends traffic to various services according to routing rules.
To use Ingress, there must be 2 parts:
Ingress Controller, for which we need to deploy a controller (such as NGINX, alb-controller, Traefik, etc.) first to work as a proxy for us.
Ingress Resource is to configure the controller to work as we want. This one is a Kubernetes resource like pods or deployments.
we will change all 3 services (frontend, admin, backend) from LoadBalancerto ClusterIPall because I will use only one load balancer of ingress to expose outside the cluster.
and DNS will have only 1 record left pointing to the load balancer IP of the ingress.
And this is what I got after bringing ingress to this Application.
From having to use 3 load balancers, there is only 1 left.
Manage a single DNS record pointing to ingress.
Can do routing from URL path such as
- infiq.tech→ frontend service
- admin.infiq.tech/users→ Admin service
- infiq.tech/profile→ Frontend service with path-based routes
Configuration regarding URL routing or TLS can be done in ingress and stored as code (Kubernetes manifest) with other manifests in one place.
Services focus on internal communication, while Ingress handles external access. It’s like comparing an internal phone system (Services) to a reception desk (Ingress) that welcomes external visitors.
Deciding between Services and Ingress depends on your application’s needs. If you’re dealing with internal communication, go for Services. For external access, Ingress is your go-to.
Services handle internal communication within your cluster, while Ingress manages external access to your services.
Absolutely! Services and Ingress complement each other, working together to ensure seamless communication both inside and outside your cluster.
Consider your application’s needs. If you’re dealing with internal communication between pods, go for Services. If you need to manage external access, Ingress is your go-to.
When configured properly, the performance impact of Ingress is minimal. However, inefficient routing or misconfiguration can lead to performance issues.
Kubernetes is designed to handle complex deployments seamlessly. By carefully configuring your Services and Ingress resources, you can ensure smooth traffic routing and management in even the most intricate setups.
Thank you so much for Reading the Article till the End! 🙌🏻 Your time and interest truly mean a lot 😁📃.
If you have any questions or thoughts about this blog, feel free to connect with me:
LinkedIn: https://www.linkedin.com/in/ravikyada
Twitter: https://twitter.com/ravijkyada
Until next time, Cheers to more learning and discovery✌🏻!
Kubernetes Services vs. Ingress: A Beginner’s Guide was originally published in InfiQ Technologies on Medium, where people are continuing the conversation by highlighting and responding to this story.