Service Deployment and Lifecycle

The FortiADC Kubernetes Controller continuously monitors the Kubernetes API for Service-related events. This section defines the operational constraints for service management and provides a template for deploying ClusterIP services via an overlay tunnel.

Operational Constraints

When configuring Kubernetes Services for use with FortiADC, the following technical limitations and behaviors apply:

• Selective Monitoring: The controller only tracks Service types and annotations for services explicitly referenced in a deployed Ingress or VirtualServer resource.

• Single Port Limitation: Currently, the controller does not support services with multiple exposed ports. Each service must map to a single logical port.

• Dependency Handling: If a Service referenced by an active Ingress/VirtualServer is deleted, Kubernetes does not issue a warning. The controller does not handle standalone Service delete events; the parent resource (Ingress/VS) must be updated or removed to clear the configuration on the FortiADC.

• ClusterIP Support:

  • Controller v2.0: Supports Ingress referencing ClusterIP services.

  • Controller v3.0+: Supports both Ingress and VirtualServer referencing ClusterIP services.

Deploying a ClusterIP Service (Overlay Mode)

Because ClusterIP addresses are only reachable within the cluster network, you must associate the service with a specific overlay tunnel defined on the FortiADC.

1. Implementation Requirements

   • Networking: A Flannel or Calico VXLAN tunnel must be pre-configured on the FortiADC.

   • Annotations: The overlay_tunnel annotation in the Service manifest must match the tunnel name created on the FortiADC.

2. Manifest Example: NGINX via ClusterIP

   The following YAML defines a deployment and a service. The service is annotated to use a VXLAN tunnel named k8s on the FortiADC. In this example, please ensure you have generated the required Kubernetes Secret and ConfigMap for your NGINX pods.

   apiVersion: v1
   kind: Service
   metadata:
     name: my-web
     labels:
       run: my-web
     annotations: {
       "health-check-ctrl" : "enable",
       "health-check-relation" : "OR",
       "health-check-list" : "LB_HLTHCK_HTTPS",
       "real-server-ssl-profile" : "LB_RS_SSL_PROF_HIGH",
       "overlay_tunnel" : "k8s",
     }
   spec:
     ports:
     - port: 443
       protocol: TCP
       name: https
       targetPort: https
     selector:
       app: my-web
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-web
   spec:
     selector:
       matchLabels:
         app: my-web
     replicas: 2
     template:
       metadata:
         labels:
           app: my-web
       spec:
         volumes:
         - name: secret-volume
           secret:
             secretName: nginxsecret
         - name: configmap-volume
           configMap:
             name: nginxconfigmap
         containers:
         - name: nginxhttps
           image: nginx
           ports:
           - containerPort: 443
             name: https
           - containerPort: 80
             name: http
           volumeMounts:
           - mountPath: /etc/nginx/ssl
             name: secret-volume
           - mountPath: /etc/nginx/conf.d
             name: configmap-volume
   

Lifecycle Behavior: What Happens When...

Event	Controller Action
New Pod Added	The controller detects the new endpoint and adds the Pod IP/Port to the FortiADC Real Server Pool immediately.
Pod Terminated	The endpoint is removed from the FortiADC pool to prevent "blackholing" traffic.
Annotation Updated	The controller updates the FortiADC Real Server Pool settings (e.g., changing the health check method) to match the new annotation.