Nodes edits

mburke5678 · mburke5678 · commit 58b754a45174 · 2019-04-10T23:34:10.000-04:00
diff --git a/_topic_map.yml b/_topic_map.yml
@@ -392,14 +392,14 @@ Topics:
     File: nodes-scheduler-default
   - Name: Placing pods relative to other pods using pod affinity/anti-affinity rules
     File: nodes-scheduler-pod-affinity
+  - Name: Controlling pod placement on nodes using node affinity rules
+    File: nodes-scheduler-node-affinity
   - Name: Placing a pod on a specific node by name
     File: nodes-scheduler-node-names
   - Name: Placing a pod in a specific project
     File: nodes-scheduler-node-projects
   - Name: Placing pods onto overcommited nodes
     File: nodes-scheduler-overcommit
-  - Name: Controlling pod placement on nodes using node affinity rules
-    File: nodes-scheduler-node-affinity
   - Name: Controlling pod placement using node taints
     File: nodes-scheduler-taints-tolerations
   - Name: Constraining pod placement using node selectors
@@ -482,8 +482,6 @@ Topics:
   File: efk-logging
 - Name: Deploying cluster logging
   File: efk-logging-deploy
-- Name: Viewing the Kibana interface
-  File: efk-logging-kibana-interface
 - Name: Changing cluster logging management state
   File: efk-logging-management
 - Name: Configuring cluster logging
diff --git a/modules/nodes-cluster-overcommit-configure-nodes.adoc b/modules/nodes-cluster-overcommit-configure-nodes.adoc
@@ -12,17 +12,38 @@ When the node starts, it ensures that the kernel tunable flags for memory
 management are set properly. The kernel should never fail memory allocations
 unless it runs out of physical memory.
 
-To ensure this behavior, the node instructs the kernel to always overcommit
-memory:
+In an overcommitted environment, it is important to properly configure your node to provide best system behavior.
+
+When the node starts, it ensures that the kernel tunable flags for memory
+management are set properly. The kernel should never fail memory allocations
+unless it runs out of physical memory.
+
+To ensure this behavior, {product-title} configures the kernel to always overcommit
+memory by setting the `vm.overcommit_memory` parameter to `1`, overriding the
+default operating system setting.
+
+{product-title} also configures the kernel not to panic when it runs out of memory
+by setting the `vm.panic_on_oom` parameter to `0`. A setting of 0 instructs the
+kernel to call oom_killer in an Out of Memory (OOM) condition, which kills
+processes based on priority
+
+You can view the current setting by running the following commands on your node:
 
 ----
-$ sysctl -w vm.overcommit_memory=1
+$ sysctl -a |grep commit
+
+vm.overcommit_memory = 0
 ----
 
-The node also instructs the kernel not to panic when it runs out of memory.
-Instead, the kernel OOM killer should kill processes based on priority:
+----
+$ sysctl -a |grep panic
+vm.panic_on_oom = 0
+----
+
+You can change these settings using:
 
 ----
+$ sysctl -w vm.overcommit_memory=1
 $ sysctl -w vm.panic_on_oom=0
 ----
 
diff --git a/modules/nodes-cluster-overcommit-master-disabling-swap.adoc b/modules/nodes-cluster-overcommit-master-disabling-swap.adoc
diff --git a/modules/nodes-cluster-resource-levels-command.adoc b/modules/nodes-cluster-resource-levels-command.adoc
@@ -5,18 +5,19 @@
 [id="nodes-cluster-resource-levels-command-{context}"]
 = Running the cluster capacity tool on the command line
 
-You can run the {product-title} capacity tool from the command line
+You can run the {product-title} cluster capacity tool from the command line
 to estimate the number of pods that can be scheduled onto your cluster.
 
 .Prerequisites
 
-A sample pod specification file, which the tool
-uses for estimating resource usage. The `podspec` specifies its resource
+* Download and install link:https://github.com/kubernetes-incubator/cluster-capacity[the *cluster-capacity* tool].
+
+* Create a sample pod specification file, which the tool uses for estimating resource usage. The `podspec` specifies its resource
 requirements as `limits` or `requests`. The cluster capacity tool takes the
 pod's resource requirements into account for its estimation analysis.
-
++
 An example of the pod specification input is:
-
++
 [source,yaml]
 ----
 apiVersion: v1
@@ -48,7 +49,7 @@ To run the tool on the command line:
 . Run the following command:
 +
 ----
-$ cluster-capacity --kubeconfig <path-to-kubeconfig> \ <1>
+$ ./cluster-capacity --kubeconfig <path-to-kubeconfig> \ <1>
     --podspec <path-to-pod-spec> <2>
 ----
 <1> Specify the path to your Kubernetes configuration file.
@@ -58,7 +59,7 @@ You can also add the `--verbose` option to output a detailed description of how
 many pods can be scheduled on each node in the cluster:
 +
 ----
-$ cluster-capacity --kubeconfig <path-to-kubeconfig> \
+$ ./cluster-capacity --kubeconfig <path-to-kubeconfig> \
     --podspec <path-to-pod-spec> --verbose
 ----
 
diff --git a/modules/nodes-cluster-resource-levels-job.adoc b/modules/nodes-cluster-resource-levels-job.adoc
@@ -9,6 +9,10 @@ Running the cluster capacity tool as a job inside of a pod has the advantage of
 being able to be run multiple times without needing user intervention. Running
 the cluster capacity tool as a job involves using a `ConfigMap`.
 
+.Prerequisites
+
+Download and install link:https://github.com/kubernetes-incubator/cluster-capacity[the *cluster-capacity* tool].
+
 .Procedure
 
 To run the cluster capacity tool:
diff --git a/modules/nodes-containers-downward-api-container-configmaps.adoc b/modules/nodes-containers-downward-api-container-configmaps.adoc
@@ -36,7 +36,7 @@ apiVersion: v1
 kind: Pod
 metadata:
   name: dapi-env-test-pod
-spec:bash
+spec:
   containers:
     - name: env-test-container
       image: gcr.io/google_containers/busybox
@@ -47,7 +47,7 @@ spec:bash
             configMapKeyRef:
               name: myconfigmap
               key: mykey
-  restartPolicy: Never
+  restartPolicy: Always
 ----
 
 . Create the pod from the `*_pod.yaml_*` file:
diff --git a/modules/nodes-containers-events-viewing.adoc b/modules/nodes-containers-events-viewing.adoc
@@ -16,11 +16,11 @@ $ oc get events [-n <project>] <1>
 ----
 <1> The name of the project.
 
-* To view events in your project from the web console.
+* To view events in your project from the {product-title} console.
 +
-. Launch the web console.
+. Launch the {product-title} console.
 +
-. Launch the *Browse* -> *Events* page.
+. Click *Home* -> *Events* and select your project.
 +
 Many other objects, such as pods and deployments, have their own
 *Events* tab as well, which shows events related to that object.
diff --git a/modules/nodes-nodes-garbage-collection-configuring.adoc b/modules/nodes-nodes-garbage-collection-configuring.adoc
@@ -56,12 +56,12 @@ spec:
     matchLabels:
       custom-kubelet: small-pods <2>
   kubeletConfig:
-    ImageMinimumGCAge:  <3>
-    ImageGCHighThresholdPercent: <4>
-    ImageGCLowThresholdPercent: <5>
+    ImageMinimumGCAge: 0 <3>
+    ImageGCHighThresholdPercent: 85 <4>
+    ImageGCLowThresholdPercent: 80 <5>
 ----
 <1> Assign a name to CR.
 <2> Specify the label to apply the configuration change.
-<3> Specify the minimum age for an unused image before it is garbage collected
+<3> Specify the minimum age for an unused image before it is garbage collected. A value of `0` means no limit.
 <4> Specify the percent of disk usage after which image garbage collection is always run.
 <5> Specify the percent of disk usage before which image garbage collection is never run.
diff --git a/modules/nodes-nodes-problem-detector-installing.adoc b/modules/nodes-nodes-problem-detector-installing.adoc
@@ -15,41 +15,20 @@ You can use the {product-title} console to install the Node Problem Detector Ope
 $ oc adm new-project openshift-node-problem-detector --node-selector ""
 ----
 
-. Create an Operator Group:
-
-.. Add the followng code to a YAML file:
-+
-----
-apiVersion: operators.coreos.com/v1alpha2
-kind: OperatorGroup
-metadata:
-  name: npd-operators
-  namespace: openshift-node-problem-detector
-spec:
-  targetNamespaces:
-  - openshift-node-problem-detector
-----
-
-.. Create the Operator Group:
-+
-----
-$ oc create -f -<file-name>.yaml
-----
-
 .Procedure
 
 The process to install the Node Problem Detector involves installing the Node Problem Detector Operator and creating a Node Problem Detector instance.
 
 . In the {product-title} console, click *Catalog* -> *OperatorHub*.
 
+. Choose *Node Problem Detector* from the list of available Operators, and click *Install*.
+
 . On the *Create Operator Subscription* page:
 
 .. Select the `openshift-node-problem-detector` project from the *A specific namespace on the cluster* drop-down list.
 
 .. Click *Subscribe*.
 
-.. Click *Subscribe*.
-
 . On the *Catalog* → *Installed Operators* page, verify that the NodeProblemDetector (CSV) eventually shows up and its *Status* ultimately resolves to *InstallSucceeded*.
 +
 If it does not, switch to the *Catalog* → *Operator Management* page and inspect the *Operator Subscriptions* and *Install Plans* tabs for any failure or errors under *Status*. Then, check the logs in any Pods in the openshift-operators project (on the *Workloads* → *Pods* page) that are reporting issues to troubleshoot further.
diff --git a/modules/nodes-nodes-rebooting-infrastructure.adoc b/modules/nodes-nodes-rebooting-infrastructure.adoc
@@ -3,12 +3,14 @@
 // * nodes/nodes-nodes-rebooting.adoc
 
 [id="nodes-nodes-rebooting-infrastructure-{context}"]
-= Understanding infrastructire node rebooting in {product-title}
+= Understanding infrastructure node rebooting in {product-title}
 
 Infrastructure nodes are nodes that are labeled to run pieces of the
 {product-title} environment. Currently, the easiest way to manage node reboots
 is to ensure that there are at least three nodes available to run
-infrastructure. The scenario below demonstrates a common mistake that can lead
+infrastructure. The nodes to run the infrastructure are called *master* nodes.
+
+The scenario below demonstrates a common mistake that can lead
 to service interruptions for the applications running on {product-title} when
 only two nodes are available.
 
@@ -19,7 +21,7 @@ node B is now running both registry pods.
 - The service exposing the two pod endpoints on node B, for a brief period of
    time, loses all endpoints until they are redeployed to node A.
 
-The same process using three infrastructure nodes does not result in a service
+The same process using three master nodes for infrastructure does not result in a service
 disruption. However, due to pod scheduling, the last node that is evacuated and
 brought back in to rotation is left running zero registries. The other two nodes
 will run two and one registries respectively. The best solution is to rely on
diff --git a/modules/nodes-nodes-viewing-memory.adoc b/modules/nodes-nodes-viewing-memory.adoc
@@ -21,12 +21,15 @@ storage consumption.
 +
 ----
 $ oc adm top nodes
-NAME       CPU(cores)   CPU%      MEMORY(bytes)   MEMORY%
-node-1     297m         29%       4263Mi          55%
-node-0     55m          5%        1201Mi          15%
-infra-1    85m          8%        1319Mi          17%
-infra-0    182m         18%       2524Mi          32%
-master-0   178m         8%        2584Mi          16%
+
+NAME                                   CPU(cores)   CPU%      MEMORY(bytes)   MEMORY%   
+ip-10-0-12-143.ec2.compute.internal    1503m        100%      4533Mi          61%       
+ip-10-0-132-16.ec2.compute.internal    76m          5%        1391Mi          18%       
+ip-10-0-140-137.ec2.compute.internal   398m         26%       2473Mi          33%       
+ip-10-0-142-44.ec2.compute.internal    656m         43%       6119Mi          82%       
+ip-10-0-146-165.ec2.compute.internal   188m         12%       3367Mi          45%       
+ip-10-0-19-62.ec2.compute.internal     896m         59%       5754Mi          77%       
+ip-10-0-44-193.ec2.compute.internal    632m         42%       5349Mi          72%    
 ----
 
 * To view the usage statistics for nodes with labels:
diff --git a/modules/nodes-pods-priority-about.adoc b/modules/nodes-pods-priority-about.adoc
@@ -5,7 +5,7 @@
 [id="nodes-pods-priority-about-{context}"]
 = Understanding pod priority in {product-title}
 
-When the Pod Priority and Preemption feature is enabled, the scheduler orders pending pods by their priority, and a pending pod is placed ahead of other pending pods with lower priority in the scheduling queue. As a result, the higher priority pod might be scheduled sooner than pods with lower priority if its scheduling requirements are met. If a pod cannot be scheduled, scheduler continues to schedule other lower priority pods.
+When you use the Pod Priority and Preemption feature, the scheduler orders pending pods by their priority, and a pending pod is placed ahead of other pending pods with lower priority in the scheduling queue. As a result, the higher priority pod might be scheduled sooner than pods with lower priority if its scheduling requirements are met. If a pod cannot be scheduled, scheduler continues to schedule other lower priority pods.
 
 [id="admin-guide-priority-preemption-priority-class-{context}"]
 == Pod priority classes
@@ -14,6 +14,14 @@ You can assign pods a priority class, which is a non-namespaced object that defi
 
 A priority class object can take any 32-bit integer value smaller than or equal to 1000000000 (one billion). Reserve numbers larger than one billion for critical pods that should not be preempted or evicted. By default, {product-title} has two reserved priority classes for critical system pods to have guaranteed scheduling.
 
+----
+$ oc get priorityclasses
+NAME                      CREATED AT
+cluster-logging           2019-03-13T14:45:12Z
+system-cluster-critical   2019-03-13T14:01:10Z
+system-node-critical      2019-03-13T14:01:10Z
+----
+
 * *system-node-critical* - This priority class has a value of 2000001000 and is used for all pods that should never be evicted from a node. Examples of pods that have this priority class are `sdn-ovs`, `sdn`, and so forth.
 
 * *system-cluster-critical* - This priority class has a value of 2000000000 (two billion) and is used with pods that are important for the cluster. Pods with this priority class can be evicted from a node in certain circumstances. For example, pods configured with the `system-node-critical` priority class can take priority. However, this priority class does ensure guaranteed scheduling. Examples of pods that can have this priority class are fluentd, add-on components like descheduler, and so forth.
@@ -30,6 +38,8 @@ A number of critical components include the `system-cluster-critical` priority c
 ** metrics-server
 ** descheduler
 
+* *cluster-logging* - This priority is used by Fluentd to make sure Fluentd pods are scheduled to nodes over other apps.
+
 [NOTE]
 ====
 If you upgrade your existing cluster, the priority of your existing pods is effectively zero. However, existing pods with
diff --git a/modules/nodes-pods-priority-configuring.adoc b/modules/nodes-pods-priority-configuring.adoc
@@ -5,7 +5,7 @@
 [id="nodes-pods-priority-configuring-{context}"]
 = Configuring priority and preemption
 
-You apply pod priority and preemption by creating a priority class objects and associating pods to the priority using the
+You apply pod priority and preemption by creating a priority class object and associating pods to the priority using the
 `priorityClassName` in your pod specifications.
 
 .Sample priority class object
diff --git a/modules/nodes-pods-priority-preempt-about.adoc b/modules/nodes-pods-priority-preempt-about.adoc
@@ -5,7 +5,7 @@
 [id="nodes-pods-priority-preempt-about-{context}"]
 = Understanding pod preemption in {product-title}
 
-When a developer creates a pod, the pod goes into a queue. When the Pod Priority and Preemption feature is enabled, the scheduler picks a pod from the queue and tries to schedule the pod on a node. If the scheduler cannot find space on an appropriate node that satisfies all the specified requirements of the pod, preemption logic is triggered for the pending pod.
+When a developer creates a pod, the pod goes into a queue. If the developer configured the pod for pod priority or preemption, the scheduler picks a pod from the queue and tries to schedule the pod on a node. If the scheduler cannot find space on an appropriate node that satisfies all the specified requirements of the pod, preemption logic is triggered for the pending pod.
 
 When the scheduler preempts one or more pods on a node, the `nominatedNodeName` field of higher-priority pod specification is set to the name of the node, along with the `nodename` field. The scheduler uses the `nominatedNodeName` field to keep track of the resources reserved for pods and also provides information to the user about preemptions in the clusters.
 
diff --git a/modules/nodes-pods-secrets-about.adoc b/modules/nodes-pods-secrets-about.adoc
@@ -69,7 +69,7 @@ Specify one of the following types to trigger minimal server-side validation to
 * `kubernetes.io/ssh-auth`. Use with SSH Key Authentication.
 * `kubernetes.io/tls`. Use with TLS certificate authorities.
 
-Specify `type= Opaque` if you do not want validation, which means the secret does not claim to conform to any convention for key names or values.
+Specify `type: Opaque` if you do not want validation, which means the secret does not claim to conform to any convention for key names or values.
 An _opaque_ secret, allows for unstructured `key:value` pairs that can contain arbitrary values.
 
 [NOTE]
diff --git a/modules/nodes-pods-viewing-usage.adoc b/modules/nodes-pods-viewing-usage.adoc
@@ -28,11 +28,12 @@ $ oc adm top pods
 For example:
 +
 ----
-$ oc adm top pods
-NAME                         CPU(cores)   MEMORY(bytes)
-hawkular-cassandra-1-pqx6l   219m         1240Mi
-hawkular-metrics-rddnv       20m          1765Mi
-heapster-n94r4               3m           37Mi
+$ oc adm top pods -n openshift-console
+NAME                         CPU(cores)   MEMORY(bytes)   
+console-7f58c69899-q8c8k     0m           22Mi            
+console-7f58c69899-xhbgg     0m           25Mi            
+downloads-594fcccf94-bcxk8   3m           18Mi            
+downloads-594fcccf94-kv4p6   2m           15Mi            
 ----
 
 . Run the following command to view the usage statistics for pods with labels:
diff --git a/nodes/clusters/nodes-cluster-overcommit.adoc b/nodes/clusters/nodes-cluster-overcommit.adoc
@@ -27,8 +27,6 @@ include::modules/nodes-cluster-overcommit-resources-containers.adoc[leveloffset=
 
 include::modules/nodes-cluster-overcommit-qos-about.adoc[leveloffset=+1]
 
-include::modules/nodes-cluster-overcommit-master-disabling-swap.adoc[leveloffset=+2]
-
 include::modules/nodes-cluster-overcommit-configure-nodes.adoc[leveloffset=+1]
 
 include::modules/nodes-cluster-overcommit-node-enforcing.adoc[leveloffset=+2]
diff --git a/nodes/containers/nodes-containers-init.adoc b/nodes/containers/nodes-containers-init.adoc
@@ -20,6 +20,4 @@ include::modules/nodes-containers-init-about.adoc[leveloffset=+1]
 
 include::modules/nodes-containers-init-creating.adoc[leveloffset=+1]
 
-For more information on Init Containers, review the 
-link:https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#detailed-behavior[Kubernetes documentation].
 
diff --git a/nodes/containers/nodes-containers-volumes.adoc b/nodes/containers/nodes-containers-volumes.adoc
@@ -8,7 +8,8 @@ toc::[]
 
 
 
-You can use _volumes_ to persist data in a container after the container stops.
+Files in a container are ephemeral. As such, when a container crashes or stops, the data is lost.
+You can use _volumes_ to persist the data used by the containers in a pod. A volume is directory, accessible to the Containers in a Pod, where data is stored for the life of the pod.
 
 // The following include statements pull in the module files that comprise
 // the assembly. Include any combination of concept, procedure, or reference
@@ -29,6 +30,4 @@ include::modules/nodes-containers-volumes-removing.adoc[leveloffset=+1]
 
 include::modules/nodes-containers-volumes-subpath.adoc[leveloffset=+1]
 
-For more information on Init Containers, review the 
-link:https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#detailed-behavior[Kubernetes documentation].
 
diff --git a/nodes/pods/nodes-pods-viewing.adoc b/nodes/pods/nodes-pods-viewing.adoc

Original file line number	Diff line number	Diff line change
`@@ -16,11 +16,11 @@ $ oc get events [-n <project>] <1>`
`16`	`16`	`----`
`17`	`17`	`<1> The name of the project.`
`18`	`18`
`19`		`-* To view events in your project from the web console.`
	`19`	`+* To view events in your project from the {product-title} console.`
`20`	`20`	`+`
`21`		`-. Launch the web console.`
	`21`	`+. Launch the {product-title} console.`
`22`	`22`	`+`
`23`		`-. Launch the Browse -> Events page.`
	`23`	`+. Click Home -> Events and select your project.`
`24`	`24`	`+`
`25`	`25`	`Many other objects, such as pods and deployments, have their own`
`26`	`26`	`Events tab as well, which shows events related to that object.`