diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 6a565dba2dbf9..a34ed8d9c49c2 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -216,12 +216,14 @@ aliases: - aisonaku - potapy4 - dianaabv + - shurup sig-docs-ru-reviews: # PR reviews for Russian content - Arhell - msheldyakov - aisonaku - potapy4 - dianaabv + - shurup sig-docs-pl-owners: # Admins for Polish content - mfilocha - nvtkaszpir diff --git a/content/en/blog/_posts/2022-11-04-live-and-let-live-with-kluctl-and-ssa.md b/content/en/blog/_posts/2022-11-04-live-and-let-live-with-kluctl-and-ssa.md index c9c43fb900a10..1e528eede3cc2 100644 --- a/content/en/blog/_posts/2022-11-04-live-and-let-live-with-kluctl-and-ssa.md +++ b/content/en/blog/_posts/2022-11-04-live-and-let-live-with-kluctl-and-ssa.md @@ -20,7 +20,7 @@ for the past 2 years. I describe Kluctl as "The missing glue to put together large Kubernetes deployments, composed of multiple smaller parts (Helm/Kustomize/...) in a manageable and unified way." -To get a basic understanding of Kluctl, I suggest to visit the [kluctl.io](https://kluctlio) +To get a basic understanding of Kluctl, I suggest to visit the [kluctl.io](https://kluctl.io) website and read through the documentation and tutorials, for example the [microservices demo tutorial](https://kluctl.io/docs/guides/tutorials/microservices-demo/). As an alternative, you can watch [Hands-on Introduction to kluctl](https://www.youtube.com/watch?v=9LoYLjDjOdg) diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md index ce290c33e1367..2e8981e4b953d 100644 --- a/content/en/docs/concepts/configuration/manage-resources-containers.md +++ b/content/en/docs/concepts/configuration/manage-resources-containers.md @@ -346,7 +346,8 @@ or 400 megabytes (`400M`). In the following example, the Pod has two containers. Each container has a request of 2GiB of local ephemeral storage. Each container has a limit of 4GiB of local ephemeral storage. Therefore, the Pod has a request of 4GiB of local ephemeral storage, and -a limit of 8GiB of local ephemeral storage. +a limit of 8GiB of local ephemeral storage. 500Mi of that limit could be +consumed by the `emptyDir` volume. ```yaml apiVersion: v1 @@ -377,7 +378,8 @@ spec: mountPath: "/tmp" volumes: - name: ephemeral - emptyDir: {} + emptyDir: + sizeLimit: 500Mi ``` ### How Pods with ephemeral-storage requests are scheduled diff --git a/content/en/docs/concepts/scheduling-eviction/_index.md b/content/en/docs/concepts/scheduling-eviction/_index.md index fd1c0bbf00b3e..00330b5a4b3eb 100644 --- a/content/en/docs/concepts/scheduling-eviction/_index.md +++ b/content/en/docs/concepts/scheduling-eviction/_index.md @@ -1,6 +1,6 @@ --- title: "Scheduling, Preemption and Eviction" -weight: 90 +weight: 95 content_type: concept description: > In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes diff --git a/content/en/docs/concepts/security/_index.md b/content/en/docs/concepts/security/_index.md index 3dfb62fe48253..50edcda94a3f6 100644 --- a/content/en/docs/concepts/security/_index.md +++ b/content/en/docs/concepts/security/_index.md @@ -1,6 +1,6 @@ --- title: "Security" -weight: 81 +weight: 85 description: > Concepts for keeping your cloud-native workload secure. --- diff --git a/content/en/docs/concepts/storage/dynamic-provisioning.md b/content/en/docs/concepts/storage/dynamic-provisioning.md index 9c46cc96444ff..54ab391d80636 100644 --- a/content/en/docs/concepts/storage/dynamic-provisioning.md +++ b/content/en/docs/concepts/storage/dynamic-provisioning.md @@ -19,9 +19,6 @@ to represent them in Kubernetes. The dynamic provisioning feature eliminates the need for cluster administrators to pre-provision storage. Instead, it automatically provisions storage when it is requested by users. - - - ## Background @@ -116,7 +113,7 @@ can enable this behavior by: is enabled on the API server. An administrator can mark a specific `StorageClass` as default by adding the -`storageclass.kubernetes.io/is-default-class` [annotation](/docs/reference/labels-annotations-taints/#storageclass-kubernetes-io-is-default-class) to it. +[`storageclass.kubernetes.io/is-default-class` annotation](/docs/reference/labels-annotations-taints/#storageclass-kubernetes-io-is-default-class) to it. When a default `StorageClass` exists in a cluster and a user creates a `PersistentVolumeClaim` with `storageClassName` unspecified, the `DefaultStorageClass` admission controller automatically adds the @@ -128,9 +125,9 @@ be created. ## Topology Awareness -In [Multi-Zone](/docs/setup/multiple-zones) clusters, Pods can be spread across +In [Multi-Zone](/docs/setup/best-practices/multiple-zones/) clusters, Pods can be spread across Zones in a Region. Single-Zone storage backends should be provisioned in the Zones where -Pods are scheduled. This can be accomplished by setting the [Volume Binding -Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode). +Pods are scheduled. This can be accomplished by setting the +[Volume Binding Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode). diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index e2d471581c65b..06127e7c5f1a5 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -297,18 +297,18 @@ the following types of volumes: * {{< glossary_tooltip text="csi" term_id="csi" >}} * flexVolume (deprecated) * gcePersistentDisk -* glusterfs +* glusterfs (deprecated) * rbd * portworxVolume You can only expand a PVC if its storage class's `allowVolumeExpansion` field is set to true. -``` yaml +```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: - name: gluster-vol-default -provisioner: kubernetes.io/glusterfs + name: example-vol-default +provisioner: vendor-name.example/magicstorage parameters: resturl: "http://192.168.10.100:8080" restuser: "" @@ -616,7 +616,7 @@ The following volume types support mount options: * `cephfs` * `cinder` (**deprecated** in v1.18) * `gcePersistentDisk` -* `glusterfs` +* `glusterfs` (**deprecated** in v1.25) * `iscsi` * `nfs` * `rbd` diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md index b9a9526f37432..e733bb2debafd 100644 --- a/content/en/docs/concepts/storage/storage-classes.md +++ b/content/en/docs/concepts/storage/storage-classes.md @@ -338,7 +338,7 @@ using `allowedTopologies`. [allowedTopologies](#allowed-topologies) {{< /note >}} -### Glusterfs +### Glusterfs (deprecated) {#glusterfs} ```yaml apiVersion: storage.k8s.io/v1 diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index d6e4caa7c1a11..c3808078b9546 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -335,12 +335,20 @@ Some uses for an `emptyDir` are: * holding files that a content-manager container fetches while a webserver container serves the data -Depending on your environment, `emptyDir` volumes are stored on whatever medium that backs the -node such as disk or SSD, or network storage. However, if you set the `emptyDir.medium` field -to `"Memory"`, Kubernetes mounts a tmpfs (RAM-backed filesystem) for you instead. -While tmpfs is very fast, be aware that unlike disks, tmpfs is cleared on -node reboot and any files you write count against your container's -memory limit. +The `emptyDir.medium` field controls where `emptyDir` volumes are stored. By +default `emptyDir` volumes are stored on whatever medium that backs the node +such as disk, SSD, or network storage, depending on your environment. If you set +the `emptyDir.medium` field to `"Memory"`, Kubernetes mounts a tmpfs (RAM-backed +filesystem) for you instead. While tmpfs is very fast, be aware that unlike +disks, tmpfs is cleared on node reboot and any files you write count against +your container's memory limit. + + +A size limit can be specified for the default medium, which limits the capacity +of the `emptyDir` volume. The storage is allocated from [node ephemeral +storage](docs/concepts/configuration/manage-resources-containers/#setting-requests-and-limits-for-local-ephemeral-storage). +If that is filled up from another source (for example, log files or image +overlays), the `emptyDir` may run out of capacity before this limit. {{< note >}} If the `SizeMemoryBackedVolumes` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled, @@ -364,7 +372,8 @@ spec: name: cache-volume volumes: - name: cache-volume - emptyDir: {} + emptyDir: + sizeLimit: 500Mi ``` ### fc (fibre channel) {#fc} @@ -534,7 +543,7 @@ spec: revision: "22f1d8406d464b0c0874075539c1f2e96c253775" ``` -### glusterfs (deprecated) +### glusterfs (deprecated) {#glusterfs} {{< feature-state for_k8s_version="v1.25" state="deprecated" >}} @@ -542,7 +551,7 @@ A `glusterfs` volume allows a [Glusterfs](https://www.gluster.org) (an open source networked filesystem) volume to be mounted into your Pod. Unlike `emptyDir`, which is erased when a Pod is removed, the contents of a `glusterfs` volume are preserved and the volume is merely unmounted. This -means that a glusterfs volume can be pre-populated with data, and that data can +means that a `glusterfs` volume can be pre-populated with data, and that data can be shared between pods. GlusterFS can be mounted by multiple writers simultaneously. diff --git a/content/en/docs/concepts/workloads/_index.md b/content/en/docs/concepts/workloads/_index.md index dffd727505d46..29b345ba76d1c 100644 --- a/content/en/docs/concepts/workloads/_index.md +++ b/content/en/docs/concepts/workloads/_index.md @@ -1,6 +1,6 @@ --- title: "Workloads" -weight: 50 +weight: 55 description: > Understand Pods, the smallest deployable compute object in Kubernetes, and the higher-level abstractions that help you to run them. no_list: true diff --git a/content/en/docs/reference/access-authn-authz/_index.md b/content/en/docs/reference/access-authn-authz/_index.md index 3677f79c57149..5039373172261 100644 --- a/content/en/docs/reference/access-authn-authz/_index.md +++ b/content/en/docs/reference/access-authn-authz/_index.md @@ -1,6 +1,6 @@ --- title: API Access Control -weight: 15 +weight: 30 no_list: true --- diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md index e7d4f7ece3606..099409f2e5a56 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md @@ -6,7 +6,8 @@ reviewers: - erictune - janetkuo - thockin -title: Using Admission Controllers +title: Admission Controllers Reference +linkTitle: Admission Controllers content_type: concept weight: 30 --- @@ -18,9 +19,19 @@ This page provides an overview of Admission Controllers. ## What are they? -An admission controller is a piece of code that intercepts requests to the +An _admission controller_ is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request -is authenticated and authorized. The controllers consist of the +is authenticated and authorized. + +Admission controllers may be _validating_, _mutating_, or both. Mutating +controllers may modify related objects to the requests they admit; validating controllers may not. + +Admission controllers limit requests to create, delete, modify objects. Admission +controllers can also block custom verbs, such as a request connect to a Pod via +an API server proxy. Admission controllers do _not_ (and cannot) block requests +to read (**get**, **watch** or **list**) objects. + +The admission controllers in Kubernetes {{< skew currentVersion >}} consist of the [list](#what-does-each-admission-controller-do) below, are compiled into the `kube-apiserver` binary, and may only be configured by the cluster administrator. In that list, there are two special controllers: @@ -29,10 +40,7 @@ mutating and validating (respectively) [admission control webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) which are configured in the API. -Admission controllers may be "validating", "mutating", or both. Mutating -controllers may modify related objects to the requests they admit; validating controllers may not. - -Admission controllers limit requests to create, delete, modify objects or connect to proxy. They do not limit requests to read objects. +## Admission control phases The admission control process proceeds in two phases. In the first phase, mutating admission controllers are run. In the second phase, validating @@ -52,7 +60,7 @@ other admission controllers. ## Why do I need them? -Many advanced features in Kubernetes require an admission controller to be enabled in order +Several important features of Kubernetes require an admission controller to be enabled in order to properly support the feature. As a result, a Kubernetes API server that is not properly configured with the right set of admission controllers is an incomplete server and will not support all the features you expect. @@ -91,7 +99,7 @@ To see which admission plugins are enabled: kube-apiserver -h | grep enable-admission-plugins ``` -In the current version, the default ones are: +In Kubernetes {{< skew currentVersion >}}, the default ones are: ```shell CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, LimitRanger, MutatingAdmissionWebhook, NamespaceLifecycle, PersistentVolumeClaimResize, PodSecurity, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook @@ -103,18 +111,18 @@ CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultI {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} -This admission controller allows all pods into the cluster. It is deprecated because +This admission controller allows all pods into the cluster. It is **deprecated** because its behavior is the same as if there were no admission controller at all. ### AlwaysDeny {#alwaysdeny} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} -Rejects all requests. AlwaysDeny is DEPRECATED as it has no real meaning. +Rejects all requests. AlwaysDeny is **deprecated** as it has no real meaning. ### AlwaysPullImages {#alwayspullimages} -This admission controller modifies every new Pod to force the image pull policy to Always. This is useful in a +This admission controller modifies every new Pod to force the image pull policy to `Always`. This is useful in a multitenant cluster so that users can be assured that their private images can only be used by those who have the credentials to pull them. Without this admission controller, once an image has been pulled to a node, any pod from any user can use it by knowing the image's name (assuming the Pod is @@ -124,8 +132,8 @@ required. ### CertificateApproval {#certificateapproval} -This admission controller observes requests to 'approve' CertificateSigningRequest resources and performs additional -authorization checks to ensure the approving user has permission to `approve` certificate requests with the +This admission controller observes requests to approve CertificateSigningRequest resources and performs additional +authorization checks to ensure the approving user has permission to **approve** certificate requests with the `spec.signerName` requested on the CertificateSigningRequest resource. See [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/) for more @@ -134,7 +142,7 @@ information on the permissions required to perform different actions on Certific ### CertificateSigning {#certificatesigning} This admission controller observes updates to the `status.certificate` field of CertificateSigningRequest resources -and performs an additional authorization checks to ensure the signing user has permission to `sign` certificate +and performs an additional authorization checks to ensure the signing user has permission to **sign** certificate requests with the `spec.signerName` requested on the CertificateSigningRequest resource. See [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/) for more @@ -159,7 +167,7 @@ must revisit their `IngressClass` objects and mark only one as default (with the "ingressclass.kubernetes.io/is-default-class"). This admission controller ignores any `Ingress` updates; it acts only on creation. -See the [ingress](/docs/concepts/services-networking/ingress/) documentation for more about ingress +See the [Ingress](/docs/concepts/services-networking/ingress/) documentation for more about ingress classes and how to mark one as default. ### DefaultStorageClass {#defaultstorageclass} @@ -181,7 +189,7 @@ storage classes and how to mark a storage class as default. This admission controller sets the default forgiveness toleration for pods to tolerate the taints `notready:NoExecute` and `unreachable:NoExecute` based on the k8s-apiserver input parameters -`default-not-ready-toleration-seconds` and `default-unreachable-toleration-seconds` if the pods don't already +`default-not-ready-toleration-seconds` and `default-unreachable-toleration-seconds` if the pods don't already have toleration for taints `node.kubernetes.io/not-ready:NoExecute` or `node.kubernetes.io/unreachable:NoExecute`. The default value for `default-not-ready-toleration-seconds` and `default-unreachable-toleration-seconds` is 5 minutes. @@ -206,7 +214,7 @@ This admission controller is disabled by default. {{< feature-state for_k8s_version="v1.13" state="alpha" >}} This admission controller mitigates the problem where the API server gets flooded by -event requests. The cluster admin can specify event rate limits by: +requests to store new Events. The cluster admin can specify event rate limits by: * Enabling the `EventRateLimit` admission controller; * Referencing an `EventRateLimit` configuration file from the file provided to the API @@ -223,7 +231,7 @@ plugins: There are four types of limits that can be specified in the configuration: - * `Server`: All event requests received by the API server share a single bucket. + * `Server`: All Event requests (creation or modifications) received by the API server share a single bucket. * `Namespace`: Each namespace has a dedicated bucket. * `User`: Each user is allocated a bucket. * `SourceAndObject`: A bucket is assigned by each combination of source and @@ -266,7 +274,7 @@ The ImagePolicyWebhook admission controller allows a backend webhook to make adm This admission controller is disabled by default. -#### Configuration File Format +#### Configuration file format {#imagereview-config-file-format} ImagePolicyWebhook uses a configuration file to set options for the behavior of the backend. This file may be json or yaml and has the following format: @@ -377,8 +385,8 @@ An example request body: } ``` -The remote service is expected to fill the `ImageReviewStatus` field of the request and -respond to either allow or disallow access. The response body's `spec` field is ignored and +The remote service is expected to fill the `status` field of the request and +respond to either allow or disallow access. The response body's `spec` field is ignored, and may be omitted. A permissive response would return: ```json @@ -529,9 +537,9 @@ permissions required to operate correctly. ### OwnerReferencesPermissionEnforcement {#ownerreferencespermissionenforcement} This admission controller protects the access to the `metadata.ownerReferences` of an object -so that only users with "delete" permission to the object can change it. +so that only users with **delete** permission to the object can change it. This admission controller also protects the access to `metadata.ownerReferences[x].blockOwnerDeletion` -of an object, so that only users with "update" permission to the `finalizers` +of an object, so that only users with **update** permission to the `finalizers` subresource of the referenced *owner* can change it. ### PersistentVolumeClaimResize {#persistentvolumeclaimresize} @@ -568,12 +576,12 @@ For more information about persistent volume claims, see [PersistentVolumeClaims {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} This admission controller automatically attaches region or zone labels to PersistentVolumes -as defined by the cloud provider (for example, GCE or AWS). +as defined by the cloud provider (for example, Azure or GCP). It helps ensure the Pods and the PersistentVolumes mounted are in the same region and/or zone. If the admission controller doesn't support automatic labelling your PersistentVolumes, you may need to add the labels manually to prevent pods from mounting volumes from -a different zone. PersistentVolumeLabel is DEPRECATED and labeling persistent volumes has been taken over by +a different zone. PersistentVolumeLabel is **deprecated** as labeling for persistent volumes has been taken over by the {{< glossary_tooltip text="cloud-controller-manager" term_id="cloud-controller-manager" >}}. This admission controller is disabled by default. @@ -745,7 +753,8 @@ pod privileges. This admission controller implements automation for [serviceAccounts](/docs/tasks/configure-pod-container/configure-service-account/). -We strongly recommend using this admission controller if you intend to make use of Kubernetes +The Kubernetes project strongly recommends enabling this admission controller. +You should enable this admission controller if you intend to make any use of Kubernetes `ServiceAccount` objects. ### StorageObjectInUseProtection diff --git a/content/en/docs/reference/command-line-tools-reference/_index.md b/content/en/docs/reference/command-line-tools-reference/_index.md index 8f9cf74a0ee9b..91ebb11b7a577 100644 --- a/content/en/docs/reference/command-line-tools-reference/_index.md +++ b/content/en/docs/reference/command-line-tools-reference/_index.md @@ -1,4 +1,4 @@ --- title: Component tools -weight: 60 +weight: 120 --- diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet.md b/content/en/docs/reference/command-line-tools-reference/kubelet.md index 134ed94b41463..0e25863216e42 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet.md @@ -1,7 +1,7 @@ --- title: kubelet content_type: tool-reference -weight: 28 +weight: 20 --- ## {{% heading "synopsis" %}} @@ -16,7 +16,7 @@ through various mechanisms (primarily through the apiserver) and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn't manage containers which were not created by Kubernetes. -Other than from a PodSpec from the apiserver, there are three ways that a +Other than from a PodSpec from the apiserver, there are two ways that a container manifest can be provided to the Kubelet. - File: Path passed as a flag on the command line. Files under this path will be @@ -24,8 +24,6 @@ container manifest can be provided to the Kubelet. and is configurable via a flag. - HTTP endpoint: HTTP endpoint passed as a parameter on the command line. This endpoint is checked every 20 seconds (also configurable with a flag). -- HTTP server: The kubelet can also listen for HTTP and respond to a simple API - (underspec'd currently) to submit a new manifest. ``` kubelet [flags] diff --git a/content/en/docs/reference/config-api/_index.md b/content/en/docs/reference/config-api/_index.md index a053b77d60235..9c05466727aee 100644 --- a/content/en/docs/reference/config-api/_index.md +++ b/content/en/docs/reference/config-api/_index.md @@ -1,5 +1,5 @@ --- title: Configuration APIs -weight: 65 +weight: 130 --- diff --git a/content/en/docs/reference/instrumentation/_index.md b/content/en/docs/reference/instrumentation/_index.md index dfde3627c770b..4b6a2bc9eccf1 100644 --- a/content/en/docs/reference/instrumentation/_index.md +++ b/content/en/docs/reference/instrumentation/_index.md @@ -1,4 +1,4 @@ --- title: Instrumentation -weight: 40 +weight: 60 --- \ No newline at end of file diff --git a/content/en/docs/reference/issues-security/_index.md b/content/en/docs/reference/issues-security/_index.md index 50c3f29333462..87e69909b217b 100644 --- a/content/en/docs/reference/issues-security/_index.md +++ b/content/en/docs/reference/issues-security/_index.md @@ -1,4 +1,4 @@ --- title: Kubernetes Issues and Security -weight: 40 +weight: 70 --- \ No newline at end of file diff --git a/content/en/docs/reference/kubectl/_index.md b/content/en/docs/reference/kubectl/_index.md index 8780e64834e68..781cd22f11f33 100644 --- a/content/en/docs/reference/kubectl/_index.md +++ b/content/en/docs/reference/kubectl/_index.md @@ -1,7 +1,7 @@ --- title: Command line tool (kubectl) content_type: reference -weight: 60 +weight: 110 no_list: true card: name: reference diff --git a/content/en/docs/reference/kubectl/conventions.md b/content/en/docs/reference/kubectl/conventions.md index 00a842f058c75..2b2cb34ceca72 100644 --- a/content/en/docs/reference/kubectl/conventions.md +++ b/content/en/docs/reference/kubectl/conventions.md @@ -3,6 +3,7 @@ title: kubectl Usage Conventions reviewers: - janetkuo content_type: concept +weight: 60 --- diff --git a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md index 95e2e79c77847..d5a98a851aca9 100644 --- a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md +++ b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md @@ -4,6 +4,7 @@ content_type: concept reviewers: - brendandburns - thockin +weight: 50 --- diff --git a/content/en/docs/reference/kubectl/jsonpath.md b/content/en/docs/reference/kubectl/jsonpath.md index 36e29e63500f5..f1aa5f8ec4946 100644 --- a/content/en/docs/reference/kubectl/jsonpath.md +++ b/content/en/docs/reference/kubectl/jsonpath.md @@ -1,6 +1,7 @@ --- title: JSONPath Support content_type: concept +weight: 40 --- diff --git a/content/en/docs/reference/kubernetes-api/_index.md b/content/en/docs/reference/kubernetes-api/_index.md index 85c5e0e672d7d..3fd611b1cfa6e 100644 --- a/content/en/docs/reference/kubernetes-api/_index.md +++ b/content/en/docs/reference/kubernetes-api/_index.md @@ -1,6 +1,6 @@ --- title: "Kubernetes API" -weight: 30 +weight: 50 --- diff --git a/content/en/docs/reference/labels-annotations-taints/_index.md b/content/en/docs/reference/labels-annotations-taints/_index.md index 5561874ce7658..93a3ce6e9fb26 100644 --- a/content/en/docs/reference/labels-annotations-taints/_index.md +++ b/content/en/docs/reference/labels-annotations-taints/_index.md @@ -1,7 +1,7 @@ --- title: Well-Known Labels, Annotations and Taints content_type: concept -weight: 20 +weight: 40 no_list: true --- diff --git a/content/en/docs/reference/labels-annotations-taints/audit-annotations.md b/content/en/docs/reference/labels-annotations-taints/audit-annotations.md index 4a3d726ce5be4..f950c6457e2f9 100644 --- a/content/en/docs/reference/labels-annotations-taints/audit-annotations.md +++ b/content/en/docs/reference/labels-annotations-taints/audit-annotations.md @@ -1,6 +1,6 @@ --- title: "Audit Annotations" -weight: 1 +weight: 10 --- diff --git a/content/en/docs/reference/node/_index.md b/content/en/docs/reference/node/_index.md index 6ffb64838185d..d3004a3849c85 100644 --- a/content/en/docs/reference/node/_index.md +++ b/content/en/docs/reference/node/_index.md @@ -1,4 +1,4 @@ --- title: Node Reference Information -weight: 40 +weight: 80 --- diff --git a/content/en/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md b/content/en/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md index 53a625ba596ba..8d2e26c1e981e 100644 --- a/content/en/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md +++ b/content/en/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md @@ -1,6 +1,7 @@ --- title: Articles on dockershim Removal and on Using CRI-compatible Runtimes content_type: reference +weight: 20 --- This is a list of articles and other pages that are either diff --git a/content/en/docs/reference/ports-and-protocols.md b/content/en/docs/reference/ports-and-protocols.md index 8ca5bc0774444..cdba8383c7b4f 100644 --- a/content/en/docs/reference/ports-and-protocols.md +++ b/content/en/docs/reference/ports-and-protocols.md @@ -1,7 +1,7 @@ --- title: Ports and Protocols content_type: reference -weight: 50 +weight: 90 --- When running Kubernetes in an environment with strict network boundaries, such diff --git a/content/en/docs/reference/scheduling/_index.md b/content/en/docs/reference/scheduling/_index.md index 316b774081953..6a44b52845201 100644 --- a/content/en/docs/reference/scheduling/_index.md +++ b/content/en/docs/reference/scheduling/_index.md @@ -1,5 +1,5 @@ --- title: Scheduling -weight: 70 +weight: 140 toc-hide: true --- diff --git a/content/en/docs/reference/scheduling/policies.md b/content/en/docs/reference/scheduling/policies.md index d64d5f1bf58df..a28bd3115297d 100644 --- a/content/en/docs/reference/scheduling/policies.md +++ b/content/en/docs/reference/scheduling/policies.md @@ -3,6 +3,7 @@ title: Scheduling Policies content_type: concept sitemap: priority: 0.2 # Scheduling priorities are deprecated +weight: 30 --- diff --git a/content/en/docs/reference/setup-tools/_index.md b/content/en/docs/reference/setup-tools/_index.md index c97758fe6ea81..2d173f3a64e79 100644 --- a/content/en/docs/reference/setup-tools/_index.md +++ b/content/en/docs/reference/setup-tools/_index.md @@ -1,4 +1,4 @@ --- title: Setup tools -weight: 50 +weight: 100 --- diff --git a/content/en/docs/reference/tools/_index.md b/content/en/docs/reference/tools/_index.md index 2ec317bd1f3a7..b6e3be860465a 100644 --- a/content/en/docs/reference/tools/_index.md +++ b/content/en/docs/reference/tools/_index.md @@ -3,7 +3,7 @@ title: Other Tools reviewers: - janetkuo content_type: concept -weight: 80 +weight: 150 no_list: true --- diff --git a/content/en/docs/reference/tools/map-crictl-dockercli.md b/content/en/docs/reference/tools/map-crictl-dockercli.md index 7fc021451c406..04edd665c0ef5 100644 --- a/content/en/docs/reference/tools/map-crictl-dockercli.md +++ b/content/en/docs/reference/tools/map-crictl-dockercli.md @@ -1,6 +1,7 @@ --- title: Mapping from dockercli to crictl content_type: reference +weight: 10 --- {{% thirdparty-content %}} diff --git a/content/en/docs/reference/using-api/_index.md b/content/en/docs/reference/using-api/_index.md index 5f0e21871bdde..cebf28fbac170 100644 --- a/content/en/docs/reference/using-api/_index.md +++ b/content/en/docs/reference/using-api/_index.md @@ -5,7 +5,7 @@ reviewers: - lavalamp - jbeda content_type: concept -weight: 10 +weight: 20 no_list: true card: name: reference diff --git a/content/en/docs/tasks/extend-kubernetes/setup-konnectivity.md b/content/en/docs/tasks/extend-kubernetes/setup-konnectivity.md index 6f5e1d18830bb..5402a4048a45e 100644 --- a/content/en/docs/tasks/extend-kubernetes/setup-konnectivity.md +++ b/content/en/docs/tasks/extend-kubernetes/setup-konnectivity.md @@ -54,7 +54,7 @@ For example, you can use the OpenSSL command line tool to issue a X.509 certific using the cluster CA certificate `/etc/kubernetes/pki/ca.crt` from a control-plane host. ```bash -openssl req -subj "/CN=system:konnectivity-server" -new -newkey rsa:2048 -nodes -out konnectivity.csr -keyout konnectivity.key -out konnectivity.csr +openssl req -subj "/CN=system:konnectivity-server" -new -newkey rsa:2048 -nodes -out konnectivity.csr -keyout konnectivity.key openssl x509 -req -in konnectivity.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out konnectivity.crt -days 375 -sha256 SERVER=$(kubectl config view -o jsonpath='{.clusters..server}') kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-credentials system:konnectivity-server --client-certificate konnectivity.crt --client-key konnectivity.key --embed-certs=true diff --git a/content/en/docs/tutorials/stateful-application/basic-stateful-set.md b/content/en/docs/tutorials/stateful-application/basic-stateful-set.md index e20ac7e708aa0..024fdacdbfd8a 100644 --- a/content/en/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/en/docs/tutorials/stateful-application/basic-stateful-set.md @@ -1202,12 +1202,54 @@ Service: kubectl delete svc nginx ``` +Delete the persistent storage media for the PersistentVolumes used in this tutorial. +```shell +kubectl get pvc +``` +``` +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE +www-web-0 Bound pvc-2bf00408-d366-4a12-bad0-1869c65d0bee 1Gi RWO standard 25m +www-web-1 Bound pvc-ba3bfe9c-413e-4b95-a2c0-3ea8a54dbab4 1Gi RWO standard 24m +www-web-2 Bound pvc-cba6cfa6-3a47-486b-a138-db5930207eaf 1Gi RWO standard 15m +www-web-3 Bound pvc-0c04d7f0-787a-4977-8da3-d9d3a6d8d752 1Gi RWO standard 15m +www-web-4 Bound pvc-b2c73489-e70b-4a4e-9ec1-9eab439aa43e 1Gi RWO standard 14m +``` + +```shell +kubectl get pv +``` +``` +NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE +pvc-0c04d7f0-787a-4977-8da3-d9d3a6d8d752 1Gi RWO Delete Bound default/www-web-3 standard 15m +pvc-2bf00408-d366-4a12-bad0-1869c65d0bee 1Gi RWO Delete Bound default/www-web-0 standard 25m +pvc-b2c73489-e70b-4a4e-9ec1-9eab439aa43e 1Gi RWO Delete Bound default/www-web-4 standard 14m +pvc-ba3bfe9c-413e-4b95-a2c0-3ea8a54dbab4 1Gi RWO Delete Bound default/www-web-1 standard 24m +pvc-cba6cfa6-3a47-486b-a138-db5930207eaf 1Gi RWO Delete Bound default/www-web-2 standard 15m +``` + +```shell +kubectl delete pvc www-web-0 www-web-1 www-web-2 www-web-3 www-web-4 +``` + +``` +persistentvolumeclaim "www-web-0" deleted +persistentvolumeclaim "www-web-1" deleted +persistentvolumeclaim "www-web-2" deleted +persistentvolumeclaim "www-web-3" deleted +persistentvolumeclaim "www-web-4" deleted +``` + +```shell +kubectl get pvc +``` + +``` +No resources found in default namespace. +``` {{< note >}} You also need to delete the persistent storage media for the PersistentVolumes used in this tutorial. - - Follow the necessary steps, based on your environment, storage configuration, and provisioning method, to ensure that all storage is reclaimed. -{{< /note >}} +{{< /note >}} \ No newline at end of file diff --git a/content/hi/docs/setup/production-environment/_index.md b/content/hi/docs/setup/production-environment/_index.md index af04f81a67e1d..cf1f2f753f4f3 100644 --- a/content/hi/docs/setup/production-environment/_index.md +++ b/content/hi/docs/setup/production-environment/_index.md @@ -58,7 +58,7 @@ no_list: true - *एपिसर्वर के लिए लोड बैलेंसर कॉन्फ़िगर करें*: विभिन्न नोड्स पर चल रहे एपिसर्वर सर्विस इंस्टेंस के लिए बाहरी एपीआई अनुरोधों को वितरित करने के लिए लोड बैलेंसर को कॉन्फ़िगर करें। विवरण के लिए [एक बाहरी लोड बैलेंसर बनाना](/docs/tasks/access-application-cluster/create-external-load-balancer/) देखें। - *अलग और बैकअप etcd सेवा*: अतिरिक्त सुरक्षा और उपलब्धता के लिए etcd सेवाएं या तो अन्य कंट्रोल प्लेन सेवाओं के समान मशीनों पर चल सकती हैं या अलग मशीनों पर चल सकती हैं। क्योंकि etcd क्लस्टर कॉन्फ़िगरेशन डेटा संग्रहीत करता है, etcd डेटाबेस का बैकअप नियमित रूप से किया जाना चाहिए ताकि यह सुनिश्चित हो सके कि यदि आवश्यक हो तो आप उस डेटाबेस की मरम्मत कर सकते हैं। -etcd को कॉन्फ़िगर करने और उपयोग करने के विवरण के लिए [etcd अक्सर पूछे जाने वाले प्रश्न](https://etcd.io/docs/v3.4/faq/) देखें। +etcd को कॉन्फ़िगर करने और उपयोग करने के विवरण के लिए [etcd अक्सर पूछे जाने वाले प्रश्न](https://etcd.io/docs/v3.5/faq/) देखें। विवरण के लिए [कुबेरनेट्स के लिए ऑपरेटिंग etcd क्लस्टर](/docs/tasks/administer-cluster/configure-upgrade-etcd/) और [kubeadm के साथ एक उच्च उपलब्धता etcd क्लस्टर स्थापित करें](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) देखें। - *मल्टीपल कण्ट्रोल प्लेन सिस्टम बनाएं*: उच्च उपलब्धता के लिए, कण्ट्रोल प्लेन एक मशीन तक सीमित नहीं होना चाहिए। यदि कण्ट्रोल प्लेन सेवाएं एक init सेवा (जैसे systemd) द्वारा चलाई जाती हैं, तो प्रत्येक सेवा को कम से कम तीन मशीनों पर चलना चाहिए। हालाँकि, कुबेरनेट्स में पॉड्स के रूप में कण्ट्रोल प्लेन सेवाएं चलाना सुनिश्चित करता है कि आपके द्वारा अनुरोधित सेवाओं की प्रतिकृति संख्या हमेशा उपलब्ध रहेगी। अनुसूचक फॉल्ट सहने वाला होना चाहिए, लेकिन अत्यधिक उपलब्ध नहीं होना चाहिए। कुबेरनेट्स सेवाओं के नेता चुनाव करने के लिए कुछ डिप्लॉयमेंट उपकरण [राफ्ट](https://raft.github.io/) सर्वसम्मति एल्गोरिथ्म की स्थापना करते हैं। यदि प्राथमिक चला जाता है, तो दूसरी सेवा स्वयं को चुनती है और कार्यभार संभालती है। diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index f442096833019..07cbdfa4a6443 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -199,7 +199,7 @@ baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64 enabled=1 gpgcheck=1 repo_gpgcheck=1 -gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg +gpgkey=https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOF # SELinuxをpermissiveモードに設定する(効果的に無効化する) diff --git a/content/ja/docs/tasks/tools/install-kubectl.md b/content/ja/docs/tasks/tools/install-kubectl.md index 688c996b1b408..8a904b78d837d 100644 --- a/content/ja/docs/tasks/tools/install-kubectl.md +++ b/content/ja/docs/tasks/tools/install-kubectl.md @@ -72,7 +72,7 @@ baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64 enabled=1 gpgcheck=1 repo_gpgcheck=1 -gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg +gpgkey=https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOF yum install -y kubectl {{< /tab >}} diff --git a/content/ja/docs/tutorials/clusters/apparmor.md b/content/ja/docs/tutorials/clusters/apparmor.md index 69a3063c6ad84..be40308acb606 100644 --- a/content/ja/docs/tutorials/clusters/apparmor.md +++ b/content/ja/docs/tutorials/clusters/apparmor.md @@ -111,7 +111,7 @@ kubectl get events | grep Created proc attrを調べることで、コンテナのルートプロセスが正しいプロファイルで実行されているかどうかを直接確認することもできます。 ```shell -kubectl exec cat /proc/1/attr/current +kubectl exec -- cat /proc/1/attr/current ``` ``` k8s-apparmor-example-deny-write (enforce) diff --git a/content/pt-br/docs/concepts/security/controlling-access.md b/content/pt-br/docs/concepts/security/controlling-access.md new file mode 100644 index 0000000000000..f17b43d2a3c76 --- /dev/null +++ b/content/pt-br/docs/concepts/security/controlling-access.md @@ -0,0 +1,184 @@ +--- +title: Controlando Acesso à API do Kubernetes +content_type: concept +--- + + +Esta página fornece uma visão geral do controle de acesso à API do Kubernetes. + + +Usuários podem acessar a [API do Kubernetes](/docs/concepts/overview/kubernetes-api/) utilizando `kubectl`, +bibliotecas, ou executando requisições REST. Ambos, usuários humanos e +[Contas de serviço do Kubernetes](/docs/tasks/configure-pod-container/configure-service-account/) podem ser autorizados +a acessar à API. +Quando uma requisição chega à API, ela passa por diversos estágios, +ilustrados no seguinte diagrama: + +![Diagrama de etapas de tratamento de requisições enviadas a API do Kubernetes](/images/docs/admin/access-control-overview.svg) + +## Segurança na camada de transporte + +Em um cluster Kubernetes típico, a API fica disponível na porta 443, protegida por segurança na camada de transporte (TLS). +O servidor de API apresenta um certificado. Este certificado pode ser assinado utilizando +uma autoridade privada de certificados (CA), ou baseado em uma infraestrutura de chave pública ligada +a uma autoridade de certificados reconhecida publicamente. + +Se o seu cluster utiliza uma autoridade privada de certificados, voce precisa de uma cópia do certificado +da autoridade de certificados (CA) dentro do arquivo de configuração `~/.kube/config`, no lado do cliente, para que +voce possa confiar na conexão e tenha a garantia de que não há interceptação de tráfego. + +O seu cliente pode apresentar o certificado de cliente TLS neste estágio. + +## Autenticação + +Uma vez em que a segurança na camada de transporte (TLS) é estabelecida, a requisição HTTP move para o passo de autenticação. +Isto é demonstrado no passo **1** no diagrama acima. +O script de criação do cluster ou configurações de administração configuram o servidor de API para executar +um ou mais módulos autenticadores. + +Autenticadores são descritos em maiores detalhes em +[Autenticação](/pt-br/docs/reference/access-authn-authz/authentication/). + +A entrada para o passo de autenticação é a requisição HTTP completa; no entanto, tipicamente +são verificados os cabeçalhos e/ou o certificado de cliente. + +Módulos de autenticação incluem certificados de cliente, senhas, tokens simples, +tokens de auto-inicialização e JSON Web Tokens (utilizados para contas de serviço). + +Vários módulos de autenticação podem ser especificados, em que cada um será verificado em sequência, +até que um deles tenha sucesso. + +Se a requisição não pode ser autenticada, será rejeitada com o código de status HTTP 401 (não autorizado). +Caso contrário, o usuário é autenticado com um "nome de usuário" específico e o nome de usuário +está disponível para as etapas subsequentes para usar em suas decisões. Alguns autenticadores +também fornecem as associações de grupo do usuário, enquanto outros autenticadores +não o fazem. + +Enquanto o Kubernetes usa nomes de usuário para decisões de controle de acesso e no registro de requisições, +ele não possui um objeto `user` nem armazena nomes de usuários ou outras informações sobre +usuários em sua API. + +## Autorização + +Após a requisição ser autenticada como originada de um usuário específico, a requisição deve ser autorizada. Isso é mostrado no passo **2** no diagrama. + +Uma requisição deve incluir o nome do usuário requerente, a ação requisitada e o objeto afetado pela ação. A requisição é autorizada se uma +política existente declarar que o usuário tem as devidas permissões para concluir a ação requisitada. + +Por exemplo, se Bob possui a política abaixo, então ele somente poderá ler pods no namespace `projectCaribou`: + +```json +{ + "apiVersion": "abac.authorization.kubernetes.io/v1beta1", + "kind": "Policy", + "spec": { + "user": "bob", + "namespace": "projectCaribou", + "resource": "pods", + "readonly": true + } +} +``` +Se Bob fizer a seguinte requisição, a requisição será autorizada porque ele tem permissão para ler objetos no namespace `projectCaribou`: +```json +{ + "apiVersion": "authorization.k8s.io/v1beta1", + "kind": "SubjectAccessReview", + "spec": { + "resourceAttributes": { + "namespace": "projectCaribou", + "verb": "get", + "group": "unicorn.example.org", + "resource": "pods" + } + } +} +``` +Se Bob fizer uma requisição para escrever (`create` ou `update`) em objetos no namespace `projectCaribou`, sua autorização será negada. Se Bob fizer uma requisição para ler (`get`) objetos em um namespace diferente, como `projectFish`, sua autorização será negada. + +A autorização do Kubernetes requer que você use atributos comuns a REST para interagir com os sistemas de controle de acesso existentes em toda uma organização ou em todo o provedor de nuvem utilizado. É importante usar a formatação REST porque esses sistemas de controle podem interagir com outras APIs além da API do Kubernetes. + +O Kubernetes oferece suporte a vários módulos de autorização, como o modo de controle de acesso baseado em atributos (ABAC), o modo de controle de acesso baseado em função (RBAC) e o modo Webhook. Quando um administrador cria um cluster, ele configura os módulos de autorização que devem ser utilizados no servidor de API. Se mais de um módulo de autorização for configurado, o Kubernetes verificará cada módulo e, se algum módulo autorizar a requisição, a requisição poderá prosseguir. Se todos os módulos negarem a requisição, a requisição será negada (com código de status HTTP 403 - Acesso Proibido). + +Para saber mais sobre a autorização do Kubernetes, incluindo detalhes sobre como criar políticas usando os módulos de autorização compatíveis, consulte [Visão Geral de Autorização](/pt-br/docs/reference/access-authn-authz/authorization/). + +## Controle de admissão + +Os módulos de controle de admissão são módulos de software que podem modificar ou rejeitar requisições. +Além dos atributos disponíveis para os módulos de Autorização, os módulos do controlador de admissão +podem acessar o conteúdo do objeto que está sendo criado ou modificado. + +Os controladores de admissão atuam em requisições que criam, modificam, excluem ou age como um proxy para outro objeto. +Os controladores de admissão não agem em requisições que apenas leem objetos. +Quando vários controladores de admissão são configurados, eles são chamados em ordem. + +Isso é mostrado como etapa **3** no diagrama. + +Ao contrário dos módulos de autenticação e autorização, se algum módulo controlador de admissão +rejeita, a solicitação é imediatamente rejeitada. + +Além de rejeitar objetos, os controladores de admissão também podem definir valores padrão complexos para +campos. + +Os módulos de Controle de Admissão disponíveis são descritos em [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/). + +Após uma requisição passar por todos os controladores de admissão, ela é validada usando as rotinas de validação +para o objeto de API correspondente e, em seguida, gravados no armazenamento de objetos (mostrado como etapa **4** no diagrama). + +## Auditoria + +A auditoria do Kubernetes fornece um conjunto de registros cronológicos relevantes para a segurança que documentam a sequência de ações em um cluster. +O cluster audita as atividades geradas pelos usuários, pelos aplicativos que usam a API do Kubernetes e pela própria camada de gerenciamento. + +Para mais informações, consulte [Auditing](/docs/tasks/debug/debug-cluster/audit/). + +## Portas e IPs do servidor de API + +A discussão anterior se aplica a requisições enviadas para a porta segura do servidor de API +(o caso típico). O servidor de API pode realmente servir em 2 portas. + +Por padrão, o servidor da API Kubernetes atende HTTP em 2 portas: + + 1. Porta `localhost`: + + - destina-se a testes e auto-inicialização e a outros componentes do nó mestre + (scheduler, controller-manager) para falar com a API + - sem segurança na camada de transporte (TLS) + - o padrão é a porta 8080 + - IP padrão é localhost, mude com a flag `--insecure-bind-address`. + - a requisição **ignora** os módulos de autenticação e autorização . + - requisição tratada pelo(s) módulo(s) de controle de admissão. + - protegido pela necessidade de ter acesso ao host + + 2. “Porta segura”: + + - utilize sempre que possível + - utiliza segurança na camada de transporte (TLS). Defina o certificado com `--tls-cert-file` e a chave com a flag `--tls-private-key-file`. + - o padrão é a porta 6443, mude com a flag `--secure-port`. + - IP padrão é a primeira interface de rede não localhost, mude com a flag `--bind-address`. + - requisição tratada pelos módulos de autenticação e autorização. + - requisição tratada pelo(s) módulo(s) de controle de admissão. + - módulos de autenticação e autorização executados. + +## {{% heading "whatsnext" %}} + +Consulte mais documentação sobre autenticação, autorização e controle de acesso à API: + +- [Autenticação](/pt-br/docs/reference/access-authn-authz/authentication/) + - [Autenticando com Tokens de Inicialização](/pt-br/docs/reference/access-authn-authz/bootstrap-tokens/) +- [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) + - [Dynamic Admission Control](/docs/reference/access-authn-authz/extensible-admission-controllers/) +- [Autorização](/pt-br/docs/reference/access-authn-authz/authorization/) + - [Using RBAC Authorization](/docs/reference/access-authn-authz/rbac/) + - [Using ABAC Authorization](/docs/reference/access-authn-authz/abac/) + - [Using Node Authorization](/docs/reference/access-authn-authz/node/) + - [Webhook Mode](/docs/reference/access-authn-authz/webhook/) +- [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/) + - incluindo [Approval or rejection of Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) + e [Signing certificates](/docs/reference/access-authn-authz/certificate-signing-requests/#signing) +- Contas de serviço + - [Configure Service Accounts for Pods](/docs/tasks/configure-pod-container/configure-service-account/) + - [Managing Service Accounts](/docs/reference/access-authn-authz/service-accounts-admin/) + +Você pode aprender mais sobre: +- como os pods podem usar [Secrets](/docs/concepts/configuration/secret/) para obter credenciais de API. diff --git a/content/pt-br/docs/reference/glossary/cloud-provider.md b/content/pt-br/docs/reference/glossary/cloud-provider.md new file mode 100644 index 0000000000000..54e5cf6fa9343 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/cloud-provider.md @@ -0,0 +1,30 @@ +--- +title: Provedor de Nuvem +id: cloud-provider +date: 2018-04-12 +short_description: > + Uma organização que oferece uma plataforma de computação em nuvem. + +aka: +- Provedor de Serviços em Nuvem +tags: +- community +--- + Uma empresa ou outra organização que oferece uma plataforma de computação em nuvem. + + + +Os provedores de nuvem, às vezes chamados de Provedores de Serviços em Nuvem (CSPs), +oferecem plataformas ou serviços de computação em nuvem. + +Muitos provedores de nuvem oferecem infraestrutura gerenciada +(também chamada de Infraestrutura como Serviço ou IaaS). +Com a infraestrutura gerenciada, o provedor de nuvem é responsável pelos servidores, +armazenamento e rede enquanto você gerencia as camadas em cima disso, +tal como a execução de um cluster Kubernetes. + +Você também pode encontrar o Kubernetes como um serviço gerenciado; +às vezes chamado de Plataforma como Serviço ou PaaS. +Com o Kubernetes gerenciado, o seu provedor de nuvem é responsável pela camada de gerenciamento do Kubernetes, +bem como pelos {{< glossary_tooltip term_id="node" text="nós" >}} e pela infraestrutura em que eles dependem: +rede, armazenamento e provavelmente outros elementos, tal como balanceadores de carga. diff --git a/content/pt-br/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/pt-br/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 85c0bff925380..8cb17675259a4 100644 --- a/content/pt-br/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/pt-br/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -166,7 +166,7 @@ baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch enabled=1 gpgcheck=1 repo_gpgcheck=1 -gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg +gpgkey=https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg exclude=kubelet kubeadm kubectl EOF diff --git a/content/ru/docs/concepts/cluster-administration/certificates.md b/content/ru/docs/concepts/cluster-administration/certificates.md new file mode 100644 index 0000000000000..6d9012a5867d6 --- /dev/null +++ b/content/ru/docs/concepts/cluster-administration/certificates.md @@ -0,0 +1,9 @@ +--- +title: Сертификаты +content_type: concept +weight: 20 +--- + + + +Чтобы узнать, как генерировать сертификаты для кластера, см. раздел [Сертификаты](/docs/tasks/administer-cluster/certificates/). diff --git a/content/ru/docs/tasks/administer-cluster/certificates.md b/content/ru/docs/tasks/administer-cluster/certificates.md new file mode 100644 index 0000000000000..11cc06610b073 --- /dev/null +++ b/content/ru/docs/tasks/administer-cluster/certificates.md @@ -0,0 +1,280 @@ +--- +title: Генерация сертификатов вручную +content_type: task +weight: 20 +--- + + + +При аутентификации с помощью клиентского сертификата сертификаты можно генерировать вручную с помощью `easyrsa`, `openssl` или `cfssl`. + + + +### easyrsa + +**easyrsa** поддерживает ручную генерацию сертификатов для кластера. + +1. Скачайте, распакуйте и инициализируйте пропатченную версию `easyrsa3`. + + ```shell + curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz + tar xzf easy-rsa.tar.gz + cd easy-rsa-master/easyrsa3 + ./easyrsa init-pki + ``` +1. Создайте новый центр сертификации (certificate authority, CA). `--batch` задает автоматический режим; + `--req-cn` указывает общее имя (Common Name, CN) для нового корневого сертификата CA. + + ```shell + ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass + ``` + +1. Сгенерируйте сертификат и ключ сервера. + + Аргумент `--subject-alt-name` задает допустимые IP-адреса и DNS-имена, с которых будет осуществляться доступ к серверу API. `MASTER_CLUSTER_IP` обычно является первым IP из CIDR сервиса, который указан в качестве аргумента `--service-cluster-ip-range` как для сервера API, так и для менеджера контроллеров. Аргумент `--days` задает количество дней, через которое истекает срок действия сертификата. В приведенном ниже примере предполагается, что `cluster.local` используется в качестве доменного имени по умолчанию. + + ```shell + ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ + "IP:${MASTER_CLUSTER_IP},"\ + "DNS:kubernetes,"\ + "DNS:kubernetes.default,"\ + "DNS:kubernetes.default.svc,"\ + "DNS:kubernetes.default.svc.cluster,"\ + "DNS:kubernetes.default.svc.cluster.local" \ + --days=10000 \ + build-server-full server nopass + ``` + +1. Скопируйте `pki/ca.crt`, `pki/issued/server.crt` и `pki/private/server.key` в свою директорию. + +1. Заполните и добавьте следующие параметры в параметры запуска сервера API: + + ```shell + --client-ca-file=/yourdirectory/ca.crt + --tls-cert-file=/yourdirectory/server.crt + --tls-private-key-file=/yourdirectory/server.key + ``` + +### openssl + +**openssl** поддерживает ручную генерацию сертификатов для кластера. + +1. Сгенерируйте 2048-разрядный ключ ca.key: + + ```shell + openssl genrsa -out ca.key 2048 + ``` + +1. На основе ca.key сгенерируйте ca.crt (используйте `-days` для установки времени действия сертификата): + + ```shell + openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt + ``` + +1. Сгенерируйте 2048-битный ключ server.key: + + ```shell + openssl genrsa -out server.key 2048 + ``` + +1. Создайте файл конфигурации для генерации запроса на подписание сертификата (Certificate Signing Request, CSR). + + Замените значения, помеченные угловыми скобками (например, ``), нужными значениями перед сохранением в файл (например, `csr.conf`). Обратите внимание, что значение для `MASTER_CLUSTER_IP` – это cluster IP сервиса для сервера API, как описано в предыдущем подразделе. В приведенном ниже примере предполагается, что `cluster.local` используется в качестве доменного имени по умолчанию. + + ```ini + [ req ] + default_bits = 2048 + prompt = no + default_md = sha256 + req_extensions = req_ext + distinguished_name = dn + + [ dn ] + C = + ST = + L = + O = + OU = + CN = + + [ req_ext ] + subjectAltName = @alt_names + + [ alt_names ] + DNS.1 = kubernetes + DNS.2 = kubernetes.default + DNS.3 = kubernetes.default.svc + DNS.4 = kubernetes.default.svc.cluster + DNS.5 = kubernetes.default.svc.cluster.local + IP.1 = + IP.2 = + + [ v3_ext ] + authorityKeyIdentifier=keyid,issuer:always + basicConstraints=CA:FALSE + keyUsage=keyEncipherment,dataEncipherment + extendedKeyUsage=serverAuth,clientAuth + subjectAltName=@alt_names + ``` + +1. Сгенерируйте запрос на подписание сертификата, используя файл конфигурации: + + ```shell + openssl req -new -key server.key -out server.csr -config csr.conf + ``` + +1. С помощью ca.key, ca.crt и server.csr сгенерируйте сертификат сервера: + + ```shell + openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ + -CAcreateserial -out server.crt -days 10000 \ + -extensions v3_ext -extfile csr.conf + ``` + +1. Используйте следующую команду, чтобы просмотреть запрос на подписание сертификата: + + ```shell + openssl req -noout -text -in ./server.csr + ``` + +1. Используйте следующую команду, чтобы просмотреть сертификат: + + ```shell + openssl x509 -noout -text -in ./server.crt + ``` + +Наконец, добавьте эти параметры в конфигурацию запуска сервера API. + +### cfssl + +**cfssl** – еще один инструмент для генерации сертификатов. + +1. Скачайте, распакуйте и подготовьте пакеты, как показано ниже. + + Обратите внимание, что команды необходимо адаптировать под архитектуру и используемую версию cfssl. + + ```shell + curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl + chmod +x cfssl + curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson + chmod +x cfssljson + curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo + chmod +x cfssl-certinfo + ``` + +1. Создайте директорию для хранения артефактов и инициализируйте cfssl: + + ```shell + mkdir cert + cd cert + ../cfssl print-defaults config > config.json + ../cfssl print-defaults csr > csr.json + ``` + +1. Создайте JSON-конфиг для генерации файла CA (например, `ca-config.json`): + + ```json + { + "signing": { + "default": { + "expiry": "8760h" + }, + "profiles": { + "kubernetes": { + "usages": [ + "signing", + "key encipherment", + "server auth", + "client auth" + ], + "expiry": "8760h" + } + } + } + } + ``` + +1. Создайте JSON-конфиг для запроса на подписание сертификата (CSR) (например, + `ca-csr.json`). Замените значения, помеченные угловыми скобками, на нужные. + + ```json + { + "CN": "kubernetes", + "key": { + "algo": "rsa", + "size": 2048 + }, + "names":[{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } + ``` + +1. Сгенерируйте ключ CA (`ca-key.pem`) и сертификат (`ca.pem`): + + ```shell + ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca + ``` + +1. Создайте конфигурационный JSON-файл для генерации ключей и сертификатов для сервера API (например, `server-csr.json`). Замените значения, помеченные угловыми скобками, на нужные. `MASTER_CLUSTER_IP` – это cluster IP сервиса для сервера API, как описано в предыдущем подразделе. В приведенном ниже примере предполагается, что `cluster.local` используется в качестве доменного имени по умолчанию. + + ```json + { + "CN": "kubernetes", + "hosts": [ + "127.0.0.1", + "", + "", + "kubernetes", + "kubernetes.default", + "kubernetes.default.svc", + "kubernetes.default.svc.cluster", + "kubernetes.default.svc.cluster.local" + ], + "key": { + "algo": "rsa", + "size": 2048 + }, + "names": [{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } + ``` + +1. Сгенерируйте ключ и сертификат для сервера API (по умолчанию они сохраняются в файлах `server-key.pem` и `server.pem` соответственно): + + ```shell + ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ + --config=ca-config.json -profile=kubernetes \ + server-csr.json | ../cfssljson -bare server + ``` + +## Распространение самоподписанного сертификата CA + +Клиентский узел может отказаться признавать самоподписанный сертификат CA действительным. В случае его использования не в production или в инсталляциях, защищенных межсетевым экраном, самоподписанный сертификат CA можно распространить среди всех клиентов и обновить локальный список действительных сертификатов. + +Для этого на каждом клиенте выполните следующие операции: + +```shell +sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt +sudo update-ca-certificates +``` + +```none +Updating certificates in /etc/ssl/certs... +1 added, 0 removed; done. +Running hooks in /etc/ca-certificates/update.d.... +done. +``` + +## API для сертификатов + +Для создания сертификатов x509, которые будут использоваться для аутентификации, можно воспользоваться API `certificates.k8s.io`. Для дополнительной информации см. [Управление TLS-сертификатами в кластере](/docs/tasks/tls/managing-tls-in-a-cluster). diff --git a/content/zh-cn/community/code-of-conduct.md b/content/zh-cn/community/code-of-conduct.md index 3dc283fec875b..8c35ef9594ba3 100644 --- a/content/zh-cn/community/code-of-conduct.md +++ b/content/zh-cn/community/code-of-conduct.md @@ -39,6 +39,6 @@ Your anonymity will be protected. -->

-
+
{{< include "/static/cncf-code-of-conduct.md" >}}
diff --git a/content/zh-cn/docs/concepts/architecture/nodes.md b/content/zh-cn/docs/concepts/architecture/nodes.md index 9154390eab9c3..515d9caf205dd 100644 --- a/content/zh-cn/docs/concepts/architecture/nodes.md +++ b/content/zh-cn/docs/concepts/architecture/nodes.md @@ -149,14 +149,18 @@ For self-registration, the kubelet is started with the following options: - `--kubeconfig` - 用于向 API 服务器执行身份认证所用的凭据的路径。 - `--cloud-provider` - 与某{{< glossary_tooltip text="云驱动" term_id="cloud-provider" >}} @@ -167,16 +171,16 @@ For self-registration, the kubelet is started with the following options: - `--node-ip` - 节点 IP 地址。 - `--node-labels` - 在集群中注册节点时要添加的{{< glossary_tooltip text="标签" term_id="label" >}}。 （参见 [NodeRestriction 准入控制插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)所实施的标签限制）。 -- `--node-status-update-frequency` - 指定 kubelet 向控制面发送状态的频率。 +- `--node-status-update-frequency` - 指定 kubelet 向 API 服务器发送其节点状态的频率。 -启用 [Node 鉴权模式](/zh-cn/docs/reference/access-authn-authz/node/)和 -[NodeRestriction 准入插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时， -仅授权 `kubelet` 创建或修改其自己的节点资源。 +当 [Node 鉴权模式](/zh-cn/docs/reference/access-authn-authz/node/)和 +[NodeRestriction 准入插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)被启用后， +仅授权 kubelet 创建/修改自己的 Node 资源。 {{< note >}} -下面对每个部分进行详细描述。 + +下面对输出的每个部分进行详细描述。 * HostName：由节点的内核报告。可以通过 kubelet 的 `--hostname-override` 参数覆盖。 * ExternalIP：通常是节点的可外部路由（从集群外可访问）的 IP 地址。 @@ -443,7 +451,7 @@ for more details. ### 容量（Capacity）与可分配（Allocatable） {#capacity} @@ -632,7 +640,7 @@ the same time: @@ -675,8 +683,8 @@ that the scheduler won't place Pods onto unhealthy nodes. Kubernetes {{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}} 保证节点上有足够的资源供其上的所有 Pod 使用。 @@ -704,7 +712,7 @@ Kubernetes {{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}} {{< note >}} 如果要为非 Pod 进程显式保留资源。 @@ -749,7 +757,7 @@ kubelet 会尝试检测节点系统关闭事件并终止在节点上运行的所 [Pod 终止流程](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。 @@ -768,9 +776,10 @@ enabled by default in 1.21. 注意，默认情况下，下面描述的两个配置选项，`shutdownGracePeriod` 和 `shutdownGracePeriodCriticalPods` 都是被设置为 0 的，因此不会激活节点体面关闭功能。 @@ -780,7 +789,8 @@ To activate the feature, the two kubelet config settings should be configured ap During a graceful shutdown, kubelet terminates pods in two phases: 1. Terminate regular pods running on the node. -2. Terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) running on the node. +2. Terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) + running on the node. --> 在体面关闭节点过程中，kubelet 分两个阶段来终止 Pod： @@ -788,11 +798,16 @@ During a graceful shutdown, kubelet terminates pods in two phases: 2. 终止在节点上运行的[关键 Pod](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。 节点体面关闭的特性对应两个 [`KubeletConfiguration`](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/) 选项： @@ -805,8 +820,8 @@ Graceful Node Shutdown feature is configured with two [`KubeletConfiguration`](/ 的持续时间。该值应小于 `shutdownGracePeriod`。 为了缓解上述情况，用户可以手动将具有 `NoExecute` 或 `NoSchedule` 效果的 `node.kubernetes.io/out-of-service` 污点添加到节点上，标记其无法提供服务。 @@ -906,11 +919,11 @@ During a non-graceful shutdown, Pods are terminated in the two phases: {{< note >}} @@ -1108,6 +1121,14 @@ must be set to false. 同时使用 `--fail-swap-on` 命令行参数或者将 `failSwapOn` [配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)设置为 false。 +{{< warning >}} + +当内存交换功能被启用后，Kubernetes 数据（如写入 tmpfs 的 Secret 对象的内容）可以被交换到磁盘。 +{{< /warning >}} + 默认情况下，`kubectl` 在 `$HOME/.kube` 目录下查找名为 `config` 的文件。 你可以通过设置 `KUBECONFIG` 环境变量或者设置 @@ -163,7 +163,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files: 以下是 `kubectl` 在合并 kubeconfig 文件时使用的规则。 2. 根据此链中的第一个匹配确定要使用的上下文。 @@ -288,20 +288,20 @@ kubeconfig 文件中的文件和路径引用是相对于 kubeconfig 文件的位 ## 代理 -你可以在 `kubeconfig` 文件中设置 `proxy-url` 来为 `kubectl` 使用代理，例如: +你可以在 `kubeconfig` 文件中，为每个集群配置 `proxy-url` 来让 `kubectl` 使用代理，例如： ```yaml apiVersion: v1 kind: Config -proxy-url: https://proxy.host:3128 - clusters: - cluster: + proxy-url: http://proxy.example.org:3128 + server: https://k8s.example.org/k8s/clusters/c-xxyyzz name: development users: @@ -310,7 +310,6 @@ users: contexts: - context: name: development - ``` ## {{% heading "whatsnext" %}} @@ -318,6 +317,6 @@ contexts: +--> * [配置对多集群的访问](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) * [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config) diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/_index.md b/content/zh-cn/docs/concepts/extend-kubernetes/_index.md index dcda32eab23b9..1db884b091e6f 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/_index.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/_index.md @@ -107,13 +107,13 @@ When you use a policy APIs that is [stable](/docs/reference/using-api/#api-versi [defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. For these reasons, policy APIs are recommended over *configuration files* and *command arguments* where suitable. --> -**内置的策略 API**，例如 [ResourceQuota](/zh-cn/docs/concepts/policy/resource-quotas/)、 +诸如 [ResourceQuota](/zh-cn/docs/concepts/policy/resource-quotas/)、 [NetworkPolicy](/zh-cn/docs/concepts/services-networking/network-policies/) 和基于角色的访问控制（[RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/)） -等等都是以声明方式配置策略选项的内置 Kubernetes API。 +等**内置策略 API** 都是以声明方式配置策略选项的内置 Kubernetes API。 即使在托管的 Kubernetes 服务和受控的 Kubernetes 安装环境中，API 通常也是可用的。 内置策略 API 遵循与 Pod 这类其他 Kubernetes 资源相同的约定。 -当你使用[稳定版本的](/zh-cn/docs/reference/using-api/#api-versioning)的策略 API， +当你使用[稳定版本](/zh-cn/docs/reference/using-api/#api-versioning)的策略 API， 它们与其他 Kubernetes API 一样，采纳的是一种[预定义的支持策略](/zh-cn/docs/reference/using-api/deprecation-policy/)。 出于以上原因，在条件允许的情况下，基于策略 API 的方案应该优先于**配置文件**和**命令参数**。 @@ -164,7 +164,7 @@ A controller is a client of the Kubernetes API. When Kubernetes is the client an out to a remote service, Kubernetes calls this a *webhook*. The remote service is called a *webhook backend*. As with custom controllers, webhooks do add a point of failure. --> -编写客户端程序有一种特殊的 {{< glossary_tooltip term_id="controller" text="控制器（Controller）" >}}模式， +编写客户端程序有一种特殊的{{< glossary_tooltip term_id="controller" text="控制器（Controller）" >}}模式， 能够与 Kubernetes 很好地协同工作。控制器通常会读取某个对象的 `.spec`，或许还会执行一些操作， 之后更新对象的 `.status`。 @@ -203,7 +203,7 @@ and by kubectl (see [Extend kubectl with plugins](/docs/tasks/extend-kubectl/kub This diagram shows the extension points in a Kubernetes cluster and the clients that access it. --> -### 扩展点 +### 扩展点 {#extension-points} 下图展示了 Kubernetes 集群中的这些扩展点及其访问集群的客户端。 @@ -375,7 +375,7 @@ Operator 模式用于管理特定的应用；通常，这些应用需要维护 你还可以创建自己的定制 API 和控制回路来管理其他资源（例如存储）或定义策略（例如访问控制限制）。 {{< feature-state for_k8s_version="v1.10" state="beta" >}} @@ -20,7 +26,8 @@ and other similar computing resources that may require vendor specific initializ and setup. --> Kubernetes 提供了一个 -[设备插件框架](https://git.k8s.io/design-proposals-archive/resource-management/device-plugin.md)，你可以用它来将系统硬件资源发布到 {{< glossary_tooltip term_id="kubelet" >}}。 +[设备插件框架](https://git.k8s.io/design-proposals-archive/resource-management/device-plugin.md)， +你可以用它来将系统硬件资源发布到 {{< glossary_tooltip term_id="kubelet" >}}。 供应商可以实现设备插件，由你手动部署或作为 {{< glossary_tooltip term_id="daemonset" >}} 来部署，而不必定制 Kubernetes 本身的代码。目标设备包括 GPU、高性能 NIC、FPGA、 @@ -66,15 +73,15 @@ to advertise that the node has 2 "Foo" devices installed and available. * 设备插件的 Unix 套接字。 * 设备插件的 API 版本。 -* `ResourceName` 是需要公布的。这里 `ResourceName` 需要遵循 - [扩展资源命名方案](/zh-cn/docs/concepts/configuration/manage-resources-containers/#extended-resources)， +* `ResourceName` 是需要公布的。这里 `ResourceName` + 需要遵循[扩展资源命名方案](/zh-cn/docs/concepts/configuration/manage-resources-containers/#extended-resources)， 类似于 `vendor-domain/resourcetype`。（比如 NVIDIA GPU 就被公布为 `nvidia.com/gpu`。） 成功注册后，设备插件就向 kubelet 发送它所管理的设备列表，然后 kubelet 负责将这些资源发布到 API 服务器，作为 kubelet 节点状态更新的一部分。 -比如，设备插件在 kubelet 中注册了 `hardware-vendor.example/foo` 并报告了 -节点上的两个运行状况良好的设备后，节点状态将更新以通告该节点已安装 2 个 +比如，设备插件在 kubelet 中注册了 `hardware-vendor.example/foo` +并报告了节点上的两个运行状况良好的设备后，节点状态将更新以通告该节点已安装 2 个 "Foo" 设备并且是可用的。 - 插件并非必须为 `GetPreferredAllocation()` 或 `PreStartContainer()` 提供有用 - 的实现逻辑，调用 `GetDevicePluginOptions()` 时所返回的 `DevicePluginOptions` + 插件并非必须为 `GetPreferredAllocation()` 或 `PreStartContainer()` 提供有用的实现逻辑， + 调用 `GetDevicePluginOptions()` 时所返回的 `DevicePluginOptions` 消息中应该设置这些调用是否可用。`kubelet` 在真正调用这些函数之前，总会调用 `GetDevicePluginOptions()` 来查看是否存在这些可选的函数。 {{< /note >}} @@ -242,7 +248,7 @@ kubelet instance. In the current implementation, a new kubelet instance deletes under `/var/lib/kubelet/device-plugins` when it starts. A device plugin can monitor the deletion of its Unix socket and re-register itself upon such an event. --> -### 处理 kubelet 重启 +### 处理 kubelet 重启 {#handling-kubelet-restarts} 设备插件应能监测到 kubelet 重启，并且向新的 kubelet 实例来重新注册自己。 在当前实现中，当 kubelet 重启的时候，新的 kubelet 实例会删除 `/var/lib/kubelet/device-plugins` @@ -265,12 +271,12 @@ in the plugin's If you choose the DaemonSet approach you can rely on Kubernetes to: place the device plugin's Pod onto Nodes, to restart the daemon Pod after failure, and to help automate upgrades. --> -## 设备插件部署 +## 设备插件部署 {#device-plugin-depoloyments} 你可以将你的设备插件作为节点操作系统的软件包来部署、作为 DaemonSet 来部署或者手动部署。 -规范目录 `/var/lib/kubelet/device-plugins` 是需要特权访问的，所以设备插件 -必须要在被授权的安全的上下文中运行。 +规范目录 `/var/lib/kubelet/device-plugins` 是需要特权访问的， +所以设备插件必须要在被授权的安全的上下文中运行。 如果你将设备插件部署为 DaemonSet，`/var/lib/kubelet/device-plugins` 目录必须要在插件的 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 中声明作为 {{< glossary_tooltip term_id="volume" >}} 被挂载到插件中。 @@ -292,7 +298,7 @@ a Kubernetes release with a newer device plugin API version, upgrade your device to support both versions before upgrading these nodes. Taking that approach will ensure the continuous functioning of the device allocations during the upgrade. --> -## API 兼容性 +## API 兼容性 {#api-compatibility} Kubernetes 设备插件支持还处于 beta 版本。所以在稳定版本出来之前 API 会以不兼容的方式进行更改。 作为一个项目，Kubernetes 建议设备插件开发者： @@ -306,9 +312,12 @@ Kubernetes 设备插件支持还处于 beta 版本。所以在稳定版本出来 +## 监控设备插件资源 {#monitoring-device-plugin-resources} {{< feature-state for_k8s_version="v1.15" state="beta" >}} + -## 监控设备插件资源 - -{{< feature-state for_k8s_version="v1.15" state="beta" >}} - 为了监控设备插件提供的资源，监控代理程序需要能够发现节点上正在使用的设备， 并获取元数据来描述哪个指标与容器相关联。 设备监控代理暴露给 [Prometheus](https://prometheus.io/) 的指标应该遵循 @@ -398,8 +403,8 @@ message ContainerDevices { } ``` - -{{< note >}} `List` 端点中的 `ContainerResources` 中的 cpu_ids 对应于分配给某个容器的专属 CPU。 如果要统计共享池中的 CPU，`List` 端点需要与 `GetAllocatableResources` 端点一起使用，如下所述: @@ -418,6 +421,9 @@ below: 3. 用 `GetAllocatableResources` 获取的 CPU 数减去 `GetCpuIds` 获取的 CPU 数。 {{< /note >}} + ### `GetAllocatableResources` gRPC 端点 {#grpc-endpoint-getallocatableresources} {{< feature-state state="beta" for_k8s_version="v1.23" >}} @@ -448,7 +454,6 @@ update and Kubelet needs to be restarted to reflect the correct resource capacit Kubelet 需要重新启动以获取正确的资源容量和可分配的资源。 {{< /note >}} - ```gRPC // AllocatableResourcesResponses 包含 kubelet 所了解到的所有设备的信息 message AllocatableResourcesResponse { @@ -504,8 +509,8 @@ gRPC 服务通过 `/var/lib/kubelet/pod-resources/kubelet.sock` 的 UNIX 套接 所以监控代理程序必须要在获得授权的安全的上下文中运行。 如果设备监控代理以 DaemonSet 形式运行，必须要在插件的 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) -中声明将 `/var/lib/kubelet/pod-resources` 目录以 -{{< glossary_tooltip text="卷" term_id="volume" >}}的形式被挂载到设备监控代理中。 +中声明将 `/var/lib/kubelet/pod-resources` +目录以{{< glossary_tooltip text="卷" term_id="volume" >}}的形式被挂载到设备监控代理中。 对 “PodResourcesLister 服务”的支持要求启用 `KubeletPodResources` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 @@ -513,21 +518,20 @@ gRPC 服务通过 `/var/lib/kubelet/pod-resources/kubelet.sock` 的 UNIX 套接 +## 设备插件与拓扑管理器的集成 {#device-plugin-integration-with-the-topology-manager} {{< feature-state for_k8s_version="v1.18" state="beta" >}} + -## 设备插件与拓扑管理器的集成 - -{{< feature-state for_k8s_version="v1.18" state="beta" >}} - 拓扑管理器是 Kubelet 的一个组件，它允许以拓扑对齐方式来调度资源。 为了做到这一点，设备插件 API 进行了扩展来包括一个 `TopologyInfo` 结构体。 ```gRPC message TopologyInfo { - repeated NUMANode nodes = 1; + repeated NUMANode nodes = 1; } message NUMANode { @@ -562,10 +566,14 @@ NUMA 节点列表表示设备插件没有该设备的 NUMA 亲和偏好。 ``` pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.TopologyInfo{Nodes: []*pluginapi.NUMANode{&pluginapi.NUMANode{ID: 0,},}}} ``` - +## 设备插件示例 {#examples} + +{{% thirdparty-content %}} + -## 设备插件示例 {#examples} - 下面是一些设备插件实现的示例： * [AMD GPU 设备插件](https://github.com/RadeonOpenCompute/k8s-device-plugin) @@ -600,7 +606,7 @@ Here are some examples of device plugin implementations: * Learn about the [Topology Manager](/docs/tasks/administer-cluster/topology-manager/) * Read about using [hardware acceleration for TLS ingress](/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes --> -* 查看[调度 GPU 资源](/zh-cn/docs/tasks/manage-gpus/scheduling-gpus/) 来学习使用设备插件 +* 查看[调度 GPU 资源](/zh-cn/docs/tasks/manage-gpus/scheduling-gpus/)来学习使用设备插件 * 查看在上如何[公布节点上的扩展资源](/zh-cn/docs/tasks/administer-cluster/extended-resource-node/) * 学习[拓扑管理器](/zh-cn/docs/tasks/administer-cluster/topology-manager/) * 阅读如何在 Kubernetes 中使用 [TLS Ingress 的硬件加速](/zh-cn/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) diff --git a/content/zh-cn/docs/concepts/overview/components.md b/content/zh-cn/docs/concepts/overview/components.md index 0ff3d33f3c2c3..8d3af794bc806 100644 --- a/content/zh-cn/docs/concepts/overview/components.md +++ b/content/zh-cn/docs/concepts/overview/components.md @@ -88,15 +88,15 @@ Some types of these controllers are: * Node controller: Responsible for noticing and responding when nodes go down. * Job controller: Watches for Job objects that represent one-off tasks, then creates Pods to run those tasks to completion. - * Endpoints controller: Populates the Endpoints object (that is, joins Services & Pods). - * Service Account & Token controllers: Create default accounts and API access tokens for new namespaces. + * EndpointSlice controller: Populates EndpointSlice objects (to provide a link between Services and Pods). + * ServiceAccount controller: Create default ServiceAccounts for new namespaces. --> 这些控制器包括： * 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应 * 任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成 -* 端点控制器（Endpoints Controller）：填充端点（Endpoints）对象（即加入 Service 与 Pod） -* 服务帐户和令牌控制器（Service Account & Token Controllers）：为新的命名空间创建默认帐户和 API 访问令牌 +* 端点分片控制器（EndpointSlice controller）：填充端点分片（EndpointSlice）对象（以提供 Service 和 Pod 之间的链接）。 +* 服务账号控制器（ServiceAccount controller）：为新的命名空间创建默认的服务账号（ServiceAccount）。 + + + +Kubernetes API 服务器是外部（用户和服务）与集群交互的主要入口。 + + +作为此角色的一部分，API 服务器有几个关键的内置安全控制， +例如审计日志和{{< glossary_tooltip text="准入控制器" term_id="admission-controller" >}}。 +但是，有一些方法可以绕过这些安全控制从而修改集群的配置或内容。 + + +本页描述了绕过 Kubernetes API 服务器中内置安全控制的几种方式， +以便集群运维人员和安全架构师可以确保这些绕过方式被适当地限制。 + + + +## 静态 Pod {#static-pods} + + +每个节点上的 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} +会加载并直接管理集群中存储在指定目录中或从特定 URL +获取的[**静态 Pod**](/zh-cn/docs/tasks/configure-pod-container/static-pod) 清单。 +API 服务器不管理这些静态 Pod。对该位置具有写入权限的攻击者可以修改从该位置加载的静态 Pod 的配置，或引入新的静态 Pod。 + + +静态 Pod 被限制访问 Kubernetes API 中的其他对象。例如，你不能将静态 Pod 配置为从集群挂载 Secret。 +但是，这些 Pod 可以执行其他安全敏感的操作，例如挂载来自下层节点的 `hostPath` 卷。 + + +默认情况下，kubelet 会创建一个{{< glossary_tooltip text="镜像 Pod（Mirror Pod）" term_id="mirror-pod">}}， +以便静态 Pod 在 Kubernetes API 中可见。但是，如果攻击者在创建 Pod 时使用了无效的名字空间名称， +则该 Pod 将在 Kubernetes API 中不可见，只能通过对受影响主机有访问权限的工具发现。 + + +如果静态 Pod 无法通过准入控制，kubelet 不会将 Pod 注册到 API 服务器。但该 Pod 仍然在节点上运行。 +有关更多信息，请参阅 [kubeadm issue #1541](https://github.com/kubernetes/kubeadm/issues/1541#issuecomment-487331701)。 + + +### 缓解措施 {#static-pods-mitigations} + + +- 仅在节点需要时[启用 kubelet 静态 Pod 清单功能](/zh-cn/docs/tasks/configure-pod-container/static-pod/#static-pod-creation)。 +- 如果节点使用静态 Pod 功能，请将对静态 Pod 清单目录或 URL 的文件系统的访问权限限制为需要访问的用户。 +- 限制对 kubelet 配置参数和文件的访问，以防止攻击者设置静态 Pod 路径或 URL。 +- 定期审计并集中报告所有对托管静态 Pod 清单和 kubelet 配置文件的目录或 Web 存储位置的访问。 + + +## kubelet API {#kubelet-api} + + +kubelet 提供了一个 HTTP API，通常暴露在集群工作节点上的 TCP 端口 10250 上。 +在某些 Kubernetes 发行版中，API 也可能暴露在控制平面节点上。 +对 API 的直接访问允许公开有关运行在节点上的 Pod、这些 Pod 的日志以及在节点上运行的每个容器中执行命令的信息。 + + +当 Kubernetes 集群用户具有对 `Node` 对象子资源 RBAC 访问权限时，该访问权限可用作与 kubelet API 交互的授权。 +实际的访问权限取决于授予了哪些子资源访问权限，详见 +[kubelet 鉴权](/zh-cn/docs/reference/access-authn-authz/kubelet-authn-authz/#kubelet-authorization)。 + + +对 kubelet API 的直接访问不受准入控制影响，也不会被 Kubernetes 审计日志记录。 +能直接访问此 API 的攻击者可能会绕过能检测或防止某些操作的控制机制。 + + +kubelet API 可以配置为以多种方式验证请求。 +默认情况下，kubelet 的配置允许匿名访问。大多数 Kubernetes 提供商将默认值更改为使用 Webhook 和证书身份认证。 +这使得控制平面能够确保调用者访问 `Node` API 资源或子资源是经过授权的。但控制平面不能确保默认的匿名访问也是如此。 + + +### 缓解措施 {#mitigations} + + +- 使用 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 等机制限制对 `Node` API 对象的子资源的访问。 + 只在有需要时才授予此访问权限，例如监控服务。 +- 限制对 kubelet 端口的访问。只允许指定和受信任的 IP 地址段访问该端口。 +- [确保将 kubelet 身份验证设置为 Webhook 或证书模式](/zh-cn/docs/reference/access-authn-authz/kubelet-authn-authz/#kubelet-authentication)。 +- 确保集群上未启用不作身份认证的“只读” Kubelet 端口。 + + +## etcd API {#the-etcd-api} + + +Kubernetes 集群使用 etcd 作为数据存储。`etcd` 服务监听 TCP 端口 2379。 +只有 Kubernetes API 服务器和你所使用的备份工具需要访问此存储。对该 API 的直接访问允许公开或修改集群中保存的数据。 + + +对 etcd API 的访问通常通过客户端证书身份认证来管理。 +由 etcd 信任的证书颁发机构所颁发的任何证书都可以完全访问 etcd 中存储的数据。 + + +对 etcd 的直接访问不受 Kubernetes 准入控制的影响，也不会被 Kubernetes 审计日志记录。 +具有对 API 服务器的 etcd 客户端证书私钥的读取访问权限（或可以创建一个新的受信任的客户端证书） +的攻击者可以通过访问集群 Secret 或修改访问规则来获得集群管理员权限。 +即使不提升其 Kubernetes RBAC 权限，可以修改 etcd 的攻击者也可以在集群内检索所有 API 对象或创建新的工作负载。 + + + +许多 Kubernetes 提供商配置 etcd 为使用双向 TLS（客户端和服务器都验证彼此的证书以进行身份验证）。 +尽管存在该特性，但目前还没有被广泛接受的 etcd API 鉴权实现。 +由于缺少鉴权模型，任何具有对 etcd 的客户端访问权限的证书都可以用于获得对 etcd 的完全访问权限。 +通常，仅用于健康检查的 etcd 客户端证书也可以授予完全读写访问权限。 + + +### 缓解措施 {#etcd-api-mitigations} + + +- 确保 etcd 所信任的证书颁发机构仅用于该服务的身份认证。 +- 控制对 etcd 服务器证书的私钥以及 API 服务器的客户端证书和密钥的访问。 +- 考虑在网络层面限制对 etcd 端口的访问，仅允许来自特定和受信任的 IP 地址段的访问。 + + +## 容器运行时套接字 {#runtime-socket} + + +在 Kubernetes 集群中的每个节点上，与容器交互的访问都由容器运行时控制。 +通常，容器运行时会公开一个 kubelet 可以访问的 UNIX 套接字。 +具有此套接字访问权限的攻击者可以启动新容器或与正在运行的容器进行交互。 + + +在集群层面，这种访问造成的影响取决于在受威胁节点上运行的容器是否可以访问 Secret 或其他机密数据， +攻击者可以使用这些机密数据将权限提升到其他工作节点或控制平面组件。 + + +### 缓解措施 {#runtime-socket-mitigations} + + +- 确保严格控制对容器运行时套接字所在的文件系统访问。如果可能，限制为仅 `root` 用户可访问。 +- 使用 Linux 内核命名空间等机制将 kubelet 与节点上运行的其他组件隔离。 +- 确保限制或禁止使用包含容器运行时套接字的 [`hostPath` 挂载](/zh-cn/docs/concepts/storage/volumes/#hostpath)， + 无论是直接挂载还是通过挂载父目录挂载。此外，`hostPath` 挂载必须设置为只读，以降低攻击者绕过目录限制的风险。 +- 限制用户对节点的访问，特别是限制超级用户对节点的访问。 diff --git a/content/zh-cn/docs/concepts/security/overview.md b/content/zh-cn/docs/concepts/security/overview.md index b61f74b6b809a..44f0935b8cb41 100644 --- a/content/zh-cn/docs/concepts/security/overview.md +++ b/content/zh-cn/docs/concepts/security/overview.md @@ -99,13 +99,13 @@ Here are links to some of the popular cloud providers' security documentation: IaaS 提供商 | 链接 | -------------------- | ------------ | Alibaba Cloud | https://www.alibabacloud.com/trust-center | -Amazon Web Services | https://aws.amazon.com/security/ | -Google Cloud Platform | https://cloud.google.com/security/ | -Huawei Cloud | https://www.huaweicloud.com/securecenter/overallsafety.html | +Amazon Web Services | https://aws.amazon.com/security | +Google Cloud Platform | https://cloud.google.com/security | +Huawei Cloud | https://www.huaweicloud.com/securecenter/overallsafety | IBM Cloud | https://www.ibm.com/cloud/security | Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security | -Oracle Cloud Infrastructure | https://www.oracle.com/security/ | -VMWare VSphere | https://www.vmware.com/security/hardening-guides.html | +Oracle Cloud Infrastructure | https://www.oracle.com/security | +VMWare VSphere | https://www.vmware.com/security/hardening-guides | {{< /table >}} @@ -216,7 +216,7 @@ Area of Concern for Containers | Recommendation | Container Vulnerability Scanning and OS Dependency Security | As part of an image build step, you should scan your containers for known vulnerabilities. Image Signing and Enforcement | Sign container images to maintain a system of trust for the content of your containers. Disallow privileged users | When constructing containers, consult your documentation for how to create users inside of the containers that have the least level of operating system privilege necessary in order to carry out the goal of the container. -Use container runtime with stronger isolation | Select [container runtime classes](/docs/concepts/containers/runtime-class/) that provide stronger isolation +Use container runtime with stronger isolation | Select [container runtime classes](/docs/concepts/containers/runtime-class/) that provide stronger isolation. --> ## 容器 {#container} diff --git a/content/zh-cn/docs/concepts/security/pod-security-admission.md b/content/zh-cn/docs/concepts/security/pod-security-admission.md index a36b9ddb8ecbf..c7fea290ee23f 100644 --- a/content/zh-cn/docs/concepts/security/pod-security-admission.md +++ b/content/zh-cn/docs/concepts/security/pod-security-admission.md @@ -84,7 +84,7 @@ predefined Pod Security Standard levels you want to use for a namespace. The lab defines what action the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} takes if a potential violation is detected: --> -## 为名字空间设置 Pod 安全性准入控制标签 +## 为名字空间设置 Pod 安全性准入控制标签 {#pod-security-admission-labels-for-namespaces} 一旦特性被启用或者安装了 Webhook，你可以配置名字空间以定义每个名字空间中 Pod 安全性准入控制模式。 diff --git a/content/zh-cn/docs/concepts/security/security-checklist.md b/content/zh-cn/docs/concepts/security/security-checklist.md new file mode 100644 index 0000000000000..03530e0c61a5e --- /dev/null +++ b/content/zh-cn/docs/concepts/security/security-checklist.md @@ -0,0 +1,749 @@ +--- +title: 安全检查清单 +description: > + 确保 Kubernetes 集群安全的基线检查清单。 +content_type: concept +weight: 100 +--- + + + + +本清单旨在提供一个基本的指导列表，其中包含链接，指向各个主题的更为全面的文档。 +此清单不求详尽无遗，是预计会不断演化的。 + +关于如何阅读和使用本文档： +- 主题的顺序并不代表优先级的顺序。 +- 在每章节的列表下面的段落中，都详细列举了一些检查清项目。 + +{{< caution >}} + +单靠检查清单是**不够的**，无法获得良好的安全态势。 +实现良好的安全态势需要持续的关注和改进，实现安全上有备无患的目标道路漫长，清单可作为征程上的第一步。 +对于你的特定安全需求，此清单中的某些建议可能过于严格或过于宽松。 +由于 Kubernetes 的安全性并不是“一刀切”的，因此针对每一类检查清单项目都应该做价值评估。 +{{< /caution >}} + + + + +## 认证和鉴权 {#authentication-authorization} + +- [ ] 在启动后 `system:masters` 组不用于用户或组件的身份验证。 +- [ ] kube-controller-manager 运行时要启用 `--use-service-account-credentials` 参数。 +- [ ] 根证书要受到保护（或离线 CA，或一个具有有效访问控制的托管型在线 CA）。 +- [ ] 中级证书和叶子证书的有效期不要超过未来 3 年。 +- [ ] 存在定期访问审查的流程，审查间隔不要超过 24 个月。 +- [ ] 遵循[基于角色的访问控制良好实践](/zh-cn/docs/concepts/security/rbac-good-practices/)，以获得与身份验证和授权相关的指导。 + + +在启动后，用户和组件都不应以 `system:masters` 身份向 Kubernetes API 进行身份验证。 +同样，应避免将任何 kube-controller-manager 以 `system:masters` 运行。 +事实上，`system:masters` 应该只用作一个例外机制，而不是管理员用户。 + + +## 网络安全 {#network-security} + +- [ ] 使用的 CNI 插件可支持网络策略。 +- [ ] 对集群中的所有工作负载应用入站和出站的网络策略。 +- [ ] 落实每个名称空间内的默认网络策略，覆盖所有 Pod，拒绝一切访问。 +- [ ] 如果合适，使用服务网格来加密集群内的所有通信。 +- [ ] 不在互联网上公开 Kubernetes API、kubelet API 和 etcd。 +- [ ] 过滤工作负载对云元数据 API 的访问。 +- [ ] 限制使用 LoadBalancer 和 ExternalIP。 + + +许多[容器网络接口（Container Network Interface，CNI）插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)提供了限制 +Pod 可能与之通信的网络资源的功能。 +这种限制通常通过[网络策略](/zh-cn/docs/concepts/services-networking/network-policies/)来完成， +网络策略提供了一种名称空间作用域的资源来定义规则。 +在每个名称空间中，默认的网络策略会阻塞所有的出入站流量，并选择所有 Pod， +采用允许列表的方法很有用，可以确保不遗漏任何工作负载。 + + +并非所有 CNI 插件都在传输过程中提供加密。 +如果所选的插件缺少此功能，一种替代方案是可以使用服务网格来提供该功能。 + +控制平面的 etcd 数据存储应该实施访问限制控制，并且不要在互联网上公开。 +此外，应使用双向 TLS（mTLS）与其进行安全通信。 +用在这里的证书机构应该仅用于 etcd。 + + +应该限制外部互联网对 Kubernetes API 服务器未公开的 API 的访问。 +请小心，因为许多托管的 Kubernetes 发行版在默认情况下公开了 API 服务器。 +当然，你可以使用堡垒机访问服务器。 + +对 [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) API 的访问应该受到限制， +并且不公开，当没有使用 `--config` 参数来设置配置文件时，默认的身份验证和鉴权设置是过于宽松的。 + + +如果使用云服务供应商托管的 Kubernetes，在没有明确需要的情况下， +也应该限制或阻止从 Pod 对云元数据 API `169.254.169.254` 的访问，因为这可能泄露信息。 + +关于限制使用 LoadBalancer 和 ExternalIP 请参阅 +[CVE-2020-8554：中间人使用 LoadBalancer 或 ExternalIP](https://github.com/kubernetes/kubernetes/issues/97076) +和 +[DenyServiceExternalIPs 准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#denyserviceexternalips)获取更多信息。 + + +## Pod 安全 {#pod-security} + +- [ ] 仅在必要时才授予 `create`、`update`、`patch`、`delete` 工作负载的 RBAC 权限。 +- [ ] 对所有名字空间实施适当的 Pod 安全标准策略，并强制执行。 +- [ ] 为工作负载设置内存限制值，并确保限制值等于或者不高于请求值。 +- [ ] 对敏感工作负载可以设置 CPU 限制。 +- [ ] 对于支持 Seccomp 的节点，可以为程序启用合适的系统调用配置文件。 +- [ ] 对于支持 AppArmor 或 SELinux 的系统，可以为程序启用合适的配置文件。 + + +RBAC 的授权是至关重要的， +但[不能在足够细的粒度上对 Pod 的资源进行授权](/zh-cn/docs/concepts/security/rbac-good-practices/#workload-creation)， +也不足以对管理 Pod 的任何资源进行授权。 +唯一的粒度是资源本身上的 API 动作，例如，对 Pod 的 `create`。 +在未指定额外许可的情况下，创建这些资源的权限允许直接不受限制地访问集群的可调度节点。 + + +[Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards/)定义了三种不同的策略： +特权策略（Privileged）、基线策略（Baseline）和限制策略（Restricted），它们限制了 `PodSpec` 中关于安全的字段的设置。 +这些标准可以通过默认启用的新的 +[Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission/)或第三方准入 Webhook 在名称空间级别强制执行。 +请注意，与它所取代的、已被删除的 PodSecurityPolicy 准入机制相反， +[Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission/)可以轻松地与准入 Webhook 和外部服务相结合使用。 + + +`restricted` Pod 安全准入策略是 [Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards/)集中最严格的策略， +可以在[多种种模式下运行](/zh-cn/docs/concepts/security/pod-security-admission/#pod-security-admission-labels-for-namespaces)， +根据最佳安全实践，逐步地采用 `warn`、`audit` 或者 `enforce` +模式以应用最合适的[安全上下文（Security Context）](/zh-cn/docs/tasks/configure-pod-container/security-context/)。 +尽管如此，对于特定的用例，应该单独审查 Pod 的[安全上下文](/zh-cn/docs/tasks/configure-pod-container/security-context/)， +以限制 Pod 在预定义的安全性标准之上可能具有的特权和访问权限。 + + +有关 [Pod 安全性](/zh-cn/docs/concepts/security/pod-security-admission/)的实践教程， +请参阅博文 [Kubernetes 1.23：Pod 安全性升级到 Beta](/blog/2021/12/09/pod-security-admission-beta/)。 + +为了限制一个 Pod 可以使用的内存和 CPU 资源， +应该设置 Pod 在节点上可消费的[内存和 CPU 限制](/zh-cn/docs/concepts/configuration/manage-resources-containers/), +从而防止来自恶意的或已被攻破的工作负载的潜在 DoS 攻击。这种策略可以由准入控制器强制执行。 +请注意，CPU 限制设置可能会影响 CPU 用量，从而可能会对自动扩缩功能或效率产生意外的影响， +换言之，系统会在可用的 CPU 资源下最大限度地运行进程。 + +{{< caution >}} + +内存限制高于请求的，可能会使整个节点面临 OOM 问题。 +{{< /caution >}} + + +### 启用 Seccomp {#enabling-seccomp} + + +Seccomp 通过减少容器内对 Linux 内核的系统调用（System Call）以缩小攻击面，从而提高工作负载的安全性。 +Seccomp 过滤器模式借助 BPF 创建了配置文件（Profile），文件中设置对具体系统调用的允许或拒绝， +可以针对单个工作负载上启用这类 Seccomp 配置文件。你可以阅读相应的[安全教程](/zh-cn/docs/tutorials/security/seccomp/)。 +此外，[Kubernetes Security Profiles Operator](https://github.com/kubernetes-sigs/security-profiles-operator) +是一个方便在集群中管理和使用 Seccomp 的项目。 + + +从历史背景看，请注意 Docker 自 2016 年以来一直使用[默认的 Seccomp 配置文件](https://docs.docker.com/engine/security/seccomp/)， +仅允许来自 [Docker Engine 1.10](https://www.docker.com/blog/docker-engine-1-10-security/) 的很小的一组系统调用， +但是，在默认情况下 Kubernetes 仍不限制工作负载。 +默认的 Seccomp 配置文件也可以在 +[containerd](https://github.com/containerd/containerd/blob/main/contrib/seccomp/seccomp_default.go) 中找到。 +幸运的是，[Seccomp Default](/blog/2021/08/25/seccomp-default/) 可将默认的 Seccomp 配置文件用于所有工作负载， +这是一项新的 Alpha 功能，现在可以启用和测试了。 + +{{< note >}} + +Seccomp 仅适用于 Linux 节点。 +{{< /note >}} + + +### 启用 AppArmor 或 SELinux {#enabling-appArmor-or-SELinux} + +#### AppArmor + + +[AppArmor](https://apparmor.net/) 是一个 Linux 内核安全模块， +可以提供一种简单的方法来实现强制访问控制（Mandatory Access Control， MAC）并通过系统日志进行更好地审计。 +要在 Kubernetes 中[启用 AppArmor](/zh-cn/docs/tutorials/security/apparmor/)，至少需要 1.4 版本。 +与 Seccomp 一样，AppArmor 也通过配置文件进行配置， +其中每个配置文件要么在强制（Enforcing）模式下运行，即阻止访问不允许的资源，要么在投诉（Complaining）模式下运行，只报告违规行为。 +AppArmor 配置文件是通过注解的方式，以容器为粒度强制执行的，允许进程获得刚好合适的权限。 + +{{< note >}} + +AppArmor 仅在 Linux 节点上可用，在[一些 Linux 发行版](https://gitlab.com/apparmor/apparmor/-/wikis/home#distributions-and-ports)中已启用。 +{{< /note >}} + +#### SELinux + + +[SELinux](https://github.com/SELinuxProject/selinux-notebook/blob/main/src/selinux_overview.md) +也是一个 Linux 内核安全模块，可以提供支持访问控制安全策略的机制，包括强制访问控制（MAC）。 +SELinux 标签可以[通过 `securityContext` 节](/zh-cn/docs/tasks/configure-pod-container/security-context/#assign-selinux-labels-to-a-container)指配给容器或 Pod。 + +{{< note >}} + +SELinux 仅在 Linux 节点上可用，在[一些 Linux 发行版](https://en.wikipedia.org/wiki/Security-Enhanced_Linux#Implementations)中已启用。 +{{< /note >}} + + +## Pod 布局 {#pod-placement} + +- [ ] Pod 布局是根据应用程序的敏感级别来完成的。 +- [ ] 敏感应用程序在节点上隔离运行或使用特定的沙箱运行时运行。 + + +处于不同敏感级别的 Pod，例如，应用程序 Pod 和 Kubernetes API 服务器，应该部署到不同的节点上。 +节点隔离的目的是防止应用程序容器的逃逸，进而直接访问敏感度更高的应用， +甚至轻松地改变集群工作机制。 +这种隔离应该被强制执行，以防止 Pod 集合被意外部署到同一节点上。 +可以通过以下功能实现： + + +[节点选择器（Node Selector）](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/) +: 作为 Pod 规约的一部分来设置的键值对，指定 Pod 可部署到哪些节点。 +通过 [PodNodeSelector](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#podnodeselector) +准入控制器可以在名字空间和集群级别强制实施节点选择。 + + +[PodTolerationRestriction](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#podtolerationrestriction) +: [容忍度](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)准入控制器， +允许管理员设置在名字空间内允许使用的容忍度。 +名字空间中的 Pod 只能使用名字空间对象的注解键上所指定的容忍度，这些键提供默认和允许的容忍度集合。 + + +[RuntimeClass](/zh-cn/docs/concepts/containers/runtime-class/) +: RuntimeClass 是一个用于选择容器运行时配置的特性，容器运行时配置用于运行 Pod 中的容器， +并以性能开销为代价提供或多或少的主机隔离能力。 + +## Secrets {#secrets} + + +- [ ] 不用 ConfigMap 保存机密数据。 +- [ ] 为 Secret API 配置静态加密。 +- [ ] 如果合适，可以部署和使用一种机制，负责注入保存在第三方存储中的 Secret。 +- [ ] 不应该将服务账号令牌挂载到不需要它们的 Pod 中。 +- [ ] 使用[绑定的服务账号令牌卷](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume)， + 而不要使用不会过期的令牌。 + + +Pod 所需的秘密信息应该存储在 Kubernetes Secret 中，而不是像 ConfigMap 这样的替代品中。 +存储在 etcd 中的 Secret 资源应该被静态加密。 + + +需要 Secret 的 Pod 应该通过卷自动挂载这些信息， +最好使用 [`emptyDir.medium` 选项](/zh-cn/docs/concepts/storage/volumes/#emptydir)存储在内存中。 +该机制还可以用于从第三方存储中注入 Secret 作为卷，如 [Secret Store CSI 驱动](https://secrets-store-csi-driver.sigs.k8s.io/)。 +与通过 RBAC 来允许 Pod 服务帐户访问 Secret 相比，应该优先使用上述机制。这种机制允许将 Secret 作为环境变量或文件添加到 Pod 中。 +请注意，与带访问权限控制的文件相比，由于日志的崩溃转储，以及 Linux 的环境变量的非机密性，环境变量方法可能更容易发生泄漏。 + + +不应该将服务账号令牌挂载到不需要它们的 Pod 中。 +这可以通过在服务帐号内将 +[`automountServiceAccountToken`](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server) +设置为 `false` 来完成整个名字空间范围的配置， +或者也可以单独在 Pod 层面定制。 +对于 Kubernetes v1.22 及更高版本， +请使用[绑定服务账号](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume)作为有时间限制的服务帐号凭证。 + + +## 镜像 {#images} +- [ ] 尽量减少容器镜像中不必要的内容。 +- [ ] 容器镜像配置为以非特权用户身份运行。 +- [ ] 对容器镜像的引用是通过 Sha256 摘要实现的，而不是标签（tags）， + 或者[通过准入控制器](/zh-cn/docs/tasks/administer-cluster/verify-signed-images/#verifying-image-signatures-with-admission-controller)在部署时验证镜像的数字签名来验证镜像的来源。 +- [ ] 在创建和部署过程中定期扫描容器镜像，并对已知的漏洞软件进行修补。 + + +容器镜像应该包含运行其所打包的程序所需要的最少内容。 +最好，只使用程序及其依赖项，基于最小的基础镜像来构建镜像。 +尤其是，在生产中使用的镜像不应包含 Shell 或调试工具， +因为可以使用[临时调试容器](/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container)进行故障排除。 + + +构建镜像时使用 [Dockerfile 中的 `USER`](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user) +指令直接开始使用非特权用户。 +[安全上下文（Security Context）](/zh-cn/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod) +允许使用 `runAsUser` 和 `runAsGroup` 来指定使用特定的用户和组来启动容器镜像， +即使没有在镜像清单文件（Manifest）中指定这些配置信息。 +不过，镜像层中的文件权限设置可能无法做到在不修改镜像的情况下，使用新的非特权用户来启动进程。 + + +避免使用镜像标签来引用镜像，尤其是 `latest` 标签，因为标签对应的镜像可以在仓库中被轻松地修改。 +首选使用完整的 `Sha256` 摘要，该摘要对特定镜像清单文件而言是唯一的。 +可以通过 [ImagePolicyWebhook](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) +强制执行此策略。 +镜像签名还可以在部署时由[准入控制器自动验证](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)， +以验证其真实性和完整性。 + + +扫描容器镜像可以防止关键性的漏洞随着容器镜像一起被部署到集群中。 +镜像扫描应在将容器镜像部署到集群之前完成，通常作为 CI/CD 流水线中的部署过程的一部分来完成。 +镜像扫描的目的是获取有关容器镜像中可能存在的漏洞及其预防措施的信息， +例如使用[公共漏洞评分系统 （Common Vulnerability Scoring System，CVSS）](https://www.first.org/cvss/)评分。 +如果镜像扫描的结果与管道合性规则匹配，则只有经过正确修补的容器镜像才会最终进入生产环境。 + + +## 准入控制器 {#admission-controllers} + +- [ ] 选择启用适当的准入控制器。 +- [ ] Pod 安全策略由 Pod 安全准入强制执行，或者和 Webhook 准入控制器一起强制执行。 +- [ ] 保证准入链插件和 Webhook 的配置都是安全的。 + + +准入控制器可以帮助提高集群的安全性。 +然而，由于它们是对 API 服务器的扩展，其自身可能会带来风险， +所以它们[应该得到适当的保护](/blog/2022/01/19/secure-your-admission-controllers-and-webhooks/)。 + + +下面列出了一些准入控制器，可以考虑用这些控制器来增强集群和应用程序的安全状况。 +列表中包括了可能在本文档其他部分曾提及的控制器。 + + +第一组准入控制器包括[默认启用的插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#which-plugins-are-enabled-by-default)， +除非你知道自己在做什么，否则请考虑保持它们处于被启用的状态： + + +[`CertificateApproval`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#certificateapproval) +: 执行额外的授权检查，以确保审批用户具有审批证书请求的权限。 + + +[`CertificateSigning`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#certificatesigning) +: 执行其他授权检查，以确保签名用户具有签名证书请求的权限。 + + +[`CertificateSubjectRestriction`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#certificatesubjectrestriction) +: 拒绝将 `group`（或 `organization attribute` ）设置为 `system:masters` 的所有证书请求。 + + +[`LimitRanger`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#limitranger) +: 强制执行 LimitRange API 约束。 + + +[`MutatingAdmissionWebhook`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) +: 允许通过 Webhook 使用自定义控制器，这些控制器可能会变更它所审查的请求。 + + +[`PodSecurity`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#podsecurity) +: Pod Security Policy 的替代品，用于约束所部署 Pod 的安全上下文。 + + +[`ResourceQuota`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#resourcequota) +: 强制执行资源配额，以防止资源被过度使用。 + + +[`ValidatingAdmissionWebhook`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook) +: 允许通过 Webhook 使用自定义控制器，这些控制器不变更它所审查的请求。 + + +第二组包括默认情况下没有启用、但处于正式发布状态的插件，建议启用这些插件以改善你的安全状况： + + +[`DenyServiceExternalIPs`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#denyserviceexternalips) +: 拒绝使用 `Service.spec.externalIPs` 字段，已有的 Service 不受影响，新增或者变更时不允许使用。 +这是 [CVE-2020-8554：中间人使用 LoadBalancer 或 ExternalIP](https://github.com/kubernetes/kubernetes/issues/97076) 的缓解措施。 + + +[`NodeRestriction`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction) +: 将 kubelet 的权限限制为只能修改其拥有的 Pod API 资源或代表其自身的节点 API 资源。 +此插件还可以防止 kubelet 使用 `node-restriction.kubernetes.io/` 注解， +攻击者可以使用该注解来访问 kubelet 的凭证，从而影响所控制的节点上的 Pod 布局。 + + +第三组包括默认情况下未启用，但可以考虑在某些场景下启用的插件： + + +[`AlwaysPullImages`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) +: 强制使用最新版本标记的镜像，并确保部署者有权使用该镜像。 + + +[`ImagePolicyWebhook`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) +: 允许通过 Webhook 对镜像强制执行额外的控制。 + + +## 接下来 + +- [RBAC 良好实践](/zh-cn/docs/concepts/security/rbac-good-practices/)提供有关授权的更多信息。 +- [集群多租户指南](/zh-cn/docs/concepts/security/multi-tenancy/)提供有关多租户的配置选项建议和最佳实践。 +- [博文“深入了解 NSA/CISA Kubernetes 强化指南”](/blog/2021/10/05/nsa-cisa-kubernetes-hardening-guidance/#building-secure-container-images)为强化 + Kubernetes 集群提供补充资源。 diff --git a/content/zh-cn/docs/concepts/services-networking/connect-applications-service.md b/content/zh-cn/docs/concepts/services-networking/connect-applications-service.md index 20e65b499875e..b149832892231 100644 --- a/content/zh-cn/docs/concepts/services-networking/connect-applications-service.md +++ b/content/zh-cn/docs/concepts/services-networking/connect-applications-service.md @@ -3,6 +3,15 @@ title: 使用 Service 连接到应用 content_type: concept weight: 30 --- + @@ -117,7 +126,6 @@ service/my-nginx exposed - 这等价于使用 `kubectl create -f` 命令及如下的 yaml 文件创建： {{< codenew file="service/networking/nginx-svc.yaml" >}} @@ -149,17 +157,24 @@ my-nginx ClusterIP 10.0.162.149 80/TCP 21s -正如前面所提到的，一个 Service 由一组 Pod 提供支撑。这些 Pod 通过 `endpoints` 暴露出来。 -Service Selector 将持续评估，结果被 POST 到一个名称为 `my-nginx` 的 Endpoint 对象上。 -当 Pod 终止后，它会自动从 Endpoint 中移除，新的能够匹配上 Service Selector 的 Pod 将自动地被添加到 Endpoint 中。 -检查该 Endpoint，注意到 IP 地址与在第一步创建的 Pod 是相同的。 +正如前面所提到的，一个 Service 由一组 Pod 提供支撑。这些 Pod 通过 +{{}} 暴露出来。 +Service Selector 将持续评估，结果被 POST +到使用{{< glossary_tooltip text="标签" term_id="label" >}}与该 Service 连接的一个 EndpointSlice。 +当 Pod 终止后，它会自动从包含该 Pod 的 EndpointSlices 中移除。 +新的能够匹配上 Service Selector 的 Pod 将自动地被为该 Service 添加到 EndpointSlice 中。 +检查 Endpoint，注意到 IP 地址与在第一步创建的 Pod 是相同的。 ```shell kubectl describe svc my-nginx @@ -178,11 +193,11 @@ Session Affinity: None Events: ``` ```shell -kubectl get ep my-nginx +kubectl get endpointslices -l kubernetes.io/service-name=my-nginx ``` ``` -NAME ENDPOINTS AGE -my-nginx 10.244.2.5:80,10.244.3.4:80 1m +NAME ADDRESSTYPE PORTS ENDPOINTS AGE +my-nginx-7vzhx IPv4 80 10.244.2.5,10.244.3.4 21s ``` - 现在，你应该能够从集群中任意节点上使用 curl 命令向 `:` 发送请求以访问 Nginx Service。 注意 Service IP 完全是虚拟的，它从来没有走过网络，如果对它如何工作的原理感到好奇， -可以进一步阅读[服务代理](/zh-cn/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies) -的内容。 +可以进一步阅读[服务代理](/zh-cn/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)的内容。 -{{< note >}} 如果不需要服务环境变量（因为可能与预期的程序冲突，可能要处理的变量太多，或者仅使用DNS等），则可以通过在 [pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) 上将 `enableServiceLinks` 标志设置为 `false` 来禁用此模式。 @@ -227,7 +240,7 @@ When a Pod runs on a Node, the kubelet adds a set of environment variables for each active Service. This introduces an ordering problem. To see why, inspect the environment of your running nginx Pods (your Pod name will be different): --> -### 环境变量 +### 环境变量 {#environment-variables} 当 Pod 在节点上运行时，kubelet 会针对每个活跃的 Service 为 Pod 添加一组环境变量。 这就引入了一个顺序的问题。为解释这个问题，让我们先检查正在运行的 Nginx Pod @@ -252,7 +265,6 @@ replicas. This will give you scheduler-level Service spreading of your Pods (provided all your nodes have equal capacity), as well as the right environment variables: --> - 能看到环境变量中并没有你创建的 Service 相关的值。这是因为副本的创建先于 Service。 这样做的另一个缺点是，调度器可能会将所有 Pod 部署到同一台机器上，如果该机器宕机则整个 Service 都会离线。 要改正的话，我们可以先终止这 2 个 Pod，然后等待 Deployment 去重新创建它们。 @@ -273,7 +285,6 @@ my-nginx-3800858182-j4rm4 1/1 Running 0 5s 10.244.3.8 - 你可能注意到，Pod 具有不同的名称，这是因为它们是被重新创建的。 ```shell @@ -292,7 +303,6 @@ KUBERNETES_SERVICE_PORT_HTTPS=443 - Kubernetes 提供了一个自动为其它 Service 分配 DNS 名字的 DNS 插件 Service。 你可以通过如下命令检查它是否在工作： @@ -327,7 +337,6 @@ Hit enter for command prompt - 然后，按回车并执行命令 `nslookup my-nginx`： ```shell @@ -350,7 +359,6 @@ Till now we have only accessed the nginx server from within the cluster. Before You can acquire all these from the [nginx https example](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/). This requires having go and make tools installed. If you don't want to install those, then follow the manual steps later. In short: --> - ## 保护 Service {#securing-the-service} 到现在为止，我们只在集群内部访问了 Nginx 服务器。在将 Service 暴露到因特网之前，我们希望确保通信信道是安全的。 @@ -574,7 +582,6 @@ $ curl https://: -k - 让我们重新创建一个 Service 以使用云负载均衡器。 将 `my-nginx` Service 的 `Type` 由 `NodePort` 改成 `LoadBalancer`： @@ -601,7 +608,6 @@ hostname, not an IP. It's too long to fit in the standard `kubectl get svc` output, in fact, so you'll need to do `kubectl describe service my-nginx` to see it. You'll see something like this: --> - 在 `EXTERNAL-IP` 列中的 IP 地址能在公网上被访问到。`CLUSTER-IP` 只能从集群/私有云网络中访问。 注意，在 AWS 上，类型 `LoadBalancer` 的服务会创建一个 ELB，且 ELB 使用主机名（比较长），而不是 IP。 diff --git a/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md b/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md index 41b06462c183e..82b36504f941c 100644 --- a/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md +++ b/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md @@ -1,7 +1,7 @@ --- title: Service 与 Pod 的 DNS content_type: concept -weight: 60 +weight: 80 description: >- 你的工作负载可以使用 DNS 发现集群内的 Service，本页说明具体工作原理。 --- @@ -11,7 +11,7 @@ reviewers: - thockin title: DNS for Services and Pods content_type: concept -weight: 60 +weight: 80 description: >- Your workload can discover Services within your cluster using DNS; this page explains how that works. @@ -29,14 +29,10 @@ Kubernetes 为 Service 和 Pod 创建 DNS 记录。 -## 介绍 {#introduction} - Kubernetes DNS 除了在集群上调度 DNS Pod 和 Service， 还配置 kubelet 以告知各个容器使用 DNS Service 的 IP 来解析 DNS 名称。 @@ -55,7 +51,7 @@ A DNS query may return different results based on the namespace of the Pod makin it. DNS queries that don't specify a namespace are limited to the Pod's namespace. Access Services in other namespaces by specifying it in the DNS query. -For example, consider a Pod in a `test` namespace. A `data` service is in +For example, consider a Pod in a `test` namespace. A `data` Service is in the `prod` namespace. A query for `data` returns no results, because it uses the Pod's `test` namespace. @@ -81,7 +77,7 @@ DNS queries may be expanded using the Pod's `/etc/resolv.conf`. Kubelet sets this file for each Pod. For example, a query for just `data` may be expanded to `data.test.svc.cluster.local`. The values of the `search` option are used to expand queries. To learn more about DNS queries, see -[the `resolv.conf` manual page.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html) +[the `resolv.conf` manual page.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html) --> DNS 查询可以使用 Pod 中的 `/etc/resolv.conf` 展开。kubelet 会为每个 Pod 生成此文件。例如，对 `data` 的查询可能被展开为 `data.test.svc.cluster.local`。 @@ -143,7 +139,7 @@ Services, this resolves to the set of IPs of the Pods selected by the Service. Clients are expected to consume the set or else use standard round-robin selection from the set. --> -### Services +### Service #### A/AAAA 记录 {#a-aaaa-records} @@ -181,7 +177,7 @@ SRV 记录格式为 `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.clu 其中包含 Pod 端口号和格式为 `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example` 的域名。 -## Pods +## Pod -Endpoints 对象可以为任何端点地址及其 IP 指定 `hostname`。 +{{}} +对象可以为任何端点地址及其 IP 指定 `hostname`。 ### Pod 的 setHostnameAsFQDN 字段 {#pod-sethostnameasfqdn-field} @@ -351,8 +346,8 @@ When a Pod is configured to have fully qualified domain name (FQDN), its hostnam When you set `setHostnameAsFQDN: true` in the Pod spec, the kubelet writes the Pod's FQDN into the hostname for that Pod's namespace. In this case, both `hostname` and `hostname --fqdn` return the Pod's FQDN. --> 当 Pod 配置为具有全限定域名 (FQDN) 时，其主机名是短主机名。 - 例如，如果你有一个具有完全限定域名 `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example` 的 Pod， - 则默认情况下，该 Pod 内的 `hostname` 命令返回 `busybox-1`，而 `hostname --fqdn` 命令返回 FQDN。 +例如，如果你有一个具有完全限定域名 `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example` 的 Pod， +则默认情况下，该 Pod 内的 `hostname` 命令返回 `busybox-1`，而 `hostname --fqdn` 命令返回 FQDN。 当你在 Pod 规约中设置了 `setHostnameAsFQDN: true` 时，kubelet 会将 Pod 的全限定域名（FQDN）作为该 Pod 的主机名记录到 Pod 所在名字空间。 @@ -364,16 +359,14 @@ In Linux, the hostname field of the kernel (the `nodename` field of `struct utsn If a Pod enables this feature and its FQDN is longer than 64 character, it will fail to start. The Pod will remain in `Pending` status (`ContainerCreating` as seen by `kubectl`) generating error events, such as Failed to construct FQDN from Pod hostname and cluster domain, FQDN `long-FQDN` is too long (64 characters is the max, 70 characters requested). One way of improving user experience for this scenario is to create an [admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) to control FQDN size when users create top level objects, for example, Deployment. --> -在 Linux 中，内核的主机名字段（`struct utsname` 的 `nodename` 字段）限定 -最多 64 个字符。 +在 Linux 中，内核的主机名字段（`struct utsname` 的 `nodename` 字段）限定最多 64 个字符。 如果 Pod 启用这一特性，而其 FQDN 超出 64 字符，Pod 的启动会失败。 Pod 会一直出于 `Pending` 状态（通过 `kubectl` 所看到的 `ContainerCreating`）， 并产生错误事件，例如 "Failed to construct FQDN from Pod hostname and cluster domain, FQDN `long-FQDN` is too long (64 characters is the max, 70 characters requested)." -（无法基于 Pod 主机名和集群域名构造 FQDN，FQDN `long-FQDN` 过长，至多 64 -字符，请求字符数为 70）。 +（无法基于 Pod 主机名和集群域名构造 FQDN，FQDN `long-FQDN` 过长，至多 64 个字符，请求字符数为 70）。 对于这种场景而言，改善用户体验的一种方式是创建一个 [准入 Webhook 控制器](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)， 在用户创建顶层对象（如 Deployment）的时候控制 FQDN 的长度。 @@ -409,9 +402,8 @@ following Pod-specific DNS policies. These policies are specified in the DNS 策略可以逐个 Pod 来设定。目前 Kubernetes 支持以下特定 Pod 的 DNS 策略。 这些策略可以在 Pod 规约中的 `dnsPolicy` 字段设置： -- "`Default`": Pod 从运行所在的节点继承名称解析配置。参考 - [相关讨论](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers) - 获取更多信息。 +- "`Default`": Pod 从运行所在的节点继承名称解析配置。 + 参考[相关讨论](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers)获取更多信息。 - "`ClusterFirst`": 与配置的集群域后缀不匹配的任何 DNS 查询（例如 "www.kubernetes.io"） 都将转发到从节点继承的上游名称服务器。集群管理员可能配置了额外的存根域和上游 DNS 服务器。 参阅[相关讨论](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers) @@ -419,15 +411,15 @@ DNS 策略可以逐个 Pod 来设定。目前 Kubernetes 支持以下特定 Pod - "`ClusterFirstWithHostNet`"：对于以 hostNetwork 方式运行的 Pod，应显式设置其 DNS 策略 "`ClusterFirstWithHostNet`"。 - 注意：这在 Windows 上不支持。 有关详细信息，请参见[下文](#dns-windows)。 -- "`None`": 此设置允许 Pod 忽略 Kubernetes 环境中的 DNS 设置。Pod 会使用其 `dnsConfig` 字段 - 所提供的 DNS 设置。 +- "`None`": 此设置允许 Pod 忽略 Kubernetes 环境中的 DNS 设置。Pod 会使用其 `dnsConfig` + 字段所提供的 DNS 设置。 参见 [Pod 的 DNS 配置](#pod-dns-config)节。 +{{< note >}} -{{< note >}} "Default" 不是默认的 DNS 策略。如果未明确指定 `dnsPolicy`，则使用 "ClusterFirst"。 {{< /note >}} @@ -459,9 +451,12 @@ spec: +### Pod 的 DNS 配置 {#pod-dns-config} {{< feature-state for_k8s_version="v1.14" state="stable" >}} + -### Pod 的 DNS 配置 {#pod-dns-config} - -{{< feature-state for_k8s_version="v1.14" state="stable" >}} - Pod 的 DNS 配置可让用户对 Pod 的 DNS 设置进行更多控制。 `dnsConfig` 字段是可选的，它可以与任何 `dnsPolicy` 设置一起使用。 @@ -544,6 +535,7 @@ kubectl exec -it dns-example -- cat /etc/resolv.conf The output is similar to this: --> 输出类似于： + ``` nameserver 2001:db8:30::a search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example @@ -551,26 +543,36 @@ options ndots:5 ``` +## DNS 搜索域列表限制 {#dns-search-domain-list-limits} -By default, for Pod's DNS Config, Kubernetes allows at most 6 search domains and -a list of search domains of up to 256 characters. +{{< feature-state for_k8s_version="1.26" state="beta" >}} -If the feature gate `ExpandedDNSConfig` is enabled for the kube-apiserver and -the kubelet, it is allowed for Kubernetes to have at most 32 search domains and -a list of search domains of up to 2048 characters. + -#### 扩展 DNS 配置 {#expanded-dns-configuration} +Kubernetes 本身不限制 DNS 配置，最多可支持 32 个搜索域列表，所有搜索域的总长度不超过 2048。 +此限制分别适用于节点的解析器配置文件、Pod 的 DNS 配置和合并的 DNS 配置。 -{{< feature-state for_k8s_version="1.22" state="alpha" >}} +{{< note >}} + +早期版本的某些容器运行时可能对 DNS 搜索域的数量有自己的限制。 +根据容器运行环境，那些具有大量 DNS 搜索域的 Pod 可能会卡在 Pending 状态。 -如果启用 kube-apiserver 和 kubelet 的特性门控 `ExpandedDNSConfig`，Kubernetes 将可以有最多 32 个 -搜索域以及一个最多 2048 个字符的搜索域列表。 +众所周知 containerd v1.5.5 或更早版本和 CRI-O v1.21 或更早版本都有这个问题。 +{{< /note >}} -有关管理 DNS 配置的指导，请查看 -[配置 DNS 服务](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers/) +有关管理 DNS 配置的指导， +请查看[配置 DNS 服务](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers/) diff --git a/content/zh-cn/docs/concepts/services-networking/dual-stack.md b/content/zh-cn/docs/concepts/services-networking/dual-stack.md index e9219f9dc2e25..de0137dadfa9e 100644 --- a/content/zh-cn/docs/concepts/services-networking/dual-stack.md +++ b/content/zh-cn/docs/concepts/services-networking/dual-stack.md @@ -8,7 +8,7 @@ feature: description: > 为 Pod 和 Service 分配 IPv4 和 IPv6 地址 content_type: concept -weight: 70 +weight: 90 --- @@ -247,11 +247,11 @@ These examples demonstrate the behavior of various dual-stack Service configurat this Service, Kubernetes assigns a cluster IP for the Service from the first configured `service-cluster-ip-range` and sets the `.spec.ipFamilyPolicy` to `SingleStack`. ([Services without selectors](/docs/concepts/services-networking/service/#services-without-selectors) and - [headless Services](/docs/concepts/services-networking/service/#headless-services) with selectors + [headless Services](/docs/concepts/services-networking/service/#headless-services) with selectors will behave in this same way.) --> 1. 此服务规约中没有显式设定 `.spec.ipFamilyPolicy`。当你创建此服务时，Kubernetes - 从所配置的第一个 `service-cluster-ip-range` 种为服务分配一个集群IP，并设置 + 从所配置的第一个 `service-cluster-ip-range` 中为服务分配一个集群 IP，并设置 `.spec.ipFamilyPolicy` 为 `SingleStack`。 （[无选择算符的服务](/zh-cn/docs/concepts/services-networking/service/#services-without-selectors) 和[无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)的行为方式 @@ -263,14 +263,14 @@ These examples demonstrate the behavior of various dual-stack Service configurat 1. This Service specification explicitly defines `PreferDualStack` in `.spec.ipFamilyPolicy`. When you create this Service on a dual-stack cluster, Kubernetes assigns both IPv4 and IPv6 addresses for the service. The control plane updates the `.spec` for the Service to record the IP - address assignments. The field `.spec.ClusterIPs` is the primary field, and contains both assigned + address assignments. The field `.spec.ClusterIPs` is the primary field, and contains both assigned IP addresses; `.spec.ClusterIP` is a secondary field with its value calculated from `.spec.ClusterIPs`. - + * For the `.spec.ClusterIP` field, the control plane records the IP address that is from the - same address family as the first service cluster IP range. + same address family as the first service cluster IP range. * On a single-stack cluster, the `.spec.ClusterIPs` and `.spec.ClusterIP` fields both only list - one address. + one address. * On a cluster with dual-stack enabled, specifying `RequireDualStack` in `.spec.ipFamilyPolicy` behaves the same as `PreferDualStack`. --> @@ -364,8 +364,8 @@ dual-stack.) 对于[不带选择算符的无头服务](/zh-cn/docs/concepts/services-networking/service/#without-selectors)， 若没有显式设置 `.spec.ipFamilyPolicy`，则 `.spec.ipFamilyPolicy` diff --git a/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md b/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md index 97640e0dfbe5d..3190908d7940e 100644 --- a/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md +++ b/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md @@ -34,38 +34,7 @@ Endpoints. -## 动机 {#motivation} - -Endpoints API 提供了在 Kubernetes 中跟踪网络端点的一种简单而直接的方法。遗憾的是，随着 Kubernetes -集群和{{< glossary_tooltip text="服务" term_id="service" >}}逐渐开始为更多的后端 Pod 处理和发送请求， -原来的 API 的局限性变得越来越明显。最重要的是那些因为要处理大量网络端点而带来的挑战。 - - -由于任一 Service 的所有网络端点都保存在同一个 Endpoints 资源中， -这类资源可能变得非常巨大，而这一变化会影响到 Kubernetes -组件（比如主控组件）的性能，并在 Endpoints 变化时产生大量的网络流量和额外的处理。 -EndpointSlice 能够帮助你缓解这一问题， -还能为一些诸如拓扑路由这类的额外功能提供一个可扩展的平台。 - - -## EndpointSlice 资源 {#endpointslice-resource} +## EndpointSlice API {#endpointslice-resource} 在 Kubernetes 中，`EndpointSlice` 包含对一组网络端点的引用。 控制面会自动为设置了{{< glossary_tooltip text="选择算符" term_id="selector" >}}的 @@ -90,7 +59,7 @@ EndpointSlice 通过唯一的协议、端口号和 Service 名称将网络端点 EndpointSlice 的名称必须是合法的 [DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 -例如，下面是 Kubernetes Service `example` 的 EndpointSlice 资源示例。 +例如，下面是 Kubernetes Service `example` 所拥有的 EndpointSlice 对象示例。 ```yaml apiVersion: discovery.k8s.io/v1 @@ -123,8 +92,7 @@ flag, up to a maximum of 1000. EndpointSlices can act as the source of truth for {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} when it comes to -how to route internal traffic. When enabled, they should provide a performance -improvement for services with large numbers of endpoints. +how to route internal traffic. --> 默认情况下，控制面创建和管理的 EndpointSlice 将包含不超过 100 个端点。 你可以使用 {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} @@ -133,7 +101,6 @@ improvement for services with large numbers of endpoints. 当涉及如何路由内部流量时，EndpointSlice 可以充当 {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} 的决策依据。 -启用该功能后，在服务的端点数量庞大时会有可观的性能提升。 ### 地址类型 @@ -152,6 +123,9 @@ EndpointSlice 支持三种地址类型： * IPv6 * FQDN (完全合格的域名) +每个 `EndpointSlice` 对象代表一个特定的 IP 地址类型。如果你有一个支持 IPv4 和 IPv6 的 Service， +那么将至少有两个 `EndpointSlice` 对象（一个用于 IPv4，一个用于 IPv6）。 + 在实践中，上面这种并非最理想的分布是很少出现的。大多数被 EndpointSlice 控制器处理的变更都是足够小的，可以添加到某已有 EndpointSlice 中去的。 -并且，假使无法添加到已有的切片中，不管怎样都会快就会需要一个新的 +并且，假使无法添加到已有的切片中，不管怎样都很快就会创建一个新的 EndpointSlice 对象。Deployment 的滚动更新为重新为 EndpointSlice 打包提供了一个自然的机会，所有 Pod 及其对应的端点在这一期间都会被替换掉。 @@ -443,20 +417,82 @@ EndpointSlice 对象。Deployment 的滚动更新为重新为 EndpointSlice Due to the nature of EndpointSlice changes, endpoints may be represented in more than one EndpointSlice at the same time. This naturally occurs as changes to -different EndpointSlice objects can arrive at the Kubernetes client watch/cache -at different times. Implementations using EndpointSlice must be able to have the -endpoint appear in more than one slice. A reference implementation of how to -perform endpoint deduplication can be found in the `EndpointSliceCache` -implementation in `kube-proxy`. +different EndpointSlice objects can arrive at the Kubernetes client watch / cache +at different times. --> ### 重复的端点 {#duplicate-endpoints} 由于 EndpointSlice 变化的自身特点，端点可能会同时出现在不止一个 EndpointSlice 中。鉴于不同的 EndpointSlice 对象在不同时刻到达 Kubernetes 的监视/缓存中， 这种情况的出现是很自然的。 -使用 EndpointSlice 的实现必须能够处理端点出现在多个切片中的状况。 -关于如何执行端点去重（deduplication）的参考实现，你可以在 `kube-proxy` 的 -`EndpointSlice` 实现中找到。 + +{{< note >}} + + +EndpointSlice API 的客户端必须能够处理特定端点地址出现在多个 EndpointSlice 中的情况。 + +你可以在 `kube-proxy` 中的 `EndpointSliceCache` 代码中找到有关如何执行这个端点去重的参考实现。 + +{{< /note >}} + + +## 与 Endpoints 的比较 {#motivation} +原来的 Endpoints API 提供了在 Kubernetes 中跟踪网络端点的一种简单而直接的方法。随着 Kubernetes +集群和{{< glossary_tooltip text="服务" term_id="service" >}}逐渐开始为更多的后端 Pod 处理和发送请求， +原来的 API 的局限性变得越来越明显。最明显的是那些因为要处理大量网络端点而带来的挑战。 + + +由于任一 Service 的所有网络端点都保存在同一个 Endpoints 对象中，这些 Endpoints +对象可能变得非常巨大。对于保持稳定的服务（长时间使用同一组端点），影响不太明显； +即便如此，Kubernetes 的一些使用场景也没有得到很好的服务。 + + + +当某 Service 存在很多后端端点并且该工作负载频繁扩缩或上线新更改时，对该 Service 的单个 Endpoints +对象的每次更新都意味着（在控制平面内以及在节点和 API 服务器之间）Kubernetes 集群组件之间会出现大量流量。 +这种额外的流量在 CPU 使用方面也有开销。 + + +使用 EndpointSlices 时，添加或移除单个 Pod 对于正监视变更的客户端会触发相同数量的更新， +但这些更新消息的大小在大规模场景下要小得多。 + + +EndpointSlices 还支持围绕双栈网络和拓扑感知路由等新功能的创新。 ## {{% heading "whatsnext" %}} diff --git a/content/zh-cn/docs/concepts/services-networking/service.md b/content/zh-cn/docs/concepts/services-networking/service.md index 4b8373fe86408..9bd5cfaca3ffe 100644 --- a/content/zh-cn/docs/concepts/services-networking/service.md +++ b/content/zh-cn/docs/concepts/services-networking/service.md @@ -4,18 +4,22 @@ feature: title: 服务发现与负载均衡 description: > 无需修改你的应用程序即可使用陌生的服务发现机制。Kubernetes 为容器提供了自己的 IP 地址和一个 DNS 名称，并且可以在它们之间实现负载均衡。 - +description: >- + 将在集群中运行的应用程序暴露在单个外向端点后面，即使工作负载分散到多个后端也是如此。 content_type: concept weight: 10 --- - @@ -54,7 +58,7 @@ to, so that the frontend can use the backend part of the workload? Enter _Services_. --> -## 动机 +## 动机 {#motivation} 创建和销毁 Kubernetes {{< glossary_tooltip term_id="pod" text="Pod" >}} 以匹配集群的期望状态。 Pod 是非永久性资源。 @@ -106,16 +110,17 @@ Service 定义的抽象能够解耦这种关联。 If you're able to use Kubernetes APIs for service discovery in your application, you can query the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} -for Endpoints, that get updated whenever the set of Pods in a Service changes. +for matching EndpointSlices. Kubernetes updates the EndpointSlices for a Service +whenever the set of Pods in a Service changes. For non-native applications, Kubernetes offers ways to place a network port or load balancer in between your application and the backend Pods. --> -### 云原生服务发现 +### 云原生服务发现 {#cloud-native-discovery} 如果你想要在应用程序中使用 Kubernetes API 进行服务发现，则可以查询 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} -的 Endpoints 资源，只要服务中的 Pod 集合发生更改，Endpoints 就会被更新。 +用于匹配 EndpointSlices。只要服务中的 Pod 集合发生更改，Kubernetes 就会为服务更新 EndpointSlices。 对于非本机应用程序，Kubernetes 提供了在应用程序和后端 Pod 之间放置网络端口或负载均衡器的方法。 @@ -131,7 +136,7 @@ The name of a Service object must be a valid For example, suppose you have a set of Pods where each listens on TCP port 9376 and contains a label `app=MyApp`: --> -## 定义 Service +## 定义 Service {#defining-a-service} Service 在 Kubernetes 中是一个 REST 对象，和 Pod 类似。 像所有的 REST 对象一样，Service 定义可以基于 `POST` 方式，请求 API server 创建新的实例。 @@ -153,7 +158,7 @@ spec: port: 80 targetPort: 9376 ``` - + -{{< note >}} 需要注意的是，Service 能够将一个接收 `port` 映射到任意的 `targetPort`。 默认情况下，`targetPort` 将被设置为与 `port` 字段相同的值。 {{< /note >}} @@ -242,7 +247,6 @@ As many Services need to expose more than one port, Kubernetes supports multiple port definitions on a Service object. Each port definition can have the same `protocol`, or a different one. --> - 服务的默认协议是 TCP；你还可以使用任何其他[受支持的协议](#protocol-support)。 由于许多服务需要公开多个端口，因此 Kubernetes 在服务对象上支持多个端口定义。 @@ -252,15 +256,19 @@ Each port definition can have the same `protocol`, or a different one. ### Services without selectors Services most commonly abstract access to Kubernetes Pods thanks to the selector, -but when used with a corresponding Endpoints object and without a selector, the Service can abstract other kinds of backends, -including ones that run outside the cluster. For example: +but when used with a corresponding set of +{{}} +objects and without a selector, the Service can abstract other kinds of backends, +including ones that run outside the cluster. - * You want to have an external database cluster in production, but in your - test environment you use your own databases. - * You want to point your Service to a Service in a different - {{< glossary_tooltip term_id="namespace" >}} or on another cluster. +For example: + +* You want to have an external database cluster in production, but in your + test environment you use your own databases. +* You want to point your Service to a Service in a different + {{< glossary_tooltip term_id="namespace" >}} or on another cluster. * You are migrating a workload to Kubernetes. While evaluating the approach, - you run only a portion of your backends in Kubernetes. + you run only a portion of your backends in Kubernetes. In any of these scenarios you can define a Service _without_ a Pod selector. For example: @@ -268,8 +276,10 @@ For example: ### 没有选择算符的 Service {#services-without-selectors} 由于选择算符的存在，服务最常见的用法是为 Kubernetes Pod 的访问提供抽象， -但是当与相应的 Endpoints 对象一起使用且没有选择算符时， +但是当与相应的 {{}} +对象一起使用且没有选择算符时， 服务也可以为其他类型的后端提供抽象，包括在集群外运行的后端。 + 例如： * 希望在生产环境中使用外部的数据库集群，但测试环境使用自己的数据库。 @@ -292,63 +302,103 @@ spec: ``` -由于此服务没有选择算符，因此不会自动创建相应的 Endpoints 对象。 -你可以通过手动添加 Endpoints 对象，将服务手动映射到运行该服务的网络地址和端口： +由于此服务没有选择算符，因此不会自动创建相应的 EndpointSlice（和旧版 Endpoint）对象。 +你可以通过手动添加 EndpointSlice 对象，将服务手动映射到运行该服务的网络地址和端口： ```yaml -apiVersion: v1 -kind: Endpoints +apiVersion: discovery.k8s.io/v1 +kind: EndpointSlice metadata: - # 这里的 name 要与 Service 的名字相同 - name: my-service -subsets: + name: my-service-1 # 按惯例将服务的名称用作 EndpointSlice 名称的前缀 + labels: + # 你应设置 "kubernetes.io/service-name" 标签。 + # 设置其值以匹配服务的名称 + kubernetes.io/service-name: my-service +addressType: IPv4 +ports: + - name: '' # 留空，因为 port 9376 未被 IANA 分配为已注册端口 + appProtocol: http + protocol: TCP + port: 9376 +endpoints: - addresses: - - ip: 192.0.2.42 - ports: - - port: 9376 + - "10.4.5.6" # 此列表中的 IP 地址可以按任何顺序显示 + - "10.1.2.3" ``` - -Endpoints 对象的名称必须是合法的 -[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 -当你为某个 Service 创建一个 [Endpoints](/zh-cn/docs/reference/kubernetes-api/service-resources/endpoints-v1/) -对象时，你要将新对象的名称设置为与 Service 的名称相同。 +#### 自定义 EndpointSlices + +当为服务创建 [EndpointSlice](#endpointslices) 对象时，可以为 EndpointSlice 使用任何名称。 +命名空间中的每个 EndpointSlice 必须有一个唯一的名称。通过在 EndpointSlice 上设置 +`kubernetes.io/service-name` {{< glossary_tooltip text="label" term_id="label" >}} +可以将 EndpointSlice 链接到服务。 {{< note >}} -端点 IPs **必须不可以** 是：本地回路（IPv4 的 127.0.0.0/8, IPv6 的 ::1/128） -或本地链接（IPv4 的 169.254.0.0/16 和 224.0.0.0/24，IPv6 的 fe80::/64)。 +端点 IP 地址**必须不是** ：本地回路地址（IPv4 的 127.0.0.0/8、IPv6 的 ::1/128） +或链路本地地址（IPv4 的 169.254.0.0/16 和 224.0.0.0/24、IPv6 的 fe80::/64）。 端点 IP 地址不能是其他 Kubernetes 服务的集群 IP，因为 {{< glossary_tooltip term_id ="kube-proxy">}} 不支持将虚拟 IP 作为目标。 {{< /note >}} +对于你自己或在你自己代码中创建的 EndpointSlice，你还应该为 +[`endpointslice.kubernetes.io/managed-by`](/zh-cn/docs/reference/labels-annotations-taints/#endpointslicekubernetesiomanaged-by) +标签拣选一个值。如果你创建自己的控制器代码来管理 EndpointSlice， +请考虑使用类似于 `"my-domain.example/name-of-controller"` 的值。 +如果你使用的是第三方工具，请使用全小写的工具名称，并将空格和其他标点符号更改为短划线 (`-`)。 +如果人们直接使用 `kubectl` 之类的工具来管理 EndpointSlices，请使用描述这种手动管理的名称， +例如 `"staff"` 或 `"cluster-admins"`。你应该避免使用保留值 `"controller"`， +该值标识由 Kubernetes 自己的控制平面管理的 EndpointSlices。 + + +#### 访问没有选择算符的 Service {#service-no-selector-access} + 访问没有选择算符的 Service，与有选择算符的 Service 的原理相同。 -请求将被路由到用户定义的 Endpoint，YAML 中为：`192.0.2.42:9376`（TCP）。 +在没有选择算符的 Service [示例](#services-without-selectors)中， +流量被路由到 EndpointSlice 清单中定义的两个端点之一： +通过 TCP 协议连接到 10.1.2.3 或 10.4.5.6 的端口 9376。 ExternalName Service 是 Service 的特例，它没有选择算符，但是使用 DNS 名称。 -有关更多信息，请参阅本文档后面的[ExternalName](#externalname)。 +有关更多信息，请参阅本文档后面的 [ExternalName](#externalname)。 +### EndpointSlices -If an Endpoints resource has more than 1000 endpoints then a Kubernetes v1.22 (or later) -cluster annotates that Endpoints with `endpoints.kubernetes.io/over-capacity: truncated`. -This annotation indicates that the affected Endpoints object is over capacity and that -the endpoints controller has truncated the number of endpoints to 1000. +{{< feature-state for_k8s_version="v1.21" state="stable" >}} + + -### 超出容量的 Endpoints {#over-capacity-endpoints} +[EndpointSlices](/zh-cn/docs/concepts/services-networking/endpoint-slices/) +这些对象表示针对服务的后备网络端点的子集（**切片**）。 -如果某个 Endpoints 资源中包含的端点个数超过 1000，则 Kubernetes v1.22 版本 -（及更新版本）的集群会将为该 Endpoints 添加注解 -`endpoints.kubernetes.io/over-capacity: truncated`。 -这一注解表明所影响到的 Endpoints 对象已经超出容量，此外 Endpoints 控制器还会将 Endpoints 对象数量截断到 1000。 +你的 Kubernetes 集群会跟踪每个 EndpointSlice 表示的端点数量。 +如果服务的端点太多以至于达到阈值，Kubernetes 会添加另一个空的 EndpointSlice 并在其中存储新的端点信息。 +默认情况下，一旦现有 EndpointSlice 都包含至少 100 个端点，Kubernetes 就会创建一个新的 EndpointSlice。 +在需要添加额外的端点之前，Kubernetes 不会创建新的 EndpointSlice。 + +参阅 [EndpointSlices](/zh-cn/docs/concepts/services-networking/endpoint-slices/) +了解有关该 API 的更多信息。 -### EndpointSlices +### Endpoints -{{< feature-state for_k8s_version="v1.21" state="stable" >}} +在 Kubernetes API 中，[Endpoints](/zh-cn/docs/reference/kubernetes-api/service-resources/endpoints-v1/) +（该资源类别为复数）定义了网络端点的列表，通常由 Service 引用，以定义可以将流量发送到哪些 Pod。 + +推荐用 EndpointSlice API 替换 Endpoints。 -EndpointSlices 是一种 API 资源，可以为 Endpoints 提供更可扩展的替代方案。 -尽管从概念上讲与 Endpoints 非常相似，但 EndpointSlices 允许跨多个资源分布网络端点。 -默认情况下，一旦到达 100 个 Endpoint，该 EndpointSlice 将被视为“已满”， -届时将创建其他 EndpointSlices 来存储任何其他 Endpoints。 +#### 超出容量的端点 -EndpointSlices 提供了附加的属性和功能，这些属性和功能在 -[EndpointSlices](/zh-cn/docs/concepts/services-networking/endpoint-slices/) -中有详细描述。 +Kubernetes 限制单个 Endpoints 对象中可以容纳的端点数量。 +当一个服务有超过 1000 个后备端点时，Kubernetes 会截断 Endpoints 对象中的数据。 +由于一个服务可以链接多个 EndpointSlice，所以 1000 个后备端点的限制仅影响旧版的 Endpoints API。 + + +这种情况下，Kubernetes 选择最多 1000 个可能的后端端点来存储到 Endpoints 对象中，并在 +Endpoints: [`endpoints.kubernetes.io/over-capacity: truncated`](/zh-cn/docs/reference/labels-annotations-taints/#endpoints-kubernetes-io-over-capacity) +上设置{{< glossary_tooltip text="注解" term_id="annotation" >}}。 +如果后端 Pod 的数量低于 1000，控制平面也会移除该注解。 + + +流量仍会发送到后端，但任何依赖旧版 Endpoints API 的负载均衡机制最多只能将流量发送到 1000 个可用的后备端点。 + +相同的 API 限制意味着你不能手动将 Endpoints 更新为拥有超过 1000 个端点。 + +### 应用协议 {#application-protocol} {{< feature-state for_k8s_version="v1.20" state="stable" >}} + + -### 应用协议 {#application-protocol} - -{{< feature-state for_k8s_version="v1.20" state="stable" >}} - `appProtocol` 字段提供了一种为每个 Service 端口指定应用协议的方式。 此字段的取值会被映射到对应的 Endpoints 和 EndpointSlices 对象。 该字段遵循标准的 Kubernetes 标签语法。 其值可以是 [IANA 标准服务名称](https://www.iana.org/assignments/service-names) 或以域名为前缀的名称，如 `mycompany.com/my-custom-protocol`。 + ### 为什么不使用 DNS 轮询？ {#why-not-use-round-robin-dns} @@ -631,6 +727,7 @@ IPVS 提供了更多选项来平衡后端 Pod 的流量。这些是： * `sed`：最短预期延迟（Shortest Expected Delay） * `nq`：从不排队（Never Queue） +{{< note >}} -{{< note >}} 要在 IPVS 模式下运行 kube-proxy，必须在启动 kube-proxy 之前使 IPVS 在节点上可用。 当 kube-proxy 以 IPVS 代理模式启动时，它将验证 IPVS 内核模块是否可用。 @@ -673,10 +769,10 @@ You can also set the maximum session sticky time by setting 你还可以通过适当设置 `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` 来设置最大会话停留时间。（默认值为 10800 秒，即 3 小时）。 +{{< note >}} -{{< note >}} 在 Windows 上，不支持为服务设置最大会话停留时间。 {{< /note >}} @@ -715,6 +811,7 @@ spec: targetPort: 9377 ``` +{{< note >}} -{{< note >}} 与一般的Kubernetes名称一样，端口名称只能包含小写字母数字字符 和 `-`。 端口名称还必须以字母数字字符开头和结尾。 @@ -742,7 +838,7 @@ The IP address that you choose must be a valid IPv4 or IPv6 address from within If you try to create a Service with an invalid clusterIP address value, the API server will return a 422 HTTP status code to indicate that there's a problem. --> -## 选择自己的 IP 地址 +## 选择自己的 IP 地址 {#choosing-your-own-ip-address} 在 `Service` 创建的请求中，可以通过设置 `spec.clusterIP` 字段来指定自己的集群 IP 地址。 比如，希望替换一个已经已存在的 DNS 条目，或者遗留系统已经配置了一个固定的 IP 且很难重新配置。 @@ -767,7 +863,6 @@ Valid values are `Cluster` and `Local`. Set the field to `Cluster` to route exte and `Local` to only route to ready node-local endpoints. If the traffic policy is `Local` and there are no node-local endpoints, the kube-proxy does not forward any traffic for the relevant Service. --> - 你可以通过设置 `spec.externalTrafficPolicy` 字段来控制来自于外部的流量是如何路由的。 可选值有 `Cluster` 和 `Local`。字段设为 `Cluster` 会将外部流量路由到所有就绪的端点， 设为 `Local` 会只路由到当前节点上就绪的端点。 @@ -782,7 +877,6 @@ If you enable the `ProxyTerminatingEndpoints` `ProxyTerminatingEndpoints` for the kube-proxy, the kube-proxy checks if the node has local endpoints and whether or not all the local endpoints are marked as terminating. --> - 如果你启用了 kube-proxy 的 `ProxyTerminatingEndpoints` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， kube-proxy 会检查节点是否有本地的端点，以及是否所有的本地端点都被标记为终止中。 @@ -793,7 +887,6 @@ any external traffic policy of `Local`. Instead, whilst the node-local endpoints terminating, the kube-proxy forwards traffic for that Service to healthy endpoints elsewhere, as if the external traffic policy were set to `Cluster`. --> - 如果本地有端点，而且所有端点处于终止中的状态，那么 kube-proxy 会忽略任何设为 `Local` 的外部流量策略。 在所有本地端点处于终止中的状态的同时，kube-proxy 将请求指定服务的流量转发到位于其它节点的状态健康的端点， 如同外部流量策略设为 `Cluster`。 @@ -868,6 +961,7 @@ REDIS_PRIMARY_PORT_6379_TCP_PORT=6379 REDIS_PRIMARY_PORT_6379_TCP_ADDR=10.0.0.11 ``` +{{< note >}} -{{< note >}} 当你具有需要访问服务的 Pod 时，并且你正在使用环境变量方法将端口和集群 IP 发布到客户端 Pod 时，必须在客户端 Pod 出现 **之前** 创建服务。 否则，这些客户端 Pod 将不会设定其环境变量。 @@ -968,33 +1061,38 @@ DNS 如何实现自动配置，依赖于 Service 是否定义了选择算符。 ### 带选择算符的服务 {#with-selectors} -对定义了选择算符的无头服务，Endpoints 控制器在 API 中创建了 `Endpoints` 记录， -并且修改 DNS 配置返回 A 记录（IP 地址），通过这个地址直接到达 `Service` 的后端 Pod 上。 +对定义了选择算符的无头服务，Kubernetes 控制平面在 Kubernetes API 中创建 EndpointSlice 对象， +并且修改 DNS 配置返回 A 或 AAA 条记录（IPv4 或 IPv6 地址），通过这个地址直接到达 `Service` 的后端 Pod 上。 ### 无选择算符的服务 {#without-selectors} -对没有定义选择算符的无头服务，Endpoints 控制器不会创建 `Endpoints` 记录。 -然而 DNS 系统会查找和配置，无论是： +对没有定义选择算符的无头服务，控制平面不会创建 EndpointSlice 对象。 +然而 DNS 系统会查找和配置以下之一： -* 对于 [`ExternalName`](#external-name) 类型的服务，查找其 CNAME 记录 -* 对所有其他类型的服务，查找与 Service 名称相同的任何 `Endpoints` 的记录 +* 对于 [`type: ExternalName`](#externalname) 服务，查找和配置其 CNAME 记录 +* 对所有其他类型的服务，针对 Service 的就绪端点的所有 IP 地址，查找和配置 DNS A / AAAA 条记录 + * 对于 IPv4 端点，DNS 系统创建 A 条记录。 + * 对于 IPv6 端点，DNS 系统创建 AAAA 条记录。 -## 发布服务（服务类型) {#publishing-services-service-types} +## 发布服务（服务类型） {#publishing-services-service-types} 对一些应用的某些部分（如前端），可能希望将其暴露给 Kubernetes 集群外部的 IP 地址。 -Kubernetes `ServiceTypes` 允许指定你所需要的 Service 类型，默认是 `ClusterIP`。 +Kubernetes `ServiceTypes` 允许指定你所需要的 Service 类型。 `Type` 的取值以及行为如下： * `ClusterIP`：通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。 - 这也是默认的 `ServiceType`。 + 这也是你没有为服务显式指定 `type` 时使用的默认值。 * [`NodePort`](#type-nodeport)：通过每个节点上的 IP 和静态端口（`NodePort`）暴露服务。 - `NodePort` 服务会路由到自动创建的 `ClusterIP` 服务。 - 通过请求 `<节点 IP>:<节点端口>`，你可以从集群的外部访问一个 `NodePort` 服务。 + 为了让节点端口可用，Kubernetes 设置了集群 IP 地址，这等同于你请求 `type: ClusterIP` 的服务。 * [`LoadBalancer`](#loadbalancer)：使用云提供商的负载均衡器向外部暴露服务。 外部负载均衡器可以将流量路由到自动创建的 `NodePort` 服务和 `ClusterIP` 服务上。 -* [`ExternalName`](#externalname)：通过返回 `CNAME` 和对应值，可以将服务映射到 +* [`ExternalName`](#externalname)：通过返回 `CNAME` 记录和对应值，可以将服务映射到 `externalName` 字段的内容（例如，`foo.bar.example.com`）。 无需创建任何类型代理。 {{< note >}} + 你需要使用 kube-dns 1.7 及以上版本或者 CoreDNS 0.0.8 及以上版本才能使用 `ExternalName` 类型。 {{< /note >}} @@ -1064,29 +1159,36 @@ allocates a port from a range specified by `--service-node-port-range` flag (def Each node proxies that port (the same port number on every Node) into your Service. Your Service reports the allocated port in its `.spec.ports[*].nodePort` field. -If you want to specify particular IP(s) to proxy the port, you can set the -`--nodeport-addresses` flag for kube-proxy or the equivalent `nodePortAddresses` -field of the -[kube-proxy configuration file](/docs/reference/config-api/kube-proxy-config.v1alpha1/) -to particular IP block(s). - -This flag takes a comma-delimited list of IP blocks (e.g. `10.0.0.0/8`, `192.0.2.0/25`) to specify IP address ranges that kube-proxy should consider as local to this node. +Using a NodePort gives you the freedom to set up your own load balancing solution, +to configure environments that are not fully supported by Kubernetes, or even +to expose one or more nodes' IP addresses directly. --> ### NodePort 类型 {#type-nodeport} 如果你将 `type` 字段设置为 `NodePort`，则 Kubernetes 控制平面将在 `--service-node-port-range` 标志指定的范围内分配端口（默认值：30000-32767）。 每个节点将那个端口（每个节点上的相同端口号）代理到你的服务中。 -你的服务在其 `.spec.ports[*].nodePort` 字段中要求分配的端口。 +你的服务在其 `.spec.ports[*].nodePort` 字段中报告已分配的端口。 + +使用 NodePort 可以让你自由设置自己的负载均衡解决方案， +配置 Kubernetes 不完全支持的环境， +甚至直接暴露一个或多个节点的 IP 地址。 -如果你想指定特定的 IP 代理端口，则可以设置 kube-proxy 中的 `--nodeport-addresses` 参数或者将 -[kube-proxy 配置文件](/zh-cn/docs/reference/config-api/kube-proxy-config.v1alpha1/) -中的等效 `nodePortAddresses` 字段设置为特定的 IP 块。 -该标志采用逗号分隔的 IP 块列表（例如，`10.0.0.0/8`、`192.0.2.0/25`）来指定 -kube-proxy 应该认为是此节点本地的 IP 地址范围。 + +对于 NodePort 服务，Kubernetes 额外分配一个端口（TCP、UDP 或 SCTP 以匹配服务的协议）。 +集群中的每个节点都将自己配置为监听分配的端口并将流量转发到与该服务关联的某个就绪端点。 +通过使用适当的协议（例如 TCP）和适当的端口（分配给该服务）连接到所有节点， +你将能够从集群外部使用 `type: NodePort` 服务。 -例如，如果你使用 `--nodeport-addresses=127.0.0.0/8` 标志启动 kube-proxy， -则 kube-proxy 仅选择 NodePort Services 的本地回路接口。 -`--nodeport-addresses` 的默认值是一个空列表。 -这意味着 kube-proxy 应该考虑 NodePort 的所有可用网络接口。 -（这也与早期的 Kubernetes 版本兼容）。 +#### 选择你自己的端口 {#nodeport-custom-port} 如果需要特定的端口号，你可以在 `nodePort` 字段中指定一个值。 控制平面将为你分配该端口或报告 API 事务失败。 这意味着你需要自己注意可能发生的端口冲突。 你还必须使用有效的端口号，该端口号在配置用于 NodePort 的范围内。 - -使用 NodePort 可以让你自由设置自己的负载均衡解决方案， -配置 Kubernetes 不完全支持的环境， -甚至直接暴露一个或多个节点的 IP。 - -需要注意的是，Service 能够通过 `:spec.ports[*].nodePort` 和 -`spec.clusterIp:spec.ports[*].port` 而对外可见。 -如果设置了 kube-proxy 的 `--nodeport-addresses` 参数或 kube-proxy 配置文件中的等效字段， - `` 将被过滤 NodeIP。 - -例如： +以下是 `type: NodePort` 服务的一个示例清单，它指定了一个 NodePort 值（在本例中为 30007）。 ```yaml apiVersion: v1 @@ -1147,6 +1227,56 @@ spec: nodePort: 30007 ``` + +#### 为 `type: NodePort` 服务自定义 IP 地址配置 {#service-nodeport-custom-listen-address} + +你可以在集群中设置节点以使用特定 IP 地址来提供 NodePort 服务。 +如果每个节点都连接到多个网络（例如：一个网络用于应用程序流量，另一个网络用于节点和控制平面之间的流量）， +你可能需要执行此操作。 + +如果你要指定特定的 IP 地址来代理端口，可以将 kube-proxy 的 `--nodeport-addresses` 标志或 +[kube-proxy 配置文件](/zh-cn/docs/reference/config-api/kube-proxy-config.v1alpha1/)的等效 +`nodePortAddresses` 字段设置为特定的 IP 段。 + + +此标志采用逗号分隔的 IP 段列表（例如 `10.0.0.0/8`、`192.0.2.0/25`）来指定 kube-proxy 应视为该节点本地的 +IP 地址范围。 + +例如，如果你使用 `--nodeport-addresses=127.0.0.0/8` 标志启动 kube-proxy， +则 kube-proxy 仅选择 NodePort 服务的环回接口。 +`--nodeport-addresses` 的默认值是一个空列表。 +这意味着 kube-proxy 应考虑 NodePort 的所有可用网络接口。 +（这也与早期的 Kubernetes 版本兼容。） +请注意，此服务显示为 `:spec.ports[*].nodePort` 和 `.spec.clusterIP:spec.ports[*].port`。 +如果设置了 kube-proxy 的 `--nodeport-addresses` 标志或 kube-proxy 配置文件中的等效字段， +则 `` 将是过滤的节点 IP 地址（或可能的 IP 地址）。 + +要实现 `type: LoadBalancer` 的服务，Kubernetes 通常首先进行与请求 `type: NodePort` 服务等效的更改。 +cloud-controller-manager 组件然后配置外部负载均衡器以将流量转发到已分配的节点端口。 + +**作为 Alpha 特性**，你可以将负载均衡服务配置为[忽略](#load-balancer-nodeport-allocation)分配节点端口， +前提是云提供商实现支持这点。 + +{{< note >}} -{{< note >}} 在 **Azure** 上，如果要使用用户指定的公共类型 `loadBalancerIP`， 则首先需要创建静态类型的公共 IP 地址资源。 此公共 IP 地址资源应与集群中其他自动创建的资源位于同一资源组中。 @@ -1220,7 +1370,7 @@ Specify the assigned IP address as loadBalancerIP. Ensure that you have updated 将分配的 IP 地址设置为 loadBalancerIP。确保你已更新云提供程序配置文件中的 securityGroupName。 有关对 `CreatingLoadBalancerFailed` 权限问题进行故障排除的信息， -请参阅[与 Azure Kubernetes 服务（AKS）负载平衡器一起使用静态 IP 地址](https://docs.microsoft.com/zh-cn/azure/aks/static-ip) +请参阅[与 Azure Kubernetes 服务（AKS）负载均衡器一起使用静态 IP 地址](https://docs.microsoft.com/zh-cn/azure/aks/static-ip) 或[在 AKS 集群上使用高级联网时出现 CreatingLoadBalancerFailed](https://github.com/Azure/AKS/issues/357)。 {{< /note >}} -{{< note >}} 可用于 LoadBalancer 类型服务的协议集仍然由云提供商决定。 如果云提供商不支持混合协议，他们将只提供单一协议。 {{< /note >}} @@ -1301,7 +1451,8 @@ Once set, it cannot be changed. 默认情况下，`.spec.loadBalancerClass` 的取值是 `nil`，如果集群使用 `--cloud-provider` 配置了云提供商， `LoadBalancer` 类型服务会使用云提供商的默认负载均衡器实现。 如果设置了 `.spec.loadBalancerClass`，则假定存在某个与所指定的类相匹配的负载均衡器实现在监视服务变化。 -所有默认的负载均衡器实现（例如，由云提供商所提供的）都会忽略设置了此字段的服务。`.spec.loadBalancerClass` 只能设置到类型为 `LoadBalancer` 的 Service 之上，而且一旦设置之后不可变更。 +所有默认的负载均衡器实现（例如，由云提供商所提供的）都会忽略设置了此字段的服务。`.spec.loadBalancerClass` +只能设置到类型为 `LoadBalancer` 的 Service 之上，而且一旦设置之后不可变更。 -{{< note >}} NLB 仅适用于某些实例类。有关受支持的实例类型的列表， 请参见 [AWS 文档](https://docs.aws.amazon.com/zh_cn/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets) @@ -1749,7 +1900,7 @@ traffic. Nodes without any Pods for a particular LoadBalancer Service will fail the NLB Target Group's health check on the auto-assigned `.spec.healthCheckNodePort` and not receive any traffic. --> -与经典弹性负载平衡器不同，网络负载平衡器（NLB）将客户端的 IP 地址转发到该节点。 +与经典弹性负载均衡器不同，网络负载均衡器（NLB）将客户端的 IP 地址转发到该节点。 如果服务的 `.spec.externalTrafficPolicy` 设置为 `Cluster` ，则客户端的IP地址不会传达到最终的 Pod。 通过将 `.spec.externalTrafficPolicy` 设置为 `Local`，客户端IP地址将传播到最终的 Pod， @@ -1768,12 +1919,11 @@ annotation. In order for client traffic to reach instances behind an NLB, the Node security groups are modified with the following IP rules: --> - 为了获得均衡流量，请使用 DaemonSet 或指定 [Pod 反亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) 使其不在同一节点上。 -你还可以将 NLB 服务与[内部负载平衡器](/zh-cn/docs/concepts/services-networking/service/#internal-load-balancer) +你还可以将 NLB 服务与[内部负载均衡器](/zh-cn/docs/concepts/services-networking/service/#internal-load-balancer) 注解一起使用。 为了使客户端流量能够到达 NLB 后面的实例，使用以下 IP 规则修改了节点安全组： @@ -1788,7 +1938,7 @@ groups are modified with the following IP rules: In order to limit which client IP's can access the Network Load Balancer, specify `loadBalancerSourceRanges`. --> -为了限制哪些客户端 IP 可以访问网络负载平衡器，请指定 `loadBalancerSourceRanges`。 +为了限制哪些客户端 IP 可以访问网络负载均衡器，请指定 `loadBalancerSourceRanges`。 ```yaml spec: @@ -1796,13 +1946,13 @@ spec: - "143.231.0.0/16" ``` +{{< note >}} -{{< note >}} 如果未设置 `.spec.loadBalancerSourceRanges` ，则 Kubernetes 允许从 `0.0.0.0/0` 到节点安全组的流量。 如果节点具有公共 IP 地址，请注意，非 NLB 流量也可以到达那些修改后的安全组中的所有实例。 {{< /note >}} @@ -1882,7 +2032,7 @@ There are other annotations for managing Cloud Load Balancers on TKE as shown be # 指定带宽参数 (取值范围： [1,2000] Mbps). service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out: "10" - # 当设置该注解时，负载平衡器将只注册正在运行 Pod 的节点， + # 当设置该注解时，负载均衡器将只注册正在运行 Pod 的节点， # 否则所有节点将会被注册。 service.kubernetes.io/local-svc-only-bind-node-with-pod: true ``` @@ -1914,12 +2064,12 @@ spec: externalName: my.database.example.com ``` +{{< note >}} -{{< note >}} ExternalName 服务接受 IPv4 地址字符串，但作为包含数字的 DNS 名称，而不是 IP 地址。 类似于 IPv4 地址的外部名称不能由 CoreDNS 或 ingress-nginx 解析，因为外部名称旨在指定规范的 DNS 名称。 要对 IP 地址进行硬编码，请考虑使用[无头 Services](#headless-services)。 @@ -1939,14 +2089,12 @@ Service's `type`. 访问 `my-service` 的方式与其他服务的方式相同，但主要区别在于重定向发生在 DNS 级别，而不是通过代理或转发。 如果以后你决定将数据库移到集群中，则可以启动其 Pod，添加适当的选择算符或端点以及更改服务的 `type`。 - -{{< warning >}} 对于一些常见的协议，包括 HTTP 和 HTTPS，你使用 ExternalName 可能会遇到问题。 如果你使用 ExternalName，那么集群内客户端使用的主机名与 ExternalName 引用的名称不同。 @@ -1955,11 +2103,11 @@ HTTP 请求将具有源服务器无法识别的 `Host:` 标头； TLS 服务器将无法提供与客户端连接的主机名匹配的证书。 {{< /warning >}} +{{< note >}} -{{< note >}} 有关这部分内容，我们要感谢 [Alen Komljen](https://akomljen.com/) 刊登的 [Kubernetes Tips - Part1](https://akomljen.com/kubernetes-tips-part-1/) 这篇博文。 {{< /note >}} @@ -2020,9 +2168,9 @@ a load balancer or node-port. The `Type` field is designed as nested functionality - each level adds to the previous. This is not strictly required on all cloud providers (e.g. Google Compute Engine does not need to allocate a `NodePort` to make `LoadBalancer` work, but AWS does) -but the current API requires it. +but the Kubernetes API design for Service requires it anyway. --> -## 不足之处 +## 不足之处 {#shortcomings} 为 VIP 使用用户空间代理，将只适合小型到中型规模的集群，不能够扩展到上千 Service 的大型集群。 查看[最初设计方案](https://github.com/kubernetes/kubernetes/issues/1107) 获取更多细节。 @@ -2034,7 +2182,7 @@ iptables 代理不会隐藏 Kubernetes 集群内部的 IP 地址， `Type` 字段支持嵌套功能 —— 每一层需要添加到上一层里面。 不会严格要求所有云提供商（例如，GCE 就没必要为了使一个 `LoadBalancer` -能工作而分配一个 `NodePort`，但是 AWS 需要 ），但当前 API 是强制要求的。 +能工作而分配一个 `NodePort`，但是 AWS 需要 ），但针对服务的 Kubernetes API 设计是强制要求的。 -### 避免冲突 +### 避免冲突 {#avoiding-collisions} Kubernetes 最主要的哲学之一，是用户不应该暴露那些能够导致他们操作失败、但又不是他们的过错的场景。 对于 Service 资源的设计，这意味着如果用户的选择有可能与他人冲突，那就不要让用户自行选择端口号。 @@ -2174,7 +2322,6 @@ This means that Service owners can choose any port they want without risk of collision. Clients can connect to an IP and port, without being aware of which Pods they are actually accessing. --> - 作为一个例子，考虑前面提到的图片处理应用程序。 当创建后端 Service 时，Kubernetes master 会给它指派一个虚拟 IP 地址，比如 10.0.0.1。 假设 Service 的端口是 1234，该 Service 会被集群中所有的 `kube-proxy` 实例观察到。 @@ -2231,16 +2378,20 @@ iptables operations slow down dramatically in large scale cluster e.g 10,000 Ser IPVS is designed for load balancing and based on in-kernel hash tables. So you can achieve performance consistency in large number of Services from IPVS-based kube-proxy. Meanwhile, IPVS-based kube-proxy has more sophisticated load balancing algorithms (least conns, locality, weighted, persistence). --> 在大规模集群（例如 10000 个服务）中，iptables 操作会显着降低速度。 -IPVS 专为负载平衡而设计，并基于内核内哈希表。 +IPVS 专为负载均衡而设计，并基于内核内哈希表。 因此，你可以通过基于 IPVS 的 kube-proxy 在大量服务中实现性能一致性。 同时，基于 IPVS 的 kube-proxy 具有更复杂的负载均衡算法（最小连接、局部性、加权、持久性）。 -## API 对象 - +## API 对象 {#api-object} + Service 是 Kubernetes REST API 中的顶级资源。你可以在以下位置找到有关 API 对象的更多详细信息： [Service 对象 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core). @@ -2329,11 +2480,11 @@ of the Service. 如果你的云提供商支持它，则可以在 LoadBalancer 模式下使用服务来设置外部 HTTP/HTTPS 反向代理，并将其转发到该服务的 Endpoints。 +{{< note >}} -{{< note >}} 你还可以使用 {{< glossary_tooltip text="Ingress" term_id="ingress" >}} 代替 Service 来公开 HTTP/HTTPS 服务。 {{< /note >}} @@ -2349,7 +2500,7 @@ of Kubernetes itself, that will forward connections prefixed with The load balancer will send an initial series of octets describing the incoming connection, similar to this example --> -### PROXY 协议 +### PROXY 协议 {#proxy-protocol} 如果你的云提供商支持它， 则可以在 LoadBalancer 模式下使用 Service 在 Kubernetes 本身之外配置负载均衡器， @@ -2357,7 +2508,7 @@ incoming connection, similar to this example [PROXY 协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) 的连接。 -负载平衡器将发送一系列初始字节，描述传入的连接，类似于此示例： +负载均衡器将发送一系列初始字节，描述传入的连接，类似于此示例： ``` PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n diff --git a/content/zh-cn/docs/concepts/storage/dynamic-provisioning.md b/content/zh-cn/docs/concepts/storage/dynamic-provisioning.md index 01fd7ed29cc92..4840c67db3212 100644 --- a/content/zh-cn/docs/concepts/storage/dynamic-provisioning.md +++ b/content/zh-cn/docs/concepts/storage/dynamic-provisioning.md @@ -1,12 +1,17 @@ --- title: 动态卷制备 content_type: concept -weight: 40 +weight: 50 --- @@ -31,7 +36,7 @@ automatically provisions storage when it is requested by users. -## 背景 +## 背景 {#background} 要启用动态制备功能，集群管理员需要为用户预先创建一个或多个 `StorageClass` 对象。 `StorageClass` 对象定义当动态制备被调用时，哪一个驱动将被使用和哪些参数将被传递给驱动。 -StorageClass 对象的名字必须是一个合法的 [DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +StorageClass 对象的名字必须是一个合法的 +[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 以下清单创建了一个 `StorageClass` 存储类 "slow"，它提供类似标准磁盘的永久磁盘。 ```yaml @@ -122,7 +128,8 @@ this field must match the name of a `StorageClass` configured by the administrator (see [below](#enabling-dynamic-provisioning)). --> 用户通过在 `PersistentVolumeClaim` 中包含存储类来请求动态制备的存储。 -在 Kubernetes v1.9 之前，这通过 `volume.beta.kubernetes.io/storage-class` 注解实现。然而，这个注解自 v1.6 起就不被推荐使用了。 +在 Kubernetes v1.9 之前，这通过 `volume.beta.kubernetes.io/storage-class` 注解实现。 +然而，这个注解自 v1.6 起就不被推荐使用了。 用户现在能够而且应该使用 `PersistentVolumeClaim` 对象的 `storageClassName` 字段。 这个字段的值必须能够匹配到集群管理员配置的 `StorageClass` 名称（见[下面](#enabling-dynamic-provisioning)）。 @@ -156,7 +163,7 @@ provisioned. When the claim is deleted, the volume is destroyed. -## 设置默认值的行为 +## 设置默认值的行为 {#defaulting-behavior} - 标记一个 `StorageClass` 为 **默认**； -- 确保 [`DefaultStorageClass` 准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 API 服务端被启用。 +- 确保 [`DefaultStorageClass` 准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 + API 服务器端被启用。 -管理员可以通过向其添加 `storageclass.kubernetes.io/is-default-class` -[annotation](/zh-cn/docs/reference/labels-annotations-taints/#storageclass-kubernetes-io-is-default-class) +管理员可以通过向其添加 +[`storageclass.kubernetes.io/is-default-class` 注解](/zh-cn/docs/reference/labels-annotations-taints/#storageclass-kubernetes-io-is-default-class) 来将特定的 `StorageClass` 标记为默认。 当集群中存在默认的 `StorageClass` 并且用户创建了一个未指定 `storageClassName` 的 `PersistentVolumeClaim` 时， `DefaultStorageClass` 准入控制器会自动向其中添加指向默认存储类的 `storageClassName` 字段。 @@ -202,12 +210,13 @@ be created. ## 拓扑感知 {#topology-awareness} 在[多可用区](/zh-cn/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到某个区域的多个可用区。 单可用区存储后端应该被制备到 Pod 被调度到的可用区。 这可以通过设置[卷绑定模式](/zh-cn/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。 + diff --git a/content/zh-cn/docs/concepts/storage/storage-classes.md b/content/zh-cn/docs/concepts/storage/storage-classes.md index cdd1e34c717fe..0b2a841b0ab07 100644 --- a/content/zh-cn/docs/concepts/storage/storage-classes.md +++ b/content/zh-cn/docs/concepts/storage/storage-classes.md @@ -1,7 +1,7 @@ --- title: 存储类 content_type: concept -weight: 30 +weight: 40 --- @@ -52,7 +52,7 @@ class needs to be dynamically provisioned. ## StorageClass 资源 {#the-storageclass-resource} 每个 StorageClass 都包含 `provisioner`、`parameters` 和 `reclaimPolicy` 字段， -这些字段会在 StorageClass 需要动态分配 PersistentVolume 时会使用到。 +这些字段会在 StorageClass 需要动态制备 PersistentVolume 时会使用到。 -{{< note >}} 此功能仅可用于扩容卷，不能用于缩小卷。 {{< /note >}} @@ -467,7 +467,7 @@ parameters: `zone` and `zones` parameters are deprecated and replaced with [allowedTopologies](#allowed-topologies) --> -`zone` 和 `zones` 已被弃用并被 [允许的拓扑结构](#allowed-topologies) 取代。 +`zone` 和 `zones` 已被弃用并被[允许的拓扑结构](#allowed-topologies)取代。 {{< /note >}} ### GCE PD {#gce-pd} @@ -503,7 +503,7 @@ parameters: * `zones`(弃用)：逗号分隔的 GCE 区域列表。如果没有指定 `zone` 和 `zones`， 通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度（round-robin）分配。 `zone` 和 `zones` 参数不能同时使用。 -* `fstype`: `ext4` 或 `xfs`。 默认: `ext4`。宿主机操作系统必须支持所定义的文件系统类型。 +* `fstype`：`ext4` 或 `xfs`。 默认：`ext4`。宿主机操作系统必须支持所定义的文件系统类型。 * `replication-type`：`none` 或者 `regional-pd`。默认值：`none`。 -{{< note >}} `zone` 和 `zones` 已被弃用并被 [allowedTopologies](#allowed-topologies) 取代。 {{< /note >}} -### Glusterfs + +### Glusterfs（已弃用） {#glusterfs} ```yaml apiVersion: storage.k8s.io/v1 @@ -659,11 +662,11 @@ parameters: deleted when the persistent volume claim is deleted. --> * `volumetype`：卷的类型及其参数可以用这个可选值进行配置。如果未声明卷类型，则由制备器决定卷的类型。 - 例如： - * 'Replica volume': `volumetype: replicate:3` 其中 '3' 是 replica 数量。 - * 'Disperse/EC volume': `volumetype: disperse:4:2` 其中 '4' 是数据，'2' 是冗余数量。 - * 'Distribute volume': `volumetype: none` + 例如： + * 'Replica volume'：`volumetype: replicate:3` 其中 '3' 是 replica 数量。 + * 'Disperse/EC volume'：`volumetype: disperse:4:2` 其中 '4' 是数据，'2' 是冗余数量。 + * 'Distribute volume'：`volumetype: none` 有关可用的卷类型和管理选项， 请参阅[管理指南](https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/)。 @@ -726,10 +729,10 @@ parameters: --> * `availability`：可用区域。如果没有指定，通常卷会在 Kubernetes 集群节点所在的活动区域中轮转调度。 +{{< note >}} -{{< note >}} {{< feature-state state="deprecated" for_k8s_version="1.11" >}} OpenStack 的内部驱动已经被弃用。请使用 [OpenStack 的外部云驱动](https://github.com/kubernetes/cloud-provider-openstack)。 @@ -745,7 +748,7 @@ There are two types of provisioners for vSphere storage classes: In-tree provisioners are [deprecated](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi). For more information on the CSI provisioner, see [Kubernetes vSphere CSI Driver](https://vsphere-csi-driver.sigs.k8s.io/) and [vSphereVolume CSI migration](/docs/concepts/storage/volumes/#vsphere-csi-migration). --> -vSphere 存储类有两种制备器 +vSphere 存储类有两种制备器： - [CSI 制备器](#vsphere-provisioner-csi)：`csi.vsphere.vmware.com` - [vCP 制备器](#vcp-provisioner)：`kubernetes.io/vsphere-volume` @@ -773,7 +776,7 @@ The following examples use the VMware Cloud Provider (vCP) StorageClass provisio --> #### vCP 制备器 {#vcp-provisioner} -以下示例使用 VMware Cloud Provider (vCP) StorageClass 调度器。 +以下示例使用 VMware Cloud Provider (vCP) StorageClass 制备器。 - `diskformat`: `thin`, `zeroedthick` 和 `eagerzeroedthick`。默认值: `"thin"`。 + `diskformat`：`thin`、`zeroedthick` 和 `eagerzeroedthick`。默认值：`"thin"`。 -* [`FlexVolume plugins`](/zh-cn/docs/concepts/storage/volumes/#flexvolume-deprecated) +* [`FlexVolume plugins`](/zh-cn/docs/concepts/storage/volumes/#flexvolume) * 请注意自 1.23 版本起，FlexVolume 已被弃用 * [`CSI Plugins`](/zh-cn/docs/concepts/storage/volumes/#csi) diff --git a/content/zh-cn/docs/concepts/workloads/controllers/deployment.md b/content/zh-cn/docs/concepts/workloads/controllers/deployment.md index 2f660e9029aee..343b0896b3573 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/deployment.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/deployment.md @@ -67,14 +67,14 @@ The following are typical use cases for Deployments: * 如果 Deployment 的当前状态不稳定，[回滚到较早的 Deployment 版本](#rolling-back-a-deployment)。 每次回滚都会更新 Deployment 的修订版本。 * [扩大 Deployment 规模以承担更多负载](#scaling-a-deployment)。 -* [暂停 Deployment ](#pausing-and-resuming-a-deployment) 以应用对 PodTemplateSpec 所作的多项修改， +* [暂停 Deployment 的上线](#pausing-and-resuming-a-deployment) 以应用对 PodTemplateSpec 所作的多项修改， 然后恢复其执行以启动新的上线版本。 * [使用 Deployment 状态](#deployment-status)来判定上线过程是否出现停滞。 * [清理较旧的不再需要的 ReplicaSet](#clean-up-policy) 。 @@ -98,11 +98,10 @@ In this example: * 创建名为 `nginx-deployment`（由 `.metadata.name` 字段标明）的 Deployment。 * 该 Deployment 创建三个（由 `.spec.replicas` 字段标明）Pod 副本。 -* `.spec.selector` 字段定义了 Deployment 如何查找要管理的 Pod。 4. 几秒钟后再次运行 `kubectl get deployments`。输出类似于： @@ -1626,10 +1626,10 @@ Deployment progress has stalled. 以下 `kubectl` 命令设置规约中的 `progressDeadlineSeconds`，从而告知控制器 -在 10 分钟后报告 Deployment 没有进展： +在 10 分钟后报告 Deployment 的上线没有进展： ```shell kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}' @@ -1683,11 +1683,11 @@ Deployment 不执行任何操作。更高级别的编排器可以利用这一设 {{< note >}} -如果你暂停了某个 Deployment 上线，Kubernetes 不再根据指定的截止时间检查 Deployment 进展。 +如果你暂停了某个 Deployment 上线，Kubernetes 不再根据指定的截止时间检查 Deployment 上线的进展。 你可以在上线过程中间安全地暂停 Deployment 再恢复其执行，这样做不会导致超出最后时限的问题。 {{< /note >}} @@ -1837,8 +1837,7 @@ $ echo $? ### Operating on a failed deployment All actions that apply to a complete Deployment also apply to a failed Deployment. You can scale it up/down, roll back -to a previous revision, or even pause it if you need to apply multiple tweaks in the Deployment -Pod template. +to a previous revision, or even pause it if you need to apply multiple tweaks in the Deployment Pod template. --> ### 对失败 Deployment 的操作 {#operating-on-a-failed-deployment} diff --git a/content/zh-cn/docs/concepts/workloads/controllers/statefulset.md b/content/zh-cn/docs/concepts/workloads/controllers/statefulset.md index 0542d1a2347a5..2f330ae4c370f 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/statefulset.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/statefulset.md @@ -622,12 +622,12 @@ StatefulSet 才会开始使用被还原的模板来重新创建 Pod。 The optional `.spec.persistentVolumeClaimRetentionPolicy` field controls if and how PVCs are deleted during the lifecycle of a StatefulSet. You must enable the `StatefulSetAutoDeletePVC` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) -to use this field. Once enabled, there are two policies you can configure for each -StatefulSet: +on the API server and the controller manager to use this field. +Once enabled, there are two policies you can configure for each StatefulSet: --> 在 StatefulSet 的生命周期中，可选字段 `.spec.persistentVolumeClaimRetentionPolicy` 控制是否删除以及如何删除 PVC。 -使用该字段，你必须启用 `StatefulSetAutoDeletePVC` +使用该字段，你必须在 API 服务器和控制器管理器启用 `StatefulSetAutoDeletePVC` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 启用后，你可以为每个 StatefulSet 配置两个策略： diff --git a/content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md b/content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md index 696fb5ba4269e..a97cfad55947c 100644 --- a/content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md @@ -43,7 +43,7 @@ or is [terminated](#pod-termination). --> 在 Kubernetes API 中，Pod 包含规约部分和实际状态部分。 Pod 对象的状态包含了一组 [Pod 状况（Conditions）](#pod-conditions)。 -如果应用需要的话，你也可以向其中注入[自定义的就绪性信息](#pod-readiness-gate)。 +如果应用需要的话，你也可以向其中注入[自定义的就绪态信息](#pod-readiness-gate)。 Pod 在其生命周期中只会被[调度](/zh-cn/docs/concepts/scheduling-eviction/)一次。 一旦 Pod 被调度（分派）到某个节点，Pod 会一直在该节点运行，直到 Pod @@ -58,7 +58,7 @@ Like individual application containers, Pods are considered to be relatively ephemeral (rather than durable) entities. Pods are created, assigned a unique ID ([UID](/docs/concepts/overview/working-with-objects/names/#uids)), and scheduled to nodes where they remain until termination (according to restart policy) or -deletion. +deletion. If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node are [scheduled for deletion](#pod-garbage-collection) after a timeout period. --> @@ -159,13 +159,13 @@ Value | Description `Failed`（失败） | Pod 中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止。 `Unknown`（未知） | 因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败。 +{{< note >}} -{{< note >}} 当一个 Pod 被删除时，执行一些 kubectl 命令会展示这个 Pod 的状态为 `Terminating`（终止）。 这个 `Terminating` 状态并不是 Pod 阶段之一。 Pod 被赋予一个可以体面终止的期限，默认为 30 秒。 @@ -338,7 +338,7 @@ Field name | Description 字段名称 | 描述 :--------------------|:----------- `type` | Pod 状况的名称 -`status` | 表明该状况是否适用，可能的取值有 "`True`", "`False`" 或 "`Unknown`" +`status` | 表明该状况是否适用，可能的取值有 "`True`"、"`False`" 或 "`Unknown`" `lastProbeTime` | 上次探测 Pod 状况时的时间戳 `lastTransitionTime` | Pod 上次从一种状态转换到另一种状态时的时间戳 `reason` | 机器可读的、驼峰编码（UpperCamelCase）的文字，表述上次状况变化的原因 @@ -845,33 +845,41 @@ An example flow: runs that hook inside of the container. If the `preStop` hook is still running after the grace period expires, the kubelet requests a small, one-off grace period extension of 2 seconds. - If the `preStop` hook needs longer to complete than the default grace period allows, - you must modify `terminationGracePeriodSeconds` to suit this. - 1. The kubelet triggers the container runtime to send a TERM signal to process 1 inside each - container. - The containers in the Pod receive the TERM signal at different times and in an arbitrary - order. If the order of shutdowns matters, consider using a `preStop` hook to synchronize. --> + 1. 如果 Pod 中的容器之一定义了 `preStop` [回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks)， `kubelet` 开始在容器内运行该回调逻辑。如果超出体面终止限期时， `preStop` 回调逻辑仍在运行，`kubelet` 会请求给予该 Pod 的宽限期一次性增加 2 秒钟。 {{< note >}} + 如果 `preStop` 回调所需要的时间长于默认的体面终止限期，你必须修改 `terminationGracePeriodSeconds` 属性值来使其正常工作。 {{< /note >}} + + - 1. `kubelet` 接下来触发容器运行时发送 TERM 信号给每个容器中的进程 1。 + 2. `kubelet` 接下来触发容器运行时发送 TERM 信号给每个容器中的进程 1。 {{< note >}} + Pod 中的容器会在不同时刻收到 TERM 信号，接收顺序也是不确定的。 如果关闭的顺序很重要，可以考虑使用 `preStop` 回调逻辑来协调。 {{< /note >}} -3. 与此同时，`kubelet` 启动体面关闭逻辑，控制面会将 Pod 从对应的端点列表（以及端点切片列表， - 如果启用了的话）中移除，过滤条件是 Pod 被对应的 - {{< glossary_tooltip term_id="service" text="服务" >}}以某 +3. 在 `kubelet` 启动体面关闭逻辑的同时，控制面会将关闭的 Pod 从对应的 + EndpointSlice（和 Endpoints）对象中移除，过滤条件是 Pod + 被对应的{{< glossary_tooltip term_id="service" text="服务" >}}以某 {{< glossary_tooltip text="选择算符" term_id="selector" >}}选定。 - {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} + {{< glossary_tooltip text="ReplicaSet" term_id="replica-set" >}} 和其他工作负载资源不再将关闭进程中的 Pod 视为合法的、能够提供服务的副本。 关闭动作很慢的 Pod 也无法继续处理请求数据， 因为负载均衡器（例如服务代理）已经在终止宽限期开始的时候将其从端点列表中移除。 @@ -907,19 +915,21 @@ An example flow: ### 强制终止 Pod {#pod-termination-forced} {{< caution >}} + 对于某些工作负载及其 Pod 而言，强制删除很可能会带来某种破坏。 {{< /caution >}} + 默认情况下，所有的删除操作都会附有 30 秒钟的宽限期限。 `kubectl delete` 命令支持 `--grace-period=` 选项，允许你重载默认值， 设定自己希望的期限值。 @@ -932,12 +942,11 @@ begin immediate cleanup. 将宽限期限强制设置为 `0` 意味着立即从 API 服务器删除 Pod。 如果 Pod 仍然运行于某节点上，强制删除操作会触发 `kubelet` 立即执行清理操作。 +{{< note >}} -{{< note >}} -你必须在设置 `--grace-period=0` 的同时额外设置 `--force` -参数才能发起强制删除请求。 +你必须在设置 `--grace-period=0` 的同时额外设置 `--force` 参数才能发起强制删除请求。 {{< /note >}} 此页面描述如何为其他语言的文档提供 [本地化](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/)版本。 @@ -34,7 +35,11 @@ This page shows you how to [localize](https://blog.mozilla.org/l10n/2011/12/14/i ## 为现有的本地化做出贡献 {#contribute-to-an-existing-localization} @@ -45,30 +50,31 @@ You can help add or improve content to an existing localization. In [Kubernetes {{< note >}} -如果你想处理已经存在的本地化，请在该本地化（如果存在）中检查此页面，而不是英文原版。 -你可能会在那里看到额外的详细信息。 +有关如何为特定本地化做贡献的更多信息，请参阅本页面的各个本地化版本。 {{< /note >}} ### 找到两个字母的语言代码 {#find-your-two-letter-language-code} 首先，有关本地化的两个字母的语言代码，请参考 [ISO 639-1 标准](https://www.loc.gov/standards/iso639-2/php/code_list.php)。 -例如，韩国的两个字母代码是 `ko`。 +例如，韩语的两个字母代码是 `ko`。 ### 派生（fork）并且克隆仓库 {#fork-and-clone-the-repo} @@ -86,7 +92,8 @@ cd website ``` 网站内容目录包括每种语言的子目录。你想要助力的本地化位于 `content/` 中。 @@ -96,15 +103,16 @@ The website content directory includes sub-directories for each language. The lo Create or update your chosen localized page based on the English original. See [translating content](#translating-content) for more details. -If you notice a technical inaccuracy or other problem with the upstream (English) -documentation, you should fix the upstream documentation first and then repeat the -equivalent fix by updating the localization you're working on. +If you notice a technical inaccuracy or other problem with the upstream +(English) documentation, you should fix the upstream documentation first and +then repeat the equivalent fix by updating the localization you're working on. -Please limit pull requests to a single localization, since pull requests that change -content in multiple localizations could be difficult to review. +Limit changes in a pull requests to a single localization. Reviewing pull +requests that change content in multiple localizations is problematic. -Follow [Suggesting Content Improvements](/docs/contribute/suggest-improvements/) to propose changes to -that localization. The process is very similar to proposing changes to the upstream (English) content. +Follow [Suggesting Content Improvements](/docs/contribute/suggesting-improvements/) +to propose changes to that localization. The process is similar to proposing +changes to the upstream (English) content. --> ### 建议更改 {#suggest-changes} @@ -114,7 +122,7 @@ that localization. The process is very similar to proposing changes to the upstr 如果你发现上游（英文）文档存在技术错误或其他问题， 你应该先修复上游文档，然后通过更新你正在处理的本地化来重复等效的修复。 -请将拉取请求限制为单个本地化，因为在多个本地化中更改内容的拉取请求可能难以审查。 +请将 PR 限制为单个语言版本，因为多语言的 PR 内容修改可能难以审查。 按照[内容改进建议](/zh-cn/docs/contribute/suggest-improvements/)提出对该本地化的更改。 该过程与提议更改上游（英文）内容非常相似。 @@ -122,29 +130,30 @@ that localization. The process is very similar to proposing changes to the upstr ## 开始新的本地化 {#start-a-new-localization} 如果你希望将 Kubernetes 文档本地化为一种新语言，你需要执行以下操作。 -因为贡献者不能批准他们自己的拉取请求，你需要 _至少两个贡献者_ 来开始本地化。 +因为贡献者不能批准他们自己的拉取请求，你需要 **至少两个贡献者** 来开始本地化。 所有本地化团队都必须能够自我维持。 Kubernetes 网站很乐意托管你的作品，但要由你来翻译它并使现有的本地化内容保持最新。 ### 找到社区 {#find-community} 让 Kubernetes SIG Docs 知道你有兴趣创建本地化！ 加入 [SIG Docs Slack 频道](https://kubernetes.slack.com/messages/sig-docs) 和 [SIG Docs Localizations Slack 频道](https://kubernetes.slack.com/messages/sig-docs-localizations)。 -其他本地化团队很乐意帮助你入门并回答你的任何问题。 +其他本地化团队很乐意帮助你入门并回答你的问题。 也请考虑参加 [SIG Docs 本地化小组的会议](https://github.com/kubernetes/community/tree/master/sig-docs)。 SIG Docs 本地化小组的任务是与 SIG Docs 本地化团队合作， 共同定义和记录创建本地化贡献指南的流程。 此外，SIG Docs 本地化小组将寻找机会在本地化团队中创建和共享通用工具， -并为 SIG Docs 领导团队确定新要求。如果你对本次会议有任何疑问， -请在 [SIG Docs Localizations Slack 频道](https://kubernetes.slack.com/messages/sig-docs-localizations) -中提问。 +并为 SIG Docs 领导团队确定新要求。如果你对本次会议有任何疑问，请在 +[SIG Docs Localizations Slack 频道](https://kubernetes.slack.com/messages/sig-docs-localizations)中提问。 你还可以在 `kubernetes/community` 仓库中为你的本地化创建一个 Slack 频道。 -有关添加 Slack 频道的示例，请参阅 -[为波斯语添加频道](https://github.com/kubernetes/community/pull/4980)的 PR。 +有关添加 Slack 频道的示例， +请参阅[为波斯语添加频道](https://github.com/kubernetes/community/pull/4980)的 PR。 ### 加入到 Kubernetes GitHub 组织 {#join-the-kubernetes-github-organization} 提交本地化 PR 后，你可以成为 Kubernetes GitHub 组织的成员。 -团队中的每个人都需要在 `kubernetes/org` 仓库中创建自己的 -[组织成员申请](https://github.com/kubernetes/org/issues/new/choose)。 +团队中的每个人都需要在 `kubernetes/org` +仓库中创建自己的[组织成员申请](https://github.com/kubernetes/org/issues/new/choose)。 ### 在 GitHub 中添加你的本地化团队 {#add-your-localization-team-in-github} 接下来，将你的 Kubernetes 本地化团队添加到 [`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/main/config/kubernetes/sig-docs/teams.yaml)。 -有关添加本地化团队的示例，请参见添加[西班牙本地化团队](https://github.com/kubernetes/org/pull/685) 的 PR。 +有关添加本地化团队的示例，请参见添加[西班牙本地化团队](https://github.com/kubernetes/org/pull/685)的 PR。 `@kubernetes/sig-docs-**-owners` 成员可以批准更改对应本地化目录 `/content/**/` 中内容的 PR，并仅限这类 PR。 - 对于每个本地化，`@kubernetes/sig-docs-**-reviews` 团队被自动分派新 PR 的审阅任务。 - - `@kubernetes/website-maintainers` 成员可以创建新的本地化分支来协调翻译工作。 - `@kubernetes/website-milestone-maintainers` 成员可以使用 `/milestone` [Prow 命令](https://prow.k8s.io/command-help)为 issues 或 PR 设定里程碑。 ### 配置工作流程 {#configure-the-workflow} @@ -247,15 +274,16 @@ For an example of adding a label, see the PR for adding the [Italian language la 有关添加标签的示例，请参见添加[意大利语标签](https://github.com/kubernetes/test-infra/pull/11316)的 PR。 -你还可以在 `kubernetes/community` 仓库中为你的本地化创建一个 Slack 频道。 -有关添加 Slack 频道的示例，请参见[为印尼语和葡萄牙语添加频道](https://github.com/kubernetes/community/pull/3605)的 PR。 - ### 修改站点配置 {#configure-the-workflow} @@ -271,25 +299,36 @@ Kubernetes 网站使用 Hugo 作为其 Web 框架。网站的 Hugo 配置位于 title = "Kubernetes" description = "Produktionsreife Container-Verwaltung" languageName = "Deutsch (German)" -languageNameLatinScript = "German" +languageNameLatinScript = "Deutsch" contentDir = "content/de" weight = 8 ``` -`languageName` 的值将列在语言选择栏中。 +语言选择栏列出了 `languageName` 的值。 将 `languageName` 赋值为“本地脚本中的语言名称（拉丁脚本中的语言名称）”。 -例如，`languageName = "한국어 (Korean)"`。 +例如，`languageName = "한국어 (Korean)"` 或 `languageName = "Deutsch (German)"`。 + `languageNameLatinScript` 可用于访问拉丁脚本中的语言名称并在主题中使用。 将 `languageNameLatinScript` 赋值为“拉丁脚本中的语言名称”。 -例如，`languageNameLatinScript ="Korean"`。 +例如，`languageNameLatinScript ="Korean"` 或 `languageNameLatinScript = "Deutsch"`。 为你的语言块分配一个 `weight` 参数时，找到权重最高的语言块并将其加 1。 @@ -298,7 +337,9 @@ For more information about Hugo's multilingual support, see "[Multilingual Mode] ### 添加一个新的本地化目录 {#add-a-new-localization-directory} @@ -333,46 +374,52 @@ For example, for German the strings live in `data/i18n/de/de.toml`, and ### 本地化社区行为准则 {#localize-the-community-code-of-conduct} -在 [`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages) +在 [`cncf/foundation`](https://github.com/cncf/foundation/tree/main/code-of-conduct-languages) 仓库提交 PR，添加你所用语言版本的行为准则。 ### 设置 OWNERS 文件 {#setting-up-the-owners-files} 要设置每个对本地化做出贡献用户的角色，请在特定于语言的子目录内创建一个 `OWNERS` 文件，其中： -- **reviewers**: 具有评审人角色的 kubernetes 团队的列表，在本例中为在 - [在 GitHub 中添加你的本地化团队](#add-your-localization-team-in-github) - 中创建的 `sig-docs-**-reviews` 团队。 -- **approvers**: 具有批准人角色的 kubernetes 团队的列表，在本例中为在 - [在 GitHub 中添加你的本地化团队](#add-your-localization-team-in-github) - 中创建的 `sig-docs-**-owners` 团队。 -- **labels**: 可以自动应用于 PR 的 GitHub 标签列表，在本例中为 - [配置工作流程](#configure-the-workflow)中创建的语言标签。 +- **reviewers**: 具有评审人角色的 kubernetes 团队的列表， + 在本例中为在[在 GitHub 中添加你的本地化团队](#add-your-localization-team-in-github)中创建的 + `sig-docs-**-reviews` 团队。 +- **approvers**: 具有批准人角色的 kubernetes 团队的列表， + 在本例中为在[在 GitHub 中添加你的本地化团队](#add-your-localization-team-in-github)中创建的 + `sig-docs-**-owners` 团队。 +- **labels**: 可以自动应用于 PR 的 GitHub 标签列表， + 在本例中为[配置工作流程](#configure-the-workflow)中创建的语言标签。 -有关 `OWNERS` 文件的更多信息，请访问[go.k8s.io/owners](https://go.k8s.io/owners)。 +有关 `OWNERS` 文件的更多信息，请访问 [go.k8s.io/owners](https://go.k8s.io/owners)。 语言代码为 `es` 的[西班牙语 OWNERS 文件](https://git.k8s.io/website/content/es/OWNERS)看起来像： - ```yaml # See the OWNERS docs at https://go.k8s.io/owners @@ -390,9 +437,14 @@ labels: ``` 添加了特定语言的 OWNERS 文件之后，使用新的 Kubernetes 本地化团队、 `sig-docs-**-owners` 和 `sig-docs-**-reviews` 列表更新 @@ -425,28 +477,34 @@ For each team, add the list of GitHub users requested in [Add your localization -### 打开拉取请求 {#open-a-pull-request} +### 发起拉取请求 {#open-a-pull-request} -接下来，[打开拉取请求](/zh-cn/docs/contribute/new-content/open-a-pr/#open-a-pr)（PR） +接下来，[发起拉取请求](/zh-cn/docs/contribute/new-content/open-a-pr/#open-a-pr)（PR） 将本地化添加到 `kubernetes/website` 存储库。 - PR 必须包含所有[最低要求内容](#minimum-required-content)才能获得批准。 有关添加新本地化的示例， -请参阅 PR 以启用[法语文档](https://github.com/kubernetes/website/pull/12548)。 +请参阅启用[法语文档](https://github.com/kubernetes/website/pull/12548)的 PR。 创建本地化的 README 文件后，请在英语版文件 `README.md` 中添加指向该文件的链接， 并给出英文形式的联系信息。你可以提供 GitHub ID、电子邮件地址、 @@ -472,27 +534,31 @@ After you create the localized README, add a link to the file from the main Engl ### 启动你的新本地化 {#add-a-localized-readme-file} 一旦本地化满足工作流程和最小输出的要求，SIG Docs 将： - 在网站上启用语言选择 -- 通过[云原生计算基金会](https://www.cncf.io/about/)（CNCF）渠道， - 包括 [Kubernetes 博客](https://kubernetes.io/blog/)，来宣传本地化的可用性。 +- 通过[云原生计算基金会](https://www.cncf.io/about/)（CNCF）渠道以及 + [Kubernetes 博客](https://kubernetes.io/zh-cn/blog/)来宣传本地化的可用性。 ## 翻译文档 {#translating-content} -本地化*所有* Kubernetes 文档是一项艰巨的任务。从小做起，循序渐进。 +本地化**所有** Kubernetes 文档是一项艰巨的任务。从小做起，循序渐进。 描述 | 网址 @@ -517,14 +583,17 @@ Releases | [All heading and subheading URLs](/releases) 主页 | [所有标题和副标题网址](/zh-cn/docs/home/) 安装 | [所有标题和副标题网址](/zh-cn/docs/setup/) 教程 | [Kubernetes 基础](/zh-cn/docs/tutorials/kubernetes-basics/), [Hello Minikube](/zh-cn/docs/tutorials/hello-minikube/) -网站字符串 | [所有网站字符串](#Site-strings-in-i18n) -发行版本 | [所有标题和副标题 URL](/releases) +网站字符串 | [所有网站字符串](#site-strings-in-i18n) +发行版本 | [所有标题和副标题 URL](/zh-cn/releases) 翻译后的文档必须保存在自己的 `content/**/` 子目录中，否则将遵循与英文源相同的 URL 路径。 -例如，要准备将 [Kubernetes 基础](/zh-cn/docs/tutorials/kubernetes-basics/) 教程翻译为德语， +例如，要准备将 [Kubernetes 基础](/zh-cn/docs/tutorials/kubernetes-basics/)教程翻译为德语， 请在 `content/de/` 文件夹下创建一个子文件夹并复制英文源： ```shell @@ -533,44 +602,51 @@ cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kube ``` 翻译工具可以加快翻译过程。例如，某些编辑器提供了用于快速翻译文本的插件。 +{{< caution >}} -{{< caution >}} 机器生成的翻译本身是不够的，本地化需要广泛的人工审核才能满足最低质量标准。 {{< /caution >}} 为了确保语法和含义的准确性，本地化团队的成员应在发布之前仔细检查所有由机器生成的翻译。 ### 源文件 {#source-files} 本地化必须基于本地化团队所针对的特定发行版本中的英文文件。 -每个本地化团队可以决定要针对哪个发行版本，在下文中称作目标版本（target version）。 +每个本地化团队可以决定要针对哪个发行版本，在下文中称作 **目标版本（target version）**。 要查找你的目标版本的源文件： @@ -590,9 +666,13 @@ The `main` branch holds content for the current release `{{< latest-version >}}` ### i18n/ 中的网站字符串 {#site-strings-in-i18n} @@ -608,12 +688,12 @@ cp data/i18n/en/en.toml data/i18n/de/de.toml ``` -修改文件顶部的注释以适合你的本地化， -然后翻译每个字符串的值。例如，这是搜索表单的德语占位符文本： +修改文件顶部的注释以适合你的本地化，然后翻译每个字符串的值。 +例如，这是搜索表单的德语占位符文本： ```toml [ui_search_placeholder] @@ -621,27 +701,33 @@ other = "Suchen" ``` -本地化网站字符串允许你自定义网站范围的文本和特性：例如，每个页面页脚中的合法版权文本。 +本地化网站字符串允许你自定义网站范围的文本和特性：例如每个页面页脚中的版权声明文本。 -### 特定语言的样式指南和词汇表 {#language-specific-style-guide-and-glossary} +### 特定语言的本地化指南 {#language-specific-localization-guide} -一些语言团队有自己的特定语言样式指南和词汇表。 -例如，请参见[中文本地化指南](/zh-cn/docs/contribute/localization_zh/)。 +作为本地化团队，你可以通过创建特定语言的本地化指南来正式确定团队需遵循的最佳实践。 +请参见[中文本地化指南](/zh-cn/docs/contribute/localization_zh/)。 ### 特定语言的 Zoom 会议 {#language-specific-zoom-meetings} @@ -664,24 +750,32 @@ To collaborate on a localization branch: --> ### 分支策略 {#branching-strategy} -因为本地化项目是高度协同的工作，所以我们鼓励团队基于共享的本地化分支工作。 -- 特别是在开始并且本地化尚未生效时。 +因为本地化项目是高度协同的工作， +特别是在刚开始本地化并且本地化尚未生效时，我们鼓励团队基于共享的本地化分支工作。 在本地化分支上协作需要： 1. [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) 中的团队成员从 https://github.com/kubernetes/website 原有分支新建一个本地化分支。 + 当你给 `kubernetes/org` 仓库[添加你的本地化团队](#add-your-localization-team-in-github)时， 你的团队批准人便加入了 `@kubernetes/website-maintainers` 团队。 @@ -693,17 +787,22 @@ To collaborate on a localization branch: 直接新建了 kubernetes/website 仓库的本地化分支 `dev-1.12-de.1`。 -2. 个人贡献者基于本地化分支创建新的特性分支 +2. 个人贡献者基于本地化分支创建新的特性分支。 - 例如，一个德语贡献者新建了一个拉取请求，并将 `username:local-branch-name` 更改为 `kubernetes:dev-1.12-de.1`。 + 例如，一个德语贡献者新建了一个拉取请求， + 并将 `username:local-branch-name` 更改为 `kubernetes:dev-1.12-de.1`。 3. 批准人审查功能分支并将其合并到本地化分支中。 @@ -711,55 +810,74 @@ To collaborate on a localization branch: 在批准 PR 之前，请确保先 squash commits。 根据需要重复步骤 1-4，直到完成本地化工作。例如，随后的德语本地化分支将是： -`dev-1.12-de.2`、`dev-1.12-de.3`，等等。 +`dev-1.12-de.2`、`dev-1.12-de.3` 等等。 -团队必须将本地化内容合入到发布分支中，该发布分支是内容的来源。 - -例如： +团队必须将本地化内容合入到发布分支中，该发布分支是内容的来源。例如： - 源于 `main` 分支的本地化分支必须被合并到 `main`。 - 源于 `release-{{ skew "prevMinorVersion" }}` 的本地化分支必须被合并到 `release-{{ skew "prevMinorVersion" }}`。 -如果你的本地化分支是基于 `main` 分支创建的，但最终没有在新的发行 -分支 `{{< release-branch >}}` 被创建之前合并到 `main` 中，需要将其 -同时将其合并到 `main` 和新的发行分支 `{{< release-branch >}}` 中。 -要将本地化分支合并到新的发行分支 `{{< release-branch >}}` 中，你需要 -将你本地化分支的上游分支切换到 `{{< release-branch >}}`。 +{{< note >}} + +如果你的本地化分支是基于 `main` 分支创建的，但最终没有在新的发行分支 +`{{< release-branch >}}` 被创建之前合并到 `main` 中，需要将其同时将其合并到 +`main` 和新的发行分支 `{{< release-branch >}}` 中。 +要将本地化分支合并到新的发行分支 `{{< release-branch >}}` 中， +你需要将你本地化分支的上游分支切换到 `{{< release-branch >}}`。 +{{< /note >}} -在团队每个里程碑的开始时段，创建一个 issue 来比较先前的本地化分支 -和当前的本地化分支之间的上游变化很有帮助。 +在团队每个里程碑的开始时段，创建一个 issue +来比较先前的本地化分支和当前的本地化分支之间的上游变化很有帮助。 现在有两个脚本用来比较上游的变化。 -[`upstream_changes.py`](https://github.com/kubernetes/website/tree/main/scripts#upstream_changespy) -对于检查对某个文件的变更很有用。 -[`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/main/scripts#diff_l10n_branchespy) -可以用来为某个特定本地化分支创建过时文件的列表。 -虽然只有批准人才能创建新的本地化分支并合并 PR，任何人都可以 -为新的本地化分支提交一个拉取请求（PR）。不需要特殊权限。 +- [`upstream_changes.py`](https://github.com/kubernetes/website/tree/main/scripts#upstream_changespy) + 对于检查对某个文件的变更很有用。 +- [`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/main/scripts#diff_l10n_branchespy) + 可以用来为某个特定本地化分支创建过时文件的列表。 + +虽然只有批准人才能创建新的本地化分支并合并 PR， +任何人都可以为新的本地化分支提交一个拉取请求（PR）。不需要特殊权限。 有关基于派生或直接从仓库开展工作的更多信息，请参见 ["派生和克隆"](#fork-and-clone-the-repo)。 diff --git a/content/zh-cn/docs/contribute/new-content/blogs-case-studies.md b/content/zh-cn/docs/contribute/new-content/blogs-case-studies.md index dfad5664206b0..f14369737242f 100644 --- a/content/zh-cn/docs/contribute/new-content/blogs-case-studies.md +++ b/content/zh-cn/docs/contribute/new-content/blogs-case-studies.md @@ -26,9 +26,10 @@ Case studies require extensive review before they're approved. @@ -45,8 +46,8 @@ Kubernetes 博客用于项目发布新功能特性、 - 不合适的博客内容包括： - 供应商产品推介 @@ -86,12 +86,17 @@ Unsuitable content includes: 要提交博文，你可以遵从以下步骤： @@ -110,9 +115,16 @@ To submit a blog post, follow these steps: ### Guidelines and expectations - Blog posts should not be vendor pitches. - - Articles must contain content that applies broadly to the Kubernetes community. For example, a submission should focus on upstream Kubernetes as opposed to vendor-specific configurations. Check the [Documentation style guide](/docs/contribute/style/content-guide/#what-s-allowed) for what is typically allowed on Kubernetes properties. - - Links should primarily be to the official Kubernetes documentation. When using external references, links should be diverse - For example a submission shouldn't contain only links back to a single company's blog. - - Sometimes this is a delicate balance. The [blog team](https://kubernetes.slack.com/messages/sig-docs-blog/) is there to give guidance on whether a post is appropriate for the Kubernetes blog, so don't hesitate to reach out. + - Articles must contain content that applies broadly to the Kubernetes community. For example, a + submission should focus on upstream Kubernetes as opposed to vendor-specific configurations. + Check the [Documentation style guide](/docs/contribute/style/content-guide/#what-s-allowed) for + what is typically allowed on Kubernetes properties. + - Links should primarily be to the official Kubernetes documentation. When using external + references, links should be diverse - For example a submission shouldn't contain only links + back to a single company's blog. + - Sometimes this is a delicate balance. The [blog team](https://kubernetes.slack.com/messages/sig-docs-blog/) + is there to give guidance on whether a post is appropriate for the Kubernetes blog, so don't + hesitate to reach out. --> ### 指导原则和期望 {#guidelines-and-expectations} @@ -130,9 +142,12 @@ To submit a blog post, follow these steps: 所以，需要帮助的时候不要犹豫。 - 博客内容应该对 Kubernetes 用户有用。 - 与参与 Kubernetes SIG 活动相关，或者与这类活动的结果相关的主题通常是切题的。 - 请参考[上游推广团队](https://github.com/kubernetes/community/blob/master/communication/marketing-team/storytelling-resources/blog-guidelines.md#upstream-marketing-blog-guidelines)的工作以获得对此类博文的支持。 - - Kubernetes 的组件都有意设计得模块化，因此使用类似 CNI、CSI 等集成点的工具 - 通常都是切题的。 + 请参考 [贡献者沟通（Contributor Comms）团队](https://github.com/kubernetes/community/blob/master/communication/contributor-comms/storytelling-resources/blog-guidelines.md#upstream-marketing-blog-guidelines)的工作以获得对此类博文的支持。 + - Kubernetes 的组件都有意设计得模块化，因此使用类似 CNI、CSI 等集成点的工具通常都是切题的。 - 关于其他 CNCF 项目的博客可能切题也可能不切题。 我们建议你在提交草稿之前与博客团队联系。 - 很多 CNCF 项目有自己的博客。这些博客通常是更好的选择。 @@ -172,9 +192,11 @@ To submit a blog post, follow these steps: ### 提交博客的技术考虑 {#technical-consideration-for-submitting-a-blog-post} @@ -207,22 +233,30 @@ We recognize that this requirement makes the process more difficult for less-fam 如果你有降低难度的好主意，请自荐帮忙。 -SIG Docs [博客子项目](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) 负责管理博客的评阅过程。 +SIG Docs +[博客子项目](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject)负责管博客的评阅过程。 更多信息可参考[提交博文](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post)。 要提交博文，你可以遵从以下指南： - [发起一个包含新博文的 PR](/zh-cn/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 @@ -244,18 +278,25 @@ SIG Docs [博客子项目](https://github.com/kubernetes/community/tree/master/s slug: text-for-URL-link-here-no-spaces --- ``` - + + - The blog team will then review your PR and give you comments on things you might need to fix. + After that the bot will merge your PR and your blog post will be published. + --> + - 第一个或者最初的提交的描述信息中应该包含一个所作工作的简单摘要， 并作为整个博文的一个独立描述。 请注意，对博文的后续修改编辑都会最终合并到此主提交中，所以此提交的描述信息 @@ -271,8 +312,14 @@ SIG Docs [博客子项目](https://github.com/kubernetes/community/tree/master/s - 博客团队会对 PR 内容进行评阅，为你提供一些评语以便修订。 之后，机器人会将你的博文合并并发表。 - + --> - 如果博文的内容仅包含预期无需更新就能对读者保持精准的内容， 则可以将这篇博文标记为长期有效（evergreen）， @@ -299,13 +346,15 @@ SIG Docs [博客子项目](https://github.com/kubernetes/community/tree/master/s ## 提交案例分析 {#submit-a-case-study} diff --git a/content/zh-cn/docs/reference/access-authn-authz/admission-controllers.md b/content/zh-cn/docs/reference/access-authn-authz/admission-controllers.md index ee739723c5678..d32fbd4a9e7bd 100644 --- a/content/zh-cn/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/zh-cn/docs/reference/access-authn-authz/admission-controllers.md @@ -1,5 +1,6 @@ --- -title: 使用准入控制器 +title: 准入控制器参考 +linkTitle: 准入控制器 content_type: concept weight: 30 --- @@ -12,7 +13,8 @@ reviewers: - erictune - janetkuo - thockin -title: Using Admission Controllers +title: Admission Controllers Reference +linkTitle: Admission Controllers content_type: concept weight: 30 --> @@ -31,9 +33,30 @@ This page provides an overview of Admission Controllers. ## 什么是准入控制插件？ {#what-are-they} +**准入控制器** 是一段代码，它会在请求通过认证和鉴权之后、对象被持久化之前拦截到达 API +服务器的请求。 + +准入控制器可以执行**验证（Validating）** 和/或**变更（Mutating）** 操作。 +变更（mutating）控制器可以根据被其接受的请求更改相关对象；验证（validating）控制器则不行。 + +准入控制器限制创建、删除、修改对象的请求。 +准入控制器也可以阻止自定义动作，例如通过 API 服务器代理连接到 Pod 的请求。 +准入控制器**不会** （也不能）阻止读取（**get**、**watch** 或 **list**）对象的请求。 + + -准入控制器是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API -服务器的请求。控制器由下面的[列表](#what-does-each-admission-controller-do)组成， +Kubernetes {{< skew currentVersion >}} +中的准入控制器由下面的[列表](#what-does-each-admission-controller-do)组成， 并编译进 `kube-apiserver` 可执行文件，并且只能由集群管理员配置。 在该列表中，有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。 -它们根据 API 中的配置，分别执行变更和验证 -[准入控制 webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 +它们根据 API 中的配置， +分别执行变更和验证[准入控制 webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 -准入控制器可以执行 “验证（Validating）” 和/或 “变更（Mutating）” 操作。 -变更（mutating）控制器可以根据被其接受的请求更改相关对象；验证（validating）控制器则不行。 - -准入控制器限制创建、删除、修改对象或连接到代理的请求，不限制读取对象的请求。 +## 准入控制阶段 {#admission-control-phases} 准入控制过程分为两个阶段。第一阶段，运行变更准入控制器。第二阶段，运行验证准入控制器。 再次提醒，某些控制器既是变更准入控制器又是验证准入控制器。 @@ -89,20 +106,19 @@ other admission controllers. ## 为什么需要准入控制器？ {#why-do-i-need-them} -Kubernetes 的许多高级功能都要求启用一个准入控制器，以便正确地支持该特性。 +Kubernetes 的若干重要功能都要求启用一个准入控制器，以便正确地支持该特性。 因此，没有正确配置准入控制器的 Kubernetes API 服务器是不完整的，它无法支持你所期望的所有特性。 -在目前版本中，默认启用的插件有： +在 Kubernetes {{< skew currentVersion >}} 中，默认启用的插件有： ```shell CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, LimitRanger, MutatingAdmissionWebhook, NamespaceLifecycle, PersistentVolumeClaimResize, PodSecurity, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook @@ -177,24 +193,24 @@ CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultI {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} -该准入控制器允许所有的 Pod 进入集群。此插件已被弃用，因其行为与没有准入控制器一样。 +该准入控制器允许所有的 Pod 进入集群。此插件**已被弃用**，因其行为与没有准入控制器一样。 ### AlwaysDeny {#alwaysdeny} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} -拒绝所有的请求。由于它没有实际意义，已被弃用。 +拒绝所有的请求。由于它没有实际意义，**已被弃用**。 ### AlwaysPullImages {#alwayspullimages} -该准入控制器会修改每个新创建的 Pod，将其镜像拉取策略设置为 Always。 +该准入控制器会修改每个新创建的 Pod，将其镜像拉取策略设置为 `Always`。 这在多租户集群中是有用的，这样用户就可以放心，他们的私有镜像只能被那些有凭证的人使用。 如果没有这个准入控制器，一旦镜像被拉取到节点上，任何用户的 Pod 都可以通过已了解到的镜像的名称 （假设 Pod 被调度到正确的节点上）来使用它，而不需要对镜像进行任何鉴权检查。 @@ -211,13 +227,13 @@ required. ### CertificateApproval {#certificateapproval} -此准入控制器获取“审批” CertificateSigningRequest 资源的请求并执行额外的鉴权检查， +此准入控制器获取审批 CertificateSigningRequest 资源的请求并执行额外的鉴权检查， 以确保针对设置了 `spec.signerName` 的 CertificateSigningRequest 资源而言， -审批请求的用户有权限对证书请求执行 `approve` 操作。 +审批请求的用户有权限对证书请求执行 **审批** 操作。 此准入控制器监视对 CertificateSigningRequest 资源的 `status.certificate` 字段的更新请求， 并执行额外的鉴权检查，以确保针对设置了 `spec.signerName` 的 CertificateSigningRequest 资源而言， -签发证书的用户有权限对证书请求执行 `sign` 操作。 +签发证书的用户有权限对证书请求执行 **签发** 操作。 关于 Ingress 类以及如何将 Ingress 类标记为默认的更多信息，请参见 @@ -320,7 +336,7 @@ storage classes and how to mark a storage class as default. -此准入控制器缓解了事件请求淹没 API 服务器的问题。集群管理员可以通过以下方式指定事件速率限制： +此准入控制器缓解了请求存储新事件时淹没 API 服务器的问题。集群管理员可以通过以下方式指定事件速率限制： -* `Server`: API 服务器收到的所有事件请求共享一个桶。 -* `Namespace`: 每个名字空间都对应一个专用的桶。 -* `User`: 为每个用户分配一个桶。 -* `SourceAndObject`: 根据事件的来源和涉及对象的各种组合分配桶。 +* `Server`：API 服务器收到的所有（创建或修改）Event 请求共享一个桶。 +* `Namespace`：每个名字空间都对应一个专用的桶。 +* `User`：为每个用户分配一个桶。 +* `SourceAndObject`：根据事件的来源和涉及对象的各种组合分配桶。 -#### 配置文件格式 {#configuration-file-format} +#### 配置文件格式 {#imagereview-config-file-format} ImagePolicyWebhook 使用配置文件来为后端行为设置选项。该文件可以是 JSON 或 YAML， 并具有以下格式: @@ -638,11 +654,11 @@ An example request body: ``` -远程服务将填充请求的 `ImageReviewStatus` 字段，并返回允许或不允许访问的响应。 +远程服务将填充请求的 `status` 字段，并返回允许或不允许访问的响应。 响应体的 `spec` 字段会被忽略，并且可以被省略。一个允许访问应答会返回： ```json @@ -904,15 +920,15 @@ permissions required to operate correctly. 此准入控制器保护对对象的 `metadata.ownerReferences` 的访问，以便只有对该对象具有 -“delete” 权限的用户才能对其进行更改。 +**delete** 权限的用户才能对其进行更改。 该准入控制器还保护对 `metadata.ownerReferences[x].blockOwnerDeletion` 对象的访问， -以便只有对所引用的 **属主（owner）** 的 `finalizers` 子资源具有 “update” +以便只有对所引用的 **属主（owner）** 的 `finalizers` 子资源具有 **update** 权限的用户才能对其进行更改。 ### PersistentVolumeClaimResize {#persistentvolumeclaimresize} @@ -964,21 +980,21 @@ For more information about persistent volume claims, see [PersistentVolumeClaims -此准入控制器会自动将由云提供商（如 GCE、AWS）定义的区（region）或区域（zone） +此准入控制器会自动将由云提供商（如 Azure 或 GCP）定义的区（region）或区域（zone） 标签附加到 PersistentVolume 上。这有助于确保 Pod 和 PersistentVolume 位于相同的区或区域。 如果准入控制器不支持为 PersistentVolumes 自动添加标签，那你可能需要手动添加标签， 以防止 Pod 挂载其他区域的卷。 -PersistentVolumeLabel 已被弃用， +PersistentVolumeLabel **已被弃用**， 为持久卷添加标签的操作已由{{< glossary_tooltip text="云管理控制器" term_id="cloud-controller-manager" >}}接管。 此准入控制器默认被禁用。 @@ -1265,13 +1281,14 @@ pod privileges. 此准入控制器实现了 [ServiceAccount](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/) -的自动化。 -如果你打算使用 Kubernetes 的 ServiceAccount 对象，我们强烈建议你使用这个准入控制器。 +的自动化。强烈推荐为 Kubernetes 项目启用此准入控制器。 +如果你打算使用 Kubernetes 的 `ServiceAccount` 对象，你应启用这个准入控制器。 ### StorageObjectInUseProtection {#storageobjectinuseprotection} @@ -1298,7 +1315,8 @@ Nodes as `NotReady` and `NoSchedule`. That tainting avoids a race condition that to be scheduled on new Nodes before their taints were updated to accurately reflect their reported conditions. --> -该准入控制器为新创建的节点添加 `NotReady` 和 `NoSchedule` {{< glossary_tooltip text="污点" term_id="taint" >}}。 +该准入控制器为新创建的节点添加 `NotReady` 和 `NoSchedule` +{{< glossary_tooltip text="污点" term_id="taint" >}}。 这些污点能够避免一些竞态条件的发生，而这类竞态条件可能导致 Pod 在更新节点污点以准确反映其所报告状况之前，就被调度到新节点上。 @@ -1340,7 +1358,7 @@ so you do not need to explicitly specify them. You can enable additional admission controllers beyond the default set using the `--enable-admission-plugins` flag (**order doesn't matter**). --> -## 有推荐的准入控制器吗？ +## 有推荐的准入控制器吗？ {#is-there-a-recommended-set-of-admission-controllers-to-use} 有。推荐使用的准入控制器默认情况下都处于启用状态 （请查看[这里](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/#options)）。 diff --git a/content/zh-cn/docs/reference/access-authn-authz/authentication.md b/content/zh-cn/docs/reference/access-authn-authz/authentication.md index 954adeb10ce13..12b16a784a85e 100644 --- a/content/zh-cn/docs/reference/access-authn-authz/authentication.md +++ b/content/zh-cn/docs/reference/access-authn-authz/authentication.md @@ -187,7 +187,7 @@ This would create a CSR for the username "jbeda", belonging to two groups, "app1 See [Managing Certificates](/docs/tasks/administer-cluster/certificates/) for how to generate a client cert. --> -此命令将使用用户名 `jbeda` 生成一个证书签名请求（CSR），且该用户属于 "app" 和 +此命令将使用用户名 `jbeda` 生成一个证书签名请求（CSR），且该用户属于 "app1" 和 "app2" 两个用户组。 参阅[管理证书](/zh-cn/docs/tasks/administer-cluster/certificates/)了解如何生成客户端证书。 diff --git a/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates.md b/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates.md index 9fe2898138e4a..0476ef1efed2a 100644 --- a/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates.md @@ -307,7 +307,7 @@ For a reference to old feature gates that are removed, please refer to | `DefaultPodTopologySpread` | `true` | GA | 1.24 | - | | `DisableAcceleratorUsageMetrics` | `false` | Alpha | 1.19 | 1.19 | | `DisableAcceleratorUsageMetrics` | `true` | Beta | 1.20 | 1.24 | -| `DisableAcceleratorUsageMetrics` | `true` | Beta | 1.25 |- | +| `DisableAcceleratorUsageMetrics` | `true` | GA | 1.25 |- | | `DryRun` | `false` | Alpha | 1.12 | 1.12 | | `DryRun` | `true` | Beta | 1.13 | 1.18 | | `DryRun` | `true` | GA | 1.19 | - | @@ -478,8 +478,7 @@ Each feature gate is designed for enabling/disabling a specific feature: - `APIResponseCompression`: Compress the API responses for `LIST` or `GET` requests. - `APIServerIdentity`: Assign each API server an ID in a cluster. - `APIServerTracing`: Add support for distributed tracing in the API server. - See [Traces for Kubernetes System Components](/docs/concepts/cluster-administration/system-traces) - for more details. + See [Traces for Kubernetes System Components](/docs/concepts/cluster-administration/system-traces) for more details. --> - `APIListChunking`：启用 API 客户端以块的形式从 API 服务器检索（“LIST” 或 “GET”）资源。 - `APIPriorityAndFairness`：在每个服务器上启用优先级和公平性来管理请求并发（由 `RequestManagement` 重命名而来）。 @@ -947,8 +946,7 @@ Each feature gate is designed for enabling/disabling a specific feature: - `KubeletTracing`: Add support for distributed tracing in the kubelet. When enabled, kubelet CRI interface and authenticated http servers are instrumented to generate OpenTelemetry trace spans. - See [Traces for Kubernetes System Components](/docs/concepts/cluster-administration/system-traces) - for more details. + See [Traces for Kubernetes System Components](/docs/concepts/cluster-administration/system-traces) for more details. - `LegacyServiceAccountTokenNoAutoGeneration`: Stop auto-generation of Secret-based [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens). --> diff --git a/content/zh-cn/docs/setup/best-practices/certificates.md b/content/zh-cn/docs/setup/best-practices/certificates.md index 7b7b6a669ba51..dc16edc9ee2fe 100644 --- a/content/zh-cn/docs/setup/best-practices/certificates.md +++ b/content/zh-cn/docs/setup/best-practices/certificates.md @@ -1,14 +1,14 @@ --- title: PKI 证书和要求 content_type: concept -weight: 40 +weight: 50 --- @@ -54,17 +54,17 @@ Kubernetes 需要 PKI 才能执行以下操作： * 集群管理员的客户端证书，用于 API 服务器身份认证 * API 服务器的客户端证书，用于和 Kubelet 的会话 * API 服务器的客户端证书，用于和 etcd 的会话 -* 控制器管理器的客户端证书/kubeconfig，用于和 API 服务器的会话 -* 调度器的客户端证书/kubeconfig，用于和 API 服务器的会话 -* [前端代理](/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 的客户端及服务端证书 +* 控制器管理器的客户端证书或 kubeconfig，用于和 API 服务器的会话 +* 调度器的客户端证书或 kubeconfig，用于和 API 服务器的会话 +* [前端代理](/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/)的客户端及服务端证书 +{{< note >}} -{{< note >}} -只有当你运行 kube-proxy 并要支持 -[扩展 API 服务器](/zh-cn/docs/tasks/extend-kubernetes/setup-extension-api-server/) -时，才需要 `front-proxy` 证书 +只有当你运行 kube-proxy +并要支持[扩展 API 服务器](/zh-cn/docs/tasks/extend-kubernetes/setup-extension-api-server/)时， +才需要 `front-proxy` 证书。 {{< /note >}} [1]: 用来连接到集群的不同 IP 或 DNS 名 （就像 [kubeadm](/zh-cn/docs/reference/setup-tools/kubeadm/) 为负载均衡所使用的固定 -IP 或 DNS 名，`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、 +IP 或 DNS 名：`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、 `kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`）。 其中，`kind` 对应一种或多种类型的 [x509 密钥用途](https://pkg.go.dev/k8s.io/api/certificates/v1beta1#KeyUsage)： @@ -216,7 +216,8 @@ For kubeadm users only: 对于 kubeadm 用户： * 不使用私钥，将证书复制到集群 CA 的方案，在 kubeadm 文档中将这种方案称为外部 CA。 -* 如果将以上列表与 kubeadm 生成的 PKI 进行比较，你会注意到，如果使用外部 etcd，则不会生成 `kube-etcd`、`kube-etcd-peer` 和 `kube-etcd-healthcheck-client` 证书。 +* 如果将以上列表与 kubeadm 生成的 PKI 进行比较，你会注意到，如果使用外部 etcd，则不会生成 + `kube-etcd`、`kube-etcd-peer` 和 `kube-etcd-healthcheck-client` 证书。 {{< /note >}} @@ -337,10 +338,10 @@ You must manually configure these administrator account and service accounts: | controller-manager.conf | default-controller-manager | system:kube-controller-manager | | | scheduler.conf | default-scheduler | system:kube-scheduler | | +{{< note >}} -{{< note >}} `kubelet.conf` 中 `` 的值 **必须** 与 kubelet 向 apiserver 注册时提供的节点名称的值完全匹配。 有关更多详细信息，请阅读[节点授权](/zh-cn/docs/reference/access-authn-authz/node/)。 {{< /note >}} diff --git a/content/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index cdf56f376d040..df6af3f768b33 100644 --- a/content/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -1,6 +1,7 @@ --- title: 配置对多集群的访问 content_type: task +weight: 30 card: name: tasks weight: 40 @@ -32,24 +33,20 @@ A file that is used to configure access to a cluster is sometimes called a *kubeconfig file*. This is a generic way of referring to configuration files. It does not mean that there is a file named `kubeconfig`. --> -用于配置集群访问的文件有时被称为 *kubeconfig 文件*。 +用于配置集群访问的文件有时被称为 **kubeconfig 文件**。 这是一种引用配置文件的通用方式，并不意味着存在一个名为 `kubeconfig` 的文件。 {{< /note >}} - - -{{< warning >}} 只使用来源可靠的 kubeconfig 文件。使用特制的 kubeconfig 文件可能会导致恶意代码执行或文件暴露。 如果必须使用不受信任的 kubeconfig 文件，请首先像检查 shell 脚本一样仔细检查它。 {{< /warning>}} - ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} @@ -62,8 +59,8 @@ cluster's API server. --> 要检查 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} 是否安装， 执行 `kubectl version --client` 命令。 -kubectl 的版本应该与集群的 API 服务器 -[使用同一次版本号](/zh-cn/releases/version-skew-policy/#kubectl)。 +kubectl 的版本应该与集群的 API +服务器[使用同一次版本号](/zh-cn/releases/version-skew-policy/#kubectl)。 @@ -138,6 +135,15 @@ Add user details to your configuration file: --> 将用户详细信息添加到配置文件中： +{{< caution >}} + +将密码保存到 Kubernetes 客户端配置中有风险。 +一个较好的替代方式是使用凭据插件并单独保存这些凭据。 +参阅 [client-go 凭据插件](/zh-cn/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins) +{{< /caution >}} + ```shell kubectl config --kubeconfig=config-demo set-credentials developer --client-certificate=fake-cert-file --client-key=fake-key-seefile kubectl config --kubeconfig=config-demo set-credentials experimenter --username=exp --password=some-password @@ -218,6 +224,10 @@ users: client-key: fake-key-file - name: experimenter user: + # 文档说明（本注释不属于命令输出）。 + # 将密码保存到 Kubernetes 客户端配置有风险。 + # 一个较好的替代方式是使用凭据插件并单独保存这些凭据。 + # 参阅 https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins password: some-password username: exp ``` @@ -320,7 +330,6 @@ listed in the `exp-scratch` context. View configuration associated with the new current context, `exp-scratch`. --> - 现在你发出的所有 `kubectl` 命令都将应用于 `scratch` 集群的默认名字空间。 同时，命令会使用 `exp-scratch` 上下文中所列用户的凭证。 @@ -358,7 +367,6 @@ kubectl config --kubeconfig=config-demo view --minify In your `config-exercise` directory, create a file named `config-demo-2` with this content: --> - ## 创建第二个配置文件 {#create-a-second-configuration-file} 在 `config-exercise` 目录中，创建名为 `config-demo-2` 的文件，其中包含以下内容： @@ -479,8 +487,8 @@ contexts: For more information about how kubeconfig files are merged, see [Organizing Cluster Access Using kubeconfig Files](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) --> -关于 kubeconfig 文件如何合并的更多信息，请参考 -[使用 kubeconfig 文件组织集群访问](/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +关于 kubeconfig 文件如何合并的更多信息， +请参考[使用 kubeconfig 文件组织集群访问](/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/) - * [使用 kubeconfig 文件组织集群访问](/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/) * [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) diff --git a/content/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md index accf8208c83d0..161e68b223f13 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md +++ b/content/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md @@ -248,16 +248,16 @@ resources: ``` {{< note >}} + -`LimitRange` **不会**去检查它所应用的默认值的一致性。这意味着由 `LimitRange` -设置的 limit 的默认值可能小于客户端提交给 API 服务器的规约中为容器指定的请求值。 -如果发生这种情况，最终的 Pod 将无法被调度。 -更多的相关信息细节，请参考[对资源限制和请求的约束](/zh-cn/docs/concepts/policy/limit-range/)。 -{{< /note >}} +`LimitRange` **不会**检查它应用的默认值的一致性。 这意味着 `LimitRange` 设置的 _limit_ 的默认值可能小于客户端提交给 +API 服务器的声明中为容器指定的 _request_ 值。如果发生这种情况，最终会导致 Pod 无法调度。更多信息， +请参阅[资源限制的 limit 和 request](/zh-cn/docs/concepts/policy/limit-range/#constraints-on-resource-limits-and-requests)。 +{{< /note >}} `YWRtaW5pc3RyYXRvcg==` 解码成 `administrator`。 + +## 编辑 Secret {#edit-secret} + +要编辑使用清单创建的 Secret 中的数据，请修改清单中的 `data` 或 `stringData` 字段并将此清单文件应用到集群。 +你可以编辑现有的 `Secret` 对象，除非它是[不可变的](/zh-cn/docs/concepts/configuration/secret/#secret-immutable)。 + +例如，如果你想将上一个示例中的密码更改为 `birdsarentreal`，请执行以下操作： + +1. 编码新密码字符串： + + ```shell + echo -n 'birdsarentreal' | base64 + ``` + + + 输出类似于： + + ``` + YmlyZHNhcmVudHJlYWw= + ``` + + +2. 使用你的新密码字符串更新 `data` 字段： + + ```yaml + apiVersion: v1 + kind: Secret + metadata: + name: mysecret + type: Opaque + data: + username: YWRtaW4= + password: YmlyZHNhcmVudHJlYWw= + ``` + + +3. 将清单应用到你的集群： + + ```shell + kubectl apply -f ./secret.yaml + ``` + + + 输出类似于： + + ``` + secret/mysecret configured + ``` + + +Kubernetes 更新现有的 `Secret` 对象。具体而言，`kubectl` 工具发现存在一个同名的现有 `Secret` 对象。 +`kubectl` 获取现有对象，计划对其进行更改，并将更改后的 `Secret` 对象提交到你的集群控制平面。 + +如果你指定了 `kubectl apply --server-side`，则 `kubectl` +使用[服务器端应用（Server-Side Apply）](/zh-cn/docs/reference/using-api/server-side-apply/)。 + @@ -273,10 +357,10 @@ kubectl delete secret mysecret - 进一步阅读 [Secret 概念](/zh-cn/docs/concepts/configuration/secret/) -- 了解如何[使用 `kubectl` 命令管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- 了解如何[使用 `kubectl` 管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kubectl/) - 了解如何[使用 kustomize 管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kustomize/) diff --git a/content/zh-cn/docs/tasks/debug/debug-cluster/local-debugging.md b/content/zh-cn/docs/tasks/debug/debug-cluster/local-debugging.md index 38845f57eecbb..8c0823cf75a72 100644 --- a/content/zh-cn/docs/tasks/debug/debug-cluster/local-debugging.md +++ b/content/zh-cn/docs/tasks/debug/debug-cluster/local-debugging.md @@ -85,7 +85,7 @@ When developing an application on Kubernetes, you typically program or debug a s 一种选择是使用连续部署流水线，但即使最快的部署流水线也会在程序或调试周期中引入延迟。 -使用 `telepresence intercept $SERVICE_NAME --port $LOCAL_PORT:REMOTE_PORT` 命令创建一个 "拦截器" 用于重新路由远程服务流量。 +使用 `telepresence intercept $SERVICE_NAME --port $LOCAL_PORT:$REMOTE_PORT` 命令创建一个 "拦截器" 用于重新路由远程服务流量。 环境变量： diff --git a/content/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer.md b/content/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer.md index 9dbe60199dc30..044fccef79933 100644 --- a/content/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer.md +++ b/content/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer.md @@ -18,27 +18,26 @@ weight: 10 -配置[聚合层](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) -可以允许 Kubernetes apiserver 使用其它 API 扩展，这些 API 不是核心 -Kubernetes API 的一部分。 +配置[聚合层](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)可以允许 +Kubernetes apiserver 使用其它 API 扩展，这些 API 不是核心 Kubernetes API 的一部分。 ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< note >}} -{{< note >}} 要使聚合层在你的环境中正常工作以支持代理服务器和扩展 apiserver 之间的相互 TLS 身份验证， 需要满足一些设置要求。Kubernetes 和 kube-apiserver 具有多个 CA， 因此请确保代理是由聚合层 CA 签名的，而不是由 Kubernetes 通用 CA 签名的。 {{< /note >}} +{{< caution >}} -{{< caution >}} 对不同的客户端类型重复使用相同的 CA 会对集群的功能产生负面影响。 有关更多信息，请参见 [CA 重用和冲突](#ca-reusage-and-conflicts)。 {{< /caution >}} @@ -52,11 +51,11 @@ Unlike Custom Resource Definitions (CRDs), the Aggregation API involves another This section describes how the authentication and authorization flows work, and how to configure them. --> -## 身份认证流程 +## 身份认证流程 {#authentication-flow} 与自定义资源定义（CRD）不同，除标准的 Kubernetes apiserver 外，Aggregation API 还涉及另一个服务器：扩展 apiserver。 -Kubernetes apiserver 将需要与你的扩展 apiserver 通信，并且你的扩展 apiserver +Kubernetes apiserver 将需要与你的扩展 apiserver 通信，并且你的扩展 apiserver 也需要与 Kubernetes apiserver 通信。 为了确保此通信的安全，Kubernetes apiserver 使用 x509 证书向扩展 apiserver 认证。 @@ -84,13 +83,15 @@ The rest of this section describes these steps in detail. The flow can be seen in the following diagram. +![aggregation auth flows](/images/docs/aggregation-api-auth-flow.png). + The source for the above swimlanes can be found in the source of this document. --> 本节的其余部分详细描述了这些步骤。 该流程可以在下图中看到。 -![聚合层认证流程](/images/docs/aggregation-api-auth-flow.png). +![聚合层认证流程](/images/docs/aggregation-api-auth-flow.png) 以上泳道的来源可以在本文档的源码中找到。 @@ -222,7 +223,7 @@ Everything to this point has been standard Kubernetes API requests, authenticati The Kubernetes apiserver now is prepared to send the request to the extension apiserver. --> -### Kubernetes Apiserver 认证和授权 +### Kubernetes Apiserver 认证和授权 {#kubernetes-apiserver-authentication-and-authorization} 由扩展 apiserver 服务的对 API 路径的请求以与所有 API 请求相同的方式开始： 与 Kubernetes apiserver 的通信。该路径已通过扩展 apiserver 在 @@ -231,10 +232,10 @@ Kubernetes apiserver 中注册。 用户与 Kubernetes apiserver 通信，请求访问路径。 Kubernetes apiserver 使用它的标准认证和授权配置来对用户认证，以及对特定路径的鉴权。 -有关对 Kubernetes 集群认证的概述，请参见 -[对集群认证](/zh-cn/docs/reference/access-authn-authz/authentication/)。 -有关对Kubernetes集群资源的访问鉴权的概述，请参见 -[鉴权概述](/zh-cn/docs/reference/access-authn-authz/authorization/)。 +有关对 Kubernetes 集群认证的概述， +请参见[对集群认证](/zh-cn/docs/reference/access-authn-authz/authentication/)。 +有关对 Kubernetes 集群资源的访问鉴权的概述， +请参见[鉴权概述](/zh-cn/docs/reference/access-authn-authz/authorization/)。 到目前为止，所有内容都是标准的 Kubernetes API 请求，认证与鉴权。 @@ -250,7 +251,7 @@ The Kubernetes apiserver now will send, or proxy, the request to the extension a In order to provide for these two, you must configure the Kubernetes apiserver using several flags. --> -### Kubernetes Apiserver 代理请求 +### Kubernetes Apiserver 代理请求 {#kubernetes-apiserver-proxies-the-request} Kubernetes apiserver 现在将请求发送或代理到注册以处理该请求的扩展 apiserver。 为此，它需要了解几件事： @@ -258,8 +259,8 @@ Kubernetes apiserver 现在将请求发送或代理到注册以处理该请求 1. Kubernetes apiserver 应该如何向扩展 apiserver 认证，以通知扩展 apiserver 通过网络发出的请求来自有效的 Kubernetes apiserver？ -2. Kubernetes apiserver 应该如何通知扩展 apiserver 原始请求 - 已通过认证的用户名和组？ +2. Kubernetes apiserver 应该如何通知扩展 apiserver + 原始请求已通过认证的用户名和组？ 为提供这两条信息，你必须使用若干标志来配置 Kubernetes apiserver。 @@ -295,12 +296,12 @@ Kubernetes apiserver 将使用由 `--proxy-client-*-file` 指示的文件来向 1. 连接必须使用由 CA 签署的客户端证书，该证书的证书位于 `--requestheader-client-ca-file` 中。 2. 连接必须使用客户端证书，该客户端证书的 CN 是 `--requestheader-allowed-names` 中列出的证书之一。 +{{< note >}} -{{< note >}} 你可以将此选项设置为空白，即为`--requestheader-allowed-names=""`。 -这将向扩展 apiserver 指示**任何** CN 是可接受的。 +这将向扩展 apiserver 指示**任何** CN 都是可接受的。 {{< /note >}} -### 扩展 Apiserver 认证 +### 扩展 Apiserver 认证请求 {#extension-apiserver-authenticates-the-request} 扩展 apiserver 在收到来自 Kubernetes apiserver 的代理请求后， 必须验证该请求确实确实来自有效的身份验证代理， 该认证代理由 Kubernetes apiserver 履行。扩展 apiserver 通过以下方式对其认证： -1. 如上所述，从`kube-system`中的 configmap 中检索以下内容： +1. 如上所述，从 `kube-system` 中的 ConfigMap 中检索以下内容： * 客户端 CA 证书 * 允许名称（CN）列表 @@ -379,7 +380,7 @@ The extension apiserver, upon receiving a proxied request from the Kubernetes ap * 由其证书与检索到的 CA 证书匹配的 CA 签名。 * 在允许的 CN 列表中有一个 CN，除非列表为空，在这种情况下允许所有 CN。 - * 从适当的头部中提取用户名和组 + * 从适当的头部中提取用户名和组。 -### 扩展 Apiserver 对请求鉴权 +### 扩展 Apiserver 对请求鉴权 {#extensions-apiserver-authorizes-the-request} 扩展 apiserver 现在可以验证从标头检索的`user/group`是否有权执行给定请求。 通过向 Kubernetes apiserver 发送标准 @@ -426,7 +427,7 @@ If the `SubjectAccessReview` passes, the extension apiserver executes the reques Enable the aggregation layer via the following `kube-apiserver` flags. They may have already been taken care of by your provider. --> -### 扩展 Apiserver 执行 +### 扩展 Apiserver 执行 {#enable-kubernetes-apiserver-flags} 如果 `SubjectAccessReview` 通过，则扩展 apiserver 执行请求。 @@ -450,7 +451,7 @@ Enable the aggregation layer via the following `kube-apiserver` flags. They may The Kubernetes apiserver has two client CA options: --> -### CA-重用和冲突 {#ca-reusage-and-conflicts} +### CA 重用和冲突 {#ca-reusage-and-conflicts} Kubernetes apiserver 有两个客户端 CA 选项： @@ -468,7 +469,7 @@ Each of these functions independently and can conflict with each other, if not u * `--client-ca-file`：当请求到达 Kubernetes apiserver 时，如果启用了此选项， 则 Kubernetes apiserver 会检查请求的证书。 如果它是由 `--client-ca-file` 引用的文件中的 CA 证书之一签名的， - 并且用户是公用名`CN=`的值，而组是组织`O=` 的取值，则该请求被视为合法请求。 + 并且用户是公用名 `CN=` 的值，而组是组织 `O=` 的取值，则该请求被视为合法请求。 请参阅[关于 TLS 身份验证的文档](/zh-cn/docs/reference/access-authn-authz/authentication/#x509-client-certs)。 * `--requestheader-client-ca-file`：当请求到达 Kubernetes apiserver 时， @@ -485,7 +486,7 @@ If _both_ `--client-ca-file` and `--requestheader-client-ca-file` are provided, For this reason, use different CA certs for the `--client-ca-file` option - to authorize control plane components and end-users - and the `--requestheader-client-ca-file` option - to authorize aggregation apiserver requests. --> 如果同时提供了 `--client-ca-file` 和 `--requestheader-client-ca-file`， -则首先检查 `--requestheader-client-ca-file` CA，然后再检查`--client-ca-file`。 +则首先检查 `--requestheader-client-ca-file` CA，然后再检查 `--client-ca-file`。 通常，这些选项中的每一个都使用不同的 CA（根 CA 或中间 CA）。 常规客户端请求与 `--client-ca-file` 相匹配，而聚合请求要与 `--requestheader-client-ca-file` 相匹配。 @@ -500,11 +501,11 @@ apiserver 认证。 用于聚合 apiserver 鉴权的 `--requestheader-client-ca-file` 选项使用 不同的 CA 证书。 +{{< warning >}} -{{< warning >}} -除非你了解风险和保护 CA 用法的机制，否则 *不要* 重用在不同上下文中使用的 CA。 +除非你了解风险和保护 CA 用法的机制，否则 **不要** 重用在不同上下文中使用的 CA。 {{< /warning >}} -### 注册 APIService 对象 +### 注册 APIService 对象 {#register-apiservice-objects} 你可以动态配置将哪些客户端请求代理到扩展 apiserver。以下是注册示例： @@ -547,8 +548,8 @@ spec: The name of an APIService object must be a valid [path segment name](/docs/concepts/overview/working-with-objects/names#path-segment-names). --> -APIService 对象的名称必须是合法的 -[路径片段名称](/zh-cn/docs/concepts/overview/working-with-objects/names#path-segment-names)。 +APIService +对象的名称必须是合法的[路径片段名称](/zh-cn/docs/concepts/overview/working-with-objects/names#path-segment-names)。 ### 编写一个转换 Webhook 服务器 {#write-a-conversion-webhook-server} diff --git a/content/zh-cn/docs/tasks/extend-kubernetes/setup-konnectivity.md b/content/zh-cn/docs/tasks/extend-kubernetes/setup-konnectivity.md index cc84dd812b2e5..460dac92c3072 100644 --- a/content/zh-cn/docs/tasks/extend-kubernetes/setup-konnectivity.md +++ b/content/zh-cn/docs/tasks/extend-kubernetes/setup-konnectivity.md @@ -31,7 +31,7 @@ plane hosts. If you do not already have a cluster, you can create one by using The following steps require an egress configuration, for example: --> -## 配置 Konnectivity 服务 +## 配置 Konnectivity 服务 {#configure-the-konnectivity-service} 接下来的步骤需要出口配置，比如： @@ -48,29 +48,16 @@ feature enabled in your cluster. It is enabled by default since Kubernetes v1.20 1. Set the `--egress-selector-config-file` flag of the API Server to the path of your API Server egress configuration file. 1. If you use UDS connection, add volumes config to the kube-apiserver: - ```yaml - spec: - containers: - volumeMounts: - - name: konnectivity-uds - mountPath: /etc/kubernetes/konnectivity-server - readOnly: false - volumes: - - name: konnectivity-uds - hostPath: - path: /etc/kubernetes/konnectivity-server - type: DirectoryOrCreate - ``` --> 你需要配置 API 服务器来使用 Konnectivity 服务，并将网络流量定向到集群节点： -确保[服务账号令牌卷投射](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) -特性被启用。该特性自 Kubernetes v1.20 起默认已被启用。 - +1. 确保[服务账号令牌卷投射](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)特性被启用。 + 该特性自 Kubernetes v1.20 起默认已被启用。 1. 创建一个出站流量配置文件，比如 `admin/konnectivity/egress-selector-configuration.yaml`。 -1. 将 API 服务器的 `--egress-selector-config-file` 参数设置为你的 API 服务器的 - 离站流量配置文件路径。 +1. 将 API 服务器的 `--egress-selector-config-file` 参数设置为你的 API + 服务器的离站流量配置文件路径。 1. 如果你在使用 UDS 连接，须将卷配置添加到 kube-apiserver： + ```yaml spec: containers: @@ -92,11 +79,10 @@ using the cluster CA certificate `/etc/kubernetes/pki/ca.crt` from a control-pla --> 为 konnectivity-server 生成或者取得证书和 kubeconfig 文件。 例如，你可以使用 OpenSSL 命令行工具，基于存放在某控制面主机上 -`/etc/kubernetes/pki/ca.crt` 文件中的集群 CA 证书来 -发放一个 X.509 证书， +`/etc/kubernetes/pki/ca.crt` 文件中的集群 CA 证书来发放一个 X.509 证书。 ```bash -openssl req -subj "/CN=system:konnectivity-server" -new -newkey rsa:2048 -nodes -out konnectivity.csr -keyout konnectivity.key -out konnectivity.csr +openssl req -subj "/CN=system:konnectivity-server" -new -newkey rsa:2048 -nodes -out konnectivity.csr -keyout konnectivity.key openssl x509 -req -in konnectivity.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out konnectivity.crt -days 375 -sha256 SERVER=$(kubectl config view -o jsonpath='{.clusters..server}') kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-credentials system:konnectivity-server --client-certificate konnectivity.crt --client-key konnectivity.key --embed-certs=true diff --git a/content/zh-cn/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/zh-cn/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md index 16845e892fbd2..548e9d2b02352 100644 --- a/content/zh-cn/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md +++ b/content/zh-cn/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md @@ -15,8 +15,8 @@ This page shows how a Pod can use environment variables to expose information about itself to containers running in the Pod, using the _downward API_. You can use environment variables to expose Pod fields, container fields, or both. --> -此页面展示 Pod 如何使用环境变量把自身的信息呈现给 Pod 中运行的容器。 -使用 **downward API** 你可以使用环境变量来呈现 Pod 的字段、容器字段或两者。 +此页面展示 Pod 如何使用 **downward API** 通过环境变量把自身的信息呈现给 Pod 中运行的容器。 +你可以使用环境变量来呈现 Pod 的字段、容器字段或两者。 -在 Kubernetes 中有两种方式可以将 Pod 和 容器字段呈现给运行中的容器： +在 Kubernetes 中有两种方式可以将 Pod 和容器字段呈现给运行中的容器： -* 如本任务所述的**环境变量**。 +* 如本任务所述的**环境变量** * [卷文件](/zh-cn/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) -这两种呈现 Pod 和 容器字段的方式统称为 downward API。 - +这两种呈现 Pod 和容器字段的方式统称为 downward API。 ## {{% heading "prerequisites" %}} @@ -47,9 +46,9 @@ downward API. In this part of exercise, you create a Pod that has one container, and you project Pod-level fields into the running container as environment variables. --> -## 用 Pod 字段作为环境变量的值 +## 用 Pod 字段作为环境变量的值 {#use-pod-fields-as-values-for-env-var} -在这部分练习中，你将创建一个包含一个容器的 Pod。并将 Pod 级别的字段作为环境变量映射到正在运行的容器中。 +在这部分练习中，你将创建一个包含一个容器的 Pod。并将 Pod 级别的字段作为环境变量投射到正在运行的容器中。 {{< codenew file="pods/inject/dapi-envars-pod.yaml" >}} @@ -62,22 +61,21 @@ variable gets its value from the Pod's `spec.nodeName` field. Similarly, the other environment variables get their names from Pod fields. --> 这个清单中，你可以看到五个环境变量。`env` 字段定义了一组环境变量。 - 数组中第一个元素指定 `MY_NODE_NAME` 这个环境变量从 Pod 的 `spec.nodeName` 字段获取变量值。 同样，其它环境变量也是从 Pod 的字段获取它们的变量值。 +{{< note >}} -{{< note >}} 本示例中的字段是 Pod 字段，不是 Pod 中 Container 的字段。 {{< /note >}} -创建Pod： +创建 Pod： ```shell kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-pod.yaml @@ -125,7 +123,7 @@ Next, get a shell into the container that is running in your Pod: 要了解为什么这些值出现在日志中，请查看配置文件中的 `command` 和 `args` 字段。 当容器启动时，它将五个环境变量的值写入标准输出。每十秒重复执行一次。 -接下来，通过打开一个 Shell 进入 Pod 中运行的容器： +接下来，进入 Pod 中运行的容器，打开一个 Shell： ```shell kubectl exec -it dapi-envars-fieldref -- sh @@ -169,9 +167,8 @@ definition, but taken from the specific rather than from the Pod overall. Here is a manifest for another Pod that again has just one container: - --> -## 使用容器字段作为环境变量的值 +## 使用容器字段作为环境变量的值 {#use-container-fields-as-value-for-env-var} 前面的练习中，你将 Pod 级别的字段作为环境变量的值。 接下来这个练习中，你将传递属于 Pod 定义的字段，但这些字段取自特定容器而不是整个 Pod。 @@ -195,7 +192,7 @@ Create the Pod: 数组中第一个元素指定 `MY_CPU_REQUEST` 这个环境变量从容器的 `requests.cpu` 字段获取变量值。同样，其它的环境变量也是从特定于这个容器的字段中获取它们的变量值。 -创建Pod： +创建 Pod： ```shell kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml @@ -244,7 +241,7 @@ The output shows the values of selected environment variables: * 阅读[给容器定义环境变量](/zh-cn/docs/tasks/inject-data-application/define-environment-variable-container/) * 阅读 Pod 的 [`spec`](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec) API 包括容器（Pod 的一部分）的定义。 -* 阅读可以使用 downward API 公开的[可用字段](/zh-cn/docs/concepts/workloads/pods/downward-api/#available-fields)列表。 +* 阅读可以使用 downward API 呈现的[可用字段](/zh-cn/docs/concepts/workloads/pods/downward-api/#available-fields)列表。 + +删除本教程中用到的 PersistentVolume 卷的持久化存储介质。 + ++```shell ++kubectl get pvc ++``` ++``` ++NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE ++www-web-0 Bound pvc-2bf00408-d366-4a12-bad0-1869c65d0bee 1Gi RWO standard 25m ++www-web-1 Bound pvc-ba3bfe9c-413e-4b95-a2c0-3ea8a54dbab4 1Gi RWO standard 24m ++www-web-2 Bound pvc-cba6cfa6-3a47-486b-a138-db5930207eaf 1Gi RWO standard 15m ++www-web-3 Bound pvc-0c04d7f0-787a-4977-8da3-d9d3a6d8d752 1Gi RWO standard 15m ++www-web-4 Bound pvc-b2c73489-e70b-4a4e-9ec1-9eab439aa43e 1Gi RWO standard 14m ++``` ++ ++```shell ++kubectl get pv ++``` ++``` ++NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE ++pvc-0c04d7f0-787a-4977-8da3-d9d3a6d8d752 1Gi RWO Delete Bound default/www-web-3 standard 15m ++pvc-2bf00408-d366-4a12-bad0-1869c65d0bee 1Gi RWO Delete Bound default/www-web-0 standard 25m ++pvc-b2c73489-e70b-4a4e-9ec1-9eab439aa43e 1Gi RWO Delete Bound default/www-web-4 standard 14m ++pvc-ba3bfe9c-413e-4b95-a2c0-3ea8a54dbab4 1Gi RWO Delete Bound default/www-web-1 standard 24m ++pvc-cba6cfa6-3a47-486b-a138-db5930207eaf 1Gi RWO Delete Bound default/www-web-2 standard 15m ++``` ++ ++```shell ++kubectl delete pvc www-web-0 www-web-1 www-web-2 www-web-3 www-web-4 ++``` ++ ++``` ++persistentvolumeclaim "www-web-0" deleted ++persistentvolumeclaim "www-web-1" deleted ++persistentvolumeclaim "www-web-2" deleted ++persistentvolumeclaim "www-web-3" deleted ++persistentvolumeclaim "www-web-4" deleted ++``` ++ ++```shell ++kubectl get pvc ++``` ++ ++``` ++No resources found in default namespace. ++``` {{< note >}}