resolving conflicts

content/en/docs/concepts/configuration/configmap.md

@@ -126,25 +126,32 @@ spec:
       configMap:
         # Provide the name of the ConfigMap you want to mount.
         name: game-demo
+        # An array of keys from the ConfigMap to create as files
+        items:
+        - key: "game.properties"
+          path: "game.properties"
+        - key: "user-interface.properties"
+          path: "user-interface.properties"
 ```
 
 
 A ConfigMap doesn't differentiate between single line property values and
 multi-line file-like values.
 What matters is how Pods and other objects consume those values.
+
 For this example, defining a volume and mounting it inside the `demo`
-container as `/config` creates four files:
+container as `/config` creates two files,
+`/config/game.properties` and `/config/user-interface.properties`,
+even though there are four keys in the ConfigMap. This is because the Pod
+definition specifies an `items` array in the `volumes` section.
+If you omit the `items` array entirely, every key  in the ConfigMap becomes
+a file with the same name as the key, and you get 4 files.
 
-- `/config/player_initial_lives`
-- `/config/ui_properties_file_name`
-- `/config/game.properties`
-- `/config/user-interface.properties`
+## Using ConfigMaps
 
-If you want to make sure that `/config` only contains files with a
-`.properties` extension, use two different ConfigMaps, and refer to both
-ConfigMaps in the `spec` for a Pod. The first ConfigMap defines
-`player_initial_lives` and `ui_properties_file_name`. The second
-ConfigMap defines the files that the kubelet places into `/config`.
+ConfigMaps can be mounted as data volumes. ConfigMaps can also be used by other
+parts of the system, without being directly exposed to the Pod. For example,
+ConfigMaps can hold data that other parts of the system should use for configuration.
 
 {{< note >}}
 The most common way to use ConfigMaps is to configure settings for
@@ -157,12 +164,6 @@ or {{< glossary_tooltip text="operators" term_id="operator-pattern" >}} that
 adjust their behavior based on a ConfigMap.
 {{< /note >}}
 
-## Using ConfigMaps
-
-ConfigMaps can be mounted as data volumes. ConfigMaps can also be used by other
-parts of the system, without being directly exposed to the Pod. For example,
-ConfigMaps can hold data that other parts of the system should use for configuration.
-
 ### Using ConfigMaps as files from a Pod
 
 To consume a ConfigMap in a volume in a Pod:

content/en/docs/concepts/configuration/manage-resources-containers.md

@@ -227,7 +227,7 @@ locally-attached writeable devices or, sometimes, by RAM.
 
 Pods use ephemeral local storage for scratch space, caching, and for logs.
 The kubelet can provide scratch space to Pods using local ephemeral storage to
-mount [`emptyDir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir)
+mount [`emptyDir`](/docs/concepts/storage/volumes/#emptydir)
  {{< glossary_tooltip term_id="volume" text="volumes" >}} into containers.
 
 The kubelet also uses this kind of storage to hold
@@ -657,7 +657,7 @@ Allocated resources:
   (Total limits may be over 100 percent, i.e., overcommitted.)
   CPU Requests    CPU Limits    Memory Requests    Memory Limits
   ------------    ----------    ---------------    -------------
-  680m (34%)      400m (20%)    920Mi (12%)        1070Mi (14%)
+  680m (34%)      400m (20%)    920Mi (11%)        1070Mi (13%)
 ```
 
 In the preceding output, you can see that if a Pod requests more than 1120m
@@ -758,5 +758,3 @@ You can see that the Container was terminated because of `reason:OOM Killed`, wh
 * Read the [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API reference
 
 * Read about [project quotas](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS
-
-

content/en/docs/concepts/configuration/pod-overhead.md

@@ -87,7 +87,7 @@ spec:
         memory: 100Mi
 ```
 
-At admission time the RuntimeClass [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)
+At admission time the RuntimeClass [admission controller](/docs/reference/access-authn-authz/admission-controllers/)
 updates the workload's PodSpec to include the `overhead` as described in the RuntimeClass. If the PodSpec already has this field defined,
 the Pod will be rejected. In the given example, since only the RuntimeClass name is specified, the admission controller mutates the Pod
 to include an `overhead`.
@@ -195,5 +195,3 @@ from source in the meantime.
 
 * [RuntimeClass](/docs/concepts/containers/runtime-class/)
 * [PodOverhead Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
-
-