Code of conduct Videos
diff --git a/content/en/docs/concepts/_index.md b/content/en/docs/concepts/_index.md
index 0cb970fd66..8165a3a1f4 100644
--- a/content/en/docs/concepts/_index.md
+++ b/content/en/docs/concepts/_index.md
@@ -1,71 +1,14 @@
---
title: Concepts
main_menu: true
-content_template: templates/concept
+content_type: concept
weight: 40
---
-{{% capture overview %}}
+
The Concepts section helps you learn about the parts of the Kubernetes system and the abstractions Kubernetes uses to represent your {{< glossary_tooltip text="cluster" term_id="cluster" length="all" >}}, and helps you obtain a deeper understanding of how Kubernetes works.
-{{% /capture %}}
-
-{{% capture body %}}
-
-## Overview
-
-To work with Kubernetes, you use *Kubernetes API objects* to describe your cluster's *desired state*: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, `kubectl`. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state.
-
-Once you've set your desired state, the *Kubernetes Control Plane* makes the cluster's current state match the desired state via the Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster:
-
-* The **Kubernetes Master** is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and [kube-scheduler](/docs/admin/kube-scheduler/).
-* Each individual non-master node in your cluster runs two processes:
- * **[kubelet](/docs/admin/kubelet/)**, which communicates with the Kubernetes Master.
- * **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node.
-
-## Kubernetes objects
-
-Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API. See [Understanding Kubernetes objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) for more details.
-
-The basic Kubernetes objects include:
-
-* [Pod](/docs/concepts/workloads/pods/pod-overview/)
-* [Service](/docs/concepts/services-networking/service/)
-* [Volume](/docs/concepts/storage/volumes/)
-* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)
-
-Kubernetes also contains higher-level abstractions that rely on [controllers](/docs/concepts/architecture/controller/) to build upon the basic objects, and provide additional functionality and convenience features. These include:
-
-* [Deployment](/docs/concepts/workloads/controllers/deployment/)
-* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
-* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
-* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
-* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
-
-## Kubernetes Control Plane
-
-The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system match the desired state that you provided.
-
-For example, when you use the Kubernetes API to create a Deployment, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes--thus making the cluster's actual state match the desired state.
-
-### Kubernetes Master
-
-The Kubernetes master is responsible for maintaining the desired state for your cluster. When you interact with Kubernetes, such as by using the `kubectl` command-line interface, you're communicating with your cluster's Kubernetes master.
-
-> The "master" refers to a collection of processes managing the cluster state. Typically all these processes run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundancy.
-
-### Kubernetes Nodes
-
-The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. The Kubernetes master controls each node; you'll rarely interact with nodes directly.
-{{% /capture %}}
-
-{{% capture whatsnext %}}
-
-If you would like to write a concept page, see
-[Using Page Templates](/docs/home/contribute/page-templates/)
-for information about the concept page type and the concept template.
-
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/architecture/_index.md b/content/en/docs/concepts/architecture/_index.md
index 3a17d1b08e..61fb48e714 100755
--- a/content/en/docs/concepts/architecture/_index.md
+++ b/content/en/docs/concepts/architecture/_index.md
@@ -1,5 +1,7 @@
---
title: "Cluster Architecture"
weight: 30
+description: >
+ The architectural concepts behind Kubernetes.
---
diff --git a/content/en/docs/concepts/architecture/cloud-controller.md b/content/en/docs/concepts/architecture/cloud-controller.md
index 31c0ad9d54..9a731b684a 100644
--- a/content/en/docs/concepts/architecture/cloud-controller.md
+++ b/content/en/docs/concepts/architecture/cloud-controller.md
@@ -1,10 +1,10 @@
---
title: Cloud Controller Manager
-content_template: templates/concept
+content_type: concept
weight: 40
---
-{{% capture overview %}}
+
{{< feature-state state="beta" for_k8s_version="v1.11" >}}
@@ -17,9 +17,9 @@ components.
The cloud-controller-manager is structured using a plugin
mechanism that allows different cloud providers to integrate their platforms with Kubernetes.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Design
@@ -200,8 +200,9 @@ rules:
- update
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
[Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
has instructions on running and managing the cloud controller manager.
@@ -212,4 +213,3 @@ The cloud controller manager uses Go interfaces to allow implementations from an
The implementation of the shared controllers highlighted in this document (Node, Route, and Service), and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core. Implementations specific to cloud providers are outside the core of Kubernetes and implement the `CloudProvider` interface.
For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
-{{% /capture %}}
\ No newline at end of file
diff --git a/content/en/docs/concepts/architecture/control-plane-node-communication.md b/content/en/docs/concepts/architecture/control-plane-node-communication.md
index 940b8faacc..925f14d17a 100644
--- a/content/en/docs/concepts/architecture/control-plane-node-communication.md
+++ b/content/en/docs/concepts/architecture/control-plane-node-communication.md
@@ -1,25 +1,24 @@
---
reviewers:
- dchen1107
-- roberthbailey
- liggitt
title: Control Plane-Node Communication
-content_template: templates/concept
+content_type: concept
weight: 20
aliases:
- master-node-communication
---
-{{% capture overview %}}
+
This document catalogs the communication paths between the control plane (really the apiserver) and the Kubernetes cluster. The intent is to allow users to customize their installation to harden the network configuration such that the cluster can be run on an untrusted network (or on fully public IPs on a cloud provider).
-{{% /capture %}}
-{{% capture body %}}
+
+
## Node to Control Plane
-All communication paths from the nodes to the control plane terminate at the apiserver (none of the other master components are designed to expose remote services). In a typical deployment, the apiserver is configured to listen for remote connections on a secure HTTPS port (443) with one or more forms of client [authentication](/docs/reference/access-authn-authz/authentication/) enabled.
+Kubernetes has a "hub-and-spoke" API pattern. All API usage from nodes (or the pods they run) terminate at the apiserver (none of the other control plane components are designed to expose remote services). The apiserver is configured to listen for remote connections on a secure HTTPS port (typically 443) with one or more forms of client [authentication](/docs/reference/access-authn-authz/authentication/) enabled.
One or more forms of [authorization](/docs/reference/access-authn-authz/authorization/) should be enabled, especially if [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests) or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) are allowed.
Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. For example, on a default GKE deployment, the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates.
@@ -32,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.
@@ -62,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.
diff --git a/content/en/docs/concepts/architecture/controller.md b/content/en/docs/concepts/architecture/controller.md
index 2872959bac..547a624a94 100644
--- a/content/en/docs/concepts/architecture/controller.md
+++ b/content/en/docs/concepts/architecture/controller.md
@@ -1,10 +1,10 @@
---
title: Controllers
-content_template: templates/concept
+content_type: concept
weight: 30
---
-{{% capture overview %}}
+
In robotics and automation, a _control loop_ is
a non-terminating loop that regulates the state of a system.
@@ -18,10 +18,10 @@ closer to the desired state, by turning equipment on or off.
{{< glossary_definition term_id="controller" length="short">}}
-{{% /capture %}}
-{{% capture body %}}
+
+
## Controller pattern
@@ -150,11 +150,12 @@ You can run your own controller as a set of Pods,
or externally to Kubernetes. What fits best will depend on what that particular
controller does.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Read about the [Kubernetes control plane](/docs/concepts/#kubernetes-control-plane)
* Discover some of the basic [Kubernetes objects](/docs/concepts/#kubernetes-objects)
* Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
* If you want to write your own controller, see [Extension Patterns](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Extending Kubernetes.
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md
index 32274f5a3b..516e4eb6d9 100644
--- a/content/en/docs/concepts/architecture/nodes.md
+++ b/content/en/docs/concepts/architecture/nodes.md
@@ -3,11 +3,11 @@ reviewers:
- caesarxuchao
- dchen1107
title: Nodes
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
Kubernetes runs your workload by placing containers into Pods to run on _Nodes_.
A node may be a virtual or physical machine, depending on the cluster. Each node
@@ -23,9 +23,9 @@ The [components](/docs/concepts/overview/components/#node-components) on a node
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}, and the
{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Management
@@ -332,12 +332,13 @@ the kubelet can use topology hints when making resource assignment decisions.
See [Control Topology Management Policies on a Node](/docs/tasks/administer-cluster/topology-manager/)
for more information.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn about the [components](/docs/concepts/overview/components/#node-components) that make up a node.
* Read the [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
* Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
section of the architecture design document.
* Read about [taints and tolerations](/docs/concepts/configuration/taint-and-toleration/).
* Read about [cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling).
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/cluster-administration/_index.md b/content/en/docs/concepts/cluster-administration/_index.md
old mode 100755
new mode 100644
index 72af40feec..7ce7126d9d
--- a/content/en/docs/concepts/cluster-administration/_index.md
+++ b/content/en/docs/concepts/cluster-administration/_index.md
@@ -1,5 +1,74 @@
---
-title: "Cluster Administration"
+title: Cluster Administration
+reviewers:
+- davidopp
+- lavalamp
weight: 100
+content_type: concept
+description: >
+ Lower-level detail relevant to creating or administering a Kubernetes cluster.
---
+
+The cluster administration overview is for anyone creating or administering a Kubernetes cluster.
+It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/).
+
+
+
+## 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*.
+
+ {{< note >}}
+ Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes.
+ {{< /note >}}
+
+Before choosing a guide, here are some considerations:
+
+ - Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
+ - Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
+ - Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.
+ - **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best.
+ - Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
+ - Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the
+ latter, choose an actively-developed distro. Some distros only use binary releases, but
+ offer a greater variety of choices.
+ - Familiarize yourself with the [components](/docs/admin/cluster-components/) needed to run a cluster.
+
+
+## Managing a cluster
+
+* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster’s master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster.
+
+* Learn how to [manage nodes](/docs/concepts/nodes/node/).
+
+* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters.
+
+## Securing a cluster
+
+* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains.
+
+* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node.
+
+* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts.
+
+* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options.
+
+* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled.
+
+* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
+
+* [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
+
+* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs.
+
+### Securing the kubelet
+ * [Master-Node communication](/docs/concepts/architecture/master-node-communication/)
+ * [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
+ * [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/)
+
+## Optional Cluster Services
+
+* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service.
+
+* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it.
diff --git a/content/en/docs/concepts/cluster-administration/addons.md b/content/en/docs/concepts/cluster-administration/addons.md
index 0347327f13..5b5110ec92 100644
--- a/content/en/docs/concepts/cluster-administration/addons.md
+++ b/content/en/docs/concepts/cluster-administration/addons.md
@@ -1,9 +1,9 @@
---
title: Installing Addons
-content_template: templates/concept
+content_type: concept
---
-{{% capture 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 %}}
+
+
## 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 %}}
+
diff --git a/content/en/docs/concepts/cluster-administration/certificates.md b/content/en/docs/concepts/cluster-administration/certificates.md
index 052e7b9aa5..8cc45252ec 100644
--- a/content/en/docs/concepts/cluster-administration/certificates.md
+++ b/content/en/docs/concepts/cluster-administration/certificates.md
@@ -1,19 +1,19 @@
---
title: Certificates
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
When using client certificate authentication, you can generate certificates
manually through `easyrsa`, `openssl` or `cfssl`.
-{{% /capture %}}
-{{% capture 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 %}}
+
diff --git a/content/en/docs/concepts/cluster-administration/cloud-providers.md b/content/en/docs/concepts/cluster-administration/cloud-providers.md
index 7d2f2a0b66..8526ac830e 100644
--- a/content/en/docs/concepts/cluster-administration/cloud-providers.md
+++ b/content/en/docs/concepts/cluster-administration/cloud-providers.md
@@ -1,16 +1,16 @@
---
title: Cloud Providers
-content_template: templates/concept
+content_type: concept
weight: 30
---
-{{% capture overview %}}
+
This page explains how to manage Kubernetes running on a specific
cloud provider.
-{{% /capture %}}
-{{% capture 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
@@ -99,7 +99,7 @@ Different settings can be applied to a load balancer service in AWS using _annot
* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: Used on the service to specify a connection draining timeout.
* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: Used on the service to specify the idle connection timeout.
* `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: Used on the service to enable or disable cross-zone load balancing.
-* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: Used to specify the security groups to be added to ELB created. This replaces all other security groups previously assigned to the ELB.
+* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: Used to specify the security groups to be added to ELB created. This replaces all other security groups previously assigned to the ELB. Security groups defined here should not be shared between services.
* `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: Used on the service to specify additional security groups to be added to ELB created
* `service.beta.kubernetes.io/aws-load-balancer-internal`: Used on the service to indicate that we want an internal ELB.
* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: Used on the service to enable the proxy protocol on an ELB. Right now we only accept the value `*` which means enabling the proxy protocol on all ELB backends. In the future we could adjust this to allow setting the proxy protocol only on certain backends.
@@ -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
@@ -433,4 +433,4 @@ Alibaba Cloud does not require the format of node name, but the kubelet needs to
### Load Balancers
-You can setup external load balancers to use specific features in Alibaba Cloud by configuring the [annotations](https://www.alibabacloud.com/help/en/doc-detail/86531.htm) .
\ No newline at end of file
+You can setup external load balancers to use specific features in Alibaba Cloud by configuring the [annotations](https://www.alibabacloud.com/help/en/doc-detail/86531.htm) .
diff --git a/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md
deleted file mode 100644
index 5ba0bb30d8..0000000000
--- a/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-reviewers:
-- davidopp
-- lavalamp
-title: Cluster Administration Overview
-content_template: templates/concept
-weight: 10
----
-
-{{% capture 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 %}}
-## 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*.
-
-Before choosing a guide, here are some considerations:
-
- - Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
- - Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
- - Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.
- - **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best.
- - Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
- - Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the
- latter, choose an actively-developed distro. Some distros only use binary releases, but
- offer a greater variety of choices.
- - Familiarize yourself with the [components](/docs/admin/cluster-components/) needed to run a cluster.
-
-Note: Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes.
-
-## Managing a cluster
-
-* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster’s master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster.
-
-* Learn how to [manage nodes](/docs/concepts/nodes/node/).
-
-* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters.
-
-## Securing a cluster
-
-* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains.
-
-* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node.
-
-* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts.
-
-* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options.
-
-* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled.
-
-* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
-
-* [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
-
-* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs.
-
-### Securing the kubelet
- * [Master-Node communication](/docs/concepts/architecture/master-node-communication/)
- * [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
- * [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/)
-
-## Optional Cluster Services
-
-* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service.
-
-* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it.
-
-{{% /capture %}}
-
-
diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md
index f9ccdca8e9..26fc1194df 100644
--- a/content/en/docs/concepts/cluster-administration/flow-control.md
+++ b/content/en/docs/concepts/cluster-administration/flow-control.md
@@ -1,10 +1,10 @@
---
title: API Priority and Fairness
-content_template: templates/concept
+content_type: concept
min-kubernetes-server-version: v1.18
---
-{{% capture 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 %}}
+
+
## Enabling API Priority and Fairness
@@ -136,7 +136,7 @@ classes:
controllers.
* The `workload-low` priority level is for requests from any other service
- account, which will typically include all requests from controllers runing in
+ account, which will typically include all requests from controllers running in
Pods.
* The `global-default` priority level handles all other traffic, e.g.
@@ -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 %}}
\ No newline at end of file
diff --git a/content/en/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/en/docs/concepts/cluster-administration/kubelet-garbage-collection.md
index eb41a01cfe..1590561cc9 100644
--- a/content/en/docs/concepts/cluster-administration/kubelet-garbage-collection.md
+++ b/content/en/docs/concepts/cluster-administration/kubelet-garbage-collection.md
@@ -1,20 +1,20 @@
---
reviewers:
title: Configuring kubelet Garbage Collection
-content_template: templates/concept
+content_type: concept
weight: 70
---
-{{% capture 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 %}}
+
+
## 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 %}}
+
diff --git a/content/en/docs/concepts/cluster-administration/logging.md b/content/en/docs/concepts/cluster-administration/logging.md
index e464a2869e..399f8f16cc 100644
--- a/content/en/docs/concepts/cluster-administration/logging.md
+++ b/content/en/docs/concepts/cluster-administration/logging.md
@@ -3,20 +3,20 @@ reviewers:
- piosz
- x13n
title: Logging Architecture
-content_template: templates/concept
+content_type: concept
weight: 60
---
-{{% capture 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 %}}
+
+
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 %}}
+
diff --git a/content/en/docs/concepts/cluster-administration/manage-deployment.md b/content/en/docs/concepts/cluster-administration/manage-deployment.md
index a6dccdbf93..b052dd3a15 100644
--- a/content/en/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/en/docs/concepts/cluster-administration/manage-deployment.md
@@ -2,18 +2,18 @@
reviewers:
- janetkuo
title: Managing Resources
-content_template: templates/concept
+content_type: concept
weight: 40
---
-{{% capture 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 %}}
+
+
## Organizing resource configurations
@@ -402,7 +402,7 @@ For more information, please see [kubectl edit](/docs/reference/generated/kubect
You can use `kubectl patch` to update API objects in place. This command supports JSON patch,
JSON merge patch, and strategic merge patch. See
-[Update API Objects in Place Using kubectl patch](/docs/tasks/run-application/update-api-object-kubectl-patch/)
+[Update API Objects in Place Using kubectl patch](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)
and
[kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch).
@@ -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 %}}
+
diff --git a/content/en/docs/concepts/cluster-administration/monitoring.md b/content/en/docs/concepts/cluster-administration/monitoring.md
index e02ac8231c..fbea5e69c1 100644
--- a/content/en/docs/concepts/cluster-administration/monitoring.md
+++ b/content/en/docs/concepts/cluster-administration/monitoring.md
@@ -4,21 +4,21 @@ reviewers:
- brancz
- logicalhan
- RainbowMango
-content_template: templates/concept
+content_type: concept
weight: 60
aliases:
- controller-metrics.md
---
-{{% capture 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 %}}
+
+
## 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 %}}
+
diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md
index c260963d87..29044be250 100644
--- a/content/en/docs/concepts/cluster-administration/networking.md
+++ b/content/en/docs/concepts/cluster-administration/networking.md
@@ -2,11 +2,11 @@
reviewers:
- thockin
title: Cluster Networking
-content_template: templates/concept
+content_type: concept
weight: 50
---
-{{% capture 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 %}}
+
+
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 %}}
+
diff --git a/content/en/docs/concepts/cluster-administration/proxies.md b/content/en/docs/concepts/cluster-administration/proxies.md
index 8e03334d12..9bf204bd9f 100644
--- a/content/en/docs/concepts/cluster-administration/proxies.md
+++ b/content/en/docs/concepts/cluster-administration/proxies.md
@@ -1,14 +1,14 @@
---
title: Proxies in Kubernetes
-content_template: templates/concept
+content_type: concept
weight: 90
---
-{{% capture overview %}}
+
This page explains proxies used with Kubernetes.
-{{% /capture %}}
-{{% capture 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 %}}
+
diff --git a/content/en/docs/concepts/configuration/_index.md b/content/en/docs/concepts/configuration/_index.md
index 1635c2a5bf..2ed10d601d 100755
--- a/content/en/docs/concepts/configuration/_index.md
+++ b/content/en/docs/concepts/configuration/_index.md
@@ -1,5 +1,7 @@
---
title: "Configuration"
weight: 80
+description: >
+ Resources that Kubernetes provides for configuring Pods.
---
diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md
index 355386f3e7..1c1a24106e 100644
--- a/content/en/docs/concepts/configuration/configmap.md
+++ b/content/en/docs/concepts/configuration/configmap.md
@@ -1,23 +1,23 @@
---
title: ConfigMaps
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
{{< glossary_definition term_id="configmap" prepend="A ConfigMap is" length="all" >}}
{{< caution >}}
-ConfigMap does not provide secrecy or encryption.
+ConfigMap does not provide secrecy or encryption.
If the data you want to store are confidential, use a
{{< glossary_tooltip text="Secret" term_id="secret" >}} rather than a ConfigMap,
or use additional (third party) tools to keep your data private.
{{< /caution >}}
-{{% /capture %}}
-{{% capture body %}}
+
+
## Motivation
Use a ConfigMap for setting configuration data separately from application code.
@@ -60,7 +60,7 @@ metadata:
name: game-demo
data:
# property-like keys; each key maps to a simple value
- player_initial_lives: 3
+ player_initial_lives: "3"
ui_properties_file_name: "user-interface.properties"
#
# file-like keys
@@ -85,9 +85,9 @@ These different methods lend themselves to different ways of modeling
the data being consumed.
For the first three methods, the
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} uses the data from
-the Secret when it launches container(s) for a Pod.
+the ConfigMap when it launches container(s) for a Pod.
-The fourth method means you have to write code to read the Secret and its data.
+The fourth method means you have to write code to read the ConfigMap and its data.
However, because you're using the Kubernetes API directly, your application can
subscribe to get updates whenever the ConfigMap changes, and react
when that happens. By accessing the Kubernetes API directly, this
@@ -131,7 +131,7 @@ spec:
A ConfigMap doesn't differentiate between single line property values and
multi-line file-like values.
-What matters how Pods and other objects consume those 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:
@@ -157,13 +157,99 @@ 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:
+
+1. Create a config map or use an existing one. Multiple Pods can reference the same config map.
+1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name the volume anything, and have a `.spec.volumes[].configMap.name` field set to reference your ConfigMap object.
+1. Add a `.spec.containers[].volumeMounts[]` to each container that needs the config map. Specify `.spec.containers[].volumeMounts[].readOnly = true` and `.spec.containers[].volumeMounts[].mountPath` to an unused directory name where you would like the config map to appear.
+1. Modify your image or command line so that the program looks for files in that directory. Each key in the config map `data` map becomes the filename under `mountPath`.
+
+This is an example of a Pod that mounts a ConfigMap in a volume:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: mypod
+spec:
+ containers:
+ - name: mypod
+ image: redis
+ volumeMounts:
+ - name: foo
+ mountPath: "/etc/foo"
+ readOnly: true
+ volumes:
+ - name: foo
+ configMap:
+ name: myconfigmap
+```
+
+Each ConfigMap you want to use needs to be referred to in `.spec.volumes`.
+
+If there are multiple containers in the Pod, then each container needs its
+own `volumeMounts` block, but only one `.spec.volumes` is needed per ConfigMap.
+
+#### Mounted ConfigMaps are updated automatically
+
+When a config map currently consumed in a volume is updated, projected keys are eventually updated as well.
+The kubelet checks whether the mounted config map is fresh on every periodic sync.
+However, the kubelet uses its local cache for getting the current value of the ConfigMap.
+The type of the cache is configurable using the `ConfigMapAndSecretChangeDetectionStrategy` field in
+the [KubeletConfiguration struct](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go).
+A ConfigMap can be either propagated by watch (default), ttl-based, or simply redirecting
+all requests directly to the API server.
+As a result, the total delay from the moment when the ConfigMap is updated to the moment
+when new keys are projected to the Pod can be as long as the kubelet sync period + cache
+propagation delay, where the cache propagation delay depends on the chosen cache type
+(it equals to watch propagation delay, ttl of cache, or zero correspondingly).
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+The Kubernetes alpha feature _Immutable Secrets and ConfigMaps_ provides an option to set
+individual Secrets and ConfigMaps as immutable. For clusters that extensively use ConfigMaps
+(at least tens of thousands of unique ConfigMap to Pod mounts), preventing changes to their
+data has the following advantages:
+
+- protects you from accidental (or unwanted) updates that could cause applications outages
+- improves performance of your cluster by significantly reducing load on kube-apiserver, by
+closing watches for config maps marked as immutable.
+
+To use this feature, enable the `ImmutableEmphemeralVolumes`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and set
+your Secret or ConfigMap `immutable` field to `true`. For example:
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ ...
+data:
+ ...
+immutable: true
+```
+
+{{< note >}}
+Once a ConfigMap or Secret is marked as immutable, it is _not_ possible to revert this change
+nor to mutate the contents of the `data` field. You can only delete and recreate the ConfigMap.
+Existing Pods maintain a mount point to the deleted ConfigMap - it is recommended to recreate
+these pods.
+{{< /note >}}
+
+
+## {{% heading "whatsnext" %}}
-{{% /capture %}}
-{{% capture whatsnext %}}
* Read about [Secrets](/docs/concepts/configuration/secret/).
* Read [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/).
* Read [The Twelve-Factor App](https://12factor.net/) to understand the motivation for
separating code from configuration.
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md
index 69ea4a255d..f8989c4a5d 100644
--- a/content/en/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/en/docs/concepts/configuration/manage-resources-containers.md
@@ -1,6 +1,6 @@
---
title: Managing Resources for Containers
-content_template: templates/concept
+content_type: concept
weight: 40
feature:
title: Automatic bin packing
@@ -8,7 +8,7 @@ feature:
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.
---
-{{% capture overview %}}
+
When you specify a {{< glossary_tooltip term_id="pod" >}}, you can optionally specify how
much of each resource a {{< glossary_tooltip text="Container" term_id="container" >}} needs.
@@ -21,10 +21,10 @@ allowed to use more of that resource than the limit you set. The kubelet also re
at least the _request_ amount of that system resource specifically for that container
to use.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Requests and limits
@@ -740,10 +740,11 @@ You can see that the Container was terminated because of `reason:OOM Killed`, wh
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Get hands-on experience [assigning Memory resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/).
@@ -758,4 +759,4 @@ You can see that the Container was terminated because of `reason:OOM Killed`, wh
* Read about [project quotas](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
index 480b708018..df767bbc3e 100644
--- a/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
+++ b/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
@@ -1,10 +1,10 @@
---
title: Organizing Cluster Access Using kubeconfig Files
-content_template: templates/concept
+content_type: concept
weight: 60
---
-{{% capture overview %}}
+
Use kubeconfig files to organize information about clusters, users, namespaces, and
authentication mechanisms. The `kubectl` command-line tool uses kubeconfig files to
@@ -25,10 +25,10 @@ variable or by setting the
For step-by-step instructions on creating and specifying kubeconfig files, see
[Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
-{{% /capture %}}
-{{% capture body %}}
+
+
## Supporting multiple clusters, users, and authentication mechanisms
@@ -143,14 +143,15 @@ File references on the command line are relative to the current working director
In `$HOME/.kube/config`, relative paths are stored relatively, and absolute paths
are stored absolutely.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/configuration/overview.md b/content/en/docs/concepts/configuration/overview.md
index b7b7b829db..744034f8ea 100644
--- a/content/en/docs/concepts/configuration/overview.md
+++ b/content/en/docs/concepts/configuration/overview.md
@@ -2,17 +2,17 @@
reviewers:
- mikedanese
title: Configuration Best Practices
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
This document highlights and consolidates configuration best practices that are introduced throughout the user guide, Getting Started documentation, and examples.
This is a living document. If you think of something that is not on this list but might be useful to others, please don't hesitate to file an issue or submit a PR.
-{{% /capture %}}
-{{% capture body %}}
+
+
## General Configuration Tips
- When defining configurations, specify the latest stable API version.
@@ -34,7 +34,7 @@ This is a living document. If you think of something that is not on this list bu
- Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or [Deployment](/docs/concepts/workloads/controllers/deployment/)) if you can avoid it. Naked Pods will not be rescheduled in the event of a node failure.
- A Deployment, which both creates a ReplicaSet to ensure that the desired number of Pods is always available, and specifies a strategy to replace Pods (such as [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), is almost always preferable to creating Pods directly, except for some explicit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) scenarios. A [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) may also be appropriate.
+ A Deployment, which both creates a ReplicaSet to ensure that the desired number of Pods is always available, and specifies a strategy to replace Pods (such as [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), is almost always preferable to creating Pods directly, except for some explicit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) scenarios. A [Job](/docs/concepts/workloads/controllers/job/) may also be appropriate.
## Services
@@ -103,7 +103,7 @@ The caching semantics of the underlying image provider make even `imagePullPolic
- Use label selectors for `get` and `delete` operations instead of specific object names. See the sections on [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) and [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
-- Use `kubectl run` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example.
+- Use `kubectl create deployment` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example.
+
-{{% /capture %}}
diff --git a/content/en/docs/concepts/configuration/pod-overhead.md b/content/en/docs/concepts/configuration/pod-overhead.md
index 9661264820..7057383dac 100644
--- a/content/en/docs/concepts/configuration/pod-overhead.md
+++ b/content/en/docs/concepts/configuration/pod-overhead.md
@@ -4,11 +4,11 @@ reviewers:
- egernst
- tallclair
title: Pod Overhead
-content_template: templates/concept
+content_type: concept
weight: 50
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
@@ -19,10 +19,10 @@ _Pod Overhead_ is a feature for accounting for the resources consumed by the Pod
on top of the container requests & limits.
-{{% /capture %}}
-{{% capture body %}}
+
+
In Kubernetes, the Pod's overhead is set at
[admission](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)
@@ -188,11 +188,12 @@ running with a defined Overhead. This functionality is not available in the 1.9
kube-state-metrics, but is expected in a following release. Users will need to build kube-state-metrics
from source in the meantime.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [RuntimeClass](/docs/concepts/containers/runtime-class/)
* [PodOverhead Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/configuration/pod-priority-preemption.md b/content/en/docs/concepts/configuration/pod-priority-preemption.md
index c9bddd7e3e..9bfc514257 100644
--- a/content/en/docs/concepts/configuration/pod-priority-preemption.md
+++ b/content/en/docs/concepts/configuration/pod-priority-preemption.md
@@ -3,11 +3,11 @@ reviewers:
- davidopp
- wojtek-t
title: Pod Priority and Preemption
-content_template: templates/concept
+content_type: concept
weight: 70
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
@@ -16,9 +16,9 @@ importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the
scheduler tries to preempt (evict) lower priority Pods to make scheduling of the
pending Pod possible.
-{{% /capture %}}
-{{% capture body %}}
+
+
{{< warning >}}
@@ -407,7 +407,8 @@ usage does not exceed their requests. If a Pod with lower priority is not
exceeding its requests, it won't be evicted. Another Pod with higher priority
that exceeds its requests may be evicted.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Read about using ResourceQuotas in connection with PriorityClasses: [limit Priority Class consumption by default](/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/configuration/resource-bin-packing.md b/content/en/docs/concepts/configuration/resource-bin-packing.md
index 0d475791ce..08a99de201 100644
--- a/content/en/docs/concepts/configuration/resource-bin-packing.md
+++ b/content/en/docs/concepts/configuration/resource-bin-packing.md
@@ -4,19 +4,19 @@ reviewers:
- k82cn
- ahg-g
title: Resource Bin Packing for Extended Resources
-content_template: templates/concept
+content_type: concept
weight: 50
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
The kube-scheduler can be configured to enable bin packing of resources along with extended resources using `RequestedToCapacityRatioResourceAllocation` priority function. Priority functions can be used to fine-tune the kube-scheduler as per custom needs.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation
@@ -132,23 +132,23 @@ CPU: 1
Node Score:
intel.com/foo = resourceScoringFunction((2+1),4)
- = (100 - ((4-3)*100/4)
- = (100 - 25)
- = 75
- = rawScoringFunction(75)
- = 7
+ = (100 - ((4-3)*100/4)
+ = (100 - 25)
+ = 75 # requested + used = 75% * available
+ = rawScoringFunction(75)
+ = 7 # floor(75/10)
Memory = resourceScoringFunction((256+256),1024)
= (100 -((1024-512)*100/1024))
- = 50
+ = 50 # requested + used = 50% * available
= rawScoringFunction(50)
- = 5
+ = 5 # floor(50/10)
CPU = resourceScoringFunction((2+1),8)
= (100 -((8-3)*100/8))
- = 37.5
+ = 37.5 # requested + used = 37.5% * available
= rawScoringFunction(37.5)
- = 3
+ = 3 # floor(37.5/10)
NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3)
= 5
@@ -194,4 +194,4 @@ NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)
```
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md
index c7b123cacc..5c553b5cc6 100644
--- a/content/en/docs/concepts/configuration/secret.md
+++ b/content/en/docs/concepts/configuration/secret.md
@@ -2,7 +2,7 @@
reviewers:
- mikedanese
title: Secrets
-content_template: templates/concept
+content_type: concept
feature:
title: Secret and configuration management
description: >
@@ -10,16 +10,16 @@ feature:
weight: 30
---
-{{% capture overview %}}
+
Kubernetes Secrets let you store and manage sensitive information, such
as passwords, OAuth tokens, and ssh keys. Storing confidential information in a Secret
is safer and more flexible than putting it verbatim in a
{{< glossary_tooltip term_id="pod" >}} definition or in a {{< glossary_tooltip text="container image" term_id="image" >}}. See [Secrets design document](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) for more information.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Overview of Secrets
@@ -29,12 +29,13 @@ Pod specification or in an image. Users can create secrets and the system
also creates some secrets.
To use a secret, a Pod needs to reference the secret.
-A secret can be used with a Pod in two ways:
+A secret can be used with a Pod in three ways:
-- As files in a
+- As [files](#using-secrets-as-files-from-a-pod) in a
{{< glossary_tooltip text="volume" term_id="volume" >}} mounted on one or more of
its containers.
-- By the kubelet when pulling images for the Pod.
+- As [container environment variable](#using-secrets-as-environment-variables).
+- By the [kubelet when pulling images](#using-imagepullsecrets) for the Pod.
### Built-in Secrets
@@ -725,7 +726,7 @@ data has the following advantages:
- improves performance of your cluster by significantly reducing load on kube-apiserver, by
closing watches for secrets marked as immutable.
-To use this feature, enable the `ImmutableEmphemeralVolumes`
+To use this feature, enable the `ImmutableEphemeralVolumes`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and set
your Secret or ConfigMap `immutable` field to `true`. For example:
```yaml
diff --git a/content/en/docs/concepts/containers/_index.md b/content/en/docs/concepts/containers/_index.md
old mode 100755
new mode 100644
index ad442f3ab3..091cea881b
--- a/content/en/docs/concepts/containers/_index.md
+++ b/content/en/docs/concepts/containers/_index.md
@@ -1,5 +1,44 @@
---
-title: "Containers"
+title: Containers
weight: 40
+description: Technology for packaging an application along with its runtime dependencies.
+reviewers:
+- erictune
+- thockin
+content_type: concept
---
+
+
+Each container that you run is repeatable; the standardization from having
+dependencies included means that you get the same behavior wherever you
+run it.
+
+Containers decouple applications from underlying host infrastructure.
+This makes deployment easier in different cloud or OS environments.
+
+
+
+
+
+
+## Container images
+A [container image](/docs/concepts/containers/images/) is a ready-to-run
+software package, containing everything needed to run an application:
+the code and any runtime it requires, application and system libraries,
+and default values for any essential settings.
+
+By design, a container is immutable: you cannot change the code of a
+container that is already running. If you have a containerized application
+and want to make changes, you need to build a new container that includes
+the change, then recreate the container to start from the updated image.
+
+## Container runtimes
+
+{{< glossary_definition term_id="container-runtime" length="all" >}}
+
+## {{% heading "whatsnext" %}}
+
+* Read about [container images](/docs/concepts/containers/images/)
+* Read about [Pods](/docs/concepts/workloads/pods/)
+
diff --git a/content/en/docs/concepts/containers/container-environment.md b/content/en/docs/concepts/containers/container-environment.md
index 86b595661d..a57ac2181a 100644
--- a/content/en/docs/concepts/containers/container-environment.md
+++ b/content/en/docs/concepts/containers/container-environment.md
@@ -3,18 +3,18 @@ reviewers:
- mikedanese
- thockin
title: Container Environment
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
This page describes the resources available to Containers in the Container environment.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Container environment
@@ -53,12 +53,13 @@ FOO_SERVICE_PORT=
Services have dedicated IP addresses and are available to the Container via DNS,
if [DNS addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/) is enabled.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
* Get hands-on experience
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/containers/container-lifecycle-hooks.md b/content/en/docs/concepts/containers/container-lifecycle-hooks.md
index fe810d23c5..386e4d00bb 100644
--- a/content/en/docs/concepts/containers/container-lifecycle-hooks.md
+++ b/content/en/docs/concepts/containers/container-lifecycle-hooks.md
@@ -3,19 +3,19 @@ reviewers:
- mikedanese
- thockin
title: Container Lifecycle Hooks
-content_template: templates/concept
+content_type: concept
weight: 30
---
-{{% capture overview %}}
+
This page describes how kubelet managed Containers can use the Container lifecycle hook framework
to run code triggered by events during their management lifecycle.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Overview
@@ -112,12 +112,13 @@ Events:
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about the [Container environment](/docs/concepts/containers/container-environment/).
* Get hands-on experience
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md
index 3d27355e3a..496387a43a 100644
--- a/content/en/docs/concepts/containers/images.md
+++ b/content/en/docs/concepts/containers/images.md
@@ -3,24 +3,56 @@ reviewers:
- erictune
- thockin
title: Images
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
-You create your Docker image and push it to a registry before referring to it in a Kubernetes pod.
+A container image represents binary data that encapsulates an application and all its
+software dependencies. Container images are executable software bundles that can run
+standalone and that make very well defined assumptions about their runtime environment.
-The `image` property of a container supports the same syntax as the `docker` command does, including private registries and tags.
+You typically create a container image of your application and push it to a registry
+before referring to it in a
+{{< glossary_tooltip text="Pod" term_id="pod" >}}
-{{% /capture %}}
+This page provides an outline of the container image concept.
-{{% capture body %}}
+
+
+
+## Image names
+
+Container images are usually given a name such as `pause`, `example/mycontainer`, or `kube-apiserver`.
+Images can also include a registry hostname; for example: `fictional.registry.example/imagename`,
+and possible a port number as well; for example: `fictional.registry.example:10443/imagename`.
+
+If you don't specify a registry hostname, Kubernetes assumes that you mean the Docker public registry.
+
+After the image name part you can add a _tag_ (as also using with commands such
+as `docker` and `podman`).
+Tags let you identify different versions of the same series of images.
+
+Image tags consist of lowercase and uppercase letters, digits, underscores (`_`),
+periods (`.`), and dashes (`-`).
+There are additional rules about where you can place the separator
+characters (`_`, `-`, and `.`) inside an image tag.
+If you don't specify a tag, Kubernetes assumes you mean the tag `latest`.
+
+{{< caution >}}
+You should avoid using the `latest` tag when deploying containers in production,
+as it is harder to track which version of the image is running and more difficult
+to roll back to a working version.
+
+Instead, specify a meaningful tag such as `v1.42.0`.
+{{< /caution >}}
## Updating Images
-The default pull policy is `IfNotPresent` which causes the Kubelet to skip
+The default pull policy is `IfNotPresent` which causes the
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip
pulling an image if it already exists. If you would like to always force a pull,
you can do one of the following:
@@ -29,45 +61,18 @@ you can do one of the following:
- omit the `imagePullPolicy` and the tag for the image to use.
- enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller.
-Note that you should avoid using `:latest` tag, see [Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images) for more information.
+When `imagePullPolicy` is defined without a specific value, it is also set to `Always`.
-## Building Multi-architecture Images with Manifests
+## Multi-architecture Images with Manifests
-Docker CLI now supports the following command `docker manifest` with sub commands like `create`, `annotate` and `push`. These commands can be used to build and push the manifests. You can use `docker manifest inspect` to view the manifest.
+As well as providing binary images, a container registry can also server a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.
-Please see docker documentation here:
-https://docs.docker.com/edge/engine/reference/commandline/manifest/
-
-See examples on how we use this in our build harness:
-https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos=
-
-These commands rely on and are implemented purely on the Docker CLI. You will need to either edit the `$HOME/.docker/config.json` and set `experimental` key to `enabled` or you can just set `DOCKER_CLI_EXPERIMENTAL` environment variable to `enabled` when you call the CLI commands.
-
-{{< note >}}
-Please use Docker *18.06 or above*, versions below that either have bugs or do not support the experimental command line option. Example https://github.com/docker/cli/issues/1135 causes problems under containerd.
-{{< /note >}}
-
-If you run into trouble with uploading stale manifests, just clean up the older manifests in `$HOME/.docker/manifests` to start fresh.
-
-For Kubernetes, we have typically used images with suffix `-$(ARCH)`. For backward compatibility, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes.
+Kubernetes itself typically names container images with a suffix `-$(ARCH)`. For backward compatibility, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes.
## Using a Private Registry
-Private registries may require keys to read images from them.
+Private registries may require keys to read images from them.
Credentials can be provided in several ways:
-
- - Using Google Container Registry
- - Per-cluster
- - automatically configured on Google Compute Engine or Google Kubernetes Engine
- - all pods can read the project's private registry
- - Using Amazon Elastic Container Registry (ECR)
- - use IAM roles and policies to control access to ECR repositories
- - automatically refreshes ECR login credentials
- - Using Oracle Cloud Infrastructure Registry (OCIR)
- - use IAM roles and policies to control access to OCIR repositories
- - Using Azure Container Registry (ACR)
- - Using IBM Cloud Container Registry
- - use IAM roles and policies to grant access to IBM Cloud Container Registry
- Configuring Nodes to Authenticate to a Private Registry
- all pods can read any configured private registries
- requires node configuration by cluster administrator
@@ -76,135 +81,59 @@ Credentials can be provided in several ways:
- requires root access to all nodes to setup
- Specifying ImagePullSecrets on a Pod
- only pods which provide own keys can access the private registry
+ - Vendor-specific or local extensions
+ - if you're using a custom node configuration, you (or your cloud
+ provider) can implement your mechanism for authenticating the node
+ to the container registry.
-Each option is described in more detail below.
+These options are explaind in more detail below.
+### Configuring Nodes to authenticate to a Private Registry
-### Using Google Container Registry
+If you run Docker on your nodes, you can configure the Docker container
+runtime to authenticate to a private container registry.
-Kubernetes has native support for the [Google Container
-Registry (GCR)](https://cloud.google.com/tools/container-registry/), when running on Google Compute
-Engine (GCE). If you are running your cluster on GCE or Google Kubernetes Engine, simply
-use the full image name (e.g. gcr.io/my_project/image:tag).
-
-All pods in a cluster will have read access to images in this registry.
-
-The kubelet will authenticate to GCR using the instance's
-Google service account. The service account on the instance
-will have a `https://www.googleapis.com/auth/devstorage.read_only`,
-so it can pull from the project's GCR, but not push.
-
-### Using Amazon Elastic Container Registry
-
-Kubernetes has native support for the [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/), when nodes are AWS EC2 instances.
-
-Simply use the full image name (e.g. `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`)
-in the Pod definition.
-
-All users of the cluster who can create pods will be able to run pods that use any of the
-images in the ECR registry.
-
-The kubelet will fetch and periodically refresh ECR credentials. It needs the following permissions to do this:
-
-- `ecr:GetAuthorizationToken`
-- `ecr:BatchCheckLayerAvailability`
-- `ecr:GetDownloadUrlForLayer`
-- `ecr:GetRepositoryPolicy`
-- `ecr:DescribeRepositories`
-- `ecr:ListImages`
-- `ecr:BatchGetImage`
-
-Requirements:
-
-- You must be using kubelet version `v1.2.0` or newer. (e.g. run `/usr/bin/kubelet --version=true`).
-- If your nodes are in region A and your registry is in a different region B, you need version `v1.3.0` or newer.
-- ECR must be offered in your region
-
-Troubleshooting:
-
-- Verify all requirements above.
-- Get $REGION (e.g. `us-west-2`) credentials on your workstation. SSH into the host and run Docker manually with those creds. Does it work?
-- Verify kubelet is running with `--cloud-provider=aws`.
-- Increase kubelet log level verbosity to at least 3 and check kubelet logs (e.g. `journalctl -u kubelet`) for log lines like:
- - `aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API`
- - `aws_credentials.go:116] Got ECR credentials from ECR API for .dkr.ecr..amazonaws.com`
-
-### Using Azure Container Registry (ACR)
-When using [Azure Container Registry](https://azure.microsoft.com/en-us/services/container-registry/)
-you can authenticate using either an admin user or a service principal.
-In either case, authentication is done via standard Docker authentication. These instructions assume the
-[azure-cli](https://github.com/azure/azure-cli) command line tool.
-
-You first need to create a registry and generate credentials, complete documentation for this can be found in
-the [Azure container registry documentation](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli).
-
-Once you have created your container registry, you will use the following credentials to login:
-
- * `DOCKER_USER` : service principal, or admin username
- * `DOCKER_PASSWORD`: service principal password, or admin user password
- * `DOCKER_REGISTRY_SERVER`: `${some-registry-name}.azurecr.io`
- * `DOCKER_EMAIL`: `${some-email-address}`
-
-Once you have those variables filled in you can
-[configure a Kubernetes Secret and use it to deploy a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
-
-### Using IBM Cloud Container Registry
-IBM Cloud Container Registry provides a multi-tenant private image registry that you can use to safely store and share your images. By default, images in your private registry are scanned by the integrated Vulnerability Advisor to detect security issues and potential vulnerabilities. Users in your IBM Cloud account can access your images, or you can use IAM roles and policies to grant access to IBM Cloud Container Registry namespaces.
-
-To install the IBM Cloud Container Registry CLI plug-in and create a namespace for your images, see [Getting started with IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started).
-
-If you are using the same account and region, you can deploy images that are stored in IBM Cloud Container Registry into the default namespace of your IBM Cloud Kubernetes Service cluster without any additional configuration, see [Building containers from images](https://cloud.ibm.com/docs/containers?topic=containers-images). For other configuration options, see [Understanding how to authorize your cluster to pull images from a registry](https://cloud.ibm.com/docs/containers?topic=containers-registry#cluster_registry_auth).
-
-### Configuring Nodes to Authenticate to a Private Registry
+This approach is suitable if you can control node configuration.
{{< note >}}
-If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
-{{< /note >}}
-
-{{< note >}}
-If you are running on AWS EC2 and are using the EC2 Container Registry (ECR), the kubelet on each node will
-manage and update the ECR login credentials. You cannot use this approach.
-{{< /note >}}
-
-{{< note >}}
-This approach is suitable if you can control node configuration. It
-will not work reliably on GCE, and any other cloud provider that does automatic
-node replacement.
-{{< /note >}}
-
-{{< note >}}
-Kubernetes as of now only supports the `auths` and `HttpHeaders` section of docker config. This means credential helpers (`credHelpers` or `credsStore`) are not supported.
+Kubernetes as only supports the `auths` and `HttpHeaders` section in Docker configuration.
+Docker credential helpers (`credHelpers` or `credsStore`) are not supported.
{{< /note >}}
Docker stores keys for private registries in the `$HOME/.dockercfg` or `$HOME/.docker/config.json` file. If you put the same file
in the search paths list below, kubelet uses it as the credential provider when pulling images.
-* `{--root-dir:-/var/lib/kubelet}/config.json`
-* `{cwd of kubelet}/config.json`
-* `${HOME}/.docker/config.json`
-* `/.docker/config.json`
-* `{--root-dir:-/var/lib/kubelet}/.dockercfg`
-* `{cwd of kubelet}/.dockercfg`
-* `${HOME}/.dockercfg`
-* `/.dockercfg`
+* `{--root-dir:-/var/lib/kubelet}/config.json`
+* `{cwd of kubelet}/config.json`
+* `${HOME}/.docker/config.json`
+* `/.docker/config.json`
+* `{--root-dir:-/var/lib/kubelet}/.dockercfg`
+* `{cwd of kubelet}/.dockercfg`
+* `${HOME}/.dockercfg`
+* `/.dockercfg`
{{< note >}}
-You may have to set `HOME=/root` explicitly in your environment file for kubelet.
+You may have to set `HOME=/root` explicitly in the environment of the kubelet process.
{{< /note >}}
Here are the recommended steps to configuring your nodes to use a private registry. In this
example, run these on your desktop/laptop:
- 1. Run `docker login [server]` for each set of credentials you want to use. This updates `$HOME/.docker/config.json`.
+ 1. Run `docker login [server]` for each set of credentials you want to use. This updates `$HOME/.docker/config.json` on your PC.
1. View `$HOME/.docker/config.json` in an editor to ensure it contains just the credentials you want to use.
- 1. Get a list of your nodes, for example:
- - if you want the names: `nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')`
- - if you want to get the IPs: `nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')`
+ 1. Get a list of your nodes; for example:
+ - if you want the names: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )`
+ - if you want to get the IP addresses: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )`
1. Copy your local `.docker/config.json` to one of the search paths list above.
- - for example: `for n in $nodes; do scp ~/.docker/config.json root@$n:/var/lib/kubelet/config.json; done`
+ - for example, to test this out: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done`
-Verify by creating a pod that uses a private image, e.g.:
+{{< note >}}
+For production clusers, use a configuration management tool so that you can apply this
+setting to all the nodes where you need it.
+{{< /note >}}
+
+Verify by creating a Pod that uses a private image; for example:
```shell
kubectl apply -f - <}}
-If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
-{{< /note >}}
-
{{< note >}}
This approach is suitable if you can control node configuration. It
-will not work reliably on GCE, and any other cloud provider that does automatic
-node replacement.
+will not work reliably if your cloud provider manages nodes and replaces
+them automatically.
{{< /note >}}
-By default, the kubelet will try to pull each image from the specified registry.
+By default, the kubelet tries to pull each image from the specified registry.
However, if the `imagePullPolicy` property of the container is set to `IfNotPresent` or `Never`,
then a local image is used (preferentially or exclusively, respectively).
@@ -277,11 +202,11 @@ All pods will have read access to any pre-pulled images.
### Specifying ImagePullSecrets on a Pod
{{< note >}}
-This approach is currently the recommended approach for Google Kubernetes Engine, GCE, and any cloud-providers
-where node creation is automated.
+This is the recommended approach to run containers based on images
+in private registries.
{{< /note >}}
-Kubernetes supports specifying registry keys on a pod.
+Kubernetes supports specifying container image registry keys on a Pod.
#### Creating a Secret with a Docker Config
@@ -292,11 +217,13 @@ kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SER
```
If you already have a Docker credentials file then, rather than using the above
-command, you can import the credentials file as a Kubernetes secret.
+command, you can import the credentials file as a Kubernetes
+{{< glossary_tooltip text="Secrets" term_id="secret" >}}.
[Create a Secret based on existing Docker credentials](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) explains how to set this up.
+
This is particularly useful if you are using multiple private container
-registries, as `kubectl create secret docker-registry` creates a Secret that will
-only work with a single private registry.
+registries, as `kubectl create secret docker-registry` creates a Secret that
+only works with a single private registry.
{{< note >}}
Pods can only reference image pull secrets in their own namespace,
@@ -306,7 +233,9 @@ so this process needs to be done one time per namespace.
#### Referring to an imagePullSecrets on a Pod
Now, you can create pods which reference that secret by adding an `imagePullSecrets`
-section to a pod definition.
+section to a Pod definition.
+
+For example:
```shell
cat < pod.yaml
@@ -332,13 +261,14 @@ EOF
This needs to be done for each pod that is using a private registry.
However, setting of this field can be automated by setting the imagePullSecrets
-in a [serviceAccount](/docs/user-guide/service-accounts) resource.
+in a [ServiceAccount](/docs/user-guide/service-accounts) resource.
+
Check [Add ImagePullSecrets to a Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) for detailed instructions.
You can use this in conjunction with a per-node `.docker/config.json`. The credentials
-will be merged. This approach will work on Google Kubernetes Engine.
+will be merged.
-### Use Cases
+## Use Cases
There are a number of solutions for configuring private registries. Here are some
common use cases and suggested solutions.
@@ -346,7 +276,7 @@ common use cases and suggested solutions.
1. Cluster running only non-proprietary (e.g. open-source) images. No need to hide images.
- Use public images on the Docker hub.
- No configuration required.
- - On GCE/Google Kubernetes Engine, a local mirror is automatically used for improved speed and availability.
+ - Some cloud providers automatically cache or mirror public images, which improves availability and reduces the time to pull images.
1. Cluster running some proprietary images which should be hidden to those outside the company, but
visible to all cluster users.
- Use a hosted private [Docker registry](https://docs.docker.com/registry/).
@@ -354,7 +284,7 @@ common use cases and suggested solutions.
- Manually configure .docker/config.json on each node as described above.
- Or, run an internal private registry behind your firewall with open read access.
- No Kubernetes configuration is required.
- - Or, when on GCE/Google Kubernetes Engine, use the project's Google Container Registry.
+ - Use a hosted container image registry service that controls image access
- It will work better with cluster autoscaling than manual node configuration.
- Or, on a cluster where changing the node configuration is inconvenient, use `imagePullSecrets`.
1. Cluster with proprietary images, a few of which require stricter access control.
@@ -370,4 +300,6 @@ common use cases and suggested solutions.
If you need access to multiple registries, you can create one secret for each registry.
Kubelet will merge any `imagePullSecrets` into a single virtual `.docker/config.json`
-{{% /capture %}}
+## {{% heading "whatsnext" %}}
+
+* Read the [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md)
diff --git a/content/en/docs/concepts/containers/overview.md b/content/en/docs/concepts/containers/overview.md
deleted file mode 100644
index 49162710d7..0000000000
--- a/content/en/docs/concepts/containers/overview.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-reviewers:
-- erictune
-- thockin
-title: Containers overview
-content_template: templates/concept
-weight: 1
----
-
-{{% capture overview %}}
-
-Containers are a technology for packaging the (compiled) code for an
-application along with the dependencies it needs at run time. Each
-container that you run is repeatable; the standardization from having
-dependencies included means that you get the same behavior wherever you
-run it.
-
-Containers decouple applications from underlying host infrastructure.
-This makes deployment easier in different cloud or OS environments.
-
-{{% /capture %}}
-
-
-{{% capture body %}}
-
-## Container images
-A [container image](/docs/concepts/containers/images/) is a ready-to-run
-software package, containing everything needed to run an application:
-the code and any runtime it requires, application and system libraries,
-and default values for any essential settings.
-
-By design, a container is immutable: you cannot change the code of a
-container that is already running. If you have a containerized application
-and want to make changes, you need to build a new container that includes
-the change, then recreate the container to start from the updated image.
-
-## Container runtimes
-
-{{< glossary_definition term_id="container-runtime" length="all" >}}
-
-{{% /capture %}}
-{{% capture whatsnext %}}
-* Read about [container images](/docs/concepts/containers/images/)
-* Read about [Pods](/docs/concepts/workloads/pods/)
-{{% /capture %}}
diff --git a/content/en/docs/concepts/containers/runtime-class.md b/content/en/docs/concepts/containers/runtime-class.md
index dca6f2d0a8..d1857f3807 100644
--- a/content/en/docs/concepts/containers/runtime-class.md
+++ b/content/en/docs/concepts/containers/runtime-class.md
@@ -3,11 +3,11 @@ reviewers:
- tallclair
- dchen1107
title: Runtime Class
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.14" state="beta" >}}
@@ -16,10 +16,10 @@ This page describes the RuntimeClass resource and runtime selection mechanism.
RuntimeClass is a feature for selecting the container runtime configuration. The container runtime
configuration is used to run a Pod's containers.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Motivation
@@ -180,12 +180,13 @@ Pod overhead is defined in RuntimeClass through the `overhead` fields. Through t
you can specify the overhead of running pods utilizing this RuntimeClass and ensure these overheads
are accounted for in Kubernetes.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
- [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
- [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
- Read about the [Pod Overhead](/docs/concepts/configuration/pod-overhead/) concept
- [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/example-concept-template.md b/content/en/docs/concepts/example-concept-template.md
index 26ce263ef4..adf3741f90 100644
--- a/content/en/docs/concepts/example-concept-template.md
+++ b/content/en/docs/concepts/example-concept-template.md
@@ -2,11 +2,11 @@
title: Example Concept Template
reviewers:
- chenopis
-content_template: templates/concept
+content_type: concept
toc_hide: true
---
-{{% capture overview %}}
+
{{< note >}}
Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
@@ -14,9 +14,9 @@ Be sure to also [create an entry in the table of contents](/docs/home/contribute
This page explains ...
-{{% /capture %}}
-{{% capture body %}}
+
+
## Understanding ...
@@ -26,15 +26,16 @@ Kubernetes provides ...
To use ...
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
**[Optional Section]**
-* Learn more about [Writing a New Topic](/docs/home/contribute/write-new-topic/).
-* See [Using Page Templates - Concept template](/docs/home/contribute/page-templates/#concept_template) for how to use this template.
-
-{{% /capture %}}
+* Learn more about [Writing a New Topic](/docs/home/contribute/style/write-new-topic/).
+* See [Page Content Types - Concept](/docs/home/contribute/style/page-concept-types/#concept).
+
+
diff --git a/content/en/docs/concepts/extend-kubernetes/_index.md b/content/en/docs/concepts/extend-kubernetes/_index.md
index 93d955441d..934861904f 100644
--- a/content/en/docs/concepts/extend-kubernetes/_index.md
+++ b/content/en/docs/concepts/extend-kubernetes/_index.md
@@ -1,4 +1,212 @@
---
title: Extending Kubernetes
weight: 110
+description: Different ways to change the behavior of your Kubernetes cluster.
+reviewers:
+- erictune
+- lavalamp
+- cheftako
+- chenopis
+content_type: concept
---
+
+
+
+Kubernetes is highly configurable and extensible. As a result,
+there is rarely a need to fork or submit patches to the Kubernetes
+project code.
+
+This guide describes the options for customizing a Kubernetes
+cluster. It is aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} who want to
+understand how to adapt their Kubernetes cluster to the needs of
+their work environment. Developers who are prospective {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} will also find it
+useful as an introduction to what extension points and patterns
+exist, and their trade-offs and limitations.
+
+
+
+
+
+
+## Overview
+
+Customization approaches can be broadly divided into *configuration*, which only involves changing flags, local configuration files, or API resources; and *extensions*, which involve running additional programs or services. This document is primarily about extensions.
+
+## Configuration
+
+*Configuration files* and *flags* are documented in the Reference section of the online documentation, under each binary:
+
+* [kubelet](/docs/admin/kubelet/)
+* [kube-apiserver](/docs/admin/kube-apiserver/)
+* [kube-controller-manager](/docs/admin/kube-controller-manager/)
+* [kube-scheduler](/docs/admin/kube-scheduler/).
+
+Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options.
+
+*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable.
+
+## Extensions
+
+Extensions are software components that extend and deeply integrate with Kubernetes.
+They adapt it to support new types and new kinds of hardware.
+
+Most cluster administrators will use a hosted or distribution
+instance of Kubernetes. As a result, most Kubernetes users will not need to
+install extensions and fewer will need to author new ones.
+
+## Extension Patterns
+
+Kubernetes is designed to be automated by writing client programs. Any
+program that reads and/or writes to the Kubernetes API can provide useful
+automation. *Automation* can run on the cluster or off it. By following
+the guidance in this doc you can write highly available and robust automation.
+Automation generally works with any Kubernetes cluster, including hosted
+clusters and managed installations.
+
+There is a specific pattern for writing client programs that work well with
+Kubernetes called the *Controller* pattern. Controllers typically read an
+object's `.spec`, possibly do things, and then update the object's `.status`.
+
+A controller is a client of Kubernetes. When Kubernetes is the client and
+calls out to a remote service, it is called a *Webhook*. The remote service
+is called a *Webhook Backend*. Like Controllers, Webhooks do add a point of
+failure.
+
+In the webhook model, Kubernetes makes a network request to a remote service.
+In the *Binary Plugin* model, Kubernetes executes a binary (program).
+Binary plugins are used by the kubelet (e.g. [Flex Volume
+Plugins](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)
+and [Network
+Plugins](/docs/concepts/cluster-administration/network-plugins/))
+and by kubectl.
+
+Below is a diagram showing how the extension points interact with the
+Kubernetes control plane.
+
+
+
+
+
+
+## Extension Points
+
+This diagram shows the extension points in a Kubernetes system.
+
+
+
+
+
+1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies.
+2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/overview/extending#api-access-extensions) section.
+3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/overview/extending#user-defined-types) section. Custom Resources are often used with API Access Extensions.
+4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/overview/extending#scheduler-extensions) section.
+5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources.
+6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](/docs/concepts/overview/extending#network-plugins) allow for different implementations of pod networking.
+7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](/docs/concepts/overview/extending#storage-plugins).
+
+If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions.
+
+
+
+
+
+
+## API Extensions
+### User-Defined Types
+
+Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such as `kubectl`.
+
+Do not use a Custom Resource as data storage for application, user, or monitoring data.
+
+For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/api-extension/custom-resources/).
+
+
+### Combining New APIs with Automation
+
+The combination of a custom resource API and a control loop is called the [Operator pattern](/docs/concepts/extend-kubernetes/operator/). The Operator pattern is used to manage specific, usually stateful, applications. These custom APIs and control loops can also be used to control other resources, such as storage or policies.
+
+### Changing Built-in Resources
+
+When you extend the Kubernetes API by adding custom resources, the added resources always fall into a new API Groups. You cannot replace or change existing API groups.
+Adding an API does not directly let you affect the behavior of existing APIs (e.g. Pods), but API Access Extensions do.
+
+
+### API Access Extensions
+
+When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) for more on this flow.
+
+Each of these steps offers extension points.
+
+Kubernetes has several built-in authentication methods that it supports. It can also sit behind an authenticating proxy, and it can send a token from an Authorization header to a remote service for verification (a webhook). All of these methods are covered in the [Authentication documentation](/docs/reference/access-authn-authz/authentication/).
+
+### Authentication
+
+[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates in all requests to a username for the client making the request.
+
+Kubernetes provides several built-in authentication methods, and an [Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) method if those don't meet your needs.
+
+
+### Authorization
+
+[Authorization](/docs/reference/access-authn-authz/webhook/) determines whether specific users can read, write, and do other operations on API resources. It just works at the level of whole resources -- it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, and [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision.
+
+
+### Dynamic Admission Control
+
+After a request is authorized, if it is a write operation, it also goes through [Admission Control](/docs/reference/access-authn-authz/admission-controllers/) steps. In addition to the built-in steps, there are several extensions:
+
+* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) restricts what images can be run in containers.
+* To make arbitrary admission control decisions, a general [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) can be used. Admission Webhooks can reject creations or updates.
+
+## Infrastructure Extensions
+
+
+### Storage Plugins
+
+[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md
+) allow users to mount volume types without built-in support by having the
+Kubelet call a Binary Plugin to mount the volume.
+
+
+### Device Plugins
+
+Device plugins allow a node to discover new Node resources (in addition to the
+builtin ones like cpu and memory) via a [Device
+Plugin](/docs/concepts/cluster-administration/device-plugins/).
+
+
+### Network Plugins
+
+Different networking fabrics can be supported via node-level [Network Plugins](/docs/admin/network-plugins/).
+
+### Scheduler Extensions
+
+The scheduler is a special type of controller that watches pods, and assigns
+pods to nodes. The default scheduler can be replaced entirely, while
+continuing to use other Kubernetes components, or [multiple
+schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
+can run at the same time.
+
+This is a significant undertaking, and almost all Kubernetes users find they
+do not need to modify the scheduler.
+
+The scheduler also supports a
+[webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)
+that permits a webhook backend (scheduler extension) to filter and prioritize
+the nodes chosen for a pod.
+
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* Learn more about [Custom Resources](/docs/concepts/api-extension/custom-resources/)
+* Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)
+* Learn more about Infrastructure extensions
+ * [Network Plugins](/docs/concepts/cluster-administration/network-plugins/)
+ * [Device Plugins](/docs/concepts/cluster-administration/device-plugins/)
+* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
+* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
+
+
diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
index 8bc6e22861..1f47323301 100644
--- a/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
+++ b/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
@@ -4,20 +4,20 @@ reviewers:
- lavalamp
- cheftako
- chenopis
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
The aggregation layer allows Kubernetes to be extended with additional APIs, beyond what is offered by the core Kubernetes APIs.
The additional APIs can either be ready-made solutions such as [service-catalog](/docs/concepts/extend-kubernetes/service-catalog/), or APIs that you develop yourself.
The aggregation layer is different from [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/), which are a way to make the {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} recognise new kinds of object.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Aggregation layer
@@ -34,13 +34,14 @@ If your extension API server cannot achieve that latency requirement, consider m
`EnableAggregatedDiscoveryTimeout=false` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the kube-apiserver
to disable the timeout restriction. This deprecated feature gate will be removed in a future release.
-{{% /capture %}}
-{{% capture 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/).
+## {{% heading "whatsnext" %}}
+
+
+* 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)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
index 976449d0cb..bd7d27305e 100644
--- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+++ b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -3,19 +3,19 @@ title: Custom Resources
reviewers:
- enisoc
- deads2k
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
*Custom resources* are extensions of the Kubernetes API. This page discusses when to add a custom
resource to your Kubernetes cluster and when to use a standalone service. It describes the two
methods for adding custom resources and how to choose between them.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Custom resources
A *resource* is an endpoint in the [Kubernetes API](/docs/reference/using-api/api-overview/) that stores a collection of
@@ -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/custom-resources/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/run-application/update-api-object-kubectl-patch/) | 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
@@ -246,12 +246,13 @@ When you add a custom resource, you can access it using:
- A REST client that you write.
- A client generated using [Kubernetes client generation tools](https://github.com/kubernetes/code-generator) (generating one is an advanced undertaking, but some projects may provide a client along with the CRD or AA).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* 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/).
+
-{{% /capture %}}
diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
index 23f64628b5..c8388478f5 100644
--- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@@ -2,11 +2,11 @@
reviewers:
title: Device Plugins
description: Use the Kubernetes device plugin framework to implement plugins for GPUs, NICs, FPGAs, InfiniBand, and similar resources that require vendor-specific setup.
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
Kubernetes provides a [device plugin framework](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)
@@ -19,9 +19,9 @@ The targeted devices include GPUs, high-performance NICs, FPGAs, InfiniBand adap
and other similar computing resources that may require vendor specific initialization
and setup.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Device plugin registration
@@ -223,14 +223,15 @@ Here are some examples of device plugin implementations:
* The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin)
* The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin)
* The [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin)
-* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) for Xilinx FPGA devices
+* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) for Xilinx FPGA devices
+
+
+## {{% heading "whatsnext" %}}
-{{% /capture %}}
-{{% capture whatsnext %}}
* Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device plugins
* Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node
* Read about using [hardware acceleration for TLS ingress](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes
* Learn about the [Topology Manager] (/docs/tasks/adminster-cluster/topology-manager/)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
index 2ff4ae2377..b32bce83dd 100644
--- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
+++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
@@ -4,12 +4,12 @@ reviewers:
- freehan
- thockin
title: Network Plugins
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
{{< feature-state state="alpha" >}}
{{< caution >}}Alpha features can change rapidly. {{< /caution >}}
@@ -19,9 +19,9 @@ Network plugins in Kubernetes come in a few flavors:
* CNI plugins: adhere to the appc/CNI specification, designed for interoperability.
* Kubenet plugin: implements basic `cbr0` using the `bridge` and `host-local` CNI plugins
-{{% /capture %}}
-{{% capture body %}}
+
+
## Installation
@@ -166,8 +166,9 @@ This option is provided to the network-plugin; currently **only kubenet supports
* `--network-plugin=kubenet` specifies that we use the `kubenet` network plugin with CNI `bridge` and `host-local` plugins placed in `/opt/cni/bin` or `cni-bin-dir`.
* `--network-plugin-mtu=9001` specifies the MTU to use, currently only used by the `kubenet` network plugin.
-{{% /capture %}}
-{{% capture whatsnext %}}
-{{% /capture %}}
+## {{% heading "whatsnext" %}}
+
+
+
diff --git a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md
index 2b5aa1b676..bc06bd4ab0 100644
--- a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md
+++ b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md
@@ -5,11 +5,11 @@ reviewers:
- lavalamp
- cheftako
- chenopis
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
Kubernetes is highly configurable and extensible. As a result,
there is rarely a need to fork or submit patches to the Kubernetes
@@ -22,10 +22,10 @@ their work environment. Developers who are prospective {{< glossary_tooltip text
useful as an introduction to what extension points and patterns
exist, and their trade-offs and limitations.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Overview
@@ -50,7 +50,7 @@ Extensions are software components that extend and deeply integrate with Kuberne
They adapt it to support new types and new kinds of hardware.
Most cluster administrators will use a hosted or distribution
-instance of Kubernetes. As a result, most Kubernetes users will need to
+instance of Kubernetes. As a result, most Kubernetes users will not need to
install extensions and fewer will need to author new ones.
## Extension Patterns
@@ -194,10 +194,11 @@ The scheduler also supports a
that permits a webhook backend (scheduler extension) to filter and prioritize
the nodes chosen for a pod.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [Custom Resources](/docs/concepts/api-extension/custom-resources/)
* Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)
@@ -207,4 +208,4 @@ the nodes chosen for a pod.
* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/extend-kubernetes/operator.md b/content/en/docs/concepts/extend-kubernetes/operator.md
index eb56d5475a..dda8f0020b 100644
--- a/content/en/docs/concepts/extend-kubernetes/operator.md
+++ b/content/en/docs/concepts/extend-kubernetes/operator.md
@@ -1,20 +1,20 @@
---
title: Operator pattern
-content_template: templates/concept
+content_type: concept
weight: 30
---
-{{% capture overview %}}
+
Operators are software extensions to Kubernetes that make use of [custom
resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
to manage applications and their components. Operators follow
Kubernetes principles, notably the [control loop](/docs/concepts/#kubernetes-control-plane).
-{{% /capture %}}
-{{% capture body %}}
+
+
## Motivation
@@ -113,9 +113,10 @@ Operator.
You also implement an Operator (that is, a Controller) using any language / runtime
that can act as a [client for the Kubernetes API](/docs/reference/using-api/client-libraries/).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* Find ready-made operators on [OperatorHub.io](https://operatorhub.io/) to suit your use case
@@ -129,4 +130,3 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie
* Read [CoreOS' original article](https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern
* Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
-{{% /capture %}}
\ No newline at end of file
diff --git a/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md b/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md
index 4c5ab12c03..7f81439c41 100644
--- a/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md
+++ b/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md
@@ -1,18 +1,18 @@
---
title: Poseidon-Firmament Scheduler
-content_template: templates/concept
+content_type: concept
weight: 80
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
The Poseidon-Firmament scheduler is an alternate scheduler that can be deployed alongside the default Kubernetes scheduler.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Introduction
@@ -102,10 +102,11 @@ Pod-by-pod schedulers, such as the Kubernetes default scheduler, process Pods in
These downsides of pod-by-pod schedulers are addressed by batching or bulk scheduling in Poseidon-Firmament scheduler. Processing several pods in a batch allows the scheduler to jointly consider their placement, and thus to find the best trade-off for the whole batch instead of one pod. At the same time it amortizes work across pods resulting in much higher throughput.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* See [Poseidon-Firmament](https://github.com/kubernetes-sigs/poseidon#readme) on GitHub for more information.
* See the [design document](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/design/README.md) for Poseidon.
* Read [Firmament: Fast, Centralized Cluster Scheduling at Scale](https://www.usenix.org/system/files/conference/osdi16/osdi16-gog.pdf), the academic paper on the Firmament scheduling design.
* If you'd like to contribute to Poseidon-Firmament, refer to the [developer setup instructions](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/devel/README.md).
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/extend-kubernetes/service-catalog.md b/content/en/docs/concepts/extend-kubernetes/service-catalog.md
index 35d181d998..b40ca7ee14 100644
--- a/content/en/docs/concepts/extend-kubernetes/service-catalog.md
+++ b/content/en/docs/concepts/extend-kubernetes/service-catalog.md
@@ -2,11 +2,11 @@
title: Service Catalog
reviewers:
- chenopis
-content_template: templates/concept
+content_type: concept
weight: 40
---
-{{% capture overview %}}
+
{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}}
A service broker, as defined by the [Open service broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md), is an endpoint for a set of managed services offered and maintained by a third-party, which could be a cloud provider such as AWS, GCP, or Azure.
@@ -14,10 +14,10 @@ Some examples of managed services are Microsoft Azure Cloud Queue, Amazon Simple
Using Service Catalog, a {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}} can browse the list of managed services offered by a service broker, provision an instance of a managed service, and bind with it to make it available to an application in the Kubernetes cluster.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Example use case
An {{< glossary_tooltip text="application developer" term_id="application-developer" >}} wants to use message queuing as part of their application running in a Kubernetes cluster.
@@ -222,16 +222,17 @@ The following example describes how to map secret values into application enviro
key: topic
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* If you are familiar with {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}, [install Service Catalog using Helm](/docs/tasks/service-catalog/install-service-catalog-using-helm/) into your Kubernetes cluster. Alternatively, you can [install Service Catalog using the SC tool](/docs/tasks/service-catalog/install-service-catalog-using-sc/).
* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
* Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project.
* View [svc-cat.io](https://svc-cat.io/docs/).
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/overview/_index.md b/content/en/docs/concepts/overview/_index.md
index ec86980c4b..a52c470446 100755
--- a/content/en/docs/concepts/overview/_index.md
+++ b/content/en/docs/concepts/overview/_index.md
@@ -1,4 +1,5 @@
---
title: "Overview"
weight: 20
----
\ No newline at end of file
+description: Get a high-level outline of Kubernetes and the components it is built from.
+---
diff --git a/content/en/docs/concepts/overview/components.md b/content/en/docs/concepts/overview/components.md
index 04c4bbe805..53e6b84c16 100644
--- a/content/en/docs/concepts/overview/components.md
+++ b/content/en/docs/concepts/overview/components.md
@@ -2,14 +2,17 @@
reviewers:
- lavalamp
title: Kubernetes Components
-content_template: templates/concept
+content_type: concept
+description: >
+ A Kubernetes cluster consists of the components that represent the control plane
+ and a set of machines called nodes.
weight: 20
card:
name: concepts
weight: 20
---
-{{% capture overview %}}
+
When you deploy Kubernetes, you get a cluster.
{{< glossary_definition term_id="cluster" length="all" prepend="A Kubernetes cluster consists of">}}
@@ -20,9 +23,9 @@ Here's the diagram of a Kubernetes cluster with all the components tied together
-{{% /capture %}}
-{{% capture body %}}
+
+
## Control Plane Components
The control plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new {{< glossary_tooltip text="pod" term_id="pod">}} when a deployment's `replicas` field is unsatisfied).
@@ -122,10 +125,11 @@ about containers in a central database, and provides a UI for browsing that data
A [cluster-level logging](/docs/concepts/cluster-administration/logging/) mechanism is responsible for
saving container logs to a central log store with search/browsing interface.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn about [Nodes](/docs/concepts/architecture/nodes/)
* Learn about [Controllers](/docs/concepts/architecture/controller/)
* Learn about [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/)
* Read etcd's official [documentation](https://etcd.io/docs/)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/overview/kubernetes-api.md b/content/en/docs/concepts/overview/kubernetes-api.md
index ad9569ede6..b3b6960358 100644
--- a/content/en/docs/concepts/overview/kubernetes-api.md
+++ b/content/en/docs/concepts/overview/kubernetes-api.md
@@ -2,82 +2,107 @@
reviewers:
- chenopis
title: The Kubernetes API
-content_template: templates/concept
+content_type: concept
weight: 30
+description: >
+ The Kubernetes API lets you query and manipulate the state of objects in Kubernetes.
+ The core of Kubernetes' control plane is the API server and the HTTP API that it exposes. Users, the different parts of your cluster, and external components all communicate with one another through the API server.
card:
name: concepts
weight: 30
---
-{{% capture overview %}}
+
-Overall API conventions are described in the [API conventions doc](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).
+The core of Kubernetes' {{< glossary_tooltip text="control plane" term_id="control-plane" >}}
+is the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}. The API server
+exposes an HTTP API that lets end users, different parts of your cluster, and external components
+communicate with one another.
-API endpoints, resource types and samples are described in [API Reference](/docs/reference).
+The Kubernetes API lets you query and manipulate the state of objects in the Kubernetes API
+(for example: Pods, Namespaces, ConfigMaps, and Events).
-Remote access to the API is discussed in the [Controlling API Access doc](/docs/reference/access-authn-authz/controlling-access/).
-
-The Kubernetes API also serves as the foundation for the declarative configuration schema for the system. The [kubectl](/docs/reference/kubectl/overview/) command-line tool can be used to create, update, delete, and get API objects.
-
-Kubernetes also stores its serialized state (currently in [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)) in terms of the API resources.
-
-Kubernetes itself is decomposed into multiple components, which interact through its API.
-
-{{% /capture %}}
+API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/).
-{{% capture body %}}
+
+
+
## API changes
-In our experience, any system that is successful needs to grow and change as new use cases emerge or existing ones change. Therefore, we expect the Kubernetes API to continuously change and grow. However, we intend to not break compatibility with existing clients, for an extended period of time. In general, new API resources and new resource fields can be expected to be added frequently. Elimination of resources or fields will require following the [API deprecation policy](/docs/reference/using-api/deprecation-policy/).
+Any system that is successful needs to grow and change as new use cases emerge or existing ones change.
+Therefore, Kubernetes has design features to allow the Kubernetes API to continuously change and grow.
+The Kubernetes project aims to _not_ break compatibility with existing clients, and to maintain that
+compatibility for a length of time so that other projects have an opportunity to adapt.
-What constitutes a compatible change and how to change the API are detailed by the [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md).
+In general, new API resources and new resource fields can be added often and frequently.
+Elimination of resources or fields requires following the
+[API deprecation policy](/docs/reference/using-api/deprecation-policy/).
-## OpenAPI and Swagger definitions
+What constitutes a compatible change, and how to change the API, are detailed in
+[API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme).
+
+## OpenAPI specification {#api-specification}
Complete API details are documented using [OpenAPI](https://www.openapis.org/).
-Starting with Kubernetes 1.10, the Kubernetes API server serves an OpenAPI spec via the `/openapi/v2` endpoint.
-The requested format is specified by setting HTTP headers:
+The Kubernetes API server serves an OpenAPI spec via the `/openapi/v2` endpoint.
+You can request the response format using request headers as follows:
-Header | Possible Values
------- | ---------------
-Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (the default content-type is `application/json` for `*/*` or not passing this header)
-Accept-Encoding | `gzip` (not passing this header is acceptable)
-
-Prior to 1.14, format-separated endpoints (`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)
-serve the OpenAPI spec in different formats. These endpoints are deprecated, and are removed in Kubernetes 1.14.
-
-**Examples of getting OpenAPI spec**:
-
-Before 1.10 | Starting with Kubernetes 1.10
------------ | -----------------------------
-GET /swagger.json | GET /openapi/v2 **Accept**: application/json
-GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf
-GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip
+
Valid request header values for OpenAPI v2 queries
+
Kubernetes implements an alternative Protobuf based serialization format for the API that is primarily intended for intra-cluster communication, documented in the [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) and the IDL files for each schema are located in the Go packages that define the API objects.
-Prior to 1.14, the Kubernetes apiserver also exposes an API that can be used to retrieve
-the [Swagger v1.2](http://swagger.io/) Kubernetes API spec at `/swaggerapi`.
-This endpoint is deprecated, and was removed in Kubernetes 1.14.
-
## API versioning
To make it easier to eliminate fields or restructure resource representations, Kubernetes supports
multiple API versions, each at a different API path, such as `/api/v1` or
`/apis/extensions/v1beta1`.
-We chose to version at the API level rather than at the resource or field level to ensure that the API presents a clear, consistent view of system resources and behavior, and to enable controlling access to end-of-life and/or experimental APIs. The JSON and Protobuf serialization schemas follow the same guidelines for schema changes - all descriptions below cover both formats.
+Versioning is done at the API level rather than at the resource or field level to ensure that the
+API presents a clear, consistent view of system resources and behavior, and to enable controlling
+access to end-of-life and/or experimental APIs.
-Note that API versioning and Software versioning are only indirectly related. The [API and release
-versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) describes the relationship between API versioning and
-software versioning.
+The JSON and Protobuf serialization schemas follow the same guidelines for schema changes - all descriptions below cover both formats.
+Note that API versioning and Software versioning are only indirectly related. The
+[Kubernetes Release Versioning](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
+proposal describes the relationship between API versioning and software versioning.
Different API versions imply different levels of stability and support. The criteria for each level are described
-in more detail in the [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). They are summarized here:
+in more detail in the
+[API Changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)
+documentation. They are summarized here:
- Alpha level:
- The version names contain `alpha` (e.g. `v1alpha1`).
@@ -101,35 +126,36 @@ in more detail in the [API Changes documentation](https://git.k8s.io/community/c
## API groups
-To make it easier to extend the Kubernetes API, we implemented [*API groups*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md).
+To make it easier to extend its API, Kubernetes implements [*API groups*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md).
The API group is specified in a REST path and in the `apiVersion` field of a serialized object.
-Currently there are several API groups in use:
+There are several API groups in a cluster:
-1. The *core* group, often referred to as the *legacy group*, is at the REST path `/api/v1` and uses `apiVersion: v1`.
+1. The *core* group, also referred to as the *legacy* group, is at the REST path `/api/v1` and uses `apiVersion: v1`.
-1. The named groups are at REST path `/apis/$GROUP_NAME/$VERSION`, and use `apiVersion: $GROUP_NAME/$VERSION`
- (e.g. `apiVersion: batch/v1`). Full list of supported API groups can be seen in [Kubernetes API reference](/docs/reference/).
+1. *Named* groups are at REST path `/apis/$GROUP_NAME/$VERSION`, and use `apiVersion: $GROUP_NAME/$VERSION`
+ (e.g. `apiVersion: batch/v1`). The Kubernetes [API reference](/docs/reference/kubernetes-api/) has a
+ full list of available API groups.
+There are two paths to extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/):
-There are two supported 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/)
- is for users with very basic CRUD needs.
-1. Users needing the full set of Kubernetes API semantics can implement their own apiserver
- and use the [aggregator](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)
+1. [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/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/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
-Certain resources and API groups are enabled by default. They can be enabled or disabled by setting `--runtime-config`
-on apiserver. `--runtime-config` accepts comma separated values. For example: to disable batch/v1, set
-`--runtime-config=batch/v1=false`, to enable batch/v2alpha1, set `--runtime-config=batch/v2alpha1`.
-The flag accepts comma separated set of key=value pairs describing runtime configuration of the apiserver.
+Certain resources and API groups are enabled by default. They can be enabled or disabled by setting `--runtime-config`
+as a command line option to the kube-apiserver.
-{{< note >}}Enabling or disabling groups or resources requires restarting apiserver and controller-manager
-to pick up the `--runtime-config` changes.{{< /note >}}
+`--runtime-config` accepts comma separated values. For example: to disable batch/v1, set
+`--runtime-config=batch/v1=false`; to enable batch/v2alpha1, set `--runtime-config=batch/v2alpha1`.
+The flag accepts comma separated set of key=value pairs describing runtime configuration of the API server.
+
+{{< note >}}Enabling or disabling groups or resources requires restarting the kube-apiserver and the
+kube-controller-manager to pick up the `--runtime-config` changes.{{< /note >}}
## Enabling specific resources in the extensions/v1beta1 group
@@ -139,4 +165,19 @@ For example: to enable deployments and daemonsets, set
{{< note >}}Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons.{{< /note >}}
-{{% /capture %}}
+## Persistence
+
+Kubernetes stores its serialized state in terms of the API resources by writing them into
+{{< glossary_tooltip term_id="etcd" >}}.
+
+
+## {{% heading "whatsnext" %}}
+
+[Controlling API Access](/docs/reference/access-authn-authz/controlling-access/) describes
+how the cluster manages authentication and authorization for API access.
+
+Overall API conventions are described in the
+[API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)
+document.
+
+API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/).
diff --git a/content/en/docs/concepts/overview/what-is-kubernetes.md b/content/en/docs/concepts/overview/what-is-kubernetes.md
index fbe74e4337..5060b6f287 100644
--- a/content/en/docs/concepts/overview/what-is-kubernetes.md
+++ b/content/en/docs/concepts/overview/what-is-kubernetes.md
@@ -5,18 +5,18 @@ reviewers:
title: What is Kubernetes?
description: >
Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
-content_template: templates/concept
+content_type: concept
weight: 10
card:
name: concepts
weight: 10
---
-{{% capture overview %}}
+
This page is an overview of Kubernetes.
-{{% /capture %}}
-{{% capture body %}}
+
+
Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
The name Kubernetes originates from Greek, meaning helmsman or pilot. Google open-sourced the Kubernetes project in 2014. Kubernetes combines [over 15 years of Google's experience](/blog/2015/04/borg-predecessor-to-kubernetes/) running production workloads at scale with best-of-breed ideas and practices from the community.
@@ -74,7 +74,7 @@ Kubernetes lets you store and manage sensitive information, such as passwords, O
## What Kubernetes is not
-Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system. Since Kubernetes operates at the container level rather than at the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, logging, and monitoring. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable. Kubernetes provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important.
+Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system. Since Kubernetes operates at the container level rather than at the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, and lets users integrate their logging, monitoring, and alerting solutions. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable. Kubernetes provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important.
Kubernetes:
@@ -86,9 +86,10 @@ Kubernetes:
* Does not provide nor adopt any comprehensive machine configuration, maintenance, management, or self-healing systems.
* Additionally, Kubernetes is not a mere orchestration system. In fact, it eliminates the need for orchestration. The technical definition of orchestration is execution of a defined workflow: first do A, then B, then C. In contrast, Kubernetes comprises a set of independent, composable control processes that continuously drive the current state towards the provided desired state. It shouldn’t matter how you get from A to C. Centralized control is also not required. This results in a system that is easier to use and more powerful, robust, resilient, and extensible.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Take a look at the [Kubernetes Components](/docs/concepts/overview/components/)
* Ready to [Get Started](/docs/setup/)?
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/overview/working-with-objects/_index.md b/content/en/docs/concepts/overview/working-with-objects/_index.md
index 8661349a3f..f872c20697 100755
--- a/content/en/docs/concepts/overview/working-with-objects/_index.md
+++ b/content/en/docs/concepts/overview/working-with-objects/_index.md
@@ -1,5 +1,7 @@
---
title: "Working with Kubernetes Objects"
weight: 40
+description: >
+ Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster.
+ Learn about the Kubernetes object model and how to work with these objects.
---
-
diff --git a/content/en/docs/concepts/overview/working-with-objects/annotations.md b/content/en/docs/concepts/overview/working-with-objects/annotations.md
index f88c6a0003..d440d2965e 100644
--- a/content/en/docs/concepts/overview/working-with-objects/annotations.md
+++ b/content/en/docs/concepts/overview/working-with-objects/annotations.md
@@ -1,15 +1,15 @@
---
title: Annotations
-content_template: templates/concept
+content_type: concept
weight: 50
---
-{{% capture overview %}}
+
You can use Kubernetes annotations to attach arbitrary non-identifying metadata
to objects. Clients such as tools and libraries can retrieve this metadata.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Attaching metadata to objects
You can use either labels or annotations to attach metadata to Kubernetes
@@ -88,10 +88,11 @@ spec:
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Learn more about [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/).
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/overview/working-with-objects/common-labels.md b/content/en/docs/concepts/overview/working-with-objects/common-labels.md
index d360d7d284..11e8944c8a 100644
--- a/content/en/docs/concepts/overview/working-with-objects/common-labels.md
+++ b/content/en/docs/concepts/overview/working-with-objects/common-labels.md
@@ -1,18 +1,18 @@
---
title: Recommended Labels
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
You can visualize and manage Kubernetes objects with more tools than kubectl and
the dashboard. A common set of labels allows tools to work interoperably, describing
objects in a common manner that all tools can understand.
In addition to supporting tooling, the recommended labels describe applications
in a way that can be queried.
-{{% /capture %}}
-{{% capture body %}}
+
+
The metadata is organized around the concept of an _application_. Kubernetes is not
a platform as a service (PaaS) and doesn't have or enforce a formal notion of an application.
Instead, applications are informal and described with metadata. The definition of
@@ -170,4 +170,4 @@ metadata:
With the MySQL `StatefulSet` and `Service` you'll notice information about both MySQL and Wordpress, the broader application, are included.
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/overview/working-with-objects/field-selectors.md b/content/en/docs/concepts/overview/working-with-objects/field-selectors.md
index 44cd54e72f..45a81e9035 100644
--- a/content/en/docs/concepts/overview/working-with-objects/field-selectors.md
+++ b/content/en/docs/concepts/overview/working-with-objects/field-selectors.md
@@ -16,12 +16,7 @@ kubectl get pods --field-selector status.phase=Running
```
{{< note >}}
-Field selectors are essentially resource *filters*. By default, no selectors/filters are applied, meaning that all resources of the specified type are selected. This makes the following `kubectl` queries equivalent:
-
-```shell
-kubectl get pods
-kubectl get pods --field-selector ""
-```
+Field selectors are essentially resource *filters*. By default, no selectors/filters are applied, meaning that all resources of the specified type are selected. This makes the `kubectl` queries `kubectl get pods` and `kubectl get pods --field-selector ""` equivalent.
{{< /note >}}
## Supported fields
diff --git a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
index b9df009db7..1f4f4e7509 100644
--- a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@@ -1,17 +1,17 @@
---
title: Understanding Kubernetes Objects
-content_template: templates/concept
+content_type: concept
weight: 10
card:
name: concepts
weight: 40
---
-{{% capture overview %}}
+
This page explains how Kubernetes objects are represented in the Kubernetes API, and how you can express them in `.yaml` format.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Understanding Kubernetes objects {#kubernetes-objects}
*Kubernetes objects* are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:
@@ -87,12 +87,13 @@ For example, the `spec` format for a Pod can be found in
and the `spec` format for a Deployment can be found in
[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [Kubernetes API overview](/docs/reference/using-api/api-overview/) explains some more API concepts
* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/pod-overview/).
* Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/overview/working-with-objects/labels.md b/content/en/docs/concepts/overview/working-with-objects/labels.md
index f08daf323b..e995db10a5 100644
--- a/content/en/docs/concepts/overview/working-with-objects/labels.md
+++ b/content/en/docs/concepts/overview/working-with-objects/labels.md
@@ -2,11 +2,11 @@
reviewers:
- mikedanese
title: Labels and Selectors
-content_template: templates/concept
+content_type: concept
weight: 40
---
-{{% capture overview %}}
+
_Labels_ are key/value pairs that are attached to objects, such as pods.
Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system.
@@ -24,10 +24,10 @@ Each object can have a set of key/value labels defined. Each Key must be unique
Labels allow for efficient queries and watches and are ideal for use in UIs and CLIs. Non-identifying information should be recorded using [annotations](/docs/concepts/overview/working-with-objects/annotations/).
-{{% /capture %}}
-{{% capture body %}}
+
+
## Motivation
@@ -228,4 +228,4 @@ selector:
One use case for selecting over labels is to constrain the set of nodes onto which a pod can schedule.
See the documentation on [node selection](/docs/concepts/scheduling-eviction/assign-pod-node/) for more information.
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/overview/working-with-objects/names.md b/content/en/docs/concepts/overview/working-with-objects/names.md
index 01bb53b56d..9831f7335c 100644
--- a/content/en/docs/concepts/overview/working-with-objects/names.md
+++ b/content/en/docs/concepts/overview/working-with-objects/names.md
@@ -3,11 +3,11 @@ reviewers:
- mikedanese
- thockin
title: Object Names and IDs
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
Each object in your cluster has a [_Name_](#names) that is unique for that type of resource.
Every Kubernetes object also has a [_UID_](#uids) that is unique across your whole cluster.
@@ -16,9 +16,9 @@ For example, you can only have one Pod named `myapp-1234` within the same [names
For non-unique user-provided attributes, Kubernetes provides [labels](/docs/concepts/overview/working-with-objects/labels/) and [annotations](/docs/concepts/overview/working-with-objects/annotations/).
-{{% /capture %}}
-{{% capture body %}}
+
+
## Names
@@ -81,8 +81,9 @@ Some resource types have additional restrictions on their names.
Kubernetes UIDs are universally unique identifiers (also known as UUIDs).
UUIDs are standardized as ISO/IEC 9834-8 and as ITU-T X.667.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Read about [labels](/docs/concepts/overview/working-with-objects/labels/) in Kubernetes.
* See the [Identifiers and Names in Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) design document.
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/overview/working-with-objects/namespaces.md b/content/en/docs/concepts/overview/working-with-objects/namespaces.md
index 8d6e907afd..07e7dac726 100644
--- a/content/en/docs/concepts/overview/working-with-objects/namespaces.md
+++ b/content/en/docs/concepts/overview/working-with-objects/namespaces.md
@@ -4,19 +4,19 @@ reviewers:
- mikedanese
- thockin
title: Namespaces
-content_template: templates/concept
+content_type: concept
weight: 30
---
-{{% capture overview %}}
+
Kubernetes supports multiple virtual clusters backed by the same physical cluster.
These virtual clusters are called namespaces.
-{{% /capture %}}
-{{% capture body %}}
+
+
## When to Use Multiple Namespaces
@@ -43,6 +43,10 @@ resources within the same namespace.
Creation and deletion of namespaces are described in the [Admin Guide documentation
for namespaces](/docs/admin/namespaces).
+{{< note >}}
+ Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces.
+{{< /note >}}
+
### Viewing namespaces
You can list the current namespaces in a cluster using:
@@ -58,12 +62,13 @@ kube-public Active 1d
kube-system Active 1d
```
-Kubernetes starts with three initial namespaces:
+Kubernetes starts with four initial namespaces:
* `default` The default namespace for objects with no other namespace
* `kube-system` The namespace for objects created by the Kubernetes system
* `kube-public` This namespace is created automatically and is readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement.
-
+ * `kube-node-lease` This namespace for the lease objects associated with each node which improves the performance of the node heartbeats as the cluster scales.
+
### Setting the namespace for a request
To set the namespace for a current request, use the `--namespace` flag.
@@ -112,11 +117,12 @@ kubectl api-resources --namespaced=true
kubectl api-resources --namespaced=false
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [creating a new namespace](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace).
* Learn more about [deleting a namespace](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace).
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/overview/working-with-objects/object-management.md b/content/en/docs/concepts/overview/working-with-objects/object-management.md
index 288be6a684..7cb65b5497 100644
--- a/content/en/docs/concepts/overview/working-with-objects/object-management.md
+++ b/content/en/docs/concepts/overview/working-with-objects/object-management.md
@@ -1,17 +1,17 @@
---
title: Kubernetes Object Management
-content_template: templates/concept
+content_type: concept
weight: 15
---
-{{% capture overview %}}
+
The `kubectl` command-line tool supports several different ways to create and manage
Kubernetes objects. This document provides an overview of the different
approaches. Read the [Kubectl book](https://kubectl.docs.kubernetes.io) for
details of managing objects by Kubectl.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Management techniques
@@ -40,12 +40,6 @@ objects, it provides no history of previous configurations.
Run an instance of the nginx container by creating a Deployment object:
-```sh
-kubectl run nginx --image nginx
-```
-
-Do the same thing using a different syntax:
-
```sh
kubectl create deployment nginx --image nginx
```
@@ -173,9 +167,10 @@ Disadvantages compared to imperative object configuration:
- Declarative object configuration is harder to debug and understand results when they are unexpected.
- Partial updates using diffs create complex merge and patch operations.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
- [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
- [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tasks/manage-kubernetes-objects/imperative-config/)
@@ -185,4 +180,4 @@ Disadvantages compared to imperative object configuration:
- [Kubectl Book](https://kubectl.docs.kubernetes.io)
- [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/policy/_index.md b/content/en/docs/concepts/policy/_index.md
index 41d91de546..d2b42bc4cd 100755
--- a/content/en/docs/concepts/policy/_index.md
+++ b/content/en/docs/concepts/policy/_index.md
@@ -1,5 +1,6 @@
---
title: "Policies"
weight: 90
+description: >
+ Policies you can configure that apply to groups of resources.
---
-
diff --git a/content/en/docs/concepts/policy/limit-range.md b/content/en/docs/concepts/policy/limit-range.md
index 8bea6c88e7..5b670d38a0 100644
--- a/content/en/docs/concepts/policy/limit-range.md
+++ b/content/en/docs/concepts/policy/limit-range.md
@@ -2,20 +2,20 @@
reviewers:
- nelvadas
title: Limit Ranges
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
By default, containers run with unbounded [compute resources](/docs/user-guide/compute-resources) on a Kubernetes cluster.
With resource quotas, cluster administrators can restrict resource consumption and creation on a {{< glossary_tooltip text="namespace" term_id="namespace" >}} basis.
Within a namespace, a Pod or Container can consume as much CPU and memory as defined by the namespace's resource quota. There is a concern that one Pod or Container could monopolize all available resources. A LimitRange is a policy to constrain resource allocations (to Pods or Containers) in a namespace.
-{{% /capture %}}
-{{% capture body %}}
+
+
A _LimitRange_ provides constraints that can:
@@ -26,9 +26,7 @@ A _LimitRange_ provides constraints that can:
## Enabling LimitRange
-LimitRange support is enabled by default for many Kubernetes distributions. It is
-enabled when the apiserver `--enable-admission-plugins=` flag has `LimitRanger` admission controller as
-one of its arguments.
+LimitRange support has been enabled by default since Kubernetes 1.10.
A LimitRange is enforced in a particular namespace when there is a
LimitRange object in that namespace.
@@ -56,9 +54,10 @@ there may be contention for resources. In this case, the Containers or Pods will
Neither contention nor changes to a LimitRange will affect already created resources.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Refer to the [LimitRanger design document](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) for more information.
@@ -72,4 +71,4 @@ For examples on using limits, see:
- a [detailed example on configuring quota per namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/).
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/policy/pod-security-policy.md b/content/en/docs/concepts/policy/pod-security-policy.md
index 52aa593e6f..5a5241c42e 100644
--- a/content/en/docs/concepts/policy/pod-security-policy.md
+++ b/content/en/docs/concepts/policy/pod-security-policy.md
@@ -3,21 +3,21 @@ reviewers:
- pweil-
- tallclair
title: Pod Security Policies
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
{{< feature-state state="beta" >}}
Pod Security Policies enable fine-grained authorization of pod creation and
updates.
-{{% /capture %}}
-{{% capture body %}}
+
+
## What is a Pod Security Policy?
@@ -34,7 +34,7 @@ administrator to control the following:
| Usage of host networking and ports | [`hostNetwork`, `hostPorts`](#host-namespaces) |
| Usage of volume types | [`volumes`](#volumes-and-file-systems) |
| Usage of the host filesystem | [`allowedHostPaths`](#volumes-and-file-systems) |
-| White list of FlexVolume drivers | [`allowedFlexVolumes`](#flexvolume-drivers) |
+| Allow specific FlexVolume drivers | [`allowedFlexVolumes`](#flexvolume-drivers) |
| Allocating an FSGroup that owns the pod's volumes | [`fsGroup`](#volumes-and-file-systems) |
| Requiring the use of a read only root file system | [`readOnlyRootFilesystem`](#volumes-and-file-systems) |
| The user and group IDs of the container | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#users-and-groups) |
@@ -401,13 +401,13 @@ namespace. Doing so gives the pod access to the loopback device, services
listening on localhost, and could be used to snoop on network activity of other
pods on the same node.
-**HostPorts** - Provides a whitelist of ranges of allowable ports in the host
+**HostPorts** - Provides a list of ranges of allowable ports in the host
network namespace. Defined as a list of `HostPortRange`, with `min`(inclusive)
and `max`(inclusive). Defaults to no allowed host ports.
### Volumes and file systems
-**Volumes** - Provides a whitelist of allowed volume types. The allowable values
+**Volumes** - Provides a list of allowed volume types. The allowable values
correspond to the volume sources that are defined when creating a volume. For
the complete list of volume types, see [Types of
Volumes](/docs/concepts/storage/volumes/#types-of-volumes). Additionally, `*`
@@ -438,7 +438,7 @@ minimum value of the first range as the default. Validates against all ranges.
all ranges if `FSGroups` is set.
- *RunAsAny* - No default provided. Allows any `fsGroup` ID to be specified.
-**AllowedHostPaths** - This specifies a whitelist of host paths that are allowed
+**AllowedHostPaths** - This specifies a list of host paths that are allowed
to be used by hostPath volumes. An empty list means there is no restriction on
host paths used. This is defined as a list of objects with a single `pathPrefix`
field, which allows hostPath volumes to mount a path that begins with an
@@ -469,7 +469,7 @@ root filesystem (i.e. no writable layer).
### FlexVolume drivers
-This specifies a whitelist of FlexVolume drivers that are allowed to be used
+This specifies a list of FlexVolume drivers that are allowed to be used
by flexvolume. An empty list or nil means there is no restriction on the drivers.
Please make sure [`volumes`](#volumes-and-file-systems) field contains the
`flexVolume` volume type; no FlexVolume driver is allowed otherwise.
@@ -555,7 +555,7 @@ the PodSecurityPolicy. For more details on Linux capabilities, see
The following fields take a list of capabilities, specified as the capability
name in ALL_CAPS without the `CAP_` prefix.
-**AllowedCapabilities** - Provides a whitelist of capabilities that may be added
+**AllowedCapabilities** - Provides a list of capabilities that are allowed to be added
to a container. The default set of capabilities are implicitly allowed. The
empty set means that no additional capabilities may be added beyond the default
set. `*` can be used to allow all capabilities.
@@ -579,7 +579,7 @@ specified.
### AllowedProcMountTypes
-`allowedProcMountTypes` is a whitelist of allowed ProcMountTypes.
+`allowedProcMountTypes` is a list of allowed ProcMountTypes.
Empty or nil indicates that only the `DefaultProcMountType` may be used.
`DefaultProcMount` uses the container runtime defaults for readonly and masked
@@ -631,12 +631,13 @@ By default, all safe sysctls are allowed.
Refer to the [Sysctl documentation](
/docs/concepts/cluster-administration/sysctl-cluster/#podsecuritypolicy).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
See [Pod Security Standards](/docs/concepts/security/pod-security-standards/) for policy recommendations.
Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details.
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md
index 39f51bf2d7..4fb3f17a38 100644
--- a/content/en/docs/concepts/policy/resource-quotas.md
+++ b/content/en/docs/concepts/policy/resource-quotas.md
@@ -2,21 +2,21 @@
reviewers:
- derekwaynecarr
title: Resource Quotas
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
When several users or teams share a cluster with a fixed number of nodes,
there is a concern that one team could use more than its fair share of resources.
Resource quotas are a tool for administrators to address this concern.
-{{% /capture %}}
-{{% capture body %}}
+
+
A resource quota, defined by a `ResourceQuota` object, provides constraints that limit
aggregate resource consumption per namespace. It can limit the quantity of objects that can
@@ -596,10 +596,11 @@ See [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) and
See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information.
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/scheduling-eviction/_index.md b/content/en/docs/concepts/scheduling-eviction/_index.md
index a30a80a451..3a2bf9359f 100644
--- a/content/en/docs/concepts/scheduling-eviction/_index.md
+++ b/content/en/docs/concepts/scheduling-eviction/_index.md
@@ -1,5 +1,8 @@
---
title: "Scheduling and Eviction"
weight: 90
+description: >
+ In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes so that the kubelet can run them.
+ Eviction is the process of proactively failing one or more Pods on resource-starved Nodes.
---
diff --git a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
index 79a9487c60..a30efc6ef6 100644
--- a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
+++ b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
@@ -4,12 +4,12 @@ reviewers:
- kevin-wangzefeng
- bsalamat
title: Assigning Pods to Nodes
-content_template: templates/concept
+content_type: concept
weight: 50
---
-{{% capture overview %}}
+
You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} to only be able to run on particular
{{< glossary_tooltip text="Node(s)" term_id="node" >}}, or to prefer to run on particular nodes.
@@ -21,9 +21,9 @@ but there are some circumstances where you may want more control on a node where
that a pod ends up on a machine with an SSD attached to it, or to co-locate pods from two different
services that communicate a lot into the same availability zone.
-{{% /capture %}}
-{{% capture body %}}
+
+
## nodeSelector
@@ -213,10 +213,8 @@ as at least one already-running pod that has a label with key "security" and val
on node N if node N has a label with key `failure-domain.beta.kubernetes.io/zone` and some value V
such that there is at least one node in the cluster with key `failure-domain.beta.kubernetes.io/zone` and
value V that is running a pod that has a label with key "security" and value "S1".) The pod anti-affinity
-rule says that the pod prefers not to be scheduled onto a node if that node is already running a pod with label
-having key "security" and value "S2". (If the `topologyKey` were `failure-domain.beta.kubernetes.io/zone` then
-it would mean that the pod cannot be scheduled onto a node if that node is in the same zone as a pod with
-label having key "security" and value "S2".) See the
+rule says that the pod cannot be scheduled onto a node if that node is in the same zone as a pod with
+label having key "security" and value "S2". See the
[design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
for many more examples of pod affinity and anti-affinity, both the `requiredDuringSchedulingIgnoredDuringExecution`
flavor and the `preferredDuringSchedulingIgnoredDuringExecution` flavor.
@@ -388,9 +386,10 @@ spec:
The above pod will run on the node kube-01.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
[Taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) allow a Node to *repel* a set of Pods.
@@ -402,4 +401,4 @@ Once a Pod is assigned to a Node, the kubelet runs the Pod and allocates node-lo
The [topology manager](/docs/tasks/administer-cluster/topology-manager/) can take part in node-level
resource allocation decisions.
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md
index 2fea98bfb4..406c3f974b 100644
--- a/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md
+++ b/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md
@@ -1,18 +1,18 @@
---
title: Kubernetes Scheduler
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
In Kubernetes, _scheduling_ refers to making sure that {{< glossary_tooltip text="Pods" term_id="pod" >}}
are matched to {{< glossary_tooltip text="Nodes" term_id="node" >}} so that
{{< glossary_tooltip term_id="kubelet" >}} can run them.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Scheduling overview {#scheduling}
@@ -86,12 +86,13 @@ of the scheduler:
`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, and others. You
can also configure the kube-scheduler to run different profiles.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Read about [scheduler performance tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
* Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
* Learn about [configuring multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
* Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/)
* Learn about [Pod Overhead](/docs/concepts/configuration/pod-overhead/)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/en/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
index e3d4b16861..06f535a574 100644
--- a/content/en/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
+++ b/content/en/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
@@ -2,11 +2,11 @@
reviewers:
- bsalamat
title: Scheduler Performance Tuning
-content_template: templates/concept
+content_type: concept
weight: 70
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.14" state="beta" >}}
@@ -24,9 +24,9 @@ in a process called _Binding_.
This page explains performance tuning optimizations that are relevant for
large Kubernetes clusters.
-{{% /capture %}}
-{{% capture body %}}
+
+
In large clusters, you can tune the scheduler's behaviour balancing
scheduling outcomes between latency (new Pods are placed quickly) and
@@ -164,4 +164,4 @@ Node 1, Node 5, Node 2, Node 6, Node 3, Node 4
After going over all the Nodes, it goes back to Node 1.
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md
index d1123b72e1..5798b0579f 100644
--- a/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md
+++ b/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md
@@ -2,11 +2,11 @@
reviewers:
- ahg-g
title: Scheduling Framework
-content_template: templates/concept
+content_type: concept
weight: 60
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
@@ -20,9 +20,9 @@ framework.
[kep]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md
-{{% /capture %}}
-{{% capture body %}}
+
+
# Framework workflow
@@ -239,4 +239,3 @@ If you are using Kubernetes v1.18 or later, you can configure a set of plugins a
a scheduler profile and then define multiple profiles to fit various kinds of workload.
Learn more at [multiple profiles](/docs/reference/scheduling/profiles/#multiple-profiles).
-{{% /capture %}}
\ No newline at end of file
diff --git a/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md
index c803676d3a..97a190a280 100644
--- a/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md
+++ b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md
@@ -4,12 +4,12 @@ reviewers:
- kevin-wangzefeng
- bsalamat
title: Taints and Tolerations
-content_template: templates/concept
+content_type: concept
weight: 40
---
-{{% capture overview %}}
+
[_Node affinity_](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity),
is a property of {{< glossary_tooltip text="Pods" term_id="pod" >}} that *attracts* them to
a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (either as a preference or a
@@ -22,9 +22,9 @@ Taints and tolerations work together to ensure that pods are not scheduled
onto inappropriate nodes. One or more taints are applied to a node; this
marks that the node should not accept any pods that do not tolerate the taints.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Concepts
@@ -250,7 +250,7 @@ tolerations:
Kubernetes automatically adds a toleration for
`node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable`
with `tolerationSeconds=300`,
-unless you, or a controller, set those tolerations explictly.
+unless you, or a controller, set those tolerations explicitly.
These automatically-added tolerations mean that Pods remain bound to
Nodes for 5 minutes after one of these problems is detected.
@@ -282,9 +282,10 @@ tolerations to all daemons, to prevent DaemonSets from breaking.
Adding these tolerations ensures backward compatibility. You can also add
arbitrary tolerations to DaemonSets.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Read about [out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) and how you can configure it
* Read about [pod priority](/docs/concepts/configuration/pod-priority-preemption/)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/security/_index.md b/content/en/docs/concepts/security/_index.md
index aecc16eee7..3dfb62fe48 100644
--- a/content/en/docs/concepts/security/_index.md
+++ b/content/en/docs/concepts/security/_index.md
@@ -1,4 +1,6 @@
---
title: "Security"
weight: 81
+description: >
+ Concepts for keeping your cloud-native workload secure.
---
diff --git a/content/en/docs/concepts/security/overview.md b/content/en/docs/concepts/security/overview.md
index 20ba255039..98776c7199 100644
--- a/content/en/docs/concepts/security/overview.md
+++ b/content/en/docs/concepts/security/overview.md
@@ -2,60 +2,54 @@
reviewers:
- zparnold
title: Overview of Cloud Native Security
-content_template: templates/concept
-weight: 1
+content_type: concept
+weight: 10
---
-{{< toc >}}
+
-{{% capture overview %}}
-Kubernetes Security (and security in general) is an immense topic that has many
-highly interrelated parts. In today's era where open source software is
-integrated into many of the systems that help web applications run,
-there are some overarching concepts that can help guide your intuition about how you can
-think about security holistically. This guide will define a mental model
-for some general concepts surrounding Cloud Native Security. The mental model is completely arbitrary
-and you should only use it if it helps you think about where to secure your software
-stack.
-{{% /capture %}}
+This overview defines a model for thinking about Kubernetes security in the context of Cloud Native security.
-{{% capture body %}}
+{{< warning >}}
+This container security model provides suggestions, not proven information security policies.
+{{< /warning >}}
+
+
+
+## The 4C's of Cloud Native security
+
+You can think about security in layers. The 4C's of Cloud Native security are Cloud,
+Clusters, Containers, and Code.
-## The 4C's of Cloud Native Security
-Let's start with a diagram that may help you understand how you can think about security in layers.
{{< note >}}
This layered approach augments the [defense in depth](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))
-approach to security, which is widely regarded as a best practice for securing
-software systems. The 4C's are Cloud, Clusters, Containers, and Code.
+computing approach to security, which is widely regarded as a best practice for securing
+software systems.
{{< /note >}}
{{< figure src="/images/docs/4c.png" title="The 4C's of Cloud Native Security" >}}
-
-As you can see from the above figure,
-each one of the 4C's depend on the security of the squares in which they fit. It
-is nearly impossibly to safeguard against poor security standards in Cloud, Containers, and Code
-by only addressing security at the code level. However, when these areas are dealt
-with appropriately, then adding security to your code augments an already strong
-base. These areas of concern will now be described in more detail below.
+Each layer of the Cloud Native security model builds upon the next outermost layer.
+The Code layer benefits from strong base (Cloud, Cluster, Container) security layers.
+You cannot safeguard against poor security standards in the base layers by addressing
+security at the Code level.
## Cloud
In many ways, the Cloud (or co-located servers, or the corporate datacenter) is the
[trusted computing base](https://en.wikipedia.org/wiki/Trusted_computing_base)
-of a Kubernetes cluster. If these components themselves are vulnerable (or
-configured in a vulnerable way) then there's no real way to guarantee the security
-of any components built on top of this base. Each cloud provider has extensive
-security recommendations they make to their customers on how to run workloads securely
-in their environment. It is out of the scope of this guide to give recommendations
-on cloud security since every cloud provider and workload is different. Here are some
-links to some of the popular cloud providers' documentation
-for security as well as give general guidance for securing the infrastructure that
-makes up a Kubernetes cluster.
+of a Kubernetes cluster. If the Cloud layer is vulnerable (or
+configured in a vulnerable way) then there is no guarantee that the components built
+on top of this base are secure. Each cloud provider makes security recommendations
+for running workloads securely in their environment.
-### Cloud Provider Security Table
+### Cloud provider security
+If you are running a Kubernetes cluster on your own hardware or a different cloud provider,
+consult your documentation for security best practices.
+Here are links to some of the popular cloud providers' security documentation:
+{{< table caption="Cloud provider security" >}}
IaaS Provider | Link |
-------------------- | ------------ |
@@ -66,46 +60,48 @@ IBM Cloud | https://www.ibm.com/cloud/security |
Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
VMWare VSphere | https://www.vmware.com/security/hardening-guides.html |
+{{< /table >}}
-If you are running on your own hardware or a different cloud provider you will need to
-consult your documentation for security best practices.
+### Infrastructure security {#infrastructure-security}
-### General Infrastructure Guidance Table
+Suggestions for securing your infrastructure in a Kubernetes cluster:
+
+{{< table caption="Infrastructure security" >}}
Area of Concern for Kubernetes Infrastructure | Recommendation |
---------------------------------------------- | ------------ |
-Network access to API Server (Masters) | Ideally all access to the Kubernetes Masters is not allowed publicly on the internet and is controlled by network access control lists restricted to the set of IP addresses needed to administer the cluster.|
-Network access to Nodes (Worker Servers) | Nodes should be configured to _only_ accept connections (via network access control lists) from the masters on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer. If possible, these nodes should not be exposed on the public internet entirely.
-Kubernetes access to Cloud Provider API | Each cloud provider will need to grant a different set of permissions to the Kubernetes Masters and Nodes, so this recommendation will be more generic. It is best to provide the cluster with cloud provider access that follows the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) for the resources it needs to administer. An example for Kops in AWS can be found here: https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles
-Access to etcd | Access to etcd (the datastore of Kubernetes) should be limited to the masters only. Depending on your configuration, you should also attempt to use etcd over TLS. More info can be found here: https://github.com/etcd-io/etcd/tree/master/Documentation#security
+--------------------------------------------- | -------------- |
+Network access to API Server (Control plane) | All access to the Kubernetes control plane is not allowed publicly on the internet and is controlled by network access control lists restricted to the set of IP addresses needed to administer the cluster.|
+Network access to Nodes (nodes) | Nodes should be configured to _only_ accept connections (via network access control lists)from the control plane on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer. If possible, these nodes should not be exposed on the public internet entirely.
+Kubernetes access to Cloud Provider API | Each cloud provider needs to grant a different set of permissions to the Kubernetes control plane and nodes. It is best to provide the cluster with cloud provider access that follows the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) for the resources it needs to administer. The [Kops documentation](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles) provides information about IAM policies and roles.
+Access to etcd | Access to etcd (the datastore of Kubernetes) should be limited to the control plane only. Depending on your configuration, you should attempt to use etcd over TLS. More information can be found in the [etcd documentation](https://github.com/etcd-io/etcd/tree/master/Documentation).
etcd Encryption | Wherever possible it's a good practice to encrypt all drives at rest, but since etcd holds the state of the entire cluster (including Secrets) its disk should especially be encrypted at rest.
+{{< /table >}}
+
## Cluster
-This section will provide links for securing
-workloads in Kubernetes. There are two areas of concern for securing
-Kubernetes:
+There are two areas of concern for securing Kubernetes:
-* Securing the components that are configurable which make up the cluster
-* Securing the components which run in the cluster
+* Securing the cluster components that are configurable
+* Securing the applications which run in the cluster
+### Components of the Cluster {#cluster-components}
-### Components _of_ the Cluster
-
-If you want to protect your cluster from accidental or malicious access, and adopt
+If you want to protect your cluster from accidental or malicious access and adopt
good information practices, read and follow the advice about
[securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/).
-### Components _in_ the Cluster (your application)
+### Components in the cluster (your application) {#cluster-applications}
+
Depending on the attack surface of your application, you may want to focus on specific
-aspects of security. For example, if you are running a service (Service A) that is critical
+aspects of security. For example: If you are running a service (Service A) that is critical
in a chain of other resources and a separate workload (Service B) which is
-vulnerable to a resource exhaustion attack, by not putting resource limits on
-Service B you run the risk of also compromising Service A. Below is a table of
-links of things to consider when securing workloads running in Kubernetes.
+vulnerable to a resource exhaustion attack then the risk of compromising Service A
+is high if you do not limit the resources of Service B. The following table lists
+areas of security concerns and recommendations for securing workloads running in Kubernetes:
Area of Concern for Workload Security | Recommendation |
------------------------------- | ------------ |
+------------------------------ | --------------------- |
RBAC Authorization (Access to the Kubernetes API) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/
Authentication | https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/
Application secrets management (and encrypting them in etcd at rest) | https://kubernetes.io/docs/concepts/configuration/secret/ https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
@@ -114,51 +110,45 @@ Quality of Service (and Cluster resource management) | https://kubernetes.io/doc
Network Policies | https://kubernetes.io/docs/concepts/services-networking/network-policies/
TLS For Kubernetes Ingress | https://kubernetes.io/docs/concepts/services-networking/ingress/#tls
-
-
## Container
-In order to run software in Kubernetes, it must be in a container. Because of this,
-there are certain security considerations that must be taken into account in order
-to benefit from the workload security primitives of Kubernetes. Container security
-is also outside the scope of this guide, but here is a table of general
-recommendations and links for further exploration of this topic.
+Container security is outside the scope of this guide. Here are general recommendations and
+links to explore this topic:
Area of Concern for Containers | Recommendation |
------------------------------- | ------------ |
-Container Vulnerability Scanning and OS Dependency Security | As part of an image build step or on a regular basis you should scan your containers for known vulnerabilities with a tool such as [CoreOS's Clair](https://github.com/coreos/clair/)
-Image Signing and Enforcement | Two other CNCF Projects (TUF and Notary) are useful tools for signing container images and maintaining a system of trust for the content of your containers. If you use Docker, it is built in to the Docker Engine as [Docker Content Trust](https://docs.docker.com/engine/security/trust/content_trust/). On the enforcement piece, [IBM's Portieris](https://github.com/IBM/portieris) project is a tool that runs as a Kubernetes Dynamic Admission Controller to ensure that images are properly signed via Notary before being admitted to the Cluster.
+------------------------------ | -------------- |
+Container Vulnerability Scanning and OS Dependency Security | As part of an image build step, you should scan your containers for known vulnerabilities.
+Image Signing and Enforcement | Sign container images to maintain a system of trust for the content of your containers.
Disallow privileged users | When constructing containers, consult your documentation for how to create users inside of the containers that have the least level of operating system privilege necessary in order to carry out the goal of the container.
## Code
-Finally moving down into the application code level, this is one of the primary attack
-surfaces over which you have the most control. This is also outside of the scope
-of Kubernetes but here are a few recommendations:
+Application code is one of the primary attack surfaces over which you have the most control.
+While securing application code is outside of the Kubernetes security topic, here
+are recommendations to protect application code:
-### General Code Security Guidance Table
+### Code security
+
+{{< table caption="Code security" >}}
Area of Concern for Code | Recommendation |
---------------------------------------------- | ------------ |
-Access over TLS only | If your code needs to communicate via TCP, ideally it would be performing a TLS handshake with the client ahead of time. With the exception of a few cases, the default behavior should be to encrypt everything in transit. Going one step further, even "behind the firewall" in our VPC's it's still a good idea to encrypt network traffic between services. This can be done through a process known as mutual or [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) which performs a two sided verification of communication between two certificate holding services. There are numerous tools that can be used to accomplish this in Kubernetes such as [Linkerd](https://linkerd.io/) and [Istio](https://istio.io/). |
+-------------------------| -------------- |
+Access over TLS only | If your code needs to communicate by TCP, perform a TLS handshake with the client ahead of time. With the exception of a few cases, encrypt everything in transit. Going one step further, it's a good idea to encrypt network traffic between services. This can be done through a process known as mutual or [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) which performs a two sided verification of communication between two certificate holding services. |
Limiting port ranges of communication | This recommendation may be a bit self-explanatory, but wherever possible you should only expose the ports on your service that are absolutely essential for communication or metric gathering. |
-3rd Party Dependency Security | Since our applications tend to have dependencies outside of our own codebases, it is a good practice to regularly scan the code's dependencies to ensure that they are still secure with no vulnerabilities currently filed against them. Each language has a tool for performing this check automatically. |
-Static Code Analysis | Most languages provide a way for a snippet of code to be analyzed for any potentially unsafe coding practices. Whenever possible you should perform checks using automated tooling that can scan codebases for common security errors. Some of the tools can be found here: https://owasp.org/www-community/Source_Code_Analysis_Tools |
-Dynamic probing attacks | There are a few automated tools that are able to be run against your service to try some of the well known attacks that commonly befall services. These include SQL injection, CSRF, and XSS. One of the most popular dynamic analysis tools is the OWASP Zed Attack proxy https://owasp.org/www-project-zap/ |
+3rd Party Dependency Security | It is a good practice to regularly scan your application's third party libraries for known security vulnerabilities. Each programming language has a tool for performing this check automatically. |
+Static Code Analysis | Most languages provide a way for a snippet of code to be analyzed for any potentially unsafe coding practices. Whenever possible you should perform checks using automated tooling that can scan codebases for common security errors. Some of the tools can be found at: https://owasp.org/www-community/Source_Code_Analysis_Tools |
+Dynamic probing attacks | There are a few automated tools that you can run against your service to try some of the well known service attacks. These include SQL injection, CSRF, and XSS. One of the most popular dynamic analysis tools is the [OWASP Zed Attack proxy](https://owasp.org/www-project-zap/) tool. |
+{{< /table >}}
-## Robust automation
+## {{% heading "whatsnext" %}}
-Most of the above mentioned suggestions can actually be automated in your code
-delivery pipeline as part of a series of checks in security. To learn about a
-more "Continuous Hacking" approach to software delivery, [this article](https://thenewstack.io/beyond-ci-cd-how-continuous-hacking-of-docker-containers-and-pipeline-driven-security-keeps-ygrene-secure/) provides more detail.
+Learn about related Kubernetes security topics:
-{{% /capture %}}
-{{% capture whatsnext %}}
-* Read about [network policies for Pods](/docs/concepts/services-networking/network-policies/)
-* Read about [securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/)
-* Read about [API access control](/docs/reference/access-authn-authz/controlling-access/)
-* Read about [data encryption in transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane
-* Read about [data encryption at rest](/docs/tasks/administer-cluster/encrypt-data/)
-* Read about [Secrets in Kubernetes](/docs/concepts/configuration/secret/)
-{{% /capture %}}
+* [Pod security standards](/docs/concepts/security/pod-security-standards/)
+* [Network policies for Pods](/docs/concepts/services-networking/network-policies/)
+* [Securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/)
+* [API access control](/docs/reference/access-authn-authz/controlling-access/)
+* [Data encryption in transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane
+* [Data encryption at rest](/docs/tasks/administer-cluster/encrypt-data/)
+* [Secrets in Kubernetes](/docs/concepts/configuration/secret/)
diff --git a/content/en/docs/concepts/security/pod-security-standards.md b/content/en/docs/concepts/security/pod-security-standards.md
index 1adf042c91..2afd6c7335 100644
--- a/content/en/docs/concepts/security/pod-security-standards.md
+++ b/content/en/docs/concepts/security/pod-security-standards.md
@@ -2,11 +2,11 @@
reviewers:
- tallclair
title: Pod Security Standards
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
Security settings for Pods are typically applied by using [security
contexts](/docs/tasks/configure-pod-container/security-context/). Security Contexts allow for the
@@ -21,9 +21,9 @@ However, numerous means of policy enforcement have arisen that augment or replac
PodSecurityPolicy. The intent of this page is to detail recommended Pod security profiles, decoupled
from any specific instantiation.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Policy Types
@@ -43,9 +43,9 @@ should range from highly restricted to highly flexible:
The Privileged policy is purposely-open, and entirely unrestricted. This type of policy is typically
aimed at system- and infrastructure-level workloads managed by privileged, trusted users.
-The privileged policy is defined by an absence of restrictions. For blacklist-oriented enforcement
+The privileged policy is defined by an absence of restrictions. For allow-by-default enforcement
mechanisms (such as gatekeeper), the privileged profile may be an absence of applied constraints
-rather than an instantiated policy. In contrast, for a whitelist oriented mechanism (such as Pod
+rather than an instantiated policy. In contrast, for a deny-by-default mechanism (such as Pod
Security Policy) the privileged policy should enable all controls (disable all restrictions).
### Baseline/Default
@@ -56,8 +56,8 @@ developers of non-critical applications. The following listed controls should be
enforced/disallowed:
-
Baseline policy specification
-
+
Baseline policy specification
+
Control
Policy
@@ -90,7 +90,7 @@ enforced/disallowed:
Restricted Fields:
spec.containers[*].securityContext.capabilities.add
spec.initContainers[*].securityContext.capabilities.add
- Allowed Values: empty (optionally whitelisted defaults)
+ Allowed Values: empty (or restricted to a known list)
@@ -105,20 +105,20 @@ enforced/disallowed:
Host Ports
- HostPorts should be disallowed, or at minimum restricted to a whitelist.
+ HostPorts should be disallowed, or at minimum restricted to a known list.
Restricted Fields:
spec.containers[*].ports[*].hostPort
spec.initContainers[*].ports[*].hostPort
- Allowed Values: 0, undefined, (whitelisted)
+ Allowed Values: 0, undefined (or restricted to a known list)
AppArmor (optional)
- On supported hosts, the `runtime/default` AppArmor profile is applied by default. The default policy should prevent overriding or disabling the policy, or restrict overrides to a whitelisted set of profiles.
+ On supported hosts, the 'runtime/default' AppArmor profile is applied by default. The default policy should prevent overriding or disabling the policy, or restrict overrides to an allowed set of profiles.
+ The default /proc masks are set up to reduce attack surface, and should be required.
+ Restricted Fields:
+ spec.containers[*].securityContext.procMount
+ spec.initContainers[*].securityContext.procMount
+ Allowed Values: undefined/nil, 'Default'
+
+
+
+
Sysctls
+
+ Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for an allowed "safe" subset.
+ A sysctl is considered safe if it is namespaced in the container or the Pod, and it is isolated from other Pods or processes on the same Node.
+ Restricted Fields:
+ spec.securityContext.sysctls
+ Allowed Values:
+ kernel.shm_rmid_forced
+ net.ipv4.ip_local_port_range
+ net.ipv4.tcp_syncookies
+ net.ipv4.ping_group_range
+ undefined/empty
+
+
@@ -143,7 +168,7 @@ well as lower-trust users.The following listed controls should be enforced/disal
-
Restricted policy specification
+
Restricted policy specification
Control
@@ -184,7 +209,7 @@ well as lower-trust users.The following listed controls should be enforced/disal
Privilege Escalation
- Privilege escalation to root should not be allowed.
+ Privilege escalation to root should not be allowed.
Restricted Fields:
spec.containers[*].securityContext.privileged
spec.initContainers[*].securityContext.privileged
@@ -194,7 +219,7 @@ well as lower-trust users.The following listed controls should be enforced/disal
Running as Non-root
- Containers must be required to run as non-root users.
+ Containers must be required to run as non-root users.
Restricted Fields:
spec.securityContext.runAsNonRoot
spec.containers[*].securityContext.runAsNonRoot
@@ -205,7 +230,7 @@ well as lower-trust users.The following listed controls should be enforced/disal
Non-root groups (optional)
- Containers should be forbidden from running with a root primary or supplementary GID.
+ Containers should be forbidden from running with a root primary or supplementary GID.
Restricted Fields:
spec.securityContext.runAsGroup
spec.securityContext.supplementalGroups[*]
@@ -224,12 +249,12 @@ well as lower-trust users.The following listed controls should be enforced/disal
Seccomp
- The runtime/default seccomp profile must be required, or allow additional whitelisted values.
+ The 'runtime/default' seccomp profile must be required, or allow specific additional profiles.
@@ -297,4 +322,4 @@ kernel. This allows for workloads requiring heightened permissions to still be i
Additionally, the protection of sandboxed workloads is highly dependent on the method of
sandboxing. As such, no single ‘recommended’ policy is recommended for all sandboxed workloads.
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/services-networking/_index.md b/content/en/docs/concepts/services-networking/_index.md
index eea2c65b33..2e7d91427e 100755
--- a/content/en/docs/concepts/services-networking/_index.md
+++ b/content/en/docs/concepts/services-networking/_index.md
@@ -1,5 +1,12 @@
---
title: "Services, Load Balancing, and Networking"
weight: 60
+description: >
+ Concepts and resources behind networking in Kubernetes.
---
+Kubernetes networking addresses four concerns:
+- Containers within a Pod use networking to communicate via loopback.
+- Cluster networking provides communication between different Pods.
+- The Service resource lets you expose an application running in Pods to be reachable from outside your cluster.
+- You can also use Services to publish services only for consumption inside your cluster.
diff --git a/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
index aeae348209..8eee03bf9b 100644
--- a/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
+++ b/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
@@ -3,29 +3,30 @@ reviewers:
- rickypai
- thockin
title: Adding entries to Pod /etc/hosts with HostAliases
-content_template: templates/concept
+content_type: concept
weight: 60
+min-kubernetes-server-version: 1.7
---
-{{< toc >}}
-{{% capture overview %}}
-Adding entries to a Pod's /etc/hosts file provides Pod-level override of hostname resolution when DNS and other options are not applicable. In 1.7, users can add these custom entries with the HostAliases field in PodSpec.
+
-Modification not using HostAliases is not suggested because the file is managed by Kubelet and can be overwritten on during Pod creation/restart.
-{{% /capture %}}
+Adding entries to a Pod's `/etc/hosts` file provides Pod-level override of hostname resolution when DNS and other options are not applicable. You can add these custom entries with the HostAliases field in PodSpec.
-{{% capture body %}}
+Modification not using HostAliases is not suggested because the file is managed by the kubelet and can be overwritten on during Pod creation/restart.
-## Default Hosts File Content
-Let's start an Nginx Pod which is assigned a Pod IP:
+
+
+## Default hosts file content
+
+Start an Nginx Pod which is assigned a Pod IP:
```shell
-kubectl run nginx --image nginx --generator=run-pod/v1
+kubectl run nginx --image nginx
```
-```shell
+```
pod/nginx created
```
@@ -35,7 +36,7 @@ Examine a Pod IP:
kubectl get pods --output=wide
```
-```shell
+```
NAME READY STATUS RESTARTS AGE IP NODE
nginx 1/1 Running 0 13s 10.200.0.4 worker0
```
@@ -46,7 +47,7 @@ The hosts file content would look like this:
kubectl exec nginx -- cat /etc/hosts
```
-```none
+```
# Kubernetes-managed hosts file.
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
@@ -60,43 +61,44 @@ fe00::2 ip6-allrouters
By default, the `hosts` file only includes IPv4 and IPv6 boilerplates like
`localhost` and its own hostname.
-## Adding Additional Entries with HostAliases
+## Adding additional entries with hostAliases
-In addition to the default boilerplate, we can add additional entries to the
-`hosts` file to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`,
-`bar.remote` to `10.1.2.3`, we can by adding HostAliases to the Pod under
+In addition to the default boilerplate, you can add additional entries to the
+`hosts` file.
+For example: to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`,
+`bar.remote` to `10.1.2.3`, you can configure HostAliases for a Pod under
`.spec.hostAliases`:
{{< codenew file="service/networking/hostaliases-pod.yaml" >}}
-This Pod can be started with the following commands:
+You can start a Pod with that configuration by running:
```shell
-kubectl apply -f hostaliases-pod.yaml
+kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml
```
-```shell
+```
pod/hostaliases-pod created
```
-Examine a Pod IP and status:
+Examine a Pod's details to see its IPv4 address and its status:
```shell
kubectl get pod --output=wide
```
-```shell
+```
NAME READY STATUS RESTARTS AGE IP NODE
hostaliases-pod 0/1 Completed 0 6s 10.200.0.5 worker0
```
-The `hosts` file content would look like this:
+The `hosts` file content looks like this:
```shell
-kubectl exec hostaliases-pod -- cat /etc/hosts
+kubectl logs hostaliases-pod
```
-```none
+```
# Kubernetes-managed hosts file.
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
@@ -111,19 +113,18 @@ fe00::2 ip6-allrouters
10.1.2.3 foo.remote bar.remote
```
-With the additional entries specified at the bottom.
+with the additional entries specified at the bottom.
-## Why Does Kubelet Manage the Hosts File?
+## Why does the kubelet manage the hosts file? {#why-does-kubelet-manage-the-hosts-file}
-Kubelet [manages](https://github.com/kubernetes/kubernetes/issues/14633) the
+The kubelet [manages](https://github.com/kubernetes/kubernetes/issues/14633) the
`hosts` file for each container of the Pod to prevent Docker from
[modifying](https://github.com/moby/moby/issues/17190) the file after the
containers have already been started.
-Because of the managed-nature of the file, any user-written content will be
-overwritten whenever the `hosts` file is remounted by Kubelet in the event of
-a container restart or a Pod reschedule. Thus, it is not suggested to modify
-the contents of the file.
-
-{{% /capture %}}
+{{< caution >}}
+Avoid making manual changes to the hosts file inside a container.
+If you make manual changes to the hosts file,
+those changes are lost when the container exits.
+{{< /caution >}}
diff --git a/content/en/docs/concepts/services-networking/connect-applications-service.md b/content/en/docs/concepts/services-networking/connect-applications-service.md
index 50c012ffc6..79c6053301 100644
--- a/content/en/docs/concepts/services-networking/connect-applications-service.md
+++ b/content/en/docs/concepts/services-networking/connect-applications-service.md
@@ -4,12 +4,12 @@ reviewers:
- lavalamp
- thockin
title: Connecting Applications with Services
-content_template: templates/concept
+content_type: concept
weight: 30
---
-{{% capture overview %}}
+
## The Kubernetes model for connecting containers
@@ -21,9 +21,9 @@ Coordinating port allocations across multiple developers or teams that provide c
This guide uses a simple nginx server to demonstrate proof of concept.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Exposing pods to the cluster
@@ -394,8 +394,8 @@ kubectl edit svc my-nginx
kubectl get svc my-nginx
```
```
-NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-my-nginx ClusterIP 10.0.162.149 162.222.184.144 80/TCP,81/TCP,82/TCP 21s
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+my-nginx LoadBalancer 10.0.162.149 xx.xxx.xxx.xxx 8080:30163/TCP 21s
```
```
curl https:// -k
@@ -418,12 +418,13 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
...
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [Using a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/)
* Learn more about [Connecting a Front End to a Back End Using a Service](/docs/tasks/access-application-cluster/connecting-frontend-backend/)
* Learn more about [Creating an External Load Balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/services-networking/dns-pod-service.md b/content/en/docs/concepts/services-networking/dns-pod-service.md
index 9cba184168..9d88019e3c 100644
--- a/content/en/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/en/docs/concepts/services-networking/dns-pod-service.md
@@ -3,14 +3,14 @@ reviewers:
- davidopp
- thockin
title: DNS for Services and Pods
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
This page provides an overview of DNS support by Kubernetes.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Introduction
@@ -66,6 +66,13 @@ of the form `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`
## Pods
+### A/AAAA records
+
+Any pods created by a Deployment or DaemonSet have the following
+DNS resolution available:
+
+`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.`
+
### Pod's hostname and subdomain fields
Currently when a pod is created, its hostname is the Pod's `metadata.name` value.
@@ -262,11 +269,11 @@ The availability of Pod DNS Config and DNS Policy "`None`" is shown as below.
| 1.10 | Beta (on by default)|
| 1.9 | Alpha |
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
For guidance on administering DNS configurations, check
[Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/)
-{{% /capture %}}
\ No newline at end of file
diff --git a/content/en/docs/concepts/services-networking/dual-stack.md b/content/en/docs/concepts/services-networking/dual-stack.md
index c753c17cc1..aa249566b9 100644
--- a/content/en/docs/concepts/services-networking/dual-stack.md
+++ b/content/en/docs/concepts/services-networking/dual-stack.md
@@ -9,11 +9,11 @@ feature:
description: >
Allocation of IPv4 and IPv6 addresses to Pods and Services
-content_template: templates/concept
+content_type: concept
weight: 70
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
@@ -21,9 +21,9 @@ weight: 70
If you enable IPv4/IPv6 dual-stack networking for your Kubernetes cluster, the cluster will support the simultaneous assignment of both IPv4 and IPv6 addresses.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Supported Features
@@ -103,10 +103,11 @@ The use of publicly routable and non-publicly routable IPv6 address blocks is ac
* Kubenet forces IPv4,IPv6 positional reporting of IPs (--cluster-cidr)
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/services-networking/endpoint-slices.md b/content/en/docs/concepts/services-networking/endpoint-slices.md
index 940374ae52..7c66ce0072 100644
--- a/content/en/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/en/docs/concepts/services-networking/endpoint-slices.md
@@ -2,12 +2,12 @@
reviewers:
- freehan
title: EndpointSlices
-content_template: templates/concept
+content_type: concept
weight: 15
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
@@ -15,9 +15,9 @@ _EndpointSlices_ provide a simple way to track network endpoints within a
Kubernetes cluster. They offer a more scalable and extensible alternative to
Endpoints.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Motivation
@@ -175,11 +175,12 @@ necessary soon anyway. Rolling updates of Deployments also provide a natural
repacking of EndpointSlices with all pods and their corresponding endpoints
getting replaced.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [Enabling EndpointSlices](/docs/tasks/administer-cluster/enabling-endpointslices)
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/services-networking/ingress-controllers.md b/content/en/docs/concepts/services-networking/ingress-controllers.md
index efeb327049..2c363ce7dc 100644
--- a/content/en/docs/concepts/services-networking/ingress-controllers.md
+++ b/content/en/docs/concepts/services-networking/ingress-controllers.md
@@ -1,11 +1,11 @@
---
title: Ingress Controllers
reviewers:
-content_template: templates/concept
+content_type: concept
weight: 40
---
-{{% capture overview %}}
+
In order for the Ingress resource to work, the cluster must have an ingress controller running.
@@ -16,9 +16,9 @@ that best fits your cluster.
Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.io/ingress-gce/README.md) and
[nginx](https://git.k8s.io/ingress-nginx/README.md) controllers.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Additional controllers
@@ -64,11 +64,12 @@ controllers operate slightly differently.
Make sure you review your ingress controller's documentation to understand the caveats of choosing it.
{{< /note >}}
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [Ingress](/docs/concepts/services-networking/ingress/).
* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube).
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md
index 062dc14f66..430ee3c72d 100644
--- a/content/en/docs/concepts/services-networking/ingress.md
+++ b/content/en/docs/concepts/services-networking/ingress.md
@@ -2,16 +2,16 @@
reviewers:
- bprashanth
title: Ingress
-content_template: templates/concept
+content_type: concept
weight: 40
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.1" state="beta" >}}
{{< glossary_definition term_id="ingress" length="all" >}}
-{{% /capture %}}
-{{% capture body %}}
+
+
## Terminology
@@ -542,10 +542,11 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
* Use [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
* Use [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn about the [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)
* Learn about [Ingress Controllers](/docs/concepts/services-networking/ingress-controllers/)
* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/services-networking/network-policies.md b/content/en/docs/concepts/services-networking/network-policies.md
index 795969757d..4a01707ab2 100644
--- a/content/en/docs/concepts/services-networking/network-policies.md
+++ b/content/en/docs/concepts/services-networking/network-policies.md
@@ -4,20 +4,20 @@ reviewers:
- caseydavenport
- danwinship
title: Network Policies
-content_template: templates/concept
+content_type: concept
weight: 50
---
{{< toc >}}
-{{% capture overview %}}
+
A network policy is a specification of how groups of {{< glossary_tooltip text="pods" term_id="pod">}} are allowed to communicate with each other and other network endpoints.
NetworkPolicy resources use {{< glossary_tooltip text="labels" term_id="label">}} to select pods and define rules which specify what traffic is allowed to the selected pods.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Prerequisites
Network policies are implemented by the [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). To use network policies, you must be using a networking solution which supports NetworkPolicy. Creating a NetworkPolicy resource without a controller that implements it will have no effect.
@@ -89,9 +89,9 @@ __podSelector__: Each NetworkPolicy includes a `podSelector` which selects the g
__policyTypes__: Each NetworkPolicy includes a `policyTypes` list which may include either `Ingress`, `Egress`, or both. The `policyTypes` field indicates whether or not the given policy applies to ingress traffic to selected pod, egress traffic from selected pods, or both. If no `policyTypes` are specified on a NetworkPolicy then by default `Ingress` will always be set and `Egress` will be set if the NetworkPolicy has any egress rules.
-__ingress__: Each NetworkPolicy may include a list of whitelist `ingress` rules. Each rule allows traffic which matches both the `from` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port, from one of three sources, the first specified via an `ipBlock`, the second via a `namespaceSelector` and the third via a `podSelector`.
+__ingress__: Each NetworkPolicy may include a list of allowed `ingress` rules. Each rule allows traffic which matches both the `from` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port, from one of three sources, the first specified via an `ipBlock`, the second via a `namespaceSelector` and the third via a `podSelector`.
-__egress__: Each NetworkPolicy may include a list of whitelist `egress` rules. Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`.
+__egress__: Each NetworkPolicy may include a list of allowed `egress` rules. Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`.
So, the example NetworkPolicy:
@@ -215,12 +215,13 @@ You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin tha
{{< /note >}}
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
- See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)
walkthrough for further examples.
- See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource.
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/services-networking/service-topology.md b/content/en/docs/concepts/services-networking/service-topology.md
index 7b3c58a84a..d36b76f55f 100644
--- a/content/en/docs/concepts/services-networking/service-topology.md
+++ b/content/en/docs/concepts/services-networking/service-topology.md
@@ -8,12 +8,12 @@ feature:
description: >
Routing of service traffic based upon cluster topology.
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
@@ -22,9 +22,9 @@ topology of the cluster. For example, a service can specify that traffic be
preferentially routed to endpoints that are on the same Node as the client, or
in the same availability zone.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Introduction
@@ -192,11 +192,12 @@ spec:
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Read about [enabling Service Topology](/docs/tasks/administer-cluster/enabling-service-topology)
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md
index e97d80db21..2ae49ac270 100644
--- a/content/en/docs/concepts/services-networking/service.md
+++ b/content/en/docs/concepts/services-networking/service.md
@@ -7,12 +7,12 @@ feature:
description: >
No need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods, and can load-balance across them.
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
{{< glossary_definition term_id="service" length="short" >}}
@@ -20,9 +20,9 @@ With Kubernetes you don't need to modify your application to use an unfamiliar s
Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods,
and can load-balance across them.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Motivation
@@ -1227,12 +1227,13 @@ SCTP is not supported on Windows based nodes.
The kube-proxy does not support the management of SCTP associations when it is in userspace mode.
{{< /warning >}}
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
* Read about [Ingress](/docs/concepts/services-networking/ingress/)
* Read about [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/storage/_index.md b/content/en/docs/concepts/storage/_index.md
index 7e0dd19b12..a6aeac7734 100755
--- a/content/en/docs/concepts/storage/_index.md
+++ b/content/en/docs/concepts/storage/_index.md
@@ -1,5 +1,7 @@
---
title: "Storage"
weight: 70
+description: >
+ Ways to provide both long-term and temporary storage to Pods in your cluster.
---
diff --git a/content/en/docs/concepts/storage/dynamic-provisioning.md b/content/en/docs/concepts/storage/dynamic-provisioning.md
index 77885981f7..dc82e5c2c8 100644
--- a/content/en/docs/concepts/storage/dynamic-provisioning.md
+++ b/content/en/docs/concepts/storage/dynamic-provisioning.md
@@ -5,11 +5,11 @@ reviewers:
- thockin
- msau42
title: Dynamic Volume Provisioning
-content_template: templates/concept
+content_type: concept
weight: 40
---
-{{% capture overview %}}
+
Dynamic volume provisioning allows storage volumes to be created on-demand.
Without dynamic provisioning, cluster administrators have to manually make
@@ -19,10 +19,10 @@ to represent them in Kubernetes. The dynamic provisioning feature eliminates
the need for cluster administrators to pre-provision storage. Instead, it
automatically provisions storage when it is requested by users.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Background
@@ -133,4 +133,4 @@ Zones in a Region. Single-Zone storage backends should be provisioned in the Zon
Pods are scheduled. This can be accomplished by setting the [Volume Binding
Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode).
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md
index c365e02171..2c3140de83 100644
--- a/content/en/docs/concepts/storage/persistent-volumes.md
+++ b/content/en/docs/concepts/storage/persistent-volumes.md
@@ -11,18 +11,18 @@ feature:
description: >
Automatically mount the storage system of your choice, whether from local storage, a public cloud provider such as GCP or AWS, or a network storage system such as NFS, iSCSI, Gluster, Ceph, Cinder, or Flocker.
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
This document describes the current state of _persistent volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Introduction
@@ -746,8 +746,9 @@ and need persistent storage, it is recommended that you use the following patter
dynamic storage support (in which case the user should create a matching PV)
or the cluster has no storage system (in which case the user cannot deploy
config requiring PVCs).
-{{% /capture %}}
- {{% capture whatsnext %}}
+
+ ## {{% heading "whatsnext" %}}
+
* Learn more about [Creating a PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume).
* Learn more about [Creating a PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim).
@@ -759,4 +760,3 @@ and need persistent storage, it is recommended that you use the following patter
* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core)
* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)
-{{% /capture %}}
\ No newline at end of file
diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md
index 1ea7c236d9..a16baf46b4 100644
--- a/content/en/docs/concepts/storage/storage-classes.md
+++ b/content/en/docs/concepts/storage/storage-classes.md
@@ -5,19 +5,19 @@ reviewers:
- thockin
- msau42
title: Storage Classes
-content_template: templates/concept
+content_type: concept
weight: 30
---
-{{% capture overview %}}
+
This document describes the concept of a StorageClass in Kubernetes. Familiarity
with [volumes](/docs/concepts/storage/volumes/) and
[persistent volumes](/docs/concepts/storage/persistent-volumes) is suggested.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Introduction
@@ -41,7 +41,7 @@ be updated once they are created.
Administrators can specify a default StorageClass just for PVCs that don't
request any particular class to bind to: see the
-[PersistentVolumeClaim section](/docs/concepts/storage/persistent-volumes/#class-1)
+[PersistentVolumeClaim section](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
for details.
```yaml
@@ -821,4 +821,4 @@ Delaying volume binding allows the scheduler to consider all of a Pod's
scheduling constraints when choosing an appropriate PersistentVolume for a
PersistentVolumeClaim.
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/storage/storage-limits.md b/content/en/docs/concepts/storage/storage-limits.md
index 295ed467a2..fb6cffed9c 100644
--- a/content/en/docs/concepts/storage/storage-limits.md
+++ b/content/en/docs/concepts/storage/storage-limits.md
@@ -5,10 +5,10 @@ reviewers:
- thockin
- msau42
title: Node-specific Volume Limits
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
This page describes the maximum number of volumes that can be attached
to a Node for various cloud providers.
@@ -18,9 +18,9 @@ how many volumes can be attached to a Node. It is important for Kubernetes to
respect those limits. Otherwise, Pods scheduled on a Node could get stuck
waiting for volumes to attach.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Kubernetes default limits
@@ -78,4 +78,4 @@ Refer to the [CSI specifications](https://github.com/container-storage-interface
* For volumes managed by in-tree plugins that have been migrated to a CSI driver, the maximum number of volumes will be the one reported by the CSI driver.
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/storage/volume-pvc-datasource.md b/content/en/docs/concepts/storage/volume-pvc-datasource.md
index 2f29fb9bb9..ac8d16041d 100644
--- a/content/en/docs/concepts/storage/volume-pvc-datasource.md
+++ b/content/en/docs/concepts/storage/volume-pvc-datasource.md
@@ -5,18 +5,18 @@ reviewers:
- thockin
- msau42
title: CSI Volume Cloning
-content_template: templates/concept
+content_type: concept
weight: 30
---
-{{% capture overview %}}
+
This document describes the concept of cloning existing CSI Volumes in Kubernetes. Familiarity with [Volumes](/docs/concepts/storage/volumes) is suggested.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Introduction
@@ -70,4 +70,4 @@ The result is a new PVC with the name `clone-of-pvc-1` that has the exact same c
Upon availability of the new PVC, the cloned PVC is consumed the same as other PVC. It's also expected at this point that the newly created PVC is an independent object. It can be consumed, cloned, snapshotted, or deleted independently and without consideration for it's original dataSource PVC. This also implies that the source is not linked in any way to the newly created clone, it may also be modified or deleted without affecting the newly created clone.
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/storage/volume-snapshot-classes.md b/content/en/docs/concepts/storage/volume-snapshot-classes.md
index dcb9516519..f3b7025270 100644
--- a/content/en/docs/concepts/storage/volume-snapshot-classes.md
+++ b/content/en/docs/concepts/storage/volume-snapshot-classes.md
@@ -7,47 +7,60 @@ reviewers:
- xing-yang
- yuxiangqian
title: Volume Snapshot Classes
-content_template: templates/concept
+content_type: concept
weight: 30
---
-{{% capture overview %}}
+
-This document describes the concept of `VolumeSnapshotClass` in Kubernetes. Familiarity
+This document describes the concept of VolumeSnapshotClass in Kubernetes. Familiarity
with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and
[storage classes](/docs/concepts/storage/storage-classes) is suggested.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Introduction
-Just like `StorageClass` provides a way for administrators to describe the "classes"
-of storage they offer when provisioning a volume, `VolumeSnapshotClass` provides a
+Just like StorageClass provides a way for administrators to describe the "classes"
+of storage they offer when provisioning a volume, VolumeSnapshotClass provides a
way to describe the "classes" of storage when provisioning a volume snapshot.
## The VolumeSnapshotClass Resource
-Each `VolumeSnapshotClass` contains the fields `driver`, `deletionPolicy`, and `parameters`,
-which are used when a `VolumeSnapshot` belonging to the class needs to be
+Each VolumeSnapshotClass contains the fields `driver`, `deletionPolicy`, and `parameters`,
+which are used when a VolumeSnapshot belonging to the class needs to be
dynamically provisioned.
-The name of a `VolumeSnapshotClass` object is significant, and is how users can
+The name of a VolumeSnapshotClass object is significant, and is how users can
request a particular class. Administrators set the name and other parameters
-of a class when first creating `VolumeSnapshotClass` objects, and the objects cannot
+of a class when first creating VolumeSnapshotClass objects, and the objects cannot
be updated once they are created.
-Administrators can specify a default `VolumeSnapshotClass` just for VolumeSnapshots
-that don't request any particular class to bind to.
-
```yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshotClass
metadata:
name: csi-hostpath-snapclass
-driver: hostpath.csi.k8s.io
+driver: hostpath.csi.k8s.io
+deletionPolicy: Delete
+parameters:
+```
+
+Administrators can specify a default VolumeSnapshotClass for VolumeSnapshots
+that don't request any particular class to bind to by adding the
+`snapshot.storage.kubernetes.io/is-default-class: "true"` annotation:
+
+```yaml
+apiVersion: snapshot.storage.k8s.io/v1beta1
+kind: VolumeSnapshotClass
+metadata:
+ name: csi-hostpath-snapclass
+ annotations:
+ snapshot.storage.kubernetes.io/is-default-class: "true"
+driver: hostpath.csi.k8s.io
deletionPolicy: Delete
parameters:
```
@@ -59,9 +72,9 @@ used for provisioning VolumeSnapshots. This field must be specified.
### DeletionPolicy
-Volume snapshot classes have a deletionPolicy. It enables you to configure what happens to a `VolumeSnapshotContent` when the `VolumeSnapshot` object it is bound to is to be deleted. The deletionPolicy of a volume snapshot can either be `Retain` or `Delete`. This field must be specified.
+Volume snapshot classes have a deletionPolicy. It enables you to configure what happens to a VolumeSnapshotContent when the VolumeSnapshot object it is bound to is to be deleted. The deletionPolicy of a volume snapshot can either be `Retain` or `Delete`. This field must be specified.
-If the deletionPolicy is `Delete`, then the underlying storage snapshot will be deleted along with the `VolumeSnapshotContent` object. If the deletionPolicy is `Retain`, then both the underlying snapshot and `VolumeSnapshotContent` remain.
+If the deletionPolicy is `Delete`, then the underlying storage snapshot will be deleted along with the VolumeSnapshotContent object. If the deletionPolicy is `Retain`, then both the underlying snapshot and VolumeSnapshotContent remain.
## Parameters
@@ -69,4 +82,4 @@ Volume snapshot classes have parameters that describe volume snapshots belonging
the volume snapshot class. Different parameters may be accepted depending on the
`driver`.
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/storage/volume-snapshots.md b/content/en/docs/concepts/storage/volume-snapshots.md
index 0ad66e75ae..a6cc122086 100644
--- a/content/en/docs/concepts/storage/volume-snapshots.md
+++ b/content/en/docs/concepts/storage/volume-snapshots.md
@@ -7,19 +7,19 @@ reviewers:
- xing-yang
- yuxiangqian
title: Volume Snapshots
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/).
-{{% /capture %}}
-{{% capture body %}}
+
+
## Introduction
@@ -154,4 +154,4 @@ the *dataSource* field in the `PersistentVolumeClaim` object.
For more details, see
[Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md
index cacab214b6..c3f43f0fa5 100644
--- a/content/en/docs/concepts/storage/volumes.md
+++ b/content/en/docs/concepts/storage/volumes.md
@@ -5,11 +5,11 @@ reviewers:
- thockin
- msau42
title: Volumes
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
On-disk files in a Container are ephemeral, which presents some problems for
non-trivial applications when running in Containers. First, when a Container
@@ -20,15 +20,15 @@ Kubernetes `Volume` abstraction solves both of these problems.
Familiarity with [Pods](/docs/user-guide/pods) is suggested.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Background
Docker also has a concept of
-[volumes](https://docs.docker.com/engine/admin/volumes/), though it is
+[volumes](https://docs.docker.com/storage/), though it is
somewhat looser and less managed. In Docker, a volume is simply a directory on
disk or in another Container. Lifetimes are not managed and until very
recently there were only local-disk-backed volumes. Docker now provides volume
@@ -456,15 +456,13 @@ spec:
```
#### Regional Persistent Disks
-{{< feature-state for_k8s_version="v1.10" state="beta" >}}
-
The [Regional Persistent Disks](https://cloud.google.com/compute/docs/disks/#repds) feature allows the creation of Persistent Disks that are available in two zones within the same region. In order to use this feature, the volume must be provisioned as a PersistentVolume; referencing the volume directly from a pod is not supported.
#### Manually provisioning a Regional PD PersistentVolume
Dynamic provisioning is possible using a [StorageClass for GCE PD](/docs/concepts/storage/storage-classes/#gce).
Before creating a PersistentVolume, you must create the PD:
```shell
-gcloud beta compute disks create --size=500GB my-data-disk
+gcloud compute disks create --size=500GB my-data-disk
--region us-central1
--replica-zones us-central1-a,us-central1-b
```
@@ -475,8 +473,6 @@ apiVersion: v1
kind: PersistentVolume
metadata:
name: test-volume
- labels:
- failure-domain.beta.kubernetes.io/zone: us-central1-a__us-central1-b
spec:
capacity:
storage: 400Gi
@@ -485,6 +481,15 @@ spec:
gcePersistentDisk:
pdName: my-data-disk
fsType: ext4
+ nodeAffinity:
+ required:
+ nodeSelectorTerms:
+ - matchExpressions:
+ - key: failure-domain.beta.kubernetes.io/zone
+ operator: In
+ values:
+ - us-central1-a
+ - us-central1-b
```
#### CSI Migration
@@ -1476,6 +1481,7 @@ sudo systemctl restart docker
-{{% capture whatsnext %}}
+## {{% heading "whatsnext" %}}
+
* Follow an example of [deploying WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/).
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/workloads/_index.md b/content/en/docs/concepts/workloads/_index.md
index ca394ebd00..1aac095cb5 100644
--- a/content/en/docs/concepts/workloads/_index.md
+++ b/content/en/docs/concepts/workloads/_index.md
@@ -1,5 +1,7 @@
---
title: "Workloads"
weight: 50
+description: >
+ Understand Pods, the smallest deployable compute object in Kubernetes, and the higher-level abstractions that help you to run them.
---
diff --git a/content/en/docs/concepts/workloads/controllers/cron-jobs.md b/content/en/docs/concepts/workloads/controllers/cron-jobs.md
index 233e0ca661..af12bcba25 100644
--- a/content/en/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/content/en/docs/concepts/workloads/controllers/cron-jobs.md
@@ -4,11 +4,11 @@ reviewers:
- soltysh
- janetkuo
title: CronJob
-content_template: templates/concept
+content_type: concept
weight: 80
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.8" state="beta" >}}
@@ -33,8 +33,8 @@ append 11 characters to the job name provided and there is a constraint that the
maximum length of a Job name is no more than 63 characters.
-{{% /capture %}}
-{{% capture body %}}
+
+
## CronJob
@@ -82,12 +82,13 @@ be down for the same period as the previous example (`08:29:00` to `10:21:00`,)
The CronJob is only responsible for creating Jobs that match its schedule, and
the Job in turn is responsible for the management of the Pods it represents.
-{{% /capture %}}
-{{% capture whatsnext %}}
-[Cron expression format](https://pkg.go.dev/github.com/robfig/cron?tab=doc#hdr-CRON_Expression_Format)
+
+## {{% heading "whatsnext" %}}
+
+[Cron expression format](https://en.wikipedia.org/wiki/Cron)
documents the format of CronJob `schedule` fields.
For instructions on creating and working with cron jobs, and for an example of CronJob
manifest, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs).
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md
index a5d0df82ce..7f1b5c4630 100644
--- a/content/en/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/en/docs/concepts/workloads/controllers/daemonset.md
@@ -6,11 +6,11 @@ reviewers:
- janetkuo
- kow3ns
title: DaemonSet
-content_template: templates/concept
+content_type: concept
weight: 50
---
-{{% capture overview %}}
+
A _DaemonSet_ ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the
cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage
@@ -18,18 +18,18 @@ collected. Deleting a DaemonSet will clean up the Pods it created.
Some typical uses of a DaemonSet are:
-- running a cluster storage daemon, such as `glusterd`, `ceph`, on each node.
-- running a logs collection daemon on every node, such as `fluentd` or `filebeat`.
-- running a node monitoring daemon on every node, such as [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond`, [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) or [Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html).
+- running a cluster storage daemon on every node
+- running a logs collection daemon on every node
+- running a node monitoring daemon on every node
In a simple case, one DaemonSet, covering all nodes, would be used for each type of daemon.
A more complex setup might use multiple DaemonSets for a single type of daemon, but with
different flags and/or different memory and cpu requests for different hardware types.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Writing a DaemonSet Spec
@@ -95,7 +95,7 @@ another DaemonSet, or via another workload resource such as ReplicaSet. Otherwi
Kubernetes will not stop you from doing this. One case where you might want to do this is manually
create a Pod with a different value on a node for testing.
-### Running Pods on Only Some Nodes
+### Running Pods on select Nodes
If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will
create Pods on nodes which match that [node
@@ -103,7 +103,7 @@ selector](/docs/concepts/scheduling-eviction/assign-pod-node/). Likewise if you
then DaemonSet controller will create Pods on nodes which match that [node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/).
If you do not specify either, then the DaemonSet controller will create Pods on all nodes.
-## How Daemon Pods are Scheduled
+## How Daemon Pods are scheduled
### Scheduled by default scheduler
@@ -144,7 +144,6 @@ In addition, `node.kubernetes.io/unschedulable:NoSchedule` toleration is added
automatically to DaemonSet Pods. The default scheduler ignores
`unschedulable` Nodes when scheduling DaemonSet Pods.
-
### Taints and Tolerations
Although Daemon Pods respect
@@ -152,17 +151,14 @@ Although Daemon Pods respect
the following tolerations are added to DaemonSet Pods automatically according to
the related features.
-| Toleration Key | Effect | Version | Description |
-| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
-| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | DaemonSet pods will not be evicted when there are node problems such as a network partition. |
-| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | DaemonSet pods will not be evicted when there are node problems such as a network partition. |
-| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | |
-| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | |
-| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | DaemonSet pods tolerate unschedulable attributes by default scheduler. |
-| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | DaemonSet pods, who uses host network, tolerate network-unavailable attributes by default scheduler. |
-
-
-
+| Toleration Key | Effect | Version | Description |
+| ---------------------------------------- | ---------- | ------- | ----------- |
+| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | DaemonSet pods will not be evicted when there are node problems such as a network partition. |
+| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | DaemonSet pods will not be evicted when there are node problems such as a network partition. |
+| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | |
+| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | |
+| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | DaemonSet pods tolerate unschedulable attributes by default scheduler. |
+| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | DaemonSet pods, who uses host network, tolerate network-unavailable attributes by default scheduler. |
## Communicating with Daemon Pods
@@ -195,7 +191,7 @@ You can [perform a rolling update](/docs/tasks/manage-daemon/update-daemon-set/)
## Alternatives to DaemonSet
-### Init Scripts
+### Init scripts
It is certainly possible to run daemon processes by directly starting them on a node (e.g. using
`init`, `upstartd`, or `systemd`). This is perfectly fine. However, there are several advantages to
@@ -233,4 +229,4 @@ number of replicas and rolling out updates are more important than controlling e
the Pod runs on. Use a DaemonSet when it is important that a copy of a Pod always run on
all or certain hosts, and when it needs to start before other Pods.
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md
index 2610380641..6b117cdc44 100644
--- a/content/en/docs/concepts/workloads/controllers/deployment.md
+++ b/content/en/docs/concepts/workloads/controllers/deployment.md
@@ -7,11 +7,11 @@ feature:
description: >
Kubernetes progressively rolls out changes to your application or its configuration, while monitoring application health to ensure it doesn't kill all your instances at the same time. If something goes wrong, Kubernetes will rollback the change for you. Take advantage of a growing ecosystem of deployment solutions.
-content_template: templates/concept
+content_type: concept
weight: 30
---
-{{% capture overview %}}
+
A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and
[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/).
@@ -22,10 +22,10 @@ You describe a _desired state_ in a Deployment, and the Deployment {{< glossary_
Do not manage ReplicaSets owned by a Deployment. Consider opening an issue in the main Kubernetes repository if your use case is not covered below.
{{< /note >}}
-{{% /capture %}}
-{{% capture body %}}
+
+
## Use Case
@@ -861,7 +861,12 @@ The output is similar to this:
```
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment.apps/nginx-deployment successfully rolled out
-$ echo $?
+```
+and the exit status from `kubectl rollout` is 0 (success):
+```shell
+echo $?
+```
+```
0
```
@@ -1003,7 +1008,12 @@ The output is similar to this:
```
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
error: deployment "nginx" exceeded its progress deadline
-$ echo $?
+```
+and the exit status from `kubectl rollout` is 1 (indicating an error):
+```shell
+echo $?
+```
+```
1
```
@@ -1166,4 +1176,4 @@ a paused Deployment and one that is not paused, is that any changes into the Pod
Deployment will not trigger new rollouts as long as it is paused. A Deployment is not paused by default when
it is created.
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/workloads/controllers/garbage-collection.md b/content/en/docs/concepts/workloads/controllers/garbage-collection.md
index 45303b66e8..a20951a35e 100644
--- a/content/en/docs/concepts/workloads/controllers/garbage-collection.md
+++ b/content/en/docs/concepts/workloads/controllers/garbage-collection.md
@@ -1,18 +1,16 @@
---
title: Garbage Collection
-content_template: templates/concept
-weight: 60
+content_type: concept
+weight: 70
---
-{{% capture overview %}}
+
The role of the Kubernetes garbage collector is to delete certain objects
that once had an owner, but no longer have an owner.
-{{% /capture %}}
-
-{{% capture body %}}
+
## Owners and dependents
@@ -168,16 +166,11 @@ See [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment
Tracked at [#26120](https://github.com/kubernetes/kubernetes/issues/26120)
-{{% /capture %}}
-{{% capture whatsnext %}}
+## {{% heading "whatsnext" %}}
+
[Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
[Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
-
-{{% /capture %}}
-
-
-
diff --git a/content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/en/docs/concepts/workloads/controllers/job.md
similarity index 92%
rename from content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md
rename to content/en/docs/concepts/workloads/controllers/job.md
index 8c03d14268..a55759c300 100644
--- a/content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md
+++ b/content/en/docs/concepts/workloads/controllers/job.md
@@ -2,16 +2,16 @@
reviewers:
- erictune
- soltysh
-title: Jobs - Run to Completion
-content_template: templates/concept
+title: Jobs
+content_type: concept
feature:
title: Batch execution
description: >
In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired.
-weight: 70
+weight: 60
---
-{{% capture overview %}}
+
A Job creates one or more Pods and ensures that a specified number of them successfully terminate.
As pods successfully complete, the Job tracks the successful completions. When a specified number
@@ -24,10 +24,10 @@ due to a node hardware failure or a node reboot).
You can also use a Job to run multiple Pods in parallel.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Running an example Job
@@ -111,7 +111,7 @@ The output is similar to this:
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
```
-## Writing a Job Spec
+## Writing a Job spec
As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `metadata` fields.
Its name must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
@@ -129,30 +129,30 @@ labels (see [pod selector](#pod-selector)) and an appropriate restart policy.
Only a [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Never` or `OnFailure` is allowed.
-### Pod Selector
+### Pod selector
The `.spec.selector` field is optional. In almost all cases you should not specify it.
See section [specifying your own pod selector](#specifying-your-own-pod-selector).
-### Parallel Jobs
+### Parallel execution for Jobs {#parallel-jobs}
There are three main types of task suitable to run as a Job:
1. Non-parallel Jobs
- - normally, only one Pod is started, unless the Pod fails.
- - the Job is complete as soon as its Pod terminates successfully.
+ - normally, only one Pod is started, unless the Pod fails.
+ - the Job is complete as soon as its Pod terminates successfully.
1. Parallel Jobs with a *fixed completion count*:
- - specify a non-zero positive value for `.spec.completions`.
- - the Job represents the overall task, and is complete when there is one successful Pod for each value in the range 1 to `.spec.completions`.
- - **not implemented yet:** Each Pod is passed a different index in the range 1 to `.spec.completions`.
+ - specify a non-zero positive value for `.spec.completions`.
+ - the Job represents the overall task, and is complete when there is one successful Pod for each value in the range 1 to `.spec.completions`.
+ - **not implemented yet:** Each Pod is passed a different index in the range 1 to `.spec.completions`.
1. Parallel Jobs with a *work queue*:
- - do not specify `.spec.completions`, default to `.spec.parallelism`.
- - the Pods must coordinate amongst themselves or an external service to determine what each should work on. For example, a Pod might fetch a batch of up to N items from the work queue.
- - each Pod is independently capable of determining whether or not all its peers are done, and thus that the entire Job is done.
- - when _any_ Pod from the Job terminates with success, no new Pods are created.
- - once at least one Pod has terminated with success and all Pods are terminated, then the Job is completed with success.
- - once any Pod has exited with success, no other Pod should still be doing any work for this task or writing any output. They should all be in the process of exiting.
+ - do not specify `.spec.completions`, default to `.spec.parallelism`.
+ - the Pods must coordinate amongst themselves or an external service to determine what each should work on. For example, a Pod might fetch a batch of up to N items from the work queue.
+ - each Pod is independently capable of determining whether or not all its peers are done, and thus that the entire Job is done.
+ - when _any_ Pod from the Job terminates with success, no new Pods are created.
+ - once at least one Pod has terminated with success and all Pods are terminated, then the Job is completed with success.
+ - once any Pod has exited with success, no other Pod should still be doing any work for this task or writing any output. They should all be in the process of exiting.
For a _non-parallel_ Job, you can leave both `.spec.completions` and `.spec.parallelism` unset. When both are
unset, both are defaulted to 1.
@@ -166,7 +166,7 @@ a non-negative integer.
For more information about how to make use of the different types of job, see the [job patterns](#job-patterns) section.
-#### Controlling Parallelism
+#### Controlling parallelism
The requested parallelism (`.spec.parallelism`) can be set to any non-negative value.
If it is unspecified, it defaults to 1.
@@ -184,7 +184,7 @@ parallelism, for a variety of reasons:
- The Job controller may throttle new Pod creation due to excessive previous pod failures in the same Job.
- When a Pod is gracefully shut down, it takes time to stop.
-## Handling Pod and Container Failures
+## Handling Pod and container failures
A container in a Pod may fail for a number of reasons, such as because the process in it exited with
a non-zero exit code, or the container was killed for exceeding a memory limit, etc. If this
@@ -218,9 +218,6 @@ exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The
back-off count is reset if no new failed Pods appear before the Job's next
status check.
-{{< note >}}
-Issue [#54870](https://github.com/kubernetes/kubernetes/issues/54870) still exists for versions of Kubernetes prior to version 1.12
-{{< /note >}}
{{< note >}}
If your job has `restartPolicy = "OnFailure"`, keep in mind that your container running the Job
will be terminated once the job backoff limit has been reached. This can make debugging the Job's executable more difficult. We suggest setting
@@ -228,7 +225,7 @@ will be terminated once the job backoff limit has been reached. This can make de
from failed Jobs is not lost inadvertently.
{{< /note >}}
-## Job Termination and Cleanup
+## Job termination and cleanup
When a Job completes, no more Pods are created, but the Pods are not deleted either. Keeping them around
allows you to still view the logs of completed pods to check for errors, warnings, or other diagnostic output.
@@ -269,7 +266,7 @@ Note that both the Job spec and the [Pod template spec](/docs/concepts/workloads
Keep in mind that the `restartPolicy` applies to the Pod, and not to the Job itself: there is no automatic Job restart once the Job status is `type: Failed`.
That is, the Job termination mechanisms activated with `.spec.activeDeadlineSeconds` and `.spec.backoffLimit` result in a permanent Job failure that requires manual intervention to resolve.
-## Clean Up Finished Jobs Automatically
+## Clean up finished jobs automatically
Finished Jobs are usually no longer needed in the system. Keeping them around in
the system will put pressure on the API server. If the Jobs are managed directly
@@ -277,7 +274,7 @@ by a higher level controller, such as
[CronJobs](/docs/concepts/workloads/controllers/cron-jobs/), the Jobs can be
cleaned up by CronJobs based on the specified capacity-based cleanup policy.
-### TTL Mechanism for Finished Jobs
+### TTL mechanism for finished Jobs
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
@@ -322,7 +319,7 @@ more information, see the documentation for
[TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) for
finished resources.
-## Job Patterns
+## Job patterns
The Job object can be used to support reliable parallel execution of Pods. The Job object is not
designed to support closely-communicating parallel processes, as commonly found in scientific
@@ -374,9 +371,9 @@ Here, `W` is the number of work items.
| Single Job with Static Work Assignment | W | any |
-## Advanced Usage
+## Advanced usage
-### Specifying your own pod selector
+### Specifying your own Pod selector
Normally, when you create a Job object, you do not specify `.spec.selector`.
The system defaulting logic adds this field when the Job is created.
@@ -461,7 +458,7 @@ As discussed in [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), `
for pods with `RestartPolicy` equal to `OnFailure` or `Never`.
(Note: If `RestartPolicy` is not set, the default value is `Always`.)
-### Single Job starts Controller Pod
+### Single Job starts controller Pod
Another pattern is for a single Job to create a Pod which then creates other Pods, acting as a sort
of custom controller for those Pods. This allows the most flexibility, but may be somewhat
@@ -478,4 +475,3 @@ object, but maintains complete control over what Pods are created and how work i
You can use a [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) to create a Job that will run at specified times/dates, similar to the Unix tool `cron`.
-{{% /capture %}}
diff --git a/content/en/docs/concepts/workloads/controllers/replicaset.md b/content/en/docs/concepts/workloads/controllers/replicaset.md
index 92cbe60a33..ef2a069ca1 100644
--- a/content/en/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/en/docs/concepts/workloads/controllers/replicaset.md
@@ -4,19 +4,19 @@ reviewers:
- bprashanth
- madhusudancs
title: ReplicaSet
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often
used to guarantee the availability of a specified number of identical Pods.
-{{% /capture %}}
-{{% capture body %}}
+
+
## How a ReplicaSet works
@@ -366,4 +366,4 @@ The two serve the same purpose, and behave similarly, except that a ReplicationC
selector requirements as described in the [labels user guide](/docs/concepts/overview/working-with-objects/labels/#label-selectors).
As such, ReplicaSets are preferred over ReplicationControllers
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
index fe20980ce6..2cc8284940 100644
--- a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -9,11 +9,11 @@ feature:
description: >
Restarts containers that fail, replaces and reschedules containers when nodes die, kills containers that don't respond to your user-defined health check, and doesn't advertise them to clients until they are ready to serve.
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
{{< note >}}
A [`Deployment`](/docs/concepts/workloads/controllers/deployment/) that configures a [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is now the recommended way to set up replication.
@@ -23,10 +23,10 @@ A _ReplicationController_ ensures that a specified number of pod replicas are ru
time. In other words, a ReplicationController makes sure that a pod or a homogeneous set of pods is
always up and available.
-{{% /capture %}}
-{{% capture body %}}
+
+
## How a ReplicationController Works
@@ -285,4 +285,4 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
Read [Run Stateless AP Replication Controller](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/).
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md
index 661955cb48..4f8429d668 100644
--- a/content/en/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/en/docs/concepts/workloads/controllers/statefulset.md
@@ -7,18 +7,18 @@ reviewers:
- kow3ns
- smarterclayton
title: StatefulSets
-content_template: templates/concept
+content_type: concept
weight: 40
---
-{{% capture overview %}}
+
StatefulSet is the workload API object used to manage stateful applications.
{{< glossary_definition term_id="statefulset" length="all" >}}
-{{% /capture %}}
-{{% capture body %}}
+
+
## Using StatefulSets
@@ -270,12 +270,13 @@ After reverting the template, you must also delete any Pods that StatefulSet had
already attempted to run with the bad configuration.
StatefulSet will then begin to recreate the Pods using the reverted template.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set/).
* Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/).
* Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/).
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md
index c5b88198f4..3a43d5e7b7 100644
--- a/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md
+++ b/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md
@@ -2,18 +2,18 @@
reviewers:
- janetkuo
title: TTL Controller for Finished Resources
-content_template: templates/concept
-weight: 65
+content_type: concept
+weight: 70
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
The TTL controller provides a TTL (time to live) mechanism to limit the lifetime of resource
objects that have finished execution. TTL controller only handles
-[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) for
-now, and may be expanded to handle other resources that will finish execution,
+{{< glossary_tooltip text="Jobs" term_id="job" >}} for now,
+and may be expanded to handle other resources that will finish execution,
such as Pods and custom resources.
Alpha Disclaimer: this feature is currently alpha, and can be enabled with both kube-apiserver and kube-controller-manager
@@ -21,19 +21,19 @@ Alpha Disclaimer: this feature is currently alpha, and can be enabled with both
`TTLAfterFinished`.
-{{% /capture %}}
-{{% capture body %}}
+
+
## TTL Controller
The TTL controller only supports Jobs for now. A cluster operator can use this feature to clean
up finished Jobs (either `Complete` or `Failed`) automatically by specifying the
`.spec.ttlSecondsAfterFinished` field of a Job, as in this
-[example](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
+[example](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically).
The TTL controller will assume that a resource is eligible to be cleaned up
TTL seconds after the resource has finished, in other words, when the TTL has expired. When the
TTL controller cleans up a resource, it will delete it cascadingly, that is to say it will delete
@@ -78,12 +78,13 @@ In Kubernetes, it's required to run NTP on all nodes
to avoid time skew. Clocks aren't always correct, but the difference should be
very small. Please be aware of this risk when setting a non-zero TTL.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
[Clean up Jobs automatically](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
[Design doc](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/workloads/pods/disruptions.md b/content/en/docs/concepts/workloads/pods/disruptions.md
index 9983a67fc8..589bde5668 100644
--- a/content/en/docs/concepts/workloads/pods/disruptions.md
+++ b/content/en/docs/concepts/workloads/pods/disruptions.md
@@ -4,11 +4,11 @@ reviewers:
- foxish
- davidopp
title: Disruptions
-content_template: templates/concept
+content_type: concept
weight: 60
---
-{{% capture overview %}}
+
This guide is for application owners who want to build
highly available applications, and thus need to understand
what types of Disruptions can happen to Pods.
@@ -16,10 +16,10 @@ what types of Disruptions can happen to Pods.
It is also for Cluster Administrators who want to perform automated
cluster actions, like upgrading and autoscaling clusters.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Voluntary and Involuntary Disruptions
@@ -262,13 +262,14 @@ the nodes in your cluster, such as a node or system software upgrade, here are s
disruptions largely overlaps with work to support autoscaling and tolerating
involuntary disruptions.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Follow steps to protect your application by [configuring a Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/).
* Learn more about [draining nodes](/docs/tasks/administer-cluster/safely-drain-node/)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/workloads/pods/ephemeral-containers.md b/content/en/docs/concepts/workloads/pods/ephemeral-containers.md
index c6506df69c..c1852df707 100644
--- a/content/en/docs/concepts/workloads/pods/ephemeral-containers.md
+++ b/content/en/docs/concepts/workloads/pods/ephemeral-containers.md
@@ -3,11 +3,11 @@ reviewers:
- verb
- yujuhong
title: Ephemeral Containers
-content_template: templates/concept
+content_type: concept
weight: 80
---
-{{% capture overview %}}
+
{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
@@ -23,9 +23,9 @@ clusters. In accordance with the [Kubernetes Deprecation Policy](
significantly in the future or be removed entirely.
{{< /warning >}}
-{{% /capture %}}
-{{% capture body %}}
+
+
## Understanding ephemeral containers
@@ -192,4 +192,4 @@ example:
kubectl attach -it example-pod -c debugger
```
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/workloads/pods/init-containers.md b/content/en/docs/concepts/workloads/pods/init-containers.md
index 2cf2bf85b5..6e67a9e0ca 100644
--- a/content/en/docs/concepts/workloads/pods/init-containers.md
+++ b/content/en/docs/concepts/workloads/pods/init-containers.md
@@ -2,20 +2,20 @@
reviewers:
- erictune
title: Init Containers
-content_template: templates/concept
+content_type: concept
weight: 40
---
-{{% capture overview %}}
+
This page provides an overview of init containers: specialized containers that run
before app containers in a {{< glossary_tooltip text="Pod" term_id="pod" >}}.
Init containers can contain utilities or setup scripts not present in an app image.
You can specify init containers in the Pod specification alongside the `containers`
array (which describes app containers).
-{{% /capture %}}
-{{% capture body %}}
+
+
## Understanding init containers
@@ -317,12 +317,13 @@ reasons:
forcing a restart, and the init container completion record has been lost due
to garbage collection.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container)
* Learn how to [debug init containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
index 74031a3722..d72265faf5 100644
--- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -1,20 +1,20 @@
---
title: Pod Lifecycle
-content_template: templates/concept
+content_type: concept
weight: 30
---
-{{% capture overview %}}
+
{{< comment >}}Updated: 4/14/2015{{< /comment >}}
{{< comment >}}Edited and moved to Concepts section: 2/2/17{{< /comment >}}
This page describes the lifecycle of a Pod.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Pod phase
@@ -77,7 +77,7 @@ A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prob
performed periodically by the [kubelet](/docs/admin/kubelet/)
on a Container. To perform a diagnostic,
the kubelet calls a
-[Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) implemented by
+[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by
the Container. There are three types of handlers:
* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
@@ -216,7 +216,7 @@ a list of additional conditions that the kubelet evaluates for Pod readiness.
Readiness gates are determined by the current state of `status.condition`
fields for the Pod. If Kubernetes cannot find such a
condition in the `status.conditions` field of a Pod, the status of the condition
-is defaulted to "`False`". Below is an example:
+is defaulted to "`False`".
Here is an example:
@@ -281,7 +281,7 @@ once bound to a node, a Pod will never be rebound to another node.
In general, Pods remain until a human or
{{< glossary_tooltip term_id="controller" text="controller" >}} process
explicitly removes them.
-The control plane cleans up terminated Pods (with a phase of `Succeeded` or
+The control plane cleans up terminated Pods (with a phase of `Succeeded` or
`Failed`), when the number of Pods exceeds the configured threshold
(determined by `terminated-pod-gc-threshold` in the kube-controller-manager).
This avoids a resource leak as Pods are created and terminated over time.
@@ -390,10 +390,11 @@ spec:
* Node controller sets Pod `phase` to Failed.
* If running under a controller, Pod is recreated elsewhere.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Get hands-on experience
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
@@ -403,7 +404,6 @@ spec:
* Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
-{{% /capture %}}
diff --git a/content/en/docs/concepts/workloads/pods/pod-overview.md b/content/en/docs/concepts/workloads/pods/pod-overview.md
index 2bc2951259..e963b7ace6 100644
--- a/content/en/docs/concepts/workloads/pods/pod-overview.md
+++ b/content/en/docs/concepts/workloads/pods/pod-overview.md
@@ -2,19 +2,19 @@
reviewers:
- erictune
title: Pod Overview
-content_template: templates/concept
+content_type: concept
weight: 10
card:
name: concepts
weight: 60
---
-{{% capture overview %}}
+
This page provides an overview of `Pod`, the smallest deployable object in the Kubernetes object model.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Understanding Pods
A *Pod* is the basic execution unit of a Kubernetes application--the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your {{< glossary_tooltip term_id="cluster" text="cluster" >}}.
@@ -111,12 +111,13 @@ For example, a Deployment controller ensures that the running Pods match the cur
On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not directly observe or manage any of the details around pod templates and updates; those details are abstracted away. That abstraction and separation of concerns simplifies system semantics, and makes it feasible to extend the cluster's behavior without changing existing code.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [Pods](/docs/concepts/workloads/pods/pod/)
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container
* Learn more about Pod behavior:
* [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods)
* [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
index 6e6f878449..2b16894e6b 100644
--- a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@@ -1,18 +1,18 @@
---
title: Pod Topology Spread Constraints
-content_template: templates/concept
+content_type: concept
weight: 50
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
You can use _topology spread constraints_ to control how {{< glossary_tooltip text="Pods" term_id="Pod" >}} are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Prerequisites
@@ -236,8 +236,7 @@ scheduled - more packed or more scattered.
The "EvenPodsSpread" feature provides flexible options to distribute Pods evenly across different
topology domains - to achieve high availability or cost-saving. This can also help on rolling update
-workloads and scaling out replicas smoothly.
-See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation) for more details.
+workloads and scaling out replicas smoothly. See [Motivation](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation) for more details.
## Known Limitations
@@ -246,4 +245,4 @@ As of 1.18, at which this feature is Beta, there are some known limitations:
- Scaling down a Deployment may result in imbalanced Pods distribution.
- Pods matched on tainted nodes are respected. See [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/workloads/pods/pod.md b/content/en/docs/concepts/workloads/pods/pod.md
index d64227be48..d87dc92cb2 100644
--- a/content/en/docs/concepts/workloads/pods/pod.md
+++ b/content/en/docs/concepts/workloads/pods/pod.md
@@ -1,19 +1,19 @@
---
reviewers:
title: Pods
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
_Pods_ are the smallest deployable units of computing that can be created and
managed in Kubernetes.
-{{% /capture %}}
-{{% capture body %}}
+
+
## What is a Pod?
@@ -206,4 +206,4 @@ describes the object in detail.
When creating the manifest for a Pod object, make sure the name specified is a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
-{{% /capture %}}
+
diff --git a/content/en/docs/concepts/workloads/pods/podpreset.md b/content/en/docs/concepts/workloads/pods/podpreset.md
index a1906c8b99..f77e34a3f9 100644
--- a/content/en/docs/concepts/workloads/pods/podpreset.md
+++ b/content/en/docs/concepts/workloads/pods/podpreset.md
@@ -2,20 +2,20 @@
reviewers:
- jessfraz
title: Pod Preset
-content_template: templates/concept
+content_type: concept
weight: 50
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
This page provides an overview of PodPresets, which are objects for injecting
certain information into pods at creation time. The information can include
secrets, volumes, volume mounts, and environment variables.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Understanding Pod presets
A PodPreset is an API resource for injecting additional runtime requirements
@@ -82,12 +82,13 @@ There may be instances where you wish for a Pod to not be altered by any Pod
Preset mutations. In these cases, you can add an annotation in the Pod Spec
of the form: `podpreset.admission.kubernetes.io/exclude: "true"`.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
See [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/)
For more information about the background, see the [design proposal for PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md).
-{{% /capture %}}
+
diff --git a/content/en/docs/contribute/_index.md b/content/en/docs/contribute/_index.md
index c6aa348125..2f93af4a35 100644
--- a/content/en/docs/contribute/_index.md
+++ b/content/en/docs/contribute/_index.md
@@ -1,5 +1,5 @@
---
-content_template: templates/concept
+content_type: concept
title: Contribute to Kubernetes docs
linktitle: Contribute
main_menu: true
@@ -10,7 +10,7 @@ card:
title: Start contributing
---
-{{% capture overview %}}
+
This website is maintained by [Kubernetes SIG Docs](/docs/contribute/#get-involved-with-sig-docs).
@@ -23,9 +23,9 @@ Kubernetes documentation contributors:
Kubernetes documentation welcomes improvements from all contributors, new and experienced!
-{{% /capture %}}
-{{% capture body %}}
+
+
## Getting started
@@ -48,7 +48,7 @@ roles and permissions.
- [Open a pull request using GitHub](/docs/contribute/new-content/new-content/#changes-using-github) to existing documentation and learn more about filing issues in GitHub.
- [Review pull requests](/docs/contribute/review/reviewing-prs/) from other Kubernetes community members for accuracy and language.
- Read the Kubernetes [content](/docs/contribute/style/content-guide/) and [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments.
-- Learn how to [use page templates](/docs/contribute/style/page-templates/) and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) to make bigger changes.
+- Learn about [page content types](/docs/contribute/style/page-content-types/) and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/).
## Next steps
@@ -75,4 +75,4 @@ SIG Docs communicates with different methods:
- Read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get involved with Kubernetes feature development.
- Submit a [blog post or case study](/docs/contribute/new-content/blogs-case-studies/).
-{{% /capture %}}
+
diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md
index 2ed3a4afd6..594816a2b5 100644
--- a/content/en/docs/contribute/advanced.md
+++ b/content/en/docs/contribute/advanced.md
@@ -1,11 +1,11 @@
---
title: Advanced contributing
slug: advanced
-content_template: templates/concept
+content_type: concept
weight: 98
---
-{{% capture overview %}}
+
This page assumes that you understand how to
[contribute to new content](/docs/contribute/new-content/overview) and
@@ -13,9 +13,9 @@ This page assumes that you understand how to
to learn about more ways to contribute. You need to use the Git command line
client and other tools for some of these tasks.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Be the PR Wrangler for a week
@@ -39,6 +39,7 @@ The PR wrangler’s duties include:
- Assign `Doc Review: Open Issues` or `Tech Review: Open Issues` for PRs that have been reviewed and require further input or action before merging.
- Assign `/lgtm` and `/approve` labels to PRs that can be merged.
- Merge PRs when they are ready, or close PRs that shouldn’t be accepted.
+ - Consider accepting accurate technical content even if the content meets only some of the docs' [style guidelines](/docs/contribute/style/style-guide/). Open a new issue with the label `good first issue` to address style concerns.
- Triage and tag incoming issues daily. See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata.
### Helpful GitHub queries for wranglers
@@ -245,4 +246,4 @@ When you’re ready to stop recording, click Stop.
The video uploads automatically to YouTube.
-{{% /capture %}}
+
diff --git a/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md b/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md
index 6c4d93cd40..5f4edbcc77 100644
--- a/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md
+++ b/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md
@@ -1,10 +1,10 @@
---
title: Contributing to the Upstream Kubernetes Code
-content_template: templates/task
+content_type: task
weight: 20
---
-{{% capture overview %}}
+
This page shows how to contribute to the upstream `kubernetes/kubernetes` project.
You can fix bugs found in the Kubernetes API documentation or the content of
@@ -16,9 +16,10 @@ API or the `kube-*` components from the upstream code, see the following instruc
- [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/)
- [Generating Reference Documentation for the Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
- You need to have these tools installed:
@@ -35,9 +36,9 @@ API or the `kube-*` components from the upstream code, see the following instruc
For more information, see [Creating a Pull Request](https://help.github.com/articles/creating-a-pull-request/)
and [GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962).
-{{% /capture %}}
-{{% capture steps %}}
+
+
## The big picture
@@ -230,12 +231,13 @@ the API reference documentation.
You are now ready to follow the [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) guide to generate the
[published Kubernetes API reference documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/)
* [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/)
-{{% /capture %}}
+
diff --git a/content/en/docs/contribute/generate-ref-docs/kubectl.md b/content/en/docs/contribute/generate-ref-docs/kubectl.md
index 5930a1f452..f057ce6800 100644
--- a/content/en/docs/contribute/generate-ref-docs/kubectl.md
+++ b/content/en/docs/contribute/generate-ref-docs/kubectl.md
@@ -1,10 +1,10 @@
---
title: Generating Reference Documentation for kubectl Commands
-content_template: templates/task
+content_type: task
weight: 90
---
-{{% capture overview %}}
+
This page shows how to generate the `kubectl` command reference.
@@ -21,15 +21,16 @@ reference page, see
[Generating Reference Pages for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/).
{{< /note >}}
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "prerequisites-ref-docs.md" >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Setting up the local repositories
@@ -253,12 +254,13 @@ A few minutes after your pull request is merged, your updated reference
topics will be visible in the
[published documentation](/docs/home).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/)
* [Generating Reference Documentation for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/)
-{{% /capture %}}
+
diff --git a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
index 35bf166d2b..10482eda97 100644
--- a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
+++ b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
@@ -1,10 +1,10 @@
---
title: Generating Reference Documentation for the Kubernetes API
-content_template: templates/task
+content_type: task
weight: 50
---
-{{% capture overview %}}
+
This page shows how to update the Kubernetes API reference documentation.
@@ -18,15 +18,16 @@ If you find bugs in the generated documentation, you need to
If you need only to regenerate the reference documentation from the [OpenAPI](https://github.com/OAI/OpenAPI-Specification)
spec, continue reading this page.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "prerequisites-ref-docs.md" >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Setting up the local repositories
@@ -138,19 +139,19 @@ git status
The output is similar to:
```
-static/docs/reference/generated/kubernetes-api/v1.17/css/bootstrap.min.css
-static/docs/reference/generated/kubernetes-api/v1.17/css/font-awesome.min.css
-static/docs/reference/generated/kubernetes-api/v1.17/css/stylesheet.css
-static/docs/reference/generated/kubernetes-api/v1.17/fonts/FontAwesome.otf
-static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.eot
-static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.svg
-static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.ttf
-static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.woff
-static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.woff2
-static/docs/reference/generated/kubernetes-api/v1.17/index.html
-static/docs/reference/generated/kubernetes-api/v1.17/js/jquery.scrollTo.min.js
-static/docs/reference/generated/kubernetes-api/v1.17/js/navData.js
-static/docs/reference/generated/kubernetes-api/v1.17/js/scroll.js
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/bootstrap.min.css
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/font-awesome.min.css
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/stylesheet.css
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/FontAwesome.otf
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.eot
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.svg
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.ttf
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.woff
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.woff2
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/index.html
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/jquery.scrollTo.min.js
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/navData.js
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/scroll.js
```
## Updating the API reference index pages
@@ -177,7 +178,7 @@ version number.
## Locally test the API reference
Publish a local version of the API reference.
-Verify the [local preview](http://localhost:1313/docs/reference/generated/kubernetes-api/v1.17/).
+Verify the [local preview](http://localhost:1313/docs/reference/generated/kubernetes-api/{{< param "version">}}/).
```shell
cd
@@ -194,12 +195,13 @@ Submit your changes as a
Monitor your pull request, and respond to reviewer comments as needed. Continue
to monitor your pull request until it has been merged.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/)
* [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/)
-{{% /capture %}}
+
diff --git a/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md b/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md
index f71db7afb1..be84beeb08 100644
--- a/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md
+++ b/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md
@@ -1,34 +1,36 @@
---
title: Generating Reference Pages for Kubernetes Components and Tools
-content_template: templates/task
+content_type: task
weight: 120
---
-{{% capture overview %}}
+
This page shows how to build the Kubernetes component and tool reference pages.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
Start with the [Prerequisites section](/docs/contribute/generate-ref-docs/quickstart/#before-you-begin)
in the Reference Documentation Quickstart guide.
-{{% /capture %}}
-{{% capture steps %}}
+
+
Follow the [Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/)
to generate the Kubernetes component and tool reference pages.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/)
* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/)
* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/)
* [Contributing to the Upstream Kubernetes Project for Documentation](/docs/contribute/generate-ref-docs/contribute-upstream/)
-{{% /capture %}}
+
diff --git a/content/en/docs/contribute/generate-ref-docs/quickstart.md b/content/en/docs/contribute/generate-ref-docs/quickstart.md
index 095bc05c21..df5cdbb95f 100644
--- a/content/en/docs/contribute/generate-ref-docs/quickstart.md
+++ b/content/en/docs/contribute/generate-ref-docs/quickstart.md
@@ -1,24 +1,25 @@
---
title: Quickstart
-content_template: templates/task
+content_type: task
weight: 40
---
-{{% capture overview %}}
+
This page shows how to use the `update-imported-docs` script to generate
the Kubernetes reference documentation. The script automates
the build setup and generates the reference documentation for a release.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "prerequisites-ref-docs.md" >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Getting the docs repository
@@ -219,19 +220,19 @@ static/docs/reference/generated/kubectl/css/font-awesome.min.css
### Generated Kubernetes API reference directories and files
```
-static/docs/reference/generated/kubernetes-api/v1.17/index.html
-static/docs/reference/generated/kubernetes-api/v1.17/js/navData.js
-static/docs/reference/generated/kubernetes-api/v1.17/js/scroll.js
-static/docs/reference/generated/kubernetes-api/v1.17/js/query.scrollTo.min.js
-static/docs/reference/generated/kubernetes-api/v1.17/css/font-awesome.min.css
-static/docs/reference/generated/kubernetes-api/v1.17/css/bootstrap.min.css
-static/docs/reference/generated/kubernetes-api/v1.17/css/stylesheet.css
-static/docs/reference/generated/kubernetes-api/v1.17/fonts/FontAwesome.otf
-static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.eot
-static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.svg
-static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.ttf
-static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.woff
-static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.woff2
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/index.html
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/navData.js
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/scroll.js
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/query.scrollTo.min.js
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/font-awesome.min.css
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/bootstrap.min.css
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/stylesheet.css
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/FontAwesome.otf
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.eot
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.svg
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.ttf
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.woff
+static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.woff2
```
Run `git add` and `git commit` to commit the files.
@@ -246,9 +247,10 @@ A few minutes after your pull request is merged, your updated reference
topics will be visible in the
[published documentation](/docs/home/).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
To generate the individual reference documentation by manually setting up the required build repositories and
running the build targets, see the following guides:
@@ -257,4 +259,4 @@ running the build targets, see the following guides:
* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/)
* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/)
-{{% /capture %}}
+
diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md
index cb3cf03187..0c698305b9 100644
--- a/content/en/docs/contribute/localization.md
+++ b/content/en/docs/contribute/localization.md
@@ -1,6 +1,6 @@
---
title: Localizing Kubernetes documentation
-content_template: templates/concept
+content_type: concept
approvers:
- remyleone
- rlenferink
@@ -12,13 +12,13 @@ card:
title: Translating the docs
---
-{{% capture overview %}}
+
This page shows you how to [localize](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/) the docs for a different language.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Getting started
@@ -279,13 +279,14 @@ SIG Docs welcomes upstream contributions and corrections to the English source.
You can also help add or improve content to an existing localization. Join the [Slack channel](https://kubernetes.slack.com/messages/C1J0BPD2M/) for the localization, and start opening PRs to help. Please limit pull requests to a single localization since pull requests that change content in multiple localizations could be difficult to review.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Once a localization meets requirements for workflow and minimum output, SIG docs will:
- Enable language selection on the website
- Publicize the localization's availability through [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF) channels, including the [Kubernetes blog](https://kubernetes.io/blog/).
-{{% /capture %}}
+
diff --git a/content/en/docs/contribute/new-content/blogs-case-studies.md b/content/en/docs/contribute/new-content/blogs-case-studies.md
index 90c50ae6e1..76acbd2d41 100644
--- a/content/en/docs/contribute/new-content/blogs-case-studies.md
+++ b/content/en/docs/contribute/new-content/blogs-case-studies.md
@@ -2,19 +2,19 @@
title: Submitting blog posts and case studies
linktitle: Blogs and case studies
slug: blogs-case-studies
-content_template: templates/concept
+content_type: concept
weight: 30
---
-{{% capture overview %}}
+
Anyone can write a blog post and submit it for review.
Case studies require extensive review before they're approved.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Write a blog post
@@ -52,8 +52,9 @@ Have a look at the source for the
Refer to the [case study guidelines](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md) and submit your request as outlined in the guidelines.
-{{% /capture %}}
-{{% capture whatsnext %}}
-{{% /capture %}}
+## {{% heading "whatsnext" %}}
+
+
+
diff --git a/content/en/docs/contribute/new-content/new-features.md b/content/en/docs/contribute/new-content/new-features.md
index 68087a2a79..54db84da8f 100644
--- a/content/en/docs/contribute/new-content/new-features.md
+++ b/content/en/docs/contribute/new-content/new-features.md
@@ -1,7 +1,7 @@
---
title: Documenting a feature for a release
linktitle: Documenting for a release
-content_template: templates/concept
+content_type: concept
main_menu: true
weight: 20
card:
@@ -9,7 +9,7 @@ card:
weight: 45
title: Documenting a feature for a release
---
-{{% capture overview %}}
+
Each major Kubernetes release introduces new features that require documentation. New releases also bring updates to existing features and documentation (such as upgrading a feature from alpha to beta).
@@ -19,9 +19,9 @@ feature as a pull request to the appropriate development branch of the
editorial feedback or edits the draft directly. This section covers the branching
conventions and process used during a release by both groups.
-{{% /capture %}}
-{{% capture body %}}
+
+
## For documentation contributors
@@ -131,4 +131,3 @@ add it to [Alpha/Beta Feature gates](/docs/reference/command-line-tools-referenc
as part of your pull request. If your feature is moving out of Alpha, make sure to
remove it from that table.
-{{% /capture %}}
\ No newline at end of file
diff --git a/content/en/docs/contribute/new-content/open-a-pr.md b/content/en/docs/contribute/new-content/open-a-pr.md
index 4407568aff..5b2642dd39 100644
--- a/content/en/docs/contribute/new-content/open-a-pr.md
+++ b/content/en/docs/contribute/new-content/open-a-pr.md
@@ -1,14 +1,14 @@
---
title: Opening a pull request
slug: new-content
-content_template: templates/concept
+content_type: concept
weight: 10
card:
name: contribute
weight: 40
---
-{{% capture overview %}}
+
{{< note >}}
**Code developers**: If you are documenting a new feature for an
@@ -22,9 +22,9 @@ If your change is small, or you're unfamiliar with git, read [Changes using GitH
If your changes are large, read [Work from a local fork](#fork-the-repo) to learn how to make changes locally on your computer.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Changes using GitHub
@@ -217,21 +217,37 @@ When you are ready to submit a pull request, commit your changes.
It's a good idea to preview your changes locally before pushing them or opening a pull request. A preview lets you catch build errors or markdown formatting problems.
-You can either build the website's docker image or run Hugo locally. Building the docker image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can be useful for debugging.
+You can either build the website's container image or run Hugo locally. Building the container image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can be useful for debugging.
{{< tabs name="tab_with_hugo" >}}
{{% tab name="Hugo in a container" %}}
+{{< note >}}
+The commands below use Docker as default container engine. Set the `CONTAINER_ENGINE` environment variable to override this behaviour.
+{{< /note >}}
+
1. Build the image locally:
```bash
- make docker-image
+ # Use docker (default)
+ make container-image
+
+ ### OR ###
+
+ # Use podman
+ CONTAINER_ENGINE=podman make container-image
```
2. After building the `kubernetes-hugo` image locally, build and serve the site:
```bash
- make docker-serve
+ # Use docker (default)
+ make container-serve
+
+ ### OR ###
+
+ # Use podman
+ CONTAINER_ENGINE=podman make container-serve
```
3. In a web browser, navigate to `https://localhost:1313`. Hugo watches the
@@ -475,10 +491,11 @@ Most repositories use issue and PR templates. Have a look through some open
issues and PRs to get a feel for that team's processes. Make sure to fill out
the templates with as much detail as possible when you file issues or PRs.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
- Read [Reviewing](/docs/contribute/reviewing/revewing-prs) to learn more about the review process.
-{{% /capture %}}
+
diff --git a/content/en/docs/contribute/new-content/overview.md b/content/en/docs/contribute/new-content/overview.md
index 11f4c067d7..e9ef332430 100644
--- a/content/en/docs/contribute/new-content/overview.md
+++ b/content/en/docs/contribute/new-content/overview.md
@@ -1,25 +1,25 @@
---
title: Contributing new content overview
linktitle: Overview
-content_template: templates/concept
+content_type: concept
main_menu: true
weight: 5
---
-{{% capture overview %}}
+
This section contains information you should know before contributing new content.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Contributing basics
- Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/).
- The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
-- [Page templates](/docs/contribute/style/page-templates/) control the presentation of documentation content in Hugo.
+- [Page content types](/docs/contribute/style/page-content-types/) describe the presentation of documentation content in Hugo.
- In addition to the standard Hugo shortcodes, we use a number of [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content.
- Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`.
- For more information about contributing to documentation in multiple languages or starting a new translation, see [localization](/docs/contribute/localization).
@@ -58,4 +58,4 @@ Limit pull requests to one language per PR. If you need to make an identical cha
The [doc contributors tools](https://github.com/kubernetes/website/tree/master/content/en/docs/doc-contributor-tools) directory in the `kubernetes/website` repository contains tools to help your contribution journey go more smoothly.
-{{% /capture %}}
+
diff --git a/content/en/docs/contribute/participating.md b/content/en/docs/contribute/participating.md
index 3f491dc856..681c53f994 100644
--- a/content/en/docs/contribute/participating.md
+++ b/content/en/docs/contribute/participating.md
@@ -1,13 +1,13 @@
---
title: Participating in SIG Docs
-content_template: templates/concept
+content_type: concept
weight: 60
card:
name: contribute
weight: 60
---
-{{% capture overview %}}
+
SIG Docs is one of the
[special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md)
@@ -30,9 +30,9 @@ The rest of this document outlines some unique ways these roles function within
SIG Docs, which is responsible for maintaining one of the most public-facing
aspects of Kubernetes -- the Kubernetes website and documentation.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Roles and responsibilities
@@ -302,9 +302,10 @@ SIG Docs approvers. Here's how it works.
specific roles, such as [PR Wrangler](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) or
[SIG Docs chairperson](#sig-docs-chairperson).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
For more information about contributing to the Kubernetes documentation, see:
@@ -312,4 +313,4 @@ For more information about contributing to the Kubernetes documentation, see:
- [Reviewing content](/docs/contribute/review/reviewing-prs)
- [Documentation style guide](/docs/contribute/style/)
-{{% /capture %}}
+
diff --git a/content/en/docs/contribute/review/_index.md b/content/en/docs/contribute/review/_index.md
index bc70e3c6f1..d2a1a5c906 100644
--- a/content/en/docs/contribute/review/_index.md
+++ b/content/en/docs/contribute/review/_index.md
@@ -3,12 +3,12 @@ title: Reviewing changes
weight: 30
---
-{{% capture overview %}}
+
This section describes how to review content.
-{{% /capture %}}
-{{% capture body %}}
-{{% /capture %}}
+
+
+
diff --git a/content/en/docs/contribute/review/for-approvers.md b/content/en/docs/contribute/review/for-approvers.md
index dccc6cfe38..0cddbcba6a 100644
--- a/content/en/docs/contribute/review/for-approvers.md
+++ b/content/en/docs/contribute/review/for-approvers.md
@@ -2,11 +2,11 @@
title: Reviewing for approvers and reviewers
linktitle: For approvers and reviewers
slug: for-approvers
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
SIG Docs [Reviewers](/docs/contribute/participating/#reviewers) and [Approvers](/docs/contribute/participating/#approvers) do a few extra things when reviewing a change.
@@ -19,10 +19,10 @@ requests (PRs) that are not already under active review.
In addition to the rotation, a bot assigns reviewers and approvers
for the PR based on the owners for the affected files.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Reviewing a PR
@@ -224,4 +224,3 @@ If this is a documentation issue, please re-open this issue.
```
-{{% /capture %}}
\ No newline at end of file
diff --git a/content/en/docs/contribute/review/reviewing-prs.md b/content/en/docs/contribute/review/reviewing-prs.md
index cb432a97ba..3c271aa44f 100644
--- a/content/en/docs/contribute/review/reviewing-prs.md
+++ b/content/en/docs/contribute/review/reviewing-prs.md
@@ -1,11 +1,11 @@
---
title: Reviewing pull requests
-content_template: templates/concept
+content_type: concept
main_menu: true
weight: 10
---
-{{% capture overview %}}
+
Anyone can review a documentation pull request. Visit the [pull requests](https://github.com/kubernetes/website/pulls) section in the Kubernetes website repository to see open pull requests.
@@ -19,9 +19,9 @@ Before reviewing, it's a good idea to:
[style guide](/docs/contribute/style/style-guide/) so you can leave informed comments.
- Understand the different [roles and responsibilities](/docs/contribute/participating/#roles-and-responsibilities) in the Kubernetes documentation community.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Before you begin
@@ -86,7 +86,7 @@ When reviewing, use the following as a starting point.
- Did this PR change or remove a page title, slug/alias or anchor link? If so, are there broken links as a result of this PR? Is there another option, like changing the page title without changing the slug?
- Does the PR introduce a new page? If so:
- - Is the page using the right [page template](/docs/contribute/style/page-templates/) and associated Hugo shortcodes?
+ - Is the page using the right [page content type](/docs/contribute/style/page-content-types/) and associated Hugo shortcodes?
- Does the page appear correctly in the section's side navigation (or at all)?
- Should the page appear on the [Docs Home](/docs/home/) listing?
- Do the changes show up in the Netlify preview? Be particularly vigilant about lists, code blocks, tables, notes and images.
@@ -95,4 +95,3 @@ When reviewing, use the following as a starting point.
For small issues with a PR, like typos or whitespace, prefix your comments with `nit:`. This lets the author know the issue is non-critical.
-{{% /capture %}}
\ No newline at end of file
diff --git a/content/en/docs/contribute/style/content-guide.md b/content/en/docs/contribute/style/content-guide.md
index b5d8ed5d02..2f367c9a81 100644
--- a/content/en/docs/contribute/style/content-guide.md
+++ b/content/en/docs/contribute/style/content-guide.md
@@ -1,11 +1,11 @@
---
title: Documentation Content Guide
linktitle: Content guide
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
This page contains guidelines for Kubernetes documentation.
@@ -17,9 +17,9 @@ You can register for Kubernetes Slack at http://slack.k8s.io/.
For information on creating new content for the Kubernetes
docs, follow the [style guide](/docs/contribute/style/style-guide).
-{{% /capture %}}
-{{% capture body %}}
+
+
## Overview
@@ -69,10 +69,11 @@ ask for help in [#sig-docs on Kubernetes Slack](https://kubernetes.slack.com/mes
If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask!
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Read the [Style guide](/docs/contribute/style/style-guide).
-{{% /capture %}}
+
diff --git a/content/en/docs/contribute/style/content-organization.md b/content/en/docs/contribute/style/content-organization.md
index e93cf8126e..249bebf0fb 100644
--- a/content/en/docs/contribute/style/content-organization.md
+++ b/content/en/docs/contribute/style/content-organization.md
@@ -1,17 +1,17 @@
---
title: Content organization
-content_template: templates/concept
+content_type: concept
weight: 40
---
-{{% capture overview %}}
+
This site uses Hugo. In Hugo, [content organization](https://gohugo.io/content-management/organization/) is a core concept.
-{{% /capture %}}
-{{% capture body %}}
+
+
{{% note %}}
**Hugo Tip:** Start Hugo with `hugo server --navigateToChanged` for content edit-sessions.
@@ -126,12 +126,13 @@ Some important notes to the files in the bundles:
The [SASS](https://sass-lang.com/) source of the stylesheets for this site is stored in `assets/sass` and is automatically built by Hugo.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn about [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/)
* Learn about the [Style guide](/docs/contribute/style/style-guide)
* Learn about the [Content guide](/docs/contribute/style/content-guide)
-{{% /capture %}}
+
diff --git a/content/en/docs/contribute/style/hugo-shortcodes/index.md b/content/en/docs/contribute/style/hugo-shortcodes/index.md
index 60479c7fec..e4a6d703ad 100644
--- a/content/en/docs/contribute/style/hugo-shortcodes/index.md
+++ b/content/en/docs/contribute/style/hugo-shortcodes/index.md
@@ -2,16 +2,16 @@
approvers:
- chenopis
title: Custom Hugo Shortcodes
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
This page explains the custom Hugo shortcodes that can be used in Kubernetes markdown documentation.
Read more about shortcodes in the [Hugo documentation](https://gohugo.io/content-management/shortcodes).
-{{% /capture %}}
-{{% capture body %}}
+
+
## Feature state
@@ -235,12 +235,13 @@ Renders to:
{{< tab name="JSON File" include="podtemplate" />}}
{{< /tabs >}}
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn about [Hugo](https://gohugo.io/).
-* Learn about [writing a new topic](/docs/home/contribute/write-new-topic/).
-* Learn about [using page templates](/docs/home/contribute/page-templates/).
-* Learn about [staging your changes](/docs/home/contribute/stage-documentation-changes/)
-* Learn about [creating a pull request](/docs/home/contribute/create-pull-request/).
-{{% /capture %}}
+* Learn about [writing a new topic](/docs/contribute/style/write-new-topic/).
+* Learn about [page content types](/docs/contribute/style/page-content-types/).
+* Learn about [creating a pull request](/docs/contribute/new-content/new-content/).
+* Learn about [advanced contributing](/docs/contribute/advanced/).
+
diff --git a/content/en/docs/contribute/style/page-content-types.md b/content/en/docs/contribute/style/page-content-types.md
new file mode 100644
index 0000000000..2a3325d397
--- /dev/null
+++ b/content/en/docs/contribute/style/page-content-types.md
@@ -0,0 +1,221 @@
+---
+title: Page content types
+content_type: concept
+weight: 30
+card:
+ name: contribute
+ weight: 30
+---
+
+
+
+The Kubernetes documentation follows several types of page content:
+
+- Concept
+- Task
+- Tutorial
+- Reference
+
+
+
+## Content sections
+
+Each page content type contains a number of sections defined by
+Markdown comments and HTML headings. You can add content headings to
+your page with the `heading` shortcode. The comments and headings help
+maintain the structure of the page content types.
+
+Examples of Markdown comments defining page content sections:
+
+```markdown
+
+```
+
+```markdown
+
+```
+
+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
+
+For example, to create a `whatsnext` heading, add the heading shortcode with the "whatsnext" string:
+
+```none
+## {{%/* heading "whatsnext" */%}}
+```
+
+You can declare a `prerequisites` heading as follows:
+
+```none
+## {{%/* heading "prerequisites" */%}}
+```
+
+The `heading` shortcode expects one string parameter.
+The heading string parameter matches the prefix of a variable in the `i18n/.toml` files.
+For example:
+
+`i18n/en.toml`:
+
+```toml
+[whatsnext_heading]
+other = "What's next"
+```
+
+`i18n/ko.toml`:
+
+```toml
+[whatsnext_heading]
+other = "다음 내용"
+```
+
+## Content types
+
+Each content type informally defines its expected page structure.
+Create page content with the suggested page sections.
+
+### Concept
+
+A concept page explains some aspect of Kubernetes. For example, a concept
+page might describe the Kubernetes Deployment object and explain the role it
+plays as an application once it is deployed, scaled, and updated. Typically, concept
+pages don't include sequences of steps, but instead provide links to tasks or
+tutorials.
+
+To write a new concept page, create a Markdown file in a subdirectory of the
+`/content/en/docs/concepts` directory, with the following characteristics:
+
+Concept pages are divided into three sections:
+
+| Page section |
+|---------------|
+| overview |
+| body |
+| whatsnext |
+
+The `overview` and `body` sections appear as comments in the concept page.
+You can add the `whatsnext` section to your page with the `heading` shortcode.
+
+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
+
+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
+to conceptual topics that provide related background and knowledge.
+
+To write a new task page, create a Markdown file in a subdirectory of the
+`/content/en/docs/tasks` directory, with the following characteristics:
+
+| Page section |
+|---------------|
+| overview |
+| prerequisites |
+| steps |
+| discussion |
+| whatsnext |
+
+The `overview`, `steps`, and `discussion` sections appear as comments in the task page.
+You can add the `prerequisites` and `whatsnext` sections to your page
+with the `heading` shortcode.
+
+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.
+- For `prerequisites`, use bullet lists when possible. Start adding additional
+ prerequisites below the `include`. The default prerequisites include a running Kubernetes cluster.
+- For `steps`, use numbered lists.
+- For discussion, use normal content to expand upon the information covered
+ in `steps`.
+- 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/extend-kubernetes/http-proxy-access-api/).
+
+### Tutorial
+
+A tutorial page shows how to accomplish a goal that is larger than a single
+task. Typically a tutorial page has several sections, each of which has a
+sequence of steps. For example, a tutorial might provide a walkthrough of a
+code sample that illustrates a certain feature of Kubernetes. Tutorials can
+include surface-level explanations, but should link to related concept topics
+for deep explanations.
+
+To write a new tutorial page, create a Markdown file in a subdirectory of the
+`/content/en/docs/tutorials` directory, with the following characteristics:
+
+| Page section |
+|---------------|
+| overview |
+| prerequisites |
+| objectives |
+| lessoncontent |
+| cleanup |
+| whatsnext |
+
+The `overview`, `objectives`, and `lessoncontent` sections appear as comments in the tutorial page.
+You can add the `prerequisites`, `cleanup`, and `whatsnext` sections to your page
+with the `heading` shortcode.
+
+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.
+- For `prerequisites`, use bullet lists when possible. Add additional
+ prerequisites below the ones included by default.
+- For `objectives`, use bullet lists.
+- For `lessoncontent`, use a mix of numbered lists and narrative content as
+ appropriate.
+- For `cleanup`, use numbered lists to describe the steps to clean up the
+ state of the cluster after finishing the task.
+- For `whatsnext`, give a bullet list of up to 5 topics the reader might be
+ interested in reading next.
+
+An example of a published tutorial topic is
+[Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/).
+
+### Reference
+
+A component tool reference page shows the description and flag options output for
+a Kubernetes component tool. Each page generates from scripts using the component tool commands.
+
+A tool reference page has several possible sections:
+
+| Page section |
+|------------------------------|
+| synopsis |
+| options |
+| options from parent commands |
+| examples |
+| seealso |
+
+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/)
+- [kubectl](/docs/reference/kubectl/kubectl/)
+
+## {{% heading "whatsnext" %}}
+
+- Learn about the [Style guide](/docs/contribute/style/style-guide/)
+- Learn about the [Content guide](/docs/contribute/style/content-guide/)
+- Learn about [content organization](/docs/contribute/style/content-organization/)
diff --git a/content/en/docs/contribute/style/page-templates.md b/content/en/docs/contribute/style/page-templates.md
deleted file mode 100644
index 7521ee3ecb..0000000000
--- a/content/en/docs/contribute/style/page-templates.md
+++ /dev/null
@@ -1,222 +0,0 @@
----
-title: Using Page Templates
-content_template: templates/concept
-weight: 30
-card:
- name: contribute
- weight: 30
----
-
-{{% capture overview %}}
-
-When contributing new topics, apply one of the following templates to them.
-This standardizes the user experience of a given page.
-
-The page templates are in the
-[`layouts/partials/templates`](https://git.k8s.io/website/layouts/partials/templates)
-directory of the [`kubernetes/website`](https://github.com/kubernetes/website)
-repository.
-
-{{< note >}}
-Every new topic needs to use a template. If you are unsure which
-template to use for a new topic, start with the
-[concept template](#concept-template).
-{{< /note >}}
-
-
-{{% /capture %}}
-
-
-{{% capture body %}}
-
-## Concept template
-
-A concept page explains some aspect of Kubernetes. For example, a concept
-page might describe the Kubernetes Deployment object and explain the role it
-plays as an application once it is deployed, scaled, and updated. Typically, concept
-pages don't include sequences of steps, but instead provide links to tasks or
-tutorials.
-
-
-To write a new concept page, create a Markdown file in a subdirectory of the
-`/content/en/docs/concepts` directory, with the following characteristics:
-
-- In the page's YAML front-matter, set `content_template: templates/concept`.
-- In the page's body, set the required `capture` variables and any optional
- ones you want to include:
-
- | Variable | Required? |
- |---------------|-----------|
- | overview | yes |
- | body | yes |
- | whatsnext | no |
-
- The page's body will look like this (remove any optional captures you don't
- need):
-
- ```
- {{%/* capture overview */%}}
-
- {{%/* /capture */%}}
-
- {{%/* capture body */%}}
-
- {{%/* /capture */%}}
-
- {{%/* capture whatsnext */%}}
-
- {{%/* /capture */%}}
- ```
-
-- 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 the concept template. This page also uses the concept template.
-
-## Task template
-
-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
-to conceptual topics that provide related background and knowledge.
-
-To write a new task page, create a Markdown file in a subdirectory of the
-`/content/en/docs/tasks` directory, with the following characteristics:
-
-- In the page's YAML front-matter, set `content_template: templates/task`.
-- In the page's body, set the required `capture` variables and any optional
- ones you want to include:
-
- | Variable | Required? |
- |---------------|-----------|
- | overview | yes |
- | prerequisites | yes |
- | steps | no |
- | discussion | no |
- | whatsnext | no |
-
- The page's body will look like this (remove any optional captures you don't
- need):
-
- ```
- {{%/* capture overview */%}}
-
- {{%/* /capture */%}}
-
- {{%/* capture prerequisites */%}}
-
- {{}} {{}}
-
- {{%/* /capture */%}}
-
- {{%/* capture steps */%}}
-
- {{%/* /capture */%}}
-
- {{%/* capture discussion */%}}
-
- {{%/* /capture */%}}
-
- {{%/* capture whatsnext */%}}
-
- {{%/* /capture */%}}
- ```
-
-- 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.
- - For `prerequisites`, use bullet lists when possible. Start adding additional
- prerequisites below the `include`. The default prerequisites include a running Kubernetes cluster.
- - For `steps`, use numbered lists.
- - For discussion, use normal content to expand upon the information covered
- in `steps`.
- - For `whatsnext`, give a bullet list of up to 5 topics the reader might be
- interested in reading next.
-
-An example of a published topic that uses the task template is [Using an HTTP proxy to access the Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api).
-
-## Tutorial template
-
-A tutorial page shows how to accomplish a goal that is larger than a single
-task. Typically a tutorial page has several sections, each of which has a
-sequence of steps. For example, a tutorial might provide a walkthrough of a
-code sample that illustrates a certain feature of Kubernetes. Tutorials can
-include surface-level explanations, but should link to related concept topics
-for deep explanations.
-
-To write a new tutorial page, create a Markdown file in a subdirectory of the
-`/content/en/docs/tutorials` directory, with the following characteristics:
-
-- In the page's YAML front-matter, set `content_template: templates/tutorial`.
-- In the page's body, set the required `capture` variables and any optional
- ones you want to include:
-
- | Variable | Required? |
- |---------------|-----------|
- | overview | yes |
- | prerequisites | yes |
- | objectives | yes |
- | lessoncontent | yes |
- | cleanup | no |
- | whatsnext | no |
-
- The page's body will look like this (remove any optional captures you don't
- need):
-
- ```
- {{%/* capture overview */%}}
-
- {{%/* /capture */%}}
-
- {{%/* capture prerequisites */%}}
-
- {{}} {{}}
-
- {{%/* /capture */%}}
-
- {{%/* capture objectives */%}}
-
- {{%/* /capture */%}}
-
- {{%/* capture lessoncontent */%}}
-
- {{%/* /capture */%}}
-
- {{%/* capture cleanup */%}}
-
- {{%/* /capture */%}}
-
- {{%/* capture whatsnext */%}}
-
- {{%/* /capture */%}}
- ```
-
-- 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.
- - For `prerequisites`, use bullet lists when possible. Add additional
- prerequisites below the ones included by default.
- - For `objectives`, use bullet lists.
- - For `lessoncontent`, use a mix of numbered lists and narrative content as
- appropriate.
- - For `cleanup`, use numbered lists to describe the steps to clean up the
- state of the cluster after finishing the task.
- - For `whatsnext`, give a bullet list of up to 5 topics the reader might be
- interested in reading next.
-
-An example of a published topic that uses the tutorial template is
-[Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/).
-
-{{% /capture %}}
-
-{{% capture whatsnext %}}
-
-- Learn about the [Style guide](/docs/contribute/style/style-guide/)
-- Learn about the [Content guide](/docs/contribute/style/content-guide/)
-- Learn about [content organization](/docs/contribute/style/content-organization/)
-
-{{% /capture %}}
diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md
index 34dce6adac..55aa30d66c 100644
--- a/content/en/docs/contribute/style/style-guide.md
+++ b/content/en/docs/contribute/style/style-guide.md
@@ -1,26 +1,25 @@
---
title: Documentation Style Guide
linktitle: Style guide
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
This page gives writing style guidelines for the Kubernetes documentation.
These are guidelines, not rules. Use your best judgment, and feel free to
propose changes to this document in a pull request.
For additional information on creating new content for the Kubernetes
-documentation, read the [Documentation Content Guide](/docs/contribute/style/content-guide/) and follow the instructions on
-[using page templates](/docs/contribute/style/page-templates/) and [creating a documentation pull request](/docs/contribute/new-content/open-a-pr).
+documentation, read the [Documentation Content Guide](/docs/contribute/style/content-guide/).
Changes to the style guide are made by SIG Docs as a group. To propose a change
or addition, [add it to the agenda](https://docs.google.com/document/d/1ddHwLK3kUMX1wVFIwlksjTk0MsqitBnWPe1LRa1Rx5A/edit) for an upcoming SIG Docs meeting, and attend the meeting to participate in the
discussion.
-{{% /capture %}}
-{{% capture body %}}
+
+
{{< note >}}
Kubernetes documentation uses [Blackfriday Markdown Renderer](https://github.com/russross/blackfriday) along with a few [Hugo Shortcodes](/docs/home/contribute/includes/) to support glossary entries, tabs,
@@ -122,7 +121,7 @@ document, use the backtick (`` ` ``).
{{< table caption = "Do and Don't - Use code style for inline code and commands" >}}
Do | Don't
:--| :-----
-The `kubectl run`command creates a Deployment. | The "kubectl run" command creates a Deployment.
+The `kubectl run`command creates a Pod. | The "kubectl run" command creates a Pod.
For declarative management, use `kubectl apply`. | For declarative management, use "kubectl apply".
Enclose code samples with triple backticks. (\`\`\`)| Enclose code samples with any other syntax.
Use single backticks to enclose inline code. For example, `var example = true`. | Use two asterisks (`**`) or an underscore (`_`) to enclose inline code. For example, **var example = true**.
@@ -212,7 +211,7 @@ The output is similar to this:
Code examples and configuration examples that include version information should be consistent with the accompanying text.
-If the information is version specific, the Kubernetes version needs to be defined in the `prerequisites` section of the [Task template](/docs/contribute/style/page-templates/#task-template) or the [Tutorial template](/docs/contribute/style/page-templates/#tutorial-template). Once the page is saved, the `prerequisites` section is shown as **Before you begin**.
+If the information is version specific, the Kubernetes version needs to be defined in the `prerequisites` section of the [Task template](/docs/contribute/style/page-content-types/#task) or the [Tutorial template](/docs/contribute/style/page-content-types/#tutorial). Once the page is saved, the `prerequisites` section is shown as **Before you begin**.
To specify the Kubernetes version for a task or tutorial page, include `min-kubernetes-server-version` in the front matter of the page.
@@ -497,7 +496,7 @@ Do | Don't
:--| :-----
You can explore the API using a browser. | The API can be explored using a browser.
The YAML file specifies the replica count. | The replica count is specified in the YAML file.
-{{< /table >}}
+{{< /table >}}
Exception: Use passive voice if active voice leads to an awkward construction.
@@ -512,7 +511,7 @@ Do | Don't
To create a ReplicaSet, ... | In order to create a ReplicaSet, ...
See the configuration file. | Please see the configuration file.
View the Pods. | With this next command, we'll view the Pods.
-{{< /table >}}
+{{< /table >}}
### Address the reader as "you"
@@ -521,7 +520,7 @@ Do | Don't
:--| :-----
You can create a Deployment by ... | We'll create a Deployment by ...
In the preceding output, you can see... | In the preceding output, we can see ...
-{{< /table >}}
+{{< /table >}}
### Avoid Latin phrases
@@ -533,7 +532,7 @@ Do | Don't
:--| :-----
For example, ... | e.g., ...
That is, ...| i.e., ...
-{{< /table >}}
+{{< /table >}}
Exception: Use "etc." for et cetera.
@@ -551,7 +550,7 @@ Do | Don't
Version 1.4 includes ... | In version 1.4, we have added ...
Kubernetes provides a new feature for ... | We provide a new feature ...
This page teaches you how to use Pods. | In this page, we are going to learn about Pods.
-{{< /table >}}
+{{< /table >}}
### Avoid jargon and idioms
@@ -563,7 +562,7 @@ Do | Don't
:--| :-----
Internally, ... | Under the hood, ...
Create a new cluster. | Turn up a new cluster.
-{{< /table >}}
+{{< /table >}}
### Avoid statements about the future
@@ -582,16 +581,15 @@ Do | Don't
:--| :-----
In version 1.4, ... | In the current version, ...
The Federation feature provides ... | The new Federation feature provides ...
-{{< /table >}}
+{{< /table >}}
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn about [writing a new topic](/docs/contribute/style/write-new-topic/).
-* Learn about [using page templates](/docs/contribute/style/page-templates/).
+* Learn about [using page templates](/docs/contribute/style/page-content-types/).
* Learn about [staging your changes](/docs/contribute/stage-documentation-changes/)
-* Learn about [creating a pull request](/docs/contribute/start/#submit-a-pull-request/).
-
-{{% /capture %}}
+* Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/).
diff --git a/content/en/docs/contribute/style/write-new-topic.md b/content/en/docs/contribute/style/write-new-topic.md
index 65dca22f1a..8bd4b8fbe2 100644
--- a/content/en/docs/contribute/style/write-new-topic.md
+++ b/content/en/docs/contribute/style/write-new-topic.md
@@ -1,19 +1,20 @@
---
title: Writing a new topic
-content_template: templates/task
+content_type: task
weight: 20
---
-{{% capture overview %}}
+
This page shows how to create a new topic for the Kubernetes docs.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
Create a fork of the Kubernetes documentation repository as described in
[Open a PR](/docs/new-content/open-a-pr/).
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Choosing a page type
@@ -27,9 +28,8 @@ Task | A task page shows how to do a single thing. The idea is to give readers a
Tutorial | A tutorial page shows how to accomplish a goal that ties together several Kubernetes features. A tutorial might provide several sequences of steps that readers can actually do as they read the page. Or it might provide explanations of related pieces of code. For example, a tutorial could provide a walkthrough of a code sample. A tutorial can include brief explanations of the Kubernetes features that are being tied together, but should link to related concept topics for deep explanations of individual features.
{{< /table >}}
-Use a template for each new page. Each page type has a
-[template](/docs/contribute/style/page-templates/)
-that you can use as you write your topic. Using templates helps ensure
+Use a [content type](/docs/contribute/style/page-content-types/) for each new page
+that you write. Using page type helps ensure
consistency among topics of a given type.
## Choosing a title and filename
@@ -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
@@ -159,9 +159,10 @@ For an example of a topic that uses this technique, see
Put image files in the `/images` directory. The preferred
image format is SVG.
-{{% /capture %}}
-{{% capture whatsnext %}}
-* Learn about [using page templates](/docs/contribute/page-templates/).
+
+## {{% heading "whatsnext" %}}
+
+* Learn about [using page content types](/docs/contribute/style/page-content-types/).
* Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/).
-{{% /capture %}}
+
diff --git a/content/en/docs/contribute/suggesting-improvements.md b/content/en/docs/contribute/suggesting-improvements.md
index 19133f379b..e48c2915b9 100644
--- a/content/en/docs/contribute/suggesting-improvements.md
+++ b/content/en/docs/contribute/suggesting-improvements.md
@@ -1,14 +1,14 @@
---
title: Suggesting content improvements
slug: suggest-improvements
-content_template: templates/concept
+content_type: concept
weight: 10
card:
name: contribute
weight: 20
---
-{{% capture overview %}}
+
If you notice an issue with Kubernetes documentation, or have an idea for new content, then open an issue. All you need is a [GitHub account](https://github.com/join) and a web browser.
@@ -16,9 +16,9 @@ In most cases, new work on Kubernetes documentation begins with an issue in GitH
then review, categorize and tag issues as needed. Next, you or another member
of the Kubernetes community open a pull request with changes to resolve the issue.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Opening an issue
@@ -62,4 +62,4 @@ Keep the following in mind when filing an issue:
fellow contributors. For example, "The docs are terrible" is not
helpful or polite feedback.
-{{% /capture %}}
+
diff --git a/content/en/docs/home/_index.md b/content/en/docs/home/_index.md
index 6b6e77c39a..8864e4781a 100644
--- a/content/en/docs/home/_index.md
+++ b/content/en/docs/home/_index.md
@@ -56,9 +56,11 @@ cards:
description: Anyone can contribute, whether you’re new to the project or you’ve been around a long time.
button: Contribute to the docs
button_path: /docs/contribute
-- name: download
- title: Download Kubernetes
+- name: release-notes
+ title: Release Notes
description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes.
+ button: "Download Kubernetes"
+ button_path: "/docs/setup/release/notes"
- name: about
title: About the documentation
description: This website contains documentation for the current and previous 4 versions of Kubernetes.
diff --git a/content/en/docs/home/supported-doc-versions.md b/content/en/docs/home/supported-doc-versions.md
index 45a6012eaa..bd368b2b54 100644
--- a/content/en/docs/home/supported-doc-versions.md
+++ b/content/en/docs/home/supported-doc-versions.md
@@ -1,20 +1,20 @@
---
title: Supported Versions of the Kubernetes Documentation
-content_template: templates/concept
+content_type: concept
card:
name: about
weight: 10
title: Supported Versions of the Documentation
---
-{{% capture overview %}}
+
This website contains documentation for the current version of Kubernetes
and the four previous versions of Kubernetes.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Current version
@@ -25,6 +25,6 @@ The current version is
{{< versions-other >}}
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/_index.md b/content/en/docs/reference/_index.md
index 8b0faf5e91..619430875e 100644
--- a/content/en/docs/reference/_index.md
+++ b/content/en/docs/reference/_index.md
@@ -5,16 +5,16 @@ approvers:
linkTitle: "Reference"
main_menu: true
weight: 70
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
This section of the Kubernetes documentation contains references.
-{{% /capture %}}
-{{% capture body %}}
+
+
## API Reference
@@ -52,4 +52,4 @@ client libraries:
An archive of the design docs for Kubernetes functionality. Good starting points are [Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and [Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals).
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/access-authn-authz/abac.md b/content/en/docs/reference/access-authn-authz/abac.md
index 40c56a985c..3810942660 100644
--- a/content/en/docs/reference/access-authn-authz/abac.md
+++ b/content/en/docs/reference/access-authn-authz/abac.md
@@ -5,15 +5,15 @@ reviewers:
- deads2k
- liggitt
title: Using ABAC Authorization
-content_template: templates/concept
+content_type: concept
weight: 80
---
-{{% capture overview %}}
+
Attribute-based access control (ABAC) defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Policy File Format
To enable `ABAC` mode, specify `--authorization-policy-file=SOME_FILENAME` and `--authorization-mode=ABAC` on startup.
@@ -152,5 +152,5 @@ privilege to the API using ABAC, you would add this line to your policy file:
The apiserver will need to be restarted to pickup the new policy lines.
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md
index a254e43a84..874bcbeb1c 100644
--- a/content/en/docs/reference/access-authn-authz/admission-controllers.md
+++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md
@@ -7,15 +7,15 @@ reviewers:
- janetkuo
- thockin
title: Using Admission Controllers
-content_template: templates/concept
+content_type: concept
weight: 30
---
-{{% capture overview %}}
+
This page provides an overview of Admission Controllers.
-{{% /capture %}}
-{{% capture body %}}
+
+
## What are they?
An admission controller is a piece of code that intercepts requests to the
@@ -32,6 +32,8 @@ which are configured in the API.
Admission controllers may be "validating", "mutating", or both. Mutating
controllers may modify the objects they admit; validating controllers may not.
+Admission controllers limit requests to create, delete, modify or connect to (proxy). They do not support read requests.
+
The admission control process proceeds in two phases. In the first phase,
mutating admission controllers are run. In the second phase, validating
admission controllers are run. Note again that some of the controllers are
@@ -97,7 +99,9 @@ NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority
## What does each admission controller do?
-### AlwaysAdmit {#alwaysadmit} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
+### AlwaysAdmit {#alwaysadmit}
+
+{{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
This admission controller allows all pods into the cluster. It is deprecated because its behavior is the same as if there were no admission controller at all.
@@ -111,7 +115,9 @@ scheduled onto the right node), without any authorization check against the imag
is enabled, images are always pulled prior to starting containers, which means valid credentials are
required.
-### AlwaysDeny {#alwaysdeny} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
+### AlwaysDeny {#alwaysdeny}
+
+{{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
Rejects all requests. AlwaysDeny is DEPRECATED as no real meaning.
@@ -162,7 +168,9 @@ if the pods don't already have toleration for taints
`node.kubernetes.io/not-ready:NoExecute` or
`node.alpha.kubernetes.io/unreachable:NoExecute`.
-### DenyExecOnPrivileged {#denyexeconprivileged} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
+### DenyExecOnPrivileged {#denyexeconprivileged}
+
+{{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
This admission controller will intercept all requests to exec a command in a pod if that pod has a privileged container.
@@ -173,7 +181,9 @@ Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypol
which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods
is recommended instead.
-### DenyEscalatingExec {#denyescalatingexec} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
+### DenyEscalatingExec {#denyescalatingexec}
+
+{{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
This admission controller will deny exec and attach commands to pods that run with escalated privileges that
allow host access. This includes pods that run as privileged, have access to the host IPC namespace, and
@@ -185,7 +195,9 @@ Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypol
which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods
is recommended instead.
-### EventRateLimit {#eventratelimit} {{< feature-state for_k8s_version="v1.13" state="alpha" >}}
+### EventRateLimit {#eventratelimit}
+
+{{< feature-state for_k8s_version="v1.13" state="alpha" >}}
This admission controller mitigates the problem where the API server gets flooded by
event requests. The cluster admin can specify event rate limits by:
@@ -444,7 +456,9 @@ applies a 0.1 CPU requirement to all Pods in the `default` namespace.
See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details.
-### MutatingAdmissionWebhook {#mutatingadmissionwebhook} {{< feature-state for_k8s_version="v1.13" state="beta" >}}
+### MutatingAdmissionWebhook {#mutatingadmissionwebhook}
+
+{{< feature-state for_k8s_version="v1.13" state="beta" >}}
This admission controller calls any mutating webhooks which match the request. Matching
webhooks are called in serial; each one may modify the object if it desires.
@@ -535,7 +549,9 @@ This admission controller also protects the access to `metadata.ownerReferences[
of an object, so that only users with "update" permission to the `finalizers`
subresource of the referenced *owner* can change it.
-### PersistentVolumeLabel {#persistentvolumelabel} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
+### PersistentVolumeLabel {#persistentvolumelabel}
+
+{{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
This admission controller automatically attaches region or zone labels to PersistentVolumes
as defined by the cloud provider (for example, GCE or AWS).
@@ -610,7 +626,7 @@ node selector.
2. If the namespace lacks such an annotation, use the `clusterDefaultNodeSelector` defined in the `PodNodeSelector`
plugin configuration file as the node selector.
3. Evaluate the pod's node selector against the namespace node selector for conflicts. Conflicts result in rejection.
-4. Evaluate the pod's node selector against the namespace-specific whitelist defined the plugin configuration file.
+4. Evaluate the pod's node selector against the namespace-specific allowed selector defined the plugin configuration file.
Conflicts result in rejection.
{{< note >}}
@@ -672,15 +688,15 @@ for more information.
The PodTolerationRestriction admission controller verifies any conflict between tolerations of a pod and the tolerations of its namespace.
It rejects the pod request if there is a conflict.
It then merges the tolerations annotated on the namespace into the tolerations of the pod.
-The resulting tolerations are checked against a whitelist of tolerations annotated to the namespace.
+The resulting tolerations are checked against a list of allowed tolerations annotated to the namespace.
If the check succeeds, the pod request is admitted otherwise it is rejected.
-If the namespace of the pod does not have any associated default tolerations or a whitelist of
-tolerations annotated, the cluster-level default tolerations or cluster-level whitelist of tolerations are used
+If the namespace of the pod does not have any associated default tolerations or allowed
+tolerations annotated, the cluster-level default tolerations or cluster-level list of allowed tolerations are used
instead if they are specified.
Tolerations to a namespace are assigned via the `scheduler.alpha.kubernetes.io/defaultTolerations` annotation key.
-The whitelist can be added via the `scheduler.alpha.kubernetes.io/tolerationsWhitelist` annotation key.
+The list of allowed tolerations can be added via the `scheduler.alpha.kubernetes.io/tolerationsWhitelist` annotation key.
Example for namespace annotations:
@@ -706,7 +722,9 @@ objects in your Kubernetes deployment, you MUST use this admission controller to
See the [resourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for more details.
-### RuntimeClass {#runtimeclass} {{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+### RuntimeClass {#runtimeclass}
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
For [RuntimeClass](/docs/concepts/containers/runtime-class/) definitions which describe an overhead associated with running a pod,
this admission controller will set the pod.Spec.Overhead field accordingly.
@@ -727,11 +745,15 @@ We strongly recommend using this admission controller if you intend to make use
The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection` finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV). In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed from the PVC or PV by PVC or PV Protection Controller. Refer to the [Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection) for more detailed information.
-### TaintNodesByCondition {#taintnodesbycondition} {{< feature-state for_k8s_version="v1.12" state="beta" >}}
+### TaintNodesByCondition {#taintnodesbycondition}
+
+{{< feature-state for_k8s_version="v1.12" state="beta" >}}
This admission controller {{< glossary_tooltip text="taints" term_id="taint" >}} newly created Nodes as `NotReady` and `NoSchedule`. That tainting avoids a race condition that could cause Pods to be scheduled on new Nodes before their taints were updated to accurately reflect their reported conditions.
-### ValidatingAdmissionWebhook {#validatingadmissionwebhook} {{< feature-state for_k8s_version="v1.13" state="beta" >}}
+### ValidatingAdmissionWebhook {#validatingadmissionwebhook}
+
+{{< feature-state for_k8s_version="v1.13" state="beta" >}}
This admission controller calls any validating webhooks which match the request. Matching
webhooks are called in parallel; if any of them rejects the request, the request
@@ -771,6 +793,4 @@ phase, and therefore is the last admission controller to run.
in the mutating phase.
For earlier versions, there was no concept of validating versus mutating and the
-admission controllers ran in the exact order specified.
-
-{{% /capture %}}
+admission controllers ran in the exact order specified.
\ No newline at end of file
diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md
index b240fb4e22..973c605127 100644
--- a/content/en/docs/reference/access-authn-authz/authentication.md
+++ b/content/en/docs/reference/access-authn-authz/authentication.md
@@ -6,15 +6,15 @@ reviewers:
- deads2k
- liggitt
title: Authenticating
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
This page provides an overview of authenticating.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Users in Kubernetes
All Kubernetes clusters have two categories of users: service accounts managed
@@ -26,6 +26,8 @@ even a file with a list of usernames and passwords. In this regard, _Kubernetes
does not have objects which represent normal user accounts._ Normal users
cannot be added to a cluster through an API call.
+Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this.
+
In contrast, service accounts are users managed by the Kubernetes API. They are
bound to specific namespaces, and created automatically by the API server or
manually through API calls. Service accounts are tied to a set of credentials
@@ -860,4 +862,4 @@ RFC3339 timestamp. Presence or absence of an expiry has the following impact:
}
}
```
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/access-authn-authz/authorization.md b/content/en/docs/reference/access-authn-authz/authorization.md
index 3a942266fc..74c433b8ee 100644
--- a/content/en/docs/reference/access-authn-authz/authorization.md
+++ b/content/en/docs/reference/access-authn-authz/authorization.md
@@ -5,16 +5,16 @@ reviewers:
- deads2k
- liggitt
title: Authorization Overview
-content_template: templates/concept
+content_type: concept
weight: 60
---
-{{% capture overview %}}
+
Learn more about Kubernetes authorization, including details about creating
policies using the supported authorization modules.
-{{% /capture %}}
-{{% capture body %}}
+
+
In Kubernetes, you must be authenticated (logged in) before your request can be
authorized (granted permission to access). For information about authentication,
see [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/).
@@ -197,9 +197,10 @@ namespace can: read all secrets in the namespace; read all config maps in the
namespace; and impersonate any service account in the namespace and take any
action the account could take. This applies regardless of authorization mode.
{{< /caution >}}
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/).
* To learn more about Admission Control, see [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/).
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md b/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md
index c8c55c08d6..542b5267be 100644
--- a/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md
+++ b/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md
@@ -2,11 +2,11 @@
reviewers:
- jbeda
title: Authenticating with Bootstrap Tokens
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
@@ -16,9 +16,9 @@ to support [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), but can be u
for users that wish to start clusters without `kubeadm`. It is also built to
work, via RBAC policy, with the [Kubelet TLS
Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) system.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Bootstrap Tokens Overview
Bootstrap Tokens are defined with a specific type
@@ -188,4 +188,4 @@ client relying on the signature to bootstrap TLS trust.
Consult the [kubeadm implementation details](/docs/reference/setup-tools/kubeadm/implementation-details/)
section for more information.
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md
index 3e81215dd8..576cde3d88 100644
--- a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md
+++ b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md
@@ -4,11 +4,11 @@ reviewers:
- mikedanese
- munnerz
title: Certificate Signing Requests
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
@@ -21,9 +21,9 @@ A CertificateSigningRequest (CSR) resource is used to request that a certificate
by a denoted signer, after which the request may be approved or denied before
finally being signed.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Request signing process
The _CertificateSigningRequest_ resource type allows a client to ask for an X.509 certificate
@@ -48,7 +48,7 @@ The CertificateSigningRequest `status.certificate` field is empty until the sign
Once the `status.certificate` field has been populated, the request has been completed and clients can now
fetch the signed certificate PEM data from the CertificateSigningRequest resource.
-Signers can instead deny certificate signing if the approval conditions are not met.
+The signers can instead deny certificate signing if the approval conditions are not met.
In order to reduce the number of old CertificateSigningRequest resources left in a cluster, a garbage collection
controller runs periodically. The garbage collection removes CertificateSigningRequests that have not changed
@@ -67,10 +67,10 @@ This includes:
1. **Permitted subjects**: any restrictions on and behavior when a disallowed subject is requested.
1. **Permitted x509 extensions**: including IP subjectAltNames, DNS subjectAltNames, Email subjectAltNames, URI subjectAltNames etc, and behavior when a disallowed extension is requested.
1. **Permitted key usages / extended key usages**: any restrictions on and behavior when usages different than the signer-determined usages are specified in the CSR.
-1. **Expiration/certificate lifetime**: whether it is fixed by the signer, configurable by the admin, determined by the CSR object etc and behavior if an expiration different than the signer-determined expiration is specified in the CSR.
+1. **Expiration/certificate lifetime**: whether it is fixed by the signer, configurable by the admin, determined by the CSR object etc and the behavior when an expiration is different than the signer-determined expiration that is specified in the CSR.
1. **CA bit allowed/disallowed**: and behavior if a CSR contains a request a for a CA certificate when the signer does not permit it.
-Commonly, the `status.certificate` field contains a single PEM-encoded X.509 certificate once the CSR is approved and the certificate is issued. Some signers store multiple certificates into the `status.certificate` field. In that case, the documentation for the signer should specify the meaning of additional certificates; for example, this might be certificate plus intermediates to be presented during TLS handshakes.
+Commonly, the `status.certificate` field contains a single PEM-encoded X.509 certificate once the CSR is approved and the certificate is issued. Some signers store multiple certificates into the `status.certificate` field. In that case, the documentation for the signer should specify the meaning of additional certificates; for example, this might be the certificate plus intermediates to be presented during TLS handshakes.
### Kubernetes signers
@@ -88,19 +88,18 @@ Kubernetes provides built-in signers that each have a well-known `signerName`:
1. `kubernetes.io/kube-apiserver-client-kubelet`: signs client certificates that will be honored as client-certs by the
kube-apiserver.
May be auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
- 1. Trust distribution: signed certificates must be honored as client-certificates by the kube-apiserver. The CA bundle
+ 1. Trust distribution: signed certificates must be honored as client-certificates by the kube-apiserver. The CA bundle
is not distributed by any other means.
1. Permitted subjects - organizations are exactly `[]string{"system:nodes"}`, common name starts with `"system:node:"`
- 1. Permitted x509 extensions - honors key usage extensions, forbids subjectAltName extensions, drops other extensions.
+ 1. Permitted x509 extensions - honors key usage extensions, forbids subjectAltName extensions and drops other extensions.
1. Permitted key usages - exactly `[]string{"key encipherment", "digital signature", "client auth"}`
- 1. Expiration/certificate lifetime - minimum of CSR signer or request. Sanity of the time is the concern of the signer.
+ 1. Expiration/certificate lifetime - minimum of CSR signer or request. The signer is responsible for checking that the certificate lifetime is valid and permissible.
1. CA bit allowed/disallowed - not allowed.
1. `kubernetes.io/kubelet-serving`: signs serving certificates that are honored as a valid kubelet serving certificate
by the kube-apiserver, but has no other guarantees.
Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
- 1. Trust distribution: signed certificates must be honored by the kube-apiserver as valid to terminate connections to a kubelet.
- The CA bundle is not distributed by any other means.
+ 1. Trust distribution: signed certificates must be honored by the kube-apiserver as valid to terminate connections to a kubelet. The CA bundle is not distributed by any other means.
1. Permitted subjects - organizations are exactly `[]string{"system:nodes"}`, common name starts with `"system:node:"`
1. Permitted x509 extensions - honors key usage and DNSName/IPAddress subjectAltName extensions, forbids EmailAddress and URI subjectAltName extensions, drops other extensions. At least one DNS or IP subjectAltName must be present.
1. Permitted key usages - exactly `[]string{"key encipherment", "digital signature", "server auth"}`
@@ -108,13 +107,13 @@ Kubernetes provides built-in signers that each have a well-known `signerName`:
1. CA bit allowed/disallowed - not allowed.
1. `kubernetes.io/legacy-unknown`: has no guarantees for trust at all. Some distributions may honor these as client
- certs, but that behavior is not standard Kubernetes behavior.
+ certs, but that behavior is non-standard Kubernetes behavior.
Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
1. Trust distribution: None. There is no standard trust or distribution for this signer in a Kubernetes cluster.
1. Permitted subjects - any
1. Permitted x509 extensions - honors subjectAltName and key usage extensions and discards other extensions.
1. Permitted key usages - any
- 1. Expiration/certificate lifetime - minimum of CSR signer or request. Sanity of the time is the concern of the signer.
+ 1. Expiration/certificate lifetime - minimum of CSR signer or request. The signer is responsible for checking that the certificate lifetime is valid and permissible.
1. CA bit allowed/disallowed - not allowed.
{{< note >}}
@@ -226,6 +225,101 @@ rules:
- sign
```
+## Normal User
+
+There are a few steps are required in order to get normal user to be able to authenticate and invoke API. First, this user must have certificate issued by the Kubernetes Cluster, and then present that Certificate into the API call as the Certificate Header, or through the kubectl.
+
+### Create Private Key
+
+The following scripts show how to generate PKI private key and CSR. It is important to set CN and O attribute of the CSR. CN is the name of the user and O is the group that this user will belong to. You can refer to [RBAC](/docs/reference/access-authn-authz/rbac/) for standard groups.
+
+```
+openssl genrsa -out john.key 2048
+openssl req -new -key john.key -out john.csr
+```
+
+### Create Certificate Request Kubernetes Object
+
+Create a CertificateSigningRequest and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the CertificateSigningRequest.
+
+```
+cat <
This page provides an overview of controlling access to the Kubernetes API.
-{{% /capture %}}
-{{% capture body %}}
+
+
Users [access the API](/docs/tasks/access-application-cluster/access-cluster/) using `kubectl`,
client libraries, or by making REST requests. Both human users and
[Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/) can be
@@ -23,7 +23,7 @@ following diagram:
## Transport Security
-In a typical Kubernetes cluster, the API serves on port 6443.
+In a typical Kubernetes cluster, the API serves on port 443.
The API server presents a certificate. This certificate is
often self-signed, so `$USER/.kube/config` on the user's machine typically
contains the root certificate for the API server's certificate, which when specified
@@ -63,9 +63,9 @@ users in its object store.
## Authorization
-After the request is authenticated as coming from a specific user, the request must be authorized. This is shown as step **2** in the diagram.
+After the request is authenticated as coming from a specific user, the request must be authorized. This is shown as step **2** in the diagram.
-A request must include the username of the requester, the requested action, and the object affected by the action. The request is authorized if an existing policy declares that the user has permissions to complete the requested action.
+A request must include the username of the requester, the requested action, and the object affected by the action. The request is authorized if an existing policy declares that the user has permissions to complete the requested action.
For example, if Bob has the policy below, then he can read pods only in the namespace `projectCaribou`:
@@ -97,7 +97,7 @@ If Bob makes the following request, the request is authorized because he is allo
}
}
```
-If Bob makes a request to write (`create` or `update`) to the objects in the `projectCaribou` namespace, his authorization is denied. If Bob makes a request to read (`get`) objects in a different namespace such as `projectFish`, then his authorization is denied.
+If Bob makes a request to write (`create` or `update`) to the objects in the `projectCaribou` namespace, his authorization is denied. If Bob makes a request to read (`get`) objects in a different namespace such as `projectFish`, then his authorization is denied.
Kubernetes authorization requires that you use common REST attributes to interact with existing organization-wide or cloud-provider-wide access control systems. It is important to use REST formatting because these control systems might interact with other APIs besides the Kubernetes API.
@@ -110,10 +110,11 @@ To learn more about Kubernetes authorization, including details about creating p
Admission Control Modules are software modules that can modify or reject requests.
In addition to the attributes available to Authorization Modules, Admission
-Control Modules can access the contents of the object that is being created or updated.
-They act on objects being created, deleted, updated or connected (proxy), but not reads.
+Control Modules can access the contents of the object that is being created or modified.
-Multiple admission controllers can be configured. Each is called in order.
+Admission controllers act on requests that create, modify, delete, or connect to (proxy) an object.
+Admission controllers do not act on requests that merely read objects.
+When multiple admission controllers are configured, they are called in order.
This is shown as step **3** in the diagram.
@@ -161,4 +162,4 @@ When the cluster is created by `kube-up.sh`, on Google Compute Engine (GCE),
and on several other cloud providers, the API server serves on port 443. On
GCE, a firewall rule is configured on the project to allow external HTTPS
access to the API. Other cluster setup methods vary.
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
index c99ff2b35c..718c9d1147 100644
--- a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
+++ b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
@@ -7,17 +7,17 @@ reviewers:
- liggitt
- jpbetz
title: Dynamic Admission Control
-content_template: templates/concept
+content_type: concept
weight: 40
---
-{{% capture overview %}}
+
In addition to [compiled-in admission plugins](/docs/reference/access-authn-authz/admission-controllers/),
admission plugins can be developed as extensions and run as webhooks configured at runtime.
This page describes how to build, configure, use, and monitor admission webhooks.
-{{% /capture %}}
-{{% capture body %}}
+
+
## What are admission webhooks?
Admission webhooks are HTTP callbacks that receive admission requests and do
@@ -549,7 +549,7 @@ Example of a minimal response from a webhook to forbid a request:
When rejecting a request, the webhook can customize the http code and message returned to the user using the `status` field.
The specified status object is returned to the user.
-See the [API documentation](/docs/reference/generated/kubernetes-api/v1.14/#status-v1-meta) for details about the status type.
+See the [API documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#status-v1-meta) for details about the status type.
Example of a response to forbid a request, customizing the HTTP status code and message presented to the user:
{{< tabs name="AdmissionReview_response_forbid_details" >}}
{{% tab name="admission.k8s.io/v1" %}}
@@ -1588,4 +1588,4 @@ If your admission webhooks don't intend to modify the behavior of the Kubernetes
plane, exclude the `kube-system` namespace from being intercepted using a
[`namespaceSelector`](#matching-requests-namespaceselector).
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/access-authn-authz/node.md b/content/en/docs/reference/access-authn-authz/node.md
index 6c0e2f3e99..439d97ff84 100644
--- a/content/en/docs/reference/access-authn-authz/node.md
+++ b/content/en/docs/reference/access-authn-authz/node.md
@@ -5,15 +5,15 @@ reviewers:
- liggitt
- ericchiang
title: Using Node Authorization
-content_template: templates/concept
+content_type: concept
weight: 90
---
-{{% capture overview %}}
+
Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by kubelets.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Overview
The Node authorizer allows a kubelet to perform API operations. This includes:
@@ -96,4 +96,4 @@ In 1.8, the binding will not be created at all.
When using RBAC, the `system:node` cluster role will continue to be created,
for compatibility with deployment methods that bind other users or groups to that role.
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md
index 7034f9a18e..20b1224e59 100644
--- a/content/en/docs/reference/access-authn-authz/rbac.md
+++ b/content/en/docs/reference/access-authn-authz/rbac.md
@@ -4,17 +4,17 @@ reviewers:
- deads2k
- liggitt
title: Using RBAC Authorization
-content_template: templates/concept
-aliases: [../../../rbac/]
+content_type: concept
+aliases: [/rbac/]
weight: 70
---
-{{% capture overview %}}
+
Role-based access control (RBAC) is a method of regulating access to computer or
network resources based on the roles of individual users within your organization.
-{{% /capture %}}
-{{% capture body %}}
+
+
RBAC authorization uses the `rbac.authorization.k8s.io`
{{< glossary_tooltip text="API group" term_id="api-group" >}} to drive authorization
decisions, allowing you to dynamically configure policies through the Kubernetes API.
@@ -1209,5 +1209,3 @@ kubectl create clusterrolebinding permissive-binding \
After you have transitioned to use RBAC, you should adjust the access controls
for your cluster to ensure that these meet your information security needs.
-
-{{% /capture %}}
diff --git a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md
index 5c2dd3ddc5..6d2cf76573 100644
--- a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md
+++ b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md
@@ -5,19 +5,19 @@ reviewers:
- lavalamp
- liggitt
title: Managing Service Accounts
-content_template: templates/concept
+content_type: concept
weight: 50
---
-{{% capture overview %}}
+
This is a Cluster Administrator guide to service accounts. It assumes knowledge of
the [User Guide to Service Accounts](/docs/user-guide/service-accounts).
Support for authorization and user accounts is planned but incomplete. Sometimes
incomplete features are referred to in order to better describe service accounts.
-{{% /capture %}}
-{{% capture body %}}
+
+
## User accounts versus service accounts
Kubernetes distinguishes between the concept of a user account and a service account
@@ -115,4 +115,4 @@ kubectl delete secret mysecretname
Service Account Controller manages ServiceAccount inside namespaces, and ensures
a ServiceAccount named "default" exists in every active namespace.
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/access-authn-authz/webhook.md b/content/en/docs/reference/access-authn-authz/webhook.md
index 3f667fa5ef..69be02ff76 100644
--- a/content/en/docs/reference/access-authn-authz/webhook.md
+++ b/content/en/docs/reference/access-authn-authz/webhook.md
@@ -5,15 +5,15 @@ reviewers:
- deads2k
- liggitt
title: Webhook Mode
-content_template: templates/concept
+content_type: concept
weight: 95
---
-{{% capture overview %}}
+
A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen.
-{{% /capture %}}
-{{% capture body %}}
+
+
When specified, mode `Webhook` causes Kubernetes to query an outside REST
service when determining user privileges.
@@ -164,8 +164,8 @@ Access to non-resource paths are sent as:
}
```
-Non-resource paths include: `/api`, `/apis`, `/metrics`, `/resetMetrics`,
-`/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, and
+Non-resource paths include: `/api`, `/apis`, `/metrics`,
+`/logs`, `/debug`, `/healthz`, `/livez`, `/openapi/v2`, `/readyz`, and
`/version.` Clients require access to `/api`, `/api/*`, `/apis`, `/apis/*`,
and `/version` to discover what resources and versions are present on the server.
Access to other non-resource paths can be disallowed without restricting access
@@ -174,6 +174,3 @@ to the REST api.
For further documentation refer to the authorization.v1beta1 API objects and
[webhook.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go).
-{{% /capture %}}
-
-
diff --git a/content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md b/content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md
index ee8d7f1ed1..982eb0993e 100644
--- a/content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md
+++ b/content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md
@@ -1,10 +1,11 @@
---
title: cloud-controller-manager
-content_template: templates/tool-reference
+content_type: tool-reference
weight: 30
---
-{{% capture synopsis %}}
+## {{% heading "synopsis" %}}
+
The Cloud controller manager is a daemon that embeds
@@ -14,9 +15,10 @@ the cloud specific control loops shipped with Kubernetes.
cloud-controller-manager [flags]
```
-{{% /capture %}}
-{{% capture options %}}
+
+## {{% heading "options" %}}
+
@@ -534,5 +536,5 @@ cloud-controller-manager [flags]
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md
index 752ee40f7d..6a9b6c1ced 100644
--- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md
@@ -1,17 +1,17 @@
---
weight: 10
title: Feature Gates
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
This page contains an overview of the various feature gates an administrator
can specify on different Kubernetes components.
See [feature stages](#feature-stages) for an explanation of the stages for a feature.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Overview
Feature gates are a set of key=value pairs that describe Kubernetes features.
@@ -105,6 +105,7 @@ different Kubernetes components.
| `HugePageStorageMediumSize` | `false` | Alpha | 1.18 | |
| `HyperVContainer` | `false` | Alpha | 1.10 | |
| `ImmutableEphemeralVolumes` | `false` | Alpha | 1.18 | |
+| `IPv6DualStack` | `false` | Alpha | 1.16 | |
| `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 |
| `KubeletPodResources` | `true` | Beta | 1.15 | |
| `LegacyNodeRoleBehavior` | `true` | Alpha | 1.16 | |
@@ -133,7 +134,8 @@ different Kubernetes components.
| `ServerSideApply` | `true` | Beta | 1.16 | |
| `ServiceNodeExclusion` | `false` | Alpha | 1.8 | |
| `ServiceTopology` | `false` | Alpha | 1.17 | |
-| `StartupProbe` | `false` | Alpha | 1.16 | |
+| `StartupProbe` | `false` | Alpha | 1.16 | 1.17 |
+| `StartupProbe` | `true` | Beta | 1.18 | |
| `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 |
| `StorageVersionHash` | `true` | Beta | 1.15 | |
| `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 |
@@ -510,8 +512,9 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `WinDSR`: Allows kube-proxy to create DSR loadbalancers for Windows.
- `WinOverlay`: Allows kube-proxy to run in overlay mode for Windows.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* The [deprecation policy](/docs/reference/using-api/deprecation-policy/) for Kubernetes explains
the project's approach to removing features and components.
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md b/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
index 6e9454dc49..01cf6a87b8 100644
--- a/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
+++ b/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
@@ -1,10 +1,11 @@
---
title: kube-apiserver
-content_template: templates/tool-reference
+content_type: tool-reference
weight: 30
---
-{{% capture synopsis %}}
+## {{% heading "synopsis" %}}
+
The Kubernetes API server validates and configures data
@@ -16,9 +17,10 @@ cluster's shared state through which all other components interact.
kube-apiserver [flags]
```
-{{% /capture %}}
-{{% capture options %}}
+
+## {{% heading "options" %}}
+
@@ -897,5 +899,5 @@ kube-controller-manager [flags]
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/command-line-tools-reference/kube-proxy.md b/content/en/docs/reference/command-line-tools-reference/kube-proxy.md
index 1ad3f6ee15..535bd81aa6 100644
--- a/content/en/docs/reference/command-line-tools-reference/kube-proxy.md
+++ b/content/en/docs/reference/command-line-tools-reference/kube-proxy.md
@@ -1,10 +1,11 @@
---
title: kube-proxy
-content_template: templates/tool-reference
+content_type: tool-reference
weight: 30
---
-{{% capture synopsis %}}
+## {{% heading "synopsis" %}}
+
The Kubernetes network proxy runs on each node. This
@@ -19,9 +20,10 @@ with the apiserver API to configure the proxy.
kube-proxy [flags]
```
-{{% /capture %}}
-{{% capture options %}}
+
+## {{% heading "options" %}}
+
@@ -336,5 +338,5 @@ kube-proxy [flags]
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md b/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
index f807c5d024..d510610140 100644
--- a/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
+++ b/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
@@ -1,10 +1,11 @@
---
title: kube-scheduler
-content_template: templates/tool-reference
+content_type: tool-reference
weight: 30
---
-{{% capture synopsis %}}
+## {{% heading "synopsis" %}}
+
The Kubernetes scheduler is a policy-rich, topology-aware,
@@ -20,9 +21,10 @@ for more information about scheduling and the kube-scheduler component.
kube-scheduler [flags]
```
-{{% /capture %}}
-{{% capture options %}}
+
+## {{% heading "options" %}}
+
@@ -512,5 +514,5 @@ kube-scheduler [flags]
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md b/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
index 2e408ff18b..b2a99213ed 100644
--- a/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
+++ b/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
@@ -4,7 +4,6 @@ reviewers:
title: Kubelet authentication/authorization
---
-{{< toc >}}
## Overview
diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
index 6269a3ec5a..0daa490276 100644
--- a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
+++ b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
@@ -5,28 +5,28 @@ reviewers:
- smarterclayton
- awly
title: TLS bootstrapping
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
In a Kubernetes cluster, the components on the worker nodes - kubelet and kube-proxy - need to communicate with Kubernetes master components, specifically kube-apiserver.
In order to ensure that communication is kept private, not interfered with, and ensure that each component of the cluster is talking to another trusted component, we strongly
recommend using client TLS certificates on nodes.
-The normal process of bootstrapping these components, especially worker nodes that need certificates so they can communicate safely with kube-apiserver,
-can be a challenging process as it is often outside of the scope of Kubernetes and requires significant additional work.
+The normal process of bootstrapping these components, especially worker nodes that need certificates so they can communicate safely with kube-apiserver,
+can be a challenging process as it is often outside of the scope of Kubernetes and requires significant additional work.
This in turn, can make it challenging to initialize or scale a cluster.
In order to simplify the process, beginning in version 1.4, Kubernetes introduced a certificate request and signing API to simplify the process. The proposal can be
found [here](https://github.com/kubernetes/kubernetes/pull/20439).
This document describes the process of node initialization, how to set up TLS client certificate bootstrapping for
-kubelets, and how it works.
+kubelets, and how it works.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Initialization Process
When a worker node starts up, the kubelet does the following:
@@ -90,7 +90,7 @@ In addition, you need your Kubernetes Certificate Authority (CA).
As without bootstrapping, you will need a Certificate Authority (CA) key and certificate. As without bootstrapping, these will be used
to sign the kubelet certificate. As before, it is your responsibility to distribute them to master nodes.
-For the purposes of this document, we will assume these have been distributed to master nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key).
+For the purposes of this document, we will assume these have been distributed to master nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key).
We will refer to these as "Kubernetes CA certificate and key".
All Kubernetes components that use these certificates - kubelet, kube-apiserver, kube-controller-manager - assume the key and certificate to be PEM-encoded.
@@ -98,7 +98,7 @@ All Kubernetes components that use these certificates - kubelet, kube-apiserver,
## kube-apiserver configuration
The kube-apiserver has several requirements to enable TLS bootstrapping:
-* Recognizing CA that signs the client certificate
+* Recognizing CA that signs the client certificate
* Authenticating the bootstrapping kubelet to the `system:bootstrappers` group
* Authorize the bootstrapping kubelet to create a certificate signing request (CSR)
@@ -120,13 +120,13 @@ of provisioning.
1. [Bootstrap Tokens](#bootstrap-tokens)
2. [Token authentication file](#token-authentication-file)
-Bootstrap tokens are a simpler and more easily managed method to authenticate kubelets, and do not require any additional flags when starting kube-apiserver.
+Bootstrap tokens are a simpler and more easily managed method to authenticate kubelets, and do not require any additional flags when starting kube-apiserver.
Using bootstrap tokens is currently __beta__ as of Kubernetes version 1.12.
Whichever method you choose, the requirement is that the kubelet be able to authenticate as a user with the rights to:
1. create and retrieve CSRs
-2. be automatically approved to request node client certificates, if automatic approval is enabled.
+2. be automatically approved to request node client certificates, if automatic approval is enabled.
A kubelet authenticating using bootstrap tokens is authenticated as a user in the group `system:bootstrappers`, which is the standard method to use.
@@ -152,7 +152,7 @@ From the kube-apiserver's perspective, however, the bootstrap token is special.
and grants anyone authenticating with that token special bootstrap rights, notably treating them as a member of the `system:bootstrappers` group. This fulfills a basic requirement
for TLS bootstrapping.
-The details for creating the secret are available [here](/docs/reference/access-authn-authz/bootstrap-tokens/).
+The details for creating the secret are available [here](/docs/reference/access-authn-authz/bootstrap-tokens/).
If you want to use bootstrap tokens, you must enable it on kube-apiserver with the flag:
@@ -161,7 +161,7 @@ If you want to use bootstrap tokens, you must enable it on kube-apiserver with t
```
#### Token authentication file
-kube-apiserver has an ability to accept tokens as authentication.
+kube-apiserver has an ability to accept tokens as authentication.
These tokens are arbitrary but should represent at least 128 bits of entropy derived
from a secure random number generator (such as `/dev/urandom` on most modern Linux
systems). There are multiple ways you can generate a token. For example:
@@ -252,8 +252,8 @@ RBAC permissions to the correct group.
There are two distinct sets of permissions:
-* `nodeclient`: If a node is creating a new certificate for a node, then it does not have a certificate yet. It is authenticating using one of the tokens listed above, and thus is part of the group `system:bootstrappers`.
-* `selfnodeclient`: If a node is renewing its certificate, then it already has a certificate (by definition), which it uses continuously to authenticate as part of the group `system:nodes`.
+* `nodeclient`: If a node is creating a new certificate for a node, then it does not have a certificate yet. It is authenticating using one of the tokens listed above, and thus is part of the group `system:bootstrappers`.
+* `selfnodeclient`: If a node is renewing its certificate, then it already has a certificate (by definition), which it uses continuously to authenticate as part of the group `system:nodes`.
To enable the kubelet to request and receive a new certificate, create a `ClusterRoleBinding` that binds the group in which the bootstrapping node is a member `system:bootstrappers` to the `ClusterRole` that grants it permission, `system:certificates.k8s.io:certificatesigningrequests:nodeclient`:
@@ -273,7 +273,7 @@ roleRef:
apiGroup: rbac.authorization.k8s.io
```
-To enable the kubelet to renew its own client certificate, create a `ClusterRoleBinding` that binds the group in which the fully functioning node is a member `system:nodes` to the `ClusterRole` that
+To enable the kubelet to renew its own client certificate, create a `ClusterRoleBinding` that binds the group in which the fully functioning node is a member `system:nodes` to the `ClusterRole` that
grants it permission, `system:certificates.k8s.io:certificatesigningrequests:selfnodeclient`:
```yml
@@ -382,7 +382,7 @@ To secure these, the kubelet can do one of:
* request serving certificates from the cluster server, via the CSR API
The client certificate provided by TLS bootstrapping is signed, by default, for `client auth` only, and thus cannot
-be used as serving certificates, or `server auth`.
+be used as serving certificates, or `server auth`.
However, you _can_ enable its server certificate, at least partially, via certificate rotation.
@@ -443,15 +443,3 @@ also manually approve certificate requests using kubectl. An administrator can
list CSRs with `kubectl get csr` and describe one in detail with `kubectl
describe csr `. An administrator can approve or deny a CSR with `kubectl
certificate approve ` and `kubectl certificate deny `.
-
-
-## Limits
-Although Kubernetes supports running control plane master components like kube-apiserver and kube-controller-manager in containers, and even as `Pod`s in a kubelet, as of this writing, you cannot both TLS Bootstrap a kubelet and run master plane components on it.
-
-The reason for this limitation is that the kubelet attempts to bootstrap communication with kube-apiserver _before_ starting any pods, even static ones define on disk and referenced via the kubelet option `--pod-manifest-path=`. Trying to do both TLS Bootstrapping and master components in kubelet leads to a race condition: kubelet needs to communicate to kube-apiserver to request certificates, yet requires those certificates to be available to start kube-apiserver.
-
-An issue is open referencing this [here](https://github.com/kubernetes/kubernetes/issues/68686).
-
-
-
-{{% /capture %}}
diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet.md b/content/en/docs/reference/command-line-tools-reference/kubelet.md
index 595ef138fc..54dc1a84d9 100644
--- a/content/en/docs/reference/command-line-tools-reference/kubelet.md
+++ b/content/en/docs/reference/command-line-tools-reference/kubelet.md
@@ -1,10 +1,11 @@
---
title: kubelet
-content_template: templates/tool-reference
+content_type: tool-reference
weight: 28
---
-{{% capture synopsis %}}
+## {{% heading "synopsis" %}}
+
The kubelet is the primary "node agent" that runs on each
node. It can register the node with the apiserver using one of: the hostname; a flag to override the hostname; or specific logic for a cloud provider.
@@ -24,10 +25,11 @@ HTTP server: The kubelet can also listen for HTTP and respond to a simple API (u
kubelet [flags]
```
-{{% /capture %}}
-{{% capture options %}}
+
+## {{% heading "options" %}}
+
@@ -1265,4 +1267,4 @@ kubelet [flags]
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/glossary/aggregation-layer.md b/content/en/docs/reference/glossary/aggregation-layer.md
index e5bafd9c06..620460429c 100644
--- a/content/en/docs/reference/glossary/aggregation-layer.md
+++ b/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.
-
+
-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.
diff --git a/content/en/docs/reference/glossary/container-env-variables.md b/content/en/docs/reference/glossary/container-env-variables.md
index 5e19a1dfa2..1453193b01 100755
--- a/content/en/docs/reference/glossary/container-env-variables.md
+++ b/content/en/docs/reference/glossary/container-env-variables.md
@@ -2,7 +2,7 @@
title: Container Environment Variables
id: container-env-variables
date: 2018-04-12
-full_link: /docs/concepts/containers/container-environment-variables/
+full_link: /docs/concepts/containers/container-environment/
short_description: >
Container environment variables are name=value pairs that provide useful information into containers running in a Pod.
diff --git a/content/en/docs/reference/glossary/cronjob.md b/content/en/docs/reference/glossary/cronjob.md
index abfdfe3705..b795fd6d5c 100755
--- a/content/en/docs/reference/glossary/cronjob.md
+++ b/content/en/docs/reference/glossary/cronjob.md
@@ -11,7 +11,7 @@ tags:
- core-object
- workload
---
- Manages a [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) that runs on a periodic schedule.
+ Manages a [Job](/docs/concepts/workloads/controllers/job/) that runs on a periodic schedule.
diff --git a/content/en/docs/reference/glossary/customresourcedefinition.md b/content/en/docs/reference/glossary/customresourcedefinition.md
index 16f4a69411..9e6ec9c7c5 100755
--- a/content/en/docs/reference/glossary/customresourcedefinition.md
+++ b/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.
-
-
-Custom Resource Definitions let you extend the Kubernetes API for your environment if the publicly supported API resources can't meet your needs.
+
+Custom Resource Definitions let you extend the Kubernetes API for your environment if the publicly supported API resources can't meet your needs.
diff --git a/content/en/docs/reference/glossary/job.md b/content/en/docs/reference/glossary/job.md
index af8cfa0c37..98a189e69e 100755
--- a/content/en/docs/reference/glossary/job.md
+++ b/content/en/docs/reference/glossary/job.md
@@ -2,7 +2,7 @@
title: Job
id: job
date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/jobs-run-to-completion
+full_link: /docs/concepts/workloads/controllers/job/
short_description: >
A finite or batch task that runs to completion.
diff --git a/content/en/docs/reference/issues-security/security.md b/content/en/docs/reference/issues-security/security.md
index 709f26ffe1..b9b1ce7c37 100644
--- a/content/en/docs/reference/issues-security/security.md
+++ b/content/en/docs/reference/issues-security/security.md
@@ -6,15 +6,15 @@ reviewers:
- erictune
- philips
- jessfraz
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
This page describes Kubernetes security and disclosure information.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Security Announcements
Join the [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce) group for emails about security and major API announcements.
@@ -29,7 +29,7 @@ To make a report, submit your vulnerability to the [Kubernetes bug bounty progra
You can also email the private [security@kubernetes.io](mailto:security@kubernetes.io) list with the security details and the details expected for [all Kubernetes bug reports](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md).
-You may encrypt your email to this list using the GPG keys of the [Product Security Committee members](https://git.k8s.io/security/security-release-process.md#product-security-committee-psc). Encryption using GPG is NOT required to make a disclosure.
+You may encrypt your email to this list using the GPG keys of the [Product Security Committee members](https://git.k8s.io/security/README.md#product-security-committee-psc). Encryption using GPG is NOT required to make a disclosure.
### When Should I Report a Vulnerability?
@@ -56,4 +56,4 @@ As the security issue moves from triage, to identified fix, to release planning
## Public Disclosure Timing
A public disclosure date is negotiated by the Kubernetes Product Security Committee and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The timeframe for disclosure is from immediate (especially if it's already publicly known) to a few weeks. For a vulnerability with a straightforward mitigation, we expect report date to disclosure date to be on the order of 7 days. The Kubernetes Product Security Committee holds the final say when setting a disclosure date.
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md
index dbf0e2dc63..36629d2c29 100644
--- a/content/en/docs/reference/kubectl/cheatsheet.md
+++ b/content/en/docs/reference/kubectl/cheatsheet.md
@@ -4,21 +4,21 @@ reviewers:
- erictune
- krousey
- clove
-content_template: templates/concept
+content_type: concept
card:
name: reference
weight: 30
---
-{{% capture overview %}}
+
See also: [Kubectl Overview](/docs/reference/kubectl/overview/) and [JsonPath Guide](/docs/reference/kubectl/jsonpath).
This page is an overview of the `kubectl` command.
-{{% /capture %}}
-{{% capture body %}}
+
+
# kubectl - Cheat Sheet
@@ -290,10 +290,10 @@ kubectl logs -f my-pod # stream pod logs (stdout)
kubectl logs -f my-pod -c my-container # stream pod container logs (stdout, multi-container case)
kubectl logs -f -l name=myLabel --all-containers # stream all pods logs with label name=myLabel (stdout)
kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell
-kubectl run nginx --image=nginx --restart=Never -n
+kubectl run nginx --image=nginx -n
mynamespace # Run pod nginx in a specific namespace
-kubectl run nginx --image=nginx --restart=Never # Run pod nginx and write its spec into a file called pod.yaml
---dry-run -o yaml > pod.yaml
+kubectl run nginx --image=nginx # Run pod nginx and write its spec into a file called pod.yaml
+--dry-run=client -o yaml > pod.yaml
kubectl attach my-pod -i # Attach to Running Container
kubectl port-forward my-pod 5000:6000 # Listen on port 5000 on the local machine and forward to port 6000 on my-pod
@@ -382,9 +382,10 @@ Verbosity | Description
`--v=8` | Display HTTP request contents.
`--v=9` | Display HTTP request contents without truncation of contents.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [Overview of kubectl](/docs/reference/kubectl/overview/).
@@ -394,4 +395,4 @@ Verbosity | Description
* See more community [kubectl cheatsheets](https://github.com/dennyzhang/cheatsheet-kubernetes-A4).
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/kubectl/conventions.md b/content/en/docs/reference/kubectl/conventions.md
index c4bdd59ec5..062847c485 100644
--- a/content/en/docs/reference/kubectl/conventions.md
+++ b/content/en/docs/reference/kubectl/conventions.md
@@ -2,14 +2,14 @@
title: kubectl Usage Conventions
reviewers:
- janetkuo
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
Recommended usage conventions for `kubectl`.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Using `kubectl` in Reusable Scripts
@@ -59,4 +59,4 @@ You can generate the following resources with a kubectl command, `kubectl create
* You can use `kubectl apply` to create or update resources. For more information about using kubectl apply to update resources, see [Kubectl Book](https://kubectl.docs.kubernetes.io).
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md
index 7def04e04c..b9c5bf9af1 100644
--- a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md
+++ b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md
@@ -1,19 +1,19 @@
---
title: kubectl for Docker Users
-content_template: templates/concept
+content_type: concept
reviewers:
- brendandburns
- thockin
---
-{{% capture overview %}}
+
You can use the Kubernetes command line tool kubectl to interact with the API Server. Using kubectl is straightforward if you are familiar with the Docker command line tool. However, there are a few differences between the docker commands and the kubectl commands. The following sections show a docker sub-command and describe the equivalent kubectl command.
-{{% /capture %}}
-{{% capture body %}}
+
+
## docker run
-To run an nginx Deployment and expose the Deployment, see [kubectl run](/docs/reference/generated/kubectl/kubectl-commands/#run).
+To run an nginx Deployment and expose the Deployment, see [kubectl create deployment](/docs/reference/generated/kubectl/kubectl-commands#-em-deployment-em-).
docker:
@@ -36,10 +36,18 @@ kubectl:
```shell
# start the pod running nginx
-kubectl run --image=nginx nginx-app --port=80 --env="DOMAIN=cluster"
+kubectl create deployment --image=nginx nginx-app
```
```
-deployment "nginx-app" created
+deployment.apps/nginx-app created
+```
+
+```
+# add env to nginx-app
+kubectl set env deployment/nginx-app DOMAIN=cluster
+```
+```
+deployment.apps/nginx-app env updated
```
{{< note >}}
@@ -56,7 +64,7 @@ service "nginx-http" exposed
By using kubectl, you can create a [Deployment](/docs/concepts/workloads/controllers/deployment/) to ensure that N pods are running nginx, where N is the number of replicas stated in the spec and defaults to 1. You can also create a [service](/docs/concepts/services-networking/service/) with a selector that matches the pod labels. For more information, see [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster).
-By default images run in the background, similar to `docker run -d ...`. To run things in the foreground, use:
+By default images run in the background, similar to `docker run -d ...`. To run things in the foreground, use [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) to create pod:
```shell
kubectl run [-i] [--tty] --attach --image=
@@ -65,9 +73,6 @@ kubectl run [-i] [--tty] --attach --image=
Unlike `docker run ...`, if you specify `--attach`, then you attach `stdin`, `stdout` and `stderr`. You cannot control which streams are attached (`docker -a ...`).
To detach from the container, you can type the escape sequence Ctrl+P followed by Ctrl+Q.
-Because the kubectl run command starts a Deployment for the container, the Deployment restarts if you terminate the attached process by using Ctrl+C, unlike `docker run -it`.
-To destroy the Deployment and its pods you need to run `kubectl delete deployment `.
-
## docker ps
To list what is currently running, see [kubectl get](/docs/reference/generated/kubectl/kubectl-commands/#get).
@@ -180,7 +185,7 @@ docker exec -ti 55c103fa1296 /bin/sh
kubectl:
```shell
-kubectl exec -ti nginx-app-5jyvm -- /bin/sh
+kubectl exec -ti nginx-app-5jyvm -- /bin/sh
# exit
```
@@ -361,4 +366,4 @@ Grafana is running at https://203.0.113.141/api/v1/namespaces/kube-system/servic
Heapster is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
InfluxDB is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy
```
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/kubectl/jsonpath.md b/content/en/docs/reference/kubectl/jsonpath.md
index 731af0004e..50c051c9f4 100644
--- a/content/en/docs/reference/kubectl/jsonpath.md
+++ b/content/en/docs/reference/kubectl/jsonpath.md
@@ -1,14 +1,14 @@
---
title: JSONPath Support
-content_template: templates/concept
+content_type: concept
weight: 25
---
-{{% capture overview %}}
+
Kubectl supports JSONPath template.
-{{% /capture %}}
-{{% capture body %}}
+
+
JSONPath template is composed of JSONPath expressions enclosed by curly braces {}.
Kubectl uses JSONPath expressions to filter on specific fields in the JSON object and format the output.
@@ -98,4 +98,4 @@ kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.
```
{{< /note >}}
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/kubectl/kubectl.md b/content/en/docs/reference/kubectl/kubectl.md
index 6342de0008..f734d32f99 100644
--- a/content/en/docs/reference/kubectl/kubectl.md
+++ b/content/en/docs/reference/kubectl/kubectl.md
@@ -1,10 +1,11 @@
---
title: kubectl
-content_template: templates/tool-reference
+content_type: tool-reference
weight: 30
---
-{{% capture synopsis %}}
+## {{% heading "synopsis" %}}
+
kubectl controls the Kubernetes cluster manager.
@@ -15,9 +16,10 @@ kubectl controls the Kubernetes cluster manager.
kubectl [flags]
```
-{{% /capture %}}
-{{% capture options %}}
+
+## {{% heading "options" %}}
+
@@ -521,9 +523,10 @@ kubectl [flags]
-{{% /capture %}}
-{{% capture seealso %}}
+
+## {{% heading "seealso" %}}
+
* [kubectl alpha](/docs/reference/generated/kubectl/kubectl-commands#alpha) - Commands for features in alpha
* [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands#annotate) - Update the annotations on a resource
@@ -569,5 +572,5 @@ kubectl [flags]
* [kubectl version](/docs/reference/generated/kubectl/kubectl-commands#version) - Print the client and server version information
* [kubectl wait](/docs/reference/generated/kubectl/kubectl-commands#wait) - Experimental: Wait for a specific condition on one or many resources.
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/kubectl/overview.md b/content/en/docs/reference/kubectl/overview.md
index fa8633fb5f..66d63c4b93 100644
--- a/content/en/docs/reference/kubectl/overview.md
+++ b/content/en/docs/reference/kubectl/overview.md
@@ -2,21 +2,21 @@
reviewers:
- hw-qiaolei
title: Overview of kubectl
-content_template: templates/concept
+content_type: concept
weight: 20
card:
name: reference
weight: 20
---
-{{% capture overview %}}
-Kubectl is a command line tool for controlling Kubernetes clusters. `kubectl` looks for a file named config in the $HOME/.kube directory. You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) files by setting the KUBECONFIG environment variable or by setting the [`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag.
+
+The kubectl command line tool lets you control Kubernetes clusters. For configuration, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory. You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) files by setting the KUBECONFIG environment variable or by setting the [`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag.
This overview covers `kubectl` syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation. For installation instructions see [installing kubectl](/docs/tasks/kubectl/install/).
-{{% /capture %}}
-{{% capture body %}}
+
+
## Syntax
@@ -32,11 +32,11 @@ where `command`, `TYPE`, `NAME`, and `flags` are:
* `TYPE`: Specifies the [resource type](#resource-types). Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output:
- ```shell
- kubectl get pod pod1
- kubectl get pods pod1
- kubectl get po pod1
- ```
+ ```shell
+ kubectl get pod pod1
+ kubectl get pods pod1
+ kubectl get po pod1
+ ```
* `NAME`: Specifies the name of the resource. Names are case-sensitive. If the name is omitted, details for all resources are displayed, for example `kubectl get pods`.
@@ -113,13 +113,13 @@ Operation | Syntax | Description
`version` | `kubectl version [--client] [flags]` | Display the Kubernetes version running on the client and server.
`wait` | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | Experimental: Wait for a specific condition on one or many resources.
-Remember: For more about command operations, see the [kubectl](/docs/user-guide/kubectl/) reference documentation.
+To learn more about command operations, see the [kubectl](/docs/reference/kubectl/kubectl/) reference documentation.
## Resource types
The following table includes a list of all the supported resource types and their abbreviated aliases.
-(This output can be retrieved from `kubectl api-resources`, and is accurate as of Kubernetes 1.13.3.)
+(This output can be retrieved from `kubectl api-resources`, and was accurate as of Kubernetes 1.13.3.)
| Resource Name | Short Names | API Group | Namespaced | Resource Kind |
|---|---|---|---|---|
@@ -175,7 +175,7 @@ The following table includes a list of all the supported resource types and thei
## Output options
-Use the following sections for information about how you can format or sort the output of certain commands. For details about which commands support the various output options, see the [kubectl](/docs/user-guide/kubectl/) reference documentation.
+Use the following sections for information about how you can format or sort the output of certain commands. For details about which commands support the various output options, see the [kubectl](/docs/reference/kubectl/kubectl/) reference documentation.
### Formatting output
@@ -234,9 +234,9 @@ where the `template.txt` file contains:
NAME RSRC
metadata.name metadata.resourceVersion
```
-The result of running either command is:
+The result of running either command is similar to:
-```shell
+```
NAME RSRC
submit-queue 610995
```
@@ -247,7 +247,7 @@ submit-queue 610995
This means that for any given resource, the server will return columns and rows relevant to that resource, for the client to print.
This allows for consistent human-readable output across clients used against the same cluster, by having the server encapsulate the details of printing.
-This feature is enabled by default in `kubectl` 1.11 and higher. To disable it, add the
+This feature is enabled by default. To disable it, add the
`--server-print=false` flag to the `kubectl get` command.
##### Examples
@@ -258,9 +258,9 @@ To print information about the status of a pod, use a command like the following
kubectl get pods --server-print=false
```
-Output looks like this:
+The output is similar to:
-```shell
+```
NAME AGE
pod-name 1m
```
@@ -405,36 +405,42 @@ Use the following set of examples to help you familiarize yourself with writing
# create a simple plugin in any language and name the resulting executable file
# so that it begins with the prefix "kubectl-"
cat ./kubectl-hello
-#!/bin/bash
+```
+```shell
+#!/bin/sh
# this plugin prints the words "hello world"
echo "hello world"
-
-# with our plugin written, let's make it executable
-sudo chmod +x ./kubectl-hello
+```
+With a plugin written, let's make it executable:
+```bash
+chmod a+x ./kubectl-hello
# and move it to a location in our PATH
sudo mv ./kubectl-hello /usr/local/bin
+sudo chown root:root /usr/local/bin
-# we have now created and "installed" a kubectl plugin.
-# we can begin using our plugin by invoking it from kubectl as if it were a regular command
+# You have now created and "installed" a kubectl plugin.
+# You can begin using this plugin by invoking it from kubectl as if it were a regular command
kubectl hello
```
```
hello world
```
-```
-# we can "uninstall" a plugin, by simply removing it from our PATH
+```shell
+# You can "uninstall" a plugin, by removing it from the folder in your
+# $PATH where you placed it
sudo rm /usr/local/bin/kubectl-hello
```
-In order to view all of the plugins that are available to `kubectl`, we can use
+In order to view all of the plugins that are available to `kubectl`, use
the `kubectl plugin list` subcommand:
```shell
kubectl plugin list
```
+The output is similar to:
```
The following kubectl-compatible plugins are available:
@@ -442,11 +448,11 @@ The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-foo
/usr/local/bin/kubectl-bar
```
-```
-# this command can also warn us about plugins that are
-# not executable, or that are overshadowed by other
-# plugins, for example
-sudo chmod -x /usr/local/bin/kubectl-foo
+
+`kubectl plugin list` also warns you about plugins that are not
+executable, or that are shadowed by other plugins; for example:
+```shell
+sudo chmod -x /usr/local/bin/kubectl-foo # remove execute permission
kubectl plugin list
```
```
@@ -460,11 +466,15 @@ The following kubectl-compatible plugins are available:
error: one plugin warning was found
```
-We can think of plugins as a means to build more complex functionality on top
+You can think of plugins as a means to build more complex functionality on top
of the existing kubectl commands:
```shell
cat ./kubectl-whoami
+```
+The next few examples assume that you already made `kubectl-whoami` have
+the following contents:
+```shell
#!/bin/bash
# this plugin makes use of the `kubectl config` command in order to output
@@ -472,26 +482,28 @@ cat ./kubectl-whoami
kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
```
-Running the above plugin gives us an output containing the user for the currently selected
-context in our KUBECONFIG file:
+Running the above command gives you an output containing the user for the
+current context in your KUBECONFIG file:
```shell
# make the file executable
sudo chmod +x ./kubectl-whoami
-# and move it into our PATH
+# and move it into your PATH
sudo mv ./kubectl-whoami /usr/local/bin
kubectl whoami
Current user: plugins-user
```
-To find out more about plugins, take a look at the [example cli plugin](https://github.com/kubernetes/sample-cli-plugin).
-{{% /capture %}}
-{{% capture whatsnext %}}
-Start using the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) commands.
+## {{% heading "whatsnext" %}}
+
+
+* Start using the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) commands.
+
+* To find out more about plugins, take a look at the [example cli plugin](https://github.com/kubernetes/sample-cli-plugin).
+
-{{% /capture %}}
diff --git a/content/en/docs/reference/kubernetes-api/labels-annotations-taints.md b/content/en/docs/reference/kubernetes-api/labels-annotations-taints.md
index e1f1e9a801..d1faa51a88 100644
--- a/content/en/docs/reference/kubernetes-api/labels-annotations-taints.md
+++ b/content/en/docs/reference/kubernetes-api/labels-annotations-taints.md
@@ -1,18 +1,18 @@
---
title: Well-Known Labels, Annotations and Taints
-content_template: templates/concept
+content_type: concept
weight: 60
---
-{{% capture overview %}}
+
Kubernetes reserves all labels and annotations in the kubernetes.io namespace.
This document serves both as a reference to the values and as a coordination point for assigning values.
-{{% /capture %}}
-{{% capture body %}}
+
+
## kubernetes.io/arch
@@ -130,4 +130,4 @@ If `PersistentVolumeLabel` does not support automatic labeling of your Persisten
adding the labels manually (or adding support for `PersistentVolumeLabel`). With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all.
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/scheduling/policies.md b/content/en/docs/reference/scheduling/policies.md
index 0bf6e030b0..67d34e59f7 100644
--- a/content/en/docs/reference/scheduling/policies.md
+++ b/content/en/docs/reference/scheduling/policies.md
@@ -1,10 +1,10 @@
---
title: Scheduling Policies
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
A scheduling Policy can be used to specify the *predicates* and *priorities*
that the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}
@@ -16,9 +16,9 @@ You can set a scheduling policy by running
`kube-scheduler --policy-configmap `
and using the [Policy type](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1?tab=doc#Policy).
-{{% /capture %}}
-{{% capture body %}}
+
+
## Predicates
@@ -117,9 +117,10 @@ The following *priorities* implement scoring:
- `EvenPodsSpreadPriority`: Implements preferred
[pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/)
* Learn about [kube-scheduler profiles](/docs/reference/scheduling/profiles/)
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/scheduling/profiles.md b/content/en/docs/reference/scheduling/profiles.md
index 48fa961b2e..fe28d10bd1 100644
--- a/content/en/docs/reference/scheduling/profiles.md
+++ b/content/en/docs/reference/scheduling/profiles.md
@@ -1,10 +1,10 @@
---
title: Scheduling Profiles
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
@@ -20,9 +20,9 @@ or [`v1alpha2`](https://pkg.go.dev/k8s.io/kube-scheduler@{{< param "fullversion"
The `v1alpha2` API allows you to configure kube-scheduler to run
[multiple profiles](#multiple-profiles).
-{{% /capture %}}
-{{% capture body %}}
+
+
## Extension points
@@ -174,8 +174,9 @@ the same configuration parameters (if applicable). This is because the scheduler
only has one pending pods queue.
{{< /note >}}
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/)
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md
index a0aa304217..cb42a34df9 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md
@@ -3,10 +3,10 @@ reviewers:
- luxas
- jbeda
title: Implementation details
-content_template: templates/concept
+content_type: concept
weight: 100
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.10" state="stable" >}}
@@ -14,9 +14,9 @@ weight: 100
However, it might not be obvious _how_ kubeadm does that.
This document provides additional details on what happen under the hood, with the aim of sharing knowledge on Kubernetes cluster best practices.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Core design principles
The cluster that `kubeadm init` and `kubeadm join` set up should be:
@@ -531,4 +531,4 @@ Please note that:
1. To make dynamic kubelet configuration work, flag `--dynamic-config-dir=/var/lib/kubelet/config/dynamic` should be specified in `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md
index c918cd5580..a4b0e501d8 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md
@@ -3,10 +3,10 @@ reviewers:
- luxas
- jbeda
title: kubeadm config
-content_template: templates/concept
+content_type: concept
weight: 50
---
-{{% capture overview %}}
+
During `kubeadm init`, kubeadm uploads the `ClusterConfiguration` object to your cluster
in a ConfigMap called `kubeadm-config` in the `kube-system` namespace. This configuration is then read during
`kubeadm join`, `kubeadm reset` and `kubeadm upgrade`. To view this ConfigMap call `kubeadm config view`.
@@ -19,9 +19,9 @@ In Kubernetes v1.13.0 and later to list/pull kube-dns images instead of the Core
the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon)
has to be used.
-{{% /capture %}}
-{{% capture body %}}
+
+
## kubeadm config view {#cmd-config-view}
{{< include "generated/kubeadm_config_view.md" >}}
@@ -40,8 +40,9 @@ has to be used.
## kubeadm config images pull {#cmd-config-images-pull}
{{< include "generated/kubeadm_config_images_pull.md" >}}
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
index 7103b39d42..54729065c6 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
@@ -3,14 +3,14 @@ reviewers:
- luxas
- jbeda
title: kubeadm init
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
This command initializes a Kubernetes control-plane node.
-{{% /capture %}}
-{{% capture body %}}
+
+
{{< include "generated/kubeadm_init.md" >}}
@@ -255,12 +255,13 @@ it does not allow the root CA hash to be validated with
`--discovery-token-ca-cert-hash` (since it's not generated when the nodes are
provisioned). For details, see the [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [kubeadm init phase](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) to understand more about
`kubeadm init` phases
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
index 1e99d1682b..d83fb98436 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
@@ -3,14 +3,14 @@ reviewers:
- luxas
- jbeda
title: kubeadm join
-content_template: templates/concept
+content_type: concept
weight: 30
---
-{{% capture overview %}}
+
This command initializes a Kubernetes worker node and joins it to the cluster.
-{{% /capture %}}
-{{% capture body %}}
+
+
{{< include "generated/kubeadm_join.md" >}}
### The join workflow {#join-workflow}
@@ -59,7 +59,7 @@ kubeadm join phase kubelet-start --help
```
Similar to the [kubeadm init phase](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases)
-command, `kubadm join phase` allows you to skip a list of phases using the `--skip-phases` flag.
+command, `kubeadm join phase` allows you to skip a list of phases using the `--skip-phases` flag.
For example:
@@ -276,10 +276,11 @@ kubeadm config print join-defaults
For details on individual fields in `JoinConfiguration` see [the godoc](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#JoinConfiguration).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/) to manage tokens for `kubeadm join`
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md
index 7185a51475..2664283daa 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md
@@ -3,14 +3,14 @@ reviewers:
- luxas
- jbeda
title: kubeadm reset
-content_template: templates/concept
+content_type: concept
weight: 60
---
-{{% capture overview %}}
+
Performs a best effort revert of changes made by `kubeadm init` or `kubeadm join`.
-{{% /capture %}}
-{{% capture body %}}
+
+
{{< include "generated/kubeadm_reset.md" >}}
### Reset workflow {#reset-workflow}
@@ -35,9 +35,10 @@ etcdctl del "" --prefix
```
See the [etcd documentation](https://github.com/coreos/etcd/tree/master/etcdctl) for more information.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-token.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-token.md
index a8e9c7cd99..92a187bb92 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-token.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-token.md
@@ -3,10 +3,10 @@ reviewers:
- luxas
- jbeda
title: kubeadm token
-content_template: templates/concept
+content_type: concept
weight: 70
---
-{{% capture overview %}}
+
Bootstrap tokens are used for establishing bidirectional trust between a node joining
the cluster and a control-plane node, as described in [authenticating with bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/).
@@ -14,9 +14,9 @@ the cluster and a control-plane node, as described in [authenticating with boots
`kubeadm init` creates an initial token with a 24-hour TTL. The following commands allow you to manage
such a token and also to create and manage new ones.
-{{% /capture %}}
-{{% capture body %}}
+
+
## kubeadm token create {#cmd-token-create}
{{< include "generated/kubeadm_token_create.md" >}}
@@ -28,8 +28,9 @@ such a token and also to create and manage new ones.
## kubeadm token list {#cmd-token-list}
{{< include "generated/kubeadm_token_list.md" >}}
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md
index 31c2f11d9c..71483aa1d6 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md
@@ -3,15 +3,15 @@ reviewers:
- luxas
- jbeda
title: kubeadm upgrade
-content_template: templates/concept
+content_type: concept
weight: 40
---
-{{% capture overview %}}
+
`kubeadm upgrade` is a user-friendly command that wraps complex upgrading logic
behind one command, with support for both planning an upgrade and actually performing it.
-{{% /capture %}}
-{{% capture body %}}
+
+
## kubeadm upgrade guidance
@@ -46,8 +46,9 @@ reports of unexpected results.
## kubeadm upgrade node {#cmd-upgrade-node}
{{< include "generated/kubeadm_upgrade_node.md" >}}
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config/) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade`
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-version.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-version.md
index 5da4209f3e..a4b57e796c 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-version.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-version.md
@@ -3,13 +3,13 @@ reviewers:
- luxas
- jbeda
title: kubeadm version
-content_template: templates/concept
+content_type: concept
weight: 80
---
-{{% capture overview %}}
+
This command prints the version of kubeadm.
-{{% /capture %}}
-{{% capture body %}}
+
+
{{< include "generated/kubeadm_version.md" >}}
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/tools.md b/content/en/docs/reference/tools.md
index 349ce58f2c..ef210f2b07 100644
--- a/content/en/docs/reference/tools.md
+++ b/content/en/docs/reference/tools.md
@@ -2,14 +2,14 @@
reviewers:
- janetkuo
title: Tools
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
Kubernetes contains several built-in tools to help you work with the Kubernetes system.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Kubectl
[`kubectl`](/docs/tasks/tools/install-kubectl/) is the command line tool for Kubernetes. It controls the Kubernetes cluster manager.
@@ -51,4 +51,4 @@ Use Kompose to:
* Translate a Docker Compose file into Kubernetes objects
* Go from local Docker development to managing your application via Kubernetes
* Convert v1 or v2 Docker Compose `yaml` files or [Distributed Application Bundles](https://docs.docker.com/compose/bundles/)
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md
index fb75cae36a..f83c43c00f 100644
--- a/content/en/docs/reference/using-api/api-concepts.md
+++ b/content/en/docs/reference/using-api/api-concepts.md
@@ -4,15 +4,15 @@ reviewers:
- smarterclayton
- lavalamp
- liggitt
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
This page describes common concepts in the Kubernetes API.
-{{% /capture %}}
-{{% capture body %}}
+
+
The Kubernetes API is a resource-based (RESTful) programmatic interface provided via HTTP. It supports retrieving, creating,
updating, and deleting primary resources via the standard HTTP verbs (POST, PUT, PATCH, DELETE, GET), includes additional subresources for many objects that allow fine grained authorization (such as binding a pod to a node), and can accept and serve those resources in different representations for convenience or efficiency. It also supports efficient change notifications on resources via "watches" and consistent lists to allow other components to effectively cache and synchronize the state of resources.
@@ -357,7 +357,7 @@ The modifying verbs (`POST`, `PUT`, `PATCH`, and `DELETE`) can accept requests i
Dry-run is triggered by setting the `dryRun` query parameter. This parameter is a string, working as an enum, and the only accepted values are:
-* `All`: Every stage runs as normal, except for the final storage stage. Admission controllers are run to check that the request is valid, mutating controllers mutate the request, merge is performed on `PATCH`, fields are defaulted, and schema validation occurs. The changes are not persisted to the underlying storage, but the final object which would have been persisted is still returned to the user, along with the normal status code. If the request would trigger an admission controller which would have side effects, the request will be failed rather than risk an unwanted side effect. All built in admission control plugins support dry-run. Additionally, admission webhooks can declare in their [configuration object](/docs/reference/generated/kubernetes-api/v1.13/#webhook-v1beta1-admissionregistration-k8s-io) that they do not have side effects by setting the sideEffects field to "None". If a webhook actually does have side effects, then the sideEffects field should be set to "NoneOnDryRun", and the webhook should also be modified to understand the `DryRun` field in AdmissionReview, and prevent side effects on dry-run requests.
+* `All`: Every stage runs as normal, except for the final storage stage. Admission controllers are run to check that the request is valid, mutating controllers mutate the request, merge is performed on `PATCH`, fields are defaulted, and schema validation occurs. The changes are not persisted to the underlying storage, but the final object which would have been persisted is still returned to the user, along with the normal status code. If the request would trigger an admission controller which would have side effects, the request will be failed rather than risk an unwanted side effect. All built in admission control plugins support dry-run. Additionally, admission webhooks can declare in their [configuration object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#webhook-v1beta1-admissionregistration-k8s-io) that they do not have side effects by setting the sideEffects field to "None". If a webhook actually does have side effects, then the sideEffects field should be set to "NoneOnDryRun", and the webhook should also be modified to understand the `DryRun` field in AdmissionReview, and prevent side effects on dry-run requests.
* Leave the value empty, which is also the default: Keep the default modifying behavior.
For example:
@@ -490,7 +490,7 @@ Nevertheless it is possible to change `metadata.managedFields` through an
option to try if, for example, the `managedFields` get into an inconsistent
state (which clearly should not happen).
-The format of the `managedFields` is described in the [API](/docs/reference/generated/kubernetes-api/v1.16/#managedfieldsentry-v1-meta).
+The format of the `managedFields` is described in the [API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#fieldsv1-v1-meta).
### Conflicts
@@ -706,9 +706,9 @@ Resource versions are strings that identify the server's internal version of an
Clients find resource versions in resources, including the resources in watch events, and list responses returned from the server:
-[v1.meta/ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#objectmeta-v1-meta) - The `metadata.resourceVersion` of a resource instance identifies the resource version the instance was last modified at.
+[v1.meta/ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectmeta-v1-meta) - The `metadata.resourceVersion` of a resource instance identifies the resource version the instance was last modified at.
-[v1.meta/ListMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#listmeta-v1-meta) - The `metadata.resourceVersion` of a resource collection (i.e. a list response) identifies the resource version at which the list response was constructed.
+[v1.meta/ListMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#listmeta-v1-meta) - The `metadata.resourceVersion` of a resource collection (i.e. a list response) identifies the resource version at which the list response was constructed.
### The ResourceVersion Parameter
diff --git a/content/en/docs/reference/using-api/api-overview.md b/content/en/docs/reference/using-api/api-overview.md
index 3820085e6b..25b7d46af9 100644
--- a/content/en/docs/reference/using-api/api-overview.md
+++ b/content/en/docs/reference/using-api/api-overview.md
@@ -4,7 +4,7 @@ reviewers:
- erictune
- lavalamp
- jbeda
-content_template: templates/concept
+content_type: concept
weight: 10
card:
name: reference
@@ -12,11 +12,11 @@ card:
title: Overview of API
---
-{{% capture overview %}}
+
This page provides an overview of the Kubernetes API.
-{{% /capture %}}
-{{% capture body %}}
+
+
The REST API is the fundamental fabric of Kubernetes. All operations and communications between components, and external user commands are REST API calls that the API Server handles. Consequently, everything in the Kubernetes
platform is treated as an API object and has a corresponding entry in the
[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/).
@@ -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.
diff --git a/content/en/docs/reference/using-api/client-libraries.md b/content/en/docs/reference/using-api/client-libraries.md
index 145a792b72..1531b2c5df 100644
--- a/content/en/docs/reference/using-api/client-libraries.md
+++ b/content/en/docs/reference/using-api/client-libraries.md
@@ -2,16 +2,16 @@
title: Client Libraries
reviewers:
- ahmetb
-content_template: templates/concept
+content_type: concept
weight: 30
---
-{{% capture overview %}}
+
This page contains an overview of the client libraries for using the Kubernetes
API from various programming languages.
-{{% /capture %}}
-{{% capture body %}}
+
+
To write applications using the [Kubernetes REST API](/docs/reference/using-api/api-overview/),
you do not need to implement the API calls and request/response types yourself.
You can use a client library for the programming language you are using.
@@ -49,6 +49,7 @@ their authors, not the Kubernetes team.
| Go | [github.com/ericchiang/k8s](https://github.com/ericchiang/k8s) |
| Java (OSGi) | [bitbucket.org/amdatulabs/amdatu-kubernetes](https://bitbucket.org/amdatulabs/amdatu-kubernetes) |
| Java (Fabric8, OSGi) | [github.com/fabric8io/kubernetes-client](https://github.com/fabric8io/kubernetes-client) |
+| Java | [github.com/manusa/yakc](https://github.com/manusa/yakc) |
| Lisp | [github.com/brendandburns/cl-k8s](https://github.com/brendandburns/cl-k8s) |
| Lisp | [github.com/xh4/cube](https://github.com/xh4/cube) |
| Node.js (TypeScript) | [github.com/Goyoo/node-k8s-client](https://github.com/Goyoo/node-k8s-client) |
@@ -74,6 +75,6 @@ their authors, not the Kubernetes team.
| DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) |
| Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) |
| Elixir | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) |
-{{% /capture %}}
+
diff --git a/content/en/docs/reference/using-api/deprecation-policy.md b/content/en/docs/reference/using-api/deprecation-policy.md
index f55438cd18..a21d0887ba 100644
--- a/content/en/docs/reference/using-api/deprecation-policy.md
+++ b/content/en/docs/reference/using-api/deprecation-policy.md
@@ -4,15 +4,15 @@ reviewers:
- lavalamp
- thockin
title: Kubernetes Deprecation Policy
-content_template: templates/concept
+content_type: concept
weight: 40
---
-{{% capture overview %}}
+
This document details the deprecation policy for various facets of the system.
-{{% /capture %}}
-{{% capture body %}}
+
+
Kubernetes is a large system with many components and many contributors. As
with any such software, the feature set naturally evolves over time, and
sometimes a feature may need to be removed. This could include an API, a flag,
@@ -425,4 +425,4 @@ leaders to find the best solutions for those specific cases, always bearing in
mind that Kubernetes is committed to being a stable system that, as much as
possible, never breaks users. Exceptions will always be announced in all
relevant release notes.
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/_index.md b/content/en/docs/setup/_index.md
index 16702b40f5..91b734953c 100644
--- a/content/en/docs/setup/_index.md
+++ b/content/en/docs/setup/_index.md
@@ -7,7 +7,7 @@ no_issue: true
title: Getting started
main_menu: true
weight: 20
-content_template: templates/concept
+content_type: concept
card:
name: setup
weight: 20
@@ -18,7 +18,7 @@ card:
title: Production environment
---
-{{% capture overview %}}
+
This section covers different options to set up and run Kubernetes.
@@ -28,9 +28,9 @@ You can deploy a Kubernetes cluster on a local machine, cloud, on-prem datacente
More simply, you can create a Kubernetes cluster in learning and production environments.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Learning environment
@@ -51,4 +51,4 @@ When evaluating a solution for a production environment, consider which aspects
[Kubernetes Partners](https://kubernetes.io/partners/#conformance) includes a list of [Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes) providers.
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/best-practices/certificates.md b/content/en/docs/setup/best-practices/certificates.md
index 6169b3f872..a85d44e0f4 100644
--- a/content/en/docs/setup/best-practices/certificates.md
+++ b/content/en/docs/setup/best-practices/certificates.md
@@ -2,20 +2,20 @@
title: PKI certificates and requirements
reviewers:
- sig-cluster-lifecycle
-content_template: templates/concept
+content_type: concept
weight: 40
---
-{{% capture overview %}}
+
Kubernetes requires PKI certificates for authentication over TLS.
If you install Kubernetes with [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), the certificates that your cluster requires are automatically generated.
You can also generate your own certificates -- for example, to keep your private keys more secure by not storing them on the API server.
This page explains the certificates that your cluster requires.
-{{% /capture %}}
-{{% capture body %}}
+
+
## How certificates are used by your cluster
@@ -31,7 +31,7 @@ Kubernetes requires PKI for the following operations:
* Client and server certificates for the [front-proxy][proxy]
{{< note >}}
-`front-proxy` certificates are required only if you run kube-proxy to support [an extension API server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/).
+`front-proxy` certificates are required only if you run kube-proxy to support [an extension API server](/docs/tasks/extend-kubernetes/setup-extension-api-server/).
{{< /note >}}
etcd also implements mutual TLS to authenticate clients and peers.
@@ -162,6 +162,6 @@ These files are used as follows:
[usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage
[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/
-[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/
+[proxy]: /docs/tasks/extend-kubernetes/configure-aggregation-layer/
+
-{{% /capture %}}
diff --git a/content/en/docs/setup/best-practices/cluster-large.md b/content/en/docs/setup/best-practices/cluster-large.md
index b8b47b3add..c8692c8872 100644
--- a/content/en/docs/setup/best-practices/cluster-large.md
+++ b/content/en/docs/setup/best-practices/cluster-large.md
@@ -15,9 +15,6 @@ At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes.
* No more than 300000 total containers
* No more than 100 pods per node
-
-
-{{< toc >}}
## Setup
diff --git a/content/en/docs/setup/best-practices/multiple-zones.md b/content/en/docs/setup/best-practices/multiple-zones.md
index ba58df028f..ab61c839a9 100644
--- a/content/en/docs/setup/best-practices/multiple-zones.md
+++ b/content/en/docs/setup/best-practices/multiple-zones.md
@@ -5,16 +5,16 @@ reviewers:
- quinton-hoole
title: Running in multiple zones
weight: 10
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
This page describes how to run a cluster in multiple zones.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Introduction
@@ -401,4 +401,4 @@ KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b k
KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh
```
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/best-practices/node-conformance.md b/content/en/docs/setup/best-practices/node-conformance.md
index 0adabe2c58..5e75959b18 100644
--- a/content/en/docs/setup/best-practices/node-conformance.md
+++ b/content/en/docs/setup/best-practices/node-conformance.md
@@ -5,7 +5,6 @@ title: Validate node setup
weight: 30
---
-{{< toc >}}
## Node Conformance Test
diff --git a/content/en/docs/setup/learning-environment/kind.md b/content/en/docs/setup/learning-environment/kind.md
index e476d220d0..ac355bd157 100644
--- a/content/en/docs/setup/learning-environment/kind.md
+++ b/content/en/docs/setup/learning-environment/kind.md
@@ -1,22 +1,22 @@
---
title: Installing Kubernetes with Kind
weight: 40
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
Kind is a tool for running local Kubernetes clusters using Docker container "nodes".
-{{% /capture %}}
-{{% capture body %}}
+
+
## Installation
See [Installing Kind](https://kind.sigs.k8s.io/docs/user/quick-start/).
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/learning-environment/minikube.md b/content/en/docs/setup/learning-environment/minikube.md
index e314d56608..a794141f2d 100644
--- a/content/en/docs/setup/learning-environment/minikube.md
+++ b/content/en/docs/setup/learning-environment/minikube.md
@@ -5,16 +5,16 @@ reviewers:
- aaron-prindle
title: Installing Kubernetes with Minikube
weight: 30
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a single-node Kubernetes cluster inside a Virtual Machine (VM) on your laptop for users looking to try out Kubernetes or develop with it day-to-day.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Minikube Features
@@ -369,7 +369,12 @@ The `minikube delete` command can be used to delete your cluster.
This command shuts down and deletes the Minikube Virtual Machine. No data or state is preserved.
### Upgrading Minikube
-If you are using macOS, see [Upgrading Minikube](https://minikube.sigs.k8s.io/docs/start/macos/#upgrading-minikube) to upgrade your existing minikube installation.
+If you are using macOS and [Brew Package Manager](https://brew.sh/) is installed run:
+
+```shell
+brew update
+brew upgrade minikube
+```
## Interacting with Your Cluster
@@ -380,9 +385,11 @@ This context contains the configuration to communicate with your Minikube cluste
Minikube sets this context to default automatically, but if you need to switch back to it in the future, run:
-`kubectl config use-context minikube`,
+`kubectl config use-context minikube`
-Or pass the context on each command like this: `kubectl get pods --context=minikube`.
+Or pass the context on each command like this:
+
+`kubectl get pods --context=minikube`
### Dashboard
@@ -509,4 +516,4 @@ For more information about Minikube, see the [proposal](https://git.k8s.io/commu
Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the #minikube channel (get an invitation [here](http://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ".
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md
index 7db25e022b..77e7bb577a 100644
--- a/content/en/docs/setup/production-environment/container-runtimes.md
+++ b/content/en/docs/setup/production-environment/container-runtimes.md
@@ -3,17 +3,17 @@ reviewers:
- vincepri
- bart0sh
title: Container runtimes
-content_template: templates/concept
+content_type: concept
weight: 10
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.6" state="stable" >}}
To run containers in Pods, Kubernetes uses a container runtime. Here are
the installation instructions for various runtimes.
-{{% /capture %}}
-{{% capture body %}}
+
+
{{< caution >}}
@@ -64,13 +64,13 @@ is to drain the Node from its workloads, remove it from the cluster and re-join
## Docker
On each of your machines, install Docker.
-Version 19.03.8 is recommended, but 1.13.1, 17.03, 17.06, 17.09, 18.06 and 18.09 are known to work as well.
+Version 19.03.11 is recommended, but 1.13.1, 17.03, 17.06, 17.09, 18.06 and 18.09 are known to work as well.
Keep track of the latest verified Docker version in the Kubernetes release notes.
Use the following commands to install Docker on your system:
{{< tabs name="tab-cri-docker-installation" >}}
-{{< tab name="Ubuntu 16.04+" >}}
+{{% tab name="Ubuntu 16.04+" %}}
```shell
# (Install Docker CE)
@@ -96,9 +96,9 @@ add-apt-repository \
```shell
# Install Docker CE
apt-get update && apt-get install -y \
- containerd.io=1.2.13-1 \
- docker-ce=5:19.03.8~3-0~ubuntu-$(lsb_release -cs) \
- docker-ce-cli=5:19.03.8~3-0~ubuntu-$(lsb_release -cs)
+ containerd.io=1.2.13-2 \
+ docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
+ docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
```
```shell
@@ -124,8 +124,8 @@ mkdir -p /etc/systemd/system/docker.service.d
systemctl daemon-reload
systemctl restart docker
```
-{{< /tab >}}
-{{< tab name="CentOS/RHEL 7.4+" >}}
+{{% /tab %}}
+{{% tab name="CentOS/RHEL 7.4+" %}}
```shell
# (Install Docker CE)
@@ -144,8 +144,8 @@ yum-config-manager --add-repo \
# Install Docker CE
yum update -y && yum install -y \
containerd.io-1.2.13 \
- docker-ce-19.03.8 \
- docker-ce-cli-19.03.8
+ docker-ce-19.03.11 \
+ docker-ce-cli-19.03.11
```
```shell
@@ -179,9 +179,15 @@ mkdir -p /etc/systemd/system/docker.service.d
systemctl daemon-reload
systemctl restart docker
```
-{{< /tab >}}
+{{% /tab %}}
{{< /tabs >}}
+If you want the docker service to start on boot, run the following command:
+
+```shell
+sudo systemctl enable docker
+```
+
Refer to the [official Docker installation guides](https://docs.docker.com/engine/installation/)
for more information.
@@ -213,7 +219,7 @@ sysctl --system
```
{{< tabs name="tab-cri-cri-o-installation" >}}
-{{< tab name="Debian" >}}
+{{% tab name="Debian" %}}
```shell
# Debian Unstable/Sid
@@ -243,9 +249,9 @@ and then install CRI-O:
```shell
sudo apt-get install cri-o-1.17
```
-{{< /tab >}}
+{{% /tab %}}
-{{< tab name="Ubuntu 18.04, 19.04 and 19.10" >}}
+{{% tab name="Ubuntu 18.04, 19.04 and 19.10" %}}
```shell
# Configure package repository
@@ -259,9 +265,9 @@ sudo apt-get update
# Install CRI-O
sudo apt-get install cri-o-1.17
```
-{{< /tab >}}
+{{% /tab %}}
-{{< tab name="CentOS/RHEL 7.4+" >}}
+{{% tab name="CentOS/RHEL 7.4+" %}}
```shell
# Install prerequisites
@@ -273,14 +279,14 @@ curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:{{< skew late
# Install CRI-O
yum install -y cri-o
```
-{{< /tab >}}
+{{% /tab %}}
-{{< tab name="openSUSE Tumbleweed" >}}
+{{% tab name="openSUSE Tumbleweed" %}}
```shell
sudo zypper install cri-o
```
-{{< /tab >}}
+{{% /tab %}}
{{< /tabs >}}
### Start CRI-O
@@ -323,7 +329,7 @@ sysctl --system
### Install containerd
{{< tabs name="tab-cri-containerd-installation" >}}
-{{< tab name="Ubuntu 16.04" >}}
+{{% tab name="Ubuntu 16.04" %}}
```shell
# (Install containerd)
@@ -360,24 +366,27 @@ containerd config default > /etc/containerd/config.toml
# Restart containerd
systemctl restart containerd
```
-{{< /tab >}}
-{{< tab name="CentOS/RHEL 7.4+" >}}
+{{% /tab %}}
+{{% tab name="CentOS/RHEL 7.4+" %}}
```shell
# (Install containerd)
## Set up the repository
### Install required packages
yum install -y yum-utils device-mapper-persistent-data lvm2
+```
```shell
## Add docker repository
yum-config-manager \
--add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
+```
```shell
## Install containerd
yum update -y && yum install -y containerd.io
+```
```shell
## Configure containerd
@@ -389,7 +398,7 @@ containerd config default > /etc/containerd/config.toml
# Restart containerd
systemctl restart containerd
```
-{{< /tab >}}
+{{% /tab %}}
{{< /tabs >}}
### systemd
@@ -402,4 +411,4 @@ When using kubeadm, manually configure the
Refer to the [Frakti QuickStart guide](https://github.com/kubernetes/frakti#quickstart) for more information.
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md b/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md
index e85953dd86..1f7d1fd81f 100644
--- a/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md
+++ b/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md
@@ -2,10 +2,10 @@
reviewers:
- thockin
title: Cloudstack
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
[CloudStack](https://cloudstack.apache.org/) is a software to build public and private clouds based on hardware virtualization principles (traditional IaaS). To deploy Kubernetes on CloudStack there are several possibilities depending on the Cloud being used and what images are made available. CloudStack also has a vagrant plugin available, hence Vagrant could be used to deploy Kubernetes either using the existing shell provisioner or using new Salt based recipes.
@@ -13,9 +13,9 @@ content_template: templates/concept
This guide uses a single [Ansible playbook](https://github.com/apachecloudstack/k8s), which is completely automated and can deploy Kubernetes on a CloudStack based Cloud using CoreOS images. The playbook, creates an ssh key pair, creates a security group and associated rules and finally starts coreOS instances configured via cloud-init.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Prerequisites
@@ -118,4 +118,4 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs
CloudStack | Ansible | CoreOS | flannel | [docs](/docs/setup/production-environment/on-premises-vm/cloudstack/) | | Community ([@Guiques](https://github.com/ltupin/))
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/production-environment/on-premises-vm/dcos.md b/content/en/docs/setup/production-environment/on-premises-vm/dcos.md
index 12e47948e2..e4b310902c 100644
--- a/content/en/docs/setup/production-environment/on-premises-vm/dcos.md
+++ b/content/en/docs/setup/production-environment/on-premises-vm/dcos.md
@@ -2,10 +2,10 @@
reviewers:
- smugcloud
title: Kubernetes on DC/OS
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
Mesosphere provides an easy option to provision Kubernetes onto [DC/OS](https://mesosphere.com/product/), offering:
@@ -14,12 +14,12 @@ Mesosphere provides an easy option to provision Kubernetes onto [DC/OS](https://
* Highly available and secure by default
* Kubernetes running alongside fast-data platforms (e.g. Akka, Cassandra, Kafka, Spark)
-{{% /capture %}}
-{{% capture body %}}
+
+
## Official Mesosphere Guide
The canonical source of getting started on DC/OS is located in the [quickstart repo](https://github.com/mesosphere/dcos-kubernetes-quickstart).
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/production-environment/on-premises-vm/ovirt.md b/content/en/docs/setup/production-environment/on-premises-vm/ovirt.md
index be6f3b8e77..1d57b6f7eb 100644
--- a/content/en/docs/setup/production-environment/on-premises-vm/ovirt.md
+++ b/content/en/docs/setup/production-environment/on-premises-vm/ovirt.md
@@ -3,16 +3,16 @@ reviewers:
- caesarxuchao
- erictune
title: oVirt
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
oVirt is a virtual datacenter manager that delivers powerful management of multiple virtual machines on multiple hosts. Using KVM and libvirt, oVirt can be installed on Fedora, CentOS, or Red Hat Enterprise Linux hosts to set up and manage your virtual data center.
-{{% /capture %}}
-{{% capture body %}}
+
+
## oVirt Cloud Provider Deployment
@@ -69,4 +69,4 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs
oVirt | | | | [docs](/docs/setup/production-environment/on-premises-vm/ovirt/) | | Community ([@simon3z](https://github.com/simon3z))
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/production-environment/tools/kops.md b/content/en/docs/setup/production-environment/tools/kops.md
index 10ae6dfa65..338dbee0e5 100644
--- a/content/en/docs/setup/production-environment/tools/kops.md
+++ b/content/en/docs/setup/production-environment/tools/kops.md
@@ -1,10 +1,10 @@
---
title: Installing Kubernetes with kops
-content_template: templates/task
+content_type: task
weight: 20
---
-{{% capture overview %}}
+
This quickstart shows you how to easily install a Kubernetes cluster on AWS.
It uses a tool called [`kops`](https://github.com/kubernetes/kops).
@@ -18,9 +18,10 @@ kops is an automated provisioning system:
* High-Availability support - see the [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/operations/high_availability.md)
* Can directly provision, or generate terraform manifests - see the [terraform.md](https://github.com/kubernetes/kops/blob/master/docs/terraform.md)
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* You must have [kubectl](/docs/tasks/tools/install-kubectl/) installed.
@@ -28,9 +29,9 @@ kops is an automated provisioning system:
* You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Creating a cluster
@@ -225,13 +226,14 @@ See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to expl
* To delete your cluster: `kops delete cluster useast1.dev.example.com --yes`
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
* Learn more about `kops` [advanced usage](https://kops.sigs.k8s.io/) for tutorials, best practices and advanced configuration options.
* Follow `kops` community discussions on Slack: [community discussions](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors)
* Contribute to `kops` by addressing or raising an issue [GitHub Issues](https://github.com/kubernetes/kops/issues)
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/production-environment/tools/krib.md b/content/en/docs/setup/production-environment/tools/krib.md
deleted file mode 100644
index 98b7cb16df..0000000000
--- a/content/en/docs/setup/production-environment/tools/krib.md
+++ /dev/null
@@ -1,101 +0,0 @@
----
-title: Installing Kubernetes with KRIB
-krib-version: 2.4
-author: Rob Hirschfeld (zehicle)
-weight: 20
----
-
-## Overview
-
-This guide helps to install a Kubernetes cluster hosted on bare metal with [Digital Rebar Provision](https://github.com/digitalrebar/provision) using only its Content packages and *kubeadm*.
-
-Digital Rebar Provision (DRP) is an integrated Golang DHCP, bare metal provisioning (PXE/iPXE) and workflow automation platform. While [DRP can be used to invoke](https://provision.readthedocs.io/en/tip/doc/integrations/ansible.html) [kubespray](/docs/setup/custom-cloud/kubespray), it also offers a self-contained Kubernetes installation known as [KRIB (Kubernetes Rebar Integrated Bootstrap)](https://github.com/digitalrebar/provision-content/tree/master/krib).
-
-{{< note >}}
-KRIB is not a _stand-alone_ installer: Digital Rebar templates drive a standard *[kubeadm](/docs/admin/kubeadm/)* configuration that manages the Kubernetes installation with the [Digital Rebar cluster pattern](https://provision.readthedocs.io/en/tip/doc/arch/cluster.html#rs-cluster-pattern) to elect leaders _without external supervision_.
-{{< /note >}}
-
-
-KRIB features:
-
-* zero-touch, self-configuring cluster without pre-configuration or inventory
-* very fast, no-ssh required automation
-* bare metal, on-premises focused platform
-* highly available cluster options (including splitting etcd from the controllers)
-* dynamic generation of a TLS infrastructure
-* composable attributes and automatic detection of hardware by profile
-* options for persistent, immutable and image-based deployments
-* support for Ubuntu 18.04, CentOS/RHEL 7, CoreOS, RancherOS and others
-
-## Creating a cluster
-
-Review [Digital Rebar documentation](https://provision.readthedocs.io/en/tip/README.html) for details about installing the platform.
-
-The Digital Rebar Provision Golang binary should be installed on a Linux-like system with 16 GB of RAM or larger (Packet.net Tiny and Rasberry Pi are also acceptable).
-
-### (1/5) Discover servers
-
-Following the [Digital Rebar installation](https://provision.readthedocs.io/en/tip/doc/quickstart.html), allow one or more servers to boot through the _Sledgehammer_ discovery process to register with the API. This will automatically install the Digital Rebar runner and to allow for next steps.
-
-### (2/5) Install KRIB Content and Certificate Plugin
-
-Upload the KRIB Content bundle (or build from [source](https://github.com/digitalrebar/provision-content/tree/master/krib)) and the Cert Plugin for your DRP platform. Both are freely available via the [RackN UX](https://portal.rackn.io) or using the upload from catalog feature of the DRPCLI (shown below).
-
-```
-drpcli plugin_providers upload certs from catalog:certs-stable
-drpcli contents upload catalog:krib-stable
-```
-
-### (3/5) Start your cluster deployment
-
-{{< note >}}
-KRIB documentation is dynamically generated from the source and will be more up to date than this guide.
-{{< /note >}}
-
-Following the [KRIB documentation](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html), create a Profile for your cluster and assign your target servers into the cluster Profile. The Profile must set `krib\cluster-name` and `etcd\cluster-name` Params to be the name of the Profile. Cluster configuration choices can be made by adding additional Params to the Profile; however, safe defaults are provided for all Params.
-
-Once all target servers are assigned to the cluster Profile, start a KRIB installation Workflow by assigning one of the included Workflows to all cluster servers. For example, selecting `krib-live-cluster` will perform an immutable deployment into the Sledgehammer discovery operating system. You may use one of the pre-created read-only Workflows or choose to build your own custom variation.
-
-For basic installs, no further action is required. Advanced users may choose to assign the controllers, etcd servers or other configuration values in the relevant Params.
-
-### (4/5) Monitor your cluster deployment
-
-Digital Rebar Provision provides detailed logging and live updates during the installation process. Workflow events are available via a websocket connection or monitoring the Jobs list.
-
-During the installation, KRIB writes cluster configuration data back into the cluster Profile.
-
-### (5/5) Access your cluster
-
-The cluster is available for access via *kubectl* once the `krib/cluster-admin-conf` Param has been set. This Param contains the `kubeconfig` information necessary to access the cluster.
-
-For example, if you named the cluster Profile `krib` then the following commands would allow you to connect to the installed cluster from your local terminal.
-
- ::
-
- drpcli profiles get krib params krib/cluster-admin-conf > admin.conf
- export KUBECONFIG=admin.conf
- kubectl get nodes
-
-
-The installation continues after the `krib/cluster-admin-conf` is set to install the Kubernetes UI and Helm. You may interact with the cluster as soon as the `admin.conf` file is available.
-
-## Cluster operations
-
-KRIB provides additional Workflows to manage your cluster. Please see the [KRIB documentation](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html) for an updated list of advanced cluster operations.
-
-### Scale your cluster
-
-You can add servers into your cluster by adding the cluster Profile to the server and running the appropriate Workflow.
-
-### Cleanup your cluster (for developers)
-
-You can reset your cluster and wipe out all configuration and TLS certificates using the `krib-reset-cluster` Workflow on any of the servers in the cluster.
-
-{{< caution >}}
-When running the reset Workflow, be sure not to accidentally target your production cluster!
-{{< /caution >}}
-
-## Feedback
-
-* Slack Channel: [#community](https://rackn.slack.com/messages/community/)
-* [GitHub Issues](https://github.com/digitalrebar/provision/issues)
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
index e2ae7267bc..1bcdad0092 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
@@ -2,11 +2,11 @@
reviewers:
- sig-cluster-lifecycle
title: Customizing control plane configuration with kubeadm
-content_template: templates/concept
+content_type: concept
weight: 40
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.12" state="stable" >}}
@@ -30,9 +30,9 @@ For more details on each field in the configuration you can navigate to our
You can generate a `ClusterConfiguration` object with default values by running `kubeadm config print init-defaults` and saving the output to a file of your choice.
{{< /note >}}
-{{% /capture %}}
-{{% capture body %}}
+
+
## APIServer flags
@@ -83,4 +83,4 @@ scheduler:
kubeconfig: /home/johndoe/kubeconfig.yaml
```
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
index 2d38666386..1afd13c4e7 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@@ -2,11 +2,11 @@
reviewers:
- sig-cluster-lifecycle
title: Creating a single control-plane cluster with kubeadm
-content_template: templates/task
+content_type: task
weight: 30
---
-{{% capture overview %}}
+
The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
`kubeadm` also supports other cluster
@@ -24,9 +24,10 @@ of cloud servers, a Raspberry Pi, and more. Whether you're deploying into the
cloud or on-premises, you can integrate `kubeadm` into provisioning systems such
as Ansible or Terraform.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
To follow this guide, you need:
@@ -53,9 +54,9 @@ slightly as the tool evolves, but the overall implementation should be pretty st
Any commands under `kubeadm alpha` are, by definition, supported on an alpha level.
{{< /note >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Objectives
@@ -117,7 +118,7 @@ While `--apiserver-advertise-address` can be used to set the advertise address f
control-plane node's API server, `--control-plane-endpoint` can be used to set the shared endpoint
for all control-plane nodes.
-`--control-plane-endpoint` allows IP addresses but also DNS names that can map to IP addresses.
+`--control-plane-endpoint` allows both IP addresses and DNS names that can map to IP addresses.
Please contact your network administrator to evaluate possible solutions with respect to such mapping.
Here is an example mapping:
@@ -312,12 +313,11 @@ kubectl apply -f https://docs.projectcalico.org/v3.14/manifests/calico.yaml
{{% /tab %}}
{{% tab name="Cilium" %}}
-For Cilium to work correctly, you must pass `--pod-network-cidr=10.217.0.0/16` to `kubeadm init`.
To deploy Cilium you just need to run:
```shell
-kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml
+kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
```
Once all Cilium Pods are marked as `READY`, you start using your cluster.
@@ -495,10 +495,10 @@ and `scp` using that other user instead.
The `admin.conf` file gives the user _superuser_ privileges over the cluster.
This file should be used sparingly. For normal users, it's recommended to
-generate an unique credential to which you whitelist privileges. You can do
+generate an unique credential to which you grant privileges. You can do
this with the `kubeadm alpha kubeconfig user --client-name `
command. That command will print out a KubeConfig file to STDOUT which you
-should save to a file and distribute to your user. After that, whitelist
+should save to a file and distribute to your user. After that, grant
privileges by using `kubectl create (cluster)rolebinding`.
{{< /note >}}
@@ -531,10 +531,9 @@ Talking to the control-plane node with the appropriate credentials, run:
```bash
kubectl drain --delete-local-data --force --ignore-daemonsets
-kubectl delete node
```
-Then, on the node being removed, reset all `kubeadm` installed state:
+Before removing the node, reset the state installed by `kubeadm`:
```bash
kubeadm reset
@@ -552,6 +551,11 @@ If you want to reset the IPVS tables, you must run the following command:
ipvsadm -C
```
+Now remove the node:
+```bash
+kubectl delete node
+```
+
If you wish to start over simply run `kubeadm init` or `kubeadm join` with the
appropriate arguments.
@@ -564,9 +568,9 @@ See the [`kubeadm reset`](/docs/reference/setup-tools/kubeadm/kubeadm-reset/)
reference documentation for more information about this subcommand and its
options.
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## What's next {#whats-next}
@@ -641,4 +645,4 @@ supports your chosen platform.
If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/ha-topology.md b/content/en/docs/setup/production-environment/tools/kubeadm/ha-topology.md
index ec05ee12db..53b1f38024 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/ha-topology.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/ha-topology.md
@@ -2,11 +2,11 @@
reviewers:
- sig-cluster-lifecycle
title: Options for Highly Available topology
-content_template: templates/concept
+content_type: concept
weight: 50
---
-{{% capture overview %}}
+
This page explains the two options for configuring the topology of your highly available (HA) Kubernetes clusters.
@@ -22,9 +22,9 @@ kubeadm bootstraps the etcd cluster statically. Read the etcd [Clustering Guide]
for more details.
{{< /note >}}
-{{% /capture %}}
-{{% capture body %}}
+
+
## Stacked etcd topology
@@ -67,10 +67,11 @@ A minimum of three hosts for control plane nodes and three hosts for etcd nodes
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
- [Set up a highly available cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/)
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
index 162e60e175..5584309406 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
@@ -2,11 +2,11 @@
reviewers:
- sig-cluster-lifecycle
title: Creating Highly Available clusters with kubeadm
-content_template: templates/task
+content_type: task
weight: 60
---
-{{% capture overview %}}
+
This page explains two different approaches to setting up a highly available Kubernetes
cluster using kubeadm:
@@ -30,9 +30,10 @@ environment, neither approach documented here works with Service objects of type
LoadBalancer, or with dynamic PersistentVolumes.
{{< /caution >}}
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
For both methods you need this infrastructure:
@@ -50,9 +51,9 @@ For the external etcd cluster only, you also need:
- Three additional machines for etcd members
-{{% /capture %}}
-{{% capture steps %}}
+
+
## First steps for both methods
@@ -107,19 +108,20 @@ option. Your cluster requirements may need a different configuration.
sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
```
-
- You can use the `--kubernetes-version` flag to set the Kubernetes version to use.
- It is recommended that the versions of kubeadm, kubelet, kubectl and Kubernetes match.
+ It is recommended that the versions of kubeadm, kubelet, kubectl and Kubernetes match.
- The `--control-plane-endpoint` flag should be set to the address or DNS and port of the load balancer.
- The `--upload-certs` flag is used to upload the certificates that should be shared
- across all the control-plane instances to the cluster. If instead, you prefer to copy certs across
- control-plane nodes manually or using automation tools, please remove this flag and refer to [Manual
- certificate distribution](#manual-certs) section below.
+ across all the control-plane instances to the cluster. If instead, you prefer to copy certs across
+ control-plane nodes manually or using automation tools, please remove this flag and refer to [Manual
+ certificate distribution](#manual-certs) section below.
{{< note >}}
The `kubeadm init` flags `--config` and `--certificate-key` cannot be mixed, therefore if you want
- to use the [kubeadm configuration](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2) you must add the `certificateKey` field in the appropriate config locations (under `InitConfiguration` and `JoinConfiguration: controlPlane`).
+ to use the [kubeadm configuration](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)
+ you must add the `certificateKey` field in the appropriate config locations
+ (under `InitConfiguration` and `JoinConfiguration: controlPlane`).
{{< /note >}}
{{< note >}}
@@ -131,34 +133,34 @@ option. Your cluster requirements may need a different configuration.
- The output looks similar to:
-```sh
-...
-You can now join any number of control-plane node by running the following command on each as a root:
- kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
-
-Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
-As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward.
-
-Then you can join any number of worker nodes by running the following on each as root:
- kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
-```
+ ```sh
+ ...
+ You can now join any number of control-plane node by running the following command on each as a root:
+ kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
+
+ Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
+ As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward.
+
+ Then you can join any number of worker nodes by running the following on each as root:
+ kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
+ ```
- Copy this output to a text file. You will need it later to join control plane and worker nodes to the cluster.
- When `--upload-certs` is used with `kubeadm init`, the certificates of the primary control plane
- are encrypted and uploaded in the `kubeadm-certs` Secret.
+ are encrypted and uploaded in the `kubeadm-certs` Secret.
- To re-upload the certificates and generate a new decryption key, use the following command on a control plane
node that is already joined to the cluster:
- ```sh
- sudo kubeadm init phase upload-certs --upload-certs
- ```
+ ```sh
+ sudo kubeadm init phase upload-certs --upload-certs
+ ```
- You can also specify a custom `--certificate-key` during `init` that can later be used by `join`.
To generate such a key you can use the following command:
- ```sh
- kubeadm alpha certs certificate-key
- ```
+ ```sh
+ kubeadm alpha certs certificate-key
+ ```
{{< note >}}
The `kubeadm-certs` Secret and decryption key expire after two hours.
@@ -169,7 +171,8 @@ Then you can join any number of worker nodes by running the following on each as
{{< /caution >}}
1. Apply the CNI plugin of your choice:
- [Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network) to install the CNI provider. Make sure the configuration corresponds to the Pod CIDR specified in the kubeadm configuration file if applicable.
+ [Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)
+ to install the CNI provider. Make sure the configuration corresponds to the Pod CIDR specified in the kubeadm configuration file if applicable.
In this example we are using Weave Net:
@@ -202,7 +205,7 @@ For each additional control plane node you should:
- The `--control-plane` flag tells `kubeadm join` to create a new control plane.
- The `--certificate-key ...` will cause the control plane certificates to be downloaded
- from the `kubeadm-certs` Secret in the cluster and be decrypted using the given key.
+ from the `kubeadm-certs` Secret in the cluster and be decrypted using the given key.
## External etcd nodes
@@ -373,4 +376,4 @@ SSH is required if you want to control all nodes from a single machine.
# Quote this line if you are using external etcd
mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
```
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
index 9438e86140..c3e5f57c1c 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
@@ -1,6 +1,6 @@
---
title: Installing kubeadm
-content_template: templates/task
+content_type: task
weight: 10
card:
name: setup
@@ -8,14 +8,15 @@ card:
title: Install the kubeadm setup tool
---
-{{% capture overview %}}
+
This page shows how to install the `kubeadm` toolbox.
For information how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* One or more machines running one of:
- Ubuntu 16.04+
@@ -32,9 +33,9 @@ For information how to create a cluster with kubeadm once you have performed thi
* Certain ports are open on your machines. See [here](#check-required-ports) for more details.
* Swap disabled. You **MUST** disable swap in order for the kubelet to work properly.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Verify the MAC address and product_uuid are unique for every node {#verify-mac-address}
@@ -190,7 +191,7 @@ sudo apt-mark hold kubelet kubeadm kubectl
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
```bash
-cat < /etc/yum.repos.d/kubernetes.repo
+cat < /etc/systemd/system/kubelet.service
-mkdir -p /etc/systemd/system/kubelet.service.d
-curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
+curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service
+sudo mkdir -p /etc/systemd/system/kubelet.service.d
+curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
```
Enable and start `kubelet`:
@@ -301,8 +306,8 @@ like CRI-O and containerd is work in progress.
If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
-{{% capture whatsnext %}}
+## {{% heading "whatsnext" %}}
+
* [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
-{{% /capture %}}
\ No newline at end of file
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
index 070dbd7274..af4eb4a101 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
@@ -2,11 +2,11 @@
reviewers:
- sig-cluster-lifecycle
title: Configuring each kubelet in your cluster using kubeadm
-content_template: templates/concept
+content_type: concept
weight: 80
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.11" state="stable" >}}
@@ -26,9 +26,9 @@ characteristics of a given machine (such as OS, storage, and networking). You ca
of your kubelets manually, but kubeadm now provides a `KubeletConfiguration` API type for [managing your
kubelet configurations centrally](#configure-kubelets-using-kubeadm).
-{{% /capture %}}
-{{% capture body %}}
+
+
## Kubelet configuration patterns
@@ -173,7 +173,7 @@ Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably,
-#the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead.
+# the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead.
# KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
@@ -198,9 +198,8 @@ The DEB and RPM packages shipped with the Kubernetes releases are:
| Package name | Description |
|--------------|-------------|
| `kubeadm` | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. |
-| `kubelet` | Installs the `/usr/bin/kubelet` binary. |
+| `kubelet` | Installs the kubelet binary in `/usr/bin` and CNI binaries in `/opt/cni/bin`. |
| `kubectl` | Installs the `/usr/bin/kubectl` binary. |
-| `kubernetes-cni` | Installs the official CNI binaries into the `/opt/cni/bin` directory. |
| `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-incubator/cri-tools). |
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md b/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md
index 84c98ebe9c..334e2266f2 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md
@@ -2,11 +2,11 @@
reviewers:
- sig-cluster-lifecycle
title: Configuring your kubernetes cluster to self-host the control plane
-content_template: templates/concept
+content_type: concept
weight: 100
---
-{{% capture overview %}}
+
### Self-hosting the Kubernetes control plane {#self-hosting}
@@ -19,9 +19,9 @@ configured in the kubelet via static files.
To create a self-hosted cluster see the
[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command.
-{{% /capture %}}
-{{% capture body %}}
+
+
#### Caveats
@@ -67,4 +67,4 @@ In summary, `kubeadm alpha selfhosting` works as follows:
1. When the original static control plane stops, the new self-hosted control
plane is able to bind to listening ports and become active.
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
index 708e10569f..739b405d14 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
@@ -2,11 +2,11 @@
reviewers:
- sig-cluster-lifecycle
title: Set up a High Availability etcd cluster with kubeadm
-content_template: templates/task
+content_type: task
weight: 70
---
-{{% capture overview %}}
+
{{< note >}}
While kubeadm is being used as the management tool for external etcd nodes
@@ -23,9 +23,10 @@ becoming unavailable. This task walks through the process of creating a high
availability etcd cluster of three members that can be used as an external etcd
when using kubeadm to set up a kubernetes cluster.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* Three hosts that can talk to each other over ports 2379 and 2380. This
document assumes these default ports. However, they are configurable through
@@ -36,9 +37,9 @@ when using kubeadm to set up a kubernetes cluster.
[toolbox]: /docs/setup/production-environment/tools/kubeadm/install-kubeadm/
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Setting up the cluster
@@ -264,12 +265,13 @@ this example.
- Set `${ETCD_TAG}` to the version tag of your etcd image. For example `3.4.3-0`. To see the etcd image and tag that kubeadm uses execute `kubeadm config images list --kubernetes-version ${K8S_VERSION}`, where `${K8S_VERSION}` is for example `v1.17.0`
- Set `${HOST0}`to the IP address of the host you are testing.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Once you have a working 3 member etcd cluster, you can continue setting up a
highly available control plane using the [external etcd method with
kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/).
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
index 054f4b28fb..a4d6d54cc2 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
@@ -1,10 +1,10 @@
---
title: Troubleshooting kubeadm
-content_template: templates/concept
+content_type: concept
weight: 20
---
-{{% capture overview %}}
+
As with any program, you might run into an error installing or running kubeadm.
This page lists some common failure scenarios and have provided steps that can help you understand and fix the problem.
@@ -18,9 +18,9 @@ If your problem is not listed below, please follow the following steps:
- If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
relevant tags like `#kubernetes` and `#kubeadm` so folks can help you.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Not possible to join a v1.18 Node to a v1.17 cluster due to missing RBAC
@@ -131,7 +131,7 @@ sudo kubeadm reset
Inspecting the logs for docker may also be useful:
```sh
-journalctl -ul docker
+journalctl -u docker
```
## Pods in `RunContainerError`, `CrashLoopBackOff` or `Error` state
@@ -404,4 +404,4 @@ nodeRegistration:
Alternatively, you can modify `/etc/fstab` to make the `/usr` mount writeable, but please
be advised that this is modifying a design principle of the Linux distribution.
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md
index ae323d38cf..64ad3f4b1a 100644
--- a/content/en/docs/setup/production-environment/tools/kubespray.md
+++ b/content/en/docs/setup/production-environment/tools/kubespray.md
@@ -1,10 +1,10 @@
---
title: Installing Kubernetes with Kubespray
-content_template: templates/concept
+content_type: concept
weight: 30
---
-{{% capture overview %}}
+
This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray).
@@ -23,9 +23,9 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in
To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
-{{% /capture %}}
-{{% capture body %}}
+
+
## Creating a cluster
@@ -35,7 +35,7 @@ Provision servers with the following [requirements](https://github.com/kubernete
* **Ansible v2.7.8 and python-netaddr is installed on the machine that will run Ansible commands**
* **Jinja 2.9 (or newer) is required to run the Ansible Playbooks**
-* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/downloads.md#offline-environment))
+* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
* The target servers are configured to allow **IPv4 forwarding**
* **Your ssh key must be copied** to all the servers part of your inventory
* The **firewalls are not managed**, you'll need to implement your own rules the way you used to. in order to avoid any issue during deployment you should disable your firewall
@@ -113,10 +113,10 @@ When running the reset playbook, be sure not to accidentally target your product
* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](http://slack.k8s.io/))
* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md).
-{{% /capture %}}
\ No newline at end of file
diff --git a/content/en/docs/setup/production-environment/turnkey/aws.md b/content/en/docs/setup/production-environment/turnkey/aws.md
index 922f4a3eb9..cbfccd7a56 100644
--- a/content/en/docs/setup/production-environment/turnkey/aws.md
+++ b/content/en/docs/setup/production-environment/turnkey/aws.md
@@ -3,16 +3,17 @@ reviewers:
- justinsb
- clove
title: Running Kubernetes on AWS EC2
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page describes how to install a Kubernetes cluster on AWS.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secret Access Key from AWS.
@@ -22,15 +23,13 @@ To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secr
* [Kubernetes Operations](https://github.com/kubernetes/kops) - Production Grade K8s Installation, Upgrades, and Management. Supports running Debian, Ubuntu, CentOS, and RHEL in AWS.
-* [CoreOS Tectonic](https://coreos.com/tectonic/) includes the open-source [Tectonic Installer](https://github.com/coreos/tectonic-installer) that creates Kubernetes clusters with Container Linux nodes on AWS.
-
-* CoreOS originated and the Kubernetes Incubator maintains [a CLI tool, kube-aws](https://github.com/kubernetes-incubator/kube-aws), that creates and manages Kubernetes clusters with [Container Linux](https://coreos.com/why/) nodes, using AWS tools: EC2, CloudFormation and Autoscaling.
+* [kube-aws](https://github.com/kubernetes-incubator/kube-aws), creates and manages Kubernetes clusters with [Flatcar Linux](https://www.flatcar-linux.org/) nodes, using AWS tools: EC2, CloudFormation and Autoscaling.
* [KubeOne](https://github.com/kubermatic/kubeone) is an open source cluster lifecycle management tool that creates, upgrades and manages Kubernetes Highly-Available clusters.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Getting started with your cluster
@@ -90,4 +89,4 @@ AWS | KubeOne | Ubuntu, CoreOS, CentOS | canal, weave
Please see the [Kubernetes docs](/docs/) for more details on administering
and using a Kubernetes cluster.
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/production-environment/turnkey/clc.md b/content/en/docs/setup/production-environment/turnkey/clc.md
deleted file mode 100644
index 7bdec362e7..0000000000
--- a/content/en/docs/setup/production-environment/turnkey/clc.md
+++ /dev/null
@@ -1,340 +0,0 @@
----
-title: Running Kubernetes on CenturyLink Cloud
----
-
-
-These scripts handle the creation, deletion and expansion of Kubernetes clusters on CenturyLink Cloud.
-
-You can accomplish all these tasks with a single command. We have made the Ansible playbooks used to perform these tasks available [here](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md).
-
-## Find Help
-
-If you run into any problems or want help with anything, we are here to help. Reach out to use via any of the following ways:
-
-- Submit a github issue
-- Send an email to Kubernetes AT ctl DOT io
-- Visit [http://info.ctl.io/kubernetes](http://info.ctl.io/kubernetes)
-
-## Clusters of VMs or Physical Servers, your choice.
-
-- We support Kubernetes clusters on both Virtual Machines or Physical Servers. If you want to use physical servers for the worker nodes (minions), simple use the --minion_type=bareMetal flag.
-- For more information on physical servers, visit: [https://www.ctl.io/bare-metal/](https://www.ctl.io/bare-metal/)
-- Physical serves are only available in the VA1 and GB3 data centers.
-- VMs are available in all 13 of our public cloud locations
-
-## Requirements
-
-The requirements to run this script are:
-
-- A linux administrative host (tested on ubuntu and macOS)
-- python 2 (tested on 2.7.11)
- - pip (installed with python as of 2.7.9)
-- git
-- A CenturyLink Cloud account with rights to create new hosts
-- An active VPN connection to the CenturyLink Cloud from your linux host
-
-## Script Installation
-
-After you have all the requirements met, please follow these instructions to install this script.
-
-1) Clone this repository and cd into it.
-
-```shell
-git clone https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc
-```
-
-2) Install all requirements, including
-
- * Ansible
- * CenturyLink Cloud SDK
- * Ansible Modules
-
-```shell
-sudo pip install -r ansible/requirements.txt
-```
-
-3) Create the credentials file from the template and use it to set your ENV variables
-
-```shell
-cp ansible/credentials.sh.template ansible/credentials.sh
-vi ansible/credentials.sh
-source ansible/credentials.sh
-
-```
-
-4) Grant your machine access to the CenturyLink Cloud network by using a VM inside the network or [ configuring a VPN connection to the CenturyLink Cloud network.](https://www.ctl.io/knowledge-base/network/how-to-configure-client-vpn/)
-
-
-#### Script Installation Example: Ubuntu 14 Walkthrough
-
-If you use an ubuntu 14, for your convenience we have provided a step by step
-guide to install the requirements and install the script.
-
-```shell
-# system
-apt-get update
-apt-get install -y git python python-crypto
-curl -O https://bootstrap.pypa.io/get-pip.py
-python get-pip.py
-
-# installing this repository
-mkdir -p ~home/k8s-on-clc
-cd ~home/k8s-on-clc
-git clone https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc.git
-cd adm-kubernetes-on-clc/
-pip install -r requirements.txt
-
-# getting started
-cd ansible
-cp credentials.sh.template credentials.sh; vi credentials.sh
-source credentials.sh
-```
-
-
-
-## Cluster Creation
-
-To create a new Kubernetes cluster, simply run the ```kube-up.sh``` script. A complete
-list of script options and some examples are listed below.
-
-```shell
-CLC_CLUSTER_NAME=[name of kubernetes cluster]
-cd ./adm-kubernetes-on-clc
-bash kube-up.sh -c="$CLC_CLUSTER_NAME"
-```
-
-It takes about 15 minutes to create the cluster. Once the script completes, it
-will output some commands that will help you setup kubectl on your machine to
-point to the new cluster.
-
-When the cluster creation is complete, the configuration files for it are stored
-locally on your administrative host, in the following directory
-
-```shell
-> CLC_CLUSTER_HOME=$HOME/.clc_kube/$CLC_CLUSTER_NAME/
-```
-
-
-#### Cluster Creation: Script Options
-
-```shell
-Usage: kube-up.sh [OPTIONS]
-Create servers in the CenturyLinkCloud environment and initialize a Kubernetes cluster
-Environment variables CLC_V2_API_USERNAME and CLC_V2_API_PASSWD must be set in
-order to access the CenturyLinkCloud API
-
-All options (both short and long form) require arguments, and must include "="
-between option name and option value.
-
- -h (--help) display this help and exit
- -c= (--clc_cluster_name=) set the name of the cluster, as used in CLC group names
- -t= (--minion_type=) standard -> VM (default), bareMetal -> physical]
- -d= (--datacenter=) VA1 (default)
- -m= (--minion_count=) number of kubernetes minion nodes
- -mem= (--vm_memory=) number of GB ram for each minion
- -cpu= (--vm_cpu=) number of virtual cps for each minion node
- -phyid= (--server_conf_id=) physical server configuration id, one of
- physical_server_20_core_conf_id
- physical_server_12_core_conf_id
- physical_server_4_core_conf_id (default)
- -etcd_separate_cluster=yes create a separate cluster of three etcd nodes,
- otherwise run etcd on the master node
-```
-
-## Cluster Expansion
-
-To expand an existing Kubernetes cluster, run the ```add-kube-node.sh```
-script. A complete list of script options and some examples are listed [below](#cluster-expansion-script-options).
-This script must be run from the same host that created the cluster (or a host
-that has the cluster artifact files stored in ```~/.clc_kube/$cluster_name```).
-
-```shell
-cd ./adm-kubernetes-on-clc
-bash add-kube-node.sh -c="name_of_kubernetes_cluster" -m=2
-```
-
-#### Cluster Expansion: Script Options
-
-```shell
-Usage: add-kube-node.sh [OPTIONS]
-Create servers in the CenturyLinkCloud environment and add to an
-existing CLC kubernetes cluster
-
-Environment variables CLC_V2_API_USERNAME and CLC_V2_API_PASSWD must be set in
-order to access the CenturyLinkCloud API
-
- -h (--help) display this help and exit
- -c= (--clc_cluster_name=) set the name of the cluster, as used in CLC group names
- -m= (--minion_count=) number of kubernetes minion nodes to add
-```
-
-## Cluster Deletion
-
-There are two ways to delete an existing cluster:
-
-1) Use our python script:
-
-```shell
-python delete_cluster.py --cluster=clc_cluster_name --datacenter=DC1
-```
-
-2) Use the CenturyLink Cloud UI. To delete a cluster, log into the CenturyLink
-Cloud control portal and delete the parent server group that contains the
-Kubernetes Cluster. We hope to add a scripted option to do this soon.
-
-## Examples
-
-Create a cluster with name of k8s_1, 1 master node and 3 worker minions (on physical machines), in VA1
-
-```shell
-bash kube-up.sh --clc_cluster_name=k8s_1 --minion_type=bareMetal --minion_count=3 --datacenter=VA1
-```
-
-Create a cluster with name of k8s_2, an ha etcd cluster on 3 VMs and 6 worker minions (on VMs), in VA1
-
-```shell
-bash kube-up.sh --clc_cluster_name=k8s_2 --minion_type=standard --minion_count=6 --datacenter=VA1 --etcd_separate_cluster=yes
-```
-
-Create a cluster with name of k8s_3, 1 master node, and 10 worker minions (on VMs) with higher mem/cpu, in UC1:
-
-```shell
-bash kube-up.sh --clc_cluster_name=k8s_3 --minion_type=standard --minion_count=10 --datacenter=VA1 -mem=6 -cpu=4
-```
-
-
-
-## Cluster Features and Architecture
-
-We configure the Kubernetes cluster with the following features:
-
-* KubeDNS: DNS resolution and service discovery
-* Heapster/InfluxDB: For metric collection. Needed for Grafana and auto-scaling.
-* Grafana: Kubernetes/Docker metric dashboard
-* KubeUI: Simple web interface to view Kubernetes state
-* Kube Dashboard: New web interface to interact with your cluster
-
-We use the following to create the Kubernetes cluster:
-
-* Kubernetes 1.1.7
-* Ubuntu 14.04
-* Flannel 0.5.4
-* Docker 1.9.1-0~trusty
-* Etcd 2.2.2
-
-## Optional add-ons
-
-* Logging: We offer an integrated centralized logging ELK platform so that all
- Kubernetes and docker logs get sent to the ELK stack. To install the ELK stack
- and configure Kubernetes to send logs to it, follow [the log
- aggregation documentation](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/log_aggregration.md). Note: We don't install this by default as
- the footprint isn't trivial.
-
-## Cluster management
-
-The most widely used tool for managing a Kubernetes cluster is the command-line
-utility ```kubectl```. If you do not already have a copy of this binary on your
-administrative machine, you may run the script ```install_kubectl.sh``` which will
-download it and install it in ```/usr/bin/local```.
-
-The script requires that the environment variable ```CLC_CLUSTER_NAME``` be defined. ```install_kubectl.sh``` also writes a configuration file which will embed the necessary
-authentication certificates for the particular cluster. The configuration file is
-written to the ```${CLC_CLUSTER_HOME}/kube``` directory
-
-
-```shell
-export KUBECONFIG=${CLC_CLUSTER_HOME}/kube/config
-kubectl version
-kubectl cluster-info
-```
-
-### Accessing the cluster programmatically
-
-It's possible to use the locally stored client certificates to access the apiserver. For example, you may want to use any of the [Kubernetes API client libraries](/docs/reference/using-api/client-libraries/) to program against your Kubernetes cluster in the programming language of your choice.
-
-To demonstrate how to use these locally stored certificates, we provide the following example of using ```curl``` to communicate to the master apiserver via https:
-
-```shell
-curl \
- --cacert ${CLC_CLUSTER_HOME}/pki/ca.crt \
- --key ${CLC_CLUSTER_HOME}/pki/kubecfg.key \
- --cert ${CLC_CLUSTER_HOME}/pki/kubecfg.crt https://${MASTER_IP}:6443
-```
-
-But please note, this *does not* work out of the box with the ```curl``` binary
-distributed with macOS.
-
-### Accessing the cluster with a browser
-
-We install [the kubernetes dashboard](/docs/tasks/web-ui-dashboard/). When you
-create a cluster, the script should output URLs for these interfaces like this:
-
-kubernetes-dashboard is running at ```https://${MASTER_IP}:6443/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy```.
-
-Note on Authentication to the UIs:
-
-The cluster is set up to use basic authentication for the user _admin_.
-Hitting the url at ```https://${MASTER_IP}:6443``` will
-require accepting the self-signed certificate
-from the apiserver, and then presenting the admin
-password written to file at: ```> _${CLC_CLUSTER_HOME}/kube/admin_password.txt_```
-
-
-### Configuration files
-
-Various configuration files are written into the home directory *CLC_CLUSTER_HOME* under ```.clc_kube/${CLC_CLUSTER_NAME}``` in several subdirectories. You can use these files
-to access the cluster from machines other than where you created the cluster from.
-
-* ```config/```: Ansible variable files containing parameters describing the master and minion hosts
-* ```hosts/```: hosts files listing access information for the Ansible playbooks
-* ```kube/```: ```kubectl``` configuration files, and the basic-authentication password for admin access to the Kubernetes API
-* ```pki/```: public key infrastructure files enabling TLS communication in the cluster
-* ```ssh/```: SSH keys for root access to the hosts
-
-
-## ```kubectl``` usage examples
-
-There are a great many features of _kubectl_. Here are a few examples
-
-List existing nodes, pods, services and more, in all namespaces, or in just one:
-
-```shell
-kubectl get nodes
-kubectl get --all-namespaces pods
-kubectl get --all-namespaces services
-kubectl get --namespace=kube-system replicationcontrollers
-```
-
-The Kubernetes API server exposes services on web URLs, which are protected by requiring
-client certificates. If you run a kubectl proxy locally, ```kubectl``` will provide
-the necessary certificates and serve locally over http.
-
-```shell
-kubectl proxy -p 8001
-```
-
-Then, you can access urls like ```http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/``` without the need for client certificates in your browser.
-
-
-## What Kubernetes features do not work on CenturyLink Cloud
-
-These are the known items that don't work on CenturyLink cloud but do work on other cloud providers:
-
-- At this time, there is no support services of the type [LoadBalancer](/docs/tasks/access-application-cluster/create-external-load-balancer/). We are actively working on this and hope to publish the changes sometime around April 2016.
-
-- At this time, there is no support for persistent storage volumes provided by
- CenturyLink Cloud. However, customers can bring their own persistent storage
- offering. We ourselves use Gluster.
-
-
-## Ansible Files
-
-If you want more information about our Ansible files, please [read this file](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md)
-
-## Further reading
-
-Please see the [Kubernetes docs](/docs/) for more details on administering
-and using a Kubernetes cluster.
-
-
-
diff --git a/content/en/docs/setup/production-environment/turnkey/gce.md b/content/en/docs/setup/production-environment/turnkey/gce.md
index 7ec902d10b..60c4e690d9 100644
--- a/content/en/docs/setup/production-environment/turnkey/gce.md
+++ b/content/en/docs/setup/production-environment/turnkey/gce.md
@@ -5,16 +5,17 @@ reviewers:
- mikedanese
- thockin
title: Running Kubernetes on Google Compute Engine
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
The example below creates a Kubernetes cluster with 3 worker node Virtual Machines and a master Virtual Machine (i.e. 4 VMs in your cluster). This cluster is set up and controlled from your workstation (or wherever you find convenient).
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
If you want a simplified getting started experience and GUI for managing clusters, please consider trying [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) for hosted cluster installation and management.
@@ -36,9 +37,9 @@ If you want to use custom binaries or pure open source Kubernetes, please contin
1. Make sure you can start up a GCE VM from the command line. At least make sure you can do the [Create an instance](https://cloud.google.com/compute/docs/instances/#startinstancegcloud) part of the GCE Quickstart.
1. Make sure you can SSH into the VM without interactive prompts. See the [Log in to the instance](https://cloud.google.com/compute/docs/instances/#sshing) part of the GCE Quickstart.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Starting a cluster
@@ -225,4 +226,4 @@ GCE | Saltstack | Debian | GCE | [docs](/docs/setup/
Please see the [Kubernetes docs](/docs/) for more details on administering
and using a Kubernetes cluster.
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/production-environment/turnkey/icp.md b/content/en/docs/setup/production-environment/turnkey/icp.md
index 81375ad370..1ebb7a9267 100644
--- a/content/en/docs/setup/production-environment/turnkey/icp.md
+++ b/content/en/docs/setup/production-environment/turnkey/icp.md
@@ -27,13 +27,9 @@ The following modules are available where you can deploy IBM Cloud Private by us
## IBM Cloud Private on AWS
-You can deploy an IBM Cloud Private cluster on Amazon Web Services (AWS) by using either AWS CloudFormation or Terraform.
+You can deploy an IBM Cloud Private cluster on Amazon Web Services (AWS) using Terraform.
-IBM Cloud Private has a Quick Start that automatically deploys IBM Cloud Private into a new virtual private cloud (VPC) on the AWS Cloud. A regular deployment takes about 60 minutes, and a high availability (HA) deployment takes about 75 minutes to complete. The Quick Start includes AWS CloudFormation templates and a deployment guide.
-
-This Quick Start is for users who want to explore application modernization and want to accelerate meeting their digital transformation goals, by using IBM Cloud Private and IBM tooling. The Quick Start helps users rapidly deploy a high availability (HA), production-grade, IBM Cloud Private reference architecture on AWS. For all of the details and the deployment guide, see the [IBM Cloud Private on AWS Quick Start](https://aws.amazon.com/quickstart/architecture/ibm-cloud-private/).
-
-IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To deploy IBM Cloud Private in an AWS EC2 environment, see [Installing IBM Cloud Private on AWS](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_aws.md).
+IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To deploy IBM Cloud Private in an AWS EC2 environment, see [Installing IBM Cloud Private on AWS](https://github.com/ibm-cloud-architecture/terraform-icp-aws).
## IBM Cloud Private on Azure
diff --git a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
index 78e61d4588..09a74d1450 100644
--- a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
+++ b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
@@ -3,17 +3,17 @@ reviewers:
- michmike
- patricklang
title: Intro to Windows support in Kubernetes
-content_template: templates/concept
+content_type: concept
weight: 65
---
-{{% capture overview %}}
+
Windows applications constitute a large portion of the services and applications that run in many organizations. [Windows containers](https://aka.ms/windowscontainers) provide a modern way to encapsulate processes and package dependencies, making it easier to use DevOps practices and follow cloud native patterns for Windows applications. Kubernetes has become the defacto standard container orchestrator, and the release of Kubernetes 1.14 includes production support for scheduling Windows containers on Windows nodes in a Kubernetes cluster, enabling a vast ecosystem of Windows applications to leverage the power of Kubernetes. Organizations with investments in Windows-based applications and Linux-based applications don't have to look for separate orchestrators to manage their workloads, leading to increased operational efficiencies across their deployments, regardless of operating system.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Windows containers in Kubernetes
@@ -584,9 +584,10 @@ If filing a bug, please include detailed information about how to reproduce the
* [Relevant logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)
* Tag the issue sig/windows by commenting on the issue with `/sig windows` to bring it to a SIG-Windows member's attention
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
We have a lot of features in our roadmap. An abbreviated high level list is included below, but we encourage you to view our [roadmap project](https://github.com/orgs/kubernetes/projects/8) and help us make Windows support better by [contributing](https://github.com/kubernetes/community/blob/master/sig-windows/).
@@ -638,4 +639,4 @@ properly provisioned.
* More CNIs
* More Storage Plugins
-{{% /capture %}}
+
diff --git a/content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md
index aa1c1f3783..e28afeb9f2 100644
--- a/content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md
+++ b/content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md
@@ -3,17 +3,17 @@ reviewers:
- michmike
- patricklang
title: Guide for scheduling Windows containers in Kubernetes
-content_template: templates/concept
+content_type: concept
weight: 75
---
-{{% capture overview %}}
+
Windows applications constitute a large portion of the services and applications that run in many organizations. This guide walks you through the steps to configure and deploy a Windows container in Kubernetes.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Objectives
@@ -245,6 +245,6 @@ spec:
```
-{{% /capture %}}
+
[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/
diff --git a/content/en/docs/setup/release/notes.md b/content/en/docs/setup/release/notes.md
index a344a11fc0..d80d6c0ffd 100644
--- a/content/en/docs/setup/release/notes.md
+++ b/content/en/docs/setup/release/notes.md
@@ -2,7 +2,7 @@
title: v1.18 Release Notes
weight: 10
card:
- name: download
+ name: release-notes
weight: 20
anchors:
- anchor: "#"
diff --git a/content/en/docs/setup/release/version-skew-policy.md b/content/en/docs/setup/release/version-skew-policy.md
index dc411807c5..cc506352d3 100644
--- a/content/en/docs/setup/release/version-skew-policy.md
+++ b/content/en/docs/setup/release/version-skew-policy.md
@@ -7,16 +7,16 @@ reviewers:
- sig-node
- sig-release
title: Kubernetes version and version skew support policy
-content_template: templates/concept
+content_type: concept
weight: 30
---
-{{% capture overview %}}
+
This document describes the maximum version skew supported between various Kubernetes components.
Specific cluster deployment tools may place additional restrictions on version skew.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Supported versions
@@ -27,11 +27,11 @@ For more information, see [Kubernetes Release Versioning](https://github.com/kub
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}).
Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility.
-Patch releases are cut from those branches at a regular cadence, or as needed.
-This decision is owned by the [patch release team](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-team.md#release-timing).
-The patch release team is part of [release managers](https://github.com/kubernetes/sig-release/blob/master/release-managers.md). For more information, see [Kubernetes Patch releases](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md).
+Patch releases are cut from those branches at a [regular cadence](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence), plus additional urgent releases, when required.
-Minor releases occur approximately every 3 months, so each minor release branch is maintained for approximately 9 months.
+The [Release Managers](https://git.k8s.io/sig-release/release-managers.md) group owns this decision.
+
+For more information, see the Kubernetes [patch releases](https://git.k8s.io/sig-release/releases/patch-releases.md) page.
## Supported version skew
diff --git a/content/en/docs/tasks/_index.md b/content/en/docs/tasks/_index.md
index 1dee1f38f1..552f17e48c 100644
--- a/content/en/docs/tasks/_index.md
+++ b/content/en/docs/tasks/_index.md
@@ -2,82 +2,18 @@
title: Tasks
main_menu: true
weight: 50
-content_template: templates/concept
+content_type: concept
---
-{{< toc >}}
-
-{{% capture overview %}}
+
This section of the Kubernetes documentation contains pages that
show how to do individual tasks. A task page shows how to do a
single thing, typically by giving a short sequence of steps.
-{{% /capture %}}
-{{% capture body %}}
+## {{% heading "whatsnext" %}}
-## Web UI (Dashboard)
-
-Deploy and access the Dashboard web user interface to help you manage and monitor containerized applications in a Kubernetes cluster.
-
-## Using the kubectl Command-line
-
-Install and setup the `kubectl` command-line tool used to directly manage Kubernetes clusters.
-
-## Configuring Pods and Containers
-
-Perform common configuration tasks for Pods and Containers.
-
-## Running Applications
-
-Perform common application management tasks, such as rolling updates, injecting information into pods, and horizontal Pod autoscaling.
-
-## Running Jobs
-
-Run Jobs using parallel processing.
-
-## Accessing Applications in a Cluster
-
-Configure load balancing, port forwarding, or setup firewall or DNS configurations to access applications in a cluster.
-
-## Monitoring, Logging, and Debugging
-
-Setup monitoring and logging to troubleshoot a cluster or debug a containerized application.
-
-## Accessing the Kubernetes API
-
-Learn various methods to directly access the Kubernetes API.
-
-## Using TLS
-
-Configure your application to trust and use the cluster root Certificate Authority (CA).
-
-## Administering a Cluster
-
-Learn common tasks for administering a cluster.
-
-## Managing Stateful Applications
-
-Perform common tasks for managing Stateful applications, including scaling, deleting, and debugging StatefulSets.
-
-## Cluster Daemons
-
-Perform common tasks for managing a DaemonSet, such as performing a rolling update.
-
-## Managing GPUs
-
-Configure and schedule NVIDIA GPUs for use as a resource by nodes in a cluster.
-
-## Managing HugePages
-
-Configure and schedule huge pages as a schedulable resource in a cluster.
-
-{{% /capture %}}
-
-{{% capture whatsnext %}}
If you would like to write a task page, see
[Creating a Documentation Pull Request](/docs/home/contribute/create-pull-request/).
-
-{{% /capture %}}
diff --git a/content/en/docs/tasks/access-application-cluster/_index.md b/content/en/docs/tasks/access-application-cluster/_index.md
index e829d22b29..4d7af48310 100755
--- a/content/en/docs/tasks/access-application-cluster/_index.md
+++ b/content/en/docs/tasks/access-application-cluster/_index.md
@@ -1,5 +1,6 @@
---
title: "Access Applications in a Cluster"
+description: Configure load balancing, port forwarding, or setup firewall or DNS configurations to access applications in a cluster.
weight: 60
---
diff --git a/content/en/docs/tasks/access-application-cluster/access-cluster.md b/content/en/docs/tasks/access-application-cluster/access-cluster.md
index 05835f2b08..39ad8b4b7e 100644
--- a/content/en/docs/tasks/access-application-cluster/access-cluster.md
+++ b/content/en/docs/tasks/access-application-cluster/access-cluster.md
@@ -1,17 +1,17 @@
---
title: Accessing Clusters
weight: 20
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
This topic discusses multiple ways to interact with clusters.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Accessing for the first time with kubectl
@@ -376,4 +376,3 @@ There are several different proxies you may encounter when using Kubernetes:
Kubernetes users will typically not need to worry about anything other than the first two types. The cluster admin
will typically ensure that the latter types are setup correctly.
-{{% /capture %}}
\ No newline at end of file
diff --git a/content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
index 33547cdca6..1d00516d28 100644
--- a/content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
+++ b/content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
@@ -1,25 +1,26 @@
---
title: Communicate Between Containers in the Same Pod Using a Shared Volume
-content_template: templates/task
+content_type: task
weight: 110
---
-{{% capture overview %}}
+
This page shows how to use a Volume to communicate between two Containers running
in the same Pod. See also how to allow processes to communicate by [sharing process namespace](/docs/tasks/configure-pod-container/share-process-namespace/) between containers.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Creating a Pod that runs two Containers
@@ -108,10 +109,10 @@ The output shows that nginx serves a web page written by the debian container:
Hello from the debian container
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Discussion
@@ -127,10 +128,11 @@ The Volume in this exercise provides a way for Containers to communicate during
the life of the Pod. If the Pod is deleted and recreated, any data stored in
the shared Volume is lost.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about
[patterns for composite containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).
@@ -147,7 +149,7 @@ the shared Volume is lost.
* See [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
index acd023548a..3f3100395c 100644
--- a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+++ b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
@@ -1,6 +1,6 @@
---
title: Configure Access to Multiple Clusters
-content_template: templates/task
+content_type: task
weight: 30
card:
name: tasks
@@ -8,7 +8,7 @@ card:
---
-{{% capture overview %}}
+
This page shows how to configure access to multiple clusters by using
configuration files. After your clusters, users, and contexts are defined in
@@ -21,15 +21,21 @@ a *kubeconfig file*. This is a generic way of referring to configuration files.
It does not mean that there is a file named `kubeconfig`.
{{< /note >}}
-{{% /capture %}}
-{{% capture prerequisites %}}
-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+## {{% heading "prerequisites" %}}
-{{% /capture %}}
-{{% capture steps %}}
+{{< include "task-tutorial-prereqs.md" >}}
+
+To check that {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} is installed,
+run `kubectl version --client`. The kubectl version should be
+[within one minor version](/docs/setup/release/version-skew-policy/#kubectl) of your
+cluster's API server.
+
+
+
+
## Define clusters, users, and contexts
@@ -369,14 +375,15 @@ export KUBECONFIG=$KUBECONFIG_SAVED
$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [Organizing Cluster Access Using kubeconfig Files](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md b/content/en/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md
deleted file mode 100644
index 0ab9428a36..0000000000
--- a/content/en/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md
+++ /dev/null
@@ -1,109 +0,0 @@
----
-reviewers:
-- bprashanth
-- davidopp
-title: Configure Your Cloud Provider's Firewalls
-content_template: templates/task
-weight: 90
----
-
-{{% capture overview %}}
-
-Many cloud providers (e.g. Google Compute Engine) define firewalls that help prevent inadvertent
-exposure to the internet. When exposing a service to the external world, you may need to open up
-one or more ports in these firewalls to serve traffic. This document describes this process, as
-well as any provider specific details that may be necessary.
-
-{{% /capture %}}
-
-
-{{% capture prerequisites %}}
-
-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-{{% /capture %}}
-
-{{% capture steps %}}
-
-## Restrict Access For LoadBalancer Service
-
- When using a Service with `spec.type: LoadBalancer`, you can specify the IP ranges that are allowed to access the load balancer
- by using `spec.loadBalancerSourceRanges`. This field takes a list of IP CIDR ranges, which Kubernetes will use to configure firewall exceptions.
- This feature is currently supported on Google Compute Engine, Google Kubernetes Engine, AWS Elastic Kubernetes Service, Azure Kubernetes Service, and IBM Cloud Kubernetes Service. This field will be ignored if the cloud provider does not support the feature.
-
- Assuming 10.0.0.0/8 is the internal subnet. In the following example, a load balancer will be created that is only accessible to cluster internal IPs.
- This will not allow clients from outside of your Kubernetes cluster to access the load balancer.
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
- name: myapp
-spec:
- ports:
- - port: 8765
- targetPort: 9376
- selector:
- app: example
- type: LoadBalancer
- loadBalancerSourceRanges:
- - 10.0.0.0/8
-```
-
- In the following example, a load balancer will be created that is only accessible to clients with IP addresses from 130.211.204.1 and 130.211.204.2.
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
- name: myapp
-spec:
- ports:
- - port: 8765
- targetPort: 9376
- selector:
- app: example
- type: LoadBalancer
- loadBalancerSourceRanges:
- - 130.211.204.1/32
- - 130.211.204.2/32
-```
-
-## Google Compute Engine
-
-When using a Service with `spec.type: LoadBalancer`, the firewall will be
-opened automatically. When using `spec.type: NodePort`, however, the firewall
-is *not* opened by default.
-
-Google Compute Engine firewalls are documented [elsewhere](https://cloud.google.com/compute/docs/networking#firewalls_1).
-
-You can add a firewall with the `gcloud` command line tool:
-
-```shell
-gcloud compute firewall-rules create my-rule --allow=tcp:
-```
-
-{{< note >}}
-GCE firewalls are defined per-vm, rather than per-ip address. This means that
-when you open a firewall for a service's ports, anything that serves on that
-port on that VM's host IP address may potentially serve traffic. Note that this
-is not a problem for other Kubernetes services, as they listen on IP addresses
-that are different than the host node's external IP address.
-
-Consider:
-
- * You create a Service with an external load balancer (IP Address 1.2.3.4)
- and port 80
- * You open the firewall for port 80 for all nodes in your cluster, so that
- the external Service actually can deliver packets to your Service
- * You start an nginx server, running on port 80 on the host virtual machine
- (IP Address 2.3.4.5). This nginx is also exposed to the internet on
- the VM's external IP address.
-
-Consequently, please be careful when opening firewalls in Google Compute Engine
-or Google Kubernetes Engine. You may accidentally be exposing other services to
-the wilds of the internet.
-
-{{< /note >}}
-
-{{% /capture %}}
diff --git a/content/en/docs/tasks/access-application-cluster/configure-dns-cluster.md b/content/en/docs/tasks/access-application-cluster/configure-dns-cluster.md
index 4c17d3128d..3535fdb8bc 100644
--- a/content/en/docs/tasks/access-application-cluster/configure-dns-cluster.md
+++ b/content/en/docs/tasks/access-application-cluster/configure-dns-cluster.md
@@ -1,13 +1,13 @@
---
title: Configure DNS for a Cluster
weight: 120
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
Kubernetes offers a DNS cluster addon, which most of the supported environments enable by default. In Kubernetes version 1.11 and later, CoreDNS is recommended and is installed by default with kubeadm.
-{{% /capture %}}
-{{% capture body %}}
+
+
For more information on how to configure CoreDNS for a Kubernetes cluster, see the [Customizing DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/). An example demonstrating how to use Kubernetes DNS with kube-dns, see the [Kubernetes DNS sample plugin](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md
index 264d930d5f..0ce827185c 100644
--- a/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md
+++ b/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md
@@ -1,30 +1,32 @@
---
title: Connect a Front End to a Back End Using a Service
-content_template: templates/tutorial
+content_type: tutorial
weight: 70
---
-{{% capture overview %}}
+
This task shows how to create a frontend and a backend
microservice. The backend microservice is a hello greeter. The
frontend and backend are connected using a Kubernetes
{{< glossary_tooltip term_id="service" >}} object.
-{{% /capture %}}
-{{% capture objectives %}}
+
+## {{% heading "objectives" %}}
+
* Create and run a microservice using a {{< glossary_tooltip term_id="deployment" >}} object.
* Route traffic to the backend using a frontend.
* Use a Service object to connect the frontend application to the
backend application.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
@@ -34,10 +36,10 @@ frontend and backend are connected using a Kubernetes
support this, you can use a Service of type
[NodePort](/docs/concepts/services-networking/service/#nodeport) instead.
-{{% /capture %}}
-{{% capture lessoncontent %}}
+
+
## Creating the backend using a Deployment
@@ -201,9 +203,10 @@ The output shows the message generated by the backend:
{"message":"Hello"}
```
-{{% /capture %}}
-{{% capture cleanup %}}
+
+## {{% heading "cleanup" %}}
+
To delete the Services, enter this command:
@@ -213,13 +216,14 @@ To delete the Deployments, the ReplicaSets and the Pods that are running the bac
kubectl delete deployment frontend hello
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [Services](/docs/concepts/services-networking/service/)
* Learn more about [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md
index 720203d60d..7dcc613232 100644
--- a/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md
+++ b/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md
@@ -1,11 +1,11 @@
---
title: Create an External Load Balancer
-content_template: templates/task
+content_type: task
weight: 80
---
-{{% capture overview %}}
+
This page shows how to create an External Load Balancer.
@@ -24,15 +24,16 @@ services externally-reachable URLs, load balance the traffic, terminate SSL etc.
please check the [Ingress](/docs/concepts/services-networking/ingress/)
documentation.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Configuration file
@@ -199,4 +200,4 @@ Once the external load balancers provide weights, this functionality can be adde
Internal pod to pod traffic should behave similar to ClusterIP services, with equal probability across all pods.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
index 0a16c71064..9288ec3064 100644
--- a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
+++ b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
@@ -1,25 +1,26 @@
---
title: Set up Ingress on Minikube with the NGINX Ingress Controller
-content_template: templates/task
+content_type: task
weight: 100
---
-{{% capture overview %}}
+
An [Ingress](/docs/concepts/services-networking/ingress/) is an API object that defines rules which allow external access
to services in a cluster. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers/) fulfills the rules set in the Ingress.
This page shows you how to set up a simple Ingress which routes requests to Service web or web2 depending on the HTTP URI.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create a Minikube cluster
@@ -275,13 +276,14 @@ The following file is an Ingress resource that sends traffic to your Service via
{{< note >}}If you are running Minikube locally, you can visit hello-world.info and hello-world.info/v2 from your browser.{{< /note >}}
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Read more about [Ingress](/docs/concepts/services-networking/ingress/)
* Read more about [Ingress Controllers](/docs/concepts/services-networking/ingress-controllers/)
* Read more about [Services](/docs/concepts/services-networking/service/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md
index b3fb886d11..d1e1ba1568 100644
--- a/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md
+++ b/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md
@@ -1,23 +1,24 @@
---
title: List All Container Images Running in a Cluster
-content_template: templates/task
+content_type: task
weight: 100
---
-{{% capture overview %}}
+
This page shows how to use kubectl to list all of the Container images
for Pods running in a cluster.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
In this exercise you will use kubectl to fetch all of the Pods
running in a cluster, and format the output to pull out the list
@@ -108,19 +109,20 @@ kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{r
-{{% /capture %}}
-{{% capture discussion %}}
-{{% /capture %}}
+
+
+
+
+## {{% heading "whatsnext" %}}
-{{% capture whatsnext %}}
### Reference
* [Jsonpath](/docs/user-guide/jsonpath/) reference guide
* [Go template](https://golang.org/pkg/text/template/) reference guide
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md b/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
index fc24022d0c..a6c2e217a5 100644
--- a/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
+++ b/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
@@ -1,29 +1,30 @@
---
title: Use Port Forwarding to Access Applications in a Cluster
-content_template: templates/task
+content_type: task
weight: 40
min-kubernetes-server-version: v1.10
---
-{{% capture overview %}}
+
This page shows how to use `kubectl port-forward` to connect to a Redis
server running in a Kubernetes cluster. This type of connection can be useful
for database debugging.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* Install [redis-cli](http://redis.io/topics/rediscli).
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Creating Redis deployment and service
@@ -179,10 +180,10 @@ for database debugging.
PONG
```
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Discussion
@@ -196,9 +197,10 @@ The support for UDP protocol is tracked in
[issue 47862](https://github.com/kubernetes/kubernetes/issues/47862).
{{< /note >}}
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Learn more about [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md
index af5eb2db86..fe90981432 100644
--- a/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md
+++ b/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md
@@ -1,35 +1,37 @@
---
title: Use a Service to Access an Application in a Cluster
-content_template: templates/tutorial
+content_type: tutorial
weight: 60
---
-{{% capture overview %}}
+
This page shows how to create a Kubernetes Service object that external
clients can use to access an application running in a cluster. The Service
provides load balancing for an application that has two running instances.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture objectives %}}
+
+## {{% heading "objectives" %}}
+
* Run two instances of a Hello World application.
* Create a Service object that exposes a node port.
* Use the Service object to access the running application.
-{{% /capture %}}
-{{% capture lessoncontent %}}
+
+
## Creating a service for an application running in two pods
@@ -130,10 +132,11 @@ As an alternative to using `kubectl expose`, you can use a
[service configuration file](/docs/concepts/services-networking/service/)
to create a Service.
-{{% /capture %}}
-{{% capture cleanup %}}
+
+## {{% heading "cleanup" %}}
+
To delete the Service, enter this command:
@@ -144,11 +147,12 @@ the Hello World application, enter this command:
kubectl delete deployment hello-world
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Learn more about
[connecting applications with services](/docs/concepts/services-networking/connect-applications-service/).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md
index 88132f5218..6d7c1cced2 100644
--- a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md
+++ b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md
@@ -4,7 +4,7 @@ reviewers:
- mikedanese
- rf232
title: Web UI (Dashboard)
-content_template: templates/concept
+content_type: concept
weight: 10
card:
name: tasks
@@ -12,7 +12,7 @@ card:
title: Use the Web UI Dashboard
---
-{{% capture overview %}}
+
Dashboard is a web-based Kubernetes user interface. You can use Dashboard to deploy containerized applications to a Kubernetes cluster, troubleshoot your containerized application, and manage the cluster resources. You can use Dashboard to get an overview of applications running on your cluster, as well as for creating or modifying individual Kubernetes resources (such as Deployments, Jobs, DaemonSets, etc). For example, you can scale a Deployment, initiate a rolling update, restart a pod or deploy new applications using a deploy wizard.
@@ -20,10 +20,10 @@ Dashboard also provides information on the state of Kubernetes resources in your
-{{% /capture %}}
-{{% capture body %}}
+
+
## Deploying the Dashboard UI
@@ -83,7 +83,11 @@ The deploy wizard expects that you provide the following information:
A [Deployment](/docs/concepts/workloads/controllers/deployment/) will be created to maintain the desired number of Pods across your cluster.
-- **Service** (optional): For some parts of your application (e.g. frontends) you may want to expose a [Service](/docs/concepts/services-networking/service/) onto an external, maybe public IP address outside of your cluster (external Service). For external Services, you may need to open up one or more ports to do so. Find more details [here](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/).
+- **Service** (optional): For some parts of your application (e.g. frontends) you may want to expose a [Service](/docs/concepts/services-networking/service/) onto an external, maybe public IP address outside of your cluster (external Service).
+
+ {{< note >}}
+ For external Services, you may need to open up one or more ports to do so.
+ {{< /note >}}
Other Services that are only visible from inside the cluster are called internal Services.
@@ -97,12 +101,12 @@ If needed, you can expand the **Advanced options** section where you can specify
Example:
-```conf
-release=1.0
-tier=frontend
-environment=pod
-track=stable
-```
+ ```conf
+ release=1.0
+ tier=frontend
+ environment=pod
+ track=stable
+ ```
- **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called [namespaces](/docs/tasks/administer-cluster/namespaces/). They let you partition resources into logically named groups.
@@ -162,11 +166,12 @@ Pod lists and detail pages link to a logs viewer that is built into Dashboard. T
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
For more information, see the
[Kubernetes Dashboard project page](https://github.com/kubernetes/dashboard).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/access-kubernetes-api/_index.md b/content/en/docs/tasks/access-kubernetes-api/_index.md
deleted file mode 100755
index f883cdee9d..0000000000
--- a/content/en/docs/tasks/access-kubernetes-api/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: "Extend Kubernetes"
-weight: 90
----
-
diff --git a/content/en/docs/tasks/administer-cluster/_index.md b/content/en/docs/tasks/administer-cluster/_index.md
index 55154406fe..6d869da354 100755
--- a/content/en/docs/tasks/administer-cluster/_index.md
+++ b/content/en/docs/tasks/administer-cluster/_index.md
@@ -1,5 +1,6 @@
---
title: "Administer a Cluster"
+description: Learn common tasks for administering a cluster.
weight: 20
---
diff --git a/content/en/docs/tasks/administer-cluster/access-cluster-api.md b/content/en/docs/tasks/administer-cluster/access-cluster-api.md
index 5aa79d4406..659c8d777c 100644
--- a/content/en/docs/tasks/administer-cluster/access-cluster-api.md
+++ b/content/en/docs/tasks/administer-cluster/access-cluster-api.md
@@ -1,18 +1,19 @@
---
title: Access Clusters Using the Kubernetes API
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page shows how to access clusters using the Kubernetes API.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Accessing the Kubernetes API
@@ -269,8 +270,8 @@ public class KubeConfigFileClientExample {
CoreV1Api api = new CoreV1Api();
// invokes the CoreV1Api client
- V1PodList list = api.listPodForAllNamespaces(null, null, null, null, null, null, null, null);
- System.out.Println("Listing all pods: ");
+ V1PodList list = api.listPodForAllNamespaces(null, null, null, null, null, null, null, null, null);
+ System.out.println("Listing all pods: ");
for (V1Pod item : list.getItems()) {
System.out.println(item.getMetadata().getName());
}
@@ -449,5 +450,5 @@ The output will be similar to this:
}
```
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/access-cluster-services.md b/content/en/docs/tasks/administer-cluster/access-cluster-services.md
index 57cdc835de..979a75a162 100644
--- a/content/en/docs/tasks/administer-cluster/access-cluster-services.md
+++ b/content/en/docs/tasks/administer-cluster/access-cluster-services.md
@@ -1,18 +1,19 @@
---
title: Access Services Running on Clusters
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page shows how to connect to services running on the Kubernetes cluster.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Accessing services running on the cluster
@@ -132,6 +133,6 @@ You may be able to put an apiserver proxy URL into the address bar of a browser.
- Some web apps may not work, particularly those with client side javascript that construct URLs in a
way that is unaware of the proxy path prefix.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/change-default-storage-class.md b/content/en/docs/tasks/administer-cluster/change-default-storage-class.md
index a2070bcfe3..9c08a2a4ad 100644
--- a/content/en/docs/tasks/administer-cluster/change-default-storage-class.md
+++ b/content/en/docs/tasks/administer-cluster/change-default-storage-class.md
@@ -1,21 +1,22 @@
---
title: Change the default StorageClass
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page shows how to change the default Storage Class that is used to
provision volumes for PersistentVolumeClaims that have no special requirements.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Why change the default storage class?
@@ -23,7 +24,7 @@ Depending on the installation method, your Kubernetes cluster may be deployed wi
an existing StorageClass that is marked as default. This default StorageClass
is then used to dynamically provision storage for PersistentVolumeClaims
that do not require any specific storage class. See
-[PersistentVolumeClaim documentation](/docs/concepts/storage/persistent-volumes/#class-1)
+[PersistentVolumeClaim documentation](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
for details.
The pre-installed default StorageClass may not fit well with your expected workload;
@@ -93,10 +94,11 @@ for details about addon manager and how to disable individual addons.
gold (default) kubernetes.io/gce-pd 1d
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
index a7ac4d80c9..729c7bde4f 100644
--- a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
+++ b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
@@ -1,20 +1,21 @@
---
title: Change the Reclaim Policy of a PersistentVolume
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page shows how to change the reclaim policy of a Kubernetes
PersistentVolume.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Why change reclaim policy of a PersistentVolume
@@ -80,9 +81,10 @@ kubectl patch pv -p "{\"spec\":{\"persistentVolumeReclaimPolicy\"
`default/claim3` has reclaim policy `Retain`. It will not be automatically
deleted when a user deletes claim `default/claim3`.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
* Learn more about [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).
@@ -91,6 +93,6 @@ kubectl patch pv -p "{\"spec\":{\"persistentVolumeReclaimPolicy\"
* [PersistentVolume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core)
* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
* See the `persistentVolumeReclaimPolicy` field of [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/cluster-management.md b/content/en/docs/tasks/administer-cluster/cluster-management.md
index 65728ec4ee..7cbab3aa2c 100644
--- a/content/en/docs/tasks/administer-cluster/cluster-management.md
+++ b/content/en/docs/tasks/administer-cluster/cluster-management.md
@@ -3,20 +3,20 @@ reviewers:
- lavalamp
- thockin
title: Cluster Management
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
This document describes several topics related to the lifecycle of a cluster: creating a new cluster,
upgrading your cluster's
master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a
running cluster.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Creating and configuring a Cluster
@@ -224,4 +224,4 @@ kubectl convert -f pod.yaml --output-version v1
For more options, please refer to the usage of [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) command.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
index 73cecd999b..91661d235f 100644
--- a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
+++ b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
@@ -3,23 +3,24 @@ reviewers:
- mml
- wojtek-t
title: Operating etcd clusters for Kubernetes
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
{{< glossary_definition term_id="etcd" length="all" prepend="etcd is a ">}}
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Prerequisites
@@ -238,4 +239,4 @@ To urgently fix this bug for Kubernetes 1.15 or earlier, build a custom kube-api
See ["kube-apiserver 1.13.x refuses to work when first etcd-server is not available"](https://github.com/kubernetes/kubernetes/issues/72102).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/coredns.md b/content/en/docs/tasks/administer-cluster/coredns.md
index 2e50d54f06..32d4f7d7ec 100644
--- a/content/en/docs/tasks/administer-cluster/coredns.md
+++ b/content/en/docs/tasks/administer-cluster/coredns.md
@@ -3,18 +3,19 @@ reviewers:
- johnbelamaric
title: Using CoreDNS for Service Discovery
min-kubernetes-server-version: v1.9
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page describes the CoreDNS upgrade process and how to install CoreDNS instead of kube-dns.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## About CoreDNS
@@ -89,14 +90,15 @@ There is a helpful [guideline and walkthrough](https://github.com/coredns/deploy
When resource utilisation is a concern, it may be useful to tune the configuration of CoreDNS. For more details, check out the
[documentation on scaling CoreDNS](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
You can configure [CoreDNS](https://coredns.io) to support many more use cases than
kube-dns by modifying the `Corefile`. For more information, see the
[CoreDNS site](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md
index 9568843e87..5ffc40781a 100644
--- a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md
+++ b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md
@@ -4,10 +4,10 @@ reviewers:
- sjenning
- ConnorDoyle
- balajismaniam
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
@@ -18,16 +18,17 @@ acceptably. The kubelet provides methods to enable more complex workload
placement policies while keeping the abstraction free from explicit placement
directives.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## CPU Management Policies
@@ -35,7 +36,7 @@ By default, the kubelet uses [CFS quota](https://en.wikipedia.org/wiki/Completel
to enforce pod CPU limits. When the node runs many CPU-bound pods,
the workload can move to different CPU cores depending on
whether the pod is throttled and which CPU cores are available at
-scheduling time. Many workloads are not sensitive to this migration and thus
+scheduling time. Many workloads are not sensitive to this migration and thus
work fine without any intervention.
However, in workloads where CPU cache affinity and scheduling latency
@@ -211,4 +212,4 @@ and `requests` are set equal to `limits` when not explicitly specified. And the
container's resource limit for the CPU resource is an integer greater than or
equal to one. The `nginx` container is granted 2 exclusive CPUs.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/declare-network-policy.md b/content/en/docs/tasks/administer-cluster/declare-network-policy.md
index 1b6a706934..61add5312a 100644
--- a/content/en/docs/tasks/administer-cluster/declare-network-policy.md
+++ b/content/en/docs/tasks/administer-cluster/declare-network-policy.md
@@ -4,13 +4,14 @@ reviewers:
- danwinship
title: Declare Network Policy
min-kubernetes-server-version: v1.8
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This document helps you get started using the Kubernetes [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) to declare network policies that govern how pods communicate with each other.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
@@ -25,9 +26,9 @@ Make sure you've configured a network provider with network policy support. Ther
{{< note >}}
The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers.
{{< /note >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create an `nginx` deployment and expose it via a service
@@ -146,4 +147,4 @@ Connecting to nginx (10.100.0.16:80)
remote file exists
```
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md b/content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md
index 0e80a018c4..0f6579d915 100644
--- a/content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md
+++ b/content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md
@@ -4,18 +4,18 @@ reviewers:
- thockin
- wlan0
title: Developing Cloud Controller Manager
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="The cloud-controller-manager is">}}
-{{% /capture %}}
-{{% capture body %}}
+
+
## Background
@@ -41,4 +41,4 @@ controller manager as your starting point.
For in-tree cloud providers, you can run the in-tree cloud controller manager as a {{< glossary_tooltip term_id="daemonset" >}} in your cluster. See [Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/) for more details.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md
index 35dd7e6943..f436b641a0 100644
--- a/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md
+++ b/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md
@@ -3,49 +3,54 @@ reviewers:
- bowei
- zihongz
title: Customizing DNS Service
-content_template: templates/task
+content_type: task
+min-kubernetes-server-version: v1.12
---
-{{% capture overview %}}
-This page explains how to configure your DNS Pod and customize the
-DNS resolution process. In Kubernetes version 1.11 and later, CoreDNS is at GA
-and is installed by default with kubeadm. See [CoreDNS ConfigMap options](#coredns-configmap-options)
-and [Using CoreDNS for Service Discovery](/docs/tasks/administer-cluster/coredns/).
-{{% /capture %}}
+
+This page explains how to configure your DNS
+{{< glossary_tooltip text="Pod(s)" term_id="pod" >}} and customize the
+DNS resolution process in your cluster.
-{{% capture prerequisites %}}
-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-* Kubernetes version 1.6 or later. To work with CoreDNS, version 1.9 or later.
-* The appropriate add-on: kube-dns or CoreDNS. To install with kubeadm,
-see [the kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-addon).
-{{% /capture %}}
+## {{% heading "prerequisites" %}}
-{{% capture steps %}}
+{{< include "task-tutorial-prereqs.md" >}}
+
+Your cluster must be running the CoreDNS add-on.
+[Migrating to CoreDNS](https://kubernetes.io/docs/tasks/administer-cluster/coredns/#migrating-to-coredns)
+explains how to use `kubeadm` to migrate from `kube-dns`.
+
+{{% version-check %}}
+
+
## Introduction
DNS is a built-in Kubernetes service launched automatically
-using the addon manager
+using the _addon manager_
[cluster add-on](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md).
-As of Kubernetes v1.12, CoreDNS is the recommended DNS Server, replacing kube-dns. However, kube-dns may still be installed by
-default with certain Kubernetes installer tools. Refer to the documentation provided by your installer to know which DNS server is installed by default.
+As of Kubernetes v1.12, CoreDNS is the recommended DNS Server, replacing kube-dns. If your cluster
+originally used kube-dns, you may still have `kube-dns` deployed rather than CoreDNS.
+{{< note >}}
+Both the CoreDNS and kube-dns Service are named `kube-dns` in the `metadata.name` field.
+This is so that there is greater interoperability with workloads that relied on the legacy `kube-dns` Service name to resolve addresses internal to the cluster. Using a Service named `kube-dns` abstracts away the implementation detail of which DNS provider is running behind that common name.
+{{< /note >}}
-The CoreDNS Deployment is exposed as a Kubernetes Service with a static IP.
-Both the CoreDNS and kube-dns Service are named `kube-dns` in the `metadata.name` field. This is done so that there is greater interoperability with workloads that relied on the legacy `kube-dns` Service name to resolve addresses internal to the cluster. It abstracts away the implementation detail of which DNS provider is running behind that common endpoint.
-The kubelet passes DNS to each container with the `--cluster-dns=` flag.
+If you are running CoreDNS as a Deployment, it will typically be exposed as a Kubernetes Service with a static IP address.
+The kubelet passes DNS resolver information to each container with the `--cluster-dns=` flag.
DNS names also need domains. You configure the local domain in the kubelet
with the flag `--cluster-domain=`.
-The DNS server supports forward lookups (A records), port lookups (SRV records), reverse IP address lookups (PTR records),
-and more. For more information see [DNS for Services and Pods] (/docs/concepts/services-networking/dns-pod-service/).
+The DNS server supports forward lookups (A and AAAA records), port lookups (SRV records), reverse IP address lookups (PTR records),
+and more. For more information, see [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/).
-If a Pod's `dnsPolicy` is set to "`default`", it inherits the name resolution
+If a Pod's `dnsPolicy` is set to `default`, it inherits the name resolution
configuration from the node that the Pod runs on. The Pod's DNS resolution
should behave the same as the node.
-But see [Known issues](/docs/tasks/administer-cluster/dns-debugging-resolution/#known-issues).
+But see [Known issues](/docs/tasks/debug-application-cluster/dns-debugging-resolution/#known-issues).
If you don't want this, or if you want a different DNS config for pods, you can
use the kubelet's `--resolv-conf` flag. Set this flag to "" to prevent Pods from
@@ -54,16 +59,17 @@ inheriting DNS. Set it to a valid file path to specify a file other than
## CoreDNS
-CoreDNS is a general-purpose authoritative DNS server that can serve as cluster DNS, complying with the [dns specifications]
-(https://github.com/kubernetes/dns/blob/master/docs/specification.md).
+CoreDNS is a general-purpose authoritative DNS server that can serve as cluster DNS, complying with the [dns specifications](https://github.com/kubernetes/dns/blob/master/docs/specification.md).
### CoreDNS ConfigMap options
-CoreDNS is a DNS server that is modular and pluggable, and each plugin adds new functionality to CoreDNS.
+CoreDNS is a DNS server that is modular and pluggable, and each plugin adds new functionality to CoreDNS.
This can be configured by maintaining a [Corefile](https://coredns.io/2017/07/23/corefile-explained/), which is the CoreDNS
-configuration file. A cluster administrator can modify the ConfigMap for the CoreDNS Corefile to change how service discovery works.
+configuration file. As a cluster administrator, you can modify the
+{{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} for the CoreDNS Corefile to change how DNS service discovery
+behaves for that cluster.
-In Kubernetes, CoreDNS is installed with the following default Corefile configuration.
+In Kubernetes, CoreDNS is installed with the following default Corefile configuration:
```yaml
apiVersion: v1
@@ -91,17 +97,16 @@ data:
reload
loadbalance
}
-```
+```
+
The Corefile configuration includes the following [plugins](https://coredns.io/plugins/) of CoreDNS:
* [errors](https://coredns.io/plugins/errors/): Errors are logged to stdout.
-* [health](https://coredns.io/plugins/health/): Health of CoreDNS is reported to http://localhost:8080/health. In this extended syntax `lameduck` will make the process unhealthy then wait for 5 seconds before the process is shut down.
+* [health](https://coredns.io/plugins/health/): Health of CoreDNS is reported to `http://localhost:8080/health`. In this extended syntax `lameduck` will make the process unhealthy then wait for 5 seconds before the process is shut down.
* [ready](https://coredns.io/plugins/ready/): An HTTP endpoint on port 8181 will return 200 OK, when all plugins that are able to signal readiness have done so.
-* [kubernetes](https://coredns.io/plugins/kubernetes/): CoreDNS will reply to DNS queries based on IP of the services and pods of Kubernetes. You can find more details [here](https://coredns.io/plugins/kubernetes/). `ttl` allows you to set a custom TTL for responses. The default is 5 seconds. The minimum TTL allowed is 0 seconds, and the maximum is capped at 3600 seconds. Setting TTL to 0 will prevent records from being cached.
-
-> The `pods insecure` option is provided for backward compatibility with kube-dns. You can use the `pods verified` option, which returns an A record only if there exists a pod in same namespace with matching IP. The `pods disabled` option can be used if you don't use pod records.
-
-* [prometheus](https://coredns.io/plugins/metrics/): Metrics of CoreDNS are available at http://localhost:9153/metrics in [Prometheus](https://prometheus.io/) format.
+* [kubernetes](https://coredns.io/plugins/kubernetes/): CoreDNS will reply to DNS queries based on IP of the services and pods of Kubernetes. You can find [more details](https://coredns.io/plugins/kubernetes/) about that plugin on the CoreDNS website. `ttl` allows you to set a custom TTL for responses. The default is 5 seconds. The minimum TTL allowed is 0 seconds, and the maximum is capped at 3600 seconds. Setting TTL to 0 will prevent records from being cached.
+ The `pods insecure` option is provided for backward compatibility with _kube-dns_. You can use the `pods verified` option, which returns an A record only if there exists a pod in same namespace with matching IP. The `pods disabled` option can be used if you don't use pod records.
+* [prometheus](https://coredns.io/plugins/metrics/): Metrics of CoreDNS are available at `http://localhost:9153/metrics` in [Prometheus](https://prometheus.io/) format (also known as OpenMetrics).
* [forward](https://coredns.io/plugins/forward/): Any queries that are not within the cluster domain of Kubernetes will be forwarded to predefined resolvers (/etc/resolv.conf).
* [cache](https://coredns.io/plugins/cache/): This enables a frontend cache.
* [loop](https://coredns.io/plugins/loop/): Detects simple forwarding loops and halts the CoreDNS process if a loop is found.
@@ -129,7 +134,7 @@ To explicitly force all non-cluster DNS lookups to go through a specific nameser
```
forward . 172.16.0.1
-```
+```
The final ConfigMap along with the default `Corefile` configuration looks like:
@@ -161,149 +166,14 @@ data:
forward . 10.150.0.1
}
```
-In Kubernetes version 1.10 and later, kubeadm supports automatic translation of the CoreDNS ConfigMap from the kube-dns ConfigMap.
-***Note: While kube-dns accepts an FQDN for stubdomain and nameserver (eg: ns.foo.com), CoreDNS does not support this feature.
-During translation, all FQDN nameservers will be omitted from the CoreDNS config.***
-## Kube-dns
+The `kubeadm` tool supports automatic translation from the kube-dns ConfigMap
+to the equivalent CoreDNS ConfigMap.
-Kube-dns is now available as an optional DNS server since CoreDNS is now the default.
-The running DNS Pod holds 3 containers:
-
-- "`kubedns`": watches the Kubernetes master for changes
- in Services and Endpoints, and maintains in-memory lookup structures to serve
- DNS requests.
-- "`dnsmasq`": adds DNS caching to improve performance.
-- "`sidecar`": provides a single health check endpoint
- to perform healthchecks for `dnsmasq` and `kubedns`.
-
-### Configure stub-domain and upstream DNS servers
-
-Cluster administrators can specify custom stub domains and upstream nameservers
-by providing a ConfigMap for kube-dns (`kube-system:kube-dns`).
-
-For example, the following ConfigMap sets up a DNS configuration with a single stub domain and two
-upstream nameservers:
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
- name: kube-dns
- namespace: kube-system
-data:
- stubDomains: |
- {"acme.local": ["1.2.3.4"]}
- upstreamNameservers: |
- ["8.8.8.8", "8.8.4.4"]
-```
-
-DNS requests with the “.acme.local” suffix
-are forwarded to a DNS listening at 1.2.3.4. Google Public DNS
-serves the upstream queries.
-
-The table below describes how queries with certain domain names map to
-their destination DNS servers:
-
-| Domain name | Server answering the query |
-| ----------- | -------------------------- |
-| kubernetes.default.svc.cluster.local| kube-dns |
-| foo.acme.local| custom DNS (1.2.3.4) |
-| widget.com | upstream DNS (one of 8.8.8.8, 8.8.4.4) |
-
-See [ConfigMap options](#configmap-options) for
-details about the configuration option format.
-
-{{% /capture %}}
-
-{{% capture discussion %}}
-
-#### Effects on Pods
-
-Custom upstream nameservers and stub domains do not affect Pods with a
-`dnsPolicy` set to "`Default`" or "`None`".
-
-If a Pod's `dnsPolicy` is set to "`ClusterFirst`", its name resolution is
-handled differently, depending on whether stub-domain and upstream DNS servers
-are configured.
-
-**Without custom configurations**: Any query that does not match the configured
-cluster domain suffix, such as "www.kubernetes.io", is forwarded to the upstream
-nameserver inherited from the node.
-
-**With custom configurations**: If stub domains and upstream DNS servers are
-configured,
-DNS queries are routed according to the following flow:
-
-1. The query is first sent to the DNS caching layer in kube-dns.
-
-1. From the caching layer, the suffix of the request is examined and then
- forwarded to the appropriate DNS, based on the following cases:
-
- * *Names with the cluster suffix*, for example ".cluster.local":
- The request is sent to kube-dns.
-
- * *Names with the stub domain suffix*, for example ".acme.local":
- The request is sent to the configured custom DNS resolver, listening for example at 1.2.3.4.
-
- * *Names without a matching suffix*, for example "widget.com":
- The request is forwarded to the upstream DNS,
- for example Google public DNS servers at 8.8.8.8 and 8.8.4.4.
-
-
-
-### ConfigMap options
-
-Options for the kube-dns `kube-system:kube-dns` ConfigMap:
-
-| Field | Format | Description |
-| ----- | ------ | ----------- |
-| `stubDomains` (optional) | A JSON map using a DNS suffix key such as “acme.local”, and a value consisting of a JSON array of DNS IPs. | The target nameserver can itself be a Kubernetes Service. For instance, you can run your own copy of dnsmasq to export custom DNS names into the ClusterDNS namespace. |
-| `upstreamNameservers` (optional) | A JSON array of DNS IPs. | If specified, the values replace the nameservers taken by default from the node’s `/etc/resolv.conf`. Limits: a maximum of three upstream nameservers can be specified. |
-
-#### Examples
-
-##### Example: Stub domain
-
-In this example, the user has a Consul DNS service discovery system they want to
-integrate with kube-dns. The consul domain server is located at 10.150.0.1, and
-all consul names have the suffix `.consul.local`. To configure Kubernetes, the
-cluster administrator creates the following ConfigMap:
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
- name: kube-dns
- namespace: kube-system
-data:
- stubDomains: |
- {"consul.local": ["10.150.0.1"]}
-```
-
-Note that the cluster administrator does not want to override the node’s
-upstream nameservers, so they did not specify the optional
-`upstreamNameservers` field.
-
-##### Example: Upstream nameserver
-
-In this example the cluster administrator wants to explicitly force all
-non-cluster DNS lookups to go through their own nameserver at 172.16.0.1.
-In this case, they create a ConfigMap with the
-`upstreamNameservers` field specifying the desired nameserver:
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
- name: kube-dns
- namespace: kube-system
-data:
- upstreamNameservers: |
- ["172.16.0.1"]
-```
-
-{{% /capture %}}
+{{< note >}}
+While kube-dns accepts an FQDN for stubdomain and nameserver (eg: ns.foo.com), CoreDNS does not support this feature.
+During translation, all FQDN nameservers will be omitted from the CoreDNS config.
+{{< /note >}}
## CoreDNS configuration equivalent to kube-dns
@@ -313,7 +183,7 @@ Similarly, the `Federations` plugin in kube-dns translates to the `federation` p
### Example
-This example ConfigMap for kubedns specifies federations, stubdomains and upstreamnameservers:
+This example ConfigMap for kube-dns specifies federations, stubdomains and upstreamnameservers:
```yaml
apiVersion: v1
@@ -330,59 +200,65 @@ kind: ConfigMap
The equivalent configuration in CoreDNS creates a Corefile:
* For federations:
-```yaml
+```
federation cluster.local {
- foo foo.feddomain.com
- }
+ foo foo.feddomain.com
+}
```
* For stubDomains:
```yaml
abc.com:53 {
- errors
- cache 30
- forward . 1.2.3.4
- }
- my.cluster.local:53 {
- errors
- cache 30
- forward . 2.3.4.5
- }
+ errors
+ cache 30
+ forward . 1.2.3.4
+}
+my.cluster.local:53 {
+ errors
+ cache 30
+ forward . 2.3.4.5
+}
```
The complete Corefile with the default plugins:
-```yaml
+```
.:53 {
- errors
- health
- kubernetes cluster.local in-addr.arpa ip6.arpa {
- pods insecure
- fallthrough in-addr.arpa ip6.arpa
- }
- federation cluster.local {
- foo foo.feddomain.com
- }
- prometheus :9153
- forward . 8.8.8.8 8.8.4.4
- cache 30
+ errors
+ health
+ kubernetes cluster.local in-addr.arpa ip6.arpa {
+ pods insecure
+ fallthrough in-addr.arpa ip6.arpa
}
- abc.com:53 {
- errors
- cache 30
- forward . 1.2.3.4
- }
- my.cluster.local:53 {
- errors
- cache 30
- forward . 2.3.4.5
+ federation cluster.local {
+ foo foo.feddomain.com
}
+ prometheus :9153
+ forward . 8.8.8.8 8.8.4.4
+ cache 30
+}
+abc.com:53 {
+ errors
+ cache 30
+ forward . 1.2.3.4
+}
+my.cluster.local:53 {
+ errors
+ cache 30
+ forward . 2.3.4.5
+}
```
## Migration to CoreDNS
-To migrate from kube-dns to CoreDNS, [a detailed blog](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/) is available to help users adapt CoreDNS in place of kube-dns.
-A cluster administrator can also migrate using [the deploy script](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh).
+To migrate from kube-dns to CoreDNS, a detailed
+[blog article](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/)
+is available to help users adapt CoreDNS in place of kube-dns.
-## What's next
-- [Debugging DNS Resolution](/docs/tasks/administer-cluster/dns-debugging-resolution/).
+You can also migrate using the offical CoreDNS
+[deploy script](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh).
+
+
+## {{% heading "whatsnext" %}}
+
+- Read [Debugging DNS Resolution](/docs/tasks/debug-application-cluster/dns-debugging-resolution/)
diff --git a/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md
index 3a69bd84ec..e762258c88 100644
--- a/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md
+++ b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md
@@ -3,43 +3,52 @@ reviewers:
- bowei
- zihongz
title: Debugging DNS Resolution
-content_template: templates/task
+content_type: task
+min-kubernetes-server-version: v1.6
---
-{{% capture overview %}}
+
This page provides hints on diagnosing DNS problems.
-{{% /capture %}}
-{{% capture prerequisites %}}
-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-* Kubernetes version 1.6 and above.
-* The cluster must be configured to use the `coredns` (or `kube-dns`) addons.
-{{% /capture %}}
+## {{% heading "prerequisites" %}}
-{{% capture steps %}}
+{{< include "task-tutorial-prereqs.md" >}}
+Your cluster must be configured to use the CoreDNS
+{{< glossary_tooltip text="addon" term_id="addons" >}} or its precursor,
+kube-dns.
+
+{{% version-check %}}
+
+
### Create a simple Pod to use as a test environment
-Create a file named dnsutils.yaml with the following contents:
-
{{< codenew file="admin/dns/dnsutils.yaml" >}}
-Then create a pod using this file and verify its status:
+Use that manifest to create a Pod:
```shell
kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml
+```
+```
pod/dnsutils created
-
+```
+…and verify its status:
+```shell
kubectl get pods dnsutils
+```
+```
NAME READY STATUS RESTARTS AGE
dnsutils 1/1 Running 0
```
-Once that pod is running, you can exec `nslookup` in that environment.
+Once that Pod is running, you can exec `nslookup` in that environment.
If you see something like the following, DNS is working correctly.
```shell
-kubectl exec -ti dnsutils -- nslookup kubernetes.default
+kubectl exec -i -t dnsutils -- nslookup kubernetes.default
+```
+```
Server: 10.0.0.10
Address 1: 10.0.0.10
@@ -68,11 +77,13 @@ nameserver 10.0.0.10
options ndots:5
```
-Errors such as the following indicate a problem with the coredns/kube-dns add-on or
-associated Services:
+Errors such as the following indicate a problem with the CoreDNS (or kube-dns)
+add-on or with associated Services:
+```shell
+kubectl exec -i -t dnsutils -- nslookup kubernetes.default
+```
```
-kubectl exec -ti dnsutils -- nslookup kubernetes.default
Server: 10.0.0.10
Address 1: 10.0.0.10
@@ -81,8 +92,10 @@ nslookup: can't resolve 'kubernetes.default'
or
+```shell
+kubectl exec -i -t dnsutils -- nslookup kubernetes.default
+```
```
-kubectl exec -ti dnsutils -- nslookup kubernetes.default
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
@@ -93,9 +106,10 @@ nslookup: can't resolve 'kubernetes.default'
Use the `kubectl get pods` command to verify that the DNS pod is running.
-For CoreDNS:
```shell
kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
+```
+```
NAME READY STATUS RESTARTS AGE
...
coredns-7b96bf9f76-5hsxb 1/1 Running 0 1h
@@ -103,26 +117,22 @@ coredns-7b96bf9f76-mvmmt 1/1 Running 0 1h
...
```
-Or for kube-dns:
-```shell
-kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
-NAME READY STATUS RESTARTS AGE
-...
-kube-dns-v19-ezo1y 3/3 Running 0 1h
-...
-```
+{{< note >}}
+The value for label `k8s-app` is `kube-dns` for both CoreDNS and kube-dns deployments.
+{{< /note >}}
-If you see that no pod is running or that the pod has failed/completed, the DNS
-add-on may not be deployed by default in your current environment and you will
-have to deploy it manually.
-### Check for Errors in the DNS pod
+If you see that no CoreDNS Pod is running or that the Pod has failed/completed,
+the DNS add-on may not be deployed by default in your current environment and you
+will have to deploy it manually.
-Use `kubectl logs` command to see logs for the DNS containers.
+### Check for errors in the DNS pod
+
+Use the `kubectl logs` command to see logs for the DNS containers.
For CoreDNS:
```shell
-for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); do kubectl logs --namespace=kube-system $p; done
+kubectl logs --namespace=kube-system -l k8s-app=kube-dns
```
Here is an example of a healthy CoreDNS log:
@@ -136,21 +146,7 @@ linux/amd64, go1.10.3, 2e322f6
2018/08/15 14:37:17 [INFO] plugin/reload: Running configuration MD5 = 24e6c59e83ce706f07bcc82c31b1ea1c
```
-
-For kube-dns, there are 3 sets of logs:
-```shell
-kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c kubedns
-
-kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c dnsmasq
-
-kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c sidecar
-```
-
-See if there are any suspicious error messages in the logs. In kube-dns, a '`W`', '`E`' or '`F`' at the beginning
-of a line represents a Warning, Error or Failure. Please search for entries that have these
-as the logging level and use
-[kubernetes issues](https://github.com/kubernetes/kubernetes/issues)
-to report unexpected errors.
+See if there are any suspicious or unexpected messages in the logs.
### Is DNS service up?
@@ -158,17 +154,23 @@ Verify that the DNS service is up by using the `kubectl get service` command.
```shell
kubectl get svc --namespace=kube-system
+```
+```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
...
kube-dns ClusterIP 10.0.0.10 53/UDP,53/TCP 1h
...
```
+{{< note >}}
+The service name is `kube-dns` for both CoreDNS and kube-dns deployments.
+{{< /note >}}
-Note that the service name will be "kube-dns" for both CoreDNS and kube-dns deployments.
-If you have created the service or in the case it should be created by default
-but it does not appear, see
-[debugging services](/docs/tasks/debug-application-cluster/debug-service/) for
+
+
+If you have created the Service or in the case it should be created by default
+but it does not appear, see
+[debugging Services](/docs/tasks/debug-application-cluster/debug-service/) for
more information.
### Are DNS endpoints exposed?
@@ -177,31 +179,32 @@ You can verify that DNS endpoints are exposed by using the `kubectl get endpoint
command.
```shell
-kubectl get ep kube-dns --namespace=kube-system
+kubectl get endpoints kube-dns --namespace=kube-system
+```
+```
NAME ENDPOINTS AGE
kube-dns 10.180.3.17:53,10.180.3.17:53 1h
```
-If you do not see the endpoints, see endpoints section in the
-[debugging services](/docs/tasks/debug-application-cluster/debug-service/) documentation.
+If you do not see the endpoints, see the endpoints section in the
+[debugging Services](/docs/tasks/debug-application-cluster/debug-service/) documentation.
For additional Kubernetes DNS examples, see the
[cluster-dns examples](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)
in the Kubernetes GitHub repository.
-
### Are DNS queries being received/processed?
You can verify if queries are being received by CoreDNS by adding the `log` plugin to the CoreDNS configuration (aka Corefile).
-The CoreDNS Corefile is held in a ConfigMap named `coredns`. To edit it, use the command ...
+The CoreDNS Corefile is held in a {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} named `coredns`. To edit it, use the command:
```
kubectl -n kube-system edit configmap coredns
```
-Then add `log` in the Corefile section per the example below.
+Then add `log` in the Corefile section per the example below:
-```
+```yaml
apiVersion: v1
kind: ConfigMap
metadata:
@@ -225,14 +228,13 @@ data:
reload
loadbalance
}
-
```
After saving the changes, it may take up to minute or two for Kubernetes to propagate these changes to the CoreDNS pods.
Next, make some queries and view the logs per the sections above in this document. If CoreDNS pods are receiving the queries, you should see them in the logs.
-Here is an example of a query in the log.
+Here is an example of a query in the log:
```
.:53
@@ -243,7 +245,6 @@ linux/amd64, go1.10.3, 2e322f6
2018/09/07 15:29:04 [INFO] plugin/reload: Running configuration MD5 = 162475cdf272d8aa601e6fe67a6ad42f
2018/09/07 15:29:04 [INFO] Reloading complete
172.17.0.18:41675 - [07/Sep/2018:15:29:11 +0000] 59925 "A IN kubernetes.default.svc.cluster.local. udp 54 false 512" NOERROR qr,aa,rd,ra 106 0.000066649s
-
```
## Known issues
@@ -252,7 +253,7 @@ Some Linux distributions (e.g. Ubuntu) use a local DNS resolver by default (syst
Systemd-resolved moves and replaces `/etc/resolv.conf` with a stub file that can cause a fatal forwarding
loop when resolving names in upstream servers. This can be fixed manually by using kubelet's `--resolv-conf` flag
to point to the correct `resolv.conf` (With `systemd-resolved`, this is `/run/systemd/resolve/resolv.conf`).
-kubeadm (>= 1.11) automatically detects `systemd-resolved`, and adjusts the kubelet flags accordingly.
+kubeadm automatically detects `systemd-resolved`, and adjusts the kubelet flags accordingly.
Kubernetes installs do not configure the nodes' `resolv.conf` files to use the
cluster DNS by default, because that process is inherently distribution-specific.
@@ -262,16 +263,11 @@ Linux's libc (a.k.a. glibc) has a limit for the DNS `nameserver` records to 3 by
If you are using Alpine version 3.3 or earlier as your base image, DNS may not
work properly due to a known issue with Alpine.
-Check [here](https://github.com/kubernetes/kubernetes/issues/30215)
-for more information.
+Kubernetes [issue 30215](https://github.com/kubernetes/kubernetes/issues/30215)
+details more information on this.
-## References
+## {{% heading "whatsnext" %}}
-- [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/)
-- [Docs for the kube-dns DNS cluster addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md)
-
-## What's next
-- [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).
-
-{{% /capture %}}
+- See [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).
+- Read [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/)
diff --git a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
index 5d5dc98ade..6fd887bd8f 100644
--- a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
+++ b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
@@ -1,14 +1,15 @@
---
title: Autoscale the DNS Service in a Cluster
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page shows how to enable and configure autoscaling of the DNS service in
your Kubernetes cluster.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
@@ -16,9 +17,9 @@ your Kubernetes cluster.
* Make sure [Kubernetes DNS](/docs/concepts/services-networking/dns-pod-service/) is enabled.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Determine whether DNS horizontal autoscaling is already enabled {#determining-whether-dns-horizontal-autoscaling-is-already-enabled}
@@ -201,9 +202,9 @@ The common path for this dns-autoscaler is:
After the manifest file is deleted, the Addon Manager will delete the
dns-autoscaler Deployment.
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Understanding how DNS horizontal autoscaling works
@@ -226,10 +227,11 @@ the autoscaler Pod.
* The autoscaler provides a controller interface to support two control
patterns: *linear* and *ladder*.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Read about [Guaranteed Scheduling For Critical Add-On Pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/).
* Learn more about the
[implementation of cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/enabling-endpointslices.md b/content/en/docs/tasks/administer-cluster/enabling-endpointslices.md
index b8e4cf900d..b9e389ead7 100644
--- a/content/en/docs/tasks/administer-cluster/enabling-endpointslices.md
+++ b/content/en/docs/tasks/administer-cluster/enabling-endpointslices.md
@@ -3,19 +3,20 @@ reviewers:
- bowei
- freehan
title: Enabling EndpointSlices
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page provides an overview of enabling EndpointSlices in Kubernetes.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Introduction
@@ -55,9 +56,10 @@ existing Endpoints functionality, EndpointSlices include new bits of information
such as topology. They will allow for greater scalability and extensibility of
network endpoints in your cluster.
-{{% capture whatsnext %}}
+## {{% heading "whatsnext" %}}
+
* Read about [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/enabling-service-topology.md b/content/en/docs/tasks/administer-cluster/enabling-service-topology.md
index c39b9b366d..998bb8b2e5 100644
--- a/content/en/docs/tasks/administer-cluster/enabling-service-topology.md
+++ b/content/en/docs/tasks/administer-cluster/enabling-service-topology.md
@@ -4,19 +4,20 @@ reviewers:
- johnbelamaric
- imroc
title: Enabling Service Topology
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page provides an overview of enabling Service Topology in Kubernetes.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Introduction
@@ -45,10 +46,11 @@ To enable service topology, enable the `ServiceTopology` and `EndpointSlice` fea
```
-{{% capture whatsnext %}}
+## {{% heading "whatsnext" %}}
+
* Read about the [Service Topology](/docs/concepts/services-networking/service-topology) concept
* Read about [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices)
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/encrypt-data.md b/content/en/docs/tasks/administer-cluster/encrypt-data.md
index b96f034963..8499855bb0 100644
--- a/content/en/docs/tasks/administer-cluster/encrypt-data.md
+++ b/content/en/docs/tasks/administer-cluster/encrypt-data.md
@@ -2,23 +2,24 @@
reviewers:
- smarterclayton
title: Encrypting Secret Data at Rest
-content_template: templates/task
+content_type: task
min-kubernetes-server-version: 1.13
---
-{{% capture overview %}}
+
This page shows how to enable and configure encryption of secret data at rest.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* etcd v3.0 or later is required
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Configuration and determining whether encryption at rest is already enabled
@@ -215,4 +216,4 @@ kubectl get secrets --all-namespaces -o json | kubectl replace -f -
```
to force all secrets to be decrypted.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/extended-resource-node.md b/content/en/docs/tasks/administer-cluster/extended-resource-node.md
index 49e491d251..07d8fea616 100644
--- a/content/en/docs/tasks/administer-cluster/extended-resource-node.md
+++ b/content/en/docs/tasks/administer-cluster/extended-resource-node.md
@@ -1,26 +1,27 @@
---
title: Advertise Extended Resources for a Node
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page shows how to specify extended resources for a Node.
Extended resources allow cluster administrators to advertise node-level
resources that would otherwise be unknown to Kubernetes.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Get the names of your Nodes
@@ -189,10 +190,11 @@ kubectl describe node | grep dongle
(you should not see any output)
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
### For application developers
@@ -204,4 +206,4 @@ kubectl describe node | grep dongle
* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md b/content/en/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md
index 0b00eed125..0d5b6d4ebe 100644
--- a/content/en/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md
+++ b/content/en/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md
@@ -4,10 +4,10 @@ reviewers:
- filipg
- piosz
title: Guaranteed Scheduling For Critical Add-On Pods
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
In addition to Kubernetes core components like api-server, scheduler, controller-manager running on a master machine
there are a number of add-ons which, for various reasons, must run on a regular cluster node (rather than the Kubernetes master).
@@ -19,14 +19,14 @@ vacated by the evicted critical add-on pod or the amount of resources available
Note that marking a pod as critical is not meant to prevent evictions entirely; it only prevents the pod from becoming permanently unavailable.
For static pods, this means it can't be evicted, but for non-static pods, it just means they will always be rescheduled.
-{{% /capture %}}
-{{% capture body %}}
+
+
### Marking pod as critical
To mark a Pod as critical, set priorityClassName for that Pod to `system-cluster-critical` or `system-node-critical`. `system-node-critical` is the highest available priority, even higher than `system-cluster-critical`.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/highly-available-master.md b/content/en/docs/tasks/administer-cluster/highly-available-master.md
index e5529da7c7..e2a582f8b2 100644
--- a/content/en/docs/tasks/administer-cluster/highly-available-master.md
+++ b/content/en/docs/tasks/administer-cluster/highly-available-master.md
@@ -2,26 +2,27 @@
reviewers:
- jszczepkowski
title: Set up High-Availability Kubernetes Masters
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.5" state="alpha" >}}
You can replicate Kubernetes masters in `kube-up` or `kube-down` scripts for Google Compute Engine.
This document describes how to use kube-up/down scripts to manage highly available (HA) masters and how HA masters are implemented for use with GCE.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Starting an HA-compatible cluster
@@ -118,9 +119,9 @@ If the cluster is large, it may take a long time to duplicate its state.
This operation may be sped up by migrating etcd data directory, as described [here](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration)
(we are considering adding support for etcd data dir migration in future).
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Implementation notes
@@ -173,4 +174,4 @@ To make such deployment secure, communication between etcd instances is authoriz
[Automated HA master deployment - design doc](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/ip-masq-agent.md b/content/en/docs/tasks/administer-cluster/ip-masq-agent.md
index bdc871ddd9..9c2e1d3d5d 100644
--- a/content/en/docs/tasks/administer-cluster/ip-masq-agent.md
+++ b/content/en/docs/tasks/administer-cluster/ip-masq-agent.md
@@ -1,19 +1,20 @@
---
title: IP Masquerade Agent User Guide
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page shows how to configure and enable the ip-masq-agent.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## IP Masquerade Agent User Guide
The ip-masq-agent configures iptables rules to hide a pod's IP address behind the cluster node's IP address. This is typically done when sending traffic to destinations outside the cluster's pod [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) range.
@@ -53,9 +54,9 @@ MASQUERADE all -- anywhere anywhere /* ip-masq-agent:
By default, in GCE/Google Kubernetes Engine starting with Kubernetes version 1.7.0, if network policy is enabled or you are using a cluster CIDR not in the 10.0.0.0/8 range, the ip-masq-agent will run in your cluster. If you are running in another environment, you can add the ip-masq-agent [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) to your cluster:
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create an ip-masq-agent
To create an ip-masq-agent, run the following kubectl command:
@@ -110,4 +111,4 @@ nonMasqueradeCIDRs:
resyncInterval: 60s
masqLinkLocal: true
```
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/kms-provider.md b/content/en/docs/tasks/administer-cluster/kms-provider.md
index d90ca853cf..34cc1d6b66 100644
--- a/content/en/docs/tasks/administer-cluster/kms-provider.md
+++ b/content/en/docs/tasks/administer-cluster/kms-provider.md
@@ -2,13 +2,14 @@
reviewers:
- smarterclayton
title: Using a KMS provider for data encryption
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page shows how to configure a Key Management Service (KMS) provider and plugin to enable secret data encryption.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
@@ -18,9 +19,9 @@ This page shows how to configure a Key Management Service (KMS) provider and plu
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
The KMS encryption provider uses an envelope encryption scheme to encrypt data in etcd. The data is encrypted using a data encryption key (DEK); a new DEK is generated for each encryption. The DEKs are encrypted with a key encryption key (KEK) that is stored and managed in a remote KMS. The KMS provider uses gRPC to communicate with a specific KMS
plugin. The KMS plugin, which is implemented as a gRPC server and deployed on the same host(s) as the Kubernetes master(s), is responsible for all communication with the remote KMS.
@@ -183,4 +184,4 @@ To disable encryption at rest:
```
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
```
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
index 28df69c13a..e82c53f3a6 100644
--- a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+++ b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
@@ -4,20 +4,21 @@ reviewers:
- patricklang
title: Adding Windows nodes
min-kubernetes-server-version: 1.17
-content_template: templates/tutorial
+content_type: tutorial
weight: 30
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
You can use Kubernetes to run a mixture of Linux and Windows nodes, so you can mix Pods that run on Linux on with Pods that run on Windows. This page shows how to register Windows nodes to your cluster.
-{{% /capture %}}
-{{% capture prerequisites %}} {{< version-check >}}
+
+## {{% heading "prerequisites" %}}
+ {{< version-check >}}
* Obtain a [Windows Server 2019 license](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)
(or higher) in order to configure the Windows node that hosts Windows containers.
@@ -25,18 +26,19 @@ If you are using VXLAN/Overlay networking you must have also have [KB4489899](ht
* A Linux-based Kubernetes kubeadm cluster in which you have access to the control plane (see [Creating a single control-plane cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)).
-{{% /capture %}}
-{{% capture objectives %}}
+
+## {{% heading "objectives" %}}
+
* Register a Windows node to the cluster
* Configure networking so Pods and Services on Linux and Windows can communicate with each other
-{{% /capture %}}
-{{% capture lessoncontent %}}
+
+
## Getting Started: Adding a Windows Node to Your Cluster
@@ -176,10 +178,11 @@ kubectl -n kube-system get pods -l app=flannel
Once the flannel Pod is running, your node should enter the `Ready` state and then be available to handle workloads.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
- [Upgrading Windows kubeadm nodes](/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
index 6329c4a395..461e45bda6 100644
--- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
+++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
@@ -2,25 +2,26 @@
reviewers:
- sig-cluster-lifecycle
title: Certificate Management with kubeadm
-content_template: templates/task
+content_type: task
weight: 10
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.15" state="stable" >}}
Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) expire after 1 year. This page explains how to manage certificate renewals with kubeadm.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
You should be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/best-practices/certificates/).
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Using custom certificates {#custom-certificates}
@@ -242,4 +243,8 @@ After a certificate is signed using your preferred method, the certificate and t
[cert-cas]: /docs/setup/best-practices/certificates/#single-root-ca
[cert-table]: /docs/setup/best-practices/certificates/#all-certificates
-{{% /capture %}}
+## Certificate authority (CA) rotation {#certificate-authority-rotation}
+
+Kubeadm does not support rotation or replacement of CA certificates out of the box.
+
+For more information about manual rotation or replacement of CA, see [manual rotation of CA certificates](/docs/tasks/tls/manual-rotation-of-ca-certificates/).
diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
index f0368ecaf9..2c4c3d135e 100644
--- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
+++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
@@ -2,12 +2,12 @@
reviewers:
- sig-cluster-lifecycle
title: Upgrading kubeadm clusters
-content_template: templates/task
+content_type: task
weight: 20
min-kubernetes-server-version: 1.18
---
-{{% capture overview %}}
+
This page explains how to upgrade a Kubernetes cluster created with kubeadm from version
1.17.x to version 1.18.x, and from version 1.18.x to 1.18.y (where `y > x`).
@@ -26,9 +26,10 @@ The upgrade workflow at high level is the following:
1. Upgrade additional control plane nodes.
1. Upgrade worker nodes.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
- You need to have a kubeadm Kubernetes cluster running version 1.17.0 or later.
- [Swap must be disabled](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).
@@ -44,9 +45,9 @@ The upgrade workflow at high level is the following:
or between PATCH versions of the same MINOR. That is, you cannot skip MINOR versions when you upgrade.
For example, you can upgrade from 1.y to 1.y+1, but not from 1.y to 1.y+2.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Determine which version to upgrade to
@@ -148,7 +149,7 @@ Find the latest stable 1.18 version:
{{< note >}}
`kubeadm upgrade` also automatically renews the certificates that it manages on this node.
To opt-out of certificate renewal the flag `--certificate-renewal=false` can be used.
-For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadmkubeadm-certs).
+For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs).
{{}}
- Choose a version to upgrade to, and run the appropriate command. For example:
@@ -295,6 +296,7 @@ Upgrade the kubelet and kubectl on all control plane nodes:
Restart the kubelet
```shell
+sudo systemctl daemon-reload
sudo systemctl restart kubelet
```
@@ -373,6 +375,7 @@ without compromising the minimum required capacity for running your workloads.
- Restart the kubelet
```shell
+ sudo systemctl daemon-reload
sudo systemctl restart kubelet
```
@@ -395,7 +398,7 @@ kubectl get nodes
The `STATUS` column should show `Ready` for all your nodes, and the version number should be updated.
-{{% /capture %}}
+
## Recovering from a failure state
@@ -441,4 +444,4 @@ and post-upgrade manifest file for a certain component, a backup file for it wil
`kubeadm upgrade node` does the following on worker nodes:
- Fetches the kubeadm `ClusterConfiguration` from the cluster.
-- Upgrades the kubelet configuration for this node.
\ No newline at end of file
+- Upgrades the kubelet configuration for this node.
diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md
index a6c626a627..35857d09a0 100644
--- a/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md
+++ b/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md
@@ -1,29 +1,30 @@
---
title: Upgrading Windows nodes
min-kubernetes-server-version: 1.17
-content_template: templates/task
+content_type: task
weight: 40
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
This page explains how to upgrade a Windows node [created with kubeadm](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes).
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* Familiarize yourself with [the process for upgrading the rest of your kubeadm
cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade). You will want to
upgrade the control plane nodes before upgrading your Windows nodes.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Upgrading worker nodes
@@ -90,4 +91,4 @@ again replacing {{< param "fullversion" >}} with your desired version:
```
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/kubelet-config-file.md b/content/en/docs/tasks/administer-cluster/kubelet-config-file.md
index 6ffe290a19..54cd837370 100644
--- a/content/en/docs/tasks/administer-cluster/kubelet-config-file.md
+++ b/content/en/docs/tasks/administer-cluster/kubelet-config-file.md
@@ -3,10 +3,10 @@ reviewers:
- mtaufen
- dawnchen
title: Set Kubelet parameters via a config file
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
A subset of the Kubelet's configuration parameters may be
@@ -16,15 +16,16 @@ This functionality is considered beta in v1.10.
Providing parameters via a config file is the recommended approach because
it simplifies node deployment and configuration management.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
- A v1.10 or higher Kubelet binary must be installed for beta functionality.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create the config file
@@ -67,9 +68,9 @@ If `--config` is provided and the values are not specified via the command line,
defaults for the `KubeletConfiguration` version apply.
In the above example, this version is `kubelet.config.k8s.io/v1beta1`.
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Relationship to Dynamic Kubelet Config
@@ -77,6 +78,6 @@ If you are using the [Dynamic Kubelet Configuration](/docs/tasks/administer-clus
feature, the combination of configuration provided via `--config` and any flags which override these values
is considered the default "last known good" configuration by the automatic rollback mechanism.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/limit-storage-consumption.md b/content/en/docs/tasks/administer-cluster/limit-storage-consumption.md
index 83ec069915..13dec384ea 100644
--- a/content/en/docs/tasks/administer-cluster/limit-storage-consumption.md
+++ b/content/en/docs/tasks/administer-cluster/limit-storage-consumption.md
@@ -1,9 +1,9 @@
---
title: Limit Storage Consumption
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This example demonstrates an easy way to limit the amount of storage consumed in a namespace.
@@ -11,15 +11,16 @@ The following resources are used in the demonstration: [ResourceQuota](/docs/con
[LimitRange](/docs/tasks/administer-cluster/memory-default-namespace/),
and [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/).
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Scenario: Limiting Storage Consumption
The cluster-admin is operating a cluster on behalf of a user population and the admin wants to control
@@ -77,9 +78,9 @@ spec:
requests.storage: "5Gi"
```
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Summary
@@ -87,6 +88,6 @@ A limit range can put a ceiling on how much storage is requested while a resourc
consumed by a namespace through claim counts and cumulative storage capacity. The allows a cluster-admin to plan their
cluster's storage budget without risk of any one project going over their allotment.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md
index a1d4c786c6..d3d1541d27 100644
--- a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md
+++ b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md
@@ -1,11 +1,11 @@
---
title: Configure Minimum and Maximum CPU Constraints for a Namespace
-content_template: templates/task
+content_type: task
weight: 40
---
-{{% capture overview %}}
+
This page shows how to set minimum and maximum values for the CPU resources used by Containers
and Pods in a namespace. You specify minimum and maximum CPU values in a
@@ -13,19 +13,20 @@ and Pods in a namespace. You specify minimum and maximum CPU values in a
object. If a Pod does not meet the constraints imposed by the LimitRange, it cannot be created
in the namespace.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
Your cluster must have at least 1 CPU available for use to run the task examples.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create a namespace
@@ -239,9 +240,10 @@ Delete your namespace:
kubectl delete namespace constraints-cpu-example
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
### For cluster administrators
@@ -266,7 +268,7 @@ kubectl delete namespace constraints-cpu-example
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md
index 65a91a3538..d2e15c91da 100644
--- a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md
+++ b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md
@@ -1,10 +1,10 @@
---
title: Configure Default CPU Requests and Limits for a Namespace
-content_template: templates/task
+content_type: task
weight: 20
---
-{{% capture overview %}}
+
This page shows how to configure default CPU requests and limits for a namespace.
A Kubernetes cluster can be divided into namespaces. If a Container is created in a namespace
@@ -12,14 +12,15 @@ that has a default CPU limit, and the Container does not specify its own CPU lim
the Container is assigned the default CPU limit. Kubernetes assigns a default CPU request
under certain conditions that are explained later in this topic.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create a namespace
@@ -163,9 +164,10 @@ Delete your namespace:
kubectl delete namespace default-cpu-example
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
### For cluster administrators
@@ -189,6 +191,6 @@ kubectl delete namespace default-cpu-example
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md
index e6a6e1c2b0..a5ad383e78 100644
--- a/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md
+++ b/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md
@@ -1,11 +1,11 @@
---
title: Configure Minimum and Maximum Memory Constraints for a Namespace
-content_template: templates/task
+content_type: task
weight: 30
---
-{{% capture overview %}}
+
This page shows how to set minimum and maximum values for memory used by Containers
running in a namespace. You specify minimum and maximum memory values in a
@@ -13,19 +13,20 @@ running in a namespace. You specify minimum and maximum memory values in a
object. If a Pod does not meet the constraints imposed by the LimitRange,
it cannot be created in the namespace.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
Each node in your cluster must have at least 1 GiB of memory.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create a namespace
@@ -239,9 +240,10 @@ Delete your namespace:
kubectl delete namespace constraints-mem-example
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
### For cluster administrators
@@ -265,7 +267,7 @@ kubectl delete namespace constraints-mem-example
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md
index bb5070bc98..df7fce39f2 100644
--- a/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md
+++ b/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md
@@ -1,27 +1,28 @@
---
title: Configure Default Memory Requests and Limits for a Namespace
-content_template: templates/task
+content_type: task
weight: 10
---
-{{% capture overview %}}
+
This page shows how to configure default memory requests and limits for a namespace.
If a Container is created in a namespace that has a default memory limit, and the Container
does not specify its own memory limit, then the Container is assigned the default memory limit.
Kubernetes assigns a default memory request under certain conditions that are explained later in this topic.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
Each node in your cluster must have at least 2 GiB of memory.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create a namespace
@@ -170,9 +171,10 @@ Delete your namespace:
kubectl delete namespace default-mem-example
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
### For cluster administrators
@@ -196,6 +198,6 @@ kubectl delete namespace default-mem-example
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md
index 9558766410..d69e3d29d6 100644
--- a/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md
+++ b/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md
@@ -1,30 +1,31 @@
---
title: Configure Memory and CPU Quotas for a Namespace
-content_template: templates/task
+content_type: task
weight: 50
---
-{{% capture overview %}}
+
This page shows how to set quotas for the total amount memory and CPU that
can be used by all Containers running in a namespace. You specify quotas in a
[ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
object.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
Each node in your cluster must have at least 1 GiB of memory.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create a namespace
@@ -146,9 +147,10 @@ Delete your namespace:
kubectl delete namespace quota-mem-cpu-example
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
### For cluster administrators
@@ -172,7 +174,7 @@ kubectl delete namespace quota-mem-cpu-example
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md
index 31cac82cf1..c44a07681f 100644
--- a/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md
+++ b/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md
@@ -1,28 +1,29 @@
---
title: Configure a Pod Quota for a Namespace
-content_template: templates/task
+content_type: task
weight: 60
---
-{{% capture overview %}}
+
This page shows how to set a quota for the total number of Pods that can run
in a namespace. You specify quotas in a
[ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
object.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create a namespace
@@ -107,9 +108,10 @@ Delete your namespace:
kubectl delete namespace quota-pod-example
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
### For cluster administrators
@@ -133,7 +135,7 @@ kubectl delete namespace quota-pod-example
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
index 9e3f4d6371..2bf0de8231 100644
--- a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
+++ b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
@@ -3,10 +3,10 @@ reviewers:
- derekwaynecarr
- janetkuo
title: Namespaces Walkthrough
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
Kubernetes {{< glossary_tooltip text="namespaces" term_id="namespace" >}}
help different projects, teams, or customers to share a Kubernetes cluster.
@@ -19,16 +19,17 @@ Use of multiple namespaces is optional.
This example demonstrates how to use Kubernetes namespaces to subdivide your cluster.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Prerequisites
@@ -242,7 +243,7 @@ snowflake 2/2 2 2 2m
```
```shell
-kubectl get pods -l run=snowflake
+kubectl get pods -l app=snowflake
```
```
NAME READY STATUS RESTARTS AGE
@@ -279,7 +280,7 @@ cattle 5/5 5 5 10s
```
```shell
-kubectl get pods -l run=cattle
+kubectl get pods -l app=cattle
```
```
NAME READY STATUS RESTARTS AGE
@@ -295,4 +296,4 @@ At this point, it should be clear that the resources users create in one namespa
As the policy support in Kubernetes evolves, we will extend this scenario to show how you can provide different
authorization rules for each namespace.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/namespaces.md b/content/en/docs/tasks/administer-cluster/namespaces.md
index 076f81d9b9..eabf58ff0b 100644
--- a/content/en/docs/tasks/administer-cluster/namespaces.md
+++ b/content/en/docs/tasks/administer-cluster/namespaces.md
@@ -3,19 +3,20 @@ reviewers:
- derekwaynecarr
- janetkuo
title: Share a Cluster with Namespaces
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page shows how to view, work in, and delete {{< glossary_tooltip text="namespaces" term_id="namespace" >}}. The page also shows how to use Kubernetes namespaces to subdivide your cluster.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* Have an [existing Kubernetes cluster](/docs/setup/).
* Have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Viewing namespaces
@@ -81,6 +82,10 @@ See the [design doc](https://git.k8s.io/community/contributors/design-proposals/
## Creating a new namespace
+{{< note >}}
+ Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces.
+{{< /note >}}
+
1. Create a new YAML file called `my-namespace.yaml` with the contents:
```yaml
@@ -189,12 +194,10 @@ This delete is asynchronous, so for a time you will see the namespace in the `Te
To demonstrate this, let's spin up a simple Deployment and Pods in the `development` namespace.
```shell
- kubectl create deployment snowflake --image=k8s.gcr.io/serve_hostname -n=development
+ kubectl create deployment snowflake --image=k8s.gcr.io/serve_hostname -n=development
kubectl scale deployment snowflake --replicas=2 -n=development
```
We have just created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that just serves the hostname.
- Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
- If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) for more details.
```shell
kubectl get deployment -n=development
@@ -204,7 +207,7 @@ This delete is asynchronous, so for a time you will see the namespace in the `Te
snowflake 2/2 2 2 2m
```
```shell
- kubectl get pods -l run=snowflake -n=development
+ kubectl get pods -l app=snowflake -n=development
```
```
NAME READY STATUS RESTARTS AGE
@@ -226,7 +229,8 @@ This delete is asynchronous, so for a time you will see the namespace in the `Te
Production likes to run cattle, so let's create some cattle pods.
```shell
- kubectl run cattle --image=k8s.gcr.io/serve_hostname --replicas=5 -n=production
+ kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname -n=production
+ kubectl scale deployment cattle --replicas=5 -n=production
kubectl get deployment -n=production
```
@@ -236,7 +240,7 @@ This delete is asynchronous, so for a time you will see the namespace in the `Te
```
```shell
- kubectl get pods -l run=cattle -n=production
+ kubectl get pods -l app=cattle -n=production
```
```
NAME READY STATUS RESTARTS AGE
@@ -252,9 +256,9 @@ At this point, it should be clear that the resources users create in one namespa
As the policy support in Kubernetes evolves, we will extend this scenario to show how you can provide different
authorization rules for each namespace.
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Understanding the motivation for using namespaces
@@ -304,12 +308,13 @@ is local to a namespace. This is useful for using the same configuration across
multiple namespaces such as Development, Staging and Production. If you want to reach
across namespaces, you need to use the fully qualified domain name (FQDN).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [setting the namespace preference](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference).
* Learn more about [setting the namespace for a request](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-for-a-request)
* See [namespaces design](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/architecture/namespaces.md).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md
index 7046752a5f..9efdccfb6e 100644
--- a/content/en/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md
+++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md
@@ -2,19 +2,20 @@
reviewers:
- caseydavenport
title: Use Calico for NetworkPolicy
-content_template: templates/task
+content_type: task
weight: 10
---
-{{% capture overview %}}
+
This page shows a couple of quick ways to create a Calico cluster on Kubernetes.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
Decide whether you want to deploy a [cloud](#creating-a-calico-cluster-with-google-kubernetes-engine-gke) or [local](#creating-a-local-calico-cluster-with-kubeadm) cluster.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Creating a Calico cluster with Google Kubernetes Engine (GKE)
**Prerequisite**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts).
@@ -44,10 +45,11 @@ Decide whether you want to deploy a [cloud](#creating-a-calico-cluster-with-goog
To get a local single-host Calico cluster in fifteen minutes using kubeadm, refer to the
[Calico Quickstart](https://docs.projectcalico.org/latest/getting-started/kubernetes/).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Once your cluster is running, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
index cca685d395..83989b1f58 100644
--- a/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
+++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
@@ -3,23 +3,24 @@ reviewers:
- danwent
- aanm
title: Use Cilium for NetworkPolicy
-content_template: templates/task
+content_type: task
weight: 20
---
-{{% capture overview %}}
+
This page shows how to use Cilium for NetworkPolicy.
For background on Cilium, read the [Introduction to Cilium](https://docs.cilium.io/en/stable/intro).
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Deploying Cilium on Minikube for Basic Testing
To get familiar with Cilium easily you can follow the
@@ -50,7 +51,7 @@ For minikube you can deploy this simple ''all-in-one'' YAML file that includes
DaemonSet configurations for Cilium as well as appropriate RBAC settings:
```shell
-kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml
+kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
```
```
configmap/cilium-config created
@@ -75,9 +76,9 @@ For detailed instructions around deploying Cilium for production, see:
This documentation includes detailed requirements, instructions and example
production DaemonSet files.
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Understanding Cilium components
Deploying a cluster with Cilium adds Pods to the `kube-system` namespace. To see
@@ -98,14 +99,15 @@ cilium-6rxbd 1/1 Running 0 1m
A `cilium` Pod runs on each node in your cluster and enforces network policy
on the traffic to/from Pods on that node using Linux BPF.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Once your cluster is running, you can follow the
[Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)
to try out Kubernetes NetworkPolicy with Cilium.
Have fun, and if you have questions, contact us using the
[Cilium Slack Channel](https://cilium.herokuapp.com/).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md
index 0111f6c21f..673118e312 100644
--- a/content/en/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md
+++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md
@@ -2,25 +2,27 @@
reviewers:
- murali-reddy
title: Use Kube-router for NetworkPolicy
-content_template: templates/task
+content_type: task
weight: 30
---
-{{% capture overview %}}
+
This page shows how to use [Kube-router](https://github.com/cloudnativelabs/kube-router) for NetworkPolicy.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
You need to have a Kubernetes cluster running. If you do not already have a cluster, you can create one by using any of the cluster installers like Kops, Bootkube, Kubeadm etc.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Installing Kube-router addon
The Kube-router Addon comes with a Network Policy Controller that watches Kubernetes API server for any NetworkPolicy and pods updated and configures iptables rules and ipsets to allow or block traffic as directed by the policies. Please follow the [trying Kube-router with cluster installers](https://www.kube-router.io/docs/user-guide/#try-kube-router-with-cluster-installers) guide to install Kube-router addon.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Once you have installed the Kube-router addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
index 42577dae85..df6adcd39f 100644
--- a/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
+++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
@@ -2,23 +2,24 @@
reviewers:
- chrismarino
title: Romana for NetworkPolicy
-content_template: templates/task
+content_type: task
weight: 40
---
-{{% capture overview %}}
+
This page shows how to use Romana for NetworkPolicy.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/).
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Installing Romana with kubeadm
@@ -32,12 +33,13 @@ To apply network policies use one of the following:
* [Example of Romana network policy](https://github.com/romana/core/blob/master/doc/policy.md).
* The NetworkPolicy API.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Once you have installed Romana, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
index 0fcb4ea107..a9d15f40a6 100644
--- a/content/en/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
+++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
@@ -2,23 +2,24 @@
reviewers:
- bboreham
title: Weave Net for NetworkPolicy
-content_template: templates/task
+content_type: task
weight: 50
---
-{{% capture overview %}}
+
This page shows how to use Weave Net for NetworkPolicy.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
You need to have a Kubernetes cluster. Follow the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/) to bootstrap one.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Install the Weave Net addon
@@ -48,12 +49,13 @@ weave-net-pmw8w 2/2 Running 0 9d
Each Node has a weave Pod, and all Pods are `Running` and `2/2 READY`. (`2/2` means that each Pod has `weave` and `weave-npc`.)
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Once you have installed the Weave Net addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. If you have any question, contact us at [#weave-community on Slack or Weave User Group](https://github.com/weaveworks/weave#getting-help).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/nodelocaldns.md b/content/en/docs/tasks/administer-cluster/nodelocaldns.md
index 0907f8f0ac..8aa6b9249b 100644
--- a/content/en/docs/tasks/administer-cluster/nodelocaldns.md
+++ b/content/en/docs/tasks/administer-cluster/nodelocaldns.md
@@ -4,21 +4,22 @@ reviewers:
- zihongz
- sftim
title: Using NodeLocal DNSCache in Kubernetes clusters
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
This page provides an overview of NodeLocal DNSCache feature in Kubernetes.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
- {{% capture steps %}}
+
+
## Introduction
@@ -27,7 +28,7 @@ NodeLocal DNSCache improves Cluster DNS performance by running a dns caching age
## Motivation
-* With the current DNS architecture, it is possible that Pods with the highest DNS QPS have to reach out to a different node, if there is no local kube-dns/CoreDNS instance.
+* With the current DNS architecture, it is possible that Pods with the highest DNS QPS have to reach out to a different node, if there is no local kube-dns/CoreDNS instance.
Having a local cache will help improve the latency in such scenarios.
* Skipping iptables DNAT and connection tracking will help reduce [conntrack races](https://github.com/kubernetes/kubernetes/issues/56903) and avoid UDP DNS entries filling up conntrack table.
@@ -45,7 +46,7 @@ Having a local cache will help improve the latency in such scenarios.
This is the path followed by DNS Queries after NodeLocal DNSCache is enabled:
-{{< figure src="/images/docs/nodelocaldns.jpg" alt="NodeLocal DNSCache flow" title="Nodelocal DNSCache flow" caption="This image shows how NodeLocal DNSCache handles DNS queries." >}}
+{{< figure src="/images/docs/nodelocaldns.svg" alt="NodeLocal DNSCache flow" title="Nodelocal DNSCache flow" caption="This image shows how NodeLocal DNSCache handles DNS queries." >}}
## Configuration
{{< note >}} The local listen IP address for NodeLocal DNSCache can be any IP in the 169.254.20.0/16 space or any other IP address that can be guaranteed to not collide with any existing IP. This document uses 169.254.20.10 as an example.
@@ -54,33 +55,33 @@ This is the path followed by DNS Queries after NodeLocal DNSCache is enabled:
This feature can be enabled using the following steps:
* Prepare a manifest similar to the sample [`nodelocaldns.yaml`](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml) and save it as `nodelocaldns.yaml.`
-* Substitute the variables in the manifest with the right values:
+* Substitute the variables in the manifest with the right values:
+
+ * kubedns=`kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP}`
+
+ * domain=``
- * kubedns=`kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP}`
-
- * domain=``
-
* localdns=``
-
+
`` is "cluster.local" by default. `` is the local listen IP address chosen for NodeLocal DNSCache.
- * If kube-proxy is running in IPTABLES mode:
-
+ * If kube-proxy is running in IPTABLES mode:
+
``` bash
sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__/$kubedns/g" nodelocaldns.yaml
```
-
- `__PILLAR__CLUSTER__DNS__` and `__PILLAR__UPSTREAM__SERVERS__` will be populated by the node-local-dns pods.
+
+ `__PILLAR__CLUSTER__DNS__` and `__PILLAR__UPSTREAM__SERVERS__` will be populated by the node-local-dns pods.
In this mode, node-local-dns pods listen on both the kube-dns service IP as well as ``, so pods can lookup DNS records using either IP address.
- * If kube-proxy is running in IPVS mode:
-
+ * If kube-proxy is running in IPVS mode:
+
``` bash
sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml
```
- In this mode, node-local-dns pods listen only on ``. The node-local-dns interface cannot bind the kube-dns cluster IP since the interface used for IPVS loadbalancing already uses this address.
+ In this mode, node-local-dns pods listen only on ``. The node-local-dns interface cannot bind the kube-dns cluster IP since the interface used for IPVS loadbalancing already uses this address.
`__PILLAR__UPSTREAM__SERVERS__` will be populated by the node-local-dns pods.
-
+
* Run `kubectl create -f nodelocaldns.yaml`
* If using kube-proxy in IPVS mode, `--cluster-dns` flag to kubelet needs to be modified to use `` that NodeLocal DNSCache is listening on.
Otherwise, there is no need to modify the value of the `--cluster-dns` flag, since NodeLocal DNSCache listens on both the kube-dns service IP as well as ``.
@@ -88,4 +89,4 @@ This feature can be enabled using the following steps:
Once enabled, node-local-dns Pods will run in the kube-system namespace on each of the cluster nodes. This Pod runs [CoreDNS](https://github.com/coredns/coredns) in cache mode, so all CoreDNS metrics exposed by the different plugins will be available on a per-node basis.
You can disable this feature by removing the DaemonSet, using `kubectl delete -f ` . You should also revert any changes you made to the kubelet configuration.
- {{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/out-of-resource.md b/content/en/docs/tasks/administer-cluster/out-of-resource.md
index c52415f4c6..a9d2ee3702 100644
--- a/content/en/docs/tasks/administer-cluster/out-of-resource.md
+++ b/content/en/docs/tasks/administer-cluster/out-of-resource.md
@@ -4,10 +4,10 @@ reviewers:
- vishh
- timstclair
title: Configure Out of Resource Handling
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
This page explains how to configure out of resource handling with `kubelet`.
@@ -16,10 +16,10 @@ are low. This is especially important when dealing with incompressible
compute resources, such as memory or disk space. If such resources are exhausted,
nodes become unstable.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Eviction Policy
@@ -372,4 +372,4 @@ to prevent system OOMs, and promote eviction of workloads so cluster state can r
The Pod eviction may evict more Pods than needed due to stats collection timing gap. This can be mitigated by adding
the ability to get root container stats on an on-demand basis [(https://github.com/google/cadvisor/issues/1247)](https://github.com/google/cadvisor/issues/1247) in the future.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/quota-api-object.md b/content/en/docs/tasks/administer-cluster/quota-api-object.md
index faf7210384..1fb48c7a2b 100644
--- a/content/en/docs/tasks/administer-cluster/quota-api-object.md
+++ b/content/en/docs/tasks/administer-cluster/quota-api-object.md
@@ -1,10 +1,10 @@
---
title: Configure Quotas for API Objects
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page shows how to configure quotas for API objects, including
PersistentVolumeClaims and Services. A quota restricts the number of
@@ -13,17 +13,18 @@ You specify quotas in a
[ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
object.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create a namespace
@@ -140,9 +141,10 @@ Delete your namespace:
kubectl delete namespace quota-object-example
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
### For cluster administrators
@@ -167,7 +169,7 @@ kubectl delete namespace quota-object-example
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md
index af5696d622..6218e8ce81 100644
--- a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md
+++ b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md
@@ -3,11 +3,11 @@ reviewers:
- mtaufen
- dawnchen
title: Reconfigure a Node's Kubelet in a Live Cluster
-content_template: templates/task
+content_type: task
min-kubernetes-server-version: v1.11
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
[Dynamic Kubelet Configuration](https://github.com/kubernetes/enhancements/issues/281)
@@ -25,9 +25,10 @@ of nodes before rolling them out cluster-wide. Advice on configuring specific
fields is available in the inline `KubeletConfiguration`
[type documentation](https://github.com/kubernetes/kubernetes/blob/release-1.11/pkg/kubelet/apis/kubeletconfig/v1beta1/types.go).
{{< /warning >}}
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
You need to have a Kubernetes cluster.
You also need kubectl v1.11 or higher, configured to communicate with your cluster.
{{< version-check >}}
@@ -43,9 +44,9 @@ because there are manual alternatives.
For each node that you're reconfiguring, you must set the kubelet
`--dynamic-config-dir` flag to a writable directory.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Reconfiguring the kubelet on a running node in your cluster
@@ -71,7 +72,7 @@ will receive default values appropriate to the configuration version
(e.g. `kubelet.config.k8s.io/v1beta1`), unless overridden by flags.
The status of the Node's kubelet configuration is reported via
-`Node.Spec.Status.Config`. Once you have updated a Node to use the new
+`Node.Status.Config`. Once you have updated a Node to use the new
ConfigMap, you can observe this status to confirm that the Node is using the
intended configuration.
@@ -311,9 +312,9 @@ empty, since all config sources have been reset to `nil`, which indicates that
the local default config is `assigned`, `active`, and `lastKnownGood`, and no
error is reported.
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## `kubectl patch` example
You can change a Node's configSource using several different mechanisms.
@@ -374,9 +375,9 @@ internal failure, see Kubelet log for details | The kubelet encountered some int
{{< /table >}}
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
- For more information on configuring the kubelet via a configuration file, see
[Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file).
- See the reference documentation for [`NodeConfigSource`](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core)
-{{% /capture %}}
\ No newline at end of file
diff --git a/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md b/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md
index c78c9edb42..4f00675c37 100644
--- a/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md
+++ b/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md
@@ -4,11 +4,11 @@ reviewers:
- derekwaynecarr
- dashpole
title: Reserve Compute Resources for System Daemons
-content_template: templates/task
+content_type: task
min-kubernetes-server-version: 1.8
---
-{{% capture overview %}}
+
Kubernetes nodes can be scheduled to `Capacity`. Pods can consume all the
available capacity on a node by default. This is an issue because nodes
@@ -22,19 +22,20 @@ compute resources for system daemons. Kubernetes recommends cluster
administrators to configure `Node Allocatable` based on their workload density
on each node.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
Your Kubernetes server must be at or later than version 1.17 to use
the kubelet command line option `--reserved-cpus` to set an
[explicitly reserved CPU list](#explicitly-reserved-cpu-list).
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Node Allocatable
@@ -226,9 +227,9 @@ more features are added. Over time, kubernetes project will attempt to bring
down utilization of node system daemons, but that is not a priority as of now.
So expect a drop in `Allocatable` capacity in future releases.
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Example Scenario
@@ -251,4 +252,3 @@ If `kube-reserved` and/or `system-reserved` is not enforced and system daemons
exceed their reservation, `kubelet` evicts pods whenever the overall node memory
usage is higher than `31.5Gi` or `storage` is greater than `90Gi`
-{{% /capture %}}
\ No newline at end of file
diff --git a/content/en/docs/tasks/administer-cluster/running-cloud-controller.md b/content/en/docs/tasks/administer-cluster/running-cloud-controller.md
index 71cc28ff40..aa01c902e4 100644
--- a/content/en/docs/tasks/administer-cluster/running-cloud-controller.md
+++ b/content/en/docs/tasks/administer-cluster/running-cloud-controller.md
@@ -4,10 +4,10 @@ reviewers:
- thockin
- wlan0
title: Cloud Controller Manager Administration
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
{{< feature-state state="beta" for_k8s_version="v1.11" >}}
@@ -15,10 +15,10 @@ Since cloud providers develop and release at a different pace compared to the Ku
The `cloud-controller-manager` can be linked to any cloud provider that satisfies [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go). For backwards compatibility, the [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) provided in the core Kubernetes project uses the same cloud libraries as `kube-controller-manager`. Cloud providers already supported in Kubernetes core are expected to use the in-tree cloud-controller-manager to transition out of Kubernetes core.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Administration
@@ -82,9 +82,10 @@ A good example of this is the TLS bootstrapping feature in the Kubelet. TLS boot
As this initiative evolves, changes will be made to address these issues in upcoming releases.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
To build and develop your own cloud controller manager, read [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/safely-drain-node.md b/content/en/docs/tasks/administer-cluster/safely-drain-node.md
index 29006ff754..e18b2ed87d 100644
--- a/content/en/docs/tasks/administer-cluster/safely-drain-node.md
+++ b/content/en/docs/tasks/administer-cluster/safely-drain-node.md
@@ -5,14 +5,15 @@ reviewers:
- foxish
- kow3ns
title: Safely Drain a Node while Respecting the PodDisruptionBudget
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page shows how to safely drain a node, respecting the PodDisruptionBudget you have defined.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
This task assumes that you have met the following prerequisites:
@@ -24,9 +25,9 @@ This task assumes that you have met the following prerequisites:
and [Configured PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) for
applications that need them.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Use `kubectl drain` to remove a node from service
@@ -151,13 +152,14 @@ In this case, there are two potential solutions:
Kubernetes does not specify what the behavior should be in this case; it is up to the
application owners and cluster owners to establish an agreement on behavior in these cases.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Follow steps to protect your application by [configuring a Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/).
* Learn more about [maintenance on a node](/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md
index d2d58ae702..7e558fb48f 100644
--- a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md
+++ b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md
@@ -5,23 +5,24 @@ reviewers:
- ericchiang
- destijl
title: Securing a Cluster
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This document covers topics related to protecting a cluster from accidental or malicious access
and provides recommendations on overall security.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Controlling access to the Kubernetes API
@@ -254,6 +255,6 @@ Join the [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernete
group for emails about security announcements. See the [security reporting](/security/)
page for more on how to report vulnerabilities.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md
index f96c066dd5..60af560e30 100644
--- a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md
+++ b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md
@@ -2,25 +2,26 @@
title: Using sysctls in a Kubernetes Cluster
reviewers:
- sttts
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
This document describes how to configure and use kernel parameters within a
Kubernetes cluster using the {{< glossary_tooltip term_id="sysctl" >}}
interface.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Listing all Sysctl Parameters
@@ -56,7 +57,8 @@ The following sysctls are supported in the _safe_ set:
- `kernel.shm_rmid_forced`,
- `net.ipv4.ip_local_port_range`,
-- `net.ipv4.tcp_syncookies`.
+- `net.ipv4.tcp_syncookies`,
+- `net.ipv4.ping_group_range` (since Kubernetes 1.18).
{{< note >}}
The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
@@ -140,9 +142,9 @@ spec:
value: "65536"
...
```
-{{% /capture %}}
-{{% capture discussion %}}
+
+
{{< warning >}}
Due to their nature of being _unsafe_, the use of _unsafe_ sysctls
@@ -188,9 +190,9 @@ Do not configure these two fields such that there is overlap, meaning that a
given sysctl is both allowed and forbidden.
{{< warning >}}
-If you whitelist unsafe sysctls via the `allowedUnsafeSysctls` field
+If you allow unsafe sysctls via the `allowedUnsafeSysctls` field
in a PodSecurityPolicy, any pod using such a sysctl will fail to start
-if the sysctl is not whitelisted via the `--allowed-unsafe-sysctls` kubelet
+if the sysctl is not allowed via the `--allowed-unsafe-sysctls` kubelet
flag as well on that node.
{{< /warning >}}
@@ -210,4 +212,4 @@ spec:
...
```
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/administer-cluster/topology-manager.md b/content/en/docs/tasks/administer-cluster/topology-manager.md
index 156146e1c2..8455bb0d8d 100644
--- a/content/en/docs/tasks/administer-cluster/topology-manager.md
+++ b/content/en/docs/tasks/administer-cluster/topology-manager.md
@@ -8,11 +8,11 @@ reviewers:
- nolancon
- bg-chun
-content_template: templates/task
+content_type: task
min-kubernetes-server-version: v1.18
---
-{{% capture overview %}}
+
{{< feature-state state="beta" for_k8s_version="v1.18" >}}
@@ -22,15 +22,16 @@ In order to extract the best performance, optimizations related to CPU isolation
_Topology Manager_ is a Kubelet component that aims to co-ordinate the set of components that are responsible for these optimizations.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## How Topology Manager Works
@@ -216,4 +217,4 @@ Using this information the Topology Manager calculates the optimal hint for the
3. The Device Manager and the CPU Manager are the only components to adopt the Topology Manager's HintProvider interface. This means that NUMA alignment can only be achieved for resources managed by the CPU Manager and the Device Manager. Memory or Hugepages are not considered by the Topology Manager for NUMA alignment.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/_index.md b/content/en/docs/tasks/configure-pod-container/_index.md
index ea8d5a89d5..462b19e4e9 100755
--- a/content/en/docs/tasks/configure-pod-container/_index.md
+++ b/content/en/docs/tasks/configure-pod-container/_index.md
@@ -1,5 +1,6 @@
---
title: "Configure Pods and Containers"
+description: Perform common configuration tasks for Pods and containers.
weight: 20
---
diff --git a/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md
index 181b92b8e1..5e79704cc4 100644
--- a/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md
+++ b/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md
@@ -1,20 +1,21 @@
---
title: Assign CPU Resources to Containers and Pods
-content_template: templates/task
+content_type: task
weight: 20
---
-{{% capture overview %}}
+
This page shows how to assign a CPU *request* and a CPU *limit* to
a container. Containers cannot use more CPU than the configured limit.
Provided the system has CPU time free, a container is guaranteed to be
allocated as much CPU as it requests.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
@@ -48,10 +49,10 @@ NAME
v1beta1.metrics.k8s.io
```
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create a namespace
@@ -239,9 +240,10 @@ Delete your namespace:
kubectl delete namespace cpu-example
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
### For app developers
@@ -266,4 +268,4 @@ kubectl delete namespace cpu-example
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md
index e8f7d8073a..394f435d12 100644
--- a/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md
+++ b/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md
@@ -1,19 +1,20 @@
---
title: Assign Memory Resources to Containers and Pods
-content_template: templates/task
+content_type: task
weight: 10
---
-{{% capture overview %}}
+
This page shows how to assign a memory *request* and a memory *limit* to a
Container. A Container is guaranteed to have as much memory as it requests,
but is not allowed to use more memory than its limit.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
@@ -46,9 +47,9 @@ NAME
v1beta1.metrics.k8s.io
```
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create a namespace
@@ -330,9 +331,10 @@ Delete your namespace. This deletes all the Pods that you created for this task:
kubectl delete namespace mem-example
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
### For app developers
@@ -356,7 +358,7 @@ kubectl delete namespace mem-example
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md b/content/en/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md
index 16773cd215..8306724c1d 100644
--- a/content/en/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md
+++ b/content/en/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md
@@ -1,22 +1,23 @@
---
title: Assign Pods to Nodes using Node Affinity
min-kubernetes-server-version: v1.10
-content_template: templates/task
+content_type: task
weight: 120
---
-{{% capture overview %}}
+
This page shows how to assign a Kubernetes Pod to a particular node using Node Affinity in a
Kubernetes cluster.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Add a label to a node
@@ -112,9 +113,10 @@ This means that the pod will prefer a node that has a `disktype=ssd` label.
nginx 1/1 Running 0 13s 10.200.0.4 worker0
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Learn more about
[Node Affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/assign-pods-nodes.md b/content/en/docs/tasks/configure-pod-container/assign-pods-nodes.md
index b5f6876e6b..f1e6e6e9ef 100644
--- a/content/en/docs/tasks/configure-pod-container/assign-pods-nodes.md
+++ b/content/en/docs/tasks/configure-pod-container/assign-pods-nodes.md
@@ -1,21 +1,22 @@
---
title: Assign Pods to Nodes
-content_template: templates/task
+content_type: task
weight: 120
---
-{{% capture overview %}}
+
This page shows how to assign a Kubernetes Pod to a particular node in a
Kubernetes cluster.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Add a label to a node
@@ -94,10 +95,11 @@ You can also schedule a pod to one specific node via setting `nodeName`.
Use the configuration file to create a pod that will get scheduled on `foo-node` only.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [labels and selectors](/docs/concepts/overview/working-with-objects/labels/).
* Learn more about [nodes](/docs/concepts/architecture/nodes/).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
index 57b5fad6c6..f5116e7691 100644
--- a/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
+++ b/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
@@ -1,27 +1,28 @@
---
title: Attach Handlers to Container Lifecycle Events
-content_template: templates/task
+content_type: task
weight: 140
---
-{{% capture overview %}}
+
This page shows how to attach handlers to Container lifecycle events. Kubernetes supports
the postStart and preStop events. Kubernetes sends the postStart event immediately
after a Container is started, and it sends the preStop event immediately before the
Container is terminated.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Define postStart and preStop handlers
@@ -56,11 +57,11 @@ The output shows the text written by the postStart handler:
Hello from the postStart handler
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Discussion
@@ -82,10 +83,11 @@ This means that the preStop hook is not invoked when the Pod is *completed*.
This limitation is tracked in [issue #55087](https://github.com/kubernetes/kubernetes/issues/55807).
{{< /note >}}
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
* Learn more about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
@@ -97,6 +99,6 @@ This limitation is tracked in [issue #55087](https://github.com/kubernetes/kuber
* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
* See `terminationGracePeriodSeconds` in [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md
index 8045ae9a02..a2b3f24628 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md
@@ -1,10 +1,10 @@
---
title: Configure GMSA for Windows Pods and containers
-content_template: templates/task
+content_type: task
weight: 20
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
@@ -12,14 +12,15 @@ This page shows how to configure [Group Managed Service Accounts](https://docs.m
In Kubernetes, GMSA credential specs are configured at a Kubernetes cluster-wide scope as Custom Resources. Windows Pods, as well as individual containers within a Pod, can be configured to use a GMSA for domain based functions (e.g. Kerberos authentication) when interacting with other Windows services. As of v1.16, the Docker runtime supports GMSA for Windows workloads.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
You need to have a Kubernetes cluster and the `kubectl` command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes. This section covers a set of initial steps required once for each cluster:
### Install the GMSACredentialSpec CRD
-A [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)(CRD) for GMSA credential spec resources needs to be configured on the cluster to define the custom resource type `GMSACredentialSpec`. Download the GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) and save it as gmsa-crd.yaml.
+A [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD) for GMSA credential spec resources needs to be configured on the cluster to define the custom resource type `GMSACredentialSpec`. Download the GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) and save it as gmsa-crd.yaml.
Next, install the CRD with `kubectl apply -f gmsa-crd.yaml`
### Install webhooks to validate GMSA users
@@ -43,9 +44,9 @@ A [script](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission
The [YAML template](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl) used by the script may also be used to deploy the webhooks and associated objects manually (with appropriate substitutions for the parameters)
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Configure GMSAs and Windows nodes in Active Directory
Before Pods in Kubernetes can be configured to use GMSAs, the desired GMSAs need to be provisioned in Active Directory as described in the [Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1). Windows worker nodes (that are part of the Kubernetes cluster) need to be configured in Active Directory to access the secret credentials associated with the desired GMSA as described in the [Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet)
@@ -252,4 +253,4 @@ If the above command corrects the error, you can automate the step by adding the
If you add the `lifecycle` section show above to your Pod spec, the Pod will execute the commands listed to restart the `netlogon` service until the `nltest.exe /query` command exits without error.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
index 19b077ab35..1630708182 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
@@ -1,10 +1,10 @@
---
title: Configure Liveness, Readiness and Startup Probes
-content_template: templates/task
+content_type: task
weight: 110
---
-{{% capture overview %}}
+
This page shows how to configure liveness, readiness and startup probes for containers.
@@ -25,15 +25,16 @@ it succeeds, making sure those probes don't interfere with the application start
This can be used to adopt liveness checks on slow starting containers, avoiding them
getting killed by the kubelet before they are up and running.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Define a liveness command
@@ -331,7 +332,7 @@ to 1 second. Minimum value is 1.
* `successThreshold`: Minimum consecutive successes for the probe to be
considered successful after having failed. Defaults to 1. Must be 1 for
liveness. Minimum value is 1.
-* `failureThreshold`: When a Pod starts and the probe fails, Kubernetes will
+* `failureThreshold`: When a probe fails, Kubernetes will
try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready.
Defaults to 3. Minimum value is 1.
@@ -360,9 +361,10 @@ For a TCP probe, the kubelet makes the probe connection at the node, not in the
means that you can not use a service name in the `host` parameter since the kubelet is unable
to resolve it.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about
[Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
@@ -373,6 +375,6 @@ You can also read the API references for:
* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
* [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
index 024e6929c7..6ff6c21530 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
@@ -1,10 +1,10 @@
---
title: Configure a Pod to Use a PersistentVolume for Storage
-content_template: templates/task
+content_type: task
weight: 60
---
-{{% capture overview %}}
+
This page shows you how to configure a Pod to use a
{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}
@@ -20,9 +20,10 @@ PersistentVolume.
1. You create a Pod that uses the above PersistentVolumeClaim for storage.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* You need to have a Kubernetes cluster that has only one Node, and the
{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}
@@ -33,9 +34,9 @@ do not already have a single-node cluster, you can create one by using
* Familiarize yourself with the material in
[Persistent Volumes](/docs/concepts/storage/persistent-volumes/).
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create an index.html file on your Node
@@ -237,10 +238,10 @@ sudo rmdir /mnt/data
You can now close the shell to your Node.
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Access control
@@ -270,10 +271,11 @@ When a Pod consumes a PersistentVolume, the GIDs associated with the
PersistentVolume are not present on the Pod resource itself.
{{< /note >}}
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
* Read the [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md).
@@ -285,6 +287,6 @@ PersistentVolume are not present on the Pod resource itself.
* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md
index c7f80b0fad..42eff59db0 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md
@@ -1,24 +1,25 @@
---
title: Configure a Pod to Use a ConfigMap
-content_template: templates/task
+content_type: task
weight: 150
card:
name: tasks
weight: 50
---
-{{% capture overview %}}
+
ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. This page provides a series of usage examples demonstrating how to create ConfigMaps and configure Pods using data stored in ConfigMaps.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create a ConfigMap
@@ -628,9 +629,9 @@ When a ConfigMap already being consumed in a volume is updated, projected keys a
A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates.
{{< /note >}}
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Understanding ConfigMaps and Pods
@@ -680,9 +681,10 @@ data:
- You can't use ConfigMaps for {{< glossary_tooltip text="static pods" term_id="static-pod" >}}, because the Kubelet does not support this.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Follow a real world example of [Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/configure-pod-initialization.md b/content/en/docs/tasks/configure-pod-container/configure-pod-initialization.md
index a418a8d7c0..9a8a33f655 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-pod-initialization.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-pod-initialization.md
@@ -1,22 +1,23 @@
---
title: Configure Pod Initialization
-content_template: templates/task
+content_type: task
weight: 130
---
-{{% capture overview %}}
+
This page shows how to use an Init Container to initialize a Pod before an
application Container runs.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create a Pod that has an Init Container
@@ -78,9 +79,10 @@ The output shows that nginx is serving the web page that was written by the init
Kubernetes is open source giving you the freedom to take advantage ...
...
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about
[communicating between Containers running in the same Pod](/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/).
@@ -88,6 +90,6 @@ The output shows that nginx is serving the web page that was written by the init
* Learn more about [Volumes](/docs/concepts/storage/volumes/).
* Learn more about [Debugging Init Containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md b/content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md
index ec6f2d9528..ad99a05c27 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md
@@ -3,11 +3,11 @@ reviewers:
- jpeeler
- pmorie
title: Configure a Pod to Use a Projected Volume for Storage
-content_template: templates/task
+content_type: task
weight: 70
---
-{{% capture overview %}}
+
This page shows how to use a [`projected`](/docs/concepts/storage/volumes/#projected) Volume to mount
several existing volume sources into the same directory. Currently, `secret`, `configMap`, `downwardAPI`,
and `serviceAccountToken` volumes can be projected.
@@ -15,13 +15,14 @@ and `serviceAccountToken` volumes can be projected.
{{< note >}}
`serviceAccountToken` is not a volume type.
{{< /note >}}
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Configure a projected volume for a pod
In this exercise, you create username and password {{< glossary_tooltip text="Secrets" term_id="secret" >}} from local files. You then create a Pod that runs one container, using a [`projected`](/docs/concepts/storage/volumes/#projected) Volume to mount the Secrets into the same shared directory.
@@ -77,9 +78,10 @@ kubectl delete pod test-projected-volume
kubectl delete secret user pass
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [`projected`](/docs/concepts/storage/volumes/#projected) volumes.
* Read the [all-in-one volume](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md) design document.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/configure-runasusername.md b/content/en/docs/tasks/configure-pod-container/configure-runasusername.md
index ac912327f3..12c10a9ddf 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-runasusername.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-runasusername.md
@@ -1,24 +1,25 @@
---
title: Configure RunAsUserName for Windows pods and containers
-content_template: templates/task
+content_type: task
weight: 20
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
This page shows how to use the `runAsUserName` setting for Pods and containers that will run on Windows nodes. This is roughly equivalent of the Linux-specific `runAsUser` setting, allowing you to run applications in a container as a different username than the default.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
You need to have a Kubernetes cluster and the kubectl command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes where pods with containers running Windows workloads will get scheduled.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Set the Username for a Pod
@@ -114,12 +115,12 @@ Examples of acceptable values for the `runAsUserName` field: `ContainerAdministr
For more information about these limtations, check [here](https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers-domains-sites-and) and [here](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.localaccounts/new-localuser?view=powershell-5.1).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [Guide for scheduling Windows containers in Kubernetes](/docs/setup/production-environment/windows/user-guide-windows-containers/)
* [Managing Workload Identity with Group Managed Service Accounts (GMSA)](/docs/setup/production-environment/windows/user-guide-windows-containers/#managing-workload-identity-with-group-managed-service-accounts)
* [Configure GMSA for Windows pods and containers](/docs/tasks/configure-pod-container/configure-gmsa/)
-{{% /capture %}}
\ No newline at end of file
diff --git a/content/en/docs/tasks/configure-pod-container/configure-service-account.md b/content/en/docs/tasks/configure-pod-container/configure-service-account.md
index 021a8feb22..2486e520e1 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-service-account.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-service-account.md
@@ -4,11 +4,11 @@ reviewers:
- liggitt
- thockin
title: Configure Service Accounts for Pods
-content_template: templates/task
+content_type: task
weight: 90
---
-{{% capture overview %}}
+
A service account provides an identity for processes that run in a Pod.
{{< note >}}
@@ -23,16 +23,17 @@ authenticated by the apiserver as a particular User Account (currently this is
usually `admin`, unless your cluster administrator has customized your cluster). Processes in containers inside pods can also contact the apiserver.
When they do, they are authenticated as a particular Service Account (for example, `default`).
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Use the Default Service Account to access the API server.
@@ -322,7 +323,7 @@ The application is responsible for reloading the token when it rotates. Periodic
{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
The Service Account Issuer Discovery feature is enabled by enabling the
-`ServiceAccountIssuerDiscovery` [feature gate](/docs/reference/command-line-tools-reference/feature)
+`ServiceAccountIssuerDiscovery` [feature gate](/docs/reference/command-line-tools-reference/feature-gates)
and then enabling the Service Account Token Projection feature as described
[above](#service-account-token-volume-projection).
@@ -370,9 +371,10 @@ override the `jwks_uri` in the OpenID Provider Configuration so that it points
to the public endpoint, rather than the API server's address, by passing the
`--service-account-jwks-uri` flag to the API server. Like the issuer URL, the
JWKS URI is required to use the `https` scheme.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
See also:
@@ -380,4 +382,4 @@ See also:
- [Service Account Signing Key Retrieval KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190730-oidc-discovery.md)
- [OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/en/docs/tasks/configure-pod-container/configure-volume-storage.md
index bec97a2975..69e665b42e 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-volume-storage.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-volume-storage.md
@@ -1,10 +1,10 @@
---
title: Configure a Pod to Use a Volume for Storage
-content_template: templates/task
+content_type: task
weight: 50
---
-{{% capture overview %}}
+
This page shows how to configure a Pod to use a Volume for storage.
@@ -14,15 +14,16 @@ consistent storage that is independent of the Container, you can use a
[Volume](/docs/concepts/storage/volumes/). This is especially important for stateful
applications, such as key-value stores (such as Redis) and databases.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Configure a volume for a Pod
@@ -126,9 +127,10 @@ of `Always`.
kubectl delete pod redis
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* See [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core).
@@ -140,6 +142,6 @@ GCE and EBS on EC2, which are preferred for critical data and will handle
details such as mounting and unmounting the devices on the nodes. See
[Volumes](/docs/concepts/storage/volumes/) for more details.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/extended-resource.md b/content/en/docs/tasks/configure-pod-container/extended-resource.md
index 36d957ca01..25fa11b0d9 100644
--- a/content/en/docs/tasks/configure-pod-container/extended-resource.md
+++ b/content/en/docs/tasks/configure-pod-container/extended-resource.md
@@ -1,19 +1,20 @@
---
title: Assign Extended Resources to a Container
-content_template: templates/task
+content_type: task
weight: 40
---
-{{% capture overview %}}
+
{{< feature-state state="stable" >}}
This page shows how to assign extended resources to a Container.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
@@ -21,10 +22,10 @@ Before you do this exercise, do the exercise in
[Advertise Extended Resources for a Node](/docs/tasks/administer-cluster/extended-resource-node/).
That will configure one of your Nodes to advertise a dongle resource.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Assign an extended resource to a Pod
@@ -127,9 +128,10 @@ kubectl delete pod extended-resource-demo
kubectl delete pod extended-resource-demo-2
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
### For application developers
@@ -140,4 +142,4 @@ kubectl delete pod extended-resource-demo-2
* [Advertise Extended Resources for a Node](/docs/tasks/administer-cluster/extended-resource-node/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md
index 9184883003..ce0b5b3656 100644
--- a/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md
+++ b/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md
@@ -1,26 +1,27 @@
---
title: Pull an Image from a Private Registry
-content_template: templates/task
+content_type: task
weight: 100
---
-{{% capture overview %}}
+
This page shows how to create a Pod that uses a Secret to pull an image from a
private Docker registry or repository.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* To do this exercise, you need a
[Docker ID](https://docs.docker.com/docker-id/) and password.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Log in to Docker
@@ -200,9 +201,10 @@ kubectl apply -f my-private-reg-pod.yaml
kubectl get pod private-reg
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [Secrets](/docs/concepts/configuration/secret/).
* Learn more about [using a private registry](/docs/concepts/containers/images/#using-a-private-registry).
@@ -211,5 +213,5 @@ kubectl get pod private-reg
* See [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core).
* See the `imagePullSecrets` field of [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md
index cd9edd0410..dec9e8db91 100644
--- a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md
+++ b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md
@@ -1,27 +1,28 @@
---
title: Configure Quality of Service for Pods
-content_template: templates/task
+content_type: task
weight: 30
---
-{{% capture overview %}}
+
This page shows how to configure Pods so that they will be assigned particular
Quality of Service (QoS) classes. Kubernetes uses QoS classes to make decisions about
scheduling and evicting Pods.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## QoS classes
@@ -235,9 +236,10 @@ Delete your namespace:
kubectl delete namespace qos-example
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
### For app developers
@@ -263,7 +265,7 @@ kubectl delete namespace qos-example
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
* [Control Topology Management policies on a node](/docs/tasks/administer-cluster/topology-manager/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/security-context.md b/content/en/docs/tasks/configure-pod-container/security-context.md
index 0c2bb05d0c..38662760b7 100644
--- a/content/en/docs/tasks/configure-pod-container/security-context.md
+++ b/content/en/docs/tasks/configure-pod-container/security-context.md
@@ -4,11 +4,11 @@ reviewers:
- mikedanese
- thockin
title: Configure a Security Context for a Pod or Container
-content_template: templates/task
+content_type: task
weight: 80
---
-{{% capture overview %}}
+
A security context defines privilege and access control settings for
a Pod or Container. Security context settings include, but are not limited to:
@@ -37,15 +37,16 @@ for a comprehensive list.
For more information about security mechanisms in Linux, see
[Overview of Linux Kernel Security Features](https://www.linux.com/learn/overview-linux-kernel-security-features)
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Set the security context for a Pod
@@ -409,9 +410,10 @@ kubectl delete pod security-context-demo-3
kubectl delete pod security-context-demo-4
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)
* [SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
@@ -423,4 +425,4 @@ kubectl delete pod security-context-demo-4
document](https://git.k8s.io/community/contributors/design-proposals/auth/no-new-privs.md)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/share-process-namespace.md b/content/en/docs/tasks/configure-pod-container/share-process-namespace.md
index ee227d3f9b..dfb8e40906 100644
--- a/content/en/docs/tasks/configure-pod-container/share-process-namespace.md
+++ b/content/en/docs/tasks/configure-pod-container/share-process-namespace.md
@@ -5,11 +5,11 @@ reviewers:
- verb
- yujuhong
- dchen1107
-content_template: templates/task
+content_type: task
weight: 160
---
-{{% capture overview %}}
+
{{< feature-state state="stable" for_k8s_version="v1.17" >}}
@@ -21,15 +21,16 @@ You can use this feature to configure cooperating containers, such as a log
handler sidecar container, or to troubleshoot container images that don't
include debugging utilities like a shell.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Configure a Pod
@@ -93,9 +94,9 @@ events {
worker_connections 1024;
```
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Understanding Process Namespace Sharing
@@ -117,6 +118,6 @@ containers, though, so it's important to understand these differences:
`/proc/$pid/root` link.** This makes debugging easier, but it also means
that filesystem secrets are protected only by filesystem permissions.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/static-pod.md b/content/en/docs/tasks/configure-pod-container/static-pod.md
index fc31526348..5189fdb882 100644
--- a/content/en/docs/tasks/configure-pod-container/static-pod.md
+++ b/content/en/docs/tasks/configure-pod-container/static-pod.md
@@ -3,10 +3,10 @@ reviewers:
- jsafrane
title: Create static Pods
weight: 170
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
*Static Pods* are managed directly by the kubelet daemon on a specific node,
@@ -30,9 +30,10 @@ Pods to run a Pod on every node, you should probably be using a
instead.
{{< /note >}}
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
@@ -41,10 +42,10 @@ and that your nodes are running the Fedora operating system.
Instructions for other distributions or Kubernetes installations may vary.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create a static pod {#static-pod-creation}
@@ -236,4 +237,4 @@ CONTAINER ID IMAGE COMMAND CREATED ...
e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago
```
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md b/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md
index 847d76f25c..4fadbb3f42 100644
--- a/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md
+++ b/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md
@@ -2,26 +2,27 @@
reviewers:
- cdrage
title: Translate a Docker Compose File to Kubernetes Resources
-content_template: templates/task
+content_type: task
weight: 200
---
-{{% capture overview %}}
+
What's Kompose? It's a conversion tool for all things compose (namely Docker Compose) to container orchestrators (Kubernetes or OpenShift).
More information can be found on the Kompose website at [http://kompose.io](http://kompose.io).
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Install Kompose
@@ -200,9 +201,9 @@ you need is an existing `docker-compose.yml` file.
$ curl http://192.0.2.89
```
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## User Guide
@@ -606,4 +607,4 @@ Kompose supports Docker Compose versions: 1, 2 and 3. We have limited support on
A full list on compatibility between all three versions is listed in our [conversion document](https://github.com/kubernetes/kompose/blob/master/docs/conversion.md) including a list of all incompatible Docker Compose keys.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/_index.md b/content/en/docs/tasks/debug-application-cluster/_index.md
index edce58d23a..0aa5f76478 100755
--- a/content/en/docs/tasks/debug-application-cluster/_index.md
+++ b/content/en/docs/tasks/debug-application-cluster/_index.md
@@ -1,5 +1,6 @@
---
title: "Monitoring, Logging, and Debugging"
+description: Set up monitoring and logging to troubleshoot a cluster, or debug a containerized application.
weight: 80
---
diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md
index 8e7497bdb8..600af51d00 100644
--- a/content/en/docs/tasks/debug-application-cluster/audit.md
+++ b/content/en/docs/tasks/debug-application-cluster/audit.md
@@ -3,11 +3,11 @@ reviewers:
- soltysh
- sttts
- ericchiang
-content_template: templates/concept
+content_type: concept
title: Auditing
---
-{{% capture overview %}}
+
Kubernetes auditing provides a security-relevant chronological set of records documenting
the sequence of activities that have affected system by individual users, administrators
@@ -22,10 +22,10 @@ answer the following questions:
- from where was it initiated?
- to where was it going?
-{{% /capture %}}
-{{% capture body %}}
+
+
[Kube-apiserver][kube-apiserver] performs auditing. Each request on each stage
of its execution generates an event, which is then pre-processed according to
@@ -119,6 +119,7 @@ request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`.
}
]
```
+
{{< /note >}}
### Log backend
@@ -234,7 +235,7 @@ spec:
url: "https://audit.app"
```
-For the complete API definition, see [AuditSink](/docs/reference/generated/kubernetes-api/v1.13/#auditsink-v1alpha1-auditregistration). Multiple objects will exist as independent solutions.
+For the complete API definition, see [AuditSink](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#auditsink-v1alpha1-auditregistration). Multiple objects will exist as independent solutions.
The name of an AuditSink object must be a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
@@ -244,7 +245,7 @@ Existing static backends that you configure with runtime flags are not affected
The AuditSink policy differs from the legacy audit runtime policy. This is because the API object serves different use cases. The policy will continue to evolve to serve more use cases.
-The `level` field applies the given audit level to all requests. The `stages` field is now a whitelist of stages to record.
+The `level` field applies the given audit level to all requests. The `stages` field is now a list of allowed stages to record.
#### Contacting the webhook
@@ -339,12 +340,12 @@ audit policies.
[Fluentd][fluentd] is an open source data collector for unified logging layer.
In this example, we will use fluentd to split audit events by different namespaces.
-1. install [fluentd][fluentd_install_doc], fluent-plugin-forest and fluent-plugin-rewrite-tag-filter in the kube-apiserver node
-{{< note >}}
-Fluent-plugin-forest and fluent-plugin-rewrite-tag-filter are plugins for fluentd. You can get details about plugin installation from [fluentd plugin-management][fluentd_plugin_management_doc].
+{{< note >}}Fluent-plugin-forest and fluent-plugin-rewrite-tag-filter are plugins for fluentd. You can get details about plugin installation from [fluentd plugin-management][fluentd_plugin_management_doc].
{{< /note >}}
-1. create a config file for fluentd
+1. Install [fluentd][fluentd_install_doc], fluent-plugin-forest and fluent-plugin-rewrite-tag-filter in the kube-apiserver node
+
+1. Create a config file for fluentd
```
cat <<'EOF' > /etc/fluentd/config
@@ -399,19 +400,19 @@ Fluent-plugin-forest and fluent-plugin-rewrite-tag-filter are plugins for fluent
EOF
```
-1. start fluentd
+1. Start fluentd
```shell
fluentd -c /etc/fluentd/config -vv
```
-1. start kube-apiserver with the following options:
+1. Start kube-apiserver with the following options:
```shell
--audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/kube-audit --audit-log-format=json
```
-1. check audits for different namespaces in `/var/log/audit-*.log`
+1. Check audits for different namespaces in `/var/log/audit-*.log`
### Use logstash to collect and distribute audit events from webhook backend
@@ -490,8 +491,7 @@ Note that in addition to file output plugin, logstash has a variety of outputs t
let users route data where they want. For example, users can emit audit events to elasticsearch
plugin which supports full-text search and analytics.
-
-[kube-apiserver]: /docs/admin/kube-apiserver
+[kube-apiserver]: /docs/reference/command-line-tools-reference/kube-apiserver/
[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md
[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go
[configure-helper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
@@ -503,12 +503,13 @@ plugin which supports full-text search and analytics.
[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html
[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Visit [Auditing with Falco](/docs/tasks/debug-application-cluster/falco).
Learn about [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/crictl.md b/content/en/docs/tasks/debug-application-cluster/crictl.md
index f7bfec87ff..a047f194e9 100644
--- a/content/en/docs/tasks/debug-application-cluster/crictl.md
+++ b/content/en/docs/tasks/debug-application-cluster/crictl.md
@@ -4,11 +4,11 @@ reviewers:
- feiskyer
- mrunalp
title: Debugging Kubernetes nodes with crictl
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.11" state="stable" >}}
@@ -17,15 +17,16 @@ You can use it to inspect and debug container runtimes and applications on a
Kubernetes node. `crictl` and its source are hosted in the
[cri-tools](https://github.com/kubernetes-incubator/cri-tools) repository.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
`crictl` requires a Linux operating system with a CRI runtime.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Installing crictl
@@ -347,12 +348,12 @@ CONTAINER ID IMAGE CREATED STATE
3e025dd50a72d busybox About a minute ago Running busybox 0
```
-{{% /capture %}}
-{{% capture discussion %}}
+
+
See [kubernetes-incubator/cri-tools](https://github.com/kubernetes-incubator/cri-tools)
for more information.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-application-introspection.md b/content/en/docs/tasks/debug-application-cluster/debug-application-introspection.md
index 2f5d6e7eda..730b9fb00c 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-application-introspection.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-application-introspection.md
@@ -2,20 +2,20 @@
reviewers:
- janetkuo
- thockin
-content_template: templates/concept
+content_type: concept
title: Application Introspection and Debugging
---
-{{% capture overview %}}
+
Once your application is running, you'll inevitably need to debug problems with it.
Earlier we described how you can use `kubectl get pods` to retrieve simple status information about
your pods. But there are a number of ways to get even more information about your application.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Using `kubectl describe pod` to fetch details about pods
@@ -387,17 +387,18 @@ status:
systemUUID: ABE5F6B4-D44B-108B-C46A-24CCE16C8B6E
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Learn about additional debugging tools, including:
* [Logging](/docs/concepts/cluster-administration/logging/)
* [Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
* [Getting into containers via `exec`](/docs/tasks/debug-application-cluster/get-shell-running-container/)
-* [Connecting to containers via proxies](/docs/tasks/access-kubernetes-api/http-proxy-access-api/)
+* [Connecting to containers via proxies](/docs/tasks/extend-kubernetes/http-proxy-access-api/)
* [Connecting to containers via port forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
* [Inspect Kubernetes node with crictl](/docs/tasks/debug-application-cluster/crictl/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-application.md b/content/en/docs/tasks/debug-application-cluster/debug-application.md
index 08f0fad008..a5c37541c3 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-application.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-application.md
@@ -3,19 +3,19 @@ reviewers:
- mikedanese
- thockin
title: Troubleshoot Applications
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
This guide is to help users debug applications that are deployed into Kubernetes and not behaving correctly.
This is *not* a guide for people who want to debug their cluster. For that you should check out
[this guide](/docs/admin/cluster-troubleshooting).
-{{% /capture %}}
-{{% capture body %}}
+
+
## Diagnosing the problem
@@ -161,12 +161,13 @@ check:
* Can you connect to your pods directly? Get the IP address for the Pod, and try to connect directly to that IP.
* Is your application serving on the port that you configured? Kubernetes doesn't do port remapping, so if your application serves on 8080, the `containerPort` field needs to be 8080.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
If none of the above solves your problem, follow the instructions in [Debugging Service document](/docs/user-guide/debugging-services) to make sure that your `Service` is running, has `Endpoints`, and your `Pods` are actually serving; you have DNS working, iptables rules installed, and kube-proxy does not seem to be misbehaving.
You may also visit [troubleshooting document](/docs/troubleshooting/) for more information.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-cluster.md b/content/en/docs/tasks/debug-application-cluster/debug-cluster.md
index 473f364361..0a66bed195 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-cluster.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-cluster.md
@@ -2,20 +2,20 @@
reviewers:
- davidopp
title: Troubleshoot Clusters
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
This doc is about cluster troubleshooting; we assume you have already ruled out your application as the root cause of the
problem you are experiencing. See
the [application troubleshooting guide](/docs/tasks/debug-application-cluster/debug-application) for tips on application debugging.
You may also visit [troubleshooting document](/docs/troubleshooting/) for more information.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Listing your cluster
@@ -124,4 +124,4 @@ This is an incomplete list of things that could go wrong, and how to adjust your
- Mitigates: Node shutdown
- Mitigates: Kubelet software fault
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-init-containers.md b/content/en/docs/tasks/debug-application-cluster/debug-init-containers.md
index 296f0a0648..a6a3a44d98 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-init-containers.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-init-containers.md
@@ -8,19 +8,20 @@ reviewers:
- kow3ns
- smarterclayton
title: Debug Init Containers
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page shows how to investigate problems related to the execution of
Init Containers. The example command lines below refer to the Pod as
`` and the Init Containers as `` and
``.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
@@ -28,9 +29,9 @@ Init Containers. The example command lines below refer to the Pod as
[Init Containers](/docs/concepts/abstractions/init-containers/).
* You should have [Configured an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/).
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Checking the status of Init Containers
@@ -113,9 +114,9 @@ Init Containers that run a shell script print
commands as they're executed. For example, you can do this in Bash by running
`set -x` at the beginning of the script.
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Understanding Pod status
@@ -131,7 +132,7 @@ Status | Meaning
`Pending` | The Pod has not yet begun executing Init Containers.
`PodInitializing` or `Running` | The Pod has already finished executing Init Containers.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
index 28c9885e57..9793b472e0 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
@@ -2,25 +2,26 @@
reviewers:
- bprashanth
title: Debug Pods and ReplicationControllers
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page shows how to debug Pods and ReplicationControllers.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* You should be familiar with the basics of
[Pods](/docs/concepts/workloads/pods/pod/) and [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/).
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Debugging Pods
@@ -106,4 +107,4 @@ or they can't. If they can't create pods, then please refer to the
You can also use `kubectl describe rc ${CONTROLLER_NAME}` to inspect events
related to the replication controller.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md b/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md
index a812640555..5e67585705 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md
@@ -3,16 +3,17 @@ reviewers:
- verb
- soltysh
title: Debug Running Pods
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page explains how to debug Pods running (or crashing) on a Node.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* Your {{< glossary_tooltip text="Pod" term_id="pod" >}} should already be
scheduled and running. If your Pod is not yet running, start with [Troubleshoot
@@ -21,9 +22,9 @@ This page explains how to debug Pods running (or crashing) on a Node.
Pod is running and have shell access to run commands on that Node. You don't
need that access to run the standard debug steps that use `kubectl`.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Examining pod logs {#examine-pod-logs}
@@ -187,4 +188,4 @@ given tools in the Kubernetes API. Therefore, if you find yourself needing to
ssh into a machine, please file a feature request on GitHub describing your use
case and why these tools are insufficient.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-service.md b/content/en/docs/tasks/debug-application-cluster/debug-service.md
index 23b210cb92..c4e12042fb 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-service.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-service.md
@@ -2,21 +2,21 @@
reviewers:
- thockin
- bowei
-content_template: templates/concept
+content_type: concept
title: Debug Services
---
-{{% capture overview %}}
+
An issue that comes up rather frequently for new installations of Kubernetes is
that a Service is not working properly. You've run your Pods through a
Deployment (or other workload controller) and created a Service, but you
get no response when you try to access it. This document will hopefully help
you to figure out what's going wrong.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Running commands in a Pod
@@ -61,8 +61,7 @@ kubectl scale deployment hostnames --replicas=3
deployment.apps/hostnames scaled
```
-{{< note >}}
-This is the same as if you had started the Deployment with the following
+Note that this is the same as if you had started the Deployment with the following
YAML:
```yaml
@@ -89,7 +88,6 @@ spec:
The label "app" is automatically set by `kubectl create deployment` to the name of the
Deployment.
-{{< /note >}}
You can confirm your Pods are running:
@@ -195,7 +193,6 @@ hostnames ClusterIP 10.0.1.175 80/TCP 5s
Now you know that the Service exists.
-{{< note >}}
As before, this is the same as if you had started the Service with YAML:
```yaml
@@ -218,7 +215,6 @@ spec:
In order to highlight the full range of configuration, the Service you created
here uses a different port number than the Pods. For many real-world
Services, these values might be the same.
-{{< /note >}}
## Does the Service work by DNS name?
@@ -732,10 +728,11 @@ Contact us on
[Forum](https://discuss.kubernetes.io) or
[GitHub](https://github.com/kubernetes/kubernetes).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Visit [troubleshooting document](/docs/troubleshooting/) for more information.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-stateful-set.md b/content/en/docs/tasks/debug-application-cluster/debug-stateful-set.md
index 8bf56bb10c..755c9b725e 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-stateful-set.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-stateful-set.md
@@ -8,23 +8,24 @@ reviewers:
- kow3ns
- smarterclayton
title: Debug a StatefulSet
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This task shows you how to debug a StatefulSet.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster.
* You should have a StatefulSet running that you want to investigate.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Debugging a StatefulSet
@@ -41,12 +42,13 @@ instructions on how to deal with them.
You can debug individual Pods in a StatefulSet using the
[Debugging Pods](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/) guide.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Learn more about [debugging an init-container](/docs/tasks/debug-application-cluster/debug-init-containers/).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
index 44b4225fdc..44dcf0e909 100644
--- a/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
+++ b/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
@@ -1,9 +1,9 @@
---
title: Determine the Reason for Pod Failure
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page shows how to write and read a Container
termination message.
@@ -16,17 +16,18 @@ put in a termination message should also be written to
the general
[Kubernetes logs](/docs/concepts/cluster-administration/logging/).
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Writing and reading a termination message
@@ -82,6 +83,11 @@ value of `/dev/termination-log`. By customizing this field, you can tell Kuberne
to use a different file. Kubernetes use the contents from the specified file to
populate the Container's status message on both success and failure.
+The termination message is intended to be brief final status, such as an assertion failure message.
+The kubelet truncates messages that are longer than 4096 bytes. The total message length across all
+containers will be limited to 12KiB. The default termination message path is `/dev/termination-log`.
+You cannot set the termination message path after a Pod is launched
+
In the following example, the container writes termination messages to
`/tmp/my-log` for Kubernetes to retrieve:
@@ -105,16 +111,17 @@ to use the last chunk of container log output if the termination message file
is empty and the container exited with an error. The log output is limited to
2048 bytes or 80 lines, whichever is smaller.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* See the `terminationMessagePath` field in
[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core).
* Learn about [retrieving logs](/docs/concepts/cluster-administration/logging/).
* Learn about [Go templates](https://golang.org/pkg/text/template/).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/events-stackdriver.md b/content/en/docs/tasks/debug-application-cluster/events-stackdriver.md
index d852ed3cf9..859c163307 100644
--- a/content/en/docs/tasks/debug-application-cluster/events-stackdriver.md
+++ b/content/en/docs/tasks/debug-application-cluster/events-stackdriver.md
@@ -2,11 +2,11 @@
reviewers:
- piosz
- x13n
-content_template: templates/concept
+content_type: concept
title: Events in Stackdriver
---
-{{% capture overview %}}
+
Kubernetes events are objects that provide insight into what is happening
inside a cluster, such as what decisions were made by scheduler or why some
@@ -34,10 +34,10 @@ of the potential inaccuracy.
{{< /note >}}
-{{% /capture %}}
-{{% capture body %}}
+
+
## Deployment
@@ -91,4 +91,4 @@ jsonPayload.involvedObject.name:"nginx-deployment"
{{< figure src="/images/docs/stackdriver-event-exporter-filter.png" alt="Filtered events in the Stackdriver Logging interface" width="500" >}}
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/falco.md b/content/en/docs/tasks/debug-application-cluster/falco.md
index 003b287602..2b6eb9323d 100644
--- a/content/en/docs/tasks/debug-application-cluster/falco.md
+++ b/content/en/docs/tasks/debug-application-cluster/falco.md
@@ -3,19 +3,19 @@ reviewers:
- soltysh
- sttts
- ericchiang
-content_template: templates/concept
+content_type: concept
title: Auditing with Falco
---
-{{% capture overview %}}
+
### Use Falco to collect audit events
[Falco](https://falco.org/) is an open source project for intrusion and abnormality detection for Cloud Native platforms.
This section describes how to set up Falco, how to send audit events to the Kubernetes Audit endpoint exposed by Falco, and how Falco applies a set of rules to automatically detect suspicious behavior.
-{{% /capture %}}
-{{% capture body %}}
+
+
#### Install Falco
@@ -116,6 +116,6 @@ For further details, see [Kubernetes Audit Events][falco_ka_docs] in the Falco d
[falco_k8s_audit_rules]: https://github.com/falcosecurity/falco/blob/master/rules/k8s_audit_rules.yaml
[falco_ka_docs]: https://falco.org/docs/event-sources/kubernetes-audit
[falco_installation]: https://falco.org/docs/installation
-[falco_helm_chart]: https://github.com/helm/charts/tree/master/stable/falco
+[falco_helm_chart]: https://github.com/falcosecurity/charts/tree/master/falco
+
-{{% /capture %}}
diff --git a/content/en/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/en/docs/tasks/debug-application-cluster/get-shell-running-container.md
index f3ff92c196..8535e9763c 100644
--- a/content/en/docs/tasks/debug-application-cluster/get-shell-running-container.md
+++ b/content/en/docs/tasks/debug-application-cluster/get-shell-running-container.md
@@ -3,29 +3,30 @@ reviewers:
- caesarxuchao
- mikedanese
title: Get a Shell to a Running Container
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This page shows how to use `kubectl exec` to get a shell to a
-running Container.
-
-{{% /capture %}}
+running container.
-{{% capture prerequisites %}}
-
-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-{{% /capture %}}
-{{% capture steps %}}
+## {{% heading "prerequisites" %}}
-## Getting a shell to a Container
-In this exercise, you create a Pod that has one Container. The Container
+{{< include "task-tutorial-prereqs.md" >}}
+
+
+
+
+
+
+## Getting a shell to a container
+
+In this exercise, you create a Pod that has one container. The container
runs the nginx image. Here is the configuration file for the Pod:
{{< codenew file="application/shell-demo.yaml" >}}
@@ -36,116 +37,121 @@ Create the Pod:
kubectl apply -f https://k8s.io/examples/application/shell-demo.yaml
```
-Verify that the Container is running:
+Verify that the container is running:
```shell
kubectl get pod shell-demo
```
-Get a shell to the running Container:
+Get a shell to the running container:
```shell
-kubectl exec -it shell-demo -- /bin/bash
+kubectl exec --stdin --tty shell-demo -- /bin/bash
```
+
{{< note >}}
-
-The double dash symbol "--" is used to separate the arguments you want to pass to the command from the kubectl arguments.
-
+The double dash (`--`) separates the arguments you want to pass to the command from the kubectl arguments.
{{< /note >}}
In your shell, list the root directory:
```shell
-root@shell-demo:/# ls /
+# Run this inside the container
+ls /
```
In your shell, experiment with other commands. Here are
some examples:
```shell
-root@shell-demo:/# ls /
-root@shell-demo:/# cat /proc/mounts
-root@shell-demo:/# cat /proc/1/maps
-root@shell-demo:/# apt-get update
-root@shell-demo:/# apt-get install -y tcpdump
-root@shell-demo:/# tcpdump
-root@shell-demo:/# apt-get install -y lsof
-root@shell-demo:/# lsof
-root@shell-demo:/# apt-get install -y procps
-root@shell-demo:/# ps aux
-root@shell-demo:/# ps aux | grep nginx
+# You can run these example commands inside the container
+ls /
+cat /proc/mounts
+cat /proc/1/maps
+apt-get update
+apt-get install -y tcpdump
+tcpdump
+apt-get install -y lsof
+lsof
+apt-get install -y procps
+ps aux
+ps aux | grep nginx
```
## Writing the root page for nginx
Look again at the configuration file for your Pod. The Pod
-has an `emptyDir` volume, and the Container mounts the volume
+has an `emptyDir` volume, and the container mounts the volume
at `/usr/share/nginx/html`.
In your shell, create an `index.html` file in the `/usr/share/nginx/html`
directory:
```shell
-root@shell-demo:/# echo Hello shell demo > /usr/share/nginx/html/index.html
+# Run this inside the container
+echo 'Hello shell demo' > /usr/share/nginx/html/index.html
```
In your shell, send a GET request to the nginx server:
```shell
-root@shell-demo:/# apt-get update
-root@shell-demo:/# apt-get install curl
-root@shell-demo:/# curl localhost
+# Run this in the shell inside your container
+apt-get update
+apt-get install curl
+curl http://localhost/
```
The output shows the text that you wrote to the `index.html` file:
-```shell
+```
Hello shell demo
```
When you are finished with your shell, enter `exit`.
-## Running individual commands in a Container
+```shell
+exit # To quit the shell in the container
+```
+
+## Running individual commands in a container
In an ordinary command window, not your shell, list the environment
-variables in the running Container:
+variables in the running container:
```shell
kubectl exec shell-demo env
```
-Experiment running other commands. Here are some examples:
+Experiment with running other commands. Here are some examples:
```shell
-kubectl exec shell-demo ps aux
-kubectl exec shell-demo ls /
-kubectl exec shell-demo cat /proc/1/mounts
+kubectl exec shell-demo -- ps aux
+kubectl exec shell-demo -- ls /
+kubectl exec shell-demo -- cat /proc/1/mounts
```
-{{% /capture %}}
-{{% capture discussion %}}
-## Opening a shell when a Pod has more than one Container
+
-If a Pod has more than one Container, use `--container` or `-c` to
-specify a Container in the `kubectl exec` command. For example,
+## Opening a shell when a Pod has more than one container
+
+If a Pod has more than one container, use `--container` or `-c` to
+specify a container in the `kubectl exec` command. For example,
suppose you have a Pod named my-pod, and the Pod has two containers
-named main-app and helper-app. The following command would open a
-shell to the main-app Container.
+named _main-app_ and _helper-app_. The following command would open a
+shell to the _main-app_ container.
```shell
-kubectl exec -it my-pod --container main-app -- /bin/bash
+kubectl exec -i -t my-pod --container main-app -- /bin/bash
```
-{{% /capture %}}
+{{< note >}}
+The short options `-i` and `-t` are the same as the long options `--stdin` and `--tty`
+{{< /note >}}
-{{% capture whatsnext %}}
-
-* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)
-
-{{% /capture %}}
-
+## {{% heading "whatsnext" %}}
+* Read about [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)
diff --git a/content/en/docs/tasks/debug-application-cluster/local-debugging.md b/content/en/docs/tasks/debug-application-cluster/local-debugging.md
index 9cfc216ee4..d00c1398eb 100644
--- a/content/en/docs/tasks/debug-application-cluster/local-debugging.md
+++ b/content/en/docs/tasks/debug-application-cluster/local-debugging.md
@@ -1,9 +1,9 @@
---
title: Developing and debugging services locally
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
Kubernetes applications usually consist of multiple, separate services, each running in its own container. Developing and debugging these services on a remote Kubernetes cluster can be cumbersome, requiring you to [get a shell on a running container](/docs/tasks/debug-application-cluster/get-shell-running-container/) and running your tools inside the remote shell.
@@ -12,17 +12,18 @@ Kubernetes applications usually consist of multiple, separate services, each run
This document describes using `telepresence` to develop and debug services running on a remote cluster locally.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* Kubernetes cluster is installed
* `kubectl` is configured to communicate with the cluster
* [Telepresence](https://www.telepresence.io/reference/install) is installed
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Getting a shell on a remote cluster
@@ -46,9 +47,10 @@ where $DEPLOYMENT_NAME is the name of your existing deployment.
Running this command spawns a shell. In the shell, start your service. You can then make edits to the source code locally, save, and see the changes take effect immediately. You can also run your service in a debugger, or any other local development tool.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
If you're interested in a hands-on tutorial, check out [this tutorial](https://cloud.google.com/community/tutorials/developing-services-with-k8s) that walks through locally developing the Guestbook application on Google Kubernetes Engine.
@@ -56,4 +58,4 @@ Telepresence has [numerous proxying options](https://www.telepresence.io/referen
For further reading, visit the [Telepresence website](https://www.telepresence.io).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md b/content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
index 327bfdf925..c47b117391 100644
--- a/content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
+++ b/content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
@@ -2,11 +2,11 @@
reviewers:
- piosz
- x13n
-content_template: templates/concept
+content_type: concept
title: Logging Using Elasticsearch and Kibana
---
-{{% capture overview %}}
+
On the Google Compute Engine (GCE) platform, the default logging support targets
[Stackdriver Logging](https://cloud.google.com/logging/), which is described in detail
@@ -21,9 +21,9 @@ Stackdriver Logging when running on GCE.
You cannot automatically deploy Elasticsearch and Kibana in the Kubernetes cluster hosted on Google Kubernetes Engine. You have to deploy them manually.
{{< /note >}}
-{{% /capture %}}
-{{% capture body %}}
+
+
To use Elasticsearch and Kibana for cluster logging, you should set the
following environment variable as shown below when creating your cluster with
@@ -114,11 +114,12 @@ Here is a typical view of ingested logs from the Kibana viewer:
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Kibana opens up all sorts of powerful options for exploring your logs! For some
ideas on how to dig into it, check out [Kibana's documentation](https://www.elastic.co/guide/en/kibana/current/discover.html).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md b/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md
index a60ceeedfb..be80133d34 100644
--- a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md
+++ b/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md
@@ -3,10 +3,10 @@ reviewers:
- piosz
- x13n
title: Logging Using Stackdriver
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
Before reading this page, it's highly recommended to familiarize yourself
with the [overview of logging in Kubernetes](/docs/concepts/cluster-administration/logging).
@@ -18,10 +18,10 @@ see the [sidecar approach](/docs/concepts/cluster-administration/logging#sidecar
in the Kubernetes logging overview.
{{< /note >}}
-{{% /capture %}}
-{{% capture body %}}
+
+
## Deploying
@@ -368,4 +368,4 @@ with minor changes:
Then run `make build push` from this directory. After updating `DaemonSet` to pick up the
new image, you can use the plugin you installed in the fluentd configuration.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/monitor-node-health.md b/content/en/docs/tasks/debug-application-cluster/monitor-node-health.md
index f434adb17e..9ebeeeddad 100644
--- a/content/en/docs/tasks/debug-application-cluster/monitor-node-health.md
+++ b/content/en/docs/tasks/debug-application-cluster/monitor-node-health.md
@@ -2,11 +2,11 @@
reviewers:
- Random-Liu
- dchen1107
-content_template: templates/task
+content_type: task
title: Monitor Node Health
---
-{{% capture overview %}}
+
*Node problem detector* is a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) monitoring the
node health. It collects node problems from various daemons and reports them
@@ -23,15 +23,16 @@ introduced to deal with node problems.
See more information
[here](https://github.com/kubernetes/node-problem-detector).
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Limitations
@@ -162,9 +163,9 @@ Kernel monitor uses [`Translator`](https://github.com/kubernetes/node-problem-de
plugin to translate kernel log the internal data structure. It is easy to
implement a new translator for a new log format.
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Caveats
@@ -177,4 +178,4 @@ resource overhead on each node. Usually this is fine, because:
* Even under high load, the resource usage is acceptable.
(see [benchmark result](https://github.com/kubernetes/node-problem-detector/issues/2#issuecomment-220255629))
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
index 547790e5b0..dbd4aa6cf4 100644
--- a/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
+++ b/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
@@ -3,20 +3,20 @@ reviewers:
- fgrzadkowski
- piosz
title: Resource metrics pipeline
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
Resource usage metrics, such as container CPU and memory usage,
are available in Kubernetes through the Metrics API. These metrics can be either accessed directly
by user, for example by using `kubectl top` command, or used by a controller in the cluster, e.g.
Horizontal Pod Autoscaler, to make decisions.
-{{% /capture %}}
-{{% capture body %}}
+
+
## The Metrics API
@@ -61,4 +61,4 @@ Metrics Server is registered with the main API server through
Learn more about the metrics server in [the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
index de8c538118..6cb716da9c 100644
--- a/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+++ b/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
@@ -1,11 +1,11 @@
---
reviewers:
- mikedanese
-content_template: templates/concept
+content_type: concept
title: Tools for Monitoring Resources
---
-{{% capture overview %}}
+
To scale an application and provide a reliable service, you need to
understand how the application behaves when it is deployed. You can examine
@@ -16,9 +16,9 @@ information about an application's resource usage at each of these levels.
This information allows you to evaluate your application's performance and
where bottlenecks can be removed to improve overall performance.
-{{% /capture %}}
-{{% capture body %}}
+
+
In Kubernetes, application monitoring does not depend on a single monitoring solution. On new clusters, you can use [resource metrics](#resource-metrics-pipeline) or [full metrics](#full-metrics-pipeline) pipelines to collect monitoring statistics.
@@ -55,4 +55,4 @@ then exposes them to Kubernetes via an adapter by implementing either the
[Prometheus](https://prometheus.io), a CNCF project, can natively monitor Kubernetes, nodes, and Prometheus itself.
Full metrics pipeline projects that are not part of the CNCF are outside the scope of Kubernetes documentation.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/debug-application-cluster/troubleshooting.md b/content/en/docs/tasks/debug-application-cluster/troubleshooting.md
index 1ed0f5aa5b..82301275ce 100644
--- a/content/en/docs/tasks/debug-application-cluster/troubleshooting.md
+++ b/content/en/docs/tasks/debug-application-cluster/troubleshooting.md
@@ -2,11 +2,11 @@
reviewers:
- brendandburns
- davidopp
-content_template: templates/concept
+content_type: concept
title: Troubleshooting
---
-{{% capture overview %}}
+
Sometimes things go wrong. This guide is aimed at making them right. It has
two sections:
@@ -17,10 +17,10 @@ two sections:
You should also check the known issues for the [release](https://github.com/kubernetes/kubernetes/releases)
you're using.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Getting help
@@ -104,4 +104,4 @@ problem, such as:
* Cloud provider, OS distro, network configuration, and Docker version
* Steps to reproduce the problem
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/example-task-template.md b/content/en/docs/tasks/example-task-template.md
index c723460fc0..90d14e98da 100644
--- a/content/en/docs/tasks/example-task-template.md
+++ b/content/en/docs/tasks/example-task-template.md
@@ -2,11 +2,11 @@
title: Example Task Template
reviewers:
- chenopis
-content_template: templates/task
+content_type: task
toc_hide: true
---
-{{% capture overview %}}
+
{{< note >}}
Be sure to also [create an entry in the table of contents](/docs/contribute/style/write-new-topic/#placing-your-topic-in-the-table-of-contents) for your new document.
@@ -14,39 +14,39 @@ Be sure to also [create an entry in the table of contents](/docs/contribute/styl
This page shows how to ...
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* Do this.
* Do this too.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Doing ...
1. Do this.
1. Do this next. Possibly read this [related explanation](#).
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Understanding ...
**[Optional Section]**
Here's an interesting thing to know about the steps you just did.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
**[Optional Section]**
* Learn more about [Writing a New Topic](/docs/home/contribute/write-new-topic/).
-* See [Using Page Templates - Task template](/docs/home/contribute/page-templates/#task_template) for how to use this template.
-
-{{% /capture %}}
\ No newline at end of file
+* Learn about [Page Content Types - Task](/docs/home/contribute/style/page-content-types/#task).
diff --git a/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md
index dcc315871b..6052bff9af 100644
--- a/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md
+++ b/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md
@@ -3,24 +3,25 @@ title: Extend kubectl with plugins
reviewers:
- juanvallejo
- soltysh
-description: With kubectl plugins, you can extend the functionality of the kubectl command by adding new subcommands.
-content_template: templates/task
+description: Extend kubectl by creating and installing kubectl plugins.
+content_type: task
---
-{{% capture overview %}}
+
This guide demonstrates how to install and write extensions for [kubectl](/docs/reference/kubectl/kubectl/). By thinking of core `kubectl` commands as essential building blocks for interacting with a Kubernetes cluster, a cluster administrator can think
of plugins as a means of utilizing these building blocks to create more complex behavior. Plugins extend `kubectl` with new sub-commands, allowing for new and custom features not included in the main distribution of `kubectl`.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
You need to have a working `kubectl` binary installed.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Installing kubectl plugins
@@ -375,9 +376,10 @@ set up a build environment (if it needs compiling), and deploy the plugin.
If you also make compiled packages available, or use Krew, that will make
installs easier.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Check the Sample CLI Plugin repository for a
[detailed example](https://github.com/kubernetes/sample-cli-plugin) of a
@@ -386,4 +388,4 @@ installs easier.
[SIG CLI team](https://github.com/kubernetes/community/tree/master/sig-cli).
* Read about [Krew](https://krew.dev/), a package manager for kubectl plugins.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/extend-kubernetes/_index.md b/content/en/docs/tasks/extend-kubernetes/_index.md
new file mode 100644
index 0000000000..7109fddde0
--- /dev/null
+++ b/content/en/docs/tasks/extend-kubernetes/_index.md
@@ -0,0 +1,6 @@
+---
+title: "Extend Kubernetes"
+description: Understand advanced ways to adapt your Kubernetes cluster to the needs of your work environment.
+weight: 90
+---
+
diff --git a/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md b/content/en/docs/tasks/extend-kubernetes/configure-aggregation-layer.md
similarity index 95%
rename from content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md
rename to content/en/docs/tasks/extend-kubernetes/configure-aggregation-layer.md
index 9a77378d5c..739a69d45a 100644
--- a/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md
+++ b/content/en/docs/tasks/extend-kubernetes/configure-aggregation-layer.md
@@ -4,31 +4,27 @@ reviewers:
- lavalamp
- cheftako
- chenopis
-content_template: templates/task
+content_type: task
weight: 10
---
-{{% capture overview %}}
+
-Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
+Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
-{{% /capture %}}
-
-{{% capture prerequisites %}}
+## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{< note >}}
-There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA.
+There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA.
+{{< /note >}}
{{< caution >}}
Reusing the same CA for different client types can negatively impact the cluster's ability to function. For more information, see [CA Reusage and Conflicts](#ca-reusage-and-conflicts).
{{< /caution >}}
-{{< /note >}}
-{{% /capture %}}
-
-{{% capture steps %}}
+
## Authentication Flow
@@ -137,7 +133,10 @@ The Kubernetes apiserver connects to the extension apiserver over TLS, authentic
The Kubernetes apiserver will use the files indicated by `--proxy-client-*-file` to authenticate to the extension apiserver. In order for the request to be considered valid by a compliant extension apiserver, the following conditions must be met:
1. The connection must be made using a client certificate that is signed by the CA whose certificate is in `--requestheader-client-ca-file`.
-2. The connection must be made using a client certificate whose CN is one of those listed in `--requestheader-allowed-names`. **Note:** You can set this option to blank as `--requestheader-allowed-names=""`. This will indicate to an extension apiserver that _any_ CN is acceptable.
+2. The connection must be made using a client certificate whose CN is one of those listed in `--requestheader-allowed-names`.
+
+{{< note >}}You can set this option to blank as `--requestheader-allowed-names=""`. This will indicate to an extension apiserver that _any_ CN is acceptable.
+{{< /note >}}
When started with these options, the Kubernetes apiserver will:
@@ -222,7 +221,7 @@ If you are not running kube-proxy on a host running the API server, then you mus
--enable-aggregator-routing=true
-{{% /capture %}}
+
### Register APIService objects
@@ -275,11 +274,8 @@ spec:
...
```
-{{% capture whatsnext %}}
-
-* [Setup an extension api-server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) to work with the aggregation layer.
-* For a high level overview, see [Extending the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/).
-* Learn how to [Extend the Kubernetes API Using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/).
-
-{{% /capture %}}
+## {{% heading "whatsnext" %}}
+* [Setup an extension api-server](/docs/tasks/extend-kubernetes/setup-extension-api-server/) to work with the aggregation layer.
+* For a high level overview, see [Extending the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
+* Learn how to [Extend the Kubernetes API Using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
diff --git a/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
similarity index 97%
rename from content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md
rename to content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
index 436584ad14..4afbee21c8 100644
--- a/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md
+++ b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
@@ -3,10 +3,11 @@ reviewers:
- davidopp
- madhusudancs
title: Configure Multiple Schedulers
-content_template: templates/task
+content_type: task
+weight: 20
---
-{{% capture overview %}}
+
Kubernetes ships with a default scheduler that is described [here](/docs/admin/kube-scheduler/).
If the default scheduler does not suit your needs you can implement your own scheduler.
@@ -19,16 +20,17 @@ document. Please refer to the kube-scheduler implementation in
[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler)
in the Kubernetes source directory for a canonical example.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Package the scheduler
@@ -219,9 +221,9 @@ kubectl create -f pod3.yaml
kubectl get pods
```
-{{% /capture %}}
-{{% capture discussion %}}
+
+
### Verifying that the pods were scheduled using the desired schedulers
@@ -241,4 +243,4 @@ verify that the pods were scheduled by the desired schedulers.
kubectl get events
```
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/_index.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/_index.md
similarity index 100%
rename from content/en/docs/tasks/access-kubernetes-api/custom-resources/_index.md
rename to content/en/docs/tasks/extend-kubernetes/custom-resources/_index.md
diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md
similarity index 99%
rename from content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md
rename to content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md
index ec35dd88e8..6eaf0cdd3a 100644
--- a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md
+++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md
@@ -3,19 +3,20 @@ title: Versions in CustomResourceDefinitions
reviewers:
- sttts
- liggitt
-content_template: templates/task
+content_type: task
weight: 30
min-kubernetes-server-version: v1.16
---
-{{% capture overview %}}
+
This page explains how to add versioning information to
[CustomResourceDefinitions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions), to indicate the stability
level of your CustomResourceDefinitions or advance your API to a new version with conversion between API representations. It also describes how to upgrade an object from one version to another.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}}
@@ -23,9 +24,9 @@ You should have a initial understanding of [custom resources](/docs/concepts/api
{{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Overview
@@ -961,4 +962,4 @@ The following is an example procedure to upgrade from `v1beta1` to `v1`.
storage version, which is `v1`.
2. Remove `v1beta1` from the CustomResourceDefinition `status.storedVersions` field.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md
similarity index 95%
rename from content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md
rename to content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md
index 4fcd389ba2..78b55b58dc 100644
--- a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md
+++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md
@@ -6,18 +6,19 @@ reviewers:
- liggitt
- roycaihw
- sttts
-content_template: templates/task
+content_type: task
weight: 20
---
-{{% capture overview %}}
+
This page shows how to install a
[custom resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
into the Kubernetes API by creating a
[CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions).
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
@@ -25,9 +26,9 @@ into the Kubernetes API by creating a
* Read about [custom resources](/docs/concepts/api-extension/custom-resources/).
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create a CustomResourceDefinition
@@ -250,11 +251,11 @@ If you later recreate the same CustomResourceDefinition, it will start out empty
{{< feature-state state="stable" for_k8s_version="v1.16" >}}
-CustomResources traditionally store arbitrary JSON (next to `apiVersion`, `kind` and `metadata`, which is validated by the API server implicitly). With [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) a schema can be specified, which is validated during creation and updates, compare below for details and limits of such a schema.
+CustomResources traditionally store arbitrary JSON (next to `apiVersion`, `kind` and `metadata`, which is validated by the API server implicitly). With [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) a schema can be specified, which is validated during creation and updates, compare below for details and limits of such a schema.
With `apiextensions.k8s.io/v1` the definition of a structural schema is mandatory for CustomResourceDefinitions, while in `v1beta1` this is still optional.
-A structural schema is an [OpenAPI v3.0 validation schema](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) which:
+A structural schema is an [OpenAPI v3.0 validation schema](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) which:
1. specifies a non-empty type (via `type` in OpenAPI) for the root, for each specified field of an object node (via `properties` or `additionalProperties` in OpenAPI) and for each item in an array node (via `items` in OpenAPI), with the exception of:
* a node with `x-kubernetes-int-or-string: true`
@@ -363,15 +364,15 @@ Violations of the structural schema rules are reported in the `NonStructural` co
Structural schemas are a requirement for `apiextensions.k8s.io/v1`, and disables the following features for `apiextensions.k8s.io/v1beta1`:
-* [Validation Schema Publishing](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#publish-validation-schema-in-openapi-v2)
-* [Webhook Conversion](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/#webhook-conversion)
+* [Validation Schema Publishing](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#publish-validation-schema-in-openapi-v2)
+* [Webhook Conversion](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#webhook-conversion)
* [Pruning](#preserving-unknown-fields)
### Pruning versus preserving unknown fields {#preserving-unknown-fields}
{{< feature-state state="stable" for_k8s_version="v1.16" >}}
-CustomResourceDefinitions traditionally store any (possibly validated) JSON as is in etcd. This means that unspecified fields (if there is a [OpenAPI v3.0 validation schema](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) at all) are persisted. This is in contrast to native Kubernetes resources such as a pod where unknown fields are dropped before being persisted to etcd. We call this "pruning" of unknown fields.
+CustomResourceDefinitions traditionally store any (possibly validated) JSON as is in etcd. This means that unspecified fields (if there is a [OpenAPI v3.0 validation schema](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) at all) are persisted. This is in contrast to native Kubernetes resources such as a pod where unknown fields are dropped before being persisted to etcd. We call this "pruning" of unknown fields.
{{< tabs name="CustomResourceDefinition_pruning" >}}
{{% tab name="apiextensions.k8s.io/v1" %}}
@@ -426,7 +427,7 @@ spec:
The field `someRandomField` has been pruned.
-Note that the `kubectl create` call uses `--validate=false` to skip client-side validation. Because the [OpenAPI validation schemas are also published](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#publish-validation-schema-in-openapi-v2) to kubectl, it will also check for unknown fields and reject those objects long before they are sent to the API server.
+Note that the `kubectl create` call uses `--validate=false` to skip client-side validation. Because the [OpenAPI validation schemas are also published](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#publish-validation-schema-in-openapi-v2) to kubectl, it will also check for unknown fields and reject those objects long before they are sent to the API server.
### Controlling pruning
@@ -532,7 +533,7 @@ allOf:
With one of those specification, both an integer and a string validate.
-In [Validation Schema Publishing](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#publish-validation-schema-in-openapi-v2), `x-kubernetes-int-or-string: true` is unfolded to one of the two patterns shown above.
+In [Validation Schema Publishing](/docs/tasks/extend-kubernetes/custom-resources/extend-api-custom-resource-definitions/#publish-validation-schema-in-openapi-v2), `x-kubernetes-int-or-string: true` is unfolded to one of the two patterns shown above.
### RawExtension
@@ -564,13 +565,13 @@ With `x-kubernetes-embedded-resource: true`, the `apiVersion`, `kind` and `metad
## Serving multiple versions of a CRD
-See [Custom resource definition versioning](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/)
+See [Custom resource definition versioning](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/)
for more information about serving multiple versions of your
CustomResourceDefinition and migrating your objects from one version to another.
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Advanced topics
### Finalizers
@@ -633,7 +634,7 @@ Additionally, the following restrictions are applied to the schema:
These fields can only be set with specific features enabled:
-- `default`: can be set for `apiextensions.k8s.io/v1` CustomResourceDefinitions. Defaulting is in GA since 1.17 (beta since 1.16 with the `CustomResourceDefaulting` feature gate to be enabled, which is the case automatically for many clusters for beta features). Compare [Validation Schema Defaulting](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting).
+- `default`: can be set for `apiextensions.k8s.io/v1` CustomResourceDefinitions. Defaulting is in GA since 1.17 (beta since 1.16 with the `CustomResourceDefaulting` feature gate to be enabled, which is the case automatically for many clusters for beta features). Compare [Validation Schema Defaulting](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting).
{{< note >}}
Compare with [structural schemas](#specifying-a-structural-schema) for further restriction required for certain CustomResourceDefinition features.
@@ -1448,13 +1449,13 @@ NAME AGE
crontabs/my-new-cron-object 3s
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* See [CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1-apiextensions-k8s-io).
-* Serve [multiple versions](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/) of a
+* Serve [multiple versions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/) of a
CustomResourceDefinition.
-{{% /capture %}}
\ No newline at end of file
diff --git a/content/en/docs/tasks/access-kubernetes-api/http-proxy-access-api.md b/content/en/docs/tasks/extend-kubernetes/http-proxy-access-api.md
similarity index 90%
rename from content/en/docs/tasks/access-kubernetes-api/http-proxy-access-api.md
rename to content/en/docs/tasks/extend-kubernetes/http-proxy-access-api.md
index be282a29c1..dd80c8c349 100644
--- a/content/en/docs/tasks/access-kubernetes-api/http-proxy-access-api.md
+++ b/content/en/docs/tasks/extend-kubernetes/http-proxy-access-api.md
@@ -1,14 +1,15 @@
---
title: Use an HTTP Proxy to Access the Kubernetes API
-content_template: templates/task
+content_type: task
weight: 40
---
-{{% capture overview %}}
+
This page shows how to use an HTTP proxy to access the Kubernetes API.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
@@ -19,9 +20,7 @@ a Hello world application by entering this command:
kubectl run node-hello --image=gcr.io/google-samples/node-hello:1.0 --port=8080
```
-{{% /capture %}}
-
-{{% capture steps %}}
+
## Using kubectl to start a proxy server
@@ -81,10 +80,6 @@ The output should look similar to this:
...
}
-{{% /capture %}}
+## {{% heading "whatsnext" %}}
-{{% capture whatsnext %}}
Learn more about [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands#proxy).
-{{% /capture %}}
-
-
diff --git a/content/en/docs/tasks/access-kubernetes-api/setup-extension-api-server.md b/content/en/docs/tasks/extend-kubernetes/setup-extension-api-server.md
similarity index 70%
rename from content/en/docs/tasks/access-kubernetes-api/setup-extension-api-server.md
rename to content/en/docs/tasks/extend-kubernetes/setup-extension-api-server.md
index 71c6059eec..626ddcab5c 100644
--- a/content/en/docs/tasks/access-kubernetes-api/setup-extension-api-server.md
+++ b/content/en/docs/tasks/extend-kubernetes/setup-extension-api-server.md
@@ -1,34 +1,35 @@
---
-title: Setup an Extension API Server
+title: Set up an Extension API Server
reviewers:
- lavalamp
- cheftako
- chenopis
-content_template: templates/task
+content_type: task
weight: 15
---
-{{% capture overview %}}
+
-Setting up an extension API server to work the aggregation layer allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
+Setting up an extension API server to work with the aggregation layer allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-* You must [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) and enable the apiserver flags.
+* You must [configure the aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) and enable the apiserver flags.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Setup an extension api-server to work with the aggregation layer
The following steps describe how to set up an extension-apiserver *at a high level*. These steps apply regardless if you're using YAML configs or using APIs. An attempt is made to specifically identify any differences between the two. For a concrete example of how they can be implemented using YAML configs, you can look at the [sample-apiserver](https://github.com/kubernetes/sample-apiserver/blob/master/README.md) in the Kubernetes repo.
-Alternatively, you can use an existing 3rd party solution, such as [apiserver-builder](https://github.com/Kubernetes-incubator/apiserver-builder/blob/master/README.md), which should generate a skeleton and automate all of the following steps for you.
+Alternatively, you can use an existing 3rd party solution, such as [apiserver-builder](https://github.com/kubernetes-sigs/apiserver-builder-alpha/blob/master/README.md), which should generate a skeleton and automate all of the following steps for you.
1. Make sure the APIService API is enabled (check `--runtime-config`). It should be on by default, unless it's been deliberately turned off in your cluster.
1. You may need to make an RBAC rule allowing you to add APIService objects, or get your cluster administrator to make one. (Since API extensions affect the entire cluster, it is not recommended to do testing/development/debug of an API extension in a live cluster.)
@@ -44,17 +45,13 @@ Alternatively, you can use an existing 3rd party solution, such as [apiserver-bu
1. Create a Kubernetes cluster role binding from the service account in your namespace to the `system:auth-delegator` cluster role to delegate auth decisions to the Kubernetes core API server.
1. Create a Kubernetes role binding from the service account in your namespace to the `extension-apiserver-authentication-reader` role. This allows your extension api-server to access the `extension-apiserver-authentication` configmap.
1. Create a Kubernetes apiservice. The CA cert above should be base64 encoded, stripped of new lines and used as the spec.caBundle in the apiservice. This should not be namespaced. If using the [kube-aggregator API](https://github.com/kubernetes/kube-aggregator/), only pass in the PEM encoded CA bundle because the base 64 encoding is done for you.
-1. Use kubectl to get your resource. It should return "No resources found." Which means that everything worked but you currently have no objects of that resource type created yet.
-
-{{% /capture %}}
-
-{{% capture whatsnext %}}
-
-* If you haven't already, [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) and enable the apiserver flags.
-* For a high level overview, see [Extending the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation).
-* Learn how to [Extend the Kubernetes API Using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/).
-
-{{% /capture %}}
+1. Use kubectl to get your resource. When run, kubectl should return "No resources found.". This message
+indicates that everything worked but you currently have no objects of that resource type created.
+## {{% heading "whatsnext" %}}
+
+* Walk through the steps to [configure the API aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) and enable the apiserver flags.
+* For a high level overview, see [Extending the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
+* Learn how to [Extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
diff --git a/content/en/docs/tasks/setup-konnectivity/setup-konnectivity.md b/content/en/docs/tasks/extend-kubernetes/setup-konnectivity.md
similarity index 61%
rename from content/en/docs/tasks/setup-konnectivity/setup-konnectivity.md
rename to content/en/docs/tasks/extend-kubernetes/setup-konnectivity.md
index b5dbd05215..da9dabb135 100644
--- a/content/en/docs/tasks/setup-konnectivity/setup-konnectivity.md
+++ b/content/en/docs/tasks/extend-kubernetes/setup-konnectivity.md
@@ -1,40 +1,39 @@
---
title: Set up Konnectivity service
-content_template: templates/task
+content_type: task
weight: 70
---
-{{% capture overview %}}
+
-The Konnectivity service provides TCP level proxy for the Master → Cluster
+The Konnectivity service provides a TCP level proxy for the control plane to cluster
communication.
-{{% /capture %}}
-
-{{% capture prerequisites %}}
+## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
-{{% /capture %}}
-
-{{% capture steps %}}
+
## Configure the Konnectivity service
-First, you need to configure the API Server to use the Konnectivity service
-to direct its network traffic to cluster nodes:
-
-1. Set the `--egress-selector-config-file` flag of the API Server, it is the
-path to the API Server egress configuration file.
-1. At the path, create a configuration file. For example,
+The following steps require an egress configuration, for example:
{{< codenew file="admin/konnectivity/egress-selector-configuration.yaml" >}}
+You need to configure the API Server to use the Konnectivity service
+and direct the network traffic to the cluster nodes:
+
+1. Create an egress configuration file such as `admin/konnectivity/egress-selector-configuration.yaml`.
+1. Set the `--egress-selector-config-file` flag of the API Server to the path of
+your API Server egress configuration file.
+
Next, you need to deploy the Konnectivity server and agents.
[kubernetes-sigs/apiserver-network-proxy](https://github.com/kubernetes-sigs/apiserver-network-proxy)
is a reference implementation.
-Deploy the Konnectivity server on your master node. The provided yaml assumes
+Deploy the Konnectivity server on your control plane node. The provided
+`konnectivity-server.yaml` manifest assumes
that the Kubernetes components are deployed as a {{< glossary_tooltip text="static Pod"
term_id="static-pod" >}} in your cluster. If not, you can deploy the Konnectivity
server as a DaemonSet.
@@ -48,5 +47,3 @@ Then deploy the Konnectivity agents in your cluster:
Last, if RBAC is enabled in your cluster, create the relevant RBAC rules:
{{< codenew file="admin/konnectivity/konnectivity-rbac.yaml" >}}
-
-{{% /capture %}}
\ No newline at end of file
diff --git a/content/en/docs/tasks/inject-data-application/_index.md b/content/en/docs/tasks/inject-data-application/_index.md
index f7f765f259..af98de866d 100755
--- a/content/en/docs/tasks/inject-data-application/_index.md
+++ b/content/en/docs/tasks/inject-data-application/_index.md
@@ -1,5 +1,6 @@
---
title: "Inject Data Into Applications"
+description: Specify configuration and other data for the Pods that run your workload.
weight: 30
---
diff --git a/content/en/docs/tasks/inject-data-application/define-command-argument-container.md b/content/en/docs/tasks/inject-data-application/define-command-argument-container.md
index 66ebd69c13..faaffc52a2 100644
--- a/content/en/docs/tasks/inject-data-application/define-command-argument-container.md
+++ b/content/en/docs/tasks/inject-data-application/define-command-argument-container.md
@@ -1,25 +1,26 @@
---
title: Define a Command and Arguments for a Container
-content_template: templates/task
+content_type: task
weight: 10
---
-{{% capture overview %}}
+
This page shows how to define commands and arguments when you run a container
in a {{< glossary_tooltip term_id="pod" >}}.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Define a command and arguments when you create a Pod
@@ -145,14 +146,15 @@ Here are some examples:
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | `[zoo boo]` | `[ep-2 zoo boo]` |
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [configuring pods and containers](/docs/tasks/).
* Learn more about [running commands in a container](/docs/tasks/debug-application-cluster/get-shell-running-container/).
* See [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md
index d10bbd323f..d75d930c56 100644
--- a/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md
+++ b/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md
@@ -1,25 +1,26 @@
---
title: Define Environment Variables for a Container
-content_template: templates/task
+content_type: task
weight: 20
---
-{{% capture overview %}}
+
This page shows how to define environment variables for a container
in a Kubernetes Pod.
-{{% /capture %}}
-{{% capture prerequisites %}}
-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-{{% /capture %}}
+## {{% heading "prerequisites" %}}
-{{% capture steps %}}
+{{< include "task-tutorial-prereqs.md" >}}
+
+
+
+
+
## Define an environment variable for a container
@@ -29,12 +30,12 @@ that run in the Pod. To set environment variables, include the `env` or
In this exercise, you create a Pod that runs one container. The configuration
file for the Pod defines an environment variable with name `DEMO_GREETING` and
-value `"Hello from the environment"`. Here is the configuration file for the
+value `"Hello from the environment"`. Here is the configuration manifest for the
Pod:
{{< codenew file="pods/inject/envars.yaml" >}}
-1. Create a Pod based on the YAML configuration file:
+1. Create a Pod based on that manifest:
```shell
kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml
@@ -46,7 +47,7 @@ Pod:
kubectl get pods -l purpose=demonstrate-envars
```
- The output is similar to this:
+ The output is similar to:
```
NAME READY STATUS RESTARTS AGE
@@ -62,7 +63,8 @@ Pod:
1. In your shell, run the `printenv` command to list the environment variables.
```shell
- root@envar-demo:/# printenv
+ # Run this in the shell inside the container
+ printenv
```
The output is similar to this:
@@ -80,12 +82,24 @@ Pod:
{{< note >}}
The environment variables set using the `env` or `envFrom` field
-will override any environment variables specified in the container image.
+override any environment variables specified in the container image.
+{{< /note >}}
+
+{{< note >}}
+The environment variables can reference each other, and cycles are possible,
+pay attention to the order before using
{{< /note >}}
## Using environment variables inside of your config
-Environment variables that you define in a Pod's configuration can be used elsewhere in the configuration, for example in commands and arguments that you set for the Pod's containers. In the example configuration below, the `GREETING`, `HONORIFIC`, and `NAME` environment variables are set to `Warm greetings to`, `The Most Honorable`, and `Kubernetes`, respectively. Those environment variables are then used in the CLI arguments passed to the `env-print-demo` container.
+Environment variables that you define in a Pod's configuration can be used
+elsewhere in the configuration, for example in commands and arguments that
+you set for the Pod's containers.
+In the example configuration below, the `GREETING`, `HONORIFIC`, and
+`NAME` environment variables are set to `Warm greetings to`, `The Most
+Honorable`, and `Kubernetes`, respectively. Those environment variables
+are then used in the CLI arguments passed to the `env-print-demo`
+container.
```yaml
apiVersion: v1
@@ -109,12 +123,13 @@ spec:
Upon creation, the command `echo Warm greetings to The Most Honorable Kubernetes` is run on the container.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
* Learn about [using secrets as environment variables](/docs/user-guide/secrets/#using-secrets-as-environment-variables).
* See [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md
index 2fb15aa3b2..40e74d36b1 100644
--- a/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md
+++ b/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md
@@ -1,24 +1,21 @@
---
title: Distribute Credentials Securely Using Secrets
-content_template: templates/task
+content_type: task
weight: 50
min-kubernetes-server-version: v1.6
---
-{{% capture overview %}}
+
This page shows how to securely inject sensitive data, such as passwords and
encryption keys, into Pods.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}}
-{{% /capture %}}
-
-{{% capture steps %}}
-
-## Convert your secret data to a base-64 representation
+### Convert your secret data to a base-64 representation
Suppose you want to have two pieces of secret data: a username `my-app` and a password
`39528$vdg7Jb`. First, use a base64 encoding tool to convert your username and password to a base64 representation. Here's an example using the commonly available base64 program:
@@ -35,6 +32,8 @@ and the base-64 representation of your password is `Mzk1MjgkdmRnN0pi`.
Use a local tool trusted by your OS to decrease the security risks of external tools.
{{< /caution >}}
+
+
## Create a Secret
Here is a configuration file you can use to create a Secret that holds your
@@ -83,15 +82,19 @@ username and password:
username: 7 bytes
```
-{{< note >}}
-If you want to skip the Base64 encoding step, you can create a Secret
-by using the `kubectl create secret` command:
-{{< /note >}}
+### Create a Secret directly with kubectl
+
+If you want to skip the Base64 encoding step, you can create the
+same Secret using the `kubectl create secret` command. For example:
```shell
-kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'
+kubectl create secret generic test-secret --from-literal='username=my-app' --from-literal='password=39528$vdg7Jb'
```
+This is more convenient. The detailed approach shown earlier runs
+through each step explicitly to demonstrate what is happening.
+
+
## Create a Pod that has access to the secret data through a Volume
Here is a configuration file you can use to create a Pod:
@@ -100,52 +103,51 @@ Here is a configuration file you can use to create a Pod:
1. Create the Pod:
- ```shell
- kubectl apply -f https://k8s.io/examples/pods/inject/secret-pod.yaml
- ```
+ ```shell
+ kubectl apply -f https://k8s.io/examples/pods/inject/secret-pod.yaml
+ ```
1. Verify that your Pod is running:
- ```shell
- kubectl get pod secret-test-pod
- ```
+ ```shell
+ kubectl get pod secret-test-pod
+ ```
- Output:
- ```shell
- NAME READY STATUS RESTARTS AGE
- secret-test-pod 1/1 Running 0 42m
- ```
+ Output:
+ ```
+ NAME READY STATUS RESTARTS AGE
+ secret-test-pod 1/1 Running 0 42m
+ ```
1. Get a shell into the Container that is running in your Pod:
- ```shell
- kubectl exec -it secret-test-pod -- /bin/bash
- ```
+ ```shell
+ kubectl exec -i -t secret-test-pod -- /bin/bash
+ ```
1. The secret data is exposed to the Container through a Volume mounted under
-`/etc/secret-volume`. In your shell, go to the directory where the secret data
-is exposed:
- ```shell
- root@secret-test-pod:/# cd /etc/secret-volume
- ```
+`/etc/secret-volume`.
-1. In your shell, list the files in the `/etc/secret-volume` directory:
- ```shell
- root@secret-test-pod:/etc/secret-volume# ls
- ```
- The output shows two files, one for each piece of secret data:
- ```shell
- password username
- ```
+ In your shell, list the files in the `/etc/secret-volume` directory:
+ ```shell
+ # Run this in the shell inside the container
+ ls /etc/secret-volume
+ ```
+ The output shows two files, one for each piece of secret data:
+ ```
+ password username
+ ```
1. In your shell, display the contents of the `username` and `password` files:
- ```shell
- root@secret-test-pod:/etc/secret-volume# cat username; echo; cat password; echo
- ```
- The output is your username and password:
- ```shell
- my-app
- 39528$vdg7Jb
- ```
+ ```shell
+ # Run this in the shell inside the container
+ echo "$( cat /etc/secret-volume/username )"
+ echo "$( cat /etc/secret-volume/password )"
+ ```
+ The output is your username and password:
+ ```
+ my-app
+ 39528$vdg7Jb
+ ```
## Define container environment variables using Secret data
@@ -170,13 +172,13 @@ is exposed:
* In your shell, display the content of `SECRET_USERNAME` container environment variable
```shell
- kubectl exec -it env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME'
+ kubectl exec -i -t env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME'
```
The output is
- ```shell
- backend-admin
- ```
+ ```
+ backend-admin
+ ```
### Define container environment variables with data from multiple Secrets
@@ -200,10 +202,10 @@ is exposed:
* In your shell, display the container environment variables
```shell
- kubectl exec -it envvars-multiple-secrets -- /bin/sh -c 'env | grep _USERNAME'
+ kubectl exec -i -t envvars-multiple-secrets -- /bin/sh -c 'env | grep _USERNAME'
```
The output is
- ```shell
+ ```
DB_USERNAME=db-admin
BACKEND_USERNAME=backend-admin
```
@@ -233,28 +235,23 @@ This functionality is available in Kubernetes v1.6 and later.
* In your shell, display `username` and `password` container environment variables
- ````shell
- kubectl exec -it envfrom-secret -- /bin/sh -c 'echo "username: $username\npassword: $password"'
- ````
+ ```shell
+ kubectl exec -i -t envfrom-secret -- /bin/sh -c 'echo "username: $username\npassword: $password\n"'
+ ```
The output is
- ````shell
+ ```
username: my-app
password: 39528$vdg7Jb
- ````
+ ```
-{{% /capture %}}
-
-{{% capture whatsnext %}}
-
-* Learn more about [Secrets](/docs/concepts/configuration/secret/).
-* Learn about [Volumes](/docs/concepts/storage/volumes/).
-
-### Reference
+### References
* [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
* [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
* [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
-{{% /capture %}}
+## {{% heading "whatsnext" %}}
+* Learn more about [Secrets](/docs/concepts/configuration/secret/).
+* Learn about [Volumes](/docs/concepts/storage/volumes/).
diff --git a/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
index a24aba65b6..4ab41f2a23 100644
--- a/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
+++ b/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
@@ -1,25 +1,26 @@
---
title: Expose Pod Information to Containers Through Files
-content_template: templates/task
+content_type: task
weight: 40
---
-{{% capture overview %}}
+
This page shows how a Pod can use a DownwardAPIVolumeFile to expose information
about itself to Containers running in the Pod. A DownwardAPIVolumeFile can expose
Pod fields and Container fields.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## The Downward API
@@ -189,9 +190,9 @@ In your shell, view the `cpu_limit` file:
You can use similar commands to view the `cpu_request`, `mem_limit` and
`mem_request` files.
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Capabilities of the Downward API
@@ -249,10 +250,11 @@ application, but that is tedious and error prone, and it violates the goal of lo
coupling. A better option would be to use the Pod's name as an identifier, and
inject the Pod's name into the well-known environment variable.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
* [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
@@ -260,7 +262,7 @@ inject the Pod's name into the well-known environment variable.
* [DownwardAPIVolumeFile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)
* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/en/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
index c23b3ba75a..2b59921c6e 100644
--- a/content/en/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
+++ b/content/en/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
@@ -1,26 +1,27 @@
---
title: Expose Pod Information to Containers Through Environment Variables
-content_template: templates/task
+content_type: task
weight: 30
---
-{{% capture overview %}}
+
This page shows how a Pod can use environment variables to expose information
about itself to Containers running in the Pod. Environment variables can expose
Pod fields and Container fields.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## The Downward API
@@ -154,9 +155,10 @@ The output shows the values of selected environment variables:
67108864
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [Defining Environment Variables for a Container](/docs/tasks/inject-data-application/define-environment-variable-container/)
* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
@@ -166,5 +168,5 @@ The output shows the values of selected environment variables:
* [ObjectFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectfieldselector-v1-core)
* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/inject-data-application/podpreset.md b/content/en/docs/tasks/inject-data-application/podpreset.md
index dcf159acf5..6533629ce4 100644
--- a/content/en/docs/tasks/inject-data-application/podpreset.md
+++ b/content/en/docs/tasks/inject-data-application/podpreset.md
@@ -3,26 +3,27 @@ reviewers:
- jessfraz
title: Inject Information into Pods Using a PodPreset
min-kubernetes-server-version: v1.6
-content_template: templates/task
+content_type: task
weight: 60
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
This page shows how to use PodPreset objects to inject information like {{< glossary_tooltip text="Secrets" term_id="secret" >}}, volume mounts, and {{< glossary_tooltip text="environment variables" term_id="container-env-variables" >}} into Pods at creation time.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one using [Minikube](/docs/setup/learning-environment/minikube/).
Make sure that you have [enabled PodPreset](/docs/concepts/workloads/pods/podpreset/#enable-pod-preset) in your cluster.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Use Pod presets to inject environment variables and volumes
@@ -321,4 +322,4 @@ The output shows that the PodPreset was deleted:
podpreset "allow-database" deleted
```
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/job/_index.md b/content/en/docs/tasks/job/_index.md
index 1948d33fc5..9e41e241c1 100644
--- a/content/en/docs/tasks/job/_index.md
+++ b/content/en/docs/tasks/job/_index.md
@@ -1,5 +1,6 @@
---
title: "Run Jobs"
+description: Run Jobs using parallel processing.
weight: 50
---
diff --git a/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md
index ae5b6633ad..e5f0d3a6b7 100644
--- a/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md
+++ b/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md
@@ -3,11 +3,11 @@ title: Running Automated Tasks with a CronJob
min-kubernetes-server-version: v1.8
reviewers:
- chenopis
-content_template: templates/task
+content_type: task
weight: 10
---
-{{% capture overview %}}
+
You can use a {{< glossary_tooltip text="CronJob" term_id="cronjob" >}} to run {{< glossary_tooltip text="Jobs" term_id="job" >}} on a time-based schedule.
These automated jobs run like [Cron](https://en.wikipedia.org/wiki/Cron) tasks on a Linux or UNIX system.
@@ -21,15 +21,16 @@ Therefore, jobs should be idempotent.
For more limitations, see [CronJobs](/docs/concepts/workloads/controllers/cron-jobs).
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* {{< include "task-tutorial-prereqs.md" >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Creating a Cron Job
@@ -157,8 +158,8 @@ A question mark (`?`) in the schedule has the same meaning as an asterisk `*`, t
### Job Template
The `.spec.jobTemplate` is the template for the job, and it is required.
-It has exactly the same schema as a [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/), except that it is nested and does not have an `apiVersion` or `kind`.
-For information about writing a job `.spec`, see [Writing a Job Spec](/docs/concepts/workloads/controllers/jobs-run-to-completion/#writing-a-job-spec).
+It has exactly the same schema as a [Job](/docs/concepts/workloads/controllers/job/), except that it is nested and does not have an `apiVersion` or `kind`.
+For information about writing a job `.spec`, see [Writing a Job Spec](/docs/concepts/workloads/controllers/job/#writing-a-job-spec).
### Starting Deadline
@@ -207,4 +208,4 @@ The `.spec.successfulJobsHistoryLimit` and `.spec.failedJobsHistoryLimit` fields
These fields specify how many completed and failed jobs should be kept.
By default, they are set to 3 and 1 respectively. Setting a limit to `0` corresponds to keeping none of the corresponding kind of jobs after they finish.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md b/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md
index 707c5b9850..346fbdda8d 100644
--- a/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md
+++ b/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md
@@ -1,12 +1,12 @@
---
title: Coarse Parallel Processing Using a Work Queue
min-kubernetes-server-version: v1.8
-content_template: templates/task
+content_type: task
weight: 30
---
-{{% capture overview %}}
+
In this example, we will run a Kubernetes Job with multiple parallel
worker processes.
@@ -23,19 +23,20 @@ Here is an overview of the steps in this example:
1. **Start a Job that works on tasks from the queue**. The Job starts several pods. Each pod takes
one task from the message queue, processes it, and repeats until the end of the queue is reached.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
Be familiar with the basic,
non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).
{{< include "task-tutorial-prereqs.md" >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Starting a message queue service
@@ -292,9 +293,9 @@ Events:
All our pods succeeded. Yay.
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Alternatives
@@ -331,4 +332,4 @@ exits with success, or if the node crashes before the kubelet is able to post th
back to the api-server, then the Job will not appear to be complete, even though all items
in the queue have been processed.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md b/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md
index 26fbbacaa7..f502113c8f 100644
--- a/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md
+++ b/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md
@@ -1,11 +1,11 @@
---
title: Fine Parallel Processing Using a Work Queue
-content_template: templates/task
+content_type: task
min-kubernetes-server-version: v1.8
weight: 40
---
-{{% capture overview %}}
+
In this example, we will run a Kubernetes Job with multiple parallel
worker processes in a given pod.
@@ -25,23 +25,24 @@ Here is an overview of the steps in this example:
1. **Start a Job that works on tasks from the queue**. The Job starts several pods. Each pod takes
one task from the message queue, processes it, and repeats until the end of the queue is reached.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
Be familiar with the basic,
non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Starting Redis
@@ -226,9 +227,9 @@ Working on lemon
As you can see, one of our pods worked on several work units.
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Alternatives
@@ -240,4 +241,4 @@ consider running your background workers with a `ReplicaSet` instead,
and consider running a background processing library such as
[https://github.com/resque/resque](https://github.com/resque/resque).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/job/parallel-processing-expansion.md b/content/en/docs/tasks/job/parallel-processing-expansion.md
index e2d0975a70..3477be2650 100644
--- a/content/en/docs/tasks/job/parallel-processing-expansion.md
+++ b/content/en/docs/tasks/job/parallel-processing-expansion.md
@@ -1,11 +1,11 @@
---
title: Parallel Processing using Expansions
-content_template: templates/task
+content_type: task
min-kubernetes-server-version: v1.8
weight: 20
---
-{{% capture overview %}}
+
This task demonstrates running multiple {{< glossary_tooltip text="Jobs" term_id="job" >}}
based on a common template. You can use this approach to process batches of work in
@@ -16,9 +16,10 @@ The sample Jobs process each item simply by printing a string then pausing.
See [using Jobs in real workloads](#using-jobs-in-real-workloads) to learn about how
this pattern fits more realistic use cases.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
You should be familiar with the basic,
non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).
@@ -35,10 +36,10 @@ Once you have Python set up, you can install Jinja2 by running:
```shell
pip install --user jinja2
```
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Create Jobs based on a template
@@ -252,8 +253,8 @@ Kubernetes accepts and runs the Jobs you created.
kubectl delete job -l jobgroup=jobexample
```
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Using Jobs in real workloads
@@ -310,4 +311,4 @@ objects.
You could also consider writing your own [controller](/docs/concepts/architecture/controller/)
to manage Job objects automatically.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/manage-daemon/_index.md b/content/en/docs/tasks/manage-daemon/_index.md
index 1cdbf06368..2b63e873ba 100755
--- a/content/en/docs/tasks/manage-daemon/_index.md
+++ b/content/en/docs/tasks/manage-daemon/_index.md
@@ -1,5 +1,6 @@
---
title: "Manage Cluster Daemons"
+description: Perform common tasks for managing a DaemonSet, such as performing a rolling update.
weight: 130
---
diff --git a/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md b/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md
index 4b1d424066..05e8060cc9 100644
--- a/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md
+++ b/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md
@@ -2,30 +2,26 @@
reviewers:
- janetkuo
title: Perform a Rollback on a DaemonSet
-content_template: templates/task
+content_type: task
weight: 20
+min-kubernetes-server-version: 1.7
---
-{{% capture overview %}}
+
-This page shows how to perform a rollback on a DaemonSet.
-
-{{% /capture %}}
+This page shows how to perform a rollback on a {{< glossary_tooltip term_id="daemonset" >}}.
-{{% capture prerequisites %}}
+## {{% heading "prerequisites" %}}
-* The DaemonSet rollout history and DaemonSet rollback features are only
- supported in `kubectl` in Kubernetes version 1.7 or later.
-* Make sure you know how to [perform a rolling update on a
- DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/).
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
+You should already know how to [perform a rolling update on a
+ DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/).
+
-{{% capture steps %}}
-
-## Performing a Rollback on a DaemonSet
+## Performing a rollback on a DaemonSet
### Step 1: Find the DaemonSet revision you want to roll back to
@@ -39,7 +35,7 @@ kubectl rollout history daemonset
This returns a list of DaemonSet revisions:
-```shell
+```
daemonsets ""
REVISION CHANGE-CAUSE
1 ...
@@ -59,17 +55,17 @@ kubectl rollout history daemonset --revision=1
This returns the details of that revision:
-```shell
+```
daemonsets "" with revision #1
Pod Template:
Labels: foo=bar
Containers:
app:
- Image: ...
- Port: ...
- Environment: ...
- Mounts: ...
-Volumes: ...
+ Image: ...
+ Port: ...
+ Environment: ...
+ Mounts: ...
+Volumes: ...
```
### Step 2: Roll back to a specific revision
@@ -81,40 +77,39 @@ kubectl rollout undo daemonset --to-revision=
If it succeeds, the command returns:
-```shell
+```
daemonset "" rolled back
```
-If `--to-revision` flag is not specified, the last revision will be picked.
+{{< note >}}
+If `--to-revision` flag is not specified, kubectl picks the most recent revision.
+{{< /note >}}
### Step 3: Watch the progress of the DaemonSet rollback
`kubectl rollout undo daemonset` tells the server to start rolling back the
-DaemonSet. The real rollback is done asynchronously on the server side.
+DaemonSet. The real rollback is done asynchronously inside the cluster
+{{< glossary_tooltip term_id="control-plane" text="control plane" >}}.
To watch the progress of the rollback:
-```shell
-kubectl rollout status ds/
+```shell
+kubectl rollout status ds/
```
-When the rollback is complete, the output is similar to this:
+When the rollback is complete, the output is similar to:
-```shell
+```
daemonset "" successfully rolled out
```
-{{% /capture %}}
+
-{{% capture discussion %}}
-
-## Understanding DaemonSet Revisions
+## Understanding DaemonSet revisions
In the previous `kubectl rollout history` step, you got a list of DaemonSet
-revisions. Each revision is stored in a resource named `ControllerRevision`.
-`ControllerRevision` is a resource only available in Kubernetes release 1.7 or
-later.
+revisions. Each revision is stored in a resource named ControllerRevision.
To see what is stored in each revision, find the DaemonSet revision raw
resources:
@@ -123,20 +118,19 @@ resources:
kubectl get controllerrevision -l =
```
-This returns a list of `ControllerRevisions`:
+This returns a list of ControllerRevisions:
-```shell
+```
NAME CONTROLLER REVISION AGE
- DaemonSet/ 1 1h
- DaemonSet/ 2 1h
```
-Each `ControllerRevision` stores the annotations and template of a DaemonSet
-revision. The name of a ControllerRevision object must be a valid
-[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+Each ControllerRevision stores the annotations and template of a DaemonSet
+revision.
-`kubectl rollout undo` takes a specific `ControllerRevision` and replaces
-DaemonSet template with the template stored in the `ControllerRevision`.
+`kubectl rollout undo` takes a specific ControllerRevision and replaces
+DaemonSet template with the template stored in the ControllerRevision.
`kubectl rollout undo` is equivalent to updating DaemonSet template to a
previous revision through other commands, such as `kubectl edit` or `kubectl
apply`.
@@ -144,16 +138,12 @@ apply`.
{{< note >}}
DaemonSet revisions only roll forward. That is to say, after a
rollback completes, the revision number (`.revision` field) of the
-`ControllerRevision` being rolled back to will advance. For example, if you
+ControllerRevision being rolled back to will advance. For example, if you
have revision 1 and 2 in the system, and roll back from revision 2 to revision
-1, the `ControllerRevision` with `.revision: 1` will become `.revision: 3`.
+1, the ControllerRevision with `.revision: 1` will become `.revision: 3`.
{{< /note >}}
## Troubleshooting
* See [troubleshooting DaemonSet rolling
update](/docs/tasks/manage-daemon/update-daemon-set/#troubleshooting).
-
-{{% /capture %}}
-
-
diff --git a/content/en/docs/tasks/manage-daemon/update-daemon-set.md b/content/en/docs/tasks/manage-daemon/update-daemon-set.md
index 8e32763e01..b9168ed098 100644
--- a/content/en/docs/tasks/manage-daemon/update-daemon-set.md
+++ b/content/en/docs/tasks/manage-daemon/update-daemon-set.md
@@ -2,25 +2,26 @@
reviewers:
- janetkuo
title: Perform a Rolling Update on a DaemonSet
-content_template: templates/task
+content_type: task
weight: 10
---
-{{% capture overview %}}
+
This page shows how to perform a rolling update on a DaemonSet.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* The DaemonSet rolling update feature is only supported in Kubernetes version 1.6 or later.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## DaemonSet Update Strategy
@@ -190,13 +191,14 @@ Delete DaemonSet from a namespace :
kubectl delete ds fluentd-elasticsearch -n kube-system
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* See [Task: Performing a rollback on a
DaemonSet](/docs/tasks/manage-daemon/rollback-daemon-set/)
* See [Concepts: Creating a DaemonSet to adopt existing DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/manage-gpus/scheduling-gpus.md b/content/en/docs/tasks/manage-gpus/scheduling-gpus.md
index 4c0b9f9bc3..4f8fc434f9 100644
--- a/content/en/docs/tasks/manage-gpus/scheduling-gpus.md
+++ b/content/en/docs/tasks/manage-gpus/scheduling-gpus.md
@@ -1,11 +1,12 @@
---
reviewers:
- vishh
-content_template: templates/concept
+content_type: concept
title: Schedule GPUs
+description: Configure and schedule GPUs for use as a resource by nodes in a cluster.
---
-{{% capture overview %}}
+
{{< feature-state state="beta" for_k8s_version="v1.10" >}}
@@ -15,10 +16,10 @@ Kubernetes includes **experimental** support for managing AMD and NVIDIA GPUs
This page describes how users can consume GPUs across different Kubernetes versions
and the current limitations.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Using device plugins
@@ -98,7 +99,7 @@ has the following requirements:
- Kubelet must use Docker as its container runtime
- `nvidia-container-runtime` must be configured as the [default runtime](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)
for Docker, instead of runc.
-- The version of the NVIDIA drivers must match the constraint ~= 361.93
+- The version of the NVIDIA drivers must match the constraint ~= 384.81.
To deploy the NVIDIA device plugin once your cluster is running and the above
requirements are satisfied:
@@ -216,4 +217,4 @@ spec:
This will ensure that the Pod will be scheduled to a node that has the GPU type
you specified.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/en/docs/tasks/manage-hugepages/scheduling-hugepages.md
index ad6b969c87..a349f123aa 100644
--- a/content/en/docs/tasks/manage-hugepages/scheduling-hugepages.md
+++ b/content/en/docs/tasks/manage-hugepages/scheduling-hugepages.md
@@ -2,19 +2,18 @@
reviewers:
- derekwaynecarr
title: Manage HugePages
-content_template: templates/task
+content_type: task
+description: Configure and manage huge pages as a schedulable resource in a cluster.
---
-{{% capture overview %}}
+
{{< feature-state state="stable" >}}
Kubernetes supports the allocation and consumption of pre-allocated huge pages
-by applications in a Pod as a **GA** feature. This page describes how users
-can consume huge pages and the current limitations.
+by applications in a Pod. This page describes how users can consume huge pages.
-{{% /capture %}}
+## {{% heading "prerequisites" %}}
-{{% capture prerequisites %}}
1. Kubernetes nodes must pre-allocate huge pages in order for the node to report
its huge page capacity. A node can pre-allocate huge pages for multiple
@@ -23,9 +22,9 @@ can consume huge pages and the current limitations.
The nodes will automatically discover and report all huge page resources as
schedulable resources.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## API
@@ -119,11 +118,3 @@ gate](/docs/reference/command-line-tools-reference/feature-gates/) on the {{<
glossary_tooltip text="kubelet" term_id="kubelet" >}} and {{<
glossary_tooltip text="kube-apiserver"
term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`).
-
-## Future
-
-- NUMA locality guarantees as a feature of quality of service.
-- LimitRange support.
-
-{{% /capture %}}
-
diff --git a/content/en/docs/tasks/manage-kubernetes-objects/_index.md b/content/en/docs/tasks/manage-kubernetes-objects/_index.md
index b7bbecf75d..541ca58c0c 100644
--- a/content/en/docs/tasks/manage-kubernetes-objects/_index.md
+++ b/content/en/docs/tasks/manage-kubernetes-objects/_index.md
@@ -1,4 +1,5 @@
---
title: "Manage Kubernetes Objects"
+description: Declarative and imperative paradigms for interacting with the Kubernetes API.
weight: 25
---
\ No newline at end of file
diff --git a/content/en/docs/tasks/manage-kubernetes-objects/declarative-config.md b/content/en/docs/tasks/manage-kubernetes-objects/declarative-config.md
index f82e54d364..308a4cf9b8 100644
--- a/content/en/docs/tasks/manage-kubernetes-objects/declarative-config.md
+++ b/content/en/docs/tasks/manage-kubernetes-objects/declarative-config.md
@@ -1,27 +1,28 @@
---
title: Declarative Management of Kubernetes Objects Using Configuration Files
-content_template: templates/task
+content_type: task
weight: 10
---
-{{% capture overview %}}
+
Kubernetes objects can be created, updated, and deleted by storing multiple
object configuration files in a directory and using `kubectl apply` to
recursively create and update those objects as needed. This method
retains writes made to live objects without merging the changes
back into the object configuration files. `kubectl diff` also gives you a
preview of what changes `apply` will make.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Trade-offs
@@ -999,11 +1000,12 @@ template:
controller-selector: "apps/v1/deployment/nginx"
```
-{{% capture whatsnext %}}
+## {{% heading "whatsnext" %}}
+
* [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
* [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/imperative-config/)
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md b/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md
index 6b1357a133..dd8b6b0f53 100644
--- a/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md
+++ b/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md
@@ -1,23 +1,24 @@
---
title: Managing Kubernetes Objects Using Imperative Commands
-content_template: templates/task
+content_type: task
weight: 30
---
-{{% capture overview %}}
+
Kubernetes objects can quickly be created, updated, and deleted directly using
imperative commands built into the `kubectl` command-line tool. This document
explains how those commands are organized and how to use them to manage live objects.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Trade-offs
@@ -159,13 +160,14 @@ kubectl create --edit -f /tmp/srv.yaml
1. The `kubectl create service` command creates the configuration for the Service and saves it to `/tmp/srv.yaml`.
1. The `kubectl create --edit` command opens the configuration file for editing before it creates the object.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tasks/manage-kubernetes-objects/imperative-config/)
* [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/)
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md b/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md
index ec6057cd68..97b62e6f0f 100644
--- a/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md
+++ b/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md
@@ -1,24 +1,25 @@
---
title: Imperative Management of Kubernetes Objects Using Configuration Files
-content_template: templates/task
+content_type: task
weight: 40
---
-{{% capture overview %}}
+
Kubernetes objects can be created, updated, and deleted by using the `kubectl`
command-line tool along with an object configuration file written in YAML or JSON.
This document explains how to define and manage objects using configuration files.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Trade-offs
@@ -142,13 +143,14 @@ template:
controller-selector: "apps/v1/deployment/nginx"
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
* [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/)
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md
index c74374a0dc..a7d887da3b 100644
--- a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md
+++ b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md
@@ -1,10 +1,10 @@
---
title: Declarative Management of Kubernetes Objects Using Kustomize
-content_template: templates/task
+content_type: task
weight: 20
---
-{{% capture overview %}}
+
[Kustomize](https://github.com/kubernetes-sigs/kustomize) is a standalone tool
to customize Kubernetes objects
@@ -24,17 +24,18 @@ To apply those Resources, run `kubectl apply` with `--kustomize` or `-k` flag:
kubectl apply -k
```
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Overview of Kustomize
@@ -824,13 +825,14 @@ deployment.apps "dev-my-nginx" deleted
| configurations | []string | Each entry in this list should resolve to a file containing [Kustomize transformer configurations](https://github.com/kubernetes-sigs/kustomize/tree/master/examples/transformerconfigs) |
| crds | []string | Each entry in this list should resolve to an OpenAPI definition file for Kubernetes types |
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [Kustomize](https://github.com/kubernetes-sigs/kustomize)
* [Kubectl Book](https://kubectl.docs.kubernetes.io)
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/run-application/update-api-object-kubectl-patch.md b/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md
similarity index 69%
rename from content/en/docs/tasks/run-application/update-api-object-kubectl-patch.md
rename to content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md
index dcfc250df1..55d9128f20 100644
--- a/content/en/docs/tasks/run-application/update-api-object-kubectl-patch.md
+++ b/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md
@@ -1,25 +1,26 @@
---
title: Update API Objects in Place Using kubectl patch
description: Use kubectl patch to update Kubernetes API objects in place. Do a strategic merge patch or a JSON merge patch.
-content_template: templates/task
-weight: 40
+content_type: task
+weight: 50
---
-{{% capture overview %}}
+
This task shows how to use `kubectl patch` to update an API object in place. The exercises
in this task demonstrate a strategic merge patch and a JSON merge patch.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Use a strategic merge patch to update a Deployment
@@ -283,6 +284,119 @@ patch-demo-1307768864-69308 1/1 Running 0 1m
patch-demo-1307768864-c86dc 1/1 Running 0 1m
```
+## Use strategic merge patch to update a Deployment using the retainKeys strategy
+
+Here's the configuration file for a Deployment that uses the `RollingUpdate` strategy:
+
+{{< codenew file="application/deployment-retainkeys.yaml" >}}
+
+Create the deployment:
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/deployment-retainkeys.yaml
+```
+
+At this point, the deployment is created and is using the `RollingUpdate` strategy.
+
+Create a file named `patch-file-no-retainkeys.yaml` that has this content:
+
+```yaml
+spec:
+ strategy:
+ type: Recreate
+```
+
+Patch your Deployment:
+
+{{< tabs name="kubectl_retainkeys_example" >}}
+{{{< tab name="Bash" codelang="bash" >}}
+kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-no-retainkeys.yaml)"
+{{< /tab >}}
+{{< tab name="PowerShell" codelang="posh" >}}
+kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw)
+{{< /tab >}}}
+{{< /tabs >}}
+
+In the output, you can see that it is not possible to set `type` as `Recreate` when a value is defined for `spec.strategy.rollingUpdate`:
+
+```shell
+The Deployment "retainkeys-demo" is invalid: spec.strategy.rollingUpdate: Forbidden: may not be specified when strategy `type` is 'Recreate'
+```
+
+The way to remove the value for `spec.strategy.rollingUpdate` when updating the value for `type` is to use the `retainKeys` strategy for the strategic merge.
+
+Create another file named `patch-file-retainkeys.yaml` that has this content:
+
+```yaml
+spec:
+ strategy:
+ $retainKeys:
+ - type
+ type: Recreate
+```
+
+With this patch, we indicate that we want to retain only the `type` key of the `strategy` object. Thus, the `rollingUpdate` will be removed during the patch operation.
+
+Patch your Deployment again with this new patch:
+
+{{< tabs name="kubectl_retainkeys2_example" >}}
+{{{< tab name="Bash" codelang="bash" >}}
+kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-retainkeys.yaml)"
+{{< /tab >}}
+{{< tab name="PowerShell" codelang="posh" >}}
+kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-retainkeys.yaml -Raw)
+{{< /tab >}}}
+{{< /tabs >}}
+
+Examine the content of the Deployment:
+
+```shell
+kubectl get deployment retainkeys-demo --output yaml
+```
+
+The output shows that the strategy object in the Deployment does not contain the `rollingUpdate` key anymore:
+
+```shell
+spec:
+ strategy:
+ type: Recreate
+ template:
+```
+
+### Notes on the strategic merge patch using the retainKeys strategy
+
+The patch you did in the preceding exercise is called a *strategic merge patch with retainKeys strategy*. This method introduces a new directive `$retainKeys` that has the following strategies:
+
+- It contains a list of strings.
+- All fields needing to be preserved must be present in the `$retainKeys` list.
+- The fields that are present will be merged with live object.
+- All of the missing fields will be cleared when patching.
+- All fields in the `$retainKeys` list must be a superset or the same as the fields present in the patch.
+
+The `retainKeys` strategy does not work for all objects. It only works when the value of the `patchStrategy` key in a field tag in the Kubernetes source code contains `retainKeys`. For example, the `Strategy` field of the `DeploymentSpec` struct has a `patchStrategy` of `retainKeys`:
+
+```go
+type DeploymentSpec struct {
+ ...
+ // +patchStrategy=retainKeys
+ Strategy DeploymentStrategy `json:"strategy,omitempty" patchStrategy:"retainKeys" ...`
+```
+
+You can also see the `retainKeys` strategy in the [OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json):
+
+```json
+"io.k8s.api.apps.v1.DeploymentSpec": {
+ ...
+ "strategy": {
+ "$ref": "#/definitions/io.k8s.api.apps.v1.DeploymentStrategy",
+ "description": "The deployment strategy to use to replace existing pods with new ones.",
+ "x-kubernetes-patch-strategy": "retainKeys"
+ },
+```
+
+And you can see the `retainKeys` strategy in the
+[Kubernetes API documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
+
## Alternate forms of the kubectl patch command
The `kubectl patch` command takes YAML or JSON. It can take the patch as a file or
@@ -330,14 +444,15 @@ create the Deployment object. Other commands for updating API objects include
and
[kubectl apply](/docs/reference/generated/kubectl/kubectl-commands/#apply).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* [Kubernetes Object Management](/docs/concepts/overview/working-with-objects/object-management/)
* [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
* [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/imperative-config/)
* [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/declarative-config/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/network/_index.md b/content/en/docs/tasks/network/_index.md
index 86dbbc1284..0dad8191a0 100755
--- a/content/en/docs/tasks/network/_index.md
+++ b/content/en/docs/tasks/network/_index.md
@@ -1,5 +1,6 @@
---
-title: "Network"
+title: "Networking"
+description: Learn how to configure networking for your cluster.
weight: 160
---
diff --git a/content/en/docs/tasks/network/validate-dual-stack.md b/content/en/docs/tasks/network/validate-dual-stack.md
index 0e6d586bea..1e21af226d 100644
--- a/content/en/docs/tasks/network/validate-dual-stack.md
+++ b/content/en/docs/tasks/network/validate-dual-stack.md
@@ -4,14 +4,15 @@ reviewers:
- khenidak
min-kubernetes-server-version: v1.16
title: Validate IPv4/IPv6 dual-stack
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clusters.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces)
* A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack (such as Kubenet or Calico)
@@ -20,9 +21,9 @@ This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clu
{{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Validate addressing
@@ -158,4 +159,4 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S
my-service ClusterIP fe80:20d::d06b 2001:db8:f100:4002::9d37:c0d7 80:31868/TCP 30s
```
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/run-application/_index.md b/content/en/docs/tasks/run-application/_index.md
index c9d64ac3fe..920df4098c 100755
--- a/content/en/docs/tasks/run-application/_index.md
+++ b/content/en/docs/tasks/run-application/_index.md
@@ -1,5 +1,6 @@
---
title: "Run Applications"
+description: Run and manage both stateless and stateful applications.
weight: 40
---
diff --git a/content/en/docs/tasks/run-application/configure-pdb.md b/content/en/docs/tasks/run-application/configure-pdb.md
index d98538c262..8113e07128 100644
--- a/content/en/docs/tasks/run-application/configure-pdb.md
+++ b/content/en/docs/tasks/run-application/configure-pdb.md
@@ -1,10 +1,10 @@
---
title: Specifying a Disruption Budget for your Application
-content_template: templates/task
+content_type: task
weight: 110
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.5" state="beta" >}}
@@ -13,9 +13,10 @@ that your application experiences, allowing for higher availability
while permitting the cluster administrator to manage the clusters
nodes.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* You are the owner of an application running on a Kubernetes cluster that requires
high availability.
* You should know how to deploy [Replicated Stateless Applications](/docs/tasks/run-application/run-stateless-application-deployment/)
@@ -23,9 +24,9 @@ nodes.
* You should have read about [Pod Disruptions](/docs/concepts/workloads/pods/disruptions/).
* You should confirm with your cluster owner or service provider that they respect
Pod Disruption Budgets.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Protecting an Application with a PodDisruptionBudget
@@ -34,9 +35,9 @@ nodes.
1. Create a PDB definition as a YAML file.
1. Create the PDB object from the YAML file.
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Identify an Application to Protect
@@ -51,7 +52,7 @@ specified by one of the built-in Kubernetes controllers:
In this case, make a note of the controller's `.spec.selector`; the same
selector goes into the PDBs `.spec.selector`.
-From version 1.15 PDBs support custom controllers where the [scale subresource](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#scale-subresource) is enabled.
+From version 1.15 PDBs support custom controllers where the [scale subresource](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) is enabled.
You can also use PDBs with pods which are not controlled by one of the above
controllers, or arbitrary groups of pods, but there are some restrictions,
@@ -238,6 +239,6 @@ You can use a selector which selects a subset or superset of the pods belonging
controller. However, when there are multiple PDBs in a namespace, you must be careful not
to create PDBs whose selectors overlap.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/run-application/delete-stateful-set.md b/content/en/docs/tasks/run-application/delete-stateful-set.md
index d37e3ba7a0..7a4a94fab4 100644
--- a/content/en/docs/tasks/run-application/delete-stateful-set.md
+++ b/content/en/docs/tasks/run-application/delete-stateful-set.md
@@ -6,23 +6,24 @@ reviewers:
- janetkuo
- smarterclayton
title: Delete a StatefulSet
-content_template: templates/task
+content_type: task
weight: 60
---
-{{% capture overview %}}
+
This task shows you how to delete a {{< glossary_tooltip term_id="StatefulSet" >}}.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* This task assumes you have an application running on your cluster represented by a StatefulSet.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Deleting a StatefulSet
@@ -81,12 +82,13 @@ In the example above, the Pods have the label `app=myapp`; substitute your own l
If you find that some pods in your StatefulSet are stuck in the 'Terminating' or 'Unknown' states for an extended period of time, you may need to manually intervene to forcefully delete the pods from the apiserver. This is a potentially dangerous task. Refer to [Force Delete StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/) for details.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Learn more about [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
index b2b364f5f9..48a61a260d 100644
--- a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
+++ b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
@@ -5,22 +5,23 @@ reviewers:
- foxish
- smarterclayton
title: Force Delete StatefulSet Pods
-content_template: templates/task
+content_type: task
weight: 70
---
-{{% capture overview %}}
+
This page shows how to delete Pods which are part of a {{< glossary_tooltip text="stateful set" term_id="StatefulSet" >}}, and explains the considerations to keep in mind when doing so.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* This is a fairly advanced task and has the potential to violate some of the properties inherent to StatefulSet.
* Before proceeding, make yourself familiar with the considerations enumerated below.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## StatefulSet considerations
@@ -74,10 +75,11 @@ kubectl patch pod -p '{"metadata":{"finalizers":null}}'
Always perform force deletion of StatefulSet Pods carefully and with complete knowledge of the risks involved.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Learn more about [debugging a StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index cab3e0af7f..7f3b046b68 100644
--- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -5,11 +5,11 @@ reviewers:
- justinsb
- directxman12
title: Horizontal Pod Autoscaler Walkthrough
-content_template: templates/task
+content_type: task
weight: 100
---
-{{% capture overview %}}
+
Horizontal Pod Autoscaler automatically scales the number of pods
in a replication controller, deployment, replica set or stateful set based on observed CPU utilization
@@ -17,11 +17,12 @@ in a replication controller, deployment, replica set or stateful set based on ob
This document walks you through an example of enabling Horizontal Pod Autoscaler for the php-apache server. For more information on how Horizontal Pod Autoscaler behaves, see the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/).
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
This example requires a running Kubernetes cluster and kubectl, version 1.2 or later.
[metrics-server](https://github.com/kubernetes-incubator/metrics-server/) monitoring needs to be deployed in the cluster
@@ -35,9 +36,9 @@ not related to any Kubernetes object you must have a Kubernetes cluster at versi
you must be able to communicate with the API server that provides the external metrics API.
See the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) for more details.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Run & expose php-apache server
@@ -181,9 +182,9 @@ Here CPU utilization dropped to 0, and so HPA autoscaled the number of replicas
Autoscaling the replicas may take a few minutes.
{{< /note >}}
-{{% /capture %}}
-{{% capture discussion %}}
+
+
## Autoscaling on multiple metrics and custom metrics
@@ -483,4 +484,4 @@ kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml
horizontalpodautoscaler.autoscaling/php-apache created
```
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
index f6852845ec..f84744cdd7 100644
--- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
+++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
@@ -9,11 +9,11 @@ feature:
description: >
Scale your application up and down with a simple command, with a UI, or automatically based on CPU usage.
-content_template: templates/concept
+content_type: concept
weight: 90
---
-{{% capture overview %}}
+
The Horizontal Pod Autoscaler automatically scales the number of pods
in a replication controller, deployment, replica set or stateful set based on observed CPU utilization (or, with
@@ -26,10 +26,10 @@ The resource determines the behavior of the controller.
The controller periodically adjusts the number of replicas in a replication controller or deployment
to match the observed average CPU utilization to the target specified by user.
-{{% /capture %}}
-{{% capture body %}}
+
+
## How does the Horizontal Pod Autoscaler work?
@@ -181,7 +181,8 @@ are preserved as annotations when working with `autoscaling/v1`.
When you create a HorizontalPodAutoscaler API object, make sure the name specified is a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
More details about the API object can be found at
-[HorizontalPodAutoscaler Object](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object).
+[HorizontalPodAutoscaler Object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling).
+
## Support for Horizontal Pod Autoscaler in kubectl
@@ -260,7 +261,7 @@ See [Support for metrics APIs](#support-for-metrics-apis) for the requirements.
By default, the HorizontalPodAutoscaler controller retrieves metrics from a series of APIs. In order for it to access these
APIs, cluster administrators must ensure that:
-* The [API aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) is enabled.
+* The [API aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) is enabled.
* The corresponding APIs are registered:
@@ -376,7 +377,7 @@ For scaling down the stabilization window is _300_ seconds(or the value of the
for scaling down which allows a 100% of the currently running replicas to be removed which
means the scaling target can be scaled down to the minimum allowed replicas.
For scaling up there is no stabilization window. When the metrics indicate that the target should be
-scaled up the target is scaled up immediately. There are 2 policies which. 4 pods or a 100% of the currently
+scaled up the target is scaled up immediately. There are 2 policies where 4 pods or a 100% of the currently
running replicas will be added every 15 seconds till the HPA reaches its steady state.
### Example: change downscale stabilization window
@@ -431,12 +432,13 @@ behavior:
selectPolicy: Disabled
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Design documentation: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md).
* kubectl autoscale command: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
* Usage example of [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md
index 7a85a74014..2a7d255c2b 100644
--- a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md
+++ b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md
@@ -7,11 +7,11 @@ reviewers:
- kow3ns
- smarterclayton
title: Run a Replicated Stateful Application
-content_template: templates/tutorial
+content_type: tutorial
weight: 30
---
-{{% capture overview %}}
+
This page shows how to run a replicated stateful application using a
[StatefulSet](/docs/concepts/workloads/controllers/statefulset/) controller.
@@ -23,9 +23,10 @@ asynchronous replication.
on general patterns for running stateful applications in Kubernetes.
{{< /note >}}
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* {{< include "default-storage-class-prereqs.md" >}}
@@ -38,18 +39,19 @@ on general patterns for running stateful applications in Kubernetes.
* Some familiarity with MySQL helps, but this tutorial aims to present
general patterns that should be useful for other systems.
-{{% /capture %}}
-{{% capture objectives %}}
+
+## {{% heading "objectives" %}}
+
* Deploy a replicated MySQL topology with a StatefulSet controller.
* Send MySQL client traffic.
* Observe resistance to downtime.
* Scale the StatefulSet up and down.
-{{% /capture %}}
-{{% capture lessoncontent %}}
+
+
## Deploy MySQL
@@ -479,9 +481,10 @@ kubectl delete pvc data-mysql-3
kubectl delete pvc data-mysql-4
```
-{{% /capture %}}
-{{% capture cleanup %}}
+
+## {{% heading "cleanup" %}}
+
1. Cancel the `SELECT @@server_id` loop by pressing **Ctrl+C** in its terminal,
or running the following from another terminal:
@@ -522,9 +525,10 @@ kubectl delete pvc data-mysql-4
Some dynamic provisioners (such as those for EBS and PD) also release the
underlying resources upon deleting the PersistentVolumes.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [scaling a StatefulSet](/docs/tasks/run-application/scale-stateful-set/).
* Learn more about [debugging a StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/).
* Learn more about [deleting a StatefulSet](/docs/tasks/run-application/delete-stateful-set/).
@@ -532,7 +536,7 @@ kubectl delete pvc data-mysql-4
* Look in the [Helm Charts repository](https://github.com/kubernetes/charts)
for other stateful application examples.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/run-application/run-single-instance-stateful-application.md b/content/en/docs/tasks/run-application/run-single-instance-stateful-application.md
index 777265c68b..4c43948a21 100644
--- a/content/en/docs/tasks/run-application/run-single-instance-stateful-application.md
+++ b/content/en/docs/tasks/run-application/run-single-instance-stateful-application.md
@@ -1,37 +1,39 @@
---
title: Run a Single-Instance Stateful Application
-content_template: templates/tutorial
+content_type: tutorial
weight: 20
---
-{{% capture overview %}}
+
This page shows you how to run a single-instance stateful application
in Kubernetes using a PersistentVolume and a Deployment. The
application is MySQL.
-{{% /capture %}}
-{{% capture objectives %}}
+
+## {{% heading "objectives" %}}
+
* Create a PersistentVolume referencing a disk in your environment.
* Create a MySQL Deployment.
* Expose MySQL to other pods in the cluster at a known DNS name.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* {{< include "default-storage-class-prereqs.md" >}}
-{{% /capture %}}
-{{% capture lessoncontent %}}
+
+
## Deploy MySQL
@@ -180,10 +182,11 @@ PersistentVolume when it sees that you deleted the PersistentVolumeClaim.
Some dynamic provisioners (such as those for EBS and PD) also release the
underlying resource upon deleting the PersistentVolume.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [Deployment objects](/docs/concepts/workloads/controllers/deployment/).
@@ -193,6 +196,6 @@ underlying resource upon deleting the PersistentVolume.
* [Volumes](/docs/concepts/storage/volumes/) and [Persistent Volumes](/docs/concepts/storage/persistent-volumes/)
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/run-application/run-stateless-application-deployment.md b/content/en/docs/tasks/run-application/run-stateless-application-deployment.md
index 68d41b5a83..9e6ed4a25e 100644
--- a/content/en/docs/tasks/run-application/run-stateless-application-deployment.md
+++ b/content/en/docs/tasks/run-application/run-stateless-application-deployment.md
@@ -1,34 +1,36 @@
---
title: Run a Stateless Application Using a Deployment
min-kubernetes-server-version: v1.9
-content_template: templates/tutorial
+content_type: tutorial
weight: 10
---
-{{% capture overview %}}
+
This page shows how to run an application using a Kubernetes Deployment object.
-{{% /capture %}}
-{{% capture objectives %}}
+
+## {{% heading "objectives" %}}
+
* Create an nginx deployment.
* Use kubectl to list information about the deployment.
* Update the deployment.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture lessoncontent %}}
+
+
## Creating and exploring an nginx deployment
@@ -146,13 +148,14 @@ which in turn uses a ReplicaSet. Before the Deployment and ReplicaSet were
added to Kubernetes, replicated applications were configured using a
[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/).
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [Deployment objects](/docs/concepts/workloads/controllers/deployment/).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/run-application/scale-stateful-set.md b/content/en/docs/tasks/run-application/scale-stateful-set.md
index 462025836d..6e34babf9d 100644
--- a/content/en/docs/tasks/run-application/scale-stateful-set.md
+++ b/content/en/docs/tasks/run-application/scale-stateful-set.md
@@ -8,15 +8,16 @@ reviewers:
- kow3ns
- smarterclayton
title: Scale a StatefulSet
-content_template: templates/task
+content_type: task
weight: 50
---
-{{% capture overview %}}
+
This task shows how to scale a StatefulSet. Scaling a StatefulSet refers to increasing or decreasing the number of replicas.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* StatefulSets are only available in Kubernetes version 1.5 or later.
To check your version of Kubernetes, run `kubectl version`.
@@ -26,9 +27,9 @@ This task shows how to scale a StatefulSet. Scaling a StatefulSet refers to incr
* You should perform scaling only when you are confident that your stateful application
cluster is completely healthy.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Scaling StatefulSets
@@ -90,10 +91,11 @@ to reason about scaling operations at the application level in these cases, and
perform scaling only when you are sure that your stateful application cluster is
completely healthy.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [deleting a StatefulSet](/docs/tasks/run-application/delete-stateful-set/).
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/service-catalog/_index.md b/content/en/docs/tasks/service-catalog/_index.md
index 17bbaec3e9..77e5fa25e4 100755
--- a/content/en/docs/tasks/service-catalog/_index.md
+++ b/content/en/docs/tasks/service-catalog/_index.md
@@ -1,5 +1,6 @@
---
-title: "Install Service Catalog"
+title: "Service Catalog"
+description: Install the Service Catalog extension API.
weight: 150
---
diff --git a/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md
index 73268ff714..499bc1fa90 100644
--- a/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md
+++ b/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md
@@ -2,18 +2,19 @@
title: Install Service Catalog using Helm
reviewers:
- chenopis
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}}
Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes cluster. Up to date information on this process can be found at the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog/blob/master/docs/install.md) repo.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* Understand the key concepts of [Service Catalog](/docs/concepts/service-catalog/).
* Service Catalog requires a Kubernetes cluster running version 1.7 or higher.
* You must have a Kubernetes cluster with cluster DNS enabled.
@@ -24,10 +25,10 @@ Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes clust
* Follow the [Helm install instructions](https://helm.sh/docs/intro/install/).
* If you already have an appropriate version of Helm installed, execute `helm init` to install Tiller, the server-side component of Helm.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Add the service-catalog Helm repository
Once Helm is installed, add the *service-catalog* Helm repository to your local machine by executing the following command:
@@ -105,11 +106,12 @@ helm install svc-cat/catalog --name catalog --namespace catalog
```
{{% /tab %}}
{{< /tabs >}}
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
* Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md b/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md
index 2a50ca2ff8..a45474e297 100644
--- a/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md
+++ b/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md
@@ -2,10 +2,10 @@
title: Install Service Catalog using SC
reviewers:
- chenopis
-content_template: templates/task
+content_type: task
---
-{{% capture overview %}}
+
{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}}
You can use the GCP [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation)
@@ -14,10 +14,11 @@ Google Cloud projects.
Service Catalog itself can work with any kind of managed service, not just Google Cloud.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
* Understand the key concepts of [Service Catalog](/docs/concepts/service-catalog/).
* Install [Go 1.6+](https://golang.org/dl/) and set the `GOPATH`.
* Install the [cfssl](https://github.com/cloudflare/cfssl) tool needed for generating SSL artifacts.
@@ -27,10 +28,10 @@ Service Catalog itself can work with any kind of managed service, not just Googl
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Install `sc` in your local environment
The installer runs on your local computer as a CLI tool named `sc`.
@@ -71,11 +72,12 @@ If you would like to uninstall Service Catalog from your Kubernetes cluster usin
sc uninstall
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
* Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/setup-konnectivity/_index.md b/content/en/docs/tasks/setup-konnectivity/_index.md
deleted file mode 100755
index 09f254eba0..0000000000
--- a/content/en/docs/tasks/setup-konnectivity/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: "Setup Konnectivity Service"
-weight: 20
----
-
diff --git a/content/en/docs/tasks/tls/_index.md b/content/en/docs/tasks/tls/_index.md
index 8607aa28d2..6fb6923847 100755
--- a/content/en/docs/tasks/tls/_index.md
+++ b/content/en/docs/tasks/tls/_index.md
@@ -1,5 +1,6 @@
---
title: "TLS"
weight: 100
+description: Understand how to protect traffic within your cluster using Transport Layer Security (TLS).
---
diff --git a/content/en/docs/tasks/tls/certificate-rotation.md b/content/en/docs/tasks/tls/certificate-rotation.md
index 3cf55db335..890621c19f 100644
--- a/content/en/docs/tasks/tls/certificate-rotation.md
+++ b/content/en/docs/tasks/tls/certificate-rotation.md
@@ -2,23 +2,24 @@
reviewers:
- jcbsmpsn
- mikedanese
-title: Certificate Rotation
-content_template: templates/task
+title: Configure Certificate Rotation for the Kubelet
+content_type: task
---
-{{% capture overview %}}
+
This page shows how to enable and configure certificate rotation for the kubelet.
-{{% /capture %}}
+
{{< feature-state for_k8s_version="v1.8" state="beta" >}}
-{{% capture prerequisites %}}
+## {{% heading "prerequisites" %}}
+
* Kubernetes version 1.8.0 or later is required
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Overview
@@ -77,6 +78,6 @@ kubelet will retrieve the new signed certificate from the Kubernetes API and
write that to disk. Then it will update the connections it has to the
Kubernetes API to reconnect using the new certificate.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md
index 7cd4cc8be5..5098d353d8 100644
--- a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md
+++ b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md
@@ -1,13 +1,13 @@
---
title: Manage TLS Certificates in a Cluster
-content_template: templates/task
+content_type: task
reviewers:
- mikedanese
- beacham
- liggit
---
-{{% capture overview %}}
+
Kubernetes provides a `certificates.k8s.io` API, which lets you provision TLS
certificates signed by a Certificate Authority (CA) that you control. These CA
@@ -23,16 +23,17 @@ CA for this purpose, but you should never rely on this. Do not assume that
these certificates will validate against the cluster root CA.
{{< /note >}}
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Trusting TLS in a Cluster
@@ -222,4 +223,4 @@ enable it, pass the `--cluster-signing-cert-file` and
`--cluster-signing-key-file` parameters to the controller manager with paths to
your Certificate Authority's keypair.
-{{% /capture %}}
+
diff --git a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md
new file mode 100644
index 0000000000..4146608760
--- /dev/null
+++ b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md
@@ -0,0 +1,144 @@
+---
+title: Manual Rotation of CA Certificates
+min-kubernetes-server-version: v1.13
+content_template: templates/task
+---
+
+
+
+This page shows how to manually rotate the certificate authority (CA) certificates.
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+- For more information about authentication in Kubernetes, see [Authenticating](/docs/reference/access-authn-authz/authentication).
+- For more information about best practices for CA certificates, see [Single root CA](docs/setup/best-practices/certificates/#single-root-ca).
+
+
+
+## Rotate the CA certificates manually
+
+{{< caution >}}
+
+Make sure to back up your certificate directory along with configuration files and any other necessary files.
+
+This approach assumes operation of the Kubernetes control plane in a HA configuration with multiple API servers. Graceful termination of the API server is also assumed so clients can cleanly disconnect from one API server and reconnect to another.
+
+Configurations with a single API server will experience unavailability while the API server is being restarted.
+
+{{< /caution >}}
+
+1. Distribute the new CA certificates and private keys (ex: `ca.crt`, `ca.key`, `front-proxy-ca.crt`, and `front-proxy-ca.key`) to all your control plane nodes in the Kubernetes certificates directory.
+
+1. Update *Kubernetes controller manager's* `--root-ca-file` to include both old and new CA and restart controller manager.
+
+ Any service account created after this point will get secrets that include both old and new CAs.
+
+ {{< note >}}
+
+ Remove the flag `--client-ca-file` from the *Kubernetes controller manager* configuration. You can also replace the existing client CA file or change this configuration item to reference a new, updated CA. [Issue 1350](https://github.com/kubernetes/kubeadm/issues/1350) tracks an issue with *Kubernetes controller manager* being unable to accept a CA bundle.
+
+ {{< /note >}}
+
+1. Update all service account tokens to include both old and new CA certificates.
+
+ If any pods are started before new CA is used by API servers, they will get this update and trust both old and new CAs.
+
+ ```shell
+ base64_encoded_ca="$(base64 )"
+
+ for namespace in $(kubectl get ns --no-headers | awk '{print $1}'); do
+ for token in $(kubectl get secrets --namespace "$namespace" --field-selector type=kubernetes.io/service-account-token -o name); do
+ kubectl get $token --namespace "$namespace" -o yaml | \
+ /bin/sed "s/\(ca.crt:\).*/\1 ${base64_encoded_ca}" | \
+ kubectl apply -f -
+ done
+ done
+ ```
+
+1. Restart all pods using in-cluster configs (ex: kube-proxy, coredns, etc) so they can use the updated certificate authority data from *ServiceAccount* secrets.
+
+ * Make sure coredns, kube-proxy and other pods using in-cluster configs are working as expected.
+
+1. Append the both old and new CA to the file against `--client-ca-file` and `--kubelet-certificate-authority` flag in the `kube-apiserver` configuration.
+
+1. Append the both old and new CA to the file against `--client-ca-file` flag in the `kube-scheduler` configuration.
+
+1. Update certificates for user accounts by replacing the content of `client-certificate-data` and `client-key-data` respectively.
+
+ For information about creating certificates for individual user accounts, see [Configure certificates for user accounts](/docs/setup/best-practices/certificates/#configure-certificates-for-user-accounts).
+
+ Additionally, update the `certificate-authority-data` section in the kubeconfig files, respectively with Base64-encoded old and new certificate authority data
+
+1. Follow below steps in a rolling fashion.
+
+ 1. Restart any other *[aggregated api servers](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)* or *webhook handlers* to trust the new CA certificates.
+
+ 1. Restart the kubelet by update the file against `clientCAFile` in kubelet configuration and `certificate-authority-data` in kubelet.conf to use both the old and new CA on all nodes.
+
+ If your kubelet is not using client certificate rotation update `client-certificate-data` and `client-key-data` in kubelet.conf on all nodes along with the kubelet client certificate file usually found in `/var/lib/kubelet/pki`.
+
+
+ 1. Restart API servers with the certificates (`apiserver.crt`, `apiserver-kubelet-client.crt` and `front-proxy-client.crt`) signed by new CA. You can use the existing private keys or new private keys. If you changed the private keys then update these in the Kubernetes certificates directory as well.
+
+ Since the pod trusts both old and new CAs, there will be a momentarily disconnection after which the pod's kube client will reconnect to the new API server that uses the certificate signed by the new CA.
+
+ * Restart Scheduler to use the new CAs.
+
+ * Make sure control plane components logs no TLS errors.
+
+ {{< note >}}
+
+ To generate certificates and private keys for your cluster using the `openssl` command line tool, see [Certificates (`openssl`)](/docs/concepts/cluster-administration/certificates/#openssl).
+ You can also use [`cfssl`](/docs/concepts/cluster-administration/certificates/#cfssl).
+
+ {{< /note >}}
+
+ 1. Annotate any Daemonsets and Deployments to trigger pod replacement in a safer rolling fashion.
+
+ Example:
+
+ ```shell
+ for namespace in $(kubectl get namespace -o jsonpath='{.items[*].metadata.name}'); do
+ for name in $(kubectl get deployments -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
+ kubectl patch deployment -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
+ done
+ for name in $(kubectl get daemonset -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
+ kubectl patch daemonset -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
+ done
+ done
+ ```
+
+ {{< note >}}
+
+ To limit the number of concurrent disruptions that your application experiences, see [configure pod disruption budget](docs/tasks/run-application/configure-pdb/).
+
+ {{< /note >}}
+
+1. If your cluster is using bootstrap tokens to join nodes, update the ConfigMap `cluster-info` in the `kube-public` namespace with new CA.
+
+ ```shell
+ base64_encoded_ca="$(base64 /etc/kubernetes/pki/ca.crt)"
+
+ kubectl get cm/cluster-info --namespace kube-public -o yaml | \
+ /bin/sed "s/\(certificate-authority-data:\).*/\1 ${base64_encoded_ca}" | \
+ kubectl apply -f -
+ ```
+
+1. Verify the cluster functionality.
+
+ 1. Validate the logs from control plane components, along with the kubelet and the kube-proxy are not throwing any tls errors, see [looking at the logs](/docs/tasks/debug-application-cluster/debug-cluster/#looking-at-logs).
+
+ 1. Validate logs from any aggregated api servers and pods using in-cluster config.
+
+1. Once the cluster functionality is successfully verified:
+
+ 1. Update all service account tokens to include new CA certificate only.
+
+ * All pods using an in-cluster kubeconfig will eventually need to be restarted to pick up the new SA secret for the old CA to be completely untrusted.
+
+ 1. Restart the control plane components by removing the old CA from the kubeconfig files and the files against `--client-ca-file`, `--root-ca-file` flags resp.
+
+ 1. Restart kubelet by removing the old CA from file against the `clientCAFile` flag and kubelet kubeconfig file.
diff --git a/content/en/docs/tasks/tools/_index.md b/content/en/docs/tasks/tools/_index.md
index 78a5ead6cd..cabf9a3c7b 100755
--- a/content/en/docs/tasks/tools/_index.md
+++ b/content/en/docs/tasks/tools/_index.md
@@ -1,5 +1,6 @@
---
title: "Install Tools"
+description: Set up Kubernetes tools on your computer.
weight: 10
---
diff --git a/content/en/docs/tasks/tools/install-kubectl.md b/content/en/docs/tasks/tools/install-kubectl.md
index 131362109a..25b5cab9b5 100644
--- a/content/en/docs/tasks/tools/install-kubectl.md
+++ b/content/en/docs/tasks/tools/install-kubectl.md
@@ -2,7 +2,7 @@
reviewers:
- mikedanese
title: Install and Set Up kubectl
-content_template: templates/task
+content_type: task
weight: 10
card:
name: tasks
@@ -10,15 +10,16 @@ card:
title: Install kubectl
---
-{{% capture overview %}}
+
The Kubernetes command-line tool, [kubectl](/docs/user-guide/kubectl/), allows you to run commands against Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage cluster resources, and view logs. For a complete list of kubectl operations, see [Overview of kubectl](/docs/reference/kubectl/overview/).
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
You must use a kubectl version that is within one minor version difference of your cluster. For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. Using the latest version of kubectl helps avoid unforeseen issues.
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Install kubectl on Linux
@@ -113,35 +114,35 @@ kubectl version --client
1. Download the latest release:
- ```
- curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl"
- ```
+ ```bash
+ curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl"
+ ```
- To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.
+ To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.
- For example, to download version {{< param "fullversion" >}} on macOS, type:
-
- ```
- curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
- ```
+ For example, to download version {{< param "fullversion" >}} on macOS, type:
-2. Make the kubectl binary executable.
+ ```bash
+ curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
+ ```
- ```
- chmod +x ./kubectl
- ```
+ Make the kubectl binary executable.
+
+ ```bash
+ chmod +x ./kubectl
+ ```
3. Move the binary in to your PATH.
- ```
- sudo mv ./kubectl /usr/local/bin/kubectl
- ```
+ ```bash
+ sudo mv ./kubectl /usr/local/bin/kubectl
+ ```
4. Test to ensure the version you installed is up-to-date:
- ```
- kubectl version --client
- ```
+ ```bash
+ kubectl version --client
+ ```
### Install with Homebrew on macOS
@@ -149,21 +150,21 @@ If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you
1. Run the installation command:
- ```
- brew install kubectl
- ```
+ ```bash
+ brew install kubectl
+ ```
- or
+ or
- ```
- brew install kubernetes-cli
- ```
+ ```bash
+ brew install kubernetes-cli
+ ```
2. Test to ensure the version you installed is up-to-date:
- ```
- kubectl version --client
- ```
+ ```bash
+ kubectl version --client
+ ```
### Install with Macports on macOS
@@ -171,16 +172,16 @@ If you are on macOS and using [Macports](https://macports.org/) package manager,
1. Run the installation command:
- ```
- sudo port selfupdate
- sudo port install kubectl
- ```
-
+ ```bash
+ sudo port selfupdate
+ sudo port install kubectl
+ ```
+
2. Test to ensure the version you installed is up-to-date:
- ```
- kubectl version --client
- ```
+ ```bash
+ kubectl version --client
+ ```
## Install kubectl on Windows
@@ -188,21 +189,21 @@ If you are on macOS and using [Macports](https://macports.org/) package manager,
1. Download the latest release {{< param "fullversion" >}} from [this link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe).
- Or if you have `curl` installed, use this command:
+ Or if you have `curl` installed, use this command:
- ```
- curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
- ```
+ ```bash
+ curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
+ ```
- To find out the latest stable version (for example, for scripting), take a look at [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt).
+ To find out the latest stable version (for example, for scripting), take a look at [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt).
2. Add the binary in to your PATH.
3. Test to ensure the version of `kubectl` is the same as downloaded:
- ```
- kubectl version --client
- ```
+ ```bash
+ kubectl version --client
+ ```
{{< note >}}
[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes) adds its own version of `kubectl` to PATH.
@@ -215,21 +216,22 @@ If you are on Windows and using [Powershell Gallery](https://www.powershellgalle
1. Run the installation commands (making sure to specify a `DownloadLocation`):
- ```
- Install-Script -Name install-kubectl -Scope CurrentUser -Force
- install-kubectl.ps1 [-DownloadLocation ]
+ ```powershell
+ Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force
+ install-kubectl.ps1 [-DownloadLocation ]
```
-{{< note >}}If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's temp Directory.
-{{< /note >}}
+ {{< note >}}
+ If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's temp Directory.
+ {{< /note >}}
The installer creates `$HOME/.kube` and instructs it to create a config file.
2. Test to ensure the version you installed is up-to-date:
- ```
- kubectl version --client
- ```
+ ```powershell
+ kubectl version --client
+ ```
{{< note >}}
Updating the installation is performed by rerunning the two commands listed in step 1.
@@ -239,50 +241,54 @@ Updating the installation is performed by rerunning the two commands listed in s
1. To install kubectl on Windows you can use either [Chocolatey](https://chocolatey.org) package manager or [Scoop](https://scoop.sh) command-line installer.
-{{< tabs name="kubectl_win_install" >}}
-{{% tab name="choco" %}}
-
- choco install kubernetes-cli
-
-{{% /tab %}}
-{{% tab name="scoop" %}}
-
- scoop install kubectl
-
-{{% /tab %}}
-{{< /tabs >}}
+ {{< tabs name="kubectl_win_install" >}}
+ {{% tab name="choco" %}}
+ ```powershell
+ choco install kubernetes-cli
+ ```
+ {{% /tab %}}
+ {{% tab name="scoop" %}}
+ ```powershell
+ scoop install kubectl
+ ```
+ {{% /tab %}}
+ {{< /tabs >}}
2. Test to ensure the version you installed is up-to-date:
- ```
- kubectl version --client
- ```
+ ```powershell
+ kubectl version --client
+ ```
3. Navigate to your home directory:
- ```
- cd %USERPROFILE%
- ```
+ ```powershell
+ # If you're using cmd.exe, run: cd %USERPROFILE%
+ cd ~
+ ```
+
4. Create the `.kube` directory:
- ```
- mkdir .kube
- ```
+ ```powershell
+ mkdir .kube
+ ```
5. Change to the `.kube` directory you just created:
- ```
- cd .kube
- ```
+ ```powershell
+ cd .kube
+ ```
6. Configure kubectl to use a remote Kubernetes cluster:
- ```
- New-Item config -type file
- ```
-
-{{< note >}}Edit the config file with a text editor of your choice, such as Notepad.{{< /note >}}
+ ```powershell
+ New-Item config -type file
+ ```
+
+{{< note >}}
+Edit the config file with a text editor of your choice, such as Notepad.
+{{< /note >}}
## Download as part of the Google Cloud SDK
@@ -292,17 +298,17 @@ You can install kubectl as part of the Google Cloud SDK.
2. Run the `kubectl` installation command:
- ```
- gcloud components install kubectl
- ```
-
+ ```shell
+ gcloud components install kubectl
+ ```
+
3. Test to ensure the version you installed is up-to-date:
- ```
- kubectl version --client
- ```
+ ```shell
+ kubectl version --client
+ ```
-## Verifying kubectl configuration
+## Verifying kubectl configuration
In order for kubectl to find and access a Kubernetes cluster, it needs a [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), which is created automatically when you create a cluster using [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) or successfully deploy a Minikube cluster. By default, kubectl configuration is located at `~/.kube/config`.
@@ -316,7 +322,7 @@ If you see a URL response, kubectl is correctly configured to access your cluste
If you see a message similar to the following, kubectl is not configured correctly or is not able to connect to a Kubernetes cluster.
-```shell
+```
The connection to the server was refused - did you specify the right host or port?
```
@@ -354,7 +360,7 @@ The above commands create `/usr/share/bash-completion/bash_completion`, which is
To find out, reload your shell and run `type _init_completion`. If the command succeeds, you're already set, otherwise add the following to your `~/.bashrc` file:
-```shell
+```bash
source /usr/share/bash-completion/bash_completion
```
@@ -366,17 +372,17 @@ You now need to ensure that the kubectl completion script gets sourced in all yo
- Source the completion script in your `~/.bashrc` file:
- ```shell
- echo 'source <(kubectl completion bash)' >>~/.bashrc
- ```
+ ```bash
+ echo 'source <(kubectl completion bash)' >>~/.bashrc
+ ```
- Add the completion script to the `/etc/bash_completion.d` directory:
- ```shell
- kubectl completion bash >/etc/bash_completion.d/kubectl
- ```
+ ```bash
+ kubectl completion bash >/etc/bash_completion.d/kubectl
+ ```
If you have an alias for kubectl, you can extend shell completion to work with that alias:
-```shell
+```bash
echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -F __start_kubectl k' >>~/.bashrc
```
@@ -407,19 +413,19 @@ There are two versions of bash-completion, v1 and v2. V1 is for Bash 3.2 (which
The instructions here assume you use Bash 4.1+. You can check your Bash's version by running:
-```shell
+```bash
echo $BASH_VERSION
```
If it is too old, you can install/upgrade it using Homebrew:
-```shell
+```bash
brew install bash
```
Reload your shell and verify that the desired version is being used:
-```shell
+```bash
echo $BASH_VERSION $SHELL
```
@@ -433,13 +439,13 @@ As mentioned, these instructions assume you use Bash 4.1+, which means you will
You can test if you have bash-completion v2 already installed with `type _init_completion`. If not, you can install it with Homebrew:
-```shell
+```bash
brew install bash-completion@2
```
As stated in the output of this command, add the following to your `~/.bash_profile` file:
-```shell
+```bash
export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
```
@@ -452,29 +458,29 @@ You now have to ensure that the kubectl completion script gets sourced in all yo
- Source the completion script in your `~/.bash_profile` file:
- ```shell
+ ```bash
echo 'source <(kubectl completion bash)' >>~/.bash_profile
```
- Add the completion script to the `/usr/local/etc/bash_completion.d` directory:
- ```shell
+ ```bash
kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
```
- If you have an alias for kubectl, you can extend shell completion to work with that alias:
- ```shell
+ ```bash
echo 'alias k=kubectl' >>~/.bash_profile
echo 'complete -F __start_kubectl k' >>~/.bash_profile
```
-
+
- If you installed kubectl with Homebrew (as explained [above](#install-with-homebrew-on-macos)), then the kubectl completion script should already be in `/usr/local/etc/bash_completion.d/kubectl`. In that case, you don't need to do anything.
- {{< note >}}
- The Homebrew installation of bash-completion v2 sources all the files in the `BASH_COMPLETION_COMPAT_DIR` directory, that's why the latter two methods work.
- {{< /note >}}
+ {{< note >}}
+ The Homebrew installation of bash-completion v2 sources all the files in the `BASH_COMPLETION_COMPAT_DIR` directory, that's why the latter two methods work.
+ {{< /note >}}
In any case, after reloading your shell, kubectl completion should be working.
{{% /tab %}}
@@ -485,35 +491,32 @@ The kubectl completion script for Zsh can be generated with the command `kubectl
To do so in all your shell sessions, add the following to your `~/.zshrc` file:
-```shell
+```zsh
source <(kubectl completion zsh)
```
If you have an alias for kubectl, you can extend shell completion to work with that alias:
-```shell
+```zsh
echo 'alias k=kubectl' >>~/.zshrc
echo 'complete -F __start_kubectl k' >>~/.zshrc
```
-
+
After reloading your shell, kubectl autocompletion should be working.
If you get an error like `complete:13: command not found: compdef`, then add the following to the beginning of your `~/.zshrc` file:
-```shell
+```zsh
autoload -Uz compinit
compinit
```
{{% /tab %}}
{{< /tabs >}}
+## {{% heading "whatsnext" %}}
-{{% /capture %}}
-
-{{% capture whatsnext %}}
* [Install Minikube](/docs/tasks/tools/install-minikube/)
-* See the [getting started guides](/docs/setup/) for more about creating clusters.
+* See the [getting started guides](/docs/setup/) for more about creating clusters.
* [Learn how to launch and expose your application.](/docs/tasks/access-application-cluster/service-access-application-cluster/)
* If you need access to a cluster you didn't create, see the [Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
* Read the [kubectl reference docs](/docs/reference/kubectl/kubectl/)
-{{% /capture %}}
diff --git a/content/en/docs/tasks/tools/install-minikube.md b/content/en/docs/tasks/tools/install-minikube.md
index 50e4436dec..f1f3788141 100644
--- a/content/en/docs/tasks/tools/install-minikube.md
+++ b/content/en/docs/tasks/tools/install-minikube.md
@@ -1,19 +1,20 @@
---
title: Install Minikube
-content_template: templates/task
+content_type: task
weight: 20
card:
name: tasks
weight: 10
---
-{{% capture overview %}}
+
This page shows you how to install [Minikube](/docs/tutorials/hello-minikube), a tool that runs a single-node Kubernetes cluster in a virtual machine on your personal computer.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< tabs name="minikube_before_you_begin" >}}
{{% tab name="Linux" %}}
@@ -53,11 +54,11 @@ Hyper-V Requirements: A hypervisor has been detected. Features required for
{{% /tab %}}
{{< /tabs >}}
-{{% /capture %}}
-{{% capture steps %}}
-# Installing minikube
+
+
+## Installing minikube
{{< tabs name="tab_with_md" >}}
{{% tab name="Linux" %}}
@@ -199,15 +200,6 @@ To install Minikube manually on Windows, download [`minikube-windows-amd64`](htt
{{% /tab %}}
{{< /tabs >}}
-
-{{% /capture %}}
-
-{{% capture whatsnext %}}
-
-* [Running Kubernetes Locally via Minikube](/docs/setup/learning-environment/minikube/)
-
-{{% /capture %}}
-
## Confirm Installation
To confirm successful installation of both a hypervisor and Minikube, you can run the following command to start up a local Kubernetes cluster:
@@ -218,6 +210,10 @@ For setting the `--driver` with `minikube start`, enter the name of the hypervis
{{< /note >}}
+{{< caution >}}
+When using KVM, note that libvirt's default QEMU URI under Debian and some other systems is `qemu:///session` whereas Minikube's default QEMU URI is `qemu:///system`. If this is the case for your system, you will need to pass `--kvm-qemu-uri qemu:///session` to `minikube start`.
+{{< /caution >}}
+
```shell
minikube start --driver=
```
@@ -259,3 +255,8 @@ then you need to clear minikube's local state:
```shell
minikube delete
```
+
+## {{% heading "whatsnext" %}}
+
+
+* [Running Kubernetes Locally via Minikube](/docs/setup/learning-environment/minikube/)
diff --git a/content/en/docs/tutorials/_index.md b/content/en/docs/tutorials/_index.md
index 9f8de2129e..0deadcd945 100644
--- a/content/en/docs/tutorials/_index.md
+++ b/content/en/docs/tutorials/_index.md
@@ -2,10 +2,10 @@
title: Tutorials
main_menu: true
weight: 60
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
This section of the Kubernetes documentation contains tutorials.
A tutorial shows how to accomplish a goal that is larger than a single
@@ -14,9 +14,9 @@ each of which has a sequence of steps.
Before walking through each tutorial, you may want to bookmark the
[Standardized Glossary](/docs/reference/glossary/) page for later references.
-{{% /capture %}}
-{{% capture body %}}
+
+
## Basics
@@ -64,12 +64,13 @@ Before walking through each tutorial, you may want to bookmark the
* [Using Source IP](/docs/tutorials/services/source-ip/)
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
If you would like to write a tutorial, see
-[Using Page Templates](/docs/home/contribute/page-templates/)
-for information about the tutorial page type and the tutorial template.
+[Content Page Types](/docs/contribute/style/page-content-types/)
+for information about the tutorial page type.
+
-{{% /capture %}}
diff --git a/content/en/docs/tutorials/clusters/apparmor.md b/content/en/docs/tutorials/clusters/apparmor.md
index ae1de98ab2..ddad3d54c2 100644
--- a/content/en/docs/tutorials/clusters/apparmor.md
+++ b/content/en/docs/tutorials/clusters/apparmor.md
@@ -2,10 +2,10 @@
reviewers:
- stclair
title: AppArmor
-content_template: templates/tutorial
+content_type: tutorial
---
-{{% capture overview %}}
+
{{< feature-state for_k8s_version="v1.4" state="beta" >}}
@@ -13,7 +13,7 @@ content_template: templates/tutorial
AppArmor is a Linux kernel security module that supplements the standard Linux user and group based
permissions to confine programs to a limited set of resources. AppArmor can be configured for any
application to reduce its potential attack surface and provide greater in-depth defense. It is
-configured through profiles tuned to whitelist the access needed by a specific program or container,
+configured through profiles tuned to allow the access needed by a specific program or container,
such as Linux capabilities, network access, file permissions, etc. Each profile can be run in either
*enforcing* mode, which blocks access to disallowed resources, or *complain* mode, which only reports
violations.
@@ -24,9 +24,10 @@ that AppArmor is not a silver bullet and can only do so much to protect against
application code. It is important to provide good, restrictive profiles, and harden your
applications and cluster from other angles as well.
-{{% /capture %}}
-{{% capture objectives %}}
+
+## {{% heading "objectives" %}}
+
* See an example of how to load a profile on a node
* Learn how to enforce the profile on a Pod
@@ -34,9 +35,10 @@ applications and cluster from other angles as well.
* See what happens when a profile is violated
* See what happens when a profile cannot be loaded
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
Make sure:
@@ -111,9 +113,9 @@ gke-test-default-pool-239f5d02-x1kf: kubelet is posting ready status. AppArmor e
gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor enabled
```
-{{% /capture %}}
-{{% capture lessoncontent %}}
+
+
## Securing a Pod
@@ -458,13 +460,14 @@ Specifying the list of profiles Pod containers is allowed to specify:
- Although an escaped comma is a legal character in a profile name, it cannot be explicitly
allowed here.
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
Additional resources:
* [Quick guide to the AppArmor profile language](https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage)
* [AppArmor core policy reference](https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout)
-{{% /capture %}}
+
diff --git a/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md
index 7ae7fb087b..7555a58201 100644
--- a/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md
+++ b/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md
@@ -3,16 +3,17 @@ reviewers:
- eparis
- pmorie
title: Configuring Redis using a ConfigMap
-content_template: templates/tutorial
+content_type: tutorial
---
-{{% capture overview %}}
+
This page provides a real world example of how to configure Redis using a ConfigMap and builds upon the [Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) task.
-{{% /capture %}}
-{{% capture objectives %}}
+
+## {{% heading "objectives" %}}
+
* Create a `kustomization.yaml` file containing:
* a ConfigMap generator
@@ -20,18 +21,19 @@ This page provides a real world example of how to configure Redis using a Config
* Apply the directory by running `kubectl apply -k ./`
* Verify that the configuration was correctly applied.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* The example shown on this page works with `kubectl` 1.14 and above.
* Understand [Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/).
-{{% /capture %}}
-{{% capture lessoncontent %}}
+
+
## Real World Example: Configuring Redis using a ConfigMap
@@ -91,7 +93,7 @@ Use `kubectl exec` to enter the pod and run the `redis-cli` tool to verify that
the configuration was correctly applied:
```shell
-kubectl exec -it redis redis-cli
+kubectl exec -it redis -- redis-cli
127.0.0.1:6379> CONFIG GET maxmemory
1) "maxmemory"
2) "2097152"
@@ -105,12 +107,13 @@ Delete the created pod:
kubectl delete pod redis
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/).
-{{% /capture %}}
+
diff --git a/content/en/docs/tutorials/hello-minikube.md b/content/en/docs/tutorials/hello-minikube.md
index de6875b582..9ba2de1abf 100644
--- a/content/en/docs/tutorials/hello-minikube.md
+++ b/content/en/docs/tutorials/hello-minikube.md
@@ -1,6 +1,6 @@
---
title: Hello Minikube
-content_template: templates/tutorial
+content_type: tutorial
weight: 5
menu:
main:
@@ -13,7 +13,7 @@ card:
weight: 10
---
-{{% capture overview %}}
+
This tutorial shows you how to run a sample app
on Kubernetes using [Minikube](/docs/setup/learning-environment/minikube) and Katacoda.
@@ -23,23 +23,25 @@ Katacoda provides a free, in-browser Kubernetes environment.
You can also follow this tutorial if you've installed [Minikube locally](/docs/tasks/tools/install-minikube/).
{{< /note >}}
-{{% /capture %}}
-{{% capture objectives %}}
+
+## {{% heading "objectives" %}}
+
* Deploy a sample application to Minikube.
* Run the app.
* View application logs.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
This tutorial provides a container image that uses NGINX to echo back all the requests.
-{{% /capture %}}
-{{% capture lessoncontent %}}
+
+
## Create a Minikube cluster
@@ -272,12 +274,13 @@ Optionally, delete the Minikube VM:
minikube delete
```
-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+
* Learn more about [Deployment objects](/docs/concepts/workloads/controllers/deployment/).
* Learn more about [Deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/).
* Learn more about [Service objects](/docs/concepts/services-networking/service/).
-{{% /capture %}}
+
diff --git a/content/en/docs/tutorials/kubernetes-basics/public/css/styles.css b/content/en/docs/tutorials/kubernetes-basics/public/css/styles.css
index 3ee982aa11..8c743991d9 100644
--- a/content/en/docs/tutorials/kubernetes-basics/public/css/styles.css
+++ b/content/en/docs/tutorials/kubernetes-basics/public/css/styles.css
@@ -2605,7 +2605,7 @@ output
color: #555;
}
-.form-control
+/* .form-control
{
font-size: 14px;
line-height: 1.42857;
@@ -2671,7 +2671,7 @@ textarea.form-control
input[type='search']
{
-webkit-appearance: none;
-}
+} */
@media screen and (-webkit-min-device-pixel-ratio: 0)
{
@@ -8804,7 +8804,6 @@ button.close
.content
{
position: relative;
- z-index: 500;
box-sizing: border-box;
margin: 0 0 0 -200px;
@@ -8813,7 +8812,7 @@ button.close
-webkit-transition: .12s ease-out;
transition: .12s ease-out;
- background: #fff;
+ /* background: #fff; */
/*box-shadow: -6px 0 14px -4px rgba(0, 0, 0, .5);*/
-webkit-box-flex: 1;
@@ -9736,12 +9735,12 @@ p a:hover
content: '|';
}
-.btn
+/* .btn
{
font-family: Roboto Slab, Roboto, 'Helvetica Neue', Helvetica, 'Open Sans', Arial, sans-serif;
border-radius: 0;
-}
+} */
.btn.btn-success
{
color: #273d6d;
@@ -9914,11 +9913,11 @@ p a:hover
padding-bottom: 0;
}
-.form-control
+/* .form-control
{
border-radius: 0;
background: #f8f8f8;
-}
+} */
.content.katacoda-content {
padding: 0;
diff --git a/content/en/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/en/docs/tutorials/kubernetes-basics/scale/scale-intro.html
index 943ef01e0f..86e3621a28 100644
--- a/content/en/docs/tutorials/kubernetes-basics/scale/scale-intro.html
+++ b/content/en/docs/tutorials/kubernetes-basics/scale/scale-intro.html
@@ -40,7 +40,7 @@ weight: 10
The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
`kubeadm` also supports other cluster
@@ -24,9 +24,10 @@ of cloud servers, a Raspberry Pi, and more. Whether you're deploying into the
cloud or on-premises, you can integrate `kubeadm` into provisioning systems such
as Ansible or Terraform.
-{{% /capture %}}
-{{% capture prerequisites %}}
+
+## {{% heading "prerequisites" %}}
+
To follow this guide, you need:
@@ -53,9 +54,9 @@ slightly as the tool evolves, but the overall implementation should be pretty st
Any commands under `kubeadm alpha` are, by definition, supported on an alpha level.
{{< /note >}}
-{{% /capture %}}
-{{% capture steps %}}
+
+
## Objectives
@@ -117,7 +118,7 @@ While `--apiserver-advertise-address` can be used to set the advertise address f
control-plane node's API server, `--control-plane-endpoint` can be used to set the shared endpoint
for all control-plane nodes.
-`--control-plane-endpoint` allows IP addresses but also DNS names that can map to IP addresses.
+`--control-plane-endpoint` allows both IP addresses and DNS names that can map to IP addresses.
Please contact your network administrator to evaluate possible solutions with respect to such mapping.
Here is an example mapping:
@@ -312,12 +313,11 @@ kubectl apply -f https://docs.projectcalico.org/v3.14/manifests/calico.yaml
{{% /tab %}}
{{% tab name="Cilium" %}}
-For Cilium to work correctly, you must pass `--pod-network-cidr=10.217.0.0/16` to `kubeadm init`.
To deploy Cilium you just need to run:
```shell
-kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml
+kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
```
Once all Cilium Pods are marked as `READY`, you start using your cluster.
@@ -495,10 +495,10 @@ and `scp` using that other user instead.
The `admin.conf` file gives the user _superuser_ privileges over the cluster.
This file should be used sparingly. For normal users, it's recommended to
-generate an unique credential to which you whitelist privileges. You can do
+generate an unique credential to which you grant privileges. You can do
this with the `kubeadm alpha kubeconfig user --client-name 
+ 
+ 
+
+### 줌에서 회의 녹화
+
+녹화를 시작할 준비가 되면, Record to Cloud를 클릭한다.
+
+녹화를 중지하려면, Stop을 클릭한다.
+
+비디오가 자동으로 유튜브에 업로드된다.
+
+
diff --git a/content/ko/docs/contribute/generate-ref-docs/_index.md b/content/ko/docs/contribute/generate-ref-docs/_index.md
new file mode 100644
index 0000000000..756c509206
--- /dev/null
+++ b/content/ko/docs/contribute/generate-ref-docs/_index.md
@@ -0,0 +1,11 @@
+---
+title: 참조 문서 개요
+main_menu: true
+weight: 80
+---
+
+이 섹션은 쿠버네티스 참조 가이드를 생성하는 방법에 대해 설명한다.
+
+참조 문서화 시스템을 빌드하려면, 다음의 가이드를 참고한다.
+
+* [참조 문서 생성에 대한 퀵스타트 가이드](/docs/contribute/generate-ref-docs/quickstart/)
\ No newline at end of file
diff --git a/content/ko/docs/contribute/localization_ko.md b/content/ko/docs/contribute/localization_ko.md
index 9b56a46dfa..f6e0ae13b7 100644
--- a/content/ko/docs/contribute/localization_ko.md
+++ b/content/ko/docs/contribute/localization_ko.md
@@ -1,16 +1,54 @@
---
title: 쿠버네티스 문서 한글화 가이드
-content_template: templates/concept
+content_type: concept
---
-{{% capture overview %}}
+
쿠버네티스 문서 한글화를 위한 가이드
-{{% /capture %}}
-{{% capture body %}}
+
+
+
+## 팀 마일스톤 관리
+
+쿠버네티스 문서 한글화팀은 커뮤니티의
+[현지화 가이드](/docs/contribute/localization/#branching-strategy)에 따라 한글화를
+위한 팀 마일스톤과 개발 브랜치를 관리한다. 본 섹션은 한글화팀의 팀 마일스톤 관리에 특화된
+내용을 다룬다.
+
+한글화팀은 `master` 브랜치에서 분기한 개발 브랜치를 사용한다. 개발 브랜치 이름은 다음과 같은
+구조를 갖는다.
+
+`dev-<소스 버전>-ko.<팀 마일스톤>`
+
+개발 브랜치는 약 2주에서 3주 사이의 팀 마일스톤 기간 동안 공동의 작업을 위해 사용되며, 팀
+마일스톤이 종료될 때 원 브랜치로 병합(merge)된다.
+
+업스트림(upstream)의 릴리스 주기(약 3개월)에 따라 다음 버전으로 마일스톤을 변경하는 시점에는
+일시적으로 `release-<소스 버전>` 브랜치를 원 브랜치로 사용하는 개발 브랜치를 추가로 운영한다.
+
+[한글화팀의 정기 화상 회의 일정](https://github.com/kubernetes/community/tree/master/sig-docs#meetings)과
+팀 마일스톤 주기는 대체로 일치하며, 정기 회의를 통해 팀 마일스톤마다 PR 랭글러(wrangler)를
+지정한다.
+
+한글화팀의 PR 랭글러가 갖는 의무는 업스트림의
+[PR 랭글러](/ko/docs/contribute/advanced/#일주일-동안-pr-랭글러-wrangler-되기)가 갖는
+의무와 유사하다. 단, 업스트림의 PR 랭글러와는 달리 승인자가 아니어도 팀 마일스톤의 PR 랭글러가
+될 수 있다. 그래서, 보다 상위 권한이 필요한 업무가 발생한 경우, PR 랭글러는 해당 권한을 가진
+한글화팀 멤버에게 처리를 요청한다.
+
+업스트림의 [PR 랭글러에게 유용한 GitHub 쿼리](/ko/docs/contribute/advanced/#랭글러에게-유용한-github-쿼리)를
+기반으로 작성한, 한글화팀의 PR 랭글러에게 유용한 쿼리를 아래에 나열한다.
+
+- [CLA 서명 없음, 병합할 수 없음](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fko)
+- [LGTM 필요](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fko+-label%3Algtm+)
+- [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fko+label%3Algtm)
+- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fko%22+)
+
+팀 마일스톤 일정과 PR 랭글러는 커뮤니티 슬랙 내 [#kubernetes-docs-ko 채널](https://kubernetes.slack.com/archives/CA1MMR86S)에 공지된다.
## 문체 가이드
@@ -67,7 +105,7 @@ content_template: templates/concept
+
+
+ title: 쿠버네티스 컴포넌트
-content_template: templates/concept
+content_type: concept
weight: 10
```
@@ -87,27 +125,58 @@ weight: 10
기존에 번역된 문서를 참고한다.
{{% note %}}
-한영 병기는 페이지 내에서 해당 용어가 처음 사용되는 경우에만 적용하고 이후 부터는 한글만 표기한다.
+한영 병기는 페이지 내에서 해당 용어가 처음 사용되는 경우에만 1회 적용하고 이후에는 한글만 표기한다.
+한영 병기의 대상에는 제목도 포함되므로 제목에 한영 병기가 제공된 경우, 문서 내부에는
+한글만 표기한다.
{{% /note %}}
-### API 오브젝트 용어 한글화 관련 방침
+### API 오브젝트 용어 한글화 방침
-API 오브젝트는 외래어 표기법에 따라 한글 표기한다.
-
-쿠버네티스 API 오브젝트는 원 단어를
+일반적으로 `kubectl api-resources` 결과의 `kind` 에 해당하는 API 오브젝트는
[국립국어원 외래어 표기법](http://kornorms.korean.go.kr/regltn/regltnView.do?regltn_code=0003#a)에
-따라 한글화 한다. 예를 들면 다음과 같다.
+따라 한글로 표기하고 영문을 병기한다. 예를 들면 다음과 같다.
-원 단어 | 외래어 표기
---- | ---
-Deployment | 디플로이먼트
-Pod | 파드
-Service | 서비스
+API 오브젝트(kind) | 한글화(외래어 표기 및 영문 병기)
+--- | ---
+ClusterRoleBinding | 클러스터롤바인딩(ClusterRoleBinding)
+ConfigMap | 컨피그맵(ConfigMap)
+Deployment | 디플로이먼트(Deployment)
+PersistentVolumeClaim | 퍼시스턴트볼륨클레임(PersistentVolumeClaim)
+... | ...
+
+`kind` 에 속하는 API 오브젝트 중에서도 일부는 표현의 간결함을 위해 한영병기를 하지 않는 등의 예외가 있으며,
+예외에 대해서는 [한글화 용어집](#한글화-용어집)에 등록된 방식을 준용한다. 예를 들면 다음과 같다.
+
+API 오브젝트(kind) | 한글화(외래어 표기)
+--- | ---
+Pod | 파드
+Service | 서비스
+... | ...
+
+
+`kind` 에 속하지 않는 API 오브젝트는, [한글화 용어집](#한글화-용어집)에 등록된 용어인 경우를 제외하고,
+모두 원문 그대로 표기한다. 예를 들면 다음과 같다.
+
+API 오브젝트(kind가 아닌 경우) | 한글화(원문 유지)
+--- | ---
+ClusterRoleBindingList | ClusterRoleBindingList
+ClusterRoleList | ClusterRoleList
+ConfigMapEnvSource | ConfigMapEnvSource
+ConfigMapKeySelector | ConfigMapKeySelector
+PersistentVolumeClaimList | PersistentVolumeClaimList
+PersistentVolumeClaimSpec | PersistentVolumeClaimSpec
+... | ...
{{% note %}}
단, API 오브젝트 한글화 원칙에 예외가 있을 수 있으며, 이 경우에는 가능한
[한글화 용어집](#한글화-용어집)을 준용한다. (예를 들면, Horizontal Pod Autoscaler
-는 API 오브젝트에 대해 외래어 표기법 적용하지 않고 원문 그대로 표기한다.)
+는 API 오브젝트에 대해 외래어 표기법을 적용하지 않고 원문 그대로 표기한다.)
+{{% /note %}}
+
+{{% note %}}
+원문에서는 API 오브젝트를 camelCase(예: configMap)로 표기하는 것을 가이드하고 있다.
+그러나 한글에는 대소문자 구분이 없으므로 이를 띄어쓰기 없이 붙여서 처리한다.
+(예: configMap -> 컨피그맵, config Map -> 컨피그맵)
{{% /note %}}
{{% note %}}
@@ -116,6 +185,31 @@ API 오브젝트의 필드 이름, 파일 이름, 경로와 같은 내용은 독
단, 주석에 포함된 내용은 한글로 옮길 수 있다.
{{% /note %}}
+### 기능 게이트(feature gate) 한글화 방침
+
+쿠버네티스의 [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
+의미하는 용어는 한글화하지 않고 원문 형태를 유지한다.
+
+기능 게이트의 예시는 다음과 같다.
+- Accelerators
+- AdvancedAuditing
+- AffinityInAnnotations
+- AllowExtTrafficLocalEndpoints
+- ...
+
+전체 기능 게이트 목록은
+[여기](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates)를 참고한다.
+
+{{% note %}}
+단, 해당 원칙에는 예외가 있을 수 있으며, 이 경우에는 가능한
+[한글화 용어집](#한글화-용어집)을 준용한다.
+{{% /note %}}
+
+{{% note %}}
+기능 게이트는 쿠버네티스 버전에 따라 변경될 수 있으므로,
+쿠버네티스 및 쿠버네티스 문서의 버전에 맞는 기능 게이트 목록을 적용하여 한글화를 진행한다.
+{{% /note %}}
+
### 한글화 용어집 정보
쿠버네티스 [한글화 용어집](#한글화-용어집)은 한글화된 쿠버네티스 문서의 일관성을 위해서
@@ -153,6 +247,7 @@ Age | 기간 |
Allocation | 할당량 |
alphanumeric | 영숫자 |
Annotation | 어노테이션 |
+APIService | API서비스(APIService) | API 오브젝트인 경우
App | 앱 |
Appendix | 부록 |
Application | 애플리케이션 |
@@ -162,6 +257,7 @@ autoscaler | 오토스케일러 |
availability zone | 가용성 영역(availability zone) |
bare pod | 베어(bare) 파드 |
beta | 베타 |
+Binding | 바인딩(Binding) | API 오브젝트인 경우
boilerplate | 상용구 |
Boot | 부트 |
Build | 빌드 |
@@ -169,31 +265,37 @@ Cache | 캐시 |
Calico | 캘리코(Calico) |
canary | 카나리(canary) | 릴리스 방식에 관련한 용어인 경우에 한함
cascading | 캐스케이딩(cascading) |
+CertificateSigningRequest | CertificateSigningRequest | API 오브젝트인 경우
character set | 캐릭터 셋 |
Charts | 차트 |
checkpoint | 체크포인트 |
Cilium | 실리움(Cilium) |
CLI | CLI |
Cluster | 클러스터 |
+ClusterRole | 클러스터롤(ClusterRole) | API 오브젝트인 경우
+ClusterRoleBinding | 클러스터롤바인딩(ClusterRoleBinding) | API 오브젝트인 경우
Command Line Tool | 커맨드라인 툴 |
-Config Map | 컨피그 맵 |
+ComponentStatus | 컴포넌트스테이터스(ComponentStatus) | API 오브젝트인 경우
+ConfigMap | 컨피그맵(ConfigMap) | API 오브젝트인 경우
configuration | 구성, 설정 |
Connection | 연결 |
containerized | 컨테이너화 된 |
Context | 컨텍스트 |
Control Plane | 컨트롤 플레인 |
controller | 컨트롤러 |
-Cron Job | 크론 잡 |
+ControllerRevision | 컨트롤러리비전(ControllerRevision) | API 오브젝트인 경우
+cron job | 크론 잡 |
+CronJob | 크론잡(CronJob) | API 오브젝트인 경우
+CSIDriver | CSI드라이버(CSIDriver) | API 오브젝트인 경우
+CSINode | CSI노드(CSINode) | API 오브젝트인 경우
custom metrics | 사용자 정의 메트릭 |
-Custom resource | 사용자 정의 리소스 |
-CustomResourceDefinition | 커스텀 리소스 데피니션 |
+custom resource | 사용자 정의 리소스 |
+CustomResourceDefinition | 커스텀리소스데피니션(CustomResourceDefinition) | API 오브젝트인 경우
Daemon | 데몬 |
-Daemon Set | 데몬 셋 |
+DaemonSet | 데몬셋(DaemonSet) | API 오브젝트인 경우
Dashboard | 대시보드 |
Data Plane | 데이터 플레인 |
-Default Limit | 기본 상한 |
-Default Request | 기본 요청량 |
-Deployment | 디플로이먼트 |
+Deployment | 디플로이먼트(Deployment) | API 오브젝트인 경우
deprecated | 사용 중단(deprecated) |
descriptor | 디스크립터, 식별자 |
Desired number of pods | 의도한 파드의 수 |
@@ -206,9 +308,11 @@ Docker Swarm | Docker Swarm |
Downward API | 다운워드(Downward) API |
draining | 드레이닝(draining) |
egress | 이그레스, 송신(egress) |
-Endpoint | 엔드포인트 |
+endpoint | 엔드포인트 |
+EndpointSlice | 엔드포인트슬라이스(EndpointSlice) | API 오브젝트인 경우
+Endpoints | 엔드포인트(Endpoints) | API 오브젝트인 경우
entry point | 진입점 |
-Event | 이벤트 |
+Event | 이벤트(Event) | API 오브젝트인 경우
evict | 축출하다 |
eviction | 축출 |
Exec | Exec |
@@ -235,27 +339,31 @@ Hypervisor | 하이퍼바이저 |
idempotent | 멱등성 |
Image | 이미지 |
Image Pull Secrets | 이미지 풀(Pull) 시크릿 |
-Ingress | 인그레스 |
+Ingress | 인그레스(Ingress) | API 오브젝트인 경우
+IngressClass | 인그레스클래스(IngressClass) | API 오브젝트인 경우
Init Container | 초기화 컨테이너 |
Instance group | 인스턴스 그룹 |
introspection | 인트로스펙션(introspection) |
Istio | 이스티오(Istio) |
-Job | 잡 |
+Job | 잡(Job) | API 오브젝트인 경우
kube-proxy | kube-proxy |
Kubelet | Kubelet |
Kubernetes | 쿠버네티스 |
Kube-router | Kube-router |
label | 레이블 |
+Lease | 리스(Lease) | API 오브젝트인 경우
lifecycle | 라이프사이클 |
+LimitRange | 리밋레인지(LimitRange) | API 오브젝트인 경우
+limit | 한도(limit) | 리소스의 개수나 용량을 한정하기 위한 수치로 사용된 경우 선택적으로 사용 (API 오브젝트의 속성으로 limit을 사용한 경우는 가능한 영문 유지)
Linux | 리눅스 |
load | 부하 |
+LocalSubjectAccessReview | 로컬서브젝트액세스리뷰(LocalSubjectAccessReview) | API 오브젝트인 경우
Log | 로그 |
loopback | 루프백(loopback) |
Lost | Lost | 클레임의 상태에 한함
Machine | 머신 |
manifest | 매니페스트 |
Master | 마스터 |
-max limit/request ratio | 최대 상한/요청량 비율 |
metadata | 메타데이터 |
metric | 메트릭 |
masquerading | 마스커레이딩 |
@@ -263,11 +371,12 @@ Minikube | Minikube |
Mirror pod | 미러 파드(mirror pod) |
monitoring | 모니터링 |
multihomed | 멀티홈드(multihomed) |
+MutatingWebhookConfiguration | MutatingWebhookConfiguration | API 오브젝트인 경우
naked pod | 네이키드(naked) 파드 |
-Namespace | 네임스페이스 |
+Namespace | 네임스페이스(Namespace) | API 오브젝트인 경우
netfilter | 넷필터(netfilter) |
-Network Policy | 네트워크 폴리시 |
-Node | 노드 |
+NetworkPolicy | 네트워크폴리시(NetworkPolicy) | API 오브젝트인 경우
+Node | 노드(Node) | API 오브젝트인 경우
node lease | 노드 리스(lease)
Object | 오브젝트 |
Orchestrate | 오케스트레이션하다 |
@@ -275,16 +384,19 @@ Output | 출력 |
parameter | 파라미터 |
patch | 패치 |
Pending | Pending | 파드, 클레임의 상태에 한함
-Persistent Volume | 퍼시스턴트 볼륨 |
-Persistent Volume Claim | 퍼시스턴트 볼륨 클레임 |
+PersistentVolume | 퍼시스턴트볼륨(PersistentVolume) | API 오브젝트인 경우
+PersistentVolumeClaim | 퍼시스턴트볼륨클레임(PersistentVolumeClaim) | API 오브젝트인 경우
pipeline | 파이프라인 |
placeholder pod | 플레이스홀더(placeholder) 파드 |
-Pod | 파드 |
+Pod | 파드 | API 오브젝트인 경우에도 표현의 간결함을 위해 한영병기를 하지 않음
Pod Preset | 파드 프리셋 |
PodAntiAffinity | 파드안티어피니티(PodAntiAffinity) |
-PodDisruptionBudget | PodDisruptionBudget |
+PodDisruptionBudget | PodDisruptionBudget | API 오브젝트인 경우
+PodSecurityPolicy | 파드시큐리티폴리시(PodSecurityPolicy) | API 오브젝트인 경우
+PodTemplate | 파드템플릿(PodTemplate) | API 오브젝트인 경우
postfix | 접미사 |
prefix | 접두사 |
+PriorityClass | 프라이어리티클래스(PriorityClass) | API 오브젝트인 경우
Privileged | 특권을 가진(privileged) |
Prometheus | 프로메테우스 |
proof of concept | 개념 증명 |
@@ -300,29 +412,33 @@ redirect | 리다이렉트(redirect) |
redirection | 리다이렉션 |
Registry | 레지스트리 |
Release | 릴리스 |
-Replica Set | 레플리카 셋 |
+ReplicaSet | 레플리카셋(ReplicaSet) | API 오브젝트인 경우
replicas | 레플리카 |
-Replication Controller | 레플리케이션 컨트롤러 |
+ReplicationController | 레플리케이션컨트롤러(ReplicationController) | API 오브젝트인 경우
repository | 리포지터리 |
+request | 요청(request) | 리소스의 개수나 용량에 대한 요청 수치를 표현하기 위해 사용된 경우 선택적으로 사용 (API 오브젝트 속성으로 request를 사용한 경우는 가능한 영문을 유지)
resource | 리소스 |
-Resource Limit | 리소스 상한 |
-Resource Quota | 리소스 쿼터 |
+ResourceQuota | 리소스쿼터(ResourceQuota) | API 오브젝트인 경우
return | 반환하다 |
revision | 리비전 |
-Role | 롤 |
+Role | 롤(Role) | API 오브젝트인 경우
+RoleBinding | 롤바인딩(RoleBinding) | API 오브젝트인 경우
rollback | 롤백 |
rolling update | 롤링 업데이트 |
rollout | 롤아웃 |
Romana | 로마나(Romana) |
Running | Running | 파드의 상태에 한함
runtime | 런타임 |
+RuntimeClass | 런타임클래스(RuntimeClass) | API 오브젝트인 경우
Scale | 스케일 |
-Secret | 시크릿 |
+Secret | 시크릿(Secret) | API 오브젝트인 경우
segment | 세그먼트 |
Selector | 셀렉터 |
Self-healing | 자가 치유 |
-Service | 서비스 |
-Service Account | 서비스 어카운트 |
+SelfSubjectAccessReview | 셀프서브젝트액세스리뷰(SelfSubjectAccessReview) | API 오브젝트인 경우
+SelfSubjectRulesReview | SelfSubjectRulesReview | API 오브젝트이지만 용어를 구성하는 단어 중 복수형 Rules를 '룰스'로 외래어 표기하는 경우 한국어 독자에게 다소 생경할 수 있어 예외적으로 영문 용어를 사용함
+Service | 서비스 | API 오브젝트인 경우에도 표현의 간결함을 위해 한영병기를 하지 않음
+ServiceAccount | 서비스어카운트(ServiceAccount) | API 오브젝트인 경우
service discovery | 서비스 디스커버리 |
service mesh | 서비스 메시 |
Session | 세션 |
@@ -335,10 +451,11 @@ skew | 차이(skew) |
snippet | 스니펫(snippet) |
spec | 명세, 스펙, 사양 |
specification | 명세 |
-Stateful Set | 스테이트풀 셋 |
+StatefulSet | 스테이트풀셋(StatefulSet) | API 오브젝트인 경우
stateless | 스테이트리스 |
Static pod | 스태틱(static) 파드 |
-Storage Class | 스토리지 클래스 |
+StorageClass | 스토리지클래스(StorageClass) | API 오브젝트인 경우
+SubjectAccessReview | 서브젝트액세스리뷰(SubjectAccessReview) | API 오브젝트인 경우
Sub-Object | 서브-오브젝트 |
support | 지원 |
Surge | 증가율 | 롤링업데이트 전략에 한함
@@ -346,6 +463,7 @@ System | 시스템 |
taint | 테인트(taint) |
Task | 태스크 |
Terminated | Terminated | 파드의 상태에 한함
+TokenReview | 토큰리뷰(TokenReview) | API 오브젝트인 경우
tolerations | 톨러레이션(toleration) |
Topology spread constraints | 토폴로지 분배 제약 조건 |
Tools | 도구 |
@@ -355,9 +473,11 @@ ubuntu | 우분투 |
use case | 유스케이스 |
userspace | 유저스페이스(userspace) |
Utilization | 사용량, 사용률 |
+ValidatingWebhookConfiguration | ValidatingWebhookConfiguration | API 오브젝트인 경우
verbosity | 로그 상세 레벨(verbosity) |
virtualization | 가상화 |
Volume | 볼륨 |
+VolumeAttachment | 볼륨어태치먼트(VolumeAttachment) | API 오브젝트인 경우
Waiting | Waiting | 파드의 상태에 한함
Walkthrough | 연습 |
Weave-net | 위브넷(Weave Net) | Weaveworks 사의 솔루션 공식 명칭은 'Weave Net'이므로 한영병기 시 공식 명칭 사용
@@ -365,5 +485,3 @@ Windows | 윈도우 |
Worker | 워커 | 노드의 형태에 한함
Workload | 워크로드 |
YAML | YAML |
-
-{{% /capture %}}
diff --git a/content/ko/docs/contribute/new-content/open-a-pr.md b/content/ko/docs/contribute/new-content/open-a-pr.md
index 17ea3342c1..46439d3565 100644
--- a/content/ko/docs/contribute/new-content/open-a-pr.md
+++ b/content/ko/docs/contribute/new-content/open-a-pr.md
@@ -1,14 +1,14 @@
---
title: 풀 리퀘스트 열기
slug: new-content
-content_template: templates/concept
+content_type: concept
weight: 10
card:
name: contribute
weight: 40
---
-{{% capture overview %}}
+
{{< note >}}
**코드 개발자**: 향후 쿠버네티스 릴리스의
@@ -22,9 +22,9 @@ card:
변경 사항이 많으면, [로컬 포크에서 작업하기](#fork-the-repo)를 읽고 컴퓨터에서 로컬로 변경하는 방법을 배운다.
-{{% /capture %}}
-{{% capture body %}}
+
+
## GitHub을 사용하여 변경하기
@@ -408,7 +408,7 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
git rebase -i HEAD~