@ancient-wolf-19325 is it possible to install flyte-core v1.15.x via helm charts in a single kubernetes namespace, so that both the control plane and task workflows run in the same kubernetes namespace? we also don’t want to install any cluster-wide resources, such as CRDs, ClusterRoles and ClusterRoleBindings

Flyte-core v1.15.x is designed to be installed via Helm charts, but by default, it creates cluster-wide resources such as CRDs, ClusterRoles, and ClusterRoleBindings. However, there is ongoing work and community discussion to support single-namespace deployments without cluster-wide permissions, including disabling CRD and ClusterRole installation and scoping FlytePropeller to a single namespace. This is not the default behavior, and while some PRs and issues (e.g., #3827, #2212, #5967) address parts of this, the official Helm chart for v1.15.x does not natively support a fully namespaced install out-of-the-box. To achieve this, you would need to: - Manually disable CRD and ClusterRole/ClusterRoleBinding creation in the Helm chart (using flags or by editing the chart/templates). - Create namespace-scoped Roles and RoleBindings for Flyte components. - Ensure FlytePropeller and FlyteAdmin are configured to operate only within the target namespace. - Accept that some features (like automatic namespace creation for projects/domains) may not work, and you may need to manage namespaces and resources manually. This approach is possible but requires custom modifications and is not fully documented or officially supported for v1.15.x. Would you like more detail on the specific steps or example configuration? Sources: - GitHub Issue: Enable flyte-binary to be deployed without cluster-wide permissions - GitHub PR: Make it possible to install multiple flyte installation in a single cluster - GitHub PR: Add option to install CRD as a part of chart install in flyte-binary 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 how about using something like the

limit-namespace

propeller setting?

The

limit-namespace

setting in FlytePropeller restricts FlytePropeller to watch and operate only within a specified namespace, which helps in running Flyte in a single namespace and avoiding cluster-wide access. However, this setting alone does not prevent the Helm chart from installing cluster-wide resources like CRDs, ClusterRoles, and ClusterRoleBindings—those are still created by default during installation and must be manually disabled or removed from the chart templates. So, while

limit-namespace

is necessary for single-namespace operation of FlytePropeller, it is not sufficient by itself to achieve a fully namespaced deployment without cluster-wide resources. Would you like more detail on how to combine

limit-namespace

with other configuration changes for a true single-namespace install? Sources: - GitHub Issue: Enable flyte-binary to be deployed without cluster-wide permissions 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 yes please

It seems likely that to achieve a true single-namespace Flyte deployment, you need to combine the

limit-namespace

FlytePropeller setting with manual Helm chart modifications. Here’s a step-by-step outline based on community discussions and PRs: 1. Set

limit-namespace

for FlytePropeller: In your FlytePropeller configuration, set the

limit-namespace

field to your target namespace. This ensures FlytePropeller only watches and manages resources in that namespace. 2. Disable Cluster-Wide Resource Creation in Helm: - Edit the Helm chart templates to prevent installation of CRDs, ClusterRoles, and ClusterRoleBindings. - For CRDs, you may need to pre-install them manually or use a flag (if available) to skip CRD creation. - For RBAC, replace ClusterRole/ClusterRoleBinding with Role/RoleBinding scoped to your namespace. 3. Install All Flyte Components in the Same Namespace: - Set the

namespace

value in your Helm values file to your chosen namespace for all components (FlyteAdmin, FlytePropeller, FlyteConsole, etc.). 4. Manually Manage Namespaces for Projects/Domains: - Since automatic namespace creation for each project/domain is disabled, you must ensure all executions use the single namespace, or manually create any additional namespaces if needed. 5. Accept Limitations: - Some features (like multi-namespace project isolation) will not be available. - You may need to maintain CRDs yourself if you skip their installation via Helm. Example snippet for FlytePropeller config (values.yaml or configmap):

propeller:
  limit-namespace: my-flyte-namespace

Example Role/RoleBinding (replace ClusterRole/ClusterRoleBinding):

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: my-flyte-namespace
  name: flyte-role
rules:
  # ... (same as ClusterRole, but scoped)
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: my-flyte-namespace
  name: flyte-rolebinding
roleRef:
  kind: Role
  name: flyte-role
  apiGroup: rbac.authorization.k8s.io
subjects:
  - kind: ServiceAccount
    name: flytepropeller
    namespace: my-flyte-namespace

This approach is not fully documented in the official Flyte docs for v1.15.x, but is discussed in GitHub Issue #3827 and PR #2212. You may need to experiment and adjust based on your environment. Sources: - GitHub Issue: Enable flyte-binary to be deployed without cluster-wide permissions - GitHub PR: Make it possible to install multiple flyte installation in a single cluster 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 when i run a test task with these flyte-core helm settings

cluster_resource_manager:
    enabled: false

  configmap:
    core:
      propeller:
        limit-namespace: flyte
    domain:
      domains:
        - id: development
          name: development
          namespace: '{{ .Release.Namespace }}'

i get the following error in the task gui:

failed to create workflow in propeller namespaces "flytesnacks-development" not found…

This error occurs because Flyte expects a namespace named

flytesnacks-development

to exist for the project/domain, but with your settings, all executions are intended to run in the single

flyte

namespace. Disabling the cluster resource manager prevents Flyte from automatically creating per-project/domain namespaces, so unless you manually create

flytesnacks-development

, the workflow cannot be scheduled there. To resolve this, you must configure Flyte to use the

flyte

namespace for all executions, not the default

{{project}}-{{domain}}

pattern. The

domain

config you provided only sets the domain name, not the execution namespace mapping. You need to explicitly set the namespace mapping in your config, for example:

configmap:
  domain:
    domains:
      - id: development
        name: development
        namespace: flyte
  namespace_config:
    namespace_mapping:
      template: flyte

This tells Flyte to use the

flyte

namespace for all executions, avoiding the missing namespace error. Would you like more detail on how to update your Helm values or config files? Sources: - GitHub Issue: Namespace creation fails with default pod template 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 i don’t see anything called

namespace_config

or

namespace_mapping

or even

mapping

in flyte-core values.yaml

It seems likely that the official flyte-core Helm chart values.yaml does not expose

namespace_config

or

namespace_mapping

as top-level configuration options. These settings are part of Flyte's internal configuration, but to use them with Helm, you need to inject them into the configmap section using the

inline

configuration or by extending the configmap templates directly. For example, you can add the following under your

configmap

in values.yaml to override the namespace mapping:

configmap:
  namespace_config:
    namespace_mapping:
      template: flyte

Alternatively, you may need to use the

inline

configuration block if your chart supports it:

configuration:
  inline:
    namespace_mapping:
      template: flyte

If neither approach is available in your chart version, you will need to manually edit the generated ConfigMap or extend the Helm chart to include this configuration. This limitation is not explicitly documented in the default values.yaml, but is discussed in GitHub Issue #2195 and PR #2196. Would you like more detail on how to patch or extend the Helm chart to include this config? Sources: - GitHub Issue #2195 - PR #2196 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.