Skip to main content

Configuring the Deployment Environment

When you deploy Flyte apps, you must configure how the data plane (Internal App Service) exposes those apps to the network and how the control plane (App Service) communicates with the data plane. This is managed through the AppConfig and InternalAppConfig classes in app/config/config.go.

Configuring the Data Plane (InternalAppConfig)

The InternalAppConfig defines the environment where apps are actually deployed as Knative Services. You typically configure this in the data plane's configuration file.

internalApps:
enabled: true
baseDomain: "apps.flyte.example.com"
scheme: "https"
defaultRequestTimeout: "300s"
maxRequestTimeout: "3600s"
ingressAppsPort: 0
namespacedNameSuffixTemplate: "{{ project }}-{{ domain }}"
defaultEnvVars:
FLYTE_INTERNAL_ENDPOINT: "http://flyte-binary.flyte.svc.cluster.local:8088"

Public URL Generation

Flyte generates deterministic public URLs for apps based on the BaseDomain and Scheme. The AppK8sClient.PublicIngress method in app/internal/k8s/app_client.go constructs these URLs using the following pattern:

{name}-{project}-{domain}.{base_domain}

If IngressAppsPort is set to a non-zero value, it is appended to the URL (e.g., :30081). If BaseDomain is empty, no public ingress URLs are generated.

Managing Request Timeouts

Timeouts are governed by two fields:

  • DefaultRequestTimeout: Applied to any app that does not specify its own timeout in the AppSpec.
  • MaxRequestTimeout: Acts as a hard cap. If an app requests a timeout longer than this value, Flyte clamps it to the maximum allowed. Note that Knative itself has a hard limit of 3600s.

Service Discovery and Environment Variables

Flyte automatically injects environment variables into every app pod to facilitate service discovery and provide cluster-internal context:

  1. DefaultEnvVars: A map of key-value pairs injected into every container. Use this to provide cluster-internal endpoints (like the Flyte manager URL) that all apps need.
  2. INTERNAL_APP_ENDPOINT_PATTERN: Automatically injected by AppK8sClient.buildKService. It allows apps to discover other apps within the same cluster using a template.

The NamespacedNameSuffixTemplate (defaulting to {{ project }}-{{ domain }}) determines the suffix used in this pattern. For example, if an app is in project myproj and domain prod, the injected variable will look like: INTERNAL_APP_ENDPOINT_PATTERN=http://{app_fqdn}-myproj-prod.flyte.svc.cluster.local

Configuring the Control Plane (AppConfig)

The control plane needs to know where the data plane is located and how to cache app statuses.

apps:
internalAppServiceUrl: "http://internal-app-service.flyte.svc.cluster.local:8091"
cacheTtl: "30s"
  • InternalAppServiceURL: The base URL of the data plane service. In unified deployments where both services run in the same process, this is often overridden by a shared mux.
  • CacheTTL: Determines how long the control plane caches app status in memory. Set this to 0 to disable caching and force a fresh lookup for every request.

Implementation Details

Deployment Logic

When AppK8sClient.Deploy is called, Flyte checks the annotationSpecSHA on the existing Knative Service. If the SHA matches the new spec, the update is skipped unless the app was previously in a "Stopped" state.

Stopping Apps

The AppK8sClient.Stop method does more than just scaling to zero. It:

  1. Sets the networking.knative.dev/visibility label to cluster-local to remove the app from the public gateway.
  2. Sets autoscaling.knative.dev/min-scale and initial-scale to 0.
  3. Deletes the LatestReadyRevision: This ensures that any currently running pods are terminated immediately, bypassing the standard Knative stable window.

Troubleshooting

  • Apps not starting: Ensure internalApps.enabled is set to true. If this is false, the data plane controller will not initialize.
  • URL Mismatches: If your ingress controller expects a different naming convention, you may need to adjust NamespacedNameSuffixTemplate. The KServiceName function in app/internal/k8s/app_client.go handles the actual resource naming, including a fallback to a SHA256 suffix if the generated name exceeds the 63-character Kubernetes DNS limit.
  • Timeout Clamping: If an app's logs indicate a timeout shorter than requested, check the MaxRequestTimeout in your InternalAppConfig. Flyte will silently clamp values exceeding this limit during the buildKService phase.