add en pages

2020-05-30 15:10:23 -04:00
parent 1502e0281d
commit ecc27bbbe7
347 changed files with 2900 additions and 2537 deletions
@@ -1,9 +1,9 @@
 ---
 title: Installing Addons
-content_template: templates/concept
+content_type: concept
 ---

-{{% capture overview %}}
+<!-- overview -->


 Add-ons extend the functionality of Kubernetes.
@@ -12,10 +12,10 @@ This page lists some of the available add-ons and links to their respective inst

 Add-ons in each section are sorted alphabetically - the ordering does not imply any preferential status.

-{{% /capture %}}


-{{% capture body %}}
+
+<!-- body -->

 ## Networking and Network Policy

@@ -55,4 +55,4 @@ There are several other add-ons documented in the deprecated [cluster/addons](ht

 Well-maintained ones should be linked to here. PRs welcome!

-{{% /capture %}}
+
@@ -1,19 +1,19 @@
 ---
 title: Certificates
-content_template: templates/concept
+content_type: concept
 weight: 20
 ---


-{{% capture overview %}}
+<!-- overview -->

 When using client certificate authentication, you can generate certificates
 manually through `easyrsa`, `openssl` or `cfssl`.

-{{% /capture %}}


-{{% capture body %}}
+
+<!-- body -->

 ### easyrsa

@@ -249,4 +249,4 @@ You can use the `certificates.k8s.io` API to provision
 x509 certificates to use for authentication as documented
 [here](/docs/tasks/tls/managing-tls-in-a-cluster).

-{{% /capture %}}
+
@@ -1,16 +1,16 @@
 ---
 title: Cloud Providers
-content_template: templates/concept
+content_type: concept
 weight: 30
 ---

-{{% capture overview %}}
+<!-- overview -->
 This page explains how to manage Kubernetes running on a specific
 cloud provider.
-{{% /capture %}}


-{{% capture body %}}
+
+<!-- body -->
 ### kubeadm
 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) is a popular option for creating kubernetes clusters.
 kubeadm has configuration options to specify configuration information for cloud providers. For example a typical
@@ -363,7 +363,7 @@ Kubernetes network plugin and should appear in the `[Route]` section of the

 [kubenet]: /docs/concepts/cluster-administration/network-plugins/#kubenet

-{{% /capture %}}
+

 ## OVirt

@@ -3,16 +3,16 @@ reviewers:
 - davidopp
 - lavalamp
 title: Cluster Administration Overview
-content_template: templates/concept
+content_type: concept
 weight: 10
 ---

-{{% capture overview %}}
+<!-- overview -->
 The cluster administration overview is for anyone creating or administering a Kubernetes cluster.
 It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/).
-{{% /capture %}}

-{{% capture body %}}
+
+<!-- body -->
 ## Planning a cluster

 See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*.
@@ -68,6 +68,6 @@ Note: Not all distros are actively maintained. Choose distros which have been te

 * [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it.

-{{% /capture %}}
+


@@ -1,10 +1,10 @@
 ---
 title: API Priority and Fairness
-content_template: templates/concept
+content_type: concept
 min-kubernetes-server-version: v1.18
 ---

-{{% capture overview %}}
+<!-- overview -->

 {{< feature-state state="alpha"  for_k8s_version="v1.18" >}}

@@ -33,9 +33,9 @@ the `--max-requests-inflight` flag without the API Priority and
 Fairness feature enabled.
 {{< /caution >}}

-{{% /capture %}}

-{{% capture body %}}
+
+<!-- body -->

 ## Enabling API Priority and Fairness

@@ -366,13 +366,13 @@ poorly-behaved workloads that may be harming system health.
  request and the PriorityLevel to which it was assigned.


-{{% /capture %}}

-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+

 For background information on design details for API priority and fairness, see
 the [enhancement proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md).
 You can make suggestions and feature requests via [SIG API
 Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).

-{{% /capture %}}
@@ -1,20 +1,20 @@
 ---
 reviewers:
 title: Configuring kubelet Garbage Collection
-content_template: templates/concept
+content_type: concept
 weight: 70
 ---

-{{% capture overview %}}
+<!-- overview -->

 Garbage collection is a helpful function of kubelet that will clean up unused images and unused containers. Kubelet will perform garbage collection for containers every minute and garbage collection for images every five minutes.

 External garbage collection tools are not recommended as these tools can potentially break the behavior of kubelet by removing containers expected to exist.

-{{% /capture %}}


-{{% capture body %}}
+
+<!-- body -->

 ## Image Collection

@@ -77,10 +77,11 @@ Including:
 | `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | eviction generalizes disk thresholds to other resources |
 | `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | eviction generalizes disk pressure transition to other resources |

-{{% /capture %}}

-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+

 See [Configuring Out Of Resource Handling](/docs/tasks/administer-cluster/out-of-resource/) for more details.

-{{% /capture %}}
+
@@ -3,20 +3,20 @@ reviewers:
 - piosz
 - x13n
 title: Logging Architecture
-content_template: templates/concept
+content_type: concept
 weight: 60
 ---

-{{% capture overview %}}
+<!-- overview -->

 Application and systems logs can help you understand what is happening inside your cluster. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism; as such, most container engines are likewise designed to support some kind of logging. The easiest and most embraced logging method for containerized applications is to write to the standard output and standard error streams.

 However, the native functionality provided by a container engine or runtime is usually not enough for a complete logging solution. For example, if a container crashes, a pod is evicted, or a node dies, you'll usually still want to access your application's logs. As such, logs should have a separate storage and lifecycle independent of nodes, pods, or containers. This concept is called _cluster-level-logging_. Cluster-level logging requires a separate backend to store, analyze, and query logs. Kubernetes provides no native storage solution for log data, but you can integrate many existing logging solutions into your Kubernetes cluster.

-{{% /capture %}}


-{{% capture body %}}
+
+<!-- body -->

 Cluster-level logging architectures are described in assumption that
 a logging backend is present inside or outside of your cluster. If you're
@@ -267,4 +267,4 @@ You can implement cluster-level logging by exposing or pushing logs directly fro
 every application; however, the implementation for such a logging mechanism
 is outside the scope of Kubernetes.

-{{% /capture %}}
+
@@ -2,18 +2,18 @@
 reviewers:
 - janetkuo
 title: Managing Resources
-content_template: templates/concept
+content_type: concept
 weight: 40
 ---

-{{% capture overview %}}
+<!-- overview -->

 You've deployed your application and exposed it via a service. Now what? Kubernetes provides a number of tools to help you manage your application deployment, including scaling and updating. Among the features that we will discuss in more depth are [configuration files](/docs/concepts/configuration/overview/) and [labels](/docs/concepts/overview/working-with-objects/labels/).

-{{% /capture %}}


-{{% capture body %}}
+
+<!-- body -->

 ## Organizing resource configurations

@@ -449,11 +449,12 @@ kubectl edit deployment/my-nginx

 That's it! The Deployment will declaratively update the deployed nginx application progressively behind the scene. It ensures that only a certain number of old replicas may be down while they are being updated, and only a certain number of new replicas may be created above the desired number of pods. To learn more details about it, visit [Deployment page](/docs/concepts/workloads/controllers/deployment/).

-{{% /capture %}}

-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+

 - Learn about [how to use `kubectl` for application introspection and debugging](/docs/tasks/debug-application-cluster/debug-application-introspection/).
 - See [Configuration Best Practices and Tips](/docs/concepts/configuration/overview/).

-{{% /capture %}}
+
@@ -4,21 +4,21 @@ reviewers:
 - brancz
 - logicalhan
 - RainbowMango
-content_template: templates/concept
+content_type: concept
 weight: 60
 aliases:
 - controller-metrics.md
 ---

-{{% capture overview %}}
+<!-- overview -->

 System component metrics can give a better look into what is happening inside them. Metrics are particularly useful for building dashboards and alerts.

 Metrics in Kubernetes control plane are emitted in [prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/) and are human readable.

-{{% /capture %}}

-{{% capture body %}}
+
+<!-- body -->

 ## Metrics in Kubernetes

@@ -124,10 +124,11 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
 cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
 ```

-{{% /capture %}}

-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
 * Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics
 * See the list of [stable Kubernetes metrics](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)
 * Read about the [Kubernetes deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
-{{% /capture %}}
+
@@ -2,11 +2,11 @@
 reviewers:
 - thockin
 title: Cluster Networking
-content_template: templates/concept
+content_type: concept
 weight: 50
 ---

-{{% capture overview %}}
+<!-- overview -->
 Networking is a central part of Kubernetes, but it can be challenging to
 understand exactly how it is expected to work.  There are 4 distinct networking
 problems to address:
@@ -17,10 +17,10 @@ problems to address:
 3. Pod-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/).
 4. External-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/).

-{{% /capture %}}


-{{% capture body %}}
+
+<!-- body -->

 Kubernetes is all about sharing machines between applications.  Typically,
 sharing machines requires ensuring that two applications do not try to use the
@@ -312,12 +312,13 @@ Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-pl
 or stand-alone.  In either version, it doesn't require any configuration or extra code
 to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes.

-{{% /capture %}}

-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+

 The early design of the networking model and its rationale, and some future
 plans are described in more detail in the [networking design
 document](https://git.k8s.io/community/contributors/design-proposals/network/networking.md).

-{{% /capture %}}
+
@@ -1,14 +1,14 @@
 ---
 title: Proxies in Kubernetes
-content_template: templates/concept
+content_type: concept
 weight: 90
 ---

-{{% capture overview %}}
+<!-- overview -->
 This page explains proxies used with Kubernetes.
-{{% /capture %}}

-{{% capture body %}}
+
+<!-- body -->

 ## Proxies

@@ -62,6 +62,6 @@ will typically ensure that the latter types are setup correctly.

 Proxies have replaced redirect capabilities.  Redirects have been deprecated.

-{{% /capture %}}
+