nicolast

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.

I am indeed. Feel free to reach out, would be happy to learn from the approach you took.

You may be interested in https://discourse.haskell.org/t/towards-an-actor-framework-f..., then!

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.

GoPro would like a word.

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.

[1] https://www.gnu.org/software/autoconf-archive/ax_append_comp...

[2] https://www.gnu.org/software/autoconf-archive/ax_check_compi...

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)

[1] https://github.com/scality/metalk8s

> 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.

[1] https://github.com/scality/metalk8s

> 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.

> How to distribute secrets if not by env? (which I agree! Honest question)

You'll want to use BuildKit (`docker buildx`), see https://docs.docker.com/develop/develop-images/build_enhance...

[edit] My bad, that works for secrets needed at build time, not at runtime of course.

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.

Not all services exposed to the outside are HTTP(S).

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.

There's https://github.com/openstack/ansible-hardening and https://github.com/dev-sec/ansible-os-hardening

> If you verify that your hardware is unstable, how can you expect the software not to fail and corrupt data?

No such thing as 'stable hardware' at scale.

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.

See https://kubernetes.io/docs/concepts/configuration/secret/

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:

- https://kubernetes.io/docs/tasks/administer-cluster/encrypt-...

- https://kubernetes.io/docs/tasks/administer-cluster/kms-prov...

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...

Exactly.

As mentioned here, the article doesn't specify whether the Calico setup uses ipip or not which could have a measurable impact.

In the Calico-without-ipip case, you're basically comparing host networking (let's assume with some iptables enabled) with host+iptables+bridge networking (yes, there may be more iptables rules involved). Let's assume the impact of iptables is the same between both, then it'd be interesting to measure the impact of the Linux bridge being used. As a colleague of mine mentioned, this may be barely noticeable on a 10Gb interface, but could be on faster networks. How about running these tests on a 20Gb or 40Gb network? These are quite common in datacenter networks, which is where you'll be using these CNIs (unlike GKE, EKS,... where you can integrate with the 'native' SDN).

Finally, I'd be interested to get some results when using the macvlan CNI plugin (though then one loses network policy support, sadly enough :( )