After playing with docker landscape for several months, I still found it is really counter intuitive to use Kubernetes Pod. I have not encountered any use case where pod is more natural a fit than container. When I am asked to use a Pod, I usually just use a single container Pod. I am trying to do a demo showcasing the strength of pod concept, but I just couldn't figure out a non-trival use case.
In my demo, I started a server pod with two service container listening on different port, one for transcribe letters to upper case, and one for transcribe letters to lower case. Then I have a client pod with two client containers talking to each server container... This use case seems really forced, I don't see why I need to use the Pod concept.
I have read through lots of tutorials and docs, and they all just touch on WHAT is a pod, without a convincing use case of WHY we must use pod... Am I missing something? What is a solid use case for using a Pod concept? Thanks.
Edit: To be specific, suppose there are two services A and B that requires co-location and shared network stack, and this is a natural fit for Pod concept. What is the advantage of using the Pod (with two collocated containers running service A and service B) compared to having service A and B running in the same container, which guarantees the collocation and shared network stack? Is there a rule of thumb for the granularity?
My original question is to find out such service A and service B that requires co-location and shared network stack. Thanks to Jared and Robert for the pointers, and I will dig through these use cases.
Jared pointed to some good examples in his comments above. As Brian Grant mentioned in the linked github issue, pushing log data and loading data are the most common uses inside of Google.
For a concrete example in the Kubernetes repository, you can look at the definition for the DNS cluster add-on. It uses a pod to co-locate a DNS server (skyDNS), local storage using etcd, and a simple program to pull Kubernetes API objects down, convert them, and put them into local storage. Rather than building a new custom DNS server, this pod leverages an existing DNS server and add some customization to it to make it aware of the cluster environment. Since all of the containers are in a pod, they can rely on localhost networking to communicate and don't need any form of sophisticated service discovery.