add en pages
This commit is contained in:
Karen Bradshaw
@@ -4,11 +4,11 @@ reviewers:
|
||||
- soltysh
|
||||
- janetkuo
|
||||
title: CronJob
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 80
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.8" state="beta" >}}
|
||||
|
||||
@@ -33,8 +33,8 @@ append 11 characters to the job name provided and there is a constraint that the
|
||||
maximum length of a Job name is no more than 63 characters.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## CronJob
|
||||
|
||||
@@ -82,12 +82,13 @@ be down for the same period as the previous example (`08:29:00` to `10:21:00`,)
|
||||
The CronJob is only responsible for creating Jobs that match its schedule, and
|
||||
the Job in turn is responsible for the management of the Pods it represents.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
[Cron expression format](https://pkg.go.dev/github.com/robfig/cron?tab=doc#hdr-CRON_Expression_Format)
|
||||
documents the format of CronJob `schedule` fields.
|
||||
|
||||
For instructions on creating and working with cron jobs, and for an example of CronJob
|
||||
manifest, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -6,11 +6,11 @@ reviewers:
|
||||
- janetkuo
|
||||
- kow3ns
|
||||
title: DaemonSet
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
A _DaemonSet_ ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the
|
||||
cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage
|
||||
@@ -26,10 +26,10 @@ In a simple case, one DaemonSet, covering all nodes, would be used for each type
|
||||
A more complex setup might use multiple DaemonSets for a single type of daemon, but with
|
||||
different flags and/or different memory and cpu requests for different hardware types.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Writing a DaemonSet Spec
|
||||
|
||||
@@ -229,4 +229,4 @@ number of replicas and rolling out updates are more important than controlling e
|
||||
the Pod runs on. Use a DaemonSet when it is important that a copy of a Pod always run on
|
||||
all or certain hosts, and when it needs to start before other Pods.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -7,11 +7,11 @@ feature:
|
||||
description: >
|
||||
Kubernetes progressively rolls out changes to your application or its configuration, while monitoring application health to ensure it doesn't kill all your instances at the same time. If something goes wrong, Kubernetes will rollback the change for you. Take advantage of a growing ecosystem of deployment solutions.
|
||||
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and
|
||||
[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/).
|
||||
@@ -22,10 +22,10 @@ You describe a _desired state_ in a Deployment, and the Deployment {{< glossary_
|
||||
Do not manage ReplicaSets owned by a Deployment. Consider opening an issue in the main Kubernetes repository if your use case is not covered below.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Use Case
|
||||
|
||||
@@ -1166,4 +1166,4 @@ a paused Deployment and one that is not paused, is that any changes into the Pod
|
||||
Deployment will not trigger new rollouts as long as it is paused. A Deployment is not paused by default when
|
||||
it is created.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,18 +1,18 @@
|
||||
---
|
||||
title: Garbage Collection
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
The role of the Kubernetes garbage collector is to delete certain objects
|
||||
that once had an owner, but no longer have an owner.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Owners and dependents
|
||||
|
||||
@@ -168,16 +168,17 @@ See [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment
|
||||
|
||||
Tracked at [#26120](https://github.com/kubernetes/kubernetes/issues/26120)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
[Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
|
||||
|
||||
[Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ reviewers:
|
||||
- erictune
|
||||
- soltysh
|
||||
title: Jobs - Run to Completion
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
feature:
|
||||
title: Batch execution
|
||||
description: >
|
||||
@@ -11,7 +11,7 @@ feature:
|
||||
weight: 70
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
A Job creates one or more Pods and ensures that a specified number of them successfully terminate.
|
||||
As pods successfully complete, the Job tracks the successful completions. When a specified number
|
||||
@@ -24,10 +24,10 @@ due to a node hardware failure or a node reboot).
|
||||
|
||||
You can also use a Job to run multiple Pods in parallel.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Running an example Job
|
||||
|
||||
@@ -478,4 +478,4 @@ object, but maintains complete control over what Pods are created and how work i
|
||||
|
||||
You can use a [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) to create a Job that will run at specified times/dates, similar to the Unix tool `cron`.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -4,19 +4,19 @@ reviewers:
|
||||
- bprashanth
|
||||
- madhusudancs
|
||||
title: ReplicaSet
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often
|
||||
used to guarantee the availability of a specified number of identical Pods.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## How a ReplicaSet works
|
||||
|
||||
@@ -366,4 +366,4 @@ The two serve the same purpose, and behave similarly, except that a ReplicationC
|
||||
selector requirements as described in the [labels user guide](/docs/concepts/overview/working-with-objects/labels/#label-selectors).
|
||||
As such, ReplicaSets are preferred over ReplicationControllers
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -9,11 +9,11 @@ feature:
|
||||
description: >
|
||||
Restarts containers that fail, replaces and reschedules containers when nodes die, kills containers that don't respond to your user-defined health check, and doesn't advertise them to clients until they are ready to serve.
|
||||
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< note >}}
|
||||
A [`Deployment`](/docs/concepts/workloads/controllers/deployment/) that configures a [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is now the recommended way to set up replication.
|
||||
@@ -23,10 +23,10 @@ A _ReplicationController_ ensures that a specified number of pod replicas are ru
|
||||
time. In other words, a ReplicationController makes sure that a pod or a homogeneous set of pods is
|
||||
always up and available.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## How a ReplicationController Works
|
||||
|
||||
@@ -285,4 +285,4 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
|
||||
|
||||
Read [Run Stateless AP Replication Controller](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -7,18 +7,18 @@ reviewers:
|
||||
- kow3ns
|
||||
- smarterclayton
|
||||
title: StatefulSets
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
StatefulSet is the workload API object used to manage stateful applications.
|
||||
|
||||
{{< glossary_definition term_id="statefulset" length="all" >}}
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Using StatefulSets
|
||||
|
||||
@@ -270,12 +270,13 @@ After reverting the template, you must also delete any Pods that StatefulSet had
|
||||
already attempted to run with the bad configuration.
|
||||
StatefulSet will then begin to recreate the Pods using the reverted template.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set/).
|
||||
* Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/).
|
||||
* Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -2,11 +2,11 @@
|
||||
reviewers:
|
||||
- janetkuo
|
||||
title: TTL Controller for Finished Resources
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 65
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
|
||||
|
||||
@@ -21,12 +21,12 @@ Alpha Disclaimer: this feature is currently alpha, and can be enabled with both
|
||||
`TTLAfterFinished`.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## TTL Controller
|
||||
|
||||
@@ -78,12 +78,13 @@ In Kubernetes, it's required to run NTP on all nodes
|
||||
to avoid time skew. Clocks aren't always correct, but the difference should be
|
||||
very small. Please be aware of this risk when setting a non-zero TTL.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
[Clean up Jobs automatically](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
|
||||
|
||||
[Design doc](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user