Merge master into dev-1.21 to keep in sync, plus latest API reference
This sync merge includes API reference updates.
This commit is contained in:
Tim Bannister
@@ -54,7 +54,9 @@ Run the example job by downloading the example file and then running this comman
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/controllers/replication.yaml
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
replicationcontroller/nginx created
|
||||
```
|
||||
@@ -64,7 +66,9 @@ Check on the status of the ReplicationController using this command:
|
||||
```shell
|
||||
kubectl describe replicationcontrollers/nginx
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
Name: nginx
|
||||
Namespace: default
|
||||
@@ -103,7 +107,9 @@ To list all the pods that belong to the ReplicationController in a machine reada
|
||||
pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})
|
||||
echo $pods
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
nginx-3ntk0 nginx-4ok8v nginx-qrm3m
|
||||
```
|
||||
@@ -117,7 +123,7 @@ specifies an expression with the name from each pod in the returned list.
|
||||
As with all other Kubernetes config, a ReplicationController needs `apiVersion`, `kind`, and `metadata` fields.
|
||||
The name of a ReplicationController object must be a valid
|
||||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
For general information about working with config files, see [object management ](/docs/concepts/overview/working-with-objects/object-management/).
|
||||
For general information about working with configuration files, see [object management](/docs/concepts/overview/working-with-objects/object-management/).
|
||||
|
||||
A ReplicationController also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
|
||||
|
||||
@@ -139,7 +145,7 @@ for example the [Kubelet](/docs/reference/command-line-tools-reference/kubelet/)
|
||||
|
||||
The ReplicationController can itself have labels (`.metadata.labels`). Typically, you
|
||||
would set these the same as the `.spec.template.metadata.labels`; if `.metadata.labels` is not specified
|
||||
then it defaults to `.spec.template.metadata.labels`. However, they are allowed to be
|
||||
then it defaults to `.spec.template.metadata.labels`. However, they are allowed to be
|
||||
different, and the `.metadata.labels` do not affect the behavior of the ReplicationController.
|
||||
|
||||
### Pod Selector
|
||||
@@ -197,7 +203,7 @@ To update pods to a new spec in a controlled way, use a [rolling update](#rollin
|
||||
|
||||
### Isolating pods from a ReplicationController
|
||||
|
||||
Pods may be removed from a ReplicationController's target set by changing their labels. This technique may be used to remove pods from service for debugging, data recovery, etc. Pods that are removed in this way will be replaced automatically (assuming that the number of replicas is not also changed).
|
||||
Pods may be removed from a ReplicationController's target set by changing their labels. This technique may be used to remove pods from service for debugging and data recovery. Pods that are removed in this way will be replaced automatically (assuming that the number of replicas is not also changed).
|
||||
|
||||
## Common usage patterns
|
||||
|
||||
@@ -207,8 +213,7 @@ As mentioned above, whether you have 1 pod you want to keep running, or 1000, a
|
||||
|
||||
### Scaling
|
||||
|
||||
The ReplicationController scales the number of replicas up or down by setting the `replicas` field.
|
||||
You can configure the ReplicationController to manage the replicas manually or by an auto-scaling control agent.
|
||||
The ReplicationController enables scaling the number of replicas up or down, either manually or by an auto-scaling control agent, by updating the `replicas` field.
|
||||
|
||||
### Rolling updates
|
||||
|
||||
@@ -245,7 +250,6 @@ The ReplicationController is forever constrained to this narrow responsibility.
|
||||
|
||||
The ReplicationController is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, scale) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](https://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc.
|
||||
|
||||
|
||||
## API Object
|
||||
|
||||
Replication controller is a top-level resource in the Kubernetes REST API. More details about the
|
||||
@@ -260,7 +264,6 @@ API object can be found at:
|
||||
It's mainly used by [Deployment](/docs/concepts/workloads/controllers/deployment/) as a mechanism to orchestrate pod creation, deletion and updates.
|
||||
Note that we recommend using Deployments instead of directly using Replica Sets, unless you require custom update orchestration or don't require updates at all.
|
||||
|
||||
|
||||
### Deployment (Recommended)
|
||||
|
||||
[`Deployment`](/docs/concepts/workloads/controllers/deployment/) is a higher-level API object that updates its underlying Replica Sets and their Pods. Deployments are recommended if you want this rolling update functionality because, they are declarative, server-side, and have additional features.
|
||||
@@ -284,5 +287,3 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
|
||||
## For more information
|
||||
|
||||
Read [Run Stateless Application Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
|
||||
|
||||
|
||||
|
||||
@@ -313,16 +313,16 @@ limit, the same as the scheduler.
|
||||
A Pod can restart, causing re-execution of init containers, for the following
|
||||
reasons:
|
||||
|
||||
* A user updates the Pod specification, causing the init container image to change.
|
||||
Any changes to the init container image restarts the Pod. App container image
|
||||
changes only restart the app container.
|
||||
* The Pod infrastructure container is restarted. This is uncommon and would
|
||||
have to be done by someone with root access to nodes.
|
||||
* All containers in a Pod are terminated while `restartPolicy` is set to Always,
|
||||
forcing a restart, and the init container completion record has been lost due
|
||||
to garbage collection.
|
||||
|
||||
|
||||
The Pod will not be restarted when the init container image is changed, or the
|
||||
init container completion record has been lost due to garbage collection. This
|
||||
applies for Kubernetes v1.20 and later. If you are using an earlier version of
|
||||
Kubernetes, consult the documentation for the version you are using.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user