talos

talos copied to clipboard

First of all: Thanks for making Talos, I really love it, and I only scratched the surface.

Feature Request

Option, to apply extra Manifests to a distinct namespace (e.g. kubectl -n <namespace> -f <urltomanifest>.

Description

As part of my cluster bootstrap, I use extraManifests to install argocd via the install.yml, that contains about 22000 lines of non namespaced lines of code. Since the extraManifests have no option for the target namespace, the manifest will be applied to the default namespace (not really best practice for argocd) of my shiny new talos kubernetes cluster. Providing a namespace option would greatly enhance the extraManifests usefulness. If my proposal doesn't align with your roadmap or architecture: Do you have an alternative way, that could help me here?

Commenting to get more attention on this. I think it would be an awesome addition to Talos to make bootstrapping more comfortable.

I believe namespace can be patched in using kustomize and other tools, it doesn't have to be part of Talos.

Thanks for your comment :-) I know, that there are numerous ways to get it deployed to a distinct namespace. I currently use helm right after I bootstrapped the talos cluster: helm upgrade --install argocd argo/argo-cd --create-namespace --namespace argocd

I want to use the official maintained manifests (not just for argocd, but also for sealed secrets, and some other basic stuff), and I don't want to maintain a patched fork.

Talos extra Manifests provide a powerful way to further automate my cluster installation. And it would be amazing, if the extra manifests could be applied context scoped (and maybe create the namespace, if its not existing beforehand). In my scenario, it would give me the opportunity to automate my whole cluster installation, that currently consists of 5 manual kubectl/helm executions.

@la7eralus,

I'm sort of working in the same area. As there (atleast for my deployment) is a secret dependancy i use the following code to generate a inline.yaml file that i have talos add when generating the controlplane.yaml

% cat ./clusters/xs4/talos/patches/inline.yaml cluster: inlineManifests: - name: argocd contents: |- EOF

% kustomize build ./clusters/xs4/kube/base/argocd --enable-alpha-plugins --enable-exec | sed 's/^/ /' >> ./clusters/xs4/talos/patches/inline.yaml

If its save to store secrets within your controlplane.yaml you could use this approach. If not, you could extract the inline config and place that somewhere more secure and use the extraManifests attribute to point it to the generated content produced by kustomize.

This is from my gitops-lab repo, as i was searching this for myself i though i would share it. I haven't committed this yet as its still a bit in flux but it might point you in the direction you need.

Also i do'nt feel like this is a Talos issue. I mean it would be great to have kustomization support for the inline or extraManifests. But i feel there isn't much of a difference where its generated and i could easiliy do that locally and than store the output for Talos to process, creating a automated way to boot and prep nodes.