Objective: Discuss the differences between Kubernetes Ingress and OpenShift Router
Prerequisite: Understanding of Kubernetes and OpenShift Background: Kubernetes Ingress and OpenShift Route can expose services (Service) through routing, facilitating external access to internal cluster resources while also providing load balancing.
Kubernetes Ingress Overview:
Kubernetes Ingress is a Kubernetes resource used to manage and configure how external traffic is directed to internal services in the cluster. It acts as an entry point between the cluster and the external network, allowing for easy management of traffic routing and load balancing. Ingress provides a standardized way to define routing rules for applications, including hostname and path matching, to route requests to different backend services based on various rules. For more details, please refer to the Kubernetes documentation.
OpenShift Route
OpenShift Route is a key feature of the OpenShift container platform used to manage external access to applications. It provides integrated security, load balancing, domain routing, and TLS authentication, among other functions. By configuring a Route, external traffic can be directed to applications within the cluster, achieving robust traffic control and security while simplifying the exposure and management of applications. Route fully utilizes OpenShift’s ecosystem, supporting features like OAuth and role-based access, making it a critical tool for easily managing application access in container orchestration environments. For more details, please refer to the OpenShift official website.
Working Principle
Kubernetes Ingress Working Principle
-
Ingress Resource Creation:
First, create a Kubernetes Ingress resource.
This resource defines how to direct external traffic to internal services in the cluster.
-
Ingress Controller:
One or more Ingress Controllers run in the Kubernetes cluster, which are the components that actually handle the Ingress configuration.
-
Ingress Routing Rules:
The Ingress Controller parses the routing rules defined in the Ingress resource, including hostname and path matching.
-
Load Balancing and Routing:
The Ingress Controller uses load balancing mechanisms to route incoming requests to the corresponding backend services (Pods).
This involves hostname and path matching in the Ingress configuration.
-
SSL Authentication:
The Ingress Controller can implement SSL/TLS authentication to protect the data in transit.
-
Advanced Routing and Security:
Some Ingress Controllers offer advanced routing policies and security features, such as label-based service selection, authentication, and authorization.
OpenShift Route Working Principle
-
Route Object Creation:
First, the OpenShift cluster administrator or developer creates a Route object.
This object defines how to direct external traffic to internal services in the cluster.
-
Routing Rules Configuration:
The Route can configure the hostname (e.g., myapp.example.com) and path rules to determine how incoming requests are matched.
TLS authentication can also be configured to provide encryption.
-
OpenShift Router:
The Router component in the OpenShift cluster is responsible for processing Route configurations.
The Router is the entry point for OpenShift, responsible for receiving incoming traffic.
-
Load Balancing and Routing:
The Router uses load balancing mechanisms to route incoming requests to the corresponding backend services (Pods).
This involves hostname and path matching in the Route configuration.
-
Security:
The Route can integrate OpenShift security features, such as OAuth and role-based access, to ensure that only authorized users or services can access the application.
-
Traffic Management:
The Router supports weight allocation, load balancing strategies, and other advanced traffic management features to enhance performance and availability.
Usage
Kubernetes Ingress
You must have an Ingress controller to satisfy the Ingress requirements. Simply creating an Ingress resource has no effect. You may need to deploy an Ingress controller, such as ingress-nginx. You can choose from many Ingress controllers. Ideally, all Ingress controllers should adhere to the reference specifications. However, in practice, each Ingress controller operates slightly differently. This example uses higress, and for usage not covered here, please refer to the higress official website.
-
Create a Pod
kind: Pod metadata: name: httpd-pod labels: app: httpd spec: containers: - name: httpd-container image: httpd:latest ports: - containerPort: 80 # Create Pod kubectl apply -f httpd-pod.yaml
-
Create a Service
apiVersion: v1
kind: Service
metadata:
name: httpd-service
spec:
selector:
app: httpd
ports:
- protocol: TCP
port: 80
targetPort: 80
kubectl apply -f httpd-service.yaml
Now we have an httpd Pod and a Service, bound together by labels: app: httpd
. 3. Install Ingress Controller
helm upgrade --install ingress-nginx ingress-nginx \
--repo https://kubernetes.github.io/ingress-nginx \
--namespace ingress-nginx --create-namespace
Or
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/cloud/deploy.yaml
-
Create Ingress Configuration
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: httpd-ingress
spec:
rules:
- host: httpd.example.com # Domain
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: httpd-service
port:
number: 80
# Apply Configuration
kubectl apply -f httpd-ingress.yaml
Then, access the URL httpd.example.com from any node to see the httpd welcome message.
OpenShift Route
OpenShift supports two ways to create Route resources, CLI and WEB.
-
First create a Pod and Service, refer to the above Pod and Service for details.
-
Create OpenShift Route Resource Configuration
CLI
apiVersion: route.openshift.io/v1
kind: Route
metadata:
name: httpd-route
spec:
to:
kind: Service
name: httpd-service
weight: 100
port:
targetPort: 80
tls:
termination: edge
wildcardPolicy: None
# Apply Configuration
oc create -f httpd-route.yaml
-
Access on node at http://httpd-route-default.apps.<cluster-name>.<cluster-base-domain>
WEB
In the OpenShift Console, you can easily and directly create Route resources as shown in the image below Fill in the necessary information and access from the node.
Summary
Kubernetes Ingress and OpenShift Route have many similarities as they are both resources used for routing traffic to internal services in a Kubernetes cluster.
-
Routing Traffic to Services:
Whether it is Kubernetes Ingress or OpenShift Route, their primary goal is to route external traffic to internal services (Service) in the cluster.
-
Load Balancing:
Both support load balancing, distributing incoming requests to multiple backend Pods, thereby improving scalability and availability.
-
Hostname and Path Matching:
Kubernetes Ingress and OpenShift Route both support hostname and path matching, routing requests to different services based on different hostnames or URL paths.
-
TLS Support:
Both support TLS authentication, allowing SSL/TLS certificates to be configured in Ingress or Route to encrypt data in transit.
-
Traffic Control:
Kubernetes Ingress and OpenShift Route both support advanced traffic control and policies, such as label-based service selection, authentication, authorization, and traffic redirection.
Despite these similarities, there are some important differences:
-
Ecology:
Kubernetes Ingress is a native resource of Kubernetes, while OpenShift Route is a specific resource of OpenShift.
They are typically used in different container orchestration platforms.
-
Configuration Syntax:
The configuration syntax of Kubernetes Ingress and OpenShift Route is slightly different.
Kubernetes Ingress uses standard Kubernetes YAML format, while OpenShift Route uses OpenShift’s Custom Resource Definitions (CRD).
-
Security Features:
OpenShift Route provides additional security features on the OpenShift platform, such as OAuth and role-based access, to meet the requirements of the OpenShift ecosystem.
In summary, Kubernetes Ingress and OpenShift Route are powerful tools that can be chosen based on specific platforms and needs. Regardless of which tool is chosen, they can help manage and control external access to applications, ensuring that applications run efficiently in cloud-native environments.
Link: https://blog.51cto.com/u_15249701/7935913
Copyright belongs to the original author, please delete if infringing