Before we dig into these items, it makes sense to step back and consider the larger concept of anti-fragility, which Nassim Nicholas Taleb discusses in his book Antifragility.

There are a number of key concepts that are important to reinforce as we cope with the complexity of the Kubernetes system, and in how we leverage the greater Kubernetes ecosystem in order to survive and strive.

First, redundancy is key. In order to cope with system failure across the many layers of a system, it's important to build redundant and failure tolerant parts into the system. These redundant layers can utilize algorithms such as Raft consensus, which aims to provide a control plane for multiple objects to agree in a fault-tolerant distributed system. Redundancy of this type relies on N+1 redundancy in order to cope with physical or logical object loss.

We'll take a look at etcd in a bit to explore redundancy.

Second, triggering, coping with, exploring, and remediating failure scenarios is key. You'll need to forcefully cause your Kubernetes system to fail in order to understand how it behaves at the limit, or in corner cases. Netflix's Chaos Monkey is a standard and well-worn approach to testing complex system reliability.

Third, we'll need to make sure that the correct patterns are available to our systems, and that we implement the correct patterns in order to build anti-fragility into Kubernetes. Retry logic, load balancing, circuit breakers, timeouts, health checks, and concurrent connection checks are key items for this dimension of anti-fragility. Istio and other service meshes are advanced players in this topic.