plural VS enhancements

I’ve just recently found out about plural. Perhaps give them a try? I think they have a cool idea for quickly deploying an ELT infrastructure. Perhaps check them out?

No wonder the GitHub license gizmo doesn't know what license this is, there's a lot of "if statements" in it: https://github.com/pluralsh/plural/blob/master/LICENSE

That aside, I wonder why they went with ZeroSSL and had to include this "watch out for the 24 hour lag" in their docs? https://docs.plural.sh/getting-started/getting-started#build...

We’ve been building Plural’s server tier in pure elixir for a year now, and recently found the need to implement a cloud shell experience. It was a pretty amazing case study in the power of phoenix channels and the BEAM’s actor model for implementing something that otherwise could be kind of a pain, and thought the broader community would find it interesting as well. High level the takeaways were

You can check our repo here: GitHub - pluralsh/plural: Multi-cloud, multi-prem application deployments for kubernetes in minutes.🚀 14 (there’s more cool things there you might find interesting, including a full GraphQl API implementation new absinthe devs could reference)

For those of you who are unfamiliar with our product, Plural is an open-source DevOps platform that simplifies deploying open-source software on Kubernetes. Even if you aren’t a power user of Kubernetes, you likely are familiar with or know a developer who mentions how steep the learning curve is for Kubernetes. For starters, you need to leverage a large list of tools to deploy and manage a Kubernetes cluster properly.

If you like what we are doing and want to contribute to our open source product, check out our Github repository for more information

0 is not the request we've defined. And that makes sense. Memory QoS has been in alpha since Kubernetes 1.22 (August 2021) and according to the KEP data was still in alpha as of 1.27.

Note: There's actually a Structured Authentication Config established via KEP-3331. It's in v1.28 as a feature flag gated option and removes the limitation of only having one OIDC provider. I may look into doing an article on it, but for now I'll deal with the issue in a manner that should work even with a bit older versions versions of Kubernetes.

Kubernetes supports a skew policy of n+2 between API server and kubelet. This means if your CP and DP are both on 1.20, you could upgrade your control plane twice (1.20 -> 1.21 -> 1.22) before you need to upgrade your data plane. And when it comes time to upgrade your data plane you can jump from 1.20 to 1.22 to minimize update churn. In the future, this skew will be opened to n+3 https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/3935-oldest-node-newest-control-plane

KEP: https://github.com/kubernetes/enhancements/tree/master/keps/...

TLDR: Introduce a restartPolicy field to init containers and use it to indicate that an init container is a sidecar container. Kubelet will start init containers with restartPolicy=Always in the order with other init containers, but instead of waiting for its completion, it will wait for the container startup completion.

So, until now, a sidecar container was just the idea of running helper containers in you Kubernetes pod that were 'helpers' for something: connection to databases or vpns, mesh networking, pulling secrets or config, debugging... But they didn't have special status, they were just regular containers in your pod.

This sometimes posed some problems because they weren't available for the full life cycle of the pod, notably on the init process. So if your init containers needed secrets, connections, networking... that was being provided via a sidecar container, you were going to have a hard time.

With this change, among other things, sidecars containers are going to be available for the whole life cycle of the pod.

There are other implications, probably, but I still haven't finished reading the KEP [0]. Check it out, and there you'll find its motivation and several interesting examples.

  0: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/753-sidecar-containers

The KEP (Kubernetes Enhancement Proposal) is linked to in the PR [1]. From the summary:

> Sidecar containers are a new type of containers that start among the Init containers, run through the lifecycle of the Pod and don’t block pod termination. Kubelet makes a best effort to keep them alive and running while other containers are running.

[1] https://github.com/kubernetes/enhancements/tree/master/keps/...

full Kubernetes Enhancement Proposal: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/753-sidecar-containers/README.md

If further interested, I may recommend checking out the KEP. I love how they document the decision making, and all these edge cases :).