Architecture and Concepts

The FortiADC Kubernetes Controller in OpenShift operates as an intermediary between OpenShift cluster resources and FortiADC configuration objects.

It runs as a controller Pod that subscribes to OpenShift API events, interprets Route, VirtualServer, RemoteServer, and Host resource definitions, and reconciles the corresponding FortiADC configurations through REST API transactions.

Architecture Overview

The controller is deployed as a containerized application within an OpenShift project namespace.

It establishes a persistent connection to the OpenShift API server using service account permissions to watch resource events in real time. When a resource change is detected, the controller evaluates the new cluster state and determines whether a configuration update is required on FortiADC.

Configuration synchronization is performed through authenticated REST API calls to FortiADC. Administrative credentials are stored in a Kubernetes Secret referenced by the controller.

Each update is executed as a discrete transaction that ensures configuration integrity and prevents drift, allowing consistent operation even in large-scale or dynamic OpenShift environments.

High-Level Workflow

1. Watch and detect — Subscribes to the OpenShift API to monitor Add, Update, and Delete events for supported resources such as Routes, Services, Pods, and Fortinet’s custom resources.

2. Translate — Converts each detected resource definition into FortiADC configuration data, including virtual servers, GLB service, content-routing rules, and real-server pools.

3. Apply — Sends the translated configuration to FortiADC through authenticated REST API calls, creating or updating the corresponding configuration objects.

4. Reconcile — Continuously compares OpenShift resource definitions with FortiADC’s active configuration and updates FortiADC whenever differences are detected.

This architecture allows FortiADC to operate as a dynamic, state-aware load balancer and application security gateway that automatically reflects changes in OpenShift application topology.

Key Components

Component	Description
Controller Pod	Runs the FortiADC Kubernetes Controller within the OpenShift cluster and manages communication with both the OpenShift API server and FortiADC.
FortiADC Instance	The external FortiADC device that receives REST API calls from the controller and applies the resulting configuration.
Service Account and RBAC	Provides the controller with permissions to read and watch OpenShift objects such as Route, Service, Pod, Secret, and VirtualServer.
Secret	Stores FortiADC login credentials securely within the OpenShift cluster.
Helm Chart	Simplifies installation, upgrade, and removal of the controller and its supporting OpenShift resources.
Custom Resource Definition (CRD)	Extends OpenShift with Fortinet’s VirtualServer resource type for defining advanced Layer 7 and layer 4 load-balancing and security parameters. RemoteServer and Host resources are included to cover GLB-related services.

Resource Mapping

The following table summarizes how OpenShift resources correspond to FortiADC objects.

OpenShift Resource	FortiADC Object
Route	Virtual Server / Content Routing
Service	Real Server Pool
Endpoint / EndpointSlice	Real Server

For more information on Fortinet’s custom resources such as VirtualServer, RemoteServer, and Host, including definitions and deployment examples, refer to FortiADC Kubernetes Controller Deployment Guide.

Static Route and VxLAN Models

The FortiADC Kubernetes Controller in OpenShift supports two network integration models for connecting FortiADC to OpenShift cluster endpoints.

• Static Route model

  FortiADC reaches OpenShift Pods or services through statically defined routes. This model requires manual route configuration on FortiADC and is typically used in environments without an overlay network. It provides predictable network paths and is suitable for deployments where network topology is fixed.

• VxLAN model

  FortiADC connects to Pods through the OpenShift VxLAN overlay network. In this model, FortiADC participates in the VxLAN fabric, allowing dynamic discovery and direct Layer 2 connectivity with Pods across nodes. This simplifies routing and improves scalability in distributed OpenShift clusters.

Both models are supported through the same controller synchronization mechanism. The controller automatically translates OpenShift resource events into FortiADC configuration updates, regardless of the underlying connectivity model.

Before deploying the FortiADC Kubernetes Controller in OpenShift, review the OpenShift, Kubernetes, and Helm concepts described in Prerequisite Knowledge.