Create a Kubernetes deployment

[displague]

Expected Behaviour

Tinkerbell should be installable via kubectl apply ... or helm install ....

Current Behaviour

Tinkerbell is not installable in Kubernetes.

Possible Solution

Create manifests for Kubernetes installations.

This requires that images are published.

• [x] https://quay.io/organization/tinkerbell (amd64)
• [ ] The images should be multiarch so the Kubernetes install works on ARM (Raspberry Pis).

This requires that Kubernetes manifests:

• [ ] Exist for kubectl apply

And these manifests have optionally:

• [ ] Have been adapted for Kustomize patches
• [ ] Have been adapted to Helm install and publishing

Your Environment

Kubernetes 😄

[displague]

I converted the docker-compose environment from https://github.com/tinkerbell/tink/tree/master/deploy into an initial set of manifests: https://github.com/displague/tink-charts.

These currently lack any documentation on the configuration steps necessary to make them usable, because I am still tinkering with them.

I am using this on Raspberry Pis. When installing these manifests, I ran into the lack of multi-arch builds for the various services.

• https://github.com/tinkerbell/boots/issues/4
• https://github.com/tinkerbell/hegel/issues/21
• tink-server
• tink-cli
• https://github.com/tinkerbell/pbnj/issues/6

[displague]

@matoszz directed me to https://github.com/tinkerbell/tink/wiki/RFC-%233-Kubernetes-Support which covers the changes needed to get Tinkerbell running from Kubernetes from the perspective of a CRD controller handling the data.

This issue was opened with the expectation of using CSI or local-path volumes to persist data. I think this is a shorter path to running Tinkerbell within Kubernetes. A CRD based approach would overcome the persistent data hurdles (especially in the case of running K3s+Tinkerbell on a single Raspberry Pi node 😄 ).

Such a change could potentially remove the need for PBNJ and PostgreSQL. The other services would then use Kubernetes resources as the source of truth. The controller would effectively replace PBNJ and Kubernetes resources would replace PostgreSQL.

Without a bespoke API, tink-cli could become a Kubectl plugin that affects Kubernetes CRDs.

The CRDs that would be needed would map to the existing database tables (and tink-cli commands):

• Hardware
• Workflow
• Template

[displague]

@detiber, it sounds like @Cbkhare is going to be exploring this topic more with helm charts to deploy Tink in Kubernetes as one avenue to provide resiliency (https://github.com/tinkerbell/proposals/pull/10).

I was hoping you might be able to share some of your progress and thinking with Kind (https://github.com/detiber/tink/tree/kindDev) here.

[displague]

364 offers charts that may check some of the boxes on this issue.

[detiber]

I created https://github.com/tinkerbell/k8s-sandbox as a place that we could use for Kubernetes related work.

[invidian]

See also https://github.com/tinkerbell/tink/issues/335

[displague]

Closing this in light of https://github.com/tinkerbell/k8s-sandbox/tree/main/deploy/kubernetes