k8spatterns/examples

Examples for "Kubernetes Patterns - Reusable Elements for Designing Cloud Native Applications", Second Edition

examples's Issues

EnvVar Configuration (v2)

Create PDF document with all instructions.

Add a kubernets-patterns-examples.adoc top-level document which includes the instructions from each pattern.
Also create a CircleCI job for creating the PDF (and maybe other formats). This PDF should be committed, too.

Singleton Service (v2)

Declarative Deployment (v2)

Immutable Configuration (v2)

Problems running PredictableDemands on Macbook Pro M2

I ran into a number of issues getting the foundational/PredictableDemands working.

1. The random-generator application didn't work with the Mac architecture. I had to perform a multi-architecture build with buildx and then host the image in my own DockerHub account, which meant that I then had to update all of the images in the yml files to refer to my image.

This is what worked for me though there are probably other ways to solve this. You may need to support other architectures.

docker buildx create --use
docker buildx build --platform linux/amd64,linux/arm64 --push -t /random-generator:1.0 .

2. On the Mac I could not use hostPaths that start at the root as Mac now has the root path as read-only. So I had to create a separate host path and then change the hostPath in yml files from /example, /logs, etc. to my hostpath.

3. The generator application was returning a 500 server error with both pod.yml and deployment.yml. After some research I added the following spec above the app spec in deployment.yml and then it started to work. I think that it started working as a side effect as I was unable to properly debug the issue. Root cause is still a mystery to me.

spec:
containers:

• command:
  • "tail"
  • "-f"
  • "/dev/null"

Batch Job (v2)

/opt/random-generator-ready not there

Hi, the published images don't have the /opt/random-generator-ready file causing some of the labs to behave odd.

I built my own images and the file is there.

Ambassador (v2)

Init Container (v2)

Network Segmentation (v2)

Errata: Pod eviction on the Kubelet

Page 19, section on "Best-Effort"

It is not necessarily 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".

Sorry for being nitpicky here :)

IIU the code base correctly, this is what happens:

// rankMemoryPressure orders the input pods for eviction in response to memory pressure.
// It ranks by whether or not the pod's usage exceeds its requests, then by priority, and
// finally by memory usage above requests.
func rankMemoryPressure(pods []*v1.Pod, stats statsFunc) {
	orderedBy(exceedMemoryRequests(stats), priority, memory(stats)).Sort(pods)
}

https://github.com/kubernetes/kubernetes/blob/f780ac028b444ed15d03de755c12fcf84c783286/pkg/kubelet/eviction/helpers.go#L667

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

Right, it depends and thus a burstable pod with the same priority as a best-effort pod, but higher mem usage ratio above requests, would be evicted first.

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 *)?

Yes. this strikes a good balance without misleading the reader.

Same goes for this discussion on page 21:

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

Configuration Resource (v2)

Daemon Service (v2)

Process Containment (v2)

Errata: Distinct between node capacity and node allocatable

This is a copy over from the errata page to allow for better discussions:

Printed edition, Page 19 1st paragraph:

Speaking of "capacity" in the paragraph, it might be worth pointing out that this is allocatable capacity on the node, not node_capacity. Also a hint that InitContainers contribute to resource requirements (and thus scheduling) would be nice.

Note from the Author or Editor:
Hi Michael,

thanks a lot for your feedback. I'm not 100% sure what you mean with node_capacity in "this is allocatable capacity on the node, not node_capacity." Do you refer to a specific resource field ?

I agree, that your comment that init containers resource requirements should be mentioned here. We have a detailed explanation of resource requirements for init-containers in the"Init Container" pattern (i.e. the top paragraph on p. 127), but we should mention that here for sure, too.

... roland

+1 on the InitContainer.

Regarding node allocatable vs node capacity: minor detail, but worth mentioning I think (correctness and clarity). For scheduling and placement, not the node's capacity but allocatable resources are used -> https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable

Automated Placement (v2)

Periodic Job (v2)

Finish and test ElasticScale example

The Elastic Scale example has been done conceptually, but is still missing a working test run.

Errata: At-most-once guarantees for StatefulSets

Page 95 in the printed book, last paragraph:

"When a node fails, it schedules new Pods on a different node unless Kubernetes can confirm that the Pods (and maybe the whole node) are shut down."

I think, corresponding with the "at most once" guarantee of stateful sets described in the chapter, this should read:

"When a node fails, it does not schedule new Pods on a different node unless Kubernetes can confirm that the Pods (and maybe the whole node) are shut down."

Revisit license and usage terms

Health Probe: http://localhost:8080/toogle-live endpoint does not work

$ curl -s http://localhost:8080/toogle-live
Handling connection for 8080
{"timestamp":"2023-01-12T11:57:58.043+0000","status":404,"error":"Not Found","message":"No message available","path":"/toogle-live"}

same isse for toogle-ready:

$ curl http://localhost:8080/toogle-ready
{"timestamp":"2023-01-12T12:03:56.413+0000","status":404,"error":"Not Found","message":"No message available","path":"/toogle-ready"}

Check that "More Information" section is complete on every pattern

Also, verify that a self-link is added, so that it appears in a collected document.

Write install and running instructions

For some patterns, the instructions for how to run the examples are missing

• Daemon Service
• Singleton Service
• Service Discovery
• Init Container
• Ambassador
• Adapter
• Configuration Resource
• Stateful Service
• Elatic Scale

Stateless Service (v2)

Predictable Demands (v2)

Self Awareness (v2)

Controller (v2)

Health Probe (v2)

Sidecar (v2)

Stateful Service (v2)

Adapter (v2)

Managed Lifecycle (v2)

Configuration Template (v2)

Secure Configuration (v2)

Operator (v2)

Service Discovery (v2)