I'll post more later (reply here to remind me), but I have your exact setup. It's a great way to learn k8s and yes, it's going to be an uphill battle for learning - but the payoff is worth it. Both for your professional career and your homelab. It's the big leagues.

For your questions, no to all of them. Once you learn some of it the rest kinda falls together.

I'm going into a meeting, but I'll post here with how I do it later. In the mean time, pick one and only one container you want to get started with. Stateless is easier to start with compared to something that needs volumes. Piece by piece brick by brick you will add more to your knowledge and understanding. Don't try to take it all on day one. First just get a container running. Then access via a port and http. Then proxy. Then certs. Piece by piece, brick by brick. Take small victories, if you try to say "tomorrow everything will be on k8s" you're setting yourself up for anger and frustration.

@sunoc@sh.itjust.works Edit: To help out I would do these things in these steps, note that steps are not equal in length, and they are not complete - but rather to help you get started without burning out on your journey. I recommend just taking each one, and when you get it working rather than jumping to the next one, instead taking a break, having a drink, and celebrating that you got it up and running.

0. Start documenting everything you do. The great thing about kubernetes is that you can restart from scratch if you have written everything down. I would start a new git repository with a README that contains every command you ran, what it did, and why you did it. Assume that you will be tearing down your cluster and rebuilding it - in fact I would even recommend that. Treat this first cluster as your testing grounds, and then you won't feel crappy spinning up temporary resources. Then, you can rebuild it and know that you did a great job - and you'll feel confident in rebuilding in case of hardware failure.

1. Get the sample nginx pod up and running with a service and deployment. Simply so you can curl the IP of your main node and port, and see the response. This I assume you have played with already.

2. Point DNS to your main node, get the nginx pod with http://your.dns.tld:PORT. This should be the same as anything you've done with docker before.

3. Convert the yaml to a helm chart as other have said, but don't worry about "templating" yet, get comfortable with helm install, helm upgrade -i, and helm uninstall. Understand what each one does and how they operate. Then go back and template, upgrade-ing after each change to understand how it works. It's pretty standard to template the image and tag for example so it's easy to upgrade them. There's a million examples online, but don't go overboard, just do the basics. My (template values.yaml) usually looks like:

<<servicename>>
  name: <<servicename>>
  image:
    repository: path/to/image
    tag: v1.1.1
    network:
     port: 8888

Just keep it simple for now.

4. Decide on your proxy service. Traefik as you see comes out of the box. I personally use istio. I can go into more details why later, but I like that I can create a "VirtualService" for "$appname.my.custom.tld` and it will point to it.
5. Implement your proxy service, and get the (http only still) app set up. Set up something like nginx.your.tld and be able to curl http://nginx.your.tld and see that it routes properly to your sample nginx service. Congrats, this is a huge one.
6. Add the CertManager chart. This will set it up so you can create Certificate types in k8s. You'll need to use the proxy in the previous step to route the /.well-known endpoints on the http port from the open web to cert-manager, for Istio this was another virtual service on the gateway - I assume Traefic would have something similar to "route all traffic on port 80 that starts with /.well-known to this service". Then, in your nginx helm chart, add in a Certificate type for your nginx endpoint, nginx.your.tld, and wait for it to be successfully granted. With Istio, this is all I need now to finally curl https://nginx.your.tld!

At this point you have routing, ports, and https set up. Have 2 drinks after this one. You can officially deploy any stateless service at this point.

Now, the big one, stateful. Longhorn is a bear, there are a thousand caveats to it.

Step one is where are your backups going to go. This can be a simple NFS/SMB share on a local server, it can be an s3 endpoint, but seriously this is step 1. Backups are critical with longhorn. You will fuck up Longhorn - multiple times. Losing these backups means losing all configs to all of your pods, so step one is to decide on your stable backup location.

Now, read the Longhorn install guide: https://longhorn.io/docs/1.9.0/deploy/install/. Do not skip reading the install guide. There are incredibly important things in there that I regretted glossing over that would have saved me. (Like setting up backups first).

The way I use longhorn is to create a PV in longhorn, and then the PVC (you can look up what both of these are later). Then I use Helm to set what the PVC name is to attach it to my pod. Try and do this with another sample pod. You are still not ready to move production things over yet, so just attach it to nginx. exec into it, write some data into the pvc. Helm uninstall. See what happens in longhorn. Helm install. Does your PVC reattach? Exec in, is your data still there? Learn how it works. I fully expect you to ping me with questions at this point, don't worry, I'll be here.

Longhorn will take time in learning, give yourself grace. Also after you feel comfortable with it, you'll need to start moving data from your old docker setup to Longhorn, and that too will be a process. You'll get there though. Just start with some of your lower priority projects, and migrate them one by one.

After all of this, there is still more. You can automount smb/nfs shares directly into pods for media or anything. You can pass in GPUs - or I even pass in some USB devices. You can encrypt your longhorn things, you can manage secrets with your favorite secret manager. There's thousands of things you'll be able to do. I wish you luck, and feel free to ping me here or on Matrix (@scrubbles@halflings.chat) if you ever need an ear. Good luck!

Ive actually been personally moving away from kubernetes for this kind of deployment and I am a big fan of using ansible to deploy containers using podman systemd units, you have a series of systemd .container files like the one below

[Unit]
Description=Loki

[Container]
Image=docker.io/grafana/loki:3.4.1

# Use volume and network defined below
Volume=/mnt/loki-config:/mnt/config
Volume=loki-tmp:/tmp/loki
PublishPort=3100:3100
AutoUpdate=registry

[Service]
Restart=always
TimeoutStartSec=900

[Install]
# Start by default on boot
WantedBy=multi-user.target default.target

You use ansible to write these into your /etc/containers/systemd/ folder. Example the file above gets written as /etc/containers/systemd/loki.container.

Your ansible script will then call systemctl daemon-reload and then you can systemctl start loki to finish the example

The answer to the first two questions are helm charts. They are collections of parametrized yaml files and the most popular way to install things into k8s. You just need one config file for each helm release (values.yaml).

If you want to go declarative with gitops rather than imperative, check ArgoCD or flux.

You're right to be reluctant to apply everything by hand. K3s has a built-in feature that watches a directory and applies the manifests automatically: https://docs.k3s.io/installation/packaged-components

This can be used to install Helm charts in a declarative way as well: https://docs.k3s.io/helm

If you want to keep your solution agnostic to the kubernetes environment, I would recommend that you try ArgoCD (or FluxCD, but I never tried it so YMMV).

I've thought about k8s, but there is so much about Docker that I still don't fully know.

And this is why I do not like K8s at all. The only reason to use it is to have something on your CV. Besides that, Docker Swarm and Hashicorp Nomad feel a lot better and are a lot easier to manage.

K3s (and k8s for that matter) expect you to build a hierarchy of yaml configs, mostly because spinning up docker instances will be done in groups with certains traits applying to whole organization, certain ones applying only to most groups, but not all, and certain configs being special for certain services (http nodes added when demand is higher than x threshold).

But I wonder why you want to cluster navidrome or pihole? Navidrome would require a significant load before service load balancing is required (and non-trivial to implement), and pihole can be put behind a round-robin DNS forwarder, and also be weird to implement behind load balancing.

Hey there,

I made a similar journey a few years ago. But I only have one home server and do not run my services in high availability (HA). As @non_burglar@lemmy.world mentioned, to run a service in HA, you need more than "just scaling up". You need to exactly know what talks when to whom. For example, database entries or file writes will be difficult when scaling up a service not ready for HA.

Here are my solutions for your challenges:

• No, you are not supposed to run kubectl apply -f for each file. I would strongly recommend helm. Then you just have to run helm install per service. If you want to write each service by yourself, you will end up with multiple .yaml files. I do it this way. Normally, you create one repository per service, which holds all YAML files. Alternatively, you could use a predefined Helm Chart and just customize the settings. This is comparable to DockerHub.
• If you want to deploy to a cluster, you just have to deploy to one server. If in your .yaml configuration multiple replicas are defined, k8s will automatically balance these replicas on multiple servers and split the entire load on all servers in the same cluster. If you just look for configuration examples, look into Helm Charts. Often service provide examples only for Docker (and Docker Compose) and not for K8s.
• As I see it, you only have to run a single line of install script on your first server and afterward join the cluster with the second server. Then you have k3s deployed. Traefik will be installed alongside k3s. If you want to access the dashboard of Traefik and install rancher and longhorn, yes, you will have to run multiple installations. Since you already have experience with Ansible, I suggest putting everything for the "base installation" into one playbook and then executing this playbook one.

Changelog:

• Removeing k3s install command. If you want to use it, look it up on the official website. Do not copy paste the command from a random user on lemmy ;) Thanks to @atzanteol@sh.itjust.works for bringing up this topic.

I use Kube everyday for work but I would recomend you to not use it. It's complicated to answer problems you don't care about. How about docker swarm, or podman services ?

Don't use kubernetes.