Deploying FortiADC Kubernetes Controller

The FortiADC Kubernetes Controller runs as a pod within a Kubernetes cluster and provides dynamic synchronization between Kubernetes resources and FortiADC configuration objects. Once deployed, it continuously monitors the cluster for changes to relevant resources and automatically updates FortiADC to reflect the current application state.

Deployment Scenarios

The controller supports multiple traffic-management models to suit your architectural requirements:

• Server Load Balancing (Ingress & VirtualServer): Use the familiar Kubernetes Ingress framework or Fortinet’s VirtualServer Custom Resource to deliver advanced Layer 4 & Layer 7 proxying, WAF security, and antivirus scanning.

• Global Load Balancing (GLB): Utilize RemoteServer and Host Custom Resources to distribute traffic across geographically dispersed servers via a DNS-based solution .

Core Deployment Components

A successful deployment integrates several key components within your cluster:

• Controller Pod: Manages communication between the Kubernetes API Server and FortiADC.

• Custom Resource Definitions (CRDs): Extensions such as VirtualServer, RemoteServer, and Host that allow for granular FortiADC configuration. These are installed automatically via Helm and are required for controller operation.

• Validating and Conversion Webhooks: The FortiADC Kubernetes Controller utilizes webhooks to ensure the integrity and compatibility of resources within the cluster. These are automatically deployed during the Helm installation process.

  • Validating Webhooks: These act as a gatekeeper. When you run kubectl apply, the validating webhook checks the YAML for configuration errors or missing required fields. If the manifest is invalid, the webhook rejects the request before it reaches the FortiADC.

  • Conversion Webhooks: These handle the seamless upgrade and migration of Fortinet-defined Custom Resources (CRs). As new versions of the controller are released with updated CRD schemas, the conversion webhook ensures that older resources are automatically translated to the latest supported version without manual intervention.

• cert-manager.io: Automates the management of TLS certificates required for secure communication with the webhook server.

High-Level Deployment Workflow

To get the controller operational, follow these phases in order:

1. Phase 1: Architecture Review: Understand how Kubernetes objects map to FortiADC and select your preferred resource model.

   See: Architecture and Concepts

2. Phase 2: Controller Installation: Deploy cert-manager (mandatory for webhook TLS) followed by the Helm Chart installation.

   See: Controller Installation

3. Phase 3: Network Integration (Optional): If using ClusterIP services, establish a VXLAN overlay tunnel for your specific CNI plugin.

   See: Kubernetes CNI Plugin

4. Phase 4: Resource Configuration: Define annotations and manifests to begin traffic synchronization.

   See: Configuration Parameters