CNE Kubernetes Ready: Networking for Kubernetes Ready Deployments

Kubernetes Ready deployments expose Liferay DXP through the liferay-default Kubernetes Service created by the Helm chart. External traffic reaches this Service through platform-managed networking layers such as Ingress controllers, Gateway API implementations, load balancers, service meshes, or CDN-fronted edge proxies, depending on the infrastructure.

Supported ingress and routing options include NGINX, Traefik, Envoy, Istio, Contour, AWS ALB, GKE Ingress, Azure Application Gateway, OpenShift Routes, and edge CDNs such as Cloudflare, Akamai, Fastly, and CloudFront.

Networking Model

The liferay-default chart exposes two Kubernetes Services:

Service	Ports	Purpose	External Traffic
`liferay-default` (ClusterIP)	`http: 8080`, `cluster: 7800`	Main entry point for Liferay DXP. Route external traffic to port `8080` only.	Yes (on `8080`)
`liferay-default-headless`	`http: 8080`, `cluster: 7800`	Stable per-pod DNS for cluster link communication	No

External traffic must only reach the liferay-default Service on port 8080.

Important

Do not expose port 7800 externally. Liferay uses this channel internally for clustering and session replication between StatefulSet replicas.

Configure Forwarded Headers

Liferay must trust the forwarded headers added by your ingress or proxy layer. Without these settings, Liferay can generate incorrect absolute URLs in redirects, emails, OAuth callbacks, and generated links.

Add these environment variables to values.yaml:

customEnv:
  x-liferay-forwarded:
    - name: LIFERAY_WEB_PERIOD_SERVER_PERIOD_FORWARDED_PERIOD_PORT_PERIOD_ENABLED
      value: "true"

    - name: LIFERAY_WEB_PERIOD_SERVER_PERIOD_FORWARDED_PERIOD_PROTOCOL_PERIOD_ENABLED
      value: "true"

    - name: LIFERAY_WEB_PERIOD_SERVER_PERIOD_FORWARDED_PERIOD_HOST_PERIOD_ENABLED
      value: "true"

Common Networking Requirements

Regardless of the ingress technology used, production deployments commonly require these adjustments:

Concern	Why it matters
WebSocket and SSE support	Collaboration features, notifications, and live updates use long-lived connections
Header size limits	Authentication tokens and cookies can exceed default proxy limits
Read and idle timeouts	Imports, exports, publishing, and large requests can run for several minutes
Sticky sessions	Optional, but can reduce failover issues during session replication
Compression	Prefer edge-side compression instead of compressing responses in Tomcat

Gateway API

You can use Gateway API when your platform standardizes on Envoy Gateway, Istio Gateway API, Contour, Kong, or other Gateway API implementations.

Enable the chart’s HTTPRoute support:

network:
  enabled: true
  gatewayName: liferay-gateway
  endpointRef: http
  forceHttpsRedirect: true

  hostnames:
    - "liferay.example.com"

  timeouts:
    backendRequest: 300s
    request: 300s

The chart creates the HTTPRoute, but your platform remains responsible for the Gateway, listeners, TLS certificates, and gateway lifecycle management.

Kubernetes Ingress Controllers

If your platform uses standard Kubernetes Ingress resources, disable the chart networking layer and create an Ingress resource separately.

Here is an example using NGINX Ingress Controller and cert-manager:

apiVersion: networking.k8s.io/v1
kind: Ingress

metadata:
  name: liferay
  namespace: liferay

  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/proxy-body-size: "100m"
    nginx.ingress.kubernetes.io/proxy-buffer-size: "16k"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "300"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "300"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"

spec:
  ingressClassName: nginx

  tls:
    - hosts:
        - liferay.example.com
      secretName: liferay-example-tls

  rules:
    - host: liferay.example.com

      http:
        paths:
          - path: /
            pathType: Prefix

            backend:
              service:
                name: liferay-default

                port:
                  name: http

Equivalent patterns exist for Traefik, HAProxy Ingress, and other controllers.

Cloud Load Balancers

Managed Kubernetes platforms commonly provision cloud-native load balancers from Kubernetes resources.

Platform	Typical Integration
Amazon EKS	AWS Load Balancer Controller with ALB
Google GKE	GKE Ingress or Gateway Controller
Azure AKS	Application Gateway for Containers or AGIC

In these environments, TLS commonly terminates at the cloud load balancer before traffic reaches the Kubernetes cluster.

Service Mesh

If your environment uses a service mesh such as Istio or Linkerd, expose Liferay through the mesh ingress gateway instead of a standalone ingress controller.

Here is an example Istio Gateway and VirtualService:

apiVersion: networking.istio.io/v1
kind: Gateway

metadata:
  name: liferay-gateway
  namespace: liferay

spec:
  selector:
    istio: ingressgateway

  servers:
    - port:
        number: 443
        name: https
        protocol: HTTPS

      hosts:
        - "liferay.example.com"

      tls:
        mode: SIMPLE
        credentialName: liferay-example-tls

---
apiVersion: networking.istio.io/v1
kind: VirtualService

metadata:
  name: liferay
  namespace: liferay

spec:
  hosts:
    - "liferay.example.com"

  gateways:
    - liferay-gateway

  http:
    - timeout: 300s

      route:
        - destination:
            host: liferay-default

            port:
              number: 8080

OpenShift Routes

OpenShift environments can expose Liferay through native Route resources instead of Ingress.

Example:

apiVersion: route.openshift.io/v1
kind: Route

metadata:
  name: liferay
  namespace: liferay

spec:
  host: liferay.example.com

  to:
    kind: Service
    name: liferay-default

  port:
    targetPort: http

  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect

CDN and Edge Proxy Deployments

Many production deployments place a CDN or edge proxy in front of Kubernetes.

Options include:

Cloudflare
Akamai
Fastly
Amazon CloudFront

These platforms commonly provide:

TLS termination
Web Application Firewall (WAF)
DDoS protection
Global edge caching
Bot filtering

Two common deployment patterns exist.

CDN in Front of a Public Ingress

The CDN forwards requests to a public Kubernetes ingress or load balancer. Restrict direct access to the origin whenever possible so requests flow through the edge layer.

Private Tunnel Into the Cluster

Some deployments connect the edge platform directly to Kubernetes through private tunnels or private networking.

Examples include:

Cloudflare Tunnel
AWS PrivateLink
Azure Private Link

In these environments, Kubernetes may not expose any public load balancer at all.

TLS Termination Strategies

Kubernetes Ready does not enforce a specific TLS strategy. Choose the layer that best matches your platform architecture.

Termination Layer	Typical Use Case
CDN or WAF	Internet-facing production deployments
Cloud load balancer	Cloud-native certificate management
Ingress or Gateway	Platform-managed certificates with cert-manager
Service mesh sidecar	End-to-end encrypted zero-trust environments

Only one layer should perform HTTP-to-HTTPS redirects. Multiple redirect layers can create redirect loops.

Validate External Connectivity

After exposing the deployment, complete these steps:

Confirm requests reach liferay-default on port 8080.
Confirm Liferay generates URLs with the correct hostname and HTTPS scheme.
Confirm large uploads, authentication flows, and WebSocket connections function correctly.
Confirm port 7800 remains inaccessible externally.
Confirm TLS certificates renew correctly if automated certificate management is used.