badLiveware

ArgoCD + Helm

But really any kind of reconciler, e.g. flux or argo with helm works very well. Helm is only used as a templating tool, i.e. helm template is the only thing allowed. It works very well and I've ran production systems for years without major issues.

I dont really understand how people have so much trouble with Helm, granted yaml whitespace + go templating is sometimes awful, it is the least bad tool out there that I have tried and once you learn the arcane ways of {{- its mostly a non-issue.

I would recommend writing your own charts for the most part and using external charts when they are simple, or well proven. Most applications you want to run arent that complicated, they are mostly a collection of environment variables, config files, and arguments.

If I could wish for a replacement of helm, it would be helm template with the chart implemented in a typed language, e.g. TypeScript, instead of go template but backwards compatible with go template.

Redis compatible projects with larger-than-memory support do exists, e.g. https://microsoft.github.io/garnet/docs/welcome/features#tie...

Source-available[1] is likely the closest commonly used term for it

[1] https://en.wikipedia.org/wiki/Source-available_software

Another option is running something like haproxy ingress in external mode on dedicated vms

https://www.haproxy.com/documentation/kubernetes/latest/inst...

Sure it does, I ran kube-vip[1](but there are many others, e.g. metallb) as my cloud controller, all it needs are valid static IPs/range/dhcp and it will assign these to LoadBalancer services(which you usually only need one of for your ingress) and it will either ARP or use BGP to route external traffic.

As for DNS records, external-dns[2] works perfectly as long as your DNS as some way to doing automatic updates.

1. https://kube-vip.io/

2. https://github.com/kubernetes-sigs/external-dns

Lazy pulling is already supported by a lot of container runtimes, most notably containerd with estargz

https://github.com/containerd/stargz-snapshotter/blob/main/d...

I am a fan of using renovate, and with docker images in particular since I can define my remote as

  FROM mcr.microsoft.com/dotnet/sdk:6.0@sha256:15c22c170650b8db2f6250547a2dc5341978b0647c6b21ef67768e628de614f3 AS build

and have renovate automatically merge digest updates, the sha256 hash, while having manually(or automatic) PRs for the tag target.

So a when upstream updates their tag I get a PR(which is automerged) that looks like so, this allows me to know when upstream has changed while still being able to target a broader version range, 6.0 in this case

  - FROM mcr.microsoft.com/dotnet/sdk:6.0@sha256:15c22c170650b8db2f6250547a2dc5341978b0647c6b21ef67768e628de614f3 AS build
  + FROM mcr.microsoft.com/dotnet/sdk:6.0@sha256:70b890cd12f73f8ad80061d242081b61da666bda7ec2d729113855a8b9410e1e AS build

The easier solution rather than managing your own OCI registry is likely to just pin the digest and have dependency update automation e.g. renovate update the digest while targeting a tag.

For example

  FROM mcr.microsoft.com/dotnet/sdk:6.0@sha256:70b890cd12f73f8ad80061d242081b61da666bda7ec2d729113855a8b9410e1e AS build

Where the tag is used by humans for targeting a tag while the digest locks it to a certain image version

Icelandic and old norse perhaps

Kubernetes using Kata containers[1] as a containerd[2] backend

[1] https://aws.amazon.com/blogs/opensource/kata-containers-1-5-...

[2] https://github.com/kata-containers/kata-containers/blob/main...

I believe that the government in Hamburg and the Bundeswehr are implementing(or has already) element and matrix.

https://element.io/pro/federation-collaboration

It's a lot faster than chocolatey, choco gets painfully slow with many packages due to being serial. Scoop is considerably faster

My company fixed this by making us use under dimensioned VMs for development. Unfortunately it has not fixed the issue.

It's for ASIC resistant currencies I believe