Architecture and Concepts

The FortiADC Kubernetes Controller operates as a containerized application within a Kubernetes cluster. It observes Kubernetes resources such as Ingress, Service, EndpointSlice, Node, VirtualServer, RemoteServer, and Host, and translates them into FortiADC configuration objects by using the FortiADC REST API. This enables continuous synchronization between cluster state and FortiADC’s application delivery configuration.

Architecture Overview

The controller interacts with both the Kubernetes API Server and a FortiADC instance. It uses a Kubernetes service account to authenticate to the cluster and relies on a Kubernetes Secret to store FortiADC credentials securely.

FortiADC Kubernetes Controller is designed for a single control plane. A single Kubernetes cluster or FortiADC Kubernetes Controller instance may manage one or more FortiADC appliances. However, each FortiADC appliance must be managed by one and only one Kubernetes cluster or controller. Managing the same FortiADC appliance with multiple controllers or clusters is not supported and can lead to control-plane conflicts and unpredictable configuration behavior.

High-level workflow

1. Watch and detect — Monitors the Kubernetes API for Add, Update, and Delete events on supported resources.

2. Translate — Converts each resource specification into FortiADC objects such as virtual servers, content-routing rules, and real-server pools.

3. Apply — Pushes the translated configuration to FortiADC through the REST API.

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

This architecture allows FortiADC to function as a dynamic, state-aware load balancer that automatically reflects Kubernetes application topology changes.

Key Components

Component	Description
Controller Pod	Runs the FortiADC Kubernetes Controller inside the cluster and manages communication with both the Kubernetes API Server and FortiADC.
FortiADC Instance	The external FortiADC device that receives REST API calls from the controller and enforces the resulting configuration.
Service Account and RBAC	Provides the controller with permissions to read and watch Kubernetes objects such as Ingress, Service, EndpointSlice, Node, VirtualServer, RemoteServer, and Host.
Secret	Stores FortiADC login credentials securely within the cluster.
Helm Chart	Simplifies installation, upgrade, and removal of the controller and its supporting Kubernetes resources.
Custom Resource Definition (CRD)	Extends Kubernetes with Fortinet’s VirtualServer, RemoteServer, and Host resource type for defining advanced traffic-management features.

Kubernetes Resource Models

The FortiADC Kubernetes Controller supports two primary methods for managing local cluster traffic, alongside a specialized model for global traffic distribution. Administrators can use these models individually or in combination depending on application complexity and operational requirements.

Server Load Balancing: The Dual-Resource Model

For traffic entering a single cluster, the controller allows you to choose between native Kubernetes objects or advanced Fortinet-defined resources:

1. Standard Ingress (Native)

   Leverages the native Kubernetes Ingress framework to expose HTTP and HTTPS services. This model provides broad compatibility and is ideal for standard application publishing workflows.

   • Integrated Security: Extends native functionality by applying FortiADC’s Web Application Firewall (WAF), antivirus scanning, and Denial-of-Service (DoS) protection.

   • Operational Visibility: Enables enterprise-grade health checks, traffic logging, and FortiView analytics.

2. VirtualServer (Custom Resource)

   Uses the Fortinet-defined VirtualServer CRD to configure FortiADC-specific parameters directly within Kubernetes. When acting as a server load balancer, the controller translates these specifications into virtual servers, content routing rules, and real server pools.

   • Advanced Routing: Supports version v1alpha2, which provides L4 (TCP/UDP) and L7 (HTTP/HTTPS) content routing options.

   • Granular Control: Supports persistence, GSLB integration, advanced Layer 7 capabilities (such as WAF profiles, SSL settings), and Layer 4 security IPS features.

Global Load Balancing (GLB)

For traffic management across geographically dispersed clusters, the controller manages specialized GLB objects such as Servers, Data Centers, Hosts, and Virtual Server Pools:

• RemoteServer: Used to specify server information and monitor both FortiADC instances and third-party servers.

• Host: Supports a DNS-based solution for load-balancing traffic across different geographical locations.

• GLB Priorities: The DNS-based response is prioritized based on virtual server health, persistence, geographic or dynamic proximity, and weighted round robin.

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

Resource Specifications

Review the following sections for the technical logic, naming conventions, and resource schemas required for deployment:

• Mapping Kubernetes Resources to FortiADC Objects: Detailed translation logic and the Naming Rules used for automated object creation.

• Kubernetes Ingress: Specifics on the five supported Ingress types and the required IngressClass configuration.

• Kubernetes Custom Resource: Field specifications and YAML examples for VirtualServer, RemoteServer, and Host definitions.