Deprecation of Docker Runtime in Kubernetes - No access to local docker socket

With us marching slowly towards end-of-life for Docker as a runtime environment in Kubernetes, and containerd turning out to be default for latest Kubernetes version on most cloud providers, I am thinking about the process of "chaincode image building and container creation" using the HLF peer. 

For HLF v1.4.x and HLF v2.x with internal builders, the chaincode containers could no longer be simply created with the help of `/var/run/docker.sock` file - as the access to it will be denied with the new `containerd` runtime in Kubernetes. 

I wanted to learn about how are we planning in supporting chaincode instantiation through peer (both, in HLF v1.4 or in HLF v2), once the old versions of Kubernetes reach end-of-life and existing users will be looking to upgrade to these latest Kubernetes versions.

With HLF v2.x external builders and chaincode as an external service, we can easily migrate to remove the dependency on usage of docker socket. That is definitely one of the ways!

Although, as it would be affecting all the HLF users to migrate from internal builders to chaincode as an external service. I consider that it might be simple, but it incurs cost in production stages and also multiple channels of communication if the setup is hosted on cloud compared to on-prem. 

I am not sure of the exact deadline we should be looking for from Kubernetes on this, but I think some sort of modification or highlight is required for sure - for everyone to be supported and migrated with ease.