Improved the Technical Overview description

Signed-off-by: Marcelo Amaral <[email protected]>

docs/README.md

@@ -1,9 +1,27 @@
 ## Technical Overview
 
-Kubernetes allows for extensions to its architecture in the form of custom
-resources: <https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/>.
-KubeVirt represents virtual machines as custom resources and manages changes
-to libvirt domains based on the state of those resources.
+Kubernetes allows for extensions to its architecture via
+[*custom resources*]( https://Kubernetes.io/docs/concepts/extend-Kubernetes/api-extension/custom-resources/),
+which add a new endpoint in the Kubernetes API that stores and retrieves a
+collection API objects of a certain kind. However, the *custom resources*
+by themselves only enable store and retrieve structured data. To add
+business logic and specific functionality into Kubernetes, it is necessary
+to use
+[*custom controllers*]( https://Kubernetes.io/docs/concepts/extend-Kubernetes/),
+which are clients of the Kubernetes API-Server that typically read an
+object's `.spec`, possibly do things, and then update the object's
+`.status`.
+
+KubeVirt uses CRDs, *controllers* and other Kubernetes features, to
+represent and manage traditional virtual machines side by side with
+containers.
+
+KubeVirt's primary CRD is the VirtualMachine (VM) resource, which contains
+a collection of VirtualMachineInstance (VMI) objects, which shares
+similarity with the Pod concept. A VMI represents a single virtualized
+workload that executes once until completion (i.e., powered off). In
+addition to the VMI, the key KubeVirt components are the virt-api, the
+virt-controller, the virt-handler, and the virt-launcher.
 
 ### Project Components