1. #docker
  2. Topics

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

Chris Gabriel <alaskadd@...>
 

From what I have found so far in a limited bit of looking into the effects of the deprecation when it actually happens is that it will cause a breaking change to the Dind container.  Although there is an alternative, I find it may be cleaner to continue on the path I was going down to use the launcher and then change the CRI runtime from Docker to Containerd for my implementation.  



Disclaimer: I have not tested this yet but will post results in this thread.

On Apr 28, 2021, at 3:50 AM, Gari Singh <gari.r.singh@...> wrote:

Using DinD in the short term should work ok, but be aware that you will need to run the Dind container with elevated privileges which can be problematic in many environments.  The best course of action is to plan for an upgrade and use a launcher.

On Tue, Apr 27, 2021 at 3:52 PM Chris Gabriel <alaskadd@...> wrote:
Also, I forgot to mention that when running on Kubernetes I set the environment variable for the CORE_VM_ENDPOINT to “http://localhost:2375” and not unix:///var/run/docker.sock 

There is more detail on this if you examine the CORE VM ENDPOINT section of core.yaml



On Apr 27, 2021, at 2:31 PM, Chris Gabriel via lists.hyperledger.org<alaskadd=gmail.com@...> wrote:

Hi Ramesh,

I am still looking into the ramifications of the Deprecation of Docker Runtime in Kubernetes for my network.  I’ll post what I find out.

As far as your second question, you can do either.  I am currently running HLF 2.3 on Kubernetes 1.20.2 with dind and all works fine.  I plan on migrating this to run the external chaincode builders in the near future however.  

Hope this helps,
Chris

On Apr 27, 2021, at 1:39 PM, ramesh.bobbala1990@... wrote:

Hello Everyone, 

 

Any further updates on this issue? I am facing the same issue, currently using HLF 1.4 version on Kubernetes 1.18 version and trying to upgrade kubernetes version to 1.19 version. 

Which is the best way to implement HLF setup on kubernetes latest versions.
1. Upgrading to 2.x versions using external chaincode builders and chaincode as an external service
2. Or  via dind (Docker-in-Docker)

 





Gari Singh
 

Using DinD in the short term should work ok, but be aware that you will need to run the Dind container with elevated privileges which can be problematic in many environments.  The best course of action is to plan for an upgrade and use a launcher.


On Tue, Apr 27, 2021 at 3:52 PM Chris Gabriel <alaskadd@...> wrote:
Also, I forgot to mention that when running on Kubernetes I set the environment variable for the CORE_VM_ENDPOINT to “http://localhost:2375” and not unix:///var/run/docker.sock 

There is more detail on this if you examine the CORE VM ENDPOINT section of core.yaml



On Apr 27, 2021, at 2:31 PM, Chris Gabriel via lists.hyperledger.org <alaskadd=gmail.com@...> wrote:

Hi Ramesh,

I am still looking into the ramifications of the Deprecation of Docker Runtime in Kubernetes for my network.  I’ll post what I find out.

As far as your second question, you can do either.  I am currently running HLF 2.3 on Kubernetes 1.20.2 with dind and all works fine.  I plan on migrating this to run the external chaincode builders in the near future however.  

Hope this helps,
Chris

On Apr 27, 2021, at 1:39 PM, ramesh.bobbala1990@... wrote:

Hello Everyone, 

 

Any further updates on this issue? I am facing the same issue, currently using HLF 1.4 version on Kubernetes 1.18 version and trying to upgrade kubernetes version to 1.19 version. 

Which is the best way to implement HLF setup on kubernetes latest versions.
1. Upgrading to 2.x versions using external chaincode builders and chaincode as an external service
2. Or  via dind (Docker-in-Docker)

 


Chris Gabriel <alaskadd@...>
 

Also, I forgot to mention that when running on Kubernetes I set the environment variable for the CORE_VM_ENDPOINT to “http://localhost:2375” and not unix:///var/run/docker.sock 

There is more detail on this if you examine the CORE VM ENDPOINT section of core.yaml



On Apr 27, 2021, at 2:31 PM, Chris Gabriel via lists.hyperledger.org <alaskadd=gmail.com@...> wrote:

Hi Ramesh,

I am still looking into the ramifications of the Deprecation of Docker Runtime in Kubernetes for my network.  I’ll post what I find out.

As far as your second question, you can do either.  I am currently running HLF 2.3 on Kubernetes 1.20.2 with dind and all works fine.  I plan on migrating this to run the external chaincode builders in the near future however.  

Hope this helps,
Chris

On Apr 27, 2021, at 1:39 PM, ramesh.bobbala1990@... wrote:

Hello Everyone, 

 

Any further updates on this issue? I am facing the same issue, currently using HLF 1.4 version on Kubernetes 1.18 version and trying to upgrade kubernetes version to 1.19 version. 

Which is the best way to implement HLF setup on kubernetes latest versions.
1. Upgrading to 2.x versions using external chaincode builders and chaincode as an external service
2. Or  via dind (Docker-in-Docker)

 


Chris Gabriel <alaskadd@...>
 

Hi Ramesh,

I am still looking into the ramifications of the Deprecation of Docker Runtime in Kubernetes for my network.  I’ll post what I find out.

As far as your second question, you can do either.  I am currently running HLF 2.3 on Kubernetes 1.20.2 with dind and all works fine.  I plan on migrating this to run the external chaincode builders in the near future however.  

Hope this helps,
Chris

On Apr 27, 2021, at 1:39 PM, ramesh.bobbala1990@... wrote:

Hello Everyone, 

 

Any further updates on this issue? I am facing the same issue, currently using HLF 1.4 version on Kubernetes 1.18 version and trying to upgrade kubernetes version to 1.19 version. 

Which is the best way to implement HLF setup on kubernetes latest versions.
1. Upgrading to 2.x versions using external chaincode builders and chaincode as an external service
2. Or  via dind (Docker-in-Docker)

 

ramesh.bobbala1990@...
 

Hello Everyone, 

 

Any further updates on this issue? I am facing the same issue, currently using HLF 1.4 version on Kubernetes 1.18 version and trying to upgrade kubernetes version to 1.19 version. 

Which is the best way to implement HLF setup on kubernetes latest versions.
1. Upgrading to 2.x versions using external chaincode builders and chaincode as an external service
2. Or  via dind (Docker-in-Docker)

 

Hakan Eryargi
 

Hi Chintan,

It's still possible to use internal builders with containerd runtime in Kubernetes. This is achievable via dind (Docker-in-Docker). 

Actually our Helm charts are supporting this since a while. See this commit: 

It's only a simple setting:
--set peer.docker.dind.enabled=true

Tested again on Azure AKS, Kubernetes version: v1.19.6

We are attaching a sidecar Docker container to peer pod, but this is not necessary. Docker container can reside in a separate pod and can be shared by multiple peers. Actually Docker daemon can even run outside of Kubernetes, as long as peer can access it through TCP. 

A small correction btw, using host's docker.sock is not dind. Dind is running a Docker daemon inside a Docker container.

Cheers,
Hakan


On Tue, Jan 19, 2021 at 2:15 PM <chintanr97@...> wrote:
Correct! 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!

Apart from this, I wanted a generic call from HLF maintainers on this topic - 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.

Regards,
Chintan Rajvir

chintanr97@...
 

Hi HLF maintainers,

I have also raised a related JIRA request. It would be really helpful to get your feedback in understanding the plan of support for HLF v1.4.x as well HLF v2.x (chaincode as an internal service) - as this would be breaking change for the people to completely move to support just chaincode as an external service.

Regards,
Chintan Rajvir

chintanr97@...
 

Correct! 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!

Apart from this, I wanted a generic call from HLF maintainers on this topic - 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.

Regards,
Chintan Rajvir

Alexandre Pauwels
 

Chintan,
HLF 2.x introduced external chaincode builders and chaincode as an external service. With minimal changes to your chaincode package, you can deploy your chaincode as a separate pod within a k8s cluster exposing a port that your peer is then instructed to communicate with for chaincode execution. No more need to build and run chaincode with a dind container. We just made the switch and it was fairly painless.

Alex


On Tue, Jan 19, 2021, 12:56 <chintanr97@...> wrote:
Hi Team,

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.

Regards,
Chintan Rajvir 

chintanr97@...
 

Hi Team,

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.

Regards,
Chintan Rajvir 

1 - 10 of 10