add en pages
This commit is contained in:
Karen Bradshaw
@@ -1,18 +1,19 @@
|
||||
---
|
||||
title: Access Clusters Using the Kubernetes API
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Accessing the Kubernetes API
|
||||
|
||||
@@ -449,5 +450,5 @@ The output will be similar to this:
|
||||
}
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -1,18 +1,19 @@
|
||||
---
|
||||
title: Access Services Running on Clusters
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,21 +1,22 @@
|
||||
---
|
||||
title: Change the default StorageClass
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Why change the default storage class?
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,20 +1,21 @@
|
||||
---
|
||||
title: Change the Reclaim Policy of a PersistentVolume
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Why change reclaim policy of a PersistentVolume
|
||||
|
||||
@@ -80,9 +81,10 @@ kubectl patch pv <your-pv-name> -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 <your-pv-name> -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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -3,20 +3,20 @@ reviewers:
|
||||
- lavalamp
|
||||
- thockin
|
||||
title: Cluster Management
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
@@ -3,10 +3,10 @@ reviewers:
|
||||
- davidopp
|
||||
- madhusudancs
|
||||
title: Configure Multiple Schedulers
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 +19,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 %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Package the scheduler
|
||||
|
||||
@@ -219,9 +220,9 @@ kubectl create -f pod3.yaml
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
### Verifying that the pods were scheduled using the desired schedulers
|
||||
|
||||
@@ -241,4 +242,4 @@ verify that the pods were scheduled by the desired schedulers.
|
||||
kubectl get events
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -3,23 +3,24 @@ reviewers:
|
||||
- mml
|
||||
- wojtek-t
|
||||
title: Operating etcd clusters for Kubernetes
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,10 +4,10 @@ reviewers:
|
||||
- sjenning
|
||||
- ConnorDoyle
|
||||
- balajismaniam
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## CPU Management Policies
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
@@ -4,18 +4,18 @@ reviewers:
|
||||
- thockin
|
||||
- wlan0
|
||||
title: Developing Cloud Controller Manager
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
@@ -3,24 +3,25 @@ reviewers:
|
||||
- bowei
|
||||
- zihongz
|
||||
title: Customizing DNS Service
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "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 %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Introduction
|
||||
|
||||
@@ -213,9 +214,9 @@ their destination DNS servers:
|
||||
See [ConfigMap options](#configmap-options) for
|
||||
details about the configuration option format.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
#### Effects on Pods
|
||||
|
||||
@@ -302,7 +303,7 @@ data:
|
||||
["172.16.0.1"]
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
## CoreDNS configuration equivalent to kube-dns
|
||||
|
||||
|
||||
@@ -3,20 +3,21 @@ reviewers:
|
||||
- bowei
|
||||
- zihongz
|
||||
title: Debugging DNS Resolution
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
This page provides hints on diagnosing DNS problems.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "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 %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
### Create a simple Pod to use as a test environment
|
||||
|
||||
@@ -273,5 +274,5 @@ for more information.
|
||||
## What's next
|
||||
- [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -1,14 +1,15 @@
|
||||
---
|
||||
title: Autoscale the DNS Service in a Cluster
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
@@ -3,19 +3,20 @@ reviewers:
|
||||
- bowei
|
||||
- freehan
|
||||
title: Enabling EndpointSlices
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
@@ -4,19 +4,20 @@ reviewers:
|
||||
- johnbelamaric
|
||||
- imroc
|
||||
title: Enabling Service Topology
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
@@ -1,26 +1,27 @@
|
||||
---
|
||||
title: Advertise Extended Resources for a Node
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Get the names of your Nodes
|
||||
|
||||
@@ -189,10 +190,11 @@ kubectl describe node <your-node-name> | grep dongle
|
||||
|
||||
(you should not see any output)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
### For application developers
|
||||
|
||||
@@ -204,4 +206,4 @@ kubectl describe node <your-node-name> | grep dongle
|
||||
* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
+5
-5
@@ -4,10 +4,10 @@ reviewers:
|
||||
- filipg
|
||||
- piosz
|
||||
title: Guaranteed Scheduling For Critical Add-On Pods
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
@@ -2,26 +2,27 @@
|
||||
reviewers:
|
||||
- jszczepkowski
|
||||
title: Set up High-Availability Kubernetes Masters
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
@@ -1,19 +1,20 @@
|
||||
---
|
||||
title: IP Masquerade Agent User Guide
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
@@ -2,13 +2,14 @@
|
||||
reviewers:
|
||||
- smarterclayton
|
||||
title: Using a KMS provider for data encryption
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
@@ -2,25 +2,26 @@
|
||||
reviewers:
|
||||
- sig-cluster-lifecycle
|
||||
title: Certificate Management with kubeadm
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Using custom certificates {#custom-certificates}
|
||||
|
||||
@@ -242,4 +243,4 @@ 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 %}}
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Determine which version to upgrade to
|
||||
|
||||
@@ -395,7 +396,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
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Upgrading worker nodes
|
||||
|
||||
@@ -90,4 +91,4 @@ again replacing {{< param "fullversion" >}} with your desired version:
|
||||
```
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -3,10 +3,10 @@ reviewers:
|
||||
- mtaufen
|
||||
- dawnchen
|
||||
title: Set Kubelet parameters via a config file
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
---
|
||||
title: Limit Storage Consumption
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
+11
-9
@@ -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 %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
+11
-9
@@ -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 %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
+11
-9
@@ -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 %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
+11
-9
@@ -1,30 +1,31 @@
|
||||
---
|
||||
title: Configure Memory and CPU Quotas for a Namespace
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 50
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,28 +1,29 @@
|
||||
---
|
||||
title: Configure a Pod Quota for a Namespace
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 60
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -3,10 +3,10 @@ reviewers:
|
||||
- derekwaynecarr
|
||||
- janetkuo
|
||||
title: Namespaces Walkthrough
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
|
||||
@@ -3,19 +3,20 @@ reviewers:
|
||||
- derekwaynecarr
|
||||
- janetkuo
|
||||
title: Share a Cluster with Namespaces
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Viewing namespaces
|
||||
|
||||
@@ -252,9 +253,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 %}}
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## Understanding the motivation for using namespaces
|
||||
|
||||
@@ -304,12 +305,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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
+11
-9
@@ -2,19 +2,20 @@
|
||||
reviewers:
|
||||
- caseydavenport
|
||||
title: Use Calico for NetworkPolicy
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
|
||||
+13
-11
@@ -3,23 +3,24 @@ reviewers:
|
||||
- danwent
|
||||
- aanm
|
||||
title: Use Cilium for NetworkPolicy
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- steps -->
|
||||
## Deploying Cilium on Minikube for Basic Testing
|
||||
|
||||
To get familiar with Cilium easily you can follow the
|
||||
@@ -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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
+11
-9
@@ -2,25 +2,27 @@
|
||||
reviewers:
|
||||
- murali-reddy
|
||||
title: Use Kube-router for NetworkPolicy
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
+11
-9
@@ -2,23 +2,24 @@
|
||||
reviewers:
|
||||
- chrismarino
|
||||
title: Romana for NetworkPolicy
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
+11
-9
@@ -2,23 +2,24 @@
|
||||
reviewers:
|
||||
- bboreham
|
||||
title: Weave Net for NetworkPolicy
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,21 +4,22 @@ reviewers:
|
||||
- zihongz
|
||||
- sftim
|
||||
title: Using NodeLocal DNSCache in Kubernetes clusters
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Introduction
|
||||
|
||||
@@ -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 <manifest>` . You should also revert any changes you made to the kubelet configuration.
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -4,10 +4,10 @@ reviewers:
|
||||
- vishh
|
||||
- timstclair
|
||||
title: Configure Out of Resource Handling
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: Configure Quotas for API Objects
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Reconfiguring the kubelet on a running node in your cluster
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
@@ -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 %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
@@ -4,10 +4,10 @@ reviewers:
|
||||
- thockin
|
||||
- wlan0
|
||||
title: Cloud Controller Manager Administration
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -5,23 +5,24 @@ reviewers:
|
||||
- ericchiang
|
||||
- destijl
|
||||
title: Securing a Cluster
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,25 +2,26 @@
|
||||
title: Using sysctls in a Kubernetes Cluster
|
||||
reviewers:
|
||||
- sttts
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Listing all Sysctl Parameters
|
||||
|
||||
@@ -140,9 +141,9 @@ spec:
|
||||
value: "65536"
|
||||
...
|
||||
```
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
{{< warning >}}
|
||||
Due to their nature of being _unsafe_, the use of _unsafe_ sysctls
|
||||
@@ -210,4 +211,4 @@ spec:
|
||||
...
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -8,11 +8,11 @@ reviewers:
|
||||
- nolancon
|
||||
- bg-chun
|
||||
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
min-kubernetes-server-version: v1.18
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- 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 %}}
|
||||
|
||||
<!-- 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 %}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user