Docker for Mac fixes idle supervisor CPU use
The June Mac edge release fixes supervisor CPU consumption and a VPNKit memory leak. It also stops replacing an existing kubectl binary when managing the bundled Kubernetes environment.
A container runtime can consume a workstation's resources even when no application container is running. The June 7 Docker for Mac edge release addresses an example in com.docker.supervisor, alongside a VPNKit memory leak. The release entry for 18.05.0-ce-mac67 describes both fixes. Their value lies in correcting work performed by the desktop environment itself, where inspecting an application's container statistics would not explain the problem.
The supervisor report is unusually useful because it separates the symptom from application load. In Docker for Mac issue 2967, opened June 3, the reporter observed sustained CPU use with no containers listed by Docker. Quitting Docker stopped the supervisor and the associated kernel-task activity. Restarting did not immediately reproduce the behavior, which instead appeared over time.
I value Docker because an image and its build file make an application environment transferable. The desktop runtime still needs to behave as a reasonable host application. Resource consumption outside the container workload makes it harder to distinguish the cost of the service being developed from the cost of keeping its development environment open.
An idle workload did not imply an idle desktop
The June report identifies Docker for Mac 18.05.0-ce-mac66 on macOS 10.13.4. It describes supervisor CPU readings above a single fully occupied core and additional kernel activity. These are observations from a particular report, not a benchmark for every installation. Their diagnostic importance is the absence of running containers and the relationship between quitting Docker and ending the activity.
An earlier May report, issue 2923, describes the supervisor reaching 100 percent CPU overnight on the same Mac edge release. Its author supplied a stack trace and reported that killing the supervisor and restarting Docker removed the symptom. Together, the reports establish a host-side problem that can persist without a known application operation triggering it.
The June release notes identify a fix but do not explain the underlying supervisor algorithm or provide a detailed root cause. It would be misleading to infer a particular polling loop or synchronization defect from the process name and CPU reading. The supported conclusion is that this desktop build corrects the supervisor problem linked by those reports.
That distinction matters for operational interpretation. A restart that temporarily stops the symptom does not identify which internal operation failed. It can establish that the activity belongs to the desktop runtime and provide a way to recover the workstation. The release connects that observed behavior to a correction without requiring users to assign the cost to an application container.
The VPNKit report came from Windows
The release also links VPNKit issue 371. Its original report concerns vpnkit.exe on Windows, with memory consumption growing over several hours while two containers were running. Docker's Mac release entry nevertheless cites it for the VPNKit memory leak fix. The distinction between the reporting platform and the release carrying a correction is worth preserving.
The report does not prove that every Mac installation had the same memory growth or that the supervisor CPU defect and VPNKit leak had one cause. They are separate items in the release notes and involve different named processes. Their common operational consequence is that supporting runtime components can retain resources beyond what a user expects from the visible workload.
The practical benefit of the release is therefore two independently stated corrections. One addresses supervisor CPU consumption. The other addresses memory growth in VPNKit. No numerical reduction for a typical Mac workload follows from the notes, and the Windows reporter's memory reading should not be presented as a measured result for the Mac build.
The bundled environment must coexist with host tools
Another fix stops Docker from overriding an existing kubectl binary in /usr/local/bin. The linked issue 2368 describes activating Kubernetes replacing an existing installation, followed by disabling Kubernetes removing it. A package manager could then believe its client remained installed even though the executable had disappeared.
This is a distinct kind of host integration failure. The user has installed a command independently, while the desktop application also needs a Kubernetes client. Replacing that command changes the user's existing tool environment as a side effect of enabling a bundled service. The June behavior leaves the existing binary in place.
The release updates its bundled Kubernetes to 1.10.3 and states that an enabled Kubernetes environment upgrades automatically when Docker starts. It also includes LinuxKit 0.4 and a Linux kernel update. Those component changes explain why the desktop build needs its own release identity, even though its name still contains the May engine version.
I find the host-tool correction as relevant as the resource fixes. A repeatable container environment is less helpful when enabling it unexpectedly changes an independently managed executable. This build addresses that ownership conflict while also correcting resource use in the processes that support the local environment.