Kubernetes
Ingress
Service
externalIPs
Networking

Kubernetes Ingress vs. Service with externalIPs

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

Introduction

In the landscape of container orchestration and management, Kubernetes stands out as a powerful and flexible system. However, when it comes to exposing your applications to the outside world, especially services running inside the Kubernetes environment, a clear understanding of Ingress vs. Service with externalIPs is vital. Both concepts serve to manage the network traffic to and from your Kubernetes environment but are suited for different scenarios. This article aims to explain the distinct roles and use-cases of both Ingress and Services with externalIPs .

Kubernetes Service with externalIPs

What is a Service?

In Kubernetes, a Service is an abstraction that defines a logical set of Pods and a policy by which to access them, usually referred to as microservices. Services of type ClusterIP , NodePort , LoadBalancer , and others enable different ways of accessing applications inside the cluster.

What is an externalIP?

The externalIP field is an additional way to make your services accessible outside the Kubernetes cluster without requiring a load balancer or ingress controller. It involves assigning an external IP address to a service, such that traffic can be routed from this IP to the service in your cluster.

How it Works

When a Kubernetes Service is configured with an externalIP , it essentially maps the external IP to the service's internal IP. Nodes in the cluster will route incoming traffic for the externalIP to the correct Pods.

Example YAML configuration for a Service with externalIP :

  • protocol: TCP
  • 192.0.2.24
  • Simple Setup: For simple applications or testing environments where you only need to expose a service quickly.
  • Limited Scope: In environments where using full-fledged load balancers is overkill or impossible due to cost or policy restrictions.
  • Direct Access Required: When direct access to specific services is needed without the complexities of routing and path management.
    • host: example.com
      • path: /foo
      • path: /bar
  • Complex Routing: Offers sophisticated routing and load balancing such as URL rewrites and redirects.
  • TLS Termination: Handle HTTPS requests with integrated TLS/SSL certificate management.
  • Name-based Virtual Hosting: Can route traffic to different services based on the requested hostname.
  • Web Applications: Best suited for scenarios requiring sophisticated request-routing based on URL paths or hostnames.
  • Security and Scalability: When scalable, secure, and easily manageable traffic control is needed, such as in production environments.
  • Centralizing Access: It simplifies access management by centralizing traffic entry to the entire Kubernetes cluster.
  • Ingress Controllers: When using Ingress, you'll need an ingress controller - a component that actually interprets and processes Ingress rules.
  • Performance: Both solutions offer performance optimizations, but Ingress can provide more advanced qualities of service.
  • Security Considerations: Ingress can handle TLS termination, offering better integration with HTTPS security practices.

Related reading
Course
Beginner
27 lessons
10 hours
System Design Fundamentals

Build a strong foundation in designing scalable, reliable distributed systems.

View the course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

All Rights Reserved.