Merge pull request #20768 from kbhawkey/konn-svc-move-kb

Move Konnectivity service task page

Author: k8s-ci-robot

content/en/docs/concepts/architecture/control-plane-node-communication.md

@@ -31,9 +31,11 @@ The control plane components also communicate with the cluster apiserver over th
 As a result, the default operating mode for connections from the nodes and pods running on the nodes to the control plane is secured by default and can run over untrusted and/or public networks.
 
 ## Control Plane to node
+
 There are two primary communication paths from the control plane (apiserver) to the nodes. The first is from the apiserver to the kubelet process which runs on each node in the cluster. The second is from the apiserver to any node, pod, or service through the apiserver's proxy functionality.
 
 ### apiserver to kubelet
+
 The connections from the apiserver to the kubelet are used for:
 
 * Fetching logs for pods.
@@ -61,9 +63,10 @@ This tunnel ensures that the traffic is not exposed outside of the network in wh
 SSH tunnels are currently deprecated so you shouldn't opt to use them unless you know what you are doing. The Konnectivity service is a replacement for this communication channel.
 
 ### Konnectivity service
+
 {{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
-As a replacement to the SSH tunnels, the Konnectivity service provides TCP level proxy for the control plane to Cluster communication. The Konnectivity consists of two parts, the Konnectivity server and the Konnectivity agents, running in the control plane network and the nodes network respectively. The Konnectivity agents initiate connections to the Konnectivity server and maintain the connections.
-All control plane to nodes traffic then goes through these connections.
+As a replacement to the SSH tunnels, the Konnectivity service provides TCP level proxy for the control plane to cluster communication. The Konnectivity service consists of two parts: the Konnectivity server and the Konnectivity agents, running in the control plane network and the nodes network respectively. The Konnectivity agents initiate connections to the Konnectivity server and maintain the network connections.
+After enabling the Konnectivity service, all control plane to nodes traffic goes through these connections.
 
-See [Konnectivity Service Setup](/docs/tasks/setup-konnectivity/) on how to set it up in your cluster.
+Follow the [Konnectivity service task](/docs/tasks/extend-kubernetes/setup-konnectivity/) to set up the Konnectivity service in your cluster.

content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md

@@ -39,9 +39,9 @@ to disable the timeout restriction. This deprecated feature gate will be removed
 ## {{% heading "whatsnext" %}}
 
 
-* To get the aggregator working in your environment, [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/).
-* Then, [setup an extension api-server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) to work with the aggregation layer.
-* Also, learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/).
+* To get the aggregator working in your environment, [configure the aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/).
+* Then, [setup an extension api-server](/docs/tasks/extend-kubernetes/setup-extension-api-server/) to work with the aggregation layer.
+* Also, learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
 * Read the specification for [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)
 
 

content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md

@@ -128,7 +128,7 @@ Regardless of how they are installed, the new resources are referred to as Custo
 
 ## CustomResourceDefinitions
 
-The [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)
+The [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
 API resource allows you to define custom resources.
 Defining a CRD object creates a new custom resource with a name and schema that you specify.
 The Kubernetes API serves and handles the storage of your custom resource.
@@ -178,17 +178,17 @@ Aggregated APIs offer more advanced API features and customization of other feat
 
 | Feature | Description | CRDs | Aggregated API |
 | ------- | ----------- | ---- | -------------- |
-| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes.  Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation).  Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks |
-| Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects). | Yes |
-| Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | Yes |
+| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes.  Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/extend-api-custom-resource-definitions/#validation).  Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks |
+| Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects). | Yes |
+| Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | Yes |
 | Custom Storage | If you need storage with a different performance mode (for example, a time-series database instead of key-value store) or isolation for security (for example, encryption of sensitive information, etc.) | No | Yes |
 | Custom Business Logic | Perform arbitrary checks or actions when creating, reading, updating or deleting an object | Yes, using [Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks). | Yes |
-| Scale Subresource | Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource)  | Yes |
-| Status Subresource | Allows fine-grained access control where user writes the spec section and the controller writes the status section. Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource) | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | Yes |
+| Scale Subresource | Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource)  | Yes |
+| Status Subresource | Allows fine-grained access control where user writes the spec section and the controller writes the status section. Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource) | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource) | Yes |
 | Other Subresources | Add operations other than CRUD, such as "logs" or "exec". | No | Yes |
 | strategic-merge-patch | The new endpoints support PATCH with `Content-Type: application/strategic-merge-patch+json`. Useful for updating objects that may be modified both locally, and by the server. For more information, see ["Update API Objects in Place Using kubectl patch"](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) | No | Yes |
 | Protocol Buffers | The new resource supports clients that want to use Protocol Buffers | No | Yes |
-| OpenAPI Schema | Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don't put an `int` in a `string` field?) | Yes, based on the [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) schema (GA in 1.16). | Yes |
+| OpenAPI Schema | Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don't put an `int` in a `string` field?) | Yes, based on the [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) schema (GA in 1.16). | Yes |
 
 ### Common Features
 
@@ -253,6 +253,6 @@ When you add a custom resource, you can access it using:
 
 * Learn how to [Extend the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
 
-* Learn how to [Extend the Kubernetes API with CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/).
+* Learn how to [Extend the Kubernetes API with CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
 
 

content/en/docs/concepts/overview/kubernetes-api.md

@@ -136,10 +136,10 @@ There are several API groups in a cluster:
 
 There are two paths to extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/):
 
-1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
+1. [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resource-definitions/)
    lets you declaratively define how the API server should provide your chosen resource API.
-1. You can also [implement your own extension API server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)
-   and use the [aggregator](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)
+1. You can also [implement your own extension API server](/docs/tasks/extend-kubernetes/setup-extension-api-server/)
+   and use the [aggregator](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
    to make it seamless for clients.
 
 ## Enabling or disabling API groups

content/en/docs/contribute/style/page-content-types.md

@@ -16,35 +16,39 @@ The Kubernetes documentation follows several types of page content:
 - Tutorial
 - Reference
 
-Content pages contain HTML headings that create structure on the page.
-
 <!-- body -->
 
 ## Content sections
 
-Each page content type contains a number of sections.
-Most of the main sections are outlined in the page using Markdown comments. 
-This page structure helps to maintain the different content types.
+Each page content type contains a number of sections declared as
+Markdown comments and HTML headings. HTML section headings render using the
+`heading` shortcode. This page structure helps to maintain the different content types.
 
-For example,
+Examples of Markdown comments defining page content sections:
 
-```
+```markdown
 <!-- body -->
 ```
 
-```
+```markdown
 <!-- overview -->
 ```
 
-To create localized headings for common headings, use the `heading` shortcode
-in your content pages. Common localized headings are:
+To create common headings in your content pages, use the `heading` shortcode with
+a heading string.
+
+Examples of heading strings:
 
 - whatsnext
 - prerequisites
 - objectives
 - cleanup
+- synopsis
+- seealso
+- options
 
-To create a localized `whatsnext` heading on a page, you can add to your page:
+To create a `whatsnext` heading, add the heading shortcode
+to your page as follows:
 
 ```none
 ## {{%/* heading "whatsnext" */%}}
@@ -54,29 +58,29 @@ The `whatsnext` heading displays as:
 
 ## {{% heading "whatsnext" %}}
 
-
-To create a localized `prerequisites` heading on a page, you can add to your page:
+You can declare a `prerequisites` heading as:
 
 ```none
 ## {{%/* heading "prerequisites" */%}}
 ```
 
-The `prerequisites heading displays as:
+The `prerequisites` heading displays as:
 
 ## {{% heading "prerequisites" %}}
 
+The `heading` shortcode takes one string parameter. The string matches the prefix
+of a variable in the `i18n/<lang>.toml` files.
 
-The `heading` shortcode takes one parameter.
-The string should match the prefix of a variable in the localized file, such `i18n/en.toml`:
+`i18n/en.toml`:
 
-```
+```toml
 [whatsnext_heading]
 other = "What's next"
 ```
 
-Another localized file, such as `i18n/ko.toml`:
+`i18n/ko.toml`:
 
-```
+```toml
 [whatsnext_heading]
 other = "다음 내용"
 ```
@@ -100,16 +104,16 @@ Concept pages are divided into three sections:
 | body          |
 | whatsnext     |
 
-
 Fill each section with content. Follow these guidelines:
+
 - Organize content with H2 and H3 headings.
 - For `overview`, set the topic's context with a single paragraph.
 - For `body`, explain the concept.
 - For `whatsnext`, provide a bulleted list of topics (5 maximum) to learn more about the concept.
 
 [Annotations](/docs/concepts/overview/working-with-objects/annotations/) is a published example of a concept page.
 
-## Task 
+## Task
 
 A task page shows how to do a single thing, typically by giving a short
 sequence of steps. Task pages have minimal explanation, but often provide links
@@ -127,6 +131,7 @@ To write a new task page, create a Markdown file in a subdirectory of the
 | whatsnext     |
 
 Within each section, write your content. Use the following guidelines:
+
 - Use a minimum of H2 headings (with two leading `#` characters). The sections
   themselves are titled automatically by the template.
 - For `overview`, use a paragraph to set context for the entire topic.
@@ -138,7 +143,7 @@ Within each section, write your content. Use the following guidelines:
 - For `whatsnext`, give a bullet list of up to 5 topics the reader might be
   interested in reading next.
 
-An example of a published task topic is [Using an HTTP proxy to access the Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api).
+An example of a published task topic is [Using an HTTP proxy to access the Kubernetes API](/docs/tasks/extend-kubernetes/http-proxy-access-api/).
 
 ## Tutorial
 
@@ -162,6 +167,7 @@ To write a new tutorial page, create a Markdown file in a subdirectory of the
 | whatsnext     |
 
 Within each section, write your content. Use the following guidelines:
+
 - Use a minimum of H2 headings (with two leading `#` characters). The sections
   themselves are titled automatically by the template.
 - For `overview`, use a paragraph to set context for the entire topic.
@@ -180,21 +186,21 @@ An example of a published tutorial topic is
 
 ## Reference
 
-A component tool reference page shows the `--help` output for a Kubernetes component tool.
-Each page output depends upon the component tool's source code in `kubernetes/kubernetes`.
+A component tool reference page shows the description and flag options output for
+a Kubernetes component tool. Each page output depends upon the component tool's source
+code in `kubernetes/kubernetes`.
 
-Typically a tool reference page has several sections:
+A tool reference page has several possible sections:
 
 | Page section                 |
 |------------------------------|
 | synopsis                     |
 | options                      |
 | options from parent commands |
 | examples                     |
-| body                         |
 | seealso                      |
 
-An example of a published tool reference topic is:
+Examples of published tool reference pages are:
 
 - [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/)
 - [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)

content/en/docs/contribute/style/write-new-topic.md

@@ -37,12 +37,12 @@ consistency among topics of a given type.
 Choose a title that has the keywords you want search engines to find.
 Create a filename that uses the words in your title separated by hyphens.
 For example, the topic with title
-[Using an HTTP Proxy to Access the Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api/)
+[Using an HTTP Proxy to Access the Kubernetes API](/docs/tasks/extend-kubernetes/http-proxy-access-api/)
 has filename `http-proxy-access-api.md`. You don't need to put
 "kubernetes" in the filename, because "kubernetes" is already in the
 URL for the topic, for example:
 
-       /docs/tasks/access-kubernetes-api/http-proxy-access-api/
+       /docs/tasks/extend-kubernetes/http-proxy-access-api/
 
 ## Adding the topic title to the front matter
 

content/en/docs/reference/glossary/aggregation-layer.md

@@ -14,6 +14,6 @@ tags:
 ---
  The aggregation layer lets you install additional Kubernetes-style APIs in your cluster.
 
-<!--more--> 
+<!--more-->
 
-When you've configured the {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} to [support additional APIs](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/), you can add `APIService` objects to "claim" a URL path in the Kubernetes API.
+When you've configured the {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} to [support additional APIs](/docs/tasks/extend-kubernetes/configure-aggregation-layer/), you can add `APIService` objects to "claim" a URL path in the Kubernetes API.

content/en/docs/reference/glossary/customresourcedefinition.md

@@ -2,7 +2,7 @@
 title: CustomResourceDefinition
 id: CustomResourceDefinition
 date: 2018-04-12
-full_link: /docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/
+full_link: /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
 short_description: >
   Custom code that defines a resource to add to your Kubernetes API server without building a complete custom server.
 
@@ -14,7 +14,6 @@ tags:
 ---
  Custom code that defines a resource to add to your Kubernetes API server without building a complete custom server.
 
-<!--more--> 
-
-Custom Resource Definitions let you extend the Kubernetes API for your environment if the publicly supported API resources can't meet your needs. 
+<!--more-->
 
+Custom Resource Definitions let you extend the Kubernetes API for your environment if the publicly supported API resources can't meet your needs.

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

@@ -86,7 +86,7 @@ Currently, there are several API groups in use:
 
 The two paths that support extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/) are:
 
- - [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
+ - [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
    for basic CRUD needs.
  - [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md) for a full set of Kubernetes API semantics to implement their own apiserver.