Removed all blank links. Inserted links to StatefulSet content. Addressed remaining feedback.
This commit is contained in:
Devin Donnelly
@@ -21,9 +21,9 @@ To work with Kubernetes objects--whether to create, modify, or delete them--you'
|
||||
|
||||
#### 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](/docs/concepts/control-plane/overview/) actively manages an object's actual state to match the desired state you supplied.
|
||||
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.
|
||||
|
||||
For example, a Kubernetes [Deployment]() is an object that can represent an application running on your cluster. When you create the Deployment, you might set the Deployment spec to specify that you want three replicas of the application to be running. The Kubernetes system reads the Deployment spec and starts three instances of your desired application--updating the status to match your spec. If any of those instances should fail (a status change), the Kubernetes system reacts to the difference between spec and status by making a correction--in this case, starting a replacement instance.
|
||||
For example, a Kubernetes Deployment is an object that can represent an application running on your cluster. When you create the Deployment, you might set the Deployment spec to specify that you want three replicas of the application to be running. The Kubernetes system reads the Deployment spec and starts three instances of your desired application--updating the status to match your spec. If any of those instances should fail (a status change), the Kubernetes system reacts to the difference between spec and status by making a correction--in this case, starting a replacement instance.
|
||||
|
||||
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).
|
||||
|
||||
@@ -31,7 +31,7 @@ For more information on the object spec, status, and metadata, see the [Kubernet
|
||||
|
||||
When you create an object in Kubernetes, you must provide the object spec that describes your desired state for it, 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 call sends the information to the Kubernetes Master as JSON. **You can express that JSON using a `.yaml` file.**
|
||||
|
||||
Here's an example `.yaml` file that shows an example of the required fields and object spec for a Kubernetes [Deployment](/docs/concepts/abstractions/deployment/):
|
||||
Here's an example `.yaml` file that shows an example of the required fields and object spec for a Kubernetes Deployment:
|
||||
|
||||
{% include code.html language="yaml" file="/docs/user-guide/nginx-deployment.yaml" ghlink="/docs/user-guide/nginx-deployment.yaml" %}
|
||||
|
||||
|
||||
@@ -27,7 +27,9 @@ The [Kubernetes Blog](http://blog.kubernetes.io) has some additional information
|
||||
* [The Distributed System Toolkit: Patterns for Composite Containers](http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html)
|
||||
* [Container Design Patterns](http://blog.kubernetes.io/2016/06/container-design-patterns.html)
|
||||
|
||||
Note that 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, such Pods are usually managed by a Controller. See [Pods and Controllers](#pods-and-controllers) for more 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, such Pods are usually managed by a Controller. See [Pods and Controllers](#pods-and-controllers) for more information.
|
||||
|
||||
> Note: Restarting a container in a Pod should not be confused with _restarting_ the Pod itself. The Pod itself does not run, but is an environment the containers run in and persists until it is deleted.
|
||||
|
||||
#### How Pods Manage Multiple Containers
|
||||
|
||||
@@ -45,11 +47,11 @@ Each Pod is assigned a unique IP address. Every the container in a pod shares th
|
||||
|
||||
##### 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.
|
||||
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
|
||||
|
||||
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 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.
|
||||
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.
|
||||
|
||||
> Note: Restarting a container in a Pod should not be confused with restarting the Pod. The Pod itself does not run, but is an environment the containers run in and persists until it is deleted.
|
||||
|
||||
@@ -61,11 +63,11 @@ A Controller can create and manage multiple Pods for you, handling replication a
|
||||
|
||||
Some examples of Controllers that contain one or more pods include:
|
||||
|
||||
* [Deployment]()
|
||||
* [StatefulSet]()
|
||||
* [DaemonSet]()
|
||||
* Deployment
|
||||
* [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/)
|
||||
* DaemonSet
|
||||
|
||||
In general, Controllers use a [Pod Template]() that you provide to create the Pods for which it is responsible.
|
||||
In general, Controllers use a Pod Template that you provide to create the Pods for which it is responsible.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
+5
-15
@@ -26,11 +26,11 @@ The basic Kubernetes objects include:
|
||||
* Volume
|
||||
* Namespace
|
||||
|
||||
In addition, Kubernetes contains a number of higher-level abstractions that build upon the basic objects, and provide additional functionality and convenience features. They include:
|
||||
In addition, Kubernetes contains a number of higher-level abstractions called Controllers. Controllers build upon the basic objects, and provide additional functionality and convenience features. They include:
|
||||
|
||||
* ReplicaSet
|
||||
* Deployment
|
||||
* StatefulSet
|
||||
* [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/))
|
||||
* DaemonSet
|
||||
* Job
|
||||
|
||||
@@ -42,29 +42,19 @@ For example, When you use the Kubernetes API to create a Deployment object, for
|
||||
|
||||
### Kubernetes Master
|
||||
|
||||
The Kubernetes master is responsible for maintaining the desired state for your cluster. The Kubernetes master(s) runs the following processes:
|
||||
The Kubernetes master is responsible for maintaining the desired state for your cluster. When you interact with Kubernetes, such as by using the `kubectl` command-line interface, you're communicating with your cluster's Kubernetes master.
|
||||
|
||||
* API Server
|
||||
* Scheduler
|
||||
* Etcd
|
||||
* Controller Manager
|
||||
> The "master" refers to a collection of processes managing the cluster state. Typically these processes are all run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundnacy.
|
||||
|
||||
### Kubernetes Nodes
|
||||
|
||||
The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. These nodes are controlled by the Kubernetes master. The following processes run on each node in a Kubernetes cluster:
|
||||
|
||||
* Kubelet
|
||||
* Docker-daemon
|
||||
* kube-proxy
|
||||
The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. The Kubernetes master controls each node; you'll rarely interact with nodes directly.
|
||||
|
||||
#### Object Metadata
|
||||
|
||||
|
||||
* [Annotations](/docs/concepts/object-metadata/annotations/)
|
||||
|
||||
#### Controllers
|
||||
* [StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/)
|
||||
|
||||
|
||||
### What's next
|
||||
|
||||
|
||||
Reference in New Issue
Block a user