whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'upstream/main' into dev-1.24

Browse Source
This commit is contained in:
Nate W
2022-02-15 08:28:12 -08:00
parent c3c3b1a7ac a04f1c9f4a
commit 8b9e77db12
82 changed files with 4905 additions and 1675 deletions
Download Patch File Download Diff File Expand all files Collapse all files
assets/scss/_custom.scss
+5
View File
@@ -402,6 +402,11 @@ body {
color: #000;
}
.deprecation-warning.outdated-blog, .pageinfo.deprecation-warning.outdated-blog {
background-color: $blue;
color: $white;
}
body.td-home .deprecation-warning, body.td-blog .deprecation-warning, body.td-documentation .deprecation-warning {
border-radius: 3px;
}
content/en/docs/concepts/cluster-administration/logging.md
+3 -1
View File
@@ -12,7 +12,9 @@ weight: 60
Application logs can help you understand what is happening inside your application. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism. Likewise, container engines are designed to support logging. The easiest and most adopted logging method for containerized applications is writing to standard output and standard error streams.
However, the native functionality provided by a container engine or runtime is usually not enough for a complete logging solution.
For example, you may want to access your application's logs if a container crashes, a pod gets evicted, or a node dies.
In a cluster, logs should have a separate storage and lifecycle independent of nodes, pods, or containers. This concept is called _cluster-level logging_.
<!-- body -->
@@ -141,7 +143,7 @@ as a `DaemonSet`.
Node-level logging creates only one agent per node and doesn't require any changes to the applications running on the node.
Containers write stdout and stderr, but with no agreed format. A node-level agent collects these logs and forwards them for aggregation.
Containers write to stdout and stderr, but with no agreed format. A node-level agent collects these logs and forwards them for aggregation.
### Using a sidecar container with the logging agent {#sidecar-container-with-logging-agent}
content/en/docs/concepts/configuration/manage-resources-containers.md
+1 -1
View File
@@ -801,6 +801,6 @@ memory limit (and possibly request) for that container.
* Get hands-on experience [assigning CPU resources to containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/).
* Read how the API reference defines a [container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)
and its [resource requirements](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources)
* Read about [project quotas](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS
* Read about [project quotas](https://xfs.org/index.php/XFS_FAQ#Q:_Quota:_Do_quotas_work_on_XFS.3F) in XFS
* Read more about the [kube-scheduler configuration reference (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
content/en/docs/concepts/containers/container-lifecycle-hooks.md
+13 -13
View File
@@ -105,22 +105,22 @@ The logs for a Hook handler are not exposed in Pod events.
If a handler fails for some reason, it broadcasts an event.
For `PostStart`, this is the `FailedPostStartHook` event,
and for `PreStop`, this is the `FailedPreStopHook` event.
You can see these events by running `kubectl describe pod <pod_name>`.
Here is some example output of events from running this command:
To generate a failed `FailedPreStopHook` event yourself, modify the [lifecycle-events.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/lifecycle-events.yaml) file to change the postStart command to "badcommand" and apply it.
Here is some example output of the resulting events you see from running `kubectl describe pod lifecycle-demo`:
```
Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567
38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 7s default-scheduler Successfully assigned default/lifecycle-demo to ip-XXX-XXX-XX-XX.us-east-2...
Normal Pulled 6s kubelet Successfully pulled image "nginx" in 229.604315ms
Normal Pulling 4s (x2 over 6s) kubelet Pulling image "nginx"
Normal Created 4s (x2 over 5s) kubelet Created container lifecycle-demo-container
Normal Started 4s (x2 over 5s) kubelet Started container lifecycle-demo-container
Warning FailedPostStartHook 4s (x2 over 5s) kubelet Exec lifecycle hook ([badcommand]) for Container "lifecycle-demo-container" in Pod "lifecycle-demo_default(30229739-9651-4e5a-9a32-a8f1688862db)" failed - error: command 'badcommand' exited with 126: , message: "OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: \"badcommand\": executable file not found in $PATH: unknown\r\n"
Normal Killing 4s (x2 over 5s) kubelet FailedPostStartHook
Normal Pulled 4s kubelet Successfully pulled image "nginx" in 215.66395ms
Warning BackOff 2s (x2 over 3s) kubelet Back-off restarting failed container
```
content/en/docs/concepts/overview/working-with-objects/finalizers.md
+13 -8
View File
@@ -21,18 +21,21 @@ your own.
When you create a resource using a manifest file, you can specify finalizers in
the `metadata.finalizers` field. When you attempt to delete the resource, the
controller that manages it notices the values in the `finalizers` field and does
the following:
API server handling the delete request notices the values in the `finalizers` field
and does the following:
* Modifies the object to add a `metadata.deletionTimestamp` field with the
time you started the deletion.
* Marks the object as read-only until its `metadata.finalizers` field is empty.
* Prevents the object from being removed until its `metadata.finalizers` field is empty.
* Returns a `202` status code (HTTP "Accepted")
The controller managing that finalizer notices the update to the object setting the
`metadata.deletionTimestamp`, indicating deletion of the object has been requested.
The controller then attempts to satisfy the requirements of the finalizers
specified for that resource. Each time a finalizer condition is satisfied, the
controller removes that key from the resource's `finalizers` field. When the
field is empty, garbage collection continues. You can also use finalizers to
prevent deletion of unmanaged resources.
`finalizers` field is emptied, an object with a `deletionTimestamp` field set
is automatically deleted. You can also use finalizers to prevent deletion of unmanaged resources.
A common example of a finalizer is `kubernetes.io/pv-protection`, which prevents
accidental deletion of `PersistentVolume` objects. When a `PersistentVolume`
@@ -63,16 +66,18 @@ Kubernetes also processes finalizers when it identifies owner references on a
resource targeted for deletion.
In some situations, finalizers can block the deletion of dependent objects,
which can cause the targeted owner object to remain in a read-only state for
which can cause the targeted owner object to remain for
longer than expected without being fully deleted. In these situations, you
should check finalizers and owner references on the target owner and dependent
objects to troubleshoot the cause.
{{<note>}}
In cases where objects are stuck in a deleting state, try to avoid manually
In cases where objects are stuck in a deleting state, avoid manually
removing finalizers to allow deletion to continue. Finalizers are usually added
to resources for a reason, so forcefully removing them can lead to issues in
your cluster.
your cluster. This should only be done when the purpose of the finalizer is
understood and is accomplished in another way (for example, manually cleaning
up some dependent object).
{{</note>}}
## {{% heading "whatsnext" %}}
content/en/docs/concepts/services-networking/ingress-controllers.md
+1
View File
@@ -48,6 +48,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
is an ingress controller driving [Kong Gateway](https://konghq.com/kong/).
* The [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx-ingress-controller/)
works with the [NGINX](https://www.nginx.com/resources/glossary/nginx/) webserver (as a proxy).
* The [Pomerium Ingress Controller](https://www.pomerium.com/docs/k8s/ingress.html) is based on [Pomerium](https://pomerium.com/), which offers context-aware access policy.
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy.
* The [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/) is an
ingress controller for the [Traefik](https://traefik.io/traefik/) proxy.
content/en/docs/concepts/services-networking/topology-aware-hints.md
+1 -1
View File
@@ -30,7 +30,7 @@ Routing". When calculating the endpoints for a {{< glossary_tooltip term_id="Ser
the EndpointSlice controller considers the topology (region and zone) of each endpoint
and populates the hints field to allocate it to a zone.
Cluster components such as the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}
can then consume those hints, and use them to influence how traffic to is routed
can then consume those hints, and use them to influence how the traffic is routed
(favoring topologically closer endpoints).
## Using Topology Aware Hints
content/en/docs/concepts/workloads/controllers/job.md
+1 -1
View File
@@ -308,7 +308,7 @@ cleaned up by CronJobs based on the specified capacity-based cleanup policy.
### TTL mechanism for finished Jobs
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
Another way to clean up finished Jobs (either `Complete` or `Failed`)
automatically is to use a TTL mechanism provided by a
content/en/docs/contribute/review/reviewing-prs.md
+2 -2
View File
@@ -36,7 +36,7 @@ Before you start a review:
## Review process
In general, review pull requests for content and style in English. The figure below outlines the steps for the review process. The details for each step follow.
In general, review pull requests for content and style in English. Figure 1 outlines the steps for the review process. The details for each step follow.
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
@@ -67,7 +67,7 @@ class S,T spacewhite
class third,fourth white
{{</ mermaid >}}
***Figure - Review process steps***
Figure 1. Review process steps.
1. Go to
[https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls).
content/en/docs/contribute/style/diagram-guide.md
+184 -76
View File
@@ -7,9 +7,13 @@ weight: 15
<!--Overview-->
This guide shows you how to create, edit and share diagrams using the Mermaid Javascript library. Mermaid.js allows you to generate diagrams using a simple markdown-like syntax inside Markdown files. You can also use Mermaid to generate `.svg` or `.png` image files that you can add to your documentation.
This guide shows you how to create, edit and share diagrams using the Mermaid
Javascript library. Mermaid.js allows you to generate diagrams using a simple
markdown-like syntax inside Markdown files. You can also use Mermaid to
generate `.svg` or `.png` image files that you can add to your documentation.
The target audience for this guide is anybody wishing to learn about Mermaid and/or how to create and add diagrams to Kubernetes documentation.
The target audience for this guide is anybody wishing to learn about Mermaid
and/or how to create and add diagrams to Kubernetes documentation.
Figure 1 outlines the topics covered in this section.
@@ -54,11 +58,12 @@ All you need to begin working with Mermaid is the following:
* Using the Mermaid live editor.
* Using [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/).
* Using the [Hugo {{</* figure */>}} shortcode](https://gohugo.io/content-management/shortcodes/#figure).
* Performing [Hugo local previews](https://kubernetes.io/docs/contribute/new-content/open-a-pr/#preview-locally).
* Performing [Hugo local previews](/docs/contribute/new-content/open-a-pr/#preview-locally).
* Familiar with the [Contributing new content](/docs/contribute/new-content/) process.
{{< note >}}
You can click on each diagram in this section to view the code and rendered diagram in the Mermaid live editor.
You can click on each diagram in this section to view the code and rendered
diagram in the Mermaid live editor.
{{< /note >}}
<!--body-->
@@ -69,21 +74,32 @@ Diagrams improve documentation clarity and comprehension. There are advantages f
The user benefits include:
* __Friendly landing spot__. A detailed text-only greeting page could intimidate users, in particular, first-time Kubernetes users.
* __Faster grasp of concepts__. A diagram can help users understand the key points of a complex topic. Your diagram can serve as a visual learning guide to dive into the topic details.
* __Friendly landing spot__. A detailed text-only greeting page could
intimidate users, in particular, first-time Kubernetes users.
* __Faster grasp of concepts__. A diagram can help users understand the key
points of a complex topic. Your diagram can serve as a visual learning guide
to dive into the topic details.
* __Better retention__. For some, it is easier to recall pictures rather than text.
The contributor benefits include:
* __Assist in developing the structure and content__ of your contribution. For example, you can start with a simple diagram covering the high-level points and then dive into details.
* __Expand and grow the user community__. Easily consumed documentation augmented with diagrams attracts new users who might previously have been reluctant to engage due to perceived complexities.
You should consider your target audience. In addition to experienced K8s users, you will have many who are new to Kubernetes. Even a simple diagram can assist new users in absorbing Kubernetes concepts. They become emboldened and more confident to further explore Kubernetes and the documentation.
* __Assist in developing the structure and content__ of your contribution. For
example, you can start with a simple diagram covering the high-level points
and then dive into details.
* __Expand and grow the user community__. Easily consumed documentation
augmented with diagrams attracts new users who might previously have been
reluctant to engage due to perceived complexities.
You should consider your target audience. In addition to experienced K8s
users, you will have many who are new to Kubernetes. Even a simple diagram can
assist new users in absorbing Kubernetes concepts. They become emboldened and
more confident to further explore Kubernetes and the documentation.
## Mermaid
[Mermaid](https://mermaid-js.github.io/mermaid/#/) is an open source JavaScript library that allows you to create, edit and easily share diagrams using a simple, markdown-like syntax configured inline in Markdown files.
[Mermaid](https://mermaid-js.github.io/mermaid/#/) is an open source
JavaScript library that allows you to create, edit and easily share diagrams
using a simple, markdown-like syntax configured inline in Markdown files.
The following lists features of Mermaid:
@@ -93,35 +109,40 @@ The following lists features of Mermaid:
* Easy collaboration with colleagues by sharing a per-diagram URL.
* Broad selection of shapes, lines, themes and styling.
The following lists advantages of using Mermaid:
* No need for separate, non-Mermaid diagram tools.
* Adheres to existing PR workflow. You can think of Mermaid code as just Markdown text included in your PR.
* Simple tool builds simple diagrams. You don't want to get bogged down (re)crafting an overly complex and detailed picture. Keep it simple!
* Adheres to existing PR workflow. You can think of Mermaid code as just
Markdown text included in your PR.
* Simple tool builds simple diagrams. You don't want to get bogged down
(re)crafting an overly complex and detailed picture. Keep it simple!
Mermaid provides a simple, open and transparent method for the SIG communities to add, edit and collaborate on diagrams for new or existing documentation.
Mermaid provides a simple, open and transparent method for the SIG communities
to add, edit and collaborate on diagrams for new or existing documentation.
{{< note >}}
You can still use Mermaid to create/edit diagrams even if it's not supported in your environment. This method is called __Mermaid+SVG__ and is explained below.
You can still use Mermaid to create/edit diagrams even if it's not supported
in your environment. This method is called __Mermaid+SVG__ and is explained
below.
{{< /note >}}
### Live editor
The [Mermaid live editor](https://mermaid-js.github.io/mermaid-live-editor) is a web-based tool that enables you to create, edit and review diagrams.
The [Mermaid live editor](https://mermaid-js.github.io/mermaid-live-editor) is
a web-based tool that enables you to create, edit and review diagrams.
The following lists live editor functions:
* Displays Mermaid code and rendered diagram.
* Generates a URL for each saved diagram. The URL is displayed in the URL field of your browser. You can share the URL with colleagues who can access and modify the diagram.
* Generates a URL for each saved diagram. The URL is displayed in the URL
field of your browser. You can share the URL with colleagues who can access
and modify the diagram.
* Option to download `.svg` or `.png` files.
{{< note >}}
The live editor is the easiest and fastest way to create and edit Mermaid diagrams.
{{< /note >}}
## Methods for creating diagrams
Figure 2 outlines the three methods to generate and add diagrams.
@@ -157,7 +178,8 @@ Figure 2. Methods to create diagrams.
### Inline
Figure 3 outlines the steps to follow for adding a diagram using the Inline method.
Figure 3 outlines the steps to follow for adding a diagram using the Inline
method.
{{< mermaid >}}
graph LR
@@ -182,7 +204,6 @@ click D "https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiZ3Jh
{{< /mermaid >}}
Figure 3. Inline Method steps.
@@ -196,8 +217,11 @@ The following lists the steps you should follow for adding a diagram using the I
4. Add a caption below the diagram using Markdown text.
A Hugo build runs the Mermaid code and turns it into a diagram.
{{< note >}}
You may find keeping track of diagram URLs is cumbersome. If so, make a note in the `.md` file that the Mermaid code is self-documenting. Contributors can copy the Mermaid code to and from the live editor for diagram edits.
You may find keeping track of diagram URLs is cumbersome. If so, make a note
in the `.md` file that the Mermaid code is self-documenting. Contributors can
copy the Mermaid code to and from the live editor for diagram edits.
{{< /note >}}
Here is a sample code snippet contained in an `.md` file:
@@ -218,7 +242,9 @@ Figure 17. A to B
more text
```
{{< note >}}
You must include the `{{</* mermaid */>}}`, `{{</* /mermaid */>}}` shortcode tags at the start and end of the Mermaid code block. You should add a diagram caption below the diagram.
You must include the `{{</* mermaid */>}}`, `{{</* /mermaid */>}}` shortcode
tags at the start and end of the Mermaid code block. You should add a diagram
caption below the diagram.
{{< /note >}}
For more details on diagram captions, see [How to use captions](#how-to-use-captions).
@@ -230,10 +256,13 @@ The following lists advantages of the Inline method:
* No need for separate `.svg` image file handling.
* Content text, diagram code and diagram caption contained in the same `.md` file.
You should use the [local](https://kubernetes.io/docs/contribute/new-content/open-a-pr/#preview-locally) and Netlify previews to verify the diagram is properly rendered.
You should use the [local](/docs/contribute/new-content/open-a-pr/#preview-locally)
and Netlify previews to verify the diagram is properly rendered.
{{< caution >}}
The Mermaid live editor feature set may not support the K8s/website Mermaid feature set. You might see a syntax error or a blank screen after the Hugo build. If that is the case, consider using the Mermaid+SVG method.
The Mermaid live editor feature set may not support the K8s/website Mermaid feature set.
You might see a syntax error or a blank screen after the Hugo build.
If that is the case, consider using the Mermaid+SVG method.
{{< /caution >}}
### Mermaid+SVG
@@ -281,9 +310,13 @@ The following lists the steps you should follow for adding a diagram using the M
4. Use the `{{</* figure */>}}` shortcode to reference the diagram in the `.md` file.
5. Add a caption using the `{{</* figure */>}}` shortcode's `caption` parameter.
For example, use the live editor to create a diagram called `boxnet`. Store the diagram URL somewhere for later access. Generate and download a `boxnet.svg` file to the appropriate `../images/` folder.
For example, use the live editor to create a diagram called `boxnet`.
Store the diagram URL somewhere for later access. Generate and download a
`boxnet.svg` file to the appropriate `../images/` folder.
Use the `{{</* figure */>}}` shortcode in your PR's `.md` file to reference
the `.svg` image file and add a caption.
Use the `{{</* figure */>}}` shortcode in your PR's `.md` file to reference the `.svg` image file and add a caption.
```json
{{</* figure src="/static/images/boxnet.svg" alt="Boxnet figure" class="diagram-large" caption="Figure 14. Boxnet caption" */>}}
```
@@ -291,10 +324,14 @@ Use the `{{</* figure */>}}` shortcode in your PR's `.md` file to reference the
For more details on diagram captions, see [How to use captions](#how-to-use-captions).
{{< note >}}
The `{{</* figure */>}}` shortcode is the preferred method for adding `.svg` image files to your documentation. You can also use the standard markdown image syntax like so: `![my boxnet diagram](static/images/boxnet.svg)`. And you will need to add a caption below the diagram.
The `{{</* figure */>}}` shortcode is the preferred method for adding `.svg` image files
to your documentation. You can also use the standard markdown image syntax like so:
`![my boxnet diagram](static/images/boxnet.svg)`.
And you will need to add a caption below the diagram.
{{< /note >}}
You should add the live editor URL as a comment block in the `.svg` image file using a text editor. For example, you would include the following at the beginning of the `.svg` image file:
You should add the live editor URL as a comment block in the `.svg` image file using a text editor.
For example, you would include the following at the beginning of the `.svg` image file:
```
<!-- To view or edit the mermaid code, use the following URL: -->
@@ -308,13 +345,17 @@ The following lists advantages of the Mermaid+SVG method:
* Employ existing K8s/website methods for handling `.svg` image files.
* Environment doesn't require Mermaid support.
Be sure to check that your diagram renders properly using the [local](https://kubernetes.io/docs/contribute/new-content/open-a-pr/#preview-locally) and Netlify previews.
Be sure to check that your diagram renders properly using the
[local](/docs/contribute/new-content/open-a-pr/#preview-locally)
and Netlify previews.
### External tool
Figure 5 outlines the steps to follow for adding a diagram using the External Tool method.
First, use your external tool to create the diagram and save it as an `.svg` or `.png` image file. After that, use the same steps as the __Mermaid+SVG__ method for adding `.svg` image files.
First, use your external tool to create the diagram and save it as an `.svg`
or `.png` image file. After that, use the same steps as the __Mermaid+SVG__
method for adding `.svg` image files.
{{< mermaid >}}
flowchart LR
@@ -350,8 +391,11 @@ Figure 5. External Tool method steps
The following lists the steps you should follow for adding a diagram using the External Tool method:
1. Use your external tool to create a diagram.
2. Save the diagram coordinates for contributor access. For example, your tool may offer a link to the diagram image, or you could place the source code file, such as an `.xml` file, in a public repository for later contributor access.
3. Generate and save the diagram as an `.svg` or `.png` image file. Download this file to the appropriate `../images/` folder.
2. Save the diagram coordinates for contributor access. For example, your tool
may offer a link to the diagram image, or you could place the source code
file, such as an `.xml` file, in a public repository for later contributor access.
3. Generate and save the diagram as an `.svg` or `.png` image file.
Download this file to the appropriate `../images/` folder.
4. Use the `{{</* figure */>}}` shortcode to reference the diagram in the `.md` file.
5. Add a caption using the `{{</* figure */>}}` shortcode's `caption` parameter.
@@ -362,30 +406,40 @@ Here is the `{{</* figure */>}}` shortcode for the `images/apple.svg` diagram:
If your external drawing tool permits:
* You can incorporate multiple `.svg` or `.png` logos, icons and images into your diagram. However, make sure you observe copyright and follow the Kubernetes documentation
* You can incorporate multiple `.svg` or `.png` logos, icons and images into your diagram.
However, make sure you observe copyright and follow the Kubernetes documentation
[guidelines](/docs/contribute/style/content-guide/) on the use of third party content.
* You should save the diagram source coordinates for later contributor access. For example, your tool may offer a link to the diagram image, or you could place the source code file, such as an `.xml` file, somewhere for contributor access.
* You should save the diagram source coordinates for later contributor access.
For example, your tool may offer a link to the diagram image, or you could
place the source code file, such as an `.xml` file, somewhere for contributor access.
For more information on K8s and CNCF logos and images, check out [CNCF Artwork](https://github.com/cncf/artwork).
For more information on K8s and CNCF logos and images, check out
[CNCF Artwork](https://github.com/cncf/artwork).
The following lists advantages of the External Tool method:
* Contributor familiarity with external tool.
* Diagrams require more detail than what Mermaid can offer.
Don't forget to check that your diagram renders correctly using the [local](https://kubernetes.io/docs/contribute/new-content/open-a-pr/#preview-locally) and Netlify previews.
Don't forget to check that your diagram renders correctly using the
[local](/docs/contribute/new-content/open-a-pr/#preview-locally) and Netlify previews.
## Examples
This section shows several examples of Mermaid diagrams.
{{< note >}}
The code block examples omit the Hugo `{{</* mermaid */>}}`, `{{</* /mermaid */>}}` shortcode tags. This allows you to copy the code block into the live editor to experiment on your own. Note that the live editor doesn't recognize Hugo shortcodes.
The code block examples omit the Hugo `{{</* mermaid */>}}`, `{{</* /mermaid */>}}`
shortcode tags. This allows you to copy the code block into the live editor
to experiment on your own.
Note that the live editor doesn't recognize Hugo shortcodes.
{{< /note >}}
### Example 1 - Pod topology spread constraints
Figure 6 shows the diagram appearing in the [Pod Topology Spread Constraints](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/#node-labels) page.
Figure 6 shows the diagram appearing in the
[Pod topology pread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/#node-labels)
page.
{{< mermaid >}}
graph TB
@@ -417,6 +471,7 @@ click n2 "https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiZ3J
Figure 6. Pod Topology Spread Constraints.
Code block:
```
graph TB
subgraph "zoneB"
@@ -437,7 +492,7 @@ graph TB
### Example 2 - Ingress
Figure 7 shows the diagram appearing in the [What is Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/#what-is-ingress) page.
Figure 7 shows the diagram appearing in the [What is Ingress](/docs/concepts/services-networking/ingress/#what-is-ingress) page.
{{< mermaid >}}
graph LR;
@@ -491,13 +546,15 @@ graph LR;
### Example 3 - K8s system flow
Figure 8 depicts a Mermaid sequence diagram showing the system flow between K8s components to start a container.
Figure 8 depicts a Mermaid sequence diagram showing the system flow between
K8s components to start a container.
{{< figure src="/docs/images/diagram-guide-example-3.svg" alt="K8s system flow diagram" class="diagram-large" caption="Figure 8. K8s system flow diagram" link="https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiJSV7aW5pdDp7XCJ0aGVtZVwiOlwibmV1dHJhbFwifX0lJVxuc2VxdWVuY2VEaWFncmFtXG4gICAgYWN0b3IgbWVcbiAgICBwYXJ0aWNpcGFudCBhcGlTcnYgYXMgY29udHJvbCBwbGFuZTxicj48YnI-YXBpLXNlcnZlclxuICAgIHBhcnRpY2lwYW50IGV0Y2QgYXMgY29udHJvbCBwbGFuZTxicj48YnI-ZXRjZCBkYXRhc3RvcmVcbiAgICBwYXJ0aWNpcGFudCBjbnRybE1nciBhcyBjb250cm9sIHBsYW5lPGJyPjxicj5jb250cm9sbGVyPGJyPm1hbmFnZXJcbiAgICBwYXJ0aWNpcGFudCBzY2hlZCBhcyBjb250cm9sIHBsYW5lPGJyPjxicj5zY2hlZHVsZXJcbiAgICBwYXJ0aWNpcGFudCBrdWJlbGV0IGFzIG5vZGU8YnI-PGJyPmt1YmVsZXRcbiAgICBwYXJ0aWNpcGFudCBjb250YWluZXIgYXMgbm9kZTxicj48YnI-Y29udGFpbmVyPGJyPnJ1bnRpbWVcbiAgICBtZS0-PmFwaVNydjogMS4ga3ViZWN0bCBjcmVhdGUgLWYgcG9kLnlhbWxcbiAgICBhcGlTcnYtLT4-ZXRjZDogMi4gc2F2ZSBuZXcgc3RhdGVcbiAgICBjbnRybE1nci0-PmFwaVNydjogMy4gY2hlY2sgZm9yIGNoYW5nZXNcbiAgICBzY2hlZC0-PmFwaVNydjogNC4gd2F0Y2ggZm9yIHVuYXNzaWduZWQgcG9kcyhzKVxuICAgIGFwaVNydi0-PnNjaGVkOiA1LiBub3RpZnkgYWJvdXQgcG9kIHcgbm9kZW5hbWU9XCIgXCJcbiAgICBzY2hlZC0-PmFwaVNydjogNi4gYXNzaWduIHBvZCB0byBub2RlXG4gICAgYXBpU3J2LS0-PmV0Y2Q6IDcuIHNhdmUgbmV3IHN0YXRlXG4gICAga3ViZWxldC0-PmFwaVNydjogOC4gbG9vayBmb3IgbmV3bHkgYXNzaWduZWQgcG9kKHMpXG4gICAgYXBpU3J2LT4-a3ViZWxldDogOS4gYmluZCBwb2QgdG8gbm9kZVxuICAgIGt1YmVsZXQtPj5jb250YWluZXI6IDEwLiBzdGFydCBjb250YWluZXJcbiAgICBrdWJlbGV0LT4-YXBpU3J2OiAxMS4gdXBkYXRlIHBvZCBzdGF0dXNcbiAgICBhcGlTcnYtLT4-ZXRjZDogMTIuIHNhdmUgbmV3IHN0YXRlIiwibWVybWFpZCI6IntcbiAgXCJ0aGVtZVwiOiBcImRlZmF1bHRcIlxufSIsInVwZGF0ZUVkaXRvciI6ZmFsc2UsImF1dG9TeW5jIjp0cnVlLCJ1cGRhdGVEaWFncmFtIjp0cnVlfQ" >}}
Code block:
```
%%{init:{"theme":"neutral"}}%%
sequenceDiagram
@@ -524,29 +581,43 @@ sequenceDiagram
## How to style diagrams
You can style one or more diagram elements using well-known CSS nomenclature. You accomplish this using two types of statements in the Mermaid code.
You can style one or more diagram elements using well-known CSS nomenclature.
You accomplish this using two types of statements in the Mermaid code.
* `classDef` defines a class of style attributes.
* `class` defines one or more elements to apply the class to.
In the code for [figure 7](https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiZ3JhcGggIExSXG4gIGNsaWVudChbY2xpZW50XSktLiBJbmdyZXNzLW1hbmFnZWQgPGJyPiBsb2FkIGJhbGFuY2VyIC4tPmluZ3Jlc3NbSW5ncmVzc107XG4gIGluZ3Jlc3MtLT58cm91dGluZyBydWxlfHNlcnZpY2VbU2VydmljZV07XG4gIHN1YmdyYXBoIGNsdXN0ZXJcbiAgaW5ncmVzcztcbiAgc2VydmljZS0tPnBvZDFbUG9kXTtcbiAgc2VydmljZS0tPnBvZDJbUG9kXTtcbiAgZW5kXG4gIGNsYXNzRGVmIHBsYWluIGZpbGw6I2RkZCxzdHJva2U6I2ZmZixzdHJva2Utd2lkdGg6NHB4LGNvbG9yOiMwMDA7XG4gIGNsYXNzRGVmIGs4cyBmaWxsOiMzMjZjZTUsc3Ryb2tlOiNmZmYsc3Ryb2tlLXdpZHRoOjRweCxjb2xvcjojZmZmO1xuICBjbGFzc0RlZiBjbHVzdGVyIGZpbGw6I2ZmZixzdHJva2U6I2JiYixzdHJva2Utd2lkdGg6MnB4LGNvbG9yOiMzMjZjZTU7XG4gIGNsYXNzIGluZ3Jlc3Msc2VydmljZSxwb2QxLHBvZDIgazhzO1xuICBjbGFzcyBjbGllbnQgcGxhaW47XG4gIGNsYXNzIGNsdXN0ZXIgY2x1c3RlcjtcbiIsIm1lcm1haWQiOiJ7XG4gIFwidGhlbWVcIjogXCJkZWZhdWx0XCJcbn0iLCJ1cGRhdGVFZGl0b3IiOmZhbHNlLCJhdXRvU3luYyI6dHJ1ZSwidXBkYXRlRGlhZ3JhbSI6dHJ1ZX0), you can see examples of both.
In the code for
[figure 7](https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiZ3JhcGggIExSXG4gIGNsaWVudChbY2xpZW50XSktLiBJbmdyZXNzLW1hbmFnZWQgPGJyPiBsb2FkIGJhbGFuY2VyIC4tPmluZ3Jlc3NbSW5ncmVzc107XG4gIGluZ3Jlc3MtLT58cm91dGluZyBydWxlfHNlcnZpY2VbU2VydmljZV07XG4gIHN1YmdyYXBoIGNsdXN0ZXJcbiAgaW5ncmVzcztcbiAgc2VydmljZS0tPnBvZDFbUG9kXTtcbiAgc2VydmljZS0tPnBvZDJbUG9kXTtcbiAgZW5kXG4gIGNsYXNzRGVmIHBsYWluIGZpbGw6I2RkZCxzdHJva2U6I2ZmZixzdHJva2Utd2lkdGg6NHB4LGNvbG9yOiMwMDA7XG4gIGNsYXNzRGVmIGs4cyBmaWxsOiMzMjZjZTUsc3Ryb2tlOiNmZmYsc3Ryb2tlLXdpZHRoOjRweCxjb2xvcjojZmZmO1xuICBjbGFzc0RlZiBjbHVzdGVyIGZpbGw6I2ZmZixzdHJva2U6I2JiYixzdHJva2Utd2lkdGg6MnB4LGNvbG9yOiMzMjZjZTU7XG4gIGNsYXNzIGluZ3Jlc3Msc2VydmljZSxwb2QxLHBvZDIgazhzO1xuICBjbGFzcyBjbGllbnQgcGxhaW47XG4gIGNsYXNzIGNsdXN0ZXIgY2x1c3RlcjtcbiIsIm1lcm1haWQiOiJ7XG4gIFwidGhlbWVcIjogXCJkZWZhdWx0XCJcbn0iLCJ1cGRhdGVFZGl0b3IiOmZhbHNlLCJhdXRvU3luYyI6dHJ1ZSwidXBkYXRlRGlhZ3JhbSI6dHJ1ZX0),
you can see examples of both.
```
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; // defines style for the k8s class
class ingress,service,pod1,pod2 k8s; // k8s class is applied to elements ingress, service, pod1 and pod2.
```
You can include one or multiple `classDef` and `class` statements in your diagram. You can also use the official K8s `#326ce5` hex color code for K8s components in your diagram.
For more information on styling and classes, see [Mermaid Styling and classes docs](https://mermaid-js.github.io/mermaid/#/flowchart?id=styling-and-classes).
You can include one or multiple `classDef` and `class` statements in your diagram.
You can also use the official K8s `#326ce5` hex color code for K8s components in your diagram.
For more information on styling and classes, see
[Mermaid Styling and classes docs](https://mermaid-js.github.io/mermaid/#/flowchart?id=styling-and-classes).
## How to use captions
A caption is a brief description of a diagram. A title or a short description of the diagram are examples of captions. Captions aren't meant to replace explanatory text you have in your documentation. Rather, they serve as a "context link" between that text and your diagram.
A caption is a brief description of a diagram. A title or a short description
of the diagram are examples of captions. Captions aren't meant to replace
explanatory text you have in your documentation. Rather, they serve as a
"context link" between that text and your diagram.
The combination of some text and a diagram tied together with a caption help provide a concise representation of the information you wish to convey to the user.
The combination of some text and a diagram tied together with a caption help
provide a concise representation of the information you wish to convey to the
user.
Without captions, you are asking the user to scan the text above or below the diagram to figure out a meaning. This can be frustrating for the user.
Without captions, you are asking the user to scan the text above or below the
diagram to figure out a meaning. This can be frustrating for the user.
Figure 9 lays out the three components for proper captioning: diagram, diagram caption and the diagram referral.
Figure 9 lays out the three components for proper captioning: diagram, diagram
caption and the diagram referral.
{{< mermaid >}}
flowchart
@@ -574,94 +645,131 @@ You should always add a caption to each diagram in your documentation.
The `Mermaid+SVG` and `External Tool` methods generate `.svg` image files.
Here is the `{{</* figure */>}}` shortcode for the diagram defined in an `.svg` image file saved to `/images/docs/components-of-kubernetes.svg`:
```text
Here is the `{{</* figure */>}}` shortcode for the diagram defined in an
`.svg` image file saved to `/images/docs/components-of-kubernetes.svg`:
```none
{{</* figure src="/images/docs/components-of-kubernetes.svg" alt="Kubernetes pod running inside a cluster" class="diagram-large" caption="Figure 4. Kubernetes Architecture Components */>}}
```
You should pass the `src`, `alt`, `class` and `caption` values into the `{{</* figure */>}}` shortcode. You can adjust the size of the diagram using `diagram-large`, `diagram-medium` and `diagram-small` classes.
You should pass the `src`, `alt`, `class` and `caption` values into the
`{{</* figure */>}}` shortcode. You can adjust the size of the diagram using
`diagram-large`, `diagram-medium` and `diagram-small` classes.
{{< note >}}
Diagrams created using the `Inline` method don't use the `{{</* figure */>}}` shortcode. The Mermaid code defines how the diagram will render on your page.
Diagrams created using the `Inline` method don't use the `{{</* figure */>}}`
shortcode. The Mermaid code defines how the diagram will render on your page.
{{< /note >}}
See [Methods for creating diagrams](#methods-for-creating-diagrams) for more information on the different methods for creating diagrams.
See [Methods for creating diagrams](#methods-for-creating-diagrams)
for more information on the different methods for creating diagrams.
**Diagram Caption**
Next, add a diagram caption.
If you define your diagram in an `.svg` image file, then you should use the `{{</* figure */>}}` shortcode's `caption` parameter.
If you define your diagram in an `.svg` image file, then you should use the
`{{</* figure */>}}` shortcode's `caption` parameter.
```text
```none
{{</* figure src="/images/docs/components-of-kubernetes.svg" alt="Kubernetes pod running inside a cluster" class="diagram-large" caption="Figure 4. Kubernetes Architecture Components" */>}}
```
If you define your diagram using inline Mermaid code, then you should use Markdown text.
```text
```none
Figure 4. Kubernetes Architecture Components
```
The following lists several items to consider when adding diagram captions:
* Use the `{{</* figure */>}}` shortcode to add a diagram caption for `Mermaid+SVG` and `External Tool` diagrams.
* Use the `{{</* figure */>}}` shortcode to add a diagram caption for `Mermaid+SVG`
and `External Tool` diagrams.
* Use simple Markdown text to add a diagram caption for the `Inline` method.
* Prepend your diagram caption with `Figure NUMBER.`. You must use `Figure` and the number must be unique for each diagram in your documentation page. Add a period after the number.
* Add your diagram caption text after the `Figure NUMBER.` on the same line. You must puncuate the caption with a period. Keep the caption text short.
* Prepend your diagram caption with `Figure NUMBER.`. You must use `Figure`
and the number must be unique for each diagram in your documentation page.
Add a period after the number.
* Add your diagram caption text after the `Figure NUMBER.` on the same line.
You must puncuate the caption with a period. Keep the caption text short.
* Position your diagram caption __BELOW__ your diagram.
**Diagram Referral**
Finally, you can add a diagram referral. This is used inside your text and should precede the diagram itself. It allows a user to connect your text with the associated diagram. The `Figure NUMBER` in your referral and caption must match.
Finally, you can add a diagram referral. This is used inside your text and
should precede the diagram itself. It allows a user to connect your text with
the associated diagram. The `Figure NUMBER` in your referral and caption must
match.
You should avoid using spatial references such as `..the image below..` or `..the following figure ..`
You should avoid using spatial references such as `..the image below..` or
`..the following figure ..`
Here is an example of a diagram referral:
```text
Figure 10 depicts the components of the Kubernetes architecture. The control plane ...
Figure 10 depicts the components of the Kubernetes architecture.
The control plane ...
```
Diagram referrals are optional and there are cases where they might not be suitable. If you are not sure, add a diagram referral to your text to see if it looks and sounds okay. When in doubt, use a diagram referral.
Diagram referrals are optional and there are cases where they might not be
suitable. If you are not sure, add a diagram referral to your text to see if
it looks and sounds okay. When in doubt, use a diagram referral.
**Complete picture**
Figure 10 shows the Kubernetes Architecture diagram that includes the diagram, diagram caption and diagram referral. The `{{</* figure */>}}` shortcode renders the diagram, adds the caption and includes the optional `link` parameter so you can hyperlink the diagram. The diagram referral is contained in this paragraph.
Figure 10 shows the Kubernetes Architecture diagram that includes the diagram,
diagram caption and diagram referral. The `{{</* figure */>}}` shortcode
renders the diagram, adds the caption and includes the optional `link`
parameter so you can hyperlink the diagram. The diagram referral is contained
in this paragraph.
Here is the `{{</* figure */>}}` shortcode for this diagram:
```
{{</* figure src="/images/docs/components-of-kubernetes.svg" alt="Kubernetes pod running inside a cluster" class="diagram-large" caption="Figure 10. Kubernetes Architecture." link="https://kubernetes.io/docs/concepts/overview/components/" */>}}
```
{{< figure src="/images/docs/components-of-kubernetes.svg" alt="Kubernetes pod running inside a cluster" class="diagram-large" caption="Figure 10. Kubernetes Architecture." link="https://kubernetes.io/docs/concepts/overview/components/" >}}
## Tips
* Always use the live editor to create/edit your diagram.
* Always use Hugo local and Netlify previews to check out how the diagram appears in the documentation.
* Always use Hugo local and Netlify previews to check out how the diagram
appears in the documentation.
* Include diagram source pointers such as a URL, source code location, or indicate the code is self-documenting.
* Include diagram source pointers such as a URL, source code location, or
indicate the code is self-documenting.
* Always use diagram captions.
* Very helpful to include the diagram `.svg` or `.png` image and/or Mermaid source code in issues and PRs.
* Very helpful to include the diagram `.svg` or `.png` image and/or Mermaid
source code in issues and PRs.
* With the `Mermaid+SVG` and `External Tool` methods, use `.svg` image files because they stay sharp when you zoom in on the diagram.
* With the `Mermaid+SVG` and `External Tool` methods, use `.svg` image files
because they stay sharp when you zoom in on the diagram.
* Best practice for `.svg` files is to load it into an SVG editing tool and use the
“Convert text to paths” function. This ensures that the diagram renders the same on all systems, regardless of font availability and font rendering support.
"Convert text to paths" function.
This ensures that the diagram renders the same on all systems, regardless of font
availability and font rendering support.
* No Mermaid support for additional icons or artwork.
* Hugo Mermaid shortcodes don't work in the live editor.
* Any time you modify a diagram in the live editor, you __must save__ it to generate a new URL for the diagram.
* Any time you modify a diagram in the live editor, you __must__ save it
to generate a new URL for the diagram.
* Click on the diagrams in this section to view the code and diagram rendering in the live editor.
* Click on the diagrams in this section to view the code and diagram rendering
in the live editor.
* Look over the source code of this page, `diagram-guide.md`, for more examples.
* Check out the [Mermaid docs](https://mermaid-js.github.io/mermaid/#/) for explanations and examples.
* Check out the [Mermaid docs](https://mermaid-js.github.io/mermaid/#/)
for explanations and examples.
Most important, __Keep Diagrams Simple__. This will save time for you and fellow contributors, and allow for easier reading by new and experienced users.
Most important, __Keep Diagrams Simple__.
This will save time for you and fellow contributors, and allow for easier reading
by new and experienced users.
content/en/docs/reference/_index.md
+1
View File
@@ -75,6 +75,7 @@ operator to use or manage a cluster.
* [kube-apiserver configuration (v1)](/docs/reference/config-api/apiserver-config.v1/)
* [kube-apiserver encryption (v1)](/docs/reference/config-api/apiserver-encryption.v1/)
* [kubelet configuration (v1alpha1)](/docs/reference/config-api/kubelet-config.v1alpha1/) and
[kubelet configuration (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
* [kube-scheduler configuration (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) and
content/en/docs/reference/config-api/apiserver-encryption.v1.md
+279
View File
@@ -0,0 +1,279 @@
---
title: kube-apiserver Encryption Configuration (v1)
content_type: tool-reference
package: apiserver.config.k8s.io/v1
auto_generated: true
---
<p>Package v1 is the v1 version of the API.</p>
## Resource Types
- [EncryptionConfiguration](#apiserver-config-k8s-io-v1-EncryptionConfiguration)
## `EncryptionConfiguration` {#apiserver-config-k8s-io-v1-EncryptionConfiguration}
<p>EncryptionConfiguration stores the complete configuration for encryption providers.</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>apiVersion</code><br/>string</td><td><code>apiserver.config.k8s.io/v1</code></td></tr>
<tr><td><code>kind</code><br/>string</td><td><code>EncryptionConfiguration</code></td></tr>
<tr><td><code>resources</code> <B>[Required]</B><br/>
<a href="#apiserver-config-k8s-io-v1-ResourceConfiguration"><code>[]ResourceConfiguration</code></a>
</td>
<td>
<p>resources is a list containing resources, and their corresponding encryption providers.</p>
</td>
</tr>
</tbody>
</table>
## `AESConfiguration` {#apiserver-config-k8s-io-v1-AESConfiguration}
**Appears in:**
- [ProviderConfiguration](#apiserver-config-k8s-io-v1-ProviderConfiguration)
<p>AESConfiguration contains the API configuration for an AES transformer.</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>keys</code> <B>[Required]</B><br/>
<a href="#apiserver-config-k8s-io-v1-Key"><code>[]Key</code></a>
</td>
<td>
<p>keys is a list of keys to be used for creating the AES transformer.
Each key has to be 32 bytes long for AES-CBC and 16, 24 or 32 bytes for AES-GCM.</p>
</td>
</tr>
</tbody>
</table>
## `IdentityConfiguration` {#apiserver-config-k8s-io-v1-IdentityConfiguration}
**Appears in:**
- [ProviderConfiguration](#apiserver-config-k8s-io-v1-ProviderConfiguration)
<p>IdentityConfiguration is an empty struct to allow identity transformer in provider configuration.</p>
## `KMSConfiguration` {#apiserver-config-k8s-io-v1-KMSConfiguration}
**Appears in:**
- [ProviderConfiguration](#apiserver-config-k8s-io-v1-ProviderConfiguration)
<p>KMSConfiguration contains the name, cache size and path to configuration file for a KMS based envelope transformer.</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>name</code> <B>[Required]</B><br/>
<code>string</code>
</td>
<td>
<p>name is the name of the KMS plugin to be used.</p>
</td>
</tr>
<tr><td><code>cachesize</code><br/>
<code>int32</code>
</td>
<td>
<p>cachesize is the maximum number of secrets which are cached in memory. The default value is 1000.
Set to a negative value to disable caching.</p>
</td>
</tr>
<tr><td><code>endpoint</code> <B>[Required]</B><br/>
<code>string</code>
</td>
<td>
<p>endpoint is the gRPC server listening address, for example &quot;unix:///var/run/kms-provider.sock&quot;.</p>
</td>
</tr>
<tr><td><code>timeout</code><br/>
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
</td>
<td>
<p>timeout for gRPC calls to kms-plugin (ex. 5s). The default is 3 seconds.</p>
</td>
</tr>
</tbody>
</table>
## `Key` {#apiserver-config-k8s-io-v1-Key}
**Appears in:**
- [AESConfiguration](#apiserver-config-k8s-io-v1-AESConfiguration)
- [SecretboxConfiguration](#apiserver-config-k8s-io-v1-SecretboxConfiguration)
<p>Key contains name and secret of the provided key for a transformer.</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>name</code> <B>[Required]</B><br/>
<code>string</code>
</td>
<td>
<p>name is the name of the key to be used while storing data to disk.</p>
</td>
</tr>
<tr><td><code>secret</code> <B>[Required]</B><br/>
<code>string</code>
</td>
<td>
<p>secret is the actual key, encoded in base64.</p>
</td>
</tr>
</tbody>
</table>
## `ProviderConfiguration` {#apiserver-config-k8s-io-v1-ProviderConfiguration}
**Appears in:**
- [ResourceConfiguration](#apiserver-config-k8s-io-v1-ResourceConfiguration)
<p>ProviderConfiguration stores the provided configuration for an encryption provider.</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>aesgcm</code> <B>[Required]</B><br/>
<a href="#apiserver-config-k8s-io-v1-AESConfiguration"><code>AESConfiguration</code></a>
</td>
<td>
<p>aesgcm is the configuration for the AES-GCM transformer.</p>
</td>
</tr>
<tr><td><code>aescbc</code> <B>[Required]</B><br/>
<a href="#apiserver-config-k8s-io-v1-AESConfiguration"><code>AESConfiguration</code></a>
</td>
<td>
<p>aescbc is the configuration for the AES-CBC transformer.</p>
</td>
</tr>
<tr><td><code>secretbox</code> <B>[Required]</B><br/>
<a href="#apiserver-config-k8s-io-v1-SecretboxConfiguration"><code>SecretboxConfiguration</code></a>
</td>
<td>
<p>secretbox is the configuration for the Secretbox based transformer.</p>
</td>
</tr>
<tr><td><code>identity</code> <B>[Required]</B><br/>
<a href="#apiserver-config-k8s-io-v1-IdentityConfiguration"><code>IdentityConfiguration</code></a>
</td>
<td>
<p>identity is the (empty) configuration for the identity transformer.</p>
</td>
</tr>
<tr><td><code>kms</code> <B>[Required]</B><br/>
<a href="#apiserver-config-k8s-io-v1-KMSConfiguration"><code>KMSConfiguration</code></a>
</td>
<td>
<p>kms contains the name, cache size and path to configuration file for a KMS based envelope transformer.</p>
</td>
</tr>
</tbody>
</table>
## `ResourceConfiguration` {#apiserver-config-k8s-io-v1-ResourceConfiguration}
**Appears in:**
- [EncryptionConfiguration](#apiserver-config-k8s-io-v1-EncryptionConfiguration)
<p>ResourceConfiguration stores per resource configuration.</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>resources</code> <B>[Required]</B><br/>
<code>[]string</code>
</td>
<td>
<p>resources is a list of kubernetes resources which have to be encrypted.</p>
</td>
</tr>
<tr><td><code>providers</code> <B>[Required]</B><br/>
<a href="#apiserver-config-k8s-io-v1-ProviderConfiguration"><code>[]ProviderConfiguration</code></a>
</td>
<td>
<p>providers is a list of transformers to be used for reading and writing the resources to disk.
eg: aesgcm, aescbc, secretbox, identity.</p>
</td>
</tr>
</tbody>
</table>
## `SecretboxConfiguration` {#apiserver-config-k8s-io-v1-SecretboxConfiguration}
**Appears in:**
- [ProviderConfiguration](#apiserver-config-k8s-io-v1-ProviderConfiguration)
<p>SecretboxConfiguration contains the API configuration for an Secretbox transformer.</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>keys</code> <B>[Required]</B><br/>
<a href="#apiserver-config-k8s-io-v1-Key"><code>[]Key</code></a>
</td>
<td>
<p>keys is a list of keys to be used for creating the Secretbox transformer.
Each key has to be 32 bytes long.</p>
</td>
</tr>
</tbody>
</table>
content/en/docs/reference/glossary/finalizer.md
+3 -3
View File
@@ -19,12 +19,12 @@ to clean up resources the deleted object owned.
<!--more-->
When you tell Kubernetes to delete an object that has finalizers specified for
it, the Kubernetes API marks the object for deletion, putting it into a
read-only state. The target object remains in a terminating state while the
it, the Kubernetes API marks the object for deletion by populating `.metadata.deletionTimestamp`,
and returns a `202` status code (HTTP "Accepted"). The target object remains in a terminating state while the
control plane, or other components, take the actions defined by the finalizers.
After these actions are complete, the controller removes the relevant finalizers
from the target object. When the `metadata.finalizers` field is empty,
Kubernetes considers the deletion complete.
Kubernetes considers the deletion complete and deletes the object.
You can use finalizers to control {{<glossary_tooltip text="garbage collection" term_id="garbage-collection">}}
of resources. For example, you can define a finalizer to clean up related resources or
content/en/docs/reference/issues-security/security.md
-2
View File
@@ -19,8 +19,6 @@ This page describes Kubernetes security and disclosure information.
Join the [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce) group for emails about security and major API announcements.
You can also subscribe to an RSS feed of the above using [this link](https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50).
## Report a Vulnerability
We're extremely grateful for security researchers and users that report vulnerabilities to the Kubernetes Open Source Community. All reports are thoroughly investigated by a set of community volunteers.
content/en/docs/reference/node/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: Node Reference Information
weight: 40
---
content/en/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md
+50
View File
@@ -0,0 +1,50 @@
---
title: Articles on dockershim Removal and on Using CRI-compatible Runtimes
content_type: reference
---
<!-- overview -->
This is a list of articles and other pages that are either
about the Kubernetes' deprecation and removal of _dockershim_,
or about using CRI-compatible container runtimes, in connection
with that removal.
<!-- body -->
## Kubernetes project
* Kubernetes blog: [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/) (originally published 2020/12/02)
* Kubernetes blog: [Kubernetes is Moving on From Dockershim: Commitments and Next Steps](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/) (published 2022/01/07)
* Kubernetes blog: [Dockershim removal is coming. Are you ready?](/blog/2021/11/12/are-you-ready-for-dockershim-removal/) (published 2021/11/12)
* Kubernetes documentation: [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/)
* Kubernetes documentation: [Container runtimes](/docs/setup/production-environment/container-runtimes/)
* Kubernetes enhancement proposal: [KEP-2221: Removing dockershim from kubelet](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2221-remove-dockershim/README.md)
* Kubernetes enhancement proposal issue: [Removing dockershim from kubelet](https://github.com/kubernetes/enhancements/issues/2221) (_k/enhancements#2221_)
You can provide feedback via the GitHub issue [**Dockershim removal feedback & issues**](https://github.com/kubernetes/kubernetes/issues/106917).
## External sources {#third-party}
<!-- sort these alphabetically -->
* Amazon Web Services EKS documentation: [Dockershim deprecation](https://docs.aws.amazon.com/eks/latest/userguide/dockershim-deprecation.html)
* CNCF conference video: [Lessons Learned Migrating Kubernetes from Docker to containerd Runtime](https://www.youtube.com/watch?v=uDOu6rK4yOk) (Ana Caylin, at KubeCon Europe 2019)
* Docker.com blog: [What developers need to know about Docker, Docker Engine, and Kubernetes v1.20](https://www.docker.com/blog/what-developers-need-to-know-about-docker-docker-engine-and-kubernetes-v1-20/) (published 2020/12/04)
* "_Google Open Source_" channel on YouTube: [Learn Kubernetes with Google - Migrating from Dockershim to Containerd](https://youtu.be/fl7_4hjT52g)
* Microsoft Apps on Azure blog: [Dockershim deprecation and AKS](https://techcommunity.microsoft.com/t5/apps-on-azure-blog/dockershim-deprecation-and-aks/ba-p/3055902) (published 2022/01/21)
* Mirantis blog: [The Future of Dockershim is cri-dockerd](https://www.mirantis.com/blog/the-future-of-dockershim-is-cri-dockerd/) (published 2021/04/21)
* Mirantis: [Mirantis/cri-dockerd](https://github.com/Mirantis/cri-dockerd) Git repository (on GitHub)
* Tripwire: [How Dockershim’s Forthcoming Deprecation Affects Your Kubernetes](https://www.tripwire.com/state-of-security/security-data-protection/cloud/how-dockershim-forthcoming-deprecation-affects-your-kubernetes/)
content/en/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig.md
+3
View File
@@ -6,6 +6,9 @@ weight: 90
`kubeadm kubeconfig` provides utilities for managing kubeconfig files.
For examples on how to use `kubeadm kubeconfig user` see
[Generating kubeconfig files for additional users](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#kubeconfig-additional-users).
## kubeadm kubeconfig {#cmd-kubeconfig}
{{< tabs name="tab-kubeconfig" >}}
content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+2 -1
View File
@@ -209,7 +209,8 @@ export KUBECONFIG=/etc/kubernetes/admin.conf
Kubeadm signs the certificate in the `admin.conf` to have `Subject: O = system:masters, CN = kubernetes-admin`.
`system:masters` is a break-glass, super user group that bypasses the authorization layer (e.g. RBAC).
Do not share the `admin.conf` file with anyone and instead grant users custom permissions by generating
them a kubeconfig file using the `kubeadm kubeconfig user` command.
them a kubeconfig file using the `kubeadm kubeconfig user` command. For more details see
[Generating kubeconfig files for additional users](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#kubeconfig-additional-users).
{{< /warning >}}
Make a record of the `kubeadm join` command that `kubeadm init` outputs. You
content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
+2 -2
View File
@@ -265,9 +265,9 @@ with recommendations on when to use each CNI:
| -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ |
| L2bridge | Containers are attached to an external vSwitch. Containers are attached to the underlay network, although the physical network doesn't need to learn the container MACs because they are rewritten on ingress/egress. | MAC is rewritten to host MAC, IP may be rewritten to host IP using HNS OutboundNAT policy. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel host-gateway uses win-bridge | win-bridge uses L2bridge network mode, connects containers to the underlay of hosts, offering best performance. Requires user-defined routes (UDR) for inter-node connectivity. |
| L2Tunnel | This is a special case of l2bridge, but only used on Azure. All packets are sent to the virtualization host where SDN policy is applied. | MAC rewritten, IP visible on the underlay network | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI allows integration of containers with Azure vNET, and allows them to leverage the set of capabilities that [Azure Virtual Network provides](https://azure.microsoft.com/en-us/services/virtual-network/). For example, securely connect to Azure services or use Azure NSGs. See [azure-cni for some examples](https://docs.microsoft.com/en-us/azure/aks/concepts-network#azure-cni-advanced-networking) |
| Overlay (Overlay networking for Windows in Kubernetes is in *alpha* stage) | Containers are given a vNIC connected to an external vSwitch. Each overlay network gets its own IP subnet, defined by a custom IP prefix.The overlay network driver uses VXLAN encapsulation. | Encapsulated with an outer header. | [Win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN (uses win-overlay) | win-overlay should be used when virtual container networks are desired to be isolated from underlay of hosts (e.g. for security reasons). Allows for IPs to be re-used for different overlay networks (which have different VNID tags) if you are restricted on IPs in your datacenter. This option requires [KB4489899](https://support.microsoft.com/help/4489899) on Windows Server 2019. |
| Overlay (Overlay networking for Windows in Kubernetes is in *alpha* stage) | Containers are given a vNIC connected to an external vSwitch. Each overlay network gets its own IP subnet, defined by a custom IP prefix.The overlay network driver uses VXLAN encapsulation. | Encapsulated with an outer header. | [win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN (uses win-overlay) | win-overlay should be used when virtual container networks are desired to be isolated from underlay of hosts (e.g. for security reasons). Allows for IPs to be re-used for different overlay networks (which have different VNID tags) if you are restricted on IPs in your datacenter. This option requires [KB4489899](https://support.microsoft.com/help/4489899) on Windows Server 2019. |
| Transparent (special use case for [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)) | Requires an external vSwitch. Containers are attached to an external vSwitch which enables intra-pod communication via logical networks (logical switches and routers). | Packet is encapsulated either via [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) or [STT](https://datatracker.ietf.org/doc/draft-davie-stt/) tunneling to reach pods which are not on the same host. <br/> Packets are forwarded or dropped via the tunnel metadata information supplied by the ovn network controller. <br/> NAT is done for north-south communication. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [Deploy via ansible](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib). Distributed ACLs can be applied via Kubernetes policies. IPAM support. Load-balancing can be achieved without kube-proxy. NATing is done without using iptables/netsh. |
| NAT (*not used in Kubernetes*) | Containers are given a vNIC connected to an internal vSwitch. DNS/DHCP is provided using an internal component called [WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/) | MAC and IP is rewritten to host MAC/IP. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | Included here for completeness |
| NAT (*not used in Kubernetes*) | Containers are given a vNIC connected to an internal vSwitch. DNS/DHCP is provided using an internal component called [WinNAT](https://techcommunity.microsoft.com/t5/virtualization/windows-nat-winnat-capabilities-and-limitations/ba-p/382303) | MAC and IP is rewritten to host MAC/IP. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | Included here for completeness |
As outlined above, the [Flannel](https://github.com/coreos/flannel)
CNI [meta plugin](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel)
content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md
+4 -2
View File
@@ -1,6 +1,8 @@
---
reviewers:
- bryk
- floreks
- maciaszczykm
- shu-mutou
- mikedanese
title: Deploy and Access the Kubernetes Dashboard
description: >-
@@ -35,7 +37,7 @@ Dashboard also provides information on the state of Kubernetes resources in your
The Dashboard UI is not deployed by default. To deploy it, run the following command:
```
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.4.0/aio/deploy/recommended.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.5.0/aio/deploy/recommended.yaml
```
## Accessing the Dashboard UI
content/en/docs/tasks/administer-cluster/encrypt-data.md
+75 -53
View File
@@ -1,7 +1,7 @@
---
title: Encrypting Secret Data at Rest
reviewers:
- smarterclayton
title: Encrypting Secret Data at Rest
content_type: task
min-kubernetes-server-version: 1.13
---
@@ -9,27 +9,26 @@ min-kubernetes-server-version: 1.13
<!-- overview -->
This page shows how to enable and configure encryption of secret data at rest.
## {{% heading "prerequisites" %}}
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* etcd v3.0 or later is required
<!-- steps -->
## Configuration and determining whether encryption at rest is already enabled
The `kube-apiserver` process accepts an argument `--encryption-provider-config`
that controls how API data is encrypted in etcd. An example configuration
is provided below.
that controls how API data is encrypted in etcd.
The configuration is provided as an API named
[`EncryptionConfiguration`](/docs/reference/config-api/apiserver-encryption.v1/).
An example configuration is provided below.
{{< caution >}}
**IMPORTANT:** For multi-master configurations (with two or more control plane nodes) the encryption configuration file must be the same!
Otherwise, the kube-apiserver can't decrypt data stored inside the key-value store.
**IMPORTANT:** For high-availability configurations (with two or more control plane nodes), the
encryption configuration file must be the same! Otherwise, the `kube-apiserver` component cannot
decrypt data stored in the etcd.
{{< /caution >}}
## Understanding the encryption at rest configuration.
@@ -63,15 +62,20 @@ resources:
Each `resources` array item is a separate config and contains a complete configuration. The
`resources.resources` field is an array of Kubernetes resource names (`resource` or `resource.group`)
that should be encrypted. The `providers` array is an ordered list of the possible encryption
providers. Only one provider type may be specified per entry (`identity` or `aescbc` may be provided, but not both in the same item).
providers.
The first provider in the list is used to encrypt resources going into storage. When reading
resources from storage each provider that matches the stored data attempts to decrypt the data in
order. If no provider can read the stored data due to a mismatch in format or secret key, an error
Only one provider type may be specified per entry (`identity` or `aescbc` may be provided,
but not both in the same item).
The first provider in the list is used to encrypt resources written into the storage. When reading
resources from storage, each provider that matches the stored data attempts in order to decrypt the
data. If no provider can read the stored data due to a mismatch in format or secret key, an error
is returned which prevents clients from accessing that resource.
For more detailed information about the `EncryptionConfiguration` struct, please refer to the
[encryption configuration API](/docs/reference/config-api/apiserver-encryption.v1/).
{{< caution >}}
**IMPORTANT:** If any resource is not readable via the encryption config (because keys were changed),
If any resource is not readable via the encryption config (because keys were changed),
the only recourse is to delete that key from the underlying etcd directly. Calls that attempt to
read that resource will fail until it is deleted or a valid decryption key is provided.
{{< /caution >}}
@@ -90,15 +94,24 @@ Name | Encryption | Strength | Speed | Key Length | Other Considerations
Each provider supports multiple keys - the keys are tried in order for decryption, and if the provider
is the first provider, the first key is used for encryption.
__Storing the raw encryption key in the EncryptionConfig only moderately improves your security posture, compared to no encryption.
Please use `kms` provider for additional security.__ By default, the `identity` provider is used to protect secrets in etcd, which
provides no encryption. `EncryptionConfiguration` was introduced to encrypt secrets locally, with a locally managed key.
Encrypting secrets with a locally managed key protects against an etcd compromise, but it fails to protect against a host compromise.
Since the encryption keys are stored on the host in the EncryptionConfig YAML file, a skilled attacker can access that file and
extract the encryption keys.
{{< caution >}}
Storing the raw encryption key in the EncryptionConfig only moderately improves your security
posture, compared to no encryption. Please use `kms` provider for additional security.
{{< /caution >}}
Envelope encryption creates dependence on a separate key, not stored in Kubernetes. In this case, an attacker would need to compromise etcd, the kubeapi-server, and the third-party KMS provider to retrieve the plaintext values, providing a higher level of security than locally-stored encryption keys.
By default, the `identity` provider is used to protect Secrets in etcd, which provides no
encryption. `EncryptionConfiguration` was introduced to encrypt Secrets locally, with a locally
managed key.
Encrypting Secrets with a locally managed key protects against an etcd compromise, but it fails to
protect against a host compromise. Since the encryption keys are stored on the host in the
EncryptionConfiguration YAML file, a skilled attacker can access that file and extract the encryption
keys.
Envelope encryption creates dependence on a separate key, not stored in Kubernetes. In this case,
an attacker would need to compromise etcd, the `kubeapi-server`, and the third-party KMS provider to
retrieve the plaintext values, providing a higher level of security than locally stored encryption keys.
## Encrypting your data
@@ -118,87 +131,90 @@ resources:
- identity: {}
```
To create a new secret perform the following steps:
To create a new Secret, perform the following steps:
1. Generate a 32 byte random key and base64 encode it. If you're on Linux or macOS, run the following command:
1. Generate a 32-byte random key and base64 encode it. If you're on Linux or macOS, run the following command:
```shell
head -c 32 /dev/urandom | base64
```
2. Place that value in the secret field.
3. Set the `--encryption-provider-config` flag on the `kube-apiserver` to point to the location of the config file.
4. Restart your API server.
1. Place that value in the `secret` field of the `EncryptionConfiguration` struct.
1. Set the `--encryption-provider-config` flag on the `kube-apiserver` to point to
the location of the config file.
1. Restart your API server.
{{< caution >}}
Your config file contains keys that can decrypt content in etcd, so you must properly restrict permissions on your masters so only the user who runs the kube-apiserver can read it.
Your config file contains keys that can decrypt the contents in etcd, so you must properly restrict
permissions on your control-plane nodes so only the user who runs the `kube-apiserver` can read it.
{{< /caution >}}
## Verifying that data is encrypted
Data is encrypted when written to etcd. After restarting your `kube-apiserver`, any newly created or
updated secret should be encrypted when stored. To check, you can use the `etcdctl` command line
program to retrieve the contents of your secret.
updated Secret should be encrypted when stored. To check this, you can use the `etcdctl` command line
program to retrieve the contents of your Secret.
1. Create a new secret called `secret1` in the `default` namespace:
1. Create a new Secret called `secret1` in the `default` namespace:
```shell
kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
```
2. Using the etcdctl commandline, read that secret out of etcd:
1. Using the `etcdctl` command line, read that Secret out of etcd:
`ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C`
where `[...]` must be the additional arguments for connecting to the etcd server.
3. Verify the stored secret is prefixed with `k8s:enc:aescbc:v1:` which indicates the `aescbc` provider has encrypted the resulting data.
1. Verify the stored Secret is prefixed with `k8s:enc:aescbc:v1:` which indicates
the `aescbc` provider has encrypted the resulting data.
4. Verify the secret is correctly decrypted when retrieved via the API:
1. Verify the Secret is correctly decrypted when retrieved via the API:
```shell
kubectl describe secret secret1 -n default
```
should match `mykey: bXlkYXRh`, mydata is encoded, check [decoding a secret](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret) to
completely decode the secret.
The output should contain `mykey: bXlkYXRh`, with contents of `mydata` encoded, check
[decoding a Secret](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret)
to completely decode the Secret.
## Ensure all Secrets are encrypted
## Ensure all secrets are encrypted
Since secrets are encrypted on write, performing an update on a secret will encrypt that content.
Since Secrets are encrypted on write, performing an update on a Secret will encrypt that content.
```shell
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
```
The command above reads all secrets and then updates them to apply server side encryption.
The command above reads all Secrets and then updates them to apply server side encryption.
{{< note >}}
If an error occurs due to a conflicting write, retry the command.
For larger clusters, you may wish to subdivide the secrets by namespace or script an update.
{{< /note >}}
## Rotating a decryption key
Changing the secret without incurring downtime requires a multi step operation, especially in
the presence of a highly available deployment where multiple `kube-apiserver` processes are running.
Changing a Secret without incurring downtime requires a multi-step operation, especially in
the presence of a highly-available deployment where multiple `kube-apiserver` processes are running.
1. Generate a new key and add it as the second key entry for the current provider on all servers
2. Restart all `kube-apiserver` processes to ensure each server can decrypt using the new key
3. Make the new key the first entry in the `keys` array so that it is used for encryption in the config
4. Restart all `kube-apiserver` processes to ensure each server now encrypts using the new key
5. Run `kubectl get secrets --all-namespaces -o json | kubectl replace -f -` to encrypt all existing secrets with the new key
6. Remove the old decryption key from the config after you back up etcd with the new key in use and update all secrets
With a single `kube-apiserver`, step 2 may be skipped.
1. Restart all `kube-apiserver` processes to ensure each server can decrypt using the new key
1. Make the new key the first entry in the `keys` array so that it is used for encryption in the config
1. Restart all `kube-apiserver` processes to ensure each server now encrypts using the new key
1. Run `kubectl get secrets --all-namespaces -o json | kubectl replace -f -` to encrypt all
existing Secrets with the new key
1. Remove the old decryption key from the config after you have backed up etcd with the new key in use
and updated all Secrets
When running a single `kube-apiserver` instance, step 2 may be skipped.
## Decrypting all data
To disable encryption at rest place the `identity` provider as the first entry in the config:
To disable encryption at rest, place the `identity` provider as the first entry in the config
and restart all `kube-apiserver` processes.
```yaml
apiVersion: apiserver.config.k8s.io/v1
@@ -214,8 +230,14 @@ resources:
secret: <BASE 64 ENCODED SECRET>
```
and restart all `kube-apiserver` processes. Then run:
Then run the following command to force decrypt
all Secrets:
```shell
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
```
to force all secrets to be decrypted.
## {{% heading "whatsnext" %}}
* Learn more about the [EncryptionConfiguration configuration API (v1)](/docs/reference/config-api/apiserver-encryption.v1/).
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
+52 -1
View File
@@ -10,7 +10,9 @@ weight: 10
{{< feature-state for_k8s_version="v1.15" state="stable" >}}
Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/) expire after 1 year. This page explains how to manage certificate renewals with kubeadm.
Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/) expire after 1 year.
This page explains how to manage certificate renewals with kubeadm. It also covers other tasks related
to kubeadm certificate management.
## {{% heading "prerequisites" %}}
@@ -289,3 +291,52 @@ Such a controller is not a secure mechanism unless it not only verifies the Comm
in the CSR but also verifies the requested IPs and domain names. This would prevent
a malicious actor that has access to a kubelet client certificate to create
CSRs requesting serving certificates for any IP or domain name.
## Generating kubeconfig files for additional users {#kubeconfig-additional-users}
During cluster creation, kubeadm signs the certificate in the `admin.conf` to have
`Subject: O = system:masters, CN = kubernetes-admin`.
[`system:masters`](/docs/reference/access-authn-authz/rbac/#user-facing-roles)
is a break-glass, super user group that bypasses the authorization layer (e.g. RBAC).
Sharing the `admin.conf` with additional users is **not recommended**!
Instead, you can use the [`kubeadm kubeconfig user`](/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig)
command to generate kubeconfig files for additional users.
The command accepts a mixture of command line flags and
[kubeadm configuration](/docs/reference/config-api/kubeadm-config.v1beta3/) options.
The generated kubeconfig will be written to stdout and can be piped to a file
using `kubeadm kubeconfig user ... > somefile.conf`.
Example configuration file that can be used with `--config`:
```yaml
# example.yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
# Will be used as the target "cluster" in the kubeconfig
clusterName: "kubernetes"
# Will be used as the "server" (IP or DNS name) of this cluster in the kubeconfig
controlPlaneEndpoint: "some-dns-address:6443"
# The cluster CA key and certificate will be loaded from this local directory
certificatesDir: "/etc/kubernetes/pki"
```
Make sure that these settings match the desired target cluster settings.
To see the settings of an existing cluster use:
```shell
kubectl get cm kubeadm-config -n kube-system -o=jsonpath="{.data.ClusterConfiguration}"
```
The following example will generate a kubeconfig file with credentials valid for 24 hours
for a new user `johndoe` that is part of the `appdevs` group:
```shell
kubeadm kubeconfig user --config example.yaml --org appdevs --client-name johndoe --validity-period 24h
```
The following example will generate a kubeconfig file with administrator credentials valid for 1 week:
```shell
kubeadm kubeconfig user --config example.yaml --client-name admin --validity-period 168h
```
content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md
+1 -1
View File
@@ -13,7 +13,7 @@ This page shows how to configure default memory requests and limits for a
{{< glossary_tooltip text="namespace" term_id="namespace" >}}.
A Kubernetes cluster can be divided into namespaces. Once you have a namespace that
that has a default memory
has a default memory
[limit](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits),
and you then try to create a Pod with a container that does not specify its own memory
limit its own memory limit, then the
content/en/docs/tasks/administer-cluster/memory-manager.md
+7 -2
View File
@@ -138,7 +138,8 @@ The sum of their values will account for the total amount of reserved memory.
A new `--reserved-memory` flag was added to Memory Manager to allow for this total reserved memory
to be split (by a node administrator) and accordingly reserved across many NUMA nodes.
The flag specifies a comma-separated list of memory reservations per NUMA node.
The flag specifies a comma-separated list of memory reservations of different memory types per NUMA node.
Memory reservations across multiple NUMA nodes can be specified using semicolon as separator.
This parameter is only useful in the context of the Memory Manager feature.
The Memory Manager will not use this reserved memory for the allocation of container workloads.
@@ -180,6 +181,10 @@ or
`--reserved-memory 0:memory=1Gi --reserved-memory 1:memory=2Gi`
or
`--reserved-memory '0:memory=1Gi;1:memory=2Gi'`
When you specify values for `--reserved-memory` flag, you must comply with the setting that
you prior provided via Node Allocatable Feature flags.
That is, the following rule must be obeyed for each memory type:
@@ -215,7 +220,7 @@ Here is an example of a correct configuration:
--kube-reserved=cpu=4,memory=4Gi
--system-reserved=cpu=1,memory=1Gi
--memory-manager-policy=Static
--reserved-memory 0:memory=3Gi --reserved-memory 1:memory=2148Mi
--reserved-memory '0:memory=3Gi;1:memory=2148Mi'
```
Let us validate the configuration above:
content/en/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md
+154
View File
@@ -0,0 +1,154 @@
---
title: "Changing the Container Runtime on a Node from Docker Engine to containerd"
weight: 8
content_type: task
---
This task outlines the steps needed to update your container runtime to containerd from Docker. It is applicable for cluster operators running Kubernetes 1.23 or earlier. Also this covers an example scenario for migrating from dockershim to containerd and alternative container runtimes can be picked from this [page](https://kubernetes.io/docs/setup/production-environment/container-runtimes/).
## {{% heading "prerequisites" %}}
{{% thirdparty-content %}}
Install containerd. For more information see, [containerd's installation documentation](https://containerd.io/docs/getting-started/) and for specific prerequisite follow [this](/docs/setup/production-environment/container-runtimes/#containerd).
## Drain the node
```
# replace <node-to-drain> with the name of your node you are draining
kubectl drain <node-to-drain> --ignore-daemonsets
```
## Stop the Docker daemon
```shell
systemctl stop kubelet
systemctl disable docker.service --now
```
## Install Containerd
This [page](/docs/setup/production-environment/container-runtimes/#containerd) contains detailed steps to install containerd.
{{< tabs name="tab-cri-containerd-installation" >}}
{{% tab name="Linux" %}}
1. Install the `containerd.io` package from the official Docker repositories.
Instructions for setting up the Docker repository for your respective Linux distribution and installing the `containerd.io` package can be found at
[Install Docker Engine](https://docs.docker.com/engine/install/#server).
2. Configure containerd:
```shell
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
```
3. Restart containerd:
```shell
sudo systemctl restart containerd
```
{{% /tab %}}
{{% tab name="Windows (PowerShell)" %}}
Start a Powershell session, set `$Version` to the desired version (ex: `$Version="1.4.3"`), and then run the following commands:
1. Download containerd:
```powershell
curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz
tar.exe xvf .\containerd-windows-amd64.tar.gz
```
2. Extract and configure:
```powershell
Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
cd $Env:ProgramFiles\containerd\
.\containerd.exe config default | Out-File config.toml -Encoding ascii
# Review the configuration. Depending on setup you may want to adjust:
# - the sandbox_image (Kubernetes pause image)
# - cni bin_dir and conf_dir locations
Get-Content config.toml
# (Optional - but highly recommended) Exclude containerd from Windows Defender Scans
Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe"
```
3. Start containerd:
```powershell
.\containerd.exe --register-service
Start-Service containerd
```
{{% /tab %}}
{{< /tabs >}}
## Configure the kubelet to use containerd as its container runtime
Edit the file `/var/lib/kubelet/kubeadm-flags.env` and add the containerd runtime to the flags. `--container-runtime=remote` and `--container-runtime-endpoint=unix:///run/containerd/containerd.sock"`
For users using kubeadm should consider the following:
The `kubeadm` tool stores the CRI socket for each host as an annotation in the Node object for that host.
To change it you must do the following:
Execute `kubectl edit no <NODE-NAME>` on a machine that has the kubeadm `/etc/kubernetes/admin.conf` file.
This will start a text editor where you can edit the Node object.
To choose a text editor you can set the `KUBE_EDITOR` environment variable.
- Change the value of `kubeadm.alpha.kubernetes.io/cri-socket` from `/var/run/dockershim.sock`
to the CRI socket path of your choice (for example `unix:///run/containerd/containerd.sock`).
Note that new CRI socket paths must be prefixed with `unix://` ideally.
- Save the changes in the text editor, which will update the Node object.
## Restart the kubelet
```shell
systemctl start kubelet
```
## Verify that the node is healthy
Run `kubectl get nodes -o wide` and containerd appears as the runtime for the node we just changed.
## Remove Docker Engine
{{% thirdparty-content %}}
Finally if everything goes well remove docker
{{< tabs name="tab-remove-docker-enigine" >}}
{{% tab name="CentOS" %}}
```shell
sudo yum remove docker-ce docker-ce-cli
```
{{% /tab %}}
{{% tab name="Debian" %}}
```shell
sudo apt-get purge docker-ce docker-ce-cli
```
{{% /tab %}}
{{% tab name="Fedora" %}}
```shell
sudo dnf remove docker-ce docker-ce-cli
```
{{% /tab %}}
{{% tab name="Ubuntu" %}}
```shell
sudo apt-get purge docker-ce docker-ce-cli
```
{{% /tab %}}
{{< /tabs >}}
content/en/docs/tasks/administer-cluster/use-cascading-deletion.md
+5 -4
View File
@@ -5,7 +5,8 @@ content_type: task
<!--overview-->
This page shows you how to specify the type of [cascading deletion](/docs/concepts/workloads/controllers/garbage-collection/#cascading-deletion)
This page shows you how to specify the type of
[cascading deletion](/docs/concepts/architecture/garbage-collection/#cascading-deletion)
to use in your cluster during {{<glossary_tooltip text="garbage collection" term_id="garbage-collection">}}.
## {{% heading "prerequisites" %}}
@@ -26,7 +27,7 @@ kubectl get pods -l app=nginx --output=yaml
The output has an `ownerReferences` field similar to this:
```
```yaml
apiVersion: v1
...
ownerReferences:
@@ -41,7 +42,7 @@ apiVersion: v1
## Use foreground cascading deletion {#use-foreground-cascading-deletion}
By default, Kubernetes uses [background cascading deletion](/docs/concepts/workloads/controllers/garbage-collection/#background-deletion)
By default, Kubernetes uses [background cascading deletion](/docs/concepts/architecture/garbage-collection/#background-deletion)
to delete dependents of an object. You can switch to foreground cascading deletion
using either `kubectl` or the Kubernetes API, depending on the Kubernetes
version your cluster runs. {{<version-check>}}
@@ -349,4 +350,4 @@ kubectl get pods -l app=nginx
* Learn about [owners and dependents](/docs/concepts/overview/working-with-objects/owners-dependents/) in Kubernetes.
* Learn about Kubernetes [finalizers](/docs/concepts/overview/working-with-objects/finalizers/).
* Learn about [garbage collection](/docs/concepts/workloads/controllers/garbage-collection/).
* Learn about [garbage collection](/docs/concepts/architecture/garbage-collection/).
content/en/docs/tasks/configure-pod-container/security-context.md
+54 -39
View File
@@ -14,21 +14,31 @@ A security context defines privilege and access control settings for
a Pod or Container. Security context settings include, but are not limited to:
* Discretionary Access Control: Permission to access an object, like a file, is based on
[user ID (UID) and group ID (GID)](https://wiki.archlinux.org/index.php/users_and_groups).
[user ID (UID) and group ID (GID)](https://wiki.archlinux.org/index.php/users_and_groups).
* [Security Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux): Objects are assigned security labels.
* [Security Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux):
Objects are assigned security labels.
* Running as privileged or unprivileged.
* [Linux Capabilities](https://linux-audit.com/linux-capabilities-hardening-linux-binaries-by-removing-setuid/): Give a process some privileges, but not all the privileges of the root user.
* [Linux Capabilities](https://linux-audit.com/linux-capabilities-hardening-linux-binaries-by-removing-setuid/):
Give a process some privileges, but not all the privileges of the root user.
* [AppArmor](/docs/tutorials/clusters/apparmor/): Use program profiles to restrict the capabilities of individual programs.
* [AppArmor](/docs/tutorials/security/apparmor/):
Use program profiles to restrict the capabilities of individual programs.
* [Seccomp](/docs/tutorials/clusters/seccomp/): Filter a process's system calls.
* [Seccomp](/docs/tutorials/security/seccomp/): Filter a process's system calls.
* AllowPrivilegeEscalation: Controls whether a process can gain more privileges than its parent process. This bool directly controls whether the [`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) flag gets set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged OR 2) has `CAP_SYS_ADMIN`.
* `allowPrivilegeEscalation`: Controls whether a process can gain more privileges than
its parent process. This bool directly controls whether the
[`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt)
flag gets set on the container process.
`allowPrivilegeEscalation` is always true when the container:
* readOnlyRootFilesystem: Mounts the container's root filesystem as read-only.
- is run as privileged, or
- has `CAP_SYS_ADMIN`
* `readOnlyRootFilesystem`: Mounts the container's root filesystem as read-only.
The above bullets are not a complete set of security context settings -- please see
[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
@@ -37,15 +47,10 @@ for a comprehensive list.
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)
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## Set the security context for a Pod
@@ -91,7 +96,7 @@ ps
The output shows that the processes are running as user 1000, which is the value of `runAsUser`:
```shell
```none
PID USER TIME COMMAND
1 1000 0:00 sleep 1h
6 1000 0:00 sh
@@ -108,7 +113,7 @@ ls -l
The output shows that the `/data/demo` directory has group ID 2000, which is
the value of `fsGroup`.
```shell
```none
drwxrwsrwx 2 root 2000 4096 Jun 6 20:08 demo
```
@@ -127,19 +132,26 @@ ls -l
The output shows that `testfile` has group ID 2000, which is the value of `fsGroup`.
```shell
```none
-rw-r--r-- 1 1000 2000 6 Jun 6 20:08 testfile
```
Run the following command:
```shell
$ id
id
```
The output is similar to this:
```none
uid=1000 gid=3000 groups=2000
```
You will see that gid is 3000 which is same as `runAsGroup` field. If the `runAsGroup` was omitted the gid would
remain as 0(root) and the process will be able to interact with files that are owned by root(0) group and that have
the required group permissions for root(0) group.
From the output, you can see that `gid` is 3000 which is same as the `runAsGroup` field.
If the `runAsGroup` was omitted, the `gid` would remain as 0 (root) and the process will
be able to interact with files that are owned by the root(0) group and groups that have
the required group permissions for the root (0) group.
Exit your shell:
@@ -159,11 +171,14 @@ slowing Pod startup. You can use the `fsGroupChangePolicy` field inside a `secur
to control the way that Kubernetes checks and manages ownership and permissions
for a volume.
**fsGroupChangePolicy** - `fsGroupChangePolicy` defines behavior for changing ownership and permission of the volume
before being exposed inside a Pod. This field only applies to volume types that support
`fsGroup` controlled ownership and permissions. This field has two possible values:
**fsGroupChangePolicy** - `fsGroupChangePolicy` defines behavior for changing ownership
and permission of the volume before being exposed inside a Pod.
This field only applies to volume types that support `fsGroup` controlled ownership and permissions.
This field has two possible values:
* _OnRootMismatch_: Only change permissions and ownership if permission and ownership of root directory does not match with expected permissions of the volume. This could help shorten the time it takes to change ownership and permission of a volume.
* _OnRootMismatch_: Only change permissions and ownership if permission and ownership of
root directory does not match with expected permissions of the volume.
This could help shorten the time it takes to change ownership and permission of a volume.
* _Always_: Always change permission and ownership of the volume when volume is mounted.
For example:
@@ -176,7 +191,6 @@ securityContext:
fsGroupChangePolicy: "OnRootMismatch"
```
{{< note >}}
This field has no effect on ephemeral volume types such as
[`secret`](/docs/concepts/storage/volumes/#secret),
@@ -238,7 +252,7 @@ kubectl exec -it security-context-demo-2 -- sh
In your shell, list the running processes:
```
```shell
ps aux
```
@@ -297,7 +311,7 @@ ps aux
The output shows the process IDs (PIDs) for the Container:
```shell
```
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 4336 796 ? Ss 18:17 0:00 /bin/sh -c node server.js
root 5 0.1 0.5 772124 22700 ? Sl 18:17 0:00 node server.js
@@ -354,7 +368,7 @@ cat status
The output shows capabilities bitmap for the process:
```shell
```
...
CapPrm: 00000000aa0435fb
CapEff: 00000000aa0435fb
@@ -374,7 +388,10 @@ See [capability.h](https://github.com/torvalds/linux/blob/master/include/uapi/li
for definitions of the capability constants.
{{< note >}}
Linux capability constants have the form `CAP_XXX`. But when you list capabilities in your Container manifest, you must omit the `CAP_` portion of the constant. For example, to add `CAP_SYS_TIME`, include `SYS_TIME` in your list of capabilities.
Linux capability constants have the form `CAP_XXX`.
But when you list capabilities in your container manifest, you must
omit the `CAP_` portion of the constant.
For example, to add `CAP_SYS_TIME`, include `SYS_TIME` in your list of capabilities.
{{< /note >}}
## Set the Seccomp Profile for a Container
@@ -437,18 +454,19 @@ the Pod's Volumes when applicable. Specifically `fsGroup` and `seLinuxOptions` a
applied to Volumes as follows:
* `fsGroup`: Volumes that support ownership management are modified to be owned
and writable by the GID specified in `fsGroup`. See the
[Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)
for more details.
and writable by the GID specified in `fsGroup`. See the
[Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)
for more details.
* `seLinuxOptions`: Volumes that support SELinux labeling are relabeled to be accessible
by the label specified under `seLinuxOptions`. Usually you only
need to set the `level` section. This sets the
[Multi-Category Security (MCS)](https://selinuxproject.org/page/NB_MLS)
label given to all Containers in the Pod as well as the Volumes.
by the label specified under `seLinuxOptions`. Usually you only
need to set the `level` section. This sets the
[Multi-Category Security (MCS)](https://selinuxproject.org/page/NB_MLS)
label given to all Containers in the Pod as well as the Volumes.
{{< warning >}}
After you specify an MCS label for a Pod, all Pods with the same label can access the Volume. If you need inter-Pod protection, you must assign a unique MCS label to each Pod.
After you specify an MCS label for a Pod, all Pods with the same label can access the Volume.
If you need inter-Pod protection, you must assign a unique MCS label to each Pod.
{{< /warning >}}
## Clean up
@@ -462,11 +480,8 @@ kubectl delete pod security-context-demo-3
kubectl delete pod security-context-demo-4
```
## {{% heading "whatsnext" %}}
* [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)
content/en/docs/tasks/debug-application-cluster/crictl.md
+23 -8
View File
@@ -19,15 +19,14 @@ Kubernetes node. `crictl` and its source are hosted in the
## {{% heading "prerequisites" %}}
`crictl` requires a Linux operating system with a CRI runtime.
<!-- steps -->
## Installing crictl
You can download a compressed archive `crictl` from the cri-tools [release
page](https://github.com/kubernetes-sigs/cri-tools/releases), for several
You can download a compressed archive `crictl` from the cri-tools
[release page](https://github.com/kubernetes-sigs/cri-tools/releases), for several
different architectures. Download the version that corresponds to your version
of Kubernetes. Extract it and move it to a location on your system path, such as
`/usr/local/bin/`.
@@ -85,6 +84,7 @@ List all pods:
```shell
crictl pods
```
The output is similar to this:
```
@@ -100,6 +100,7 @@ List pods by name:
```shell
crictl pods --name nginx-65899c769f-wv2gp
```
The output is similar to this:
```
@@ -112,6 +113,7 @@ List pods by label:
```shell
crictl pods --label run=nginx
```
The output is similar to this:
```
@@ -126,6 +128,7 @@ List all images:
```shell
crictl images
```
The output is similar to this:
```
@@ -141,6 +144,7 @@ List images by repository:
```shell
crictl images nginx
```
The output is similar to this:
```
@@ -153,6 +157,7 @@ Only list image IDs:
```shell
crictl images -q
```
The output is similar to this:
```
@@ -169,6 +174,7 @@ List all containers:
```shell
crictl ps -a
```
The output is similar to this:
```
@@ -181,9 +187,10 @@ CONTAINER ID IMAGE
List running containers:
```
```shell
crictl ps
```
The output is similar to this:
```
@@ -198,6 +205,7 @@ CONTAINER ID IMAGE
```shell
crictl exec -i -t 1f73f2d81bf98 ls
```
The output is similar to this:
```
@@ -211,6 +219,7 @@ Get all container logs:
```shell
crictl logs 87d3992f84f74
```
The output is similar to this:
```
@@ -224,6 +233,7 @@ Get only the latest `N` lines of logs:
```shell
crictl logs --tail=1 87d3992f84f74
```
The output is similar to this:
```
@@ -270,13 +280,16 @@ deleted by the Kubelet.
```shell
crictl pull busybox
```
```none
Image is up to date for busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47
```
2. Create configs for the pod and the container:
**Pod config**:
```yaml
```json
{
"metadata": {
"name": "nginx-sandbox",
@@ -291,7 +304,8 @@ deleted by the Kubelet.
```
**Container config**:
```yaml
```json
{
"metadata": {
"name": "busybox"
@@ -322,6 +336,7 @@ deleted by the Kubelet.
```shell
crictl ps -a
```
The output is similar to this:
```
@@ -336,6 +351,7 @@ To start a container, pass its ID to `crictl start`:
```shell
crictl start 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60
```
The output is similar to this:
```
@@ -357,6 +373,5 @@ CONTAINER ID IMAGE CREATED STATE
## {{% heading "whatsnext" %}}
* [Learn more about `crictl`](https://github.com/kubernetes-sigs/cri-tools).
* [Map `docker` CLI commands to `crictl`](/reference/tools/map-crictl-dockercli/).
* [Map `docker` CLI commands to `crictl`](/docs/reference/tools/map-crictl-dockercli/).
<!-- discussion -->
content/en/docs/tasks/debug-application-cluster/debug-application.md
+2 -1
View File
@@ -58,7 +58,8 @@ Again, the information from `kubectl describe ...` should be informative. The m
* Make sure that you have the name of the image correct.
* Have you pushed the image to the registry?
* Run a manual `docker pull <image>` on your machine to see if the image can be pulled.
* Try to manually pull the image to see if the image can be pulled. For example,
if you use Docker on your PC, run `docker pull <image>`.
#### My pod is crashing or otherwise unhealthy
content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+2 -2
View File
@@ -86,8 +86,8 @@ worker node, but it can't run on that machine. Again, the information from
* Make sure that you have the name of the image correct.
* Have you pushed the image to the repository?
* Run a manual `docker pull <image>` on your machine to see if the image can be
pulled.
* Try to manually pull the image to see if it can be pulled. For example, if you
use Docker on your PC, run `docker pull <image>`.
### My pod is crashing or otherwise unhealthy
content/en/docs/tasks/debug-application-cluster/troubleshooting.md
+3 -2
View File
@@ -45,8 +45,9 @@ and command-line interfaces (CLIs), such as [`kubectl`](/docs/reference/kubectl/
Someone else from the community may have already asked a similar question or may
be able to help with your problem. The Kubernetes team will also monitor
[posts tagged Kubernetes](https://stackoverflow.com/questions/tagged/kubernetes).
If there aren't any existing questions that help, please
[ask a new one](https://stackoverflow.com/questions/ask?tags=kubernetes)!
If there aren't any existing questions that help, **please [ensure that your question is on-topic on Stack Overflow](https://stackoverflow.com/help/on-topic)
and that you read through the guidance on [how to ask a new question](https://stackoverflow.com/help/how-to-ask)**,
before [asking a new one](https://stackoverflow.com/questions/ask?tags=kubernetes)!
### Slack
content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
+4 -4
View File
@@ -88,7 +88,7 @@ or the custom metrics API (for all other metrics).
The common use for HorizontalPodAutoscaler is to configure it to fetch metrics from
{{< glossary_tooltip text="aggregated APIs" term_id="aggregation-layer" >}}
(`metrics.k8s.io`, `custom.metrics.k8s.io`, or `external.metrics.k8s.io`). The `metrics.k8s.io` API is
usually provided by an add on named Metrics Server, which needs to be launched separately.
usually provided by an add-on named Metrics Server, which needs to be launched separately.
For more information about resource metrics, see
[Metrics Server](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server).
@@ -329,7 +329,7 @@ APIs, cluster administrators must ensure that:
* The corresponding APIs are registered:
* For resource metrics, this is the `metrics.k8s.io` API, generally provided by [metrics-server](https://github.com/kubernetes-sigs/metrics-server).
It can be launched as a cluster addon.
It can be launched as a cluster add-on.
* For custom metrics, this is the `custom.metrics.k8s.io` API. It's provided by "adapter" API servers provided by metrics solution vendors.
Check with your metrics pipeline to see if there is a Kubernetes metrics adapter available.
@@ -514,7 +514,7 @@ Finally, you can delete an autoscaler using `kubectl delete hpa`.
In addition, there is a special `kubectl autoscale` command for creating a HorizontalPodAutoscaler object.
For instance, executing `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`
will create an autoscaler for replication set *foo*, with target CPU utilization set to `80%`
will create an autoscaler for ReplicaSet *foo*, with target CPU utilization set to `80%`
and the number of replicas between 2 and 5.
## Implicit maintenance-mode deactivation
@@ -538,7 +538,7 @@ desired and could be troublesome when an HPA is active.
Keep in mind that the removal of `spec.replicas` may incur a one-time
degradation of Pod counts as the default value of this key is 1 (reference
[Deployment Replicas](/docs/concepts/workloads/controllers/deployment#replicas).
[Deployment Replicas](/docs/concepts/workloads/controllers/deployment#replicas)).
Upon the update, all Pods except 1 will begin their termination procedures. Any
deployment application afterwards will behave as normal and respect a rolling
update configuration as desired. You can avoid this degradation by choosing one of the following two
content/en/docs/tasks/tls/managing-tls-in-a-cluster.md
+52 -41
View File
@@ -29,13 +29,18 @@ these certificates will validate against the cluster root CA.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{< include "task-tutorial-prereqs.md" >}}
You need the `cfssl` tool. You can download `cfssl` from
[https://github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases).
Some steps in this page use the `jq` tool. If you don't have `jq`, you can
install it via your operating system's software sources, or fetch it from
[https://stedolan.github.io/jq/](https://stedolan.github.io/jq/).
<!-- steps -->
## Trusting TLS in a Cluster
## Trusting TLS in a cluster
Trusting the custom CA from an application running as a pod usually requires
some extra application configuration. You will need to add the CA certificate
@@ -48,7 +53,7 @@ You can distribute the CA certificate as a
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap) that your
pods have access to use.
## Requesting a Certificate
## Requesting a certificate
The following section demonstrates how to create a TLS certificate for a
Kubernetes service accessed through DNS.
@@ -57,12 +62,7 @@ Kubernetes service accessed through DNS.
This tutorial uses CFSSL: Cloudflare's PKI and TLS toolkit [click here](https://blog.cloudflare.com/introducing-cfssl/) to know more.
{{< /note >}}
## Download and install CFSSL
The cfssl tools used in this example can be downloaded at
[https://github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases).
## Create a Certificate Signing Request
## Create a certificate signing request
Generate a private key and certificate signing request (or CSR) by running
the following command:
@@ -98,14 +98,14 @@ is the pod's DNS name. You should see the output similar to:
```
This command generates two files; it generates `server.csr` containing the PEM
encoded [pkcs#10](https://tools.ietf.org/html/rfc2986) certification request,
encoded [PKCS#10](https://tools.ietf.org/html/rfc2986) certification request,
and `server-key.pem` containing the PEM encoded key to the certificate that
is still to be created.
## Create a Certificate Signing Request object to send to the Kubernetes API
## Create a CertificateSigningRequest object to send to the Kubernetes API
Generate a CSR yaml blob and send it to the apiserver by running the following
command:
Generate a CSR manifest (in YAML), and send it to the API server. You can do that by
running the following command:
```shell
cat <<EOF | kubectl apply -f -
@@ -124,7 +124,7 @@ EOF
```
Notice that the `server.csr` file created in step 1 is base64 encoded
and stashed in the `.spec.request` field. We are also requesting a
and stashed in the `.spec.request` field. You are also requesting a
certificate with the "digital signature", "key encipherment", and "server
auth" key usages, signed by an example `example.com/serving` signer.
A specific `signerName` must be requested.
@@ -157,7 +157,7 @@ Subject Alternative Names:
Events: <none>
```
## Get the Certificate Signing Request Approved
## Get the CertificateSigningRequest approved {#get-the-certificate-signing-request-approved}
Approving the [certificate signing request](/docs/reference/access-authn-authz/certificate-signing-requests/)
is either done by an automated approval process or on a one off basis by a cluster
@@ -186,16 +186,18 @@ my-svc.my-namespace 10m example.com/serving yourname@example.com <none>
This means the certificate request has been approved and is waiting for the
requested signer to sign it.
## Sign the Certificate Signing Request
## Sign the CertificateSigningRequest {#sign-the-certificate-signing-request}
Next, you'll play the part of a certificate signer, issue the certificate, and upload it to the API.
A signer would typically watch the Certificate Signing Request API for objects with its `signerName`,
A signer would typically watch the CertificateSigningRequest API for objects with its `signerName`,
check that they have been approved, sign certificates for those requests,
and update the API object status with the issued certificate.
### Create a Certificate Authority
You need an authority to provide the digital signature on the new certificate.
First, create a signing certificate by running the following:
```shell
@@ -210,7 +212,7 @@ cat <<EOF | cfssl gencert -initca - | cfssljson -bare ca
EOF
```
You should see the output similar to:
You should see output similar to:
```none
2022/02/01 11:50:39 [INFO] generating a new CA key and certificate from CSR
@@ -223,7 +225,7 @@ You should see the output similar to:
This produces a certificate authority key file (`ca-key.pem`) and certificate (`ca.pem`).
### Issue a Certificate
### Issue a certificate
{{< codenew file="tls/server-signing-config.json" >}}
@@ -245,7 +247,7 @@ You should see the output similar to:
This produces a signed serving certificate file, `ca-signed-server.pem`.
### Upload the Signed Certificate
### Upload the signed certificate
Finally, populate the signed certificate in the API object's status:
@@ -256,22 +258,25 @@ kubectl get csr my-svc.my-namespace -o json | \
```
{{< note >}}
This uses the command line tool [jq](https://stedolan.github.io/jq/) to populate the base64-encoded content in the `.status.certificate` field.
If you do not have `jq`, you can also save the JSON output to a file, populate this field manually, and upload the resulting file.
This uses the command line tool [`jq`](https://stedolan.github.io/jq/) to populate the base64-encoded
content in the `.status.certificate` field.
If you do not have `jq`, you can also save the JSON output to a file, populate this field manually, and
upload the resulting file.
{{< /note >}}
Once the CSR is approved and the signed certificate is uploaded you should see the following:
Once the CSR is approved and the signed certificate is uploaded, run:
```shell
kubectl get csr
```
The output is similar to:
```none
NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION
my-svc.my-namespace 20m example.com/serving yourname@example.com <none> Approved,Issued
```
## Download the Certificate and Use It
## Download the certificate and use it
Now, as the requesting user, you can download the issued certificate
and save it to a `server.crt` file by running the following:
@@ -281,8 +286,10 @@ kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \
| base64 --decode > server.crt
```
Now you can populate `server.crt` and `server-key.pem` in a secret and mount
it into a pod to use as the keypair to start your HTTPS server:
Now you can populate `server.crt` and `server-key.pem` in a
{{< glossary_tooltip text="Secret" term_id="secret" >}}
that you could later mount into a Pod (for example, to use with a webserver
that serves HTTPS).
```shell
kubectl create secret tls server --cert server.crt --key server-key.pem
@@ -292,8 +299,8 @@ kubectl create secret tls server --cert server.crt --key server-key.pem
secret/server created
```
Finally, you can populate `ca.pem` in a configmap and use it as the trust root
to verify the serving certificate:
Finally, you can populate `ca.pem` into a {< glossary_tooltip text="ConfigMap" term_id="configmap" >}}
and use it as the trust root to verify the serving certificate:
```shell
kubectl create configmap example-serving-ca --from-file ca.crt=ca.pem
@@ -303,15 +310,24 @@ kubectl create configmap example-serving-ca --from-file ca.crt=ca.pem
configmap/example-serving-ca created
```
## Approving Certificate Signing Requests
## Approving CertificateSigningRequests {#approving-certificate-signing-requests}
A Kubernetes administrator (with appropriate permissions) can manually approve
(or deny) Certificate Signing Requests by using the `kubectl certificate
(or deny) CertificateSigningRequests by using the `kubectl certificate
approve` and `kubectl certificate deny` commands. However if you intend
to make heavy usage of this API, you might consider writing an automated
certificates controller.
Whether a machine or a human using kubectl as above, the role of the approver is
{{< caution >}}
The ability to approve CSRs decides who trusts whom within your environment. The
ability to approve CSRs should not be granted broadly or lightly.
You should make sure that you confidently understand both the verification requirements
that fall on the approver **and** the repercussions of issuing a specific certificate
before you grant the `approve` permission.
{{< /caution >}}
Whether a machine or a human using kubectl as above, the role of the _approver_ is
to verify that the CSR satisfies two requirements:
1. The subject of the CSR controls the private key used to sign the CSR. This
@@ -326,20 +342,15 @@ to verify that the CSR satisfies two requirements:
If and only if these two requirements are met, the approver should approve
the CSR and otherwise should deny the CSR.
## A Word of Warning on the Approval Permission
For more information on certificate approval and access control, read
the [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/)
reference page.
The ability to approve CSRs decides who trusts whom within your environment. The
ability to approve CSRs should not be granted broadly or lightly. The
requirements of the challenge noted in the previous section and the
repercussions of issuing a specific certificate should be fully understood
before granting this permission.
## Configuring your cluster to provide signing
## A Note to Cluster Administrators
This tutorial assumes that a signer is setup to serve the certificates API. The
This page assumes that a signer is setup to serve the certificates API. The
Kubernetes controller manager provides a default implementation of a signer. To
enable it, pass the `--cluster-signing-cert-file` and
`--cluster-signing-key-file` parameters to the controller manager with paths to
your Certificate Authority's keypair.
content/es/docs/concepts/overview/what-is-kubernetes.md
+1 -1
View File
@@ -54,7 +54,7 @@ facilitar sus flujos de trabajo y hacer más fácil a las herramientas administr
Además, el [Plano de Control](/docs/concepts/overview/components/) de Kubernetes usa las mismas
[APIs](/docs/reference/using-api/api-overview/) que usan los desarrolladores y usuarios finales.
Los usuarios pueden escribir sus propios controladores, como por ejemplo un planificador o [scheduler](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md),
Los usuarios pueden escribir sus propios controladores, como por ejemplo un planificador o [scheduler](https://github.com/kubernetes/community/blob/master/contributors/devel/scheduler.md),
usando [sus propias
APIs](/docs/concepts/api-extension/custom-resources/)
desde una [herramienta de línea de comandos](/docs/user-guide/kubectl-overview/).
content/es/docs/concepts/storage/volumes.md
+12 -12
View File
@@ -105,7 +105,7 @@ Para desactivar el complemento de almacenamiento `awsElasticBlockStore` de ser c
El tipo de volumen `azureDisk` monta un [Data Disk](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers) de Microsoft Azure en el Pod.
Para más detalles, mira el [`azureDisk` volume plugin](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md).
Para más detalles, mira el [`azureDisk` volume plugin](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_disk/README.md).
#### Migración CSI azureDisk
@@ -119,7 +119,7 @@ de complemento desde el complemento existente dentro del árbol existente al con
El tipo de volumen `azureFile` monta un volumen de ficheros de Microsoft Azure (SMB 2.1 and 3.0) en un Pod.
Para más detalles, mira el [`azureFile` volume plugin](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md).
Para más detalles, mira el [`azureFile` volume plugin](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_file/README.md).
#### Migración CSI azureFile CSI
@@ -141,7 +141,7 @@ A diferencia de `emptydir`, que es borrado cuando se remueve el Pod, el contenid
Debes tener tu propio servidor Ceph corriendo con el recurso compartido exportado antes de usarlo.
{{< /note >}}
Mira el [CephFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/) para más detalles.
Mira el [CephFS example](https://github.com/kubernetes/examples/tree/master/volumes/cephfs/) para más detalles.
### cinder
@@ -292,7 +292,7 @@ Debes configurar FC SAN zoning para asignar y enmascarar esos (volúmenes) LUNs
para que los hosts Kubernetes pueda acceder a ellos.
{{< /note >}}
Revisa el [ejemplo de canal de fibra](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel) para más detalles.
Revisa el [ejemplo de canal de fibra](https://github.com/kubernetes/examples/tree/master/staging/volumes/fibre_channel) para más detalles.
### flocker (deprecado) {#flocker}
@@ -306,7 +306,7 @@ de nuevo por Flocker al nodo donde el Pod está programado. Esto significa que l
Debes tener una instalación propia de Flocker ejecutándose antes de poder usarla.
{{< /note >}}
Mira el [ejemplo de Flocker ](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker) para más detalles.
Mira el [ejemplo de Flocker ](https://github.com/kubernetes/examples/tree/master/staging/volumes/flocker) para más detalles.
### gcePersistentDisk
@@ -453,7 +453,7 @@ y que los datos pueden ser compartidos entre pods. GlusterFS puede ser montado p
Debes tener tu propia instalación de GlusterFS ejecutándose antes de poder usarla.
{{< /note >}}
Mira el [ejemplo de GlusterFS](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs) para más detalles.
Mira el [ejemplo de GlusterFS](https://github.com/kubernetes/examples/tree/master/volumes/glusterfs) para más detalles.
### hostPath {#hostpath}
@@ -560,7 +560,7 @@ Esto significa que puedes pre-poblar un volumen con tu conjunto de datos y servi
Desafortunadamente, los volúmenes ISCSI solo se pueden montar por un único consumidor en modo lectura-escritura.
Escritores simultáneos no está permitido.
Mira el [ejemplo iSCSI](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi) para más detalles.
Mira el [ejemplo iSCSI](https://github.com/kubernetes/examples/tree/master/volumes/iscsi) para más detalles.
### local
@@ -634,7 +634,7 @@ NFS puede ser montado por múltiples escritores simultáneamente.
Debes tener tu propio servidor NFS en ejecución con el recurso compartido exportado antes de poder usarlo.
{{< /note >}}
Mira el [ ejemplo NFS ](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs) para más información.
Mira el [ ejemplo NFS ](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs) para más información.
### persistentVolumeClaim {#persistentvolumeclaim}
@@ -674,7 +674,7 @@ spec:
Asegúrate de tener un PortworxVolume con el nombre `pxvol` antes de usarlo en el Pod.
{{< /note >}}
Para más detalles, mira los ejemplos de [volumen Portworx](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md).
Para más detalles, mira los ejemplos de [volumen Portworx](https://github.com/kubernetes/examples/tree/master/staging/volumes/portworx/README.md).
### projected
@@ -687,7 +687,7 @@ Actualmente, se pueden los siguientes tipos de volúmenes:
- [`configMap`](#configmap)
- `serviceAccountToken`
Se requiere que todas las fuentes estén en el mismo namespace que el Pod. Para más detalles mira el [all-in-one volume design document](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md).
Se requiere que todas las fuentes estén en el mismo namespace que el Pod. Para más detalles mira el [all-in-one volume design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md).
#### Configuración de ejemplo con un secret, un downwardAPI, y un configMap {#example-configuration-secret-downwardapi-configmap}
@@ -828,7 +828,7 @@ Debes tener una instalación de Ceph ejecutándose antes de usar RBD.
Una función de RBD es que solo se puede montar como de solo lectura por múltiples consumidores simultáneamente.
Esto significa que puedes pre-poblar un volumen con tu conjunto de datos y luego servirlo en paralelo desde tantos pods como necesites. Desafortunadamente, los volúmenes RBD solo se pueden montar por un único consumidor en modo lectura-escritura. No se permiten escritores simultáneos.
Mira el [ejemplo RBD](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd) para más detalles.
Mira el [ejemplo RBD](https://github.com/kubernetes/examples/tree/master/volumes/rbd) para más detalles.
### scaleIO (deprecado) {#scaleio}
@@ -865,7 +865,7 @@ spec:
fsType: xfs
```
Para más detalles, mira los ejemplos de [ScaleIO](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio)
Para más detalles, mira los ejemplos de [ScaleIO](https://github.com/kubernetes/examples/tree/master/staging/volumes/scaleio)
### secret
content/es/docs/concepts/workloads/controllers/jobs-run-to-completion.md
+1 -1
View File
@@ -443,7 +443,7 @@ de controlador personalizado para esos Pods. Esto da la máxima flexibilidad, pe
cueste un poco más de entender y ofrece menos integración con Kubernetes.
Un ejemplo de este patrón sería un Job que arranca un Pod que ejecuta una secuencia de comandos que, a su vez,
arranca un controlador maestro de Spark (ver el [ejemplo de spark](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)),
arranca un controlador maestro de Spark (ver el [ejemplo de spark](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)),
ejecuta un manejador de spark, y a continuación lo limpia todo.
Una ventaja de este enfoque es que el proceso general obtiene la garantía del objeto Job,
content/es/docs/concepts/workloads/controllers/statefulset.md
+1 -1
View File
@@ -36,7 +36,7 @@ proporcione un conjunto de réplicas sin estado, como un
## Limitaciones
* El almacenamiento de un determinado Pod debe provisionarse por un [Provisionador de PersistentVolume](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) basado en la `storage class` requerida, o pre-provisionarse por un administrador.
* El almacenamiento de un determinado Pod debe provisionarse por un [Provisionador de PersistentVolume](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md) basado en la `storage class` requerida, o pre-provisionarse por un administrador.
* Eliminar y/o reducir un StatefulSet *no* eliminará los volúmenes asociados con el StatefulSet. Este comportamiento es intencional y sirve para garantizar la seguridad de los datos, que da más valor que la purga automática de los recursos relacionados del StatefulSet.
* Los StatefulSets actualmente necesitan un [Servicio Headless](/docs/concepts/services-networking/service/#headless-services) como responsable de la identidad de red de los Pods. Es tu responsabilidad crear este Service.
* Los StatefulSets no proporcionan ninguna garantía de la terminación de los pods cuando se elimina un StatefulSet. Para conseguir un término de los pods ordenado y controlado en el StatefulSet, es posible reducir el StatefulSet a 0 réplicas justo antes de eliminarlo.
content/es/docs/tasks/debug-application-cluster/audit.md
+2 -2
View File
@@ -421,8 +421,8 @@ al plugin de elasticsearch que soporta búsquedas avanzadas y analíticas.
[kube-apiserver]: /docs/admin/kube-apiserver
[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md
[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go
[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735
[auditing-api]: https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go
[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh#L735
[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/
[fluentd]: http://www.fluentd.org/
[fluentd_install_doc]: https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd
content/es/docs/tasks/tools/included/_index.md
+6
View File
@@ -0,0 +1,6 @@
---
title: "Herramientas incluidas"
description: "Fragmentos que se incluirán en las páginas principales de kubectl-installs-*."
headless: true
toc_hide: true
---
content/es/docs/tasks/tools/included/install-kubectl-linux.md
+244
View File
@@ -0,0 +1,244 @@
---
reviewers:
title: Instalar y configurar kubectl en Linux
content_type: task
weight: 10
card:
name: tasks
weight: 20
title: Instalar kubectl en Linux
---
## {{% heading "prerequisites" %}}
Debes usar una versión de kubectl que esté dentro de una diferencia de versión menor de tu clúster. Por ejemplo, un cliente v{{< skew latestVersion >}} puede comunicarse con v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, y v{{< skew nextMinorVersion >}} del plano de control.
El uso de la última versión de kubectl ayuda a evitar problemas inesperados.
## Instalar kubectl en Linux
Existen los siguientes métodos para instalar kubectl en Linux:
- [Instalar el binario kubectl con curl en Linux](#install-kubectl-binary-with-curl-on-linux)
- [Instalar usando la administración nativa de paquetes](#install-using-native-package-management)
- [Instalar usando otra administración de paquetes](#install-using-other-package-management)
### Instale el binario kubectl con curl en Linux
1. Descargue la última versión con el comando:
```bash
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
```
{{< note >}}
Para descargar una versión específica, reemplace la parte de `$(curl -L -s https://dl.k8s.io/release/stable.txt)` del comando con la versión específica.
Por ejemplo, para descargar la versión {{< param "fullversion" >}} en Linux, escriba:
```bash
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
```
{{< /note >}}
1. Validar el binario (opcional)
Descargue el archivo de comprobación de kubectl:
```bash
curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
```
Valide el binario kubectl con el archivo de comprobación:
```bash
echo "$(<kubectl.sha256) kubectl" | sha256sum --check
```
Si es válido, la salida es:
```console
kubectl: OK
```
Si la comprobación falla, `sha256` arroja un valor distinto de cero e imprime una salida similar a:
```bash
kubectl: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
```
{{< note >}}
Descargue la misma versión del binario y el archivo de comprobación.
{{< /note >}}
1. Instalar kubectl
```bash
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
```
{{< note >}}
Si no tiene acceso de root en el sistema de destino, aún puede instalar kubectl en el `~/.local/bin` directorio:
```bash
chmod +x kubectl
mkdir -p ~/.local/bin/kubectl
mv ./kubectl ~/.local/bin/kubectl
# y luego agregue ~/.local/bin/kubectl en el $PATH
```
{{< /note >}}
1. Para asegurarse de que la versión que instaló este actualizada ejecute:
```bash
kubectl version --client
```
### Instalar usando la administración nativa de paquetes
{{< tabs name="kubectl_install" >}}
{{% tab name="Debian-based distributions" %}}
1. Actualice el índice de paquetes de `apt` e instale los paquetes necesarios para usar Kubernetes con el repositorio `apt`:
```shell
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl
```
2. Descargue la clave de firma pública de Google Cloud:
```shell
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
```
3. Agregue el repositorio de Kubernetes a `apt`:
```shell
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
```
4. Actualice el índice de paquetes de `apt` con el nuevo repositorio e instale kubectl:
```shell
sudo apt-get update
sudo apt-get install -y kubectl
```
{{% /tab %}}
{{< tab name="Red Hat-based distributions" codelang="bash" >}}
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
yum install -y kubectl
{{< /tab >}}
{{< /tabs >}}
### Instalar usando otra administración de paquetes
{{< tabs name="other_kubectl_install" >}}
{{% tab name="Snap" %}}
Si está en Ubuntu u otra distribución de Linux que admita el administrador de paquetes [snap](https://snapcraft.io/docs/core/install), kubectl estará disponible como solicitud de [snap](https://snapcraft.io/).
```shell
snap install kubectl --classic
kubectl version --client
```
{{% /tab %}}
{{% tab name="Homebrew" %}}
Si está en Linux y usa [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) como administrador de paquetes, kubectl está disponible para [instalación](https://docs.brew.sh/Homebrew-on-Linux#install).
```shell
brew install kubectl
kubectl version --client
```
{{% /tab %}}
{{< /tabs >}}
## Verificar la configuración de kubectl
{{< include "verify-kubectl.md" >}}
## Plugins y configuraciones opcionales de kubectl
### Habilitar el autocompletado de shell
kubectl proporciona soporte de autocompletado para Bash y Zsh, lo que puede ahorrarle mucho tiempo al interactuar con la herramienta.
A continuación, se muestran los procedimientos para configurar el autocompletado para Bash y Zsh.
{{< tabs name="kubectl_autocompletion" >}}
{{< tab name="Bash" include="optional-kubectl-configs-bash-linux.md" />}}
{{< tab name="Zsh" include="optional-kubectl-configs-zsh.md" />}}
{{< /tabs >}}
### Instalar en pc `kubectl convert` plugin
{{< include "kubectl-convert-overview.md" >}}
1. Descargue la última versión con el comando:
```bash
curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert
```
1. Valide el binario (opcional)
Descargue el archivo de comprobación kubectl-convert:
```bash
curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert.sha256"
```
Valide el binario kubectl-convert con el archivo de comprobación:
```bash
echo "$(<kubectl-convert.sha256) kubectl-convert" | sha256sum --check
```
Si es válido, la salida es:
```console
kubectl-convert: OK
```
Si la comprobación falla, `sha256` arroja un valor distinto de cero e imprime una salida similar a:
```bash
kubectl-convert: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
```
{{< note >}}
Descargue la misma versión del binario y el archivo de comprobación.
{{< /note >}}
1. Instale kubectl-convert en pc
```bash
sudo install -o root -g root -m 0755 kubectl-convert /usr/local/bin/kubectl-convert
```
1. Verifique que el plugin se haya instalado correctamente
```shell
kubectl convert --help
```
Si no ve un error, significa que el plugin se instaló correctamente.
## {{% heading "whatsnext" %}}
{{< include "kubectl-whats-next.md" >}}
content/es/docs/tasks/tools/included/install-kubectl-macos.md
+248
View File
@@ -0,0 +1,248 @@
---
reviewers:
title: Instalar y configurar kubectl en macOS
content_type: task
weight: 10
card:
name: tasks
weight: 20
title: Instalar kubectl en macOS
---
## {{% heading "prerequisites" %}}
Debes usar una versión de kubectl que esté dentro de una diferencia de versión menor de tu clúster. Por ejemplo, un cliente v{{< skew latestVersion >}} puede comunicarse con v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, y v{{< skew nextMinorVersion >}} del plano de control.
El uso de la última versión de kubectl ayuda a evitar problemas imprevistos.
## Instalar kubectl en macOS
Existen los siguientes métodos para instalar kubectl en macOS:
- [Instalar el binario de kubectl con curl en macOS](#install-kubectl-binary-with-curl-on-macos)
- [Instalar con Homebrew en macOS](#install-with-homebrew-on-macos)
- [Instalar con Macports en macOS](#install-with-macports-on-macos)
### Instalar el binario de kubectl con curl en macOS
1. Descargue la última versión:
{{< tabs name="download_binary_macos" >}}
{{< tab name="Intel" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
{{< /tab >}}
{{< tab name="Apple Silicon" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl"
{{< /tab >}}
{{< /tabs >}}
{{< note >}}
Para descargar una versión específica, reemplace el `$(curl -L -s https://dl.k8s.io/release/stable.txt)` parte del comando con la versión específica.
Por ejemplo, para descargar la versión {{< param "fullversion" >}} en Intel macOS, escriba:
```bash
curl -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl"
```
Y para macOS en Apple Silicon, escriba:
```bash
curl -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/arm64/kubectl"
```
{{< /note >}}
1. Validar el binario (opcional)
Descargue el archivo de comprobación de kubectl:
{{< tabs name="download_checksum_macos" >}}
{{< tab name="Intel" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256"
{{< /tab >}}
{{< tab name="Apple Silicon" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl.sha256"
{{< /tab >}}
{{< /tabs >}}
Valide el binario kubectl con el archivo de comprobación:
```bash
echo "$(<kubectl.sha256) kubectl" | shasum -a 256 --check
```
Si es válido, la salida es:
```console
kubectl: OK
```
Si la verificación falla, `shasum` arroja un valor distinto de cero e imprime una salida similar a:
```bash
kubectl: FAILED
shasum: WARNING: 1 computed checksum did NOT match
```
{{< note >}}
Descargue la misma versión del binario y el archivo de comprobación.
{{< /note >}}
1. Hacer ejecutable el binario de kubectl.
```bash
chmod +x ./kubectl
```
1. Mueva el binario kubectl a una ubicación de archivo en su sistema `PATH`.
```bash
sudo mv ./kubectl /usr/local/bin/kubectl
sudo chown root: /usr/local/bin/kubectl
```
{{< note >}}
Asegúrese de que `/usr/local/bin` se encuentre definida en su variable de entorno PATH.
{{< /note >}}
1. Para asegurarse de que la versión que instaló se encuentra actualizada, ejecute:
```bash
kubectl version --client
```
### Instalar con Homebrew en macOS
Si está en macOS y usa [Homebrew](https://brew.sh/) como administrador de paquetes, puede instalar kubectl con Homebrew.
1. Ejecute el comando de instalación:
```bash
brew install kubectl
```
or
```bash
brew install kubernetes-cli
```
1. Para asegurarse de que la versión que instaló se encuentra actualizada, ejecute:
```bash
kubectl version --client
```
### Instalar con Macports en macOS
Si está en macOS y usa [Macports](https://macports.org/) como administrador de paquetes, puede instalar kubectl con Macports.
1. Ejecute el comando de instalación:
```bash
sudo port selfupdate
sudo port install kubectl
```
1. Para asegurarse de que la versión que instaló se encuentra actualizada, ejecute:
```bash
kubectl version --client
```
## Verificar la configuración de kubectl
{{< include "verify-kubectl.md" >}}
## Plugins y configuraciones opcionales de kubectl
### Habilitar el autocompletado de shell
kubectl proporciona soporte de autocompletado para Bash y Zsh, lo que puede ahorrarle mucho tiempo al escribir.
A continuación, se muestran los procedimientos para configurar el autocompletado para Bash y Zsh.
{{< tabs name="kubectl_autocompletion" >}}
{{< tab name="Bash" include="optional-kubectl-configs-bash-mac.md" />}}
{{< tab name="Zsh" include="optional-kubectl-configs-zsh.md" />}}
{{< /tabs >}}
### Instalar el plugin `kubectl-convert`
{{< include "kubectl-convert-overview.md" >}}
1. Descargue la última versión con el comando:
{{< tabs name="download_convert_binary_macos" >}}
{{< tab name="Intel" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert"
{{< /tab >}}
{{< tab name="Apple Silicon" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert"
{{< /tab >}}
{{< /tabs >}}
1. Validar el binario (opcional)
Descargue el archivo de comprobación de kubectl:
{{< tabs name="download_convert_checksum_macos" >}}
{{< tab name="Intel" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert.sha256"
{{< /tab >}}
{{< tab name="Apple Silicon" codelang="bash" >}}
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert.sha256"
{{< /tab >}}
{{< /tabs >}}
Valide el binario kubectl-convert con el archivo de comprobación:
```bash
echo "$(<kubectl-convert.sha256) kubectl-convert" | shasum -a 256 --check
```
Si es válido, la salida es:
```console
kubectl-convert: OK
```
Si la verificación falla, `shasum` arroja un valor distinto de cero e imprime una salida similar a:
```bash
kubectl-convert: FAILED
shasum: WARNING: 1 computed checksum did NOT match
```
{{< note >}}
Descargue la misma versión del binario y el archivo de comprobación.
{{< /note >}}
1. Hacer ejecutable el binario de kubectl-convert
```bash
chmod +x ./kubectl-convert
```
1. Mueva el binario kubectl-convert a una ubicación de archivo en su sistema `PATH`.
```bash
sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert
sudo chown root: /usr/local/bin/kubectl-convert
```
{{< note >}}
Asegúrese de que `/usr/local/bin` se encuentre definida en su variable de entorno PATH.
{{< /note >}}
1. Verifique que el complemento se haya instalado correctamente
```shell
kubectl convert --help
```
Si no ve algun error, significa que el complemento se instaló correctamente.
## {{% heading "whatsnext" %}}
{{< include "kubectl-whats-next.md" >}}
content/es/docs/tasks/tools/included/install-kubectl-windows.md
+190
View File
@@ -0,0 +1,190 @@
---
reviewers:
title: Instalar y configurar kubectl en Windows
content_type: task
weight: 10
card:
name: tasks
weight: 20
title: Instalar kubectl en Windows
---
## {{% heading "prerequisites" %}}
Debes usar una versión de kubectl que este dentro de una diferencia de versión menor de tu clúster. Por ejemplo, un cliente v{{< skew latestVersion >}} puede comunicarse con versiones v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, y v{{< skew nextMinorVersion >}} del plano de control.
El uso de la última versión de kubectl ayuda a evitar problemas imprevistos.
## Instalar kubectl en Windows
Existen los siguientes métodos para instalar kubectl en Windows:
- [Instalar el binario de kubectl con curl en Windows](#install-kubectl-binary-with-curl-on-windows)
- [Instalar en Windows usando Chocolatey o Scoop](#install-on-windows-using-chocolatey-or-scoop)
### Instalar el binario de kubectl con curl en Windows
1. Descarga la [última versión {{< param "fullversion" >}}](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe).
O si tiene `curl` instalado, use este comando:
```powershell
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
```
{{< note >}}
Para conocer la última versión estable (por ejemplo, para secuencias de comandos), eche un vistazo a [https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt).
{{< /note >}}
1. Validar el binario (opcional)
Descargue el archivo de comprobación de kubectl:
```powershell
curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256
```
Valide el binario kubectl con el archivo de comprobación:
- Usando la consola del sistema para comparar manualmente la salida de `CertUtil` con el archivo de comprobación descargado:
```cmd
CertUtil -hashfile kubectl.exe SHA256
type kubectl.exe.sha256
```
- Usando PowerShell puede automatizar la verificación usando el operador `-eq` para obtener un resultado de `True` o `False`:
```powershell
$($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256)
```
1. Agregue el binario a su `PATH`.
1. Para asegurar que la versión de`kubectl` es la misma que descargada, ejecute:
```cmd
kubectl version --client
```
{{< note >}}
[Docker Desktop para Windows](https://docs.docker.com/docker-for-windows/#kubernetes) agrega su propia versión de `kubectl` a el `PATH`.
Si ha instalado Docker Desktop antes, es posible que deba colocar su entrada en el `PATH` antes de la agregada por el instalador de Docker Desktop o elimine el `kubectl`.
{{< /note >}}
### Instalar en Windows usando Chocolatey o Scoop
1. Para instalar kubectl en Windows, puede usar [Chocolatey](https://chocolatey.org)
como administrador de paquetes o el instalador [Scoop](https://scoop.sh) desde línea de comandos.
{{< tabs name="kubectl_win_install" >}}
{{% tab name="choco" %}}
```powershell
choco install kubernetes-cli
```
{{% /tab %}}
{{% tab name="scoop" %}}
```powershell
scoop install kubectl
```
{{% /tab %}}
{{< /tabs >}}
1. Para asegurarse de que la versión que instaló esté actualizada, ejecute:
```powershell
kubectl version --client
```
1. Navegue a su directorio de inicio:
```powershell
# Si estas usando cmd.exe, correr: cd %USERPROFILE%
cd ~
```
1. Cree el directorio `.kube`:
```powershell
mkdir .kube
```
1. Cambie al directorio `.kube` que acaba de crear:
```powershell
cd .kube
```
1. Configure kubectl para usar un clúster de Kubernetes remoto:
```powershell
New-Item config -type file
```
{{< note >}}
Edite el archivo de configuración con un editor de texto de su elección, como el Bloc de notas.
{{< /note >}}
## Verificar la configuración de kubectl
{{< include "verify-kubectl.md" >}}
## Plugins y configuraciones opcionales de kubectl
### Habilitar el autocompletado de shell
kubectl proporciona soporte de autocompletado para Bash y Zsh, lo que puede ahorrarle mucho tiempo al escribir.
A continuación se muestran los procedimientos para configurar el autocompletado para Zsh, si lo está ejecutando en Windows.
{{< include "optional-kubectl-configs-zsh.md" >}}
### Instalar el plugin `kubectl-convert`
{{< include "kubectl-convert-overview.md" >}}
1. Descargue la última versión con el comando:
```powershell
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe
```
1. Validar el binario (opcional)
Descargue el archivo de comprobación kubectl-convert:
```powershell
curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe.sha256
```
Valide el binario kubectl-convert con el archivo de comprobación:
- Usando la consola del sistema puede comparar manualmente la salida de `CertUtil` con el archivo de comprobación descargado:
```cmd
CertUtil -hashfile kubectl-convert.exe SHA256
type kubectl-convert.exe.sha256
```
- Usando PowerShell puede automatizar la verificación usando el operador `-eq`
para obtener un resultado de `True` o `False`:
```powershell
$($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256)
```
1. Agregue el binario a su `PATH`.
1. Verifique que el plugin se haya instalado correctamente
```shell
kubectl convert --help
```
Si no ve un error, significa que el plugin se instaló correctamente.
## {{% heading "whatsnext" %}}
{{< include "kubectl-whats-next.md" >}}
content/es/docs/tasks/tools/included/kubectl-convert-overview.md
+9
View File
@@ -0,0 +1,9 @@
---
title: "Descripción general de kubectl-convert"
description: >-
Un plugin de kubectl que le permite convertir manifiestos de una versión
headless: true
---
Un plugin para la herramienta de línea de comandos de Kubernetes `kubectl`, que le permite convertir manifiestos entre diferentes versiones de la API. Esto puede ser particularmente útil para migrar manifiestos a una versión no obsoleta de la API con la versión más reciente de Kubernetes.
Para obtener más información, visite [migrar a APIs no obsoletas](/docs/reference/using-api/deprecation-guide/#migrate-to-non-deprecated-apis)
content/es/docs/tasks/tools/included/kubectl-whats-next.md
+12
View File
@@ -0,0 +1,12 @@
---
title: "¿Que sigue?"
description: "¿Qué sigue después de instalar kubectl."
headless: true
---
* [Instalar Minikube](https://minikube.sigs.k8s.io/docs/start/)
* Consulte las [guías de introducción](/docs/setup/) para obtener más información sobre la creación de clústeres.
* [Aprenda a iniciar y exponer su aplicación.](/docs/tasks/access-application-cluster/service-access-application-cluster/)
* Si necesita acceso a un clúster que no creó, consulte la guia de
[Compartir el acceso al clúster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
* Lea los [documentos de referencia de kubectl](/docs/reference/kubectl/kubectl/)
content/es/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md
+54
View File
@@ -0,0 +1,54 @@
---
title: "Autocompletar bash en Linux"
description: "Alguna configuración opcional para la finalización automática de bash en Linux."
headless: true
---
### Introducción
El script de completado de kubectl para Bash se puede generar con el comando `kubectl completion bash`. Obtener el script de completado en su shell habilita el autocompletado de kubectl.
Sin embargo, el script de completado depende de [**bash-completion**](https://github.com/scop/bash-completion), lo que significa que primero debe instalar este software (puedes probar si tienes bash-completion ya instalado ejecutando `type _init_completion`).
### Instalar bash-complete
El completado de bash es proporcionado por muchos administradores de paquetes (ver [aquí](https://github.com/scop/bash-completion#installation)). Puedes instalarlo con `apt-get install bash-completion` o `yum install bash-completion`, etc.
Los comandos anteriores crean `/usr/share/bash-completion/bash_completion`, que es el script principal de bash-complete. Dependiendo de su administrador de paquetes, debe obtener manualmente este archivo de perfil en su `~/.bashrc`.
Para averiguarlo, recargue su shell y ejecute `type _init_completion`. Si el comando tiene éxito, ya está configurado; de lo contrario, agregue lo siguiente a su archivo `~/.bashrc`:
```bash
source /usr/share/bash-completion/bash_completion
```
Vuelva a cargar su shell y verifique que la finalización de bash esté correctamente instalada escribiendo `type _init_completion`.
### Habilitar el autocompletado de kubectl
Ahora debe asegurarse de que el script de completado de kubectl se obtenga en todas sus sesiones de shell. Hay dos formas de hacer esto:
- Obtenga el script de completado en su perfil `~/.bashrc`:
```bash
echo 'source <(kubectl completion bash)' >>~/.bashrc
```
- Agregue el script de completado al directorio de `/etc/bash_completion.d`:
```bash
kubectl completion bash >/etc/bash_completion.d/kubectl
```
Si tiene un alias para kubectl, puede extender el completado del shell para trabajar con ese alias:
```bash
echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -F __start_kubectl k' >>~/.bashrc
```
{{< note >}}
El código fuente de bash-complete todos los scripts se encuentra en `/etc/bash_completion.d`.
{{< /note >}}
Ambos enfoques son equivalentes. Después de recargar su shell, el autocompletado de kubectl debería estar funcionando.
content/es/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md
+88
View File
@@ -0,0 +1,88 @@
---
title: "Autocompletar bash en macOS"
description: "Alguna configuración opcional para la finalización automática de bash en macOS."
headless: true
---
### Introducción
El script de completado de kubectl para Bash se puede generar con `kubectl completion bash`. Obtener este script en su shell permite el completado de kubectl.
Sin embargo, el script de finalización de kubectl depende de [**bash-completion**](https://github.com/scop/bash-completion) que, por lo tanto, debe instalar previamente.
{{< warning>}}
Hay dos versiones de bash-complete, v1 y v2. V1 es para Bash 3.2 (
que es el predeterminado en macOS), y v2 es para Bash 4.1+. El script de completado de kubectl **no funciona** correctamente con bash-complete v1 y Bash 3.2. Requiere **bash-complete v2** y **Bash 4.1+**. Por lo tanto, para poder usar correctamente la finalización de kubectl en macOS, debe instalar y usar Bash 4.1+ ([*instrucciones*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). Las siguientes instrucciones asumen que usa Bash 4.1+ (es decir, cualquier versión de Bash de 4.1 o posterior).
{{< /warning >}}
### Actualizar Bash
Las siguientes instrucciones asumen que usa Bash 4.1+. Puede verificar la versión de su Bash ejecutando:
```bash
echo $BASH_VERSION
```
Si es demasiado antiguo, puede instalarlo o actualizarlo usando Homebrew:
```bash
brew install bash
```
Vuelva a cargar su shell y verifique que se esté utilizando la versión deseada:
```bash
echo $BASH_VERSION $SHELL
```
Homebrew generalmente lo instala en `/usr/local/bin/bash`.
### Instalar bash-complete
{{< note >}}
Como se mencionó antes, estas instrucciones asumen que usa Bash 4.1+, lo que significa que instalará bash-completacion v2 (a diferencia de Bash 3.2 y bash-deployment v1, en cuyo caso el completado de kubectl no funcionará).
{{< /note >}}
Puede probar si ya tiene instalado bash-complete v2 con `type _init_completion`. Si no es así, puede instalarlo con Homebrew:
```bash
brew install bash-completion@2
```
Como se indica en el resultado de este comando, agregue lo siguiente a su archivo `~/.bash_profile`:
```bash
export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
```
Vuelva a cargar su shell y verifique que bash-complete v2 esté instalado correctamente con `type _init_completion`.
### Habilitar el autocompletado de kubectl
Ahora debe asegurarse de que el script de completado de kubectl se obtenga en todas sus sesiones de shell. Hay varias formas de lograrlo:
- Obtenga el script de finalización en su perfil `~/.bash_profile`:
```bash
echo 'source <(kubectl completion bash)' >>~/.bash_profile
```
- Agregue el script de completado al directorio `/usr/local/etc/bash_completion.d`:
```bash
kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
```
- Si tiene un alias para kubectl, puede extender el completado del shell para trabajar con ese alias:
```bash
echo 'alias k=kubectl' >>~/.bash_profile
echo 'complete -F __start_kubectl k' >>~/.bash_profile
```
- Si instaló kubectl con Homebrew (como se explica [aquí](/docs/tasks/tools/install-kubectl-macos/#install-with-homebrew-on-macos)), entonces el script de completado de kubectl ya debería estar en `/usr/local/etc/bash_completion.d/kubectl`. En ese caso, no necesita hacer nada.
{{< note >}}
La instalación de Homebrew de bash-completion v2 genera todos los archivos en el directorio `BASH_COMPLETION_COMPAT_DIR`, es por eso que los dos últimos métodos funcionan.
{{< /note >}}
En cualquier caso, después de recargar su shell, el completado de kubectl debería estar funcionando.
content/es/docs/tasks/tools/included/optional-kubectl-configs-zsh.md
+29
View File
@@ -0,0 +1,29 @@
---
title: "Autocompletar zsh"
description: "Alguna configuración opcional para la finalización automática de zsh."
headless: true
---
El script de completado de kubectl para Zsh se puede generar con el comando `kubectl completion zsh`. Obtener el script de completado en su shell habilita el autocompletado de kubectl.
Para hacerlo en todas sus sesiones de shell, agregue lo siguiente a su perfil `~/.zshrc`:
```zsh
source <(kubectl completion zsh)
```
Si tiene un alias para kubectl, puede extender el completado del shell para trabajar con ese alias:
```zsh
echo 'alias k=kubectl' >>~/.zshrc
echo 'compdef __start_kubectl k' >>~/.zshrc
```
Después de recargar su shell, el autocompletado de kubectl debería estar funcionando.
Si recibe un error como `complete:13: command not found: compdef`,
luego agregue lo siguiente al comienzo de su perfil `~/.zshrc`:
```zsh
autoload -Uz compinit
compinit
```
content/es/docs/tasks/tools/included/verify-kubectl.md
+31
View File
@@ -0,0 +1,31 @@
---
title: "verificar la instalación de kubectl"
description: "Cómo verificar kubectl."
headless: true
---
Para que kubectl encuentre y acceda a un clúster de Kubernetes, necesita un
[archivo kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/), que se crea automáticamente cuando creas un clúster usando
[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)
o implementar con éxito un clúster de Minikube.
De forma predeterminada, la configuración de kubectl se encuentra en `~/.kube/config`.
Verifique que kubectl esté configurado correctamente obteniendo el estado del clúster:
```shell
kubectl cluster-info
```
Si ve una respuesta de URL, kubectl está configurado correctamente para acceder a su clúster.
Si ve un mensaje similar al siguiente, kubectl no está configurado correctamente o no puede conectarse a un clúster de Kubernetes.
```
The connection to the server <server-name:port> was refused - did you specify the right host or port?
```
Por ejemplo, si tiene la intención de ejecutar un clúster de Kubernetes en su computadora portátil (localmente), primero necesitará instalar una herramienta como Minikube y luego volver a ejecutar los comandos indicados anteriormente.
Si kubectl cluster-info devuelve la respuesta de la URL pero no puede acceder a su clúster, para verificar si está configurado correctamente, use:
```shell
kubectl cluster-info dump
```
content/es/docs/tasks/tools/install-kubectl.md
-515
View File
@@ -1,515 +0,0 @@
---
title: Instalar y Configurar kubectl
content_type: task
weight: 10
card:
name: tasks
weight: 20
title: Instalar kubectl
---
<!-- overview -->
Usa la herramienta de línea de comandos de Kubernetes, [kubectl](/docs/reference/kubectl/kubectl/), para desplegar y gestionar aplicaciones en Kubernetes. Usando kubectl, puedes inspeccionar recursos del clúster; crear, eliminar, y actualizar componentes; explorar tu nuevo clúster; y arrancar aplicaciones de ejemplo. Para ver la lista completa de operaciones de kubectl, se puede ver [el resumen de kubectl](/docs/reference/kubectl/overview/).
## {{% heading "prerequisites" %}}
Debes usar una versión de kubectl que esté a menos de una versión menor de diferencia con tu clúster. Por ejemplo, un cliente v1.2 debería funcionar con un máster v1.1, v1.2, y v1.3. Usar la última versión de kubectl ayuda a evitar problemas inesperados.
<!-- steps -->
## Instalar kubectl en Linux
### Instalar el binario de kubectl con curl en Linux
1. Descargar la última entrega:
```
curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
```
Para descargar una versión específica, remplaza el comando `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` con la versión específica.
Por ejemplo, para descarga la versión {{< param "fullversion" >}} en Linux, teclea:
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
```
2. Habilita los permisos de ejecución del binario `kubectl`.
```
chmod +x ./kubectl
```
3. Mueve el binario dentro de tu PATH.
```
sudo mv ./kubectl /usr/local/bin/kubectl
```
4. Comprueba que la versión que se ha instalado es la más reciente.
```
kubectl version --client
```
## Instalar mediante el gestor de paquetes del sistema
{{< tabs name="kubectl_install" >}}
{{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}}
sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubectl
{{< /tab >}}
{{< tab name="CentOS, RHEL or Fedora" codelang="bash" >}}cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
sudo yum install -y kubectl
{{< /tab >}}
{{< /tabs >}}
### Instalar usando otro gestor de paquetes
{{< tabs name="other_kubectl_install" >}}
{{% tab name="Snap" %}}
Si usas Ubuntu o alguna de las otras distribuciones de Linux que soportan el gestor de paquetes [snap](https://snapcraft.io/docs/core/install), kubectl está disponible como una aplicación [snap](https://snapcraft.io/).
```shell
snap install kubectl --classic
kubectl version --client
```
{{% /tab %}}
{{% tab name="Homebrew" %}}
Si usas alguna de las otras distribuciones de Linux que soportan el gestor de paquetes [Homebrew](https://docs.brew.sh/Homebrew-on-Linux), kubectl está disponible como una aplicación de [Homebrew]((https://docs.brew.sh/Homebrew-on-Linux#install).
```shell
brew install kubectl
kubectl version --client
```
{{% /tab %}}
{{< /tabs >}}
## Instalar kubectl en macOS
### Instalar el binario de kubectl usando curl en macOS
1. Descarga la última entrega:
```bash
curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl"
```
Para descargar una versión específica, remplaza el comando `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` con la versión específica.
Por ejemplo, para descargar la versión {{< param "fullversion" >}} en macOS, teclea:
```bash
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
```
2. Habilita los permisos de ejecución del binario `kubectl`.
```bash
chmod +x ./kubectl
```
3. Mueve el binario dentro de tu PATH.
```bash
sudo mv ./kubectl /usr/local/bin/kubectl
```
4. Para asegurar que la versión utilizada sea la más actual puedes probar:
```bash
kubectl version --client
```
### Instalar con Homebrew en macOS
Si estás usando macOS y el gestor de paquetes es [Homebrew](https://brew.sh/), puedes instalar `kubectl` con `brew`.
1. Ejecuta el comando de instalación:
```bash
brew install kubectl
```
o
```bash
brew install kubernetes-cli
```
2. Para asegurar que la versión utilizada sea la más actual, puedes ejecutar:
```bash
kubectl version --client
```
### Instalar con Macports en macOS
Si estás en macOS y utilizas el gestor de paquetes [Macports](https://macports.org/), puedes instalar `kubectl` con `port`.
1. Ejecuta los comandos de instalación:
```bash
sudo port selfupdate
sudo port install kubectl
```
2. Para asegurar que la versión utilizada sea la más actual puedes ejecutar:
```bash
kubectl version --client
```
# Instalar kubectl en Windows
### Instalar el binario de kubectl con curl en Windows
1. Descargar la última entrega {{< param "fullversion" >}} de [este link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe).
o si tiene `curl` instalada, utiliza este comando:
```bash
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
```
Para averiguar la última versión estable (por ejemplo, para secuencias de comandos), echa un vistazo a [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt).
2. Añade el binario a tu PATH.
3. Para asegurar que la versión utilizada sea la más actual, puedes ejecutar:
```bash
kubectl version --client
```
{{< note >}}
[Docker Desktop para Windows](https://docs.docker.com/docker-for-windows/#kubernetes) añade su propia versión de `kubectl` a PATH.
Si tienes Docker Desktop instalado, es posible que tengas que modificar tu PATH al PATH añadido por Docker Desktop o eliminar la versión de `kubectl` proporcionada por Docker Desktop.
{{< /note >}}
### Instalar con Powershell desde PSGallery
Si estás en Windows y utilizas el gestor de paquetes [Powershell Gallery](https://www.powershellgallery.com/), puedes instalar y actualizar kubectl con Powershell.
1. Ejecuta los comandos de instalación (asegurándote de especificar una `DownloadLocation`):
```powershell
Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force
install-kubectl.ps1 [-DownloadLocation <path>]
```
{{< note >}}Si no especificas una `DownloadLocation`, `kubectl` se instalará en el directorio temporal del usuario.{{< /note >}}
El instalador crea `$HOME/.kube` y crea un archivo de configuración
2. Para asegurar que la versión utilizada sea la más actual puedes probar:
```powershell
kubectl version --client
```
{{< note >}}
Actualizar la instalación se realiza mediante la re-ejecución de los dos comandos listados en el paso 1.{{< /note >}}
### Instalar en Windows usando Chocolatey o scoop
1. Para instalar kubectl en Windows puedes usar el gestor de paquetes [Chocolatey](https://chocolatey.org) o el instalador de línea de comandos [scoop](https://scoop.sh).
{{< tabs name="kubectl_win_install" >}}
{{% tab name="choco" %}}
Using [Chocolatey](https://chocolatey.org).
```powershell
choco install kubernetes-cli
```
{{% /tab %}}
{{% tab name="scoop" %}}
Using [scoop](https://scoop.sh).
```powershell
scoop install kubectl
```
{{% /tab %}}
{{< /tabs >}}
2. Para asegurar que la versión utilizada sea la más actual puedes probar:
```powershell
kubectl version --client
```
3. Navega a tu directorio de inicio:
```powershell
# Si estas usando cmd.exe, ejecuta: cd %USERPROFILE%
cd ~
```
4. Crea el directorio `.kube`:
```powershell
mkdir .kube
```
5. Cambia al directorio `.kube` que acabas de crear:
```powershell
cd .kube
```
6. Configura kubectl para usar un clúster remoto de Kubernetes:
```powershell
New-Item config -type file
```
{{< note >}}Edita el fichero de configuración con un editor de texto de tu elección, como Notepad.{{< /note >}}
## Descarga como parte del Google Cloud SDK
Puedes instalar kubectl como parte del Google Cloud SDK.
1. Instala el [Google Cloud SDK](https://cloud.google.com/sdk/).
2. Ejecuta el comando de instalación de `kubectl`:
```shell
gcloud components install kubectl
```
3. Para asegurar que la versión utilizada sea la más actual puedes probar:
```shell
kubectl version --client
```
## Comprobar la configuración kubectl
Para que kubectl pueda encontrar y acceder a un clúster de Kubernetes, necesita un [fichero kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), que se crea de forma automática cuando creas un clúster usando [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) o despliegas de forma satisfactoria un clúster de Minikube. Revisa las [guías para comenzar](/docs/setup/) para más información acerca de crear clústers. Si necesitas acceso a un clúster que no has creado, ver el [documento de Compartir Acceso a un Clúster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
Por defecto, la configuración de kubectl se encuentra en `~/.kube/config`.
Comprueba que kubectl está correctamente configurado obteniendo el estado del clúster:
```shell
kubectl cluster-info
```
Si ves una respuesta en forma de URL, kubectl está correctamente configurado para acceder a tu clúster.
Si ves un mensaje similar al siguiente, kubectl no está correctamente configurado o no es capaz de conectar con un clúster de Kubernetes.
```
The connection to the server <server-name:port> was refused - did you specify the right host or port?
```
Por ejemplo, si intentas ejecutar un clúster de Kubernetes en tu portátil (localmente), necesitarás una herramienta como minikube que esté instalada primero y entonces volver a ejecutar los comandos indicados arriba.
Si kubectl cluster-info devuelve la respuesta en forma de url, pero no puedes acceder a tu clúster, para comprobar si está configurado adecuadamente, usa:
```shell
kubectl cluster-info dump
```
## kubectl configuraciones opcionales
### Habilitar el auto-completado en el intérprete de comandos
kubectl provee de soporte para auto-completado para Bash y Zsh, ¡que te puede ahorrar mucho uso del teclado!
Abajo están los procedimientos para configurar el auto-completado para Bash (incluyendo la diferencia entre Linux y macOS) y Zsh.
{{< tabs name="kubectl_autocompletion" >}}
{{% tab name="Bash en Linux" %}}
### Introducción
La secuencia de comandos de completado de kubectl para Bash puede ser generado con el comando `kubectl completion bash`. Corriendo la secuencia de comandos de completado en tu intérprete de comandos habilita el auto-completado de kubectl.
Sin embargo, la secuencia de comandos de completado depende de [*bash-completion**](https://github.com/scop/bash-completion), lo que significa que tienes que instalar primero este programa (puedes probar si ya tienes bash-completion instalado ejecutando `type _init_completion`).
### Instalar bash-completion
bash-completion es ofrecido por muchos gestores de paquetes (ver [aquí](https://github.com/scop/bash-completion#installation)). Puedes instalarlo con `apt-get install bash-completion` o `yum install bash-completion`, etc.
Los comandos de arriba crean `/usr/share/bash-completion/bash_completion`, que es la secuencia de comandos principal de bash-completion. Dependiendo de tu gestor de paquetes, tienes que correr manualmente este archivo en tu `~/.bashrc`.
Para averiguarlo, recarga tu intérprete de comandos y ejecuta `type _init_completion`. Si el comando tiene éxito, ya has terminado; si no, añade lo siguiente a tu `~/.bashrc`:
```shell
source /usr/share/bash-completion/bash_completion
```
recarga tu intérprete de comandos y verifica que bash-completion está correctamente instalado tecleando `type _init_completion`.
### Habilitar el auto-completado de kubectl
Debes asegurarte que la secuencia de comandos de completado de kubectl corre en todas tus sesiones de tu intérprete de comandos. Hay dos formas en que puedes hacer esto:
- Corre la secuencia de comandos de completado en tu `~/.bashrc`:
```bash
echo 'source <(kubectl completion bash)' >>~/.bashrc
```
- Añade la secuencia de comandos de completado al directorio `/etc/bash_completion.d`:
```bash
kubectl completion bash >/etc/bash_completion.d/kubectl
```
Si tienes un alias para `kubectl`, puedes extender los comandos de shell para funcionar con ese alias:
```bash
echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -F __start_kubectl k' >>~/.bashrc
```
{{< note >}}
bash-completion corre todas las secuencias de comandos de completado en `/etc/bash_completion.d`.
{{< /note >}}
Ambas estrategias son equivalentes. Tras recargar tu intérprete de comandos, el auto-completado de kubectl debería estar funcionando.
{{% /tab %}}
{{% tab name="Bash en macOS" %}}
### Introducción
La secuencia de comandos de completado de kubectl para Bash puede generarse con el comando `kubectl completion bash`. Corriendo la secuencia de comandos de completado en tu intérprete de comandos habilita el auto-completado de kubectl.
Sin embargo, la secuencia de comandos de completado depende de [*bash-completion**](https://github.com/scop/bash-completion), lo que significa que tienes que instalar primero este programa (puedes probar si ya tienes bash-completion instalado ejecutando `type _init_completion`).
{{< warning>}}
macOS incluye Bash 3.2 por defecto. La secuencia de comandos de completado de kubectl requiere Bash 4.1+ y no funciona con Bash 3.2. Una posible alternativa es instalar una nueva versión de Bash en macOS (ver instrucciones [aquí](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). Las instrucciones de abajo sólo funcionan si estás usando Bash 4.1+.
{{< /warning >}}
### Actualizar bash
Las instrucciones asumen que usa Bash 4.1+. Puedes comprobar tu versión de bash con:
```bash
echo $BASH_VERSION
```
Si no es 4.1+, puede actualizar bash con Homebrew:
```bash
brew install bash
```
Recarga tu intérprete de comandos y verifica que estás usando la versión deseada:
```bash
echo $BASH_VERSION $SHELL
```
Usualmente, Homebrew lo instala en `/usr/local/bin/bash`.
### Instalar bash-completion
Puedes instalar bash-completion con Homebrew:
```bash
brew install bash-completion@2
```
{{< note >}}
El `@2` simboliza bash-completion 2, que es requerido por la secuencia de comandos de completado de kubectl (no funciona con bash-completion 1). Luego, bash-completion 2 requiere Bash 4.1+, eso es por lo que necesitabas actualizar Bash.
{{< /note >}}
Como se indicaba en la salida de `brew install` (sección "Caveats"), añade las siguientes líneas a tu `~/.bashrc` o `~/.bash_profile`:
```bash
export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
```
Recarga tu intérprete de comandos y verifica que bash-completion está correctamente instalado tecleando `type _init_completion`.
### Habilitar el auto-completado de kubectl
Debes asegurarte que la secuencia de comandos de completado de kubectl corre en todas tus sesiones de tu intérprete de comenados. Hay múltiples formas en que puedes hacer esto:
- Corre la secuencia de comandos de completado en tu `~/.bashrc`:
```shell
echo 'source <(kubectl completion bash)' >>~/.bashrc
```
- Añade la secuencia de comandos de completado al directorio `/usr/local/etc/bash_completion.d`:
```shell
kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
```
- Si has instalado kubectl con Homebrew (como se explica [aquí](#install-with-homebrew-on-macos)), entonces la secuencia de comandos de completado se instaló automáticamente en `/usr/local/etc/bash_completion.d/kubectl`. En este caso, no tienes que hacer nada.
{{< note >}}
bash-completion (si se instaló con Homebrew) corre todas las secuencias de comandos de completado en el directorio que se ha puesto en la variable de entorno `BASH_COMPLETION_COMPAT_DIR`.
{{< /note >}}
Todas las estrategias son equivalentes. Tras recargar tu intérprete de comandos, el auto-completado de kubectl debería funcionar.
{{% /tab %}}
{{% tab name="Zsh" %}}
La secuencia de comandos de completado de kubectl para Zsh puede ser generada con el comando `kubectl completion zsh`. Corriendo la secuencia de comandos de completado en tu intérprete de comandos habilita el auto-completado de kubectl.
Para hacerlo en todas tus sesiones de tu intérprete de comandos, añade lo siguiente a tu `~/.zshrc`:
```zsh
source <(kubectl completion zsh)
```
Si tienes alias para kubectl, puedes extender el completado de intérprete de comandos para funcionar con ese alias.
```zsh
echo 'alias k=kubectl' >>~/.zshrc
echo 'compdef __start_kubectl k' >>~/.zshrc
```
Tras recargar tu intérprete de comandos, el auto-completado de kubectl debería funcionar.
Si obtienes un error como `complete:13: command not found: compdef`, entonces añade lo siguiente al principio de tu `~/.zshrc`:
```zsh
autoload -Uz compinit
compinit
```
{{% /tab %}}
{{< /tabs >}}
## {{% heading "whatsnext" %}}
* [Instalar Minikube](https://minikube.sigs.k8s.io/docs/start/)
* Ver las [guías](/docs/setup/) para ver mas información sobre como crear clusteres.
* [Aprender cómo lanzar y exponer tu aplicación.](/docs/tasks/access-application-cluster/service-access-application-cluster/).
* Si necesita acceso a un clúster que no se creó, ver el documento de [compartiendo acceso a clúster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
* Leer ´la documentación de kubectl reference](/docs/reference/kubectl/kubectl/)
content/id/docs/tasks/administer-cluster/sysctl-cluster.md
+2 -1
View File
@@ -55,7 +55,8 @@ Sysctl berikut ini didukung dalam kelompok _safe_:
- `kernel.shm_rmid_forced`,
- `net.ipv4.ip_local_port_range`,
- `net.ipv4.tcp_syncookies`,
- `net.ipv4.ping_group_range` (sejak Kubernetes 1.18).
- `net.ipv4.ping_group_range` (sejak Kubernetes 1.18),
- `net.ipv4.ip_unprivileged_port_start` (sejak Kubernetes 1.22).
{{< note >}}
Contoh `net.ipv4.tcp_syncookies` bukan merupakan Namespace pada kernel Linux versi 4.4 atau lebih rendah.
content/id/docs/tasks/manage-kubernetes-objects/kustomization.md
+2 -2
View File
@@ -80,10 +80,10 @@ Isinya seperti di bawah ini:
apiVersion: v1
data:
application.properties: |
FOO=Bar
FOO: Bar
kind: ConfigMap
metadata:
name: example-configmap-1-8mbdf7882g
name: example-configmap-1-42cfbf598f
```
ConfigMap juga dapat dibangkitkan dari pasangan _key-value_ literal. Untuk membangkitkan secara literal, tambahkan entri pada daftar `literals` di `configMapGenerator`.
content/it/docs/concepts/cluster-administration/logging.md
+1 -1
View File
@@ -88,7 +88,7 @@ la rotazione e ci sono due file, uno da 10 MB e uno vuoto,
`kubectl logs` restituirà una risposta vuota.
{{< /note >}}
[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh
### System component logs
content/it/docs/concepts/cluster-administration/manage-deployment.md
+1 -1
View File
@@ -140,7 +140,7 @@ Se sei interessato a saperne di più su `kubectl`, vai avanti e leggi [Panoramic
Gli esempi che abbiamo utilizzato fino ad ora si applicano al massimo una singola etichetta a qualsiasi risorsa. Esistono molti scenari in cui è necessario utilizzare più etichette per distinguere i set l'uno dall'altro.
Ad esempio, diverse applicazioni utilizzerebbero valori diversi per l'etichetta `app`, ma un'applicazione multilivello, come l'esempio [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/), avrebbe inoltre bisogno di distinguere ogni livello. Il frontend potrebbe contenere le seguenti etichette:
Ad esempio, diverse applicazioni utilizzerebbero valori diversi per l'etichetta `app`, ma un'applicazione multilivello, come l'esempio [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/), avrebbe inoltre bisogno di distinguere ogni livello. Il frontend potrebbe contenere le seguenti etichette:
```yaml
labels:
content/pt-br/docs/concepts/cluster-administration/logging.md
+1 -1
View File
@@ -78,7 +78,7 @@ Quando você executa [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-
Atualmente, se algum sistema externo executou a rotação, apenas o conteúdo do arquivo de log mais recente estará disponível através de `kubectl logs`. Por exemplo, se houver um arquivo de 10MB, o `logrotate` executa a rotação e existem dois arquivos, um com 10MB de tamanho e um vazio, o `kubectl logs` retornará uma resposta vazia.
{{< /note >}}
[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh
### Logs de componentes do sistema
content/pt-br/docs/concepts/configuration/overview.md
+1 -1
View File
@@ -70,7 +70,7 @@ combinação de <`hostIP`, `hostPort`, `protocol`> deve ser única. Se você nã
## Usando Labels
- Defina e use [labels](/docs/concepts/overview/working-with-objects/labels/) que identifiquem _atributos semânticos_ da sua aplicação ou Deployment, como `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Você pode usar essas labels para selecionar os Pods apropriados para outros recursos; por exemplo, um Service que seleciona todos os Pods `tier: frontend`, ou todos
os componentes de `app: myapp`. Veja o app [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) para exemplos dessa abordagem.
os componentes de `app: myapp`. Veja o app [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/) para exemplos dessa abordagem.
Um Service pode ser feito para abranger vários Deployments, omitindo labels específicas de lançamento de seu seletor. Quando você
precisar atualizar um serviço em execução sem _downtime_, use um [Deployment](/docs/concepts/workloads/controllers/deployment/).
content/pt-br/docs/concepts/containers/container-environment.md
+1 -1
View File
@@ -42,7 +42,7 @@ FOO_SERVICE_PORT=<a porta em que o serviço está executando>
```
Serviços possuem endereço IP dedicado e são disponibilizados para o contêiner via DNS,
se possuírem [DNS addon](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/) habilitado.
se possuírem [DNS addon](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/) habilitado.
content/pt-br/docs/concepts/overview/working-with-objects/field-selectors.md
+56
View File
@@ -0,0 +1,56 @@
---
title: Seletores de Campos
weight: 60
---
Os _Seletores de Campos_ permitem que você [selecione recursos do Kubernetes](/docs/concepts/overview/working-with-objects/kubernetes-objects) baseado no valor de um ou mais campos de um recurso. Seguem alguns exemplos de buscas utilizando seletores de campos:
* `metadata.name=my-service`
* `metadata.namespace!=default`
* `status.phase=Pending`
O comando `kubectl`, mostrado a seguir, seleciona todos os Pods nos quais o valor do campo [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) é `Running`:
```shell
kubectl get pods --field-selector status.phase=Running
```
{{< note >}}
Seletores de campos são essencialmente *filtros* de recursos. Por padrão, nenhum seletor/filtro é aplicado, de forma que todos os recursos do tipo especificado são selecionados. Isso faz com que as seguintes pesquisas utilizando `kubectl` sejam equivalentes: `kubectl get pods` e `kubectl get pods --field-selector ""`
{{< /note >}}
## Campos suportados
Os campos de seleção suportados variam dependendo do tipo de recurso Kubernetes. Todos os tipos de recursos suportam os campos `metadata.name` e `metadata.namespace`. Utilizar campos não suportados produz um erro. Como por exemplo:
```shell
kubectl get ingress --field-selector foo.bar=baz
```
```
Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace"
```
## Operadores suportados
Você pode utilizar os operadores `=`, `==` e `!=` com seletores de campos (`=` e `==` significam a mesma coisa). Por exemplo, o comando `kubectl` a seguir seleciona todos os Kubernetes Services que não estão no namespace `default`:
```shell
kubectl get services --all-namespaces --field-selector metadata.namespace!=default
```
## Seletores em cadeia
Assim como [label](/docs/concepts/overview/working-with-objects/labels) e outros tipos de seletores, podem ser utilizados em cadeia através de uma lista separada por vírgula. O comando `kubectl` a seguir seleciona todos os Pods nos quais `status.phase` não é igual a `Running` e `spec.restartPolicy` é igual a `Always`
```shell
kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always
```
## Múltiplos tipos de recursos
Você pode utilizar seletores de campos através de múltiplos tipos de recursos. Por exemplo, o comando `kubectl` a seguir seleciona todos Statefulsets e Services que não estão presentes no namespace `default`.
```shell
kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default
```
content/pt-br/docs/reference/access-authn-authz/bootstrap-tokens.md
+1 -1
View File
@@ -57,7 +57,7 @@ do gerenciador de controle - kube-controller-manager.
## Formato do _secret_ dos tokens de inicialização
Cada token válido possui um _secret_ no namespace `kube-system`. Você pode
encontrar a documentação completa [aqui](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).
encontrar a documentação completa [aqui](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).
Um _secret_ de token se parece com o exemplo abaixo:
content/ru/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
+1 -1
View File
@@ -137,7 +137,7 @@ kubelet отправляет запрос HTTP GET на сервер, котор
Любой код, больший или равный 200 и меньший 400, означает успех. Любой другой код интерпретируется как ошибка.
Вы можете посмотреть исходные коды сервера в
[server.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/test/images/agnhost/liveness/server.go).
[server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go).
В течение первых 10 секунд жизни контейнера обработчик `/healthz`
возвращает статус 200. После обработчик возвращает статус 500.
content/uk/docs/tasks/tools/install-minikube.md
+5 -5
View File
@@ -13,7 +13,7 @@ card:
a tool that runs a single-node Kubernetes cluster in a virtual machine on your personal computer.
-->
Ця сторінка описує як встановити [Minikube](/docs/tutorials/hello-minikube), інструмент який дозволяє
Ця сторінка описує, як встановити [Minikube](/docs/tutorials/hello-minikube) - інструмент, який дозволяє
запустити Kubernetes кластер з однієї ноди у віртуальній машині на вашому персональному комп'ютері.
@@ -21,7 +21,7 @@ a tool that runs a single-node Kubernetes cluster in a virtual machine on your p
{{< tabs name="minikube_before_you_begin" >}}
{{% tab name="Linux" %}}
Для перевірки, чи підтримується віртуалізація на Linux, запустіть наступну команду і впевніться що вивід команди не пустий:
Для перевірки, чи підтримується віртуалізація на Linux, запустіть наступну команду і впевніться що її вивід не пустий:
```
grep -E --color 'vmx|svm' /proc/cpuinfo
```
@@ -69,7 +69,7 @@ Hyper-V Requirements: A hypervisor has been detected. Features required for
### Встановлення kubectl
Впевніться що kubectl встановлен. Ви можете встановити kubectl згідно інструкції [Установка та налаштування kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux).
Впевніться що kubectl встановлений. Ви можете встановити kubectl згідно інструкції [Встановлення та налаштування kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux).
### Встановлення Hypervisor
@@ -196,7 +196,7 @@ choco install minikube
### Встановлення Minikube за допомогою програми встановлення
Для установкі Minikube вручну на Windows за допомогою [Windows Installer](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal), скачайте [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe) та виконайте програму.
Для встановлення Minikube вручну на Windows за допомогою [Windows Installer](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal), скачайте [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe) та виконайте програму.
### Встановлення Minikube за допомогою прямого завантаження
@@ -226,7 +226,7 @@ choco install minikube
minikube start --driver=<driver_name>
```
Як тількі `minikube start` закінчився, запустіть команду нижче, щоб перевірити стан кластера:
Після того як `minikube start` закінчився, запустіть команду нижче, щоб перевірити стан кластера:
```shell
minikube status
content/zh/community/_index.html
+239 -112
View File
@@ -5,129 +5,256 @@ cid: community
---
<!--
---
title: Community
layout: basic
cid: community
---
-->
<section id="mainContent">
<main>
<!-- <div class="content">
<h3>Ensuring Kubernetes works well everywhere and for everyone.</h3>
<p>Connect with the Kubernetes community on our <a href="http://slack.k8s.io/">Slack channel</a>, <a href="https://discuss.kubernetes.io/">discussion board</a>, or join the
<a href="https://groups.google.com/forum/#!forum/kubernetes-dev">Kubernetes-dev Google group</a>. A weekly
community meeting takes place via video conference to discuss the state of affairs, see
<a href="https://github.com/kubernetes/community/blob/master/events/community-meeting.md">these instructions</a> for information
on how to participate.</p>
<p>You can also join Kubernetes all around the world through our
<a href="https://www.meetup.com/topics/kubernetes/">Kubernetes Meetup Community</a> and the
<a href="https://www.meetup.com/Kubernetes-Cloud-Native-Online-Meetup/">Kubernetes Cloud Native Meetup Community</a>.</p>
</div> -->
<div class="newcommunitywrapper">
<div class="banner1">
<img src="/images/community/kubernetes-community-final-02.jpg" alt="Kubernetes 会议一览" style="width:100%;padding-left:0px" class="desktop">
<img src="/images/community/kubernetes-community-02-mobile.jpg" alt="Kubernetes 会议一览" style="width:100%;padding-left:0px" class="mobile">
</div>
<div class="content">
<h3>保证 Kubernetes 到处都适用，每个人都喜欢。</h3>
<p>在我们的<a href="http://slack.k8s.io/">Slack channel</a>,
<a href="https://discuss.kubernetes.io/">讨论版</a>, 或者
<a href="https://groups.google.com/forum/#!forum/kubernetes-dev">Kubernetes-dev Google 群主</a>上和 Kubernetes 互动。
同时，每周我们也有社区视频会议，讨论最新进展。参见
<a href="https://github.com/kubernetes/community/blob/master/events/community-meeting.md">这些指导</a>了解如何参与其中。</p>
<p>你也可以在世界各地通过我们的
<a href="https://www.meetup.com/topics/kubernetes/">Kubernetes Meetup 社区</a> 以及
<a href="https://www.meetup.com/Kubernetes-Cloud-Native-Online-Meetup/">Kubernetes Cloud Native Meetup 社区</a>来参与。</p>
<div class="intro">
<br class="mobile">
<!--p>The Kubernetes community -- users, contributors, and the culture we've built together -- is one of the biggest reasons for the meteoric rise of this open source project. Our culture and values continue to grow and change as the project itself grows and changes. We all work together toward constant improvement of the project and the ways we work on it.
<br><br>We are the people who file issues and pull requests, attend SIG meetings, Kubernetes meetups, and KubeCon, advocate for its adoption and innovation, run <code>kubectl get pods</code>, and contribute in a thousand other vital ways. Read on to learn how you can get involved and become part of this amazing community.</p>
-->
<p>
Kubernetes 社区 -- 用户、贡献者以及我们一起塑造的文化 -- 是这个开源项目持续增长的最重要原因。
我们的文化和价值观随着项目自身的成长和变化而成长着、变化着。
我们一起努力地持续改进项目本身，以及我们在这个项目中的工作方式。
<br><br>我们是登记缺陷、提出拉取请求、参加 SIG 会议、Kubernetes Meetup、KubeCon，
为了技术采纳和创新四处宣讲、运行 <code>kubectl get pods</code>
并通过难以计数的其他重要方式作出贡献的一群人。
如果想要了解如何参与进来并成为这一令人赞叹的社区的一员，请继续阅读。</p>
</div>
<div class="community__navbar">
<a href="https://www.kubernetes.dev/"><!--Contributor Community-->贡献者社区</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#values"><!--Community Values-->社区价值观</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#conduct"><!--Code of conduct-->行为规范</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#videos"><!--Videos-->视频</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#discuss"><!--Discussions-->讨论</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#events"><!--Events and meetups-->活动与聚会</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#news"><!--News-->新闻</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="/releases"><!--Releases-->发行版本</a>
</div>
<br class="mobile"><br class="mobile">
<div class="imagecols">
<br class="mobile">
<div class="imagecol">
<img src="/images/community/kubernetes-community-final-03.jpg" alt="Kubernetes 会议一览" style="width:100%" class="desktop">
</div>
<!-- <div class="content">
<h3>Special Interest Groups (SIGs)</h3>
<p>Have a special interest in how Kubernetes works with another technology? See our ever growing
<a href="https://git.k8s.io/community/sig-list.md">lists of SIGs</a>,
from AWS and Openstack to Big Data and Scalability, there's a place for you to contribute and instructions
for forming a new SIG if your special interest isn't covered (yet).</p>
<p>As a member of the Kubernetes community, you are welcome to join any of the SIG meetings
you are interested in. No registration required.</p>
</div> -->
<div class="content">
<h3>特殊兴趣小组 （Special Interest Groups，SIGs）</h3>
<p>对于 Kubernetes 是如何和另外的技术协作感兴趣？了解下我们不停发展的
<a href="https://git.k8s.io/community/sig-list.md">SIGs 群组</a>,
从 AWS 和 Openstack 到 大数据和可扩展性，总会有一个适合你，如果你所关注的不在其列，也有指导帮助你成立新的 SIG。</p>
<p>作为 Kubernetes 社区的一员，你可以随意加入任何你感兴趣的 SIG 会议。不需要额外注册。</p>
<div class="imagecol">
<img src="/images/community/kubernetes-community-final-04.jpg" alt="Kubernetes 会议一览" style="width:100%" class="desktop">
</div>
<!-- <div class="content">
<h3>Code of Conduct</h3>
<p>The Kubernetes community values respect and inclusiveness, and
enforces a <a href="code-of-conduct/">Code of Conduct</a> in all
interactions. If you notice a violation of the Code of Conduct at
an event or meeting, in Slack, or in another communication
mechanism, reach out to the <a href="https://github.com/kubernetes/community/tree/master/committee-code-of-conduct">Kubernetes Code of Conduct Committee</a>
<a href="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>.
Your anonymity will be protected.</p>
</p>
</div> -->
<div class="imagecol" style="margin-right:0% important">
<img src="/images/community/kubernetes-community-final-05.jpg" alt="Kubernetes 会议一览" style="width:100%;margin-right:0% important" class="desktop">
</div>
<img src="/images/community/kubernetes-community-04-mobile.jpg" alt="Kubernetes 会议一览" style="width:100%;margin-bottom:3%" class="mobile">
<a name="values"></a>
</div>
<div class="content">
<h3>行为规范</h3>
<p>Kubernetes 社区重视尊重和包容，并要求在所有场合都遵循
<a href="code-of-conduct/">行为规范</a>。
如果你在活动、会议、Slack 或是其它场合发现有任何违反行为规范的行为，请联系
<a href="https://github.com/kubernetes/community/tree/master/committee-code-of-conduct">Kubernetes 行为规范委员会</a>
<a href="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>.
我们会确保您的匿名性。</p>
<div><a name="values"></a></div>
<div class="conduct">
<div class="conducttext">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<div class="conducttextnobutton" style="margin-bottom:2%"><h1><!--Community Values-->社区价值观</h1>
<!--
The Kubernetes Community values are the keystone to the ongoing success of the project.<br>
These principles guide every aspect of the Kubernetes project.
-->
Kubernetes 社区价值观是项目持续成功的基石。<br>
这些原则会指导 Kubernetes 项目的方方面面。
<br>
<a href="/community/values/">
<br class="mobile"><br class="mobile">
<span class="fullbutton">
<!--READ MORE-->继续阅读
</span>
</a>
</div><a name="conduct"></a>
</div>
</div>
</main>
</section>
<!-- <section id="talkToUs">
<main>
<h3>Talk to Us!</h3>
<h4>We would love to hear from you, how you are using Kubernetes,<br> and what we can do to make it better.</h4>
<div id="bigSocial">
<div>
<a href="https://twitter.com/kubernetesio">@kubernetesio</a>
<p>Get the latest news and updates.</p>
</div>
<div>
<a href="https://github.com/kubernetes/kubernetes">Github Project</a>
<p>Check out the project and consider contributing.</p>
</div>
<div>
<a href="http://slack.k8s.io/">#kubernetes-users</a>
<p>Our Slack channel is the best way to contact our engineers and share your ideas with them.</p>
</div>
<div>
<a href="http://stackoverflow.com/questions/tagged/kubernetes">Stack Overflow</a>
<p>Our user forum is a great place to go for community support.</p>
</div>
</div>
</main>
</section> -->
<section id="talkToUs">
<main>
<h3>与我们联系！</h3>
<h4>我们很希望听到你的声音，你是如何使用 Kubernetes 的，<br>以及我们可以将 Kubernetes 变得更美好。</h4>
<div id="bigSocial">
<div>
<a href="https://twitter.com/kubernetesio">@kubernetesio</a>
<p>获取更多的资讯和更新。</p>
</div>
<div>
<a href="https://github.com/kubernetes/kubernetes">Github 项目</a>
<p>了解项目，作出贡献。</p>
</div>
<div>
<a href="http://slack.k8s.io/">#kubernetes-users</a>
<p>Slack channel 是联系工程师，分享想法的最佳方法。</p>
</div>
<div>
<a href="http://stackoverflow.com/questions/tagged/kubernetes">Stack Overflow</a>
<p>我们的论坛是获得社区支持的最佳地点。</p>
</div>
</div>
</main>
</section>
<div class="conduct">
<div class="conducttext">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<div class="conducttextnobutton" style="margin-bottom:2%"><h1><!--Code of Conduct-->行为规范</h1>
<!--
The Kubernetes community values respect and inclusiveness, and enforces a Code of Conduct in all interactions. If you notice a violation of the Code of Conduct at an event or meeting, in Slack, or in another communication mechanism, reach out to the Kubernetes Code of Conduct Committee at <a href="mailto:conduct@kubernetes.io" style="color:#0662EE;font-weight:300">conduct@kubernetes.io</a>. All reports are kept confidential. You can read about the committee&nbsp;<a href="https://github.com/kubernetes/community/tree/master/committee-code-of-conduct" style="color:#0662EE;font-weight:300">here</a>.
-->
Kubernetes 社区倡导相互尊重和包容，并要求在所有交互中遵从一种行为规范（Code of Conduct）。
如果你在某个活动或会议中、Slack 上或者其他通信机制中观察到违反行为规范的情况，
请通过 <a href="mailto:conduct@kubernetes.io" style="color:#0662EE;font-weight:300">conduct@kubernetes.io</a>
联系 Kubernetes 的行为规范委员会（Kubernetes Code of Conduct Committee）。
所有的违规报告都会被严格保密。你可以在
<a href="https://github.com/kubernetes/community/tree/master/committee-code-of-conduct" style="color:#0662EE;font-weight:300">这里</a>阅读该委员会的信息。
<br>
<a href="https://kubernetes.io/community/code-of-conduct/">
<br class="mobile"><br class="mobile">
<span class="fullbutton">
<!--READ MORE-->继续阅读
</span>
</a>
</div><a name="videos"></a>
</div>
</div>
<div class="videos">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<h1 style="margin-top:0px">Videos</h1>
<div style="margin-bottom:4%;font-weight:300;text-align:center;padding-left:10%;padding-right:10%"><!--We're on YouTube,
a lot. Subscribe for a wide range of&nbsp;topics.-->我们在 YouTube 上有很多视频，你可以订阅很多不同的主题。</div>
<div class="videocontainer">
<div class="video">
<iframe width="100%" height="250"
src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP3azFUvYJjGn45YbF6C-uIg" title="阅读办公时间" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP3azFUvYJjGn45YbF6C-uIg">
<div class="videocta">
观看阅读办公会议&nbsp;&#9654;</div>
</a>
</div>
<div class="video">
<iframe width="100%" height="250"
src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ" title="社区每周例会" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ">
<div class="videocta">
观看社区每周例会&nbsp;&#9654;
</div>
</a>
</div>
<div class="video">
<iframe width="100%" height="250"
src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP3QpQrhZq_sLYo77BVKv09F" title="来自社区成员的演讲" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP3QpQrhZq_sLYo77BVKv09F">
<div class="videocta">
观看来自社区成员的演讲&nbsp;&#9654;
</div>
</a>
<a name="discuss"></a>
</div>
</div>
</div>
<div class="resources">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<h1 style="padding-top:1%"><!--Discussions-->讨论</h1>
<div style="font-weight:300;text-align:center"><!--We talk a lot. Find us and join the conversation on any of
these&nbsp;platforms.-->我们有很多演讲材料。你可以在以下任何平台上找到我们并加入讨论。</div>
<div class="resourcecontainer">
<div class="resourcebox">
<img src="/images/community/discuss.png" alt=Forum" style="width:80%;padding-bottom:2%">
<a href="https://discuss.kubernetes.io/" style="color:#0662EE;display:block;margin-top:1%">
<!--forum-->论坛&nbsp;&#9654;
</a>
<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">
<!--
Topic-based technical discussions that bridge docs, StackOverflow, and so much&nbsp;more
-->
基于主题的技术讨论，包括 docs、StackOverflow 以及很多其他渠道。
</div>
</div>
<div class="resourcebox">
<img src="/images/community/twitter.png" alt="Twitter" style="width:80%;padding-bottom:2%">
<a href="https://twitter.com/kubernetesio" style="color:#0662EE;display:block;margin-top:1%">
Twitter&nbsp;&#9654;
</a>
<div class="resourceboxtext" style="font-size:12px;text-transform:none
!important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%"><!--Real-time announcements of blog posts,
events, news, ideas -->关于博客发表、活动、新闻、想法的实时公布</div>
</div>
<div class="resourcebox">
<img src="/images/community/github.png" alt="GitHub" style="width:80%;padding-bottom:2%">
<a href="https://github.com/kubernetes/kubernetes" style="color:#0662EE;display:block;margin-top:1%">
github&nbsp;&#9654;
</a>
<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">
<!--All the project and issue tracking, plus of course code-->所有的项目和缺陷跟踪，当然也包含代码
</div>
</div>
<div class="resourcebox">
<img src="/images/community/stack.png" alt="Stack Overflow" style="width:80%;padding-bottom:2%">
<a href="https://stackoverflow.com/search?q=kubernetes" style="color:#0662EE;display:block;margin-top:1%">
StackOverflow&nbsp;&#9654;
</a>
<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">
<!--Technical troubleshooting for any use&nbsp;case-->针对不同场景的技术问题排查
<a name="events"></a>
</div>
</div>
</div>
</div>
<div class="events">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<div class="eventcontainer">
<h1 style="color:white !important"><!--Upcoming Events-->未来活动</h1>
{{< upcoming-events >}}
</div>
</div>
<div class="meetups">
<div class="meetupcol">
<div class="meetuptext">
<h1 style="text-align:left"><!--Global Community-->全球社区</h1>
<!--
With over 150 meetups in the world and growing, go find your local kube people. If one isn't near, take charge and create your own.
-->
我们在全球有超过 150 个 Meetup，而且数量仍在增长，你可以去找到本地的 Kubernetes
人员。如果附近没有，你可以负起责来，建一个你自己的 Meetup。
</div>
<a href="https://www.meetup.com/topics/kubernetes/">
<div class="button">
<!--FIND A MEETUP-->寻找 Meetup
</div>
</a>
<a name="news"></a>
</div>
</div>
<div class="news">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<h1 style="margin-bottom:2%"><!--Recent News-->最近新闻</h1>
<br>
<div class="twittercol1">
<a class="twitter-timeline" data-tweet-limit="1" href="https://twitter.com/kubernetesio?ref_src=twsrc%5Etfw"><!--Tweets
by kubernetesio-->kubernetesio 账号的推特</a> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
</div>
<br>
<br><br><br><br>
</div>
</div>
content/zh/docs/concepts/configuration/configmap.md
+21 -4
View File
@@ -104,10 +104,6 @@ definition to create an [immutable ConfigMap](#configmap-immutable).
You can write a Pod `spec` that refers to a ConfigMap and configures the container(s)
in that Pod based on the data in the ConfigMap. The Pod and the ConfigMap must be in
the same {{< glossary_tooltip text="namespace" term_id="namespace" >}}.
Here's an example ConfigMap that has some keys with single values,
and other keys where the value looks like a fragment of a configuration
format.
-->
## ConfigMaps 和 Pods
@@ -115,6 +111,20 @@ format.
在该 Pod 中配置容器。这个 Pod 和 ConfigMap 必须要在同一个
{{< glossary_tooltip text="名字空间" term_id="namespace" >}} 中。
<!--
The `spec` of a {{< glossary_tooltip text="static Pod" term_id="static-pod" >}} cannot refer to a ConfigMap
or any other API objects.
-->
{{< note >}}
{{< glossary_tooltip text="静态 Pod" term_id="static-pod" >}} 中的 `spec`
字段不能引用 ConfigMap 或任何其他 API 对象。
{{< /note >}}
<!--
Here's an example ConfigMap that has some keys with single values,
and other keys where the value looks like a fragment of a configuration
format.
-->
这是一个 ConfigMap 的示例，它的一些键只有一个值，其他键的值看起来像是
配置的片段格式。
@@ -381,6 +391,13 @@ ConfigMaps consumed as environment variables are not updated automatically and r
以环境变量方式使用的 ConfigMap 数据不会被自动更新。
更新这些数据需要重新启动 Pod。
<!--
A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes#using-subpath) volume mount will not receive ConfigMap updates.
-->
{{< note >}}
使用 ConfigMap 作为 [subPath](/zh/docs/concepts/storage/volumes#using-subpath) 卷挂载的容器将不会收到 ConfigMap 的更新。
{{< /note >}}
<!--
## Immutable ConfigMaps {#configmap-immutable}
-->
content/zh/docs/concepts/configuration/overview.md
+16 -65
View File
@@ -19,7 +19,7 @@ This document highlights and consolidates configuration best practices that are
This is a living document. If you think of something that is not on this list but might be useful to others, please don't hesitate to file an issue or submit a PR.
-->
这是一份不断改进的文件。
如果您认为某些内容缺失但可能对其他人有用，请不要犹豫，提交 Issue 或提交 PR。
如果你认为某些内容缺失但可能对其他人有用，请不要犹豫，提交 Issue 或提交 PR。
<!-- body -->
<!--
@@ -36,7 +36,7 @@ This is a living document. If you think of something that is not on this list bu
- Configuration files should be stored in version control before being pushed to the cluster. This allows you to quickly roll back a configuration change if necessary. It also aids cluster re-creation and restoration.
-->
- 在推送到集群之前，配置文件应存储在版本控制中。
这允许您在必要时快速回滚配置更改。
这允许你在必要时快速回滚配置更改。
它还有助于集群重新创建和恢复。
<!--
@@ -45,11 +45,11 @@ This is a living document. If you think of something that is not on this list bu
- 使用 YAML 而不是 JSON 编写配置文件。虽然这些格式几乎可以在所有场景中互换使用，但 YAML 往往更加用户友好。
<!--
- Group related objects into a single file whenever it makes sense. One file is often easier to manage than several. See the [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) file as an example of this syntax.
- Group related objects into a single file whenever it makes sense. One file is often easier to manage than several. See the [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml) file as an example of this syntax.
-->
- 只要有意义，就将相关对象分组到一个文件中。
一个文件通常比几个文件更容易管理。
请参阅[guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) 文件作为此语法的示例。
请参阅 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml) 文件作为此语法的示例。
<!--
- Note also that many `kubectl` commands can be called on a directory. For example, you can call `kubectl apply` on a directory of config files.
@@ -93,7 +93,7 @@ Deployment 既可以创建一个 ReplicaSet 来确保预期个数的 Pod 始终
<!--
## Services
-->
## 服务
## 服务 {#services}
<!--
- Create a [Service](/docs/concepts/services-networking/service/) before its corresponding backend workloads (Deployments or ReplicaSets), and before any workloads that need to access it. When Kubernetes starts a container, it provides environment variables pointing to all the Services which were running when the container was started. For example, if a Service named `foo` exists, all containers will get the following variables in their initial environment:
@@ -128,21 +128,21 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN
- 除非绝对必要，否则不要为 Pod 指定 `hostPort`。
将 Pod 绑定到`hostPort`时，它会限制 Pod 可以调度的位置数，因为每个
`<hostIP, hostPort, protocol>`组合必须是唯一的。
如果您没有明确指定 `hostIP` 和 `protocol`，Kubernetes 将使用 `0.0.0.0` 作为默认
如果你没有明确指定 `hostIP` 和 `protocol`，Kubernetes 将使用 `0.0.0.0` 作为默认
`hostIP` 和 `TCP` 作为默认 `protocol`。
<!--
If you only need access to the port for debugging purposes, you can use the [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) or [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
-->
如果您只需要访问端口以进行调试，则可以使用
如果你只需要访问端口以进行调试，则可以使用
[apiserver proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)或
[`kubectl port-forward`](/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。
<!--
If you explicitly need to expose a Pod's port on the node, consider using a [NodePort](/docs/concepts/services-networking/service/#nodeport) Service before resorting to `hostPort`.
If you explicitly need to expose a Pod's port on the node, consider using a [NodePort](/docs/concepts/services-networking/service/#type-nodeport) Service before resorting to `hostPort`.
-->
如果您明确需要在节点上公开 Pod 的端口，请在使用 `hostPort` 之前考虑使用
[NodePort](/zh/docs/concepts/services-networking/service/#nodeport) 服务。
如果你明确需要在节点上公开 Pod 的端口，请在使用 `hostPort` 之前考虑使用
[NodePort](/zh/docs/concepts/services-networking/service/#type-nodeport) 服务。
<!--
- Avoid using `hostNetwork`, for the same reasons as `hostPort`.
@@ -153,23 +153,23 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN
- Use [headless Services](/docs/concepts/services-networking/service/#headless-
services) (which have a `ClusterIP` of `None`) for service discovery when you don't need `kube-proxy` load balancing.
-->
- 当您不需要 `kube-proxy` 负载均衡时，使用
- 当你不需要 `kube-proxy` 负载均衡时，使用
[无头服务](/zh/docs/concepts/services-networking/service/#headless-services)
(`ClusterIP` 被设置为 `None`)以便于服务发现。
<!--
## Using Labels
-->
## 使用标签
## 使用标签 {#using-labels}
<!--
- Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or Deployment, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the appropriate Pods for other resources; for example, a Service that selects all `tier: frontend` Pods, or all `phase: test` components of `app: myapp`. See the [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) app for examples of this approach.
- Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or Deployment, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the appropriate Pods for other resources; for example, a Service that selects all `tier: frontend` Pods, or all `phase: test` components of `app: myapp`. See the [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/) app for examples of this approach.
-->
- 定义并使用[标签](/zh/docs/concepts/overview/working-with-objects/labels/)来识别应用程序
或 Deployment 的 __语义属性__，例如`{ app: myapp, tier: frontend, phase: test, deployment: v3 }`。
你可以使用这些标签为其他资源选择合适的 Pod；
例如，一个选择所有 `tier: frontend` Pod 的服务，或者 `app: myapp` 的所有 `phase: test` 组件。
有关此方法的示例，请参阅[guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 。
有关此方法的示例，请参阅 [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/) 。
<!--
A Service can be made to span multiple Deployments by omitting release-specific labels from its selector. [Deployments](/docs/concepts/workloads/controllers/deployment/) make it easy to update a running service without downtime.
@@ -195,66 +195,17 @@ Deployment 描述了对象的期望状态，并且如果对该规范的更改被
<!--
- You can manipulate labels for debugging. Because Kubernetes controllers (such as ReplicaSet) and Services match to Pods using selector labels, removing the relevant labels from a Pod will stop it from being considered by a controller or from being served traffic by a Service. If you remove the labels of an existing Pod, its controller will create a new Pod to take its place. This is a useful way to debug a previously "live" Pod in a "quarantine" environment. To interactively remove or add labels, use [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label).
-->
- 您可以操纵标签进行调试。
- 你可以操纵标签进行调试。
由于 Kubernetes 控制器（例如 ReplicaSet）和服务使用选择器标签来匹配 Pod，
从 Pod 中删除相关标签将阻止其被控制器考虑或由服务提供服务流量。
如果删除现有 Pod 的标签，其控制器将创建一个新的 Pod 来取代它。
这是在"隔离"环境中调试先前"活跃"的 Pod 的有用方法。
要以交互方式删除或添加标签，请使用 [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)。
<!--
## Container Images
-->
## 容器镜像
<!--
The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the tag of the image affect when the [kubelet](/docs/reference/command-line-tools-reference/kubelet/) attempts to pull the specified image.
-->
[imagePullPolicy](/zh/docs/concepts/containers/images/#updating-images)和镜像标签会影响
[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 何时尝试拉取指定的镜像。
<!--
- `imagePullPolicy: IfNotPresent`: the image is pulled only if it is not already present locally.
- `imagePullPolicy: Always`: the image is pulled every time the pod is started.
- `imagePullPolicy` is omitted and either the image tag is `:latest` or it is omitted: `imagePullPolicy` is automatically set to `Always`. Note that this will _not_ be updated to `IfNotPresent` if the tag changes value.
- `imagePullPolicy` is omitted and the image tag is present but not `:latest`: `imagePullPolicy` is automatically set to `IfNotPresent`. Note that this will _not_ be updated to `Always` if the tag is later removed or changed to `:latest`.
- `imagePullPolicy: Never`: the image is assumed to exist locally. No attempt is made to pull the image.
-->
- `imagePullPolicy: IfNotPresent`：仅当镜像在本地不存在时才被拉取。
- `imagePullPolicy: Always`：每次启动 Pod 的时候都会拉取镜像。
- `imagePullPolicy` 省略时，镜像标签为 `:latest` 或不存在，其值自动被设置为 `Always`。注意，如果镜像标签的值发生改变，`imagePullPolicy` 的值不会被更新为 `IfNotPresent`。
- `imagePullPolicy` 省略时，指定镜像标签并且不是 `:latest`，其值自动被设置为 `IfNotPresent`。注意，如果镜像标签的值之后被移除或者修改为 `latest`，`imagePullPolicy` 的值不会被更新为 `Always`。
- `imagePullPolicy: Never`：假设镜像已经存在本地，不会尝试拉取镜像。
<!--
To make sure the container always uses the same version of the image, you can specify its [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier), for example `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`. The digest uniquely identifies a specific version of the image, so it is never updated by Kubernetes unless you change the digest value.
-->
{{< note >}}
要确保容器始终使用相同版本的镜像，你可以指定其
[摘要](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)，
例如 `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`。
摘要唯一地标识出镜像的指定版本，因此除非您更改摘要值，否则 Kubernetes 永远不会更新它。
{{< /note >}}
<!--
You should avoid using the `:latest` tag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly.
-->
{{< note >}}
在生产中部署容器时应避免使用 `:latest` 标记，因为这样更难跟踪正在运行的镜像版本，并且更难以正确回滚。
{{< /note >}}
<!--
The caching semantics of the underlying image provider make even `imagePullPolicy: Always` efficient, as long as the registry is reliably accessible. With Docker, for example, if the image already exists, the pull attempt is fast because all image layers are cached and no image download is needed.
-->
{{< note >}}
只要镜像仓库是可访问的，底层镜像驱动程序的缓存语义能够使即便 `imagePullPolicy: Always` 的配置也很高效。
例如，对于 Docker，如果镜像已经存在，则拉取尝试很快，因为镜像层都被缓存并且不需要下载。
{{< /note >}}
<!--
## Using kubectl
-->
## 使用 kubectl
## 使用 kubectl {#using-kubectl}
<!--
- Use `kubectl apply -f <directory>`. This looks for Kubernetes configuration in all `.yaml`, `.yml`, and `.json` files in `<directory>` and passes it to `apply`.
content/zh/docs/concepts/containers/container-lifecycle-hooks.md
+18 -16
View File
@@ -158,7 +158,7 @@ less than the total time (55+10) it takes for these two things to happen.
`PreStop` 回调并不会与停止容器的信号处理程序异步执行；回调必须在
可以发送信号之前完成执行。
如果 `PreStop` 回调在执行期间停滞不前，Pod 的阶段会变成 `Terminating`
并且一致处于该状态，直到其 `terminationGracePeriodSeconds` 耗尽为止，
并且一直处于该状态，直到其 `terminationGracePeriodSeconds` 耗尽为止，
这时 Pod 会被杀死。
这一宽限期是针对 `PreStop` 回调的执行时间及容器正常停止时间的总和而言的。
例如，如果 `terminationGracePeriodSeconds` 是 60，回调函数花了 55 秒钟
@@ -214,30 +214,32 @@ The logs for a Hook handler are not exposed in Pod events.
If a handler fails for some reason, it broadcasts an event.
For `PostStart`, this is the `FailedPostStartHook` event,
and for `PreStop`, this is the `FailedPreStopHook` event.
You can see these events by running `kubectl describe pod <pod_name>`.
Here is some example output of events from running this command:
To generate a failed `FailedPreStopHook` event yourself, modify the [lifecycle-events.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/lifecycle-events.yaml) file to change the postStart command to "badcommand" and apply it.
Here is some example output of the resulting events you see from running `kubectl describe pod lifecycle-demo`:
-->
### 调试回调处理程序
回调处理程序的日志不会在 Pod 事件中公开。
如果处理程序由于某种原因失败，它将播放一个事件。
对于 `PostStart`，这是 `FailedPostStartHook` 事件，对于 `PreStop`，这是 `FailedPreStopHook` 事件。
您可以通过运行 `kubectl describe pod <pod_name>` 命令来查看这些事件。
下面是运行这个命令的一些事件输出示例:
要自己生成失败的 `FailedPreStopHook` 事件，请修改
[lifecycle-events.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/lifecycle-events.yaml)
文件将 postStart 命令更改为 ”badcommand“ 并应用它。
以下是通过运行 `kubectl describe pod lifecycle-demo` 后你看到的一些结果事件的示例输出：
```
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567
38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 7s default-scheduler Successfully assigned default/lifecycle-demo to ip-XXX-XXX-XX-XX.us-east-2...
Normal Pulled 6s kubelet Successfully pulled image "nginx" in 229.604315ms
Normal Pulling 4s (x2 over 6s) kubelet Pulling image "nginx"
Normal Created 4s (x2 over 5s) kubelet Created container lifecycle-demo-container
Normal Started 4s (x2 over 5s) kubelet Started container lifecycle-demo-container
Warning FailedPostStartHook 4s (x2 over 5s) kubelet Exec lifecycle hook ([badcommand]) for Container "lifecycle-demo-container" in Pod "lifecycle-demo_default(30229739-9651-4e5a-9a32-a8f1688862db)" failed - error: command 'badcommand' exited with 126: , message: "OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: \"badcommand\": executable file not found in $PATH: unknown\r\n"
Normal Killing 4s (x2 over 5s) kubelet FailedPostStartHook
Normal Pulled 4s kubelet Successfully pulled image "nginx" in 215.66395ms
Warning BackOff 2s (x2 over 3s) kubelet Back-off restarting failed container
```
## {{% heading "whatsnext" %}}
content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md
+4 -4
View File
@@ -625,13 +625,13 @@ In a three node cluster, a web application has in-memory cache such as redis. We
##### 始终放置在相同节点上
在三节点集群中，一个 web 应用程序具有内存缓存，例如 redis。
我们希望 web 服务器尽可能与缓存放置在同一位置。
我们希望 web 服务器与缓存尽可能放置在同一节点上。
<!--
Here is the yaml snippet of a simple redis deployment with three replicas and selector label `app=store`. The deployment has `PodAntiAffinity` configured to ensure the scheduler does not co-locate replicas on a single node.
-->
下面是一个简单 redis Deployment 的 YAML 代码段，它有三个副本和选择器标签 `app=store`。
Deployment 配置了 `PodAntiAffinity`，用来确保调度器不会将副本调度到单个节点上。
Deployment 配置了 `PodAntiAffinity`，用来确保调度器不会将所有副本调度到同一节点上。
```yaml
apiVersion: apps/v1
@@ -667,8 +667,8 @@ spec:
The below yaml snippet of the webserver deployment has `podAntiAffinity` and `podAffinity` configured. This informs the scheduler that all its replicas are to be co-located with pods that have selector label `app=store`. This will also ensure that each web-server replica does not co-locate on a single node.
-->
下面 webserver Deployment 的 YAML 代码段中配置了 `podAntiAffinity` 和 `podAffinity`。
这将通知调度器将它的所有副本与具有 `app=store` 选择器标签的 Pod 放置在一起。
这还确保每个 web 服务器副本不会调度到单个节点上。
这将通知调度器将 web-server 的所有副本与具有 `app=store` 选择器标签的 Pod 放置在一起。
同时这还确保了不会有两个 web 服务器的副本被调度到同一节点上。
```yaml
apiVersion: apps/v1
content/zh/docs/reference/access-authn-authz/authentication.md
+399 -79
View File
@@ -96,16 +96,15 @@ API 请求则或者与某普通用户相关联，或者与某服务账号相关
<!--
## Authentication strategies
Kubernetes uses client certificates, bearer tokens, an authenticating proxy, or HTTP basic auth to
Kubernetes uses client certificates, bearer tokens, or an authenticating proxy to
authenticate API requests through authentication plugins. As HTTP requests are
made to the API server, plugins attempt to associate the following attributes
with the request:
-->
## 身份认证策略 {#authentication-strategies}
Kubernetes 使用身份认证插件利用客户端证书、持有者令牌（Bearer Token）、身份认证代理（Proxy）
或者 HTTP 基本认证机制来认证 API 请求的身份。HTTP 请求发给 API 服务器时，
插件会将以下属性关联到请求本身：
Kubernetes 通过身份认证插件利用客户端证书、持有者令牌（Bearer Token）或身份认证代理（Proxy）
来认证 API 请求的身份。HTTP 请求发给 API 服务器时，插件会将以下属性关联到请求本身：
<!--
* Username: a string which identifies the end user. Common values might be `kube-admin` or `jane@example.com`.
@@ -126,8 +125,8 @@ when interpreted by an [authorizer](/docs/reference/access-authn-authz/authoriza
You can enable multiple authentication methods at once. You should usually use at least two methods:
- service account tokens for service accounts
- at least one other method for user authentication.
- service account tokens for service accounts
- at least one other method for user authentication.
-->
所有（属性）值对于身份认证系统而言都是不透明的，只有被
[鉴权组件](/zh/docs/reference/access-authn-authz/authorization/)
@@ -189,18 +188,18 @@ openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app
<!--
This would create a CSR for the username "jbeda", belonging to two groups, "app1" and "app2".
See [Managing Certificates](/docs/concepts/cluster-administration/certificates/) for how to generate a client cert.
See [Managing Certificates](/docs/tasks/administer-cluster/certificates/) for how to generate a client cert.
-->
此命令将使用用户名 `jbeda` 生成一个证书签名请求（CSR），且该用户属于 "app" 和
"app2" 两个用户组。
参阅[管理证书](/zh/docs/concepts/cluster-administration/certificates/)了解如何生成客户端证书。
参阅[管理证书](/zh/docs/tasks/administer-cluster/certificates/)了解如何生成客户端证书。
<!--
### Static Token File
The API server reads bearer tokens from a file when given the `-token-auth-file=SOMEFILE` option on the command line. Currently, tokens last indefinitely, and the token list cannot be
changed without restarting API server.
changed without restarting the API server.
The token file is a csv file with a minimum of 3 columns: token, user name, user uid,
followed by optional group names.
@@ -382,9 +381,9 @@ spec:
<!--
Service account bearer tokens are perfectly valid to use outside the cluster and
can be used to create identities for long standing jobs that wish to talk to the
Kubernetes API. To manually create a service account, simply use the `kubectl
create serviceaccount (NAME)` command. This creates a service account in the
current namespace and an associated secret.
Kubernetes API. To manually create a service account, use the `kubectl create
serviceaccount (NAME)` command. This creates a service account in the current
namespace and an associated secret.
-->
在集群外部使用服务账号持有者令牌也是完全合法的，且可用来为长时间运行的、需要与
Kubernetes API 服务器通信的任务创建标识。要手动创建服务账号，可以使用
@@ -568,25 +567,23 @@ sequenceDiagram
<!--
Since all of the data needed to validate who you are is in the `id_token`, Kubernetes doesn't need to
"phone home" to the identity provider. In a model where every request is stateless this provides a very scalable
solution for authentication. It does offer a few challenges:
"phone home" to the identity provider. In a model where every request is stateless this provides a very scalable solution for authentication. It does offer a few challenges:
-->
由于用来验证你是谁的所有数据都在 `id_token` 中，Kubernetes 不需要再去联系
身份服务。在一个所有请求都是无状态请求的模型中，这一工作方式可以使得身份认证
的解决方案更容易处理大规模请求。不过，此访问也有一些挑战：
由于用来验证你是谁的所有数据都在 `id_token` 中，Kubernetes 不需要再去联系身份服务。
在一个所有请求都是无状态请求的模型中，这一工作方式可以使得身份认证的解决方案更容易处理大规模请求。
不过，此访问也有一些挑战：
<!--
1. Kubernetes has no "web interface" to trigger the authentication process. There is no browser or interface to collect credentials which is why you need to authenticate to your identity provider first.
2. The `id_token` can't be revoked, it's like a certificate so it should be short-lived (only a few minutes) so it can be very annoying to have to get a new token every few minutes.
3. There's no easy way to authenticate to the Kubernetes dashboard without using the `kubectl proxy` command or a reverse proxy that injects the `id_token`.
3. To authenticate to the Kubernetes dashboard, you must use the `kubectl proxy` command or a reverse proxy that injects the `id_token`.
-->
1. Kubernetes 没有提供用来触发身份认证过程的 "Web 界面"。
因为不存在用来收集用户凭据的浏览器或用户接口，你必须自己先行完成
对身份服务的认证过程。
因为不存在用来收集用户凭据的浏览器或用户接口，你必须自己先行完成对身份服务的认证过程。
2. `id_token` 令牌不可收回。因其属性类似于证书，其生命期一般很短（只有几分钟），
所以，每隔几分钟就要获得一个新的令牌这件事可能很让人头疼。
3. 如果不使用 `kubectl proxy` 命令或者一个能够注入 `id_token` 的反向代理，
向 Kubernetes 控制面板执行身份认证是很困难的。
3. 如果需要向 Kubernetes 控制面板执行身份认证，你必须使用 `kubectl proxy`
命令或者一个能够注入 `id_token` 的反向代理。
<!--
#### Configuring the API Server
@@ -643,7 +640,7 @@ You can use an existing public OpenID Connect Identity Provider (such as Google,
Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex),
[Keycloak](https://github.com/keycloak/keycloak),
CloudFoundry [UAA](https://github.com/cloudfoundry/uaa), or
Tremolo Security's [OpenUnison](https://github.com/tremolosecurity/openunison).
Tremolo Security's [OpenUnison](https://openunison.github.io/).
-->
Kubernetes 并未提供 OpenID Connect 的身份服务。
你可以使用现有的公共的 OpenID Connect 身份服务（例如 Google 或者
@@ -652,8 +649,7 @@ Kubernetes 并未提供 OpenID Connect 的身份服务。
CoreOS [dex](https://github.com/coreos/dex)、
[Keycloak](https://github.com/keycloak/keycloak)、
CloudFoundry [UAA](https://github.com/cloudfoundry/uaa) 或者
Tremolo Security 的
[OpenUnison](https://github.com/tremolosecurity/openunison)。
Tremolo Security 的 [OpenUnison](https://openunison.github.io/)。
<!--
For an identity provider to work with Kubernetes it must:
@@ -765,13 +761,13 @@ users:
Once your `id_token` expires, `kubectl` will attempt to refresh your `id_token` using your `refresh_token` and `client_secret` storing the new values for the `refresh_token` and `id_token` in your `.kube/config`.
-->
当你的 `id_token` 过期时，`kubectl` 会尝试使用你的 `refresh_token` 来刷新你的
`id_token`，并且在 `client_secret` 中存放 `refresh_token` 的新值，同时把
`id_token` 的新值写入到 `.kube/config` 文件中。
`id_token`，并且在 `.kube/config` 文件的 `client_secret` 中存放 `refresh_token`
和 `id_token` 的新值。
<!--
##### Option 2 - Use the `--token` Option
The `kubectl` command lets you pass in a token using the `--token` option. Simply copy and paste the `id_token` into this option:
The `kubectl` command lets you pass in a token using the `--token` option. Copy and paste the `id_token` into this option:
-->
##### 选项二 - 使用 `--token` 选项
@@ -819,7 +815,7 @@ clusters:
- name: name-of-remote-authn-service
cluster:
certificate-authority: /path/to/ca.pem # CA for verifying the remote service.
server: https://authn.example.com/authenticate # URL of remote service to query. Must use 'https'.
server: https://authn.example.com/authenticate # URL of remote service to query. 'https' recommended for production.
# users refers to the API server's webhook configuration.
users:
@@ -847,7 +843,7 @@ clusters:
- name: name-of-remote-authn-service
cluster:
certificate-authority: /path/to/ca.pem # 用来验证远程服务的 CA
server: https://authn.example.com/authenticate # 要查询的远程服务 URL。必须使用 'https'。
server: https://authn.example.com/authenticate # 要查询的远程服务 URL。生产环境中建议使用 'https'。
# users 指代 API 服务的 Webhook 配置
users:
@@ -1148,8 +1144,9 @@ to the impersonated user info.
The following HTTP headers can be used to performing an impersonation request:
* `Impersonate-User`: The username to act as.
* `Impersonate-Group`: A group name to act as. Can be provided multiple times to set multiple groups. Optional. Requires "Impersonate-User"
* `Impersonate-Group`: A group name to act as. Can be provided multiple times to set multiple groups. Optional. Requires "Impersonate-User".
* `Impersonate-Extra-( extra name )`: A dynamic header used to associate extra fields with the user. Optional. Requires "Impersonate-User". In order to be preserved consistently, `( extra name )` should be lower-case, and any characters which aren't [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6) MUST be utf8 and [percent-encoded](https://tools.ietf.org/html/rfc3986#section-2.1).
* `Impersonate-Uid`: A unique identifier that represents the user being impersonated. Optional. Requires "Impersonate-User". Kubernetes does not impose any format requirements on this string.
-->
以下 HTTP 头部字段可用来执行伪装请求：
@@ -1161,6 +1158,9 @@ The following HTTP headers can be used to performing an impersonation request:
`<附加名称>`部分必须是小写字符，如果有任何字符不是
[合法的 HTTP 头部标签字符](https://tools.ietf.org/html/rfc7230#section-3.2.6)，
则必须是 utf8 字符，且转换为[百分号编码](https://tools.ietf.org/html/rfc3986#section-2.1)。
* `Impersonate-Uid`：一个唯一标识符，用来表示所伪装的用户。此头部可选。
如果设置，则要求 "Impersonate-User" 也存在。
Kubernetes 对此字符串没有格式要求。
<!--
Prior to 1.11.3 (and 1.10.7, 1.9.11), `( extra name )` could only contain characters which were [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6).
@@ -1170,10 +1170,29 @@ Prior to 1.11.3 (and 1.10.7, 1.9.11), `( extra name )` could only contain charac
合法的 HTTP 标签字符。
{{< /note >}}
{{< note >}}
<!--
An example set of headers:
`Impersonate-Uid` is only available in versions 1.22.0 and higher.
-->
头部字段集合的示例：
`Impersonate-Uid` 仅在 1.22.0 及更高版本中可用。
{{< /note >}}
<!--
An example of the impersonation headers used when impersonating a user with groups:
-->
伪装带有用户组的用户时，所使用的伪装头部字段示例：
```http
Impersonate-User: jane.doe@example.com
Impersonate-Group: developers
Impersonate-Group: admins
```
<!--
An example of the impersonation headers used when impersonating a user with a UID and
extra fields:
-->
伪装带有 UID 和附加字段的用户时，所使用的伪装头部字段示例：
```http
Impersonate-User: jane.doe@example.com
@@ -1214,17 +1233,24 @@ node/mynode cordoned
node/mynode drained
```
{{< note >}}
<!--
To impersonate a user, group, or set extra fields, the impersonating user must
`kubectl` cannot impersonate extra fields or UIDs.
-->
`kubectl` 不能对附加字段或 UID 执行伪装。
{{< /note >}}
<!--
To impersonate a user, group, user identifier (UID) or extra fields, the impersonating user must
have the ability to perform the "impersonate" verb on the kind of attribute
being impersonated ("user", "group", etc.). For clusters that enable the RBAC
being impersonated ("user", "group", "uid", etc.). For clusters that enable the RBAC
authorization plugin, the following ClusterRole encompasses the rules needed to
set user and group impersonation headers:
-->
要伪装成某个用户、某个组或者设置附加字段，执行伪装操作的用户必须具有对所伪装的
类别（“user”、“group” 等）执行 “impersonate” 动词操作的能力。
对于启用了 RBAC 鉴权插件的集群，下面的 ClusterRole 封装了设置用户和组伪装字段
所需的规则：
若要伪装成某个用户、某个组、用户标识符（UID））或者设置附加字段，
执行伪装操作的用户必须具有对所伪装的类别（“user”、“group”、“uid” 等）执行 “impersonate”
动词操作的能力。
对于启用了 RBAC 鉴权插件的集群，下面的 ClusterRole 封装了设置用户和组伪装字段所需的规则：
```yaml
apiVersion: rbac.authorization.k8s.io/v1
@@ -1238,22 +1264,24 @@ rules:
```
<!--
For impersonation, extra fields and impersonated UIDs are both under the "authentication.k8s.io" `apiGroup`.
Extra fields are evaluated as sub-resources of the resource "userextras". To
allow a user to use impersonation headers for the extra field "scopes", a user
should be granted the following role:
allow a user to use impersonation headers for the extra field "scopes" and
for UIDs, a user should be granted the following role:
-->
为了执行伪装，附加字段和所伪装的 UID 都位于 "authorization.k8s.io" `apiGroup` 中。
附加字段会被作为 `userextras` 资源的子资源来执行权限评估。
如果要允许用户为附加字段 “scopes” 设置伪装头部，该用户需要被授予以下规则：
如果要允许用户为附加字段 “scopes” 和 UID 设置伪装头部，该用户需要被授予以下角色：
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: scopes-impersonator
name: scopes-and-uid-impersonator
rules:
# 可以设置 "Impersonate-Extra-scopes" 头部
# 可以设置 "Impersonate-Extra-scopes" 和 "Impersonate-Uid" 头部
- apiGroups: ["authentication.k8s.io"]
resources: ["userextras/scopes"]
resources: ["userextras/scopes", "uids"]
verbs: ["impersonate"]
```
@@ -1286,6 +1314,12 @@ rules:
resources: ["userextras/scopes"]
verbs: ["impersonate"]
resourceNames: ["view", "development"]
# 可以伪装 UID "06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b"
- apiGroups: ["authentication.k8s.io"]
resources: ["uids"]
verbs: ["impersonate"]
resourceNames: ["06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b"]
```
<!--
@@ -1293,7 +1327,7 @@ rules:
-->
## client-go 凭据插件 {#client-go-credential-plugins}
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
{{< feature-state for_k8s_version="v1.22" state="stable" >}}
<!--
`k8s.io/client-go` and tools using it such as `kubectl` and `kubelet` are able to execute an
@@ -1359,6 +1393,9 @@ as part of the user fields.
凭据插件通过 [kubectl 配置文件](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
来作为 user 字段的一部分设置。
{{< tabs name="exec_plugin_kubeconfig_example_1" >}}
{{% tab name="client.authentication.k8s.io/v1" %}}
<!--
```yaml
apiVersion: v1
@@ -1375,8 +1412,9 @@ users:
# The API version returned by the plugin MUST match the version listed here.
#
# To integrate with tools that support multiple versions (such as client.authentication.k8s.io/v1alpha1),
# set an environment variable or pass an argument to the tool that indicates which version the exec plugin expects.
apiVersion: "client.authentication.k8s.io/v1beta1"
# set an environment variable, pass an argument to the tool that indicates which version the exec plugin expects,
# or read the version from the ExecCredential object in the KUBERNETES_EXEC_INFO environment variable.
apiVersion: "client.authentication.k8s.io/v1"
# Environment variables to set when executing the plugin. Optional.
env:
@@ -1405,6 +1443,13 @@ users:
# very large CA data, to this exec plugin as a part of the KUBERNETES_EXEC_INFO
# environment variable.
provideClusterInfo: true
# The contract between the exec plugin and the standard input I/O stream. If the
# contract cannot be satisfied, this plugin will not be run and an error will be
# returned. Valid values are "Never" (this exec plugin never uses standard input),
# "IfAvailable" (this exec plugin wants to use standard input if it is available),
# or "Always" (this exec plugin requires standard input to function). Required.
interactiveMode: Never
clusters:
- name: my-cluster
cluster:
@@ -1439,8 +1484,9 @@ users:
# 插件返回的 API 版本必需与这里列出的版本匹配。
#
# 要与支持多个版本的工具（如 client.authentication.k8sio/v1alpha1）集成，
# 可以设置一个环境变量或者向工具传递一个参数标明 exec 插件所期望的版本。
apiVersion: "client.authentication.k8s.io/v1beta1"
# 可以设置一个环境变量或者向工具传递一个参数标明 exec 插件所期望的版本，
# 或者从 KUBERNETES_EXEC_INFO 环境变量的 ExecCredential 对象中读取版本信息。
apiVersion: "client.authentication.k8s.io/v1"
# 执行此插件时要设置的环境变量。可选字段。
env:
@@ -1467,6 +1513,157 @@ users:
# 是否使用 KUBERNETES_EXEC_INFO 环境变量的一部分向这个 exec 插件
# 提供集群信息（可能包含非常大的 CA 数据）
provideClusterInfo: true
# Exec 插件与标准输入 I/O 数据流之间的协议。如果协议无法满足，
# 则插件无法运行并会返回错误信息。合法的值包括 "Never" （Exec 插件从不使用标准输入），
# "IfAvailable" （Exec 插件希望在可以的情况下使用标准输入），
# 或者 "Always" （Exec 插件需要使用标准输入才能工作）。必需字段。
interactiveMode: Never
clusters:
- name: my-cluster
cluster:
server: "https://172.17.4.100:6443"
certificate-authority: "/etc/kubernetes/ca.pem"
extensions:
- name: client.authentication.k8s.io/exec # 为每个集群 exec 配置保留的扩展名
extension:
arbitrary: config
this: 在设置 provideClusterInfo 时可通过环境变量 KUBERNETES_EXEC_INFO 指定
you: ["can", "put", "anything", "here"]
contexts:
- name: my-cluster
context:
cluster: my-cluster
user: my-user
current-context: my-cluster
```
{{% /tab %}}
{{% tab name="client.authentication.k8s.io/v1beta1" %}}
<!--
```yaml
apiVersion: v1
kind: Config
users:
- name: my-user
user:
exec:
# Command to execute. Required.
command: "example-client-go-exec-plugin"
# API version to use when decoding the ExecCredentials resource. Required.
#
# The API version returned by the plugin MUST match the version listed here.
#
# To integrate with tools that support multiple versions (such as client.authentication.k8s.io/v1alpha1),
# set an environment variable, pass an argument to the tool that indicates which version the exec plugin expects,
# or read the version from the ExecCredential object in the KUBERNETES_EXEC_INFO environment variable.
apiVersion: "client.authentication.k8s.io/v1beta1"
# Environment variables to set when executing the plugin. Optional.
env:
- name: "FOO"
value: "bar"
# Arguments to pass when executing the plugin. Optional.
args:
- "arg1"
- "arg2"
# Text shown to the user when the executable doesn't seem to be present. Optional.
installHint: |
example-client-go-exec-plugin is required to authenticate
to the current cluster. It can be installed:
On macOS: brew install example-client-go-exec-plugin
On Ubuntu: apt-get install example-client-go-exec-plugin
On Fedora: dnf install example-client-go-exec-plugin
...
# Whether or not to provide cluster information, which could potentially contain
# very large CA data, to this exec plugin as a part of the KUBERNETES_EXEC_INFO
# environment variable.
provideClusterInfo: true
# The contract between the exec plugin and the standard input I/O stream. If the
# contract cannot be satisfied, this plugin will not be run and an error will be
# returned. Valid values are "Never" (this exec plugin never uses standard input),
# "IfAvailable" (this exec plugin wants to use standard input if it is available),
# or "Always" (this exec plugin requires standard input to function). Optional.
# Defaults to "IfAvailable".
interactiveMode: Never
clusters:
- name: my-cluster
cluster:
server: "https://172.17.4.100:6443"
certificate-authority: "/etc/kubernetes/ca.pem"
extensions:
- name: client.authentication.k8s.io/exec # reserved extension name for per cluster exec config
extension:
arbitrary: config
this: can be provided via the KUBERNETES_EXEC_INFO environment variable upon setting provideClusterInfo
you: ["can", "put", "anything", "here"]
contexts:
- name: my-cluster
context:
cluster: my-cluster
user: my-user
current-context: my-cluster
```
-->
```yaml
apiVersion: v1
kind: Config
users:
- name: my-user
user:
exec:
# 要执行的命令。必需。
command: "example-client-go-exec-plugin"
# 解析 ExecCredentials 资源时使用的 API 版本。必需。
#
# 插件返回的 API 版本必需与这里列出的版本匹配。
#
# 要与支持多个版本的工具（如 client.authentication.k8sio/v1alpha1）集成，
# 可以设置一个环境变量或者向工具传递一个参数标明 exec 插件所期望的版本，
# 或者从 KUBERNETES_EXEC_INFO 环境变量的 ExecCredential 对象中读取版本信息。
apiVersion: "client.authentication.k8s.io/v1"
# 执行此插件时要设置的环境变量。可选字段。
env:
- name: "FOO"
value: "bar"
# 执行插件时要传递的参数。可选字段。
args:
- "arg1"
- "arg2"
# 当可执行文件不存在时显示给用户的文本。可选的。
installHint: |
需要 example-client-go-exec-plugin 来在当前集群上执行身份认证。可以通过以下命令安装：
MacOS: brew install example-client-go-exec-plugin
Ubuntu: apt-get install example-client-go-exec-plugin
Fedora: dnf install example-client-go-exec-plugin
...
# 是否使用 KUBERNETES_EXEC_INFO 环境变量的一部分向这个 exec 插件
# 提供集群信息（可能包含非常大的 CA 数据）
provideClusterInfo: true
# Exec 插件与标准输入 I/O 数据流之间的协议。如果协议无法满足，
# 则插件无法运行并会返回错误信息。合法的值包括 "Never" （Exec 插件从不使用标准输入），
# "IfAvailable" （Exec 插件希望在可以的情况下使用标准输入），
# 或者 "Always" （Exec 插件需要使用标准输入才能工作）。可选字段。
# 默认值为 "IfAvailable"。
interactiveMode: Never
clusters:
- name: my-cluster
cluster:
@@ -1486,6 +1683,9 @@ contexts:
current-context: my-cluster
```
{{% /tab %}}
{{< /tabs >}}
<!--
Relative command paths are interpreted as relative to the directory of the config file. If
KUBECONFIG is set to `/home/jane/kubeconfig` and the exec command is `./bin/example-client-go-exec-plugin`,
@@ -1502,7 +1702,8 @@ the binary `/home/jane/bin/example-client-go-exec-plugin` is executed.
exec:
# 对 kubeconfig 目录而言的相对路径
command: "./bin/example-client-go-exec-plugin"
apiVersion: "client.authentication.k8s.io/v1beta1"
apiVersion: "client.authentication.k8s.io/v1"
interactiveMode: Never
```
<!--
@@ -1510,26 +1711,77 @@ the binary `/home/jane/bin/example-client-go-exec-plugin` is executed.
The executed command prints an `ExecCredential` object to `stdout`. `k8s.io/client-go`
authenticates against the Kubernetes API using the returned credentials in the `status`.
When run from an interactive session, `stdin` is exposed directly to the plugin. Plugins should use a
[TTY check](https://godoc.org/golang.org/x/crypto/ssh/terminal#IsTerminal) to determine if it's
appropriate to prompt a user interactively.
To use bearer token credentials, the plugin returns a token in the status of the `ExecCredential`.
The executed command is passed an `ExecCredential` object as input via the `KUBERNETES_EXEC_INFO`
environment variable. This input contains helpful information like the expected API version
of the returned `ExecCredential` object and whether or not the plugin can use `stdin` to interact
with the user.
-->
### 输出和输出格式 {#input-and-output-formats}
所执行的命令会在 `stdout` 打印 `ExecCredential` 对象。
`k8s.io/client-go` 使用 `status` 中返回的凭据信息向 Kubernetes API 服务器
执行身份认证。
`k8s.io/client-go` 使用 `status` 中返回的凭据信息向 Kubernetes API 服务器执行身份认证。
所执行的命令会通过环境变量 `KUBERNETES_EXEC_INFO` 收到一个 `ExecCredential` 对象作为其输入。
此输入中包含类似于所返回的 `ExecCredential` 对象的预期 API 版本，
以及是否插件可以使用 `stdin` 与用户交互这类信息。
在交互式会话中运行时，`stdin` 是直接暴露给插件使用的。
插件应该使用
[TTY check](https://godoc.org/golang.org/x/crypto/ssh/terminal#IsTerminal)
来确定是否适合用交互方式请求用户输入。
<!--
When run from an interactive session (i.e., a terminal), `stdin` can be exposed directly
to the plugin. Plugins should use the `spec.interactive` field of the input
`ExecCredential` object from the `KUBERNETES_EXEC_INFO` environment variable in order to
determine if `stdin` has been provided. A plugin's `stdin` requirements (i.e., whether
`stdin` is optional, strictly required, or never used in order for the plugin
to run successfully) is declared via the `user.exec.interactiveMode` field in the
[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) (see table
below for valid values). The `user.exec.interactiveMode` field is optional in `client.authentication.k8s.io/v1beta1`
and required in `client.authentication.k8s.io/v1`.
-->
与使用持有者令牌凭据，插件在 `ExecCredential` 的状态中返回一个令牌：
在交互式会话（即，某终端）中运行时，`stdin` 是直接暴露给插件使用的。
插件应该使用来自 `KUBERNETES_EXEC_INFO` 环境变量的 `ExecCredential`
输入对象中的 `spec.interactive` 字段来确定是否提供了 `stdin`。
插件的 `stdin` 需求（即，为了能够让插件成功运行，是否 `stdin` 是可选的、
必须提供的或者从不会被使用的）是通过
[kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
中的 `user.exec.interactiveMode` 来声明的（参见下面的表格了解合法值）。
字段 `user.exec.interactiveMode` 在 `client.authentication.k8s.io/v1beta1`
中是可选的，在 `client.authentication.k8s.io/v1` 中是必需的。
<!--
| `interactiveMode` Value | Meaning |
| ----------------------- | ------- |
| `Never` | This exec plugin never needs to use standard input, and therefore the exec plugin will be run regardless of whether standard input is available for user input. |
| `IfAvailable` | This exec plugin would like to use standard input if it is available, but can still operate if standard input is not available. Therefore, the exec plugin will be run regardless of whether stdin is available for user input. If standard input is available for user input, then it will be provided to this exec plugin. |
| `Always` | This exec plugin requires standard input in order to run, and therefore the exec plugin will only be run if standard input is available for user input. If standard input is not available for user input, then the exec plugin will not be run and an error will be returned by the exec plugin runner. |
-->
{{< table caption="interactiveMode 取值" >}}
| `interactiveMode` 取值 | 含义 |
| ----------------------- | ------- |
| `Never` | 此 exec 插件从不需要使用标准输入，因此如论是否有标准输入提供给用户输入，该 exec 插件都能运行。 |
| `IfAvailable` | 此 exec 插件希望在标准输入可用的情况下使用标准输入，但在标准输入不存在时也可运行。因此，无论是否存在给用户提供输入的标准输入，此 exec 插件都会运行。如果存在供用户输入的标准输入，则该标准输入会被提供给 exec 插件。 |
| `Always` | 此 exec 插件需要标准输入才能正常运行，因此只有存在供用户输入的标准输入时，此 exec 插件才会运行。如果不存在供用户输入的标准输入，则 exec 插件无法运行，并且 exec 插件的执行者会因此返回错误信息。 |
{{< /table >}}
<!--
To use bearer token credentials, the plugin returns a token in the status of the
[`ExecCredential`](/docs/reference/config-api/client-authentication.v1beta1/#client-authentication-k8s-io-v1beta1-ExecCredential)
-->
与使用持有者令牌凭据，插件在 [`ExecCredential`](/zh/docs/reference/config-api/client-authentication.v1beta1/#client-authentication-k8s-io-v1beta1-ExecCredential)
的状态中返回一个令牌：
{{< tabs name="exec_plugin_ExecCredential_example_1" >}}
{{% tab name="client.authentication.k8s.io/v1" %}}
```json
{
"apiVersion": "client.authentication.k8s.io/v1",
"kind": "ExecCredential",
"status": {
"token": "my-bearer-token"
}
}
```
{{% /tab %}}
{{% tab name="client.authentication.k8s.io/v1beta1" %}}
```json
{
"apiVersion": "client.authentication.k8s.io/v1beta1",
@@ -1539,6 +1791,8 @@ To use bearer token credentials, the plugin returns a token in the status of the
}
}
```
{{% /tab %}}
{{< /tabs >}}
<!--
Alternatively, a PEM-encoded client certificate and key can be returned to use TLS client auth.
@@ -1558,6 +1812,20 @@ If specified, `clientKeyData` and `clientCertificateData` must both must be pres
`clientCertificateData` 字段可能包含一些要发送给服务器的中间证书（Intermediate
Certificates）。
{{< tabs name="exec_plugin_ExecCredential_example_2" >}}
{{% tab name="client.authentication.k8s.io/v1" %}}
```json
{
"apiVersion": "client.authentication.k8s.io/v1",
"kind": "ExecCredential",
"status": {
"clientCertificateData": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
"clientKeyData": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----"
}
}
```
{{% /tab %}}
{{% tab name="client.authentication.k8s.io/v1beta1" %}}
```json
{
"apiVersion": "client.authentication.k8s.io/v1beta1",
@@ -1568,6 +1836,8 @@ Certificates）。
}
}
```
{{% /tab %}}
{{< /tabs >}}
<!--
Optionally, the response can include the expiry of the credential formatted as a
@@ -1587,6 +1857,20 @@ RFC3339 timestamp. Presence or absence of an expiry has the following impact:
- 如果未指定到期时间，则持有者令牌和 TLS 凭据会被缓存，直到服务器返回 401
HTTP 状态码或者进程退出。
{{< tabs name="exec_plugin_ExecCredential_example_3" >}}
{{% tab name="client.authentication.k8s.io/v1" %}}
```json
{
"apiVersion": "client.authentication.k8s.io/v1",
"kind": "ExecCredential",
"status": {
"token": "my-bearer-token",
"expirationTimestamp": "2018-03-05T17:30:20-08:00"
}
}
```
{{% /tab %}}
{{% tab name="client.authentication.k8s.io/v1beta1" %}}
```json
{
"apiVersion": "client.authentication.k8s.io/v1beta1",
@@ -1597,23 +1881,46 @@ RFC3339 timestamp. Presence or absence of an expiry has the following impact:
}
}
```
{{% /tab %}}
{{< /tabs >}}
<!--
The plugin can optionally be called with an environment variable, `KUBERNETES_EXEC_INFO`,
that contains information about the cluster for which this plugin is obtaining
credentials. This information can be used to perform cluster-specific credential
acquisition logic. In order to enable this behavior, the `provideClusterInfo` field must
be set on the exec user field in the
[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Here is an
example of the aforementioned `KUBERNETES_EXEC_INFO` environment variable.
To enable the exec plugin to obtain cluster-specific information, set `provideClusterInfo` on the `user.exec`
field in the [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/).
The plugin will then be supplied this cluster-specific information in the `KUBERNETES_EXEC_INFO` environment variable.
Information from this environment variable can be used to perform cluster-specific
credential acquisition logic.
The following `ExecCredential` manifest describes a cluster information sample.
-->
为了让 exec 插件能够获得特定与集群的信息，可以在
[kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
中的 `user.exec` 设置 `provideClusterInfo`。
这一特定于集群的信息就会通过 `KUBERNETES_EXEC_INFO` 环境变量传递给插件。
此环境变量中的信息可以用来执行特定于集群的凭据获取逻辑。
下面的 `ExecCredential` 清单描述的是一个示例集群信息。
调用此插件时可以选择性地设置环境变量 `KUBERNETES_EXEC_INFO`。
该变量包含了此插件获取凭据所针对的集群信息。此信息可用于执行群集特定的凭据获取逻辑。
为了启用此行为，必须在 [kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
中的 exec user 字段上设置`provideClusterInfo`字段。
下面是上述 `KUBERNETES_EXEC_INFO` 环境变量的示例。
{{< tabs name="exec_plugin_ExecCredential_example_4" >}}
{{% tab name="client.authentication.k8s.io/v1" %}}
```json
{
"apiVersion": "client.authentication.k8s.io/v1",
"kind": "ExecCredential",
"spec": {
"cluster": {
"server": "https://172.17.4.100:6443",
"certificate-authority-data": "LS0t...",
"config": {
"arbitrary": "config",
"this": "可以在设置 provideClusterInfo 时通过 KUBERNETES_EXEC_INFO 环境变量提供",
"you": ["can", "put", "anything", "here"]
}
},
"interactive": true
}
}
```
{{% /tab %}}
{{% tab name="client.authentication.k8s.io/v1beta1" %}}
```json
{
"apiVersion": "client.authentication.k8s.io/v1beta1",
@@ -1624,10 +1931,23 @@ example of the aforementioned `KUBERNETES_EXEC_INFO` environment variable.
"certificate-authority-data": "LS0t...",
"config": {
"arbitrary": "config",
"this": "在设置 provideClusterInfo 时可通过环境变量 KUBERNETES_EXEC_INFO 指定",
"this": "可以在设置 provideClusterInfo 时通过 KUBERNETES_EXEC_INFO 环境变量提供",
"you": ["can", "put", "anything", "here"]
}
}
},
"interactive": true
}
}
```
{{% /tab %}}
{{< /tabs >}}
## {{% heading "whatsnext" %}}
<!--
* Read the [client authentication reference (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/)
* Read the [client authentication reference (v1)](/docs/reference/config-api/client-authentication.v1/)
-->
* 阅读[客户端认证参考文档 (v1beta1)](/zh/docs/reference/config-api/client-authentication.v1beta1/)
* 阅读[客户端认证参考文档 (v1)](/zh/docs/reference/config-api/client-authentication.v1/)
content/zh/docs/reference/access-authn-authz/rbac.md
+1 -1
View File
@@ -559,7 +559,7 @@ Allow reading `"pods"` resources in the core
-->
#### Role 示例 {#role-examples}
以下示例均为从 Role 或 CLusterRole 对象中截取出来，我们仅展示其 `rules` 部分。
以下示例均为从 Role 或 ClusterRole 对象中截取出来，我们仅展示其 `rules` 部分。
允许读取在核心 {{< glossary_tooltip text="API 组" term_id="api-group" >}}下的
`"Pods"`：
content/zh/docs/reference/config-api/kube-proxy-config.v1alpha1.md
+477 -254
View File
File diff suppressed because it is too large Load Diff
content/zh/docs/reference/using-api/client-libraries.md
+2 -1
View File
@@ -121,7 +121,7 @@ their authors, not the Kubernetes team.
| Scala | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) |
-->
| 语言 | 客户端库 |
| -------------------- | ---------------------------------------- |
|----------------------| ---------------------------------------- |
| Clojure | [github.com/yanatan16/clj-kubernetes-api](https://github.com/yanatan16/clj-kubernetes-api) |
| DotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) |
| DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) |
@@ -143,6 +143,7 @@ their authors, not the Kubernetes team.
| PHP | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) |
| PHP | [github.com/renoki-co/php-k8s](https://github.com/renoki-co/php-k8s) |
| Python | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) |
| Python | [github.com/gtsystem/lightkube](https://github.com/gtsystem/lightkube) |
| Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
| Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) |
| Python | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) |
content/zh/docs/reference/using-api/deprecation-guide.md
+743
View File
@@ -0,0 +1,743 @@
---
title: 已弃用 API 的迁移指南
weight: 45
content_type: reference
---
<!--
reviewers:
- liggitt
- lavalamp
- thockin
- smarterclayton
title: "Deprecated API Migration Guide"
weight: 45
content_type: reference
-->
<!-- overview -->
<!--
As the Kubernetes API evolves, APIs are periodically reorganized or upgraded.
When APIs evolve, the old API is deprecated and eventually removed.
This page contains information you need to know when migrating from
deprecated API versions to newer and more stable API versions.
-->
随着 Kubernetes API 的演化，APIs 会周期性地被重组或升级。
当 APIs 演化时，老的 API 会被弃用并被最终删除。
本页面包含你在将已弃用 API 版本迁移到新的更稳定的 API 版本时需要了解的知识。
<!-- body -->
<!--
## Removed APIs by release
-->
## 各发行版本中移除的 API {#removed-apis-by-release}
### v1.26
<!--
The **v1.26** release will stop serving the following deprecated API versions:
-->
**v1.26** 发行版本中将去除以下已弃用的 API 版本：
<!--
#### Flow control resources {#flowcontrol-resources-v126}
-->
#### 流控制资源 {#flowcontrol-resources-v126}
<!--
The **flowcontrol.apiserver.k8s.io/v1beta1** API version of FlowSchema and PriorityLevelConfiguration will no longer be served in v1.26.
* Migrate manifests and API clients to use the **flowcontrol.apiserver.k8s.io/v1beta2** API version, available since v1.23.
* All existing persisted objects are accessible via the new API
* No notable changes
-->
**flowcontrol.apiserver.k8s.io/v1beta1** API 版本的 FlowSchema
和 PriorityLevelConfiguration 将不会在 v1.26 中提供。
* 迁移清单和 API 客户端使用 **flowcontrol.apiserver.k8s.io/v1beta2** API 版本，
此 API 从 v1.23 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
* 没有需要额外注意的变更
#### HorizontalPodAutoscaler {#horizontalpodautoscaler-v126}
<!--
The **autoscaling/v2beta2** API version of HorizontalPodAutoscaler will no longer be served in v1.26.
* Migrate manifests and API clients to use the **autoscaling/v2** API version, available since v1.23.
* All existing persisted objects are accessible via the new API
-->
**autoscaling/v2beta2** API 版本的 HorizontalPodAutoscaler 将不会在
v1.26 版本中提供。
* 迁移清单和 API 客户端使用 **autoscaling/v2** API 版本，
此 API 从 v1.23 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
### v1.25
<!--
The **v1.25** release will stop serving the following deprecated API versions:
-->
**v1.25** 发行版本将停止提供以下已废弃 API 版本：
#### CronJob {#cronjob-v125}
<!--
The **batch/v1beta1** API version of CronJob will no longer be served in v1.25.
* Migrate manifests and API clients to use the **batch/v1** API version, available since v1.21.
* All existing persisted objects are accessible via the new API
* No notable changes
-->
**batch/v1beta1** API 版本的 CronJob 将不会在 v1.25 版本中继续提供。
* 迁移清单和 API 客户端使用 **batch/v1** API 版本，此 API 从 v1.21 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
* 没有需要额外注意的变更
#### EndpointSlice {#endpointslice-v125}
<!--
The **discovery.k8s.io/v1beta1** API version of EndpointSlice will no longer be served in v1.25.
* Migrate manifests and API clients to use the **discovery.k8s.io/v1** API version, available since v1.21.
* All existing persisted objects are accessible via the new API
* Notable changes in **discovery.k8s.io/v1**:
* use per Endpoint `nodeName` field instead of deprecated `topology["kubernetes.io/hostname"]` field
* use per Endpoint `zone` field instead of deprecated `topology["topology.kubernetes.io/zone"]` field
* `topology` is replaced with the `deprecatedTopology` field which is not writable in v1
-->
**discovery.k8s.io/v1beta1** API 版本的 EndpointSlice 将不会在 v1.25 版本中继续提供。
* 迁移清单和 API 客户端使用 **discovery.k8s.io/v1** API 版本，此 API 从 v1.21 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
* **discovery.k8s.io/v1** 中值得注意的变更有：
* 使用每个 Endpoint 的 `nodeName` 字段而不是已被弃用的
`topology["kubernetes.io/hostname"]` 字段；
* 使用每个 Endpoint 的 `zone` 字段而不是已被弃用的
`topology["kubernetes.io/zone"]` 字段；
* `topology` 字段被替换为 `deprecatedTopology`，并且在 v1 版本中不可写入。
#### Event {#event-v125}
<!--
The **events.k8s.io/v1beta1** API version of Event will no longer be served in v1.25.
* Migrate manifests and API clients to use the **events.k8s.io/v1** API version, available since v1.19.
* All existing persisted objects are accessible via the new API
-->
**events.k8s.io/v1beta1** API 版本的 Event 将不会在 v1.25 版本中继续提供。
* 迁移清单和 API 客户端使用 **events.k8s.io/v1** API 版本，此 API 从 v1.19 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
<!--
* Notable changes in **events.k8s.io/v1**:
* `type` is limited to `Normal` and `Warning`
* `involvedObject` is renamed to `regarding`
* `action`, `reason`, `reportingController`, and `reportingInstance` are required when creating new **events.k8s.io/v1** Events
* use `eventTime` instead of the deprecated `firstTimestamp` field (which is renamed to `deprecatedFirstTimestamp` and not permitted in new **events.k8s.io/v1** Events)
* use `series.lastObservedTime` instead of the deprecated `lastTimestamp` field (which is renamed to `deprecatedLastTimestamp` and not permitted in new **events.k8s.io/v1** Events)
* use `series.count` instead of the deprecated `count` field (which is renamed to `deprecatedCount` and not permitted in new **events.k8s.io/v1** Events)
* use `reportingController` instead of the deprecated `source.component` field (which is renamed to `deprecatedSource.component` and not permitted in new **events.k8s.io/v1** Events)
* use `reportingInstance` instead of the deprecated `source.host` field (which is renamed to `deprecatedSource.host` and not permitted in new **events.k8s.io/v1** Events)
-->
* **events.k8s.io/v1** 中值得注意的变更有：
* `type` 字段只能设置为 `Normal` 和 `Warning` 之一；
* `involvedObject` 字段被更名为 `regarding`；
* `action`、`reason`、`reportingController` 和 `reportingInstance` 字段
在创建新的 **events.k8s.io/v1** 版本 Event 时都是必需的字段；
* 使用 `eventTime` 而不是已被弃用的 `firstTimestamp` 字段
（该字段已被更名为 `deprecatedFirstTimestamp`，且不允许出现在新的 **events.k8s.io/v1** Event 对象中）；
* 使用 `series.lastObservedTime` 而不是已被弃用的 `lastTimestamp` 字段
（该字段已被更名为 `deprecatedLastTimestamp`，且不允许出现在新的 **events.k8s.io/v1** Event 对象中）；
* 使用 `series.count` 而不是已被弃用的 `count` 字段
（该字段已被更名为 `deprecatedCount`，且不允许出现在新的 **events.k8s.io/v1** Event 对象中）；
* 使用 `reportingController` 而不是已被弃用的 `source.component` 字段
（该字段已被更名为 `deprecatedSource.component`，且不允许出现在新的 **events.k8s.io/v1** Event 对象中）；
* 使用 `reportingInstance` 而不是已被弃用的 `source.host` 字段
（该字段已被更名为 `deprecatedSource.host`，且不允许出现在新的 **events.k8s.io/v1** Event 对象中）。
#### HorizontalPodAutoscaler {#horizontalpodautoscaler-v125}
<!--
The **autoscaling/v2beta1** API version of HorizontalPodAutoscaler will no longer be served in v1.25.
* Migrate manifests and API clients to use the **autoscaling/v2** API version, available since v1.23.
* All existing persisted objects are accessible via the new API
-->
**autoscaling/v2beta1** API 版本的 HorizontalPodAutoscaler 将不会在 v1.25 版本中继续提供。
* 迁移清单和 API 客户端使用 **autoscaling/v2** API 版本，此 API 从 v1.23 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
#### PodDisruptionBudget {#poddisruptionbudget-v125}
<!--
The **policy/v1beta1** API version of PodDisruptionBudget will no longer be served in v1.25.
* Migrate manifests and API clients to use the **policy/v1** API version, available since v1.21.
* All existing persisted objects are accessible via the new API
* Notable changes in **policy/v1**:
* an empty `spec.selector` (`{}`) written to a `policy/v1` PodDisruptionBudget selects all pods in the namespace (in `policy/v1beta1` an empty `spec.selector` selected no pods). An unset `spec.selector` selects no pods in either API version.
-->
**policy/v1beta1** API 版本的 PodDisruptionBudget 将不会在 v1.25 版本中继续提供。
* 迁移清单和 API 客户端使用 **policy/v1** API 版本，此 API 从 v1.21 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
* **policy/v1** 中需要额外注意的变更有：
* 在 `policy/v1` 版本的 PodDisruptionBudget 中将 `spec.selector`
设置为空（`{}`）时会选择名字空间中的所有 Pods（在 `policy/v1beta1`
版本中，空的 `spec.selector` 不会选择任何 Pods）。如果 `spec.selector`
未设置，则在两个 API 版本下都不会选择任何 Pods。
#### PodSecurityPolicy {#psp-v125}
<!--
PodSecurityPolicy in the **policy/v1beta1** API version will no longer be served in v1.25, and the PodSecurityPolicy admission controller will be removed.
PodSecurityPolicy replacements are still under discussion, but current use can be migrated to
[3rd-party admission webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/) now.
-->
**policy/v1beta1** API 版本中的 PodSecurityPolicy 将不会在 v1.25 中提供，
并且 PodSecurityPolicy 准入控制器也会被删除。
PodSecurityPolicy 的替换方案仍在讨论过程中，不过当前的用法可以迁移到
[第三方准入性质的 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)。
#### RuntimeClass {#runtimeclass-v125}
<!--
RuntimeClass in the **node.k8s.io/v1beta1** API version will no longer be served in v1.25.
* Migrate manifests and API clients to use the **node.k8s.io/v1** API version, available since v1.20.
* All existing persisted objects are accessible via the new API
* No notable changes
-->
**node.k8s.io/v1beta1** API 版本中的 RuntimeClass 将不会在 v1.25 中提供。
* 迁移清单和 API 客户端使用 **node.k8s.io/v1** API 版本，此 API 从 v1.20 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
* 没有需要额外注意的变更
### v1.22
<!--
The **v1.22** release stopped serving the following deprecated API versions:
-->
**v1.22** 发行版本停止提供以下已废弃 API 版本：
<!--
#### Webhook resources {#webhook-resources-v122}
-->
#### Webhook 资源 {#webhook-resources-v122}
<!--
The **admissionregistration.k8s.io/v1beta1** API version of MutatingWebhookConfiguration and ValidatingWebhookConfiguration is no longer served as of v1.22.
-->
**admissionregistration.k8s.io/v1beta1** API 版本的 MutatingWebhookConfiguration
和 ValidatingWebhookConfiguration 不在 v1.22 版本中继续提供。
<!--
* Migrate manifests and API clients to use the **admissionregistration.k8s.io/v1** API version, available since v1.16.
* All existing persisted objects are accessible via the new APIs
-->
* 迁移清单和 API 客户端使用 **admissionregistration.k8s.io/v1** API 版本，
此 API 从 v1.16 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
<!--
* Notable changes:
* `webhooks[*].failurePolicy` default changed from `Ignore` to `Fail` for v1
* `webhooks[*].matchPolicy` default changed from `Exact` to `Equivalent` for v1
* `webhooks[*].timeoutSeconds` default changed from `30s` to `10s` for v1
* `webhooks[*].sideEffects` default value is removed, and the field made required, and only `None` and `NoneOnDryRun` are permitted for v1
* `webhooks[*].admissionReviewVersions` default value is removed and the field made required for v1 (supported versions for AdmissionReview are `v1` and `v1beta1`)
* `webhooks[*].name` must be unique in the list for objects created via `admissionregistration.k8s.io/v1`
-->
* 值得注意的变更：
* `webhooks[*].failurePolicy` 在 v1 版本中默认值从 `Ignore` 改为 `Fail`
* `webhooks[*].matchPolicy` 在 v1 版本中默认值从 `Exact` 改为 `Equivalent`
* `webhooks[*].timeoutSeconds` 在 v1 版本中默认值从 `30s` 改为 `10s`
* `webhooks[*].sideEffects` 的默认值被删除，并且该字段变为必须指定；
在 v1 版本中可选的值只能是 `None` 和 `NoneOnDryRun` 之一
* `webhooks[*].admissionReviewVersions` 的默认值被删除，在 v1
版本中此字段变为必须指定（AdmissionReview 的被支持版本包括 `v1` 和 `v1beta1`）
* `webhooks[*].name` 必须在通过 `admissionregistration.k8s.io/v1`
创建的对象列表中唯一
#### CustomResourceDefinition {#customresourcedefinition-v122}
<!--
The **apiextensions.k8s.io/v1beta1** API version of CustomResourceDefinition is no longer served as of v1.22.
* Migrate manifests and API clients to use the **apiextensions.k8s.io/v1** API version, available since v1.16.
* All existing persisted objects are accessible via the new API
-->
**apiextensions.k8s.io/v1beta1** API 版本的 CustomResourceDefinition
不在 v1.22 版本中继续提供。
* 迁移清单和 API 客户端使用 **apiextensions/v1** API 版本，此 API 从 v1.16 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
<!--
* Notable changes:
* `spec.scope` is no longer defaulted to `Namespaced` and must be explicitly specified
* `spec.version` is removed in v1; use `spec.versions` instead
* `spec.validation` is removed in v1; use `spec.versions[*].schema` instead
* `spec.subresources` is removed in v1; use `spec.versions[*].subresources` instead
* `spec.additionalPrinterColumns` is removed in v1; use `spec.versions[*].additionalPrinterColumns` instead
* `spec.conversion.webhookClientConfig` is moved to `spec.conversion.webhook.clientConfig` in v1
-->
* 值得注意的变更：
* `spec.scope` 的默认值不再是 `Namespaced`，该字段必须显式指定
* `spec.version` 在 v1 版本中被删除；应改用 `spec.versions`
* `spec.validation` 在 v1 版本中被删除；应改用 `spec.versions[*].schema`
* `spec.subresources` 在 v1 版本中被删除；应改用 `spec.versions[*].subresources`
* `spec.additionalPrinterColumns` 在 v1 版本中被删除；应改用
`spec.versions[*].additionalPrinterColumns`
* `spec.conversion.webhookClientConfig` 在 v1 版本中被移动到
`spec.conversion.webhook.clientConfig` 中
<!--
* `spec.conversion.conversionReviewVersions` is moved to `spec.conversion.webhook.conversionReviewVersions` in v1
* `spec.versions[*].schema.openAPIV3Schema` is now required when creating v1 CustomResourceDefinition objects, and must be a [structural schema](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema)
* `spec.preserveUnknownFields: true` is disallowed when creating v1 CustomResourceDefinition objects; it must be specified within schema definitions as `x-kubernetes-preserve-unknown-fields: true`
* In `additionalPrinterColumns` items, the `JSONPath` field was renamed to `jsonPath` in v1 (fixes [#66531](https://github.com/kubernetes/kubernetes/issues/66531))
-->
* `spec.conversion.conversionReviewVersions` 在 v1 版本中被移动到
`spec.conversion.webhook.conversionReviewVersions`
* `spec.versions[*].schema.openAPIV3Schema` 在创建 v1 版本的
CustomResourceDefinition 对象时变成必需字段，并且其取值必须是一个
[结构化的 Schema](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema)
* `spec.preserveUnknownFields: true` 在创建 v1 版本的 CustomResourceDefinition
对象时不允许指定；该配置必须在 Schema 定义中使用
`x-kubernetes-preserve-unknown-fields: true` 来设置
* 在 v1 版本中，`additionalPrinterColumns` 的条目中的 `JSONPath` 字段被更名为
`jsonPath`（补丁 [#66531](https://github.com/kubernetes/kubernetes/issues/66531)）
#### APIService {#apiservice-v122}
<!--
The **apiregistration.k8s.io/v1beta1** API version of APIService is no longer served as of v1.22.
* Migrate manifests and API clients to use the **apiregistration.k8s.io/v1** API version, available since v1.10.
* All existing persisted objects are accessible via the new API
* No notable changes
-->
**apiregistration/v1beta1** API 版本的 APIService 不在 v1.22 版本中继续提供。
* 迁移清单和 API 客户端使用 **apiregistration.k8s.io/v1** API 版本，此 API 从
v1.10 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
* 没有需要额外注意的变更
#### TokenReview {#tokenreview-v122}
<!--
The **authentication.k8s.io/v1beta1** API version of TokenReview is no longer served as of v1.22.
* Migrate manifests and API clients to use the **authentication.k8s.io/v1** API version, available since v1.6.
* No notable changes
-->
**authentication.k8s.io/v1beta1** API 版本的 TokenReview 不在 v1.22 版本中继续提供。
* 迁移清单和 API 客户端使用 **authentication.k8s.io/v1** API 版本，此 API 从
v1.6 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
* 没有需要额外注意的变更
#### SubjectAccessReview resources {#subjectaccessreview-resources-v122}
<!--
The **authorization.k8s.io/v1beta1** API version of LocalSubjectAccessReview, SelfSubjectAccessReview, and SubjectAccessReview is no longer served as of v1.22.
* Migrate manifests and API clients to use the **authorization.k8s.io/v1** API version, available since v1.6.
* Notable changes:
* `spec.group` was renamed to `spec.groups` in v1 (fixes [#32709](https://github.com/kubernetes/kubernetes/issues/32709))
-->
**authorization.k8s.io/v1beta1** API 版本的 LocalSubjectAccessReview、
SelfSubjectAccessReview、SubjectAccessReview 不在 v1.22 版本中继续提供。
* 迁移清单和 API 客户端使用 **authorization.k8s.io/v1** API 版本，此 API 从
v1.6 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
* 需要额外注意的变更：
* `spec.group` 在 v1 版本中被更名为 `spec.groups`
（补丁 [#32709](https://github.com/kubernetes/kubernetes/issues/32709)）
#### CertificateSigningRequest {#certificatesigningrequest-v122}
<!--
The **certificates.k8s.io/v1beta1** API version of CertificateSigningRequest is no longer served as of v1.22.
* Migrate manifests and API clients to use the **certificates.k8s.io/v1** API version, available since v1.19.
* All existing persisted objects are accessible via the new API
-->
**certificates.k8s.io/v1beta1** API 版本的 CertificateSigningRequest 不在
v1.22 版本中继续提供。
* 迁移清单和 API 客户端使用 **certificates.k8s.io/v1** API 版本，此 API 从
v1.19 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
<!--
* Notable changes in `certificates.k8s.io/v1`:
* For API clients requesting certificates:
* `spec.signerName` is now required (see [known Kubernetes signers](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers)), and requests for `kubernetes.io/legacy-unknown` are not allowed to be created via the `certificates.k8s.io/v1` API
* `spec.usages` is now required, may not contain duplicate values, and must only contain known usages
* For API clients approving or signing certificates:
* `status.conditions` may not contain duplicate types
* `status.conditions[*].status` is now required
* `status.certificate` must be PEM-encoded, and contain only `CERTIFICATE` blocks
-->
* `certificates.k8s.io/v1` 中需要额外注意的变更：
* 对于请求证书的 API 客户端而言：
* `spec.signerName` 现在变成必需字段（参阅
[已知的 Kubernetes 签署者](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers)），
并且通过 `certificates.k8s.io/v1` API 不可以创建签署者为
`kubernetes.io/legacy-unknown` 的请求
* `spec.usages` 现在变成必需字段，其中不可以包含重复的字符串值，
并且只能包含已知的用法字符串
* 对于要批准或者签署证书的 API 客户端而言：
* `status.conditions` 中不可以包含重复的类型
* `status.conditions[*].status` 字段现在变为必需字段
* `status.certificate` 必须是 PEM 编码的，而且其中只能包含 `CERTIFICATE`
数据块
#### Lease {#lease-v122}
<!--
The **coordination.k8s.io/v1beta1** API version of Lease is no longer served as of v1.22.
* Migrate manifests and API clients to use the **coordination.k8s.io/v1** API version, available since v1.14.
* All existing persisted objects are accessible via the new API
* No notable changes
-->
**coordination.k8s.io/v1beta1** API 版本的 Lease 不在 v1.22 版本中继续提供。
* 迁移清单和 API 客户端使用 **coordination.k8s.io/v1** API 版本，此 API 从
v1.14 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
* 没有需要额外注意的变更
#### Ingress {#ingress-v122}
<!--
The **extensions/v1beta1** and **networking.k8s.io/v1beta1** API versions of Ingress is no longer served as of v1.22.
* Migrate manifests and API clients to use the **networking.k8s.io/v1** API version, available since v1.19.
* All existing persisted objects are accessible via the new API
-->
**extensions/v1beta1** 和 **networking.k8s.io/v1beta1** API 版本的 Ingress
不在 v1.22 版本中继续提供。
* 迁移清单和 API 客户端使用 **networking.k8s.io/v1** API 版本，此 API 从
v1.19 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
<!--
* Notable changes:
* `spec.backend` is renamed to `spec.defaultBackend`
* The backend `serviceName` field is renamed to `service.name`
* Numeric backend `servicePort` fields are renamed to `service.port.number`
* String backend `servicePort` fields are renamed to `service.port.name`
* `pathType` is now required for each specified path. Options are `Prefix`, `Exact`, and `ImplementationSpecific`. To match the undefined `v1beta1` behavior, use `ImplementationSpecific`.
-->
* 值得注意的变更：
* `spec.backend` 字段被更名为 `spec.defaultBackend`
* 后端的 `serviceName` 字段被更名为 `service.name`
* 数值表示的后端 `servicePort` 字段被更名为 `service.port.number`
* 字符串表示的后端 `servicePort` 字段被更名为 `service.port.name`
* 对所有要指定的路径，`pathType` 都成为必需字段。
可选项为 `Prefix`、`Exact` 和 `ImplementationSpecific`。
要匹配 `v1beta1` 版本中未定义路径类型时的行为，可使用 `ImplementationSpecific`
#### IngressClass {#ingressclass-v122}
<!--
The **networking.k8s.io/v1beta1** API version of IngressClass is no longer served as of v1.22.
* Migrate manifests and API clients to use the **networking.k8s.io/v1** API version, available since v1.19.
* All existing persisted objects are accessible via the new API
* No notable changes
-->
**networking.k8s.io/v1beta1** API 版本的 IngressClass 不在 v1.22 版本中继续提供。
* 迁移清单和 API 客户端使用 **networking.k8s.io/v1** API 版本，此 API 从
v1.19 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
* 没有需要额外注意的变更
<!--
#### RBAC resources {#rbac-resources-v122}
The **rbac.authorization.k8s.io/v1beta1** API version of ClusterRole, ClusterRoleBinding, Role, and RoleBinding is no longer served as of v1.22.
* Migrate manifests and API clients to use the **rbac.authorization.k8s.io/v1** API version, available since v1.8.
* All existing persisted objects are accessible via the new APIs
* No notable changes
-->
#### RBAC 资源 {#rbac-resources-v122}
**rbac.authorization.k8s.io/v1beta1** API 版本的 ClusterRole、ClusterRoleBinding、
Role 和 RoleBinding 不在 v1.22 版本中继续提供。
* 迁移清单和 API 客户端使用 **rbac.authorization.k8s.io/v1** API 版本，此 API 从
v1.8 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
* 没有需要额外注意的变更
#### PriorityClass {#priorityclass-v122}
<!--
The **scheduling.k8s.io/v1beta1** API version of PriorityClass is no longer served as of v1.22.
* Migrate manifests and API clients to use the **scheduling.k8s.io/v1** API version, available since v1.14.
* All existing persisted objects are accessible via the new API
* No notable changes
-->
**scheduling.k8s.io/v1beta1** API 版本的 PriorityClass 不在 v1.22 版本中继续提供。
* 迁移清单和 API 客户端使用 **scheduling.k8s.io/v1** API 版本，此 API 从
v1.14 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
* 没有需要额外注意的变更
<!--
#### Storage resources {#storage-resources-v122}
-->
#### 存储资源 {#storage-resources-v122}
<!--
The **storage.k8s.io/v1beta1** API version of CSIDriver, CSINode, StorageClass, and VolumeAttachment is no longer served as of v1.22.
* Migrate manifests and API clients to use the **storage.k8s.io/v1** API version
* CSIDriver is available in **storage.k8s.io/v1** since v1.19.
* CSINode is available in **storage.k8s.io/v1** since v1.17
* StorageClass is available in **storage.k8s.io/v1** since v1.6
* VolumeAttachment is available in **storage.k8s.io/v1** v1.13
* All existing persisted objects are accessible via the new APIs
* No notable changes
-->
**storage.k8s.io/v1beta1** API 版本的 CSIDriver、CSINode、StorageClass
和 VolumeAttachment 不在 v1.22 版本中继续提供。
* 迁移清单和 API 客户端使用 **storage.k8s.io/v1** API 版本
* CSIDriver 从 v1.19 版本开始在 **storage.k8s.io/v1** 中提供；
* CSINode 从 v1.17 版本开始在 **storage.k8s.io/v1** 中提供；
* StorageClass 从 v1.6 版本开始在 **storage.k8s.io/v1** 中提供；
* VolumeAttachment 从 v1.13 版本开始在 **storage.k8s.io/v1** 中提供；
* 所有的已保存的对象都可以通过新的 API 来访问；
* 没有需要额外注意的变更
### v1.16
<!--
The **v1.16** release stopped serving the following deprecated API versions:
-->
**v1.16** 发行版本停止提供以下已废弃 API 版本：
#### NetworkPolicy {#networkpolicy-v116}
<!--
The **extensions/v1beta1** API version of NetworkPolicy is no longer served as of v1.16.
* Migrate manifests and API clients to use the **networking.k8s.io/v1** API version, available since v1.8.
* All existing persisted objects are accessible via the new API
-->
**extensions/v1beta1** API 版本的 NetworkPolicy 不在 v1.16 版本中继续提供。
* 迁移清单和 API 客户端使用 **networking.k8s.io/v1** API 版本，此 API 从
v1.8 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
#### DaemonSet {#daemonset-v116}
<!--
The **extensions/v1beta1** and **apps/v1beta2** API versions of DaemonSet are no longer served as of v1.16.
* Migrate manifests and API clients to use the **apps/v1** API version, available since v1.9.
* All existing persisted objects are accessible via the new API
-->
**extensions/v1beta1** 和 **apps/v1beta2** API 版本的 DaemonSet 在
v1.16 版本中不再继续提供。
* 迁移清单和 API 客户端使用 **apps/v1** API 版本，此 API 从 v1.9 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
<!--
* Notable changes:
* `spec.templateGeneration` is removed
* `spec.selector` is now required and immutable after creation; use the existing template labels as the selector for seamless upgrades
* `spec.updateStrategy.type` now defaults to `RollingUpdate` (the default in `extensions/v1beta1` was `OnDelete`)
-->
* 值得注意的变更：
* `spec.templateGeneration` 字段被删除
* `spec.selector` 现在变成必需字段，并且在对象创建之后不可变更；
可以将现有模板的标签作为选择算符以实现无缝迁移。
* `spec.updateStrategy.type` 的默认值变为 `RollingUpdate`
（`extensions/v1beta1` API 版本中的默认值是 `OnDelete`）。
#### Deployment {#deployment-v116}
<!--
The **extensions/v1beta1**, **apps/v1beta1**, and **apps/v1beta2** API versions of Deployment are no longer served as of v1.16.
* Migrate manifests and API clients to use the **apps/v1** API version, available since v1.9.
* All existing persisted objects are accessible via the new API
-->
**extensions/v1beta1**、**apps/v1beta1** 和 **apps/v1beta2** API 版本的
Deployment 在 v1.16 版本中不再继续提供。
* 迁移清单和 API 客户端使用 **apps/v1** API 版本，此 API 从 v1.9 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
<!--
* Notable changes:
* `spec.rollbackTo` is removed
* `spec.selector` is now required and immutable after creation; use the existing template labels as the selector for seamless upgrades
* `spec.progressDeadlineSeconds` now defaults to `600` seconds (the default in `extensions/v1beta1` was no deadline)
* `spec.revisionHistoryLimit` now defaults to `10` (the default in `apps/v1beta1` was `2`, the default in `extensions/v1beta1` was to retain all)
* `maxSurge` and `maxUnavailable` now default to `25%` (the default in `extensions/v1beta1` was `1`)
-->
* 值得注意的变更：
* `spec.rollbackTo` 字段被删除
* `spec.selector` 字段现在变为必需字段，并且在 Deployment 创建之后不可变更；
可以使用现有的模板的标签作为选择算符以实现无缝迁移。
* `spec.progressDeadlineSeconds` 的默认值变为 `600` 秒
（`extensions/v1beta1` 中的默认值是没有期限）
* `spec.revisionHistoryLimit` 的默认值变为 `10`
（`apps/v1beta1` API 版本中此字段默认值为 `2`，在`extensions/v1beta1` API
版本中的默认行为是保留所有历史记录）。
* `maxSurge` 和 `maxUnavailable` 的默认值变为 `25%`
（在 `extensions/v1beta1` API 版本中，这些字段的默认值是 `1`）。
#### StatefulSet {#statefulset-v116}
<!--
The **apps/v1beta1** and **apps/v1beta2** API versions of StatefulSet are no longer served as of v1.16.
* Migrate manifests and API clients to use the **apps/v1** API version, available since v1.9.
* All existing persisted objects are accessible via the new API
-->
**apps/v1beta1** 和 **apps/v1beta2** API 版本的 StatefulSet 在 v1.16 版本中不再继续提供。
* 迁移清单和 API 客户端使用 **apps/v1** API 版本，此 API 从 v1.9 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
<!--
* Notable changes:
* `spec.selector` is now required and immutable after creation; use the existing template labels as the selector for seamless upgrades
* `spec.updateStrategy.type` now defaults to `RollingUpdate` (the default in `apps/v1beta1` was `OnDelete`)
-->
* 值得注意的变更：
* `spec.selector` 字段现在变为必需字段，并且在 StatefulSet 创建之后不可变更；
可以使用现有的模板的标签作为选择算符以实现无缝迁移。
* `spec.updateStrategy.type` 的默认值变为 `RollingUpdate`
（`apps/v1beta1` API 版本中的默认值是 `OnDelete`）。
#### ReplicaSet {#replicaset-v116}
<!--
The **extensions/v1beta1**, **apps/v1beta1**, and **apps/v1beta2** API versions of ReplicaSet are no longer served as of v1.16.
* Migrate manifests and API clients to use the **apps/v1** API version, available since v1.9.
* All existing persisted objects are accessible via the new API
-->
**extensions/v1beta1**、**apps/v1beta1** 和 **apps/v1beta2** API 版本的
ReplicaSet 在 v1.16 版本中不再继续提供。
* 迁移清单和 API 客户端使用 **apps/v1** API 版本，此 API 从 v1.9 版本开始可用；
* 所有的已保存的对象都可以通过新的 API 来访问；
<!--
* Notable changes:
* `spec.selector` is now required and immutable after creation; use the existing template labels as the selector for seamless upgrades
-->
* 值得注意的变更：
* `spec.selector` 现在变成必需字段，并且在对象创建之后不可变更；
可以将现有模板的标签作为选择算符以实现无缝迁移。
#### PodSecurityPolicy {#psp-v116}
<!--
The **extensions/v1beta1** API version of PodSecurityPolicy is no longer served as of v1.16.
* Migrate manifests and API client to use the **policy/v1beta1** API version, available since v1.10.
* Note that the **policy/v1beta1** API version of PodSecurityPolicy will be removed in v1.25.
-->
**extensions/v1beta1** API 版本的 PodSecurityPolicy 在 v1.16 版本中不再继续提供。
* 迁移清单和 API 客户端使用 **policy/v1beta1** API 版本，此 API 从 v1.10 版本开始可用；
* 注意 **policy/v1beta1** API 版本的 PodSecurityPolicy 会在 v1.25 版本中移除。
<!--
## What to do
### Test with deprecated APIs disabled
-->
## 需要做什么 {#what-to-do}
### 在禁用已启用 API 的情况下执行测试
<!--
You can test your clusters by starting an API server with specific API versions disabled
to simulate upcoming removals. Add the following flag to the API server startup arguments:
-->
你可以通过在启动 API 服务器时禁用特定的 API 版本来模拟即将发生的
API 移除，从而完成测试。在 API 服务器启动参数中添加如下标志：
`--runtime-config=<group>/<version>=false`
<!--
For example:
-->
例如：
`--runtime-config=admissionregistration.k8s.io/v1beta1=false,apiextensions.k8s.io/v1beta1,...`
<!--
### Locate use of deprecated APIs
Use [client warnings, metrics, and audit information available in 1.19+](https://kubernetes.io/blog/2020/09/03/warnings/#deprecation-warnings)
to locate use of deprecated APIs.
-->
### 定位何处使用了已弃用的 API
使用 [client warnings, metrics, and audit information available in 1.19+](https://kubernetes.io/blog/2020/09/03/warnings/#deprecation-warnings)
来定位在何处使用了已启用的 API。
<!--
### Migrate to non-deprecated APIs
-->
### 迁移到未被弃用的 API
<!--
* Update custom integrations and controllers to call the non-deprecated APIs
* Change YAML files to reference the non-deprecated APIs
-->
* 更新自定义的集成组件和控制器，调用未被弃用的 API
* 更改 YAML 文件引用未被弃用的 API
<!--
You can use the `kubectl-convert` command (`kubectl convert` prior to v1.20)
to automatically convert an existing object:
-->
你可以用 `kubectl-convert` 命令（在 v1.20 之前是 `kubectl convert`）
来自动转换现有对象：
`kubectl-convert -f <file> --output-version <group>/<version>`.
<!--
For example, to convert an older Deployment to `apps/v1`, you can run:
-->
例如，要将较老的 Deployment 转换为 `apps/v1` 版本，你可以运行
`kubectl-convert -f ./my-deployment.yaml --output-version apps/v1`
<!--
Note that this may use non-ideal default values. To learn more about a specific
resource, check the Kubernetes [API reference](/docs/reference/kubernetes-api/).
-->
注意这种操作生成的结果中可能使用的默认值并不理想。
要进一步了解某个特定资源，可查阅 Kubernetes [API 参考](/zh/docs/reference/kubernetes-api/)。
content/zh/docs/setup/production-environment/_index.md
+1 -1
View File
@@ -463,7 +463,7 @@ for a description of these different methods of authenticating Kubernetes users.
-->
- *基于角色的访问控制*（[RBAC](/zh/docs/reference/access-authn-authz/rbac/)）：
让你通过为通过身份认证的用户授权特定的许可集合来控制集群访问。
访问许可可以针对某特定名字空间（Role）或者针对整个集群（CLusterRole）。
访问许可可以针对某特定名字空间（Role）或者针对整个集群（ClusterRole）。
通过使用 RoleBinding 和 ClusterRoleBinding 对象，这些访问许可可以被
关联到特定的用户身上。
<!--
content/zh/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md
+243
View File
@@ -0,0 +1,243 @@
---
title: 使用 kubeadm 支持双协议栈
content_type: task
weight: 110
min-kubernetes-server-version: 1.21
---
<!--
title: Dual-stack support with kubeadm
content_type: task
weight: 110
min-kubernetes-server-version: 1.21
-->
<!-- overview -->
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
<!--
Your Kubernetes cluster includes [dual-stack](/docs/concepts/services-networking/dual-stack/) networking, which means that cluster networking lets you use either address family. In a cluster, the control plane can assign both an IPv4 address and an IPv6 address to a single {{< glossary_tooltip text="Pod" term_id="pod" >}} or a {{< glossary_tooltip text="Service" term_id="service" >}}.
-->
你的集群包含[双协议栈](/zh/docs/concepts/services-networking/dual-stack/)组网支持，
这意味着集群网络允许你在两种地址族间任选其一。在集群中，控制面可以为同一个
{{< glossary_tooltip text="Pod" term_id="pod" >}} 或者 {{< glossary_tooltip text="Service" term_id="service" >}}
同时赋予 IPv4 和 IPv6 地址。
<!-- body -->
## {{% heading "prerequisites" %}}
<!--
You need to have installed the {{< glossary_tooltip text="kubeadm" term_id="kubeadm" >}} tool, following the steps from [Installing kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
-->
你需要已经遵从[安装 kubeadm](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)
中所给的步骤安装了 {{< glossary_tooltip text="kubeadm" term_id="kubeadm" >}} 工具。
<!--
For each server that you want to use as a {{< glossary_tooltip text="node" term_id="node" >}}, make sure it allows IPv6 forwarding. On Linux, you can set this by running run `sysctl -w net.ipv6.conf.all.forwarding=1` as the root user on each server.
-->
针对你要作为{{< glossary_tooltip text="节点" term_id="node" >}}使用的每台服务器，
确保其允许 IPv6 转发。在 Linux 节点上，你可以通过以 root 用户在每台服务器上运行
`sysctl -w net.ipv6.conf.all.forwarding=1` 来完成设置。
<!--
You need to have an IPv4 and and IPv6 address range to use. Cluster operators typically
use private address ranges for IPv4. For IPv6, a cluster operator typically chooses a global
unicast address block from within `2000::/3`, using a range that is assigned to the operator.
You don't have to route the cluster's IP address ranges to the public internet.
The size of the IP address allocations should be suitable for the number of Pods and
Services that you are planning to run.
-->
你需要一个可以使用的 IPv4 和 IPv6 地址范围。集群操作人员通常为 IPv4 使用
私有地址范围。对于 IPv6，集群操作人员通常会基于分配给该操作人员的地址范围，
从 `2000::/3` 中选择一个全局的单播地址块。你不需要将集群的 IP 地址范围路由
到公众互联网。
{{< note >}}
<!--
If you are upgrading an existing cluster with the `kubeadm upgrade` command,
`kubeadm` does not support making modifications to the pod IP address range
(“cluster CIDR”) nor to the cluster's Service address range (“Service CIDR”).
-->
如果你在使用 `kubeadm upgrade` 命令升级现有的集群，`kubeadm` 不允许更改 Pod
的 IP 地址范围（“集群 CIDR”），也不允许更改集群的服务地址范围（“Service CIDR”）。
{{< /note >}}
<!--
### Create a dual-stack cluster
To create a dual-stack cluster with `kubeadm init` you can pass command line arguments
similar to the following example:
-->
### 创建双协议栈集群 {#create-a-dual-stack-cluster}
要使用 `kubeadm init` 创建一个双协议栈集群，你可以传递与下面的例子类似的命令行参数：
```shell
# 这里的地址范围仅作示例使用
kubeadm init --pod-network-cidr=10.244.0.0/16,2001:db8:42:0::/56 --service-cidr=10.96.0.0/16,2001:db8:42:1::/112
```
<!--
To make things clearer, here is an example kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) `kubeadm-config.yaml` for the primary dual-stack control plane node.
-->
为了更便于理解，参看下面的名为 `kubeadm-config.yaml` 的 kubeadm
[配置文件](/docs/reference/config-api/kubeadm-config.v1beta3/)，
该文件用于双协议栈控制面的主控制节点。
```yaml
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
networking:
podSubnet: 10.244.0.0/16,2001:db8:42:0::/56
serviceSubnet: 10.96.0.0/16,2001:db8:42:1::/112
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
localAPIEndpoint:
advertiseAddress: "10.100.0.1"
bindPort: 6443
nodeRegistration:
kubeletExtraArgs:
node-ip: 10.100.0.2,fd00:1:2:3::2
```
<!--
`advertiseAddress` in InitConfiguration specifies the IP address that the API Server will advertise it is listening on. The value of `advertiseAddress` equals the `--apiserver-advertise-address` flag of `kubeadm init`
Run kubeadm to initiate the dual-stack control plane node:
-->
InitConfiguration 中的 `advertiseAddress` 给出 API 服务器将公告自身要监听的
IP 地址。`advertiseAddress` 的取值与 `kubeadm init` 的标志
`--apiserver-advertise-address` 的取值相同。
运行 kubeadm 来实例化双协议栈控制面节点：
```shell
kubeadm init --config=kubeadm-config.yaml
```
<!--
The kube-controller-manager flags `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` are set with default values. See [configure IPv4/IPv6 dual stack](/docs/concepts/services-networking/dual-stack#configure-ipv4-ipv6-dual-stack).
-->
kube-controller-manager 标志 `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6`
是使用默认值来设置的。参见[配置 IPv4/IPv6 双协议栈](/zh/docs/concepts/services-networking/dual-stack#configure-ipv4-ipv6-dual-stack)。
{{< note >}}
<!--
The `--apiserver-advertise-address` flag does not support dual-stack.
-->
标志 `--apiserver-advertise-address` 不支持双协议栈。
{{< /note >}}
<!--
### Join a node to dual-stack cluster
Before joining a node, make sure that the node has IPv6 routable network interface and allows IPv6 forwarding.
Here is an example kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) `kubeadm-config.yaml` for joining a worker node to the cluster.
-->
### 向双协议栈集群添加节点 {#join-a-node-to-dual-stack-cluster}
在添加节点之前，请确保该节点具有 IPv6 可路由的网络接口并且启用了 IPv6 转发。
下面的名为 `kubeadm-config.yaml` 的 kubeadm
[配置文件](/docs/reference/config-api/kubeadm-config.v1beta3/)
示例用于向集群中添加工作节点。
```yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: JoinConfiguration
discovery:
bootstrapToken:
apiServerEndpoint: 10.100.0.1:6443
token: "clvldh.vjjwg16ucnhp94qr"
caCertHashes:
- "sha256:a4863cde706cfc580a439f842cc65d5ef112b7b2be31628513a9881cf0d9fe0e"
# 请更改上面的认证信息，使之与你的集群中实际使用的令牌和 CA 证书匹配
nodeRegistration:
kubeletExtraArgs:
node-ip: 10.100.0.3,fd00:1:2:3::3
```
<!--
Also, here is an example kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) `kubeadm-config.yaml` for joining another control plane node to the cluster.
-->
下面的名为 `kubeadm-config.yaml` 的 kubeadm
[配置文件](/docs/reference/config-api/kubeadm-config.v1beta3/)
示例用于向集群中添加另一个控制面节点。
```yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: JoinConfiguration
controlPlane:
localAPIEndpoint:
advertiseAddress: "10.100.0.2"
bindPort: 6443
discovery:
bootstrapToken:
apiServerEndpoint: 10.100.0.1:6443
token: "clvldh.vjjwg16ucnhp94qr"
caCertHashes:
- "sha256:a4863cde706cfc580a439f842cc65d5ef112b7b2be31628513a9881cf0d9fe0e"
# 请更改上面的认证信息，使之与你的集群中实际使用的令牌和 CA 证书匹配
nodeRegistration:
kubeletExtraArgs:
node-ip: 10.100.0.4,fd00:1:2:3::4
```
<!--
`advertiseAddress` in JoinConfiguration.controlPlane specifies the IP address that the API Server will advertise it is listening on. The value of `advertiseAddress` equals the `--apiserver-advertise-address` flag of `kubeadm join`.
-->
JoinConfiguration.controlPlane 中的 `advertiseAddress` 设定 API 服务器将公告自身要监听的
IP 地址。`advertiseAddress` 的取值与 `kubeadm join` 的标志
`--apiserver-advertise-address` 的取值相同。
```shell
kubeadm join --config=kubeadm-config.yaml
```
<!--
### Create a single-stack cluster
-->
### 创建单协议栈集群 {#create-a-single-stack-cluster}
{{< note >}}
<!--
Dual-stack support doesn't mean that you need to use dual-stack addressing.
You can deploy a single-stack cluster that has the dual-stack networking feature enabled.
-->
双协议栈支持并不意味着你需要使用双协议栈来寻址。
你可以部署一个启用了双协议栈联网特性的单协议栈集群。
{{< /note >}}
<!--
To make things more clear, here is an example kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) `kubeadm-config.yaml` for the single-stack control plane node.
-->
为了更便于理解，参看下面的名为 `kubeadm-config.yaml` 的 kubeadm
[配置文件](/docs/reference/config-api/kubeadm-config.v1beta3/)示例，
该文件用于单协议栈控制面节点。
```yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
networking:
podSubnet: 10.244.0.0/16
serviceSubnet: 10.96.0.0/16
```
## {{% heading "whatsnext" %}}
<!--
* [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking
* Read about [Dual-stack](/docs/concepts/services-networking/dual-stack/) cluster networking
* Learn more about the kubeadm [configuration format](/docs/reference/config-api/kubeadm-config.v1beta3/)
-->
* [验证 IPv4/IPv6 双协议栈](/zh/docs/tasks/network/validate-dual-stack)联网
* 阅读[双协议栈](/zh/docs/concepts/services-networking/dual-stack/)集群网络
* 进一步了解 kubeadm [配置格式](/docs/reference/config-api/kubeadm-config.v1beta3/)
content/zh/docs/tasks/access-application-cluster/web-ui-dashboard.md
+46 -24
View File
@@ -1,5 +1,5 @@
---
title: Web 界面 (Dashboard)
title: 部署和访问 Kubernetes 仪表板（Dashboard）
content_type: concept
weight: 10
card:
@@ -11,8 +11,7 @@ card:
reviewers:
- bryk
- mikedanese
- rf232
title: Web UI (Dashboard)
title: Deploy and Access the Kubernetes Dashboard
content_type: concept
weight: 10
card:
@@ -56,7 +55,7 @@ The Dashboard UI is not deployed by default. To deploy it, run the following com
默认情况下不会部署 Dashboard。可以通过以下命令部署：
```
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.4.0/aio/deploy/recommended.yaml
```
<!--
@@ -67,7 +66,7 @@ Currently, Dashboard only supports logging in with a Bearer Token.
To create a token for this demo, you can follow our guide on
[creating a sample user](https://github.com/kubernetes/dashboard/wiki/Creating-sample-user).
-->
## 访问 Dashboard UI
## 访问 Dashboard 用户界面
为了保护你的集群数据，默认情况下，Dashboard 会使用最少的 RBAC 配置进行部署。
当前，Dashboard 仅支持使用 Bearer 令牌登录。
@@ -85,11 +84,12 @@ The sample user created in the tutorial will have administrative privileges and
<!--
### Command line proxy
You can access Dashboard using the kubectl command-line tool by running the following command:
You can enable access to the Dashboard using the `kubectl` command-line tool,
by running the following command:
-->
### 命令行代理
你可以使用 kubectl 命令行工具访问 Dashboard，命令如下：
你可以使用 `kubectl` 命令行工具来启用 Dashboard 访问，命令如下：
```
kubectl proxy
@@ -106,10 +106,11 @@ The UI can _only_ be accessed from the machine where the command is executed. Se
UI _只能_ 通过执行这条命令的机器进行访问。更多选项参见 `kubectl proxy --help`。
<!--
Kubeconfig Authentication method does NOT support external identity providers or x509 certificate-based authentication.
The kubeconfig authentication method does **not** support external identity providers
or X.509 certificate-based authentication.
-->
{{< note >}}
Kubeconfig 身份验证方法不支持外部身份提供程序或基于 x509 证书的身份验证。
Kubeconfig 身份验证方法**不**支持外部身份提供程序或基于 x509 证书的身份验证。
{{< /note >}}
<!--
@@ -133,11 +134,14 @@ When you access Dashboard on an empty cluster, you'll see the welcome page. This
<!--
## Deploying containerized applications
Dashboard lets you create and deploy a containerized application as a Deployment and optional Service with a simple wizard. You can either manually specify application details, or upload a YAML or JSON file containing application configuration.
Dashboard lets you create and deploy a containerized application as a Deployment and optional Service with a simple wizard.
You can either manually specify application details, or upload a YAML or JSON _manifest_ file containing application configuration.
-->
## 部署容器化应用
通过一个简单的部署向导，你可以使用 Dashboard 将容器化应用作为一个 Deployment 和可选的 Service 进行创建和部署。可以手工指定应用的详细配置，或者上传一个包含应用配置的 YAML 或 JSON 文件。
通过一个简单的部署向导，你可以使用 Dashboard 将容器化应用作为一个 Deployment 和可选的
Service 进行创建和部署。你可以手工指定应用的详细配置，或者上传一个包含应用配置的 YAML
或 JSON _清单_文件。
<!--
Click the **CREATE** button in the upper right corner of any page to begin.
@@ -336,17 +340,22 @@ If needed, you can expand the **Advanced options** section where you can specify
<!--
### Uploading a YAML or JSON file
Kubernetes supports declarative configuration. In this style, all configuration is stored in YAML or JSON configuration files using the Kubernetes [API](/docs/concepts/overview/kubernetes-api/) resource schemas.
Kubernetes supports declarative configuration.
In this style, all configuration is stored in manifests (YAML or JSON configuration files).
The manifests use the Kubernetes [API](/docs/concepts/overview/kubernetes-api/) resource schemas.
-->
### 上传 YAML 或者 JSON 文件
Kubernetes 支持声明式配置。所有的配置都存储在遵循 Kubernetes
[API](/zh/docs/concepts/overview/kubernetes-api/) 规范的 YAML 或者 JSON 配置文件中。
Kubernetes 支持声明式配置。所有的配置都存储在清单文件
（YAML 或者 JSON 配置文件）中。这些
清单使用 Kubernetes [API](/zh/docs/concepts/overview/kubernetes-api/) 定义的资源模式。
<!--
As an alternative to specifying application details in the deploy wizard, you can define your application in YAML or JSON files, and upload the files using Dashboard:
As an alternative to specifying application details in the deploy wizard,
you can define your application one or more manifests, and upload the files using Dashboard.
-->
作为一种替代在部署向导中指定应用详情的方式，你可以在 YAML 或者 JSON 文件中定义应用，并且使用 Dashboard 上传文件：
作为一种替代在部署向导中指定应用详情的方式，你可以在一个或多个清单文件中定义应用，并且使用
Dashboard 上传文件。
<!--
## Using Dashboard
@@ -375,7 +384,10 @@ Dashboard 展示大部分 Kubernetes 对象，并将它们分组放在几个菜
<!--
#### Admin Overview
For cluster and namespace administrators, Dashboard lists Nodes, Namespaces and Persistent Volumes and has detail views for them. Node list view contains CPU and memory usage metrics aggregated across all Nodes. The details view shows the metrics for a Node, its specification, status, allocated resources, events and pods running on the node.
For cluster and namespace administrators, Dashboard lists Nodes, Namespaces and PersistentVolumes and has detail views for them.
Node list view contains CPU and memory usage metrics aggregated across all Nodes.
The details view shows the metrics for a Node, its specification, status,
allocated resources, events and pods running on the node.
-->
#### 管理概述
@@ -385,22 +397,31 @@ For cluster and namespace administrators, Dashboard lists Nodes, Namespaces and
<!--
#### Workloads
Shows all applications running in the selected namespace. The view lists applications by workload kind (e.g., Deployments, Replica Sets, Stateful Sets, etc.) and each workload kind can be viewed separately. The lists summarize actionable information about the workloads, such as the number of ready pods for a Replica Set or current memory usage for a Pod.
Shows all applications running in the selected namespace.
The view lists applications by workload kind (e.g., Deployments, ReplicaSets, Stateful Sets, etc.).
Each workload kind can be viewed separately.
The lists summarize actionable information about the workloads,
such as the number of ready pods for a ReplicaSet or current memory usage for a Pod.
-->
#### 负载
显示选中的名字空间中所有运行的应用。
视图按照负载类型（如 Deployment、ReplicaSet、StatefulSet 等）罗列应用，并且每种负载都可以单独查看。
列表总结了关于负载的可执行信息，比如一个 ReplicaSet 的准备状态的 Pod 数量，或者目前一个 Pod 的内存使用量。
列表总结了关于负载的可执行信息，比如一个 ReplicaSet 的就绪状态的 Pod 数量，或者目前一个 Pod 的内存用量。
<!--
Detail views for workloads show status and specification information and surface relationships between objects. For example, Pods that Replica Set is controlling or New Replica Sets and Horizontal Pod Autoscalers for Deployments.
Detail views for workloads show status and specification information and
surface relationships between objects.
For example, Pods that Replica Set is controlling or New ReplicaSets and HorizontalPodAutoscalers for Deployments.
-->
工作负载的详情视图展示了对象的状态、详细信息和相互关系。
例如，ReplicaSet 所控制的 Pod，或者 Deployment 关联的 新 ReplicaSet 和 Pod 水平扩展控制器。
例如，ReplicaSet 所控制的 Pod，或者 Deployment 所关联的新 ReplicaSet 和
HorizontalPodAutoscalers。
<!--
#### Services
Shows Kubernetes resources that allow for exposing services to external world and discovering them within a cluster. For that reason, Service and Ingress views show Pods targeted by them, internal endpoints for cluster connections and external endpoints for external users.
-->
#### 服务
@@ -411,7 +432,7 @@ Shows Kubernetes resources that allow for exposing services to external world an
<!--
#### Storage
Storage view shows Persistent Volume Claim resources which are used by applications for storing data.
Storage view shows PersistentVolumeClaim resources which are used by applications for storing data.
-->
#### 存储
@@ -425,7 +446,7 @@ Shows all Kubernetes resources that are used for live configuration of applicati
#### ConfigMap 和 Secret
展示的所有 Kubernetes 资源是在集群中运行的应用程序的实时配置。
通过这个视图可以编辑和管理配置对象，并显示那些默认隐藏的 secret。
通过这个视图可以编辑和管理配置对象，并显示那些默认隐藏的 Secret。
<!--
#### Logs viewer
@@ -434,7 +455,8 @@ Pod lists and detail pages link to logs viewer that is built into Dashboard. The
-->
#### 日志查看器
Pod 列表和详细信息页面可以链接到 Dashboard 内置的日志查看器。查看器可以钻取属于同一个 Pod 的不同容器的日志。
Pod 列表和详细信息页面可以链接到 Dashboard 内置的日志查看器。
查看器可以深入查看属于同一个 Pod 的不同容器的日志。
<!--
![Logs viewer](/images/docs/ui-dashboard-logs-view.png)
content/zh/docs/tasks/administer-cluster/reconfigure-kubelet.md
+14 -21
View File
@@ -17,13 +17,13 @@ content_type: task
<!--
{{< caution >}}
[Dynamic Kubelet Configuration](https://github.com/kubernetes/enhancements/issues/281)
The [Dynamic Kubelet Configuration](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/281-dynamic-kubelet-configuration)
feature is deprecated and should not be used.
Please switch to alternative means distributing configuration to the Nodes of your cluster.
{{< /caution >}}
-->
{{< caution >}}
[动态 kubelet 配置](https://github.com/kubernetes/enhancements/issues/281)
[动态 kubelet 配置](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/281-dynamic-kubelet-configuration)
已经废弃不建议使用。请选择其他方法将配置分发到集群中的节点。
{{< /caution >}}
@@ -57,22 +57,15 @@ fields is available in the inline
<!--
You need to have a Kubernetes cluster.
You also need kubectl v1.11 or higher, configured to communicate with your cluster.
You also need `kubectl`, [installed](/docs/tasks/tools/#kubectl) and configured to communicate with your cluster.
Make sure that you are using a version of `kubectl` that is
[compatible](/releases/version-skew-policy/) with your cluster.
{{< version-check >}}
Your cluster API server version (eg v1.12) must be no more than one minor
version away from the version of kubectl that you are using. For example,
if your cluster is running v1.16 then you can use kubectl v1.15, v1.16
or v1.17; other combinations
[aren't supported](/docs/setup/release/version-skew-policy/#kubectl).
-->
你需要一个 Kubernetes 集群。
你需要 v1.11 或更高版本的 kubectl，并配置好与集群的通信。
你还需要 `kubectl`，[安装](/zh/docs/tasks/tools/#kubectl)并配置好与集群的通信。
{{< version-check >}}
你的集群 API 服务器版本（如 v1.12）不能和你的 kubectl
版本相差超过一个小版本号。
例如，如果你的集群在运行 v1.16，那么你可以使用 v1.15、v1.16、v1.17 的 kubectl，
所有其他的组合都是
[不支持的](/zh/docs/setup/release/version-skew-policy/#kubectl)。
确保你使用的 `kubectl` 版本与集群 [兼容](/releases/version-skew-policy/)。
<!--
Some of the examples use the command line tool
@@ -508,7 +501,7 @@ new ConfigMap, and then update the Node to use the new ConfigMap.
#### 做出更多的改变 {#make-more-changes}
按照下面的工作流程做出更多的改变并再次推送它们。
你每次推送一个 ConfigMap 的新内容时，kubeclt 的 `--append-hash` 选项都会给
你每次推送一个 ConfigMap 的新内容时，kubectl 的 `--append-hash` 选项都会给
ConfigMap 创建一个新的名称。
最安全的上线策略是首先创建一个新的 ConfigMap，然后更新节点以使用新的 ConfigMap。
@@ -658,15 +651,15 @@ internal failure, see Kubelet log for details | 在对配置进行同步的循
## {{% heading "whatsnext" %}}
<!--
- For more information on configuring the kubelet via a configuration file, see
[Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file).
- See the reference documentation for [`NodeConfigSource`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core)
- [Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file)
explains the supported way to configure a kubelet.
- See the reference documentation for Node, including the `configSource` field within
the Node's [.spec](/docs/reference/kubernetes-api/cluster-resources/node-v1/#NodeSpec)
- Learn more about kubelet configuration by checking the
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/)
reference.
-->
- 关于如何通过配置文件来配置 kubelet 的更多细节信息，可参阅
[使用配置文件设置 kubelet 参数](/zh/docs/tasks/administer-cluster/kubelet-config-file).
- 阅读 API 文档中 [`NodeConfigSource`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core) 说明
- [使用配置文件设置 kubelet 参数](/zh/docs/tasks/administer-cluster/kubelet-config-file)说明了配置 kubelet 的方法。
- 阅读 Node 的参考文档，包括 [.spec](/docs/reference/kubernetes-api/cluster-resources/node-v1/#NodeSpec) 里的 `configSource` 字段
- 查阅[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/)文献进一步了解 kubelet
配置信息。
content/zh/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md
+120
View File
@@ -0,0 +1,120 @@
---
title: 通过配置内置准入控制器实施 Pod 安全标准
content_type: task
min-kubernetes-server-version: v1.22
---
<!--
title: Enforce Pod Security Standards by Configuring the Built-in Admission Controller
reviewers:
- tallclair
- liggitt
content_type: task
min-kubernetes-server-version: v1.22
-->
<!--
As of v1.22, Kubernetes provides a built-in [admission controller](/docs/reference/access-authn-authz/admission-controllers/#podsecurity)
to enforce the [Pod Security Standards](/docs/concepts/security/pod-security-standards).
You can configure this admission controller to set cluster-wide defaults and [exemptions](/docs/concepts/security/pod-security-admission/#exemptions).
-->
在 v1.22 版本中，Kubernetes 提供一种内置的[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#podsecurity)
用来强制实施 [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards)。
你可以配置此准入控制器来设置集群范围的默认值和[豁免选项](/zh/docs/concepts/security/pod-security-admission/#exemptions)。
## {{% heading "prerequisites" %}}
{{% version-check %}}
<!--
- Ensure the `PodSecurity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) is enabled.
-->
- 确保 `PodSecurity` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features)已被启用。
<!--
## Configure the Admission Controller
-->
## 配置准入控制器 {#configure-the-admission-controller}
{{< tabs name="PodSecurityConfiguration_example_1" >}}
{{% tab name="pod-security.admission.config.k8s.io/v1beta1" %}}
```yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
configuration:
apiVersion: pod-security.admission.config.k8s.io/v1beta1
kind: PodSecurityConfiguration
# 当未设置 mode 标签时会应用的默认设置
#
# level 标签必须是以下取值之一：
# - "privileged" (默认)
# - "baseline"
# - "restricted"
#
# version 标签必须是如下取值之一：
# - "latest" (默认)
# - 诸如 "v{{< skew latestVersion >}}" 这类版本号
defaults:
enforce: "privileged"
enforce-version: "latest"
audit: "privileged"
audit-version: "latest"
warn: "privileged"
warn-version: "latest"
exemptions:
# 要豁免的已认证用户名列表
usernames: []
# 要豁免的运行时类名称列表
runtimeClassNames: []
# 要豁免的名字空间列表
namespaces: []
```
{{< note >}}
<!--
v1beta1 configuration requires v1.23+. For v1.22, use v1alpha1.
-->
v1beta1 配置结构需要使用 v1.23+ 版本；对于 v1.22 版本，可使用 v1alpha1。
{{< /note >}}
{{% /tab %}}
{{% tab name="pod-security.admission.config.k8s.io/v1alpha1" %}}
```yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
configuration:
apiVersion: pod-security.admission.config.k8s.io/v1alpha1
kind: PodSecurityConfiguration
# 当未设置 mode 标签时会应用的默认设置
#
# level 标签必须是以下取值之一：
# - "privileged" (默认)
# - "baseline"
# - "restricted"
#
# version 标签必须是如下取值之一：
# - "latest" (默认)
# - 诸如 "v{{< skew latestVersion >}}" 这类版本号
defaults:
enforce: "privileged"
enforce-version: "latest"
audit: "privileged"
audit-version: "latest"
warn: "privileged"
warn-version: "latest"
exemptions:
# 要豁免的已认证用户名列表
usernames: []
# 要豁免的运行时类名称列表
runtimeClasses: []
# 要豁免的名字空间列表
namespaces: []
```
{{% /tab %}}
{{< /tabs >}}
content/zh/docs/tasks/configure-pod-container/enforce-standards-namespace-labels.md
+141
View File
@@ -0,0 +1,141 @@
---
title: 使用名字空间标签来实施 Pod 安全性标准
content_type: task
min-kubernetes-server-version: v1.22
---
<!--
title: Enforce Pod Security Standards with Namespace Labels
reviewers:
- tallclair
- liggitt
content_type: task
min-kubernetes-server-version: v1.22
-->
<!--
Namespaces can be labeled to enforce the [Pod Security Standards](/docs/concepts/security/pod-security-standards).
-->
你可以通过为名字空间设置标签来强制实施 [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards)。
## {{% heading "prerequisites" %}}
{{% version-check %}}
<!--
- Ensure the `PodSecurity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) is enabled.
-->
- 确保 `PodSecurity` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features)已被启用。
<!--
## Requiring the `baseline` Pod Security Standard with namespace labels
-->
## 通过名字空间标签来要求实施 `baseline` Pod 容器标准
<!--
This manifest defines a Namespace `my-baseline-namespace` that:
- _Blocks_ any pods that don't satisfy the `baseline` policy requirements.
- Generates a user-facing warning and adds an audit annotation to any created pod that does not
meet the `restricted` policy requirements.
- Pins the versions of the `baseline` and `restricted` policies to v{{< skew latestVersion >}}.
-->
下面的清单定义了一个 `my-baseline-namespace` 名字空间，其中
- *阻止*任何不满足 `baseline` 策略要求的 Pods；
- 针对任何无法满足 `restricted` 策略要求的、已创建的 Pod 为用户生成警告信息，
并添加审计注解；
- 将 `baseline` 和 `restricted` 策略的版本锁定到 v{{< skew latestVersion >}}。
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: my-baseline-namespace
labels:
pod-security.kubernetes.io/enforce: baseline
pod-security.kubernetes.io/enforce-version: v{{< skew latestVersion >}}
# 我们将这些标签设置为我们所 _期望_ 的 `enforce` 级别
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/audit-version: v{{< skew latestVersion >}}
pod-security.kubernetes.io/warn: restricted
pod-security.kubernetes.io/warn-version: v{{< skew latestVersion >}}
```
<!--
## Add labels to existing namespaces with `kubectl label`
-->
## 使用 `kubectl label` 为现有名字空间添加标签
{{< note >}}
<!--
When an `enforce` policy (or version) label is added or changed, the admission plugin will test
each pod in the namespace against the new policy. Violations are returned to the user as warnings.
-->
在添加或变更 `enforce` 策略（或版本）标签时，准入插件会测试名字空间中的每个
Pod 以检查其是否满足新的策略。不符合策略的情况会被以警告的形式返回给用户。
{{< /note >}}
<!--
It is helpful to apply the `--dry-run` flag when initially evaluating security profile changes for
namespaces. The Pod Security Standard checks will still be run in _dry run_ mode, giving you
information about how the new policy would treat existing pods, without actually updating a policy.
-->
在刚开始为名字空间评估安全性策略变更时，使用 `--dry-run` 标志是很有用的。
Pod 安全性标准会在 _dry run（试运行）_
模式下运行，在这种模式下会生成新策略如何处理现有 Pod 的信息，
但不会真正更新策略。
```shell
kubectl label --dry-run=server --overwrite ns --all \
pod-security.kubernetes.io/enforce=baseline
```
<!--
### Applying to all namespaces
-->
### 应用到所有名字空间
<!--
If you're just getting started with the Pod Security Standards, a suitable first step would be to
configure all namespaces with audit annotations for a stricter level such as `baseline`:
-->
如果你是刚刚开始使用 Pod 安全性标准，一种比较合适的初始步骤是针对所有名字空间为类似
`baseline` 这种比较严格的安全级别配置审计注解。
```shell
kubectl label --overwrite ns --all \
pod-security.kubernetes.io/audit=baseline \
pod-security.kubernetes.io/warn=baseline
```
<!--
Note that this is not setting an enforce level, so that namespaces that haven't been explicitly
evaluated can be distinguished. You can list namespaces without an explicitly set enforce level
using this command:
-->
注意，这里没有设置 enforce 级别，因而没有被显式评估的名字空间可以被识别出来。
你可以使用下面的命令列举那些没有显式设置 enforce 级别的名字空间：
```shell
kubectl get namespaces --selector='!pod-security.kubernetes.io/enforce'
```
<!--
### Applying to a single namespace
-->
### 应用到单个名字空间
<!--
You can update a specific namespace as well. This command adds the `enforce=restricted`
policy to `my-existing-namespace`, pinning the restricted policy version to v{{< skew latestVersion >}}.
-->
你也可以更新特定的名字空间。下面的命令将 `enforce=restricted` 策略应用到
`my-existing-namespace` 名字空间，将 restricted 策略的版本锁定到 v{{< skew latestVersion >}}。
```shell
kubectl label --overwrite ns my-existing-namespace \
pod-security.kubernetes.io/enforce=restricted \
pod-security.kubernetes.io/enforce-version=v{{< skew latestVersion >}}
```
content/zh/docs/tasks/configure-pod-container/migrate-from-psp.md
+93
View File
@@ -0,0 +1,93 @@
---
title: 从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器
content_type: task
min-kubernetes-server-version: v1.22
---
<!--
title: Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller
reviewers:
- tallclair
- liggitt
content_type: task
min-kubernetes-server-version: v1.22
-->
<!-- overview -->
<!--
This page describes the process of migrating from PodSecurityPolicies to the built-in PodSecurity
admission controller. This can be done effectively using a combination of dry-run and `audit` and
`warn` modes, although this becomes harder if mutating PSPs are used.
-->
本页面描述从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器的过程。
这一迁移过程可以通过综合使用试运行、`audit` 和 `warn` 模式等来实现，
尽管在使用了变更式 PSP 时会变得有些困难。
## {{% heading "prerequisites" %}}
{{% version-check %}}
<!--
- Ensure the `PodSecurity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) is enabled.
-->
- 确保 `PodSecurity` [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)被启用。
<!-- body -->
<!--
## Steps
-->
## 步骤 {#steps}
<!--
- **Eliminate mutating PodSecurityPolicies, if your cluster has any set up.**
- Clone all mutating PSPs into a non-mutating version.
- Update all ClusterRoles authorizing use of those mutating PSPs to also authorize use of the
non-mutating variant.
- Watch for Pods using the mutating PSPs and work with code owners to migrate to valid,
non-mutating resources.
- Delete mutating PSPs.
-->
-- **如果你的集群中配置了变更式的 PodSecurityPolicy，将它们删除。**
- 复制所有变更式 PSP 复制到非变更式版本中。
- 更新所有授权使用那些变更式 PSP 的 ClusterRole，使之也能为非变更式版本鉴权。
- 检视使用了变更式 PSP 的 Pod，与拥有该代码的人一起将其迁移到合法的、非变更式的资源。
- 删除变更式 PSP。
<!--
- **Select a compatible policy level for each namespace.** Analyze existing resources in the
namespace to drive this decision.
- Review the requirements of the different [Pod Security Standards](/docs/concepts/security/pod-security-standards).
- Evaluate the difference in privileges that would come from disabling the PSP controller.
- In the event that a PodSecurityPolicy falls between two levels, consider:
- Selecting a _less_ permissive PodSecurity level prioritizes security, and may require adjusting
workloads to fit within the stricter policy.
- Selecting a _more_ permissive PodSecurity level prioritizes avoiding disrupting or
changing workloads, but may allow workload authors in the namespace greater permissions
than desired.
-->
- **为每个名字空间选择一个兼容的策略级别。**
要分析名字空间中已有的资源才能作出此决定。
- 审阅不同 [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards)的需求。
- 评估禁用 PSP 控制器所带来的特权级变化。
- 当 PodSecurityPolicy 中的设置介于两种策略级别之间时，考虑：
- 选择一个安全许可*略弱*的 PodSecurity 级别，可能需要调整负载本身，
使之能够在较严格的策略下工作。
- 选择一个安全许可*略强*的 PodSecurity 级别，从而避免干扰或变更负载本身。
不过这样做可能会让负载的作者在名字空间中拥有超出预期的权限。
<!--
- **Apply the selected profiles in `warn` and `audit` mode.** This will give you an idea of how
your Pods will respond to the new policies, without breaking existing workloads. Iterate on your
[Pods' configuration](/docs/concepts/security/pod-security-admission#configuring-pods) until
they are in compliance with the selected profiles.
- Apply the profiles in `enforce` mode.
- Stop including `PodSecurityPolicy` in the `--enable-admission-plugins` flag.
-->
- **在 `warn` 和 `audit` 模式下应用所选的策略。**
这样做会让你了解 Pod 会如何对新的策略作出反应，同时不会破坏现有负载。
反复调试你的[Pod 配置](/zh/docs/concepts/security/pod-security-admission#configuring-pods)
直到它们与所选的策略匹配。
- 用 `enforce` 模式下应用策略。
- 在 `--enable-admission-plugins` 标志中去除 `PodSecurityPolicy`。
content/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
+40 -23
View File
@@ -32,12 +32,12 @@ Pod 使用哪个调度器。
<!--
A detailed description of how to implement a scheduler is outside the scope of this
document. Please refer to the kube-scheduler implementation in
[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler)
[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/master/pkg/scheduler)
in the Kubernetes source directory for a canonical example.
-->
关于实现调度器的具体细节描述超出了本文范围。
请参考 kube-scheduler 的实现，规范示例代码位于
[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler)。
[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/master/pkg/scheduler)。
## {{% heading "prerequisites" %}}
@@ -116,18 +116,33 @@ ReplicaSet 再管理 Pod，从而使调度器能够免受一些故障的影响
{{< codenew file="admin/sched/my-scheduler.yaml" >}}
<!--
An important thing to note here is that the name of the scheduler specified as an
argument to the scheduler command in the container spec should be unique.
This is the name that is matched against the value of the optional `spec.schedulerName`
on pods, to determine whether this scheduler is responsible for scheduling a particular pod.
In the above manifest, you use a [KubeSchedulerConfiguration](/docs/reference/scheduling/config/)
to customize the behavior of your scheduler implementation. This configuration has been passed to
the `kube-scheduler` during initialization with the `--config` option. The `my-scheduler-config` ConfigMap stores the configuration file. The Pod of the`my-scheduler` Deployment mounts the `my-scheduler-config` ConfigMap as a volume.
-->
这里需要注意的是，在容器规约中配置的调度器启动命令参数（--scheduler-name）所指定的
调度器名称应该是唯一的。
这个名称应该与 Pod 上的可选参数 `spec.schedulerName` 的值相匹配，也就是说调度器名称的匹配
关系决定了 Pods 的调度任务由哪个调度器负责。
在以上的清单中，你使用 [KubeSchedulerConfiguration](/zh/docs/reference/scheduling/config/)
来自定义调度器实现的行为。当使用 `--config` 选项进行初始化时，该配置被传递到 `kube-scheduler`。
`my-scheduler-config` ConfigMap 存储配置数据。
`my-scheduler` Deployment 的 Pod 将 `my-scheduler-config` ConfigMap 挂载为一个卷。
<!--
Note also that we created a dedicated service account `my-scheduler` and bind the cluster role
In the aforementioned Scheduler Configuration, your scheduler implementation is represented via
a [KubeSchedulerProfile](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-KubeSchedulerProfile).
{{< note >}}
To determine if a scheduler is responsible for scheduling a specific Pod, the `spec.schedulerName` field in a
PodTemplate or Pod manifest must match the `schedulerName` field of the `KubeSchedulerProfile`.
All schedulers running in the cluster must have unique names.
{{< /note >}}
-->
在前面提到的调度器配置中，你的调度器通过 [KubeSchedulerProfile](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-KubeSchedulerProfile) 进行实现。
{{< note >}}
要确定一个调度器是否可以调度特定的 Pod，PodTemplate 或 Pod 清单中的 `spec.schedulerName`
字段必须匹配 `KubeSchedulerProfile` 中的 `schedulerName` 字段。
所有运行在集群中的调度器必须拥有唯一的名称。
{{< /note >}}
<!--
Also, note that you create a dedicated service account `my-scheduler` and bind the ClusterRole
`system:kube-scheduler` to it so that it can acquire the same privileges as `kube-scheduler`.
-->
还要注意，我们创建了一个专用服务账号 `my-scheduler` 并将集群角色 `system:kube-scheduler`
@@ -136,10 +151,13 @@ Note also that we created a dedicated service account `my-scheduler` and bind th
<!--
Please see the
[kube-scheduler documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for
detailed description of other command line arguments.
detailed description of other command line arguments and
[Scheduler Configuration reference](/docs/reference/config-api/kube-scheduler-config.v1beta3/) for
detailed description of other customizable `kube-scheduler` configurations.
-->
请参阅 [kube-scheduler 文档](/docs/reference/command-line-tools-reference/kube-scheduler/)
以获取其他命令行参数的详细说明。
获取其他命令行参数以及 [Scheduler 配置参考](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
获取自定义 `kube-scheduler` 配置的详细说明。
<!--
## Run the second scheduler in the cluster
@@ -186,17 +204,17 @@ pod in this list.
To run multiple-scheduler with leader election enabled, you must do the following:
First, update the following fields in your YAML file:
Update the following fields for the KubeSchedulerConfiguration in the `my-scheduler-config` ConfigMap in your YAML file:
-->
### 启用领导者选举
要在启用了 leader 选举的情况下运行多调度器，你必须执行以下操作：
首先，更新上述 Deployment YAML（my-scheduler.yaml）文件中的以下字段：
更新你的 YAML 文件中的 `my-scheduler-config` ConfigMap 里的 KubeSchedulerConfiguration 相关字段如下：
* `--leader-elect=true`
* `--lock-object-namespace=<lock-object-namespace>`
* `--lock-object-name=<lock-object-name>`
* `leaderElection.leaderElect` to `true`
* `leaderElection.resourceNamespace` to `<lock-object-namespace>`
* `leaderElection.resourceName` to `<lock-object-name>`
{{< note >}}
<!--
@@ -288,12 +306,11 @@ scheduler in that pod spec. Let's look at three examples.
<!--
In this case, we specify that this pod should be scheduled using the scheduler that we
deployed - `my-scheduler`. Note that the value of `spec.schedulerName` should match the name supplied to the scheduler
command as an argument in the deployment config for the scheduler.
deployed - `my-scheduler`. Note that the value of `spec.schedulerName` should match the name supplied for the scheduler
in the `schedulerName` field of the mapping `KubeSchedulerProfile`.
-->
在这种情况下，我们指定此 pod 使用我们部署的 `my-scheduler` 来调度。
请注意，`spec.schedulerName` 参数的值应该与 Deployment 中配置的提供给
scheduler 命令的参数名称匹配。
在这种情况下，我们指定此 Pod 使用我们部署的 `my-scheduler` 来调度。
请注意，`spec.schedulerName` 参数的值应该与调度器提供的 `KubeSchedulerProfile` 中的 `schedulerName` 字段相匹配。
<!--
Save this file as `pod3.yaml` and submit it to the Kubernetes cluster.
content/zh/docs/tasks/manage-kubernetes-objects/declarative-config.md
+1 -1
View File
@@ -347,7 +347,7 @@ spec:
Directly update the `replicas` field in the live configuration by using `kubectl scale`.
This does not use `kubectl apply`:
-->
通过 `kubeclt scale` 命令直接更新现时配置中的 `replicas` 字段。
通过 `kubectl scale` 命令直接更新现时配置中的 `replicas` 字段。
这一命令没有使用 `kubectl apply`：
```shell
content/zh/docs/tasks/tls/managing-tls-in-a-cluster.md
+15 -5
View File
@@ -231,14 +231,24 @@ Events: <none>
<!--
## Get the Certificate Signing Request Approved
Approving the certificate signing request is either done by an automated
approval process or on a one off basis by a cluster administrator. More
information on what this involves is covered below.
Approving the [certificate signing request](/docs/reference/access-authn-authz/certificate-signing-requests/)
is either done by an automated approval process or on a one off basis by a cluster
administrator. If you're authorized to approve a certificate request, you can do that
manually using `kubectl`; for example:
-->
## 批准证书签名请求
批准证书签名请求是通过自动批准过程完成的，或由集群管理员一次性完成。
有关这方面涉及的更多信息，请参见下文。
[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)
的批准或者是通过自动批准过程完成的，或由集群管理员一次性完成。
如果你被授权批准证书请求，你可以使用 `kubectl` 来手动完成此操作；例如：
```shell
kubectl certificate approve my-svc.my-namespace
```
```none
certificatesigningrequest.certificates.k8s.io/my-svc.my-namespace approved
```
<!--
## Download the Certificate and Use It
content/zh/examples/admin/sched/my-scheduler.yaml
+26 -7
View File
@@ -17,6 +17,20 @@ roleRef:
name: system:kube-scheduler
apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: ConfigMap
metadata:
name: my-scheduler-config
namespace: kube-system
data:
my-scheduler-config.yaml: |
apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: my-scheduler
leaderElection:
leaderElect: false
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
@@ -55,26 +69,31 @@ spec:
containers:
- command:
- /usr/local/bin/kube-scheduler
- --address=0.0.0.0
- --leader-elect=false
- --scheduler-name=my-scheduler
- --config=/etc/kubernetes/my-scheduler/my-scheduler-config.yaml
image: gcr.io/my-gcp-project/my-kube-scheduler:1.0
livenessProbe:
httpGet:
path: /healthz
port: 10251
port: 10259
scheme: HTTPS
initialDelaySeconds: 15
name: kube-second-scheduler
readinessProbe:
httpGet:
path: /healthz
port: 10251
port: 10259
scheme: HTTPS
resources:
requests:
cpu: '0.1'
securityContext:
privileged: false
volumeMounts: []
volumeMounts:
- name: config-volume
mountPath: /etc/kubernetes/my-scheduler
hostNetwork: false
hostPID: false
volumes: []
volumes:
- name: config-volume
configMap:
name: my-scheduler-config
layouts/partials/deprecation-warning.html
+2 -2
View File
@@ -10,8 +10,8 @@
</div>
</section>
{{ else if and (eq .Section "blog") .Date (.Date.Before (now.AddDate -1 0 0)) -}}
<section id="deprecation-warning" class="outdated-blog">
<div class="content deprecation-warning pageinfo">
<section id="deprecation-warning">
<div class="content deprecation-warning pageinfo outdated-blog">
<h3>{{ T "outdated_blog__title" }}</h3>
<p>{{ T "outdated_blog__message" }}</p>
</div>