The Children's Illustrated Guide to Kubernetes
Wonderful illustrations. However, I'm going to dissent on its benefits as a guide. For me, this makes a common mistake in "simplified" technical writing: it assumes you already possess the knowledge that the author does. An example:<p><pre><code>  > Kubernetes uses labels as "nametags" to identify things.
  > And it can query based on these labels. Labels are open-
  > ended: You can use them to indicate roles, stability, or
  > other important attributes.
</code></pre>
Using nametags as an analogy is great, but what's the querying for? The image shows a bullet point "Can query based on these labels". What can query, and when does it query? Is it Kubernetes can query, or I can query? Why would I want to query? And what's an example of a role? How does one indicate stability? Is stability labeling when a container has been running unreliably recently, or does stability mean that it's a beta version, or something else? What is an example of an "other important attribute"?<p>And so on... many other knowledge assumptions are made. The primary deficiency is that it doesn't present the story in terms of a problem to be solved. It's a solution presented as if you already know the full context of the problem, which is its achilles heel.<p>I exaggerate a little here, but I'll recap the story with what essentially are the questions I have remaining if I don't make many knowledge assumptions after having read it a few times. I know I can apply my experience to make intelligent assumptions and fill in the gaps, but you did say this was a guide for children, and I don't expect them to have decades of experience. Here's my recap:<p>So some giraffe doesn't like its environment and decides to go floating on an ocean, eventually gets picked up by a ship captain, is thrown into a pod (apparently along with an imaginary other container I have to pretend doesn't exist), and has an unexplained fetish for cloning. Why would a giraffe want to clone itself? Then some tunnel opens up to the rest of the ship. Does this mean that the captain, who has a penchant for picking up random strangers in the ocean, has now given access to my stuff to everybody else riding on the ship? What if some of those other random strangers are malicious? This tunnel sounds like a bad idea. Why do I want to be discovered, or discover others? Then the giraffe gets a gift and stores it in a shared location. Why would other clones need access to a private gift? Does that mean the elephant, lion, and turtle hiding in the closet now have access to my gift too? I don't know or trust them. Then namespaces are introduced, ostensibly as a means to have privacy. But wait... I thought my container, or my pod was private. I used it to get away from the scary shared hosting, but it sounds like it's no different here. And what is a namespace? Is it related to the "Hello my name is ______" image that was used for labels? Maybe it labels groups of things together? I'm not sure how revision control system (rcs) fits into this. Maybe I can store multiple versions. At any rate, it shows that a namespace lets you keep secrets from each other. Oh, maybe this is a better place to store my gift than a volume. Volumes can be read by any pod (and I don't want that pesky lion and turtle reading my things) so I'll keep it secret in a namespace... somehow. I hope my gift isn't too large to store it there. I'm told that a namespace isolates me from the rest of the cluster, but this is the first time the word cluster is introduced other than the original, highly technical explanation which resulted in the "Huh?" response that triggered this children's story.<p>Again, nice illustrations and a good effort. But I'm left confused about what all this stuff is because I don't know the answers to some of the assumptions you've made. I still have no idea why a PHP app with only one page needs all this complexity. It's just one page, right?