diff --git a/Makefile b/Makefile index a6f987547b..bcae221430 100644 --- a/Makefile +++ b/Makefile @@ -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 diff --git a/content/en/_index.html b/content/en/_index.html index 13a3c069be..2abc22985c 100644 --- a/content/en/_index.html +++ b/content/en/_index.html @@ -43,12 +43,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise

- Attend KubeCon NA virtually on November 17-20, 2020 + Attend KubeCon North America on October 11-15, 2021



- Attend KubeCon EU virtually on May 4 – 7, 2021 + Revisit KubeCon EU 2021
@@ -58,4 +58,4 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise {{< blocks/kubernetes-features >}} -{{< blocks/case-studies >}} \ No newline at end of file +{{< blocks/case-studies >}} diff --git a/content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md b/content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md index 385e6a814a..cf7cc12c92 100644 --- a/content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md +++ b/content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md @@ -95,7 +95,7 @@ The core workloads API surface is stable, but it’s 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/) diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md index 3e94277d93..71eb8106e5 100644 --- a/content/en/docs/concepts/cluster-administration/flow-control.md +++ b/content/en/docs/concepts/cluster-administration/flow-control.md @@ -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). diff --git a/content/en/docs/concepts/policy/pod-security-policy.md b/content/en/docs/concepts/policy/pod-security-policy.md index f0884c3dea..fac2b1205e 100644 --- a/content/en/docs/concepts/policy/pod-security-policy.md +++ b/content/en/docs/concepts/policy/pod-security-policy.md @@ -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 diff --git a/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md index a7b3639366..e294537c4b 100644 --- a/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -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 diff --git a/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md index 946e858a02..3a733f56c3 100644 --- a/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -10,7 +10,7 @@ weight: 40 -[_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. diff --git a/content/en/docs/concepts/services-networking/topology-aware-hints.md b/content/en/docs/concepts/services-networking/topology-aware-hints.md index c2c15878ff..f471caff6b 100644 --- a/content/en/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/en/docs/concepts/services-networking/topology-aware-hints.md @@ -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 diff --git a/content/en/docs/contribute/analytics.md b/content/en/docs/contribute/analytics.md new file mode 100644 index 0000000000..ccffc79fdd --- /dev/null +++ b/content/en/docs/contribute/analytics.md @@ -0,0 +1,25 @@ +--- +title: Viewing Site Analytics +content_type: concept +weight: 100 +card: + name: contribute + weight: 100 +--- + + + +This page contains information about the kubernetes.io analytics dashboard. + + + + +[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). diff --git a/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md b/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md index 5f4edbcc77..656f8c971b 100644 --- a/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md +++ b/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md @@ -134,7 +134,6 @@ Go to `` 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 diff --git a/content/en/docs/reference/_index.md b/content/en/docs/reference/_index.md index a9d7ee3a9b..376fb69ba4 100644 --- a/content/en/docs/reference/_index.md +++ b/content/en/docs/reference/_index.md @@ -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 diff --git a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md index ea04f462b1..0d4ecff08c 100644 --- a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md @@ -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 diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 079e72292b..fa57fbba9e 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -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 diff --git a/content/en/docs/reference/labels-annotations-taints.md b/content/en/docs/reference/labels-annotations-taints.md index 2d74362913..29f3a63a8c 100644 --- a/content/en/docs/reference/labels-annotations-taints.md +++ b/content/en/docs/reference/labels-annotations-taints.md @@ -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 diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md index e517a13d52..da41e7c4c9 100644 --- a/content/en/docs/reference/using-api/api-concepts.md +++ b/content/en/docs/reference/using-api/api-concepts.md @@ -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`. diff --git a/content/en/docs/reference/using-api/server-side-apply.md b/content/en/docs/reference/using-api/server-side-apply.md index 1502684325..3d88413b50 100644 --- a/content/en/docs/reference/using-api/server-side-apply.md +++ b/content/en/docs/reference/using-api/server-side-apply.md @@ -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: diff --git a/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md index 3a8983eec8..133eae902b 100644 --- a/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -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 diff --git a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md index be7cbf2673..6a11b4f2d3 100644 --- a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md +++ b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md @@ -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 diff --git a/content/en/docs/tasks/administer-cluster/highly-available-master.md b/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md similarity index 57% rename from content/en/docs/tasks/administer-cluster/highly-available-master.md rename to content/en/docs/tasks/administer-cluster/highly-available-control-plane.md index 141b4ee9cd..339f48e41a 100644 --- a/content/en/docs/tasks/administer-cluster/highly-available-master.md +++ b/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md @@ -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/' ] --- {{< 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 ``` -
  1. Add a new replica in place of the old one:
+
  1. Add a new node in place of the old one:
```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/) diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md index aad5f13909..9d8c672dfe 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md @@ -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 >}} diff --git a/content/en/docs/tasks/configure-pod-container/configure-runasusername.md b/content/en/docs/tasks/configure-pod-container/configure-runasusername.md index 12c10a9ddf..9ddcac270f 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-runasusername.md +++ b/content/en/docs/tasks/configure-pod-container/configure-runasusername.md @@ -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. diff --git a/content/en/docs/tasks/configure-pod-container/configure-service-account.md b/content/en/docs/tasks/configure-pod-container/configure-service-account.md index 23a76f3752..505ec7d755 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/en/docs/tasks/configure-pod-container/configure-service-account.md @@ -167,8 +167,8 @@ The output is similar to this: Name: build-robot-secret Namespace: default Labels: -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 diff --git a/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md index 697a4c6e0e..57c5329b7a 100644 --- a/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -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: diff --git a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md index 0e6a02af37..abe6320563 100644 --- a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md @@ -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 - - diff --git a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md b/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md deleted file mode 100644 index 29ace662f6..0000000000 --- a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md +++ /dev/null @@ -1,371 +0,0 @@ ---- -reviewers: -- piosz -- x13n -title: Logging Using Stackdriver -content_type: concept ---- - - - -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 >}} - - - - - - -## 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: - -``` - - type parser - format /^(?\w):(?\w):(?.*)/ - reserve_data true - suppress_parse_error_log true - key_name log - -``` - -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/`. -* 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. - - diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md index 1e21306e5f..05e60449c4 100644 --- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md @@ -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. diff --git a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md index 27f3762988..9b16c25167 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -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: diff --git a/content/en/docs/tasks/tools/install-kubectl-macos.md b/content/en/docs/tasks/tools/install-kubectl-macos.md index b748a38c6f..d952359407 100644 --- a/content/en/docs/tasks/tools/install-kubectl-macos.md +++ b/content/en/docs/tasks/tools/install-kubectl-macos.md @@ -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" diff --git a/content/en/releases/release-managers.md b/content/en/releases/release-managers.md index e8b895def6..1554f3df9a 100644 --- a/content/en/releases/release-managers.md +++ b/content/en/releases/release-managers.md @@ -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)) diff --git a/content/fr/docs/reference/glossary/container-runtime.md b/content/fr/docs/reference/glossary/container-runtime.md index ccd95157b9..1d2c8b105f 100644 --- a/content/fr/docs/reference/glossary/container-runtime.md +++ b/content/fr/docs/reference/glossary/container-runtime.md @@ -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. diff --git a/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 4b8b736336..5902ca926d 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -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. diff --git a/content/ja/docs/concepts/configuration/manage-resources-containers.md b/content/ja/docs/concepts/configuration/manage-resources-containers.md index bb2ccb7c20..0d59ecd319 100644 --- a/content/ja/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ja/docs/concepts/configuration/manage-resources-containers.md @@ -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` diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md index 5f2fd15120..ee63e066d8 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/content/ja/docs/concepts/configuration/overview.md @@ -58,11 +58,11 @@ weight: 10 ## ラベルの使用 -- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの__セマンティック属性__を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](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/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](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)を使います。 diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index 67334995eb..bc4e285c66 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -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`フィールドによって定義されます。 diff --git a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md index c1c0c95b6d..6bc7af0dab 100644 --- a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -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`のようなラベルです。 diff --git a/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md index 9f2b86a425..cbd833ba3d 100644 --- a/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -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を異なるプロファイルを実行するように設定することもできます。 diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index a91da37567..f7273d45f1 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -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アドレス(とポート)の面において、自動的に生成されます。 diff --git a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md index 8235e113ae..ba78ba15fa 100644 --- a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -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証明書ベースの認証には対応していません。 diff --git a/content/ru/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/ru/docs/contribute/generate-ref-docs/kubernetes-api.md index 90011b3dd2..883fc8d16c 100644 --- a/content/ru/docs/contribute/generate-ref-docs/kubernetes-api.md +++ b/content/ru/docs/contribute/generate-ref-docs/kubernetes-api.md @@ -75,16 +75,16 @@ git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes ### Настройка переменных для сборки * `K8S_ROOT` со значением ``. -* `WEB_ROOT` со значением ``. +* `K8S_WEBROOT` со значением ``. * `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//website +export K8S_WEBROOT=$(GOPATH)/src/github.com//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 "/gen-apidocs/generators/build/index.html" ] && echo "index.html built" || echo "no index.html" -[ -e "/gen-apidocs/generators/build/navData.js" ] && echo "navData.js built" || echo "no navData.js" +[ -e "/gen-apidocs/build/index.html" ] && echo "index.html built" || echo "no index.html" +[ -e "/gen-apidocs/build/navData.js" ] && echo "navData.js built" || echo "no navData.js" ``` Перейдите в корень директории `` и посмотрите, какие файлы были изменены: diff --git a/content/ru/docs/reference/glossary/container-runtime.md b/content/ru/docs/reference/glossary/container-runtime.md index cea63dfa94..25916582e5 100644 --- a/content/ru/docs/reference/glossary/container-runtime.md +++ b/content/ru/docs/reference/glossary/container-runtime.md @@ -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: > Среда выполнения контейнера — это программа, предназначенная для выполнения контейнеров. diff --git a/content/zh/docs/concepts/containers/runtime-class.md b/content/zh/docs/concepts/containers/runtime-class.md index c45df4e62b..d1ed733804 100644 --- a/content/zh/docs/concepts/containers/runtime-class.md +++ b/content/zh/docs/concepts/containers/runtime-class.md @@ -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) diff --git a/content/zh/docs/concepts/scheduling-eviction/_index.md b/content/zh/docs/concepts/scheduling-eviction/_index.md index f7388ba108..01265f3a05 100644 --- a/content/zh/docs/concepts/scheduling-eviction/_index.md +++ b/content/zh/docs/concepts/scheduling-eviction/_index.md @@ -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 失效的过程。 --- + + + + + + + +## 调度 + +* [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 干扰 + +* [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/) diff --git a/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md index c237281776..7f93a31186 100644 --- a/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -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 =` +`kubectl label nodes =` 命令将标签添加到你所选择的节点上。 -例如，如果你的节点名称为 '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 >}} 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. 用户也可以使用 `namespaceSelector` 选择匹配的名字空间，`namespaceSelector` @@ -828,4 +838,3 @@ resource allocation decisions. 一旦 Pod 分配给 节点，kubelet 应用将运行该 pod 并且分配节点本地资源。 [拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/) 可以参与到节点级别的资源分配决定中。 - diff --git a/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md b/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md index 40684ff11c..998a2c3327 100644 --- a/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md @@ -1,9 +1,21 @@ --- title: Pod 开销 content_type: concept -weight: 20 +weight: 30 --- + + {{< 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`。 - ## 使用示例 @@ -85,7 +97,7 @@ overhead: cpu: "250m" ``` - 在 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}' ``` - 输出： @@ -146,25 +158,25 @@ The output is: map[cpu:250m memory:120Mi] ``` - 如果定义了 ResourceQuata, 则容器请求的总量以及 `overhead` 字段都将计算在内。 - 当 kube-scheduler 决定在哪一个节点调度运行新的 Pod 时，调度器会兼顾该 Pod 的 `overhead` 以及该 Pod 的容器请求总量。在这个示例中，调度器将资源请求和开销相加，然后寻找具备 2.25 CPU 和 320 MiB 内存可用的节点。 - 一旦 Pod 调度到了某个节点， 该节点上的 kubelet 将为该 Pod 新建一个 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}. 底层容器运行时将在这个 pod 中创建容器。 - 对于 CPU, 如果 Pod 的 QoS 是 Guaranteed 或者 Burstable, kubelet 会基于容器请求总量与 PodSpec 中定义的 `overhead` 之和设置 `cpu.shares`. - 请看这个例子，验证工作负载的容器请求： @@ -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}' ``` - 容器请求总计 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] ``` - 对照从节点观察到的情况来检查一下： @@ -203,7 +215,7 @@ Check this against what is observed by the node: kubectl describe node | grep test-pod -B2 ``` - 该输出显示请求了 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)" ``` - 可以依此判断该 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 ``` - 执行结果的 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" ``` - 在这个例子中，该 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 ``` - 和预期的一样是 320 MiB @@ -286,7 +299,7 @@ This is 320 MiB, as expected: 335544320 ``` - ### 可观察性 @@ -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) - diff --git a/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md index a08539b1a0..b8c097e5df 100644 --- a/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -1,16 +1,18 @@ --- title: 扩展资源的资源装箱 content_type: concept -weight: 30 +weight: 80 --- @@ -18,7 +20,7 @@ weight: 30 {{< feature-state for_k8s_version="1.16" state="alpha" >}} 使用 `RequestedToCapacityRatioResourceAllocation` 优先级函数，可以将 kube-scheduler @@ -48,7 +50,7 @@ Kubernetes 1.16 在优先级函数中添加了一个新参数，该参数允许 （least requested）或 最多请求（most requested）计算。 `resources` 包含由 `name` 和 `weight` 组成，`name` 指定评分时要考虑的资源， -`weight` 指定每种资源的权重。 +`weight` 指定每种资源的权重。 它可以用来添加扩展资源，如下所示： @@ -249,4 +251,3 @@ CPU = resourceScoringFunction((2+6),8) NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) = 7 ``` - diff --git a/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index 42894aca1e..8a43385d13 100644 --- a/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -1,14 +1,16 @@ --- title: 调度器性能调优 content_type: concept -weight: 80 +weight: 100 --- @@ -45,7 +47,7 @@ large Kubernetes clusters. - ### 设置阈值 - -要修改这个值，编辑 [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`。 - 修改完成后，你可以执行 @@ -96,17 +98,17 @@ After you have made this change, you can run kubectl get pods -n kube-system | grep kube-scheduler ``` - 来检查该 kube-scheduler 组件是否健康。 - ## 节点打分阈值 {#percentage-of-nodes-to-score} - -你可以使用整个集群节点总数的百分比作为阈值来指定需要多少节点就足够。 +你可以使用整个集群节点总数的百分比作为阈值来指定需要多少节点就足够。 kube-scheduler 会将它转换为节点数的整数值。在调度期间，如果 kube-scheduler 已确认的可调度节点数足以超过了配置的百分比数量， kube-scheduler 将停止继续查找可调度节点并继续进行 [打分阶段](/zh/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)。 - [调度器如何遍历节点](#how-the-scheduler-iterates-over-nodes) 详细介绍了这个过程。 - ### 默认阈值 - 这意味着，调度器至少会对集群中 5% 的节点进行打分，除非用户将该参数设置的低于 5。 - 如果你想让调度器对集群内所有节点进行打分，则将 `percentageOfNodesToScore` 设置为 100。 - ## 示例 @@ -189,15 +191,15 @@ percentageOfNodesToScore: 50 `percentageOfNodesToScore` 的值必须在 1 到 100 之间，而且其默认值是通过集群的规模计算得来的。 另外，还有一个 50 个 Node 的最小值是硬编码在程序中。 在评估完所有 Node 后，将会返回到 Node 1，从头开始。 - ## {{% heading "whatsnext" %}} -* 查阅 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/) + +* 参见 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/) diff --git a/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md index 5927a4c8f3..1107c19565 100644 --- a/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md +++ b/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md @@ -1,15 +1,17 @@ --- title: 调度框架 content_type: concept -weight: 70 +weight: 90 --- @@ -17,17 +19,15 @@ weight: 70 {{< feature-state for_k8s_version="1.15" state="alpha" >}} -调度框架是 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="调度框架扩展点" >}} @@ -163,12 +163,12 @@ tries to make the pod schedulable by preempting other Pods. 则其余的插件不会调用。典型的后筛选实现是抢占，试图通过抢占其他 Pod 的资源使该 Pod 可以调度。 - ### 前置评分 {#pre-score} - ### 评分 {#scoring} @@ -325,17 +325,17 @@ _Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟 将返回调度队列，从而触发 [Unreserve](#unreserve) 插件。 - {{< 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 >}} # 插件配置 - @@ -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` (*只适合主机网络配置*) diff --git a/content/zh/docs/concepts/workloads/pods/_index.md b/content/zh/docs/concepts/workloads/pods/_index.md index 422ee139c2..4dde0a45db 100644 --- a/content/zh/docs/concepts/workloads/pods/_index.md +++ b/content/zh/docs/concepts/workloads/pods/_index.md @@ -135,7 +135,7 @@ Kubernetes 集群中的 Pod 主要有两种用法： * **运行多个协同工作的容器的 Pod**。 Pod 可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。 这些位于同一位置的容器可能形成单个内聚的服务单元 —— 一个容器将文件从共享卷提供给公众， - 而另一个单独的“挂斗”（sidecar）容器则刷新或更新这些文件。 + 而另一个单独的“边车”（sidecar）容器则刷新或更新这些文件。 Pod 将这些容器和存储资源打包为一个可管理的实体。 {{< note >}} diff --git a/content/zh/docs/concepts/workloads/pods/disruptions.md b/content/zh/docs/concepts/workloads/pods/disruptions.md index c200a51757..e146d66bc5 100644 --- a/content/zh/docs/concepts/workloads/pods/disruptions.md +++ b/content/zh/docs/concepts/workloads/pods/disruptions.md @@ -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/) 也会产生自愿（和非自愿）的干扰。 -### 临时容器 API {#ephemeral-containers-api}」 +### 临时容器 API {#ephemeral-containers-api} {{< note >}} @@ -29,16 +30,26 @@ This section of the Kubernetes documentation contains references. ## 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 客户端库 +## 官方支持的客户端库 如果您需要通过编程语言调用 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 参考 +## 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 集群。 -## 组件参考 +## 组件 + +* [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) + + +## 配置 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) ## 设计文档 diff --git a/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md b/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md index 82b37c9043..071329096c 100644 --- a/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md @@ -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. 如果该 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 中。 -当 `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" >}} + + +当 `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 +``` + + +此投射卷有三个数据源： + +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。 + + +参阅[投射卷](/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage/) +了解进一步的细节。 + +如果 `BoundServiceAccountTokenVolume` 特性门控未被启用， +你可以手动地将一个基于 Secret 的服务账号卷升级为一个投射卷， +方法是将上述投射卷添加到 Pod 规约中。 +不过，这时仍需要启用 `RootCAConfigMap` 特性门控。 ## {{% 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 -已弃用: 要监听 --port 端口的 IP 地址（对于所有 IPv4 接口设置为 0.0.0.0，对于所有 IPv6 接口设置为 ::）。 +已弃用： 要监听 --port 端口的 IP 地址（将其设置为 0.0.0.0 或者 :: 用于监听所有接口和 IP族）。 请参阅 --bind-address。 +如果在 --config 中指定了一个配置文件，这个参数将被忽略。 @@ -73,19 +76,36 @@ DEPRECATED: the IP address on which to listen for the --port port (set to 0.0.0. -已弃用: 要使用的调度算法驱动，此标志设置组件配置框架的默认插件。 +已弃用： 要使用的调度算法驱动，此标志设置组件配置框架的默认插件。 可选值：ClusterAutoscalerProvider | DefaultProvider + +--allow-metric-labels stringToString      +默认值： [] + + + + +这个键值映射表设置 度量标签 所允许设置的值。 +其中键的格式是 <MetricName>,<LabelName>。 +值的格式是 <allowed_value>,<allowed_value>。 +例如：metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'。 + + + --alsologtostderr +日志记录到标准错误以及文件 @@ -141,7 +161,7 @@ If true, failures to look up missing authentication configuration from the clust ---authorization-always-allow-paths stringSlice     默认值：[/healthz] +--authorization-always-allow-paths strings     默认值："/healthz,/readyz,/livez" @@ -203,16 +223,17 @@ Path to the file containing Azure container registry configuration information. ---bind-address ip     默认值：0.0.0.0 +--bind-address string     默认值：0.0.0.0 监听 --secure-port 端口的 IP 地址。 集群的其余部分以及 CLI/ Web 客户端必须可以访问关联的接口。 如果为空，将使用所有接口（0.0.0.0 表示使用所有 IPv4 接口，"::" 表示使用所有 IPv6 接口）。 +如果为空或未指定地址 (0.0.0.0 或 ::)，所有接口将被使用。 @@ -248,27 +269,43 @@ If set, any request presenting a client certificate signed by one of the authori 配置文件的路径。以下标志会覆盖此文件中的值：
---address
---port
---use-legacy-policy-config
---policy-configmap
+--algorithm-provider
--policy-config-file
---algorithm-provider +--policy-configmap
+--policy-configmap-namespace ---contention-profiling +--contention-profiling     默认值: true -已弃用: 如果启用了性能分析，则启用锁竞争分析 +已弃用: 如果启用了性能分析，则启用锁竞争分析。 +如果 --config 指定了一个配置文件，那么这个参数将被忽略。 + + + + +--disabled-metrics strings + + + + +这个标志提供了一个规避不良指标的选项。你必须提供完整的指标名称才能禁用它。 +免责声明：禁用指标的优先级比显示隐藏的指标更高。 @@ -287,7 +324,7 @@ DEPRECATED: enable lock contention profiling, if profiling is enabled ---feature-gates mapStringBool +--feature-gates <逗号分隔的 'key=True|False' 对> @@ -299,41 +336,35 @@ APIResponseCompression=true|false (BETA - default=true)
APIServerIdentity=true|false (ALPHA - default=false)
AllAlpha=true|false (ALPHA - default=false)
AllBeta=true|false (BETA - default=false)
-AllowInsecureBackendProxy=true|false (BETA - default=true)
AnyVolumeDataSource=true|false (ALPHA - default=false)
AppArmor=true|false (BETA - default=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)
-BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)
+BoundServiceAccountTokenVolume=true|false (BETA - default=true)
CPUManager=true|false (BETA - default=true)
-CRIContainerLogRotation=true|false (BETA - default=true)
CSIInlineVolume=true|false (BETA - default=true)
CSIMigration=true|false (BETA - default=true)
CSIMigrationAWS=true|false (BETA - default=false)
-CSIMigrationAWSComplete=true|false (ALPHA - default=false)
CSIMigrationAzureDisk=true|false (BETA - default=false)
-CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)
-CSIMigrationAzureFile=true|false (ALPHA - default=false)
-CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)
+CSIMigrationAzureFile=true|false (BETA - default=false)
CSIMigrationGCE=true|false (BETA - default=false)
-CSIMigrationGCEComplete=true|false (ALPHA - default=false)
-CSIMigrationOpenStack=true|false (BETA - default=false)
-CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)
+CSIMigrationOpenStack=true|false (BETA - default=true)
CSIMigrationvSphere=true|false (BETA - default=false)
CSIMigrationvSphereComplete=true|false (BETA - default=false)
-CSIServiceAccountToken=true|false (ALPHA - default=false)
-CSIStorageCapacity=true|false (ALPHA - default=false)
+CSIServiceAccountToken=true|false (BETA - default=true)
+CSIStorageCapacity=true|false (BETA - default=true)
CSIVolumeFSGroupPolicy=true|false (BETA - default=true)
+CSIVolumeHealth=true|false (ALPHA - default=false)
ConfigurableFSGroupPolicy=true|false (BETA - default=true)
-CronJobControllerV2=true|false (ALPHA - default=false)
+ControllerManagerLeaderMigration=true|false (ALPHA - default=false)
+CronJobControllerV2=true|false (BETA - default=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
+DaemonSetUpdateSurge=true|false (ALPHA - default=false)
DefaultPodTopologySpread=true|false (BETA - default=true)
DevicePlugins=true|false (BETA - default=true)
DisableAcceleratorUsageMetrics=true|false (BETA - default=true)
-DownwardAPIHugePages=true|false (ALPHA - default=false)
+DownwardAPIHugePages=true|false (BETA - default=false)
DynamicKubeletConfig=true|false (BETA - default=true)
-EfficientWatchResumption=true|false (ALPHA - default=false)
-EndpointSlice=true|false (BETA - default=true)
-EndpointSliceNodeName=true|false (ALPHA - default=false)
+EfficientWatchResumption=true|false (BETA - default=true)
EndpointSliceProxying=true|false (BETA - default=true)
EndpointSliceTerminatingCondition=true|false (ALPHA - default=false)
EphemeralContainers=true|false (ALPHA - default=false)
@@ -341,90 +372,98 @@ ExpandCSIVolumes=true|false (BETA - default=true)
ExpandInUsePersistentVolumes=true|false (BETA - default=true)
ExpandPersistentVolumes=true|false (BETA - default=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
-GenericEphemeralVolume=true|false (ALPHA - default=false)
-GracefulNodeShutdown=true|false (ALPHA - default=false)
+GenericEphemeralVolume=true|false (BETA - default=true)
+GracefulNodeShutdown=true|false (BETA - default=true)
HPAContainerMetrics=true|false (ALPHA - default=false)
HPAScaleToZero=true|false (ALPHA - default=false)
HugePageStorageMediumSize=true|false (BETA - default=true)
-IPv6DualStack=true|false (ALPHA - default=false)
-ImmutableEphemeralVolumes=true|false (BETA - default=true)
+IPv6DualStack=true|false (BETA - default=true)
+InTreePluginAWSUnregister=true|false (ALPHA - default=false)
+InTreePluginAzureDiskUnregister=true|false (ALPHA - default=false)
+InTreePluginAzureFileUnregister=true|false (ALPHA - default=false)
+InTreePluginGCEUnregister=true|false (ALPHA - default=false)
+InTreePluginOpenStackUnregister=true|false (ALPHA - default=false)
+InTreePluginvSphereUnregister=true|false (ALPHA - default=false)
+IndexedJob=true|false (ALPHA - default=false)
+IngressClassNamespacedParams=true|false (ALPHA - default=false)
KubeletCredentialProviders=true|false (ALPHA - default=false)
KubeletPodResources=true|false (BETA - default=true)
-LegacyNodeRoleBehavior=true|false (BETA - default=true)
+KubeletPodResourcesGetAllocatable=true|false (ALPHA - default=false)
LocalStorageCapacityIsolation=true|false (BETA - default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
+LogarithmicScaleDown=true|false (ALPHA - default=false)
+MemoryManager=true|false (ALPHA - default=false)
MixedProtocolLBService=true|false (ALPHA - default=false)
-NodeDisruptionExclusion=true|false (BETA - default=true)
+NamespaceDefaultLabelName=true|false (BETA - default=true)
+NetworkPolicyEndPort=true|false (ALPHA - default=false)
NonPreemptingPriority=true|false (BETA - default=true)
-PodDisruptionBudget=true|false (BETA - default=true)
+PodAffinityNamespaceSelector=true|false (ALPHA - default=false)
+PodDeletionCost=true|false (ALPHA - default=false)
PodOverhead=true|false (BETA - default=true)
+PreferNominatedNode=true|false (ALPHA - default=false)
+ProbeTerminationGracePeriod=true|false (ALPHA - default=false)
ProcMountType=true|false (ALPHA - default=false)
QOSReserved=true|false (ALPHA - default=false)
RemainingItemCount=true|false (BETA - default=true)
RemoveSelfLink=true|false (BETA - default=true)
-RootCAConfigMap=true|false (BETA - default=true)
RotateKubeletServerCertificate=true|false (BETA - default=true)
-RunAsGroup=true|false (BETA - default=true)
ServerSideApply=true|false (BETA - default=true)
-ServiceAccountIssuerDiscovery=true|false (BETA - default=true)
+ServiceInternalTrafficPolicy=true|false (ALPHA - default=false)
ServiceLBNodePortControl=true|false (ALPHA - default=false)
-ServiceNodeExclusion=true|false (BETA - default=true)
+ServiceLoadBalancerClass=true|false (ALPHA - default=false)
ServiceTopology=true|false (ALPHA - default=false)
SetHostnameAsFQDN=true|false (BETA - default=true)
SizeMemoryBackedVolumes=true|false (ALPHA - default=false)
StorageVersionAPI=true|false (ALPHA - default=false)
StorageVersionHash=true|false (BETA - default=true)
-Sysctls=true|false (BETA - default=true)
-TTLAfterFinished=true|false (ALPHA - default=false)
+SuspendJob=true|false (ALPHA - default=false)
+TTLAfterFinished=true|false (BETA - default=true)
+TopologyAwareHints=true|false (ALPHA - default=false)
TopologyManager=true|false (BETA - default=true)
ValidateProxyRedirects=true|false (BETA - default=true)
+VolumeCapacityPriority=true|false (ALPHA - default=false)
WarningHeaders=true|false (BETA - default=true)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (BETA - default=true)
-WindowsEndpointSliceProxying=true|false (ALPHA - default=false) +WindowsEndpointSliceProxying=true|false (BETA - default=true) --> 一组 key=value 对，描述了 alpha/experimental 特征开关。选项包括：
+A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
APIListChunking=true|false (BETA - 默认值=true)
APIPriorityAndFairness=true|false (BETA - 默认值=true)
APIResponseCompression=true|false (BETA - 默认值=true)
APIServerIdentity=true|false (ALPHA - 默认值=false)
AllAlpha=true|false (ALPHA - 默认值=false)
AllBeta=true|false (BETA - 默认值=false)
-AllowInsecureBackendProxy=true|false (BETA - 默认值=true)
AnyVolumeDataSource=true|false (ALPHA - 默认值=false)
AppArmor=true|false (BETA - 默认值=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false)
-BoundServiceAccountTokenVolume=true|false (ALPHA - 默认值=false)
+BoundServiceAccountTokenVolume=true|false (BETA - 默认值=true)
CPUManager=true|false (BETA - 默认值=true)
-CRIContainerLogRotation=true|false (BETA - 默认值=true)
CSIInlineVolume=true|false (BETA - 默认值=true)
CSIMigration=true|false (BETA - 默认值=true)
-CSIMigrationAWS=true|false (BETA - 默认值=true)
-CSIMigrationAWSComplete=true|false (ALPHA - 默认值=false)
-CSIMigrationAzureDisk=true|false (BETA - 默认值=true)
-CSIMigrationAzureDiskComplete=true|false (ALPHA - 默认值=false)
-CSIMigrationAzureFile=true|false (ALPHA - 默认值=false)
-CSIMigrationAzureFileComplete=true|false (ALPHA - 默认值=false)
-CSIMigrationGCE=true|false (BETA - 默认值=true)
-CSIMigrationGCEComplete=true|false (ALPHA - 默认值=false)
+CSIMigrationAWS=true|false (BETA - 默认值=false)
+CSIMigrationAzureDisk=true|false (BETA - 默认值=false)
+CSIMigrationAzureFile=true|false (BETA - 默认值=false)
+CSIMigrationGCE=true|false (BETA - 默认值=false)
CSIMigrationOpenStack=true|false (BETA - 默认值=true)
-CSIMigrationOpenStackComplete=true|false (ALPHA - 默认值=false)
CSIMigrationvSphere=true|false (BETA - 默认值=false)
-CSIMigrationvSphereComplete=true|false (BETA - default=false)
-CSIServiceAccountToken=true|false (ALPHA - 默认值=false)
-CSIStorageCapacity=true|false (ALPHA - 默认值=false)
+CSIMigrationvSphereComplete=true|false (BETA - 默认值=false)
+CSIServiceAccountToken=true|false (BETA - 默认值=true)
+CSIStorageCapacity=true|false (BETA - 默认值=true)
CSIVolumeFSGroupPolicy=true|false (BETA - 默认值=true)
+CSIVolumeHealth=true|false (ALPHA - 默认值=false)
ConfigurableFSGroupPolicy=true|false (BETA - 默认值=true)
-CronJobControllerV2=true|false (ALPHA - 默认值=false)
+ControllerManagerLeaderMigration=true|false (ALPHA - 默认值=false)
+CronJobControllerV2=true|false (BETA - 默认值=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
+DaemonSetUpdateSurge=true|false (ALPHA - 默认值=false)
DefaultPodTopologySpread=true|false (BETA - 默认值=true)
DevicePlugins=true|false (BETA - 默认值=true)
DisableAcceleratorUsageMetrics=true|false (BETA - 默认值=true)
-DownwardAPIHugePages=true|false (ALPHA - 默认值=false)
+DownwardAPIHugePages=true|false (BETA - 默认值=false)
DynamicKubeletConfig=true|false (BETA - 默认值=true)
-EfficientWatchResumption=true|false (ALPHA - 默认值=false)
-EndpointSlice=true|false (ALPHA - 默认值=false)
-EndpointSliceNodeName=true|false (ALPHA - 默认值=false)
+EfficientWatchResumption=true|false (BETA - 默认值=true)
EndpointSliceProxying=true|false (BETA - 默认值=true)
EndpointSliceTerminatingCondition=true|false (ALPHA - 默认值=false)
EphemeralContainers=true|false (ALPHA - 默认值=false)
@@ -432,47 +471,60 @@ ExpandCSIVolumes=true|false (BETA - 默认值=true)
ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
ExpandPersistentVolumes=true|false (BETA - 默认值=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false)
-GenericEphemeralVolume=true|false (ALPHA - 默认值=false)
-GracefulNodeShutdown=true|false (ALPHA - 默认值=false)
+GenericEphemeralVolume=true|false (BETA - 默认值=true)
+GracefulNodeShutdown=true|false (BETA - 默认值=true)
HPAContainerMetrics=true|false (ALPHA - 默认值=false)
HPAScaleToZero=true|false (ALPHA - 默认值=false)
HugePageStorageMediumSize=true|false (BETA - 默认值=true)
-IPv6DualStack=true|false (ALPHA - 默认值=false)
-ImmutableEphemeralVolumes=true|false (BETA - 默认值=true)
+IPv6DualStack=true|false (BETA - 默认值=true)
+InTreePluginAWSUnregister=true|false (ALPHA - 默认值=false)
+InTreePluginAzureDiskUnregister=true|false (ALPHA - 默认值=false)
+InTreePluginAzureFileUnregister=true|false (ALPHA - 默认值=false)
+InTreePluginGCEUnregister=true|false (ALPHA - 默认值=false)
+InTreePluginOpenStackUnregister=true|false (ALPHA - 默认值=false)
+InTreePluginvSphereUnregister=true|false (ALPHA - 默认值=false)
+IndexedJob=true|false (ALPHA - 默认值=false)
+IngressClassNamespacedParams=true|false (ALPHA - 默认值=false)
KubeletCredentialProviders=true|false (ALPHA - 默认值=false)
KubeletPodResources=true|false (BETA - 默认值=true)
-LegacyNodeRoleBehavior=true|false (BETA - 默认值=true)
+KubeletPodResourcesGetAllocatable=true|false (ALPHA - 默认值=false)
LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
+LogarithmicScaleDown=true|false (ALPHA - 默认值=false)
+MemoryManager=true|false (ALPHA - 默认值=false)
MixedProtocolLBService=true|false (ALPHA - 默认值=false)
-NodeDisruptionExclusion=true|false (BETA - 默认值=false)
+NamespaceDefaultLabelName=true|false (BETA - 默认值=true)
+NetworkPolicyEndPort=true|false (ALPHA - 默认值=false)
NonPreemptingPriority=true|false (BETA - 默认值=true)
-PodDisruptionBudget=true|false (BETA - 默认值=true)
+PodAffinityNamespaceSelector=true|false (ALPHA - 默认值=false)
+PodDeletionCost=true|false (ALPHA - 默认值=false)
PodOverhead=true|false (BETA - 默认值=true)
+PreferNominatedNode=true|false (ALPHA - 默认值=false)
+ProbeTerminationGracePeriod=true|false (ALPHA - 默认值=false)
ProcMountType=true|false (ALPHA - 默认值=false)
QOSReserved=true|false (ALPHA - 默认值=false)
RemainingItemCount=true|false (BETA - 默认值=true)
RemoveSelfLink=true|false (BETA - 默认值=true)
-RootCAConfigMap=true|false (BETA - 默认值=true)
RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
-RunAsGroup=true|false (BETA - 默认值=true)
ServerSideApply=true|false (BETA - 默认值=true)
-ServiceAccountIssuerDiscovery=true|false (BETA - 默认值=true)
+ServiceInternalTrafficPolicy=true|false (ALPHA - 默认值=false)
ServiceLBNodePortControl=true|false (ALPHA - 默认值=false)
-ServiceNodeExclusion=true|false (BETA - 默认值=true)
+ServiceLoadBalancerClass=true|false (ALPHA - 默认值=false)
ServiceTopology=true|false (ALPHA - 默认值=false)
SetHostnameAsFQDN=true|false (BETA - 默认值=true)
SizeMemoryBackedVolumes=true|false (ALPHA - 默认值=false)
StorageVersionAPI=true|false (ALPHA - 默认值=false)
StorageVersionHash=true|false (BETA - 默认值=true)
-Sysctls=true|false (BETA - 默认值=true)
-TTLAfterFinished=true|false (ALPHA - 默认值=false)
+SuspendJob=true|false (ALPHA - 默认值=false)
+TTLAfterFinished=true|false (BETA - 默认值=true)
+TopologyAwareHints=true|false (ALPHA - 默认值=false)
TopologyManager=true|false (BETA - 默认值=true)
ValidateProxyRedirects=true|false (BETA - 默认值=true)
+VolumeCapacityPriority=true|false (ALPHA - 默认值=false)
WarningHeaders=true|false (BETA - 默认值=true)
WinDSR=true|false (ALPHA - 默认值=false)
WinOverlay=true|false (BETA - 默认值=true)
-WindowsEndpointSliceProxying=true|false (ALPHA - 默认值=false) +WindowsEndpointSliceProxying=true|false (BETA - 默认值=true) @@ -482,12 +534,13 @@ WindowsEndpointSliceProxying=true|false (ALPHA - 默认值=false) 已弃用: RequiredDuringScheduling 亲和性是不对称的，但是存在与每个 RequiredDuringScheduling 关联性规则相对应的隐式 PreferredDuringScheduling 关联性规则。 --hard-pod-affinity-symmetric-weight 代表隐式 PreferredDuringScheduling -关联性规则的权重。权重必须在 0-100 范围内。此选项已移至策略配置文件。 +关联性规则的权重。权重必须在 0-100 范围内。 +如果 --config 指定了一个配置文件，那么这个参数将被忽略。 @@ -521,9 +574,10 @@ The limit that the server gives to clients for the maximum number of streams in 已弃用: 与 kubernetes API 通信时使用的突发请求个数限值。 +如果 --config 指定了一个配置文件，那么这个参数将被忽略。 @@ -533,9 +587,10 @@ DEPRECATED: burst to use while talking with kubernetes apiserver 已弃用: 发送到 API 服务器的请求的内容类型。 +如果 --config 指定了一个配置文件，那么这个参数将被忽略。 @@ -545,9 +600,10 @@ DEPRECATED: content type of requests sent to apiserver. 已弃用: 与 kubernetes apiserver 通信时要使用的 QPS +如果 --config 指定了一个配置文件，那么这个参数将被忽略。 @@ -557,9 +613,10 @@ DEPRECATED: QPS to use while talking with kubernetes apiserver 已弃用: 包含鉴权和主节点位置信息的 kubeconfig 文件的路径。 +如果 --config 指定了一个配置文件，那么这个参数将被忽略。 @@ -604,7 +661,7 @@ The interval between attempts by the acting master to renew a leadership slot be ---leader-elect-resource-lock endpoints     默认值："leases" +--leader-elect-resource-lock string     默认值："leases" @@ -659,9 +716,10 @@ The duration the clients should wait between attempting acquisition and renewal 已弃用: 定义锁对象的名称。将被删除以便使用 --leader-elect-resource-name。 +如果 --config 指定了一个配置文件，那么这个参数将被忽略。 @@ -671,14 +729,16 @@ DEPRECATED: define the name of the lock object. Will be removed in favor of lead 已弃用: 定义锁对象的命名空间。将被删除以便使用 leader-elect-resource-namespace。 +如果 --config 指定了一个配置文件，那么这个参数将被忽略。 ---log-backtrace-at traceLocation     默认值：:0 +--log-backtrace-at <a string in the form 'file:N'>      +默认值: 0 @@ -739,19 +799,24 @@ Maximum number of seconds between log flushes ---logging-format string     默认值："text" +--logging-format string     默认值：“text” -设置日志格式。可选格式："json"、"text"。
-非默认格式不会在意以下标志设置： ---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.
+设置日志格式。可选格式：“json”，“text”。
+采用非默认格式时，以下标识不会生效： +--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.
非默认选项目前处于 Alpha 阶段，有可能会出现变更且无事先警告。 @@ -786,22 +851,38 @@ Kubernetes API 服务器的地址（覆盖 kubeconfig 中的任何值）。 若此标志为 true，则日志仅写入其自身的严重性级别，而不会写入所有较低严重性级别。 + +--permit-address-sharing + + + + +如果为 true，在绑定端口时将使用 SO_REUSEADDR。 +这将允许同时绑定诸如 0.0.0.0 这类通配符 IP和特定 IP， +并且它避免等待内核释放处于 TIME_WAIT 状态的套接字。 +默认值： false + + + --permit-port-sharing 如果此标志为 true，在绑定端口时会使用 SO_REUSEPORT，从而允许不止一个 实例绑定到同一地址和端口。 +默认值：false @@ -853,22 +934,25 @@ DEPRECATED: the namespace where policy ConfigMap is located. The kube-system nam -已弃用: 在没有身份验证和授权的情况下不安全地为 HTTP 服务的端口。 -如果为0，则根本不提供 HTTP。请参见--secure-port。 +已弃用： 在没有身份验证和鉴权的情况下不安全地为 HTTP 服务的端口。 +如果为 0，则根本不提供 HTTP。请参见 --secure-port。 +如果 --config 指定了一个配置文件，这个参数将被忽略。 ---profiling +--profiling     默认值： true 已弃用: 通过 Web 界面主机启用配置文件：host:port/debug/pprof/。 +如果 --config 指定了一个配置文件，这个参数将被忽略。 @@ -901,7 +985,8 @@ Root certificate bundle to use to verify client certificates on incoming request - --requestheader-extra-headers-prefix stringSlice     默认值：[x-remote-extra-] +--requestheader-extra-headers-prefix strings      +默认值: "x-remote-extra-" @@ -913,7 +998,8 @@ List of request header prefixes to inspect. X-Remote-Extra- is suggested. ---requestheader-group-headers stringSlice     默认值：[x-remote-group] +--requestheader-group-headers strings      +默认值: "x-remote-group" @@ -925,7 +1011,8 @@ List of request headers to inspect for groups. X-Remote-Group is suggested. ---requestheader-username-headers stringSlice     默认值：[x-remote-user] +--requestheader-username-headers strings      +默认值: "x-remote-user" @@ -937,15 +1024,17 @@ List of request headers to inspect for usernames. X-Remote-User is common. ---scheduler-name string     默认值："default-scheduler" +--scheduler-name string      +默认值："default-scheduler" -已弃用: 调度器名称，用于根据 Pod 的 "spec.schedulerName" 选择此 +已弃用: 调度器名称，用于根据 Pod 的 “spec.schedulerName” 选择此 调度器将处理的 Pod。 +如果 --config 指定了一个配置文件，那么这个参数将被忽略 @@ -955,7 +1044,7 @@ DEPRECATED: name of the scheduler, used to select which pods will be processed b 通过身份验证和授权为 HTTPS 服务的端口。如果为 0，则根本不提供 HTTPS。 @@ -1001,7 +1090,7 @@ If true, avoid headers when opening log files ---stderrthreshold severity     默认值：2 +--stderrthreshold int     默认值：2 @@ -1028,15 +1117,16 @@ File containing the default x509 Certificate for HTTPS. (CA cert, if any, concat ---tls-cipher-suites stringSlice +--tls-cipher-suites strings 服务器的密码套件列表，以逗号分隔。如果省略，将使用默认的 Go 密码套件。 优先考虑的值： @@ -1071,18 +1161,20 @@ File containing the default x509 private key matching --tls-cert-file. ---tls-sni-cert-key namedCertKey     默认值：[] +--tls-sni-cert-key string -一对 x509 证书和私钥文件路径，可选地后缀为完全限定域名的域模式列表， -并可能带有前缀的通配符段。如果未提供域名模式，则提取证书名称。 -非通配符匹配优先于通配符匹配，显式域名模式优先于提取而来的名称。 +一对 x509 证书和私钥文件路径，也可以包含由全限定域名构成的域名模式列表作为后缀， +并可能带有前缀的通配符段。域名匹配还允许是 IP 地址， +但是只有当 apiserver 对客户端请求的 IP 地址可见时，才能使用 IP。 +如果未提供域名匹配模式，则提取证书名称。 +非通配符匹配优先于通配符匹配，显式域名匹配优先于提取而来的名称。 若有多个密钥/证书对，可多次使用 --tls-sni-cert-key。 -例如: "example.crt,example.key" 或者 "foo.crt,foo.key:*.foo.com,foo.com"。 +例子: "example.crt,example.key" 或者 "foo.crt,foo.key:*.foo.com,foo.com"。 @@ -1100,7 +1192,7 @@ DEPRECATED: when set to true, scheduler will ignore policy ConfigMap and uses po --v, --v Level +-v, --v int @@ -1124,14 +1216,14 @@ Print version information and quit ---vmodule moduleSpec +--vmodule <逗号分隔的 ‘模式=N’ 配置列表> -以逗号分隔的 pattern=N 设置列表，用于文件过滤的日志记录。 +以逗号分隔的 ‘模式=N’ 设置列表，用于文件过滤的日志记录。 diff --git a/content/zh/docs/reference/glossary/pod.md b/content/zh/docs/reference/glossary/pod.md index 71a1494e0a..873ec90e62 100644 --- a/content/zh/docs/reference/glossary/pod.md +++ b/content/zh/docs/reference/glossary/pod.md @@ -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。 diff --git a/content/zh/docs/reference/labels-annotations-taints.md b/content/zh/docs/reference/labels-annotations-taints.md index 1c163cc056..e4b1fdfe70 100644 --- a/content/zh/docs/reference/labels-annotations-taints.md +++ b/content/zh/docs/reference/labels-annotations-taints.md @@ -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 + + +当 `NamespaceDefaultLabelName` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +被启用时，Kubernetes API 服务器会在所有命名空间上设置此标签。标签值被设置为命名空间的名称。 + +如果你想使用标签 {{< glossary_tooltip text="选择器" term_id="selector" >}} 来指向特定的命名空间，这很有用。 + ## beta.kubernetes.io/arch (deprecated) +该注解用于设置 [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` + + +当 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 + + +当单个的 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 + + +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"` + + +注解的值是此 Pod 的默认容器名称。 +例如，`kubectl logs` 或 `kubectl exec` 没有 `-c` 或 `--container` 参数时，将使用这个默认的容器。 + +## endpoints.kubernetes.io/over-capacity + +示例：`endpoints.kubernetes.io/over-capacity:warning` + +用于：Endpoints + + +在 Kubernetes 集群 v1.21（或更高版本）中，如果 Endpoint 超过 1000 个，Endpoint 控制器 +就会向其添加这个注解。该注解表示 Endpoint 资源已超过容量。 + **以下列出的污点只能用于 Node** ## node.kubernetes.io/not-ready diff --git a/static/_redirects b/static/_redirects index b89d7ea7af..0d95cef56f 100644 --- a/static/_redirects +++ b/static/_redirects @@ -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