[Tracking] Feature/performance parity for process-isolated (shared-kernel) containers vs. Linux containers

Open
#653 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
docker, linux
Domain
infrastructure

Research direction

Start by reading the four linked tickets: #649, #650, #651, and #652, since this issue is only a tracking umbrella. Review their owners and implementation scopes rather than looking for an independent change here. The umbrella is done when all four scoped parity tickets are completed or the project chooses another tracking mechanism.

Written by the indexing model from the issue text.

Description

enhancement triage

Is your feature request related to a problem? Please describe.

Process-isolated Windows Server containers lag Linux containers on several related fronts — privilege isolation granularity, PID namespace semantics, image layer/filesystem performance, and host/image version coupling. Each gap has its own owner surface and is filed as its own ticket, but they share a common motivation (closing the parity gap without falling back to Hyper-V isolation, which erases the density/startup-time benefit process isolation exists for), so this issue exists to track them as one effort.

Describe the solution you'd like

Track progress against the four scoped tickets below:

  • #649 — Syscall/capability-scoped restriction policy for process-isolated containers (seccomp/capabilities parity)
  • #650 — True PID namespace isolation for process-isolated containers (server silos)
  • #651 — CimFS-backed overlay mount performance parity with Linux overlayfs for container image layers
  • #652 — Decouple container base image version from host OS version for process-isolated containers

Describe alternatives you've considered

N/A — this issue is a tracking umbrella, not an independent ask; alternatives are discussed per-ticket above.

Additional context

#652 is flagged as the hardest of the four, likely requiring changes below the container runtime layer; the other three are scoped to be independently actionable. Happy to close this umbrella once all four are triaged/assigned if the team prefers tracking via a label or milestone instead.

Dominant language
PowerShell
Stars
551
Forks
76
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/Windows-Containers

All issues in microsoft/Windows-Containers

Similar issues

More DevOps issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.