Is this project dead?

[hcbu-unix-ai]

Checks

• [x] I have searched the existing issues.
• [x] This issue is NOT security related. (Please disclose responsibly)
• [x] This issue is NOT specific to the CLI. (Please open a CLI issue)

deployKF Version

0.1.5

Kubernetes Distribution

RKE2

Kubernetes Version

1.30.1

Description

Hi All

Is this project dead? I did not see any new releases. I there any other alternative tool to easily deploy and manager Kubeflow.

Thanks

Relevant Logs

deployKF Values (Optional)

[thesuperzapper]

Hi, the project is not dead, and new versions are being worked on.

For context, we are intending to bring it back to a community focused development. I agree that we need to communicate and start this process immediately so people can have their say and contribute to deployKF.

As we were discussing in the slack, the next steps for deployKF is to set up a community meeting to kick-off a new focus on community driven development, separate from any commercial interest.

We are planning to do the meeting directly after the Kubeflow community meeting (8am PT on Tuesdays), but only once a month, so probably at 9am.

[hcbu-unix-ai]

Thanks for the update. Good to know.

Just want to know if we can use helmfile in deploykf for deploy kubeflow from local system without/with argocd. that will be greate.

I can also contribute to that. I just tried to work on helmfile project by my own, but it will take time and resources. you already have a community to do that.

check out this project to get an idea about this. https://github.com/meetzuber/kubeflow-helm

[abhinavsarkari]

@thesuperzapper Assuming the project is live, any idea when would the next release be available?

[moulin-louis]

Same question here 🙂

[edi-bice]

I have forked this project at https://github.com/edi-bice/deployKF and am gradually attempting to upgrade to upstream 1.10, so far mostly pipelines related. Will create a PR when things are working ... which may take a while given there's no clear mapping of the yamls used in deploykf and the upstream manifests

[berglh]

Just want to know if we can use helmfile in deploykf for deploy kubeflow from local system without/with argocd. that will be greate.

I can also contribute to that. I just tried to work on helmfile project by my own, but it will take time and resources. you already have a community to do that.

check out this project to get an idea about this. https://github.com/meetzuber/kubeflow-helm

@hcbu-unix-ai This has been discussed in #110. There are some components of deployKF that need to be update, along with stateful/declarative management of resources (i.e. Ensuring resources no longer required are remove from k8s) that ArgoCD handles via the GitOps pattern. I argue that you can do most of this with generated manifests and Terraform. Running ArgoCD is pretty simple compared to the complexity of customising Kubeflow for specific cloud environments, and so far, the benefits for me have outweighed the additional overhead of a separate deployment.

[surfaceflinger]

I think it'll be a good place to ask this - is anyone using deployKF on K8s 1.31 or higher on production without any issues? If yes, it would be good to at least update the compatibility matrix since AWS EKS 1.30 is entering extended support in a month. Simply not having something newer in compatibility matrix is definitely a huge blocker for upgrades for lots of organizations with various regulations even if there are no relevant breaking changes in K8s API.

[berglh]

@surfaceflinger I'm currently in the same holding pattern. Looking at the API deprecations for K8s 1.31 though, it seems like a fairly low-risk upgrade. I was planning to hold out as long as possible, then just upgrading next month if we don't get a new deployKF Kubeflow 1.10 release by then. Looking at https://github.com/deployKF/deployKF/issues/254 though, it has been working for at least one person.

[tom-pavz]

Any updates on whether the deployKF project is dead? Still haven't seen any new releases or announcements or anything very encouraging. main branch hasn't gotten a commit since May 27, 2024. As discussed in other messages in this thread, kubernetes versions continue to be released and deprecated on most major platforms, along with deployKF by default using quite old versions of kubeflow components (KFP, etc) and things like Istio. I fear the currently published latest version of DeployKF will become unusable in the not-so-distant future.

[RyanRennCN]

At this point, I think we all really need some clarity. If the answer is that the project is dead, then it is what it is, but we need that knowledge so that we can plan and move forward. Otherwise, we will have to assume and then proceed accordingly.

[thomaswetzler]

I really like the overall concept and architecture of the deployKF project — it provides a clean and modular approach for deploying Kubeflow with existing infrastructure and GitOps integration.

Unfortunately, the current version appears to be outdated and no longer functional. The main issue seems to be that several components in the deployment process depend on a Bitnami kubectl container image, which can no longer be pulled or built, because Bitnami removed this image from their registry on August 28, 2025.

As a result, the deployment fails when these images are referenced.

[berglh]

@thomaswetzler

For me, the ArgoCD initcontainer for the deploykf plugin stopped working as well. Updating the image to the following should work for the ArgoCD repo server init container.

    - name: deploykf-plugin-setup--kubectl
      image: docker.io/bitnamilegacy/kubectl:1.26.10
      command:
        - "/bin/sh"
        - "-c"

For the other images, I think you can update them in the deploykf values that contain.

-        repository: docker.io/bitnami/kubectl
+        repository: docker.io/bitnamilegacy/kubectl

After doing this, I resynced my ArgoCD apps and deleted the hung jobs in Kyverno. Eventually they restarted with the bitnamilegacy containers and are completing successfully.

Ref from @Ryan: https://github.com/bitnami/containers/issues/83267 pointed me in the direction of the legacy repo. I recommend caching images in a private container repo (i.e. ECR) to avoid further container deprecations.

[thomaswetzler]

I actually tried something similar using my own “swissknife” image, which I built specifically for situations like this. All Bitnami kubectl container images have already been replaced in my setup.

However, it seems that the installation still references remote Kustomization scripts which also depend on the same bitnami image. To fix this properly, one would need to create custom Kustomization patches to replace those references — which essentially requires a deep dive into both deployKF and Kubeflow internals.

Since I mainly want to experiment with AI, and not spend too much energy maintaining a complex Kubeflow deployment, I’ll probably step away from deployKF for now. Sorry about that, but I really appreciate the idea behind the project.

[berglh]

@thomaswetzler I'm pretty sure that's only the Argo CD plugin that pulls bitnami image to generate the YAML with Kustomize for Argo CD, but I can't be sure that will work for everything as you mention you've already tried something like that? In my case I brought my own Argo CD deployment in Amazon EKS, and just had to add the deployKF plugin and wire it up to my deployKF repo where my values are stored.

We really only use the notebook environment (where our users can use GPU accelerated JupyterLab environments for ML/LLM experiments) and use Airflow for scheduled workloads, but I guess if you're wanting to experiment with developing and serving models with the Kubeflow tools, Kubeflow isn't a bad platform.

At this stage, I think rolling my own Kubeflow might be on the horizon - but deployKF has been mostly great, despite it not having any updates for a while. The only other real solution if you don't want to build your own from Kubeflow manifests is the Canonical Charmed Kubeflow distribution which seems to be more actively maintained and cloud agnostic, perhaps you could look at that if you want the full Kubeflow environment.

[thomaswetzler]

@berglh Thanks for the hint! An out-of-the-box solution like Canonical is not an option for me, since I want to leverage existing cloud services. I am running on a European OpenStack-based provider (OpenTelekomCloud), so a tightly integrated rollout targeting US hyperscalers is not a good fit for me too.

I have therefore already started implementing Kubeflow service by service, making use of Claude Code and OpenSpec to streamline the setup. So far, progress has been good.

Thanks again for the input — much appreciated!

[mrcghil]

@thomaswetzler

For me, the ArgoCD initcontainer for the deploykf plugin stopped working as well. Updating the image to the following should work for the ArgoCD repo server init container.

- name: deploykf-plugin-setup--kubectl
  image: docker.io/bitnamilegacy/kubectl:1.26.10
  command:
    - "/bin/sh"
    - "-c"

For the other images, I think you can update them in the deploykf values that contain.

•    repository: docker.io/bitnami/kubectl
  

•    repository: docker.io/bitnamilegacy/kubectl
  

After doing this, I resynced my ArgoCD apps and deleted the hung jobs in Kyverno. Eventually they restarted with the bitnamilegacy containers and are completing successfully.

Ref from @Ryan: bitnami/containers#83267 pointed me in the direction of the legacy repo. I recommend caching images in a private container repo (i.e. ECR) to avoid further container deprecations.

Hello! I also run out into this issue and it took me a while to figure out because I thought I had messed up somewhere else. When can we have this in main? All the best,

Marco