Errata

It is not true that best-effort pods are evicted before other classes, i.e. burstable. The memory pressure rank (and eviction) logic has changed since v1.9: https://github.com/kubernetes/kubernetes/blob/da31c50da191ae1c055069b936d9e549741e3e8a/pkg/kubelet/eviction/helpers.go#L667 Pods with high resource consumption above requests will be evicted first, which not necessarily implies they're best-effort. E.g. a burstable pod with low requests but high mem usage will be evicted first: https://github.com/kubernetes/kubernetes/blob/da31c50da191ae1c055069b936d9e549741e3e8a/pkg/kubelet/eviction/helpers.go#L524

Note from the Author or Editor:
Thanks for the hint! I'm not 100% sure, whether the statement that 'best-effort' QoS container (i.e. those with no request limits) are not also considered to be evicted first, as according to https://github.com/kubernetes/kubernetes/blob/7b8c9acc09d51a8f6018eafc49490102ae7cb0c4/pkg/kubelet/eviction/helpers.go#L583 every current memory value is higher than the initValue (== 0 bytes). That said, I'm not super intimidated with the K8s source, so not sure what the decision criteria are when there are multiple pods exceeding their resources. Is it is like that the pod which exceed requests the *most* are evicted first? In that case, wouldn't a request value of 0 be a high-probability candidate for this criteria? Of course, that depends on the absolute values, too (e.g. having a request of 1 MB and limits 2 GB, and having an actual value of 1 GB put higher memory pressure on it as a best-effort Pod with the actual usage of 100 MB). Do you think it's a valid simplification to still say the best-effort Pods are the one which is *most likely* killed the first? (or *with a high probability *)? The purpose of this QoS categorization in the context of the book is to give the user a rough guideline of what to chose without knowing the super gory details. Here our intention was also to highly recommend to introduce limits in any case. I totally agree though, that we should not use a normative statement like "always killed first". --- Soften the wording a bit, but for a second edition which should rewrite that section and possibly add more details.

Related to my previous comment on QoS and eviction, the Kubelet eviction logic has changed from QoS only to more complex since v1.9: 1) usage > requests 2) priority 3) mem usage compared to requests https://github.com/kubernetes/kubernetes/blob/da31c50da191ae1c055069b936d9e549741e3e8a/pkg/kubelet/eviction/helpers.go#L667

Note from the Author or Editor:
Confirmed that eviction policy is more complicated than QoS. Having requests set to "0" sets condition 1) for sure to 0, and for 3) the delta is potentially also much larger (for the same image) We definitely should expand on this section and e.g. mention also that priority has a critical influence, i.e. to decided between two pods, both exceeding their requests (which is always the case for a pod with requests == 0, i.e. "Best Effort" QoS pods).

These diagrams would be a more clear if you add a vertical line to show when the release process starts and stops. This will make the whole section more clear. Also the diagram for canary release is wrong. At the end of the release the new release version line should go up and the old version should go down. Maybe you need to highlight a manual step that is required in the diagram. But as the diagram stands we never complete the release

Note from the Author or Editor:
Thanks for your feedback, highly appreciated ! I agree, that an additional indicator for the actual beginning of the release is useful, but for this type of schematic diagram, the intention was to be as simple as possible/helpful and not to confuse with too many details. Our hope is that people can infer that point in time, but you are right, and an additional indication might be helpful. wrt/ to the canary release I tend to disagree though. Actually it depends on your definition of a "canary release" really. For us the end result of a canary release is a traffic split between the old and the new version, with the new version usually getting only a small fraction of the traffic (e.g. 5/95). This is because you will keep that state for quite some time to measure the impact of the new release for a small user group. The final rollout to the new release (100/0) or the rollback to the old release (0/100) is an extra step that is not part of the initial canary release (i.e. you have to do an additional configuration for this to happen). So from this perspective, we believe the diagram reflects this first, initial 'canary release' step. As mentioned, it's really how you define a canary release, whether you include both steps (but then also stretch the time-scale when the experimentation happens which is much longer than the initial rollout and can not be reflected easily in this diagram) or whether you describe this as two separate steps. I will add a more detailed explanation to the text to make clear how we define the 'canary release'. Thanks for the heads up! Edited: I just saw that our explanation in this chapter for the "canary release" does indeed not fit the diagram. So we should either adapt the description, or, as suggested, the diagram itself.

The line says "Also keep in mind that if containers are running on a node that is not managed by kubernetes, reflected in the node capacity calculations by kubernetes." I believe you are missing 'the resources used by these containers are not ' after the comma. So it becomes "Also keep in mind that if containers are running on a node that is not managed by kubernetes, the resources used by these containers are not reflected in the node capacity calculations by kubernetes."

Note from the Author or Editor:
Correct, the sentence doesn't make sense as-is and missing the part that you mention.

The third numbered point says "Two pods members in the StatefulSet named ng-0 and ng-1" It should say "Two pods members in the StatefulSet named rg-0 and rg-1" According to yml shown in Example 11-1. Looking at metadata.name

Note from the Author or Editor:
Correct it needs to 'rg-0' and 'rg-1' in the callout for this example.

In the section, "Internal Service Discovery" it says, "As soon as we create a Deployment with a few replicas, the scheduler places the Pods on the suitable nodes, and each Pod gets a *cluster IP* address assigned before starting up.". This should read, "...each Pod gets a *Pod IP* address...", not a cluster IP.

Note from the Author or Editor:
Thanks a lot for the feedback! (and sorry for the delayed response) With 'cluster IP address' we mean a 'cluster-internal IP address' that is within the cluster's private network and not reachable from the outside. It's not the IP of the cluster itself (which IMO doesn't make much sense as a cluster itself does not has an IP address, except one would refer to the cluster's entry point (ingress controller/load balancer) as the cluster's IP. But you are right, 'cluster IP ' might be misleading, so we are going to reword this to 'cluster-internal IP address'.

I'm referring to the More Information section of the Adapter pattern. The second link titled The Distributed System Toolkit: Container Patterns for Modular Distributed System Design points to a private YouTube video https://www.youtube.com/watch?v=Ph3t8jIt894

Note from the Author or Editor:
Thanks a lot for the heads up ! The visibility of the video must have changed after the book has been released. I removed the link from the chapter, but we are looking for a better way of collecting and maintaining those links in the future as they are quite volatile and can get stale easily. The idea is to maintain those links at https://github.com/k8spatterns/examples but we are not there yet (and tbh it has not a big priority yet).

It is said: The configuration in Example 19-1 that is mounted as a volume results in two files ..." I think it should say four files instead (EXTRA_OPTIONS and SEED are not being considered...by mistake)

Note from the Author or Editor:
Thanks for the heads up. You are absolutely right, it should be four files which are mounted. I'm going to adapt this according. Book updated.

In the diagram, for the box labelled Application container the folder is value wrong. It currently says '/var/config/ but it should say '/config'. This is based on the text in the previous paragraph and yml code in Example 20-6 under containers.volumeMounts.mounthpath

Note from the Author or Editor:
The image does not match the example, that is a correct observation. I'm going to fix the example (to point to /var/config) as this the make it also clear that the mount paths do not have to be the same.

"which influences where the managing Pods will be scheduled": Should be either "where the *managed* Pods will be scheduled" or just "where the Pods will be scheduled" ---- Fixed in source (2019-12-12)