Merge pull request #85 from cgwalters/explain-podman-alignment

README.md: Elaborate on relationship with podman and kube

Author: cgwalters

README.md

@@ -103,6 +103,38 @@ preserving state.
 
 ## Relationship with other projects
 
+### Relationship with podman
+
+It gets a bit confusing to talk about shipping bootable operating systems in container images.
+Again, to be clear: we are reusing container images as:
+
+- A build mechanism (including running *as* a standard OCI container image)
+- A transport mechanism
+
+But, actually when a bootc container is booted, podman (or docker, etc.) is not involved.
+The storage used for the operating system content is distinct from `/var/lib/containers`.
+`podman image prune --all` will not delete your operating system.
+
+That said, a toplevel goal of bootc is alignment with the https://github.com/containers ecosystem,
+which includes podman.  But more specifically at a technical level, today bootc uses
+[skopeo](https://github.com/containers/skopeo/) and hence indirectly [containers/image](https://github.com/containers/image)
+as a way to fetch container images.
+
+This means that bootc automatically also honors many of the knobs available in `/etc/containers` - specifically
+things like [containers-registries.conf](https://github.com/containers/image/blob/main/docs/containers-registries.conf.5.md).
+
+In other words, if you configure `podman` to pull images from your local mirror registry, then `bootc` will automatically honor that as well.
+
+The simple way to say it is: A goal of `bootc` is to be the bootable-container analogue for `podman`, which runs application containers.  Everywhere one might run `podman`, one could also consider using `bootc`. 
+
+### Relationship with Kubernetes
+
+Just as `podman` does not depend on a Kubernetes API server, `bootc` will also not depend on one.
+
+However, there are also plans for `bootc` to also understand Kubernetes API types.  See [configmap/secret support](https://github.com/containers/bootc/issues/22) for example.
+
+Perhaps in the future we may actually support some kind of `Pod` analogue for representing the host state.  Or we may define a [CRD](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) which can be used inside and outside of Kubernetes.
+
 ### Relationship with rpm-ostree
 
 Today rpm-ostree directly links to `ostree-rs-ext`, and hence