DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Last call! Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • How Kubernetes Cluster Sizing Affects Performance and Cost Efficiency in Cloud Deployments
  • The Production-Ready Kubernetes Service Checklist
  • 10 Best Practices for Managing Kubernetes at Scale
  • Optimizing Prometheus Queries With PromQL

Trending

  • Docker Model Runner: Streamlining AI Deployment for Developers
  • Contextual AI Integration for Agile Product Teams
  • Operational Principles, Architecture, Benefits, and Limitations of Artificial Intelligence Large Language Models
  • Building Resilient Identity Systems: Lessons from Securing Billions of Authentication Requests
  1. DZone
  2. Software Design and Architecture
  3. Cloud Architecture
  4. Routing External Traffic Into Your Kubernetes Services

Routing External Traffic Into Your Kubernetes Services

If you are looking to route some stuff through your Kubernetes services, you have a few choices to make.

By 
Madeesha Fernando user avatar
Madeesha Fernando
·
Updated Jun. 17, 19 · Tutorial
Likes (8)
Comment
Save
Tweet
Share
16.5K Views

Join the DZone community and get the full member experience.

Join For Free

Image title


There are several methods to route internet traffic to your Kubernetes cluster. However, when choosing the right approach, we need to consider some factors such as cost, security, and maintainability. This article guides you to choose a better approach to route the external traffic to your Kubernetes cluster by considering the above facts.

Image title

Before routing external traffic, let’s get some knowledge on the routing mechanism inside the cluster. In Kubernetes, all the applications are running inside a pod. A pod is a container which gives more advantages over static instances.

To access an application running inside a pod, there should be a dedicated service for it. The mapping between the service and pod is determined by a "label selector" mechanism. Below is a sample yaml which can be used to create a Hello World application. There you can get a clear idea about the label selector mapping.


---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: helloworld-deployment
  labels:
    app: helloworld
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: helloworld
    spec:
      containers:
      - name: helloworld
        image: dockercloud/hello-world
        ports:
        - containerPort: 80


Let’s see how can we create a Kubernetes service for the above Hello World application. In this example, I have used theapp=helloworld label to define my application. Now you need to use this "helloworld" label as the selector of your service. Then only your service identifies which pods to be looked after by the service. Below is the sample service corresponding to the above application,

apiVersion: v1
kind: Service
metadata:
  name: "service-helloworld"
spec:
  selector:
    app: helloworld
  type: ClusterIP
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80


This specification will create a new Service named “service-helloworld” which targets TCP port 8080 on any Pod with the "app=helloworld" label.

Here you can see the service type is “ClusterIP.” It is the default type of a Kubernetes service. Other than this, there are another two types of services called “NodePort” and “LoadBalancer.” The mechanism of routing traffic to a Kuberntes cluster will depend on the service type you used when defining a service. Let’s dig into more details.

  1. LoadBalancer: Exposes the service externally using a cloud provider’s load balancer. In AWS, it will create an ELB for each service which exposes the type as the “LoadBalancer.” Then you can access the service using the dedicated DNS name of the ELB.
  2. NodePort: Exposes the service on each Node’s IP at a static port. You can connect to the NodePort service outside the cluster by requesting <NodeIP>:<NodePort>. This is a fixed port to a service and it is in the range of 30000–32767.
  3. ClusterIP: The ClusterIP service is the default Kubernetes service. Exposes the service on a cluster-internal IP. Choosing this value makes the service only reachable from within the cluster. But to expose these services to the outside, you need an ingress controller inside your cluster.


Image title

By considering these services types, the easiest way of exposing a service outside the cluster is using the “LoadBalancer” service type. But these cloud load balancers cost money and every Loadbalancer Kubernetes service creates a separate cloud load balancer by default. Therefore, this service type is very expensive. Can you bear the cost of a deployment which creates a separate ELB (if the cluster is in AWS) for every single service you create inside the Kubernetes cluster?

Image title

The next choice we have is the "NodePort" service type. But choosing the NodePort as the service type has some disadvantages due to several drawbacks. Because by the design it bypasses almost all the network security provided by the Kubernetes cluster, it allocates a port from a range 30000–32767 dynamically. Therefore, standard ports such as 80, 443 or 8443 are cannot be used. Because of this dynamic allocation, you do not know the assigned port in advance, and you need to examine the allocated port after creating the service and on most hosts, you need to open the relevant port in firewall after the service creation.

Image title

The final and the most recommended approach to routing traffic to your Kubernentes service is "ClusterIP" service type. The one and only drawback of using ClusterIP is that you cannot call the services from the outside of the cluster without using a proxy. because by default, ClusterIP is only accessible by the services inside its own Kubernetes cluster. Let’s talk about how we can get the help of Kubernetes ingress controller to expose ClusterIP services to outside the network.

The following diagram illustrates the basic architecture of the traffic flow to your ClusterIP services through the Kubernetes ingress controller.

Image title

If you have multiple services deployed in Kubernetes cluster, I recommended the above approach due to several advantages.

  • Ingress enables you to configure rules that control the routing of external traffic to the services.
  • You can handle SSL/TLS termination at the Nginx Ingress Controller level.
  • You can get the support for URI rewrites.

When you need to provide external access to your Kubernetes services, you need to create an Ingress resource that defines the connectivity rules, including the URI path and backing service name. The Ingress controller then automatically configures a frontend load balancer to implement the Ingress rules.

Kubernetes cluster

Opinions expressed by DZone contributors are their own.

Related

  • How Kubernetes Cluster Sizing Affects Performance and Cost Efficiency in Cloud Deployments
  • The Production-Ready Kubernetes Service Checklist
  • 10 Best Practices for Managing Kubernetes at Scale
  • Optimizing Prometheus Queries With PromQL

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!