Merge pull request #28377 from ritpanjw/merged-master-dev-1.22

Merge master into dev-1.22 to keep in sync - SIG-Release 1.22 Docs team 6/11/21
This commit is contained in:
Kubernetes Prow Robot
2021-06-12 00:55:00 -07:00
committed by GitHub
58 changed files with 846 additions and 795 deletions
+5 -1
View File
@@ -19,7 +19,11 @@ help: ## Show this help.
@awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {sub("\\\\n",sprintf("\n%22c"," "), $$2);printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST)
module-check:
@git submodule status --recursive | awk '/^[+-]/ {printf "\033[31mWARNING\033[0m Submodule not initialized: \033[34m%s\033[0m\n",$$2}' 1>&2
@git submodule status --recursive | awk '/^[+-]/ {err = 1; printf "\033[31mWARNING\033[0m Submodule not initialized: \033[34m%s\033[0m\n",$$2} END { if (err != 0) print "You need to run \033[32mmake module-init\033[0m to initialize missing modules first"; exit err }' 1>&2
module-init:
@echo "Initializing submodules..." 1>&2
@git submodule update --init --recursive --depth 1
all: build ## Build site with production settings and put deliverables in ./public
+3 -3
View File
@@ -43,12 +43,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
<button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Attend KubeCon NA virtually on November 17-20, 2020</a>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna21" button id="desktopKCButton">Attend KubeCon North America on October 11-15, 2021</a>
<br>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu21" button id="desktopKCButton">Attend KubeCon EU virtually on May 4 7, 2021</a>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu21" button id="desktopKCButton">Revisit KubeCon EU 2021</a>
</div>
<div id="videoPlayer">
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
@@ -58,4 +58,4 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
{{< blocks/kubernetes-features >}}
{{< blocks/case-studies >}}
{{< blocks/case-studies >}}
@@ -95,7 +95,7 @@ The core workloads API surface is stable, but its still software, and softwar
--Kenneth Owens, Software Engineer, Google
- [Download](http://get.k8s.io/) Kubernetes
- [Download](https://get.k8s.io/) Kubernetes
- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)
- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
- Connect with the community on [Slack](http://slack.k8s.io/)
@@ -526,6 +526,6 @@ When you enable the API Priority and Fairness feature, the kube-apiserver serves
For background information on design details for API priority and fairness, see
the [enhancement proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md).
the [enhancement proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1040-priority-and-fairness).
You can make suggestions and feature requests via [SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery)
or the feature's [slack channel](http://kubernetes.slack.com/messages/api-priority-and-fairness).
@@ -464,12 +464,12 @@ allowed prefix, and a `readOnly` field indicating it must be mounted read-only.
For example:
```yaml
allowedHostPaths:
# This allows "/foo", "/foo/", "/foo/bar" etc., but
# disallows "/fool", "/etc/foo" etc.
# "/foo/../" is never valid.
- pathPrefix: "/foo"
readOnly: true # only allow read-only mounts
allowedHostPaths:
# This allows "/foo", "/foo/", "/foo/bar" etc., but
# disallows "/fool", "/etc/foo" etc.
# "/foo/../" is never valid.
- pathPrefix: "/foo"
readOnly: true # only allow read-only mounts
```
{{< warning >}}There are many ways a container with unrestricted access to the host
@@ -26,40 +26,41 @@ each resource to score nodes based on the request to capacity ratio. This
allows users to bin pack extended resources by using appropriate parameters
and improves the utilization of scarce resources in large clusters. The
behavior of the `RequestedToCapacityRatioResourceAllocation` priority function
can be controlled by a configuration option called
`requestedToCapacityRatioArguments`. This argument consists of two parameters
`shape` and `resources`. The `shape` parameter allows the user to tune the
function as least requested or most requested based on `utilization` and
`score` values. The `resources` parameter consists of `name` of the resource
to be considered during scoring and `weight` specify the weight of each
resource.
can be controlled by a configuration option called `RequestedToCapacityRatioArgs`.
This argument consists of two parameters `shape` and `resources`. The `shape`
parameter allows the user to tune the function as least requested or most
requested based on `utilization` and `score` values. The `resources` parameter
consists of `name` of the resource to be considered during scoring and `weight`
specify the weight of each resource.
Below is an example configuration that sets
`requestedToCapacityRatioArguments` to bin packing behavior for extended
resources `intel.com/foo` and `intel.com/bar`.
```yaml
apiVersion: v1
kind: Policy
apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
profiles:
# ...
priorities:
# ...
- name: RequestedToCapacityRatioPriority
weight: 2
argument:
requestedToCapacityRatioArguments:
shape:
- utilization: 0
score: 0
- utilization: 100
score: 10
resources:
- name: intel.com/foo
weight: 3
- name: intel.com/bar
weight: 5
pluginConfig:
- name: RequestedToCapacityRatio
args:
shape:
- utilization: 0
score: 10
- utilization: 100
score: 0
resources:
- name: intel.com/foo
weight: 3
- name: intel.com/bar
weight: 5
```
Referencing the `KubeSchedulerConfiguration` file with the kube-scheduler
flag `--config=/path/to/config/file` will pass the configuration to the
scheduler.
**This feature is disabled by default**
### Tuning the Priority Function
@@ -10,7 +10,7 @@ weight: 40
<!-- overview -->
[_Node affinity_](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity),
[_Node affinity_](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
is a property of {{< glossary_tooltip text="Pods" term_id="pod" >}} that *attracts* them to
a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (either as a preference or a
hard requirement). _Taints_ are the opposite -- they allow a node to repel a set of pods.
@@ -13,7 +13,7 @@ weight: 45
_Topology Aware Hints_ enable topology aware routing by including suggestions
for how clients should consume endpoints. This approach adds metadata to enable
consumers of EndpointSlice and / or and Endpoints objects, so that traffic to
consumers of EndpointSlice and / or Endpoints objects, so that traffic to
those network endpoints can be routed closer to where it originated.
For example, you can route traffic within a locality to reduce
+25
View File
@@ -0,0 +1,25 @@
---
title: Viewing Site Analytics
content_type: concept
weight: 100
card:
name: contribute
weight: 100
---
<!-- overview -->
This page contains information about the kubernetes.io analytics dashboard.
<!-- body -->
[View the dashboard](https://datastudio.google.com/reporting/fede2672-b2fd-402a-91d2-7473bdb10f04).
This dashboard is built using Google Data Studio and shows information collected on kubernetes.io using Google Analytics.
### Using the dashboard
By default, the dashboard shows all collected analytics for the past 30 days. Use the date selector to see data from a different date range. Other filtering options allow you to view data based on user location, the device used to access the site, the translation of the docs used, and more.
If you notice an issue with this dashboard, or would like to request any improvements, please [open an issue](https://github.com/kubernetes/website/issues/new/choose).
@@ -134,7 +134,6 @@ Go to `<k8s-base>` and run these scripts:
hack/update-generated-swagger-docs.sh
hack/update-openapi-spec.sh
hack/update-generated-protobuf.sh
hack/update-api-reference-docs.sh
```
Run `git status` to see what was generated.
@@ -143,8 +142,6 @@ Run `git status` to see what was generated.
On branch master
...
modified: api/openapi-spec/swagger.json
modified: api/swagger-spec/apps_v1.json
modified: docs/api-reference/apps/v1/definitions.html
modified: staging/src/k8s.io/api/apps/v1/generated.proto
modified: staging/src/k8s.io/api/apps/v1/types.go
modified: staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go
+1 -1
View File
@@ -38,7 +38,7 @@ client libraries:
- [Kubernetes Python client library](https://github.com/kubernetes-client/python)
- [Kubernetes Java client library](https://github.com/kubernetes-client/java)
- [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript)
- [Kubernetes Dotnet client library](https://github.com/kubernetes-client/csharp)
- [Kubernetes C# client library](https://github.com/kubernetes-client/csharp)
- [Kubernetes Haskell Client library](https://github.com/kubernetes-client/haskell)
## CLI
@@ -58,7 +58,7 @@ It acts synchronously to modify pods as they are created or updated. When this p
1. It ensures that the `ServiceAccount` referenced by the pod exists, and otherwise rejects it.
1. It adds a `volume` to the pod which contains a token for API access if neither the ServiceAccount `automountServiceAccountToken` nor the Pod's `automountServiceAccountToken` is set to `false`.
1. It adds a `volumeSource` to each container of the pod mounted at `/var/run/secrets/kubernetes.io/serviceaccount`, if the previous step has created a volume for ServiceAccount token.
1. If the pod does not contain any `ImagePullSecrets`, then `ImagePullSecrets` of the `ServiceAccount` are added to the pod.
1. If the pod does not contain any `imagePullSecrets`, then `imagePullSecrets` of the `ServiceAccount` are added to the pod.
#### Bound Service Account Token Volume
@@ -91,14 +91,14 @@ add the following projected volume instead of a Secret-based volume for the non-
This projected volume consists of three sources:
1. A ServiceAccountToken acquired from kube-apiserver via TokenRequest API. It will expire after 1 hour by default or when the pod is deleted. It is bound to the pod and has kube-apiserver as the audience.
1. A ConfigMap containing a CA bundle used for verifying connections to the kube-apiserver. This feature depends on the `RootCAConfigMap` feature gate being enabled, which publishes a "kube-root-ca.crt" ConfigMap to every namespace. `RootCAConfigMap` is enabled by default in 1.20, and always enabled in 1.21+.
1. A ConfigMap containing a CA bundle used for verifying connections to the kube-apiserver. This feature depends on the `RootCAConfigMap` feature gate, which publishes a "kube-root-ca.crt" ConfigMap to every namespace. `RootCAConfigMap` feature gate is graduated to GA in 1.21 and default to true. (This flag will be removed from --feature-gate arg in 1.22)
1. A DownwardAPI that references the namespace of the pod.
See more details about [projected volumes](/docs/tasks/configure-pod-container/configure-projected-volume-storage/).
You can manually migrate a secret-based service account volume to a projected volume when
You can manually migrate a Secret-based service account volume to a projected volume when
the `BoundServiceAccountTokenVolume` feature gate is not enabled by adding the above
projected volume to the pod spec. However, `RootCAConfigMap` needs to be enabled.
projected volume to the pod spec.
### Token Controller
@@ -852,7 +852,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `ValidateProxyRedirects`: This flag controls whether the API server should
validate that redirects are only followed to the same host. Only used if the
`StreamingProxyRedirects` flag is enabled.
- 'VolumeCapacityPriority`: Enable support for prioritizing nodes in different
- `VolumeCapacityPriority`: Enable support for prioritizing nodes in different
topologies based on available PV capacity.
- `VolumePVCDataSource`: Enable support for specifying an existing PVC as a DataSource.
- `VolumeScheduling`: Enable volume topology aware scheduling and make the
@@ -222,7 +222,9 @@ When a single IngressClass resource has this annotation set to `"true"`, new Ing
## kubernetes.io/ingress.class (deprecated)
{{< note >}} Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassName`. {{< /note >}}
{{< note >}}
Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassName`.
{{< /note >}}
## storageclass.kubernetes.io/is-default-class
@@ -230,7 +232,8 @@ Example: `storageclass.kubernetes.io/is-default-class=true`
Used on: StorageClass
When a single StorageClass resource has this annotation set to `"true"`, new Physical Volume Claim resource without a class specified will be assigned this default class.
When a single StorageClass resource has this annotation set to `"true"`, new PersistentVolumeClaim
resource without a class specified will be assigned this default class.
## alpha.kubernetes.io/provided-node-ip
@@ -49,7 +49,7 @@ Some resource types will have one or more sub-resources, represented as sub path
* Cluster-scoped subresource: `GET /apis/GROUP/VERSION/RESOURCETYPE/NAME/SUBRESOURCE`
* Namespace-scoped subresource: `GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME/SUBRESOURCE`
The verbs supported for each subresource will differ depending on the object - see the API documentation more information. It is not possible to access sub-resources across multiple resources - generally a new virtual resource type would be used if that becomes necessary.
The verbs supported for each subresource will differ depending on the object - see the API documentation for more information. It is not possible to access sub-resources across multiple resources - generally a new virtual resource type would be used if that becomes necessary.
## Efficient detection of changes
@@ -442,7 +442,7 @@ feature, see the section on
## Resource Versions
Resource versions are strings that identify the server's internal version of an object. Resource versions can be used by clients to determine when objects have changed, or to express data consistency requirements when getting, listing and watching resources. Resource versions must be treated as opaque by clients and passed unmodified back to the server. For example, clients must not assume resource versions are numeric, and may only compare two resource version for equality (i.e. must not compare resource versions for greater-than or less-than relationships).
Resource versions are strings that identify the server's internal version of an object. Resource versions can be used by clients to determine when objects have changed, or to express data consistency requirements when getting, listing and watching resources. Resource versions must be treated as opaque by clients and passed unmodified back to the server. For example, clients must not assume resource versions are numeric, and may only compare two resource versions for equality (i.e. must not compare resource versions for greater-than or less-than relationships).
### ResourceVersion in metadata
@@ -454,7 +454,7 @@ Clients find resource versions in resources, including the resources in watch ev
### The ResourceVersion Parameter
The get, list and watch operations support the `resourceVersion` parameter.
The get, list, and watch operations support the `resourceVersion` parameter.
The exact meaning of this parameter differs depending on the operation and the value of `resourceVersion`.
@@ -245,7 +245,7 @@ field tags.
### Compatibility across topology changes
On rare occurences, a CRD or built-in type author may want to change the
On rare occurrences, a CRD or built-in type author may want to change the
specific topology of a field in their resource without incrementing its
version. Changing the topology of types, by upgrading the cluster or
updating the CRD, has different consequences when updating existing
@@ -253,7 +253,7 @@ objects. There are two categories of changes: when a field goes from
`map`/`set`/`granular` to `atomic` and the other way around.
When the `listType`, `mapType`, or `structType` changes from
`map`/`set`/`granular` to `atomic`, the whole list, map or struct of
`map`/`set`/`granular` to `atomic`, the whole list, map, or struct of
existing objects will end-up being owned by actors who owned an element
of these types. This means that any further change to these objects
would cause a conflict.
@@ -310,7 +310,7 @@ simplify the update logic of your controller. The main differences with a
read-modify-write and/or patch are the following:
* the applied object must contain all the fields that the controller cares about.
* there are no way to remove fields that haven't been applied by the controller
* there is no way to remove fields that haven't been applied by the controller
before (controller can still send a PATCH/UPDATE for these use-cases).
* the object doesn't have to be read beforehand, `resourceVersion` doesn't have
to be specified.
@@ -473,7 +473,7 @@ have an opinion about.
## Clearing ManagedFields
It is possible to strip all managedFields from an object by overwriting them
using `MergePatch`, `StrategicMergePatch`, `JSONPatch` or `Update`, so every
using `MergePatch`, `StrategicMergePatch`, `JSONPatch`, or `Update`, so every
non-apply operation. This can be done by overwriting the managedFields field
with an empty entry. Two examples are:
@@ -23,7 +23,7 @@ of Containers for each.
- Fetch all Pods in all namespaces using `kubectl get pods --all-namespaces`
- Format the output to include only the list of Container image names
using `-o jsonpath={..image}`. This will recursively parse out the
using `-o jsonpath={.items[*].spec.containers[*].image}`. This will recursively parse out the
`image` field from the returned json.
- See the [jsonpath reference](/docs/reference/kubectl/jsonpath/)
for further information on how to use jsonpath.
@@ -33,7 +33,7 @@ of Containers for each.
- Use `uniq` to aggregate image counts
```shell
kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
tr -s '[[:space:]]' '\n' |\
sort |\
uniq -c
@@ -80,7 +80,7 @@ To target only Pods matching a specific label, use the -l flag. The
following matches only Pods with labels matching `app=nginx`.
```shell
kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
```
## List Container images filtering by Pod namespace
@@ -89,7 +89,7 @@ To target only pods in a specific namespace, use the namespace flag. The
following matches only Pods in the `kube-system` namespace.
```shell
kubectl get pods --namespace kube-system -o jsonpath="{..image}"
kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}"
```
## List Container images using a go-template instead of jsonpath
@@ -26,7 +26,7 @@ volume is automatically deleted when a user deletes the corresponding
PersistentVolumeClaim. This automatic behavior might be inappropriate if the volume
contains precious data. In that case, it is more appropriate to use the "Retain"
policy. With the "Retain" policy, if a user deletes a PersistentVolumeClaim,
the corresponding PersistentVolume is not be deleted. Instead, it is moved to the
the corresponding PersistentVolume will not be deleted. Instead, it is moved to the
Released phase, where all of its data can be manually recovered.
## Changing the reclaim policy of a PersistentVolume
@@ -1,16 +1,17 @@
---
reviewers:
- jszczepkowski
title: Set up High-Availability Kubernetes Masters
title: Set up a High-Availability Control Plane
content_type: task
aliases: [ '/docs/tasks/administer-cluster/highly-available-master/' ]
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.5" state="alpha" >}}
You can replicate Kubernetes masters in `kube-up` or `kube-down` scripts for Google Compute Engine.
This document describes how to use kube-up/down scripts to manage highly available (HA) masters and how HA masters are implemented for use with GCE.
You can replicate Kubernetes control plane nodes in `kube-up` or `kube-down` scripts for Google Compute Engine.
This document describes how to use kube-up/down scripts to manage a highly available (HA) control plane and how HA control planes are implemented for use with GCE.
@@ -28,17 +29,17 @@ This document describes how to use kube-up/down scripts to manage highly availab
To create a new HA-compatible cluster, you must set the following flags in your `kube-up` script:
* `MULTIZONE=true` - to prevent removal of master replicas kubelets from zones different than server's default zone.
Required if you want to run master replicas in different zones, which is recommended.
* `MULTIZONE=true` - to prevent removal of control plane kubelets from zones different than server's default zone.
Required if you want to run control plane nodes in different zones, which is recommended.
* `ENABLE_ETCD_QUORUM_READ=true` - to ensure that reads from all API servers will return most up-to-date data.
If true, reads will be directed to leader etcd replica.
Setting this value to true is optional: reads will be more reliable but will also be slower.
Optionally, you can specify a GCE zone where the first master replica is to be created.
Optionally, you can specify a GCE zone where the first control plane node is to be created.
Set the following flag:
* `KUBE_GCE_ZONE=zone` - zone where the first master replica will run.
* `KUBE_GCE_ZONE=zone` - zone where the first control plane node will run.
The following sample command sets up a HA-compatible cluster in the GCE zone europe-west1-b:
@@ -46,50 +47,52 @@ The following sample command sets up a HA-compatible cluster in the GCE zone eur
MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
```
Note that the commands above create a cluster with one master;
however, you can add new master replicas to the cluster with subsequent commands.
Note that the commands above create a cluster with one control plane node;
however, you can add new control plane nodes to the cluster with subsequent commands.
## Adding a new master replica
## Adding a new control plane node
After you have created an HA-compatible cluster, you can add master replicas to it.
You add master replicas by using a `kube-up` script with the following flags:
After you have created an HA-compatible cluster, you can add control plane nodes to it.
You add control plane nodes by using a `kube-up` script with the following flags:
* `KUBE_REPLICATE_EXISTING_MASTER=true` - to create a replica of an existing
master.
* `KUBE_REPLICATE_EXISTING_MASTER=true` - to create a replica of an existing control plane
node.
* `KUBE_GCE_ZONE=zone` - zone where the master replica will run.
Must be in the same region as other replicas' zones.
* `KUBE_GCE_ZONE=zone` - zone where the control plane node will run.
Must be in the same region as other control plane nodes' zones.
You don't need to set the `MULTIZONE` or `ENABLE_ETCD_QUORUM_READS` flags,
as those are inherited from when you started your HA-compatible cluster.
The following sample command replicates the master on an existing HA-compatible cluster:
The following sample command replicates the control plane node on an existing
HA-compatible cluster:
```shell
KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
```
## Removing a master replica
## Removing a control plane node
You can remove a master replica from an HA cluster by using a `kube-down` script with the following flags:
You can remove a control plane node from an HA cluster by using a `kube-down` script with the following flags:
* `KUBE_DELETE_NODES=false` - to restrain deletion of kubelets.
* `KUBE_GCE_ZONE=zone` - the zone from where master replica will be removed.
* `KUBE_GCE_ZONE=zone` - the zone from where the control plane node will be removed.
* `KUBE_REPLICA_NAME=replica_name` - (optional) the name of master replica to remove.
If empty: any replica from the given zone will be removed.
* `KUBE_REPLICA_NAME=replica_name` - (optional) the name of control plane node to
remove. If empty: any replica from the given zone will be removed.
The following sample command removes a master replica from an existing HA cluster:
The following sample command removes a control plane node from an existing HA cluster:
```shell
KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
```
## Handling master replica failures
## Handling control plane node failures
If one of the master replicas in your HA cluster fails,
the best practice is to remove the replica from your cluster and add a new replica in the same zone.
If one of the control plane nodes in your HA cluster fails,
the best practice is to remove the node from your cluster and add a new control plane
node in the same zone.
The following sample commands demonstrate this process:
1. Remove the broken replica:
@@ -98,26 +101,31 @@ The following sample commands demonstrate this process:
KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
```
<ol start="2"><li>Add a new replica in place of the old one:</li></ol>
<ol start="2"><li>Add a new node in place of the old one:</li></ol>
```shell
KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
```
## Best practices for replicating masters for HA clusters
## Best practices for replicating control plane nodes for HA clusters
* Try to place master replicas in different zones. During a zone failure, all masters placed inside the zone will fail.
* Try to place control plane nodes in different zones. During a zone failure, all
control plane nodes placed inside the zone will fail.
To survive zone failure, also place nodes in multiple zones
(see [multiple-zones](/docs/setup/best-practices/multiple-zones/) for details).
* Do not use a cluster with two master replicas. Consensus on a two-replica cluster requires both replicas running when changing persistent state.
As a result, both replicas are needed and a failure of any replica turns cluster into majority failure state.
A two-replica cluster is thus inferior, in terms of HA, to a single replica cluster.
* Do not use a cluster with two control plane nodes. Consensus on a two-node
control plane requires both nodes running when changing persistent state.
As a result, both nodes are needed and a failure of any node turns the cluster
into majority failure state.
A two-node control plane is thus inferior, in terms of HA, to a cluster with
one control plane node.
* When you add a master replica, cluster state (etcd) is copied to a new instance.
* When you add a control plane node, cluster state (etcd) is copied to a new instance.
If the cluster is large, it may take a long time to duplicate its state.
This operation may be sped up by migrating etcd data directory, as described [here](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration)
(we are considering adding support for etcd data dir migration in future).
This operation may be sped up by migrating the etcd data directory, as described in
the [etcd administration guide](https://etcd.io/docs/v2.3/admin_guide/#member-migration)
(we are considering adding support for etcd data dir migration in the future).
@@ -129,7 +137,7 @@ This operation may be sped up by migrating etcd data directory, as described [he
### Overview
Each of master replicas will run the following components in the following mode:
Each of the control plane nodes will run the following components in the following mode:
* etcd instance: all instances will be clustered together using consensus;
@@ -143,9 +151,9 @@ In addition, there will be a load balancer in front of API servers that will rou
### Load balancing
When starting the second master replica, a load balancer containing the two replicas will be created
When starting the second control plane node, a load balancer containing the two replicas will be created
and the IP address of the first replica will be promoted to IP address of load balancer.
Similarly, after removal of the penultimate master replica, the load balancer will be removed and its IP address will be assigned to the last remaining replica.
Similarly, after removal of the penultimate control plane node, the load balancer will be removed and its IP address will be assigned to the last remaining replica.
Please note that creation and removal of load balancer are complex operations and it may take some time (~20 minutes) for them to propagate.
### Master service & kubelets
@@ -153,17 +161,17 @@ Please note that creation and removal of load balancer are complex operations an
Instead of trying to keep an up-to-date list of Kubernetes apiserver in the Kubernetes service,
the system directs all traffic to the external IP:
* in one master cluster the IP points to the single master,
* in case of a single node control plane, the IP points to the control plane node,
* in multi-master cluster the IP points to the load balancer in-front of the masters.
* in case of an HA control plane, the IP points to the load balancer in-front of the masters.
Similarly, the external IP will be used by kubelets to communicate with master.
Similarly, the external IP will be used by kubelets to communicate with the control plane.
### Master certificates
### Control plane node certificates
Kubernetes generates Master TLS certificates for the external public IP and local IP for each replica.
There are no certificates for the ephemeral public IP for replicas;
to access a replica via its ephemeral public IP, you must skip TLS verification.
Kubernetes generates TLS certificates for the external public IP and local IP for each control plane node.
There are no certificates for the ephemeral public IP for control plane nodes;
to access a control plane node via its ephemeral public IP, you must skip TLS verification.
### Clustering etcd
@@ -172,7 +180,7 @@ To make such deployment secure, communication between etcd instances is authoriz
### API server identity
{{< feature-state state="alpha" for_k8s_version="v1.20" >}}
{{< feature-state state="alpha" for_k8s_version="v1.20" >}}
The API Server Identity feature is controlled by a
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
@@ -188,7 +188,7 @@ To install a specific version of containerD specify the version with -ContainerD
```powershell
# Example
.\Install-Containerd.ps1 -ContainerDVersion v1.4.1
.\Install-Containerd.ps1 -ContainerDVersion 1.4.1
```
{{< /note >}}
@@ -23,7 +23,7 @@ You need to have a Kubernetes cluster and the kubectl command-line tool must be
## Set the Username for a Pod
To specify the username with which to execute the Pod's container processes, include the `securityContext` field ([PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core) in the Pod specification, and within it, the `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core) field containing the `runAsUserName` field.
To specify the username with which to execute the Pod's container processes, include the `securityContext` field ([PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)) in the Pod specification, and within it, the `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core)) field containing the `runAsUserName` field.
The Windows security context options that you specify for a Pod apply to all Containers and init Containers in the Pod.
@@ -63,7 +63,7 @@ ContainerUser
## Set the Username for a Container
To specify the username with which to execute a Container's processes, include the `securityContext` field ([SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)) in the Container manifest, and within it, the `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core) field containing the `runAsUserName` field.
To specify the username with which to execute a Container's processes, include the `securityContext` field ([SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)) in the Container manifest, and within it, the `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core)) field containing the `runAsUserName` field.
The Windows security context options that you specify for a Container apply only to that individual Container, and they override the settings made at the Pod level.
@@ -167,8 +167,8 @@ The output is similar to this:
Name: build-robot-secret
Namespace: default
Labels: <none>
Annotations: kubernetes.io/service-account.name=build-robot
kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da
Annotations: kubernetes.io/service-account.name: build-robot
kubernetes.io/service-account.uid: da68f9c6-9d26-11e7-b84e-002dc52800da
Type: kubernetes.io/service-account-token
@@ -54,7 +54,7 @@ If you use a Docker credentials store, you won't see that `auth` entry but a `cr
## Create a Secret based on existing Docker credentials {#registry-secret-existing-credentials}
A Kubernetes cluster uses the Secret of `docker-registry` type to authenticate with
A Kubernetes cluster uses the Secret of `kubernetes.io/dockerconfigjson` type to authenticate with
a container registry to pull a private image.
If you already ran `docker login`, you can copy that credential into Kubernetes:
@@ -45,8 +45,12 @@ kubectl create namespace qos-example
For a Pod to be given a QoS class of Guaranteed:
* Every Container, including init containers, in the Pod must have a memory limit and a memory request, and they must be the same.
* Every Container, including init containers, in the Pod must have a CPU limit and a CPU request, and they must be the same.
* Every Container in the Pod must have a memory limit and a memory request.
* For every Container in the Pod, the memory limit must equal the memory request.
* Every Container in the Pod must have a CPU limit and a CPU request.
* For every Container in the Pod, the CPU limit must equal the CPU request.
These restrictions apply to init containers and app containers equally.
Here is the configuration file for a Pod that has one Container. The Container has a memory limit and a
memory request, both equal to 200 MiB. The Container has a CPU limit and a CPU request, both equal to 700 milliCPU:
@@ -272,5 +276,3 @@ kubectl delete namespace qos-example
@@ -1,371 +0,0 @@
---
reviewers:
- piosz
- x13n
title: Logging Using Stackdriver
content_type: concept
---
<!-- overview -->
Before reading this page, it's highly recommended to familiarize yourself
with the [overview of logging in Kubernetes](/docs/concepts/cluster-administration/logging).
{{< note >}}
By default, Stackdriver logging collects only your container's standard output and
standard error streams. To collect any logs your application writes to a file (for example),
see the [sidecar approach](/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent)
in the Kubernetes logging overview.
{{< /note >}}
<!-- body -->
## Deploying
To ingest logs, you must deploy the Stackdriver Logging agent to each node in your cluster.
The agent is a configured `fluentd` instance, where the configuration is stored in a `ConfigMap`
and the instances are managed using a Kubernetes `DaemonSet`. The actual deployment of the
`ConfigMap` and `DaemonSet` for your cluster depends on your individual cluster setup.
### Deploying to a new cluster
#### Google Kubernetes Engine
Stackdriver is the default logging solution for clusters deployed on Google Kubernetes Engine.
Stackdriver Logging is deployed to a new cluster by default unless you explicitly opt-out.
#### Other platforms
To deploy Stackdriver Logging on a *new* cluster that you're
creating using `kube-up.sh`, do the following:
1. Set the `KUBE_LOGGING_DESTINATION` environment variable to `gcp`.
1. **If not running on GCE**, include the `beta.kubernetes.io/fluentd-ds-ready=true`
in the `KUBE_NODE_LABELS` variable.
Once your cluster has started, each node should be running the Stackdriver Logging agent.
The `DaemonSet` and `ConfigMap` are configured as addons. If you're not using `kube-up.sh`,
consider starting a cluster without a pre-configured logging solution and then deploying
Stackdriver Logging agents to the running cluster.
{{< warning >}}
The Stackdriver logging daemon has known issues on platforms other
than Google Kubernetes Engine. Proceed at your own risk.
{{< /warning >}}
### Deploying to an existing cluster
1. Apply a label on each node, if not already present.
The Stackdriver Logging agent deployment uses node labels to determine to which nodes
it should be allocated. These labels were introduced to distinguish nodes with the
Kubernetes version 1.6 or higher. If the cluster was created with Stackdriver Logging
configured and node has version 1.5.X or lower, it will have fluentd as static pod. Node
cannot have more than one instance of fluentd, therefore only apply labels to the nodes
that don't have fluentd pod allocated already. You can ensure that your node is labelled
properly by running `kubectl describe` as follows:
```
kubectl describe node $NODE_NAME
```
The output should be similar to this:
```
Name: NODE_NAME
Role:
Labels: beta.kubernetes.io/fluentd-ds-ready=true
...
```
Ensure that the output contains the label `beta.kubernetes.io/fluentd-ds-ready=true`. If it
is not present, you can add it using the `kubectl label` command as follows:
```
kubectl label node $NODE_NAME beta.kubernetes.io/fluentd-ds-ready=true
```
{{< note >}}
If a node fails and has to be recreated, you must re-apply the label to
the recreated node. To make this easier, you can use Kubelet's command-line parameter
for applying node labels in your node startup script.
{{< /note >}}
1. Deploy a `ConfigMap` with the logging agent configuration by running the following command:
```
kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-configmap.yaml
```
The command creates the `ConfigMap` in the `default` namespace. You can download the file
manually and change it before creating the `ConfigMap` object.
1. Deploy the logging agent `DaemonSet` by running the following command:
```
kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-ds.yaml
```
You can download and edit this file before using it as well.
## Verifying your Logging Agent Deployment
After Stackdriver `DaemonSet` is deployed, you can discover logging agent deployment status
by running the following command:
```shell
kubectl get ds --all-namespaces
```
If you have 3 nodes in the cluster, the output should looks similar to this:
```
NAMESPACE NAME DESIRED CURRENT READY NODE-SELECTOR AGE
...
default fluentd-gcp-v2.0 3 3 3 beta.kubernetes.io/fluentd-ds-ready=true 5m
...
```
To understand how logging with Stackdriver works, consider the following
synthetic log generator pod specification [counter-pod.yaml](/examples/debug/counter-pod.yaml):
{{< codenew file="debug/counter-pod.yaml" >}}
This pod specification has one container that runs a bash script
that writes out the value of a counter and the datetime once per
second, and runs indefinitely. Let's create this pod in the default namespace.
```shell
kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
```
You can observe the running pod:
```shell
kubectl get pods
```
```
NAME READY STATUS RESTARTS AGE
counter 1/1 Running 0 5m
```
For a short period of time you can observe the 'Pending' pod status, because the kubelet
has to download the container image first. When the pod status changes to `Running`
you can use the `kubectl logs` command to view the output of this counter pod.
```shell
kubectl logs counter
```
```
0: Mon Jan 1 00:00:00 UTC 2001
1: Mon Jan 1 00:00:01 UTC 2001
2: Mon Jan 1 00:00:02 UTC 2001
...
```
As described in the logging overview, this command fetches log entries
from the container log file. If the container is killed and then restarted by
Kubernetes, you can still access logs from the previous container. However,
if the pod is evicted from the node, log files are lost. Let's demonstrate this
by deleting the currently running counter container:
```shell
kubectl delete pod counter
```
```
pod "counter" deleted
```
and then recreating it:
```shell
kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml
```
```
pod/counter created
```
After some time, you can access logs from the counter pod again:
```shell
kubectl logs counter
```
```
0: Mon Jan 1 00:01:00 UTC 2001
1: Mon Jan 1 00:01:01 UTC 2001
2: Mon Jan 1 00:01:02 UTC 2001
...
```
As expected, only recent log lines are present. However, for a real-world
application you will likely want to be able to access logs from all containers,
especially for the debug purposes. This is exactly when the previously enabled
Stackdriver Logging can help.
## Viewing logs
Stackdriver Logging agent attaches metadata to each log entry, for you to use later
in queries to select only the messages you're interested in: for example,
the messages from a particular pod.
The most important pieces of metadata are the resource type and log name.
The resource type of a container log is `container`, which is named
`GKE Containers` in the UI (even if the Kubernetes cluster is not on Google Kubernetes Engine).
The log name is the name of the container, so that if you have a pod with
two containers, named `container_1` and `container_2` in the spec, their logs
will have log names `container_1` and `container_2` respectively.
System components have resource type `compute`, which is named
`GCE VM Instance` in the interface. Log names for system components are fixed.
For a Google Kubernetes Engine node, every log entry from a system component has one of the following
log names:
* docker
* kubelet
* kube-proxy
You can learn more about viewing logs on [the dedicated Stackdriver page](https://cloud.google.com/logging/docs/view/logs_viewer).
One of the possible ways to view logs is using the
[`gcloud logging`](https://cloud.google.com/logging/docs/api/gcloud-logging)
command line interface from the [Google Cloud SDK](https://cloud.google.com/sdk/).
It uses Stackdriver Logging [filtering syntax](https://cloud.google.com/logging/docs/view/advanced_filters)
to query specific logs. For example, you can run the following command:
```none
gcloud beta logging read 'logName="projects/$YOUR_PROJECT_ID/logs/count"' --format json | jq '.[].textPayload'
```
```
...
"2: Mon Jan 1 00:01:02 UTC 2001\n"
"1: Mon Jan 1 00:01:01 UTC 2001\n"
"0: Mon Jan 1 00:01:00 UTC 2001\n"
...
"2: Mon Jan 1 00:00:02 UTC 2001\n"
"1: Mon Jan 1 00:00:01 UTC 2001\n"
"0: Mon Jan 1 00:00:00 UTC 2001\n"
```
As you can see, it outputs messages for the count container from both
the first and second runs, despite the fact that the kubelet already deleted
the logs for the first container.
### Exporting logs
You can export logs to [Google Cloud Storage](https://cloud.google.com/storage/)
or to [BigQuery](https://cloud.google.com/bigquery/) to run further
analysis. Stackdriver Logging offers the concept of sinks, where you can
specify the destination of log entries. More information is available on
the Stackdriver [Exporting Logs page](https://cloud.google.com/logging/docs/export/configure_export_v2).
## Configuring Stackdriver Logging Agents
Sometimes the default installation of Stackdriver Logging may not suit your needs, for example:
* You may want to add more resources because default performance doesn't suit your needs.
* You may want to introduce additional parsing to extract more metadata from your log messages,
like severity or source code reference.
* You may want to send logs not only to Stackdriver or send it to Stackdriver only partially.
In this case you need to be able to change the parameters of `DaemonSet` and `ConfigMap`.
### Prerequisites
If you're using GKE and Stackdriver Logging is enabled in your cluster, you
cannot change its configuration, because it's managed and supported by GKE.
However, you can disable the default integration and deploy your own.
{{< note >}}
You will have to support and maintain a newly deployed configuration
yourself: update the image and configuration, adjust the resources and so on.
{{< /note >}}
To disable the default logging integration, use the following command:
```
gcloud beta container clusters update --logging-service=none CLUSTER
```
You can find notes on how to then install Stackdriver Logging agents into
a running cluster in the [Deploying section](#deploying).
### Changing `DaemonSet` parameters
When you have the Stackdriver Logging `DaemonSet` in your cluster, you can modify the
`template` field in its spec. The DaemonSet controller manages the pods for you.
For example, assume you've installed the Stackdriver Logging as described above. Now you want to
change the memory limit to give fluentd more memory to safely process more logs.
Get the spec of `DaemonSet` running in your cluster:
```shell
kubectl get ds fluentd-gcp-v2.0 --namespace kube-system -o yaml > fluentd-gcp-ds.yaml
```
Then edit resource requirements in the spec file and update the `DaemonSet` object
in the apiserver using the following command:
```shell
kubectl replace -f fluentd-gcp-ds.yaml
```
After some time, Stackdriver Logging agent pods will be restarted with the new configuration.
### Changing fluentd parameters
Fluentd configuration is stored in the `ConfigMap` object. It is effectively a set of configuration
files that are merged together. You can learn about fluentd configuration on the
[official site](https://docs.fluentd.org).
Imagine you want to add a new parsing logic to the configuration, so that fluentd can understand
default Python logging format. An appropriate fluentd filter looks similar to this:
```
<filter reform.**>
type parser
format /^(?<severity>\w):(?<logger_name>\w):(?<log>.*)/
reserve_data true
suppress_parse_error_log true
key_name log
</filter>
```
Now you have to put it in the configuration and make Stackdriver Logging agents pick it up.
Get the current version of the Stackdriver Logging `ConfigMap` in your cluster
by running the following command:
```shell
kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp-configmap.yaml
```
Then in the value of the key `containers.input.conf` insert a new filter right after
the `source` section.
{{< note >}}
Order is important.
{{< /note >}}
Updating `ConfigMap` in the apiserver is more complicated than updating `DaemonSet`. It's better
to consider `ConfigMap` to be immutable. Then, in order to update the configuration, you should
create `ConfigMap` with a new name and then change `DaemonSet` to point to it
using [guide above](#changing-daemonset-parameters).
### Adding fluentd plugins
Fluentd is written in Ruby and allows to extend its capabilities using
[plugins](https://www.fluentd.org/plugins). If you want to use a plugin, which is not included
in the default Stackdriver Logging container image, you have to build a custom image. Imagine
you want to add Kafka sink for messages from a particular container for additional processing.
You can re-use the default [container image sources](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image)
with minor changes:
* Change Makefile to point to your container repository, for example `PREFIX=gcr.io/<your-project-id>`.
* Add your dependency to the Gemfile, for example `gem 'fluent-plugin-kafka'`.
Then run `make build push` from this directory. After updating `DaemonSet` to pick up the
new image, you can use the plugin you installed in the fluentd configuration.
@@ -80,7 +80,7 @@ Removing an old version:
If this occurs, switch back to using `served:true` on the old version, migrate the
remaining clients to the new version and repeat this step.
1. Ensure the [upgrade of existing objects to the new stored version](#upgrade-existing-objects-to-a-new-stored-version) step has been completed.
1. Verify that the `stored` is set to `true` for the new version in the `spec.versions` list in the CustomResourceDefinition.
1. Verify that the `storage` is set to `true` for the new version in the `spec.versions` list in the CustomResourceDefinition.
1. Verify that the old version is no longer listed in the CustomResourceDefinition `status.storedVersions`.
1. Remove the old version from the CustomResourceDefinition `spec.versions` list.
1. Drop conversion support for the old version in conversion webhooks.
@@ -180,7 +180,7 @@ spec:
containers:
- name: app
image: my-app
volumeMount:
volumeMounts:
- name: config
mountPath: /config
volumes:
@@ -234,7 +234,7 @@ spec:
containers:
- image: my-app
name: app
volumeMount:
volumeMounts:
- mountPath: /config
name: config
volumes:
@@ -327,7 +327,7 @@ spec:
containers:
- name: app
image: my-app
volumeMount:
volumeMounts:
- name: password
mountPath: /secrets
volumes:
@@ -31,6 +31,7 @@ The following methods exist for installing kubectl on macOS:
{{< tabs name="download_binary_macos" >}}
{{< tab name="Intel" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
chmod +x kubectl
{{< /tab >}}
{{< tab name="Apple Silicon" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl"
+2
View File
@@ -192,6 +192,8 @@ GitHub team: [@kubernetes/sig-release-leads](https://github.com/orgs/kubernetes/
### Technical Leads
- Adolfo García Veytia ([@puerco](https://github.com/puerco))
- Carlos Panato ([@cpanato](https://github.com/cpanato))
- Daniel Mangum ([@hasheddan](https://github.com/hasheddan))
- Jeremy Rickard ([@jeremyrickard](https://github.com/jeremyrickard))
@@ -2,7 +2,7 @@
title: Container Runtime
id: container-runtime
date: 2019-06-05
full_link: /docs/reference/generated/container-runtime
full_link: /docs/setup/production-environment/container-runtimes
short_description: >
L'environnement d'exécution de conteneurs est le logiciel responsable de l'exécution des conteneurs.
@@ -225,7 +225,7 @@ Si la startup probe ne réussit jamais, le conteneur est tué après 300s puis s
Parfois, les applications sont temporairement incapables de servir le trafic.
Par exemple, une application peut avoir besoin de charger des larges données ou des fichiers de configuration pendant le démarrage, ou elle peut dépendre de services externes après le démarrage.
Dans ces cas, vous ne voulez pas tuer l'application, mais tu ne veux pas non plus lui envoyer de requêtes. Kubernetes fournit des readiness probes pour détecter et atténuer ces situations. Un pod avec des conteneurs qui signale qu'elle n'est pas prête ne reçoit pas de trafic par les services de Kubernetes.
Dans ces cas, vous ne voulez pas tuer l'application, mais vous ne voulez pas non plus lui envoyer de requêtes. Kubernetes fournit des readiness probes pour détecter et atténuer ces situations. Un pod avec des conteneurs qui signale qu'elle n'est pas prête ne reçoit pas de trafic par les services de Kubernetes.
{{< note >}}
Readiness probes fonctionnent sur le conteneur pendant tout son cycle de vie.
@@ -237,7 +237,7 @@ kubeletは、`tmpfs`のemptyDirボリュームをローカルのエフェメラ
### ローカルのエフェメラルストレージの要求と制限設定
ローカルのエフェメラルストレージを管理するためには_ephemeral-storage_パラメーターを利用することができます。
ローカルのエフェメラルストレージを管理するためには _ephemeral-storage_ パラメーターを利用することができます。
Podの各コンテナは、次の1つ以上を指定できます。
* `spec.containers[].resources.limits.ephemeral-storage`
* `spec.containers[].resources.requests.ephemeral-storage`
@@ -58,11 +58,11 @@ weight: 10
## ラベルの使用
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの__セマンティック属性__を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tierfrontend`を持つPodを選択するServiceや、`appmyapp`に属するすべての`phasetest`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの __セマンティック属性__ を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tierfrontend`を持つPodを選択するServiceや、`appmyapp`に属するすべての`phasetest`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。
セレクターからリリース固有のラベルを省略することで、Serviceを複数のDeploymentにまたがるように作成できます。 [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)により、ダウンタイムなしで実行中のサービスを簡単に更新できます。
オブジェクトの望ましい状態はDeploymentによって記述され、その仕様への変更が_適用_されると、Deploymentコントローラは制御された速度で実際の状態を望ましい状態に変更します。
オブジェクトの望ましい状態はDeploymentによって記述され、その仕様への変更が _適用_ されると、Deploymentコントローラは制御された速度で実際の状態を望ましい状態に変更します。
- デバッグ用にラベルを操作できます。Kubernetesコントローラー(ReplicaSetなど)とServiceはセレクターラベルを使用してPodとマッチするため、Podから関連ラベルを削除すると、コントローラーによって考慮されたり、Serviceによってトラフィックを処理されたりすることがなくなります。既存のPodのラベルを削除すると、そのコントローラーはその代わりに新しいPodを作成します。これは、「隔離」環境で以前の「ライブ」Podをデバッグするのに便利な方法です。対話的にラベルを削除または追加するには、[`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)を使います。
@@ -140,7 +140,7 @@ RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSele
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
Podが稼働する時に関連する_オーバーヘッド_リソースを指定できます。オーバーヘッドを宣言すると、クラスター(スケジューラーを含む)がPodとリソースに関する決定を行うときにオーバーヘッドを考慮することができます。
Podが稼働する時に関連する _オーバーヘッド_ リソースを指定できます。オーバーヘッドを宣言すると、クラスター(スケジューラーを含む)がPodとリソースに関する決定を行うときにオーバーヘッドを考慮することができます。
Podオーバーヘッドを使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではonです)
PodのオーバーヘッドはRuntimeClass内の`overhead`フィールドによって定義されます。
@@ -83,7 +83,7 @@ Nodeにラベルを付与することで、Podは特定のNodeやNodeグルー
`NodeRestriction`プラグインは、kubeletが`node-restriction.kubernetes.io/`プレフィックスを有するラベルの設定や上書きを防ぎます。
Nodeの隔離にラベルのプレフィックスを使用するためには、以下のようにします。
1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が_有効_になっていること。
1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が _有効_ になっていること。
2. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。
例えば、`example.com.node-restriction.kubernetes.io/fips=true` または `example.com.node-restriction.kubernetes.io/pci-dss=true`のようなラベルです。
@@ -26,11 +26,11 @@ kube-schedulerは、もし希望するのであれば自分自身でスケジュ
kube-schedulerは、新規に作成された各Podや他のスケジューリングされていないPodを稼働させるために最適なNodeを選択します。
しかし、Pod内の各コンテナにはそれぞれ異なるリソースの要件があり、各Pod自体にもそれぞれ異なる要件があります。そのため、既存のNodeは特定のスケジューリング要求によってフィルターされる必要があります。
クラスター内でPodに対する割り当て要求を満たしたNodeは_割り当て可能_ なNodeと呼ばれます。
クラスター内でPodに対する割り当て要求を満たしたNodeは _割り当て可能_ なNodeと呼ばれます。
もし適切なNodeが一つもない場合、スケジューラーがNodeを割り当てることができるまで、そのPodはスケジュールされずに残ります。
スケジューラーはPodに対する割り当て可能なNodeをみつけ、それらの割り当て可能なNodeにスコアをつけます。その中から最も高いスコアのNodeを選択し、Podに割り当てるためのいくつかの関数を実行します。
スケジューラーは_binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったNodeの情報を通知します。
スケジューラーは _binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったNodeの情報を通知します。
スケジューリングを決定する上で考慮が必要な要素としては、個別または複数のリソース要求や、ハードウェア/ソフトウェアのポリシー制約、affinityやanti-affinityの設定、データの局所性や、ワークロード間での干渉などが挙げられます。
@@ -52,7 +52,7 @@ _スコアリング_ ステップでは、Podを割り当てるのに最も適
スケジューラーのフィルタリングとスコアリングの動作に関する設定には2つのサポートされた手法があります。
1. [スケジューリングポリシー](/docs/reference/scheduling/policies) は、フィルタリングのための_Predicates_とスコアリングのための_Priorities_の設定することができます。
1. [スケジューリングポリシー](/docs/reference/scheduling/policies) は、フィルタリングのための _Predicates_ とスコアリングのための _Priorities_ の設定することができます。
1. [スケジューリングプロファイル](/docs/reference/scheduling/config/#profiles)は、`QueueSort``Filter``Score``Bind``Reserve``Permit`やその他を含む異なるスケジューリングの段階を実装するプラグインを設定することができます。kube-schedulerを異なるプロファイルを実行するように設定することもできます。
@@ -95,7 +95,7 @@ Serviceは多くの場合、KubernetesのPodに対するアクセスを抽象化
* Serviceを、異なる{{< glossary_tooltip term_id="namespace" >}}のServiceや他のクラスターのServiceに向ける場合
* ワークロードをKubernetesに移行するとき、アプリケーションに対する処理をしながら、バックエンドの一部をKubernetesで実行する場合
このような場合において、ユーザーはPodセレクター_なしで_ Serviceを定義できます。
このような場合において、ユーザーはPodセレクター*なしで*Serviceを定義できます。
```yaml
apiVersion: v1
@@ -882,7 +882,7 @@ Kubernetesは各Serviceに、それ自身のIPアドレスを割り当てるこ
### ServiceのIPアドレス {#ips-and-vips}
実際に固定された向き先であるPodのIPアドレスとは異なり、ServiceのIPは実際には単一のホストによって応答されません。
その代わり、kube-proxyは必要な時に透過的にリダイレクトされる_仮想_ IPアドレスを定義するため、iptables(Linuxのパケット処理ロジック)を使用します。
その代わり、kube-proxyは必要な時に透過的にリダイレクトされる*仮想*IPアドレスを定義するため、iptables(Linuxのパケット処理ロジック)を使用します。
クライアントがVIPに接続する時、そのトラフィックは自動的に適切なEndpointsに転送されます。
Service用の環境変数とDNSは、Serviceの仮想IPアドレス(とポート)の面において、自動的に生成されます。
@@ -55,7 +55,7 @@ kubectl proxy
kubectlは、ダッシュボードを http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ で利用できるようにします。
UIはコマンドを実行しているマシンから_のみ_ アクセスできます。オプションについては`kubectl proxy --help`を参照してください。
UIはコマンドを実行しているマシンから _のみ_ アクセスできます。オプションについては`kubectl proxy --help`を参照してください。
{{< note >}}
Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベースの認証には対応していません。
@@ -75,16 +75,16 @@ git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes
### Настройка переменных для сборки
* `K8S_ROOT` со значением `<k8s-base>`.
* `WEB_ROOT` со значением `<web-base>`.
* `K8S_WEBROOT` со значением `<web-base>`.
* `K8S_RELEASE` со значением нужной версии документации.
Например, если вы хотите собрать документацию для Kubernetes версии 1.17, определите переменную окружения `K8S_RELEASE` со значением 1.17.
Например, если вы хотите собрать документацию для Kubernetes версии 1.17.0, определите переменную окружения `K8S_RELEASE` со значением 1.17.0.
Примеры:
```shell
export WEB_ROOT=$(GOPATH)/src/github.com/<your-username>/website
export K8S_WEBROOT=$(GOPATH)/src/github.com/<your-username>/website
export K8S_ROOT=$(GOPATH)/src/k8s.io/kubernetes
export K8S_RELEASE=1.17
export K8S_RELEASE=1.17.0
```
### Создание версионированной директории и получение Open API spec
@@ -113,8 +113,8 @@ make copyapi
Убедитесь в том, что перечисленные ниже два файлы были сгенерированы:
```shell
[ -e "<rdocs-base>/gen-apidocs/generators/build/index.html" ] && echo "index.html built" || echo "no index.html"
[ -e "<rdocs-base>/gen-apidocs/generators/build/navData.js" ] && echo "navData.js built" || echo "no navData.js"
[ -e "<rdocs-base>/gen-apidocs/build/index.html" ] && echo "index.html built" || echo "no index.html"
[ -e "<rdocs-base>/gen-apidocs/build/navData.js" ] && echo "navData.js built" || echo "no navData.js"
```
Перейдите в корень директории `<web-base>` и посмотрите, какие файлы были изменены:
@@ -2,7 +2,7 @@
title: Среда выполнения контейнера
id: container-runtime
date: 2019-06-05
full_link: /docs/reference/generated/container-runtime
full_link: /docs/setup/production-environment/container-runtimes
short_description: >
Среда выполнения контейнера — это программа, предназначенная для выполнения контейнеров.
@@ -313,6 +313,4 @@ Pod 开销通过 RuntimeClass 的 `overhead` 字段定义。
- [RuntimeClass 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
- [RuntimeClass 调度设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
- 阅读关于 [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/) 的概念
- [PodOverhead 特性设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
- [PodOverhead 特性设计](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)
@@ -1,5 +1,53 @@
---
title: 调度和驱逐 (Scheduling and Eviction)
title: 调度,抢占和驱逐
weight: 90
description: 在Kubernetes中,调度 (Scheduling) 指的是确保 Pods 匹配到合适的节点,以便 kubelet 能够运行它们。驱逐 (Eviction) 是在资源匮乏的节点上,主动让一个或多个 Pods 失效的过程。
content_type: concept
description: >
在Kubernetes中,调度 (scheduling) 指的是确保 Pods 匹配到合适的节点,
以便 kubelet 能够运行它们。抢占 (Preemption) 指的是终止低优先级的 Pods 以便高优先级的 Pods 可以
调度运行的过程。驱逐 (Eviction) 是在资源匮乏的节点上,主动让一个或多个 Pods 失效的过程。
---
<!--
---
title: "Scheduling, Preemption and Eviction"
weight: 90
content_type: concept
description: >
In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes
so that the kubelet can run them. Preemption is the process of terminating
Pods with lower Priority so that Pods with higher Priority can schedule on
Nodes. Eviction is the process of proactively terminating one or more Pods on
resource-starved Nodes.
no_list: true
---
-->
<!--
In Kubernetes, scheduling refers to making sure that {{<glossary_tooltip text="Pods" term_id="pod">}}
are matched to {{<glossary_tooltip text="Nodes" term_id="node">}} so that the
{{<glossary_tooltip text="kubelet" term_id="kubelet">}} can run them. Preemption
is the process of terminating Pods with lower {{<glossary_tooltip text="Priority" term_id="pod-priority">}}
so that Pods with higher Priority can schedule on Nodes. Eviction is the process
of terminating one or more Pods on Nodes.
-->
<!-- ## Scheduling -->
## 调度
* [Kubernetes 调度器](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)
* [将 Pods 指派到节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)
* [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/)
* [污点和容忍](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)
* [调度框架](/zh/docs/concepts/scheduling-eviction/scheduling-framework)
* [调度器的性能调试](/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
* [扩展资源的资源装箱](/zh/docs/concepts/scheduling-eviction/resource-bin-packing/)
<!-- ## Pod Disruption -->
## Pod 干扰
* [Pod 优先级和抢占](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)
* [节点压力驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)
* [API发起的驱逐](/zh/docs/concepts/scheduling-eviction/api-eviction/)
@@ -75,9 +75,9 @@ Run `kubectl get nodes` to get the names of your cluster's nodes. Pick out the o
执行 `kubectl get nodes` 命令获取集群的节点名称。
选择一个你要增加标签的节点,然后执行
`kubectl label nodes <node-name> <label-key>=<label-value>`
`kubectl label nodes <node-name> <label-key>=<label-value>`
命令将标签添加到你所选择的节点上。
例如,如果你的节点名称为 'kubernetes-foo-node-1.c.a-robinson.internal'
例如,如果你的节点名称为 'kubernetes-foo-node-1.c.a-robinson.internal'
并且想要的标签是 'disktype=ssd',则可以执行
`kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd` 命令。
@@ -136,8 +136,18 @@ with a standard set of labels. See [Well-Known Labels, Annotations and Taints](/
-->
## 插曲:内置的节点标签 {#built-in-node-labels}
除了你[添加](#attach-labels-to-node)的标签外,节点还预先填充了一组标准标签。
参见[常用标签注解污点](/zh/docs/reference/labels-annotations-taints/)
除了你[添加](#step-one-attach-label-to-the-node)的标签外,节点还预了一组标准标签。
参见这些[常用标签注解以及污点](/zh/docs/reference/labels-annotations-taints/)
* [`kubernetes.io/hostname`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname)
* [`failure-domain.beta.kubernetes.io/zone`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone)
* [`failure-domain.beta.kubernetes.io/region`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion)
* [`topology.kubernetes.io/zone`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
* [`topology.kubernetes.io/region`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
* [`beta.kubernetes.io/instance-type`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type)
* [`node.kubernetes.io/instance-type`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type)
* [`kubernetes.io/os`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os)
* [`kubernetes.io/arch`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch)
{{< note >}}
<!--
@@ -181,7 +191,7 @@ To make use of that label prefix for node isolation:
For example, `example.com.node-restriction.kubernetes.io/fips=true` or `example.com.node-restriction.kubernetes.io/pci-dss=true`.
-->
1. 检查是否在使用 Kubernetes v1.11+,以便 NodeRestriction 功能可用。
2. 确保你在使用[节点授权](/zh/docs/reference/access-authn-authz/node/)并且已经_启用_
2. 确保你在使用[节点授权](/zh/docs/reference/access-authn-authz/node/)并且已经_启用_
[NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)。
3. 将 `node-restriction.kubernetes.io/` 前缀下的标签添加到 Node 对象,
然后在节点选择器中使用这些标签。
@@ -574,7 +584,7 @@ must be satisfied for the pod to be scheduled onto a node.
<!--
Users can also select matching namespaces using `namespaceSelector`, which is a label query over the set of namespaces.
The affinity term is applied to the union of the namespaces selected by `namespaceSelector` and the ones listed in the `namespaces` field.
Note that an empty `namespaceSelector` ({}) matches all namespaces, while a null or empty `namespaces` list and
Note that an empty `namespaceSelector` ({}) matches all namespaces, while a null or empty `namespaces` list and
null `namespaceSelector` means "this pod's namespace".
-->
用户也可以使用 `namespaceSelector` 选择匹配的名字空间,`namespaceSelector`
@@ -828,4 +838,3 @@ resource allocation decisions.
一旦 Pod 分配给 节点,kubelet 应用将运行该 pod 并且分配节点本地资源。
[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/)
可以参与到节点级别的资源分配决定中。
@@ -1,9 +1,21 @@
---
title: Pod 开销
content_type: concept
weight: 20
weight: 30
---
<!--
---
reviewers:
- dchen1107
- egernst
- tallclair
title: Pod Overhead
content_type: concept
weight: 30
---
-->
<!-- overview -->
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
@@ -58,7 +70,7 @@ across your cluster, and a `RuntimeClass` is utilized which defines the `overhea
您需要确保在集群中启用了 `PodOverhead` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
(在 1.18 默认是开启的),以及一个用于定义 `overhead` 字段的 `RuntimeClass`
<!--
<!--
## Usage example
-->
## 使用示例
@@ -85,7 +97,7 @@ overhead:
cpu: "250m"
```
<!--
<!--
Workloads which are created which specify the `kata-fc` RuntimeClass handler will take the memory and
cpu overheads into account for resource quota calculations, node scheduling, as well as Pod cgroup sizing.
@@ -119,7 +131,7 @@ spec:
memory: 100Mi
```
<!--
<!--
At admission time the RuntimeClass [admission controller](/docs/reference/access-authn-authz/admission-controllers/)
updates the workload's PodSpec to include the `overhead` as described in the RuntimeClass. If the PodSpec already has this field defined,
the Pod will be rejected. In the given example, since only the RuntimeClass name is specified, the admission controller mutates the Pod
@@ -129,7 +141,7 @@ to include an `overhead`.
RuntimeClass 中定义的 `overhead`. 如果 PodSpec 中该字段已定义,该 Pod 将会被拒绝。
在这个例子中,由于只指定了 RuntimeClass 名称,所以准入控制器更新了 Pod, 包含了一个 `overhead`.
<!--
<!--
After the RuntimeClass admission controller, you can check the updated PodSpec:
-->
在 RuntimeClass 准入控制器之后,可以检验一下已更新的 PodSpec:
@@ -138,7 +150,7 @@ After the RuntimeClass admission controller, you can check the updated PodSpec:
kubectl get pod test-pod -o jsonpath='{.spec.overhead}'
```
<!--
<!--
The output is:
-->
输出:
@@ -146,25 +158,25 @@ The output is:
map[cpu:250m memory:120Mi]
```
<!--
<!--
If a ResourceQuota is defined, the sum of container requests as well as the
`overhead` field are counted.
-->
如果定义了 ResourceQuata, 则容器请求的总量以及 `overhead` 字段都将计算在内。
<!--
<!--
When the kube-scheduler is deciding which node should run a new Pod, the scheduler considers that Pod's
`overhead` as well as the sum of container requests for that Pod. For this example, the scheduler adds the
requests and the overhead, then looks for a node that has 2.25 CPU and 320 MiB of memory available.
-->
当 kube-scheduler 决定在哪一个节点调度运行新的 Pod 时,调度器会兼顾该 Pod 的 `overhead` 以及该 Pod 的容器请求总量。在这个示例中,调度器将资源请求和开销相加,然后寻找具备 2.25 CPU 和 320 MiB 内存可用的节点。
<!--
<!--
Once a Pod is scheduled to a node, the kubelet on that node creates a new {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}
for the Pod. It is within this pod that the underlying container runtime will create containers. -->
一旦 Pod 调度到了某个节点, 该节点上的 kubelet 将为该 Pod 新建一个 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}. 底层容器运行时将在这个 pod 中创建容器。
<!--
<!--
If the resource has a limit defined for each container (Guaranteed QoS or Bustrable QoS with limits defined),
the kubelet will set an upper limit for the pod cgroup associated with that resource (cpu.cfs_quota_us for CPU
and memory.limit_in_bytes memory). This upper limit is based on the sum of the container limits plus the `overhead`
@@ -179,7 +191,7 @@ requests plus the `overhead` defined in the PodSpec.
-->
对于 CPU, 如果 Pod 的 QoS 是 Guaranteed 或者 Burstable, kubelet 会基于容器请求总量与 PodSpec 中定义的 `overhead` 之和设置 `cpu.shares`.
<!--
<!--
Looking at our example, verify the container requests for the workload:
-->
请看这个例子,验证工作负载的容器请求:
@@ -187,7 +199,7 @@ Looking at our example, verify the container requests for the workload:
kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}'
```
<!--
<!--
The total container requests are 2000m CPU and 200MiB of memory:
-->
容器请求总计 2000m CPU 和 200MiB 内存:
@@ -195,7 +207,7 @@ The total container requests are 2000m CPU and 200MiB of memory:
map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi]
```
<!--
<!--
Check this against what is observed by the node:
-->
对照从节点观察到的情况来检查一下:
@@ -203,7 +215,7 @@ Check this against what is observed by the node:
kubectl describe node | grep test-pod -B2
```
<!--
<!--
The output shows 2250m CPU and 320MiB of memory are requested, which includes PodOverhead:
-->
该输出显示请求了 2250m CPU 以及 320MiB 内存,包含了 PodOverhead 在内:
@@ -226,8 +238,9 @@ cgroups directly on the node.
First, on the particular node, determine the Pod identifier:
-->
在工作负载所运行的节点上检查 Pod 的内存 cgroups. 在接下来的例子中,将在该节点上使用具备 CRI 兼容的容器运行时命令行工具 [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md).
这是一个展示 PodOverhead 行为的进阶示例,用户并不需要直接在该节点上检查 cgroups.
在工作负载所运行的节点上检查 Pod 的内存 cgroups. 在接下来的例子中,
将在该节点上使用具备 CRI 兼容的容器运行时命令行工具
[`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)。
首先在特定的节点上确定该 Pod 的标识符:
@@ -240,7 +253,7 @@ First, on the particular node, determine the Pod identifier:
POD_ID="$(sudo crictl pods --name test-pod -q)"
```
<!--
<!--
From this, you can determine the cgroup path for the Pod:
-->
可以依此判断该 Pod 的 cgroup 路径:
@@ -254,7 +267,7 @@ From this, you can determine the cgroup path for the Pod:
sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath
```
<!--
<!--
The resulting cgroup path includes the Pod's `pause` container. The Pod level cgroup is one directory above.
-->
执行结果的 cgroup 路径中包含了该 Pod 的 `pause` 容器。Pod 级别的 cgroup 即上面的一个目录。
@@ -262,7 +275,7 @@ The resulting cgroup path includes the Pod's `pause` container. The Pod level cg
"cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a"
```
<!--
<!--
In this specific case, the pod cgroup path is `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`. Verify the Pod level cgroup setting for memory:
-->
在这个例子中,该 pod 的 cgroup 路径是 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`。验证内存的 Pod 级别 cgroup 设置:
@@ -278,7 +291,7 @@ In this specific case, the pod cgroup path is `kubepods/podd7f4b509-cf94-4951-94
cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes
```
<!--
<!--
This is 320 MiB, as expected:
-->
和预期的一样是 320 MiB
@@ -286,7 +299,7 @@ This is 320 MiB, as expected:
335544320
```
<!--
<!--
### Observability
-->
### 可观察性
@@ -298,8 +311,11 @@ running with a defined Overhead. This functionality is not available in the 1.9
kube-state-metrics, but is expected in a following release. Users will need to build kube-state-metrics
from source in the meantime.
-->
在 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 中可以通过 `kube_pod_overhead` 指标来协助确定何时使用 PodOverhead 以及协助观察以一个既定开销运行的工作负载的稳定性。
该特性在 kube-state-metrics 的 1.9 发行版本中不可用,不过预计将在后续版本中发布。在此之前,用户需要从源代码构建 kube-state-metrics.
在 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 中可以通过
`kube_pod_overhead` 指标来协助确定何时使用 PodOverhead 以及协助观察以一个既定
开销运行的工作负载的稳定性。
该特性在 kube-state-metrics 的 1.9 发行版本中不可用,不过预计将在后续版本中发布。
在此之前,用户需要从源代码构建 kube-state-metrics。
## {{% heading "whatsnext" %}}
@@ -310,4 +326,3 @@ from source in the meantime.
* [RuntimeClass](/zh/docs/concepts/containers/runtime-class/)
* [PodOverhead 设计](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)
@@ -1,16 +1,18 @@
---
title: 扩展资源的资源装箱
content_type: concept
weight: 30
weight: 80
---
<!--
---
reviewers:
- bsalamat
- k82cn
- ahg-g
title: Resource Bin Packing for Extended Resources
content_type: concept
weight: 30
weight: 80
---
-->
<!-- overview -->
@@ -18,7 +20,7 @@ weight: 30
{{< feature-state for_k8s_version="1.16" state="alpha" >}}
<!--
The kube-scheduler can be configured to enable bin packing of resources along with extended resources using `RequestedToCapacityRatioResourceAllocation` priority function. Priority functions can be used to fine-tune the kube-scheduler as per custom needs.
The kube-scheduler can be configured to enable bin packing of resources along with extended resources using `RequestedToCapacityRatioResourceAllocation` priority function. Priority functions can be used to fine-tune the kube-scheduler as per custom needs.
-->
使用 `RequestedToCapacityRatioResourceAllocation` 优先级函数,可以将 kube-scheduler
@@ -48,7 +50,7 @@ Kubernetes 1.16 在优先级函数中添加了一个新参数,该参数允许
least requested)或
最多请求(most requested)计算。
`resources` 包含由 `name``weight` 组成,`name` 指定评分时要考虑的资源,
`weight` 指定每种资源的权重。
`weight` 指定每种资源的权重。
<!--
Below is an example configuration that sets `requestedToCapacityRatioArguments` to bin packing behavior for extended resources `intel.com/foo` and `intel.com/bar`
@@ -130,7 +132,7 @@ The above arguments give the node a score of 0 if utilization is 0% and 10 for u
```
<!--
It can be used to add extended resources as follows:
It can be used to add extended resources as follows:
-->
它可以用来添加扩展资源,如下所示:
@@ -249,4 +251,3 @@ CPU = resourceScoringFunction((2+6),8)
NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)
= 7
```
@@ -1,14 +1,16 @@
---
title: 调度器性能调优
content_type: concept
weight: 80
weight: 100
---
<!--
---
reviewers:
- bsalamat
title: Scheduler Performance Tuning
content_type: concept
weight: 80
weight: 100
---
-->
<!-- overview -->
@@ -45,7 +47,7 @@ large Kubernetes clusters.
<!-- body -->
<!--
<!--
In large clusters, you can tune the scheduler's behaviour balancing
scheduling outcomes between latency (new Pods are placed quickly) and
accuracy (the scheduler rarely makes poor placement decisions).
@@ -60,12 +62,12 @@ a threshold for scheduling nodes in your cluster.
你可以通过设置 kube-scheduler 的 `percentageOfNodesToScore` 来配置这个调优设置。
这个 KubeSchedulerConfiguration 设置决定了调度集群中节点的阈值。
<!--
<!--
### Setting the threshold
-->
### 设置阈值
<!--
<!--
The `percentageOfNodesToScore` option accepts whole numeric values between 0
and 100. The value 0 is a special number which indicates that the kube-scheduler
should use its compiled-in default.
@@ -77,17 +79,17 @@ had set a value of 100.
如果你设置 `percentageOfNodesToScore` 的值超过了 100
kube-scheduler 的表现等价于设置值为 100。
<!--
<!--
To change the value, edit the
[kube-scheduler configuration file](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
and then restart the scheduler.
In many cases, the configuration file can be found at `/etc/kubernetes/config/kube-scheduler.yaml`.
-->
要修改这个值,编辑 [kube-scheduler 的配置文件](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/)
后重启调度器。
在很多场合下,配置文件位于 `/etc/kubernetes/config/kube-scheduler.yaml`
In many cases, the configuration file can be found at `/etc/kubernetes/config/kube-scheduler.yaml`
-->
要修改这个值,编辑 [kube-scheduler 的配置文件](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/)
后重启调度器。
大多数情况下,这个配置文件 `/etc/kubernetes/config/kube-scheduler.yaml`
<!--
<!--
After you have made this change, you can run
-->
修改完成后,你可以执行
@@ -96,17 +98,17 @@ After you have made this change, you can run
kubectl get pods -n kube-system | grep kube-scheduler
```
<!--
<!--
to verify that the kube-scheduler component is healthy.
-->
来检查该 kube-scheduler 组件是否健康。
<!--
<!--
## Node scoring threshold {#percentage-of-nodes-to-score}
-->
## 节点打分阈值 {#percentage-of-nodes-to-score}
<!--
<!--
To improve scheduling performance, the kube-scheduler can stop looking for
feasible nodes once it has found enough of them. In large clusters, this saves
time compared to a naive approach that would consider every node.
@@ -114,7 +116,7 @@ time compared to a naive approach that would consider every node.
要提升调度性能,kube-scheduler 可以在找到足够的可调度节点之后停止查找。
在大规模集群中,比起考虑每个节点的简单方法相比可以节省时间。
<!--
<!--
You specify a threshold for how many nodes are enough, as a whole number percentage
of all the nodes in your cluster. The kube-scheduler converts this into an
integer number of nodes. During scheduling, if the kube-scheduler has identified
@@ -122,24 +124,24 @@ enough feasible nodes to exceed the configured percentage, the kube-scheduler
stops searching for more feasible nodes and moves on to the
[scoring phase](/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation).
-->
你可以使用整个集群节点总数的百分比作为阈值来指定需要多少节点就足够。
你可以使用整个集群节点总数的百分比作为阈值来指定需要多少节点就足够。
kube-scheduler 会将它转换为节点数的整数值。在调度期间,如果
kube-scheduler 已确认的可调度节点数足以超过了配置的百分比数量,
kube-scheduler 将停止继续查找可调度节点并继续进行
[打分阶段](/zh/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)。
<!--
<!--
[How the scheduler iterates over Nodes](#how-the-scheduler-iterates-over-nodes)
describes the process in detail.
-->
[调度器如何遍历节点](#how-the-scheduler-iterates-over-nodes) 详细介绍了这个过程。
<!--
<!--
### Default threshold
-->
### 默认阈值
<!--
<!--
If you don't specify a threshold, Kubernetes calculates a figure using a
linear formula that yields 50% for a 100-node cluster and yields 10%
for a 5000-node cluster. The lower bound for the automatic value is 5%.
@@ -147,20 +149,20 @@ for a 5000-node cluster. The lower bound for the automatic value is 5%.
如果你不指定阈值,Kubernetes 使用线性公式计算出一个比例,在 100-节点集群
下取 50%,在 5000-节点的集群下取 10%。这个自动设置的参数的最低值是 5%。
<!--
<!--
This means that, the kube-scheduler always scores at least 5% of your cluster no
matter how large the cluster is, unless you have explicitly set
`percentageOfNodesToScore` to be smaller than 5.
-->
这意味着,调度器至少会对集群中 5% 的节点进行打分,除非用户将该参数设置的低于 5。
<!--
<!--
If you want the scheduler to score all nodes in your cluster, set
`percentageOfNodesToScore` to 100.
-->
如果你想让调度器对集群内所有节点进行打分,则将 `percentageOfNodesToScore` 设置为 100。
<!--
<!--
## Example
-->
## 示例
@@ -189,15 +191,15 @@ percentageOfNodesToScore: 50
<!--
`percentageOfNodesToScore` must be a value between 1 and 100 with the default
value being calculated based on the cluster size. There is also a hardcoded
minimum value of 50 nodes.
minimum value of 50 nodes.
-->
`percentageOfNodesToScore` 的值必须在 1 到 100 之间,而且其默认值是通过集群的规模计算得来的。
另外,还有一个 50 个 Node 的最小值是硬编码在程序中。
<!--
In clusters with less than 50 feasible nodes, the scheduler still
{{< note >}} In clusters with less than 50 feasible nodes, the scheduler still
checks all the nodes because there are not enough feasible nodes to stop
the scheduler's search early.
the scheduler's search early.
In a small cluster, if you set a low value for `percentageOfNodesToScore`, your
change will have no or little effect, for a similar reason.
@@ -294,8 +296,8 @@ After going over all the Nodes, it goes back to Node 1.
-->
在评估完所有 Node 后,将会返回到 Node 1,从头开始。
## {{% heading "whatsnext" %}}
* 查阅 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/)
<!-- * Check the [kube-scheduler configuration reference (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) -->
* 参见 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/)
@@ -1,15 +1,17 @@
---
title: 调度框架
content_type: concept
weight: 70
weight: 90
---
<!--
---
reviewers:
- ahg-g
title: Scheduling Framework
content_type: concept
weight: 70
weight: 90
---
-->
<!-- overview -->
@@ -17,17 +19,15 @@ weight: 70
{{< feature-state for_k8s_version="1.15" state="alpha" >}}
<!--
The scheduling framework is a plugable architecture for the Kubernetes Scheduler.
It adds a new set of "plugin" APIs to the existing scheduler. Plugins are compiled
into the scheduler. The APIs allow most scheduling features to be implemented as
plugins, while keeping the
scheduling "core" simple and maintainable. Refer to the [design proposal of the
The scheduling framework is a pluggable architecture for the Kubernetes scheduler.
It adds a new set of "plugin" APIs to the existing scheduler. Plugins are compiled into the scheduler. The APIs allow most scheduling features to be implemented as plugins, while keeping the
scheduling "core" lightweight and maintainable. Refer to the [design proposal of the
scheduling framework][kep] for more technical information on the design of the
framework.
-->
调度框架是 Kubernetes 调度器的一种可插入架构。
调度框架向现有的调度器增加了一组新的“插件(Plugin)” API。
插件被编译到调度器程序中。
调度框架是面向 Kubernetes 调度器的一种插件架构,
它为现有的调度器添加了一组新的“插件” API。插件会被编译到调度器中。
这些 API 允许大多数调度功能以插件的形式实现,同时使调度“核心”保持简单且可维护。
请参考[调度框架的设计提案](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/624-scheduling-framework/README.md)
获取框架设计的更多技术信息。
@@ -98,7 +98,7 @@ stateful tasks.
-->
一个插件可以在多个扩展点处注册,以执行更复杂或有状态的任务。
<!--
<!--
{{< figure src="/images/docs/scheduling-framework-extensions.png" title="scheduling framework extension points" >}}
-->
{{< figure src="/images/docs/scheduling-framework-extensions.png" title="调度框架扩展点" >}}
@@ -163,12 +163,12 @@ tries to make the pod schedulable by preempting other Pods.
则其余的插件不会调用。典型的后筛选实现是抢占,试图通过抢占其他 Pod
的资源使该 Pod 可以调度。
<!--
<!--
### PreScore {#pre-score}
-->
### 前置评分 {#pre-score}
<!--
<!--
These plugins are used to perform "pre-scoring" work, which generates a sharable
state for Score plugins to use. If a PreScore plugin returns an error, the
scheduling cycle is aborted.
@@ -176,7 +176,7 @@ scheduling cycle is aborted.
前置评分插件用于执行 “前置评分” 工作,即生成一个可共享状态供评分插件使用。
如果 PreScore 插件返回错误,则调度周期将终止。
<!--
<!--
### Score {#scoring}
-->
### 评分 {#scoring}
@@ -325,17 +325,17 @@ _Permit_ 插件在每个 Pod 调度周期的最后调用,用于防止或延迟
将返回调度队列,从而触发 [Unreserve](#unreserve) 插件。
<!--
<!--
While any plugin can access the list of "waiting" Pods and approve them
(see [`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle)), we expect only the permit
plugins to approve binding of reserved Pods that are in "waiting" state. Once a Pod
is approved, it is sent to the [PreBind](#pre-bind) phase.
-->
{{< note >}}
尽管任何插件可以访问 “等待中” 状态的 Pod 列表并批准它们
(参阅 [`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle)
我们望只有允许插件可以批准处于“等待中”状态的预留 Pod 的绑定。
一旦 Pod 被批准了,它将进入到[预绑定](#pre-bind) 阶段。
尽管任何插件可以访问 “等待中” 状态的 Pod 列表并批准它们
(查看 [`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle))
我们望只有允许插件可以批准处于 “等待中” 状态的预留 Pod 的绑定。
一旦 Pod 被批准了,它将发送到[预绑定](#pre-bind) 阶段。
{{< /note >}}
<!--
@@ -444,7 +444,7 @@ type PreFilterPlugin interface {
-->
# 插件配置
<!--
<!--
You can enable or disable plugins in the scheduler configuration. If you are using
Kubernetes v1.18 or later, most scheduling
[plugins](/docs/reference/scheduling/config/#scheduling-plugins) are in use and
@@ -455,7 +455,7 @@ enabled by default.
[插件](/zh/docs/reference/scheduling/config/#scheduling-plugins)
都在使用中且默认启用。
<!--
<!--
In addition to default plugins, you can also implement your own scheduling
plugins and get them configured along with default plugins. You can visit
[scheduler-plugins](https://github.com/kubernetes-sigs/scheduler-plugins) for more details.
@@ -464,7 +464,7 @@ plugins and get them configured along with default plugins. You can visit
你可以访问[scheduler-plugins](https://github.com/kubernetes-sigs/scheduler-plugins)
了解更多信息。
<!--
<!--
If you are using Kubernetes v1.18 or later, you can configure a set of plugins as
a scheduler profile and then define multiple profiles to fit various kinds of workload.
Learn more at [multiple profiles](/docs/reference/scheduling/config/#multiple-profiles).
@@ -472,4 +472,3 @@ Learn more at [multiple profiles](/docs/reference/scheduling/config/#multiple-pr
如果你正在使用 Kubernetes v1.18 或更高版本,你可以将一组插件设置为
一个调度器配置文件,然后定义不同的配置文件来满足各类工作负载。
了解更多关于[多配置文件](/zh/docs/reference/scheduling/config/#multiple-profiles)。
@@ -357,9 +357,9 @@ true. The following taints are built in:
the NodeCondition `Ready` being "`False`".
* `node.kubernetes.io/unreachable`: Node is unreachable from the node
controller. This corresponds to the NodeCondition `Ready` being "`Unknown`".
* `node.kubernetes.io/out-of-disk`: Node becomes out of disk.
* `node.kubernetes.io/memory-pressure`: Node has memory pressure.
* `node.kubernetes.io/disk-pressure`: Node has disk pressure.
* `node.kubernetes.io/pid-pressure`: Node has PID pressure.
* `node.kubernetes.io/network-unavailable`: Node's network is unavailable.
* `node.kubernetes.io/unschedulable`: Node is unschedulable.
* `node.cloudprovider.kubernetes.io/uninitialized`: When the kubelet is started
@@ -371,9 +371,9 @@ true. The following taints are built in:
* `node.kubernetes.io/not-ready`:节点未准备好。这相当于节点状态 `Ready` 的值为 "`False`"。
* `node.kubernetes.io/unreachable`:节点控制器访问不到节点. 这相当于节点状态 `Ready` 的值为 "`Unknown`"。
* `node.kubernetes.io/out-of-disk`:节点磁盘耗尽。
* `node.kubernetes.io/memory-pressure`:节点存在内存压力。
* `node.kubernetes.io/disk-pressure`:节点存在磁盘压力。
* `node.kubernetes.io/pid-pressure`: 节点的 PID 压力。
* `node.kubernetes.io/network-unavailable`:节点网络不可用。
* `node.kubernetes.io/unschedulable`: 节点不可调度。
* `node.cloudprovider.kubernetes.io/uninitialized`:如果 kubelet 启动时指定了一个 "外部" 云平台驱动,
@@ -486,7 +486,7 @@ breaking.
* `node.kubernetes.io/memory-pressure`
* `node.kubernetes.io/disk-pressure`
* `node.kubernetes.io/out-of-disk` (*only for critical pods*)
* `node.kubernetes.io/pid-pressure` (1.14 or later)
* `node.kubernetes.io/unschedulable` (1.10 or later)
* `node.kubernetes.io/network-unavailable` (*host network only*)
-->
@@ -498,7 +498,7 @@ DaemonSet 控制器自动为所有守护进程添加如下 `NoSchedule` 容忍
* `node.kubernetes.io/memory-pressure`
* `node.kubernetes.io/disk-pressure`
* `node.kubernetes.io/out-of-disk` (*只适合关键 Pod*)
* `node.kubernetes.io/pid-pressure` (1.14 或更高版本)
* `node.kubernetes.io/unschedulable` (1.10 或更高版本)
* `node.kubernetes.io/network-unavailable` (*只适合主机网络配置*)
@@ -135,7 +135,7 @@ Kubernetes 集群中的 Pod 主要有两种用法:
* **运行多个协同工作的容器的 Pod**
Pod 可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。
这些位于同一位置的容器可能形成单个内聚的服务单元 —— 一个容器将文件从共享卷提供给公众,
而另一个单独的“挂斗”(sidecar)容器则刷新或更新这些文件。
而另一个单独的“边车”(sidecar)容器则刷新或更新这些文件。
Pod 将这些容器和存储资源打包为一个可管理的实体。
{{< note >}}
@@ -170,7 +170,7 @@ in your pod spec can also cause voluntary (and involuntary) disruptions.
实现可能导致碎片整理和紧缩节点的自愿干扰。集群
管理员或托管提供商应该已经记录了各级别的自愿干扰(如果有的话)。
有些配置选项,例如在 pod spec 中
[使用 PriorityClasses]https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/
[使用 PriorityClasses](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)
也会产生自愿(和非自愿)的干扰。
<!--
@@ -151,7 +151,7 @@ for examples of troubleshooting using ephemeral containers.
<!--
## Ephemeral containers API
-->
### 临时容器 API {#ephemeral-containers-api}
### 临时容器 API {#ephemeral-containers-api}
{{< note >}}
<!--
@@ -460,7 +460,7 @@ Website 的仓库中 `scripts/linkchecker.py` 是一个工具,可用来检查
- service discovery,服务发现
- service mesh,服务网格
- session,会话
- sidecar挂斗
- sidecar边车
- skew,偏移
- spec,规约
- specification,规约
+84 -24
View File
@@ -15,6 +15,7 @@ linkTitle: "Reference"
main_menu: true
weight: 70
content_type: concept
no_list: true
-->
<!-- overview -->
@@ -29,16 +30,26 @@ This section of the Kubernetes documentation contains references.
<!--
## API Reference
* [API Reference for Kubernetes {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
* [Glossary](/docs/reference/glossary/) - a comprehensive, standardized list of Kubernetes terminology
* [Kubernetes API Reference](/docs/reference/kubernetes-api/)
* [One-page API Reference for Kubernetes {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
* [Using The Kubernetes API](/docs/reference/using-api/) - overview of the API for Kubernetes.
* [API access control](/docs/reference/access-authn-authz/) - details on how Kubernetes controls API access
* [Well-Known Labels, Annotations and Taints](/docs/reference/labels-annotations-taints/)
-->
## API 参考
* [术语表](/zh/docs/reference/glossary/) - 一个全面的标准化的 Kubernetes 术语表
* [Kubernetes API 单页参考](/zh/docs/reference/kubernetes-api/)
* [Kubernetes API 参考 {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。
* [使用 Kubernetes API ](/zh/docs/reference/using-api/) - Kubernetes 的 API 概述
* [API 的访问控制](/zh/docs/reference/access-authn-authz/) - 关于 Kubernetes 如何控制 API 访问的详细信息
* [常见的标签、注解和污点](/zh/docs/reference/labels-annotations-taints/)
<!--
## API Client Libraries
## Officially supported client libraries
To call the Kubernetes API from a programming language, you can use
[client libraries](/docs/reference/using-api/client-libraries/). Officially supported
@@ -48,8 +59,10 @@ client libraries:
- [Kubernetes Python client library](https://github.com/kubernetes-client/python)
- [Kubernetes Java client library](https://github.com/kubernetes-client/java)
- [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript)
- [Kubernetes Dotnet client library](https://github.com/kubernetes-client/csharp)
- [Kubernetes Haskell Client library](https://github.com/kubernetes-client/haskell)
-->
## API 客户端库
## 官方支持的客户端库
如果您需要通过编程语言调用 Kubernetes API,您可以使用
[客户端库](/zh/docs/reference/using-api/client-libraries/)。以下是官方支持的客户端库:
@@ -58,16 +71,17 @@ client libraries:
- [Kubernetes Python 语言客户端库](https://github.com/kubernetes-client/python)
- [Kubernetes Java 语言客户端库](https://github.com/kubernetes-client/java)
- [Kubernetes JavaScript 语言客户端库](https://github.com/kubernetes-client/javascript)
- [Kubernetes Dotnet 语言客户端库](https://github.com/kubernetes-client/csharp)
- [Kubernetes Haskell 语言客户端库](https://github.com/kubernetes-client/haskell)
<!--
## CLI Reference
## CLI
* [kubectl](/docs/user-guide/kubectl-overview) - Main CLI tool for running commands and managing Kubernetes clusters.
* [JSONPath](/docs/user-guide/jsonpath/) - Syntax guide for using [JSONPath expressions](http://goessner.net/articles/JsonPath/) with kubectl.
* [kubeadm](/docs/admin/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster.
* [kubefed](/docs/admin/kubefed/) - CLI tool to help you administrate your federated clusters.
* [kubectl](/docs/reference/kubectl/overview/) - Main CLI tool for running commands and managing Kubernetes clusters.
* [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](https://goessner.net/articles/JsonPath/) with kubectl.
* [kubeadm](/docs/reference/setup-tools/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster.
-->
## CLI 参考
## CLI
* [kubectl](/zh/docs/reference/kubectl/overview/) - 主要的 CLI 工具,用于运行命令和管理 Kubernetes 集群。
* [JSONPath](/zh/docs/reference/kubectl/jsonpath/) - 通过 kubectl 使用
@@ -75,29 +89,75 @@ client libraries:
* [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) - 此 CLI 工具可轻松配置安全的 Kubernetes 集群。
<!--
## Components Reference
## Components
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - The primary *node agent* that runs on each node. The kubelet takes a set of PodSpecs and ensures that the described containers are running and healthy.
* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - REST API that validates and configures data for API objects such as pods, services, replication controllers.
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - The
primary agent that runs on each node. The kubelet takes a set of PodSpecs
and ensures that the described containers are running and healthy.
* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) -
REST API that validates and configures data for API objects such as pods,
services, replication controllers.
* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - Daemon that embeds the core control loops shipped with Kubernetes.
* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - Can do simple TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across a set of back-ends.
* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - Can
do simple TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across
a set of back-ends.
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - Scheduler that manages availability, performance, and capacity.
* [kube-scheduler Policies](/docs/reference/scheduling/policies)
* [kube-scheduler Profiles](/docs/reference/scheduling/config#profiles)
* [Scheduler Policies](/docs/reference/scheduling/policies)
* [Scheduler Profiles](/docs/reference/scheduling/config#profiles)
-->
## 组件参考
## 组件
* [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) -
在每个节点上运行的主代理。kubelet 接收一组 PodSpecs 并确保其所描述的容器健康地运行。
* [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) -
REST API,用于验证和配置 API 对象(如 Pod、服务或副本控制器等)的数据。
* [kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) -
一个守护进程,其中包含 Kubernetes 所附带的核心控制回路。
* [kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/) -
可进行简单的 TCP/UDP 流转发或针对一组后端执行轮流 TCP/UDP 转发。
* [kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) -
一个调度程序,用于管理可用性、性能和容量。
* [调度策略](/zh/docs/reference/scheduling/policies)
* [调度配置](/zh/docs/reference/scheduling/config#profiles)
<!--
## Config APIs
This section hosts the documentation for "unpublished" APIs which are used to
configure kubernetes components or tools. Most of these APIs are not exposed
by the API server in a RESTful way though they are essential for a user or an
operator to use or manage a cluster.
* [kubelet configuration (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
* [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
* [kube-scheduler policy reference (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/)
* [kube-proxy configuration (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
* [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/)
* [Client authentication API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/)
* [WebhookAdmission configuration (v1)](/docs/reference/config-api/apiserver-webhookadmission.v1/)
-->
## 配置 API
本节包含用于配置 kubernetes 组件或工具的 "未发布" API 的文档。
尽管这些 API 对于用户或操作者使用或管理集群来说是必不可少的,
它们大都没有以 RESTful 的方式在 API 服务器上公开。
* [kubelet 配置 (v1beta1)](/zh/docs/reference/config-api/kubelet-config.v1beta1/)
* [kube-scheduler 配置 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/)
* [kube-scheduler 策略参考 (v1)](/zh/docs/reference/config-api/kube-scheduler-policy-config.v1/)
* [kube-proxy 配置 (v1alpha1)](/zh/docs/reference/config-api/kube-proxy-config.v1alpha1/)
* [`audit.k8s.io/v1` API](/zh/docs/reference/config-api/apiserver-audit.v1/)
* [客户端认证 API (v1beta1)](/zh/docs/reference/config-api/client-authentication.v1beta1/)
* [WebhookAdmission 配置 (v1)](/zh/docs/reference/config-api/apiserver-webhookadmission.v1/)
* [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) - 在每个节点上运行的主 *节点代理* 。kubelet 采用一组 PodSpecs 并确保所描述的容器健康地运行。
* [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) - REST API,用于验证和配置 API 对象(如 Pod、服务或副本控制器等)的数据。
* [kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) - 一个守护进程,它嵌入到了 Kubernetes 的附带的核心控制循环。
* [kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/) - 可进行简单的 TCP/UDP 流转发或针对一组后端执行轮流 TCP/UDP 转发。
* [kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) - 一个调度程序,用于管理可用性、性能和容量。
* [kube-scheduler 策略](/zh/docs/reference/scheduling/policies)
* [kube-scheduler 配置](/zh/docs/reference/scheduling/config#profiles)
<!--
## Design Docs
An archive of the design docs for Kubernetes functionality. Good starting points are [Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and [Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals).
An archive of the design docs for Kubernetes functionality. Good starting points are
[Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and
[Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals).
-->
## 设计文档
@@ -1,5 +1,5 @@
---
title: 管理 Service Accounts
title: 管理服务账号
content_type: concept
weight: 50
---
@@ -20,7 +20,7 @@ weight: 50
This is a Cluster Administrator guide to service accounts. You should be familiar with
[configuring Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/).
Support for authorization and user accounts is planned but incomplete. Sometimes
Support for authorization and user accounts is planned but incomplete. Sometimes
incomplete features are referred to in order to better describe service accounts.
-->
这是一篇针对服务账号的集群管理员指南。你应该熟悉
@@ -102,41 +102,98 @@ It acts synchronously to modify pods as they are created or updated. When this p
或更新时它会进行以下操作:
<!--
1. If the pod does not have a `serviceAccountName` set, it sets the
`serviceAccountName` to `default`.
1. It ensures that the `serviceAccountName` referenced by the pod exists, and
otherwise rejects it.
1. If the pod does not contain any `imagePullSecrets`, then `imagePullSecrets`
of the ServiceAccount referenced by `serviceAccountName` are added to the pod.
1. If the pod does not have a `ServiceAccount` set, it sets the `ServiceAccount` to `default`.
1. It ensures that the `ServiceAccount` referenced by the pod exists, and otherwise rejects it.
1. It adds a `volume` to the pod which contains a token for API access
if neither the ServiceAccount `automountServiceAccountToken` nor the Pod's
`automountServiceAccountToken` is set to `false`.
1. It adds a `volumeSource` to each container of the pod mounted at
`/var/run/secrets/kubernetes.io/serviceaccount`, if the previous step has
created a volume for ServiceAccount token.
1. If the pod does not contain any `ImagePullSecrets`, then `ImagePullSecrets` of the `ServiceAccount` are added to the pod.
-->
1. 如果该 Pod 没有设置 `serviceAccountName`,将其 `serviceAccountName` 设为
`default`
1. 保证 Pod 所引用的 `serviceAccountName` 确实存在,否则拒绝该 Pod。
1. 如果 Pod 不包含 `imagePullSecrets` 设置,将 `serviceAccountName` 所引用
的服务账号中的 `imagePullSecrets` 信息添加到 Pod 中。
1. 如果该 Pod 没有设置 `ServiceAccount`,将其 `ServiceAccount` 设为 `default`
1. 保证 Pod 所引用的 `ServiceAccount` 确实存在,否则拒绝该 Pod
1. 如果服务账号的 `automountServiceAccountToken` 或 Pod 的
`automountServiceAccountToken` 都为设置为 `false`,则为 Pod 创建一个
`volume`,在其中包含用来访问 API 的令牌。
1. 如果前一步中为服务账号令牌创建了卷,则为 Pod 中的每个容器添加一个
`volumeSource`,挂载在其 `/var/run/secrets/kubernetes.io/serviceaccount`
目录下。
1. 如果 Pod 不包含 `imagePullSecrets` 设置,将 `ServiceAccount` 所引用
的服务账号中的 `imagePullSecrets` 信息添加到 Pod 中。
<!--
You can migrate a service account volume to a projected volume when
the `BoundServiceAccountTokenVolume` feature gate is enabled.
The service account token will expire after 1 hour or the pod is deleted. See
more details about
[projected volume](/docs/tasks/configure-pod-container/configure-projected-volume-storage/).
#### Bound Service Account Token Volume
-->
`BoundServiceAccountTokenVolume` 特性门控被启用时,你可以将服务账号卷迁移到投射卷。
服务账号令牌会在 1 小时后或者 Pod 被删除之后过期。
更多信息可参阅[投射卷](/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage/)。
#### 绑定的服务账号令牌卷 {#bound-service-account-token-volume}
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
<!--
When the `BoundServiceAccountTokenVolume` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled, the service account admission controller will
add the following projected volume instead of a Secret-based volume for the non-expiring service account token created by Token Controller.
-->
`BoundServiceAccountTokenVolume`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
被启用时,服务账号准入控制器将添加如下投射卷,而不是为令牌控制器
所生成的不过期的服务账号令牌而创建的基于 Secret 的卷。
```yaml
- name: kube-api-access-<随机后缀>
projected:
defaultMode: 420 # 0644
sources:
- serviceAccountToken:
expirationSeconds: 3600
path: token
- configMap:
items:
- key: ca.crt
path: ca.crt
name: kube-root-ca.crt
- downwardAPI:
items:
- fieldRef:
apiVersion: v1
fieldPath: metadata.namespace
path: namespace
```
<!--
This projected volume consists of three sources:
1. A ServiceAccountToken acquired from kube-apiserver via TokenRequest API. It will expire after 1 hour by default or when the pod is deleted. It is bound to the pod and has kube-apiserver as the audience.
1. A ConfigMap containing a CA bundle used for verifying connections to the kube-apiserver. This feature depends on the `RootCAConfigMap` feature gate being enabled, which publishes a "kube-root-ca.crt" ConfigMap to every namespace. `RootCAConfigMap` is enabled by default in 1.20, and always enabled in 1.21+.
1. A DownwardAPI that references the namespace of the pod.
-->
此投射卷有三个数据源:
1. 通过 TokenRequest API 从 kube-apiserver 处获得的 ServiceAccountToken。
这一令牌默认会在一个小时之后或者 Pod 被删除时过期。
该令牌绑定到 Pod 实例上,并将 kube-apiserver 作为其受众(audience)。
1. 包含用来验证与 kube-apiserver 连接的 CA 证书包的 ConfigMap 对象。
这一特性依赖于 `RootCAConfigMap` 特性门控被启用。该特性被启用时,
控制面会公开一个名为 `kube-root-ca.crt` 的 ConfigMap 给所有名字空间。
`RootCAConfigMap` 在 1.20 版本中是默认被启用的,在 1.21 及之后版本中
总是被启用。
1. 引用 Pod 名字空间的一个 DownwardAPI。
<!--
See more details about [projected volumes](/docs/tasks/configure-pod-container/configure-projected-volume-storage/).
You can manually migrate a secret-based service account volume to a projected volume when
the `BoundServiceAccountTokenVolume` feature gate is not enabled by adding the above
projected volume to the pod spec. However, `RootCAConfigMap` needs to be enabled.
-->
参阅[投射卷](/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage/)
了解进一步的细节。
如果 `BoundServiceAccountTokenVolume` 特性门控未被启用,
你可以手动地将一个基于 Secret 的服务账号卷升级为一个投射卷,
方法是将上述投射卷添加到 Pod 规约中。
不过,这时仍需要启用 `RootCAConfigMap` 特性门控。
<!--
### Token Controller
@@ -2,11 +2,13 @@
title: kube-scheduler
content_type: tool-reference
weight: 30
auto_generated: true
---
<!--
title: kube-scheduler
content_type: tool-reference
weight: 28
weight: 30
auto_generated: true
-->
## {{% heading "synopsis" %}}
@@ -18,14 +20,14 @@ each Pod in the scheduling queue according to constraints and available
resources. The scheduler then ranks each valid Node and binds the Pod to a
suitable Node. Multiple different schedulers may be used within a cluster;
kube-scheduler is the reference implementation.
See [scheduling](https://kubernetes.io/docs/concepts/scheduling-eviction/)
See [scheduling](/docs/concepts/scheduling-eviction/)
for more information about scheduling and the kube-scheduler component.
-->
Kubernetes 调度器是一个控制面进程,负责将 Pods 指派到节点上。
调度器基于约束和可用资源为调度队列中每个 Pod 确定其可合法放置的节点。
调度器之后对所有合法的节点进行排序,将 Pod 绑定到一个合适的节点。
在同一个集群中可以使用多个不同的调度器;kube-scheduler 是其参考实现。
参阅[调度](https://kubernetes.io/zh/docs/concepts/scheduling-eviction/)
参阅[调度](/zh/docs/concepts/scheduling-eviction/)
以获得关于调度和 kube-scheduler 组件的更多信息。
```
@@ -58,10 +60,11 @@ If true, adds the file directory to the header of the log messages
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
DEPRECATED: the IP address on which to listen for the --port port (set to 0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces). See --bind-address instead.
DEPRECATED: the IP address on which to listen for the --port port (set to 0.0.0.0 or :: for listening in all interfaces and IP families). See --bind-address instead. This parameter is ignored if a config file is specified in --config.
-->
已弃用: 要监听 --port 端口的 IP 地址(对于所有 IPv4 接口设置为 0.0.0.0,对于所有 IPv6 接口设置为 ::)。
已弃用 要监听 --port 端口的 IP 地址(将其设置为 0.0.0.0 或者 :: 用于监听所有接口和 IP族)。
请参阅 --bind-address。
如果在 --config 中指定了一个配置文件,这个参数将被忽略。
</td>
</tr>
@@ -73,19 +76,36 @@ DEPRECATED: the IP address on which to listen for the --port port (set to 0.0.0.
<!--
DEPRECATED: the scheduling algorithm provider to use, this sets the default plugins for component config profiles. Choose one of: ClusterAutoscalerProvider | DefaultProvider
-->
已弃用: 要使用的调度算法驱动,此标志设置组件配置框架的默认插件。
已弃用 要使用的调度算法驱动,此标志设置组件配置框架的默认插件。
可选值:ClusterAutoscalerProvider | DefaultProvider
</td>
</tr>
<tr>
<td colspan="2">--allow-metric-labels stringToString&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<!--Default-->默认值: []</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
The map from metric-label to value allow-list of this label. The key's format is &lt;MetricName&gt;,&lt;LabelName&gt;. The value's format is &lt;allowed_value&gt;,&lt;allowed_value&gt;...e.g. metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'.
-->
这个键值映射表设置 度量标签 所允许设置的值。
其中键的格式是 &lt;MetricName&gt;,&lt;LabelName&gt;。
值的格式是 &lt;allowed_value&gt;,&lt;allowed_value&gt;。
例如:metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'。
</td>
</tr>
<tr>
<td colspan="2">--alsologtostderr</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
日志记录到标准错误以及文件
log to standard error as well as files
-->
日志记录到标准错误以及文件
</td>
</tr>
@@ -141,7 +161,7 @@ If true, failures to look up missing authentication configuration from the clust
</tr>
<tr>
<td colspan="2">--authorization-always-allow-paths stringSlice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default:-->默认值:[/healthz]</td>
<td colspan="2">--authorization-always-allow-paths strings&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default:-->默认值:"/healthz,/readyz,/livez"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
@@ -203,16 +223,17 @@ Path to the file containing Azure container registry configuration information.
</tr>
<tr>
<td colspan="2">--bind-address ip&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default:-->默认值:0.0.0.0</td>
<td colspan="2">--bind-address string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default:-->默认值:0.0.0.0</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank, all interfaces will be used (0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces).
The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank or an unspecified address (0.0.0.0 or ::), all interfaces will be used.
-->
监听 --secure-port 端口的 IP 地址。
集群的其余部分以及 CLI/ Web 客户端必须可以访问关联的接口。
如果为空,将使用所有接口(0.0.0.0 表示使用所有 IPv4 接口,"::" 表示使用所有 IPv6 接口)。
如果为空或未指定地址 (0.0.0.0 或 ::),所有接口将被使用。
</td>
</tr>
@@ -248,27 +269,43 @@ If set, any request presenting a client certificate signed by one of the authori
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
The path to the configuration file. The following flags can overwrite fields in this file:<br/> --address<br/> --port<br/> --use-legacy-policy-config<br/> --policy-configmap<br/> --policy-config-file<br/> --algorithm-provider
The path to the configuration file. The following flags can overwrite fields in this file:<br/>
--algorithm-provider<br/>
--policy-config-file<br/>
--policy-configmap<br/>
--policy-configmap-namespace
-->
配置文件的路径。以下标志会覆盖此文件中的值:<br/>
--address<br/>
--port<br/>
--use-legacy-policy-config<br/>
--policy-configmap<br/>
--algorithm-provider<br/>
--policy-config-file<br/>
--algorithm-provider
--policy-configmap<br/>
--policy-configmap-namespace
</td>
</tr>
<tr>
<td colspan="2">--contention-profiling</td>
<td colspan="2">--contention-profiling&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default-->默认值: true</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
DEPRECATED: enable lock contention profiling, if profiling is enabled
DEPRECATED: enable lock contention profiling, if profiling is enabled. This parameter is ignored if a config file is specified in --config.
-->
已弃用: 如果启用了性能分析,则启用锁竞争分析
已弃用: 如果启用了性能分析,则启用锁竞争分析
如果 --config 指定了一个配置文件,那么这个参数将被忽略。
</td>
</tr>
<tr>
<td colspan="2">--disabled-metrics strings</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
This flag provides an escape hatch for misbehaving metrics. You must provide the fully qualified metric name in order to disable it. Disclaimer: disabling metrics is higher in precedence than showing hidden metrics.
-->
这个标志提供了一个规避不良指标的选项。你必须提供完整的指标名称才能禁用它。
免责声明:禁用指标的优先级比显示隐藏的指标更高。
</td>
</tr>
@@ -287,7 +324,7 @@ DEPRECATED: enable lock contention profiling, if profiling is enabled
</tr>
<tr>
<td colspan="2">--feature-gates mapStringBool</td>
<td colspan="2">--feature-gates &lt;<!--comma-separated 'key=True|False' pairs-->逗号分隔的 'key=True|False' 对&gt;</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
@@ -299,41 +336,35 @@ APIResponseCompression=true|false (BETA - default=true)<br/>
APIServerIdentity=true|false (ALPHA - default=false)<br/>
AllAlpha=true|false (ALPHA - default=false)<br/>
AllBeta=true|false (BETA - default=false)<br/>
AllowInsecureBackendProxy=true|false (BETA - default=true)<br/>
AnyVolumeDataSource=true|false (ALPHA - default=false)<br/>
AppArmor=true|false (BETA - default=true)<br/>
BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>
BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>
BoundServiceAccountTokenVolume=true|false (BETA - default=true)<br/>
CPUManager=true|false (BETA - default=true)<br/>
CRIContainerLogRotation=true|false (BETA - default=true)<br/>
CSIInlineVolume=true|false (BETA - default=true)<br/>
CSIMigration=true|false (BETA - default=true)<br/>
CSIMigrationAWS=true|false (BETA - default=false)<br/>
CSIMigrationAWSComplete=true|false (ALPHA - default=false)<br/>
CSIMigrationAzureDisk=true|false (BETA - default=false)<br/>
CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)<br/>
CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>
CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)<br/>
CSIMigrationAzureFile=true|false (BETA - default=false)<br/>
CSIMigrationGCE=true|false (BETA - default=false)<br/>
CSIMigrationGCEComplete=true|false (ALPHA - default=false)<br/>
CSIMigrationOpenStack=true|false (BETA - default=false)<br/>
CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)<br/>
CSIMigrationOpenStack=true|false (BETA - default=true)<br/>
CSIMigrationvSphere=true|false (BETA - default=false)<br/>
CSIMigrationvSphereComplete=true|false (BETA - default=false)<br/>
CSIServiceAccountToken=true|false (ALPHA - default=false)<br/>
CSIStorageCapacity=true|false (ALPHA - default=false)<br/>
CSIServiceAccountToken=true|false (BETA - default=true)<br/>
CSIStorageCapacity=true|false (BETA - default=true)<br/>
CSIVolumeFSGroupPolicy=true|false (BETA - default=true)<br/>
CSIVolumeHealth=true|false (ALPHA - default=false)<br/>
ConfigurableFSGroupPolicy=true|false (BETA - default=true)<br/>
CronJobControllerV2=true|false (ALPHA - default=false)<br/>
ControllerManagerLeaderMigration=true|false (ALPHA - default=false)<br/>
CronJobControllerV2=true|false (BETA - default=true)<br/>
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>
DaemonSetUpdateSurge=true|false (ALPHA - default=false)<br/>
DefaultPodTopologySpread=true|false (BETA - default=true)<br/>
DevicePlugins=true|false (BETA - default=true)<br/>
DisableAcceleratorUsageMetrics=true|false (BETA - default=true)<br/>
DownwardAPIHugePages=true|false (ALPHA - default=false)<br/>
DownwardAPIHugePages=true|false (BETA - default=false)<br/>
DynamicKubeletConfig=true|false (BETA - default=true)<br/>
EfficientWatchResumption=true|false (ALPHA - default=false)<br/>
EndpointSlice=true|false (BETA - default=true)<br/>
EndpointSliceNodeName=true|false (ALPHA - default=false)<br/>
EfficientWatchResumption=true|false (BETA - default=true)<br/>
EndpointSliceProxying=true|false (BETA - default=true)<br/>
EndpointSliceTerminatingCondition=true|false (ALPHA - default=false)<br/>
EphemeralContainers=true|false (ALPHA - default=false)<br/>
@@ -341,90 +372,98 @@ ExpandCSIVolumes=true|false (BETA - default=true)<br/>
ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>
ExpandPersistentVolumes=true|false (BETA - default=true)<br/>
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>
GenericEphemeralVolume=true|false (ALPHA - default=false)<br/>
GracefulNodeShutdown=true|false (ALPHA - default=false)<br/>
GenericEphemeralVolume=true|false (BETA - default=true)<br/>
GracefulNodeShutdown=true|false (BETA - default=true)<br/>
HPAContainerMetrics=true|false (ALPHA - default=false)<br/>
HPAScaleToZero=true|false (ALPHA - default=false)<br/>
HugePageStorageMediumSize=true|false (BETA - default=true)<br/>
IPv6DualStack=true|false (ALPHA - default=false)<br/>
ImmutableEphemeralVolumes=true|false (BETA - default=true)<br/>
IPv6DualStack=true|false (BETA - default=true)<br/>
InTreePluginAWSUnregister=true|false (ALPHA - default=false)<br/>
InTreePluginAzureDiskUnregister=true|false (ALPHA - default=false)<br/>
InTreePluginAzureFileUnregister=true|false (ALPHA - default=false)<br/>
InTreePluginGCEUnregister=true|false (ALPHA - default=false)<br/>
InTreePluginOpenStackUnregister=true|false (ALPHA - default=false)<br/>
InTreePluginvSphereUnregister=true|false (ALPHA - default=false)<br/>
IndexedJob=true|false (ALPHA - default=false)<br/>
IngressClassNamespacedParams=true|false (ALPHA - default=false)<br/>
KubeletCredentialProviders=true|false (ALPHA - default=false)<br/>
KubeletPodResources=true|false (BETA - default=true)<br/>
LegacyNodeRoleBehavior=true|false (BETA - default=true)<br/>
KubeletPodResourcesGetAllocatable=true|false (ALPHA - default=false)<br/>
LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>
LogarithmicScaleDown=true|false (ALPHA - default=false)<br/>
MemoryManager=true|false (ALPHA - default=false)<br/>
MixedProtocolLBService=true|false (ALPHA - default=false)<br/>
NodeDisruptionExclusion=true|false (BETA - default=true)<br/>
NamespaceDefaultLabelName=true|false (BETA - default=true)<br/>
NetworkPolicyEndPort=true|false (ALPHA - default=false)<br/>
NonPreemptingPriority=true|false (BETA - default=true)<br/>
PodDisruptionBudget=true|false (BETA - default=true)<br/>
PodAffinityNamespaceSelector=true|false (ALPHA - default=false)<br/>
PodDeletionCost=true|false (ALPHA - default=false)<br/>
PodOverhead=true|false (BETA - default=true)<br/>
PreferNominatedNode=true|false (ALPHA - default=false)<br/>
ProbeTerminationGracePeriod=true|false (ALPHA - default=false)<br/>
ProcMountType=true|false (ALPHA - default=false)<br/>
QOSReserved=true|false (ALPHA - default=false)<br/>
RemainingItemCount=true|false (BETA - default=true)<br/>
RemoveSelfLink=true|false (BETA - default=true)<br/>
RootCAConfigMap=true|false (BETA - default=true)<br/>
RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>
RunAsGroup=true|false (BETA - default=true)<br/>
ServerSideApply=true|false (BETA - default=true)<br/>
ServiceAccountIssuerDiscovery=true|false (BETA - default=true)<br/>
ServiceInternalTrafficPolicy=true|false (ALPHA - default=false)<br/>
ServiceLBNodePortControl=true|false (ALPHA - default=false)<br/>
ServiceNodeExclusion=true|false (BETA - default=true)<br/>
ServiceLoadBalancerClass=true|false (ALPHA - default=false)<br/>
ServiceTopology=true|false (ALPHA - default=false)<br/>
SetHostnameAsFQDN=true|false (BETA - default=true)<br/>
SizeMemoryBackedVolumes=true|false (ALPHA - default=false)<br/>
StorageVersionAPI=true|false (ALPHA - default=false)<br/>
StorageVersionHash=true|false (BETA - default=true)<br/>
Sysctls=true|false (BETA - default=true)<br/>
TTLAfterFinished=true|false (ALPHA - default=false)<br/>
SuspendJob=true|false (ALPHA - default=false)<br/>
TTLAfterFinished=true|false (BETA - default=true)<br/>
TopologyAwareHints=true|false (ALPHA - default=false)<br/>
TopologyManager=true|false (BETA - default=true)<br/>
ValidateProxyRedirects=true|false (BETA - default=true)<br/>
VolumeCapacityPriority=true|false (ALPHA - default=false)<br/>
WarningHeaders=true|false (BETA - default=true)<br/>
WinDSR=true|false (ALPHA - default=false)<br/>
WinOverlay=true|false (BETA - default=true)<br/>
WindowsEndpointSliceProxying=true|false (ALPHA - default=false)
WindowsEndpointSliceProxying=true|false (BETA - default=true)
-->
一组 key=value 对,描述了 alpha/experimental 特征开关。选项包括:<br/>
A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>
APIListChunking=true|false (BETA - 默认值=true)<br/>
APIPriorityAndFairness=true|false (BETA - 默认值=true)<br/>
APIResponseCompression=true|false (BETA - 默认值=true)<br/>
APIServerIdentity=true|false (ALPHA - 默认值=false)<br/>
AllAlpha=true|false (ALPHA - 默认值=false)<br/>
AllBeta=true|false (BETA - 默认值=false)<br/>
AllowInsecureBackendProxy=true|false (BETA - 默认值=true)<br/>
AnyVolumeDataSource=true|false (ALPHA - 默认值=false)<br/>
AppArmor=true|false (BETA - 默认值=true)<br/>
BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false)<br/>
BoundServiceAccountTokenVolume=true|false (ALPHA - 默认值=false)<br/>
BoundServiceAccountTokenVolume=true|false (BETA - 默认值=true)<br/>
CPUManager=true|false (BETA - 默认值=true)<br/>
CRIContainerLogRotation=true|false (BETA - 默认值=true)<br/>
CSIInlineVolume=true|false (BETA - 默认值=true)<br/>
CSIMigration=true|false (BETA - 默认值=true)<br/>
CSIMigrationAWS=true|false (BETA - 默认值=true)<br/>
CSIMigrationAWSComplete=true|false (ALPHA - 默认值=false)<br/>
CSIMigrationAzureDisk=true|false (BETA - 默认值=true)<br/>
CSIMigrationAzureDiskComplete=true|false (ALPHA - 默认值=false)<br/>
CSIMigrationAzureFile=true|false (ALPHA - 默认值=false)<br/>
CSIMigrationAzureFileComplete=true|false (ALPHA - 默认值=false)<br/>
CSIMigrationGCE=true|false (BETA - 默认值=true)<br/>
CSIMigrationGCEComplete=true|false (ALPHA - 默认值=false)<br/>
CSIMigrationAWS=true|false (BETA - 默认值=false)<br/>
CSIMigrationAzureDisk=true|false (BETA - 默认值=false)<br/>
CSIMigrationAzureFile=true|false (BETA - 默认值=false)<br/>
CSIMigrationGCE=true|false (BETA - 默认值=false)<br/>
CSIMigrationOpenStack=true|false (BETA - 默认值=true)<br/>
CSIMigrationOpenStackComplete=true|false (ALPHA - 默认值=false)<br/>
CSIMigrationvSphere=true|false (BETA - 默认值=false)<br/>
CSIMigrationvSphereComplete=true|false (BETA - default=false)<br/>
CSIServiceAccountToken=true|false (ALPHA - 默认值=false)<br/>
CSIStorageCapacity=true|false (ALPHA - 默认值=false)<br/>
CSIMigrationvSphereComplete=true|false (BETA - 默认值=false)<br/>
CSIServiceAccountToken=true|false (BETA - 默认值=true)<br/>
CSIStorageCapacity=true|false (BETA - 默认值=true)<br/>
CSIVolumeFSGroupPolicy=true|false (BETA - 默认值=true)<br/>
CSIVolumeHealth=true|false (ALPHA - 默认值=false)<br/>
ConfigurableFSGroupPolicy=true|false (BETA - 默认值=true)<br/>
CronJobControllerV2=true|false (ALPHA - 默认值=false)<br/>
ControllerManagerLeaderMigration=true|false (ALPHA - 默认值=false)<br/>
CronJobControllerV2=true|false (BETA - 默认值=true)<br/>
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)<br/>
DaemonSetUpdateSurge=true|false (ALPHA - 默认值=false)<br/>
DefaultPodTopologySpread=true|false (BETA - 默认值=true)<br/>
DevicePlugins=true|false (BETA - 默认值=true)<br/>
DisableAcceleratorUsageMetrics=true|false (BETA - 默认值=true)<br/>
DownwardAPIHugePages=true|false (ALPHA - 默认值=false)<br/>
DownwardAPIHugePages=true|false (BETA - 默认值=false)<br/>
DynamicKubeletConfig=true|false (BETA - 默认值=true)<br/>
EfficientWatchResumption=true|false (ALPHA - 默认值=false)<br/>
EndpointSlice=true|false (ALPHA - 默认值=false)<br/>
EndpointSliceNodeName=true|false (ALPHA - 默认值=false)<br/>
EfficientWatchResumption=true|false (BETA - 默认值=true)<br/>
EndpointSliceProxying=true|false (BETA - 默认值=true)<br/>
EndpointSliceTerminatingCondition=true|false (ALPHA - 默认值=false)<br/>
EphemeralContainers=true|false (ALPHA - 默认值=false)<br/>
@@ -432,47 +471,60 @@ ExpandCSIVolumes=true|false (BETA - 默认值=true)<br/>
ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)<br/>
ExpandPersistentVolumes=true|false (BETA - 默认值=true)<br/>
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false)<br/>
GenericEphemeralVolume=true|false (ALPHA - 默认值=false)<br/>
GracefulNodeShutdown=true|false (ALPHA - 默认值=false)<br/>
GenericEphemeralVolume=true|false (BETA - 默认值=true)<br/>
GracefulNodeShutdown=true|false (BETA - 默认值=true)<br/>
HPAContainerMetrics=true|false (ALPHA - 默认值=false)<br/>
HPAScaleToZero=true|false (ALPHA - 默认值=false)<br/>
HugePageStorageMediumSize=true|false (BETA - 默认值=true)<br/>
IPv6DualStack=true|false (ALPHA - 默认值=false)<br/>
ImmutableEphemeralVolumes=true|false (BETA - 默认值=true)<br/>
IPv6DualStack=true|false (BETA - 默认值=true)<br/>
InTreePluginAWSUnregister=true|false (ALPHA - 默认值=false)<br/>
InTreePluginAzureDiskUnregister=true|false (ALPHA - 默认值=false)<br/>
InTreePluginAzureFileUnregister=true|false (ALPHA - 默认值=false)<br/>
InTreePluginGCEUnregister=true|false (ALPHA - 默认值=false)<br/>
InTreePluginOpenStackUnregister=true|false (ALPHA - 默认值=false)<br/>
InTreePluginvSphereUnregister=true|false (ALPHA - 默认值=false)<br/>
IndexedJob=true|false (ALPHA - 默认值=false)<br/>
IngressClassNamespacedParams=true|false (ALPHA - 默认值=false)<br/>
KubeletCredentialProviders=true|false (ALPHA - 默认值=false)<br/>
KubeletPodResources=true|false (BETA - 默认值=true)<br/>
LegacyNodeRoleBehavior=true|false (BETA - 默认值=true)<br/>
KubeletPodResourcesGetAllocatable=true|false (ALPHA - 默认值=false)<br/>
LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)<br/>
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)<br/>
LogarithmicScaleDown=true|false (ALPHA - 默认值=false)<br/>
MemoryManager=true|false (ALPHA - 默认值=false)<br/>
MixedProtocolLBService=true|false (ALPHA - 默认值=false)<br/>
NodeDisruptionExclusion=true|false (BETA - 默认值=false)<br/>
NamespaceDefaultLabelName=true|false (BETA - 默认值=true)<br/>
NetworkPolicyEndPort=true|false (ALPHA - 默认值=false)<br/>
NonPreemptingPriority=true|false (BETA - 默认值=true)<br/>
PodDisruptionBudget=true|false (BETA - 默认值=true)<br/>
PodAffinityNamespaceSelector=true|false (ALPHA - 默认值=false)<br/>
PodDeletionCost=true|false (ALPHA - 默认值=false)<br/>
PodOverhead=true|false (BETA - 默认值=true)<br/>
PreferNominatedNode=true|false (ALPHA - 默认值=false)<br/>
ProbeTerminationGracePeriod=true|false (ALPHA - 默认值=false)<br/>
ProcMountType=true|false (ALPHA - 默认值=false)<br/>
QOSReserved=true|false (ALPHA - 默认值=false)<br/>
RemainingItemCount=true|false (BETA - 默认值=true)<br/>
RemoveSelfLink=true|false (BETA - 默认值=true)<br/>
RootCAConfigMap=true|false (BETA - 默认值=true)<br/>
RotateKubeletServerCertificate=true|false (BETA - 默认值=true)<br/>
RunAsGroup=true|false (BETA - 默认值=true)<br/>
ServerSideApply=true|false (BETA - 默认值=true)<br/>
ServiceAccountIssuerDiscovery=true|false (BETA - 默认值=true)<br/>
ServiceInternalTrafficPolicy=true|false (ALPHA - 默认值=false)<br/>
ServiceLBNodePortControl=true|false (ALPHA - 默认值=false)<br/>
ServiceNodeExclusion=true|false (BETA - 默认值=true)<br/>
ServiceLoadBalancerClass=true|false (ALPHA - 默认值=false)<br/>
ServiceTopology=true|false (ALPHA - 默认值=false)<br/>
SetHostnameAsFQDN=true|false (BETA - 默认值=true)<br/>
SizeMemoryBackedVolumes=true|false (ALPHA - 默认值=false)<br/>
StorageVersionAPI=true|false (ALPHA - 默认值=false)<br/>
StorageVersionHash=true|false (BETA - 默认值=true)<br/>
Sysctls=true|false (BETA - 默认值=true)<br/>
TTLAfterFinished=true|false (ALPHA - 默认值=false)<br/>
SuspendJob=true|false (ALPHA - 默认值=false)<br/>
TTLAfterFinished=true|false (BETA - 默认值=true)<br/>
TopologyAwareHints=true|false (ALPHA - 默认值=false)<br/>
TopologyManager=true|false (BETA - 默认值=true)<br/>
ValidateProxyRedirects=true|false (BETA - 默认值=true)<br/>
VolumeCapacityPriority=true|false (ALPHA - 默认值=false)<br/>
WarningHeaders=true|false (BETA - 默认值=true)<br/>
WinDSR=true|false (ALPHA - 默认值=false)<br/>
WinOverlay=true|false (BETA - 默认值=true)<br/>
WindowsEndpointSliceProxying=true|false (ALPHA - 默认值=false)
WindowsEndpointSliceProxying=true|false (BETA - 默认值=true)
</td>
</tr>
@@ -482,12 +534,13 @@ WindowsEndpointSliceProxying=true|false (ALPHA - 默认值=false)
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
DEPRECATED: RequiredDuringScheduling affinity is not symmetric, but there is an implicit PreferredDuringScheduling affinity rule corresponding to every RequiredDuringScheduling affinity rule. --hard-pod-affinity-symmetric-weight represents the weight of implicit PreferredDuringScheduling affinity rule. Must be in the range 0-100.This option was moved to the policy configuration file
DEPRECATED: RequiredDuringScheduling affinity is not symmetric, but there is an implicit PreferredDuringScheduling affinity rule corresponding to every RequiredDuringScheduling affinity rule. --hard-pod-affinity-symmetric-weight represents the weight of implicit PreferredDuringScheduling affinity rule. Must be in the range 0-100.This parameter is ignored if a config file is specified in --config.
-->
已弃用: RequiredDuringScheduling 亲和性是不对称的,但是存在与每个
RequiredDuringScheduling 关联性规则相对应的隐式 PreferredDuringScheduling 关联性规则。
<code>--hard-pod-affinity-symmetric-weight</code> 代表隐式 PreferredDuringScheduling
关联性规则的权重。权重必须在 0-100 范围内。此选项已移至策略配置文件。
关联性规则的权重。权重必须在 0-100 范围内。
如果 --config 指定了一个配置文件,那么这个参数将被忽略。
</td>
</tr>
@@ -521,9 +574,10 @@ The limit that the server gives to clients for the maximum number of streams in
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
DEPRECATED: burst to use while talking with kubernetes apiserver
DEPRECATED: burst to use while talking with kubernetes apiserver. This parameter is ignored if a config file is specified in --config.
-->
已弃用: 与 kubernetes API 通信时使用的突发请求个数限值。
如果 --config 指定了一个配置文件,那么这个参数将被忽略。
</td>
</tr>
@@ -533,9 +587,10 @@ DEPRECATED: burst to use while talking with kubernetes apiserver
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
DEPRECATED: content type of requests sent to apiserver.
DEPRECATED: content type of requests sent to apiserver. This parameter is ignored if a config file is specified in --config.
-->
已弃用: 发送到 API 服务器的请求的内容类型。
如果 --config 指定了一个配置文件,那么这个参数将被忽略。
</td>
</tr>
@@ -545,9 +600,10 @@ DEPRECATED: content type of requests sent to apiserver.
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
DEPRECATED: QPS to use while talking with kubernetes apiserver
DEPRECATED: QPS to use while talking with kubernetes apiserver. This parameter is ignored if a config file is specified in --config.
-->
已弃用: 与 kubernetes apiserver 通信时要使用的 QPS
如果 --config 指定了一个配置文件,那么这个参数将被忽略。
</td>
</tr>
@@ -557,9 +613,10 @@ DEPRECATED: QPS to use while talking with kubernetes apiserver
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
DEPRECATED: path to kubeconfig file with authorization and master location information.
DEPRECATED: path to kubeconfig file with authorization and master location information. This parameter is ignored if a config file is specified in --config.
-->
已弃用: 包含鉴权和主节点位置信息的 kubeconfig 文件的路径。
如果 --config 指定了一个配置文件,那么这个参数将被忽略。
</td>
</tr>
@@ -604,7 +661,7 @@ The interval between attempts by the acting master to renew a leadership slot be
</tr>
<tr>
<td colspan="2">--leader-elect-resource-lock endpoints&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default:-->默认值:"leases"</td>
<td colspan="2">--leader-elect-resource-lock string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default:-->默认值:"leases"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
@@ -659,9 +716,10 @@ The duration the clients should wait between attempting acquisition and renewal
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
DEPRECATED: define the name of the lock object. Will be removed in favor of leader-elect-resource-name
DEPRECATED: define the name of the lock object. Will be removed in favor of leader-elect-resource-name. This parameter is ignored if a config file is specified in --config.
-->
已弃用: 定义锁对象的名称。将被删除以便使用 <code>--leader-elect-resource-name</code>。
如果 --config 指定了一个配置文件,那么这个参数将被忽略。
</td>
</tr>
@@ -671,14 +729,16 @@ DEPRECATED: define the name of the lock object. Will be removed in favor of lead
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
DEPRECATED: define the namespace of the lock object. Will be removed in favor of leader-elect-resource-namespace.
DEPRECATED: define the namespace of the lock object. Will be removed in favor of leader-elect-resource-namespace. This parameter is ignored if a config file is specified in --config.
-->
已弃用: 定义锁对象的命名空间。将被删除以便使用 <code>leader-elect-resource-namespace</code>。
如果 --config 指定了一个配置文件,那么这个参数将被忽略。
</td>
</tr>
<tr>
<td colspan="2">--log-backtrace-at traceLocation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default:-->默认值::0</td>
<td colspan="2">--log-backtrace-at &lt;a string in the form 'file:N'&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<!--Default:-->默认值: 0</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
@@ -739,19 +799,24 @@ Maximum number of seconds between log flushes
</tr>
<tr>
<td colspan="2">--logging-format string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default:-->默认值:"text"</td>
<td colspan="2">--logging-format string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default:-->默认值:text</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
Sets the log format. Permitted formats: "json", "text".<br/>Non-default formats don't honor these flags: --add_dir_header, --alsologtostderr, --log_backtrace_at, --log_dir, --log_file, --log_file_max_size, --logtostderr, --one_output, --skip_headers, --skip_log_headers, --stderrthreshold, --vmodule, --log-flush-frequency.<br/>Non-default choices are currently alpha and subject to change without warning.
Sets the log format. Permitted formats: &quot;json&quot;, &quot;text&quot;.<br/>
Non-default formats don't honor these flags: --add-dir-header, --alsologtostderr, --log-backtrace-at,
--log-dir, --log-file, --log-file-max-size,
--logtostderr, --one-output, --skip-headers, --skip-log-headers,
--stderrthreshold, --vmodule, --log-flush-frequency.<br/>
Non-default choices are currently alpha and subject to change without warning.
-->
设置日志格式。可选格式:"json"、"text"。<br/>
非默认格式不会在意以下标志设置
--add_dir_header--alsologtostderr--log_backtrace_at、--log_dir、
--log_file--log_file_max_size、--logtostderr、--one_output、
--skip_headers--skip_log_headers、--stderrthreshold、--vmodule、
--log-flush-frequency.<br/>
设置日志格式。可选格式:json”,“text。<br/>
采用非默认格式时,以下标识不会生效
--add-dir-header, --alsologtostderr, --log-backtrace-at,
--log-dir, --log-file, --log-file-max-size,
--logtostderr, --one-output, --skip-headers, --skip-log-headers,
--stderrthreshold, --vmodule, --log-flush-frequency.<br/>
非默认选项目前处于 Alpha 阶段,有可能会出现变更且无事先警告。
</td>
</tr>
@@ -786,22 +851,38 @@ Kubernetes API 服务器的地址(覆盖 kubeconfig 中的任何值)。
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
If true, only write logs to their native severity level (vs also writing to each lower severity level
If true, only write logs to their native severity level (vs also writing to each lower severity level)
-->
若此标志为 true,则日志仅写入其自身的严重性级别,而不会写入所有较低严重性级别。
</td>
</tr>
<tr>
<td colspan="2">--permit-address-sharing</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
If true, SO_REUSEADDR will be used when binding the port. This allows binding to wildcard IPs like 0.0.0.0 and specific IPs in parallel, and it avoids waiting for the kernel to release sockets in TIME_WAIT state. [default=false]
-->
如果为 true,在绑定端口时将使用 SO_REUSEADDR。
这将允许同时绑定诸如 0.0.0.0 这类通配符 IP和特定 IP,
并且它避免等待内核释放处于 TIME_WAIT 状态的套接字。
默认值: false
</td>
</tr>
<tr>
<td colspan="2">--permit-port-sharing</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
If true, SO_REUSEPORT will be used when binding the port, which allows more than one instance to bind on the same address and port.
If true, SO_REUSEPORT will be used when binding the port, which allows more than one instance to bind on the same address and port. [default=false]
-->
如果此标志为 true,在绑定端口时会使用 SO_REUSEPORT,从而允许不止一个
实例绑定到同一地址和端口。
默认值:false
</td>
</tr>
@@ -853,22 +934,25 @@ DEPRECATED: the namespace where policy ConfigMap is located. The kube-system nam
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
DEPRECATED: the port on which to serve HTTP insecurely without authentication and authorization. If 0, don't serve plain HTTP at all. See --secure-port instead.
DEPRECATED: the port on which to serve HTTP insecurely without authentication and authorization. If 0, don't serve plain HTTP at all. See --secure-port instead. This parameter is ignored if a config file is specified in --config.
-->
已弃用: 在没有身份验证和权的情况下不安全地为 HTTP 服务的端口。
如果为0,则根本不提供 HTTP。请参见--secure-port。
已弃用 在没有身份验证和权的情况下不安全地为 HTTP 服务的端口。
如果为 0,则根本不提供 HTTP。请参见 --secure-port。
如果 --config 指定了一个配置文件,这个参数将被忽略。
</td>
</tr>
<tr>
<td colspan="2">--profiling</td>
<td colspan="2">--profiling&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default:-->默认值: true</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
DEPRECATED: enable profiling via web interface host:port/debug/pprof/
DEPRECATED: enable profiling via web interface host:port/debug/pprof/.
This parameter is ignored if a config file is specified in --config.
-->
已弃用: 通过 Web 界面主机启用配置文件:<code>host:port/debug/pprof/</code>。
如果 --config 指定了一个配置文件,这个参数将被忽略。
</td>
</tr>
@@ -901,7 +985,8 @@ Root certificate bundle to use to verify client certificates on incoming request
</tr>
<tr>
<td colspan="2"> --requestheader-extra-headers-prefix stringSlice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default:-->默认值:[x-remote-extra-]</td>
<td colspan="2">--requestheader-extra-headers-prefix strings&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<!--Default:-->默认值: "x-remote-extra-"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
@@ -913,7 +998,8 @@ List of request header prefixes to inspect. X-Remote-Extra- is suggested.
</tr>
<tr>
<td colspan="2">--requestheader-group-headers stringSlice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default:-->默认值:[x-remote-group]</td>
<td colspan="2">--requestheader-group-headers strings&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<!--Default:-->默认值: "x-remote-group"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
@@ -925,7 +1011,8 @@ List of request headers to inspect for groups. X-Remote-Group is suggested.
</tr>
<tr>
<td colspan="2">--requestheader-username-headers stringSlice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default:-->默认值:[x-remote-user]</td>
<td colspan="2">--requestheader-username-headers strings&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<!--Default:-->默认值: "x-remote-user"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
@@ -937,15 +1024,17 @@ List of request headers to inspect for usernames. X-Remote-User is common.
</tr>
<tr>
<td colspan="2">--scheduler-name string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default:-->默认值:"default-scheduler"</td>
<td colspan="2">--scheduler-name string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default:-->
默认值:"default-scheduler"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
DEPRECATED: name of the scheduler, used to select which pods will be processed by this scheduler, based on pod's "spec.schedulerName".
DEPRECATED: name of the scheduler, used to select which pods will be processed by this scheduler, based on pod's &quot;spec.schedulerName&quot;. This parameter is ignored if a config file is specified in --config.
-->
已弃用: 调度器名称,用于根据 Pod 的 "spec.schedulerName" 选择此
已弃用: 调度器名称,用于根据 Pod 的 spec.schedulerName 选择此
调度器将处理的 Pod。
如果 --config 指定了一个配置文件,那么这个参数将被忽略
</td>
</tr>
@@ -955,7 +1044,7 @@ DEPRECATED: name of the scheduler, used to select which pods will be processed b
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
The port on which to serve HTTPS with authentication and authorization.If 0, don't serve HTTPS at all.
The port on which to serve HTTPS with authentication and authorization. If 0, don't serve HTTPS at all.
-->
通过身份验证和授权为 HTTPS 服务的端口。如果为 0,则根本不提供 HTTPS。
</td>
@@ -1001,7 +1090,7 @@ If true, avoid headers when opening log files
</tr>
<tr>
<td colspan="2">--stderrthreshold severity&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default:-->默认值:2</td>
<td colspan="2">--stderrthreshold int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default:-->默认值:2</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
@@ -1028,15 +1117,16 @@ File containing the default x509 Certificate for HTTPS. (CA cert, if any, concat
</tr>
<tr>
<td colspan="2">--tls-cipher-suites stringSlice</td>
<td colspan="2">--tls-cipher-suites strings</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used.<br/>
Preferred values:
TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384. <br/>
Insecure values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA.
Preferred values:
TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384.<br/>
Insecure values:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA.
-->
服务器的密码套件列表,以逗号分隔。如果省略,将使用默认的 Go 密码套件。
优先考虑的值:
@@ -1071,18 +1161,20 @@ File containing the default x509 private key matching --tls-cert-file.
</tr>
<tr>
<td colspan="2">--tls-sni-cert-key namedCertKey&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!--Default:-->默认值:[]</td>
<td colspan="2">--tls-sni-cert-key string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com".
A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. The domain patterns also allow IP addresses, but IPs should only be used if the apiserver has visibility to the IP address requested by a client. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: &quot;example.crt,example.key&quot; or &quot;foo.crt,foo.key:*.foo.com,foo.com&quot;.
-->
一对 x509 证书和私钥文件路径,可选地后缀为完全限定域名的域模式列表,
并可能带有前缀的通配符段。如果未提供域名模式,则提取证书名称。
非通配符匹配优先于通配符匹配,显式域名模式优先于提取而来的名称
一对 x509 证书和私钥文件路径,也可以包含由全限定域名构成的域模式列表作为后缀
并可能带有前缀的通配符段。域名匹配还允许是 IP 地址,
但是只有当 apiserver 对客户端请求的 IP 地址可见时,才能使用 IP
如果未提供域名匹配模式,则提取证书名称。
非通配符匹配优先于通配符匹配,显式域名匹配优先于提取而来的名称。
若有多个密钥/证书对,可多次使用 <code>--tls-sni-cert-key</code>。
: "example.crt,example.key" 或者 "foo.crt,foo.key:*.foo.com,foo.com"。
: "example.crt,example.key" 或者 "foo.crt,foo.key:*.foo.com,foo.com"。
</td>
</tr>
@@ -1100,7 +1192,7 @@ DEPRECATED: when set to true, scheduler will ignore policy ConfigMap and uses po
</tr>
<tr>
<td colspan="2">-v, --v Level</td>
<td colspan="2">-v, --v int</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
@@ -1124,14 +1216,14 @@ Print version information and quit
</tr>
<tr>
<td colspan="2">--vmodule moduleSpec</td>
<td colspan="2">--vmodule &lt;<!--comma-separated 'pattern=N' settings-->逗号分隔的 ‘模式=N 配置列表&gt;</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
comma-separated list of pattern=N settings for file-filtered logging
-->
以逗号分隔的 pattern=N 设置列表,用于文件过滤的日志记录。
以逗号分隔的 ‘模式=N 设置列表,用于文件过滤的日志记录。
</td>
</tr>
+1 -1
View File
@@ -40,4 +40,4 @@ tags:
A Pod is typically set up to run a single primary container. It can also run optional sidecar containers that add supplementary features like logging. Pods are commonly managed by a {{< glossary_tooltip term_id="deployment" >}}.
-->
通常创建 Pod 是为了运行单个主容器。Pod 还可以运行可选的挂斗(sidecar)容器,以添加诸如日志记录之类的补充特性。通常用 {{< glossary_tooltip term_id="deployment" >}} 来管理 Pod。
通常创建 Pod 是为了运行单个主容器。Pod 还可以运行可选的边车(sidecar)容器,以添加诸如日志记录之类的补充特性。通常用 {{< glossary_tooltip term_id="deployment" >}} 来管理 Pod。
@@ -46,6 +46,26 @@ The Kubelet populates this with `runtime.GOOS` as defined by Go. This can be han
-->
Kubelet 用 Go 定义的 `runtime.GOOS` 生成该标签的键值。在混合使用异构操作系统场景下(例如:混合使用 Linux 和 Windows 节点),此键值可以带来极大便利。
## kubernetes.io/metadata.name
示例:`kubernetes.io/metadata.name=mynamespace`
用于:Namespaces
<!--
When the `NamespaceDefaultLabelName`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled,
the Kubernetes API server sets this label on all namespaces. The label value is set to
the name of the namespace.
This is useful if you want to target a specific namespace with a label
{{< glossary_tooltip text="selector" term_id="selector" >}}.
-->
`NamespaceDefaultLabelName` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
被启用时,Kubernetes API 服务器会在所有命名空间上设置此标签。标签值被设置为命名空间的名称。
如果你想使用标签 {{< glossary_tooltip text="选择器" term_id="selector" >}} 来指向特定的命名空间,这很有用。
## beta.kubernetes.io/arch (deprecated)
<!--
@@ -75,6 +95,19 @@ Kubelet 用主机名生成此标签。需要注意的是主机名可修改,这
此标签也可用做拓扑层次的一个部分。更多信息参见[topology.kubernetes.io/zone](#topologykubernetesiozone)。
## controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost}
示例:`controller.kubernetes.io/pod-deletion-cost=10`
用于:Pod
<!--
This annotation is used to set [Pod Deletion Cost](/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost)
which allows users to influence ReplicaSet downscaling order. The annotation parses into an `int32` type.
-->
该注解用于设置 [Pod 删除开销](/zh/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost)
允许用户影响 ReplicaSet 的缩减顺序。该注解解析为 `int32` 类型。
## beta.kubernetes.io/instance-type (deprecated)
{{< note >}}
@@ -124,6 +157,22 @@ Starting in v1.17, this label is deprecated in favor of [topology.kubernetes.io/
从 v1.17 开始,此标签被弃用,取而代之的是 [topology.kubernetes.io/zone](#topologykubernetesiozone).
{{< /note >}}
## statefulset.kubernetes.io/pod-name {#statefulsetkubernetesiopod-name}
示例:`statefulset.kubernetes.io/pod-name=mystatefulset-7`
<!--
When a StatefulSet controller creates a Pod for the StatefulSet, the control plane
sets this label on that Pod. The value of the label is the name of the Pod being created.
See [Pod Name Label](/docs/concepts/workloads/controllers/statefulset/#pod-name-label) in the
StatefulSet topic for more details.
-->
当 StatefulSet 控制器为 StatefulSet 创建 Pod 时,控制平面会在该 Pod 上设置此标签。
标签的值是正在创建的 Pod 的名称。
更多细节请参见 StatefulSet 文章中的 [Pod 名称标签](/zh/docs/concepts/workloads/controllers/statefulset/#pod-name-label)。
## topology.kubernetes.io/region {#topologykubernetesioregion}
示例
@@ -316,6 +365,17 @@ Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassN
从 v1.18 开始,此注解被弃用,取而代之的是 `spec.ingressClassName`
{{< /note >}}
## storageclass.kubernetes.io/is-default-class
示例:`storageclass.kubernetes.io/is-default-class=true`
用于:StorageClass
<!--
When a single StorageClass resource has this annotation set to `"true"`, new Physical Volume Claim resource without a class specified will be assigned this default class.
-->
当单个的 StorageClass 资源将这个注解设置为 `"true"` 时,新的持久卷申领(PVC
资源若未指定类别,将被设定为此默认类别。
## alpha.kubernetes.io/provided-node-ip
@@ -327,14 +387,50 @@ Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassN
The kubelet can set this annotation on a Node to denote its configured IPv4 address.
When kubelet is started with the "external" cloud provider, it sets this annotation on the Node to denote an IP address set from the command line flag (`--node-ip`). This IP is verified with the cloud provider as valid by the cloud-controller-manager.
**The taints listed below are always used on Nodes**
-->
kubectl 在 Node 上设置此注解,表示它的 IPv4 地址。
当 kubectl 由外部的云供应商启动时,在 Node 上设置此注解,表示由命令行标记(`--node-ip`)设置的 IP 地址。
cloud-controller-manager 向云供应商验证此 IP 是否有效。
## batch.kubernetes.io/job-completion-index
示例:`batch.kubernetes.io/job-completion-index: "3"`
用于:Pod
<!--
The Job controller in the kube-controller-manager sets this annotation for Pods
created with Indexed [completion mode](/docs/concepts/workloads/controllers/job/#completion-mode).
-->
kube-controller-manager 中的 Job 控制器给创建使用索引
[完成模式](/zh/docs/concepts/workloads/controllers/job/#completion-mode)
的 Pod 设置此注解。
## kubectl.kubernetes.io/default-container
示例:`kubectl.kubernetes.io/default-container: "front-end-app"`
<!--
The value of the annotation is the container name that is default for this Pod. For example, `kubectl logs` or `kubectl exec` without `-c` or `--container` flag will use this default container.
-->
注解的值是此 Pod 的默认容器名称。
例如,`kubectl logs``kubectl exec` 没有 `-c``--container` 参数时,将使用这个默认的容器。
## endpoints.kubernetes.io/over-capacity
示例:`endpoints.kubernetes.io/over-capacity:warning`
用于:Endpoints
<!--
In Kubernetes clusters v1.21 (or later), the Endpoints controller adds this annotation to an Endpoints resource if it has more than 1000 endpoints. The annotation indicates that the Endpoints resource is over capacity.
**The taints listed below are always used on Nodes**
-->
在 Kubernetes 集群 v1.21(或更高版本)中,如果 Endpoint 超过 1000 个,Endpoint 控制器
就会向其添加这个注解。该注解表示 Endpoint 资源已超过容量。
**以下列出的污点只能用于 Node**
## node.kubernetes.io/not-ready
+4 -2
View File
@@ -184,11 +184,12 @@
/docs/home/contribute/generated-reference/kubernetes-api/ /docs/contribute/generate-ref-docs/kubernetes-api/ 301
/docs/home/contribute/generated-reference/kubernetes-components/ /docs/contribute/generate-ref-docs/kubernetes-components/ 301
/docs/home/contribute/localization/ /docs/contribute/localization/ 301
/docs/home/contribute/page-templates/ /docs/contribute/style/page-templates/ 301
/docs/home/contribute/participating/ /docs/contribute/participating/ 301
/docs/home/contribute/page-templates/ /docs/contribute/style/page-content-types/ 301
/docs/home/contribute/participating/ /docs/contribute/participate/ 301
/docs/home/contribute/review-issues/ /docs/contribute/intermediate/ 301
/docs/home/contribute/blog-post/ /docs/contribute/start/ 301
/docs/home/contribute/write-new-topic/ /docs/contribute/style/write-new-topic/ 301
/docs/contribute/style/page-templates/ /docs/contribute/style/page-content-types/ 301
/docs/reference/command-line-tools-reference/labels-annotations-taints/ /docs/reference/labels-annotations-taints/ 301
@@ -206,6 +207,7 @@
/docs/reference/glossary/maintainer/ /docs/reference/glossary/approver/ 301
/docs/reference/kubectl/kubectl-cmds/ /docs/reference/generated/kubectl/kubectl-commands/ 301!
/docs/reference/kubectl/kubectl/kubectl_*.md /docs/reference/generated/kubectl/kubectl-commands#:splat 301
/docs/reference/scheduling/profiles/ /docs/reference/scheduling/config/#profiles 301