Yes, CaaS is very much a thing it means Container-Orchestration-as-a-Service. Kubernetes is the leading technology in this space.
The key to understanding the following progression is the concept of "-as-a-Service":
Dedicated → IaaS → CaaS → FaaS → PaaS → SaaS
It means you are paying either an internal or external team money to host a service onto which you deploy your business solution. Yes, you can use containers on top of a dedicated hardware service. You can use containers on-top of IaaS. Yet you have to look after the low-level concerns such as installing and patching the operating system. If you are simply renting VMs from a cloud provider you are not renting a container solution as a service.
When people talk about CaaS they usually mean “Container-Orchestration-as-a-service”. Examples include Amazon Elastic Kubernetes Service, Azure Kubernetes Service, and Google Kubernetes Engine, IBM Cloud Kubernetes Service and Alibaba Container Service for Kubernetes. There is a vast difference between deploying software onto a Kubernetes cluster that someone else set up, secured, then automated for you and having to configure a bunch of IaaS VMs to reliably run containers yourself. High-performance Kubernetes installations use specialist 'single purpose' operating systems such that the servers are more like appliances than typical VMs. The idea is that the cluster (both OS and Kubernetes software) can be security patched as a rolling upgrade without any downtime of the services hosted on the cluster.
History Lesson ;-)
The historic position around 2011 before Docker was released in 2013 would have been:
Dedicated → IaaS → PaaS → SaaS
In that, it is PaaS which, IMHO, is the vague classification that has changed over time with the rise of containers. Examples of early PaaS solutions that came before containers are the original Heroku, the original CloudFoundry, and early versions of RedHat Openshift. They were “DevOps platforms” before the term DevOps was invented. The original versions used some of the Linux techniques that containers later made famous, but it was an internal detail. The main marketing points made were two-fold. The first was developer productivity of having built-in CI/CD and the second was that the servers were easy to security patch and administer. The servers were treated like sheep and the vendor-supplied service packs to keep them secure.
The problems with the original PaaS concept was no standardisation, vendor lock-in, little portability, as well as proprietary tooling. They had embedded and proprietary build systems as well as proprietary configuration and deployment mechanisms. Opensource container orchestrators have revolutionised things by fixing those problems. The big open-source PaaS solutions such as OpenShift, CloudFoundry and Mesosphere now all support Kubernetes. Users no longer need to use a proprietary build and deploy pipeline nor propriety configuration mechanisms. They can use a vast number of different tools to build containers that they pushed up to any number of hosted container registries. They can then use the Kubernetes API to deploy into their chosen cloud provider. IMHO the original PaaS concept of “rapidly build, deploy and configure a web app” has standardised into CaaS as the main runtime.
if you want to see what you can do with CaaS checkout my blog on full automation of a start up.
I found the talks Stop Calling Knative Serverless! - Doug Davis very informative. At around 2:45 which compares PaaS, with CaaS, with FaaS. The talk introduces KNative and at the end around 32:07 compares KNative to PaaS, CaaS and FaaS. The presentation states that the Kubernetes definition of CaaS is rather bare-bones and missing a lot of "obvious" things if you are familiar with a PaaS. Both KNative and OKD (Openshift) are demonstrating that you can build another style of platform (PaaS, FaaS) on top of the bare-bones Kubernetes CaaS.