diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 296e743a8450d..443410ae561eb 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -200,6 +200,7 @@ aliases: - devlware - jhonmike - rikatz + - stormqueen1990 - yagonobre sig-docs-vi-owners: # Admins for Vietnamese content - huynguyennovem diff --git a/README-zh.md b/README-zh.md index 5f0f83c80feb7..0b9dfc1ce70df 100644 --- a/README-zh.md +++ b/README-zh.md @@ -257,6 +257,51 @@ This works for Catalina as well as Mojave macOS. --> 这适用于 Catalina 和 Mojave macOS。 +### 对执行 make container-image 命令部分地区访问超时的故障排除 + +现象如下: + +```shell +langs/language.go:23:2: golang.org/x/text@v0.3.7: Get "https://proxy.golang.org/golang.org/x/text/@v/v0.3.7.zip": dial tcp 142.251.43.17:443: i/o timeout +langs/language.go:24:2: golang.org/x/text@v0.3.7: Get "https://proxy.golang.org/golang.org/x/text/@v/v0.3.7.zip": dial tcp 142.251.43.17:443: i/o timeout +common/text/transform.go:21:2: golang.org/x/text@v0.3.7: Get "https://proxy.golang.org/golang.org/x/text/@v/v0.3.7.zip": dial tcp 142.251.43.17:443: i/o timeout +common/text/transform.go:22:2: golang.org/x/text@v0.3.7: Get "https://proxy.golang.org/golang.org/x/text/@v/v0.3.7.zip": dial tcp 142.251.43.17:443: i/o timeout +common/text/transform.go:23:2: golang.org/x/text@v0.3.7: Get "https://proxy.golang.org/golang.org/x/text/@v/v0.3.7.zip": dial tcp 142.251.43.17:443: i/o timeout +hugolib/integrationtest_builder.go:29:2: golang.org/x/tools@v0.1.11: Get "https://proxy.golang.org/golang.org/x/tools/@v/v0.1.11.zip": dial tcp 142.251.42.241:443: i/o timeout +deploy/google.go:24:2: google.golang.org/api@v0.76.0: Get "https://proxy.golang.org/google.golang.org/api/@v/v0.76.0.zip": dial tcp 142.251.43.17:443: i/o timeout +parser/metadecoders/decoder.go:32:2: gopkg.in/yaml.v2@v2.4.0: Get "https://proxy.golang.org/gopkg.in/yaml.v2/@v/v2.4.0.zip": dial tcp 142.251.42.241:443: i/o timeout +The command '/bin/sh -c mkdir $HOME/src && cd $HOME/src && curl -L https://github.com/gohugoio/hugo/archive/refs/tags/v${HUGO_VERSION}.tar.gz | tar -xz && cd "hugo-${HUGO_VERS ION}" && go install --tags extended' returned a non-zero code: 1 +make: *** [Makefile:69:container-image] error 1 +``` + +请修改 `Dockerfile` 文件,为其添加网络代理。修改内容如下: + +```dockerfile +... +FROM golang:1.18-alpine + +LABEL maintainer="Luc Perkins " + +ENV GO111MODULE=on # 需要添加内容1 + +ENV GOPROXY=https://proxy.golang.org,direct # 需要添加内容2 + +RUN apk add --no-cache \ + curl \ + gcc \ + g++ \ + musl-dev \ + build-base \ + libc6-compat + +ARG HUGO_VERSION +... +``` + +将 "https://proxy.golang.org" 替换为本地可以使用的代理地址。 + +**注意:** 此部分仅适用于中国大陆 + -Der Horizontal Pod Autoscaler skaliert automatisch die Anzahl der Pods eines Replication Controller, Deployment oder Replikat Set basierend auf der beobachteten CPU-Auslastung (oder, mit Unterstützung von [benutzerdefinierter Metriken](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md), von der Anwendung bereitgestellten Metriken). Beachte, dass die horizontale Pod Autoskalierung nicht für Objekte gilt, die nicht skaliert werden können, z. B. DaemonSets. +Der Horizontal Pod Autoscaler skaliert automatisch die Anzahl der Pods eines Replication Controller, Deployment oder Replikat Set basierend auf der beobachteten CPU-Auslastung (oder, mit Unterstützung von [benutzerdefinierter Metriken](https://git.k8s.io/design-proposals-archive/instrumentation/custom-metrics-api.md), von der Anwendung bereitgestellten Metriken). Beachte, dass die horizontale Pod Autoskalierung nicht für Objekte gilt, die nicht skaliert werden können, z. B. DaemonSets. Der Horizontal Pod Autoscaler ist als Kubernetes API-Ressource und einem Controller implementiert. Die Ressource bestimmt das Verhalten des Controllers. @@ -46,7 +46,7 @@ Das Verwenden von Metriken aus Heapster ist seit der Kubernetes Version 1.11 ver Siehe [Unterstützung der Metrik APIs](#unterstützung-der-metrik-apis) für weitere Details. -Der Autoscaler greift über die Scale Sub-Ressource auf die entsprechenden skalierbaren Controller (z.B. Replication Controller, Deployments und Replika Sets) zu. Scale ist eine Schnittstelle, mit der Sie die Anzahl der Replikate dynamisch einstellen und jeden ihrer aktuellen Zustände untersuchen können. Weitere Details zu der Scale Sub-Ressource findest du [hier](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource). +Der Autoscaler greift über die Scale Sub-Ressource auf die entsprechenden skalierbaren Controller (z.B. Replication Controller, Deployments und Replika Sets) zu. Scale ist eine Schnittstelle, mit der Sie die Anzahl der Replikate dynamisch einstellen und jeden ihrer aktuellen Zustände untersuchen können. Weitere Details zu der Scale Sub-Ressource findest du [hier](https://git.k8s.io/design-proposals-archive/autoscaling/horizontal-pod-autoscaler.md#scale-subresource). ### Details zum Algorithmus @@ -90,7 +90,7 @@ Die aktuelle stabile Version, die nur die Unterstützung für die automatische S Die Beta-Version, welche die Skalierung des Speichers und benutzerdefinierte Metriken unterstützt, befindet sich unter `autoscaling/v2beta2`. Die in `autoscaling/v2beta2` neu eingeführten Felder bleiben bei der Arbeit mit `autoscaling/v1` als Anmerkungen erhalten. -Weitere Details über das API Objekt kann unter dem [HorizontalPodAutoscaler Objekt](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object) gefunden werden. +Weitere Details über das API Objekt kann unter dem [HorizontalPodAutoscaler Objekt](https://git.k8s.io/design-proposals-archive/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object) gefunden werden. ## Unterstützung des Horizontal Pod Autoscaler in kubectl @@ -166,7 +166,7 @@ Standardmäßig ruft der HorizontalPodAutoscaler Controller Metriken aus einer R ## {{% heading "whatsnext" %}} -* Design Dokument [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md). +* Design Dokument [Horizontal Pod Autoscaling](https://git.k8s.io/design-proposals-archive/autoscaling/horizontal-pod-autoscaler.md). * kubectl autoscale Befehl: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). * Verwenden des [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). diff --git a/content/en/blog/_posts/2022-07-13-gateway-api-in-beta.md b/content/en/blog/_posts/2022-07-13-gateway-api-in-beta.md new file mode 100644 index 0000000000000..54457cd3366b2 --- /dev/null +++ b/content/en/blog/_posts/2022-07-13-gateway-api-in-beta.md @@ -0,0 +1,178 @@ +--- +layout: blog +title: Kubernetes Gateway API Graduates to Beta +date: 2022-07-13 +slug: gateway-api-graduates-to-beta +canonicalUrl: https://gateway-api.sigs.k8s.io/blog/2022/graduating-to-beta/ +--- + +**Authors:** Shane Utt (Kong), Rob Scott (Google), Nick Young (VMware), Jeff Apple (HashiCorp) + +We are excited to announce the v0.5.0 release of Gateway API. For the first +time, several of our most important Gateway API resources are graduating to +beta. Additionally, we are starting a new initiative to explore how Gateway API +can be used for mesh and introducing new experimental concepts such as URL +rewrites. We'll cover all of this and more below. + +## What is Gateway API? + +Gateway API is a collection of resources centered around [Gateway][gw] resources +(which represent the underlying network gateways / proxy servers) to enable +robust Kubernetes service networking through expressive, extensible and +role-oriented interfaces that are implemented by many vendors and have broad +industry support. + +Originally conceived as a successor to the well known [Ingress][ing] API, the +benefits of Gateway API include (but are not limited to) explicit support for +many commonly used networking protocols (e.g. `HTTP`, `TLS`, `TCP`, `UDP`) as +well as tightly integrated support for Transport Layer Security (TLS). The +`Gateway` resource in particular enables implementations to manage the lifecycle +of network gateways as a Kubernetes API. + +If you're an end-user interested in some of the benefits of Gateway API we +invite you to jump in and find an implementation that suits you. At the time of +this release there are over a dozen [implementations][impl] for popular API +gateways and service meshes and guides are available to start exploring quickly. + +[gw]:https://gateway-api.sigs.k8s.io/api-types/gateway/ +[ing]:https://kubernetes.io/docs/reference/kubernetes-api/service-resources/ingress-v1/ +[impl]:https://gateway-api.sigs.k8s.io/implementations/ + +### Getting started + +Gateway API is an official Kubernetes API like +[Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/). +Gateway API represents a superset of Ingress functionality, enabling more +advanced concepts. Similar to Ingress, there is no default implementation of +Gateway API built into Kubernetes. Instead, there are many different +[implementations][impl] available, providing significant choice in terms of underlying +technologies while providing a consistent and portable experience. + +Take a look at the [API concepts documentation][concepts] and check out some of +the [Guides][guides] to start familiarizing yourself with the APIs and how they +work. When you're ready for a practical application open the [implementations +page][impl] and select an implementation that belongs to an existing technology +you may already be familiar with or the one your cluster provider uses as a +default (if applicable). Gateway API is a [Custom Resource Definition +(CRD)][crd] based API so you'll need to [install the CRDs][install-crds] onto a +cluster to use the API. + +If you're specifically interested in helping to contribute to Gateway API, we +would love to have you! Please feel free to [open a new issue][issue] on the +repository, or join in the [discussions][disc]. Also check out the [community +page][community] which includes links to the Slack channel and community meetings. + +[crd]:https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ +[concepts]:https://gateway-api.sigs.k8s.io/concepts/api-overview/ +[guides]:https://gateway-api.sigs.k8s.io/guides/getting-started/ +[impl]:https://gateway-api.sigs.k8s.io/implementations/ +[install-crds]:https://gateway-api.sigs.k8s.io/guides/getting-started/#install-the-crds +[issue]:https://github.com/kubernetes-sigs/gateway-api/issues/new/choose +[disc]:https://github.com/kubernetes-sigs/gateway-api/discussions +[community]:https://gateway-api.sigs.k8s.io/contributing/community/ + +## Release highlights + +### Graduation to beta + +The `v0.5.0` release is particularly historic because it marks the growth in +maturity to a beta API version (`v1beta1`) release for some of the key APIs: + +- [GatewayClass](https://gateway-api.sigs.k8s.io/api-types/gatewayclass/) +- [Gateway](https://gateway-api.sigs.k8s.io/api-types/gateway/) +- [HTTPRoute](https://gateway-api.sigs.k8s.io/api-types/httproute/) + +This achievement was marked by the completion of several graduation criteria: + +- API has been [widely implemented][impl]. +- Conformance tests provide basic coverage for all resources and have multiple implementations passing tests. +- Most of the API surface is actively being used. +- Kubernetes SIG Network API reviewers have approved graduation to beta. + +For more information on Gateway API versioning, refer to the [official +documentation](https://gateway-api.sigs.k8s.io/concepts/versioning/). To see +what's in store for future releases check out the [next steps](#next-steps) +section. + +[impl]:https://gateway-api.sigs.k8s.io/implementations/ + +### Release channels + +This release introduces the `experimental` and `standard` [release channels][ch] +which enable a better balance of maintaining stability while still enabling +experimentation and iterative development. + +The `standard` release channel includes: + +- resources that have graduated to beta +- fields that have graduated to standard (no longer considered experimental) + +The `experimental` release channel includes everything in the `standard` release +channel, plus: + +- `alpha` API resources +- fields that are considered experimental and have not graduated to `standard` channel + +Release channels are used internally to enable iterative development with +quick turnaround, and externally to indicate feature stability to implementors +and end-users. + +For this release we've added the following experimental features: + +- [Routes can attach to Gateways by specifying port numbers](https://gateway-api.sigs.k8s.io/geps/gep-957/) +- [URL rewrites and path redirects](https://gateway-api.sigs.k8s.io/geps/gep-726/) + +[ch]:https://gateway-api.sigs.k8s.io/concepts/versioning/#release-channels-eg-experimental-standard + +### Other improvements + +For an exhaustive list of changes included in the `v0.5.0` release, please see +the [v0.5.0 release notes](https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.5.0). + +## Gateway API for service mesh: the GAMMA Initiative +Some service mesh projects have [already implemented support for the Gateway +API](https://gateway-api.sigs.k8s.io/implementations/). Significant overlap +between the Service Mesh Interface (SMI) APIs and the Gateway API has [inspired +discussion in the SMI +community](https://github.com/servicemeshinterface/smi-spec/issues/249) about +possible integration. + +We are pleased to announce that the service mesh community, including +representatives from Cilium Service Mesh, Consul, Istio, Kuma, Linkerd, NGINX +Service Mesh and Open Service Mesh, is coming together to form the [GAMMA +Initiative](https://gateway-api.sigs.k8s.io/contributing/gamma/), a dedicated +workstream within the Gateway API subproject focused on Gateway API for Mesh +Management and Administration. + +This group will deliver [enhancement +proposals](https://gateway-api.sigs.k8s.io/v1beta1/contributing/gep/) consisting +of resources, additions, and modifications to the Gateway API specification for +mesh and mesh-adjacent use-cases. + +This work has begun with [an exploration of using Gateway API for +service-to-service +traffic](https://docs.google.com/document/d/1T_DtMQoq2tccLAtJTpo3c0ohjm25vRS35MsestSL9QU/edit#heading=h.jt37re3yi6k5) +and will continue with enhancement in areas such as authentication and +authorization policy. + +## Next steps + +As we continue to mature the API for production use cases, here are some of the highlights of what we'll be working on for the next Gateway API releases: + +- [GRPCRoute][gep1016] for [gRPC][grpc] traffic routing +- [Route delegation][pr1085] +- Layer 4 API maturity: Graduating [TCPRoute][tcpr], [UDPRoute][udpr] and + [TLSRoute][tlsr] to beta +- [GAMMA Initiative](https://gateway-api.sigs.k8s.io/contributing/gamma/) - Gateway API for Service Mesh + +If there's something on this list you want to get involved in, or there's +something not on this list that you want to advocate for to get on the roadmap +please join us in the #sig-network-gateway-api channel on Kubernetes Slack or our weekly [community calls](https://gateway-api.sigs.k8s.io/contributing/community/#meetings). + +[gep1016]:https://github.com/kubernetes-sigs/gateway-api/blob/master/site-src/geps/gep-1016.md +[grpc]:https://grpc.io/ +[pr1085]:https://github.com/kubernetes-sigs/gateway-api/pull/1085 +[tcpr]:https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/tcproute_types.go +[udpr]:https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/udproute_types.go +[tlsr]:https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/tlsroute_types.go +[community]:https://gateway-api.sigs.k8s.io/contributing/community/ diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md index 538372b2f4593..9428da09e3124 100644 --- a/content/en/docs/concepts/configuration/manage-resources-containers.md +++ b/content/en/docs/concepts/configuration/manage-resources-containers.md @@ -332,7 +332,7 @@ container of a Pod can specify either or both of the following: Limits and requests for `ephemeral-storage` are measured in byte quantities. You can express storage as a plain integer or as a fixed-point number using one of these suffixes: -E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi, +E, P, T, G, M, k. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi, Mi, Ki. For example, the following quantities all represent roughly the same value: - `128974848` @@ -340,6 +340,10 @@ Mi, Ki. For example, the following quantities all represent roughly the same val - `129M` - `123Mi` +Pay attention to the case of the suffixes. If you request `400m` of ephemeral-storage, this is a request +for 0.4 bytes. Someone who types that probably meant to ask for 400 mebibytes (`400Mi`) +or 400 megabytes (`400M`). + In the following example, the Pod has two containers. Each container has a request of 2GiB of local ephemeral storage. Each container has a limit of 4GiB of local ephemeral storage. Therefore, the Pod has a request of 4GiB of local ephemeral storage, and diff --git a/content/en/docs/concepts/scheduling-eviction/node-pressure-eviction.md b/content/en/docs/concepts/scheduling-eviction/node-pressure-eviction.md index 78835c3a7dd27..a7724c83d9c4a 100644 --- a/content/en/docs/concepts/scheduling-eviction/node-pressure-eviction.md +++ b/content/en/docs/concepts/scheduling-eviction/node-pressure-eviction.md @@ -85,11 +85,15 @@ The kubelet supports the following filesystem partitions: Kubelet auto-discovers these filesystems and ignores other filesystems. Kubelet does not support other configurations. -{{}} -Some kubelet garbage collection features are deprecated in favor of eviction. -For a list of the deprecated features, see -[kubelet garbage collection deprecation](/docs/concepts/architecture/garbage-collection/#deprecation). -{{}} +Some kubelet garbage collection features are deprecated in favor of eviction: + +| Existing Flag | New Flag | Rationale | +| ------------- | -------- | --------- | +| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection | +| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior | +| `--maximum-dead-containers` | | deprecated once old logs are stored outside of container's context | +| `--maximum-dead-containers-per-container` | | deprecated once old logs are stored outside of container's context | +| `--minimum-container-ttl-duration` | | deprecated once old logs are stored outside of container's context | ### Eviction thresholds diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index 66aa8f7f8a860..07521f42eec68 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -558,7 +558,7 @@ If the access modes are specified as ReadWriteOncePod, the volume is constrained | AzureFile | ✓ | ✓ | ✓ | - | | AzureDisk | ✓ | - | - | - | | CephFS | ✓ | ✓ | ✓ | - | -| Cinder | ✓ | - | - | - | +| Cinder | ✓ | - | ([if multi-attach volumes are available](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/features.md#multi-attach-volumes)) | - | | CSI | depends on the driver | depends on the driver | depends on the driver | depends on the driver | | FC | ✓ | ✓ | - | - | | FlexVolume | ✓ | ✓ | depends on the driver | - | diff --git a/content/en/docs/concepts/storage/projected-volumes.md b/content/en/docs/concepts/storage/projected-volumes.md index df67132cf599f..a404a26e5e05a 100644 --- a/content/en/docs/concepts/storage/projected-volumes.md +++ b/content/en/docs/concepts/storage/projected-volumes.md @@ -73,7 +73,7 @@ volume mount will not receive updates for those volume sources. ## SecurityContext interactions -The [proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#proposal) for file permission handling in projected service account volume enhancement introduced the projected files having the the correct owner permissions set. +The [proposal](https://git.k8s.io/enhancements/keps/sig-storage/2451-service-account-token-volumes#proposal) for file permission handling in projected service account volume enhancement introduced the projected files having the correct owner permissions set. ### Linux @@ -99,6 +99,7 @@ into their own volume mount outside of `C:\`. By default, the projected files will have the following ownership as shown for an example projected volume file: + ```powershell PS C:\> Get-Acl C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt | Format-List @@ -111,6 +112,7 @@ Access : NT AUTHORITY\SYSTEM Allow FullControl Audit : Sddl : O:BAG:SYD:AI(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;0x1200a9;;;BU) ``` + This implies all administrator users like `ContainerAdministrator` will have read, write and execute access while, non-administrator users will have read and execute access. diff --git a/content/en/docs/concepts/windows/intro.md b/content/en/docs/concepts/windows/intro.md index a78a849931c42..f3867ea86cdc4 100644 --- a/content/en/docs/concepts/windows/intro.md +++ b/content/en/docs/concepts/windows/intro.md @@ -132,7 +132,7 @@ section refers to several key workload abstractions and how they map to Windows. * CronJob * ReplicationController * {{< glossary_tooltip text="Services" term_id="service" >}} - See [Load balancing and Services](#load-balancing-and-services) for more details. + See [Load balancing and Services](/docs/concepts/services-networking/windows-networking/#load-balancing-and-services) for more details. Pods, workload resources, and Services are critical elements to managing Windows workloads on Kubernetes. However, on their own they are not enough to enable diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md index 9d917505dee8a..b4ab6f72717d0 100644 --- a/content/en/docs/concepts/workloads/controllers/job.md +++ b/content/en/docs/concepts/workloads/controllers/job.md @@ -71,7 +71,7 @@ Pod Template: job-name=pi Containers: pi: - Image: perl + Image: perl:5.34.0 Port: Host Port: Command: @@ -125,7 +125,7 @@ spec: - -Mbignum=bpi - -wle - print bpi(2000) - image: perl + image: perl:5.34.0 imagePullPolicy: Always name: pi resources: {} @@ -356,7 +356,7 @@ spec: spec: containers: - name: pi - image: perl + image: perl:5.34.0 command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] restartPolicy: Never ``` @@ -402,7 +402,7 @@ spec: spec: containers: - name: pi - image: perl + image: perl:5.34.0 command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] restartPolicy: Never ``` 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 2989535ead9b8..50b5a00608e23 100644 --- a/content/en/docs/contribute/new-content/open-a-pr.md +++ b/content/en/docs/contribute/new-content/open-a-pr.md @@ -216,16 +216,16 @@ Figure 2. Working from a local fork to make your changes. 1. Decide which branch base to your work on: - - 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 long-running efforts that multiple SIG Docs contributors collaborate on, - like content reorganization, use a specific feature branch created for that effort. + - 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 long-running efforts that multiple SIG Docs contributors collaborate on, + 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. + If you need help choosing a branch, ask in the `#sig-docs` Slack channel. 1. Create a new branch based on the branch identified in step 1. This example assumes the base branch is `upstream/main`: @@ -234,7 +234,7 @@ Figure 2. Working from a local fork to make your changes. git checkout -b upstream/main ``` -3. Make your changes using a text editor. +1. Make your changes using a text editor. At any time, use the `git status` command to see what files you've changed. @@ -396,7 +396,7 @@ Figure 3. Steps to open a PR from your fork to the K8s/website. 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: +1. 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. @@ -484,10 +484,10 @@ conflict. You must resolve all merge conflicts in your PR. 1. Fetch changes from `kubernetes/website`'s `upstream/main` and rebase your branch: - ```shell - git fetch upstream - git rebase upstream/main - ``` + ```shell + git fetch upstream + git rebase upstream/main + ``` 1. Inspect the results of the rebase: @@ -512,7 +512,7 @@ conflict. You must resolve all merge conflicts in your PR. 1. Continue the rebase: - `` + ```shell git rebase --continue ``` diff --git a/content/en/docs/contribute/review/reviewing-prs.md b/content/en/docs/contribute/review/reviewing-prs.md index 54b209dc0e24e..41aaecea1719a 100644 --- a/content/en/docs/contribute/review/reviewing-prs.md +++ b/content/en/docs/contribute/review/reviewing-prs.md @@ -10,9 +10,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. -Reviewing documentation pull requests is a -great way to introduce yourself to the Kubernetes community. -It helps you learn the code base and build trust with other contributors. +Reviewing documentation pull requests is a great way to introduce yourself to the Kubernetes +community. It helps you learn the code base and build trust with other contributors. Before reviewing, it's a good idea to: @@ -28,7 +27,6 @@ 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. - Be polite, considerate, and helpful. @@ -73,6 +71,7 @@ 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. @@ -103,12 +102,20 @@ Figure 1. Review process steps. 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. 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**. + a summary of your review (and leave some positive comments for the contributor!). + Please always use the "Comment" + + - Avoid clicking the "Request changes" button when finishing your review. + If you want to block a PR from being merged before some further changes are made, + you can leave a "/hold" comment. + Mention why you are setting a hold, and optionally specify the conditions under + which the hold can be removed by you or other reviewers. + + - Avoid clicking the "Approve" button when finishing your review. + Leaving a "/approve" comment is recommended most of the time. ## Reviewing checklist diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md index 73119e0375e1f..99a139416432e 100644 --- a/content/en/docs/contribute/style/style-guide.md +++ b/content/en/docs/contribute/style/style-guide.md @@ -361,7 +361,7 @@ Beware. ### Katacoda Embedded Live Environment -This button lets users run Minikube in their browser using the [Katacoda Terminal](https://www.katacoda.com/embed/panel). +This button lets users run Minikube in their browser using the Katacoda Terminal. It lowers the barrier of entry by allowing users to use Minikube with one click instead of going through the complete Minikube and Kubectl installation process locally. diff --git a/content/en/docs/reference/access-authn-authz/psp-to-pod-security-standards.md b/content/en/docs/reference/access-authn-authz/psp-to-pod-security-standards.md index 6c820a6e99c1c..82394b363afd0 100644 --- a/content/en/docs/reference/access-authn-authz/psp-to-pod-security-standards.md +++ b/content/en/docs/reference/access-authn-authz/psp-to-pod-security-standards.md @@ -9,7 +9,7 @@ weight: 95 The tables below enumerate the configuration parameters on -[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) objects, whether the field mutates +[PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) objects, whether the field mutates and/or validates pods, and how the configuration values map to the [Pod Security Standards](/docs/concepts/security/pod-security-standards/). @@ -31,9 +31,9 @@ The fields enumerated in this table are part of the `PodSecurityPolicySpec`, whi under the `.spec` field path. - - - + + + @@ -54,19 +54,19 @@ under the `.spec` field path. @@ -236,9 +236,9 @@ The [annotations](/docs/concepts/overview/working-with-objects/annotations/) enu table can be specified under `.metadata.annotations` on the PodSecurityPolicy object.
Mapping PodSecurityPolicySpec fields to Pod Security Standards
Mapping PodSecurityPolicySpec fields to Pod Security Standards
PodSecurityPolicySpec Type Pod Security Standards Equivalent

Baseline: subset of

    -
  • AUDIT_WRITE
  • -
  • CHOWN
  • -
  • DAC_OVERRIDE
  • -
  • FOWNER
  • -
  • FSETID
  • -
  • KILL
  • -
  • MKNOD
  • -
  • NET_BIND_SERVICE
  • -
  • SETFCAP
  • -
  • SETGID
  • -
  • SETPCAP
  • -
  • SETUID
  • -
  • SYS_CHROOT
  • +
  • AUDIT_WRITE
  • +
  • CHOWN
  • +
  • DAC_OVERRIDE
  • +
  • FOWNER
  • +
  • FSETID
  • +
  • KILL
  • +
  • MKNOD
  • +
  • NET_BIND_SERVICE
  • +
  • SETFCAP
  • +
  • SETGID
  • +
  • SETPCAP
  • +
  • SETUID
  • +
  • SYS_CHROOT

Restricted: empty / undefined / nil OR a list containing only NET_BIND_SERVICE

- - - + + + diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md index d085251e4337f..a681164fe9d10 100644 --- a/content/en/docs/reference/access-authn-authz/rbac.md +++ b/content/en/docs/reference/access-authn-authz/rbac.md @@ -54,8 +54,8 @@ it can't be both. ClusterRoles have several uses. You can use a ClusterRole to: -1. define permissions on namespaced resources and be granted within individual namespace(s) -1. define permissions on namespaced resources and be granted across all namespaces +1. define permissions on namespaced resources and be granted access within individual namespace(s) +1. define permissions on namespaced resources and be granted access across all namespaces 1. define permissions on cluster-scoped resources If you want to define a role within a namespace, use a Role; if you want to define diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet.md b/content/en/docs/reference/command-line-tools-reference/kubelet.md index abaa00af1f2f2..f2a80315021f5 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet.md @@ -90,7 +90,7 @@ kubelet [flags] - + diff --git a/content/en/docs/reference/glossary/extensions.md b/content/en/docs/reference/glossary/extensions.md index 4f5c5ebd78776..c994b601a1a43 100644 --- a/content/en/docs/reference/glossary/extensions.md +++ b/content/en/docs/reference/glossary/extensions.md @@ -2,9 +2,10 @@ title: Extensions id: Extensions date: 2019-02-01 -full_link: /docs/concepts/extend-kubernetes/extend-cluster/#extensions +full_link: /docs/concepts/extend-kubernetes/#extensions short_description: > - Extensions are software components that extend and deeply integrate with Kubernetes to support new types of hardware. + Extensions are software components that extend and deeply integrate with Kubernetes to support + new types of hardware. aka: tags: @@ -15,4 +16,6 @@ tags: -Many cluster administrators use a hosted or distribution instance of Kubernetes. These clusters come with extensions pre-installed. As a result, most Kubernetes users will not need to install [extensions](/docs/concepts/extend-kubernetes/extend-cluster/#extensions) and even fewer users will need to author new ones. +Many cluster administrators use a hosted or distribution instance of Kubernetes. These clusters +come with extensions pre-installed. As a result, most Kubernetes users will not need to install +[extensions](/docs/concepts/extend-kubernetes/) and even fewer users will need to author new ones. diff --git a/content/en/docs/reference/glossary/garbage-collection.md b/content/en/docs/reference/glossary/garbage-collection.md index ec2fe19af7cc9..1d4b9b5785209 100644 --- a/content/en/docs/reference/glossary/garbage-collection.md +++ b/content/en/docs/reference/glossary/garbage-collection.md @@ -2,7 +2,7 @@ title: Garbage Collection id: garbage-collection date: 2021-07-07 -full_link: /docs/concepts/workloads/controllers/garbage-collection/ +full_link: /docs/concepts/architecture/garbage-collection/ short_description: > A collective term for the various mechanisms Kubernetes uses to clean up cluster resources. @@ -12,13 +12,16 @@ tags: - fundamental - operation --- - Garbage collection is a collective term for the various mechanisms Kubernetes uses to clean up - cluster resources. + +Garbage collection is a collective term for the various mechanisms Kubernetes uses to clean up +cluster resources. -Kubernetes uses garbage collection to clean up resources like [unused containers and images](/docs/concepts/workloads/controllers/garbage-collection/#containers-images), +Kubernetes uses garbage collection to clean up resources like +[unused containers and images](/docs/concepts/architecture/garbage-collection/#containers-images), [failed Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection), [objects owned by the targeted resource](/docs/concepts/overview/working-with-objects/owners-dependents/), [completed Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/), and resources -that have expired or failed. \ No newline at end of file +that have expired or failed. + diff --git a/content/en/docs/reference/using-api/_index.md b/content/en/docs/reference/using-api/_index.md index 6592deb3c7155..182bbd4fe6339 100644 --- a/content/en/docs/reference/using-api/_index.md +++ b/content/en/docs/reference/using-api/_index.md @@ -39,7 +39,7 @@ The JSON and Protobuf serialization schemas follow the same guidelines for schema changes. The following descriptions cover both formats. The API versioning and software versioning are indirectly related. -The [API and release versioning proposal](https://git.k8s.io/design-proposals-archive/release/versioning.md) +The [API and release versioning proposal](https://git.k8s.io/sig-release/release-engineering/versioning.md) describes the relationship between API versioning and software versioning. Different API versions indicate different levels of stability and support. You diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md index e0525562c6556..fe139261f6d3f 100644 --- a/content/en/docs/setup/production-environment/tools/kubespray.md +++ b/content/en/docs/setup/production-environment/tools/kubespray.md @@ -13,10 +13,10 @@ Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [i * a highly available cluster * composable attributes * support for most popular Linux distributions - * Ubuntu 16.04, 18.04, 20.04 + * Ubuntu 16.04, 18.04, 20.04, 22.04 * CentOS/RHEL/Oracle Linux 7, 8 * Debian Buster, Jessie, Stretch, Wheezy - * Fedora 31, 32 + * Fedora 34, 35 * Fedora CoreOS * openSUSE Leap 15 * Flatcar Container Linux by Kinvolk @@ -33,7 +33,7 @@ To choose a tool which best fits your use case, read [this comparison](https://g Provision servers with the following [requirements](https://github.com/kubernetes-sigs/kubespray#requirements): -* **Ansible v2.9 and python-netaddr are installed on the machine that will run Ansible commands** +* **Ansible v2.11 and python-netaddr are installed on the machine that will run Ansible commands** * **Jinja 2.11 (or newer) is required to run the Ansible Playbooks** * The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)) * The target servers are configured to allow **IPv4 forwarding** diff --git a/content/en/docs/tasks/administer-cluster/verify-signed-images.md b/content/en/docs/tasks/administer-cluster/verify-signed-images.md index fec6d1e59d52c..074a9f3410e9e 100644 --- a/content/en/docs/tasks/administer-cluster/verify-signed-images.md +++ b/content/en/docs/tasks/administer-cluster/verify-signed-images.md @@ -69,4 +69,4 @@ admission controller. To get started with `cosigned` here are a few helpful resources: * [Installation](https://github.com/sigstore/cosign#installation) -* [Configuration Options](https://github.com/sigstore/cosign/tree/main/config) +* [Configuration Options](https://github.com/sigstore/cosign/blob/main/USAGE.md#detailed-usage) 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 7766bcedf3b4d..812c723a51be5 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 @@ -362,9 +362,9 @@ and create it: kubectl create --validate=false -f my-crontab.yaml -o yaml ``` -your output is similar to: +Your output is similar to: -```console +```yaml apiVersion: stable.example.com/v1 kind: CronTab metadata: @@ -836,7 +836,7 @@ Validation Rules Examples: | `has(self.expired) && self.created + self.ttl < self.expired` | Validate that 'expired' date is after a 'create' date plus a 'ttl' duration | | `self.health.startsWith('ok')` | Validate a 'health' string field has the prefix 'ok' | | `self.widgets.exists(w, w.key == 'x' && w.foo < 10)` | Validate that the 'foo' property of a listMap item with a key 'x' is less than 10 | -| `type(self) == string ? self == '100%' : self == 1000` | Validate an int-or-string field for both the the int and string cases | +| `type(self) == string ? self == '100%' : self == 1000` | Validate an int-or-string field for both the int and string cases | | `self.metadata.name.startsWith(self.prefix)` | Validate that an object's name has the prefix of another field value | | `self.set1.all(e, !(e in self.set2))` | Validate that two listSets are disjoint | | `size(self.names) == size(self.details) && self.names.all(n, n in self.details)` | Validate the 'details' map is keyed by the items in the 'names' listSet | @@ -844,7 +844,6 @@ Validation Rules Examples: Xref: [Supported evaluation on CEL](https://github.com/google/cel-spec/blob/v0.6.0/doc/langdef.md#evaluation) - - If the Rule is scoped to the root of a resource, it may make field selection into any fields declared in the OpenAPIv3 schema of the CRD as well as `apiVersion`, `kind`, `metadata.name` and `metadata.generateName`. This includes selection of fields in both the `spec` and `status` in the diff --git a/content/en/docs/tasks/kubelet-credential-provider/kubelet-credential-provider.md b/content/en/docs/tasks/kubelet-credential-provider/kubelet-credential-provider.md index 70e514b473299..16547f0bf4507 100644 --- a/content/en/docs/tasks/kubelet-credential-provider/kubelet-credential-provider.md +++ b/content/en/docs/tasks/kubelet-credential-provider/kubelet-credential-provider.md @@ -7,7 +7,7 @@ description: Configure the kubelet's image credential provider plugin content_type: task --- -{{< feature-state for_k8s_version="v1.20" state="alpha" >}} +{{< feature-state for_k8s_version="v1.24" state="beta" >}} diff --git a/content/en/examples/admin/konnectivity/egress-selector-configuration.yaml b/content/en/examples/admin/konnectivity/egress-selector-configuration.yaml index c85f25ea51590..631e6cc26862e 100644 --- a/content/en/examples/admin/konnectivity/egress-selector-configuration.yaml +++ b/content/en/examples/admin/konnectivity/egress-selector-configuration.yaml @@ -2,7 +2,7 @@ apiVersion: apiserver.k8s.io/v1beta1 kind: EgressSelectorConfiguration egressSelections: # Since we want to control the egress traffic to the cluster, we use the -# "cluster" as the name. Other supported values are "etcd", and "master". +# "cluster" as the name. Other supported values are "etcd", and "controlplane". - name: cluster connection: # This controls the protocol between the API Server and the Konnectivity diff --git a/content/en/examples/controllers/job.yaml b/content/en/examples/controllers/job.yaml index a6e40bc778d6d..d8befe89dba46 100644 --- a/content/en/examples/controllers/job.yaml +++ b/content/en/examples/controllers/job.yaml @@ -7,7 +7,7 @@ spec: spec: containers: - name: pi - image: perl:5.34 + image: perl:5.34.0 command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] restartPolicy: Never backoffLimit: 4 diff --git a/content/en/examples/pods/pod-with-affinity-anti-affinity.yaml b/content/en/examples/pods/pod-with-affinity-anti-affinity.yaml index 5dcc7693b67c8..10d3056f2d279 100644 --- a/content/en/examples/pods/pod-with-affinity-anti-affinity.yaml +++ b/content/en/examples/pods/pod-with-affinity-anti-affinity.yaml @@ -8,11 +8,10 @@ spec: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - - key: topology.kubernetes.io/zone + - key: kubernetes.io/os operator: In values: - - antarctica-east1 - - antarctica-west1 + - linux preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference: diff --git a/content/en/examples/pods/pod-with-node-affinity.yaml b/content/en/examples/pods/pod-with-node-affinity.yaml index e077f79883eff..ebc6f14490351 100644 --- a/content/en/examples/pods/pod-with-node-affinity.yaml +++ b/content/en/examples/pods/pod-with-node-affinity.yaml @@ -8,10 +8,11 @@ spec: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - - key: kubernetes.io/os + - key: topology.kubernetes.io/zone operator: In values: - - linux + - antarctica-east1 + - antarctica-west1 preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference: diff --git a/content/en/releases/patch-releases.md b/content/en/releases/patch-releases.md index 91bdcc58bb91e..f263e431c2a9f 100644 --- a/content/en/releases/patch-releases.md +++ b/content/en/releases/patch-releases.md @@ -78,7 +78,6 @@ releases may also occur in between these. | Monthly Patch Release | Cherry Pick Deadline | Target date | | --------------------- | -------------------- | ----------- | -| 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 | @@ -87,24 +86,28 @@ releases may also occur in between these. ### 1.24 -Next patch release is **1.24.1** +Next patch release is **1.24.4** -End of Life for **1.24** is **2023-09-29** +End of Life for **1.24** is **2023-07-28** | PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE | |---------------|----------------------|-------------|------| +| 1.24.4 | 2022-08-12 | 2022-08-17 | | | 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 | | ### 1.23 +Next patch release is **1.23.10** + **1.23** enters maintenance mode on **2022-12-28**. End of Life for **1.23** is **2023-02-28**. | Patch Release | Cherry Pick Deadline | Target Date | Note | |---------------|----------------------|-------------|------| +| 1.23.10 | 2022-08-12 | 2022-08-17 | | | 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 | | @@ -117,12 +120,15 @@ End of Life for **1.23** is **2023-02-28**. ### 1.22 +Next patch release is **1.22.13** + **1.22** enters maintenance mode on **2022-08-28** End of Life for **1.22** is **2022-10-28** | Patch Release | Cherry Pick Deadline | Target Date | Note | |---------------|----------------------|-------------|------| +| 1.22.13 | 2022-08-12 | 2022-08-17 | | | 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 | | diff --git a/content/en/releases/release-managers.md b/content/en/releases/release-managers.md index 1c4eba3863445..61afd672679d0 100644 --- a/content/en/releases/release-managers.md +++ b/content/en/releases/release-managers.md @@ -4,8 +4,8 @@ type: docs --- "Release Managers" is an umbrella term that encompasses the set of Kubernetes -contributors responsible for maintaining release branches, tagging releases, -and building/packaging Kubernetes. +contributors responsible for maintaining release branches and creating releases +by using the tools SIG Release provides. The responsibilities of each role are described below. @@ -133,7 +133,9 @@ referred to as Release Manager shadows. They are responsible for: GitHub Mentions: @kubernetes/release-engineering - Arnaud Meukam ([@ameukam](https://github.com/ameukam)) +- Jeremy Rickard ([@jeremyrickard](https://github.com/jeremyrickard)) - Jim Angel ([@jimangel](https://github.com/jimangel)) +- Joseph Sandoval ([@jrsapi](https://github.com/jrsapi)) - Joyce Kung ([@thejoycekung](https://github.com/thejoycekung)) - Max Körbächer ([@mkorbi](https://github.com/mkorbi)) - Seth McCombs ([@sethmccombs](https://github.com/sethmccombs)) diff --git a/content/en/releases/release.md b/content/en/releases/release.md index af08831dac9ac..e0d21c0df16c7 100644 --- a/content/en/releases/release.md +++ b/content/en/releases/release.md @@ -124,7 +124,7 @@ The general labeling process should be consistent across artifact types. referring to a release MAJOR.MINOR `vX.Y` version. See also - [release versioning](https://git.k8s.io/design-proposals-archive/release/versioning.md). + [release versioning](https://git.k8s.io/sig-release/release-engineering/versioning.md). - *release branch*: Git branch `release-X.Y` created for the `vX.Y` milestone. diff --git a/content/en/releases/version-skew-policy.md b/content/en/releases/version-skew-policy.md index 4d0fa8c9d9259..0d1c96f9226af 100644 --- a/content/en/releases/version-skew-policy.md +++ b/content/en/releases/version-skew-policy.md @@ -21,7 +21,7 @@ Specific cluster deployment tools may place additional restrictions on version s ## Supported versions Kubernetes versions are expressed as **x.y.z**, where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology. -For more information, see [Kubernetes Release Versioning](https://git.k8s.io/design-proposals-archive/release/versioning.md#kubernetes-release-versioning). +For more information, see [Kubernetes Release Versioning](https://git.k8s.io/sig-release/release-engineering/versioning.md#kubernetes-release-versioning). The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew currentVersion >}}, {{< skew currentVersionAddMinor -1 >}}, {{< skew currentVersionAddMinor -2 >}}). Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support. diff --git a/content/es/docs/concepts/architecture/nodes.md b/content/es/docs/concepts/architecture/nodes.md index d2313849eff3a..ccb3e582905a9 100644 --- a/content/es/docs/concepts/architecture/nodes.md +++ b/content/es/docs/concepts/architecture/nodes.md @@ -8,7 +8,7 @@ weight: 10 -Un nodo es una máquina de trabajo en Kubernetes, previamente conocida como `minion`. Un nodo puede ser una máquina virtual o física, dependiendo del tipo de clúster. Cada nodo está gestionado por el componente máster y contiene los servicios necesarios para ejecutar [pods](/docs/concepts/workloads/pods/pod). Los servicios en un nodo incluyen el [container runtime](/docs/concepts/overview/components/#node-components), kubelet y el kube-proxy. Accede a la sección [The Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) en el documento de diseño de arquitectura para más detalle. +Un nodo es una máquina de trabajo en Kubernetes, previamente conocida como `minion`. Un nodo puede ser una máquina virtual o física, dependiendo del tipo de clúster. Cada nodo está gestionado por el componente máster y contiene los servicios necesarios para ejecutar [pods](/docs/concepts/workloads/pods/pod). Los servicios en un nodo incluyen el [container runtime](/docs/concepts/overview/components/#node-components), kubelet y el kube-proxy. Accede a la sección [The Kubernetes Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node) en el documento de diseño de arquitectura para más detalle. diff --git a/content/es/docs/concepts/configuration/manage-resources-containers.md b/content/es/docs/concepts/configuration/manage-resources-containers.md index 9630d271ba729..4cdc6c4a26ab2 100644 --- a/content/es/docs/concepts/configuration/manage-resources-containers.md +++ b/content/es/docs/concepts/configuration/manage-resources-containers.md @@ -676,7 +676,7 @@ La cantidad de recursos disponibles para los pods es menor que la capacidad del los demonios del sistema utilizan una parte de los recursos disponibles. El campo `allocatable` [NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core) indica la cantidad de recursos que están disponibles para los Pods. Para más información, mira -[Node Allocatable Resources](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md). +[Node Allocatable Resources](https://git.k8s.io/design-proposals-archive/node/node-allocatable.md). La característica [resource quota](/docs/concepts/policy/resource-quotas/) se puede configurar para limitar la cantidad total de recursos que se pueden consumir. Si se usa en conjunto @@ -757,7 +757,7 @@ Puedes ver que el Contenedor fué terminado a causa de `reason:OOM Killed`, dond * Obtén experiencia práctica [assigning CPU resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/). * Para más detalles sobre la diferencia entre solicitudes y límites, mira - [Resource QoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md). + [Resource QoS](https://git.k8s.io/design-proposals-archive/node/resource-qos.md). * Lee [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) referencia de API diff --git a/content/es/docs/concepts/configuration/pod-overhead.md b/content/es/docs/concepts/configuration/pod-overhead.md index 0d7a89bcd6904..baaf8a902fc3c 100644 --- a/content/es/docs/concepts/configuration/pod-overhead.md +++ b/content/es/docs/concepts/configuration/pod-overhead.md @@ -38,4 +38,4 @@ Para obtener más detalles vea la [documentación sobre autorización](/docs/ref * [RuntimeClass](/docs/concepts/containers/runtime-class/) -* [PodOverhead Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) +* [Diseño de capacidad de PodOverhead](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) diff --git a/content/es/docs/concepts/configuration/secret.md b/content/es/docs/concepts/configuration/secret.md index 8fd08c0285486..ffbc78fa7001b 100644 --- a/content/es/docs/concepts/configuration/secret.md +++ b/content/es/docs/concepts/configuration/secret.md @@ -14,7 +14,7 @@ weight: 50 Los objetos de tipo {{< glossary_tooltip text="Secret" term_id="secret" >}} en Kubernetes te permiten almacenar y administrar información confidencial, como contraseñas, tokens OAuth y llaves ssh. Poniendo esta información en un Secret -es más seguro y más flexible que ponerlo en la definición de un {{< glossary_tooltip term_id="pod" >}} o en un {{< glossary_tooltip text="container image" term_id="image" >}}. Ver [Secrets design document](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) para más información. +es más seguro y más flexible que ponerlo en la definición de un {{< glossary_tooltip term_id="pod" >}} o en un {{< glossary_tooltip text="container image" term_id="image" >}}. Ver [Secrets design document](https://git.k8s.io/design-proposals-archive/auth/secrets.md) para más información. @@ -345,7 +345,7 @@ echo 'MWYyZDFlMmU2N2Rm' | base64 --decode ## Usando Secrets Los Secrets se pueden montar como volúmenes de datos o ser expuestos como -{{< glossary_tooltip text="variables de ambiente" term_id="container-env-variables" >}} +{{< glossary_tooltip text="variables de entorno" term_id="container-env-variables" >}} para ser usados por un contenedor en un pod. También pueden ser utilizados por otras partes del sistema, sin estar directamente expuesto en el pod. Por ejemplo, pueden tener credenciales que otras partes del sistema usan para interactuar con sistemas externos en su nombre. diff --git a/content/es/docs/concepts/containers/runtime-class.md b/content/es/docs/concepts/containers/runtime-class.md index fa27366b35a1a..ef4c5e0d2c888 100644 --- a/content/es/docs/concepts/containers/runtime-class.md +++ b/content/es/docs/concepts/containers/runtime-class.md @@ -202,4 +202,4 @@ cuentan en Kubernetes. - [Diseño de RuntimeClass](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md) - [Diseño de programación de RuntimeClass](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling) - Leer sobre el concepto de [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/) -- [Diseño de capacidad de PodOverhead](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) +- [Diseño de capacidad de PodOverhead](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) diff --git a/content/es/docs/concepts/overview/kubernetes-api.md b/content/es/docs/concepts/overview/kubernetes-api.md index 25cfe18049398..54155a63026ca 100644 --- a/content/es/docs/concepts/overview/kubernetes-api.md +++ b/content/es/docs/concepts/overview/kubernetes-api.md @@ -66,7 +66,7 @@ Para facilitar la eliminación de propiedades o reestructurar la representación Se versiona a nivel de la API en vez de a nivel de los recursos o propiedades para asegurarnos de que la API presenta una visión clara y consistente de los recursos y el comportamiento del sistema, y para controlar el acceso a las APIs experimentales o que estén terminando su ciclo de vida. Los esquemas de serialización JSON y Protobuf siguen los mismos lineamientos para los cambios, es decir, estas descripciones cubren ambos formatos. -Se ha de tener en cuenta que hay una relación indirecta entre el versionado de la API y el versionado del resto del software. La propuesta de [versionado de la API y releases](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) describe esta relación. +Se ha de tener en cuenta que hay una relación indirecta entre el versionado de la API y el versionado del resto del software. La propuesta de [versionado de la API y releases](https://git.k8s.io/design-proposals-archive/release/versioning.md) describe esta relación. Las distintas versiones de la API implican distintos niveles de estabilidad y soporte. El criterio para cada nivel se describe en detalle en la documentación de [Cambios a la API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). A continuación se ofrece un resumen: @@ -89,7 +89,7 @@ Las distintas versiones de la API implican distintos niveles de estabilidad y so ## Grupos de API -Para que sea más fácil extender la API de Kubernetes, se han creado los [*grupos de API*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md). +Para que sea más fácil extender la API de Kubernetes, se han creado los [*grupos de API*](https://git.k8s.io/design-proposals-archive/api-machinery/api-group.md). Estos grupos se especifican en una ruta REST y en la propiedad `apiVersion` de un objeto serializado. Actualmente hay varios grupos de API en uso: diff --git a/content/es/docs/concepts/overview/what-is-kubernetes.md b/content/es/docs/concepts/overview/what-is-kubernetes.md index 510f32202d8cf..9fe53180b2780 100644 --- a/content/es/docs/concepts/overview/what-is-kubernetes.md +++ b/content/es/docs/concepts/overview/what-is-kubernetes.md @@ -60,7 +60,7 @@ APIs](/docs/concepts/api-extension/custom-resources/) desde una [herramienta de línea de comandos](/docs/user-guide/kubectl-overview/). Este -[diseño](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) +[diseño](https://git.k8s.io/design-proposals-archive/architecture/architecture.md) ha permitido que otros sistemas sean construidos sobre Kubernetes. ## Lo que Kubernetes no es diff --git a/content/es/docs/concepts/overview/working-with-objects/names.md b/content/es/docs/concepts/overview/working-with-objects/names.md index ef241f6aff50e..f683b3d985400 100644 --- a/content/es/docs/concepts/overview/working-with-objects/names.md +++ b/content/es/docs/concepts/overview/working-with-objects/names.md @@ -10,7 +10,7 @@ Todos los objetos de la API REST de Kubernetes se identifica de forma inequívoc Para aquellos atributos provistos por el usuario que no son únicos, Kubernetes provee de [etiquetas](/docs/user-guide/labels) y [anotaciones](/docs/concepts/overview/working-with-objects/annotations/). -Echa un vistazo al [documento de diseño de identificadores](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) para información precisa acerca de las reglas sintácticas de los Nombres y UIDs. +Echa un vistazo al [documento de diseño de identificadores](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md) para información precisa acerca de las reglas sintácticas de los Nombres y UIDs. diff --git a/content/es/docs/concepts/policy/limit-range.md b/content/es/docs/concepts/policy/limit-range.md index 22d4c74f51849..5fccd8b13dc90 100644 --- a/content/es/docs/concepts/policy/limit-range.md +++ b/content/es/docs/concepts/policy/limit-range.md @@ -58,7 +58,7 @@ Ni la contención ni los cambios en un LimitRange afectarán a los recursos ya c ## {{% heading "whatsnext" %}} -Consulte el [documento de diseño del LimitRanger](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) para más información. +Consulte el [documento de diseño del LimitRanger](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md) para más información. Los siguientes ejemplos utilizan límites y están pendientes de su traducción: diff --git a/content/es/docs/concepts/services-networking/service.md b/content/es/docs/concepts/services-networking/service.md index 7329aa1075b1f..3bd85a1701286 100644 --- a/content/es/docs/concepts/services-networking/service.md +++ b/content/es/docs/concepts/services-networking/service.md @@ -95,7 +95,7 @@ Los Services comúnmente abstraen el acceso a los Pods de Kubernetes, pero tambi Por ejemplo: -- Quieres tener un clúster de base de datos externo en producción, pero en el ambiente de pruebas quieres usar tus propias bases de datos. +- Quieres tener un clúster de base de datos externo en producción, pero en el entorno de pruebas quieres usar tus propias bases de datos. - Quieres apuntar tu Service a un Service en un {{< glossary_tooltip term_id="namespace" text="Namespace" >}} o en un clúster diferente. - Estás migrando tu carga de trabajo a Kubernetes. Mientras evalúas la aproximación, corres solo una porción de tus backends en Kubernetes. @@ -418,7 +418,7 @@ Si quieres un número de puerto específico, puedes especificar un valor en el c Esto significa que necesitas prestar atención a posibles colisiones de puerto por tu cuenta. También tienes que usar un número de puerto válido, uno que esté dentro del rango configurado para uso del NodePort. -Usar un NodePort te da libertad para configurar tu propia solución de balanceo de cargas, para configurar ambientes que no soportan Kubernetes del todo, o para exponer uno o más IPs del nodo directamente. +Usar un NodePort te da libertad para configurar tu propia solución de balanceo de cargas, para configurar entornos que no soportan Kubernetes del todo, o para exponer uno o más IPs del nodo directamente. Ten en cuenta que este Service es visible como `:spec.ports[*].nodePort` y `.spec.clusterIP:spec.ports[*].port`. Si la bandera `--nodeport-addresses` está configurada para el kube-proxy o para el campo equivalente en el fichero de configuración, `` sería IP filtrada del nodo. Si @@ -514,7 +514,7 @@ El valor de `spec.loadBalancerClass` debe ser un identificador de etiqueta, con #### Balanceador de carga interno -En un ambiente mixto algunas veces es necesario enrutar el tráfico desde Services dentro del mismo bloque (virtual) de direcciones de red. +En un entorno mixto algunas veces es necesario enrutar el tráfico desde Services dentro del mismo bloque (virtual) de direcciones de red. En un entorno de split-horizon DNS necesitarías dos Services para ser capaz de enrutar tanto el tráfico externo como el interno a tus Endpoints. @@ -646,7 +646,7 @@ HTTP y HTTPS seleccionan un proxy de capa 7: el ELB termina la conexión con el TCP y SSL seleccionan un proxy de capa 4: el ELB reenvía el tráfico sin modificar los encabezados. -En un ambiente mixto donde algunos puertos están asegurados y otros se dejan sin encriptar, puedes usar una de las siguientes anotaciones: +En un entorno mixto donde algunos puertos están asegurados y otros se dejan sin encriptar, puedes usar una de las siguientes anotaciones: ```yaml metadata: diff --git a/content/es/docs/concepts/storage/volume-health-monitoring.md b/content/es/docs/concepts/storage/volume-health-monitoring.md new file mode 100644 index 0000000000000..a300368f8364c --- /dev/null +++ b/content/es/docs/concepts/storage/volume-health-monitoring.md @@ -0,0 +1,36 @@ +--- +reviewers: +- edithturn +- raelga +- electrocucaracha +title: Supervisión del Estado del Volumen +content_type: concept +--- + + + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +La supervisión del estado del volumen de {{< glossary_tooltip text="CSI" term_id="csi" >}} permite que los controladores de CSI detecten condiciones de volumen anómalas de los sistemas de almacenamiento subyacentes y las notifiquen como eventos en {{< glossary_tooltip text="PVCs" term_id="persistent-volume-claim" >}} o {{< glossary_tooltip text="Pods" term_id="pod" >}}. + + + + + +## Supervisión del Estado del Volumen + +El _monitoreo del estado del volumen_ de Kubernetes es parte de cómo Kubernetes implementa la Interfaz de Almacenamiento de Contenedores (CSI). La función de supervisión del estado del volumen se implementa en dos componentes: un controlador de supervisión del estado externo y {{< glossary_tooltip term_id="kubelet" text="Kubelet" >}}. + +Si un controlador CSI admite la función supervisión del estado del volumen desde el lado del controlador, se informará un evento en el {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} (PVC) relacionado cuando se detecte una condición de volumen anormal en un volumen CSI. + +El {{< glossary_tooltip text="controlador" term_id="controller" >}} de estado externo también observa los eventos de falla del nodo. Se puede habilitar la supervisión de fallas de nodos configurando el indicador `enable-node-watcher` en verdadero. Cuando el monitor de estado externo detecta un evento de falla de nodo, el controlador reporta que se informará un evento en el PVC para indicar que los Pods que usan este PVC están en un nodo fallido. + +Si un controlador CSI es compatible con la función monitoreo del estado del volumen desde el lado del nodo, se informará un evento en cada Pod que use el PVC cuando se detecte una condición de volumen anormal en un volumen CSI. + +{{< note >}} +Se necesita habilitar el `CSIVolumeHealth` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) para usar esta función desde el lado del nodo. +{{< /note >}} + +## {{% heading "whatsnext" %}} + +Ver la [documentación del controlador CSI](https://kubernetes-csi.github.io/docs/drivers.html) para averiguar qué controladores CSI han implementado esta característica. diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md index c8e7a9d24b857..84ee2a2be2eaa 100644 --- a/content/es/docs/concepts/storage/volumes.md +++ b/content/es/docs/concepts/storage/volumes.md @@ -638,7 +638,7 @@ Mira el [ ejemplo NFS ](https://github.com/kubernetes/examples/tree/master/stagi ### persistentVolumeClaim {#persistentvolumeclaim} -Un volumen `persistenceVolumeClain` se utiliza para montar un [PersistentVolume](/docs/concepts/storage/persistent-volumes/) en tu Pod. PersistentVolumeClaims son una forma en que el usuario "reclama" almacenamiento duradero (como un PersistentDisk GCE o un volumen ISCSI) sin conocer los detalles del ambiente de la nube en particular. +Un volumen `persistenceVolumeClain` se utiliza para montar un [PersistentVolume](/docs/concepts/storage/persistent-volumes/) en tu Pod. PersistentVolumeClaims son una forma en que el usuario "reclama" almacenamiento duradero (como un PersistentDisk GCE o un volumen ISCSI) sin conocer los detalles del entorno de la nube en particular. Mira la información spbre [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) para más detalles. diff --git a/content/es/docs/concepts/workloads/controllers/garbage-collection.md b/content/es/docs/concepts/workloads/controllers/garbage-collection.md index bc18541ce2f34..9653e6f582c5d 100644 --- a/content/es/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/es/docs/concepts/workloads/controllers/garbage-collection.md @@ -170,7 +170,7 @@ Seguimiento en [#26120](https://github.com/kubernetes/kubernetes/issues/26120) ## {{% heading "whatsnext" %}} -[Documento de Diseño 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md) +[Documento de Diseño 1](https://git.k8s.io/design-proposals-archive/api-machinery/garbage-collection.md) -[Documento de Diseño 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md) +[Documento de Diseño 2](https://git.k8s.io/design-proposals-archive/api-machinery/synchronous-garbage-collection.md) diff --git a/content/es/docs/concepts/workloads/pods/podpreset.md b/content/es/docs/concepts/workloads/pods/podpreset.md index d4406f56ea81c..76110e5ee84df 100644 --- a/content/es/docs/concepts/workloads/pods/podpreset.md +++ b/content/es/docs/concepts/workloads/pods/podpreset.md @@ -92,4 +92,4 @@ modificación del Pod Preset. En estos casos, se puede añadir una observación Ver [Inyectando datos en un Pod usando PodPreset](/docs/tasks/inject-data-application/podpreset/) -Para más información sobre los detalles de los trasfondos, consulte la [propuesta de diseño de PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md). +Para más información sobre los detalles de los trasfondos, consulte la [propuesta de diseño de PodPreset](https://git.k8s.io/design-proposals-archive/service-catalog/pod-preset.md). diff --git a/content/es/docs/reference/_index.md b/content/es/docs/reference/_index.md index a3625a903eed8..8ea72cfb26ad6 100644 --- a/content/es/docs/reference/_index.md +++ b/content/es/docs/reference/_index.md @@ -59,6 +59,6 @@ En estos momento, las librerías con soporte oficial son: Un archivo de los documentos de diseño para la funcionalidad de Kubernetes. -Puedes empezar por [Arquitectura de Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) y [Vista general del diseño de Kubernetes](https://git.k8s.io/community/contributors/design-proposals). +Puedes empezar por [Arquitectura de Kubernetes](https://git.k8s.io/design-proposals-archive/architecture/architecture.md) y [Vista general del diseño de Kubernetes](https://git.k8s.io/community/contributors/design-proposals). diff --git a/content/es/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/es/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md index 9e7097ffbca2b..080a91df302f8 100644 --- a/content/es/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md +++ b/content/es/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md @@ -52,6 +52,6 @@ El servidor reune métricas de la Summary API, que es expuesta por el [Kubelet]( El servidor de métricas se añadió a la API de Kubernetes utilizando el [Kubernetes aggregator](/docs/concepts/api-extension/apiserver-aggregation/) introducido en Kubernetes 1.7. -Puedes aprender más acerca del servidor de métricas en el [documento de diseño](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md). +Puedes aprender más acerca del servidor de métricas en el [documento de diseño](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/metrics-server.md). diff --git a/content/es/docs/tutorials/hello-minikube.md b/content/es/docs/tutorials/hello-minikube.md index 67d7bf7afaef8..fb40f2fdb0bf1 100644 --- a/content/es/docs/tutorials/hello-minikube.md +++ b/content/es/docs/tutorials/hello-minikube.md @@ -17,7 +17,7 @@ card: Este tutorial muestra como ejecutar una aplicación Node.js Hola Mundo en Kubernetes utilizando [Minikube](/docs/setup/learning-environment/minikube) y Katacoda. -Katacoda provee un ambiente de Kubernetes desde el navegador. +Katacoda provee un entorno de Kubernetes desde el navegador. {{< note >}} También se puede seguir este tutorial si se ha instalado [Minikube localmente](/docs/tasks/tools/install-minikube/). @@ -63,9 +63,9 @@ Para más información sobre el comando `docker build`, lea la [documentación d minikube dashboard ``` -3. Solo en el ambiente de Katacoda: En la parte superior de la terminal, haz clic en el símbolo + y luego clic en **Select port to view on Host 1**. +3. Solo en el entorno de Katacoda: En la parte superior de la terminal, haz clic en el símbolo + y luego clic en **Select port to view on Host 1**. -4. Solo en el ambiente de Katacoda: Escribir `30000`, y hacer clic en **Display Port**. +4. Solo en el entorno de Katacoda: Escribir `30000`, y hacer clic en **Display Port**. ## Crear un Deployment @@ -154,15 +154,15 @@ Por defecto, el Pod es accedido por su dirección IP interna dentro del clúster minikube service hello-node ``` -4. Solo en el ambiente de Katacoda: Hacer clic sobre el símbolo +, y luego en **Select port to view on Host 1**. +4. Solo en el entorno de Katacoda: Hacer clic sobre el símbolo +, y luego en **Select port to view on Host 1**. -5. Solo en el ambiente de Katacoda: Anotar el puerto de 5 dígitos ubicado al lado del valor de `8080` en el resultado de servicios. Este número de puerto es generado aleatoriamente y puede ser diferente al indicado en el ejemplo. Escribir el número de puerto en el cuadro de texto y hacer clic en Display Port. Usando el ejemplo anterior, usted escribiría `30369`. +5. Solo en el entorno de Katacoda: Anotar el puerto de 5 dígitos ubicado al lado del valor de `8080` en el resultado de servicios. Este número de puerto es generado aleatoriamente y puede ser diferente al indicado en el ejemplo. Escribir el número de puerto en el cuadro de texto y hacer clic en Display Port. Usando el ejemplo anterior, usted escribiría `30369`. Esto abre una ventana de navegador que contiene la aplicación y muestra el mensaje "Hello World". ## Habilitar Extensiones -Minikube tiene un conjunto de {{< glossary_tooltip text="Extensiones" term_id="addons" >}} que pueden ser habilitados y desahabilitados en el ambiente local de Kubernetes. +Minikube tiene un conjunto de {{< glossary_tooltip text="Extensiones" term_id="addons" >}} que pueden ser habilitados y desahabilitados en el entorno local de Kubernetes. 1. Listar las extensiones soportadas actualmente: diff --git a/content/es/partners/_index.html b/content/es/partners/_index.html index 87ae9d5349a9d..afb2f6128f1de 100644 --- a/content/es/partners/_index.html +++ b/content/es/partners/_index.html @@ -7,85 +7,48 @@ ---
-
-
Kubernetes trabaja con socios para crear una base de código sólida y vibrante que admita un espectro de plataformas complementarias.
-
-
-
-
- Kubernetes Certified Service Providers -
-
Proveedores de servicios con amplia experiencia ayudando a las empresas a adoptar Kubernetes con éxito. -


- -

Conviértete en KCSP -
-
-
-
-
- Certified Kubernetes Distributions, Hosted Platforms, and Installers -
La conformidad del software garantiza que la versión de Kubernetes de cada proveedor sea compatible con las API requeridas. -


- -

Conviértete en Certified Kubernetes -
-
-
-
-
Kubernetes Training Partners
-
Partners de formación que ofrecen cursos de alta calidad y con una amplia experiencia en formación de tecnologías nativas de la nube. -



- -

Conviértete en KTP -
-
-
- - - -
- - +
Kubernetes trabaja con socios para crear una base de código sólida y vibrante que admita un espectro de plataformas complementarias.
+
+
+
+
+ Kubernetes Certified Service Providers +
+
Proveedores de servicios con amplia experiencia ayudando a las empresas a adoptar Kubernetes con éxito. +


+ +

Conviértete en + KCSP? +
+
+
+
+
+ Certified Kubernetes Distributions, Hosted Platforms, and Installers +
La conformidad del software garantiza que la versión de Kubernetes de cada proveedor sea compatible con las API requeridas. +


+ +

Conviértete en + Certified Kubernetes? +
+
+
+
+
+ Kubernetes Training Partners +
+
Partners de formación que ofrecen cursos de alta calidad y con una amplia experiencia en formación de tecnologías nativas de la nube. +


+ +

Conviértete en + KTP? +
+
- -
+ {{< cncf-landscape helpers=true >}}
- diff --git a/content/fr/docs/setup/custom-cloud/kubespray.md b/content/fr/docs/setup/custom-cloud/kubespray.md index cde3cbb3f92e2..4a9709818d51b 100644 --- a/content/fr/docs/setup/custom-cloud/kubespray.md +++ b/content/fr/docs/setup/custom-cloud/kubespray.md @@ -15,8 +15,8 @@ Kubespray se base sur des outils de provisioning, des [paramètres](https://gith * Le support des principales distributions Linux: * Container Linux de CoreOS * Debian Jessie, Stretch, Wheezy - * Ubuntu 16.04, 18.04 - * CentOS/RHEL 7 + * Ubuntu 16.04, 18.04, 20.04, 22.04 + * CentOS/RHEL 7, 8 * Fedora/CentOS Atomic * openSUSE Leap 42.3/Tumbleweed * des tests d'intégration continue @@ -33,8 +33,8 @@ Afin de choisir l'outil le mieux adapté à votre besoin, veuillez lire [cette c Les serveurs doivent être installés en s'assurant des éléments suivants: -* **Ansible v2.6 (ou version plus récente) et python-netaddr installés sur la machine qui exécutera les commandes Ansible** -* **Jinja 2.9 (ou version plus récente) est nécessaire pour exécuter les playbooks Ansible** +* **Ansible v2.11 (ou version plus récente) et python-netaddr installés sur la machine qui exécutera les commandes Ansible** +* **Jinja 2.11 (ou version plus récente) est nécessaire pour exécuter les playbooks Ansible** * Les serveurs cibles doivent avoir **accès à Internet** afin de télécharger les images Docker. Autrement, une configuration supplémentaire est nécessaire, (se référer à [Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/downloads.md#offline-environment)) * Les serveurs cibles doivent être configurés afin d'autoriser le transfert IPv4 (**IPv4 forwarding**) * **Votre clé ssh doit être copiée** sur tous les serveurs faisant partie de votre inventaire Ansible. diff --git a/content/id/docs/concepts/cluster-administration/addons.md b/content/id/docs/concepts/cluster-administration/addons.md index 5d44364314d8a..a39668ee2472b 100644 --- a/content/id/docs/concepts/cluster-administration/addons.md +++ b/content/id/docs/concepts/cluster-administration/addons.md @@ -22,15 +22,15 @@ Laman ini akan menjabarkan beberapa *add-ons* yang tersedia serta tautan instruk * [ACI](https://www.github.com/noironetworks/aci-containers) menyediakan integrasi jaringan kontainer dan keamanan jaringan dengan Cisco ACI. * [Calico](https://docs.projectcalico.org/latest/getting-started/kubernetes/) merupakan penyedia jaringan L3 yang aman dan *policy* jaringan. -* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) menggabungkan Flannel dan Calico, menyediakan jaringan serta *policy* jaringan. +* [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) menggabungkan Flannel dan Calico, menyediakan jaringan serta *policy* jaringan. * [Cilium](https://github.com/cilium/cilium) merupakan *plugin* jaringan L3 dan *policy* jaringan yang dapat menjalankan *policy* HTTP/API/L7 secara transparan. Mendukung mode *routing* maupun *overlay/encapsulation*. -* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) memungkinkan Kubernetes agar dapat terkoneksi dengan beragam *plugin* CNI, seperti Calico, Canal, Flannel, Romana, atau Weave dengan mulus. +* [CNI-Genie](https://github.com/cni-genie/CNI-Genie) memungkinkan Kubernetes agar dapat terkoneksi dengan beragam *plugin* CNI, seperti Calico, Canal, Flannel, Romana, atau Weave dengan mulus. * [Contiv](http://contiv.github.io) menyediakan jaringan yang dapat dikonfigurasi (*native* L3 menggunakan BGP, *overlay* menggunakan vxlan, klasik L2, dan Cisco-SDN/ACI) untuk berbagai penggunaan serta *policy framework* yang kaya dan beragam. Proyek Contiv merupakan proyek [open source](http://github.com/contiv). Laman [instalasi](http://github.com/contiv/install) ini akan menjabarkan cara instalasi, baik untuk klaster dengan kubeadm maupun non-kubeadm. * [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), yang berbasis dari [Tungsten Fabric](https://tungsten.io), merupakan sebuah proyek *open source* yang menyediakan virtualisasi jaringan *multi-cloud* serta platform manajemen *policy*. Contrail dan Tungsten Fabric terintegrasi dengan sistem orkestrasi lainnya seperti Kubernetes, OpenShift, OpenStack dan Mesos, serta menyediakan mode isolasi untuk mesin virtual (VM), kontainer/pod dan *bare metal*. * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) merupakan penyedia jaringan *overlay* yang dapat digunakan pada Kubernetes. * [Knitter](https://github.com/ZTE/Knitter/) merupakan solusi jaringan yang mendukung multipel jaringan pada Kubernetes. -* Multus merupakan sebuah multi *plugin* agar Kubernetes mendukung multipel jaringan secara bersamaan sehingga dapat menggunakan semua *plugin* CNI (contoh: Calico, Cilium, Contiv, Flannel), ditambah pula dengan SRIOV, DPDK, OVS-DPDK dan VPP pada *workload* Kubernetes. -* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) menyediakan integrasi antara VMware NSX-T dan orkestrator kontainer seperti Kubernetes, termasuk juga integrasi antara NSX-T dan platform CaaS/PaaS berbasis kontainer seperti *Pivotal Container Service* (PKS) dan OpenShift. +* [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) merupakan sebuah multi *plugin* agar Kubernetes mendukung multipel jaringan secara bersamaan sehingga dapat menggunakan semua *plugin* CNI (contoh: Calico, Cilium, Contiv, Flannel), ditambah pula dengan SRIOV, DPDK, OVS-DPDK dan VPP pada *workload* Kubernetes. +* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) Container Plug-in (NCP) menyediakan integrasi antara VMware NSX-T dan orkestrator kontainer seperti Kubernetes, termasuk juga integrasi antara NSX-T dan platform CaaS/PaaS berbasis kontainer seperti *Pivotal Container Service* (PKS) dan OpenShift. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) merupakan platform SDN yang menyediakan *policy-based* jaringan antara Kubernetes Pods dan non-Kubernetes *environment* dengan *monitoring* visibilitas dan keamanan. * [Romana](http://romana.io) merupakan solusi jaringan *Layer* 3 untuk jaringan pod yang juga mendukung [*NetworkPolicy* API](/id/docs/concepts/services-networking/network-policies/). Instalasi Kubeadm *add-on* ini tersedia [di sini](https://github.com/romana/romana/tree/master/containerize). * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) menyediakan jaringan serta *policy* jaringan, yang akan membawa kedua sisi dari partisi jaringan, serta tidak membutuhkan basis data eksternal. diff --git a/content/it/docs/concepts/cluster-administration/addons.md b/content/it/docs/concepts/cluster-administration/addons.md index aed6cdf7561e0..782ce4ecfa491 100644 --- a/content/it/docs/concepts/cluster-administration/addons.md +++ b/content/it/docs/concepts/cluster-administration/addons.md @@ -22,14 +22,14 @@ I componenti aggiuntivi in ogni sezione sono ordinati alfabeticamente - l'ordine * [ACI](https://www.github.com/noironetworks/aci-containers) fornisce funzionalità integrate di networking e sicurezza di rete con Cisco ACI. * [Calico](https://docs.projectcalico.org/latest/getting-started/kubernetes/) è un provider di sicurezza e rete L3 sicuro. -* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unisce Flannel e Calico, fornendo i criteri di rete e di rete. +* [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) unisce Flannel e Calico, fornendo i criteri di rete e di rete. * [Cilium](https://github.com/cilium/cilium) è un plug-in di criteri di rete e di rete L3 in grado di applicare in modo trasparente le politiche HTTP / API / L7. Sono supportate entrambe le modalità di routing e overlay / incapsulamento. -* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) consente a Kubernetes di connettersi senza problemi a una scelta di plugin CNI, come Calico, Canal, Flannel, Romana o Weave. +* [CNI-Genie](https://github.com/cni-genie/CNI-Genie) consente a Kubernetes di connettersi senza problemi a una scelta di plugin CNI, come Calico, Canal, Flannel, Romana o Weave. * [Contiv](https://contivpp.io/) offre networking configurabile (L3 nativo con BGP, overlay con vxlan, L2 classico e Cisco-SDN / ACI) per vari casi d'uso e un ricco framework di policy. Il progetto Contiv è completamente [open source](http://github.com/contiv). Il [programma di installazione](http://github.com/contiv/install) fornisce sia opzioni di installazione basate su kubeadm che non su Kubeadm. * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) è un provider di reti sovrapposte che può essere utilizzato con Kubernetes. * [Knitter](https://github.com/ZTE/Knitter/) è una soluzione di rete che supporta più reti in Kubernetes. -* Multus è un multi-plugin per il supporto di più reti in Kubernetes per supportare tutti i plugin CNI (es. Calico, Cilium, Contiv, Flannel), oltre a SRIOV, DPDK, OVS-DPDK e carichi di lavoro basati su VPP in Kubernetes. -* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) fornisce l'integrazione tra VMware NSX-T e orchestratori di contenitori come Kubernetes, oltre all'integrazione tra NSX-T e piattaforme CaaS / PaaS basate su container come Pivotal Container Service (PKS) e OpenShift. +* [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) è un multi-plugin per il supporto di più reti in Kubernetes per supportare tutti i plugin CNI (es. Calico, Cilium, Contiv, Flannel), oltre a SRIOV, DPDK, OVS-DPDK e carichi di lavoro basati su VPP in Kubernetes. +* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) Container Plug-in (NCP) fornisce l'integrazione tra VMware NSX-T e orchestratori di contenitori come Kubernetes, oltre all'integrazione tra NSX-T e piattaforme CaaS / PaaS basate su container come Pivotal Container Service (PKS) e OpenShift. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1/docs/kubernetes-1-installation.rst) è una piattaforma SDN che fornisce una rete basata su policy tra i pod di Kubernetes e non Kubernetes con visibilità e monitoraggio della sicurezza. * [Romana](https://github.com/romana/romana) è una soluzione di rete Layer 3 per pod network che supporta anche [API NetworkPolicy](/docs/concepts/services-networking/network-policies/). Dettagli di installazione del componente aggiuntivo di Kubeadm disponibili [qui](https://github.com/romana/romana/tree/master/containerize). * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) fornisce i criteri di rete e di rete, continuerà a funzionare su entrambi i lati di una partizione di rete e non richiede un database esterno. diff --git a/content/ja/docs/concepts/configuration/secret.md b/content/ja/docs/concepts/configuration/secret.md index ca8b3126593cb..3a2dd6ce43141 100644 --- a/content/ja/docs/concepts/configuration/secret.md +++ b/content/ja/docs/concepts/configuration/secret.md @@ -277,7 +277,7 @@ kubectl create secret tls my-tls-secret \ Bootstrap token Secretは、Secretの`type`を`bootstrap.kubernetes.io/token`に明示的に指定することで作成できます。このタイプのSecretは、ノードのブートストラッププロセス中に使用されるトークン用に設計されています。よく知られているConfigMapに署名するために使用されるトークンを格納します。 -Bootstrap toke Secretは通常、`kube-system`namespaceで作成され`bootstrap-token-`の形式で名前が付けられます。ここで``はトークンIDの6文字の文字列です。 +Bootstrap token Secretは通常、`kube-system`namespaceで作成され`bootstrap-token-`の形式で名前が付けられます。ここで``はトークンIDの6文字の文字列です。 Kubernetesマニフェストとして、Bootstrap token Secretは次のようになります。 diff --git a/content/ja/docs/setup/production-environment/tools/kubespray.md b/content/ja/docs/setup/production-environment/tools/kubespray.md index 4fe5c6e978b66..9d6497c0547af 100644 --- a/content/ja/docs/setup/production-environment/tools/kubespray.md +++ b/content/ja/docs/setup/production-environment/tools/kubespray.md @@ -6,19 +6,20 @@ 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: * a highly available cluster * composable attributes * support for most popular Linux distributions - * Container Linux by CoreOS + * Ubuntu 16.04, 18.04, 20.04, 22.04 + * CentOS/RHEL/Oracle Linux 7, 8 * Debian Buster, Jessie, Stretch, Wheezy - * Ubuntu 16.04, 18.04 - * CentOS/RHEL/Oracle Linux 7 - * Fedora 28 + * Fedora 34, 35 + * Fedora CoreOS * openSUSE Leap 15 + * Flatcar Container Linux by Kinvolk * continuous integration tests To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to @@ -34,13 +35,13 @@ To choose a tool which best fits your use case, read [this comparison](https://g Provision servers with the following [requirements](https://github.com/kubernetes-sigs/kubespray#requirements): -* **Ansible v2.7.8 and python-netaddr is installed on the machine that will run Ansible commands** -* **Jinja 2.9 (or newer) is required to run the Ansible Playbooks** +* **Ansible v2.11 and python-netaddr are installed on the machine that will run Ansible commands** +* **Jinja 2.11 (or newer) is required to run the Ansible Playbooks** * The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)) * The target servers are configured to allow **IPv4 forwarding** -* **Your ssh key must be copied** to all the servers part of your inventory -* The **firewalls are not managed**, you'll need to implement your own rules the way you used to. in order to avoid any issue during deployment you should disable your firewall -* If kubespray is ran from non-root user account, correct privilege escalation method should be configured in the target servers. Then the `ansible_become` flag or command parameters `--become` or `-b` should be specified +* **Your ssh key must be copied** to all the servers in your inventory +* **Firewalls are not managed by kubespray**. You'll need to implement appropriate rules as needed. You should disable your firewall in order to avoid any issues during deployment +* If kubespray is run from a non-root user account, correct privilege escalation method should be configured in the target servers and the `ansible_become` flag or command parameters `--become` or `-b` should be specified Kubespray provides the following utilities to help provision your environment: diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index a91b5a91705a1..5e8d7b2734f6f 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -28,7 +28,7 @@ APIService를 구현하는 가장 일반적인 방법은 클러스터 내에 실 Extension-apiserver는 kube-apiserver로 오가는 연결의 레이턴시가 낮아야 한다. kube-apiserver로 부터의 디스커버리 요청은 왕복 레이턴시가 5초 이내여야 한다. -extention API server가 레이턴시 요구 사항을 달성할 수 없는 경우 이를 충족할 수 있도록 변경하는 것을 고려한다. +Extension API server가 레이턴시 요구 사항을 달성할 수 없는 경우 이를 충족할 수 있도록 변경하는 것을 고려한다. ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/contribute/localization_ko.md b/content/ko/docs/contribute/localization_ko.md index e2e10f01cc8cf..aee88732483b0 100644 --- a/content/ko/docs/contribute/localization_ko.md +++ b/content/ko/docs/contribute/localization_ko.md @@ -19,7 +19,7 @@ content_type: concept 위한 팀 마일스톤과 개발 브랜치를 관리한다. 본 섹션은 한글화팀의 팀 마일스톤 관리에 특화된 내용을 다룬다. -한글화팀은 `master` 브랜치에서 분기한 개발 브랜치를 사용한다. 개발 브랜치 이름은 다음과 같은 +한글화팀은 `main` 브랜치에서 분기한 개발 브랜치를 사용한다. 개발 브랜치 이름은 다음과 같은 구조를 갖는다. `dev-<소스 버전>-ko.<팀 마일스톤>` @@ -46,7 +46,7 @@ content_type: concept - [CLA 서명 없음, 병합할 수 없음](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fko) - [LGTM 필요](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fko+-label%3Algtm+) - [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fko+label%3Algtm) -- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fko%22+) +- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amain+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fko%22+) 팀 마일스톤 일정과 PR 랭글러는 커뮤니티 슬랙 내 [#kubernetes-docs-ko 채널](https://kubernetes.slack.com/archives/CA1MMR86S)에 공지된다. @@ -221,7 +221,7 @@ API 오브젝트의 필드 이름, 파일 이름, 경로와 같은 내용은 독 한글화 용어집의 개선(추가, 수정, 삭제 등)을 위한 과정은 다음과 같다. -1. 컨트리뷰터가 개선이 필요한 용어을 파악하면, ISSUE를 생성하여 개선 필요성을 공유하거나 `master` 브랜치에 +1. 컨트리뷰터가 개선이 필요한 용어을 파악하면, ISSUE를 생성하여 개선 필요성을 공유하거나 `main` 브랜치에 PR을 생성하여 개선된 용어를 제안한다. 1. 개선 제안에 대한 논의는 ISSUE 및 PR을 통해서 이루어지며, 한글화팀 회의를 통해 확정한다. diff --git a/content/ko/docs/setup/production-environment/tools/kubespray.md b/content/ko/docs/setup/production-environment/tools/kubespray.md index 598ad326099a9..16cae936fabb1 100644 --- a/content/ko/docs/setup/production-environment/tools/kubespray.md +++ b/content/ko/docs/setup/production-environment/tools/kubespray.md @@ -13,10 +13,10 @@ Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](h * 고가용성을 지닌 클러스터 * 구성할 수 있는 속성들 * 대부분의 인기있는 리눅스 배포판들에 대한 지원 - * Ubuntu 16.04, 18.04, 20.04 + * Ubuntu 16.04, 18.04, 20.04, 22.04 * CentOS/RHEL/Oracle Linux 7, 8 * Debian Buster, Jessie, Stretch, Wheezy - * Fedora 31, 32 + * Fedora 34, 35 * Fedora CoreOS * openSUSE Leap 15 * Flatcar Container Linux by Kinvolk @@ -33,7 +33,7 @@ Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](h 언더레이(underlay) [요건](https://github.com/kubernetes-sigs/kubespray#requirements)을 만족하는 프로비전 한다. -* **Ansible의 명령어를 실행하기 위해 Ansible v 2.9와 Python netaddr 라이브러리가 머신에 설치되어 있어야 한다** +* **Ansible의 명령어를 실행하기 위해 Ansible v 2.11와 Python netaddr 라이브러리가 머신에 설치되어 있어야 한다** * **Ansible 플레이북을 실행하기 위해 2.11 (혹은 그 이상) 버전의 Jinja가 필요하다** * 타겟 서버들은 docker 이미지를 풀(pull) 하기 위해 반드시 인터넷에 접속할 수 있어야 한다. 아니라면, 추가적인 설정을 해야 한다 ([오프라인 환경 확인하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)) * 타겟 서버들의 **IPv4 포워딩**이 활성화되어야 한다 diff --git a/content/ko/examples/admin/konnectivity/egress-selector-configuration.yaml b/content/ko/examples/admin/konnectivity/egress-selector-configuration.yaml index ca19321d80fc2..fee3016e8cf7a 100644 --- a/content/ko/examples/admin/konnectivity/egress-selector-configuration.yaml +++ b/content/ko/examples/admin/konnectivity/egress-selector-configuration.yaml @@ -2,7 +2,7 @@ apiVersion: apiserver.k8s.io/v1beta1 kind: EgressSelectorConfiguration egressSelections: # 클러스터에 대한 송신(egress) 트래픽을 제어하기 위해 -# "cluster"를 name으로 사용한다. 기타 지원되는 값은 "etcd" 및 "master"이다. +# "cluster"를 name으로 사용한다. 기타 지원되는 값은 "etcd" 및 "controlplane"이다. - name: cluster connection: # API 서버와 Konnectivity 서버 간의 프로토콜을 diff --git a/content/pt-br/docs/reference/glossary/rbac.md b/content/pt-br/docs/reference/glossary/rbac.md new file mode 100644 index 0000000000000..b868363fde700 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/rbac.md @@ -0,0 +1,20 @@ +--- +title: RBAC (Controle de Acesso Baseado em Funções) +id: rbac +date: 2018-04-12 +full_link: /docs/reference/access-authn-authz/rbac/ +short_description: > + Gerencia decisões de autorização, permitindo que os administradores configurem dinamicamente políticas de acesso por meio da API do Kubernetes. + +aka: + - Role Based Access Control + - Controle de Acesso Baseado em Funções +tags: +- security +- fundamental +--- + Gerencia decisões de autorização, permitindo que os administradores configurem dinamicamente políticas de acesso por meio da {{< glossary_tooltip text="API do Kubernetes" term_id="kubernetes-api" >}}. + + + +O RBAC (do inglês - Role-Based Access Control) utiliza *funções*, que contêm regras de permissão, e *atribuição das funções*, que concedem as permissões definidas em uma função a um conjunto de usuários. \ No newline at end of file diff --git a/content/vi/partners/_index.html b/content/vi/partners/_index.html index f5b44d5e94886..3ea37f2242a0d 100644 --- a/content/vi/partners/_index.html +++ b/content/vi/partners/_index.html @@ -7,85 +7,48 @@ ---
-
-
Kubernetes phối hợp làm việc với các đối tác để tạo ra một codebase mạnh mẽ hỗ trợ một loạt các nền tảng bổ sung.
-
-
-
-
- Các nhà cung cấp dịch vụ được chứng nhận bởi Kubernetes (KCSP) -
-
Các nhà cung cấp dịch vụ được chứng nhận với bề dày kinh nghiệm sẽ trợ giúp các tổ chức kinh doanh, các công ty ứng dụng Kubernetes nhanh chóng. -


- -

Bạn muốn trở thành một KCSP? -
-
-
-
-
- Các nhà phân phối Kubernetes, dịch vụ hosting, dịch vụ cài đặt -
Tiêu chuẩn tương thích về phần mềm bảo đảm rằng các phiên bản Kubernetes từ các nhà cung cấp sẽ hỗ trợ các bộ API được yêu cầu bởi khách hàng. -


- -

Bạn muốn trở thành một Kubernetes Certified? -
-
-
-
-
Các đối tác đào tạo Kubernetes (KTP)
-
Các đối tác đào tạo được chứng nhận đã và đang sở hữu bề dày kinh nghiệm trong lĩnh vực đám mây. -



- -

Bạn muốn trở thành một KTP? -
-
-
- - - -
- - +
Kubernetes phối hợp làm việc với các đối tác để tạo ra một codebase mạnh mẽ hỗ trợ một loạt các nền tảng bổ sung.
+
+
+
+
+ Các nhà cung cấp dịch vụ được chứng nhận bởi Kubernetes (KCSP) +
+
Các nhà cung cấp dịch vụ được chứng nhận với bề dày kinh nghiệm sẽ trợ giúp các tổ chức kinh doanh, các công ty ứng dụng Kubernetes nhanh chóng. +


+ +

Bạn muốn trở thành một + KCSP? +
+
+
+
+
+ Các nhà phân phối Kubernetes, dịch vụ hosting, dịch vụ cài đặt +
Tiêu chuẩn tương thích về phần mềm bảo đảm rằng các phiên bản Kubernetes từ các nhà cung cấp sẽ hỗ trợ các bộ API được yêu cầu bởi khách hàng. +


+ +

Bạn muốn trở thành một + Kubernetes Certified? +
+
+
+
+
+ Các đối tác đào tạo Kubernetes (KTP) +
+
Các đối tác đào tạo được chứng nhận đã và đang sở hữu bề dày kinh nghiệm trong lĩnh vực đám mây. +


+ +

Bạn muốn trở thành một + KTP? +
+
- -
+ {{< cncf-landscape helpers=true >}}
- diff --git a/content/zh-cn/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md b/content/zh-cn/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md index 0adca625e39f1..e7bd4275657bb 100644 --- a/content/zh-cn/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md +++ b/content/zh-cn/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md @@ -1,27 +1,35 @@ --- layout: blog title: "认识我们的贡献者 - 亚太地区(印度地区)" -date: 2022-01-10T12:00:00+0000 +date: 2022-01-10 slug: meet-our-contributors-india-ep-01 -canonicalUrl: https://kubernetes.dev/blog/2022/01/10/meet-our-contributors-india-ep-01/ +canonicalUrl: https://www.kubernetes.dev/blog/2022/01/10/meet-our-contributors-india-ep-01/ --- -**作者和采访者:** [Anubhav Vardhan](https://github.com/anubha-v-ardhan) , [Atharva Shinde](https://github.com/Atharva-Shinde) , [Avinesh Tripathi](https://github.com/AvineshTripathi) , [Debabrata Panigrahi](https://github.com/Debanitrkl) , [Kunal Verma](https://github.com/verma-kunal) , [Pranshu Srivastava](https://github.com/PranshuSrivastava) , [Pritish Samal](https://github.com/CIPHERTron) , [Purneswar Prasad](https://github.com/PurneswarPrasad) , [Vedant Kakde](https://github.com/vedant-kakde) +**作者和采访者:** [Anubhav Vardhan](https://github.com/anubha-v-ardhan)、 +[Atharva Shinde](https://github.com/Atharva-Shinde)、 +[Avinesh Tripathi](https://github.com/AvineshTripathi)、 +[Debabrata Panigrahi](https://github.com/Debanitrkl)、 +[Kunal Verma](https://github.com/verma-kunal)、 +[Pranshu Srivastava](https://github.com/PranshuSrivastava)、 +[Pritish Samal](https://github.com/CIPHERTron)、 +[Purneswar Prasad](https://github.com/PurneswarPrasad)、 +[Vedant Kakde](https://github.com/vedant-kakde) -**编辑:** [Priyanka Saggu](https://psaggu.com) +**编辑:** [Priyanka Saggu](https://psaggu.com) --- @@ -39,10 +47,10 @@ Welcome to the first episode of the APAC edition of the "Meet Our Contributors" -在这篇文章中,我们将向您介绍来自印度地区的五位优秀贡献者,他们一直在以各种方式积极地为上游 Kubernetes 项目做贡献,同时也是众多社区倡议的领导者和维护者。 +在这篇文章中,我们将向你介绍来自印度地区的五位优秀贡献者,他们一直在以各种方式积极地为上游 Kubernetes 项目做贡献,同时也是众多社区倡议的领导者和维护者。 💫 *闲话少说,我们开始吧。* @@ -70,7 +78,9 @@ To the newcomers, Arsh helps plan their early contributions sustainably. > actually handle. This can often lead to burnout in later stages. It's much more sustainable > to work on things iteratively._ --> -> _我鼓励大家以可持续的方式为社区做贡献。我的意思是,一个人很容易在早期的时候非常有热情,并且承担了很多超出个人实际能力的事情。这通常会导致后期的倦怠。迭代地处理事情会让大家对社区的贡献变得可持续。_ +> 我鼓励大家以可持续的方式为社区做贡献。 +> 我的意思是,一个人很容易在早期的时候非常有热情,并且承担了很多超出个人实际能力的事情。 +> 这通常会导致后期的倦怠。迭代地处理事情会让大家对社区的贡献变得可持续。 ## [Kunal Kushwaha](https://github.com/kunal-kushwaha) @@ -80,7 +90,7 @@ Kunal Kushwaha is a core member of the Kubernetes marketing council. He is also Kunal Kushwaha 是 Kubernetes 营销委员会的核心成员。他同时也是 [CNCF 学生计划](https://community.cncf.io/cloud-native-students/) 的创始人之一。他还在 1.22 版本周期中担任通信经理一职。 在他的第一年结束时,Kunal 开始为 [fabric8io kubernetes-client](https://github.com/fabric8io/kubernetes-client) 项目做贡献。然后,他被推选从事同一项目,此项目是 Google Summer of Code 的一部分。Kunal 在 Google Summer of Code、Google Code-in 等项目中指导过很多人。 @@ -99,7 +109,11 @@ As an open-source enthusiast, he believes that diverse participation in the comm > because being a beginner is a skill and you can bring new perspectives to the > organisation._ --> -> _我相信,如果你发现自己在一个了解不多的项目当中,那是件好事,因为现在你可以一边贡献一边学习,社区也会帮助你。它帮助我获得了很多技能,认识了来自世界各地的人,也帮助了他们。你可以在这个过程中学习,自己不一定必须是专家。请重视非代码贡献,因为作为初学者这是一项技能,你可以为组织带来新的视角。_ +> 我相信,如果你发现自己在一个了解不多的项目当中,那是件好事, +> 因为现在你可以一边贡献一边学习,社区也会帮助你。 +> 它帮助我获得了很多技能,认识了来自世界各地的人,也帮助了他们。 +> 你可以在这个过程中学习,自己不一定必须是专家。 +> 请重视非代码贡献,因为作为初学者这是一项技能,你可以为组织带来新的视角。 ## [Madhav Jivarajani](https://github.com/MadhavJivrajani) @@ -112,12 +126,19 @@ Madhav Jivarajani 在 VMware 上游 Kubernetes 稳定性团队工作。他于 20 -在这几个重要项目中,他最近致力于 [设计方案](https://github.com/kubernetes/community/issues/6055) 的存档工作,重构 k8s-infra 存储库下的 ["组"代码库](https://github.com/kubernetes/k8s.io/pull/2713) ,使其具有可模拟性和可测试性,以及改进 [GitHub k8s 机器人](https://github.com/kubernetes/test-infra/issues/23129) 的功能。 +在这几个重要项目中,他最近致力于[设计方案](https://github.com/kubernetes/community/issues/6055)的存档工作, +重构 k8s-infra 存储库下的 ["组"代码库](https://github.com/kubernetes/k8s.io/pull/2713), +使其具有可模拟性和可测试性,以及改进 [GitHub k8s 机器人](https://github.com/kubernetes/test-infra/issues/23129)的功能。 -除了在技术方面的贡献,Madhav 还监督许多旨在帮助新贡献者的项目。他每两周组织一次的“KEP 阅读俱乐部”会议,帮助新人了解添加新功能、摒弃旧功能以及对上游项目进行其他关键更改的过程。他还致力于开发 [Katacoda 场景](https://github.com/kubernetes-sigs/contributor-katacoda) ,以帮助新的贡献者在为 k/k 做贡献的过程更加熟练。目前除了每周与社区成员会面外,他还组织了几个 [新贡献者讲习班(NCW)](https://www.youtube.com/watch?v=FgsXbHBRYIc) 。 +除了在技术方面的贡献,Madhav 还监督许多旨在帮助新贡献者的项目。 +他每两周组织一次的 “KEP 阅读俱乐部” 会议,帮助新人了解添加新功能、 +摒弃旧功能以及对上游项目进行其他关键更改的过程。他还致力于开发 +[Katacoda 场景](https://github.com/kubernetes-sigs/contributor-katacoda), +以帮助新的贡献者在为 k/k 做贡献的过程更加熟练。目前除了每周与社区成员会面外, +他还组织了几个[新贡献者讲习班(NCW)](https://www.youtube.com/watch?v=FgsXbHBRYIc)。 -> _一开始我对 Kubernetes 了解并不多。我加入社区是因为社区超级友好。但让我留下来的不仅仅是人,还有项目本身。我在社区中不会感到不知所措,这是因为我能够在感兴趣的和正在讨论的主题中获得尽可能多的背景和知识。因此,我将继续深入探讨 Kubernetes 及其设计。我是一个系统迷,kubernetes 对我来说绝对是一个金矿。_ +> 一开始我对 Kubernetes 了解并不多。我加入社区是因为社区超级友好。 +> 但让我留下来的不仅仅是人,还有项目本身。我在社区中不会感到不知所措, +> 这是因为我能够在感兴趣的和正在讨论的主题中获得尽可能多的背景和知识。 +> 因此,我将继续深入探讨 Kubernetes 及其设计。 +> 我是一个系统迷,kubernetes 对我来说绝对是一个金矿。 ## [Rajas Kakodkar](https://github.com/rajaskakodkar) @@ -152,7 +177,8 @@ One of the first challenges he ran across was that he was in a different time zo > cutting edge tech but more importantly because I get to work with > awesome people and help in solving real world problems._ --> -> _我喜欢为 kubernetes 做出贡献,不仅因为我可以从事尖端技术工作,更重要的是,我可以和优秀的人一起工作,并帮助解决现实问题。_ +> 我喜欢为 kubernetes 做出贡献,不仅因为我可以从事尖端技术工作, +> 更重要的是,我可以和优秀的人一起工作,并帮助解决现实问题。 ## [Rajula Vineet Reddy](https://github.com/rajula96reddy) @@ -180,18 +206,19 @@ Rajas 说,参与项目会议和跟踪各种项目角色对于了解社区至 > _The first step to_ “come forward and start” _is hard. But it's all gonna be > smooth after that. Just take that jump._ --> -> _我发现社区非常有帮助,而且总是“你得到的回报和你贡献的一样多”。你参与得越多,你就越会了解、学习和贡献新东西。_ -> _“挺身而出”的第一步是艰难的。但在那之后一切都会顺利的。勇敢地参与进来吧。_ +> 我发现社区非常有帮助,而且总是“你得到的回报和你贡献的一样多”。 +> 你参与得越多,你就越会了解、学习和贡献新东西。 +> +> “挺身而出”的第一步是艰难的。但在那之后一切都会顺利的。勇敢地参与进来吧。 + --- -如果您对我们下一步应该采访谁有任何意见/建议,请在 #sig-contribex 中告知我们。我们很高兴有其他人帮助我们接触社区中更优秀的人。我们将不胜感激。 - +如果你对我们下一步应该采访谁有任何意见/建议,请在 #sig-contribex 中告知我们。我们很高兴有其他人帮助我们接触社区中更优秀的人。我们将不胜感激。 我们下期见。最后,祝大家都能快乐地为社区做贡献!👋 - diff --git a/content/zh-cn/blog/_posts/2022-03-15-meet-our-contributors-APAC-AU-NZ-region-01.md b/content/zh-cn/blog/_posts/2022-03-15-meet-our-contributors-APAC-AU-NZ-region-02.md similarity index 87% rename from content/zh-cn/blog/_posts/2022-03-15-meet-our-contributors-APAC-AU-NZ-region-01.md rename to content/zh-cn/blog/_posts/2022-03-15-meet-our-contributors-APAC-AU-NZ-region-02.md index 1b658bc9cf438..6b01e42be9366 100644 --- a/content/zh-cn/blog/_posts/2022-03-15-meet-our-contributors-APAC-AU-NZ-region-01.md +++ b/content/zh-cn/blog/_posts/2022-03-15-meet-our-contributors-APAC-AU-NZ-region-02.md @@ -1,14 +1,14 @@ --- layout: blog title: "认识我们的贡献者 - 亚太地区(澳大利亚-新西兰地区)" -date: 2022-03-16T12:00:00+0000 +date: 2022-03-16 slug: meet-our-contributors-au-nz-ep-02 canonicalUrl: https://www.kubernetes.dev/blog/2022/03/14/meet-our-contributors-au-nz-ep-02/ --- @@ -17,16 +17,16 @@ canonicalUrl: https://www.kubernetes.dev/blog/2022/03/14/meet-our-contributors-a **Authors & Interviewers:** [Anubhav Vardhan](https://github.com/anubha-v-ardhan), [Atharva Shinde](https://github.com/Atharva-Shinde), [Avinesh Tripathi](https://github.com/AvineshTripathi), [Brad McCoy](https://github.com/bradmccoydev), [Debabrata Panigrahi](https://github.com/Debanitrkl), [Jayesh Srivastava](https://github.com/jayesh-srivastava), [Kunal Verma](https://github.com/verma-kunal), [Pranshu Srivastava](https://github.com/PranshuSrivastava), [Priyanka Saggu](github.com/Priyankasaggu11929/), [Purneswar Prasad](https://github.com/PurneswarPrasad), [Vedant Kakde](https://github.com/vedant-kakde) --> **作者和采访者:** -[Anubhav Vardhan](https://github.com/anubha-v-ardhan), -[Atharva Shinde](https://github.com/Atharva-Shinde), -[Avinesh Tripathi](https://github.com/AvineshTripathi), -[Brad McCoy](https://github.com/bradmccoydev), -[Debabrata Panigrahi](https://github.com/Debanitrkl), -[Jayesh Srivastava](https://github.com/jayesh-srivastava), -[Kunal Verma](https://github.com/verma-kunal), -[Pranshu Srivastava](https://github.com/PranshuSrivastava), -[Priyanka Saggu](github.com/Priyankasaggu11929/), -[Purneswar Prasad](https://github.com/PurneswarPrasad), +[Anubhav Vardhan](https://github.com/anubha-v-ardhan)、 +[Atharva Shinde](https://github.com/Atharva-Shinde)、 +[Avinesh Tripathi](https://github.com/AvineshTripathi)、 +[Brad McCoy](https://github.com/bradmccoydev)、 +[Debabrata Panigrahi](https://github.com/Debanitrkl)、 +[Jayesh Srivastava](https://github.com/jayesh-srivastava)、 +[Kunal Verma](https://github.com/verma-kunal)、 +[Pranshu Srivastava](https://github.com/PranshuSrivastava)、 +[Priyanka Saggu](github.com/Priyankasaggu11929/)、 +[Purneswar Prasad](https://github.com/PurneswarPrasad)、 [Vedant Kakde](https://github.com/vedant-kakde) --- @@ -79,8 +79,8 @@ Caleb 也是 [CloudNative NZ](https://www.meetup.com/cloudnative-nz/) -> _亚太地区需要更多的外联活动,教育工作者和大学必须学习 Kubernetes,因为他们非常缓慢, -而且已经落后了8年多。新西兰倾向于在海外付费,而不是教育当地人最新的云技术。_ +> 亚太地区需要更多的外联活动,教育工作者和大学必须学习 Kubernetes,因为他们非常缓慢, +> 而且已经落后了8年多。新西兰倾向于在海外付费,而不是教育当地人最新的云技术。 ## [Dylan Graham](https://github.com/DylanGraham) @@ -107,7 +107,7 @@ He believes that consistent attendance at community/project meetings, taking on -> _成为大社区的一份子感觉真的很特别。我遇到了一些了不起的人,甚至是在现实生活中疫情发生之前。_ +> 成为大社区的一份子感觉真的很特别。我遇到了一些了不起的人,甚至是在现实生活中疫情发生之前。 ## [Hippie Hacker](https://github.com/hh) @@ -137,7 +137,7 @@ He recommends that new contributors use pair programming. -> _针对一个项目,多人关注和交叉交流往往比单独的评审、批准 PR 能产生更大的效果。_ +> 针对一个项目,多人关注和交叉交流往往比单独的评审、批准 PR 能产生更大的效果。 ## [Nick Young](https://github.com/youngnick) @@ -154,7 +154,7 @@ His contribution path was notable in that he began working on major areas of the 他的贡献之路是引人注目的,因为他很早就在 Kubernetes 项目的主要领域工作,这改变了他的轨迹。 他断言,一个新贡献者能做的最好的事情就是“开始贡献”。当然,如果与他的工作息息相关,那好极了; 然而,把非工作时间投入到贡献中去,从长远来看可以在工作上获得回报。 @@ -163,8 +163,8 @@ He asserts the best thing a new contributor can do is to "start contributing". N -> _只要积极主动,做出贡献,你就可以走很远。一旦你活跃了一段时间,你会发现你能够解答别人的问题, -这意味着会有人请教你或和你讨论,在你意识到这一点之前,你就已经是专家了。_ +> 只要积极主动,做出贡献,你就可以走很远。一旦你活跃了一段时间,你会发现你能够解答别人的问题, +> 这意味着会有人请教你或和你讨论,在你意识到这一点之前,你就已经是专家了。 --- diff --git a/content/zh-cn/blog/_posts/2022-05-03-kubernetes-release-1.24.md b/content/zh-cn/blog/_posts/2022-05-03-kubernetes-release-1.24.md new file mode 100644 index 0000000000000..887c5b9f8ee99 --- /dev/null +++ b/content/zh-cn/blog/_posts/2022-05-03-kubernetes-release-1.24.md @@ -0,0 +1,523 @@ +--- +layout: blog +title: "Kubernetes 1.24: 观星者" +date: 2022-05-03 +slug: kubernetes-1-24-release-announcement +--- + + + + +**作者**: [Kubernetes 1.24 发布团队](https://git.k8s.io/sig-release/releases/release-1.24/release-team.md) + +我们很高兴地宣布 Kubernetes 1.24 的发布,这是 2022 年的第一个版本! + +这个版本包括 46 个增强功能:14 个增强功能已经升级到稳定版,15 个增强功能正在进入 Beta 版, +13 个增强功能正在进入 Alpha 阶段。另外,有两个功能被废弃了,还有两个功能被删除了。 + + +## 主要议题 + +### 从 kubelet 中删除 Dockershim + +在 v1.20 版本中被废弃后,dockershim 组件已被从 Kubernetes v1.24 版本的 kubelet 中移除。 +从v1.24开始,如果你依赖 Docker Engine 作为容器运行时, +则需要使用其他[受支持的运行时](/zh-cn/docs/setup/production-environment/container-runtimes/)之一 +(如 containerd 或 CRI-O)或使用 CRI dockerd。 +有关确保群集已准备好进行此删除的更多信息,请参阅[本指南](/zh-cn/blog/2022/03/31/ready-for-dockershim-removal/)。 + + +### 默认情况下关闭 Beta API + +[新的 beta API 默认不会在集群中启用](https://github.com/kubernetes/enhancements/issues/3136)。 +默认情况下,现有 Beta API 和及其更新版本将继续被启用。 + + +### 签署发布工件 + +发布工件使用 [cosign](https://github.com/sigstore/cosign) 签名进行[签名](https://github.com/kubernetes/enhancements/issues/3031), +并且有[验证图像签名](/zh-cn/docs/tasks/administer-cluster/verify-signed-images/)的实验性支持。 +发布工件的签名和验证是[提高 Kubernetes 发布过程的软件供应链安全性](https://github.com/kubernetes/enhancements/issues/3027) +的一部分。 + + +### OpenAPI v3 + +Kubernetes 1.24 提供了以 [OpenAPI v3 格式](https://github.com/kubernetes/enhancements/issues/2896)发布其 API 的 Beta 支持。 + + +### 存储容量和卷扩展普遍可用 + +[存储容量跟踪](https://github.com/kubernetes/enhancements/issues/1472)支持通过 +[CSIStorageCapacity 对象](/zh-cn/docs/concepts/storage/storage-capacity/#api)公开当前可用的存储容量, +并增强使用具有后期绑定的 CSI 卷的 pod 的调度。 + +[卷的扩展](https://github.com/kubernetes/enhancements/issues/284)增加了对调整现有持久性卷大小的支持。 + + +### NonPreemptingPriority 到稳定 + +此功能[为 PriorityClasses 添加了一个新选项](https://github.com/kubernetes/enhancements/issues/902),可以启用或禁用 Pod 抢占。 + + +### 存储插件迁移 + +目前正在进行[迁移树内存储插件的内部组件](https://github.com/kubernetes/enhancements/issues/625)工作, +以便在保持原有 API 的同时调用 CSI 插件。[Azure Disk](https://github.com/kubernetes/enhancements/issues/1490) +和 [OpenStack Cinder](https://github.com/kubernetes/enhancements/issues/1489) 插件都已迁移。 + + +### gRPC 探针升级到 Beta + +在 Kubernetes 1.24 中,[gRPC 探测功能](https://github.com/kubernetes/enhancements/issues/2727) +已进入测试版,默认可用。现在,你可以在 Kubernetes 中为你的 gRPC +应用程序原生地[配置启动、活跃度和就绪性探测](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes), +而无需暴露 HTTP 端点或使用额外的可执行文件。 + + +### Kubelet 凭证提供者毕业至 Beta + +kubelet 最初在 Kubernetes 1.20 中作为 Alpha 发布,现在它对[镜像凭证提供者](/zh-cn/docs/tasks/kubelet-credential-provider/kubelet-credential-provider/) +的支持已升级到 Beta。这允许 kubelet 使用 exec 插件动态检索容器映像注册表的凭据,而不是将凭据存储在节点的文件系统上。 + + +### Alpha 中的上下文日志记录 + +Kubernetes 1.24 引入了[上下文日志](https://github.com/kubernetes/enhancements/issues/3077) +这使函数的调用者能够控制日志记录的所有方面(输出格式、详细程度、附加值和名称)。 + + +### 避免 IP 分配给服务的冲突 + +Kubernetes 1.24 引入了一项新的选择加入功能, +允许你[为服务的静态 IP 地址分配软保留范围](/zh-cn/docs/concepts/services-networking/service/#service-ip-static-sub-range)。 +通过手动启用此功能,集群将更喜欢从服务 IP 地址池中自动分配,从而降低冲突风险。 + + +服务的 `ClusterIP` 可以按照以下两种方式分配: + +* 动态,这意味着集群将自动在配置的服务 IP 范围内选择一个空闲 IP。 +* 静态,这意味着用户将在配置的服务 IP 范围内设置一个 IP。 + +服务 `ClusterIP` 是唯一的;因此,尝试使用已分配的 `ClusterIP` 创建服务将返回错误。 + + +### 从 Kubelet 中删除动态 Kubelet 配置 + +在 Kubernetes 1.22 中被弃用后,动态 Kubelet 配置已从 kubelet 中删除。 +该功能将从 Kubernetes 1.26 的 API 服务器中删除。 + + +## CNI 版本相关的重大更改 + +在升级到 Kubernetes 1.24 之前,请确认你正在使用/升级到经过测试可以在此版本中正常工作的容器运行时。 + +例如,以下容器运行时正在为 Kubernetes 准备,或者已经准备好了。 + +* containerd v1.6.4 及更高版本,v1.5.11 及更高版本 +* CRI-O 1.24 及更高版本 + + +当 CNI 插件尚未升级和/或 CNI 配置版本未在 CNI 配置文件中声明时,在 containerd v1.6.0–v1.6.3 +中存在 pod CNI 网络设置和拆除的服务问题。containerd 团队报告说,“这些问题在 containerd v1.6.4 中得到解决。” + +在 containerd v1.6.0-v1.6.3 版本中,如果你不升级 CNI 插件和/或声明 CNI 配置版本, +你可能会遇到以下 “Incompatible CNI versions” 或 “Failed to destroy network for sandbox” 的错误情况。 + + +## CSI 快照 + +**此信息是在首次发布后添加的。** + +[VolumeSnapshot v1beta1 CRD 已被移除](https://github.com/kubernetes/enhancements/issues/177)。 +Kubernetes 和容器存储接口 (CSI) 的卷快照和恢复功能,提供标准化的 API 设计 (CRD) 并添加了对 CSI 卷驱动程序的 +PV 快照/恢复支持,在 v1.20 中移至 GA。VolumeSnapshot v1beta1 在 v1.20 中被弃用,现在不受支持。 +有关详细信息,请参阅 [KEP-177: CSI 快照](https://git.k8s.io/enhancements/keps/sig-storage/177-volume-snapshot#kep-177-csi-snapshot) +和[卷快照 GA 博客](/blog/2020/12/10/kubernetes-1.20-volume-snapshot-moves-to-ga/)。 + + +## 其他更新 + +### 毕业到稳定 + +在此版本中,有 14 项增强功能升级为稳定版: + + +* [容器存储接口(CSI)卷扩展](https://github.com/kubernetes/enhancements/issues/284) +* [Pod 开销](https://github.com/kubernetes/enhancements/issues/688): 核算与 Pod 沙箱绑定的资源,但不包括特定的容器。 +* [向 PriorityClass 添加非抢占选项](https://github.com/kubernetes/enhancements/issues/902) +* [存储容量跟踪](https://github.com/kubernetes/enhancements/issues/1472) +* [OpenStack Cinder In-Tree 到 CSI 驱动程序迁移](https://github.com/kubernetes/enhancements/issues/1489) +* [Azure 磁盘树到 CSI 驱动程序迁移](https://github.com/kubernetes/enhancements/issues/1490) +* [高效的监视恢复](https://github.com/kubernetes/enhancements/issues/1904): + kube-apiserver 重新启动后,可以高效地恢复监视。 +* [Service Type=LoadBalancer 类字段](https://github.com/kubernetes/enhancements/issues/1959): + 引入新的服务注解 `service.kubernetes.io/load-balancer-class` , + 允许在同一个集群中提供 `type: LoadBalancer` 服务的多个实现。 +* [带索引的 Job](https://github.com/kubernetes/enhancements/issues/2214):为带有固定完成计数的 Job 的 Pod 添加完成索引。 +* [在 Job API 中增加 suspend 字段](https://github.com/kubernetes/enhancements/issues/2232): + 在 Job API 中增加一个 suspend 字段,允许协调者在创建作业时对 Pod 的创建进行更多控制。 +* [Pod 亲和性 NamespaceSelector](https://github.com/kubernetes/enhancements/issues/2249): + 为 Pod 亲和性/反亲和性规约添加一个 `namespaceSelector` 字段。 +* [控制器管理器的领导者迁移](https://github.com/kubernetes/enhancements/issues/2436): + kube-controller-manager 和 cloud-controller-manager 可以在 HA 控制平面中重新分配新的控制器到控制器管理器,而无需停机。 +* [CSR 期限](https://github.com/kubernetes/enhancements/issues/2784): + 用一种机制来扩展证书签名请求 API,允许客户为签发的证书请求一个特定的期限。 + + +### 主要变化 + +此版本有两个主要变化: + +* [Dockershim 移除](https://github.com/kubernetes/enhancements/issues/2221) +* [Beta APIs 默认关闭](https://github.com/kubernetes/enhancements/issues/3136) + + +### 发行说明 + +在我们的[发行说明](https://git.k8s.io/kubernetes/CHANGELOG/CHANGELOG-1.24.md) 中查看 Kubernetes 1.24 版本的完整详细信息。 + + +### 可用性 + +Kubernetes 1.24 可在 [GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.24.0) 上下载。 +要开始使用 Kubernetes,请查看这些[交互式教程](/zh-cn/docs/tutorials/)或在本地运行。 +使用 [kind](https://kind.sigs.k8s.io/),可以将容器作为 Kubernetes 集群的 “节点”。 +你还可以使用 [kubeadm](/zh-cn/docs/setup/independent/create-cluster-kubeadm/) 轻松安装 1.24。 + + +### 发布团队 + +如果没有组成 Kubernetes 1.24 发布团队的坚定个人的共同努力,这个版本是不可能实现的。 +该团队齐心协力交付每个 Kubernetes 版本中的所有组件,包括代码、文档、发行说明等。 + +特别感谢我们的发布负责人 James Laverack 指导我们完成了一个成功的发布周期, +并感谢所有发布团队成员投入时间和精力为 Kubernetes 社区提供 v1.24 版本。 + + +### 发布主题和徽标 + +**Kubernetes 1.24: 观星者** + +{{< figure src="/images/blog/2022-05-03-kubernetes-release-1.24/kubernetes-1.24.png" alt="" class="release-logo" >}} + +Kubernetes 1.24 的主题是**观星者(Stargazer)**。 + + +古代天文学家到建造 James Webb 太空望远镜的科学家,几代人都怀着敬畏和惊奇的心情仰望星空。 +星星启发了我们,点燃了我们的想象力,并引导我们在艰难的海上度过了漫长的夜晚。 + +通过此版本,我们向上凝视,当我们的社区聚集在一起时可能发生的事情。 +Kubernetes 是全球数百名贡献者和数千名最终用户支持的成果, +是一款为数百万人服务的应用程序。每个人都是我们天空中的一颗星星,帮助我们规划路线。 + +发布标志由 [Britnee Laverack](https://www.instagram.com/artsyfie/) 制作, +描绘了一架位于星空和[昴星团](https://en.wikipedia.org/wiki/Pleiades)的望远镜,在神话中通常被称为“七姐妹”。 +数字 7 对于 Kubernetes 项目特别吉祥,是对我们最初的“项目七”名称的引用。 + +这个版本的 Kubernetes 为那些仰望夜空的人命名——为所有的观星者命名。 ✨ + + +### 用户亮点 + +* 了解领先的零售电子商务公司 + [La Redoute 如何使用 Kubernetes 以及其他 CNCF 项目来转变和简化](https://www.cncf.io/case-studies/la-redoute/) + 其从开发到运营的软件交付生命周期。 +* 为了确保对 API 调用的更改不会导致任何中断,[Salt Security 完全在 Kubernetes 上构建了它的微服务, + 它通过 gRPC 进行通信,而 Linkerd 确保消息是加密的](https://www.cncf.io/case-studies/salt-security/)。 +* 为了从私有云迁移到公共云,[Alllainz Direct 工程师在短短三个月内重新设计了其 CI/CD 管道, + 同时设法将 200 个工作流压缩到 10-15 个](https://www.cncf.io/case-studies/allianz/)。 +* 看看[英国金融科技公司 Bink 是如何用 Linkerd 更新其内部的 Kubernetes 分布,以建立一个云端的平台, + 根据需要进行扩展,同时允许他们密切关注性能和稳定性](https://www.cncf.io/case-studies/bink/)。 +* 利用Kubernetes,荷兰组织 [Stichting Open Nederland](http://www.stichtingopennederland.nl/) + 在短短一个半月内创建了一个测试门户网站,以帮助安全地重新开放荷兰的活动。 + [入门测试 (Testen voor Toegang)](https://www.testenvoortoegang.org/) + 平台[利用 Kubernetes 的性能和可扩展性来帮助个人每天预订超过 400,000 个 COVID-19 测试预约](https://www.cncf.io/case-studies/true/)。 +* 与 SparkFabrik 合作并利用 Backstage,[Santagostino 创建了开发人员平台 Samaritan 来集中服务和文档, + 管理服务的整个生命周期,并简化 Santagostino 开发人员的工作](https://www.cncf.io/case-studies/santagostino/)。 + + +### 生态系统更新 + +* KubeCon + CloudNativeCon Europe 2022 将于 2022 年 5 月 16 日至 20 日在西班牙巴伦西亚举行! + 你可以在[活动网站](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/)上找到有关会议和注册的更多信息。 +* 在 [2021 年云原生调查](https://www.cncf.io/announcements/2022/02/10/cncf-sees-record-kubernetes-and-container-adoption-in-2021-cloud-native-survey/) + 中,CNCF 看到了创纪录的 Kubernetes 和容器采用。参阅[调查结果](https://www.cncf.io/reports/cncf-annual-survey-2021/)。 +* [Linux 基金会](https://www.linuxfoundation.org/)和[云原生计算基金会](https://www.cncf.io/) (CNCF) + 宣布推出新的 [云原生开发者训练营](https://training.linuxfoundation.org/training/cloudnativedev-bootcamp/?utm_source=lftraining&utm_medium=pr&utm_campaign=clouddevbc0322) + 为参与者提供设计、构建和部署云原生应用程序的知识和技能。查看[公告](https://www.cncf.io/announcements/2022/03/15/new-cloud-native-developer-bootcamp-provides-a-clear-path-to-cloud-native-careers/)以了解更多信息。 + + +### 项目速度 + +The [CNCF K8s DevStats](https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1&refresh=15m) 项目 +汇总了许多与 Kubernetes 和各种子项目的速度相关的有趣数据点。这包括从个人贡献到做出贡献的公司数量的所有内容, +并且说明了为发展这个生态系统而付出的努力的深度和广度。 + +在[运行 17 周](https://github.com/kubernetes/sig-release/tree/master/releases/release-1.24) +( 1 月 10 日至 5 月 3 日)的 v1.24 发布周期中,我们看到 [1029 家公司](https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1&var-period_name=v1.23.0%20-%20v1.24.0&var-metric=contributions) +和 [1179 人](https://k8s.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1&var-period_name=v1.23.0%20-%20v1.24.0&var-metric=contributions&var-repogroup_name=Kubernetes&var-country_name=All&var-companies=All&var-repo_name=kubernetes%2Fkubernetes) 的贡献。 + + +## 即将发布的网络研讨会 + +在太平洋时间 2022 年 5 月 24 日星期二上午 9:45 至上午 11 点加入 Kubernetes 1.24 发布团队的成员, +了解此版本的主要功能以及弃用和删除,以帮助规划升级。有关更多信息和注册, +请访问 CNCF 在线计划网站上的[活动页面](https://community.cncf.io/e/mck3kd/)。 + + +## 参与进来 + +参与 Kubernetes 的最简单方法是加入符合你兴趣的众多 [特别兴趣组](https://git.k8s.io/community/sig-list.md)(SIG) 之一。 +你有什么想向 Kubernetes 社区广播的内容吗? +在我们的每周的[社区会议](https://git.k8s.io/community/communication)上分享你的声音,并通过以下渠道: + +* 在 [Kubernetes Contributors](https://www.kubernetes.dev/) 网站上了解有关为 Kubernetes 做出贡献的更多信息 +* 在 Twitter 上关注我们 [@Kubernetesio](https://twitter.com/kubernetesio) 以获取最新更新 +* 加入社区讨论 [Discuss](https://discuss.kubernetes.io/) +* 加入 [Slack](http://slack.k8s.io/) 社区 +* 在 [Server Fault](https://serverfault.com/questions/tagged/kubernetes) 上发布问题(或回答问题)。 +* 分享你的 Kubernetes [故事](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform) +* 在[博客](/zh-cn/blog/)上阅读有关 Kubernetes 正在发生的事情的更多信息 +* 详细了解 [Kubernetes 发布团队](https://git.k8s.io/sig-release/release-team) diff --git a/content/zh-cn/blog/_posts/2022-06-01-annual-report-2021.md b/content/zh-cn/blog/_posts/2022-06-01-annual-report-2021.md index 93c119560b75b..412fabe2febe8 100644 --- a/content/zh-cn/blog/_posts/2022-06-01-annual-report-2021.md +++ b/content/zh-cn/blog/_posts/2022-06-01-annual-report-2021.md @@ -14,7 +14,7 @@ slug: annual-report-summary-2021 -**作者:**Paris Pittman(指导委员会) +**作者:** Paris Pittman(指导委员会) -
-

案例研究:
Ygrene: 使用原生云为金融行业带来安全性和可扩展性 - -

- - -
- - -
- 公司  Ygrene     位置  佩塔卢马,加利福尼亚州     行业  清洁能源融资 -
- -
-
-
-
-

挑战

- -作为一家 PACE(清洁能源资产评估)融资公司,Ygrene 自2010年以来已经为超过10亿的贷款提供资金。为了批准和处理这些贷款,“我们有很多正在聚合的数据源,而且我们也有许多系统需要对这些数据进行改动,”Ygrene 开发经理 Austin Adams 说。该公司正在使用大量服务器,“我们刚刚达到能够垂直扩展它们的极限。我们有一个非常不稳定的系统,它变得不知所措,要求只是做后台数据处理的实时。用户看到的性能很差。我们需要一个解决方案,不需要我们对代码库进行大量重构。作为一家金融公司,Ygrene 还需要确保他们安全地传输应用程序。” - -
- -

解决方案

- -从 Engine Yard 和 Amazon Elastic Beanstalk 上迁移了应用后,Ygrene 团队采用云原生技术和实践:使用Kubernetes来帮助垂直扩展和分配工作负载,使用 Notary 加入构建时间控制和获取使用第三方依赖的可信赖 Docker 镜像,使用Fluentd“掌握堆栈中的所有情况”,这些都运行在Amazon EC2 Spot上。 -
- -
- + + + +

挑战

+ + +

作为一家 PACE(清洁能源资产评估)融资公司,Ygrene 自 2010 年以来已经为超过 10 亿的贷款提供资金。为了批准和处理这些贷款,“我们有很多正在聚合的数据源,而且我们也有许多系统需要对这些数据进行改动,”Ygrene 开发经理 Austin Adams 说。该公司正在使用大量服务器,“我们刚刚达到能够垂直扩展它们的极限。我们有一个非常不稳定的系统,它变得不知所措,要求只是做后台数据处理的实时。用户看到的性能很差。我们需要一个解决方案,不需要我们对代码库进行大量重构。作为一家金融公司,Ygrene 还需要确保他们安全地传输应用程序。”

+ + +

解决方案

+ + +

从 Engine Yard 和 Amazon Elastic Beanstalk 上迁移了应用后,Ygrene 团队采用云原生技术和实践:使用 Kubernetes 来帮助垂直扩展和分配工作负载,使用 Notary 加入构建时间控制和获取使用第三方依赖的可信赖 Docker 镜像,使用 Fluentd “掌握堆栈中的所有情况”,这些都运行在 Amazon EC2 Spot 上。

+ +

影响

- -以前,部署通常需要三到四个小时,而且每周或每两周要把一些两三个月工作量的任务在系统占用低的时候进行部署。现在,他们用5分钟来配置 Kubernetes,然后用一个小时进行整体部署与烟雾测试。Adams 说:“我们每周可以部署三到四次,只需一周或两天的工作量。”“我们在工作周、白天的任意时间进行部署,甚至不需要停机。以前我们不得不请求企业批准,以关闭系统,因为即使在半夜,人们也可能正在访问服务。现在,我们可以部署、上传代码和迁移数据库,而无需关闭系统。公司获得新功能,而不必担心某些业务会丢失或延迟。”此外,通过使用 kops 项目,Ygrene 现在可以用以前成本的十分之一使用 AWS EC2 Spot 运行其 Kubernetes 集群。Adams 说,这些云原生技术“改变了可扩展性、可观察性和安全性(我们正在添加新的非常安全的数据源)的游戏。”“没有 Kubernetes、Notary 和 Fluent,我们就无法告诉投资者和团队成员,我们知道刚刚发生了什么事情。” - -
- -
-
-
-
- -“CNCF 项目正在帮助 Ygrene 确定整个 PACE 行业的安全性和可观察性标准。我们是一个新兴的金融企业,没有这些项目,尤其是 Kubernetes,我们不可能成为今天的行业领导者。”

— Austin Adams, Ygrene 能源基金会开发经理
- -
-
- -
-
- -

在不到十年的时间里, Ygrene 就为可再生能源项目提供了超过10亿美元的贷款。

PACE (清洁能源物业评估)融资公司开发经理 Austin Adams 表示:“我们抵押房屋或商业建筑,用贷款来为任何可以节约电力、生产电力、节约用水或减少碳排放的项目提供资金支持。”

- - -为了批准这些贷款,公司需要处理大量的承销数据。Adams 说:“我们必须要验证有关财产、公司或人员的问题,像这样的工作数以千计。因此,我们有很多正在聚合的数据源,并且我们也有大量系统需要实时对这些数据进行改动。”

- -到 2017 年,部署和可扩展性已成为痛点。该公司已经使用了大量服务器,“我们刚刚达到能够垂直扩展的极限,”他说。迁移到 AWS Elastic Beanstalk 并不能解决问题:“Scala 服务需要来自主 Ruby on Rails 服务和不同供应商提供的大量数据,因此他们要求从我们的 Ruby 服务以一种服务器无法承受的速率获取信息。在 Elastic Beanstalk 上我们也有许多配置与应用不匹配。这仅仅是一个开始,我们也意识到我们这个系统非常不稳定。” -
-
-
-
- -“CNCF 是众多项目惊人的孵化器。现在,我们定期查看其网页,了解是否有任何新的、可敬的高质量项目可以应用到我们的系统中。它实际上已成为我们了解自身需要什么样的软件以使我们的系统更加安全和具有可伸缩性的信息中心。”

— Austin Adams, Ygrene 能源基金会开发经理
-
-
-
-
- - -Adams 和其他团队一起着手寻找一种具有变革性的解决方案,但“不需要我们对代码库进行巨大的重构,”他说。作为一家金融公司,和可伸缩性一样,Ygrene 需要更好的安全性。他们通过采用云原生技术找到了答案:Kubernetes 帮助纵向扩展和分配工作负载,Notary 在各个级别实现可靠的安全性,Fluentd 来提供可观察性。Adams 说:“ Kubernetes 是社区前进的方向,也是我们展望未来的证明。”

- -有了 Kubernetes,该团队能够快速将 Ygrene 应用程序用 Docker 容器化。“我们必须改变一些实现和代码,以及系统的构建方式,” Adams 说,“但我们已经能够在一个月左右的时间内将主要系统引入 Kubernetes,然后在两个月内投入生产。对于一家金融公司来说,这已经非常快了。”

- -怎么样?Adams 说,这些云原生技术“改变了可扩展性、可观察性和安全性(我们正在添加新的非常安全的数据源)的游戏。”“没有 Kubernetes、Notary 和 Fluent,我们就无法告诉投资者和团队成员,我们知道刚刚发生了什么事情。”

- -Adams 说,尤其 Notary 简直就是“天赐之物”。“我们要清楚,我们针对第三方依赖项的攻击面较低,或者至少是托管的。因为我们使用 Notary 作为一个信任系统,我们也使用它作为区分,所以生产镜像由 Notary 签名,但一些开发镜像就不签署。这是为了确保未签名镜像无法进入生产集群。我们已经在测试集群中使用它,以使构建的应用更安全。” - - -
-
-
-
- + + +

以前,部署通常需要三到四个小时,而且每周或每两周要把一些两三个月工作量的任务在系统占用低的时候进行部署。现在,他们用 5 分钟来配置 Kubernetes,然后用一个小时进行整体部署与烟雾测试。Adams 说:“我们每周可以部署三到四次,只需一周或两天的工作量。”“我们在工作周、白天的任意时间进行部署,甚至不需要停机。以前我们不得不请求企业批准,以关闭系统,因为即使在半夜,人们也可能正在访问服务。现在,我们可以部署、上传代码和迁移数据库,而无需关闭系统。公司获得新功能,而不必担心某些业务会丢失或延迟。”此外,通过使用 kops 项目,Ygrene 现在可以用以前成本的十分之一使用 AWS EC2 Spot 运行其 Kubernetes 集群。Adams 说,这些云原生技术“改变了可扩展性、可观察性和安全性(我们正在添加新的非常安全的数据源)的游戏。”“没有 Kubernetes、Notary 和 Fluent,我们就无法告诉投资者和团队成员,我们知道刚刚发生了什么事情。”

+ + +{{< case-studies/quote author="Austin Adams, Ygrene 能源基金会开发经理" >}} +“CNCF 项目正在帮助 Ygrene 确定整个 PACE 行业的安全性和可观察性标准。我们是一个新兴的金融企业,没有这些项目,尤其是 Kubernetes,我们不可能成为今天的行业领导者。” +{{< /case-studies/quote >}} + + +{{< case-studies/lead >}} +在不到十年的时间里, Ygrene 就为可再生能源项目提供了超过 10 亿美元的贷款。 +{{< /case-studies/lead >}} + + +

PACE (清洁能源物业评估)融资公司开发经理 Austin Adams 表示:“我们抵押房屋或商业建筑,用贷款来为任何可以节约电力、生产电力、节约用水或减少碳排放的项目提供资金支持。”

+ + +

为了批准这些贷款,公司需要处理大量的承销数据。Adams 说:“我们必须要验证有关财产、公司或人员的问题,像这样的工作数以千计。因此,我们有很多正在聚合的数据源,并且我们也有大量系统需要实时对这些数据进行改动。”

+ + +

到 2017 年,部署和可扩展性已成为痛点。该公司已经使用了大量服务器,“我们刚刚达到能够垂直扩展的极限,”他说。迁移到 AWS Elastic Beanstalk 并不能解决问题:“Scala 服务需要来自主 Ruby on Rails 服务和不同供应商提供的大量数据,因此他们要求从我们的 Ruby 服务以一种服务器无法承受的速率获取信息。在 Elastic Beanstalk 上我们也有许多配置与应用不匹配。这仅仅是一个开始,我们也意识到我们这个系统非常不稳定。”

+ + +{{< case-studies/quote + image="/images/case-studies/ygrene/banner3.jpg" + author="Austin Adams, Ygrene 能源基金会开发经理" +>}} +“CNCF 是众多项目惊人的孵化器。现在,我们定期查看其网页,了解是否有任何新的、可敬的高质量项目可以应用到我们的系统中。它实际上已成为我们了解自身需要什么样的软件以使我们的系统更加安全和具有可伸缩性的信息中心。” +{{< /case-studies/quote >}} + + +

Adams 和其他团队一起着手寻找一种具有变革性的解决方案,但“不需要我们对代码库进行巨大的重构,”他说。作为一家金融公司,和可伸缩性一样,Ygrene 需要更好的安全性。他们通过采用云原生技术找到了答案:Kubernetes 帮助纵向扩展和分配工作负载,Notary 在各个级别实现可靠的安全性,Fluentd 来提供可观察性。Adams 说:“Kubernetes 是社区前进的方向,也是我们展望未来的证明。”

+ + +

有了 Kubernetes,该团队能够快速将 Ygrene 应用程序用 Docker 容器化。“我们必须改变一些实现和代码,以及系统的构建方式,” Adams 说,“但我们已经能够在一个月左右的时间内将主要系统引入 Kubernetes,然后在两个月内投入生产。对于一家金融公司来说,这已经非常快了。”

+ + +

怎么样?Adams 说,这些云原生技术“改变了可扩展性、可观察性和安全性(我们正在添加新的非常安全的数据源)的游戏。”“没有 Kubernetes、Notary 和 Fluent,我们就无法告诉投资者和团队成员,我们知道刚刚发生了什么事情。”

+ + +

Adams 说,尤其 Notary 简直就是“天赐之物”。“我们要清楚,我们针对第三方依赖项的攻击面较低,或者至少是托管的。因为我们使用 Notary 作为一个信任系统,我们也使用它作为区分,所以生产镜像由 Notary 签名,但一些开发镜像就不签署。这是为了确保未签名镜像无法进入生产集群。我们已经在测试集群中使用它,以使构建的应用更安全。”

+ + +{{< case-studies/quote image="/images/case-studies/ygrene/banner4.jpg">}} “我们必须改变一些实现和代码,以及系统的构建方式,” Adams 说,“但我们已经能够在一个月左右的时间内将主要系统引入 Kubernetes,然后在两个月内投入生产。对于一家金融公司来说,这已经非常快了。” -
-
- -
-
- -通过使用 kops 项目,Ygrene 能够用以前成本的十分之一从 Elastic Beanstalk 迁移到 AWS EC2 Spot 上运行其 Kubernetes 群集。Adams 说:“以前为了扩展,我们需要增加实例大小,导致高成本产出低价值。现在,借助 Kubernetes 和 kops,我们能够在具有多个实例组的 Spot 上水平缩放。”

- -这也帮助他们降低了在公共云中运行所带来的风险。“我们发现,基本上,如果我们能够使用中断可能性极低、无中断历史的 EC2 Spot 选择实例类,并且我们愿意付出足够高的价格,我们几乎可以得到和使用 Kubernetes 相同的保证,因为我们有足够的节点,”软件工程师 Zach Arnold 说,他领导了向 Kubernetes 的迁移。“现在,我们已经重新架构了应用程序的这些部分,使之不再位于同一台服务器上,我们可以推送到许多不同的服务器,并实现更稳定的部署。”

- -因此,团队现在可以在一天中的任何时间传输代码。阿诺德说:“以前这样做是很危险的,因为它会拖慢整个贷款管理软件。”“但现在,我们可以在白天安全部署。” - -
-
-
-
- +{{< /case-studies/quote >}} + + +

通过使用 kops 项目,Ygrene 能够用以前成本的十分之一从 Elastic Beanstalk 迁移到 AWS EC2 Spot 上运行其 Kubernetes 集群。Adams 说:“以前为了扩展,我们需要增加实例大小,导致高成本产出低价值。现在,借助 Kubernetes 和 kops,我们能够在具有多个实例组的 Spot 上水平缩放。”

+ + +

这也帮助他们降低了在公共云中运行所带来的风险。“我们发现,基本上,如果我们能够使用中断可能性极低、无中断历史的 EC2 Spot 选择实例类,并且我们愿意付出足够高的价格,我们几乎可以得到和使用 Kubernetes 相同的保证,因为我们有足够的节点,”软件工程师 Zach Arnold 说,他领导了向 Kubernetes 的迁移。“现在,我们已经重新架构了应用程序的这些部分,使之不再位于同一台服务器上,我们可以推送到许多不同的服务器,并实现更稳定的部署。”

+ + +

因此,团队现在可以在一天中的任何时间传输代码。阿诺德说:“以前这样做是很危险的,因为它会拖慢整个贷款管理软件。”“但现在,我们可以在白天安全部署。”

+ + +{{< case-studies/quote >}} Adams 说:“以前为了扩展,我们需要增加实例大小,导致高成本产出低价值。现在,借助 Kubernetes 和 kops,我们能够在具有多个实例组的 Spot 上水平缩放。” -
-
- -
-
- -以前,部署通常需要三到四个小时,而且每周或每两周要把一些两三个月工作量的任务在系统占用低的时候进行部署。现在,他们用5分钟来配置 Kubernetes,然后用一个小时进行整体部署与烟雾测试。Adams 说:“我们每周可以部署三到四次,只需一周或两天的工作量。”“我们在工作周、白天的任意时间进行部署,甚至不需要停机。以前我们不得不请求企业批准,以关闭系统,因为即使在半夜,人们也可能正在访问服务。现在,我们可以部署、上传代码和迁移数据库,而无需关闭系统。公司增加新项目,而不必担心某些业务会丢失或延迟。”

- -云原生也影响了 Ygrene 的 50 多名开发人员和承包商的工作方式。Adams 和 Arnold 花了相当长的时间“教人们思考开箱即用的”,Arnold 说。“我们最终选择了称之为“航运四S”:安全、可靠、稳妥、快速。”(有关其安全部分的更多内容,请参阅他们关于"持续黑客攻击"策略的文章。至于工程师,Adams 说,“他们已经能够跟上软件进步的步伐。我想一天结束时,开发人员会感觉更好,他们也会感觉与现代软件开发社区的联系更加紧密。”

- -展望未来,Adams 很高兴能探索更多的 CNCF 项目,包括 SPIFFE 和 SPIRE。“ CNCF 是众多项目惊人的孵化器。现在,我们定期查看其网页,了解是否有任何新的、可敬的高质量项目可以应用到我们的系统中。它实际上已成为我们了解自身需要什么样的软件以使我们的系统更加安全和具有可伸缩性的信息中心。” - - -
- -
+{{< /case-studies/quote >}} + + +

以前,部署通常需要三到四个小时,而且每周或每两周要把一些两三个月工作量的任务在系统占用低的时候进行部署。现在,他们用5分钟来配置 Kubernetes,然后用一个小时进行整体部署与烟雾测试。Adams 说:“我们每周可以部署三到四次,只需一周或两天的工作量。”“我们在工作周、白天的任意时间进行部署,甚至不需要停机。以前我们不得不请求企业批准,以关闭系统,因为即使在半夜,人们也可能正在访问服务。现在,我们可以部署、上传代码和迁移数据库,而无需关闭系统。公司增加新项目,而不必担心某些业务会丢失或延迟。”

+ + +

云原生也影响了 Ygrene 的 50 多名开发人员和承包商的工作方式。Adams 和 Arnold 花了相当长的时间“教人们思考开箱即用的”,Arnold 说。“我们最终选择了称之为“航运四S”:安全、可靠、稳妥、快速。”(有关其安全部分的更多内容,请参阅他们关于"持续黑客攻击"策略的文章。至于工程师,Adams 说,“他们已经能够跟上软件进步的步伐。我想一天结束时,开发人员会感觉更好,他们也会感觉与现代软件开发社区的联系更加紧密。”

+ + +

展望未来,Adams 很高兴能探索更多的 CNCF 项目,包括 SPIFFE 和 SPIRE。“CNCF 是众多项目惊人的孵化器。现在,我们定期查看其网页,了解是否有任何新的、可敬的高质量项目可以应用到我们的系统中。它实际上已成为我们了解自身需要什么样的软件以使我们的系统更加安全和具有可伸缩性的信息中心。”

diff --git a/content/zh-cn/case-studies/zalando/index.html b/content/zh-cn/case-studies/zalando/index.html index 39fc63ab1d98a..0247943d87956 100644 --- a/content/zh-cn/case-studies/zalando/index.html +++ b/content/zh-cn/case-studies/zalando/index.html @@ -2,131 +2,195 @@ title: 案例研究:Zalando case_study_styles: true cid: caseStudies -css: /css/style_zalando.css + +new_case_study_styles: true +heading_background: /images/case-studies/zalando/banner1.jpg +heading_title_logo: /images/zalando_logo.png +subheading: > + 欧洲领先的在线时尚平台通过云原生获得突破性进展 +case_study_details: + - 公司: Zalando + - 位置: Berlin, Germany + - 行业: 在线时尚平台 --- + + +

挑战

-
- -

案例研究:
欧洲领先的在线时尚平台通过云原生获得突破性进展 -

- -
- - -
- 公司  Zalando     位置  柏林, 德国     行业  在线时尚平台 -
- -
-
-
-
-

挑战

- -Zalando 是欧洲领先的在线时尚平台,自 2008 年成立以来,经历了指数级增长。2015 年,Zalando 计划进一步扩展其原有的电子商务站点,以扩展新的服务和产品,从而开始了彻底的变革,因此形成了自主的自组织团队。这次扩展需要可以随工程组织的增长而扩展的基础架构。Zalando 的技术部门开始重写其应用程序,使其能够在云端运行,并开始将其基础架构从内部数据中心迁移到云。虽然编排没有立即被考虑,因为团队迁移到亚马逊网络服务(AWS):“我们体验过团队在 AWS 上进行基础设施架构和使用云资源时遇到的痛苦,”开发人员生产力主管 Henning Jacobs 说,“我们遇到了一些难题。对于团队和合规性来说,运营开销仍然过多。为了提供更好的支持,项目引入了集群管理。” - -
- -
-

解决方案

- -该公司现在使用 Kubernetes 编排在 AWS 上运行的 Docker 容器。 -
+ +

Zalando 是欧洲领先的在线时尚平台,自 2008 年成立以来,经历了指数级增长。在 2015 年,Zalando 计划进一步扩展其原有的电子商务站点,以扩展新的服务和产品,从而开始了彻底的变革,因此形成了自主的自组织团队。这次扩展需要可以随工程组织的增长而扩展的基础架构。Zalando 的技术部门开始重写其应用程序,使其能够在云端运行,并开始将其基础架构从内部数据中心迁移到云。虽然编排没有立即被考虑,因为团队迁移到亚马逊网络服务(AWS):“我们体验过团队在 AWS 上进行基础设施架构和使用云资源时遇到的痛苦,”开发人员生产力主管 Henning Jacobs 说,“我们遇到了一些难题。对于团队和合规性来说,运营开销仍然过多。为了提供更好的支持,项目引入了集群管理。”

+ + +

解决方案

+ + +

该公司现在使用 Kubernetes 编排在 AWS 上运行的 Docker 容器。

+ +

影响

- -Jacobs 说,由于旧基础设施“很难正确采用新技术,而 DevOps 团队被视为瓶颈。”“现在,有了这个云基础架构,它们有了这种打包格式,可以包含任何在Linux内核上运行的东西。这使得很多人相当高兴。工程师喜欢自主。” -
-
-
-
-
- -“我们设想所有 Zalando 交付团队在 Kubernetes 提供的最先进的、可靠且可扩展的群集基础架构上运行其容器化应用程序。”

- Henning Jacobs, Zalando 开发人员生产力主管 -
-
-
-
-
- -

当 Henning Jacobs 于2010年来到 Zalando 时,该公司刚成立两年,有180名员工经营一家网上商店,供欧洲消费者购买时尚商品。

- -Zalando 的开发人员生产力主管 Jacobs 说:“它最初是一个 PHP 电子商务网站,很容易上手,但无法随业务需求扩展。”

- -当时,公司开始从德国以外扩展到其他欧洲市场。快进到今天,Zalando 现在拥有超过 14000 名员工,2016 年收入为 36 亿欧元,业务遍及 15 个国家/地区。他表示:“这种全面快速的增长和不断扩展,一生只能有一次。”

- -能拥有像 Jacobs 这样的基础设施专家的机会是非常独特的。就在他加入公司后,公司开始在内部重写他们的所有应用。“这通常是我们的策略,”他表示。“例如,我们从我们自己的物流仓库开始,但起初不知道如何做物流软件,所以得用一些供应商软件。然后我们用自己的软件替换了它,因为使用现成的软件是没有竞争力的。需要根据特定业务需求优化这些流程。”

- -在重写其应用程序的同时,Zalando 设定了一个目标,即从基本电子商务扩展到提供多租户的平台、大量增加的分类和样式、当天送达,甚至您自己的平台个人在线造型师

- -扩展的需求最终引领了公司踏上云原生之旅。它采用基于微服务的软件架构,使工程团队拥有更多的项目自主权和所有权。“迁移到云是必要的,因为在数据中心中,团队不可能随心所欲。使用相同的基础架构,因此只能运行 Java 或 Python 应用,”Jacobs 说。 - -
-
-
-
- + + +

Jacobs 说,由于旧基础设施“很难正确采用新技术,而 DevOps 团队被视为瓶颈。”“现在,有了这个云基础架构,它们有了这种打包格式,可以包含任何在 Linux 内核上运行的东西。这使得很多人相当高兴。工程师喜欢自主。”

+ + +{{< case-studies/quote author="Henning Jacobs, Zalando 开发人员生产力主管" >}} +

“我们设想所有 Zalando 交付团队在 Kubernetes 提供的最先进的、可靠且可扩展的集群基础架构上运行其容器化应用程序。”

+{{< /case-studies/quote >}} + + +{{< case-studies/lead >}} +当 Henning Jacobs 于 2010 年来到 Zalando 时,该公司刚成立两年,有 180 名员工经营一家网上商店,供欧洲消费者购买时尚商品。 +{{< /case-studies/lead >}} + + +

Zalando 的开发人员生产力主管 Jacobs 说:“它最初是一个 PHP 电子商务网站,很容易上手,但无法随业务需求扩展。”

+ + +

当时,公司开始从 Germany 以外扩展到其他欧洲市场。快进到今天,Zalando 现在拥有超过 14000 名员工,2016 年收入为 36 亿欧元,业务遍及 15 个国家/地区。他表示:“这种全面快速的增长和不断扩展,一生只能有一次。”

+ + +

能拥有像 Jacobs 这样的基础设施专家的机会是非常独特的。就在他加入公司后,公司开始在内部重写他们的所有应用。“这通常是我们的策略,”他表示。“例如,我们从我们自己的物流仓库开始,但起初不知道如何做物流软件,所以得用一些供应商软件。然后我们用自己的软件替换了它,因为使用现成的软件是没有竞争力的。需要根据特定业务需求优化这些流程。”

+ + +

在重写其应用程序的同时,Zalando 设定了一个目标,即从基本电子商务扩展到一个提供多租户、大量增加的分类和样式、当天送达,甚至你自己个人在线造型师的平台。

+ + +

扩展的需求最终引领了公司踏上云原生之旅。它采用基于微服务的软件架构,使工程团队拥有更多的项目自主权和所有权。“迁移到云是必要的,因为在数据中心中,团队不可能随心所欲。使用相同的基础架构,因此只能运行 Java 或 Python 应用,”Jacobs 说。

+ + +{{< case-studies/quote image="/images/case-studies/zalando/banner3.jpg" >}} “迁移到云是必要的,因为在数据中心中,团队不可能随心所欲。使用相同的基础架构,因此只能运行 Java 或 Python 应用。” +{{< /case-studies/quote >}} + + +

Zalando 开始将其基础架构从两个内部数据中心迁移到云,这需要迁移较旧的应用程序使其在云中准备就绪。“我们决定果断一些,” Jacobs 说。“我们的亚马逊网络服务基础设施是这样的:每个团队都有自己的 AWS 账户,该账户是完全隔离的,这意味着没有'提升和转移'。基本上必须重写应用程序,使其在云中准备就绪,甚至到持久层也是如此。我们勇敢地回到绘图板,重做一切,首先选择 Docker 作为通用容器化,然后从那里构建基础结构。”

+ + +

公司最初决定推迟编排,但随着团队迁移到 AWS,“我们看到团队在 AWS 上的基础设施和使用云资源方面遇到了难题,” Jacobs 说。

+ + +

Zalando 200 多人的自主工程团队研究使用哪些技术,并可以使用自己的 AWS 账户操作自己的应用程序。事实证明,此设置是一项合规性挑战。即使制定了严格的游戏规则和自动化的合规性检查,工程团队和 IT 合规性在解决合规性问题方面也负担过重。Jacobs 说:"违规行为会出现,我们在扫描云基础架构时会检测到这些行为。“一切皆有可能,没有强制实施,因此你必须忍受违规行为(并解决它们),而不是一开始就防止错误。这些都会增加团队的开销,以及合规性和操作的开销。在 AWS 上启动新的 EC2 实例也需要时间,这会影响我们的部署速度。”

+ + +

Jacobs 说,团队意识到他们需要“利用从集群管理中获得的价值”。当他们在 2015 年首次将平台视为服务(PaaS)选项时,市场是支离破碎的;但“现在似乎有一个明确的赢家。使用 Kubernetes 似乎是一个很好的尝试。”

+ + +

Kubernetes 的过渡始于 2016 年 Zalando 的极客周期间,参与者将他们的项目部署到 Kubernetes 集群。60 名技术基础设施部门的成员开始使用这项技术,之后每次会加入一支工程团队。Jacobs 说:“我们总是从与他们交谈开始,确保每个人的期望都清晰。然后,我们进行一些 Kubernetes 培训,这主要是针对我们的 CI/CD 设置的培训,因为我们的用户界面主要通过 CI/CD 系统。但是他们必须知道 Kubernetes 的基本概念和API。之后每周与每个团队同步,以检查其进度。一旦出现什么状况,就可以确定我们所做的改进是否正常。”

+ + +{{< case-studies/quote image="/images/case-studies/zalando/banner4.jpg" >}} +一旦 Zalando 开始将应用迁移到 Kubernetes,效果立竿见影。“Kubernetes 是我们无缝端到端开发人员体验的基石。我们能够使用单一一致且声明性的 API 将创意运送到生产中,” Jacobs 说。 +{{< /case-studies/quote >}} + + +

目前,Zalando 正在运行最初的 40 个 Kubernetes 集群,并计划在可预见的将来进行扩展。一旦 Zalando 开始将申请迁移到 Kubernetes,效果立竿见影。“Kubernetes 是我们无缝端到端开发人员体验的基石。我们能够使用单一一致且声明性的 API 将创意运送到生产中,” Jacobs 说。“自愈基础架构提供了无摩擦体验,基于低级最佳实践构建了更高级别的抽象。我们设想所有 Zalando 交付团队都将在 Kubernetes 提供的最先进的可靠和可扩展集群基础架构上运行其容器化应用程序。”

+ + +

Jacobs 说,使用旧的内部基础设施,“很难正确采用新技术,而 DevOps 团队被视为瓶颈。”“现在,有了这个云基础架构,它们有了这种打包格式,可以包含运行在 Linux 内核中的任何内容。这使得很多人相当高兴。工程师喜欢自主性。”

+ + +

在 Zalando 的 Kubernetes 实施中出现了一些挑战。Jacobs 说:“我们是一支由七人组成的团队,为不同的工程团队提供集群,我们的目标是为所有团队提供坚如磐石的体验。”“我们不想要宠物集群。我们不想了解他们的工作量;它应该只是开箱即用。考虑到这一点,集群自动缩放非常重要。执行集群管理的方法有很多种,这不是核心的一部分。因此,我们创建了两个组件来预配集群,具有集群的注册表,并管理整个集群生命周期。”

+ + + +

Jacobs 的团队还致力于改进 Kubernetes-AWS 集成。“由于许多限制条件,需要通过基础设施来扩展每个自主团队的想法。”此外,“仍然缺少很多最佳实践,” Jacobs 说。例如,该团队最近解决了 pod 安全策略问题。“在 Kubernetes 已经有一个概念,但没有记录,所以有点棘手,”他说。大型的 Kubernetes 社区是解决这个问题的一大帮助。为了帮助其他公司走上同样的道路,Jacobs 在一份名为在生产中运行 Kubernetes 的文件中汇编了他的团队的经验教训。

+ + +{{< case-studies/quote >}} +“Kubernetes API 允许我们以与云提供商无关的方式运行应用程序,这使我们能够在未来几年中自由访问 IaaS 提供商...。我们期望 Kubernetes API 成为 PaaS 基础设施的全球标准,并对未来的继续旅程感到兴奋。” +{{< /case-studies/quote >}} + + + +

最后,Kubernetes 使 Zalando 能够引进和维护公司为发展其平台而设想的新产品。Jacobs 说:“时尚咨询产品使用 Scala,而我们以前的基础设施也难以实现这一点。”这是一个解决方法,该团队需要平台团队提供越来越多的支持,只是因为他们使用了不同的技术。现在有了 Kubernetes,它就自主了。无论工作负载是什么,该团队都可以走自己的路,而 Kubernetes 可以防止其他瓶颈。

+ + +

展望未来,Jacobs 将 Zalando 的新基础设施视为公司在进行的其他工程中的巨大推动因素,从新的物流软件到连接品牌的平台功能,以及数据科学家梦寐以求的产品。Jacobs 说:“一个愿景是,如果你看下一部 James Bond 的电影,看看他穿的西装,你就应该能够自动订购,并在一小时内把它送到你身边。”“这是关于连接整个时尚领域。如果你遇到瓶颈,因为每个人都在同一个数据中心运行,因此限制很大,则这绝对是不可能的。需要基础设施来扩展每个自主团队的想法。”

+ + +

对于考虑这项技术的其他公司,Jacobs 说,他不一定建议像 Zalando 那样做。他表示:“如果你准备尝试失败,那么这样做是可以的。”“设定正确的期望是必须的。并不是一切都会起作用。重写应用和这种类型的组织更改可能会造成中断。我们移动的第一个产品至关重要。存在大量依赖关系,而且时间比预期长。也许我们应该从不那么复杂、不是业务关键的东西开始,只是为了开个好头。”

-
-
-
-
- -Zalando 开始将其基础架构从两个内部数据中心迁移到云,这需要迁移较旧的应用程序使其在云中准备就绪。“我们决定果断一些,” Jacobs 说。“我们的亚马逊网络服务基础设施是这样的:每个团队都有自己的 AWS 账户,该账户是完全隔离的,这意味着没有'提升和转移'。基本上必须重写应用程序,使其在云中准备就绪,甚至到持久层也是如此。我们勇敢地回到绘图板,重做一切,首先选择 Docker 作为通用容器化,然后从那里构建基础结构。”

- -公司最初决定推迟编排,但随着团队迁移到 AWS,“我们看到团队在 AWS 上的基础设施和使用云资源方面遇到了难题,” Jacobs 说。

- -Zalando 200多人的自主工程团队研究使用哪些技术,并可以使用自己的 AWS 账户操作自己的应用程序。事实证明,此设置是一项合规性挑战。即使制定了严格的游戏规则和自动化的合规性检查,工程团队和 IT 合规性在解决合规性问题方面也负担过重。Jacobs 说:"违规行为会出现,我们在扫描云基础架构时会检测到这些行为。“一切皆有可能,没有强制实施,因此您必须忍受违规行为(并解决它们),而不是一开始就防止错误。这些都会增加团队的开销,以及合规性和操作的开销。在 AWS 上启动新的 EC2 实例也需要时间,这会影响我们的部署速度。”

- -Jacobs 说,团队意识到他们需要“利用从集群管理中获得的价值”。当他们在2015年首次将平台视为服务(PaaS)选项时,市场是支离破碎的;但“现在似乎有一个明确的赢家。使用 Kubernetes 似乎是一个很好的尝试。”

- -Kubernetes 的过渡始于 2016 年 Zalando 的极客周期间,参与者将他们的项目部署到 Kubernetes 集群。60名技术基础设施部门的成员开始使用这项技术,之后每次会加入一支工程团队。Jacobs 说:“我们总是从与他们交谈开始,确保每个人的期望都清晰。然后,我们进行一些 Kubernetes 培训,这主要是针对我们的 CI/CD 设置的培训,因为我们的用户界面主要通过 CI/CD 系统。但是他们必须知道Kubernetes的基本概念和API。之后每周与每个团队同步,以检查其进度。一旦出现什么状况,就可以确定我们所做的改进是否正常。” - -
-
-
-
- -一旦Zalando开始将应用迁移到Kubernetes,效果立竿见影。“Kubernetes 是我们无缝端到端开发人员体验的基石。我们能够使用单一一致且声明性的 API 将创意运送到生产中,” Jacobs 说。 -
-
- -
-
- -目前,Zalando正在运行最初的40个Kubernetes集群,并计划在可预见的将来进行扩展。一旦Zalando开始将申请迁移到Kubernetes,效果立竿见影。“ Kubernetes 是我们无缝端到端开发人员体验的基石。我们能够使用单一一致且声明性的 API 将创意运送到生产中,” Jacobs 说。“自愈基础架构提供了无摩擦体验,基于低级最佳实践构建了更高级别的抽象。我们设想所有 Zalando 交付团队都将在 Kubernetes 提供的最先进的可靠和可扩展群集基础架构上运行其容器化应用程序。” - -Jacobs 说,使用旧的内部基础设施,“很难正确采用新技术,而 DevOps 团队被视为瓶颈。”“现在,有了这个云基础架构,它们有了这种打包格式,可以包含运行在 Linux 内核中的任何内容。这使得很多人相当高兴。工程师喜欢自主性。”在Zalando的Kubernetes实施中出现了一些挑战。Jacobs 说:“我们是一支由七人组成的团队,为不同的工程团队提供集群,我们的目标是为所有团队提供坚如磐石的体验。”“我们不想要宠物集群。我们不想了解他们的工作量;它应该只是开箱即用。考虑到这一点,集群自动缩放非常重要。执行集群管理的方法有很多种,这不是核心的一部分。因此,我们创建了两个组件来预配群集,具有集群的注册表,并管理整个集群生命周期。”

- -Jacobs 的团队还致力于改进Kubernetes-AWS 集成。“由于许多限制条件,需要通过基础设施来扩展每个自主团队的想法。” - -此外,“仍然缺少很多最佳实践,”Jacobs说。例如,该团队最近解决了 pod 安全策略问题。“在Kubernetes已经有一个概念,但没有记录,所以有点棘手,”他说。大型的Kubernetes社区是解决这个问题的一大帮助。为了帮助其他公司走上同样的道路,Jacobs在一份名为“在生产中运行 Kubernetes ”的文件中汇编了他的团队的经验教训。 - -
-
- -
-
- -“ Kubernetes API 允许我们以与云提供商无关的方式运行应用程序,这使我们能够在未来几年中自由访问 IaaS 提供商...我们期望 Kubernetes API 成为 PaaS 基础设施的全球标准,并对未来的继续旅程感到兴奋。” -
-
-
-
- -最后,Kubernetes 使 Zalando 能够引进和维护公司为发展其平台而设想的新产品。Jacobs 说:“时尚咨询产品使用 Scala,而我们以前的基础设施也难以实现这一点。”这是一个解决方法,该团队需要平台团队提供越来越多的支持,只是因为他们使用了不同的技术。现在有了Kubernetes,它就自主了。无论工作负载是什么,该团队都可以走自己的路,而 Kubernetes 可以防止其他瓶颈。

- -展望未来,Jacobs 将 Zalando 的新基础设施视为公司在进行的其他工程中的巨大推动因素,从新的物流软件到连接品牌的平台功能,以及数据科学家梦寐以求的产品。Jacobs说:“一个愿景是,如果你看下一部 James Bond 的电影,看看他穿的西装,你就应该能够自动订购,并在一小时内把它送到你身边。”“这是关于连接整个时尚领域。如果您遇到瓶颈,因为每个人都在同一个数据中心运行,因此限制很大,则这绝对是不可能的。需要基础设施来扩展每个自主团队的想法。”

- -对于考虑这项技术的其他公司,Jacobs 说,他不一定建议像 Zalando 那样做。他表示:“如果你准备尝试失败,那么这样做是可以的。”“设定正确的期望是必须的。并不是一切都会起作用。重写应用和这种类型的组织更改可能会造成中断。我们移动的第一个产品至关重要。存在大量依赖关系,而且时间比预期长。也许我们应该从不那么复杂、不是业务关键的东西开始,只是为了开个好头。”

- -但是,一旦他们到了另一边,“每个人都很清楚,没有大的选择,” Jacobs 补充说。“ Kubernetes API 允许我们以与云提供商无关的方式运行应用程序,这使我们能够在未来几年中自由访问 IaaS 提供商。Zalando 受益于迁移到 Kubernetes,因为我们能够利用现有知识创建工程平台,为我们的工程师提供灵活性和速度,同时显著降低运营开销。我们期望 Kubernetes API 成为 PaaS 基础设施的全球标准,并对未来的旅程感到兴奋。” - -
- -
+ +

但是,一旦他们到了另一边,“每个人都很清楚,没有大的选择,” Jacobs 补充说。“Kubernetes API 允许我们以与云提供商无关的方式运行应用程序,这使我们能够在未来几年中自由访问 IaaS 提供商。Zalando 受益于迁移到 Kubernetes,因为我们能够利用现有知识创建工程平台,为我们的工程师提供灵活性和速度,同时显著降低运营开销。我们期望 Kubernetes API 成为 PaaS 基础设施的全球标准,并对未来的旅程感到兴奋。”

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 e8d99338ffd35..ed3075a273ebb 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 @@ -54,7 +54,7 @@ API 服务器被配置为在一个安全的 HTTPS 端口(通常为 443)上 Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the API server along with valid client credentials. A good approach is that the client credentials provided to the kubelet are in the form of a client certificate. See -[kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) +[kubelet TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates. --> 应该使用集群的公共根证书开通节点,这样它们就能够基于有效的客户端凭据安全地连接 API 服务器。 diff --git a/content/zh-cn/docs/concepts/architecture/nodes.md b/content/zh-cn/docs/concepts/architecture/nodes.md index a57f98dc14ad0..b50ded16816cd 100644 --- a/content/zh-cn/docs/concepts/architecture/nodes.md +++ b/content/zh-cn/docs/concepts/architecture/nodes.md @@ -1170,14 +1170,13 @@ see [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) and its * 进一步了解节点[组件](/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) + [Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node) 的章节。 * 了解[污点和容忍度](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)。 - diff --git a/content/zh-cn/docs/concepts/cluster-administration/addons.md b/content/zh-cn/docs/concepts/cluster-administration/addons.md index 0c231d5bb76b1..88514c9729085 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/addons.md +++ b/content/zh-cn/docs/concepts/cluster-administration/addons.md @@ -11,15 +11,11 @@ content_type: concept Add-ons extend the functionality of Kubernetes. This page lists some of the available add-ons and links to their respective installation instructions. - -Add-ons in each section are sorted alphabetically - the ordering does not imply any preferential status. --> Add-ons 扩展了 Kubernetes 的功能。 本文列举了一些可用的 add-ons 以及到它们各自安装说明的链接。 -每个 Add-ons 按字母顺序排序 - 顺序不代表任何优先地位。 - -## 网络和网络策略 +## 联网和网络策略 * [ACI](https://www.github.com/noironetworks/aci-containers) 通过 Cisco ACI 提供集成的容器网络和安全网络。 * [Antrea](https://antrea.io/) 在第 3/4 层执行操作,为 Kubernetes 提供网络连接和安全服务。Antrea 利用 Open vSwitch 作为网络的数据面。 -* [Calico](https://docs.projectcalico.org/v3.11/getting-started/kubernetes/installation/calico) - 是一个安全的 L3 网络和网络策略驱动。 -* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) 结合 Flannel 和 Calico,提供网络和网络策略。 +* [Calico](https://docs.projectcalico.org/latest/introduction/) 是一个联网和网络策略供应商。 + Calico 支持一套灵活的网络选项,因此你可以根据自己的情况选择最有效的选项,包括非覆盖和覆盖网络,带或不带 BGP。 + Calico 使用相同的引擎为主机、Pod 和(如果使用 Istio 和 Envoy)应用程序在服务网格层执行网络策略。 +* [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) 结合 Flannel 和 Calico,提供联网和网络策略。 * [Cilium](https://github.com/cilium/cilium) 是一个 L3 网络和网络策略插件,能够透明的实施 HTTP/API/L7 策略。 - 同时支持路由(routing)和覆盖/封装(overlay/encapsulation)模式。 -* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) 使 Kubernetes 无缝连接到一种 CNI 插件, - 例如:Flannel、Calico、Canal 或者 Weave。 + 同时支持路由(routing)和覆盖/封装(overlay/encapsulation)模式,并且它可以在其他 CNI 插件之上工作。 + +* [CNI-Genie](https://github.com/cni-genie/CNI-Genie) 使 Kubernetes 无缝连接到 + Calico、Canal、Flannel 或 Weave 等其中一种 CNI 插件。 * [Contiv](https://contivpp.io/) 为各种用例和丰富的策略框架提供可配置的网络 - (使用 BGP 的本机 L3、使用 vxlan 的覆盖、标准 L2 和 Cisco-SDN/ACI)。 + (带 BGP 的原生 L3、带 vxlan 的覆盖、标准 L2 和 Cisco-SDN/ACI)。 Contiv 项目完全[开源](https://github.com/contiv)。 - [安装程序](https://github.com/contiv/install) 提供了基于 kubeadm 和非 kubeadm 的安装选项。 -* 基于 [Tungsten Fabric](https://tungsten.io) 的 - [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) - 是一个开源的多云网络虚拟化和策略管理平台,Contrail 和 Tungsten Fabric 与业务流程系统 - (例如 Kubernetes、OpenShift、OpenStack和Mesos)集成在一起, + 其[安装程序](https://github.com/contiv/install) 提供了基于 kubeadm 和非 kubeadm 的安装选项。 +* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) 基于 + [Tungsten Fabric](https://tungsten.io),是一个开源的多云网络虚拟化和策略管理平台。 + Contrail 和 Tungsten Fabric 与业务流程系统(例如 Kubernetes、OpenShift、OpenStack 和 Mesos)集成在一起, 为虚拟机、容器或 Pod 以及裸机工作负载提供了隔离模式。 + * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) 是一个可以用于 Kubernetes 的 overlay 网络提供者。 -* [Knitter](https://github.com/ZTE/Knitter/) 是为 kubernetes 提供复合网络解决方案的网络组件。 -* Multus 是一个多插件,可在 Kubernetes 中提供多种网络支持, - 以支持所有 CNI 插件(例如 Calico,Cilium,Contiv,Flannel), +* [Knitter](https://github.com/ZTE/Knitter/) 是在一个 Kubernetes Pod 中支持多个网络接口的插件。 +* [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) 是一个多插件, + 可在 Kubernetes 中提供多种网络支持,以支持所有 CNI 插件(例如 Calico、Cilium、Contiv、Flannel), 而且包含了在 Kubernetes 中基于 SRIOV、DPDK、OVS-DPDK 和 VPP 的工作负载。 + * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) 是一个 Kubernetes 网络驱动, 基于 [OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)实现,是从 Open vSwitch (OVS) - 项目衍生出来的虚拟网络实现。 - OVN-Kubernetes 为 Kubernetes 提供基于覆盖网络的网络实现,包括一个基于 OVS 实现的负载均衡器 - 和网络策略。 -* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) 是一个基于 OVN 的 CNI - 控制器插件,提供基于云原生的服务功能链条(Service Function Chaining,SFC)、多种 OVN 覆盖 - 网络、动态子网创建、动态虚拟网络创建、VLAN 驱动网络、直接驱动网络,并且可以 - 驳接其他的多网络插件,适用于基于边缘的、多集群联网的云原生工作负载。 -* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 容器插件(NCP) + 项目衍生出来的虚拟网络实现。OVN-Kubernetes 为 Kubernetes 提供基于覆盖网络的网络实现, + 包括一个基于 OVS 实现的负载均衡器和网络策略。 +* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) 是一个基于 OVN 的 CNI 控制器插件, + 提供基于云原生的服务功能链条(Service Function Chaining,SFC)、多种 OVN 覆盖网络、动态子网创建、 + 动态虚拟网络创建、VLAN 驱动网络、直接驱动网络,并且可以驳接其他的多网络插件, + 适用于基于边缘的、多集群联网的云原生工作负载。 + +* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) 容器插件(NCP) 提供了 VMware NSX-T 与容器协调器(例如 Kubernetes)之间的集成,以及 NSX-T 与基于容器的 CaaS / PaaS 平台(例如关键容器服务(PKS)和 OpenShift)之间的集成。 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) @@ -87,7 +90,7 @@ Add-ons 扩展了 Kubernetes 的功能。 * [Romana](https://github.com/romana) 是一个 Pod 网络的第三层解决方案,并支持 [NetworkPolicy](/zh-cn/docs/concepts/services-networking/network-policies/) API。 * [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) - 提供在网络分组两端参与工作的网络和网络策略,并且不需要额外的数据库。 + 提供在网络分组两端参与工作的联网和网络策略,并且不需要额外的数据库。 网络模型的早期设计、运行原理以及未来的一些计划, -都在[联网设计文档](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)里有更详细的描述。 +都在[联网设计文档](https://git.k8s.io/design-proposals-archive/network/networking.md)里有更详细的描述。 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 9791183f47ab1..ecd0cfea78702 100644 --- a/content/zh-cn/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/zh-cn/docs/concepts/containers/container-lifecycle-hooks.md @@ -71,8 +71,8 @@ parameters are passed to the handler. 而被终止之前,此回调会被调用。 如果容器已经处于已终止或者已完成状态,则对 preStop 回调的调用将失败。 在用来停止容器的 TERM 信号被发出之前,回调必须执行结束。 -Pod 的终止宽限周期在 `PreStop` 回调被执行之前即开始计数,所以无论 -回调函数的执行结果如何,容器最终都会在 Pod 的终止宽限期内被终止。 +Pod 的终止宽限周期在 `PreStop` 回调被执行之前即开始计数, +所以无论回调函数的执行结果如何,容器最终都会在 Pod 的终止宽限期内被终止。 没有参数会被传递给处理程序。 ### 回调递送保证 -回调的递送应该是 *至少一次*,这意味着对于任何给定的事件, +回调的递送应该是**至少一次**,这意味着对于任何给定的事件, 例如 `PostStart` 或 `PreStop`,回调可以被调用多次。 如何正确处理被多次调用的情况,是回调实现所要考虑的问题。 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 91eb354810558..85710cda6a46e 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 @@ -13,9 +13,9 @@ Every Kubernetes object also has a [_UID_](#uids) that is unique across your who For example, you can only have one Pod named `myapp-1234` within the same [namespace](/docs/concepts/overview/working-with-objects/namespaces/), but you can have one Pod and one Deployment that are each named `myapp-1234`. --> -集群中的每一个对象都有一个[_名称_](#names)来标识在同类资源中的唯一性。 +集群中的每一个对象都有一个[**名称**](#names)来标识在同类资源中的唯一性。 -每个 Kubernetes 对象也有一个 [_UID_](#uids) 来标识在整个集群中的唯一性。 +每个 Kubernetes 对象也有一个 [**UID**](#uids) 来标识在整个集群中的唯一性。 比如,在同一个[名字空间](/zh-cn/docs/concepts/overview/working-with-objects/namespaces/) 中有一个名为 `myapp-1234` 的 Pod,但是可以命名一个 Pod 和一个 Deployment 同为 `myapp-1234`。 @@ -171,9 +171,9 @@ UUIDs 是标准化的,见 ISO/IEC 9834-8 和 ITU-T X.667。 * 进一步了解 Kubernetes [标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/) -* 参阅 [Kubernetes 标识符和名称](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)的设计文档 +* 参阅 [Kubernetes 标识符和名称](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md)的设计文档 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 47c758d2672bc..d3dd367df763c 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 @@ -318,18 +318,18 @@ Disadvantages compared to imperative object configuration: - [使用指令式命令管理 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/) +- [使用配置文件对 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) +- [Kubectl Book](https://kubectl.docs.kubernetes.io/zh/) - [Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/zh-cn/docs/concepts/policy/limit-range.md b/content/zh-cn/docs/concepts/policy/limit-range.md index da2560b6a0b88..3eb7f7eee6d9f 100644 --- a/content/zh-cn/docs/concepts/policy/limit-range.md +++ b/content/zh-cn/docs/concepts/policy/limit-range.md @@ -28,7 +28,7 @@ A _LimitRange_ provides constraints that can: - Set default request/limit for compute resources in a namespace and automatically inject them to Containers at runtime. --> -一个 _LimitRange(限制范围)_ 对象提供的限制能够做到: +一个 **LimitRange(限制范围)** 对象提供的限制能够做到: - 在一个命名空间中实施对每个 Pod 或 Container 最小和最大的资源使用量的限制。 - 在一个命名空间中实施对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小的限制。 @@ -40,13 +40,14 @@ A _LimitRange_ provides constraints that can: LimitRange support has been enabled by default since Kubernetes 1.10. -LimitRange support is enabled by default for many Kubernetes distributions. +A LimitRange is enforced in a particular namespace when there is a +LimitRange object in that namespace. --> ## 启用 LimitRange 对 LimitRange 的支持自 Kubernetes 1.10 版本默认启用。 -LimitRange 支持在很多 Kubernetes 发行版本中也是默认启用的。 +当某命名空间中有一个 LimitRange 对象时,将在该命名空间中实施 LimitRange 限制。 -参阅 [LimitRanger 设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)获取更多信息。 +参阅 [LimitRanger 设计文档](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)获取更多信息。 -关于使用限值的例子,可参看 +关于使用限值的例子,可参阅: - [如何配置每个命名空间最小和最大的 CPU 约束](/zh-cn/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。 - [如何配置每个命名空间最小和最大的内存约束](/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。 diff --git a/content/zh-cn/docs/concepts/policy/resource-quotas.md b/content/zh-cn/docs/concepts/policy/resource-quotas.md index 75498e16b82d3..ede0a5f27ef22 100644 --- a/content/zh-cn/docs/concepts/policy/resource-quotas.md +++ b/content/zh-cn/docs/concepts/policy/resource-quotas.md @@ -33,7 +33,7 @@ be created in a namespace by type, as well as the total amount of compute resour be consumed by resources in that namespace. --> 资源配额,通过 `ResourceQuota` 对象来定义,对每个命名空间的资源消耗总量提供限制。 -它可以限制命名空间中某种类型的对象的总数目上限,也可以限制命令空间中的 Pod 可以使用的计算资源的总上限。 +它可以限制命名空间中某种类型的对象的总数目上限,也可以限制命名空间中的 Pod 可以使用的计算资源的总上限。 -- 不同的团队可以在不同的命名空间下工作。这可以通过 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 强制执行。 +- 不同的团队可以在不同的命名空间下工作。这可以通过 + [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 强制执行。 - 集群管理员可以为每个命名空间创建一个或多个 ResourceQuota 对象。 -- 当用户在命名空间下创建资源(如 Pod、Service 等)时,Kubernetes 的配额系统会 - 跟踪集群的资源使用情况,以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。 +- 当用户在命名空间下创建资源(如 Pod、Service 等)时,Kubernetes 的配额系统会跟踪集群的资源使用情况, + 以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。 - 如果资源创建或者更新请求违反了配额约束,那么该请求会报错(HTTP 403 FORBIDDEN), 并在消息中给出有可能违反的约束。 -- 如果命名空间下的计算资源 (如 `cpu` 和 `memory`)的配额被启用,则用户必须为 - 这些资源设定请求值(request)和约束值(limit),否则配额系统将拒绝 Pod 的创建。 +- 如果命名空间下的计算资源 (如 `cpu` 和 `memory`)的配额被启用, + 则用户必须为这些资源设定请求值(request)和约束值(limit),否则配额系统将拒绝 Pod 的创建。 提示: 可使用 `LimitRanger` 准入控制器来为没有设置计算资源需求的 Pod 设置默认值。 若想避免这类问题,请参考 @@ -161,7 +162,7 @@ The following resource types are supported: ### Resource Quota For Extended Resources In addition to the resources mentioned above, in release 1.10, quota support for -[extended resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) is added. +[extended resources](/docs/concepts/configuration/manage-resources-containers/#extended-resources) is added. --> ### 扩展资源的资源配额 @@ -316,12 +317,9 @@ Job 而导致集群拒绝服务。 对有限的一组资源上实施一般性的对象数量配额也是可能的。 -此外,还可以进一步按资源的类型设置其配额。 支持以下类型: @@ -466,10 +464,10 @@ one value. For example: ``` -如果 `operator` 为 `Exists` 或 `DoesNotExist`,则*不*可以设置 `values` 字段。 +如果 `operator` 为 `Exists` 或 `DoesNotExist`,则**不**可以设置 `values` 字段。 -如果配额对象通过 `scopeSelector` 字段设置其作用域为优先级类,则配额对象只能 -跟踪以下资源: +如果配额对象通过 `scopeSelector` 字段设置其作用域为优先级类, +则配额对象只能跟踪以下资源: * `pods` * `cpu` @@ -713,27 +711,27 @@ Operators can use `CrossNamespacePodAffinity` quota scope to limit which namespa have pods with affinity terms that cross namespaces. Specifically, it controls which pods are allowed to set `namespaces` or `namespaceSelector` fields in pod affinity terms. --> -集群运维人员可以使用 `CrossNamespacePodAffinity` 配额作用域来 -限制哪个名字空间中可以存在包含跨名字空间亲和性规则的 Pod。 -更为具体一点,此作用域用来配置哪些 Pod 可以在其 Pod 亲和性规则 -中设置 `namespaces` 或 `namespaceSelector` 字段。 +集群运维人员可以使用 `CrossNamespacePodAffinity` +配额作用域来限制哪个名字空间中可以存在包含跨名字空间亲和性规则的 Pod。 +更为具体一点,此作用域用来配置哪些 Pod 可以在其 Pod 亲和性规则中设置 +`namespaces` 或 `namespaceSelector` 字段。 -禁止用户使用跨名字空间的亲和性规则可能是一种被需要的能力,因为带有 -反亲和性约束的 Pod 可能会阻止所有其他名字空间的 Pod 被调度到某失效域中。 +禁止用户使用跨名字空间的亲和性规则可能是一种被需要的能力, +因为带有反亲和性约束的 Pod 可能会阻止所有其他名字空间的 Pod 被调度到某失效域中。 -使用此作用域操作符可以避免某些名字空间(例如下面例子中的 `foo-ns`)运行 -特别的 Pod,这类 Pod 使用跨名字空间的 Pod 亲和性约束,在该名字空间中创建 -了作用域为 `CrossNamespaceAffinity` 的、硬性约束为 0 的资源配额对象。 +使用此作用域操作符可以避免某些名字空间(例如下面例子中的 `foo-ns`)运行特别的 Pod, +这类 Pod 使用跨名字空间的 Pod 亲和性约束,在该名字空间中创建了作用域为 +`CrossNamespaceAffinity` 的、硬性约束为 0 的资源配额对象。 ```yaml apiVersion: v1 @@ -752,12 +750,12 @@ spec: -如果集群运维人员希望默认禁止使用 `namespaces` 和 `namespaceSelector`,而 -仅仅允许在特定名字空间中这样做,他们可以将 `CrossNamespaceAffinity` 作为一个 -被约束的资源。方法是为 `kube-apiserver` 设置标志 +如果集群运维人员希望默认禁止使用 `namespaces` 和 `namespaceSelector`, +而仅仅允许在特定名字空间中这样做,他们可以将 `CrossNamespaceAffinity` +作为一个被约束的资源。方法是为 `kube-apiserver` 设置标志 `--admission-control-config-file`,使之指向如下的配置文件: ```yaml @@ -779,8 +777,8 @@ With the above configuration, pods can use `namespaces` and `namespaceSelector` if the namespace where they are created have a resource quota object with `CrossNamespaceAffinity` scope and a hard limit greater than or equal to the number of pods using those fields. --> -基于上面的配置,只有名字空间中包含作用域为 `CrossNamespaceAffinity` 且 -硬性约束大于或等于使用 `namespaces` 和 `namespaceSelector` 字段的 Pods +基于上面的配置,只有名字空间中包含作用域为 `CrossNamespaceAffinity` +且硬性约束大于或等于使用 `namespaces` 和 `namespaceSelector` 字段的 Pod 个数时,才可以在该名字空间中继续创建在其 Pod 亲和性规则中设置 `namespaces` 或 `namespaceSelector` 的新 Pod。 @@ -987,18 +985,18 @@ should be allowed in a namespace, if and only if, a matching quota object exists (例如 "cluster-services")的 Pod。 -通过这种机制,操作人员能够将限制某些高优先级类仅出现在有限数量的命名空间中, +通过这种机制,操作人员能够限制某些高优先级类仅出现在有限数量的命名空间中, 而并非每个命名空间默认情况下都能够使用这些优先级类。 -要实现此目的,应设置 kube-apiserver 的标志 `--admission-control-config-file` +要实现此目的,应设置 `kube-apiserver` 的标志 `--admission-control-config-file` 指向如下配置文件: ```yaml @@ -1057,14 +1055,13 @@ and it is to be created in a namespace other than `kube-system`. ## {{% heading "whatsnext" %}} -- 查看[资源配额设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) -- 查看[如何使用资源配额的详细示例](/zh-cn/docs/tasks/administer-cluster/quota-api-object/)。 -- 阅读[优先级类配额支持的设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)。 - 了解更多信息。 -- 参阅 [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) +- 参阅[资源配额设计文档](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_resource_quota.md)。 +- 参阅[如何使用资源配额的详细示例](/zh-cn/docs/tasks/administer-cluster/quota-api-object/)。 +- 参阅[优先级类配额支持的设计文档](https://git.k8s.io/design-proposals-archive/scheduling/pod-priority-resourcequota.md)了解更多信息。 +- 参阅 [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)。 diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/_index.md b/content/zh-cn/docs/concepts/scheduling-eviction/_index.md index 3919a6cfa0715..5ff8e6e6ed494 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/_index.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/_index.md @@ -31,7 +31,17 @@ so that Pods with higher Priority can schedule on Nodes. Eviction is the process of terminating one or more Pods on Nodes. --> - + ## 调度 @@ -43,10 +53,20 @@ of terminating one or more Pods on Nodes. * [调度器的性能调试](/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) * [扩展资源的资源装箱](/zh-cn/docs/concepts/scheduling-eviction/resource-bin-packing/) - + ## Pod 干扰 +{{}} + * [Pod 优先级和抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) -* [节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* [节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/) * [API发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/) 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 c6d249d46507c..4eedc0c9edf36 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 @@ -18,13 +18,13 @@ weight: 20 你可以约束一个 {{< glossary_tooltip text="Pod" term_id="pod" >}} @@ -172,6 +172,19 @@ define. Some of the benefits of affinity and anti-affinity include: * 你可以使用节点上(或其他拓扑域中)运行的其他 Pod 的标签来实施调度约束, 而不是只能使用节点本身的标签。这个能力让你能够定义规则允许哪些 Pod 可以被放置在一起。 + +亲和性功能由两种类型的亲和性组成: + +* **节点亲和性**功能类似于 `nodeSelector` 字段,但它的表达能力更强,并且允许你指定软规则。 +* Pod 间亲和性/反亲和性允许你根据其他 Pod 的标签来约束 Pod。 + 在这一示例中,所应用的规则如下: -* 节点必须包含键名为 `kubernetes.io/os` 的标签,并且其取值为 `linux`。 -* 节点 **最好** 具有键名为 `another-node-label-key` 且取值为 +* 节点**必须**包含一个键名为 `topology.kubernetes.io/zone` 的标签, + 并且该标签的取值**必须**为 `antarctica-east1` 或 `antarctica-west1`。 +* 节点**最好**具有一个键名为 `another-node-label-key` 且取值为 `another-node-label-value` 的标签。 如果你指定了多个与同一 `nodeSelectorTerms` 关联的 `matchExpressions`, 则只有当所有 `matchExpressions` 都满足时 Pod 才可以被调度到节点上。 @@ -341,8 +355,8 @@ must have existing nodes with the `kubernetes.io/os=linux` label. 在配置多个[调度方案](/zh-cn/docs/reference/scheduling/config/#multiple-profiles)时, @@ -410,7 +424,7 @@ Inter-pod affinity and anti-affinity allow you to constrain which nodes your Pods can be scheduled on based on the labels of **Pods** already running on that node, instead of the node labels. --> -### pod 间亲和性与反亲和性 {#inter-pod-affinity-and-anti-affinity} +### Pod 间亲和性与反亲和性 {#inter-pod-affinity-and-anti-affinity} Pod 间亲和性与反亲和性使你可以基于已经在节点上运行的 **Pod** 的标签来约束 Pod 可以调度到的节点,而不是基于节点上的标签。 @@ -552,9 +566,9 @@ same zone currently running Pods with the `Security=S2` Pod label. -查阅[设计文档](https://github.com/kubernetes/design-proposals-archive/blob/main/scheduling/podaffinity.md) +查阅[设计文档](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md) 以进一步熟悉 Pod 亲和性与反亲和性的示例。 +以一个三节点的集群为例,该集群运行一个带有 Redis 这种内存缓存的 Web 应用程序。 +你可以使用节点间的亲和性和反亲和性来尽可能地将 Web 服务器与缓存并置。 + * 进一步阅读[污点与容忍度](/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) +* 阅读[节点亲和性](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md) + 和[Pod 间亲和性与反亲和性](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md) 的设计文档。 * 了解[拓扑管理器](/zh-cn/docs/tasks/administer-cluster/topology-manager/)如何参与节点层面资源分配决定。 * 了解如何使用 [nodeSelector](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes/)。 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 8a0910315e232..ce17740440cfd 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 @@ -22,7 +22,7 @@ During a node-pressure eviction, the kubelet sets the `PodPhase` for the selected pods to `Failed`. This terminates the pods. Node-pressure eviction is not the same as -[API-initiated eviction](/docs/reference/generated/kubernetes-api/v1.23/). +[API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/). --> {{}} 监控集群节点的 CPU、内存、磁盘空间和文件系统的 inode 等资源。 @@ -31,7 +31,7 @@ kubelet 可以主动地使节点上一个或者多个 Pod 失效,以回收资 在节点压力驱逐期间,kubelet 将所选 Pod 的 `PodPhase` 设置为 `Failed`。这将终止 Pod。 -节点压力驱逐不同于 [API 发起的驱逐](/docs/reference/generated/kubernetes-api/v1.23/)。 +节点压力驱逐不同于 [API 发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/)。 -一些 kubelet 垃圾收集功能已被弃用,以支持驱逐。 -有关已弃用功能的列表,请参阅 -[kubelet 垃圾收集弃用](/zh-cn/docs/concepts/cluster-administration/kubelet-garbage-collection/#deprecation)。 -{{}} +一些 kubelet 垃圾收集功能已被弃用,以鼓励使用驱逐机制。 + +| 现有标志 | 新的标志 | 原因 | +| ------------- | -------- | --------- | +| `--image-gc-high-threshold` | `--eviction-hard` 或 `--eviction-soft` | 现有的驱逐信号可以触发镜像垃圾收集 | +| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | 驱逐回收具有相同的行为 | +| `--maximum-dead-containers` | - | 一旦旧的日志存储在容器的上下文之外就会被弃用 | +| `--maximum-dead-containers-per-container` | - | 一旦旧的日志存储在容器的上下文之外就会被弃用 | +| `--minimum-container-ttl-duration` | - | 一旦旧的日志存储在容器的上下文之外就会被弃用 | -当 kubelet 因 inode 或 PID 不足而驱逐 pod 时, +当 kubelet 因 inode 或 PID 不足而驱逐 Pod 时, 它使用优先级来确定驱逐顺序,因为 inode 和 PID 没有请求。 kubelet 根据节点是否具有专用的 `imagefs` 文件系统对 Pod 进行不同的排序: @@ -648,7 +659,7 @@ Consider the following scenario: * 节点内存容量:`10Gi` * 操作员希望为系统守护进程(内核、`kubelet` 等)保留 10% 的内存容量 -* 操作员希望驱逐内存利用率为 95% 的Pod,以减少系统 OOM 的概率。 +* 操作员希望驱逐内存利用率为 95% 的 Pod,以减少系统 OOM 的概率。 -更多细节请参见 [https://github.com/kubernetes/kubernetes/issues/43916](https://github.com/kubernetes/kubernetes/issues/43916) +更多细节请参见 [https://github.com/kubernetes/kubernetes/issues/43916](https://github.com/kubernetes/kubernetes/issues/43916)。 你可以通过为可能执行 I/O 密集型活动的容器设置相同的内存限制和内存请求来应对该行为。 你将需要估计或测量该容器的最佳内存限制值。 @@ -765,14 +776,14 @@ to estimate or measure an optimal memory limit value for that container. ## {{% heading "whatsnext" %}} -* 了解 [API 发起的驱逐](/docs/reference/generated/kubernetes-api/v1.23/) -* 了解 [Pod 优先级和驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) -* 了解 [PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) +* 了解 [API 发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/) +* 了解 [Pod 优先级和抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* 了解 [PodDisruptionBudgets](/zh-cn/docs/tasks/run-application/configure-pdb/) * 了解[服务质量](/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-priority-preemption.md b/content/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption.md index afa224896ad60..cf4e594d6c2a5 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 @@ -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-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) Pod 的顺序。 +[节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/) Pod 的顺序。 你可以使用 QoS 类来估计 Pod 最有可能被驱逐的顺序。kubelet 根据以下因素对 Pod 进行驱逐排名: 1. 对紧俏资源的使用是否超过请求值 @@ -650,8 +650,8 @@ kubelet 使用优先级来确定 [kubelet 驱逐时 Pod 的选择](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction)。 当某 Pod 的资源用量未超过其请求时,kubelet 节点压力驱逐不会驱逐该 Pod。 -如果优先级较低的 Pod 没有超过其请求,则不会被驱逐。 -另一个优先级高于其请求的 Pod 可能会被驱逐。 +如果优先级较低的 Pod 的资源使用量没有超过其请求,则不会被驱逐。 +另一个优先级较高且资源使用量超过其请求的 Pod 可能会被驱逐。 ## {{% heading "whatsnext" %}} @@ -659,11 +659,11 @@ kubelet 使用优先级来确定 * Read about using ResourceQuotas in connection with PriorityClasses: [limit Priority Class consumption by default](/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default) * Learn about [Pod Disruption](/docs/concepts/workloads/pods/disruptions/) -* Learn about [API-initiated Eviction](/docs/reference/generated/kubernetes-api/v1.23/) +* Learn about [API-initiated Eviction](/docs/concepts/scheduling-eviction/api-eviction/) * Learn about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) --> * 阅读有关将 ResourceQuota 与 PriorityClass 结合使用的信息: [默认限制优先级消费](/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-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* 了解 [API 发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/) +* 了解[节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/) 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 53e60e1cb8592..a3c403081a726 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 @@ -528,6 +528,6 @@ 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-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/), +* 阅读[节点压力驱逐](/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/security/controlling-access.md b/content/zh-cn/docs/concepts/security/controlling-access.md index b8b671cb8a6ae..cf3b1bd4818a3 100644 --- a/content/zh-cn/docs/concepts/security/controlling-access.md +++ b/content/zh-cn/docs/concepts/security/controlling-access.md @@ -40,14 +40,18 @@ following diagram: ## 传输安全 {#transport-security} -在典型的 Kubernetes 集群中,API 服务器在 443 端口上提供服务,受 TLS 保护。 -API 服务器出示证书。 -该证书可以使用私有证书颁发机构(CA)签名,也可以基于链接到公认的 CA 的公钥基础架构签名。 +默认情况下,Kubernetes API 服务器在第一个非 localhost 网络接口的 6443 端口上进行监听, +受 TLS 保护。在一个典型的 Kubernetes 生产集群中,API 使用 443 端口。 +该端口可以通过 `--secure-port` 进行变更,监听 IP 地址可以通过 `--bind-address` 标志进行变更。 + +API 服务器出示证书。该证书可以使用私有证书颁发机构(CA)签名,也可以基于链接到公认的 CA 的公钥基础架构签名。 +该证书和相应的私钥可以通过使用 `--tls-cert-file` 和 `--tls-private-key-file` 标志进行设置。 -## API 服务器端口和 IP {#api-server-ports-and-ips} - - -前面的讨论适用于发送到 API 服务器的安全端口的请求(典型情况)。 API 服务器实际上可以在 2 个端口上提供服务: - -默认情况下,Kubernetes API 服务器在 2 个端口上提供 HTTP 服务: - - - 1. `localhost` 端口: - - - 用于测试和引导,以及主控节点上的其他组件(调度器,控制器管理器)与 API 通信 - - 没有 TLS - - 默认为端口 8080 - - 默认 IP 为 localhost,使用 `--insecure-bind-address` 进行更改 - - 请求 **绕过** 身份认证和鉴权模块 - - 由准入控制模块处理的请求 - - 受需要访问主机的保护 - - 2. “安全端口”: - - - 尽可能使用 - - 使用 TLS。 用 `--tls-cert-file` 设置证书,用 `--tls-private-key-file` 设置密钥 - - 默认端口 6443,使用 `--secure-port` 更改 - - 默认 IP 是第一个非本地网络接口,使用 `--bind-address` 更改 - - 请求须经身份认证和鉴权组件处理 - - 请求须经准入控制模块处理 - - 身份认证和鉴权模块运行 - +更多信息请参考[审计](/zh-cn/docs/tasks/debug/debug-cluster/audit/)。 ## {{% heading "whatsnext" %}} @@ -348,4 +296,4 @@ You can learn about: 你可以了解 - Pod 如何使用 [Secrets](/zh-cn/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials) - 获取 API 凭证. + 获取 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 243bd9529c360..22a5f7edcda79 100644 --- a/content/zh-cn/docs/concepts/security/pod-security-standards.md +++ b/content/zh-cn/docs/concepts/security/pod-security-standards.md @@ -43,8 +43,6 @@ Pod 安全性标准定义了三种不同的 **策略(Policy)**,以广泛 ## Profile 细节 {#profile-details} @@ -98,10 +96,9 @@ fail validation.
- - - - + + - - @@ -284,7 +280,7 @@ fail validation. - + - + - + - + - - + - - + + - @@ -86,7 +73,7 @@ metric2,label='v1,v2,v3'。 The reconciler sync wait time between volume attach detach. This duration must be larger than one second, and increasing this value from the default may allow for volumes to be mismatched with pods. --> 协调器(reconciler)在相邻两次对存储卷进行挂载和解除挂载操作之间的等待时间。 -此时长必须长于 1 秒钟。此值设置为大于默认值时,可能导致存储卷无法与 Pods 匹配。 +此时长必须长于 1 秒钟。此值设置为大于默认值时,可能导致存储卷无法与 Pod 匹配。 @@ -98,9 +85,9 @@ The reconciler sync wait time between volume attach detach. This duration must b -此标志值为一个 kubeconfig 文件的路径名。该文件中包含与某 Kubernetes “核心” +此标志值为一个 kubeconfig 文件的路径名。该文件中包含与某 Kubernetes “核心” 服务器相关的信息,并支持足够的权限以创建 tokenreviews.authentication.k8s.io。 -此选项是可选的。如果设置为空值,所有令牌请求都会被认作匿名请求, +此选项是可选的。如果设置为空值,则所有令牌请求都会被认作匿名请求, Kubernetes 也不再在集群中查找客户端的 CA 证书信息。 @@ -113,8 +100,8 @@ Kubernetes 也不再在集群中查找客户端的 CA 证书信息。 -此值为 false 时,通过 authentication-kubeconfig 参数所指定的文件会被用来 -检索集群中缺失的身份认证配置信息。 +此值为 false 时,通过 authentication-kubeconfig +参数所指定的文件会被用来检索集群中缺失的身份认证配置信息。 @@ -256,8 +243,8 @@ Type of CIDR allocator to use If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate. --> 如果设置了此标志,对于所有能够提供客户端证书的请求,若该证书由 ---client-ca-file 中所给机构之一签署,则该请求会被 -成功认证为客户端证书中 CommonName 所标识的实体。 +--client-ca-file 中所给机构之一签署, +则该请求会被成功认证为客户端证书中 CommonName 所标识的实体。 @@ -293,7 +280,7 @@ The provider for cloud services. Empty string for no provider. -集群中 Pods 的 CIDR 范围。要求 --allocate-node-cidrs 标志为 true。 +集群中 Pod 的 CIDR 范围。要求 --allocate-node-cidrs 标志为 true。 @@ -318,7 +305,7 @@ The instance prefix for the cluster. Filename containing a PEM-encoded X509 CA certificate used to issue cluster-scoped certificates. If specified, no more specific --cluster-signing-* flag may be specified. --> 包含 PEM 编码格式的 X509 CA 证书的文件名。该证书用来发放集群范围的证书。 -如果设置了此标志,则不能指定更具体的--cluster-signing-* 标志。 +如果设置了此标志,则不能指定更具体的 --cluster-signing-* 标志。 @@ -331,7 +318,7 @@ Filename containing a PEM-encoded X509 CA certificate used to issue cluster-scop The max length of duration signed certificates will be given. Individual CSRs may request shorter certs by setting spec.expirationSeconds. --> -所签名证书的有效期限。每个 CSR 可以通过设置 spec.expirationSeconds 来请求更短的证书。 +所签名证书的有效期限。每个 CSR 可以通过设置 spec.expirationSeconds 来请求更短的证书。 @@ -358,7 +345,7 @@ If specified, no more specific --cluster-signing-* flag may be specified. Filename containing a PEM-encoded X509 CA certificate used to issue certificates for the kubernetes.io/kube-apiserver-client signer. If specified, --cluster-signing-{cert,key}-file must not be set. --> 包含 PEM 编码的 X509 CA 证书的文件名, -该证书用于为 kubernetes.io/kube-apiserver-client 签署者颁发证书。 +该证书用于为 kubernetes.io/kube-apiserver-client 签署者颁发证书。 如果指定,则不得设置 --cluster-signing-{cert,key}-file。 @@ -372,7 +359,7 @@ Filename containing a PEM-encoded X509 CA certificate used to issue certificates Filename containing a PEM-encoded RSA or ECDSA private key used to sign certificates for the kubernetes.io/kube-apiserver-client signer. If specified, --cluster-signing-{cert,key}-file must not be set. --> 包含 PEM 编码的 RSA 或 ECDSA 私钥的文件名, -该私钥用于为 kubernetes.io/kube-apiserver-client 签署者签名证书。 +该私钥用于为 kubernetes.io/kube-apiserver-client 签署者签名证书。 如果指定,则不得设置 --cluster-signing-{cert,key}-file。 @@ -386,7 +373,7 @@ Filename containing a PEM-encoded RSA or ECDSA private key used to sign certific Filename containing a PEM-encoded X509 CA certificate used to issue certificates for the kubernetes.io/kube-apiserver-client-kubelet signer. If specified, --cluster-signing-{cert,key}-file must not be set. --> 包含 PEM 编码的 X509 CA 证书的文件名, -该证书用于为 kubernetes.io/kube-apiserver-client-kubelet 签署者颁发证书。 +该证书用于为 kubernetes.io/kube-apiserver-client-kubelet 签署者颁发证书。 如果指定,则不得设置 --cluster-signing-{cert,key}-file。 @@ -672,7 +659,7 @@ Interval between starting controller managers. -要启用的控制器列表。\* 表示启用所有默认启用的控制器; +要启用的控制器列表。* 表示启用所有默认启用的控制器; foo 启用名为 foo 的控制器; -foo 表示禁用名为 foo 的控制器。
控制器的全集:attachdetach、bootstrapsigner、cloud-node-lifecycle、clusterrole-aggregation、cronjob、csrapproving、csrcleaner、csrsigning、daemonset、deployment、disruption、endpoint、endpointslice、endpointslicemirroring、ephemeral-volume、garbagecollector、horizontalpodautoscaling、job、namespace、nodeipam、nodelifecycle、persistentvolume-binder、persistentvolume-expander、podgc、pv-protection、pvc-protection、replicaset、replicationcontroller、resourcequota、root-ca-cert-publisher、route、service、serviceaccount、serviceaccount-token、statefulset、tokencleaner、ttl、ttl-after-finished
@@ -700,13 +687,11 @@ Disable volume attach detach reconciler sync. Disabling this may cause volumes t -此标志提供对行为异常的度量值的防控措施。你必须提供度量值的 -完全限定名称才能将其禁用。声明:禁用度量值的操作比显示隐藏度量值 -的操作优先级高。 +此标志提供对行为异常的度量值的防控措施。你必须提供度量值的完全限定名称才能将其禁用。 +声明:禁用度量值的操作比显示隐藏度量值的操作优先级高。

- @@ -741,7 +726,7 @@ Enable HostPath PV provisioning when running without a cloud provider. This allo --> 在没有云驱动程序的情况下,启用 HostPath 持久卷的制备。 此参数便于对卷供应功能进行开发和测试。HostPath 卷的制备并非受支持的功能特性, -在多节点的集群中也无法工作,因此除了开发和测试环境中不应使用。 +在多节点的集群中也无法工作,因此除了开发和测试环境中不应使用 HostPath 卷的制备。 @@ -757,7 +742,6 @@ Whether to enable controller leader migration.

- @@ -766,8 +750,8 @@ Whether to enable controller leader migration. -警告:此为Beta 阶段特性。设置为 true 时会启用 NoExecute 污点, -并在所有标记了此污点的节点上逐出所有无法忍受该污点的 Pods。 +警告:此为 Beta 阶段特性。设置为 true 时会启用 NoExecute 污点, +并在所有标记了此污点的节点上驱逐所有无法忍受该污点的 Pod。 @@ -779,7 +763,7 @@ WARNING: Beta feature. If set to true enables NoExecute Taints and will evict al -端点(Endpoint)批量更新周期时长。对 Pods 变更的处理会被延迟, +端点(Endpoint)批量更新周期时长。对 Pod 变更的处理会被延迟, 以便将其与即将到来的更新操作合并,从而减少端点更新操作次数。 较大的数值意味着端点更新的迟滞时间会增长,也意味着所生成的端点版本个数会变少。 @@ -793,7 +777,7 @@ The length of endpoint updates batching period. Processing of pod changes will b -端点片段(Endpoint Slice)批量更新周期时长。对 Pods 变更的处理会被延迟, +端点片段(Endpoint Slice)批量更新周期时长。对 Pod 变更的处理会被延迟, 以便将其与即将到来的更新操作合并,从而减少端点更新操作次数。 较大的数值意味着端点更新的迟滞时间会增长,也意味着所生成的端点版本个数会变少。 @@ -808,8 +792,8 @@ The length of endpoint slice updates batching period. Processing of pod changes The plugin to use when cloud provider is set to external. Can be empty, should only be set when cloud-provider is external. Currently used to allow node and volume controllers to work for in tree cloud providers. --> 当云驱动程序设置为 external 时要使用的插件名称。此字符串可以为空。 -只能在云驱动程序为 external 时设置。目前用来保证节点控制器和卷控制器能够 -在三种云驱动上正常工作。 +只能在云驱动程序为 external 时设置。 +目前用来保证节点控制器和卷控制器能够在三种云驱动上正常工作。 @@ -922,7 +906,7 @@ WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (BETA - default=true)
WindowsHostProcessContainers=true|false (BETA - default=true) --> -一组 key=value 对,用来描述测试性/试验性功能的特性门控(Feature Gate)。可选项有: +一组 key=value 对,用来描述测试性/试验性功能的特性门控(Feature Gate)。可选项有:
APIListChunking=true|false (BETA - 默认值=true)
APIPriorityAndFairness=true|false (BETA - 默认值=true)
APIResponseCompression=true|false (BETA - 默认值=true)
@@ -1071,8 +1055,8 @@ Pod 启动之后可以忽略 CPU 采样值的时长。 -自动扩缩程序的回溯时长。自动扩缩器不会基于在给定的时长内所建议的规模 -对负载执行规模缩小的操作。 +自动扩缩程序的回溯时长。 +自动扩缩程序不会基于在给定的时长内所建议的规模对负载执行缩容操作。 @@ -1096,7 +1080,7 @@ Pod 启动之后,在此值所给定的时长内,就绪状态的变化都不 -水平 Pod 扩缩器对 Pods 数目执行同步操作的周期。 +水平 Pod 扩缩器对 Pod 数目执行同步操作的周期。 @@ -1182,8 +1166,9 @@ Path to kubeconfig file with authorization and master location information. -节点控制器在执行 Pod 逐出操作逻辑时,基于此标志所设置的节点个数阈值来判断 -所在集群是否为大规模集群。当集群规模小于等于此规模时, +节点控制器在执行 Pod 驱逐操作逻辑时, +基于此标志所设置的节点个数阈值来判断所在集群是否为大规模集群。 +当集群规模小于等于此规模时, --secondary-node-eviction-rate 会被隐式重设为 0。 @@ -1209,10 +1194,11 @@ Start a leader election client and gain leadership before executing the main loo -对于未获得领导者身份的节点,在探测到领导者身份需要更迭时需要等待 -此标志所设置的时长,才能尝试去获得曾经是领导者但尚未续约的席位。 -本质上,这个时长也是现有领导者节点在被其他候选节点替代之前可以停止 -的最长时长。只有集群启用了领导者选举机制时,此标志才起作用。 +对于未获得领导者身份的节点, +在探测到领导者身份需要更迭时需要等待此标志所设置的时长, +才能尝试去获得曾经是领导者但尚未续约的席位。本质上, +这个时长也是现有领导者节点在被其他候选节点替代之前可以停止的最长时长。 +只有集群启用了领导者选举机制时,此标志才起作用。 @@ -1240,7 +1226,7 @@ The interval between attempts by the acting master to renew a leadership slot be The type of resource object that is used for locking during leader election. Supported options are 'leases', 'endpointsleases' and 'configmapsleases'. --> 在领导者选举期间用于锁定的资源对象的类型。 支持的选项为 -"leases"、"endpointsleases" 和 "configmapsleases"。 +leasesendpointsleasesconfigmapsleases。 @@ -1465,8 +1451,8 @@ Number of nodes per second on which pods are deleted in case of node failure whe --> 当某区域健康时,在节点故障的情况下每秒删除 Pods 的节点数。 请参阅 --unhealthy-zone-threshold -以了解“健康”的判定标准。这里的区域(zone)在集群并不跨多个区域时 -指的是整个集群。 +以了解“健康”的判定标准。 +这里的区域(zone)在集群并不跨多个区域时指的是整个集群。 @@ -1545,7 +1531,7 @@ If true, SO_REUSEPORT will be used when binding the port, which allows more than -在失效的节点上删除 Pods 时为其预留的宽限期。 +在失效的节点上删除 Pod 时为其预留的宽限期。 @@ -1569,8 +1555,8 @@ Enable profiling via web interface host:port/debug/pprof/ -NFS 清洗 Pod 在清洗用过的卷时,根据此标志所设置的秒数,为每清洗 1 GiB 数据 -增加对应超时时长,作为 activeDeadlineSeconds。 +NFS 清洗 Pod 在清洗用过的卷时,根据此标志所设置的秒数, +为每清洗 1 GiB 数据增加对应超时时长,作为 activeDeadlineSeconds。 @@ -1607,7 +1593,7 @@ NFS 回收器 Pod 要使用的 activeDeadlineSeconds 参数下限。 -对 HostPath 持久卷进行回收利用时,用作模版的 Pod 定义文件所在路径。 +对 HostPath 持久卷进行回收利用时,用作模板的 Pod 定义文件所在路径。 此标志仅用于开发和测试目的,不适合多节点集群中使用。 @@ -1620,7 +1606,7 @@ The file path to a pod definition used as a template for HostPath persistent vol -对 NFS 卷执行回收利用时,用作模版的 Pod 定义文件所在路径。 +对 NFS 卷执行回收利用时,用作模板的 Pod 定义文件所在路径。 @@ -1759,7 +1745,7 @@ The period for reconciling routes created for Nodes by cloud provider. -当区域不健康,节点失效时,每秒钟从此标志所给的节点个数上删除 Pods。 +当一个区域不健康造成节点失效时,每秒钟从此标志所给的节点上删除 Pod 的节点个数。 参见 --unhealthy-zone-threshold 以了解“健康与否”的判定标准。 在只有一个区域的集群中,区域指的是整个集群。如果集群规模小于 --large-cluster-size-threshold 所设置的节点个数时, @@ -1826,8 +1812,8 @@ The previous version for which you want to show hidden metrics. Only the previou -在已终止 Pods 垃圾收集器删除已终止 Pods 之前,可以保留的已删除 -Pods 的个数上限。若此值小于等于 0,则相当于禁止垃圾回收已终止的 Pods。 +在已终止 Pod 垃圾收集器删除已终止 Pod 之前,可以保留的已终止 Pod 的个数上限。 +若此值小于等于 0,则相当于禁止垃圾回收已终止的 Pod。 @@ -1896,8 +1882,9 @@ A pair of x509 certificate and private key file paths, optionally suffixed with --> X509 证书和私钥文件路径的耦对。作为可选项,可以添加域名模式的列表, 其中每个域名模式都是可以带通配片段前缀的全限定域名(FQDN)。 -域名模式也可以使用 IP 地址字符串,不过只有 API 服务器在所给 IP 地址上 -对客户端可见时才可以使用 IP 地址。在未提供域名模式时,从证书中提取域名。 +域名模式也可以使用 IP 地址字符串, +不过只有 API 服务器在所给 IP 地址上对客户端可见时才可以使用 IP 地址。 +在未提供域名模式时,从证书中提取域名。 如果有非通配方式的匹配,则优先于通配方式的匹配;显式的域名模式优先于提取的域名。 当存在多个密钥/证书耦对时,可以多次使用 --tls-sni-cert-key 标志。 例如:example.crt,example.keyfoo.crt,foo.key:\*.foo.com,foo.com。 diff --git a/content/zh-cn/docs/reference/config-api/kubelet-config.v1beta1.md b/content/zh-cn/docs/reference/config-api/kubelet-config.v1beta1.md index 15864fe93d192..e67edb1a92846 100644 --- a/content/zh-cn/docs/reference/config-api/kubelet-config.v1beta1.md +++ b/content/zh-cn/docs/reference/config-api/kubelet-config.v1beta1.md @@ -971,7 +971,7 @@ run those in addition to the pods specified by static pod files, and exit. Default: false -->

runOnce字段被设置时,kubelet 会咨询 API 服务器一次并获得 Pod 列表, -运行在静态 Pod 文件中指定的 Pod 及这里所获得的的 Pod,然后退出。

+运行在静态 Pod 文件中指定的 Pod 及这里所获得的 Pod,然后退出。

默认值:false

@@ -1467,13 +1467,13 @@ Default: "" @@ -1486,13 +1486,13 @@ Default: "" @@ -1509,7 +1509,7 @@ If none is specified, no other options may be specified. When system-reserved is in the list, systemReservedCgroup must be specified. When kube-reserved is in the list, kubeReservedCgroup must be specified. This field is supported only when cgroupsPerQOS is set to true. -Refer to Node Allocatable +Refer to Node Allocatable for more information. Default: ["pods"] --> @@ -1520,7 +1520,7 @@ Default: ["pods"]

如果列表中包含system-reserved,则必须设置systemReservedCgroup

如果列表中包含kube-reserved,则必须设置kubeReservedCgroup

这个字段只有在cgroupsPerQOS被设置为true才被支持。

-

参阅Node Allocatable +

参阅Node Allocatable 了解进一步的信息。

默认值:["pods"]

diff --git a/content/zh-cn/docs/reference/kubectl/cheatsheet.md b/content/zh-cn/docs/reference/kubectl/cheatsheet.md index 8878d01f7f66c..f85846aa3285a 100644 --- a/content/zh-cn/docs/reference/kubectl/cheatsheet.md +++ b/content/zh-cn/docs/reference/kubectl/cheatsheet.md @@ -334,6 +334,9 @@ kubectl get pods --selector=app=cassandra -o \ kubectl get configmap myconfig \ -o jsonpath='{.data.ca\.crt}' +# Retrieve a base64 encoded value with dashes instead of underscores. +kubectl get secret my-secret --template='{{index .data "key-name-with-dashes"}}' + # Get all worker nodes (use a selector to exclude results that have a label # named 'node-role.kubernetes.io/control-plane') kubectl get node --selector='!node-role.kubernetes.io/control-plane' @@ -417,6 +420,9 @@ kubectl get pods --selector=app=cassandra -o \ kubectl get configmap myconfig \ -o jsonpath='{.data.ca\.crt}' +# 检索一个 base64 编码的值,其中的键名应该包含减号而不是下划线。 +kubectl get secret my-secret --template='{{index .data "key-name-with-dashes"}}' + # 获取所有工作节点(使用选择器以排除标签名称为 'node-role.kubernetes.io/control-plane' 的结果) kubectl get node --selector='!node-role.kubernetes.io/control-plane' diff --git a/content/zh-cn/docs/reference/kubernetes-api/authorization-resources/self-subject-access-review-v1.md b/content/zh-cn/docs/reference/kubernetes-api/authorization-resources/self-subject-access-review-v1.md index 164a054c41422..6ed5ef043144d 100644 --- a/content/zh-cn/docs/reference/kubernetes-api/authorization-resources/self-subject-access-review-v1.md +++ b/content/zh-cn/docs/reference/kubernetes-api/authorization-resources/self-subject-access-review-v1.md @@ -45,8 +45,8 @@ Self 是一个特殊情况,因为用户应始终能够检查自己是否可以 --> - **metadata** (}}">ObjectMeta) - 标准的列表元数据。 - 更多信息: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** (}}">SelfSubjectAccessReviewSpec),必需 diff --git a/content/zh-cn/docs/reference/kubernetes-api/authorization-resources/self-subject-rules-review-v1.md b/content/zh-cn/docs/reference/kubernetes-api/authorization-resources/self-subject-rules-review-v1.md index e4c39decdca3d..487f23ab28761 100644 --- a/content/zh-cn/docs/reference/kubernetes-api/authorization-resources/self-subject-rules-review-v1.md +++ b/content/zh-cn/docs/reference/kubernetes-api/authorization-resources/self-subject-rules-review-v1.md @@ -30,7 +30,7 @@ SelfSubjectRulesReview 枚举当前用户可以在某命名空间内执行的操 返回的操作列表可能不完整,具体取决于服务器的鉴权模式以及评估过程中遇到的任何错误。 SelfSubjectRulesReview 应由 UI 用于显示/隐藏操作,或让最终用户尽快理解自己的权限。 SelfSubjectRulesReview 不得被外部系统使用以驱动鉴权决策, -因为这会引起混淆代理人(confused deputy)、缓存有效期/吊销(cache lifetime/revocation)和正确性问题。 +因为这会引起混淆代理人(Confused deputy)、缓存有效期/吊销(Cache lifetime/revocation)和正确性问题。 SubjectAccessReview 和 LocalAccessReview 是遵从 API 服务器所做鉴权决策的正确方式。
@@ -49,8 +49,8 @@ SubjectAccessReview 和 LocalAccessReview 是遵从 API 服务器所做鉴权决 --> - **metadata** (}}">ObjectMeta) - 标准的列表元数据。 - 更多信息: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** (}}">SelfSubjectRulesReviewSpec),必需 @@ -60,12 +60,6 @@ SubjectAccessReview 和 LocalAccessReview 是遵从 API 服务器所做鉴权决 Status is filled in by the server and indicates the set of actions a user can perform. *SubjectRulesReviewStatus contains the result of a rules check. This check can be incomplete depending on the set of authorizers the server is configured with and any errors experienced during evaluation. Because authorization rules are additive, if a rule appears in a list it's safe to assume the subject has that permission, even if that list is incomplete.* - - **status.incomplete** (boolean), required - Incomplete is true when the rules returned by this call are incomplete. This is most commonly encountered when an authorizer, such as an external authorizer, doesn't support rules evaluation. - - **status.nonResourceRules** ([]NonResourceRule), required - NonResourceRules is the list of actions the subject is allowed to perform on non-resources. The list ordering isn't significant, may contain duplicates, and possibly be incomplete. - - *NonResourceRule holds information that describes a rule for the non-resource* --> - **status** (SubjectRulesReviewStatus) @@ -76,6 +70,15 @@ SubjectAccessReview 和 LocalAccessReview 是遵从 API 服务器所做鉴权决 此检查可能不完整,具体取决于服务器配置的 Authorizer 的集合以及评估期间遇到的任何错误。 由于鉴权规则是叠加的,所以如果某个规则出现在列表中,即使该列表不完整,也可以安全地假定该主体拥有该权限。** + + - **status.incomplete** (boolean),必需 当此调用返回的规则不完整时,incomplete 结果为 true。 @@ -88,28 +91,33 @@ SubjectAccessReview 和 LocalAccessReview 是遵从 API 服务器所做鉴权决 **nonResourceRule 包含描述非资源路径的规则的信息。** - + NonResourceURLs is a set of partial urls that a user should have access to. *s are allowed, but only as the full, final step in the path. "*" means all. + --> + - **status.nonResourceRules.verbs** ([]string),必需 verb 是 kubernetes 非资源 API 动作的列表,例如 get、post、put、delete、patch、head、options。 - "*" 表示所有动作。 + `*` 表示所有动作。 - **status.nonResourceRules.nonResourceURLs** ([]string) nonResourceURLs 是用户应有权访问的一组部分 URL。 - 允许使用 "*",但仅能作为路径中最后一段且必须用于完整的一段。 - "*" 表示全部。 + 允许使用 `*`,但仅能作为路径中最后一段且必须用于完整的一段。 + `*` 表示全部。 + + - **status.resourceRules** ([]ResourceRule),必需 @@ -122,8 +130,9 @@ SubjectAccessReview 和 LocalAccessReview 是遵从 API 服务器所做鉴权决 - **status.resourceRules.verbs** ([]string),必需 verb 是 kubernetes 资源 API 动作的列表,例如 get、list、watch、create、update、delete、proxy。 - "*" 表示所有动作。 - + --> + - **status.resourceRules.apiGroups** ([]string) apiGroups 是包含资源的 APIGroup 的名称。 如果指定了多个 API 组,则允许对任何 API 组中枚举的资源之一请求任何操作。 - "*" 表示所有 APIGroup。 + `*` 表示所有 APIGroup。 - **status.resourceRules.resourceNames** ([]string) resourceNames 是此规则所适用的资源名称白名单,可选。 空集合意味着允许所有资源。 - "*" 表示所有资源。 + `*` 表示所有资源。 - **status.resourceRules.resources** ([]string) resources 是此规则所适用的资源的列表。 - "*" 表示指定 APIGroup 中的所有资源。 - "*/foo" 表示指定 APIGroup 中所有资源的子资源 "foo"。 + `*` 表示指定 APIGroup 中的所有资源。 + `*/foo` 表示指定 APIGroup 中所有资源的子资源 "foo"。 + + - **status.evaluationError** (string) diff --git a/content/zh-cn/docs/reference/kubernetes-api/authorization-resources/subject-access-review-v1.md b/content/zh-cn/docs/reference/kubernetes-api/authorization-resources/subject-access-review-v1.md index be42036d46dcf..b4120827cf95f 100644 --- a/content/zh-cn/docs/reference/kubernetes-api/authorization-resources/subject-access-review-v1.md +++ b/content/zh-cn/docs/reference/kubernetes-api/authorization-resources/subject-access-review-v1.md @@ -43,8 +43,8 @@ SubjectAccessReview 检查用户或组是否可以执行某操作。 - **status** (}}">SubjectAccessReviewStatus) Status is filled in by the server and indicates whether the request is allowed or not --> - 标准的列表元数据。 - 更多信息: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** (}}">SubjectAccessReviewSpec),必需 diff --git a/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/event-v1.md b/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/event-v1.md new file mode 100644 index 0000000000000..a62915f651eb8 --- /dev/null +++ b/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/event-v1.md @@ -0,0 +1,935 @@ +--- +api_metadata: + apiVersion: "events.k8s.io/v1" + import: "k8s.io/api/events/v1" + kind: "Event" +content_type: "api_reference" +description: "Event 是集群中某个事件的报告。" +title: "Event" +weight: 3 +--- + + + +`apiVersion: events.k8s.io/v1` + +`import "k8s.io/api/events/v1"` + +## Event {#Event} + +Event 是集群中某个事件的报告。它一般表示系统的某些状态变化。 +Event 的保留时间有限,触发器和消息可能会随着时间的推移而演变。 +事件消费者不应假定给定原因的事件的时间所反映的是一致的下层触发因素,或具有该原因的事件的持续存在。 +Events 应被视为通知性质的、尽最大努力而提供的补充数据。 + +
+ +- **apiVersion**: events.k8s.io/v1 + +- **kind**: Event + +- **metadata** (}}">ObjectMeta) + + + 标准的对象元数据。更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + + + +- **eventTime** (MicroTime),必需 + + evenTime 是该事件首次被观察到的时间。它是必需的。 + + + + + + **MicroTime 是微秒级精度的 Time 版本** + +- **action** (string) + + + action 是针对相关对象所采取的或已失败的动作。字段值是机器可读的。对于新的 Event,此字段不能为空, + 且最多为 128 个字符。 + +- **deprecatedCount** (int32) + + + deprecatedCount 是确保与 core.v1 Event 类型向后兼容的已弃用字段。 + +- **deprecatedFirstTimestamp** (Time) + + + deprecatedFirstTimestamp 是确保与 core.v1 Event 类型向后兼容的已弃用字段。 + + + + + **Time 是对 time.Time 的封装。Time 支持对 YAML 和 JSON 进行正确封包。为 time 包的许多函数方法提供了封装器。** + +- **deprecatedLastTimestamp** (Time) + + + deprecatedLastTimestamp 是确保与 core.v1 Event 类型向后兼容的已弃用字段。 + + + + + **Time 是对 time.Time 的封装。Time 支持对 YAML 和 JSON 进行正确封包。为 time 包的许多函数方法提供了封装器。** + +- **deprecatedSource** (EventSource) + + + deprecatedSource 是确保与 core.v1 Event 类型向后兼容的已弃用字段。 + + + + + + **EventSource 包含事件信息。** + + - **deprecatedSource.component** (string) + + + + 生成事件的组件。 + + - **deprecatedSource.host** (string) + + + + 产生事件的节点名称。 + +- **note** (string) + + + node 是对该操作状态的可读描述。注释的最大长度是 1kB,但是库应该准备好处理最多 64kB 的值。 + +- **reason** (string) + + + reason 是采取行动的原因。它是人类可读的。对于新的 Event,此字段不能为空,且最多为128个字符。 + +- **regarding** (}}">ObjectReference) + + + 关于包含此 Event 所涉及的对象。在大多数情况下,所指的是报告事件的控制器所实现的一个 Object。 + 例如 ReplicaSetController 实现了 ReplicaSet,这个事件被触发是因为控制器对 ReplicaSet 对象做了一些变化。 + +- **related** (}}">ObjectReference) + + + related 是用于更复杂操作的、可选的、从属性的对象。例如,当 regarding 对象触发 related 对象的创建或删除时。 + +- **reportingController** (string) + + + reportingController 是触发该事件的控制器的名称,例如 `kubernetes.io/kubelet`。对于新的 Event,此字段不能为空。 + +- **reportingInstance** (string) + + + reportingInstance 为控制器实例的 ID,例如 `kubelet-xyzf`。对于新的 Event,此字段不能为空,且最多为 128 个字符。 + +- **series** (EventSeries) + + + series 是该事件代表的事件系列的数据,如果是单事件,则为 nil。 + + + + + EventSeries 包含一系列事件的信息,即一段时间内持续发生的事情。 + EventSeries 的更新频率由事件报告者决定。 + 默认事件报告程序在 "k8s.io/client-go/tools/events/event_broadcaster.go" + 展示在发生心跳时该结构如何被更新,可以指导定制的报告者实现。 + + + + - **series.count** (int32),必需 + + + + count 是到最后一次心跳时间为止在该系列中出现的次数。 + + + + - **series.lastObservedTime** (MicroTime),必需 + + lastObservedTime 是在最后一次心跳时间之前看到最后一个 Event 的时间。 + + + + + + **MicroTime 是微秒级精度的 Time 版本。** + +- **type** (string) + + + type 是该事件的类型(Normal、Warning),未来可能会添加新的类型。字段值是机器可读的。 + 对于新的 Event,此字段不能为空。 + +## EventList {#EventList} + + +EventList 是一个 Event 对象列表。 + +
+ +- **apiVersion**: events.k8s.io/v1 + +- **kind**: EventList + +- **metadata** (}}">ListMeta) + + + 标准的列表元数据。更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + + +- **items** ([]}}">Event),必需 + + items 是模式(Schema)对象的列表。 + + +## 操作 {#操作} + +
+ + +### `get` 读取特定 Event + +#### HTTP 请求 + +GET /apis/events.k8s.io/v1/namespaces/{namespace}/events/{name} + + +#### 参数 + + +- **name** (**路径参数**):string,必需 + + Event 名称 + + +- **namespace** (**路径参数**):string,必需 + + }}">namespace + + +- **pretty** (**路径参数**):string + + }}">pretty + + +#### 响应 + +200 (}}">Event): OK + +401: Unauthorized + + +### `list` 列出或观察事件类型对象 + +#### HTTP 请求 + +GET /apis/events.k8s.io/v1/namespaces/{namespace}/events + + +#### 参数 + + +- **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 (}}">EventList): OK + +401: Unauthorized + + +### `list` 列出或观察事件类型对象 + +#### HTTP 请求 + +GET /apis/events.k8s.io/v1/events + + +#### 参数 + + +- **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 (}}">EventList): OK + +401: Unauthorized + + +### `create` 创建一个 Event + +#### HTTP 请求 + +POST /apis/events.k8s.io/v1/namespaces/{namespace}/events + + +#### 参数 + + +- **namespace** (**查询参数**):string,必需 + + }}">namespace + + +- **body**: }}">Event,必需 + + +- **dryRun** (**查询参数**):string + + }}">dryRun + + +- **fieldManager** (**查询参数**):string + + }}">fieldManager + + +- **fieldValidation** (**查询参数**):string + + }}">fieldValidation + + +- **pretty** (**查询参数**):string + + }}">pretty + + +#### 响应 + +200 (}}">Event): OK + +201 (}}">Event): Created + +202 (}}">Event): Accepted + +401: Unauthorized + + +### `update` 替换指定 Event + +#### HTTP 请求 + +PUT /apis/events.k8s.io/v1/namespaces/{namespace}/events/{name} + +#### 参数 + + +- **name** (**路径参数**):string,必需 + + Event 名称 + + +- **namespace** (**路径参数**):string,必需 + + }}">namespace + + +- **body**:}}">Event,必需 + + +- **dryRun** (**查询参数**):必需 + + }}">dryRun + + +- **fieldManager** (**查询参数**):string + + }}">fieldManager + + +- **fieldValidation** (**查询参数**):string + + }}">fieldValidation + + +- **pretty** (**查询参数**):string + + }}">pretty + + +#### 响应 + +200 (}}">Event): OK + +201 (}}">Event): Created + +401: Unauthorized + + +### `patch` 部分更新指定的 Event + +#### HTTP 请求 + +PATCH /apis/events.k8s.io/v1/namespaces/{namespace}/events/{name} + + +#### 参数 + + +- **name** (**路径参数**):string,必需 + + Event 名称 + + +- **namespace** (**路径参数**):string,必需 + + }}">namespace + + +- **body**: }}">Patch,必需 + + + +- **dryRun** (**查询参数**):string + + }}">dryRun + + +- **fieldManager** (**查询参数**):string + + }}">fieldManager + + +- **fieldValidation** (**查询参数**):string + + }}">fieldValidation + + +- **force** (**查询参数**):boolean + + }}">force + + +- **pretty** (**查询参数**):string + + }}">pretty + + +#### 响应 + +200 (}}">Event): OK + +201 (}}">Event): Created + +401: Unauthorized + + +### `delete` 删除 Event + +#### HTTP 请求 + +DELETE /apis/events.k8s.io/v1/namespaces/{namespace}/events/{name} + + +#### 参数 + + +- **name** (**路径参数**):string,必需 + + Event 名称 + + +- **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` 删除 Event 集合 + +#### HTTP 请求 + +DELETE /apis/events.k8s.io/v1/namespaces/{namespace}/events + + +#### 参数 + + +- **namespace** (*in path*):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 + diff --git a/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/node-v1.md b/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/node-v1.md new file mode 100644 index 0000000000000..51b368411756b --- /dev/null +++ b/content/zh-cn/docs/reference/kubernetes-api/cluster-resources/node-v1.md @@ -0,0 +1,1567 @@ +--- +api_metadata: + apiVersion: "v1" + import: "k8s.io/api/core/v1" + kind: "Node" +content_type: "api_reference" +description: "Node 是 Kubernetes 中的工作节点。" +title: "Node" +weight: 1 +--- + + + +`apiVersion: v1` + +`import "k8s.io/api/core/v1"` + +## Node {#Node} + + + +Node 是 Kubernetes 中的工作节点。 +每个节点在缓存中(即在 etcd 中)都有一个唯一的标识符。 + +
+ +- **apiVersion**: v1 + +- **kind**: Node + + + +- **metadata** (}}">ObjectMeta) + + 标准的对象元数据。 + 更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata 。 + + + +- **spec** (}}">NodeSpec) + + spec 定义节点的行为。 + https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status 。 + + + +- **status** (}}">NodeStatus) + + 此节点的最近观测状态。由系统填充。只读。 + 更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status 。 + +## NodeSpec {#NodeSpec} + + + +NodeSpec 描述了创建节点时使用的属性。 + +
+ +- **configSource** (NodeConfigSource) + + + + 已弃用:以前用于为 DynamicKubeletConfig 功能指定节点配置的来源。 + 自 1.24 的版本起,此功能已从 Kubelets 中移除,并将在 1.26 的版本中完全移除。 + + + + + **NodeConfigSource 指定节点配置的来源。指定一个子字段(不包括元数据)必须为非空。此 API 自 1.22的版本起已被弃用** + + - **configSource.configMap** (ConfigMapNodeConfigSource) + + + + configMap 是对 Node 的 ConfigMap 的引用。 + + + + + ConfigMapNodeConfigSource 包含引用某 ConfigMap 作为节点配置源的信息。 + 此 API 自 1.22 版本起已被弃用: https://git.k8s.io/enhancements/keps/sig-node/281-dynamic-kubelet-configuration + + + + - **configSource.configMap.kubeletConfigKey** (string), 必需 + + kubeletConfigKey 声明所引用的 ConfigMap 的哪个键对应于 KubeletConfiguration 结构体, + 该字段在所有情况下都是必需的。 + + + + - **configSource.configMap.name** (string), 必需 + + name 是被引用的 ConfigMap 的 metadata.name。 + 此字段在所有情况下都是必需的。 + + + + - **configSource.configMap.namespace** (string), 必需 + + namespace 是所引用的 ConfigMap 的 metadata.namespace。 + 此字段在所有情况下都是必需的。 + + - **configSource.configMap.resourceVersion** (string) + + + + resourceVersion 是所引用的 ConfigMap 的 metadata.resourceVersion。 + 该字段在 Node.spec 中是禁止的,在 Node.status 中是必需的。 + + - **configSource.configMap.uid** (string) + + + + uid 是所引用的 ConfigMap 的 metadata.uid。 + 该字段在 Node.spec 中是禁止的,在 Node.status 中是必需的。 + +- **externalID** (string) + + + + 已弃用。并非所有 kubelet 都会设置此字段。 + 1.13 的版本之后会删除该字段。见: https://issues.k8s.io/61966 。 + +- **podCIDR** (string) + + + + podCIDR 表示分配给节点的 Pod IP 范围。 + +- **podCIDRs** ([]string) + + + + podCIDRs 表示分配给节点以供该节点上的 Pod 使用的 IP 范围。 + 如果指定了该字段,则第 0 个条目必须与 podCIDR 字段匹配。 + 对于 IPv4 和 IPv6,它最多可以包含 1 个值。 + +- **providerID** (string) + + + + 云提供商分配的节点ID,格式为:\://\ + +- **taints** ([]Taint) + + + + 如果设置了,则为节点的污点。 + + + + + **此污点附加到的节点对任何不容忍污点的 Pod 都有 “影响”。** + + + + - **taints.effect** (string), 必需 + + 必需的。污点对不容忍污点的 Pod 的影响。合法的 effect 值有 NoSchedule、PreferNoSchedule 和 NoExecute。 + + + + - **taints.key** (string), 必需 + + 必需的。被应用到节点上的污点的键。 + + - **taints.timeAdded** (Time) + + + + timeAdded 表示添加污点的时间。它仅适用于 NoExecute 的污点。 + + + + + Time 是 time.Time 的包装器,它支持对 YAML 和 JSON 的正确编组。 + time 包的许多工厂方法提供了包装器。 + + - **taints.value** (string) + + + + 与污点键对应的污点值。 + +- **unschedulable** (boolean) + + + + unschedulable 控制新 Pod 的节点可调度性。 + 默认情况下,节点是可调度的。 + 更多信息: https://kubernetes.io/docs/concepts/nodes/node/#manual-node-administration 。 + +## NodeStatus {#NodeStatus} + + + +NodeStatus 是有关节点当前状态的信息。 + +
+ +- **addresses** ([]NodeAddress) + + + + **补丁策略:根据 `type` 键执行合并操作** + + 节点可到达的地址列表。从云提供商处查询(如果有)。 + 更多信息: https://kubernetes.io/docs/concepts/nodes/node/#addresses 。 + 注意:该字段声明为可合并,但合并键不够唯一,合并时可能导致数据损坏。 + 调用者应改为使用完全替换性质的补丁操作。 + 有关示例,请参见 http://pr.k8s.io/79391。 + + + + + **NodeAddress 包含节点地址的信息。** + + + + - **addresses.address** (string), 必需 + + 节点地址。 + + + + - **addresses.type** (string), 必需 + + 节点地址类型,Hostname、ExternalIP 或 InternalIP 之一。 + +- **allocatable** (map[string]}}">Quantity) + + + + allocatable 表示节点的可用于调度的资源。默认为容量。 + +- **capacity** (map[string]}}">Quantity) + + + + capacity 代表一个节点的总资源。 + 更多信息: https://kubernetes.io/docs/concepts/storage/persistent-volumes#capacity 。 + +- **conditions** ([]NodeCondition) + + + + **补丁策略:根据 `type` 键执行合并操作** + + conditions 是当前观测到的节点状况的数组。 + 更多信息: https://kubernetes.io/docs/concepts/nodes/node/#condition 。 + + + + + **NodeCondition 包含节点状况的信息。** + + + + - **conditions.status** (string), 必需 + + 状况的状态为 True、False、Unknown 之一。 + + + + - **conditions.type** (string), 必需 + + 节点状况的类型。 + + - **conditions.lastHeartbeatTime** (Time) + + + + 给定状况最近一次更新的时间。 + + + + + Time 是 time.Time 的包装器,它支持对 YAML 和 JSON 的正确编组。 + time 包的许多工厂方法提供了包装器。 + + - **conditions.lastTransitionTime** (Time) + + + + 状况最近一次从一种状态转换到另一种状态的时间。 + + + + + Time 是 time.Time 的包装器,它支持对 YAML 和 JSON 的正确编组。 + time 包的许多工厂方法提供了包装器。 + + - **conditions.message** (string) + + + + 指示有关上次转换详细信息的人类可读消息。 + + - **conditions.reason** (string) + + + + (简要)状况最后一次转换的原因。 + +- **config** (NodeConfigStatus) + + + + 通过动态 Kubelet 配置功能分配给节点的配置状态。 + + + + + **NodeConfigStatus 描述了由 Node.spec.configSource 分配的配置的状态。** + + - **config.active** (NodeConfigSource) + + + + active 报告节点正在使用的检查点配置。 + active 将代表已分配配置的当前版本或当前 LastKnownGood 配置,具体取决于尝试使用已分配配置是否会导致错误。 + + + + + **NodeConfigSource 指定节点配置的来源。指定一个子字段(不包括元数据)必须为非空。此 API 自 1.22 版本起已弃用** + + - **config.active.configMap** (ConfigMapNodeConfigSource) + + + + configMap 是对 Node 的 ConfigMap 的引用。 + + + + + ConfigMapNodeConfigSource 包含引用某 ConfigMap 作为节点配置源的信息。 + 此 API 自 1.22 版本起已被弃用: https://git.k8s.io/enhancements/keps/sig-node/281-dynamic-kubelet-configuration。 + + + + - **config.active.configMap.kubeletConfigKey** (string), 必需 + + kubeletConfigKey 声明所引用的 ConfigMap 的哪个键对应于 KubeletConfiguration 结构体, + 该字段在所有情况下都是必需的。 + + + + - **config.active.configMap.name** (string), 必需 + + name 是所引用的 ConfigMap 的 metadata.name。 + 此字段在所有情况下都是必需的。 + + + + - **config.active.configMap.namespace** (string), 必需 + + namespace 是所引用的 ConfigMap 的 metadata.namespace。 + 此字段在所有情况下都是必需的。 + + - **config.active.configMap.resourceVersion** (string) + + + + resourceVersion 是所引用的 ConfigMap 的 metadata.resourceVersion。 + 该字段在 Node.spec 中是禁止的,在 Node.status 中是必需的。 + + - **config.active.configMap.uid** (string) + + + + uid 是所引用的 ConfigMap 的 metadata.uid。 + 该字段在 Node.spec 中是禁止的,在 Node.status 中是必需的。 + + - **config.assigned** (NodeConfigSource) + + + + assigned 字段报告节点将尝试使用的检查点配置。 + 当 Node.spec.configSource 被更新时,节点将所关联的配置负载及指示预期配置的记录通过检查点操作加载到本地磁盘。 + 节点参考这条记录来选择它的配置检查点,并在 assigned 中报告这条记录。 + 仅在记录被保存到磁盘后才会更新 status 中的 assigned。 + 当 kubelet 重新启动时,它会尝试通过加载和验证由 assigned 标识的检查点有效负载来使 assigned 配置成为 active 配置。 + + + + + **NodeConfigSource 指定节点配置的来源。指定一个子字段(不包括元数据)必须为非空。此 API 自 1.22 版本起已弃用** + + - **config.assigned.configMap** (ConfigMapNodeConfigSource) + + + + configMap 是对 Node 的 ConfigMap 的引用。 + + + + + ConfigMapNodeConfigSource 包含引用某 ConfigMap 为节点配置源的信息。 + 此 API 自 1.22 版本起已被弃用: https://git.k8s.io/enhancements/keps/sig-node/281-dynamic-kubelet-configuration。 + + + + - **config.assigned.configMap.kubeletConfigKey** (string), 必需 + + kubeletConfigKey 声明所引用的 ConfigMap 的哪个键对应于 KubeletConfiguration 结构体, + 该字段在所有情况下都是必需的。 + + + + - **config.assigned.configMap.name** (string), 必需 + + name 是所引用的 ConfigMap 的 metadata.name。 + 此字段在所有情况下都是必需的。 + + + + - **config.assigned.configMap.namespace** (string), 必需 + + namespace 是所引用的 ConfigMap 的 metadata.namespace。 + 此字段在所有情况下都是必需的。 + + - **config.assigned.configMap.resourceVersion** (string) + + + + resourceVersion 是所引用的 ConfigMap 的 metadata.resourceVersion。 + 该字段在 Node.spec 中是禁止的,在 Node.status 中是必需的。 + + - **config.assigned.configMap.uid** (string) + + + + uid 是所引用的 ConfigMap 的 metadata.uid。 + 该字段在 Node.spec 中是禁止的,在 Node.status 中是必需的。 + + - **config.error** (string) + + + + error 描述了在 spec.configSource 与活动配置间协调时发生的所有问题。 + 可能会发生的情况,例如,尝试将 spec.configSource 通过检查点操作复制到到本地 assigned 记录时, + 尝试对与 spec.configSource 关联的有效负载执行检查点操作,尝试加​​载或验证 assigned 的配置时。 + 同步配置时可能会在不同位置发生错误,较早的错误(例如下载或检查点错误)不会导致回滚到 LastKnownGood, + 并且可能会在 Kubelet 重试后解决。 + 后期发生的错误(例如加载或验证检查点配置)将导致回滚到 LastKnownGood。 + 在后一种情况下,通常可以通过修复 spec.sonfigSource 中 assigned 配置来解决错误。 + 你可以通过在 Kubelet 日志中搜索错误消息来找到更多的调试信息。 + error 是错误状态的人类可读描述;机器可以检查 error 是否为空,但不应依赖跨 Kubelet 版本的 error 文本的稳定性。 + + - **config.lastKnownGood** (NodeConfigSource) + + + + lastKnownGood 报告节点在尝试使用 assigned 配置时遇到错误时将回退到的检查点配置。 + 当节点确定 assigned 配置稳定且正确时,assigned 配置会成为 lastKnownGood 配置。 + 这当前实施为从更新分配配置的本地记录开始的 10 分钟浸泡期。 + 如果在此期间结束时分配的配置依旧处于活动状态,则它将成为 lastKnownGood。 + 请注意,如果 spec.configSource 重置为 nil(使用本地默认值), + LastKnownGood 也会立即重置为 nil,因为始终假定本地默认配置是好的。 + 你不应该对节点确定配置稳定性和正确性的方法做出假设,因为这可能会在将来发生变化或变得可配置。 + + + + + **NodeConfigSource 指定节点配置的来源。指定一个子字段(不包括元数据)必须为非空。此 API 自 1.22 版本起已弃用** + + - **config.lastKnownGood.configMap** (ConfigMapNodeConfigSource) + + + + configMap 是对 Node 的 ConfigMap 的引用。 + + + + + ConfigMapNodeConfigSource 包含引用某 ConfigMap 作为节点配置源的信息。 + 此 API 自 1.22 版本起已被弃用: https://git.k8s.io/enhancements/keps/sig-node/281-dynamic-kubelet-configuration 。 + + + + - **config.lastKnownGood.configMap.kubeletConfigKey** (string), 必需 + + kubeletConfigKey 声明所引用的 ConfigMap 的哪个键对应于 KubeletConfiguration 结构体, + 该字段在所有情况下都是必需的。 + + + + - **config.lastKnownGood.configMap.name** (string), 必需 + + name 是所引用的 ConfigMap 的 metadata.name。 + 此字段在所有情况下都是必需的。 + + + + - **config.lastKnownGood.configMap.namespace** (string), 必需 + + namespace 是所引用的 ConfigMap 的 metadata.namespace。 + 此字段在所有情况下都是必需的。 + + - **config.lastKnownGood.configMap.resourceVersion** (string) + + + + resourceVersion 是所引用的 ConfigMap 的 metadata.resourceVersion。 + 该字段在 Node.spec 中是禁止的,在 Node.status 中是必需的。 + + - **config.lastKnownGood.configMap.uid** (string) + + + + uid 是所引用的 ConfigMap 的 metadata.uid。 + 该字段在 Node.spec 中是禁止的,在 Node.status 中是必需的。 + +- **daemonEndpoints** (NodeDaemonEndpoints) + + + + 在节点上运行的守护进程的端点。 + + + + + **NodeDaemonEndpoints 列出了节点上运行的守护进程打开的端口。** + + - **daemonEndpoints.kubeletEndpoint** (DaemonEndpoint) + + + + Kubelet 正在侦听的端点。 + + + + + **DaemonEndpoint 包含有关单个 Daemon 端点的信息。** + + + + - **daemonEndpoints.kubeletEndpoint.Port** (int32), 必需 + + 给定端点的端口号。 + +- **images** ([]ContainerImage) + + + + 该节点上的容器镜像列表。 + + + + + **描述一个容器镜像** + + - **images.names** ([]string) + + + + 已知此镜像的名称。 + 例如 ["k8s.gcr.io/hyperkube:v1.0.7", "dockerhub.io/google_containers/hyperkube:v1.0.7"] + + - **images.sizeBytes** (int64) + + + + 镜像的大小(以字节为单位)。 + +- **nodeInfo** (NodeSystemInfo) + + + + 用于唯一标识节点的 ids/uuids 集。 + 更多信息: https://kubernetes.io/docs/concepts/nodes/node/#info 。 + + + + + **NodeSystemInfo 是一组用于唯一标识节点的 ids/uuids。** + + + + - **nodeInfo.architecture** (string), 必需 + + 节点报告的 architecture。 + + + + - **nodeInfo.bootID** (string), 必需 + + 节点报告的 bootID。 + + + + - **nodeInfo.containerRuntimeVersion** (string), 必需 + + 节点通过运行时远程 API 报告的 ContainerRuntime 版本(例如 containerd://1.4.2)。 + + + + - **nodeInfo.kernelVersion** (string), 必需 + + 节点来自 “uname -r” 报告的内核版本(例如 3.16.0-0.bpo.4-amd64)。 + + + + - **nodeInfo.kubeProxyVersion** (string), 必需 + + 节点报告的 KubeProxy 版本。 + + + + - **nodeInfo.kubeletVersion** (string), 必需 + + 节点报告的 Kubelet 版本。 + + + + - **nodeInfo.machineID** (string), 必需 + + 节点上报的 machineID。 + 对于集群中的唯一机器标识,此字段是首选。 + 从 man(5) machine-id 了解更多信息: http://man7.org/linux/man-pages/man5/machine-id.5.html 。 + + + + - **nodeInfo.operatingSystem** (string), 必需 + + 节点上报的操作系统。 + + + + - **nodeInfo.osImage** (string), 必需 + + 节点从 /etc/os-release 报告的操作系统映像(例如 Debian GNU/Linux 7 (wheezy))。 + + + + - **nodeInfo.systemUUID** (string), 必需 + + 节点报告的 systemUUID。 + 对于唯一的机器标识 MachineID 是首选。 + 此字段特定于 Red Hat 主机 https://access.redhat.com/documentation/en-us/red_hat_subscription_management/1/html/rhsm/uuid 。 + +- **phase** (string) + + + + NodePhase 是最近观测到的节点的生命周期阶段。 + 更多信息: https://kubernetes.io/docs/concepts/nodes/node/#phase 该字段从未填充,现在已被弃用。 + +- **volumesAttached** ([]AttachedVolume) + + + + 附加到节点的卷的列表。 + + + + + **AttachedVolume 描述附加到节点的卷** + + + + - **volumesAttached.devicePath** (string), 必需 + + devicePath 表示卷应该可用的设备路径。 + + + + - **volumesAttached.name** (string), 必需 + + 附加卷的名称。 + +- **volumesInUse** ([]string) + + + + 节点正在使用(安装)的可附加卷的列表。 + +## NodeList {#NodeList} + + + +NodeList 是已注册到 master 的所有节点的完整列表。 + +
+ +- **apiVersion**: v1 + +- **kind**: NodeList + +- **metadata** (}}">ListMeta) + + + + 标准的列表元数据。 + 更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds 。 + + + +- **items** ([]}}">Node), 必需 + + 节点的列表。 + + + +## 操作 {#Operations} + +
+ +### `get` 读取指定节点 + +#### HTTP 请求 + +GET /api/v1/nodes/{name} + +#### 参数 + + + +- **name** (**路径参数**): string, 必需 + + 节点的名称。 + +- **pretty** (**路径参数**): string + + }}">pretty + +#### 响应 + +200 (}}">Node): OK + +401: Unauthorized + + + +### `get` 读取指定节点的状态 + +#### HTTP 请求 + +GET /api/v1/nodes/{name}/status + +#### 参数 + + + +- **name** (**路径参数**): string, 必需 + + 节点的名称。 + +- **pretty** (**查询参数**): string + + }}">pretty + +#### 响应 + +200 (}}">Node): OK + +401: Unauthorized + + + +### `list` 列出或监视节点类型的对象 + +#### HTTP 请求 + +GET /api/v1/nodes + +#### 参数 + + + +- **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 (}}">NodeList): OK + +401: Unauthorized + + + +### `create` 创建一个节点 + +#### HTTP 请求 + +POST /api/v1/nodes + +#### 参数 + + + +- **body**: }}">Node, 必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + +#### 响应 + +200 (}}">Node): OK + +201 (}}">Node): Created + +202 (}}">Node): Accepted + +401: Unauthorized + + + +### `update` 替换指定节点 + +#### HTTP 请求 + +PUT /api/v1/nodes/{name} + +#### 参数 + + + +- **name** (**路径参数**): string, 必需 + + 节点的名称。 + +- **body**: }}">Node, 必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + +#### 响应 + +200 (}}">Node): OK + +201 (}}">Node): Created + +401: Unauthorized + + + +### `update` 替换指定节点的状态 + +#### HTTP 请求 + +PUT /api/v1/nodes/{name}/status + +#### 参数 + + + +- **name** (**路径参数**): string, 必需 + + 节点的名称。 + +- **body**: }}">Node, 必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + +#### 响应 + +200 (}}">Node): OK + +201 (}}">Node): Created + +401: Unauthorized + + + +### `patch` 部分更新指定节点 + +#### HTTP 请求 + +PATCH /api/v1/nodes/{name} + +#### 参数 + + + +- **name** (**路径参数**): string, 必需 + + 节点的名称。 + +- **body**: }}">Patch, 必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **force** (**查询参数**): boolean + + }}">force + +- **pretty** (**查询参数**): string + + }}">pretty + +#### 响应 + +200 (}}">Node): OK + +201 (}}">Node): Created + +401: Unauthorized + + + +### `patch` 部分更新指定节点的状态 + +#### HTTP 请求 + +PATCH /api/v1/nodes/{name}/status + +#### 参数 + + + +- **name** (**路径参数**): string, 必需 + + 节点的名称。 + +- **body**: }}">Patch, 必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **force** (**查询参数**): boolean + + }}">force + +- **pretty** (**查询参数**): string + + }}">pretty + +#### 响应 + +200 (}}">Node): OK + +201 (}}">Node): Created + +401: Unauthorized + + + +### `delete` 删除一个节点 + +#### HTTP 请求 + +DELETE /api/v1/nodes/{name} + +#### 参数 + + + +- **name** (**路径参数**): string, 必需 + + 节点的名称。 + +- **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 /api/v1/nodes + +#### 参数 + +- **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 diff --git a/content/zh-cn/docs/reference/kubernetes-api/common-definitions/node-selector-requirement.md b/content/zh-cn/docs/reference/kubernetes-api/common-definitions/node-selector-requirement.md index 018672655dd8c..964f6fc0e37c9 100644 --- a/content/zh-cn/docs/reference/kubernetes-api/common-definitions/node-selector-requirement.md +++ b/content/zh-cn/docs/reference/kubernetes-api/common-definitions/node-selector-requirement.md @@ -4,12 +4,12 @@ api_metadata: import: "k8s.io/api/core/v1" kind: "NodeSelectorRequirement" content_type: "api_reference" -description: "节点选择器是要求包含键、值和关联键和值的运算符的选择器" +description: 节点选择算符需求是一个选择算符,其中包含值集、主键以及一个将键和值集关联起来的操作符。 title: "NodeSelectorRequirement" weight: 5 -auto_generated: true --- - - - - - `import "k8s.io/api/core/v1"` - - 节点选择器是要求包含键、值和关联键和值的运算符的选择器。 +节点选择算符需求是一个选择算符,其中包含值集、主键以及一个将键和值集关联起来的操作符。
@@ -48,20 +34,19 @@ A node selector requirement is a selector that contains values, a key, and an op - **key** (string), required The label key that the selector applies to. ---> -- **key** (string), 必选 - - 选择器适用的标签键。 - -- **operator** (string), 必选 +- **key** (string),必需 + + 选择算符所适用的标签主键。 - 表示键与一组值的关系的运算符。有效的运算符包括:In、NotIn、Exists、DoesNotExist、Gt 和 Lt。 +- **operator** (string),必需 + 代表主键与值集之间的关系。合法的 operator 值包括 `In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt` 和 `Lt`。 + - **values** ([]string) - 字符串数组。如果运算符为 In 或 NotIn,则数组必须为非空。 - 如果运算符为 Exists 或 DoesNotExist,则数组必须为空。 - 如果运算符为 Gt 或 Lt,则数组必须有一个元素,该元素将被译为整数。 - 该数组在合并计划补丁时将被替换。 - + 一个由字符串值组成的数组。如果 operator 是 `In` 或 `NotIn`,则 values 数组不能为空。 + 如果 operator 为 `Exists` 或 `DoesNotExist`,则 values 数组只能为空。 + 如果 operator 为 `Gt` 或 `Lt`,则 values 数组只能包含一个元素,并且该元素会被解释为整数。 + 在执行策略性合并补丁操作时,此数组会被整体替换。 diff --git a/content/zh-cn/docs/reference/kubernetes-api/extend-resources/custom-resource-definition-v1.md b/content/zh-cn/docs/reference/kubernetes-api/extend-resources/custom-resource-definition-v1.md new file mode 100644 index 0000000000000..f0bba86822a17 --- /dev/null +++ b/content/zh-cn/docs/reference/kubernetes-api/extend-resources/custom-resource-definition-v1.md @@ -0,0 +1,1736 @@ +--- +api_metadata: + apiVersion: "apiextensions.k8s.io/v1" + import: "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1" + kind: "CustomResourceDefinition" +content_type: "api_reference" +description: "CustomResourceDefinition 表示应在 API 服务器上公开的资源。" +title: "CustomResourceDefinition" +weight: 1 +--- + + +`apiVersion: apiextensions.k8s.io/v1` + +`import "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1"` + +## CustomResourceDefinition {#CustomResourceDefinition} + + +CustomResourceDefinition 表示应在 API 服务器上公开的资源。其名称必须采用 `<.spec.name>.<.spec.group>` 格式。 + +
+ +- **apiVersion**: apiextensions.k8s.io/v1 + +- **kind**: CustomResourceDefinition + +- **metadata** (}}">ObjectMeta) + + 标准的对象元数据,更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + +- **spec** (}}">CustomResourceDefinitionSpec), 必需 + + spec 描述了用户希望资源的呈现方式 + +- **status** (}}">CustomResourceDefinitionStatus) + + status 表示 CustomResourceDefinition 的实际状态 + +## CustomResourceDefinitionSpec {#CustomResourceDefinitionSpec} + + +CustomResourceDefinitionSpec 描述了用户希望资源的呈现方式 + +
+ + +- **group** (string),必需 + + group 是自定义资源的 API 组。自定义资源在 `/apis//...` 下提供。 + 必须与 CustomResourceDefinition 的名称匹配(格式为 `.`)。 + + + +- **names** (CustomResourceDefinitionNames),必需 + + names 表示自定义资源的资源和种类名称。 + + + + **CustomResourceDefinitionNames 表示提供此 CustomResourceDefinition 资源的名称** + + - **names.kind** (string),必需 + + kind 是资源的序列化类型。它通常是驼峰命名的单数形式。自定义资源实例将使用此值作为 API 调用中的 `kind` 属性。 + + + + - **names.plural** (string),必需 + + plural 是所提供的资源的复数名称,自定义资源在 `/apis///.../` 下提供。 + 必须与 CustomResourceDefinition 的名称匹配(格式为 `.`)。必须全部小写。 + + - **names.categories** ([]string) + + + + categories 是自定义资源所属的分组资源列表(例如 'all')。 + 它在 API 发现文档中发布,并支持客户端像 `kubectl get all` 这样的调用。 + + - **names.listKind** (string) + + + + listKind 是此资源列表的序列化类型。默认为 "`kind`List"。 + + - **names.shortNames** ([]string) + + + + shortNames 是资源的短名称,在 API 发现文档中公开,并支持客户端调用,如 `kubectl get `。必须全部小写。 + + - **names.singular** (string) + + + + singular 是资源的单数名称。必须全部小写。默认为小写 `kind`。 + + + +- **scope** (string),必需 + + scope 表示自定义资源是群集作用域还是命名空间作用域。允许的值为 `Cluster` 和 `Namespaced`。 + + + +- **versions** ([]CustomResourceDefinitionVersion),必需 + + versions 是自定义资源的所有 API 版本的列表。版本名称用于计算服务版本在 API 发现中列出的顺序。 + 如果版本字符串是与 Kubernetes 的版本号形式类似,则它将排序在非 Kubernetes 形式版本字符串之前。 + Kubernetes 的版本号字符串按字典顺序排列。Kubernetes 版本号以 “v” 字符开头, + 后面是一个数字(主版本),然后是可选字符串 “alpha” 或 “beta” 和另一个数字(次要版本)。 + 它们首先按 GA > beta > alpha 排序(其中 GA 是没有 beta 或 alpha 等后缀的版本),然后比较主要版本, + 最后是比较次要版本。版本排序列表示例:v10、v2、v1、v11beta2、v10beta3、v3beta1、v12alpha1、v11alpha2、foo1、foo10。 + + + + **CustomResourceDefinitionVersion 描述 CRD 的一个版本** + + - **versions.name** (string),必需 + + name 是版本名称,例如 “v1”、“v2beta1” 等。如果 `served` 是 true,自定义资源在 + `/apis///...` 版本下提供。 + + + + - **versions.served** (boolean),必需 + + served 是用于启用/禁用该版本通过 REST API 提供服务的标志 + + + + - **versions.storage** (boolean),必需 + + storage 表示在将自定义资源持久保存到存储时应使用此版本。有且仅有一个版本的 storage=true。 + + - **versions.additionalPrinterColumns** ([]CustomResourceColumnDefinition) + + + + additionalPrinterColumns 表示在表输出中返回的附加列。 + 有关详细信息,请参阅 https://kubernetes.io/zh-cn/docs/reference/using-api/api-concepts/#receiving-resources-as-tables。 + 如果没有指定列,则显示自定义资源存活时间(AGE)列。 + + + + + **CustomResourceColumnDefinition 指定用于服务器端打印的列。** + + - **versions.additionalPrinterColumns.jsonPath** (string),必需 + + jsonPath 是一个简单的 JSON 路径(使用数组表示法),它对每个自定义资源进行评估,以生成该列的值。 + + + + - **versions.additionalPrinterColumns.name** (string),必需 + + name 是便于阅读的列名称 + + + + - **versions.additionalPrinterColumns.type** (string),必需 + + type 是此列的 OpenAPI 类型定义。有关详细信息, + 请参阅 https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types + + - **versions.additionalPrinterColumns.description** (string) + + + + description 是该列的可读性描述 + + - **versions.additionalPrinterColumns.format** (string) + + + + format 是这个列的可选 OpenAPI 类型定义。'name' 格式应用于主标识符列,以帮助客户端识别列是资源名称。 + 有关详细信息,请参阅 https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types。 + + - **versions.additionalPrinterColumns.priority** (int32) + + + + priority 是一个定义此列相对于其他列的相对重要性的整数。数字越低,优先级越高。 + 在空间有限的情况下,可以省略的列的优先级应大于 0。 + + - **versions.deprecated** (boolean) + + + + deprecated 表示此版本的自定义资源 API 已弃用。设置为 true 时,对此版本的 API + 请求会在服务器响应头信息中带有警告(warning)信息。此值默认为 false。 + + - **versions.deprecationWarning** (string) + + + + deprecationWarning 会覆盖返回给 API 客户端的默认警告。只能在 `deprecated` 为 true 时设置。 + 默认警告表示此版本已弃用,建议使用最新的同等或更高稳定性版本(如果存在)。 + + - **versions.schema** (CustomResourceValidation) + + + + schema 描述了用于验证、精简和默认此版本的自定义资源的模式。 + + + + + **CustomResourceValidation 是 CustomResources 的验证方法列表。** + + - **versions.schema.openAPIV3Schema** (}}">JSONSchemaProps) + + + + openAPIV3Schema 是用于验证和精简的 OpenAPI v3 模式。 + + - **versions.subresources** (CustomResourceSubresources) + + + + subresources 指定此版本已定义的自定义资源具有哪些子资源。 + + + + + **CustomResourceSubresources 定义了 CustomResources 子资源的状态和规模。** + + - **versions.subresources.scale** (CustomResourceSubresourceScale) + + + + scale 表示自定义资源应该提供一个 `/scale` 子资源,该子资源返回一个 `autoscaling/v1` Scale 对象。 + + + + + **CustomResourceSubresourceScale 定义了如何为 CustomResources 的 scale 子资源提供服务。** + + - **versions.subresources.scale.specReplicasPath** (string),必需 + + specReplicasPath 定义对应于 Scale 的自定义资源内的 JSON 路径 `spec.replicas`。 + 只允许没有数组表示法的 JSON 路径。必须是 `.spec` 下的 JSON 路径。 + 如果自定义资源中的给定路径下没有值,那么 GET `/scale` 子资源将返回错误。 + + + + - **versions.subresources.scale.statusReplicasPath** (string),必需 + + statusReplicasPath 定义对应于 Scale 的自定义资源内的 JSON 路径 `status.replicas`。 + 只允许不带数组表示法的 JSON 路径。必须是 `.status` 下的 JSON 路径。 + 如果自定义资源中给定路径下没有值,则 `/scale` 子资源中的 `status.replicas` 值将默认为 0。 + + - **versions.subresources.scale.labelSelectorPath** (string) + + + + labelSelectorPath 定义对应于 Scale 的自定义资源内的 JSON 路径 `status.selector`。 + 只允许不带数组表示法的 JSON 路径。必须是 `.status` 或 `.spec` 下的路径。 + 必须设置为与 HorizontalPodAutoscaler 一起使用。 + 此 JSON 路径指向的字段必须是字符串字段(不是复杂的选择器结构),其中包含字符串形式的序列化标签选择器。 + 更多信息: https://kubernetes.io/zh-cn/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions#scale-subresource。 + 如果自定义资源中给定路径下没有值,则 `/scale` 子资源中的 `status.selector` 默认值为空字符串。 + + - **versions.subresources.status** (CustomResourceSubresourceStatus) + + + + status 表示自定义资源应该为 `/status` 子资源服务。当启用时: + + 1. 对自定义资源主端点的请求会忽略对对象的 `status` 节的改变; + 2. 对自定义资源 `/status` 子资源的请求忽略对对象的 `status` 节以外的任何变化。 + + + + + CustomResourceSubresourceStatus 定义了如何为自定义资源提供 status 子资源。 + 状态由 CustomResource 中的 `.status` JSON 路径表示。设置后, + + * 为自定义资源提供一个 `/status` 子资源。 + * 向 `/status` 子资源发出的 PUT 请求时,需要提供自定义资源对象,服务器端会忽略对 status 节以外的任何内容更改。 + * 对自定义资源的 PUT/POST/PATCH 请求会忽略对 status 节的更改。 + +- **conversion** (CustomResourceConversion) + + + conversion 定义了 CRD 的转换设置。 + + + + + **CustomResourceConversion 描述了如何转换不同版本的自定义资源。** + + - **conversion.strategy** (string),必需 + + strategy 指定如何在版本之间转换自定义资源。允许的值为: + + - `None`:转换器仅更改 apiVersion 并且不会触及自定义资源中的任何其他字段。 + - `Webhook`:API 服务器将调用外部 Webhook 进行转换。此选项需要其他信息。这要求 + spec.preserveUnknownFields 为 false,并且设置 spec.conversion.webhook。 + + - **conversion.webhook** (WebhookConversion) + + + + webhook 描述了如何调用转换 Webhook。当 `strategy` 设置为 `Webhook` 时有效。 + + + + + **WebhookConversion 描述了如何调用转换 Webhook** + + - **conversion.webhook.conversionReviewVersions** ([]string),必需 + + conversionReviewVersions 是 Webhook 期望的 `ConversionReview` 版本的有序列表。 + API 服务器将使用它支持的列表中的第一个版本。如果 API 服务器不支持此列表中指定的版本,则自定义资源的转换将失败。 + 如果持久化的 Webhook 配置指定了允许的版本但其中不包括 API 服务器所了解的任何版本,则对 Webhook 的调用将失败。 + + - **conversion.webhook.clientConfig** (WebhookClientConfig) + + + + 如果 strategy 是 `Webhook`, 那么 clientConfig 是关于如何调用 Webhook 的说明。 + + + + + **WebhookClientConfig 包含与 Webhook 建立 TLS 连接的信息。** + + - **conversion.webhook.clientConfig.caBundle** ([]byte) + + + + caBundle 是一个 PEM 编码的 CA 包,用于验证 Webhook 服务器的服务证书。 + 如果未指定,则使用 API 服务器上的系统根证书。 + + - **conversion.webhook.clientConfig.service** (ServiceReference) + + + + service 是对此 Webhook 服务的引用。必须指定 service 或 url 字段之一。 + + 如果在集群中运行 Webhook,那么你应该使用 `service`。 + + + + + **ServiceReference 保存对 Service.legacy.k8s.io 的一个引用。** + + - **conversion.webhook.clientConfig.service.name** (string),必需 + + name 是服务的名称。必需。 + + + + - **conversion.webhook.clientConfig.service.namespace** (string),必需 + + namespace 是服务的命名空间。必需。 + + - **conversion.webhook.clientConfig.service.path** (string) + + + + path 是一个可选的 URL 路径,Webhook 将通过该路径联系服务。 + + - **conversion.webhook.clientConfig.service.port** (int32) + + + + port 是 Webhook 联系的可选服务端口。`port` 应该是一个有效的端口号(1-65535,包含)。 + 为实现向后兼容,默认端口号为 443。 + + - **conversion.webhook.clientConfig.url** (string) + + + + url 以标准 URL 的形式(`scheme://host:port/path`)给出 Webhook 的位置。`url` 或 `service` 必须指定一个且只能指定一个。 + + + + `host` 不应引用集群中运行的服务;若使用集群内服务应改为使用 `service` 字段。 + host 值可能会通过外部 DNS 解析(例如,`kube-apiserver` 无法解析集群内 DNS,因为这将违反分层规则)。 + `host` 也可能是 IP 地址。 + + + + 请注意,使用 `localhost` 或 `127.0.0.1` 作为 `host` 是有风险的, + 除非你非常小心地在所有运行 API 服务器的主机上运行这个 Webhook,因为这些 API 服务器可能需要调用这个 Webhook。 + 这样的安装可能是不可移植的,也就是说,不容易在一个新的集群中复现。 + + + + scheme 必须是 "https";URL 必须以 "https://" 开头。 + + 路径(path)是可选的,如果存在,则可以是 URL 中允许的任何字符串。 + 你可以使用路径传递一个任意字符串给 Webhook,例如,一个集群标识符。 + + 不允许使用用户或基本认证,例如 "user:password@",是不允许的。片段("#...")和查询参数("?...")也是不允许的。 + +- **preserveUnknownFields** (boolean) + + + + preserveUnknownFields 表示将对象写入持久性存储时应保留 OpenAPI 模式中未规定的对象字段。 + apiVersion、kind、元数据(metadata)和元数据中的已知字段始终保留。不推荐使用此字段,而建议在 + `spec.versions[*].schema.openAPIV3Schema` 中设置 `x-preserve-unknown-fields` 为 true。 + 更多详细信息参见: https://kubernetes.io/zh-cn/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#pruning-versus-preserving-unknown-fields + +## JSONSchemaProps {#JSONSchemaProps} + + +JSONSchemaProps 是JSON 模式(JSON-Schema),遵循其规范草案第 4 版 (http://json-schema.org/)。 + +
+ +- **$ref** (string) + +- **$schema** (string) + +- **additionalItems** (JSONSchemaPropsOrBool) + + + + **JSONSchemaPropsOrBool 表示 JSONSchemaProps 或布尔值。布尔属性默认为 true。** + +- **additionalProperties** (JSONSchemaPropsOrBool) + + + + **JSONSchemaPropsOrBool 表示 JSONSchemaProps 或布尔值。布尔属性默认为 true。** + +- **allOf** ([]}}">JSONSchemaProps) + +- **anyOf** ([]}}">JSONSchemaProps) + +- **default** (JSON) + + + default 是未定义对象字段的默认值。设置默认值操作是 CustomResourceDefaulting 特性门控所控制的一个 Beta 特性。 + 应用默认值设置时要求 spec.preserveUnknownFields 为 false。 + + + + **JSON 表示任何有效的 JSON 值。支持以下类型:bool、int64、float64、string、[]interface{}、map[string]interface{} 和 nil。** + +- **definitions** (map[string]}}">JSONSchemaProps) + +- **dependencies** (map[string]JSONSchemaPropsOrStringArray) + + + + **JSONSchemaPropsOrStringArray 表示 JSONSchemaProps 或字符串数组。** + +- **description** (string) + +- **enum** ([]JSON) + + + + **JSON 表示任何有效的 JSON 值。支持以下类型:bool、int64、float64、string、[]interface{}、map[string]interface{} 和 nil。** + +- **example** (JSON) + + + + **JSON 表示任何有效的 JSON 值。支持以下类型:bool、int64、float64、string、[]interface{}、map[string]interface{} 和 nil。** + +- **exclusiveMaximum** (boolean) + +- **exclusiveMinimum** (boolean) + +- **externalDocs** (ExternalDocumentation) + + + + **ExternalDocumentation 允许引用外部资源作为扩展文档。** + + - **externalDocs.description** (string) + + - **externalDocs.url** (string) + +- **format** (string) + + + format 是 OpenAPI v3 格式字符串。未知格式将被忽略。以下格式会被验证合法性: + + - bsonobjectid:一个 bson 对象的 ID,即一个 24 个字符的十六进制字符串 + - uri:由 Go 语言 net/url.ParseRequestURI 解析得到的 URI + - email:由 Go 语言 net/mail.ParseAddress 解析得到的电子邮件地址 + - hostname:互联网主机名的有效表示,由 RFC 1034 第 3.1 节 [RFC1034] 定义 + - ipv4:由 Go 语言 net.ParseIP 解析得到的 IPv4 协议的 IP + - ipv6:由 Go 语言 net.ParseIP 解析得到的 IPv6 协议的 IP + - cidr: 由 Go 语言 net.ParseCIDR 解析得到的 CIDR + - mac:由 Go 语言 net.ParseMAC 解析得到的一个 MAC 地址 + - uuid:UUID,允许大写字母,满足正则表达式 (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{12}$ + - uuid3:UUID3,允许大写字母,满足正则表达式 (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?3[0-9a-f]{3}-?[0-9a-f]{4}-?[0-9a-f]{12}$ + - uuid4:UUID4,允许大写字母,满足正则表达式 (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?4[0-9a-f]{3}-?[89ab][0-9a-f]{3}-?[0-9a-f]{12}$ + - uuid5:UUID5,允许大写字母,满足正则表达式 (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?5[0-9a-f]{3}-?[89ab][0-9a-f]{3}-?[0-9a-f]{12}$ + - isbn:一个 ISBN10 或 ISBN13 数字字符串,如 "0321751043" 或 "978-0321751041" + - isbn10:一个 ISBN10 数字字符串,如 "0321751043" + - isbn13: 一个 ISBN13 号码字符串,如 "978-0321751041" + - creditcard:信用卡号码,满足正则表达式 ^(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})$,其中混合任意非数字字符 + - ssn:美国社会安全号码,满足正则表达式 ^\d{3}[- ]?\d{2}[- ]?\d{4}$ + - hexcolor:一个十六进制的颜色编码,如 "#FFFFFF",满足正则表达式 ^#?([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$ + - rgbcolor:一个 RGB 颜色编码 例如 "rgb(255,255,255)" + - byte:base64 编码的二进制数据 + - password: 任何类型的字符串 + - date:类似 "2006-01-02" 的日期字符串,由 RFC3339 中的完整日期定义 + - duration:由 Go 语言 time.ParseDuration 解析的持续时长字符串,如 "22 ns",或与 Scala 持续时间格式兼容。 + - datetime:一个日期时间字符串,如 "2014-12-15T19:30:20.000Z",由 RFC3339 中的 date-time 定义。 + +- **id** (string) + +- **items** (JSONSchemaPropsOrArray) + + + + **JSONSchemaPropsOrArray 表示可以是 JSONSchemaProps 或 JSONSchemaProps 数组的值。这里目的主要用于序列化。** + +- **maxItems** (int64) + +- **maxLength** (int64) + +- **maxProperties** (int64) + +- **maximum** (double) + +- **minItems** (int64) + +- **minLength** (int64) + +- **minProperties** (int64) + +- **minimum** (double) + +- **multipleOf** (double) + +- **not** (}}">JSONSchemaProps) + +- **nullable** (boolean) + +- **oneOf** ([]}}">JSONSchemaProps) + +- **pattern** (string) + +- **patternProperties** (map[string]}}">JSONSchemaProps) + +- **properties** (map[string]}}">JSONSchemaProps) + +- **required** ([]string) + +- **title** (string) + +- **type** (string) + +- **uniqueItems** (boolean) + +- **x-kubernetes-embedded-resource** (boolean) + + + x-kubernetes-embedded-resource 定义该值是一个嵌入式 Kubernetes runtime.Object,具有 TypeMeta 和 ObjectMeta。 + 类型必须是对象。允许进一步限制嵌入对象。会自动验证 kind、apiVersion 和 metadata 等字段值。 + x-kubernetes-preserve-unknown-fields 允许为 true,但如果对象已完全指定 + (除 kind、apiVersion、metadata 之外),则不必为 true。 + +- **x-kubernetes-int-or-string** (boolean) + + + x-kubernetes-int-or-string 指定此值是整数或字符串。如果为 true,则允许使用空类型, + 并且如果遵循以下模式之一,则允许作为 anyOf 的子类型: + + 1) anyOf: + - type: integer + - type: string + 2) allOf: + - anyOf: + - type: integer + - type: string + + + - (可以有选择地包含其他类型) + +- **x-kubernetes-list-map-keys** ([]string) + + + X-kubernetes-list-map-keys 通过指定用作 map 索引的键来使用 x-kubernetes-list-type `map` 注解数组。 + + 这个标签必须只用于 "x-kubernetes-list-type" 扩展设置为 "map" 的列表。 + 而且,为这个属性指定的值必须是子结构的标量类型的字段(不支持嵌套)。 + + 指定的属性必须是必需的或具有默认值,以确保所有列表项都存在这些属性。 + +- **x-kubernetes-list-type** (string) + + + x-kubernetes-list-type 注解一个数组以进一步描述其拓扑。此扩展名只能用于列表,并且可能有 3 个可能的值: + + + + 1. `atomic`: + 列表被视为单个实体,就像标量一样。原子列表在更新时将被完全替换。这个扩展可以用于任何类型的列表(结构,标量,…)。 + 2. `set`: + set 是不能有多个具有相同值的列表。每个值必须是标量、具有 x-kubernetes-map-type + `atomic` 的对象或具有 x-kubernetes-list-type `atomic` 的数组。 + 3. `map`: + 这些列表类似于映射表,因为它们的元素具有用于标识它们的非索引键。合并时保留顺序。 + map 标记只能用于元数类型为 object 的列表。 + 数组默认为原子数组。 + +- **x-kubernetes-map-type** (string) + + + x-kubernetes-map-type 注解一个对象以进一步描述其拓扑。此扩展只能在 type 为 object 时使用,并且可能有 2 个可能的值: + + + + 1) `granular`: + 这些 map 是真实的映射(键值对),每个字段都是相互独立的(它们都可以由不同的角色来操作)。 + 这是所有 map 的默认行为。 + 2) `atomic`:map 被视为单个实体,就像标量一样。原子 map 更新后将被完全替换。 + +- **x-kubernetes-preserve-unknown-fields** (boolean) + + + + x-kubernetes-preserve-unknown-fields 针对未在验证模式中指定的字段,禁止 API 服务器的解码步骤剪除这些字段。 + 这一设置对字段的影响是递归的,但在模式中指定了嵌套 properties 或 additionalProperties 时,会切换回正常的字段剪除行为。 + 该值可为 true 或 undefined,不能为 false。 + +- **x-kubernetes-validations** ([]ValidationRule) + + + + **补丁策略:基于键 `rule` 合并** + + **Map:合并时将保留 rule 键的唯一值** + + x-kubernetes-validations 描述了用 CEL 表达式语言编写的验证规则列表。此字段是 Alpha 级别。 + 使用此字段需要启用 `CustomResourceValidationExpressions` 特性门控。 + + + + + **ValidationRule 描述用 CEL 表达式语言编写的验证规则。** + + - **x-kubernetes-validations.rule** (string),必需 + + + + rule 表示将由 CEL 评估的表达式。参考: https://github.com/google/cel-spec。 + rule 的作用域为模式中的 x-kubernetes-validation 扩展所在的位置。CEL 表达式中的 `self` 与作用域值绑定。 + 例子:rule 的作用域是一个具有状态子资源的资源根:{"rule": "self.status.actual \<= self.spec.maxDesired"}。 + + + + 如果 rule 的作用域是一个带有属性的对象,那么该对象的可访问属性是通过 `self` 进行字段选择的, + 并且可以通过 `has(self.field)` 来检查字段是否存在。在 CEL 表达式中,Null 字段被视为不存在的字段。 + 如果该 rule 的作用域是一个带有附加属性的对象(例如一个 map),那么该 map 的值可以通过 + `self[mapKey]`来访问,map 是否包含某主键可以通过 `mapKey in self` 来检查。 + map 中的所有条目都可以通过 CEL 宏和函数(如 `self.all(...)`)访问。 + 如果 rule 的作用域是一个数组,数组的元素可以通过 `self[i]` 访问,也可以通过宏和函数访问。 + 如果 rule 的作用域为标量,`self` 绑定到标量值。举例: + + - rule 作用域为对象映射:{"rule": "self.components['Widget'].priority \< 10"} + - rule 作用域为整数列表:{"rule": "self.values.all(value, value >= 0 && value \< 100)"} + - rule 作用域为字符串值:{"rule": "self.startsWith('kube')"} + + + + `apiVersion`, `kind`, `metadata.name` 和 `metadata.generateName` 总是可以从对象的根和任何带 + x-kubernetes-embedded-resource 注解的对象访问。其他元数据属性都无法访问。 + + + + 在 CEL 表达式中无法访问通过 x-kubernetes-preserve-unknown-fields 保存在自定义资源中的未知数据。 + 这包括: + + - 由包含 x-kubernetes-preserve-unknown-fields 的对象模式所保留的未知字段值; + - 属性模式为 "未知类型" 的对象属性。"未知类型" 递归定义为: + + - 没有设置 type 但 x-kubernetes-preserve-unknown-fields 设置为 true 的模式。 + - 条目模式为"未知类型"的数组。 + - additionalProperties 模式为"未知类型"的对象。 + + + + 只有名称符合正则表达式 `[a-zA-Z_.-/][a-zA-Z0-9_.-/]*` 的属性才可被访问。 + 在表达式中访问属性时,可访问的属性名称根据以下规则进行转义: + + - '__' 转义为 '__underscores__' + - '.' 转义为 '__dot__' + - '-' 转义为 '__dash__' + - '/' 转义为 '__slash__' + - 恰好匹配 CEL 保留关键字的属性名称转义为 '__{keyword}__' 。这里的关键字具体包括: + "true","false","null","in","as","break","const","continue","else","for","function","if", + "import","let","loop","package","namespace","return"。 + 举例: + + - 规则访问名为 "namespace" 的属性:`{"rule": "self.__namespace__ > 0"}` + - 规则访问名为 "x-prop" 的属性:`{"rule": "self.x__dash__prop > 0"}` + - 规则访问名为 "redact__d" 的属性:`{"rule": "self.redact__underscores__d > 0"}` + + + + 对 x-kubernetes-list-type 为 'set' 或 'map' 的数组进行比较时忽略元素顺序,如:[1, 2] == [2, 1]。 + 使用 x-kubernetes-list-type 对数组进行串接使用下列类型的语义: + + - 'set':`X + Y` 执行合并,其中 `X` 保留所有元素的数组位置,并附加不相交的元素 `Y`,保留其局部顺序。 + - 'map':`X + Y` 执行合并,保留 `X` 中所有键的数组位置,但当 `X` 和 `Y` 的键集相交时,会被 `Y` 中的值覆盖。 + 添加 `Y` 中具有不相交键的元素,保持其局顺序。 + + - **x-kubernetes-validations.message** (string) + + + + message 表示验证失败时显示的消息。如果规则包含换行符,则需要该消息。消息不能包含换行符。 + 如果未设置,则消息为 "failed rule: {Rule}",如:"must be a URL with the host matching spec.host" + +## CustomResourceDefinitionStatus {#CustomResourceDefinitionStatus} + +CustomResourceDefinitionStatus 表示 CustomResourceDefinition 的状态 + +
+ +- **acceptedNames** (CustomResourceDefinitionNames) + + + + acceptedNames 是实际用于服务发现的名称。它们可能与规约(spec)中的名称不同。 + + + + + **CustomResourceDefinitionNames 表示提供此 CustomResourceDefinition 资源的名称** + + - **acceptedNames.kind** (string),必需 + + kind 是资源的序列化类型。它通常是驼峰命名的单数形式。自定义资源实例将使用此值作为 API 调用中的 `kind` 属性。 + + + + - **acceptedNames.plural** (string), required + + plural 是所提供的资源的复数名称,自定义资源在 `/apis///.../` 下提供。 + 必须与 CustomResourceDefinition 的名称匹配(格式为 `.`)。必须全部小写。 + + - **acceptedNames.categories** ([]string) + + + + categories 是此自定义资源所属的分组资源列表(例如 'all')。 + 它在 API 发现文档中发布,并被客户端用于支持像 `kubectl get all` 这样的调用。 + + - **acceptedNames.listKind** (string) + + + + listKind 是此资源列表的序列化类型。默认为 "`List`"。 + + - **acceptedNames.shortNames** ([]string) + + + + shortNames 是资源的短名称,在 API 发现文档中公开,并支持客户端调用,如 `kubectl get `。必须全部小写。 + + - **acceptedNames.singular** (string) + + + + singular 是资源的单数名称。必须全部小写。默认为小写形式的 `kind`。 + +- **conditions** ([]CustomResourceDefinitionCondition) + + + + **Map:合并时将保留 type 键的唯一值** + + conditions 表示 CustomResourceDefinition 特定方面的状态 + + + + + **CustomResourceDefinitionCondition 包含此 Pod 当前状况的详细信息。** + + - **conditions.status** (string),必需 + + status 表示状况(Condition)的状态,取值为 True、False 或 Unknown 之一。 + + + + - **conditions.type** (string),必需 + + type 是状况的类型。类型包括:Established、NamesAccepted 和 Terminating。 + + - **conditions.lastTransitionTime** (Time) + + + + lastTransitionTime 是上一次发生状况状态转换的时间。 + + + + + **Time 是对 time.Time 的封装。Time 支持对 YAML 和 JSON 进行正确封包。为 time 包的许多函数方法提供了封装器。** + + - **conditions.message** (string) + + + + message 是有关上次转换的详细可读信息。 + + - **conditions.reason** (string) + + + + reason 表述状况上次转换原因的、驼峰格式命名的、唯一的一个词。 + +- **storedVersions** ([]string) + + + + storedVersions 列出了曾经被持久化的所有 CustomResources 版本。跟踪这些版本可以为 etcd 中的存储版本提供迁移路径。 + 该字段是可变的,因此迁移控制器可以完成到另一个版本的迁移(确保存储中没有遗留旧对象),然后从该列表中删除其余版本。 + 当版本在此列表中时,则不能从 `spec.versions` 中删除。 + +## CustomResourceDefinitionList {#CustomResourceDefinitionList} + +CustomResourceDefinitionList 是 CustomResourceDefinition 对象的列表。 + +
+ + + +- **items** ([]}}">CustomResourceDefinition),必需 + + items 列出单个 CustomResourceDefinition 对象 + +- **apiVersion** (string) + + + + apiVersion 定义对象表示的版本化模式。服务器应将已识别的模式转换为最新的内部值,并可能拒绝未识别的值。 + 更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources + +- **kind** (string) + + + + kind 是一个字符串值,表示该对象所表示的 REST 资源。服务器可以从客户端提交请求的端点推断出 REST 资源。不能被更新。驼峰命名。 + 更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds + +- **metadata** (}}">ListMeta) + + + + 标准的对象元数据,更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + +## Operations {#Operations} + +
+ + +### `get` 读取指定的 CustomResourceDefinition + +#### HTTP 请求 + +GET /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name} + + +#### 参数 + +- **name** (**路径参数**):string,必需 + + CustomResourceDefinition 的名称 + +- **pretty** (**查询参数**):string + + }}">pretty + + +#### 响应 + +200 (}}">CustomResourceDefinition): OK + +401: Unauthorized + + +### `get` 读取指定 CustomResourceDefinition 的状态 + +#### HTTP 请求 + +GET /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}/status + + +#### 参数 + +- **name** (**路径参数**):string,必需 + + CustomResourceDefinition 的名称 + +- **pretty** (**查询参数**):string + + }}">pretty + + +#### 响应 + +200 (}}">CustomResourceDefinition): OK + +401: Unauthorized + + +### `list` 列出或观察 CustomResourceDefinition 类型的对象 + +#### HTTP 请求 + +GET /apis/apiextensions.k8s.io/v1/customresourcedefinitions + + +#### 参数 + +- **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 (}}">CustomResourceDefinitionList): OK + +401: Unauthorized + + +### `create` 创建一个 CustomResourceDefinition + +#### HTTP 请求 + +POST /apis/apiextensions.k8s.io/v1/customresourcedefinitions + + +#### 参数 + +- **body**: }}">CustomResourceDefinition,必需 + +- **dryRun** (**查询参数**):string + + }}">dryRun + +- **fieldManager** (**查询参数**):string + + }}">fieldManager + +- **fieldValidation** (**查询参数**):string + + }}">fieldValidation + +- **pretty** (**查询参数**):string + + }}">pretty + + +#### 响应 + +200 (}}">CustomResourceDefinition): OK + +201 (}}">CustomResourceDefinition): Created + +202 (}}">CustomResourceDefinition): Accepted + +401: Unauthorized + + +### `update` 替换指定的 CustomResourceDefinition + +#### HTTP 请求 + +PUT /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name} + + +#### 参数 + +- **name** (**路径参数**):string,必需 + + CustomResourceDefinition 的名称 + +- **body**: }}">CustomResourceDefinition,必需 + +- **dryRun** (**查询参数**):string + + }}">dryRun + +- **fieldManager** (**查询参数**):string + + }}">fieldManager + +- **fieldValidation** (**查询参数**):string + + }}">fieldValidation + +- **pretty** (**查询参数**):string + + }}">pretty + + +#### 响应 + +200 (}}">CustomResourceDefinition): OK + +201 (}}">CustomResourceDefinition): Created + +401: Unauthorized + + +### `update` 替换指定 CustomResourceDefinition 的状态 + +#### HTTP 请求 + +PUT /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}/status + + +#### 参数 + +- **name** (**路径参数**):string,必需 + + CustomResourceDefinition 的名称 + +- **body**: }}">CustomResourceDefinition,必需 + +- **dryRun** (**查询参数**):string + + }}">dryRun + +- **fieldManager** (**查询参数**):string + + }}">fieldManager + +- **fieldValidation** (**查询参数**):string + + }}">fieldValidation + +- **pretty** (**查询参数**):string + + }}">pretty + + +#### 响应 + +200 (}}">CustomResourceDefinition): OK + +201 (}}">CustomResourceDefinition): Created + +401: Unauthorized + + +### `patch` 部分更新指定的 CustomResourceDefinition + +#### HTTP 请求 + +PATCH /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name} + + +#### 参数 + +- **name** (**路径参数**):string,必需 + + CustomResourceDefinition 的名称 + +- **body**: }}">Patch,必需 + +- **dryRun** (**查询参数**):string + + }}">dryRun + +- **fieldManager** (**查询参数**):string + + }}">fieldManager + +- **fieldValidation** (**查询参数**):string + + }}">fieldValidation + +- **force** (**查询参数**):boolean + + }}">force + +- **pretty**(**查询参数**):string + + }}">pretty + + +#### 响应 + +200 (}}">CustomResourceDefinition): OK + +201 (}}">CustomResourceDefinition): Created + +401: Unauthorized + + +### `patch` 部分更新指定 CustomResourceDefinition 的状态 + +#### HTTP 请求 + +PATCH /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}/status + + +#### 参数 + +- **name** (**路径参数**):string,必需 + + CustomResourceDefinition 的名称 + +- **body**: }}">Patch,必需 + +- **dryRun** (**查询参数**):string + + }}">dryRun + +- **fieldManager** (**查询参数**):string + + }}">fieldManager + +- **fieldValidation** (**查询参数**):string + + }}">fieldValidation + +- **force** (**查询参数**):boolean + + }}">force + +- **pretty** (**查询参数**):string + + }}">pretty + + +#### 响应 + +200 (}}">CustomResourceDefinition): OK + +201 (}}">CustomResourceDefinition): Created + +401: Unauthorized + + +### `delete` 删除一个 CustomResourceDefinition + +#### HTTP 请求 + +DELETE /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name} + + +#### 参数 + +- **name** (**路径参数**):string,必需 + + CustomResourceDefinition 的名称 + +- **body**: }}">DeleteOptions + +- **dryRun** (**查询参数**):string + + }}">dryRun + +- **gracePeriodSeconds** (**查询参数**):integer + + }}">gracePeriodSeconds + +- **pretty** (**查询参数**):string + + }}">pretty + +- **propagationPolicy** (**查询参数**):string + + }}">propagationPolicy + + +#### 响应 + +200 (}}">Status): OK + +202 (}}">Status): Accepted + +401: Unauthorized + + +### `deletecollection` 删除 CustomResourceDefinition 的集合 + +#### HTTP 请求 + +DELETE /apis/apiextensions.k8s.io/v1/customresourcedefinitions + + +#### 参数 + +- **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 + diff --git a/content/zh-cn/docs/reference/kubernetes-api/extend-resources/validating-webhook-configuration-v1.md b/content/zh-cn/docs/reference/kubernetes-api/extend-resources/validating-webhook-configuration-v1.md new file mode 100644 index 0000000000000..2349041146065 --- /dev/null +++ b/content/zh-cn/docs/reference/kubernetes-api/extend-resources/validating-webhook-configuration-v1.md @@ -0,0 +1,1102 @@ +--- +api_metadata: + apiVersion: "admissionregistration.k8s.io/v1" + import: "k8s.io/api/admissionregistration/v1" + kind: "ValidatingWebhookConfiguration" +content_type: "api_reference" +description: "ValidatingWebhookConfiguration 描述准入 Webhook 的配置,该 Webhook 可在不更改对象的情况下接受或拒绝对象请求" +title: "ValidatingWebhookConfiguration" +weight: 3 +--- + + + +`apiVersion: admissionregistration.k8s.io/v1` + +`import "k8s.io/api/admissionregistration/v1"` + +## ValidatingWebhookConfiguration {#validatingWebhookConfiguration} + + +ValidatingWebhookConfiguration 描述准入 Webhook 的配置,该 Webhook 可在不更改对象的情况下接受或拒绝对象请求。 + +
+ +- **apiVersion**: admissionregistration.k8s.io/v1 + +- **kind**: ValidatingWebhookConfiguration + + + +- **metadata** (}}">ObjectMeta) + + 标准的对象元数据,更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata。 + + + +- **webhooks** ([]ValidatingWebhook) + + **补丁策略:根据 `name` 键执行合并操作** + + webhooks 是 Webhook 以及受影响的资源和操作的列表。 + + + **ValidatingWebhook 描述了一个准入 Webhook 及其适用的资源和操作。** + + + + - **webhooks.admissionReviewVersions** ([]string), 必需 + + admissionReviewVersions 是 Webhook 期望的首选 `AdmissionReview` 版本的有序列表。 + API 服务器将尝试使用它支持的列表中的第一个版本。如果 API 服务器不支持此列表中指定的版本,则此对象将验证失败。 + 如果持久化的 Webhook 配置指定了允许的版本,并且不包括 API 服务器已知的任何版本,则对 Webhook 的调用将失败并受失败策略的约束。 + + + + - **webhooks.clientConfig** (WebhookClientConfig), 必需 + + clientConfig 定义了如何与 Webhook 通信。必需。 + + + **WebhookClientConfig 包含与 Webhook 建立 TLS 连接的信息** + + + + - **webhooks.clientConfig.caBundle** ([]byte) + + `caBundle` 是一个 PEM 编码的 CA 包,将用于验证 Webhook 的服务证书。如果未指定,则使用 apiserver 上的系统信任根。 + + + + - **webhooks.clientConfig.service** (ServiceReference) + + `service` 是对此 Webhook 服务的引用。必须指定 `service` 或 `url`。 + + 如果 Webhook 在集群中运行,那么你应该使用 `service`。 + + + **ServiceReference 持有对 Service.legacy.k8s.io 的引用** + + + + - **webhooks.clientConfig.service.name** (string), 必需 + + `name` 是服务的名称。必需。 + + + + - **webhooks.clientConfig.service.namespace** (string), 必需 + + `namespace` 是服务的命名空间。必需。 + + + + - **webhooks.clientConfig.service.path** (string) + + `path` 是一个可选的 URL 路径,它将发送任何请求到此服务。 + + + + - **webhooks.clientConfig.service.port** (int32) + + 如果指定,则为托管 Webhook 的服务上的端口。默认为 443 以实现向后兼容性。`port` 应该是一个有效的端口号(包括 1-65535)。 + + + + - **webhooks.clientConfig.url** (string) + + `url` 以标准 URL 形式(`scheme://host:port/path`)给出了 Webhook 的位置。必须指定 `url` 或 `service` 中的一个。 + + `host` 不应指代在集群中运行的服务;请改用 `service` 字段。在某些 apiserver 中,可能会通过外部 DNS 解析 `host`。 + (例如,`kube-apiserver` 无法解析集群内 DNS,因为这会违反分层原理)。`host` 也可以是 IP 地址。 + + 请注意,使用 `localhost` 或 `127.0.0.1` 作为 `host` 是有风险的,除非你非常小心地在运行 apiserver 的所有主机上运行此 Webhook, + 而这些 API 服务器可能需要调用此 Webhook。此类部署可能是不可移植的,即不容易在新集群中重复安装。 + + 该方案必须是 “https”;URL 必须以 “https://” 开头。 + + 路径是可选的,如果存在,可以是 URL 中允许的任何字符串。你可以使用路径将任意字符串传递给 Webhook,例如集群标识符。 + + 不允许使用用户或基本身份验证,例如不允许使用 “user:password@”。 + 不允许使用片段(“#...”)和查询参数(“?...”)。 + + + + - **webhooks.name** (string), 必需 + + 准入 Webhook 的名称。应该是完全限定的名称,例如 imagepolicy.kubernetes.io,其中 “imagepolicy” 是 Webhook 的名称, + kubernetes.io 是组织的名称。必需。 + + + + - **webhooks.sideEffects** (string), 必需 + + sideEffects 说明此 Webhook 是否有副作用。可接受的值为:None、NoneOnDryRun(通过 v1beta1 创建的 Webhook 也可以指定 Some 或 Unknown)。 + 具有副作用的 Webhook 必须实现协调系统,因为请求可能会被准入链中的未来步骤拒绝,因此需要能够撤消副作用。 + 如果请求与带有 sideEffects == Unknown 或 Some 的 Webhook 匹配,则带有 dryRun 属性的请求将被自动拒绝。 + + + + - **webhooks.failurePolicy** (string) + + failurePolicy 定义了如何处理来自准入端点的无法识别的错误 - 允许的值是 Ignore 或 Fail。默认为 Fail。 + + + + - **webhooks.matchPolicy** (string) + + matchPolicy 定义了如何使用 "rules" 列表来匹配传入的请求。允许的值为 "Exact" 或 "Equivalent"。 + + - Exact: 仅当请求与指定规则完全匹配时才匹配请求。 + 例如,如果可以通过 apps/v1、apps/v1beta1 和 extensions/v1beta1 修改 deployments 资源, + 但 “rules” 仅包含 `apiGroups:["apps"]、apiVersions:["v1"]、resources:["deployments "]`, + 对 apps/v1beta1 或 extensions/v1beta1 的请求不会被发送到 Webhook。 + + - Equivalent: 如果针对的资源包含在 “rules” 中,即使是通过另一个 API 组或版本,也视作匹配请求。 + 例如,如果可以通过 apps/v1、apps/v1beta1 和 extensions/v1beta1 修改 deployments 资源, + 并且 “rules” 仅包含 `apiGroups:["apps"]、apiVersions:["v1"]、resources:["deployments "]`, + 对 apps/v1beta1 或 extensions/v1beta1 的请求将被转换为 apps/v1 并发送到 Webhook。 + + 默认为 “Equivalent”。 + + - **webhooks.namespaceSelector** (}}">LabelSelector) + + + namespaceSelector 根据对象的命名空间是否与 selector 匹配来决定是否在该对象上运行 Webhook。 + 如果对象本身是命名空间,则在 object.metadata.labels 上执行匹配。 + 如果对象是另一个集群范围的资源,则永远不会跳过 Webhook 执行匹配。 + + 例如,在命名空间与 “0” 或 “1” 的 “runlevel” 不关联的任何对象上运行 Webhook; + 你可以按如下方式设置 selector : + ``` + "namespaceSelector": { + "matchExpressions": [ + { + "key": "runlevel", + "operator": "NotIn", + "values": [ + "0", + "1" + ] + } + ] + } + ``` + + 相反,如果你只想在命名空间与 “prod” 或 “staging” 的 “environment” 相关联的对象上运行 Webhook; + 你可以按如下方式设置 selector: + ``` + "namespaceSelector": { + "matchExpressions": [ + { + "key": "environment", + "operator": "In", + "values": [ + "prod", + "staging" + ] + } + ] + } + ``` + + 有关标签选择算符的更多示例,请参阅 + https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/labels。 + + 默认为空的 LabelSelector,匹配所有对象。 + + + + - **webhooks.objectSelector** (}}">LabelSelector) + + objectSelector 根据对象是否具有匹配的标签来决定是否运行 Webhook。 + objectSelector 针对将被发送到 Webhook 的 oldObject 和 newObject 进行评估,如果任一对象与选择器匹配,则视为匹配。 + 空对象(create 时为 oldObject,delete 时为 newObject)或不能有标签的对象(如 DeploymentRollback 或 PodProxyOptions 对象) + 认为是不匹配的。 + 仅当 Webhook 支持时才能使用对象选择器,因为最终用户可以通过设置标签来跳过准入 webhook。 + 默认为空的 LabelSelector,匹配所有内容。 + + + + - **webhooks.rules** ([]RuleWithOperations) + + rules 描述了 Webhook 关心的资源/子资源上有哪些操作。Webhook 关心操作是否匹配**任何**rules。 + 但是,为了防止 ValidatingAdmissionWebhooks 和 MutatingAdmissionWebhooks 将集群置于只能完全禁用插件才能恢复的状态, + ValidatingAdmissionWebhooks 和 MutatingAdmissionWebhooks 永远不会在处理 ValidatingWebhookConfiguration + 和 MutatingWebhookConfiguration 对象的准入请求被调用。 + + + **RuleWithOperations 是操作和资源的元组。建议确保所有元组组合都是有效的。** + + + + - **webhooks.rules.apiGroups** ([]string) + + apiGroups 是资源所属的 API 组列表。'*' 是所有组。 + 如果存在 '*',则列表的长度必须为 1。必需。 + + + + - **webhooks.rules.apiVersions** ([]string) + + apiVersions 是资源所属的 API 版本列表。'*' 是所有版本。 + 如果存在 '*',则列表的长度必须为 1。必需。 + + + + - **webhooks.rules.operations** ([]string) + + operations 是准入 Webhook 所关心的操作 —— CREATE、UPDATE、DELETE、CONNECT + 或用来指代所有已知操作以及将来可能添加的准入操作的 `*`。 + 如果存在 '*',则列表的长度必须为 1。必需。 + + + + - **webhooks.rules.resources** ([]string) + + resources 是此规则适用的资源列表。 + + 'pods' 表示 pods,'pods/log' 表示 pods 的日志子资源。'*' 表示所有资源,但不是子资源。 + 'pods/*' 表示 pods 的所有子资源, + '*/scale' 表示所有 scale 子资源, + '*/*' 表示所有资源及其子资源。 + + 如果存在通配符,则验证规则将确保资源不会相互重叠。 + + 根据所指定的对象,可能不允许使用子资源。必需。 + + + + - **webhooks.rules.scope** (string) + + scope 指定此规则的范围。有效值为 "Cluster", "Namespaced" 和 "*"。 + "Cluster" 表示只有集群范围的资源才会匹配此规则。 + Namespace API 对象是集群范围的。 + "Namespaced" 意味着只有命名空间作用域的资源会匹配此规则。 + "*" 表示没有范围限制。 + 子资源与其父资源的作用域相同。默认为 "*"。 + + + + - **webhooks.timeoutSeconds** (int32) + + timeoutSeconds 指定此 Webhook 的超时时间。超时后,Webhook 的调用将被忽略或 API 调用将根据失败策略失败。 + 超时值必须在 1 到 30 秒之间。默认为 10 秒。 + +## ValidatingWebhookConfigurationList {#ValidatingWebhookConfigurationList} + + +ValidatingWebhookConfigurationList 是 ValidatingWebhookConfiguration 的列表。 + +
+ +- **apiVersion**: admissionregistration.k8s.io/v1 + +- **kind**: ValidatingWebhookConfigurationList + + + +- **metadata** (}}">ListMeta) + + 标准的对象元数据,更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds。 + + + +- **items** ([]}}">ValidatingWebhookConfiguration), 必需 + + ValidatingWebhookConfiguration 列表。 + + +## 操作 {#operations} + +
+ + +### `get` 读取指定的 ValidatingWebhookConfiguration + +#### HTTP 请求 + +GET /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations/{name} + + +#### 参数 + +- **name** (**路径参数**): string, 必需 + + ValidatingWebhookConfiguration 的名称。 + + + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">ValidatingWebhookConfiguration): OK + +401: Unauthorized + + +### `list` 列出或观察 ValidatingWebhookConfiguration 类型的对象 + +#### HTTP 请求 + +GET /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations + + +#### 参数 + +- **allowWatchBookmarks** (**查询参数**): boolean + + }}">allowWatchBookmarks + + + +- **continue** (**查询参数**): string + + }}">continue + + + +- **fieldSelector** (**查询参数**): string + + }}">fieldSelector + + + +- **fieldSelector** (**查询参数**): string + + }}">fieldSelector + + + +- **limit** (**查询参数**): integer + + }}">limit + + + +- **pretty** (**查询参数**): string + + }}">pretty + + + +- **resourceVersion** (**查询参数**): string + + }}">resourceVersion + + + +- **resourceVersionMatch** (**查询参数**): string + + }}">resourceVersionMatch + + + +- **timeoutSeconds** (**查询参数**): integer + + }}">timeoutSeconds + + + +- **watch** (**查询参数**): boolean + + }}">watch + + +#### 响应 + + +200 (}}">ValidatingWebhookConfigurationList): OK + +401: Unauthorized + + +### `create` 创建一个 ValidatingWebhookConfiguration + +#### HTTP 请求 + +POST /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations + + +#### 参数 + +- **body**: }}">ValidatingWebhookConfiguration, 必需 + + + +- **dryRun** (**查询参数**): string + + }}">dryRun + + + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + + + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + + + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">ValidatingWebhookConfiguration): OK + +201 (}}">ValidatingWebhookConfiguration): Created + +202 (}}">ValidatingWebhookConfiguration): Accepted + +401: Unauthorized + + +### `update` 替换指定的 ValidatingWebhookConfiguration + +#### HTTP 请求 + +PUT /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations/{name} + + +#### 参数 + +- **name** (**路径参数**): string, 必需 + + ValidatingWebhookConfiguration 的名称。 + + + +- **body**: }}">ValidatingWebhookConfiguration, 必需 + + + +- **dryRun** (**查询参数**): string + + }}">dryRun + + + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + + + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + + + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">ValidatingWebhookConfiguration): OK + +201 (}}">ValidatingWebhookConfiguration): Created + +401: Unauthorized + + +### `patch` 部分更新指定的 ValidatingWebhookConfiguration + +#### HTTP 请求 + +PATCH /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations/{name} + + +#### 参数 + +- **name** (**路径参数**): string, 必需 + + ValidatingWebhookConfiguration 的名称。 + + + +- **body**: }}">Patch, 必需 + + + +- **dryRun** (**查询参数**): string + + }}">dryRun + + + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + + + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + + + +- **force** (**查询参数**): boolean + + }}">force + + + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">ValidatingWebhookConfiguration): OK + +201 (}}">ValidatingWebhookConfiguration): Created + +401: Unauthorized + + +### `delete` 删除 ValidatingWebhookConfiguration + +#### HTTP 请求 + +DELETE /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations/{name} + + +#### 参数 + +- **name** (**路径参数**): string, 必需 + + ValidatingWebhookConfiguration 的名称。 + +- **body**: }}">DeleteOptions + + + +- **dryRun** (**查询参数**): string + + }}">dryRun + + + +- **gracePeriodSeconds** (**查询参数**): integer + + }}">gracePeriodSeconds + + + +- **pretty** (**查询参数**): string + + }}">pretty + + + +- **propagationPolicy** (**查询参数**): string + + }}">propagationPolicy + + +#### 响应 + +200 (}}">Status): OK + +202 (}}">Status): Accepted + +401: Unauthorized + + +### `deletecollection` 删除 ValidatingWebhookConfiguration 的集合 + +#### HTTP 请求 + +DELETE /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations + + +#### 参数 + +- **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 \ No newline at end of file diff --git a/content/zh-cn/docs/reference/kubernetes-api/policy-resources/network-policy-v1.md b/content/zh-cn/docs/reference/kubernetes-api/policy-resources/network-policy-v1.md new file mode 100644 index 0000000000000..aeb49ad674297 --- /dev/null +++ b/content/zh-cn/docs/reference/kubernetes-api/policy-resources/network-policy-v1.md @@ -0,0 +1,1551 @@ +--- +api_metadata: + apiVersion: "networking.k8s.io/v1" + import: "k8s.io/api/networking/v1" + kind: "NetworkPolicy" +content_type: "api_reference" +description: "NetworkPolicy 描述针对一组 Pod 所允许的网络流量。" +title: "NetworkPolicy" +weight: 3 +--- + + +`apiVersion: networking.k8s.io/v1` + +`import "k8s.io/api/networking/v1"` + + +## NetworkPolicy {#NetworkPolicy} + + +NetworkPolicy 描述针对一组 Pod 所允许的网络流量。 + +
+ +- **apiVersion**: networking.k8s.io/v1 + +- **kind**: NetworkPolicy + +- **metadata** (}}">ObjectMeta) + + 标准的对象元数据。更多信息: + https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + +- **spec** (}}">NetworkPolicySpec) + + spec 定义特定网络策略所需的所有信息. + +- **status** (}}">NetworkPolicyStatus) + + status 是 NetworkPolicy 的当前状态。更多信息: + https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status + +## NetworkPolicySpec {#NetworkPolicySpec} + + +NetworkPolicySpec 定义特定 NetworkPolicy 所需的所有信息. + +
+ + +- **podSelector** (}}">LabelSelector), 必需 + + podSelector 选择此网络策略所适用的一组 Pod。一组 Ingress 入口策略将应用于此字段选择的所有 Pod。 + 多个网络策略可以选择同一组 Pod。 + 在这种情况下,这些列表条目的 Ingress 规则效果会被叠加。 此字段不是可选的,并且遵循标准标签选择算符语义。 + 空值的 podSelector 匹配此命名空间中的所有 Pod。 + + +- **policyTypes** ([]string) + + NetworkPolicy 相关的规则类型列表。 有效选项为 `[“Ingress”]`,`[“Egress”]` 或 `[“Ingress”, “Egress”]`。 + 如果不指定此字段,则默认值取决是否存在 Ingress 或 Egress 规则;规则里包含 Egress 部分的策略将会影响出站流量, + 并且所有策略(无论它们是否包含 Ingress 部分)都将会影响 入站流量。 + 如果要仅定义出站流量策略,则必须明确指定 `[ "Egress" ]`。 + 同样,如果要定义一个指定拒绝所有出站流量的策略,则必须指定一个包含 “Egress” 的 policyTypes 值 + (因为这样不包含 Egress 部分的策略,将会被默认为只有 [ "Ingress" ] )。 此字段在 1.8 中为 Beta。 + + +- **ingress** ([]NetworkPolicyIngressRule) + + 定义所选 Pod 的入站规则列表。在没有被任何 NetworkPolicy 选择到 Pod 的情况下(同时假定集群策略允许对应流量), + 或者如果流量源是 Pod 的本地节点,或者流量与所有 NetworkPolicy 中的至少一个入站规则(Ingress) 匹配, + 则进入 Pod 的流量是被允许的。如果此字段为空,则此 NetworkPolicy 不允许任何入站流量 + (这种设置用来确保它所选择的 Pod 在默认情况下是被隔离的)。 + + + **NetworkPolicyIngressRule 定义 NetworkPolicySpec 的 podSelector 所选 Pod 的入站规则的白名单列表, + 流量必须同时匹配 ports 和 from 。** + + + + - **ingress.from** ([]NetworkPolicyPeer) + + 流量来源列表,列表中的来源可以访问被此规则选中的 Pod。此列表中的流量来源使用逻辑或操作进行组合。 + 如果此字段为空值或缺失(未设置), + 则此规则匹配所有流量来源(也即允许所有入站流量)。如果此字段存在并且至少包含一项来源,则仅当流量与来自列表中的至少一项匹配时, + 此规则才允许流量访问被选中的 Pod 集合。 + + + **NetworkPolicyPeer 描述了允许进出流量的对等点。 这个参数只允许某些字段组合** + + + + - **ingress.from.ipBlock** (IPBlock) + + IPBlock 针对特定的 IP CIDR 范围设置策略。如果设置了此字段,则不可以设置其他字段。 + + + IPBlock 定义一个特定的 CIDR 范围(例如 `192.168.1.1/24`、`2001:db9::/64`), + 来自这个 IP 范围的流量来源将会被允许访问与 NetworkPolicySpec 的 podSelector 匹配的 Pod 集合。 + except 字段则设置应排除在此规则之外的 CIDR 范围。 + + + + - **ingress.from.ipBlock.cidr** (string), 必需 + + CIDR 是指定 IP 组块的字符串, 例如 `"192.168.1.1/24"` 或 `"2001:db9::/64"`。 + + - **ingress.from.ipBlock.except** ([]string) + + except 是一个由 CIDR 范围组成的列表,其中指定的 CIDR 都应排除在此 IP 区块范围之外。 + 例如 `"192.168.1.1/24"` 或 `"2001:db9::/64"`。 + 如果 except 字段的值超出 ipBlock.cidr 的范围则被视为无效策略。 + + + + - **ingress.from.namespaceSelector** (}}">LabelSelector) + + 此选择器使用集群范围标签来选择特定的 Namespace。此字段遵循标准标签选择算符语义; + 如果此字段存在但为空值,则会选择所有名字空间。 + + 如果 podSelector 也被定义了, 那么 NetworkPolicyPeer 将选择那些同时满足 namespaceSelector 所选名字空间下 + 和 podSelector 规则匹配的 Pod。 + 反之选择 namespaceSelector 所选名字空间下所有的 Pod。 + + + + - **ingress.from.podSelector** (}}">LabelSelector) + + 这个标签选择算符负责选择 Pod。该字段遵循标准标签选择算符语义;如果字段存在但为空值,则选择所有 Pod。 + + 如果 namespaceSelector 也被定义,那么 NetworkPolicyPeer 将选择那些同时满足 namespaceSelector 定义的名字空间下 + 和 podSelector 规则匹配的 Pod。 + 反之会在策略所在的名字空间中选择与 podSelector 匹配的 Pod。 + + + + - **ingress.ports** ([]NetworkPolicyPort) + + 定义在此规则选中的 Pod 上应可访问的端口列表。此列表中的个项目使用逻辑或操作组合。如果此字段为空或缺失, + 则此规则匹配所有端口(进入流量可访问任何端口)。 + 如果此字段存在并且包含至少一个有效值,则此规则仅在流量至少匹配列表中的一个端口时才允许访问。 + + + **NetworkPolicyPort 定义可以连接的端口** + + + + - **ingress.ports.port** (IntOrString) + + 给定协议上的端口。字段值可以是 Pod 上的数字或命名端口。如果未提供此字段,则匹配所有端口名和端口号。 + 如果定义了,则仅允许对给定的协议和端口的入口流量。 + + + IntOrString 是一种可以包含 int32 或字符串值的类型。在 JSON 或 YAML 编组和解组中使用时,它会生成或使用内部类型。 + 例如,这允许你拥有一个可以接受名称或数字的 JSON 字段。 + + + + - **ingress.ports.endPort** (int32) + + 如果设置了此字段,则表明策略应该允许 port 与 endPort 之间(包含二者)的所有端口。 + 如果未定义 port 或将 port 字段值为命名端口(字符串),则不可以使用 endPort 。 + endPort 必须等于或大于 port 值。此功能是 Beta 阶段,默认启用。可以使用 “NetworkPolicyEndPort” 特性门控来禁用 endPort 。 + + - **ingress.ports.protocol** (string) + + 流量必须匹配的网络协议(TCP、UDP 或 SCTP)。如果未指定,此字段默认为 TCP。 + + + +- **egress** ([]NetworkPolicyEgressRule) + + egress 定义所选 Pod 的出站规则的列表。如果没有 NetworkPolicy 选中指定 Pod(并且其他集群策略也允许出口流量), + 或者在所有通过 podSelector 选中了某 Pod 的 NetworkPolicy 中,至少有一条出站规则与出站流量匹配, + 则该 Pod 的出站流量是被允许的。 + 如果此字段为空,则此 NetworkPolicy 拒绝所有出站流量(这策略可以确保它所选中的 Pod 在默认情况下是被隔离的)。 + egress 字段在 1.8 中为 Beta 级别。 + + + NetworkPolicyEgressRule 针对被 NetworkPolicySpec 的 podSelector 所选中 Pod,描述其被允许的出站流量。 + 流量必须同时匹配 ports 和 to 设置。此类型在 1.8 中为 Beta 级别。 + + + + - **egress.to** ([]NetworkPolicyPeer) + + 针对此规则所选择的 Pod 的出口流量的目的地列表。此列表中的目的地使用逻辑或操作进行组合。 如果此字段为空或缺失, + 则此规则匹配所有目的地(流量不受目的地限制)。 如果此字段存在且至少包含一项目的地,则仅当流量与目标列表中的至少一个匹配时, + 此规则才允许出口流量。 + + + **NetworkPolicyPeer 描述允许进出流量的对等点。这个对象只允许某些字段组合。** + + + + - **egress.to.ipBlock** (IPBlock) + + ipBlock 针对特定的 IP 区块定义策略。如果设置了此字段,则其他不可以设置其他字段。 + + + IPBlock 描述一个特定的 CIDR 范围(例如 `192.168.1.1/24`、`2001:db9::/64`), + 与 NetworkPolicySpec 的 podSelector 匹配的 Pod 将被允许连接到这个 IP 范围,作为其出口流量目的地。 + except 字段则设置了不被此规则影响的 CIDR 范围。 + + + + - **egress.to.ipBlock.cidr** (string), 必需 + + CIDR 是用来表达 IP 组块的字符串,例如 `"192.168.1.1/24"` 或 `"2001:db9::/64"`。 + + - **egress.to.ipBlock.except** ([]string) + + except 定义不应包含在 ipBlock 内的 CIDR 范围列表。例如 `"192.168.1.1/24"` 或 `"2001:db9::/64"`。 + 如果 except 的值超出 ipBlock.cidr 的范围则被拒绝。 + + + + - **egress.to.namespaceSelector** (}}">LabelSelector) + + 此选择算符使用集群范围标签来选择特定的名字空间。该字段遵循标准标签选择算符语义;如果字段存在但为空值,那会选择所有名字空间。 + + 如果 egress.to.podSelector 也被定义了, 那么 NetworkPolicyPeer 将选择那些同时满足 namespaceSelector 指定的名字空间下 + 和 podSelector 规则匹配的 Pod。 + 反之选择 namespaceSelector 指定的名字空间下所有的 Pod。 + + + + - **egress.to.podSelector** (}}">LabelSelector) + + 这个标签选择器负责选择一组 Pod。该字段遵循标准标签选择算符语义; 如果字段存在但为空值,则选择所有 Pod。 + + 如果 egress.to.namespaceSelector 也被定义,则 NetworkPolicyPeer 将选择 namespaceSelector 所指定的名字空间下 + 和 podSelector 规则匹配的 Pod。 + 反之会在策略所属的名字空间中选择与 podSelector 匹配的 Pod。 + + + + - **egress.ports** ([]NetworkPolicyPort) + + 出站流量目的地的端口列表。此列表中的各个项目使用逻辑或操作进行组合。如果此字段为空或缺失, + 则此规则匹配所有端口(可访问出口流量目的地的任何端口)。 如果此字段存在并且包含至少一个有效值, + 则此规则仅在流量与列表中的至少一个端口匹配时才允许访问。 + + + **NetworkPolicyPort 定义出口流量目的地的端口** + + + + - **egress.ports.port** (IntOrString) + + 给定协议上的端口。字段值可以是 Pod 上的数字或命名端口。如果未提供此字段,则匹配所有端口名和端口号。 + 如果定义此字段,则仅允许针对给定的协议和端口的出站流量。 + + + IntOrString 是一种可以包含 int32 或字符串值的类型。在 JSON 或 YAML 编组和解组中使用时,它会生成或使用内部类型。 + 例如,这允许你拥有一个可以接受名称或数字的 JSON 字段。 + + - **egress.ports.endPort** (int32) + + 如果设置了 endPort,则用来指定策略所允许的从 port 到 endPort 的端口范围(包含边界值)。 + 如果未设置 port 或 port 字段值为端口名称(字符串),则不可以指定 endPort。 + endPort 必须等于或大于 port 值。此功能是 Beta 阶段,默认被启用。可以使用 “NetworkPolicyEndPort” 特性门控来禁用 endPort 。 + + - **egress.ports.protocol** (string) + + 流量必须匹配的网络协议(TCP、UDP 或 SCTP)。如果未指定,此字段默认为 TCP。 + +## NetworkPolicyStatus {#NetworkPolicyStatus} + + + +NetworkPolicyStatus 描述有关此 NetworkPolicy 的当前状态。 + +
+ + + +- **conditions** ([]Condition) + + **补丁策略:根据 `type` 键执行合并操作** + + **Map:键 type 的唯一值将在合并期间被保留** + + conditions 包含描述此 NetworkPolicy 状态的 metav1.Condition 数组,即当前服务状态。 + + + **Condition 包含此 API 资源当前状态的一个方面的详细信息。** + + + + - **conditions.lastTransitionTime** (Time), 必需 + + lastTransitionTime 是状况最近一次从一种状态转换到另一种状态的时间。 + 这种变化通常出现在下层状况发生变化的时候。如果无法了解下层状况变化,使用 API 字段更改的时间也是可以接受的。 + + + Time 是 time.Time 的包装器,它支持对 YAML 和 JSON 的正确编组。 + time 包的许多工厂方法提供了包装器。 + + + + - **conditions.message** (string), 必需 + + message 是一条人类可读的消息,指示有关转换的详细信息。它可能是一个空字符串。 + + + + - **conditions.reason** (string), 必需 + + reason 包含一个程序标识符,指示状况最后一次转换的原因。 + 特定状况类型的生产者可以定义该字段的预期值和含义,以及这些值是否可被视为有保证的 API。 + 该值应该是 CamelCase 字符串。此字段不能为空。 + + + + - **conditions.status** (string), 必需 + + 状况的状态为 True、False、Unknown 之一。 + + + + - **conditions.type** (string), 必需 + + CamelCase 或 foo.example.com/CamelCase 形式的状况类型。 + + + + - **conditions.observedGeneration** (int64) + + observedGeneration 表示设置状况时所基于的 `.metadata.generation`。 + 例如,如果 `.metadata.generation` 当前为 12,但 `.status.conditions[x].observedGeneration` 为 9, + 则状况相对于实例的当前状态已过期。 + + +## NetworkPolicyList {#NetworkPolicyList} + + + +NetworkPolicyList 是 NetworkPolicy 的集合。 + +
+ +- **apiVersion**: networking.k8s.io/v1 + + +- **kind**: NetworkPolicyList + + + + +- **metadata** (}}">ListMeta) + + 标准的对象元数据。 + 更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata。 + + + +- **items** ([]}}">NetworkPolicy), 必需 + + items 是 NetworkPolicy 的列表。 + + +## 操作 {#Operations} + +
+ + + +### `get` 读取指定的 NetworkPolicy + +#### HTTP 请求 + +GET /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name} + + +#### 参数 + + +- **name** (**路径参数**): string, 必需 + + NetworkPolicy 的名称。 + + +- **namespace** (**路径参数**): string, 必需 + + }}">namespace + + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">NetworkPolicy): OK + +401: Unauthorized + + + +### `get` 读取指定的 NetworkPolicy 的状态 + +GET /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name}/status + + +#### 参数 + + +- **name** (**路径参数**): string, 必需 + + NetworkPolicy 的名称。 + + +- **namespace** (**路径参数**): string, 必需 + + }}">namespace + + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">NetworkPolicy): OK + +401: Unauthorized + + + +### `list` 列出或监视 NetworkPolicy 类型的对象 + +#### HTTP 请求 + +GET /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies + + +#### 参数 + + +- **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 (}}">NetworkPolicyList): OK + +401: Unauthorized + + + +### `list` 列出或监视 NetworkPolicy 类 + +#### HTTP Request + +GET /apis/networking.k8s.io/v1/networkpolicies + + +#### 参数 + + +- **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 (}}">NetworkPolicyList): OK + +401: Unauthorized + + + +### `create` 创建 NetworkPolicy + +#### HTTP 请求 + +POST /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies + + +#### 参数 + + +- **namespace** (**路径参数**): string, 必需 + +- **body**: }}">NetworkPolicy, 必需 + + + +- **dryRun** (**查询参数**): string + + }}">dryRun + + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">NetworkPolicy): OK + +201 (}}">NetworkPolicy): Created + +202 (}}">NetworkPolicy): Accepted + +401: Unauthorized + + + +### `update` 替换指定的 NetworkPolicy + +#### HTTP 请求 + +PUT /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name} + + +#### 参数 + + +- **name** (**路径参数**): string, 必需 + + NetworkPolicy 的名称。 + + +- **namespace** (**路径参数**): string, 必需 + + }}">namespace + + +- **body**: }}">NetworkPolicy, 必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">NetworkPolicy): OK + +201 (}}">NetworkPolicy): Created + +401: Unauthorized + + +### `update` 替换指定的 NetworkPolicy 的状态 + +#### HTTP 请求 + +PUT /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name}/status + + +#### 参数 + + +- **name** (**路径参数**): string, 必需 + + NetworkPolicy 的名称。 + + +- **namespace** (**路径参数**): string, 必需 + + }}">namespace + + +- **body**: }}">NetworkPolicy, 必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">NetworkPolicy): OK + +201 (}}">NetworkPolicy): Created + +401: Unauthorized + + +### `patch` 部分更新指定的 NetworkPolicy + +#### HTTP 请求 + +PATCH /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name} + + +#### 参数 + + +- **name** (**路径参数**): string, 必需 + + NetworkPolicy 的名称。 + + +- **namespace** (**路径参数**): string, 必需 + + }}">namespace + + +- **body**: }}">Patch, 必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **force** (*in query*): boolean + + }}">force + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">NetworkPolicy): OK + +201 (}}">NetworkPolicy): Created + +401: Unauthorized + + +### `patch` 部分更新指定的 NetworkPolicy 的状态 + +#### HTTP 请求 + +PATCH /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name}/status + + +#### 参数 + + +- **name** (**路径参数**): string, 必需 + + NetworkPolicy 的名称。 + + +- **namespace** (**路径参数**): string, 必需 + + }}">namespace + + +- **body**: }}">Patch, 必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **force** (*in query*): boolean + + }}">force + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">NetworkPolicy): OK + +201 (}}">NetworkPolicy): Created + +401: Unauthorized + + +### `delete` 删除 NetworkPolicy + +#### HTTP 请求 + +DELETE /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name} + + +#### 参数 + + +- **name** (**路径参数**): string, 必需 + + name of the NetworkPolicy + + +- **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` 删除 NetworkPolicy 的集合 + +#### HTTP 请求 + +DELETE /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies + + +#### 参数 + + +- **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 + diff --git a/content/zh-cn/docs/reference/kubernetes-api/policy-resources/pod-disruption-budget-v1.md b/content/zh-cn/docs/reference/kubernetes-api/policy-resources/pod-disruption-budget-v1.md new file mode 100644 index 0000000000000..9590a2f6497eb --- /dev/null +++ b/content/zh-cn/docs/reference/kubernetes-api/policy-resources/pod-disruption-budget-v1.md @@ -0,0 +1,1347 @@ +--- +api_metadata: + apiVersion: "policy/v1" + import: "k8s.io/api/policy/v1" + kind: "PodDisruptionBudget" +content_type: "api_reference" +description: "PodDisruptionBudget 是一个对象,用于定义可能对一组 Pod 造成的最大干扰。" +title: "PodDisruptionBudget" +weight: 4 +--- + + + +`apiVersion: policy/v1` + +`import "k8s.io/api/policy/v1"` + +## PodDisruptionBudget {#PodDisruptionBudget} + + +PodDisruptionBudget 是一个对象,用于定义可能对一组 Pod 造成的最大干扰。 + +
+ +- **apiVersion**: policy/v1 + +- **kind**: PodDisruptionBudget + + +- **metadata** (}}">ObjectMeta) + + 标准的对象元数据。 + 更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata。 + + +- **spec** (}}">PodDisruptionBudgetSpec) + + PodDisruptionBudget 预期行为的规约。 + + + +- **status** (}}">PodDisruptionBudgetStatus) + + 此 PodDisruptionBudget 的最近观测状态。 + +## PodDisruptionBudgetSpec {#PodDisruptionBudgetSpec} + + +PodDisruptionBudgetSpec 是对 PodDisruptionBudget 的描述。 + +
+ + + +- **maxUnavailable** (IntOrString) + + 如果 “selector” 所选中的 Pod 中最多有 “maxUnavailable” Pod 在驱逐后不可用(即去掉被驱逐的 Pod 之后),则允许驱逐。 + 例如,可以通过将此字段设置为 0 来阻止所有自愿驱逐。此字段是与 “minAvailable” 互斥的设置。 + + + IntOrString 是一种可以包含 int32 或字符串数值的类型。在 JSON 或 YAML 编组和解组时, + 会生成或使用内部类型。例如,此类型允许你定义一个可以接受名称或数字的 JSON 字段。 + + + +- **minAvailable** (IntOrString) + + 如果 “selector” 所选中的 Pod 中,至少 “minAvailable” 个 Pod 在驱逐后仍然可用(即去掉被驱逐的 Pod 之后),则允许驱逐。 + 因此,你可以通过将此字段设置为 “100%” 来禁止所有自愿驱逐。 + + + IntOrString 是一种可以包含 int32 或字符串数值的类型。在 JSON 或 YAML 编组和解组时, + 会生成或使用内部类型。例如,此类型允许你定义一个可以接受名称或数字的 JSON 字段。 + + + +- **selector** (}}">LabelSelector) + + 标签查询,用来选择其驱逐由干扰预算来管理的 Pod 集合。 + 选择算符为 null 时将不会匹配任何 Pod,而空 ({}) 选择算符将选中名字空间内的所有 Pod。 + +## PodDisruptionBudgetStatus {#PodDisruptionBudgetStatus} + + +PodDisruptionBudgetStatus 表示有关此 PodDisruptionBudget 状态的信息。状态可能会反映系统的实际状态。 + +
+ + + +- **currentHealthy** (int32), 必需 + + 当前健康 Pod 的数量。 + + + +- **desiredHealthy** (int32), 必需 + + 健康 Pod 的最小期望值。 + + + +- **disruptionsAllowed** (int32), 必需 + + 当前允许的 Pod 干扰计数。 + +- **conditions** ([]Condition) + + + + **补丁策略:根据 `type` 键执行合并操作** + + **Map:键 type 的唯一值将在合并期间被保留** + + conditions 包含 PDB 的状况。干扰控制器会设置 DisruptionAllowed 状况。 + 以下是 reason 字段的已知值(将来可能会添加其他原因): + + - SyncFailed:控制器遇到错误并且无法计算允许的干扰计数。因此不允许任何干扰,且状况的状态将变为 False。 + - InsufficientPods:Pod 的数量只能小于或等于 PodDisruptionBudget 要求的数量。 + 不允许任何干扰,且状况的状态将是 False。 + - SufficientPods:Pod 个数超出 PodDisruptionBudget 所要求的阈值。 + 此状况为 True 时,基于 disruptsAllowed 属性确定所允许的干扰数目。 + + + + + Condition 包含此 API 资源当前状态的一个方面的详细信息。 + + + + - **conditions.lastTransitionTime** (Time), 必需 + + lastTransitionTime 是状况最近一次从一种状态转换到另一种状态的时间。 + 这种变化通常出现在下层状况发生变化的时候。如果无法了解下层状况变化,使用 API 字段更改的时间也是可以接受的。 + + + Time 是 time.Time 的包装器,它支持对 YAML 和 JSON 的正确编组。 + time 包的许多工厂方法提供了包装器。 + + + + - **conditions.message** (string), 必需 + + message 是一条人类可读的消息,指示有关转换的详细信息。它可能是一个空字符串。 + + + + - **conditions.reason** (string), 必需 + + reason 包含一个程序标识符,指示状况最后一次转换的原因。 + 特定状况类型的生产者可以定义该字段的预期值和含义,以及这些值是否可被视为有保证的 API。 + 该值应该是 CamelCase 字符串。此字段不能为空。 + + + + - **conditions.status** (string), 必需 + + 状况的状态为 True、False、Unknown 之一。 + + + + - **conditions.type** (string), 必需 + + CamelCase 或 foo.example.com/CamelCase 形式的状况类型。 + + + + - **conditions.observedGeneration** (int64) + + observedGeneration 表示设置状况时所基于的 .metadata.generation。 + 例如,如果 .metadata.generation 当前为 12,但 .status.conditions[x].observedGeneration 为 9, + 则状况相对于实例的当前状态已过期。 + + + +- **disruptedPods** (map[string]Time) + + disruptedPods 包含有关 Pod 的一些信息,这些 Pod 的驱逐操作已由 API 服务器上的 eviction 子资源处理程序处理, + 但尚未被 PodDisruptionBudget 控制器观察到。 + 从 API 服务器处理驱逐请求到 PDB 控制器看到该 Pod 已标记为删除(或超时后),Pod 将记录在此映射中。 + 映射中的键名是 Pod 的名称,键值是 API 服务器处理驱逐请求的时间。 + 如果删除没有发生并且 Pod 仍然存在,PodDisruptionBudget 控制器将在一段时间后自动将 Pod 从列表中删除。 + 如果一切顺利,此映射大部分时间应该是空的。映射中的存在大量条目可能表明 Pod 删除存在问题。 + + + + Time 是 time.Time 的包装器,它支持对 YAML 和 JSON 的正确编组。 + time 包的许多工厂方法提供了包装器。 + + + +- **observedGeneration** (int64) + + 更新此 PDB 状态时观察到的最新一代。 + DisruptionsAllowed 和其他状态信息仅在 observedGeneration 等于 PDB 的对象的代数时才有效。 + +## PodDisruptionBudgetList {#PodDisruptionBudgetList} + + + +PodDisruptionBudgetList 是 PodDisruptionBudget 的集合。 + +
+ +- **apiVersion**: policy/v1 + +- **kind**: PodDisruptionBudgetList + + + +- **metadata** (}}">ListMeta) + + 标准的对象元数据。 + 更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata。 + + +- **items** ([]}}">PodDisruptionBudget), 必需 + + items 是 PodDisruptionBudgets 的列表。 + + + +## 操作 {#Operations} + +
+ + + +### `get` 读取指定的 PodDisruptionBudget + +#### HTTP 请求 + +GET /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name} + + +#### 参数 + + +- **name** (**路径参数**): string, 必需 + + PodDisruptionBudget 的名称。 + + +- **namespace** (**路径参数**): string, 必需 + + }}">namespace + + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">PodDisruptionBudget): OK + +401: Unauthorized + + +### `get` 读取指定 PodDisruptionBudget 的状态 + +#### HTTP 请求 + +GET /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}/status + + +#### 参数 + + +- **name** (**路径参数**): string, 必需 + + PodDisruptionBudget 的名称。 + + +- **namespace** (**路径参数**): string, 必需 + + }}">namespace + + +- **pretty** (**查询参数**): string + + }}">pretty + + +响应 + +200 (}}">PodDisruptionBudget): OK + +401: Unauthorized + + +### `list` 列出或监视 PodDisruptionBudget 类型的对象 + +#### HTTP 请求 + +GET /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets + + +#### 参数 + + +- **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 (}}">PodDisruptionBudgetList): OK + +401: Unauthorized + + +### `list` 列出或监视 PodDisruptionBudget 类型的对象 + +#### HTTP 请求 + +GET /apis/policy/v1/poddisruptionbudgets + + +#### 参数 + + +- **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 (}}">PodDisruptionBudgetList): OK + +401: Unauthorized + + +### `create` 创建一个 PodDisruptionBudget +#### HTTP 请求 + +POST /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets + + +#### 参数 + + +- **namespace** (**路径参数**): string, 必需 + + }}">namespace + + +- **body**: }}">PodDisruptionBudget, +必需 + + +- **dryRun** (**查询参数**): string + + }}">dryRun + + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">PodDisruptionBudget): OK + +201 (}}">PodDisruptionBudget): Created + +202 (}}">PodDisruptionBudget): Accepted + +401: Unauthorized + + +### `update` 替换指定的 PodDisruptionBudget + +#### HTTP 请求 + +PUT /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name} + + +#### 参数 + + +- **name** (**路径参数**): string, 必需 + + PodDisruptionBudget 的名称。 + + +- **namespace** (**路径参数**): string, 必需 + + }}">namespace + + +- **body**: }}">PodDisruptionBudget, +必需 + + +- **dryRun** (**查询参数**): string + + }}">dryRun + + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + + + + +#### 响应 + +200 (}}">PodDisruptionBudget): OK + +201 (}}">PodDisruptionBudget): Created + +401: Unauthorized + + +### `update` 替换指定 PodDisruptionBudget 的状态 + +#### HTTP 请求 + +PUT /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}/status + + +#### 参数 + + +- **name** (**路径参数**): string, 必需 + + PodDisruptionBudget 的名称。 + + +- **namespace** (**路径参数**): string, 必需 + + }}">namespace + + +- **body**: }}">PodDisruptionBudget, +必需 + + +- **dryRun** (**查询参数**): string + + }}">dryRun}}">fieldManager +--> +- **fieldManager** (**查询参数**): string + + }}">fieldManager + + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + + + + +#### 响应 + +200 (}}">PodDisruptionBudget): OK + +201 (}}">PodDisruptionBudget): Created + +401: Unauthorized + + +### `patch` 部分更新指定的 PodDisruptionBudget +#### HTTP 请求 + +PATCH /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name} + + +#### 参数 + + +- **name** (**路径参数**): string, 必需 + + PodDisruptionBudget 的名称 + + +- **namespace** (**路径参数**): string, 必需 + + }}">namespace + + + +- **body**: }}">Patch, 必需 + + +- **dryRun** (**查询参数**): string + + }}">dryRun + + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + + +- **force** (**查询参数**): boolean + + }}">force + + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">PodDisruptionBudget): OK + +201 (}}">PodDisruptionBudget): Created + +401: Unauthorized + + +### `patch` 部分更新指定 PodDisruptionBudget 的状态 +#### HTTP 请求 + +PATCH /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}/status + + +#### 参数 + + +- **name** (**路径参数**): string, 必需 + + PodDisruptionBudget 的名称。 + + +- **namespace** (**路径参数**): string, 必需 + + }}">namespace + + +- **body**: }}">Patch, 必需 + + +- **dryRun** (**查询参数**): string + + }}">dryRun + + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + + +- **force** (**查询参数**): boolean + + }}">force + + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">PodDisruptionBudget): OK + +201 (}}">PodDisruptionBudget): Created + +401: Unauthorized + + +### `delete` 删除 PodDisruptionBudget + +#### HTTP 请求 + +DELETE /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name} + + +#### 参数 + + +- **name** (**路径参数**): string, 必需 + + PodDisruptionBudget 的名称。 + + +- **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` 删除 PodDisruptionBudget 的集合 + +#### HTTP Request + +DELETE /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets + + +#### 参数 + + +- **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 + diff --git a/content/zh-cn/docs/reference/kubernetes-api/service-resources/ingress-class-v1.md b/content/zh-cn/docs/reference/kubernetes-api/service-resources/ingress-class-v1.md index 54b62f404c67f..81f308cbaf394 100644 --- a/content/zh-cn/docs/reference/kubernetes-api/service-resources/ingress-class-v1.md +++ b/content/zh-cn/docs/reference/kubernetes-api/service-resources/ingress-class-v1.md @@ -4,13 +4,12 @@ api_metadata: import: "k8s.io/api/networking/v1" kind: "IngressClass" content_type: "api_reference" -description: "IngressClass 代表 Ingress 的类, 被 Ingress 的规约引用。" +description: "IngressClass 代表 Ingress 的类,被 Ingress 的规约引用。" title: "IngressClass" weight: 5 --- `apiVersion: networking.k8s.io/v1` @@ -34,8 +32,9 @@ IngressClass represents the class of the Ingress, referenced by the Ingress Spec --> ## IngressClass {#IngressClass} -IngressClass 代表 Ingress 的类, 被 Ingress 的规约引用。 -`ingressclass.kubernetes.io/is-default-class` 注解可以用来标明一个 IngressClass 应该被视为默认的 Ingress 类。 +IngressClass 代表 Ingress 的类,被 Ingress 的规约引用。 +`ingressclass.kubernetes.io/is-default-class` +注解可以用来标明一个 IngressClass 应该被视为默认的 Ingress 类。 当某个 IngressClass 资源将此注解设置为 true 时, 没有指定类的新 Ingress 资源将被分配到此默认类。 @@ -50,22 +49,23 @@ IngressClass 代表 Ingress 的类, 被 Ingress 的规约引用。 - 标准的列表元数据。 - 更多信息: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** (}}">IngressClassSpec) - spec 是 IngressClass 的期望状态。更多信息:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status + spec 是 IngressClass 的期望状态。更多信息: + https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status ## IngressClassSpec {#IngressClassSpec} -IngressClassSpec 提供有关 Ingress 类的信息。 +IngressClassSpec 提供有关 Ingress 类的信息。
@@ -120,14 +120,16 @@ IngressClassSpec 提供有关 Ingress 类的信息。 apiGroup 是被引用资源的组。 如果未指定 apiGroup,则被指定的 kind 必须在核心 API 组中。 - 对于任何其他第三方类型, APIGroup 是必需的。 + 对于任何其他第三方类型,apiGroup 是必需的。 - **parameters.namespace** (string) - namespace 是被引用资源的命名空间。当范围被设置为 “namespace” 时,此字段是必需的,当范围被设置为 “Cluster”,此字段必须取消设置。 + namespace 是被引用资源的命名空间。 + 当范围被设置为 “namespace” 时,此字段是必需的; + 当范围被设置为 “Cluster” 时,此字段必须不设置。 - **parameters.scope** (string) - **items** ([]}}">IngressClass),必需 - items 是 IngressClasses 的列表 + items 是 IngressClasses 的列表。 + +`apiVersion: v1` + +`import "k8s.io/api/core/v1”` + +## Service {#Service} + + +Service 是软件服务(例如 mysql)的命名抽象,包含代理要侦听的本地端口(例如 3306)和一个选择算符, +选择算符用来确定哪些 Pod 将响应通过代理发送的请求。 + +
+ +- **apiVersion**: v1 + +- **kind**: Service + +- **metadata** (}}">ObjectMeta) + + + + 标准的对象元数据。 + 更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + +- **spec** (}}">ServiceSpec) + + + + spec 定义 Service 的行为。https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status + +- **status**(}}">ServiceStatus) + + + + 最近观察到的 Service 状态。由系统填充。只读。 + 更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status + +## ServiceSpec {#ServiceSpec} + + +ServiceSpec 描述用户在服务上创建的属性。 + +
+ +- **selector** (map[string]string) + + + + 将 Service 流量路由到具有与此 selector 匹配的标签键值对的 Pod。 + 如果为空或不存在,则假定该服务有一个外部进程管理其端点,Kubernetes 不会修改该端点。 + 仅适用于 ClusterIP、NodePort 和 LoadBalancer 类型。如果类型为 ExternalName,则忽略。 + 更多信息: https://kubernetes.io/docs/concepts/services-networking/service/ + +- **ports** ([]ServicePort) + + + + **Patch strategy:基于键 `type` 合并** + + **Map:合并时将保留 type 键的唯一值** + + 此 Service 公开的端口列表。 + 更多信息: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies + + + + + + **ServicePort 包含有关 ServicePort 的信息。** + + + + - **ports.port** (int32),必需 + + Service 将公开的端口。 + + + + 在 Service 所针对的 Pod 上要访问的端口号或名称。 + 编号必须在 1 到 65535 的范围内。名称必须是 IANA_SVC_NAME。 + 如果此值是一个字符串,将在目标 Pod 的容器端口中作为命名端口进行查找。 + 如果未指定字段,则使用 "port” 字段的值(直接映射)。 + 对于 clusterIP 为 None 的服务,此字段将被忽略, + 应忽略不设或设置为 "port” 字段的取值。 + 更多信息: https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service + + + + + + IntOrString 是一种可以保存 int32 或字符串的类型。 + 在 JSON 或 YAML 编组和解组中使用时,它会生成或使用内部类型。 + 例如,这允许您拥有一个可以接受名称或数字的 JSON 字段。 + + - **ports.protocol** (string) + + + + 此端口的 IP 协议。支持 “TCP”、“UDP” 和 “SCTP”。默认为 TCP。 + + - **ports.name** (string) + + + + Service 中此端口的名称。这必须是 DNS_LABEL。 + ServiceSpec 中的所有端口的名称都必须唯一。 + 在考虑 Service 的端点时,这一字段值必须与 EndpointPort 中的 `name` 字段相同。 + 如果此服务上仅定义一个 ServicePort,则为此字段为可选。 + + - **ports.nodePort** (int32) + + + + 当类型为 NodePort 或 LoadBalancer 时,Service 公开在节点上的端口, + 通常由系统分配。如果指定了一个在范围内且未使用的值,则将使用该值,否则操作将失败。 + 如果在创建的 Service 需要该端口时未指定该字段,则会分配端口。 + 如果在创建不需要该端口的 Service时指定了该字段,则会创建失败。 + 当更新 Service 时,如果不再需要此字段(例如,将类型从 NodePort 更改为 ClusterIP),这个字段将被擦除。 + 更多信息: https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport + + - **ports.appProtocol** (string) + + + + 此端口的应用协议,遵循标准的 Kubernetes 标签语法,无前缀名称按照 IANA 标准服务名称 + (参见 RFC-6335 和 https://www.iana.org/assignments/service-names)。 + 非标准协议应该使用前缀名称,如 mycompany.com/my-custom-protocol。 + +- **type** (string) + + + + type 确定 Service 的公开方式。默认为 ClusterIP。 + 有效选项为 ExternalName、ClusterIP、NodePort 和 LoadBalancer。 + “ClusterIP” 为端点分配一个集群内部 IP 地址用于负载均衡。 + Endpoints 由 selector 确定,如果未设置 selector,则需要通过手动构造 Endpoints 或 EndpointSlice 的对象来确定。 + 如果 clusterIP 为 “None”,则不分配虚拟 IP,并且 Endpoints 作为一组端点而不是虚拟 IP 发布。 + “NodePort” 建立在 ClusterIP 之上,并在每个节点上分配一个端口,该端口路由到与 clusterIP 相同的 Endpoints。 + “LoadBalancer” 基于 NodePort 构建并创建一个外部负载均衡器(如果当前云支持),该负载均衡器路由到与 clusterIP 相同的 Endpoints。 + “externalName” 将此 Service 别名为指定的 externalName。其他几个字段不适用于 ExternalName Service。 + 更多信息: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types + +- **ipFamilies** ([]string) + + + + **原子: 将在合并期间被替换** + + + + iPFamilies 是分配给此服务的 IP 协议(例如 IPv4、IPv6)的列表。 + 该字段通常根据集群配置和 ipFamilyPolicy 字段自动设置。 + 如果手动指定该字段,且请求的协议在集群中可用,且 ipFamilyPolicy 允许,则使用;否则服务创建将失败。 + 该字段修改是有条件的:它允许添加或删除辅助 IP 协议,但不允许更改服务的主要 IP 协议。 + 有效值为 “IPv4” 和 “IPv6”。 + 该字段仅适用于 ClusterIP、NodePort 和 LoadBalancer 类型的服务,并且确实可用于“无头”服务。 + 更新服务设置类型为 ExternalName 时,该字段将被擦除。 + + + + 该字段最多可以包含两个条目(双栈系列,按任意顺序)。 + 如果指定,这些协议栈必须对应于 clusterIPs 字段的值。 + clusterIP 和 ipFamilies 都由 ipFamilyPolicy 字段管理。 + +- **ipFamilyPolicy** (string) + + + + iPFamilyPolicy 表示此服务请求或要求的双栈特性。 + 如果没有提供值,则此字段将被设置为 SingleStack。 + 服务可以是 “SingleStack”(单个 IP 协议)、 + “PreferDualStack”(双栈配置集群上的两个 IP 协议或单栈集群上的单个 IP 协议) + 或 “RequireDualStack”(双栈上的两个 IP 协议配置的集群,否则失败)。 + ipFamilies 和 clusterIPs 字段取决于此字段的值。 + 更新服务设置类型为 ExternalName 时,此字段将被擦除。 + + +- **clusterIP** (string) + + + + clusterIP 是服务的 IP 地址,通常是随机分配的。 + 如果地址是手动指定的,在范围内(根据系统配置),且没有被使用,它将被分配给服务,否则创建服务将失败。 + clusterIP 一般不会被更改,除非 type 被更改为 ExternalName + (ExternalName 需要 clusterIP 为空)或 type 已经是 ExternalName 时,可以更改 clusterIP(在这种情况下,可以选择指定此字段)。 + 可选值 “None”、空字符串 (“”) 或有效的 IP 地址。 + clusterIP 为 “None” 时会生成“无头服务”(无虚拟 IP),这在首选直接 Endpoint 连接且不需要代理时很有用。 + 仅适用于 ClusterIP、NodePort、和 LoadBalancer 类型的服务。 + 如果在创建 ExternalName 类型的 Service 时指定了 clusterIP,则创建将失败。 + 更新 Service type 为 ExternalName 时,clusterIP 会被移除。 + 更多信息: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies + +- **clusterIPs** ([]string) + + + **原子: 将在合并期间被替换** + + + + clusterIPs 是分配给该 Service 的 IP 地址列表,通常是随机分配的。 + 如果地址是手动指定的,在范围内(根据系统配置),且没有被使用,它将被分配给 Service;否则创建 Service 失败。 + clusterIP 一般不会被更改,除非 type 被更改为 ExternalName + (ExternalName 需要 clusterIPs 为空)或 type 已经是 ExternalName 时,可以更改 clusterIPs(在这种情况下,可以选择指定此字段)。 + 可选值 “None”、空字符串 (“”) 或有效的 IP 地址。 + clusterIPs 为 “None” 时会生成“无头服务”(无虚拟 IP),这在首选直接 Endpoint 连接且不需要代理时很有用。 + 适用于 ClusterIP、NodePort、和 LoadBalancer 类型的服务。 + 如果在创建 ExternalName 类型的 Service 时指定了 clusterIPs,则会创建失败。 + 更新 Service type 为 ExternalName 时,该字段将被移除。如果未指定此字段,则将从 clusterIP 字段初始化。 + 如果指定 clusterIPs,客户端必须确保 clusterIPs[0] 和 clusterIP 一致。 + + + + clusterIPs 最多可包含两个条目(双栈系列,按任意顺序)。 + 这些 IP 必须与 ipFamilies 的值相对应。 + clusterIP 和 ipFamilies 都由 ipFamilyPolicy 管理。 + 更多信息: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies + +- **externalIPs** ([]string) + + + + externalIPs 是一个 IP 列表,集群中的节点会为此 Service 接收针对这些 IP 地址的流量。 + 这些 IP 不被 Kubernetes 管理。用户需要确保流量可以到达具有此 IP 的节点。 + 一个常见的例子是不属于 Kubernetes 系统的外部负载均衡器。 + +- **sessionAffinity** (string) + + + + 支持 “ClientIP” 和 “None”。用于维护会话亲和性。 + 启用基于客户端 IP 的会话亲和性。必须是 ClientIP 或 None。默认为 None。 + 更多信息: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies + +- **loadBalancerIP** (string) + + + + 仅适用于服务类型: LoadBalancer。此功能取决于底层云提供商是否支持负载均衡器。 + 如果云提供商不支持该功能,该字段将被忽略。 + 已弃用: 该字段信息不足,且其含义因实现而异,而且不支持双栈。 + 从 Kubernetes v1.24 开始,鼓励用户在可用时使用特定于实现的注释。在未来的 API 版本中可能会删除此字段。 + +- **loadBalancerSourceRanges** ([]string) + + + + 如果设置了此字段并且被平台支持,将限制通过云厂商的负载均衡器的流量到指定的客户端 IP。 + 如果云提供商不支持该功能,该字段将被忽略。 + 更多信息: https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/ + +- **loadBalancerClass** (string) + + + + loadBalancerClass 是此 Service 所属的负载均衡器实现的类。 + 如果设置了此字段,则字段值必须是标签风格的标识符,带有可选前缀,例如 ”internal-vip” 或 “example.com/internal-vip”。 + 无前缀名称是为最终用户保留的。该字段只能在 Service 类型为 “LoadBalancer” 时设置。 + 如果未设置此字段,则使用默认负载均衡器实现。默认负载均衡器现在通常通过云提供商集成完成,但应适用于任何默认实现。 + 如果设置了此字段,则假定负载均衡器实现正在监视具有对应负载均衡器类的 Service。 + 任何默认负载均衡器实现(例如云提供商)都应忽略设置此字段的 Service。 + 只有在创建或更新的 Service 的 type 为 “LoadBalancer” 时,才可设置此字段。 + 一经设定,不可更改。当 Service 的 type 更新为 “LoadBalancer” 之外的其他类型时,此字段将被移除。 + +- **externalName** (string) + + + + externalName 是发现机制将返回的外部引用,作为此服务的别名(例如 DNS CNAME 记录)。 + 不涉及代理。必须是小写的 RFC-1123 主机名 (https://tools.ietf.org/html/rfc1123), + 并且要求 `type` 为 “ExternalName”。 + +- **externalTrafficPolicy** (string) + + + externalTrafficPolicy 表示此 Service 是否希望将外部流量路由到节点本地或集群范围的 Endpoint。 + 字段值 “Local” 保留客户端 IP 并可避免 LoadBalancer 和 Nodeport 类型 Service 的第二跳,但存在潜在流量传播不平衡的风险。 + 字段值 “Cluster” 则会掩盖客户端源 IP,可能会导致第二次跳转到另一个节点,但整体流量负载分布较好。 + +- **internalTrafficPolicy** (string) + + + internalTrafficPolicy 指定是将集群内部流量路由到所有端点还是仅路由到节点本地的端点。 + 字段值 “Cluster” 将 Service 的内部流量路由到所有端点。 + 字段值 ”Local” 意味着仅将流量路由到节点本地的端点;如果节点本地端点未准备好,则丢弃流量。 + 默认值为 “Cluster”。 + +- **healthCheckNodePort** (int32) + + + healthCheckNodePort 指定 Service 的健康检查节点端口。 + 仅适用于 type 为 LoadBalancer 且 externalTrafficPolicy 设置为 Local 的情况。 + 如果为此字段设定了一个值,该值在合法范围内且没有被使用,则使用所指定的值。 + 如果未设置此字段,则自动分配字段值。外部系统(例如负载平衡器)可以使用此端口来确定给定节点是否拥有此服务的端点。 + 在创建不需要 healthCheckNodePort 的 Service 时指定了此字段,则 Service 创建会失败。 + 要移除 healthCheckNodePort,需要更改 Service 的 type。 + +- **publishNotReadyAddresses** (boolean) + + + + publishNotReadyAddresses 表示任何处理此 Service 端点的代理都应忽略任何准备就绪/未准备就绪的指示。 + 设置此字段的主要场景是为 StatefulSet 的服务提供支持,使之能够为其 Pod 传播 SRV DNS 记录,以实现对等发现。 + 为 Service 生成 Endpoints 和 EndpointSlice 资源的 Kubernetes 控制器对字段的解读是, + 即使 Pod 本身还没有准备好,所有端点都可被视为 “已就绪”。 + 对于代理而言,如果仅使用 Kubernetes 通过 Endpoints 或 EndpointSlice 资源所生成的端点, + 则可以安全地假设这种行为。 + +- **sessionAffinityConfig** (SessionAffinityConfig) + + + sessionAffinityConfig 包含会话亲和性的配置。 + + + + + **SessionAffinityConfig 表示会话亲和性的配置。** + + - **sessionAffinityConfig.clientIP** (ClientIPConfig) + + + + clientIP 包含基于客户端 IP 的会话亲和性的配置。 + + + + + + ClientIPConfig 表示基于客户端 IP 的会话亲和性的配置。 + + - **sessionAffinityConfig.clientIP.timeoutSeconds** (int32) + + + + timeoutSeconds 指定 ClientIP 类型会话的维系时间秒数。 + 如果 ServiceAffinity == "ClientIP",则该值必须 >0 && <=86400(1 天)。默认值为 10800(3 小时)。 + +- **allocateLoadBalancerNodePorts** (boolean) + + + + allocateLoadBalancerNodePorts 定义了是否会自动为 LoadBalancer 类型的 Service 分配 NodePort。默认为 true。 + 如果集群负载均衡器不依赖 NodePort,则可以设置此字段为 false。 + 如果调用者(通过指定一个值)请求特定的 NodePort,则无论此字段如何,都会接受这些请求。 + 该字段只能设置在 type 为 LoadBalancer 的 Service 上,如果 type 更改为任何其他类型,该字段将被移除。 + +## ServiceStatus {#ServiceStatus} + + +ServiceStatus 表示 Service 的当前状态。 + +
+ +- **conditions** ([]Condition) + + + + **Patch strategy: 在 `type` 上合并** + + **Map: 键类型的唯一值将在合并期间保留** + + 服务的当前状态。 + + + + + + **condition 包含此 API 资源某一方面当前的状态详细信息。** + + + + - **conditions.lastTransitionTime**(时间),必需 + + lastTransitionTime 是状况最近一次状态转化的时间。 + 变化应该发生在下层状况发生变化的时候。如果不知道下层状况发生变化的时间, + 那么使用 API 字段更改的时间是可以接受的。 + + + + + + time 是 time.Time 的包装类,支持正确地序列化为 YAML 和 JSON。 + 为 time 包提供的许多工厂方法提供了包装类。 + + + + - **conditions.message** (string),必需 + + + + message 是人类可读的消息,有关转换的详细信息,可以是空字符串。 + + + + - **conditions.reason** (string),必需 + + + + reason 包含一个程序标识符,指示 condition 最后一次转换的原因。 + 特定条件类型的生产者可以定义该字段的预期值和含义,以及这些值是否被视为有保证的 API。 + 该值应该是 CamelCase 字符串且不能为空。 + + + + - **conditions.status** (string),必需 + + + + condition 的状态,True、False、Unknown 之一。 + + + + - **conditions.type** (string),必需 + + + + CamelCase 或 foo.example.com/CamelCase 中的条件类型。 + + - **conditions.observedGeneration** (int64) + + + + observedGeneration 表示设置 condition 基于的 .metadata.generation 的过期次数。 + 例如,如果 .metadata.generation 当前为 12,但 .status.conditions[x].observedGeneration 为 9, + 则 condition 相对于实例的当前状态已过期。 + +- **loadBalancer** (LoadBalancerStatus) + + + + loadBalancer 包含负载均衡器的当前状态(如果存在)。 + + + + + + **LoadBalancerStatus 表示负载均衡器的状态。** + + - **loadBalancer.ingress** ([]LoadBalancerIngress) + + + + ingress 是一个包含负载均衡器 Ingress 点的列表。Service 的流量需要被发送到这些 Ingress 点。 + + + + + + **LoadBalancerIngress 表示负载平衡器入口点的状态: 用于服务的流量是否被发送到入口点。** + + - **loadBalancer.ingress.hostname** (string) + + + + hostname 是为基于 DNS 的负载均衡器 Ingress 点(通常是 AWS 负载均衡器)设置的。 + + - **loadBalancer.ingress.ip** (string) + + + + ip 是为基于 IP 的负载均衡器 Ingress 点(通常是 GCE 或 OpenStack 负载均衡器)设置的。 + + - **loadBalancer.ingress.ports** ([]PortStatus) + + + + **Atomic: 将在合并期间被替换** + + + + ports 是 Service 的端口列表。如果设置了此字段,Service 中定义的每个端口都应该在此列表中。 + + + + + + - **loadBalancer.ingress.ports.port** (int32),必需 + + + + port 是所记录的服务端口状态的端口号。 + + + + - **loadBalancer.ingress.ports.protocol** (string),必需 + + + + protocol 是所记录的服务端口状态的协议。支持的值为:“TCP”、”UDP”、“SCTP”。 + + - **loadBalancer.ingress.ports.error** (string) + + + + error 是记录 Service 端口的问题。 + 错误的格式应符合以下规则: + - 内置错误原因应在此文件中指定,应使用 CamelCase 名称。 + - 云提供商特定错误原因的名称必须符合格式 foo.example.com/CamelCase。 + +## ServiceList {#ServiceList} + + + +ServiceList 包含一个 Service 列表。 + +
+ +- **apiVersion**: v1 + +- **kind**: Service 列表 + +- **metadata** (}}">ListMeta) + + + 标准列表元数据。 + 更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds + + + +- **items**([]}}">Service),必需 + + + + Service 列表 + + + +## 操作 {#operations} + +
+ + + +### `get` 读取指定的 APIService + +#### HTTP 请求 + +GET /api/v1/namespaces/{namespace}/services/{name} + + +#### 参数 + +- **name** (**查询参数**):string,必需 + + + Service 名称 + +- **namespace**(**路径参数**):string,必需 + + }}">namespace + +- **pretty**(**查询参数**):string + + }}">pretty + + + +#### 响应 + +200(}}">Service): OK + +401: Unauthorized + + + +### `get` 读取指定 Service 的状态 + +#### HTTP 请求 + +获取 /api/v1/namespaces/{namespace}/services/{name}/status + + + +#### 参数 + +- **name** (**路径参数**):string,必需 + + + + Service 名称 + +- **namespace**(**路径参数**):string,必需 + + }}">namespace + +- **pretty**(**查询参数**):string + + }}">pretty + + + +#### 响应 + +200(}}">Service): OK + +401: Unauthorized + + + +### `list` 列出或观察 Service 类型的对象 + +#### HTTP 请求 + +获取 /api/v1/namespaces/{namespace}/services + + + +#### 参数 + +- **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(}}">ServiceList): OK + +401: Unauthorized + + + +### `list` 列出或观察 Service 类型的对象 + +#### HTTP 请求 + +获取 /api/v1/服务 + + + +#### 参数 + +- **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(}}">ServiceList): OK + +401: Unauthorized + + + +### `create` 创建一个 Service + +#### HTTP 请求 + +POST /api/v1/namespaces/{namespace}/services + + + +#### 参数 + +- **namespace**(**路径参数**):string,必需 + + }}">namespace + +- **body**: }}">Service,必需 + +- **dryRun**(**查询参数**):string + + }}">dryRun + +- **fieldManager**(**查询参数**):string + + }}">fieldManager + +- **fieldValidation**(**查询参数**):string + + }}">fieldValidation + +- **pretty**(**查询参数**):string + + }}">pretty + + + +#### 响应 + +200(}}">Service): OK + +201(}}">Service): Created + +202(}}">Service): Accepted + +401: Unauthorized + + + +### `update` 替换指定的 Service + +#### HTTP 请求 + +PUT /api/v1/namespaces/{namespace}/services/{name} + + + +#### 参数 + +- **name** (**路径参数**):string,必需 + + + + Service 名称 + +- **namespace**(**路径参数**):string,必需 + + }}">namespace + +- **body**: }}">Service,必需 + +- **dryRun**(**查询参数**):string + + }}">dryRun + +- **fieldManager**(**查询参数**):string + + }}">fieldManager + +- **fieldValidation**(**查询参数**):string + + }}">fieldValidation + +- **pretty**(**查询参数**):string + + }}">pretty + + + +#### 响应 + +200(}}">Service): OK + +201(}}">Service): Created + +401: Unauthorized + + + +### `update` 替换指定 Service 的状态 + +#### HTTP 请求 + +PUT /api/v1/namespaces/{namespace}/services/{name}/status + + + +#### 参数 + +- **name** (**路径参数**):string,必需 + + + + Service 名称 + +- **namespace**(**路径参数**):string,必需 + + }}">namespace + +- **body**: }}">Service,必需 + +- **dryRun**(**查询参数**):string + + }}">dryRun + +- **fieldManager**(**查询参数**):string + + }}">fieldManager + +- **fieldValidation**(**查询参数**):string + + }}">fieldValidation + +- **pretty**(**查询参数**):string + + }}">pretty + + + +#### 响应 + +200(}}">Service): OK + +201(}}">Service): Created + +401: Unauthorized + + + +### `patch` 部分更新指定的 Service + +#### HTTP 请求 + +PATCH /api/v1/namespaces/{namespace}/services/{name} + + + +#### 参数 + +- **name** (**路径参数**):string,必需 + + + + Service 名称 + +- **namespace**(**路径参数**):string,必需 + + }}">namespace + +- **body**: }}">Patch,必需 + +- **dryRun**(**查询参数**):string + + }}">dryRun + +- **fieldManager**(**查询参数**):string + + }}">fieldManager + +- **fieldValidation**(**查询参数**):string + + }}">fieldValidation + +- **force**(**查询参数**):boolean + + }}">force + +- **pretty**(**查询参数**):string + + }}">pretty + + + +#### 响应 + +200(}}">Service): OK + +201(}}">Service): Created + +401: Unauthorized + +### `patch` 部分更新指定 Service 的状态 + +#### HTTP 请求 + +PATCH /api/v1/namespaces/{namespace}/services/{name}/status + + + +#### 参数 + +- **name** (**路径参数**):string,必需 + + + + Service 名称 + +- **namespace**(**路径参数**):string,必需 + + }}">namespace + +- **body**: }}">Patch,必需 + +- **dryRun**(**查询参数**):string + + }}">dryRun + +- **fieldManager**(**查询参数**):string + + }}">fieldManager + +- **fieldValidation**(**查询参数**):string + + }}">fieldValidation + +- **force**(**查询参数**):boolean + + }}">force + +- **pretty**(**查询参数**):string + + }}">pretty + + + +#### 响应 + +200(}}">Service): OK + +201(}}">Service): Created + +401: Unauthorized + + + +### `delete` 删除 Service + +#### HTTP 请求 + +DELETE /api/v1/namespaces/{namespace}/services/{name} + + + +#### 参数 + +- **name** (**路径参数**):string,必需 + + + + Service 名称 + +- **namespace**(**路径参数**):string,必需 + + }}">namespace + +- **正文**: }}">DeleteOptions + +- **dryRun**(**查询参数**):string + + }}">dryRun + +- **gracePeriodSeconds**(**查询参数**):integer + + }}">gracePeriodSeconds + +- **pretty**(**查询参数**):string + + }}">pretty + +- **propagationPolicy**(**查询参数**):string + + }}">propagationPolicy + + + +#### 响应 + +200(}}">Service): OK + +202(}}">Service): Accepted + +401: Unauthorized + + + +### `deletecollection` 删除 Service 集合 + +#### HTTP 请求 + +DELETE /api/v1/namespaces/{namespace}/services + + + +#### 参数 + +- **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 diff --git a/content/zh-cn/docs/reference/kubernetes-api/workload-resources/controller-revision-v1.md b/content/zh-cn/docs/reference/kubernetes-api/workload-resources/controller-revision-v1.md index d29eda09df6e0..69b44a1b7af70 100644 --- a/content/zh-cn/docs/reference/kubernetes-api/workload-resources/controller-revision-v1.md +++ b/content/zh-cn/docs/reference/kubernetes-api/workload-resources/controller-revision-v1.md @@ -7,7 +7,6 @@ content_type: "api_reference" description: "ControllerRevision 实现了状态数据的不可变快照。" title: "ControllerRevision" weight: 7 -auto_generated: false --- - `apiVersion: apps/v1` `import "k8s.io/api/apps/v1"` @@ -71,8 +69,8 @@ API 服务器将无法成功验证所有尝试改变 data 字段的请求。 --> - **metadata** (}}">ObjectMeta) - 标准的对象元数据。 - 更多信息: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 - *RawExtension 用于以外部版本来保存扩展数据。 + **RawExtension 用于以外部版本来保存扩展数据。** - // 内部包: + 内部包: + + ```go type MyAPIObject struct { runtime.TypeMeta `json:",inline"` MyPlugin runtime.Object `json:"myPlugin"` @@ -120,6 +120,7 @@ API 服务器将无法成功验证所有尝试改变 data 字段的请求。 type PluginA struct { AOption string `json:"aOption"` } + ``` - // 外部包: + 外部包: + + ```go type MyAPIObject struct { runtime.TypeMeta `json:",inline"` MyPlugin runtime.RawExtension `json:"myPlugin"` @@ -137,6 +140,7 @@ API 服务器将无法成功验证所有尝试改变 data 字段的请求。 type PluginA struct { AOption string `json:"aOption"` } + ``` - // 在网络上,JSON 看起来像这样: + 在网络上,JSON 看起来像这样: + ```json { "kind":"MyAPIObject", "apiVersion":"v1", @@ -157,6 +162,7 @@ API 服务器将无法成功验证所有尝试改变 data 字段的请求。 "aOption":"foo", }, } + ``` - **metadata** (}}">ListMeta) - 更多信息: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 + +`apiVersion: autoscaling/v2` + +`import "k8s.io/api/autoscaling/v2"` + + +## HorizontalPodAutoscaler {#HorizontalPodAutoscaler} + + +HorizontalPodAutoscaler 是水平 Pod 自动扩缩器的配置, +它根据指定的指标自动管理实现 scale 子资源的任何资源的副本数。 + +
+ +- **apiVersion**: autoscaling/v2 + +- **kind**: HorizontalPodAutoscaler + +- **metadata** (}}">ObjectMeta) + + + + metadata 是标准的对象元数据。更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + +- **spec** (}}">HorizontalPodAutoscalerSpec) + + + + spec 是自动扩缩器行为的规约。更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status. + +- **status** (}}">HorizontalPodAutoscalerStatus) + + + + status 是自动扩缩器的当前信息。 + +## HorizontalPodAutoscalerSpec {#HorizontalPodAutoscalerSpec} + + +HorizontalPodAutoscalerSpec 描述了 HorizontalPodAutoscaler 预期的功能。 + +
+ + + +- **maxReplicas** (int32),必需 + + maxReplicas 是自动扩缩器可以扩容的副本数的上限。不能小于 minReplicas。 + + + +- **scaleTargetRef** (CrossVersionObjectReference),必需 + + scaleTargetRef 指向要扩缩的目标资源,用于收集 Pod 的相关指标信息以及实际更改的副本数。 + + + + + + **CrossVersionObjectReference 包含足够的信息来让你识别出所引用的资源。** + + - **scaleTargetRef.kind** (string),必需 + + 被引用对象的类别;更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds" + + + + - **scaleTargetRef.name** (string),必需 + + 被引用对象的名称;更多信息: https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/names/#names + + + + - **scaleTargetRef.apiVersion** (string) + + 被引用对象的 API 版本。 + + + +- **minReplicas** (int32) + + minReplicas 是自动扩缩器可以缩减的副本数的下限。它默认为 1 个 Pod。 + 如果启用了 Alpha 特性门控 HPAScaleToZero 并且配置了至少一个 Object 或 External 度量指标, + 则 minReplicas 允许为 0。只要至少有一个度量值可用,扩缩就处于活动状态。 + + + +- **behavior** (HorizontalPodAutoscalerBehavior) + + behavior 配置目标在扩容(Up)和缩容(Down)两个方向的扩缩行为(分别用 scaleUp 和 scaleDown 字段)。 + 如果未设置,则会使用默认的 HPAScalingRules 进行扩缩容。 + + + + + + **HorizontalPodAutoscalerBehavior 配置目标在扩容(Up)和缩容(Down)两个方向的扩缩行为 + (分别用 scaleUp 和 scaleDown 字段)。** + + - **behavior.scaleDown** (HPAScalingRules) + + scaleDown 是缩容策略。如果未设置,则默认值允许缩减到 minReplicas 数量的 Pod, + 具有 300 秒的稳定窗口(使用最近 300 秒的最高推荐值)。 + + + + + + HPAScalingRules 为一个方向配置扩缩行为。在根据 HPA 的指标计算 desiredReplicas 后应用这些规则。 + 可以通过指定扩缩策略来限制扩缩速度。可以通过指定稳定窗口来防止抖动, + 因此不会立即设置副本数,而是选择稳定窗口中最安全的值。 + + - **behavior.scaleDown.policies** ([]HPAScalingPolicy) + + **原子性:将在合并时被替换** + + policies 是可在扩缩容过程中使用的潜在扩缩策略的列表。必须至少指定一个策略,否则 HPAScalingRules 将被视为无效而丢弃。 + + + + + + **HPAScalingPolicy 是一个单一的策略,它必须在指定的过去时间间隔内保持为 true。** + + - **behavior.scaleDown.policies.type** (string),必需 + + type 用于指定扩缩策略。 + + + + - **behavior.scaleDown.policies.value** (int32),必需 + + value 包含策略允许的更改量。它必须大于零。 + + + + - **behavior.scaleDown.policies.periodSeconds** (int32),必需 + + periodSeconds 表示策略应该保持为 true 的时间窗口长度。 + periodSeconds 必须大于零且小于或等于 1800(30 分钟)。 + + + + - **behavior.scaleDown.selectPolicy** (string) + + selectPolicy 用于指定应该使用哪个策略。如果未设置,则使用默认值 Max。 + + + + - **behavior.scaleDown.stabilizationWindowSeconds** (int32) + + stabilizationWindowSeconds 是在扩缩容时应考虑的之前建议的秒数。stabilizationWindowSeconds + 必须大于或等于零且小于或等于 3600(一小时)。如果未设置,则使用默认值: + + - 扩容:0(不设置稳定窗口)。 + - 缩容:300(即稳定窗口为 300 秒)。 + + + + - **behavior.scaleUp** (HPAScalingRules) + + scaleUp 是用于扩容的扩缩策略。如果未设置,则默认值为以下值中的较高者: + + * 每 60 秒增加不超过 4 个 Pod + * 每 60 秒 Pod 数量翻倍 + + 不使用稳定窗口。 + + + + + + HPAScalingRules 为一个方向配置扩缩行为。在根据 HPA 的指标计算 desiredReplicas 后应用这些规则。 + 可以通过指定扩缩策略来限制扩缩速度。可以通过指定稳定窗口来防止抖动, + 因此不会立即设置副本数,而是选择稳定窗口中最安全的值。 + + - **behavior.scaleUp.policies** ([]HPAScalingPolicy) + + **原子性:将在合并时被替换** + + policies 是可在扩缩容过程中使用的潜在扩缩策略的列表。必须至少指定一个策略,否则 HPAScalingRules 将被视为无效而丢弃。 + + + + + + **HPAScalingPolicy 是一个单一的策略,它必须在指定的过去时间间隔内保持为 true。** + + - **behavior.scaleUp.policies.type** (string),必需 + + type 用于指定扩缩策略。 + + + + - **behavior.scaleUp.policies.value** (int32),必需 + + value 包含策略允许的更改量。它必须大于零。 + + + + - **behavior.scaleUp.policies.periodSeconds** (int32),必需 + + periodSeconds 表示策略应该保持为 true 的时间窗口长度。 + periodSeconds 必须大于零且小于或等于 1800(30 分钟)。 + + + + - **behavior.scaleUp.selectPolicy** (string) + + selectPolicy 用于指定应该使用哪个策略。如果未设置,则使用默认值 Max。 + + + + - **behavior.scaleUp.stabilizationWindowSeconds** (int32) + + stabilizationWindowSeconds 是在扩缩容时应考虑的之前建议的秒数。stabilizationWindowSeconds + 必须大于或等于零且小于或等于 3600(一小时)。如果未设置,则使用默认值: + + - 扩容:0(不设置稳定窗口)。 + - 缩容:300(即稳定窗口为 300 秒)。 + + + +- **metrics** ([]MetricSpec) + + **原子性:将在合并时被替换** + + metrics 包含用于计算预期副本数的规约(将使用所有指标的最大副本数)。 + 预期副本数是通过将目标值与当前值之间的比率乘以当前 Pod 数来计算的。 + 因此,使用的指标必须随着 Pod 数量的增加而减少,反之亦然。 + 有关每种类别的指标必须如何响应的更多信息,请参阅各个指标源类别。 + 如果未设置,默认指标将设置为 80% 的平均 CPU 利用率。 + + + + + + **MetricSpec 指定如何基于单个指标进行扩缩容(一次只能设置 `type` 和一个其他匹配字段)** + + - **metrics.type** (string),必需 + + type 是指标源的类别。它取值是 “ContainerResource”、“External”、“Object”、“Pods” 或 “Resource” 之一, + 每个类别映射到对象中的一个对应的字段。注意:“ContainerResource” 类别在特性门控 HPAContainerMetrics 启用时可用。 + + + + - **metrics.containerResource** (ContainerResourceMetricSource) + + containerResource 是指 Kubernetes 已知的资源指标(例如在请求和限制中指定的那些), + 描述当前扩缩目标中每个 Pod 中的单个容器(例如 CPU 或内存)。 + 此类指标内置于 Kubernetes 中,在使用 “pods” 源的、按 Pod 计算的普通指标之外,还具有一些特殊的扩缩选项。 + 这是一个 Alpha 特性,可以通过 HPAContainerMetrics 特性标志启用。 + + + + + + ContainerResourceMetricSource 指示如何根据请求和限制中指定的 Kubernetes 已知的资源指标进行扩缩容, + 此结构描述当前扩缩目标中的每个 Pod(例如 CPU 或内存)。在与目标值比较之前,这些值先计算平均值。 + 此类指标内置于 Kubernetes 中,并且在使用 “Pods” 源的、按 Pod 统计的普通指标之外支持一些特殊的扩缩选项。 + 只应设置一种 “target” 类别。 + + - **metrics.containerResource.container** (string),必需 + + container 是扩缩目标的 Pod 中容器的名称。 + + + + - **metrics.containerResource.name** (string),必需 + + name 是相关资源的名称。 + + + + - **metrics.containerResource.target** (MetricTarget),必需 + + target 指定给定指标的目标值。 + + + + + + **MetricTarget 定义特定指标的目标值、平均值或平均利用率** + + - **metrics.containerResource.target.type** (string),必需 + + type 表示指标类别是 `Utilization`、`Value` 或 `AverageValue`。 + + + + - **metrics.containerResource.target.averageUtilization** (int32) + + averageUtilization 是跨所有相关 Pod 的资源指标均值的目标值, + 表示为 Pod 资源请求值的百分比。目前仅对 “Resource” 指标源类别有效。 + + + + - **metrics.containerResource.target.averageValue** (}}">Quantity) + + 是跨所有相关 Pod 的指标均值的目标值(以数量形式给出)。 + + + + - **metrics.containerResource.target.value** (}}">Quantity) + + value 是指标的目标值(以数量形式给出)。 + + + + - **metrics.external** (ExternalMetricSource) + + external 指的是不与任何 Kubernetes 对象关联的全局指标。 + 这一字段允许基于来自集群外部运行的组件(例如云消息服务中的队列长度,或来自运行在集群外部的负载均衡器的 QPS)的信息进行自动扩缩容。 + + + + + + ExternalMetricSource 指示如何基于 Kubernetes 对象无关的指标 + (例如云消息传递服务中的队列长度,或来自集群外部运行的负载均衡器的 QPS)执行扩缩操作。 + + - **metrics.external.metric** (MetricIdentifier),必需 + + metric 通过名称和选择算符识别目标指标。 + + + + + + **MetricIdentifier 定义指标的名称和可选的选择算符** + + - **metrics.external.metric.name** (string),必需 + + name 是给定指标的名称。 + + + + - **metrics.external.metric.selector** (}}">LabelSelector) + + selector 是给定指标的标准 Kubernetes 标签选择算符的字符串编码形式。 + 设置后,它作为附加参数传递给指标服务器,以获取更具体的指标范围。 + 未设置时,仅 metricName 参数将用于收集指标。 + + + + - **metrics.external.target** (MetricTarget),必需 + + target 指定给定指标的目标值。 + + + + + + **MetricTarget 定义特定指标的目标值、平均值或平均利用率** + + - **metrics.external.target.type** (string),必需 + + type 表示指标类别是 `Utilization`、`Value` 或 `AverageValue`。 + + + + - **metrics.external.target.averageUtilization** (int32) + + averageUtilization 是跨所有相关 Pod 得到的资源指标均值的目标值, + 表示为 Pod 资源请求值的百分比。目前仅对 “Resource” 指标源类别有效。 + + + + - **metrics.external.target.averageValue** (}}">Quantity) + + averageValue 是跨所有相关 Pod 得到的指标均值的目标值(以数量形式给出)。 + + + + - **metrics.external.target.value** (}}">Quantity) + + value 是指标的目标值(以数量形式给出)。 + + + + - **metrics.object** (ObjectMetricSource) + + object 是指描述单个 Kubernetes 对象的指标(例如,Ingress 对象上的 `hits-per-second`)。 + + + + + + **ObjectMetricSource 表示如何根据描述 Kubernetes 对象的指标进行扩缩容(例如,Ingress 对象的 `hits-per-second`)** + + - **metrics.object.describedObject** (CrossVersionObjectReference),必需 + + describeObject 表示对象的描述,如对象的 `kind`、`name`、`apiVersion`。 + + + + + + **CrossVersionObjectReference 包含足够的信息来让你识别所引用的资源。** + + - **metrics.object.describedObject.kind** (string),必需 + + 被引用对象的类别;更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds"。 + + + + - **metrics.object.describedObject.name** (string),必需 + + 被引用对象的名称;更多信息: https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/names/#names + + + + - **metrics.object.describedObject.apiVersion** (string) + + 被引用对象的 API 版本。 + + + + - **metrics.object.metric** (MetricIdentifier),必需 + + metric 通过名称和选择算符识别目标指标。 + + + + + + **MetricIdentifier 定义指标的名称和可选的选择算符** + + - **metrics.object.metric.name** (string),必需 + + name 是给定指标的名称。 + + + + - **metrics.object.metric.selector** (}}">LabelSelector) + + selector 是给定指标的标准 Kubernetes 标签选择算符的字符串编码形式。 + 设置后,它作为附加参数传递给指标服务器,以获取更具体的指标范围。 + 未设置时,仅 metricName 参数将用于收集指标。 + + + + - **metrics.object.target** (MetricTarget),必需 + + target 表示给定指标的目标值。 + + + + + + **MetricTarget 定义特定指标的目标值、平均值或平均利用率** + + - **metrics.object.target.type** (string),必需 + + type 表示指标类别是 `Utilization`、`Value` 或 `AverageValue`。 + + + + - **metrics.object.target.averageUtilization** (int32) + + averageUtilization 是跨所有相关 Pod 得出的资源指标均值的目标值, + 表示为 Pod 资源请求值的百分比。目前仅对 “Resource” 指标源类别有效。 + + + + - **metrics.object.target.averageValue** (}}">Quantity) + + averageValue 是跨所有 Pod 得出的指标均值的目标值(以数量形式给出)。 + + + + - **metrics.object.target.value** (}}">Quantity) + + value 是指标的目标值(以数量形式给出)。 + + + + - **metrics.pods** (PodsMetricSource) + + pods 是指描述当前扩缩目标中每个 Pod 的指标(例如,`transactions-processed-per-second`)。 + 在与目标值进行比较之前,这些指标值将被平均。 + + + + + + PodsMetricSource 表示如何根据描述当前扩缩目标中每个 Pod 的指标进行扩缩容(例如,`transactions-processed-per-second`)。 + 在与目标值进行比较之前,这些指标值将被平均。 + + - **metrics.pods.metric** (MetricIdentifier),必需 + + metric 通过名称和选择算符识别目标指标。 + + + + + + **MetricIdentifier 定义指标的名称和可选的选择算符** + + - **metrics.pods.metric.name** (string),必需 + + name 是给定指标的名称。 + + + + - **metrics.pods.metric.selector** (}}">LabelSelector) + + selector 是给定指标的标准 Kubernetes 标签选择算符的字符串编码形式。 + 设置后,它作为附加参数传递给指标服务器,以获取更具体的指标范围。 + 未设置时,仅 metricName 参数将用于收集指标。 + + + + - **metrics.pods.target** (MetricTarget),必需 + + target 表示给定指标的目标值。 + + + + + + **MetricTarget 定义特定指标的目标值、平均值或平均利用率** + + - **metrics.pods.target.type** (string),必需 + + type 表示指标类别是 `Utilization`、`Value` 或 `AverageValue`。 + + + + - **metrics.pods.target.averageUtilization** (int32) + + averageUtilization 是跨所有相关 Pod 得出的资源指标均值的目标值, + 表示为 Pod 资源请求值的百分比。目前仅对 “Resource” 指标源类别有效。 + + + + - **metrics.pods.target.averageValue** (}}">Quantity) + + averageValue 是跨所有 Pod 得出的指标均值的目标值(以数量形式给出)。 + + + + - **metrics.pods.target.value** (}}">Quantity) + + value 是指标的目标值(以数量形式给出)。 + + + + - **metrics.resource** (ResourceMetricSource) + + resource 是指 Kubernetes 已知的资源指标(例如在请求和限制中指定的那些), + 此结构描述当前扩缩目标中的每个 Pod(例如 CPU 或内存)。此类指标内置于 Kubernetes 中, + 并且在使用 “Pods” 源的、按 Pod 统计的普通指标之外支持一些特殊的扩缩选项。 + + + + + + ResourceMetricSource 指示如何根据请求和限制中指定的 Kubernetes 已知的资源指标进行扩缩容, + 此结构描述当前扩缩目标中的每个 Pod(例如 CPU 或内存)。在与目标值比较之前,这些指标值将被平均。 + 此类指标内置于 Kubernetes 中,并且在使用 “Pods” 源的、按 Pod 统计的普通指标之外支持一些特殊的扩缩选项。 + 只应设置一种 “target” 类别。 + + - **metrics.resource.name** (string),必需 + + name 是相关资源的名称。 + + + + - **metrics.resource.target** (MetricTarget),必需 + + target 指定给定指标的目标值。 + + + + + + **MetricTarget 定义特定指标的目标值、平均值或平均利用率** + + - **metrics.resource.target.type** (string),必需 + + type 表示指标类别是 `Utilization`、`Value` 或 `AverageValue`。 + + + + - **metrics.resource.target.averageUtilization** (int32) + + averageUtilization 是跨所有相关 Pod 得出的资源指标均值的目标值, + 表示为 Pod 资源请求值的百分比。目前仅对 “Resource” 指标源类别有效。 + + + + - **metrics.resource.target.averageValue** (}}">Quantity) + + averageValue 是跨所有 Pod 得出的指标均值的目标值(以数量形式给出)。 + + + + - **metrics.resource.target.value** (}}">Quantity) + + value 是指标的目标值(以数量形式给出)。 + +## HorizontalPodAutoscalerStatus {#HorizontalPodAutoscalerStatus} + + +HorizontalPodAutoscalerStatus 描述了水平 Pod 自动扩缩器的当前状态。 + +
+ + + +- **desiredReplicas** (int32),必需 + + desiredReplicas 是此自动扩缩器管理的 Pod 的所期望的副本数,由自动扩缩器最后计算。 + + + +- **conditions** ([]HorizontalPodAutoscalerCondition) + + **补丁策略:基于键 `type` 合并** + + **Map:合并时将保留 type 键的唯一值** + + conditions 是此自动扩缩器扩缩其目标所需的一组条件,并指示是否满足这些条件。 + + + + + + **HorizontalPodAutoscalerCondition 描述 HorizontalPodAutoscaler 在某一时间点的状态。** + + - **conditions.status** (string),必需 + + status 是状况的状态(True、False、Unknown)。 + + + + - **conditions.type** (string),必需 + + type 描述当前状况。 + + + + - **conditions.lastTransitionTime** (Time) + + lastTransitionTime 是状况最近一次从一种状态转换到另一种状态的时间。 + + + + + **Time 是对 time.Time 的封装。Time 支持对 YAML 和 JSON 进行正确封包。为 time 包的许多函数方法提供了封装器。** + + + + - **conditions.message** (string) + + message 是一个包含有关转换的可读的详细信息。 + + + + - **conditions.reason** (string) + + reason 是状况最后一次转换的原因。 + + + +- **currentMetrics** ([]MetricStatus) + + **原子性:将在合并期间被替换** + + currentMetrics 是此自动扩缩器使用的指标的最后读取状态。 + + + + + + **MetricStatus 描述了单个指标的最后读取状态。** + + - **currentMetrics.type** (string),必需 + + type 是指标源的类别。它取值是 “ContainerResource”、“External”、“Object”、“Pods” 或 “Resource” 之一, + 每个类别映射到对象中的一个对应的字段。注意:“ContainerResource” 类别在特性门控 HPAContainerMetrics 启用时可用。 + + + + - **currentMetrics.containerResource** (ContainerResourceMetricStatus) + + containerResource 是指 Kubernetes 已知的一种资源指标(例如在请求和限制中指定的那些), + 描述当前扩缩目标中每个 Pod 中的单个容器(例如 CPU 或内存)。 + 此类指标内置于 Kubernetes 中,并且在使用 "Pods" 源的、按 Pod 统计的普通指标之外支持一些特殊的扩缩选项。 + + + + + + ContainerResourceMetricStatus 指示如何根据请求和限制中指定的 Kubernetes 已知的资源指标进行扩缩容, + 此结构描述当前扩缩目标中的每个 Pod(例如 CPU 或内存)。此类指标内置于 Kubernetes 中, + 并且在使用 “Pods” 源的、按 Pod 统计的普通指标之外支持一些特殊的扩缩选项。 + + - **currentMetrics.containerResource.container** (string),必需 + + container 是扩缩目标的 Pod 中的容器名称。 + + + + - **currentMetrics.containerResource.current** (MetricValueStatus),必需 + + current 包含给定指标的当前值。 + + + + + + **MetricValueStatus 保存指标的当前值** + + - **currentMetrics.containerResource.current.averageUtilization** (int32) + + averageUtilization 是跨所有相关 Pod 得出的资源指标均值的当前值,表示为 Pod 资源请求值的百分比。 + + + + - **currentMetrics.containerResource.current.averageValue** (}}">Quantity) + + averageValue 是跨所有相关 Pod 的指标均值的当前值(以数量形式给出)。 + + + + - **currentMetrics.containerResource.current.value** (}}">Quantity) + + value 是指标的当前值(以数量形式给出)。 + + + + - **currentMetrics.containerResource.name** (string),必需 + + name 是相关资源的名称。 + + + + - **currentMetrics.external** (ExternalMetricStatus) + + external 指的是不与任何 Kubernetes 对象关联的全局指标。这一字段允许基于来自集群外部运行的组件 + (例如云消息服务中的队列长度,或来自集群外部运行的负载均衡器的 QPS)的信息进行自动扩缩。 + + + + + + **ExternalMetricStatus 表示与任何 Kubernetes 对象无关的全局指标的当前值。** + + - **currentMetrics.external.current** (MetricValueStatus),必需 + + current 包含给定指标的当前值。 + + + + + + **MetricValueStatus 保存指标的当前值** + + - **currentMetrics.external.current.averageUtilization** (int32) + + averageUtilization 是跨所有相关 Pod 得出的资源指标均值的当前值,表示为 Pod 资源请求值的百分比。 + + + + - **currentMetrics.external.current.averageValue** (}}">Quantity) + + averageValue 是跨所有相关 Pod 的指标均值的当前值(以数量形式给出)。 + + + + - **currentMetrics.external.current.value** (}}">Quantity) + + value 是指标的当前值(以数量形式给出)。 + + + + - **currentMetrics.external.metric** (MetricIdentifier),必需 + + metric 通过名称和选择算符识别目标指标。 + + + + + + **MetricIdentifier 定义指标的名称和可选的选择算符** + + - **currentMetrics.external.metric.name** (string),必需 + + name 是给定指标的名称。 + + + + - **currentMetrics.external.metric.selector** (}}">LabelSelector) + + selector 是给定指标的标准 Kubernetes 标签选择算符的字符串编码形式。 + 设置后,它作为附加参数传递给指标服务器,以获取更具体的指标范围。 + 未设置时,仅 metricName 参数将用于收集指标。 + + + + - **currentMetrics.object** (ObjectMetricStatus) + + object 是指描述单个 Kubernetes 对象的指标(例如,Ingress 对象的 `hits-per-second`)。 + + + + + + **ObjectMetricStatus 表示描述 Kubernetes 对象的指标的当前值(例如,Ingress 对象的 `hits-per-second`)。** + + - **currentMetrics.object.current** (MetricValueStatus),必需 + + current 包含给定指标的当前值。 + + + + + + **MetricValueStatus 保存指标的当前值** + + - **currentMetrics.object.current.averageUtilization** (int32) + + averageUtilization 是跨所有相关 Pod 得出的资源指标均值的当前值,表示为 Pod 资源请求值的百分比。 + + + + - **currentMetrics.object.current.averageValue** (}}">Quantity) + + averageValue 是跨所有相关 Pod 的指标均值的当前值(以数量形式给出)。 + + + + - **currentMetrics.object.current.value** (}}">Quantity) + + value 是指标的当前值(以数量形式给出)。 + + + + - **currentMetrics.object.describedObject** (CrossVersionObjectReference),必需 + + describeObject 表示对象的描述,如对象的 `kind`、`name`、`apiVersion`。 + + + + + + **CrossVersionObjectReference 包含足够的信息来让你识别所引用的资源。** + + - **currentMetrics.object.describedObject.kind** (string),必需 + + 被引用对象的类别;更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds" + + + + - **currentMetrics.object.describedObject.name** (string),必需 + + 被引用对象的名称;更多信息: https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/names/#names + + + + - **currentMetrics.object.describedObject.apiVersion** (string) + + 被引用对象的 API 版本。 + + + + - **currentMetrics.object.metric** (MetricIdentifier),必需 + + metric 通过名称和选择算符识别目标指标。 + + + + + + **MetricIdentifier 定义指标的名称和可选的选择算符** + + - **currentMetrics.object.metric.name** (string),必需 + + name 是给定指标的名称。 + + + + - **currentMetrics.object.metric.selector** (}}">LabelSelector) + + selector 是给定指标的标准 Kubernetes 标签选择算符的字符串编码形式。 + 设置后,它作为附加参数传递给指标服务器,以获取更具体的指标范围。 + 未设置时,仅 metricName 参数将用于收集指标。 + + + + - **currentMetrics.pods** (PodsMetricStatus) + + pods 是指描述当前扩缩目标中每个 Pod 的指标(例如,`transactions-processed-per-second`)。 + 在与目标值进行比较之前,这些指标值将被平均。 + + + + + + **PodsMetricStatus 表示描述当前扩缩目标中每个 Pod 的指标的当前值(例如,`transactions-processed-per-second`)。** + + - **currentMetrics.pods.current** (MetricValueStatus),必需 + + current 包含给定指标的当前值。 + + + + + + **MetricValueStatus 保存指标的当前值** + + - **currentMetrics.pods.current.averageUtilization** (int32) + + averageUtilization 是跨所有相关 Pod 得出的资源指标均值的当前值,表示为 Pod 资源请求值的百分比。 + + + + - **currentMetrics.pods.current.averageValue** (}}">Quantity) + + averageValue 是跨所有相关 Pod 的指标均值的当前值(以数量形式给出)。 + + + + - **currentMetrics.pods.current.value** (}}">Quantity) + + value 是指标的当前值(以数量形式给出)。 + + + + - **currentMetrics.pods.metric** (MetricIdentifier),必需 + + metric 通过名称和选择算符识别目标指标。 + + + + + + **MetricIdentifier 定义指标的名称和可选的选择算符** + + - **currentMetrics.pods.metric.name** (string),必需 + + name 是给定指标的名称。 + + + + - **currentMetrics.pods.metric.selector** (}}">LabelSelector) + + selector 是给定指标的标准 Kubernetes 标签选择算符的字符串编码形式。 + 设置后,它作为附加参数传递给指标服务器,以获取更具体的指标范围。 + 未设置时,仅 metricName 参数将用于收集指标。 + + + + - **currentMetrics.resource** (ResourceMetricStatus) + + resource 是指 Kubernetes 已知的资源指标(例如在请求和限制中指定的那些), + 此结构描述当前扩缩目标中的每个 Pod(例如 CPU 或内存)。此类指标内置于 Kubernetes 中, + 并且在使用 “Pods” 源的、按 Pod 统计的普通指标之外支持一些特殊的扩缩选项。 + + + + + + ResourceMetricSource 指示如何根据请求和限制中指定的 Kubernetes 已知的资源指标进行扩缩容, + 此结构描述当前扩缩目标中的每个 Pod(例如 CPU 或内存)。在与目标值比较之前,这些指标值将被平均。 + 此类指标内置于 Kubernetes 中,并且在使用 “Pods” 源的、按 Pod 统计的普通指标之外支持一些特殊的扩缩选项。 + + - **currentMetrics.resource.current** (MetricValueStatus),必需 + + current 包含给定指标的当前值。 + + + + + + **MetricValueStatus 保存指标的当前值** + + - **currentMetrics.resource.current.averageUtilization** (int32) + + averageUtilization 是跨所有相关 Pod 得出的资源指标均值的当前值, + 表示为 Pod 资源请求值的百分比。 + + + + - **currentMetrics.resource.current.averageValue** (}}">Quantity) + + averageValue 是跨所有相关 Pod 的指标均值的当前值(以数量形式给出)。 + + + + - **currentMetrics.resource.current.value** (}}">Quantity) + + value 是指标的当前值(以数量形式给出)。 + + + + - **currentMetrics.resource.name** (string),必需 + + name 是相关资源的名称。 + + + +- **currentReplicas** (int32) + + currentReplicas 是此自动扩缩器管理的 Pod 的当前副本数,如自动扩缩器最后一次看到的那样。 + + + +- **lastScaleTime** (Time) + + lastScaleTime 是 HorizontalPodAutoscaler 上次扩缩 Pod 数量的时间,自动扩缩器使用它来控制更改 Pod 数量的频率。 + + + + + + **Time 是对 time.Time 的封装。Time 支持对 YAML 和 JSON 进行正确封包。为 time 包的许多函数方法提供了封装器。** + + + +- **observedGeneration** (int64) + + observedGeneration 是此自动扩缩器观察到的最新一代。 + +## HorizontalPodAutoscalerList {#HorizontalPodAutoscalerList} + + +HorizontalPodAutoscalerList 是水平 Pod 自动扩缩器对象列表。 + +
+ +- **apiVersion**: autoscaling/v2 + +- **kind**: HorizontalPodAutoscalerList + + + +- **metadata** (}}">ListMeta) + + metadata 是标准的列表元数据。 + + + +- **items** ([]}}">HorizontalPodAutoscaler), required + + items 是水平 Pod 自动扩缩器对象的列表。 + +## Operations {#Operations} + +
+ + +### `get` 读取指定的 HorizontalPodAutoscaler + +#### HTTP 请求 + +GET /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name} + + +#### 参数 + +- **name** (**路径参数**): string,必需 + + HorizontalPodAutoscaler 的名称。 + + +- **namespace** (**路径参数**): string,必需 + + }}">namespace + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">HorizontalPodAutoscaler): OK + +401: Unauthorized + + +### `get` 读取指定 HorizontalPodAutoscaler 的状态 + +#### HTTP 请求 + +GET /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}/status + + +#### 参数 + +- **name** (**路径参数**): string,必需 + + HorizontalPodAutoscaler 的名称。 + + +- **namespace** (**路径参数**): string,必需 + + }}">namespace + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">HorizontalPodAutoscaler): OK + +401: Unauthorized + + +### `list` 列出或观察 HorizontalPodAutoscaler 类别的对象 + +#### HTTP 请求 + +GET /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers + + +#### 参数 + +- **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 (}}">HorizontalPodAutoscalerList): OK + +401: Unauthorized + + +### `list` 列出或观察 HorizontalPodAutoscaler 类别的对象 + +#### HTTP 请求 + +GET /apis/autoscaling/v2/horizontalpodautoscalers + + +#### 参数 + +- **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 (}}">HorizontalPodAutoscalerList): OK + +401: Unauthorized + + +### `create` 创建一个 HorizontalPodAutoscaler + +#### HTTP 请求 + +POST /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers + + +#### 参数 + +- **namespace** (**路径参数**): string,必需 + + }}">namespace + +- **body**: }}">HorizontalPodAutoscaler必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">HorizontalPodAutoscaler): OK + +201 (}}">HorizontalPodAutoscaler): Created + +202 (}}">HorizontalPodAutoscaler): Accepted + +401: Unauthorized + + +### `update` 替换指定的 HorizontalPodAutoscaler + +#### HTTP 请求 + +PUT /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name} + + +#### 参数 + +- **name** (**路径参数**): string,必需 + + HorizontalPodAutoscaler 的名称。 + + +- **namespace** (**路径参数**): string,必需 + + }}">namespace + +- **body**: }}">HorizontalPodAutoscaler必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">HorizontalPodAutoscaler): OK + +201 (}}">HorizontalPodAutoscaler): Created + +401: Unauthorized + + +### `update` 替换指定 HorizontalPodAutoscaler 的状态 + +#### HTTP 请求 + +PUT /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}/status + + +#### 参数 + +- **name** (**路径参数**): string,必需 + + HorizontalPodAutoscaler 的名称。 + + +- **namespace** (**路径参数**): string,必需 + + }}">namespace + +- **body**: }}">HorizontalPodAutoscaler必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">HorizontalPodAutoscaler): OK + +201 (}}">HorizontalPodAutoscaler): Created + +401: Unauthorized + + +### `patch` 部分更新指定的 HorizontalPodAutoscaler + +#### HTTP 请求 + +PATCH /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name} + + +#### 参数 + +- **name** (**路径参数**): string,必需 + + HorizontalPodAutoscaler 的名称。 + + +- **namespace** (**路径参数**): string,必需 + + }}">namespace + +- **body**: }}">Patch必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **force** (**查询参数**): boolean + + }}">force + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">HorizontalPodAutoscaler): OK + +201 (}}">HorizontalPodAutoscaler): Created + +401: Unauthorized + + +### `patch` 部分更新指定 HorizontalPodAutoscaler 的状态 + +#### HTTP 请求 + +PATCH /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}/status + + +#### 参数 + +- **name** (**路径参数**): string,必需 + + HorizontalPodAutoscaler 的名称。 + + +- **namespace** (**路径参数**): string,必需 + + }}">namespace + +- **body**: }}">Patch必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **force** (**查询参数**): boolean + + }}">force + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">HorizontalPodAutoscaler): OK + +201 (}}">HorizontalPodAutoscaler): Created + +401: Unauthorized + + +### `delete` 删除一个 HorizontalPodAutoscaler + +#### HTTP 请求 + +DELETE /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name} + + +#### 参数 + +- **name** (**路径参数**): string,必需 + + HorizontalPodAutoscaler 的名称。 + + +- **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` 删除 HorizontalPodAutoscaler 的集合 + +#### HTTP 请求 + +DELETE /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers + + +#### 参数 + +- **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 + diff --git a/content/zh-cn/docs/reference/using-api/_index.md b/content/zh-cn/docs/reference/using-api/_index.md index 3d39084395acd..e4a7b86e5cca7 100644 --- a/content/zh-cn/docs/reference/using-api/_index.md +++ b/content/zh-cn/docs/reference/using-api/_index.md @@ -59,11 +59,11 @@ JSON 和 Protobuf 序列化模式遵循相同的模式更改原则。 API 版本控制和软件版本控制是间接相关的。 -[API 和发布版本控制提案](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) +[API 和发布版本控制提案](https://git.k8s.io/sig-release/release-engineering/versioning.md) 描述了 API 版本控制和软件版本控制间的关系。 -[API 组](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md) +[API 组](https://git.k8s.io/design-proposals-archive/api-machinery/api-group.md) 能够简化对 Kubernetes API 的扩展。 API 组信息出现在REST 路径中,也出现在序列化对象的 `apiVersion` 字段中。 diff --git a/content/zh-cn/docs/setup/production-environment/_index.md b/content/zh-cn/docs/setup/production-environment/_index.md index f48e83fa4600d..0bcee800d786a 100644 --- a/content/zh-cn/docs/setup/production-environment/_index.md +++ b/content/zh-cn/docs/setup/production-environment/_index.md @@ -53,7 +53,7 @@ has a single point of failure. Creating a highly available cluster means conside - 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. --> -- *可用性*:一个单机的 Kubernetes [学习环境](/zh-cn/docs/setup/#学习环境) +- **可用性**:一个单机的 Kubernetes [学习环境](/zh-cn/docs/setup/#学习环境) 具有单点失效特点。创建高可用的集群则意味着需要考虑: - 将控制面与工作节点分开 - 在多个节点上提供控制面组件的副本 @@ -69,7 +69,7 @@ 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. --> -- *规模*:如果你预期你的生产用 Kubernetes 环境要承受固定量的请求, +- **规模**:如果你预期你的生产用 Kubernetes 环境要承受固定量的请求, 你可能可以针对所需要的容量来一次性完成安装。 不过,如果你预期服务请求会随着时间增长,或者因为类似季节或者特殊事件的 原因而发生剧烈变化,你就需要规划如何处理请求上升时对控制面和工作节点 @@ -87,7 +87,7 @@ 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 集群上,你拥有完全的管理员特权。 +- **安全性与访问管理**:在你自己的学习环境 Kubernetes 集群上,你拥有完全的管理员特权。 但是针对运行着重要工作负载的共享集群,用户账户不止一两个时,就需要更细粒度 的方案来确定谁或者哪些主体可以访问集群资源。 你可以使用基于角色的访问控制([RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/)) @@ -122,12 +122,12 @@ upgrades when needed. services you may need, such as storage, container registries, authentication methods, and development tools. --> -- *无服务*:仅是在第三方设备上运行负载,完全不必管理集群本身。你需要为 +- **无服务**:仅是在第三方设备上运行负载,完全不必管理集群本身。你需要为 CPU 用量、内存和磁盘请求等付费。 -- *托管控制面*:让供应商决定集群控制面的规模和可用性,并负责打补丁和升级等操作。 -- *托管工作节点*:配置一个节点池来满足你的需要,由供应商来确保节点始终可用, +- **托管控制面**:让供应商决定集群控制面的规模和可用性,并负责打补丁和升级等操作。 +- **托管工作节点**:配置一个节点池来满足你的需要,由供应商来确保节点始终可用, 并在需要的时候完成升级。 -- *集成*:有一些供应商能够将 Kubernetes 与一些你可能需要的其他服务集成, +- **集成**:有一些供应商能够将 Kubernetes 与一些你可能需要的其他服务集成, 这类服务包括存储、容器镜像仓库、身份认证方法以及开发工具等。 -- *选择部署工具*:你可以使用类似 kubeadm、kops 和 kubespray 这类工具来部署控制面。 +- **选择部署工具**:你可以使用类似 kubeadm、kops 和 kubespray 这类工具来部署控制面。 参阅[使用部署工具安装 Kubernetes](/zh-cn/docs/setup/production-environment/tools/) 以了解使用这类部署方法来完成生产就绪部署的技巧。 存在不同的[容器运行时](/zh-cn/docs/setup/production-environment/container-runtimes/) @@ -204,7 +204,7 @@ 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. --> -- *管理证书*:控制面服务之间的安全通信是通过证书来完成的。证书是在部署期间 +- **管理证书**:控制面服务之间的安全通信是通过证书来完成的。证书是在部署期间 自动生成的,或者你也可以使用自己的证书机构来生成它们。 参阅 [PKI 证书和需求](/zh-cn/docs/setup/best-practices/certificates/)了解细节。 -- *为 API 服务器配置负载均衡*:配置负载均衡器来将外部的 API 请求散布给运行在 +- **为 API 服务器配置负载均衡**:配置负载均衡器来将外部的 API 请求散布给运行在 不同节点上的 API 服务实例。参阅 [创建外部负载均衡器](/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer/) 了解细节。 @@ -228,7 +228,7 @@ See [Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/conf and [Set up a High Availability etcd cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) for details. --> -- *分离并备份 etcd 服务*:etcd 服务可以运行于其他控制面服务所在的机器上, +- **分离并备份 etcd 服务**:etcd 服务可以运行于其他控制面服务所在的机器上, 也可以运行在不同的机器上以获得更好的安全性和可用性。 因为 etcd 存储着集群的配置数据,应该经常性地对 etcd 数据库进行备份, 以确保在需要的时候你可以修复该数据库。与配置和使用 etcd 相关的细节可参阅 @@ -247,7 +247,7 @@ but not highly available. Some deployment tools set up [Raft](https://raft.githu consensus algorithm to do leader election of Kubernetes services. If the primary goes away, another service elects itself and take over. --> -- *创建多控制面系统*:为了实现高可用性,控制面不应被限制在一台机器上。 +- **创建多控制面系统**:为了实现高可用性,控制面不应被限制在一台机器上。 如果控制面服务是使用某 init 服务(例如 systemd)来运行的,每个服务应该 至少运行在三台机器上。不过,将控制面作为服务运行在 Kubernetes Pods 中可以确保你所请求的个数的服务始终保持可用。 @@ -263,7 +263,7 @@ 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. --> -- *跨多个可用区*:如果保持你的集群一直可用这点非常重要,可以考虑创建一个跨 +- **跨多个可用区**:如果保持你的集群一直可用这点非常重要,可以考虑创建一个跨 多个数据中心的集群;在云环境中,这些数据中心被视为可用区。 若干个可用区在一起可构成地理区域。 通过将集群分散到同一区域中的多个可用区内,即使某个可用区不可用,整个集群 @@ -278,7 +278,7 @@ and [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm- See [Administer a Cluster](/docs/tasks/administer-cluster/) for a longer list of Kubernetes administrative tasks. --> -- *管理演进中的特性*:如果你计划长时间保留你的集群,就需要执行一些维护其 +- **管理演进中的特性**:如果你计划长时间保留你的集群,就需要执行一些维护其 健康和安全的任务。例如,如果你采用 kubeadm 安装的集群,则有一些可以帮助你完成 [证书管理](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) 和[升级 kubeadm 集群](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade) @@ -330,7 +330,7 @@ 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: --> -- *配置节点*:节点可以是物理机或者虚拟机。如果你希望自行创建和管理节点, +- **配置节点**:节点可以是物理机或者虚拟机。如果你希望自行创建和管理节点, 你可以安装一个受支持的操作系统,之后添加并运行合适的 [节点服务](/zh-cn/docs/concepts/overview/components/#node-components)。 考虑: @@ -347,7 +347,7 @@ then add and run the appropriate for information on how to ensure that a node meets the requirements to join a Kubernetes cluster. --> -- *验证节点*:参阅[验证节点配置](/zh-cn/docs/setup/best-practices/node-conformance/) +- **验证节点**:参阅[验证节点配置](/zh-cn/docs/setup/best-practices/node-conformance/) 以了解如何确保节点满足加入到 Kubernetes 集群的需求。 -- *添加节点到集群中*:如果你自行管理你的集群,你可以通过安装配置你的机器, +- **添加节点到集群中**:如果你自行管理你的集群,你可以通过安装配置你的机器, 之后或者手动加入集群,或者让它们自动注册到集群的 API 服务器。参阅 [节点](/zh-cn/docs/concepts/architecture/nodes/)节,了解如何配置 Kubernetes 以便以这些方式来添加节点。 @@ -366,7 +366,7 @@ 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. --> -- *扩缩节点*:制定一个扩充集群容量的规划,你的集群最终会需要这一能力。 +- **扩缩节点**:制定一个扩充集群容量的规划,你的集群最终会需要这一能力。 参阅[大规模集群考察事项](/zh-cn/docs/setup/best-practices/cluster-large/) 以确定你所需要的节点数;这一规模是基于你要运行的 Pod 和容器个数来确定的。 如果你自行管理集群节点,这可能意味着要购买和安装你自己的物理设备。 @@ -381,7 +381,7 @@ 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) 以便替换不健康的节点、根据需求来增加或缩减节点个数。参阅 [常见问题](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md) @@ -436,7 +436,7 @@ 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. --> -- *认证(Authentication)*:API 服务器可以使用客户端证书、持有者令牌、身份 +- **认证(Authentication)**:API 服务器可以使用客户端证书、持有者令牌、身份 认证代理或者 HTTP 基本认证机制来完成身份认证操作。 你可以选择你要使用的认证方法。通过使用插件,API 服务器可以充分利用你所在 组织的现有身份认证方法,例如 LDAP 或者 Kerberos。 @@ -445,14 +445,14 @@ for a description of these different methods of authenticating Kubernetes users. -- *鉴权(Authorization)*:当你准备为一般用户执行权限判定时,你可能会需要 +- **鉴权(Authorization)**:当你准备为一般用户执行权限判定时,你可能会需要 在 RBAC 和 ABAC 鉴权机制之间做出选择。参阅 [鉴权概述](/zh-cn/docs/reference/access-authn-authz/authorization/),了解 对用户账户(以及访问你的集群的服务账户)执行鉴权的不同模式。 - - *基于角色的访问控制*([RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/)): + - **基于角色的访问控制**([RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/)): 让你通过为通过身份认证的用户授权特定的许可集合来控制集群访问。 访问许可可以针对某特定名字空间(Role)或者针对整个集群(ClusterRole)。 通过使用 RoleBinding 和 ClusterRoleBinding 对象,这些访问许可可以被 @@ -460,11 +460,11 @@ for a description of these different methods of authenticating Kubernetes users. - - *基于属性的访问控制*([ABAC](/zh-cn/docs/reference/access-authn-authz/abac/)): + - **基于属性的访问控制**([ABAC](/zh-cn/docs/reference/access-authn-authz/abac/)): 让你能够基于集群中资源的属性来创建访问控制策略,基于对应的属性来决定 允许还是拒绝访问。策略文件的每一行都给出版本属性(apiVersion 和 kind) 以及一个规约属性的映射,用来匹配主体(用户或组)、资源属性、非资源属性 - (/version 或 /apis)和只读属性。 + (/version 或/apis)和只读属性。 参阅[示例](/zh-cn/docs/reference/access-authn-authz/abac/#examples)以了解细节。 -- *设置鉴权模式*:当 Kubernetes API 服务器 +- **设置鉴权模式**:当 Kubernetes API 服务器 ([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)) 启动时,所支持的鉴权模式必须使用 `--authorization-mode` 标志配置。 例如,`kube-apiserver.yaml`(位于 `/etc/kubernetes/manifests` 下)中对应的 @@ -493,7 +493,7 @@ 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. --> -- *创建用户证书和角色绑定(RBAC)*:如果你在使用 RBAC 鉴权,用户可以创建 +- **创建用户证书和角色绑定(RBAC)**:如果你在使用 RBAC 鉴权,用户可以创建 由集群 CA 签名的 CertificateSigningRequest(CSR)。接下来你就可以将 Role 和 ClusterRole 绑定到每个用户身上。 参阅[证书签名请求](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/) @@ -505,7 +505,7 @@ 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). --> -- *创建组合属性的策略(ABAC)*:如果你在使用 ABAC 鉴权,你可以设置属性组合 +- **创建组合属性的策略(ABAC)**:如果你在使用 ABAC 鉴权,你可以设置属性组合 以构造策略对所选用户或用户组执行鉴权,判定他们是否可访问特定的资源 (例如 Pod)、名字空间或者 apiGroup。进一步的详细信息可参阅 [示例](/zh-cn/docs/reference/access-authn-authz/abac/#examples)。 @@ -517,7 +517,7 @@ 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. --> -- *考虑准入控制器*:针对指向 API 服务器的请求的其他鉴权形式还包括 +- **考虑准入控制器**:针对指向 API 服务器的请求的其他鉴权形式还包括 [Webhook 令牌认证](/zh-cn/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)。 Webhook 和其他特殊的鉴权类型需要通过向 API 服务器添加 [准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/) @@ -542,7 +542,7 @@ for details. You can also set [Hierarchical Namespaces](/blog/2020/08/14/introducing-hierarchical-namespaces/) for inheriting limits. --> -- *设置名字空间限制*:为每个名字空间的内存和 CPU 设置配额。 +- **设置名字空间限制**:为每个名字空间的内存和 CPU 设置配额。 参阅[管理内存、CPU 和 API 资源](/zh-cn/docs/tasks/administer-cluster/manage-resources/) 以了解细节。你也可以设置 [层次化名字空间](/blog/2020/08/14/introducing-hierarchical-namespaces/) @@ -552,7 +552,7 @@ for inheriting limits. 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/). --> -- *为 DNS 请求做准备*:如果你希望工作负载能够完成大规模扩展,你的 DNS 服务 +- **为 DNS 请求做准备**:如果你希望工作负载能够完成大规模扩展,你的 DNS 服务 也必须能够扩大规模。参阅 [自动扩缩集群中 DNS 服务](/zh-cn/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)。 -- *创建额外的服务账户*:用户账户决定用户可以在集群上执行的操作,服务账号则定义的 +- **创建额外的服务账户**:用户账户决定用户可以在集群上执行的操作,服务账号则定义的 是在特定名字空间中 Pod 的访问权限。 默认情况下,Pod 使用所在名字空间中的 default 服务账号。 参阅[管理服务账号](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/) diff --git a/content/zh-cn/docs/setup/production-environment/tools/kubespray.md b/content/zh-cn/docs/setup/production-environment/tools/kubespray.md index 0f17c9281f715..c051dfeff5288 100644 --- a/content/zh-cn/docs/setup/production-environment/tools/kubespray.md +++ b/content/zh-cn/docs/setup/production-environment/tools/kubespray.md @@ -30,10 +30,10 @@ Kubespray 提供: * a highly available cluster * composable attributes * support for most popular Linux distributions - * Ubuntu 16.04, 18.04, 20.04 + * Ubuntu 16.04, 18.04, 20.04, 22.04 * CentOS/RHEL/Oracle Linux 7, 8 * Debian Buster, Jessie, Stretch, Wheezy - * Fedora 31, 32 + * Fedora 34, 35 * Fedora CoreOS * openSUSE Leap 15 * Flatcar Container Linux by Kinvolk @@ -42,10 +42,10 @@ Kubespray 提供: * 高可用性集群 * 可组合属性 * 支持大多数流行的 Linux 发行版 - * Ubuntu 16.04、18.04、20.04 + * Ubuntu 16.04、18.04、20.04, 22.04 * CentOS / RHEL / Oracle Linux 7、8 * Debian Buster、Jessie、Stretch、Wheezy - * Fedora 31、32 + * Fedora 34、35 * Fedora CoreOS * openSUSE Leap 15 * Kinvolk 的 Flatcar Container Linux @@ -59,7 +59,7 @@ To choose a tool which best fits your use case, read [this comparison](https://g [kubeadm](/zh-cn/docs/reference/setup-tools/kubeadm/) 和 [kops](/zh-cn/docs/setup/production-environment/tools/kops/) 之间的 [这份比较](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md)。 - 。 + -* 在将运行 Ansible 命令的计算机上安装 Ansible v2.9 和 python-netaddr +* 在将运行 Ansible 命令的计算机上安装 Ansible v2.11 和 python-netaddr * **运行 Ansible Playbook 需要 Jinja 2.11(或更高版本)** * 目标服务器必须有权访问 Internet 才能拉取 Docker 镜像。否则, 需要其他配置([请参见离线环境](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)) @@ -240,7 +240,7 @@ When running the reset playbook, be sure not to accidentally target your product --> ## 清理 -你可以通过 [reset](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml) Playbook +你可以通过 [reset playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml) 重置节点并清除所有与 Kubespray 一起安装的组件。 {{< caution >}} diff --git a/content/zh-cn/docs/tasks/administer-cluster/kubelet-in-userns.md b/content/zh-cn/docs/tasks/administer-cluster/kubelet-in-userns.md index 8f456e8058d9e..bc6d34c7426ea 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/kubelet-in-userns.md +++ b/content/zh-cn/docs/tasks/administer-cluster/kubelet-in-userns.md @@ -1,15 +1,13 @@ --- -title: 以非root用户身份运行 Kubernetes 节点组件 +title: 以非 root 用户身份运行 Kubernetes 节点组件 content_type: task min-kubernetes-server-version: 1.22 --- @@ -32,7 +30,7 @@ If you are just looking for how to run a pod as a non-root user, see [SecurityCo 这个文档描述了怎样不使用 root 特权,而是通过使用 {{< glossary_tooltip text="用户命名空间" term_id="userns" >}} 去运行 Kubernetes 节点组件(例如 kubelet、CRI、OCI、CNI)。 -这种技术也叫做 _rootless 模式(Rootless mode)_。 +这种技术也叫做 **rootless 模式(Rootless mode)**。 {{< note >}} 这个文档描述了怎么以非 root 用户身份运行 Kubernetes 节点组件以及 Pod。 @@ -55,7 +53,7 @@ If you are just looking for how to run a pod as a non-root user, see [SecurityCo {{% version-check %}} -* [启用 Cgroup v2](https://rootlesscontaine.rs/getting-started/common/cgroup2/) +* [启用 cgroup v2](https://rootlesscontaine.rs/getting-started/common/cgroup2/) * [在 systemd 中启用 user session](https://rootlesscontaine.rs/getting-started/common/login/) * [根据不同的 Linux 发行版,配置 sysctl 的值](https://rootlesscontaine.rs/getting-started/common/sysctl/) * [确保你的非特权用户被列在 `/etc/subuid` 和 `/etc/subgid` 文件中](https://rootlesscontaine.rs/getting-started/common/subuid/) @@ -74,11 +72,12 @@ See [Running kind with Rootless Docker](https://kind.sigs.k8s.io/docs/user/rootl ### minikube -[minikube](https://minikube.sigs.k8s.io/) also supports running Kubernetes inside Rootless Docker. +[minikube](https://minikube.sigs.k8s.io/) also supports running Kubernetes inside Rootless Docker or Rootless Podman. -See the page about the [docker](https://minikube.sigs.k8s.io/docs/drivers/docker/) driver in the Minikube documentation. +See the Minikube documentation: -Rootless Podman is not supported. +* [Rootless Docker](https://minikube.sigs.k8s.io/docs/drivers/docker/) +* [Rootless Podman](https://minikube.sigs.k8s.io/docs/drivers/podman/) --> ## 使用 Rootless 模式的 Docker/Podman 运行 Kubernetes @@ -91,13 +90,12 @@ Rootless Podman is not supported. ### minikube -[minikube](https://minikube.sigs.k8s.io/) 也支持使用 Rootless 模式的 Docker 运行 Kubernetes。 - -请参阅 Minikube 文档中的 [docker](https://minikube.sigs.k8s.io/docs/drivers/docker/) 驱动页面。 +[minikube](https://minikube.sigs.k8s.io/) 也支持使用 Rootless 模式的 Docker 或 Podman 运行 Kubernetes。 -它不支持 Rootless 模式的 Podman。 +请参阅 Minikube 文档: - +* [Rootless Docker](https://minikube.sigs.k8s.io/docs/drivers/docker/) +* [Rootless Podman](https://minikube.sigs.k8s.io/docs/drivers/podman/) Sysbox 支持在非特权容器内运行 Kubernetes, -而不需要 Cgroup v2 和 “KubeletInUserNamespace” 特性门控。 +而不需要 cgroup v2 和 “KubeletInUserNamespace” 特性门控。 Sysbox 通过在容器内暴露特定的 `/proc` 和 `/sys` 文件系统, 以及其它一些先进的操作系统虚拟化技术来实现。 @@ -251,18 +249,18 @@ At least, the following directories need to be writable *in* the namespace (not 在取消命名空间的共享之后,你也必须对其它的命名空间例如 mount 命名空间取消共享。 -在取消 mount 命名空间的共享之后,你*不*需要调用 `chroot()` 或者 `pivot_root()`, -但是你必须*在这个命名空间内*挂载可写的文件系统到几个目录上。 +在取消 mount 命名空间的共享之后,你**不**需要调用 `chroot()` 或者 `pivot_root()`, +但是你必须**在这个命名空间内**挂载可写的文件系统到几个目录上。 -请确保*这个命名空间内*(不是这个命名空间外部)至少以下几个目录是可写的: +请确保**这个命名空间内**(不是这个命名空间外部)至少以下几个目录是可写的: - `/etc` - `/run` - `/var/logs` - `/var/lib/kubelet` - `/var/lib/cni` -- `/var/lib/containerd` (参照 containerd ) -- `/var/lib/containers` (参照 CRI-O ) +- `/var/lib/containerd` (参照 containerd) +- `/var/lib/containers` (参照 CRI-O) -此示例演示了如何限制一个名字空间中的存储使用量。 +此示例演示如何限制一个名字空间中的存储使用量。 -演示中用到了以下资源:[ResourceQuota](/zh-cn/docs/concepts/policy/resource-quotas/), +演示中用到了以下资源:[ResourceQuota](/zh-cn/docs/concepts/policy/resource-quotas/)、 [LimitRange](/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) 和 [PersistentVolumeClaim](/zh-cn/docs/concepts/storage/persistent-volumes/)。 @@ -32,18 +32,18 @@ and [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/). -## 场景:限制存储消耗 +## 场景:限制存储使用量 -集群管理员代表用户群操作集群,管理员希望控制单个名称空间可以消耗多少存储空间以控制成本。 +集群管理员代表用户群操作集群,该管理员希望控制单个名字空间可以消耗多少存储空间以控制成本。 -管理员想要限制: +该管理员想要限制: -管理员可以限制某个名字空间中的 PVCs 个数以及这些 PVCs 的累计容量。 -新 PVCs 请求如果超过任一上限值将被拒绝。 +管理员可以限制某个名字空间中的 PVC 个数以及这些 PVC 的累计容量。 +如果 PVC 的数目超过任一上限值,新的 PVC 将被拒绝。 在此示例中,名字空间中的第 6 个 PVC 将被拒绝,因为它超过了最大计数 5。 -或者,当与上面的 2Gi 最大容量限制结合在一起时,意味着 5Gi 的最大配额 -不能支持 3 个都是 2Gi 的 PVC。 -后者实际上是向名字空间请求 6Gi 容量,而该命令空间已经设置上限为 5Gi。 +或者,当与上面的 2Gi 最大容量限制结合在一起时, +意味着 5Gi 的最大配额不能支持 3 个都是 2Gi 的 PVC。 +后者实际上是向名字空间请求 6Gi 容量,而该名字空间已经设置上限为 5Gi。 ```yaml apiVersion: v1 diff --git a/content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors.md b/content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors.md index e60db86be82ea..d7b6e3174ddfc 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors.md +++ b/content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors.md @@ -23,18 +23,6 @@ Kubernetes. 为了避免 CNI 插件相关的错误,需要验证你正在使用或升级到一个经过测试的容器运行时, 该容器运行时能够在你的 Kubernetes 版本上正常工作。 - - -例如,针对 Kubernetes v1.24 而言,以下容器运行时正在准备或已经就绪: - -* containerd v1.6.4 及更新版本、v1.5.11 及更新版本 -* CRI-O v1.24.0 及更新版本 - diff --git a/content/zh-cn/docs/tasks/administer-cluster/namespaces.md b/content/zh-cn/docs/tasks/administer-cluster/namespaces.md index e8a2e0174fe46..358a4092ce234 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/namespaces.md +++ b/content/zh-cn/docs/tasks/administer-cluster/namespaces.md @@ -24,9 +24,9 @@ This page shows how to view, work in, and delete {{< glossary_tooltip text="name * You have a basic understanding of Kubernetes {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip term_id="service" text="Services" >}}, and {{< glossary_tooltip text="Deployments" term_id="deployment" >}}. --> * 你已拥有一个[配置好的 Kubernetes 集群](/zh-cn/docs/setup/)。 -* 你已对 Kubernetes 的 {{< glossary_tooltip text="Pods" term_id="pod" >}} , - {{< glossary_tooltip term_id="service" text="Services" >}} , 和 - {{< glossary_tooltip text="Deployments" term_id="deployment" >}} 有基本理解。 +* 你已对 Kubernetes 的 {{< glossary_tooltip text="Pod" term_id="pod" >}}、 + {{< glossary_tooltip term_id="service" text="Service" >}} 和 + {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 有基本理解。 @@ -91,16 +91,18 @@ Resource Limits -资源配额跟踪并聚合 *Namespace* 中资源的使用情况,并允许集群运营者定义 *Namespace* 可能消耗的 *Hard* 资源使用限制。 +资源配额跟踪并聚合 **Namespace** 中资源的使用情况,并允许集群运营者定义 **Namespace** 可能消耗的 **Hard** 资源使用限制。 - +See [Admission control: Limit Range](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md) +--> -限制区间定义了单个实体在一个 *Namespace* 中可使用的最小/最大资源量约束。 +限制区间定义了单个实体在一个 **Namespace** 中可使用的最小/最大资源量约束。 -参阅 [准入控制: 限制区间](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) +参阅 [准入控制:限制区间](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)。 +--> 名字空间可以处于下列两个阶段中的一个: * `Active` 名字空间正在被使用中 * `Terminating` 名字空间正在被删除,且不能被用于新对象。 -更多细节,参阅 API 参考中的[命名空间](/docs/reference/kubernetes-api/cluster-resources/namespace-v1/)。 +更多细节,参阅 API 参考中的[命名空间](/zh-cn/docs/reference/kubernetes-api/cluster-resources/namespace-v1/)。 ## 创建名字空间 @@ -165,11 +167,14 @@ The name of your namespace must be a valid -可选字段 `finalizers` 允许观察者们在名字空间被删除时清除资源。记住如果指定了一个不存在的终结器,名字空间仍会被创建,但如果用户试图删除它,它将陷入 `Terminating` 状态。 +可选字段 `finalizers` 允许观察者们在名字空间被删除时清除资源。 +记住如果指定了一个不存在的终结器,名字空间仍会被创建, +但如果用户试图删除它,它将陷入 `Terminating` 状态。 -更多有关 `finalizers` 的信息请查阅 [设计文档](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers) 中名字空间部分。 +更多有关 `finalizers` 的信息请查阅 +[设计文档](https://git.k8s.io/design-proposals-archive/architecture/namespaces.md#finalizers)中名字空间部分。 ## 删除名字空间 @@ -185,7 +190,7 @@ kubectl delete namespaces {{< warning >}} -这会删除名字空间下的 _所有内容_ ! +这会删除名字空间下的 **所有内容** ! {{< /warning >}} @@ -206,13 +211,13 @@ kubectl delete namespaces 1. 理解 default 名字空间 默认情况下,Kubernetes 集群会在配置集群时实例化一个 default 名字空间,用以存放集群所使用的默认 - Pods、Services 和 Deployments 集合。 + Pod、Service 和 Deployment 集合。 - 假设你有一个新的集群,你可以通过执行以下操作来内省可用的名字空间 + 假设你有一个新的集群,你可以通过执行以下操作来内省可用的名字空间: ```shell kubectl get namespaces @@ -245,8 +250,8 @@ kubectl delete namespaces and go, and the restrictions on who can or cannot modify resources are relaxed to enable agile development. --> - 开发团队希望在集群中维护一个空间,以便他们可以查看用于构建和运行其应用程序的 Pods、Services - 和 Deployments 列表。在这个空间里,Kubernetes 资源被自由地加入或移除, + 开发团队希望在集群中维护一个空间,以便他们可以查看用于构建和运行其应用程序的 Pod、Service + 和 Deployment 列表。在这个空间里,Kubernetes 资源被自由地加入或移除, 对谁能够或不能修改资源的限制被放宽,以实现敏捷开发。 运维团队希望在集群中维护一个空间,以便他们可以强制实施一些严格的规程, - 对谁可以或不可以操作运行生产站点的 Pods、Services 和 Deployments 集合进行控制。 + 对谁可以或不可以操作运行生产站点的 Pod、Service 和 Deployment 集合进行控制。 - 该组织可以遵循的一种模式是将 Kubernetes 集群划分为两个名字空间:development 和 production。 + 该组织可以遵循的一种模式是将 Kubernetes 集群划分为两个名字空间:`development` 和 `production`。 让我们创建两个新的名字空间来保存我们的工作。 @@ -294,14 +299,14 @@ kubectl delete namespaces ``` -3. 在每个名字空间中创建 pod +3. 在每个名字空间中创建 Pod - Kubernetes 名字空间为集群中的 Pods、Services 和 Deployments 提供了作用域。 + Kubernetes 名字空间为集群中的 Pod、Service 和 Deployment 提供了作用域。 与一个名字空间交互的用户不会看到另一个名字空间中的内容。 @@ -346,8 +351,8 @@ kubectl delete namespaces 看起来还不错,开发人员能够做他们想做的事,而且他们不必担心会影响到 `production` 名字空间下面的内容。 - 让我们切换到 `production` 名字空间,展示一下一个名字空间中的资源是如何对 - 另一个名字空间隐藏的。 + 让我们切换到 `production` 名字空间, + 展示一下一个名字空间中的资源是如何对另一个名字空间隐藏的。 名字空间 `production` 应该是空的,下面的命令应该不会返回任何东西。 @@ -387,7 +392,7 @@ kubectl delete namespaces -此时,应该很清楚的展示了用户在一个名字空间中创建的资源对另一个名字空间是隐藏的。 +此时,应该很清楚地展示了用户在一个名字空间中创建的资源对另一个名字空间是隐藏的。 -Kubernetes _名字空间_ 帮助不同的项目、团队或客户去共享 Kubernetes 集群。 +Kubernetes **名字空间** 帮助不同的项目、团队或客户去共享 Kubernetes 集群。 每个用户社区都有自己的: -1. 资源(pods、服务、 副本控制器等等) +1. 资源(Pod、服务、副本控制器等等) 2. 策略(谁能或不能在他们的社区里执行操作) -3. 约束(该社区允许多少配额,等等) +3. 约束(该社区允许多少配额等等) * 进一步了解[设置名字空间偏好](/zh-cn/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference) * 进一步了解[设置请求的名字空间](/zh-cn/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-for-a-request) -* 参阅[名字空间的设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/namespaces.md) +* 参阅[名字空间的设计文档](https://git.k8s.io/design-proposals-archive/architecture/namespaces.md) diff --git a/content/zh-cn/docs/tasks/administer-cluster/verify-signed-images.md b/content/zh-cn/docs/tasks/administer-cluster/verify-signed-images.md index 4fd9736b55f3c..507011981c97b 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/verify-signed-images.md +++ b/content/zh-cn/docs/tasks/administer-cluster/verify-signed-images.md @@ -115,6 +115,6 @@ resources: [cosigned](https://docs.sigstore.dev/cosign/kubernetes/#cosigned-admission-controller) 控制器验证其签名。如要使用 `cosigned`,下面是一些有帮助的资源: -* [安装](https://github.com/sigstore/helm-charts/tree/main/charts/cosigned) -* [配置选项](https://github.com/sigstore/cosign/tree/main/config) +* [安装](https://github.com/sigstore/cosign#installation) +* [配置选项](https://github.com/sigstore/cosign/blob/main/USAGE.md#detailed-usage) diff --git a/content/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index 3bd9777355f46..a3ba703b09443 100644 --- a/content/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/content/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -462,10 +462,10 @@ PersistentVolume are not present on the Pod resource itself. * 进一步了解 [PersistentVolumes](/zh-cn/docs/concepts/storage/persistent-volumes/) -* 阅读[持久存储设计文档](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) +* 阅读[持久存储设计文档](https://git.k8s.io/design-proposals-archive/storage/persistent-storage.md) * `fsGroup`:支持属主管理的卷会被修改,将其属主变更为 `fsGroup` 所指定的 GID, 并且对该 GID 可写。进一步的细节可参阅 - [属主变更设计文档](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)。 + [属主变更设计文档](https://git.k8s.io/design-proposals-archive/storage/volume-ownership-management.md)。 * `seLinuxOptions`:支持 SELinux 标签的卷会被重新打标签,以便可被 `seLinuxOptions` 下所设置的标签访问。通常你只需要设置 `level` 部分。 @@ -771,11 +771,11 @@ kubectl delete pod security-context-demo-4 * [PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core) * [SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core) * [Tuning Docker with the newest security enhancements](https://github.com/containerd/containerd/blob/main/docs/cri/config.md) -* [Security Contexts design document](https://git.k8s.io/community/contributors/design-proposals/auth/security_context.md) -* [Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md) +* [Security Contexts design document](https://git.k8s.io/design-proposals-archive/auth/security_context.md) +* [Ownership Management design document](https://git.k8s.io/design-proposals-archive/storage/volume-ownership-management.md) * [Pod Security Policies](/docs/concepts/security/pod-security-policy/) * [AllowPrivilegeEscalation design - document](https://git.k8s.io/community/contributors/design-proposals/auth/no-new-privs.md) + document](https://git.k8s.io/design-proposals-archive/auth/no-new-privs.md) * For more information about security mechanisms in Linux, see [Overview of Linux Kernel Security Features](https://www.linux.com/learn/overview-linux-kernel-security-features) --> diff --git a/content/zh-cn/docs/tasks/debug/debug-cluster/windows.md b/content/zh-cn/docs/tasks/debug/debug-cluster/windows.md index ef4f236539cca..2ebfc8c1aa940 100644 --- a/content/zh-cn/docs/tasks/debug/debug-cluster/windows.md +++ b/content/zh-cn/docs/tasks/debug/debug-cluster/windows.md @@ -23,7 +23,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. --> ## 工作节点级别排障 {#troubleshooting-node} @@ -31,7 +31,7 @@ content_type: concept 1. 我的 Pod 都卡在 “Container Creating” 或者不断重启 确保你的 pause 镜像跟你的 Windows 版本兼容。 - 查看 [Pause 容器](/zh-cn/docs/setup/production-environment/windows/intro-windows-in-kubernetes#pause-container) + 查看 [Pause 容器](/zh-cn/docs/concepts/windows/intro/#pause-container) 以了解最新的或建议的 pause 镜像,或者了解更多信息。 {{< note >}} @@ -51,7 +51,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). --> 2. 我的 Pod 状态显示 'ErrImgPull' 或者 'ImagePullBackOff' @@ -59,7 +59,7 @@ content_type: concept Windows 节点上。 关于如何为你的 Pod 指定一个兼容节点, - 可以查看这个指可以查看[这个指南](/zh-cn/docs/setup/production-environment/windows/user-guide-windows-containers/#ensuring-os-specific-workloads-land-on-the-appropriate-container-host) + 可以查看这个指可以查看[这个指南](/zh-cn/docs/concepts/windows/user-guide/#ensuring-os-specific-workloads-land-on-the-appropriate-container-host) 以了解更多的信息。 -Kubernetes apiserver 将使用由 `--proxy-client-*-file` 指示的文件来验证扩展 apiserver。 +Kubernetes apiserver 将使用由 `--proxy-client-*-file` 指示的文件来向扩展 apiserver认证。 为了使合规的扩展 apiserver 能够将该请求视为有效,必须满足以下条件: 1. 连接必须使用由 CA 签署的客户端证书,该证书的证书位于 `--requestheader-client-ca-file` 中。 diff --git a/content/zh-cn/docs/tasks/job/indexed-parallel-processing-static.md b/content/zh-cn/docs/tasks/job/indexed-parallel-processing-static.md index 9490812abed8e..a4fe1942583d4 100644 --- a/content/zh-cn/docs/tasks/job/indexed-parallel-processing-static.md +++ b/content/zh-cn/docs/tasks/job/indexed-parallel-processing-static.md @@ -15,7 +15,6 @@ weight: 30 - 在此示例中,你将运行一个使用多个并行工作进程的 Kubernetes Job。 每个 worker 都是在自己的 Pod 中运行的不同容器。 -Pod 具有控制平面自动设置的 _索引编号(index number)_, +Pod 具有控制平面自动设置的**索引编号(index number)**, 这些编号使得每个 Pod 能识别出要处理整个任务的哪个部分。 - -## 选择一种方法 + +## 选择一种方法 {#choose-an-approach} -要从工作程序访问工作项,你有几个选择: +要从工作程序访问工作项,你有几个选项: 1. 读取 `JOB_COMPLETION_INDEX` 环境变量。Job {{< glossary_tooltip text="控制器" term_id="controller" >}} @@ -99,7 +100,7 @@ For this example, imagine that you chose option 3 and you want to run the [rev](https://man7.org/linux/man-pages/man1/rev.1.html) utility. This program accepts a file as an argument and prints its content reversed. --> -对于此示例,假设你选择了方法 3 并且想要运行 +对于此示例,假设你选择了选项 3 并且想要运行 [rev](https://man7.org/linux/man-pages/man1/rev.1.html) 实用程序。 这个程序接受一个文件作为参数并按逆序打印其内容。 @@ -111,7 +112,7 @@ rev data.txt You'll use the `rev` tool from the [`busybox`](https://hub.docker.com/_/busybox) container image. --> -你将使用 [`busybox`](https://hub.docker.com/_/busybox) 容器映像中的 `rev` 工具。 +你将使用 [`busybox`](https://hub.docker.com/_/busybox) 容器镜像中的 `rev` 工具。 -由于这只是一个例子,每个 Pod 只做一小部分工作(反转一个短字符串)。 -例如,在实际工作负载中,你可能会创建一个表示基于场景数据制作 60 秒视频的任务的 Job 。 -视频渲染 Job 中的每个工作项都将渲染该视频剪辑的特定帧。 -索引完成意味着 Job 中的每个 Pod 都知道通过从剪辑开始计算帧数,来确定渲染和发布哪一帧,。 - - -## 定义索引作业 +由于这只是一个例子,每个 Pod 只做一小部分工作(反转一个短字符串)。 +例如,在实际工作负载中,你可能会创建一个表示基于场景数据制作 60 秒视频任务的 Job 。 +此视频渲染 Job 中的每个工作项都将渲染该视频剪辑的特定帧。 +索引完成意味着 Job 中的每个 Pod 都知道通过从剪辑开始计算帧数,来确定渲染和发布哪一帧。 +## 定义索引作业 {#define-an-indexed-job} + 这是一个使用 `Indexed` 完成模式的示例 Job 清单: {{< codenew language="yaml" file="application/job/indexed-job.yaml" >}} @@ -150,7 +152,7 @@ from a [ConfigMap as an environment variable or file](/docs/tasks/configure-pod- --> 在上面的示例中,你使用 Job 控制器为所有容器设置的内置 `JOB_COMPLETION_INDEX` 环境变量。 [Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/) -将索引映射到一个静态值,并将其写入一个文件,该文件通过 +将索引映射到一个静态值,并将其写入一个文件,该文件通过 [emptyDir 卷](/zh-cn/docs/concepts/storage/volumes/#emptydir) 与运行 worker 的容器共享。或者,你可以 [通过 Downward API 定义自己的环境变量](/zh-cn/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) @@ -169,10 +171,13 @@ like shown in the following example: {{< codenew language="yaml" file="application/job/indexed-job-vol.yaml" >}} - -## 执行 Job + +## 执行 Job {running-the-job} - 现在执行 Job: ```shell @@ -187,20 +192,22 @@ Because `.spec.parallelism` is less than `.spec.completions`, the control plane Once you have created the Job, wait a moment then check on progress: --> -当你创建此 Job 时,控制平面会创建一系列 Pod,每个索引都由你指定。 -`.spec.parallelism` 的值决定了一次可以运行多少个, +当你创建此 Job 时,控制平面会创建一系列 Pod,你指定的每个索引都会运行一个 Pod。 +`.spec.parallelism` 的值决定了一次可以运行多少个 Pod, 而 `.spec.completions` 决定了 Job 总共创建了多少个 Pod。 因为 `.spec.parallelism` 小于 `.spec.completions`, -控制平面在启动更多 Pod 之前,等待部分第一批 Pod 完成。 +所以控制平面在启动更多 Pod 之前,将等待第一批的某些 Pod 完成。 -创建 Job 后,稍等片刻,然后检查进度: +创建 Job 后,稍等片刻,就能检查进度: ```shell kubectl describe jobs/indexed-job ``` - + 输出类似于: ``` @@ -269,9 +276,11 @@ inspect the output of one of the pods: kubectl logs indexed-job-fdhq5 # 更改它以匹配来自该 Job 的 Pod 的名称 ``` - + 输出类似于: ``` xuq -``` \ No newline at end of file +``` diff --git a/content/zh-cn/docs/tasks/kubelet-credential-provider/kubelet-credential-provider.md b/content/zh-cn/docs/tasks/kubelet-credential-provider/kubelet-credential-provider.md index 0c63d0208e9d8..85cfc7d046e3a 100644 --- a/content/zh-cn/docs/tasks/kubelet-credential-provider/kubelet-credential-provider.md +++ b/content/zh-cn/docs/tasks/kubelet-credential-provider/kubelet-credential-provider.md @@ -13,7 +13,7 @@ description: Configure the kubelet's image credential provider plugin content_type: task --> -{{< feature-state for_k8s_version="v1.20" state="alpha" >}} +{{< feature-state for_k8s_version="v1.24" state="beta" >}} diff --git a/content/zh-cn/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/zh-cn/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index 348deda8c98b0..f90ba82192613 100644 --- a/content/zh-cn/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/zh-cn/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -94,7 +94,7 @@

部署你在 Kubernetes 上的第一个应用程序<

你可以使用 Kubernetes 命令行界面 Kubectl 创建和管理 Deployment。Kubectl 使用 Kubernetes API 与集群进行交互。在本单元中,你将学习创建在 Kubernetes 集群上运行应用程序的 Deployment 所需的最常见的 Kubectl 命令。

-

创建 Deployment 时,你需要指定应用程序的容器映像以及要运行的副本数。你可以稍后通过更新 Deployment 来更改该信息; 模块 56 讨论了如何扩展和更新 Deployments。

+

创建 Deployment 时,你需要指定应用程序的容器镜像以及要运行的副本数。你可以稍后通过更新 Deployment 来更改该信息; 模块 56 讨论了如何扩展和更新 Deployments。

diff --git a/content/zh-cn/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/zh-cn/docs/tutorials/kubernetes-basics/explore/explore-intro.html index d7d507f2d29fa..aa5e1a9e9b488 100644 --- a/content/zh-cn/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/zh-cn/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -54,7 +54,7 @@

Kubernetes Pods

  • 共享存储,当作卷
  • 网络,作为唯一的集群 IP 地址
  • -
  • 有关每个容器如何运行的信息,例如容器映像版本或要使用的特定端口。
  • +
  • 有关每个容器如何运行的信息,例如容器镜像版本或要使用的特定端口。
-本教程描述拉如何在 Kubernetes 上运行 [Apache Cassandra](https://cassandra.apache.org/)。 -数据库 Cassandra 需要永久性存储提供数据持久性(应用“状态”)。 -在此示例中,自定义 Cassandra seed provider 使数据库在加入 Cassandra -集群时发现新的 Cassandra 实例。 +本教程描述了如何在 Kubernetes 上运行 [Apache Cassandra](https://cassandra.apache.org/)。 +数据库 Cassandra 需要永久性存储提供数据持久性(应用**状态**)。 +在此示例中,自定义 Cassandra seed provider 使数据库在接入 Cassandra 集群时能够发现新的 Cassandra 实例。 -使用"StatefulSets"可以更轻松地将有状态的应用程序部署到你的 Kubernetes 集群中。 +使用**StatefulSet**可以更轻松地将有状态的应用程序部署到你的 Kubernetes 集群中。 有关本教程中使用的功能的更多信息, -参阅 [StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/)。 +请参阅 [StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/)。 {{< note >}} -Cassandra 和 Kubernetes 都使用术语“节点(node)”来表示集群的成员。 -在本教程中,属于 StatefulSet 的 Pod 是 Cassandra 节点,并且是 Cassandra 集群的成员(称为 “ring”)。 +Cassandra 和 Kubernetes 都使用术语**节点(node)**来表示集群的成员。 +在本教程中,属于 StatefulSet 的 Pod 是 Cassandra 节点,并且是 Cassandra 集群的成员(称为 **ring**)。 当这些 Pod 在你的 Kubernetes 集群中运行时,Kubernetes 控制平面会将这些 Pod 调度到 Kubernetes 的 {{< glossary_tooltip text="节点" term_id="node" >}}上。 @@ -51,9 +50,9 @@ nodes in the ring. This tutorial deploys a custom Cassandra seed provider that lets the database discover new Cassandra Pods as they appear inside your Kubernetes cluster. --> -当 Cassandra 节点启动时,使用 _seed列表_ 来引导发现 ring 中其他节点。 -本教程部署了一个自定义的 Cassandra seed provider,使数据库可以发现新的 Cassandra Pod -出现在 Kubernetes 集群中。 +当 Cassandra 节点启动时,使用 **seed 列表**来引导发现 ring 中的其他节点。 +本教程部署了一个自定义的 Cassandra seed provider, +使数据库可以发现 Kubernetes 集群中出现的新的 Cassandra Pod。 {{< /note >}} ## {{% heading "objectives" %}} @@ -65,11 +64,11 @@ new Cassandra Pods as they appear inside your Kubernetes cluster. * Modify the StatefulSet. * Delete the StatefulSet and its {{< glossary_tooltip text="Pods" term_id="pod" >}}. --> -* 创建并验证 Cassandra 无头(headless){{< glossary_tooltip text="Service" term_id="service" >}}.. +* 创建并验证 Cassandra 无头(headless){{< glossary_tooltip text="Service" term_id="service" >}}。 * 使用 {{< glossary_tooltip term_id="StatefulSet" >}} 创建一个 Cassandra ring。 * 验证 StatefulSet。 * 修改 StatefulSet。 -* 删除 StatefulSet 及其 {{< glossary_tooltip text="Pod" term_id="pod" >}}. +* 删除 StatefulSet 及其 {{< glossary_tooltip text="Pod" term_id="pod" >}}。 ## {{% heading "prerequisites" %}} @@ -81,7 +80,7 @@ To complete this tutorial, you should already have a basic familiarity with {{< glossary_tooltip text="Services" term_id="service" >}}, and {{< glossary_tooltip text="StatefulSets" term_id="StatefulSet" >}}. --> -要完成本教程,你应该已经熟悉 {{< glossary_tooltip text="Pod" term_id="pod" >}}, +要完成本教程,你应该已经熟悉 {{< glossary_tooltip text="Pod" term_id="pod" >}}、 {{< glossary_tooltip text="Service" term_id="service" >}} 和 {{< glossary_tooltip text="StatefulSet" term_id="StatefulSet" >}}。 @@ -96,14 +95,14 @@ errors during this tutorial. To avoid these errors, start Minikube with the foll ### 额外的 Minikube 设置说明 {{< caution >}} -[Minikube](https://minikube.sigs.k8s.io/docs/)默认为 2048MB 内存和 2 个 CPU。 -在本教程中,使用默认资源配置运行 Minikube 会导致资源不足的错误。为避免这些错误,请使用以下设置启动 Minikube: +[Minikube](https://minikube.sigs.k8s.io/docs/) 默认需要 2048MB 内存和 2 个 CPU。 +在本教程中,使用默认资源配置运行 Minikube 会出现资源不足的错误。为避免这些错误,请使用以下设置启动 Minikube: ```shell minikube start --memory 5120 --cpus=4 ``` -{{< /caution >}} +{{< /caution >}} -使用 `cassandra-statefulset.yaml` 文件创建 Cassandra StatefulSet : +使用 `cassandra-statefulset.yaml` 文件创建 Cassandra StatefulSet: ```shell # 如果你能未经修改地 apply cassandra-statefulset.yaml,请使用此命令 @@ -318,10 +317,9 @@ Use `kubectl edit` to modify the size of a Cassandra StatefulSet. 此命令你的终端中打开一个编辑器。需要更改的是 `replicas` 字段。下面是 StatefulSet 文件的片段示例: ```yaml - # Please edit the object below. Lines beginning with a '#' will be ignored, - # and an empty file will abort the edit. If an error occurs while saving this file will be - # reopened with the relevant failures. - # + # 请编辑以下对象。以 '#' 开头的行将被忽略, + # 且空文件将放弃编辑。如果保存此文件时发生错误, + # 将重新打开并显示相关故障。 apiVersion: apps/v1 kind: StatefulSet metadata: @@ -378,7 +376,7 @@ This setting is for your safety because your data is more valuable than automati Depending on the storage class and reclaim policy, deleting the *PersistentVolumeClaims* may cause the associated volumes to also be deleted. Never assume you'll be able to access data if its volume claims are deleted. --> -根据存储类和回收策略,删除 *PersistentVolumeClaims* 可能导致关联的卷也被删除。 +根据存储类和回收策略,删除 **PersistentVolumeClaims** 可能导致关联的卷也被删除。 千万不要认为其容量声明被删除,你就能访问数据。 {{< /warning >}} @@ -422,7 +420,7 @@ By using environment variables you can change values that are inserted into `cas 镜像。上面的 Docker 镜像基于 [debian-base](https://github.com/kubernetes/release/tree/master/images/build/debian-base), 并且包含 OpenJDK 8。 -该映像包括来自 Apache Debian 存储库的标准 Cassandra 安装。 +该镜像包括来自 Apache Debian 存储库的标准 Cassandra 安装。 通过使用环境变量,你可以更改插入到 `cassandra.yaml` 中的值。 | 环境变量 | 默认值 | diff --git a/content/zh-cn/examples/admin/konnectivity/egress-selector-configuration.yaml b/content/zh-cn/examples/admin/konnectivity/egress-selector-configuration.yaml index 2f1cff1aea845..e2c9ddbb03ccb 100644 --- a/content/zh-cn/examples/admin/konnectivity/egress-selector-configuration.yaml +++ b/content/zh-cn/examples/admin/konnectivity/egress-selector-configuration.yaml @@ -2,7 +2,7 @@ apiVersion: apiserver.k8s.io/v1beta1 kind: EgressSelectorConfiguration egressSelections: # 由于我们要控制集群的出站流量,所以将 “cluster” 用作 name。 -# 其他支持的值有 “etcd” 和 “master”。 +# 其他支持的值有 “etcd” 和 “controlplane”。 - name: cluster connection: # 这一属性将控制 API 服务器 Konnectivity 服务器之间的协议。 diff --git a/content/zh-cn/examples/pods/pod-with-affinity-anti-affinity.yaml b/content/zh-cn/examples/pods/pod-with-affinity-anti-affinity.yaml index a7d14b2d6f755..eeb3cb372bf31 100644 --- a/content/zh-cn/examples/pods/pod-with-affinity-anti-affinity.yaml +++ b/content/zh-cn/examples/pods/pod-with-affinity-anti-affinity.yaml @@ -8,10 +8,11 @@ spec: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - - key: kubernetes.io/os + - key: topology.kubernetes.io/zone operator: In values: - - linux + - antarctica-east1 + - antarctica-west1 preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference: diff --git a/content/zh-cn/partners/_index.html b/content/zh-cn/partners/_index.html index eefdfd6e02727..5e87b88a5ca8a 100644 --- a/content/zh-cn/partners/_index.html +++ b/content/zh-cn/partners/_index.html @@ -15,95 +15,63 @@ -->
-
- -
Kubernetes 与合作伙伴携手打造一个强大、活跃的代码库,支持一系列互补平台。
-
-
-
-
- - Kubernetes 认证服务提供商 -
- -
经过审核的服务提供商在帮助企业成功采用 Kubernetes 方面有深厚的经验。 -


- - - -

想要成为KCSP吗? -
-
-
-
-
- - Kubernetes 认证的发行版本、托管平台以及安装工具 - -
软件合规性确保各厂商的 Kubernetes 版本都支持必需的 API。 -


- - - -

想要成为Kubernetes 认证的厂商吗? -
-
-
-
- -
Kubernetes 培训合作伙伴
- -
经过审核的培训机构在云原生技术培训方面有深厚的经验。 -



- - - -

想要成为KTP吗? -
-
-
- - - -
- - + +
Kubernetes 与合作伙伴携手打造一个强大、活跃的代码库,支持一系列互补平台。
+
+
+
+
+ + Kubernetes 认证服务提供商 +
+ +
经过审核的服务提供商在帮助企业成功采用 Kubernetes 方面有深厚的经验。 +


+ + + +

想要成为 + KCSP 吗? +
- -
+
+
+
+ + Kubernetes 认证的发行版本、托管平台以及安装工具 + +
软件合规性确保各厂商的 Kubernetes 版本都支持必需的 API。 +


+ + + +

想要成为 + Kubernetes 认证的厂商吗? +
+
+
+
+
+ + Kubernetes 培训合作伙伴 +
+ +
经过审核的培训机构在云原生技术培训方面有深厚的经验。 +


+ + + +

想要成为 + KTP 吗? +
+
+
+ {{< cncf-landscape helpers=true >}} - diff --git a/content/zh-cn/releases/patch-releases.md b/content/zh-cn/releases/patch-releases.md index 565355cc566b0..0ec1dba1e894a 100644 --- a/content/zh-cn/releases/patch-releases.md +++ b/content/zh-cn/releases/patch-releases.md @@ -147,14 +147,12 @@ releases may also occur in between these. | 月度补丁发布 | Cherry Pick 截止日期 | 目标日期 | | ------------- | -------------------- | ----------- | -| 2022 年 7 月 | 2022-07-08 | 2022-07-13 | | 2022 年 8 月 | 2022-08-12 | 2022-08-16 | | 2022 年 9 月 | 2022-09-09 | 2022-09-14 | | 2022 年 10 月 | 2022-10-07 | 2022-10-12 | @@ -164,12 +162,13 @@ releases may also occur in between these. ### 1.24 -Next patch release is **1.24.1** +Next patch release is **1.24.4** -End of Life for **1.24** is **2023-09-29** +End of Life for **1.24** is **2023-07-28** | PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE | |---------------|----------------------|-------------|------| +| 1.24.4 | 2022-08-12 | 2022-08-17 | | | 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 | | @@ -178,12 +177,13 @@ End of Life for **1.24** is **2023-09-29** ### 1.24 -下一个补丁版本是 **1.24.1** +下一个补丁版本是 **1.24.4** -**1.24** 的生命周期结束时间为 **2023-09-29** +**1.24** 的生命周期结束时间为 **2023-07-28** | 补丁发布 | Cherry Pick 截止日期 | 目标日期 | 说明 | |----------|----------------------|------------|------| +| 1.24.4 | 2022-08-12 | 2022-08-17 | | | 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 | | @@ -191,10 +191,15 @@ End of Life for **1.24** is **2023-09-29** ### 1.23 + +下一个补丁版本是 **1.23.10**。 + **1.23** 于 **2022-12-28** 进入维护模式。 **1.23** 的生命周期结束时间为 **2023-02-28**。 @@ -203,9 +208,23 @@ End of Life for **1.23** is **2023-02-28**. | Patch Release | Cherry Pick Deadline | Target Date | Note | [Out-of-Band Release](https://groups.google.com/a/kubernetes.io/g/dev/c/Xl1sm-CItaY) +| Patch Release | Cherry Pick Deadline | Target Date | Note | +|---------------|----------------------|-------------|------| +| 1.23.10 | 2022-08-12 | 2022-08-17 | | +| 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 | | +| 1.23.5 | 2022-03-11 | 2022-03-16 | | +| 1.23.4 | 2022-02-11 | 2022-02-16 | | +| 1.23.3 | 2022-01-24 | 2022-01-25 | [Out-of-Band Release](https://groups.google.com/a/kubernetes.io/g/dev/c/Xl1sm-CItaY) | +| 1.23.2 | 2022-01-14 | 2022-01-19 | | +| 1.23.1 | 2021-12-14 | 2021-12-16 | | --> + | 补丁发布 | Cherry Pick 截止日期 | 目标日期 | 说明 | |---------------|----------------------|-------------|------| +| 1.23.10 | 2022-08-12 | 2022-08-17 | | | 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 | | @@ -219,19 +238,39 @@ End of Life for **1.23** is **2023-02-28**. ### 1.22 + +下一个补丁版本是 **1.22.13**。 + **1.22** 于 **2022-08-28** 进入维护模式 **1.22** 的生命周期结束时间为 **2022-10-28** | 补丁发布 | Cherry Pick 截止日期 | 目标日期 | 说明 | |---------------|----------------------|-------------|------| +| 1.22.13 | 2022-08-12 | 2022-08-17 | | | 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 | | diff --git a/content/zh-cn/releases/release-managers.md b/content/zh-cn/releases/release-managers.md index 1da4957daa88c..c78b09d67bcf0 100644 --- a/content/zh-cn/releases/release-managers.md +++ b/content/zh-cn/releases/release-managers.md @@ -130,7 +130,7 @@ Release Managers are responsible for: - Reviewing cherry picks - Ensuring the release branch stays healthy and that no unintended patch gets merged -- Mentoring the [Release Manager Associates](#associates) group +- Mentoring the [Release Manager Associates](#release-manager-associates) group - Actively developing features and maintaining the code in k/release - Supporting Release Manager Associates and contributors through actively participating in the Buddy program @@ -150,7 +150,7 @@ Release Managers are responsible for: - 维护发布分支: - 审查 Cherry Pick - 确保发布分支保持健康并且没有合并意外的补丁 -- 指导[发布管理员助理](#associates)小组 +- 指导[发布管理员助理](#release-manager-associates)小组 - 积极开发功能并维护 kubernetes/release 中的代码 - 通过积极参与 Buddy 计划来支持发布管理员助理和贡献者 - 每月与助理核对并委派任务,授权他们生成发行版本并指导工作 @@ -246,7 +246,9 @@ GitHub Mentions: @kubernetes/release-engineering GitHub 提及:@kubernetes/release-engineering - Arnaud Meukam ([@ameukam](https://github.com/ameukam)) +- Jeremy Rickard ([@jeremyrickard](https://github.com/jeremyrickard)) - Jim Angel ([@jimangel](https://github.com/jimangel)) +- Joseph Sandoval ([@jrsapi](https://github.com/jrsapi)) - Joyce Kung ([@thejoycekung](https://github.com/thejoycekung)) - Max Körbächer ([@mkorbi](https://github.com/mkorbi)) - Seth McCombs ([@sethmccombs](https://github.com/sethmccombs)) diff --git a/data/releases/schedule.yaml b/data/releases/schedule.yaml index a88fb511a735d..5f56b2cbb28d9 100644 --- a/data/releases/schedule.yaml +++ b/data/releases/schedule.yaml @@ -1,11 +1,14 @@ schedules: - release: 1.24 releaseDate: 2022-05-03 - next: 1.24.3 - cherryPickDeadline: 2022-07-08 - targetDate: 2022-07-13 - endOfLifeDate: 2023-09-29 + next: 1.24.4 + cherryPickDeadline: 2022-08-12 + targetDate: 2022-08-17 + endOfLifeDate: 2023-07-28 previousPatches: + - release: 1.24.3 + cherryPickDeadline: 2022-07-08 + targetDate: 2022-07-13 - release: 1.24.2 cherryPickDeadline: 2022-06-10 targetDate: 2022-06-15 @@ -14,11 +17,14 @@ schedules: targetDate: 2022-05-24 - release: 1.23 releaseDate: 2021-12-07 - next: 1.23.9 - cherryPickDeadline: 2022-07-08 - targetDate: 2022-07-13 + next: 1.23.10 + cherryPickDeadline: 2022-08-12 + targetDate: 2022-08-17 endOfLifeDate: 2023-02-28 previousPatches: + - release: 1.23.9 + cherryPickDeadline: 2022-07-08 + targetDate: 2022-07-13 - release: 1.23.8 cherryPickDeadline: 2022-06-10 targetDate: 2022-06-15 @@ -46,11 +52,14 @@ schedules: targetDate: 2021-12-16 - release: 1.22 releaseDate: 2021-08-04 - next: 1.22.12 - cherryPickDeadline: 2022-07-08 - targetDate: 2022-07-13 + next: 1.22.13 + cherryPickDeadline: 2022-08-12 + targetDate: 2022-08-17 endOfLifeDate: 2022-10-28 previousPatches: + - release: 1.22.12 + cherryPickDeadline: 2022-07-08 + targetDate: 2022-07-13 - release: 1.22.11 cherryPickDeadline: 2022-06-10 targetDate: 2022-06-15

Mapping PodSecurityPolicy annotations to Pod Security Standards
Mapping PodSecurityPolicy annotations to Pod Security Standards
PSP Annotation Type Pod Security Standards Equivalent
--authorization-mode string     Default: AlwaysAllow--authorization-mode string     Default: AlwaysAllow
Authorization mode for Kubelet server. Valid options are AlwaysAllow or Webhook. Webhook mode uses the SubjectAccessReview API to determine authorization. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.)控制(Control) 策略(Policy)
HostProcess +
HostProcess

Windows Pod 提供了运行 HostProcess 容器 的能力,这使得对 Windows 节点的特权访问成为可能。Baseline 策略中禁止对宿主的特权访问。{{< feature-state for_k8s_version="v1.23" state="beta" >}}

@@ -121,7 +118,7 @@ fail validation.
宿主名字空间 +

必须禁止共享宿主上的名字空间。

限制的字段

    @@ -195,7 +192,6 @@ fail validation.
  • 未定义、nil
宿主端口
Seccomp

Seccomp 配置必须不能显式设置为 Unconfined

@@ -304,7 +300,7 @@ fail validation.
SysctlsSysctls

Sysctls 可以禁用安全机制或影响宿主上所有容器,因此除了若干“安全”的子集之外,应该被禁止。如果某 sysctl 是受容器或 Pod 的名字空间限制,且与节点上其他 Pod 或进程相隔离,可认为是安全的。

限制的字段

@@ -360,7 +356,7 @@ fail validation.
Baseline 策略的所有要求。
卷类型卷类型

除了限制 HostPath 卷之外,此类策略还限制可以通过 PersistentVolumes 定义的非核心卷类型。

限制的字段

@@ -382,7 +378,7 @@ fail validation.
特权提升(v1.8+)特权提升(v1.8+)

禁止(通过 SetUID 或 SetGID 文件模式)获得特权提升。

限制的字段

@@ -398,8 +394,8 @@ fail validation.
以非 root 账号运行 + 以非 root 账号运行

容器必须以非 root 账号运行。

限制的字段

    @@ -453,15 +449,29 @@ fail validation.
  • Localhost
- 如果 Pod 级别的 spec.securityContext.seccompProfile.type 已设置得当,容器级别的安全上下文字段可以为 未定义/nil。反而言之,如果 所有的 容器级别的安全上下文字段已设置,则 Pod 级别的字段可为 未定义/nil。 + + 如果 Pod 级别的 spec.securityContext.seccompProfile.type + 已设置得当,容器级别的安全上下文字段可以为未定义/nil。 + 反之如果 所有的 容器级别的安全上下文字段已设置, + 则 Pod 级别的字段可为 未定义/nil
权能(v1.22+) +

- 容器必须弃用 ALL 权能,并且只允许添加 NET_BIND_SERVICE 权能。 + + 容器必须弃用 ALL 权能,并且只允许添加 + NET_BIND_SERVICE 权能。

限制的字段

    @@ -568,13 +578,13 @@ SIG Auth may reconsider this position in the future, should a clear need for oth SIG Auth 可能会在将来考虑这个范围的框架,前提是有对其他框架的需求。 -### 安全策略与安全上下文的区别是什么? +### 安全配置与安全上下文的区别是什么? [安全上下文](/zh-cn/docs/tasks/configure-pod-container/security-context/)在运行时配置 Pod 和容器。安全上下文是在 Pod 清单中作为 Pod 和容器规约的一部分来定义的, @@ -595,18 +605,18 @@ built-in [Pod Security Admission Controller](/docs/concepts/security/pod-securit ### What profiles should I apply to my Windows Pods? Windows in Kubernetes has some limitations and differentiators from standard Linux-based -workloads. Specifically, the Pod SecurityContext fields [have no effect on -Windows](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext). As -such, no standardized Pod Security profiles currently exists. +workloads. Specifically, many of the Pod SecurityContext fields +[have no effect on Windows](/docs/concepts/windows/intro/#compatibility-v1-pod-spec-containers-securitycontext). +As such, no standardized Pod Security profiles currently exist. --> ### 我应该为我的 Windows Pod 实施哪种框架? Kubernetes 中的 Windows 负载与标准的基于 Linux 的负载相比有一些局限性和区别。 尤其是 Pod SecurityContext -字段[对 Windows 不起作用](/zh-cn/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。 +字段[对 Windows 不起作用](/zh-cn/docs/concepts/windows/intro/#compatibility-v1-pod-spec-containers-securitycontext)。 因此,目前没有对应的标准 Pod 安全性框架。 - 你应该只在 Privileged 策略下使用 HostProcess 标志来创建 HostProcess Pod。 在 Baseline 和 Restricted 策略下,创建 Windows HostProcess Pod 是被禁止的, @@ -645,11 +657,11 @@ restrict privileged permissions is lessened when the workload is isolated from t kernel. This allows for workloads requiring heightened permissions to still be isolated. Additionally, the protection of sandboxed workloads is highly dependent on the method of -sandboxing. As such, no single recommended policy is recommended for all sandboxed workloads. +sandboxing. As such, no single recommended profile is recommended for all sandboxed workloads. --> 沙箱化负载所需要的保护可能彼此各不相同。例如,当负载与下层内核直接隔离开来时, 限制特权化操作的许可就不那么重要。这使得那些需要更多许可权限的负载仍能被有效隔离。 此外,沙箱化负载的保护高度依赖于沙箱化的实现方法。 -因此,现在还没有针对所有沙箱化负载的建议策略。 +因此,现在还没有针对所有沙箱化负载的建议配置。 diff --git a/content/zh-cn/docs/concepts/storage/persistent-volumes.md b/content/zh-cn/docs/concepts/storage/persistent-volumes.md index 44fd6188d4fc6..1d2b50735bd22 100644 --- a/content/zh-cn/docs/concepts/storage/persistent-volumes.md +++ b/content/zh-cn/docs/concepts/storage/persistent-volumes.md @@ -31,7 +31,7 @@ weight: 20 -本文描述 Kubernetes 中的 _持久卷(Persistent Volume)_ 。 +本文描述 Kubernetes 中的**持久卷(Persistent Volume)** 。 建议先熟悉[卷(Volume)](/zh-cn/docs/concepts/storage/volumes/)的概念。 @@ -43,24 +43,25 @@ Managing storage is a distinct problem from managing compute instances. The Pers --> ## 介绍 {#introduction} -存储的管理是一个与计算实例的管理完全不同的问题。PersistentVolume 子系统为用户 -和管理员提供了一组 API,将存储如何供应的细节从其如何被使用中抽象出来。 +存储的管理是一个与计算实例的管理完全不同的问题。 +PersistentVolume 子系统为用户和管理员提供了一组 API, +将存储如何制备的细节从其如何被使用中抽象出来。 为了实现这点,我们引入了两个新的 API 资源:PersistentVolume 和 PersistentVolumeClaim。 -持久卷(PersistentVolume,PV)是集群中的一块存储,可以由管理员事先供应,或者 -使用[存储类(Storage Class)](/zh-cn/docs/concepts/storage/storage-classes/)来动态供应。 -持久卷是集群资源,就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样,也是使用 -卷插件来实现的,只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。 +**持久卷(PersistentVolume,PV)** 是集群中的一块存储,可以由管理员事先制备, +或者使用[存储类(Storage Class)](/zh-cn/docs/concepts/storage/storage-classes/)来动态制备。 +持久卷是集群资源,就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样, +也是使用卷插件来实现的,只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。 此 API 对象中记述了存储的实现细节,无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。 -持久卷申领(PersistentVolumeClaim,PVC)表达的是用户对存储的请求。概念上与 Pod 类似。 +**持久卷申领(PersistentVolumeClaim,PVC)** 表达的是用户对存储的请求。概念上与 Pod 类似。 Pod 会耗用节点资源,而 PVC 申领会耗用 PV 资源。Pod 可以请求特定数量的资源(CPU 和内存);同样 PVC 申领也可以请求特定的大小和访问模式 (例如,可以要求 PV 卷能够以 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany @@ -71,11 +72,11 @@ While PersistentVolumeClaims allow a user to consume abstract storage resources, See the [detailed walkthrough with working examples](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). --> -尽管 PersistentVolumeClaim 允许用户消耗抽象的存储资源,常见的情况是针对不同的 -问题用户需要的是具有不同属性(如,性能)的 PersistentVolume 卷。 -集群管理员需要能够提供不同性质的 PersistentVolume,并且这些 PV 卷之间的差别不 -仅限于卷大小和访问模式,同时又不能将卷是如何实现的这些细节暴露给用户。 -为了满足这类需求,就有了 _存储类(StorageClass)_ 资源。 +尽管 PersistentVolumeClaim 允许用户消耗抽象的存储资源, +常见的情况是针对不同的问题用户需要的是具有不同属性(如,性能)的 PersistentVolume 卷。 +集群管理员需要能够提供不同性质的 PersistentVolume, +并且这些 PV 卷之间的差别不仅限于卷大小和访问模式,同时又不能将卷是如何实现的这些细节暴露给用户。 +为了满足这类需求,就有了 **存储类(StorageClass)** 资源。 参见[基于运行示例的详细演练](/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)。 @@ -93,19 +94,19 @@ There are two ways PVs may be provisioned: statically or dynamically. PV 卷是集群中的资源。PVC 申领是对这些资源的请求,也被用来执行对资源的申领检查。 PV 卷和 PVC 申领之间的互动遵循如下生命周期: -### 供应 {#provisioning} +### 制备 {#provisioning} -PV 卷的供应有两种方式:静态供应或动态供应。 +PV 卷的制备有两种方式:静态制备或动态制备。 -#### 静态供应 {#static} +#### 静态制备 {#static} -集群管理员创建若干 PV 卷。这些卷对象带有真实存储的细节信息,并且对集群 -用户可用(可见)。PV 卷对象存在于 Kubernetes API 中,可供用户消费(使用)。 +集群管理员创建若干 PV 卷。这些卷对象带有真实存储的细节信息, +并且对集群用户可用(可见)。PV 卷对象存在于 Kubernetes API 中,可供用户消费(使用)。 -#### 动态供应 {#dynamic} +#### 动态制备 {#dynamic} 如果管理员所创建的所有静态 PV 卷都无法与用户的 PersistentVolumeClaim 匹配, -集群可以尝试为该 PVC 申领动态供应一个存储卷。 -这一供应操作是基于 StorageClass 来实现的:PVC 申领必须请求某个 -[存储类](/zh-cn/docs/concepts/storage/storage-classes/),同时集群管理员必须 -已经创建并配置了该类,这样动态供应卷的动作才会发生。 -如果 PVC 申领指定存储类为 `""`,则相当于为自身禁止使用动态供应的卷。 +集群可以尝试为该 PVC 申领动态制备一个存储卷。 +这一制备操作是基于 StorageClass 来实现的:PVC 申领必须请求某个 +[存储类](/zh-cn/docs/concepts/storage/storage-classes/), +同时集群管理员必须已经创建并配置了该类,这样动态制备卷的动作才会发生。 +如果 PVC 申领指定存储类为 `""`,则相当于为自身禁止使用动态制备的卷。 -为了基于存储类完成动态的存储供应,集群管理员需要在 API 服务器上启用 +为了基于存储类完成动态的存储制备,集群管理员需要在 API 服务器上启用 `DefaultStorageClass` [准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)。 举例而言,可以通过保证 `DefaultStorageClass` 出现在 API 服务器组件的 -`--enable-admission-plugins` 标志值中实现这点;该标志的值可以是逗号 -分隔的有序列表。关于 API 服务器标志的更多信息,可以参考 +`--enable-admission-plugins` 标志值中实现这点;该标志的值可以是逗号分隔的有序列表。 +关于 API 服务器标志的更多信息,可以参考 [kube-apiserver](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/) 文档。 @@ -147,30 +148,28 @@ check [kube-apiserver](/docs/admin/kube-apiserver/) documentation. ### Binding A user creates, or in the case of dynamic provisioning, has already created, a PersistentVolumeClaim with a specific amount of storage requested and with certain access modes. A control loop in the master watches for new PVCs, finds a matching PV (if possible), and binds them together. If a PV was dynamically provisioned for a new PVC, the loop will always bind that PV to the PVC. Otherwise, the user will always get at least what they asked for, but the volume may be in excess of what was requested. Once bound, PersistentVolumeClaim binds are exclusive, regardless of how they were bound. A PVC to PV binding is a one-to-one mapping, using a ClaimRef which is a bi-directional binding between the PersistentVolume and the PersistentVolumeClaim. - -Claims will remain unbound indefinitely if a matching volume does not exist. Claims will be bound as matching volumes become available. For example, a cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi. The PVC can be bound when a 100Gi PV is added to the cluster. --> ### 绑定 {#binding} 用户创建一个带有特定存储容量和特定访问模式需求的 PersistentVolumeClaim 对象; -在动态供应场景下,这个 PVC 对象可能已经创建完毕。 +在动态制备场景下,这个 PVC 对象可能已经创建完毕。 主控节点中的控制回路监测新的 PVC 对象,寻找与之匹配的 PV 卷(如果可能的话), 并将二者绑定到一起。 -如果为了新的 PVC 申领动态供应了 PV 卷,则控制回路总是将该 PV 卷绑定到这一 PVC 申领。 +如果为了新的 PVC 申领动态制备了 PV 卷,则控制回路总是将该 PV 卷绑定到这一 PVC 申领。 否则,用户总是能够获得他们所请求的资源,只是所获得的 PV 卷可能会超出所请求的配置。 -一旦绑定关系建立,则 PersistentVolumeClaim 绑定就是排他性的,无论该 PVC 申领是 -如何与 PV 卷建立的绑定关系。 -PVC 申领与 PV 卷之间的绑定是一种一对一的映射,实现上使用 ClaimRef 来记述 PV 卷 -与 PVC 申领间的双向绑定关系。 +一旦绑定关系建立,则 PersistentVolumeClaim 绑定就是排他性的, +无论该 PVC 申领是如何与 PV 卷建立的绑定关系。 +PVC 申领与 PV 卷之间的绑定是一种一对一的映射,实现上使用 ClaimRef 来记述 +PV 卷与 PVC 申领间的双向绑定关系。 如果找不到匹配的 PV 卷,PVC 申领会无限期地处于未绑定状态。 当与之匹配的 PV 卷可用时,PVC 申领会被绑定。 -例如,即使某集群上供应了很多 50 Gi 大小的 PV 卷,也无法与请求 -100 Gi 大小的存储的 PVC 匹配。当新的 100 Gi PV 卷被加入到集群时,该 -PVC 才有可能被绑定。 +例如,即使某集群上制备了很多 50 Gi 大小的 PV 卷,也无法与请求 +100 Gi 大小的存储的 PVC 匹配。当新的 100 Gi PV 卷被加入到集群时, +该 PVC 才有可能被绑定。 ### 使用 {#using} -Pod 将 PVC 申领当做存储卷来使用。集群会检视 PVC 申领,找到所绑定的卷,并 -为 Pod 挂载该卷。对于支持多种访问模式的卷,用户要在 Pod 中以卷的形式使用申领 -时指定期望的访问模式。 +Pod 将 PVC 申领当做存储卷来使用。集群会检视 PVC 申领,找到所绑定的卷, +并为 Pod 挂载该卷。对于支持多种访问模式的卷, +用户要在 Pod 中以卷的形式使用申领时指定期望的访问模式。 -一旦用户有了申领对象并且该申领已经被绑定,则所绑定的 PV 卷在用户仍然需要它期间 -一直属于该用户。用户通过在 Pod 的 `volumes` 块中包含 `persistentVolumeClaim` +一旦用户有了申领对象并且该申领已经被绑定, +则所绑定的 PV 卷在用户仍然需要它期间一直属于该用户。 +用户通过在 Pod 的 `volumes` 块中包含 `persistentVolumeClaim` 节区来调度 Pod,访问所申领的 PV 卷。 相关细节可参阅[使用申领作为卷](#claims-as-volumes)。 @@ -198,9 +198,9 @@ The purpose of the Storage Object in Use Protection feature is to ensure that Pe --> ### 保护使用中的存储对象 {#storage-object-in-use-protection} -保护使用中的存储对象(Storage Object in Use Protection)这一功能特性的目的 -是确保仍被 Pod 使用的 PersistentVolumeClaim(PVC)对象及其所绑定的 -PersistentVolume(PV)对象在系统中不会被删除,因为这样做可能会引起数据丢失。 +保护使用中的存储对象(Storage Object in Use Protection) +这一功能特性的目的是确保仍被 Pod 使用的 PersistentVolumeClaim(PVC) +对象及其所绑定的 PersistentVolume(PV)对象在系统中不会被删除,因为这样做可能会引起数据丢失。 -### 回收 {#reclaiming} +### 回收(Reclaiming) {#reclaiming} -当用户不再使用其存储卷时,他们可以从 API 中将 PVC 对象删除,从而允许 -该资源被回收再利用。PersistentVolume 对象的回收策略告诉集群,当其被 -从申领中释放时如何处理该数据卷。 +当用户不再使用其存储卷时,他们可以从 API 中将 PVC 对象删除, +从而允许该资源被回收再利用。PersistentVolume 对象的回收策略告诉集群, +当其被从申领中释放时如何处理该数据卷。 目前,数据卷可以被 Retained(保留)、Recycled(回收)或 Deleted(删除)。 #### 保留(Retain) {#retain} -回收策略 `Retain` 使得用户可以手动回收资源。当 PersistentVolumeClaim 对象 -被删除时,PersistentVolume 卷仍然存在,对应的数据卷被视为"已释放(released)"。 +回收策略 `Retain` 使得用户可以手动回收资源。当 PersistentVolumeClaim +对象被删除时,PersistentVolume 卷仍然存在,对应的数据卷被视为"已释放(released)"。 由于卷上仍然存在这前一申领人的数据,该卷还不能用于其他申领。 管理员可以通过下面的步骤来手动回收该卷: @@ -314,10 +314,10 @@ For volume plugins that support the `Delete` reclaim policy, deletion removes bo 对于支持 `Delete` 回收策略的卷插件,删除动作会将 PersistentVolume 对象从 Kubernetes 中移除,同时也会从外部基础设施(如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷)中移除所关联的存储资产。 -动态供应的卷会继承[其 StorageClass 中设置的回收策略](#reclaim-policy),该策略默认 -为 `Delete`。 -管理员需要根据用户的期望来配置 StorageClass;否则 PV 卷被创建之后必须要被 -编辑或者修补。参阅[更改 PV 卷的回收策略](/zh-cn/docs/tasks/administer-cluster/change-pv-reclaim-policy/). +动态制备的卷会继承[其 StorageClass 中设置的回收策略](#reclaim-policy), +该策略默认为 `Delete`。管理员需要根据用户的期望来配置 StorageClass; +否则 PV 卷被创建之后必须要被编辑或者修补。 +参阅[更改 PV 卷的回收策略](/zh-cn/docs/tasks/administer-cluster/change-pv-reclaim-policy/). -定制回收器 Pod 模板中在 `volumes` 部分所指定的特定路径要替换为 -正被回收的卷的路径。 +定制回收器 Pod 模板中在 `volumes` 部分所指定的特定路径要替换为正被回收的卷的路径。 绑定操作不会考虑某些卷匹配条件是否满足,包括节点亲和性等等。 -控制面仍然会检查 -[存储类](/zh-cn/docs/concepts/storage/storage-classes/)、访问模式和所请求的 -存储尺寸都是合法的。 +控制面仍然会检查[存储类](/zh-cn/docs/concepts/storage/storage-classes/)、 +访问模式和所请求的存储尺寸都是合法的。 ```yaml apiVersion: v1 @@ -503,9 +501,9 @@ spec: This method does not guarantee any binding privileges to the PersistentVolume. If other PersistentVolumeClaims could use the PV that you specify, you first need to reserve that storage volume. Specify the relevant PersistentVolumeClaim in the `claimRef` field of the PV so that other PVCs can not bind to it. --> 此方法无法对 PersistentVolume 的绑定特权做出任何形式的保证。 -如果有其他 PersistentVolumeClaim 可以使用你所指定的 PV,则你应该首先预留 -该存储卷。你可以将 PV 的 `claimRef` 字段设置为相关的 PersistentVolumeClaim -以确保其他 PVC 不会绑定到该 PV 卷。 +如果有其他 PersistentVolumeClaim 可以使用你所指定的 PV, +则你应该首先预留该存储卷。你可以将 PV 的 `claimRef` 字段设置为相关的 +PersistentVolumeClaim 以确保其他 PVC 不会绑定到该 PV 卷。 ```yaml apiVersion: v1 @@ -524,8 +522,8 @@ spec: This is useful if you want to consume PersistentVolumes that have their `claimPolicy` set to `Retain`, including cases where you are reusing an existing PV. --> -如果你想要使用 `claimPolicy` 属性设置为 `Retain` 的 PersistentVolume 卷 -时,包括你希望复用现有的 PV 卷时,这点是很有用的 +如果你想要使用 `claimPolicy` 属性设置为 `Retain` 的 PersistentVolume 卷时, +包括你希望复用现有的 PV 卷时,这点是很有用的 -对 CSI 卷的扩充能力默认是被启用的,不过扩充 CSI 卷要求 CSI 驱动支持 -卷扩充操作。可参阅特定 CSI 驱动的文档了解更多信息。 +对 CSI 卷的扩充能力默认是被启用的,不过扩充 CSI 卷要求 CSI +驱动支持卷扩充操作。可参阅特定 CSI 驱动的文档了解更多信息。 -当卷中包含文件系统时,只有在 Pod 使用 `ReadWrite` 模式来使用 PVC 申领的 -情况下才能重设其文件系统的大小。 -文件系统扩充的操作或者是在 Pod 启动期间完成,或者在下层文件系统支持在线 -扩充的前提下在 Pod 运行期间完成。 +当卷中包含文件系统时,只有在 Pod 使用 `ReadWrite` 模式来使用 PVC +申领的情况下才能重设其文件系统的大小。文件系统扩充的操作或者是在 Pod +启动期间完成,或者在下层文件系统支持在线扩充的前提下在 Pod 运行期间完成。 -如果 FlexVolumes 的驱动将 `RequiresFSResize` 能力设置为 `true`,则该 -FlexVolume 卷(于 Kubernetes v1.23 弃用)可以在 Pod 重启期间调整大小。 +如果 FlexVolumes 的驱动将 `RequiresFSResize` 能力设置为 `true`, +则该 FlexVolume 卷(于 Kubernetes v1.23 弃用)可以在 Pod 重启期间调整大小。 -如果扩充下层存储的操作失败,集群管理员可以手动地恢复 PVC 申领的状态并 -取消重设大小的请求。否则,在没有管理员干预的情况下,控制器会反复重试 -重设大小的操作。 +如果扩充下层存储的操作失败,集群管理员可以手动地恢复 PVC +申领的状态并取消重设大小的请求。否则,在没有管理员干预的情况下, +控制器会反复重试重设大小的操作。 -1. 将绑定到 PVC 申领的 PV 卷标记为 `Retain` 回收策略; +1. 将绑定到 PVC 申领的 PV 卷标记为 `Retain` 回收策略。 2. 删除 PVC 对象。由于 PV 的回收策略为 `Retain`,我们不会在重建 PVC 时丢失数据。 3. 删除 PV 规约中的 `claimRef` 项,这样新的 PVC 可以绑定到该卷。 这一操作会使得 PV 卷变为 "可用(Available)"。 @@ -736,12 +733,12 @@ size that is within the capacity limits of underlying storage provider. You can --> 如果集群中的特性门控 `RecoverVolumeExpansionFailure` 已启用,在 PVC 的扩展发生失败时,你可以使用比先前请求的值更小的尺寸来重试扩展。 -要使用一个更小的尺寸尝试请求新的扩展,请编辑该 PVC 的 `.spec.resources` 并选择 -一个比你之前所尝试的值更小的值。 +要使用一个更小的尺寸尝试请求新的扩展,请编辑该 PVC 的 `.spec.resources` +并选择一个比你之前所尝试的值更小的值。 如果由于容量限制而无法成功扩展至更高的值,这将很有用。 -如果发生了这种情况,或者你怀疑可能发生了这种情况,你可以通过指定一个在底层存储供应容量 -限制内的尺寸来重试扩展。你可以通过查看 `.status.resizeStatus` 以及 PVC 上的事件 -来监控调整大小操作的状态。 +如果发生了这种情况,或者你怀疑可能发生了这种情况, +你可以通过指定一个在底层存储制备容量限制内的尺寸来重试扩展。 +你可以通过查看 `.status.resizeStatus` 以及 PVC 上的事件来监控调整大小操作的状态。 @@ -897,8 +893,7 @@ Currently, storage size is the only resource that can be set or requested. Futu 一般而言,每个 PV 卷都有确定的存储容量。 容量属性是使用 PV 对象的 `capacity` 属性来设置的。 -参考词汇表中的 -[量纲(Quantity)](/zh-cn/docs/reference/glossary/?all=true#term-quantity) +参考词汇表中的[量纲(Quantity)](/zh-cn/docs/reference/glossary/?all=true#term-quantity) 词条,了解 `capacity` 字段可以接受的单位。 目前,存储大小是可以设置和请求的唯一资源。 @@ -954,11 +949,9 @@ A PersistentVolume can be mounted on a host in any way supported by the resource ### 访问模式 {#access-modes} PersistentVolume 卷可以用资源提供者所支持的任何方式挂载到宿主系统上。 -如下表所示,提供者(驱动)的能力不同,每个 PV 卷的访问模式都会设置为 -对应卷所支持的模式值。 -例如,NFS 可以支持多个读写客户,但是某个特定的 NFS PV 卷可能在服务器 -上以只读的方式导出。每个 PV 卷都会获得自身的访问模式集合,描述的是 -特定 PV 卷的能力。 +如下表所示,提供者(驱动)的能力不同,每个 PV 卷的访问模式都会设置为对应卷所支持的模式值。 +例如,NFS 可以支持多个读写客户,但是某个特定的 NFS PV 卷可能在服务器上以只读的方式导出。 +每个 PV 卷都会获得自身的访问模式集合,描述的是特定 PV 卷的能力。 -> __重要提醒!__ 每个卷同一时刻只能以一种访问模式挂载,即使该卷能够支持 -> 多种访问模式。例如,一个 GCEPersistentDisk 卷可以被某节点以 ReadWriteOnce -> 模式挂载,或者被多个节点以 ReadOnlyMany 模式挂载,但不可以同时以两种模式 -> 挂载。 +> **重要提醒!** 每个卷同一时刻只能以一种访问模式挂载,即使该卷能够支持多种访问模式。 +> 例如,一个 GCEPersistentDisk 卷可以被某节点以 ReadWriteOnce +> 模式挂载,或者被多个节点以 ReadOnlyMany 模式挂载,但不可以同时以两种模式挂载。 ### 节点亲和性 {#node-affinity} - -每个 PV 卷可以通过设置节点亲和性来定义一些约束,进而限制从哪些节点上可以访问此卷。 -使用这些卷的 Pod 只会被调度到节点亲和性规则所选择的节点上执行。 -要设置节点亲和性,配置 PV 卷 `.spec` 中的 `nodeAffinity`。 -[持久卷](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec) -API 参考关于该字段的更多细节。 - @@ -1183,12 +1165,19 @@ For most volume types, you do not need to set this field. It is automatically po 对大多数类型的卷而言,你不需要设置节点亲和性字段。 [AWS EBS](/zh-cn/docs/concepts/storage/volumes/#awselasticblockstore)、 [GCE PD](/zh-cn/docs/concepts/storage/volumes/#gcepersistentdisk) 和 -[Azure Disk](/zh-cn/docs/concepts/storage/volumes/#azuredisk) 卷类型都能 -自动设置相关字段。 -你需要为 [local](/zh-cn/docs/concepts/storage/volumes/#local) 卷显式地设置 -此属性。 +[Azure Disk](/zh-cn/docs/concepts/storage/volumes/#azuredisk) 卷类型都能自动设置相关字段。 +你需要为 [local](/zh-cn/docs/concepts/storage/volumes/#local) 卷显式地设置此属性。 {{< /note >}} + +每个 PV 卷可以通过设置节点亲和性来定义一些约束,进而限制从哪些节点上可以访问此卷。 +使用这些卷的 Pod 只会被调度到节点亲和性规则所选择的节点上执行。 +要设置节点亲和性,配置 PV 卷 `.spec` 中的 `nodeAffinity`。 +[持久卷](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec) +API 参考关于该字段的更多细节。 + ### 资源 {#resources} 申领和 Pod 一样,也可以请求特定数量的资源。在这个上下文中,请求的资源是存储。 卷和申领都使用相同的 -[资源模型](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md)。 +[资源模型](https://git.k8s.io/design-proposals-archive/scheduling/resources.md)。 PVC 申领不必一定要请求某个类。如果 PVC 的 `storageClassName` 属性值设置为 `""`, -则被视为要请求的是没有设置存储类的 PV 卷,因此这一 PVC 申领只能绑定到未设置 -存储类的 PV 卷(未设置注解或者注解值为 `""` 的 PersistentVolume(PV)对象在系统中不会被删除,因为这样做可能会引起数据丢失。 -未设置 `storageClassName` 的 PVC 与此大不相同,也会被集群作不同处理。 -具体筛查方式取决于 +则被视为要请求的是没有设置存储类的 PV 卷,因此这一 PVC 申领只能绑定到未设置存储类的 +PV 卷(未设置注解或者注解值为 `""` 的 PersistentVolume(PV)对象在系统中不会被删除, +因为这样做可能会引起数据丢失。未设置 `storageClassName` 的 PVC 与此大不相同, +也会被集群作不同处理。具体筛查方式取决于 [`DefaultStorageClass` 准入控制器插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) 是否被启用。 @@ -1348,11 +1336,11 @@ PVC 申领不必一定要请求某个类。如果 PVC 的 `storageClassName` 属 所有未设置 `storageClassName` 的 PVC 都只能绑定到隶属于默认存储类的 PV 卷。 设置默认 StorageClass 的工作是通过将对应 StorageClass 对象的注解 `storageclass.kubernetes.io/is-default-class` 赋值为 `true` 来完成的。 - 如果管理员未设置默认存储类,集群对 PVC 创建的处理方式与未启用准入控制器插件 - 时相同。如果设定的默认存储类不止一个,准入控制插件会禁止所有创建 PVC 操作。 + 如果管理员未设置默认存储类,集群对 PVC 创建的处理方式与未启用准入控制器插件时相同。 + 如果设定的默认存储类不止一个,准入控制插件会禁止所有创建 PVC 操作。 * 如果准入控制器插件被关闭,则不存在默认 StorageClass 的说法。 所有未设置 `storageClassName` 的 PVC 都只能绑定到未设置存储类的 PV 卷。 - 在这种情况下,未设置 `storageClassName` 的 PVC 与 `storageClassName` 设置未 + 在这种情况下,未设置 `storageClassName` 的 PVC 与 `storageClassName` 设置为 `""` 的 PVC 的处理方式相同。 {{< note >}} -目前,设置了非空 `selector` 的 PVC 对象无法让集群为其动态供应 PV 卷。 +目前,设置了非空 `selector` 的 PVC 对象无法让集群为其动态制备 PV 卷。 {{< /note >}} -以下卷插件支持原始块卷,包括其动态供应(如果支持的话)的卷: +以下卷插件支持原始块卷,包括其动态制备(如果支持的话)的卷: * AWSElasticBlockStore * AzureDisk @@ -1502,135 +1490,10 @@ spec: requests: storage: 10Gi ``` - - - -## 卷填充器(Populator)与数据源 {#volume-populators-and-data-sources} - -{{< feature-state for_k8s_version="v1.24" state="beta" >}} - -{{< note >}} -Kubernetes 支持自定义的卷填充器;要使用自定义的卷填充器,你必须为 -kube-apiserver 和 kube-controller-manager 启用 `AnyVolumeDataSource` -[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 -{{< /note >}} - -卷填充器利用了 PVC 规约字段 `dataSourceRef`。 -不像 `dataSource` 字段只能包含对另一个持久卷申领或卷快照的引用, -`dataSourceRef` 字段可以包含对同一命名空间中任何对象的引用(不包含除 PVC 以外的核心资源)。 -对于启用了特性门控的集群,使用 `dataSourceRef` 比 `dataSource` 更好。 - - - -## 数据源引用 {#data-source-references} - -`dataSourceRef` 字段的行为与 `dataSource` 字段几乎相同。 -如果其中一个字段被指定而另一个字段没有被指定,API 服务器将给两个字段相同的值。 -这两个字段都不能在创建后改变,如果试图为这两个字段指定不同的值,将导致验证错误。 -因此,这两个字段将总是有相同的内容。 - - -在 `dataSourceRef` 字段和 `dataSource` 字段之间有两个用户应该注意的区别: -* `dataSource` 字段会忽略无效的值(如同是空值), - 而 `dataSourceRef` 字段永远不会忽略值,并且若填入一个无效的值,会导致错误。 - 无效值指的是 PVC 之外的核心对象(没有 apiGroup 的对象)。 -* `dataSourceRef` 字段可以包含不同类型的对象,而 `dataSource` 字段只允许 PVC 和卷快照。 - -用户应该始终在启用了特性门控的集群上使用 `dataSourceRef`,而在没有启用特性门控的集群上使用 `dataSource`。 -在任何情况下都没有必要查看这两个字段。 -这两个字段的值看似相同但是语义稍微不一样,是为了向后兼容。 -特别是混用旧版本和新版本的控制器时,它们能够互通。 - - -## 使用卷填充器 {#using-volume-populators} - -卷填充器是能创建非空卷的{{< glossary_tooltip text="控制器" term_id="controller" >}}, -其卷的内容通过一个自定义资源决定。 -用户通过使用 `dataSourceRef` 字段引用自定义资源来创建一个被填充的卷: - -```yaml -apiVersion: v1 -kind: PersistentVolumeClaim -metadata: - name: populated-pvc -spec: - dataSourceRef: - name: example-name - kind: ExampleDataSource - apiGroup: example.storage.k8s.io - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 10Gi -``` - - -因为卷填充器是外部组件,如果没有安装所有正确的组件,试图创建一个使用卷填充器的 PVC 就会失败。 -外部控制器应该在 PVC 上产生事件,以提供创建状态的反馈,包括在由于缺少某些组件而无法创建 PVC 的情况下发出警告。 - -你可以把 alpha 版本的[卷数据源验证器](https://github.com/kubernetes-csi/volume-data-source-validator) -控制器安装到你的集群中。 -如果没有填充器处理该数据源的情况下,该控制器会在 PVC 上产生警告事件。 -当一个合适的填充器被安装到 PVC 上时,该控制器的职责是上报与卷创建有关的事件,以及在该过程中发生的问题。 - -### 在容器中添加原始块设备路径的 Pod 规约 +### 在容器中添加原始块设备路径的 Pod 规约 {#pod-spec-adding-raw-block-device-path-in-container} ```yaml apiVersion: v1 @@ -1668,12 +1531,12 @@ Volume binding matrix for statically provisioned volumes: --> ### 绑定块卷 {#binding-block-volumes} -如果用户通过 PersistentVolumeClaim 规约的 `volumeMode` 字段来表明对原始 -块设备的请求,绑定规则与之前版本中未在规约中考虑此模式的实现略有不同。 +如果用户通过 PersistentVolumeClaim 规约的 `volumeMode` 字段来表明对原始块设备的请求, +绑定规则与之前版本中未在规约中考虑此模式的实现略有不同。 下面列举的表格是用户和管理员可以为请求原始块设备所作设置的组合。 此表格表明在不同的组合下卷是否会被绑定。 -静态供应卷的卷绑定矩阵: +静态制备卷的卷绑定矩阵: {{< note >}} -Alpha 发行版本中仅支持静态供应的卷。 +Alpha 发行版本中仅支持静态制备的卷。 管理员需要在处理原始块设备时小心处理这些值。 {{< /note >}} -## 对卷快照及从卷快照中恢复卷的支持 +## 对卷快照及从卷快照中恢复卷的支持 {#volume-snapshot-and-restore-volume-from-snapshot-support} -{{< feature-state for_k8s_version="v1.17" state="beta" >}} +{{< feature-state for_k8s_version="v1.20" state="stable" >}} -卷快照(Volume Snapshot)特性的添加仅是为了支持 CSI 卷插件。 +卷快照(Volume Snapshot)仅支持树外 CSI 卷插件。 有关细节可参阅[卷快照](/zh-cn/docs/concepts/storage/volume-snapshots/)文档。 - -要启用从卷快照数据源恢复数据卷的支持,可在 API 服务器和控制器管理器上启用 -`VolumeSnapshotDataSource` 特性门控。 +树内卷插件被弃用。你可以查阅[卷插件 FAQ](https://git.k8s.io/community/sig-storage/volume-plugin-faq.md) +了解已弃用的卷插件。 ## 卷克隆 {#volume-cloning} -[卷克隆](/zh-cn/docs/concepts/storage/volume-pvc-datasource/)功能特性仅适用于 -CSI 卷插件。 +[卷克隆](/zh-cn/docs/concepts/storage/volume-pvc-datasource/)功能特性仅适用于 CSI 卷插件。 + +## 卷填充器(Populator)与数据源 {#volume-populators-and-data-sources} + +{{< feature-state for_k8s_version="v1.24" state="beta" >}} + +Kubernetes 支持自定义的卷填充器。要使用自定义的卷填充器,你必须为 +kube-apiserver 和 kube-controller-manager 启用 `AnyVolumeDataSource` +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 + +卷填充器利用了 PVC 规约字段 `dataSourceRef`。 +不像 `dataSource` 字段只能包含对另一个持久卷申领或卷快照的引用, +`dataSourceRef` 字段可以包含对同一命名空间中任何对象的引用(不包含除 PVC 以外的核心资源)。 +对于启用了特性门控的集群,使用 `dataSourceRef` 比 `dataSource` 更好。 + + + +## 数据源引用 {#data-source-references} + +`dataSourceRef` 字段的行为与 `dataSource` 字段几乎相同。 +如果其中一个字段被指定而另一个字段没有被指定,API 服务器将给两个字段相同的值。 +这两个字段都不能在创建后改变,如果试图为这两个字段指定不同的值,将导致验证错误。 +因此,这两个字段将总是有相同的内容。 + + +在 `dataSourceRef` 字段和 `dataSource` 字段之间有两个用户应该注意的区别: + +* `dataSource` 字段会忽略无效的值(如同是空值), + 而 `dataSourceRef` 字段永远不会忽略值,并且若填入一个无效的值,会导致错误。 + 无效值指的是 PVC 之外的核心对象(没有 apiGroup 的对象)。 +* `dataSourceRef` 字段可以包含不同类型的对象,而 `dataSource` 字段只允许 PVC 和卷快照。 + +用户应该始终在启用了特性门控的集群上使用 `dataSourceRef`,而在没有启用特性门控的集群上使用 `dataSource`。 +在任何情况下都没有必要查看这两个字段。 +这两个字段的值看似相同但是语义稍微不一样,是为了向后兼容。 +特别是混用旧版本和新版本的控制器时,它们能够互通。 + + +## 使用卷填充器 {#using-volume-populators} + +卷填充器是能创建非空卷的{{< glossary_tooltip text="控制器" term_id="controller" >}}, +其卷的内容通过一个自定义资源决定。 +用户通过使用 `dataSourceRef` 字段引用自定义资源来创建一个被填充的卷: + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: populated-pvc +spec: + dataSourceRef: + name: example-name + kind: ExampleDataSource + apiGroup: example.storage.k8s.io + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi +``` + + +因为卷填充器是外部组件,如果没有安装所有正确的组件,试图创建一个使用卷填充器的 PVC 就会失败。 +外部控制器应该在 PVC 上产生事件,以提供创建状态的反馈,包括在由于缺少某些组件而无法创建 PVC 的情况下发出警告。 + +你可以把 alpha 版本的[卷数据源验证器](https://github.com/kubernetes-csi/volume-data-source-validator) +控制器安装到你的集群中。 +如果没有填充器处理该数据源的情况下,该控制器会在 PVC 上产生警告事件。 +当一个合适的填充器被安装到 PVC 上时,该控制器的职责是上报与卷创建有关的事件,以及在该过程中发生的问题。 + -关于在投射的服务账号卷中处理文件访问权限的[提案](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#proposal) +关于在投射的服务账号卷中处理文件访问权限的[提案](https://git.k8s.io/enhancements/keps/sig-storage/2451-service-account-token-volumes#proposal) 介绍了如何使得所投射的文件具有合适的属主访问权限。 ### Linux diff --git a/content/zh-cn/docs/concepts/storage/volumes.md b/content/zh-cn/docs/concepts/storage/volumes.md index ebe50dd89705b..5466f54f33f05 100644 --- a/content/zh-cn/docs/concepts/storage/volumes.md +++ b/content/zh-cn/docs/concepts/storage/volumes.md @@ -540,11 +540,11 @@ It mounts a directory and writes the requested data in plain text files. 这种卷类型挂载一个目录并在纯文本文件中写入所请求的数据。 {{< note >}} -容器以 [subPath](#using-subpath) 卷挂载方式使用 downwardAPI 时,将不能接收到它的更新。 +容器以 [subPath](#using-subpath) 卷挂载方式使用 downward API 时,在字段值更改时将不能接收到它的更新。 {{< /note >}} 关于 Kubernetes 如何为应用管理 Pods,还有两个支撑概念能够提供相关背景信息: -* [垃圾收集](/zh-cn/docs/concepts/workloads/controllers/garbage-collection/)机制负责在 +* [垃圾收集](/zh-cn/docs/concepts/architecture/garbage-collection/)机制负责在 对象的 _属主资源_ 被删除时在集群中清理这些对象。 * [_Time-to-Live_ 控制器](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/) 会在 Job 结束之后的指定时间间隔之后删除它们。 diff --git a/content/zh-cn/docs/concepts/workloads/controllers/replicaset.md b/content/zh-cn/docs/concepts/workloads/controllers/replicaset.md index 06f8123a5138f..353baa30ca270 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/replicaset.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/replicaset.md @@ -42,22 +42,22 @@ ReplicaSet 是通过一组字段来定义的,包括一个用来识别可获得 进而实现其存在价值。当 ReplicaSet 需要创建新的 Pod 时,会使用所提供的 Pod 模板。 ReplicaSet 通过 Pod 上的 -[metadata.ownerReferences](/zh-cn/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents) +[metadata.ownerReferences](/zh-cn/docs/concepts/architecture/garbage-collection/#owners-and-dependents) 字段连接到附属 Pod,该字段给出当前对象的属主资源。 ReplicaSet 所获得的 Pod 都在其 ownerReferences 字段中包含了属主 ReplicaSet 的标识信息。正是通过这一连接,ReplicaSet 知道它所维护的 Pod 集合的状态, 并据此计划其操作行为。 ReplicaSet 使用其选择算符来辨识要获得的 Pod 集合。如果某个 Pod 没有 OwnerReference 或者其 OwnerReference 不是一个{{< glossary_tooltip text="控制器" term_id="controller" >}}, @@ -408,7 +408,9 @@ matchLabels: {{< note >}} 对于设置了相同的 `.spec.selector`,但 `.spec.template.metadata.labels` 和 `.spec.template.spec` 字段不同的两个 @@ -435,11 +437,13 @@ ReplicaSet 创建、删除 Pod 以与此值匹配。 ### Deleting a ReplicaSet and its Pods -To delete a ReplicaSet and all of its Pods, use [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). The [Garbage collector](/docs/concepts/workloads/controllers/garbage-collection/) automatically deletes all of the dependent Pods by default. +To delete a ReplicaSet and all of its Pods, use +[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). The +[Garbage collector](/docs/concepts/architecture/garbage-collection/) automatically deletes all of +the dependent Pods by default. -When using the REST API or the `client-go` library, you must set `propagationPolicy` to `Background` or `Foreground` in -the -d option. -For example: +When using the REST API or the `client-go` library, you must set `propagationPolicy` to +`Background` or `Foreground` in the `-d` option. For example: --> ## 使用 ReplicaSet {#working-with-replicasets} @@ -447,7 +451,7 @@ For example: 要删除 ReplicaSet 和它的所有 Pod,使用 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 命令。 -默认情况下,[垃圾收集器](/zh-cn/docs/concepts/workloads/controllers/garbage-collection/) +默认情况下,[垃圾收集器](/zh-cn/docs/concepts/architecture/garbage-collection/) 自动删除所有依赖的 Pod。 当使用 REST API 或 `client-go` 库时,你必须在 `-d` 选项中将 `propagationPolicy` @@ -463,7 +467,9 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron @@ -488,7 +494,8 @@ Once the original is deleted, you can create a new ReplicaSet to replace it. As as the old and new `.spec.selector` are the same, then the new one will adopt the old Pods. However, it will not make any effort to make existing Pods match a new, different pod template. To update Pods to a new spec in a controlled way, use a -[Deployment](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment), as ReplicaSets do not support a rolling update directly. +[Deployment](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment), as +ReplicaSets do not support a rolling update directly. --> 一旦删除了原来的 ReplicaSet,就可以创建一个新的来替换它。 由于新旧 ReplicaSet 的 `.spec.selector` 是相同的,新的 ReplicaSet 将接管老的 Pod。 @@ -529,13 +536,13 @@ prioritize scaling down pods based on the following general algorithm: 其一般性算法如下: 1. 首先选择剔除悬决(Pending,且不可调度)的各个 Pod 2. 如果设置了 `controller.kubernetes.io/pod-deletion-cost` 注解,则注解值较小的优先被裁减掉 @@ -677,7 +684,12 @@ ReplicaSet,Deployment 拥有并管理其 ReplicaSet。 ### 裸 Pod {#bare-pods} @@ -691,8 +703,8 @@ ReplicaSet 将本地容器重启的任务委托给了节点上的某个代理( ### Job @@ -718,7 +730,7 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown. ### ReplicationController +{{< note >}} -{{< note >}} 现在推荐使用配置 [`ReplicaSet`](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 的 [`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/) 来建立副本管理机制。 {{< /note >}} @@ -56,7 +56,7 @@ only a single pod. A ReplicationController is similar to a process supervisor, but instead of supervising individual processes on a single node, the ReplicationController supervises multiple pods across multiple nodes. --> -## ReplicationController 如何工作 +## ReplicationController 如何工作 {#how-a-replicationcontroller-works} 当 Pod 数量过多时,ReplicationController 会终止多余的 Pod。当 Pod 数量太少时,ReplicationController 将会启动新的 Pod。 与手动创建的 Pod 不同,由 ReplicationController 创建的 Pod 在失败、被删除或被终止时会被自动替换。 @@ -82,7 +82,7 @@ service, such as web servers. This example ReplicationController config runs three copies of the nginx web server. --> -## 运行一个示例 ReplicationController +## 运行一个示例 ReplicationController {#running-an-example-replicationcontroller} 这个示例 ReplicationController 配置运行 nginx Web 服务器的三个副本。 @@ -187,14 +187,18 @@ specifies an expression with the name from each pod in the returned list. ## Writing a ReplicationController Spec As with all other Kubernetes config, a ReplicationController needs `apiVersion`, `kind`, and `metadata` fields. +The name of a ReplicationController object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). For general information about working with configuration files, see [object management](/docs/concepts/overview/working-with-objects/object-management/). A ReplicationController also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). --> -## 编写一个 ReplicationController 规约 +## 编写一个 ReplicationController 规约 {#writing-a-replicationcontroller-spec} 与所有其它 Kubernetes 配置一样,ReplicationController 需要 `apiVersion`、 `kind` 和 `metadata` 字段。 +ReplicationController 对象的名称必须是有效的 +[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 有关使用配置文件的常规信息,参考 [对象管理](/zh-cn/docs/concepts/overview/working-with-objects/object-management/)。 @@ -205,14 +209,14 @@ ReplicationController 也需要一个 [`.spec` 部分](https://git.k8s.io/commun The `.spec.template` is the only required field of the `.spec`. -The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`. +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. --> ### Pod 模板 {#pod-template} `.spec.template` 是 `.spec` 的唯一必需字段。 `.spec.template` 是一个 [Pod 模板](/zh-cn/docs/concepts/workloads/pods/#pod-templates)。 -它的模式与 [Pod](/zh-cn/docs/concepts/workloads/pods/) 完全相同,只是它是嵌套的,没有 `apiVersion` 或 `kind` 属性。 +它的模式与 {{< glossary_tooltip text="Pod" term_id="pod" >}} 完全相同,只是它是嵌套的,没有 `apiVersion` 或 `kind` 属性。 除了 Pod 所需的字段外,ReplicationController 中的 Pod 模板必须指定适当的标签和适当的重新启动策略。 对于标签,请确保不与其他控制器重叠。参考 [Pod 选择算符](#pod-selector)。 @@ -368,7 +372,7 @@ Pods may be removed from a ReplicationController's target set by changing their -## 常见的使用模式 +## 常见的使用模式 {#common-usage-patterns} ### 滚动更新 {#rolling-updates} @@ -407,17 +411,11 @@ ReplicationController 的设计目的是通过逐个替换 Pod 以方便滚动 Ideally, the rolling update controller would take application readiness into account, and would ensure that a sufficient number of pods were productively serving at any given time. The two ReplicationControllers would need to create pods with at least one differentiating label, such as the image tag of the primary container of the pod, since it is typically image updates that motivate rolling updates. - -Rolling update is implemented in the client tool -[`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update). Visit [`kubectl rolling-update` task](/docs/tasks/run-application/rolling-update-replication-controller/) for more concrete examples. --> 理想情况下,滚动更新控制器将考虑应用程序的就绪情况,并确保在任何给定时间都有足够数量的 Pod 有效地提供服务。 这两个 ReplicationController 将需要创建至少具有一个不同标签的 Pod,比如 Pod 主要容器的镜像标签,因为通常是镜像更新触发滚动更新。 -滚动更新是在客户端工具 [`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) -中实现的。访问 [`kubectl rolling-update` 任务](/zh-cn/docs/tasks/run-application/rolling-update-replication-controller/)以获得更多的具体示例。 - -## 编写多副本的应用 +## 编写多副本的应用 {#writing-programs-for-replication} 由 ReplicationController 创建的 Pod 是可替换的,语义上是相同的, 尽管随着时间的推移,它们的配置可能会变得异构。 @@ -477,9 +475,9 @@ Pods created by a ReplicationController are intended to be fungible and semantic -## ReplicationController 的职责 +## ReplicationController 的职责 {#responsibilities-of-the-replicationcontroller} ReplicationController 仅确保所需的 Pod 数量与其标签选择算符匹配,并且是可操作的。 目前,它的计数中只排除终止的 Pod。 @@ -488,7 +486,7 @@ ReplicationController 仅确保所需的 Pod 数量与其标签选择算符匹 我们计划发出事件,这些事件可以被外部客户端用来实现任意复杂的替换和/或缩减策略。 ReplicationController 永远被限制在这个狭隘的职责范围内。 它本身既不执行就绪态探测,也不执行活跃性探测。 @@ -501,7 +499,7 @@ ReplicationController 永远被限制在这个狭隘的职责范围内。 我们甚至计划考虑批量创建 Pod 的机制(查阅 [#170](https://issue.k8s.io/170))。 ReplicationController 旨在成为可组合的构建基元。 我们希望在它和其他补充原语的基础上构建更高级别的 API 或者工具,以便于将来的用户使用。 @@ -516,7 +514,7 @@ Replication controller is a top-level resource in the Kubernetes REST API. More API object can be found at: [ReplicationController API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replicationcontroller-v1-core). --> -## API 对象 +## API 对象 {#api-object} 在 Kubernetes REST API 中 Replication controller 是顶级资源。 更多关于 API 对象的详细信息可以在 @@ -524,13 +522,14 @@ API object can be found at: -## ReplicationController 的替代方案 +## ReplicationController 的替代方案 {#alternatives-to-replicationcontroller} ### ReplicaSet @@ -569,7 +568,7 @@ ReplicationController 将本地容器重启委托给节点上的某个代理(例 ### Job diff --git a/content/zh-cn/docs/contribute/new-content/open-a-pr.md b/content/zh-cn/docs/contribute/new-content/open-a-pr.md index a0dd88e8e1b67..1e2dc956c1bd5 100644 --- a/content/zh-cn/docs/contribute/new-content/open-a-pr.md +++ b/content/zh-cn/docs/contribute/new-content/open-a-pr.md @@ -23,7 +23,9 @@ 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. +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. --> {{< note >}} **代码开发者们**:如果你在为下一个 Kubernetes 发行版本中的某功能特性撰写文档, @@ -31,14 +33,14 @@ To contribute new content pages or improve existing content pages, open a pull r {{< /note >}} 要贡献新的内容页面或者改进已有内容页面,请发起拉取请求(PR)。 -请确保你满足了[开始之前](/zh-cn/docs/contribute/new-content/#before-you-begin)一节中所列举的所有要求。 +请确保你满足了[开始之前](/zh-cn/docs/contribute/new-content/)一节中所列举的所有要求。 如果你所提交的变更足够小,或者你对 git 工具不熟悉,可以阅读 [使用 GitHub 提交变更](#changes-using-github)以了解如何编辑页面。 @@ -52,12 +54,12 @@ learn how to make changes locally on your computer. ## Changes using GitHub If you're less experienced with git workflows, here's an easier method of -opening a pull request. The figure below outlines the steps and the details follow. +opening a pull request. Figure 1 outlines the steps and the details follow. --> -## 使用 GitHub 提交变更 {#changes-using-github} +## 使用 GitHub 提交变更 {#changes-using-github} 如果你在 git 工作流方面欠缺经验,这里有一种发起拉取请求的更为简单的方法。 -下图勾勒了后续的步骤和细节。 +图 1 勾勒了后续的步骤和细节。 @@ -90,67 +92,75 @@ class tasks,tasks2 white class id1 k8s {{}} -***插图 - 使用 GitHub 发起一个 PR 的步骤*** - +图 1. 使用 GitHub 发起一个 PR 的步骤。 + + 1. 在你发现问题的网页,选择右上角的铅笔图标。 你也可以滚动到页面底端,选择**编辑此页**。 + 2. 在 GitHub 的 Markdown 编辑器中修改内容。 + 3. 在编辑器的下方,填写 **Propose file change** 表单。 在第一个字段中,为你的提交消息取一个标题。 在第二个字段中,为你的提交写一些描述文字。 - + + {{< note >}} 不要在提交消息中使用 [GitHub 关键词](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)。 你可以在后续的 PR 描述中使用这些关键词。 {{< /note >}} + 4. 选择 **Propose File Change**。 + 5. 选择 **Create pull request**。 + 6. 出现 **Open a pull request** 界面。填写表单: - - **Subject** 字段默认为提交的概要信息。你可以根据需要修改它。 - - **Body** 字段包含更为详细的提交消息,如果你之前有填写过的话, - 以及一些模板文字。填写模板所要求的详细信息, - 之后删除多余的模板文字。 - - 确保 **Allow edits from maintainers** 复选框被勾选。 + - **Subject** 字段默认为提交的概要信息。你可以根据需要修改它。 + - **Body** 字段包含更为详细的提交消息,如果你之前有填写过的话, + 以及一些模板文字。填写模板所要求的详细信息, + 之后删除多余的模板文字。 + - 确保 **Allow edits from maintainers** 复选框被勾选。 {{< note >}} PR 描述信息是帮助 PR 评阅人了解你所提议的变更的重要途径。 更多信息请参考[发起一个 PR](#open-a-pr)。 {{< /note >}} - + 7. 选择 **Create pull request**。 -### 在 GitHub 上处理反馈意见 +### 在 GitHub 上处理反馈意见 {#addressing-feedback-in-github} 在合并 PR 之前,Kubernetes 社区成员会评阅并批准它。 `k8s-ci-robot` 会基于页面中最近提及的属主来建议评阅人(reviewers)。 @@ -171,12 +181,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. --> @@ -199,11 +209,12 @@ 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. -The figure below shows the steps to follow when you work from a local fork. The details for each step follow. +Figure 2 shows the steps to follow when you work from a local fork. The details for each step follow. --> -## 基于本地克隆副本开展工作 {#work-from-a-local-fork} +## 基于本地克隆副本开展工作 {#fork-the-repo} 如果你有 git 的使用经验,或者你要提议的修改不仅仅几行,请使用本地克隆副本 来开展工作。 @@ -211,7 +222,7 @@ The figure below shows the steps to follow when you work from a local fork. The 首先要确保你在本地计算机上安装了 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)。 你也可以使用 git 的带用户界面的应用。 -下图显示了基于本地克隆副本开展工作的步骤。 +图 2 显示了基于本地克隆副本开展工作的步骤。 每个步骤的细节如下。 @@ -243,88 +254,90 @@ class changes,changes2 white {{}} -***插图 - 使用本地克隆副本进行修改*** +图 2. 使用本地克隆副本进行修改。 -### 派生 kubernetes/website 仓库 +### 派生 kubernetes/website 仓库 {#fork-the-kubernetes-website-repository} 1. 前往 [`kubernetes/website`](https://github.com/kubernetes/website/) 仓库; -2. 选择 **Fork**. +1. 选择 **Fork**. -### 创建一个本地克隆副本并指定 upstream 仓库 +### 创建一个本地克隆副本并指定 upstream 仓库 {#create-a-local-clone-and-set-the-upstream} -3. 打开终端窗口,克隆你所派生的副本,并更新 [Docsy Hugo 主题](https://github.com/google/docsy#readme): +1. 打开终端窗口,克隆你所派生的副本,并更新 [Docsy Hugo 主题](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. 前往新的 `website` 目录,将 `kubernetes/website` 仓库设置为 `upstream` +2. 前往新的 `website` 目录,将 `kubernetes/website` 仓库设置为 `upstream` 远端: - ```bash - cd website - git remote add upstream https://github.com/kubernetes/website.git - ``` + ```shell + cd website + + git remote add upstream https://github.com/kubernetes/website.git + ``` -5. 确认你现在有两个仓库,`origin` 和 `upstream`: +3. 确认你现在有两个仓库,`origin` 和 `upstream`: - ```bash - git remote -v - ``` + ```shell + git remote -v + ``` - - 输出类似于: + 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. 从你的克隆副本取回 `origin/master` 分支,从 `kubernetes/website` 取回 `upstream/main`: +4. 从你的克隆副本取回 `origin/main` 分支,从 `kubernetes/website` 取回 `upstream/main`: + + ```shell + git fetch origin + git fetch upstream + ``` - ```bash - git fetch origin - git fetch upstream - ``` 这样可以确保你本地的仓库在开始工作前是最新的。 - {{< note >}} - 此工作流程与 [Kubernetes 社区 GitHub 工作流](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)有所不同。 - 在推送你的变更到你的远程派生副本库之前,你不需要将你本地的 `main` 与 `upstream/main` 合并。 - {{< /note >}} + {{< note >}} + 此工作流程与 [Kubernetes 社区 GitHub 工作流](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)有所不同。 + 在推送你的变更到你的远程派生副本库之前,你不需要将你本地的 `main` 与 `upstream/main` 合并。 + {{< /note >}} -### 创建一个分支 +### 创建一个分支 {#create-a-branch} 1. 决定你要基于哪个分支来开展工作: @@ -357,24 +371,24 @@ class changes,changes2 white 如果你在选择分支上需要帮助,请在 `#sig-docs` Slack 频道提问。 2. 基于第 1 步中选定的分支,创建新分支。 下面的例子假定基础分支是 `upstream/main`: - ```bash - git checkout -b upstream/main - ``` + ```shell + git checkout -b upstream/main + ``` + - 3. 使用文本编辑器进行修改。 - 在任何时候,都可以使用 `git status` 命令查看你所改变了的文件列表。 -### 提交你的变更 +### 提交你的变更 {#commit-your-changes} 当你准备好发起拉取请求(PR)时,提交你所做的变更。 1. 在你的本地仓库中,检查你要提交的文件: - ```bash - git status - ``` + ```shell + git status + ``` - 输出类似于: + + 输出类似于: - ```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. 将 **Changes not staged for commit** 下列举的文件添加到提交中: - ```bash - git add - ``` - - 针对每个文件重复此操作。 - + 针对每个文件重复此操作。 - {{< 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 >}} + 3. 添加完所有文件之后,创建一个提交(commit): - ```bash - git commit -m "Your commit message" - ``` + ```shell + git commit -m "Your commit message" + ``` - {{< note >}} - 不要在提交消息中使用任何 [GitHub 关键词](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)。 - 你可以在后续的 PR 描述中使用这些关键词。 - {{< /note >}} - + {{< note >}} + 不要在提交消息中使用任何 [GitHub 关键词](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)。 + 你可以在后续的 PR 描述中使用这些关键词。 + {{< /note >}} - ```bash - git push origin - ``` + 4. 推送你本地分支及其中的新提交到你的远程派生副本库: - ```bash - git push origin - ``` + ```shell + git push origin + ``` -### 在本地预览你的变更 {#preview-locally} +### 在本地预览你的变更 {#preview-locally} 在推送变更或者发起 PR 之前在本地查看一下预览是个不错的主意。 通过预览你可以发现构建错误或者 Markdown 格式问题。 @@ -500,9 +492,8 @@ You can either build the website's container image or run Hugo locally. Building {{% tab name="在容器内执行 Hugo" %}} {{< note >}} 下面的命令中使用 Docker 作为默认的容器引擎。 @@ -510,39 +501,33 @@ The commands below use Docker as default container engine. Set the `CONTAINER_EN {{< /note >}} -1. 在本地构建镜像: - - ```bash - # 使用 docker (默认) - make container-image +1. 在本地构建容器镜像 + _如果你正在测试对 Hugo 工具本身的更改,则仅需要此步骤_ - ### 或 ### - - # 使用 podman - CONTAINER_ENGINE=podman make container-image - ``` + ```shell + # 在终端窗口中执行(如果有需要) + make container-image + ``` -2. 在本地构建了 `kubernetes-hugo` 镜像之后,可以构建并启动网站: +2. 在容器中启动 Hugo: - ```bash - # 使用 docker (默认) - make container-serve - - ### 或 ### + ```shell + # 在终端窗口中执行 + make container-serve + ``` - # 使用 podman - CONTAINER_ENGINE=podman make container-serve - ``` 3. 启动浏览器,浏览 `https://localhost:1313`。 Hugo 会监测文件的变更并根据需要重新构建网站。 @@ -558,10 +543,11 @@ Alternately, install and use the `hugo` command on your computer: 另一种方式是,在你的本地计算机上安装并使用 `hugo` 命令: 1. 安装 [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml) 文件中指定的 [Hugo](https://gohugo.io/getting-started/installing/) 版本。 @@ -570,24 +556,30 @@ Alternately, install and use the `hugo` command on your computer: 如果本地缺少主题的副本,则该站点无法构建。 要更新网站主题,运行以下命令: - ```bash - git submodule update --init --recursive --depth 1 - ``` + ```shell + git submodule update --init --recursive --depth 1 + ``` + 3. 启动一个终端窗口,进入 Kubernetes 网站仓库目录,启动 Hugo 服务器: - ```bash - cd /website - hugo server - ``` + ```shell + cd /website + hugo server --buildFuture + ``` + 4. 在浏览器的地址栏输入: `https://localhost:1313`。 Hugo 会监测文件的变更并根据需要重新构建网站。 + 5. 要停止本地 Hugo 实例,返回到终端窗口并输入 `Ctrl+C` 或者关闭终端窗口。 {{% /tab %}} @@ -596,12 +588,12 @@ Alternately, install and use the `hugo` command on your computer: -### 从你的克隆副本向 kubernetes/website 发起拉取请求(PR) {#open-a-pr} +### 从你的克隆副本向 kubernetes/website 发起拉取请求(PR) {#open-a-pr} -下图显示了从你的克隆副本向 K8s/website 发起 PR 的步骤。 +图 3 显示了从你的克隆副本向 K8s/website 发起 PR 的步骤。 详细信息如下。 @@ -629,58 +621,71 @@ classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:b class 1,2,3,4,5,6,7,8 grey class first,second white {{}} + -***插图 - 从你的克隆副本向 K8s/website 发起一个 PR 的步骤*** +图 3. 从你的克隆副本向 K8s/website 发起一个 PR 的步骤。 1. 在 Web 浏览器中,前往 [`kubernetes/website`](https://github.com/kubernetes/website/) 仓库; -2. 点击 **New Pull Request**; -3. 选择 **compare across forks**; -4. 从 **head repository** 下拉菜单中,选取你的派生仓库; -5. 从 **compare** 下拉菜单中,选择你的分支; -6. 点击 **Create Pull Request**; -7. 为你的拉取请求添加一个描述: +1. 点击 **New Pull Request**; +1. 选择 **compare across forks**; +1. 从 **head repository** 下拉菜单中,选取你的派生仓库; +1. 从 **compare** 下拉菜单中,选择你的分支; +1. 点击 **Create Pull Request**; +1. 为你的拉取请求添加一个描述: + - **Title** (不超过 50 个字符):总结变更的目的; - **Description**:给出变更的详细信息; + - 如果存在一个相关联的 GitHub Issue,可以在描述中包含 `Fixes #12345` 或 `Closes #12345`。GitHub 的自动化设施能够在当前 PR 被合并时自动关闭所提及 的 Issue。如果有其他相关联的 PR,也可以添加对它们的链接。 - 如果你特别希望获得某方面的建议,可以在描述中包含你希望评阅人思考的问题。 -8. 点击 **Create pull request** 按钮。 - 祝贺你!你的拉取请求现在出现在 [Pull Requests](https://github.com/kubernetes/website/pulls) 列表中了! +1. 点击 **Create pull request** 按钮。 + +祝贺你!你的拉取请求现在出现在 [Pull Requests](https://github.com/kubernetes/website/pulls) 列表中了! 在发起 PR 之后,GitHub 会执行一些自动化的测试,并尝试使用 [Netlify](https://www.netlify.com/) 部署一个预览版本。 - - 如果 Netlify 构建操作失败,可选择 **Details** 了解详细信息。 - - 如果 Netlify 构建操作成功,选择 **Details** 会打开 Kubernetes 的一个预览 - 版本,其中包含了你所作的变更。评阅人也使用这一功能来检查你的变更。 +- 如果 Netlify 构建操作失败,可选择 **Details** 了解详细信息。 +- 如果 Netlify 构建操作成功,选择 **Details** 会打开 Kubernetes 的一个预览版本, + 其中包含了你所作的变更。评阅人也使用这一功能来检查你的变更。 GitHub 也会自动为 PR 分派一些标签,以帮助评阅人。 如果有需要,你也可以向 PR 添加标签。 @@ -692,32 +697,33 @@ GitHub 也会自动为 PR 分派一些标签,以帮助评阅人。 1. After making your changes, amend your previous commit: --> -### 在本地处理反馈 +### 在本地处理反馈 {#addressing-feedback-locally} 1. 在本地完成修改之后,可以修补(amend)你之前的提交: - ```bash - git commit -a --amend - ``` + ```shell + git commit -a --amend + ``` - - - `-a`:提交所有修改 - - `--amend`:对前一次提交进行增补,而不是创建新的提交 + + - `-a`:提交所有修改 + - `--amend`:对前一次提交进行增补,而不是创建新的提交 2. 如果有必要,更新你的提交消息; + 3. 使用 `git push origin ` 来推送你的变更,重新触发 Netlify 测试。 {{< note >}} 如果你使用 `git commit -m` 而不是增补参数,在 PR 最终合并之前你必须 @@ -731,43 +737,45 @@ Sometimes reviewers commit to your pull request. Before making any other changes 1. Fetch commits from your remote fork and rebase your working branch: --> -#### 来自评阅人的修改 +#### 来自评阅人的修改 {#changes-from-reviewers} 有时评阅人会向你的 PR 中提交修改。在作出其他修改之前,请先取回这些提交。 1. 从你的远程派生副本仓库取回提交,让你的工作分支基于所取回的分支: - ```bash - git fetch origin - git rebase origin/ - ``` + ```shell + git fetch origin + git rebase origin/ + ``` + 2. 变更基线(rebase)操作完成之后,强制推送本地的新改动到你的派生仓库: - ```bash - git push --force-with-lease origin - ``` + ```shell + git push --force-with-lease origin + ``` -#### 合并冲突和重设基线 +#### 合并冲突和重设基线 {#merge-conflicts-and-rebasing} {{< note >}} 要了解更多信息,可参考 -[Git 分支管理 - 基本分支和合并](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts)、 -[高级合并](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging), +[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), 或者在 `#sig-docs` Slack 频道寻求帮助。 {{< /note >}} @@ -776,99 +784,108 @@ If another contributor commits changes to the same file in another PR, it can cr 1. 更新你的派生副本,重设本地分支的基线: - ```bash + ```shell git fetch origin git rebase origin/ ``` - + 之后强制推送修改到你的派生副本仓库: - ```bash + ```shell git push --force-with-lease origin ``` + 2. 从 `kubernetes/website` 的 `upstream/main` 分支取回更改,然后重设本地分支的基线: - ```bash + ```shell git fetch upstream git rebase upstream/main ``` + 3. 检查重设基线操作之后的状态: - ```bash + ```shell git status ``` - + 你会看到一组存在冲突的文件。 4. 打开每个存在冲突的文件,查找冲突标记:`>>>`、`<<<` 和 `===`。 解决完冲突之后删除冲突标记。 - - {{< note >}} - 进一步的详细信息可参见 - [冲突是怎样表示的](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented). - {{< /note >}} + + {{< note >}} + 进一步的详细信息可参见 + [冲突是怎样表示的](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented). + {{< /note >}} 5. 添加文件到变更集合: - ```bash - git add - ``` + ```shell + git add + ``` + 6. 继续执行基线变更(rebase)操作: - ```bash - git rebase --continue - ``` + ```shell + git rebase --continue + ``` 7. 根据需要重复步骤 2 到 5。 在应用完所有提交之后,`git status` 命令会显示 rebase 操作完成。 8. 将分支强制推送到你的派生仓库: - ```bash - git push --force-with-lease origin - ``` + ```shell + git push --force-with-lease origin + ``` - - PR 不再显示存在冲突。 + + PR 不再显示存在冲突。 -### 压缩(Squashing)提交 {#squashing-commits} +### 压缩(Squashing)提交 {#squashing-commits} {{< note >}} 要了解更多信息,可参看 @@ -877,13 +894,17 @@ For more information, see [Git Tools - Rewriting History](https://git-scm.com/bo {{< /note >}} 如果你的 PR 包含多个提交(commits),你必须将其压缩成一个提交才能被合并。 你可以在 PR 的 **Commits** Tab 页面查看提交个数,也可以在本地通过 `git log` 命令查看提交个数。 - + {{< note >}} 本主题假定使用 `vim` 作为命令行文本编辑器。 {{< /note >}} @@ -893,103 +914,113 @@ If your PR has multiple commits, you must squash them into a single commit befor --> 1. 启动一个交互式的 rebase 操作: - ```bash - git rebase -i HEAD~ - ``` + ```shell + git rebase -i HEAD~ + ``` - - 压缩提交的过程也是一种重设基线的过程。 - 这里的 `-i` 开关告诉 git 你希望交互式地执行重设基线操作。 - `HEAD~ + 压缩提交的过程也是一种重设基线的过程。 + 这里的 `-i` 开关告诉 git 你希望交互式地执行重设基线操作。 + `HEAD~ - 输出类似于; + + 输出类似于; - ```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 - # Rebase 3d18sf680..7d54e15ee onto 3d183f680 (3 commands) + # Rebase 3d18sf680..7d54e15ee onto 3d183f680 (3 commands) - ... + ... - # These lines can be re-ordered; they are executed from top to bottom. - ``` + # These lines can be re-ordered; they are executed from top to bottom. + ``` - - 输出的第一部分列举了重设基线操作中的提交。 - 第二部分给出每个提交的选项。 - 改变单词 `pick` 就可以改变重设基线操作之后提交的状态。 + For the purposes of rebasing, focus on `squash` and `pick`. + --> + 输出的第一部分列举了重设基线操作中的提交。 + 第二部分给出每个提交的选项。 + 改变单词 `pick` 就可以改变重设基线操作之后提交的状态。 - 就重设基线操作本身,我们关注 `squash` 和 `pick` 选项。 + 就重设基线操作本身,我们关注 `squash` 和 `pick` 选项。 - - {{< note >}} - 进一步的详细信息可参考 [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode)。 - {{< /note >}} + + {{< note >}} + 进一步的详细信息可参考 [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode)。 + {{< /note >}} 2. 开始编辑文件。 - 修改原来的文本: + 修改原来的文本: - ```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 + ``` - - 使之成为: + + 使之成为: - ```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 + ``` - - 以上编辑操作会压缩提交 `4fa167b80 Address feedback 1` 和 `7d54e15ee Address feedback 2` - 到 `d875112ca Original commit` 中,只留下 `d875112ca Original commit` 成为时间线中的一部分。 + + 以上编辑操作会压缩提交 `4fa167b80 Address feedback 1` 和 `7d54e15ee Address feedback 2` + 到 `d875112ca Original commit` 中,只留下 `d875112ca Original commit` 成为时间线中的一部分。 3. 保存文件并退出编辑器。 4. 推送压缩后的提交: - ```bash - git push --force-with-lease origin - ``` + ```shell + git push --force-with-lease origin + ``` -## 贡献到其他仓库 +## 贡献到其他仓库 {#contribute-to-other-repos} [Kubernetes 项目](https://github.com/kubernetes)包含大约 50 多个仓库。 这些仓库中很多都有文档:提供给最终用户的帮助文本、错误信息、API 参考或者代码注释等。 @@ -998,13 +1029,12 @@ This can help you figure out where to submit your issue or PR. 这样有助于发现要在哪里提交 Issue 或 PR。 每个仓库有其自己的流程和过程。在登记 Issue 或者发起 PR 之前, 记得阅读仓库可能存在的 `README.md`、`CONTRIBUTING.md` 和 @@ -1018,7 +1048,7 @@ the templates with as much detail as possible when you file issues or PRs. ## {{% heading "whatsnext" %}} - 阅读[评阅](/zh-cn/docs/contribute/review/reviewing-prs)节,学习评阅过程。 diff --git a/content/zh-cn/docs/reference/access-authn-authz/authorization.md b/content/zh-cn/docs/reference/access-authn-authz/authorization.md index fbac09ef6071e..ba70c2b36dd3d 100644 --- a/content/zh-cn/docs/reference/access-authn-authz/authorization.md +++ b/content/zh-cn/docs/reference/access-authn-authz/authorization.md @@ -158,6 +158,14 @@ PUT | update PATCH | patch DELETE | delete(针对单个资源)、deletecollection(针对集合) +{{< caution >}} + +`get`、`list` 和 `watch` 动作都可以返回一个资源的完整详细信息。就返回的数据而言,它们是等价的。 +例如,对 `secrets` 使用 `list` 仍然会显示所有已返回资源的 `data` 属性。 +{{< /caution >}} + - - ## {{% heading "synopsis" %}} 从度量值标签到准许值列表的映射。键名的格式为<MetricName>,<LabelName>。 准许值的格式为<allowed_value>,<allowed_value>...。 -例如,metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' +例如,metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3', metric2,label='v1,v2,v3'

--enable-dynamic-provisioning     默认值:true
--enable-taint-manager     默认值:true

systemReservedCgroup帮助 kubelet 识别用来为 OS 系统级守护进程实施 systemReserved计算资源预留时使用的顶级控制组(CGroup)。 -参考 Node Allocatable +参考 Node Allocatable 以了解详细信息。

默认值:""

kubeReservedCgroup 帮助 kubelet 识别用来为 Kubernetes 节点系统级守护进程实施 kubeReserved计算资源预留时使用的顶级控制组(CGroup)。 -参阅 Node Allocatable +参阅 Node Allocatable 了解进一步的信息。

默认值:""