Provides snippet for PLEG (#13805)

pull/13815/head
codyc 2019-04-14 10:18:00 -05:00 committed by Kubernetes Prow Robot
parent 04a8c62dc9
commit 862bd49693
2 changed files with 11 additions and 1 deletions

View File

@ -17,7 +17,7 @@ The Concepts section helps you learn about the parts of the Kubernetes system an
To work with Kubernetes, you use *Kubernetes API objects* to describe your cluster's *desired state*: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, `kubectl`. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state.
Once you've set your desired state, the *Kubernetes Control Plane* works to make the cluster's current state match the desired state. To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster:
Once you've set your desired state, the *Kubernetes Control Plane* using the Pod Lifecycle Event Generator (PLEG) works to make the cluster's current state matches the desired state. To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster:
* The **Kubernetes Master** is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and [kube-scheduler](/docs/admin/kube-scheduler/).
* Each individual non-master node in your cluster runs two processes:

View File

@ -29,6 +29,16 @@ is checked every 20 seconds (also configurable with a flag).
HTTP server: The kubelet can also listen for HTTP and respond to a simple API
(underspec'd currently) to submit a new manifest.
#### Pod Lifecycle Event Generator (PLEG)
The Pod Lifecycle Event Generator is a function of the kubelet that creates a list of
the states for all containers and pods then compares it to the previous states of the
containers and pods in a process called Relisting. This allows the PLEG to know which
pods and containers need to be synced. In versions prior to 1.2, this was accomplished
by polling and was CPU intensive. By changing to this method, this significantly reduced
resource utilization allowing for better container density.
```
kubelet [flags]
```