Networking

Following is high level network flow for Link application

By default, a Service is created with type: ClusterIP, making it reachable only from within the cluster. To expose it externally, you change the type.

apiVersion: v1
kind: Service
metadata:
  name: my-app-nodeport
spec:
  type: NodePort # Specify the type
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
    # nodePort: 30007 # Optional: You can specify a port, or K8s assigns one

LoadBalancer

• What it is: Provisions an external load balancer from your cloud provider (e.g., AWS ELB, GCP Load Balancer).
• How it works: Automatically creates a NodePort service and configures the cloud load balancer to send traffic to it.
• Use Case: The standard "production" way to expose a service in a cloud environment.

apiVersion: v1
kind: Service
metadata:
  name: my-app-loadbalancer
spec:
  type: LoadBalancer # Specify the type
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

# Generic syntax for forwarding to a Service:
# This forwards your <local-port> to the <service-port> on the Service
kubectl port-forward service/<service-name> <local-port>:<service-port>

# Specific example:
# Forwards your local port 4443 to port 443 on the 'lnkdemo-lnk-product-client' service
kubectl port-forward service/lnkdemo-lnk-product-client 4443:443

After running this command, you can access your service by navigating to httpsD://localhost:4443 in your local browser.

An Ingress is an L7 (HTTP/HTTPS) router that manages external access to multiple services, usually under a single IP address. It is a separate Kubernetes resource, not a Service type, and requires an Ingress Controller (such as NGINX, Traefik, or HAProxy) to be running in the cluster.

Ingress supports advanced routing features, including:

• Host-based routing:foo.example.com → foo-service, bar.example.com → bar-service
• Path-based routing:example.com/api → api-service, example.com/ui → ui-service
• SSL/TLS termination: Centralized HTTPS certificate management

Example (Working Ingress YAML):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: link-ingress
  annotations:
    # Tells NGINX to use regular expressions for path matching
    nginx.ingress.kubernetes.io/use-regex: "true" 
    # Takes the part of the URL matched in the regex (.*) and appends it
    # e.g., /restdemo/users becomes /users when sent to the backend
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  ingressClassName: nginx # Specifies which ingress controller to use
  rules:
  - host: mynode.local # The domain name to listen on
    http:
      paths:
      # Traffic for mynode.local/restdemo/...
      - path: /restdemo/(.*)
        pathType: ImplementationSpecific # Use ImplementationSpecific for regex
        backend:
          service:
            name: link-lnk-product-rest # routes to the 'rest' service
            port:
              number: 8080
      # Traffic for mynode.local/serverdemo/...
      - path: /serverdemo/(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: link-lnk-product-server # routes to the 'server' service
            port:
              number: 8080
      # Catch-all for all other traffic (e.g., the frontend client)
      - path: /(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: link-lnk-product-client # routes to the 'client' service
            port:
              number: 80

Routes are the OpenShift-specific (RHOS) equivalent of Ingress. OpenShift created Routes before Ingress was a standardized feature in Kubernetes.

• What it is: A first-class OpenShift resource for L7 routing, tightly integrated with the built-in OpenShift Router (which is typically HAProxy).
• Features: Similar to Ingress (host/path routing, TLS termination), but with different resource definitions and specific OpenShift features like re-encrypt and passthrough for TLS.

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: my-app-route
spec:
  host: myapp.example.com # The router makes this host available
  to:
    kind: Service
    name: my-app-service # Points to the service
  port:
    targetPort: http # References the 'name' of the port in the service
  tls:
    termination: edge # Router terminates TLS

This category describes higher-level patterns for managing ingress traffic.

External Load Balancers

An External Load Balancer (cloud-based or on-prem, such as F5) operates outside the Kubernetes cluster and serves as the primary entry point for all incoming traffic.

Typical flow: User → External LB → Kubernetes Ingress Controller Service (NodePort/LB) → Ingress Pod → App Service → App Pod

This setup provides a stable, highly available entry point that remains independent of the cluster nodes.

An API Gateway is an advanced L7 proxy offering more capabilities than a standard Ingress Controller. Many modern controllers, such as Kong, Ambassador, and Traefik, can also act as API Gateways.

Ingress Controller focus: Routing HTTP traffic from a specific host or path (X) to the appropriate service (Y).

• Authentication and Authorization: Support for OIDC, JWT validation, etc.

• Rate Limiting: Restrict excessive requests from users.

• Request/Response Transformation: Modify headers or message bodies.

• Metrics and Observability: Provide detailed API usage analytics.