update with master content resolving merge conflicts

content/en/docs/concepts/configuration/assign-pod-node.md

@@ -256,6 +256,7 @@ be co-located in the same defined topology, eg., the same node.
 ##### Always co-located in the same node
 
 In a three node cluster, a web application has in-memory cache such as redis. We want the web-servers to be co-located with the cache as much as possible.
+
 Here is the yaml snippet of a simple redis deployment with three replicas and selector label `app=store`. The deployment has `PodAntiAffinity` configured to ensure the scheduler does not co-locate replicas on a single node.
 
 ```yaml
@@ -339,7 +340,10 @@ If we create the above two deployments, our three node cluster should look like
 As you can see, all the 3 replicas of the `web-server` are automatically co-located with the cache as expected.
 
 ```
-$ kubectl get pods -o wide
+kubectl get pods -o wide
+```
+The output is similar to this:
+```
 NAME                           READY     STATUS    RESTARTS   AGE       IP           NODE
 redis-cache-1450370735-6dzlj   1/1       Running   0          8m        10.192.4.2   kube-node-3
 redis-cache-1450370735-j2j96   1/1       Running   0          8m        10.192.2.2   kube-node-1

content/en/docs/concepts/configuration/manage-compute-resources-container.md

@@ -3,7 +3,7 @@ title: Managing Compute Resources for Containers
 content_template: templates/concept
 weight: 20
 feature:
-  title: Automatic binpacking
+  title: Automatic bin packing
   description: >
     Automatically places containers based on their resource requirements and other constraints, while not sacrificing availability. Mix critical and best-effort workloads in order to drive up utilization and save even more resources.
 ---

content/en/docs/concepts/configuration/pod-priority-preemption.md

@@ -34,7 +34,7 @@ Kubernetes Version | Priority and Preemption State | Enabled by default
 1.9                | alpha                         | no
 1.10               | alpha                         | no
 1.11               | beta                          | yes
-1.14               | GA                            | yes
+1.14               | stable                        | yes
 
 {{< warning >}}In a cluster where not all users are trusted, a
 malicious user could create pods at the highest possible priorities, causing
@@ -143,7 +143,7 @@ cluster when they should use this PriorityClass.
 ### Example PriorityClass
 
 ```yaml
-apiVersion: scheduling.k8s.io/v1beta1
+apiVersion: scheduling.k8s.io/v1
 kind: PriorityClass
 metadata:
   name: high-priority
@@ -334,9 +334,8 @@ preempted. Here's an example:
 If Pod Q were removed from its Node, the Pod anti-affinity violation would be
 gone, and Pod P could possibly be scheduled on Node N.
 
-We may consider adding cross Node preemption in future versions if we find an
-algorithm with reasonable performance. We cannot promise anything at this point,
-and cross Node preemption will not be considered a blocker for Beta or GA.
+We may consider adding cross Node preemption in future versions if there is
+enough demand and if we find an algorithm with reasonable performance.
 
 ## Debugging Pod Priority and Preemption
 

content/en/docs/concepts/configuration/scheduler-perf-tuning.md

@@ -43,7 +43,7 @@ smaller than 5.
 Below is an example configuration that sets `percentageOfNodesToScore` to 50%.
 
 ```yaml
-apiVersion: componentconfig/v1alpha1
+apiVersion: kubescheduler.config.k8s.io/v1alpha1
 kind: KubeSchedulerConfiguration
 algorithmSource:
   provider: DefaultProvider

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

@@ -75,11 +75,11 @@ kubectl create secret generic db-user-pass --from-file=./username.txt --from-fil
 ```
 secret "db-user-pass" created
 ```
-{{< note >}}	
-Special characters such as `$`, `\*`, and `!` require escaping.	
-If the password you are using has special characters, you need to escape them using the `\\` character. For example, if your actual password is `S!B\*d$zDsb`, you should execute the command this way:	
-     kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password=S\\!B\\\*d\\$zDsb	
- You do not need to escape special characters in passwords from files (`--from-file`).	
+{{< note >}}
+Special characters such as `$`, `\*`, and `!` require escaping.
+If the password you are using has special characters, you need to escape them using the `\\` character. For example, if your actual password is `S!B\*d$zDsb`, you should execute the command this way:
+     kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password=S\\!B\\\\*d\\$zDsb
+ You do not need to escape special characters in passwords from files (`--from-file`).
 {{< /note >}}
 
 You can check that the secret was created like this:
@@ -203,8 +203,6 @@ The output will be similar to:
 
 ```yaml
 apiVersion: v1
-data:
-  config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
 kind: Secret
 metadata:
   creationTimestamp: 2018-11-15T20:40:59Z
@@ -214,6 +212,8 @@ metadata:
   selfLink: /api/v1/namespaces/default/secrets/mysecret
   uid: c280ad2e-e916-11e8-98f2-025000000001
 type: Opaque
+data:
+  config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
 ```
 
 If a field is specified in both data and stringData, the value from stringData
@@ -235,8 +235,6 @@ Results in the following secret:
 
 ```yaml
 apiVersion: v1
-data:
-  username: YWRtaW5pc3RyYXRvcg==
 kind: Secret
 metadata:
   creationTimestamp: 2018-11-15T20:46:46Z
@@ -246,6 +244,8 @@ metadata:
   selfLink: /api/v1/namespaces/default/secrets/mysecret
   uid: 91460ecb-e917-11e8-98f2-025000000001
 type: Opaque
+data:
+  username: YWRtaW5pc3RyYXRvcg==
 ```
 
 Where `YWRtaW5pc3RyYXRvcg==` decodes to `administrator`.
@@ -261,9 +261,9 @@ the option `-w 0` to `base64` commands or the pipeline `base64 | tr -d '\n'` if
 `-w` option is not available.
 
 #### Creating a Secret from Generator
-Kubectl supports [managing objects using Kustomize](/docs/concepts/overview/object-management-kubectl/kustomization/)
+Kubectl supports [managing objects using Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/)
 since 1.14. With this new feature,
-you can also create a Secret from generators and then apply it to create the object on 
+you can also create a Secret from generators and then apply it to create the object on
 the Apiserver. The generators
 should be specified in a `kustomization.yaml` inside a directory.
 
@@ -306,7 +306,7 @@ username.txt:    5 bytes
 ```
 
 For example, to generate a Secret from literals `username=admin` and `password=secret`,
-you can specify the secret generator in `kusotmization.yaml` as
+you can specify the secret generator in `kustomization.yaml` as
 ```shell
 # Create a kustomization.yaml file with SecretGenerator
 $ cat <<EOF >./kustomization.yaml
@@ -336,9 +336,6 @@ kubectl get secret mysecret -o yaml
 ```
 ```
 apiVersion: v1
-data:
-  username: YWRtaW4=
-  password: MWYyZDFlMmU2N2Rm
 kind: Secret
 metadata:
   creationTimestamp: 2016-01-22T18:41:56Z
@@ -348,6 +345,9 @@ metadata:
   selfLink: /api/v1/namespaces/default/secrets/mysecret
   uid: cfee02d6-c137-11e5-8d73-42010af00002
 type: Opaque
+data:
+  username: YWRtaW4=
+  password: MWYyZDFlMmU2N2Rm
 ```
 
 Decode the password field:
@@ -359,7 +359,7 @@ echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
 1f2d1e2e67df
 ```
 
-### Using Secrets
+## Using Secrets
 
 Secrets can be mounted as data volumes or be exposed as
 {{< glossary_tooltip text="environment variables" term_id="container-env-variables" >}}
@@ -368,7 +368,7 @@ system, without being directly exposed to the pod.  For example, they can hold
 credentials that other parts of the system should use to interact with external
 systems on your behalf.
 
-#### Using Secrets as Files from a Pod
+### Using Secrets as Files from a Pod
 
 To consume a Secret in a volume in a Pod:
 
@@ -521,12 +521,15 @@ ls /etc/foo/
 username
 password
 ```
+
 ```shell
 cat /etc/foo/username
 ```
 ```
 admin
 ```
+
+
 ```shell
 cat /etc/foo/password
 ```
@@ -557,7 +560,7 @@ A container using a Secret as a
 Secret updates.
 {{< /note >}}
 
-#### Using Secrets as Environment Variables
+### Using Secrets as Environment Variables
 
 To use a secret in an {{< glossary_tooltip text="environment variable" term_id="container-env-variables" >}}
 in a pod:
@@ -610,7 +613,7 @@ echo $SECRET_PASSWORD
 1f2d1e2e67df
 ```
 
-#### Using imagePullSecrets
+### Using imagePullSecrets
 
 An imagePullSecret is a way to pass a secret that contains a Docker (or other) image registry
 password to the Kubelet so it can pull a private image on behalf of your Pod.
@@ -694,9 +697,11 @@ start until all the pod's volumes are mounted.
 ### Use-Case: Pod with ssh keys
 
 Create a kustomization.yaml with SecretGenerator containing some ssh keys:
+
 ```shell
 kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub
 ```
+
 ```
 secret "ssh-key-secret" created
 ```
@@ -710,8 +715,8 @@ Now we can create a pod which references the secret with the ssh key and
 consumes it in a volume:
 
 ```yaml
-kind: Pod
 apiVersion: v1
+kind: Pod
 metadata:
   name: secret-test-pod
   labels:
@@ -746,6 +751,7 @@ credentials and another pod which consumes a secret with test environment
 credentials.
 
 Make the kustomization.yaml with SecretGenerator
+
 ```shell
 kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11
 ```
@@ -753,6 +759,23 @@ kubectl create secret generic prod-db-secret --from-literal=username=produser --
 secret "prod-db-secret" created
 ```
 
+```shell
+kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests
+```
+```
+secret "test-db-secret" created
+```
+{{< note >}}
+Special characters such as `$`, `\*`, and `!` require escaping.
+If the password you are using has special characters, you need to escape them using the `\\` character. For example, if your actual password is `S!B\*d$zDsb`, you should execute the command this way:
+
+```shell
+kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password=S\\!B\\\*d\\$zDsb
+```
+
+You do not need to escape special characters in passwords from files (`--from-file`).
+{{< /note >}}
+
 Now make the pods:
 
 ```shell
@@ -828,8 +851,8 @@ one called, say, `prod-user` with the `prod-db-secret`, and one called, say,
 `test-user` with the `test-db-secret`.  Then, the pod spec can be shortened to, for example:
 
 ```yaml
-kind: Pod
 apiVersion: v1
+kind: Pod
 metadata:
   name: prod-db-client-pod
   labels:
@@ -847,15 +870,15 @@ In order to make piece of data 'hidden' (i.e., in a file whose name begins with
 make that key begin with a dot.  For example, when the following secret is mounted into a volume:
 
 ```yaml
-kind: Secret
 apiVersion: v1
+kind: Secret
 metadata:
   name: dotfile-secret
 data:
   .secret-file: dmFsdWUtMg0KDQo=
 ---
-kind: Pod
 apiVersion: v1
+kind: Pod
 metadata:
   name: secret-dotfiles-pod
 spec: