Exactly: a non-blacklisted IP with good reputation, correct mailname and valid PTR record is the foundation, ideally augmented with SPF. I've been running an e-mail service without DKIM and DMARC for many years without any delivery issues, only adding those very recently.
For this kind of decisions, why not simply keep notes as comments in the code? These can easily be added later, even 14+ years after the code was written. Then, when someone dives into the codebase to figure out why something was done this or that way, the answer is right there. No need to dive into (and scavenge, sometimes) VCS history.
There's also 'AX_APPEND_COMPILE_FLAGS' [1] (and its dependency 'AX_CHECK_COMPILE_FLAG' [2]), next to many other (related or unrelated) macros in the autoconf archive.
An 'easy' way to deploy a cluster could be using kubeadm. Then you'll need a CNI like Calico to get Pod networking up-and-running. However, you'll want to install a bunch of other software on said cluster to monitor it, manage logs,...
Given you're running on physical infrastructure, MetalK8s [1] could be of interest (full disclosure: I'm one of the leads of said project, which is fully open-source and used as part of our commercial enterprise storage products)
> first of all with k3s keeping a production cluster running is still pretty easy.
Fair enough. I'll admit I have no direct experience with K3s. There are, however, many K8s deployment systems out there which I would not consider 'production-ready' at all even though they're marketed that way.
> second you should always be ready to start from scratch, which is also pretty simple, because of terraform.
That may all be possible if your environment can be spawned using Terraform (e.g., cloud/VMWare environments and similar). If your deployment targets physical servers in enterprise datacenters where you don't even fully own the OS layer, Terraform won't bring much.
> a lot of people are scared of k8s but they did not even try. they prefer to maintain their scary ansible/puppet whatever script that works only half as good as k8s.
We've been deploying and running K8s as part of our on-premises storage product offering since 2018, so 'scared' and 'didn't try' seems not applicable to my experience. Yes, our solution (MetalK8s, it's open source, PTAL) uses a tech 'half as good' as K8s (SaltStack, not Ansible or Puppet) because you need something to deploy/lifecycle said cluster. Once the basic K8s cluster is up, we run as much as possible 'inside' K8s. But IMO K8s is only a partial replacement for technologies like SaltStack and Ansible, i.e., in environments where you can somehow 'get' a (managed) K8s cluster out of thin air.
My comment above did not come out of the blue, but based on real-world experience ;-) You may be interested in our MetalK8s project [1] which seems related to yours.
> Getting Kubernetes up and running isn't really the issue anymore, that's pretty easy to do. The tricky part is long term maintenance and storage.
This times 100. Deploying basic clusters is easy. Keeping a test/dev-cluster running for a while? Sure. Keeping production clusters running (TLS cert TTLs expiring, anyone?), upgrading to new K8s versions, proper monitoring (the whole stack, not just your app or the control-plane), provisioning (local) storage,... is where difficulties lie.
Not an Arrow expert at all, so I may be missing something, but I fail to understand the "The Science of Reading/Writing Data" section, or rather, its relevance to the article (and Arrow).
From what I could find, Arrow supports reading (writing?) data from (to?) memory-mapped files (i.e., memory regions created through mmap and friends). However, this has no relation to how the IO is being done, hence not related to access to IO devices using either IO ports, or memory mappings (DMA and such).
This section seems to be mixing up two fairly distinct concepts, i.e., talking about ways to access IO devices and transfer data to/from them (among which memory mapping is an option), where the memory mapping (mmap of files) as used by Arrow is something a little different.
Cases like this seem to confirm the approach LetsEncrypt took of only issuing certificates of a somewhat-short lifetime, which kind-of forces a user to fully automate the handling of certificates (monitoring expiration, taking measures to request a new cert in time, deploying the new cert,...).
The practice of issuing certificates with a (sometimes very) long lifetime, from one year and up, results in a situation where such automation is not strictly required, and complex bureaucratic processes can be put in place to replace certs, which becomes a major issue when 'emergency' revocations are necessary. I'd argue such bureaucratic processes don't even increase 'security', because in the end they rely on people performing manual operations (often with more rights granted than strictly required), whilst an automated system can be more easily vetted, tested, and locked down.
I'm not involved in the Phippy 'project' in any way (only got a copy of the books and some plastic version of the animals as a speaker here at KubeCon :-D).
I agree the wording may be a bit 'off' and providing a detail which doesn't necessarily add value or can cause confusion, so that would've been good feedback before the whole thing went to 'print' :)
As for the end user who shouldn't know about encoding: that's not entirely true. Thing is, when sending a Secret object into the API (as YAML or JSON), you need to pre-encode the secret value using base64 in this document (so it's not K8s doing this for you, indeed another source of confusion given the current wording). The reason being that the API being YAML/JSON-based could otherwise not be used to store non-UTF8 secret values (e.g. binary ones).
However, if you use 'kubectl create secret' instead of interacting with the API directly (or using 'kubectl create -f ...' with a YAML document as input, which is also 'interacting with the API directly' with some extras) then I believe the CLI will take care of this encoding for you, where required.
You assume it's meant to explain K8s to kids, or teach adults about it. I don't believe it's either, more of a gimmick for the existing Kubernetes community.
If an adult (or a kid, for that matter) wants to really learn about Kubernetes, its inner workings etc, there's plenty of documentation and literature available which does explain how Pods are scheduled, what Services are and how they're implemented, etc.
'secrets are base64 encoded at rest' means exactly what it says: a secret value is encoded using base64 in the Secret object 'document' that's stored in etcd. It doesn't say anything about at-rest encryption, and the Kubernetes community is well aware base64 doesn't provide any such guarantees.
However, if you want at-rest encryption (of data stored in etcd), we got you covered, if wanted way beyond only encrypting Secret objects! Some pointers:
I'm aware it doesn't use iptables, except to implement network policies, hence the reference.
Good call about the bridge usage, my bad, makes sense that's not being used given Calico is L3...