Merge branch 'master' into fix-restart-always-docs

content/en/docs/reference/access-authn-authz/rbac.md

@@ -1182,7 +1182,7 @@ allowed by *either* the RBAC or ABAC policies is allowed.
 
 When the kube-apiserver is run with a log level of 5 or higher for the RBAC component
 (`--vmodule=rbac*=5` or `--v=5`), you can see RBAC denials in the API server log
-(prefixed with `RBAC DENY:`).
+(prefixed with `RBAC`).
 You can use that information to determine which roles need to be granted to which users, groups, or service accounts.
 
 Once you have [granted roles to service accounts](#service-account-permissions) and workloads

content/en/docs/reference/glossary/cloud-controller-manager.md

@@ -4,7 +4,7 @@ id: cloud-controller-manager
 date: 2018-04-12
 full_link: /docs/tasks/administer-cluster/running-cloud-controller/
 short_description: >
-  Cloud Controller Manager is an alpha feature in 1.8. In upcoming releases it will be the preferred way to integrate Kubernetes with any cloud.
+  Cloud Controller Manager is a Kubernetes component that embeds cloud-specific control logic.
 
 aka: 
 tags:
@@ -12,8 +12,8 @@ tags:
 - architecture
 - operation
 ---
- Cloud Controller Manager is an alpha feature in 1.8. In upcoming releases it will be the preferred way to integrate Kubernetes with any cloud.
+ Cloud Controller Manager is a Kubernetes component that embeds cloud-specific control logic.
 
 <!--more--> 
 
-Kubernetes v1.6 contains a new binary called cloud-controller-manager. cloud-controller-manager is a daemon that embeds cloud-specific control loops. These cloud-specific control loops were originally in the kube-controller-manager. Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the cloud-controller-manager binary allows cloud vendors to evolve independently from the core Kubernetes code.
+Originally part of the kube-controller-manager, the cloud-controller-manager is responsible to decoupling the interoperability logic between Kubernetes and the underlying cloud infrastructure, enabling cloud providers to release features at a different pace compared to the main project.

content/en/docs/reference/glossary/container-runtime.md

@@ -2,7 +2,7 @@
 title: Container Runtime
 id: container-runtime
 date: 2019-06-05
-full_link: /docs/reference/generated/container-runtime
+full_link: /docs/setup/production-environment/container-runtimes
 short_description: >
  The container runtime is the software that is responsible for running containers.
 

content/en/docs/reference/glossary/host-aliases.md

@@ -2,7 +2,7 @@
 title: HostAliases
 id: HostAliases
 date: 2019-01-31
-full_link: /docs/reference/generated/kubernetes-api/v1.13/#hostalias-v1-core
+full_link: /docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core
 short_description: >
   A HostAliases is a mapping between the IP address and hostname to be injected into a Pod's hosts file.
 
@@ -14,4 +14,4 @@ tags:
 
 <!--more-->
 
-[HostAliases](/docs/reference/generated/kubernetes-api/v1.13/#hostalias-v1-corev) is an optional list of hostnames and IP addresses that will be injected into the Pod's hosts file if specified. This is only valid for non-hostNetwork Pods.
+[HostAliases](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core) is an optional list of hostnames and IP addresses that will be injected into the Pod's hosts file if specified. This is only valid for non-hostNetwork Pods.

content/en/docs/reference/glossary/service-account.md

@@ -1,5 +1,5 @@
 ---
-title: Service Account
+title: ServiceAccount
 id: service-account
 date: 2018-04-12
 full_link: /docs/tasks/configure-pod-container/configure-service-account/
@@ -16,4 +16,3 @@ tags:
 <!--more--> 
 
 When processes inside Pods access the cluster, they are authenticated by the API server as a particular service account, for example, `default`. When you create a Pod, if you do not specify a service account, it is automatically assigned the default service account in the same {{< glossary_tooltip text="Namespace" term_id="namespace" >}}.
-

content/en/docs/reference/using-api/api-concepts.md

@@ -89,7 +89,7 @@ A given Kubernetes server will only preserve a historical list of changes for a
 
 ### Watch bookmarks
 
-To mitigate the impact of short history window, we introduced a concept of `bookmark` watch event. It is a special kind of event to pass an information that all changes up to a given `resourceVersion` client is requesting has already been sent. Object returned in that event is of the type requested by the request, but only `resourceVersion` field is set, e.g.:
+To mitigate the impact of short history window, we introduced a concept of `bookmark` watch event. It is a special kind of event to mark that all changes up to a given `resourceVersion` the client is requesting have already been sent. Object returned in that event is of the type requested by the request, but only `resourceVersion` field is set, e.g.:
 
         GET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245&allowWatchBookmarks=true
         ---
@@ -334,6 +334,17 @@ are not vulnerable to ordering changes in the list.
 Once the last finalizer is removed, the resource is actually removed from etcd.
 
 
+## Single resource API
+
+API verbs GET, CREATE, UPDATE, PATCH, DELETE and PROXY support single resources only.
+These verbs with single resource support have no support for submitting
+multiple resources together in an ordered or unordered list or transaction.
+Clients including kubectl will parse a list of resources and make
+single-resource API requests.
+
+API verbs LIST and WATCH support getting multiple resources, and
+DELETECOLLECTION supports deleting multiple resources.
+
 ## Dry-run
 
  {{< feature-state for_k8s_version="v1.18" state="stable" >}}