From 7e546c83bee0ae0ef421a2262c2321f42b9cbe6a Mon Sep 17 00:00:00 2001 From: Vedant Koditkar Date: Tue, 15 Feb 2022 12:16:40 +0530 Subject: [PATCH 001/209] Update hyperlinks to point to main branch --- content/fr/docs/contribute/localization.md | 4 +--- content/fr/docs/contribute/participating.md | 10 ++++------ 2 files changed, 5 insertions(+), 9 deletions(-) diff --git a/content/fr/docs/contribute/localization.md b/content/fr/docs/contribute/localization.md index 91667afdd2..332aeb4ea4 100644 --- a/content/fr/docs/contribute/localization.md +++ b/content/fr/docs/contribute/localization.md @@ -147,7 +147,7 @@ La dernière version est **{{< latest-version >}}**, donc la branche de la relea ### Chaînes de sites en i18n/ -Les localisations doivent inclure le contenu des éléments suivants [`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml) dans un nouveau fichier spécifique à la langue. +Les localisations doivent inclure le contenu des éléments suivants [`i18n/en.toml`](https://github.com/kubernetes/website/blob/main/i18n/en.toml) dans un nouveau fichier spécifique à la langue. Prenons l'allemand comme exemple : `i18n/de.toml`. Ajouter un nouveau fichier de localisation dans `i18n/`. Par exemple, avec l'allemand (de) : @@ -230,5 +230,3 @@ Une fois qu'une traduction répond aux exigences de logistique et à une couvert - Activer la sélection de la langue sur le site Web - Publier la disponibilité de la traduction via les canaux de la [Cloud Native Computing Foundation](https://www.cncf.io/), y compris sur le blog de [Kubernetes](https://kubernetes.io/blog/). - - diff --git a/content/fr/docs/contribute/participating.md b/content/fr/docs/contribute/participating.md index 0658be231f..4fe2583859 100644 --- a/content/fr/docs/contribute/participating.md +++ b/content/fr/docs/contribute/participating.md @@ -102,7 +102,7 @@ Pour en savoir plus sur comment devenir un relecteur SIG Docs et sur les respons Lorsque vous remplissez les [conditions requises](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), vous pouvez devenir un relecteur SIG Docs. Les relecteurs d'autres SIG doivent demander séparément le statut de relecteur dans le SIG Docs. -Pour postuler, ouvrez une pull request et ajoutez vous à la section `reviewers` du fichier [top-level OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) dans le dépôt `kubernetes/website`. +Pour postuler, ouvrez une pull request et ajoutez vous à la section `reviewers` du fichier [top-level OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) dans le dépôt `kubernetes/website`. Affectez la PR à un ou plusieurs approbateurs SIG Docs. Si votre pull request est approuvée, vous êtes maintenant un relecteur SIG Docs. @@ -130,7 +130,7 @@ Pour en savoir plus sur comment devenir un approbateur SIG Docs et sur les respo Lorsque vous remplissez les [conditions requises](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), vous pouvez devenir un approbateur SIG Docs. Les approbateurs appartenant à d'autres SIG doivent demander séparément le statut d'approbateur dans SIG Docs. -Pour postuler, ouvrez une pull request pour vous ajouter à la section `approvers` du fichier [top-level OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) dans le dépot `kubernetes/website`. +Pour postuler, ouvrez une pull request pour vous ajouter à la section `approvers` du fichier [top-level OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) dans le dépot `kubernetes/website`. Affectez la PR à un ou plusieurs approbateurs SIG Docs. Si votre Pull Request est approuvée, vous êtes à présent approbateur SIG Docs. @@ -184,9 +184,9 @@ Le [dépôt du site web Kubernetes](https://github.com/kubernetes/website) utili - blunderbuss - approve -Ces deux plugins utilisent les fichiers [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) et [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) à la racine du dépôt Github `kubernetes/website` pour contrôler comment prow fonctionne. +Ces deux plugins utilisent les fichiers [OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) et [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) à la racine du dépôt Github `kubernetes/website` pour contrôler comment prow fonctionne. -Un fichier [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) contient une liste de personnes qui sont des relecteurs et des approbateurs SIG Docs. +Un fichier [OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) contient une liste de personnes qui sont des relecteurs et des approbateurs SIG Docs. Les fichiers OWNERS existent aussi dans les sous-dossiers, et peuvent ignorer qui peut agir en tant que relecteur ou approbateur des fichiers de ce sous-répertoire et de ses descendants. Pour plus d'informations sur les fichiers OWNERS en général, voir [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md). @@ -203,5 +203,3 @@ Pour plus d'informations sur la contribution à la documentation Kubernetes, voi - [Commencez à contribuer](/docs/contribute/start/) - [Documentation style](/docs/contribute/style/) - - From 223103bcf09dc9c7cfbb27addc91260803f235b7 Mon Sep 17 00:00:00 2001 From: carolina valencia Date: Thu, 2 Dec 2021 16:16:11 -0300 Subject: [PATCH 002/209] fix: broken link security pod policy --- content/pt-br/docs/concepts/security/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt-br/docs/concepts/security/overview.md b/content/pt-br/docs/concepts/security/overview.md index cfef9135f7..0cbbbf2961 100644 --- a/content/pt-br/docs/concepts/security/overview.md +++ b/content/pt-br/docs/concepts/security/overview.md @@ -103,7 +103,7 @@ vulnerável a um ataque de exaustão de recursos e, por consequência, o risco d Autorização RBAC (acesso à API Kubernetes) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/ Autenticação | https://kubernetes.io/docs/concepts/security/controlling-access/ Gerenciamento de segredos na aplicação (e encriptando-os no etcd em repouso) | https://kubernetes.io/docs/concepts/configuration/secret/
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ -Políticas de segurança do Pod | https://kubernetes.io/docs/concepts/policy/pod-security-policy/ +Garantir que os Pods atendem aos padrões de segurança do Pod | https://kubernetes.io/docs/concepts/security/pod-security-standards/#policy-instantiation Qualidade de serviço (e gerenciamento de recursos de cluster) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/ Políticas de Rede | https://kubernetes.io/docs/concepts/services-networking/network-policies/ TLS para Kubernetes Ingress | https://kubernetes.io/docs/concepts/services-networking/ingress/#tls From 6ce3dd22371ec661005acd09b215a1842c72d3c9 Mon Sep 17 00:00:00 2001 From: Mike Spreitzer Date: Mon, 11 Apr 2022 22:03:12 -0400 Subject: [PATCH 003/209] Update APF metrics again --- .../cluster-administration/flow-control.md | 57 +++++++++++++++++-- 1 file changed, 53 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md index 9e8f2a7923..68419b8231 100644 --- a/content/en/docs/concepts/cluster-administration/flow-control.md +++ b/content/en/docs/concepts/cluster-administration/flow-control.md @@ -471,11 +471,15 @@ poorly-behaved workloads that may be harming system health. requests, broken down by the labels `phase` (which takes on the values `waiting` and `executing`) and `request_kind` (which takes on the values `mutating` and `readOnly`). The observations are made - periodically at a high rate. + periodically at a high rate. Each observed value is a ratio, + between 0 and 1, of a number of requests divided by the + corresponding limit on the number of requests (queue length limit + for waiting and concurrency limit for executing). * `apiserver_flowcontrol_read_vs_write_request_count_watermarks` is a histogram vector of high or low water marks of the number of - requests broken down by the labels `phase` (which takes on the + requests (divided by the corresponding limit to get a ratio in the + range 0 to 1) broken down by the labels `phase` (which takes on the values `waiting` and `executing`) and `request_kind` (which takes on the values `mutating` and `readOnly`); the label `mark` takes on values `high` and `low`. The water marks are accumulated over @@ -502,11 +506,15 @@ poorly-behaved workloads that may be harming system health. values `waiting` and `executing`) and `priority_level`. Each histogram gets observations taken periodically, up through the last activity of the relevant sort. The observations are made at a high - rate. + rate. Each observed value is a ratio, between 0 and 1, of a number + of requests divided by the corresponding limit on the number of + requests (queue length limit for waiting and concurrency limit for + executing). * `apiserver_flowcontrol_priority_level_request_count_watermarks` is a histogram vector of high or low water marks of the number of - requests broken down by the labels `phase` (which takes on the + requests (divided by the corresponding limit to get a ratio in the + range 0 to 1) broken down by the labels `phase` (which takes on the values `waiting` and `executing`) and `priority_level`; the label `mark` takes on values `high` and `low`. The water marks are accumulated over windows bounded by the times when an observation @@ -514,6 +522,31 @@ poorly-behaved workloads that may be harming system health. `apiserver_flowcontrol_priority_level_request_count_samples`. These water marks show the range of values that occurred between samples. +* `apiserver_flowcontrol_priority_level_seat_count_samples` is a + histogram vector of observations of the utilization of a priority + level's concurrency limit, broken down by `priority_level`. This + utilization is the fraction (number of seats occupied) / + (concurrency limit). This metric considers all stages of execution + (both normal and the extra delay at the end of a write to cover for + the corresponding notification work) of all requests except WATCHes; + for those it considers only the initial stage that delivers + notifications of pre-existing objects. Each histogram in the vector + is also labeled with `phase: executing` (there is no seat limit for + the waiting phase). Each histogram gets observations taken + periodically, up through the last activity of the relevant sort. + The observations + are made at a high rate. + +* `apiserver_flowcontrol_priority_level_seat_count_watermarks` is a + histogram vector of high or low water marks of the utilization of a + priority level's concurrency limit, broken down by `priority_level` + and `mark` (which takes on values `high` and `low`). Each histogram + in the vector is also labeled with `phase: executing` (there is no + seat limit for the waiting phase). The water marks are accumulated + over windows bounded by the times when an observation was added to + `apiserver_flowcontrol_priority_level_seat_count_samples`. These + water marks show the range of values that occurred between samples. + * `apiserver_flowcontrol_request_queue_length_after_enqueue` is a histogram vector of queue lengths for the queues, broken down by the labels `priority_level` and `flow_schema`, as sampled by the @@ -556,6 +589,22 @@ poorly-behaved workloads that may be harming system health. and `priority_level` (indicating the one to which the request was assigned). +* `apiserver_flowcontrol_watch_count_samples` is a histogram vector of + the number of active WATCH requests relevant to a given write, + broken down by `flow_schema` and `priority_level`. + +* `apiserver_flowcontrol_work_estimated_seats` is a histogram vector + of the number of estimated seats (maximum of initial and final stage + of execution) associated with requests, broken down by `flow_schema` + and `priority_level`. + +* `apiserver_flowcontrol_request_dispatch_no_accommodation_total` is a + counter vec of the number of events that in principle could have led + to a request being dispatched but did not, due to lack of available + concurrency, broken down by `flow_schema` and `priority_level`. The + relevant sorts of events are arrival of a request and completion of + a request. + ### Debug endpoints When you enable the API Priority and Fairness feature, the `kube-apiserver` From aec5647e90c712b474b8f3a89a1775b33203e43d Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" Date: Sat, 23 Apr 2022 12:28:05 -0300 Subject: [PATCH 004/209] Add pt-br/docs/reference/glossary/cluster-infrastructure.md --- .../reference/glossary/cluster-infrastructure.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 content/pt-br/docs/reference/glossary/cluster-infrastructure.md diff --git a/content/pt-br/docs/reference/glossary/cluster-infrastructure.md b/content/pt-br/docs/reference/glossary/cluster-infrastructure.md new file mode 100644 index 0000000000..44a6e9f156 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/cluster-infrastructure.md @@ -0,0 +1,13 @@ +--- +title: infraestrutura de Cluster +id: cluster-infrastructure +date: 2019-05-12 +full_link: +short_description: > + A camada de infraestrutura fornece e mantém máquinas virtuais, redes, grupos de segurança e outros. + +aka: +tags: +- operation +--- + A camada de infraestrutura fornece e mantém máquinas virtuais, redes, grupos de segurança e outros. From 85f076192eb188458a993bbb431c173d19e338d4 Mon Sep 17 00:00:00 2001 From: xing-yang Date: Wed, 25 May 2022 01:30:17 +0000 Subject: [PATCH 005/209] Add doc for CRD version removal --- .../custom-resource-definition-versioning.md | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md index fdcc276a45..28757ffd84 100644 --- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md @@ -353,6 +353,36 @@ spec: {{< /tabs >}} +### Version removal + +An API version can be removed if there is a newer API version served and stored in the API server for at least 3 Kubernetes releases. +The older API version cannot be dropped from the CRD manifest until data has been migrated to the newer API version for all clusters that served the older version of the CRD and cleared the older version from status.storedVersions. + +{{< tabs name="CustomResourceDefinition_versioning_removal" >}} +{{% tab name="apiextensions.k8s.io/v1" %}} +```yaml +apiVersion: apiextensions.k8s.io/v1 +kind: CustomResourceDefinition + name: crontabs.example.com +spec: + group: example.com + names: + plural: crontabs + singular: crontab + kind: CronTab + scope: Namespaced + versions: + - name: v1beta1 + served: false + # This indicates the v1beta1 version of the custom resource is no longer served. + # API requests to this version receive a not found error in the server response. + schema: ... + - name: v1 + served: true + storage: true + schema: ... +``` + ## Webhook conversion {{< feature-state state="stable" for_k8s_version="v1.16" >}} From 39afd8538ddb7351c7390e5f796be8d4b2960d1f Mon Sep 17 00:00:00 2001 From: Jim Bugwadia Date: Tue, 24 May 2022 22:27:00 -0700 Subject: [PATCH 006/209] initial draft Signed-off-by: Jim Bugwadia --- .../concepts/security/controlling-access.md | 1 + .../docs/concepts/security/multi-tenancy.md | 235 ++++++++++++++++++ .../concepts/security/rbac-good-practices.md | 1 + .../concepts/security/windows-security.md | 2 +- static/images/docs/multi-tenancy.png | Bin 0 -> 34460 bytes 5 files changed, 238 insertions(+), 1 deletion(-) create mode 100755 content/en/docs/concepts/security/multi-tenancy.md create mode 100755 static/images/docs/multi-tenancy.png diff --git a/content/en/docs/concepts/security/controlling-access.md b/content/en/docs/concepts/security/controlling-access.md index e7ba78e1c4..04b13a82c5 100644 --- a/content/en/docs/concepts/security/controlling-access.md +++ b/content/en/docs/concepts/security/controlling-access.md @@ -4,6 +4,7 @@ reviewers: - lavalamp title: Controlling Access to the Kubernetes API content_type: concept +weight: 50 --- diff --git a/content/en/docs/concepts/security/multi-tenancy.md b/content/en/docs/concepts/security/multi-tenancy.md new file mode 100755 index 0000000000..f26d9d6354 --- /dev/null +++ b/content/en/docs/concepts/security/multi-tenancy.md @@ -0,0 +1,235 @@ +--- +title: Multi-tenancy +content_type: concept +weight: 70 +--- + + + +This page provides an overview of available configuration options and best practices for cluster multi-tenancy. + + + +Sharing clusters saves costs and simplifies administration. However, sharing clusters also presents challenges such as security, fairness, and managing noisy neighbors. + +Clusters can be shared in many ways. In some cases, different applications may run in the same cluster. In other cases, multiple instances of the same application may run in the same cluster, one for each end user. All these types of sharing are frequently described using the umbrella term "multi-tenancy." + +While Kubernetes does not have first-class concepts of end users or tenants, it provides several features to help manage different tenancy requirements. These are discussed below. + +## Use Cases + +The first step to determining how to share your cluster is to understand your own use case, so you can evaluate the patterns and tools available to you. In general, multi-tenancy in Kubernetes clusters falls into two broad categories, though many variations and hybrids are also possible. + +### Multiple teams + +A common form of multi-tenancy is to share a cluster between multiple teams within an organization, each of whom may operate one or more workloads. These workloads frequently need to communicate with each other, and with other workloads located on the same or different clusters. + +In this scenario, members of the teams often have direct access to Kubernetes resources via tools such as `kubectl`, or indirect access through GitOps controllers or other types of release automation tools. There is often some level of trust between members of different teams, but Kubernetes policies such as RBAC, quotas, and network policies are essential to safely and fairly share clusters. + +### Multiple customers + +The other major form of multi-tenancy frequently involves a Software-as-a-Service (SaaS) vendor running multiple instances of a workload for customers. This business model is so strongly associated with this deployment style that many people call it "SaaS tenancy." However, a better term might be "multi-customer tenancy,” since SaaS vendors may also use other deployment models, and this deployment model can also be used outside of SaaS. + +In this scenario, the customers do not have access to the cluster; Kubernetes is invisible from their perspective, and is only used by the vendor themselves to manage the workloads. Cost optimization is frequently a critical concern, and Kubernetes policies are used to ensure that the workloads are strongly isolated from each other. + +## Terminology + +### Tenants + +When discussing multi-tenancy in Kubernetes, there is no single definition for a "tenant". Rather, the definition of a tenant will vary depending on whether we are discussing multi-team or multi-customer tenancy. + +In multi-team usage, a tenant is typically a team, where each team typically deploys a small number of workloads that scales with the complexity of the service. However, the definition of "team" may itself be fuzzy, as teams may be organized into higher-level divisions or subdivided into subteams. + +By contrast, if each team deploys dedicated workloads for each new client, they are using a multi-customer model of tenancy. In this case, a "tenant" is simply a group of users who share a single workload. This may be as large as an entire company, or as small as a single team at that company. + +In many cases, the same organization may use both definitions of "tenants" in different contexts. For example, a platform team may offer shared services such as security tools and databases to multiple internal “customers”. And a SaaS vendor may also have multiple teams sharing a development cluster. Finally, hybrid architectures are also possible, such as a SaaS provider using a combination of per-customer workloads for sensitive data, combined with multi-tenant shared services. + +{{< figure src="/images/docs/multi-tenancy.png" title="A cluster showing coexisting tenancy models" class="diagram-large" >}} + + +### Isolation + +There are several ways to design and build multi-tenant solutions with Kubernetes, each with its own set of tradeoffs that impact the isolation level, implementation effort, operational complexity, and cost of service. + +A Kubernetes cluster consists of a control plane which runs Kubernetes software, and a data plane consisting of worker nodes where tenant workloads are executed as pods. Tenant isolation can be applied in both the control plane and the data plane based on organizational requirements. + +The level of isolation offered is sometimes described using terms like “hard” multi-tenancy, which implies strong isolation, and “soft” multi-tenancy, which implies weaker isolation. In particular, "hard" multi-tenancy is often used to describe cases where the tenants do not trust each other, often from security and resource sharing perspectives (e.g. guarding against attacks such as data exfiltration or DoS). Since data planes typically have much larger attack surfaces, "hard" multi-tenancy often requires extra attention to isolating the data-plane, though control plane isolation also remains critical. + +However, the terms "hard" and "soft" can often be confusing, as there is no single definition that will apply to all users. Rather, "hardness" or "softness" is better understood as a coarse spectrum, with many different techniques that can be used to maintain different types of isolation in your clusters, based on your own requirements. + +In more extreme cases, it may be easier or necessary to forgo any cluster-level sharing at all, and assign each tenant their own dedicated cluster, possibly even running on dedicated hardware if VMs are not considered an adequate security boundary. This may be easier with managed Kubernetes clusters, where the overhead of creating and operating clusters is at least somewhat taken on by a cloud provider. The benefit of stronger tenant isolation must be evaluated against the cost and complexity of managing multiple clusters. The [Multi-cluster SIG](https://github.com/kubernetes/community/blob/master/sig-multicluster/README.md) is responsible for addressing these types of use cases. + +The remainder of this page focuses on isolation techniques used for shared Kubernetes clusters. However, even if you are considering dedicated clusters, it may be valuable to review these recommendations, as it will give you the flexibility to shift to shared clusters in the future if your needs or capabilities change. + + +## Control Plane Isolation + +Control plane isolation ensures that different tenants cannot access or affect each others' Kubernetes API resources. + +### Namespaces + +In Kubernetes, a Namespace provides a mechanism for isolating groups of API resources within a single cluster. This isolation has two key dimensions: + +1. Object names within a namespace can overlap with names in other namespaces, similarly to files in folders. This allows tenants to name their resources without having to consider what other tenants are doing. + +2. Many Kubernetes security policies are scoped to namespaces. For example, RBAC and Network Policies are scoped to namespaces (by default), while objects such as Secrets and Service Accounts may only be accessed from their own namespaces. + +In a multi-tenant environment, a Namespace helps segment a tenant's workload into a logical and distinct management unit. In fact, a common practice is to isolate every workload in its own namespace, even if multiple workloads are operated by the same tenant. This ensures that each workload has its own identity and can be configured with an appropriate security policy. + +The namespace isolation model requires configuration of several other Kubernetes resources, networking plugins, and adherence to security best practices to properly isolate tenant workloads. These considerations are discussed below. + +### Access Controls + +The most important type of isolation for the control plane is authorization. If teams, or their workloads, can access or modify each others' API resources, they can change or disable all other types of policies, negating any protection those policies may offer. As a result, it is critical to ensure that each tenant has the appropriate access to only the namespaces they need, and no more. This is known as the "Principle of Least Privilege." + +Role-based access control (RBAC) is the recommended method to enforce authorization in the Kubernetes control plane, for both human users and workloads (service accounts). [Roles](/docs/reference/access-authn-authz/rbac/#role-and-clusterrole) and [role bindings](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) are Kubernetes objects that are used at a namespace level to enforce access control in your application; similar objects exist for authorizing access to cluster-level objects, though these are less useful for multi-tenant clusters. + +In a multi-team environment, RBAC must be used to restrict tenants' access to the appropriate namespaces, and ensure that cluster-wide resources can only be accessed or modified by privileged users such as cluster administrators. + +If a policy ends up granting a user more permissions than they need, this is likely a signal that the namespace containing the affected resources should be refactored into finer-grained namespaces. Namespace management tools may simplify the management of these finer-grained namespaces by applying common RBAC policies to different namespaces, while still allowing fine-grained policies where necessary. + +### Quotas + +Kubernetes workloads consume node resources, like CPU and memory. In a multi-tenant environment, [Resource Quotas](/docs/concepts/policy/resource-quotas/) are used to manage data-plane resource usage of tenant workloads. For the multiple teams use case, where tenants have access to the Kubernetes API, resource quotas can also be used to limit the number of API resources (e.g. the number of Pods or ConfigMaps) a tenant can create. + +Resource quotas are namespaced objects. By mapping tenants to namespaces, cluster admins can use quotas to ensure that a tenant cannot monopolize a cluster's resources or overwhelm its control plane. Namespace management tools simplify the administration of quotas. In addition, while Kubernetes quotas only apply within a single namespace, some namespace management tools allow groups of namespaces to share quotas, giving administrators far more flexibility with less effort than built-in quotas. + +Quotas prevent a single tenant from consuming greater than their allocated share of resources hence minimizing the “noisy neighbor” issue, where one tenant negatively impacts the performance of other tenants' workloads. + +When you apply a quota to namespace, Kubernetes requires you to also specify resource requests and limits for each container. Limits are the upper bound for the amount of resources that a container can consume. Containers that attempt to consume resources that exceed the configured limits will either be throttled or killed, based on the resource type. When resource requests are set lower than limits, each container is guaranteed the requested amount but there may still be some potential for impact across workloads. + +Quotas cannot protect against all kinds of resource sharing, such as network traffic. Node isolation (described below) may be a better solution for this problem. + +## Data Plane Isolation + +Data plane isolation ensures that pods and workloads for different tenants are sufficiently isolated. + +### Network isolation + +By default, all pods in a Kubernetes cluster are allowed to communicate with each other, and all network traffic is unencrypted. This can lead to security vulnerabilities where traffic is accidentally or maliciously sent to an unintended destination, or is intercepted by a workload on a compromised node. + +Pod-to-pod communication can be controlled using [Network Policies](/docs/concepts/services-networking/network-policies/), which restrict communication between pods using namespace labels or IP address ranges. In a multi-tenant environment where strict network isolation between tenants is required, we recommend starting with a default policy that denies communication between pods, and another rule that allows all pods to query the DNS server for name resolution. With that in place, you can begin adding more permissive rules that allow for communication within a namespace. This can be further refined as required. Note that this only applies to pods within a single control plane; pods that belong to different virtual control planes cannot talk to each other via Kubernetes networking. + +Namespace management tools may simplify the creation of default or common network policies. In addition, some of these tools allow you to enforce a consistent set of namespace labels across your cluster, ensuring that they are a trusted basis for your policies. + +More advanced network isolation may be provided by service meshes, which provide OSI Layer 7 policies based on workload identity, in addition to namespaces. These higher-level policies can make it easier to manage namespaced based multi-tenancy, especially when multiple namespaces are dedicated to a single tenant. They frequently also offer encryption using mutual TLS, protecting your data even in the presence of a compromised node, and work across dedicated or virtual clusters. However, they can be significantly more complex to manage and may not be appropriate for all users. + +### Storage Isolation + +Kubernetes offers several types of volumes that can be used as persistent storage for workloads. For security and data-isolation, [dynamic volume provisioning](/docs/concepts/storage/dynamic-provisioning/) is recommended and volume types that use node resources should be avoided. + +[StorageClasses](/docs/concepts/storage/storage-classes/) allow you to describe custom "classes" of storage offered by your cluster, based on quality-of-service levels, backup policies, or custom policies determined by the cluster administrators. + +Pods can request storage using a [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/). A PersistentVolumeClaim is a namespaced resource, which enables isolating portions of the storage system and dedicating it to tenants within the shared Kubernetes cluster. However, it is important to note that a PersistentVolume is a cluster-wide resource and has a lifecycle independent of workloads and namespaces. + +A StorageClass can be configured per tenant, for stronger isolation. If a StorageClass is shared, a [reclaim policy of “Delete”](/docs/concepts/storage/storage-classes/#reclaim-policy) should be used to ensure that a PersistentVolume cannot be reused across namespaces. + +### Sandboxing + +{{% thirdparty-content %}} + +Kubernetes pods are composed of one or more containers that execute on worker nodes. Containers utilize OS-level virtualization and hence offer a weaker isolation boundary than virtual machines that utilize hardware-based virtualization. + +In a shared environment, unpatched vulnerabilities in the application and system layers can be exploited by attackers for container breakouts and remote code execution that allow access to host resources. In some applications, like a Content Management System (CMS), customers may be allowed the ability to upload and execute untrusted scripts or code. In either case, mechanisms to further isolate and protect workloads using strong isolation are desirable. + +Sandboxing provides a way to isolate workloads running in a shared cluster. It typically involves running each pod in a separate execution environment such as a virtual machine or a userspace kernel. Sandboxing is often recommended when you are running untrusted code, where workloads are assumed to be malicious. Part of the reason this type of isolation is necessary is because containers are processes running on a shared kernel; they mount file systems like /sys and /proc from the underlying host, making them less secure than an application that runs on a virtual machine which has its own kernel. While controls such as seccomp, AppArmor, and SELinux can be used to strengthen the security of containers, it is hard to apply a universal set of rules to all workloads running in a shared cluster. Running workloads in a sandbox environment helps to insulate the host from container escapes, where an attacker exploits a vulnerability to gain access to the host system and all the processes/files running on that host. + +Virtual machines and userspace kernels are 2 popular approaches to sandboxing. [Kata Containers](https://katacontainers.io/) is an OCI compliant runtime that allows you to run containers in a VM. The hardware virtualization available in Kata offers an added layer of security for containers running untrusted code. [gVisor](https://gvisor.dev/) offers similar isolation, but rather than isolating containers with hardware virtualization, it intercepts syscalls from containers and runs them through a userspace kernel, written in Go, with limited access to the underlying host. + +### Node Isolation + +Node isolation is another technique that you can use to isolate tenant workloads from each other. With node isolation, a set of nodes is dedicated to running pods from a particular tenant and co-mingling of tenant pods is prohibited. This configuration reduces the noisy tenant issue, in that all pods running on a node will be from a particular tenant. The risk of information disclosure is slightly lower with node isolation because an attacker that manages to escape from a container will only have access to the containers and volumes mounted to that node. + +Although workloads from different tenants are running on different nodes, it is important to be aware that the kubelet and (unless using virtual control planes) the API service are still shared services. A skilled attacker could use the permissions assigned to the kubelet or other pods running on the node to move laterally within the cluster and gain access to tenant workloads running on other nodes. If this is a major concern, consider implementing compensating controls such as seccomp, AppArmor or SELinux or explore using sandboxing or creating separate clusters for each tenant. + +Node isolation is a little easier to reason about from a billing standpoint than sandboxing since you can charge back per node rather than per pod. It also has fewer compatibility and performance issues and may be easier to implement than sandboxing. For example, nodes for each tenant can be configured with taints so that only pods with the corresponding toleration can run on them. A mutating webhook could then be used to automatically add tolerations and node affinities to pods deployed into tenant namespaces so that they run on a specific set of nodes designated for that tenant. + +## Additional Considerations + +This section discusses other Kubernetes constructs and patterns that are relevant for multi-tenancy. + +### API Priority and Fairness + +[API priority and fairness](/docs/concepts/cluster-administration/flow-control/) is a Kubernetes feature that allows you to assign a priority to certain pods running within the cluster. When an application calls the Kubernetes API, the API server evaluates the priority assigned to pod. Calls from pods with higher priority are fulfilled before those with a lower priority. When contention is high, lower priority calls can be queued until the server is less busy or you can reject the requests. + +Using API priority and fairness will not be very common in SaaS environments unless you are allowing customers to run applications that interface with the Kubernetes API, e.g. a controller. + +### Quality-of-Service (QoS) + +When you’re running a SaaS application, you may want the ability to offer different Quality-of-Service (QoS) tiers of service to different tenants. For example, you may have freemium service that comes with fewer performance guarantees and features and a for-fee service tier with specific performance guarantees. Fortunately, there are several Kubernetes constructs that can help you accomplish this within a shared cluster, including network QoS, storage classes, and pod priority and preemption. The idea with each of these is to provide tenants with the quality of service that they paid for. Let’s start by looking at networking QoS. + +By default, all of the pods on a node share the node’s network interface. Without network QoS, a pod with 100 network flows will always consume a greater share of the node’s bandwidth than a pod with 10 flows. The Kubernetes [bandwidth plugin](https://www.cni.dev/plugins/current/meta/bandwidth/) creates an [extended resource](/docs/concepts/configuration/manage-resources-containers/#extended-resources) for networking that allows you to use Kubernetes resources constructs, i.e. requests/limits, to apply rate limits to pods by using Linux tc queues. Be aware that the plugin is considered experimental as per the [Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#support-traffic-shaping) documentation and should be thoroughly tested before use in production environments. + +For storage QoS, you will likely want to create different storage classes or profiles with different performance characteristics. Each storage profile can be associated with a different tier of service that is optimized for different workloads such IO, redundancy, or throughput. Additional logic might be necessary to allow the tenant to associate the appropriate storage profile with their workload. + +Finally, there’s [pod priority and preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/) where you can assign priority values to pods. When scheduling pods, the scheduler will try evicting pods with lower priority when there are insufficient resources to schedule pods assigned a higher priority. If you have a use case where you’re running freemium and for-fee services in a shared cluster you may want to give priority to your paid tenants by using this feature. + +### DNS + +Kubernetes clusters include a Domain Name System (DNS) service to provide translations from names to IP addresses, for all Services and Pods. By default, the Kubernetes DNS service allows lookups across all namespaces in the cluster. + +In multi-tenant environments where tenants can access pods and other Kubernetes resources, or where stronger isolation is required, it may be necessary to prevent pods from looking up services in other Namespaces. This can be done by configuring firewall rules for the DNS service. For example, CoreDNS, the default DNS service for Kubernetes, can leverage Kubernetes metadata to restrict queries to pods and services within a namespace as described in this example in the [CoreDNS documentation](https://github.com/coredns/policy#kubernetes-metadata-multi-tenancy-policy). + +When a "Virtual Control Plane per tenant" model is used, a DNS service must be configured per tenant or a [customized version of CoreDNS](https://github.com/kubernetes-sigs/cluster-api-provider-nested/blob/main/virtualcluster/doc/tenant-dns.md) must be configured. + +### Operators + +[Operators](/docs/concepts/extend-kubernetes/operator/) are Kubernetes controllers that manage applications. Operators can simplify the management of multiple instances of an application, like a database service, which makes them a common building block in the multi-consumer (SaaS) multi-tenancy use case. + +Operators used in a multi-tenant environment should follow a stricter set of guidelines [2]. Specifically, the Operator should: +* Support creating resources within different tenant namespaces, rather than just in the namespace in which the Operator is deployed. +* Ensure that the Pods are configured with resource requests and limits, to ensure scheduling and fairness. +* Support configuration of Pods for data-plane isolation techniques such as node isolation and sandboxing. + +## Implementations + +{{% thirdparty-content %}} + +There are two primary ways to share a Kubernetes cluster for multi-tenancy: using Namespaces (i.e. a Namespace per tenant) or by virtualizing the control plane (i.e. Virtual control plane per tenant). + +In both cases, data plane isolation, and management of additional considerations such as API Priority and Fairness, is also recommended. + +Namespace isolation is well-supported by Kubernetes, has a negligible resource cost, and provides mechanisms to allow tenants to interact appropriately, such as by allowing service-to-service communication. However, it can be difficult to configure, and doesn't apply to Kubernetes resources that can't be namespaced, such as Custom Resource Definitions, Storage Classes, and Webhooks. + +Control plane virtualization allows for isolation of non-namespaced resources at the cost of somewhat higher resource usage and more difficult cross-tenant sharing. It is a good option when namespace isolation is insufficient but dedicated clusters are undesirable, due to the high cost of maintaining them (especially on-prem) or due to their higher overhead and lack of resource sharing. However, even within a virtualized control plane, you will likely see benefits by using namespaces as well. + +The two options are discussed in more detail in the following sections: + +### Namespace per tenant + +As previously mentioned, you should consider isolating each workload in its own namespace, even if you are using dedicated clusters or virtualized control planes. This ensures that each workload only has access to its own resources, such as Config Maps and Secrets, and allows you to tailor dedicated security policies for each workload. In addition, it is a best practice to give each namespace names that are unique across your entire fleet (i.e., even if they are in separate clusters), as this gives you the flexibility to switch between dedicated and shared clusters in the future, or to use multi-cluster tooling such as service meshes. + +Conversely, there are also advantages to assigning namespaces at the tenant level, not just the workload level, since there are often policies that apply to all workloads owned by a single tenant. However, this raises its own problems. Firstly, this makes it difficult or impossible to customize policies to individual workloads, and secondly, it may be challenging to come up with a single level of "tenancy" that should be given a namespace. For example, an organization may have divisions, teams, and subteams - which should be assigned a namespace? + +To solve this, Kubernetes provides the [Hierarchical Namespace Controller (HNC)](https://github.com/kubernetes-sigs/hierarchical-namespaces), which allows you to organize your namespaces into hierarchies, and share certain policies and resources between them. It also helps you manage namespace labels, namespace lifecycles, and delegated management, and share resource quotas across related namespaces. These capabilities can be useful in both multi-team and multi-customer scenarios. + +Other open-source projects provide similar capabilities and aid in managing namespaced resources: + +**Multi-team tenancy:** +* [Capsule](https://github.com/clastix/capsule) +* [Kiosk](https://github.com/loft-sh/kiosk) + +**Multi-customer tenancy:** +* [Kubeplus](https://github.com/cloud-ark/kubeplus) + +**Policy engines:** +* [Kyverno](https://kyverno.io/) +* [OPA/Gatekeeper](https://github.com/open-policy-agent/gatekeeper) + +### Virtual control plane per tenant + +Another form of control-plane isolation is to use Kubernetes extensions to provide each tenant a virtual control-plane that enables segmentation of cluster-wide API resources but shares worker nodes. + +The virtual control plane based multi-tenancy model extends namespace-based multi-tenancy by providing each tenant with dedicated control plane components, and hence complete control over cluster-wide resources and add-on services. Worker nodes are shared across all tenants, and are managed by a Kubernetes cluster that is normally inaccessible to tenants. This cluster is often referred to as a “super-cluster” (or sometimes as a “host-cluster”). Since a tenant’s control-plane is not directly associated with underlying compute resources it is referred to as a “virtual” control plane. + +A virtual control plane typically consists of the Kubernetes API server, the controller manager, and the etcd data store. It interacts with the super cluster via a metadata synchronization controller which coordinates changes across tenant control planes and the control plane of the super--cluster. + +By using per-tenant dedicated control planes, most of the isolation problems due to sharing one API server among all tenants are solved. Examples include noisy neighbors in the control plane, uncontrollable blast radius of policy misconfigurations, and conflicts between cluster scope objects such as webhooks and CRDs. Hence, the virtual control plane model is particularly suitable for cases where each tenant requires access to a Kubernetes API server and expects the full cluster manageability. + +The improved isolation comes at the cost of running and maintaining an individual virtual control plane per tenant. In addition, per-tenant control planes do not solve isolation problems in the data plane, such as node-level noisy neighbors or security threats. These must still be addressed separately. + +The Kubernetes [Cluster API - Nested (CAPN)](https://github.com/kubernetes-sigs/cluster-api-provider-nested/tree/main/virtualcluster) project provides an implementation of virtual control planes. + +**Other implementations:** +* [vcluster](https://github.com/loft-sh/vcluster) + diff --git a/content/en/docs/concepts/security/rbac-good-practices.md b/content/en/docs/concepts/security/rbac-good-practices.md index 2434b13f75..41a7e555b5 100644 --- a/content/en/docs/concepts/security/rbac-good-practices.md +++ b/content/en/docs/concepts/security/rbac-good-practices.md @@ -4,6 +4,7 @@ title: Role Based Access Control Good Practices description: > Principles and practices for good RBAC design for cluster operators. content_type: concept +weight: 60 --- diff --git a/content/en/docs/concepts/security/windows-security.md b/content/en/docs/concepts/security/windows-security.md index 1341f38c59..8d661235ca 100644 --- a/content/en/docs/concepts/security/windows-security.md +++ b/content/en/docs/concepts/security/windows-security.md @@ -6,7 +6,7 @@ reviewers: - perithompson title: Security For Windows Nodes content_type: concept -weight: 75 +weight: 40 --- diff --git a/static/images/docs/multi-tenancy.png b/static/images/docs/multi-tenancy.png new file mode 100755 index 0000000000000000000000000000000000000000..0ce341120a19047d0087c68659c46ae98bef348f GIT binary patch literal 34460 zcmc$G2UJs8_irp?2OO}03L{meNtYTGQGoyoia-Q3G*ODuAwW=+A|TQU2oa@-f)J`w zReIMTy-9BYq=lN~otvPdGxNRg{oh;bvDPdn$vth?-`;2M>w8iCJi`vQ9WWS-LHWX2 zO&DymCk(bRZ`(%j4NvV(D)?uEt>*bNus8LGM!|>8W~bFo!(jNpovSzg0H3$txu9zc zgK>{Q|82N$^v59>%u7W1?CHx+1`}OfX@V8bJ)mY)NqrRm4LqS{i8W7=5~Jt8ZpW5lb^o8R_8mUB*}zQk<%0nuSYPm6g}BoDYxa<51 zk|(w{i>lfGd@8iQRG?Vq&`_ezo2F9)|SQupB=_l{srqm`+y-nK2;=F#qx5eg<~ zNs>}-La~XXjHl638HN;XVD930+nr32f|HVa=DXO&Z59V})y2$Yr)T{o9fq3AWZPRl zGlSiqI>?x;G>Q;Va2P4mWHf(rqpdO-$;VP-VUuK8L6CoGqLO48!^|2qFLQ+p? z-QbpkWttajKE)R*8~T_y&M4O_mq6UQ&cfKRtR#kSfV;Y$Jg4c^eSR!VIaf5g)4T(J zL1EUf4bH)gj*jxxeQw`=;#!{d;{@S&^jT36F!Y(cw;B04HjvwpPua5ETS2Mhj z8*j!4&B(AeqgdfFt#eTc7kX-W9oroQ%oRdn2|df7G|m^UKyqP?T$=KX(c|#ru`nhZ??8~=JQRe5w&y6Bda*bM& z=kdD=A2bdbjk<3ZA!my#QwjU~%4`a`u&jG95Cv{xPTL@~mYFOxbhVj|91QtFf9KZDu%-HvEs z0-@6ZF^{Flv#h|WCDA;q3yxZ$)MX9|i}@3?2@QE!H!&K`Tg~I6-EVxg=4*EsIIn`t z13L`Te;0R{G0d!Z_59}r;!bFTpCU^dF`p3#ihWA)QXDRPi!)YW&|;%4pjFqLvSw*k ztF&r=qnFWWT`3`iRm*FcRJ0omg9S*-k@we?=5hS7+F4RT;N=QQc&c_?z2k9$lv{?_ zQbIlk)$P|*sT?bLs3vluG)3*)vR9<^${A>^_|UgGLva?d;4vKnCxfV{Zgtz{A;4?_ zYEWvj24=FiXZ4c?E{eS-Z52@cLo!Ln#nB`zsjh+(Ia~j8`H1?`ykbQj>m3Oejg>ud zDpI-`5murz$(63WLj?az?YLWk2~r`UCFEtYwTkC1nxtK~X4If203nqJLR#C!X)S~8 zS<3C9yfa)5wN%LrLWK7Pyoi_0O4G=e;;Bm^y1KxREahTI95_8QF_GKhRyH$id_0%2 zE!)63o+*1LQ3=?{Af_qjrPmm;wN76zfoW@En~$5@s|n*{U3N7#VzL*bE-ERD@oV(D z_u|N=%Vx|b)-&g2361G}TQlTW2}$mbF9Y17i^NF82x=u`uXjE1ngJJ>-Gdh}ncooKFfbRYr;xdW7L+3W4M7&#YL2t$_6ntYZwri zk3~#z385!|RqlBO4eii1$CpmE2~$6hM(0;)P{ao|pRo?-NisfM!EH2yG^Sbo_uYqL zDX&dXLtske<1f)~R_mC^Sp~YrtNpG9goWz+JVqH(9f6qDhMDJDSB6^%UiBZw(3pp{ zt=)MzbZA#p?anL|dc;9`g|-nIr^Q%yhPN)_l+cwzCK*TQCn-UJ6 zW1+A2U;|(t%fJACm07(PdFGwU|F;LM#PHO9>WUcblmz7zBJNs3rNw60m-E0ExAZcV zwg?FKtavC<&Dft7)kQ=Yx-ZS`O?b$e`6uim2XMXDyy3eIGyNM%+2w3?1j~6XLmB8N zV^n>uWW17Q0fX%sgl3V)MqYLM8e2de#OfsFX>G|%du`Fj?YEys2FBaJKHM*c$3H|^ zh$)$J!Ja7~10XW(SiQFx1-`8K?aPx_A0I0@V&t^+q0o%6tt8I%D|Tz_nS#~7lJldr z7rnO+=H}&X_i5=Amn93ecGAXd zuDz?;MSQn1^iJj#!ORk)J#`sTTl(1Kt8`HkIGIDS7C9rf-_va1@X;x|;b%#&6bIEx zUXB$}>dl{4-wz>5-;2(hlQSy{r|2KPrSL@i@Jy8vE_R3<;b~L3LjfgN4n&r6EGWv z1r7Ku4c+hLPZ@d6&AF&Mb$WCj+o_(hu-T>IeYJnf^Ze?f$BIGxUFhBw)!L?uH|otk z74BbKN;OY)Wsp&%gGSXaxifK6c2i0Va(N5S^QQrUN8NNdLY(Flo;c#h&?NY`5n(}c zM|`K<$V9h!On66*a1w^UKPNtkFR9n0_Q$gI*C%g()}J@1lpR#}o2|3{msL;yhgGK( zNIl|mv#_)PmxUfnJApzof|g4@6LHpRS}R9;8L2gT8m(ajEjg=^LES84c7mEc^5)#r zFb?8d+(6AN&(N)xCx*q=$f>kYz|)mLw()*x`DYu2{~!#ew6y8&n>mG)aU*Kn$R_mE zCfD2yGisqc8c7PLOmc}nD0 ziTG?pt*AQRJS?39Vpk#4xLZREjfmOlbj2sOvW@$+ssPA zm<-4GeZ%?xwrBOC%dNuzdEX8(jh_Ibu8lD zA~$bq~tl`H0HcIbddm^?Cl2S8e#|$ey^Uj79%JxJY;Gn#W&c~HM(DI zi{V|3H5GqHQ*p&hz*Bvtuc;t8eR7qneA>f(wIx+XekEkXZO6u`WHa^Dt$L*J*vX2S z3`-xu@T)po<}wN%b;MSrR*W@3+y_QJ290NtMjMm5!iKG?vxvFV_w+%oC^q~m?)mp_zdj*&;^|m_euoJ!!jr` z$J7|5RQUkrQ5Tf%MSg;X!8$laEbDF=qo_llaT5WEZLrou+i$lrVYkE51(_S01w=)X z4IcwEA&L0NMp8802($1j&62n+$g;8(xB4n%x%%%*42njK8>0qAYn1=?n+7;``VHph zA6uVb0ra}#euH6i4-REn*0>$nJd2cYR91+_9%TYqLD*({*-b;DiDgL`@ye5`r zTZ$-sQ{-~)9=B1|j1c)nN-hR|_yL?!KAfGt$)hZ1Mh@b>C##0f3uaI2W|=UPRpWg4nR7EyFMTKs|4 z5k@9!2+v>Zb&QQZ0yqrBTKf#|=A0Uv%#zDR$M$_n_|UC07 z6AZuuse_o4zSkI4SZ;>WCM{ik+s*}Ms4RW-Wc$5|s8Cm7W%u%W*sO^+Ypb=NyCwAE1svhs(i{{)V`hb&CGrDJc}TIW(#_GNT++XdnbXt zgNIIgja*mo)5yPJs zR)|m@Al42h#hGIx{1e7?iTA*)D&J?-sTWHR~w zZJa@gilppRzg2~P6x;Mlb9#I6Zd`+Wt=D)UNpr$8lEaLdYlK>IST^Pd;uGRYWPztUelT+K|P1q zLjLf*vJWh?UsT>Vn;(sB$Y7D3mkW1F(1hFP>Il-cy!B0{Y9zj?H_Q309mXa%F3|od z2#Xuj#X?hCIepDeb1+eP!7_$knDnl+`&xpfVpZ%3D=xEHU;5 zIeM(ES3SEz)V@%;LFI8YehWmC`8Lr;I>mvSC}v=P@}_qDRv8mrM}up^;WL1pOSwAQP^x zP$8q>c2;Q)X=I2)uDyEBP{OFTtN3T-v7=KnH-0V*(i-fXquOGCg7O{iMDc4buSoNY zL`Hr-z#mSQkmW(f#yodk(gJ+x3g3KK)r0pAgApRWQy@XXk<-Q;=AhAb@BW-hbV5y} zTa1;cO%5ql{6ao5D3w)_Lyg!a<9@F+if)nhrY3UrsSU!JB*qaE^WD*0&*v4qVW#S+ zhClp(3R@HiDUexM`@OuOs%P?h=sm8Ysg}(RW*99&o)V+f)jqPhDbVI z)B2^U-H*6Anu~4;I>HP;8Y`Vd5{eEk>r}KMYU4T5b2%|y-~ka!9HSN%u?rbtST5ix z0|-2gm(^F#D|X1vK?vwuS-#7NnF|i{XL7QL`FZY+stOrmsQTf@3HeAaOCr*o<^VOk zlM%dLsWrkznbc4%cZpz(h*($Xln#nDB#_rML#;|RKgrvY?j1cQs)cU^yT?b*F15MV)Yh|8vb3 z!*Wsc8!gG7)p~_DT7S3B5KlO8*~@EF5}j8sUXP)%;yA>LnVLwvvC)9pU}I4RlAn@X z+$iO!Iwv|Gf!As@l3sB<$!!^efw6UP{-hh}8=lctk|iW}G3CN0i^mY<)lC{oi>+J1$Q z+Kd`TAj6e-ri5es4hZbKr$5lFhz+*phI&gwX?0UOVH2&~ww$D6~v4oqE#7d2GKeA@iO82*Nk{1GYJu)Asa><6m(zXoJ9XS)IRT{mbj zD5?qEgDhAV;ekE;4eDi9md3lk1E6bKSXR}|~+(5kG!9WKpbi{}QiIVFj>u}NkqiK+0ba?eUYNba8zig9cPXROs&^crsqP?gt zcOTZeef!3T00L(oU`;lhl)<*D{KqHO;oCFP)7v&)=i}bC2g1cD<9K)Jb@Ul5<*L-6 zeB{`8Q>T;2ym z`ul$ohC+)q*c*XbBrL!;TL1p3BM=NfcWx{Kim=wW0G+Z@@t{X}X`RsNXS;!H z?&IQ`uUQ9_kMgmf9*AQ&Wz=UH@z+HkfE@gSf|dtC4o=v8HsBVeo3FSpzDRVPF8`rEq?)o4h?x{}3U|cH0!X&(in%#0PxClAd>3MZPiPhZm z%NwtwYkc^Jome`}dc$*)o&}kVYYc>Y#TY0j70i>+4R9C5_Nk`~mFOwz!@vghVElKA ztQUJa8M1qu_@x^Az$5h`EFYdy&490L2aukc6=hY7VE;%3!Cl_Lt_R>(& zj{uS`h{)IV3a-eFq{Vs1f`EwJZuhBPRgHLTW=z5IK-Xec^xl>BJXNvT5hOf4wW!J^ z0i#k%y1sSZl%%xGk7y>o+nTnRm}!yQ{dyr`DbWVoS`e3hHKNEsHN@g}du!c@=oYNb zrSDphul}oj4rK}a3p&wiiQ_W=71Bfb!Ic*6JmoS+1Lu{jRIQXWaZqM-|niSC^mAcAbO8} zH8C!|FRf*)QC!F1qrZ^RqSf$x*Yoev^-t!;M=mS-`0O{!(FaW(A%$NK_RQ4>c5Co^ zv-gl=#8ur1)hFLf7pN~CMAm`e-AB*Uf|@hZBCml$T~TD}0Xju;x&5R$fAL~xq%m*z zP8I(Cw_WmQ(aI&Y@t2R-1b3sVjLEJ>V;3WxtWTsq{cPf|T+-q3+llaOeajmln>?!0;v)HtNJT(MR&D9bnho0FJ^0`g$$_>W6f`ERA0$WS_Pje8o|B-(+LnEQ5keu=ZN zuPd@UIHz`i8LQ@SvPYcvN~P4})bPKm5-)RGn6u9E>+EOU(TKihYR78iP!aIxHv|9r z$QxX()0*K286OByRQu`*W)?!+5M!?vOqdo5e<|lW>T7SeWcXNxU*9xjqE0G6`gLXi zx+ji#VUmL)f4dj+@hK^JJH7=LRvTWzz0=Zm=KcLL2p6y%0e?mlMKFZbzsTrh&% z|HGrbs~wbNS?MX7J|}TEAp!C;gQeqP|GJti;Q%^CW8B-=#Zt0OdKgfQO|OH zS8-W!Coyis?R8zxTlCaqG0%w?H3#q=BI~3KSmj$jE&O8aYtHU5Ed~G%MZ3nr`pQr* zny|@@SE`bFn3P2@k&ID$qq$T*UH*9yUMxZY3YltN=$qRzz-?y7%H<$y>U41T+9`m0 z(qWi(F)80f_jT3usNkY{?Jev?YPFne#nwF&cMWqC7QXJSF(%~J^rdwtZTFDy>nu_E z5`EGNlCqhqFrRYL8RGc$cPg$zcgqi+H>+dc!SA5p;ALPvY~JHi=vsg0T*MLJ;mg%q zR}#5+Cy>nl-TKBTUiP}wR<0tR6G0_9__W6IAakdhMM;NX$v0SEhA>C>IZCCS$t!2Y zpvMk+0@;QHTrTq6#8>3qOE2^J5vhK-L-PM|U2>j8dMCvc{vsGO} z?gmQU;(=w|RCSLxkfr*?Ox!zDS^9?OH)NRNbl9mZRQQ!IPh42 zyiXE_dm#btteW$&a_%n{{?k9Ky-CiRi2p#eogiEYd$RqK`ZYLqTJ4d>wk&ch`C9@X zMU-q9hNr4{#;8)IBNq3|RRNGg%V5&g;_s+dTah+JyE5<46scgTgab1imP?+W=|FuD zDh%`uXee9>bQI;e2BFDcH0)oeVxzWBU?vogi!CnAg8@O!M=Ox=|;M(-taeUp5pb^U9>;ij)d>fjF_|5*Kr=7SP)1E zGOc%*84Gc2?5WI1Lt}UrKIgh$N4kZ~t58FICXP^^d$|QsW`ZT6rwzh6Y93+6aYdOd zep?>a9%Mk@8&%CYRF#t$(B&`01#{*Q3tu4$Nd`CUuu4Et4XW^GP4o9V=Bdf5G2 zRrtB;RQZL+HDBCVnN|zN)Q^a2nyO^+K|1skPDpsfJXsgzKn`J?kI7Pv&4u__>T$|x zy{SHyyTP009!cE?kjcuC>9Yahgcz6dx7zbI!6&JcM^vI^*b=3z0f32T^(@d|r*msJ z9)4x|V-Y~P04ncHkE@uhyyC)9kt&*brIe0aAVG^h$Gbf|!D+>+d~n{H@~uMCu>H&D z6Vv==qpxGZ#I3XbMbWgN&t_fZjLf75=T167&}B*}OWIXHB=Nb{!}HdKoxI#8l!^BkG zEpQ)$IeVJg;ES=8ZoN>E;`{bNpHJW=+?oKO%!;2HqQ#)=Z;e3c2H7-#%Hsj0SOfcm zI&{Kkfc0qpJctoHo@$3x%aQ64A4=(a;lIR*k$W-TO)i0(3)UBfI3#~QQP=|DS5Wv| z*VA?O^T$;X+0ateC!lw(!nKmNFZG=5-J)GOyJw8)hOK-P4~w{XqodXdDdm z!*`*XFbi?FRSc`MovtIayR$VX5Ad$CVqjO$Y^#`?9-KSmz?@Z7d$(G3X@SX*(E}!H z%JHhomXqDY&kzz3JGW$+3+Vbt9$ZcSc8RpMJs{+m+L)rJ)c7GBWdmT*}!(-~Plfp-gjEUeeGvxN6L!p7so)lBA#rT0Esyy5eeUL!pWO;qWAWbey;#i0;*6C<2s$qdL zekEy2mU`f7JZraTQ9w+5fS)O9!HS|gCjRGG_P2=_{?0Fg7@hR;ridVBDkY$YgayqofDji%@oOTeDffw~5QAcxn~o5CuH$fH`>9+%<3E}|YsOr_5yIWC zb!g~~_7$E?mf{k_JEOZ1Gz~?Ab z&4cf7{V$NvS&WGBgS=XS0d^8?$}}E+=I!K^!ggy(%8R>}2gTUT^#-mb(HT74&nH0w=I z8D;!6^!QgY-z6L8{RY8-5dEFLAX@=pjmb5-|4+ADeCeMuNk=4I0*mH7BPaucv#T$p zjBlf99q7izARW~O#ONaBW3s1}p$RbP}$&Rek zOoKqWc{;co0jVY)Q$hw0&GSH%3Zqp%l$nIDd4>J!BXmHk!8pqoG;DVz@EEe8l(?#q zX8g<*V5@|k2pMI8mEh3YU~%&vf0|qY*{4TIJ0Vc;9g+eu12)=!F=?V>rPW|98&%5e z->r56V!ot;q{w6!hA2T&ii%Zoqh}K7w&7lA6twTpJnGZjx8qfgA$4ABa@RY5f_VV#enpcGc*)ebOU) zpdiiqJ(c$8(G`$rjJhkylDU~UJwD}hP#Cz&?oaugIU!eZ1qX5DOq3zg(cF~XZG3A^ zlay}SoQ7{Jd!Ib(3Mcv6Qwj9s2mYc_fsWLLF*oy~WK&*A>pR5xM6PcjzcNM6WEIOp z?9~Ey_0lvm^)og5QYRbu3f3ir06FY9n5v(lYY%6)*yz4-{s8jZ@NH#V|7h%+z+vXj z9g=_48ULbU2!WaqOQnP8-9-(05W6x9PY=9jNh(`fT#5vc#=n zf@U}9?&U{e$C*p`TQ!PEvDNL}DhncA!CPPF4m%}F6;-j*NI)CcY^s!xZsbhDi=&n06~a+^hN^{_1fz z$4Lu(Il;|8+0&@+YCYj}s5x&$SfjCI4is(Z(MgfqMic5baGZJx6SzEX2wz~Qrr z)(;J%8*h5y6IA)}<96xMqa=`{zg_-G%mqShkEAqQRNF;Eq>UxpdR-eM{W*J1=IF_A zN8it8og!|P5Eea|xDX5$I2ZpST%ih3v&BE&c5t#=BR33Q1e=&+ij7+ zGCnd>ydw;x=Xg7!=^3DfB91GS30o@W45C=|>ode_d!&h!y-#?{p!GN}Ug%lk!#00M@1RY@*orUyQjjM=fl^WI9@NwHG_Ph#yAD5&5gB za;i@VKz2kOBE7KRtzsSB@BO?2Q!3K}Iadj;*suAc)$tVz2;NUCd|%LFyCd4{J|G0T zd8?^QrGAm}C%fRme_E$inKz6C<4eSAf2Hg{9DI6nkJ{C~O^---gpm^)xBwxGxQai+PbOmN0w-M^ORtJN2_xCTVV7qcQ1Wj;R*>E9AZ$H zp_t>p2wB3@RMRp&hsuJ*M_Xx`+)xNP{X3n!ZJ5#b7XptZmJzn2`=%U%#NW#(P)7os z-fAG1?^?pm6Z{tX;=2*mrNEh3tSpes@ha3!UWB5oWY7LENw(3~-we!+q+Y0|#hnh( z#LOM{fs&%YJT(h=DgAouby@CVrD8{S>!!THU2j%u)IUaFLFbzz%Xg_qX}`-XG_||; z>sWfcwhOlZ2<@&s?xoWXaIg04sg<66v%k>pfA+OM?jDaG*R})~V$}ehJ^C&$z>EI4 z_}sJiHFOa+2=J!TcSEF+i)|gI;^3*gLYZH#^0I7%Nv>s9Y4-KtMMiAvmG5l(j*OOF4u%)Fu{C4LALbY(r*-5-6HcQedlEp7X} z@7QJ<)cFAyLADyIUHcDDtfS8Vn}W!Hynlx(F@G|2EiXVXQv1F)dT0&R5P&?v54oeq zu4{-ctVVz@X!~z>`~Ohl2niB}jMHYpM*bp5^mW$*s{j5<-n<2>c0I_`0P0CWbtmnL z)ng*ajO}OTC8$CryH6UrmMKFx9V$wNYE;+CY02~(VNgl275XKDphvHV{U6rFB5z|4 zKt;fyBzB%Z;@veq7XAobTGQh)FreV;AB~$Gmb|25$_h{`P>%|&?IHiyTEQ+*NbvVe z5?s@Rzn1}^cme#~TC3-Ehbki0pCscsqL#VtB}cIGxzX733kG%#FVMny!=HbY>_Y|m z^m29}cSL)c&F3UBO5rBkA)uI_ijH7rUiL7SIPyIIAVHbA?Ox;1ZX}qdtP&g ziMP_^AF%hA!I4hj;K727{ff;ZU|M!$snzy-ilA zqx@)(V#le)Yt|a&+QVU^vr{Pu;x`?4+Xww0QaX({IU-G~)r#)QWkwgqEC4;ATjW+4u~l)KV7r_kIb-x%yA9-(I*N{=epI#&Ba`1_}ml^la zr26ogH)UG1MzW`af${J90`nbl9V_hjX#GeHrR(~UlAb#6;jq`<#CPX78R`A_^}JhQ zp}Gv(H_L{Co_=L%lb>Z;<4v9jo-=-G(`nxKsBwxx+zi3vH3 z$xUyy%h2s~`{oYrfc&2gHLi{r?z*r^v8=HEO;gyUk#6t4$yvt+N`Am&B_uoCJR-E; z`Ygj-fapw0L0d1&T_zc7q}|k!ErG8OuC7$|kM=B8EE4*%rR33$Z{@t%O=f#s z5}LgW{aHS(cam};ioZ~!c38~&UQ*xW3;PDj*4W~N1Wa_Ok+*F_A6G;5n1G+prp~33 zgM~>_PMwYB)#j=tv;EHPY8crs}g1GSvJ84Aq9@wld{#DEqaD*Ag z1D#D+@O?KGmpcoa46IZxt21OSXw0;xPTz4$nuF)xp4PUp5r#Y6nWfZ%Kx%cOc%a|M zMS+~;*j^X&ILQr%F6>^IJmy%Qng8189Xa!fb~(eP$<<+^VZDLIYI!|F`aWyo06+yC{@x6xbBHqYs%!q+~B)oZhITc zXNO9y81Lj~-c_`ttR_tuHYkuVGViCO6_sTlcQj4ZPZ|WslArrB_F{ihr|=)B<9u!C zx_uR{@EZp8sxg!5+u7bVhaSUfjo%A*8?485oRll!n;Q3*eJzVg>z|Z0_9oc6RM;%0 zX7q02sD3_8BvS8~j`mhCer}!R$fm|-YEX?U?($Vgnpb=V7WMMvEj_52D)tyKsHYCz zN)+^Ny*>SfvXWLzagojyPR`s8%K^6aSg0CktCHf~R0z2q56LeGKKmGN8>TF-BV0G%4u5AQux<7sV7%1m3 zECL6eK7Rr9MoHHFScHZLASClIZ`s(&vDCEx>6eI8bnLTLqH!M`tDSs_%>f4hL*JjS z%X&x$Zj6AgbVPIqNZk=S$n%UcS4}{q4BfkDgU|m8{@QO*;!giF zE^G%Zk$~T!b#?JyJ;w5S>HGy~s_RgNWY5y__~2Py-g)Sobj3A*2EE~fx=O-805zQ@ zm{A<6lLdRvyC8E>Z8h$6vM@ybwJ+*EW|=V4mmcRFJteWTFj`U^43>JShQ?zKo5%}2={JPmWHmIEO51Yr}~&G9aKYmqMgoR ztif<)*{^uvV2JBNf^d~O>1*9o;kS{pVWR3H-O=<%;7ua?D1S1qJs}FM_0-_oJCtC8FzmWCSj$dF3DOYnBI-ns24-vRh2`Gj z-C-`EzaS%ompm<{fML5IJ@Wy#>?@3!ZiMQ_C2y7&Q9zwHNlj9Pa2S^UG=7tsObTbL zulz!GON}oAF?K$9=O)tZKukL6G%m;6gz2V$qzU}c~KZn~gAVXf3NO*)^P1j>) z*dCtIQz4AEcLBwE57HV%D})H>6quQzhVAaXnYaV92erQUM9n#F>razS{LvIOaG|>_ zS1*&bxYT5+3F;Xd)GIWPtg+Y#6F36RT0@)FzqSMNk4#WPM#`vpIzDwsfX!O`Uig6yYw(!>|r>thD;g&o1 zbkA?}c>M$j+C%diZf_GWAfMOkO;O?D@uN@N$b-V}?X*@N=1B3Rj8w|#hb)5MA$-U6 zm+|MP1i9deN1cbhEHr{3@w@ml@-sjLgZhgWVz|3pX3@f6ra@DD)gl_ztgn!Nw2*st z)D%StJl5gd{x0U#Irnw^|c;|Jr13mhs2HVlV;%=|<)tY;?>awdBS5 zR`D$m)YS88nvVpp#zzwn2u)e8;l{cs!XyWAm03?1&`@Xl-$vPI?m1$uX;0mUO5gOy zXqcp`R`O)D-p@9nLgJOD;9V@P<;(yptSP>9iuhhp{6h?*rqC|fv&~hO0)oo94seD@ z;jS;04o8cNngq>PUYnu1JV9G6#DFbg_=k|1t5lkyf?J;onj0?FKutfdaK1EQzvU*- z6?m5ZFq^0d&;Bj2i)R#ALKaFbZhH+V1$()HZV$}T;_#FjuOS$uTkdqrP0Ne&X&YTq z)(ivBfSAY%3AA|;)SN-*n;N zQgcC!b4hj1)Do++(9)ZSX3RO3xfgaK8l3lu?=eV?nYnX=5Ek9VpG;=9hf!ZNTq39~ zJ+{f|@;^FZr34zfB1Q*4`!y(MN)<2M$2l(mj?^g2T&(*D7e85b;~r!wBVBn-xpVQ> zjgI9h`6dFfxOk4!p_qJWN!@xb^T@Cf6GDkSOY9l&>XO{i0@rUz?jIdS6rje&Y+$}G zdePM#vgDvoCbQFg0Cx(pQf-y0!^>r^845;Ac0EYC#%o$mt#Vi8{ngIEhAenZ&r#%E zmIN~ps9DhL8AIVRGEd_-MV;%e9v76{gT=gOqn%exMt~dQEyvqX$eNta5Ln{!?uD#} ziMHZWWWtrMo>!vbEz0{>nnMZ~{hv3*>k}G;9C}=WrAG2tFGZ=?Q#C6OV6QF*CBZwR zlQ+VI&JgbL9u5!Lfo=T=Kf?()o4%!oN}9p|bF6y?Mf97@*VJz=pAo+ePn>qqi8A9m zB%m0w1?Eu`Z1+r=?zx(kz#QORRycAy-K}x`bP6=H4cs2^7B`uJdIIli9|S~hQPES= zaO1i!AS3W|x?B4a1w-h*TW9~8QqXfmG{0kdqg@n=k-yLO4}&jP0~;@W0SE{9W8(!n z&0vb!`Ez5h-f8lZzRfp5k_Pnk2Jn)$(Z2SQ`t*iv+Ah~*9YBwgzd5^iWJS+koZT0$H{`+dGIN2^&xz-2Lt{+Ph5)pW;0lH&PMKiXmGZ26z=>#JaXjS2{jacD;O$3a{ft#AE)?_B+wy3oAz^K z|G@fwDC^IsJcnPFpKDNd+ir}y{Q<=UPOL+m-Bu5iObYla07OdCg@$R6e$IYmP-ZxV znaB=`x86ilDxBl9#-8t4J{=;Q{y>{=Q~BG)CTl?V=>1O_rm>511W;syzckb90_q?# z_R8LEyZDLDtB07IcbEY!BXe7eK`mp);6YtIy`3Dzl={&tJcES`)Q{mJ=Dyc=7BB<_ z?qxcM)*2ZL@ip0vYdqsRX<{@3E|=i}pVjdAj8cT&^BX*UV%Sz~z`L@7G78j4k}8{+ zg(tulzJ_hnDI84A?FkV&A$o-r;@hSeC%=1YwW4>PeZbuSL<74l^pNV zutkd8);U(au*0Cf)ZV+@h@>ag?6pseNHh{%cDeyXUGO*%(D} zaa<``BwWQIESUQ;!(Kk%IUZ=e#ocai=JtXewsM!6_1TVrE)W;nR43b7w#vlv z#Tssf2%iRH6!OwBmdx$F@$TF}7V^HJ;1tswSqy;z&Lv}vjoAxjHgaIafafMt+ zmVlnO>Rr2qhoi-iM}rKL+(8kjm-{zUS?Bqx{OQSezjd*+p@o5o z(Yx~Yvzoj&ySrX@ zEUoW*$%6mgX&s!D-Hgp=BfNjq_2JQIVr}EH(-CcpOa9J#>j+ykiFfcEA>DhrP{_ve z@&(rq$+58>Zb8NT-jCUZ<+#cR?q4kqC{viy{LnTa{2?BD%C)}rrYmD}*MiYXgxY>_ zXzB?Q7q>5)`!dDZWn2or`5y>TEgSw}K>bt&N!aMN=l<3im628f&xGMQ_?xJ^72q~E z>86FM{$)1!o2>#XX;alQR5haNpKMBfVa?`zHSv5dsz*=wc1Y~%?y1{K2A`QB0~fKQ zp4WDJV*Tbm+wyb$wmubZJ(k<=R{1oDh_LxJ(5z>a9Z1xdl!ngx$T?fyrCM`lx7gvzNJqXp=H@h6E>0WsDvNWfwUdJ>0k7 zgMJU=#EP<|i>*tJ9K1wv0!w5bp`-u)RfmPnLBYn!P$9g{3W`0f7zC#C^Dskjt1$kZEtSkLK^#nNTPd7fx5`Em!rIgW{Lw$+1fxc40`A4-0 zSeYiX&M-VqWD~zj!;Lt}eJcg3f0&8cZTD%gPmxo|uiPQzgxeu&3Ew>3rj%w^o6C;t z_`4UzVw;cRQ>aLDx+F8RA|R%9e};L%+Qvx|`Y4%`VL{+xKUT-uG#EUbRNGAO4T##b!R|lkt3DAa!5Ss2c~Igo7HTx^)$GaYK)zfnPf%U;m-q?dpyTj*brEE`jWY&v}g{ z%ia)-lvbwKHXYX@>$z^z*UJ&xN{9U|%gkhvQ#Y?(lY~6l3X3{`&kb)qN|{GD1(Y_ z+?8R>PEHKvqjq*&xkGGGmBZ0!3wsTY)5P&^j+o_UD@R)rH##tOG^}k;zRG!p_F+}) zh?lIw%ZakrDrvCh+VPXoajGYbcn<)L8|t$ic)qXNSc`pHdV)S^tgw2C(7|)7+^=Yq zG2-UG?3q={xzx~abl;WK7n#}3;kd%L6ZT=p2Q)p6T!ibO?yB*d zo>OT;CSe4Dy<4lLY-hDy%se@|QthG{nxaou#UDa;wG_*A0*j`KRy zwGp_i)~}WN;tikbYgKair@XSFdyU@Ihocv%{_s3tUpG z<*3M0yJtN7g_)+)hq$6eyBcDRr}SCqvanOxQDXj$I9Se}G+%%Hp6VH0G;la|pLqUK zF#I&smnjh)<5kBp3?D-MiSt%}#&7GBSzpwhybf?aprPok$Mz>GN9Yl~t%kOV=Uj-N zS4{NEOrFqx+7$VTWd;B6wB!{@^c@!rY*gb!##yLPiAd7KyI+vo6@axaguisadLN&@ z^ELN%VMgvsTXY}5NG_gPqU9$bZ7l?^65eiS!gyDEF6@Zj^EL0XOaFed*o`snr|sQk zx&hb|c#gi=_{D2*2C-7J&$3Mov8S#=dTGe|yzRH`p0T+RWe1$3t(b-$I||+v#_N7b zBDHq&GoWnWB6`8wRFDUaLoy%6eRKhv&MWpl%#SU2PHTQMINoel+W+v&L1fs(mD1e1 z+S(jpys?*3bfWFFuBOb{%oo~>jGj=>Kp!)*VbqU;`p_8E=987}X(nQ)0eQ`eg}mEb zI;@J7KY7)+LE+|JFQwAE3EjJKC5ipEzhQMiR52;rf+j0JZ;R}&i!oQb)iK{#?us$k zHVbHr@?WwRI!N&<16 z@j+pln%7Ivvc)WXB*xl7l;Vl#U=y?qn-3r5&ldB)dW*->dVhPonHBomhg{u1!-Rw$ zF-2q}_Rn{Rh&%X_M@WXw+kAw~6KX6nVpbC8j+zqm%|*ROt}Kt`;#-IHfl|J8?F!;k zFs%0Kvwf=RqPk<$=GZhdVaaqD;i^6^b$Gpre!$Iwo`xd7#(3cK|J>#>)%&(7RcG6* zkMnZTtZnkPptbUI;e!-W&dp3=cJqQ}-CyJTar@Ah%vYTCU38zp?GFg;TS#b0C{4HX zlh243w3L^%e2eUhtKP!RR^hE_p|7#E=Mk~FRFh3Ne@pF5?Tp0k}dldDk*yWqvJIk)v1L&9u?`s`Ya?L{+4|jQCQChizrXMI_s8$AUX0GU&wcK>&vm`8&-FQK zwMs&PgRVOr%b1ZD4#;7Jg{Ngxe#tW^<0ZmkwVKXkV9z_UVh6(l6K-<+8PM5EV^*D2 zn8wvbj@B!of2HFn_EBUAbZ)!D-36yUW6NG`H^=$1gJ+GYZA#R$H}mQT(ECgf_^VG# z7-Ns3Rt1f!hSl-74zKuYsN(C2+!!y!L&dG7278RAf^y1;_!_&r{`Av5b$xbsSOr+=oPh7l?2;>Dea`qWrSV zIE;z4dCcZ4wR86h9!VcSxV=vHWYa%cEXwylxR=t9*V%A^pz0GVEicb!LUh+$DiE@i z+lSXZkD%c_KQI9$WXI{O#cg4p;)AZaqI{>k$UW>v?>gxyJ*0k0{C3_E zYEe^qHZz)F?Y4Eoj*^QPM}Xr~hDJ#d^17kKo_*=$dWzfv&hyIrpII#wcK;?XjfQFr zi0L^O`!h0`Tx!Ca(Z5M-N6J@*sb!NQc0n?f(qa|w|6j6tzsad(!{1?vj_MQYQ0fd3 z7>E)52T(_CEy-VpGHvFtq6Zs=gnx%*{$2fnnpaaKJW#zPdZShX!ILni)#ZX|lE42-H)rODL!om5ZgZOg?@a;0Ec+59^hbO1YG~Mf z9O~+q#k@!@onJM(dN}$qJ^P?Tuy>Z{iJm{vypTH8w>70(A}`R)unA&H(jqbk23-w< zn=$JBNmmP!K~}kedZ4d5bpOB!Ko7v@;xBQy8ujnM420+Dm=M%W=jI=knUB=WuW_?J3={w!e@7^Y5b5;M1w|wA-0>?L-;(TUXLS(5G#$d?63c@SGCrbGH zB_*SEL}3)7uKQY9zsU?Xjkgo_+B{Pbt9#uJ?enIUlK$F)pm+5YxVUi^rEn2{mPnL9kj-hTtUB}4euZ;q_wn^w$xV%*leCPg{D zJ{)79I}>|dEzrKCq<&Y^gWD#8S+&+mISYqvX0tsy44OD)#Y9;2VN}7N(dCyMWiC+-|&}& zsZPNaS`9*vqJgxd({e@?fe@Oe_5;66GX=yBrhKA%HK=?kDvaoLkgw~ zdy9;wI(%*c`JUG9wud050groV+@k+vFQQ=GysIt>0GrNZMlNc%B)9v+qT-~l@7=_@1M?i) zWbJ)Y&<-<>5%*IIOckGz``z#bE8%Y>$o+wr`{WkWqdcq-ZUW@&xqPYUPNHX=Y7m@L z45hX_V-TfgwN6~X^~oI(-Zw1^J7+l^PYoQB&%j2e+u?VCo65C$KSO-qo!Ju>{`{2Y zmNsnjS>1e|>0>QP_|dVE^S*~Tuq(^|MOJX3KlCp^U{zOaPu^Kjqrtwv>-l$vqb7e<*|u$_HXmz7(> z)p}LDcPX3Hpoxd%s{bWf`3b?M0)Kw&+1x3{+s?BdLnivm634*M-RGGn(f+n$_UL4* zsc*Tp?UkbBs{=+*vrNrir2z)K?UMhe+GY&=O$?$9jl1w9hmh~lQ>|s8uO;b2gVDbopL3F}Wy zkdk<93k`YR>g9F*GX}Ht2noFkR$D6{OAAnpJxoPLLD=aG3R zBNQ2RU$&(^Mv-0BYfu*L=NRwKd5EC12+Cws++%N8T8Z}oXlUWt@UH*Czaht{&@-{ zlBg_wV(R?P+F&G25a!6;cYOVTP*#$Wra zw@42+n_nGkFLp;K6!77_NSe9OdF5tW70nRnvyH0Lsdn3rCOo!TA1u!9NhfGC;-Qd< z<}&4wX4`q{f10||6iX1kB(C!-VWv5~|B%?+J{CWrbR*qYkxiY3xfc#t1M&me)I3#q zxlr-e3dw7YZimJzP8n~{z|u<%gER>Ztp7~ohte1Ve&D=^K;L!cIheM~SZ2=r*bmb5 zzAX5?4N`B!YFCtnNDEgNvD})=f^TgvR@V2f(L78Us>mD4P{-ILxeNH+t<26^6#~Fd0cwKY4Ir@391!@!`b1Y zn!vK>@|3QU7mZ20GU@orgDwz1d1MaQ56-+3d@9G9u3ZIC%v9>3-Amkx7ebrUrdmul zF%nEDz!FgT^5?Md2_N`E$&1_G4qkE7f3l#`Q8*LuQRJ=VuXH5jz&ag?Joxn}+&>Co z`7$39x**l`ej)`|ecTG$lbTQhPm6sy6{CD1$oXNP#=dCRFpyt>%uH~~IG~XslhQ&01o~!zM<=m(`0~E6@pY0*=4hF8|y>E)~P|H==8)w9- z@!;I03Ih+Gx9_CMmpYL*CSjWC-`_q5du zrPk|G>b9exK2kmWIr8N6Hyx=xNP!PY%9OJ;#V;gwI?7QCRU6?b6v(%pq#zPc=3+Q^ z1MkTAQd4spkLC|2pfdY~`e5dhy10(w#M^hGBmE4CDru9Wx5lkrVj&|St5XOQ^_?2U z-Mkt-xXyyMd+4K_FYHexJ9{6)cFwtd&91wtC75>U+B2qzJT~;}zC)(oFEaR?$Y7s3 zQ_V7K^|7OvQjdlT9l~ag)d>=;BY}Sx;u;eQm4lm2YpO@(JZ#SGmrY|vD*r$$X9HjM zQ;Jel<_$z^<=;BG-iO2df!bmB39wKs2ZMB<@NU}dl+zG;9TTq4O61yr_8I)3YN3OEp`%k75tNH{8&*?nHLBdLa1cr3Z>Hi#sMIg%uPua zs4+9JFWp1oQm#;H_@hMtw50yBQ(Pq;s8PSK_llBe_nz}U7rhC#LJ5vJ%CUR)J^^xI z^gTJ;EZsat(+=%V=bdgInBJ##<7YA-@XxIM2K#DKCD2p?4g@lKNC>-Q9RY3YJ_yOR zxTzI!21t*f4CILdXMZYX|MF|m1ZHhW1^7Gt0+7iRvHweu0uTknL)K-JR1GMALhC$3 zlHq&Hz_0olXys3Dto(JICZtRI@5D5}C~xb+{8J50DV=B0;d?)%ye7C--kOrv$}?%SzKgWs1{s^qmU4e{#j5 z|Av|O_ug{k&FxzRPdokb0%(-ff`WmhI4e}BJ4jxf9}=0?>KXNcw_FVay%oYfVswiL zB$z~jHyO}Y?t88V38|_;OH|(RqC&1O4XLFIUga!CkX5}lcr(@tej@WY|4)Bx3H>pw zk1H!Z46|(Bu_H`ji|#3>KW;$Es@kj2xkH2q(7DIy%V1O=OCAlUc_*r^-la;I(9G zNbn9j29`ws8$iURgmASfy8L+5`Cx`0>A7Ge0l2 zU%md)Z(6 z#7^_qTtWBI)+~jM5w6#i10updoY|7+%Z@(sZyUo&zFoWAD}3G zCgTfn2^8#i17N@U&DgKI2PWiE-wB)-x%NG~OMchsh}@zls8`o%?h#QOwWtQoFboS$ zWk}ytb8Y~5)B5d?N`UiPhQt@11$wW`Kr2cWsX^-j#1PG?F$7>eYf`RJ`$&r2E6gm) zob(vj(q1SbKF|zTu!fV3Z9acc^dsAMtw?N(9ERL#{Vh>kwmRN08ISsBcU>nLD z+H3tp-6`^nlcL5ZncR+Oy+u>!eyML?pXQK?^60)B*{`J0 zCb^R{d{~sW=EECtOsG#L^9Am+_p1DM0#(-4ipdrKX;7RG2PXBkwT&0vhB7_LN(Zti z;$nJCli^~VN5*p@bJ3$&b;EhtQfN45&xyt2boAFHtteAt0rwtEbV0T5JgbbP!s8^g zm_mtUuE3Dj^ z1nm7>F!N;hCLOcN?Lk%VFBU#+w+dgr_S}4IxK8E%oY;*sg8F1b+@hzgp1sL`BEE_d zCX*eAvd>hF!><_1vc-2Bh&IuVGW6Iut;w%c7%>OmjFGD_iZ^H~4fZnuTId-%a59D} zT@3{9G2Onu|5~MJ-+lrA4nkxeuD06nrtr-?p)`I9|3`m$OxsrWT21)hRhxP`fDW3%3>(-8cSjWk37(eCCVr{>_TB>Z0|~OVo;Ao5_w5{8|9Xa51=#K{zlVDOY$_vp-gB; z_f_KYaZ8-UEnJm@?@JETV<+w#oFiq&3Y|O?pznWawkesGrc~psMa@e@86=klk7?e>F|SFe?=< zYnJF|ozih6Huzjd^zmuwJL2UX2GjFCA4@P!yt=3x_2%kj3WFnyUpKcT4gP(}Qbgzp zRx#!JA7ZEi#OPn#GO>9x14JG=8TmSnYa-Q5>Q3&h0+=1NqpzTVEkf z<8mF#4D-o~BJXuulV9cC2BX|*4p1R#0~O{F6x@)iut`@{sPIy?aBxU4HetZHsy*q1 zbSwO2Fc*;`!TQ^Lj-9vEdCKS; zG}QJ3;RviYqS>ib=3C*;mG*4Aj~5}o#ZLeg#kGt2UX&}VTY6@hcjN+ai^r2OoRQ=-yG1 zOX?i0b^irJL&hfeB0_6UE;MeBIZg$HidLO{s7YFFD4BLN26T%+aS8PFaPChp_Ao?> z-~<>m`+y^Lbr_Jbn70e~-jMXQ_|mZyjTJ@Cl-FI1BQO9N$llBHh6U3zFFjY;{xs^o zx4+llJ9_e>6rKjDSc31uC@IWk_k9^5s*yPr+62~^S~G+Iqg%Z$vdW`GaE@(Km!W(Q zJdQ-0lw*0#QaLJR?S*B|UuR?bV2xj`<&`;487rRS(!R;rv|^3+Yb4J0YHeZ|skg9E zm#T&YiPjDVeFW?LWXq%w;D`YZLWLDK4m}krHbqJ`fs24Fh~&KV`jBjmmP;WVyR&qj zglI4Zj$@d?IuS(=xj2s%SlW#Uk(-3iyA|Ucq;wqzj|6cVZxXuMu}s#Q{S8DO2&ReU z%q}IY#Kv4F)hk%;XHI-O5>TL$@Oo*6|1!686RkA|dIIxhDAykF8Vubn+EG(Vhnzhd zSSr_#d224(ybj@V?ScG^Z0ewy);uv0ibO?t{~7C2nRH@$sMpP(D!UqH5s%)5xrXxS z6g0u;#DB5AkUyUjLgB`PfvM;xptMFE*kDW1TeYQwIFJ(;pHQrosUJQp(_Hjsz`l`3 zM=N49c6Y8#1C~dI=_#aVS|1cO(Kxd4BVzb& zR0n*SRIqIXTrn28U;=SPmJ@GdMFomZ*1@dp-eNi4;FVift`M)5d|IZOb-Q?q)Qjj% zc^3rYP4&GGjM~m!vK_3%hQ3mhzJ-O0==TGoeCDAeXbx%EXbToHOK)q@MFMOIrug2j z3HS}{VU0U#lqkFzYz|#HUb6H}vkjb~FKMm0lEav)b~?j!9O;|<2TG4`>ZG8=%Qi29 zxA*nR6K0CoREi9}mmy0|rKOOT_;Yf0?DYvT&!uA{{!->SX@ENR11=&{09=f^&J@VT zkm4-nKEraw>NN0V3znSSD(YTE=o0qPRbO%$R7nGHvDxo21Q&%00bHDPZ<_A;0T*9& zb1u7dX9cTs#J;0zF--rAm{Qx19`kiu$~{SUHWm_=;hVtjy+?c;((k!39+IdQ8d53J zrlw9{GkNXaSAW{+nYD7ItTul{&6$!%tRlysI+BmmH`yvw-oCOPFG5w>g(|z@YK@0b zdrM*MxpOy@GI`iZ1j4kA-;U1Qt)Q!Xu)N2JHo4#Xo4-gx>rmP?+`Q#EGN8V-cI z6}G`exFI_!5hG6RL-)e6g>f$v_ddUg8jUMV6SB=<^w2nIi)U6DS}+b3nj9a_<3UTJ zo}7!ittc^~M|AP<@SFxB@(MguNXaRf*O&OpW5kD|BstJZLlf#nZTB~XsoJI`NLvOm zCkE9;Na@lyi8Tk+dQ*;tWWI%;OHpSA$W(ZIe9CEpmp$uq{zV zq@f;PoH|FV-b5qbydBumZs@Zlfj$csFSp0kHdjI6!WvqPk_Bi{lEcgLVq+>78E=b7~hP>mHTzNE`SH?2v=fCd;D$Aa?>it{Ty@(en`SH%(qAb$9;)0Y-@b_%gN_**0iSJGi74gYp9l~}kh42hY!JpNNkAC0)c@TX ze+2^1uYcs)pLq8NEMNisY+20Ib{!f4g};O#QyVrO*4`a!d;ln^^1wSqq4pMPgY%>X zgbg Date: Wed, 25 May 2022 19:19:01 +0000 Subject: [PATCH 007/209] Address comments --- .../custom-resource-definition-versioning.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md index 28757ffd84..730a0fd688 100644 --- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md @@ -355,11 +355,8 @@ spec: ### Version removal -An API version can be removed if there is a newer API version served and stored in the API server for at least 3 Kubernetes releases. -The older API version cannot be dropped from the CRD manifest until data has been migrated to the newer API version for all clusters that served the older version of the CRD and cleared the older version from status.storedVersions. +An older API version cannot be dropped from a CustomResourceDefinition manifest until existing persisted data has been migrated to the newer API version for all clusters that served the older version of the custom resource, and the old version is removed from the `status.storedVersions` of the CustomResourceDefinition. -{{< tabs name="CustomResourceDefinition_versioning_removal" >}} -{{% tab name="apiextensions.k8s.io/v1" %}} ```yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition @@ -373,12 +370,13 @@ spec: scope: Namespaced versions: - name: v1beta1 - served: false # This indicates the v1beta1 version of the custom resource is no longer served. # API requests to this version receive a not found error in the server response. + served: false schema: ... - name: v1 served: true + # The new served version should be set as the storage version storage: true schema: ... ``` From 460a86b59a6d6df9b70700e25b4fb768079b5ff5 Mon Sep 17 00:00:00 2001 From: Daniel Wright Date: Mon, 13 Jun 2022 08:16:25 +1000 Subject: [PATCH 008/209] [es] update es docs to use recommended labels --- .../concepts/services-networking/service.md | 48 +++++++++---------- .../workloads/pods/init-containers.md | 4 +- 2 files changed, 26 insertions(+), 26 deletions(-) diff --git a/content/es/docs/concepts/services-networking/service.md b/content/es/docs/concepts/services-networking/service.md index 5ef231df3a..7329aa1075 100644 --- a/content/es/docs/concepts/services-networking/service.md +++ b/content/es/docs/concepts/services-networking/service.md @@ -54,7 +54,7 @@ Para aplicaciones no nativas, Kubernetes ofrece una manera de colocar un puerto Un Service en Kubernetes es un objeto REST, similar a un Pod. Como todos los objetos REST, puedes hacer un `Post` a una definición de un Service al servidor API para crear una nueva instancia. EL nombre de un objeto Service debe ser un [nombre RFC 1035 válido](/docs/concepts/overview/working-with-objects/names#rfc-1035-label-names). -Por ejemplo, supongamos que tienes un conjunto de Pods en el que cada uno escucha el puerto TCP 9376 y contiene la etiqueta `app=MyApp`: +Por ejemplo, supongamos que tienes un conjunto de Pods en el que cada uno escucha el puerto TCP 9376 y contiene la etiqueta `app.kubernetes.io/name=MyApp`: ```yaml apiVersion: v1 @@ -63,14 +63,14 @@ metadata: name: mi-servicio spec: selector: - app: MyApp + app.kubernetes.io/name: MyApp ports: - protocol: TCP port: 80 targetPort: 9376 ``` -Esta especificación crea un nuevo objeto Service llamado "mi-servicio", que apunta via TCP al puerto 9376 de cualquier Pod con la etiqueta `app=MyApp`. +Esta especificación crea un nuevo objeto Service llamado "mi-servicio", que apunta via TCP al puerto 9376 de cualquier Pod con la etiqueta `app.kubernetes.io/name=MyApp`. Kubernetes asigna una dirección IP a este Service (Algunas veces llamado "Cluster IP"), la cual es usada por los proxies de los Services (mira [IPs Virtuales y proxies de servicios](#virtual-ips-and-service-proxies) abajo). @@ -297,7 +297,7 @@ spec: {{< note >}} Como con los {{< glossary_tooltip term_id="name" text="nombres">}} de Kubernetes en general, los nombres para los puertos deben contener alfanuméricos en minúsculas y `-`. Los nombres de puertos deben comenzar y terminar con un carácter alfanumérico. -Por ejemplo, los nombres `123-abc` and `web` son válidos, pero `123_abc` y `-web` no lo son. +Por ejemplo, los nombres `123-abc` and `web` son válidos, pero `123_abc` y `-web` no lo son. {{< /note >}} ## Eligiendo tu propia dirección IP @@ -799,11 +799,11 @@ NLB solo funciona con ciertas clases de instancias; mira la [documentación AWS] A diferencia de los balanceadores de cargas, el balanceador de carga de red (NLB) reenvía la dirección IP del cliente a través del nodo. Si el campo `.spec.externalTrafficPolicy` está fijado a `clúster`, la dirección IP del cliente no es propagada a los Pods finales. Al fijar `.spec.externalTrafficPolicy` en `Local`, la dirección IP del cliente se propaga a los Pods finales, -pero esto puede resultar a una distribución de tráfico desigual. Los nodos sin ningún Pod para un Service particular de tipo LoadBalancer fallarán en la comprobación de estado del grupo objetivo del NLB en el puerto `.spec.healthCheckNodePort` y no recibirán ningún tráfico. +pero esto puede resultar a una distribución de tráfico desigual. Los nodos sin ningún Pod para un Service particular de tipo LoadBalancer fallarán en la comprobación de estado del grupo objetivo del NLB en el puerto `.spec.healthCheckNodePort` y no recibirán ningún tráfico. -Para conseguir trafico equilibrado, usa un DaemonSet o especifica [pod anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) para no localizar en el mismo nodo. +Para conseguir trafico equilibrado, usa un DaemonSet o especifica [pod anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) para no localizar en el mismo nodo. -También puedes usar Services NLB con la anotación del [balanceador de carga interno](/docs/concepts/services-networking/service/#internal-load-balancer) +También puedes usar Services NLB con la anotación del [balanceador de carga interno](/docs/concepts/services-networking/service/#internal-load-balancer) Para permitir que el tráfico del cliente alcance las instancias detrás del NLB, los grupos de seguridad del Nodo se modifican con las siguientes reglas de IP: @@ -822,7 +822,7 @@ spec: ``` {{< note >}} -Si no se establece `.spec.loadBalancerSourceRanges`, Kubernetes permite el tráfico +Si no se establece `.spec.loadBalancerSourceRanges`, Kubernetes permite el tráfico desde `0.0.0.0/0` a los Grupos de Seguridad del Nodo. Si los nodos tienen direcciones IP públicas, ten en cuenta que el tráfico que no viene del NLB también puede alcanzar todas las instancias en esos grupos de seguridad modificados. {{< /note >}} @@ -865,9 +865,9 @@ Hay otras anotaciones para administrar balanceadores de carga en la nube en TKE ### Tipo ExternalName {#externalname} -Los Services de tipo ExternalName mapean un Service a un nombre DNS, no a un selector típico como `mi-servicio` o `cassandra`. Estos Services se especifican con el parámetro `spec.externalName`. +Los Services de tipo ExternalName mapean un Service a un nombre DNS, no a un selector típico como `mi-servicio` o `cassandra`. Estos Services se especifican con el parámetro `spec.externalName`. -Esta definición de Service, por ejemplo, mapea el Service `mi-Servicio` en el namespace `prod` a `my.database.example.com`: +Esta definición de Service, por ejemplo, mapea el Service `mi-Servicio` en el namespace `prod` a `my.database.example.com`: ```yaml apiVersion: v1 @@ -884,7 +884,7 @@ spec: ExternalName acepta una cadena de texto IPv4, pero como un nombre DNS compuesto de dígitos, no como una dirección IP. ExternalNames que se parecen a direcciones IPv4 no se resuelven por el CoreDNS o ingress-nginx, ya que ExternalName se usa para especificar un nombre DNS canónico. Al fijar una dirección IP, considera usar [headless Services](#headless-services). {{< /note >}} -Cuando busca el host `mi-servicio.prod.svc.cluster.local`, el Service DNS del clúster devuelve un registro `CNAME` con el valor `my.database.example.com`. Acceder a `mi-servicio` funciona de la misma manera que otros Services, pero con la diferencia crucial de que la redirección ocurre a nivel del DNS en lugar reenviarlo o redirigirlo. Si posteriormente decides mover tu base de datos al clúster, puedes iniciar sus Pods, agregar selectores apropiados o endpoints, y cambiar el `type` del Service. +Cuando busca el host `mi-servicio.prod.svc.cluster.local`, el Service DNS del clúster devuelve un registro `CNAME` con el valor `my.database.example.com`. Acceder a `mi-servicio` funciona de la misma manera que otros Services, pero con la diferencia crucial de que la redirección ocurre a nivel del DNS en lugar reenviarlo o redirigirlo. Si posteriormente decides mover tu base de datos al clúster, puedes iniciar sus Pods, agregar selectores apropiados o endpoints, y cambiar el `type` del Service. {{< warning >}} @@ -894,15 +894,15 @@ Para protocolos que usan el nombre del host esta diferencia puede llevar a error {{< /warning >}} {{< note >}} -Esta sección está en deuda con el artículo de blog [Kubernetes Tips - Part 1](https://akomljen.com/kubernetes-tips-part-1/) de [Alen Komljen](https://akomljen.com/). +Esta sección está en deuda con el artículo de blog [Kubernetes Tips - Part 1](https://akomljen.com/kubernetes-tips-part-1/) de [Alen Komljen](https://akomljen.com/). {{< /note >}} ### IPs Externas -Si existen IPs externas que enrutan hacia uno o más nodos del clúster, los Services de Kubernetes pueden ser expuestos en esas `externalIPs`. El tráfico que ingresa al clúster con la IP externa (como IP de destino), en el puerto del Service, será enrutado a uno de estos endpoints del Service. Las `externalIPs` no son administradas por Kubernetes y son responsabilidad del administrador del clúster. +Si existen IPs externas que enrutan hacia uno o más nodos del clúster, los Services de Kubernetes pueden ser expuestos en esas `externalIPs`. El tráfico que ingresa al clúster con la IP externa (como IP de destino), en el puerto del Service, será enrutado a uno de estos endpoints del Service. Las `externalIPs` no son administradas por Kubernetes y son responsabilidad del administrador del clúster. En la especificación del Service, las `externalIPs` se pueden especificar junto con cualquiera de los `ServiceTypes`. -En el ejemplo de abajo, "`mi-servicio`" puede ser accedido por clientes en "`80.11.12.10:80`" (`externalIP:port`) +En el ejemplo de abajo, "`mi-servicio`" puede ser accedido por clientes en "`80.11.12.10:80`" (`externalIP:port`) ```yaml apiVersion: v1 @@ -911,7 +911,7 @@ metadata: name: mi-servicio spec: selector: - app: MyApp + app.kubernetes.io/name: MyApp ports: - name: http protocol: TCP @@ -925,21 +925,21 @@ spec: Usar el proxy del userspace for VIPs funciona en pequeña y mediana escala, pero no escalará a clústeres muy grandes con miles de Services. El tópico [original design proposal for portals](https://github.com/kubernetes/kubernetes/issues/1107) tiene más detalles sobre esto. -Usar el proxy del userspace oculta la dirección IP de origen de un paquete que accede al Service. Esto hace que algún tipo de filtrado (firewalling) sea imposible. El modo proxy iptables no oculta IPs de origen en el clúster, pero aún tiene impacto en clientes que vienen desde un balanceador de carga o un node-port. +Usar el proxy del userspace oculta la dirección IP de origen de un paquete que accede al Service. Esto hace que algún tipo de filtrado (firewalling) sea imposible. El modo proxy iptables no oculta IPs de origen en el clúster, pero aún tiene impacto en clientes que vienen desde un balanceador de carga o un node-port. -El campo `Type` está diseñado como una funcionalidad anidada - cada nivel se agrega al anterior. Esto no es estrictamente requerido en todos los proveedores de la nube (ej. Google Compute Engine no necesita asignar un `NodePort` para que funcione el `LoadBalancer`, pero AWS si) pero la API actual lo requiere. +El campo `Type` está diseñado como una funcionalidad anidada - cada nivel se agrega al anterior. Esto no es estrictamente requerido en todos los proveedores de la nube (ej. Google Compute Engine no necesita asignar un `NodePort` para que funcione el `LoadBalancer`, pero AWS si) pero la API actual lo requiere. ## Implementación de IP Virtual {#the-gory-details-of-virtual-ips} La información previa sería suficiente para muchas personas que quieren usar Services. Sin embargo, ocurren muchas cosas detrás de bastidores que valdría la pena entender. -### Evitar colisiones +### Evitar colisiones Una de las principales filosofías de Kubernetes es que no debe estar expuesto a situaciones que podrían hacer que sus acciones fracasen por su propia culpa. Para el diseño del recurso de Service, esto significa no obligarlo a elegir su propio número de puerto si esa elección puede colisionar con la de otra persona. Eso es un fracaso de aislamiento. Para permitirte elegir un número de puerto en tus Services, debemos asegurarnos que dos Services no puedan colisionar. Kubernetes lo hace asignando a cada Service su propia dirección IP. -Para asegurarse que cada Service recibe una IP única, un asignador interno actualiza atómicamente el mapa global de asignaciones en {{< glossary_tooltip term_id="etcd" >}} antes de crear cada Service. El objeto mapa debe existir en el registro para que los Services obtengan asignaciones de dirección IP, de lo contrario las creaciones fallarán con un mensaje indicando que la dirección IP no pudo ser asignada. +Para asegurarse que cada Service recibe una IP única, un asignador interno actualiza atómicamente el mapa global de asignaciones en {{< glossary_tooltip term_id="etcd" >}} antes de crear cada Service. El objeto mapa debe existir en el registro para que los Services obtengan asignaciones de dirección IP, de lo contrario las creaciones fallarán con un mensaje indicando que la dirección IP no pudo ser asignada. En el plano de control, un controlador de trasfondo es responsable de crear el mapa (requerido para soportar la migración desde versiones más antiguas de Kubernetes que usaban bloqueo en memoria). Kubernetes también utiliza controladores para revisar asignaciones inválidas (ej. debido a la intervención de un administrador) y para limpiar las direcciones IP que ya no son usadas por ningún Service. @@ -947,7 +947,7 @@ En el plano de control, un controlador de trasfondo es responsable de crear el m A diferencia de direcciones IP del Pod, que enrutan a un destino fijo, las IPs del Service no son respondidas por ningún host. En lugar de ello, El kube-proxy usa iptables (lógica de procesamiento de paquetes en Linux) para definir direcciones IP _virtuales_ que se redirigen de forma transparente cuando se necesita. Cuando el cliente se conecta con la VIP, su tráfico es transportado automáticamente al endpoint apropiado. Las variables de entorno y DNS para los Services son pobladas en términos de la dirección IP virtual del Service (y el puerto). -Kube-proxy soporta tres modos — userspace, iptables e IPVS — los cuales operan ligeramente diferente cada uno. +Kube-proxy soporta tres modos — userspace, iptables e IPVS — los cuales operan ligeramente diferente cada uno. #### Userspace @@ -955,11 +955,11 @@ Por ejemplo, considera la aplicación de procesamiento de imágenes descrita arr Cuando un cliente se conecta a la dirección IP virtual del Service, la regla de iptables entra en acción, y redirige los paquetes al propio puerto del proxy. El "proxy del Service" elige un backend, y comienza a redirigir el tráfico desde el cliente al backend. -Esto quiere decir que los dueños del Service pueden elegir cualquier puerto que quieran sin riesgo de colisión. Los clientes pueden conectarse a una IP y un puerto, sin estar conscientes de a cuáles Pods están accediendo. +Esto quiere decir que los dueños del Service pueden elegir cualquier puerto que quieran sin riesgo de colisión. Los clientes pueden conectarse a una IP y un puerto, sin estar conscientes de a cuáles Pods están accediendo. #### iptables -Nuevamente, considera la aplicación de procesamiento de imágenes descrita arriba. Cuando se crea el Service Backend, el plano de control de Kubernetes asigna una dirección IP virtual, por ejemplo 10.0.0.1. Asumiendo que el puerto del servicio es 1234, el Service es observado por todas las instancias del kube-proxy en el clúster. Cuando un proxy mira un nuevo Service, instala una serie de reglas de iptables que redirigen desde la dirección IP virtual a las reglas del Service. Las reglas del Service enlazan a las reglas del Endpoint que redirigen el tráfico (usando NAT de destino) a los backends. +Nuevamente, considera la aplicación de procesamiento de imágenes descrita arriba. Cuando se crea el Service Backend, el plano de control de Kubernetes asigna una dirección IP virtual, por ejemplo 10.0.0.1. Asumiendo que el puerto del servicio es 1234, el Service es observado por todas las instancias del kube-proxy en el clúster. Cuando un proxy mira un nuevo Service, instala una serie de reglas de iptables que redirigen desde la dirección IP virtual a las reglas del Service. Las reglas del Service enlazan a las reglas del Endpoint que redirigen el tráfico (usando NAT de destino) a los backends. Cuando un cliente se conecta a la dirección IP virtual del Service la regla de iptables son aplicadas. A diferencia del modo proxy userspace, el kube-proxy no tiene que estar corriendo para que funcione la dirección IP virtual, y los nodos observan el tráfico que viene desde la dirección IP del cliente sin alteraciones. @@ -1014,11 +1014,11 @@ El kube-proxy no soporta la administración de asociaciones SCTP cuando está en Si tu proveedor de la nube lo soporta, puedes usar un Service en modo LoadBalancer para configurar un proxy invertido HTTP/HTTPS, redirigido a los Endpoints del Service. {{< note >}} -También puedes usar {{< glossary_tooltip term_id="ingress" >}} en lugar de un Service para exponer Services HTTP/HTTPS. +También puedes usar {{< glossary_tooltip term_id="ingress" >}} en lugar de un Service para exponer Services HTTP/HTTPS. {{< /note >}} ### Protocolo PROXY -Si tu proveedor de la nube lo soporta, puedes usar un Service en modo LoadBalancer para configurar un balanceador de carga fuera de Kubernetes mismo, que redirigirá las conexiones prefijadas con [protocolo PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt). +Si tu proveedor de la nube lo soporta, puedes usar un Service en modo LoadBalancer para configurar un balanceador de carga fuera de Kubernetes mismo, que redirigirá las conexiones prefijadas con [protocolo PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt). El balanceador de carga enviará una serie inicial de octetos describiendo la conexión entrante, similar a este ejemplo diff --git a/content/es/docs/concepts/workloads/pods/init-containers.md b/content/es/docs/concepts/workloads/pods/init-containers.md index fafb6ae2f6..2ae5323771 100644 --- a/content/es/docs/concepts/workloads/pods/init-containers.md +++ b/content/es/docs/concepts/workloads/pods/init-containers.md @@ -113,7 +113,7 @@ kind: Pod metadata: name: myapp-pod labels: - app: myapp + app.kubernetes.io/name: MyApp spec: containers: - name: myapp-container @@ -165,7 +165,7 @@ El resultado es similar a esto: Name: myapp-pod Namespace: default [...] -Labels: app=myapp +Labels: app.kubernetes.io/name=MyApp Status: Pending [...] Init Containers: From d06462b87f2d798aabf90a112d3c24472bca6989 Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" Date: Wed, 15 Jun 2022 11:12:20 -0300 Subject: [PATCH 009/209] Update title --- content/pt-br/docs/reference/glossary/cluster-infrastructure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt-br/docs/reference/glossary/cluster-infrastructure.md b/content/pt-br/docs/reference/glossary/cluster-infrastructure.md index 44a6e9f156..a65f04a346 100644 --- a/content/pt-br/docs/reference/glossary/cluster-infrastructure.md +++ b/content/pt-br/docs/reference/glossary/cluster-infrastructure.md @@ -1,5 +1,5 @@ --- -title: infraestrutura de Cluster +title: Infraestrutura de Cluster id: cluster-infrastructure date: 2019-05-12 full_link: From 8e1c4e4c8052f7bfc1d15c95c6ebb32886aa9eb9 Mon Sep 17 00:00:00 2001 From: HeGaoYuan Date: Thu, 16 Jun 2022 22:39:29 +0800 Subject: [PATCH 010/209] Update topology-manager.md --- content/zh-cn/docs/tasks/administer-cluster/topology-manager.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh-cn/docs/tasks/administer-cluster/topology-manager.md b/content/zh-cn/docs/tasks/administer-cluster/topology-manager.md index c01fb50f4b..0189c239b1 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/topology-manager.md +++ b/content/zh-cn/docs/tasks/administer-cluster/topology-manager.md @@ -324,7 +324,7 @@ Topology Manager will reject this pod from the node. This will result in a pod i ### restricted 策略 {#policy-restricted} 对于 Pod 中的每个容器，配置了 `restricted` 拓扑管理策略的 kubelet -调用每个建议提供者以确定其资源可用性。。 +调用每个建议提供者以确定其资源可用性。 使用此信息，拓扑管理器存储该容器的首选 NUMA 节点亲和性。 如果亲和性不是首选，则拓扑管理器将从节点中拒绝此 Pod。 这将导致 Pod 处于 `Terminated` 状态，且 Pod 无法被节点接纳。 From 6b8ac48f299206338fcb277a098baf528b99b494 Mon Sep 17 00:00:00 2001 From: ystkfujii <76274657+ystkfujii@users.noreply.github.com> Date: Fri, 17 Jun 2022 12:32:13 +0900 Subject: [PATCH 011/209] [ja] Fix a typo in concepts/security/overview.md --- content/ja/docs/concepts/security/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/security/overview.md b/content/ja/docs/concepts/security/overview.md index 3cb67943f6..f1bb1fed43 100644 --- a/content/ja/docs/concepts/security/overview.md +++ b/content/ja/docs/concepts/security/overview.md @@ -125,7 +125,7 @@ TLS経由のアクセスのみ | コードがTCP通信を必要とする場合 関連するKubernetesセキュリティについて学びます。 * [Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards/) -* [Podのネットワークポリシー]](/ja/docs/concepts/services-networking/network-policies/) +* [Podのネットワークポリシー](/ja/docs/concepts/services-networking/network-policies/) * [Kubernetes APIへのアクセスを制御する](/docs/concepts/security/controlling-access) * [クラスターの保護](/docs/tasks/administer-cluster/securing-a-cluster/) * コントロールプレーンとの[通信時のデータ暗号化](/docs/tasks/tls/managing-tls-in-a-cluster/) From 7add5521749ef0f7d0a3a64593ace159f37d46c8 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 18 Jun 2022 13:37:13 +0800 Subject: [PATCH 012/209] Batch fixes for links (1) There are dangling links or links that redirects to a different destination page. This PR fixes some of them. --- content/en/docs/setup/_index.md | 3 +- .../migrating-from-dockershim/_index.md | 2 +- .../migrate-from-psp.md | 2 +- .../docs/tasks/debug/debug-cluster/_index.md | 109 ++++++++------- .../docs/tasks/debug/debug-cluster/windows.md | 17 ++- .../custom-resource-definitions.md | 125 ++++++++++++------ .../job/automated-tasks-with-cron-jobs.md | 30 +++-- .../tls/manual-rotation-of-ca-certificates.md | 2 +- 8 files changed, 181 insertions(+), 109 deletions(-) diff --git a/content/en/docs/setup/_index.md b/content/en/docs/setup/_index.md index adc7304033..ba9b3c6785 100644 --- a/content/en/docs/setup/_index.md +++ b/content/en/docs/setup/_index.md @@ -67,4 +67,5 @@ for deploying Kubernetes is [kubeadm](/docs/setup/production-environment/tools/k Kubernetes is designed for its {{< glossary_tooltip term_id="control-plane" text="control plane" >}} to run on Linux. Within your cluster you can run applications on Linux or other operating systems, including Windows. -- Learn to [set up clusters with Windows nodes](/docs/setup/production-environment/windows/) + +- Learn to [set up clusters with Windows nodes](/docs/concepts/windows/) diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md index ef046077a8..b10f75dd9c 100644 --- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md +++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md @@ -29,7 +29,7 @@ configuration. These tasks will help you to migrate: -* [Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) +* [Check whether Dockershim removal affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) * [Migrate Docker Engine nodes from dockershim to cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/) * [Migrating telemetry and security agents from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/) diff --git a/content/en/docs/tasks/configure-pod-container/migrate-from-psp.md b/content/en/docs/tasks/configure-pod-container/migrate-from-psp.md index 1879ba5ba7..f7d78ea13e 100644 --- a/content/en/docs/tasks/configure-pod-container/migrate-from-psp.md +++ b/content/en/docs/tasks/configure-pod-container/migrate-from-psp.md @@ -323,7 +323,7 @@ configuration of the API server: To verify that the PodSecurityPolicy admission controller is no longer enabled, you can manually run a test by impersonating a user without access to any PodSecurityPolicies (see the -[PodSecurityPolicy example](/docs/concepts/policy/pod-security-policy/#example)), or by verifying in +[PodSecurityPolicy example](/docs/concepts/security/pod-security-policy/#example)), or by verifying in the API server logs. At startup, the API server outputs log lines listing the loaded admission controller plugins: diff --git a/content/en/docs/tasks/debug/debug-cluster/_index.md b/content/en/docs/tasks/debug/debug-cluster/_index.md index 9c0ad56a4c..29fb9a06ae 100644 --- a/content/en/docs/tasks/debug/debug-cluster/_index.md +++ b/content/en/docs/tasks/debug/debug-cluster/_index.md @@ -36,7 +36,13 @@ kubectl cluster-info dump ### Example: debugging a down/unreachable node -Sometimes when debugging it can be useful to look at the status of a node -- for example, because you've noticed strange behavior of a Pod that's running on the node, or to find out why a Pod won't schedule onto the node. As with Pods, you can use `kubectl describe node` and `kubectl get node -o yaml` to retrieve detailed information about nodes. For example, here's what you'll see if a node is down (disconnected from the network, or kubelet dies and won't restart, etc.). Notice the events that show the node is NotReady, and also notice that the pods are no longer running (they are evicted after five minutes of NotReady status). +Sometimes when debugging it can be useful to look at the status of a node -- for example, because +you've noticed strange behavior of a Pod that's running on the node, or to find out why a Pod +won't schedule onto the node. As with Pods, you can use `kubectl describe node` and `kubectl get +node -o yaml` to retrieve detailed information about nodes. For example, here's what you'll see if +a node is down (disconnected from the network, or kubelet dies and won't restart, etc.). Notice +the events that show the node is NotReady, and also notice that the pods are no longer running +(they are evicted after five minutes of NotReady status). ```shell kubectl get nodes @@ -222,14 +228,16 @@ of the relevant log files. On systemd-based systems, you may need to use `journ ### Control Plane nodes - * `/var/log/kube-apiserver.log` - API Server, responsible for serving the API - * `/var/log/kube-scheduler.log` - Scheduler, responsible for making scheduling decisions - * `/var/log/kube-controller-manager.log` - a component that runs most Kubernetes built-in {{}}, with the notable exception of scheduling (the kube-scheduler handles scheduling). +* `/var/log/kube-apiserver.log` - API Server, responsible for serving the API +* `/var/log/kube-scheduler.log` - Scheduler, responsible for making scheduling decisions +* `/var/log/kube-controller-manager.log` - a component that runs most Kubernetes built-in + {{}}, with the notable exception of scheduling + (the kube-scheduler handles scheduling). ### Worker Nodes - * `/var/log/kubelet.log` - logs from the kubelet, responsible for running containers on the node - * `/var/log/kube-proxy.log` - logs from `kube-proxy`, which is responsible for directing traffic to Service endpoints +* `/var/log/kubelet.log` - logs from the kubelet, responsible for running containers on the node +* `/var/log/kube-proxy.log` - logs from `kube-proxy`, which is responsible for directing traffic to Service endpoints ## Cluster failure modes @@ -237,45 +245,46 @@ This is an incomplete list of things that could go wrong, and how to adjust your ### Contributing causes - - VM(s) shutdown - - Network partition within cluster, or between cluster and users - - Crashes in Kubernetes software - - Data loss or unavailability of persistent storage (e.g. GCE PD or AWS EBS volume) - - Operator error, for example misconfigured Kubernetes software or application software +- VM(s) shutdown +- Network partition within cluster, or between cluster and users +- Crashes in Kubernetes software +- Data loss or unavailability of persistent storage (e.g. GCE PD or AWS EBS volume) +- Operator error, for example misconfigured Kubernetes software or application software ### Specific scenarios - - API server VM shutdown or apiserver crashing - - Results - - unable to stop, update, or start new pods, services, replication controller - - existing pods and services should continue to work normally, unless they depend on the Kubernetes API - - API server backing storage lost - - Results - - the kube-apiserver component fails to start successfully and become healthy - - kubelets will not be able to reach it but will continue to run the same pods and provide the same service proxying - - manual recovery or recreation of apiserver state necessary before apiserver is restarted - - Supporting services (node controller, replication controller manager, scheduler, etc) VM shutdown or crashes - - currently those are colocated with the apiserver, and their unavailability has similar consequences as apiserver - - in future, these will be replicated as well and may not be co-located - - they do not have their own persistent state - - Individual node (VM or physical machine) shuts down - - Results - - pods on that Node stop running - - Network partition - - Results - - partition A thinks the nodes in partition B are down; partition B thinks the apiserver is down. (Assuming the master VM ends up in partition A.) - - Kubelet software fault - - Results - - crashing kubelet cannot start new pods on the node - - kubelet might delete the pods or not - - node marked unhealthy - - replication controllers start new pods elsewhere - - Cluster operator error - - Results - - loss of pods, services, etc - - lost of apiserver backing store - - users unable to read API - - etc. +- API server VM shutdown or apiserver crashing + - Results + - unable to stop, update, or start new pods, services, replication controller + - existing pods and services should continue to work normally, unless they depend on the Kubernetes API +- API server backing storage lost + - Results + - the kube-apiserver component fails to start successfully and become healthy + - kubelets will not be able to reach it but will continue to run the same pods and provide the same service proxying + - manual recovery or recreation of apiserver state necessary before apiserver is restarted +- Supporting services (node controller, replication controller manager, scheduler, etc) VM shutdown or crashes + - currently those are colocated with the apiserver, and their unavailability has similar consequences as apiserver + - in future, these will be replicated as well and may not be co-located + - they do not have their own persistent state +- Individual node (VM or physical machine) shuts down + - Results + - pods on that Node stop running +- Network partition + - Results + - partition A thinks the nodes in partition B are down; partition B thinks the apiserver is down. + (Assuming the master VM ends up in partition A.) +- Kubelet software fault + - Results + - crashing kubelet cannot start new pods on the node + - kubelet might delete the pods or not + - node marked unhealthy + - replication controllers start new pods elsewhere +- Cluster operator error + - Results + - loss of pods, services, etc + - lost of apiserver backing store + - users unable to read API + - etc. ### Mitigations @@ -308,9 +317,13 @@ This is an incomplete list of things that could go wrong, and how to adjust your ## {{% heading "whatsnext" %}} -* Learn about the metrics available in the [Resource Metrics Pipeline](resource-metrics-pipeline) -* Discover additional tools for [monitoring resource usage](resource-usage-monitoring) -* Use Node Problem Detector to [monitor node health](monitor-node-health) -* Use `crictl` to [debug Kubernetes nodes](crictl) -* Get more information about [Kubernetes auditing](audit) -* Use `telepresence` to [develop and debug services locally](local-debugging) +* Learn about the metrics available in the + [Resource Metrics Pipeline](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/) +* Discover additional tools for + [monitoring resource usage](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) +* Use Node Problem Detector to + [monitor node health](/docs/tasks/debug/debug-cluster/monitor-node-health/) +* Use `crictl` to [debug Kubernetes nodes](/docs/tasks/debug/debug-cluster/crictl/) +* Get more information about [Kubernetes auditing](/docs/tasks/debug/debug-cluster/audit/) +* Use `telepresence` to [develop and debug services locally](/docs/tasks/debug/debug-cluster/local-debugging/) + diff --git a/content/en/docs/tasks/debug/debug-cluster/windows.md b/content/en/docs/tasks/debug/debug-cluster/windows.md index 095fdb9571..c3a06faf16 100644 --- a/content/en/docs/tasks/debug/debug-cluster/windows.md +++ b/content/en/docs/tasks/debug/debug-cluster/windows.md @@ -17,7 +17,7 @@ content_type: concept 1. My Pods are stuck at "Container Creating" or restarting over and over Ensure that your pause image is compatible with your Windows OS version. - See [Pause container](/docs/setup/production-environment/windows/intro-windows-in-kubernetes#pause-container) + See [Pause container](/docs/concepts/windows/intro/#pause-container) to see the latest / recommended pause image and/or get more information. {{< note >}} @@ -32,7 +32,7 @@ content_type: concept Windows Node. More information on how to specify a compatible node for your Pod can be found in - [this guide](/docs/setup/production-environment/windows/user-guide-windows-containers/#ensuring-os-specific-workloads-land-on-the-appropriate-container-host). + [this guide](/docs/concepts/windows/user-guide/#ensuring-os-specific-workloads-land-on-the-appropriate-container-host). ## Network troubleshooting {#troubleshooting-network} @@ -102,8 +102,8 @@ content_type: concept Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*" ``` - Often it is worthwhile to modify the [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) parameter of the `start.ps1` script, - in cases where the host's network adapter isn't "Ethernet". + Often it is worthwhile to modify the [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) + parameter of the `start.ps1` script, in cases where the host's network adapter isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation. 1. DNS resolution is not properly working @@ -112,9 +112,11 @@ content_type: concept 1. `kubectl port-forward` fails with "unable to do port forwarding: wincat not found" - This was implemented in Kubernetes 1.15 by including `wincat.exe` in the pause infrastructure container `mcr.microsoft.com/oss/kubernetes/pause:3.6`. + This was implemented in Kubernetes 1.15 by including `wincat.exe` in the pause infrastructure container + `mcr.microsoft.com/oss/kubernetes/pause:3.6`. Be sure to use a supported version of Kubernetes. - If you would like to build your own pause infrastructure container be sure to include [wincat](https://github.com/kubernetes/kubernetes/tree/master/build/pause/windows/wincat). + If you would like to build your own pause infrastructure container be sure to include + [wincat](https://github.com/kubernetes/kubernetes/tree/master/build/pause/windows/wincat). 1. My Kubernetes installation is failing because my Windows Server node is behind a proxy @@ -170,4 +172,5 @@ If these steps don't resolve your problem, you can get help running Windows cont * StackOverflow [Windows Server Container](https://stackoverflow.com/questions/tagged/windows-server-container) topic * Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes.io/) -* Kubernetes Slack [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows) \ No newline at end of file +* Kubernetes Slack [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows) + diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md index 93fc8266ed..fba91934ca 100644 --- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md @@ -187,7 +187,8 @@ kubectl get crontabs ``` ```none -Error from server (NotFound): Unable to list {"stable.example.com" "v1" "crontabs"}: the server could not find the requested resource (get crontabs.stable.example.com) +Error from server (NotFound): Unable to list {"stable.example.com" "v1" "crontabs"}: the server could not +find the requested resource (get crontabs.stable.example.com) ``` If you later recreate the same CustomResourceDefinition, it will start out empty. @@ -206,22 +207,28 @@ CustomResourceDefinition, the structural schema was optional. A structural schema is an [OpenAPI v3.0 validation schema](#validation) which: -1. specifies a non-empty type (via `type` in OpenAPI) for the root, for each specified field of an object node (via `properties` or `additionalProperties` in OpenAPI) and for each item in an array node (via `items` in OpenAPI), with the exception of: +1. specifies a non-empty type (via `type` in OpenAPI) for the root, for each specified field of an object node + (via `properties` or `additionalProperties` in OpenAPI) and for each item in an array node + (via `items` in OpenAPI), with the exception of: * a node with `x-kubernetes-int-or-string: true` * a node with `x-kubernetes-preserve-unknown-fields: true` -2. for each field in an object and each item in an array which is specified within any of `allOf`, `anyOf`, `oneOf` or `not`, the schema also specifies the field/item outside of those logical junctors (compare example 1 and 2). -3. does not set `description`, `type`, `default`, `additionalProperties`, `nullable` within an `allOf`, `anyOf`, `oneOf` or `not`, with the exception of the two pattern for `x-kubernetes-int-or-string: true` (see below). +2. for each field in an object and each item in an array which is specified within any of `allOf`, `anyOf`, + `oneOf` or `not`, the schema also specifies the field/item outside of those logical junctors (compare example 1 and 2). +3. does not set `description`, `type`, `default`, `additionalProperties`, `nullable` within an `allOf`, `anyOf`, + `oneOf` or `not`, with the exception of the two pattern for `x-kubernetes-int-or-string: true` (see below). 4. if `metadata` is specified, then only restrictions on `metadata.name` and `metadata.generateName` are allowed. - Non-structural example 1: + ```yaml allOf: - properties: foo: ... ``` + conflicts with rule 2. The following would be correct: + ```yaml properties: foo: @@ -313,10 +320,13 @@ Violations of the structural schema rules are reported in the `NonStructural` co ### Field pruning -CustomResourceDefinitions store validated resource data in the cluster's persistence store, {{< glossary_tooltip term_id="etcd" text="etcd">}}. As with native Kubernetes resources such as {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}, if you specify a field that the API server does not recognize, the unknown field is _pruned_ (removed) before being persisted. +CustomResourceDefinitions store validated resource data in the cluster's persistence store, {{< glossary_tooltip term_id="etcd" text="etcd">}}. +As with native Kubernetes resources such as {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}, +if you specify a field that the API server does not recognize, the unknown field is _pruned_ (removed) before being persisted. {{< note >}} -CRDs converted from `apiextensions.k8s.io/v1beta1` to `apiextensions.k8s.io/v1` might lack structural schemas, and `spec.preserveUnknownFields` might be `true`. +CRDs converted from `apiextensions.k8s.io/v1beta1` to `apiextensions.k8s.io/v1` might lack structural schemas, +and `spec.preserveUnknownFields` might be `true`. For legacy CustomResourceDefinition objects created as `apiextensions.k8s.io/v1beta1` with `spec.preserveUnknownFields` set to @@ -376,7 +386,10 @@ to clients, `kubectl` also checks for unknown fields and rejects those objects w #### Controlling pruning -By default, all unspecified fields for a custom resource, across all versions, are pruned. It is possible though to opt-out of that for specifc sub-trees of fields by adding `x-kubernetes-preserve-unknown-fields: true` in the [structural OpenAPI v3 validation schema](#specifying-a-structural-schema). +By default, all unspecified fields for a custom resource, across all versions, are pruned. It is possible though to +opt-out of that for specifc sub-trees of fields by adding `x-kubernetes-preserve-unknown-fields: true` in the +[structural OpenAPI v3 validation schema](#specifying-a-structural-schema). + For example: ```yaml @@ -455,7 +468,8 @@ properties: x-kubernetes-int-or-string: true ``` -Also those nodes are partially excluded from rule 3 in the sense that the following two patterns are allowed (exactly those, without variations in order to additional fields): +Also those nodes are partially excluded from rule 3 in the sense that the following two patterns are allowed +(exactly those, without variations in order to additional fields): ```yaml x-kubernetes-int-or-string: true @@ -488,7 +502,8 @@ RawExtensions (as in `runtime.RawExtension` defined in [k8s.io/apimachinery](https://github.com/kubernetes/apimachinery/blob/03ac7a9ade429d715a1a46ceaa3724c18ebae54f/pkg/runtime/types.go#L94)) holds complete Kubernetes objects, i.e. with `apiVersion` and `kind` fields. -It is possible to specify those embedded objects (both completely without constraints or partially specified) by setting `x-kubernetes-embedded-resource: true`. For example: +It is possible to specify those embedded objects (both completely without constraints or partially specified) +by setting `x-kubernetes-embedded-resource: true`. For example: ```yaml type: object @@ -508,7 +523,8 @@ foo: ... ``` -Because `x-kubernetes-preserve-unknown-fields: true` is specified alongside, nothing is pruned. The use of `x-kubernetes-preserve-unknown-fields: true` is optional though. +Because `x-kubernetes-preserve-unknown-fields: true` is specified alongside, nothing is pruned. +The use of `x-kubernetes-preserve-unknown-fields: true` is optional though. With `x-kubernetes-embedded-resource: true`, the `apiVersion`, `kind` and `metadata` are implicitly specified and validated. @@ -771,6 +787,7 @@ The CronTab "my-new-cron-object" is invalid: The `rule` under `x-kubernetes-validations` represents the expression which will be evaluated by CEL. The `message` represents the message displayed when validation fails. If message is unset, the above response would be: + ``` The CronTab "my-new-cron-object" is invalid: * spec: Invalid value: map[string]interface {}{"maxReplicas":10, "minReplicas":0, "replicas":20}: failed rule: self.replicas <= self.maxReplicas @@ -781,16 +798,19 @@ The request of CRDs create/update will fail if compilation of validation rules f Compilation process includes type checking as well. The compilation failure: + - `no_matching_overload`: this function has no overload for the types of the arguments. - e.g. Rule like `self == true` against a field of integer type will get error: + e.g. Rule like `self == true` against a field of integer type will get error: + ``` Invalid value: apiextensions.ValidationRule{Rule:"self == true", Message:""}: compilation failed: ERROR: \:1:6: found no matching overload for '_==_' applied to '(int, bool)' ``` - `no_such_field`: does not contain the desired field. - e.g. Rule like `self.nonExistingField > 0` against a non-existing field will return the error: + e.g. Rule like `self.nonExistingField > 0` against a non-existing field will return the error: + ``` Invalid value: apiextensions.ValidationRule{Rule:"self.nonExistingField > 0", Message:""}: compilation failed: ERROR: \:1:5: undefined field 'nonExistingField' ``` @@ -798,11 +818,11 @@ The compilation failure: - `invalid argument`: invalid argument to macros. e.g. Rule like `has(self)` will return error: + ``` Invalid value: apiextensions.ValidationRule{Rule:"has(self)", Message:""}: compilation failed: ERROR: :1:4: invalid argument to has() macro ``` - Validation Rules Examples: | Rule | Purpose | @@ -994,16 +1014,18 @@ Here is the declarations type mapping between OpenAPIv3 and CEL type: | 'string' with format=datetime | timestamp (google.protobuf.Timestamp) | | 'string' with format=duration | duration (google.protobuf.Duration) | -xref: [CEL types](https://github.com/google/cel-spec/blob/v0.6.0/doc/langdef.md#values), [OpenAPI -types](https://swagger.io/specification/#data-types), [Kubernetes Structural Schemas](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema). +xref: [CEL types](https://github.com/google/cel-spec/blob/v0.6.0/doc/langdef.md#values), +[OpenAPI types](https://swagger.io/specification/#data-types), +[Kubernetes Structural Schemas](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema). #### Validation functions {#available-validation-functions} Functions available include: - - CEL standard functions, defined in the [list of standard definitions](https://github.com/google/cel-spec/blob/v0.7.0/doc/langdef.md#list-of-standard-definitions) - - CEL standard [macros](https://github.com/google/cel-spec/blob/v0.7.0/doc/langdef.md#macros) - - CEL [extended string function library](https://pkg.go.dev/github.com/google/cel-go@v0.11.2/ext#Strings) - - Kubernetes [CEL extension library](https://pkg.go.dev/k8s.io/apiextensions-apiserver@v0.24.0/pkg/apiserver/schema/cel/library#pkg-functions) + +- CEL standard functions, defined in the [list of standard definitions](https://github.com/google/cel-spec/blob/v0.7.0/doc/langdef.md#list-of-standard-definitions) +- CEL standard [macros](https://github.com/google/cel-spec/blob/v0.7.0/doc/langdef.md#macros) +- CEL [extended string function library](https://pkg.go.dev/github.com/google/cel-go@v0.11.2/ext#Strings) +- Kubernetes [CEL extension library](https://pkg.go.dev/k8s.io/apiextensions-apiserver@v0.24.0/pkg/apiserver/schema/cel/library#pkg-functions) #### Transition rules @@ -1038,7 +1060,8 @@ applied, e.g. "*path*: update rule *rule* cannot be set on schema because the sc schema is not mergeable". Transition rules are only allowed on _correlatable portions_ of a schema. -A portion of the schema is correlatable if all `array` parent schemas are of type `x-kubernetes-list-type=map`; any `set`or `atomic`array parent schemas make it impossible to unambiguously correlate a `self` with `oldSelf`. +A portion of the schema is correlatable if all `array` parent schemas are of type `x-kubernetes-list-type=map`; +any `set`or `atomic`array parent schemas make it impossible to unambiguously correlate a `self` with `oldSelf`. Here are some examples for transition rules: @@ -1070,12 +1093,13 @@ For example, a rule that asserts that `self.foo == 1` does not by itself have an risk of rejection on validation resource budget groups. But if `foo` is a string and you define a validation rule `self.foo.contains("someString")`, that rule takes longer to execute depending on how long `foo` is. -Another example would be if `foo` were an array, and you specified a validation rule `self.foo.all(x, x > 5)`. The cost system always assumes the worst-case scenario if -a limit on the length of `foo` is not given, and this will happen for anything that can be iterated -over (lists, maps, etc.). +Another example would be if `foo` were an array, and you specified a validation rule `self.foo.all(x, x > 5)`. +The cost system always assumes the worst-case scenario if a limit on the length of `foo` is not +given, and this will happen for anything that can be iterated over (lists, maps, etc.). Because of this, it is considered best practice to put a limit via `maxItems`, `maxProperties`, and -`maxLength` for anything that will be processed in a validation rule in order to prevent validation errors during cost estimation. For example, given this schema with one rule: +`maxLength` for anything that will be processed in a validation rule in order to prevent validation +errors during cost estimation. For example, given this schema with one rule: ```yaml openAPIV3Schema: @@ -1090,10 +1114,11 @@ openAPIV3Schema: ``` then the API server rejects this rule on validation budget grounds with error: + ``` - spec.validation.openAPIV3Schema.properties[spec].properties[foo].x-kubernetes-validations[0].rule: Forbidden: - CEL rule exceeded budget by more than 100x (try simplifying the rule, or adding maxItems, maxProperties, and - maxLength where arrays, maps, and strings are used) +spec.validation.openAPIV3Schema.properties[spec].properties[foo].x-kubernetes-validations[0].rule: Forbidden: +CEL rule exceeded budget by more than 100x (try simplifying the rule, or adding maxItems, maxProperties, and +maxLength where arrays, maps, and strings are used) ``` The rejection happens because `self.all` implies calling `contains()` on every string in `foo`, @@ -1136,7 +1161,8 @@ openAPIV3Schema: ``` If a list inside of a list has a validation rule that uses `self.all`, that is significantly more expensive -than a non-nested list with the same rule. A rule that would have been allowed on a non-nested list might need lower limits set on both nested lists in order to be allowed. For example, even without having limits set, +than a non-nested list with the same rule. A rule that would have been allowed on a non-nested list might need +lower limits set on both nested lists in order to be allowed. For example, even without having limits set, the following rule is allowed: ```yaml @@ -1247,15 +1273,20 @@ Defaulting happens on the object * when reading from etcd using the storage version defaults, * after mutating admission plugins with non-empty patches using the admission webhook object version defaults. -Defaults applied when reading data from etcd are not automatically written back to etcd. An update request via the API is required to persist those defaults back into etcd. +Defaults applied when reading data from etcd are not automatically written back to etcd. +An update request via the API is required to persist those defaults back into etcd. Default values must be pruned (with the exception of defaults for `metadata` fields) and must validate against a provided schema. -Default values for `metadata` fields of `x-kubernetes-embedded-resources: true` nodes (or parts of a default value covering `metadata`) are not pruned during CustomResourceDefinition creation, but through the pruning step during handling of requests. +Default values for `metadata` fields of `x-kubernetes-embedded-resources: true` nodes (or parts of +a default value covering `metadata`) are not pruned during CustomResourceDefinition creation, but +through the pruning step during handling of requests. #### Defaulting and Nullable -**New in 1.20:** null values for fields that either don't specify the nullable flag, or give it a `false` value, will be pruned before defaulting happens. If a default is present, it will be applied. When nullable is `true`, null values will be conserved and won't be defaulted. +**New in 1.20:** null values for fields that either don't specify the nullable flag, or give it a +`false` value, will be pruned before defaulting happens. If a default is present, it will be +applied. When nullable is `true`, null values will be conserved and won't be defaulted. For example, given the OpenAPI schema below: @@ -1293,13 +1324,20 @@ spec: bar: null ``` -with `foo` pruned and defaulted because the field is non-nullable, `bar` maintaining the null value due to `nullable: true`, and `baz` pruned because the field is non-nullable and has no default. +with `foo` pruned and defaulted because the field is non-nullable, `bar` maintaining the null +value due to `nullable: true`, and `baz` pruned because the field is non-nullable and has no +default. ### Publish Validation Schema in OpenAPI v2 -CustomResourceDefinition [OpenAPI v3 validation schemas](#validation) which are [structural](#specifying-a-structural-schema) and [enable pruning](#field-pruning) are published as part of the [OpenAPI v2 spec](/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions) from Kubernetes API server. +CustomResourceDefinition [OpenAPI v3 validation schemas](#validation) which are +[structural](#specifying-a-structural-schema) and [enable pruning](#field-pruning) are published +as part of the [OpenAPI v2 spec](/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions) +from Kubernetes API server. -The [kubectl](/docs/reference/kubectl/) command-line tool consumes the published schema to perform client-side validation (`kubectl create` and `kubectl apply`), schema explanation (`kubectl explain`) on custom resources. The published schema can be consumed for other purposes as well, like client generation or documentation. +The [kubectl](/docs/reference/kubectl/) command-line tool consumes the published schema to perform +client-side validation (`kubectl create` and `kubectl apply`), schema explanation (`kubectl explain`) +on custom resources. The published schema can be consumed for other purposes as well, like client generation or documentation. The OpenAPI v3 validation schema is converted to OpenAPI v2 schema, and show up in `definitions` and `paths` fields in the [OpenAPI v2 spec](/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions). @@ -1309,9 +1347,13 @@ kubectl in previous 1.13 version. These modifications prevent kubectl from being valid OpenAPI schemas that it doesn't understand. The conversion won't modify the validation schema defined in CRD, and therefore won't affect [validation](#validation) in the API server. -1. The following fields are removed as they aren't supported by OpenAPI v2 (in future versions OpenAPI v3 will be used without these restrictions) +1. The following fields are removed as they aren't supported by OpenAPI v2 + (in future versions OpenAPI v3 will be used without these restrictions) + - The fields `allOf`, `anyOf`, `oneOf` and `not` are removed -2. If `nullable: true` is set, we drop `type`, `nullable`, `items` and `properties` because OpenAPI v2 is not able to express nullable. To avoid kubectl to reject good objects, this is necessary. + +2. If `nullable: true` is set, we drop `type`, `nullable`, `items` and `properties` because OpenAPI v2 is + not able to express nullable. To avoid kubectl to reject good objects, this is necessary. ### Additional printer columns @@ -1402,7 +1444,8 @@ differentiates between columns shown in standard view or wide view (using the `- #### Type -A column's `type` field can be any of the following (compare [OpenAPI v3 data types](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#dataTypes)): +A column's `type` field can be any of the following (compare +[OpenAPI v3 data types](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#dataTypes)): - `integer` – non-floating-point numbers - `number` – floating point numbers @@ -1495,8 +1538,9 @@ the status replica value in the `/scale` subresource will default to 0. - It must be set to work with HPA. - Only JSONPaths under `.status` or `.spec` and with the dot notation are allowed. - If there is no value under the `labelSelectorPath` in the custom resource, -the status selector value in the `/scale` subresource will default to the empty string. - - The field pointed by this JSON path must be a string field (not a complex selector struct) which contains a serialized label selector in string form. + the status selector value in the `/scale` subresource will default to the empty string. + - The field pointed by this JSON path must be a string field (not a complex selector struct) + which contains a serialized label selector in string form. In the following example, both status and scale subresources are enabled. @@ -1703,3 +1747,4 @@ crontabs/my-new-cron-object 3s * Serve [multiple versions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/) of a CustomResourceDefinition. + diff --git a/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md index e37e5b6569..e99ea5473c 100644 --- a/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md +++ b/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md @@ -13,7 +13,8 @@ CronJobs was promoted to general availability in Kubernetes v1.21. If you are us Kubernetes, please refer to the documentation for the version of Kubernetes that you are using, so that you see accurate information. Older Kubernetes versions do not support the `batch/v1` CronJob API. -You can use a {{< glossary_tooltip text="CronJob" term_id="cronjob" >}} to run {{< glossary_tooltip text="Jobs" term_id="job" >}} on a time-based schedule. +You can use a {{< glossary_tooltip text="CronJob" term_id="cronjob" >}} to run {{< glossary_tooltip text="Jobs" term_id="job" >}} +on a time-based schedule. These automated jobs run like [Cron](https://en.wikipedia.org/wiki/Cron) tasks on a Linux or UNIX system. Cron jobs are useful for creating periodic and recurring tasks, like running backups or sending emails. @@ -87,6 +88,7 @@ You can stop watching the job and view the cron job again to see that it schedul ```shell kubectl get cronjob hello ``` + The output is similar to this: ``` @@ -94,7 +96,8 @@ NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE hello */1 * * * * False 0 50s 75s ``` -You should see that the cron job `hello` successfully scheduled a job at the time specified in `LAST SCHEDULE`. There are currently 0 active jobs, meaning that the job has completed or failed. +You should see that the cron job `hello` successfully scheduled a job at the time specified in +`LAST SCHEDULE`. There are currently 0 active jobs, meaning that the job has completed or failed. Now, find the pods that the last scheduled job created and view the standard output of one of the pods. @@ -127,7 +130,7 @@ kubectl delete cronjob hello ``` Deleting the cron job removes all the jobs and pods it created and stops it from creating additional jobs. -You can read more about removing jobs in [garbage collection](/docs/concepts/workloads/controllers/garbage-collection/). +You can read more about removing jobs in [garbage collection](/docs/concepts/architecture/garbage-collection/). ## Writing a Cron Job Spec @@ -144,7 +147,8 @@ All modifications to a cron job, especially its `.spec`, are applied only to the ### Schedule The `.spec.schedule` is a required field of the `.spec`. -It takes a [Cron](https://en.wikipedia.org/wiki/Cron) format string, such as `0 * * * *` or `@hourly`, as schedule time of its jobs to be created and executed. +It takes a [Cron](https://en.wikipedia.org/wiki/Cron) format string, such as `0 * * * *` or `@hourly`, +as schedule time of its jobs to be created and executed. The format also includes extended "Vixie cron" step values. As explained in the [FreeBSD manual](https://www.freebsd.org/cgi/man.cgi?crontab%285%29): @@ -157,13 +161,15 @@ The format also includes extended "Vixie cron" step values. As explained in the > asterisk, so if you want to say "every two hours", just use `*/2`. {{< note >}} -A question mark (`?`) in the schedule has the same meaning as an asterisk `*`, that is, it stands for any of available value for a given field. +A question mark (`?`) in the schedule has the same meaning as an asterisk `*`, that is, +it stands for any of available value for a given field. {{< /note >}} ### Job Template The `.spec.jobTemplate` is the template for the job, and it is required. -It has exactly the same schema as a [Job](/docs/concepts/workloads/controllers/job/), except that it is nested and does not have an `apiVersion` or `kind`. +It has exactly the same schema as a [Job](/docs/concepts/workloads/controllers/job/), except that +it is nested and does not have an `apiVersion` or `kind`. For information about writing a job `.spec`, see [Writing a Job Spec](/docs/concepts/workloads/controllers/job/#writing-a-job-spec). ### Starting Deadline @@ -188,8 +194,10 @@ It specifies how to treat concurrent executions of a job that is created by this The spec may specify only one of the following concurrency policies: * `Allow` (default): The cron job allows concurrently running jobs -* `Forbid`: The cron job does not allow concurrent runs; if it is time for a new job run and the previous job run hasn't finished yet, the cron job skips the new job run -* `Replace`: If it is time for a new job run and the previous job run hasn't finished yet, the cron job replaces the currently running job run with a new job run +* `Forbid`: The cron job does not allow concurrent runs; if it is time for a new job run and the + previous job run hasn't finished yet, the cron job skips the new job run +* `Replace`: If it is time for a new job run and the previous job run hasn't finished yet, the + cron job replaces the currently running job run with a new job run Note that concurrency policy only applies to the jobs created by the same cron job. If there are multiple cron jobs, their respective jobs are always allowed to run concurrently. @@ -203,13 +211,15 @@ Defaults to false. {{< caution >}} Executions that are suspended during their scheduled time count as missed jobs. -When `.spec.suspend` changes from `true` to `false` on an existing cron job without a [starting deadline](#starting-deadline), the missed jobs are scheduled immediately. +When `.spec.suspend` changes from `true` to `false` on an existing cron job without a +[starting deadline](#starting-deadline), the missed jobs are scheduled immediately. {{< /caution >}} ### Jobs History Limits The `.spec.successfulJobsHistoryLimit` and `.spec.failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. -By default, they are set to 3 and 1 respectively. Setting a limit to `0` corresponds to keeping none of the corresponding kind of jobs after they finish. +By default, they are set to 3 and 1 respectively. Setting a limit to `0` corresponds to keeping +none of the corresponding kind of jobs after they finish. diff --git a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md index 7691466889..bad390575d 100644 --- a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md +++ b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md @@ -161,7 +161,7 @@ Configurations with a single API server will experience unavailability while the 1. Check the logs from control plane components, along with the kubelet and the kube-proxy. Ensure those components are not reporting any TLS errors; see - [looking at the logs](/docs/tasks/debug-application-cluster/debug-cluster/#looking-at-logs) for more details. + [looking at the logs](/docs/tasks/debug/debug-cluster/#looking-at-logs) for more details. 1. Validate logs from any aggregated api servers and pods using in-cluster config. From cfdd213d0aa79d88cbb71d902b5f0fd6ef54b55f Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 18 Jun 2022 13:45:31 +0800 Subject: [PATCH 013/209] Tweak page production environment This page has a lot of indentations or line wrappings that are "wrong". It would make tracking changes (especially for localization teams) very difficult. --- .../setup/production-environment/_index.md | 297 ++++++++++-------- 1 file changed, 158 insertions(+), 139 deletions(-) diff --git a/content/en/docs/setup/production-environment/_index.md b/content/en/docs/setup/production-environment/_index.md index 7d8200a6b3..3fed2210ef 100644 --- a/content/en/docs/setup/production-environment/_index.md +++ b/content/en/docs/setup/production-environment/_index.md @@ -28,29 +28,29 @@ on or hand to others, consider how your requirements for a Kubernetes cluster are influenced by the following issues: - *Availability*: A single-machine Kubernetes [learning environment](/docs/setup/#learning-environment) -has a single point of failure. Creating a highly available cluster means considering: + has a single point of failure. Creating a highly available cluster means considering: - Separating the control plane from the worker nodes. - Replicating the control plane components on multiple nodes. - Load balancing traffic to the cluster’s {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}}. - Having enough worker nodes available, or able to quickly become available, as changing workloads warrant it. - *Scale*: If you expect your production Kubernetes environment to receive a stable amount of -demand, you might be able to set up for the capacity you need and be done. However, -if you expect demand to grow over time or change dramatically based on things like -season or special events, you need to plan how to scale to relieve increased -pressure from more requests to the control plane and worker nodes or scale down to reduce unused -resources. + demand, you might be able to set up for the capacity you need and be done. However, + if you expect demand to grow over time or change dramatically based on things like + season or special events, you need to plan how to scale to relieve increased + pressure from more requests to the control plane and worker nodes or scale down to reduce unused + resources. - *Security and access management*: You have full admin privileges on your own -Kubernetes learning cluster. But shared clusters with important workloads, and -more than one or two users, require a more refined approach to who and what can -access cluster resources. You can use role-based access control -([RBAC](/docs/reference/access-authn-authz/rbac/)) and other -security mechanisms to make sure that users and workloads can get access to the -resources they need, while keeping workloads, and the cluster itself, secure. -You can set limits on the resources that users and workloads can access -by managing [policies](/docs/concepts/policy/) and -[container resources](/docs/concepts/configuration/manage-resources-containers/). + Kubernetes learning cluster. But shared clusters with important workloads, and + more than one or two users, require a more refined approach to who and what can + access cluster resources. You can use role-based access control + ([RBAC](/docs/reference/access-authn-authz/rbac/)) and other + security mechanisms to make sure that users and workloads can get access to the + resources they need, while keeping workloads, and the cluster itself, secure. + You can set limits on the resources that users and workloads can access + by managing [policies](/docs/concepts/policy/) and + [container resources](/docs/concepts/configuration/manage-resources-containers/). Before building a Kubernetes production environment on your own, consider handing off some or all of this job to @@ -59,16 +59,16 @@ providers or other [Kubernetes Partners](https://kubernetes.io/partners/). Options include: - *Serverless*: Just run workloads on third-party equipment without managing -a cluster at all. You will be charged for things like CPU usage, memory, and -disk requests. + a cluster at all. You will be charged for things like CPU usage, memory, and + disk requests. - *Managed control plane*: Let the provider manage the scale and availability -of the cluster's control plane, as well as handle patches and upgrades. + of the cluster's control plane, as well as handle patches and upgrades. - *Managed worker nodes*: Configure pools of nodes to meet your needs, -then the provider makes sure those nodes are available and ready to implement -upgrades when needed. + then the provider makes sure those nodes are available and ready to implement + upgrades when needed. - *Integration*: There are providers that integrate Kubernetes with other -services you may need, such as storage, container registries, authentication -methods, and development tools. + services you may need, such as storage, container registries, authentication + methods, and development tools. Whether you build a production Kubernetes cluster yourself or work with partners, review the following sections to evaluate your needs as they relate @@ -99,52 +99,52 @@ and ensuring that it can be repaired if something goes wrong is important, consider these steps: - *Choose deployment tools*: You can deploy a control plane using tools such -as kubeadm, kops, and kubespray. See -[Installing Kubernetes with deployment tools](/docs/setup/production-environment/tools/) -to learn tips for production-quality deployments using each of those deployment -methods. Different [Container Runtimes](/docs/setup/production-environment/container-runtimes/) -are available to use with your deployments. + as kubeadm, kops, and kubespray. See + [Installing Kubernetes with deployment tools](/docs/setup/production-environment/tools/) + to learn tips for production-quality deployments using each of those deployment + methods. Different [Container Runtimes](/docs/setup/production-environment/container-runtimes/) + are available to use with your deployments. - *Manage certificates*: Secure communications between control plane services -are implemented using certificates. Certificates are automatically generated -during deployment or you can generate them using your own certificate authority. -See [PKI certificates and requirements](/docs/setup/best-practices/certificates/) for details. + are implemented using certificates. Certificates are automatically generated + during deployment or you can generate them using your own certificate authority. + See [PKI certificates and requirements](/docs/setup/best-practices/certificates/) for details. - *Configure load balancer for apiserver*: Configure a load balancer -to distribute external API requests to the apiserver service instances running on different nodes. See -[Create an External Load Balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/) -for details. + to distribute external API requests to the apiserver service instances running on different nodes. See + [Create an External Load Balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/) + for details. - *Separate and backup etcd service*: The etcd services can either run on the -same machines as other control plane services or run on separate machines, for -extra security and availability. Because etcd stores cluster configuration data, -backing up the etcd database should be done regularly to ensure that you can -repair that database if needed. -See the [etcd FAQ](https://etcd.io/docs/v3.4/faq/) for details on configuring and using etcd. -See [Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/) -and [Set up a High Availability etcd cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) -for details. + same machines as other control plane services or run on separate machines, for + extra security and availability. Because etcd stores cluster configuration data, + backing up the etcd database should be done regularly to ensure that you can + repair that database if needed. + See the [etcd FAQ](https://etcd.io/docs/v3.4/faq/) for details on configuring and using etcd. + See [Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/) + and [Set up a High Availability etcd cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) + for details. - *Create multiple control plane systems*: For high availability, the -control plane should not be limited to a single machine. If the control plane -services are run by an init service (such as systemd), each service should run on at -least three machines. However, running control plane services as pods in -Kubernetes ensures that the replicated number of services that you request -will always be available. -The scheduler should be fault tolerant, -but not highly available. Some deployment tools set up [Raft](https://raft.github.io/) -consensus algorithm to do leader election of Kubernetes services. If the -primary goes away, another service elects itself and take over. + control plane should not be limited to a single machine. If the control plane + services are run by an init service (such as systemd), each service should run on at + least three machines. However, running control plane services as pods in + Kubernetes ensures that the replicated number of services that you request + will always be available. + The scheduler should be fault tolerant, + but not highly available. Some deployment tools set up [Raft](https://raft.github.io/) + consensus algorithm to do leader election of Kubernetes services. If the + primary goes away, another service elects itself and take over. - *Span multiple zones*: If keeping your cluster available at all times is -critical, consider creating a cluster that runs across multiple data centers, -referred to as zones in cloud environments. Groups of zones are referred to as regions. -By spreading a cluster across -multiple zones in the same region, it can improve the chances that your -cluster will continue to function even if one zone becomes unavailable. -See [Running in multiple zones](/docs/setup/best-practices/multiple-zones/) for details. + critical, consider creating a cluster that runs across multiple data centers, + referred to as zones in cloud environments. Groups of zones are referred to as regions. + By spreading a cluster across + multiple zones in the same region, it can improve the chances that your + cluster will continue to function even if one zone becomes unavailable. + See [Running in multiple zones](/docs/setup/best-practices/multiple-zones/) for details. - *Manage on-going features*: If you plan to keep your cluster over time, -there are tasks you need to do to maintain its health and security. For example, -if you installed with kubeadm, there are instructions to help you with -[Certificate Management](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) -and [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/). -See [Administer a Cluster](/docs/tasks/administer-cluster/) -for a longer list of Kubernetes administrative tasks. + there are tasks you need to do to maintain its health and security. For example, + if you installed with kubeadm, there are instructions to help you with + [Certificate Management](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) + and [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/). + See [Administer a Cluster](/docs/tasks/administer-cluster/) + for a longer list of Kubernetes administrative tasks. To learn about available options when you run control plane services, see [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/), @@ -166,39 +166,39 @@ consider how you want to manage your worker nodes (also referred to simply as *nodes*). - *Configure nodes*: Nodes can be physical or virtual machines. If you want to -create and manage your own nodes, you can install a supported operating system, -then add and run the appropriate -[Node services](/docs/concepts/overview/components/#node-components). Consider: + create and manage your own nodes, you can install a supported operating system, + then add and run the appropriate + [Node services](/docs/concepts/overview/components/#node-components). Consider: - The demands of your workloads when you set up nodes by having appropriate memory, CPU, and disk speed and storage capacity available. - Whether generic computer systems will do or you have workloads that need GPU processors, Windows nodes, or VM isolation. - *Validate nodes*: See [Valid node setup](/docs/setup/best-practices/node-conformance/) -for information on how to ensure that a node meets the requirements to join -a Kubernetes cluster. + for information on how to ensure that a node meets the requirements to join + a Kubernetes cluster. - *Add nodes to the cluster*: If you are managing your own cluster you can -add nodes by setting up your own machines and either adding them manually or -having them register themselves to the cluster’s apiserver. See the -[Nodes](/docs/concepts/architecture/nodes/) section for information on how to set up Kubernetes to add nodes in these ways. + add nodes by setting up your own machines and either adding them manually or + having them register themselves to the cluster’s apiserver. See the + [Nodes](/docs/concepts/architecture/nodes/) section for information on how to set up Kubernetes to add nodes in these ways. - *Add Windows nodes to the cluster*: Kubernetes offers support for Windows -worker nodes, allowing you to run workloads implemented in Windows containers. See -[Windows in Kubernetes](/docs/setup/production-environment/windows/) for details. + worker nodes, allowing you to run workloads implemented in Windows containers. See + [Windows in Kubernetes](/docs/setup/production-environment/windows/) for details. - *Scale nodes*: Have a plan for expanding the capacity your cluster will -eventually need. See [Considerations for large clusters](/docs/setup/best-practices/cluster-large/) -to help determine how many nodes you need, based on the number of pods and -containers you need to run. If you are managing nodes yourself, this can mean -purchasing and installing your own physical equipment. + eventually need. See [Considerations for large clusters](/docs/setup/best-practices/cluster-large/) + to help determine how many nodes you need, based on the number of pods and + containers you need to run. If you are managing nodes yourself, this can mean + purchasing and installing your own physical equipment. - *Autoscale nodes*: Most cloud providers support -[Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme) -to replace unhealthy nodes or grow and shrink the number of nodes as demand requires. See the -[Frequently Asked Questions](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md) -for how the autoscaler works and -[Deployment](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment) -for how it is implemented by different cloud providers. For on-premises, there -are some virtualization platforms that can be scripted to spin up new nodes -based on demand. + [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme) + to replace unhealthy nodes or grow and shrink the number of nodes as demand requires. See the + [Frequently Asked Questions](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md) + for how the autoscaler works and + [Deployment](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment) + for how it is implemented by different cloud providers. For on-premises, there + are some virtualization platforms that can be scripted to spin up new nodes + based on demand. - *Set up node health checks*: For important workloads, you want to make sure -that the nodes and pods running on those nodes are healthy. Using the -[Node Problem Detector](/docs/tasks/debug/debug-cluster/monitor-node-health/) -daemon, you can ensure your nodes are healthy. + that the nodes and pods running on those nodes are healthy. Using the + [Node Problem Detector](/docs/tasks/debug/debug-cluster/monitor-node-health/) + daemon, you can ensure your nodes are healthy. ## Production user management @@ -215,39 +215,51 @@ cluster (authentication) and deciding if they have permissions to do what they are asking (authorization): - *Authentication*: The apiserver can authenticate users using client -certificates, bearer tokens, an authenticating proxy, or HTTP basic auth. -You can choose which authentication methods you want to use. -Using plugins, the apiserver can leverage your organization’s existing -authentication methods, such as LDAP or Kerberos. See -[Authentication](/docs/reference/access-authn-authz/authentication/) -for a description of these different methods of authenticating Kubernetes users. -- *Authorization*: When you set out to authorize your regular users, you will probably choose between RBAC and ABAC authorization. See [Authorization Overview](/docs/reference/access-authn-authz/authorization/) to review different modes for authorizing user accounts (as well as service account access to your cluster): - - *Role-based access control* ([RBAC](/docs/reference/access-authn-authz/rbac/)): Lets you assign access to your cluster by allowing specific sets of permissions to authenticated users. Permissions can be assigned for a specific namespace (Role) or across the entire cluster (ClusterRole). Then using RoleBindings and ClusterRoleBindings, those permissions can be attached to particular users. - - *Attribute-based access control* ([ABAC](/docs/reference/access-authn-authz/abac/)): Lets you create policies based on resource attributes in the cluster and will allow or deny access based on those attributes. Each line of a policy file identifies versioning properties (apiVersion and kind) and a map of spec properties to match the subject (user or group), resource property, non-resource property (/version or /apis), and readonly. See [Examples](/docs/reference/access-authn-authz/abac/#examples) for details. + certificates, bearer tokens, an authenticating proxy, or HTTP basic auth. + You can choose which authentication methods you want to use. + Using plugins, the apiserver can leverage your organization’s existing + authentication methods, such as LDAP or Kerberos. See + [Authentication](/docs/reference/access-authn-authz/authentication/) + for a description of these different methods of authenticating Kubernetes users. +- *Authorization*: When you set out to authorize your regular users, you will probably choose + between RBAC and ABAC authorization. See [Authorization Overview](/docs/reference/access-authn-authz/authorization/) + to review different modes for authorizing user accounts (as well as service account access to + your cluster): + - *Role-based access control* ([RBAC](/docs/reference/access-authn-authz/rbac/)): Lets you + assign access to your cluster by allowing specific sets of permissions to authenticated users. + Permissions can be assigned for a specific namespace (Role) or across the entire cluster + (ClusterRole). Then using RoleBindings and ClusterRoleBindings, those permissions can be attached + to particular users. + - *Attribute-based access control* ([ABAC](/docs/reference/access-authn-authz/abac/)): Lets you + create policies based on resource attributes in the cluster and will allow or deny access + based on those attributes. Each line of a policy file identifies versioning properties (apiVersion + and kind) and a map of spec properties to match the subject (user or group), resource property, + non-resource property (/version or /apis), and readonly. See + [Examples](/docs/reference/access-authn-authz/abac/#examples) for details. As someone setting up authentication and authorization on your production Kubernetes cluster, here are some things to consider: - *Set the authorization mode*: When the Kubernetes API server -([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)) -starts, the supported authentication modes must be set using the *--authorization-mode* -flag. For example, that flag in the *kube-adminserver.yaml* file (in */etc/kubernetes/manifests*) -could be set to Node,RBAC. This would allow Node and RBAC authorization for authenticated requests. + ([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)) + starts, the supported authentication modes must be set using the *--authorization-mode* + flag. For example, that flag in the *kube-adminserver.yaml* file (in */etc/kubernetes/manifests*) + could be set to Node,RBAC. This would allow Node and RBAC authorization for authenticated requests. - *Create user certificates and role bindings (RBAC)*: If you are using RBAC -authorization, users can create a CertificateSigningRequest (CSR) that can be -signed by the cluster CA. Then you can bind Roles and ClusterRoles to each user. -See [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/) -for details. + authorization, users can create a CertificateSigningRequest (CSR) that can be + signed by the cluster CA. Then you can bind Roles and ClusterRoles to each user. + See [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/) + for details. - *Create policies that combine attributes (ABAC)*: If you are using ABAC -authorization, you can assign combinations of attributes to form policies to -authorize selected users or groups to access particular resources (such as a -pod), namespace, or apiGroup. For more information, see -[Examples](/docs/reference/access-authn-authz/abac/#examples). + authorization, you can assign combinations of attributes to form policies to + authorize selected users or groups to access particular resources (such as a + pod), namespace, or apiGroup. For more information, see + [Examples](/docs/reference/access-authn-authz/abac/#examples). - *Consider Admission Controllers*: Additional forms of authorization for -requests that can come in through the API server include -[Webhook Token Authentication](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication). -Webhooks and other special authorization types need to be enabled by adding -[Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) -to the API server. + requests that can come in through the API server include + [Webhook Token Authentication](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication). + Webhooks and other special authorization types need to be enabled by adding + [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) + to the API server. ## Set limits on workload resources @@ -256,38 +268,45 @@ of the Kubernetes control plane. Consider these items when setting up for the needs of your cluster's workloads: - *Set namespace limits*: Set per-namespace quotas on things like memory and CPU. See -[Manage Memory, CPU, and API Resources](/docs/tasks/administer-cluster/manage-resources/) -for details. You can also set -[Hierarchical Namespaces](/blog/2020/08/14/introducing-hierarchical-namespaces/) -for inheriting limits. + [Manage Memory, CPU, and API Resources](/docs/tasks/administer-cluster/manage-resources/) + for details. You can also set + [Hierarchical Namespaces](/blog/2020/08/14/introducing-hierarchical-namespaces/) + for inheriting limits. - *Prepare for DNS demand*: If you expect workloads to massively scale up, -your DNS service must be ready to scale up as well. See -[Autoscale the DNS service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). + your DNS service must be ready to scale up as well. See + [Autoscale the DNS service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). - *Create additional service accounts*: User accounts determine what users can -do on a cluster, while a service account defines pod access within a particular -namespace. By default, a pod takes on the default service account from its namespace. -See [Managing Service Accounts](/docs/reference/access-authn-authz/service-accounts-admin/) -for information on creating a new service account. For example, you might want to: - - Add secrets that a pod could use to pull images from a particular container registry. See [Configure Service Accounts for Pods](/docs/tasks/configure-pod-container/configure-service-account/) for an example. - - Assign RBAC permissions to a service account. See [ServiceAccount permissions](/docs/reference/access-authn-authz/rbac/#service-account-permissions) for details. + do on a cluster, while a service account defines pod access within a particular + namespace. By default, a pod takes on the default service account from its namespace. + See [Managing Service Accounts](/docs/reference/access-authn-authz/service-accounts-admin/) + for information on creating a new service account. For example, you might want to: + - Add secrets that a pod could use to pull images from a particular container registry. See + [Configure Service Accounts for Pods](/docs/tasks/configure-pod-container/configure-service-account/) + for an example. + - Assign RBAC permissions to a service account. See + [ServiceAccount permissions](/docs/reference/access-authn-authz/rbac/#service-account-permissions) + for details. ## {{% heading "whatsnext" %}} - Decide if you want to build your own production Kubernetes or obtain one from -available [Turnkey Cloud Solutions](/docs/setup/production-environment/turnkey-solutions/) -or [Kubernetes Partners](https://kubernetes.io/partners/). + available [Turnkey Cloud Solutions](/docs/setup/production-environment/turnkey-solutions/) + or [Kubernetes Partners](https://kubernetes.io/partners/). - If you choose to build your own cluster, plan how you want to -handle [certificates](/docs/setup/best-practices/certificates/) -and set up high availability for features such as -[etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) -and the -[API server](/docs/setup/production-environment/tools/kubeadm/ha-topology/). -- Choose from [kubeadm](/docs/setup/production-environment/tools/kubeadm/), [kops](/docs/setup/production-environment/tools/kops/) or [Kubespray](/docs/setup/production-environment/tools/kubespray/) -deployment methods. + handle [certificates](/docs/setup/best-practices/certificates/) + and set up high availability for features such as + [etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) + and the + [API server](/docs/setup/production-environment/tools/kubeadm/ha-topology/). +- Choose from [kubeadm](/docs/setup/production-environment/tools/kubeadm/), + [kops](/docs/setup/production-environment/tools/kops/) or + [Kubespray](/docs/setup/production-environment/tools/kubespray/) + deployment methods. - Configure user management by determining your -[Authentication](/docs/reference/access-authn-authz/authentication/) and -[Authorization](/docs/reference/access-authn-authz/authorization/) methods. + [Authentication](/docs/reference/access-authn-authz/authentication/) and + [Authorization](/docs/reference/access-authn-authz/authorization/) methods. - Prepare for application workloads by setting up -[resource limits](/docs/tasks/administer-cluster/manage-resources/), -[DNS autoscaling](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) -and [service accounts](/docs/reference/access-authn-authz/service-accounts-admin/). + [resource limits](/docs/tasks/administer-cluster/manage-resources/), + [DNS autoscaling](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) + and [service accounts](/docs/reference/access-authn-authz/service-accounts-admin/). + From aa585d2c29c46378dbb0905d674002f685b4e78d Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 18 Jun 2022 15:19:45 +0800 Subject: [PATCH 014/209] Reformat the open a PR page --- .../docs/contribute/new-content/open-a-pr.md | 529 ++++++++++-------- 1 file changed, 283 insertions(+), 246 deletions(-) diff --git a/content/en/docs/contribute/new-content/open-a-pr.md b/content/en/docs/contribute/new-content/open-a-pr.md index 666dfdce96..2989535ead 100644 --- a/content/en/docs/contribute/new-content/open-a-pr.md +++ b/content/en/docs/contribute/new-content/open-a-pr.md @@ -15,13 +15,15 @@ upcoming Kubernetes release, see [Document a new feature](/docs/contribute/new-content/new-features/). {{< /note >}} -To contribute new content pages or improve existing content pages, open a pull request (PR). Make sure you follow all the requirements in the [Before you begin](/docs/contribute/new-content/overview/#before-you-begin) section. - -If your change is small, or you're unfamiliar with git, read [Changes using GitHub](#changes-using-github) to learn how to edit a page. - -If your changes are large, read [Work from a local fork](#fork-the-repo) to learn how to make changes locally on your computer. +To contribute new content pages or improve existing content pages, open a pull request (PR). +Make sure you follow all the requirements in the +[Before you begin](/docs/contribute/new-content/) section. +If your change is small, or you're unfamiliar with git, read +[Changes using GitHub](#changes-using-github) to learn how to edit a page. +If your changes are large, read [Work from a local fork](#fork-the-repo) to learn how to make +changes locally on your computer. @@ -63,38 +65,39 @@ class id1 k8s Figure 1. Steps for opening a PR using GitHub. -1. On the page where you see the issue, select the pencil icon at the top right. - You can also scroll to the bottom of the page and select **Edit this page**. +1. On the page where you see the issue, select the pencil icon at the top right. + You can also scroll to the bottom of the page and select **Edit this page**. -2. Make your changes in the GitHub markdown editor. +1. Make your changes in the GitHub markdown editor. -3. Below the editor, fill in the **Propose file change** - form. In the first field, give your commit message a title. In - the second field, provide a description. +1. Below the editor, fill in the **Propose file change** form. + In the first field, give your commit message a title. + In the second field, provide a description. - {{< note >}} - Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in your commit message. You can add those to the pull request - description later. - {{< /note >}} + {{< note >}} + Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) + in your commit message. You can add those to the pull request description later. + {{< /note >}} -4. Select **Propose file change**. +1. Select **Propose file change**. -5. Select **Create pull request**. +1. Select **Create pull request**. -6. The **Open a pull request** screen appears. Fill in the form: +1. The **Open a pull request** screen appears. Fill in the form: - - The **Subject** field of the pull request defaults to the commit summary. - You can change it if needed. - - The **Body** contains your extended commit message, if you have one, - and some template text. Add the - details the template text asks for, then delete the extra template text. - - Leave the **Allow edits from maintainers** checkbox selected. + - The **Subject** field of the pull request defaults to the commit summary. + You can change it if needed. + - The **Body** contains your extended commit message, if you have one, + and some template text. Add the + details the template text asks for, then delete the extra template text. + - Leave the **Allow edits from maintainers** checkbox selected. - {{< note >}} - PR descriptions are a great way to help reviewers understand your change. For more information, see [Opening a PR](#open-a-pr). - {{}} + {{< note >}} + PR descriptions are a great way to help reviewers understand your change. + For more information, see [Opening a PR](#open-a-pr). + {{}} -7. Select **Create pull request**. +1. Select **Create pull request**. ### Addressing feedback in GitHub @@ -106,12 +109,12 @@ leave a comment with their GitHub username in it. If a reviewer asks you to make changes: 1. Go to the **Files changed** tab. -2. Select the pencil (edit) icon on any files changed by the -pull request. -3. Make the changes requested. -4. Commit the changes. +1. Select the pencil (edit) icon on any files changed by the pull request. +1. Make the changes requested. +1. Commit the changes. -If you are waiting on a reviewer, reach out once every 7 days. You can also post a message in the `#sig-docs` Slack channel. +If you are waiting on a reviewer, reach out once every 7 days. You can also post a message in the +`#sig-docs` Slack channel. When your review is complete, a reviewer merges your PR and your changes go live a few minutes later. @@ -120,7 +123,8 @@ When your review is complete, a reviewer merges your PR and your changes go live If you're more experienced with git, or if your changes are larger than a few lines, work from a local fork. -Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) installed on your computer. You can also use a git UI application. +Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) installed +on your computer. You can also use a git UI application. Figure 2 shows the steps to follow when you work from a local fork. The details for each step follow. @@ -157,53 +161,56 @@ Figure 2. Working from a local fork to make your changes. ### Fork the kubernetes/website repository 1. Navigate to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository. -2. Select **Fork**. +1. Select **Fork**. ### Create a local clone and set the upstream -3. In a terminal window, clone your fork and update the [Docsy Hugo theme](https://github.com/google/docsy#readme): +1. In a terminal window, clone your fork and update the [Docsy Hugo theme](https://github.com/google/docsy#readme): - ```bash - git clone git@github.com//website - cd website - git submodule update --init --recursive --depth 1 - ``` + ```shell + git clone git@github.com//website + cd website + git submodule update --init --recursive --depth 1 + ``` -4. Navigate to the new `website` directory. Set the `kubernetes/website` repository as the `upstream` remote: +1. Navigate to the new `website` directory. Set the `kubernetes/website` repository as the `upstream` remote: - ```bash - cd website + ```shell + cd website - git remote add upstream https://github.com/kubernetes/website.git - ``` + git remote add upstream https://github.com/kubernetes/website.git + ``` -5. Confirm your `origin` and `upstream` repositories: +1. Confirm your `origin` and `upstream` repositories: - ```bash - git remote -v - ``` + ```shell + git remote -v + ``` - Output is similar to: + Output is similar to: - ```bash - origin git@github.com:/website.git (fetch) - origin git@github.com:/website.git (push) - upstream https://github.com/kubernetes/website.git (fetch) - upstream https://github.com/kubernetes/website.git (push) - ``` + ```none + origin git@github.com:/website.git (fetch) + origin git@github.com:/website.git (push) + upstream https://github.com/kubernetes/website.git (fetch) + upstream https://github.com/kubernetes/website.git (push) + ``` -6. Fetch commits from your fork's `origin/main` and `kubernetes/website`'s `upstream/main`: +1. Fetch commits from your fork's `origin/main` and `kubernetes/website`'s `upstream/main`: - ```bash - git fetch origin - git fetch upstream - ``` + ```shell + git fetch origin + git fetch upstream + ``` - This makes sure your local repository is up to date before you start making changes. + This makes sure your local repository is up to date before you start making changes. - {{< note >}} - This workflow is different than the [Kubernetes Community GitHub Workflow](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md). You do not need to merge your local copy of `main` with `upstream/main` before pushing updates to your fork. - {{< /note >}} + {{< note >}} + This workflow is different than the + [Kubernetes Community GitHub Workflow](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md). + You do not need to merge your local copy of `main` with `upstream/main` before pushing updates + to your fork. + {{< /note >}} ### Create a branch @@ -211,21 +218,23 @@ Figure 2. Working from a local fork to make your changes. - For improvements to existing content, use `upstream/main`. - For new content about existing features, use `upstream/main`. - - For localized content, use the localization's conventions. For more information, see [localizing Kubernetes documentation](/docs/contribute/localization/). - - For new features in an upcoming Kubernetes release, use the feature branch. For more information, see [documenting for a release](/docs/contribute/new-content/new-features/). + - For localized content, use the localization's conventions. For more information, see + [localizing Kubernetes documentation](/docs/contribute/localization/). + - For new features in an upcoming Kubernetes release, use the feature branch. For more + information, see [documenting for a release](/docs/contribute/new-content/new-features/). - For long-running efforts that multiple SIG Docs contributors collaborate on, - like content reorganization, use a specific feature branch created for that - effort. + like content reorganization, use a specific feature branch created for that effort. If you need help choosing a branch, ask in the `#sig-docs` Slack channel. -2. Create a new branch based on the branch identified in step 1. This example assumes the base branch is `upstream/main`: +1. Create a new branch based on the branch identified in step 1. This example assumes the base + branch is `upstream/main`: - ```bash - git checkout -b upstream/main - ``` + ```shell + git checkout -b upstream/main + ``` -3. Make your changes using a text editor. +3. Make your changes using a text editor. At any time, use the `git status` command to see what files you've changed. @@ -235,109 +244,116 @@ When you are ready to submit a pull request, commit your changes. 1. In your local repository, check which files you need to commit: - ```bash - git status - ``` + ```shell + git status + ``` - Output is similar to: + Output is similar to: - ```bash - On branch - Your branch is up to date with 'origin/'. + ```none + On branch + Your branch is up to date with 'origin/'. - Changes not staged for commit: - (use "git add ..." to update what will be committed) - (use "git checkout -- ..." to discard changes in working directory) + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) - modified: content/en/docs/contribute/new-content/contributing-content.md + modified: content/en/docs/contribute/new-content/contributing-content.md - no changes added to commit (use "git add" and/or "git commit -a") - ``` + no changes added to commit (use "git add" and/or "git commit -a") + ``` -2. Add the files listed under **Changes not staged for commit** to the commit: +1. Add the files listed under **Changes not staged for commit** to the commit: - ```bash - git add - ``` + ```shell + git add + ``` - Repeat this for each file. + Repeat this for each file. -3. After adding all the files, create a commit: +1. After adding all the files, create a commit: - ```bash - git commit -m "Your commit message" - ``` + ```shell + git commit -m "Your commit message" + ``` - {{< note >}} - Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in your commit message. You can add those to the pull request - description later. - {{< /note >}} + {{< note >}} + Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) + in your commit message. You can add those to the pull request + description later. + {{< /note >}} -4. Push your local branch and its new commit to your remote fork: +1. Push your local branch and its new commit to your remote fork: - ```bash - git push origin - ``` + ```shell + git push origin + ``` ### Preview your changes locally {#preview-locally} -It's a good idea to preview your changes locally before pushing them or opening a pull request. A preview lets you catch build errors or markdown formatting problems. +It's a good idea to preview your changes locally before pushing them or opening a pull request. +A preview lets you catch build errors or markdown formatting problems. -You can either build the website's container image or run Hugo locally. Building the container image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can be useful for debugging. +You can either build the website's container image or run Hugo locally. Building the container +image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can +be useful for debugging. {{< tabs name="tab_with_hugo" >}} {{% tab name="Hugo in a container" %}} {{< note >}} -The commands below use Docker as default container engine. Set the `CONTAINER_ENGINE` environment variable to override this behaviour. +The commands below use Docker as default container engine. Set the `CONTAINER_ENGINE` environment +variable to override this behaviour. {{< /note >}} 1. Build the container image locally _You only need this step if you are testing a change to the Hugo tool itself_ - ```bash + + ```shell # Run this in a terminal (if required) make container-image ``` 1. Start Hugo in a container: - ```bash + ```shell # Run this in a terminal make container-serve ``` -1. In a web browser, navigate to `https://localhost:1313`. Hugo watches the - changes and rebuilds the site as needed. +1. In a web browser, navigate to `https://localhost:1313`. Hugo watches the + changes and rebuilds the site as needed. -1. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`, - or close the terminal window. +1. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`, + or close the terminal window. {{% /tab %}} {{% tab name="Hugo on the command line" %}} Alternately, install and use the `hugo` command on your computer: -1. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml). +1. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in + [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml). -2. If you have not updated your website repository, the `website/themes/docsy` directory is empty. - The site cannot build without a local copy of the theme. To update the website theme, run: +1. If you have not updated your website repository, the `website/themes/docsy` directory is empty. + The site cannot build without a local copy of the theme. To update the website theme, run: - ```bash - git submodule update --init --recursive --depth 1 - ``` + ```shell + git submodule update --init --recursive --depth 1 + ``` -3. In a terminal, go to your Kubernetes website repository and start the Hugo server: +1. In a terminal, go to your Kubernetes website repository and start the Hugo server: - ```bash - cd /website - hugo server --buildFuture - ``` + ```shell + cd /website + hugo server --buildFuture + ``` -4. In a web browser, navigate to `https://localhost:1313`. Hugo watches the - changes and rebuilds the site as needed. +1. In a web browser, navigate to `https://localhost:1313`. Hugo watches the + changes and rebuilds the site as needed. -5. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`, - or close the terminal window. +1. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`, + or close the terminal window. {{% /tab %}} {{< /tabs >}} @@ -345,6 +361,7 @@ Alternately, install and use the `hugo` command on your computer: ### Open a pull request from your fork to kubernetes/website {#open-a-pr} Figure 3 shows the steps to open a PR from your fork to the K8s/website. The details follow. + @@ -374,47 +391,55 @@ class first,second white Figure 3. Steps to open a PR from your fork to the K8s/website. 1. In a web browser, go to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository. -2. Select **New Pull Request**. -3. Select **compare across forks**. -4. From the **head repository** drop-down menu, select your fork. -5. From the **compare** drop-down menu, select your branch. -6. Select **Create Pull Request**. -7. Add a description for your pull request: +1. Select **New Pull Request**. +1. Select **compare across forks**. +1. From the **head repository** drop-down menu, select your fork. +1. From the **compare** drop-down menu, select your branch. +1. Select **Create Pull Request**. +`. Add a description for your pull request: + - **Title** (50 characters or less): Summarize the intent of the change. - **Description**: Describe the change in more detail. - - If there is a related GitHub issue, include `Fixes #12345` or `Closes #12345` in the description. GitHub's automation closes the mentioned issue after merging the PR if used. If there are other related PRs, link those as well. - - If you want advice on something specific, include any questions you'd like reviewers to think about in your description. -8. Select the **Create pull request** button. + - If there is a related GitHub issue, include `Fixes #12345` or `Closes #12345` in the + description. GitHub's automation closes the mentioned issue after merging the PR if used. + If there are other related PRs, link those as well. + - If you want advice on something specific, include any questions you'd like reviewers to + think about in your description. + +1. Select the **Create pull request** button. Congratulations! Your pull request is available in [Pull requests](https://github.com/kubernetes/website/pulls). +After opening a PR, GitHub runs automated tests and tries to deploy a preview using +[Netlify](https://www.netlify.com/). -After opening a PR, GitHub runs automated tests and tries to deploy a preview using [Netlify](https://www.netlify.com/). +- If the Netlify build fails, select **Details** for more information. +- If the Netlify build succeeds, select **Details** opens a staged version of the Kubernetes + website with your changes applied. This is how reviewers check your changes. - - If the Netlify build fails, select **Details** for more information. - - If the Netlify build succeeds, select **Details** opens a staged version of the Kubernetes website with your changes applied. This is how reviewers check your changes. - -GitHub also automatically assigns labels to a PR, to help reviewers. You can add them too, if needed. For more information, see [Adding and removing issue labels](/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels). +GitHub also automatically assigns labels to a PR, to help reviewers. You can add them too, if +needed. For more information, see [Adding and removing issue labels](/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels). ### Addressing feedback locally 1. After making your changes, amend your previous commit: - ```bash - git commit -a --amend - ``` + ```shell + git commit -a --amend + ``` - - `-a`: commits all changes - - `--amend`: amends the previous commit, rather than creating a new one + - `-a`: commits all changes + - `--amend`: amends the previous commit, rather than creating a new one -2. Update your commit message if needed. +1. Update your commit message if needed. -3. Use `git push origin ` to push your changes and re-run the Netlify tests. +1. Use `git push origin ` to push your changes and re-run the Netlify tests. - {{< note >}} - If you use `git commit -m` instead of amending, you must [squash your commits](#squashing-commits) before merging. - {{< /note >}} + {{< note >}} + If you use `git commit -m` instead of amending, you must [squash your commits](#squashing-commits) + before merging. + {{< /note >}} #### Changes from reviewers @@ -422,89 +447,97 @@ Sometimes reviewers commit to your pull request. Before making any other changes 1. Fetch commits from your remote fork and rebase your working branch: - ```bash - git fetch origin - git rebase origin/ - ``` + ```shell + git fetch origin + git rebase origin/ + ``` -2. After rebasing, force-push new changes to your fork: +1. After rebasing, force-push new changes to your fork: - ```bash - git push --force-with-lease origin - ``` + ```shell + git push --force-with-lease origin + ``` #### Merge conflicts and rebasing {{< note >}} -For more information, see [Git Branching - Basic Branching and Merging](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), [Advanced Merging](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging), or ask in the `#sig-docs` Slack channel for help. +For more information, see [Git Branching - Basic Branching and Merging](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), +[Advanced Merging](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging), or ask in the +`#sig-docs` Slack channel for help. {{< /note >}} -If another contributor commits changes to the same file in another PR, it can create a merge conflict. You must resolve all merge conflicts in your PR. +If another contributor commits changes to the same file in another PR, it can create a merge +conflict. You must resolve all merge conflicts in your PR. 1. Update your fork and rebase your local branch: - ```bash - git fetch origin - git rebase origin/ - ``` + ```shell + git fetch origin + git rebase origin/ + ``` - Then force-push the changes to your fork: + Then force-push the changes to your fork: - ```bash - git push --force-with-lease origin - ``` + ```shell + git push --force-with-lease origin + ``` -2. Fetch changes from `kubernetes/website`'s `upstream/main` and rebase your branch: +1. Fetch changes from `kubernetes/website`'s `upstream/main` and rebase your branch: - ```bash + ```shell git fetch upstream git rebase upstream/main ``` -3. Inspect the results of the rebase: +1. Inspect the results of the rebase: - ```bash - git status - ``` + ```shell + git status + ``` - This results in a number of files marked as conflicted. + This results in a number of files marked as conflicted. -4. Open each conflicted file and look for the conflict markers: `>>>`, `<<<`, and `===`. Resolve the conflict and delete the conflict marker. +1. Open each conflicted file and look for the conflict markers: `>>>`, `<<<`, and `===`. + Resolve the conflict and delete the conflict marker. - {{< note >}} - For more information, see [How conflicts are presented](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented). - {{< /note >}} + {{< note >}} + For more information, see [How conflicts are presented](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented). + {{< /note >}} -5. Add the files to the changeset: +1. Add the files to the changeset: - ```bash - git add - ``` -6. Continue the rebase: + ```shell + git add + ``` - ```bash - git rebase --continue - ``` +1. Continue the rebase: -7. Repeat steps 2 to 5 as needed. + `` + git rebase --continue + ``` - After applying all commits, the `git status` command shows that the rebase is complete. +1. Repeat steps 2 to 5 as needed. -8. Force-push the branch to your fork: + After applying all commits, the `git status` command shows that the rebase is complete. - ```bash - git push --force-with-lease origin - ``` +1. Force-push the branch to your fork: - The pull request no longer shows any conflicts. + ```shell + git push --force-with-lease origin + ``` + + The pull request no longer shows any conflicts. ### Squashing commits {{< note >}} -For more information, see [Git Tools - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History), or ask in the `#sig-docs` Slack channel for help. +For more information, see [Git Tools - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History), +or ask in the `#sig-docs` Slack channel for help. {{< /note >}} -If your PR has multiple commits, you must squash them into a single commit before merging your PR. You can check the number of commits on your PR's **Commits** tab or by running the `git log` command locally. +If your PR has multiple commits, you must squash them into a single commit before merging your PR. +You can check the number of commits on your PR's **Commits** tab or by running the `git log` +command locally. {{< note >}} This topic assumes `vim` as the command line text editor. @@ -512,79 +545,83 @@ This topic assumes `vim` as the command line text editor. 1. Start an interactive rebase: - ```bash - git rebase -i HEAD~ - ``` + ```shell + git rebase -i HEAD~ + ``` - Squashing commits is a form of rebasing. The `-i` switch tells git you want to rebase interactively. `HEAD~}} - For more information, see [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode). - {{< /note >}} + {{< note >}} + For more information, see [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode). + {{< /note >}} -2. Start editing the file. +1. Start editing the file. - Change the original text: + Change the original text: - ```bash - pick d875112ca Original commit - pick 4fa167b80 Address feedback 1 - pick 7d54e15ee Address feedback 2 - ``` + ```none + pick d875112ca Original commit + pick 4fa167b80 Address feedback 1 + pick 7d54e15ee Address feedback 2 + ``` - To: + To: - ```bash - pick d875112ca Original commit - squash 4fa167b80 Address feedback 1 - squash 7d54e15ee Address feedback 2 - ``` + ```none + pick d875112ca Original commit + squash 4fa167b80 Address feedback 1 + squash 7d54e15ee Address feedback 2 + ``` - This squashes commits `4fa167b80 Address feedback 1` and `7d54e15ee Address feedback 2` into `d875112ca Original commit`, leaving only `d875112ca Original commit` as a part of the timeline. + This squashes commits `4fa167b80 Address feedback 1` and `7d54e15ee Address feedback 2` into + `d875112ca Original commit`, leaving only `d875112ca Original commit` as a part of the timeline. -3. Save and exit your file. +1. Save and exit your file. -4. Push your squashed commit: +1. Push your squashed commit: - ```bash - git push --force-with-lease origin - ``` + ```shell + git push --force-with-lease origin + ``` ## Contribute to other repos -The [Kubernetes project](https://github.com/kubernetes) contains 50+ repositories. Many of these repositories contain documentation: user-facing help text, error messages, API references or code comments. +The [Kubernetes project](https://github.com/kubernetes) contains 50+ repositories. Many of these +repositories contain documentation: user-facing help text, error messages, API references or code +comments. -If you see text you'd like to improve, use GitHub to search all repositories in the Kubernetes organization. -This can help you figure out where to submit your issue or PR. +If you see text you'd like to improve, use GitHub to search all repositories in the Kubernetes +organization. This can help you figure out where to submit your issue or PR. -Each repository has its own processes and procedures. Before you file an -issue or submit a PR, read that repository's `README.md`, `CONTRIBUTING.md`, and -`code-of-conduct.md`, if they exist. +Each repository has its own processes and procedures. Before you file an issue or submit a PR, +read that repository's `README.md`, `CONTRIBUTING.md`, and `code-of-conduct.md`, if they exist. -Most repositories use issue and PR templates. Have a look through some open -issues and PRs to get a feel for that team's processes. Make sure to fill out -the templates with as much detail as possible when you file issues or PRs. +Most repositories use issue and PR templates. Have a look through some open issues and PRs to get +a feel for that team's processes. Make sure to fill out the templates with as much detail as +possible when you file issues or PRs. ## {{% heading "whatsnext" %}} - - Read [Reviewing](/docs/contribute/review/reviewing-prs) to learn more about the review process. From 700433da48ff83524e020dabf13be86c79888200 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 18 Jun 2022 14:35:50 +0800 Subject: [PATCH 015/209] Tweak localization page --- content/en/docs/contribute/localization.md | 255 ++++++++++++------ .../contribute/suggesting-improvements.md | 1 - 2 files changed, 178 insertions(+), 78 deletions(-) diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md index 97b15541f1..9307075174 100644 --- a/content/en/docs/contribute/localization.md +++ b/content/en/docs/contribute/localization.md @@ -13,14 +13,19 @@ card: -This page shows you how to [localize](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/) the docs for a different language. +This page shows you how to +[localize](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/) the docs for a +different language. ## Contribute to an existing localization -You can help add or improve content to an existing localization. In [Kubernetes Slack](https://slack.k8s.io/) you'll find a channel for each localization. There is also a general [SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations) where you can say hello. +You can help add or improve content to an existing localization. In [Kubernetes +Slack](https://slack.k8s.io/) you'll find a channel for each localization. There is also a general +[SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations) +where you can say hello. {{< note >}} If you want to work on a localization that already exists, check @@ -30,11 +35,14 @@ English original. You might see extra details there. ### Find your two-letter language code -First, consult the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php) to find your localization's two-letter language code. For example, the two-letter code for Korean is `ko`. +First, consult the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php) +to find your localization's two-letter language code. For example, the two-letter code for Korean +is `ko`. ### Fork and clone the repo -First, [create your own fork](/docs/contribute/new-content/open-a-pr/#fork-the-repo) of the [kubernetes/website](https://github.com/kubernetes/website) repository. +First, [create your own fork](/docs/contribute/new-content/open-a-pr/#fork-the-repo) of the +[kubernetes/website](https://github.com/kubernetes/website) repository. Then, clone your fork and `cd` into it: @@ -43,7 +51,8 @@ git clone https://github.com//website cd website ``` -The website content directory includes sub-directories for each language. The localization you want to help out with is inside `content/`. +The website content directory includes sub-directories for each language. The localization you +want to help out with is inside `content/`. ### Suggest changes @@ -57,8 +66,9 @@ equivalent fix by updating the localization you're working on. Please limit pull requests to a single localization, since pull requests that change content in multiple localizations could be difficult to review. -Follow [Suggesting Content Improvements](/docs/contribute/suggest-improvements/) to propose changes to -that localization. The process is very similar to proposing changes to the upstream (English) content. +Follow [Suggesting Content Improvements](/docs/contribute/suggesting-improvements/) +to propose changes to that localization. The process is very similar to proposing changes to the +upstream (English) content. ## Start a new localization @@ -86,40 +96,62 @@ can incrementally work towards that goal. ### Find community -Let Kubernetes SIG Docs know you're interested in creating a localization! Join the [SIG Docs Slack channel](https://kubernetes.slack.com/messages/sig-docs) and the [SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations). Other localization teams are happy to help you get started and answer any questions you have. +Let Kubernetes SIG Docs know you're interested in creating a localization! Join the +[SIG Docs Slack channel](https://kubernetes.slack.com/messages/sig-docs) and the +[SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations). +Other localization teams are happy to help you get started and answer any questions you have. -Please also consider participating in the [SIG Docs Localization Subgroup meeting](https://github.com/kubernetes/community/tree/master/sig-docs). The mission of the SIG Docs localization subgroup is to work across the SIG Docs localization teams to collaborate on defining and documenting the processes for creating localized contribution guides. In addition, the SIG Docs localization subgroup will look for opportunities for the creation and sharing of common tools across localization teams and also serve to identify new requirements to the SIG Docs Leadership team. If you have questions about this meeting, please inquire on the [SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations). +Please also consider participating in the +[SIG Docs Localization Subgroup meeting](https://github.com/kubernetes/community/tree/master/sig-docs). +The mission of the SIG Docs localization subgroup is to work across the SIG Docs localization +teams to collaborate on defining and documenting the processes for creating localized contribution +guides. In addition, the SIG Docs localization subgroup will look for opportunities for the +creation and sharing of common tools across localization teams and also serve to identify new +requirements to the SIG Docs Leadership team. If you have questions about this meeting, please +inquire on the [SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations). -You can also create a Slack channel for your localization in the `kubernetes/community` repository. For an example of adding a Slack channel, see the PR for [adding a channel for Persian](https://github.com/kubernetes/community/pull/4980). +You can also create a Slack channel for your localization in the `kubernetes/community` +repository. For an example of adding a Slack channel, see the PR for +[adding a channel for Persian](https://github.com/kubernetes/community/pull/4980). ### Join the Kubernetes GitHub organization -Once you've opened a localization PR, you can become members of the Kubernetes GitHub organization. Each person on the team needs to create their own [Organization Membership Request](https://github.com/kubernetes/org/issues/new/choose) in the `kubernetes/org` repository. +Once you've opened a localization PR, you can become members of the Kubernetes GitHub +organization. Each person on the team needs to create their own +[Organization Membership Request](https://github.com/kubernetes/org/issues/new/choose) +in the `kubernetes/org` repository. ### Add your localization team in GitHub -Next, add your Kubernetes localization team to [`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/main/config/kubernetes/sig-docs/teams.yaml). For an example of adding a localization team, see the PR to add the [Spanish localization team](https://github.com/kubernetes/org/pull/685). - -Members of `@kubernetes/sig-docs-**-owners` can approve PRs that change content within (and only within) your localization directory: `/content/**/`. - -For each localization, The `@kubernetes/sig-docs-**-reviews` team automates review assignment for new PRs. +Next, add your Kubernetes localization team to +[`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/main/config/kubernetes/sig-docs/teams.yaml). +For an example of adding a localization team, see the PR to add the +[Spanish localization team](https://github.com/kubernetes/org/pull/685). +Members of `@kubernetes/sig-docs-**-owners` can approve PRs that change content within (and only +within) your localization directory: `/content/**/`. +For each localization, The `@kubernetes/sig-docs-**-reviews` team automates review assignment for +new PRs. Members of `@kubernetes/website-maintainers` can create new localization branches to coordinate translation efforts. - -Members of `@kubernetes/website-milestone-maintainers` can use the `/milestone` [Prow command](https://prow.k8s.io/command-help) to assign a milestone to issues or PRs. +Members of `@kubernetes/website-milestone-maintainers` can use the `/milestone` +[Prow command](https://prow.k8s.io/command-help) to assign a milestone to issues or PRs. ### Configure the workflow -Next, add a GitHub label for your localization in the `kubernetes/test-infra` repository. A label lets you filter issues and pull requests for your specific language. - -For an example of adding a label, see the PR for adding the [Italian language label](https://github.com/kubernetes/test-infra/pull/11316). +Next, add a GitHub label for your localization in the `kubernetes/test-infra` repository. A label +lets you filter issues and pull requests for your specific language. +For an example of adding a label, see the PR for adding the +[Italian language label](https://github.com/kubernetes/test-infra/pull/11316). ### Modify the site configuration -The Kubernetes website uses Hugo as its web framework. The website's Hugo configuration resides in the [`config.toml`](https://github.com/kubernetes/website/tree/main/config.toml) file. To support a new localization, you'll need to modify `config.toml`. +The Kubernetes website uses Hugo as its web framework. The website's Hugo configuration resides in +the [`config.toml`](https://github.com/kubernetes/website/tree/main/config.toml) file. +To support a new localization, you'll need to modify `config.toml`. -Add a configuration block for the new language to `config.toml`, under the existing `[languages]` block. The German block, for example, looks like: +Add a configuration block for the new language to `config.toml`, under the existing `[languages]` block. +The German block, for example, looks like: ```toml [languages.de] @@ -131,17 +163,25 @@ contentDir = "content/de" weight = 8 ``` -The value for `languageName` will be listed in language selection bar. Assign "language name in native script and language (English language name in latin script)" to `languageName`. For example, `languageName = "한국어 (Korean)"` or `languageName = "Deutsch (German)"`. +The value for `languageName` will be listed in language selection bar. Assign "language name in +native script and language (English language name in latin script)" to `languageName`. +For example, `languageName = "한국어 (Korean)"` or `languageName = "Deutsch (German)"`. -`languageNameLatinScript` can be used to access the language name in latin script and use it in the theme. Assign "language name in latin script" to `languageNameLatinScript`. For example, `languageNameLatinScript ="Korean"` or `languageNameLatinScript = "Deutsch"`. +`languageNameLatinScript` can be used to access the language name in latin script and use it in +the theme. Assign "language name in latin script" to `languageNameLatinScript`. For example, +`languageNameLatinScript ="Korean"` or `languageNameLatinScript = "Deutsch"`. -When assigning a `weight` parameter for your block, find the language block with the highest weight and add 1 to that value. +When assigning a `weight` parameter for your block, find the language block with the highest +weight and add 1 to that value. -For more information about Hugo's multilingual support, see "[Multilingual Mode](https://gohugo.io/content-management/multilingual/)". +For more information about Hugo's multilingual support, see +"[Multilingual Mode](https://gohugo.io/content-management/multilingual/)". ### Add a new localization directory -Add a language-specific subdirectory to the [`content`](https://github.com/kubernetes/website/tree/main/content) folder in the repository. For example, the two-letter code for German is `de`: +Add a language-specific subdirectory to the +[`content`](https://github.com/kubernetes/website/tree/main/content) folder in the repository. +For example, the two-letter code for German is `de`: ```shell mkdir content/de @@ -151,28 +191,34 @@ You also need to create a directory inside `data/i18n` for [localized strings](#site-strings-in-i18n); look at existing localizations for an example. To use these new strings, you must also create a symbolic link from `i18n/.toml` to the actual string configuration in -`data/i18n//.toml` (remember to commit the symbolic -link). +`data/i18n//.toml` (remember to commit the symbolic link). For example, for German the strings live in `data/i18n/de/de.toml`, and `i18n/de.toml` is a symbolic link to `data/i18n/de/de.toml`. ### Localize the community code of conduct -Open a PR against the [`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages) repository to add the code of conduct in your language. - +Open a PR against the [`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages) +repository to add the code of conduct in your language. ### Setting up the OWNERS files -To set the roles of each user contributing to the localization, create an `OWNERS` file inside the language-specific subdirectory with: +To set the roles of each user contributing to the localization, create an `OWNERS` file inside the +language-specific subdirectory with: -- **reviewers**: A list of kubernetes teams with reviewer roles, in this case, the `sig-docs-**-reviews` team created in [Add your localization team in GitHub](#add-your-localization-team-in-github). -- **approvers**: A list of kubernetes teams with approvers roles, in this case, the `sig-docs-**-owners` team created in [Add your localization team in GitHub](#add-your-localization-team-in-github). -- **labels**: A list of GitHub labels to automatically apply to a PR, in this case, the language label created in [Configure the workflow](#configure-the-workflow). +- **reviewers**: A list of kubernetes teams with reviewer roles, in this case, the + `sig-docs-**-reviews` team created in + [Add your localization team in GitHub](#add-your-localization-team-in-github). +- **approvers**: A list of kubernetes teams with approvers roles, in this case, the + `sig-docs-**-owners` team created in + [Add your localization team in GitHub](#add-your-localization-team-in-github). +- **labels**: A list of GitHub labels to automatically apply to a PR, in this case, the language + label created in [Configure the workflow](#configure-the-workflow). More information about the `OWNERS` file can be found at [go.k8s.io/owners](https://go.k8s.io/owners). -The [Spanish OWNERS file](https://git.k8s.io/website/content/es/OWNERS), with language code `es`, looks like: +The [Spanish OWNERS file](https://git.k8s.io/website/content/es/OWNERS), +with language code `es`, looks like: ```yaml # See the OWNERS docs at https://go.k8s.io/owners @@ -190,9 +236,13 @@ labels: - language/es ``` -After adding the language-specific `OWNERS` file, update the [root `OWNERS_ALIASES`](https://git.k8s.io/website/OWNERS_ALIASES) file with the new Kubernetes teams for the localization, `sig-docs-**-owners` and `sig-docs-**-reviews`. +After adding the language-specific `OWNERS` file, update the [root +`OWNERS_ALIASES`](https://git.k8s.io/website/OWNERS_ALIASES) file with the new Kubernetes teams +for the localization, `sig-docs-**-owners` and `sig-docs-**-reviews`. -For each team, add the list of GitHub users requested in [Add your localization team in GitHub](#add-your-localization-team-in-github), in alphabetical order. +For each team, add the list of GitHub users requested in +[Add your localization team in GitHub](#add-your-localization-team-in-github), +in alphabetical order. ```diff --- a/OWNERS_ALIASES @@ -216,33 +266,45 @@ For each team, add the list of GitHub users requested in [Add your localization ### Open a pull request -Next, [open a pull request](/docs/contribute/new-content/open-a-pr/#open-a-pr) (PR) to add a localization to the `kubernetes/website` repository. +Next, [open a pull request](/docs/contribute/new-content/open-a-pr/#open-a-pr) (PR) to add a +localization to the `kubernetes/website` repository. +The PR must include all of the [minimum required content](#minimum-required-content) before it can +be approved. -The PR must include all of the [minimum required content](#minimum-required-content) before it can be approved. - -For an example of adding a new localization, see the PR to enable [docs in French](https://github.com/kubernetes/website/pull/12548). +For an example of adding a new localization, see the PR to enable +[docs in French](https://github.com/kubernetes/website/pull/12548). ### Add a localized README file -To guide other localization contributors, add a new [`README-**.md`](https://help.github.com/articles/about-readmes/) to the top level of [k/website](https://github.com/kubernetes/website/), where `**` is the two-letter language code. For example, a German README file would be `README-de.md`. +To guide other localization contributors, add a new +[`README-**.md`](https://help.github.com/articles/about-readmes/) to the top level of +[k/website](https://github.com/kubernetes/website/), where `**` is the two-letter language code. +For example, a German README file would be `README-de.md`. -Provide guidance to localization contributors in the localized `README-**.md` file. Include the same information contained in `README.md` as well as: +Provide guidance to localization contributors in the localized `README-**.md` file. +Include the same information contained in `README.md` as well as: - A point of contact for the localization project - Any information specific to the localization -After you create the localized README, add a link to the file from the main English `README.md`, and include contact information in English. You can provide a GitHub ID, email address, [Slack channel](https://slack.com/), or other method of contact. You must also provide a link to your localized Community Code of Conduct. +After you create the localized README, add a link to the file from the main English `README.md`, +and include contact information in English. You can provide a GitHub ID, email address, +[Slack channel](https://slack.com/), or other method of contact. You must also provide a link to your +localized Community Code of Conduct. ### Launching your new localization Once a localization meets requirements for workflow and minimum output, SIG Docs will: - Enable language selection on the website -- Publicize the localization's availability through [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF) channels, including the [Kubernetes blog](https://kubernetes.io/blog/). +- Publicize the localization's availability through + [Cloud Native Computing Foundation](https://www.cncf.io/about/)(CNCF) channels, including the + [Kubernetes blog](https://kubernetes.io/blog/). ## Translating content -Localizing *all* of the Kubernetes documentation is an enormous task. It's okay to start small and expand over time. +Localizing *all* of the Kubernetes documentation is an enormous task. It's okay to start small and +expand over time. ### Minimum required content @@ -256,20 +318,26 @@ Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Mini Site strings | [All site strings](#Site-strings-in-i18n) in a new localized TOML file Releases | [All heading and subheading URLs](/releases) -Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source: +Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the +same URL path as the English source. For example, to prepare the +[Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, +create a subfolder under the `content/de/` folder and copy the English source: ```shell mkdir -p content/de/docs/tutorials cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md ``` -Translation tools can speed up the translation process. For example, some editors offers plugins to quickly translate text. +Translation tools can speed up the translation process. For example, some editors offers plugins +to quickly translate text. {{< caution >}} -Machine-generated translation is insufficient on its own. Localization requires extensive human review to meet minimum standards of quality. +Machine-generated translation is insufficient on its own. Localization requires extensive human +review to meet minimum standards of quality. {{< /caution >}} -To ensure accuracy in grammar and meaning, members of your localization team should carefully review all machine-generated translations before publishing. +To ensure accuracy in grammar and meaning, members of your localization team should carefully +review all machine-generated translations before publishing. ### Source files @@ -280,17 +348,21 @@ To find source files for your target version: 1. Navigate to the Kubernetes website repository at https://github.com/kubernetes/website. 2. Select a branch for your target version from the following table: - Target version | Branch - -----|----- - Latest version | [`main`](https://github.com/kubernetes/website/tree/main) - Previous version | [`release-{{< skew prevMinorVersion >}}`](https://github.com/kubernetes/website/tree/release-{{< skew prevMinorVersion >}}) - Next version | [`dev-{{< skew nextMinorVersion >}}`](https://github.com/kubernetes/website/tree/dev-{{< skew nextMinorVersion >}}) -The `main` branch holds content for the current release `{{< latest-version >}}`. The release team will create a `{{< release-branch >}}` branch before the next release: v{{< skew nextMinorVersion >}}. + Target version | Branch + -----|----- + Latest version | [`main`](https://github.com/kubernetes/website/tree/main) + Previous version | [`release-{{< skew prevMinorVersion >}}`](https://github.com/kubernetes/website/tree/release-{{< skew prevMinorVersion >}}) + Next version | [`dev-{{< skew nextMinorVersion >}}`](https://github.com/kubernetes/website/tree/dev-{{< skew nextMinorVersion >}}) + +The `main` branch holds content for the current release `{{< latest-version >}}`. The release team +will create a `{{< release-branch >}}` branch before the next release: v{{< skew nextMinorVersion >}}. ### Site strings in i18n -Localizations must include the contents of [`data/i18n/en/en.toml`](https://github.com/kubernetes/website/blob/main/data/i18n/en/en.toml) in a new language-specific file. Using German as an example: `data/i18n/de/de.toml`. +Localizations must include the contents of +[`data/i18n/en/en.toml`](https://github.com/kubernetes/website/blob/main/data/i18n/en/en.toml) +in a new language-specific file. Using German as an example: `data/i18n/de/de.toml`. Add a new localization directory and file to `data/i18n/`. For example, with German (`de`): @@ -308,17 +380,22 @@ placeholder text for the search form: other = "Suchen" ``` -Localizing site strings lets you customize site-wide text and features: for example, the legal copyright text in the footer on each page. +Localizing site strings lets you customize site-wide text and features: for example, the legal +copyright text in the footer on each page. ### Language specific style guide and glossary -Some language teams have their own language-specific style guide and glossary. For example, see the [Korean Localization Guide](/ko/docs/contribute/localization_ko/). +Some language teams have their own language-specific style guide and glossary. +For example, see the [Korean Localization Guide](/ko/docs/contribute/localization_ko/). ### Language specific Zoom meetings -If the localization project needs a separate meeting time, contact a SIG Docs Co-Chair or Tech Lead to create a new reoccurring Zoom meeting and calendar invite. This is only needed when the the team is large enough to sustain and require a separate meeting. +If the localization project needs a separate meeting time, contact a SIG Docs Co-Chair or Tech +Lead to create a new reoccurring Zoom meeting and calendar invite. This is only needed when the +the team is large enough to sustain and require a separate meeting. -Per CNCF policy, the localization teams must upload their meetings to the SIG Docs YouTube playlist. A SIG Docs Co-Chair or Tech Lead can help with the process until SIG Docs automates it. +Per CNCF policy, the localization teams must upload their meetings to the SIG Docs YouTube +playlist. A SIG Docs Co-Chair or Tech Lead can help with the process until SIG Docs automates it. ## Branching strategy @@ -328,42 +405,66 @@ when starting out and the localization is not yet live. To collaborate on a localization branch: -1. A team member of [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) opens a localization branch from a source branch on https://github.com/kubernetes/website. +1. A team member of + [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) + opens a localization branch from a source branch on https://github.com/kubernetes/website. - Your team approvers joined the `@kubernetes/website-maintainers` team when you [added your localization team](#add-your-localization-team-in-github) to the [`kubernetes/org`](https://github.com/kubernetes/org) repository. + Your team approvers joined the `@kubernetes/website-maintainers` team when you + [added your localization team](#add-your-localization-team-in-github) to the + [`kubernetes/org`](https://github.com/kubernetes/org) repository. - We recommend the following branch naming scheme: + We recommend the following branch naming scheme: - `dev--.` + `dev--.` - For example, an approver on a German localization team opens the localization branch `dev-1.12-de.1` directly against the k/website repository, based on the source branch for Kubernetes v1.12. + For example, an approver on a German localization team opens the localization branch + `dev-1.12-de.1` directly against the k/website repository, based on the source branch for + Kubernetes v1.12. 2. Individual contributors open feature branches based on the localization branch. - For example, a German contributor opens a pull request with changes to `kubernetes:dev-1.12-de.1` from `username:local-branch-name`. + For example, a German contributor opens a pull request with changes to + `kubernetes:dev-1.12-de.1` from `username:local-branch-name`. 3. Approvers review and merge feature branches into the localization branch. -4. Periodically, an approver merges the localization branch to its source branch by opening and approving a new pull request. Be sure to squash the commits before approving the pull request. +4. Periodically, an approver merges the localization branch to its source branch by opening and + approving a new pull request. Be sure to squash the commits before approving the pull request. -Repeat steps 1-4 as needed until the localization is complete. For example, subsequent German localization branches would be: `dev-1.12-de.2`, `dev-1.12-de.3`, etc. +Repeat steps 1-4 as needed until the localization is complete. For example, subsequent German +localization branches would be: `dev-1.12-de.2`, `dev-1.12-de.3`, etc. Teams must merge localized content into the same branch from which the content was sourced. - For example: + - a localization branch sourced from `main` must be merged into `main`. -- a localization branch sourced from `release-{{% skew "prevMinorVersion" %}}` must be merged into `release-{{% skew "prevMinorVersion" %}}`. +- a localization branch sourced from `release-{{% skew "prevMinorVersion" %}}` must be merged into + `release-{{% skew "prevMinorVersion" %}}`. {{< note >}} -If your localization branch was created from `main` branch but it is not merged into `main` before new release branch `{{< release-branch >}}` created, merge it into both `main` and new release branch `{{< release-branch >}}`. To merge your localization branch into new release branch `{{< release-branch >}}`, you need to switch upstream branch of your localization branch to `{{< release-branch >}}`. +If your localization branch was created from `main` branch but it is not merged into `main` before +new release branch `{{< release-branch >}}` created, merge it into both `main` and new release +branch `{{< release-branch >}}`. To merge your localization branch into new release branch +`{{< release-branch >}}`, you need to switch upstream branch of your localization branch to +`{{< release-branch >}}`. {{< /note >}} -At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes between the previous localization branch and the current localization branch. There are two scripts for comparing upstream changes. [`upstream_changes.py`](https://github.com/kubernetes/website/tree/main/scripts#upstream_changespy) is useful for checking the changes made to a specific file. And [`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/main/scripts#diff_l10n_branchespy) is useful for creating a list of outdated files for a specific localization branch. +At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes +between the previous localization branch and the current localization branch. +There are two scripts for comparing upstream changes. -While only approvers can open a new localization branch and merge pull requests, anyone can open a pull request for a new localization branch. No special permissions are required. +- [`upstream_changes.py`](https://github.com/kubernetes/website/tree/main/scripts#upstream_changespy) + is useful for checking the changes made to a specific file. And +- [`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/main/scripts#diff_l10n_branchespy) + is useful for creating a list of outdated files for a specific localization branch. -For more information about working from forks or directly from the repository, see ["fork and clone the repo"](#fork-and-clone-the-repo). +While only approvers can open a new localization branch and merge pull requests, anyone can open a +pull request for a new localization branch. No special permissions are required. + +For more information about working from forks or directly from the repository, see +["fork and clone the repo"](#fork-and-clone-the-repo). ## Upstream contributions SIG Docs welcomes upstream contributions and corrections to the English source. + diff --git a/content/en/docs/contribute/suggesting-improvements.md b/content/en/docs/contribute/suggesting-improvements.md index 9cab3f7a72..d79df11476 100644 --- a/content/en/docs/contribute/suggesting-improvements.md +++ b/content/en/docs/contribute/suggesting-improvements.md @@ -1,6 +1,5 @@ --- title: Suggesting content improvements -slug: suggest-improvements content_type: concept weight: 10 card: From 2e5e4d2489ec0fc201b920409b368d5877ace8a6 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 18 Jun 2022 17:30:37 +0800 Subject: [PATCH 016/209] Reformat the extend-kubernetes page This page has too many long lines which make change tracking very difficult. --- .../docs/concepts/extend-kubernetes/_index.md | 152 ++++++++++++------ 1 file changed, 106 insertions(+), 46 deletions(-) diff --git a/content/en/docs/concepts/extend-kubernetes/_index.md b/content/en/docs/concepts/extend-kubernetes/_index.md index c50010a39f..5404f8c463 100644 --- a/content/en/docs/concepts/extend-kubernetes/_index.md +++ b/content/en/docs/concepts/extend-kubernetes/_index.md @@ -17,26 +17,29 @@ no_list: true -Kubernetes is highly configurable and extensible. As a result, -there is rarely a need to fork or submit patches to the Kubernetes -project code. +Kubernetes is highly configurable and extensible. As a result, there is rarely a need to fork or +submit patches to the Kubernetes project code. -This guide describes the options for customizing a Kubernetes -cluster. It is aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} who want to -understand how to adapt their Kubernetes cluster to the needs of -their work environment. Developers who are prospective {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} will also find it -useful as an introduction to what extension points and patterns -exist, and their trade-offs and limitations. +This guide describes the options for customizing a Kubernetes cluster. It is aimed at +{{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} who want to understand +how to adapt their Kubernetes cluster to the needs of their work environment. Developers who are +prospective {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} or +Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} will also +find it useful as an introduction to what extension points and patterns exist, and their +trade-offs and limitations. ## Overview -Customization approaches can be broadly divided into *configuration*, which only involves changing flags, local configuration files, or API resources; and *extensions*, which involve running additional programs or services. This document is primarily about extensions. +Customization approaches can be broadly divided into *configuration*, which only involves changing +flags, local configuration files, or API resources; and *extensions*, which involve running +additional programs or services. This document is primarily about extensions. ## Configuration -*Configuration files* and *flags* are documented in the Reference section of the online documentation, under each binary: +*Configuration files* and *flags* are documented in the Reference section of the online +documentation, under each binary: * [kubelet](/docs/reference/command-line-tools-reference/kubelet/) * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) @@ -44,9 +47,22 @@ Customization approaches can be broadly divided into *configuration*, which only * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). -Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options. +Flags and configuration files may not always be changeable in a hosted Kubernetes service or a +distribution with managed installation. When they are changeable, they are usually only changeable +by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and +setting them may require restarting processes. For those reasons, they should be used only when +there are no other options. -*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/security/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable. +*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), +[PodSecurityPolicies](/docs/concepts/security/pod-security-policy/), +[NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control +([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. +APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. +They are declarative and use the same conventions as other Kubernetes resources like pods, +so new cluster configuration can be repeatable and be managed the same way as applications. +And, where they are stable, they enjoy a +[defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. +For these reasons, they are preferred over *configuration files* and *flags* where suitable. ## Extensions @@ -70,10 +86,9 @@ There is a specific pattern for writing client programs that work well with Kubernetes called the *Controller* pattern. Controllers typically read an object's `.spec`, possibly do things, and then update the object's `.status`. -A controller is a client of Kubernetes. When Kubernetes is the client and -calls out to a remote service, it is called a *Webhook*. The remote service -is called a *Webhook Backend*. Like Controllers, Webhooks do add a point of -failure. +A controller is a client of Kubernetes. When Kubernetes is the client and calls out to a remote +service, it is called a *Webhook*. The remote service is called a *Webhook Backend*. Like +Controllers, Webhooks do add a point of failure. In the webhook model, Kubernetes makes a network request to a remote service. In the *Binary Plugin* model, Kubernetes executes a binary (program). @@ -95,15 +110,35 @@ This diagram shows the extension points in a Kubernetes system. ![Extension Points](/docs/concepts/extend-kubernetes/extension-points.png) -1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies. -2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](#api-access-extensions) section. -3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](#user-defined-types) section. Custom Resources are often used with API Access Extensions. -4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](#scheduler-extensions) section. -5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources. -6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](#network-plugins) allow for different implementations of pod networking. -7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](#storage-plugins). +1. Users often interact with the Kubernetes API using `kubectl`. + [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. + They only affect the individual user's local environment, and so cannot enforce site-wide policies. -If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions. +1. The API server handles all requests. Several types of extension points in the API server allow + authenticating requests, or blocking them based on their content, editing content, and handling + deletion. These are described in the [API Access Extensions](#api-access-extensions) section. + +1. The API server serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are + defined by the Kubernetes project and can't be changed. You can also add resources that you + define, or that other projects have defined, called *Custom Resources*, as explained in the + [Custom Resources](#user-defined-types) section. Custom Resources are often used with API access + extensions. + +1. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend + scheduling. These are described in the [Scheduler Extensions](#scheduler-extensions) section. + +1. Much of the behavior of Kubernetes is implemented by programs called Controllers which are + clients of the API server. Controllers are often used in conjunction with Custom Resources. + +1. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on + the cluster network. [Network Plugins](#network-plugins) allow for different implementations of + pod networking. + +1. The kubelet also mounts and unmounts volumes for containers. New types of storage can be + supported via [Storage Plugins](#storage-plugins). + +If you are unsure where to start, this flowchart can help. Note that some solutions may involve +several types of extensions. ![Flowchart for Extension](/docs/concepts/extend-kubernetes/flowchart.png) @@ -112,60 +147,86 @@ If you are unsure where to start, this flowchart can help. Note that some soluti ### User-Defined Types -Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such as `kubectl`. +Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application +configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such +as `kubectl`. Do not use a Custom Resource as data storage for application, user, or monitoring data. -For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). +For more about Custom Resources, see the +[Custom Resources concept guide](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). ### Combining New APIs with Automation -The combination of a custom resource API and a control loop is called the [Operator pattern](/docs/concepts/extend-kubernetes/operator/). The Operator pattern is used to manage specific, usually stateful, applications. These custom APIs and control loops can also be used to control other resources, such as storage or policies. +The combination of a custom resource API and a control loop is called the +[Operator pattern](/docs/concepts/extend-kubernetes/operator/). The Operator pattern is used to manage +specific, usually stateful, applications. These custom APIs and control loops can also be used to +control other resources, such as storage or policies. ### Changing Built-in Resources -When you extend the Kubernetes API by adding custom resources, the added resources always fall into a new API Groups. You cannot replace or change existing API groups. -Adding an API does not directly let you affect the behavior of existing APIs (e.g. Pods), but API Access Extensions do. +When you extend the Kubernetes API by adding custom resources, the added resources always fall +into a new API Groups. You cannot replace or change existing API groups. +Adding an API does not directly let you affect the behavior of existing APIs (e.g. Pods), but API +Access Extensions do. ### API Access Extensions -When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/) for more on this flow. +When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then +subject to various types of Admission Control. See +[Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/) +for more on this flow. Each of these steps offers extension points. -Kubernetes has several built-in authentication methods that it supports. It can also sit behind an authenticating proxy, and it can send a token from an Authorization header to a remote service for verification (a webhook). All of these methods are covered in the [Authentication documentation](/docs/reference/access-authn-authz/authentication/). +Kubernetes has several built-in authentication methods that it supports. It can also sit behind an +authenticating proxy, and it can send a token from an Authorization header to a remote service for +verification (a webhook). All of these methods are covered in the +[Authentication documentation](/docs/reference/access-authn-authz/authentication/). ### Authentication -[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates in all requests to a username for the client making the request. - -Kubernetes provides several built-in authentication methods, and an [Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) method if those don't meet your needs. +[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates +in all requests to a username for the client making the request. +Kubernetes provides several built-in authentication methods, and an +[Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) +method if those don't meet your needs. ### Authorization -[Authorization](/docs/reference/access-authn-authz/authorization/) determines whether specific users can read, write, and do other operations on API resources. It works at the level of whole resources -- it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision. - +[Authorization](/docs/reference/access-authn-authz/authorization/) determines whether specific +users can read, write, and do other operations on API resources. It works at the level of whole +resources -- it doesn't discriminate based on arbitrary object fields. If the built-in +authorization options don't meet your needs, [Authorization webhook](/docs/reference/access-authn-authz/webhook/) +allows calling out to user-provided code to make an authorization decision. ### Dynamic Admission Control -After a request is authorized, if it is a write operation, it also goes through [Admission Control](/docs/reference/access-authn-authz/admission-controllers/) steps. In addition to the built-in steps, there are several extensions: +After a request is authorized, if it is a write operation, it also goes through +[Admission Control](/docs/reference/access-authn-authz/admission-controllers/) steps. +In addition to the built-in steps, there are several extensions: -* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) restricts what images can be run in containers. -* To make arbitrary admission control decisions, a general [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) can be used. Admission Webhooks can reject creations or updates. +* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) + restricts what images can be run in containers. +* To make arbitrary admission control decisions, a general + [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) + can be used. Admission Webhooks can reject creations or updates. ## Infrastructure Extensions ### Storage Plugins -[Flex Volumes](https://git.k8s.io/design-proposals-archive/storage/flexvolume-deployment.md -) allow users to mount volume types without built-in support by having the -Kubelet call a Binary Plugin to mount the volume. - -FlexVolume is deprecated since Kubernetes v1.23. The Out-of-tree CSI driver is the recommended way to write volume drivers in Kubernetes. See [Kubernetes Volume Plugin FAQ for Storage Vendors](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors) for more information. +[Flex Volumes](https://git.k8s.io/design-proposals-archive/storage/flexvolume-deployment.md) +allow users to mount volume types without built-in support by having the kubelet call a binary +plugin to mount the volume. +FlexVolume is deprecated since Kubernetes v1.23. The out-of-tree CSI driver is the recommended way +to write volume drivers in Kubernetes. See +[Kubernetes Volume Plugin FAQ for Storage Vendors](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors) +for more information. ### Device Plugins @@ -173,7 +234,6 @@ Device plugins allow a node to discover new Node resources (in addition to the builtin ones like cpu and memory) via a [Device Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/). - ### Network Plugins Different networking fabrics can be supported via node-level From aa60715e8465b7cc2aa0bd9499bfbe6c0bda76db Mon Sep 17 00:00:00 2001 From: Rishit Dagli Date: Sat, 18 Jun 2022 11:48:00 +0000 Subject: [PATCH 017/209] Update Create a Custom Resource Definition Co-authored-by: Antonio Alonso Alarcon --- .../custom-resources/custom-resource-definitions.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md index cfe5cb2ad4..4bdc5ca55a 100644 --- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md @@ -28,11 +28,12 @@ the documentation for that version to see advice that is relevant for your clust ## Create a CustomResourceDefinition When you create a new CustomResourceDefinition (CRD), the Kubernetes API Server -creates a new RESTful resource path for each version you specify. The CRD can be -either namespaced or cluster-scoped, as specified in the CRD's `scope` field. As -with existing built-in objects, deleting a namespace deletes all custom objects -in that namespace. CustomResourceDefinitions themselves are non-namespaced and -are available to all namespaces. +creates a new RESTful resource path for each version you specify. The custom +resource created from a CRD object can be either namespaced or cluster-scoped, +as specified in the CRD's `spec.scope` field. As with existing built-in +objects, deleting a namespace deletes all custom objects in that namespace. +CustomResourceDefinitions themselves are non-namespaced and are available to +all namespaces. For example, if you save the following CustomResourceDefinition to `resourcedefinition.yaml`: From f8d5bdaa00005f9de62bf13de7b1cf6f47f7b438 Mon Sep 17 00:00:00 2001 From: vehagn Date: Sun, 19 Jun 2022 09:20:44 +0200 Subject: [PATCH 018/209] Update broken link from Packet to Equinix Metal The Kubespray documentation links to Packet which has now been renamed to Equinix Metal with a different link in the kubernetes-sigs/kubespray github repo. --- .../en/docs/setup/production-environment/tools/kubespray.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md index fd594b92f8..e0525562c6 100644 --- a/content/en/docs/setup/production-environment/tools/kubespray.md +++ b/content/en/docs/setup/production-environment/tools/kubespray.md @@ -6,7 +6,7 @@ weight: 30 -This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray). +This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Equinix Metal (formerly Packet), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray). Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides: @@ -46,7 +46,7 @@ Kubespray provides the following utilities to help provision your environment: * [Terraform](https://www.terraform.io/) scripts for the following cloud providers: * [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws) * [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack) - * [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet) + * [Equinix Metal](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/metal) ### (2/5) Compose an inventory file From 199c78c0f39c7d936b51c9532b1e5cb21363ebd3 Mon Sep 17 00:00:00 2001 From: cpanato Date: Mon, 20 Jun 2022 13:43:57 +0200 Subject: [PATCH 019/209] update patch schedule for July cycle Signed-off-by: cpanato --- content/en/releases/patch-releases.md | 5 ++++- data/releases/schedule.yaml | 27 ++++++++++++++++++--------- 2 files changed, 22 insertions(+), 10 deletions(-) diff --git a/content/en/releases/patch-releases.md b/content/en/releases/patch-releases.md index d0f56d19c3..8557945423 100644 --- a/content/en/releases/patch-releases.md +++ b/content/en/releases/patch-releases.md @@ -78,10 +78,10 @@ releases may also occur in between these. | Monthly Patch Release | Cherry Pick Deadline | Target date | | --------------------- | -------------------- | ----------- | -| June 2022 | 2022-06-10 | 2022-06-15 | | July 2022 | 2022-07-08 | 2022-07-13 | | August 2022 | 2022-08-12 | 2022-08-17 | | September 2022 | 2022-09-09 | 2022-09-14 | +| October 2022 | 2022-10-07 | 2022-10-12 | ## Detailed Release History for Active Branches @@ -93,6 +93,7 @@ End of Life for **1.24** is **2023-09-29** | PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE | |---------------|----------------------|-------------|------| +| 1.24.3 | 2022-07-08 | 2022-07-13 | | | 1.24.2 | 2022-06-10 | 2022-06-15 | | | 1.24.1 | 2022-05-20 | 2022-05-24 | | @@ -104,6 +105,7 @@ End of Life for **1.23** is **2023-02-28**. | Patch Release | Cherry Pick Deadline | Target Date | Note | |---------------|----------------------|-------------|------| +| 1.23.9 | 2022-07-08 | 2022-07-13 | | | 1.23.8 | 2022-06-10 | 2022-06-15 | | | 1.23.7 | 2022-05-20 | 2022-05-24 | | | 1.23.6 | 2022-04-08 | 2022-04-13 | | @@ -121,6 +123,7 @@ End of Life for **1.22** is **2022-10-28** | Patch Release | Cherry Pick Deadline | Target Date | Note | |---------------|----------------------|-------------|------| +| 1.22.12 | 2022-07-08 | 2022-07-13 | | | 1.22.11 | 2022-06-10 | 2022-06-15 | | | 1.22.10 | 2022-05-20 | 2022-05-24 | | | 1.22.9 | 2022-04-08 | 2022-04-13 | | diff --git a/data/releases/schedule.yaml b/data/releases/schedule.yaml index d00c37468a..735c0fcf68 100644 --- a/data/releases/schedule.yaml +++ b/data/releases/schedule.yaml @@ -1,21 +1,27 @@ schedules: - release: 1.24 releaseDate: 2022-05-03 - next: 1.24.2 - cherryPickDeadline: 2022-06-10 - targetDate: 2022-06-15 + next: 1.24.3 + cherryPickDeadline: 2022-07-08 + targetDate: 2022-07-13 endOfLifeDate: 2023-09-29 previousPatches: + - release: 1.24.2 + cherryPickDeadline: 2022-06-10 + targetDate: 2022-06-15 - release: 1.24.1 cherryPickDeadline: 2022-05-20 targetDate: 2022-05-24 - release: 1.23 releaseDate: 2021-12-07 - next: 1.23.8 - cherryPickDeadline: 2022-06-10 - targetDate: 2022-06-15 + next: 1.23.9 + cherryPickDeadline: 2022-07-08 + targetDate: 2022-07-13 endOfLifeDate: 2023-02-28 previousPatches: + - release: 1.23.8 + cherryPickDeadline: 2022-06-10 + targetDate: 2022-06-15 - release: 1.23.7 cherryPickDeadline: 2022-05-20 targetDate: 2022-05-24 @@ -40,11 +46,14 @@ schedules: targetDate: 2021-12-16 - release: 1.22 releaseDate: 2021-08-04 - next: 1.22.11 - cherryPickDeadline: 2022-06-10 - targetDate: 2022-06-15 + next: 1.22.12 + cherryPickDeadline: 2022-07-08 + targetDate: 2022-07-13 endOfLifeDate: 2022-10-28 previousPatches: + - release: 1.22.11 + cherryPickDeadline: 2022-06-10 + targetDate: 2022-06-15 - release: 1.22.10 cherryPickDeadline: 2022-05-20 targetDate: 2022-05-24 From 1897dfba16e4654dd2887b92f92326abc9b3430f Mon Sep 17 00:00:00 2001 From: cpanato Date: Mon, 20 Jun 2022 13:44:25 +0200 Subject: [PATCH 020/209] remove v1.21 release from the schedule due to EOL Signed-off-by: cpanato --- content/en/releases/patch-releases.md | 24 +------------- data/releases/schedule.yaml | 47 --------------------------- 2 files changed, 1 insertion(+), 70 deletions(-) diff --git a/content/en/releases/patch-releases.md b/content/en/releases/patch-releases.md index 8557945423..91bdcc58bb 100644 --- a/content/en/releases/patch-releases.md +++ b/content/en/releases/patch-releases.md @@ -136,35 +136,13 @@ End of Life for **1.22** is **2022-10-28** | 1.22.2 | 2021-09-10 | 2021-09-15 | | | 1.22.1 | 2021-08-16 | 2021-08-19 | | -### 1.21 - -**1.21** enters maintenance mode on **2022-04-28** - -End of Life for **1.21** is **2022-06-28** - -| Patch Release | Cherry Pick Deadline | Target Date | Note | -| ------------- | -------------------- | ----------- | ------------------------------------------------------------------------ | -| 1.21.14 | 2022-06-10 | 2022-06-15 | If there is any critical issues to be released otherwise will be skipped | -| 1.21.13 | 2022-05-20 | 2022-05-24 | | -| 1.21.12 | 2022-04-08 | 2022-04-13 | | -| 1.21.11 | 2022-03-11 | 2022-03-16 | | -| 1.21.10 | 2022-02-11 | 2022-02-16 | | -| 1.21.9 | 2022-01-14 | 2022-01-19 | | -| 1.21.8 | 2021-12-10 | 2021-12-15 | | -| 1.21.7 | 2021-11-12 | 2021-11-17 | | -| 1.21.6 | 2021-10-22 | 2021-10-27 | | -| 1.21.5 | 2021-09-10 | 2021-09-15 | | -| 1.21.4 | 2021-08-07 | 2021-08-11 | | -| 1.21.3 | 2021-07-10 | 2021-07-14 | | -| 1.21.2 | 2021-06-12 | 2021-06-16 | | -| 1.21.1 | 2021-05-07 | 2021-05-12 | [Regression](https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs) | - ## Non-Active Branch History These releases are no longer supported. | Minor Version | Final Patch Release | EOL Date | Note | | ------------- | ------------------- | ---------- | ---------------------------------------------------------------------- | +| 1.21 | 1.21.14 | 2022-06-28 | | | 1.20 | 1.20.15 | 2022-02-28 | | | 1.19 | 1.19.16 | 2021-10-28 | | | 1.18 | 1.18.20 | 2021-06-18 | Created to resolve regression introduced in 1.18.19 | diff --git a/data/releases/schedule.yaml b/data/releases/schedule.yaml index 735c0fcf68..a88fb511a7 100644 --- a/data/releases/schedule.yaml +++ b/data/releases/schedule.yaml @@ -84,50 +84,3 @@ schedules: - release: 1.22.1 cherryPickDeadline: 2021-08-16 targetDate: 2021-08-19 -- release: 1.21 - releaseDate: 2021-04-08 - next: 1.21.14 - cherryPickDeadline: 2022-06-10 - targetDate: 2022-06-15 - endOfLifeDate: 2022-06-28 - previousPatches: - - release: 1.21.13 - cherryPickDeadline: 2022-05-20 - targetDate: 2022-05-24 - - release: 1.21.12 - cherryPickDeadline: 2022-04-08 - targetDate: 2022-04-13 - - release: 1.21.11 - cherryPickDeadline: 2022-03-11 - targetDate: 2022-03-16 - - release: 1.21.10 - cherryPickDeadline: 2022-02-11 - targetDate: 2022-02-16 - - release: 1.21.9 - cherryPickDeadline: 2022-01-14 - targetDate: 2022-01-19 - - release: 1.21.8 - cherryPickDeadline: 2021-12-10 - targetDate: 2021-12-15 - - release: 1.21.7 - cherryPickDeadline: 2021-11-12 - targetDate: 2021-11-17 - - release: 1.21.6 - cherryPickDeadline: 2021-10-22 - targetDate: 2021-10-27 - - release: 1.21.5 - cherryPickDeadline: 2021-09-10 - targetDate: 2021-09-15 - - release: 1.21.4 - cherryPickDeadline: 2021-08-07 - targetDate: 2021-08-11 - - release: 1.21.3 - cherryPickDeadline: 2021-07-10 - targetDate: 2021-07-14 - - release: 1.21.2 - cherryPickDeadline: 2021-06-12 - targetDate: 2021-06-16 - - release: 1.21.1 - cherryPickDeadline: 2021-05-07 - targetDate: 2021-05-12 - note: Regression https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs From 31bc7698f8920bf13fc8aa58184530afd6e9b526 Mon Sep 17 00:00:00 2001 From: Manuel Fontan Date: Mon, 20 Jun 2022 20:21:58 +0100 Subject: [PATCH 021/209] Update task-tutorial-prereqs.md ## Description Remove Katacoda playground reference ## Why Katacoda.com is now closed --- content/en/includes/task-tutorial-prereqs.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/en/includes/task-tutorial-prereqs.md b/content/en/includes/task-tutorial-prereqs.md index b5d3c0abf3..4d627a0df1 100644 --- a/content/en/includes/task-tutorial-prereqs.md +++ b/content/en/includes/task-tutorial-prereqs.md @@ -2,7 +2,6 @@ You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using [minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/) -or you can use one of these Kubernetes playgrounds: +or you can use this Kubernetes playground: -* [Katacoda](https://www.katacoda.com/courses/kubernetes/playground) * [Play with Kubernetes](http://labs.play-with-k8s.com/) From 9b5e2aec1b2c9ed19c49f3c589a8f1cdc77df939 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 18 Jun 2022 15:30:05 +0800 Subject: [PATCH 022/209] Fix links in some pages This PR fixes some links that are using redirect records or dangling. --- content/en/docs/contribute/_index.md | 2 +- content/en/docs/contribute/advanced.md | 2 +- .../en/docs/contribute/participate/_index.md | 2 +- .../participate/roles-and-responsibilities.md | 2 +- .../docs/contribute/review/reviewing-prs.md | 77 ++++++++++++------- .../container-runtimes.md | 4 +- .../tools/kubeadm/create-cluster-kubeadm.md | 12 ++- 7 files changed, 62 insertions(+), 39 deletions(-) diff --git a/content/en/docs/contribute/_index.md b/content/en/docs/contribute/_index.md index 8627e8dd93..b4c7d838fa 100644 --- a/content/en/docs/contribute/_index.md +++ b/content/en/docs/contribute/_index.md @@ -145,7 +145,7 @@ class first,second white {{}} Figure 2. Preparation for your first contribution. -- Read the [Contribution overview](/docs/contribute/new-content/overview/) to +- Read the [Contribution overview](/docs/contribute/new-content/) to learn about the different ways you can contribute. - Check [`kubernetes/website` issues list](https://github.com/kubernetes/website/issues/) for issues that make good entry points. diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md index 34e0107035..b825ad5e2c 100644 --- a/content/en/docs/contribute/advanced.md +++ b/content/en/docs/contribute/advanced.md @@ -8,7 +8,7 @@ weight: 98 This page assumes that you understand how to -[contribute to new content](/docs/contribute/new-content/overview) and +[contribute to new content](/docs/contribute/new-content/) and [review others' work](/docs/contribute/review/reviewing-prs/), and are ready to learn about more ways to contribute. You need to use the Git command line client and other tools for some of these tasks. diff --git a/content/en/docs/contribute/participate/_index.md b/content/en/docs/contribute/participate/_index.md index ff4714f803..b76423eded 100644 --- a/content/en/docs/contribute/participate/_index.md +++ b/content/en/docs/contribute/participate/_index.md @@ -115,6 +115,6 @@ SIG Docs approvers. Here's how it works. For more information about contributing to the Kubernetes documentation, see: -- [Contributing new content](/docs/contribute/new-content/overview/) +- [Contributing new content](/docs/contribute/new-content/) - [Reviewing content](/docs/contribute/review/reviewing-prs) - [Documentation style guide](/docs/contribute/style/) diff --git a/content/en/docs/contribute/participate/roles-and-responsibilities.md b/content/en/docs/contribute/participate/roles-and-responsibilities.md index c577c3f8be..10d6072ce3 100644 --- a/content/en/docs/contribute/participate/roles-and-responsibilities.md +++ b/content/en/docs/contribute/participate/roles-and-responsibilities.md @@ -32,7 +32,7 @@ Anyone can: - Suggest improvements on [Slack](https://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). -After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also: +After [signing the CLA](https://github.com/kubernetes/community/blob/master/CLA.md), anyone can also: - Open a pull request to improve existing content, add new content, or write a blog post or case study - Create diagrams, graphics assets, and embeddable screencasts and videos diff --git a/content/en/docs/contribute/review/reviewing-prs.md b/content/en/docs/contribute/review/reviewing-prs.md index 5a5bbce533..54b209dc0e 100644 --- a/content/en/docs/contribute/review/reviewing-prs.md +++ b/content/en/docs/contribute/review/reviewing-prs.md @@ -7,7 +7,8 @@ weight: 10 -Anyone can review a documentation pull request. Visit the [pull requests](https://github.com/kubernetes/website/pulls) section in the Kubernetes website repository to see open pull requests. +Anyone can review a documentation pull request. Visit the [pull requests](https://github.com/kubernetes/website/pulls) +section in the Kubernetes website repository to see open pull requests. Reviewing documentation pull requests is a great way to introduce yourself to the Kubernetes community. @@ -27,7 +28,9 @@ Before reviewing, it's a good idea to: Before you start a review: -- Read the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) and ensure that you abide by it at all times. + +- Read the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) + and ensure that you abide by it at all times. - Be polite, considerate, and helpful. - Comment on positive aspects of PRs as well as changes. - Be empathetic and mindful of how your review may be received. @@ -36,7 +39,8 @@ Before you start a review: ## Review process -In general, review pull requests for content and style in English. Figure 1 outlines the steps for the review process. The details for each step follow. +In general, review pull requests for content and style in English. Figure 1 outlines the steps for +the review process. The details for each step follow. @@ -69,32 +73,39 @@ class third,fourth white Figure 1. Review process steps. -1. Go to - [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls). - You see a list of every open pull request against the Kubernetes website and - docs. +1. Go to [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls). + You see a list of every open pull request against the Kubernetes website and docs. -2. Filter the open PRs using one or all of the following labels: - - `cncf-cla: yes` (Recommended): PRs submitted by contributors who have not signed the CLA cannot be merged. See [Sign the CLA](/docs/contribute/new-content/overview/#sign-the-cla) for more information. - - `language/en` (Recommended): Filters for english language PRs only. - - `size/`: filters for PRs of a certain size. If you're new, start with smaller PRs. +2. Filter the open PRs using one or all of the following labels: - Additionally, ensure the PR isn't marked as a work in progress. PRs using the `work in progress` label are not ready for review yet. + - `cncf-cla: yes` (Recommended): PRs submitted by contributors who have not signed the CLA + cannot be merged. See [Sign the CLA](/docs/contribute/new-content/#sign-the-cla) + for more information. + - `language/en` (Recommended): Filters for english language PRs only. + - `size/`: filters for PRs of a certain size. If you're new, start with smaller PRs. -3. Once you've selected a PR to review, understand the change by: - - Reading the PR description to understand the changes made, and read any linked issues - - Reading any comments by other reviewers - - Clicking the **Files changed** tab to see the files and lines changed - - Previewing the changes in the Netlify preview build by scrolling to the PR's build check section at the bottom of the **Conversation** tab. - Here's a screenshot (this shows GitHub's desktop site; if you're reviewing - on a tablet or smartphone device, the GitHub web UI is slightly different): - {{< figure src="/images/docs/github_netlify_deploy_preview.png" alt="GitHub pull request details including link to Netlify preview" >}} - To open the preview, click on the **Details** link of the **deploy/netlify** line in the list of checks. + Additionally, ensure the PR isn't marked as a work in progress. PRs using the `work in + progress` label are not ready for review yet. -4. Go to the **Files changed** tab to start your review. - 1. Click on the `+` symbol beside the line you want to comment on. - 2. Fill in any comments you have about the line and click either **Add single comment** (if you have only one comment to make) or **Start a review** (if you have multiple comments to make). - 3. When finished, click **Review changes** at the top of the page. Here, you can add +3. Once you've selected a PR to review, understand the change by: + + - Reading the PR description to understand the changes made, and read any linked issues + - Reading any comments by other reviewers + - Clicking the **Files changed** tab to see the files and lines changed + - Previewing the changes in the Netlify preview build by scrolling to the PR's build check + section at the bottom of the **Conversation** tab. + Here's a screenshot (this shows GitHub's desktop site; if you're reviewing + on a tablet or smartphone device, the GitHub web UI is slightly different): + {{< figure src="/images/docs/github_netlify_deploy_preview.png" alt="GitHub pull request details including link to Netlify preview" >}} + To open the preview, click on the **Details** link of the **deploy/netlify** line in the + list of checks. + +4. Go to the **Files changed** tab to start your review. + + 1. Click on the `+` symbol beside the line you want to comment on. + 1. Fill in any comments you have about the line and click either **Add single comment** (if you + have only one comment to make) or **Start a review** (if you have multiple comments to make). + 1. When finished, click **Review changes** at the top of the page. Here, you can add a summary of your review (and leave some positive comments for the contributor!), approve the PR, comment or request changes as needed. New contributors should always choose **Comment**. @@ -119,14 +130,22 @@ When reviewing, use the following as a starting point. ### Website -- Did this PR change or remove a page title, slug/alias or anchor link? If so, are there broken links as a result of this PR? Is there another option, like changing the page title without changing the slug? +- Did this PR change or remove a page title, slug/alias or anchor link? If so, are there broken + links as a result of this PR? Is there another option, like changing the page title without + changing the slug? + - Does the PR introduce a new page? If so: - - Is the page using the right [page content type](/docs/contribute/style/page-content-types/) and associated Hugo shortcodes? + + - Is the page using the right [page content type](/docs/contribute/style/page-content-types/) + and associated Hugo shortcodes? - Does the page appear correctly in the section's side navigation (or at all)? - Should the page appear on the [Docs Home](/docs/home/) listing? -- Do the changes show up in the Netlify preview? Be particularly vigilant about lists, code blocks, tables, notes and images. + +- Do the changes show up in the Netlify preview? Be particularly vigilant about lists, code + blocks, tables, notes and images. ### Other -For small issues with a PR, like typos or whitespace, prefix your comments with `nit:`. This lets the author know the issue is non-critical. +For small issues with a PR, like typos or whitespace, prefix your comments with `nit:`. +This lets the author know the issue is non-critical. diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index deaee23022..dd432afd3d 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -36,8 +36,8 @@ part of Kubernetes (this removal was [announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation) as part of the v1.20 release). You can read -[Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) to understand how this removal might -affect you. To learn about migrating from using dockershim, see +[Check whether Dockershim removal affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) +to understand how this removal might affect you. To learn about migrating from using dockershim, see [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/). If you are running a version of Kubernetes other than v{{< skew currentVersion >}}, diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index 220a72bce5..eedee3b5a3 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -91,7 +91,8 @@ to not download the default container images which are hosted at `k8s.gcr.io`. Kubeadm has commands that can help you pre-pull the required images when creating a cluster without an internet connection on its nodes. -See [Running kubeadm without an internet connection](/docs/reference/setup-tools/kubeadm/kubeadm-init#without-internet-connection) for more details. +See [Running kubeadm without an internet connection](/docs/reference/setup-tools/kubeadm/kubeadm-init#without-internet-connection) +for more details. Kubeadm allows you to use a custom image repository for the required images. See [Using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init#custom-images) @@ -365,7 +366,8 @@ The output is similar to this: 5didvk.d09sbcov8ph2amjw ``` -If you don't have the value of `--discovery-token-ca-cert-hash`, you can get it by running the following command chain on the control-plane node: +If you don't have the value of `--discovery-token-ca-cert-hash`, you can get it by running the +following command chain on the control-plane node: ```bash openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \ @@ -506,7 +508,7 @@ options. * Verify that your cluster is running properly with [Sonobuoy](https://github.com/heptio/sonobuoy) * See [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) for details about upgrading your cluster using `kubeadm`. -* Learn about advanced `kubeadm` usage in the [kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/kubeadm) +* Learn about advanced `kubeadm` usage in the [kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/) * Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/). * See the [Cluster Networking](/docs/concepts/cluster-administration/networking/) page for a bigger list of Pod network add-ons. @@ -613,4 +615,6 @@ supports your chosen platform. ## Troubleshooting {#troubleshooting} -If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/). +If you are running into difficulties with kubeadm, please consult our +[troubleshooting docs](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/). + From 9f5c01ca6f9a85c20eef86fccddc3011e81daa26 Mon Sep 17 00:00:00 2001 From: Michael Date: Thu, 16 Jun 2022 22:32:47 +0800 Subject: [PATCH 023/209] [zh] resyn ref-k8s-api-config: volume-attachment-v1.md --- .../volume-attachment-v1.md | 690 ++++++++++++++++++ 1 file changed, 690 insertions(+) create mode 100644 content/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/volume-attachment-v1.md diff --git a/content/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/volume-attachment-v1.md b/content/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/volume-attachment-v1.md new file mode 100644 index 0000000000..ef5a7772d0 --- /dev/null +++ b/content/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/volume-attachment-v1.md @@ -0,0 +1,690 @@ +--- +api_metadata: + apiVersion: "storage.k8s.io/v1" + import: "k8s.io/api/storage/v1" + kind: "VolumeAttachment" +content_type: "api_reference" +description: "VolumeAttachment 抓取将指定卷挂接到指定节点或从指定节点解除挂接指定卷的意图。" +title: "VolumeAttachment" +weight: 7 +--- + + +`apiVersion: storage.k8s.io/v1` + +`import "k8s.io/api/storage/v1"` + +## VolumeAttachment {#VolumeAttachment} + +VolumeAttachment 抓取将指定卷挂接到指定节点或从指定节点解除挂接指定卷的意图。 + +VolumeAttachment 对象未划分命名空间。 + +
+ +- **apiVersion**: storage.k8s.io/v1 +- **kind**: VolumeAttachment + + +- **metadata** (}}">ObjectMeta) + 标准的对象元数据。更多信息： + https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + +- **spec** (}}">VolumeAttachmentSpec)，必需 + 期望的挂接/解除挂接卷行为的规约。由 Kubernetes 系统填充。 + + +- **status** (}}">VolumeAttachmentStatus) + VolumeAttachment 请求的状态。由完成挂接或解除挂接操作的实体（即外部挂接器）进行填充。 + +## VolumeAttachmentSpec {#VolumeAttachmentSpec} + +VolumeAttachmentSpec 是 VolumeAttachment 请求的规约。 + +
+ + +- **attacher** (string)，必需 + attacher 表示必须处理此请求的卷驱动的名称。这是由 GetPluginName() 返回的名称。 + +- **nodeName** (string)，必需 + 卷应挂接到的节点。 + + +- **source** (VolumeAttachmentSource)，必需 + source 表示应挂接的卷。 + + + **VolumeAttachmentSource 表示应挂接的卷。现在只能通过外部挂接器挂接 PersistenVolume， + 将来我们可能还允许 Pod 中的内联卷。只能设置一个成员。** + + - **source.inlineVolumeSpec** (}}">PersistentVolumeSpec) + + inlineVolumeSpec 包含挂接由 Pod 的内联 VolumeSource 定义的持久卷时所有必需的信息。 + 仅为 CSIMigation 功能填充此字段。 + 它包含从 Pod 的内联 VolumeSource 转换为 PersistentVolumeSpec 的字段。 + 此字段处于 beta 阶段，且只有启用 CSIMigration 功能的服务器才能使用此字段。 + + - **source.persistentVolumeName** (string) + 要挂接的持久卷的名称。 + +## VolumeAttachmentStatus {#VolumeAttachmentStatus} + +VolumeAttachmentStatus 是 VolumeAttachment 请求的状态。 + +
+ +- **attached** (boolean)，必需 + 表示卷被成功挂接。此字段只能由完成挂接操作的实体（例如外部挂接器）进行设置。 + + +- **attachError** (VolumeError) + 挂接操作期间遇到的最后一个错误，如果有。 + 此字段只能由完成挂接操作的实体（例如外部挂接器）进行设置。 + + + **VolumeError 抓取卷操作期间遇到的一个错误。** + + - **attachError.message** (string) + 此字符串详细说明挂接或解除挂接操作期间遇到的错误。 + 此字符串可以放入日志，因此它不应包含敏感信息。 + + - **attachError.time** (Time) + 遇到错误的时间。 + + + **time 是 time.Time 的包装类，支持正确地序列化为 YAML 和 JSON。 + 为 time 包提供的许多工厂方法提供了包装类。** + + +- **attachmentMetadata** (map[string]string) + 成功挂接时，此字段将由挂接操作返回的任何信息进行填充， + 这些信息必须传递到后续的 WaitForAttach 或 Mount 调用中。 + 此字段只能由完成挂接操作的实体（例如外部挂接器）进行设置。 + + +- **detachError** (VolumeError) + 解除挂接操作期间遇到的最后一个错误，如果有。 + 此字段只能由完成解除挂接操作的实体（例如外部挂接器）进行设置。 + + + **VolumeError 抓取卷操作期间遇到的一个错误。** + + - **detachError.message** (string) + 此字符串详细说明挂接或解除挂接操作期间遇到的错误。 + 此字符串可以放入日志，因此它不应包含敏感信息。 + + - **detachError.time** (Time) + 遇到错误的时间。 + + + **time 是 time.Time 的包装类，支持正确地序列化为 YAML 和 JSON。 + 为 time 包提供的许多工厂方法提供了包装类。** + +## VolumeAttachmentList {#VolumeAttachmentList} + +VolumeAttachmentList 是 VolumeAttachment 对象的集合。 + +
+ +- **apiVersion**: storage.k8s.io/v1 +- **kind**: VolumeAttachmentList + + +- **metadata** (}}">ListMeta) + 标准的列表元数据。更多信息： + https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + +- **items** ([]}}">VolumeAttachment)，必需 + items 是 VolumeAttachment 的列表。 + + +## 操作 {#Operations} +
+ +### `get` 读取指定的 VolumeAttachment +#### HTTP 请求 + +GET /apis/storage.k8s.io/v1/volumeattachments/{name} + + +#### 参数 +- **name** (**路径参数**): string，必需 + VolumeAttachment 的名称 + +- **pretty** (**查询参数**): string + }}">pretty + + +#### 响应 +200 (}}">VolumeAttachment): OK + +401: Unauthorized + + +### `get` 读取指定的 VolumeAttachment 的状态 +#### HTTP 请求 +GET /apis/storage.k8s.io/v1/volumeattachments/{name}/status + + +#### 参数 +- **name** (**路径参数**): string，必需 + VolumeAttachment 的名称 + +- **pretty** (**查询参数**): string + }}">pretty + + +#### 响应 +200 (}}">VolumeAttachment): OK + +401: Unauthorized + + +### `list` 列出或观测类别为 VolumeAttachment 的对象 +#### HTTP 请求 +GET /apis/storage.k8s.io/v1/volumeattachments + + +#### 参数 +- **allowWatchBookmarks** (**查询参数**): boolean + }}">allowWatchBookmarks + +- **continue** (**查询参数**): string + }}">continue + +- **fieldSelector** (**查询参数**): string + }}">fieldSelector + +- **labelSelector** (**查询参数**): string + }}">labelSelector + +- **limit** (**查询参数**): integer + }}">limit + +- **pretty** (**查询参数**): string + }}">pretty + +- **resourceVersion** (**查询参数**): string + }}">resourceVersion + +- **resourceVersionMatch** (**查询参数**): string + }}">resourceVersionMatch + +- **timeoutSeconds** (**查询参数**): integer + }}">timeoutSeconds + +- **watch** (**查询参数**): boolean + }}">watch + + +#### 响应 +200 (}}">VolumeAttachmentList): OK + +401: Unauthorized + + +### `create` 创建 VolumeAttachment +#### HTTP 请求 +POST /apis/storage.k8s.io/v1/volumeattachments + + +#### 参数 +- **body**: }}">VolumeAttachment，必需 +- **dryRun** (**查询参数**): string + }}">dryRun + +- **fieldManager** (**查询参数**): string + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + }}">fieldValidation + +- **pretty** (**查询参数**): string + }}">pretty + + +#### 响应 +200 (}}">VolumeAttachment): OK + +201 (}}">VolumeAttachment): Created + +202 (}}">VolumeAttachment): Accepted + +401: Unauthorized + + +### `update` 替换指定的 VolumeAttachment +#### HTTP 请求 +PUT /apis/storage.k8s.io/v1/volumeattachments/{name} + + +#### 参数 +- **name** (**路径参数**): string，必需 + VolumeAttachment 的名称 + +- **body**: }}">VolumeAttachment，必需 +- **dryRun** (**查询参数**): string + }}">dryRun + +- **fieldManager** (**查询参数**): string + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + }}">fieldValidation + +- **pretty** (**查询参数**): string + }}">pretty + + +#### 响应 +200 (}}">VolumeAttachment): OK + +201 (}}">VolumeAttachment): Created + +401: Unauthorized + + +### `update` 替换指定的 VolumeAttachment 的状态 +#### HTTP 请求 +PUT /apis/storage.k8s.io/v1/volumeattachments/{name}/status + + +#### 参数 +- **name** (**路径参数**): string，必需 + VolumeAttachment 的名称 + +- **body**: }}">VolumeAttachment，必需 +- **dryRun** (**查询参数**): string + }}">dryRun + +- **fieldManager** (**查询参数**): string + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + }}">fieldValidation + +- **pretty** (**查询参数**): string + }}">pretty + + +#### 响应 +200 (}}">VolumeAttachment): OK + +201 (}}">VolumeAttachment): Created + +401: Unauthorized + + +### `patch` 部分更新指定的 VolumeAttachment +#### HTTP 请求 +PATCH /apis/storage.k8s.io/v1/volumeattachments/{name} + + +#### 参数 +- **name** (**路径参数**): string，必需 + VolumeAttachment 的名称 + +- **body**: }}">Patch，必需 +- **dryRun** (**查询参数**): string + }}">dryRun + +- **fieldManager** (**查询参数**): string + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + }}">fieldValidation + +- **force** (**查询参数**): boolean + }}">force + +- **pretty** (**查询参数**): string + }}">pretty + + +#### 响应 +200 (}}">VolumeAttachment): OK + +201 (}}">VolumeAttachment): Created + +401: Unauthorized + + +### `patch` 部分更新指定的 VolumeAttachment 的状态 +#### HTTP 请求 +PATCH /apis/storage.k8s.io/v1/volumeattachments/{name}/status + + +#### 参数 +- **name** (**路径参数**): string，必需 + VolumeAttachment 的名称 + +- **body**: }}">Patch，必需 +- **dryRun** (**查询参数**): string + }}">dryRun + +- **fieldManager** (**查询参数**): string + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + }}">fieldValidation + +- **force** (**查询参数**): boolean + }}">force + +- **pretty** (**查询参数**): string + }}">pretty + + +#### 响应 +200 (}}">VolumeAttachment): OK + +201 (}}">VolumeAttachment): Created + +401: Unauthorized + + +### `delete` 删除 VolumeAttachment +#### HTTP 请求 +DELETE /apis/storage.k8s.io/v1/volumeattachments/{name} + + +#### 参数 +- **name** (**路径参数**): string，必需 + VolumeAttachment 的名称 + +- **body**: }}">DeleteOptions +- **dryRun** (**查询参数**): string + }}">dryRun + +- **gracePeriodSeconds** (**查询参数**): integer + }}">gracePeriodSeconds + +- **pretty** (**查询参数**): string + }}">pretty + +- **propagationPolicy** (**查询参数**): string + }}">propagationPolicy + + +#### 响应 +200 (}}">VolumeAttachment): OK + +202 (}}">VolumeAttachment): Accepted + +401: Unauthorized + + +### `deletecollection` 删除 VolumeAttachment 的集合 +#### HTTP 请求 +DELETE /apis/storage.k8s.io/v1/volumeattachments + + +#### 参数 +- **body**: }}">DeleteOptions +- **continue** (**查询参数**): string + }}">continue + +- **dryRun** (**查询参数**): string + }}">dryRun + +- **fieldSelector** (**查询参数**): string + }}">fieldSelector + +- **gracePeriodSeconds** (**查询参数**): integer + }}">gracePeriodSeconds + +- **labelSelector** (**查询参数**): string + }}">labelSelector + +- **limit** (**查询参数**): integer + }}">limit + +- **pretty** (**查询参数**): string + }}">pretty + +- **propagationPolicy** (**查询参数**): string + }}">propagationPolicy + +- **resourceVersion** (**查询参数**): string + }}">resourceVersion + +- **resourceVersionMatch** (**查询参数**): string + }}">resourceVersionMatch + +- **timeoutSeconds** (**查询参数**): integer + }}">timeoutSeconds + + +#### 响应 +200 (}}">Status): OK + +401: Unauthorized From c1055ca471048735d980c88041932515a766cbc7 Mon Sep 17 00:00:00 2001 From: liuzhilin Date: Tue, 21 Jun 2022 20:36:31 +0800 Subject: [PATCH 024/209] Translate docs/reference/kubernetes-api/cluster-resources/lease-v1 --- .../cluster-resources/lease-v1.md | 1074 +++++++++++++++++ 1 file changed, 1074 insertions(+) create mode 100644 content/zh-cn/docs/reference/kubernetes-api/cluster-resources/lease-v1.md diff --git a/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/lease-v1.md b/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/lease-v1.md new file mode 100644 index 0000000000..8aa5453f44 --- /dev/null +++ b/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/lease-v1.md @@ -0,0 +1,1074 @@ +--- +api_metadata: + apiVersion: "coordination.k8s.io/v1" + import: "k8s.io/api/coordination/v1" + kind: "Lease" +content_type: "api_reference" +description: "Lease defines a lease concept." +title: "Lease" +weight: 5 +auto_generated: true +--- + + + +`apiVersion: coordination.k8s.io/v1` + +`import "k8s.io/api/coordination/v1"` + + +## Lease {#Lease} + +Lease 定义了lease 的概念。 +
+ +- **apiVersion**: coordination.k8s.io/v1 + + +- **kind**: Lease + + +- **metadata** (}}">ObjectMeta) + + + 更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + +- **spec** (}}">LeaseSpec) + + + 租赁规范。更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status + + + + +## LeaseSpec {#LeaseSpec} + + +LeaseSpec 是一个 Lease 的规范。 + +
+ + +- **acquireTime** (MicroTime) + + acquireTime 是当前租赁被获取的时间。 + + + *MicroTime 是微妙级精确时间的版本。* + +- **holderIdentity** (string) + + holderIdentity 包含当前租约持有人的身份。 + +- **leaseDurationSeconds** (int32) + + leaseDurationSeconds 是租约候选人需要等待强制获取租约的持续时间。这是相对于上次观察到的更新时间的度量。 + +- **leaseTransitions** (int32) + + LeasetTransitions 是租约持有人之间的转换次数。 + +- **renewTime** (MicroTime) + + renewTime是当前租约持有人上次更新租约的时间。 + + + *MicroTime是具有微秒级精度的时间版本。* + + + + +## LeaseList {#LeaseList} + + +LeaseList是租赁对象的列表。 + +
+ +- **apiVersion**: coordination.k8s.io/v1 + + +- **kind**: LeaseList + + +- **metadata** (}}">ListMeta) + + + 标准列表元数据。更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + +- **items** ([]}}">Lease), required + + + Items 是架构对象的列表。 + + + + +## 操作 {#operations} + + +
+ + + + + + +### `get` 读取指定的租约 + +#### HTTP 请求 + +GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} + +#### 参数 + + +- **name** (*路径参数*): string, 必需 + + 租约名称 + +- **namespace** (*路径参数*): string, 必需 + + }}">namespace + +- **pretty** (*查询参数*): string + + }}">pretty + + +#### 响应 + +200 (}}">Lease): OK + +401: Unauthorized + + +### `list` 列出或监视租赁类对象 + +#### HTTP 请求 + +GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases + + +#### 参数 + + +- **namespace** (*路径参数*): string, 必需 + + }}">namespace + + +- **allowWatchBookmarks** (*查询参数*): boolean + + }}">allowWatchBookmarks + + +- **continue** (*查询参数*): string + + }}">continue + + +- **fieldSelector** (*查询参数*): string + + }}">fieldSelector + + +- **labelSelector** (*查询参数*): string + + }}">labelSelector + + +- **limit** (*查询参数*): integer + + }}">limit + + +- **pretty** (*查询参数*): string + + }}">pretty + + +- **resourceVersion** (*查询参数*): string + + }}">resourceVersion + +- **resourceVersionMatch** (*查询参数*): string + + }}">resourceVersionMatch + + +- **timeoutSeconds** (*查询参数*): integer + + }}">timeoutSeconds + + +- **watch** (*查询参数*): boolean + + }}">watch + + +#### 响应 + +200 (}}">LeaseList): OK + +401: Unauthorized + + +### `list` 列出或监视租赁类对象 + +#### HTTP 请求 + +GET /apis/coordination.k8s.io/v1/leases + + +#### 参数 + + +- **allowWatchBookmarks** (*查询参数*): boolean + + }}">allowWatchBookmarks + + +- **continue** (*查询参数*): string + + }}">continue + + +- **fieldSelector** (*查询参数*): string + + }}">fieldSelector + + +- **labelSelector** (*查询参数*): string + + }}">labelSelector + + +- **limit** (*查询参数*): integer + + }}">limit + + +- **pretty** (*查询参数*): string + + }}">pretty + +- **resourceVersion** (*查询参数*): string + + }}">resourceVersion + +- **resourceVersionMatch** (*查询参数*): string + + }}">resourceVersionMatch + + +- **timeoutSeconds** (*查询参数*): integer + + }}">timeoutSeconds + + +- **watch** (*查询参数*): boolean + + }}">watch + + +#### 响应 + + +200 (}}">LeaseList): OK + +401: Unauthorized + + +### `create` 创建租约 + +#### HTTP 请求 + +POST /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases + + +#### 参数 + + +- **namespace** (*路径参数*): string, 必需 + + }}">namespace + + +- **body**: }}">Lease, 必需 + + + + +- **dryRun** (*查询参数*): string + + }}">dryRun + + +- **fieldManager** (*查询参数*): string + + }}">fieldManager + + +- **fieldValidation** (*查询参数*): string + + }}">fieldValidation + + +- **pretty** (*查询参数*): string + + }}">pretty + + +#### 响应 + + +200 (}}">Lease): OK + +201 (}}">Lease): Created + +202 (}}">Lease): Accepted + +401: Unauthorized + + +### `update` 替换指定的租约 + +#### HTTP 请求 + +PUT /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} + +#### 参数 + + +- **name** (*路径参数*): string, 必需 + + 租约名称 + + +- **namespace** (*路径参数*): string, 必需 + + }}">namespace + + +- **body**: }}">Lease, 必需 + + + + +- **dryRun** (*查询参数*): string + + }}">dryRun + + +- **fieldManager** (*查询参数*): string + + }}">fieldManager + + +- **fieldValidation** (*查询参数*): string + + }}">fieldValidation + +- **pretty** (*查询参数*): string + + }}">pretty + + +#### 响应 + + +200 (}}">Lease): OK + +201 (}}">Lease): Created + +401: Unauthorized + + +### `patch` 部分更新指定的租约 + +#### HTTP 请求 + +PATCH /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} + +#### 参数 + + +- **name** (*路径参数*): string, 必需 + + 租约名称 + + +- **namespace** (*路径参数*): string, 必需 + + }}">namespace + + +- **body**: }}">Patch, 必需 + + + + +- **dryRun** (*查询参数*): string + + }}">dryRun + + +- **fieldManager** (*查询参数*): string + + }}">fieldManager + + +- **fieldValidation** (*查询参数*): string + + }}">fieldValidation + + +- **force** (*查询参数*): boolean + + }}">force + + +- **pretty** (*查询参数*): string + + }}">pretty + + +#### 响应 + + +200 (}}">Lease): OK + +201 (}}">Lease): Created + +401: Unauthorized + + +### `delete` 删除一个租约 + +#### HTTP 请求 + +DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} + +#### 参数 + + +- **name** (*路径参数*): string, 必需 + + 租约的名称 + + +- **namespace** (*路径参数*): string, 必需 + + }}">namespace + + +- **body**: }}">DeleteOptions + + + + +- **dryRun** (*查询参数*): string + + }}">dryRun + + +- **gracePeriodSeconds** (*查询参数*): integer + + }}">gracePeriodSeconds + + +- **pretty** (*查询参数*): string + + }}">pretty + + +- **propagationPolicy** (*查询参数*): string + + }}">propagationPolicy + + +#### 响应 + + +200 (}}">Status): OK + +202 (}}">Status): Accepted + +401: Unauthorized + + +### `deletecollection` 删除租赁收款 + +#### HTTP 请求 + +DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases + +#### 参数 + + +- **namespace** (*路径参数*): string, 必需 + + }}">namespace + + +- **body**: }}">DeleteOptions + + + + +- **continue** (*查询参数*): string + + }}">continue + + +- **dryRun** (*查询参数*): string + + }}">dryRun + + +- **fieldSelector** (*查询参数*): string + + }}">fieldSelector + + +- **gracePeriodSeconds** (*查询参数*): integer + + }}">gracePeriodSeconds + + +- **labelSelector** (*查询参数*): string + + }}">labelSelector + + +- **limit** (*查询参数*): integer + + }}">limit + + +- **pretty** (*查询参数*): string + + }}">pretty + + +- **propagationPolicy** (*查询参数*): string + + }}">propagationPolicy + + +- **resourceVersion** (*查询参数*): string + + }}">resourceVersion + + +- **resourceVersionMatch** (*查询参数*): string + + }}">resourceVersionMatch + + +- **timeoutSeconds** (*查询参数*): integer + + }}">timeoutSeconds + + +#### 响应 + + +200 (}}">Status): OK + +401: Unauthorized + From 04d79a37c5c9736df6df0c4f499c4dba37aef39a Mon Sep 17 00:00:00 2001 From: X723166587 Date: Tue, 21 Jun 2022 21:17:29 +0800 Subject: [PATCH 025/209] [zh] added internal LB service annotations for Oracle Cloud (OCI) Apply PR #32743 corrections to Chinese content --- .../docs/concepts/services-networking/service.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/content/zh-cn/docs/concepts/services-networking/service.md b/content/zh-cn/docs/concepts/services-networking/service.md index 71140bf426..0b594b0ebc 100644 --- a/content/zh-cn/docs/concepts/services-networking/service.md +++ b/content/zh-cn/docs/concepts/services-networking/service.md @@ -1407,6 +1407,17 @@ metadata: [...] ``` +{{% /tab %}} +{{% tab name="OCI" %}} + +```yaml +[...] +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/oci-load-balancer-internal: true +[...] +``` {{% /tab %}} {{< /tabs >}} From 2f2a4d5bae9f45392516e521a4570f4f7d730150 Mon Sep 17 00:00:00 2001 From: Brandon Richard <56069278+Kwazimolo@users.noreply.github.com> Date: Tue, 21 Jun 2022 15:04:37 +0100 Subject: [PATCH 026/209] Updated cheatsheet.md with 'get taints' command Updated the kubectl cheat sheet (cheatsheet.md) with a command for viewing taints which exists on current nodes. --- content/en/docs/reference/kubectl/cheatsheet.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index 3f96fd6e4c..03fbff2f78 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -381,6 +381,9 @@ kubectl cluster-info # Display kubectl cluster-info dump # Dump current cluster state to stdout kubectl cluster-info dump --output-directory=/path/to/cluster-state # Dump current cluster state to /path/to/cluster-state +# View existing taints on which exist on current nodes. +kubectl get nodes -o=custom-columns=NodeName:.metadata.name,TaintKey:.spec.taints[*].key,TaintValue:.spec.taints[*].value,TaintEffect:.spec.taints[*].effect + # If a taint with that key and effect already exists, its value is replaced as specified. kubectl taint nodes foo dedicated=special-user:NoSchedule ``` From 58cf632e9910715af48ef56961ecdeb895adddfa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?rom=C3=A3o?= Date: Tue, 21 Jun 2022 21:27:09 -0300 Subject: [PATCH 027/209] Update persistent-volumes.md Adding an forgotten blank space. --- content/pt-br/docs/concepts/storage/persistent-volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt-br/docs/concepts/storage/persistent-volumes.md b/content/pt-br/docs/concepts/storage/persistent-volumes.md index 75b8e86fe0..12ff2700fe 100644 --- a/content/pt-br/docs/concepts/storage/persistent-volumes.md +++ b/content/pt-br/docs/concepts/storage/persistent-volumes.md @@ -22,7 +22,7 @@ O gerenciamento de armazenamento é uma questão bem diferente do gerenciamento Um _PersistentVolume_ (PV) é uma parte do armazenamento dentro do cluster que tenha sido provisionada por um administrador, ou dinamicamente utilizando [Classes de Armazenamento](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó também é. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do armazenamento, seja ele NFS, iSCSI, ou um armazenamento específico de um provedor de cloud pública. -Uma_PersistentVolumeClaim_ (PVC) é uma requisição para armazenamento por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem solicitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [Modos de Acesso](#modos-de-acesso)). +Uma _PersistentVolumeClaim_ (PVC) é uma requisição para armazenamento por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem solicitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [Modos de Acesso](#modos-de-acesso)). Enquanto as PersistentVolumeClaims permitem que um usuário utilize recursos de armazenamento de forma limitada, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como desempenho, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que difiram em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essas, temos o recurso de _StorageClass_. From 75b7fce11f17e89a8ccdb02f5809b8bf107f604c Mon Sep 17 00:00:00 2001 From: "paul.zhang" Date: Wed, 22 Jun 2022 17:28:48 +0800 Subject: [PATCH 028/209] Add anchor:#modify-kubelet-configmap Add anchor:#modify-kubelet-configmap --- .../administer-cluster/kubeadm/configure-cgroup-driver.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md b/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md index 97fa2bc352..8fa57ea894 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md @@ -73,7 +73,7 @@ To use `cgroupfs` and to prevent `kubeadm upgrade` from modifying the about its value. This applies to a case where you do not wish future versions of kubeadm to apply the `systemd` driver by default. -See the below section on "Modify the kubelet ConfigMap" for details on +See the below section on "[Modify the kubelet ConfigMap](#modify-kubelet-configmap)" for details on how to be explicit about the value. If you wish to configure a container runtime to use the `cgroupfs` driver, @@ -92,7 +92,7 @@ before joining the new nodes and ensuring the workloads can safely move to the n nodes before deleting the old nodes. {{< /note >}} -### Modify the kubelet ConfigMap +### Modify the kubelet ConfigMap {#modify-kubelet-configmap} - Call `kubectl edit cm kubelet-config -n kube-system`. - Either modify the existing `cgroupDriver` value or add a new field that looks like this: From cdd00696da52c1e7be03e6aa11748707574b15c3 Mon Sep 17 00:00:00 2001 From: liuzhilin Date: Wed, 22 Jun 2022 18:15:30 +0800 Subject: [PATCH 029/209] Translate docs/reference/kubernetes-api/cluster-resources/lease-v1 --- .../cluster-resources/lease-v1.md | 158 +++++++++--------- 1 file changed, 79 insertions(+), 79 deletions(-) diff --git a/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/lease-v1.md b/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/lease-v1.md index 8aa5453f44..25ba32aa53 100644 --- a/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/lease-v1.md +++ b/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/lease-v1.md @@ -30,7 +30,7 @@ guide. You can file document formatting bugs against the -Lease 定义了lease 的概念。 +Lease 定义了租贷的概念。
- **apiVersion**: coordination.k8s.io/v1 @@ -44,14 +44,14 @@ Lease 定义了lease 的概念。 - 更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + 更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata - **spec** (}}">LeaseSpec) - 租赁规范。更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status + 租贷规范。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status @@ -61,7 +61,7 @@ Lease 定义了lease 的概念。 -LeaseSpec 是一个 Lease 的规范。 +LeaseSpec 是一个租贷的规范。
@@ -97,7 +97,7 @@ LeaseSpec 是一个 Lease 的规范。 acquireTime 是当前租赁被获取的时间。 - *MicroTime 是微妙级精确时间的版本。* + **MicroTime 是微秒级精确时间的版本。** - **holderIdentity** (string) @@ -113,10 +113,10 @@ LeaseSpec 是一个 Lease 的规范。 - **renewTime** (MicroTime) - renewTime是当前租约持有人上次更新租约的时间。 + renewTime 是当前租约持有人上次更新租约的时间。 - *MicroTime是具有微秒级精度的时间版本。* + **MicroTime 是具有微秒级精度的时间版本。** @@ -126,7 +126,7 @@ LeaseSpec 是一个 Lease 的规范。 -LeaseList是租赁对象的列表。 +LeaseList 是租贷对象的列表。
@@ -141,7 +141,7 @@ LeaseList是租赁对象的列表。 - 标准列表元数据。更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + 标准列表元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata - **items** ([]}}">Lease), required @@ -173,7 +173,7 @@ GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} #### Parameters --> -### `get` 读取指定的租约 +### `get` 读取指定的租贷 #### HTTP 请求 @@ -196,15 +196,15 @@ GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} }}">pretty --> -- **name** (*路径参数*): string, 必需 +- **name** (**路径参数**): string, 必需 租约名称 -- **namespace** (*路径参数*): string, 必需 +- **namespace** (**路径参数**): string, 必需 }}">namespace -- **pretty** (*查询参数*): string +- **pretty** (**查询参数**): string }}">pretty @@ -291,56 +291,56 @@ GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases #### 参数 -- **namespace** (*路径参数*): string, 必需 +- **namespace** (**路径参数**): string, 必需 }}">namespace -- **allowWatchBookmarks** (*查询参数*): boolean +- **allowWatchBookmarks** (**查询参数**): boolean }}">allowWatchBookmarks -- **continue** (*查询参数*): string +- **continue** (**查询参数**): string }}">continue -- **fieldSelector** (*查询参数*): string +- **fieldSelector** (**查询参数**): string }}">fieldSelector -- **labelSelector** (*查询参数*): string +- **labelSelector** (**查询参数**): string }}">labelSelector -- **limit** (*查询参数*): integer +- **limit** (**查询参数**): integer }}">limit -- **pretty** (*查询参数*): string +- **pretty** (**查询参数**): string }}">pretty -- **resourceVersion** (*查询参数*): string +- **resourceVersion** (**查询参数**): string }}">resourceVersion -- **resourceVersionMatch** (*查询参数*): string +- **resourceVersionMatch** (**查询参数**): string }}">resourceVersionMatch -- **timeoutSeconds** (*查询参数*): integer +- **timeoutSeconds** (**查询参数**): integer }}">timeoutSeconds -- **watch** (*查询参数*): boolean +- **watch** (**查询参数**): boolean }}">watch @@ -358,7 +358,7 @@ GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases #### HTTP Request --> -### `list` 列出或监视租赁类对象 +### `list` 列出或监视租贷类对象 #### HTTP 请求 @@ -420,50 +420,50 @@ GET /apis/coordination.k8s.io/v1/leases #### 参数 -- **allowWatchBookmarks** (*查询参数*): boolean +- **allowWatchBookmarks** (**查询参数**): boolean }}">allowWatchBookmarks -- **continue** (*查询参数*): string +- **continue** (**查询参数**): string }}">continue -- **fieldSelector** (*查询参数*): string +- **fieldSelector** (**查询参数**): string }}">fieldSelector -- **labelSelector** (*查询参数*): string +- **labelSelector** (**查询参数**): string }}">labelSelector -- **limit** (*查询参数*): integer +- **limit** (**查询参数**): integer }}">limit -- **pretty** (*查询参数*): string +- **pretty** (**查询参数**): string }}">pretty -- **resourceVersion** (*查询参数*): string +- **resourceVersion** (**查询参数**): string }}">resourceVersion -- **resourceVersionMatch** (*查询参数*): string +- **resourceVersionMatch** (**查询参数**): string }}">resourceVersionMatch -- **timeoutSeconds** (*查询参数*): integer +- **timeoutSeconds** (**查询参数**): integer }}">timeoutSeconds -- **watch** (*查询参数*): boolean +- **watch** (**查询参数**): boolean }}">watch @@ -489,7 +489,7 @@ GET /apis/coordination.k8s.io/v1/leases POST /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases --> -### `create` 创建租约 +### `create` 创建租贷 #### HTTP 请求 @@ -531,7 +531,7 @@ POST /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases #### 参数 -- **namespace** (*路径参数*): string, 必需 +- **namespace** (**路径参数**): string, 必需 }}">namespace @@ -541,22 +541,22 @@ POST /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases -- **dryRun** (*查询参数*): string +- **dryRun** (**查询参数**): string }}">dryRun -- **fieldManager** (*查询参数*): string +- **fieldManager** (**查询参数**): string }}">fieldManager -- **fieldValidation** (*查询参数*): string +- **fieldValidation** (**查询参数**): string }}">fieldValidation -- **pretty** (*查询参数*): string +- **pretty** (**查询参数**): string }}">pretty @@ -590,7 +590,7 @@ POST /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases PUT /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} --> -### `update` 替换指定的租约 +### `update` 替换指定的租贷 #### HTTP 请求 @@ -636,12 +636,12 @@ PUT /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} #### 参数 -- **name** (*路径参数*): string, 必需 +- **name** (**路径参数**): string, 必需 - 租约名称 + 租贷名称 -- **namespace** (*路径参数*): string, 必需 +- **namespace** (**路径参数**): string, 必需 }}">namespace @@ -651,21 +651,21 @@ PUT /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} -- **dryRun** (*查询参数*): string +- **dryRun** (**查询参数**): string }}">dryRun -- **fieldManager** (*查询参数*): string +- **fieldManager** (**查询参数**): string }}">fieldManager -- **fieldValidation** (*查询参数*): string +- **fieldValidation** (**查询参数**): string }}">fieldValidation -- **pretty** (*查询参数*): string +- **pretty** (**查询参数**): string }}">pretty @@ -695,7 +695,7 @@ PUT /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} PATCH /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} --> -### `patch` 部分更新指定的租约 +### `patch` 部分更新指定的租贷 #### HTTP 请求 @@ -746,12 +746,12 @@ PATCH /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} #### 参数 -- **name** (*路径参数*): string, 必需 +- **name** (**路径参数**): string, 必需 - 租约名称 + 租贷名称 -- **namespace** (*路径参数*): string, 必需 +- **namespace** (**路径参数**): string, 必需 }}">namespace @@ -761,27 +761,27 @@ PATCH /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} -- **dryRun** (*查询参数*): string +- **dryRun** (**查询参数**): string }}">dryRun -- **fieldManager** (*查询参数*): string +- **fieldManager** (**查询参数**): string }}">fieldManager -- **fieldValidation** (*查询参数*): string +- **fieldValidation** (**查询参数**): string }}">fieldValidation -- **force** (*查询参数*): boolean +- **force** (**查询参数**): boolean }}">force -- **pretty** (*查询参数*): string +- **pretty** (**查询参数**): string }}">pretty @@ -811,7 +811,7 @@ PATCH /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} --> -### `delete` 删除一个租约 +### `delete` 删除一个租贷 #### HTTP 请求 @@ -857,12 +857,12 @@ DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} #### 参数 -- **name** (*路径参数*): string, 必需 +- **name** (**路径参数**): string, 必需 - 租约的名称 + 租贷的名称 -- **namespace** (*路径参数*): string, 必需 +- **namespace** (**路径参数**): string, 必需 }}">namespace @@ -872,22 +872,22 @@ DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} -- **dryRun** (*查询参数*): string +- **dryRun** (**查询参数**): string }}">dryRun -- **gracePeriodSeconds** (*查询参数*): integer +- **gracePeriodSeconds** (**查询参数**): integer }}">gracePeriodSeconds -- **pretty** (*查询参数*): string +- **pretty** (**查询参数**): string }}">pretty -- **propagationPolicy** (*查询参数*): string +- **propagationPolicy** (**查询参数**): string }}">propagationPolicy @@ -917,7 +917,7 @@ DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases --> -### `deletecollection` 删除租赁收款 +### `deletecollection` 删除租贷收款 #### HTTP 请求 @@ -993,7 +993,7 @@ DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases #### 参数 -- **namespace** (*路径参数*): string, 必需 +- **namespace** (**路径参数**): string, 必需 }}">namespace @@ -1003,57 +1003,57 @@ DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases -- **continue** (*查询参数*): string +- **continue** (**查询参数**): string }}">continue -- **dryRun** (*查询参数*): string +- **dryRun** (**查询参数**): string }}">dryRun -- **fieldSelector** (*查询参数*): string +- **fieldSelector** (**查询参数**): string }}">fieldSelector -- **gracePeriodSeconds** (*查询参数*): integer +- **gracePeriodSeconds** (**查询参数**): integer }}">gracePeriodSeconds -- **labelSelector** (*查询参数*): string +- **labelSelector** (**查询参数**): string }}">labelSelector -- **limit** (*查询参数*): integer +- **limit** (**查询参数**): integer }}">limit -- **pretty** (*查询参数*): string +- **pretty** (**查询参数**): string }}">pretty -- **propagationPolicy** (*查询参数*): string +- **propagationPolicy** (**查询参数**): string }}">propagationPolicy -- **resourceVersion** (*查询参数*): string +- **resourceVersion** (**查询参数**): string }}">resourceVersion -- **resourceVersionMatch** (*查询参数*): string +- **resourceVersionMatch** (**查询参数**): string }}">resourceVersionMatch -- **timeoutSeconds** (*查询参数*): integer +- **timeoutSeconds** (**查询参数**): integer }}">timeoutSeconds From 75719d7cf59a6fca85a50b6ce6ba89081abc8563 Mon Sep 17 00:00:00 2001 From: ayush Date: Wed, 22 Jun 2022 20:58:58 +0530 Subject: [PATCH 030/209] changed links changed --- content/en/blog/_posts/2021-04-22-gateway-api/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/blog/_posts/2021-04-22-gateway-api/index.md b/content/en/blog/_posts/2021-04-22-gateway-api/index.md index c22d45cdbb..145554803d 100644 --- a/content/en/blog/_posts/2021-04-22-gateway-api/index.md +++ b/content/en/blog/_posts/2021-04-22-gateway-api/index.md @@ -30,9 +30,9 @@ This led to design principles that allow the Gateway API to improve upon Ingress The Gateway API introduces a few new resource types: -- **[GatewayClasses](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.GatewayClass)** are cluster-scoped resources that act as templates to explicitly define behavior for Gateways derived from them. This is similar in concept to StorageClasses, but for networking data-planes. -- **[Gateways](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.Gateway)** are the deployed instances of GatewayClasses. They are the logical representation of the data-plane which performs routing, which may be in-cluster proxies, hardware LBs, or cloud LBs. -- **Routes** are not a single resource, but represent many different protocol-specific Route resources. The [HTTPRoute](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRoute) has matching, filtering, and routing rules that get applied to Gateways that can process HTTP and HTTPS traffic. Similarly, there are [TCPRoutes](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.TCPRoute), [UDPRoutes](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.UDPRoute), and [TLSRoutes](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.TLSRoute) which also have protocol-specific semantics. This model also allows the Gateway API to incrementally expand its protocol support in the future. +- **[GatewayClasses](https://gateway-api.sigs.k8s.io/concepts/api-overview/#gatewayclass)** are cluster-scoped resources that act as templates to explicitly define behavior for Gateways derived from them. This is similar in concept to StorageClasses, but for networking data-planes. +- **[Gateways](https://gateway-api.sigs.k8s.io/concepts/api-overview/#gateway)** are the deployed instances of GatewayClasses. They are the logical representation of the data-plane which performs routing, which may be in-cluster proxies, hardware LBs, or cloud LBs. +- **Routes** are not a single resource, but represent many different protocol-specific Route resources. The [HTTPRoute](https://gateway-api.sigs.k8s.io/concepts/api-overview/#httproute) has matching, filtering, and routing rules that get applied to Gateways that can process HTTP and HTTPS traffic. Similarly, there are [TCPRoutes](https://gateway-api.sigs.k8s.io/concepts/api-overview/#tcproute-and-udproute), [UDPRoutes](https://gateway-api.sigs.k8s.io/concepts/api-overview/#tcproute-and-udproute), and [TLSRoutes](https://gateway-api.sigs.k8s.io/concepts/api-overview/#gateway) which also have protocol-specific semantics. This model also allows the Gateway API to incrementally expand its protocol support in the future. ![The resources of the Gateway API](gateway-api-resources.png) From 22a1fab7c137df4d632e37bf815047dd7bc3660b Mon Sep 17 00:00:00 2001 From: Dominik-K <5795847+Dominik-K@users.noreply.github.com> Date: Wed, 22 Jun 2022 18:44:14 +0200 Subject: [PATCH 031/209] blog: 2020-09-03-warnings: correct `removed_release` label Used since introduction in code: https://github.com/kubernetes/kubernetes/commit/e4bb1daecf36aac3051d36a20dfdf7ea3050de58#diff-c4f07ee44a4626c817dd95cf30e147a2125ea923804be5c3608fb4a845fc1c20R69 --- content/en/blog/_posts/2020-09-03-warnings/index.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/content/en/blog/_posts/2020-09-03-warnings/index.md b/content/en/blog/_posts/2020-09-03-warnings/index.md index 082aa72f6f..07d64ef77a 100644 --- a/content/en/blog/_posts/2020-09-03-warnings/index.md +++ b/content/en/blog/_posts/2020-09-03-warnings/index.md @@ -60,7 +60,7 @@ so we added two administrator-facing tools to help track use of deprecated APIs Starting in Kubernetes v1.19, when a request is made to a deprecated REST API endpoint, an `apiserver_requested_deprecated_apis` gauge metric is set to `1` in the kube-apiserver process. This metric has labels for the API `group`, `version`, `resource`, and `subresource`, -and a `removed_version` label that indicates the Kubernetes release in which the API will no longer be served. +and a `removed_release` label that indicates the Kubernetes release in which the API will no longer be served. This is an example query using `kubectl`, [prom2json](https://github.com/prometheus/prom2json), and [jq](https://stedolan.github.io/jq/) to determine which deprecated APIs have been requested @@ -169,7 +169,7 @@ You can also find that information through the following Prometheus query, which returns information about requests made to deprecated APIs which will be removed in v1.22: ```promql -apiserver_requested_deprecated_apis{removed_version="1.22"} * on(group,version,resource,subresource) +apiserver_requested_deprecated_apis{removed_release="1.22"} * on(group,version,resource,subresource) group_right() apiserver_request_total ``` @@ -328,3 +328,7 @@ A couple areas we're looking at next are warning about [known problematic values we cannot reject outright for compatibility reasons, and warning about use of deprecated fields or field values (like selectors using beta os/arch node labels, [deprecated in v1.14](/docs/reference/labels-annotations-taints/#beta-kubernetes-io-arch-deprecated)). I'm excited to see progress in this area, continuing to make it easier to use Kubernetes. + + +## EDIT +* The correct label is `removed_release`, not `removed_version`. From 8fba55fd141d3c3742501259bd3434e606a591b4 Mon Sep 17 00:00:00 2001 From: CatherineF-dev Date: Wed, 22 Jun 2022 13:19:02 -0400 Subject: [PATCH 032/209] Update 2021-09-03-api-server-tracing.md Add etcd required version 3.5+ in blog `API Server Tracing` --- content/en/blog/_posts/2021-09-03-api-server-tracing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2021-09-03-api-server-tracing.md b/content/en/blog/_posts/2021-09-03-api-server-tracing.md index fc98a68d23..344ff8fa46 100644 --- a/content/en/blog/_posts/2021-09-03-api-server-tracing.md +++ b/content/en/blog/_posts/2021-09-03-api-server-tracing.md @@ -42,7 +42,7 @@ samplingRatePerMillion: 10000 ### Enabling Etcd Tracing -Add `--experimental-enable-distributed-tracing`, `--experimental-distributed-tracing-address=0.0.0.0:4317`, `--experimental-distributed-tracing-service-name=etcd` flags to etcd to enable tracing. Note that this traces every request, so it will probably generate a lot of traces if you enable it. +Add `--experimental-enable-distributed-tracing`, `--experimental-distributed-tracing-address=0.0.0.0:4317`, `--experimental-distributed-tracing-service-name=etcd` flags to etcd to enable tracing. Note that this traces every request, so it will probably generate a lot of traces if you enable it. Required etcd version is [v3.5+](https://etcd.io/docs/v3.5/op-guide/monitoring/#distributed-tracing). ### Example Trace: List Nodes From 7bbdc5d83e5023beb7aebed21088b903b069e87e Mon Sep 17 00:00:00 2001 From: Marcelo Juchem Date: Wed, 22 Jun 2022 19:13:35 -0500 Subject: [PATCH 033/209] client-libraries.md: adding C client library link --- content/en/docs/reference/using-api/client-libraries.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/docs/reference/using-api/client-libraries.md b/content/en/docs/reference/using-api/client-libraries.md index 8647198fe9..ad95ee188d 100644 --- a/content/en/docs/reference/using-api/client-libraries.md +++ b/content/en/docs/reference/using-api/client-libraries.md @@ -36,6 +36,7 @@ The following client libraries are officially maintained by | Java | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [browse](https://github.com/kubernetes-client/java#installation) | JavaScript | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [browse](https://github.com/kubernetes-client/javascript/tree/master/examples) | Python | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [browse](https://github.com/kubernetes-client/python/tree/master/examples) +| C | [github.com/kubernetes-client/c](https://github.com/kubernetes-client/c/) | [browse](https://github.com/kubernetes-client/c/tree/master/examples) ## Community-maintained client libraries From 6040ce1f30abfee97abdbe97b46e42523e682a85 Mon Sep 17 00:00:00 2001 From: "paul.zhang" Date: Thu, 23 Jun 2022 09:14:12 +0800 Subject: [PATCH 034/209] Update configure-cgroup-driver.md --- .../administer-cluster/kubeadm/configure-cgroup-driver.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md b/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md index 8fa57ea894..72435fb3b8 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md @@ -73,7 +73,7 @@ To use `cgroupfs` and to prevent `kubeadm upgrade` from modifying the about its value. This applies to a case where you do not wish future versions of kubeadm to apply the `systemd` driver by default. -See the below section on "[Modify the kubelet ConfigMap](#modify-kubelet-configmap)" for details on +See the below section on "[Modify the kubelet ConfigMap](#modify-the-kubelet-configmap)" for details on how to be explicit about the value. If you wish to configure a container runtime to use the `cgroupfs` driver, @@ -92,7 +92,7 @@ before joining the new nodes and ensuring the workloads can safely move to the n nodes before deleting the old nodes. {{< /note >}} -### Modify the kubelet ConfigMap {#modify-kubelet-configmap} +### Modify the kubelet ConfigMap {#modify-the-kubelet-configmap} - Call `kubectl edit cm kubelet-config -n kube-system`. - Either modify the existing `cgroupDriver` value or add a new field that looks like this: From 06a51d10c97243ec7a949fd5a26a6996a6fb27e8 Mon Sep 17 00:00:00 2001 From: liuzhilin Date: Thu, 23 Jun 2022 10:11:03 +0800 Subject: [PATCH 035/209] Translate docs/reference/kubernetes-api/cluster-resources/lease-v1 --- .../cluster-resources/lease-v1.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/lease-v1.md b/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/lease-v1.md index 25ba32aa53..3b2f519039 100644 --- a/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/lease-v1.md +++ b/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/lease-v1.md @@ -30,7 +30,7 @@ guide. You can file document formatting bugs against the -Lease 定义了租贷的概念。 +Lease 定义了租赁的概念。
- **apiVersion**: coordination.k8s.io/v1 @@ -61,7 +61,7 @@ Lease 定义了租贷的概念。 -LeaseSpec 是一个租贷的规范。 +LeaseSpec 是一个租赁的规范。
@@ -126,7 +126,7 @@ LeaseSpec 是一个租贷的规范。 -LeaseList 是租贷对象的列表。 +LeaseList 是租赁对象的列表。
@@ -173,7 +173,7 @@ GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} #### Parameters --> -### `get` 读取指定的租贷 +### `get` 读取指定的租赁 #### HTTP 请求 @@ -198,7 +198,7 @@ GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} --> - **name** (**路径参数**): string, 必需 - 租约名称 + 租赁名称 - **namespace** (**路径参数**): string, 必需 @@ -358,7 +358,7 @@ GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases #### HTTP Request --> -### `list` 列出或监视租贷类对象 +### `list` 列出或监视租赁类对象 #### HTTP 请求 @@ -489,7 +489,7 @@ GET /apis/coordination.k8s.io/v1/leases POST /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases --> -### `create` 创建租贷 +### `create` 创建租赁 #### HTTP 请求 @@ -590,7 +590,7 @@ POST /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases PUT /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} --> -### `update` 替换指定的租贷 +### `update` 替换指定的租赁 #### HTTP 请求 @@ -695,7 +695,7 @@ PUT /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} PATCH /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} --> -### `patch` 部分更新指定的租贷 +### `patch` 部分更新指定的租赁 #### HTTP 请求 @@ -811,7 +811,7 @@ PATCH /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} --> -### `delete` 删除一个租贷 +### `delete` 删除一个租赁 #### HTTP 请求 @@ -917,7 +917,7 @@ DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases --> -### `deletecollection` 删除租贷收款 +### `deletecollection` 删除租赁收款 #### HTTP 请求 From 299afad15da663b2319976b0db1df3cdeac50d8b Mon Sep 17 00:00:00 2001 From: liuzhilin Date: Thu, 23 Jun 2022 11:11:40 +0800 Subject: [PATCH 036/209] Translate docs/reference/kubernetes-api/cluster-resources/lease-v1 --- .../cluster-resources/lease-v1.md | 26 +++++++++---------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/lease-v1.md b/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/lease-v1.md index 3b2f519039..12d626ef5b 100644 --- a/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/lease-v1.md +++ b/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/lease-v1.md @@ -30,7 +30,7 @@ guide. You can file document formatting bugs against the -Lease 定义了租赁的概念。 +Lease 定义了租约的概念。
- **apiVersion**: coordination.k8s.io/v1 @@ -51,7 +51,7 @@ Lease 定义了租赁的概念。 - 租贷规范。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status + Lease 规范。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status @@ -61,7 +61,7 @@ Lease 定义了租赁的概念。 -LeaseSpec 是一个租赁的规范。 +LeaseSpec 是一个 Lease 的规范。
@@ -94,7 +94,7 @@ LeaseSpec 是一个租赁的规范。 --> - **acquireTime** (MicroTime) - acquireTime 是当前租赁被获取的时间。 + acquireTime 是当前租约被获取的时间。 **MicroTime 是微秒级精确时间的版本。** @@ -126,7 +126,7 @@ LeaseSpec 是一个租赁的规范。 -LeaseList 是租赁对象的列表。 +LeaseList 是 Lease 对象的列表。
@@ -198,7 +198,7 @@ GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} --> - **name** (**路径参数**): string, 必需 - 租赁名称 + Lease 名称 - **namespace** (**路径参数**): string, 必需 @@ -224,7 +224,7 @@ GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases --> -### `list` 列出或监视租赁类对象 +### `list` 列出或监视 Lease 类对象 #### HTTP 请求 @@ -358,7 +358,7 @@ GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases #### HTTP Request --> -### `list` 列出或监视租赁类对象 +### `list` 列出或监视 Lease 类对象 #### HTTP 请求 @@ -489,7 +489,7 @@ GET /apis/coordination.k8s.io/v1/leases POST /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases --> -### `create` 创建租赁 +### `create` 创建 Lease #### HTTP 请求 @@ -590,7 +590,7 @@ POST /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases PUT /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} --> -### `update` 替换指定的租赁 +### `update` 替换指定的 Lease #### HTTP 请求 @@ -695,7 +695,7 @@ PUT /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} PATCH /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} --> -### `patch` 部分更新指定的租赁 +### `patch` 部分更新指定的 Lease #### HTTP 请求 @@ -811,7 +811,7 @@ PATCH /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} --> -### `delete` 删除一个租赁 +### `delete` 删除一个 Lease #### HTTP 请求 @@ -917,7 +917,7 @@ DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases --> -### `deletecollection` 删除租赁收款 +### `deletecollection` 删除 Lease 收款 #### HTTP 请求 From d02c5fdc5048587794ac3016aa2e41561d10e52b Mon Sep 17 00:00:00 2001 From: windsonsea Date: Mon, 20 Jun 2022 17:26:20 +0800 Subject: [PATCH 037/209] [zh] resyn ref-k8s-api-config: volume.md --- .../config-and-storage-resources/volume.md | 1784 +++++++++++++++++ 1 file changed, 1784 insertions(+) create mode 100755 content/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/volume.md diff --git a/content/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/volume.md b/content/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/volume.md new file mode 100755 index 0000000000..828209a5b9 --- /dev/null +++ b/content/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/volume.md @@ -0,0 +1,1784 @@ +--- +api_metadata: + apiVersion: "" + import: "k8s.io/api/core/v1" + kind: "Volume" +content_type: "api_reference" +description: "Volume 表示 Pod 中一个有名字的卷，可以由 Pod 中的任意容器进行访问。" +title: "Volume" +weight: 3 +--- + + +`import "k8s.io/api/core/v1"` + +## Volume {#Volume} + +Volume 表示 Pod 中一个有名字的卷，可以由 Pod 中的任意容器进行访问。 + +
+ + +- **name** (string)，必需 + + 卷的名称。必须是 DNS_LABEL 且在 Pod 内是唯一的。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/names/#names + + +### 暴露的持久卷 {#exposed-persistent-volumes} +- **persistentVolumeClaim** (PersistentVolumeClaimVolumeSource) + + persistentVolumeClaimVolumeSource 表示对同一名字空间中 PersistentVolumeClaim 的引用。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes#persistentvolumeclaims + + + **PersistentVolumeClaimVolumeSource 引用同一名字空间中用户的 PVC。 + 此卷找到绑定的 PV 并为 Pod 挂载这个 PV 卷。 + PersistentVolumeClaimVolumeSource 本质上是其他人（或系统）拥有的另一类卷的包装类。** + + + - **persistentVolumeClaim.claimName** (string)，必需 + + claimName 是与使用此卷的 Pod 位于同一名字空间中的 PersistentVolumeClaim 的名称。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes#persistentvolumeclaims + + - **persistentVolumeClaim.readOnly** (boolean) + + readOnly 将在卷挂载中强制设置 readOnly 属性。默认为 false。 + + +### 投射 {#projections} +- **configMap** (ConfigMapVolumeSource) + + configMap 表示应填充此卷的 configMap。 + + + **将 ConfigMap 适配到一个卷中。目标 ConfigMap 的 data 字段的内容将以文件的形式呈现在一个卷中， + 使用 data 字段中的键名作为文件名，除非 items 元素中已经填充了由键名到路径的特定映射。 + ConfigMap 卷支持所有权管理和 SELinux 重新打标签。** + + + - **configMap.name** (string) + + 被引用资源的名称。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/names/#names + + - **configMap.optional** (boolean) + + optional 指定是否所引用的 ConfigMap 或其键必须已经被定义。 + + - **configMap.defaultMode** (int32) + + defaultMode 是可选的：默认情况下，模式位用于为已创建的文件设置权限。 + 必须是 0000 到 0777 之间的八进制值或 0 到 511 之间的十进制值。 + YAML 既接受八进制值也接受十进制值，JSON 针对模式位需要十进制值。此字段默认为 0644。 + 路径内的目录不受此设置的影响。这可能与影响文件模式的其他选项（如 fsGroup）有冲突，且结果可以是其他模式位也被设置。 + + - **configMap.items** ([]}}">KeyToPath) + + 如果未指定 items，则所引用的 ConfigMap 的 data 字段中的每个键值对将作为一个文件被投射到卷中， + 这个文件的名称是键名，而文件的内容是键的取值。 + 如果指定 items，则所列出的键将被投射到指定的路径中，且不会显示未列出的键。 + 如果指定的键不在 ConfigMap 中，则卷设置将出错，除非对应的键被标记为可选。 + 路径必须是相对路径，不能包含 “..” 路径，也不能以 “..” 开头。 + +- **secret** (SecretVolumeSource) + + secret 表示用来填充此卷的 Secret。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#secret + + + **将 Secret 适配到一个卷中。 + 目标 Secret 的 data 字段的内容将以文件的形式呈现在一个卷中，使用 data 字段中的键名作为文件名。 + Secret 卷支持所有权管理和 SELinux 重新打标签。** + + + - **secret.secretName** (string) + + secretName 是要使用的、位于 Pod 的名字空间中的 Secret 名称。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#secret + + - **secret.optional** (boolean) + + optional 字段指定是否 Secret 或其键必须已经定义。 + + + - **secret.defaultMode** (int32) + + defaultMode 是可选的：默认情况下，模式位用于为已创建的文件设置权限。 + 必须是 0000 到 0777 之间的八进制值或 0 到 511 之间的十进制值。 + YAML 既接受八进制值也接受十进制值，JSON 针对模式位需要十进制值。此字段默认为 0644。 + 路径内的目录不受此设置的影响。 + 这可能与影响文件模式的其他选项（如 fsGroup）有冲突，且结果可以是其他模式位也被设置。 + + - **secret.items** ([]}}">KeyToPath) + + 如果未指定 items，则所引用的 Secret 的 data 字段中的每个键值对将作为一个文件被投射到卷中， + 这个文件的名称是键名，而文件的内容是键的取值。 + 如果指定 items，则所列出的键将被投射到指定的路径中，且不会显示未列出的键。 + 如果指定的键不在 Secret 中，则卷设置将出错，除非对应的键被标记为可选。 + 路径必须是相对路径，不能包含 “..” 路径，也不能以 “..” 开头。 + + +- **downwardAPI** (DownwardAPIVolumeSource) + + downwardAPI 表示有关 Pod 的 Downward API，用来填充此卷。 + + + **DownwardAPIVolumeSource 表示包含 Downward API 信息的一个卷。Downward API 卷支持所有权管理和 SELinux 重新打标签。** + + + - **downwardAPI.defaultMode** (int32) + + 可选：默认情况下，模式位用于已创建的文件。 + 必须是可选的：默认情况下，模式位用于为已创建的文件设置权限。 + 必须是 0000 到 0777 之间的八进制值或 0 到 511 之间的十进制值。 + YAML 既接受八进制值也接受十进制值，JSON 针对模式位需要十进制值。此字段默认为 0644。 + 路径内的目录不受此设置的影响。这可能与影响文件模式的其他选项（如 fsGroup）有冲突，且结果可以是其他模式位也被设置。 + + - **downwardAPI.items** ([]}}">DownwardAPIVolumeFile) + + items 是 Downward API 卷文件的列表。 + + +- **projected** (ProjectedVolumeSource) + + 这是供 Secret、ConfigMap 和 Downward API 等所有资源使用的投射项。 + + + **表示一个投射的卷源。** + + - **projected.defaultMode** (int32) + + defaultMode 是默认情况下用于为已创建的文件设置权限的模式位。 + 必须是 0000 到 0777 之间的八进制值或 0 到 511 之间的十进制值。 + YAML 既接受八进制值也接受十进制值，JSON 针对模式位需要十进制值。 + 路径内的目录不受此设置的影响。 + 这可能与影响文件模式的其他选项（如 fsGroup）有冲突，且结果可以是其他模式位也被设置。 + + + - **projected.sources** ([]VolumeProjection) + + sources 是卷投射的列表。 + + + **这里的投射项目可能与其他受支持的卷类型一起进行投射。** + + - **projected.sources.configMap** (ConfigMapProjection) + + 与要投射的 ConfigMap 数据有关的 ConfigMap 信息。 + + + **将 ConfigMap 适配到一个投射的卷中。 + 目标 ConfigMap 的 Data 字段的内容将以文件的形式呈现在一个被投射的卷中， + 使用 data 字段中的键名作为文件名，除非 items 元素中已经填充了由键名到路径的特定映射。 + 请注意，这等同于没有默认模式的 ConfigMap 卷源。** + + + - **projected.sources.configMap.name** (string) + + 被引用资源的名称。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/names/#names + + - **projected.sources.configMap.optional** (boolean) + + optional 指定是否所引用的 ConfigMap 或其键必须已经被定义。 + + + - **projected.sources.configMap.items** ([]}}">KeyToPath) + + 如果未指定 items，则所引用的 ConfigMap 的 data 字段中的每个键值对将作为一个文件被投射到卷中， + 这个文件的名称是键名，而文件的内容是键的取值。 + 如果指定 items，则所列出的键将被投射到指定的路径中，且不会显示未列出的键。 + 如果指定的键不在 ConfigMap 中，则卷设置将出错，除非对应的键被标记为可选。 + 路径必须是相对路径，不能包含 “..” 路径，也不能以 “..” 开头。 + + + - **projected.sources.downwardAPI** (DownwardAPIProjection) + + 与要投射的 downward API 数据有关的 downward API 信息。 + + + **表示投射到投射卷的 Downward API 信息。请注意，这等同于没有默认模式的 downwardAPI 卷源。** + + - **projected.sources.downwardAPI.items** ([]}}">DownwardAPIVolumeFile) + + items 是 DownwardAPIVolume 文件的列表。 + + + - **projected.sources.secret** (SecretProjection) + + 与要投射的 Secret 数据有关的 Secret 信息。 + + + **将 Secret 适配到一个投射卷中。 + 目标 Secret 的 data 字段的内容将以文件的形式呈现在一个投射卷中，使用 data 字段中的键名作为文件名。 + 请注意，这等同于没有默认模式的 Secret 卷源。** + + - **projected.sources.secret.name** (string) + + 被引用资源的名称。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/names/#names + + + - **projected.sources.secret.optional** (boolean) + + optional 字段指定是否 Secret 或其键必须已经定义。 + + - **projected.sources.secret.items** ([]}}">KeyToPath) + + 如果未指定 items，则所引用的 Secret 的 data 字段中的每个键值对将作为一个文件被投射到卷中， + 这个文件的名称是键名，而文件的内容是键的取值。 + 如果指定 items，则所列出的键将被投射到指定的路径中，且不会显示未列出的键。 + 如果指定的键不在 Secret 中，则卷设置将出错，除非对应的键被标记为可选。 + 路径必须是相对路径，不能包含 “..” 路径，也不能以 “..” 开头。 + + - **projected.sources.serviceAccountToken** (ServiceAccountTokenProjection) + + serviceAccountToken 是与要投射的服务账号令牌数据有关的信息。 + + + **ServiceAccountTokenProjection 表示一个投射的服务账号令牌卷。 + 这种投射可用于将服务账号令牌插入到 Pod 运行时文件系统，供访问 API（Kubernetes API Server 或其他）使用。** + + - **projected.sources.serviceAccountToken.path** (string)，必需 + + path 是相对于令牌投射目标文件的挂载点的路径。 + + + - **projected.sources.serviceAccountToken.audience** (string) + + audience 是令牌的目标受众。 + 令牌的接收方必须用令牌受众中指定的一个标识符来标识自己，否则应拒绝此令牌。 + 受众默认为 apiserver 的标识符。 + + - **projected.sources.serviceAccountToken.expirationSeconds** (int64) + + expirationSeconds 是所请求的服务账号令牌的有效期。 + 当令牌即将到期时，kubelet 卷插件将主动轮换服务账号令牌。 + 如果令牌超过其生存时间的 80% 或令牌超过 24 小时，kubelet 将开始尝试轮换令牌。 + 默认为 1 小时且必须至少为 10 分钟。 + + +### 本地/临时目录 {#local-temporary-directory} +- **emptyDir** (EmptyDirVolumeSource) + + emptyDir 表示与 Pod 生命周期相同的临时目录。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#emptydir + + + **表示供 Pod 使用的一个空目录。空目录卷支持所有权管理和 SELinux 重新打标签。** + + - **emptyDir.medium** (string) + + medium 表示此目录应使用哪种类别的存储介质。默认为 ""，这意味着使用节点的默认介质。 + 必须是空字符串（默认值）或 Memory。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#emptydir + + + - **emptyDir.sizeLimit** (}}">Quantity) + + sizeLimit 是这个 EmptyDir 卷所需的本地存储总量。这个大小限制也适用于内存介质。 + EmptyDir 的内存介质最大使用量将是此处指定的 sizeLimit 与 Pod 中所有容器内存限制总和这两个值之间的最小值。 + 默认为 nil，这意味着限制未被定义。更多信息： + http://kubernetes.io/zh-cn/docs/user-guide/volumes#emptydir + + +- **hostPath** (HostPathVolumeSource) + + hostPath 表示主机上预先存在的文件或目录，它们将被直接暴露给容器。 + 这种卷通常用于系统代理或允许查看主机的其他特权操作。大多数容器**不需要**这种卷。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#hostpath + + + **表示映射到 Pod 中的主机路径。主机路径卷不支持所有权管理或 SELinux 重新打标签。** + + + - **hostPath.path** (string)，必需 + + 目录在主机上的路径。如果该路径是一个符号链接，则它将沿着链接指向真实路径。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#hostpath + + - **hostPath.type** (string) + + HostPath 卷的类型。默认为 ""。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#hostpath + + +### 持久卷 {#persistent-volumes} +- **awsElasticBlockStore** (AWSElasticBlockStoreVolumeSource) + + awsElasticBlockStore 表示挂接到 kubelet 的主机随后暴露给 Pod 的一个 AWS Disk 资源。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#awselasticblockstore + + + **表示 AWS 上的 Persistent Disk 资源。挂载到一个容器之前 AWS EBS 磁盘必须存在。 + 该磁盘还必须与 kubelet 位于相同的 AWS 区域中。AWS EBS 磁盘只能以读/写一次进行挂载。 + AWS EBS 卷支持所有权管理和 SELinux 重新打标签。** + + + - **awsElasticBlockStore.volumeID** (string)，必需 + + volumeID 是 AWS（Amazon EBS 卷）中持久磁盘资源的唯一 ID。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#awselasticblockstore + + - **awsElasticBlockStore.fsType** (string) + + fsType 是你要挂载的卷的文件系统类型。提示：确保主机操作系统支持此文件系统类型。 + 例如：“ext4”、“xfs”、“ntfs”。如果未指定，则隐式推断为 “ext4”。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#awselasticblockstore + + + - **awsElasticBlockStore.partition** (int32) + + partition 是你要挂载的卷中的分区。如果省略，则默认为按卷名称进行挂载。例如：对于卷 /dev/sda1， + 将分区指定为 “1”。类似地，/dev/sda 的卷分区为 “0”（或可以将属性留空）。 + + - **awsElasticBlockStore.readOnly** (boolean) + + readOnly 值为 true 将使得卷挂载被强制设置为 readOnly。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#awselasticblockstore + + +- **azureDisk** (AzureDiskVolumeSource) + + azureDisk 表示挂载到主机上并绑定挂载到 Pod 上的 Azure 数据盘。 + + + **azureDisk 表示挂载到主机上并绑定挂载到 Pod 上的 Azure 数据盘。** + + + - **azureDisk.diskName** (string)，必需 + + diskName 是 Blob 存储中数据盘的名称。 + + - **azureDisk.diskURI** (string)，必需 + + diskURI 是 Blob 存储中数据盘的 URI。 + + - **azureDisk.cachingMode** (string) + + cachingMode 是主机缓存（Host Caching）模式：None、Read Only、Read Write。 + + + - **azureDisk.fsType** (string) + + fsType 是要挂载的文件系统类型。必须是主机操作系统所支持的文件系统类型之一。 + 例如 “ext4”、“xfs”、“ntfs”。如果未指定，则隐式推断为 “ext4”。 + + - **azureDisk.kind** (string) + + kind 预期值包括： + + - Shared：每个存储帐户多个 Blob 磁盘； + - Dedicated：每个存储帐户单个 Blob 磁盘； + - Managed：azure 托管的数据盘（仅托管的可用性集合中）。 + + 默认为 Shared。 + + - **azureDisk.readOnly** (boolean) + + readOnly 默认为 false（读/写）。此处的 readOnly 将强制设置卷挂载中的 readOnly 属性。 + + +- **azureFile** (AzureFileVolumeSource) + + azureDisk 表示挂载到主机上并绑定挂载到 Pod 上的 Azure File Service。 + + + **azureFile 表示挂载到主机上并绑定挂载到 Pod 上的 Azure File Service。** + + + - **azureFile.secretName** (string)，必需 + + secretName 是包含 Azure 存储账号名称和主键的 Secret 的名称。 + + - **azureFile.shareName** (string)，必需 + + shareName 是 Azure 共享名称。 + + - **azureFile.readOnly** (boolean) + + readOnly 默认为 false（读/写）。此处的 readOnly 将强制设置卷挂载中的 readOnly 属性。 + + +- **cephfs** (CephFSVolumeSource) + + cephfs 表示在主机上挂载的 Ceph FS，该文件系统挂载与 Pod 的生命周期相同。 + + + **表示在 Pod 的生命周期内持续的 Ceph Filesystem 挂载。cephfs 卷不支持所有权管理或 SELinux 重新打标签。** + + - **cephfs.monitors** ([]string)，必需 + + monitors 是必需的。monitors 是 Ceph 监测的集合。更多信息： + https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it + + + - **cephfs.path** (string) + + path 是可选的。用作挂载的根，而不是挂载完整的 Ceph 树，默认为 “/”。 + + - **cephfs.readOnly** (boolean) + + readOnly 是可选的。默认为 false（读/写）。 + 此处的 readOnly 将强制设置卷挂载中的 readOnly 属性。更多信息： + https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it + + + - **cephfs.secretFile** (string) + + secretFile 是可选的。secretFile 是 User 对应的密钥环的路径，默认为 /etc/ceph/user.secret。更多信息： + https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it + + - **cephfs.secretRef** (}}">LocalObjectReference) + + secretRef 是可选的。secretRef 是针对用户的身份认证 Secret 的引用，默认为空。更多信息： + https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it + + - **cephfs.user** (string) + + user 是可选的。user 是 rados 用户名，默认为 admin。更多信息： + https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it + + +- **cinder** (CinderVolumeSource) + + cinder 表示 kubelet 主机上挂接和挂载的 Cinder 卷。更多信息： + https://examples.k8s.io/mysql-cinder-pd/README.md + + + **表示 Openstack 中的一个 Cinder 卷资源。挂载到一个容器之前 Cinder 卷必须已经存在。 + 该卷还必须与 kubelet 位于相同的地区中。cinder 卷支持所有权管理和 SELinux 重新打标签。** + + - **cinder.volumeID** (string)，必需 + + volumeID 用于标识 Cinder 中的卷。更多信息： + https://examples.k8s.io/mysql-cinder-pd/README.md + + + - **cinder.fsType** (string) + + fsType 是要挂载的文件系统类型。必须是主机操作系统所支持的文件系统类型之一。例如：“ext4”、“xfs”、“ntfs”。 + 如果未指定，则隐式推断为“ext4”。更多信息： + https://examples.k8s.io/mysql-cinder-pd/README.md + + - **cinder.readOnly** (boolean) + + readOnly 默认为 false（读/写）。此处的 readOnly 将强制设置卷挂载中的 readOnly 属性。 + 更多信息： https://examples.k8s.io/mysql-cinder-pd/README.md + + - **cinder.secretRef** (}}">LocalObjectReference) + + secretRef 是可选的。指向 Secret 对象，内含的参数用于连接到 OpenStack。 + + +- **csi** (CSIVolumeSource) + + csi 表示由某个外部容器存储接口（Container Storage Interface，CSI）驱动处理的临时存储（Beta 特性）。 + + + **表示要挂载的卷的源位置，由外部 CSI 驱动进行管理。** + + - **csi.driver** (string)，必需 + + driver 是处理此卷的 CSI 驱动的名称。咨询你的管理员以获取在集群中注册的正确名称。 + + - **csi.fsType** (string) + + 要挂载的 fsType。例如 “ext4”、“xfs”、“ntfs”。 + 如果未提供，则将空值传递给关联的 CSI 驱动，以便决定要应用的默认文件系统。 + + + - **csi.nodePublishSecretRef** (}}">LocalObjectReference) + + nodePublishSecretRef 是对包含敏感信息的 Secret 对象的引用， + 该 Secret 对象将被传递到 CSI 驱动以完成 CSI NodePublishVolume 和 NodeUnpublishVolume 调用。 + 此字段是可选的，如果不需要 Secret，则此字段可以为空。 + 如果 Secret 对象包含多个 Secret，则所有 Secret 引用将被传递。 + + - **csi.readOnly** (boolean) + + readOnly 指定供卷使用的只读配置。默认为 false（读/写）。 + + - **csi.volumeAttributes** (map[string]string) + + volumeAttributes 存储传递给 CSI 驱动且特定于驱动的属性。查阅你的驱动文档，了解支持的值。 + + +- **fc** (FCVolumeSource) + + fc 表示挂接到 kubelet 的主机随后暴露给 Pod 的一个 Fibre Channel 资源。 + + + **表示 Fibre Channel 卷。Fibre Channel 卷只能以读/写一次进行挂载。 + Fibre Channel 卷支持所有权管理和 SELinux 重新打标签。** + + + - **fc.fsType** (string) + + fsType 是要挂载的文件系统类型。必须是主机操作系统所支持的文件系统类型之一。 + 例如 “ext4”、“xfs”、“ntfs”。如果未指定，则隐式推断为 “ext4”。 + + - **fc.lun** (int32) + + lun 是可选的：FC 目标 lun 编号。 + + + - **fc.readOnly** (boolean) + + readOnly 是可选的。默认为 false（读/写）。此处的 readOnly 将强制设置卷挂载中的 readOnly 属性。 + + - **fc.targetWWNs** ([]string) + + targetWWNs 是可选的。FC 目标全球名称（WWN）。 + + - **fc.wwids** ([]string) + + wwids 是可选的。FC 卷全球识别号（wwids）。 + 必须设置 wwids 或 targetWWNs 及 lun 的组合，但不能同时设置两者。 + + +- **flexVolume** (FlexVolumeSource) + + flexVolume 表示使用基于 exec 的插件制备/挂接的通用卷资源。 + + + **flexVolume 表示使用基于 exec 的插件制备/挂接的通用卷资源。** + + - **flexVolume.driver** (string)，必需 + + driver 是供此卷使用的驱动的名称。 + + - **flexVolume.fsType** (string) + + fsType 是要挂载的文件系统类型。必须是主机操作系统所支持的文件系统类型之一。例如 “ext4”、“xfs”、“ntfs”。 + 默认的文件系统取决于 flexVolume 脚本。 + + + - **flexVolume.options** (map[string]string) + + options 是可选的。此字段包含额外的命令选项（如果有）。 + + - **flexVolume.readOnly** (boolean) + + readOnly 是可选的。默认为 false（读/写）。此处的 readOnly 将强制设置卷挂载中的 readOnly 属性。 + + - **flexVolume.secretRef** (}}">LocalObjectReference) + + secretRef 是可选的。secretRef 是对包含敏感信息的 Secret 对象的引用，该 Secret 会被传递到插件脚本。 + 如果未指定 Secret 对象，则此字段可以为空。如果 Secret 对象包含多个 Secret，则所有 Secret 被传递到插件脚本。 + + +- **flocker** (FlockerVolumeSource) + + flocker 表示挂接到一个 kubelet 主机的 Flocker 卷。Flocker 卷依赖于正在运行的 Flocker 控制服务。 + + + **表示 Flocker 代理挂载的 Flocker 卷。应设置一个且仅设置 datasetName 和 datasetUUID 中的一个。 + Flocker 卷不支持所有权管理或 SELinux 重新打标签。** + + - **flocker.datasetName** (string) + + datasetName 是存储为元数据的数据集的名称。Flocker 数据集的名称应视为已弃用。 + + - **flocker.datasetUUID** (string) + + datasetUUID 是数据集的 UUID。这是 Flocker 数据集的唯一标识符。 + + +- **gcePersistentDisk** (GCEPersistentDiskVolumeSource) + + gcePersistentDisk 表示挂接到 kubelet 的主机随后暴露给 Pod 的一个 GCE Disk 资源。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#gcepersistentdisk + + + **表示 Google Compute Engine 中的 Persistent Disk 资源。 + 挂载到一个容器之前 GCE PD 必须已经存在。该磁盘还必须与 kubelet 位于相同的 GCE 项目和区域中。 + GCE PD 只能挂载为读/写一次或只读多次。GCE PD 支持所有权管理和 SELinux 重新打标签。** + + + - **gcePersistentDisk.pdName** (string)，必需 + + pdName 是 GCE 中 PD 资源的唯一名称。用于标识 GCE 中的磁盘。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#gcepersistentdisk + + - **gcePersistentDisk.fsType** (string) + + fsType 是你要挂载的卷的文件系统类型。提示：确保主机操作系统支持此文件系统类型。 + 例如：“ext4”、“xfs”、“ntfs”。如果未指定，则隐式推断为“ext4”。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#gcepersistentdisk + + + - **gcePersistentDisk.partition** (int32) + + partition 是你要挂载的卷中的分区。如果省略，则默认为按卷名称进行挂载。 + 例如：对于卷 /dev/sda1，将分区指定为 “1”。类似地，/dev/sda 的卷分区为 “0”（或可以将属性留空）。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#gcepersistentdisk + + - **gcePersistentDisk.readOnly** (boolean) + + 此处的 readOnly 将强制设置卷挂载中的 readOnly 属性。默认为 false。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#gcepersistentdisk + + +- **glusterfs** (GlusterfsVolumeSource) + + glusterfs 表示在与 Pod 共享生命周期的主机上挂载的 Glusterfs。更多信息： + https://examples.k8s.io/volumes/glusterfs/README.md + + + **表示在 Pod 的生命周期内持续的 Glusterfs 挂载。glusterfs 卷不支持所有权管理或 SELinux 重新打标签。** + + + - **glusterfs.endpoints** (string)，必需 + + endpoints 是详细说明 Glusterfs 拓扑的端点名称。更多信息： + https://examples.k8s.io/volumes/glusterfs/README.md#create-a-pod + + - **glusterfs.path** (string)，必需 + + path 是 Glusterfs 卷路径。更多信息： + https://examples.k8s.io/volumes/glusterfs/README.md#create-a-pod + + - **glusterfs.readOnly** (boolean) + + 此处 readOnly 将强制使用只读权限挂载 Glusterfs 卷。默认为 false。更多信息： + https://examples.k8s.io/volumes/glusterfs/README.md#create-a-pod + + +- **iscsi** (ISCSIVolumeSource) + + iscsi 表示挂接到 kubelet 的主机随后暴露给 Pod 的一个 ISCSI Disk 资源。更多信息： + https://examples.k8s.io/volumes/iscsi/README.md + + + **表示一个 ISCSI 磁盘。ISCSI 卷只能以读/写一次进行挂载。ISCSI 卷支持所有权管理和 SELinux 重新打标签。** + + + - **iscsi.iqn** (string)，必需 + + iqn 是目标 iSCSI 限定名称。 + + - **iscsi.lun** (int32)，必需 + + lun 表示 iSCSI 目标逻辑单元号。 + + - **iscsi.targetPortal** (string)，必需 + + targetPortal 是 iSCSI 目标门户。 + 如果不是默认端口（通常是 TCP 端口 860 和 3260），则 Portal 为 IP 或 ip_addr:port。 + + + - **iscsi.chapAuthDiscovery** (boolean) + + chapAuthDiscovery 定义是否支持 iSCSI Discovery CHAP 身份认证。 + + - **iscsi.chapAuthSession** (boolean) + + chapAuthSession 定义是否支持 iSCSI Session CHAP 身份认证。 + + + - **iscsi.fsType** (string) + + fsType 是你要挂载的卷的文件系统类型。提示：确保主机操作系统支持此文件系统类型。 + 例如：“ext4”、“xfs”、“ntfs”。如果未指定，则隐式推断为 “ext4”。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#iscsi + + - **iscsi.initiatorName** (string) + + initiatorName 是自定义的 iSCSI 发起程序名称（iSCSI Initiator Name）。 + 如果同时用 iscsiInterface 指定 initiatorName，将为连接创建新的 iSCSI 接口 \<目标门户>:\<卷名称>。 + + + - **iscsi.iscsiInterface** (string) + + iscsiInterface 是使用 iSCSI 传输的接口名称。默认为 “default”（tcp）。 + + - **iscsi.portals** ([]string) + + portals 是 iSCSI 目标门户列表（iSCSI Target Portal List）。 + 如果不是默认端口（通常是 TCP 端口 860 和 3260），则 Portal 为 IP 或 ip_addr:port。 + + + - **iscsi.readOnly** (boolean) + + 此处的 readOnly 将强制设置卷挂载中的 readOnly 属性。默认为 false。 + + - **iscsi.secretRef** (}}">LocalObjectReference) + + secretRef 是 iSCSI 目标和发起程序身份认证所用的 CHAP Secret。 + + +- **nfs** (NFSVolumeSource) + + nfs 表示在主机上挂载的 NFS，其生命周期与 Pod 相同。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#nfs + + + **表示 Pod 的生命周期内一直存在的 NFS 挂载。NFS 卷不支持所有权管理或 SELinux 重新打标签。** + + - **nfs.path** (string)，必需 + + path 是由 NFS 服务器导出的路径。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#nfs + + + - **nfs.server** (string)，必需 + + server 是 NFS 服务器的主机名或 IP 地址。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#nfs + + - **nfs.readOnly** (boolean) + + 此处 readOnly 将强制使用只读权限挂载 NFS 导出。默认为 false。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#nfs + + +- **photonPersistentDisk** (PhotonPersistentDiskVolumeSource) + + photonPersistentDisk 表示 kubelet 主机上挂接和挂载的 PhotonController 持久磁盘。 + + + **表示 Photon Controller 持久磁盘资源。** + + - **photonPersistentDisk.pdID** (string)，必需 + + pdID 是标识 Photon Controller 持久磁盘的 ID。 + + - **photonPersistentDisk.fsType** (string) + + fsType 是要挂载的文件系统类型。必须是主机操作系统所支持的文件系统类型之一。 + 例如 “ext4”、“xfs”、“ntfs”。如果未指定，则隐式推断为 “ext4”。 + + +- **portworxVolume** (PortworxVolumeSource) + + portworxVolume 表示 kubelet 主机上挂接和挂载的 portworx 卷。 + + + **PortworxVolumeSource 表示 Portworx 卷资源。** + + - **portworxVolume.volumeID** (string)，必需 + + volumeID 唯一标识 Portworx 卷。 + + + - **portworxVolume.fsType** (string) + + fSType 表示要挂载的文件系统类型。必须是主机操作系统支持的文件系统类型。例如 “ext4”、“xfs”。 + 如果未指定，则隐式推断为 “ext4”。 + + - **portworxVolume.readOnly** (boolean) + + readOnly 默认为 false（读/写）。此处的 readOnly 将强制设置卷挂载中的 readOnly 属性。 + + +- **quobyte** (QuobyteVolumeSource) + + quobyte 表示在共享 Pod 生命周期的主机上挂载的 Quobyte。 + + + **表示在 Pod 的生命周期内持续的 Quobyte 挂载。Quobyte 卷不支持所有权管理或 SELinux 重新打标签。** + + + - **quobyte.registry** (string)，必需 + + registry 表示将一个或多个 Quobyte Registry 服务指定为 host:port 对的字符串形式 + （多个条目用英文逗号分隔），用作卷的中央注册表。 + + - **quobyte.volume** (string)，必需 + + volume 是按名称引用已创建的 Quobyte 卷的字符串。 + + - **quobyte.group** (string) + + group 是将卷访问映射到的组。默认为无组。 + + + - **quobyte.readOnly** (boolean) + + 此处 readOnly 将强制使用只读权限挂载 Quobyte 卷。默认为 false。 + + - **quobyte.tenant** (string) + + tenant 拥有 Backend Used 中给定的 Quobyte 卷，随动态制备的 Quobyte 卷一起使用，值由插件设置。 + + - **quobyte.user** (string) + + user 是将卷访问映射到的用户。默认为 serivceaccount 用户。 + + +- **rbd** (RBDVolumeSource) + + rbd 表示在共享 Pod 生命周期的主机上挂载的 Rados Block Device。更多信息： + https://examples.k8s.io/volumes/rbd/README.md + + + **表示在 Pod 的生命周期内持续的 Rados Block Device 挂载。RBD 卷支持所有权管理和 SELinux 重新打标签。** + + - **rbd.image** (string)，必需 + + image 是 rados 镜像名称。更多信息： + https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it + + + - **rbd.monitors** ([]string)，必需 + + monitors 是 Ceph 监测的集合。更多信息： + https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it + + - **rbd.fsType** (string) + + fsType 是你要挂载的卷的文件系统类型。提示：确保主机操作系统支持此文件系统类型。 + 例如：“ext4”、“xfs”、“ntfs”。如果未指定，则隐式推断为 “ext4”。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/volumes#rbd + + + - **rbd.keyring** (string) + + keyring 是 RBDUser 密钥环的路径。默认为 /etc/ceph/keyring。更多信息： + https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it + + - **rbd.pool** (string) + + pool 是 rados 池名称。默认为 rbd。更多信息： + https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it + + - **rbd.readOnly** (boolean) + + 此处的 readOnly 将强制设置卷挂载中的 readOnly 属性。默认为 false。更多信息： + https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it + + + - **rbd.secretRef** (}}">LocalObjectReference) + + secretRef 是 RBDUser 的身份认证 Secret 的名称。如果提供，则重载 keyring。默认为 nil。更多信息： + https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it + + - **rbd.user** (string) + + user 是 rados 用户名。默认为 admin。更多信息： + https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it + + +- **scaleIO** (ScaleIOVolumeSource) + + scaleIO 表示 Kubernetes 节点上挂接和挂载的 ScaleIO 持久卷。 + + + **ScaleIOVolumeSource 表示一个 ScaleIO 持久卷。** + + - **scaleIO.gateway** (string)，必需 + + gateway 是 ScaleIO API 网关的主机地址。 + + + - **scaleIO.secretRef** (}}">LocalObjectReference)，必需 + + secretRef 引用到 ScaleIO 用户的 Secret 和其他敏感信息。如果未提供此项，则 Login 操作将失败。 + + - **scaleIO.system** (string)，必需 + + system 是存储系统的名称，与 ScaleIO 中的配置相同。 + + - **scaleIO.fsType** (string) + + fsType 是要挂载的文件系统类型。必须是主机操作系统所支持的文件系统类型之一。例如 “ext4”、“xfs”、“ntfs”。默认为 “xfs”。 + + + - **scaleIO.protectionDomain** (string) + + protectionDomain 是 ScaleIO 保护域（ScaleIO Protection Domain）的名称，用于已配置的存储。 + + - **scaleIO.readOnly** (boolean) + + readOnly 默认为 false（读/写）。此处的 readOnly 将强制设置卷挂载中的 readOnly 属性。 + + - **scaleIO.sslEnabled** (boolean) + + sslEnabled 标志启用/禁用与网关的 SSL 通信，默认为 false。 + + + - **scaleIO.storageMode** (string) + + storageMode 指示卷所用的存储应是 ThickProvisioned 或 ThinProvisioned。默认为 ThinProvisioned。 + + - **scaleIO.storagePool** (string) + + storagePool 是与保护域关联的 ScaleIO Storage Pool。 + + - **scaleIO.volumeName** (string) + + volumeName 是在与此卷源关联的 ScaleIO 系统中已创建的卷的名称。 + + +- **storageos** (StorageOSVolumeSource) + + storageOS 表示 Kubernetes 节点上挂接和挂载的 StorageOS 卷。 + + + **表示 StorageOS 持久卷资源。** + + - **storageos.fsType** (string) + + fsType 是要挂载的文件系统类型。必须是主机操作系统所支持的文件系统类型之一。 + 例如 “ext4”、“xfs”、“ntfs”。如果未指定，则隐式推断为 “ext4”。 + + + - **storageos.readOnly** (boolean) + + readOnly 默认为 false（读/写）。此处的 readOnly 将强制设置卷挂载中的 readOnly 属性。 + + - **storageos.secretRef** (}}">LocalObjectReference) + + secretRef 指定用于获取 StorageOS API 凭据的 Secret。如果未指定，则将尝试使用默认值。 + + + - **storageos.volumeName** (string) + + volumeName 是 StorageOS 卷的人类可读名称。这些卷名称在一个名字空间内是唯一的。 + + - **storageos.volumeNamespace** (string) + + volumeNamespace 指定 StorageOS 内卷的作用域。如果未指定名字空间，则将使用 Pod 的名字空间。 + 这个设置使得 Kubernetes 的名字作用域可以在 StorageOS 内进行映射，实现更紧密的集成。 + 将 volumeName 设为任何名称以重载默认的行为。如果你未在 StorageOS 内使用名字空间，则设为“default”。 + 将创建 StorageOS 内预先不存在的名字空间。 + + +- **vsphereVolume** (VsphereVirtualDiskVolumeSource) + + vsphereVolume 表示 kubelet 主机上挂接和挂载的 vSphere 卷。 + + + **表示 vSphere 卷资源。** + + - **vsphereVolume.volumePath** (string)，必需 + + volumePath 是标识 vSphere 卷 vmdk 的路径。 + + + - **vsphereVolume.fsType** (string) + + fsType 是要挂载的文件系统类型。必须是主机操作系统所支持的文件系统类型之一。 + 例如 “ext4”、“xfs”、“ntfs”。如果未指定，则隐式推断为 “ext4”。 + + - **vsphereVolume.storagePolicyID** (string) + + storagePolicyID 是与 StoragePolicyName 关联的基于存储策略的管理（SPBM）配置文件 ID。 + + - **vsphereVolume.storagePolicyName** (string) + + storagePolicyName 是基于存储策略的管理（SPBM）配置文件名称。 + + +### Alpha 级别 {#alpha-level} +- **ephemeral** (EphemeralVolumeSource) + + ephemeral 表示由一个集群存储驱动处理的卷。此卷的生命周期与定义其的 Pod 相关联。 + Pod 启动前创建此卷，Pod 移除时删除此卷。 + + 使用此字段的情形包括： + a) 仅在 pod 运行时才需要此卷， + b) 需要从快照恢复或容量跟踪等正常卷的功能特性， + c) 通过存储类指定存储驱动，以及 + d) 存储驱动支持通过 PersistentVolumeClaim 进行动态卷制备（有关此卷类型和 PersistentVolumeClaim 之间连接的更多信息，请参考 EphemeralVolumeSource）。 + + + 对于持续时间超过单个 Pod 生命周期的卷，使用 PersistentVolumeClaim 或某种特定于供应商的 API。 + + 如果打算以这种方式使用 CSI 驱动，则将 CSI 用于轻量级本地临时卷。更多的相关信息，请参考驱动文档。 + + 一个 Pod 可以同时使用临时卷和持久卷这两种类别的卷。 + + + **表示由一个正常存储驱动处理的临时卷。** + + + - **ephemeral.volumeClaimTemplate** (PersistentVolumeClaimTemplate) + + 将用于创建独立的 PVC 以制备卷。 + 嵌入了 EphemeralVolumeSource 的 Pod 将是 PVC 的所有者，即 PVC 将与 Pod 一起删除。 + PVC 的名称将是 `-<卷名称>`，其中 `<卷名称>` 是来自 `PodSpec.Volumes` 数组条目的名称。 + 如果串联的名称对于 PVC 无效（例如太长），则 Pod 验证将拒绝该 Pod。 + + 如果具有此名称的 PVC 不属于 Pod，则这个 PVC 将不会用于此 Pod，以避免错误地使用不相关的卷。 + 如果出现这种情况，Pod 的启动操作会被阻塞直到不相关的 PVC 被移除。 + 如果 Pod 准备使用这样一个预先创建的 PVC ，那么一旦此 Pod 出现，就必须更新 PVC， + 将其属主引用指向该 Pod。通常没有必要这样做，但这对手动重构损坏的集群时可能很有用。 + + + 此字段是只读的，PVC 被创建后 Kubernetes 不会对其进行任何更改。 + + 必需，不能为 nil。 + + + **PersistentVolumeClaimTemplate 用于作为 EphemeralVolumeSource 的一部分生成 PersistentVolumeClaim 对象。** + + + - **ephemeral.volumeClaimTemplate.spec** (}}">PersistentVolumeClaimSpec)，必需 + + PersistentVolumeClaim 的规约。整个规约的内容将被原封不动地复制到从此模板创建的 PVC 中。 + 与 PersistentVolumeClaim 相同的字段在此处也有效。 + + - **ephemeral.volumeClaimTemplate.metadata** (}}">ObjectMeta) + + 可能包含一些标签和注解，在创建 PVC 时，这些数据会被复制到 PVC 中。在验证期间，其他字段都不允许设置进而被拒绝。 + + +### 已弃用 {#deprecated} +- **gitRepo** (GitRepoVolumeSource) + + gitRepo 表示特定修订版本的 git 仓库。（注意：GitRepo 已被弃用。）如果与为某容器提速 Git 仓库， + 可以先将 emptyDir 挂载到 InitContainer 上，由后者使用 git 克隆仓库，然后将 emptyDir 挂载到 Pod 的容器中。 + + + **表示用 Git 仓库的内容进行填充的一个卷。Git 仓库卷不支持所有权管理。Git 仓库卷支持 SELinux 重新打标签。 + （注意：GitRepo 已被弃用。）如果与为某容器提速 Git 仓库， + 可以先将 emptyDir 挂载到 InitContainer 上，由后者使用 git 克隆仓库，然后将 emptyDir 挂载到 Pod 的容器中。** + + + - **gitRepo.repository** (string)，必需 + + repository 是仓库的 URL。 + + - **gitRepo.directory** (string) + + directory 是目标目录的名称。不得包含 “..” 或以 “..” 开头。如果提供了 “.”，则卷目录将是 Git 仓库。 + 否则，如果指定，卷将用给定名称的子目录中存放 Git 仓库。 + + - **gitRepo.revision** (string) + + revision 是指定修订版本的提交哈希值。 + +## DownwardAPIVolumeFile {#DownwardAPIVolumeFile} + +DownwardAPIVolumeFile 表示创建包含 Pod 字段的文件的信息。 + +
+ +- **path** (string)，必需 + + 必需。path 是要创建的文件的相对路径名称。不得使用绝对路径，也不得包含 “..” 路径。 + 必须用 UTF-8 进行编码。相对路径的第一项不得用 “..” 开头。 + +- **fieldRef** (}}">ObjectFieldSelector) + + 必需。选择 Pod 的字段：仅支持注解、标签、名称和名字空间。 + + +- **mode** (int32) + + 可选：模式位用于设置文件的权限，必须是 0000 到 0777 之间的八进制值或 0 到 511 之间的十进制值。 + YAML 既接受八进制值也接受十进制值，JSON 针对模式位需要十进制值。 + 如果未指定，则将使用卷 defaultMode。 + 这可能与影响文件模式的其他选项（如 fsGroup）有冲突，且结果可以是其他模式位也被设置。 + +- **resourceFieldRef** (}}">ResourceFieldSelector) + + 选择容器的资源：目前仅支持资源限制与请求（limits.cpu、limits.memory、requests.cpu 和 requests.memory）。 + +## KeyToPath {#KeyToPath} + + +将一个字符串键映射到卷中的一个路径。 + +
+ +- **key** (string)，必需 + + key 是要投射的键。 + +- **path** (string)，必需 + + path 是将键映射到的文件的相对路径。不能是绝对路径。不能包含路径元素 “..”。不能以字符串 “..” 开头。 + + +- **mode** (int32) + + mode 是可选的：模式位用于为文件设置权限。必须是 0000 到 0777 之间的八进制值或 0 到 511 之间的十进制值。 + YAML 既接受八进制值也接受十进制值，JSON 针对模式位需要十进制值。 + 如果未指定，则将使用卷 defaultMode。 + 这可能与影响文件模式的其他选项（如 fsGroup）有冲突，且结果可以是其他模式位也被设置。 From 445856614d4827063dad5482ef9acdf4d0285889 Mon Sep 17 00:00:00 2001 From: Marcelo Juchem Date: Thu, 23 Jun 2022 02:27:22 -0500 Subject: [PATCH 038/209] sorting library list in lexicographic order --- content/en/docs/reference/using-api/client-libraries.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/using-api/client-libraries.md b/content/en/docs/reference/using-api/client-libraries.md index ad95ee188d..44ea4b622d 100644 --- a/content/en/docs/reference/using-api/client-libraries.md +++ b/content/en/docs/reference/using-api/client-libraries.md @@ -30,13 +30,13 @@ The following client libraries are officially maintained by | Language | Client Library | Sample Programs | |----------|----------------|-----------------| +| C | [github.com/kubernetes-client/c](https://github.com/kubernetes-client/c/) | [browse](https://github.com/kubernetes-client/c/tree/master/examples) | dotnet | [github.com/kubernetes-client/csharp](https://github.com/kubernetes-client/csharp) | [browse](https://github.com/kubernetes-client/csharp/tree/master/examples/simple) | Go | [github.com/kubernetes/client-go/](https://github.com/kubernetes/client-go/) | [browse](https://github.com/kubernetes/client-go/tree/master/examples) | Haskell | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) | [browse](https://github.com/kubernetes-client/haskell/tree/master/kubernetes-client/example) | Java | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [browse](https://github.com/kubernetes-client/java#installation) | JavaScript | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [browse](https://github.com/kubernetes-client/javascript/tree/master/examples) | Python | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [browse](https://github.com/kubernetes-client/python/tree/master/examples) -| C | [github.com/kubernetes-client/c](https://github.com/kubernetes-client/c/) | [browse](https://github.com/kubernetes-client/c/tree/master/examples) ## Community-maintained client libraries From ee0a90c64e35372b7f8e796e28d267a374d7578b Mon Sep 17 00:00:00 2001 From: howieyuen Date: Thu, 23 Jun 2022 15:22:13 +0800 Subject: [PATCH 039/209] [zh]fix 2017 blogs: add slug and remove url --- .../blog/_posts/2017-10-00-Five-Days-Of-Kubernetes-18.md | 5 +---- ...ernetes-Community-Steering-Committee-Election-Results.md | 6 ++---- .../blog/_posts/2017-11-00-Autoscaling-In-Kubernetes.md | 5 +---- 3 files changed, 4 insertions(+), 12 deletions(-) diff --git a/content/zh-cn/blog/_posts/2017-10-00-Five-Days-Of-Kubernetes-18.md b/content/zh-cn/blog/_posts/2017-10-00-Five-Days-Of-Kubernetes-18.md index 64ff3b1b62..6418a161f4 100644 --- a/content/zh-cn/blog/_posts/2017-10-00-Five-Days-Of-Kubernetes-18.md +++ b/content/zh-cn/blog/_posts/2017-10-00-Five-Days-Of-Kubernetes-18.md @@ -3,14 +3,11 @@ title: " Kubernetes 1.8 的五天 " date: 2017-10-24 slug: five-days-of-kubernetes-18 --- - + diff --git a/content/zh-cn/blog/_posts/2017-11-00-Autoscaling-In-Kubernetes.md b/content/zh-cn/blog/_posts/2017-11-00-Autoscaling-In-Kubernetes.md index cab6c2b331..c30f22aa35 100644 --- a/content/zh-cn/blog/_posts/2017-11-00-Autoscaling-In-Kubernetes.md +++ b/content/zh-cn/blog/_posts/2017-11-00-Autoscaling-In-Kubernetes.md @@ -3,14 +3,11 @@ title: " Kubernetes 中自动缩放 " date: 2017-11-17 slug: autoscaling-in-kubernetes --- - + **作者: Zach Corleissen（Linux 基金会）** 去年我们对 Kubernetes 网站进行了优化，加入了[多语言内容的支持](https://kubernetes.io/blog/2018/11/08/kubernetes-docs-updates-international-edition/)。贡献者们踊跃响应，加入了多种新的本地化内容：截至 2019 年 4 月，Kubernetes 文档有了 9 个不同语言的未完成版本，其中有 6 个是 2019 年加入的。在每个 Kubernetes 文档页面的上方，读者都可以看到一个语言选择器，其中列出了所有可用语言。 不论是完成度最高的[中文版 v1.12](https://v1-12.docs.kubernetes.io/zh/)，还是最新加入的[葡萄牙文版 v1.14](https://kubernetes.io/pt/)，各语言的本地化内容还未完成，这是一个进行中的项目。如果读者有兴趣对现有本地化工作提供支持，请继续阅读。 + ## 什么是本地化 翻译是以词表意的问题。而本地化在此基础之上，还包含了过程和设计方面的工作。 @@ -18,6 +40,15 @@ date: 2019-04-26 本地化很重要，能够有效的降低 Kubernetes 的采纳和支持门槛。如果能用母语阅读 Kubernetes 文档，就能更轻松的开始使用 Kubernetes，并对其发展作出贡献。 + ## 如何启动本地化工作 不同语言的本地化工作都是单独的功能——和其它 Kubernetes 功能一致，贡献者们在一个 SIG 中进行本地化工作，分享出来进行评审，并加入项目。 @@ -26,6 +57,27 @@ date: 2019-04-26 每个团队都有自己的工作流。有些团队手工完成所有的内容翻译；有些会使用带有翻译插件的编译器，并使用评审机来提供正确性的保障。SIG Docs 专注于输出的标准；这就给了本地化团队采用适合自己工作情况的工作流。这样一来，团队可以根据最佳实践进行协作，并以 Kubernetes 的社区精神进行分享。 + ## 为本地化工作添砖加瓦 如果你有兴趣为 Kubernetes 文档加入新语种的本地化内容，[Kubernetes contribution guide](https://kubernetes.io/docs/contribute/localization/) 中包含了这方面的相关内容。 @@ -46,6 +98,14 @@ date: 2019-04-26 |葡萄牙文|[#kubernetes-docs-pt](https://kubernetes.slack.com/messages/CJ21AS0NA/)| |西班牙文|[#kubernetes-docs-es](https://kubernetes.slack.com/messages/CH7GB2E3B/)| + + ## 下一步？ 最新的[印地文本地化](https://kubernetes.slack.com/messages/CJ14B9BDJ/)工作正在启动。为什么不加入你的语言？ diff --git a/content/zh-cn/blog/_posts/2019-06-12-contributor-summit-shanghai.md b/content/zh-cn/blog/_posts/2019-06-12-contributor-summit-shanghai.md index 1d136352bd..ae932956ae 100644 --- a/content/zh-cn/blog/_posts/2019-06-12-contributor-summit-shanghai.md +++ b/content/zh-cn/blog/_posts/2019-06-12-contributor-summit-shanghai.md @@ -2,6 +2,7 @@ layout: blog title: '欢迎参加在上海举行的贡献者峰会' date: 2019-06-11 +slug: join-us-at-the-contributor-summit-in-shanghai --- + From 1328174cee81b01347eb3e0d0a6f3e51b3d2388d Mon Sep 17 00:00:00 2001 From: howieyuen Date: Thu, 23 Jun 2022 15:21:50 +0800 Subject: [PATCH 042/209] [zh]fix 2015 blogs: add slug and remove url --- .../2015-03-00-Kubernetes-Gathering-Videos.md | 7 +------ ...-03-00-Weekly-Kubernetes-Community-Hangout.md | 7 ++----- .../2015-03-00-Welcome-To-Kubernetes-Blog.md | 5 +---- .../2015-04-00-Borg-Predecessor-To-Kubernetes.md | 6 ++---- ...-04-00-Weekly-Kubernetes-Community-Hangout.md | 8 +++----- ...00-Appc-Support-For-Kubernetes-Through-Rkt.md | 16 +++++++--------- .../_posts/2015-05-00-Kubernetes-On-Openstack.md | 5 +---- ...-05-00-Weekly-Kubernetes-Community-Hangout.md | 5 +---- .../2015-06-00-Slides-Cluster-Management-With.md | 5 +---- ...-00-Announcing-First-Kubernetes-Enterprise.md | 6 +++--- ...-08-00-Weekly-Kubernetes-Community-Hangout.md | 16 ++++++---------- ...s-Improved-Tooling-And-A-Growing-Community.md | 6 ++---- ...es-And-Replication-Controllers-With-Puppet.md | 7 ++----- 13 files changed, 32 insertions(+), 67 deletions(-) diff --git a/content/zh-cn/blog/_posts/2015-03-00-Kubernetes-Gathering-Videos.md b/content/zh-cn/blog/_posts/2015-03-00-Kubernetes-Gathering-Videos.md index 90dd2a1317..f085117d1c 100644 --- a/content/zh-cn/blog/_posts/2015-03-00-Kubernetes-Gathering-Videos.md +++ b/content/zh-cn/blog/_posts/2015-03-00-Kubernetes-Gathering-Videos.md @@ -1,18 +1,13 @@ --- - title: " Kubernetes 采集视频 " date: 2015-03-23 slug: kubernetes-gathering-videos --- - + diff --git a/content/zh-cn/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout.md b/content/zh-cn/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout.md index a95a116b49..323cdad934 100644 --- a/content/zh-cn/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout.md +++ b/content/zh-cn/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout.md @@ -1,17 +1,15 @@ --- -title: " 每周 Kubernetes 社区例会笔记 - 2015年4月3日 " +title: " 每周 Kubernetes 社区例会笔记 - 2015 年 4 月 3 日 " date: 2015-04-04 slug: weekly-kubernetes-community-hangout -url: /zh/blog/2015/04/Weekly-Kubernetes-Community-Hangout --- + diff --git a/content/zh-cn/blog/_posts/2015-05-00-Appc-Support-For-Kubernetes-Through-Rkt.md b/content/zh-cn/blog/_posts/2015-05-00-Appc-Support-For-Kubernetes-Through-Rkt.md index 275cbead77..c715afe8b2 100644 --- a/content/zh-cn/blog/_posts/2015-05-00-Appc-Support-For-Kubernetes-Through-Rkt.md +++ b/content/zh-cn/blog/_posts/2015-05-00-Appc-Support-For-Kubernetes-Through-Rkt.md @@ -1,17 +1,15 @@ - --- title: " 通过 RKT 对 Kubernetes 的 AppC 支持 " date: 2015-05-04 slug: appc-support-for-kubernetes-through-rkt -url: /zh/blog/2015/05/Appc-Support-For-Kubernetes-Through-Rkt --- + + diff --git a/content/zh-cn/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md b/content/zh-cn/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md index 68a50e93c8..0ac0f14276 100644 --- a/content/zh-cn/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md +++ b/content/zh-cn/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md @@ -3,14 +3,11 @@ title: " OpenStack 上的 Kubernetes " date: 2015-05-19 slug: kubernetes-on-openstack --- - [![](https://3.bp.blogspot.com/-EOrCHChZJZE/VVZzq43g6CI/AAAAAAAAF-E/JUilRHk369E/s400/Untitled%2Bdrawing.jpg)](https://3.bp.blogspot.com/-EOrCHChZJZE/VVZzq43g6CI/AAAAAAAAF-E/JUilRHk369E/s1600/Untitled%2Bdrawing.jpg) diff --git a/content/zh-cn/blog/_posts/2015-05-00-Weekly-Kubernetes-Community-Hangout.md b/content/zh-cn/blog/_posts/2015-05-00-Weekly-Kubernetes-Community-Hangout.md index 8b7e00355d..39f88f204c 100644 --- a/content/zh-cn/blog/_posts/2015-05-00-Weekly-Kubernetes-Community-Hangout.md +++ b/content/zh-cn/blog/_posts/2015-05-00-Weekly-Kubernetes-Community-Hangout.md @@ -3,14 +3,11 @@ title: " Kubernetes 社区每周聚会笔记- 2015年5月1日 " date: 2015-05-11 slug: weekly-kubernetes-community-hangout --- - +url: /blog/2015/07/Announcing-First-Kubernetes-Enterprise +--> 在谷歌，我们依赖 Linux 容器应用程序去运行我们的核心基础架构。所有服务，从搜索引擎到Gmail服务，都运行在容器中。事实上，我们非常喜欢容器，甚至我们的谷歌云计算引擎虚拟机也运行在容器上！由于容器对于我们的业务至关重要，我们已经与社区合作开发许多基本的容器技术（从 cgroups 到 Docker 的 LibContainer）,甚至决定去构建谷歌的下一代开源容器调度技术，Kubernetes。 diff --git a/content/zh-cn/blog/_posts/2015-08-00-Weekly-Kubernetes-Community-Hangout.md b/content/zh-cn/blog/_posts/2015-08-00-Weekly-Kubernetes-Community-Hangout.md index 7e2bc24423..54f648fd5c 100644 --- a/content/zh-cn/blog/_posts/2015-08-00-Weekly-Kubernetes-Community-Hangout.md +++ b/content/zh-cn/blog/_posts/2015-08-00-Weekly-Kubernetes-Community-Hangout.md @@ -1,19 +1,15 @@ - ---- -title: " Kubernetes社区每周环聊笔记-2015年7月31日 " -date: 2015-08-04 -slug: weekly-kubernetes-community-hangout -url: /zh/blog/2015/08/Weekly-Kubernetes-Community-Hangout ---- - + diff --git a/content/zh-cn/blog/_posts/2015-12-00-Managing-Kubernetes-Pods-Services-And-Replication-Controllers-With-Puppet.md b/content/zh-cn/blog/_posts/2015-12-00-Managing-Kubernetes-Pods-Services-And-Replication-Controllers-With-Puppet.md index 2fb1d70b9f..1eecaafae6 100644 --- a/content/zh-cn/blog/_posts/2015-12-00-Managing-Kubernetes-Pods-Services-And-Replication-Controllers-With-Puppet.md +++ b/content/zh-cn/blog/_posts/2015-12-00-Managing-Kubernetes-Pods-Services-And-Replication-Controllers-With-Puppet.md @@ -1,16 +1,13 @@ --- -title: " 使用 Puppet 管理 Kubernetes Pods，Services 和 Replication Controllers " +title: "使用 Puppet 管理 Kubernetes Pod、Service 和 Replication Controller" date: 2015-12-17 slug: managing-kubernetes-pods-services-and-replication-controllers-with-puppet --- - -[云控制器管理器的管理](/zh/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) +[云控制器管理器的管理](/zh-cn/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) 给出了运行和管理云控制器管理器的指南。 -要升级 HA 控制平面以使用云控制器管理器，请参见 [将复制的控制平面迁移以使用云控制器管理器](/zh/docs/tasks/administer-cluster/controller-manager-leader-migration/) +要升级 HA 控制平面以使用云控制器管理器，请参见 [将复制的控制平面迁移以使用云控制器管理器](/zh-cn/docs/tasks/administer-cluster/controller-manager-leader-migration/) 想要了解如何实现自己的云控制器管理器，或者对现有项目进行扩展么？ @@ -343,6 +343,6 @@ For more information about developing plugins, see [Developing Cloud Controller 特定于云驱动的实现虽不是 Kubernetes 核心成分，仍要实现 `CloudProvider` 接口。 关于如何开发插件的详细信息，可参考 -[开发云控制器管理器](/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager/) +[开发云控制器管理器](/zh-cn/docs/tasks/administer-cluster/developing-cloud-controller-manager/) 文档。 diff --git a/content/zh-cn/docs/concepts/architecture/control-plane-node-communication.md b/content/zh-cn/docs/concepts/architecture/control-plane-node-communication.md index 8a92d69f2e..57f05179ed 100644 --- a/content/zh-cn/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/zh-cn/docs/concepts/architecture/control-plane-node-communication.md @@ -33,17 +33,17 @@ Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。 所有从集群（或所运行的 Pods）发出的 API 调用都终止于 API 服务器。 其它控制面组件都没有被设计为可暴露远程服务。 API 服务器被配置为在一个安全的 HTTPS 端口（通常为 443）上监听远程连接请求， -并启用一种或多种形式的客户端[身份认证](/zh/docs/reference/access-authn-authz/authentication/)机制。 -一种或多种客户端[鉴权机制](/zh/docs/reference/access-authn-authz/authorization/)应该被启用， -特别是在允许使用[匿名请求](/zh/docs/reference/access-authn-authz/authentication/#anonymous-requests) -或[服务账号令牌](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。 +并启用一种或多种形式的客户端[身份认证](/zh-cn/docs/reference/access-authn-authz/authentication/)机制。 +一种或多种客户端[鉴权机制](/zh-cn/docs/reference/access-authn-authz/authorization/)应该被启用， +特别是在允许使用[匿名请求](/zh-cn/docs/reference/access-authn-authz/authentication/#anonymous-requests) +或[服务账号令牌](/zh-cn/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。 应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 API 服务器。 一种好的方法是以客户端证书的形式将客户端凭据提供给 kubelet。 -请查看 [kubelet TLS 启动引导](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) +请查看 [kubelet TLS 启动引导](/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) 以了解如何自动提供 kubelet 客户端证书。 在温度计的例子中，如果房间很冷，那么某个控制器可能还会启动一个防冻加热器。 就 Kubernetes 集群而言，控制面间接地与 IP 地址管理工具、存储服务、云驱动 -APIs 以及其他服务协作，通过[扩展 Kubernetes](/zh/docs/concepts/extend-kubernetes/) +APIs 以及其他服务协作，通过[扩展 Kubernetes](/zh-cn/docs/concepts/extend-kubernetes/) 来实现这点。 -* 阅读 [Kubernetes 控制平面组件](/zh/docs/concepts/overview/components/#control-plane-components) -* 了解 [Kubernetes 对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/) +* 阅读 [Kubernetes 控制平面组件](/zh-cn/docs/concepts/overview/components/#control-plane-components) +* 了解 [Kubernetes 对象](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/) 的一些基本知识 -* 进一步学习 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/) +* 进一步学习 [Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api/) * 如果你想编写自己的控制器，请看 Kubernetes 的 - [扩展模式](/zh/docs/concepts/extend-kubernetes/#extension-patterns)。 + [扩展模式](/zh-cn/docs/concepts/extend-kubernetes/#extension-patterns)。 diff --git a/content/zh-cn/docs/concepts/architecture/cri.md b/content/zh-cn/docs/concepts/architecture/cri.md index 68cd082fc0..c0b3579578 100644 --- a/content/zh-cn/docs/concepts/architecture/cri.md +++ b/content/zh-cn/docs/concepts/architecture/cri.md @@ -46,7 +46,7 @@ flags](/docs/reference/command-line-tools-reference/kubelet) --> 当通过 gRPC 连接到容器运行时时，kubelet 充当客户端。 运行时和镜像服务端点必须在容器运行时中可用，可以使用 -[命令行标志](/zh/docs/reference/command-line-tools-reference/kubelet)的 +[命令行标志](/zh-cn/docs/reference/command-line-tools-reference/kubelet)的 `--image-service-endpoint` 和 `--container-runtime-endpoint` 在 kubelet 中单独配置。 diff --git a/content/zh-cn/docs/concepts/architecture/garbage-collection.md b/content/zh-cn/docs/concepts/architecture/garbage-collection.md index c095601354..d45b98fa8f 100644 --- a/content/zh-cn/docs/concepts/architecture/garbage-collection.md +++ b/content/zh-cn/docs/concepts/architecture/garbage-collection.md @@ -32,16 +32,16 @@ allows the clean up of resources like the following: manager * [Node Lease objects](/docs/concepts/architecture/nodes/#heartbeats) --> -* [失败的 Pod](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection) -* [已完成的 Job](/zh/docs/concepts/workloads/controllers/ttlafterfinished/) +* [失败的 Pod](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection) +* [已完成的 Job](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/) * [不再存在属主引用的对象](#owners-dependents) * [未使用的容器和容器镜像](#containers-images) -* [动态制备的、StorageClass 回收策略为 Delete 的 PV 卷](/zh/docs/concepts/storage/persistent-volumes/#delete) -* [阻滞或者过期的 CertificateSigningRequest (CSRs)](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) +* [动态制备的、StorageClass 回收策略为 Delete 的 PV 卷](/zh-cn/docs/concepts/storage/persistent-volumes/#delete) +* [阻滞或者过期的 CertificateSigningRequest (CSRs)](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) * 在以下情形中删除了的{{}}对象： - * 当集群使用[云控制器管理器](/zh/docs/concepts/architecture/cloud-controller/)运行于云端时； + * 当集群使用[云控制器管理器](/zh-cn/docs/concepts/architecture/cloud-controller/)运行于云端时； * 当集群使用类似于云控制器管理器的插件运行在本地环境中时。 -* [节点租约对象](/zh/docs/concepts/architecture/nodes/#heartbeats) +* [节点租约对象](/zh-cn/docs/concepts/architecture/nodes/#heartbeats) ## 属主与依赖 {#owners-dependents} -Kubernetes 中很多对象通过[*属主引用*](/zh/docs/concepts/overview/working-with-objects/owners-dependents/) +Kubernetes 中很多对象通过[*属主引用*](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/) 链接到彼此。属主引用（Owner Reference）可以告诉控制面哪些对象依赖于其他对象。 Kubernetes 使用属主引用来为控制面以及其他 API 客户端在删除某对象时提供一个清理关联资源的机会。 在大多数场合，Kubernetes 都是自动管理属主引用的。 @@ -69,7 +69,7 @@ to the labels, each `EndpointSlice` that is managed on behalf of a Service has an owner reference. Owner references help different parts of Kubernetes avoid interfering with objects they don’t control. --> -属主关系与某些资源所使用的[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)不同。 +属主关系与某些资源所使用的[标签和选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)不同。 例如，考虑一个创建 `EndpointSlice` 对象的 {{}} 对象。Service 对象使用*标签*来允许控制面确定哪些 `EndpointSlice` 对象被该 Service 使用。除了标签，每个被 Service 托管的 `EndpointSlice` 对象还有一个属主引用属性。 @@ -181,7 +181,7 @@ to learn more. 在前台级联删除过程中，唯一可能阻止属主对象被删除的是那些带有 `ownerReference.blockOwnerDeletion=true` 字段的依赖对象。 -参阅[使用前台级联删除](/zh/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion) +参阅[使用前台级联删除](/zh-cn/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion) 以了解进一步的细节。 要配置对未使用容器和镜像的垃圾收集选项，可以使用一个 -[配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/)，基于 -[`KubeletConfiguration`](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) +[配置文件](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/)，基于 +[`KubeletConfiguration`](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) 资源类型来调整与垃圾搜集相关的 kubelet 行为。 @@ -353,8 +353,8 @@ configure garbage collection: * Learn more about Kubernetes [finalizers](/docs/concepts/overview/working-with-objects/finalizers/). * Learn about the [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) that cleans up finished Jobs. --> -* 进一步了解 [Kubernetes 对象的属主关系](/zh/docs/concepts/overview/working-with-objects/owners-dependents/)。 -* 进一步了解 Kubernetes [finalizers](/zh/docs/concepts/overview/working-with-objects/finalizers/)。 -* 进一步了解 [TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/) (beta)， +* 进一步了解 [Kubernetes 对象的属主关系](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/)。 +* 进一步了解 Kubernetes [finalizers](/zh-cn/docs/concepts/overview/working-with-objects/finalizers/)。 +* 进一步了解 [TTL 控制器](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/) (beta)， 该控制器负责清理已完成的 Job。 diff --git a/content/zh-cn/docs/concepts/architecture/nodes.md b/content/zh-cn/docs/concepts/architecture/nodes.md index 0ab1e695ca..a57f98dc14 100644 --- a/content/zh-cn/docs/concepts/architecture/nodes.md +++ b/content/zh-cn/docs/concepts/architecture/nodes.md @@ -38,7 +38,7 @@ Kubernetes 通过将容器放入在节点（Node）上运行的 Pod 中来执行 通常集群中会有若干个节点；而在一个学习用或者资源受限的环境中，你的集群中也可能 只有一个节点。 -节点上的[组件](/zh/docs/concepts/overview/components/#node-components)包括 +节点上的[组件](/zh-cn/docs/concepts/overview/components/#node-components)包括 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、 {{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}以及 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}。 @@ -110,7 +110,7 @@ The name of a Node object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). --> Node 对象的名称必须是合法的 -[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 ### 节点名称唯一性 {#node-name-uniqueness} -节点的[名称](/zh/docs/concepts/overview/working-with-objects/names#names)用来标识 Node 对象。 +节点的[名称](/zh-cn/docs/concepts/overview/working-with-objects/names#names)用来标识 Node 对象。 没有两个 Node 可以同时使用相同的名称。 Kubernetes 还假定名字相同的资源是同一个对象。 就 Node 而言，隐式假定使用相同名称的实例会具有相同的状态（例如网络配置、根磁盘内容） 和类似节点标签这类属性。这可能在节点被更改但其名称未变时导致系统状态不一致。 @@ -167,7 +167,7 @@ For self-registration, the kubelet is started with the following options: （逗号分隔的 `=:`）注册节点。当 `register-node` 为 false 时无效。 - `--node-ip` - 节点 IP 地址。 - `--node-labels` - 在集群中注册节点时要添加的{{< glossary_tooltip text="标签" term_id="label" >}}。 - （参见 [NodeRestriction 准入控制插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)所实施的标签限制）。 + （参见 [NodeRestriction 准入控制插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)所实施的标签限制）。 - `--node-status-update-frequency` - 指定 kubelet 向控制面发送状态的频率。 -启用[Node 鉴权模式](/zh/docs/reference/access-authn-authz/node/)和 -[NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时， +启用[Node 鉴权模式](/zh-cn/docs/reference/access-authn-authz/node/)和 +[NodeRestriction 准入插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时， 仅授权 `kubelet` 创建或修改其自己的节点资源。 {{< note >}} @@ -256,7 +256,7 @@ kubectl cordon $NODENAME See [Safely Drain a Node](/docs/tasks/administer-cluster/safely-drain-node/) for more details. --> -更多细节参考[安全地腾空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)。 +更多细节参考[安全地腾空节点](/zh-cn/docs/tasks/administer-cluster/safely-drain-node/)。 {{< note >}} 当节点上出现问题时，Kubernetes 控制面会自动创建与影响节点的状况对应的 -[污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 +[污点](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)。 调度器在将 Pod 指派到某 Node 时会考虑 Node 上的污点设置。 Pod 也可以设置{{< glossary_tooltip text="容忍度" term_id="toleration" >}}， 以便能够在设置了特定污点的 Node 上运行。 @@ -439,7 +439,7 @@ Pod 也可以设置{{< glossary_tooltip text="容忍度" term_id="toleration" >} See [Taint Nodes by Condition](/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition) for more details. --> -进一步的细节可参阅[根据状况为节点设置污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition)。 +进一步的细节可参阅[根据状况为节点设置污点](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition)。 -可以在学习如何在节点上[预留计算资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +可以在学习如何在节点上[预留计算资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) 的时候了解有关容量和可分配资源的更多信息。 如果要为非 Pod 进程显式保留资源。 -请参考[为系统守护进程预留资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)。 +请参考[为系统守护进程预留资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)。 {{< /note >}} -如果启用了 `TopologyManager` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +如果启用了 `TopologyManager` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， `kubelet` 可以在作出资源分配决策时使用拓扑提示。 -参考[控制节点上拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)了解详细信息。 +参考[控制节点上拓扑管理策略](/zh-cn/docs/tasks/administer-cluster/topology-manager/)了解详细信息。 节点体面关闭的特性对应两个 -[`KubeletConfiguration`](/zh/docs/tasks/administer-cluster/kubelet-config-file/) 选项： +[`KubeletConfiguration`](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/) 选项： * `shutdownGracePeriod`： * 指定节点应延迟关闭的总持续时间。此时间是 Pod 体面终止的时间总和，不区分常规 Pod - 还是[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。 + 还是[关键 Pod](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。 * `shutdownGracePeriodCriticalPods`： - * 在节点关闭期间指定用于终止[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) + * 在节点关闭期间指定用于终止[关键 Pod](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) 的持续时间。该值应小于 `shutdownGracePeriod`。 假设集群中存在以下自定义的 Pod -[优先级类](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)。 +[优先级类](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)。 | Pod 优先级类名称 | Pod 优先级类数值 | |-------------------------|------------------------| @@ -982,7 +982,7 @@ in a cluster, Within the [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) the settings for `shutdownGracePeriodByPodPriority` could look like: --> -在 [kubelet 配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)中， +在 [kubelet 配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)中， `shutdownGracePeriodByPodPriority` 可能看起来是这样： | Pod 优先级类数值 | 关闭期限 | @@ -1059,8 +1059,8 @@ their respective shutdown periods. 如果此功能特性被启用，但没有提供配置数据，则不会出现排序操作。 使用此功能特性需要启用 `GracefulNodeShutdownBasedOnPodPriority` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， -并将 [kubelet 配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/) +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， +并将 [kubelet 配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/) 中的 `shutdownGracePeriodByPodPriority` 设置为期望的配置， 其中包含 Pod 的优先级类数值以及对应的关闭期限。 @@ -1107,7 +1107,7 @@ must be set to false. --> 要在节点上启用交换内存，必须启用kubelet 的 `NodeSwap` 特性门控， 同时使用 `--fail-swap-on` 命令行参数或者将 `failSwapOn` -[配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)设置为 false。 +[配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)设置为 false。 -* 进一步了解节点[组件](/zh/docs/concepts/overview/components/#node-components)。 +* 进一步了解节点[组件](/zh-cn/docs/concepts/overview/components/#node-components)。 * 阅读 [Node 的 API 定义](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)。 * 阅读架构设计文档中有关 [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) 的章节。 -* 了解[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 +* 了解[污点和容忍度](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)。 diff --git a/content/zh-cn/docs/concepts/cluster-administration/_index.md b/content/zh-cn/docs/concepts/cluster-administration/_index.md index d37c50dcad..c340a741c7 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/_index.md +++ b/content/zh-cn/docs/concepts/cluster-administration/_index.md @@ -25,7 +25,7 @@ The cluster administration overview is for anyone creating or administering a Ku It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/). --> 集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。 -我们假设你大概了解一些核心的 Kubernetes [概念](/zh/docs/concepts/)。 +我们假设你大概了解一些核心的 Kubernetes [概念](/zh-cn/docs/concepts/)。 @@ -40,7 +40,7 @@ Before choosing a guide, here are some considerations: --> ## 规划集群 {#planning-a-cluster} -查阅[安装](/zh/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes +查阅[安装](/zh-cn/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版* 。 {{< note >}} @@ -68,12 +68,12 @@ Before choosing a guide, here are some considerations: - 你的集群是在**本地**还是**云（IaaS）** 上？Kubernetes 不能直接支持混合集群。 作为代替，你可以建立多个集群。 - **如果你在本地配置 Kubernetes**，需要考虑哪种 - [网络模型](/zh/docs/concepts/cluster-administration/networking/)最适合。 + [网络模型](/zh-cn/docs/concepts/cluster-administration/networking/)最适合。 - 你的 Kubernetes 在**裸金属硬件**上还是**虚拟机（VMs）** 上运行？ - 你是想**运行一个集群**，还是打算**参与开发 Kubernetes 项目代码**？ 如果是后者，请选择一个处于开发状态的发行版。 某些发行版只提供二进制发布版，但提供更多的选择。 -- 让你自己熟悉运行一个集群所需的[组件](/zh/docs/concepts/overview/components/)。 +- 让你自己熟悉运行一个集群所需的[组件](/zh-cn/docs/concepts/overview/components/)。 ## 管理集群 {#managing-a-cluster} -* 学习如何[管理节点](/zh/docs/concepts/architecture/nodes/)。 +* 学习如何[管理节点](/zh-cn/docs/concepts/architecture/nodes/)。 -* 学习如何设定和管理集群共享的[资源配额](/zh/docs/concepts/policy/resource-quotas/) 。 +* 学习如何设定和管理集群共享的[资源配额](/zh-cn/docs/concepts/policy/resource-quotas/) 。 ## 保护集群 {#securing-a-cluster} -* [生成证书](/zh/docs/tasks/administer-cluster/certificates/) +* [生成证书](/zh-cn/docs/tasks/administer-cluster/certificates/) 节描述了使用不同的工具链生成证书的步骤。 -* [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment/) +* [Kubernetes 容器环境](/zh-cn/docs/concepts/containers/container-environment/) 描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。 -* [控制到 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/) +* [控制到 Kubernetes API 的访问](/zh-cn/docs/concepts/security/controlling-access/) 描述了如何为用户和 service accounts 建立权限许可。 -* [身份认证](/zh/docs/reference/access-authn-authz/authentication/) +* [身份认证](/zh-cn/docs/reference/access-authn-authz/authentication/) 节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。 -* [鉴权](/zh/docs/reference/access-authn-authz/authorization/) +* [鉴权](/zh-cn/docs/reference/access-authn-authz/authorization/) 与身份认证不同，用于控制如何处理 HTTP 请求。 -* [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers) +* [使用准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。 -* [在 Kubernetes 集群中使用 Sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/) +* [在 Kubernetes 集群中使用 Sysctls](/zh-cn/docs/tasks/administer-cluster/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。 -* [审计](/zh/docs/tasks/debug/debug-cluster/audit/) +* [审计](/zh-cn/docs/tasks/debug/debug-cluster/audit/) 描述了如何与 Kubernetes 的审计日志交互。 ### 保护 kubelet {#securing-the-kubelet} -* [主控节点通信](/zh/docs/concepts/architecture/control-plane-node-communication/) -* [TLS 引导](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) -* [Kubelet 认证/授权](/zh/docs/reference/access-authn-authz/kubelet-authn-authz/) +* [主控节点通信](/zh-cn/docs/concepts/architecture/control-plane-node-communication/) +* [TLS 引导](/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) +* [Kubelet 认证/授权](/zh-cn/docs/reference/access-authn-authz/kubelet-authn-authz/) ## 可选集群服务 {#optional-cluster-services} -* [DNS 集成](/zh/docs/concepts/services-networking/dns-pod-service/) +* [DNS 集成](/zh-cn/docs/concepts/services-networking/dns-pod-service/) 描述了如何将一个 DNS 名解析到一个 Kubernetes service。 -* [记录和监控集群活动](/zh/docs/concepts/cluster-administration/logging/) +* [记录和监控集群活动](/zh-cn/docs/concepts/cluster-administration/logging/) 阐述了 Kubernetes 的日志如何工作以及怎样实现。 diff --git a/content/zh-cn/docs/concepts/cluster-administration/certificates.md b/content/zh-cn/docs/concepts/cluster-administration/certificates.md index b900e77ec9..2297ffac05 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/certificates.md +++ b/content/zh-cn/docs/concepts/cluster-administration/certificates.md @@ -14,5 +14,5 @@ weight: 20 -要了解如何为集群生成证书，参阅[证书](/zh/docs/tasks/administer-cluster/certificates/)。 +要了解如何为集群生成证书，参阅[证书](/zh-cn/docs/tasks/administer-cluster/certificates/)。 diff --git a/content/zh-cn/docs/concepts/cluster-administration/flow-control.md b/content/zh-cn/docs/concepts/cluster-administration/flow-control.md index a28154dfe6..746a7b4e3b 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/flow-control.md +++ b/content/zh-cn/docs/concepts/cluster-administration/flow-control.md @@ -86,7 +86,7 @@ command-line flags to your `kube-apiserver` invocation: --> API 优先级与公平性（APF）特性由特性门控控制，默认情况下启用。 有关特性门控的一般性描述以及如何启用和禁用特性门控， -请参见[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +请参见[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 APF 的特性门控称为 `APIPriorityAndFairness`。 此特性也与某个 {{< glossary_tooltip term_id="api-group" text="API 组" >}} 相关： diff --git a/content/zh-cn/docs/concepts/cluster-administration/logging.md b/content/zh-cn/docs/concepts/cluster-administration/logging.md index ff6e2612ed..8b53c28ae3 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/logging.md +++ b/content/zh-cn/docs/concepts/cluster-administration/logging.md @@ -478,7 +478,7 @@ a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to c --> 下面是两个配置文件，可以用来实现一个带日志代理的边车容器。 第一个文件包含用来配置 fluentd 的 -[ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)。 +[ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)。 {{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}} diff --git a/content/zh-cn/docs/concepts/cluster-administration/manage-deployment.md b/content/zh-cn/docs/concepts/cluster-administration/manage-deployment.md index 7d77f529e2..38bda5a21f 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/zh-cn/docs/concepts/cluster-administration/manage-deployment.md @@ -12,8 +12,8 @@ You've deployed your application and exposed it via a service. Now what? Kuberne 你已经部署了应用并通过服务暴露它。然后呢？ Kubernetes 提供了一些工具来帮助管理你的应用部署，包括扩缩容和更新。 我们将更深入讨论的特性包括 -[配置文件](/zh/docs/concepts/configuration/overview/)和 -[标签](/zh/docs/concepts/overview/working-with-objects/labels/)。 +[配置文件](/zh-cn/docs/concepts/configuration/overview/)和 +[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)。 @@ -85,7 +85,7 @@ A URL can also be specified as a configuration source, which is handy for deploy 还可以使用 URL 作为配置源，便于直接使用已经提交到 Github 上的配置文件进行部署： ```shell -kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/zh/examples/application/nginx/nginx-deployment.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/application/nginx/nginx-deployment.yaml ``` ``` @@ -239,7 +239,7 @@ persistentvolumeclaim/my-pvc created If you're interested in learning more about `kubectl`, go ahead and read [Command line tool (kubectl)](/docs/reference/kubectl/). --> 如果你有兴趣进一步学习关于 `kubectl` 的内容，请阅读 -[命令行工具（kubectl）](/zh/docs/reference/kubectl/)。 +[命令行工具（kubectl）](/zh-cn/docs/reference/kubectl/)。 想要了解更多信息，请参考 -[注解](/zh/docs/concepts/overview/working-with-objects/annotations/)和 +[注解](/zh-cn/docs/concepts/overview/working-with-objects/annotations/)和 [`kubectl annotate`](/docs/reference/generated/kubectl/kubectl-commands/#annotate) 命令文档。 @@ -535,7 +535,7 @@ For more information, please see [kubectl scale](/docs/reference/generated/kubec 想要了解更多信息，请参考 [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale)命令文档、 [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 命令文档和 -[水平 Pod 自动伸缩](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) 文档。 +[水平 Pod 自动伸缩](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) 文档。 你可以使用 `kubectl patch` 来更新 API 对象。此命令支持 JSON patch、 JSON merge patch、以及 strategic merge patch。 请参考 -[使用 kubectl patch 更新 API 对象](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) +[使用 kubectl patch 更新 API 对象](/zh-cn/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) 和 [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch). @@ -716,7 +716,7 @@ That's it! The Deployment will declaratively update the deployed nginx applicati --> 没错，就是这样！Deployment 将在后台逐步更新已经部署的 nginx 应用。 它确保在更新过程中，只有一定数量的旧副本被开闭，并且只有一定基于所需 Pod 数量的新副本被创建。 -想要了解更多细节，请参考 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/)。 +想要了解更多细节，请参考 [Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)。 ## {{% heading "whatsnext" %}} @@ -724,5 +724,5 @@ That's it! The Deployment will declaratively update the deployed nginx applicati - [Learn about how to use `kubectl` for application introspection and debugging.](/docs/tasks/debug/debug-application/debug-running-pod/) - [Configuration Best Practices and Tips](/docs/concepts/configuration/overview/) --> -- 学习[如何使用 `kubectl` 观察和调试应用](/zh/docs/tasks/debug/debug-application/debug-running-pod/) -- 阅读[配置最佳实践和技巧](/zh/docs/concepts/configuration/overview/) +- 学习[如何使用 `kubectl` 观察和调试应用](/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/) +- 阅读[配置最佳实践和技巧](/zh-cn/docs/concepts/configuration/overview/) diff --git a/content/zh-cn/docs/concepts/cluster-administration/networking.md b/content/zh-cn/docs/concepts/cluster-administration/networking.md index 4bfae1a551..edc6866ec8 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/networking.md +++ b/content/zh-cn/docs/concepts/cluster-administration/networking.md @@ -29,8 +29,8 @@ problems to address: 1. 高度耦合的容器间通信：这个已经被 {{< glossary_tooltip text="Pods" term_id="pod" >}} 和 `localhost` 通信解决了。 2. Pod 间通信：本文档讲述重点。 -3. Pod 和服务间通信：由[服务](/zh/docs/concepts/services-networking/service/)负责。 -4. 外部和服务间通信：也由[服务](/zh/docs/concepts/services-networking/service/)负责。 +3. Pod 和服务间通信：由[服务](/zh-cn/docs/concepts/services-networking/service/)负责。 +4. 外部和服务间通信：也由[服务](/zh-cn/docs/concepts/services-networking/service/)负责。 @@ -56,7 +56,7 @@ Kubernetes 的宗旨就是在应用之间共享机器。 而 API 服务器还需要知道如何将动态端口数值插入到配置模块中，服务也需要知道如何找到对方等等。 与其去解决这些问题，Kubernetes 选择了其他不同的方法。 -要了解 Kubernetes 网络模型，请参阅[此处](/zh/docs/concepts/services-networking/)。 +要了解 Kubernetes 网络模型，请参阅[此处](/zh-cn/docs/concepts/services-networking/)。 -1. [kubectl proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api)： +1. [kubectl proxy](/zh-cn/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api)： - 运行在用户的桌面或 pod 中 - 从本机地址到 Kubernetes apiserver 的代理 @@ -56,7 +56,7 @@ There are several different proxies you may encounter when using Kubernetes: - can be used to reach a Node, Pod, or Service - does load balancing when used to reach a Service --> -2. [apiserver proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services)： +2. [apiserver proxy](/zh-cn/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services)： - 是一个建立在 apiserver 内部的“堡垒” - 将集群外部的用户与集群 IP 相连接，这些IP是无法通过其他方式访问的 @@ -75,7 +75,7 @@ There are several different proxies you may encounter when using Kubernetes: - provides load balancing - is only used to reach services --> -3. [kube proxy](/zh/docs/concepts/services-networking/service/#ips-and-vips)： +3. [kube proxy](/zh-cn/docs/concepts/services-networking/service/#ips-and-vips)： - 在每个节点上运行 - 代理 UDP、TCP 和 SCTP diff --git a/content/zh-cn/docs/concepts/cluster-administration/system-logs.md b/content/zh-cn/docs/concepts/cluster-administration/system-logs.md index 164d416b9f..2365e3bd23 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/system-logs.md +++ b/content/zh-cn/docs/concepts/cluster-administration/system-logs.md @@ -38,7 +38,7 @@ klog 是 Kubernetes 的日志库。 [klog](https://github.com/kubernetes/klog) 为 Kubernetes 系统组件生成日志消息。 -有关 klog 配置的更多信息，请参见[命令行工具参考](/zh/docs/reference/command-line-tools-reference/)。 +有关 klog 配置的更多信息，请参见[命令行工具参考](/zh-cn/docs/reference/command-line-tools-reference/)。 JSON 输出并不支持太多标准 klog 参数。对于不受支持的 klog 参数的列表， -请参见[命令行工具参考](/zh/docs/reference/command-line-tools-reference/)。 +请参见[命令行工具参考](/zh-cn/docs/reference/command-line-tools-reference/)。 并不是所有日志都保证写成 JSON 格式（例如，在进程启动期间）。 如果你打算解析日志，请确保可以处理非 JSON 格式的日志行。 @@ -388,7 +388,7 @@ The `logrotate` tool rotates logs daily, or once the log size is greater than 10 * Read about [deprecation of klog flags](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) * Read about the [Conventions for logging severity](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) --> -* 阅读 [Kubernetes 日志架构](/zh/docs/concepts/cluster-administration/logging/) +* 阅读 [Kubernetes 日志架构](/zh-cn/docs/concepts/cluster-administration/logging/) * 阅读[结构化日志提案（英文）](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging) * 阅读[上下文日志提案（英文）](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging) * 阅读 [klog 参数的废弃（英文）](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) diff --git a/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md b/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md index f054161998..2f971177fe 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md +++ b/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md @@ -204,7 +204,7 @@ kubelet 在驱动程序上保持打开状态。这意味着为了执行基础结 现在，收集加速器指标的责任属于供应商，而不是 kubelet。供应商必须提供一个收集指标的容器， 并将其公开给指标服务（例如 Prometheus）。 -[`DisableAcceleratorUsageMetrics` 特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +[`DisableAcceleratorUsageMetrics` 特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 禁止由 kubelet 收集的指标。 关于[何时会在默认情况下启用此功能也有一定规划](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)。 @@ -271,7 +271,7 @@ The kube-scheduler identifies the resource [requests and limits](/docs/concepts/ - the unit of the resource if known (for example, `cores`) --> kube-scheduler 组件能够辩识各个 Pod 所配置的资源 -[请求和约束](/zh/docs/concepts/configuration/manage-resources-containers/)。 +[请求和约束](/zh-cn/docs/concepts/configuration/manage-resources-containers/)。 在 Pod 的资源请求值或者约束值非零时，kube-scheduler 会以度量值时间序列的形式 生成报告。该时间序列值包含以下标签： - 名字空间 @@ -341,4 +341,4 @@ Here is an example: * Read about the [Kubernetes deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) --> * 阅读有关指标的 [Prometheus 文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) -* 阅读有关 [Kubernetes 弃用策略](/zh/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) +* 阅读有关 [Kubernetes 弃用策略](/zh-cn/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) diff --git a/content/zh-cn/docs/concepts/cluster-administration/system-traces.md b/content/zh-cn/docs/concepts/cluster-administration/system-traces.md index 71ede2f3e7..2a3860a361 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/system-traces.md +++ b/content/zh-cn/docs/concepts/cluster-administration/system-traces.md @@ -114,7 +114,7 @@ with `--tracing-config-file=`. This is an example config that re spans for 1 in 10000 requests, and uses the default OpenTelemetry endpoint: --> 要启用追踪特性，需要启用 kube-apiserver 上的 `APIServerTracing` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 然后，使用 `--tracing-config-file=<<配置文件路径>` 为 kube-apiserver 提供追踪配置文件。 下面是一个示例配置，它为万分之一的请求记录 spans，并使用了默认的 OpenTelemetry 端口。 @@ -132,7 +132,7 @@ For more information about the `TracingConfiguration` struct, see --> 有关 TracingConfiguration 结构体的更多信息，请参阅 -[API 服务器配置 API (v1alpha1)](/zh/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration)。 +[API 服务器配置 API (v1alpha1)](/zh-cn/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration)。 ## ConfigMap 对象 -ConfigMap 是一个 API [对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)， +ConfigMap 是一个 API [对象](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/)， 让你可以存储其他对象所需要使用的配置。 和其他 Kubernetes 对象都有一个 `spec` 不同的是，ConfigMap 使用 `data` 和 `binaryData` 字段。这些字段能够接收键-值对作为其取值。`data` 和 `binaryData` @@ -81,7 +81,7 @@ ConfigMap 是一个 API [对象](/zh/docs/concepts/overview/working-with-objects 则被设计用来保存二进制数据作为 base64 编码的字串。 ConfigMap 的名字必须是一个合法的 -[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 {{< note >}} -使用 ConfigMap 作为 [subPath](/zh/docs/concepts/storage/volumes#using-subpath) 卷挂载的容器将不会收到 ConfigMap 的更新。 +使用 ConfigMap 作为 [subPath](/zh-cn/docs/concepts/storage/volumes#using-subpath) 卷挂载的容器将不会收到 ConfigMap 的更新。 {{< /note >}} 此功能特性由 `ImmutableEphemeralVolumes` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)来控制。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)来控制。 你可以通过将 `immutable` 字段设置为 `true` 创建不可变更的 ConfigMap。 例如： @@ -465,7 +465,7 @@ to the deleted ConfigMap, it is recommended to recreate these pods. * Read [The Twelve-Factor App](https://12factor.net/) to understand the motivation for separating code from configuration. --> -* 阅读 [Secret](/zh/docs/concepts/configuration/secret/)。 -* 阅读[配置 Pod 使用 ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)。 -* 阅读[修改 ConfigMap（或任何其他 Kubernetes 对象）](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。 +* 阅读 [Secret](/zh-cn/docs/concepts/configuration/secret/)。 +* 阅读[配置 Pod 使用 ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)。 +* 阅读[修改 ConfigMap（或任何其他 Kubernetes 对象）](/zh-cn/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。 * 阅读 [Twelve-Factor 应用](https://12factor.net/zh_cn/)来了解将代码和配置分开的动机。 diff --git a/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md b/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md index 001ab761ef..7c1d37f9fa 100644 --- a/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md +++ b/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md @@ -145,8 +145,8 @@ through the Kubernetes API server. --> CPU 和内存统称为“计算资源”，或简称为“资源”。 计算资源的数量是可测量的，可以被请求、被分配、被消耗。 -它们与 [API 资源](/zh/docs/concepts/overview/kubernetes-api/) 不同。 -API 资源（如 Pod 和 [Service](/zh/docs/concepts/services-networking/service/)）是可通过 +它们与 [API 资源](/zh-cn/docs/concepts/overview/kubernetes-api/) 不同。 +API 资源（如 Pod 和 [Service](/zh-cn/docs/concepts/services-networking/service/)）是可通过 Kubernetes API 服务器读取和修改的对象。 kubelet 也使用此类存储来保存 -[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， +[节点层面的容器日志](/zh-cn/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， 容器镜像文件、以及运行中容器的可写入层。 {{< caution >}} @@ -502,7 +502,7 @@ Kubernetes 有两种方式支持节点上配置本地临时性存储： （kubelet）来保存数据的。 kubelet 也会生成 -[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， +[节点层面的容器日志](/zh-cn/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， 并按临时性本地存储的方式对待之。 字段 `.status.allocatable` 描述节点上可以用于 Pod 的资源总量（例如：15 个虚拟 CPU、7538 MiB 内存）。关于 Kubernetes 中节点可分配资源的信息，可参阅 -[为系统守护进程预留计算资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/)。 +[为系统守护进程预留计算资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/)。 -你可以配置[资源配额](/zh/docs/concepts/policy/resource-quotas/)功能特性以限制每个名字空间可以使用的资源总量。 +你可以配置[资源配额](/zh-cn/docs/concepts/policy/resource-quotas/)功能特性以限制每个名字空间可以使用的资源总量。 当某名字空间中存在 ResourceQuota 时，Kubernetes 会在该名字空间中的对象强制实施配额。 例如，如果你为不同的团队分配名字空间，你可以为这些名字空间添加 ResourceQuota。 设置资源配额有助于防止一个团队占用太多资源，以至于这种占用会影响其他团队。 @@ -1375,10 +1375,10 @@ memory limit (and possibly request) for that container. * Read about [project quotas](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS * Read more about the [kube-scheduler configuration reference (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) --> -* 获取[分配内存资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验 -* 获取[分配 CPU 资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验 +* 获取[分配内存资源给容器和 Pod ](/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验 +* 获取[分配 CPU 资源给容器和 Pod ](/zh-cn/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验 * 阅读 API 参考中 [Container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container) 和其[资源请求](/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources)定义。 * 阅读 XFS 中[配额](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)的文档 -* 进一步阅读 [kube-scheduler 配置参考 (v1beta3)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/) +* 进一步阅读 [kube-scheduler 配置参考 (v1beta3)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/) diff --git a/content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index fa77d3c2de..c46b91d3c7 100644 --- a/content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -58,7 +58,7 @@ For step-by-step instructions on creating and specifying kubeconfig files, see [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters). --> 有关创建和指定 kubeconfig 文件的分步说明，请参阅 -[配置对多集群的访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。 +[配置对多集群的访问](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。 @@ -193,7 +193,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files: [Setting the KUBECONFIG environment variable](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable). --> 有关设置 `KUBECONFIG` 环境变量的示例，请参阅 - [设置 KUBECONFIG 环境变量](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。 + [设置 KUBECONFIG 环境变量](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。 -* [配置对多集群的访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +* [配置对多集群的访问](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) * [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config) diff --git a/content/zh-cn/docs/concepts/configuration/overview.md b/content/zh-cn/docs/concepts/configuration/overview.md index 01314daf34..b0d9c2a033 100644 --- a/content/zh-cn/docs/concepts/configuration/overview.md +++ b/content/zh-cn/docs/concepts/configuration/overview.md @@ -77,8 +77,8 @@ This is a living document. If you think of something that is not on this list bu - Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or [Deployment](/docs/concepts/workloads/controllers/deployment/)) if you can avoid it. Naked Pods will not be rescheduled in the event of a node failure. --> - 如果可能，不要使用独立的 Pods（即，未绑定到 -[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) 或 -[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 的 Pod）。 +[ReplicaSet](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 或 +[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/) 的 Pod）。 如果节点发生故障，将不会重新调度独立的 Pods。 Deployment 既可以创建一个 ReplicaSet 来确保预期个数的 Pod 始终可用，也可以指定替换 Pod 的策略（例如 -[RollingUpdate](/zh/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)）。 -除了一些显式的 [`restartPolicy: Never`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) -场景外，Deployment 通常比直接创建 Pod 要好得多。[Job](/zh/docs/concepts/workloads/controllers/job/) 也可能是合适的选择。 +[RollingUpdate](/zh-cn/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)）。 +除了一些显式的 [`restartPolicy: Never`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) +场景外，Deployment 通常比直接创建 Pod 要好得多。[Job](/zh-cn/docs/concepts/workloads/controllers/job/) 也可能是合适的选择。 - 在创建相应的后端工作负载（Deployment 或 ReplicaSet），以及在需要访问它的任何工作负载之前创建 - [服务](/zh/docs/concepts/services-networking/service/)。 + [服务](/zh-cn/docs/concepts/services-networking/service/)。 当 Kubernetes 启动容器时，它提供指向启动容器时正在运行的所有服务的环境变量。 例如，如果存在名为 `foo` 的服务，则所有容器将在其初始环境中获得以下变量。 @@ -118,7 +118,7 @@ Deployment 既可以创建一个 ReplicaSet 来确保预期个数的 Pod 始终 - An optional (though strongly recommended) [cluster add-on](/docs/concepts/cluster-administration/addons/) is a DNS server. The DNS server watches the Kubernetes API for new `Services` and creates a set of DNS records for each. If DNS has been enabled throughout the cluster then all `Pods` should be able to do name resolution of `Services` automatically. --> -- 一个可选（尽管强烈推荐）的[集群插件](/zh/docs/concepts/cluster-administration/addons/) +- 一个可选（尽管强烈推荐）的[集群插件](/zh-cn/docs/concepts/cluster-administration/addons/) 是 DNS 服务器。DNS 服务器为新的 `Services` 监视 Kubernetes API，并为每个创建一组 DNS 记录。 如果在整个集群中启用了 DNS，则所有 `Pods` 应该能够自动对 `Services` 进行名称解析。 @@ -135,14 +135,14 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN If you only need access to the port for debugging purposes, you can use the [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) or [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/). --> 如果你只需要访问端口以进行调试，则可以使用 - [apiserver proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)或 - [`kubectl port-forward`](/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。 + [apiserver proxy](/zh-cn/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)或 + [`kubectl port-forward`](/zh-cn/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。 如果你明确需要在节点上公开 Pod 的端口，请在使用 `hostPort` 之前考虑使用 - [NodePort](/zh/docs/concepts/services-networking/service/#type-nodeport) 服务。 + [NodePort](/zh-cn/docs/concepts/services-networking/service/#type-nodeport) 服务。 - 当你不需要 `kube-proxy` 负载均衡时，使用 - [无头服务](/zh/docs/concepts/services-networking/service/#headless-services) + [无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services) (`ClusterIP` 被设置为 `None`)以便于服务发现。 -- 定义并使用[标签](/zh/docs/concepts/overview/working-with-objects/labels/)来识别应用程序 +- 定义并使用[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)来识别应用程序 或 Deployment 的 __语义属性__，例如`{ app: myapp, tier: frontend, phase: test, deployment: v3 }`。 你可以使用这些标签为其他资源选择合适的 Pod； 例如，一个选择所有 `tier: frontend` Pod 的服务，或者 `app: myapp` 的所有 `phase: test` 组件。 @@ -175,7 +175,7 @@ services) (which have a `ClusterIP` of `None`) for service discovery when you do A Service can be made to span multiple Deployments by omitting release-specific labels from its selector. [Deployments](/docs/concepts/workloads/controllers/deployment/) make it easy to update a running service without downtime. --> 通过从选择器中省略特定发行版的标签，可以使服务跨越多个 Deployment。 -当你需要不停机的情况下更新正在运行的服务，可以使用[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)。 +当你需要不停机的情况下更新正在运行的服务，可以使用[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)。 -- 对于常见场景，应使用 [Kubernetes 通用标签](/zh/docs/concepts/overview/working-with-objects/common-labels/)。 +- 对于常见场景，应使用 [Kubernetes 通用标签](/zh-cn/docs/concepts/overview/working-with-objects/common-labels/)。 这些标准化的标签丰富了对象的元数据，使得包括 `kubectl` 和 - [仪表板（Dashboard）](/zh/docs/tasks/access-application-cluster/web-ui-dashboard) + [仪表板（Dashboard）](/zh-cn/docs/tasks/access-application-cluster/web-ui-dashboard) 这些工具能够以可互操作的方式工作。 - 使用标签选择器进行 `get` 和 `delete` 操作，而不是特定的对象名称。 -- 请参阅[标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)和 - [有效使用标签](/zh/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)部分。 +- 请参阅[标签选择器](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)和 + [有效使用标签](/zh-cn/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)部分。 - 使用`kubectl run`和`kubectl expose`来快速创建单容器部署和服务。 - 有关示例，请参阅[使用服务访问集群中的应用程序](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/)。 + 有关示例，请参阅[使用服务访问集群中的应用程序](/zh-cn/docs/tasks/access-application-cluster/service-access-application-cluster/)。 diff --git a/content/zh-cn/docs/concepts/configuration/secret.md b/content/zh-cn/docs/concepts/configuration/secret.md index 961b149257..b67534c238 100644 --- a/content/zh-cn/docs/concepts/configuration/secret.md +++ b/content/zh-cn/docs/concepts/configuration/secret.md @@ -74,8 +74,8 @@ In order to safely use Secrets, take at least the following steps: 为了安全地使用 Secret，请至少执行以下步骤： -1. 为 Secret [启用静态加密](/zh/docs/tasks/administer-cluster/encrypt-data/)； -1. [启用或配置 RBAC 规则](/zh/docs/reference/access-authn-authz/authorization/)来限制读取和写入 +1. 为 Secret [启用静态加密](/zh-cn/docs/tasks/administer-cluster/encrypt-data/)； +1. [启用或配置 RBAC 规则](/zh-cn/docs/reference/access-authn-authz/authorization/)来限制读取和写入 Secret 的数据（包括通过间接方式）。需要注意的是，被准许创建 Pod 的人也隐式地被授权获取 Secret 内容。 1. 在适当的情况下，还可以使用 RBAC 等机制来限制允许哪些主体创建新 Secret 或替换现有 Secret。 @@ -139,7 +139,7 @@ Here are some of your options: token). --> - 如果你的云原生组件需要执行身份认证来访问你所知道的、在同一 Kubernetes 集群中运行的另一个应用， - 你可以使用 [ServiceAccount](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens) + 你可以使用 [ServiceAccount](/zh-cn/docs/reference/access-authn-authz/authentication/#service-account-tokens) 及其令牌来标识你的客户端身份。 - 你可以运行的第三方工具也有很多，这些工具可以运行在集群内或集群外，提供机密数据管理。 例如，这一工具可能是 Pod 通过 HTTPS 访问的一个服务，该服务在客户端能够正确地通过身份认证 @@ -153,9 +153,9 @@ Here are some of your options: trusted Pods onto nodes that provide a Trusted Platform Module, configured out-of-band. --> - 就身份认证而言，你可以为 X.509 证书实现一个定制的签名者，并使用 - [CertificateSigningRequest](/zh/docs/reference/access-authn-authz/certificate-signing-requests/) + [CertificateSigningRequest](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/) 来让该签名者为需要证书的 Pod 发放证书。 -- 你可以使用一个[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +- 你可以使用一个[设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) 来将节点本地的加密硬件暴露给特定的 Pod。例如，你可以将可信任的 Pod 调度到提供可信平台模块（Trusted Platform Module，TPM）的节点上。 这类节点是另行配置的。 @@ -191,9 +191,9 @@ There are several options to create a Secret: ### 创建 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/) +- [使用 `kubectl` 命令来创建 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- [基于配置文件来创建 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- [使用 kustomize 来创建 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kustomize/) -你仍然可以[手动创建](/zh/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token) +你仍然可以[手动创建](/zh-cn/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 服务器的令牌。 @@ -648,7 +648,7 @@ A container using a Secret as a [subPath](/docs/concepts/storage/volumes#using-subpath) volume mount does not receive automated Secret updates. --> -对于以 [subPath](/zh/docs/concepts/storage/volumes#using-subpath) 形式挂载 Secret 卷的容器而言， +对于以 [subPath](/zh-cn/docs/concepts/storage/volumes#using-subpath) 形式挂载 Secret 卷的容器而言， 它们无法收到自动的 Secret 更新。 {{< /note >}} @@ -660,7 +660,7 @@ the [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/) --> Kubelet 组件会维护一个缓存，在其中保存节点上 Pod 卷中使用的 Secret 的当前主键和取值。 你可以配置 kubelet 如何检测所缓存数值的变化。 -[kubelet 配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/)中的 +[kubelet 配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/)中的 `configMapAndSecretChangeDetectionStrategy` 字段控制 kubelet 所采用的策略。 默认的策略是 `Watch`。 @@ -886,7 +886,7 @@ documentation. --> ##### 手动设定 imagePullSecret {#manually-specifying-an-imagepullsecret} -你可以通过阅读[容器镜像](/zh/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) +你可以通过阅读[容器镜像](/zh-cn/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) 文档了解如何设置 `imagePullSecrets`。 -参考 [ServiceAccount](/zh/docs/tasks/configure-pod-container/configure-service-account/) +参考 [ServiceAccount](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/) 文档了解服务账号的工作原理。你也可以查看 [`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) 资源中的 `automountServiceAccountToken` 和 `serviceAccountName` 字段文档， @@ -1814,7 +1814,7 @@ The following YAML contains an example config for a TLS Secret: Kubernetes 提供一种内置的 `kubernetes.io/tls` Secret 类型，用来存放 TLS 场合通常要使用的证书及其相关密钥。 -TLS Secret 的一种典型用法是为 [Ingress](/zh/docs/concepts/services-networking/ingress/) +TLS Secret 的一种典型用法是为 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/) 资源配置传输过程中的数据加密，不过也可以用于其他资源或者直接在负载中使用。 当使用此类型的 Secret 时，Secret 配置中的 `data` （或 `stringData`）字段必须包含 `tls.key` 和 `tls.crt` 主键，尽管 API 服务器实际上并不会对每个键的取值作进一步的合法性检查。 @@ -2164,8 +2164,8 @@ on that node. [authorization policies](/docs/reference/access-authn-authz/authorization/) such as [RBAC](/docs/reference/access-authn-authz/rbac/). --> -- 部署与 Secret API 交互的应用时，你应该使用 [RBAC](/zh/docs/reference/access-authn-authz/rbac/) - 这类[鉴权策略](/zh/docs/reference/access-authn-authz/authorization/)来限制访问。 +- 部署与 Secret API 交互的应用时，你应该使用 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) + 这类[鉴权策略](/zh-cn/docs/reference/access-authn-authz/authorization/)来限制访问。 -- 学习如何[使用 `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/) -- 阅读 [API 参考](/zh/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)了解 `Secret` +- 学习如何[使用 `kubectl` 管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- 学习如何[使用配置文件管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- 学习如何[使用 kustomize 管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kustomize/) +- 阅读 [API 参考](/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)了解 `Secret` diff --git a/content/zh-cn/docs/concepts/configuration/windows-resource-management.md b/content/zh-cn/docs/concepts/configuration/windows-resource-management.md index a34682f5ae..4a4cefb483 100644 --- a/content/zh-cn/docs/concepts/configuration/windows-resource-management.md +++ b/content/zh-cn/docs/concepts/configuration/windows-resource-management.md @@ -104,7 +104,7 @@ On Windows these values are only used to calculate the node's 为了满足操作系统、容器运行时和 kubelet 等 Kubernetes 主机进程使用的内存和 CPU， 你可以（且应该）用 `--kube-reserved` 和/或 `--system-reserved` kubelet 标志来预留内存和 CPU 资源。 -在 Windows 上，这些值仅用于计算节点的[可分配](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)资源。 +在 Windows 上，这些值仅用于计算节点的[可分配](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)资源。 ## 容器镜像 {#container-images} -[容器镜像](/zh/docs/concepts/containers/images/)是一个随时可以运行的软件包， +[容器镜像](/zh-cn/docs/concepts/containers/images/)是一个随时可以运行的软件包， 包含运行应用程序所需的一切：代码和它需要的所有运行时、应用程序和系统库，以及一些基本设置的默认值。 根据设计，容器是不可变的：你不能更改已经运行的容器的代码。 @@ -53,7 +53,7 @@ the change, then recreate the container to start from the updated image. * Read about [Pods](/docs/concepts/workloads/pods/) --> -* 进一步阅读[容器镜像](/zh/docs/concepts/containers/images/) -* 进一步阅读 [Pods](/zh/docs/concepts/workloads/pods/) +* 进一步阅读[容器镜像](/zh-cn/docs/concepts/containers/images/) +* 进一步阅读 [Pods](/zh-cn/docs/concepts/workloads/pods/) diff --git a/content/zh-cn/docs/concepts/containers/container-environment.md b/content/zh-cn/docs/concepts/containers/container-environment.md index 362e9d4c1b..32ed23ba50 100644 --- a/content/zh-cn/docs/concepts/containers/container-environment.md +++ b/content/zh-cn/docs/concepts/containers/container-environment.md @@ -34,8 +34,8 @@ The Kubernetes Container environment provides several important resources to Con Kubernetes 的容器环境给容器提供了几个重要的资源： -* 文件系统，其中包含一个[镜像](/zh/docs/concepts/containers/images/) - 和一个或多个的[卷](/zh/docs/concepts/storage/volumes/) +* 文件系统，其中包含一个[镜像](/zh-cn/docs/concepts/containers/images/) + 和一个或多个的[卷](/zh-cn/docs/concepts/storage/volumes/) * 容器自身的信息 * 集群中其他对象的信息 @@ -59,7 +59,7 @@ as are any environment variables specified statically in the container image. [`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html) 函数来获取。 Pod 名称和命名空间可以通过 -[下行 API](/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) +[下行 API](/zh-cn/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) 转换为环境变量。 Pod 定义中的用户所定义的环境变量也可在容器中使用，就像在 container 镜像中静态指定的任何环境变量一样。 @@ -100,7 +100,7 @@ if [DNS addon](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addon * Get hands-on experience [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). --> -* 学习更多有关[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)的知识 -* 动手[为容器生命周期事件添加处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) +* 学习更多有关[容器生命周期回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks/)的知识 +* 动手[为容器生命周期事件添加处理程序](/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) diff --git a/content/zh-cn/docs/concepts/containers/container-lifecycle-hooks.md b/content/zh-cn/docs/concepts/containers/container-lifecycle-hooks.md index 32d86af26a..9791183f47 100644 --- a/content/zh-cn/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/zh-cn/docs/concepts/containers/container-lifecycle-hooks.md @@ -80,7 +80,7 @@ A more detailed description of the termination behavior can be found in [Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination). --> 有关终止行为的更详细描述，请参见 -[终止 Pod](/zh/docs/concepts/workloads/pods/pod-lifecycle/#termination-of-pods)。 +[终止 Pod](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#termination-of-pods)。 -* 进一步了解[容器环境](/zh/docs/concepts/containers/container-environment/) -* 动手实践，[为容器生命周期事件添加处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) +* 进一步了解[容器环境](/zh-cn/docs/concepts/containers/container-environment/) +* 动手实践，[为容器生命周期事件添加处理程序](/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) diff --git a/content/zh-cn/docs/concepts/containers/images.md b/content/zh-cn/docs/concepts/containers/images.md index 12c48ef463..f3783775cc 100644 --- a/content/zh-cn/docs/concepts/containers/images.md +++ b/content/zh-cn/docs/concepts/containers/images.md @@ -101,7 +101,7 @@ these values have: --> ### 镜像拉取策略 {#image-pull-policy} -容器的 `imagePullPolicy` 和镜像的标签会影响 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 尝试拉取（下载）指定的镜像。 +容器的 `imagePullPolicy` 和镜像的标签会影响 [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 尝试拉取（下载）指定的镜像。 以下列表包含了 `imagePullPolicy` 可以设置的值，以及这些值的效果： @@ -179,7 +179,7 @@ running the same code no matter what tag changes happen at the registry. 镜像摘要唯一标识了镜像的特定版本，因此 Kubernetes 每次启动具有指定镜像名称和摘要的容器时，都会运行相同的代码。 通过摘要指定镜像可固定你运行的代码，这样镜像仓库的变化就不会导致版本的混杂。 -有一些第三方的[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) +有一些第三方的[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/) 在创建 Pod（和 Pod 模板）时产生变更，这样运行的工作负载就是根据镜像摘要，而不是标签来定义的。 无论镜像仓库上的标签发生什么变化，你都想确保你所有的工作负载都运行相同的代码，那么指定镜像摘要会很有用。 @@ -247,7 +247,7 @@ If you would like to always force a pull, you can do one of the following: 当你提交 Pod 时，Kubernetes 会将策略设置为 `Always`。 - 省略 `imagePullPolicy` 和镜像的标签； 当你提交 Pod 时，Kubernetes 会将策略设置为 `Always`。 -- 启用准入控制器 [AlwaysPullImages](/zh/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。 +- 启用准入控制器 [AlwaysPullImages](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。 有关配置私有容器镜像仓库的示例，请参阅任务 -[从私有镜像库中提取图像](/zh/docs/tasks/configure-pod-container/pull-image-private-registry)。 +[从私有镜像库中提取图像](/zh-cn/docs/tasks/configure-pod-container/pull-image-private-registry)。 该示例使用 Docker Hub 中的私有注册表。 你需要对使用私有仓库的每个 Pod 执行以上操作。 不过，设置该字段的过程也可以通过为 -[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/) +[服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/) 资源设置 `imagePullSecrets` 来自动完成。 有关详细指令可参见 -[将 ImagePullSecrets 添加到服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)。 +[将 ImagePullSecrets 添加到服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)。 你也可以将此方法与节点级别的 `.docker/config.json` 配置结合使用。 来自不同来源的凭据会被合并。 @@ -685,7 +685,7 @@ common use cases and suggested solutions. - Move sensitive data into a "Secret" resource, instead of packaging it in an image. --> 3. 集群使用专有镜像，且有些镜像需要更严格的访问控制 - - 确保 [AlwaysPullImages 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)被启用。否则，所有 Pod 都可以使用所有镜像。 + - 确保 [AlwaysPullImages 准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)被启用。否则，所有 Pod 都可以使用所有镜像。 - 确保将敏感数据存储在 Secret 资源中，而不是将其打包在镜像里 4. 集群是多租户的并且每个租户需要自己的私有仓库 - - 确保 [AlwaysPullImages 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。否则，所有租户的所有的 Pod 都可以使用所有镜像。 + - 确保 [AlwaysPullImages 准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。否则，所有租户的所有的 Pod 都可以使用所有镜像。 - 为私有仓库启用鉴权 - 为每个租户生成访问仓库的凭据，放置在 Secret 中，并将 Secrert 发布到各租户的命名空间下。 - 租户将 Secret 添加到每个名字空间中的 imagePullSecrets @@ -716,4 +716,4 @@ Kubelet will merge any `imagePullSecrets` into a single virtual `.docker/config. * Learn about [container image garbage collection](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection). --> * 阅读 [OCI Image Manifest 规范](https://github.com/opencontainers/image-spec/blob/master/manifest.md)。 -* 了解[容器镜像垃圾收集](/zh/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)。 +* 了解[容器镜像垃圾收集](/zh-cn/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)。 diff --git a/content/zh-cn/docs/concepts/containers/runtime-class.md b/content/zh-cn/docs/concepts/containers/runtime-class.md index 99b9f8851d..5eb922eee5 100644 --- a/content/zh-cn/docs/concepts/containers/runtime-class.md +++ b/content/zh-cn/docs/concepts/containers/runtime-class.md @@ -92,7 +92,7 @@ The configurations have a corresponding `handler` name, referenced by the Runtim handler must be a valid [DNS label name](/docs/concepts/overview/working-with-objects/names/#dns-label-names). --> 所有这些配置都具有相应的 `handler` 名，并被 RuntimeClass 引用。 -handler 必须是有效的 [DNS 标签名](/zh/docs/concepts/overview/working-with-objects/names/#dns-label-names)。 +handler 必须是有效的 [DNS 标签名](/zh-cn/docs/concepts/overview/working-with-objects/names/#dns-label-names)。 {{< note >}} 建议将 RuntimeClass 写操作（create、update、patch 和 delete）限定于集群管理员使用。 -通常这是默认配置。参阅[授权概述](/zh/docs/reference/access-authn-authz/authorization/)了解更多信息。 +通常这是默认配置。参阅[授权概述](/zh-cn/docs/reference/access-authn-authz/authorization/)了解更多信息。 {{< /note >}} 这一设置会告诉 kubelet 使用所指的 RuntimeClass 来运行该 pod。 如果所指的 RuntimeClass 不存在或者 CRI 无法运行相应的 handler， -那么 pod 将会进入 `Failed` 终止[阶段](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)。 -你可以查看相应的[事件](/zh/docs/tasks/debug/debug-application/debug-running-pod/)， +那么 pod 将会进入 `Failed` 终止[阶段](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)。 +你可以查看相应的[事件](/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/)， 获取执行过程中的错误信息。 更多有关 node selector 和 tolerations 的配置信息，请查阅 -[将 Pod 分派到节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)。 +[将 Pod 分派到节点](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/)。 - [RuntimeClass 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md) - [RuntimeClass 调度设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling) -- 阅读关于 [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/) 的概念 +- 阅读关于 [Pod 开销](/zh-cn/docs/concepts/scheduling-eviction/pod-overhead/) 的概念 - [PodOverhead 特性设计](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) From f0ddd217db97a00e0ed36d55891f94a24c4fde30 Mon Sep 17 00:00:00 2001 From: howieyuen Date: Thu, 23 Jun 2022 20:17:26 +0800 Subject: [PATCH 044/209] [zh]Update concepts pages(part-2) for links with '/zh/' prefix, using new prefix '/zh-cn/' --- .../docs/concepts/extend-kubernetes/_index.md | 66 +++++++++---------- .../api-extension/apiserver-aggregation.md | 8 +-- .../api-extension/custom-resources.md | 46 ++++++------- .../compute-storage-net/device-plugins.md | 20 +++--- .../concepts/extend-kubernetes/operator.md | 10 +-- .../extend-kubernetes/service-catalog.md | 6 +- .../docs/concepts/overview/components.md | 18 ++--- .../docs/concepts/overview/kubernetes-api.md | 22 +++---- .../concepts/overview/what-is-kubernetes.md | 4 +- .../working-with-objects/annotations.md | 2 +- .../working-with-objects/field-selectors.md | 6 +- .../working-with-objects/finalizers.md | 2 +- .../kubernetes-objects.md | 10 +-- .../overview/working-with-objects/labels.md | 24 +++---- .../overview/working-with-objects/names.md | 8 +-- .../working-with-objects/namespaces.md | 22 +++---- .../working-with-objects/object-management.md | 8 +-- .../working-with-objects/owners-dependents.md | 10 +-- .../zh-cn/docs/concepts/policy/limit-range.md | 16 ++--- .../concepts/policy/node-resource-managers.md | 8 +-- .../docs/concepts/policy/pid-limiting.md | 14 ++-- 21 files changed, 165 insertions(+), 165 deletions(-) diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/_index.md b/content/zh-cn/docs/concepts/extend-kubernetes/_index.md index e6f8d4bf86..95b0b1cf31 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/_index.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/_index.md @@ -79,11 +79,11 @@ Customization approaches can be broadly divided into *configuration*, which only 配置文件和参数标志的说明位于在线文档的参考章节，按可执行文件组织： -* [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) -* [kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/) -* [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) -* [kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) -* [kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/). +* [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) +* [kube-proxy](/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/) +* [kube-apiserver](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/) +* [kube-controller-manager](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/) +* [kube-scheduler](/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/). -*内置的策略 API*，例如[ResourceQuota](/zh/docs/concepts/policy/resource-quotas/)、 -[PodSecurityPolicies](/zh/docs/concepts/security/pod-security-policy/)、 -[NetworkPolicy](/zh/docs/concepts/services-networking/network-policies/) -和基于角色的访问控制（[RBAC](/zh/docs/reference/access-authn-authz/rbac/)） +*内置的策略 API*，例如[ResourceQuota](/zh-cn/docs/concepts/policy/resource-quotas/)、 +[PodSecurityPolicies](/zh-cn/docs/concepts/security/pod-security-policy/)、 +[NetworkPolicy](/zh-cn/docs/concepts/services-networking/network-policies/) +和基于角色的访问控制（[RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/)） 等等都是内置的 Kubernetes API。 API 通常用于托管的 Kubernetes 服务和受控的 Kubernetes 安装环境中。 这些 API 是声明式的，与 Pod 这类其他 Kubernetes 资源遵从相同的约定， 所以新的集群配置是可复用的，并且可以当作应用程序来管理。 此外，对于稳定版本的 API 而言，它们与其他 Kubernetes API 一样， -采纳的是一种[预定义的支持策略](/zh/docs/reference/using-api/deprecation-policy/)。 +采纳的是一种[预定义的支持策略](/zh-cn/docs/reference/using-api/deprecation-policy/)。 出于以上原因，在条件允许的情况下，基于 API 的方案应该优先于配置文件和参数标志。 1. 用户通常使用 `kubectl` 与 Kubernetes API 交互。 - [kubectl 插件](/zh/docs/tasks/extend-kubectl/kubectl-plugins/)能够扩展 kubectl 程序的行为。 + [kubectl 插件](/zh-cn/docs/tasks/extend-kubectl/kubectl-plugins/)能够扩展 kubectl 程序的行为。 这些插件只会影响到每个用户的本地环境，因此无法用来强制实施整个站点范围的策略。 2. API 服务器处理所有请求。API 服务器中的几种扩展点能够使用户对请求执行身份认证、 @@ -273,7 +273,7 @@ For more about Custom Resources, see the [Custom Resources concept guide](/docs/ 不要使用自定义资源来充当应用、用户或者监控数据的数据存储。 -关于自定义资源的更多信息，可参见[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 +关于自定义资源的更多信息，可参见[自定义资源概念指南](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 ### 身份认证 {#authentication} -[身份认证](/zh/docs/reference/access-authn-authz/authentication/)负责将所有请求中 +[身份认证](/zh-cn/docs/reference/access-authn-authz/authentication/)负责将所有请求中 的头部或证书映射到发出该请求的客户端的用户名。 Kubernetes 提供若干种内置的认证方法，以及 -[认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) +[认证 Webhook](/zh-cn/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法以备内置方法无法满足你的要求。 ### 鉴权 {#authorization} -[鉴权](/zh/docs/reference/access-authn-authz/authorization/) +[鉴权](/zh-cn/docs/reference/access-authn-authz/authorization/) 操作负责确定特定的用户是否可以读、写 API 资源或对其执行其他操作。 此操作仅在整个资源集合的层面进行。 换言之，它不会基于对象的特定字段作出不同的判决。 如果内置的鉴权选项无法满足你的需要，你可以使用 -[鉴权 Webhook](/zh/docs/reference/access-authn-authz/webhook/)来调用用户提供 +[鉴权 Webhook](/zh-cn/docs/reference/access-authn-authz/webhook/)来调用用户提供 的代码，执行定制的鉴权操作。 ### 设备插件 {#device-plugins} -使用[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)， +使用[设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)， 节点能够发现新的节点资源（除了内置的类似 CPU 和内存这类资源）。 ### 网络插件 {#network-plugins} -通过节点层面的[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)， +通过节点层面的[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)， 可以支持不同的网络设施。 -* 进一步了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) -* 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) +* 进一步了解[自定义资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* 了解[动态准入控制](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/) * 进一步了解基础设施扩展 - * [网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) - * [设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) -* 了解 [kubectl 插件](/zh/docs/tasks/extend-kubectl/kubectl-plugins/) -* 了解 [Operator 模式](/zh/docs/concepts/extend-kubernetes/operator/) + * [网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) + * [设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +* 了解 [kubectl 插件](/zh-cn/docs/tasks/extend-kubectl/kubectl-plugins/) +* 了解 [Operator 模式](/zh-cn/docs/concepts/extend-kubernetes/operator/) diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index d2a0c6c188..52a0c64e7e 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -32,7 +32,7 @@ The aggregation layer is different from [Custom Resources](/docs/concepts/extend 或者你自己开发的 API。 聚合层不同于 -[定制资源（Custom Resources）](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 +[定制资源（Custom Resources）](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 后者的目的是让 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} 能够认识新的对象类别（Kind）。 @@ -83,10 +83,10 @@ If your extension API server cannot achieve that latency requirement, consider m Alternatively: learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). --> -* 阅读[配置聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 文档， +* 阅读[配置聚合层](/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 文档， 了解如何在自己的环境中启用聚合器。 -* 接下来，了解[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)， +* 接下来，了解[安装扩展 API 服务器](/zh-cn/docs/tasks/extend-kubernetes/setup-extension-api-server/)， 开始使用聚合层。 * 从 API 参考资料中研究关于 [APIService](/docs/reference/kubernetes-api/cluster-resources/api-service-v1/) 的内容。 -或者，学习如何[使用自定义资源定义扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。 +或者，学习如何[使用自定义资源定义扩展 Kubernetes API](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。 diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index e2021c4043..f69c13963f 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -37,9 +37,9 @@ collection of Pod objects. ## 定制资源 *资源（Resource）* 是 -[Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/) 中的一个端点， +[Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api/) 中的一个端点， 其中存储的是某个类别的 -[API 对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/) +[API 对象](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/) 的一个集合。 例如内置的 *pods* 资源包含一组 Pod 对象。 @@ -84,7 +84,7 @@ keep the current state of Kubernetes objects in sync with the desired state. The controller interprets the structured data as a record of the user's desired state, and continually maintains this state. --> -使用[声明式 API](/zh/docs/concepts/overview/kubernetes-api/)， +使用[声明式 API](/zh-cn/docs/concepts/overview/kubernetes-api/)， 你可以 _声明_ 或者设定你的资源的期望状态，并尝试让 Kubernetes 对象的当前状态 同步到其期望状态。控制器负责将结构化的数据解释为用户所期望状态的记录，并 持续地维护该状态。 @@ -99,7 +99,7 @@ for specific applications into an extension of the Kubernetes API. --> 你可以在一个运行中的集群上部署和更新定制控制器，这类操作与集群的生命周期无关。 定制控制器可以用于任何类别的资源，不过它们与定制资源结合起来时最为有效。 -[Operator 模式](/zh/docs/concepts/extend-kubernetes/operator/)就是将定制资源 +[Operator 模式](/zh-cn/docs/concepts/extend-kubernetes/operator/)就是将定制资源 与定制控制器相结合的。你可以使用定制控制器来将特定于某应用的领域知识组织 起来，以编码的形式构造对 Kubernetes API 的扩展。 @@ -113,7 +113,7 @@ or let your API stand alone. ## 我是否应该向我的 Kubernetes 集群添加定制资源？ 在创建新的 API 时，请考虑是 -[将你的 API 与 Kubernetes 集群 API 聚合起来](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +[将你的 API 与 Kubernetes 集群 API 聚合起来](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 还是让你的 API 独立运行。 {{< note >}} -请使用 [Secret](/zh/docs/concepts/configuration/secret/) 来保存敏感数据。 +请使用 [Secret](/zh-cn/docs/concepts/configuration/secret/) 来保存敏感数据。 Secret 类似于 configMap，但更为安全。 {{< /note >}} @@ -251,7 +251,7 @@ Kubernetes provides two ways to add custom resources to your cluster: Kubernetes 提供了两种方式供你向集群中添加定制资源： - CRD 相对简单，创建 CRD 可以不必编程。 -- [API 聚合](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +- [API 聚合](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 需要编程，但支持对 API 行为进行更多的控制，例如数据如何存储以及在不同 API 版本间如何转换等。 ## CustomResourceDefinitions -[CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) +[CustomResourceDefinition](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) API 资源允许你定义定制资源。 定义 CRD 对象的操作会使用你所设定的名字和模式定义（Schema）创建一个新的定制资源， Kubernetes API 负责为你的定制资源提供存储和访问服务。 CRD 对象的名称必须是合法的 -[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 | 特性 | 描述 | CRDs | 聚合 API | | ------- | ----------- | ---- | -------------- | -| 合法性检查 | 帮助用户避免错误，允许你独立于客户端版本演化 API。这些特性对于由很多无法同时更新的客户端的场合。| 可以。大多数验证可以使用 [OpenAPI v3.0 合法性检查](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) 来设定。其他合法性检查操作可以通过添加[合法性检查 Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)来实现。 | 可以，可执行任何合法性检查。| -| 默认值设置 | 同上 | 可以。可通过 [OpenAPI v3.0 合法性检查](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting)的 `default` 关键词（自 1.17 正式发布）或[更改性（Mutating）Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)来实现（不过从 etcd 中读取老的对象时不会执行这些 Webhook）。 | 可以。 | -| 多版本支持 | 允许通过两个 API 版本同时提供同一对象。可帮助简化类似字段更名这类 API 操作。如果你能控制客户端版本，这一特性将不再重要。 | [可以](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning)。 | 可以。 | +| 合法性检查 | 帮助用户避免错误，允许你独立于客户端版本演化 API。这些特性对于由很多无法同时更新的客户端的场合。| 可以。大多数验证可以使用 [OpenAPI v3.0 合法性检查](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) 来设定。其他合法性检查操作可以通过添加[合法性检查 Webhook](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)来实现。 | 可以，可执行任何合法性检查。| +| 默认值设置 | 同上 | 可以。可通过 [OpenAPI v3.0 合法性检查](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting)的 `default` 关键词（自 1.17 正式发布）或[更改性（Mutating）Webhook](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)来实现（不过从 etcd 中读取老的对象时不会执行这些 Webhook）。 | 可以。 | +| 多版本支持 | 允许通过两个 API 版本同时提供同一对象。可帮助简化类似字段更名这类 API 操作。如果你能控制客户端版本，这一特性将不再重要。 | [可以](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning)。 | 可以。 | | 定制存储 | 支持使用具有不同性能模式的存储（例如，要使用时间序列数据库而不是键值存储），或者因安全性原因对存储进行隔离（例如对敏感信息执行加密）。 | 不可以。 | 可以。 | -| 定制业务逻辑 | 在创建、读取、更新或删除对象时，执行任意的检查或操作。 | 可以。要使用 [Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 | 可以。 | -| 支持 scale 子资源 | 允许 HorizontalPodAutoscaler 和 PodDisruptionBudget 这类子系统与你的新资源交互。 | [可以](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource)。 | 可以。 | -| 支持 status 子资源 | 允许在用户写入 spec 部分而控制器写入 status 部分时执行细粒度的访问控制。允许在对定制资源的数据进行更改时增加对象的代际（Generation）；这需要资源对 spec 和 status 部分有明确划分。| [可以](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource)。 | 可以。 | +| 定制业务逻辑 | 在创建、读取、更新或删除对象时，执行任意的检查或操作。 | 可以。要使用 [Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 | 可以。 | +| 支持 scale 子资源 | 允许 HorizontalPodAutoscaler 和 PodDisruptionBudget 这类子系统与你的新资源交互。 | [可以](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource)。 | 可以。 | +| 支持 status 子资源 | 允许在用户写入 spec 部分而控制器写入 status 部分时执行细粒度的访问控制。允许在对定制资源的数据进行更改时增加对象的代际（Generation）；这需要资源对 spec 和 status 部分有明确划分。| [可以](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource)。 | 可以。 | | 其他子资源 | 添加 CRUD 之外的操作，例如 "logs" 或 "exec"。 | 不可以。 | 可以。 | -| strategic-merge-patch | 新的端点要支持标记了 `Content-Type: application/strategic-merge-patch+json` 的 PATCH 操作。对于更新既可在本地更改也可在服务器端更改的对象而言是有用的。要了解更多信息，可参见[使用 `kubectl patch` 来更新 API 对象](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。 | 不可以。 | 可以。 | +| strategic-merge-patch | 新的端点要支持标记了 `Content-Type: application/strategic-merge-patch+json` 的 PATCH 操作。对于更新既可在本地更改也可在服务器端更改的对象而言是有用的。要了解更多信息，可参见[使用 `kubectl patch` 来更新 API 对象](/zh-cn/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。 | 不可以。 | 可以。 | | 支持协议缓冲区 | 新的资源要支持想要使用协议缓冲区（Protocol Buffer）的客户端。 | 不可以。 | 可以。 | -| OpenAPI Schema | 是否存在新资源类别的 OpenAPI（Swagger）Schema 可供动态从服务器上读取？是否存在机制确保只能设置被允许的字段以避免用户犯字段拼写错误？是否实施了字段类型检查（换言之，不允许在 `string` 字段设置 `int` 值）？ | 可以，依据 [OpenAPI v3.0 合法性检查](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) 模式（1.16 中进入正式发布状态）。 | 可以。| +| OpenAPI Schema | 是否存在新资源类别的 OpenAPI（Swagger）Schema 可供动态从服务器上读取？是否存在机制确保只能设置被允许的字段以避免用户犯字段拼写错误？是否实施了字段类型检查（换言之，不允许在 `string` 字段设置 `int` 值）？ | 可以，依据 [OpenAPI v3.0 合法性检查](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) 模式（1.16 中进入正式发布状态）。 | 可以。| ## 访问定制资源 -Kubernetes [客户端库](/zh/docs/reference/using-api/client-libraries/)可用来访问定制资源。 +Kubernetes [客户端库](/zh-cn/docs/reference/using-api/client-libraries/)可用来访问定制资源。 并非所有客户端库都支持定制资源。_Go_ 和 _Python_ 客户端库是支持的。 当你添加了新的定制资源后，可以用如下方式之一访问它们： @@ -553,6 +553,6 @@ Kubernetes [客户端库](/zh/docs/reference/using-api/client-libraries/)可用 * Learn how to [Extend the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/). * Learn how to [Extend the Kubernetes API with CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). --> -* 了解如何[使用聚合层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) -* 了解如何[使用 CustomResourceDefinition 来扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) +* 了解如何[使用聚合层扩展 Kubernetes API](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +* 了解如何[使用 CustomResourceDefinition 来扩展 Kubernetes API](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index c1f94153e0..90a4494d0f 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -67,7 +67,7 @@ to advertise that the node has 2 "Foo" devices installed and available. * 设备插件的 Unix 套接字。 * 设备插件的 API 版本。 * `ResourceName` 是需要公布的。这里 `ResourceName` 需要遵循 - [扩展资源命名方案](/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources)， + [扩展资源命名方案](/zh-cn/docs/concepts/configuration/manage-resources-containers/#extended-resources)， 类似于 `vendor-domain/resourcetype`。（比如 NVIDIA GPU 就被公布为 `nvidia.com/gpu`。） 成功注册后，设备插件就向 kubelet 发送它所管理的设备列表，然后 kubelet @@ -86,7 +86,7 @@ other resources, with the following differences: * Devices cannot be shared between containers. --> 然后，用户可以请求设备作为 Pod 规范的一部分， -参见[Container](/zh/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)。 +参见[Container](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)。 请求扩展资源类似于管理请求和限制的方式， 其他资源，有以下区别： @@ -441,7 +441,7 @@ it does (for example: hotplug/hotunplug, device health changes), client is expec However, calling `GetAllocatableResources` endpoint is not sufficient in case of cpu and/or memory update and Kubelet needs to be restarted to reflect the correct resource capacity and allocatable. --> -`GetAllocatableResources` 应该仅被用于评估一个节点上的[可分配的](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +`GetAllocatableResources` 应该仅被用于评估一个节点上的[可分配的](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) 资源。如果目标是评估空闲/未分配的资源，此调用应该与 List() 端点一起使用。 除非暴露给 kubelet 的底层资源发生变化 否则 `GetAllocatableResources` 得到的结果将保持不变。 这种情况很少发生，但当发生时（例如：热插拔，设备健康状况改变），客户端应该调用 `GetAlloctableResources` 端点。 @@ -471,7 +471,7 @@ Preceding Kubernetes v1.23, to enable this feature `kubelet` must be started wit --> 从 Kubernetes v1.23 开始，`GetAllocatableResources` 被默认启用。 你可以通过关闭 `KubeletPodResourcesGetAllocatable` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 来禁用。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 来禁用。 在 Kubernetes v1.23 之前，要启用这一功能，`kubelet` 必须用以下标志启动： @@ -484,7 +484,7 @@ plugins report [when they register themselves to the kubelet](/docs/concepts/ext --> `ContainerDevices` 会向外提供各个设备所隶属的 NUMA 单元这类拓扑信息。 NUMA 单元通过一个整数 ID 来标识，其取值与设备插件所报告的一致。 -[设备插件注册到 kubelet 时](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +[设备插件注册到 kubelet 时](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) 会报告这类信息。 -* 查看[调度 GPU 资源](/zh/docs/tasks/manage-gpus/scheduling-gpus/) 来学习使用设备插件 -* 查看在上如何[公布节点上的扩展资源](/zh/docs/tasks/administer-cluster/extended-resource-node/) -* 学习[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/) -* 阅读如何在 Kubernetes 中使用 [TLS Ingress 的硬件加速](/zh/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) +* 查看[调度 GPU 资源](/zh-cn/docs/tasks/manage-gpus/scheduling-gpus/) 来学习使用设备插件 +* 查看在上如何[公布节点上的扩展资源](/zh-cn/docs/tasks/administer-cluster/extended-resource-node/) +* 学习[拓扑管理器](/zh-cn/docs/tasks/administer-cluster/topology-manager/) +* 阅读如何在 Kubernetes 中使用 [TLS Ingress 的硬件加速](/zh-cn/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/operator.md b/content/zh-cn/docs/concepts/extend-kubernetes/operator.md index 7dd8e6fbd3..5403556037 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/operator.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/operator.md @@ -19,9 +19,9 @@ to manage applications and their components. Operators follow Kubernetes principles, notably the [control loop](/docs/concepts/architecture/controller/). --> Operator 是 Kubernetes 的扩展软件，它利用 -[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +[定制资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 管理应用及其组件。 -Operator 遵循 Kubernetes 的理念，特别是在[控制器](/zh/docs/concepts/architecture/controller/) +Operator 遵循 Kubernetes 的理念，特别是在[控制器](/zh-cn/docs/concepts/architecture/controller/) 方面。 @@ -67,7 +67,7 @@ Kubernetes 的 {{< glossary_tooltip text="Operator 模式" term_id="operator-pat Kubernetes 自身代码的情况下，通过为一个或多个自定义资源关联{{< glossary_tooltip text="控制器" term_id="controller" >}} 来扩展集群的能力。 Operator 是 Kubernetes API 的客户端，充当 -[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +[自定义资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 的控制器。 * 阅读 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} [Operator 白皮书](https://github.com/cncf/tag-app-delivery/blob/eece8f7307f2970f46f100f51932db106db46968/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md)。 -* 详细了解 [定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* 详细了解 [定制资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) * 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合你的 Operator * [发布](https://operatorhub.io/)你的 Operator，让别人也可以使用 * 阅读 [CoreOS 原始文章](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html)，它介绍了 Operator 模式（这是一个存档版本的原始文章）。 diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/service-catalog.md b/content/zh-cn/docs/concepts/extend-kubernetes/service-catalog.md index fe5437c1ba..cb4eb28e40 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/service-catalog.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/service-catalog.md @@ -66,7 +66,7 @@ It is implemented using a [CRDs-based](/docs/concepts/extend-kubernetes/api-exte 与服务代理进行通信，并作为 Kubernetes API 服务器的中介，以便协商启动部署和获取 应用程序使用托管服务时必须的凭据。 -它是[基于 CRDs](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-resources) +它是[基于 CRDs](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-resources) 架构实现的。 ![服务目录架构](/images/docs/service-catalog-architecture.svg) @@ -436,9 +436,9 @@ The following example describes how to map secret values into application enviro * Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project. --> * 如果你熟悉 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}， - 可以[使用 Helm 安装服务目录](/zh/docs/tasks/service-catalog/install-service-catalog-using-helm/) + 可以[使用 Helm 安装服务目录](/zh-cn/docs/tasks/service-catalog/install-service-catalog-using-helm/) 到 Kubernetes 集群中。或者，你可以 - [使用 SC 工具安装服务目录](/zh/docs/tasks/service-catalog/install-service-catalog-using-sc/)。 + [使用 SC 工具安装服务目录](/zh-cn/docs/tasks/service-catalog/install-service-catalog-using-sc/)。 * 查看[服务代理示例](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) * 浏览 [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 项目 diff --git a/content/zh-cn/docs/concepts/overview/components.md b/content/zh-cn/docs/concepts/overview/components.md index 902edf5cd3..e7f844aaa6 100644 --- a/content/zh-cn/docs/concepts/overview/components.md +++ b/content/zh-cn/docs/concepts/overview/components.md @@ -63,7 +63,7 @@ for an example control plane setup that runs across multiple machines. 控制平面组件可以在集群中的任何节点上运行。 然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件， 并且不会在此计算机上运行用户容器。 -请参阅[使用 kubeadm 构建高可用性集群](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/) +请参阅[使用 kubeadm 构建高可用性集群](/zh-cn/docs/setup/production-environment/tools/kubeadm/high-availability/) 中关于跨多机器控制平面设置的示例。 ### kube-apiserver @@ -177,7 +177,7 @@ Selected addons are described below; for an extended list of available addons, p see [Addons](/docs/concepts/cluster-administration/addons/). --> 下面描述众多插件中的几种。有关可用插件的完整列表，请参见 -[插件（Addons）](/zh/docs/concepts/cluster-administration/addons/)。 +[插件（Addons）](/zh-cn/docs/concepts/cluster-administration/addons/)。 ### Web 界面（仪表盘） {#web-ui-dashboard} -[Dashboard](/zh/docs/tasks/access-application-cluster/web-ui-dashboard/) +[Dashboard](/zh-cn/docs/tasks/access-application-cluster/web-ui-dashboard/) 是 Kubernetes 集群的通用的、基于 Web 的用户界面。 它使用户可以管理集群中运行的应用程序以及集群本身， 并进行故障排除。 @@ -218,7 +218,7 @@ about containers in a central database, and provides a UI for browsing that data --> ### 容器资源监控 {#container-resource-monitoring} -[容器资源监控](/zh/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) +[容器资源监控](/zh-cn/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中， 并提供浏览这些数据的界面。 @@ -230,7 +230,7 @@ saving container logs to a central log store with search/browsing interface. --> ### 集群层面日志 {#cluster-level-logging} -[集群层面日志](/zh/docs/concepts/cluster-administration/logging/) +[集群层面日志](/zh-cn/docs/concepts/cluster-administration/logging/) 机制负责将容器的日志数据保存到一个集中的日志存储中， 这种集中日志存储提供搜索和浏览接口。 @@ -242,7 +242,7 @@ saving container logs to a central log store with search/browsing interface. * Learn about [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/) * Read etcd's official [documentation](https://etcd.io/docs/) --> -* 进一步了解[节点](/zh/docs/concepts/architecture/nodes/) -* 进一步了解[控制器](/zh/docs/concepts/architecture/controller/) -* 进一步了解 [kube-scheduler](/zh/docs/concepts/scheduling-eviction/kube-scheduler/) +* 进一步了解[节点](/zh-cn/docs/concepts/architecture/nodes/) +* 进一步了解[控制器](/zh-cn/docs/concepts/architecture/controller/) +* 进一步了解 [kube-scheduler](/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler/) * 阅读 etcd 官方[文档](https://etcd.io/docs/) diff --git a/content/zh-cn/docs/concepts/overview/kubernetes-api.md b/content/zh-cn/docs/concepts/overview/kubernetes-api.md index 52b9c32b1e..ce6a1575d7 100644 --- a/content/zh-cn/docs/concepts/overview/kubernetes-api.md +++ b/content/zh-cn/docs/concepts/overview/kubernetes-api.md @@ -35,8 +35,8 @@ API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和 Kubernetes API 使你可以查询和操纵 Kubernetes API 中对象（例如：Pod、Namespace、ConfigMap 和 Event）的状态。 -大部分操作都可以通过 [kubectl](/zh/docs/reference/kubectl/) 命令行接口或 -类似 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) 这类命令行工具来执行， +大部分操作都可以通过 [kubectl](/zh-cn/docs/reference/kubectl/) 命令行接口或 +类似 [kubeadm](/zh-cn/docs/reference/setup-tools/kubeadm/) 这类命令行工具来执行， 这些工具在背后也是调用 API。不过，你也可以使用 REST 调用来访问这些 API。 如果你正在编写程序来访问 Kubernetes API，可以考虑使用 -[客户端库](/zh/docs/reference/using-api/client-libraries/)之一。 +[客户端库](/zh-cn/docs/reference/using-api/client-libraries/)之一。 @@ -157,7 +157,7 @@ for the kube-apiserver component. Kubernetes {{< param "version" >}} 提供将其 API 以 OpenAPI v3 形式发布的 beta 支持； 这一功能特性处于 beta 状态，默认被开启。 你可以通过为 kube-apiserver 组件关闭 `OpenAPIV3` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)来禁用此 beta 特性。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)来禁用此 beta 特性。 一般而言，新的 API 资源和新的资源字段可以被频繁地添加进来。 删除资源或者字段则要遵从 -[API 废弃策略](/zh/docs/reference/using-api/deprecation-policy/)。 +[API 废弃策略](/zh-cn/docs/reference/using-api/deprecation-policy/)。 关于 API 版本分级的定义细节，请参阅 -[API 版本参考](/zh/docs/reference/using-api/#api-versioning)页面。 +[API 版本参考](/zh-cn/docs/reference/using-api/#api-versioning)页面。 -1. 你可以使用[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +1. 你可以使用[自定义资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 来以声明式方式定义 API 服务器如何提供你所选择的资源 API。 1. 你也可以选择实现自己的 - [聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) + [聚合层](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 来扩展 Kubernetes API。 ## {{% heading "whatsnext" %}} @@ -323,11 +323,11 @@ The Kubernetes API can be extended in one of two ways: [API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme). --> - 了解如何通过添加你自己的 - [CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) + [CustomResourceDefinition](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) 来扩展 Kubernetes API。 -- [控制 Kubernetes API 访问](/zh/docs/concepts/security/controlling-access/)页面描述了集群如何针对 +- [控制 Kubernetes API 访问](/zh-cn/docs/concepts/security/controlling-access/)页面描述了集群如何针对 API 访问管理身份认证和鉴权。 -- 通过阅读 [API 参考](/zh/docs/reference/kubernetes-api/)了解 API 端点、资源类型以及示例。 +- 通过阅读 [API 参考](/zh-cn/docs/reference/kubernetes-api/)了解 API 端点、资源类型以及示例。 - 阅读 [API 变更（英文）](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme) 以了解什么是兼容性的变更以及如何变更 API。 diff --git a/content/zh-cn/docs/concepts/overview/what-is-kubernetes.md b/content/zh-cn/docs/concepts/overview/what-is-kubernetes.md index e26ea7c861..25feebb7fc 100644 --- a/content/zh-cn/docs/concepts/overview/what-is-kubernetes.md +++ b/content/zh-cn/docs/concepts/overview/what-is-kubernetes.md @@ -273,5 +273,5 @@ Kubernetes： * Take a look at the [Kubernetes Components](/docs/concepts/overview/components/) * Ready to [Get Started](/docs/setup/)? --> -* 查阅[Kubernetes 组件](/zh/docs/concepts/overview/components/) -* 开始[Kubernetes 的建置](/zh/docs/setup/)吧！ +* 查阅[Kubernetes 组件](/zh-cn/docs/concepts/overview/components/) +* 开始[Kubernetes 的建置](/zh-cn/docs/setup/)吧！ diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/annotations.md b/content/zh-cn/docs/concepts/overview/working-with-objects/annotations.md index 4d2ff7fc6f..c8a03e0bc6 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/annotations.md @@ -163,5 +163,5 @@ spec: -* 进一步了解[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)。 +* 进一步了解[标签和选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)。 diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/field-selectors.md b/content/zh-cn/docs/concepts/overview/working-with-objects/field-selectors.md index f5a78976da..35fc5cdda4 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/field-selectors.md @@ -11,7 +11,7 @@ weight: 60 _Field selectors_ let you [select Kubernetes resources](/docs/concepts/overview/working-with-objects/kubernetes-objects) based on the value of one or more resource fields. Here are some example field selector queries: --> “字段选择器（Field selectors）”允许你根据一个或多个资源字段的值 -[筛选 Kubernetes 资源](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects)。 +[筛选 Kubernetes 资源](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects)。 下面是一些使用字段选择器查询的例子： * `metadata.name=my-service` @@ -21,7 +21,7 @@ _Field selectors_ let you [select Kubernetes resources](/docs/concepts/overview/ -下面这个 `kubectl` 命令将筛选出 [`status.phase`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) +下面这个 `kubectl` 命令将筛选出 [`status.phase`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) 字段值为 `Running` 的所有 Pod： ```shell @@ -81,7 +81,7 @@ As with [label](/docs/concepts/overview/working-with-objects/labels) and other s --> ## 链式选择器 {#chained-selectors} -同[标签](/zh/docs/concepts/overview/working-with-objects/labels/)和其他选择器一样， +同[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)和其他选择器一样， 字段选择器可以通过使用逗号分隔的列表组成一个选择链。 下面这个 `kubectl` 命令将筛选 `status.phase` 字段不等于 `Running` 同时 `spec.restartPolicy` 字段等于 `Always` 的所有 Pod： diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/finalizers.md b/content/zh-cn/docs/concepts/overview/working-with-objects/finalizers.md index 6a0a784fcf..db6f51514f 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/finalizers.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/finalizers.md @@ -99,7 +99,7 @@ any Pods in the cluster with the same label. ## 属主引用、标签和 Finalizers {#owners-labels-finalizers} 与{{}}类似， -[属主引用](/zh/concepts/overview/working-with-objects/owners-dependents/) +[属主引用](/zh-cn/concepts/overview/working-with-objects/owners-dependents/) 描述了 Kubernetes 中对象之间的关系，但它们作用不同。 当一个{{}} 管理类似于 Pod 的对象时，它使用标签来跟踪相关对象组的变化。 diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 1cd32dc950..36c1212fcd 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -64,7 +64,7 @@ Kubernetes 对象是“目标性记录”——一旦创建对象，Kubernetes 这就是 Kubernetes 集群所谓的 **期望状态（Desired State）**。 操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用 -[Kubernetes API](/zh/docs/concepts/overview/kubernetes-api)。 +[Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api)。 比如，当使用 `kubectl` 命令行接口（CLI）时，CLI 会调用必要的 Kubernetes API； 也可以在程序中使用[客户端库](/zh-cn/docs/reference/using-api/client-libraries/)， 来直接调用 Kubernetes API。 @@ -217,7 +217,7 @@ detail the structure of that `.status` field, and its content for each different 另一个对象规约的例子是 StatefulSet API 中的 [`spec` 字段](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/#StatefulSetSpec)。 对于 StatefulSet 而言，其 `.spec` 字段设置了 StatefulSet 及其期望状态。 -在 StatefulSet 的 `.spec` 内，有一个为 Pod 对象提供的[模板](/zh/docs/concepts/workloads/pods/#pod-templates)。该模板描述了 StatefulSet 控制器为了满足 StatefulSet 规约而要创建的 Pod。 +在 StatefulSet 的 `.spec` 内，有一个为 Pod 对象提供的[模板](/zh-cn/docs/concepts/workloads/pods/#pod-templates)。该模板描述了 StatefulSet 控制器为了满足 StatefulSet 规约而要创建的 Pod。 不同类型的对象可以由不同的 `.status` 信息。API 参考页面给出了 `.status` 字段的详细结构， 以及针对不同类型 API 对象的具体内容。 @@ -228,7 +228,7 @@ detail the structure of that `.status` field, and its content for each different * Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes. * [Using the Kubernetes API](/docs/reference/using-api/) explains some more API concepts. --> -* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/zh/docs/concepts/workloads/pods/)。 -* 了解 Kubernetes 中的[控制器](/zh/docs/concepts/architecture/controller/)。 -* [使用 Kubernetes API](/zh/docs/reference/using-api/) 一节解释了一些 API 概念。 +* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/zh-cn/docs/concepts/workloads/pods/)。 +* 了解 Kubernetes 中的[控制器](/zh-cn/docs/concepts/architecture/controller/)。 +* [使用 Kubernetes API](/zh-cn/docs/reference/using-api/) 一节解释了一些 API 概念。 diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/labels.md b/content/zh-cn/docs/concepts/overview/working-with-objects/labels.md index a1840bacbd..650eb02a4e 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/labels.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/labels.md @@ -40,7 +40,7 @@ and CLIs. Non-identifying information should be recorded using [annotations](/docs/concepts/overview/working-with-objects/annotations/). --> 标签能够支持高效的查询和监听操作，对于用户界面和命令行是很理想的。 -应使用[注解](/zh/docs/concepts/overview/working-with-objects/annotations/)记录非识别信息。 +应使用[注解](/zh-cn/docs/concepts/overview/working-with-objects/annotations/)记录非识别信息。 @@ -72,7 +72,7 @@ Example labels: -有一些[常用标签](/zh/docs/concepts/overview/working-with-objects/common-labels/)的例子；你可以任意制定自己的约定。 +有一些[常用标签](/zh-cn/docs/concepts/overview/working-with-objects/common-labels/)的例子；你可以任意制定自己的约定。 请记住，标签的 Key 对于给定对象必须是唯一的。 ## 标签选择算符 {#label-selectors} -与[名称和 UID](/zh/docs/concepts/overview/working-with-objects/names/) 不同， +与[名称和 UID](/zh-cn/docs/concepts/overview/working-with-objects/names/) 不同， 标签不支持唯一性。通常，我们希望许多对象携带相同的标签。 ### 在 API 对象中设置引用 -一些 Kubernetes 对象，例如 [`services`](/zh/docs/concepts/services-networking/service/) -和 [`replicationcontrollers`](/zh/docs/concepts/workloads/controllers/replicationcontroller/) ， +一些 Kubernetes 对象，例如 [`services`](/zh-cn/docs/concepts/services-networking/service/) +和 [`replicationcontrollers`](/zh-cn/docs/concepts/workloads/controllers/replicationcontroller/) ， 也使用了标签选择算符去指定了其他资源的集合，例如 -[pods](/zh/docs/concepts/workloads/pods/)。 +[pods](/zh-cn/docs/concepts/workloads/pods/)。 #### 支持基于集合需求的资源 -比较新的资源，例如 [`Job`](/zh/docs/concepts/workloads/controllers/job/)、 -[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/)、 -[`Replica Set`](/zh/docs/concepts/workloads/controllers/replicaset/) 和 -[`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/)， +比较新的资源，例如 [`Job`](/zh-cn/docs/concepts/workloads/controllers/job/)、 +[`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/)、 +[`Replica Set`](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 和 +[`DaemonSet`](/zh-cn/docs/concepts/workloads/controllers/daemonset/)， 也支持 _基于集合的_ 需求。 ```yaml @@ -400,5 +400,5 @@ See the documentation on [node selection](/docs/concepts/configuration/assign-po #### 选择节点集 通过标签进行选择的一个用例是确定节点集，方便 Pod 调度。 -有关更多信息，请参阅[选择节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)文档。 +有关更多信息，请参阅[选择节点](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/)文档。 diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/names.md b/content/zh-cn/docs/concepts/overview/working-with-objects/names.md index e7ccb39110..91eb354810 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/names.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/names.md @@ -17,15 +17,15 @@ For example, you can only have one Pod named `myapp-1234` within the same [names 每个 Kubernetes 对象也有一个 [_UID_](#uids) 来标识在整个集群中的唯一性。 -比如，在同一个[名字空间](/zh/docs/concepts/overview/working-with-objects/namespaces/) +比如，在同一个[名字空间](/zh-cn/docs/concepts/overview/working-with-objects/namespaces/) 中有一个名为 `myapp-1234` 的 Pod，但是可以命名一个 Pod 和一个 Deployment 同为 `myapp-1234`。 对于用户提供的非唯一性的属性，Kubernetes 提供了 -[标签（Labels）](/zh/docs/concepts/working-with-objects/labels)和 -[注解（Annotation）](/zh/docs/concepts/overview/working-with-objects/annotations/)机制。 +[标签（Labels）](/zh-cn/docs/concepts/working-with-objects/labels)和 +[注解（Annotation）](/zh-cn/docs/concepts/overview/working-with-objects/annotations/)机制。 @@ -173,7 +173,7 @@ UUIDs 是标准化的，见 ISO/IEC 9834-8 和 ITU-T X.667。 * Read about [labels](/docs/concepts/overview/working-with-objects/labels/) in Kubernetes. * See the [Identifiers and Names in Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) design document. --> -* 进一步了解 Kubernetes [标签](/zh/docs/concepts/overview/working-with-objects/labels/) +* 进一步了解 Kubernetes [标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/) * 参阅 [Kubernetes 标识符和名称](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)的设计文档 diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/namespaces.md b/content/zh-cn/docs/concepts/overview/working-with-objects/namespaces.md index 62d47ad897..46c3f35ac9 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/namespaces.md @@ -49,7 +49,7 @@ resource can only be in one namespace. -名字空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/zh/docs/concepts/policy/resource-quotas/)）。 +名字空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/zh-cn/docs/concepts/policy/resource-quotas/)）。 ## 使用名字空间 -名字空间的创建和删除在[名字空间的管理指南文档](/zh/docs/tasks/administer-cluster/namespaces/)描述。 +名字空间的创建和删除在[名字空间的管理指南文档](/zh-cn/docs/tasks/administer-cluster/namespaces/)描述。 ## 名字空间和 DNS -当你创建一个[服务](/zh/docs/concepts/services-networking/service/)时， -Kubernetes 会创建一个相应的 [DNS 条目](/zh/docs/concepts/services-networking/dns-pod-service/)。 +当你创建一个[服务](/zh-cn/docs/concepts/services-networking/service/)时， +Kubernetes 会创建一个相应的 [DNS 条目](/zh-cn/docs/concepts/services-networking/dns-pod-service/)。 因此，所有的名字空间名称都必须是合法的 -[RFC 1123 DNS 标签](/zh/docs/concepts/overview/working-with-objects/names/#dns-label-names)。 +[RFC 1123 DNS 标签](/zh-cn/docs/concepts/overview/working-with-objects/names/#dns-label-names)。 {{< warning >}} 为了缓解这类问题，需要将创建名字空间的权限授予可信的用户。 如果需要，你可以额外部署第三方的安全控制机制，例如以 -[准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) +[准入 Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/) 的形式，阻止用户创建与公共 [TLD](https://data.iana.org/TLD/tlds-alpha-by-domain.txt) 同名的名字空间。 {{< /warning >}} @@ -224,7 +224,7 @@ persistentVolumes, are not in any namespace. --> 大多数 kubernetes 资源（例如 Pod、Service、副本控制器等）都位于某些名字空间中。 但是名字空间资源本身并不在名字空间中。而且底层资源，例如 -[节点](/zh/docs/concepts/architecture/nodes/)和持久化卷不属于任何名字空间。 +[节点](/zh-cn/docs/concepts/architecture/nodes/)和持久化卷不属于任何名字空间。 -* 进一步了解[建立新的名字空间](/zh/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)。 -* 进一步了解[删除名字空间](/zh/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)。 +* 进一步了解[建立新的名字空间](/zh-cn/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)。 +* 进一步了解[删除名字空间](/zh-cn/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)。 diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/object-management.md b/content/zh-cn/docs/concepts/overview/working-with-objects/object-management.md index b1dd99ca60..47c758d267 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/object-management.md @@ -325,10 +325,10 @@ Disadvantages compared to imperative object configuration: - [Kubectl Book](https://kubectl.docs.kubernetes.io) - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) --> -- [使用指令式命令管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/imperative-command/) -- [使用对象配置管理 Kubernetes 对象（指令式）](/zh/docs/tasks/manage-kubernetes-objects/imperative-config/) -- [使用对象配置管理 Kubernetes 对象（声明式）](/zh/docs/tasks/manage-kubernetes-objects/declarative-config/) -- [使用 Kustomize（声明式）管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/kustomization/) +- [使用指令式命令管理 Kubernetes 对象](/zh-cn/docs/tasks/manage-kubernetes-objects/imperative-command/) +- [使用对象配置管理 Kubernetes 对象（指令式）](/zh-cn/docs/tasks/manage-kubernetes-objects/imperative-config/) +- [使用对象配置管理 Kubernetes 对象（声明式）](/zh-cn/docs/tasks/manage-kubernetes-objects/declarative-config/) +- [使用 Kustomize（声明式）管理 Kubernetes 对象](/zh-cn/docs/tasks/manage-kubernetes-objects/kustomization/) - [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/) - [Kubectl Book](https://kubectl.docs.kubernetes.io) - [Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents.md b/content/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents.md index b7f5d0cb71..a02810877f 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents.md @@ -31,7 +31,7 @@ to the labels, each `EndpointSlice` that is managed on behalf of a Service has an owner reference. Owner references help different parts of Kubernetes avoid interfering with objects they don’t control. --> -属主关系不同于一些资源使用的[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)机制。 +属主关系不同于一些资源使用的[标签和选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)机制。 例如，有一个创建 `EndpointSlice` 对象的 Service， 该 Service 使用标签来让控制平面确定，哪些 `EndpointSlice` 对象属于该 Service。 除开标签，每个代表 Service 所管理的 `EndpointSlice` 都有一个属主引用。 @@ -132,7 +132,7 @@ bound to a Pod. ## 属主关系与 Finalizer {#ownership-and-finalizers} 当你告诉 Kubernetes 删除一个资源，API 服务器允许管理控制器处理该资源的任何 -[Finalizer 规则](/zh/docs/concepts/overview/working-with-objects/finalizers/)。 +[Finalizer 规则](/zh-cn/docs/concepts/overview/working-with-objects/finalizers/)。 {{}} 防止意外删除你的集群所依赖的、用于正常运作的资源。 例如，如果你试图删除一个仍被 Pod 使用的 `PersistentVolume`，该资源不会被立即删除， @@ -150,7 +150,7 @@ specify an orphan deletion policy, Kubernetes adds the `orphan` finalizer so that the controller ignores dependent resources after it deletes the owner object. --> -当你使用[前台或孤立级联删除](/zh/docs/concepts/architecture/garbage-collection/#cascading-deletion)时， +当你使用[前台或孤立级联删除](/zh-cn/docs/concepts/architecture/garbage-collection/#cascading-deletion)时， Kubernetes 也会向属主资源添加 Finalizer。 在前台删除中，会添加 `foreground` Finalizer，这样控制器必须在删除了拥有 `ownerReferences.blockOwnerDeletion=true` 的附属资源后，才能删除属主对象。 @@ -164,6 +164,6 @@ Kubernetes 也会向属主资源添加 Finalizer。 * Learn about [garbage collection](/docs/concepts/architecture/garbage-collection). * Read the API reference for [object metadata](/docs/reference/kubernetes-api/common-definitions/object-meta/#System). --> -* 了解更多关于 [Kubernetes Finalizer](/zh/docs/concepts/overview/working-with-objects/finalizers/)。 -* 了解关于[垃圾收集](/zh/docs/concepts/architecture/garbage-collection)。 +* 了解更多关于 [Kubernetes Finalizer](/zh-cn/docs/concepts/overview/working-with-objects/finalizers/)。 +* 了解关于[垃圾收集](/zh-cn/docs/concepts/architecture/garbage-collection)。 * 阅读[对象元数据](/docs/reference/kubernetes-api/common-definitions/object-meta/#System)的 API 参考文档。 diff --git a/content/zh-cn/docs/concepts/policy/limit-range.md b/content/zh-cn/docs/concepts/policy/limit-range.md index 8412d9e80c..da2560b6a0 100644 --- a/content/zh-cn/docs/concepts/policy/limit-range.md +++ b/content/zh-cn/docs/concepts/policy/limit-range.md @@ -11,7 +11,7 @@ By default, containers run with unbounded [compute resources](/docs/concepts/con With resource quotas, cluster administrators can restrict resource consumption and creation on a {{< glossary_tooltip text="namespace" term_id="namespace" >}} basis. Within a namespace, a Pod or Container can consume as much CPU and memory as defined by the namespace's resource quota. There is a concern that one Pod or Container could monopolize all available resources. A LimitRange is a policy to constrain resource allocations (to Pods or Containers) in a namespace. --> -默认情况下， Kubernetes 集群上的容器运行使用的[计算资源](/zh/docs/concepts/configuration/manage-resources-containers/)没有限制。 +默认情况下， Kubernetes 集群上的容器运行使用的[计算资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/)没有限制。 使用资源配额，集群管理员可以以{{< glossary_tooltip text="名字空间" term_id="namespace" >}}为单位，限制其资源的使用与创建。 在命名空间中，一个 Pod 或 Container 最多能够使用命名空间的资源配额所定义的 CPU 和内存用量。 有人担心，一个 Pod 或 Container 会垄断所有可用的资源。 @@ -53,7 +53,7 @@ The name of a LimitRange object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). --> LimitRange 的名称必须是合法的 -[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 关于使用限值的例子，可参看 -- [如何配置每个命名空间最小和最大的 CPU 约束](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。 -- [如何配置每个命名空间最小和最大的内存约束](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。 -- [如何配置每个命名空间默认的 CPU 申请值和限制值](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。 -- [如何配置每个命名空间默认的内存申请值和限制值](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。 -- [如何配置每个命名空间最小和最大存储使用量](/zh/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)。 -- [配置每个命名空间的配额的详细例子](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)。 +- [如何配置每个命名空间最小和最大的 CPU 约束](/zh-cn/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。 +- [如何配置每个命名空间最小和最大的内存约束](/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。 +- [如何配置每个命名空间默认的 CPU 申请值和限制值](/zh-cn/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。 +- [如何配置每个命名空间默认的内存申请值和限制值](/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。 +- [如何配置每个命名空间最小和最大存储使用量](/zh-cn/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)。 +- [配置每个命名空间的配额的详细例子](/zh-cn/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)。 diff --git a/content/zh-cn/docs/concepts/policy/node-resource-managers.md b/content/zh-cn/docs/concepts/policy/node-resource-managers.md index 73f28da383..5636547075 100644 --- a/content/zh-cn/docs/concepts/policy/node-resource-managers.md +++ b/content/zh-cn/docs/concepts/policy/node-resource-managers.md @@ -30,7 +30,7 @@ The main manager, the Topology Manager, is a Kubelet component that co-ordinates The configuration of individual managers is elaborated in dedicated documents: --> 主管理器，也叫拓扑管理器（Topology Manager），是一个 Kubelet 组件， -它通过[策略](/zh/docs/tasks/administer-cluster/topology-manager/)， +它通过[策略](/zh-cn/docs/tasks/administer-cluster/topology-manager/)， 协调全局的资源管理过程。 各个管理器的配置方式会在专项文档中详细阐述： @@ -40,6 +40,6 @@ The configuration of individual managers is elaborated in dedicated documents: - [Device Manager](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) - [Memory Manager Policies](/docs/tasks/administer-cluster/memory-manager/) --> -- [CPU 管理器策略](/zh/docs/tasks/administer-cluster/cpu-management-policies/) -- [设备管理器](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) -- [内存管理器策略](/zh/docs/tasks/administer-cluster/memory-manager/) +- [CPU 管理器策略](/zh-cn/docs/tasks/administer-cluster/cpu-management-policies/) +- [设备管理器](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) +- [内存管理器策略](/zh-cn/docs/tasks/administer-cluster/memory-manager/) diff --git a/content/zh-cn/docs/concepts/policy/pid-limiting.md b/content/zh-cn/docs/concepts/policy/pid-limiting.md index 85b1c531aa..61fed9674b 100644 --- a/content/zh-cn/docs/concepts/policy/pid-limiting.md +++ b/content/zh-cn/docs/concepts/policy/pid-limiting.md @@ -105,7 +105,7 @@ and limits. However, you specify it in a different way: rather than defining a Pod's resource limit in the `.spec` for a Pod, you configure the limit as a setting on the kubelet. Pod-defined PID limits are not currently supported. --> -PID 限制是与[计算资源](/zh/docs/concepts/configuration/manage-resources-containers/) +PID 限制是与[计算资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/) 请求和限制相辅相成的一种机制。不过，你需要用一种不同的方式来设置这一限制： 你需要将其设置到 kubelet 上而不是在 Pod 的 `.spec` 中为 Pod 设置资源限制。 目前还不支持在 Pod 级别设置 PID 限制。 @@ -146,7 +146,7 @@ gate](/docs/reference/command-line-tools-reference/feature-gates/) `SupportNodePidsLimit` to work. --> 在 Kubernetes 1.20 版本之前，在节点级别通过 PID 资源限制预留 PID 的能力 -需要启用[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +需要启用[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) `SupportNodePidsLimit` 才行。 {{< /note >}} @@ -166,7 +166,7 @@ Kubernetes 允许你限制 Pod 中运行的进程个数。你可以在节点级 而不是为特定的 Pod 来将其设置为资源限制。 每个节点都可以有不同的 PID 限制设置。 要设置限制值，你可以设置 kubelet 的命令行参数 `--pod-max-pids`，或者 -在 kubelet 的[配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/) +在 kubelet 的[配置文件](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/) 中设置 `PodPidsLimit`。 {{< note >}} @@ -176,7 +176,7 @@ the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SupportPodPidsLimit` to work. --> 在 Kubernetes 1.20 版本之前，为 Pod 设置 PID 资源限制的能力需要启用 -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) `SupportNodePidsLimit` 才行。 {{< /note >}} @@ -197,7 +197,7 @@ Eviction signal value is calculated periodically and does NOT enforce the limit. 你可以配置 kubelet 使之在 Pod 行为不正常或者消耗不正常数量资源的时候将其终止。 这一特性称作驱逐。你可以针对不同的驱逐信号 -[配置资源不足的处理](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 +[配置资源不足的处理](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 使用 `pid.available` 驱逐信号来配置 Pod 使用的 PID 个数的阈值。 你可以设置硬性的和软性的驱逐策略。不过，即使使用硬性的驱逐策略， 如果 PID 个数增长过快，节点仍然可能因为触及节点 PID 限制而进入一种不稳定状态。 @@ -233,6 +233,6 @@ Pod 行为不正常而没有 PID 可用。 - 关于历史背景，请阅读 [Kubernetes 1.14 中限制进程 ID 以提升稳定性](/blog/2019/04/15/process-id-limiting-for-stability-improvements-in-kubernetes-1.14/) 的博文。 -- 请阅读[为容器管理资源](/zh/docs/concepts/configuration/manage-resources-containers/)。 -- 学习如何[配置资源不足情况的处理](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 +- 请阅读[为容器管理资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/)。 +- 学习如何[配置资源不足情况的处理](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 From 5f0ec40aaad2cb909ff48b1738465d28550ddd6a Mon Sep 17 00:00:00 2001 From: howieyuen Date: Thu, 23 Jun 2022 20:18:40 +0800 Subject: [PATCH 045/209] [zh]Update concepts pages(part-3) for links with '/zh/' prefix, using new prefix '/zh-cn/' --- .../concepts/scheduling-eviction/_index.md | 20 ++++---- .../scheduling-eviction/api-eviction.md | 14 +++--- .../scheduling-eviction/assign-pod-node.md | 42 ++++++++--------- .../scheduling-eviction/kube-scheduler.md | 20 ++++---- .../node-pressure-eviction.md | 14 +++--- .../scheduling-eviction/pod-overhead.md | 10 ++-- .../pod-priority-preemption.md | 22 ++++----- .../scheduler-perf-tuning.md | 8 ++-- .../scheduling-framework.md | 4 +- .../taint-and-toleration.md | 20 ++++---- .../concepts/security/controlling-access.md | 42 ++++++++--------- .../zh-cn/docs/concepts/security/overview.md | 34 +++++++------- .../security/pod-security-admission.md | 32 ++++++------- .../concepts/security/pod-security-policy.md | 40 ++++++++-------- .../security/pod-security-standards.md | 14 +++--- .../concepts/security/rbac-good-practices.md | 22 ++++----- .../concepts/security/windows-security.md | 4 +- .../concepts/services-networking/_index.md | 2 +- .../connect-applications-service.md | 14 +++--- .../services-networking/dns-pod-service.md | 10 ++-- .../services-networking/endpoint-slices.md | 4 +- .../ingress-controllers.md | 12 ++--- .../concepts/services-networking/ingress.md | 46 +++++++++---------- .../services-networking/network-policies.md | 18 ++++---- .../services-networking/service-topology.md | 8 ++-- .../service-traffic-policy.md | 10 ++-- .../concepts/services-networking/service.md | 26 +++++------ .../topology-aware-hints.md | 6 +-- .../services-networking/windows-networking.md | 2 +- 29 files changed, 260 insertions(+), 260 deletions(-) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/_index.md b/content/zh-cn/docs/concepts/scheduling-eviction/_index.md index de33763b46..3919a6cfa0 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/_index.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/_index.md @@ -35,18 +35,18 @@ of terminating one or more Pods on Nodes. ## 调度 -* [Kubernetes 调度器](/zh/docs/concepts/scheduling-eviction/kube-scheduler/) -* [将 Pods 指派到节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/) -* [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/) -* [污点和容忍](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/) -* [调度框架](/zh/docs/concepts/scheduling-eviction/scheduling-framework) -* [调度器的性能调试](/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) -* [扩展资源的资源装箱](/zh/docs/concepts/scheduling-eviction/resource-bin-packing/) +* [Kubernetes 调度器](/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler/) +* [将 Pods 指派到节点](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/) +* [Pod 开销](/zh-cn/docs/concepts/scheduling-eviction/pod-overhead/) +* [污点和容忍](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/) +* [调度框架](/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework) +* [调度器的性能调试](/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) +* [扩展资源的资源装箱](/zh-cn/docs/concepts/scheduling-eviction/resource-bin-packing/) ## Pod 干扰 -* [Pod 优先级和抢占](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) -* [节点压力驱逐](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) -* [API发起的驱逐](/zh/docs/concepts/scheduling-eviction/api-eviction/) +* [Pod 优先级和抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* [节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* [API发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/api-eviction.md b/content/zh-cn/docs/concepts/scheduling-eviction/api-eviction.md index f51af2f678..4b9615951b 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/api-eviction.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/api-eviction.md @@ -30,12 +30,12 @@ on the Pod. 此操作创建一个 `Eviction` 对象，该对象再驱动 API 服务器终止选定的 Pod。 API 发起的驱逐将遵从你的 -[`PodDisruptionBudgets`](/zh/docs/tasks/run-application/configure-pdb/) -和 [`terminationGracePeriodSeconds`](/zh/docs/concepts/workloads/pods/pod-lifecycle#pod-termination) +[`PodDisruptionBudgets`](/zh-cn/docs/tasks/run-application/configure-pdb/) +和 [`terminationGracePeriodSeconds`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle#pod-termination) 配置。 使用 API 创建 Eviction 对象，就像对 Pod 执行策略控制的 -[`DELETE` 操作](/zh/docs/reference/kubernetes-api/workload-resources/pod-v1/#delete-delete-a-pod) +[`DELETE` 操作](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#delete-delete-a-pod) ## 调用 Eviction API -你可以使用 [Kubernetes 语言客户端](/zh/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api) +你可以使用 [Kubernetes 语言客户端](/zh-cn/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api) 来访问 Kubernetes API 并创建 `Eviction` 对象。 要执行此操作，你应该用 POST 发出要尝试的请求，类似于下面的示例： @@ -201,6 +201,6 @@ If you notice stuck evictions, try one of the following solutions: * Learn about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/). * Learn about [Pod Priority and Preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/). --> -* 了解如何使用 [Pod 干扰预算](/zh/docs/tasks/run-application/configure-pdb/) 保护你的应用。 -* 了解[节点压力引发的驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 -* 了解 [Pod 优先级和抢占](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)。 +* 了解如何使用 [Pod 干扰预算](/zh-cn/docs/tasks/run-application/configure-pdb/) 保护你的应用。 +* 了解[节点压力引发的驱逐](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 +* 了解 [Pod 优先级和抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)。 diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md index 3dcd46b8c4..c6d249d465 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -30,7 +30,7 @@ services that communicate a lot into the same availability zone. 你可以约束一个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 只能在特定的{{< glossary_tooltip text="节点" term_id="node" >}}上运行。 有几种方法可以实现这点，推荐的方法都是用 -[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)来进行选择。 +[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)来进行选择。 通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 Pod 分散到节点上， 而不是将 Pod 放置在可用资源不足的节点上等等）。但在某些情况下，你可能需要进一步控制 Pod 被部署到的节点。例如，确保 Pod 最终落在连接了 SSD 的机器上， @@ -62,10 +62,10 @@ for a list of common node labels. --> ## 节点标签 {#built-in-node-labels} -与很多其他 Kubernetes 对象类似，节点也有[标签](/zh/docs/concepts/overview/working-with-objects/labels/)。 -你可以[手动地添加标签](/zh/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node)。 +与很多其他 Kubernetes 对象类似，节点也有[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)。 +你可以[手动地添加标签](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node)。 Kubernetes 也会为集群中所有节点添加一些标准的标签。 -参见[常用的标签、注解和污点](/zh/docs/reference/labels-annotations-taints/)以了解常见的节点标签。 +参见[常用的标签、注解和污点](/zh-cn/docs/reference/labels-annotations-taints/)以了解常见的节点标签。 {{< note >}} -[`NodeRestriction` 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)防止 +[`NodeRestriction` 准入插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)防止 kubelet 使用 `node-restriction.kubernetes.io/` 前缀设置或修改标签。 要使用该标签前缀进行节点隔离： @@ -118,8 +118,8 @@ kubelet 使用 `node-restriction.kubernetes.io/` 前缀设置或修改标签。 2. Add labels with the `node-restriction.kubernetes.io/` prefix to your nodes, and use those labels in your [node selectors](#nodeselector). For example, `example.com.node-restriction.kubernetes.io/fips=true` or `example.com.node-restriction.kubernetes.io/pci-dss=true`. --> -1. 确保你在使用[节点鉴权](/zh/docs/reference/access-authn-authz/node/)机制并且已经启用了 - [NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)。 +1. 确保你在使用[节点鉴权](/zh-cn/docs/reference/access-authn-authz/node/)机制并且已经启用了 + [NodeRestriction 准入插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)。 2. 将带有 `node-restriction.kubernetes.io/` 前缀的标签添加到 Node 对象， 然后在[节点选择器](#nodeSelector)中使用这些标签。 例如，`example.com.node-restriction.kubernetes.io/fips=true` 或 @@ -142,7 +142,7 @@ Kubernetes 只会将 Pod 调度到拥有你所指定的每个标签的节点上 See [Assign Pods to Nodes](/docs/tasks/configure-pod-container/assign-pods-nodes) for more information. --> -进一步的信息可参见[将 Pod 指派给节点](/zh/docs/tasks/configure-pod-container/assign-pods-nodes)。 +进一步的信息可参见[将 Pod 指派给节点](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes)。 `NotIn` 和 `DoesNotExist` 可用来实现节点反亲和性行为。 -你也可以使用[节点污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/) +你也可以使用[节点污点](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/) 将 Pod 从特定节点上驱逐。 {{< note >}} @@ -279,7 +279,7 @@ satisfied. See [Assign Pods to Nodes using Node Affinity](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/) for more information. --> -参阅[使用节点亲和性来为 Pod 指派节点](/zh/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)， +参阅[使用节点亲和性来为 Pod 指派节点](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)， 以了解进一步的信息。 -在配置多个[调度方案](/zh/docs/reference/scheduling/config/#multiple-profiles)时， +在配置多个[调度方案](/zh-cn/docs/reference/scheduling/config/#multiple-profiles)时， 你可以将某个方案与节点亲和性关联起来，如果某个调度方案仅适用于某组特殊的节点时， 这样做是很有用的。 -要实现这点，可以在[调度器配置](/zh/docs/reference/scheduling/config/)中为 -[`NodeAffinity` 插件](/zh/docs/reference/scheduling/config/#scheduling-plugins)的 +要实现这点，可以在[调度器配置](/zh-cn/docs/reference/scheduling/config/)中为 +[`NodeAffinity` 插件](/zh-cn/docs/reference/scheduling/config/#scheduling-plugins)的 `args` 字段添加 `addedAffinity`。例如： ```yaml @@ -397,7 +397,7 @@ does not support scheduling profiles. When the DaemonSet controller creates Pods, the default Kubernetes scheduler places those Pods and honors any `nodeAffinity` rules in the DaemonSet controller. --> -DaemonSet 控制器[为 DaemonSet 创建 Pods](/zh/docs/concepts/workloads/controllers/daemonset/#scheduled-by-default-scheduler)， +DaemonSet 控制器[为 DaemonSet 创建 Pods](/zh-cn/docs/concepts/workloads/controllers/daemonset/#scheduled-by-default-scheduler)， 但该控制器不理会调度方案。 DaemonSet 控制器创建 Pod 时，默认的 Kubernetes 调度器负责放置 Pod， 并遵从 DaemonSet 控制器中奢侈的 `nodeAffinity` 规则。 @@ -434,7 +434,7 @@ Kubernetes, so Pod labels also implicitly have namespaces. Any label selectors for Pod labels should specify the namespaces in which Kubernetes should look for those labels. --> -你通过[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors) +你通过[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors) 的形式来表达规则（Y），并可根据需要指定选关联的名字空间列表。 Pod 在 Kubernetes 中是名字空间作用域的对象，因此 Pod 的标签也隐式地具有名字空间属性。 针对 Pod 标签的所有标签选择算符都要指定名字空间，Kubernetes @@ -446,7 +446,7 @@ the node label that the system uses to denote the domain. For examples, see [Well-Known Labels, Annotations and Taints](/docs/reference/labels-annotations-taints/). --> 你会通过 `topologyKey` 来表达拓扑域（X）的概念，其取值是系统用来标示域的节点标签键。 -相关示例可参见[常用标签、注解和污点](/zh/docs/reference/labels-annotations-taints/)。 +相关示例可参见[常用标签、注解和污点](/zh-cn/docs/reference/labels-annotations-taints/)。 {{< note >}} -参阅 [ZooKeeper 教程](/zh/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) +参阅 [ZooKeeper 教程](/zh-cn/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) 了解一个 StatefulSet 的示例，该 StatefulSet 配置了反亲和性以实现高可用， 所使用的是与此例相同的技术。 @@ -810,11 +810,11 @@ The above Pod will only run on the node `kube-01`. * Learn how to use [nodeSelector](/docs/tasks/configure-pod-container/assign-pods-nodes/). * Learn how to use [affinity and anti-affinity](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/). --> -* 进一步阅读[污点与容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)文档。 +* 进一步阅读[污点与容忍度](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)文档。 * 阅读[节点亲和性](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md) 和[Pod 间亲和性与反亲和性](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) 的设计文档。 -* 了解[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/)如何参与节点层面资源分配决定。 -* 了解如何使用 [nodeSelector](/zh/docs/tasks/configure-pod-container/assign-pods-nodes/)。 -* 了解如何使用[亲和性和反亲和性](/zh/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)。 +* 了解[拓扑管理器](/zh-cn/docs/tasks/administer-cluster/topology-manager/)如何参与节点层面资源分配决定。 +* 了解如何使用 [nodeSelector](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes/)。 +* 了解如何使用[亲和性和反亲和性](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)。 diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler.md index 30791e6249..067dd959fa 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -57,7 +57,7 @@ is the default scheduler for Kubernetes and runs as part of the kube-scheduler is designed so that, if you want and need to, you can write your own scheduling component and use that instead. --> -[kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) +[kube-scheduler](/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/) 是 Kubernetes 集群的默认调度器，并且是集群 {{< glossary_tooltip text="控制面" term_id="control-plane" >}} 的一部分。 如果你真的希望或者有这方面的需求，kube-scheduler 在设计上是允许 @@ -162,9 +162,9 @@ of the scheduler: `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, and others. You can also configure the kube-scheduler to run different profiles. --> -1. [调度策略](/zh/docs/reference/scheduling/policies) 允许你配置过滤的 _断言(Predicates)_ +1. [调度策略](/zh-cn/docs/reference/scheduling/policies) 允许你配置过滤的 _断言(Predicates)_ 和打分的 _优先级(Priorities)_ 。 -2. [调度配置](/zh/docs/reference/scheduling/config/#profiles) 允许你配置实现不同调度阶段的插件， +2. [调度配置](/zh-cn/docs/reference/scheduling/config/#profiles) 允许你配置实现不同调度阶段的插件， 包括：`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 等等。 你也可以配置 kube-scheduler 运行不同的配置文件。 @@ -178,10 +178,10 @@ of the scheduler: * Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/) * Learn about [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/) --> -* 阅读关于 [调度器性能调优](/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) -* 阅读关于 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/) -* 阅读关于 kube-scheduler 的 [参考文档](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) -* 阅读 [kube-scheduler 配置参考 (v1beta3)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/) -* 了解关于 [配置多个调度器](/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) 的方式 -* 了解关于 [拓扑结构管理策略](/zh/docs/tasks/administer-cluster/topology-manager/) -* 了解关于 [Pod 额外开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/) +* 阅读关于 [调度器性能调优](/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) +* 阅读关于 [Pod 拓扑分布约束](/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints/) +* 阅读关于 kube-scheduler 的 [参考文档](/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/) +* 阅读 [kube-scheduler 配置参考 (v1beta3)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/) +* 了解关于 [配置多个调度器](/zh-cn/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) 的方式 +* 了解关于 [拓扑结构管理策略](/zh-cn/docs/tasks/administer-cluster/topology-manager/) +* 了解关于 [Pod 额外开销](/zh-cn/docs/concepts/scheduling-eviction/pod-overhead/) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md b/content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md index 810324c0c2..8a0910315e 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md @@ -128,9 +128,9 @@ memory is reclaimable under pressure. --> `memory.available` 的值来自 cgroupfs，而不是像 `free -m` 这样的工具。 这很重要，因为 `free -m` 在容器中不起作用，如果用户使用 -[节点可分配资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +[节点可分配资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) 这一功能特性，资源不足的判定是基于 CGroup 层次结构中的用户 Pod 所处的局部及 CGroup 根节点作出的。 -这个[脚本](/zh/examples/admin/resource/memory-available.sh) +这个[脚本](/zh-cn/examples/admin/resource/memory-available.sh) 重现了 kubelet 为计算 `memory.available` 而执行的相同步骤。 kubelet 在其计算中排除了 inactive_file（即非活动 LRU 列表上基于文件来虚拟的内存的字节数）， 因为它假定在压力下内存是可回收的。 @@ -161,7 +161,7 @@ For a list of the deprecated features, see [kubelet garbage collection deprecati --> 一些 kubelet 垃圾收集功能已被弃用，以支持驱逐。 有关已弃用功能的列表，请参阅 -[kubelet 垃圾收集弃用](/zh/docs/concepts/cluster-administration/kubelet-garbage-collection/#deprecation)。 +[kubelet 垃圾收集弃用](/zh-cn/docs/concepts/cluster-administration/kubelet-garbage-collection/#deprecation)。 {{}} 你可以使用 `--eviction-minimum-reclaim` 标志或 -[kubelet 配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/) +[kubelet 配置文件](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/) 为每个资源配置最小回收量。 当 kubelet 注意到某个资源耗尽时，它会继续回收该资源，直到回收到你所指定的数量为止。 @@ -772,7 +772,7 @@ to estimate or measure an optimal memory limit value for that container. * Check out the [Eviction API](/docs/reference/generated/kubernetes-api/{{}}/#create-eviction-pod-v1-core) --> * 了解 [API 发起的驱逐](/docs/reference/generated/kubernetes-api/v1.23/) -* 了解 [Pod 优先级和驱逐](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* 了解 [Pod 优先级和驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) * 了解 [PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) -* 了解[服务质量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)（QoS） +* 了解[服务质量](/zh-cn/docs/tasks/configure-pod-container/quality-service-pod/)（QoS） * 查看[驱逐 API](/docs/reference/generated/kubernetes-api/{{}}/#create-eviction-pod-v1-core) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/pod-overhead.md b/content/zh-cn/docs/concepts/scheduling-eviction/pod-overhead.md index 17951dd91e..046a27cd99 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/pod-overhead.md @@ -40,8 +40,8 @@ time according to the overhead associated with the Pod's [RuntimeClass](/docs/concepts/containers/runtime-class/). --> -在 Kubernetes 中，Pod 的开销是根据与 Pod 的 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) -相关联的开销在[准入](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)时设置的。 +在 Kubernetes 中，Pod 的开销是根据与 Pod 的 [RuntimeClass](/zh-cn/docs/concepts/containers/runtime-class/) +相关联的开销在[准入](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)时设置的。 -在准入阶段 RuntimeClass [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) +在准入阶段 RuntimeClass [准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/) 更新工作负载的 PodSpec 以包含 RuntimeClass 中定义的 `overhead`。如果 PodSpec 中已定义该字段，该 Pod 将会被拒绝。 在这个例子中，由于只指定了 RuntimeClass 名称，所以准入控制器更新了 Pod，使之包含 `overhead`。 @@ -154,7 +154,7 @@ map[cpu:250m memory:120Mi] If a [ResourceQuota](/docs/concepts/policy/resource-quotas/) is defined, the sum of container requests as well as the `overhead` field are counted. --> -如果定义了 [ResourceQuata](/zh/docs/concepts/policy/resource-quotas/), +如果定义了 [ResourceQuata](/zh-cn/docs/concepts/policy/resource-quotas/), 则容器请求的总量以及 `overhead` 字段都将计算在内。 -* 学习更多关于 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 的信息 +* 学习更多关于 [RuntimeClass](/zh-cn/docs/concepts/containers/runtime-class/) 的信息 * 阅读 [PodOverhead 设计](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)增强建议以获取更多上下文 diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption.md b/content/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption.md index f22065f8f9..afa224896a 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption.md @@ -23,7 +23,7 @@ importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the scheduler tries to preempt (evict) lower priority Pods to make scheduling of the pending Pod possible. --> -[Pod](/zh/docs/concepts/workloads/pods/) 可以有 _优先级_。 +[Pod](/zh-cn/docs/concepts/workloads/pods/) 可以有 _优先级_。 优先级表示一个 Pod 相对于其他 Pod 的重要性。 如果一个 Pod 无法被调度，调度程序会尝试抢占（驱逐）较低优先级的 Pod， 以使悬决 Pod 可以被调度。 @@ -44,7 +44,7 @@ for details. 在一个并非所有用户都是可信的集群中，恶意用户可能以最高优先级创建 Pod， 导致其他 Pod 被驱逐或者无法被调度。 管理员可以使用 ResourceQuota 来阻止用户创建高优先级的 Pod。 -参见[默认限制优先级消费](/zh/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default)。 +参见[默认限制优先级消费](/zh-cn/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default)。 {{< /warning >}} @@ -82,7 +82,7 @@ These are common classes and are used to [ensure that critical components are al --> Kubernetes 已经提供了 2 个 PriorityClass： `system-cluster-critical` 和 `system-node-critical`。 -这些是常见的类，用于[确保始终优先调度关键组件](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)。 +这些是常见的类，用于[确保始终优先调度关键组件](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)。 {{< /note >}} #### 支持 PodDisruptionBudget，但不保证 -[PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/) +[PodDisruptionBudget](/zh-cn/docs/concepts/workloads/pods/disruptions/) (PDB) 允许多副本应用程序的所有者限制因自愿性质的干扰而同时终止的 Pod 数量。 Kubernetes 在抢占 Pod 时支持 PDB，但对 PDB 的支持是基于尽力而为原则的。 调度器会尝试寻找不会因被抢占而违反 PDB 的牺牲者，但如果没有找到这样的牺牲者， @@ -639,7 +639,7 @@ exceeding its requests, it won't be evicted. Another Pod with higher priority that exceeds its requests may be evicted. --> kubelet 使用优先级来确定 -[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) Pod 的顺序。 +[节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) Pod 的顺序。 你可以使用 QoS 类来估计 Pod 最有可能被驱逐的顺序。kubelet 根据以下因素对 Pod 进行驱逐排名： 1. 对紧俏资源的使用是否超过请求值 @@ -647,7 +647,7 @@ kubelet 使用优先级来确定 1. 相对于请求的资源使用量 有关更多详细信息，请参阅 -[kubelet 驱逐时 Pod 的选择](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction)。 +[kubelet 驱逐时 Pod 的选择](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction)。 当某 Pod 的资源用量未超过其请求时，kubelet 节点压力驱逐不会驱逐该 Pod。 如果优先级较低的 Pod 没有超过其请求，则不会被驱逐。 @@ -663,7 +663,7 @@ kubelet 使用优先级来确定 * Learn about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) --> * 阅读有关将 ResourceQuota 与 PriorityClass 结合使用的信息： - [默认限制优先级消费](/zh/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default) -* 了解 [Pod 干扰](/zh/docs/concepts/workloads/pods/disruptions/) + [默认限制优先级消费](/zh-cn/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default) +* 了解 [Pod 干扰](/zh-cn/docs/concepts/workloads/pods/disruptions/) * 了解 [API 发起的驱逐](/docs/reference/generated/kubernetes-api/v1.23/) -* 了解[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* 了解[节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index dd6e1da395..6ceffe8461 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -23,7 +23,7 @@ is the Kubernetes default scheduler. It is responsible for placement of Pods on Nodes in a cluster. --> 作为 kubernetes 集群的默认调度器， -[kube-scheduler](/zh/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler) +[kube-scheduler](/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler) 主要负责将 Pod 调度到集群的 Node 上。 -要修改这个值，先编辑 [kube-scheduler 的配置文件](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/) +要修改这个值，先编辑 [kube-scheduler 的配置文件](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/) 然后重启调度器。 大多数情况下，这个配置文件是 `/etc/kubernetes/config/kube-scheduler.yaml`。 @@ -128,7 +128,7 @@ stops searching for more feasible nodes and moves on to the kube-scheduler 会将它转换为节点数的整数值。在调度期间，如果 kube-scheduler 已确认的可调度节点数足以超过了配置的百分比数量， kube-scheduler 将停止继续查找可调度节点并继续进行 -[打分阶段](/zh/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)。 +[打分阶段](/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)。 -* 参见 [kube-scheduler 配置参考 (v1beta3)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/) +* 参见 [kube-scheduler 配置参考 (v1beta3)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md index 9e0fee45ac..80cefde2e1 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md @@ -451,7 +451,7 @@ enabled by default. --> 你可以在调度器配置中启用或禁用插件。 如果你在使用 Kubernetes v1.18 或更高版本，大部分调度 -[插件](/zh/docs/reference/scheduling/config/#scheduling-plugins) +[插件](/zh-cn/docs/reference/scheduling/config/#scheduling-plugins) 都在使用中且默认启用。 如果你正在使用 Kubernetes v1.18 或更高版本，你可以将一组插件设置为 一个调度器配置文件，然后定义不同的配置文件来满足各类工作负载。 -了解更多关于[多配置文件](/zh/docs/reference/scheduling/config/#multiple-profiles)。 +了解更多关于[多配置文件](/zh-cn/docs/reference/scheduling/config/#multiple-profiles)。 diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration.md index 1e02d72fdd..39ad284a00 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -11,7 +11,7 @@ is a property of {{< glossary_tooltip text="Pods" term_id="pod" >}} that *attrac a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (either as a preference or a hard requirement). _Taints_ are the opposite -- they allow a node to repel a set of pods. --> -[_节点亲和性_](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) +[_节点亲和性_](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) 是 {{< glossary_tooltip text="Pod" term_id="pod" >}} 的一种属性，它使 Pod 被吸引到一类特定的{{< glossary_tooltip text="节点" term_id="node" >}} （这可能出于一种偏好，也可能是硬性要求）。 @@ -270,7 +270,7 @@ onto nodes labeled with `dedicated=groupName`. * **专用节点**：如果你想将某些节点专门分配给特定的一组用户使用，你可以给这些节点添加一个污点（即， `kubectl taint nodes nodename dedicated=groupName:NoSchedule`）， 然后给这组用户的 Pod 添加一个相对应的 toleration（通过编写一个自定义的 - [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)，很容易就能做到）。 + [准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)，很容易就能做到）。 拥有上述容忍度的 Pod 就能够被分配到上述专用节点，同时也能够被分配到集群中的其它节点。 如果你希望这些 Pod 只能被分配到上述专用节点，那么你还需要给这些专用节点另外添加一个和上述 污点类似的 label （例如：`dedicated=groupName`），同时 还要在上述准入控制器中给 Pod @@ -306,10 +306,10 @@ manually add tolerations to your pods. `kubectl taint nodes nodename special=true:PreferNoSchedule`)， 然后给使用了这类特殊硬件的 Pod 添加一个相匹配的 toleration。 和专用节点的例子类似，添加这个容忍度的最简单的方法是使用自定义 - [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)。 - 比如，我们推荐使用[扩展资源](/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources) + [准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)。 + 比如，我们推荐使用[扩展资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/#extended-resources) 来表示特殊硬件，给配置了特殊硬件的节点添加污点时包含扩展资源名称， - 然后运行一个 [ExtendedResourceToleration](/zh/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) + 然后运行一个 [ExtendedResourceToleration](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) 准入控制器。此时，因为节点已经被设置污点了，没有对应容忍度的 Pod 不会被调度到这些节点。但当你创建一个使用了扩展资源的 Pod 时， `ExtendedResourceToleration` 准入控制器会自动给 Pod 加上正确的容忍度， @@ -395,7 +395,7 @@ as the master becoming partitioned from the nodes. --> {{< note >}} 为了保证由于节点问题引起的 Pod 驱逐 -[速率限制](/zh/docs/concepts/architecture/nodes/)行为正常， +[速率限制](/zh-cn/docs/concepts/architecture/nodes/)行为正常， 系统实际上会以限定速率的方式添加污点。在像主控节点与工作节点间通信中断等场景下， 这样做可以避免 Pod 被大量驱逐。 {{< /note >}} @@ -461,7 +461,7 @@ Nodes for 5 minutes after one of these problems is detected. This ensures that DaemonSet pods are never evicted due to these problems. --> -[DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/) 中的 Pod 被创建时， +[DaemonSet](/zh-cn/docs/concepts/workloads/controllers/daemonset/) 中的 Pod 被创建时， 针对以下污点自动添加的 `NoExecute` 的容忍度将不会指定 `tolerationSeconds`： * `node.kubernetes.io/unreachable` @@ -487,7 +487,7 @@ control plane adds the `node.kubernetes.io/memory-pressure` taint. --> 控制平面使用节点{{}}自动创建 -与[节点状况](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)对应的带有 `NoSchedule` 效应的污点。 +与[节点状况](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)对应的带有 `NoSchedule` 效应的污点。 调度器在进行调度时检查污点，而不是检查节点状况。这确保节点状况不会直接影响调度。 例如，如果 `DiskPressure` 节点状况处于活跃状态，则控制平面 @@ -544,5 +544,5 @@ arbitrary tolerations to DaemonSets. * Read about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) and how you can configure it * Read about [Pod Priority](/docs/concepts/scheduling-eviction/pod-priority-preemption/) --> -* 阅读[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)，以及如何配置其行为 -* 阅读 [Pod 优先级](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* 阅读[节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)，以及如何配置其行为 +* 阅读 [Pod 优先级](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) diff --git a/content/zh-cn/docs/concepts/security/controlling-access.md b/content/zh-cn/docs/concepts/security/controlling-access.md index 5946a002b6..5de2cb3e59 100644 --- a/content/zh-cn/docs/concepts/security/controlling-access.md +++ b/content/zh-cn/docs/concepts/security/controlling-access.md @@ -28,8 +28,8 @@ authorized for API access. When a request reaches the API, it goes through several stages, illustrated in the following diagram: --> -用户使用 `kubectl`、客户端库或构造 REST 请求来访问 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/)。 -人类用户和 [Kubernetes 服务账户](/zh/docs/tasks/configure-pod-container/configure-service-account/)都可以被鉴权访问 API。 +用户使用 `kubectl`、客户端库或构造 REST 请求来访问 [Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api/)。 +人类用户和 [Kubernetes 服务账户](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/)都可以被鉴权访问 API。 当请求到达 API 时，它会经历多个阶段，如下图所示： ![Kubernetes API 请求处理步骤示意图](/images/docs/admin/access-control-overview.svg) @@ -72,7 +72,7 @@ Authenticators are described in more detail in --> 如上图步骤 **1** 所示，建立 TLS 后， HTTP 请求将进入认证（Authentication）步骤。 集群创建脚本或者集群管理员配置 API 服务器，使之运行一个或多个身份认证组件。 -身份认证组件在[认证](/zh/docs/reference/access-authn-authz/authentication/)节中有更详细的描述。 +身份认证组件在[认证](/zh-cn/docs/reference/access-authn-authz/authentication/)节中有更详细的描述。 ## 准入控制 {#admission-control} @@ -223,7 +223,7 @@ for the corresponding API object, and then written to the object store (shown as 除了拒绝对象之外，准入控制器还可以为字段设置复杂的默认值。 -可用的准入控制模块在[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)中进行了描述。 +可用的准入控制模块在[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)中进行了描述。 请求通过所有准入控制器后，将使用检验例程检查对应的 API 对象，然后将其写入对象存储（如步骤 **4** 所示）。 @@ -241,7 +241,7 @@ For more information, see [Auditing](/docs/tasks/debug/debug-cluster/audit/). Kubernetes 审计提供了一套与安全相关的、按时间顺序排列的记录，其中记录了集群中的操作序列。 集群对用户、使用 Kubernetes API 的应用程序以及控制平面本身产生的活动进行审计。 -更多信息请参考 [审计](/zh/docs/tasks/debug/debug-cluster/audit/). +更多信息请参考 [审计](/zh-cn/docs/tasks/debug/debug-cluster/audit/). ## API 服务器端口和 IP {#api-server-ports-and-ips} @@ -327,23 +327,23 @@ You can learn about: --> 阅读更多有关身份认证、鉴权和 API 访问控制的文档： -- [认证](/zh/docs/reference/access-authn-authz/authentication/) - - [使用 Bootstrap 令牌进行身份认证](/zh/docs/reference/access-authn-authz/bootstrap-tokens/) -- [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) - - [动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) -- [鉴权](/zh/docs/reference/access-authn-authz/authorization/) - - [基于角色的访问控制](/zh/docs/reference/access-authn-authz/rbac/) - - [基于属性的访问控制](/zh/docs/reference/access-authn-authz/abac/) - - [节点鉴权](/zh/docs/reference/access-authn-authz/node/) - - [Webhook 鉴权](/zh/docs/reference/access-authn-authz/webhook/) -- [证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/) - - 包括 [CSR 认证](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) - 和[证书签名](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#signing) +- [认证](/zh-cn/docs/reference/access-authn-authz/authentication/) + - [使用 Bootstrap 令牌进行身份认证](/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens/) +- [准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/) + - [动态准入控制](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/) +- [鉴权](/zh-cn/docs/reference/access-authn-authz/authorization/) + - [基于角色的访问控制](/zh-cn/docs/reference/access-authn-authz/rbac/) + - [基于属性的访问控制](/zh-cn/docs/reference/access-authn-authz/abac/) + - [节点鉴权](/zh-cn/docs/reference/access-authn-authz/node/) + - [Webhook 鉴权](/zh-cn/docs/reference/access-authn-authz/webhook/) +- [证书签名请求](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/) + - 包括 [CSR 认证](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) + 和[证书签名](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/#signing) - 服务账户 - - [开发者指导](/zh/docs/tasks/configure-pod-container/configure-service-account/) - - [管理](/zh/docs/reference/access-authn-authz/service-accounts-admin/) + - [开发者指导](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/) + - [管理](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/) 你可以了解 - Pod 如何使用 - [Secrets](/zh/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials) + [Secrets](/zh-cn/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials) 获取 API 凭证. diff --git a/content/zh-cn/docs/concepts/security/overview.md b/content/zh-cn/docs/concepts/security/overview.md index 9a9e9845a7..165c339de1 100644 --- a/content/zh-cn/docs/concepts/security/overview.md +++ b/content/zh-cn/docs/concepts/security/overview.md @@ -165,7 +165,7 @@ good information practices, read and follow the advice about --> ### 集群组件 {#cluster-components} -如果想要保护集群免受意外或恶意的访问，采取良好的信息管理实践，请阅读并遵循有关[保护集群](/zh/docs/tasks/administer-cluster/securing-a-cluster/)的建议。 +如果想要保护集群免受意外或恶意的访问，采取良好的信息管理实践，请阅读并遵循有关[保护集群](/zh-cn/docs/tasks/administer-cluster/securing-a-cluster/)的建议。 学习了解相关的 Kubernetes 安全主题： -* [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/) -* [Pod 的网络策略](/zh/docs/concepts/services-networking/network-policies/) -* [控制对 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/) -* [保护你的集群](/zh/docs/tasks/administer-cluster/securing-a-cluster/) -* 为控制面[加密通信中的数据](/zh/docs/tasks/tls/managing-tls-in-a-cluster/) -* [加密静止状态的数据](/zh/docs/tasks/administer-cluster/encrypt-data/) -* [Kubernetes 中的 Secret](/zh/docs/concepts/configuration/secret/) -* [运行时类](/zh/docs/concepts/containers/runtime-class) +* [Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/) +* [Pod 的网络策略](/zh-cn/docs/concepts/services-networking/network-policies/) +* [控制对 Kubernetes API 的访问](/zh-cn/docs/concepts/security/controlling-access/) +* [保护你的集群](/zh-cn/docs/tasks/administer-cluster/securing-a-cluster/) +* 为控制面[加密通信中的数据](/zh-cn/docs/tasks/tls/managing-tls-in-a-cluster/) +* [加密静止状态的数据](/zh-cn/docs/tasks/administer-cluster/encrypt-data/) +* [Kubernetes 中的 Secret](/zh-cn/docs/concepts/configuration/secret/) +* [运行时类](/zh-cn/docs/concepts/containers/runtime-class) diff --git a/content/zh-cn/docs/concepts/security/pod-security-admission.md b/content/zh-cn/docs/concepts/security/pod-security-admission.md index b5097a995e..6e04de352d 100644 --- a/content/zh-cn/docs/concepts/security/pod-security-admission.md +++ b/content/zh-cn/docs/concepts/security/pod-security-admission.md @@ -29,7 +29,7 @@ The Kubernetes [Pod Security Standards](/docs/concepts/security/pod-security-sta different isolation levels for Pods. These standards let you define how you want to restrict the behavior of pods in a clear, consistent fashion. --> -Kubernetes [Pod 安全性标准（Security Standards）](/zh/docs/concepts/security/pod-security-standards/) +Kubernetes [Pod 安全性标准（Security Standards）](/zh-cn/docs/concepts/security/pod-security-standards/) 为 Pod 定义不同的隔离级别。这些标准能够让你以一种清晰、一致的方式定义如何限制 Pod 行为。 作为一项 Beta 功能特性，Kubernetes 提供一种内置的 _Pod 安全性_ {{< glossary_tooltip text="准入控制器" term_id="admission-controller" >}}， -作为 [PodSecurityPolicies](/zh/docs/concepts/security/pod-security-policy/) +作为 [PodSecurityPolicies](/zh-cn/docs/concepts/security/pod-security-policy/) 特性的后继演化版本。Pod 安全性限制是在 Pod 被创建时在 {{< glossary_tooltip text="名字空间" term_id="namespace" >}}层面实施的。 @@ -51,7 +51,7 @@ The PodSecurityPolicy API is deprecated and will be [removed](/docs/reference/using-api/deprecation-guide/#v1-25) from Kubernetes in v1.25. --> PodSecurityPolicy API 已经被废弃，会在 Kubernetes v1.25 发行版中 -[移除](/zh/docs/reference/using-api/deprecation-guide/#v1-25)。 +[移除](/zh-cn/docs/reference/using-api/deprecation-guide/#v1-25)。 {{< /note >}} @@ -75,7 +75,7 @@ is a beta feature and is enabled by default. You must have this feature gate ena If you are running a different version of Kubernetes, consult the documentation for that release. --> 在 Kubernetes v{{< skew currentVersion >}} 中，`PodSecurity` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)是一项 Beta 特性， +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)是一项 Beta 特性， 默认被启用。你必须启用此功能门控。如果你运行的是不同版本的 Kubernetes，请查阅该版本的文档。 @@ -132,11 +132,11 @@ Standards](/docs/concepts/security/pod-security-standards): `privileged`, `basel `restricted`. Refer to the [Pod Security Standards](/docs/concepts/security/pod-security-standards) page for an in-depth look at those requirements. --> -Pod 安全性准入插件对 Pod 的[安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/) -有一定的要求，并且依据 [Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards) +Pod 安全性准入插件对 Pod 的[安全性上下文](/zh-cn/docs/tasks/configure-pod-container/security-context/) +有一定的要求，并且依据 [Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards) 所定义的三个级别（`privileged`、`baseline` 和 `restricted`）对其他字段也有要求。 关于这些需求的更进一步讨论，请参阅 -[Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards/)页面。 +[Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards/)页面。 关于用法示例，可参阅 -[使用名字空间标签来强制实施 Pod 安全标准](/zh/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/)。 +[使用名字空间标签来强制实施 Pod 安全标准](/zh-cn/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/)。 -- [Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards/) -- [强制实施 Pod 安全性标准](/zh/docs/setup/best-practices/enforcing-pod-security-standards/) -- [通过配置内置的准入控制器强制实施 Pod 安全性标准](/zh/docs/tasks/configure-pod-container/enforce-standards-admission-controller/) -- [使用名字空间标签来实施 Pod 安全性标准](/zh/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/) -- [从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh/docs/tasks/configure-pod-container/migrate-from-psp/) +- [Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards/) +- [强制实施 Pod 安全性标准](/zh-cn/docs/setup/best-practices/enforcing-pod-security-standards/) +- [通过配置内置的准入控制器强制实施 Pod 安全性标准](/zh-cn/docs/tasks/configure-pod-container/enforce-standards-admission-controller/) +- [使用名字空间标签来实施 Pod 安全性标准](/zh-cn/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/) +- [从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh-cn/docs/tasks/configure-pod-container/migrate-from-psp/) diff --git a/content/zh-cn/docs/concepts/security/pod-security-policy.md b/content/zh-cn/docs/concepts/security/pod-security-policy.md index 6bb83482f6..d68df8050c 100644 --- a/content/zh-cn/docs/concepts/security/pod-security-policy.md +++ b/content/zh-cn/docs/concepts/security/pod-security-policy.md @@ -24,9 +24,9 @@ For more information on the deprecation, see [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). --> PodSecurityPolicy 在 Kubernetes v1.21 版本中被弃用，**将在 v1.25 中删除**。 -我们建议迁移到 [Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission)， +我们建议迁移到 [Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission)， 或者第三方的准入插件。 -若需了解迁移指南，可参阅[从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh/docs/tasks/configure-pod-container/migrate-from-psp/)。 +若需了解迁移指南，可参阅[从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh-cn/docs/tasks/configure-pod-container/migrate-from-psp/)。 关于弃用的更多信息，请查阅 [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)。 {{< /caution >}} @@ -107,8 +107,8 @@ cluster. --> ## 启用 Pod 安全策略 {#enabling-pod-security-policies} -Pod 安全策略实现为一种可选的[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)。 -[启用了准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)即可强制实施 +Pod 安全策略实现为一种可选的[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)。 +[启用了准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)即可强制实施 Pod 安全策略，不过如果没有授权认可策略之前即启用准入控制器 **将导致集群中无法创建任何 Pod**。 大多数 Kubernetes Pod 不是由用户直接创建的。相反，这些 Pod 是由 -[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)、 -[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) +[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)、 +[ReplicaSet](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 或者经由控制器管理器模版化的控制器创建。 赋予控制器访问策略的权限意味着对应控制器所创建的 *所有* Pod 都可访问策略。 因此，对策略进行授权的优先方案是为 Pod 的服务账号授予访问权限 @@ -164,7 +164,7 @@ policies. The rules to grant access look like this: --> ### 通过 RBAC 授权 {#via-rbac} -[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 是一种标准的 Kubernetes +[RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 是一种标准的 Kubernetes 鉴权模式，可以很容易地用来授权策略访问。 首先，某 `Role` 或 `ClusterRole` 需要获得使用 `use` 访问目标策略的权限。 @@ -272,7 +272,7 @@ For more examples of RBAC bindings, see [Role Binding Examples](/docs/reference/access-authn-authz/rbac#role-binding-examples). For a complete example of authorizing a PodSecurityPolicy, see [below](#example). --> -参阅[角色绑定示例](/zh/docs/reference/access-authn-authz/rbac#role-binding-examples)查看 +参阅[角色绑定示例](/zh-cn/docs/reference/access-authn-authz/rbac#role-binding-examples)查看 RBAC 绑定的更多实例。 参阅[下文](#example)，查看对 PodSecurityPolicy 进行授权的完整示例。 @@ -303,7 +303,7 @@ PodSecurityPolicy 正在被一个新的、简化的 `PodSecurity` - {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}} --> 1. 将 PodSecurityPolicies 限制为 - [Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards)所定义的策略： + [Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards)所定义的策略： - {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}} - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}} @@ -371,9 +371,9 @@ PodSecurityPolicy 正在被一个新的、简化的 `PodSecurity` --> ### 故障排查 {#troubleshooting} -- [控制器管理器组件](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) +- [控制器管理器组件](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/) 必须运行在安全的 API 端口之上，并且不能拥有超级用户的访问权限。 - 参阅[控制 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access)以了解 + 参阅[控制 Kubernetes API 的访问](/zh-cn/docs/concepts/security/controlling-access)以了解 API 服务器的访问控制。 如果控制器管理器通过可信的 API 端口连接（也称作 `localhost` 监听组件）， @@ -381,7 +381,7 @@ PodSecurityPolicy 正在被一个新的、简化的 `PodSecurity` 用户亦能授予自身创建特权容器的特权。 关于配置控制器管理器鉴权的进一步细节， - 请参阅[控制器角色](/zh/docs/reference/access-authn-authz/rbac/#controller-roles)。 + 请参阅[控制器角色](/zh-cn/docs/reference/access-authn-authz/rbac/#controller-roles)。 更多的示例可参考 -[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/#policy-instantiation)。 +[Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/#policy-instantiation)。 -参阅 [Sysctl 文档](/zh/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)。 +参阅 [Sysctl 文档](/zh-cn/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)。 ## {{% heading "whatsnext" %}} @@ -1353,7 +1353,7 @@ Refer to the [Sysctl documentation](/docs/tasks/administer-cluster/sysctl-cluste Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)， 了解 Pod 安全策略的未来。 -- 参阅[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)， +- 参阅[Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/)， 了解策略建议。 - 阅读 [Pod 安全策略参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)， 了解 API 细节。 diff --git a/content/zh-cn/docs/concepts/security/pod-security-standards.md b/content/zh-cn/docs/concepts/security/pod-security-standards.md index 4bd324ceb0..1aafe77bf2 100644 --- a/content/zh-cn/docs/concepts/security/pod-security-standards.md +++ b/content/zh-cn/docs/concepts/security/pod-security-standards.md @@ -117,7 +117,7 @@ fail validation. -->

Windows Pod 提供了运行 - HostProcess 容器 的能力， + HostProcess 容器 的能力， 这使得对 Windows 节点的特权访问成为可能。 基线策略中对宿主的特权访问是被禁止的。 HostProcess Pod 是 Kubernetes v1.22 版本的 @@ -833,13 +833,13 @@ of individual policies are not defined here. 随着相关机制的成熟，这些机制会按策略分别定义在下面。特定策略的实施方法不在这里定义。 -[**Pod 安全性准入控制器**](/zh/docs/concepts/security/pod-security-admission/) +[**Pod 安全性准入控制器**](/zh-cn/docs/concepts/security/pod-security-admission/) - {{< example file="security/podsecurity-privileged.yaml" >}}Privileged 名字空间{{< /example >}} - {{< example file="security/podsecurity-baseline.yaml" >}}Baseline 名字空间{{< /example >}} - {{< example file="security/podsecurity-restricted.yaml" >}}Restricted 名字空间{{< /example >}} -[**PodSecurityPolicy**](/zh/docs/concepts/security/pod-security-policy/) （已弃用） +[**PodSecurityPolicy**](/zh-cn/docs/concepts/security/pod-security-policy/) （已弃用） - {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}} - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}} @@ -896,7 +896,7 @@ in the Pod manifest, and represent parameters to the container runtime. --> ### 安全策略与安全上下文的区别是什么？ -[安全上下文](/zh/docs/tasks/configure-pod-container/security-context/)在运行时配置 Pod +[安全上下文](/zh-cn/docs/tasks/configure-pod-container/security-context/)在运行时配置 Pod 和容器。安全上下文是在 Pod 清单中作为 Pod 和容器规约的一部分来定义的， 所代表的是传递给容器运行时的参数。 @@ -908,8 +908,8 @@ built-in [Pod Security Admission Controller](/docs/concepts/security/pod-securit --> 安全策略则是控制面用来对安全上下文以及安全性上下文之外的参数实施某种设置的机制。 在 2020 年 7 月， -[Pod 安全性策略](/zh/docs/concepts/security/pod-security-policy/)已被废弃， -取而代之的是内置的 [Pod 安全性准入控制器](/zh/docs/concepts/security/pod-security-admission/)。 +[Pod 安全性策略](/zh-cn/docs/concepts/security/pod-security-policy/)已被废弃， +取而代之的是内置的 [Pod 安全性准入控制器](/zh-cn/docs/concepts/security/pod-security-admission/)。 @@ -74,7 +74,7 @@ some general rules that can be applied are : 由于 Kubernetes 是一个可扩展的系统，因此通过通配符来授予访问权限不仅会授予集群中当前的所有对象类型， 还包含所有未来被创建的所有对象类型。 - 管理员不应使用 `cluster-admin` 账号，除非特别需要。为低特权帐户提供 - [伪装权限](/zh/docs/reference/access-authn-authz/authentication/#user-impersonation) + [伪装权限](/zh-cn/docs/reference/access-authn-authz/authentication/#user-impersonation) 可以避免意外修改集群资源。 - 避免将用户添加到 `system:masters` 组。任何属于此组成员的用户都会绕过所有 RBAC 权限检查， 始终具有不受限制的超级用户访问权限，并且不能通过删除 `RoleBinding` 或 `ClusterRoleBinding` @@ -102,9 +102,9 @@ In cases where a workload requires powerful permissions, consider the following - 限制运行此类 Pod 的节点数量。确保你运行的任何 DaemonSet 都是必需的， 并且以最小权限运行，以限制容器逃逸的影响范围。 - 避免将此类 Pod 与不可信任或公开的 Pod 在一起运行。 - 考虑使用[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)、 - [节点亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)或 - [Pod 反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)确保 + 考虑使用[污点和容忍度](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)、 + [节点亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)或 + [Pod 反亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)确保 Pod 不会与不可信或不太受信任的 Pod 一起运行。 特别注意可信度不高的 Pod 不符合 **Restricted** Pod 安全标准的情况。 ### 工作负载的创建 {#workload-creation} -能够创建工作负载的用户（Pod 或管理 Pod 的[工作负载资源](/zh/docs/concepts/workloads/controllers/)） +能够创建工作负载的用户（Pod 或管理 Pod 的[工作负载资源](/zh-cn/docs/concepts/workloads/controllers/)） 能够访问下层的节点，除非基于 Kubernetes 的 -[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)做限制。 +[Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/)做限制。 -可以为 Windows Pod 或容器指定 [RunAsUsername](/zh/docs/tasks/configure-pod-container/configure-runasusername) +可以为 Windows Pod 或容器指定 [RunAsUsername](/zh-cn/docs/tasks/configure-pod-container/configure-runasusername) 以作为特定用户执行容器进程。这大致相当于 [RunAsUser](/zh-cn/docs/concepts/security/pod-security-policy/#users-and-groups)。 -Windows 容器还可以通过使用[组管理的服务账号](/zh/docs/tasks/configure-pod-container/configure-gmsa/)作为 +Windows 容器还可以通过使用[组管理的服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-gmsa/)作为 Active Directory 身份运行。 -* 进一步了解如何[使用 Service 访问集群中的应用](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/) -* 进一步了解如何[使用 Service 将前端连接到后端](/zh/docs/tasks/access-application-cluster/connecting-frontend-backend/) -* 进一步了解如何[创建外部负载均衡器](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/) +* 进一步了解如何[使用 Service 访问集群中的应用](/zh-cn/docs/tasks/access-application-cluster/service-access-application-cluster/) +* 进一步了解如何[使用 Service 将前端连接到后端](/zh-cn/docs/tasks/access-application-cluster/connecting-frontend-backend/) +* 进一步了解如何[创建外部负载均衡器](/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer/) diff --git a/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md b/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md index 2bee2ba425..9946a88eb3 100644 --- a/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md +++ b/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md @@ -168,7 +168,7 @@ of the form `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example` #### SRV 记录 {#srv-records} Kubernetes 根据普通 Service 或 -[Headless Service](/zh/docs/concepts/services-networking/service/#headless-services) +[Headless Service](/zh-cn/docs/concepts/services-networking/service/#headless-services) 中的命名端口创建 SRV 记录。每个命名端口， SRV 记录格式为 `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`。 普通 Service，该记录会被解析成端口号和域名：`my-svc.my-namespace.svc.cluster-domain.example`。 @@ -370,7 +370,7 @@ Pod 会一直出于 `Pending` 状态（通过 `kubectl` 所看到的 `ContainerC （无法基于 Pod 主机名和集群域名构造 FQDN，FQDN `long-FQDN` 过长，至多 64 字符，请求字符数为 70）。 对于这种场景而言，改善用户体验的一种方式是创建一个 -[准入 Webhook 控制器](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)， +[准入 Webhook 控制器](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)， 在用户创建顶层对象（如 Deployment）的时候控制 FQDN 的长度。 {{< /note >}} @@ -405,11 +405,11 @@ DNS 策略可以逐个 Pod 来设定。目前 Kubernetes 支持以下特定 Pod 这些策略可以在 Pod 规约中的 `dnsPolicy` 字段设置： - "`Default`": Pod 从运行所在的节点继承名称解析配置。参考 - [相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers) + [相关讨论](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers) 获取更多信息。 - "`ClusterFirst`": 与配置的集群域后缀不匹配的任何 DNS 查询（例如 "www.kubernetes.io"） 都将转发到从节点继承的上游名称服务器。集群管理员可能配置了额外的存根域和上游 DNS 服务器。 - 参阅[相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers) + 参阅[相关讨论](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers) 了解在这些场景中如何处理 DNS 查询的信息。 - "`ClusterFirstWithHostNet`"：对于以 hostNetwork 方式运行的 Pod，应显式设置其 DNS 策略 "`ClusterFirstWithHostNet`"。 @@ -609,5 +609,5 @@ For guidance on administering DNS configurations, check [Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/) --> 有关管理 DNS 配置的指导，请查看 -[配置 DNS 服务](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/) +[配置 DNS 服务](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers/) diff --git a/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md b/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md index 05f808a1a9..b3f0949298 100644 --- a/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md +++ b/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md @@ -82,7 +82,7 @@ Kubernetes Service. 这些 EndpointSlice 将包含对与 Service 选择算符匹配的所有 Pod 的引用。 EndpointSlice 通过唯一的协议、端口号和 Service 名称将网络端点组织在一起。 EndpointSlice 的名称必须是合法的 -[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 例如，下面是 Kubernetes Service `example` 的 EndpointSlice 资源示例。 @@ -459,5 +459,5 @@ implementation in `kube-proxy`. -* 阅读[使用 Service 连接到应用](/zh/docs/concepts/services-networking/connect-applications-service/) +* 阅读[使用 Service 连接到应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/zh-cn/docs/concepts/services-networking/ingress-controllers.md b/content/zh-cn/docs/concepts/services-networking/ingress-controllers.md index 06a4c948bd..1e2d6ae078 100644 --- a/content/zh-cn/docs/concepts/services-networking/ingress-controllers.md +++ b/content/zh-cn/docs/concepts/services-networking/ingress-controllers.md @@ -143,13 +143,13 @@ You may deploy any number of ingress controllers using [ingress class](/docs/con within a cluster. Note the `.metadata.name` of your ingress class resource. When you create an ingress you would need that name to specify the `ingressClassName` field on your Ingress object (refer to [IngressSpec v1 reference](/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec). `ingressClassName` is a replacement of the older [annotation method](/docs/concepts/services-networking/ingress/#deprecated-annotation). --> 你可以使用 -[Ingress 类](/zh/docs/concepts/services-networking/ingress/#ingress-class)在集群中部署任意数量的 +[Ingress 类](/zh-cn/docs/concepts/services-networking/ingress/#ingress-class)在集群中部署任意数量的 Ingress 控制器。 请注意你的 Ingress 类资源的 `.metadata.name` 字段。 当你创建 Ingress 时，你需要用此字段的值来设置 Ingress 对象的 `ingressClassName` 字段（请参考 [IngressSpec v1 reference](/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec)）。 `ingressClassName` -是之前的[注解](/zh/docs/concepts/services-networking/ingress/#deprecated-annotation)做法的替代。 +是之前的[注解](/zh-cn/docs/concepts/services-networking/ingress/#deprecated-annotation)做法的替代。 如果你不为 Ingress 指定 IngressClass，并且你的集群中只有一个 IngressClass 被标记为默认，那么 Kubernetes 会将此集群的默认 IngressClass -[应用](/zh/docs/concepts/services-networking/ingress/#default-ingress-class)到 Ingress 上。 +[应用](/zh-cn/docs/concepts/services-networking/ingress/#default-ingress-class)到 Ingress 上。 IngressClass。 你可以通过将 -[`ingressclass.kubernetes.io/is-default-class` 注解](/zh/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class) +[`ingressclass.kubernetes.io/is-default-class` 注解](/zh-cn/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class) 的值设置为 `"true"` 来将一个 IngressClass 标记为集群默认。 理想情况下，所有 Ingress 控制器都应满足此规范，但各种 Ingress 控制器的操作略有不同。 @@ -181,6 +181,6 @@ Make sure you review your ingress controller's documentation to understand the c * Learn more about [Ingress](/docs/concepts/services-networking/ingress/). * [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube). --> -* 进一步了解 [Ingress](/zh/docs/concepts/services-networking/ingress/)。 -* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/zh/docs/tasks/access-application-cluster/ingress-minikube)。 +* 进一步了解 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/)。 +* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/zh-cn/docs/tasks/access-application-cluster/ingress-minikube)。 diff --git a/content/zh-cn/docs/concepts/services-networking/ingress.md b/content/zh-cn/docs/concepts/services-networking/ingress.md index e14cd79ef8..6b5bf60c38 100644 --- a/content/zh-cn/docs/concepts/services-networking/ingress.md +++ b/content/zh-cn/docs/concepts/services-networking/ingress.md @@ -36,7 +36,7 @@ For clarity, this guide defines the following terms: 在此示例和在大多数常见的 Kubernetes 部署环境中，集群中的节点都不在公共网络中。 * 边缘路由器（Edge Router）: 在集群中强制执行防火墙策略的路由器。可以是由云提供商管理的网关，也可以是物理硬件。 * 集群网络（Cluster Network）: 一组逻辑的或物理的连接，根据 Kubernetes - [网络模型](/zh/docs/concepts/cluster-administration/networking/)在集群内实现通信。 + [网络模型](/zh-cn/docs/concepts/cluster-administration/networking/)在集群内实现通信。 * 服务（Service）：Kubernetes {{< glossary_tooltip term_id="service" >}}， 使用{{< glossary_tooltip text="标签" term_id="label" >}}选择器（selectors）辨认一组 Pod。 除非另有说明，否则假定服务只具有在集群网络中可路由的虚拟 IP。 @@ -51,7 +51,7 @@ Traffic routing is controlled by rules defined on the Ingress resource. ## Ingress 是什么？ {#what-is-ingress} [Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io) -公开从集群外部到集群内[服务](/zh/docs/concepts/services-networking/service/)的 +公开从集群外部到集群内[服务](/zh-cn/docs/concepts/services-networking/service/)的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源上定义的规则控制。 @@ -66,7 +66,7 @@ Here is a simple example where an Ingress sends all its traffic to one Service: An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers) is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic. --> Ingress 可为 Service 提供外部可访问的 URL、负载均衡流量、终止 SSL/TLS，以及基于名称的虚拟托管。 -[Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) +[Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers) 通常负责通过负载均衡器来实现 Ingress，尽管它也可以配置边缘路由器或其他前端来帮助处理流量。 Ingress 不会公开任意端口或协议。 将 HTTP 和 HTTPS 以外的服务公开到 Internet 时，通常使用 -[Service.Type=NodePort](/zh/docs/concepts/services-networking/service/#type-nodeport) -或 [Service.Type=LoadBalancer](/zh/docs/concepts/services-networking/service/#loadbalancer) +[Service.Type=NodePort](/zh-cn/docs/concepts/services-networking/service/#type-nodeport) +或 [Service.Type=LoadBalancer](/zh-cn/docs/concepts/services-networking/service/#loadbalancer) 类型的 Service。 ## 环境准备 -你必须拥有一个 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 才能满足 Ingress 的要求。 +你必须拥有一个 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers) 才能满足 Ingress 的要求。 仅创建 Ingress 资源本身没有任何效果。 你可能需要部署 Ingress 控制器，例如 [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)。 -你可以从许多 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 中进行选择。 +你可以从许多 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers) 中进行选择。 Ingress 需要指定 `apiVersion`、`kind`、 `metadata`和 `spec` 字段。 -Ingress 对象的命名必须是合法的 [DNS 子域名名称](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 -关于如何使用配置文件，请参见[部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)、 -[配置容器](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)、 -[管理资源](/zh/docs/concepts/cluster-administration/manage-deployment/)。 +Ingress 对象的命名必须是合法的 [DNS 子域名名称](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +关于如何使用配置文件，请参见[部署应用](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)、 +[配置容器](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)、 +[管理资源](/zh-cn/docs/concepts/cluster-administration/manage-deployment/)。 Ingress 经常使用注解（annotations）来配置一些选项，具体取决于 Ingress 控制器，例如[重写目标注解](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)。 -不同的 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)支持不同的注解。 +不同的 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers)支持不同的注解。 查看你所选的 Ingress 控制器的文档，以了解其支持哪些注解。 {{< note >}} -取决于你所使用的 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)， -你可能需要创建默认 HTTP 后端[服务](/zh/docs/concepts/services-networking/service/)。 +取决于你所使用的 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers)， +你可能需要创建默认 HTTP 后端[服务](/zh-cn/docs/concepts/services-networking/service/)。 {{< /note >}} 值得注意的是，尽管健康检查不是通过 Ingress 直接暴露的，在 Kubernetes 中存在并行的概念，比如 -[就绪检查](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)， +[就绪检查](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)， 允许你实现相同的目的。 请检查特定控制器的说明文档（[nginx](https://git.k8s.io/ingress-nginx/README.md)、 [GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)）以了解它们是怎样处理健康检查的。 @@ -1000,7 +1000,7 @@ Please check the documentation of the relevant [Ingress controller](/docs/concep ## 跨可用区失败 {#failing-across-availability-zones} 不同的云厂商使用不同的技术来实现跨故障域的流量分布。详情请查阅相关 Ingress 控制器的文档。 -请查看相关 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)的文档以了解详细信息。 +请查看相关 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers)的文档以了解详细信息。 -* 使用 [Service.Type=LoadBalancer](/zh/docs/concepts/services-networking/service/#loadbalancer) -* 使用 [Service.Type=NodePort](/zh/docs/concepts/services-networking/service/#nodeport) +* 使用 [Service.Type=LoadBalancer](/zh-cn/docs/concepts/services-networking/service/#loadbalancer) +* 使用 [Service.Type=NodePort](/zh-cn/docs/concepts/services-networking/service/#nodeport) ## {{% heading "whatsnext" %}} @@ -1026,6 +1026,6 @@ You can expose a Service in multiple ways that don't directly involve the Ingres * [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube/) --> * 进一步了解 [Ingress](/docs/reference/kubernetes-api/service-resources/ingress-v1/) API -* 进一步了解 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/) -* [使用 NGINX 控制器在 Minikube 上安装 Ingress](/zh/docs/tasks/access-application-cluster/ingress-minikube/) +* 进一步了解 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers/) +* [使用 NGINX 控制器在 Minikube 上安装 Ingress](/zh-cn/docs/tasks/access-application-cluster/ingress-minikube/) diff --git a/content/zh-cn/docs/concepts/services-networking/network-policies.md b/content/zh-cn/docs/concepts/services-networking/network-policies.md index ef2884c281..f86efea978 100644 --- a/content/zh-cn/docs/concepts/services-networking/network-policies.md +++ b/content/zh-cn/docs/concepts/services-networking/network-policies.md @@ -58,7 +58,7 @@ Network policies are implemented by the [network plugin](/docs/concepts/extend-k --> ## 前置条件 {#prerequisites} -网络策略通过[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +网络策略通过[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) 来实现。要使用网络策略，你必须使用支持 NetworkPolicy 的网络解决方案。 创建一个 NetworkPolicy 资源对象而没有控制器来使它生效的话，是没有任何作用的。 @@ -144,8 +144,8 @@ __podSelector__: Each NetworkPolicy includes a `podSelector` which selects the g --> __必需字段__：与所有其他的 Kubernetes 配置一样，NetworkPolicy 需要 `apiVersion`、 `kind` 和 `metadata` 字段。关于配置文件操作的一般信息，请参考 -[配置 Pod 以使用 ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/), -和[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management)。 +[配置 Pod 以使用 ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/), +和[对象管理](/zh-cn/docs/concepts/overview/working-with-objects/object-management)。 __spec__：NetworkPolicy [规约](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 中包含了在一个名字空间中定义特定网络策略所需的所有信息。 @@ -204,7 +204,7 @@ See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network- 3. （Egress 规则）允许 “default” 命名空间中任何带有标签 “role=db” 的 Pod 到 CIDR 10.0.0.0/24 下 5978 TCP 端口的连接。 -参阅[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)演练 +参阅[声明网络策略](/zh-cn/docs/tasks/administer-cluster/declare-network-policy/)演练 了解更多示例。 你的集群所使用的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件 必须支持在 NetworkPolicy 规约中使用 `endPort` 字段。 -如果你的[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +如果你的[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) 不支持 `endPort` 字段，而你指定了一个包含 `endPort` 字段的 NetworkPolicy， 策略只对单个 `port` 字段生效。 {{< /note >}} @@ -530,7 +530,7 @@ While NetworkPolicy cannot target a namespace by its name with some object field standardized label to target a specific namespace. --> 只要 `NamespaceDefaultLabelName` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 被启用，Kubernetes 控制面会在所有名字空间上设置一个不可变更的标签 `kubernetes.io/metadata.name`。该标签的值是名字空间的名称。 @@ -588,7 +588,7 @@ As of Kubernetes {{< skew latestVersion >}}, the following functionality does no walkthrough for further examples. - See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource. --> -- 参阅[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/) +- 参阅[声明网络策略](/zh-cn/docs/tasks/administer-cluster/declare-network-policy/) 演练了解更多示例； - 有关 NetworkPolicy 资源所支持的常见场景的更多信息，请参见 [此指南](https://github.com/ahmetb/kubernetes-network-policy-recipes)。 diff --git a/content/zh-cn/docs/concepts/services-networking/service-topology.md b/content/zh-cn/docs/concepts/services-networking/service-topology.md index 4ab71cee41..e899786565 100644 --- a/content/zh-cn/docs/concepts/services-networking/service-topology.md +++ b/content/zh-cn/docs/concepts/services-networking/service-topology.md @@ -25,7 +25,7 @@ introduced in Kubernetes v1.21, provide similar functionality. --> 此功能特性，尤其是 Alpha 阶段的 `topologyKeys` API，在 Kubernetes v1.21 版本中已被废弃。Kubernetes v1.21 版本中引入的 -[拓扑感知的提示](/zh/docs/concepts/services-networking/topology-aware-hints/), +[拓扑感知的提示](/zh-cn/docs/concepts/services-networking/topology-aware-hints/), 提供类似的功能。 {{}} @@ -104,7 +104,7 @@ as the last value in the list. ## 使用服务拓扑 {#using-service-topology} 如果集群启用了 `ServiceTopology` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， 你就可以在 Service 规约中设定 `topologyKeys` 字段，从而控制其流量路由。 此字段是 `Node` 标签的优先顺序字段，将用于在访问这个 `Service` 时对端点进行排序。 流量会被定向到第一个标签值和源 `Node` 标签值相匹配的 `Node`。 @@ -300,6 +300,6 @@ spec: * Read about [enabling Service Topology](/docs/tasks/administer-cluster/enabling-service-topology) * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) --> -* 阅读关于[启用服务拓扑](/zh/docs/tasks/administer-cluster/enabling-service-topology/) -* 阅读[用服务连接应用程序](/zh/docs/concepts/services-networking/connect-applications-service/) +* 阅读关于[启用服务拓扑](/zh-cn/docs/tasks/administer-cluster/enabling-service-topology/) +* 阅读[用服务连接应用程序](/zh-cn/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/zh-cn/docs/concepts/services-networking/service-traffic-policy.md b/content/zh-cn/docs/concepts/services-networking/service-traffic-policy.md index dad9dcc79b..b291c17758 100644 --- a/content/zh-cn/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/zh-cn/docs/concepts/services-networking/service-traffic-policy.md @@ -43,7 +43,7 @@ When the feature is enabled, you can enable the internal-only traffic policy for This tells kube-proxy to only use node local endpoints for cluster internal traffic. --> `ServiceInternalTrafficPolicy` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 是 Beta 功能，默认启用。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 是 Beta 功能，默认启用。 启用该功能后，你就可以通过将 {{< glossary_tooltip text="Services" term_id="service" >}} 的 `.spec.internalTrafficPolicy` 项设置为 `Local`， 来为它指定一个内部专用的流量策略。 @@ -99,7 +99,7 @@ When the [feature gate](/docs/reference/command-line-tools-reference/feature-gat kube-proxy 基于 `spec.internalTrafficPolicy` 的设置来过滤路由的目标服务端点。 当它的值设为 `Local` 时，只选择节点本地的服务端点。 当它的值设为 `Cluster` 或缺省时，则选择所有的服务端点。 -启用[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +启用[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) `ServiceInternalTrafficPolicy` 后， `spec.internalTrafficPolicy` 的值默认设为 `Cluster`。 @@ -123,6 +123,6 @@ kube-proxy 基于 `spec.internalTrafficPolicy` 的设置来过滤路由的目标 * Read about [Service External Traffic Policy](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip) * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) --> -* 请阅读[拓扑感知提示](/zh/docs/concepts/services-networking/topology-aware-hints) -* 请阅读[Service 的外部流量策略](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip) -* 请阅读[用 Service 连接应用](/zh/docs/concepts/services-networking/connect-applications-service/) +* 请阅读[拓扑感知提示](/zh-cn/docs/concepts/services-networking/topology-aware-hints) +* 请阅读[Service 的外部流量策略](/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip) +* 请阅读[用 Service 连接应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/zh-cn/docs/concepts/services-networking/service.md b/content/zh-cn/docs/concepts/services-networking/service.md index 71140bf426..05aec469ff 100644 --- a/content/zh-cn/docs/concepts/services-networking/service.md +++ b/content/zh-cn/docs/concepts/services-networking/service.md @@ -320,7 +320,7 @@ The name of the Endpoints object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). --> Endpoints 对象的名称必须是合法的 -[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 如果你启用了 kube-proxy 的 `ProxyTerminatingEndpoints` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， kube-proxy 会检查节点是否有本地的端点，以及是否所有的本地端点都被标记为终止中。 -你可以（几乎总是应该）使用[附加组件](/zh/docs/concepts/cluster-administration/addons/) +你可以（几乎总是应该）使用[附加组件](/zh-cn/docs/concepts/cluster-administration/addons/) 为 Kubernetes 集群设置 DNS 服务。 支持集群的 DNS 服务器（例如 CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。 @@ -905,7 +905,7 @@ Kubernetes 还支持命名端口的 DNS SRV（服务）记录。 Kubernetes DNS 服务器是唯一的一种能够访问 `ExternalName` 类型的 Service 的方式。 更多关于 `ExternalName` 信息可以查看 -[DNS Pod 和 Service](/zh/docs/concepts/services-networking/dns-pod-service/)。 +[DNS Pod 和 Service](/zh-cn/docs/concepts/services-networking/dns-pod-service/)。 -你也可以使用 [Ingress](/zh/docs/concepts/services-networking/ingress/) 来暴露自己的服务。 +你也可以使用 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/) 来暴露自己的服务。 Ingress 不是一种服务类型，但它充当集群的入口点。 它可以将路由规则整合到一个资源中，因为它可以在同一IP地址下公开多个服务。 @@ -1735,10 +1735,10 @@ groups are modified with the following IP rules: --> 为了获得均衡流量，请使用 DaemonSet 或指定 -[Pod 反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) +[Pod 反亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) 使其不在同一节点上。 -你还可以将 NLB 服务与[内部负载平衡器](/zh/docs/concepts/services-networking/service/#internal-load-balancer) +你还可以将 NLB 服务与[内部负载平衡器](/zh-cn/docs/concepts/services-networking/service/#internal-load-balancer) 注解一起使用。 为了使客户端流量能够到达 NLB 后面的实例，使用以下 IP 规则修改了节点安全组： @@ -2089,7 +2089,7 @@ assigned from the lower band. This allows users to use the lower band of the `service-cluster-ip-range` for their Services with static IPs assigned with a very low risk of running into conflicts. --> -如果启用 `ServiceIPStaticSubrange`[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +如果启用 `ServiceIPStaticSubrange`[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， 分配策略根据配置的 `service-cluster-ip-range` 的大小，使用以下公式 `min(max(16, cidrSize / 16), 256)` 进行划分，该公式可描述为 “在不小于 16 且不大于 256 之间有一个步进量（Graduated Step）”，将 @@ -2351,7 +2351,7 @@ followed by the data from the client. * Read about [Ingress](/docs/concepts/services-networking/ingress/) * Read about [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/) --> -* 阅读[使用服务访问应用](/zh/docs/concepts/services-networking/connect-applications-service/) -* 阅读了解 [Ingress](/zh/docs/concepts/services-networking/ingress/) -* 阅读了解[端点切片（Endpoint Slices）](/zh/docs/concepts/services-networking/endpoint-slices/) +* 阅读[使用服务访问应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/) +* 阅读了解 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/) +* 阅读了解[端点切片（Endpoint Slices）](/zh-cn/docs/concepts/services-networking/endpoint-slices/) diff --git a/content/zh-cn/docs/concepts/services-networking/topology-aware-hints.md b/content/zh-cn/docs/concepts/services-networking/topology-aware-hints.md index f0b28aca2a..a867c2a537 100644 --- a/content/zh-cn/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/zh-cn/docs/concepts/services-networking/topology-aware-hints.md @@ -41,7 +41,7 @@ by default. To try out this feature, you have to enable the `TopologyAwareHints` {{< note >}} “拓扑感知提示”特性处于 Beta 阶段，并且默认情况下**未**启用。 要试用此特性，你必须启用 `TopologyAwareHints` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 {{< /note >}} @@ -117,7 +117,7 @@ as many endpoints to the zone with 2 CPU cores. 此特性开启后，EndpointSlice 控制器负责在 EndpointSlice 上设置提示信息。 控制器按比例给每个区域分配一定比例数量的端点。 这个比例来源于此区域中运行节点的 -[可分配](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +[可分配](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) CPU 核心数。 例如，如果一个区域拥有 2 CPU 核心，而另一个区域只有 1 CPU 核心， 那控制器将给那个有 2 CPU 的区域分配两倍数量的端点。 @@ -292,4 +292,4 @@ Kubernetes 控制平面和每个节点上的 kube-proxy，在使用拓扑感知 * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) --> -* 参阅[通过服务连通应用](/zh/docs/concepts/services-networking/connect-applications-service/) +* 参阅[通过服务连通应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/zh-cn/docs/concepts/services-networking/windows-networking.md b/content/zh-cn/docs/concepts/services-networking/windows-networking.md index b6a7662461..ea2df2e815 100644 --- a/content/zh-cn/docs/concepts/services-networking/windows-networking.md +++ b/content/zh-cn/docs/concepts/services-networking/windows-networking.md @@ -42,7 +42,7 @@ is responsible for the management of networking resources such as: --> ## Windows 容器网络 {#networking} -Windows 容器网络通过 [CNI 插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)暴露。 +Windows 容器网络通过 [CNI 插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)暴露。 Windows 容器网络的工作方式与虚拟机类似。 每个容器都有一个连接到 Hyper-V 虚拟交换机（vSwitch）的虚拟网络适配器（vNIC）。 主机网络服务（Host Networking Service，HNS）和主机计算服务（Host Comute Service，HCS） From fd9be8986380b1aa50daec8429e03334637eca69 Mon Sep 17 00:00:00 2001 From: howieyuen Date: Thu, 23 Jun 2022 20:23:35 +0800 Subject: [PATCH 046/209] [zh]Update contribute pages for links with '/zh/' prefix, using new prefix '/zh-cn/' --- .../contribute/generate-ref-docs/_index.md | 2 +- .../generate-ref-docs/contribute-upstream.md | 12 +++++------ .../contribute/generate-ref-docs/kubectl.md | 10 +++++----- .../generate-ref-docs/kubernetes-api.md | 10 +++++----- .../kubernetes-components.md | 12 +++++------ .../prerequisites-ref-docs.md | 2 +- .../generate-ref-docs/quickstart.md | 12 +++++------ content/zh-cn/docs/contribute/localization.md | 16 +++++++-------- .../docs/contribute/new-content/_index.md | 14 ++++++------- .../new-content/blogs-case-studies.md | 4 ++-- .../contribute/new-content/new-features.md | 6 +++--- .../docs/contribute/new-content/open-a-pr.md | 14 ++++++------- .../contribute/participate/pr-wranglers.md | 12 +++++------ .../docs/contribute/review/for-approvers.md | 8 ++++---- .../docs/contribute/style/content-guide.md | 10 +++++----- .../contribute/style/content-organization.md | 8 ++++---- .../docs/contribute/style/diagram-guide.md | 20 +++++++++---------- .../contribute/style/hugo-shortcodes/index.md | 14 ++++++------- .../contribute/style/page-content-types.md | 18 ++++++++--------- .../docs/contribute/style/style-guide.md | 8 ++++---- .../docs/contribute/style/write-new-topic.md | 20 +++++++++---------- 21 files changed, 116 insertions(+), 116 deletions(-) diff --git a/content/zh-cn/docs/contribute/generate-ref-docs/_index.md b/content/zh-cn/docs/contribute/generate-ref-docs/_index.md index fc73d84b29..87f08c5f6d 100644 --- a/content/zh-cn/docs/contribute/generate-ref-docs/_index.md +++ b/content/zh-cn/docs/contribute/generate-ref-docs/_index.md @@ -22,5 +22,5 @@ To build the reference documentation, see the following guide: 本节的主题是描述如何生成 Kubernetes 参考指南。 要生成参考文档，请参考下面的指南： -* [生成参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/) +* [生成参考文档快速入门](/zh-cn/docs/contribute/generate-ref-docs/quickstart/) diff --git a/content/zh-cn/docs/contribute/generate-ref-docs/contribute-upstream.md b/content/zh-cn/docs/contribute/generate-ref-docs/contribute-upstream.md index a702b3243a..cbbc13cb9b 100644 --- a/content/zh-cn/docs/contribute/generate-ref-docs/contribute-upstream.md +++ b/content/zh-cn/docs/contribute/generate-ref-docs/contribute-upstream.md @@ -29,8 +29,8 @@ API or the `kube-*` components from the upstream code, see the following instruc --> 如果你仅想从上游代码重新生成 Kubernetes API 或 `kube-*` 组件的参考文档。请参考以下说明： -- [生成 Kubernetes API 的参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) -- [生成 Kubernetes 组件和工具的参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/) +- [生成 Kubernetes API 的参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api/) +- [生成 Kubernetes 组件和工具的参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components/) ## {{% heading "prerequisites" %}} @@ -406,7 +406,7 @@ You are now ready to follow the [Generating Reference Documentation for the Kube [published Kubernetes API reference documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/). --> 现在，你可以按照 -[生成 Kubernetes API 的参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) +[生成 Kubernetes API 的参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api/) 指南来生成 [已发布的 Kubernetes API 参考文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。 @@ -417,7 +417,7 @@ You are now ready to follow the [Generating Reference Documentation for the Kube * [Generating Reference Docs for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/) * [Generating Reference Documentation for kubectl Commands](/docs/home/contribute/generated-reference/kubectl/) --> -* [生成 Kubernetes API 的参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) -* [为 Kubernetes 组件和工具生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/) -* [生成 kubectl 命令的参考文档](/zh/docs/contribute/generate-ref-docs/kubectl/) +* [生成 Kubernetes API 的参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api/) +* [为 Kubernetes 组件和工具生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components/) +* [生成 kubectl 命令的参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubectl/) diff --git a/content/zh-cn/docs/contribute/generate-ref-docs/kubectl.md b/content/zh-cn/docs/contribute/generate-ref-docs/kubectl.md index 97f539bdf9..957ca8b347 100644 --- a/content/zh-cn/docs/contribute/generate-ref-docs/kubectl.md +++ b/content/zh-cn/docs/contribute/generate-ref-docs/kubectl.md @@ -36,7 +36,7 @@ reference page, see 生成参考文档，如 [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) 和 [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)。 本主题没有讨论如何生成 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 组件选项的参考页面。 -相关说明请参见[为 Kubernetes 组件和工具生成参考页面](/zh/docs/contribute/generate-ref-docs/kubernetes-components/)。 +相关说明请参见[为 Kubernetes 组件和工具生成参考页面](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components/)。 {{< /note >}} ## {{% heading "prerequisites" %}} @@ -416,7 +416,7 @@ topics will be visible in the 对 `kubernetes/website` 仓库创建 PR。跟踪你的 PR，并根据需要回应评审人的评论。 继续跟踪你的 PR，直到它被合入。 -在 PR 合入的几分钟后，你更新的参考主题将出现在[已发布文档](/zh/docs/home/)中。 +在 PR 合入的几分钟后，你更新的参考主题将出现在[已发布文档](/zh-cn/docs/home/)中。 ## {{% heading "whatsnext" %}} @@ -425,7 +425,7 @@ topics will be visible in the * [Generating Reference Documentation for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) * [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) --> -* [生成参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/) -* [为 Kubernetes 组件和工具生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/) -* [为 Kubernetes API 生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) +* [生成参考文档快速入门](/zh-cn/docs/contribute/generate-ref-docs/quickstart/) +* [为 Kubernetes 组件和工具生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components/) +* [为 Kubernetes API 生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api/) diff --git a/content/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api.md index 7ec78b9c17..74fc1fe897 100644 --- a/content/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api.md +++ b/content/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api.md @@ -31,7 +31,7 @@ Kubernetes API 参考文档是从 构建的， 且使用[kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) 生成代码。 -如果你在生成的文档中发现错误，则需要[在上游修复](/zh/docs/contribute/generate-ref-docs/contribute-upstream/)。 +如果你在生成的文档中发现错误，则需要[在上游修复](/zh-cn/docs/contribute/generate-ref-docs/contribute-upstream/)。 如果你只需要从 [OpenAPI](https://github.com/OAI/OpenAPI-Specification) 规范中重新生成参考文档，请继续阅读此页。 @@ -305,7 +305,7 @@ Submit your changes as a Monitor your pull request, and respond to reviewer comments as needed. Continue to monitor your pull request until it has been merged. --> -基于你所生成的更改[创建 PR](/zh/docs/contribute/new-content/open-a-pr/)， +基于你所生成的更改[创建 PR](/zh-cn/docs/contribute/new-content/open-a-pr/)， 提交到 [kubernetes/website](https://github.com/kubernetes/website) 仓库。 监视你提交的 PR，并根据需要回复 reviewer 的评论。继续监视你的 PR，直到合并为止。 @@ -316,7 +316,7 @@ to monitor your pull request until it has been merged. * [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) * [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/) --> -* [生成参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/) -* [为 Kubernetes 组件和工具生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/) -* [为 kubectl 命令集生成参考文档](/zh/docs/contribute/generate-ref-docs/kubectl/) +* [生成参考文档快速入门](/zh-cn/docs/contribute/generate-ref-docs/quickstart/) +* [为 Kubernetes 组件和工具生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components/) +* [为 kubectl 命令集生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubectl/) diff --git a/content/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components.md b/content/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components.md index 0ca9d48df6..a89e8d655e 100644 --- a/content/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components.md +++ b/content/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components.md @@ -23,7 +23,7 @@ This page shows how to build the Kubernetes component and tool reference pages. Start with the [Prerequisites section](/docs/contribute/generate-ref-docs/quickstart/#before-you-begin) in the Reference Documentation Quickstart guide. --> -阅读参考文档快速入门指南中的[准备工作](/zh/docs/contribute/generate-ref-docs/quickstart/#before-you-begin)节。 +阅读参考文档快速入门指南中的[准备工作](/zh-cn/docs/contribute/generate-ref-docs/quickstart/#before-you-begin)节。 @@ -31,7 +31,7 @@ in the Reference Documentation Quickstart guide. Follow the [Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/) to generate the Kubernetes component and tool reference pages. --> -按照[参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/) +按照[参考文档快速入门](/zh-cn/docs/contribute/generate-ref-docs/quickstart/) 指引，生成 Kubernetes 组件和工具的参考文档。 ## {{% heading "whatsnext" %}} @@ -43,8 +43,8 @@ to generate the Kubernetes component and tool reference pages. * [Contributing to the Upstream Kubernetes Project for Documentation](/docs/contribute/generate-ref-docs/contribute-upstream/) --> -* [生成参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/) -* [为 kubectll 命令生成参考文档](/zh/docs/contribute/generate-ref-docs/kubectl/) -* [为 Kubernetes API 生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) -* [为上游 Kubernetes 项目做贡献以改进文档](/zh/docs/contribute/generate-ref-docs/contribute-upstream/) +* [生成参考文档快速入门](/zh-cn/docs/contribute/generate-ref-docs/quickstart/) +* [为 kubectll 命令生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubectl/) +* [为 Kubernetes API 生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api/) +* [为上游 Kubernetes 项目做贡献以改进文档](/zh-cn/docs/contribute/generate-ref-docs/contribute-upstream/) diff --git a/content/zh-cn/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md b/content/zh-cn/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md index 5d5cde99f8..7954f939c0 100644 --- a/content/zh-cn/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md +++ b/content/zh-cn/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md @@ -41,5 +41,5 @@ - 你需要知道如何为一个 GitHub 仓库创建拉取请求（PR）。 这牵涉到创建仓库的派生（fork）副本。 - 有关信息可进一步查看[基于本地副本开展工作](/zh/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 + 有关信息可进一步查看[基于本地副本开展工作](/zh-cn/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 diff --git a/content/zh-cn/docs/contribute/generate-ref-docs/quickstart.md b/content/zh-cn/docs/contribute/generate-ref-docs/quickstart.md index 521b834153..7c4336aae5 100644 --- a/content/zh-cn/docs/contribute/generate-ref-docs/quickstart.md +++ b/content/zh-cn/docs/contribute/generate-ref-docs/quickstart.md @@ -57,7 +57,7 @@ see the [contributing upstream guide](/docs/contribute/generate-ref-docs/contrib {{< note>}} 如果你希望更改构建工具和 API 参考资料，可以阅读 -[上游贡献指南](/zh/docs/contribute/generate-ref-docs/contribute-upstream). +[上游贡献指南](/zh-cn/docs/contribute/generate-ref-docs/contribute-upstream). {{< /note >}} 通过工具导入的单页面的 Markdown 文档必须遵从 -[文档样式指南](/zh/docs/contribute/style/style-guide/)。 +[文档样式指南](/zh-cn/docs/contribute/style/style-guide/)。 要手动设置所需的构造仓库，执行构建目标，以生成各个参考文档，可参考下面的指南： -* [为 Kubernetes 组件和工具生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/) -* [为 kubectl 命令生成参考文档](/zh/docs/contribute/generate-ref-docs/kubectl/) -* [为 Kubernetes API 生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) +* [为 Kubernetes 组件和工具生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components/) +* [为 kubectl 命令生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubectl/) +* [为 Kubernetes API 生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api/) diff --git a/content/zh-cn/docs/contribute/localization.md b/content/zh-cn/docs/contribute/localization.md index 47d56e6163..9c21b55e2a 100644 --- a/content/zh-cn/docs/contribute/localization.md +++ b/content/zh-cn/docs/contribute/localization.md @@ -73,7 +73,7 @@ The website content directory includes sub-directories for each language. The lo ### 派生（fork）并且克隆仓库 {#fork-and-clone-the-repo} 首先，为 [kubernetes/website](https://github.com/kubernetes/website) 仓库 -[创建你自己的副本](/zh/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 +[创建你自己的副本](/zh-cn/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 ### 打开拉取请求 {#open-a-pull-request} -接下来，[打开拉取请求](/zh/docs/contribute/new-content/open-a-pr/#open-a-pr)（PR） +接下来，[打开拉取请求](/zh-cn/docs/contribute/new-content/open-a-pr/#open-a-pr)（PR） 将本地化添加到 `kubernetes/website` 存储库。 PR 必须包含所有[最低要求内容](#minimum-required-content)才能获得批准。 @@ -515,9 +515,9 @@ Releases | [All heading and subheading URLs](/releases) --> 描述 | 网址 -----|----- -主页 | [所有标题和副标题网址](/zh/docs/home/) -安装 | [所有标题和副标题网址](/zh/docs/setup/) -教程 | [Kubernetes 基础](/zh/docs/tutorials/kubernetes-basics/), [Hello Minikube](/zh/docs/tutorials/hello-minikube/) +主页 | [所有标题和副标题网址](/zh-cn/docs/home/) +安装 | [所有标题和副标题网址](/zh-cn/docs/setup/) +教程 | [Kubernetes 基础](/zh-cn/docs/tutorials/kubernetes-basics/), [Hello Minikube](/zh-cn/docs/tutorials/hello-minikube/) 网站字符串 | [所有网站字符串](#Site-strings-in-i18n) 发行版本 | [所有标题和副标题 URL](/releases) @@ -525,7 +525,7 @@ Releases | [All heading and subheading URLs](/releases) Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source: --> 翻译后的文档必须保存在自己的 `content/**/` 子目录中，否则将遵循与英文源相同的 URL 路径。 -例如，要准备将 [Kubernetes 基础](/zh/docs/tutorials/kubernetes-basics/) 教程翻译为德语， +例如，要准备将 [Kubernetes 基础](/zh-cn/docs/tutorials/kubernetes-basics/) 教程翻译为德语， 请在 `content/de/` 文件夹下创建一个子文件夹并复制英文源： ```shell @@ -634,7 +634,7 @@ Some language teams have their own language-specific style guide and glossary. F ### 特定语言的样式指南和词汇表 {#language-specific-style-guide-and-glossary} 一些语言团队有自己的特定语言样式指南和词汇表。 -例如，请参见[中文本地化指南](/zh/docs/contribute/localization_zh/)。 +例如，请参见[中文本地化指南](/zh-cn/docs/contribute/localization_zh/)。 - 你可以使用 [Docsy 短代码](https://www.docsy.dev/docs/adding-content/shortcodes/) - 或[定制的 Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/)贡献 Kubernetes 文档。 + 或[定制的 Hugo 短代码](/zh-cn/docs/contribute/style/hugo-shortcodes/)贡献 Kubernetes 文档。 - 除了标准的 Hugo 短代码外， - 我们还在文档中使用一些[定制的 Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/)来控制内容的呈现。 + 我们还在文档中使用一些[定制的 Hugo 短代码](/zh-cn/docs/contribute/style/hugo-shortcodes/)来控制内容的呈现。 - 文档的源代码有多种语言形式，位于 `/content/` 目录下。 每种语言都有一个自己的目录，用两个字母表示，这两个字母是基于 [ISO 639-1 标准](https://www.loc.gov/standards/iso639-2/php/code_list.php)来确定的。 例如，英语文档的源代码位于 `/content/en/docs/` 目录下。 - 关于为多语言文档做贡献以及如何开始新翻译的详细信息， - 可参考[本地化文档](/zh/docs/contribute/localization)。 + 可参考[本地化文档](/zh-cn/docs/contribute/localization)。 -- [发起一个包含新博文的 PR](/zh/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 +- [发起一个包含新博文的 PR](/zh-cn/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 新博文要创建于 [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/main/content/en/blog/_posts) 目录下。 - 确保你的博文遵从合适的命名规范，并带有下面的引言（元数据）信息： diff --git a/content/zh-cn/docs/contribute/new-content/new-features.md b/content/zh-cn/docs/contribute/new-content/new-features.md index 031ce848fd..bf75186ac3 100644 --- a/content/zh-cn/docs/contribute/new-content/new-features.md +++ b/content/zh-cn/docs/contribute/new-content/new-features.md @@ -64,7 +64,7 @@ the techniques described in 在你选定了某个功能特性，为其撰写文档（主笔或辅助），请在 `#sig-docs` Slack 频道、SIG Docs 的每周例会上， 或者在功能特性对应的 PR 上提出咨询。 如果继续工作是没有问题的，你可以使用 -[向他人的 PR 中提交](/zh/docs/contribute/review/for-approvers/#commit-into-another-persons-pr) +[向他人的 PR 中提交](/zh-cn/docs/contribute/review/for-approvers/#commit-into-another-persons-pr) 中描述的技术之一，参与 PR 的编辑工作。 如果你在处理的功能特性处于 Alpha 或 Beta 阶段并由某特性门控控制， 请确保在你的 PR 中，该特性门控被添加到 -[Alpha/Beta 特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) +[Alpha/Beta 特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) 表格中。对于新的特性门控选项，需要为该特性门控提供一段描述。 如果所处理的功能特性已经进入正式发布（GA）状态或者被废弃， 请确保将其从上述表格中迁移到 -[已毕业或废弃的特性](/zh/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-graduated-or-deprecated-features) +[已毕业或废弃的特性](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-graduated-or-deprecated-features) 表格中，并确保迁移后保留其 Alpha、Beta 版本变迁历史。 {{< note >}} **代码开发者们**：如果你在为下一个 Kubernetes 发行版本中的某功能特性撰写文档， -请参考[为发行版本撰写功能特性文档](/zh/docs/contribute/new-content/new-features/)。 +请参考[为发行版本撰写功能特性文档](/zh-cn/docs/contribute/new-content/new-features/)。 {{< /note >}} 要贡献新的内容页面或者改进已有内容页面，请发起拉取请求（PR）。 -请确保你满足了[开始之前](/zh/docs/contribute/new-content/#before-you-begin)一节中所列举的所有要求。 +请确保你满足了[开始之前](/zh-cn/docs/contribute/new-content/#before-you-begin)一节中所列举的所有要求。 -- 阅读[评阅](/zh/docs/contribute/review/reviewing-prs)节，学习评阅过程。 +- 阅读[评阅](/zh-cn/docs/contribute/review/reviewing-prs)节，学习评阅过程。 diff --git a/content/zh-cn/docs/contribute/participate/pr-wranglers.md b/content/zh-cn/docs/contribute/participate/pr-wranglers.md index b2d9748839..9ec889d8cd 100644 --- a/content/zh-cn/docs/contribute/participate/pr-wranglers.md +++ b/content/zh-cn/docs/contribute/participate/pr-wranglers.md @@ -15,11 +15,11 @@ SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#ap This section covers the duties of a PR wrangler. For more information on giving good reviews, see [Reviewing changes](/docs/contribute/review/). --> -SIG Docs 的[批准人（Approvers）](/zh/docs/contribute/participate/roles-and-responsibilities/#approvers)们每周轮流负责 +SIG Docs 的[批准人（Approvers）](/zh-cn/docs/contribute/participate/roles-and-responsibilities/#approvers)们每周轮流负责 [管理仓库的 PR](https://github.com/kubernetes/website/wiki/PR-Wranglers)。 本节介绍 PR 管理者的职责。关于如何提供较好的评审意见， -可参阅[评审变更](/zh/docs/contribute/review/)。 +可参阅[评审变更](/zh-cn/docs/contribute/review/)。 @@ -36,11 +36,11 @@ Each day in a week-long shift as PR Wrangler: 在为期一周的轮值期内，PR 管理者要： - 每天对新增的 Issues 判定和打标签。参见 - [对 Issues 进行判定和分类](/zh/docs/contribute/review/for-approvers/#triage-and-categorize-issues) + [对 Issues 进行判定和分类](/zh-cn/docs/contribute/review/for-approvers/#triage-and-categorize-issues) 以了解 SIG Docs 如何使用元数据的详细信息。 - 检查[悬决的 PR](https://github.com/kubernetes/website/pulls) 的质量并确保它们符合 - [样式指南](/zh/docs/contribute/style/style-guide/)和 - [内容指南](/zh/docs/contribute/style/content-guide/)要求。 + [样式指南](/zh-cn/docs/contribute/style/style-guide/)和 + [内容指南](/zh-cn/docs/contribute/style/content-guide/)要求。 - 首先查看最小的 PR（`size/XS`），然后逐渐扩展到最大的 PR（`size/XXL`），尽可能多地评审 PR。 @@ -77,7 +77,7 @@ Each day in a week-long shift as PR Wrangler: - 使用 `/approve` 评论来批准可以合并的 PR，在 PR 就绪时将其合并。 - PR 在被合并之前，应该有来自其他成员的 `/lgtm` 评论。 - 可以考虑接受那些技术上准确，但文风上不满足 - [风格指南](/zh/docs/contribute/style/style-guide/)要求的 PR。 + [风格指南](/zh-cn/docs/contribute/style/style-guide/)要求的 PR。 批准变更时，可以登记一个新的 Issue 来解决文档风格问题。 你通常可以将这些风格修复问题标记为 `good first issue`。 - 将风格修复事项标记为 `good first issue` 可以很好地确保向新加入的贡献者分派一些比较简单的任务， diff --git a/content/zh-cn/docs/contribute/review/for-approvers.md b/content/zh-cn/docs/contribute/review/for-approvers.md index c5763a378c..3192603db1 100644 --- a/content/zh-cn/docs/contribute/review/for-approvers.md +++ b/content/zh-cn/docs/contribute/review/for-approvers.md @@ -27,8 +27,8 @@ In addition to the rotation, a bot assigns reviewers and approvers for the PR based on the owners for the affected files. --> SIG Docs -[评阅人（Reviewers）](/zh/docs/contribute/participate/roles-and-responsibilities/#reviewers) -和[批准人（Approvers）](/zh/docs/contribute/participate/roles-and-responsibilities/#approvers) +[评阅人（Reviewers）](/zh-cn/docs/contribute/participate/roles-and-responsibilities/#reviewers) +和[批准人（Approvers）](/zh-cn/docs/contribute/participate/roles-and-responsibilities/#approvers) 在对变更进行评审时需要做一些额外的事情。 每周都有一个特定的文档批准人自愿负责对 PR 进行分类和评阅。 @@ -51,7 +51,7 @@ Everything described in [Reviewing a pull request](/docs/contribute/review/revie Kubernetes 文档遵循 [Kubernetes 代码评阅流程](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process)。 -[评阅 PR](/zh/docs/contribute/review/reviewing-prs/) 文档中所描述的所有规程都适用， +[评阅 PR](/zh-cn/docs/contribute/review/reviewing-prs/) 文档中所描述的所有规程都适用， 不过评阅人和批准人还要做以下工作： @@ -92,9 +92,9 @@ Kubernetes 文档包含 Kubernetes 项目下的多个项目的应用示例。 Kubernetes 需要某些第三方内容才能正常工作。例如 容器运行时（containerd、CRI-O、Docker）， -[联网策略](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) -（CNI 插件），[Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/) -以及[日志](/zh/docs/concepts/cluster-administration/logging/)等。 +[联网策略](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +（CNI 插件），[Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers/) +以及[日志](/zh-cn/docs/concepts/cluster-administration/logging/)等。 只有对应的第三方开源软件（OSS）是运行 Kubernetes 所必需的，才可以在文档中包含 指向这些 Kubernetes 项目之外的软件的链接。 @@ -138,4 +138,4 @@ If you have questions about allowed content, join the [Kubernetes Slack](https:/ ## {{% heading "whatsnext" %}} -* 阅读[样式指南](/zh/docs/contribute/style/style-guide)。 +* 阅读[样式指南](/zh-cn/docs/contribute/style/style-guide)。 diff --git a/content/zh-cn/docs/contribute/style/content-organization.md b/content/zh-cn/docs/contribute/style/content-organization.md index eb35c80b5f..247d016057 100644 --- a/content/zh-cn/docs/contribute/style/content-organization.md +++ b/content/zh-cn/docs/contribute/style/content-organization.md @@ -159,7 +159,7 @@ One example is [Custom Hugo Shortcodes](/docs/contribute/style/hugo-shortcodes/) 除了独立的内容页面（Markdown 文件），Hugo 还支持 [页面包](https://gohugo.io/content-management/page-bundles/)。 -一个例子是[定制的 Hugo 短代码（shortcodes）](/zh/docs/contribute/style/hugo-shortcodes/)。 +一个例子是[定制的 Hugo 短代码（shortcodes）](/zh-cn/docs/contribute/style/hugo-shortcodes/)。 它被认为是 `leaf bundle`（叶子包）。 目录下的所有内容，包括 `index.md`，都是包的一部分。此外还包括页面间相对链接、可被处理的图像等： @@ -222,7 +222,7 @@ The `SASS` source of the stylesheets for this site is stored below `src/sass` an * Learn about the [Content guide](/docs/contribute/style/content-guide) --> -* 了解[定制 Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/) -* 了解[样式指南](/zh/docs/contribute/style/style-guide) -* 了解[内容指南](/zh/docs/contribute/style/content-guide) +* 了解[定制 Hugo 短代码](/zh-cn/docs/contribute/style/hugo-shortcodes/) +* 了解[样式指南](/zh-cn/docs/contribute/style/style-guide) +* 了解[内容指南](/zh-cn/docs/contribute/style/content-guide) diff --git a/content/zh-cn/docs/contribute/style/diagram-guide.md b/content/zh-cn/docs/contribute/style/diagram-guide.md index 7a88803e45..010901f6dd 100644 --- a/content/zh-cn/docs/contribute/style/diagram-guide.md +++ b/content/zh-cn/docs/contribute/style/diagram-guide.md @@ -85,10 +85,10 @@ All you need to begin working with Mermaid is the following: * 对 Markdown 有一个基本的了解 * 使用 Mermaid 在线编辑器 -* 使用 [Hugo 短代码（shortcode）](/zh/docs/contribute/style/hugo-shortcodes/) +* 使用 [Hugo 短代码（shortcode）](/zh-cn/docs/contribute/style/hugo-shortcodes/) * 使用 [Hugo {{}} 短代码](https://gohugo.io/content-management/shortcodes/#figure) -* 执行 [Hugo 本地预览](/zh/docs/contribute/new-content/open-a-pr/#preview-locally) -* 熟悉[贡献新内容](/zh/docs/contribute/new-content/)的流程 +* 执行 [Hugo 本地预览](/zh-cn/docs/contribute/new-content/open-a-pr/#preview-locally) +* 熟悉[贡献新内容](/zh-cn/docs/contribute/new-content/)的流程 {{< note >}} -你应该使用[本地](/zh/docs/contribute/new-content/open-a-pr/#preview-locally)和 Netlify +你应该使用[本地](/zh-cn/docs/contribute/new-content/open-a-pr/#preview-locally)和 Netlify 预览来验证图表是可以正常渲染的。 {{< caution >}} @@ -564,7 +564,7 @@ Be sure to check that your diagram renders properly using the [local](/docs/contribute/new-content/open-a-pr/#preview-locally) and Netlify previews. --> -要使用[本地](/zh/docs/contribute/new-content/open-a-pr/#preview-locally)和 +要使用[本地](/zh-cn/docs/contribute/new-content/open-a-pr/#preview-locally)和 Netlify 预览来检查你的图表可以正常渲染。 ### 示例 1 - Pod 拓扑分布约束 -图 6 展示的是 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/#node-labels) +图 6 展示的是 [Pod 拓扑分布约束](/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints/#node-labels) 页面所出现的图表。 {{< mermaid >}} @@ -792,7 +792,7 @@ Figure 7 shows the diagram appearing in the [What is Ingress](/docs/concepts/ser --> ### 示例 2 - Ingress -图 7 显示的是 [Ingress 是什么](/zh/docs/concepts/services-networking/ingress/#what-is-ingress) +图 7 显示的是 [Ingress 是什么](/zh-cn/docs/concepts/services-networking/ingress/#what-is-ingress) 页面所出现的图表。 {{< mermaid >}} @@ -860,7 +860,7 @@ K8s components to start a container. 图 8 给出的是一个 Mermaid 时序图，展示启动容器时 K8s 组件间的控制流。 -{{< figure src="/zh/docs/images/diagram-guide-example-3.svg" alt="K8s system flow diagram" class="diagram-large" caption="Figure 8. K8s system flow diagram" link="https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiJSV7aW5pdDp7XCJ0aGVtZVwiOlwibmV1dHJhbFwifX0lJVxuc2VxdWVuY2VEaWFncmFtXG4gICAgYWN0b3IgbWVcbiAgICBwYXJ0aWNpcGFudCBhcGlTcnYgYXMgY29udHJvbCBwbGFuZTxicj48YnI-YXBpLXNlcnZlclxuICAgIHBhcnRpY2lwYW50IGV0Y2QgYXMgY29udHJvbCBwbGFuZTxicj48YnI-ZXRjZCBkYXRhc3RvcmVcbiAgICBwYXJ0aWNpcGFudCBjbnRybE1nciBhcyBjb250cm9sIHBsYW5lPGJyPjxicj5jb250cm9sbGVyPGJyPm1hbmFnZXJcbiAgICBwYXJ0aWNpcGFudCBzY2hlZCBhcyBjb250cm9sIHBsYW5lPGJyPjxicj5zY2hlZHVsZXJcbiAgICBwYXJ0aWNpcGFudCBrdWJlbGV0IGFzIG5vZGU8YnI-PGJyPmt1YmVsZXRcbiAgICBwYXJ0aWNpcGFudCBjb250YWluZXIgYXMgbm9kZTxicj48YnI-Y29udGFpbmVyPGJyPnJ1bnRpbWVcbiAgICBtZS0-PmFwaVNydjogMS4ga3ViZWN0bCBjcmVhdGUgLWYgcG9kLnlhbWxcbiAgICBhcGlTcnYtLT4-ZXRjZDogMi4gc2F2ZSBuZXcgc3RhdGVcbiAgICBjbnRybE1nci0-PmFwaVNydjogMy4gY2hlY2sgZm9yIGNoYW5nZXNcbiAgICBzY2hlZC0-PmFwaVNydjogNC4gd2F0Y2ggZm9yIHVuYXNzaWduZWQgcG9kcyhzKVxuICAgIGFwaVNydi0-PnNjaGVkOiA1LiBub3RpZnkgYWJvdXQgcG9kIHcgbm9kZW5hbWU9XCIgXCJcbiAgICBzY2hlZC0-PmFwaVNydjogNi4gYXNzaWduIHBvZCB0byBub2RlXG4gICAgYXBpU3J2LS0-PmV0Y2Q6IDcuIHNhdmUgbmV3IHN0YXRlXG4gICAga3ViZWxldC0-PmFwaVNydjogOC4gbG9vayBmb3IgbmV3bHkgYXNzaWduZWQgcG9kKHMpXG4gICAgYXBpU3J2LT4-a3ViZWxldDogOS4gYmluZCBwb2QgdG8gbm9kZVxuICAgIGt1YmVsZXQtPj5jb250YWluZXI6IDEwLiBzdGFydCBjb250YWluZXJcbiAgICBrdWJlbGV0LT4-YXBpU3J2OiAxMS4gdXBkYXRlIHBvZCBzdGF0dXNcbiAgICBhcGlTcnYtLT4-ZXRjZDogMTIuIHNhdmUgbmV3IHN0YXRlIiwibWVybWFpZCI6IntcbiAgXCJ0aGVtZVwiOiBcImRlZmF1bHRcIlxufSIsInVwZGF0ZUVkaXRvciI6ZmFsc2UsImF1dG9TeW5jIjp0cnVlLCJ1cGRhdGVEaWFncmFtIjp0cnVlfQ" >}} +{{< figure src="/zh-cn/docs/images/diagram-guide-example-3.svg" alt="K8s system flow diagram" class="diagram-large" caption="Figure 8. K8s system flow diagram" link="https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiJSV7aW5pdDp7XCJ0aGVtZVwiOlwibmV1dHJhbFwifX0lJVxuc2VxdWVuY2VEaWFncmFtXG4gICAgYWN0b3IgbWVcbiAgICBwYXJ0aWNpcGFudCBhcGlTcnYgYXMgY29udHJvbCBwbGFuZTxicj48YnI-YXBpLXNlcnZlclxuICAgIHBhcnRpY2lwYW50IGV0Y2QgYXMgY29udHJvbCBwbGFuZTxicj48YnI-ZXRjZCBkYXRhc3RvcmVcbiAgICBwYXJ0aWNpcGFudCBjbnRybE1nciBhcyBjb250cm9sIHBsYW5lPGJyPjxicj5jb250cm9sbGVyPGJyPm1hbmFnZXJcbiAgICBwYXJ0aWNpcGFudCBzY2hlZCBhcyBjb250cm9sIHBsYW5lPGJyPjxicj5zY2hlZHVsZXJcbiAgICBwYXJ0aWNpcGFudCBrdWJlbGV0IGFzIG5vZGU8YnI-PGJyPmt1YmVsZXRcbiAgICBwYXJ0aWNpcGFudCBjb250YWluZXIgYXMgbm9kZTxicj48YnI-Y29udGFpbmVyPGJyPnJ1bnRpbWVcbiAgICBtZS0-PmFwaVNydjogMS4ga3ViZWN0bCBjcmVhdGUgLWYgcG9kLnlhbWxcbiAgICBhcGlTcnYtLT4-ZXRjZDogMi4gc2F2ZSBuZXcgc3RhdGVcbiAgICBjbnRybE1nci0-PmFwaVNydjogMy4gY2hlY2sgZm9yIGNoYW5nZXNcbiAgICBzY2hlZC0-PmFwaVNydjogNC4gd2F0Y2ggZm9yIHVuYXNzaWduZWQgcG9kcyhzKVxuICAgIGFwaVNydi0-PnNjaGVkOiA1LiBub3RpZnkgYWJvdXQgcG9kIHcgbm9kZW5hbWU9XCIgXCJcbiAgICBzY2hlZC0-PmFwaVNydjogNi4gYXNzaWduIHBvZCB0byBub2RlXG4gICAgYXBpU3J2LS0-PmV0Y2Q6IDcuIHNhdmUgbmV3IHN0YXRlXG4gICAga3ViZWxldC0-PmFwaVNydjogOC4gbG9vayBmb3IgbmV3bHkgYXNzaWduZWQgcG9kKHMpXG4gICAgYXBpU3J2LT4-a3ViZWxldDogOS4gYmluZCBwb2QgdG8gbm9kZVxuICAgIGt1YmVsZXQtPj5jb250YWluZXI6IDEwLiBzdGFydCBjb250YWluZXJcbiAgICBrdWJlbGV0LT4-YXBpU3J2OiAxMS4gdXBkYXRlIHBvZCBzdGF0dXNcbiAgICBhcGlTcnYtLT4-ZXRjZDogMTIuIHNhdmUgbmV3IHN0YXRlIiwibWVybWFpZCI6IntcbiAgXCJ0aGVtZVwiOiBcImRlZmF1bHRcIlxufSIsInVwZGF0ZUVkaXRvciI6ZmFsc2UsImF1dG9TeW5jIjp0cnVlLCJ1cGRhdGVEaWFncmFtIjp0cnVlfQ" >}} 运行 Kubernetes 需要第三方软件。例如：你通常需要将 -[DNS 服务器](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#introduction) +[DNS 服务器](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers/#introduction) 添加到集群中，以便名称解析工作。 -当我们链接到第三方软件或以其他方式提及它时，我们会遵循[内容指南](/zh/docs/contribute/style/content-guide/) +当我们链接到第三方软件或以其他方式提及它时，我们会遵循[内容指南](/zh-cn/docs/contribute/style/content-guide/) 并标记这些第三方项目。 * 了解 [Hugo](https://gohugo.io/)。 -* 了解[撰写新的话题](/zh/docs/contribute/style/write-new-topic/)。 -* 了解[使用页面内容类型](/zh/docs/contribute/style/page-content-types/)。 -* 了解[发起 PR](/zh/docs/contribute/new-content/open-a-pr/)。 -* 了解[进阶贡献](/zh/docs/contribute/advanced/)。 +* 了解[撰写新的话题](/zh-cn/docs/contribute/style/write-new-topic/)。 +* 了解[使用页面内容类型](/zh-cn/docs/contribute/style/page-content-types/)。 +* 了解[发起 PR](/zh-cn/docs/contribute/new-content/open-a-pr/)。 +* 了解[进阶贡献](/zh-cn/docs/contribute/advanced/)。 diff --git a/content/zh-cn/docs/contribute/style/page-content-types.md b/content/zh-cn/docs/contribute/style/page-content-types.md index de72b6b4c4..2c4f11b51d 100644 --- a/content/zh-cn/docs/contribute/style/page-content-types.md +++ b/content/zh-cn/docs/contribute/style/page-content-types.md @@ -198,7 +198,7 @@ published example of a concept page. - 在 `body` 节中，详细解释对应概念； - 对于 `whatsnext` 节，提供一个项目符号列表（最多 5 个），帮助读者进一步学习掌握概念 -[注解](/zh/docs/concepts/overview/working-with-objects/annotations/)页面是一个已经 +[注解](/zh-cn/docs/concepts/overview/working-with-objects/annotations/)页面是一个已经 上线的概念页面的例子。 -- 了解[样式指南](/zh/docs/contribute/style/style-guide/) -- 了解[内容指南](/zh/docs/contribute/style/content-guide/) -- 了解[内容组织](/zh/docs/contribute/style/content-organization/) +- 了解[样式指南](/zh-cn/docs/contribute/style/style-guide/) +- 了解[内容指南](/zh-cn/docs/contribute/style/content-guide/) +- 了解[内容组织](/zh-cn/docs/contribute/style/content-organization/) diff --git a/content/zh-cn/docs/contribute/style/style-guide.md b/content/zh-cn/docs/contribute/style/style-guide.md index aee75544b4..83c9056f22 100644 --- a/content/zh-cn/docs/contribute/style/style-guide.md +++ b/content/zh-cn/docs/contribute/style/style-guide.md @@ -459,8 +459,8 @@ To specify the Kubernetes version for a task or tutorial page, include `min-kube 代码示例或者配置示例如果包含版本信息，应该与对应的文字描述一致。 如果所给的信息是特定于具体版本的，需要在 -[任务模版](/zh/docs/contribute/style/page-content-types/#task) -或[教程模版](/zh/docs/contribute/style/page-content-types/#tutorial) +[任务模版](/zh-cn/docs/contribute/style/page-content-types/#task) +或[教程模版](/zh-cn/docs/contribute/style/page-content-types/#tutorial) 的 `prerequisites` 小节定义 Kubernetes 版本。 页面保存之后，`prerequisites` 小节会显示为 **开始之前**。 @@ -952,7 +952,7 @@ Write Markdown-style links: `[link text](URL)`. For example: `[Hugo shortcodes]( 可以 | 不可以 :--| :----- 插入超级链接时给出它们所链接到的目标内容的上下文。例如：你的机器上某些端口处于开放状态。参见检查所需端口了解更详细信息。| 使用有二义性的术语，如“点击这里”。例如：你的机器上某些端口处于打开状态。参见这里了解详细信息。 -编写 Markdown 风格的链接：`[链接文本](URL)`。例如：`[Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/#table-captions)`，输出是[Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/#table-captions). | 编写 HTML 风格的超级链接：`访问我们的教程！`，或者创建会打开新 Tab 页或新窗口的链接。例如：`[网站示例](https://example.com){target="_blank"}`。 +编写 Markdown 风格的链接：`[链接文本](URL)`。例如：`[Hugo 短代码](/zh-cn/docs/contribute/style/hugo-shortcodes/#table-captions)`，输出是[Hugo 短代码](/zh-cn/docs/contribute/style/hugo-shortcodes/#table-captions). | 编写 HTML 风格的超级链接：`访问我们的教程！`，或者创建会打开新 Tab 页或新窗口的链接。例如：`[网站示例](https://example.com){target="_blank"}`。 {{< /table >}} -如[发起 PR](/zh/docs/contribute/new-content/open-a-pr/)中所述，创建 Kubernetes 文档库的派生副本。 +如[发起 PR](/zh-cn/docs/contribute/new-content/open-a-pr/)中所述，创建 Kubernetes 文档库的派生副本。 @@ -46,8 +46,8 @@ Tutorial | A tutorial page shows how to accomplish a goal that ties together sev {{< table caption = "选择页面类型的说明" >}} 类型 | 描述 :--- | :---------- -概念（Concept） | 概念页面负责解释 Kubernetes 的某方面。例如，概念页面可以描述 Kubernetes Deployment 对象，并解释当部署、扩展和更新时，它作为应用程序所扮演的角色。一般来说，概念页面不包括步骤序列，而是提供任务或教程的链接。概念主题的示例可参见 节点。 -任务（Task） | 任务页面展示如何完成特定任务。其目的是给读者提供一系列的步骤，让他们在阅读时可以实际执行。任务页面可长可短，前提是它始终围绕着某个主题展开。在任务页面中，可以将简短的解释与要执行的步骤混合在一起。如果需要提供较长的解释，则应在概念主题中进行。相关联的任务和概念主题应该相互链接。一个简短的任务页面的实例可参见 配置 Pod 使用卷存储。一个较长的任务页面的实例可参见 配置活跃性和就绪性探针。 +概念（Concept） | 概念页面负责解释 Kubernetes 的某方面。例如，概念页面可以描述 Kubernetes Deployment 对象，并解释当部署、扩展和更新时，它作为应用程序所扮演的角色。一般来说，概念页面不包括步骤序列，而是提供任务或教程的链接。概念主题的示例可参见 节点。 +任务（Task） | 任务页面展示如何完成特定任务。其目的是给读者提供一系列的步骤，让他们在阅读时可以实际执行。任务页面可长可短，前提是它始终围绕着某个主题展开。在任务页面中，可以将简短的解释与要执行的步骤混合在一起。如果需要提供较长的解释，则应在概念主题中进行。相关联的任务和概念主题应该相互链接。一个简短的任务页面的实例可参见 配置 Pod 使用卷存储。一个较长的任务页面的实例可参见 配置活跃性和就绪性探针。 教程（Tutorial） | 教程页面展示如何实现某个目标，该目标将若干 Kubernetes 功能特性联系在一起。教程可能提供一些步骤序列，读者可以在阅读页面时实际执行这些步骤。或者它可以提供相关代码片段的解释。例如，教程可以提供代码示例的讲解。教程可以包括对 Kubernetes 几个关联特性的简要解释，但有关更深入的特性解释应该链接到相关概念主题。 {{< /table >}} @@ -56,7 +56,7 @@ Use a [content type](/docs/contribute/style/page-content-types/) for each new pa that you write. Using page type helps ensure consistency among topics of a given type. --> -为每个新页面选择其[内容类型](/zh/docs/contribute/style/page-content-types/)。 +为每个新页面选择其[内容类型](/zh-cn/docs/contribute/style/page-content-types/)。 使用页面类型有助于确保给定类型的各主题之间保持一致。 有关使用此技术的主题的示例，请参见 -[运行单实例有状态的应用](/zh/docs/tasks/run-application/run-single-instance-stateful-application/)。 +[运行单实例有状态的应用](/zh-cn/docs/tasks/run-application/run-single-instance-stateful-application/)。 -* 了解[使用页面内容类型](/zh/docs/contribute/style/page-content-types/). -* 了解[创建 PR](/zh/docs/contribute/new-content/open-a-pr/). +* 了解[使用页面内容类型](/zh-cn/docs/contribute/style/page-content-types/). +* 了解[创建 PR](/zh-cn/docs/contribute/new-content/open-a-pr/). From 65fe964c69abdf97e5be9b2fc3ebe50ee847afd3 Mon Sep 17 00:00:00 2001 From: howieyuen Date: Thu, 23 Jun 2022 20:25:04 +0800 Subject: [PATCH 047/209] [zh]Update reference pages(part-1) for links with '/zh/' prefix, using new prefix '/zh-cn/' --- content/zh-cn/docs/reference/glossary/addons.md | 4 ++-- .../docs/reference/glossary/admission-controller.md | 4 ++-- content/zh-cn/docs/reference/glossary/affinity.md | 4 ++-- .../zh-cn/docs/reference/glossary/aggregation-layer.md | 4 ++-- content/zh-cn/docs/reference/glossary/annotation.md | 2 +- content/zh-cn/docs/reference/glossary/api-eviction.md | 10 +++++----- content/zh-cn/docs/reference/glossary/api-group.md | 4 ++-- content/zh-cn/docs/reference/glossary/certificate.md | 2 +- .../reference/glossary/cloud-controller-manager.md | 2 +- content/zh-cn/docs/reference/glossary/cni.md | 4 ++-- content/zh-cn/docs/reference/glossary/configmap.md | 2 +- .../docs/reference/glossary/container-env-variables.md | 2 +- .../reference/glossary/container-lifecycle-hooks.md | 2 +- .../reference/glossary/container-runtime-interface.md | 4 ++-- .../zh-cn/docs/reference/glossary/container-runtime.md | 2 +- content/zh-cn/docs/reference/glossary/container.md | 2 +- content/zh-cn/docs/reference/glossary/controller.md | 2 +- content/zh-cn/docs/reference/glossary/cri.md | 2 +- content/zh-cn/docs/reference/glossary/cronjob.md | 4 ++-- content/zh-cn/docs/reference/glossary/csi.md | 4 ++-- .../reference/glossary/customresourcedefinition.md | 2 +- content/zh-cn/docs/reference/glossary/daemonset.md | 2 +- content/zh-cn/docs/reference/glossary/deployment.md | 2 +- content/zh-cn/docs/reference/glossary/device-plugin.md | 4 ++-- content/zh-cn/docs/reference/glossary/disruption.md | 4 ++-- content/zh-cn/docs/reference/glossary/docker.md | 2 +- content/zh-cn/docs/reference/glossary/dockershim.md | 4 ++-- .../reference/glossary/dynamic-volume-provisioning.md | 2 +- 28 files changed, 44 insertions(+), 44 deletions(-) diff --git a/content/zh-cn/docs/reference/glossary/addons.md b/content/zh-cn/docs/reference/glossary/addons.md index 31fc1f0098..3fd0546714 100644 --- a/content/zh-cn/docs/reference/glossary/addons.md +++ b/content/zh-cn/docs/reference/glossary/addons.md @@ -2,7 +2,7 @@ title: 附加组件（Add-ons） id: addons date: 2019-12-15 -full_link: /zh/docs/concepts/cluster-administration/addons/ +full_link: /zh-cn/docs/concepts/cluster-administration/addons/ short_description: > 扩展 Kubernetes 功能的资源。 @@ -37,4 +37,4 @@ tags: -[安装附加组件](/zh/docs/concepts/cluster-administration/addons/) 阐释了更多关于如何在集群内使用附加组件，并列出了一些流行的附加组件。 +[安装附加组件](/zh-cn/docs/concepts/cluster-administration/addons/) 阐释了更多关于如何在集群内使用附加组件，并列出了一些流行的附加组件。 diff --git a/content/zh-cn/docs/reference/glossary/admission-controller.md b/content/zh-cn/docs/reference/glossary/admission-controller.md index 22567c4861..90e63e52b1 100644 --- a/content/zh-cn/docs/reference/glossary/admission-controller.md +++ b/content/zh-cn/docs/reference/glossary/admission-controller.md @@ -2,7 +2,7 @@ title: 准入控制器（Admission Controller） id: admission-controller date: 2019-06-28 -full_link: /zh/docs/reference/access-authn-authz/admission-controllers/ +full_link: /zh-cn/docs/reference/access-authn-authz/admission-controllers/ short_description: > 在对象持久化之前拦截 Kubernetes Api 服务器请求的一段代码 aka: @@ -47,4 +47,4 @@ validating controllers may not. 准入控制器可针对 Kubernetes Api 服务器进行配置，可以执行验证，变更或两者都执行。任何准入控制器都可以拒绝访问请求。 变更（mutating）控制器可以修改其允许的对象，验证（validating）控制器则不可以。 -* [Kubernetes 文档中的准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) \ No newline at end of file +* [Kubernetes 文档中的准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/) \ No newline at end of file diff --git a/content/zh-cn/docs/reference/glossary/affinity.md b/content/zh-cn/docs/reference/glossary/affinity.md index b3450ed02f..44aa0ab6ca 100644 --- a/content/zh-cn/docs/reference/glossary/affinity.md +++ b/content/zh-cn/docs/reference/glossary/affinity.md @@ -36,8 +36,8 @@ There are two kinds of affinity: * [node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity) * [pod-to-pod affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) --> -* [节点亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity) -* [Pod 间亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) +* [节点亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity) +* [Pod 间亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) -当你配置了 {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} 来 [支持额外的 API](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)， +当你配置了 {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} 来 [支持额外的 API](/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/)， 你就可以在 Kubernetes API 中增加 `APIService` 对象来 "申领（Claim）" 一个 URL 路径。 diff --git a/content/zh-cn/docs/reference/glossary/annotation.md b/content/zh-cn/docs/reference/glossary/annotation.md index a305352e32..5554aafbbc 100644 --- a/content/zh-cn/docs/reference/glossary/annotation.md +++ b/content/zh-cn/docs/reference/glossary/annotation.md @@ -2,7 +2,7 @@ title: 注解（Annotation） id: annotation date: 2018-04-12 -full_link: /zh/docs/concepts/overview/working-with-objects/annotations/ +full_link: /zh-cn/docs/concepts/overview/working-with-objects/annotations/ short_description: > 注解是以键值对的形式给资源对象附加随机的无法标识的元数据。 diff --git a/content/zh-cn/docs/reference/glossary/api-eviction.md b/content/zh-cn/docs/reference/glossary/api-eviction.md index 0f1aabd435..4ed41b8648 100644 --- a/content/zh-cn/docs/reference/glossary/api-eviction.md +++ b/content/zh-cn/docs/reference/glossary/api-eviction.md @@ -2,7 +2,7 @@ title: API 发起的驱逐 id: api-eviction date: 2021-04-27 -full_link: /zh/docs/concepts/scheduling-eviction/pod-eviction/#api-eviction +full_link: /zh-cn/docs/concepts/scheduling-eviction/pod-eviction/#api-eviction short_description: > API 发起的驱逐是一个先调用 Eviction API 创建驱逐对象，再由该对象体面地中止 Pod 的过程。 aka: @@ -46,13 +46,13 @@ API-initiated eviction is not the same as [node-pressure eviction](/docs/concept 你可以通过 kube-apiserver 的客户端，比如 `kubectl drain` 这样的命令，直接调用 Eviction API 发起驱逐。 当 `Eviction` 对象创建出来之后，该对象将驱动 API 服务器终止选定的Pod。 -API 发起的驱逐取决于你配置的 [`PodDisruptionBudgets`](/zh/docs/tasks/run-application/configure-pdb/) -和 [`terminationGracePeriodSeconds`](/zh/docs/concepts/workloads/pods/pod-lifecycle#pod-termination)。 +API 发起的驱逐取决于你配置的 [`PodDisruptionBudgets`](/zh-cn/docs/tasks/run-application/configure-pdb/) +和 [`terminationGracePeriodSeconds`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle#pod-termination)。 API 发起的驱逐不同于 -[节点压力引发的驱逐](/zh/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction)。 +[节点压力引发的驱逐](/zh-cn/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction)。 -* 有关详细信息，请参阅 [API 发起的驱逐](/zh/docs/concepts/scheduling-eviction/api-eviction/)。 \ No newline at end of file +* 有关详细信息，请参阅 [API 发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/)。 \ No newline at end of file diff --git a/content/zh-cn/docs/reference/glossary/api-group.md b/content/zh-cn/docs/reference/glossary/api-group.md index a219943be7..42006b5e90 100644 --- a/content/zh-cn/docs/reference/glossary/api-group.md +++ b/content/zh-cn/docs/reference/glossary/api-group.md @@ -2,7 +2,7 @@ title: API Group id: api-group date: 2019-09-02 -full_link: /zh/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning +full_link: /zh-cn/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning short_description: > Kubernetes API 中的一组相关路径 @@ -47,4 +47,4 @@ API group 在 REST 路径和序列化对象的 `apiVersion` 字段中指定。 -* 阅读 [API Group](/zh/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning) 了解更多信息。 +* 阅读 [API Group](/zh-cn/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning) 了解更多信息。 diff --git a/content/zh-cn/docs/reference/glossary/certificate.md b/content/zh-cn/docs/reference/glossary/certificate.md index 05b50e37dc..7de6715c16 100644 --- a/content/zh-cn/docs/reference/glossary/certificate.md +++ b/content/zh-cn/docs/reference/glossary/certificate.md @@ -2,7 +2,7 @@ title: 证书（Certificate） id: certificate date: 2018-04-12 -full_link: /zh/docs/tasks/tls/managing-tls-in-a-cluster/ +full_link: /zh-cn/docs/tasks/tls/managing-tls-in-a-cluster/ short_description: > 证书是个安全加密文件，用来确认对 Kubernetes 集群访问的合法性。 diff --git a/content/zh-cn/docs/reference/glossary/cloud-controller-manager.md b/content/zh-cn/docs/reference/glossary/cloud-controller-manager.md index 7fc039db36..72c581453c 100644 --- a/content/zh-cn/docs/reference/glossary/cloud-controller-manager.md +++ b/content/zh-cn/docs/reference/glossary/cloud-controller-manager.md @@ -2,7 +2,7 @@ title: 云控制器管理器（Cloud Controller Manager） id: cloud-controller-manager date: 2018-04-12 -full_link: /zh/docs/concepts/architecture/cloud-controller/ +full_link: /zh-cn/docs/concepts/architecture/cloud-controller/ short_description: > 将 Kubernetes 与第三方云提供商进行集成的控制面组件。 diff --git a/content/zh-cn/docs/reference/glossary/cni.md b/content/zh-cn/docs/reference/glossary/cni.md index 64febe0215..5f87815cb5 100644 --- a/content/zh-cn/docs/reference/glossary/cni.md +++ b/content/zh-cn/docs/reference/glossary/cni.md @@ -2,7 +2,7 @@ title: 容器网络接口（CNI） id: cni date: 2018-05-25 -full_link: /zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni +full_link: /zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni short_description: > 容器网络接口 (CNI) 插件是遵循 appc/CNI 协议的一类网络插件。 @@ -41,4 +41,4 @@ tags: * For information on Kubernetes and CNI, see ["Network plugins"](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni). --> -* 想了解 Kubernetes 和 CNI 请参考 ["网络插件"](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni)。 +* 想了解 Kubernetes 和 CNI 请参考 ["网络插件"](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni)。 diff --git a/content/zh-cn/docs/reference/glossary/configmap.md b/content/zh-cn/docs/reference/glossary/configmap.md index cc22e9de56..b90382e518 100644 --- a/content/zh-cn/docs/reference/glossary/configmap.md +++ b/content/zh-cn/docs/reference/glossary/configmap.md @@ -2,7 +2,7 @@ title: ConfigMap id: configmap date: 2018-04-12 -full_link: /zh/docs/tasks/configure-pod-container/configure-pod-configmap/ +full_link: /zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/ short_description: > ConfigMap 是一种 API 对象，用来将非机密性的数据保存到键值对中。使用时可以用作环境变量、命令行参数或者存储卷中的配置文件。 diff --git a/content/zh-cn/docs/reference/glossary/container-env-variables.md b/content/zh-cn/docs/reference/glossary/container-env-variables.md index e8796a12bd..134b0c0c7e 100644 --- a/content/zh-cn/docs/reference/glossary/container-env-variables.md +++ b/content/zh-cn/docs/reference/glossary/container-env-variables.md @@ -2,7 +2,7 @@ title: 容器环境变量（Container Environment Variables） id: container-env-variables date: 2018-04-12 -full_link: /zh/docs/concepts/containers/container-environment/ +full_link: /zh-cn/docs/concepts/containers/container-environment/ short_description: > 容器环境变量提供了 name=value 形式的、运行容器化应用所必须的一些重要信息。 diff --git a/content/zh-cn/docs/reference/glossary/container-lifecycle-hooks.md b/content/zh-cn/docs/reference/glossary/container-lifecycle-hooks.md index 6a43d283c9..1823b66b4c 100644 --- a/content/zh-cn/docs/reference/glossary/container-lifecycle-hooks.md +++ b/content/zh-cn/docs/reference/glossary/container-lifecycle-hooks.md @@ -2,7 +2,7 @@ title: 容器生命周期钩子（Container Lifecycle Hooks） id: container-lifecycle-hooks date: 2018-10-08 -full_link: /zh/docs/concepts/containers/container-lifecycle-hooks/ +full_link: /zh-cn/docs/concepts/containers/container-lifecycle-hooks/ short_description: > 生命周期钩子暴露容器管理生命周期中的事件，允许用户在事件发生时运行代码。 diff --git a/content/zh-cn/docs/reference/glossary/container-runtime-interface.md b/content/zh-cn/docs/reference/glossary/container-runtime-interface.md index 39bc8d0017..b902dc5da0 100644 --- a/content/zh-cn/docs/reference/glossary/container-runtime-interface.md +++ b/content/zh-cn/docs/reference/glossary/container-runtime-interface.md @@ -2,7 +2,7 @@ title: 容器运行时接口 id: container-runtime-interface date: 2021-11-24 -full_link: /zh/docs/concepts/architecture/cri +full_link: /zh-cn/docs/concepts/architecture/cri short_description: > kubelet 和容器运行时之间通信的主要协议。 @@ -37,6 +37,6 @@ The Kubernetes Container Runtime Interface (CRI) defines the main {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. --> Kubernetes 容器运行时接口（CRI）定义了主要 [gRPC](https://grpc.io) 协议， -用于[集群组件](/zh/docs/concepts/overview/components/#node-components) +用于[集群组件](/zh-cn/docs/concepts/overview/components/#node-components) {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 和 {{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}。 \ No newline at end of file diff --git a/content/zh-cn/docs/reference/glossary/container-runtime.md b/content/zh-cn/docs/reference/glossary/container-runtime.md index 0040642c43..4eaf10627e 100644 --- a/content/zh-cn/docs/reference/glossary/container-runtime.md +++ b/content/zh-cn/docs/reference/glossary/container-runtime.md @@ -2,7 +2,7 @@ title: 容器运行时（Container Runtime） id: container-runtime date: 2019-06-05 -full_link: /zh/docs/setup/production-environment/container-runtimes +full_link: /zh-cn/docs/setup/production-environment/container-runtimes short_description: > 容器运行时是负责运行容器的软件。 diff --git a/content/zh-cn/docs/reference/glossary/container.md b/content/zh-cn/docs/reference/glossary/container.md index 450a8af998..1ca18e3ca4 100644 --- a/content/zh-cn/docs/reference/glossary/container.md +++ b/content/zh-cn/docs/reference/glossary/container.md @@ -2,7 +2,7 @@ title: 容器（Container） id: container date: 2018-04-12 -full_link: /zh/docs/concepts/overview/what-is-kubernetes/#why-containers +full_link: /zh-cn/docs/concepts/overview/what-is-kubernetes/#why-containers short_description: > 容器是可移植、可执行的轻量级的镜像，镜像中包含软件及其相关依赖。 diff --git a/content/zh-cn/docs/reference/glossary/controller.md b/content/zh-cn/docs/reference/glossary/controller.md index e60b710603..a0c0c02bce 100644 --- a/content/zh-cn/docs/reference/glossary/controller.md +++ b/content/zh-cn/docs/reference/glossary/controller.md @@ -2,7 +2,7 @@ title: 控制器（Controller） id: controller date: 2018-04-12 -full_link: /zh/docs/concepts/architecture/controller/ +full_link: /zh-cn/docs/concepts/architecture/controller/ short_description: > 控制器通过 apiserver 监控集群的公共状态，并致力于将当前状态转变为期望的状态。 diff --git a/content/zh-cn/docs/reference/glossary/cri.md b/content/zh-cn/docs/reference/glossary/cri.md index 8c8da979e9..24450960d0 100644 --- a/content/zh-cn/docs/reference/glossary/cri.md +++ b/content/zh-cn/docs/reference/glossary/cri.md @@ -2,7 +2,7 @@ title: 容器运行时接口（CRI） id: cri date: 2019-03-07 -full_link: /zh/docs/concepts/overview/components/#container-runtime +full_link: /zh-cn/docs/concepts/overview/components/#container-runtime short_description: > 一组与 kubelet 集成的容器运行时 API diff --git a/content/zh-cn/docs/reference/glossary/cronjob.md b/content/zh-cn/docs/reference/glossary/cronjob.md index fe16d58762..487731fe31 100644 --- a/content/zh-cn/docs/reference/glossary/cronjob.md +++ b/content/zh-cn/docs/reference/glossary/cronjob.md @@ -2,7 +2,7 @@ title: 周期调度任务（CronJob） id: cronjob date: 2018-04-12 -full_link: /zh/docs/concepts/workloads/controllers/cron-jobs/ +full_link: /zh-cn/docs/concepts/workloads/controllers/cron-jobs/ short_description: > 周期调度的任务（作业）。 @@ -32,7 +32,7 @@ tags: Manages a [Job](/docs/concepts/workloads/controllers/job/) that runs on a periodic schedule. --> - 管理定期运行的 [任务](/zh/docs/concepts/workloads/controllers/job/)。 + 管理定期运行的 [任务](/zh-cn/docs/concepts/workloads/controllers/job/)。 diff --git a/content/zh-cn/docs/reference/glossary/csi.md b/content/zh-cn/docs/reference/glossary/csi.md index 89bb66cafd..d430ef3eca 100644 --- a/content/zh-cn/docs/reference/glossary/csi.md +++ b/content/zh-cn/docs/reference/glossary/csi.md @@ -2,7 +2,7 @@ title: 容器存储接口（Container Storage Interface，CSI） id: csi date: 2018-06-25 -full_link: /zh/docs/concepts/storage/volumes/#csi +full_link: /zh-cn/docs/concepts/storage/volumes/#csi short_description: > 容器存储接口 （CSI）定义了存储系统暴露给容器的标准接口。 @@ -48,5 +48,5 @@ CSI 允许存储驱动提供商为 Kubernetes 创建定制化的存储插件， [将它部署到你的集群上](https://kubernetes-csi.github.io/docs/deploying.html)。 然后你才能创建使用该 CSI 驱动的 {{< glossary_tooltip text="Storage Class" term_id="storage-class" >}} 。 -* [Kubernetes 文档中关于 CSI 的描述](/zh/docs/concepts/storage/volumes/#csi) +* [Kubernetes 文档中关于 CSI 的描述](/zh-cn/docs/concepts/storage/volumes/#csi) * [可用的 CSI 驱动列表](https://kubernetes-csi.github.io/docs/drivers.html) diff --git a/content/zh-cn/docs/reference/glossary/customresourcedefinition.md b/content/zh-cn/docs/reference/glossary/customresourcedefinition.md index c29e02d8c5..2d63482c3e 100644 --- a/content/zh-cn/docs/reference/glossary/customresourcedefinition.md +++ b/content/zh-cn/docs/reference/glossary/customresourcedefinition.md @@ -2,7 +2,7 @@ title: CustomResourceDefinition id: CustomResourceDefinition date: 2018-04-12 -full_link: /zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ +full_link: /zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ short_description: > 通过定制化的代码给你的 Kubernetes API 服务器增加资源对象，而无需编译完整的定制 API 服务器。 diff --git a/content/zh-cn/docs/reference/glossary/daemonset.md b/content/zh-cn/docs/reference/glossary/daemonset.md index 5f35ae5012..7096011743 100644 --- a/content/zh-cn/docs/reference/glossary/daemonset.md +++ b/content/zh-cn/docs/reference/glossary/daemonset.md @@ -2,7 +2,7 @@ title: DaemonSet id: daemonset date: 2018-04-12 -full_link: /zh/docs/concepts/workloads/controllers/daemonset/ +full_link: /zh-cn/docs/concepts/workloads/controllers/daemonset/ short_description: > 确保 Pod 的副本在集群中的一组节点上运行。 diff --git a/content/zh-cn/docs/reference/glossary/deployment.md b/content/zh-cn/docs/reference/glossary/deployment.md index ca52523e46..e09f680581 100644 --- a/content/zh-cn/docs/reference/glossary/deployment.md +++ b/content/zh-cn/docs/reference/glossary/deployment.md @@ -2,7 +2,7 @@ title: Deployment id: deployment date: 2018-04-12 -full_link: /zh/docs/concepts/workloads/controllers/deployment/ +full_link: /zh-cn/docs/concepts/workloads/controllers/deployment/ short_description: > Deployment 是管理应用副本的 API 对象。 diff --git a/content/zh-cn/docs/reference/glossary/device-plugin.md b/content/zh-cn/docs/reference/glossary/device-plugin.md index 30664b8c31..9bbecf8d1d 100644 --- a/content/zh-cn/docs/reference/glossary/device-plugin.md +++ b/content/zh-cn/docs/reference/glossary/device-plugin.md @@ -2,7 +2,7 @@ title: 设备插件（Device Plugin） id: device-plugin date: 2019-02-02 -full_link: /zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/ +full_link: /zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/ short_description: > 一种软件扩展，可以使 Pod 访问由特定厂商初始化或者安装的设备。 aka: @@ -49,4 +49,4 @@ See [Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) for more information. --> -更多信息请查阅[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) \ No newline at end of file +更多信息请查阅[设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) \ No newline at end of file diff --git a/content/zh-cn/docs/reference/glossary/disruption.md b/content/zh-cn/docs/reference/glossary/disruption.md index 6cfc0a1809..aa4fca945c 100644 --- a/content/zh-cn/docs/reference/glossary/disruption.md +++ b/content/zh-cn/docs/reference/glossary/disruption.md @@ -2,7 +2,7 @@ title: 干扰（Disruption） id: disruption date: 2019-09-10 -full_link: /zh/docs/concepts/workloads/pods/disruptions/ +full_link: /zh-cn/docs/concepts/workloads/pods/disruptions/ short_description: > 导致 Pod 服务停止的事件。 aka: @@ -44,4 +44,4 @@ See [Disruptions](/docs/concepts/workloads/pods/disruptions/) for more informati 如果你作为一个集群操作人员，销毁了一个从属于某个应用的 Pod, Kubernetes 视之为**自愿干扰（Voluntary Disruption）**。 如果由于节点故障 或者影响更大区域故障的断电导致 Pod 离线，kubernetes 视之为**非愿干扰（Involuntary Disruption）**。 -更多信息请查阅[Disruptions](/zh/docs/concepts/workloads/pods/disruptions/) \ No newline at end of file +更多信息请查阅[Disruptions](/zh-cn/docs/concepts/workloads/pods/disruptions/) \ No newline at end of file diff --git a/content/zh-cn/docs/reference/glossary/docker.md b/content/zh-cn/docs/reference/glossary/docker.md index bec6c834f2..78ac4c9f50 100644 --- a/content/zh-cn/docs/reference/glossary/docker.md +++ b/content/zh-cn/docs/reference/glossary/docker.md @@ -2,7 +2,7 @@ title: Docker id: docker date: 2018-04-12 -full_link: /zh/docs/reference/kubectl/docker-cli-to-kubectl/ +full_link: /zh-cn/docs/reference/kubectl/docker-cli-to-kubectl/ short_description: > Docker 是一种可以提供操作系统级别虚拟化（也称作容器）的软件技术。 diff --git a/content/zh-cn/docs/reference/glossary/dockershim.md b/content/zh-cn/docs/reference/glossary/dockershim.md index 22570a4b17..b12b08d54a 100644 --- a/content/zh-cn/docs/reference/glossary/dockershim.md +++ b/content/zh-cn/docs/reference/glossary/dockershim.md @@ -2,7 +2,7 @@ title: Dockershim id: dockershim date: 2022-04-15 -full_link: /zh/dockershim +full_link: /zh-cn/dockershim short_description: > dockershim 是 Kubernetes v1.23 及之前版本中的一个组件，Kubernetes 系统组件通过它与 Docker Engine 通信。 @@ -37,4 +37,4 @@ Kubernetes 系统组件通过它与 {{< glossary_tooltip text="Docker Engine" te Starting with version 1.24, dockershim has been removed from Kubernetes. For more information, see [Dockershim FAQ](/dockershim). --> 从 Kubernetes v1.24 开始，dockershim 已从 Kubernetes 中移除. -想了解更多信息，可参考[移除 Dockershim 的常见问题](/zh/dockershim)。 \ No newline at end of file +想了解更多信息，可参考[移除 Dockershim 的常见问题](/zh-cn/dockershim)。 \ No newline at end of file diff --git a/content/zh-cn/docs/reference/glossary/dynamic-volume-provisioning.md b/content/zh-cn/docs/reference/glossary/dynamic-volume-provisioning.md index 5606af15a4..a4f8212ba8 100644 --- a/content/zh-cn/docs/reference/glossary/dynamic-volume-provisioning.md +++ b/content/zh-cn/docs/reference/glossary/dynamic-volume-provisioning.md @@ -2,7 +2,7 @@ title: 动态卷供应（Dynamic Volume Provisioning） id: dynamicvolumeprovisioning date: 2018-04-12 -full_link: /zh/docs/concepts/storage/dynamic-provisioning/ +full_link: /zh-cn/docs/concepts/storage/dynamic-provisioning/ short_description: > 允许用户请求自动创建存储卷。 From e79cdf3a62e40108ebe6db06a802124e0bf3fa55 Mon Sep 17 00:00:00 2001 From: howieyuen Date: Thu, 23 Jun 2022 20:27:29 +0800 Subject: [PATCH 048/209] [zh]Update reference pages(part-2) for links with '/zh/' prefix, using new prefix '/zh-cn/' --- .../zh-cn/docs/reference/glossary/endpoint-slice.md | 2 +- .../docs/reference/glossary/ephemeral-container.md | 2 +- content/zh-cn/docs/reference/glossary/etcd.md | 4 ++-- content/zh-cn/docs/reference/glossary/event.md | 2 +- content/zh-cn/docs/reference/glossary/eviction.md | 4 ++-- content/zh-cn/docs/reference/glossary/extensions.md | 4 ++-- content/zh-cn/docs/reference/glossary/finalizer.md | 4 ++-- content/zh-cn/docs/reference/glossary/flexvolume.md | 4 ++-- .../docs/reference/glossary/garbage-collection.md | 10 +++++----- .../reference/glossary/horizontal-pod-autoscaler.md | 2 +- content/zh-cn/docs/reference/glossary/ingress.md | 2 +- content/zh-cn/docs/reference/glossary/job.md | 2 +- .../docs/reference/glossary/kube-controller-manager.md | 2 +- content/zh-cn/docs/reference/glossary/kube-proxy.md | 6 +++--- .../zh-cn/docs/reference/glossary/kube-scheduler.md | 2 +- content/zh-cn/docs/reference/glossary/kubeadm.md | 2 +- .../zh-cn/docs/reference/glossary/kubernetes-api.md | 2 +- content/zh-cn/docs/reference/glossary/label.md | 2 +- content/zh-cn/docs/reference/glossary/logging.md | 4 ++-- .../zh-cn/docs/reference/glossary/managed-service.md | 2 +- content/zh-cn/docs/reference/glossary/minikube.md | 2 +- content/zh-cn/docs/reference/glossary/name.md | 2 +- content/zh-cn/docs/reference/glossary/namespace.md | 2 +- .../zh-cn/docs/reference/glossary/network-policy.md | 2 +- .../docs/reference/glossary/node-pressure-eviction.md | 2 +- content/zh-cn/docs/reference/glossary/node.md | 4 ++-- content/zh-cn/docs/reference/glossary/object.md | 2 +- 27 files changed, 40 insertions(+), 40 deletions(-) diff --git a/content/zh-cn/docs/reference/glossary/endpoint-slice.md b/content/zh-cn/docs/reference/glossary/endpoint-slice.md index dcfc35e308..f08f9adf4b 100644 --- a/content/zh-cn/docs/reference/glossary/endpoint-slice.md +++ b/content/zh-cn/docs/reference/glossary/endpoint-slice.md @@ -2,7 +2,7 @@ title: EndpointSlice id: endpoint-slice date: 2018-04-12 -full_link: /zh/docs/concepts/services-networking/endpoint-slices/ +full_link: /zh-cn/docs/concepts/services-networking/endpoint-slices/ short_description: > 一种将网络端点与 Kubernetes 资源组合在一起的方法。 diff --git a/content/zh-cn/docs/reference/glossary/ephemeral-container.md b/content/zh-cn/docs/reference/glossary/ephemeral-container.md index a317bbfb10..0816175899 100644 --- a/content/zh-cn/docs/reference/glossary/ephemeral-container.md +++ b/content/zh-cn/docs/reference/glossary/ephemeral-container.md @@ -2,7 +2,7 @@ title: 临时容器（Ephemeral Container） id: ephemeral-container date: 2019-08-26 -full_link: /zh/docs/concepts/workloads/pods/ephemeral-containers/ +full_link: /zh-cn/docs/concepts/workloads/pods/ephemeral-containers/ short_description: > 你可以在 Pod 中临时运行的一种容器类型 aka: diff --git a/content/zh-cn/docs/reference/glossary/etcd.md b/content/zh-cn/docs/reference/glossary/etcd.md index adb4737975..8929d62f17 100644 --- a/content/zh-cn/docs/reference/glossary/etcd.md +++ b/content/zh-cn/docs/reference/glossary/etcd.md @@ -2,7 +2,7 @@ title: etcd id: etcd date: 2018-04-12 -full_link: /zh/docs/tasks/administer-cluster/configure-upgrade-etcd/ +full_link: /zh-cn/docs/tasks/administer-cluster/configure-upgrade-etcd/ short_description: > etcd 是兼具一致性和高可用性的键值数据库，用作保存 Kubernetes 所有集群数据的后台数据库。 @@ -40,7 +40,7 @@ If your Kubernetes cluster uses etcd as its backing store, make sure you have a [back up](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) plan for those data. --> -你的 Kubernetes 集群的 `etcd` 数据库通常需要有个[备份](/zh/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)计划。 +你的 Kubernetes 集群的 `etcd` 数据库通常需要有个[备份](/zh-cn/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)计划。 diff --git a/content/zh-cn/docs/reference/glossary/event.md b/content/zh-cn/docs/reference/glossary/event.md index 37d143e60b..6c74215300 100644 --- a/content/zh-cn/docs/reference/glossary/event.md +++ b/content/zh-cn/docs/reference/glossary/event.md @@ -51,6 +51,6 @@ Events should be treated as informative, best-effort, supplemental data. In Kubernetes, [auditing](/docs/tasks/debug/debug-cluster/audit/) generates a different kind of Event record (API group `audit.k8s.io`). --> -在 Kubernetes 中，[审计](/zh/docs/tasks/debug/debug-cluster/audit/) +在 Kubernetes 中，[审计](/zh-cn/docs/tasks/debug/debug-cluster/audit/) 机制会生成一种不同种类的 Event 记录（API 组为 `audit.k8s.io`）。 diff --git a/content/zh-cn/docs/reference/glossary/eviction.md b/content/zh-cn/docs/reference/glossary/eviction.md index 30666ca2b1..142b9fa602 100644 --- a/content/zh-cn/docs/reference/glossary/eviction.md +++ b/content/zh-cn/docs/reference/glossary/eviction.md @@ -2,7 +2,7 @@ title: 驱逐 id: eviction date: 2021-05-08 -full_link: /zh/docs/concepts/scheduling-eviction/ +full_link: /zh-cn/docs/concepts/scheduling-eviction/ short_description: > 终止节点上一个或多个 Pod 的过程。 aka: @@ -33,6 +33,6 @@ There are two kinds of eviction: * [API-initiated eviction](/docs/reference/generated/kubernetes-api/v1.23/) --> 驱逐的两种类型 -* [节点压力驱逐](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* [节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) * [API 发起的驱逐](/docs/reference/generated/kubernetes-api/v1.23/) diff --git a/content/zh-cn/docs/reference/glossary/extensions.md b/content/zh-cn/docs/reference/glossary/extensions.md index bec430f31d..ae33b45a2e 100644 --- a/content/zh-cn/docs/reference/glossary/extensions.md +++ b/content/zh-cn/docs/reference/glossary/extensions.md @@ -2,7 +2,7 @@ title: 扩展组件（Extensions） id: Extensions date: 2019-02-01 -full_link: /zh/docs/concepts/extend-kubernetes/extend-cluster/#extensions +full_link: /zh-cn/docs/concepts/extend-kubernetes/extend-cluster/#extensions short_description: > 扩展组件是扩展并与 Kubernetes 深度集成以支持新型硬件的软件组件。 aka: @@ -37,5 +37,5 @@ Many cluster administrators use a hosted or distribution instance of Kubernetes. 许多集群管理员会使用托管的 Kubernetes 或其某种发行包，这些集群预装了扩展。 因此，大多数 Kubernetes 用户将不需要 -安装[扩展组件](/zh/docs/concepts/extend-kubernetes/extend-cluster/#extensions)， +安装[扩展组件](/zh-cn/docs/concepts/extend-kubernetes/extend-cluster/#extensions)， 需要编写新的扩展组件的用户就更少了。 diff --git a/content/zh-cn/docs/reference/glossary/finalizer.md b/content/zh-cn/docs/reference/glossary/finalizer.md index 82b462784c..2de7c10073 100644 --- a/content/zh-cn/docs/reference/glossary/finalizer.md +++ b/content/zh-cn/docs/reference/glossary/finalizer.md @@ -2,7 +2,7 @@ title: Finalizer id: finalizer date: 2021-07-07 -full_link: /zh/docs/concepts/overview/working-with-objects/finalizers/ +full_link: /zh-cn/docs/concepts/overview/working-with-objects/finalizers/ short_description: > 一个带有命名空间的键，告诉 Kubernetes 等到特定的条件被满足后， 再完全删除被标记为删除的资源。 @@ -17,7 +17,7 @@ tags: title: Finalizer id: finalizer date: 2021-07-07 -full_link: /zh/docs/concepts/overview/working-with-objects/finalizers/ +full_link: /zh-cn/docs/concepts/overview/working-with-objects/finalizers/ short_description: > A namespaced key that tells Kubernetes to wait until specific conditions are met before it fully deletes an object marked for deletion. diff --git a/content/zh-cn/docs/reference/glossary/flexvolume.md b/content/zh-cn/docs/reference/glossary/flexvolume.md index e0f15afb4c..c00fd05922 100644 --- a/content/zh-cn/docs/reference/glossary/flexvolume.md +++ b/content/zh-cn/docs/reference/glossary/flexvolume.md @@ -2,7 +2,7 @@ title: FlexVolume id: flexvolume date: 2018-06-25 -full_link: /zh/docs/concepts/storage/volumes/#flexvolume +full_link: /zh-cn/docs/concepts/storage/volumes/#flexvolume short_description: > FlexVolume 是一个已弃用的接口，用于创建树外卷插件。 {{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}} @@ -47,6 +47,6 @@ FlexVolume 驱动程序的二进制文件和依赖项必须安装在主机上。 * [More information on FlexVolumes](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) * [Volume Plugin FAQ for Storage Vendors](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) --> -* [Kubernetes 文档中的 Flexvolume](/zh/docs/concepts/storage/volumes/#flexvolume) +* [Kubernetes 文档中的 Flexvolume](/zh-cn/docs/concepts/storage/volumes/#flexvolume) * [更多关于 Flexvolumes 的信息](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) * [存储供应商的卷插件 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) diff --git a/content/zh-cn/docs/reference/glossary/garbage-collection.md b/content/zh-cn/docs/reference/glossary/garbage-collection.md index effc51483c..f6ca64f58d 100644 --- a/content/zh-cn/docs/reference/glossary/garbage-collection.md +++ b/content/zh-cn/docs/reference/glossary/garbage-collection.md @@ -2,7 +2,7 @@ title: 垃圾收集 id: garbage-collection date: 2021-07-07 -full_link: /zh/docs/concepts/workloads/controllers/garbage-collection/ +full_link: /zh-cn/docs/concepts/workloads/controllers/garbage-collection/ short_description: > Kubernetes 用于清理集群资源的各种机制的统称。 @@ -42,8 +42,8 @@ Kubernetes uses garbage collection to clean up resources like [unused containers that have expired or failed. --> Kubernetes 使用垃圾收集机制来清理资源，例如： -[未使用的容器和镜像](/zh/docs/concepts/workloads/controllers/garbage-collection/#containers-images)、 -[失败的 Pod](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)、 -[目标资源拥有的对象](/zh/docs/concepts/overview/working-with-objects/owners-dependents/)、 -[已完成的 Job](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)、 +[未使用的容器和镜像](/zh-cn/docs/concepts/workloads/controllers/garbage-collection/#containers-images)、 +[失败的 Pod](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)、 +[目标资源拥有的对象](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/)、 +[已完成的 Job](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/)、 过期或出错的资源。 \ No newline at end of file diff --git a/content/zh-cn/docs/reference/glossary/horizontal-pod-autoscaler.md b/content/zh-cn/docs/reference/glossary/horizontal-pod-autoscaler.md index 45e5033a5a..49b18de3ee 100644 --- a/content/zh-cn/docs/reference/glossary/horizontal-pod-autoscaler.md +++ b/content/zh-cn/docs/reference/glossary/horizontal-pod-autoscaler.md @@ -2,7 +2,7 @@ title: Pod 水平自动扩缩器（Horizontal Pod Autoscaler） id: horizontal-pod-autoscaler date: 2018-04-12 -full_link: /zh/docs/tasks/run-application/horizontal-pod-autoscale/ +full_link: /zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/ short_description: > Pod 水平自动扩缩器（Horizontal Pod Autoscaler）是一种 API 资源，它根据目标 CPU 利用率或自定义度量目标扩缩 Pod 副本的数量。 diff --git a/content/zh-cn/docs/reference/glossary/ingress.md b/content/zh-cn/docs/reference/glossary/ingress.md index 2b08741574..e48b9948a1 100644 --- a/content/zh-cn/docs/reference/glossary/ingress.md +++ b/content/zh-cn/docs/reference/glossary/ingress.md @@ -2,7 +2,7 @@ title: Ingress id: ingress date: 2018-04-12 -full_link: /zh/docs/concepts/services-networking/ingress/ +full_link: /zh-cn/docs/concepts/services-networking/ingress/ short_description: > Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。 diff --git a/content/zh-cn/docs/reference/glossary/job.md b/content/zh-cn/docs/reference/glossary/job.md index aa557297be..220f811144 100644 --- a/content/zh-cn/docs/reference/glossary/job.md +++ b/content/zh-cn/docs/reference/glossary/job.md @@ -2,7 +2,7 @@ title: Job id: job date: 2018-04-12 -full_link: /zh/docs/concepts/workloads/controllers/job/ +full_link: /zh-cn/docs/concepts/workloads/controllers/job/ short_description: > Job 是需要运行完成的确定性的或批量的任务。 diff --git a/content/zh-cn/docs/reference/glossary/kube-controller-manager.md b/content/zh-cn/docs/reference/glossary/kube-controller-manager.md index f770230160..132a05936b 100644 --- a/content/zh-cn/docs/reference/glossary/kube-controller-manager.md +++ b/content/zh-cn/docs/reference/glossary/kube-controller-manager.md @@ -29,7 +29,7 @@ tags: Control plane component that runs {{< glossary_tooltip text="controller" term_id="controller" >}} processes. --> -[kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) +[kube-controller-manager](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/) 是{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}的组件， 负责运行{{< glossary_tooltip text="控制器" term_id="controller" >}}进程。 diff --git a/content/zh-cn/docs/reference/glossary/kube-proxy.md b/content/zh-cn/docs/reference/glossary/kube-proxy.md index 3fce715cb7..ef7b661715 100644 --- a/content/zh-cn/docs/reference/glossary/kube-proxy.md +++ b/content/zh-cn/docs/reference/glossary/kube-proxy.md @@ -2,7 +2,7 @@ title: kube-proxy id: kube-proxy date: 2018-04-12 -full_link: /zh/docs/reference/command-line-tools-reference/kube-proxy/ +full_link: /zh-cn/docs/reference/command-line-tools-reference/kube-proxy/ short_description: > `kube-proxy` 是集群中每个节点上运行的网络代理。 @@ -15,7 +15,7 @@ tags: title: kube-proxy id: kube-proxy date: 2018-04-12 -full_link: /zh/docs/reference/command-line-tools-reference/kube-proxy/ +full_link: /zh-cn/docs/reference/command-line-tools-reference/kube-proxy/ short_description: > `kube-proxy` is a network proxy that runs on each node in the cluster. @@ -30,7 +30,7 @@ tags: implementing part of the Kubernetes {{< glossary_tooltip term_id="service">}} concept. --> -[kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/) +[kube-proxy](/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/) 是集群中每个{{< glossary_tooltip text="节点（node）" term_id="node" >}}所上运行的网络代理， 实现 Kubernetes {{< glossary_tooltip term_id="service">}} 概念的一部分。 diff --git a/content/zh-cn/docs/reference/glossary/kube-scheduler.md b/content/zh-cn/docs/reference/glossary/kube-scheduler.md index c2964d0d74..f9c6ecdaf8 100644 --- a/content/zh-cn/docs/reference/glossary/kube-scheduler.md +++ b/content/zh-cn/docs/reference/glossary/kube-scheduler.md @@ -2,7 +2,7 @@ title: kube-scheduler id: kube-scheduler date: 2018-04-12 -full_link: /zh/docs/reference/command-line-tools-reference/kube-scheduler/ +full_link: /zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/ short_description: > 控制平面组件，负责监视新创建的、未指定运行节点的 Pod，选择节点让 Pod 在上面运行。 diff --git a/content/zh-cn/docs/reference/glossary/kubeadm.md b/content/zh-cn/docs/reference/glossary/kubeadm.md index f565376100..106edda93c 100644 --- a/content/zh-cn/docs/reference/glossary/kubeadm.md +++ b/content/zh-cn/docs/reference/glossary/kubeadm.md @@ -2,7 +2,7 @@ title: Kubeadm id: kubeadm date: 2018-04-12 -full_link: /zh/docs/setup/production-environment/tools/kubeadm/ +full_link: /zh-cn/docs/setup/production-environment/tools/kubeadm/ short_description: > 用来快速安装 Kubernetes 并搭建安全稳定的集群的工具。 diff --git a/content/zh-cn/docs/reference/glossary/kubernetes-api.md b/content/zh-cn/docs/reference/glossary/kubernetes-api.md index 060ddf93cd..0a6c096a42 100644 --- a/content/zh-cn/docs/reference/glossary/kubernetes-api.md +++ b/content/zh-cn/docs/reference/glossary/kubernetes-api.md @@ -2,7 +2,7 @@ title: Kubernetes API id: kubernetes-api date: 2018-04-12 -full_link: /zh/docs/concepts/overview/kubernetes-api/ +full_link: /zh-cn/docs/concepts/overview/kubernetes-api/ short_description: > Kubernetes API 是通过 RESTful 接口提供 Kubernetes 功能服务并负责集群状态存储的应用程序。 diff --git a/content/zh-cn/docs/reference/glossary/label.md b/content/zh-cn/docs/reference/glossary/label.md index f2c661cc44..e0654faa26 100644 --- a/content/zh-cn/docs/reference/glossary/label.md +++ b/content/zh-cn/docs/reference/glossary/label.md @@ -2,7 +2,7 @@ title: 标签（Label） id: label date: 2018-04-12 -full_link: /zh/docs/concepts/overview/working-with-objects/labels/ +full_link: /zh-cn/docs/concepts/overview/working-with-objects/labels/ short_description: > 用来为对象设置可标识的属性标记；这些标记对用户而言是有意义且重要的。 diff --git a/content/zh-cn/docs/reference/glossary/logging.md b/content/zh-cn/docs/reference/glossary/logging.md index 64d8dbd0ac..17e490de27 100644 --- a/content/zh-cn/docs/reference/glossary/logging.md +++ b/content/zh-cn/docs/reference/glossary/logging.md @@ -2,7 +2,7 @@ title: 日志（Logging） id: logging date: 2019-04-04 -full_link: /zh/docs/concepts/cluster-administration/logging/ +full_link: /zh-cn/docs/concepts/cluster-administration/logging/ short_description: > 日志是集群或应用程序记录的事件列表。 @@ -18,7 +18,7 @@ tags: title: Logging id: logging date: 2019-04-04 -full_link: /zh/docs/concepts/cluster-administration/logging/ +full_link: /zh-cn/docs/concepts/cluster-administration/logging/ short_description: > Logs are the list of events that are logged by cluster or application. diff --git a/content/zh-cn/docs/reference/glossary/managed-service.md b/content/zh-cn/docs/reference/glossary/managed-service.md index 567736f091..d115469431 100644 --- a/content/zh-cn/docs/reference/glossary/managed-service.md +++ b/content/zh-cn/docs/reference/glossary/managed-service.md @@ -40,7 +40,7 @@ list, provision, and bind with Managed Services offered by --> 托管服务的一些例子有 AWS EC2、Azure SQL 数据库和 GCP Pub/Sub 等， 不过它们也可以是可以被某应用使用的任何软件交付件。 -[服务目录](/zh/docs/concepts/extend-kubernetes/service-catalog/) +[服务目录](/zh-cn/docs/concepts/extend-kubernetes/service-catalog/) 提供了一种方法用来列举、制备和绑定到 {{< glossary_tooltip text="服务代理商（Service Brokers）" term_id="service-broker" >}} 所提供的托管服务。 diff --git a/content/zh-cn/docs/reference/glossary/minikube.md b/content/zh-cn/docs/reference/glossary/minikube.md index 4d834cd807..b688f96822 100644 --- a/content/zh-cn/docs/reference/glossary/minikube.md +++ b/content/zh-cn/docs/reference/glossary/minikube.md @@ -44,4 +44,4 @@ You can use Minikube to Minikube 在用户计算机上的一个虚拟机内运行单节点 Kubernetes 集群。 你可以使用 Minikube -[在学习环境中尝试 Kubernetes](/zh/docs/setup/learning-environment/). +[在学习环境中尝试 Kubernetes](/zh-cn/docs/setup/learning-environment/). diff --git a/content/zh-cn/docs/reference/glossary/name.md b/content/zh-cn/docs/reference/glossary/name.md index 6c6dd2b15c..984b85f1f7 100644 --- a/content/zh-cn/docs/reference/glossary/name.md +++ b/content/zh-cn/docs/reference/glossary/name.md @@ -2,7 +2,7 @@ title: 名称（Name） id: name date: 2018-04-12 -full_link: /zh/docs/concepts/overview/working-with-objects/names/ +full_link: /zh-cn/docs/concepts/overview/working-with-objects/names/ short_description: > 客户端提供的字符串，用来指代资源 URL 中的对象，如 `/api/v1/pods/some-name`。 diff --git a/content/zh-cn/docs/reference/glossary/namespace.md b/content/zh-cn/docs/reference/glossary/namespace.md index 5934d748fe..b2033d2a03 100644 --- a/content/zh-cn/docs/reference/glossary/namespace.md +++ b/content/zh-cn/docs/reference/glossary/namespace.md @@ -2,7 +2,7 @@ title: 名字空间（Namespace） id: namespace date: 2018-04-12 -full_link: /zh/docs/concepts/overview/working-with-objects/namespaces/ +full_link: /zh-cn/docs/concepts/overview/working-with-objects/namespaces/ short_description: > 名字空间是 Kubernetes 用来支持隔离单个集群中的资源组的一种抽象。 diff --git a/content/zh-cn/docs/reference/glossary/network-policy.md b/content/zh-cn/docs/reference/glossary/network-policy.md index 864b6760d9..69c8f50319 100644 --- a/content/zh-cn/docs/reference/glossary/network-policy.md +++ b/content/zh-cn/docs/reference/glossary/network-policy.md @@ -2,7 +2,7 @@ title: 网络策略 id: network-policy date: 2018-04-12 -full_link: /zh/docs/concepts/services-networking/network-policies/ +full_link: /zh-cn/docs/concepts/services-networking/network-policies/ short_description: > 网络策略是一种规范，规定了允许 Pod 组之间、Pod 与其他网络端点之间以怎样的方式进行通信。 diff --git a/content/zh-cn/docs/reference/glossary/node-pressure-eviction.md b/content/zh-cn/docs/reference/glossary/node-pressure-eviction.md index c5faa5f135..ad2108e9d8 100644 --- a/content/zh-cn/docs/reference/glossary/node-pressure-eviction.md +++ b/content/zh-cn/docs/reference/glossary/node-pressure-eviction.md @@ -2,7 +2,7 @@ title: 节点压力驱逐 id: node-pressure-eviction date: 2021-05-13 -full_link: /zh/docs/concepts/scheduling-eviction/node-pressure-eviction/ +full_link: /zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/ short_description: > 节点压力驱逐是 kubelet 主动使 Pod 失败以回收节点上的资源的过程。 aka: diff --git a/content/zh-cn/docs/reference/glossary/node.md b/content/zh-cn/docs/reference/glossary/node.md index d9ac8a9deb..be28602cac 100644 --- a/content/zh-cn/docs/reference/glossary/node.md +++ b/content/zh-cn/docs/reference/glossary/node.md @@ -2,7 +2,7 @@ title: 节点（Node） id: node date: 2018-04-12 -full_link: /zh/docs/concepts/architecture/nodes/ +full_link: /zh-cn/docs/concepts/architecture/nodes/ short_description: > Kubernetes 中的工作机器称作节点。 @@ -15,7 +15,7 @@ tags: title: Node id: node date: 2018-04-12 -full_link: /zh/docs/concepts/architecture/nodes/ +full_link: /zh-cn/docs/concepts/architecture/nodes/ short_description: > A node is a worker machine in Kubernetes. diff --git a/content/zh-cn/docs/reference/glossary/object.md b/content/zh-cn/docs/reference/glossary/object.md index 99576b5665..0a5a07d10a 100644 --- a/content/zh-cn/docs/reference/glossary/object.md +++ b/content/zh-cn/docs/reference/glossary/object.md @@ -2,7 +2,7 @@ title: 对象（Object） id: object date: 2020-10-12 -full_link: /zh/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects +full_link: /zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects short_description: > Kubernetes 系统中的实体, 代表了集群的部分状态。 aka: From b7f8644d81b989cd68de78514baed04b0189b700 Mon Sep 17 00:00:00 2001 From: howieyuen Date: Thu, 23 Jun 2022 20:28:45 +0800 Subject: [PATCH 049/209] [zh]Update reference pages(part-3) for links with '/zh/' prefix, using new prefix '/zh-cn/' --- content/zh-cn/docs/reference/glossary/operator-pattern.md | 4 ++-- .../docs/reference/glossary/persistent-volume-claim.md | 2 +- content/zh-cn/docs/reference/glossary/persistent-volume.md | 2 +- content/zh-cn/docs/reference/glossary/platform-developer.md | 4 ++-- .../zh-cn/docs/reference/glossary/pod-disruption-budget.md | 4 ++-- content/zh-cn/docs/reference/glossary/pod-disruption.md | 2 +- content/zh-cn/docs/reference/glossary/pod-lifecycle.md | 4 ++-- content/zh-cn/docs/reference/glossary/pod-priority.md | 4 ++-- .../zh-cn/docs/reference/glossary/pod-security-policy.md | 4 ++-- content/zh-cn/docs/reference/glossary/preemption.md | 4 ++-- content/zh-cn/docs/reference/glossary/proxy.md | 2 +- content/zh-cn/docs/reference/glossary/rbac.md | 4 ++-- content/zh-cn/docs/reference/glossary/replica-set.md | 4 ++-- content/zh-cn/docs/reference/glossary/resource-quota.md | 4 ++-- content/zh-cn/docs/reference/glossary/secret.md | 6 +++--- content/zh-cn/docs/reference/glossary/security-context.md | 2 +- content/zh-cn/docs/reference/glossary/selector.md | 2 +- content/zh-cn/docs/reference/glossary/service-account.md | 2 +- content/zh-cn/docs/reference/glossary/service-broker.md | 2 +- content/zh-cn/docs/reference/glossary/service.md | 2 +- content/zh-cn/docs/reference/glossary/statefulset.md | 2 +- content/zh-cn/docs/reference/glossary/static-pod.md | 2 +- content/zh-cn/docs/reference/glossary/storage-class.md | 2 +- content/zh-cn/docs/reference/glossary/sysctl.md | 2 +- content/zh-cn/docs/reference/glossary/taint.md | 2 +- content/zh-cn/docs/reference/glossary/toleration.md | 2 +- content/zh-cn/docs/reference/glossary/uid.md | 2 +- content/zh-cn/docs/reference/glossary/volume.md | 4 ++-- content/zh-cn/docs/reference/glossary/workload.md | 2 +- 29 files changed, 42 insertions(+), 42 deletions(-) diff --git a/content/zh-cn/docs/reference/glossary/operator-pattern.md b/content/zh-cn/docs/reference/glossary/operator-pattern.md index c6da670257..21751ab4ab 100644 --- a/content/zh-cn/docs/reference/glossary/operator-pattern.md +++ b/content/zh-cn/docs/reference/glossary/operator-pattern.md @@ -2,7 +2,7 @@ title: Operator 模式 id: operator-pattern date: 2019-05-21 -full_link: /zh/docs/concepts/extend-kubernetes/operator/ +full_link: /zh-cn/docs/concepts/extend-kubernetes/operator/ short_description: > 一种用于管理自定义资源的专用控制器 @@ -28,7 +28,7 @@ The [operator pattern](/docs/concepts/extend-kubernetes/operator/) is a system design that links a {{< glossary_tooltip term_id="controller" >}} to one or more custom resources. --> -[operator 模式](/zh/docs/concepts/extend-kubernetes/operator/) 是一种系统设计, +[operator 模式](/zh-cn/docs/concepts/extend-kubernetes/operator/) 是一种系统设计, 将 {{< glossary_tooltip term_id="controller" >}} 关联到一个或多个自定义资源。 diff --git a/content/zh-cn/docs/reference/glossary/persistent-volume-claim.md b/content/zh-cn/docs/reference/glossary/persistent-volume-claim.md index f5ab57a3e8..4eb2e49e2b 100644 --- a/content/zh-cn/docs/reference/glossary/persistent-volume-claim.md +++ b/content/zh-cn/docs/reference/glossary/persistent-volume-claim.md @@ -2,7 +2,7 @@ title: 持久卷申领（Persistent Volume Claim） id: persistent-volume-claim date: 2018-04-12 -full_link: /zh/docs/concepts/storage/persistent-volumes/ +full_link: /zh-cn/docs/concepts/storage/persistent-volumes/ short_description: > 声明在持久卷中定义的存储资源，以便可以将其挂载为容器中的卷。 diff --git a/content/zh-cn/docs/reference/glossary/persistent-volume.md b/content/zh-cn/docs/reference/glossary/persistent-volume.md index 671e3a8bf3..8bcd24d6a8 100644 --- a/content/zh-cn/docs/reference/glossary/persistent-volume.md +++ b/content/zh-cn/docs/reference/glossary/persistent-volume.md @@ -2,7 +2,7 @@ title: 持久卷（Persistent Volume） id: persistent-volume date: 2018-04-12 -full_link: /zh/docs/concepts/storage/persistent-volumes/ +full_link: /zh-cn/docs/concepts/storage/persistent-volumes/ short_description: > 持久卷是代表集群中一块存储空间的 API 对象。 它是通用的、可插拔的、并且不受单个 Pod 生命周期约束的持久化资源。 diff --git a/content/zh-cn/docs/reference/glossary/platform-developer.md b/content/zh-cn/docs/reference/glossary/platform-developer.md index 41e8b99995..a03cf67d81 100644 --- a/content/zh-cn/docs/reference/glossary/platform-developer.md +++ b/content/zh-cn/docs/reference/glossary/platform-developer.md @@ -41,8 +41,8 @@ develop extensions which are contributed to the Kubernetes community. Others develop closed-source commercial or site-specific extensions. --> -平台开发人员可以使用[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) -或[使用汇聚层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +平台开发人员可以使用[定制资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +或[使用汇聚层扩展 Kubernetes API](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 来为其 Kubernetes 实例增加功能，特别是为其应用程序添加功能。 一些平台开发人员也是 kubernetes {{< glossary_tooltip text="贡献者" term_id="contributor" >}}， 他们会开发贡献给 Kubernetes 社区的扩展。 diff --git a/content/zh-cn/docs/reference/glossary/pod-disruption-budget.md b/content/zh-cn/docs/reference/glossary/pod-disruption-budget.md index 444bec87e3..32077d48cd 100644 --- a/content/zh-cn/docs/reference/glossary/pod-disruption-budget.md +++ b/content/zh-cn/docs/reference/glossary/pod-disruption-budget.md @@ -1,7 +1,7 @@ --- id: pod-disruption-budget title: Pod Disruption Budget -full-link: /zh/docs/concepts/workloads/pods/disruptions/ +full-link: /zh-cn/docs/concepts/workloads/pods/disruptions/ date: 2019-02-12 short_description: > Pod Disruption Budget 是这样一种对象：它保证在主动中断（ voluntary disruptions）时，多实例应用的 {{< glossary_tooltip text="Pod" term_id="pod" >}} 不会少于一定的数量。 @@ -43,7 +43,7 @@ tags: Involuntary disruptions cannot be prevented by PDBs; however they do count against the budget. --> - [Pod 干扰预算（Pod Disruption Budget，PDB）](/zh/docs/concepts/workloads/pods/disruptions/) + [Pod 干扰预算（Pod Disruption Budget，PDB）](/zh-cn/docs/concepts/workloads/pods/disruptions/) 使应用所有者能够为多实例应用创建一个对象，来确保一定数量的具有指定标签的 Pod 在任何时候都不会被主动驱逐。 PDB 无法防止非主动的中断，但是会计入预算（budget）。 diff --git a/content/zh-cn/docs/reference/glossary/pod-disruption.md b/content/zh-cn/docs/reference/glossary/pod-disruption.md index 5ea9d70b10..39b8ce8d83 100644 --- a/content/zh-cn/docs/reference/glossary/pod-disruption.md +++ b/content/zh-cn/docs/reference/glossary/pod-disruption.md @@ -37,7 +37,7 @@ tags: Pods on Nodes are terminated either voluntarily or involuntarily. --> -[pod 干扰](/zh/docs/concepts/workloads/pods/disruptions/) 是指节点上的 pod 被自愿或非自愿终止的过程。 +[pod 干扰](/zh-cn/docs/concepts/workloads/pods/disruptions/) 是指节点上的 pod 被自愿或非自愿终止的过程。 diff --git a/content/zh-cn/docs/reference/glossary/pod-lifecycle.md b/content/zh-cn/docs/reference/glossary/pod-lifecycle.md index d83ca39ad0..8eff328c4d 100644 --- a/content/zh-cn/docs/reference/glossary/pod-lifecycle.md +++ b/content/zh-cn/docs/reference/glossary/pod-lifecycle.md @@ -2,7 +2,7 @@ title: Pod 生命周期 id: pod-lifecycle date: 2019-02-17 -full-link: /zh/docs/concepts/workloads/pods/pod-lifecycle/ +full-link: /zh-cn/docs/concepts/workloads/pods/pod-lifecycle/ related: - pod - container @@ -36,7 +36,7 @@ A high-level summary of what phase the Pod is in within its lifecyle. -[Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 是关于 Pod +[Pod 生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/) 是关于 Pod 处于哪个阶段的概述。包含了下面5种可能的的阶段: Running、Pending、Succeeded、 Failed、Unknown。关于 Pod 的阶段的更高级描述请查阅 [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) `phase` 字段。 diff --git a/content/zh-cn/docs/reference/glossary/pod-priority.md b/content/zh-cn/docs/reference/glossary/pod-priority.md index d029d0593c..1ddc48e1a8 100644 --- a/content/zh-cn/docs/reference/glossary/pod-priority.md +++ b/content/zh-cn/docs/reference/glossary/pod-priority.md @@ -2,7 +2,7 @@ title: Pod 优先级（Pod Priority） id: pod-priority date: 2019-01-31 -full_link: /zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority +full_link: /zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority short_description: > Pod 优先级表示一个 Pod 相对于其他 Pod 的重要性。 @@ -34,7 +34,7 @@ tags: -[Pod 优先级](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority) +[Pod 优先级](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority) 允许用户为 Pod 设置高于或低于其他 Pod 的优先级 -- 这对于生产集群 工作负载而言是一个重要的特性。 diff --git a/content/zh-cn/docs/reference/glossary/pod-security-policy.md b/content/zh-cn/docs/reference/glossary/pod-security-policy.md index f80416fb44..db49173930 100644 --- a/content/zh-cn/docs/reference/glossary/pod-security-policy.md +++ b/content/zh-cn/docs/reference/glossary/pod-security-policy.md @@ -2,7 +2,7 @@ title: Pod 安全策略 id: pod-security-policy date: 2018-04-12 -full_link: /zh/docs/concepts/security/pod-security-policy/ +full_link: /zh-cn/docs/concepts/security/pod-security-policy/ short_description: > 为 Pod 的创建和更新操作启用细粒度的授权。 @@ -47,5 +47,5 @@ Pod 安全策略是集群级别的资源，它控制着 Pod 规约中的安全 PodSecurityPolicy is deprecated as of Kubernetes v1.21, and will be removed in v1.25. We recommend migrating to [Pod Security Admission](/docs/concepts/security/pod-security-admission/), or a 3rd party admission plugin. --> PodSecurityPolicy 自 Kubernetes v1.21 起已弃用，并将在 v1.25 中删除。 -我们建议迁移到 [Pod 安全准入](/zh/docs/concepts/security/pod-security-admission/)或第三方准入插件。 +我们建议迁移到 [Pod 安全准入](/zh-cn/docs/concepts/security/pod-security-admission/)或第三方准入插件。 diff --git a/content/zh-cn/docs/reference/glossary/preemption.md b/content/zh-cn/docs/reference/glossary/preemption.md index 328d0abfac..7875e60d0b 100644 --- a/content/zh-cn/docs/reference/glossary/preemption.md +++ b/content/zh-cn/docs/reference/glossary/preemption.md @@ -2,7 +2,7 @@ title: 抢占（Preemption） id: preemption date: 2019-01-31 -full_link: /zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption +full_link: /zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption short_description: > Kubernetes 中的抢占逻辑通过驱逐节点上的低优先级 Pod 来帮助悬决的 Pod 找到合适的节点。 @@ -37,6 +37,6 @@ Kubernetes 中的抢占逻辑通过驱逐{{< glossary_tooltip term_id="node" >}} If a Pod cannot be scheduled, the scheduler tries to [preempt](/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption) lower priority Pods to make scheduling of the pending Pod possible. --> 如果一个 Pod 无法调度，调度器会尝试 -[抢占](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption) +[抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption) 较低优先级的 Pod，以使得悬决的 Pod 有可能被调度。 diff --git a/content/zh-cn/docs/reference/glossary/proxy.md b/content/zh-cn/docs/reference/glossary/proxy.md index c9d4ff0bea..b186dd6065 100644 --- a/content/zh-cn/docs/reference/glossary/proxy.md +++ b/content/zh-cn/docs/reference/glossary/proxy.md @@ -43,7 +43,7 @@ actual server's reply to the client. network proxy that runs on each node in your cluster, implementing part of the Kubernetes {{< glossary_tooltip term_id="service">}} concept. --> -[kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/) 是集群中每个节点上运行的网络代理，实现了部分 Kubernetes {{< glossary_tooltip term_id="service">}} 概念。 +[kube-proxy](/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/) 是集群中每个节点上运行的网络代理，实现了部分 Kubernetes {{< glossary_tooltip term_id="service">}} 概念。 -更多信息可参考[storage](/zh/docs/concepts/storage/) \ No newline at end of file +更多信息可参考[storage](/zh-cn/docs/concepts/storage/) \ No newline at end of file diff --git a/content/zh-cn/docs/reference/glossary/workload.md b/content/zh-cn/docs/reference/glossary/workload.md index 394b42bd1c..68cd860a83 100644 --- a/content/zh-cn/docs/reference/glossary/workload.md +++ b/content/zh-cn/docs/reference/glossary/workload.md @@ -2,7 +2,7 @@ title: 工作负载（Workload） id: workloads date: 2019-02-13 -full_link: /zh/docs/concepts/workloads/ +full_link: /zh-cn/docs/concepts/workloads/ short_description: > 工作负载是在 Kubernetes 上运行的应用程序。 From e5913a70a5d38054ebe5f1f10d7915b3cd42d022 Mon Sep 17 00:00:00 2001 From: howieyuen Date: Thu, 23 Jun 2022 19:59:48 +0800 Subject: [PATCH 050/209] [zh]Update reference pages(part-4) for links with '/zh/' prefix, using new prefix '/zh-cn/' --- .../docs/reference/issues-security/issues.md | 4 +- .../reference/issues-security/security.md | 2 +- .../zh-cn/docs/reference/kubectl/_index.md | 32 ++++---- .../docs/reference/kubectl/cheatsheet.md | 16 ++-- .../docs/reference/kubectl/conventions.md | 2 +- .../kubectl/docker-cli-to-kubectl.md | 12 +-- .../zh-cn/docs/reference/kubectl/kubectl.md | 2 +- .../service-account-v1.md | 4 +- .../local-object-reference.md | 2 +- .../config-and-storage-resources/secret-v1.md | 4 +- .../labels-annotations-taints/_index.md | 80 +++++++++---------- .../audit-annotations.md | 18 ++--- ...-dockershim-and-cri-compatible-runtimes.md | 8 +- .../docs/reference/ports-and-protocols.md | 2 +- .../zh-cn/docs/reference/scheduling/config.md | 28 +++---- .../docs/reference/scheduling/policies.md | 10 +-- 16 files changed, 113 insertions(+), 113 deletions(-) diff --git a/content/zh-cn/docs/reference/issues-security/issues.md b/content/zh-cn/docs/reference/issues-security/issues.md index 0cad3c4329..45a248990c 100644 --- a/content/zh-cn/docs/reference/issues-security/issues.md +++ b/content/zh-cn/docs/reference/issues-security/issues.md @@ -1,7 +1,7 @@ --- title: Kubernetes 问题追踪 weight: 10 -aliases: [/zh/cve/, /zh/cves/] +aliases: [/zh-cn/cve/, /zh-cn/cves/] --- 要报告安全问题，请遵循 -[Kubernetes 安全问题公开流程](/zh/docs/reference/issues-security/security/#report-a-vulnerability)。 +[Kubernetes 安全问题公开流程](/zh-cn/docs/reference/issues-security/security/#report-a-vulnerability)。 `针对配置信息，`kubectl` 在 `$HOME/.kube` 目录中查找一个名为 `config` 的配置文件。 你可以通过设置 `KUBECONFIG` 环境变量或设置 -[`--kubeconfig`](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) -参数来指定其它 [kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 文件。 +[`--kubeconfig`](/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +参数来指定其它 [kubeconfig](/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 文件。 -有关安装说明，请参见[安装 kubectl](/zh/docs/tasks/tools/#kubectl)； -如需快速指南，请参见[备忘单](/zh/docs/reference/kubectl/cheatsheet/)。 +有关安装说明，请参见[安装 kubectl](/zh-cn/docs/tasks/tools/#kubectl)； +如需快速指南，请参见[备忘单](/zh-cn/docs/reference/kubectl/cheatsheet/)。 如果你更习惯使用 `docker` 命令行工具， -[Docker 用户的 `kubectl`](/zh/docs/reference/kubectl/docker-cli-to-kubectl/) +[Docker 用户的 `kubectl`](/zh-cn/docs/reference/kubectl/docker-cli-to-kubectl/) 介绍了一些 Kubernetes 的等价命令。 @@ -131,7 +131,7 @@ for example `create`, `get`, `describe`, `delete`. * 用一个或多个文件指定资源：`-f file1 -f file2 -f file<#>` - * [使用 YAML 而不是 JSON](/zh/docs/concepts/configuration/overview/#general-configuration-tips)， + * [使用 YAML 而不是 JSON](/zh-cn/docs/concepts/configuration/overview/#general-configuration-tips)， 因为 YAML 对用户更友好, 特别是对于配置文件。
例子：`kubectl get -f ./pod.yaml` @@ -341,7 +341,7 @@ Operation | Syntax | Description To learn more about command operations, see the [kubectl](/docs/reference/kubectl/kubectl/) reference documentation. --> 了解更多有关命令操作的信息， -请参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。 +请参阅 [kubectl](/zh-cn/docs/reference/kubectl/kubectl/) 参考文档。 有关如何格式化或排序某些命令的输出的信息，请参阅以下章节。有关哪些命令支持不同输出选项的详细信息， -请参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。 +请参阅 [kubectl](/zh-cn/docs/reference/kubectl/kubectl/) 参考文档。 请记住：有关每个命令支持哪种输出格式的详细信息， -请参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。 +请参阅 [kubectl](/zh-cn/docs/reference/kubectl/kubectl/) 参考文档。 要将对象排序后输出到终端窗口，可以将 `--sort-by` 参数添加到支持的 `kubectl` 命令。 通过使用 `--sort-by` 参数指定任何数字或字符串字段来对对象进行排序。 -要指定字段，请使用 [jsonpath](/zh/docs/reference/kubectl/jsonpath/) 表达式。 +要指定字段，请使用 [jsonpath](/zh-cn/docs/reference/kubectl/jsonpath/) 表达式。 * 阅读 `kubectl` 参考文档： - * kubectl [命令参考](/zh/docs/reference/kubectl/kubectl/) + * kubectl [命令参考](/zh-cn/docs/reference/kubectl/kubectl/) * 参考[命令行参数](/docs/reference/generated/kubectl/kubectl-commands/) -* 学习关于 [`kubectl` 使用约定](/zh/docs/reference/kubectl/conventions/) -* 阅读 kubectl 中的 [JSONPath 支持](/zh/docs/reference/kubectl/jsonpath/) -* 了解如何[使用插件扩展 kubectl](/zh/docs/tasks/extend-kubectl/kubectl-plugins) +* 学习关于 [`kubectl` 使用约定](/zh-cn/docs/reference/kubectl/conventions/) +* 阅读 kubectl 中的 [JSONPath 支持](/zh-cn/docs/reference/kubectl/jsonpath/) +* 了解如何[使用插件扩展 kubectl](/zh-cn/docs/tasks/extend-kubectl/kubectl-plugins) * 查看更多[示例 cli 插件](https://github.com/kubernetes/sample-cli-plugin)。 \ No newline at end of file diff --git a/content/zh-cn/docs/reference/kubectl/cheatsheet.md b/content/zh-cn/docs/reference/kubectl/cheatsheet.md index 9ea9111fd3..a20e05c713 100644 --- a/content/zh-cn/docs/reference/kubectl/cheatsheet.md +++ b/content/zh-cn/docs/reference/kubectl/cheatsheet.md @@ -94,7 +94,7 @@ detailed config file information. ## Kubectl 上下文和配置 设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。 -查看[使用 kubeconfig 跨集群授权访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +查看[使用 kubeconfig 跨集群授权访问](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文档获取配置文件详细信息。 -列出所支持的全部资源类型和它们的简称、[API 组](/zh/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning), 是否是[名字空间作用域](/zh/docs/concepts/overview/working-with-objects/namespaces) 和 [Kind](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects)。 +列出所支持的全部资源类型和它们的简称、[API 组](/zh-cn/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning), 是否是[名字空间作用域](/zh-cn/docs/concepts/overview/working-with-objects/namespaces) 和 [Kind](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects)。 ```bash kubectl api-resources @@ -846,8 +846,8 @@ Output format | Description `-o=custom-columns=` | 使用逗号分隔的自定义列来打印表格 `-o=custom-columns-file=` | 使用 `` 文件中的自定义列模板打印表格 `-o=json` | 输出 JSON 格式的 API 对象 -`-o=jsonpath=