Removing references to Docker from Nodes topics

mburke5678 · mburke5678 · commit ad5dd73e2d66 · 2019-02-11T21:04:22.000-05:00
diff --git a/modules/nodes-cluster-overcommit-node-resources.adoc b/modules/nodes-cluster-overcommit-node-resources.adoc
@@ -8,7 +8,7 @@
 
 To provide more reliable scheduling and minimize node resource overcommitment, 
 each node can reserve a portion of its resources for use by system daemons 
-that are required to run on your node for your cluster to function (*sshd*, *docker*, etc.). 
+that are required to run on your node for your cluster to function (*sshd*, etc.). 
 In particular, it is recommended that you reserve resources for incompressible resources such as memory.
 
 .Procedure
diff --git a/modules/nodes-containers-using-about.adoc b/modules/nodes-containers-using-about.adoc
@@ -17,16 +17,6 @@ as a web server or a database, though containers can be used for arbitrary
 workloads.
 
 The Linux kernel has been incorporating capabilities for container technologies
-for years. More recently the Docker project has developed a convenient
-management interface for Linux containers on a host. {product-title} and
-Kubernetes add the ability to orchestrate Docker-formatted containers across
+for years. {product-title} and
+Kubernetes add the ability to orchestrate containers across
 multi-host installations.
-
-Though you do not directly interact with the Docker CLI or service when using
-{product-title}, understanding their capabilities and terminology is
-important for understanding their role in {product-title} and how your
-applications function inside of containers. The *docker* RPM is available
-as part of RHEL 7, as well as CentOS and Fedora, so you can
-experiment with it separately from {product-title}. Refer to the article
-link:https://access.redhat.com/articles/881893[Get Started with Docker Formatted Container Images on Red Hat Systems] for a guided introduction.
-
diff --git a/modules/nodes-nodes-garbage-collection-containers.adoc b/modules/nodes-nodes-garbage-collection-containers.adoc
@@ -59,14 +59,6 @@ the `*maximum-dead-containers*` limit.
 When the node removes the dead containers, all files inside those containers are
 removed as well. Only containers created by the node are removed.
 
-ifdef::openshift-origin[]
-[NOTE]
-====
-Currently, Docker and rkt are supported. The following only applies to Docker;
-rkt has its own garbage collection.
-====
-endif::[]
-
 Each spin of the garbage collector loop goes through the following steps:
 
 1. Retrieve a list of available containers.
diff --git a/modules/nodes-nodes-modifying-maximum.adoc b/modules/nodes-nodes-modifying-maximum.adoc
@@ -20,11 +20,11 @@ maximum number of pods that can be scheduled to a node: `pods-per-core` and
 `max-pods`. When both options are in use, the lower of the two limits the number
 of pods on a node. Exceeding these values can result in:
 
-* Increased CPU utilization on both {product-title} and Docker.
+* Increased CPU utilization on {product-title}.
 * Slow pod scheduling.
 * Potential out-of-memory scenarios (depends on the amount of memory in the node).
 * Exhausting the pool of IP addresses.
-* Resource overcommitting, leading to poor user application performance.
+// * Resource overcommitting, leading to poor user application performance.
 
 [NOTE]
 ====
diff --git a/modules/nodes-nodes-problem-detector-about.adoc b/modules/nodes-nodes-problem-detector-about.adoc
@@ -54,15 +54,6 @@ status: false
 type: KernelDeadLock
 ----
 
-.Sample output for KernelDeadLock condition
-[source,bash]
-----
-message: task docker:1234 blocked for more than 120 seconds
-reason: DockerHung
-status: true
-type: KernelDeadLock
-----
-
 This example shows output from the Node Problem Detector watching for events on a node.
 The following command uses `oc get event` against the *default* project watching for
 events listed in the `kernel-monitor.json` section of the Node Problem Detector configuration map.
@@ -76,7 +67,6 @@ events listed in the `kernel-monitor.json` section of the Node Problem Detector
 [source,bash]
 ----
 LAST SEEN                       FIRST SEEN                    COUNT NAME     KIND  SUBOBJECT TYPE    REASON      SOURCE                   MESSAGE
-2018-06-27 09:08:27 -0400 EDT   2018-06-27 09:08:27 -0400 EDT 1     my-node1 node            Warning TaskHunk    kernel-monitor.my-node1  docker:1234 blocked for more than 300 seconds
 2018-06-27 09:08:27 -0400 EDT   2018-06-27 09:08:27 -0400 EDT 3     my-node2 node            Warning KernelOops  kernel-monitor.my-node2  BUG: unable to handle kernel NULL pointer deference at nowhere
 2018-06-27 09:08:27 -0400 EDT   2018-06-27 09:08:27 -0400 EDT 1     my-node1 node            Warning KernelOops  kernel-monitor.my-node2  divide error 0000 [#0] SMP
 ----
diff --git a/modules/nodes-nodes-problem-detector-customizing.adoc b/modules/nodes-nodes-problem-detector-customizing.adoc
@@ -26,26 +26,7 @@ kind: ConfigMap
 metadata:
   name: node-problem-detector
 data:
-  docker-monitor.json: |  <1>
-    {
-        "plugin": "journald", <2>
-        "pluginConfig": {
-                "source": "docker"
-        },
-        "logPath": "/host/log/journal", <3>
-        "lookback": "5m",
-        "bufferSize": 10,
-        "source": "docker-monitor",
-        "conditions": [],
-        "rules": [              <4>
-                {
-                        "type": "temporary", <5>
-                        "reason": "CorruptDockerImage", <6>
-                        "pattern": "Error trying v2 registry: failed to register layer: rename /var/lib/docker/image/(.+) /var/lib/docker/image/(.+): directory not empty.*" <7>
-                }
-        ]
-    }
-  kernel-monitor.json: |  <8>
+    kernel-monitor.json: |  <8>
     {
         "plugin": "journald", <2>
         "pluginConfig": {
@@ -94,12 +75,6 @@ data:
                         "reason": "AUFSUmountHung",
                         "pattern": "task umount\\.aufs:\\w+ blocked for more than \\w+ seconds\\."
                 },
-                {
-                        "type": "permanent",
-                        "condition": "KernelDeadlock",
-                        "reason": "DockerHung",
-                        "pattern": "task docker:\\w+ blocked for more than \\w+ seconds\\."
-                }
         ]
     }
 ----
@@ -161,7 +136,7 @@ spec:
         - node-problem-detector
         - --alsologtostderr=true <1>
         - --log_dir="/tmp" <2>
-        - --system-log-monitors=/etc/npd/kernel-monitor.json,/etc/npd/docker-monitor.json <3>
+        - --system-log-monitors=/etc/npd/kernel-monitor.json <3>
 ----
 +
 <1> Sends the output to standard output (stdout).
diff --git a/modules/nodes-nodes-problem-detector-verifying.adoc b/modules/nodes-nodes-problem-detector-verifying.adoc
@@ -53,6 +53,6 @@ I0416 23:22:00.641354       1 log_monitor.go:63] Finish parsing log monitor conf
 +
 [source,bash]
 ----
-# echo "kernel: task docker:7 blocked for more than 300 seconds." >> /dev/kmsg
+# echo "kernel: task blocked for more than 300 seconds." >> /dev/kmsg
 ----
 
diff --git a/modules/nodes-nodes-rebooting-affinity.adoc b/modules/nodes-nodes-rebooting-affinity.adoc
@@ -33,7 +33,7 @@ spec:
         podAffinityTerm:
           labelSelector:
             matchExpressions:
-            - key: docker-registry <4>
+            - key: registry <4>
               operator: In <5>
               values: 
               - default
@@ -46,7 +46,7 @@ spec:
 <5> The operator represents the relationship between the label on the existing pod and the set of values in the `matchExpression` parameters in the specification for the new pod. Can be `In`, `NotIn`, `Exists`, or `DoesNotExist`.
 +
 This example assumes the container image registry pod has a label of
-`*docker-registry=default*`. Pod anti-affinity can use any Kubernetes match
+`*registry=default*`. Pod anti-affinity can use any Kubernetes match
 expression.
 
 . Enable the `*MatchInterPodAffinity*` scheduler predicate in *_/etc/origin/master/scheduler.json_*. See _Default Scheduling_.
diff --git a/modules/nodes-nodes-viewing-listing.adoc b/modules/nodes-nodes-viewing-listing.adoc
@@ -18,15 +18,11 @@ node1.example.com      Ready     compute   7h        v1.9.1+a0ce1bc657
 node2.example.com      Ready     compute   7h        v1.9.1+a0ce1bc657
 ----
 
-* The `-wide` option provides provides additional information on all nodes:
+* The `-wide` option provides provides additional information on all nodes.
 +
 [source,bash]
 ----
 $ oc get nodes -o wide
-NAME                           STATUS    ROLES     AGE       VERSION           EXTERNAL-IP      OS-IMAGE                                      KERNEL-VERSION          CONTAINER-RUNTIME
-ip-172-18-0-39.ec2.internal    Ready     infra     1d        v1.10.0+b81c8f8   54.172.185.130   Red Hat Enterprise Linux Server 7.5 (Maipo)   3.10.0-862.el7.x86_64   docker://1.13.1
-ip-172-18-10-95.ec2.internal   Ready     master    1d        v1.10.0+b81c8f8   54.88.22.81      Red Hat Enterprise Linux Server 7.5 (Maipo)   3.10.0-862.el7.x86_64   docker://1.13.1
-ip-172-18-8-35.ec2.internal    Ready     compute   1d        v1.10.0+b81c8f8   34.230.50.57     Red Hat Enterprise Linux Server 7.5 (Maipo)   3.10.0-862.el7.x86_64   docker://1.13.1
 ----
 
 * The following command lists information about a single node:
@@ -112,14 +108,14 @@ System Info:                 <9>
  OS Image:                           OpenShift Enterprise
  Operating System:                   linux
  Architecture:                       amd64
- Container Runtime Version:          docker://1.13.1
+ Container Runtime Version:          1.13.1
  Kubelet Version:                    v1.10.0+b81c8f8
  Kube-Proxy Version:                 v1.10.0+b81c8f8
 ExternalID:                          node1.example.com
 Non-terminated Pods:                 (14 in total)       <10>
   Namespace                          Name                                  CPU Requests  CPU Limits  Memory Requests  Memory Limits
   ---------                          ----                                  ------------  ----------  ---------------  -------------
-  default                            docker-registry-2-w252l               100m (5%)     0 (0%)      256Mi (3%)       0 (0%)
+  default                            registry-2-w252l                      100m (5%)     0 (0%)      256Mi (3%)       0 (0%)
   default                            registry-console-2-dpnc9              0 (0%)        0 (0%)      0 (0%)           0 (0%)
   default                            router-2-5snb2                        100m (5%)     0 (0%)      256Mi (3%)       0 (0%)
   kube-service-catalog               apiserver-jh6gt                       0 (0%)        0 (0%)      0 (0%)           0 (0%)
diff --git a/modules/nodes-pods-disabling-features-list.adoc b/modules/nodes-pods-disabling-features-list.adoc
@@ -11,9 +11,6 @@ Use the following list to determine the name of the feature you want to disable:
 |===
 | Feature gate| Description
 
-| *Accelerators*
-| Enables link:https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/[Nvidia GPU] support when using Docker.
-
 | *AdvancedAuditing*
 | Enables Advanced Audit].
 
@@ -23,9 +20,6 @@ Use the following list to determine the name of the feature you want to disable:
 | *APIResponseCompression*
 | Enables the compression of API responses for LIST or GET requests.
 
-| *AppArmor*
-| Enables AppArmor-based mandatory access control on Linux nodes when using Docker. For more information, see the link:https://kubernetes.io/docs/tutorials/clusters/apparmor/[Kubernetes AppArmor documentation].
-
 | *BlockVolume*
 | Enables the definition and consumption of raw block devices in pods. For more information, see
 the link:https://kubernetes.io/docs/concepts/storage/persistent-volumes/#raw-block-volume-support[Kubernetes Raw Block Volume Support].
@@ -69,9 +63,6 @@ For more information, see Extending the Kubernetes API with Custom Resources.
 | *ExperimentalCriticalPodAnnotation*
 | Enables annotating specific pods as critical so that their scheduling is guaranteed.
 
-| *ExperimentalHostUserNamespaceDefaultingGate*
-| Enables the disabling of user namespaces. This is for Containers that are using other host projects, host mounts, or Containers that are privileged or using specific non-project capabilities, such as MKNODE, SYS_MODULE, and so forth. This should only be enabled if user project remapping is enabled in the Docker daemon.
-
 | *GCERegionalPersistentDisk*
 | Enables the GCE Persistent Disk feature.
 
diff --git a/modules/nodes-pods-secrets-about.adoc b/modules/nodes-pods-secrets-about.adoc
@@ -6,7 +6,7 @@
 = Understanding secrets
 
 The `Secret` object type provides a mechanism to hold sensitive information such
-as passwords, {product-title} client configuration files, `dockercfg` files,
+as passwords, {product-title} client configuration files, 
 private source repository credentials, and so on. Secrets decouple sensitive
 content from the pods. You can mount secrets into Containers using a volume
 plug-in or the system can use secrets to perform actions on behalf of a pod.
@@ -65,8 +65,6 @@ which is the default.
 Specify one of the following types to trigger minimal server-side validation to ensure the presence of specific key names in the secret data:
 
 * `kubernetes.io/service-account-token`. Uses a service account token.
-* `kubernetes.io/dockercfg`. Uses the *_.dockercfg_* file for required Docker credentials.
-* `kubernetes.io/dockerconfigjson`. Uses the *_.docker/config.json_* file for required Docker credentials.
 * `kubernetes.io/basic-auth`. Use with Basic Authentication.
 * `kubernetes.io/ssh-auth`. Use with SSH Key Authentication.
 * `kubernetes.io/tls`. Use with TLS certificate authorities.
diff --git a/modules/nodes-pods-secrets-certificates-about.adoc b/modules/nodes-pods-secrets-certificates-about.adoc
@@ -20,9 +20,9 @@ masters.
 apiVersion: v1
   kind: Service
   metadata:
-    name: docker-registry
+    name: registry
     annotations:                                                        
-      service.alpha.openshift.io/serving-cert-secret-name: docker-cert<1>
+      service.alpha.openshift.io/serving-cert-secret-name: cert<1>
 ....
 ----
 <1> Specify the name for the certificate
diff --git a/modules/nodes-pods-secrets-creating-docker.adoc b/modules/nodes-pods-secrets-creating-docker.adoc
diff --git a/modules/nodes-pods-using-example.adoc b/modules/nodes-pods-using-example.adoc
@@ -24,10 +24,10 @@ kind: Pod
 metadata:
   annotations: { ... }
   labels:                                <1>
-    deployment: docker-registry-1
-    deploymentconfig: docker-registry
-    docker-registry: default
-  generateName: docker-registry-1-       <2>
+    deployment: registry-1
+    deploymentconfig: registry
+    registry: default
+  generateName: registry-1-       <2>
 spec:
   containers:                            <3>
   - env:                                 <4>
@@ -41,7 +41,7 @@ spec:
       value: ...
     - name: OPENSHIFT_MASTER
       value: https://master.example.com:8443
-    image: openshift/origin-docker-registry:v0.6.2 <5>
+    image: openshift/origin-registry:v0.6.2 <5>
     imagePullPolicy: IfNotPresent
     name: registry
     ports:                              <6>
@@ -57,7 +57,7 @@ spec:
       readOnly: true
   dnsPolicy: ClusterFirst
   imagePullSecrets:
-  - name: default-dockercfg-at06w
+  - name: default-cfg-at06w
   restartPolicy: Always                 <9>
   serviceAccount: default               <10>
   volumes:                              <11>
@@ -71,15 +71,15 @@ spec:
 <1> Pods can be "tagged" with one or more labels, which can then
 be used to select and manage groups of pods in a single operation. The labels
 are stored in key/value format in the `*metadata*` hash. One label in this
-example is *docker-registry=default*.
+example is *registry=default*.
 <2> Pods must have a unique name within their namespace. A pod definition can specify
 the basis of a name with the `*generateName*` attribute, and random characters
 will be added automatically to generate a unique name.
 <3> `*containers*` specifies an array of Container definitions; in this case (as
 with most), just one.
 <4> Environment variables can be specified to pass necessary values to each
 Container.
-<5> Each Container in the pod is instantiated from its own Docker-formatted Container image.
+<5> Each Container in the pod is instantiated from its own Container image.
 <6> The Container can bind to ports which will be made available on the pod's
 IP.
 <7> {product-title} defines a security context for Containers which specifies whether they are allowed to run as
diff --git a/nodes/nodes-containers-using.adoc b/nodes/nodes-containers-using.adoc
@@ -21,19 +21,10 @@ as a web server or a database, though containers can be used for arbitrary
 workloads.
 
 The Linux kernel has been incorporating capabilities for container technologies
-for years. More recently the Docker project has developed a convenient
-management interface for Linux containers on a host. {product-title} and
-Kubernetes add the ability to orchestrate Docker-formatted containers across
+for years. {product-title} and
+Kubernetes add the ability to orchestrate containers across
 multi-host installations.
 
-Though you do not directly interact with the Docker CLI or service when using
-{product-title}, understanding their capabilities and terminology is
-important for understanding their role in {product-title} and how your
-applications function inside of containers. The *docker* RPM is available
-as part of RHEL 7, as well as CentOS and Fedora, so you can
-experiment with it separately from {product-title}. Refer to the article
-link:https://access.redhat.com/articles/881893[Get Started with Docker Formatted Container Images on Red Hat Systems] for a guided introduction.
-
 
 // The following include statements pull in the module files that comprise
 // the assembly. Include any combination of concept, procedure, or reference
diff --git a/nodes/nodes-nodes-resources-configuring.adoc b/nodes/nodes-nodes-resources-configuring.adoc
@@ -9,8 +9,8 @@ toc::[]
 
 To provide more reliable scheduling and minimize node resource overcommitment,
 each node can reserve a portion of its resources for use by all underlying node
-components (e.g., kubelet, kube-proxy, Docker) and the remaining system
-components (e.g., *sshd*, *NetworkManager*) on the host. Once specified, the
+components (such as kubelet, kube-proxy) and the remaining system
+components (such as *sshd*, *NetworkManager*) on the host. Once specified, the
 scheduler has more information about the resources (e.g., memory, CPU) a node
 has allocated for pods.
 
diff --git a/nodes/nodes-pods-secrets.adoc b/nodes/nodes-pods-secrets.adoc
@@ -20,8 +20,6 @@ include::modules/nodes-pods-secrets-creating.adoc[leveloffset=+1]
 
 include::modules/nodes-pods-secrets-creating-opaque.adoc[leveloffset=+2]
 
-include::modules/nodes-pods-secrets-creating-docker.adoc[leveloffset=+2]
-
 include::modules/nodes-pods-secrets-updating.adoc[leveloffset=+1]
 
 include::modules/nodes-pods-secrets-certificates-about.adoc[leveloffset=+1]

Original file line number	Diff line number	Diff line change
`@@ -53,6 +53,6 @@ I0416 23:22:00.641354 1 log_monitor.go:63] Finish parsing log monitor conf`
`53`	`53`	`+`
`54`	`54`	`[source,bash]`
`55`	`55`	`----`
`56`		`-# echo "kernel: task docker:7 blocked for more than 300 seconds." >> /dev/kmsg`
	`56`	`+# echo "kernel: task blocked for more than 300 seconds." >> /dev/kmsg`
`57`	`57`	`----`
`58`	`58`