Reduce heading levels by 1.
This commit is contained in:
@@ -22,7 +22,7 @@ guarantees about the ordering of deployment and scaling.
|
||||
|
||||
{% capture body %}
|
||||
|
||||
### Using StatefulSets
|
||||
## Using StatefulSets
|
||||
|
||||
StatefulSets are valuable for applications that require one or more of the
|
||||
following.
|
||||
@@ -39,7 +39,7 @@ provides a set of stateless replicas. Controllers such as
|
||||
[Deployment](/docs/user-guide/deployments/) or
|
||||
[ReplicaSet](/docs/user-guide/replicasets/) may be better suited to your stateless needs.
|
||||
|
||||
### Limitations
|
||||
## Limitations
|
||||
* StatefulSet is a beta resource, not available in any Kubernetes release prior to 1.5.
|
||||
* As with all alpha/beta resources, you can disable StatefulSet through the `--runtime-config` option passed to the apiserver.
|
||||
* The storage for a given Pod must either be provisioned by a [PersistentVolume Provisioner](http://releases.k8s.io/{{page.githubbranch}}/examples/experimental/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin.
|
||||
@@ -47,7 +47,7 @@ provides a set of stateless replicas. Controllers such as
|
||||
* StatefulSets currently require a [Headless Service](/docs/user-guide/services/#headless-services) to be responsible for the network identity of the Pods. You are responsible for creating this Service.
|
||||
* Updating an existing StatefulSet is currently a manual process.
|
||||
|
||||
### Components
|
||||
## Components
|
||||
The example below demonstrates the components of a StatefulSet.
|
||||
|
||||
* A Headless Service, named nginx, is used to control the network domain.
|
||||
@@ -103,17 +103,17 @@ spec:
|
||||
storage: 1Gi
|
||||
```
|
||||
|
||||
### Pod Identity
|
||||
## 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,
|
||||
regardless of which node it's (re)scheduled on.
|
||||
|
||||
__Ordinal Index__
|
||||
### 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.
|
||||
|
||||
__Stable Network ID__
|
||||
### 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
|
||||
@@ -139,7 +139,7 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain
|
||||
Note that Cluster Domain will be set to `cluster.local` unless
|
||||
[otherwise configured](http://releases.k8s.io/{{page.githubbranch}}/build/kube-dns/README.md#how-do-i-configure-it).
|
||||
|
||||
__Stable Storage__
|
||||
### Stable Storage
|
||||
|
||||
Kubernetes creates one [PersistentVolume](/docs/user-guide/volumes/) for each
|
||||
VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume
|
||||
@@ -149,7 +149,7 @@ 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 Guarantee
|
||||
## Deployment and Scaling Guarantee
|
||||
|
||||
* 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}.
|
||||
|
||||
@@ -7,7 +7,7 @@ This page explains how Kubernetes objects are represented in the Kubernetes API,
|
||||
{% endcapture %}
|
||||
|
||||
{% capture body %}
|
||||
### Understanding Kubernetes Objects
|
||||
## Understanding Kubernetes Objects
|
||||
|
||||
*Kubernetes Objects* are persistent entities in the Kubernetes system. Kubenetes uses these entities to represent the state of your cluster. Specifically, they can describe:
|
||||
|
||||
@@ -19,7 +19,7 @@ A Kubernetes object is a "record of intent"--once you create the object, the Kub
|
||||
|
||||
To work with Kubernetes objects--whether to create, modify, or delete them--you'll need to use the [Kubernetes API](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md). When you use the `kubectl` comamnd-line interface, for example, the CLI makes the necessary Kubernetes API calls for you; you can also use the Kubernetes API directly in your own programs. Kubernetes currently provides a `golang` [client library](https://github.com/kubernetes/client-go) for this purpose, and other language libraries (such as [Python](https://github.com/kubernetes-incubator/client-python)) are being developed.
|
||||
|
||||
#### Object Spec and Status
|
||||
### Object Spec and Status
|
||||
|
||||
Every Kubernetes object includes two nested object fields that govern the object's configuration: the object *spec* and the object *status*. The *spec*, which you must provide, describes your *desired state* for the object--the characteristics that you want the object to have. The *status* describes the *actual state* for the object, and is supplied and updated by the Kubernetes system. At any given time, the Kubernetes Control Plane actively manages an object's actual state to match the desired state you supplied.
|
||||
|
||||
@@ -27,7 +27,7 @@ For example, a Kubernetes Deployment is an object that can represent an applicat
|
||||
|
||||
For more information on the object spec, status, and metadata, see the [Kubernetes API Conventions](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md#spec-and-status).
|
||||
|
||||
#### Describing a Kubernetes Object
|
||||
### Describing a Kubernetes Object
|
||||
|
||||
When you create an object in Kubernetes, you must provide the object spec that describes its desired state, as well as some basic information about the object (such as a name). When you use the Kubernetes API to create the object (either directly or via `kubectl`), that API request must include that information as JSON in the request body. **Most often, you provide the information to `kubectl` in a .yaml file.** `kubectl` converts the information to JSON when making the API request.
|
||||
|
||||
@@ -47,7 +47,7 @@ The output is similar to this:
|
||||
deployment "nginx-deployment" created
|
||||
```
|
||||
|
||||
#### Required Fields
|
||||
### Required Fields
|
||||
|
||||
In the `.yaml` file for the Kubernetes object you want to create, you'll need to set values for the following fields:
|
||||
|
||||
@@ -63,4 +63,4 @@ You'll also need to provide the object `spec` field. The precise format of the o
|
||||
* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/abstractions/pod/).
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/concept.md %}
|
||||
{% include templates/concept.md %}
|
||||
|
||||
@@ -9,7 +9,7 @@ This page provides an overview of `Pod`, the smallest deployable object in the K
|
||||
{:toc}
|
||||
|
||||
{% capture body %}
|
||||
### Understanding Pods
|
||||
## Understanding Pods
|
||||
|
||||
A *Pod* is the basic building block of Kubernetes--the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents a running process on your cluster.
|
||||
|
||||
@@ -29,7 +29,7 @@ The [Kubernetes Blog](http://blog.kubernetes.io) has some additional information
|
||||
|
||||
Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (e.g., run muliple instances), you should use multiple Pods, one for each instance. In Kubernetes, this is generally referred to as _replication_. Replicated Pods are usually created and managed as a group by an abstraction called a Controller. See [Pods and Controllers](#pods-and-controllers) for more information.
|
||||
|
||||
#### How Pods Manage Multiple Containers
|
||||
### How Pods Manage Multiple Containers
|
||||
|
||||
Pods are designed to support multiple cooperating processes (as containers) that form a cohesive unit of service. The containers in a Pod are automatically co-located and co-scheduled on the same phyiscal or virtual machine in the cluster. The containers can share resources and dependencies, communicate with one another, and coordinate when and how they are terminated.
|
||||
|
||||
@@ -39,15 +39,15 @@ Note that grouping multiple co-located and co-managed containers in a single Pod
|
||||
|
||||
Pods provide two kinds of shared resources for their constituent containers: *networking* and *storage*.
|
||||
|
||||
##### Networking
|
||||
#### Networking
|
||||
|
||||
Each Pod is assigned a unique IP address. Every the container in a Pod shares the network namespace, including the IP address and network ports. Containers *inside a Pod* can communicate with one another using `localhost`. When containers in a Pod communicate with entities *outside the Pod*, they must coordinate how they use the shared network resources (such as ports).
|
||||
|
||||
##### Storage
|
||||
#### Storage
|
||||
|
||||
A Pod can specify a set of shared storage *volumes*. All containers in the Pod can access the shared volumes, allowing those containers to share data. Volumes also allow persistent data in a Pod to survive in case one of the containers within needs to be restarted. See Volumes for more information on how Kubernetes implements shared storage in a Pod.
|
||||
|
||||
### Working with Pods
|
||||
## Working with Pods
|
||||
|
||||
You'll rarely create individual Pods directly in Kubernetes--even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a Controller), it is scheduled to run on a Node in your your cluster. The Pod remains on that Node until the process is terminated, the pod object is deleted, or the pod is *evicted* for lack of resources, or the Node fails.
|
||||
|
||||
@@ -55,7 +55,7 @@ You'll rarely create individual Pods directly in Kubernetes--even singleton Pods
|
||||
|
||||
Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a *Controller*, that handles the work of managing the relatively disposable Pod instances. Thus, while it is possible to use Pod directly, it's far more common in Kubernetes to manage your pods using a Controller. See [Pods and Controllers](#pods-and-controllers) for more information on how Kubernetes uses Controllers to implement Pod scaling and healing.
|
||||
|
||||
#### Pods and Controllers
|
||||
### 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).
|
||||
|
||||
@@ -75,4 +75,4 @@ In general, Controllers use a Pod Template that you provide to create the Pods f
|
||||
* Other Pod Topics
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/concept.md %}
|
||||
{% include templates/concept.md %}
|
||||
|
||||
Reference in New Issue
Block a user