whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Changes for move to Netlify (#4464)

Browse Source 
* disable jekyll-redirect-from gem

* add _redirects file

* disable 404 redirect script

* add 301 redirect to test

* retain _redirects file

* Convert redirect_from's to _redirect file. (#4409)

* Remove redirect_from's. (#4424)

* Add 301's to _redirects. (#4427)

* add whitespace before 301

* move redirects in /js/redirects/js to _redirects

* add disabled option for cn redirect

* convert include to array in _config.yml

* enable redirects.js script for legacy support
This commit is contained in:
Andrew Chen
2017-07-28 08:23:11 -07:00
committed by GitHub
parent 130b72927c
commit 2e257d9707
158 changed files with 624 additions and 1011 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/architecture/master-node-communication.md
+12 -17
View File
@@ -4,11 +4,6 @@ assignees:
- roberthbailey
- liggitt
title: Master-Node communication
redirect_from:
- "/docs/admin/master-node-communication/"
- "/docs/admin/master-node-communication.html"
- "/docs/concepts/cluster-administration/master-node-communication/"
- "/docs/concepts/cluster-administration/master-node-communication.html"
---
* TOC
@@ -30,18 +25,18 @@ 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/admin/authentication/) enabled. One or more forms
of [authorization](/docs/admin/authorization/) should be enabled, especially
if [anonymous requests](/docs/admin/authentication/#anonymous-requests) or
[service account tokens](/docs/admin/authentication/#service-account-tokens)
if [anonymous requests](/docs/admin/authentication/#anonymous-requests) or
[service account tokens](/docs/admin/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 GCE deployment, the client credentials
provided to the kubelet are in the form of a client certificate. See
[kubelet TLS bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) for
automated provisioning of kubelet client certificates.
provided to the kubelet are in the form of a client certificate. See
[kubelet TLS bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) for
automated provisioning of kubelet client certificates.
Pods that wish to connect to the apiserver can do so securely by leveraging a
Pods that wish to connect to the apiserver can do so securely by leveraging a
service account so that Kubernetes will automatically inject the public root
certificate and a valid bearer token into the pod when it is instantiated.
The `kubernetes` service (in all namespaces) is configured with a virtual IP
@@ -71,23 +66,23 @@ or service through the apiserver's proxy functionality.
The connections from the apiserver to the kubelet are used for fetching logs
for pods, attaching (through kubectl) to running pods, and using the kubelet's
port-forwarding functionality. These connections terminate at the kubelet's
port-forwarding functionality. These connections terminate at the kubelet's
HTTPS endpoint.
By default, the apiserver does not verify the kubelet's serving certificate,
which makes the connection subject to man-in-the-middle attacks, and
which makes the connection subject to man-in-the-middle attacks, and
**unsafe** to run over untrusted and/or public networks.
To verify this connection, use the `--kubelet-certificate-authority` flag to
provide the apiserver with a root certificates bundle to use to verify the
To verify this connection, use the `--kubelet-certificate-authority` flag to
provide the apiserver with a root certificates bundle to use to verify the
kubelet's serving certificate.
If that is not possible, use [SSH tunneling](/docs/admin/master-node-communication/#ssh-tunnels)
between the apiserver and kubelet if required to avoid connecting over an
between the apiserver and kubelet if required to avoid connecting over an
untrusted or public network.
Finally, [Kubelet authentication and/or authorization](/docs/admin/kubelet-authentication-authorization/)
should be enabled to secure the kubelet API.
should be enabled to secure the kubelet API.
### apiserver -> nodes, pods, and services
docs/concepts/architecture/nodes.md
+1 -6
View File
@@ -3,11 +3,6 @@ assignees:
- caesarxuchao
- dchen1107
title: Nodes
redirect_from:
- "/docs/admin/node/"
- "/docs/admin/node.html"
- "/docs/concepts/nodes/node/"
- "/docs/concepts/nodes/node.html"
---
* TOC
@@ -68,7 +63,7 @@ The node condition is represented as a JSON object. For example, the following r
]
```
If the Status of the Ready condition is "Unknown" or "False" for longer than the `pod-eviction-timeout`, an argument passed to the [kube-controller-manager](/docs/admin/kube-controller-manager/), all of the Pods on the node are scheduled for deletion by the Node Controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on it. The decision to delete the pods cannot be communicated to the kubelet until it re-establishes communication with the apiserver. In the meantime, the pods which are scheduled for deletion may continue to run on the partitioned node.
If the Status of the Ready condition is "Unknown" or "False" for longer than the `pod-eviction-timeout`, an argument passed to the [kube-controller-manager](/docs/admin/kube-controller-manager/), all of the Pods on the node are scheduled for deletion by the Node Controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on it. The decision to delete the pods cannot be communicated to the kubelet until it re-establishes communication with the apiserver. In the meantime, the pods which are scheduled for deletion may continue to run on the partitioned node.
In versions of Kubernetes prior to 1.5, the node controller would [force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) these unreachable pods from the apiserver. However, in 1.5 and higher, the node controller does not force delete pods until it is confirmed that they have stopped running in the cluster. One can see these pods which may be running on an unreachable node as being in the "Terminating" or "Unknown" states. In cases where Kubernetes cannot deduce from the underlying infrastructure if a node has permanently left a cluster, the cluster administrator may need to delete the node object by hand. Deleting the node object from Kubernetes causes all the Pod objects running on it to be deleted from the apiserver, freeing up their names.
docs/concepts/cluster-administration/addons.md
-3
View File
@@ -1,8 +1,5 @@
---
title: Installing Addons
redirect_from:
- "/docs/admin/addons/"
- "/docs/admin/addons.html"
---
## Overview
docs/concepts/cluster-administration/cluster-administration-overview.md
-5
View File
@@ -3,11 +3,6 @@ assignees:
- davidopp
- lavalamp
title: Cluster Administration Overview
redirect_from:
- "/docs/admin/"
- "/docs/admin/index.html"
- "/docs/tasks/administer-cluster/overview/"
- "/docs/tasks/administer-cluster/overview.html"
---
{% capture overview %}
docs/concepts/cluster-administration/federation.md
+1 -8
View File
@@ -1,12 +1,5 @@
---
title: Federation
redirect_from:
- "/docs/user-guide/federation/"
- "/docs/user-guide/federation/index.html"
- "/docs/concepts/cluster-administration/multiple-clusters/"
- "/docs/concepts/cluster-administration/multiple-clusters.html"
- "/docs/admin/multi-cluster/"
- "/docs/admin/multi-cluster.html"
---
{% capture overview %}
@@ -48,7 +41,7 @@ why you might want multiple clusters are:
* [Hybrid cloud](###hybrid-cloud-capabilities): You can have multiple clusters on different cloud providers or
on-premises data centers.
### Caveats
### Caveats
While there are a lot of attractive use cases for federation, there are also
some caveats:
docs/concepts/cluster-administration/kubelet-garbage-collection.md
-3
View File
@@ -2,9 +2,6 @@
assignees:
- mikedanese
title: Configuring kubelet Garbage Collection
redirect_from:
- "/docs/admin/garbage-collection/"
- "/docs/admin/garbage-collection.html"
---
* TOC
docs/concepts/cluster-administration/logging.md
-6
View File
@@ -3,12 +3,6 @@ assignees:
- crassirostris
- piosz
title: Logging Architecture
redirect_from:
- "/docs/concepts/clusters/logging/"
- "/docs/concepts/clusters/logging.html"
redirect_from:
- "/docs/user-guide/logging/overview/"
- "/docs/user-guide/logging/overview.html"
---
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.
docs/concepts/cluster-administration/manage-deployment.md
-3
View File
@@ -4,9 +4,6 @@ assignees:
- janetkuo
- mikedanese
title: Managing Resources
redirect_from:
- "/docs/user-guide/managing-deployments/"
- "/docs/user-guide/managing-deployments.html"
---
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 we'll discuss in more depth are [configuration files](/docs/user-guide/configuring-containers/#configuration-in-kubernetes) and [labels](/docs/user-guide/deploying-applications/#labels).
docs/concepts/cluster-administration/network-plugins.md
-3
View File
@@ -4,9 +4,6 @@ assignees:
- freehan
- thockin
title: Network Plugins
redirect_from:
- "/docs/admin/network-plugins/"
- "/docs/admin/network-plugins.html"
---
* TOC
docs/concepts/cluster-administration/networking.md
+4 -7
View File
@@ -2,9 +2,6 @@
assignees:
- thockin
title: Cluster Networking
redirect_from:
- "/docs/admin/networking/"
- "/docs/admin/networking.html"
---
Kubernetes approaches networking somewhat differently than Docker does by
@@ -85,7 +82,7 @@ talk to other VMs in your project. This is the same basic model.
Until now this document has talked about containers. In reality, Kubernetes
applies IP addresses at the `Pod` scope - containers within a `Pod` share their
network namespaces - including their IP address. This means that containers
within a `Pod` can all reach each other's ports on `localhost`. This does imply
within a `Pod` can all reach each other's ports on `localhost`. This does imply
that containers within a `Pod` must coordinate port usage, but this is no
different than processes in a VM. We call this the "IP-per-pod" model. This
is implemented in Docker as a "pod container" which holds the network namespace
@@ -217,9 +214,9 @@ Calico can also be run in policy enforcement mode in conjunction with other netw
### Weave Net from Weaveworks
[Weave Net](https://www.weave.works/products/weave-net/) is a
resilient and simple to use network for Kubernetes and its hosted applications.
Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-plugin/)
[Weave Net](https://www.weave.works/products/weave-net/) is a
resilient and simple to use network for Kubernetes and its hosted applications.
Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-plugin/)
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.
docs/concepts/cluster-administration/proxies.md
-3
View File
@@ -1,8 +1,5 @@
---
title: Proxies in Kubernetes
redirect_from:
- "/docs/user-guide/accessing-the-cluster/"
- "/docs/user-guide/accessing-the-cluster.html"
---
{% capture overview %}
docs/concepts/cluster-administration/sysctl-cluster.md
-3
View File
@@ -2,9 +2,6 @@
assignees:
- sttts
title: Using Sysctls in a Kubernetes Cluster
redirect_from:
- "/docs/admin/sysctls/"
- "/docs/admin/sysctls.html"
---
* TOC
docs/concepts/configuration/assign-pod-node.md
+7 -10
View File
@@ -4,9 +4,6 @@ assignees:
- kevin-wangzefeng
- bsalamat
title: Assigning Pods to Nodes
redirect_from:
- "/docs/user-guide/node-selection/"
- "/docs/user-guide/node-selection/index.html"
---
You can constrain a [pod](/docs/concepts/workloads/pods/pod/) to only be able to run on particular [nodes](/docs/concepts/nodes/node/) or to prefer to
@@ -205,7 +202,7 @@ If omitted, it defaults to the namespace of the pod where the affinity/anti-affi
If defined but empty, it means "all namespaces."
All `matchExpressions` associated with `requiredDuringSchedulingIgnoredDuringExecution` affinity and anti-affinity
must be satisfied for the pod to schedule onto a node.
must be satisfied for the pod to schedule onto a node.
For more information on inter-pod affinity/anti-affinity, see the design doc
[here](https://git.k8s.io/community/contributors/design-proposals/podaffinity.md).
@@ -236,7 +233,7 @@ taint created by the `kubectl taint` line above, and thus a pod with either tole
to schedule onto `node1`:
```yaml
tolerations:
tolerations:
- key: "key"
operator: "Equal"
value: "value"
@@ -244,7 +241,7 @@ tolerations:
```
```yaml
tolerations:
tolerations:
- key: "key"
operator: "Exists"
effect: "NoSchedule"
@@ -304,7 +301,7 @@ kubectl taint nodes node1 key2=value2:NoSchedule
And a pod has two tolerations:
```yaml
tolerations:
tolerations:
- key: "key1"
operator: "Equal"
value: "value1"
@@ -327,7 +324,7 @@ an optional `tolerationSeconds` field that dictates how long the pod will stay b
to the node after the taint is added. For example,
```yaml
tolerations:
tolerations:
- key: "key1"
operator: "Equal"
value: "value1"
@@ -345,7 +342,7 @@ Taints and tolerations are a flexible way to steer pods away from nodes or evict
pods that shouldn't be running. A few of the use cases are
* **dedicated nodes**: If you want to dedicate a set of nodes for exclusive use by
a particular set of users, you can add a taint to those nodes (say,
a particular set of users, you can add a taint to those nodes (say,
`kubectl taint nodes nodename dedicated=groupName:NoSchedule`) and then add a corresponding
toleration to their pods (this would be done most easily by writing a custom
[admission controller](/docs/admin/admission-controllers/)).
@@ -410,7 +407,7 @@ that the partition will recover and thus the pod eviction can be avoided.
The toleration the pod would use in that case would look like
```yaml
tolerations:
tolerations:
- key: "node.alpha.kubernetes.io/unreachable"
operator: "Exists"
effect: "NoExecute"
docs/concepts/configuration/manage-compute-resources-container.md
-3
View File
@@ -1,8 +1,5 @@
---
title: Managing Compute Resources for Containers
redirect_from:
- "/docs/user-guide/compute-resources/"
- "/docs/user-guide/compute-resources.html"
---
{% capture overview %}
docs/concepts/configuration/overview.md
-3
View File
@@ -2,9 +2,6 @@
assignees:
- mikedanese
title: Configuration Best Practices
redirect_from:
- "/docs/user-guide/config-best-practices/"
- "/docs/user-guide/config-best-practices.html"
---
{% capture overview %}
docs/concepts/configuration/secret.md
-3
View File
@@ -2,9 +2,6 @@
assignees:
- mikedanese
title: Secrets
redirect_from:
- "/docs/user-guide/secrets/index/"
- "/docs/user-guide/secrets/index.html"
---
Objects of type `secret` are intended to hold sensitive information, such as
docs/concepts/containers/container-lifecycle-hooks.md
+11 -14
View File
@@ -3,15 +3,12 @@ assignees:
- mikedanese
- thockin
title: Container Lifecycle Hooks
redirect_from:
- "/docs/user-guide/container-environment/"
- "/docs/user-guide/container-environment.html"
---
{% 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.
to run code triggered by events during their management lifecycle.
{% endcapture %}
@@ -34,14 +31,14 @@ There are two hooks that are exposed to Containers:
This hook executes immediately after a container is created.
However, there is no guarantee that the hook will execute before the container ENTRYPOINT.
No parameters are passed to the handler.
No parameters are passed to the handler.
`PreStop`
This hook is called immediately before a container is terminated.
It is blocking, meaning it is synchronous,
so it must complete before the call to delete the container can be sent.
No parameters are passed to the handler.
so it must complete before the call to delete the container can be sent.
No parameters are passed to the handler.
A more detailed description of the termination behavior can be found in
[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods).
@@ -58,13 +55,13 @@ Resources consumed by the command are counted against the Container.
### Hook handler execution
When a Container lifecycle management hook is called,
the Kubernetes management system executes the handler in the Container registered for that hook. 
the Kubernetes management system executes the handler in the Container registered for that hook. 
Hook handler calls are synchronous within the context of the Pod containing the Container.
This means that for a `PostStart` hook,
the Container ENTRYPOINT and hook fire asynchronously.
However, if the hook takes too long to run or hangs,
the Container cannot reach a `running` state.
the Container cannot reach a `running` state.
The behavior is similar for a `PreStop` hook.
If the hook hangs during execution,
@@ -87,16 +84,16 @@ Generally, only single deliveries are made.
If, for example, an HTTP hook receiver is down and is unable to take traffic,
there is no attempt to resend.
In some rare cases, however, double delivery may occur.
For instance, if a kubelet restarts in the middle of sending a hook,
For instance, if a kubelet restarts in the middle of sending a hook,
the hook might be resent after the kubelet comes back up.
### Debugging Hook handlers
The logs for a Hook handler are not exposed in Pod events.
If a handler fails for some reason, it broadcasts an event.
For `PostStart`, this is the `FailedPostStartHook` event,
and for `PreStop`, this is the `FailedPreStopHook` event.
You can see these events by running `kubectl describe pod <pod_name>`.
For `PostStart`, this is the `FailedPostStartHook` event,
and for `PreStop`, this is the `FailedPreStopHook` event.
You can see these events by running `kubectl describe pod <pod_name>`.
Here is some example output of events from running this command:
```
@@ -111,7 +108,7 @@ Events:
38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
```
{% endcapture %}
docs/concepts/containers/images.md
+1 -4
View File
@@ -3,9 +3,6 @@ assignees:
- erictune
- thockin
title: Images
redirect_from:
- "/docs/user-guide/images/"
- "/docs/user-guide/images.html"
---
{% capture overview %}
@@ -83,7 +80,7 @@ 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:GetAuthorizationToken`
- `ecr:BatchCheckLayerAvailability`
- `ecr:GetDownloadUrlForLayer`
- `ecr:GetRepositoryPolicy`
docs/concepts/overview/components.md
+7 -9
View File
@@ -2,10 +2,8 @@
assignees:
- lavalamp
title: Kubernetes Components
redirect_from:
- "/docs/admin/cluster-components/"
- "/docs/admin/cluster-components.html"
---
{% capture overview %}
This document outlines the various binary components needed to
deliver a functioning Kubernetes cluster.
@@ -15,7 +13,7 @@ deliver a functioning Kubernetes cluster.
## Master Components
Master components provide the cluster's control plane. Master components make global decisions about the
cluster (for example, scheduling), and detecting and responding to cluster events (starting up a new pod when a replication controller's 'replicas' field is unsatisfied).
cluster (for example, scheduling), and detecting and responding to cluster events (starting up a new pod when a replication controller's 'replicas' field is unsatisfied).
Master components can be run on any node in the cluster. However,
for simplicity, set up scripts typically start all master components on
@@ -28,7 +26,7 @@ Kubernetes control plane. It is designed to scale horizontally -- that is, it sc
### etcd
[etcd](/docs/admin/etcd) is used as Kubernetes' backing store. All cluster data is stored here. Always have a backup plan for etcd's data for your Kubernetes cluster.
[etcd](/docs/admin/etcd) is used as Kubernetes' backing store. All cluster data is stored here. Always have a backup plan for etcd's data for your Kubernetes cluster.
### kube-controller-manager
@@ -41,12 +39,12 @@ These controllers include:
controller object in the system.
* Endpoints Controller: Populates the Endpoints object (that is, joins Services & Pods).
* Service Account & Token Controllers: Create default accounts and API access tokens for new namespaces.
### cloud-controller-manager
cloud-controller-manager runs controllers that interact with the underlying cloud providers. The cloud-controller-manager binary is an alpha feature introduced in Kubernetes release 1.6.
cloud-controller-manager runs controllers that interact with the underlying cloud providers. The cloud-controller-manager binary is an alpha feature introduced in Kubernetes release 1.6.
cloud-controller-manager runs cloud-provider-specific controller loops only. You must disable these controller loops in the kube-controller-manager. You can disable the controller loops by setting the `--cloud-provider` flag to `external` when starting the kube-controller-manager.
cloud-controller-manager runs cloud-provider-specific controller loops only. You must disable these controller loops in the kube-controller-manager. You can disable the controller loops by setting the `--cloud-provider` flag to `external` when starting the kube-controller-manager.
cloud-controller-manager allows cloud vendors code and the Kubernetes core to evolve independent of each other. In prior releases, the core Kubernetes code was dependent upon cloud-provider-specific code for functionality. In future releases, code specific to cloud vendors should be maintained by the cloud vendor themselves, and linked to cloud-controller-manager while running Kubernetes.
@@ -55,7 +53,7 @@ The following controllers have cloud provider dependencies:
* Node Controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding
* Route Controller: For setting up routes in the underlying cloud infrastructure
* Service Controller: For creating, updating and deleting cloud provider load balancers
* Volume Controller: For creating, attaching, and mounting volumes, and interacting with the cloud provider to orchestrate volumes
* Volume Controller: For creating, attaching, and mounting volumes, and interacting with the cloud provider to orchestrate volumes
### kube-scheduler
docs/concepts/overview/kubernetes-api.md
-3
View File
@@ -2,9 +2,6 @@
assignees:
- chenopis
title: The Kubernetes API
redirect_from:
- "/docs/api/"
- "/docs/api.html"
---
Overall API conventions are described in the [API conventions doc](https://git.k8s.io/community/contributors/devel/api-conventions.md).
docs/concepts/overview/what-is-kubernetes.md
+2 -4
View File
@@ -3,10 +3,8 @@ assignees:
- bgrant0607
- mikedanese
title: What is Kubernetes?
redirect_from:
- "/docs/whatisk8s/"
- "/docs/whatisk8s.html"
---
{% capture overview %}
This page is an overview of Kubernetes.
{% endcapture %}
@@ -19,7 +17,7 @@ With Kubernetes, you are able to quickly and efficiently respond to customer dem
- Deploy your applications quickly and predictably.
- Scale your applications on the fly.
- Roll out new features seamlessly.
- Limit hardware usage to required resources only.
- Limit hardware usage to required resources only.
Our goal is to foster an ecosystem of components and tools that relieve the burden of running applications in public and private clouds.
docs/concepts/overview/working-with-objects/annotations.md
-3
View File
@@ -1,8 +1,5 @@
---
title: Annotations
redirect_from:
- "/docs/user-guide/annotations/"
- "/docs/user-guide/annotations.html"
---
{% capture overview %}
docs/concepts/overview/working-with-objects/kubernetes-objects.md
-4
View File
@@ -1,9 +1,5 @@
---
title: Understanding Kubernetes Objects
redirect_from:
- "/docs/concepts/abstractions/overview/"
- "/docs/concepts/abstractions/overview.html"
---
{% capture overview %}
docs/concepts/overview/working-with-objects/labels.md
+1 -4
View File
@@ -2,9 +2,6 @@
assignees:
- mikedanese
title: Labels and Selectors
redirect_from:
- "/docs/user-guide/labels/"
- "/docs/user-guide/labels.html"
---
_Labels_ are key/value pairs that are attached to objects, such as pods.
@@ -60,7 +57,7 @@ An empty label selector (that is, one with zero requirements) selects every obje
A null label selector (which is only possible for optional selector fields) selects no objects.
**Note**: the label selectors of two controllers must not overlap within a namespace, otherwise they will fight with each other.
**Note**: the label selectors of two controllers must not overlap within a namespace, otherwise they will fight with each other.
### _Equality-based_ requirement
docs/concepts/overview/working-with-objects/names.md
-3
View File
@@ -3,9 +3,6 @@ assignees:
- mikedanese
- thockin
title: Names
redirect_from:
- "/docs/user-guide/identifiers/"
- "/docs/user-guide/identifiers.html"
---
All objects in the Kubernetes REST API are unambiguously identified by a Name and a UID.
docs/concepts/overview/working-with-objects/namespaces.md
-3
View File
@@ -4,9 +4,6 @@ assignees:
- mikedanese
- thockin
title: Namespaces
redirect_from:
- "/docs/user-guide/namespaces/"
- "/docs/user-guide/namespaces.html"
---
Kubernetes supports multiple virtual clusters backed by the same physical cluster.
docs/concepts/policy/pod-security-policy.md
+17 -20
View File
@@ -2,13 +2,10 @@
assignees:
- pweil-
title: Pod Security Policies
redirect_from:
- "/docs/user-guide/pod-security-policy/"
- "/docs/user-guide/pod-security-policy/index.html"
---
Objects of type `PodSecurityPolicy` govern the ability
to make requests on a pod that affect the `SecurityContext` that will be
to make requests on a pod that affect the `SecurityContext` that will be
applied to a pod and container.
See [PodSecurityPolicy proposal](https://git.k8s.io/community/contributors/design-proposals/security-context-constraints.md) for more information.
@@ -18,10 +15,10 @@ See [PodSecurityPolicy proposal](https://git.k8s.io/community/contributors/desig
## What is a Pod Security Policy?
A _Pod Security Policy_ is a cluster-level resource that controls the
A _Pod Security Policy_ is a cluster-level resource that controls the
actions that a pod can perform and what it has the ability to access. The
`PodSecurityPolicy` objects define a set of conditions that a pod must
run with in order to be accepted into the system. They allow an
`PodSecurityPolicy` objects define a set of conditions that a pod must
run with in order to be accepted into the system. They allow an
administrator to control the following:
| Control Aspect | Field Name |
@@ -41,16 +38,16 @@ administrator to control the following:
| Allocating an FSGroup that owns the pod's volumes | [`fsGroup`](#fsgroup) |
| Requiring the use of a read only root file system | `readOnlyRootFilesystem` |
_Pod Security Policies_ are comprised of settings and strategies that
control the security features a pod has access to. These settings fall
_Pod Security Policies_ are comprised of settings and strategies that
control the security features a pod has access to. These settings fall
into three categories:
- *Controlled by a boolean*: Fields of this type default to the most
restrictive value.
- *Controlled by an allowable set*: Fields of this type are checked
- *Controlled by a boolean*: Fields of this type default to the most
restrictive value.
- *Controlled by an allowable set*: Fields of this type are checked
against the set to ensure their value is allowed.
- *Controlled by a strategy*: Items that have a strategy to provide
a mechanism to generate the value and a mechanism to ensure that a
a mechanism to generate the value and a mechanism to ensure that a
specified value falls into the set of allowable values.
@@ -75,22 +72,22 @@ specified.
### SupplementalGroups
- *MustRunAs* - Requires at least one range to be specified. Uses the
- *MustRunAs* - Requires at least one range to be specified. Uses the
minimum value of the first range as the default. Validates against all ranges.
- *RunAsAny* - No default provided. Allows any `supplementalGroups` to be
specified.
### FSGroup
- *MustRunAs* - Requires at least one range to be specified. Uses the
minimum value of the first range as the default. Validates against the
- *MustRunAs* - Requires at least one range to be specified. Uses the
minimum value of the first range as the default. Validates against the
first ID in the first range.
- *RunAsAny* - No default provided. Allows any `fsGroup` ID to be specified.
### Controlling Volumes
The usage of specific volume types can be controlled by setting the
volumes field of the PSP. The allowable values of this field correspond
The usage of specific volume types can be controlled by setting the
volumes field of the PSP. The allowable values of this field correspond
to the volume sources that are defined when creating a volume:
1. azureFile
@@ -122,7 +119,7 @@ to the volume sources that are defined when creating a volume:
1. storageos
1. \* (allow all volumes)
The recommended minimum set of allowed volumes for new PSPs are
The recommended minimum set of allowed volumes for new PSPs are
configMap, downwardAPI, emptyDir, persistentVolumeClaim, secret, and projected.
### Host Network
@@ -193,7 +190,7 @@ podsecuritypolicy "permissive" deleted
## Enabling Pod Security Policies
In order to use Pod Security Policies in your cluster you must ensure the
In order to use Pod Security Policies in your cluster you must ensure the
following
1. You have enabled the api type `extensions/v1beta1/podsecuritypolicy` (only for versions prior 1.6)
docs/concepts/policy/resource-quotas.md
+2 -5
View File
@@ -2,9 +2,6 @@
assignees:
- derekwaynecarr
title: Resource Quotas
redirect_from:
- "/docs/admin/resourcequota/"
- "/docs/admin/resourcequota/index.html"
---
When several users or teams share a cluster with a fixed number of nodes,
@@ -56,7 +53,7 @@ Resource Quota is enforced in a particular namespace when there is a
## Compute Resource Quota
You can limit the total sum of [compute resources](/docs/user-guide/compute-resources) that can be requested in a given namespace.
The following resource types are supported:
| Resource Name | Description |
@@ -70,7 +67,7 @@ The following resource types are supported:
## Storage Resource Quota
You can limit the total sum of [storage resources](/docs/user-guide/persistent-volumes) that can be requested in a given namespace.
You can limit the total sum of [storage resources](/docs/user-guide/persistent-volumes) that can be requested in a given namespace.
In addition, you can limit consumption of storage resources based on associated storage-class.
docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
-3
View File
@@ -3,9 +3,6 @@ assignees:
- rickypai
- thockin
title: Adding entries to Pod /etc/hosts with HostAliases
redirect_from:
- "/docs/user-guide/add-entries-to-pod-etc-hosts-with-host-aliases/"
- "/docs/user-guide/add-entries-to-pod-etc-hosts-with-host-aliases.md"
---
* TOC
docs/concepts/services-networking/connect-applications-service.md
-3
View File
@@ -4,9 +4,6 @@ assignees:
- lavalamp
- thockin
title: Connecting Applications with Services
redirect_from:
- "/docs/user-guide/connecting-applications/"
- "/docs/user-guide/connecting-applications.html"
---
* TOC
docs/concepts/services-networking/dns-pod-service.md
+2 -5
View File
@@ -3,9 +3,6 @@ assignees:
- davidopp
- thockin
title: DNS Pods and Services
redirect_from:
- "/docs/admin/dns/"
- "/docs/admin/dns.html"
---
## Introduction
@@ -105,7 +102,7 @@ spec:
clusterIP: None
ports:
- name: foo # Actually, no port is needed.
port: 1234
port: 1234
targetPort: 1234
---
apiVersion: v1
@@ -142,7 +139,7 @@ spec:
```
If there exists a headless service in the same namespace as the pod and with the same name as the subdomain, the cluster's KubeDNS Server also returns an A record for the Pod's fully qualified hostname.
Given a Pod with the hostname set to "busybox-1" and the subdomain set to "default-subdomain", and a headless Service named "default-subdomain" in the same namespace, the pod will see it's own FQDN as "busybox-1.default-subdomain.my-namespace.svc.cluster.local". DNS serves an A record at that name, pointing to the Pod's IP. Both pods "busybox1" and "busybox2" can have their distinct A records.
Given a Pod with the hostname set to "busybox-1" and the subdomain set to "default-subdomain", and a headless Service named "default-subdomain" in the same namespace, the pod will see it's own FQDN as "busybox-1.default-subdomain.my-namespace.svc.cluster.local". DNS serves an A record at that name, pointing to the Pod's IP. Both pods "busybox1" and "busybox2" can have their distinct A records.
As of Kubernetes v1.2, the Endpoints object also has the annotation `endpoints.beta.kubernetes.io/hostnames-map`. Its value is the json representation of map[string(IP)][endpoints.HostRecord], for example: '{"10.245.1.6":{HostName: "my-webserver"}}'.
If the Endpoints are for a headless service, an A record is created with the format <hostname>.<service name>.<pod namespace>.svc.<cluster domain>
docs/concepts/services-networking/ingress.md
-3
View File
@@ -2,9 +2,6 @@
assignees:
- bprashanth
title: Ingress Resources
redirect_from:
- "/docs/user-guide/ingress/"
- "/docs/user-guide/ingress.html"
---
* TOC
docs/concepts/services-networking/network-policies.md
-3
View File
@@ -4,9 +4,6 @@ assignees:
- caseydavenport
- danwinship
title: Network Policies
redirect_from:
- "/docs/user-guide/networkpolicies/"
- "/docs/user-guide/networkpolicies.html"
---
* TOC
docs/concepts/services-networking/service.md
+13 -16
View File
@@ -2,9 +2,6 @@
assignees:
- bprashanth
title: Services
redirect_from:
- "/docs/user-guide/services/"
- "/docs/user-guide/services/index.html"
---
Kubernetes [`Pods`](/docs/user-guide/pods) are mortal. They are born and when they die, they
@@ -319,9 +316,9 @@ Sometimes you don't need or want load-balancing and a single service IP. In
this case, you can create "headless" services by specifying `"None"` for the
cluster IP (`spec.clusterIP`).
This option allows developers to reduce coupling to the Kubernetes system by
allowing them freedom to do discovery their own way. Applications can still use
a self-registration pattern and adapters for other discovery systems could easily
This option allows developers to reduce coupling to the Kubernetes system by
allowing them freedom to do discovery their own way. Applications can still use
a self-registration pattern and adapters for other discovery systems could easily
be built upon this API.
For such `Services`, a cluster IP is not allocated, kube-proxy does not handle
@@ -356,15 +353,15 @@ The default is `ClusterIP`.
`Type` values and their behaviors are:
* `ClusterIP`: Exposes the service on a cluster-internal IP. Choosing this value
makes the service only reachable from within the cluster. This is the
* `ClusterIP`: Exposes the service on a cluster-internal IP. Choosing this value
makes the service only reachable from within the cluster. This is the
default `ServiceType`.
* `NodePort`: Exposes the service on each Node's IP at a static port (the `NodePort`).
A `ClusterIP` service, to which the NodePort service will route, is automatically
created. You'll be able to contact the `NodePort` service, from outside the cluster,
* `NodePort`: Exposes the service on each Node's IP at a static port (the `NodePort`).
A `ClusterIP` service, to which the NodePort service will route, is automatically
created. You'll be able to contact the `NodePort` service, from outside the cluster,
by requesting `<NodeIP>:<NodePort>`.
* `LoadBalancer`: Exposes the service externally using a cloud provider's load balancer.
`NodePort` and `ClusterIP` services, to which the external load balancer will route,
* `LoadBalancer`: Exposes the service externally using a cloud provider's load balancer.
`NodePort` and `ClusterIP` services, to which the external load balancer will route,
are automatically created.
* `ExternalName`: Maps the service to the contents of the `externalName` field
(e.g. `foo.bar.example.com`), by returning a `CNAME` record with its value.
@@ -441,9 +438,9 @@ This can be achieved by adding the following annotations to the service based on
For AWS:
```yaml
[...]
metadata:
metadata:
name: my-service
annotations:
annotations:
service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0
[...]
```
@@ -516,7 +513,7 @@ spec:
protocol: TCP
port: 80
targetPort: 9376
externalIPs:
externalIPs:
- 80.11.12.10
```
docs/concepts/storage/persistent-volumes.md
+3 -6
View File
@@ -5,9 +5,6 @@ assignees:
- saad-ali
- thockin
title: Persistent Volumes
redirect_from:
- "/docs/user-guide/persistent-volumes/"
- "/docs/user-guide/persistent-volumes/index.html"
---
This document describes the current state of `PersistentVolumes` in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
@@ -265,7 +262,7 @@ spec:
pdName: "gce-disk-1"
```
A mount option is a string which will be cumulatively joined and used while mounting volume to the disk.
A mount option is a string which will be cumulatively joined and used while mounting volume to the disk.
Note that not all Persistent volume types support mount options. In Kubernetes version 1.6, the following
volume types support mount options.
@@ -734,7 +731,7 @@ parameters:
If storage account is not provided, all storage accounts associated with the resource group are searched to find one that matches `skuName` and `location`. If storage account is provided, it must reside in the same resource group as the cluster, and `skuName` and `location` are ignored.
During provision, a secret will be created for mounting credentials. If the cluster has enabled both [RBAC](/docs/admin/authorization/rbac/) and [Controller Roles](/docs/admin/authorization/rbac/#controller-roles), you will first need to add `create` permission of resource `secret` for clusterrole `system:controller:persistent-volume-binder`.
#### Portworx Volume
```yaml
@@ -786,7 +783,7 @@ parameters:
* `readOnly`: specifies the access mode to the mounted volume
* `fsType`: the file system to use for the volume
The ScaleIO Kubernetes volume plugin requires a configured Secret object.
The ScaleIO Kubernetes volume plugin requires a configured Secret object.
The secret must be created with type `kubernetes.io/scaleio` and use the same namespace value as that of the PVC where it is referenced
as shown in the following command:
docs/concepts/storage/volumes.md
+1 -4
View File
@@ -5,9 +5,6 @@ assignees:
- saad-ali
- thockin
title: Volumes
redirect_from:
- "/docs/user-guide/volumes/"
- "/docs/user-guide/volumes.html"
---
{% capture overview %}
@@ -788,7 +785,7 @@ spec:
Note that local PersistentVolume cleanup and deletion requires manual
intervention without the external provisioner.
For details on the `local` volume type, see the [Local Persistent Storage
For details on the `local` volume type, see the [Local Persistent Storage
user guide](https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume)
## Using subPath
docs/concepts/workloads/controllers/cron-jobs.md
-5
View File
@@ -4,11 +4,6 @@ assignees:
- soltysh
- janetkuo
title: Cron Jobs
redirect_from:
- "/docs/concepts/jobs/cron-jobs/"
- "/docs/concepts/jobs/cron-jobs.html"
- "/docs/user-guide/cron-jobs/"
- "/docs/user-guide/cron-jobs.html"
---
* TOC
docs/concepts/workloads/controllers/daemonset.md
+2 -5
View File
@@ -2,9 +2,6 @@
assignees:
- erictune
title: Daemon Sets
redirect_from:
- "/docs/admin/daemons/"
- "/docs/admin/daemons.html"
---
* TOC
@@ -77,7 +74,7 @@ a node for testing.
If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will
create pods on nodes which match that [node
selector](/docs/concepts/configuration/assign-pod-node/). Likewise if you specify a `.spec.template.spec.affinity`
selector](/docs/concepts/configuration/assign-pod-node/). Likewise if you specify a `.spec.template.spec.affinity`
then DaemonSet controller will create pods on nodes which match that [node affinity](/docs/concepts/configuration/assign-pod-node/).
If you do not specify either, then the DaemonSet controller will create pods on all nodes.
@@ -91,7 +88,7 @@ when the pod is created, so it is ignored by the scheduler). Therefore:
by the DaemonSet controller.
- DaemonSet controller can make pods even when the scheduler has not been started, which can help cluster
bootstrap.
Daemon pods do respect [taints and tolerations](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature), but they are
created with `NoExecute` tolerations for the `node.alpha.kubernetes.io/notReady` and `node.alpha.kubernetes.io/unreachable`
taints with no `tolerationSeconds`. This ensures that when the `TaintBasedEvictions` alpha feature is enabled,
docs/concepts/workloads/controllers/deployment.md
+5 -8
View File
@@ -3,9 +3,6 @@ assignees:
- bgrant0607
- janetkuo
title: Deployments
redirect_from:
- "/docs/user-guide/deployments/"
- "/docs/user-guide/deployments.html"
---
{:toc}
@@ -503,7 +500,7 @@ nginx-deployment-1989198191 7 7 0 7m
nginx-deployment-618515232 11 11 11 7m
```
## Pausing and Resuming a Deployment
## Pausing and Resuming a Deployment
You can pause a Deployment before triggering one or more updates and then resume it. This will allow you to
apply multiple fixes in between pausing and resuming without triggering unnecesarry rollouts.
@@ -549,7 +546,7 @@ deployment "nginx" resource requirements updated
```
The initial state of the Deployment prior to pausing it will continue its function, but new updates to
the Deployment will not have any effect as long as the Deployment is paused.
the Deployment will not have any effect as long as the Deployment is paused.
Eventually, resume the Deployment and observe a new ReplicaSet coming up with all the new updates:
```shell
@@ -754,13 +751,13 @@ to a previous revision, or even pause it if you need to apply multiple tweaks in
You can set `.spec.revisionHistoryLimit` field in a Deployment to specify how many old ReplicaSets for
this Deployment you want to retain. The rest will be garbage-collected in the background. By default,
all revision history will be kept. In a future version, it will default to switch to 2.
all revision history will be kept. In a future version, it will default to switch to 2.
**Note:** Explicitly setting this field to 0, will result in cleaning up all the history of your Deployment
thus that Deployment will not be able to roll back.
## Use Cases
## Use Cases
### Canary Deployment
@@ -900,7 +897,7 @@ ReplicaSets will be kept by default, consuming resources in `etcd` and crowding
if this field is not set. The configuration of each Deployment revision is stored in its ReplicaSets;
therefore, once an old ReplicaSet is deleted, you lose the ability to rollback to that revision of Deployment.
More specifically, setting this field to zero means that all old ReplicaSets with 0 replica will be cleaned up.
More specifically, setting this field to zero means that all old ReplicaSets with 0 replica will be cleaned up.
In this case, a new Deployment rollout cannot be undone, since its revision history is cleaned up.
### Paused
docs/concepts/workloads/controllers/garbage-collection.md
+6 -12
View File
@@ -1,11 +1,5 @@
---
title: Garbage Collection
redirect_from:
- "/docs/concepts/abstractions/controllers/garbage-collection/"
- "/docs/concepts/abstractions/controllers/garbage-collection.html"
- "/docs/user-guide/garbage-collection/"
- "/docs/user-guide/garbage-collection.html"
---
{% capture overview %}
@@ -70,15 +64,15 @@ metadata:
When you delete an object, you can specify whether the object's dependents are
also deleted automatically. Deleting dependents automatically is called *cascading
deletion*. There are two modes of *cascading deletion*: *background* and *foreground*.
deletion*. There are two modes of *cascading deletion*: *background* and *foreground*.
If you delete an object without deleting its dependents
automatically, the dependents are said to be *orphaned*.
automatically, the dependents are said to be *orphaned*.
### Background cascading deletion
In *background cascading deletion*, Kubernetes deletes the owner object
immediately and the garbage collector then deletes the dependents in
In *background cascading deletion*, Kubernetes deletes the owner object
immediately and the garbage collector then deletes the dependents in
the background.
### Foreground cascading deletion
@@ -90,7 +84,7 @@ the following things are true:
* The object is still visible via the REST API
* The object's `deletionTimestamp` is set
* The object's `metadata.finalizers` contains the value "foregroundDeletion".
Once the "deletion in progress" state is set, the garbage
collector deletes the object's dependents. Once the garbage collector has deleted all
"blocking" dependents (objects with `ownerReference.blockOwnerDeletion=true`), it delete
@@ -100,7 +94,7 @@ Note that in the "foregroundDeletion", only dependents with
`ownerReference.blockOwnerDeletion` block the deletion of the owner object.
Kubernetes version 1.7 will add an admission controller that controls user access to set
`blockOwnerDeletion` to true based on delete permissions on the owner object, so that
unauthorized dependents cannot delay deletion of an owner object.
unauthorized dependents cannot delay deletion of an owner object.
If an object's `ownerReferences` field is set by a controller (such as Deployment or ReplicaSet),
blockOwnerDeletion is set automatically and you do not need to manually modify this field.
docs/concepts/workloads/controllers/jobs-run-to-completion.md
-5
View File
@@ -3,11 +3,6 @@ assignees:
- erictune
- soltysh
title: Jobs - Run to Completion
redirect_from:
- "/docs/concepts/jobs/run-to-completion-finite-workloads/"
- "/docs/concepts/jobs/run-to-completion-finite-workloads.html"
- "/docs/user-guide/jobs/"
- "/docs/user-guide/jobs.html"
---
* TOC
docs/concepts/workloads/controllers/petset.md
-7
View File
@@ -8,13 +8,6 @@ assignees:
- kow3ns
- smarterclayton
title: PetSets
redirect_from:
- "/docs/concepts/abstractions/controllers/petsets/"
- "/docs/concepts/abstractions/controllers/petsets.html"
- "/docs/user-guide/petset/bootstrapping/"
- "/docs/user-guide/petset/bootstrapping/index.html"
- "/docs/user-guide/petset/"
- "/docs/user-guide/petset.html"
---
__Warning:__ Starting in Kubernetes version 1.5, PetSet has been renamed to [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets). To use (or continue to use) PetSet in Kubernetes 1.5, you _must_ [migrate](/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set/) your existing PetSets to StatefulSets. For information on working with StatefulSet, see the tutorial on [how to run replicated stateful applications](/docs/tutorials/stateful-application/run-replicated-stateful-application).
docs/concepts/workloads/controllers/replicaset.md
-3
View File
@@ -4,9 +4,6 @@ assignees:
- bprashanth
- madhusudancs
title: Replica Sets
redirect_from:
- "/docs/user-guide/replicasets/"
- "/docs/user-guide/replicasets.html"
---
* TOC
docs/concepts/workloads/controllers/replicationcontroller.md
+2 -5
View File
@@ -3,9 +3,6 @@ assignees:
- bprashanth
- janetkuo
title: Replication Controller
redirect_from:
- "/docs/user-guide/replication-controller/"
- "/docs/user-guide/replication-controller/index.html"
---
* TOC
@@ -194,7 +191,7 @@ Ideally, the rolling update controller would take application readiness into acc
The two ReplicationControllers would need to create pods with at least one differentiating label, such as the image tag of the primary container of the pod, since it is typically image updates that motivate rolling updates.
Rolling update is implemented in the client tool
[`kubectl rolling-update`](/docs/user-guide/kubectl/{{page.version}}/#rolling-update). Visit [`kubectl rolling-update` task](/docs/tasks/run-application/rolling-update-replication-controller/) for more concrete examples.
[`kubectl rolling-update`](/docs/user-guide/kubectl/{{page.version}}/#rolling-update). Visit [`kubectl rolling-update` task](/docs/tasks/run-application/rolling-update-replication-controller/) for more concrete examples.
### Multiple release tracks
@@ -240,7 +237,7 @@ Note that we recommend using Deployments instead of directly using Replica Sets,
### Deployment (Recommended)
[`Deployment`](/docs/concepts/workloads/controllers/deployment/) is a higher-level API object that updates its underlying Replica Sets and their Pods
in a similar fashion as `kubectl rolling-update`. Deployments are recommended if you want this rolling update functionality,
in a similar fashion as `kubectl rolling-update`. Deployments are recommended if you want this rolling update functionality,
because unlike `kubectl rolling-update`, they are declarative, server-side, and have additional features.
### Bare Pods
docs/concepts/workloads/controllers/statefulset.md
+65 -68
View File
@@ -7,14 +7,11 @@ assignees:
- kow3ns
- smarterclayton
title: StatefulSets
redirect_from:
- "/docs/concepts/abstractions/controllers/statefulsets/"
- "/docs/concepts/abstractions/controllers/statefulsets.html"
---
{% capture overview %}
**StatefulSets are a beta feature in 1.7. This feature replaces the
PetSets feature from 1.4. Users of PetSets are referred to the 1.5
**StatefulSets are a beta feature in 1.7. This feature replaces the
PetSets feature from 1.4. Users of PetSets are referred to the 1.5
[Upgrade Guide](/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set/)
for further information on how to upgrade existing PetSets to StatefulSets.**
@@ -26,7 +23,7 @@ guarantees about the ordering of deployment and scaling.
## Using StatefulSets
StatefulSets are valuable for applications that require one or more of the
StatefulSets are valuable for applications that require one or more of the
following.
* Stable, unique network identifiers.
@@ -36,10 +33,10 @@ following.
* Ordered, automated rolling updates.
In the above, stable is synonymous with persistence across Pod (re)scheduling.
If an application doesn't require any stable identifiers or ordered deployment,
deletion, or scaling, you should deploy your application with a controller that
provides a set of stateless replicas. Controllers such as
[Deployment](/docs/concepts/workloads/controllers/deployment/) or
If an application doesn't require any stable identifiers or ordered deployment,
deletion, or scaling, you should deploy your application with a controller that
provides a set of stateless replicas. Controllers such as
[Deployment](/docs/concepts/workloads/controllers/deployment/) or
[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) may be better suited to your stateless needs.
## Limitations
@@ -50,11 +47,11 @@ provides a set of stateless replicas. Controllers such as
* StatefulSets currently require a [Headless Service](/docs/concepts/services-networking/service/#headless-services) to be responsible for the network identity of the Pods. You are responsible for creating this Service.
## Components
The example below demonstrates the components of a StatefulSet.
The example below demonstrates the components of a StatefulSet.
* A Headless Service, named nginx, is used to control the network domain.
* A Headless Service, named nginx, is used to control the network domain.
* The StatefulSet, named web, has a Spec that indicates that 3 replicas of the nginx container will be launched in unique Pods.
* The volumeClaimTemplates will provide stable storage using [PersistentVolumes](/docs/concepts/storage/volumes/) provisioned by a
* The volumeClaimTemplates will provide stable storage using [PersistentVolumes](/docs/concepts/storage/volumes/) provisioned by a
PersistentVolume Provisioner.
```yaml
@@ -107,30 +104,30 @@ spec:
```
## Pod Identity
StatefulSet Pods have a unique identity that is comprised of an ordinal, a
stable network identity, and stable storage. The identity sticks to the Pod,
StatefulSet Pods have a unique identity that is comprised of an ordinal, a
stable network identity, and stable storage. The identity sticks to the Pod,
regardless of which node it's (re)scheduled on.
### Ordinal Index
For a StatefulSet with N replicas, each Pod in the StatefulSet will be
assigned an integer ordinal, in the range [0,N), that is unique over the Set.
For a StatefulSet with N replicas, each Pod in the StatefulSet will be
assigned an integer ordinal, in the range [0,N), that is unique over the Set.
### Stable Network ID
Each Pod in a StatefulSet derives its hostname from the name of the StatefulSet
and the ordinal of the Pod. The pattern for the constructed hostname
is `$(statefulset name)-$(ordinal)`. The example above will create three Pods
Each Pod in a StatefulSet derives its hostname from the name of the StatefulSet
and the ordinal of the Pod. The pattern for the constructed hostname
is `$(statefulset name)-$(ordinal)`. The example above will create three Pods
named `web-0,web-1,web-2`.
A StatefulSet can use a [Headless Service](/docs/concepts/services-networking/service/#headless-services)
to control the domain of its Pods. The domain managed by this Service takes the form:
`$(service name).$(namespace).svc.cluster.local`, where "cluster.local"
is the [cluster domain](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md).
As each Pod is created, it gets a matching DNS subdomain, taking the form:
`$(podname).$(governing service domain)`, where the governing service is defined
to control the domain of its Pods. The domain managed by this Service takes the form:
`$(service name).$(namespace).svc.cluster.local`, where "cluster.local"
is the [cluster domain](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md).
As each Pod is created, it gets a matching DNS subdomain, taking the form:
`$(podname).$(governing service domain)`, where the governing service is defined
by the `serviceName` field on the StatefulSet.
Here are some examples of choices for Cluster Domain, Service name,
Here are some examples of choices for Cluster Domain, Service name,
StatefulSet name, and how that affects the DNS names for the StatefulSet's Pods.
Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain | Pod DNS | Pod Hostname |
@@ -139,96 +136,96 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain
cluster.local | foo/nginx | foo/web | nginx.foo.svc.cluster.local | web-{0..N-1}.nginx.foo.svc.cluster.local | web-{0..N-1} |
kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} |
Note that Cluster Domain will be set to `cluster.local` unless
Note that Cluster Domain will be set to `cluster.local` unless
[otherwise configured](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md).
### Stable Storage
Kubernetes creates one [PersistentVolume](/docs/concepts/storage/volumes/) for each
VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume
with a storage class of `anything` and 1 Gib of provisioned storage. When a Pod is (re)scheduled
onto a node, its `volumeMounts` mount the PersistentVolumes associated with its
PersistentVolume Claims. Note that, the PersistentVolumes associated with the
Pods' PersistentVolume Claims are not deleted when the Pods, or StatefulSet are deleted.
Kubernetes creates one [PersistentVolume](/docs/concepts/storage/volumes/) for each
VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume
with a storage class of `anything` and 1 Gib of provisioned storage. When a Pod is (re)scheduled
onto a node, its `volumeMounts` mount the PersistentVolumes associated with its
PersistentVolume Claims. Note that, the PersistentVolumes associated with the
Pods' PersistentVolume Claims are not deleted when the Pods, or StatefulSet are deleted.
This must be done manually.
## Deployment and Scaling Guarantees
* For a StatefulSet with N replicas, when Pods are being deployed, they are created sequentially, in order from {0..N-1}.
* For a StatefulSet with N replicas, when Pods are being deployed, they are created sequentially, in order from {0..N-1}.
* When Pods are being deleted, they are terminated in reverse order, from {N-1..0}.
* Before a scaling operation is applied to a Pod, all of its predecessors must be Running and Ready.
* Before a scaling operation is applied to a Pod, all of its predecessors must be Running and Ready.
* Before a Pod is terminated, all of its successors must be completely shutdown.
The StatefulSet should not specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. This practice is unsafe and strongly discouraged. For further explanation, please refer to [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/).
When the nginx example above is created, three Pods will be deployed in the order
web-0, web-1, web-2. web-1 will not be deployed before web-0 is
[Running and Ready](/docs/user-guide/pod-states), and web-2 will not be deployed until
web-1 is Running and Ready. If web-0 should fail, after web-1 is Running and Ready, but before
web-2 is launched, web-2 will not be launched until web-0 is successfully relaunched and
becomes Running and Ready.
When the nginx example above is created, three Pods will be deployed in the order
web-0, web-1, web-2. web-1 will not be deployed before web-0 is
[Running and Ready](/docs/user-guide/pod-states), and web-2 will not be deployed until
web-1 is Running and Ready. If web-0 should fail, after web-1 is Running and Ready, but before
web-2 is launched, web-2 will not be launched until web-0 is successfully relaunched and
becomes Running and Ready.
If a user were to scale the deployed example by patching the StatefulSet such that
`replicas=1`, web-2 would be terminated first. web-1 would not be terminated until web-2
is fully shutdown and deleted. If web-0 were to fail after web-2 has been terminated and
is completely shutdown, but prior to web-1's termination, web-1 would not be terminated
`replicas=1`, web-2 would be terminated first. web-1 would not be terminated until web-2
is fully shutdown and deleted. If web-0 were to fail after web-2 has been terminated and
is completely shutdown, but prior to web-1's termination, web-1 would not be terminated
until web-0 is Running and Ready.
### Pod Management Policies
In Kubernetes 1.7 and later, StatefulSet allows you to relax its ordering guarantees while
In Kubernetes 1.7 and later, StatefulSet allows you to relax its ordering guarantees while
preserving its uniqueness and identity guarantees via its `.spec.podManagementPolicy` field.
#### OrderedReady Pod Management
`OrderedReady` pod management is the default for StatefulSets. It implements the behavior
`OrderedReady` pod management is the default for StatefulSets. It implements the behavior
described [above](#deployment-and-scaling-guarantees).
#### Parallel Pod Management
`Parallel` pod management tells the StatefulSet controller to launch or
terminate all Pods in parallel, and to not wait for Pods to become Running
and Ready or completely terminated prior to launching or terminating another
`Parallel` pod management tells the StatefulSet controller to launch or
terminate all Pods in parallel, and to not wait for Pods to become Running
and Ready or completely terminated prior to launching or terminating another
Pod.
## Update Strategies
In Kuberentes 1.7 and later, StatefulSet's `.spec.updateStrategy` field allows you to configure
and disable automated rolling updates for containers, labels, resource request/limits, and
In Kuberentes 1.7 and later, StatefulSet's `.spec.updateStrategy` field allows you to configure
and disable automated rolling updates for containers, labels, resource request/limits, and
annotations for the Pods in a StatefulSet.
### On Delete
The `OnDelete` update strategy implements the legacy (1.6 and prior) behavior. It is the default
strategy when `spec.updateStrategy` is left unspecified. When a StatefulSet's
`.spec.updateStrategy.type` is set to `OnDelete`, the StatefulSet controller will not automatically
update the Pods in a StatefulSet. Users must manually delete Pods to cause the controller to
The `OnDelete` update strategy implements the legacy (1.6 and prior) behavior. It is the default
strategy when `spec.updateStrategy` is left unspecified. When a StatefulSet's
`.spec.updateStrategy.type` is set to `OnDelete`, the StatefulSet controller will not automatically
update the Pods in a StatefulSet. Users must manually delete Pods to cause the controller to
create new Pods that reflect modifications made to a StatefulSet's `.spec.template`.
### Rolling Updates
The `RollingUpdate` update strategy implements automated, rolling update for the Pods in a
StatefulSet. When a StatefulSet's `.spec.updateStrategy.type` is set to `RollingUpdate`, the
StatefulSet controller will delete and recreate each Pod in the StatefulSet. It will proceed
in the same order as Pod termination (from the largest ordinal to the smallest), updating
each Pod one at a time. It will wait until an updated Pod is Running and Ready prior to
The `RollingUpdate` update strategy implements automated, rolling update for the Pods in a
StatefulSet. When a StatefulSet's `.spec.updateStrategy.type` is set to `RollingUpdate`, the
StatefulSet controller will delete and recreate each Pod in the StatefulSet. It will proceed
in the same order as Pod termination (from the largest ordinal to the smallest), updating
each Pod one at a time. It will wait until an updated Pod is Running and Ready prior to
updating its predecessor.
#### Partitions
The `RollingUpdate` update strategy can be partitioned, by specifying a
`.spec.updateStrategy.rollingUpdate.partition`. If a partition is specified, all Pods with an
ordinal that is greater than or equal to the partition will be updated when the StatefulSet's
`.spec.template` is updated. All Pods with an ordinal that is less than the partition will not
be updated, and, even if they are deleted, they will be recreated at the previous version. If a
StatefulSet's `.spec.updateStrategy.rollingUpdate.partition` is greater than its `.spec.replicas`,
The `RollingUpdate` update strategy can be partitioned, by specifying a
`.spec.updateStrategy.rollingUpdate.partition`. If a partition is specified, all Pods with an
ordinal that is greater than or equal to the partition will be updated when the StatefulSet's
`.spec.template` is updated. All Pods with an ordinal that is less than the partition will not
be updated, and, even if they are deleted, they will be recreated at the previous version. If a
StatefulSet's `.spec.updateStrategy.rollingUpdate.partition` is greater than its `.spec.replicas`,
updates to its `.spec.template` will not be propagated to its Pods.
In most cases you will not need to use a partition, but they are useful if you want to stage an
In most cases you will not need to use a partition, but they are useful if you want to stage an
update, roll out a canary, or perform a phased roll out.
{% endcapture %}
{% capture whatsnext %}
* Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set).
* Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set).
{% endcapture %}
{% include templates/concept.md %}
docs/concepts/workloads/pods/disruptions.md
-5
View File
@@ -4,11 +4,6 @@ assignees:
- foxish
- davidopp
title: Disruptions
redirect_from:
- "/docs/admin/disruptions/"
- "/docs/admin/disruptions.html"
- "/docs/tasks/configure-pod-container/configure-pod-disruption-budget/"
- "/docs/tasks/administer-cluster/configure-pod-disruption-budget/"
---
{% capture overview %}
docs/concepts/workloads/pods/init-containers.md
-5
View File
@@ -2,11 +2,6 @@
assignees:
- erictune
title: Init Containers
redirect_from:
- "/docs/concepts/abstractions/init-containers/"
- "/docs/concepts/abstractions/init-containers.html"
- "/docs/user-guide/pods/init-container/"
- "/docs/user-guide/pods/init-container.html"
---
{% capture overview %}
docs/concepts/workloads/pods/pod-lifecycle.md
-3
View File
@@ -1,8 +1,5 @@
---
title: Pod Lifecycle
redirect_from:
- "/docs/user-guide/pod-states/"
- "/docs/user-guide/pod-states.html"
---
{% capture overview %}
docs/concepts/workloads/pods/pod-overview.md
+1 -6
View File
@@ -2,11 +2,6 @@
assignees:
- erictune
title: Pod Overview
redirect_from:
- "/docs/concepts/abstractions/pod/"
- "/docs/concepts/abstractions/pod.html"
- "/docs/user-guide/pod-templates/"
- "/docs/user-guide/pod-templates.html"
---
{% capture overview %}
@@ -64,7 +59,7 @@ Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fail
### Pods and Controllers
A Controller can create and manage multiple Pods for you, handling replication and rollout and providing self-healing capabilities at cluster scope. For example, if a Node fails, the Controller might automatically replace the Pod by scheduling an identical replacement on a different Node.
A Controller can create and manage multiple Pods for you, handling replication and rollout and providing self-healing capabilities at cluster scope. For example, if a Node fails, the Controller might automatically replace the Pod by scheduling an identical replacement on a different Node.
Some examples of Controllers that contain one or more pods include:
docs/concepts/workloads/pods/pod.md
-3
View File
@@ -1,9 +1,6 @@
---
assignees:
title: Pods
redirect_from:
- "/docs/user-guide/pods/index/"
- "/docs/user-guide/pods/index.html"
---
* TOC