Adding it to my to-do list...

`emptyDir` (baked into Kubernetes) does use node storage. There are others that might use external storage for ephemeral volumes. Since storage is implemented through CNI drives, it can be anything and it depends on what your provider has (apart from those like `emptyDir` that are baked-in).

I would not call it like that. I think it's more of a base on top of which we or your vendor builds a platform. If you would make an analogy with operating systems, it would be more like a Kernel than an OS distribution. Kernel does not do much by itself but once you compile it and add a bunch of other things you get something like Ubuntu, RedHat OS, Suse, etc.

That would be using helmfile only for the initial installation of argo CD which would deal with all other apps (including future updates of itself). In such a case, I'm not sure why bother with helmfile and not simply run helm install.

Thanks for the fast reply! The issue I’m struggling with is how to make it obvious what the preferred order of install/applies are. Also, since Helm can’t handle installing to different namespaces, the dependencies are split in different folders. But it’s possible I’m coming at this the wrong way. I prefer Jsonnet, but we don’t use that at my current job.

Sync order can be problematic with gitops tools but mostly for Cards created by third party tools. You haven't mentioned that so I'm assuming that's not the your case. For most of other types of resources it should not matter. Kubernetes is asynchronous by nature and resources should get eventually consistent. Part of the reason we're using kubernetes is to avoid orchestration where we decide what is done first, what is second, and so on. The need to define the order of what is done and when it's done often happens when people try to apply the logic from before kubernetes to kubernetes.

@@DevOpsToolkit I guess you mean "Charts" :) And I'm mentioning it now, haha. To be specific when we bootstrap a cluster it's for things like External DNS, Istio, Cert Manager, Metrics Server, ArgoCD etc. So essentially only third party charts. While what you're saying is true, there are some exceptions, specifically w.r.t CRDs. As an example, you can't create a ClusterIssuer until you've applied the Cert Manager chart as that CRD won't exist before it. There are some other examples, where things can get stuck in a bad state due to ill-designed reconciliation loops etc. Granted, those are likely bugs, but it still happens. :) What I like, after a very shallow examination, with Helmfile is that what constitutes (in our case) a bootstrap is very explicitly defined. The question is, is it worth introducing another tool and dependency just for that. :) I really appreciate you taking the time! Merry Christmas!

Autocorrect keeps changing charts into cards... I honestly think that helmfile is a waste of time. It was great in the past and i used it a lot before we got argo CD and flux. Now it is only a distraction that will lead you to a wrong path. It is incompatible with gitops. Whatever you choose, don't choose to combine both.

I'm not sure I understood the question. Can you please elaborate?

Yes it can. That's what I used as one of the examples in the last video.

continued watching and funnily enough our exact question that we pondered all those years ago has been answered :)

Nobody cares about swarm any more. Docker gave up on it and sold it to mirantis. Mirantis bought it mostly to milk it's users a bit longer but is not investing into it either. So, you're using a project that is on life support and that's fine if it's doing what you need it to do just as long as you are not putting any investment into it. Do not put a single hour into swarm since that would be an hour wasted. Use it as-is. P.S. I loved swarm and placed all my bets into it back when it was not sure who will win. However, i had to realize that i lost and move on.

If you are referring to Goigle Cloud Run, it does not use kubernetes.

@DevOpsToolkit True. I remembered it incorrectly. It is knative compatible in its manifests as I understood it. So targeting it could be a good stepping stone to later deploy on k8s+knative 🤩

Yeah. Knative API, no matter whether self hosted on kubernetes or in Google, is closest to the right abstraction when apps are concerned. It became a bit bloated over time and i still prefer creating my own API but for those looking for a ready-to-go option is is the best we have. The problem, however, are day 2 operations if it's running in kubernetes. Unlike in Google, one would need to know all the underlying tech when running in kubernetes.

If you apply crossplane managed resources that match resources that already exist, crossplane will take control of them.

Have you tried Vitess?

@@DevOpsToolkit I haven't tried any mysql in kubernetes, I would usually run the mysql outside of the cluster. I'll definitely take a look at that though, thanks. I have been running the cnpg now for a couple of months after watching your previous video and am very impressed by it so far.

... Don't?

have you tried cnpg?

The Crunchy Data postgres operator is pretty solid too

I don't think I encountered that error. I had others that were caused by 2.x using a new yaml format. I can send you a sample yaml if that helps (it's for gcp).

@@DevOpsToolkit Don't you ever sleep? It seems like you're always online... The one I borrowed is below, adjusted to my path/keys: providers: google_secrets_manager: kind: google_secretmanager maps: - id: secrets path: projects/vfarcic keys: upbound-account: UP_ACCOUNT upbound-token: UP_TOKEN aws-access-key-id: AWS_ACCESS_KEY_ID aws-secret-access-key: AWS_SECRET_ACCESS_KEY github-user: GITHUB_USER

Not sure... I tend to use mostly PostgreSQL and, occasionally, mySQL which both have Kubernetes-native versions.

That would indeed be an issue for DBs that do not run multiple replicas. Still, that is no different from running it outside kubernetes. If you cannot update your VMs for whatever reason you need to keep it as whichever version it is. If you move such a workload to kubernetes, you can still keep kubernetes version fixed. It's not great but it's not worse than without kubernetes.

The release cadence is much more relaxed now. AWS and Azure (probably more) started to create LTS versions of kubernetes and just because there's a new kubernetes version, you don't have to upgrade directly. If you have a look into the version skew, you can see that the worker nodes can run 3 minor versions behind. So you could have everything else running v1.31.x and still keep your DB NG in version v1.28.X. When it's eol, just skip all those versions and repeat. To upgrade patch versions you don't even need to drain the whole node, it's enough to restart kubelet and kube-proxy in the new version.

Homelab != production ready

@gdelignieres never claimed that, just wanted to outline a very clean and simple way to do it.

I'm waiting for one of the features to graduate to GA. Once that happens i will do a new chapter/video. Unfortunately, i don't know when that will be.

It's coming... It'll probably be released the first or the second week of January.

I'm not sure how that could be fixed. Crossplane needs to know what the external name is. Otherwise, it cannot find it. Alternative is to fetch the non-deterministic name from the cluster and add it as `external-name` annotation into the manifest in Git. From there on, Argo CD or Flux would work. However, that can be very time demanding. What could be nice is to have some kind of an operator that would react when MRs are changed and push `external-name` annotation (when it differs from `metadata.name`) to Git. The problem is that I don't see how such an operator could be generic since those would need to be added to Claims which could be based on any schema.

@@DevOpsToolkit I think that the Syngit operator can solve this issue since it pushes the resource after the mutating webhooks execution. By creating a RemoteSyncer that just scope the Crossplane objects

I have it on my to-do list but did not yet have time to check it out. I'll go through it soon.

I'm triggering it (in that video) on ReplicaSets which is not perfect, but still okay in most of the cases (at least when using Deployments). That being said, I don't think that Argo Events is the right tool, but that it is the best we have (among many bad options).

Prometheus will fetch metrics from places where metrics exist (e.g. kubernetes API). Your app needs to be instrumented to provide those metrics so you do need to instrument it besides having those tools if you want app-specific metrics to be in Prometheus.