Open gesker opened 6 months ago
Maybe an obvious question to ask, but wasn't docker deprecated by k8s a long time ago? Is it worth it worrying about something deprecated not working properly?
Just dockershim not docker as a management environment. Integrating with an application that is bundled with its UI in “docker desktop” and uses dockerd environment. For support - and development in general - it is much easier to have a single container engine/toolkit than multiple. In this case much less friction for the end user.
That being said I do hope there is a “—podman” flag added. Next project is a similar scenario but “podman” user facing application instead of docker. Perhaps just a socket endpoint change on that one will be enough.
So not so much dockershim as much as the rest of the docker product environment.
On Wed, Feb 21, 2024 at 01:57 Jairo Llopis @.***> wrote:
Maybe an obvious question to ask, but wasn't docker deprecated by k8s a long time ago https://kubernetes.io/blog/2020/12/02/dockershim-faq/? Is it worth it worrying about something deprecated not working properly?
— Reply to this email directly, view it on GitHub https://github.com/NixOS/nixpkgs/issues/290267#issuecomment-1956172872, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUGXHU4D65QLGOSTQZMDILYUWZFVAVCNFSM6AAAAABDR2IVCGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJWGE3TEOBXGI . You are receiving this because you authored the thread.Message ID: @.***>
But the CRI used by docker is containerd, just like k3s uses containerd by default. So why do you need docker in the picture? 🤔
The application I’m integrating with uses docker desktop. As in the UI is a docker desktop plugin. When I connect my application in k3s to docker using the —docker flag both applications can communicate and the existing user interface reflects the data provided by my application. Without the docker flag the applications do not communicate.
Outside of this logging issue everything works fine.
It would be useful to have this logging issue resolved.
On Thu, Feb 22, 2024 at 05:02 Jairo Llopis @.***> wrote:
But the CRI used by docker is containerd, just like k3s uses containerd by default. So why do you need docker in the picture? 🤔
— Reply to this email directly, view it on GitHub https://github.com/NixOS/nixpkgs/issues/290267#issuecomment-1959307045, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUGXHU7YTHJLRXBMBJJNDDYU4XT3AVCNFSM6AAAAABDR2IVCGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJZGMYDOMBUGU . You are receiving this because you authored the thread.Message ID: @.***>
Describe the bug
A significant amount of noise in the logs relating to logs written in containers
Steps To Reproduce
Steps to reproduce the behavior: 1.Install k3s (1.27)
Expected behavior
Run without "noise" in the log and interact gracefully with docker.
Screenshots
Additional context
Adding a few entries to the
virtualisation.docker.daemon.settings
seems sufficient to squelch some of the messages written to the k3s logs.However, I am uncertain of this approach in eliminating the log noise as perhaps that might hide a different "real" issue logged from the same or related k3s sub-systems.
I am also uncertain if the regular logging of the docker daemon will be impacted by changing the log-driver setting. So far it does not appear to impact the output of logs written to journald; journald it is the default value value of virtualisation.docker.logDriver.
The issue also appears in package k3s_1_28.
The --docker flag is indicated in the k3s.io documentation as an experimental option.
This flag is proving to be a very useful k3s configuration option. Hopefully, podman also becomes an option in the future.
Notify maintainers
@euank @Mic92 @yajo
Metadata
Please run
nix-shell -p nix-info --run "nix-info -m"
and paste the result.