Change:
Umbrella issue: Originating issue: (partially fixes) File: URL: Line 207 contains The code sample includes docker mentions. Action: remove the phrase. Add warning about code samples potentially breaking. Test code samples on a cluster with a different runtime and on a cluster with cri-dockerd and Docker. File: URL: Line 65 contains Docker Hub as an example. Action: keep, since it's an example image. File: URL: Last sentence in line 392 contains Docker as an example. Action: Rephrase to "some agent on the node, such as the kubelet" File: URL: Line 142 and 273 have Docker as an example. Action: Line 142: remove "or Docker". Line 273: rephrase to "some agent on the node, such as the kubelet." File: URL: Line 35 - 48: Uses Docker to describe what Pods are. Action: reword the overview of a Pod to describe it without a reliance on a third party. Use content from our Glossary. File: /concepts/workloads/pods/init- URL: Output in line 189 and 190 seem to use docker as the runtime. Action: not sure. Replace example output with the output while using containerd or cri-o? File: /concepts/workloads/pods/pod- URL: Line 208 uses docker as the container ID example Action: keep as-is. /sig docs /language en /help-wanted
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted
Hi, Can I work on this?
yup, go for it! If you run into issues or have questions, feel free to ask here or on Slack :) /assign
Hi, good evening, I wanted to clarify something in I have to implement the code using cri-dockerd and Docker right? Different runtime means we have to use containerd, runC or CRI-O right??
that's my understanding. If you use a container runtime that's not docker and also not one of the ones you listed, that's also fine.
Need any help here?
Hi are you working on this issue already? If not I'd like to tackle this issue :)
Yeah I'm working I have corrected the simple text changes but I'm having trouble running containerd on my system for replacing docker examples as mentioned in the issue, you can work on this if you want
kindly unassign yourself from this issue, so that other people can take it up. Thanks! Are you working on this?
/milestone 1.24
Sorry, I didn't know I had to unassign it by myself. I thought only a contributor will have this authority. Now I know and have unassigned myself.
If no one is working on this issue can you assign this issue to me .
Sure you can go ahead. Anytime, you can assign yourself by commenting on particular issue you want to work. For now, I am assigning this to you. /assign
Thank you Meha for assigning me for this issue . Let me know you that i am new in this open source contribution journey and indeed so much of guidance to move forward it will be very helpful if you can do this for me in anyway. Meha Bhalodiya
Hi did you need any help with this issue to move it along?
Clearing the 1.24 milestone. This can be to subsequent milestones if needed. /milestone clear
It's been a while since the last update. PRs to address this issue are welcome (by any contributor). /priority important-longterm
I don't see any updates; so unassigning you. Please feel free to assign, if you come back here again and are willing to work on it! Thank you /unassign
/assign
hi the context in the 5th issue from the top is quite unclear to me what I understand is that the I have to remove reference of docker with pods and redefine it as below plz help me with this While Kubernetes supports more {{< glossarytooltip text="container runtimes" termid="container-runtime" }} than just Docker, is the most commonly known runtime. {{< /note }} The Pod is the smallest and simplest Kubernetes object which is a set of Linux namespaces, cgroups, and potentially other facets of isolation . Within a Pod , the individual applications may have further sub-isolations applied. A Pod represents a set of running on your cluster. ) A Pod is typically set up to run a single primary container. It can also run optional sidecar containers that add supplementary features like logging.
what I suggest you do is open a PR to work on that and show your initial thinking, and also write a PR description that explains how you approached the challenge. Then, a reviewer can comment on both the intent and the changes you've made. A word of warning, though. This particular sub-task calls for a strong ability to explain a technical concept. If you're not comfortable with that, it's OK to pick a different subtask from the list that looks easier to tackle.
sure thanks for the suggestion
Is this issue still needed to be worked upon?
Yes you can pick it up if you want to work on
/assign
Hey let me know if you are not working on this, I can pick it up :)
Go ahead and work on this issue. I'd love to see what changes you bring:)
/unassign
Thanks /assign
At this point we're pretty unlikely to be testing things on docker as a runtime given it hasn't been supported for multiple releases (unless using cri-dockerd, which may have it's own breakage). Also, FWIW, generally workloads should not be container runtime sensitive, though some unusual edge cases exist mostly which are also technically configurable etc. and can be different even using the same runtime.

Discussion:
- Ability to monitor and manage logs for daemons in the same way as applications. - Same config language and tools (e.g. Pod templates, `kubectl`) for daemons and applications. - Running daemons in containers with resource limits increases isolation between daemons from app <del> containers.  However, this can also be accomplished by running the daemons in a container but not in a Pod (e.g. start directly via Docker). </del> <ins> containers.  However, this can also be accomplished by running the daemons in a container but not in a Pod. </ins> ### Bare Pods

Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Always` is allowed, which is the default if not specified. For local container restarts, ReplicationControllers delegate to an agent on the node, <del> for example the [Kubelet](/docs/reference/command-line-tools-reference/kubelet/) or Docker. </del> <ins> for example the [Kubelet](/docs/reference/command-line-tools-reference/kubelet/). </ins> ### Labels on the ReplicationController

### Bare Pods <del> Unlike in the case where a user directly created pods, a ReplicationController replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicationController even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node.  A ReplicationController delegates local container restarts to some agent on the node (for example, Kubelet or Docker). </del> <ins> Unlike in the case where a user directly created pods, a ReplicationController replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicationController even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node.  A ReplicationController delegates local container restarts to some agent on the node, such as the kubelet. </ins> ### Job

{{< /note >}} The shared context of a Pod is a set of Linux namespaces, cgroups, and <del> potentially other facets of isolation - the same things that isolate a Docker container.  Within a Pod's context, the individual applications may have </del> <ins> potentially other facets of isolation - the same things that isolate a {{< glossary_tooltip text="container" term_id="container" >}}. Within a Pod's context, the individual applications may have </ins> further sub-isolations applied. <del> In terms of Docker concepts, a Pod is similar to a group of Docker containers with shared namespaces and shared filesystem volumes. </del> <ins> A Pod is similar to a set of containers with shared namespaces and shared filesystem volumes. </ins> ## Using Pods

16s          16s         1        {default-scheduler }                                              Normal        Scheduled     Successfully assigned myapp-pod to 172.17.4.201 16s          16s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulling       pulling image "busybox" 13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulled        Successfully pulled image "busybox" <del> 13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Created       Created container with docker id 5ced34a04634; Security:[seccomp=unconfined] 13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Started       Started container with docker id 5ced34a04634 </del> <ins> 13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Created       Created container init-myservice 13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Started       Started container init-myservice </ins> ``` To see logs for the init containers in this Pod, run:

volumeMounts: - name: varlog mountPath: /var/log <del> - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true </del> terminationGracePeriodSeconds: 30 volumes: - name: varlog hostPath: path: /var/log <del> - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers </del>