From 461a09332b34e25501303ec7f28fcb14b366cb47 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Wed, 9 Mar 2022 21:28:09 +0800 Subject: [PATCH 01/32] [zh] Tune the feature gates page Reformat some line wraps, reorder some items in the description and fix a version missing in table 1. --- .../feature-gates.md | 171 +++++++++++------- 1 file changed, 101 insertions(+), 70 deletions(-) diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 4e1b4c6184..f33d2d747f 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -74,7 +74,7 @@ different Kubernetes components. | `CSIInlineVolume` | `true` | Beta | 1.16 | - | | `CSIMigration` | `false` | Alpha | 1.14 | 1.16 | | `CSIMigration` | `true` | Beta | 1.17 | | -| `CSIMigrationAWS` | `false` | Alpha | 1.14 | | +| `CSIMigrationAWS` | `false` | Alpha | 1.14 | 1.16 | | `CSIMigrationAWS` | `false` | Beta | 1.17 | 1.22 | | `CSIMigrationAWS` | `true` | Beta | 1.23 | | | `CSIMigrationAzureDisk` | `false` | Alpha | 1.15 | 1.18 | @@ -579,39 +579,47 @@ Each feature gate is designed for enabling/disabling a specific feature: See [AppArmor Tutorial](/docs/tutorials/security/apparmor/) for more details. - `AttachVolumeLimit`: Enable volume plugins to report limits on number of volumes that can be attached to a node. - See [dynamic volume limits](/docs/concepts/storage/storage-limits/#dynamic-volume-limits) for more details. -- `BalanceAttachedNodeVolumes`: Include volume count on node to be considered for balanced resource allocation - while scheduling. A node which has closer CPU, memory utilization, and volume count is favored by the scheduler - while making decisions. + See [dynamic volume limits](/docs/concepts/storage/storage-limits/#dynamic-volume-limits) + for more details. +- `BalanceAttachedNodeVolumes`: Include volume count on node to be considered for + balanced resource allocation while scheduling. A node which has closer CPU, + memory utilization, and volume count is favored by the scheduler while making decisions. - `BlockVolume`: Enable the definition and consumption of raw block devices in Pods. See [Raw Block Volume Support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support) for more details. -- `BoundServiceAccountTokenVolume`: Migrate ServiceAccount volumes to use a projected volume consisting of a - ServiceAccountTokenVolumeProjection. Cluster admins can use metric `serviceaccount_stale_tokens_total` to - monitor workloads that are depending on the extended tokens. If there are no such workloads, turn off - extended tokens by starting `kube-apiserver` with flag `--service-account-extend-token-expiration=false`. +- `BoundServiceAccountTokenVolume`: Migrate ServiceAccount volumes to use a projected volume + consisting of a ServiceAccountTokenVolumeProjection. Cluster admins can use metric + `serviceaccount_stale_tokens_total` to monitor workloads that are depending on the extended + tokens. If there are no such workloads, turn off extended tokens by starting `kube-apiserver` with + flag `--service-account-extend-token-expiration=false`. Check [Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md) - for more details. + for more details. - `ControllerManagerLeaderMigration`: Enables Leader Migration for [kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration) and - [cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager) which allows a cluster operator to live migrate + [cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager) + which allows a cluster operator to live migrate controllers from the kube-controller-manager into an external controller-manager (e.g. the cloud-controller-manager) in an HA cluster without downtime. - `CPUManager`: Enable container level CPU affinity support, see [CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/). -- `CPUManagerPolicyAlphaOptions`: This allows fine-tuning of CPUManager policies, experimental, Alpha-quality options +- `CPUManagerPolicyAlphaOptions`: This allows fine-tuning of CPUManager policies, + experimental, Alpha-quality options This feature gate guards *a group* of CPUManager options whose quality level is alpha. This feature gate will never graduate to beta or stable. -- `CPUManagerPolicyBetaOptions`: This allows fine-tuning of CPUManager policies, experimental, Beta-quality options +- `CPUManagerPolicyBetaOptions`: This allows fine-tuning of CPUManager policies, + experimental, Beta-quality options This feature gate guards *a group* of CPUManager options whose quality level is beta. This feature gate will never graduate to stable. - `CPUManagerPolicyOptions`: Allow fine-tuning of CPUManager policies. -- `CRIContainerLogRotation`: Enable container log rotation for CRI container runtime. The default max size of a log file is 10MB and the - default max number of log files allowed for a container is 5. These values can be configured in the kubelet config. - See the [logging at node level](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level) documentation for more details. +- `CRIContainerLogRotation`: Enable container log rotation for CRI container runtime. + The default max size of a log file is 10MB and the default max number of + log files allowed for a container is 5. + These values can be configured in the kubelet config. + See [logging at node level](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level) + for more details. - `CSIBlockVolume`: Enable external CSI volume drivers to support block storage. - See the [`csi` raw block volume support](/docs/concepts/storage/volumes/#csi-raw-block-volume-support) - documentation for more details. + See [`csi` raw block volume support](/docs/concepts/storage/volumes/#csi-raw-block-volume-support) + for more details. - `CSIDriverRegistry`: Enable all logic related to the CSIDriver API object in csi.storage.k8s.io. - `CSIInlineVolume`: Enable CSI Inline volumes support for pods. @@ -643,7 +651,8 @@ Each feature gate is designed for enabling/disabling a specific feature: AzureDisk CSI plugin. Requires CSIMigration and CSIMigrationAzureDisk feature flags enabled and AzureDisk CSI plugin installed and configured on all nodes in the cluster. This flag has been deprecated in favor of the - `InTreePluginAzureDiskUnregister` feature flag which prevents the registration of in-tree AzureDisk plugin. + `InTreePluginAzureDiskUnregister` feature flag which prevents the registration + of in-tree AzureDisk plugin. - `CSIMigrationAzureFile`: Enables shims and translation logic to route volume operations from the Azure-File in-tree plugin to AzureFile CSI plugin. Supports falling back to in-tree AzureFile plugin for mount operations to @@ -666,19 +675,13 @@ Each feature gate is designed for enabling/disabling a specific feature: Does not support falling back for provision operations, for those the CSI plugin must be installed and configured. Requires CSIMigration feature flag enabled. -- `csiMigrationRBD`: Enables shims and translation logic to route volume - operations from the RBD in-tree plugin to Ceph RBD CSI plugin. Requires - CSIMigration and csiMigrationRBD feature flags enabled and Ceph CSI plugin - installed and configured in the cluster. This flag has been deprecated in - favor of the - `InTreePluginRBDUnregister` feature flag which prevents the registration of - in-tree RBD plugin. - `CSIMigrationGCEComplete`: Stops registering the GCE-PD in-tree plugin in kubelet and volume controllers and enables shims and translation logic to route volume operations from the GCE-PD in-tree plugin to PD CSI plugin. Requires CSIMigration and CSIMigrationGCE feature flags enabled and PD CSI plugin installed and configured on all nodes in the cluster. This flag has - been deprecated in favor of the `InTreePluginGCEUnregister` feature flag which prevents the registration of in-tree GCE PD plugin. + been deprecated in favor of the `InTreePluginGCEUnregister` feature flag which + prevents the registration of in-tree GCE PD plugin. - `CSIMigrationOpenStack`: Enables shims and translation logic to route volume operations from the Cinder in-tree plugin to Cinder CSI plugin. Supports falling back to in-tree Cinder plugin for mount operations to nodes that have @@ -691,7 +694,14 @@ Each feature gate is designed for enabling/disabling a specific feature: volume operations from the Cinder in-tree plugin to Cinder CSI plugin. Requires CSIMigration and CSIMigrationOpenStack feature flags enabled and Cinder CSI plugin installed and configured on all nodes in the cluster. This flag has - been deprecated in favor of the `InTreePluginOpenStackUnregister` feature flag which prevents the registration of in-tree openstack cinder plugin. + been deprecated in favor of the `InTreePluginOpenStackUnregister` feature flag + which prevents the registration of in-tree openstack cinder plugin. +- `csiMigrationRBD`: Enables shims and translation logic to route volume + operations from the RBD in-tree plugin to Ceph RBD CSI plugin. Requires + CSIMigration and csiMigrationRBD feature flags enabled and Ceph CSI plugin + installed and configured in the cluster. This flag has been deprecated in + favor of the `InTreePluginRBDUnregister` feature flag which prevents the registration of + in-tree RBD plugin. - `CSIMigrationvSphere`: Enables shims and translation logic to route volume operations from the vSphere in-tree plugin to vSphere CSI plugin. Supports falling back to in-tree vSphere plugin for mount operations to nodes that have the feature @@ -704,11 +714,12 @@ Each feature gate is designed for enabling/disabling a specific feature: from the vSphere in-tree plugin to vSphere CSI plugin. Requires CSIMigration and CSIMigrationvSphere feature flags enabled and vSphere CSI plugin installed and configured on all nodes in the cluster. This flag has been deprecated in favor - of the `InTreePluginvSphereUnregister` feature flag which prevents the registration of in-tree vsphere plugin. + of the `InTreePluginvSphereUnregister` feature flag which prevents the + registration of in-tree vsphere plugin. - `CSIMigrationPortworx`: Enables shims and translation logic to route volume operations from the Portworx in-tree plugin to Portworx CSI plugin. - Requires Portworx CSI driver to be installed and configured in the cluster, and feature gate set `CSIMigrationPortworx=true` in kube-controller-manager and kubelet configs. -- `CSINodeInfo`: Enable all logic related to the CSINodeInfo API object in csi.storage.k8s.io. + Requires Portworx CSI driver to be installed and configured in the cluster. +- `CSINodeInfo`: Enable all logic related to the CSINodeInfo API object in `csi.storage.k8s.io`. - `CSIPersistentVolume`: Enable discovering and mounting volumes provisioned through a [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) compatible volume plugin. @@ -736,7 +747,9 @@ Each feature gate is designed for enabling/disabling a specific feature: version 1 of the same controller is selected. - `CustomCPUCFSQuotaPeriod`: Enable nodes to change `cpuCFSQuotaPeriod` in [kubelet config](/docs/tasks/administer-cluster/kubelet-config-file/). -- `CustomResourceValidationExpressions`: Enable expression language validation in CRD which will validate customer resource based on validation rules written in `x-kubernetes-validations` extension. +- `CustomResourceValidationExpressions`: Enable expression language validation in CRD + which will validate customer resource based on validation rules written in + the `x-kubernetes-validations` extension. - `CustomPodDNS`: Enable customizing the DNS settings for a Pod using its `dnsConfig` property. Check [Pod's DNS Config](/docs/concepts/services-networking/dns-pod-service/#pods-dns-config) for more details. @@ -819,7 +832,8 @@ Each feature gate is designed for enabling/disabling a specific feature: host mounts, or containers that are privileged or using specific non-namespaced capabilities (e.g. `MKNODE`, `SYS_MODULE` etc.). This should only be enabled if user namespace remapping is enabled in the Docker daemon. -- `ExternalPolicyForExternalIP`: Fix a bug where ExternalTrafficPolicy is not applied to Service ExternalIPs. +- `ExternalPolicyForExternalIP`: Fix a bug where ExternalTrafficPolicy is not + applied to Service ExternalIPs. - `GCERegionalPersistentDisk`: Enable the regional PD feature on GCE. - `GenericEphemeralVolume`: Enables ephemeral, inline volumes that support all features of normal volumes (can be provided by third-party storage vendors, storage capacity tracking, @@ -832,8 +846,10 @@ Each feature gate is designed for enabling/disabling a specific feature: for more details. - `GracefulNodeShutdownBasedOnPodPriority`: Enables the kubelet to check Pod priorities when shutting down a node gracefully. -- `GRPCContainerProbe`: Enables the gRPC probe method for {Liveness,Readiness,Startup}Probe. See [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe). -- `HonorPVReclaimPolicy`: Honor persistent volume reclaim policy when it is `Delete` irrespective of PV-PVC deletion ordering. +- `GRPCContainerProbe`: Enables the gRPC probe method for {Liveness,Readiness,Startup}Probe. + See [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe). +- `HonorPVReclaimPolicy`: Honor persistent volume reclaim policy when it is `Delete` + irrespective of PV-PVC deletion ordering. - `HPAContainerMetrics`: Enable the `HorizontalPodAutoscaler` to scale based on metrics from individual containers in target pods. - `HPAScaleToZero`: Enables setting `minReplicas` to 0 for `HorizontalPodAutoscaler` @@ -845,10 +861,19 @@ Each feature gate is designed for enabling/disabling a specific feature: - `HyperVContainer`: Enable [Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container) for Windows containers. -- `IdentifyPodOS`: Allows the Pod OS field to be specified. This helps in identifying the OS of the pod - authoritatively during the API server admission time. In Kubernetes {{< skew currentVersion >}}, the allowed values for the `pod.spec.os.name` are `windows` and `linux`. +- `IdentifyPodOS`: Allows the Pod OS field to be specified. This helps in identifying + the OS of the pod authoritatively during the API server admission time. + In Kubernetes {{< skew currentVersion >}}, the allowed values for the `pod.spec.os.name` + are `windows` and `linux`. - `ImmutableEphemeralVolumes`: Allows for marking individual Secrets and ConfigMaps as immutable for better safety and performance. +- `IndexedJob`: Allows the [Job](/docs/concepts/workloads/controllers/job/) + controller to manage Pod completions per completion index. +- `IngressClassNamespacedParams`: Allow namespace-scoped parameters reference in + `IngressClass` resource. This feature adds two fields - `Scope` and `Namespace` + to `IngressClass.spec.parameters`. +- `Initializers`: Allow asynchronous coordination of object creation using the + Initializers admission plugin. - `InTreePluginAWSUnregister`: Stops registering the aws-ebs in-tree plugin in kubelet and volume controllers. - `InTreePluginAzureDiskUnregister`: Stops registering the azuredisk in-tree plugin in kubelet @@ -865,13 +890,6 @@ Each feature gate is designed for enabling/disabling a specific feature: and volume controllers. - `InTreePluginvSphereUnregister`: Stops registering the vSphere in-tree plugin in kubelet and volume controllers. -- `IndexedJob`: Allows the [Job](/docs/concepts/workloads/controllers/job/) - controller to manage Pod completions per completion index. -- `IngressClassNamespacedParams`: Allow namespace-scoped parameters reference in - `IngressClass` resource. This feature adds two fields - `Scope` and `Namespace` - to `IngressClass.spec.parameters`. -- `Initializers`: Allow asynchronous coordination of object creation using the - Initializers admission plugin. - `IPv6DualStack`: Enable [dual stack](/docs/concepts/services-networking/dual-stack/) support for IPv6. - `JobMutableNodeSchedulingDirectives`: Allows updating node scheduling directives in @@ -889,17 +907,21 @@ Each feature gate is designed for enabling/disabling a specific feature: a file specified using a config file. See [setting kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/) for more details. -- `KubeletCredentialProviders`: Enable kubelet exec credential providers for image pull credentials. -- `KubeletInUserNamespace`: Enables support for running kubelet in a {{}}. +- `KubeletCredentialProviders`: Enable kubelet exec credential providers for + image pull credentials. +- `KubeletInUserNamespace`: Enables support for running kubelet in a + {{}}. See [Running Kubernetes Node Components as a Non-root User](/docs/tasks/administer-cluster/kubelet-in-userns/). - `KubeletPluginsWatcher`: Enable probe-based plugin watcher utility to enable kubelet to discover plugins such as [CSI volume drivers](/docs/concepts/storage/volumes/#csi). - `KubeletPodResources`: Enable the kubelet's pod resources gRPC endpoint. See [Support Device Monitoring](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/606-compute-device-assignment/README.md) for more details. -- `KubeletPodResourcesGetAllocatable`: Enable the kubelet's pod resources `GetAllocatableResources` functionality. - This API augments the [resource allocation reporting](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#monitoring-device-plugin-resources) - with informations about the allocatable resources, enabling clients to properly track the free compute resources on a node. +- `KubeletPodResourcesGetAllocatable`: Enable the kubelet's pod resources + `GetAllocatableResources` functionality. This API augments the + [resource allocation reporting](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#monitoring-device-plugin-resources) + with informations about the allocatable resources, enabling clients to properly + track the free compute resources on a node. - `LegacyNodeRoleBehavior`: When disabled, legacy behavior in service load balancers and node disruption will ignore the `node-role.kubernetes.io/master` label in favor of the feature-specific labels provided by `NodeDisruptionExclusion` and `ServiceNodeExclusion`. @@ -918,18 +940,22 @@ Each feature gate is designed for enabling/disabling a specific feature: based on logarithmic bucketing of pod timestamps. - `MemoryManager`: Allows setting memory affinity for a container based on NUMA topology. -- `MemoryQoS`: Enable memory protection and usage throttle on pod / container using cgroup v2 memory controller. +- `MemoryQoS`: Enable memory protection and usage throttle on pod / container using + cgroup v2 memory controller. - `MixedProtocolLBService`: Enable using different protocols in the same `LoadBalancer` type Service instance. - `MountContainers`: Enable using utility containers on host as the volume mounter. - `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods. For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation). -- `NamespaceDefaultLabelName`: Configure the API Server to set an immutable {{< glossary_tooltip text="label" term_id="label" >}} - `kubernetes.io/metadata.name` on all namespaces, containing the namespace name. -- `NetworkPolicyEndPort`: Enable use of the field `endPort` in NetworkPolicy objects, allowing the selection of a port range instead of a single port. +- `NamespaceDefaultLabelName`: Configure the API Server to set an immutable + {{< glossary_tooltip text="label" term_id="label" >}} `kubernetes.io/metadata.name` + on all namespaces, containing the namespace name. +- `NetworkPolicyEndPort`: Enable use of the field `endPort` in NetworkPolicy objects, + allowing the selection of a port range instead of a single port. - `NodeDisruptionExclusion`: Enable use of the Node label `node.kubernetes.io/exclude-disruption` which prevents nodes from being evacuated during zone failures. -- `NodeLease`: Enable the new Lease API to report node heartbeats, which could be used as a node health signal. +- `NodeLease`: Enable the new Lease API to report node heartbeats, which could be used + as a node health signal. - `NodeSwap`: Enable the kubelet to allocate swap memory for Kubernetes workloads on a node. Must be used with `KubeletConfiguration.failSwapOn` set to false. For more details, please see [swap memory](/docs/concepts/architecture/nodes/#swap-memory) @@ -937,23 +963,23 @@ Each feature gate is designed for enabling/disabling a specific feature: - `OpenAPIEnums`: Enables populating "enum" fields of OpenAPI schemas in the spec returned from the API server. - `OpenAPIV3`: Enables the API server to publish OpenAPI v3. -- `PVCProtection`: Enable the prevention of a PersistentVolumeClaim (PVC) from - being deleted when it is still used by any Pod. - `PodDeletionCost`: Enable the [Pod Deletion Cost](/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost) feature which allows users to influence ReplicaSet downscaling order. - `PersistentLocalVolumes`: Enable the usage of `local` volume type in Pods. Pod affinity has to be specified if requesting a `local` volume. -- `PodAndContainerStatsFromCRI`: Configure the kubelet to gather container and pod stats from the CRI container runtime - rather than gathering them from cAdvisor. +- `PodAndContainerStatsFromCRI`: Configure the kubelet to gather container and + pod stats from the CRI container runtime rather than gathering them from cAdvisor. - `PodDisruptionBudget`: Enable the [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) feature. -- `PodAffinityNamespaceSelector`: Enable the [Pod Affinity Namespace Selector](/docs/concepts/scheduling-eviction/assign-pod-node/#namespace-selector) - and [CrossNamespacePodAffinity](/docs/concepts/policy/resource-quotas/#cross-namespace-pod-affinity-quota) quota scope features. +- `PodAffinityNamespaceSelector`: Enable the + [Pod Affinity Namespace Selector](/docs/concepts/scheduling-eviction/assign-pod-node/#namespace-selector) + and [CrossNamespacePodAffinity](/docs/concepts/policy/resource-quotas/#cross-namespace-pod-affinity-quota) + quota scope features. - `PodOverhead`: Enable the [PodOverhead](/docs/concepts/scheduling-eviction/pod-overhead/) feature to account for pod overheads. - `PodPriority`: Enable the descheduling and preemption of Pods based on their [priorities](/docs/concepts/scheduling-eviction/pod-priority-preemption/). - `PodReadinessGates`: Enable the setting of `PodReadinessGate` field for extending - Pod readiness evaluation. See [Pod readiness gate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate) + Pod readiness evaluation. See [Pod readiness gate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate) for more details. - `PodSecurity`: Enables the `PodSecurity` admission plugin. - `PodShareProcessNamespace`: Enable the setting of `shareProcessNamespace` in a Pod for sharing @@ -964,25 +990,27 @@ Each feature gate is designed for enabling/disabling a specific feature: the cluster. - `ProbeTerminationGracePeriod`: Enable [setting probe-level `terminationGracePeriodSeconds`](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds) - on pods. See the [enhancement proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period) for more details. + on pods. See the [enhancement proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period) + for more details. - `ProcMountType`: Enables control over the type proc mounts for containers by setting the `procMount` field of a SecurityContext. - `ProxyTerminatingEndpoints`: Enable the kube-proxy to handle terminating endpoints when `ExternalTrafficPolicy=Local`. +- `PVCProtection`: Enable the prevention of a PersistentVolumeClaim (PVC) from + being deleted when it is still used by any Pod. - `QOSReserved`: Allows resource reservations at the QoS level preventing pods at lower QoS levels from bursting into resources requested at higher QoS levels (memory only for now). - `ReadWriteOncePod`: Enables the usage of `ReadWriteOncePod` PersistentVolume access mode. -- `RecoverVolumeExpansionFailure`: Enables users to edit their PVCs to smaller sizes so as they can recover from previously issued - volume expansion failures. See - [Recovering from Failure when Expanding Volumes](/docs/concepts/storage/persistent-volumes/#recovering-from-failure-when-expanding-volumes) +- `RecoverVolumeExpansionFailure`: Enables users to edit their PVCs to smaller + sizes so as they can recover from previously issued volume expansion failures. + See [Recovering from Failure when Expanding Volumes](/docs/concepts/storage/persistent-volumes/#recovering-from-failure-when-expanding-volumes) for more details. - `RemainingItemCount`: Allow the API servers to show a count of remaining items in the response to a [chunking list request](/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks). -- `RemoveSelfLink`: Deprecates and removes `selfLink` from ObjectMeta and - ListMeta. +- `RemoveSelfLink`: Deprecates and removes `selfLink` from ObjectMeta and ListMeta. - `RequestManagement`: Enables managing request concurrency with prioritization and fairness at each API server. Deprecated by `APIPriorityAndFairness` since 1.17. - `ResourceLimitsPriorityFunction`: Enable a scheduler priority function that @@ -997,7 +1025,8 @@ Each feature gate is designed for enabling/disabling a specific feature: [Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md) for more details. - `RotateKubeletClientCertificate`: Enable the rotation of the client TLS certificate on the kubelet. - See [kubelet configuration](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration) for more details. + See [kubelet configuration](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration) + for more details. - `RotateKubeletServerCertificate`: Enable the rotation of the server TLS certificate on the kubelet. See [kubelet configuration](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration) for more details. @@ -1009,7 +1038,8 @@ Each feature gate is designed for enabling/disabling a specific feature: instead of the DaemonSet controller. - `SCTPSupport`: Enables the _SCTP_ `protocol` value in Pod, Service, Endpoints, EndpointSlice, and NetworkPolicy definitions. -- `SeccompDefault`: Enables the use of `RuntimeDefault` as the default seccomp profile for all workloads. +- `SeccompDefault`: Enables the use of `RuntimeDefault` as the default seccomp profile + for all workloads. The seccomp profile is specified in the `securityContext` of a Pod and/or a Container. - `SelectorIndex`: Allows label and field based indexes in API server watch cache to accelerate list operations. @@ -1023,7 +1053,8 @@ Each feature gate is designed for enabling/disabling a specific feature: - `ServiceInternalTrafficPolicy`: Enables the `internalTrafficPolicy` field on Services - `ServiceLBNodePortControl`: Enables the `allocateLoadBalancerNodePorts` field on Services. - `ServiceLoadBalancerClass`: Enables the `loadBalancerClass` field on Services. See - [Specifying class of load balancer implementation](/docs/concepts/services-networking/service/#load-balancer-class) for more details. + [Specifying class of load balancer implementation](/docs/concepts/services-networking/service/#load-balancer-class) + for more details. - `ServiceLoadBalancerFinalizer`: Enable finalizer protection for Service load balancers. - `ServiceNodeExclusion`: Enable the exclusion of nodes from load balancers created by a cloud provider. A node is eligible for exclusion if labelled with From 61849547f2f6a2ade1908165030d43e18d4b454c Mon Sep 17 00:00:00 2001 From: Arhell Date: Tue, 22 Mar 2022 10:38:22 +0200 Subject: [PATCH 02/32] [ja] update audit.md --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index b020b9c0b2..c38014b39e 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -149,6 +149,7 @@ volumeMounts: 最後に`hostPath`を設定します: ```yaml ... +volumes: - name: audit hostPath: path: /etc/kubernetes/audit-policy.yaml @@ -158,7 +159,6 @@ volumeMounts: hostPath: path: /var/log/audit.log type: FileOrCreate - ``` ### Webhookバックエンド From accbd5ef66f9430b4812aff82c387f67bc6b6cba Mon Sep 17 00:00:00 2001 From: Ilya Z Date: Sat, 26 Mar 2022 19:45:18 +0400 Subject: [PATCH 03/32] translated_quote --- content/ru/community/static/community-values.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ru/community/static/community-values.md b/content/ru/community/static/community-values.md index c9c0f00ac5..712635feb0 100644 --- a/content/ru/community/static/community-values.md +++ b/content/ru/community/static/community-values.md @@ -25,4 +25,4 @@ Открытость новым идеям и изученная технологическая эволюция делают Kubernetes более сильным проектом. Постоянное совершенствование, лидерство слуг, наставничество и уважение-вот основы культуры проекта Kubernetes. Лидеры сообщества Kubernetes обязаны находить, спонсировать и продвигать новых членов сообщества. Лидеры должны ожидать, что они отойдут в сторону. Члены сообщества должны ожидать, что они сделают шаг вперед. -**"Culture eats strategy for breakfast." --Peter Drucker** +**"Культура съедает стратегию на завтрак" — Питер Друкер** \ No newline at end of file From 2139601101658463c2570d0631a9f2a934e4357d Mon Sep 17 00:00:00 2001 From: Ilya Z Date: Sat, 26 Mar 2022 20:14:01 +0400 Subject: [PATCH 04/32] arch_concept --- content/ru/docs/concepts/architecture/_index.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/ru/docs/concepts/architecture/_index.md b/content/ru/docs/concepts/architecture/_index.md index 05b3535491..1a4ac050ce 100644 --- a/content/ru/docs/concepts/architecture/_index.md +++ b/content/ru/docs/concepts/architecture/_index.md @@ -2,6 +2,5 @@ title: "Кластерная Архитектура" weight: 30 description: > - The architectural concepts behind Kubernetes. ---- - + Архитектурные концепции, лежащие в основе Kubernetes. +--- \ No newline at end of file From a664033f6912cf4475c0f8fd2457c8055d0519f8 Mon Sep 17 00:00:00 2001 From: Ilya Z Date: Sat, 26 Mar 2022 20:54:01 +0400 Subject: [PATCH 05/32] fix_misspellings --- .../concepts/architecture/cloud-controller.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/content/ru/docs/concepts/architecture/cloud-controller.md b/content/ru/docs/concepts/architecture/cloud-controller.md index 5bb9c3d4fa..8c51bbcb0a 100644 --- a/content/ru/docs/concepts/architecture/cloud-controller.md +++ b/content/ru/docs/concepts/architecture/cloud-controller.md @@ -8,7 +8,7 @@ weight: 40 {{< feature-state state="beta" for_k8s_version="v1.11" >}} -Технологии облачной инфраструктуры позволяет запускать Kubernetes в общедоступных, частных и гибридных облаках. Kubernetes верит в автоматизированную, управляемую API инфраструктуру без жесткой связи между компонентами. +Технологии облачной инфраструктуры позволяют запускать Kubernetes в общедоступных, частных и гибридных облаках. Kubernetes верит в автоматизированную, управляемую API инфраструктуру без жесткой связи между компонентами. {{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="Диспетчер облачных контроллеров">}} @@ -33,7 +33,7 @@ weight: 40 Контроллеры внутри диспетчера облачных контроллеров включают в себя: -### Контролер узла +### Контроллер узла Контроллер узла отвечает за создание объектов {{< glossary_tooltip text="узла" term_id="node" >}} при создании новых серверов в вашей облачной инфраструктуре. Контроллер узла получает информацию о работающих хостах внутри вашей арендуемой инфраструктуры облачного провайдера. Контроллер узла выполняет следующие функции: @@ -41,13 +41,13 @@ weight: 40 1. Инициализация объектов узла для каждого сервера, которые контроллер получает через API облачного провайдера. 2. Аннотирование и маркировка объектов узла специфичной для облака информацией, такой как регион узла и доступные ему ресурсы (процессор, память и т.д.). 3. Получение имени хоста и сетевых адресов. -4. Проверка работоспособности узла. В случае, если узел перестает отвечать на запросы, этот контроллер проверяет с помощью API вашего облачного провайдера, был ли сервер деактивирован / удален / прекращен. Если узел был удален из облака, контроллер удлаяет объект узла из вашего Kubernetes кластера. +4. Проверка работоспособности узла. В случае, если узел перестает отвечать на запросы, этот контроллер проверяет с помощью API вашего облачного провайдера, был ли сервер деактивирован / удален / прекращен. Если узел был удален из облака, контроллер удаляет объект узла из вашего Kubernetes кластера. Некоторые облачные провайдеры реализуют его разделение на контроллер узла и отдельный контроллер жизненного цикла узла. -### Контролер маршрута +### Контроллер маршрута -Контролер маршрута отвечает за соответствующую настройку маршрутов в облаке, чтобы контейнеры на разных узлах кластера Kubernetes могли взаимодействовать друг с другом. +Контроллер маршрута отвечает за соответствующую настройку маршрутов в облаке, чтобы контейнеры на разных узлах кластера Kubernetes могли взаимодействовать друг с другом. В зависимости от облачного провайдера, контроллер маршрута способен также выделять блоки IP-адресов для сети Pod-ов. @@ -61,7 +61,7 @@ weight: 40 ### Контроллер узла {#authorization-node-controller} -Контроллер узла работает только с объектом узла. Он требует полного доступа для и изменения объектов узла. +Контроллер узла работает только с объектом узла. Он требует полного доступа на чтение и изменение объектов узла. `v1/Node`: @@ -73,9 +73,9 @@ weight: 40 - Watch - Delete -### Контролер маршрута {#authorization-route-controller} +### Контроллер маршрута {#authorization-route-controller} -Контролер маршрута прослушивает создание объектов узла и соответствующим образом настраивает маршруты. Для этого требуется получить доступ к объектам узла. +Контроллер маршрута прослушивает создание объектов узла и соответствующим образом настраивает маршруты. Для этого требуется получить доступ к объектам узла. `v1/Node`: @@ -99,7 +99,7 @@ weight: 40 ### Другие {#authorization-miscellaneous} -Реализация ядра диспетчера облачных контроллеров требует доступ для создания создания объектов событий, а для обеспечения безопасной работы требуется доступ к созданию сервисных учетных записей (ServiceAccounts). +Реализация ядра диспетчера облачных контроллеров требует доступ для создания объектов событий, а для обеспечения безопасной работы требуется доступ к созданию сервисных учетных записей (ServiceAccounts). `v1/Event`: @@ -111,7 +111,7 @@ weight: 40 - Create -The {{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRole для диспетчера облачных контроллеров выглядит так: +{{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRole для диспетчера облачных контроллеров выглядит так: ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -179,7 +179,7 @@ rules: ## {{% heading "whatsnext" %}} [Администрирование диспетчера облачных контроллеров](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) -содержит инструкции по запуску и управлению диспетером облачных контроллеров. +содержит инструкции по запуску и управлению диспетчером облачных контроллеров. Хотите знать, как реализовать свой собственный диспетчер облачных контроллеров или расширить проект? From 510bd76dd7f7f55922aa8ec5b0f36a40ddbac18c Mon Sep 17 00:00:00 2001 From: Ilya Z Date: Sat, 26 Mar 2022 22:49:23 +0400 Subject: [PATCH 06/32] gc_typos --- .../architecture/garbage-collection.md | 36 +++++++++---------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/content/ru/docs/concepts/architecture/garbage-collection.md b/content/ru/docs/concepts/architecture/garbage-collection.md index f7ded8b44e..e94da8fc62 100644 --- a/content/ru/docs/concepts/architecture/garbage-collection.md +++ b/content/ru/docs/concepts/architecture/garbage-collection.md @@ -23,7 +23,7 @@ weight: 50 Многие объекты в Kubernetes ссылаются друг на друга через [*ссылки владельцев*](/docs/concepts/overview/working-with-objects/owners-dependents/). Ссылки владельцев сообщают плоскости управления какие объекты зависят от других. Kubernetes использует ссылки владельцев, чтобы предоставить плоскости управления и другим API -клиентам, возможность очистить связанные ресурсы передудалением объекта. В большинстве случаев, Kubernetes автоматический управляет ссылками владельцев. +клиентам, возможность очистить связанные ресурсы перед удалением объекта. В большинстве случаев, Kubernetes автоматический управляет ссылками владельцев. Владелец отличается от [меток и селекторов](/docs/concepts/overview/working-with-objects/labels/) которые также используют некоторые ресурсы. Например, рассмотрим @@ -36,15 +36,15 @@ Kubernetes использует ссылки владельцев, чтобы п {{< note >}} Ссылки на владельцев перекрестных пространств имен запрещены по дизайну. Зависимости пространства имен могут указывать на область действия кластера или владельцев пространства имен. -Владелец пространства имен **должен** быть в том же пространстве имен что и зависимости. -Если это не возможно, cсылка владельца считается отсутствующей и зависимый объект подлежит удалению, как только будет проверено отсутствие всех владельцев. +Владелец пространства имен **должен** быть в том же пространстве имен, что и зависимости. +Если это не возможно, ссылка владельца считается отсутствующей и зависимый объект подлежит удалению, как только будет проверено отсутствие всех владельцев. Зависимости области действия кластер может указывать только владельцев области действия кластера. В версии v1.20+, если зависимость с областью действия кластера указывает на пространство имен как владелец, тогда он рассматривается как имеющий неразрешимую ссылку на владельца и не может быть обработан сборщиком мусора. В версии v1.20+, если сборщик мусора обнаружит недопустимое перекрестное пространство имен `ownerReference`, -или зависящие от облости действия кластера `ownerReference` ссылка на тип пространства имен, предупреждающее событие с причиной `OwnerRefInvalidNamespace` и `involvedObject` сообщающеся о не действительной зависимости. +или зависящие от области действия кластера `ownerReference` ссылка на тип пространства имен, предупреждающее событие с причиной `OwnerRefInvalidNamespace` и `involvedObject` сообщающее о недействительной зависимости. Вы можете проверить наличие такого рода событий, выполнив `kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`. {{< /note >}} @@ -52,22 +52,22 @@ Kubernetes использует ссылки владельцев, чтобы п Kubernetes проверяет и удаляет объекты, на которые больше нет ссылок владельцев, так же как и pod-ов, оставленных после удаления ReplicaSet. Когда Вы удаляете объект, вы можете контролировать автоматический ли Kubernetes удаляет зависимые объекты автоматически в процессе вызова *каскадного удаления*. Существует два типа каскадного удаления, а именно: - * Каскадное удалени Foreground + * Каскадное удаление Foreground * Каскадное удаление Background Вы так же можете управлять как и когда сборщик мусора удаляет ресурсы, на которые ссылаются владельцы с помощью Kubernetes {{}}. -### Каскадное удалени Foreground {#foreground-deletion} +### Каскадное удаление Foreground {#foreground-deletion} -В Каскадном удалени Foreground, объект владельца, который вы удаляете, сначало переходить в состояние *в процессе удаления*. В этом состоянии с объектом-владельцем происходить следующее: +В Каскадном удалении Foreground, объект владельца, который вы удаляете, сначала переходить в состояние *в процессе удаления*. В этом состоянии с объектом-владельцем происходить следующее: * Сервер Kubernetes API устанавливает полю объекта `metadata.deletionTimestamp` время, когда объект был помечен для удаления. * Сервер Kubernetes API так же устанавливает метку `metadata.finalizers`для поля `foregroundDeletion`. - * Объект остается видимым блогодоря Kubernetes API пока процесс удаления не завершиться + * Объект остается видимым благодаря Kubernetes API пока процесс удаления не завершиться -После того, как владелец объекта переходит в состояние прогресса удаления, контроллер удаляет зависимые объекты. После удаления всех зависимых объектов, контроллер удаляет объект владельца. На этом этапе, объект больше не отображается в Kubernetes API. +После того как владелец объекта переходит в состояние прогресса удаления, контроллер удаляет зависимые объекты. После удаления всех зависимых объектов, контроллер удаляет объект владельца. На этом этапе, объект больше не отображается в Kubernetes API. Во время каскадного удаления foreground, единственным зависимым, которые блокируют удаления владельца, являются те, у кого имеется поле `ownerReference.blockOwnerDeletion=true`. Чтобы узнать больше. Смотрите [Использование каскадного удаления foreground](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion). @@ -80,16 +80,16 @@ Kubernetes проверяет и удаляет объекты, на котор ### Осиротевшие зависимости -Когда Kubernetes удаляет владельца объекта, оставшиеся зависимости называются *осиротевшыми* объектами. По умолчанию, Kubernetes удаляет зависимые объекты. Чтобы узнать, как переопределить это повидение смотрите [Удаление объектов владельца и осиротевших зависимостей](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy). +Когда Kubernetes удаляет владельца объекта, оставшиеся зависимости называются *осиротевшими* объектами. По умолчанию, Kubernetes удаляет зависимые объекты. Чтобы узнать, как переопределить это поведение смотрите [Удаление объектов владельца и осиротевших зависимостей](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy). -## Сбор мусора из неиспользуемых контейнеров и изобробразов {#containers-images} +## Сбор мусора из неиспользуемых контейнеров и изображений {#containers-images} {{}} выполняет сбор мусора для неиспользуемых образов каждые пять минут и для неиспользуемых контейнеров каждую минуту. Вам следует избегать использования внешних инструментов для сборки мусора, так как они могут нарушить поведение kubelet и удалить контейнеры, которые должны существовать. -Чтобы настроить параметры для сборшика мусора для неиспользуемого контейнера и сборки мусора образа, подстройте +Чтобы настроить параметры для сборщика мусора для неиспользуемого контейнера и сборки мусора образа, подстройте kubelet использую [конфигурационный файл](/docs/tasks/administer-cluster/kubelet-config-file/) -и измените параметры, связанные со сборшиком мусора используя тип ресурса +и измените параметры, связанные со сборщиком мусора используя тип ресурса [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration). ### Жизненный цикл контейнерных образов Container image lifecycle @@ -99,19 +99,19 @@ Kubernetes управляет жизненным циклом всех обра * `HighThresholdPercent` * `LowThresholdPercent` -Использование диска выше настроенного значения `HighThresholdPercent` запускает сборку мусора, которая удаляет образы в порядке основанном на последнем использовании, начиная с самого старого. kubelet удлаяет образы до тех пор, пока использование диска не достигнет значения `LowThresholdPercent`. +Использование диска выше настроенного значения `HighThresholdPercent` запускает сборку мусора, которая удаляет образы в порядке основанном на последнем использовании, начиная с самого старого. Kubelet удаляет образы до тех пор, пока использование диска не достигнет значения `LowThresholdPercent`. ### Сборщик мусора контейнерных образов {#container-image-garbage-collection} -kubelet собирает не используемые контейнеры на основе следующих переменных, которые вы можете определить: +Kubelet собирает не используемые контейнеры на основе следующих переменных, которые вы можете определить: * `MinAge`: минимальный возраст, при котором kubelet может начать собирать мусор контейнеров. Отключить, установив значение `0`. - * `MaxPerPodContainer`: максимальное количество некативныз контейнеров, которое может быть у каджой пары Pod-ов. Отключить, установив значение меньше чем `0`. + * `MaxPerPodContainer`: максимальное количество неактивных контейнеров, которое может быть у каждой пары Pod-ов. Отключить, установив значение меньше чем `0`. * `MaxContainers`: максимальное количество не используемых контейнеров, которые могут быть в кластере. Отключить, установив значение меньше чем `0`. В дополнение к этим переменным, kubelet собирает неопознанные и удаленные контейнеры, обычно начиная с самого старого. -`MaxPerPodContainer` и `MaxContainer` могут потенциально конфликтовать друг с другом в ситуациях, когда требуется максимальное количество контейнеров в Pod-е (`MaxPerPodContainer`) выйдет за пределы допустимого общего количества глобальных не используемых контейнеров (`MaxContainers`). В этой ситуации kubelet регулирует `MaxPodPerContainer` для устранения конфликта. наихудшим сценарием было бы понизить `MaxPerPodContainer` да `1` и изгнать самые старые контейнеры. +`MaxPerPodContainer` и `MaxContainer` могут потенциально конфликтовать друг с другом в ситуациях, когда требуется максимальное количество контейнеров в Pod-е (`MaxPerPodContainer`) выйдет за пределы допустимого общего количества глобальных не используемых контейнеров (`MaxContainers`). В этой ситуации kubelet регулирует `MaxPodPerContainer` для устранения конфликта. Наихудшим сценарием было бы понизить `MaxPerPodContainer` да `1` и изгнать самые старые контейнеры. Кроме того, владельцы контейнеров в pod-е могут быть удалены, как только они становятся старше чем `MinAge`. {{}} @@ -120,7 +120,7 @@ Kubelet собирает мусор только у контейнеров, ко ## Настройка сборщик мусора {#configuring-gc} -Вы можете настроить сборку мусора ресурсов, настроив параметры, специфичные для контроллеров, управляющих этими ресурсами. В последующих страницах показанно, как настроить сборку мусора: +Вы можете настроить сборку мусора ресурсов, настроив параметры, специфичные для контроллеров, управляющих этими ресурсами. В последующих страницах показано, как настроить сборку мусора: * [Настройка каскадного удаления объектов Kubernetes](/docs/tasks/administer-cluster/use-cascading-deletion/) * [Настройка очистки завершенных заданий](/docs/concepts/workloads/controllers/ttlafterfinished/) From 232c79f4e4e2646064c1239a18e934b23677eb9f Mon Sep 17 00:00:00 2001 From: Ilya Z Date: Sat, 26 Mar 2022 23:03:46 +0400 Subject: [PATCH 07/32] fix_some_typos --- .../ru/docs/concepts/architecture/nodes.md | 54 +++++++++---------- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/content/ru/docs/concepts/architecture/nodes.md b/content/ru/docs/concepts/architecture/nodes.md index 075c3140f5..613155f012 100644 --- a/content/ru/docs/concepts/architecture/nodes.md +++ b/content/ru/docs/concepts/architecture/nodes.md @@ -32,7 +32,7 @@ Kubernetes запускает ваши приложения, помещая ко 1. Kubelet на узле саморегистрируется в плоскости управления 2. Вы или другой пользователь вручную добавляете объект Узла -После того, как вы создадите объект Узла или kubelet на узле самозарегистируется, +После того как вы создадите объект Узла или kubelet на узле самозарегистируется, плоскость управления проверяет, является ли новый объект Узла валидным (правильным). Например, если вы попробуете создать Узел при помощи следующего JSON манифеста: @@ -50,9 +50,9 @@ Kubernetes запускает ваши приложения, помещая ко ``` Kubernetes создает внутри себя объект Узла (представление). Kubernetes проверяет, -что kubelet зарегистрировался на API сервере, который совпадает с значением поля `metadata.name` Узла. +что kubelet зарегистрировался на API сервере, который совпадает со значением поля `metadata.name` Узла. Если узел здоров (если все необходимые сервисы запущены), -он имеет право на запуск Пода. В противном случае, этот узел игнорируется для любой активности кластера +он имеет право на запуск Пода. В противном случае этот узел игнорируется для любой активности кластера до тех пор, пока он не станет здоровым. {{< note >}} @@ -62,13 +62,13 @@ Kubernetes сохраняет объект для невалидного Узл остановить проверку доступности узла. {{< /note >}} -Имя объекта Узла дожно быть валидным +Имя объекта Узла должно быть валидным [именем поддомена DNS](/ru/docs/concepts/overview/working-with-objects/names#имена-поддоменов-dns). ### Саморегистрация Узлов Когда kubelet флаг `--register-node` имеет значение _true_ (по умолчанию), то kubelet будет пытаться -зарегистрировать себя на API сервере. Это наиболее предпочтительная модель, используемая большиством дистрибутивов. +зарегистрировать себя на API сервере. Это наиболее предпочтительная модель, используемая большинством дистрибутивов. Для саморегистрации kubelet запускается со следующими опциями: @@ -94,16 +94,16 @@ kubelet'ы имеют право только создавать/изменят Когда вы хотите создать объекты Узла вручную, установите kubelet флаг `--register-node=false`. Вы можете изменять объекты Узла независимо от настройки `--register-node`. -Например, вы можете установить метки на существующем Узле или пометить его неназначаемым. +Например, вы можете установить метки на существующем Узле или пометить его не назначаемым. Вы можете использовать метки на Узлах в сочетании с селекторами узла на Подах для управления планированием. -Например, вы можете ограничить Под иметь право на запуск только на группе доступных узлов. +Например, вы можете ограничить Под, иметь право на запуск только на группе доступных узлов. -Маркировка узла как неназначаемого предотвращает размещение планировщиком новых подов на этом Узле, +Маркировка узла как не назначаемого предотвращает размещение планировщиком новых подов на этом Узле, но не влияет на существующие Поды на Узле. Это полезно в качестве подготовительного шага перед перезагрузкой узла или другим обслуживанием. -Чтобы отметить Узел неназначемым, выполните: +Чтобы отметить Узел не назначаемым, выполните: ```shell kubectl cordon $NODENAME @@ -111,7 +111,7 @@ kubectl cordon $NODENAME {{< note >}} Поды, являющиеся частью {{< glossary_tooltip term_id="daemonset" >}} допускают -запуск на неназначаемом Узле. DaemonSets обычно обеспечивает локальные сервисы узла, +запуск на не назначаемом Узле. DaemonSets обычно обеспечивает локальные сервисы узла, которые должны запускаться на Узле, даже если узел вытесняется для запуска приложений. {{< /note >}} @@ -157,7 +157,7 @@ kubectl describe node {{< note >}} Если вы используете инструменты командной строки для вывода сведений об блокированном узле, то Условие включает `SchedulingDisabled`. `SchedulingDisabled` не является Условием в Kubernetes API; -вместо этого блокированные узлы помечены как Неназначемые в их спецификации. +вместо этого блокированные узлы помечены как Не назначаемые в их спецификации. {{< /note >}} Состояние узла представлено в виде JSON объекта. Например, следующая структура описывает здоровый узел: @@ -203,8 +203,8 @@ kubectl describe node Описывает ресурсы, доступные на узле: CPU, память и максимальное количество подов, которые могут быть запланированы на узле. -Поля в блоке capasity указывают общее количество ресурсов, которые есть на Узле. -Блок allocatable указывает количество ресурсовна Узле, +Поля в блоке capacity указывают общее количество ресурсов, которые есть на Узле. +Блок allocatable указывает количество ресурсов на Узле, которые доступны для использования обычными Подами. Вы можете прочитать больше о емкости и выделяемых ресурсах, изучая, как [зарезервировать вычислительные ресурсы](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) на Узле. @@ -212,7 +212,7 @@ kubectl describe node ### Информация (Info) Описывает общую информацию об узле, такую как версия ядра, версия Kubernetes (версии kubelet и kube-proxy), версия Docker (если используется) и название ОС. -Эта информация соберается Kubelet'ом на узле. +Эта информация собирается Kubelet'ом на узле. ### Контроллер узла @@ -247,16 +247,16 @@ ConditionUnknown, когда узел становится недоступны [Lease объект](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io). Каждый узел имеет связанный с ним Lease объект в `kube-node-lease` {{< glossary_tooltip term_id="namespace" text="namespace">}}. -Lease - это легковестный ресурс, который улучшает производительность +Lease - это легковесный ресурс, который улучшает производительность сердцебиений узла при масштабировании кластера. -Kubelet отвечает за создание и обновление `NodeStatus` и Lease объекта. +Kubelet отвечает за создание и обновление `NodeStatus` и Lease объекта. - Kubelet обновляет `NodeStatus` либо когда происходит изменение статуса, - либо если в течение настронного интервала обновления не было. По умолчанию + либо если в течение настроенного интервала обновления не было. По умолчанию интервал для обновлений `NodeStatus` составляет 5 минут (намного больше, чем 40-секундный стандартный таймаут для недоступных узлов). -- Kubelet созадет и затем обновляет свой Lease объект каждый 10 секунд +- Kubelet создает и затем обновляет свой Lease объект каждый 10 секунд (интервал обновления по умолчанию). Lease обновления происходят независимо от `NodeStatus` обновлений. Если обновление Lease завершается неудачно, kubelet повторяет попытку с экспоненциальным откатом, начинающимся с 200 миллисекунд и ограниченным 7 секундами. @@ -265,7 +265,7 @@ Kubelet отвечает за создание и обновление `NodeStat В большинстве случаев контроллер узла ограничивает скорость выселения до `--node-eviction-rate` (по умолчанию 0,1) в секунду, что означает, -что он не выселяет поды с узлов быстрее чем c 1 узела в 10 секунд. +что он не выселяет поды с узлов быстрее чем с одного узла в 10 секунд. Поведение выселения узла изменяется, когда узел в текущей зоне доступности становится нездоровым. Контроллер узла проверяет, какой процент узлов в зоне @@ -288,26 +288,26 @@ Kubelet отвечает за создание и обновление `NodeStat выселяет поды с нормальной скоростью `--node-eviction-rate`. Крайний случай - когда все зоны полностью нездоровы (т.е. в кластере нет здоровых узлов). В таком случае контроллер узла предполагает, что существует некоторая проблема с подключением к мастеру, -и останавеливает все выселения, пока какое-нибудь подключение не будет восстановлено. +и останавливает все выселения, пока какое-нибудь подключение не будет восстановлено. Контроллер узла также отвечает за выселение подов, запущенных на узлах с `NoExecute` ограничениями, за исключением тех подов, которые сопротивляются этим ограничениям. Контроллер узла так же добавляет {{< glossary_tooltip text="ограничения" term_id="taint" >}} -соотвествующие проблемам узла, таким как узел недоступен или не готов. Это означает, +соответствующие проблемам узла, таким как узел недоступен или не готов. Это означает, что планировщик не будет размещать поды на нездоровых узлах. {{< caution >}} -`kubectl cordon` помечает узел как 'неназначемый', что имеет побочный эфект от контроллера сервисов, +`kubectl cordon` помечает узел как 'не назначаемый', что имеет побочный эффект от контроллера сервисов, удаляющего узел из любых списков целей LoadBalancer узла, на которые он ранее имел право, -эффектино убирая входящий трафик балансировщика нагрузки с блокированного узла(ов). +эффективно убирая входящий трафик балансировщика нагрузки с блокированного узла(ов). {{< /caution >}} ### Емкость узла Объекты узла отслеживают информацию о емкости ресурсов узла (например, объем доступной памяти и количество CPU). -Узлы, которые [самостоятельно зарегистировались](#саморегистрация-узлов) сообщают -о свое емкости во время регистрации. Если вы [вручную](#ручное-администрирование-узла) +Узлы, которые [самостоятельно зарегистрировались](#саморегистрация-узлов), сообщают +о своей емкости во время регистрации. Если вы [вручную](#ручное-администрирование-узла) добавляете узел, то вам нужно задать информацию о емкости узла при его добавлении. {{< glossary_tooltip text="Планировщик" term_id="kube-scheduler" >}} Kubernetes гарантирует, @@ -318,7 +318,7 @@ Kubelet отвечает за создание и обновление `NodeStat а также исключает любые процессы, запущенные вне контроля kubelet. {{< note >}} -Если вы явно хотите зарезервировать ресурсы для процессов, не связанныз с Подами, смотрите раздел +Если вы явно хотите зарезервировать ресурсы для процессов, не связанных с Подами, смотрите раздел [зарезервировать ресурсы для системных демонов](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved). {{< /note >}} @@ -339,4 +339,4 @@ Kubelet отвечает за создание и обновление `NodeStat * Подробнее про [Узлы](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) of the architecture design document. * Подробнее про [ограничения и допуски](/docs/concepts/configuration/taint-and-toleration/). -* Подробнее про [автомаштабирование кластера](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling). +* Подробнее про [авто масштабирование кластера](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling). From 0c259797db186ad73214f96b036614b6c2745337 Mon Sep 17 00:00:00 2001 From: Ilya Z Date: Sat, 26 Mar 2022 23:18:08 +0400 Subject: [PATCH 08/32] cluster_admin_typos --- .../concepts/cluster-administration/_index.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/content/ru/docs/concepts/cluster-administration/_index.md b/content/ru/docs/concepts/cluster-administration/_index.md index b596e111f3..77f610bf18 100644 --- a/content/ru/docs/concepts/cluster-administration/_index.md +++ b/content/ru/docs/concepts/cluster-administration/_index.md @@ -11,7 +11,7 @@ no_list: true --- -Обзор администрирования кластера предназначен для всех, кто создает или администрирует кластер Kubernetes. Это предполагает некоторое знакомство с основными [концепциями] (/docs/concepts/) Kubernetes. +Обзор администрирования кластера предназначен для всех, кто создает или администрирует кластер Kubernetes. Это предполагает некоторое знакомство с основными [концепциями](/docs/concepts/) Kubernetes. @@ -19,19 +19,19 @@ no_list: true См. Руководства в разделе [настройка](/docs/setup/) для получения примеров того, как планировать, устанавливать и настраивать кластеры Kubernetes. Решения, перечисленные в этой статье, называются *distros*. - {{< note >}} + {{< note >}} не все дистрибутивы активно поддерживаются. Выбирайте дистрибутивы, протестированные с последней версией Kubernetes. {{< /note >}} Прежде чем выбрать руководство, вот некоторые соображения: - - Вы хотите опробовать Kubernetes на вашем компьюторе или собрать многоузловой кластер высокой доступности? Выбирайте дистрибутивы, наиболее подходящие для ваших нужд. - - будете ли вы использовать **размещенный кластер Kubernetes**, такой как [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) или **разместите собственный кластер**? - - Будет ли ваш кластер **в помещений** или **в облаке (IaaS)**? Kubernetes не поддерживает напрямую гибридные кластеры. Вместо этого вы можете настроить несколько кластеров. - - **Если вы будете настроаивать Kubernetes в помещений (локально)**, подумайте, какая [сетевая модель](/docs/concepts/cluster-administration/networking/) подходит лучше всего. - - Будете ли вы запускать Kubernetes на **оборудований "bare metal"** или на **вирутальных машинах (VMs)**? - - Вы хотите **запустить кластер** или планируете **активно разворачивать код проекта Kubernetes**? В последнем случае выберите активно разрабатываемый дистрибутив. Некоторые дистрибутивы используют только двоичные выпуски, но предлагают болле широкий выбор. - - Ознакомьтесь с [компонентами](/docs/concepts/overview/components/) необходивые для запуска кластера. + - Вы хотите опробовать Kubernetes на вашем компьютере или собрать много узловой кластер высокой доступности? Выбирайте дистрибутивы, наиболее подходящие для ваших нужд. + - Будете ли вы использовать **размещенный кластер Kubernetes**, такой, как [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) или **разместите собственный кластер**? + - Будет ли ваш кластер **в помещении** или **в облаке (IaaS)**? Kubernetes не поддерживает напрямую гибридные кластеры. Вместо этого вы можете настроить несколько кластеров. + - **Если вы будете настраивать Kubernetes в помещении (локально)**, подумайте, какая [сетевая модель](/docs/concepts/cluster-administration/networking/) подходит лучше всего. + - Будете ли вы запускать Kubernetes на **оборудований "bare metal"** или на **виртуальных машинах (VMs)**? + - Вы хотите **запустить кластер** или планируете **активно разворачивать код проекта Kubernetes**? В последнем случае выберите активно разрабатываемый дистрибутив. Некоторые дистрибутивы используют только двоичные выпуски, но предлагают более широкий выбор. + - Ознакомьтесь с [компонентами](/docs/concepts/overview/components/) необходимые для запуска кластера. ## Управление кластером @@ -54,7 +54,7 @@ no_list: true * [Использование контроллеров допуска](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization. -* [Использование Sysctls в кластере Kubernetes](/docs/tasks/administer-cluster/sysctl-cluster/) описывает администратору, как использовать sysctlинструмент командной строки для установки параметров ядра. +* [Использование Sysctls в кластере Kubernetes](/docs/tasks/administer-cluster/sysctl-cluster/) описывает администратору, как использовать sysctl инструмент командной строки для установки параметров ядра. * [Аудит](/docs/tasks/debug-application-cluster/audit/) описывает, как взаимодействовать с журналами аудита Kubernetes. From 026b8773ffc530ab387f7a2117287384d110be92 Mon Sep 17 00:00:00 2001 From: Ilya Z Date: Sat, 26 Mar 2022 23:40:25 +0400 Subject: [PATCH 09/32] addons_typos --- .../concepts/cluster-administration/addons.md | 26 +++++++++---------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/content/ru/docs/concepts/cluster-administration/addons.md b/content/ru/docs/concepts/cluster-administration/addons.md index e86d485949..7e93ef82b2 100644 --- a/content/ru/docs/concepts/cluster-administration/addons.md +++ b/content/ru/docs/concepts/cluster-administration/addons.md @@ -13,33 +13,33 @@ content_type: concept -## Сеть и сетевыя политика +## Сеть и сетевая политика * [ACI](https://www.github.com/noironetworks/aci-containers) обеспечивает интегрированную сеть контейнеров и сетевую безопасность с помощью Cisco ACI. * [Antrea](https://antrea.io/) работает на уровне 3, обеспечивая сетевые службы и службы безопасности для Kubernetes, используя Open vSwitch в качестве уровня сетевых данных. * [Calico](https://docs.projectcalico.org/latest/introduction/) Calico поддерживает гибкий набор сетевых опций, поэтому вы можете выбрать наиболее эффективный вариант для вашей ситуации, включая сети без оверлея и оверлейные сети, с или без BGP. Calico использует тот же механизм для обеспечения соблюдения сетевой политики для хостов, модулей и (при использовании Istio и Envoy) приложений на уровне сервисной сети (mesh layer). -* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) объединяет Flannel и Calico, обеспечивая сеть и сетевую политик. +* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) объединяет Flannel и Calico, обеспечивая сеть и сетевую политику. * [Cilium](https://github.com/cilium/cilium) - это плагин сети L3 и сетевой политики, который может прозрачно применять политики HTTP/API/L7. Поддерживаются как режим маршрутизации, так и режим наложения/инкапсуляции, и он может работать поверх других подключаемых модулей CNI. * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) позволяет Kubernetes легко подключаться к выбору плагинов CNI, таких как Calico, Canal, Flannel, Romana или Weave. -* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), основан на [Tungsten Fabric](https://tungsten.io), представляет собой платформу для виртуализации мультиоблачных сетей с открытым исходным кодом и управления политиками. Contrail и Tungsten Fabric are интегрированы с системами оркестровки, такими как Kubernetes, OpenShift, OpenStack и Mesos, и обеспечивают режимы изоляции для виртуальных машин, контейнеров/pod-ов и рабочих нагрузок без операционной системы. +* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), основан на [Tungsten Fabric](https://tungsten.io), представляет собой платформу для виртуализации мультиоблачных сетей с открытым исходным кодом и управления политиками. Contrail и Tungsten Fabric интегрированы с системами оркестрации, такими как Kubernetes, OpenShift, OpenStack и Mesos, и обеспечивают режимы изоляции для виртуальных машин, контейнеров/подов и рабочих нагрузок без операционной системы. * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) - это поставщик оверлейной сети, который можно использовать с Kubernetes. -* [Knitter](https://github.com/ZTE/Knitter/) - это плагин для поддержки нескольких сетевых интерфейсов Kubernetes pod-ов. -* Multus - это плагин Multi для поддержки нексольких сетейв Kubernetes для поддержки всех CNI плагинов (наприме: Calico, Cilium, Contiv, Flannel), в дополнение к рабочим нагрузкам основанных на SRIOV, DPDK, OVS-DPDK и VPP в Kubernetes. -* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) - это сетевой провайдер для Kubernetes основанный на [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), реализация виртуалной сети a появившейся в результате проекта Open vSwitch (OVS). OVN-Kubernetes обеспечивает сетевую реализацию на основе наложения для Kubernetes, включая реализацию балансировки нагрузки и сетевой политики на основе OVS. -* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) - это подключаемый модуль контроллера CNI на основе OVN для обеспечения облачной цепочки сервисных функций (SFC), несколько наложеных сетей OVN, динамического создания подсети, динамического создания виртуальных сетей, сети поставщика VLAN, сети прямого поставщика и подключаемого к другим Multi Сетевые плагины, идеально подходящие для облачных рабочих нагрузок на периферии в сети с несколькими кластерами. +* [Knitter](https://github.com/ZTE/Knitter/) - это плагин для поддержки нескольких сетевых интерфейсов Kubernetes подов. +* [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) - это плагин Multi для работы с несколькими сетями в Kubernetes, который поддерживает большинство самых популярных [CNI](https://github.com/containernetworking/cni) (например: Calico, Cilium, Contiv, Flannel), в дополнение к рабочим нагрузкам основанных на SRIOV, DPDK, OVS-DPDK и VPP в Kubernetes. +* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) - это сетевой провайдер для Kubernetes основанный на [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), реализация виртуальной сети, появившийся в результате проекта Open vSwitch (OVS). OVN-Kubernetes обеспечивает сетевую реализацию на основе наложения для Kubernetes, включая реализацию балансировки нагрузки и сетевой политики на основе OVS. +* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) - это подключаемый модуль контроллера CNI на основе OVN для обеспечения облачной цепочки сервисных функций (SFC), несколько наложенных сетей OVN, динамического создания подсети, динамического создания виртуальных сетей, сети поставщика VLAN, сети прямого поставщика и подключаемого к другим Multi Сетевые плагины, идеально подходящие для облачных рабочих нагрузок на периферии в сети с несколькими кластерами. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) плагин для контейнера (NCP) обеспечивающий интеграцию между VMware NSX-T и контейнерами оркестраторов, таких как Kubernetes, а так же интеграцию между NSX-T и контейнеров на основе платформы CaaS/PaaS, таких как Pivotal Container Service (PKS) и OpenShift. -* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) - эта платформа SDN, которая обеспечивает сетевое взаимодействие на основе политик между Kubernetes Pod-ами и не Kubernetes окружением с отображением и мониторингом безопасности. -* [Romana](https://romana.io) - это сетевое решение уровня 3 для pod сетей, которое также поддерживает [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Подробности установки Kubeadm доступны [здесь](https://github.com/romana/romana/tree/master/containerize). -* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) обеспечивает сетевуюи политику сетей, будет работать в сетевого раздела и не требует внешней базы данных. +* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) - эта платформа SDN, которая обеспечивает сетевое взаимодействие на основе политик между Kubernetes подами и не Kubernetes окружением, с отображением и мониторингом безопасности. +* [Romana](https://romana.io) - это сетевое решение уровня 3 для сетей подов, которое также поддерживает [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Подробности установки Kubeadm доступны [здесь](https://github.com/romana/romana/tree/master/containerize). +* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) предоставляет сеть и обеспечивает сетевую политику, будет работать на обеих сторонах сетевого раздела и не требует внешней базы данных. ## Обнаружение служб -* [CoreDNS](https://coredns.io) - это гибкий, расширяемый DNS-сервер, который может быть [установлен](https://github.com/coredns/deployment/tree/master/kubernetes) в качестве внутрикластерного DNS для pod-ов. +* [CoreDNS](https://coredns.io) - это гибкий, расширяемый DNS-сервер, который может быть [установлен](https://github.com/coredns/deployment/tree/master/kubernetes) в качестве внутрикластерного DNS для подов. ## Визуализация и контроль * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) - это веб-интерфейс панели инструментов для Kubernetes. -* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) - это инструмент для графической визуализации ваших контейнеров, pod-ов, сервисов и т.д. Используйте его вместе с [учетной записью Weave Cloud](https://cloud.weave.works/) или разместите пользовательский интерфейс самостоятельно. +* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) - это инструмент для графической визуализации ваших контейнеров, подов, сервисов и т.д. Используйте его вместе с [учетной записью Weave Cloud](https://cloud.weave.works/) или разместите пользовательский интерфейс самостоятельно. ## Инфраструктура @@ -49,4 +49,4 @@ content_type: concept В устаревшем каталоге [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) задокументировано несколько других дополнений. -Ссылки на те, в хорошем состоянии, должны быть здесь. PR приветствуются! +Ссылки на те, в хорошем состоянии, должны быть здесь. Пул реквесты приветствуются! From 6525c0cab5d755aa3a1baf4bb172266bbd2c2f4b Mon Sep 17 00:00:00 2001 From: Ilya Z Date: Sat, 26 Mar 2022 23:55:11 +0400 Subject: [PATCH 10/32] kube_api_typos --- content/ru/docs/concepts/overview/kubernetes-api.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/content/ru/docs/concepts/overview/kubernetes-api.md b/content/ru/docs/concepts/overview/kubernetes-api.md index e2523c5191..e9a3debbc3 100644 --- a/content/ru/docs/concepts/overview/kubernetes-api.md +++ b/content/ru/docs/concepts/overview/kubernetes-api.md @@ -36,7 +36,7 @@ Kubernetes как таковой состоит из множества комп Все детали API документируется с использованием [OpenAPI](https://www.openapis.org/). Начиная с Kubernetes 1.10, API-сервер Kubernetes основывается на спецификации OpenAPI через конечную точку `/openapi/v2`. -Нужный формат устанавливается через HTTP-заголовоки: +Нужный формат устанавливается через HTTP-заголовки: Заголовок | Возможные значения ------ | --------------- @@ -61,11 +61,11 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github Чтобы упростить удаления полей или изменение ресурсов, Kubernetes поддерживает несколько версий API, каждая из которых доступна по собственному пути, например, `/api/v1` или `/apis/extensions/v1beta1`. -Мы выбрали версионирование API, а не конкретных ресурсов или полей, чтобы API отражал четкое и согласованное представление о системных ресурсах и их поведении, а также, чтобы разграничивать API, которые уже не поддерживаются и/или находятся в экспериментальной стадии. Схемы сериализации JSON и Protobuf следуют одним и тем же правилам по внесению изменений в схему, поэтому описание ниже охватывают оба эти формата. +Мы выбрали версионирование API, а не конкретных ресурсов или полей, чтобы API отражал четкое и согласованное представление о системных ресурсах и их поведении, а также, чтобы разграничивать API, которые уже не поддерживаются и/или находятся в экспериментальной стадии. Схемы сериализации JSON и Protobuf следуют одним и тем же правилам по внесению изменений в схему, поэтому описание ниже охватывают оба эти формата. -Обратите внимание, что версиоирование API и программное обеспечение косвенно связаны друг с другом. [Предложение по версионированию API и новых выпусков](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) описывает, как связаны между собой версии API с версиями программного обеспечения. +Обратите внимание, что версионирование API и программное обеспечение косвенно связаны друг с другом. [Предложение по версионированию API и новых выпусков](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) описывает, как связаны между собой версии API с версиями программного обеспечения. -Разные версии API имеют характеризуются разной уровнем стабильностью и поддержкой. Критерии каждого уровня более подробно описаны в [документации изменений API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). Ниже приводится краткое изложение: +Разные версии API характеризуются разными уровнями стабильности и поддержки. Критерии каждого уровня более подробно описаны в [документации изменений API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). Ниже приводится краткое изложение: - Альфа-версии: - Названия версий включают надпись `alpha` (например, `v1alpha1`). @@ -79,7 +79,7 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github - Поддержка функциональности в целом не будет прекращена, хотя кое-что может измениться. - Схема и/или семантика объектов может стать несовместимой с более поздними бета-версиями или стабильными выпусками. Когда это случится, мы даем инструкции по миграции на следующую версию. Это обновление может включать удаление, редактирование и повторного создание API-объектов. Этот процесс может потребовать тщательного анализа. Кроме этого, это может привести к простою приложений, которые используют данную функциональность. - Рекомендуется только для неосновного производственного использования из-за риска возникновения возможных несовместимых изменений с будущими версиями. Если у вас есть несколько кластеров, которые возможно обновить независимо, вы можете снять это ограничение. - - **Пожалуйста, попробуйте в действии бета-версии функциональности и поделитесь своими впечатлениями! После того, как функциональность выйдет из бета-версии, нам может быть нецелесообразно что-то дальше изменять.** + - **Пожалуйста, попробуйте в действии бета-версии функциональности и поделитесь своими впечатлениями! После того как функциональность выйдет из бета-версии, нам может быть нецелесообразно что-то дальше изменять.** - Стабильные версии: - Имя версии `vX`, где `vX` — целое число. - Стабильные версии функциональностей появятся в новых версиях. @@ -113,5 +113,3 @@ DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies и Re Например: чтобы включить deployments и daemonsets, используйте флаг `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`. {{< note >}}Включение/отключение отдельных ресурсов поддерживается только в API-группе `extensions/v1beta1` по историческим причинам.{{< /note >}} - - From 6319b586d6df260b46e013fc1a385af6a543f7be Mon Sep 17 00:00:00 2001 From: Ilya Z Date: Sun, 27 Mar 2022 01:03:40 +0400 Subject: [PATCH 11/32] content-guide_fix --- .../ru/docs/contribute/style/content-guide.md | 80 +++++++++---------- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/content/ru/docs/contribute/style/content-guide.md b/content/ru/docs/contribute/style/content-guide.md index bfb0073357..58cbc6af7c 100644 --- a/content/ru/docs/contribute/style/content-guide.md +++ b/content/ru/docs/contribute/style/content-guide.md @@ -25,72 +25,72 @@ card: ### Контент, полученный из двух источников -Документация Kubernetes не содержит дублированный контент, полученный из разных мест (так называемый **контент из двумя источниками**). Контент из двух источников требует дублирования работы со стороны мейнтейнеров проекта и к тому же быстро теряет актуальность. +Документация Kubernetes не содержит дублированный контент, полученный из разных мест (так называемый **контент из двух источников**). Контент из двух источников требует дублирования работы со стороны мейнтейнеров проекта и к тому же быстро теряет актуальность. Перед добавлением контента, задайте себе вопрос: -- Новая информация относится к действующему проекту CNCF ИЛИ проекту в организациях на GitHub kubernetes или kubernetes-sigs? +- Новая информация относится к действующему проекту CNCF или проекту в организациях на GitHub kubernetes или kubernetes-sigs? - Если да, то: - У этого проекта есть собственная документация? - - если да, то укажите ссылку на документацию проекта в документации Kubernetes - - если нет, добавьте информацию в репозиторий проекта (если это возможно), а затем укажите ссылку на неё в документации Kubernetes + - если да, то укажите ссылку на документацию проекта в документации Kubernetes. + - если нет, добавьте информацию в репозиторий проекта (если это возможно), а затем укажите ссылку на неё в документации Kubernetes. - Если нет, то: - Остановитесь! - - Добавление информации по продуктам от других разработчиков не допускается + - Добавление информации о продуктах от других разработчиков не допускается. - Не разрешено ссылаться на документацию и сайты сторонних разработчиков. ### Разрешенная и запрещённая информация Есть несколько условий, когда в документации Kubernetes может быть информация, относящиеся не к проектам Kubernetes. -Ниже перечислены основные категории по содержанию проектов, не касающихся к Kubernetes, а также приведены рекомендации о том, что разрешено, а что нет: +Ниже перечислены основные категории по содержанию проектов, не касающихся Kubernetes, а также приведены рекомендации о том, что разрешено, а что нет: -1. Инструкции по установке или эксплуатации Kubernetes, которые не связаны с проектами Kubernetes +1. Инструкции по установке или эксплуатации Kubernetes, которые не связаны с проектами Kubernetes. - Разрешено: - - Ссылаться на документацию на CNCF-проекта или на проект в GitHub-организациях kubernetes или kubernetes-sigs - - Пример: для установки Kubernetes в процессе обучения нужно обязательно установить и настроить minikube, а также сослаться на соответствующую документацию minikube - - Добавление инструкций для проектов в организации kubernetes или kubernetes-sigs, если по ним нет инструкций - - Пример: добавление инструкций по установке и решению неполадок [kubadm](https://github.com/kubernetes/kubeadm) + - Ссылаться на документацию CNCF-проекта или на проект в GitHub-организациях kubernetes или kubernetes-sigs. + - Пример: для установки Kubernetes в процессе обучения нужно обязательно установить и настроить minikube, а также сослаться на соответствующую документацию minikube. + - Добавление инструкций для проектов в организации kubernetes или kubernetes-sigs, если по ним нет инструкций. + - Пример: добавление инструкций по установке и решению неполадок [kubeadm](https://github.com/kubernetes/kubeadm). - Запрещено: - - Добавление информацию, которая повторяет документацию в другом репозитории + - Добавление информации, которая дублирует документацию в другом репозитории. - Примеры: - - Добавление инструкций по установке и настройке minikube; Minikube имеет собственную [документацию](https://minikube.sigs.k8s.io/docs/), которая включают эти инструкции - - Добавление инструкций по установке Docker, CRI-O, containerd и других окружений для выполнения контейнеров в разных операционных системах + - Добавление инструкций по установке и настройке minikube; Minikube имеет собственную [документацию](https://minikube.sigs.k8s.io/docs/), которая включают эти инструкции. + - Добавление инструкций по установке Docker, CRI-O, containerd и других окружений для выполнения контейнеров в разных операционных системах. - Добавление инструкций по установке Kubernetes в промышленных окружениях, используя разные проекты: - -Kubernetes Rebar Integrated Bootstrap (KRIB) — это проект стороннего разработчика, поэтому все содержимое находится репозитории разработчика. + - Kubernetes Rebar Integrated Bootstrap (KRIB) — это проект стороннего разработчика, поэтому всё содержимое находится в репозитории разработчика. - У проекта [Kubernetes Operations (kops)](https://github.com/kubernetes/kops) есть инструкции по установке и руководства в GitHub-репозитории. - - У проекта [Kubespray](https://kubespray.io) есть собственная документация - - Добавление руководства, в котором объясняется, как выполнить задачу с использованием продукта определенного разработчика или проекта с открытым исходным кодом, не являющиеся CNCF-проектом или проектом в GitHub-организациях kubernetes или kubnetes-sigs. - - Добавление руководства по использованию CNCF-проекта или проекта в GitHub-организациях kubernetes или kubnetes-sigs, если у проекта есть собственная документация -1. Подробное описание технических аспектов по использованию стороннего проекта (не Kubernetes) или как этот проект разработан + - У проекта [Kubespray](https://kubespray.io) есть собственная документация. + - Добавление руководства, в котором объясняется, как выполнить задачу с использованием продукта определенного разработчика или проекта с открытым исходным кодом, не являющиеся CNCF-проектами или проектом в GitHub-организациях kubernetes, или kubernetes-sigs. + - Добавление руководства по использованию CNCF-проекта или проекта в GitHub-организациях kubernetes или kubernetes-sigs, если у проекта есть собственная документация. +1. Подробное описание технических аспектов по использованию стороннего проекта (не Kubernetes) или как этот проект разработан. Добавление такого типа информации в документацию Kubernetes не допускается. -1. Информация стороннему проекту +1. Информация стороннему проекту. - Разрешено: - - Добавление краткого введения о CNCF-проекте или проекте в GitHub-организациях kubernetes или kubernetes-sigs; этот абзац может содержать ссылки на проект + - Добавление краткого введения о CNCF-проекте или проекте в GitHub-организациях kubernetes или kubernetes-sigs; этот абзац может содержать ссылки на проект. - Запрещено: - - Добавление информации по продукту определённого разработчика - - Добавление информации по проекту с открытым исходным кодом, который не является CNCF-проектом или проектом в GitHub-организациях kubernetes или kubnetes-sigs - - Добавление информации, дублирующего документацию из другого проекта, независимо от оригинального репозитория - - Пример: добавление документации для проекта [Kubernetes in Docker (KinD)](https://kind.sigs.k8s.io) в документацию Kubernetes -1. Только ссылки на сторонний проект + - Добавление информации по продукту определённого разработчика. + - Добавление информации по проекту с открытым исходным кодом, который не является CNCF-проектом или проектом в GitHub-организациях kubernetes или kubernetes-sigs. + - Добавление информации, дублирующего документацию из другого проекта, независимо от оригинального репозитория. + - Пример: добавление документации для проекта [Kubernetes in Docker (KinD)](https://kind.sigs.k8s.io) в документацию Kubernetes. +1. Только ссылки на сторонний проект. - Разрешено: - - Ссылаться на проекты в GitHub-организациях kubernetes и kubernetes-sigs - - Пример: добавление ссылок на [документацию](https://kind.sigs.k8s.io/docs/user/quick-start) проекта Kubernetes in Docker (KinD), который находится в GitHub-организации kubernetes-sigs - - Добавление ссылок на действующие CNCF-проекты - - Пример: добавление ссылок на [документацию](https://prometheus.io/docs/introduction/overview/) проекта Prometheus; Prometheus — это действующий проект CNCF + - Ссылаться на проекты в GitHub-организациях kubernetes и kubernetes-sigs. + - Пример: добавление ссылок на [документацию](https://kind.sigs.k8s.io/docs/user/quick-start) проекта Kubernetes in Docker (KinD), который находится в GitHub-организации kubernetes-sigs. + - Добавление ссылок на действующие CNCF-проекты. + - Пример: добавление ссылок на [документацию](https://prometheus.io/docs/introduction/overview/) проекта Prometheus; Prometheus — это действующий проект CNCF. - Запрещено: - - Ссылаться на продукты стороннего разработчика - - Ссылаться на архивированные проекты CNCF - - Ссылаться на недействующие проекты в организациях GitHub в kubernetes и kubernetes-sigs - - Ссылаться на проекты с открытым исходным кодом, которые не являются проектами CNCF или не находятся в организациях GitHub kubernetes или kubernetes-sigs. -1. Содержание учебных курсов + - Ссылаться на продукты стороннего разработчика. + - Ссылаться на прекращенные проекты CNCF. + - Ссылаться на недействующие проекты в организациях GitHub в kubernetes и kubernetes-sigs. + - Ссылаться на проекты с открытым исходным кодом, которые не являются проектами CNCF или не находятся в организациях GitHub kubernetes, или kubernetes-sigs. +1. Содержание учебных курсов. - Разрешено: - - Ссылаться на независимые от разработчиков учебные курсы Kubernetes, предлагаемыми [CNCF](https://www.cncf.io/), [Linux Foundation](https://www.linuxfoundation.org/) и [Linux Academy](https://linuxacademy.com/) (партнер Linux Foundation) - - Пример: добавление ссылок на курсы Linux Academy, такие как [Kubernetes Quick Start](https://linuxacademy.com/course/kubernetes-quick-start/) в [Kubernetes Security](https://linuxacademy.com/course/kubernetes-security/) + - Ссылаться на независимые от разработчиков учебные курсы Kubernetes, предлагаемыми [CNCF](https://www.cncf.io/), [Linux Foundation](https://www.linuxfoundation.org/) и [Linux Academy](https://linuxacademy.com/) (партнер Linux Foundation). + - Пример: добавление ссылок на курсы Linux Academy, такие как [Kubernetes Quick Start](https://linuxacademy.com/course/kubernetes-quick-start/) и [Kubernetes Security](https://linuxacademy.com/course/kubernetes-security/). - Запрещено: - - Ссылаться на учебныЕе онлайн-курсы, вне CNCF, Linux Foundation или Linux Academy; документация Kubernetes не содержит ссылок на сторонний контент + - Ссылаться на учебные онлайн-курсы, не относящиеся к CNCF, Linux Foundation или Linux Academy; документация Kubernetes не содержит ссылок на сторонний контент. - Пример: добавление ссылок на учебные руководства или курсы Kubernetes на Medium, KodeKloud, Udacity, Coursera, learnk8s и т.д. - - Ссылаться на руководства определённых разработчиков вне зависимости от обучающей организации - - Пример: добавление ссылок на такие курсы Linux Academy, как [Google Kubernetes Engine Deep Dive](https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive) and [Amazon EKS Deep Dive](https://linuxacademy.com/course/amazon-eks-deep-dive/) + - Ссылаться на руководства определённых разработчиков вне зависимости от обучающей организации. + - Пример: добавление ссылок на такие курсы Linux Academy, как [Google Kubernetes Engine Deep Dive](https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive) и [Amazon EKS Deep Dive](https://linuxacademy.com/course/amazon-eks-deep-dive/) Если у вас есть вопросы по поводу допустимого контента, присоединяйтесь к каналу #sig-docs в [Slack Kubernetes](http://slack.k8s.io/)! From 9f0afaf0c344e1f81328ec22e43ffc0667219344 Mon Sep 17 00:00:00 2001 From: Ilya Z Date: Sun, 27 Mar 2022 01:41:03 +0400 Subject: [PATCH 12/32] advanced_guide_edited --- content/ru/docs/contribute/advanced.md | 76 +++++++++++++------------- 1 file changed, 37 insertions(+), 39 deletions(-) diff --git a/content/ru/docs/contribute/advanced.md b/content/ru/docs/contribute/advanced.md index dfe68fa685..bb4ff9a35f 100644 --- a/content/ru/docs/contribute/advanced.md +++ b/content/ru/docs/contribute/advanced.md @@ -1,5 +1,5 @@ --- -title: Участие для опытных +title: Существенный вклад slug: advanced content_type: concept weight: 30 @@ -22,20 +22,20 @@ weight: 30 - Ежедневно проверять [открытые пулреквесты](https://github.com/kubernetes/website/pulls) для контроля качества и соблюдения рекомендаций по [оформлению](/docs/contribute/style/style-guide/) и [содержимому](/docs/contribute/style/content-guide/). - В первую очередь просматривайте самые маленькие пулреквесты (`size/XS`), и только потом беритесь за самые большие (`size/XXL`). - Проверяйте столько пулреквестов, сколько сможете. -- Проследить, что CLA подписан каждым участником. +- Проследите, что CLA подписан каждым участником. - Помогайте новым участникам подписать [CLA](https://github.com/kubernetes/community/blob/master/CLA.md). - - Используйте [этот](https://github.com/zparnold/k8s-docs-pr-botherer) скрипт, чтобы автоматически напомнить участникам, не подписавшим CLA, чтобы они подписали CLA. + - Используйте [этот](https://github.com/zparnold/k8s-docs-pr-botherer) скрипт, чтобы автоматически напомнить участникам, не подписавшим CLA, подписать его. - Оставить свое мнение о предложенных изменениях и поспособствовать в проведении технического обзора от членов других SIG-групп. - Предложить исправления для измененного контента в PR. - Если вы хотите убедиться в правильности контента, прокомментируйте PR и задайте уточняющие вопросы. - - Добавьте нужны метки с `sig/`. - - Если нужно, то назначьте рецензентов из секции `reviewers:` в фронтальной части файла. + - Добавьте нужные метки с `sig/`. + - Если нужно, то назначьте рецензентов из секции `reviewers:` в верхней части файла. - Добавьте метки `Docs Review` и `Tech Review` для установки статуса проверки PR. - Добавьте метку `Needs Doc Review` или `Needs Tech Review` для пулреквестов, которые ещё не были проверены. - Добавьте метку `Doc Review: Open Issues` или `Tech Review: Open Issues` для пулреквестов, которые были проверены и требуют дополнительную информацию и выполнение действия перед слиянием. - Добавьте метки `/lgtm` и `/approve` для пулреквестов, которые могут быть приняты. - Объедините пулреквесты, если они готовы, либо закройте те, которые не могут быть приняты. -- Ежедневно отсортируйте и пометьте новые заявки. Обратитесь к странице [Участие для опытных](/ru/docs/contribute/intermediate/) для получения информации по использование метаданных SIG Docs. +- Ежедневно отсортируйте и пометьте новые заявки. Обратитесь к странице [Участие для опытных](/ru/docs/contribute/intermediate/) для получения информации по использованию метаданных SIG Docs. ### Полезные ссылки на GitHub для дежурных @@ -43,9 +43,9 @@ weight: 30 - [Нет CLA, нет права на слияние](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): напомните участнику подписать CLA. Если об этом уже напомнил и бот, и человек, то закройте PR и напишите автору, что он может открыть свой PR после подписания CLA. **Не проверяйте PR, если их авторы не подписали CLA!** -- [Требуется LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): если нужен проверка с технической точки зрения, попросите её провести одного из рецензентов, который предложил бот. Если требуется просмотр пулреквест со стороны группы документации или вычитка, то предложите изменения, либо сами измените PR, чтобы ускорить процесс принятия пулреквеста. -- [Имеет LGTM, нужно одобрение со стороны группы документации](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): выясните, нужно ли внести какие-либо дополнительные изменения или обновления, чтобы принять PR. Если по вашему мнению PR готов к слияния, оставьте комментарий с текстом `/approve`. -- [Быстрые результаты](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): если маленький PR направлен в основную ветку и не имеет условий для объединения. (поменяйте "XS" в метке с размером при работе с другими пулреквестами [XS, S, M, L, XL, XXL]). +- [Требуется LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): если нужна проверка с технической точки зрения, попросите её провести одного из рецензентов, которого предложил бот. Если требуется просмотр пулреквеста со стороны группы документации или вычитка, то предложите изменения, либо сами измените PR, чтобы ускорить процесс принятия пулреквеста. +- [Имеет LGTM, нужно одобрение со стороны группы документации](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): выясните, нужно ли внести какие-либо дополнительные изменения или обновления, чтобы принять PR. Если по вашему мнению PR готов к слиянию, оставьте комментарий с текстом `/approve`. +- [Быстрые результаты](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): если маленький PR направлен в основную ветку и не имеет условий для объединения (поменяйте "XS" в метке с размером при работе с другими пулреквестами [XS, S, M, L, XL, XXL]). - [Вне основной ветки](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): если PR отправлен в ветку `dev-`, значит он предназначается для будущего выпуска. Убедитесь, что [release meister](https://github.com/kubernetes/sig-release/tree/master/release-team) знает об этом, добавив комментарий с `/assign @`. Если он направлен в старую ветку, помогите автору PR изменить на более подходящую ветку. ### Когда закрывать пулреквесты @@ -57,7 +57,7 @@ weight: 30 - Закройте любой PR, если автор не отреагировал на комментарии или проверки в течение 2 или более недель. -Не бойтесь закрывать пулреквесты. Участники с лёгкостью открыть и возобновить незаконченную работу. Зачастую уведомление о закрытии стимулировать автора возобновить и закончить свой вклад. +Не бойтесь закрывать пулреквесты. Участники с лёгкостью могут открыть и возобновить незаконченную работу. Зачастую уведомление о закрытии стимулирует автора возобновить и завершить свою работу до конца. Чтобы закрыть пулреквест, оставьте комментарий `/close` в PR. @@ -71,8 +71,8 @@ weight: 30 [Члены](/ru/docs/contribute/participating/#члены) SIG Docs могут предлагать улучшения. -После того, как вы давно начали работать над документацией Kubernetes, у наверняка появились какие-нибудь идеи по улучшению [руководства по оформлению](/docs/contribute/style/style-guide/), [руководства по оформлению](/docs/contribute/style/content-guide/), набору инструментов, который используется для создания документации, стилизации сайта, процессов проверки и объединения пулреквестов. Для максимальной открытости подобные типы предложений по улучшению должны обсуждаться на встречи SIG Docs или в [списке рассылки kubernetes-sig-docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). -Помимо этого, это поможет разъяснить, как всё устроено в данный момент, и объяснить, почему так было принято, прежде чем предлагать радикальные изменения. Самый быстрый способ узнать ответы на вопросы о том, как в настоящее время работает документация, это задать их на канале `#sig-docs` Slack на [kubernetes.slack.com](https://kubernetes.slack.com). +Если вы давно начали работать над документацией Kubernetes, у вас наверняка появились какие-нибудь идеи по улучшению [руководства по оформлению](/docs/contribute/style/style-guide/), [руководства по содержанию](/docs/contribute/style/content-guide/), набору инструментов, который используется для создания документации, стилизации сайта, процессов проверки и объединения пулреквестов. Для максимальной открытости подобные типы предложений по улучшению должны обсуждаться на встречи SIG Docs или в [списке рассылки kubernetes-sig-docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). +Помимо этого, это поможет разъяснить, как всё устроено в данный момент, и объяснить, почему так было принято, прежде чем предлагать радикальные изменения. Самый быстрый способ узнать ответы на вопросы о том, как в настоящее время работает документация, это задать их в канале `#sig-docs` в [официальном Slack](https://kubernetes.slack.com). Когда обсуждение состоялось, а SIG-группа согласилась с желаемым результатом, вы можете работать над предлагаемыми изменениями наиболее приемлемым способом. Например, обновление руководства по оформлению или функциональности сайта может включать открытие пулреквеста, а изменение, связанное с тестированием документации, может предполагать взаимодействие с sig-testing. @@ -84,11 +84,11 @@ weight: 30 Представитель SIG Docs для данного выпуска координирует следующие задачи: -- Мониторинг электронной таблицы с отслеживанием функциональности на наличие новых или измененных возможностей, затрагивают документацию. Если документация для определенной функциональности не будет готова к выпуску, возможно, она не попадет в выпуск. -- Регулярное посещение встречи sig-release и обновлять информацию о статусе документации в выпуске. +- Мониторинг электронной таблицы с отслеживанием функциональности на наличие новых или измененных возможностей, затрагивающих документацию. Если документация для определенной функциональности не будет готова к выпуску, возможно, она не попадет в выпуск. +- Регулярное посещение встречи sig-release и обновление информации о статусе документации к выпуску. - Проверка и вычитка документации по функциональности, подготовленной SIG-группой, ответственной за реализацию этой функциональности. - Объединение связанных с выпуском пулреквестов и поддержка Git-ветки выпуска. -- Консультируйте других участников SIG Docs, которые хотят научиться выполнять эту роль в будущем. Это называется сопровождение (shadowing). +- Консультирование других участников SIG Docs, которые хотят научиться выполнять эту роль в будущем. Это называется сопровождение (shadowing). - Публикация изменений в документации, связанные с выпуском при размещении артефактов. Координация выпуска обычно занимает 3-4 месяца, а обязанности распределяются между утверждающими SIG Docs. @@ -101,10 +101,10 @@ weight: 30 Обязанности амбассадоров новых участников включают в себя: -- Отвечать на вопросы новых участников на [Slack-канале Kubernetes #sig-docs](https://kubernetes.slack.com). +- Отвечать на вопросы новых участников в [Slack-канале Kubernetes #sig-docs](https://kubernetes.slack.com). - Совместно работать с дежурным по PR, чтобы определять заявки, которые подойдут для решения новыми участниками. - Консультировать новых участников в их PR. -- Помогать новых участникам в создании более сложных PR, чтобы они могли стать членами Kubernetes. +- Помогать новым участникам в создании более сложных PR, чтобы они могли стать членами Kubernetes. - [Оказывать содействие участникам](/ru/docs/contribute/advanced/#поддержка-нового-участника) на их пути становления членом в Kubernetes. Текущие амбассадоры новых участников объявляются на каждом собрании SIG Docs и на канале [#sig-docs в Kubernetes](https://kubernetes.slack.com). @@ -115,7 +115,7 @@ weight: 30 Если участник сделал 5 значительных пулреквестов в один или несколько репозиториев Kubernetes, он имеет право на [членство](/ru/docs/contribute/participating#члены) в организации Kubernetes. Членство участника должно быть поддержано двумя спонсорами, которые уже являются рецензентами. -Новые участники документации могут найти спонсоров в канале #sig-docs в [в Slack Kubernetes](https://kubernetes.slack.com) или в [списке рассылки SIG Docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). Если вы осознали полезность работы автора заявки на членство, вы добровольно можете поддержать (спонсировать) его. Когда они подадут заявку на членство, отреагируйте на заявку "+1" и напишите подробный комментарий о том, почему вы считаете, что кандидат отлично вписывается в члены организации Kubernetes. +Новые участники документации могут найти спонсоров в канале #sig-docs [в Slack Kubernetes](https://kubernetes.slack.com) или в [списке рассылки SIG Docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). Если вы осознали полезность работы автора заявки на членство, вы добровольно можете поддержать (спонсировать) его. Когда они подадут заявку на членство, отреагируйте на заявку "+1" и напишите подробный комментарий о том, почему вы считаете, что кандидат отлично вписывается в члены организации Kubernetes. ## Сопредседатель SIG @@ -125,9 +125,9 @@ weight: 30 Сопредседатели должны соответствовать следующим требованиям: -- Быть утверждающим SIG Docs не меньше 6 месяцев -- [Руководить выпуском документации Kubernetes](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) или сопровождать два выпуска -- Понимание рабочих процессов и инструментов SIG Docs: git, Hugo, локализация, блог +- Быть утверждающими SIG Docs не меньше 6 месяцев. +- [Руководить выпуском документации Kubernetes](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) или сопроводить два выпуска. +- Понимать рабочие процессы и инструменты SIG Docs: git, Hugo, локализация, блог. - Понимать, как другие SIG-группы и репозитории Kubernetes влияют на рабочий процесс SIG Docs, включая: [команды в k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [процессы в k/community](https://github.com/kubernetes/community/tree/master/sig-docs), плагины в [k/test-infra](https://github.com/kubernetes/test-infra/) и роль [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture). - Уделять не менее 5 часов в неделю (но зачастую больше) в течение как минимум 6 месяцев для выполнения обязанностей. @@ -137,13 +137,13 @@ weight: 30 Обязанности включают в себя: -- Сосредоточить группу SIG Docs на достижении максимального счастья для разработчиков через отличную документацию -- Быть примером соблюдения [норм поведения сообщества]https://github.com/cncf/foundation/blob/master/code-of-conduct.md) и контролировать их выполнение членами SIG -- Изучение и внедрение передовых практик для SIG-группы, обновляя рекомендации по участию -- Планирование и проведение встреч SIG: еженедельные обновления информации, ежеквартальные ретроспективные/плановые совещания и многое другое -- Планирование и проведение спринтов по документации на мероприятиях KubeCon и других конференциях +- Сосредоточить группу SIG Docs на достижении максимального счастья для разработчиков через отличную документацию. +- Быть примером соблюдения [норм поведения сообщества](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) и контролировать их выполнение членами SIG. +- Изучать и внедрять передовые практики для SIG-группы, обновляя рекомендации по участию. +- Планировать и проверять встречи SIG: еженедельные обновления информации, ежеквартальные ретроспективные/плановые совещания и многое другое. +- Планирование и проведение спринтов по документации на мероприятиях KubeCon и других конференциях. - Набирать персонал и выступать в поддержку {{< glossary_tooltip text="CNCF" term_id="cncf" >}} и его платиновых партнеров, включая Google, Oracle, Azure, IBM и Huawei. -- Поддерживать нормальную работу SIG +- Поддерживать нормальную работу SIG. ### Проведение продуктивных встреч @@ -155,33 +155,33 @@ weight: 30 **Сформулируйте четкую повестку дня**: -- Определите конкретную цель встречи -- Опубликуйте программу дня заранее +- Определите конкретную цель встречи. +- Опубликуйте программу дня заранее. Для еженедельных встреч скопируйте примечания из предыдущей недели в раздел "Past meetings". **Работайте вместе для создания точных примечания**: -- Запишите обсуждение встречи -- Подумайте над тем, чтобы делегировать роль стенографист кому-нибудь другому +- Запишите обсуждение встречи. +- Подумайте над тем, чтобы делегировать роль стенографиста кому-нибудь другому. **Определяйте решения по пунктам повестки четко и точно**: -- Записывайте решения по пунктам, кто будет ими заниматься и ожидаемую дату завершения +- Записывайте решения по пунктам, кто будет ими заниматься и ожидаемую дату завершения. **Руководите обсуждением, когда это необходимо**: -- Если обсуждение выходит за пределы повестки дня, снова обратите внимание участников на обсуждаемую тему -- Найдите место для различных стилей ведения обсуждения, не отвлекаясь от темы обсуждения и уважая время людей +- Если обсуждение выходит за пределы повестки дня, снова обратите внимание участников на обсуждаемую тему. +- Найдите место для различных стилей ведения обсуждения, не отвлекаясь от темы обсуждения и уважая время людей. **Уважайте время людей**: -- Начинайте и заканчивайте встречи своевременно +- Начинайте и заканчивайте встречи своевременно. **Используйте Zoom эффективно**: -- Ознакомьтесь с [рекомендациями Zoom для Kubernetes](https://github.com/kubernetes/community/blob/master/communication/zoom-guidelines.md) -- Попробуйте попроситься быть ведущим в самом начале встречи, введя ключ ведущего +- Ознакомьтесь с [рекомендациями Zoom для Kubernetes](https://github.com/kubernetes/community/blob/master/communication/zoom-guidelines.md). +- Попробуйте попроситься быть ведущим в самом начале встречи, введя ключ ведущего. Исполнение роли ведущего в Zoom @@ -192,5 +192,3 @@ weight: 30 Если нужно остановить запись, нажмите на кнопку Stop. Запись автоматически загрузится на YouTube. - - From 9a49299b4f15e54e0957c0681f86abd161a492de Mon Sep 17 00:00:00 2001 From: Ilya Z Date: Sun, 27 Mar 2022 12:20:37 +0400 Subject: [PATCH 13/32] cheatsheet_fixes --- content/ru/docs/reference/kubectl/cheatsheet.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/ru/docs/reference/kubectl/cheatsheet.md b/content/ru/docs/reference/kubectl/cheatsheet.md index 02a8a9bc4a..8c4721b4fc 100644 --- a/content/ru/docs/reference/kubectl/cheatsheet.md +++ b/content/ru/docs/reference/kubectl/cheatsheet.md @@ -235,7 +235,7 @@ kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl kubectl label pods my-pod new-label=awesome # Добавить метку kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # Добавить аннотацию -kubectl autoscale deployment foo --min=2 --max=10 # Автоматически промасштабировать развёртывание "foo" +kubectl autoscale deployment foo --min=2 --max=10 # Автоматически масштабировать развёртывание "foo" в диапазоне от 2 до 10 подов ``` ## Обновление ресурсов @@ -269,10 +269,10 @@ KUBE_EDITOR="nano" kubectl edit svc/docker-registry # Использовать ## Масштабирование ресурсов ```bash -kubectl scale --replicas=3 rs/foo # Промасштабировать набор реплик (replicaset) 'foo' до 3 -kubectl scale --replicas=3 -f foo.yaml # Промасштабировать ресурс в "foo.yaml" до 3 -kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # Если количество реплик в развёртывании mysql равен 2, промасштабировать его до 3 -kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Промасштабировать несколько контроллеров репликации +kubectl scale --replicas=3 rs/foo # Масштабирование набора реплик (replicaset) 'foo' до 3 +kubectl scale --replicas=3 -f foo.yaml # Масштабирование ресурса в "foo.yaml" до 3 +kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # Если количество реплик в развёртывании mysql равен 2, масштабировать его до 3 +kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Масштабирование нескольких контроллеров репликации до 5 ``` ## Удаление ресурсов @@ -362,7 +362,7 @@ kubectl api-resources --api-group=extensions # Все ресурсы в API-гр ### Уровни детальности вывода и отладки в Kubectl -Уровни детальности вывода Kubectl регулируются с помощью флагов `-v` или `--v`, за которыми следует целое число, представляющее уровни логирования. Общие соглашения по логированиия Kubernetes и связанные с ними уровни описаны [здесь](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md). +Уровни детальности вывода Kubectl регулируются с помощью флагов `-v` или `--v`, за которыми следует целое число, представляющее уровни логирования. Общие соглашения по логированию Kubernetes и связанные с ними уровни описаны [здесь](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md). Уровень детальности | Описание From 482bfee980bb62774cc778de184c47c6d42e657e Mon Sep 17 00:00:00 2001 From: Ilya Z Date: Sun, 27 Mar 2022 12:47:02 +0400 Subject: [PATCH 14/32] kubectl_docs_fixes --- .../kubectl/docker-cli-to-kubectl.md | 2 +- content/ru/docs/reference/kubectl/jsonpath.md | 2 +- content/ru/docs/reference/kubectl/kubectl.md | 94 +++++++++---------- 3 files changed, 49 insertions(+), 49 deletions(-) diff --git a/content/ru/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/ru/docs/reference/kubectl/docker-cli-to-kubectl.md index 4d834098c6..c742e1fba4 100644 --- a/content/ru/docs/reference/kubectl/docker-cli-to-kubectl.md +++ b/content/ru/docs/reference/kubectl/docker-cli-to-kubectl.md @@ -70,7 +70,7 @@ kubectl run [-i] [--tty] --attach --image= ``` В отличие от `docker run ...`, если вы укажете `--attach`, то присоедините `stdin`, `stdout` and `stderr`. Нельзя проконтролировать, какие потоки прикрепляются (`docker -a ...`). -Чтобы отсоединиться от контейнера воспользуетесь комбинацией клавиш Ctrl+P, а затем Ctrl+Q. +Чтобы отсоединиться от контейнера, воспользуетесь комбинацией клавиш Ctrl+P, а затем Ctrl+Q. Так как команда kubectl run запускает развёртывание для контейнера, то оно начнет перезапускаться, если завершить прикрепленный процесс по нажатию Ctrl+C, в отличие от команды `docker run -it`. Для удаления объекта Deployment вместе с подами, необходимо выполнить команду `kubectl delete deployment `. diff --git a/content/ru/docs/reference/kubectl/jsonpath.md b/content/ru/docs/reference/kubectl/jsonpath.md index d6bd9b5c48..231d3a0dc9 100644 --- a/content/ru/docs/reference/kubectl/jsonpath.md +++ b/content/ru/docs/reference/kubectl/jsonpath.md @@ -90,7 +90,7 @@ kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.st ``` {{< note >}} -В Windows нужно заключить в _двойные_ кавычки JSONPath-шаблон, который содержит пробелы (не в одинарные, как в примерах выше для bash). Таким образом, любые литералы в таких шаблонов нужно оборачивать в одинарные кавычки или экранированные двойные кавычки. Например: +В Windows нужно заключить в _двойные_ кавычки JSONPath-шаблон, который содержит пробелы (не в одинарные, как в примерах выше для bash). Таким образом, любые литералы в таких шаблонах нужно оборачивать в одинарные кавычки или экранированные двойные кавычки. Например: ```cmd kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}" diff --git a/content/ru/docs/reference/kubectl/kubectl.md b/content/ru/docs/reference/kubectl/kubectl.md index ce01d0b8ab..405522525d 100644 --- a/content/ru/docs/reference/kubectl/kubectl.md +++ b/content/ru/docs/reference/kubectl/kubectl.md @@ -158,14 +158,14 @@ kubectl [flags] --default-not-ready-toleration-seconds int     По умолчанию: 300 -Указывает tolerationSeconds для допущения notReady:NoExecute, которое по умолчанию добавляется к каждому поду, у которого нет установлено такое допущение. +Указывает tolerationSeconds для допущения notReady:NoExecute, которое по умолчанию добавляется к каждому поду, у которого не установлено такое допущение. --default-unreachable-toleration-seconds int     По умолчанию: 300 -Указывает tolerationSeconds для допущения unreachable:NoExecute, которое по умолчанию добавляется к каждому поду, у которого нет установлено такое допущение. +Указывает tolerationSeconds для допущения unreachable:NoExecute, которое по умолчанию добавляется к каждому поду, у которого не установлено такое допущение. @@ -221,7 +221,7 @@ kubectl [flags] --docker-tls-cert string     По умолчанию: "cert.pem" -путь к клиентскому сертификату +Путь к клиентскому сертификату @@ -277,7 +277,7 @@ kubectl [flags] --insecure-skip-tls-verify -Если true, значит сертификат сервера не будет проверятся на достоверность. Это сделает подключения через HTTPS небезопасными. +Если true, значит сертификат сервера не будет проверяться на достоверность. Это сделает подключения через HTTPS небезопасными. @@ -333,7 +333,7 @@ kubectl [flags] --logtostderr     По умолчанию: true -Логировать в стандартный поток ошибок вместо сохранения логов в файлы +Вывод логов в стандартный поток ошибок вместо сохранения их в файлы @@ -521,48 +521,48 @@ kubectl [flags] ## {{% heading "seealso" %}} -* [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands#annotate) - Обновить аннотации ресурса -* [kubectl api-resources](/docs/reference/generated/kubectl/kubectl-commands#api-resources) - Вывести доступные API-ресурсы на сервере -* [kubectl api-versions](/docs/reference/generated/kubectl/kubectl-commands#api-versions) - Вывести доступные API-версии на сервере в виде "group/version". -* [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) - Внести изменения в конфигурацию ресурса из файла или потока stdin. -* [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands#attach) - Присоединиться к запущенному контейнеру -* [kubectl auth](/docs/reference/generated/kubectl/kubectl-commands#auth) - Проверить разрешение на выполнение определённых действий -* [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale) - Автоматически промасштабировать Deployment, ReplicaSet или ReplicationController -* [kubectl certificate](/docs/reference/generated/kubectl/kubectl-commands#certificate) - Изменить сертификаты ресурсов. -* [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands#cluster-info) - Показать информацию по кластеру -* [kubectl completion](/docs/reference/generated/kubectl/kubectl-commands#completion) - Вывод кода автодополнения указанной командной оболочки (bash или zsh) -* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) - Изменить файлы kubeconfig -* [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) - Конвертировать конфигурационные файлы в различные API-версии -* [kubectl cordon](/docs/reference/generated/kubectl/kubectl-commands#cordon) - Отметить узел как неназначаемый -* [kubectl cp](/docs/reference/generated/kubectl/kubectl-commands#cp) - Копировать файлы и директории в/из контейнеров. -* [kubectl create](/docs/reference/generated/kubectl/kubectl-commands#create) - Создать ресурс из файла или потока stdin. -* [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands#delete) - Удалить ресурсы из файла, потока stdin, либо с помощью селекторов меток, имен, селекторов ресурсов или ресурсов -* [kubectl describe](/docs/reference/generated/kubectl/kubectl-commands#describe) - Показать подробную информацию о конкретном ресурсе или группе ресурсов -* [kubectl diff](/docs/reference/generated/kubectl/kubectl-commands#diff) - Сравнить действующую версию с новой (применяемой) -* [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands#drain) - Вытеснить узел для подготовки к эксплуатации -* [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands#edit) - Отредактировать ресурс на сервере -* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands#exec) - Выполнить команду в контейнере -* [kubectl explain](/docs/reference/generated/kubectl/kubectl-commands#explain) - Получить документацию ресурсов -* [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands#expose) - Создать новый сервис Kubernetes из контроллера репликации, сервиса, развёртывания или пода -* [kubectl get](/docs/reference/generated/kubectl/kubectl-commands#get) - Вывести один или несколько ресурсов -* [kubectl kustomize](/docs/reference/generated/kubectl/kubectl-commands#kustomize) - Собрать ресурсы kustomization из директории или URL-адреса. -* [kubectl label](/docs/reference/generated/kubectl/kubectl-commands#label) - Обновить метки ресурса -* [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands#logs) - Вывести логи контейнера в поде -* [kubectl options](/docs/reference/generated/kubectl/kubectl-commands#options) - Вывести список флагов, применяемых ко всем командам -* [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands#patch) - Обновить один или несколько полей ресурса, используя стратегию слияния патча -* [kubectl plugin](/docs/reference/generated/kubectl/kubectl-commands#plugin) - Команда для работы с плагинами. -* [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands#port-forward) - Переадресовать один или несколько локальных портов в под -* [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands#proxy) - Запустить прокси на API-сервер Kubernetes -* [kubectl replace](/docs/reference/generated/kubectl/kubectl-commands#replace) - Заменить ресурс из определения в файле или потоке stdin. -* [kubectl rollout](/docs/reference/generated/kubectl/kubectl-commands#rollout) - Управление плавающим обновлением ресурса -* [kubectl run](/docs/reference/generated/kubectl/kubectl-commands#run) - Запустить указанный образ в кластере -* [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands#scale) - Задать новый размер для Deployment, ReplicaSet или Replication Controller. -* [kubectl set](/docs/reference/generated/kubectl/kubectl-commands#set) - Конфигурировать ресурсы в объектах -* [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint) - Обновить ограничения для одного или нескольких узлов -* [kubectl top](/docs/reference/generated/kubectl/kubectl-commands#top) - Показать информацию по использованию системных ресурсов (процессор, память, диск) -* [kubectl uncordon](/docs/reference/generated/kubectl/kubectl-commands#uncordon) - Отметить узел как назначаемый -* [kubectl version](/docs/reference/generated/kubectl/kubectl-commands#version) - Вывести информацию о версии клиента и сервера -* [kubectl wait](/docs/reference/generated/kubectl/kubectl-commands#wait) - Экспериментально: ожидать выполнения определенного условия в одном или нескольких ресурсах. +* [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands#annotate) - Обновить аннотации ресурса. +* [kubectl api-resources](/docs/reference/generated/kubectl/kubectl-commands#api-resources) - Вывести доступные API-ресурсы на сервере. +* [kubectl api-versions](/docs/reference/generated/kubectl/kubectl-commands#api-versions) - Вывести доступные API-версии на сервере в виде "group/version". +* [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) - Внести изменения в конфигурацию ресурса из файла или потока stdin. +* [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands#attach) - Присоединиться к запущенному контейнеру. +* [kubectl auth](/docs/reference/generated/kubectl/kubectl-commands#auth) - Проверить разрешение на выполнение определённых действий. +* [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale) - Автоматически масштабировать Deployment, ReplicaSet или ReplicationController. +* [kubectl certificate](/docs/reference/generated/kubectl/kubectl-commands#certificate) - Изменить сертификаты ресурсов. +* [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands#cluster-info) - Показать информацию по кластеру. +* [kubectl completion](/docs/reference/generated/kubectl/kubectl-commands#completion) - Вывод кода автодополнения указанной командной оболочки (bash или zsh). +* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) - Изменить файлы kubeconfig. +* [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) - Конвертировать конфигурационные файлы в различные API-версии. +* [kubectl cordon](/docs/reference/generated/kubectl/kubectl-commands#cordon) - Отметить узел как неназначаемый. +* [kubectl cp](/docs/reference/generated/kubectl/kubectl-commands#cp) - Копировать файлы и директории в/из контейнеров. +* [kubectl create](/docs/reference/generated/kubectl/kubectl-commands#create) - Создать ресурс из файла или потока stdin. +* [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands#delete) - Удалить ресурсы из файла, потока stdin, либо с помощью селекторов меток, имен, селекторов ресурсов или ресурсов. +* [kubectl describe](/docs/reference/generated/kubectl/kubectl-commands#describe) - Показать подробную информацию о конкретном ресурсе или группе ресурсов. +* [kubectl diff](/docs/reference/generated/kubectl/kubectl-commands#diff) - Сравнить действующую версию с новой (применяемой). +* [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands#drain) - Вытеснить узел для подготовки к эксплуатации. +* [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands#edit) - Отредактировать ресурс на сервере. +* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands#exec) - Выполнить команду в контейнере. +* [kubectl explain](/docs/reference/generated/kubectl/kubectl-commands#explain) - Получить документацию ресурсов. +* [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands#expose) - Создать новый сервис Kubernetes из контроллера репликации, сервиса, развёртывания или пода. +* [kubectl get](/docs/reference/generated/kubectl/kubectl-commands#get) - Вывести один или несколько ресурсов. +* [kubectl kustomize](/docs/reference/generated/kubectl/kubectl-commands#kustomize) - Собрать ресурсы kustomization из директории или URL-адреса. +* [kubectl label](/docs/reference/generated/kubectl/kubectl-commands#label) - Обновить метки ресурса. +* [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands#logs) - Вывести логи контейнера в поде. +* [kubectl options](/docs/reference/generated/kubectl/kubectl-commands#options) - Вывести список флагов, применяемых ко всем командам. +* [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands#patch) - Обновить один или несколько полей ресурса, используя стратегию слияния патча. +* [kubectl plugin](/docs/reference/generated/kubectl/kubectl-commands#plugin) - Команда для работы с плагинами. +* [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands#port-forward) - Переадресовать один или несколько локальных портов в под. +* [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands#proxy) - Запустить прокси на API-сервер Kubernetes. +* [kubectl replace](/docs/reference/generated/kubectl/kubectl-commands#replace) - Заменить ресурс из определения в файле или потоке stdin. +* [kubectl rollout](/docs/reference/generated/kubectl/kubectl-commands#rollout) - Управление плавающим обновлением ресурса. +* [kubectl run](/docs/reference/generated/kubectl/kubectl-commands#run) - Запустить указанный образ в кластере. +* [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands#scale) - Задать новый размер для Deployment, ReplicaSet или Replication Controller. +* [kubectl set](/docs/reference/generated/kubectl/kubectl-commands#set) - Конфигурировать ресурсы в объектах. +* [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint) - Обновить ограничения для одного или нескольких узлов. +* [kubectl top](/docs/reference/generated/kubectl/kubectl-commands#top) - Показать информацию по использованию системных ресурсов (процессор, память, диск). +* [kubectl uncordon](/docs/reference/generated/kubectl/kubectl-commands#uncordon) - Отметить узел как назначаемый. +* [kubectl version](/docs/reference/generated/kubectl/kubectl-commands#version) - Вывести информацию о версии клиента и сервера. +* [kubectl wait](/docs/reference/generated/kubectl/kubectl-commands#wait) - Экспериментально: ожидать выполнения определенного условия в одном или нескольких ресурсах. From 81881f8d8452ac2ab30f3f708e6149c1fc8630e7 Mon Sep 17 00:00:00 2001 From: Sudheer Satyanarayana Date: Sun, 27 Mar 2022 16:01:25 +0530 Subject: [PATCH 15/32] minor text edit `Pay attention to the case of suffixes` seems better than `Take care about case for suffixes` --- .../docs/concepts/configuration/manage-resources-containers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md index 18f2fc5cb5..575f96f04d 100644 --- a/content/en/docs/concepts/configuration/manage-resources-containers.md +++ b/content/en/docs/concepts/configuration/manage-resources-containers.md @@ -134,7 +134,7 @@ Mi, Ki. For example, the following represent roughly the same value: 128974848, 129e6, 129M, 128974848000m, 123Mi ``` -Take care about case for suffixes. If you request `400m` of memory, this is a request +Pay attention to the case of the suffixes. If you request `400m` of memory, this is a request for 0.4 bytes. Someone who types that probably meant to ask for 400 mebibytes (`400Mi`) or 400 megabytes (`400M`). From f01be79f66100ad40eca6490b3f7a90ba78570f6 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sun, 27 Mar 2022 19:43:59 +0800 Subject: [PATCH 16/32] [zh] Resync pod topology spread constraints page --- .../pods/pod-topology-spread-constraints.md | 140 ++++++++++-------- 1 file changed, 76 insertions(+), 64 deletions(-) diff --git a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 5ac4fed192..77e2127443 100644 --- a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -75,7 +75,7 @@ node4 Ready 2m43s v1.16.0 node=node4,zone=zoneB -然后从逻辑上看集群如下： +那么，从逻辑上看集群如下： {{}} graph TB @@ -96,11 +96,9 @@ graph TB {{< /mermaid >}} -你可以复用在大多数集群上自动创建和填充的 -[常用标签](/zh/docs/reference/labels-annotations-taints/)， +你可以复用在大多数集群上自动创建和填充的[常用标签](/zh/docs/reference/labels-annotations-taints/)， 而不是手动添加标签。 +当 Pod 定义了不止一个 `topologySpreadConstraint`，这些约束之间是逻辑与的关系。 +kube-scheduler 会为新的 Pod 寻找一个能够满足所有约束的节点。 + @@ -353,7 +357,6 @@ graph BT class zoneA,zoneB cluster; {{< /mermaid >}} - @@ -374,54 +377,59 @@ The scheduler will skip the non-matching nodes from the skew calculations if the --> ### 节点亲和性与节点选择器的相互作用 {#interaction-with-node-affinity-and-node-selectors} -如果 Pod 定义了 `spec.nodeSelector` 或 `spec.affinity.nodeAffinity`，调度器将从倾斜计算中跳过不匹配的节点。 +如果 Pod 定义了 `spec.nodeSelector` 或 `spec.affinity.nodeAffinity`， +调度器将在偏差计算中跳过不匹配的节点。 - 假设你有一个跨越 zoneA 到 zoneC 的 5 节点集群： +### 示例：TopologySpreadConstraints 与 NodeAffinity - {{}} - graph BT - subgraph "zoneB" - p3(Pod) --> n3(Node3) - n4(Node4) - end - subgraph "zoneA" - p1(Pod) --> n1(Node1) - p2(Pod) --> n2(Node2) - end +假设你有一个跨越 zoneA 到 zoneC 的 5 节点集群： - classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; - classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; - classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; - class n1,n2,n3,n4,p1,p2,p3 k8s; - class p4 plain; - class zoneA,zoneB cluster; - {{< /mermaid >}} +{{}} +graph BT + subgraph "zoneB" + p3(Pod) --> n3(Node3) + n4(Node4) + end + subgraph "zoneA" + p1(Pod) --> n1(Node1) + p2(Pod) --> n2(Node2) + end - {{}} - graph BT - subgraph "zoneC" - n5(Node5) - end +classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; +classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; +classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; +class n1,n2,n3,n4,p1,p2,p3 k8s; +class p4 plain; +class zoneA,zoneB cluster; +{{< /mermaid >}} - classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; - classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; - classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; - class n5 k8s; - class zoneC cluster; - {{< /mermaid >}} +{{}} +graph BT + subgraph "zoneC" + n5(Node5) + end - 而且你知道 "zoneC" 必须被排除在外。在这种情况下，可以按如下方式编写 yaml， - 以便将 "mypod" 放置在 "zoneB" 上，而不是 "zoneC" 上。同样，`spec.nodeSelector` - 也要一样处理。 +classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; +classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; +classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; +class n5 k8s; +class zoneC cluster; +{{< /mermaid >}} - {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}} + + +而且你知道 "zoneC" 必须被排除在外。在这种情况下，可以按如下方式编写 YAML， +以便将 "mypod" 放置在 "zoneB" 上，而不是 "zoneC" 上。同样，`spec.nodeSelector` +也要一样处理。 + +{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}} 此外，原来用于提供等同行为的 `SelectorSpread` 插件也会被禁用。 +{{< note >}} + +对于分布约束中所指定的拓扑键而言，`PodTopologySpread` 插件不会为不包含这些主键的节点评分。 +这可能导致在使用默认拓扑约束时，其行为与原来的 `SelectorSpread` 插件的默认行为不同， + -{{< note >}} 如果你的节点不会 **同时** 设置 `kubernetes.io/hostname` 和 `topology.kubernetes.io/zone` 标签，你应该定义自己的约束而不是使用 Kubernetes 的默认约束。 - -插件 `PodTopologySpread` 不会为未设置分布约束中所给拓扑键的节点评分。 {{< /note >}} -如果你不想为集群使用默认的 Pod 分布约束，你可以通过设置 `defaultingType` 参数为 `List` 和 -将 `PodTopologySpread` 插件配置中的 `defaultConstraints` 参数置空来禁用默认 Pod 分布约束。 +如果你不想为集群使用默认的 Pod 分布约束，你可以通过设置 `defaultingType` 参数为 `List` +并将 `PodTopologySpread` 插件配置中的 `defaultConstraints` 参数置空来禁用默认 Pod 分布约束。 ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta1 +apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: @@ -613,9 +625,9 @@ scheduled - more packed or more scattered. - 对于 `PodAffinity`，你可以尝试将任意数量的 Pod 集中到符合条件的拓扑域中。 - 对于 `PodAntiAffinity`，只能将一个 Pod 调度到某个拓扑域中。 @@ -627,12 +639,6 @@ cost-saving. This can also help on rolling update workloads and scaling out replicas smoothly. See [Motivation](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation) for more details. - - -The "EvenPodsSpread" feature provides flexible options to distribute Pods evenly across different -topology domains - to achieve high availability or cost-saving. This can also help on rolling update -workloads and scaling out replicas smoothly. -See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation) for more details. --> 要实现更细粒度的控制，你可以设置拓扑分布约束来将 Pod 分布到不同的拓扑域下， 从而实现高可用性或节省成本。这也有助于工作负载的滚动更新和平稳地扩展副本规模。 @@ -642,13 +648,19 @@ See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig ## 已知局限性 -- Deployment 缩容操作可能导致 Pod 分布不平衡。 -- 具有污点的节点上的 Pods 也会被统计。 +- 当 Pod 被移除时，无法保证约束仍被满足。例如，缩减某 Deployment 的规模时， + Pod 的分布可能不再均衡。 + 你可以使用 [Descheduler](https://github.com/kubernetes-sigs/descheduler) + 来重新实现 Pod 分布的均衡。 + +- 具有污点的节点上匹配的 Pods 也会被统计。 参考 [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)。 ## {{% heading "whatsnext" %}} From 8260ee0f423f08546f2888eebc3d20d9baecd6e1 Mon Sep 17 00:00:00 2001 From: zhangxiaoyang Date: Sat, 26 Mar 2022 18:01:43 +0800 Subject: [PATCH 17/32] [zh]Add 2022-03-15-meet-our-contributors-APAC-AU-NZ-region-01.md --- ...t-our-contributors-APAC-AU-NZ-region-01.md | 180 ++++++++++++++++++ 1 file changed, 180 insertions(+) create mode 100644 content/zh/blog/_posts/2022-03-15-meet-our-contributors-APAC-AU-NZ-region-01.md diff --git a/content/zh/blog/_posts/2022-03-15-meet-our-contributors-APAC-AU-NZ-region-01.md b/content/zh/blog/_posts/2022-03-15-meet-our-contributors-APAC-AU-NZ-region-01.md new file mode 100644 index 0000000000..1b658bc9cf --- /dev/null +++ b/content/zh/blog/_posts/2022-03-15-meet-our-contributors-APAC-AU-NZ-region-01.md @@ -0,0 +1,180 @@ +--- +layout: blog +title: "认识我们的贡献者 - 亚太地区（澳大利亚-新西兰地区）" +date: 2022-03-16T12:00:00+0000 +slug: meet-our-contributors-au-nz-ep-02 +canonicalUrl: https://www.kubernetes.dev/blog/2022/03/14/meet-our-contributors-au-nz-ep-02/ +--- + + + +**作者和采访者：** +[Anubhav Vardhan](https://github.com/anubha-v-ardhan), +[Atharva Shinde](https://github.com/Atharva-Shinde), +[Avinesh Tripathi](https://github.com/AvineshTripathi), +[Brad McCoy](https://github.com/bradmccoydev), +[Debabrata Panigrahi](https://github.com/Debanitrkl), +[Jayesh Srivastava](https://github.com/jayesh-srivastava), +[Kunal Verma](https://github.com/verma-kunal), +[Pranshu Srivastava](https://github.com/PranshuSrivastava), +[Priyanka Saggu](github.com/Priyankasaggu11929/), +[Purneswar Prasad](https://github.com/PurneswarPrasad), +[Vedant Kakde](https://github.com/vedant-kakde) + +--- + + +大家好👋 + + +欢迎来到亚太地区的”认识我们的贡献者”博文系列第二期。 + + +这篇文章将介绍来自澳大利亚和新西兰地区的四位杰出贡献者， +他们在上游 Kubernetes 项目中承担着不同子项目的领导者和社区贡献者的角色。 + + +闲话少说，让我们直接进入主题。 + +## [Caleb Woodbine](https://github.com/BobyMCbobs) + + +Caleb Woodbine 目前是 ii.nz 组织的成员。 + + +他于 2018 年作为 Kubernetes Conformance 工作组的成员开始为 Kubernetes 项目做贡献。 +他积极向上，他从一位来自新西兰的贡献者 [Hippie Hacker](https://github.com/hh) 的早期指导中受益匪浅。 + + +他在 `SIG k8s-infra` 和 `k8s-conformance` 工作组为 Kubernetes 项目做出了重大贡献。 + + +Caleb 也是 [CloudNative NZ](https://www.meetup.com/cloudnative-nz/) +社区活动的联合组织者，该活动旨在扩大 Kubernetes 项目在整个新西兰的影响力，以鼓励科技教育和改善就业机会。 + + +> _亚太地区需要更多的外联活动，教育工作者和大学必须学习 Kubernetes，因为他们非常缓慢， +而且已经落后了8年多。新西兰倾向于在海外付费，而不是教育当地人最新的云技术。_ + +## [Dylan Graham](https://github.com/DylanGraham) + + +Dylan Graham 是来自澳大利亚 Adeliade 的云计算工程师。自 2018 年以来，他一直在为上游 Kubernetes 项目做出贡献。 + + +他表示，成为如此大项目的一份子，最初压力是比较大的，但社区的友好和开放帮助他度过了难关。 + + +开始在项目文档方面做贡献，现在主要致力于为亚太地区提供社区支持。 + + +他相信，持续参加社区/项目会议，承担项目任务，并在需要时寻求社区指导，可以帮助有抱负的新开发人员成为有效的贡献者。 + + +> _成为大社区的一份子感觉真的很特别。我遇到了一些了不起的人，甚至是在现实生活中疫情发生之前。_ + +## [Hippie Hacker](https://github.com/hh) + + +Hippie 来自新西兰，曾在 CNCF.io 作为战略计划承包商工作 5 年多。他是 k8s-infra、 +API 一致性测试、云提供商一致性提交以及上游 Kubernetes 和 CNCF 项目 apisnoop.cncf.io 域的积极贡献者。 + + +他讲述了他们早期参与 Kubernetes 项目的情况，该项目始于大约 5 年前，当时他们的公司 ii.nz +演示了[使用 PXE 从 Raspberry Pi 启动网络，并在集群中运行Gitlab，以便在服务器上安装 Kubernetes ](https://ii.nz/post/bringing-the-cloud-to-your-community/) + + +他描述了自己的贡献经历：一开始，他试图独自完成所有艰巨的任务，但最终看到了团队协作贡献的好处， +分工合作减少了过度疲劳，这让人们能够凭借自己的动力继续前进。 + + +他建议新的贡献者结对编程。 + + +> _针对一个项目，多人关注和交叉交流往往比单独的评审、批准 PR 能产生更大的效果。_ + +## [Nick Young](https://github.com/youngnick) + + +Nick Young 在 VMware 工作，是 CNCF 入口控制器 Contour 的技术负责人。 +他从一开始就积极参与上游 Kubernetes 项目，最终成为 LTS 工作组的主席， +他提倡关注用户。他目前是 SIG Network Gateway API 子项目的维护者。 + + +他的贡献之路是引人注目的，因为他很早就在 Kubernetes 项目的主要领域工作，这改变了他的轨迹。 + + +他断言，一个新贡献者能做的最好的事情就是“开始贡献”。当然，如果与他的工作息息相关，那好极了; +然而，把非工作时间投入到贡献中去，从长远来看可以在工作上获得回报。 +他认为，应该鼓励新的贡献者，特别是那些目前是 Kubernetes 用户的人，参与到更高层次的项目讨论中来。 + + +> _只要积极主动，做出贡献，你就可以走很远。一旦你活跃了一段时间，你会发现你能够解答别人的问题， +这意味着会有人请教你或和你讨论，在你意识到这一点之前，你就已经是专家了。_ + +--- + + +如果你对我们接下来应该采访的人有任何意见/建议，请在 #sig-contribex 中告知我们。 +非常感谢你的建议。我们很高兴有更多的人帮助我们接触到社区中更优秀的人。 + + +我们下期再见。祝你有个愉快的贡献之旅!👋 From 99b0fce444787ee8d7acc3615a266e9657ea8028 Mon Sep 17 00:00:00 2001 From: zhangxiaoyang Date: Sat, 26 Mar 2022 15:29:21 +0800 Subject: [PATCH 18/32] [zh]Add 2021-12-08-dual-stack-networking-ga.md --- .../2021-12-08-dual-stack-networking-ga.md | 154 ++++++++++++++++++ 1 file changed, 154 insertions(+) create mode 100644 content/zh/blog/_posts/2021-12-08-dual-stack-networking-ga.md diff --git a/content/zh/blog/_posts/2021-12-08-dual-stack-networking-ga.md b/content/zh/blog/_posts/2021-12-08-dual-stack-networking-ga.md new file mode 100644 index 0000000000..fa8cd74cc0 --- /dev/null +++ b/content/zh/blog/_posts/2021-12-08-dual-stack-networking-ga.md @@ -0,0 +1,154 @@ +--- +layout: blog +title: 'Kubernetes 1.23：IPv4/IPv6 双协议栈网络达到 GA' +date: 2021-12-08 +slug: dual-stack-networking-ga +--- + + + +**作者:** Bridget Kromhout (微软) + + +“Kubernetes 何时支持 IPv6？” 自从 k8s v1.9 版本中首次添加对 IPv6 的 alpha 支持以来，这个问题的讨论越来越频繁。 +虽然 Kubernetes 从 v1.18 版本开始就支持纯 IPv6 集群，但当时还无法支持 IPv4 迁移到 IPv6。 +[IPv4/IPv6 双协议栈网络](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/563-dual-stack/) +在 Kubernetes v1.23 版本中进入正式发布（GA）阶段。 + +让我们来看看双协议栈网络对你来说意味着什么？ + + +## 更新 Service API + + +[Services](/zh/docs/concepts/services-networking/service/) 在 1.20 版本之前是单协议栈的， +因此，使用两个 IP 协议族意味着需为每个 IP 协议族创建一个 Service。在 1.20 版本中对用户体验进行简化， +重新实现了 Service 以支持两个 IP 协议族，这意味着一个 Service 就可以处理 IPv4 和 IPv6 协议。 +对于 Service 而言，任意的 IPv4 和 IPv6 协议组合都可以实现负载均衡。 + + +Service API 现在有了支持双协议栈的新字段，取代了单一的 ipFamily 字段。 +* 你可以通过将 `ipFamilyPolicy` 字段设置为 `SingleStack`、`PreferDualStack` 或 +`RequireDualStack` 来设置 IP 协议族。Service 可以在单协议栈和双协议栈之间进行转换(在某些限制内)。 +* 设置 `ipFamilies` 为指定的协议族列表，可用来设置使用协议族的顺序。 +* 'clusterIPs' 的能力在涵盖了之前的 'clusterIP'的情况下，还允许设置多个 IP 地址。 +所以不再需要运行重复的 Service，在两个 IP 协议族中各运行一个。你可以在两个 IP 协议族中分配集群 IP 地址。 + + +请注意，Pods 也是双协议栈的。对于一个给定的 Pod，不可能在同一协议族中设置多个 IP 地址。 + + +## 默认行为仍然是单协议栈 + + +从 1.20 版本开始，重新实现的双协议栈服务处于 Alpha 阶段，无论集群是否配置了启用双协议栈的特性标志， +Kubernetes 的底层网络都已经包括了双协议栈。 + + +Kubernetes 1.23 删除了这个特性标志，说明该特性已经稳定。 +如果你想要配置双协议栈网络，这一能力总是存在的。 +你可以将集群网络设置为 IPv4 单协议栈 、IPv6 单协议栈或 IPV4/IPV6 双协议栈 。 + + +虽然 Service 是根据你的配置设置的，但 Pod 默认是由 CNI 插件设置的。 +如果你的 CNI 插件分配单协议栈 IP，那么就是单协议栈，除非 `ipFamilyPolicy` 设置为 `PreferDualStack` 或 `RequireDualStack`。 +如果你的 CNI 插件分配双协议栈 IP，则 `pod.status.PodIPs` 默认为双协议栈。 + + +尽管双协议栈是可用的，但并不强制你使用它。 +在[双协议栈服务配置](/zh/docs/concepts/services-networking/dual-stack/#dual-stack-service-configuration-scenarios) +文档中的示例列出了可能出现的各种场景. + + +## 现在尝试双协议栈 + + +虽然现在上游 Kubernetes 支持[双协议栈网络](/zh/docs/concepts/services-networking/dual-stack/) +作为 GA 或稳定特性，但每个提供商对双协议栈 Kubernetes 的支持可能会有所不同。节点需要提供可路由的 IPv4/IPv6 网络接口。 +Pod 需要是双协议栈的。[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +是用来为 Pod 分配 IP 地址的，所以集群需要支持双协议栈的网络插件。一些容器网络接口（CNI）插件支持双协议栈，例如 kubenet。 + + +支持双协议栈的生态系统在不断壮大；你可以使用 +[kubeadm 创建双协议栈集群](/zh/docs/setup/production-environment/tools/kubeadm/dual-stack-support/), +在本地尝试用 [KIND 创建双协议栈集群](https://kind.sigs.k8s.io/docs/user/configuration/#ip-family)， +还可以将双协议栈集群部署到云上（在查阅 CNI 或 kubenet 可用性的文档之后） + + +## 加入 Network SIG + + +SIG-Network 希望从双协议栈网络的社区体验中学习，以了解更多不断变化的需求和你的用例信息。 +[SIG-network 更新了来自 KubeCon 2021 北美大会的视频](https://www.youtube.com/watch?v=uZ0WLxpmBbY&list=PLj6h78yzYM2Nd1U4RMhv7v88fdiFqeYAP&index=4) +总结了 SIG 最近的更新，包括双协议栈将在 1.23 版本中稳定。 + + +当前 SIG-Network 在 GitHub 上的 [KEPs](https://github.com/orgs/kubernetes/projects/10) 和 +[issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Fnetwork) +说明了该 SIG 的重点领域。[双协议栈 API 服务器](https://github.com/kubernetes/enhancements/issues/2438) +是一个考虑贡献的方向。 + + +[SIG-Network 会议](https://github.com/kubernetes/community/tree/master/sig-network#meetings) +是一个友好、热情的场所，你可以与社区联系并分享你的想法。期待你的加入！ + + +## 致谢 + + +许多 Kubernetes 贡献者为双协议栈网络做出了贡献。感谢所有贡献了代码、经验报告、文档、代码审查以及其他工作的人。 +Bridget Kromhout 在 [Kubernetes的双协议栈网络](https://containerjournal.com/features/dual-stack-networking-in-kubernetes/) +中详细介绍了这项社区工作。Tim Hockin 和 Khaled (Kal) Henidak 在 2019 年的 KubeCon 大会演讲 +（[Kubernetes 通往 IPv4/IPv6 双协议栈的漫漫长路](https://www.youtube.com/watch?v=o-oMegdZcg4)） +和 Lachlan Evenson 在 2021 年演讲（[我们来啦，Kubernetes 双协议栈网络](https://www.youtube.com/watch?v=o-oMegdZcg4)） +中讨论了双协议栈的发展旅程，耗时 5 年和海量代码。 From 03926364b56bbe971490cbe0927b10753f491377 Mon Sep 17 00:00:00 2001 From: "xin.li" Date: Mon, 28 Mar 2022 13:16:53 +0800 Subject: [PATCH 19/32] [zh] Update install-kubectl-windows.md Signed-off-by: xin.li --- .../tasks/tools/install-kubectl-windows.md | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/content/zh/docs/tasks/tools/install-kubectl-windows.md b/content/zh/docs/tasks/tools/install-kubectl-windows.md index 617ca3f3ce..921a8e13a9 100644 --- a/content/zh/docs/tasks/tools/install-kubectl-windows.md +++ b/content/zh/docs/tasks/tools/install-kubectl-windows.md @@ -71,20 +71,20 @@ The following methods exist for installing kubectl on Windows: 1. 验证该可执行文件（可选步骤） - 下载 kubectl 校验和文件： + 下载 `kubectl` 校验和文件： ```powershell curl -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256" ``` - 基于校验和文件，验证 kubectl 的可执行文件： + 基于校验和文件，验证 `kubectl` 的可执行文件： -1. 将 kubectl 二进制文件夹附加或添加到你的 `PATH` 环境变量中。 +1. 将 `kubectl` 二进制文件夹追加或插入到你的 `PATH` 环境变量中。 1. 测试一下，确保此 `kubectl` 的版本和期望版本一致： @@ -261,22 +261,22 @@ kubectl 为 Bash、Zsh、Fish 和 PowerShell 提供自动补全功能，可以 1. 验证该可执行文件（可选步骤） - 下载 kubectl-convert 校验和文件： + 下载 `kubectl-convert` 校验和文件： ```powershell curl -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe.sha256" ``` - 基于校验和，验证 kubectl-convert 的可执行文件： + 基于校验和，验证 `kubectl-convert` 的可执行文件： - 用提示的命令对 `CertUtil` 的输出和下载的校验和文件进行手动比较。 @@ -295,11 +295,11 @@ kubectl 为 Bash、Zsh、Fish 和 PowerShell 提供自动补全功能，可以 ``` -1. 将 kubectl 二进制文件夹附加或添加到你的 `PATH` 环境变量中。 +1. 将 `kubectl-convert` 二进制文件夹附加或添加到你的 `PATH` 环境变量中。 1. 验证插件是否安装成功 From b765f0fee6f2f8eeb0d8d7e9c41ac7f3bbc3938f Mon Sep 17 00:00:00 2001 From: howieyuen Date: Sat, 26 Mar 2022 14:56:22 +0800 Subject: [PATCH 20/32] [zh]translate content/docs/reference/kubernetes-api/common-definitions/quantity.md into Chinese --- .../common-definitions/quantity.md | 135 ++++++++++++++++++ 1 file changed, 135 insertions(+) create mode 100644 content/zh/docs/reference/kubernetes-api/common-definitions/quantity.md diff --git a/content/zh/docs/reference/kubernetes-api/common-definitions/quantity.md b/content/zh/docs/reference/kubernetes-api/common-definitions/quantity.md new file mode 100644 index 0000000000..84ce0dd899 --- /dev/null +++ b/content/zh/docs/reference/kubernetes-api/common-definitions/quantity.md @@ -0,0 +1,135 @@ +--- +api_metadata: + apiVersion: "" + import: "k8s.io/apimachinery/pkg/api/resource" + kind: "Quantity" +content_type: "api_reference" +description: "数量（Quantity）是数字的定点表示。" +title: "Quantity" +weight: 10 +auto_generated: true +--- + + + + + + + +`import "k8s.io/apimachinery/pkg/api/resource"` + + + +数量（Quantity）是数字的定点表示。 +除了 String() 和 AsInt64() 的访问接口之外， +它以 JSON 和 YAML形式提供方便的打包和解包方法。 + +序列化格式如下： + + +``` + ::= + (注意 可能为空, 例如 的 "" 情形。)
+ ::= 0 | 1 | ... | 9
+ ::= |
+ ::= | . | . | .
+ ::= "+" | "-"
+ ::= |
+ ::= | |
+ ::= Ki | Mi | Gi | Ti | Pi | Ei + (国际单位制度；查阅：http://physics.nist.gov/cuu/Units/binary.html)
+ ::= m | "" | k | M | G | T | P | E + (注意，1024 = 1ki 但 1000 = 1k；我没有选择大写。)
+ ::= "e" | "E"
+``` + + + +无论使用三种指数形式中哪一种，没有数量可以表示大于 263-1 的数，也不可能超过 3 个小数位。 +更大或更精确的数字将被截断或向上取整。（例如：0.1m 将向上取整为 1m。） +如果将来我们需要更大或更小的数量，可能会扩展。 + +当从字符串解析数量时，它将记住它具有的后缀类型，并且在序列化时将再次使用相同类型。 + + +在序列化之前，数量将以“规范形式”放置。这意味着指数或者后缀将被向上或向下调整（尾数相应增加或减少），并确保： + 1. 没有精度丢失 + 2. 不会输出小数数字 + 3. 指数（或后缀）尽可能大。 +除非数量是负数，否则将省略正负号。 + + +例如： + - 1.5 将会被序列化成 “1500m” + - 1.5Gi 将会被序列化成 “1536Mi” + + +请注意，数量永远**不会**在内部以浮点数表示。这是本设计的重中之重。 + +只要它们格式正确，非规范值仍将解析，但将以其规范形式重新输出。（所以应该总是使用规范形式，否则不要执行 diff 比较。） + +这种格式旨在使得很难在不撰写某种特殊处理代码的情况下使用这些数字，进而希望实现者也使用定点实现。 + +
From 1698664aed79daf8f9bde9fbdb97c360b8f7f108 Mon Sep 17 00:00:00 2001 From: howieyuen Date: Sat, 26 Mar 2022 15:03:49 +0800 Subject: [PATCH 21/32] [zh]translate content/docs/reference/kubernetes-api/common-definitions/resource-field-selector.md into Chinese --- .../resource-field-selector.md | 62 +++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 content/zh/docs/reference/kubernetes-api/common-definitions/resource-field-selector.md diff --git a/content/zh/docs/reference/kubernetes-api/common-definitions/resource-field-selector.md b/content/zh/docs/reference/kubernetes-api/common-definitions/resource-field-selector.md new file mode 100644 index 0000000000..e77543e25f --- /dev/null +++ b/content/zh/docs/reference/kubernetes-api/common-definitions/resource-field-selector.md @@ -0,0 +1,62 @@ +--- +api_metadata: + apiVersion: "" + import: "k8s.io/api/core/v1" + kind: "ResourceFieldSelector" +content_type: "api_reference" +description: "ResourceFieldSelector 表示容器资源（CPU，内存）及其输出格式。" +title: "ResourceFieldSelector" +weight: 11 +auto_generated: true +--- + + + + + + + +`import "k8s.io/api/core/v1"` + + + +ResourceFieldSelector 表示容器资源（CPU，内存）及其输出格式。 + +
+ +- **resource** (string), 必选 + + + 必选：选择的资源 + +- **containerName** (string) + + + 容器名称：对卷必选，对环境变量可选 + +- **divisor** (}}">Quantity) + + + 指定所曝光资源的输出格式，默认值为“1” + + + From d21c4302bc793971697f6ce6ddd1fa05ceac00c1 Mon Sep 17 00:00:00 2001 From: Mitesh Jain <47820816+miteshskj@users.noreply.github.com> Date: Mon, 28 Mar 2022 19:17:39 +0530 Subject: [PATCH 22/32] Remove bootstrap token being in beta state in kubelet-tls-bootstrapping.md --- .../command-line-tools-reference/kubelet-tls-bootstrapping.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md index 5d2458079e..78aee8cf06 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md @@ -126,7 +126,6 @@ of provisioning. 2. [Token authentication file](#token-authentication-file) Bootstrap tokens are a simpler and more easily managed method to authenticate kubelets, and do not require any additional flags when starting kube-apiserver. -Using bootstrap tokens is currently __beta__ as of Kubernetes version 1.12. Whichever method you choose, the requirement is that the kubelet be able to authenticate as a user with the rights to: From 5183202a3bf782ed4cbecf0b3999ee454c3ad1a4 Mon Sep 17 00:00:00 2001 From: Bob <39816893+bobcode99@users.noreply.github.com> Date: Mon, 28 Mar 2022 22:36:36 +0800 Subject: [PATCH 23/32] Update horizontal-pod-autoscale.md Update HPA V2, custom.metrics.k8s.io, external.metrics.k8s.io design proposals to archive github link. --- .../docs/tasks/run-application/horizontal-pod-autoscale.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md index e5c05ea90c..0039254f7e 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -337,9 +337,9 @@ APIs, cluster administrators must ensure that: * For external metrics, this is the `external.metrics.k8s.io` API. It may be provided by the custom metrics adapters provided above. For more information on these different metrics paths and how they differ please see the relevant design proposals for -[the HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md), -[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md) -and [external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md). +[the HPA V2](https://github.com/kubernetes/design-proposals-archive/blob/main/autoscaling/hpa-v2.md), +[custom.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/custom-metrics-api.md) +and [external.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/external-metrics-api.md). For examples of how to use them see [the walkthrough for using custom metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics) and [the walkthrough for using external metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects). From a76cc64203cecbdb804944664311fa6d86537be6 Mon Sep 17 00:00:00 2001 From: Mitesh Jain <47820816+miteshskj@users.noreply.github.com> Date: Mon, 28 Mar 2022 20:53:39 +0530 Subject: [PATCH 24/32] Fix broken link for stale CSR clean up in garbage-collection.md --- content/en/docs/concepts/architecture/garbage-collection.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/architecture/garbage-collection.md b/content/en/docs/concepts/architecture/garbage-collection.md index 38aa99d654..a6fa885bfc 100644 --- a/content/en/docs/concepts/architecture/garbage-collection.md +++ b/content/en/docs/concepts/architecture/garbage-collection.md @@ -13,7 +13,7 @@ allows the clean up of resources like the following: * [Objects without owner references](#owners-dependents) * [Unused containers and container images](#containers-images) * [Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete](/docs/concepts/storage/persistent-volumes/#delete) - * [Stale or expired CertificateSigningRequests (CSRs)](/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) + * [Stale or expired CertificateSigningRequests (CSRs)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) * {{}} deleted in the following scenarios: * On a cloud when the cluster uses a [cloud controller manager](/docs/concepts/architecture/cloud-controller/) * On-premises when the cluster uses an addon similar to a cloud controller From abab541c57768f977535c6979d7ca82d56076c6e Mon Sep 17 00:00:00 2001 From: Ilya Z Date: Mon, 28 Mar 2022 23:40:05 +0400 Subject: [PATCH 25/32] small_fix --- content/ru/docs/reference/kubectl/overview.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ru/docs/reference/kubectl/overview.md b/content/ru/docs/reference/kubectl/overview.md index 58305f2d95..15a0a3e611 100644 --- a/content/ru/docs/reference/kubectl/overview.md +++ b/content/ru/docs/reference/kubectl/overview.md @@ -52,7 +52,7 @@ kubectl [command] [TYPE] [NAME] [flags] * Выбор ресурсов по одному или нескольким файлов: `-f file1 -f file2 -f file<#>` - * [Используйте YAML вместо JSON](/docs/concepts/configuration/overview/#general-configuration-tips), так так YAML удобнее для пользователей, особенно в конфигурационных файлов.
+ * [Используйте YAML вместо JSON](/docs/concepts/configuration/overview/#general-configuration-tips), так как YAML удобнее для пользователей, особенно в конфигурационных файлах.
Пример: `kubectl get pod -f ./pod.yaml` * `flags`: определяет дополнительные флаги. Например, вы можете использовать флаги `-s` или `--server`, чтобы указать адрес и порт API-сервера Kubernetes.
@@ -162,7 +162,7 @@ kubectl [command] [TYPE] [NAME] [flags] ### Форматирование вывода -Стандартный формат вывода всех команд `kubectl` представлен в человекочитаемом текстовом формате. Чтобы вывести подробности в определенном формате можно добавить флаги `-o` или `--output` к команде `kubectl`. +Стандартный формат вывода всех команд `kubectl` представлен в понятном для человека текстовом формате. Чтобы вывести подробности в определенном формате можно добавить флаги `-o` или `--output` к команде `kubectl`. #### Синтаксис @@ -229,7 +229,7 @@ submit-queue 610995 `kubectl` может получать информацию об объектах с сервера. Это означает, что для любого указанного ресурса сервер вернет столбцы и строки по этому ресурсу, которые отобразит клиент. -Благодаря тому, что сервер инкапсулирует реализацию вывода, гарантируется единообразный и человекочитаемый вывод на всех клиентах, использующих один и тот же кластер. +Благодаря тому, что сервер инкапсулирует реализацию вывода, гарантируется единообразный и понятный для человека вывод на всех клиентах, использующих один и тот же кластер. Эта функциональность включена по умолчанию, начиная с `kubectl` 1.11 и выше. Чтобы отключить ее, добавьте флаг `--server-print=false` в команду `kubectl get`. @@ -340,7 +340,7 @@ kubectl delete pods,services -l name= kubectl delete pods --all ``` -`kubectl exec` - Выполнить команду в контейнера пода. +`kubectl exec` - Выполнить команду в контейнере пода. ```shell # Получить вывод от запущенной команды 'date' в поде . По умолчанию отображается вывод из первого контейнера. From 5ff402c477f792e4bd14658dfee4a5e78647dd6b Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Mon, 28 Mar 2022 23:08:25 +0100 Subject: [PATCH 26/32] Remove incorrect /dockershim alias This fixes up a previous, inadvertent mistake where the alias was retained during localization. --- content/pt-br/blog/_posts/2022-02-17-updated-dockershim-faq.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/pt-br/blog/_posts/2022-02-17-updated-dockershim-faq.md b/content/pt-br/blog/_posts/2022-02-17-updated-dockershim-faq.md index 526ec6e344..bf92c1fedc 100644 --- a/content/pt-br/blog/_posts/2022-02-17-updated-dockershim-faq.md +++ b/content/pt-br/blog/_posts/2022-02-17-updated-dockershim-faq.md @@ -3,7 +3,6 @@ layout: blog title: "Atualizado: Perguntas frequentes (FAQ) sobre a remoção do Dockershim" date: 2022-02-17 slug: dockershim-faq -aliases: [ '/dockershim' ] --- **Esta é uma atualização do artigo original [FAQ sobre a depreciação do Dockershim](/blog/2020/12/02/dockershim-faq/), From fb3db4db2b84f9df11a9a87c551ba9e6a5370d05 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Mon, 28 Mar 2022 23:46:34 +0100 Subject: [PATCH 27/32] Remove incorrect /dockershim alias This fixes up a previous, inadvertent mistake where the alias was retained during localization. --- content/zh/blog/_posts/2022-02-17-updated-dockershim-faq.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/zh/blog/_posts/2022-02-17-updated-dockershim-faq.md b/content/zh/blog/_posts/2022-02-17-updated-dockershim-faq.md index 9a1cac8cc2..8400012b61 100644 --- a/content/zh/blog/_posts/2022-02-17-updated-dockershim-faq.md +++ b/content/zh/blog/_posts/2022-02-17-updated-dockershim-faq.md @@ -3,7 +3,6 @@ layout: blog title: "更新：弃用 Dockershim 的常见问题" date: 2022-02-17 slug: dockershim-faq -aliases: [ '/dockershim' ] --- @@ -38,8 +39,8 @@ Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象 Because Secrets can be created independently of the Pods that use them, there is less risk of the Secret (and its data) being exposed during the workflow of creating, viewing, and editing Pods. Kubernetes, and applications that run in -your cluster, can also take additional precautions with Secrets, such as -avoiding writing confidential data to nonvolatile storage. +your cluster, can also take additional precautions with Secrets, such as avoiding +writing confidential data to nonvolatile storage. Secrets are similar to {{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}} but are specifically intended to hold confidential data. @@ -60,9 +61,11 @@ Additionally, anyone who is authorized to create a Pod in a namespace can use th In order to safely use Secrets, take at least the following steps: 1. [Enable Encryption at Rest](/docs/tasks/administer-cluster/encrypt-data/) for Secrets. -2. Enable or configure [RBAC rules](/docs/reference/access-authn-authz/authorization/) that - restrict reading data in Secrets (including via indirect means). -3. Where appropriate, also use mechanisms such as RBAC to limit which principals are allowed to create new Secrets or replace existing ones. +1. Enable or configure [RBAC rules](/docs/reference/access-authn-authz/authorization/) that + restrict reading and writing data in Secrets. Be aware that secrets can be obtained + implicitly by anyone with the permission to create a Pod. +1. Where appropriate, also use mechanisms such as RBAC to limit which principals are allowed + to create new Secrets or replace existing ones. --> 默认情况下，Kubernetes Secret 未加密地存储在 API 服务器的底层数据存储（etcd）中。 任何拥有 API 访问权限的人都可以检索或修改 Secret，任何有权访问 etcd 的人也可以。 @@ -72,65 +75,1271 @@ In order to safely use Secrets, take at least the following steps: 为了安全地使用 Secret，请至少执行以下步骤： 1. 为 Secret [启用静态加密](/zh/docs/tasks/administer-cluster/encrypt-data/)； -2. 启用或配置 [RBAC 规则](/zh/docs/reference/access-authn-authz/authorization/)来限制读取 Secret 的数据（包括通过间接方式）。 -3. 在适当的情况下，还可以使用 RBAC 等机制来限制允许哪些主体创建新 Secret 或替换现有 Secret。 +1. 启用或配置 [RBAC 规则](/zh/docs/reference/access-authn-authz/authorization/)来限制读取和写入 + Secret 的数据（包括通过间接方式）。需要注意的是，被准许创建 Pod 的人也隐式地被授权获取 + Secret 内容。 +1. 在适当的情况下，还可以使用 RBAC 等机制来限制允许哪些主体创建新 Secret 或替换现有 Secret。 {{< /caution >}} + +参见 [Secret 的信息安全](#information-security-for-secrets)了解详情。 + -## Secret 概览 {#overview-of-secrets} -要使用 Secret，Pod 需要引用 Secret。 -Pod 可以用三种方式之一来使用 Secret： - -- 作为挂载到一个或多个容器上的 {{< glossary_tooltip text="卷" term_id="volume" >}} - 中的[文件](#using-secrets-as-files-from-a-pod)。 -- 作为[容器的环境变量](#using-secrets-as-environment-variables) -- 由 [kubelet 在为 Pod 拉取镜像时使用](#using-imagepullsecrets) - - -Kubernetes 控制平面也使用 Secret； +## Secret 的使用 {#uses-for-secrets} + +Pod 可以用三种方式之一来使用 Secret： + +- 作为挂载到一个或多个容器上的{{< glossary_tooltip text="卷" term_id="volume" >}} + 中的[文件](#using-secrets-as-files-from-a-pod)。 +- 作为[容器的环境变量](#using-secrets-as-environment-variables)。 +- 由 [kubelet 在为 Pod 拉取镜像时使用](#using-imagepullsecrets)。 + +Kubernetes 控制面也使用 Secret； 例如，[引导令牌 Secret](#bootstrap-token-secrets) 是一种帮助自动化节点注册的机制。 +### Secret 的替代方案 {#alternatives-to-secrets} + +除了使用 Secret 来保护机密数据，你也可以选择一些替代方案。 + +下面是一些选项： + + +- 如果你的云原生组件需要执行身份认证来访问你所知道的、在同一 Kubernetes 集群中运行的另一个应用， + 你可以使用 [ServiceAccount](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens) + 及其令牌来标识你的客户端身份。 +- 你可以运行的第三方工具也有很多，这些工具可以运行在集群内或集群外，提供机密数据管理。 + 例如，这一工具可能是 Pod 通过 HTTPS 访问的一个服务，该服务在客户端能够正确地通过身份认证 + （例如，通过 ServiceAccount 令牌）时，提供机密数据内容。 + +- 就身份认证而言，你可以为 X.509 证书实现一个定制的签名者，并使用 + [CertificateSigningRequest](/zh/docs/reference/access-authn-authz/certificate-signing-requests/) + 来让该签名者为需要证书的 Pod 发放证书。 +- 你可以使用一个[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) + 来将节点本地的加密硬件暴露给特定的 Pod。例如，你可以将可信任的 Pod + 调度到提供可信平台模块（Trusted Platform Module，TPM）的节点上。 + 这类节点是另行配置的。 + + +你还可以将如上选项的两种或多种进行组合，包括直接使用 Secret 对象本身也是一种选项。 + +例如：实现（或部署）一个 {{< glossary_tooltip text="operator" term_id="operator-pattern" >}}， +从外部服务取回生命期很短的会话令牌，之后基于这些生命期很短的会话令牌来创建 Secret。 +运行在集群中的 Pod 可以使用这些会话令牌，而 Operator 则确保这些令牌是合法的。 +这种责权分离意味着你可以运行那些不了解会话令牌如何发放与刷新的确切机制的 Pod。 + + +## 使用 Secret {#working-with-secrets} + +### 创建 Secret {#creating-a-secret} + +- [使用 `kubectl` 命令来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- [基于配置文件来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- [使用 kustomize 来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize/) + + +#### 对 Secret 名称与数据的约束 {#restriction-names-data} + +Secret 对象的名称必须是合法的 +[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 + + -Secret 对象的名称必须是合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 在为创建 Secret 编写配置文件时，你可以设置 `data` 与/或 `stringData` 字段。 `data` 和 `stringData` 字段都是可选的。`data` 字段中所有键值都必须是 base64 编码的字符串。如果不希望执行这种 base64 字符串的转换操作，你可以选择设置 `stringData` 字段，其中可以使用任何字符串作为其取值。 +`data` 和 `stringData` 中的键名只能包含字母、数字、`-`、`_` 或 `.` 字符。 +`stringData` 字段中的所有键值对都会在内部被合并到 `data` 字段中。 +如果某个主键同时出现在 `data` 和 `stringData` 字段中，`stringData` +所指定的键值具有高优先级。 + + +#### 尺寸限制 {#restriction-data-size} + +每个 Secret 的尺寸最多为 1MiB。施加这一限制是为了避免用户创建非常大的 Secret， +进而导致 API 服务器和 kubelet 内存耗尽。不过创建很多小的 Secret 也可能耗尽内存。 +你可以使用[资源配额](/zh/docs/concepts/policy/resource-quotas/)来约束每个名字空间中 +Secret（或其他资源）的个数。 + + +### 编辑 Secret {#editing-a-secret} + +你可以使用 kubectl 来编辑一个已有的 Secret： + +```shell +kubectl edit secrets mysecret +``` + +这一命令会启动你的默认编辑器，允许你更新 `data` 字段中存放的 base64 编码的 Secret 值； +例如： + +```yaml +# Please edit the object below. Lines beginning with a '#' will be ignored, +# and an empty file will abort the edit. If an error occurs while saving this file, it will be +# reopened with the relevant failures. +# +apiVersion: v1 +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm +kind: Secret +metadata: + annotations: + kubectl.kubernetes.io/last-applied-configuration: { ... } + creationTimestamp: 2020-01-22T18:41:56Z + name: mysecret + namespace: default + resourceVersion: "164619" + uid: cfee02d6-c137-11e5-8d73-42010af00002 +type: Opaque +``` + + +这一示例清单定义了一个 Secret，其 `data` 字段中包含两个主键：`username` 和 `password`。 +清单中的字段值是 Base64 字符串，不过，当你在 Pod 中使用 Secret 时，kubelet 为 Pod +及其中的容器提供的是解码后的数据。 + +你可以在一个 Secret 中打包多个主键和数值，也可以选择使用多个 Secret， +完全取决于哪种方式最方便。 + + +### 使用 Secret {#using-a-secret} + +Secret 可以以数据卷的形式挂载，也可以作为{{< glossary_tooltip text="环境变量" term_id="container-env-variables" >}} +暴露给 Pod 中的容器使用。Secret 也可用于系统中的其他部分，而不是一定要直接暴露给 Pod。 +例如，Secret 也可以包含系统中其他部分在替你与外部系统交互时要使用的凭证数据。 + + +Kubernetes 会检查 Secret 的卷数据源，确保所指定的对象引用确实指向类型为 Secret +的对象。因此，如果 Pod 依赖于某 Secret，该 Secret 必须先于 Pod 被创建。 + +如果 Secret 内容无法取回（可能因为 Secret 尚不存在或者临时性地出现 API +服务器网络连接问题），kubelet 会周期性地重试 Pod 运行操作。kubelet 也会为该 Pod +报告 Event 事件，给出读取 Secret 时遇到的问题细节。 + + +#### 可选的 Secret {#restriction-secret-must-exist} + +当你定义一个基于 Secret 的环境变量时，你可以将其标记为可选。 +默认情况下，所引用的 Secret 都是必需的。 + +只有所有非可选的 Secret 都可用时，Pod 中的容器才能启动运行。 + +如果 Pod 引用了 Secret 中的特定主键，而虽然 Secret 本身存在，对应的主键不存在， +Pod 启动也会失败。 + + +### 在 Pod 中以文件形式使用 Secret {#using-secrets-as-files-from-a-pod} + +如果你希望在 Pod 中访问 Secret 内的数据，一种方式是让 Kubernetes 将 Secret +以 Pod 中一个或多个容器的文件系统中的文件的形式呈现出来。 + +要配置这种行为，你需要： + + +1. 创建一个 Secret 或者使用已有的 Secret。多个 Pod 可以引用同一个 Secret。 +1. 更改 Pod 定义，在 `.spec.volumes[]` 下添加一个卷。根据需要为卷设置其名称， + 并将 `.spec.volumes[].secret.secretName` 字段设置为 Secret 对象的名称。 +1. 为每个需要该 Secret 的容器添加 `.spec.containers[].volumeMounts[]`。 + 并将 `.spec.containers[].volumeMounts[].readyOnly` 设置为 `true`， + 将 `.spec.containers[].volumeMounts[].mountPath` 设置为希望 Secret + 被放置的、目前尚未被使用的路径名。 +1. 更改你的镜像或命令行，以便程序读取所设置的目录下的文件。Secret 的 `data` + 映射中的每个主键都成为 `mountPath` 下面的文件名。 + +下面是一个通过卷来挂载名为 `mysecret` 的 Secret 的 Pod 示例： + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret + optional: false # 默认设置，意味着 "mysecret" 必须已经存在 +``` + + +你要访问的每个 Secret 都需要通过 `.spec.volumes` 来引用。 + +如果 Pod 中包含多个容器，则每个容器需要自己的 `volumeMounts` 块， +不过针对每个 Secret 而言，只需要一份 `.spec.volumes` 设置。 + +{{< note >}} + +Kubernetes v1.22 版本之前都会自动创建用来访问 Kubernetes API 的凭证。 +这一老的机制是基于创建可被挂载到 Pod 中的令牌 Secret 来实现的。 +在最近的版本中，包括 Kubernetes v{{< skew currentVersion >}} 中，API 凭据是直接通过 +[TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) +API 来获得的，这一凭据会使用[投射卷](/zh/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume) +挂载到 Pod 中。使用这种方式获得的令牌有确定的生命期，并且在挂载它们的 Pod +被删除时自动作废。 + + +你仍然可以[手动创建](/zh/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token) +服务账号令牌。例如，当你需要一个永远都不过期的令牌时。 +不过，仍然建议使用 [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) +子资源来获得访问 API 服务器的令牌。 +{{< /note >}} + + +#### 将 Secret 键投射到特定目录 + +你也可以控制 Secret 键所投射到的卷中的路径。 +你可以使用 `.spec.volumes[].secret.items` 字段来更改每个主键的目标路径： + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret + items: + - key: username + path: my-group/my-username +``` + + +将发生的事情如下： + +- `mysecret` 中的键 `username` 会出现在容器中的路径为 `/etc/foo/my-group/my-username`， + 而不是 `/etc/foo/username`。 +- Secret 对象的 `password` 键不会被投射。 + +如果使用了 `.spec.volumes[].secret.items`，则只有 `items` 中指定了的主键会被投射。 +如果要使用 Secret 中的所有主键，则需要将它们全部枚举到 `items` 字段中。 + +如果你显式地列举了主键，则所列举的主键都必须在对应的 Secret 中存在。 +否则所在的卷不会被创建。 + + +#### Secret 文件的访问权限 + +你可以为某个 Secret 主键设置 POSIX 文件访问权限位。 +如果你不指定访问权限，默认会使用 `0644`。 +你也可以为整个 Secret 卷设置默认的访问模式，然后再根据需要在主键层面重载。 + +例如，你可以像下面这样设置默认的模式： + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + volumes: + - name: foo + secret: + secretName: mysecret + defaultMode: 0400 +``` + + +该 Secret 被挂载在 `/etc/foo` 下，Secret 卷挂载所创建的所有文件的访问模式都是 `0400`。 + +{{< note >}} + +如果你是使用 JSON 来定义 Pod 或 Pod 模板，需要注意 JSON 规范不支持八进制的记数方式。 +你可以在 `defaultMode` 中设置十进制的值（例如，八进制中的 0400 在十进制中为 256）。 +如果你使用 YAML 来编写定义，你可以用八进制值来设置 `defaultMode`。 +{{< /note >}} + + +#### 使用来自卷中的 Secret 值 {#consuming-secret-values-from-volumes} + +在挂载了 Secret 卷的容器内，Secret 的主键都呈现为文件。 +Secret 的取值都是 Base64 编码的，保存在这些文件中。 + +下面是在上例中的容器内执行命令的结果： + +```shell +ls /etc/foo/ +``` + + +输出类似于： + +``` +username +password +``` + +```shell +cat /etc/foo/username +``` + + +输出类似于： + +``` +admin +``` + +```shell +cat /etc/foo/password +``` + + +输出类似于： + +``` +1f2d1e2e67df +``` + + +容器中的程序要负责根据需要读取 Secret 数据。 + + +#### 挂载的 Secret 是被自动更新的 {#mounted-secrets-are-updated-automatically} + +当卷中包含来自 Secret 的数据，而对应的 Secret 被更新，Kubernetes +会跟踪到这一操作并更新卷中的数据。更新的方式是保证最终一致性。 + +{{< note >}} + +对于以 [subPath](/zh/docs/concepts/storage/volumes#using-subpath) 形式挂载 Secret 卷的容器而言， +它们无法收到自动的 Secret 更新。 +{{< /note >}} + + +Kubelet 组件会维护一个缓存，在其中保存节点上 Pod 卷中使用的 Secret 的当前主键和取值。 +你可以配置 kubelet 如何检测所缓存数值的变化。 +[kubelet 配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/)中的 +`configMapAndSecretChangeDetectionStrategy` 字段控制 kubelet 所采用的策略。 +默认的策略是 `Watch`。 + + +对 Secret 的更新操作既可以通过 API 的 watch 机制（默认）来传播， +基于设置了生命期的缓存获取，也可以通过 kubelet 的同步回路来从集群的 API +服务器上轮询获取。 + + +因此，从 Secret 被更新到新的主键被投射到 Pod 中，中间存在一个延迟。 +这一延迟的上限是 kubelet 的同步周期加上缓存的传播延迟， +其中缓存的传播延迟取决于所选择的缓存类型。 +对应上一段中提到的几种传播机制，延迟时长为 watch 的传播延迟、所配置的缓存 TTL +或者对于直接轮询而言是零。 + + +### 以环境变量的方式使用 Secret {#using-secrets-as-environment-variables} + +如果需要在 Pod 中以{{< glossary_tooltip text="环境变量" term_id="container-env-variables" >}} +的形式使用 Secret： + + +1. 创建 Secret（或者使用现有 Secret）。多个 Pod 可以引用同一个 Secret。 +1. 更改 Pod 定义，在要使用 Secret 键值的每个容器中添加与所使用的主键对应的环境变量。 + 读取 Secret 主键的环境变量应该在 `env[].valueFrom.secretKeyRef` 中填写 Secret + 的名称和主键名称。 +1. 更改你的镜像或命令行，以便程序读取环境变量中保存的值。 + + +下面是一个通过环境变量来使用 Secret 的示例 Pod： + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-env-pod +spec: + containers: + - name: mycontainer + image: redis + env: + - name: SECRET_USERNAME + valueFrom: + secretKeyRef: + name: mysecret + key: username + optional: false # 此值为默认值；意味着 "mysecret" + # 必须存在且包含名为 "username" 的主键 + - name: SECRET_PASSWORD + valueFrom: + secretKeyRef: + name: mysecret + key: password + optional: false # 此值为默认值；意味着 "mysecret" + # 必须存在且包含名为 "password" 的主键 + restartPolicy: Never +``` + + +#### 非法环境变量 {#restriction-env-from-invalid} + +对于通过 `envFrom` 字段来填充环境变量的 Secret 而言， +如果其中包含的主键不能被当做合法的环境变量名，这些主键会被忽略掉。 +Pod 仍然可以启动。 + + +如果你定义的 Pod 中包含非法的变量名称，则 Pod 可能启动失败， +会形成 reason 为 `InvalidVariableNames` 的事件，以及列举被略过的非法主键的消息。 +下面的例子中展示了一个 Pod，引用的是名为 `mysecret` 的 Secret， +其中包含两个非法的主键：`1badkey` 和 `2alsobad`。 + +```shell +kubectl get events +``` + + +输出类似于： + +``` +LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON +0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames kubelet, 127.0.0.1 Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names. +``` + + +#### 通过环境变量使用 Secret 值 + +在通过环境变量来使用 Secret 的容器中，Secret 主键展现为普通的环境变量。 +这些变量的取值是 Secret 数据的 Base64 解码值。 + +下面是在前文示例中的容器内执行命令的结果： + +```shell +echo "$SECRET_USERNAME" +``` + + +输出类似于： + +``` +admin +``` + +```shell +echo "$SECRET_PASSWORD" +``` + + +输出类似于： + +``` +1f2d1e2e67df +``` + +{{< note >}} + +如果容器已经在通过环境变量来使用 Secret，Secret 更新在容器内是看不到的， +除非容器被重启。有一些第三方的解决方案，能够在 Secret 发生变化时触发容器重启。 +{{< /note >}} + + +### 容器镜像拉取 Secret {#using-imagepullsecrets} + +如果你尝试从私有仓库拉取容器镜像，你需要一种方式让每个节点上的 kubelet +能够完成与镜像库的身份认证。你可以配置 *镜像拉取 Secret* 来实现这点。 +Secret 是在 Pod 层面来配置的。 + + +Pod 的 `imagePullSecrets` 字段是一个对 Pod 所在的名字空间中的 Secret +的引用列表。你可以使用 `imagePullSecrets` 来将镜像仓库访问凭据传递给 kubelet。 +kubelet 使用这个信息来替你的 Pod 拉取私有镜像。 +参阅 [Pod API 参考](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec) +中的 `PodSpec` 进一步了解 `imagePullSecrets` 字段。 + + +#### 使用 imagePullSecrets + +`imagePullSecrets` 字段是一个列表，包含对同一名字空间中 Secret 的引用。 +你可以使用 `imagePullSecrets` 将包含 Docker（或其他）镜像仓库密码的 Secret +传递给 kubelet。kubelet 使用此信息来替 Pod 拉取私有镜像。 +参阅 [PodSpec API ](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec) +进一步了解 `imagePullSecrets` 字段。 + + +##### 手动设定 imagePullSecret + +你可以通过阅读[容器镜像](/zh/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) +文档了解如何设置 `imagePullSecrets`。 + + +##### 设置 imagePullSecrets 为自动挂载 + +你可以手动创建 `imagePullSecret`，并在一个 ServiceAccount 中引用它。 +对使用该 ServiceAccount 创建的所有 Pod，或者默认使用该 ServiceAccount 创建的 Pod +而言，其 `imagePullSecrets` 字段都会设置为该服务账号。 +请阅读[向服务账号添加 ImagePullSecrets](/zh/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) +来详细了解这一过程。 + + +### 在静态 Pod 中使用 Secret {#restriction-static-pod} + +你不可以在{{< glossary_tooltip text="静态 Pod" term_id="static-pod" >}}. +中使用 ConfigMap 或 Secret。 + + +## 使用场景 {#use-case} + +### 使用场景：作为容器环境变量 + +创建 Secret： + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + USER_NAME: YWRtaW4= + PASSWORD: MWYyZDFlMmU2N2Rm +``` + + +创建 Secret： + +```shell +kubectl apply -f mysecret.yaml +``` + + +使用 `envFrom` 来将 Secret 的所有数据定义为容器的环境变量。 +来自 Secret 的主键成为 Pod 中的环境变量名称： + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "env" ] + envFrom: + - secretRef: + name: mysecret + restartPolicy: Never +``` + + +### 使用场景：带 SSH 密钥的 Pod + +创建包含一些 SSH 密钥的 Secret： + +```shell +kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub +``` + + +输出类似于： + +``` +secret "ssh-key-secret" created +``` + + +你也可以创建一个 `kustomization.yaml` 文件，在其 `secretGenerator` +字段中包含 SSH 密钥。 + +{{< caution >}} + +在提供你自己的 SSH 密钥之前要仔细思考：集群的其他用户可能有权访问该 Secret。 + + +你也可以创建一个 SSH 私钥，代表一个你希望与你共享 Kubernetes 集群的其他用户分享的服务标识。 +当凭据信息被泄露时，你可以收回该访问权限。 +{{< /caution >}} + + +现在你可以创建一个 Pod，在其中访问包含 SSH 密钥的 Secret，并通过卷的方式来使用它： + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-test-pod + labels: + name: secret-test +spec: + volumes: + - name: secret-volume + secret: + secretName: ssh-key-secret + containers: + - name: ssh-test-container + image: mySshImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +``` + + +容器命令执行时，秘钥的数据可以在下面的位置访问到： + +``` +/etc/secret-volume/ssh-publickey +/etc/secret-volume/ssh-privatekey +``` + + +容器就可以随便使用 Secret 数据来建立 SSH 连接。 + + +### 使用场景：带有生产、测试环境凭据的 Pod + +这一示例所展示的一个 Pod 会使用包含生产环境凭据的 Secret，另一个 Pod +使用包含测试环境凭据的 Secret。 + +你可以创建一个带有 `secretGenerator` 字段的 `kustomization.yaml` 文件或者运行 +`kubectl create secret` 来创建 Secret。 + +```shell +kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 +``` + + +输出类似于： + +``` +secret "prod-db-secret" created +``` + + +你也可以创建一个包含测试环境凭据的 Secret： + +```shell +kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests +``` + + +输出类似于： + +``` +secret "test-db-secret" created +``` + +{{< note >}} + +特殊字符（例如 `$`、`\`、`*`、`=` 和 `!`）会被你的 +[Shell](https://en.wikipedia.org/wiki/Shell_(computing))解释，因此需要转义。 + + +在大多数 Shell 中，对密码进行转义的最简单方式是用单引号（`'`）将其括起来。 +例如，如果你的实际密码是 `S!B\*d$zDsb`，则应通过以下方式执行命令： + +```shell +kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb=' +``` + +你无需对文件中的密码（`--from-file`）中的特殊字符进行转义。 +{{< /note >}} + + +现在生成 Pod： + +```shell +cat < pod.yaml +apiVersion: v1 +kind: List +items: +- kind: Pod + apiVersion: v1 + metadata: + name: prod-db-client-pod + labels: + name: prod-db-client + spec: + volumes: + - name: secret-volume + secret: + secretName: prod-db-secret + containers: + - name: db-client-container + image: myClientImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +- kind: Pod + apiVersion: v1 + metadata: + name: test-db-client-pod + labels: + name: test-db-client + spec: + volumes: + - name: secret-volume + secret: + secretName: test-db-secret + containers: + - name: db-client-container + image: myClientImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +EOF +``` + + +将 Pod 添加到同一 `kustomization.yaml` 文件中： + +```shell +cat <> kustomization.yaml +resources: +- pod.yaml +EOF +``` + + +通过下面的命令在 API 服务器上应用所有这些对象： + +```shell +kubectl apply -k . +``` + + +两个文件都会在其文件系统中出现下面面的文件，文件中内容是各个容器的环境值： + +``` +/etc/secret-volume/username +/etc/secret-volume/password +``` + + +注意这两个 Pod 的规约中只有一个字段不同。 +这便于基于相同的 Pod 模板生成具有不同能力的 Pod。 + + +你可以通过使用两个服务账号来进一步简化这一基本的 Pod 规约： + +1. `prod-user` 服务账号使用 `prod-db-secret` +1. `test-user` 服务账号使用 `test-db-secret` + +Pod 规约简化为： + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: prod-db-client-pod + labels: + name: prod-db-client +spec: + serviceAccount: prod-db-client + containers: + - name: db-client-container + image: myClientImage +``` + + +### 使用场景：在 Secret 卷中带句点的文件 + +通过定义以句点（`.`）开头的主键，你可以“隐藏”你的数据。 +这些主键代表的是以句点开头的文件或“隐藏”文件。 +例如，当下面的 Secret 被挂载到 `secret-volume` 卷中时： + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: dotfile-secret +data: + .secret-file: dmFsdWUtMg0KDQo= +--- +apiVersion: v1 +kind: Pod +metadata: + name: secret-dotfiles-pod +spec: + volumes: + - name: secret-volume + secret: + secretName: dotfile-secret + containers: + - name: dotfile-test-container + image: k8s.gcr.io/busybox + command: + - ls + - "-l" + - "/etc/secret-volume" + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +``` + + +卷中会包含一个名为 `.secret-file` 的文件，并且容器 `dotfile-test-container` +中此文件位于路径 `/etc/secret-volume/.secret-file` 处。 + +{{< note >}} + +以句点开头的文件会在 `ls -l` 的输出中被隐藏起来； +列举目录内容时你必须使用 `ls -la` 才能看到它们。 +{{< /note >}} + + +### 使用场景：仅对 Pod 中一个容器可见的 Secret + +考虑一个需要处理 HTTP 请求，执行某些复杂的业务逻辑，之后使用 HMAC +来对某些消息进行签名的程序。因为这一程序的应用逻辑很复杂， +其中可能包含未被注意到的远程服务器文件读取漏洞， +这种漏洞可能会把私钥暴露给攻击者。 + + +这一程序可以分隔成两个容器中的两个进程：前端容器要处理用户交互和业务逻辑， +但无法看到私钥；签名容器可以看到私钥，并对来自前端的简单签名请求作出响应 +（例如，通过本地主机网络）。 + + +采用这种划分的方法，攻击者现在必须欺骗应用服务器来做一些其他操作， +而这些操作可能要比读取一个文件要复杂很多。 + ## Secret 的类型 {#secret-types} -创建 Secret 时，你可以使用 Secret 资源的 `type` 字段， -或者与其等价的 `kubectl` 命令行参数（如果有的话）为其设置类型。 -Secret 的 `type` 有助于对不同类型机密数据的编程处理。 +创建 Secret 时，你可以使用 [Secret](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/) +资源的 `type` 字段，或者与其等价的 `kubectl` 命令行参数（如果有的话）为其设置类型。 +Secret 类型有助于对 Secret 数据进行编程处理。 Kubernetes 提供若干种内置的类型，用于一些常见的使用场景。 针对这些类型，Kubernetes 所执行的合法性检查操作以及对其所实施的限制各不相同。 @@ -171,15 +1380,27 @@ Kubernetes 提供若干种内置的类型，用于一些常见的使用场景。 +通过为 Secret 对象的 `type` 字段设置一个非空的字符串值，你也可以定义并使用自己 +Secret 类型。如果 `type` 值为空字符串，则被视为 `Opaque` 类型。 + + -通过为 Secret 对象的 `type` 字段设置一个非空的字符串值，你也可以定义并使用自己 -Secret 类型。如果 `type` 值为空字符串，则被视为 `Opaque` 类型。 Kubernetes 并不对类型的名称作任何限制。不过，如果你要使用内置类型之一， 则你必须满足为该类型所定义的所有要求。 + +如果你要定义一种公开使用的 Secret 类型，请遵守 Secret 类型的约定和结构， +在类型名签名添加域名，并用 `/` 隔开。 +例如：`cloud-hosting.example.net/cloud-api-credentials`。 + ### 服务账号令牌 Secret {#service-account-token-secrets} 类型为 `kubernetes.io/service-account-token` 的 Secret 用来存放标识某 -服务账号的令牌。使用这种 Secret 类型时，你需要确保对象的注解 -`kubernetes.io/service-account-name` 被设置为某个已有的服务账号名称。 -某个 Kubernetes 控制器会填写 Secret 的其它字段，例如 -`kubernetes.io/service-account.uid` 注解以及 `data` 字段中的 `token` -键值，使之包含实际的令牌内容。 +{{< glossary_tooltip text="服务账号" term_id="service-account" >}}的令牌。 +使用这种 Secret 类型时，你需要确保对象的注解 `kubernetes.io/service-account-name` +被设置为某个已有的服务账号名称。某个 Kubernetes +{{< glossary_tooltip text="控制器" term_id="controller" >}}会填写 Secret +的其它字段，例如 `kubernetes.io/service-account.uid` 注解以及 `data` 字段中的 +`token` 键值，使之包含实际的令牌内容。 下面的配置实例声明了一个服务账号令牌 Secret： @@ -268,9 +1494,9 @@ data: ``` -`kubernetes.io/dockercfg` 是一种保留类型，用来存放 `~/.dockercfg` 文件的 -序列化形式。该文件是配置 Docker 命令行的一种老旧形式。 -使用此 Secret 类型时，你需要确保 Secret 的 `data` 字段中包含名为 -`.dockercfg` 的主键，其对应键值是用 base64 编码的某 `~/.dockercfg` -文件的内容。 +`kubernetes.io/dockercfg` 是一种保留类型，用来存放 `~/.dockercfg` 文件的序列化形式。 +该文件是配置 Docker 命令行的一种老旧形式。使用此 Secret 类型时，你需要确保 +Secret 的 `data` 字段中包含名为 `.dockercfg` 的主键，其对应键值是用 base64 +编码的某 `~/.dockercfg` 文件的内容。 类型 `kubernetes.io/dockerconfigjson` 被设计用来保存 JSON 数据的序列化形式， -该 JSON 也遵从 `~/.docker/config.json` 文件的格式规则，而后者是 -`~/.dockercfg` 的新版本格式。 -使用此 Secret 类型时，Secret 对象的 `data` 字段必须包含 `.dockerconfigjson` -键，其键值为 base64 编码的字符串包含 `~/.docker/config.json` 文件的内容。 +该 JSON 也遵从 `~/.docker/config.json` 文件的格式规则，而后者是 `~/.dockercfg` +的新版本格式。使用此 Secret 类型时，Secret 对象的 `data` 字段必须包含 +`.dockerconfigjson` 键，其键值为 base64 编码的字符串包含 `~/.docker/config.json` +文件的内容。 下面是一个 `kubernetes.io/dockercfg` 类型 Secret 的示例： @@ -376,25 +1601,24 @@ to create a Docker registry Secret, you can do: ```shell kubectl create secret docker-registry secret-tiger-docker \ + --docker-email=tiger@acme.example \ --docker-username=tiger \ --docker-password=pass113 \ - --docker-email=tiger@acme.com + --docker-server=my-registry.example:5000 ``` 上面的命令创建一个类型为 `kubernetes.io/dockerconfigjson` 的 Secret。 -如果你对 `data` 字段中的 `.dockerconfigjson` 内容进行转储，你会得到下面的 -JSON 内容，而这一内容是一个合法的 Docker 配置文件。 +如果你对 `.data.dockerconfigjson` 内容进行转储并执行 base64 解码： ```json { "auths": { - "https://index.docker.io/v1/": { + "my-registry.example:5000": { "username": "tiger", "password": "pass113", "email": "tiger@acme.com", @@ -404,6 +1628,15 @@ JSON 内容，而这一内容是一个合法的 Docker 配置文件。 } ``` +{{< note >}} + +`auths` 值是 base64 编码的，其内容被屏蔽但未被加密。 +任何能够读取该 Secret 的人都可以了解镜像库的访问令牌。 +{{< /note >}} + -提供基本身份认证类型的 Secret 仅仅是出于用户方便性考虑。 +提供基本身份认证类型的 Secret 仅仅是出于方便性考虑。 你也可以使用 `Opaque` 类型来保存用于基本身份认证的凭据。 -不过，使用内置的 Secret 类型的有助于对凭据格式进行归一化处理，并且 -API 服务器确实会检查 Secret 配置中是否提供了所需要的主键。 +不过，使用预定义的、公开的 Secret 类型（`kubernetes.io/basic-auth`） +有助于帮助其他用户理解 Secret 的目的，并且对其中存在的主键形成一种约定。 +API 服务器会检查 Secret 配置中是否提供了所需要的主键。 ### SSH 身份认证 Secret {#ssh-authentication-secrets} @@ -472,7 +1709,7 @@ Kubernetes 所提供的内置类型 `kubernetes.io/ssh-auth` 用来存放 SSH 所需要的凭据。使用这种 Secret 类型时，你就必须在其 `data` （或 `stringData`） 字段中提供一个 `ssh-privatekey` 键值对，作为要使用的 SSH 凭据。 -下面的 YAML 是一个 SSH 身份认证 Secret 的配置示例： +下面的清单是一个 SSH 公钥/私钥身份认证的 Secret 示例： ```yaml apiVersion: v1 @@ -488,23 +1725,26 @@ data: 提供 SSH 身份认证类型的 Secret 仅仅是出于用户方便性考虑。 你也可以使用 `Opaque` 类型来保存用于 SSH 身份认证的凭据。 -不过，使用内置的 Secret 类型的有助于对凭据格式进行归一化处理，并且 +不过，使用预定义的、公开的 Secret 类型（`kubernetes.io/ssh-auth`） +有助于其他人理解你的 Secret 的用途，也可以就其中包含的主键名形成约定。 API 服务器确实会检查 Secret 配置中是否提供了所需要的主键。 +{{< caution >}} -{{< caution >}} SSH 私钥自身无法建立 SSH 客户端与服务器端之间的可信连接。 需要其它方式来建立这种信任关系，以缓解“中间人（Man In The Middle）” 攻击，例如向 ConfigMap 中添加一个 `known_hosts` 文件。 @@ -514,9 +1754,11 @@ SSH 私钥自身无法建立 SSH 客户端与服务器端之间的可信连接 ### TLS secrets Kubernetes provides a builtin Secret type `kubernetes.io/tls` for storing -a certificate and its associated key that are typically used for TLS . This -data is primarily used with TLS termination of the Ingress resource, but may -be used with other resources or directly by a workload. +a certificate and its associated key that are typically used for TLS. + +One common use for TLS secrets is to configure encryption in transit for +an [Ingress](/docs/concepts/services-networking/ingress/), but you can also use it +with other resources or directly in your workload. When using this type of Secret, the `tls.key` and the `tls.crt` key must be provided in the `data` (or `stringData`) field of the Secret configuration, although the API server doesn't actually validate the values for each key. @@ -525,12 +1767,12 @@ The following YAML contains an example config for a TLS Secret: --> ### TLS Secret -Kubernetes 提供一种内置的 `kubernetes.io/tls` Secret 类型，用来存放证书 -及其相关密钥（通常用在 TLS 场合）。 -此类数据主要提供给 Ingress 资源，用以终结 TLS 链接，不过也可以用于其他 -资源或者负载。当使用此类型的 Secret 时，Secret 配置中的 `data` （或 -`stringData`）字段必须包含 `tls.key` 和 `tls.crt` 主键，尽管 API 服务器 -实际上并不会对每个键的取值作进一步的合法性检查。 +Kubernetes 提供一种内置的 `kubernetes.io/tls` Secret 类型，用来存放 TLS +场合通常要使用的证书及其相关密钥。 +TLS Secret 的一种典型用法是为 [Ingress](/zh/docs/concepts/services-networking/ingress/) +资源配置传输过程中的数据加密，不过也可以用于其他资源或者直接在负载中使用。 +当使用此类型的 Secret 时，Secret 配置中的 `data` （或 `stringData`）字段必须包含 +`tls.key` 和 `tls.crt` 主键，尽管 API 服务器实际上并不会对每个键的取值作进一步的合法性检查。 下面的 YAML 包含一个 TLS Secret 的配置示例： @@ -573,18 +1815,36 @@ kubectl create secret tls my-tls-secret \ -这里的公钥/私钥对都必须事先已存在。用于 `--cert` 的公钥证书必须是 .PEM 编码的 -（Base64 编码的 DER 格式），且与 `--key` 所给定的私钥匹配。 -私钥必须是通常所说的 PEM 私钥格式，且未加密。对这两个文件而言，PEM 格式数据 -的第一行和最后一行（例如，证书所对应的 `--------BEGIN CERTIFICATE-----` 和 -`-------END CERTIFICATE----`）都不会包含在其中。 +这里的公钥/私钥对都必须事先已存在。用于 `--cert` 的公钥证书必须是 +[RFC 7468 中 5.1 节](https://datatracker.ietf.org/doc/html/rfc7468#section-5.1) +中所规定的 DER 格式，且与 `--key` 所给定的私钥匹配。 +私钥必须是 DER 格式的 PKCS #8 +（参见 [RFC 7468 第 11节](https://datatracker.ietf.org/doc/html/rfc7468#section-11)）。 + +{{< note >}} + +类型为 `kubernetes.io/tls` 的 Secret 中包含密钥和证书的 DER 数据，以 Base64 格式编码。 +如果你熟悉私钥和证书的 PEM 格式，base64 与该格式相同，只是你需要略过 PEM +数据中所包含的第一行和最后一行。 + + +例如，对于证书而言，你 **不要** 包含 `--------BEGIN CERTIFICATE-----` +和 `-------END CERTIFICATE----` 这两行。 +{{< /note >}} + -## 创建 Secret {#creating-a-secret} - -有几种不同的方式来创建 Secret： - -- [使用 `kubectl` 命令创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/) -- [使用配置文件来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/) -- [使用 kustomize 来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize/) - - -## 编辑 Secret {#editing-a-secret} - -你可以通过下面的命令编辑现有的 Secret： - -```shell -kubectl edit secrets mysecret -``` - - -这一命令会打开默认的编辑器，允许你更新 `data` 字段中包含的 -base64 编码的 Secret 值： - -```yaml -# Please edit the object below. Lines beginning with a '#' will be ignored, -# and an empty file will abort the edit. If an error occurs while saving this file will be -# reopened with the relevant failures. -# -apiVersion: v1 -data: - username: YWRtaW4= - password: MWYyZDFlMmU2N2Rm -kind: Secret -metadata: - annotations: - kubectl.kubernetes.io/last-applied-configuration: { ... } - creationTimestamp: 2016-01-22T18:41:56Z - name: mysecret - namespace: default - resourceVersion: "164619" - uid: cfee02d6-c137-11e5-8d73-42010af00002 -type: Opaque -``` - - -## 使用 Secret {#using-secrets} - -Secret 可以作为数据卷被挂载，或作为{{< glossary_tooltip text="环境变量" term_id="container-env-variables" >}} -暴露出来以供 Pod 中的容器使用。它们也可以被系统的其他部分使用，而不直接暴露在 Pod 内。 -例如，它们可以保存凭据，系统的其他部分将用它来代表你与外部系统进行交互。 - - - -### 在 Pod 中使用 Secret 文件 {#using-secrets-as-files-from-a-pod} - -在 Pod 中使用存放在卷中的 Secret： - -1. 创建一个 Secret 或者使用已有的 Secret。多个 Pod 可以引用同一个 Secret。 -1. 修改你的 Pod 定义，在 `spec.volumes[]` 下增加一个卷。可以给这个卷随意命名， - 它的 `spec.volumes[].secret.secretName` 必须是 Secret 对象的名字。 -1. 将 `spec.containers[].volumeMounts[]` 加到需要用到该 Secret 的容器中。 - 指定 `spec.containers[].volumeMounts[].readOnly = true` 和 - `spec.containers[].volumeMounts[].mountPath` 为你想要该 Secret 出现的尚未使用的目录。 -1. 修改你的镜像并且／或者命令行，让程序从该目录下寻找文件。 - Secret 的 `data` 映射中的每一个键都对应 `mountPath` 下的一个文件名。 - -这是一个在 Pod 中使用存放在挂载卷中 Secret 的例子： - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: mypod -spec: - containers: - - name: mypod - image: redis - volumeMounts: - - name: foo - mountPath: "/etc/foo" - readOnly: true - volumes: - - name: foo - secret: - secretName: mysecret -``` - - -您想要用的每个 Secret 都需要在 `spec.volumes` 中引用。 - -如果 Pod 中有多个容器，每个容器都需要自己的 `volumeMounts` 配置块， -但是每个 Secret 只需要一个 `spec.volumes`。 - -您可以打包多个文件到一个 Secret 中，或者使用的多个 Secret，怎样方便就怎样来。 - -#### 将 Secret 键名映射到特定路径 - -我们还可以控制 Secret 键名在存储卷中映射的的路径。 -你可以使用 `spec.volumes[].secret.items` 字段修改每个键对应的目标路径： - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: mypod -spec: - containers: - - name: mypod - image: redis - volumeMounts: - - name: foo - mountPath: "/etc/foo" - readOnly: true - volumes: - - name: foo - secret: - secretName: mysecret - items: - - key: username - path: my-group/my-username -``` - - -将会发生什么呢： - -- `username` Secret 存储在 `/etc/foo/my-group/my-username` 文件中而不是 `/etc/foo/username` 中。 -- `password` Secret 没有被映射 - -如果使用了 `spec.volumes[].secret.items`，只有在 `items` 中指定的键会被映射。 -要使用 Secret 中所有键，就必须将它们都列在 `items` 字段中。 -所有列出的键名必须存在于相应的 Secret 中。否则，不会创建卷。 - -#### Secret 文件权限 - -你还可以指定 Secret 将拥有的权限模式位。如果不指定，默认使用 `0644`。 -你可以为整个 Secret 卷指定默认模式；如果需要，可以为每个密钥设定重载值。 - -例如，您可以指定如下默认模式： - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: mypod -spec: - containers: - - name: mypod - image: redis - volumeMounts: - - name: foo - mountPath: "/etc/foo" - volumes: - - name: foo - secret: - secretName: mysecret - defaultMode: 256 -``` - - -之后，Secret 将被挂载到 `/etc/foo` 目录，而所有通过该 Secret 卷挂载 -所创建的文件的权限都是 `0400`。 - -请注意，JSON 规范不支持八进制符号，因此使用 256 值作为 0400 权限。 -如果你使用 YAML 而不是 JSON，则可以使用八进制符号以更自然的方式指定权限。 - - -注意，如果你通过 `kubectl exec` 进入到 Pod 中，你需要沿着符号链接来找到 -所期望的文件模式。例如，下面命令检查 Secret 文件的访问模式： - -```shell -kubectl exec mypod -it sh - -cd /etc/foo -ls -l -``` - - -输出类似于： - -``` -total 0 -lrwxrwxrwx 1 root root 15 May 18 00:18 password -> ..data/password -lrwxrwxrwx 1 root root 15 May 18 00:18 username -> ..data/username -``` - - -沿着符号链接，可以查看文件的访问模式： - -```shell -cd /etc/foo/..data -ls -l -``` - - -输出类似于： - -``` -total 8 --r-------- 1 root root 12 May 18 00:18 password --r-------- 1 root root 5 May 18 00:18 username -``` - - - -你还可以使用映射，如上一个示例，并为不同的文件指定不同的权限，如下所示： - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: mypod -spec: - containers: - - name: mypod - image: redis - volumeMounts: - - name: foo - mountPath: "/etc/foo" - volumes: - - name: foo - secret: - secretName: mysecret - items: - - key: username - path: my-group/my-username - mode: 511 -``` - - -在这里，位于 `/etc/foo/my-group/my-username` 的文件的权限值为 `0777`。 -由于 JSON 限制，必须以十进制格式指定模式，即 `511`。 - -请注意，如果稍后读取此权限值，可能会以十进制格式显示。 - -#### 使用来自卷中的 Secret 值 {#consuming-secret-values-from-volumes} - -在挂载了 Secret 卷的容器内，Secret 键名显示为文件名，并且 Secret 的值 -使用 base-64 解码后存储在这些文件中。 -这是在上面的示例容器内执行的命令的结果： - -```shell -ls /etc/foo/ -``` - - -输出类似于： - -``` -username -password -``` - -```shell -cat /etc/foo/username -``` - - -输出类似于： - -``` -admin -``` - -```shell -cat /etc/foo/password -``` - - -输出类似于： - -``` -1f2d1e2e67df -``` - - -容器中的程序负责从文件中读取 secret。 - - -#### 挂载的 Secret 会被自动更新 - -当已经存储于卷中被使用的 Secret 被更新时，被映射的键也将终将被更新。 -组件 kubelet 在周期性同步时检查被挂载的 Secret 是不是最新的。 -但是，它会使用其本地缓存的数值作为 Secret 的当前值。 - -缓存的类型可以使用 [KubeletConfiguration 结构](/zh/docs/reference/config-api/kubelet-config.v1beta1/) -中的 `ConfigMapAndSecretChangeDetectionStrategy` 字段来配置。 -它可以通过 watch 操作来传播（默认），基于 TTL 来刷新，也可以 -将所有请求直接重定向到 API 服务器。 -因此，从 Secret 被更新到将新 Secret 被投射到 Pod 的那一刻的总延迟可能与 -kubelet 同步周期 + 缓存传播延迟一样长，其中缓存传播延迟取决于所选的缓存类型。 -对应于不同的缓存类型，该延迟或者等于 watch 传播延迟，或者等于缓存的 TTL， -或者为 0。 - - -{{< note >}} -使用 Secret 作为[子路径](/zh/docs/concepts/storage/volumes#using-subpath)卷挂载的容器 -不会收到 Secret 更新。 -{{< /note >}} - - -#### 以环境变量的形式使用 Secrets {#using-secrets-as-environment-variables} - -将 Secret 作为 Pod 中的{{< glossary_tooltip text="环境变量" term_id="container-env-variables" >}}使用： - -1. 创建一个 Secret 或者使用一个已存在的 Secret。多个 Pod 可以引用同一个 Secret。 -1. 修改 Pod 定义，为每个要使用 Secret 的容器添加对应 Secret 键的环境变量。 - 使用 Secret 键的环境变量应在 `env[x].valueFrom.secretKeyRef` 中指定 - 要包含的 Secret 名称和键名。 -1. 更改镜像并／或者命令行，以便程序在指定的环境变量中查找值。 - -这是一个使用来自环境变量中的 Secret 值的 Pod 示例： - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: secret-env-pod -spec: - containers: - - name: mycontainer - image: redis - env: - - name: SECRET_USERNAME - valueFrom: - secretKeyRef: - name: mysecret - key: username - - name: SECRET_PASSWORD - valueFrom: - secretKeyRef: - name: mysecret - key: password - restartPolicy: Never -``` - - -#### 使用来自环境变量的 Secret 值 {#consuming-secret-values-from-environment-variables} - -在一个以环境变量形式使用 Secret 的容器中，Secret 键表现为常规的环境变量，其中 -包含 Secret 数据的 base-64 解码值。这是从上面的示例在容器内执行的命令的结果： - -```shell -echo $SECRET_USERNAME -``` - - -输出类似于： - -``` -admin -``` - -```shell -echo $SECRET_PASSWORD -``` - - -输出类似于： - -``` -1f2d1e2e67df -``` - - -#### Secret 更新之后对应的环境变量不会被更新 - -如果某个容器已经在通过环境变量使用某 Secret，对该 Secret 的更新不会被 -容器马上看见，除非容器被重启。有一些第三方的解决方案能够在 Secret 发生 -变化时触发容器重启。 - @@ -1225,33 +1970,30 @@ There are third party solutions for triggering restarts when secrets change. {{< feature-state for_k8s_version="v1.21" state="stable" >}} -Kubernetes 的特性 _不可变的 Secret 和 ConfigMap_ 提供了一种可选配置， -可以设置各个 Secret 和 ConfigMap 为不可变的。 -对于大量使用 Secret 的集群（至少有成千上万各不相同的 Secret 供 Pod 挂载）， -禁止变更它们的数据有下列好处： +Kubernetes 允许你将特定的 Secret（和 ConfigMap）标记为 **不可更改（Immutable）**。 +禁止更改现有 Secret 的数据有下列好处： - 防止意外（或非预期的）更新导致应用程序中断 -- 通过将 Secret 标记为不可变来关闭 kube-apiserver 对其的监视，从而显著降低 - kube-apiserver 的负载，提升集群性能。 +- （对于大量使用 Secret 的集群而言，至少数万个不同的 Secret 供 Pod 挂载）， + 通过将 Secret 标记为不可变，可以极大降低 kube-apiserver 的负载，提升集群性能。 + kubelet 不需要监视那些被标记为不可更改的 Secret。 -这个特性通过 `ImmutableEmphemeralVolumes` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) -来控制，从 v1.19 开始默认启用。 +### 将 Secret 标记为不可更改 {#secret-immutable-create} + 你可以通过将 Secret 的 `immutable` 字段设置为 `true` 创建不可更改的 Secret。 例如： @@ -1265,6 +2007,11 @@ data: immutable: true ``` + +你也可以更改现有的 Secret，令其不可更改。 + {{< note >}} -一旦一个 Secret 或 ConfigMap 被标记为不可更改，撤销此操作或者更改 `data` 字段的内容都是 _不_ 可能的。 -只能删除并重新创建这个 Secret。现有的 Pod 将维持对已删除 Secret 的挂载点 - 建议重新创建这些 Pod。 +一旦一个 Secret 或 ConfigMap 被标记为不可更改，撤销此操作或者更改 `data` +字段的内容都是 **不** 可能的。 +只能删除并重新创建这个 Secret。现有的 Pod 将维持对已删除 Secret 的挂载点 -- +建议重新创建这些 Pod。 {{< /note >}} -#### 使用 imagePullSecret {#using-imagepullsecrets} +## Secret 的信息安全问题 -`imagePullSecrets` 字段中包含一个列表，列举对同一名字空间中的 Secret 的引用。 -你可以使用 `imagePullSecrets` 将包含 Docker（或其他）镜像仓库密码的 Secret 传递给 -kubelet。kubelet 使用此信息来替你的 Pod 拉取私有镜像。 -关于 `imagePullSecrets` 字段的更多信息，请参考 -[PodSpec API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 文档。 - -#### 手动指定 imagePullSecret - -你可以阅读[容器镜像文档](/zh/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) -以了解如何设置 `imagePullSecrets`。 - - -#### 设置自动附加 imagePullSecrets - -您可以手动创建 `imagePullSecret`，并在 ServiceAccount 中引用它。 -使用该 ServiceAccount 创建的任何 Pod 和默认使用该 ServiceAccount 的 -Pod 将会将其的 imagePullSecret 字段设置为服务帐户的 imagePullSecret 值。 -有关该过程的详细说明，请参阅 -[将 ImagePullSecrets 添加到服务帐户](/zh/docs/tasks/configure-pod-container/configure-service-account/#adding-imagepullsecrets-to-a-service-account)。 - - - -## 详细说明 {#details} - -### 限制 {#restrictions} - -Kubernetes 会验证 Secret 作为卷来源时所给的对象引用确实指向一个类型为 -Secret 的对象。因此，Secret 需要先于任何依赖于它的 Pod 创建。 - -Secret API 对象处于某{{< glossary_tooltip text="名字空间" term_id="namespace" >}} -中。它们只能由同一命名空间中的 Pod 引用。 - - -每个 Secret 的大小限制为 1MB。这是为了防止创建非常大的 Secret 导致 API 服务器 -和 kubelet 的内存耗尽。然而，创建过多较小的 Secret 也可能耗尽内存。 -更全面得限制 Secret 内存用量的功能还在计划中。 - -kubelet 仅支持从 API 服务器获得的 Pod 使用 Secret。 -这包括使用 `kubectl` 创建的所有 Pod，以及间接通过副本控制器创建的 Pod。 -它不包括通过 kubelet `--manifest-url` 标志，`--config` 标志或其 REST API -创建的 Pod（这些不是创建 Pod 的常用方法）。 -{{}} -的 `spec` 不能引用 Secret 或任何其他 API 对象。 - - -以环境变量形式在 Pod 中使用 Secret 之前必须先创建 -Secret，除非该环境变量被标记为可选的。 -Pod 中引用不存在的 Secret 时将无法启动。 - -使用 `secretKeyRef` 时，如果引用了指定 Secret 不存在的键，对应的 Pod 也无法启动。 - -对于通过 `envFrom` 填充环境变量的 Secret，如果 Secret 中包含的键名无法作为 -合法的环境变量名称，对应的键会被跳过，该 Pod 将被允许启动。 -不过这时会产生一个事件，其原因为 `InvalidVariableNames`，其消息中包含被跳过的无效键的列表。 -下面的示例显示一个 Pod，它引用了包含 2 个无效键 1badkey 和 2alsobad。 - -```shell -kubectl get events -``` - - -输出类似于： - -``` -LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON -0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames kubelet, 127.0.0.1 Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names. -``` - - -### Secret 与 Pod 生命周期的关系 - -通过 API 创建 Pod 时，不会检查引用的 Secret 是否存在。一旦 Pod 被调度，kubelet -就会尝试获取该 Secret 的值。如果获取不到该 Secret，或者暂时无法与 API 服务器建立连接， -kubelet 将会定期重试。kubelet 将会报告关于 Pod 的事件，并解释它无法启动的原因。 -一旦获取到 Secret，kubelet 将创建并挂载一个包含它的卷。在 Pod 的所有卷被挂载之前， -Pod 中的容器不会启动。 - - -## 使用案例 - - -### 案例：以环境变量的形式使用 Secret - - -创建一个 Secret 定义： - -```yaml -apiVersion: v1 -kind: Secret -metadata: - name: mysecret -type: Opaque -data: - USER_NAME: YWRtaW4= - PASSWORD: MWYyZDFlMmU2N2Rm -``` - - -生成 Secret 对象： - -```shell -kubectl apply -f mysecret.yaml -``` - - -使用 `envFrom` 将 Secret 的所有数据定义为容器的环境变量。 -Secret 中的键名称为 Pod 中的环境变量名称： - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: secret-test-pod -spec: - containers: - - name: test-container - image: k8s.gcr.io/busybox - command: [ "/bin/sh", "-c", "env" ] - envFrom: - - secretRef: - name: mysecret - restartPolicy: Never -``` - - -### 案例：包含 SSH 密钥的 Pod - -创建一个包含 SSH 密钥的 Secret： - -```shell -kubectl create secret generic ssh-key-secret \ - --from-file=ssh-privatekey=/path/to/.ssh/id_rsa \ - --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub -``` - - -输出类似于： - -``` -secret "ssh-key-secret" created -``` - - -你也可以创建一个带有包含 SSH 密钥的 `secretGenerator` 字段的 -`kustomization.yaml` 文件。 - - -{{< caution >}} -发送自己的 SSH 密钥之前要仔细思考：集群的其他用户可能有权访问该密钥。 -你可以使用一个服务帐户，分享给 Kubernetes 集群中合适的用户，这些用户是你要分享的。 -如果服务账号遭到侵犯，可以将其收回。 -{{< /caution >}} - - -现在我们可以创建一个 Pod，令其引用包含 SSH 密钥的 Secret，并通过存储卷来使用它： - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: secret-test-pod - labels: - name: secret-test -spec: - volumes: - - name: secret-volume - secret: - secretName: ssh-key-secret - containers: - - name: ssh-test-container - image: mySshImage - volumeMounts: - - name: secret-volume - readOnly: true - mountPath: "/etc/secret-volume" -``` - - -容器中的命令运行时，密钥的片段可以在以下目录找到： - -``` -/etc/secret-volume/ssh-publickey -/etc/secret-volume/ssh-privatekey -``` - - -然后容器可以自由使用 Secret 数据建立一个 SSH 连接。 - - -### 案例：包含生产/测试凭据的 Pod - -下面的例子展示的是两个 Pod。 -一个 Pod 使用包含生产环境凭据的 Secret，另一个 Pod 使用包含测试环境凭据的 Secret。 - -你可以创建一个带有 `secretGenerator` 字段的 `kustomization.yaml` -文件，或者执行 `kubectl create secret`： - -```shell -kubectl create secret generic prod-db-secret \ - --from-literal=username=produser \ - --from-literal=password=Y4nys7f11 -``` - - -输出类似于： - -``` -secret "prod-db-secret" created -``` - -```shell -kubectl create secret generic test-db-secret \ - --from-literal=username=testuser \ - --from-literal=password=iluvtests -``` - - -输出类似于： - -``` -secret "test-db-secret" created -``` - - -{{< note >}} -特殊字符（例如 `$`、`\`、`*`、`=` 和 `!`）会被你的 -[Shell](https://en.wikipedia.org/wiki/Shell_(computing))解释，因此需要转义。 -在大多数 Shell 中，对密码进行转义的最简单方式是用单引号（`'`）将其括起来。 -例如，如果您的实际密码是 `S!B\*d$zDsb`，则应通过以下方式执行命令： - -```shell -kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb=' -``` - -您无需对文件中的密码（`--from-file`）中的特殊字符进行转义。 -{{< /note >}} - - -创建 pod ： - -```shell -$ cat < pod.yaml -apiVersion: v1 -kind: List -items: -- kind: Pod - apiVersion: v1 - metadata: - name: prod-db-client-pod - labels: - name: prod-db-client - spec: - volumes: - - name: secret-volume - secret: - secretName: prod-db-secret - containers: - - name: db-client-container - image: myClientImage - volumeMounts: - - name: secret-volume - readOnly: true - mountPath: "/etc/secret-volume" -- kind: Pod - apiVersion: v1 - metadata: - name: test-db-client-pod - labels: - name: test-db-client - spec: - volumes: - - name: secret-volume - secret: - secretName: test-db-secret - containers: - - name: db-client-container - image: myClientImage - volumeMounts: - - name: secret-volume - readOnly: true - mountPath: "/etc/secret-volume" -EOF -``` - - -将 Pod 添加到同一个 kustomization.yaml 文件 - -```shell -$ cat <> kustomization.yaml -resources: -- pod.yaml -EOF -``` - - -通过下面的命令应用所有对象 - -```shell -kubectl apply -k . -``` - - -两个容器都会在其文件系统上存在以下文件，其中包含容器对应的环境的值： - -``` -/etc/secret-volume/username -/etc/secret-volume/password -``` - - -请注意，两个 Pod 的规约配置中仅有一个字段不同；这有助于使用共同的 Pod 配置模板创建 -具有不同能力的 Pod。 - -您可以使用两个服务账号进一步简化基本的 Pod 规约： - -1. 名为 `prod-user` 的服务账号拥有 `prod-db-secret` -1. 名为 `test-user` 的服务账号拥有 `test-db-secret` - -然后，Pod 规约可以缩短为： - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: prod-db-client-pod - labels: - name: prod-db-client -spec: - serviceAccount: prod-db-client - containers: - - name: db-client-container - image: myClientImage -``` - - -### 案例：Secret 卷中以句点号开头的文件 - -你可以通过定义以句点开头的键名，将数据“隐藏”起来。 -例如，当如下 Secret 被挂载到 `secret-volume` 卷中： - -```yaml -apiVersion: v1 -kind: Secret -metadata: - name: dotfile-secret -data: - .secret-file: dmFsdWUtMg0KDQo= ---- -apiVersion: v1 -kind: Pod -metadata: - name: secret-dotfiles-pod -spec: - volumes: - - name: secret-volume - secret: - secretName: dotfile-secret - containers: - - name: dotfile-test-container - image: k8s.gcr.io/busybox - command: - - ls - - "-l" - - "/etc/secret-volume" - volumeMounts: - - name: secret-volume - readOnly: true - mountPath: "/etc/secret-volume" -``` - - - -卷中将包含唯一的叫做 `.secret-file` 的文件。 -容器 `dotfile-test-container` 中，该文件处于 `/etc/secret-volume/.secret-file` 路径下。 - - -{{< note >}} -以点号开头的文件在 `ls -l` 的输出中会被隐藏起来； -列出目录内容时，必须使用 `ls -la` 才能看到它们。 -{{< /note >}} - - -### 案例：Secret 仅对 Pod 中的一个容器可见 {#secret-visible-to-only-one-container} -考虑一个需要处理 HTTP 请求、执行一些复杂的业务逻辑，然后使用 HMAC 签署一些消息的应用。 -因为应用程序逻辑复杂，服务器中可能会存在一个未被注意的远程文件读取漏洞， -可能会将私钥暴露给攻击者。 - - -解决的办法可以是将应用分为两个进程，分别运行在两个容器中： -前端容器，用于处理用户交互和业务逻辑，但无法看到私钥； -签名容器，可以看到私钥，响应来自前端（例如通过本地主机网络）的简单签名请求。 - -使用这种分割方法，攻击者现在必须欺骗应用程序服务器才能进行任意的操作， -这可能比使其读取文件更难。 - - - - -## 最佳实践 {#best-practices} - -### 客户端使用 Secret API - -当部署与 Secret API 交互的应用程序时，应使用 -[鉴权策略](/zh/docs/reference/access-authn-authz/authorization/)， -例如 [RBAC](/zh/docs/reference/access-authn-authz/rbac/)，来限制访问。 +尽管 ConfigMap 和 Secret 的工作方式类似，但 Kubernetes 对 Secret 有一些额外的保护。 - -Secret 中的值对于不同的环境来说重要性可能不同。 -很多 Secret 都可能导致 Kubernetes 集群内部的权限越界（例如服务账号令牌） -甚至逃逸到集群外部。 -即使某一个应用程序可以就所交互的 Secret 的能力作出正确抉择，但是同一命名空间中 -的其他应用程序却可能不这样做。 - -由于这些原因，在命名空间中 `watch` 和 `list` Secret 的请求是非常强大的能力， -是应该避免的行为。列出 Secret 的操作可以让客户端检查该命名空间中存在的所有 Secret。 -在群集中 `watch` 和 `list` 所有 Secret 的能力应该只保留给特权最高的系统级组件。 +Secret 通常保存重要性各异的数值，其中很多都可能会导致 Kubernetes 中 +（例如，服务账号令牌）或对外部系统的特权提升。 +即使某些个别应用能够推导它期望使用的 Secret 的能力， +同一名字空间中的其他应用可能会让这种假定不成立。 -需要访问 Secret API 的应用程序应该针对所需要的 Secret 执行 `get` 请求。 -这样，管理员就能限制对所有 Secret 的访问，同时为应用所需要的 -[实例设置访问允许清单](/zh/docs/reference/access-authn-authz/rbac/#referring-to-resources) 。 - -为了获得高于轮询操作的性能，客户端设计资源时，可以引用 Secret，然后对资源执行 `watch` -操作，在引用更改时重新检索 Secret。 -此外，社区还存在一种 [“批量监控” API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/bulk_watch.md) -的提案，允许客户端 `watch` 独立的资源，该功能可能会在将来的 Kubernetes 版本中提供。 +只有当某个节点上的 Pod 需要某 Secret 时，对应的 Secret 才会被发送到该节点上。 +如果将 Secret 挂载到 Pod 中，kubelet 会将数据的副本保存在在 `tmpfs` 中， +这样机密的数据不会被写入到持久性存储中。 +一旦依赖于该 Secret 的 Pod 被删除，kubelet 会删除来自于该 Secret 的机密数据的本地副本。 -## 安全属性 {#security-properties} - -### 保护 {#protections} - -因为 Secret 对象可以独立于使用它们的 Pod 而创建，所以在创建、查看和编辑 Pod 的流程中 -Secret 被暴露的风险较小。系统还可以对 Secret 对象采取额外的预防性保护措施， -例如，在可能的情况下避免将其写到磁盘。 +同一个 Pod 中可能包含多个容器。默认情况下，你所定义的容器只能访问默认 ServiceAccount +及其相关 Secret。你必须显式地定义环境变量或者将卷映射到容器中，才能为容器提供对其他 +Secret 的访问。 -只有当某节点上的 Pod 需要用到某 Secret 时，该 Secret 才会被发送到该节点上。 -Secret 不会被写入磁盘，而是被 kubelet 存储在 tmpfs 中。 -一旦依赖于它的 Pod 被删除，Secret 数据的本地副本就被删除。 +针对同一节点上的多个 Pod 可能有多个 Secret。不过，只有某个 Pod 所请求的 Secret +才有可能对 Pod 中的容器可见。因此，一个 Pod 不会获得访问其他 Pod 的 Secret 的权限。 -同一节点上的很多个 Pod 可能拥有多个 Secret。 -但是，只有 Pod 所请求的 Secret 在其容器中才是可见的。 -因此，一个 Pod 不能访问另一个 Pod 的 Secret。 +{{< warning >}} + +节点上的所有特权容器都可能访问到该节点上使用的所有 Secret。 +{{< /warning >}} -同一个 Pod 中可能有多个容器。但是，Pod 中的每个容器必须通过 `volumeeMounts` -请求挂载 Secret 卷才能使卷中的 Secret 对容器可见。 -这一实现可以用于在 Pod 级别[构建安全分区](#secret-visible-to-only-one-container)。 +### 针对开发人员的安全性建议 -在大多数 Kubernetes 发行版中，用户与 API 服务器之间的通信以及 -从 API 服务器到 kubelet 的通信都受到 SSL/TLS 的保护。 -通过这些通道传输时，Secret 受到保护。 - -{{< feature-state for_k8s_version="v1.13" state="beta" >}} +- 应用在从环境变量或卷中读取了机密信息内容之后仍要对其进行保护。例如， + 你的应用应该避免用明文的方式将 Secret 数据写入日志，或者将其传递给不可信的第三方。 +- 如果你在一个 Pod 中定义了多个容器，而只有一个容器需要访问某 Secret， + 定义卷挂载或环境变量配置时，应确保其他容器无法访问该 Secret。 + +- 如果你通过{{< glossary_tooltip text="清单" term_id="manifest" >}}来配置某 Secret， + Secret 数据以 Base64 的形式编码，将此文件共享，或者将其检入到某源码仓库， + 都意味着 Secret 对于任何可以读取清单的人都是可见的。 + Base64 编码 **不是** 一种加密方法，与明文相比没有任何安全性提升。 + +- 部署与 Secret API 交互的应用时，你应该使用 [RBAC](/zh/docs/reference/access-authn-authz/rbac/) + 这类[鉴权策略](/zh/docs/reference/access-authn-authz/authorization/)来限制访问。 + +- 在 Kubernetes API 中，名字空间内对 Secret 对象的 `watch` 和 `list` 请求是非常强大的能力。 + 在可能的时候应该避免授予这类访问权限，因为通过列举 Secret， + 客户端能够查看对应名字空间内所有 Secret 的取值。 -你可以为 Secret 数据开启[静态加密](/zh/docs/tasks/administer-cluster/encrypt-data/)， -这样 Secret 数据就不会以明文形式存储到{{< glossary_tooltip term_id="etcd" >}} 中。 +### 针对集群管理员的安全性建议 + +{{< caution >}} + +能够创建使用 Secret 的 Pod 的用户也可以查看该 Secret 的取值。 +即使集群策略不允许某用户直接读取 Secret 对象，这一用户仍然可以通过运行一个 +Pod 来访问 Secret 的内容。 +{{< /caution >}} -### 风险 +- 保留（使用 Kubernetes API）对集群中所有 Secret 对象执行 `watch` 或 `list` 操作的能力， + 这样只有特权级最高、系统级别的组件能够执行这类操作。 +- 在部署需要通过 Secret API 交互的应用时，你应该通过使用 + [RBAC](/zh/docs/reference/access-authn-authz/rbac/) + 这类[鉴权策略](/zh/docs/reference/access-authn-authz/authorization/)来限制访问。 + +- 在 API 服务器上，对象（包括 Secret）会被持久化到 {{< glossary_tooltip term_id="etcd" >}} 中； + 因此： -- API 服务器上的 Secret 数据以纯文本的方式存储在 etcd 中，因此： - - 管理员应该为集群数据开启静态加密（要求 v1.13 或者更高版本）。 - - 管理员应该限制只有 admin 用户能访问 etcd； - - API 服务器中的 Secret 数据位于 etcd 使用的磁盘上；管理员可能希望在不再使用时擦除/粉碎 etcd 使用的磁盘 - - 如果 etcd 运行在集群内，管理员应该确保 etcd 之间的通信使用 SSL/TLS 进行加密。 -- 如果您将 Secret 数据编码为 base64 的清单（JSON 或 YAML）文件，共享该文件或将其检入代码库，该密码将会被泄露。 Base64 编码不是一种加密方式，应该视同纯文本。 -- 应用程序在从卷中读取 Secret 后仍然需要保护 Secret 的值，例如不会意外将其写入日志或发送给不信任方。 -- 可以创建使用 Secret 的 Pod 的用户也可以看到该 Secret 的值。即使 API 服务器策略不允许用户读取 Secret 对象，用户也可以运行 Pod 导致 Secret 暴露。 + - 只应准许集群管理员访问 etcd（包括只读访问）； + - 为 Secret 对象启用[静态加密](/zh/docs/tasks/administer-cluster/encrypt-data/)， + 这样这些 Secret 的数据就不会以明文的形式保存到 + {{< glossary_tooltip term_id="etcd" >}} 中； + - 当 etcd 的持久化存储不再被使用时，请考虑彻底擦除存储介质； + - 如果存在多个 etcd 实例，请确保 etcd 使用 SSL/TLS 来完成其对等通信。 ## {{% heading "whatsnext" %}} From 849eed7d0ad030f6e1958d43d0a09e27178ca951 Mon Sep 17 00:00:00 2001 From: "xin.li" Date: Tue, 29 Mar 2022 11:21:58 +0800 Subject: [PATCH 29/32] [zh] Update optional-kubectl-configs-zsh.md Signed-off-by: xin.li --- .../tools/included/optional-kubectl-configs-zsh.md | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/content/zh/docs/tasks/tools/included/optional-kubectl-configs-zsh.md b/content/zh/docs/tasks/tools/included/optional-kubectl-configs-zsh.md index b439db63bc..9a40a829aa 100644 --- a/content/zh/docs/tasks/tools/included/optional-kubectl-configs-zsh.md +++ b/content/zh/docs/tasks/tools/included/optional-kubectl-configs-zsh.md @@ -26,24 +26,19 @@ source <(kubectl completion zsh) ``` -如果你为 kubectl 定义了别名，可以扩展脚本补全，以兼容该别名。 - -```zsh -echo 'alias k=kubectl' >>~/.zshrc -echo 'compdef __start_kubectl k' >>~/.zshrc -``` +如果你为 kubectl 定义了别名，kubectl 自动补全将自动使用它。 重新加载 shell 后，kubectl 自动补全功能将立即生效。 -如果你收到 `complete:13: command not found: compdef` 这样的错误提示，那请将下面内容添加到 `~/.zshrc` 文件的开头： - +如果你收到 `2: command not found: compdef` 这样的错误提示，那请将下面内容添加到 `~/.zshrc` 文件的开头： ```zsh autoload -Uz compinit compinit From 047966418e7928b23b8ee36f13e87e08ae41c8f2 Mon Sep 17 00:00:00 2001 From: "xin.li" Date: Tue, 29 Mar 2022 11:51:15 +0800 Subject: [PATCH 30/32] [zh] update create-cluster_index.md Signed-off-by: xin.li --- .../tutorials/kubernetes-basics/create-cluster/_index.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/content/zh/docs/tutorials/kubernetes-basics/create-cluster/_index.md b/content/zh/docs/tutorials/kubernetes-basics/create-cluster/_index.md index a3e250856e..59dc1385c7 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/create-cluster/_index.md +++ b/content/zh/docs/tutorials/kubernetes-basics/create-cluster/_index.md @@ -2,3 +2,9 @@ title: 创建集群 weight: 10 --- + + +了解 Kubernetes {{}}并使用 Minikube +创建一个简单的集群。 From 62c4ddc8f68ea22816f07c7505d6f30017d793cb Mon Sep 17 00:00:00 2001 From: "xin.li" Date: Tue, 29 Mar 2022 15:35:59 +0800 Subject: [PATCH 31/32] [zh]Update cluster-intro.md Signed-off-by: xin.li --- .../kubernetes-basics/create-cluster/cluster-intro.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html index d6a0d4a9ec..eb1d9eb7ca 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html +++ b/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html @@ -72,7 +72,7 @@ weight: 10

Master 负责管理整个集群。 Master 协调集群中的所有活动，例如调度应用、维护应用的所需状态、应用扩容以及推出新的更新。

-

Node 是一个虚拟机或者物理机，它在 Kubernetes 集群中充当工作机器的角色 每个Node都有 Kubelet , 它管理 Node 而且是 Node 与 Master 通信的代理。 Node 还应该具有用于​​处理容器操作的工具，例如 Docker 或 rkt 。处理生产级流量的 Kubernetes 集群至少应具有三个 Node 。

+

Node 是一个虚拟机或者物理机，它在 Kubernetes 集群中充当工作机器的角色 每个Node都有 Kubelet , 它管理 Node 而且是 Node 与 Master 通信的代理。 Node 还应该具有用于​​处理容器操作的工具，例如 Docker 或 rkt 。处理生产级流量的 Kubernetes 集群至少应具有三个 Node，因为如果一个 Node 出现故障其对应的 etcd 成员和控制平面实例都会丢失，并且冗余会受到影响。 你可以通过添加更多控制平面节点来降低这种风险 。

From 200f5f5e4c8e8c78371777fefcbe4a38228b3b2d Mon Sep 17 00:00:00 2001 From: "xin.li" Date: Tue, 29 Mar 2022 17:52:33 +0800 Subject: [PATCH 32/32] [zh] Update cluster-level-pass.md Signed-off-by: xin.li --- .../zh/docs/tutorials/security/cluster-level-pss.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/zh/docs/tutorials/security/cluster-level-pss.md b/content/zh/docs/tutorials/security/cluster-level-pss.md index 0b4721c43b..714bbca1f7 100644 --- a/content/zh/docs/tutorials/security/cluster-level-pss.md +++ b/content/zh/docs/tutorials/security/cluster-level-pss.md @@ -19,7 +19,7 @@ Pod Security admission (PSA) is enabled by default in v1.23 and later, as it has [graduated to beta](/blog/2021/12/09/pod-security-admission-beta/). Pod Security is an admission controller that carries out checks against the Kubernetes -[Pod Security Standards](docs/concepts/security/pod-security-standards/) when new pods are +[Pod Security Standards](/docs/concepts/security/pod-security-standards/) when new pods are created. This tutorial shows you how to enforce the `baseline` Pod Security Standard at the cluster level which applies a standard configuration to all namespaces in a cluster. @@ -406,14 +406,14 @@ following: ## 清理 {#clean-up} -运行 `kind delete cluster -name psa-with-cluster-pss` 和 -`kind delete cluster -name psa-wo-cluster-pss` 来删除你创建的集群。 +运行 `kind delete cluster --name psa-with-cluster-pss` 和 +`kind delete cluster --name psa-wo-cluster-pss` 来删除你创建的集群。 ## {{% heading "whatsnext" %}}