Hi Flyte team, I'm trying to setup Flyte on EKS But your guide flyte-the-hard-way is difficult to setup as I did the most part - except the last part which is to setup the ingress controller and load balancer then I dig deep and found this page of yours https://helm.flyte.org/#production-clusters-for-eks which has wrong instructions the RDS_HOST_DNS is repeated twice, and also the userSettings.yaml is not right - I somehow used bucketName field in that and it worked However, there's no proper resource I could find to make it PRODUCTION ready. I need community help to guide me! Please help me!

Hey @numerous-pizza-94528 have you looked at union? We have a BYOK offering so you don’t have to setup ingress etc. Only the data plane and everything is managed through control plane

https://github.com/unionai-oss/deploy-flyte/tree/main/environments/aws/flyte-core Also have a look at this: @numerous-pizza-94528

@numerous-pizza-94528 Deploying flyte can be confusing , and even more so to make it production ready. For storage (which to me was very confusing because documentation is not great on deployment side), I found the most straight forward way to configure it was to specify 'custom' type and then use stow configuration to configure it correctly. If you plan to use MINIO storage, just use the same configuration as S3 (no need to enable v2 signing, since current MINIO version supports v4 signing). Below is an example configuration using 'custom':

storage:
  type: custom #sandbox, s3, gcs and custom
  custom:
    type: minio # or s3, local, mem, stow
    container: default container/bucket name (flyte creates if not exist)
    stow:
      kind: s3 # or azure, google, oracle, swift, b2, sftp, local
      config: #stow config associated with specified stow kind
        access_key_id: 
        auth_type: 
        secret_key: 
        disable_ssl: 
        endpoint: <http://your-custom-url.com|your-custom-url.com>
        v2_signing: 
    signedUrl:
      stowConfigOverride:
        # really important when deploying flyte to avoid errors related to MD5 checksum errors. Typically same as stow.config.endpoint
        endpoint: <http://your-custom-url.com|your-custom-url.com>
    enable-multicontainer:

On the other hand, making Flyte production ready consists of load-balancing, ingresses and adding TLS encryption to ingresses I would focus on the later 2, since telling researchers that they have to port forward services to local workstations (vs giving them a config file and calling it a day) on top of making sure code is now tailored for Flyte will create friction. Flyte has a flag that will create ingresses for you, and you can just modify those ingresses to suit your needs:

common:
  ingress:
    create: true
    ingressClassName: nginx # or whatever you use
    separateGrpcIngress: true # not necessary, but I prefer separate ingresses for http and grpc for better debugging when things go wrong
    commonAnnotations:
      <http://ingress.kubernetes.io/rewrite-target|ingress.kubernetes.io/rewrite-target>: /
      <http://nginx.ingress.kubernetes.io/ssl-redirect|nginx.ingress.kubernetes.io/ssl-redirect>: "true"
      <http://kubernetes.io/ingress.class|kubernetes.io/ingress.class>: public
    httpAnnotations:
      <http://nginx.ingress.kubernetes.io/app-root|nginx.ingress.kubernetes.io/app-root>: /console
    grpcAnnotations:
      <http://nginx.ingress.kubernetes.io/backend-protocol|nginx.ingress.kubernetes.io/backend-protocol>: GRPC
    host: <http://some.domain.com|some.domain.com> # NOTE: change for the URL you'll use to connect to Flyte
    ### Comment if you want to remove TLS support from HTTP/GRPC (NOTE: GRPC service only works with TLS when using kubernetes ingress)
    tls:
      enabled: true
      hosts:
        - "<http://some.domain.com|some.domain.com>"
      secretName: some-domain-tls # you have to create this secret sepparately using whatever ca certificate key your IT department uses

why dont you try with flyte-binary very staright forward